ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

Система стандартов информационного моделирования зданий и сооружений

ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ

Справочник по обмену информацией

Часть 2

Структура взаимодействия

(ISO 29481-2:2012,

Building information models — Information delivery manual — Part 2: Interaction framework,

IDT)

Издание официальное

Москва

Стандартинформ

2019

Предисловие

1    ПОДГОТОВЛЕН Ассоциацией организаций по развитию технологий информационного моделирования в строительстве и ЖКХ (БИМ-Ассоциация) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2    ВНЕСЕН Проектным техническим комитетом по стандартизации ПТК 705 «Технологии информационного моделирования на всех этапах жизненного цикла обьектов капитального строительства и недвижимости»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 5 июня 2019 г. № 280-ст

4    Настоящий стандарт идентичен международному стандарту ИСО 29481-2:2012 «Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 2. Структура взаимодействия» (ISO 29481-2:2012 «Building information models — Information delivery manual — Part 2: Interaction framework», IDT).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правипа применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. №162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© ISO. 2012 — Все права сохраняются © Стандартинформ, оформление. 2019

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

-    структура взаимодействия (XML),

-    схема структуры взаимодействия (XSD),

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

На выходе получаем схему взаимодействия в виде XSD-файла.

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

В приложении В описываются шаблоны, содержащиеся в XSD-файле.

В приложении D описываются принципы работы промотора.

Рисунок 6 — Схема поддержки программных решений

4.8.4    Поддержка обмена информацией

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

4.8.5    Техническая реализация обмена информацией

Чтобы обеспечить техническую сторону обмена сообщениями с вложениями между информационными системами, должны быть предусмотрены указания по его реализации. Они должны охватывать следующее:

-    протокол обмена информацией.

-    архитектуру/сервер обмена информацией.

-    шифрование.

-    вызов SOAP-функции.

Указания по реализации не входят в область рассмотрения настоящего стандарта.

5 Формат структуры взаимодействия

5.1    Введение

Как указано в разделе 4, для поддержки программных решений каждая структура взаимодействия должна соответствовать схеме структуры взаимодействия. Этот раздел определяет формат структуры взаимодействия посредством описания схемы структуры взаимодействия.

В подразделе 5.2 представлен обзор классов информации, которые могут встречаться в структуре взаимодействия и определены в схеме структуры взаимодействия. Поскольку структура взаимодействия определена в XML. используется термин «тип», а не «класс». В приложении А приведено полное описание схемы структуры взаимодействия. В приложении В приведен пример экземпляра структуры взаимодействия.

5.2    Типы информации в схеме структуры взаимодействия

5.2.1    Введение

Схема заполняется рядом классов или типов. В этом разделе приводится краткое описание доступных типов в схеме структуры взаимодействия. В приложении А содержится полное описание схемы структуры взаимодействия в XML. Структура взаимодействия создается из экземпляров этих типов и имеет заголовок, который указывает на схему с определенными доступными типами.

5.2.2    AppendixType

AppendixType — это определение, которое определяет структуру элементов, относящихся к метаданным. Экземпляр AppendixType используется для определения определенных типов файлов или документов, которые могут быть частью отправляемых/получаемых сообщений. Структура элементов, связанных с экземпляром AppendixType. представляет определенные метаданные, которые необходимы для определенного типа файла или документа.

5.2.3    ComplexElementType

ComplexElementType содержит набор SimpleElementTypes. Каиздый тип SimpleElementType встречается ровно столько раз. сколько встречается элемент, к которому он относится.

5.2.4    ElementCondition

Экземпляр ElementCondition описывает поведение значений элементов в последовательности сообщений. Например, когда экземпляр типа ElementCondition создается со значением FIXED, это указывает на то. что элементы в последовательности сообщений должны копироваться в случаях, когда доступен один и тот же элемент и его значение не может быть изменено. ElementCondition может ссылаться на различные уровни в структуре. Он может быть напрямую связан с SimpleElement, но также можно связать ElementCondition с ComplexElement или MessagelnTransactionType. В этом случае ElementCondition является действительным для всех элементов, которые являются частью структуры/ набора элементов связанных типов.

5.2.5    GroupType

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

5.2.6    Message Туре

Тип MessageType используется для определения содержимого сообщения. Элементы, которые являются частью сообщения, в свою очередь группируются в один или несколько экземпляров ComplexElementType.

