УНИВЕРСИТЕТ ИТМО
Кафедра «Технологии программирования»

Автоматное проектирование программ. Алгоритмизация и программирование задач логического управления

(c) А.А.Шалыто

4. Выводы.

Предлагаемый подход позволяет:

• использовать теорию конечных детерминированных автоматов при алгоритмизации и программировании процессов управления;
• первоначально описывать желаемое поведение управляющего "устройства", а не его структуру, которая является вторичной и поэтому труднее читаемой и понимаемой;
• ввести в алгоритмизацию и программирование в качестве основного понятие "состояние", начиная алгоритмизацию с определения числа состояний;
• ввести понятие "автоматное программирование" и "автоматное проектирование программ";
• построение алгоритмов и программ начинать с формирования дешифратора состояний, а не событий;
• применять основные структурные модели теории автоматов и ввести новые;
• использовать в качестве языка алгоритмизации графы переходов и системы взаимосвязанных графов переходов;
• при построении графов переходов исключить зависимость от "глубокой" предыстории по состояниям и выходам, а по возможности и зависимость значений выходных переменных автоматов с памятью от значений входных переменных;
• применять многозначное кодирование состояний для каждого графа переходов и вне зависимости от числа его вершин использовать только одну внутреннюю переменную, их кодирующую;
• применять в качестве основной алгоритмической модели графы переходов автоматов Мура, у которых коды состояний и значения выходов принципиально разделены, а значения выходных переменных в каждом состоянии не зависят от входных переменных, что упрощает внесение изменений;
• обеспечить реализацию таких свойств алгоритмов управления как композиция, декомпозиция, иерархичность, параллелизм, вызываемость и вложенность;
• иметь один язык спецификаций при различных языках программирования, в том числе и специализированных, применяемых в программируемых логических контроллерах;
• проводить алгоритмизацию в результате взаимного общения Заказчика, Технолога и Разработчика. При этом выдача Технического Задания превращается из однократного события с "бесконечными" последующими дополнениями в однократный процесс общения, завершающийся созданием графа переходов или системы взаимосвязанных графов переходов, в которых учтены все детали с точностью до каждого состояния, перехода и бита;
• в качестве сертификационного теста применять графы переходов без флагов и умолчаний, у которых число вершин совпадает с числом состояний автомата, и строить граф проверки или граф достижимых маркировок для других классов графов переходов или систем взаимосвязанных графов переходов с целью проверки их поведения, что позволяет заменить тестирование программ анализом их функциональных возможностей;
• ввести формальный критерий понятности различных форм описаний автоматов с памятью - изоморфизм каждого из них с соответствующим графом переходов без флагов и умолчаний. При этом автомат, заданный таким графом переходов, может быть назван "абсолютно белым ящиком", а автомат, заданный в любой другой форме "относительно белым ящиком". Автомат, для которого известно максимальное число состояний в его минимальной форме, который может быть распознан на основе анализа "входо-выходных" последовательностей, назван в [42] "относительно черным ящиком", а автомат, о внутреннем содержании которого ничего не известно, не распознаваемый указанным "абсолютно черным ящиком". Таким образом, если понятие "состояние" при алгоритмизации и программировании не вводится, то в результате тестирования алгоритмов и программ с помощью входо-выходных последовательностей в общем случае не удается распознать автоматы, которые они реализуют;
• использовать методы формального и изоморфного перехода от спецификации к программам логического управления на различных языках программирования;
• при применении алгоритмических языков программирования высокого уровня проводить программирование с помощью конструкций switch (в том числе вложенных) или им аналогичных, что кроме изоморфизма со спецификацией обеспечивает доступность каждого значения многозначной переменной, кодирующей состояния каждого графа переходов, для всех остальных графов, входящих в систему, и поэтому не требует введения дополнительных внутренних переменных для реализации взаимодействия графов;
• ввести в программирование понятие "наблюдаемость", что обеспечивает возможность рассмотрения программы в качестве "абсолютно белого ящика", в котором все внутренние переменные, число которых минимально, доступны для наблюдения;
• проводить проверку программ в два этапа: сначала по номерам состояний проверить наличие всех переходов, имеющихся в графе переходов, а затем в статике в каждом состоянии проверить значения выходных переменных;
• Участникам разработки (Заказчику, Технологу (Проекту), Разработчику, Программисту, Оператору (Пользователю) и Контролеру) однозначно и полностью понимать, что должно быть сделано, что делается и что сделано в функциональной части программно реализуемого проекта, т.е. решить для рассматриваемого класса задач проблему взаимопонимания;
• на ранних стадиях проектирования учесть все детали Технического Задания и продемонстрировать Заказчику как оно понято;
• разделить работу, а самое главное, ответственность между Заказчиком, Технологом, Разработчиком и Программистом. Это особенно важно, когда указанные Специалисты представляют разные организации, а тем более страны, так как в противном случае возникают существенные языковые, а, в конечном счете, и экономические проблемы;
• Участникам разработки общаться не традиционным путем в терминах технологического процесса (например, не "идет" режим экстренного пуска), а на промежуточном полностью формализованном языке (своего рода техническом эсперанто), на котором объясняться можно, например, следующим образом: "в третьем графе переходов, в пятой вершине, на четвертой позиции - изменить значение 0 на 1", что не вызывает разночтений, возникающих из-за неоднозначности понимания даже для одного естественного языка, а тем более для нескольких таких языков, в случае, когда Участники разработки представляют разные страны, и не требует привлечения Специалистов, знающих технологический процесс, для корректного внесения изменений [43];
• снять с Программиста необходимость знания особенностей технологического процесса, а с Разработчика - тонкостей программирования;
• Программисту функциональных задач ничего не додумывать за Заказчика, Технолога и Разработчика, а только однозначно и формально реализовывать систему графов переходов в виде программы, что позволяет резко снизить требования к его квалификации, а в конечном счете и вовсе отказаться от его услуг и автоматизировать процесс программирования или перейти к автопрограммированию Разработчиком. Последнее возможно, однако, только в том случае, когда программирование является для Разработчика "открытым", что не всегда имеет место в особенности при работе с инофирмами или их подразделениями, занимающимися разработкой систем управления, а не только аппаратуры;
• оставлять понятные "следы" после завершения разработки. Это позволяет проводить модификацию программ новым людям, что при традиционном подходе чрезвычайно трудоемко ("проще построить программу заново, чем разобраться в чужой программе"). При этом необходимо отметить, что структурирование и комментарии указанную проблему решают лишь частично;
• упростить внесение изменений в спецификацию и программу и повысить их "надежность";
• сделать алгоритмы управления инвариантными к используемым языкам программирования, что открывает возможность формирования и поддержания библиотек алгоритмов, записанных строго формально;
• Заказчику, Технологу и Разработчику контролировать тексты функциональных программ, а не только результаты их выполнения, как это имеет место в большинстве случаев в настоящее время;
• устранить не равную "прочность" приемки аппаратуры и программ Контролером, так как в первом случае им кроме функционирования проверяется много других характеристик (например, качество печатных плат и их покрытий, качество пайки, номиналы и обозначения элементов), а во втором - все внимание уделяется только проверке функционирования и не исследуются внутренняя организация программ и технология их построения.

