Дисклеймер

Вообще-то, дисклеймер означает отказ от ответственности, но я, как автор, конечно, не отказываюсь от ответственности за качество контента, просто хочу предупредить, что, не считая себя экспертом в теме, всё же решаюсь писать о ней, потому что для меня это самый работающий способ получения знаний. Через изучение, обобщение и изложение я узнаю предмет.

Поводом к написанию этой статьи стал анализ кастдевов с пользователями Tangl, где снова появилась тема поддержки стандарта IDS в Tangl control. Я решила разобраться с перспективами и ограничениями спецификации IDS для автоматической проверки BIM-моделей на основе правил.

Что такое IDS

В двух словах, спецификация IDS (Information Delivery Specification) была предложена консорциумом buildingSMART в качестве перспективного подхода к определению требований к информации в рамках рабочих процессов BIM. Как и в случае с другими стандартами от bSI, это не конкретные требования к информации, разумеется, а стандартизированная схема того, как описывать эти требования так, чтобы описание могло быть понятно любому софту для проверки BIM-моделей.

То есть если раньше BIM-координаторы вручную переносили требования из традиционных для выпуска EIR человекочитаемых форматов типа PDF в свои инструменты для проверки BIM-моделей, таких как Navisworks, Solibri, Tangl control, то теперь появляется альтернативный путь – сразу выдавать требования к элементам модели и в машиночитаемом формате тоже, чтобы как минимум автоматизировать и ускорить проверки и исключить обидные ручные ошибки из-за человеческого фактора.

На текущий момент (май 2025 года) актуальной версией стандарта IDS является версия 1.0 и в ней определено шесть типов фасетов (facets), которые используются для описания требований к информационному наполнению BIM-моделей. Я приведу их здесь, чтобы можно было прямо сейчас не переключаться, но вообще вся подробная информация по спецификации есть здесь, в документации на сайте buildingSMART. Или если предпочитаете читать на русском, то вот хорошая статья Information Delivery Specification (IDS) – перспективное дополнение к MVD пользователя @Ryzhov_Roman. 

• Entity определяет принадлежность объекта к классу IFC, к которому применяется требование (например, IfcWall, IfcDoor).

• Attribute относится к встроенным атрибутам и их значениям, таким как Name, Description и другие.

• Property относится пользовательским свойствам, определённым в наборах свойств (Psets), например, Pset_WallCommon.FireRating.

• Classification указывает на применённые классификаторы, например, по системам UniClass, OmniClass и т.д.

• Material указывает на наличие материалов, связанных с объектом, например, бетон, сталь, дерево и т.д.

• partOf указывает на иерархические или составные связи между объектами, например, что элемент является частью группы или сборки.

С учётом этого, можно довольно чётко определить те BIM-сценарии, в которых он будет хорошо работать, и те, где текущих возможностей стандарта IDS не хватит.

Сценарии, где IDS наиболее полезен

В этой части рассмотрены ключевые BIM-сценарии (BIM-uses), в которых применение IDS приносит наибольшую пользу.

Проверка полноты и правильности атрибутов

Один из самых прямых сценариев – убедиться, что во всех элементах модели заполнены необходимые свойства и атрибуты, и они имеют корректные значения. Например, в требованиях ТИМ-Стандарта, утверждённом в 2024 году Министерством строительства и развития инфраструктуры Свердловской области, в разделе 4.1 Раздел Архитектурные решения приводится требование, что у элементов “Стена” и “Перегородка” должны присутствовать обязательные параметры Предел огнестойкости и Тип противопожарной преграды и они должны быть значениями из списка допустимых (например, REI_60, EI_30 для первого атрибута, или 0, 1, 2 для второго). 

Ещё пример – опубликованные Центром госэкспертизы Санкт-Петербурга машиночитаемые требования к цифровым информационным моделям.

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

Контроль использования классификаций и кодов