5.2.7    MessagelnTransactionType

MessagelnTransactionType (MITT) представляет собой определение, используемое для связывания экземпляров типа MessageType с экземплярами типа TransactionType. Проще говоря, один и тот же тип сообщения может встречаться в данном типе транзакции чаще, чем один раз. и наоборот. Можно связать несколько экземпляров MessageType с одним экземпляром TransactionType и один экземпляр MessageType с несколькими экземплярами TransactionType. Кроме того. MITT дает возможность изменить направление действия от исполнителя к инициатору. Также он предусматривает возможность отслеживания того, блокируется ли поток сообщений открытыми вторичными транзакциями или нет.

5.2.8    OrganisationType

Определение конкретной группы организаций. В общем случае в структуре доступен как минимум один экземпляр с конкретной причиной для определения структуры элементов организации.

5.2.9    PersonType

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

5.2.10    ProjectType

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

5.2.11    RoleType

Определение роли. Экземпляры типа RoleType необходимы для создания TransactionType в структуре.

5.2.12    SimpleElementType

SimpleElementType — это определение, описывающее свойства, которые могут встречаться в структурах объектов. Связь с объектом всегда устанавливается через ComplexElementType.

5.2.13    TransactionPhaseType

Определение, которое может использоваться для определения экземпляра, описывающего этап транзакции. Например, экземпляр TransactionPhaseType может соответствовать этапам «запрошен результат» или «в ожидании».

5.2.14    TransactionType

Определение транзакции. В экземпляре транзакции определяются роли инициатора и исполнителя.

5.2.15    userDefinedType

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

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

Приложение А (обязательное)

Определение схемы структуры взаимодействия

А.1 Введение

Структура взаимодействия должна соответствовать правилам, которые включены в схему структуры взаимодействия В настоящем приложении определение схемы структуры взаимодействия приводится в формате EXPRESS и в формате XSD Кроме того, приведены описания типов элементов, атрибутов, элементов и ссылок Для каждого объекта в схеме взаимодействия требуются дата начала и дата окончания Это позволяет включать временные ограничения в срок действия конкретного объекта

А.2 Определение схемы структуры взаимодействия (формат EXPRESS)¹)

SCHEMA ISO 29481_Part_2A.

ENTITY ProjectType, — Определение конкретной группы проектов Обычно в структуре взаимодействия будет присутствовать только один экземпляр, определяющий структуру элементов, которые будут предоставляться в каждом экземпляре проекта namespace STRING; description STRING; startDate DATETIME. endDate DATETIME; state: STRING. dateLaMu: DATETIME; userLaMu: STRING; language OPTIONAL STRING, category OPTIONAL STRING; helplnfo OPTIONAL STRING, code: OPTIONAL STRING;

complexElements: OPTIONAL SET (0:?) OF ComplexElementType.

END_ENTITY.

ENTITY PersonType. — Определение конкретной группы лиц Обычно в структуре взаимодействия будет присутствовать только один экземпляр, определяющий структуру элементов, которые будут предоставляться в каждом экземпляре лица descnption STRING; startDate: DATETIME; endDate DATETIME; state STRING; dateLaMu DATETIME. userLaMu: STRING; language: OPTIONAL STRING; category OPTIONAL STRING; helplnfo OPTIONAL STRING, code: OPTIONAL STRING;

complexElements OPTIONAL SET (0:?) OF ComplexElementType.

END_ENTITY,

ENTITY OrganisationType; — Определение конкретной группы организаций Обычно в структуре взаимодействия присутствует только один экземпляр, определяющий структуру элементов, которые должны предоставляться в каждом экземпляре организации description STRING; startDate DATETIME. endDate: DATETIME; state STRING; dateLaMu DATETIME; userLaMu: STRING, language OPTIONAL STRING, category OPTIONAL STRING; helplnfo: OPTIONAL STRING;

В настоящем стандарте приводится полное описание схемы структуры взаимодействия, представленное в ИСО 29481-2 2012

code: OPTIONAL STRING:

complexElements OPTIONAL SET [0 ?] OF ComplexElementType.

END_ENTITY;

