Почему в эпоху нейронных сетей для управления ответственными технологическими объектам необходимо применять автоматное программирование

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

Теперь и я решил «позвонить». Нейронные сети применяют, в том числе и в управлении техническими объектами, например комбайнами. Однако, по моему мнению, всё что создано рукотворно человеком, должно быть понятно Разработчику, Заказчику и Пользователю автоматизированного объекта управления. Каждый из них должен понимать, как работает система управления. Это должно позволить сравнительно просто реализовать старинное свойство, предъявляемое к системам управления – обеспечить их «ремонтопригодность», понимаемую как приспособленность к внесению изменений в определенные документацией сроки.

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

Если же в процессе испытаний или в ходе эксплуатации изделия авария будет связана с человеческими жертвами, то родственников погибших, конечно же, не удовлетворит естественный в этой ситуации ответ: «Недоучили!».

Этого существенного недостатка для ответственных технологических объектов лишено автоматное программирование, которое я и мои ученики развивают и успешно внедряют в промышленности уже много лет. Кратко изложу его основы.

1. Основным понятием автоматного программирования является понятие «состояние». Мне кажется, что в программировании состояния также важны, как и в жизни человека: если у человека кружится голова, то состояние «кружится голова» отвратительно, и он не хочет находиться в нём долго, и старается побыстрее перейти в другое состояние, в котором понимает, что все «встало на свои места». Думаю, что программа, в которой с самого начала не выделены состояния, «испытывает» нечто похожее на головокружение человека, что не нормально.

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

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

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

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

4. Еще о состояниях. А. Дж. Перлис в 1966 г. [1] предложил в описания языка, среды и правил вычислений включать состояния, которые могут подвергаться мониторингу во время исполнения, позволяя диагностировать программы, не нарушая их целостности. В этом же году Э. Дейкстра [2] предложил ввести так называемые переменные состояния, с помощью которых можно описывать состояния системы в любой момент времени. Он (как и я в автоматном программировании) использовал для этих целей целочисленные (многозначные) переменные. При этом им были поставлены вопросы о том, какие состояния должны вводиться, как много значений должны иметь переменные состояния, и что эти значения должны означать. Он предложил сначала определять набор подходящих состояний (и я в автоматном программировании предлагаю тоже), а лишь затем строить программу. Он также предложил сопоставлять процессы с переменными состояний и связывать процессы через эти переменные, что я делаю в автоматном программировании.

5. По мнению Дейкстры, диаграммы переходов (я их называю графы переходов) между состояниями могут оказаться мощным средством для проверки программ. Это обеспечивает поддержку его идеи о том, что «программы должны быть с самого начала составлены правильно, а не отлаживаться до тех пор, пока они не станут правильными». Не появление ли автоматного программирования он предвещал [3-16]

