Эта статья продолжает цикл воспоминаний разработчика тренажёрных комплексов. Несколько лет назад наша команда столкнулась с задачей создания эмулятора автоматизированной системы управления технологическим процессом (АСУ ТП) для одной из тепловых электростанций. Задача выглядела стандартной и несложной: воспроизвести логику контроллеров, разработать мнемосхему и запустить модель.
Однако реальность внесла свои коррективы. Исходных данных не хватало, сроки были крайне ограниченными, ресурсов недостаточно, а первая версия интерфейса HMI, созданная на собственном проверенном, но морально устаревшем инструменте проектирования, не соответствовала требуемым характеристикам производительности и масштабирования.
Цель настоящей публикации — поделиться опытом разработки эмуляторов АСУ для учебных тренажёрных комплексов, рассмотреть типы симуляций, привести пример архитектуры подобного решения, коснуться используемых технологий и языков программирования, описать часто возникающие трудности и предложить способы их преодоления.
Цена точности: сравнение методов моделирования АСУ в тренажёрах
Пару слов о методах моделирования АСУ ТП и компонентов в составе прикладного программного обеспечения тренажеров. Есть несколько методов, а именно
Полная симуляция — копия АСУ ТП, включающая аппаратное и программное обеспечение, интегрируется с тренажёром
Виртуальная симуляция — используется виртуальная копия программного обеспечения АСУ ТП на эмулируемом оборудовании
Гибридный метод — используется аппаратная платформа человеко-машинного интерфейса (HMI) АСУ ТП с эмулируемым программным обеспечением
Полная эмуляция — используется эмулируемое аппаратное и программное обеспечение АСУ ТП
Сравнение методов эмуляции/симуляции АСУ
Характеристика | Полная симуляция | Виртуальная симуляция | Гибридный метод | Полная эмуляция |
Необходимость данных | Не требуется (предоставляются вендором АСУ) | Низкая (требуется для корректного взаимодействия с эмулируемым HMI) | Средняя (требуется для связи между HMI и эмулируемым ПО) | Высокая (требуется для точной эмуляции реальной АСУ; чем точнее данные, тем лучше эмуляция) |
Проприетарные ограничения | Максимальные (все права на ПО и оборудование принадлежат вендору АСУ) | Высокие (все права на ПО и оборудование принадлежат вендору АСУ) | Средние (основная проблема — протокол связи между HMI АСУ и эмулируемым ПО) | Отсутствуют (всё оборудование и ПО полностью независимы от вендора АСУ) |
Временные затраты | Минимальные (время тратится только на точную интеграцию АСУ с моделями симуляции) | Низкие (время тратится на точную интеграцию моделей симуляции и эмулируемого HMI) | Высокие (время тратится на эмуляцию ПО АСУ и взаимодействие с HMI) | Низкие (время тратится только на эмуляцию ПО АСУ) |
Обновления | Средние (несложно реализовать, но может быть дорого) | Средние (зависит от ситуации) | Низкие (может быть сложнее, но может выполняться внутренним персоналом или сторонними специалистами) | Низкие (может быть сложнее, но может выполняться внутренним персоналом или сторонними специалистами) |
Техническое обслуживание | Высокое (сильно зависит от вендора АСУ по проприетарным компонентам и ПО) | Среднее (низкие затраты на обслуживание оборудования, но зависимость от проприетарного ПО вендора) | Среднее (низкие затраты на обслуживание ПО, но зависимость от проприетарного оборудования вендора) | Низкое (недорогое, легкодоступное оборудование и не проприетарное ПО) |
Стоимость в рамках поставки тренажера | Максимальная (каждый экземпляр АСУ включает полную стоимость проприетарного оборудования) | Низкая (недорого, при условии включения лицензионного сбора, можно использовать доступное оборудование) | Высокая (каждый экземпляр АСУ включает полную стоимость проприетарного оборудования) | Минимальная (недорого, легкодоступное оборудование и не проприетарное ПО) |
Вот именно о полной эмуляции мы и поговорим.
Боевой проект
На примере проекта по разработке и внедрению полномасштабного тренажера для тепловой станции мощностью в 800 МВт и работающей на закритических параметрах пара (это важно, так как модель физических процессов тоже очень нетривиальная).
Что же у нас есть на входе? Набор данных об АСУ ТП объекта прототипа. Это и инструкции по эксплуатации, технологические схемы, выгрузки из оперативной базы данных, схемы электрические принципиальные, и много чего еще. А главное, единиц оборудования порядка 1000 механизмов двигательной нагрузки, 4000 тысячи различной электроприводной арматуры, и около 10000 точек аналогово и дискретного контроля вместе взятых. И на все это есть свой алгоритм дистанционного управления, автоматического регулирования и не забываем про технологические защиты и блокировки. Гораздо важнее было то, что управляющие программы генерировались из штатной инженерной станции в виде человеко-читаемых текстовых файлов (некое подобие Structured Text), содержащие функциональные блоки и связи между ними. Такую информацию можно интерпретировать в виде модели.
Структурировав исходные данные (так как документы еще были с разными временными датами и о разных версиях ПО, и в разношерстных форматах PDF/DOC/ DWG/CSV), начала вырисовываться картинка что нужно сделать. На основе описания функциональных блоков были разработаны модели для работы в составе исполнительной системы тренажера. Интерпретатор программ управления среднего уровня был реализован на Python (версии 3.8.5 на тот момент), выбор был сделан из-за его простоты, работы со строками и текстом в целом. Первый прототип эмулятора среднего уровня был готов уже в течении недели, а дальше приходилось уже его полировать и доводить «копию близко к оригиналу». Хочу отметить, что возможности исполнительной системы тренажера позволяют также эмулировать и работу контроллерного оборудования, расчет программ с различным квантованием по времени, обмен между эмулируемыми контроллерами.
Интереснее дела обстояли с верхним уровнем. Операторские кадры хранятся в бинарном формате. И некоторую часть времени пришлось потратить для разбора в «языке древних свитков». Но команда у нас опытная, и это не первый эмулятор, который приходилось реализовывать. Разобравшись с исходными файлами, команда разработки принялась к созданию эмулятора верхнего уровня. Здесь уже в качестве технологического стека используется Java. Приложение должны быть кроссплатформенным, быстрым, и так сложилось, что в компании набралась сильная компетенция по разработке десктопных приложений на Java(Swing/JavaFx).
Часть компонентов была взята из наших библиотек, такие как обмен с моделью тренажера, сервисы архивации, сигнализации и журналирования, хотя некоторые изменения были внесены и в них, дабы соответствовать эталону. В качестве основного стека использовалась Java версии 14, а для рендеринга SVG графики на видеокадрах взяли популярную библиотеку Batik. Для хранения архивных данных использовали старую-добрую MariaDB. Весь проект получился порядка 300+ классов.
Окна трендов, управления механизмами, ввода информации реализовывались уже отдельно. Стоит дополнить, что не смотря на успешность разработки и проведение испытаний на полигоне, доработка программного обеспечения и отладка моделей во время опытной эксплуатации остается трудоемким процессом. Сказывается не хватка исходных данных, противоречивая информация от тест-операторов.
Пару слов про производительность. Поскольку на оригинальных АРМ обновлялись с дискретностью в 1 с, нагрузка на сервер и обмен информацией не столь значительны. Используемый на проекте сервер оснащён процессором Intel Core i7‑8700K (6 ядер, 3,7/4,7 ГГц) и 16 ГБ оперативной памяти DDR4. Его ресурсов достаточно как для выполнения полномасштабной модели объекта в реальном времени, так и для выполнения серверных функций эмулятора верхнего уровня АСУ ТП.
Все эмуляторы были готовы в течении 6 месяцев, а далее начался длительный, но важнейший этап – опытная эксплуатация. Эмуляторы «обогащались» доработками и функциями, описаний и функций которых так не хватало в исходных данных. Но это уже привычный и неотъемлемый путь создания качественного тренажерного комплекса.
Осталась одна важная система для эмуляции – ПТК системы регулирования турбины. Всеми любимый «черный ящик». Из исходных данных есть только инструкции по эксплуатации, и то, в основном в них описано взаимодействие с операторским интерфейсом, и со всем немного про алгоритмы регулирования. Эмуляцию пришлось выполнять с помощью нашего САПР, моделировать алгоритмы. А для эмулятора HMI использовали всю ту же Java.
С какими проблемами мы сталкиваемся при отладке эмуляторов АСУ ТП
Представьте себе, что вы пытаетесь починить огромный механизм, где всё взаимосвязано, как в часах. Только эти «часы» размером с небоскрёб, и вместо шестерёнок — сотни компьютеров, труб и датчиков. Вот примерно так выглядит отладка эмулятора АСУ ТП.
Еще раз про исходные данные. Очень часто, они похожи на пазл, где половина кусочков потерялась, а оставшиеся не всегда подходят друг к другу. Бывает, что документация написана для разных версий системы, и вы пытаетесь собрать современный смартфон по инструкции от кнопочного телефона. А иногда информация просто противоречит сама себе —как если бы в инструкции к машине говорилось, что руль поворачивает направо, а педали тормозят вперёд.
А теперь представьте себе древнегреческую гидру. Помните, как только Геракл отрубал одну голову, на её месте вырастали две новые? Точно так же бывает при отладке сложных систем. Закроешь одну ошибку — всплывает другая, иногда в самом неожиданном месте. Как в старом водопроводе: заделаешь течь в одном месте, а вода находит новый путь и прорывается где-то ещё.
Сложность добавляет то, что система распределённая. Это как пытаться дирижировать оркестром, где каждый музыкант находится в отдельном здании, а связь между ними идёт через интернет. Изменишь что-то в одном месте — и непонятно, как это повлияет на всё остальное.
Особенно весело становится, когда дело доходит до систем регулирования. Они часто работают как чёрные ящики: снаружи видно только кнопки и экраны, а что происходит внутри — загадка. Разработчикам приходится быть настоящими детективами, чтобы понять логику работы системы и правильно её воспроизвести.
В общем, отладка эмулятора АСУ ТП — это как попытка собрать работающий космический корабль, используя инструкции, написанные на неизвестном языке, с кучей ошибок и пропусков. Но трудности только закаляют, верно?
Итоговое слово: когда цена оправдана
Помните знаменитую фразу из фильма: «В каждой подделке есть доля подлинности»? В нашем случае всё наоборот — чем ближе копия к оригиналу, тем больше в ней от настоящего, и тем дороже она обходится.
Годы разработки различных тренажерных программно-технических комплексов убедили меня: высокая стоимость профессиональных решений неслучайна. Точность воспроизведения реального промышленного объекта —это не просто красивая фраза в презентации, а результат колоссальной работы:
Детального анализа тысяч параметров
Воспроизведения сложных алгоритмов управления
Эмуляции поведения оборудования в разных режимах
Создания реалистичной среды для обучения
Каждый уровень детализации требует дополнительных ресурсов:
Базовая симуляция — это каркас
Средняя точность — это проработка деталей
Максимальная копия — это уже произведение инженерного искусства
Важно понимать: дорогой тренажёр — это не переплата за бренд, а инвестиция в:
Безопасность обучения
Качество подготовки персонала
Реальные навыки управления
Уверенность в действиях операторов
В конечном счёте хочу сказать, что разработка таких вот цифровых двойников — настоящее искусство. Мы создаём не просто модель, а максимально точную копию реального объекта. И чем ближе эта копия к оригиналу, тем больше жизней и единиц оборудования она сможет защитить.