ENTITY AppendixType: — AppendixType содержит определение дополнения Какие элементы данных должны записываться с помощью дополнения, можно указать в разделе составного элемента descnption STRING, startDate: DATETIME; endDate: DATETIME, state STRING. dateLaMu DATETIME, userLaMu: STRING: language OPTIONAL STRING, category OPTIONAL STRING, helplnfo OPTIONAL STRING, code: OPTIONAL STRING;

complexElements OPTIONAL SET (0 ?] OF ComplexElementType,

END_ENTITY;

ENTITY ComplexElementType; — ComplexElementType содержит набор SimpleElementTypes Каждый заявленный тип SimpleElementType входит ровно столько раз. сколько он упоминается description: STRING, startDate: DATETIME; endDate DATETIME, state: STRING. dateLaMu: DATETIME. userLaMu: STRING; language OPTIONAL STRING, category OPTIONAL STRING, helplnfo OPTIONAL STRING;

complexElements OPTIONAL SET [0 ?] OF ComplexElementType; simpleElements OPTIONAL SET [0:?] OF SimpleElementType;

END_ENTITY;

ENTITY MessageType; — Определение типа сообщения (MessageType), которое указывает структуру сообщения и какой набор типов SimpleElementType (через ComplexElementType) оно может сопровождать descnption: STRING; startDate: DATETIME; endDate DATETIME, state: STRING. dateLaMu: DATETIME. userLaMu STRING; language OPTIONAL STRING, category OPTIONAL STRING, helplnfo OPTIONAL STRING, code: OPTIONAL STRING,

complexElements OPTIONAL SET [0 ?] OF ComplexElementType, appendixTypes: OPTIONAL SET (1:?) OF AppendixType;

END_ENTITY;

ENTiTY ElementCondition. — Условие SimpleElementType в том виде, как оно используется в конкретном MessageType

descnption: STRING;

condition STRING;

helplnfo: OPTIONAL STRING:

complexElement OPTIONAL ComplexElementType.

simpleElement OPTIONAL SimpleElementType.

messagelnTransaction OPTIONAL MessagelnTransactionType;

END_ENTITY;

ENTITY SimpleElementType, — Определение типа простого элемента (SimpleElementType) Этот тип элемента указывает свойство, которое может встречаться в различных структурах объекта, например в MessageType (см также AppendixType, ProjectType. PersonType и OrgamsationType) SimpleElementType всегда является вложенным в ComplexElementType description: STRING, interfaceType STRING; state STRING.

dateLaMu: DATETIME; userLaMu STRING; language OPTIONAL STRING, category OPTIONAL STRING; helplnfo: OPTIONAL STRING; valueList OPTIONAL STRING; userDefinedType: UserDefinedType;

END_ENTITY.

ENTITY UserDefinedType, — Спецификация типа данных (для использования в SimpleElementType) Этот тип данных формирует заполняемые области в конечном сообщении, например, нидерландский почтовый индекс всегда начинается с четырех цифр, за которыми следуют две буквы description STRING; state STRING. dateLaMu: DATETIME; userLaMu STRING; baseType STRING; xsdRestriction OPTIONAL STRING, language OPTIONAL STRING; helplnfo: OPTIONAL STRING,

END_ENTITY.

ENTITY MessagelnTransacbonType; — Образец типа MessageType в типе TransactionType, относящийся к конкретному типу группы (GroupType) requiredNotify: INTEGER; dateLaMu: DATETIME; userLaMu STRING; received BOOLEAN, send: BOOLEAN; state STRING;

initiatorToExecutor OPTIONAL BOOLEAN; openSecondaryTransactionsAllowed OPTIONAL BOOLEAN, firstMessage: OPTIONAL BOOLEAN; message MessageType.

previous: OPTIONAL SET (0 ?] OF MessagelnTransactionType; transaction: TransacbonType; transactionPhase OPTIONAL TransactionPhaseType; group GroupType,

appendixTypes OPTIONAL SET (1?) OF AppendixType;

END_ENTITY;

ENTITY TransactionPhaseType. — Определение фазы, относящейся к транзакции

Примеры «назначение принято» или «часть результата получена».

description STRING;

startDate DATETIME;

endDate: DATETIME,

state: STRING;

dateLaMu: DATETIME;

userLaMu STRING;

language OPTIONAL STRING.

category: OPTIONAL STRING;

