Реализация принципов BIM для проектирования комплексных технологических процессов на примере ПО «PROMPROEKTOR»

Введение

Привычные нам проекты в области технологии производств обычно представляют собой некую комбинацию из графической составляющей и документации, не имеющие общей базы. Чертежи и документы проекта формируются отдельно друг от друга, что зачастую приводит к высокому проценту ошибок разработчика при переносе данных. Не говоря уже о количестве ресурсов необходимых для формирования документации. ПО «PROMPROEKTOR» – это принципиально новый подход к разработке проектной документации.

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

Ссылка на видео: https://rutube.ru/video/private/c99796fd74eff7d1412c94c01d766718/?p=CE6BNOMmZriQuHkTyA0d-w.

ПО «PROMPROEKTOR» – это информационная модель, с помощью которой можно получить полный набор проектной документации. Основной функционал «PROMPROEKTOR» был реализован на базе платформы nanoCAD с помощью ее нативных инструментов.

Следующим этапом эволюции ПО «PROMPROEKTOR» стал переход к API MultiCAD и его тесная интеграция с уже разработанным функционалом параметрических объектов, производства СиСофт Омск.

Переход на MultiCAD поспособствовал формированию фундаментальной цели – созданию информационной модели процесса.

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

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

Чтобы перейти к описанию фундаментальных принципов, заложенных в архитектуре ПО «PROMPROEKTOR», введем ключевые понятия.

Терминология

Класс – формальное описание типа объектов, определяющее их структуру данных (атрибуты) и поведение (методы). Например, абстрактное понятие «Аппарат» является классом.

Экземпляр объекта (Объект) – конкретная реализация класса, размещенная на чертеже. Например, аппарат «Емкость сырьевого бензина Р-101» – это экземпляр класса «Аппарат». Обладает собственными значениями атрибутов.

Модель – совокупность взаимосвязанных экземпляров объектов, описывающая часть или всю систему.

Основная часть

Фундаментальным принципом, который реализуется в ПО «PROMPROEKTOR» является принцип «Единственного источника истины» (Single Source of Truth). Любые данные вводятся в модель один раз на соответствующем уровне, после чего автоматически наследуются всеми экземплярами объектов зависимых классов. Это исключает дублирование, противоречия и ручной перенос данных, что выводит процесс создания проектной документации на качественно новый уровень.

Объектная архитектура системы

Основой информационной модели являются «Объекты». На рисунке ниже представлена объектная модель ПО «PROMPROEKTOR» (Рисунок 1).

Архитектура ПО «PROMPROEKTOR» состоит из трех взаимосвязанных логических блоков, отражающих суть технологического процесса:

· Модель аппарата.

· Модель трубопровода.

· Модель АСУТП.

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

Модель аппарата

Базовым состоянием модели аппарата является простой объект, состоящий из одного экземпляра объекта класса «Аппарат» (Рисунок 2).

Примером простого объекта может служить емкостное оборудование (далее – ёмкость), т.к. расчётные параметры на практике по всей ёмкости принимаются одинаковыми.

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

В продвинутом состоянии аппарат является составным объектом, который обладает возможностью связывания с такими же экземплярами класса «аппарат» технологической схемы. Составной аппарат применим, когда внутри одного технологического агрегата параметры существенно изменяются, одним из ярких примеров является трубчатая печь. Модель печи может быть представлена несколькими экземплярами класса «Аппарат», связанными между собой и олицетворяющими секции (радиантную, конвекционную, камеру дожига). Количество секций при этом не ограничено.

Модель трубопровода

Модель трубопровода наследует принципы модели аппарата, но является более комплексной, так как требует сепарации данных по признаку принадлежности к технологической и монтажной частям (Рисунок 4).

Модель разделена на две основные части:

1. База технологических данных («Менеджер трубопроводов») являющаяся источником технической информации о технологических параметрах трубопровода (контейнер данных для технологической части проектной документации) (Рисунок 5).

2. Экземпляры класса «Участок трубопровода», являющиеся визуальным воплощением трубопровода на монтажной схеме (контейнер данных для монтажной части проектной документации) (Рисунок 6).