5. Аппробация.

Предлагаемый подход, в частности, использован:

• при создании системы управления дизель-генератором ДГР-2А 500*500 судна проекта 15640 на базе аппаратуры "Selma-2". Программирование выполнено НПО "Аврора" на языке функциональных блоков [2,41];
• при создании совместно с фирмой "Norcontrol" (Норвегия) системы управления дизель-генератором того же типа для судов проекта 15760. Программирование выполнено фирмой на языке ПЛ/М [43];
• при создании комплексной системы управления техническими средствами для судна проекта 17310 на базе программируемых логических контроллеров "Autolog". Программирование выполнено НПО "Аврора" на языке инструкций ALPro вручную (для общесудовых систем) и автоматически с помощью транслятора (для систем управления вспомогательными механизмами главного двигателя).

Заключение.

В течение всего времени пока создавалась предложенная и внедренная автором в 1991 году SWITCH-технология [41,44], складывалась весьма странная ситуация, состоящая в том, что ни одна (за исключением [22]) из ведущих в области автоматизации фирм мира не предлагала технологий алгоритмизации и/или программирования на базе графов переходов, являющихся основой рассматриваемой методологии.

Только в 1996 году эта ситуация существенно изменилась - фирма "Сименс" в дополнение к своим программным продуктам разработала новый продукт, названный "S7-HiGraph technology software", который позволяет использовать в качестве языка программирования диаграммы состояний (state diagram), что является другим названием графов переходов. При этом по описанию на этом языке автоматически генерируется исполняемый (только на программируемых логических контроллерах этой фирмы) код.

По мнению фирмы "Сименс", описание на таком языке не только подходит для Программиста программируемых логических контроллеров, но также понятно Инженеру-механику, Инженеру по запуску оборудования и Инженеру по обслуживанию [21].

Особенно странным в этой ситуации является то, что подобный продукт мог быть разработан, например и 15 лет назад, так как диаграммы состояний, в свою очередь, были предложены более сорока лет назад, однако, всемирное увлечение сетями Петри, которые обеспечивают возможность описания параллельных процессов одной компонентой (функциональной единицей) и являются поэтому основой языка "Графсет" (S7-Graph technology software), видимо, психологически не позволило этого сделать.

Автор надеется, что после появления указанного продукта будет иметь место эффект "домино", и в ближайшее время многие фирмы мира создадут аналогичные продукты.

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

Излагаемая технология - существенное дополнение Международного стандарта IEC 1131-3 [46], в котором описываются языки программирования программируемых логических контроллеров, но не излагаются методы алгоритмизации и программирования, которые подробно описаны в [39].

Предлагаемая технология может стать основой для повышения безопасности программного обеспечения систем логического управления [47]. Эта технология, не исключая других методов построения программного обеспечения "без ошибок" [48], существенно более конструктивна, так как позволяет начинать "борьбу с ошибками" еще на стадии алгоритмизации.

Использование пентады (состояние - независимость от "глубокой" предыстории - система взаимосвязанных графов переходов - многозначное кодирование - конструкция switch (или ее аналог в любом языке программирования, например, в языке функциональных схем)) обеспечивают наглядность, структурность, вызываемость, вложенность, иерархичность, управляемость и наблюдаемость программ, а также их изоморфизм (изобразительную эквивалентность) со спецификациями, по которым они формально строятся. Это позволяет Заказчику, Технологу (Проектанту), Разработчику, Программисту, Оператору (Пользователю) и Контролеру однозначно понимать друг друга и точно знать, что должно быть сделано, что делается и что сделано в программно реализуемом проекте. Это позволяет также разделять работу и ответственность, легко и корректно вносить изменения в алгоритмы и программы.

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

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

Применение систем взаимосвязанных графов переходов было рассмотрено в работах В.В. Руднева (например, [50]). Однако теоретический характер этих работ и использование двоичных переменных для связи графов ограничили применение этой модели на практике.

Автор надеется, что судьба предлагаемого подхода в части его практического использования будет более успешной.