История развития отечественных АСУ

Департамент образования города Москвы

Государственное Образовательное Учреждение

среднего профессионального образования

Политехнический колледж №8

Имени дважды Героя Советского Союза И.Ф.Павлова

Реферат

по дисциплине «Автоматизированные системы управления теплоэнергетическими объектами и установками».

Тема: «История развития отечественных АСУ».

   Выполнил:____________

гр. 43-АСУ-2

Проверила: Дементьева И.Н.

2010 г.

История развития отечественных АСУ.

История индустрии программного обеспечения в России пережила не одну революцию. Но каждый раз все созданное терялось едва ли не полностью. Последовательного накопления результатов в масштабах отрасли почти не происходило. Если какое-то накопление и было, то только в виде знаний в головах отдельных специалистов. А отрасль страдала глобальными приступами амнезии.

Не желая программировать в машинных кодах, отечественные энтузиасты в 60-е годы проектировали для этих машин языки программирования, принципиально отличающиеся от американского Фортрана, Алгола или Кобола, самым бурным и последовательным было развитие общесистемного и прикладного программного обеспечения для «Минск-32». К середине 70-х были созданы и успешно эксплуатировались в различных АСУП мощные пакеты прикладных программ. Существовала ассоциация пользователей «Минск-32», распространявшая отечественные программы общего назначения со статусом freeware и shareware. В большинстве случаев программные продукты создавались талантливыми специалистами, объединяющимися в небольшие коллективы.

А вот «централизованное» отраслевое ПО, призванное ликвидировать дублирование разработок для однотипных задач, большой популярностью у предприятий не пользовалось. Основные причины — некачественное исполнение, невысокий уровень разработчиков, недостаточные знания объекта внедрения, слабая зависимость вознаграждения авторов от тиража программы.

Первая революция — это переход с машин второго поколения на ЕС ЭВМ и на ОС ЕС. Решение руководства страны по развитию направления ЕС ЭВМ позволило отечественным программистам в максимальной степени интегрироваться в индустрию американского «софта» (а на самом деле — стать к ней в хвост) и сделало абсолютно бесперспективным развитие, сопровождение, эксплуатацию созданных программ на отечественных машинах второго поколения. Большая часть накопленного была потеряна.

Прикладное ПО, не имеющее западных аналогов, было заново написано для ЕС ЭВМ. Правда, теперь уже с применением систем управления базами данных и других пакетов программ. В общесистемном программном обеспечении ведущие институты страны добросовестно заменяли сочетания слов: «IBM 360» на «ЕС ЭВМ»; «IMS» на «OKA»; «CICS» на «KAMA»; «ADABAS» на «ТРИАДА» или «ДИСОД», и так далее и тому подобное. Документация к ПО переводилась, как правило, лингвистами, и устанавливать соответствие между действующими программами и их описанием было затруднительно. Вместе с тем советские программисты постоянно «латали дырки» американского программного обеспечения.

Термин «автоматизированная система управления» - АСУ – прочно вошел в обиход как раз в середине 70-х, многие слова прижились, став привычными. Значительно хуже прижились и не получили распространения сами АСУ, хотя практически каждое предприятие так или иначе подверглось автоматизации, а программисты среднего и старшего поколения, чье становление прошло в годы больших машин, буквально вскормлены на идеях АСУ.

В истории становления и развития программного обеспечения (ПО) АСУ  выделяют три важных этапа. На первом этапе (60-е годы) элементы ПО АСУ  разрабатывались для каждой конкретной АСУ строго индивидуально. Использовать готовые программы из библиотеки практически не удавалось, поэтому ПО каждой АСУ требовало 3-5 лет работы квалифицированных специалистов, и о широком внедрении АСУ не могло быть и речи.

В 70-х годах, когда произошел всплеск интереса к созданию АСУ, возникло  противоречие между потребностью в АСУ и возможностью их разработки и  внедрения, сформировался второй этап становления ПО АСУ, на основе  концепции типизации методов, моделей, алгоритмов и программ ПО АСУ. Однако практическая реализация такой концепции оказалась возможной далеко не сразу.

