Комментарии 11
События в real time системе в принципе зло. Они мешают точному расчету времени реакции. Они могут зацикливаться. Они могут переполняться. У них могут быть гонки.
Словом отладка систем с событиями очень сложна. Но как раз про это ни слова в статье.
Создатели IEC 61131-3 были не дураки, и были в курсе о событиях. Однако их не реализовали.
Я так понимаю, что события притянули для необходимости рисования SM выполняющихся распределенно на медленных недетерминированных шинах типа MODBUS по TCP.
Если бы был EtherCAT, TSN, Profinet IRT и т.п. события бы не понадобились.
Т.е. по сути вот такая реализаци IEC 61499 - это декларация технологической отсталости.
Простенькое приложение с событиями где еще нет рисков запутаться может и ChatGPT нагенерить в VS Code. Для этого не нужны специальные IDE.
Если для управления достаточно одного ПЛК, то все верно. Как только появляется распределенная система (РСУ) то 61131-3 как раз и мотивирует на создание непрогнозируемых костылей (в основном на Modbus, ага).
События 61499 придумали для РСУ. А с появлением OPCUA over TSN/Ethernet APL только его и тащат в унифицированные вычисления. Впрочем 61131-3 внутри ФБ живет и будет жить.
Ну а то, что РСУ - сложные, так кому сейчас легко.
Для подобных проектов есть площадки типа github. Какие сейчас есть Open source SCADA?
Всегда было интересно, а те, кто пишут такие статьи - когда-нибудь что-нибудь ПНРили на реальной площадке с количеством сигналов в АСУТП этак в 500 и более?)
Помнится Вяткин много книжек по этому стандарту написал. Но, стандарт на практике не очень часто применяется... Интересно, как он стыкуется с 61850
Спасибо за статью и огромную работу!
Мы похожие вещи пытаемся делать, причем на отечественной элементной базе (https://habr.com/ru/articles/881784/). Сейчас работаем над 4Diac.
Как построить открытую АСУТП. IEC 61499 — основа открытой автоматизации будущего