DRAKON.SU

Мне сложно называть себя программистом. Скорее специалист по проектному обучению. И мне ДРАКОН интересен скорее как способ описания специфического знания, а не инструмент для создания программы для ПК/МК. Но использую его для программирования, т.к. это детям интересно, и результат быстро достижим.

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

Вспоминается методика по Зюбину:
* https://forum.oberoncore.ru/viewtopic.php?f=152&t=5971&view=previous#p99829

* Пути расширения языка ST из состава МЭК 61131-3 для задач промышленной автоматизации

* Программирование информационно-управляющих систем на основе конечных автоматов: учебное пособие

* Разработка графического формализма для описания алгоритмов в процесс-ориентированном стиле

Там свой язык для ПЛК (текстовый и вариант блок-схем). Транслируется в С, всё на глобальных переменных, однако процессы имеют своё логическое распределение имён с заданными областями видимости -- мол такие-то переменные доступны всем процессам или таким-то выбранным. Процесс может иметь вход/выход как ссылки на переменные других процессов.
В общем, есть смысл взглянуть на тамошние мотивы, может быть подскажут что-то насчёт организации общих алгоритмов (именно общих или обобщённых, когда нужны и параметры подпрограмм). При трансляции, как вариант, подпрограммы можно сливать и в общую "goto-лапшу" или "автомат" единого тела FB, как здесь:
https://forum.drakon.su/viewtopic.php?f=211&t=6305&start=40#p102165

Вспомнились ваши примеры, среди них:
https://forum.drakon.su/viewtopic.php?f=211&t=6305#p102080

На первом рисунке по ссылке выше есть применение ФБ "ТАЙМЕР_ИМП_1" -- видимо, пример "классики".
Там же в теме "комментарий" по означенной проблематике:
https://forum.drakon.su/viewtopic.php?f=211&t=6305&start=20#p102163

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

https://forum.drakon.su/viewtopic.php?f=211&t=6860#p104864

Увы, не попробую (особенно на 200 икон). В своей деятельности с ПЛК/встроенкой не повязан, о предметке поверхностные представления.
Для оперативной деятельности (программирование) Дракон не использую, лишь для моделей "верхнего уровня", постановок задач. И то, если не нужна "презентация", то в ходу псевдокод (или иногда реальный специализированный скриптинг) и Р-схемы, заменить их Дракон-ом всё никак не получается.
Однако позволю себе предположить, что в случае 200 и более икон необходима некая иная методика, изначально "разобранная", что ли...

В самом деле, в подобной предметке "высокоуровневые" автоматы в каком-либо виде, вроде бы, к месту.

Чтобы не плодить или уменьшить вспомогательные флаги и прочие данные для хранения предыстории "сложного" процесса и постоянно их анализировать/устанавливать при каждом такте исполнения, можно "фиксировать состояние", и в последующем уже не анализировать всё и вся каждый раз сначала. Смежные процессы должны исполняться тогда, когда нужно, и требовать минимум явной "технической обвязки" для себя (вспомогательных "управляющих" переменных и оперирование ими).
На Дракон-е с автоматами не всё так гладко, однако.

У Степана Митькина и Сергея Ефанова "состояния" -- ветка силуэта, с "ожиданием" в виде "выбора" или "ожидающего цикла с выходом во внешнюю среду" в начале ветки (в последнем случае истинная семантика не очевидна, о чём отмечено по последней ссылке). Так предопределяется соответствующая гранулярность алгоконструкций -- если внутри "состояния" возникает необходимость разделить операции по веткам (снять возникающее пересечение линий, выстроить "деревья решений" в данной алгоситуации), то необходимо выделять функционал в отдельную схему/схемы и внедрять/вставлять внутри ветки-"состояния".

Возникают вопросы по поводу непосредственно вычислительной модели. У Зюбина кроме "состояний" есть и "логический параллелизм" процессов через их "ручной" запуск/останов -- если под "процессами" эмулировать применение ФБ, то моделирование тогда оторвано от "традиционного" использования ФБ или предполагается иной стиль работы. Однако не стоит сразу же отбрасывать "чужеродное" -- не так уж просто по-другому вырулить на Дракон-е...

