Формирование единой цифровой среды для передачи данных ТИМ-моделей – одна из самых непростых задач, которая встает перед профессиональным сообществом уже сейчас. Ряд экспертов и чиновников заявляют о необходимости формирования отечественного открытого формата обмена данными, чтобы исключить возможную утечку информации – но это колоссальные затраты времени и средств. 

При этом в мире давно существует необходимый документ – это международный стандарт IFC, который мог бы стать основой для формирования национального стандарта. Кто прав?

Сегодня мы предоставляем слово профессору, доктору физико-математических наук, зав. отделом системной интеграции и прикладных программных комплексов Института системного программирования им.В.П.Иванникова РАН Виталию Семенову, который разработал Манифест национального стандарта «Открытый формат обмена ТИМ данными»:

— Манифест появился в результате участия автора в мероприятиях, прекрасно организованных и проведенных НОТИМ в 2021 году, и последующего анализа ситуации, сложившейся в области ТИМ-технологий применительно к строительной отрасли России.

Конгресс «ТИМ-СООБЩЕСТВО-2021», который послужил площадкой для выступления большого числа делегатов и представления широкого спектра позиций, выявил невероятно высокую популярность концепции “Common Data Environment”, которая определяется соответствующим стандартом ISO 19650 и следование которой декларировалось практически каждым делегатом. Это показалось автору особенно удивительным, поскольку стандарт определяет самые общие принципы организации систем управления документами и контроля версий, которым исполнилось уже почти полвека, и применение которых не требует никаких особых навыков и усилий. Обменом документами на Яндекс-диске и ведением проектной деятельности на гитхабе успешно владеют старшеклассники непрофильных школ, даже не догадываясь о существовании данного стандарта. Очевидно, что внедрение стандарта ровным счетом ничего не меняет в давно сложившемся технологическом укладе и не решает ключевых проблем цифровой трансформации отрасли. По-видимому, главное предназначение стандарта ISO 19650 состоит в определении типовых организационных мероприятий и рабочих процессов документооборота, которые могут быть содержательны для строительной отрасли.

К ключевым проблемам цифровизации отрасли следует отнести переход к управлению структурированными данными, которые могли бы интерпретироваться и обрабатываться специализированными приложениями, входящими в состав развитых экосистем программного обеспечения ТИМ. Под структурированными здесь понимаются данные, представленные в соответствии с открытой концептуальной и формальной информационной схемой (иногда называемой моделью данных, иногда — онтологией). Для архитектурно-строительной и смежных отраслей подобную информационную схему предоставляет стандарт ISO 16739 (Industry Foundation Classes).

Примечательно, что структуризация данных и централизация управления являются главными тенденциями развития ТИМ, которые одинаково квалифицируются и в популярной модели зрелости Бью-Ричардса (BIM Level 0-3) и в более профессиональной модели Шуккара (BIM Stage 0-4). При этом документооборот в обеих моделях соответствует самым ранним этапам BIM Level 1 и BIM Stage 1 соответственно. Заметим, что в ISO 19650 и русском переводе допущена ошибка относительно BIM Level 2, поскольку принципиально невозможна федеративная организация неструктурированных и полу-структурированных данных, а коллективная работа является необходимым, но не достаточным условием подобной квалификации.

Поскольку технологии документооборота успешно применялись и будут применяться там, где имеется необходимая для этого мотивация, а централизованное управление структурированными ТИМ-данными привносит качественно новые возможности в строительную отрасль, перспективной представляется ГАРМОНИЗАЦИЯ стандартов ISO 19650 (CDE) и ISO 16739 (IFC). Концепцией подобной гармонизации и управления существенно неоднородными ТИМ данными в настоящее время успешно занимается коллектив ИСП РАН.

Легенды и мифы IFC

Вопросам перехода к управлению структурированными ТИМ-данными и национальному аналогу международного стандарта IFC было посвящено специальное совещание НОТИМ, проведенное в Министерстве строительства РФ. Сама тема совещания предполагала, что есть весомые причины не использовать IFC, однако выступления и вопросы коллег выявили проблемы иного рода. 

Одна из проблем — это поверхностное владение стандартом и связанные с этим недоразумения (хотя международный стандарт IFC развивается с 1997 года, а в 2018 году он был принят в РФ в качестве государственного). Среди распространенных домыслов и разночтений следует указать следующие:

• “Формат IFC устарел” 
• “IFC небезопасен”
• “IFC использует старую методологию STEP”
• “Мы не можем влиять на развитие IFC”
• “IFC сложный”
• “IFC содержит серые места”
• “IFC нерасширяем”
• “IFC интероперабельный, но не операбельный”
• “IFC данные разбухают”
• “IFC не подходит для инфраструктурных проектов”

