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

Шалыто А.А.

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Парадигма автоматного программирования состоит в представлении сущностей со сложным поведением в виде автоматизированных объектов управления.

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

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

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

Литература

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.

Об авторе: Анатолий Шалыто - докт. техн. наук, профессор, Университет ИТМО
Помещена в музей с разрешения автора 30 декабря 2022