Каждый участок наследует технологические данные из общей базы.

Технологическая часть данных находится в базе данных, которая является общей базой для всех экземпляров класса «участок трубопровода».

Поведение экземпляров класса «Участок трубопровода» принципиально не отличается от поведения экземпляров класса «Аппарат». За исключением того, что экземпляр класса «Аппарат» сам себе является контейнером собственных технологических параметров, а экземпляры класса «Участок трубопровода» получают исходную технологическую информацию из общего источника («Менеджер трубопроводов»).

Решение о разделении технологических и монтажных данных в модели трубопровода продиктовано тем, что количество трубопроводов на технологической схеме как правило много больше, чем количество аппаратов.

Централизованное управление технологическими параметрами через «Менеджер трубопроводов» позволяет вносить изменения для целых групп участков трубопроводов без необходимости правки каждого объекта вручную.

Модель АСУТП

Это наиболее комплексная часть системы, реализующая многоуровневую иерархию объектов управления.

Модель АСУТП является самой комплексной из всех представленных, так как включает в себя набор из пяти объектов, которые олицетворяют собой разные уровни реализации системы управления технологическим процессом в проектной документации (Рисунок 8).

Полевой уровень. Представлен классом «Первичный КИП». Экземпляры класса «Первичный КИП» связываются непосредственно с экземплярами классов «Аппарат» и «Участок трубопровода» с одновременным наследованием необходимых технологических данных. «Первичный КИП» может реализовывать собой как функцию измерительного прибор (датчик давления PT), так и функцию исполнительного механизма (задвижка с электроприводом) (Рисунок 7).

Уровень функции. Представлен классом «Функция КИПиА». Экземпляры класса «Функция КИПиА» связываются непосредственно с экземплярами класса «Первичный КИП» и олицетворяют собой обработку сигнала от прибора внутри системы АСУТП (индикация, регистрация, преобразование). При этом, «Функция КИПиА» непосредственно не реализует функцию управления исполнительными механизмами автоматического действия (Рисунок 7).

Логический уровень. На логическом уровне осуществляется управление исполнительными механизмами по факту срабатывания «триггера». «Триггер» – это дискретный сигнал, исходящий от измерительного прибора по факту срабатывания «Уставка». «Уставка» – это инициатор защитного действия, выполняемого исполнительным механизмом. Логический уровень реализуется объектами трех классов: «блокировка», «сигнал состояния» и «сигнал управления» (Рисунок 9).

«Блокировка» используется для комплексного описания контуров противоаварийной защиты (ПАЗ) непрерывных технологических процессов.

Объектная модель реализует автоматическое формирование описаний контуров блокировок.

Заключение

Представленный подход в ПО «PROMPROEKTOR» предлагает целостное решение для проектирования сложных технологических объектов. Перенося фокус с 3D-геометрии на технологическую схему как на «единый источник истины», система обеспечивает:

1. сквозную согласованность данных,

2. автоматизирует рутинные задачи и минимизирует ошибки.

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

Кроме основного направления работы ПО «PROMPROEKTOR» – формирования проектной документации на основе информационной модели реализован ряд дополнительных функциональных модулей:

1. Модуль для проверки таблиц на предмет несогласованности с интегрированным ИИ.

2. Модуль для расчета свойств простых веществ и их смесей.

На стадии разработки находится еще один модуль – для расчета свойств псевдокомпонентов.

Таким образом, ПО «PROMPROEKTOR» позволяет следующий ряд задач в области проектирования химической технологии:

1. Разработка проектной документации (стадия П);

2. Разработка рабочей документации (стадия Р);

3. Разработка проектной документации для технического перевооружения опасных производственных объектов.

Философия ПО «PROMPROEKTOR» берет за основу правило внутренней согласованности и логичности архитектуры. Разработчики ПО «PROMPROEKTOR» максимально придерживаются этого правила, т.к. следование логике всегда вознаграждается результатами, которые невозможно было предугадать на первоначальном этапе и таким образом программа становится даже лучше, чем она была задумана.