IDS поддерживает требования по классификации элементов. Например, заказчик может потребовать, чтобы все помещения были классифицированы по определённой системе (UniClass, OmniClass, и др.) с указанием соответствующего кода классификатора. В IDS это описывается через фасет "Classification", где задаётся система и требуемый код или диапазон кодов. Проверка IDS покажет, какие элементы не имеют нужной классификационной записи. Таким образом достигается единообразие данных для последующих задач – например, количественных расчётов или смет, где важно, чтобы каждому элементу был присвоен правильный код классификатора.

Проверка соответствия модели требованиям этапа проекта (LOI)

В разных стадиях проекта требуется различный уровень детализации и состава данных. IDS позволяет явно зафиксировать, какой минимальный набор информации должен быть в модели на каждой вехе. Например, для стадии эскизного проекта можно задать один IDS с базовыми требованиями (общие размеры, типы элементов, основные свойства), а для стадии П – более расширенный IDS (добавляются свойства маркировки, спецификаций материалов, и т.п.)​ При приближении сдачи модели создаётся самый подробный IDS (например, включающий COBie параметры для эксплуатации здания). Такой подход гарантирует, что на каждом этапе жизненного цикла модель соответствует ожиданиям: проектировщики видят, какие данные от них требуются на текущей стадии, и могут заранее подготовить модель к проверке. К примеру, IDS может контролировать заполненность свойств, связанных с этапом – статус элемента (новый/существующий), стадию готовности, номер ревизии и прочее, то есть всё, что регламентирует стадийность модели. 

Координация междисциплинарных моделей и передача заказчику

В задачах междисциплинарной координации,когда несколько команд обмениваются моделями (архитекторы, конструкторы, инженеры), IDS помогает формализовать требования к обмену данными. Например, BIM-менеджер может выпустить IDS-файл с перечнем информации, которую каждая дисциплина должна предоставить в своей IFC-модели (атрибуты авторства, дата обновления, нужные свойства для оборудования, ссылки на стандарты и т.д.). Затем при обмене моделями участники могут автоматически проверить полученный IFC-файл на соответствие этому IDS.

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

Обеспечение данных для последующих BIM-задач

Многие последующие этапы работы с моделью (4D/5D-планирование, расчёт энергоэффективности, эксплуатация здания) требуют, чтобы в модели были необходимые исходные сведения. IDS позволяет ещё на этапе подготовки модели заложить эти требования. Например, для энергетического анализа можно через IDS потребовать, чтобы у всех помещений были указаны температуры, категории пространства и др. Для получения детальных ведомостей объёмов работ, допустим, с разбивкой по этажам или секциям, нужно убедиться, что у элементов моделей заполнены параметры местоположения “Этаж” и “Секция”.

IDS на этапах жизненного цикла проекта

На этапах жизненного цикла проекта применение спецификации IDS наиболее полезно на следующих стадиях:

Стадия проектирования

В начале проектирования IDS применяется для явного определения требований заказчика к модели. Проектировщики получают машиночитаемые инструкции, какие свойства и данные включать в модель. Это снижает неопределённость и позволяет с самого начала заложить нужные атрибуты. 

В ходе работы над проектом файл IDS может быть подключён в САПР/BIM ПО для разработки модели (через плагины или встроенные средства), чтобы автор модели в реальном времени контролировал соответствие вводимых данных требованиям​. Таким образом, уже при создании BIM-модели может быть обеспечено её соответствие будущим проверкам. Например, для нормативных проверок минимальных площадей помещений, высоты этажей, ширины дверных проёмов и т.п. нужны будут определённые параметры для отбора элементов для проверку.

Стадия координации и междисциплинарной проверки 

Во время совмещения моделей разных разделов IDS полезен для автоматического контроля качества (QA/QC) информации. BIM-координатор может проверить каждую объединённую модель на соответствие своему разделу IDS-требований: например, убедиться, что конструктивная модель содержит все марки металлопроката, инженерная – наименование оборудования и систем, архитектурная – классификацию помещений и т.д. 

Междисциплинарная проверка подразумевает поиск и анализ коллизий, а параметры элементов нужны для создания соответствующих наборов. 

