IFC как национальный формат данных:

мнение «за»

Строительную отрасль можно представить как наш мир, в котором есть много национальностей (специальностей) и стран (предприятий-участников строительных проектов). Аналогия вполне уместна, и многие читатели согласятся: иногда, кажется, что строители, проектировщики, сметчики и другие участники говорят на разных языках и не понимают друг друга. Иначе откуда возникает столько сложностей, нестыковок, переделок в ходе проектирования и строительства.

Для того чтобы передавать замысел проекта от одного участника к другому были придуманы чертежи, стандарты их оформления. Затем появились компьютеры и специальное программное обеспечение (САПР). Это сильно облегчило задачи инженерам: копирование из одного чертежа в другой и т.п. Но передача сложной инженерной информации и повторное использование этой информации — по-прежнему оставались весьма затруднительными, а проекты содержали большое количество ошибок. Пришло время информационного моделирования, создания трехмерных моделей зданий. Но и при таком подходе к работе над проектами не ушла необходимость передавать данные между разными участниками и разным программным обеспечением. Очевидно, что для такого взаимодействия не подойдут форматы, которые придумывались для чертежей или просто для трехмерных моделей.

На сцене появляется формат IFC. Из материалов сайта держателей формата можно понять, что он из себя представляет. IFC — это стандартизированное цифровое описание отрасли строительных активов. Это открытый международный стандарт (ISO 16739−1: 2018), который обеспечивает независимые от поставщика и применимые возможности для широкого спектра аппаратных устройств, программных платформ и интерфейсов для множества различных вариантов использования.

Рис. 1. Международная публичная лицензия buildingSMART (фрагмент)

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

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

Но иногда лучше пояснить на простых примерах. Так, например, стена, созданная в инструменте ArchiCAD, экспортируется в формат IFC и после импорта в Renga интерпретируется как параметрический объект «Стена». В этой стене сохраняется описание свойств (атрибутов), которые пользователь назначал в ArchiCAD. Но может быть и иначе: объект в Revit создан обобщенным семейством и при передаче в другую систему через IFC он будет воспринят как универсальный (прокси) элемент. Его хоть и нельзя будет редактировать через параметры, но зато мы получим его геометрию и свойства. А этого для многих и многих сценариев взаимодействия участников строительных проектов окажется достаточно. У IFC, как и у любого решения, есть свои плюсы и минусы. Плюсов, на мой взгляд, сильно больше и они очень весомые.

Вот некоторые положительные моменты, которые я отмечаю:

1. Больше всего привлекает открытость этого формата. Спецификация на формат доступна всем желающим применять этот формат в своей работе. Работа с форматом не требует применения каких-либо закрытых компонентов.
2. Огромная история формата и колоссальная проработанность схемы данных. Разработки формата ведутся с конца прошлого века — более двух десятков лет. А они, в свою очередь, опираются на еще более давнюю историю — разработки формата STEP. Давайте учтем количество организаций и людей со всего мира, принявших участие в развитии этих форматов, и попытаемся понять невероятность затраченных трудов. Тут хочется сказать — попробуйте сделать иной новый формат с похожим уровнем проработки!
3. Несколько сотен программных продуктов, которые поддерживают этот формат. Реализация поддержки этого формата дает возможность разработчику ПО взаимодействовать со всем этим программным обеспечением. Перечень такого программного обеспечения можно посмотреть на сайте организации BuildingSmart [1] (рис. 1). В том числе там можно увидеть разработки из России.
4. Схема допускает расширение. Это позволяет создавать национальные «надстройки» для учета потребностей в той или иной стране. Как это сделали, например, в Финляндии и Норвегии. Но делать это следует осторожно и с осознанием того, как такой модифицированный формат будет восприниматься в других странах и программных продуктах из этих стран. Хорошо бы еще с четким пониманием — зачем и поиском альтернативных решений задачи. Ну и, разумеется, учитывать, что IFC лицензирован по международной лицензии Creative Commons Attribution-NoDerivatives 4.0 [2].
5. Является национальным форматом для обмена и управления данными об объектах строительства в Российской Федерации, описан в национальном стандарте Российской Федерации ГОСТ Р 10.0.02−2019/ИСО 16739−1:2018 СИМЗС «Отраслевые базовые классы (IFC) для обмена и управления данными об объектах строительства» [3].
6. Формат является гибко настраиваемым. Он позволяет описывать геометрию и информацию объектов с помощью разных способов, поэтому для стандартизации этих способов были предусмотрены так называемые модельные представления MVD [4]. Понимая цели и задачи, можно сформировать свой вариант MVD и предлагать его для всех участников вашего проекта. Нужно только учесть способность вашего программного обеспечения учитывать такие варианты настроек и представлений. Часто слышу: выполнил экспорт в IFC и при импорте в другом софте пропали, скажем, стены. А они не пропали. Внутри IFC все на месте. Просто принимающая сторона (ПО) неспособна отобразить объект в таком представлении.

Есть еще одна особенность и вариативность — варианты формата [5]. Тут тоже следует подходить разумно и учитывать рекомендацию разработчиков. Приведу ее в оригинале и с переводом от Яндекс-переводчика: «For the widest compatibility and smallest size for file-based import and export, STEP Physical File (SPF) is recommended. For web service communication, any of the above formats may be automatically negotiated by clients and servers» («Для обеспечения максимально широкой совместимости и наименьшего размера при импорте и экспорте на основе файлов рекомендуется использовать STEP Physical File (SPF). Для взаимодействия с веб-сервисами клиенты и серверы могут автоматически согласовывать любой из вышеперечисленных форматов»).

Есть еще один важный момент, но оценить его можно по-разному: работа с форматом IFC заставляет думать над тем, что, кому и для решения какой задачи вы хотите передавать, и учитывать возможности принимающей стороны. Это кажется мне очень разумным подходом. Но это непривычно для большинства и вызывает массу вопросов у новичков при освоении темы. Тут нельзя как с чертежом — просто нажать кнопку Печать. Хотя и с печатью есть много тонкостей и настроек. Поэтому можно сказать, что это все очень сложно. Да, это непростой формат. Но и очень непростые задачи решаются с помощью него, а мы, в свою очередь, стараемся обучать этой науке всех желающих. Так, например, с учетом требований государства и выпущенных постановлений проектировщикам, заказчикам и органам экспертизы нужно уметь обращаться с форматом IFC для прохождения государственной экспертизы, и мы подсказываем, как это делать [6]. И даже формируем шаблоны проектов для упрощения жизни пользователей [7].