Открытые и закрытые форматы данных в САПР, СОД, СУИД/СУпрИД

Александр Тучков,
к.т.н., технический директор ГК «САПР-Петербург»

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

Многообразие САПР

В настоящее время волей­неволей складывается понимание, что не может быть единого инструмента САПР, который закрывает все необходимые требования самых разнообразных специалистов: конструкторов, проектировщиков, дизайнеров и прочих пользователей.

Позволю себе обозначить как минимум несколько типов САПР, очень существенно различающихся по требованиям и принципам их создания:

• САПР общего назначения, с одной стороны, средства создания двумерной графической документации, с другой — платформы, на базе которых создаются специализированные САПР. Примеры: AutoCAD, MicroStation, nanoCAD, КОМПАС­График и др.;
• Машиностроительный САПР — интуитивно понятно без объяснений. Примеры: Autodesk Inventor, SOLIDWORKS, КОМПАС­3D, T­FLEX CAD и пр.;
• Архитектурно­строительные САПР, они же САПР ПГС, они же САПР AEC — Autodesk REVIT, ArchiCAD, RENGA и линейка САПР на базе nanoCAD (nanoCAD BIM Конструкции, например);
• САПР проектирования инфраструктуры и землеустройства — Autodesk Civil 3D, КРЕДО, nanoCAD GeoniCS и ряд других;
• так называемые PlantDesign, САПР технологических и промышленных установок: PDS, PDMS, Smart­>3D, E3D, AutoPlant, PlantLinker, Model Studo CS и др.

Мы никак не претендуем на полноту этого списка. Думаю, сразу можно привести еще несколько названий — например САПР металлоконструкций.

Итак, мы осознали, что проектируем в разных САПР, и поняли, что эти САПР имеют абсолютно разные форматы представления документации и трехмерных моделей. Появилось даже название для этих разнообразных форматов — «нативные» форматы. В подавляющем большинстве случаев это закрытые форматы, принадлежащие производителю той или иной САПР («проприетарные» форматы).

«Аутентичные» форматы

Но проектировщик и конструктор должен представить заказчику, монтажнику, строителю, заводу­производителю электронную документацию и трехмерные модели желательно в едином формате.

Исторически возник термин «аутентичные» форматы, то есть форматы, которые, с одной стороны, точно соответствуют документам, порожденным САПР, с другой — могут быть прочитаны, проанализированы и распечатаны без использования исходной САПР. В первую очередь таким стандартом «де факто» стал формат PDF. Отметим, кстати, что этот формат обеспечивает представление не только графических, но и текстовых, табличных и сканированных документов.

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

В машиностроении и других промышленных отраслях стандартом «де факто» стал формат STEP. Он поддерживается всеми машиностроительными САПР и огромным количеством вьюверов. Но, к сожалению, этот формат имеет очень много вариантов, иногда не полностью совместимых.

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

Обращаю ваше внимание, что:

• и STEP, и IFC являются ОТКРЫТЫМИ форматами, спецификации которых определяются стандартами ISO 10303, ISO 10303­21 и ISO 10303­28;
• и STEP, и IFC сегодня не используются как «нативные» форматы. Это означает, что в большинстве САПР эти модели можно загрузить только в качестве «референсных» моделей, то есть как модели, недоступные для редактирования;
• сегодня такие модели и передаются субподрядчикам, заказчикам и другим партнерским организациям с целью их просмотра и изучения БЕЗ возможности их изменения и без использования исходных САПР;
• в реальной жизни оказалась очень востребованной функция «сборки» нескольких моделей в «комплексную» модель. Например, сборка модели здания по следующим дисциплинам: строительные конструкции, оборудование, различные инженерные сети. Именно IFC и STEP прекрасно решают эту задачу.

Подведем на этом этапе промежуточные итоги:

• мы имеем «нативные» форматы, которые содержат результаты проектирования в самых разных САПР. Модели и документы в этих форматах могут в большинстве случаев редактироваться только этими же или родственными САПР. Последнее в основном касается САПР на основе формата DWG;
• мы имеем «аутентичные» форматы фактически для любых документов (графических, текстовых, табличных, сканированных), редактирование которых в большинстве случаев запрещено (иногда юридически);
• мы имеем плохо стандартизированные форматы STEP и IFC для представления трехмерных моделей самых разных изделий и объектов. Фактически модели в этих форматах играют роль «аутентичных» моделей для передачи партнерским организациям, субподрядчикам, заказчикам и любым пользователям, не имеющим доступ к необходимой САПР.

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