У Ефанова, к примеру, задействована модель на базе switch-технологии от Шалыто, где есть "задержка результатов" на один такт исполнения системы согласно политики диспетчеризации процессов -- не от хорошей жизни. К тому же в этом случае возникают обвязки в виде отдельных переменных-"сообщений" (требующих специализированной инфраструктуры, т.е. набора операций или "фреймворка" для своей поддержки) -- в дополнение к имеющимся "свойствам" ФБ (их входам/выходам, если внедрять такую модель поверх ФБ).

Помнится, он критиковал модели автоматов выше, небезосновательно. Предлагал использовать "паузу" как границу "такта" (или "автоматного состояния") в алгоритме, если не ошибаюсь, под впечатлением методики реализации корутин в Kotlin.
Но в целом методология так и не была обозначена в какой-то более-менее целостной форме.

Вот у ANSYS, в тамошней SCADE, автоматы очень-таки толково выглядят.

Можно воспользоваться некоторыми фундаментальными принципами от упомянутой "многолимонной" SCADE и внедрить их, но уже в "наколенную" императивщину "для бедных". Ключевое:
- автомат как гиперфункция (на манер терминологии от Зюбина выше) -- функции/процессы могут изменять своё поведение во время работы в качестве реакции на один и тот же вход -- полиморфный гиперпроцесс с "переключением" или выбором функций во время исполнения;
- иерархическая и параллельная композиция автоматов с "вытеснением" -- прекращением работы автоматов или переводом их в иное состояние;
- так называемый "модульный reset" -- операция вида "сброс состояния" или "начинать сначала", "в исходное" или т.п., распространяемые косвенно в разрезе нужной композиции процессов.

Нужна оценка, насколько может быть усложнён язык моделирования и оправданно ли...

Далее в общих чертах накидаю некую методику. Во всяком случае -- как почва для анализа особенностей Дракон-а, хотя бы...

Расширим базовый тезаурус императивного языка моделирования (в дополнение к последовательности и goto, развилкам и циклам).

Добавим "паузу" в потоке управления или "передача управления". Пример, абстрактный псевдокод:

Подпрограмма f1 обозначена через sub, чтобы подчеркнуть, что речь не о традиционных функциях как комбинаторных автоматах без состояния (обозначаемые часто как fn/function и т.п.).
Оператор yield -- приостановка или выход из алгоритма (не окончательный "возврат"/"return") с выдачей выходных данных (если имеются). При следующем такте, т.е. вызове f1(...) с новыми входными данными, управление восстановится в точке yield, и алгоритм продолжит исполнение далее (при этом все необходимые внутренние переменные сохраняют своё состояние). При достижении конца алгоритма или оператора вида return последующий такт исполнения осуществляется с начала тела алгоритма.

Так в данном примерчике имеем два варианта расчёта "y", исполняемые попеременно.

Предполагается предельная абстракция. Функция/процедура рассматривается как "вручную" регулярно вызываемая аля сопрограмма/корутина/субрутина (или, если угодно, как некий аналог селективных хранимых процедур в SQL-СУБД), со ссылками на входные/выходные данные (в сигнатуре опции in/out). Интерпретация разная: в каких-то случаях подпрограммы понимаются как "протоколы о намерениях", на основе которых осуществляется реализация распределенных систем, где-то формализм "переводится" или адаптируется на язык структур/объектов ("сохраняющих" состояние) с набором связанных методов (т.е. реальное сохранение и модификация данных осуществляется в "полях" структур/объектов), где-то непосредственно в технологическом языке возникнет прямая реализация (операции yield и др.), как в том же упомянутом Kotlin, например, и т.д.
Таким образом, предполагается отсутствие какого-то специализированного планировщика процессов и т.п., в этом случае "диспетчеризация реагирующих алгоритмов" -- повторное исполнение "вручную" или повторный вызов процедуры/функции/функционального блока (где-то там, в каком-то "управленческом" цикле, например). Или же задачи композиции совместно исполняемых процессов являются дополнительными согласно уже конкретной предметке, вне означенных рамок, в этом случае операция yield осуществляет передачу управления условному диспетчеру и т.п.

Р-схема, текстовая псевдографика:

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