helplnfo OPTIONAL STRING.

code: OPTIONAL STRING.

END_ENTITY.

ENTITY TransactionType. — Определение типа транзакции Тип транзакции может ссылаться на другие типы транзакции Транзакцию будет инициировать лицо, принадлежащее к организации, выполняющей определенную роль На этом уровне должен быть заявлен тип роли инициатора (введенный в действие активированной схемой). Это же верно для исполнителя description STRING. startDate: DATETIME; endDate: DATETIME; state STRING; dateLaMu DATETIME; userLaMu: STRING; language OPTIONAL STRING.

category OPTIONAL STRING; helplnfo OPTIONAL STRING, code OPTIONAL STRING, result OPTIONAL STRING;

subTransactions: OPTIONAL SET [1:?] OF TransactionType; initiator RoleType. executor RoleType,

appendixTypes: OPTIONAL SET [1:?] OF AppendixType;

END_ENTITY;

ENTITY RoleType, — Определение конкретного типа роли

descnption: STRING,

startDate DATETIME;

endDate DATETIME,

state: STRING.

dateLaMu DATETIME;

userLaMu STRING,

language OPTIONAL STRING,

category OPTIONAL STRING;

helplnfo OPTIONAL STRING.

code OPTIONAL STRING,

responsibilityScope: OPTIONAL STRING;

responsibility Task OPTIONAL STRING.

responsibilitySupportTask OPTIONAL STRING.

responsibilityFeedback OPTIONAL STRING.

END_ENTITY;

ENTITY GroupType. — Определение группы для сохранения дополнений, отправленных с сообщением в транзакции

descnption: STRING; startDate DATETIME. endDate DATETIME, state: STRING: dateLaMu DATETIME. userLaMu STRING, language OPTIONAL STRING; category OPTIONAL STRING, helplnfo OPTIONAL STRING.

END ENTITY;

END SCHEMA.

А.З Определение схемы структуры взаимодействия (формат XSO)

<?xml version="1.0" encoding = "UTF-8"? >

<xsd:schema targetNamespace="http://www. ISO 29481 Part 2A.com/schemas" xmlns:iso29481p2a ■ "http://www.ISO 29481 Part 2A.com/schemas" xmlnsrxsd = "http://www.w3.org/2001/XMLSchema" elementFormDefault - "qualified" >

<!- объявление корневого элемента (для SCHEMA определений) —

<xsd:element name«"IS0 29481_Part_2A" >

<xsd:complexType>

<xsd:choice maxOccurs="unbounded" >

<xsd:element ref«"iso29481p2a:AppendixType"/ >

<xsd:element ref="iso29481p2a:ComplexElementType"/ > <xsd:element ref="iso29481p2a:ElementCondition"/ > <xsd:element ref-"iso29481p2a:GroupType"/ >

<xsd:element ref="iso29481p2a:MessageInTransactionType"/ > <xsd:element ref="iso29481p2a:MessageType"/ >

<xsd:element ref="iso29481p2a:OrganisationType"/ > <xsd:element ref="iso29481p2a:PersonType"/ >

<xsd:element ref-"iso29481p2a:ProjectType"/ >

<xsd:element ref="iso29481p2a:RoleType"/ >

<xsd:element ref="iso29481p2a:SimpleElementType"/ > <xsd:element ref«"iso29481p2a:TransactionPhaseType"/ > <xsd:element ref="iso29481p2a:TransactionType"/ > <xsd:element ref="iso29481p2a:UserDefinedType"/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

<!- объявление элемента (для ENTITY определений) —

<xsd:element name="AppendixType" type = "iso29481p2a:AppendixTypeType" >

<xsd:annotation>

<xsd:documentation>Tnn AppendixType содержит определение приложения. Какие элементы данных должны быть записаны в приложении, можно указать в разделе сложный элемент.</xsd:documentation> </xsd:annotation>

</xsd:element>

<xsd:element name-"ComplexElementType" type = "iso29481p2a:ComplexElementTypeType" >

<xsd:annotation>

<xsd:documentation>Cлoжный тип элемента ComplexElementType содержит набор простых типов элементов SimpleElementTypes. Каждый, из описанных SimpleElementType встречается ровно столько раз, сколько указано.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ElementCondition" type = "iso29481p2a:ElementConditionType" >