6. А еще мне близки слова Б. Лисков (https://ru.wikipedia.org/wiki/Лисков,_Барбара): «Моделируйте свои классы на основе поведения, а не свойств. Моделируйте свои данные на основе свойств, а не поведения». При этом всегда надо помнить: «то, что не специфицировано формально, не может быть проверено, а то, что не может быть проверено, не может быть безошибочным».

7. Наличие явно выделенных состояний в автоматных программах позволяет естественным образом (без дополнительных затрат) формировать протоколы, как для отладки, так и контроля их работы. Вот, что по этому поводу пишет мой аспирант А.В. Калачинский [16], неоднократно применявший автоматное программирование на практике: «Одной из замечательных возможностей, заложенной в автоматное программирование, является автоматическое встраивание в генерируемый код функций документирования работы автоматных программ, что позволяет полностью контролировать процесс их выполнения. Это обеспечивает возможность значительно сократить время автономной и комплексной отладки систем». И еще от него: «Для систем управления объектами повышенной важности Заказчиком часто выдвигаются дополнительные требования к системе по ведению штатного документирования поведения объекта и работы системы. Таким образом, дополнительный, часто только отладочный функционал документирования работы автоматной программы, превращается в необходимую и обязательную часть функционирования системы – штатную функцию регистрации наблюдения за объектом управления и работой системы. Эта особенность автоматного программирования позволяет без дополнительных затрат превратить технологический (отладочный) режим в одну из основных функций системы, которая обеспечивает реализацию очень важного требования Заказчика».

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

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

10. Формализация на основе использования графов переходов автоматов при выдаче технического задания позволила разделить работу, а главное, ответственность между организациями Заказчика и Разработчика. Это также обеспечило возможность проводить корректировку алгоритмов и программ не в терминах судовых устройств, как это делалось до сих пор, а в терминах автоматов, что для программистов значительно проще и понятнее.

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

12. Графы переходов автоматов (в том числе вложенных), например, с помощью пакета Stateflow [11] изображаются на экране и отлаживаются в различных режимах (пошаговом и автоматическом). В пакете имеется возможность по графам переходов осуществить генерацию программы, в частности, на одном из ассемблеров ПЛИС, которая и загружается в схему. По этой технологии моим аспирантом Ю.Ю. Янкиным [11] реализовано программное обеспечение для модулей большого числа систем управления ответственными промышленными объектами. С динамикой работы указанного пакета можно ознакомиться здесь: https://www.youtube.com/watch?v=YNWdmnwHZi8.

13. Для поддержки автоматного программирования, в том числе и с участием автора, разработаны различные инструментальные средства, одним из которых является UniMod [8]. Сайт, посвященный этому средству, расположен по адресу https://unimod.sourceforge.io. Работа UniMod проиллюстрирована здесь: https://www.youtube.com/watch?v=Y4et51dz-HE.

14. Мой ученик В.О. Клебан [14] мне как-то рассказывал, что он сдавал на объекте управляющую систему, некоторые подсистемы которой были реализованы автоматно, а другие – традиционным путем. При этом автоматные подсистемы либо сразу правильно работали, либо не работали, и тогда их работоспособность обеспечивалась достаточно просто. Уверенность в правильности работы остальных подсистем отсутствовала даже после их сдачи.

15. Я предложил применять автоматные программы для управления ответственными технологическими объектами, так как обычно сравниваю традиционные программы с флагами со «слонами на тонких ножках», изображенными С. Дали на картине «Искушение Святого Антония». При этом я всегда отмечаю, что такие слоны уникальны – встречаются только на этой картине, а программы с флагами применяются повсеместно, обладая устойчивостью :-) этих слонов! Однако, по мнению В. Аллена, тонкие ножки присущи не только программам и слонам: «Профессор спасался от здоровенного мохнатого неправильного глагола tener (иметь), гонявшегося за ним на длинных тонких ножках». В общем, «в тонких ножках» в отличие от состояний, нет ничего хорошего…

16. Без исходных текстов плохо, но и с ними тоже бывает нехорошо. Чего же не хватает Заказчику, Разработчику и Пользователю «для полного счастья»? Ответ прост: проектной документации, выполненной весьма подробно и аккуратно, в которую программная документация входит только как одна из составляющих. Мосты, дороги и небоскребы без проектной документации обычно не строятся, а вот про программы несмотря на их в общем случае сложность этого не скажешь. В программировании сложилась ситуация, определяемая так: «Если бы строители строили дома так, как программисты пишут программы, достаточно было бы одного единственного дятла, чтобы разрушить цивилизацию». Время идет, а в этом вопросе несмотря на все мои старания, к сожалению, практически ничего не меняется...

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

18. Автоматные спецификации достаточно просто валидируются [15], а при необходимости и верифицируются [12, 13], так как программы этого класса формально и изоморфно строятся по модели, в то время как для иных классов программ верификация выполняется в обратном порядке – по программе строится модель, что, по моему мнению, противоестественно. Применение автоматов приближает к доказательному проектированию программ

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

