Имитационный стенд для тестирования алгоритмов управления

[Jackson]

Обучающие стенды для операторов на опасных объектах - это требование ТН.
ИМХО это несколько иное, чем заявленная в топике цель.

ИМХО тоже. Тут цель не дать оператору имитатор вместо реального объекта, а другая, как я понял: дать разработчикам модель среднего уровня чтобы лучше состыковать его с верхним и с нижним исполнительным. Проблема в том что на реальном объекте средний уровень будет заменён, т.е. отлаживается только софт и не факт что на той же платформе. При переносе на реальный объект новые ошибки и нюансы неизбежны.

Поэтому наши датские коллеги пошли по другому пути и встроили модель объекта в аппаратуру среднего уровня, достаточно переключиться с реальных измерений на модель при отладке и обратно при запуске объекта. Даже при работе объекта в случае каких-то проблем можно всегда перейти к модели и проверить работу при остановленном/отключенном объекте или его части. То есть изделие после отладки как есть становится на объект и работает так как отладили без дополнительных операций. Часто используется в трёх случаях:

• при отладке готового собранного ГРЩ или ЩУ в отсутствии (или при стоящем стоящем) генераторов, при этом все исполнительные механизмы отрабатывают, видно как работает вся схема, хорошо отлавливаются ошибки монтажа;
• при постановке задачи когда нужно понять, какие вообще алгоритмы применимы на новом объекте и как их увязать;
• для удалённого разбора полётов и удалённой отладки: нам присылают актуальную конфигурацию всех контроллеров с реального объекта, мы тестируем эту конфигурацию и выявляем проблемы, объект всё это время продолжает работать если проблемы это позволяют делать.

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

Однако составление приличной модели и для реальных установок, типа гидрокрекинга, вкупе с разумным использованием таких моделей может обернуться прибылями, измерямыми в 7-8-значных цифрах.
И это весьма нетривиальная задача.

Может быть, это принесёт такую прибыль на стадии принципиальных разработок? А если объект с уже типовой отработанной технологией?

[Никита]

Интересная дискуссия :)
Вся фишка в том, что живем не в модели а в мире. Кроме параметров, непосредственно контролируемых и управляемых АСУ, есть туева хуча других факторов, которые непредсказуемы. От пьяного эксплуатационщика до выбитого космическими лучами носителя заряда в полупроводнике. Если учесть все возмущения, то сложность модели возрастет на порядки и трудозатраты могут просто разорить.
Модель взаимодействия объекта с окружающим миром построить невозможно, можно предусмотреть некоторые ситуации, которые могут возникнуть. Но тут все зависит от личных способностей разработчиков модели.
Вроде тут где-то вплывал пример, что в ПО элементарно не было предусмотрено ситуации, когда сырья привезли меньше чем надо и процесс дозирования не смог завершиться. Это моделируется элементарно, но если знать о такой возможности, то модель не нужна программист и так это учтет, а если про нее забыть - то и в модели не будет.
С другой стороны, с массой возмущений, не предусмотренных моделью, типовые решения неплохо справляются. Для второго примера - процесс горения в котле. Качество топлива плавает от завоза к завозу, но с этим разбирается штатная автоматика, никому и в голову не приходит моделировать это как возмущение, но тем не менее, система отрабатывает.
И третье - при крупных проблемах имеет место эффект домино, когда одна за одной начинают отрабатывать несколько защит. Учесть все эти взаимосвязи в модели - тоже непросто. Плюс режимы работы, которые я не представляю как учесть в модели. Третий пример - насос управляемый частотником может крутиться на 39 герцах и на 41. А на 40 он ловит механический резонанс. Естественно, при нормальной наладке, это окно будет пропущено, но в системе появится нелинейность, которая может сорвать процесс в колебания. Причем предсказать математически это возможно только с определенной вероятностью, ибо зависит от процесса изготовления насоса, центровки, износа и т.п.
Так что все модели хороши до определенного приближения к объекту, остальное - только опыт и реальность.

[shcham]

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

Конечно, модель не гарантирует 100% верности алгоритмов, получаемых на выходе процесса расчетов на комплексной модели, но по крайней мере, алгоритмы проверены хотя бы на модели, чем не проверены вовсе.

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

Ну а заключительным этапом (если есть модель) является стендовая отладка, когда модель и алгоритмы моделируются не в пределах 1 компьютера, а уже готовый ПТК, с контроллерами, блоками ввода-вывода подключается своими клеммами к миллиамперам и вольтам, выдаваемым ЦАП-ами из модели. Таким образом можно достичь уже отладки не только алгоритмической части АСУ, но и ее "железа", и также верхнего уровня, в обстановке приближенной к действительности.

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