Information Delivery Specification (IDS) – перспективное дополнение к MVD

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

С тех пор строители не оставили попыток обойти древнее проклятие и найти подходящий способ объяснить свои ожидания от объекта строительства.

В книге «Руководство BIMcert — Базовые сведения openBIM (издание 2023 г.)» Леон ван Берло (Léon van Berlo), технический директор BuildingSMART International, и Симон Фишер (Simon Fischer), ассистент университета в области исследований цифрового строительного процесса Венского технического университета в Главе 3.7. объясняют, какие перспективы строительной отрасли даёт стандарт IDS. Рассмотрены примеры использования данного стандарта при формировании требований к автоматизированному обмену сведениями компонентов модели.

«Руководство BIMcert — Базовые сведения openBIM (издание 2023 г.)» доступно для бесплатной загрузки по адресу https://www.buildingsmart.co.at/downloads

3.7. Регламент передачи информации
3.7.1. Структура данных
3.7.2. Взаимосвязь со словарем данных buildingSmart
3.7.3. Фасет-параметры
3.7.4 Простые и составные ограничения
3.7.5. Область применения и использование IDS
3.7.6. Новые возможности с IDS
3.7.7. IDS в деталях
3.7.8. Альтернативные варианты
3.7.9. Возможности визуализации IDS
3.7.10. Взаимосвязь IDS с IFC

3.7. Регламент передачи информации

Приглашенные авторы: Леон ван Берло (Léon van Berlo) и Симон Фишер (Simon Fischer)

Information Delivery Specification (IDS) является стандартом от BuildingSMART International. Документ призван автоматизировать формирование требований к обмену моделями в таком виде, чтобы информация легко воспринималась как человеком, так и машиной. IDS - относительно молодой стандарт (2023 год), который можно назвать дополнением к MVD. Если MVD рассматривает такие фундаментальные темы, как корректное отображение иерархии классов и передачу геометрии, то IDS указывает, как наполнить модель информацией при помощи букв и цифр. Стандарт определяет, с какой информацией должен передаваться объект. По этой причине IDS является многообещающим инструментом. С одной стороны он дает заказчику возможность подготовить требования к информации, указанные в AIA. С другой – это инструмент для быстрой и эффективной проверки соответствия информации выдвинутым требованиям. Это связывает между собой требования к информации, которые в настоящее время мы имеем в виде текста с автоматизированным openBIM-процессом. IDS может применяться к двум подпроцессам:

• Определение информации: IDS выступает в роли файла конфигурации для BIM-софта, в котором создается и редактируется информационная модель. IDS используется для автоматизированного формирования требуемой структуры информации;

• Проверка информации: IDS применяется в качестве файла конфигурации для проверочного BIM-софта. Здесь IDS обеспечивает автоматизированный анализ или оценку как самой структуры информации (как организованы данные о здании), так и её содержания (какие конкретные данные о здании представлены в информационной модели).

Рабочий процесс передачи информации по стандарту IDS начинается с BIM-Менеджера заказчика. BIM-Менеджер определяет желаемый сценарий использования BIM и необходимую для этого информацию.
Давайте рассмотрим два примера требований к информации.

В первом примере заказчик хочет, чтобы все помещения в модели классифицировались определенным кодом и обладали набором свойств. Требование можно описать так.

Все помещения в модели должны:

• Классифицироваться как [AT]Zimmer (нем. Комнаты);

• Иметь информацию о Площади чистого пола и Общей площади помещения. Данные записываются соответственно в свойства NetFloorArea и GrossFloorArea как Основные величины, т.е. BaseQuanitites;

• Иметь информацию о номере комнаты, записанном в свойство AT_Zimmernummer в наборе свойств Austria_example.

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

Второй пример связан именно с областью применения. Определим требования к информации о свойствах стены:

• Все стены должны иметь информацию о том, принадлежит ли она к категории несущих. Информация записывается в свойство LoadBearing. У стены должна быть указана ее огнестойкость в свойстве FireRating.

• Оба свойства размещаются в наборе свойств, общим для всех стен, т.е. в наборе Pset_WallCommon.

• Несущие стены, т.е. со значением true для свойства LoadBearing требуют информации о своей огнестойкости, т.е. значения у свойства FireRating из следующего списка: [ND, REI 30, REI 60, REI 90, REI 120]

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

Определение требований к информации обычно выполняется с использованием инструмента для работы со структурой данных и с учетом сведений из bSDD и UCM. Затем BIM-Менеджер экспортирует требования к информации в формат IDS и предоставляет их BIM-Координатору или BIM-Автору подрядчика. Они используют IDS в качестве файла конфигурации в BIM-программах как для создания/редактирования модели, так для ее проверки. BIM-программа для проектирования автоматически создает необходимые характеристики и свойства для конкретных объектов. В проверочной BIM-программе файл конфигурации автоматически выбирает и заполняет правила проверки. После проверки файл IFC отправляется BIM-Менеджеру. Тот в свою очередь использует им же созданный файл IDS для конфигурации своего программного обеспечения и проведения проверки на своей стороне. Таким образом, IDS связывает информационные требования заказчика с BIM-моделью и позволяет автоматически проверять именно ту информацию, которая была затребована.

3.7.1. Структура данных

Формат файла IDS основан на схеме XML. Точнее, он является его стандартизированной формой. Это означает, что структура и синтаксис файла IDS определены более точно, чем для общего XML-файла. Для этого в BuildingSMART International используется формат XSD (XML Schema Definition). Он определяет, какие элементы должны и могут содержаться в файле IDS.

Файл IDS в основном состоит из двух секций: "Заголовок" и список спецификаций. Заголовок содержит общие метаданные о файле. Они собираются в элементе info. Возможная информация включает заголовок, авторское право, версию, описание, автора, дату, цель и веху. Обязательным является только название. Вся остальная информация является необязательной. Строки перед метаданными - это XML-Prolog для определения версии XML, кодировки символов и корневой элемент документа <ids ...> с определением пространств имен.

<?xml version="1.0" encoding="UTF-8"?>
<ids xmlns="http://standards.buildingsmart.org/IDS" xmlns:xsi="http://www.w3.org/ 2001/XMLSchema-instance" xsi:schemaLocation="http://standards.buildingsmart.org/IDS/ids_09.xsd">
	<info>
		<title>IDS for BIMcert</title>
		<copyright>Simon Fischer</copyright>
		<description>Created to describe IDS for BIMcert</description>
		<date>2023-01-11</date>
	</info>

За общими метаданными следует собственно содержимое файла IDS: список спецификаций. Спецификации описывают требования к информации для элементов IFC. Они структурированы таким образом, чтобы их понял и человек и машина. Спецификация состоит из трех частей: Метаданные, Область применения и Требования.

Метаданные содержатся в виде XML-атрибутов в элементе спецификации. В приведенном ниже примере это две обязательные части информации Имя (name) и IFC_Версия (ifcVersion). Кроме того, могут быть определены Необходимость (occurs), Идентификатор (identifier), Описание (description) и Инструкции (instructions). Описание и Инструкции — это варианты дополнения требований такой документацией, которую может воспринять человек. Несмотря на то, что IDS предназначены для интерпретации компьютерами, во многих случаях людям неизбежно потребуется добавить информацию в набор BIM-данных. Поэтому создатель IDS может оставить инструкции, которые дают понять, что человек также должен вводить данные.

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

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

• Entity Facet — Фасет "Сущность"

• Attribute Facet — Фасет "Атрибут"

• Classification Facet — Фасет "Классификация"

• Property Facet — Фасет "Свойство"

• Material Facet — Фасет "Материал"

• PartOf Facet — Фасет "Часть от"

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

Благодаря всем этим функциям IDS может обеспечить расширенное определение требований. Она позволяет пользователям запрашивать свойства, которые совместно используются с определенным типом мероприятий. Также имеются широкие возможности по определению ограничений для значений. Например, значение свойства может быть выбрано только из списка допустимых значений. Если значение является числом, оно может иметь определенный минимум, максимум или диапазон. Сопоставление с шаблоном также является одной из опций, доступных в IDS. Чтобы повысить надежность IDS использует XSD-ограничения. Ограничения для требований — еще один пример расширенной функции. С помощью XML-атрибутов minOccurs и maxOccurs пользователи могут определить минимальное, максимальное, диапазон или точное количество объектов, которые должны быть включены в набор данных BIM. Пользователи могут использовать фасет "PartOf" для указания принадлежности к определенной структуре в наборе данных BIM, характерной для использования Industry Foundation Classes (IFC). Такая функциональность позволяет определить требования, согласно которым объект должен быть частью сборки или частью группы.