О возможных Дракон-схемах далее, после разбора проблематики...

Пример использования "yield" в цикле -- цикла вида while, с множеством условий (ака "цикл Дейкстры") -- выполняем действия пока валидны предикаты цикла и "выходим" во внешнюю среду каждый раз после итерации:


Переменные fb1, fb2, fb3 символизируют другие "процедуры с состоянием" ("функциональные блоки").

Тело оператора "while ... end" (на схеме цикл выделяется "петлёй" -- двойной дугой) дополняется "then"-частью -- общая зона действий, исполняется в случае срабатывания какой-либо "охраны" (условия цикла), т.е. при наличии итерации цикла. В данном случае там единственный yield. После каждой итерации выполняется "выход". Когда цикл "непроходной" (не сработала ни одна охрана), то он завершается (без "выхода", поскольку "проход" в конечную вершину структуры-цикла в данном случае интерпретируется по двойной дуге).
На схеме then-часть цикла трансформирована в единственную вершину с точкой (общая вершина для всех структур под двойной дугой).

Оператор выбора/ожидания событий.

Такие "акты коммуникации" имеются как и в различных теоретических "исчислениях процессов", так и в ряде языков моделирования/программирования в виде операторов select, receive и прочие спецоперации. Ниже используется оператор select:


На схеме у структуры оператора select верхняя ("главная") дуга не имеет стрелки и её конечная вершина "разорвана" (две вершины с промежутком) -- это не сам переход (т.е. переход в "состояние" -- Р-схемы по сути есть упорядоченные графы переходов с образованием "графических структур"), реальный переход в конечную вершину структуры осуществляют дуги ниже (которые теперь являются "поглощёнными"). Так на схемах выделяются блоки.
В данном случае для блока в конце (при "разрыве") указана точка "выхода". Интерпретация следующая: "выход" выполняется, если вся структура является непроходной, т.е. когда предикаты на дугах из начальной вершины "не срабатывают". После "выхода" (при новом входе в алгоритм) попадаем в начальную вершину (новая попытка акта ожидания). Если какой-то вариант "сработал", то по дугам осуществляется переход в конечную вершину всей структуры, и "select" завершается.

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

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

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


К переменным fb1, fb2, fb3 применяется условно стандартная операция reset -- "сброс" состояния для заданных объектов/функциональных блоков. Сброс заключается в прекращении всех возможных "пауз" у процесса -- осуществляется прерывание операций ожидания "входа" и завершение всего алгоритма.

В дополнение к возможным стандартным операциям вида "конструктор/деструктор", в т.ч. и как здесь -- Init и Exit в ООП для функциональных блоков:
http://prolog-plc.ru/oopIECru

необходим и стандартный "пользовательский метод" (необязательный) как реакция на reset, например Revert (в общем случае семантика применения отлична от стартового "конструктора" или финального/окончательного "деструктора") -- после встроенного технического "сброса" осуществляется прикладная корректировка внутренних данных.

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

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

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

Частный случай -- ожидание единственного события и ничего не делать:

Цикл ожидания событий (оператор "for select"):


(в языках моделирования/программирования с оператором вида "select" не всегда встречается отдельный специализированный циклический оператор для выбора событий).

Дуга-"выбор" задана как двойная ("петля"). События "выбираются" циклически, т.е. после успешного "срабатывания" выбор повторяется. Цикл может быть завершён через оператор вида exit/break (на схеме отмечен как структурный переход "#" -- на конец данного блока -- выход из цикла), или иным способом (см. далее). Или же цикл может быть прекращён внешне, как и весь алгоритм -- через "сброс" где-то извне.

Изменим пример с циклом "for select" след. образом:


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

Действия по "сбросу" объектов fb1, fb2, fb3 перенесены в секцию finally, операция reset на схеме указана альтернативно через имя "~".

Ещё одна полезная секция -- "наблюдатель" (unless):


В упомянутой SCADE есть всякие способы "вытеснения", воспользуемся вариантом на манер оператора "do ... unless ..." из SCADE/Lustre (делать что-то пока не произойдут такие-то события) или "watching" из императивного SCADE/Esterel. По сути подобные операторы представляют из себя иерархическую композицию автоматов, где автоматы верхнего уровня имеют приоритет в реакциях на события и могут реагировать в виде переходов в иное состояние, "вытесняя" или прекращая работу внутренних вложенных автоматов (на диаграммах состояний так всё и отображается в явном виде).

В примере блок "do...end" (аналог "begin...end") разделен на секции, задействуя "финализатор" (finally) и "наблюдатель" (unless) -- последний на схеме обозначен параллельной структурой через спецвершину "(:)". Как и для оператора "выбор", в секции unless предполагается наличие начальных предикатов (из своей стартовой вершины) -- события, при возникновении которых немедленно осуществляется проход по данной структуре (выполняются указанные действия и пр.) и весь блок "вытесняется" (осуществляется немедленный выход из блока), с исполнением "финализатора" (если есть). Если при работе "наблюдаемого" блока указанные события не возникают, то секция unless не исполняется.

"Наблюдение" начинается с момента входа в зону ответственности (т.е. с входом в указанный блок, do...end в примере). Важно понимать, когда именно "возникают" события. Упрощённо -- как только данные, ассоциированные с предикатами событий, интерпретируются как условно новые. Причём "наблюдатели" имеет высший приоритет над прочими "потребителями" этих данных.

Данные могут возникать при "входе" во время любого "ожидания" -- секция unless может контролировать и "выбор события" в каком либо виде, в том числе может прекращать работу циклов "for select" (циклический выбор событий ранее) и любых циклов вместо операторов exit/break. В случае "выбора событий" семантика "доступности" данных такая же, как и для соответствующего оператора "ожидания", но у unless выше приоритет.

Если анализируются "пассивные" изменяемые объекты -- операнды, над которыми совершается работа, то предполагается анализ их нового состояния после совершения операции над ними.

Так в примере используется некий объект st типа stream (какая-то работа с потоком данных). После каждой операции чтения/записи (изменяющей состояние объекта) возможны проблемы: может возникнуть техническая ошибка -- метод "err()" возвращает true, если объект находится в "ошибочном" состоянии; может быть выявлено окончание данных или их некорректное состояние -- метод "eod()" сигнализирует об этом.
В каких-то случаях может быть выстроен цикл вида:

Выше "опасное" действие в цикле находится под "защитой" его условия. В исходном примере нет подобного цикла, необходимо делать проверки после каждой операции с потоком (или перед последующей операцией с ним). Можно действовать "в рамках структурности" -- анализировать "вручную" каждый раз и далее продвигаться согласно "защите" потока управления (без дополнительных досрочных выходов и т.п.), как здесь, например:
https://forum.oberoncore.ru/viewtopic.php?f=27&t=3175#p57990
https://forum.oberoncore.ru/viewtopic.php?f=6&t=2290

Однако, каждый раз требуется один и тот же анализ (и реакция). В программировании напридумано немало трюков, чтоб "выкручиваться" в подобных случаях: задействование механизма исключительных ситуаций (сами операции "бросают исключения"), обвёртки в виде спецфункций/макросов (или их аналог в виде специализированных языковых инструкций в условно новых ЯП), генерирующие исключения или осуществляющие досрочные выходы из функций, либо производящие скрытые goto в нужные места и пр.
В автоматных же методиках ("реагирующих") полвека назад предполагалось выделение "главного" автомата, наделенного в едином месте полномочиями (т.е. некие общие действия, которые должны быть во множестве мест, выносятся в единую точку).

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

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

В том числе через unless можно выразить и перехват exception/trap и т.п., если требуется конкретикой технологического языка.

"Наблюдатель" возможен и при использовании "активных" объектов -- объектов, совершающих работу -- параллельные, конкурентные процессы:


В примере используется некий объект ao типа ActiveObj, имеющий свой параллельный поток управления. Предикат в unless как функция "top(ao)" (на схеме альтернативно -- крышечка с аргументом) означает "сигнализирующее" состояние у объекта -- в данном случае: объект завершил свою работу (сигнал по умолчанию).
Для "активных" объектов анализ их нового состояния (для "вытеснения") осуществляется перед обращением к таким объектам (или, точнее, во время обращения к активному объекту -- в конкретике реального технологического языка, скорее всего, будут свои особенности операций в подобных случаях, например, при вызовах вида "ao.GetData(...)" предполагается блокировка объекта или т.п. -- по сути осуществляется обращение к условному диспетчеру, который "разбирается" в событиях как и при операторах вида "select").
Второй предикат "d < 0" в unless -- над "пассивным" объектом.

Аналогично активным объектам возможны "вытеснения" и при анализе конкурентных объектов или разделяемых переменных (пассивных) между параллельными процессами:


Выше используются параллельные (и рекурсивные) действия в блоке "do...par...end" (на схеме структура с дивергенцией/конвергенцией процессов задана через спецвершины "(||)" и "(&)"). Рекурсивные вызовы обозначены двойной стрелкой, начало рекурсивной процедуры -- "двойной" вершиной (в "графике" -- кружок с двойной границей).
Объект found специального типа signal -- для конкурентного доступа, операция emit (на схеме -- крышечка как действие) -- "взвод" сигнала, top (как и в примере ранее, на схеме крышечка в качестве предиката) -- определение наличие сигнала.
В примере параллельные действия могут быть "вытеснены" в случае обнаружения искомых данных (технологический язык может предусматривать прерывание параллельных процессов и т.д.).

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

И последний "автоматный" штрих -- явные "автоматные состояния", или явные "гиперфункции" (по Зюбину выше):

Подпрограмма f1, которая может иметь какие-то промежуточные выходы как yield или в каком-либо ином виде, заканчивается особым образом -- для return в качестве операнда указывается функция f1_1 -- переключение в иное "автоматное состояние" (подпрограмма f1 не имеет выходного результата в сигнатуре как результат функции, т.е. её тип "sub f1(...): void", а не, напр., "sub f1(...): int", и для "обычного" return в данном случае нет операндов). Для f1_1 передаются ссылки на входные и выходные параметры (идентифицированы в сигнатурах через in/out), плюс некоторый дополнительный параметр (его значение сохраняется во время работы f1_1 как и прочие необходимые локальные данные). Теперь при вызове f1(...) будет "скрыто" выполняться f1_1(...). Затем f1_1 когда-то сделает "переход" в f1_2. При завершении f1_2 (если подпрограмма завершается самостоятельно) или при потенциальном "сбросе" f1 восстановит исходное "состояние", т.е. работа начнётся вновь с самой f1, и т.д.

Вторая форма "переключения в состояние" -- вместо "return ..." оператор "immediate ...", напр., "immediate f1_1(data, x, y)". В этом случае осуществляется "немедленный" переход -- происходит выход из исходной процедуры (например, f1) и сразу же выполняется новая указанная процедура (f1_1). В случае же оператора return -- новая процедура исполняется при следующем такте системы (при последующем акте диспетчеризации f1).

Такие субпрограммы напоминают части оператора "automaton" в SCADE/Lustre.

На алгоритмических Р-схемах "автоматные" переходы можно указать как особые структурные переходы:

К вопросу организации схем. Сформируем схемку для алгоритма:


Для всего тела функции определена секция finally.
Все return-ы (квадратиком отмечены возвращаемые данные) показаны явно как переходы в конечную вершину (проблематика неструктурных досрочных выходов из алгоритма -- отдельный вопрос).
Однако, "длинные палки" (как и свисающие длинные "лианы" в Дракон-е), выглядят не очень-то...

Переделаем:

Теперь досрочные выходы заданы как переходы через "#" (выход из блока, если неуказано целевое имя-адресат (т.е. label) -- выход из текущего блока, всей схемы в данном случае).
Однако, есть "пустые" альтернативные дуги, теперь ещё больше элементов в единой горизонтали, и не избавились от нижней "палки".

Ещё вариант:

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

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

Подобный "силуэт" был (вероятно, и есть) в "горизонтальном Дракон-е" -- InteloGraf:
https://forum.drakon.su/viewtopic.php?f=62&t=4060
http://intelograf.narod.ru/

В общем, вот такое направление наколенной автоматной методики, реализующей "гиперфункции" с помощью операторов передачи управления (yield), ожидания/выбора событий (select и for select, await), переключения или "перехода в состояние" (специальная форма return и immediate), операции "сброса" (reset), а также секций "финализатор" (finalize) и "наблюдатель" (unless).

