Закономерность систем

Термин  «системный анализ» впервые появился в связи с задачами военного управления в исследованиях RAND Corporation (1948), а  в отечественной литературе получил  широкое распространение после выхода в 1969 г. книги С. Оптнера «Системный анализ для решения деловых и промышленных проблем».

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

Так, например, в ранних руководящих материалах по разработке автоматизированных систем управления (АСУ) рекомендовалось цели представлять в виде набора задач и составлять матрицы, связывающие задачи с методами и средствами достижения. Правда, при практическом применении этого подхода довольно быстро выяснялась его недостаточность, и исследователи стали прежде всего обращать внимание на необходимость построения моделей, не просто фиксирующих цели, компоненты связи между ними, а позволяющих накапливать информацию, вводить новые компоненты, выявлять новые связи и т. д„ т. е. отображать объект в виде развивающейся системы, не всегда предлагая, как это делать.

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

В настоящее время системный  анализ развивается применительно  к проблемам планирования и управления, и в связи с усилением внимания к программно-целевым принципам  в планировании этот термин стал практически неотделим от терминов «целеобразование» и «программно-целевое планирование и управление». В работах этого периода системы анализируются как целое, рассматривается роль процессов целеобразования в развитии целого, роль человека. При этом оказалось, что в системном анализе не хватает средств: развиты в основном средства расчленения на части, но почти нет рекомендаций, как при расчленении не утратить целое. Поэтому наблюдается усиление внимания к роли неформализованных методов при проведении системного анализа. Вопросы сочетания и взаимодействия формальных и неформальных методов при проведении системного анализа не решены. Но развитие этого научного направления идет по пути их решения.

2. Непроцедурные языки

Сразу же после появления программируемых устройств снижение сложности программирования стала одной из главных забот всех разработчиков. Первые этапы развития средств программирования хорошо описаны в литературе и не являются предметом данной статьи.

Для нас интересен момент выделения из общего дерева программных средств языков технологического программирования. Это событие стало результатом осознания особенностей задач, стоящих перед разработчиком АСУТП, и желанием приблизить алгоритмиста-технолога к написанию прикладных программ. Для удобства технологов программы стали представлять в графическом виде, привычном для проектировщиков АСУТП: релейно-контактных схем (RCS), функциональных блоковых диаграмм (FBD), ...(SFC). К концу 80-х годов, как вершина этого подхода, был разработан стандарт IEC1131-3. Опубликованный в 1988г, он включил в себя 5 языков технологического программирования: перечисленные выше графические плюс текстовые ST и IL. На момент своего принятия стандарт использовал современные технологии программирования и стал важным этапом развития языков технологического программирования, существенно облегчив разработчикам создание прикладных программ.

Однако, поставленную задачу, стать  средством программирования для  технологов - языки стандарта не решили и решить не могли, т.к. структура описания алгоритма, естественная для технолога (примером которой может служить любая инструкция оператора-машиниста), принципиально отличается от структур языков 1131-3.

В 90-х годах в мире программирования произошла настоящая революция, связанная с внедрением объектной и компонентной технологий. Однако, перевернув весь программистский мир, они лишь всколыхнули поверхность в «стране» АСУТП. Знакомство с новейшими пакетами нескольких очень известных фирм разочаровывает - новые технологии используются преимущественно в графических и цифровых интерфейсах, почти не повлияв на внутреннюю организацию систем. Последняя редакция IEC1131-3, опубликованная в 1999г, вообще не обратила на них никакого внимания, хотя при программировании систем реального времени эти технологии дают максимальный эффект. Фактически, первоначально удачный стандарт превратился сейчас в тормоз, а не стимул развития средств технологического программирования.

Характерно, что наиболее «продвинутые» SCADA-системы, например Genesis32, в качестве встроенного средства программирования используют не языки 1131-3, а различные варианты Visual Basic - объектность и компонентность языка перевешивают его «нетехнологичность», но естественным для алгоритмиста-технолога такой язык не является.

Использование современных технологий позволяет уже сейчас создавать системы программирования действительно дружественные для алгоритмиста-технолога.

Основой современной системы технологического программирования являются:  

1. объектный подход;
2. компонентная структура;
3. технология «промежуточного слоя» с микроядром;
4. непроцедурное программирование.

Автоматизированная система управления технологическим процессом (АСУ  ТП) — комплекс технических и программных средств, предназначенный для автоматизации управления технологическим оборудованием на промышленных предприятиях. Может иметь связь с более общей автоматизированной системой управления предприятием (АСУП).

