Национальный стандарт РФ ГОСТ Р 10.0.03-2019/ИСО 29481-1:2016 "Система стандартов информационного моделирования зданий и сооружений. Информационное моделирование в строительстве. Справочник по обмену информацией. Часть 1. Методология и формат" (утв. и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 5 июня 2019 г. N 279-ст)

System of standards on information modeling of buildings and structures. Building information models. Information delivery manual. Part 1. Methodology and format

ОКС 91.010.01
35.240.67
35.240.01

Дата введения - 1 сентября 2019 г.
Взамен ГОСТ Р 57310-2016 (ИСО 29481-1:2010)

Предисловие

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

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

3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 5 июня 2019 г. N 279-ст

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

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

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

5 Взамен ГОСТ Р 57310-2016 (ИСО 29481-1:2010)

Введение

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

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

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

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

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

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

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

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

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

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

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

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

ISO 6707-1, Buildings and civil engineering works - Vocabulary - Part 1: General terms (Здания и сооружения. Словарь. Часть 1. Общие термины)

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

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

3.1 актор (actor): Лицо, организация или организационная единица (отдел, команда и т.д.), участвующие в строительном процессе.

3.2 технологии информационного моделирования (зданий и сооружений): Деятельность по созданию, управлению и хранению электронной информации о зданиях и сооружениях на всех или отдельных стадиях их жизненного цикла, результатом которой является создание информационной модели здания или сооружения.

Примечание - Термин "технологии информационного моделирования" равнозначен англоязычному термину "Building Information Modeling" (BIM) и может использоваться в национальных стандартах, документах по стандартизации и любых других нормативных и нормативно-технических документах в качестве аббревиатуры "ТИМ".

3.3 программное обеспечение BIM (BIM software application): Программное обеспечение, используемое для создания, модификации, анализа, управления, публикации, совместного использования, завершения или выполнения иных действий с элементами BIM.

3.4 бизнес-требование (business requirement): Требование, описывающее в терминах деловой среды, что необходимо предоставить или выполнить.

3.5 информационное ограничение (information constraint): Положение, формально определяющее или ограничивающее сферу действия информации ввиду какого-либо аспекта деловой деятельности, правило, в соответствии с которым действует организация, а также политика или решение, оказывающие влияние на процесс.

3.6 класс (class): Тип или набор предметов, обладающих общими свойствами.

3.7 объект строительства (construction works): Все, что построено или является результатом строительства.

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

3.8 строительный процесс (construction process): Процесс, использующий строительные ресурсы для достижения результатов строительства.

Примечание - Строительный процесс может подразделяться на составляющие его процессы.

3.9 требование к обмену информацией (exchange requirement; ER): Конкретный набор информационных единиц, которыми необходимо обмениваться для соблюдения определенного бизнес-требования на определенных стадиях или этапах процесса.

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

Примечание - Данную документацию называют также "спецификацией обмена информацией" (IDM - сокр. от англ. information delivery specification).

3.11 компоненты IDM (IDM components): Базовые элементы, формирующие IDM: карты взаимодействия (транзакций), карты процессов и требования к обмену информацией.

3.12 информационная единица (information unit): Отдельный информационный элемент, такой как идентификатор окна или высота помещения.

3.13 карта взаимодействия (interaction map): Представление ролей и транзакций, имеющих отношение к конкретной цели.

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

3.15 модель (model): Представление системы, позволяющее исследовать ее свойства.

3.16 определение модельного вида (model view definition; MVD): Спецификация, устанавливающая техническое описание процесса реализации IDM для разработчиков программного обеспечения.

Примечание - Спецификация MVD (Model View Definition - Определение модельного вида) установлена в качестве спецификации международной некоммерческой организации buildingSMART International.

3.17 объект (object): Часть реального или воображаемого мира.

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

3.18 технологическая карта (process map, РМ): Представление характеристик процесса, соответствующего поставленной цели, в виде карты.

3.19 роль (role): Функции, выполняемые актором в определенный момент времени.

Примечание - Роль актора определяется не столько его профессией или родом занятий, сколько действием и результатом.

3.20 транзакция (transaction): Коммуникационное событие, осуществляющее взаимосвязь между двумя ролями.

3.21 карта транзакции (transaction map): Представление набора сообщений, которыми обмениваются участвующие роли с определенной целью.

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

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

В этом разделе описывается ряд понятий и принципов, применяемых при разработке IDM.

4.2 Аудитория настоящего стандарта

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

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

- профессиональные разработчики IDM и поставщики ПО;

- пользователи информации, то есть руководители и конечные пользователи, занимающиеся наполнением IDM и пользующиеся ими.

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

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

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

- клиент, инициирующий (разрабатывающий) IDM и включающий его в договор;

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

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

- строительная организация, использующая IDM для особого типа проектов в качестве шаблона или стандарта для применения в конкретной области специализации.

4.3 Бизнес-контекст

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

Рисунок 1 - Пример простого бизнес-контекста, требующего IDM

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

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

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

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

4.4 Полная схема

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

4.5 Разделение полной схемы для обеспечения соблюдения требований

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

4.6 Поддержка процесса информационного моделирования объектов строительства

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

Рисунок 2 - Поддержка процесса BIM

4.7 Поддержка бизнес-процесса

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

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

4.8 Поддержка программного решения

Для перехода от определенного требования к обмену к программной реализации, которую предоставляет поставщик решения, необходима разработка определения модельного вида (MVD).

4.9 Характерное содержимое IDM

Характерное содержимое IDM должно:

- описывать потребность в обмене информацией в бизнес-контексте;

- определять акторов, отправляющих и получающих информацию;

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

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

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