В следующем примере показаны требования для объектов класса IfcWall в виде IDS и, для сравнения, в виде классического текста. В первом требовании указано, что у каждой стены должно быть свойство LoadBearing в Pset_WallCommon. Второе требование регламентирует возможные значения для класса огнестойкости несущих стен (список следует понимать как выборку возможных значений). Область применения обоих требований и сами требования в коде обозначены комментарием.

Спойлер

<specifications>
	<specification name="IfcWall General" ifcVersion="IFC4"> 

		
		<applicability> <!-- Область применения требований -->
			<entity>
				<name>
					<simpleValue>IFCWALL</simpleValue>
				</name>
			</entity>
		</applicability> <!-- -->
		
			
		<requirements> <!-- Tребования -->	
			<property measure="IfcBoolean">
				<propertySet>
					<simpleValue>Pset_WallCommon</simpleValue>
					</propertySet>
				<name>
					<simpleValue>LoadBearing</simpleValue>
				</name>
				</property>
			<!-- further properties -->
		</requirements> <!-- -->

		
	</specification>
	<specification name="IfcWall FireRating for LoadBearing walls" ifcVersion="IFC4">
		
		<applicability> <!-- Область применения требований -->
			<entity>
				<name>
					<simpleValue>IFCWALL</simpleValue>
				</name>
			</entity>
			<property measure="IfcBoolean">
				<propertySet>
					<simpleValue>Pset_WallCommon</simpleValue>
				</propertySet>
				<name>
					<simpleValue>LoadBearing</simpleValue>
				</name>
				<value>
					<simpleValue>true</simpleValue>
				</value>
			</property>
		</applicability> <!-- -->
		
		<requirements> <!-- Tребования -->
			<property measure="IfcLabel">
				<propertySet>
					<simpleValue>Pset_WallCommon</simpleValue>
				</propertySet>
				<name>
					<simpleValue>FireRating</simpleValue>
				</name>
				<value>
					<xs:restriction base="xs:string">
					<xs:enumeration value="ND"/>
					<xs:enumeration value="REI 30"/>
					<xs:enumeration value="REI 60"/>
					<xs:enumeration value="REI 90"/>
					<xs:enumeration value="REI 120"/>
					</xs:restriction>
				</value>
			</property>
		</requirements> <!-- -->

	</specification>
</specifications>
</ids>

3.7.2. Взаимосвязь со словарем данных buildingSmart

Когда исполнитель получает от заказчика IDS, он может сравнить свои собственные данные с требованиями, определенными в IDS. Чтобы исполнитель мог лучше понять требования, IDS может содержать доступные для чтения пояснения и инструкции. IDS позволяет добавить ссылку (как правило, Uniform Resource Identifier URI) с дополнительной информацией о свойстве или коде классификации. Именно здесь и появляется ссылка на bSDD. URI начинается с identifier.buildingsmart.org/… и ссылается на объект, который можно найти в bSDD. Если исполнитель переходит по этому URI, он получает более подробную информацию об объекте, выходящую за рамки уровня детализации, который может быть указан в IFC. bSDD содержит подробную, стандартизированную информацию об определениях, единицах измерения, взаимосвязях с другими объектами и т. д. Это относится к кодам классификации, свойствам (включая атрибуты и количества) и материалам, как для международных, так и для специфических стандартов конкретной страны. Опции для определения ограничений значений в IDS те же, что и в bSDD. Это обеспечивает беспрепятственное взаимодействие между IDS и bSDD. Добавив URI к свойству или к коду классификации (или системе), пользователи (а в некоторых случаях и компьютеры) могут получить дополнительную информацию о требованиях и типичном использовании объектов.

3.7.3. Фасет-параметры

В этом разделе рассматриваются функциональность и возможности шести фасет-параметров. Для фасетов, как и в случае со спецификациями, Необходимость (occurs) может быть указана в качестве XML-атрибута. Фасет "Property" и фасет "PartOf" также предлагают дополнительные специфические XML-атрибуты. Следующее описание содержит примеры кода для каждого фасета. Первые два раздела связаны с областью применения спецификации. Остальные разделы могут быть интегрированы в область применения или область требований спецификации аналогичным образом.