70-е годы (вторая половина) — время безраздельного господства машин из клона IBM 360/370.

Компьютеры по-прежнему были безумно дороги, но их мощность и надежность резко возросли. Начали создаваться крупные информационные системы для промышленных и торговых предприятий, банков, социальных учреждений. Пользователи перестали бегать с колодами перфокарт — появились сначала магнитные ленты, потом магнитные диски, а уж потом на рабочих местах возникли дисплеи, подключенные к центральной ЭВМ, расположенной в вычислительном центре фирмы.

ЕС ЭВМ и СМ ЭВМ не были полными копиями западных машин. Они были разработаны так, чтобы отечественные заводы, чья технология была хуже зарубежной, могли наладить крупносерийный выпуск. А программная совместимость на уровне аппаратной архитектуры семейств ЭВМ третьего поколения была основным решением, принятым во всем мире. Цель обеспечить программную совместимость ЕС ЭВМ и СМ ЭВМ с наиболее распространенными на Западе компьютерами, архитектуры которых стали стандартами де-факто, была вполне оправданной. Совместимость обеспечивала возможности сотрудничества организаций, занимавшихся применением ЭВМ, обмен прикладным и системным программным обеспечением. Конечно, при этом не было “расчета на то, что можно будет наворовать много матобеспечения”, а в страну хлынет поток этого обеспечения.

Задача разработки семейства моделей, программно совместимых между собой и с машинами семейств 360 и 370 фирмы IBM, была в инженерном отношении даже более сложной, чем разработка семейства с собственной оригинальной архитектурой. Нужно было не просто “угадать”,  как сделаны западные машины, а обеспечить совместимость с ними, реализуя эту архитектуру на другой элементной базе и конструктивах, которые отвечали бы технологии отечественных заводов да еще с учетом требований военных стандартов СССР. Будь машины ЕС ЭВМ копиями машин фирмы IBM, их нельзя было бы производить на наших заводах, а Министерство обороны СССР не могло бы их применять.

Благодаря программной совместимости с моделями семейств 360 и 370 фирмы IBM, на ЕС ЭВМ выполнялись зарубежные пакеты программ IMS, IDMS, ADABAS. Были выпущены их отечественные аналоги “ОКА” и “КАМА” – передовые по тем временам СУБД с телекоммуникационным доступом. На ЕС ЭВМ функционировало в большинстве применений ПО, разработанное совместными усилиями многих организаций, создававших АСУ, а также западное ПО, причем  не “ворованное”, а купленное (только в обход ограничений КОКОМ). Так что страна выиграла от программной совместимости ЭВМ, и это был не провал, а успех принятой технической политики. Это был действительно грандиозный научно-технический проект, в результате которого вычислительная индустрия перешла на новый качественный и количественный уровень, фактически от опытного к промышленному производству.

Для организации вычислительного процесса на этих ЭВМ понадобились операционные системы нового типа, позволяющие организовать диалог большого числа пользователей в режиме разделения времени. Мало того, создание крупных информационных систем поставило перед разработчиками общего ПО  проблему хранения больших массивов данных и организации их обработки множеством  независимых программ.

Возникла концепция систем управления базами данных (СУБД).

Разработка эффективных СУБД оказалась задачей не менее трудоемкой, чем проектирование ОС, первая промышленная СУБД IMS для IBM 360/370 была создана корпорацией IBM в 1969-1970.

Использование СУБД произвело настоящую революцию в индустрии обработки данных, стало одним из основополагающих элементов новых информационных технологий. Многие заказные кустарные программы, осуществляющие стандартные операции над данными, оказались ненужными, они были вытеснены надежными промышленными продуктами. Это — характерный пример того, как специальное ПО становится общим.

История баз данных фактически началась с появлением магнитных дисков. Эти устройства внешней памяти обладали существенно большей емкостью, чем предыдущее поколение носителей – магнитная лента и магнитные барабаны, а также обеспечивали во много раз большую скорость доступа к данным в режиме произвольной выборки. Базы данных на больших ЭВМ и первые СУБД пришли на смену файлам  и файловым системам.

