Обсудить моделирование

Друзья! Те, кому алгоритмы интереснее каши, не могли бы вы высказаться по моей статье, которая вышла  в "Публикации on-line/ПО/Моделирование" ("Классификация дискретных выходов для улучшения графики SCADA", Александр Скуснов, Людмила Вертикова; мои благодарности Людмиле за рисунки)?

1. Пригодятся ли такие модели?

2. Используете ли вы какие-нибудь модели?

3. Не пора ли на форуме завести новую рубрику типа "Алгоритмы и моделирование", т.к. программисту бывает всё-равно на каком контроллере и на каком языке реализовать задачу управления. А вот как мы внедряем алгоритмы оптимизации, адаптации, цифровой фильтрации, нейронных сетей, да и просто ПИД-законы - это по-моему надо обсуждать.

(Коротко о статье. Дискретный выход - это 0 или 1, что тут ещё придумаешь? Но  есть две хитрости. Во-первых, бывает, что исп. механизм подключен к двум выходам (напр., реверсивный э/дв. использует "Пуск/Стоп" и "Вперёд/Назад"), так появилось 6 вариантов. Второе. Перемещение (речь не идёт о трубах, котлах, линиях электропитания) бывает лучше передать с реальной скоростью, а не мгновенно, поэтому вводим время реакции (ещё можно добавить трёхмерку). Даже такой выход как включение освещения при использовании диммиров займёт неск. секунд и это вы захотите продемонстрировать вашему клиенту в SCADA.

Статью прочел, спасибо - зачастую полезно размять мозги, закостеневшие в рутине.

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

1)ориентироваться на выходные сигналы, не имея обратной связи от исполнительных механизмов (ИМ), все-таки идея порочная, хотя, как говорится, что имеем, то и используем. Причем подводные камни тут одинаковые как для контроллера, так и для SCADA - наличие выходной команды не дает 100% срабатывания ИМ.

2) не очень понял упор на имитацию в среде визуализации. В статье совершенно справедливо отмечено, что уже давно ведутся успешные работы по объектно-ориентированному программированию.

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

Хуже обстоит дело, когда речь идет о программировании на RLL, тогда  - да, в контроллере приходится делать специальные флаги состояния ИМ, придумывать для этого схемы (тот же триггер с квитированием). Но как правило подобные флаги все равно будут нужны при выполнении технологического алгоритма. Таким образом, перенося "имитацию" ИМ целиком на контроллер, мы убиваем двух зайцев: имеем возможность использования максимально корректного определения состояния и возможность его визуализации без доп. скриптов в SCADA.

Да, согласен - это минус.

Хотя и тут все неоднозначно. К примеру встречал объектные алгоритмы, которые всю статусную информацию выдавали в зашифрованном 16-битном виде. И наряду с сигналами неисправности арматуры (которые все равно надо было вытаскивать в SCADA) в этом слове были и биты, отвечающие за ее состояние и полученные путем анализа момента подачи команды, тип команды, времени ее действия и т. д.

То есть для SCADA вся эта информация считывалась одной переменной (Word).

Тут, как и везде, выбор - либо платим за несколько большее время разработки проекта программисту, либо за "лишние" точки ввода/вывода.

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

Мое почтение !

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

Теперь о контроллере. Безусловно, все управление должно быть сосредоточено только в нем, никакие функции не доложны перекладываться на визуализацию или другие модули - это однозначно.

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

С уважением, SAN