Продолжаем рассказ о разработке компьютерного тренажерного комплекса (КТК). Если вы пропустили начало: Часть первая: Модель >
Современное ПО предоставляет удобную визуальную объектно-ориентированную среду для разработки моделей (см. рисунок 1). При первом взгляде на неё у неподготовленного зрителя может возникнуть ложное ощущение, что разработка тренажёра – это перерисовка технологических схем: выбирай нужные элементы и рисуй связи. Конечно, это только часть работы. Чтобы сформировать более полную картину, далее я ознакомлю вас с некоторыми вопросами и сложностями разработки КТК.
Рисунок 1.
1. Определение объёма моделирования.
Выделите самые существенные части технологического процесса (ТП), которые нужны для целей обучения. Можно исходить из специализации обучаемого. Если он – машинист компрессорного зала, то необходимо включить все вспомогательные системы и компрессор. Если обучаемый - оператор ТП, то вспомогательные системы нужно выключить из объёма и оставить только сам компрессор.
Как и везде, надо искать золотую середину, потому что существует соблазн упростить объём моделирования до одной технологической линии, убрать всю вспомогательную арматуру и арматуру по месту, резервирование насосов. Но, построив модель таким образом, мы не дадим обучающемуся человеку степеней свободы для вывода установки из непредвиденных обстоятельств: переключиться на второй насос, подать поток по байпасу и т.п.
Критерий завершённости:
В завершении этого этапа будут определены:
2. Получение данных от Клиента.
Самый существенный ограничивающий фактор в моделировании – неполнота и противоречивость исходных данных. Если какие-то данные можно получить сравнительно легко (геометрические размеры оборудования и его расположение в пространстве), то другие – затруднительно (данные модернизации ТП), а некоторые практически невозможно (энергии активации участвующих в процессе реакций).
Также сложно получить качественно-количественное описание динамического поведения исследуемого объекта. Опытный оператор может предсказать поведение установки в большом диапазоне наблюдаемых параметров процесса, но не в экстремальных условиях. Возможно, за всё время его многолетней работы таких ситуаций и вовсе не было. Опять же субъективная оценка причин и последствий аварии снижает адекватность модели.
В итоге, настраивается и моделируется так называемый «нормальный режим». Это режим, находящийся в пределах технологических норм, – один из реальных режимов работы установки. Но обучение стажёров происходит в других условиях – пограничных, приближенных к боевым (аварии, поломки, неправильные действия обучаемого). Таким образом, адекватность модели технологическому процессу может гарантироваться и оцениваться только в узком диапазоне всевозможных вариантов протекания ТП.
Следует понимать, что данный этап непрерывен на всём жизненном цикле проекта. С Клиентом на протяжении всего процесса разработки поддерживается связь, уточняются и дополняются характеристики процесса. Но для начала работ по созданию тренажёра нужен обязательный минимум данных:
3. Выбор термодинамического пакета и оптимального количества компонентов. Определение допущений моделирования.
Для большинства процессов нефтепереработки подходит модель Пенг-Робинсона (уравнение состояния термодинамического равновесия), учитывающая неидеальность взаимодействий внутри многокомпонентной смеси, но для некоторых процессов используются специализированные пакеты. Выбор правильного пакета избавит от неожиданностей и переделок модели в процессе разработки. Количество компонентов должно быть, с одной стороны таким, чтобы не исчерпать вычислительные ресурсы компьютера до предела, с другой стороны, чтобы модель точно описывала основные характеристики моделируемого объекта.
Под допущениями моделирования понимается степень детализации модели. Стоит ли моделировать датчики загазованности? Достаточно ли арматуры по месту? Учёт ограничений используемого симулятора: неадекватность показаний датчиков, нестабильность расчёта термодинамического состояния, производительность и т.п.
Материально-тепловой баланс сходится. Создана статическая модель процесса.
4. Сборка визуальной схемы, задание характеристик моделируемых объектов.
На данном этапе инженерами проекта моделируются составные блоки (секции) объекта в динамике, в соответствии с соглашением об интеграции в единую модель.
В вырожденном случае, при небольшом объёме моделирования, модель создаётся сразу одним блоком.
Заданы все характеристики объектов. Смоделирован весь КИПиА. Смоделирован весь ТП. Каждый отдельный блок процесса находится в нормальном режиме.
5. Интеграция модели.
Объединяем результаты усилий всех инженеров, и модель становится единым целым. Если производительности ЭВМ не хватает, то оптимизируем количество расчетных частей модели, точки соединения, параметры связи частей модели (сигнальные, оптимальная модель передачи состояния).
Достигнута необходимая производительность. Определено количество составных частей модели. Процесс ведёт себя стабильно. Получен нормальный режим. Строго говоря, этап интеграции моделей на МАТ (тестирование мат. модели) необязателен, также как и наличие всего объёма КИПиА, но очень желателен.
6. Тестирование и отладка.
Самый ресурсоёмкий этап в разработке. В силу перечисленных выше ограничений самого подхода к моделированию (дискретизация состава, дискретизация непрерывного процесса и ограниченное описание его динамики набором статических точек, ограничения ПО, и т.д.) и недостаточности данных от Клиента, этот этап играет ключевую роль в процессе создания модели. Занимает в 3-4 раза больше времени, чем все предыдущие шаги.
7. Интеграция с РСУ и ПАЗ.
При эмуляции РСУ или ПАЗ возникает проблема неточности воспроизведения реальных алгоритмов, которая требует методичного тестирования каждого алгоритма, что занимает много времени. Данный вопрос решается симуляцией РСУ и ПАЗ с использованием реальной базы данных (БД) конфигурации. Но при этом возникают другие сложности: БД передаётся в неактуальном состоянии и в момент сдачи КТК алгоритмы, заложенные в КТК, отличаются от таковых на реальном объекте. Также отмечу проблемы связи модели с РСУ: ненастроенное управление на объекте, разная степень инерционности объектов реального мира и математической модели.
Все датчики процесса «живут». КТК полностью управляется с интерфейсов оператора и полевого оператора. Алгоритмы РСУ и ПАЗ повторяют поведение алгоритмов на объекте.
Подводя итог, хотелось бы обратить ваше внимание на то, что в процессе реализации КТК полностью инспектируются все алгоритмы (в том числе РСУ и ПАЗ), что позволяет диагностировать неточности управления на реальном объекте. К сожалению, часто эта работа пропадает впустую. При должной заинтересованности эти данные можно эффективно использовать не только для разработки качественного тренажерного комплекса, но также для отладки алгоритмов и настройки рабочей системы.