<xsd:annotation>

<xsd:documentation>ycnoBne SimpleElementType, используемое в определенном MessageType.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="GroupType" type * "iso29481p2a:GroupTypeType" > <xsd:annotation>

<xsd:documentation>Oпpeдeлeниe группы для хранения приложений, отправленных с сообщением в транзакции.</xsd:documentation> </xsd:annotation>

</xsd:element>

<xsd:element name="MessageInTransactionType" type = "iso29481p2a:MessageInTransactionTypeType" >

<xsd:annotation>

<xsd:documentation>Bo3HHKHOBeHne MessageType в TransactionType, связанного с определенным типом группы (GroupType).</xsd:documentation> </xsd:annotation>

</xsd:element>

<xsd:element name-"MessageType" type ■ "iso29481p2a:MessageTypeType" > <xsd:annotation>

<xsd:documentation>Oпpeдeлeниe типа сообщения (MessageType), указывающее структуру сообщения и какой набор SimpleElementType (через ComplexElementType) оно может сопровождать.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="OrganisationType" type ■ "iso29481p2a:OrganisationTypeType" >

<xsd:annotation>

<xsd:documentation>Oпpeдeлeниe конкретной группы организаций. Как правило, только один экземпляр будет присутствовать в структуре взаимодействия, определяющей структуру элементов, которые должен представлять каждый экземпляр организации.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="PersonType" type * "iso29481p2a:PersonTypeType" > <xsd:annotation>

<xsd:documentation>Oпpeдeлeниe конкретной группы людей. Как правило, только один экземпляр будет присутствовать в структуре взаимодействия, определяющей структуру элементов, которые должен представлять каждый экземпляр человека.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="ProjectType" type = "iso29481p2a:ProjectTypeType" > <xsd:annotation>

<xsd:documentation>Oпpeдeлeниe конкретной группы проектов. Как правило, только один экземпляр будет присутствовать в структуре взаимодействия, определяющей структуру элементов, которые должен представлять каждый экземпляр проекта.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="RoleType" type = "iso29481p2a:RoleTypeType" > <xsd:annotation>

<xsd:documentation>Oпpeдeлeниe конкретного типа роли.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="SimpleElementType" type ■ "iso29481p2a:SimpleElementTypeType^// >

<xsd:annotation>

<х5й:ск>ситег^а1:1оп>0пределение простого типа элемента (SimpleElementType). Этот тип элемента определяет свойство, которое может встречаться в различных структурах объектов, например, в MessageType (см. Также AppendixType, ProjectType, PersonType и OrganisationType). SimpleElementType всегда встроен в ComplexElementType.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="TransactionPhaseType" type = "iso29481p2a:TransactionPhaseTypeType" >

<xsd:annotation>

<xsd:documentation>Oпpeдeлeниe фазы, связанной с транзакцией. Примерами являются "принятое назначение" или "полученная часть результата".</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd: element name-^//TransactionType^,/ type = "iso29481p2a:TransactionTypeType" >

<xsd:annotation>

<xsd:documentat1оп>Определение типа транзакции. Тип транзакции может вновь ссылаться на другие типы транзакций. Инициатором сделки является лицо, принадлежащее к организации, выполняющей определенную роль. На этом уровне должен быть указан тип роли инициатора (продвинутая схема будет применять это). То же самое относится и к исполнителю.</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name="UserDefinedType" type - "iso29481p2a:UserDefinedTypeType" >

<xsd:annotation>

<xsd:documentat1оп>Спецификация типа данных (для использования в SimpleElementType).</xsd:documentation>

</xsd:annotation>

</xsd:element>

<!- объявления ссылок на элементы (для ENTITY определений) —

<xsd:element name="AppendixTypeRef" type = "iso29481p2a:AppendixTypeTypeRef"/ >

<xsd:element name""ComplexElementTypeRef" type = "iso29481p2a:ComplexElementTypeTypeRef"/ >

<xsd:element name=»"ElementConditionRef" type ■ ^,,iso29481p2a:ElementConditionTypeRef"/ >

<xsd:element name="GroupTypeRef " type = "iso29481p2a:GroupTypeTypeRef"/ >

<xsd:element name-"MessageInTransactionTypeRef" type = "iso29481p2a:MessageInTransactionTypeTypeRef"/ >