Инструменты автоматической проверки помогут найти элементы, не удовлетворяющие требованиям, создавая отчёт с замечаниями по ним​. Это значительно ускоряет процесс согласования моделей между участниками и делает его объективным. Вместо вручную составленных отчётов по качеству данных – объективный протокол, где видно, какие пункты выполнены, а какие нет.

Стадия сдачи модели, передача заказчику или в эксплуатацию

Перед финальной передачей модели заказчику, например, BIM-модель как результат проекта для эксплуатации здания, IDS оказывается критически полезным для процесса приёмки модели. Формируется итоговый IDS, охватывающий все информационные требования заказчика (атрибуты инвентаризации, серийные номера, коды помещений, сроки установки, вплоть до требований стандарта COBie, если нужно). Далее выполняется проверка модели на соответствие IDS без длинных ручных чек-листов и результат сразу покажет элементы, где эти поля пустые. 

На этапе сдачи такая проверка повышает уверенность обеих сторон: и исполнитель, и заказчик могут легко удостовериться, что модель отвечает всем заявленным критериям качества данных. Теоретически, спецификация IDS может быть включена прямо в ТЗ и тогда модель не будет считаться принятой, пока автоматическая проверка на базе открытого стандарта IDS не покажет 100% соответствие. 

Подводя итог этим двум главам, можно сделать вывод, что IDS приносит наибольшую пользу там, где требуется чётко определить и автоматически проконтролировать состав информации в BIM-модели. Это касается большинства BIM-сценариев, связанных с информационным наполнением модели – от проверки свойств и классификаций до приёмки BIM-модели по информационным требованиям (EIR). Использование IDS особенно эффективно на критических точках жизненного цикла (разработка, координация,сдача), обеспечивая преемственность требований.

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

Сценарии, где IDS не применим или малополезен

Существует целый ряд задач проверок качества BIM-моделей, которые не могут быть решены с помощью IDS, исходя из его структуры, целей и текущих ограничений. Ниже перечислены такие сценарии и объеяснение, почему IDS в них не подходит:

Поиск коллизий

IDS не оперирует геометрией, поэтому не может обнаруживать пересечения или зазоры между элементами. Правило вида "перекрытие трубы и балки не допускается" не выразить с помощью схемы IDS. Для этого нужны специализированные инструменты и алгоритмы анализа геометрии, имеющиеся, например, в Navisworks или Tangl control). В IDS 1.0 прямо указано, что он "не имеет возможности задавать детали геометрии". Таким образом, любые проверки, требующие расчёта пересечений, расстояний или анализа формы объектов, находятся за рамками IDS.

Проверка пространственных отношений и топологии

Если требуется проверить, что объекты расположены определённым образом (например, оборудование находится внутри нужного помещения, задан минимальный просвет между ограждениями, сухие помещения не находятся под мокрыми), IDS не может напрямую задать такие правила. Он может потребовать наличие связи, фасет PartOf позволяет указать, что элемент должен быть включён в другой элемент, однако, требования по геометрическому расположению, например, находится ли стена физически внутри границ этажа, или что пожарный гидрант расположен на расстоянии не более 30 м от выходов, в IDS не определить. Для пространственных проверок нужны геометрические вычисления и контекстная логика, которые есть, например, в комплексных проверках Tangl control. Но пока это определяется правилами вне IDS​.

Визуальный контроль модели 

Некоторые аспекты качества модели проверяются вручную или визуально – соответствие архитектурной концепции, эстетические моменты, понятность моделей и чертежей. Очевидно, что IDS не заменяет экспертизу человека и не предназначен для субъективных критериев. Также IDS не проверит корректность оформления чертёжей, наличия нужных планов, правильности цвета или текстуры материалов в рендеринге и т.п., иными словами, всё, что выходит за область структурированных данных IFC. 

Проверка геометрии и LOD (уровня детализации модели)