Идея типового проектирования получила пусть не очень широкую и удачную, но все же реализацию  лишь на третьем этапе (конец 70-х и 80-е годы) становления и развития АСУ на основе пакетов прикладных программ (ППП) как наборов программно-алгоритмических средств, совокупность которых обеспечивает решение одной или нескольких близких задач АСУ.

Массовое поступление однотипных ЭВМ третьего поколения в сферу обработки экономической информации поставило по-новому проблему проектирования автоматизированных систем, требовало индустриальных методов решения этой проблемы. Современное состояние теории систем электронной обработки информации, советский и зарубежный опыт внедрения таких систем убедительно свидетельствуют о возможности индустриального подхода к проектированию автоматизированных систем. 

Основная  роль во внедрении индустриальных методов проектирования отводилась ППП общего назначения, которые являлись  основной формой организации программного обеспечения. В общем случае ППП — это набор программных средств, позволяющий решать определенный класс задач или выполнять определенную совокупность функций.  В виде ППП оформлялись  как программные средства, расширяющие возможности операционной системы и общей системы программирования (системы управления базами данных (СУБД), автоматизации документирования, информационно-вычислительные, обработки данных), так и все типовые классы задач АСУ. ППП выступали важнейшими компонентами программного обеспечения автоматизированных систем. На их основе поддерживается  работа прикладных задач (программ) с обрабатываемыми данными.

Об этом убедительно говорит опыт применения таких пакетов, как «Банк», «Ока», «СИОД», «Набоб» и др. ППП СУБД функционируют с такой же нагрузкой, как и программы операционной системы, и от организации (структурирования) базы данных прямо зависит непроизводительно затрачиваемое машинное время.

К сожалению, набор ППП СУБД, предоставляемый в распоряжение проектировщиков АСУ, недостаточно полон (в пакетах недостает средств загрузки базы данных, передачи данных по каналам связи, моделирования базы данных для выбора наилучшей по отношению к конкретным задачам структуры базы данных и т. п.), слабо освещена методика применения таких пакетов.

Первый опыт работы с системами управления базами данных в автоматизированных информационных системах показал, что для внедрения современной информационной технологии необходимо значительное расширение программного окружения СУБД. Это связано с тем, что задачи и запросы на обработку данных при создании информационных систем, ориентированных на массовых пользователей различной профессиональной ориентации, не могут быть выполнены с применением только алгоритмических языков. Большинство первоначально разработанных СУБД располагало средствами, предназначенными только для пользователей-программистов. Пакетный режим работы с базами данных, ограниченный набор языковых средств, отсутствие словарей-справочников данных и многих сервисных средств — вес это существенно ограничивало возможности применения СУБД в информационных системах. Если к этому добавить ограниченные объемы запоминающих устройств прямого доступа, отсутствие методических материалов по проектированию баз данных, не достаточную надежность вычислительных установок, то станут понятными трудности внедрения технологии работы с базами данных на начальном этапе.

В качестве основных достижений ПO АСУ разрабатывавшегося  и внедрявшегося  на основе ППП, назывались:  

                    ППП открыты для добавления в них новых модулей, что обеспечивает возможность непрерывного развития ПO;

                    ППП позволяют относительно легко и быстро с привлечением специалистов средней квалификации решать наиболее трудоемкую часть разработки и внедрения АСУ – создание программного обеспечения АСУ.

Проблемы и недостатки – их признавали

В это время (на рубеже 80-х годов) уже большое количество предприятий, организаций различных министерств и ведомств прошло через трудности внедрения систем и некоторые даже в повседневной работе начали ощущать преимущества автоматизированного управления, но в целом – первая эйфория массовой автоматизации начала спадать, формулируют  недостатки действующих систем:

                    нарушения системного подхода в определении состава автоматизируемых функций управления, заключающиеся, с одной стороны, в неполноте охвата взаимоувязанных функций управления,  неоправданном предпочтении одних функций управления другим, а с другой стороны, в попытке реализовать глобальную систему управления крупным объектом без учета таких факторов, как подготовленность объекта и возможности существующей техники;