Entity Facet (Фасет "Сущность")

Фасет "Entity" относится к классам в схеме IFC. Поэтому он особенно важен для определения области применения, так как описывает класс IFC, для которого актуально выдвигаемое требование. Помимо обязательного имени класса IFC, в фасете "Entity" можно указать предопределенный тип элемента. Следующий фрагмент кода показывает использование фасета "Entity" для определения области применения спецификации для всех элементов IFC-класса IfcDoor.

<applicability>
	<entity>
		<name>
			<simpleValue>IFCDOOR</simpleValue>
		</name>
	</entity>
</applicability>

Attribute Facet (Фасет "Атрибут")

Фасет "Attribute" позволяет учитывать атрибуты, которые по умолчанию содержатся в классах IFC, например, имя элемента или GUID. Чтобы использовать фасет, необходимо указать имя атрибута; значение атрибута необязательно. Если задано только имя без значения, элемент должен содержать атрибут с именем и произвольным определенным (непустым) значением. Во фрагменте кода показано использование фасета "Attribute" для определения области действия спецификации для всех элементов IFC класса IfcDoor с именем Entry.

<applicability>
	<entity>
		<name>
			<simpleValue>IFCDOOR</simpleValue>
		</name>
	</entity>
	<attribute minOccurs="1" maxOccurs="1">
		<name>
			<simpleValue>Name</simpleValue>
		</name>
		<value>
			<simpleValue>Entry</simpleValue>
		</value>
	</attribute>
</applicability>

Classification Facet (Фасет "Классификация")

Если в дополнение к классам схемы IFC используются другие системы классификации, они могут быть учтены с помощью фасета "Classification". Такими внешними системами классификации являются, например, Uniclass2015 или национальные системы классификации. Фасет "Classification" позволяет указать вашу систему классификации и код-идентификатор (как объект классифицируется в вашей системе). Оба параметра являются необязательными. Если ни какого параметра не указано, объект должен быть классифицирован с произвольным кодом-идентификатором в произвольной системе. Кроме того, в качестве XML-атрибута элемента "Classification" может быть добавлен URI для ссылки на дополнительную информацию. Здесь показана спецификация системы Uniclass2015 с произвольным кодом-идентификатором.

<classification minOccurs="1" maxOccurs="1">
	<system>
		<simpleValue>Uniclass2015</simpleValue>
	</system>
</classification>

Property Facet (Фасет "Свойство")

Фасет "Property" является аналогом фасета "Attribute" и относится к свойствам, которые не включены в IFC по умолчанию. Он также может использоваться для указания количества. Для определения требования используются следующие параметры Property Set (Quantity Set), Property Name (Quantity Name), Value и Data Type. Здесь значение свойства тоже является необязательным параметром и ведет себя так же, как и в предыдущих фасетах. Все остальные параметры являются обязательными, при этом тип данных должен быть указан как XML-атрибут элемента «Property», а не как отдельный XML-элемент, как другие параметры. URI также может быть добавлен в качестве XML-атрибута, например, для ссылки на bSDD. В качестве примера приведена спецификация, требующая наличия свойства LoadBearing со значением true и типом данных IfcBoolean в наборе свойств Pset_WallCommon.

<property measure="IfcBoolean" minOccurs="1" maxOccurs="1">
	<propertySet>
		<simpleValue>Pset_WallCommon</simpleValue>
	</propertySet>
	<name>
		<simpleValue>LoadBearing</simpleValue>
	</name>
	<value>
		<simpleValue>true</simpleValue>
	</value>
</property>

Material Facet (Фасет "Материал")

При определении ограничений на материалы следует учитывать, что объект может состоять из одного или нескольких материалов. Фасет "Material" используется для проверки, соответствует ли один из материалов соответствующего объекта указанному материалу. В этом фасете есть только один необязательный параметр для материала. Если он не определен, то должна присутствовать любая произвольная информация о материале. URI может использоваться в качестве XML-атрибута элемента "Material" для ссылки на дополнительную информацию о материале.

<material minOccurs="1" maxOccurs="1">
	<value>
		<simpleValue> ExampleMaterial</simpleValue>
	</value>