20. Парадигма автоматного программирования состоит в представлении и реализации программ как систем автоматизированных объектов управления. Аналоги: объекты в объектно-ориентированном программировании и агенты в агентно-ориентированном программировании (https://znanierussia.ru/articles/Парадигмы_программирования).

21. Нахождение компромисса между сложностью автомата и сложностью операций объекта управления, примирение тьюрингова программирования с традиционным – это и есть «миссия» автоматного подхода в мире разработки программного обеспечения.

22. Возможно, что применение автоматного программирования является «серебряной» пулей, о которой в 1975 г. Ф. Брукс, говорил, что при создании ПО ее не существует, а через 25 лет – в 2010 г. [17] с учетом работ Д. Харела [18], основанных на одной из разновидностей автоматного подхода, в ее отсутствии он уже был не так уверен.

Видимо, не случайно в международном стандарте IEC 61499 [19], предназначенном для построения современных распределенных систем управления и автоматизации, в блоках, описывающих поведение программ, применяются не нейронные сети, а графы переходов конечных автоматов. Перспективные системы управления в нефтедобыче [20] и «интеллектуальной» энергетике [21] в настоящее время разрабатываются с использованием этого стандарта.

Обзорные статьи по автоматному программированию размещены здесь: https://vk.com/@1077823-vtomatnoe-programmirovanie, https://vk.com/@1077823-esche-ob-avtomatnom-programmirovanii.

Литература

1. Перлис А. Синтез алгоритмических систем / Лекции лауреатов премии Тьюринга за первые двадцать лет. 1966-1985. М.: Мир, 1993, с. 16-29.

2. Дейкстра Э. Взаимодействие последовательных процессов / Языки программирования. М.: Мир, 1972, с. 9-86.

3. Шалыто А.А. Switch-технология. Алгоритмизация и программирование задач логического управления. СПб.: Наука. 1998, 628 c.

4. Шалыто А.А. Автоматное проектирование программ. Алгоритмизация и программирование задач логического управления // Известия РАН. Теория и системы управления. 2000. № 6, с. 63-81.

5. Шалыто А.А. Алгоритмизация и программирование для систем логического управления и «реактивных» систем //Автоматика и телемеханика. 2001. № 1, с. 3-39.

6. Шалыто А.А., Туккель Н.И. Switch-технология – автоматный подход к созданию программного обеспечения «реактивных» систем // Программирование. 2001. № 5, с. 45-62.

7. Канжелев С.Ю., Шалыто А.А. Автоматическая генерация автоматного кода // Информационно-управляющие системы. 2006. № 6, с. 35-42.

8. Гуров В.С., Мазин М.А., Нарвский А.С., Шалыто А.А. Инструментальное средство для поддержки автоматного программирования // Программирование. 2007. № 6, с. 65-80.

9. Шалыто А.А. Парадигма автоматного программирования // Научно-технический вестник информационных технологий, механики и оптики. 2008. № 8 (53). Автоматное программирование, с. 3-24.

10. Поликарпова Н.И., Шалыто А.А. Автоматное программирование. СПб.: «Питер». 2008, 168 с.

11. Янкин Ю.Ю., Шалыто А.А. Автоматное программирование ПЛИС в задачах управления электроприводом // Информационно-управляющие системы. 2011. № 1, с. 50-56.

12. Вельдер С.Э., Лукин М.А., Шалыто А.А., Яминов Б.Р. Верификация автоматных программ. СПб.: Наука. 2011, 244 с.

13. Кузьмин Е.В., Соколов В.А. Моделирование, спецификация и верификация «автоматных» программ // Программирование. 2008. № 1, с. 38-60.

14. Клебан В.О., Шалыто А.А. Разработка системы управления малоразмерным вертолетом // Научно-технический вестник информационных технологий, механики и оптики. 2011. № 2, с. 12-15.

15. Шалыто А.А. Валидация автоматных спецификаций // Научно-технический вестник информационных технологий, механики и оптики. 2023. № 2, с. 436-438.

16. Калачинский А.В. Технология проектирования программного обеспечения систем дискретного управления на основе автоматного подхода // Системы управления и обработки информации. 2023. № 3, с. 30-47.

17. Брукс Ф. Мифический человеко-месяц, или как создаются программные системы. СПб.: Символ, 2010. 298 с.

18. Harel D. Statechart: A Visual Formalism for Complex Systems // Science of Computer Programming. 1987. № 8, pp. 231-274.

19. Дубинин В.Н., Вяткин В.В. Модели функциональных блоков IEC 61499, их проверка и трансформации в проектировании распределенных систем управления. Пенза. Изд-во ПГУ. 2012, 348 с.

20. Bartusiak R., Bitar S., DeBari D., Houk B., Stevens D., Fitzpatrick B., Sloan P. Open Process Automation: A Standards-Based, Open, Secure, Interoperable Process Control Architecture // Control Engineering Practice. 121 (2022). 105034.

21.Wang Y., Guo N., Yan G., Liu J. Design of Integrated Energy System Based on IEC 61499 and OPC UA / Proceedings of the 41st Chinese Control Conference, 2022, China, pp. 4270-4275.

Вариант этой статьи опубликован по адресу: https://computer-museum.ru/articles/yazyki-i-sistemy-programmirovaniya/6442/

P.S. «Замечательный текст! Миссия (автоматного подхода в мире разработки программного обеспечения), как ее я вижу, совпадает с Вашим энергичном отстаиванием принципов точности и четкости конечных автоматов в мире обычного ПО, которое так легко проглатывает и прощает программисту до поры до времени его ошибки» (И. Дейнека, ИТМО).