Объектный подход - мощная современная технология проектирования и программирования, разработанная в конце 80-х годов. К настоящему времени АСУТП в силу большой инерционности остается одной из наименее освоенных этой технологией областей. Он практически не используется в системах технологического программирования, а при организации управления «объектность» не поднимается выше уровня задвижки и регулятора. Преимущества объектного подхода в сравнении с функциональным доказаны как теоретически, так и 15-летней практикой его использования.

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

Компонентная структура - современная технология построения программной системы из набора типовых элементов (компонентов). Для всех компонентов разрабатывается единый протокол взаимодействия с исполняющей системой, пользователями и другими компонентами.

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

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

Многослойная организация системы  полностью изолирует технологическую  логику работы прикладного ПО от используемых технических и низкоуровневых программных средств, обеспечивает высокую переносимость программного комплекса.

Последним словом» данной технологии является использование виртуальных  машин обеспечивающих максимальную переносимость программного кода.

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

Как известно, человеческое мышление построено прежде всего на ассоциациях и связях. Естественное мышление непроцедурно - алгоритмы типа «делай раз, делай два» составляются с трудом лучшими специалистами, а всеми остальными выучиваются наизусть. Вне производства люди по-возможности избегают жестких алгоритмов (показательно, что даже в классически-процедурном кулинарном процессе хозяйки не любят использовать «строгие» измерения и активно варьируют рецептуру, сохраняя смысловые связи между компонентами).

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

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

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

Заканчивая исторический экскурс хотелось бы особо отметить, что непроцедурное программирование - одна из немногих областей, в которых отечественная наукоемкое производство находится на передовых рубежах. Несколько коллективов РАН, ведущих соответствующие разработки высоко котируются в мире. К сожалению, Российское правительство практически не финансирует развитие этого стратегического направления отечественной научной технологии, а существенным источником финансирования работ в течении длительного времени были заказы от НАСА и министерства обороны США!

3. Процесс управления

Информационная система управления - система, предназначенная для управления, - как другой системой, так и внутри системы (т.е. в качестве управляющей  подсистемы).

Различают также основные 6 типов информационных систем управления (тип системы определяется целью, ресурсами, характером использования и предметной областью):

1. Диалоговая система обработки запросов (Transaction Processing System) - для реализации текущих, краткосрочных, тактического характера, часто рутинных и жестко структурируемых и формализуемых процедур, например, обработки накладных, ведомостей, бухгалтерских счетов, складских документов и т.д.
2. Система информационного обеспечения (Information Provision System) - для подготовки информационных сообщений краткосрочного (обычно) использования тактического или стратегического характера, например, с использованием данных из базы данных и структурированных, формализованных процедур.
3. Система поддержки принятия решений (Decision Support System) - для анализа (моделирования) реальной формализуемой ситуации, в которой менеджер должен принять некоторое решение, возможно, просчитав различные варианты потенциального поведения системы (варьируя ее параметры); такие системы используются как в краткосрочном, так и в долгосрочном управлении тактического или стратегического характера в автоматизированном режиме.
4. Интегрированная, программируемая система принятия решения (Programmed Decision System) предназначена для автоматического, в соответствии с программно реализованными в системе, структурированными и формализованными критериями оценки, отбора (выбора) решений; используются как в краткосрочном, так и в долгосрочном управлении тактического (стратегического) характера.
5. Экспертные системы (Expert System) - информационные консультирующие и (или) принимающие решения системы, которые основаны на структурированных, часто плохо формализуемых процедурах, использующих опыт и интуицию, т.е. поддерживающие и моделирующие работу экспертов, интеллектуальные особенности; системы используются как в долгосрочном, так и в краткосрочном оперативном прогнозировании, управлении.
6. Интеллектуальные системы, или системы, основанные на знаниях (Knowledge Based System) - поддерживают задачи принятия решения в сложных системах, где необходимо использование знаний в достаточно широком диапазоне, особенно в плохо формализуемых и плохо структурируемых системах, нечетких системах и при нечетких критериях принятия решения; эти системы наиболее эффективны и применяемы для сведения проблем долгосрочного, стратегического управления к проблемам тактического и краткосрочного характера, повышения управляемости, особенно в условиях многокритериальности. В отличие от экспертных систем, в системах, основанных на знаниях, следует по возможности избегать экспертных и эвристических процедур и прибегать к процедурам минимизации риска. Здесь более существенно влияние профессионализма персонала, ибо при разработке таких систем необходимо сотрудничество и взаимопонимание не только разработчиков, но и пользователей, менеджеров, а сам процесс разработки, как правило, происходит итерационно, итерационными улучшениями, постепенным переходом от процедурных знаний (как делать) - к непроцедурным (что делать).