<xsd:element name="MessageTypeRef" type - "iso29481p2a:MessageTypeTypeRef"/ >

<xsd:element name="OrganisationTypeRef" type = "iso29481p2a:OrganisationTypeTypeRef"/ >

<xsd:element name-"PersonTypeRef" type = "iso29481p2a:PersonTypeTypeRef"/ >

Содержание

1    Область применения....................................................................................................................................1

2    Нормативные ссылки....................................................................................................................................1

3    Термины и определения...............................................................................................................................1

4    Основные принципы.....................................................................................................................................2

4.1    Общие положения..................................................................................................................................2

4.2    BIM и ЮМ................................................................................................................................................2

4.3    Компоненты ЮМ.....................................................................................................................................2

4.4    Основные принципы деловой коммуникации.......................................................................................3

4.5    Карта взаимодействия...........................................................................................................................3

4.6    Сообщения в транзакции.......................................................................................................................5

4.7    Структура взаимодействия....................................................................................................................6

4.8    Поддержка программных решений.......................................................................................................6

5    Формат структуры взаимодействия.............................................................................................................8

5.1    Введение.................................................................................................................................................8

5.2    Типы информации в схеме структуры взаимодействия......................................................................8

Приложение А (обязательное) Определение схемы структуры взаимодействия....................................10

Приложение В (обязательное) Определение шаблонов............................................................................43

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

конструкторского бюро........................................................................................................58

Приложение D (справочное) Основные идеи алгоритма промотора........................................................70

Приложение ДА (справочное) Сведения о соответствии ссылочных международных

стандартов национальным стандартам..........................................................................71

Библиография................................................................................................................................................72

<xsd:element name="complexElements'

<xsd:complexType>

<xsd:choice maxOccurs-"unbounded" >

<xsd:element ref="iso29481p2a:ComplexElementType"/ <xsd:element ref="iso29481p2a:ComplexElementTypeRef"/ >

</xsd:choice>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

<xsd:complexType name="ComplexElementTypeType" >

<xsd:complexContent>

<xsd:extension base="iso29481p2a:elementType" >

<xsd:sequence>

<xsd:element name="description" type = "xsd:string"/ > <xsd:element name="startDate" type = "xsd:dateTime"/ > <xsd:element name="endDate" type - "xsd:dateTime"/ >

<xsd:element name="state" type - "xsd:string"/ >

<xsd:element name="dateLaMu" type = "xsd:dateTime"/ >

Введение

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

Справочник по обмену информацией (ЮМ) значительно способствует наиболее эффективному применению информационной модели здания (BIM). Быстрый доступ к необходимой информации хорошего качества значительно улучшает строительный процесс. Для этого требуется единое понимание строительных процессов и информации, необходимой для их выполнения.

В настоящем стандарте основное внимание уделяется аспектам строительного процесса, относящимся к задачам управления участниками процесса и координации их действий. Координация, в свою очередь, зависит от коммуникации, которая должна быть хорошо структурированной, понятной, исчерпывающей и оперативной. Благодаря акценту на координацию и взаимодействие настоящий стандарт естественным образом дополняет такие стандарты моделирования зданий, как ИСО 10303-239 и ИСО 16739-1:2018.

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

Разработка настоящего стандарта вызвана потребностью участников процесса в надежности при обмене информацией. Она основывается главным образом на стандарте Нидерландов VISI, разработанном в 2003 году.

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Система стандартов информационного моделирования зданий и сооружений

ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ

Справочник по обмену информацией

Часть 2

Структура взаимодействия

System of standards on information modeling of buildings and structures Building information models Information delivery manual Part 2 Interaction framework

Дата введения — 2019—09—01

1    Область применения

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

В настоящем стандарте приведены:

-    методология, описывающая структуру взаимодействия,

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

-    формат, в котором должна описываться структура взаимодействия.

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

2    Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт:

ISO 29481-1, Building information models — Information delivery manual — Part 1: Methodology and format (Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 1. Методология и формат)

3    Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1    справочник по обмену информацией (Information Delivery Manual. IDM): Документация, описывающая бизнес-процесс и содержащая подробное описание информации, которую на определенном этапе проекта должен предоставить пользователь, выполняющий определенную роль.