Чтобы не превратить предисловие к Манифесту в самостоятельное эссе, ограничимся краткими пояснениями и комментариями.

“Формат IFC устарел?”

Прежде всего, IFC — это не файловый формат, а концептуальная информационная схема архитектурно-строительной и смежных отраслей, формально специфицированная на языке объектно-ориентированного моделирования данных EXPRESS. Данные, определяемые IFC схемой, могут представляться разными форматами, например, STEP physical file (SPF), XML, JSON, RDF, и храниться под управлением реляционных и объектно-ориентированных СУБД. В настоящее время наиболее распространены файлы IFC SPF.

Концептуальная схема IFC продолжает стремительно развиваться, и тезис об устаревании является явно надуманным. Заинтересованные читатели могут обратиться к видео-презентации пленарного доклада Dr. Thomas Liebich “OpenBIM. Quarter Centure Development and Perspectives of the IFC standard”, который был сделан на Европейской конференции по информационному моделированию продуктов и процессов в области архитектуры и строительства (ЕСРРМ 2021), организованной ИСП РАН и МГСУ в сентябре 2021 года (https://ecppm.ispras.ru).

“IFC небезопасен?”

Открытая спецификация схемы IFC, как и текстовые файлы с данными, определяемые схемой, являются, конечно, абсолютно безопасными. Заметим, что это не исполняемые коды и программы, которые подлежат соответствующей сертификации из-за возможных уязвимостей, закладок, вирусов и т.п.
“IFC использует старую методологию STEP?”

Стандарт IFC действительно наследует методологию STEP, хотя бы в силу тех обстоятельств, что информационная схема IFC специфицирована на языке EXPRESS, а в качестве одного из файловых форматов для представления и хранения данных используется SPF. 

International Organization for Standardization. ISO 10303-11: Industrial automation systems and integration – Product data representation and exchange – Part 11: Description methods: The EXPRESS language reference manual. Geneva, Switzerland. 2016.

International Organization for Standartization. ISO 10303-21: Industrial automation systems and integration – Product data representation and exchange – Part 21: Implementation methods: Clear text encoding of the exchange structure. Geneva, Switzerland. 2016. 

Однако главное в STEP — это методология метамоделирования, которая успешно применяется в самых современных технологиях программной инженерии, включая Model-Driven Architecture (MDA), Domain-Specific Languages (DSL), Model-Driven Development (MDD). Именно этим обстоятельством объясняется наличие огромного количества программных приложений, реализующих IFC схему на разных языках и платформах разработки.

“Мы не можем влиять на развитие IFC?”

Стандарт IFC развивается международным консорциумом buildingSMART, в работу которого вовлечены сотни профильных организаций и компаний из разных стран. Предложения по развитию стандарта проходят необходимые фазы валидации и принимаются в результате консенсуса. Безусловно, мы можем и должны влиять на развитие стандарта IFC! Для этого необходимо проводить НИОКР, апробировать результаты на международных конференциях и BIM-форумах, публиковать успешные результаты в ведущих иностранных изданиях и, наконец, формулировать конструктивные предложения, которые могли бы быть интересны и поддержаны членами консорциума.

“IFC сложный?”

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

“IFC содержит серые места?”

Данный тезис допускает самые разные толкования, но, видимо, речь идет об альтернативных представлениях данных в рамках одной формальной схемы. Например, IFC определяет супермножество типов данных для представления разнообразных геометрических моделей, используемых в системах автоматизированного проектирования. При этом формальная схема допускает, что в качестве геометрического представления строительного элемента может быть указана и граничная, и твердотельная, и скелетная, и габаритная модель. Поскольку каждая конкретная система не обязана поддерживать работу со всеми типами данных, предусмотренными IFC схемой, при файловом обмене это обстоятельство следует учитывать и уточнять, какие именно данные предполагается передать. При сертификации IFC-совместимых систем подмножество поддерживаемых типов данных декларируется с помощью MVD (Model View Definition) запроса.

“IFC нерасширяем?”

IFC схема определяет фиксированный набор типов данных и семантических правил для них. В ходе эволюции схемы этот набор неизбежно расширяется. Приведенная Таблица 1 убедительно иллюстрирует этот процесс. Однако важной особенностью IFC схемы является наличие обобщенных типов данных, благодаря которым могут быть определены пользовательские классы объектов, их свойства и отношения. Тем самым, в рамках фиксированной формальной схемы удается поддерживать самые разнообразные пользовательские типы данных. Понятно, что их семантика должна определяться дополнительными соглашениями, если предполагается не только файловая передача и хранение данных, но их интерпретация и содержательная обработка разными приложениями. Благодаря данной возможности удается, в частности, удовлетворить национальным требованиям, которые обычно предполагают задание специфичных для каждой страны дополнительных атрибутивных данных.

Таблица 1. Эволюция стандарта ISO 16739 (IFC)

IFC СХЕМА (год принятия)	1.5.1  (1997)	2.0  (1999)	2.1  (2000)	2.2  (2003)	2.3.0.1  (2007)	4.0  (2013)	4.0.2.1  (2017)	4.1  (2018)
ENTITIES	186	290	370	623	653	766	776	801
TYPES	95	157	228	312	327	391	397	400
DERIVED	44	45	41	55	57	59	62	62
FUNCTIONS	25	27	25	37	38	42	47	47
ENTITY RULES	107	168	195	271	338	639	652	658
TYPE RULES	12	12	13	16	24	24	25	25
UNIQUE RULES	1	3	14	14	17	4	4	4
GLOBAL RULES	0	0	3	3	2	2	2	2

“IFC интероперабельный, но не операбельный?”

Довольно веселый парафраз, но понятие интероперабельности имеет вполне серьезную основу, которая предполагает семь следующих уровней: не интероперабельный, технический, синтаксический, семантический, прагматический, динамический и концептуальный. Обеспечение интероперабельности на каждом следующем уровне сопряжено с применением соответствующих технологических решений. Надлежащая реализация функций экспорта/импорта IFC SPF файлов обеспечивает интероперабельность на семантическом уровне, а практика поддержки данного формата ведущими мировыми вендорами убедительно доказывает работоспособность данного подхода.

“IFC данные разбухают?”

IFC данные типового проекта в формате SPF обычно занимают на диске от 50Mb до 1Gb, что не является проблемой для современных устройств внешней памяти. Как известно, при работе со структурированными данными требования к объему основной памяти существенно возрастают. Именно этим объясняется использование универсальных или специализированных СУБД в индустриальных 3D CAD системах. В этом отношении работа с большими IFC данными не является исключением. Однако в наше время работа с большими данными является типовой задачей, решение которой хорошо известно широкому кругу IT специалистов.

“IFC не подходит для инфраструктурных проектов?”

Схемы IFC 4.1, IFC 4.2, IFC 4.3 включают расширения стандартной схемы IFC 4, необходимые для инфраструктурных проектов, таких как автомобильные дороги, мосты, туннели, железные дороги, порты и акватории. IFC 4.3 имеет статус релиз кандидата, который предзнаменует выпуск официального стандарта и скорую поддержку мировыми вендорами.

Примечательно, что работы по расширению IFC для телекоммуникационных систем на железных дорогах ведутся международным консорциумом профильных компаний Италии (RFI), Франции (FNRC), Австрии (ÖBB), Швейцарии (SBB), Финляндии (FTIA), Швеции (Trafikverket) и Китая (CRBIM). К сожалению, РЖД никак не представлено в консорциуме, несмотря на железнодорожное сообщение и с европейскими странами и с Китаем. Видео-презентацию проекта, тезисы доклада и текст статьи A. Dsoul, S. Karoui, J.D. Adounvo, P.E. Gautier, J.G. Philibert, C. Carpinteri, L. Lihai, L.Yifan & M. Boutros “Digital description of the railway telecommunication system for a new data exchange format” можно найти на сайте упомянутой выше конференции.

***
Другая проблема, которая обсуждалась на совещании в Минстрое России и которая вызывает многочисленные вопросы, — это разработка национального аналога стандарта IFC и его поддержка профильными российскими организациями и компаниями. Поскольку подобная деятельность требует колоссальных интеллектуальных усилий и значительных финансовых затрат, и при этом несет риски повторить непростой 25-летний путь консорциума buildingSMART (который был учрежден как International Alliance for Interoperability), было бы правильно вначале сформулировать цели, которые должны быть достигнуты, определить задачи и наметить пути к их решению.

Представленный МАНИФЕСТ НАЦИОНАЛЬНОГО СТАНДАРТА представляет собой попытку сформулировать цели разработки стандарта, перечислить функциональные и реализационные требования к открытому формату обмена ТИМ данными, представить и проанализировать возможные подходы к его разработке и имплементации. Публикация документа имеет целью привлечь внимание ТИМ сообщества к данной проблеме, а также собрать и систематизировать экспертные оценки и предложения в рамках НОТИМ.

Полный текст Манифеста Национального стандарта доступен по ссылке.

Фото https://pixabay.com/ru/