Хотя IDS может косвенно влиять на уровень информационного наполнения (LOI), он не описывает геометрическую детализацию (LOD) элементов. Нельзя задать через IDS, что "элемент должен содержать хотя бы 100 полигонов" или "труба должна быть смоделирована как сплошной цилиндр, а не как отрезок линии". Если стоит задача проконтролировать, что на определённой стадии модели геометрия упрощена или усложнена до нужного уровня, IDS не поможет, т.к. он не оперирует метриками формы. 

В buildingSMART обсуждали возможность включения в IDS требований к типам представлений (геометрическим репрезентациям), например, чтобы объект имел твердотельное представление (Breps) или осевое, но признали, что это пока не реализовано​. Обсуждение здесь forums.buildingsmart.org. К тому же такие требования рискованны: они могут противоречить самой спецификации IFC или быть сложными для выполнения в САПР-системах. Поэтому контроль LOD/LOG (уровня проработки графики) пока остаётся за пределами текущего IDS.

Сложные составные правила и зависимости между элементами 

IDS-файл состоит из отдельных требований, не связанных напрямую друг с другом, что означает, что IDS не умеет выражать условия типа "Если A и B, то C". Например, нельзя одним требованием IDS описать правило вида: "каждому помещению должны соответствовать двери, причём количество дверей ≥ 1". IDS-проверка не суммирует данные по разным объектам и не делает выводов – она лишь проверяет каждый заявленный критерий по отдельности на элементах, к которым он применим. Поэтому агрегированные правила (учитывающие сразу множество объектов или зависимость между разными объектами) с помощью IDS не задаются. Не получится проверить долю остекления фасада, соотношение общей и жилой площади помещений, соответствие размеров оборудования габаритам шахты и т.п. – всё, что требует одновременного анализа нескольких элементов или глобальных показателей модели. 

Подводя итог, в целом можно говорить, что ограничения IDS вытекают из его концепции: это не инструмент проверки всех аспектов модели, а именно стандарт спецификации информационных требований. В официальном описании подчеркивается, что IDS не предназначен для описания требований к проектному решению и сложных правил, а сфокусирован только на передаче сведений​. 

В тех случаях, где необходим анализ формы, положения, количества или взаимного соответствия элементов, нужны другие подходы. Альтернативами могут быть проверки с помощью скриптов Dynamo, конструктор правил в Solibri, комплексные проверки в Tangl control, старый формат mvdXML (который позволял некоторые логические проверки, но сложен).

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

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

Перспективы развития спецификации IDS

Стандарт IDS – относительно новый (версия 1.0 официально утверждена год назад в июне 2024​), и его функциональность активно развивается сообществом buildingSMART. На данный момент IDS решает основной круг задач (информационные требования без геометрии), но уже обсуждаются направления расширения возможностей в будущих версиях.

Дорожная карта развития

Согласно официальным заявлениям, планируется выпустить версию IDS 1.1 с небольшими исправлениями и уточнениями по результатам первых внедрений, а в более отдаленной перспективе – IDS 2.0 с расширением функционала​. Версия 1.1, судя по всему, будет ориентирована на улучшение стабильности и соглашений между разработчиками ПО, т.е. чтобы все инструменты единообразно поддерживали стандарт. А вот в IDS 2.0 могут появиться более заметные новшества. Пока нет превью версии 2.0, но из обсуждений следует, что рассматриваются улучшения в области задания правил и зависимостей. Например, buildingSMART упоминает, что область правил (Conditions) может быть либо уточнена, либо расширена в следующих версиях. Иными словами, есть понимание, что пользователям нужны более сложные требования, условные, зависящие от контекста, и рабочая группа IDS собирает обратную связь, как лучше их реализовать.

Обсуждения в сообществе

Команда разработки IDS открыта для предложений: на официальном GitHub-репозитории можно создать issue с идеей или проблемой, также функционирует IDS Working Group, куда приглашаются желающие внести вклад. На форумах buildingSMART тоже периодически возникают темы по развитию IDS. К примеру, обсуждался вопрос включения в IDS требований к геометрическому представлению объектов – нужно ли позволить задавать, каким образом объект моделируется (IfcProductDefinitionShape) в плане типов геометрии. То есть поддержка геометрических аспектов не исключается в принципе, просто требует аккуратного подхода, чтобы не противоречить IFC и не усложнить жизнь проектировщикам. Вероятно, сначала добавят возможность контролировать типы геометрических элементов, например, что поверхность – твёрдое тело.