3.2    структура взаимодействия (interaction framework): Формальное описание элементов взаимодействия, включая определение ролей, транзакций, сообщений в транзакциях и элементов данных в сообщениях.

3.3    схема структуры взаимодействия (interaction framework schema): Формальное описание правил, которым должна подчиняться структура взаимодействия.

3.4    схема взаимодействия (interaction schema): Формальное описание правил, которым должны соответствовать отправленные и полученные сообщения.

Издание официальное

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

3.6    файл шаблонов (templates file): Файл, содержащий несколько независимых от структуры взаимодействия шаблонов для формирования схемы взаимодействия.

3.7    VISI: Аббревиатура, обозначающая стандарт Нидерландов по взаимодействию между участниками в строительных проектах.

Примечание — VISI означает «Voorwaarden scheppen voor Invoeren Standaardisatie ICT in de Infrastructuur-sector», что переводится как «Создание условий для стандартизации ИКТ-технологий в строительной отрасли»

4 Основные принципы

4.1    Общие положения

Настоящий раздел выделяет и объясняет основные понятия, на которых основан настоящий стандарт.

4.2    BIM и ЮМ

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

В настоящем стандарте излагается метод разработки справочника по обмену информацией. Приведенная в ИСО 29481-1:2016 методология IDM должна использоваться для всех упоминаний о разработке и использовании IDM.

4.3    Компоненты ЮМ

Методология и компоненты ЮМ описаны в ИСО 29481-1:2016. В указанном стандарте схематически показано, что представляют собой различные компоненты IDM и как они связаны мехаду собой.

ЮМ можно рассматривать под двумя углами: в ракурсе пользовательских требований и в контексте технических решений. Для кахадого подхода выделяется ряд зон. характеризующих различные компоненты ЮМ (см. рисунок 1).

Карта взаимодействия ' Технологическая карта Ссыло«<ы« прайсе** Греф*» пров*п - Доставка информации

Бизмос-объокт

	Сплрфммци» •«фор»*»»*
	Инфсе**ви*юим» мсоапД
	обмана ctpOMiantctaa 1

Рисунок 1 — Зоны ЮМ

С точки зрения пользовательских требований к этим зонам относятся:

-    карты взаимодействия, описывающие роли и взаимодействия менаду ними;

-    технолотческие карты, описывающие общий процесс, в котором происходит обмен информацией; -доставка информации, описывающая потребности в обмене информацией;

-    ссылочные процессы (хранимые описания операций обмена информацией);

-    график проекта (реализации процессов в контексте проекта).

С точки зрения технических решений выделяют следующие зоны:

-    бизнес-объекты, включающие перечень требований к обмену информацией;

-спецификация информации, описывающая схему, лежащую в основе обмена информацией;

-    информационная модель здания.

Настоящий стандарт регламентирует карты взаимодействия и основывается на общих принципах деловой коммуникации.

4.4 Основные принципы деловой коммуникации

После запроса клиента или заказчика предоставить продукт или оказать услугу возникает цепочка действий, совместный результат которых заключается в предоставлении продукта или услуги. Такая цепочка действий называется бизнес-процессом. Речь идет, в частности, о первичном бизнес-процессе, поскольку он инициируется извне.

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

Рисунок 2 — Шаблон транзакции (Dietz J.L.G., 2006 (1))

На рисунке 2 представлена простейшая форма шаблона транзакции. Шаблон показывает, что достижение какого-либо нового результата (возьмем в качестве «желаемого результата», например, предоставление некоего документа) начинается с запроса этого результата лицом, действующим в роли заказчика. у лица, действующего в роли исполнителя. Это действие переводит процесс в состояние «результат запрошен». Далее исполнитель отвечает на запрос, пообещав предоставить желаемый результат, тем самым переводя процесс в состояние «результат обещан». Таким образом, у исполнителя появляется задача: он должен выполнить обещание, фактически подготовив документ и приняв решение предоставить его заказчику. При передаче документа заказчику исполнитель сообщает, что его обещание выполнено. Заказчик отвечает путем приемки полученного результата. Это действие завершает транзакцию.

В бизнес-процессе зачастую участвует множество акторов. Их поведение зависит от их роли в конкретном процессе. Роли/акторы взаимодействуют с другими ролями/акторами путем осуществления транзакций. Удобным представлением взаимодействия между ролями/акторами является карта взаимодействия.