Пример чертежа, используемого в системах электронного архива и документооборота

Электронные архивы и среда общих данных

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

• люди, участвующие в процессе проектирования, но не работающие с САПР: главные конструкторы, ГИПы, начальники отделов и их помощники, сметчики, технические писатели и т.д., и т.п.
• люди, не участвующие в процессе проектирования, но участвующие во внешних процессах: заказчики, эксперты, технологи, строители, сотрудники МТО.

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

Далее появилась «среда общих данных» (СОД) обеспечивающая совместную работу как над документами традиционно в «аутентичных» форматах, так зачастую и в «нативных» форматах, а потом и с моделями. Электронный архив в облаках!

Машиностроение оказалось впереди и создало системы PDM/PLM, но фактически все они связаны с конкретными САПР конкретного производителя, а результаты работы других САПР понимают через формат STEP или как документы в форматах DWG и PDF.

В архитектурно­строительной области появилась технология BIM и вполне справедливо восторжествовал формат IFC. Появились комплексные модели, сохраненные в IFC из разных САПР для различных специальностей (дисциплин). Технология СОД с удовольствием «проглотила» технологию IFC и начала дальше расширяться в сторону управления строительством и эксплуатацией.

Особенности отрасли PlantDesign

А вот передовые САПР в области PlantDesign пошли по пути создания трехмерных моделей сложных промышленных и технологических установок на основе объектного моделирования их в структурах баз данных. При этом все проектировщики могут одновременно работать с этой базой данных. И оказалось, что «нативный» формат исчез, превратившись в дамп базы данных, которая содержит модель установки, а то и нескольких. Автоматизированная генерация чертежей из моделей превратилась в отдельную проектную специальность, как, впрочем, и генерация табличной документации (спецификации, ведомости и т.п.). Но тут проблем не возникло — к этому все уже привыкли: DWG, DOC, XLS и, конечно, вездесущий PDF.

Пример сложной технологической установки

Тут же выяснилось, что все хотят иметь доступ к трехмерным моделям, не имея этих сложных и дорогих САПР. Сначала каждый уважающий себя вендор создал свой формат для просмотра (.DWF, .NWD, .VUE, .RVT и т.д.). Но такой подход можно себе позволить в рамках одной проектной компании, работающей на одной САПР. Количество используемых вьюверов этих форматов в серьезной проектной компании должно раза в три­четыре превышать количество САПР. Кстати, большинство этих форматов «проприетарны», то есть закрыты.

Сегодня для создания комплексных моделей предлагается использовать те самые открытые форматы STEP и IFC. В строительной отрасли при проектировании, строительстве и эксплуатации этот подход в настоящее время развивается семимильными шагами.

Но в отрасли PlantDesign для строительства и эксплуатации сложных промышленных и технологических объектов объем IFC­файлов, содержащих модели установок, оказался устрашающим. Одна установка в формате IFC сегодня занимает от 20 до 90 Гбайт. Большинство распространенных вьюверов IFC на таких объемах либо «падают», либо начинают работать очень медленно: медленно загружают, медленно масштабируются и позиционируются. Кроме того, при визуализации IFC в тонких клиентах (WEB­клиентах) начинают действовать ограничения на объемы, с которыми работают браузеры.

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

Тут важно вместе с водой не выплеснуть ребенка. Мы совсем недавно договорились о работе в открытых форматах, и тут же пытаемся уйти с этого пути. Мы абсолютно уверены, что хранимый формат должен быть «открытым». Поменяются СУИД, СОД, электронные архивы, вьюверы и операционные системы, но информация во всех случаях должна быть доступной! Сегодня мы видим, как развиваются эти процессы в рамках импортозамещения.

Попробуем резюмировать, что мы имеем сегодня:

• есть «нативные» («проприетарные») форматы моделей и документов, и для дальнейшего развития и модернизации спроектированных изделий и объектов мы ОБЯЗАТЕЛЬНО вынуждены их хранить. Иногда это просто .DWG­файлы, а иногда — дампы огромных баз данных;
• существуют стандартизированные «открытые» форматы для документации, ставшие стандартом «де факто», — это PDF и «условно открытый» DWG;
• и есть плохо стандартизированные, но открытые форматы для визуализации трехмерных моделей машиностроительных изделий (STEP), трехмерных моделей строительных объектов (IFC). Эти форматы в названных отраслях тоже стали стандартом «де факто»;
• а вот в отрасли PlantDesign востребованы оба этих формата (STEP — для моделей оборудования, IFC — для моделей строительных и технологических конструкций). И, несмотря на трудности (объемы), сегодня это самое разумное направление визуализации сложных моделей.

СУИД — Система управления инженерными данными

Относительно недавно, во втором десятилетии 21­го века, становится востребована концепция Систем управления инженерными данными (СУИД), ориентированная в первую очередь на организации, владеющие и эксплуатирующие сложные технические объекты (атомные и тепловые станции, нефтеперерабатывающие и газоперерабатывающие заводы, химические заводы, металлургия). Одними из основных видов контента, хранящихся в СУИД, считаются инженерная документация и трехмерные модели сложных объектов.

Концептуальная схема информации, содержащейся в СУИД

Опять­таки с инженерной документацией проблем нет: DWG, DOC, XLS и PDF. Для хранения трехмерных моделей сложных изделий и объектов наиболее подходят STEP и IFC. Именно эти форматы обеспечат преемственность данных (и сохранение инвестиций) при развитии всех рассматриваемых программных компонентов. А развитие неизбежно — и как общемировая тенденция, и как тенденция импортозамещения в России. И сохранить накопленные сегодня огромные объемы данных становится стратегической задачей.

Проблемы усугубляются тем, что мы создаем СУИД, которые теоретически должны эксплуатироваться десятилетиями — ровно столько, сколько эксплуатируются сложные промышленные и технологические установки. То есть к моменту вывода из эксплуатации объекта, построенного вчера, не будет актуальных сегодня операционных систем, СУБД, компьютеров и серверов. Мы сегодня должны закладывать решения, которые обеспечат доступ к информации через десятилетия.

В таких условиях использование открытых форматов — единственный разумный выход.

Философские рассуждения о развитии «нативных» форматов

Процесс передачи «нативных» форматов от одного пользователя к другим может быть очень сложным. Даже простейшая передача DWG­файлов наталкивается на требование мапирования шрифтов, текстур и ряд проблем с версиями. А современные многопользовательские САПР (Smart­>3D, например) фактически требуют передачи дампа базы данных, на которой велось проектирование, а то и просто виртуальной машины, на которой исполнялся проект.

Сегодня мы вынуждены хранить «нативные» форматы в электронных архивах, СОД, СУИД, PDM/PLM, а иногда, когда это невозможно, и просто в файловых системах.

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

Сегодня такая технология применяется в САПР PlantLinker и как «нативный» (но открытый) формат для хранения моделей, и как формат для обмена моделями с САПР Smart­>3D, Tekla Structure, AVEVA E3D, и для обмена строительными конструкциями с Autodesk REVIT. В дальнейшем планируется использовать этот формат для публикации моделей и структур сложных инженерных объектов в СУИД Плант­Навигатор.

Мы надеемся, что рассматриваемый подход завоюет свое место как минимум в трех отраслях: PlantDesign (нефте­ и газопереработка, атомная и тепловая энергетика, металлургия, химическое производство и т.п.), судостроение (в части насыщения судов, кораблей и морских объектов) и промышленное и гражданское строительство (ПГС).

Выводы

Мир приходит к очевидному (на сегодняшний момент) решению по разработке и использованию открытых форматов: конкурентоспособность САПР, СОД, ТДО, СУИД, PDM/PLM и других инструментальных средств в значительной мере будет определяться возможностями генерации и обработки информации в открытых форматах.

Ориентация на открытые форматы, разработка новых инструментальных средств и создание прикладных решений на их основе делает относительно безболезненными процедуры миграции с одних систем на другие, а также внедрение новых видов систем (о которых мы сейчас даже не имеем представления). Уже сегодня информация, концентрируемая в СУИД, необходима огромному количеству систем: технический документооборот, материально­техническое снабжение, техническое обслуживание и ремонт оборудования, системы управления предприятием и финансовые системы, тренажеры обслуживающего персонала, системы МЧС.

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

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