</material>

PartOf Facet (Фасет "Часть от")

Фасет "PartOf" может использоваться для определения взаимосвязи между объектами. Отношения (Relations) определяются в IFC с помощью отдельных классов, начинающихся с IfcRel... В фасете "PartOf" Relation может быть указано через тот Relation-Класс и IFC-Класс, на который это Relation будет ссылаться. Relation должно быть указано как XML-атрибут элемента "PartOf". Одним из возможных требований является то, что элемент должен иметь отношение к определенному этажу. Для этого должно быть выбрано отношение IfcRelContainedInSpatialStructure с классом IfcBuildingStorey.

<partOf relation="IfcRelContainedInSpatialStructure" minOccurs="1" maxOccurs="1">
	<entity>
		<name>
			<simpleValue>IFCBUILDINGSTOREY</simpleValue>
		</name>
	</entity>
</partOf>

3.7.4. Простые и составные ограничения

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

Перечисление (Enumeration)

Перечисление используется для указания списка допустимых значений. Список может содержать как текстовые, так и числовые значения. Ниже приведен пример задания классов огнестойкости для несущих стен (выдержка из возможных значений).

<value>
	<xs:restriction base="xs:string">
		<xs:enumeration value="ND"/>
		<xs:enumeration value="REI 30"/>
		<xs:enumeration value="REI 60"/>
		<xs:enumeration value="REI 90"/>
		<xs:enumeration value="REI 120"/>
	</xs:restriction>
</value>

Шаблон (Pattern)

Шаблон описывает порядок, в котором различные символы могут быть соединены вместе. Эта функциональность особенно полезна при определении имен или схем наименования. Регулярные выражения (regex) являются широко распространенным методом определения таких шаблонов и также используются для IDS. В качестве примера приводится требование к наименованию помещений. [A-Z] означает, что название начинается с заглавной буквы. [0-9]{2} означает, что за ней следуют две цифры от 0 до 9.

Использования дефиса в выражении -[0-9]{2} показывает, что имя должно заканчиваться двумя цифрами от 0 до 9 после дефиса. Поэтому допустимыми именами являются, например, W01-01 или B18-74.

<value>
	<xs:restriction base="xs:string">
		<xs:pattern value="[A-Z][0-9]{2} -[0-9]{2}"/>
	</xs:restriction>
</value>

Границы (Bounds)

Границы определяют интервал допустимых значений. Можно задать либо нижнюю, либо верхнюю границу, либо обе. Границы также могут быть определены с помощью символов исключения из диапазона < / > или <= / >= для включения в него.

Длина (Length)

Наконец, можно указать длину значения, то есть количество отдельных символов. Можно указать как точную, так и минимальную или максимальную длину значения.

3.7.5. Область применения и использование IDS

Файл IDS может содержать несколько требований. Эти требования представляют собой независимые блоки и не имеют ссылок на другие требования в файле. Такая структура позволяет копировать и вставлять требования из одного файла в другой. В настоящее время (2023 год) производители программного обеспечения разрабатывают первые редакторы IDS и инструменты для создания IDS, чтобы облегчить пользователям создание файлов IDS. В будущем BuildingSMART предполагает существование библиотек IDS, в которых примеры отдельных требований будут доступны для всех. Пользователи смогут искать требования IDS и перетаскивать их в корзину для выбора, чтобы создать свой собственный файл IDS. Важным определением сферы применения IDS является то, что она фокусируется только на "Регламенте представления сведений". Это означает, что структурированные требования IDS могут определять, какая информация необходима и как она должна быть структурирована.

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

3.7.6. Новые возможности с IDS

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

3.7.7. IDS в подробностях

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

3.7.8. Альтернативные варианты

Существует множество способов определения потребности в информации. Excel кажется наиболее распространенным, но имеет свои ограничения. Другие альтернативы: Product Data Templates (PDTs), Level of Information Need (LOIN), Exchange (или Employer) Information Requirements (EIR/AIA), план выполнения BIM (BAP), mvdXML, SHACL и другие. Все эти альтернативы имеют свои преимущества и ограничения. В зависимости от конкретного случая, другие стандарты или альтернативы могут стать лучшим выбором. Сравнение, подготовленное Томчаком и др., можно найти здесь

Таблица сравнения альтернатив стандарту IDS