4.5 Карта взаимодействия

Карта взаимодействия определяет соответствующие типы ролей и транзакций для определенного процесса. ЮМ выделяет роль, делающую запрос (инициатор), и роль, отвечающую на этот запрос (исполнитель). В каждой транзакции может быть только одна инициирующая роль и одна исполняющая. На рисунке 3 показаны компоненты карты взаимодействия.

Примечание — Система обозначений на карте взаимодействия основана на строительной модели, описанной в публикации профессора Яна Л Г Дитца Она отличается от системы обозначений BPMN и используется для создания максимально простых карт Также она включает концепцию «транзакции», отсутствующую в BPMN.

Тип роли Rj

<$>

Тип транзакции Tj    Связь с инициатором    Связь с исполнителем

Рисунок 3 — Компоненты карты взаимодействия

Преимущество карты взаимодействия заключается в том. что она фокусируется на интерфейсах между ролями, скрывая при этом сломоюсть конкретного процесса в области ролей и подробности взаимодействия между этими ролями. Использование абстрактных ролей позволяет применять карту взаимодействия в самых разных случаях. Карта взаимодействия — это ценный инструмент для анализа и определения основных элементов бизнес-процесса. На рисунке 4 показан упрощенный пример карты взаимодействия конструкторского бюро.

Конструкторское бюро

CRj					r2
Клиент		1 у—	Управление проектом		Системное гро«**'И1»взниа
			R1		R3
					трех мерных моделей
					R4
					жоиоми<оасов обоснование

Рисунок 4 — Пример карты взаимодействия

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

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

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

Таблица 1— Упрощенная таблица транзакций конструкторского бюро

Результат транзакции Тип транзакции Разработан проект Т1. разработка проекта Разработана спецификация системы Т2. разработка спецификации системы Разработана трехмерная модель ТЗ. разработка трехмерной модели Разработана смета Т4. разработка сметы

4.6 Сообщения в транзакции

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

В качестве примера транзакции можно привести обработку запроса трехмерной модели. На рисунке 5 показаны сообщения в транзакции в форме диаграммы последовательности в обозначении UML. Транзакция может быть инициирована только руководителем проекта R1 с помощью сообщения «Запрос трехмерной модели». Инженер — разработчик трехмерных моделей (роль R3) может направить в ответ сообщение «Задание выполнено, запрашивается утверждение выполнения». После отправки сообщения «Выполнение задания утверждено» (или «Выполнение задания не утверждено») транзакция будет завершена.

Рисунок 5 — Пример сообщений в транзакции

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

4.7    Структура взаимодействия

Для выдачи указаний процессу и передачи информации элементы взаимодействия необходимо описать упорядоченным образом. Такое упорядоченное описание носит название структуры взаимодействия. Структура взаимодействия включает:

-    определение соответствующих ролей.

-транзакции.

-    сообщения в транзакции,

-    порядок сообщений в транзакции,

-    элементы данных в сообщениях.

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

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

4.8    Поддержка программных решений

4.8.1    Обзор

Следующим шагом является поддержка структуры взаимодействия с программными решениями в следующих целях:

-    поддержка редактирования структуры взаимодействия,

-    гарантия полноты и обоснованности структуры взаимодействия.

-    поддержка портативности структуры взаимодействия.

-    поддержка работы информационных систем.

-    поддержка коммуникационной интероперабельности.

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

На рисунке 6 показано, как осуществляется поддержка программных решений. В следующих разделах приводится пояснение.

4.8.2    Поддержка структуры взаимодействия

Чтобы обеспечить портативность структуры взаимодействия, необходимо четко обозначить, каким правилам она должна соответствовать. Эти правила должны быть включены в схему структуры взаимодействия. которая записывается в XSD-файл схемы. Структура взаимодействия включает в себя экземпляры классов, определенных в схеме, и записывается в XML-файл.

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

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

Каждая структура взаимодействия должна соответствовать схеме структуры взаимодействия.

Редактор структуры взаимодействия должен использовать схему структуры взаимодействия для валидации созданных структур.

4.8.3    Промотор

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

Схема взаимодействия генерируется с помощью общего алгоритма, называемого «промотор». Промотор «продвигает» экземпляры XML в классы XSD. В качестве входных данных используются: