FBD (Function Block Diagram) по IEC 61131-3 удобен тем, что напоминает привычные схемы автоматики: блоки, входы-выходы, поток сигналов. На маленьком узле он выглядит «как документация сама себя». На крупном проекте без правил через год превращается в полотно, где никто не понимает, откуда взялся сигнал, какие границы ответственности у блоков и что можно менять без регресса.
Ниже - про иерархию, именование, повторное использование, ревью изменений и связку с документацией и версионированием, плюс чек-лист ревью FBD перед выпуском в эксплуатацию.
Короткий ответ
Читаемый FBD на большом проекте - это не «красивые линии», а договорённости: глубина иерархии, единый словарь имён, библиотечные блоки с контрактом, маленькие диффы и прослеживаемость версий так же, как для исходного кода.
Если на листе больше ~30-50 функциональных смысловых узлов без группировки - пора дробить на подпрограммы или выносить повтор в FB/FC, а не «раздвигать монитор».
Иерархия: сколько уровней и что на каждом
Верхний уровень (обзор линии, агрегат, участок) - координация режимов, межподсистемные связи, без арифметики в каждом блоке. Здесь уместны крупные FB «насосная группа», «печь - зона 3», «транспорт - накопитель».
Средний уровень - технологические подфункции: пуск/стоп, аварийный останов ветки, выбор автомат/ручной, межблокировки.
Нижний уровень - детальная логика одного механизма или ограниченный набор сигналов; здесь допустимы мелкие элементы, но не дублируйте то, что уже инкапсулировано в библиотеке.
Правило большого пальца: один лист FBD - одна история для читателя. Если истории две - два листа или вложенный FB.
Именование: чтобы поиск и diff работали
•Сигналы процесса - по словарю проекта (технологический тег, суффиксы _Cmd, _Fb, _Alm и т. д., как договоритесь).
•Внутренние - с префиксом области (Z3_, L12_) или типа (b_, r_) - главное единообразие, а не «как у автора вчера».
•FB и экземпляры - имя типа и имя экземпляра должны отвечать на вопросы что это и где стоит (FB_MotorStarter, MS_Drive03).
Имя FB_001 через полгода не объяснит ничего ни вам, ни в git blame.
Повторное использование: библиотека, а не копипаст
Повтор - только через типизированный FB/функцию с зафиксированным интерфейсом (входы-выходы, ENO, коды ошибок). Копипаст трёх одинаковых цепочек гарантирует, что исправление бага делается один раз в одном месте - а на деле нигде полностью.
Для вариантов (два производителя датчика, два режима) лучше один FB с ENUM/режимом или наследование/расширение в рамках возможностей среды, чем две почти одинаковые ветки на одном листе.
Ревью изменений: что смотреть в FBD
•Размер диффа: если в merge попало пол-экрана несвязанных линий - ревью почти бесполезно. Требуйте атомарных задач и переноса проводки отдельным коммитом только когда это оправдано.
•Поток сигналов: в западных командах часто договариваются слева направо (питание логики - слева, исполнение - справа) или наоборот - важно не смешивать в одном проекте.
•Сквозные связи через десять листов без стрелок/кросс-референсов - источник ошибок; для них нужны глобальные структуры или явные FB-интерфейсы, а не «провод куда пришлось».
Документация и версионирование
Документация для FBD - это не PDF «на весь проект», а живые связи:
•таблица сигнал - блок - лист;
•для каждого критичного FB - краткое текстовое назначение (в свойстве блока, wiki, README в репозитории);
•ссылка на P&ID или функциональную спецификацию номером строки/раздела, а не «см. файл».
Версионирование: бинарные/полубинарные файлы среды плохо дружат с git merge - выбирайте политику: либо экспорт в текстовые форматы там, где платформа позволяет, либо жёсткие ветки и ответственный за слияние, либо вендорский сервер версий. Главное - не надеяться на «все помнят».
Практика крупных команд: связка тикет в трекере - номер сборки ПЛК - тег в репозитории/архиве и журнал изменений на объект.
Типовые антипаттерны
•«Божественный лист» на тысячу элементов - невозможно ревьюить и невозможно тестировать по частям.
•Магические константы на входах блоков без именованных констант в проекте.
•Смешение уровней: на одном листе и межблокировка линии, и PID внутренностями, и обработка драйвера.
•Скрытые глобальные переменные без явного контракта FB.
•Отсутствие ENO/ошибок у библиотечных блоков - сбои «проглатываются» молча.
Чек-лист ревью FBD перед выпуском в эксплуатацию (10 пунктов)
1.Иерархия: нет листов, которые одновременно описывают несвязанные подсистемы; крупные узлы вынесены в FB/отдельные программы.
2.Имена: сигналы и экземпляры FB соответствуют словарю проекта; нет «temp1», «Network_12» без смысла в имени.
3.Поток: согласованное направление чтения схемы; минимум хаотичных пересечений; кроссы подписаны или заменены на структурированные связи.
4.Повтор: дублирующиеся цепочки сведены к библиотечным FB; нет расхождения копий после правок.
5.Константы: все уставки и таймеры, влияющие на безопасность процесса, именованы и вынесены в зону параметризации, а не «зашиты» только на диаграмме.
6.Аварийность: для каждого критичного пути есть явная индикация отказа (ENO, код ошибки, alarm-бит) и понятное поведение при сбое датчика/исполнителя.
7.Гонки и порядок: учтён порядок выполнения в рамках среды (скан, вызовы, условия); нет «хрупкой» логики, зависящей от случайного порядка сегментов без документации.
8.Соответствие спецификации: каждый режим (авто/ручной/ремонт) прослеживается до требований в документе; нет недокументированных переходов.
9.Трассируемость версий: известны кто, когда и по какому тикету внёс изменения; архив/тег соответствует прошивке на стенде, прошедшей FAT.
10.Тест: есть чек-лист сценариев (норма, граница, отказ датчика, обрыв связи, ручной режим) с отметками выполнения под этот релиз.
Где уместен СТАБУР
В проектах на базе СТАБУР FBD остаётся рабочим языком для технологической логики, если закрепить проектные стандарты (иерархия, имена, библиотека, ревью) так же, как для кода на ST. Тогда смена интегратора или расширение линии не превращается в археологию по полотнам.
Заключение
FBD масштабируется дисциплиной, а не размером монитора. Иерархия, контракты FB, именование, маленькие изменения с ясным diff и версия, привязанные к тесту - это минимальный набор, без которого «функциональная схема» быстро становится лабиринтом, опасным для эксплуатации и дорогим для сопровождения.
FAQ
Стоит ли весь проект переводить на ST вместо FBD?
Не обязательно. Часто оптимально FBD на верхнем и среднем уровне, а алгоритмы - в ST внутри FB.
Как бороться с merge в среде без текстового diff?
Через модульные границы, ответственного за слияние, частые интеграции и автоматические экспорты там, где инструмент это позволяет.
Один FB может вызываться тысячи раз по скорости?
Зависит от платформы и кода внутри; при росте нагрузки профилируйте цикл ПЛК и упрощайте критичные вызовы.
Нужны ли стандарты для цвета блоков?
Если команда воспринимает цвет как семантику (авария, ручной) - да, и едино для всего проекта.
Что важнее: красота схемы или покрытие тестами?
Для эксплуатации важнее предсказуемость и трассируемость; красота помогает ревью, но не заменяет тест.
Обсуждение