Методы определения требований к информации в проектах цифрового строительства по ссылке: https://www.buildingsmart.org/methods-to-specify-information-requirements-in-digital-construction-projects/

Таблица сравнения альтернатив стандарту IDS

Для большинства случаев использования openBIM IDS является рекомендуемым решением для определения требований к информации. В нем соблюдается баланс между совместимостью с IFC и bSDD, с одной стороны, и простотой использования и надежностью - с другой. Существуют различные программные инструменты для сравнения файла IFC с требованиями файла IDS. Как правило, результаты отображаются в программе просмотра. Для обмена результатами рекомендуется использовать формат BIM Collaboration Format (BCF). BCF — это структурированный метод обмена информацией об объектах IFC с партнерами по проекту.

3.7.9. Возможности визуализации IDS

В этом разделе на примере требования к информации о помещениях из введения показаны различные варианты визуализации IDS. Требование гласит: "Все данные о помещениях в модели должны быть классифицированы как [AT]Zimmer и иметь свойства NetFloorArea и GrossFloorArea (оба в наборе BaseQuanitites), а свойство AT_Zimmernummer в наборе свойств Austria_example". Форматирование этого человекочитаемого требования в IDS выглядит следующим образом:

Спойлер

<ids:ids xmlns:xs="https://www.w3.org/2001/XMLSchema" xmlns:ids=" http://standards.buildingsmart.org/IDS">
	<ids:info>
		<ids:title>Austia example</ids:title>
		<ids:copyright>buildingSMART</ids:copyright>
		<ids:version>0.0.3</ids:version>
		<ids:description>A few example checks</ids:description>
		<ids:author>[e-mail]</ids:author>
		<ids:date>2023-01-16+01:OO</ids:date>
	</ids:info>
	<ids:specifications>
		<ids:specification minOccurs="1" ifcVersion="IFC2X3 IFC4" name="Spaces">
			<ids:applicability>
				<ids:entity>
					<ids:name>
						<ids:simpleValue>IFCSPACE</ids:simpleValue>
					</ids:name>
				</ids:entity>
			</ids:applicability>
			<ids:requirements>
				<ids:classification>
					<ids:value>
						<ids:simpleValue>[AT]Zimmer</ids:simpleValue>
					</ids:value>
				</ids:classification>
				<ids:property>
					<ids:propertySet>
						<ids:simpleValue>BaseQuantities</ids:simpleValue>
					</ids:propertySet>
					<ids:name>
						<ids:simpleValue>GrossFloorArea</ids:simpleValue>
					</ids:name>
				</ids:property>
				<ids:property>
					<ids:propertySet>
						<ids:simpleValue>BaseQuantities</ids:simpleValue>
					</ids:propertySet>
					<ids:name>
						<ids:simpleValue>NetFloorArea</ids:simpleValue>
					</ids:name>
				</ids:property>
				<ids:property url="https://identifier.buildingsmart.org/url/example/prop/zimmernummer">
					<ids:propertySet>
						<ids:simpleValue>Austria_example</ids:simpleValue>
					</ids:propertySet>
					<ids:name>
						<ids:simpleValue>AT_Zimmernummer</ids:simpleValue>
					</ids:name>
				</ids:property>
			</ids:requirements>
		</ids:specification>
	</ids:specifications>
</ids:ids>

На изображении показан другой способ визуализации этого XML. Здесь вы видите ту же информацию, но в виде таблицы. Это очень общий вид, который можно применить ко всем XML-файлам.

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

3.7.10. Взаимосвязь IDS с IFC

Хотя IDS можно использовать в строительной отрасли для требований к любому типу данных, лучше всего он работает с данными, структурированными в соответствии со стандартом IFC (Industry Foundation Classes). Как видно из примера с определением требования к помещению (в строке спецификации), эта спецификация требует, чтобы в модели присутствовал хотя бы один такой объект. В ней также указано, что это требование применимо как к IFC2×3, так и к IFC4. Область действия этой IDS также определяет IFCSPACE. Это сущность IFC. Хотя спецификация может использоваться для данных, не относящихся к IFC, IDS отдает предпочтение спецификациям, основанным на IFC. Это также можно увидеть в существовании различия между атрибутами и свойствами, а также в фасете «PartOf».