- применять полученные спецификации информации к местным методам работы.

Указания по определению содержимого IDM и выбору подхода к его разработке приводятся в приложении А.

5 Инфраструктура IDM

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

Каждое руководство по обмену информацией содержит (рисунок 3):

- карту взаимодействия/транзакции и/или технологическую карту;

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

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

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

Рисунок 3 - Базовая инфраструктура IDM

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

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

Техническая реализация требования к обмену выполняется через определение представления модели. Техническая реализация карты взаимодействия/транзакции предоставляется в инфраструктуре взаимодействия.

5.2 Базовая инфраструктура

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

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

5.2.2 Информация заголовка компонента IDM

Каждый компонент IDM должен включать по меньшей мере следующую административную информацию:

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

- уникальный идентификатор;

- этап проекта, поддерживаемый компонентом;

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

Таблица 1 - Правила именования

N	Правило именования
1	Каждый компонент IDM должен иметь имя
2	Первая часть каждого имени - это префикс: - er_ для требований к обмену информацией; - im_ для карт взаимодействия; - pm_ для технологических карт; - tm_ для карт транзакций
3	Имя, данное каждому компоненту IDM, является императивом, состоящим из двух частей: - первая часть имени - требуемое действие (или активность), выраженное глаголом; - вторая часть имени - объект, на который направлено действие, выраженный существительным или именным словосочетанием. Оно может представлять непосредственно объект (как в "Моделировать стену") или подразумеваемый косвенный объект (как в "Указать материал", что означает связывание стены с материалом)
4	Все распознаваемые слова в имени разделяются символом подчеркивания "_"
5	Компоненты IDM могут иметь дополнительные квалифицирующие параметры. Эти параметры выражаются в виде списка, помещенного в круглых скобках, например (а, b, с, d)

Этап проекта определяется этапом жизненного цикла объекта строительства. Справка по этапам жизненного цикла приведена в приложении С.

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

5.2.3 Общие сведения о компонентах IDM

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

Примеры упрощенных компонентов IDM приведены в приложении В.

5.3 Карта взаимодействия/транзакции

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

Рекомендованный подход для подготовки карты взаимодействия формулируется согласно модели CRISP (Dietz, J.L.G.: Enterprise Ontology, Springer, 2006).

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

Карта транзакции - это представление сообщений, которыми могут обмениваться задействованные роли в конкретной транзакции, включая ограничения на последовательность. Для подготовки карты транзакции рекомендуется подход UML (Unified Modeling Language - диаграмма последовательности).

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

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

- требование к обмену;

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

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

5.4 Технологические карты

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

Для представления технологических карт рекомендуется использовать подход BPMN (Business Process Modelling Notation, "Нотация для моделирования бизнес-процессов"). Дополнительные сведения о BPMN приведены в приложении D.

Технологическая карта в составе IDM:

- устанавливает границы для объема информации, содержащейся в процессе,

- устанавливает действия, выполняемые в рамках процесса, и

- показывает логическую последовательность этих действий.

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

Технологическая карта включает следующую административную информацию:

- требования к обмену, лежащие в пределах границ процесса;

- обзор, который дает полное описание общего процесса.

Диаграммы могут использоваться для иллюстрации отдельных пунктов в обзоре.

5.5 Требования к обмену информацией

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

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

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

5.5.2 Информационные единицы

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

Сначала определяются предусловия для требования к обмену. Предусловие - требование к обмену, которое должно было быть выполнено до исполнения текущего требования к обмену.

Далее должны быть указаны информационные единицы, обеспечивающие следующее:

- описание информационной единицы: описание должно быть максимально точным и достаточно однозначным, чтобы MVD-моделлеры не путали их с другими понятиями;

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

5.5.3 Информационные ограничения

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

Типы данных: текст, целое число, номер, 2D-графика, 3D-модель и т.д.

Контекст, правила и ограничения использования:

- у стола должно быть не менее трех ножек;

- сборное железобетонное изделие должно иметь не менее трех идентификаторов: марку изделия (производственный серийный номер), маркировочный номер (проектный номер) и идентификатор местоположения монтажа;

- площадь комнаты не может быть меньше 0 м²;

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

5.6 Техническая реализация

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

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

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

5.6.2 Реализация метаданных

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

5.6.3 Инфраструктура взаимодействия

Инфраструктура взаимодействия - это формальное описание элементов взаимодействия, включая определение ролей, транзакций, сообщений в транзакции, последовательности сообщений и элементов данных в сообщениях. Методология разработки инфраструктуры взаимодействия и ее формата включена в ИСО 29481-2 [1].

5.6.4 Определение модельного вида (MVD)

MVD (Model view definition) определяет модель данных или подмножество существующей модели данных, необходимые для соблюдения одного или нескольких конкретных требований к обмену данными (рисунок 4). MVD используются в разработке программного обеспечения и должны иметь машиночитаемое представление. Определение модельного вида (MVD), относящееся к одному справочнику по передаче информации (IDM, Information Delivery Manual), может использоваться для фильтрации информации в программных средствах для конкретного требования к обмену информацией. Если информационные ограничения добавляются к MVD, то эта комбинация может использоваться в целях валидации данных. В программных продуктах, поддерживающих несколько требований к обмену, могут быть реализованы объединенные MVD, ссылающиеся на несколько IDM. Объединенные MVD часто используются в сертификации программных продуктов, но проверка данных всегда должна выполняться для каждого отдельного MVD.

Рисунок 4 - Связь между IDM и MVD

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

[1]	ISO 29481-2, Building information models - Information delivery manual - Part 2: Interaction framework