Есть возможность организовать как и "иерархическую субординацию" (работа через вызов операций и передачу входных/выходных операндов), так и "горизонтальное" взаимодействие (оперирование смежными совместными объектами).

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

"Вставка" в стиле FBD -- слева входы, справа выходы -- на Дракон-схеме мало полезна, поскольку нет соединения этих входов (это не операторные схемы, нет явной передачи операндов, разве что иногда выход можно "замкнуть" на вход). Польза возможна для "комфортной продвинутой" отладки, если транслятор/интерпретатор крутой и может рисовать значения "по месту". Однако такие иконы, видимо, громоздки и "одиночны" (см. ниже)...

Вот здесь заметил императивную реализацию (на С++) стандартного набора базовых элементов в стиле CODESYS (таймеры, триггеры и пр.) для Arduino:
https://habr.com/ru/post/402315/

Подход выглядит практичным: объекты имеют "свойства" (ака входы/выходы ФБ) для поддержки исторического наследия методик и функции-методы вида "run(...): boolean", что позволяет использовать конструкты и в виде комплексных выражений (в т.ч. и как вложенные функции "g(f(x))") -- в общем, типичные выражения-вычисления (expression). Если язык/платформа позволяет перегрузить операцию "аппликации", то вместо "obj.run(...)" можно использовать объект "напрямую" аля "obj(...)".
В целом "формулы-выражения" могут быть внедрены где угодно либо там, где необходимо, в т.ч. и для компактизации конструкций (избавление от "одиночных" икон).
Однако, для прям уж "комфортной продвинутой инженерной" отладки необходим и такой же крутой интерпретатор, на манер некоторых IDE, "разбирающихся в формулах по месту", напр.:
https://github.com/lamdu/lamdu
http://lighttable.com/

А на форуме когда-то была попытка воссоединить Дракон и FBD:

* Алаверды Дракону
* Как запустить Дракона?
* Два пернатых в одной берлоге не уживутся?
* ДРАКОН и функциональные языки программирования

Степан конкретно обозначил проблематику (продублирую):
https://forum.drakon.su/viewtopic.php?p=75329#p75335

Рисунок к цитате выше:


И к рисунку:
https://drakon.su/_media/biblioteka/alaverdy_drakon.pdf

"Комплементарность" выше подразумевает вписывание Дракон-схемы вовнутрь FBD-блока (Дракон внутри FBD):
https://forum.drakon.su/viewtopic.php?f=62&t=4086#p75341

и инъекции FBD-блоков вовнутрь "вопросов":
https://forum.drakon.su/viewtopic.php?f=62&t=3355&view=next


Насчёт "чёткости ветвления ДРАКОНа". На последнем рисунке схема справа ("визуальное логическое выражение") демонстрирует правило "семейного сходства" (если не ошибаюсь) -- мол все последующие иконы ниже "узла принятия решений" (ниже "дерева вопросов") должны быть выровнены между собой (на смежных маршрутах) и быть именно ниже "зоны" предикатов (однако, подобные правила не реализуются самим синтаксисом языка -- дополнительно вручную или задача выравнивания возлагается на редактор, если он сможет "догадаться"). В случае масштабных "деревьев решений", когда вопросы переплетаются с действиями и другими промежуточными элементами, подобное выравнивание не всегда возможно. Здесь на форуме уже была тема с демонстрацией "деревьев решений", где, пожалуй, главная задача -- выкрутиться без пересечения линий, иначе алгоситуацию придётся рвать на ветки силуэта (или разные схемы), для чего в ход идут и "неструктурные" переходы (в т.ч. переходы на смежные маршруты), дублирование условий в предикатах (условная методика "визуального логического выражения" хоть и снижает, но не избавляет от потребности в дубликатах выражений), и пр. Например:
https://forum.drakon.su/viewtopic.php?f=215&t=6666&p=103698#p103696


Да, на схеме есть принципиальная возможность отобразить сложные комплексные условия. Узлы решений представляются нечто вроде в стиле "линейных бинарных графов" (от школы Шалыто):
https://forum.drakon.su/viewtopic.php?f=148&t=6693

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

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