Также в сообществе поднимаются вопросы увязки IDS с другими стандартами. Часто обсуждается интеграция с bSDD (buildingSMART Data Dictionary), уже сейчас IDS позволяет ссылаться на словари для определения допустимых свойств и значений через GUID из bSDD. В будущем, возможно, эта связка станет плотнее: например, чтобы IDS мог автоматически подтягивать из bSDD актуальные требования к объектам конкретного типа или даже проверять семантические соответствия. 

Сертификация ПО

В перспективе обсуждается введение сертификации ПО на поддержку спецификации IDS. За год с момента утверждения спецификации сформировался список программных продуктов, разработчики которых декларируют работу с IDS.

Однако (и вот это уже настоящий дисклеймер) сам консорциум buildingSMART в данный момент не занимается проверкой сведений, предоставляемых производителями ПО о своём функционале. То есть, строго говоря, этот список не является списком сертифицированных инструментов. Хотя практика ведения реестра сертифицированного ПО для работы, например, с IFC, у buildingSMART есть, так что появление подобного списка по IDS вполне реально.

Поддержка IDS в BIM-инструментах

Поддержка открытой спецификации IDS проявляется в различных формах и зависит от назначения инструмента – от модулей для чтения и валидации IDS до средств создания IDS-файлов и интеграции их в BIM-платформы.

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

Плюс сам подход openBIM с открытостью спецификации IDS, когда грамотный спец берёт библиотеку ifcopenshell с открытым исходным кодом для языка python, предоставляющую возможность чтения, записи и редактирования данных IFC, и пишет собственное приложение для проверки модели, способствует тому, что всё больше участников рынка будут внедрять поддержку IDS. 

Важно, что buildingSMART сам предоставляет инструменты для поддержки стандарта. Помимо упомянутой библиотеки ifcopenshell, есть официальный IDS Audit Tool для проверки IDS-файлов на соответствие стандарту (свободно доступен на GitHub)​. Это полезно разработчикам IDS-редакторов, чтобы убедиться, что сгенерированный файл корректен и будет читаться другими приложениями. По сути, уже формируется полноценная инфраструктура: схема XSD, тест-наборы, reference-реализации валидаторов.

Заключение

Краткие выводы для тех, кто сразу прокрутил до конца статьи: 

• IDS полезен для автоматизации контроля атрибутов и классификаций, а также для формализации информационных требований на разных стадиях проекта.

• IDS не предназначен для анализа коллизий, геометрии, сложных зависимостей между элементами, визуальных проверок и т.д.

• Перспективы развития: стандарт в фазе активного развития, возможны расширения в части логики и поддержки геометрических аспектов, но коллизии и пространственные проверки вряд ли станут частью IDS.

• Поддержка со стороны ПО уже достаточно широка: Solibri, BIMcollab, BIMVision, Archicad, плагины для Revit и др. Все ведущие BIM-инструменты либо имеют, либо внедряют модули IDS.

К 2025 году IDS уже поддерживается в ряде ключевых BIM-средств, прежде всего для целей автоматической проверки моделей и управления требованиями. Есть выбор как коммерческих, так и бесплатных решений для создания IDS (редакторы) и для валидации IFC (плагины, сервисы). Интеграция IDS в BIM-процессы становится реальностью: от этапа постановки требований (BIM-менеджер формирует IDS) через этап моделирования (проектировщик видит требования в своей среде для разработки моделей) до этапа проверки (координатор запускает IDS-чекер и выпускает отчёт). 

При этом нужно понимать, что IDS закрывает лишь часть требований к BIM-моделям, и поддержка этой спецификации – важный, но не главный критерий при выборе ПО для проверки качества BIM-проекта.