DRAKON.SU

Онлайн-демо по автоматному программированию на языке ДРАКОН.
https://drakonhub.com/files/lift.html
Игрушечный лифт, можно понажимать кнопочки.
Диаграммы силуэт конечных автоматов.
Тестирование.

Степан, спасибо!

Очень интересно!

Степан, у вашего лифта есть как минимум 2 уязвимости:
1) Если лифт стоит на каком-то этаже, то можно постоянно нажимать кнопку вызова и лифт никогда не уедет
2) Если лифт стоит на каком-то этаже, то можно нажимать на кнопку этого этажа в кабине, и лифт никогда не поедет

Вот пример видео: http://recordit.co/kbJtN72jQc

Интересно как вы предложите устранять их.

Круто Степан правда не на русском
А как все четыре схемы со существуют?
Это получается на один лифт 4 контроллера надо?
В какой последовательности их стоит выполнять?
Где находится сам алгоритм Машины Состояния?
Пока идет переходной процесс допустим MOVING c выбором MOVE, другие ветки не в одном алгоритме выполнятся не могут? Значит машина состояний полноценно работать не может
Т.е. если в момент выполнения какой- то ветки алгоритма( т.к она зациклена сама на себя и выход может быть только по окончанию процесса) другие события могущие возникнуть в других частях системы обработке не подлежат?

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

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

Алексей, вы читали статью Степана Митькина по автоматному программированию на языке ДРАКОН, опубликованную в журнале "Программная инженерия" №1 за 2019 год?
https://drakonhub.com/files/pe_drakon_a ... n_2019.pdf

Да читал, задавал вопросы Степану, от ответов на которые он отклонился или ответил размыто.
С помощью теории конечных автоматов, неоднократно под разными углами, я пытался решить задачу управления группой насосов(простейшая задача имеющая огромное число вариантов реализации), но контроллер ... есть контроллер, он живет по другим, явно не теоретическим законам....
Результат отрицательный
Хотя казалось, что конечный автомат в данной задаче подход здравый....

Это называется "Держать лифт, пока друганы из столовой идут".


Никак, потому что это не уязвимость, а фича. Замысел такой: если дверь закрыта или закрывается на твоём этаже, нажми кнопку, и дверь откроется.

Но если есть желание эту фичу отключить, нужно просто убрать реакцию автомата Door в состоянии Closing на сообщение open.
А именно:
1. В машине Door, состоянии Closing, сообщении open убрать действие requestOpen(self).
2. Ниже в том же месте переключить икону Адрес с Opening на Closing.

Они соединены в виде упорядоченного графа.

4 машины внутри одного контроллера. Машин может быть сколько угодно.
Недавно решал задачу по непрерывному перерасчёту стоимости портфелей ценных бумаг на основании real-time данных с финансовых рынков. Там в одной программе крутится несколько тысяч автоматов.

Автоматы могут работать в нескольких режимах.
Данный пример работает в браузере, а там реактивная модель выполнения. В реактивной модели автоматы не нужно "выполнять", им нужно только кидать сообщения. Например "нажата кнопка 2 этаж" или "двери закрылись".
Кроме этого бывает режим опроса (polling). В режиме опроса есть цикл, в котором каждому автомату по очереди дают команду "выполни следующий шаг". Сообщения в режиме опроса автомату посылают путём установки флагов, которые автомат проверяет при выполнении шага. Иногда в цикле обходят не все автоматы в системе, а только "грязные". Иногда не флаги устанавливают, а кладут сообщения в очередь, принадлежащую этому автомату.

Алгоритм Машины состояния генерируется автоматически. Пример: строка 741 здесь:
https://github.com/stepan-mitkin/lift-d ... ftLogic.js

Могут. Каждый автомат представляет собой параллельный процесс.
Получив сообщение (или команду "следующий шаг"), автомат быстро выполняет некоторый код и сразу отдаёт управление обратно.
Потом следующий автомат выполняет свой код.

Ага. У нормальных лифтов защита от этого есть.
Либо у грузовых нормальная кнопка "для погрузки".


Это вообще уберёте. А что-нибудь в духе "если дверь не закрывается более трёх раз, то пищим, плюём на кнопки, закрываем и едем дальше"?

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

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

И это хорошо. Потому что любые параллельные процессы можно исполнять последовательно, и лучше по своим чётким правилам, чем полагаясь на планировщики "больших" ОС.

Да, Алексей, Вы правы.
Пытался применить теорию конечных автоматов неоднократно.
В результате получается что для каждого состояния необходимо писать полный обработчик этих состояний, который гарантировано должен выполнятся каждый цикл.
Далее т.к обработчик одинаковый для всех состояний я выношу его в отдельную ветку которая гарантированно выполняется каждый цикл.
Получается сквозной конечный автомат.
1) В начале цикла обрабатывается состояние конечного автомата после прошлого цикла, далее проверяются, не появились ли новые условия при которых необходимо изменить состояние автомата - эту ветку я обычно называю МАШИНА СОСТОЯНИЙ- результат выполнения ветки отправка к ветке необходимого конечного состояния.
2) Выполняем конечное состояние. Как правило это приравнивание входов подпрограмм, и выходных переменных, реже в ветке конечного состояния может находится вспомогательное событие, которое может влиять на данные, выполняемые только в этом состоянии автомата
3) последняя ветка обязательное гарантированное выполнение подпрограмм. Т.к многие подпрограммы должны работать с разностью данных между идущим циклом и предыдущим циклом. Нарушение этого правила ведет к некорректной работе подпрограмм. По факту подпрограммы- это очень простые конечные автоматы имеющие не более трех состояний (таймеры, тригерры, и прочий вспомогательный функционал.

Далее выполняется по тому же принципу следующий конечный автомат, .... и еще конечный автомат

пока не кончатся конечные автоматы длится цикл. Как только закончился цикл, снова начинается выполнение по вышеприведенной схеме первого автомата. И так до тех пор пока есть питание контроллера с интервалом 10 мсек.

Кроме всего прочего в машине состояний нужно проработать приоритет того или иного состояния.
Возможно что имеет смысл проработать теорию автомата состояний?