Товары в корзине: 0 шт Оформить заказ
Стр. 1 

32 страницы

Купить ГОСТ Р 10.0.03-2019 — бумажный документ с голограммой и синими печатями. подробнее

Цена на этот документ пока неизвестна. Нажмите кнопку "Купить" и сделайте заказ, и мы пришлем вам цену.

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

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

 Скачать PDF

Идентичен ISO 29481-1:2016

Оглавление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение А (справочное) Процесс разработки IDM

Приложение В (справочное) Примеры упрощенных компонентов IDM

Приложение С (справочное) Справка по этапам жизненного цикла объекта строительства

Приложение D (справочное) Использование в IDM методов BPMN

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

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

 
Дата введения01.09.2019
Добавлен в базу01.02.2020
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

05.06.2019УтвержденФедеральное агентство по техническому регулированию и метрологии279-ст
РазработанБИМ-Ассоциация
ИзданСтандартинформ2019 г.

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

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

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

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ


ГОСТ Р 10.0.03

2019/

ИСО 29481-1:2016


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

ИНФОРМАЦИОННОЕ МОДЕЛИРОВАНИЕ В СТРОИТЕЛЬСТВЕ Справочник по обмену информацией

Часть 1

Методология и формат

(ISO 29481-1:2016, Building information models — Information delivery manual — Part 1: Methodology and format, IDT)

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

Москва

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

2019

Предисловие

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

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

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

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

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

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

Рисунок 3 — Базовая инфраструктура ЮМ

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

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

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

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

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

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

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

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

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

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

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

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

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

Правило именования

1

Каждый компонент ЮМ должен иметь имя

2

Первая часть каждого имени — это префикс:

-    ег_ для требований к обмену информацией;

-    im_ для карт взаимодействия.

-    рт_ для технологических карт,

-    tm_ для карт транзакций

3

Имя. данное каждому компоненту ЮМ, является императивом, состоящим из двух частей

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

-    вторая часть имени — объект, на который направлено действие, выраженный существительным или именным словосочетанием Оно может представлять непосредственно объект (как в «Моделировать стену») или подразумеваемый косвенный объект (как в «Указать материал», что означает связывание стены с материалом)

4

Все распознаваемые слова в имени разделяются символом подчеркивания «_»

5

Компоненты ЮМ могут иметь дополнительные квалифицирующие параметры Эти параметры выражаются в виде списка, помещенного в круглых скобках, например (a. b. с. d)

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

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

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

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

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

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

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

Рекомендованный подход для подготовки карты взаимодействия формулируется согласно модели 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    Информационные ограничения

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

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

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

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

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

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

-    для доставки обычным грузовиком максимальный размер панели не должен превышать 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). относящееся к одному справочнику по передаче информации (ЮМ. Information Delivery Manual), может использоваться для фильтрации информации в программных средствах для конкретного требования к обмену информацией. Если информационные ограничения добавляются к MVD. то эта комбинация может использоваться в целях валидации данных. В программных продуктах, поддерживающих несколько требований к обмену, могут быть реализованы обьединенные MVD. ссылающиеся на несколько ЮМ. Обьединенные MVD часто используются в сертификации программных продуктов, но проверка данных всегда должна выполняться для каждого отдельного MVD.

ЮМ


Требования


Реализация программы/ сертификация


Проверка непротиворечивости и полноты данных


Требование к обмену данными


Требование к обмену данными


ЮМ


Требование к обмену данными


Консолидированный MVD

MVD

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

MVD

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


ЮМ

Требование

MVD

MVD + Информаци-

к обмену данными

онмые ограничения

Рисунок 4 — Связь между ЮМ и MVD


Приложение А (справочное)

Процесс разработки ЮМ

А.1 Внесение предложения о разработке ЮМ А.1.1 Общие сведения

Внесение предложения о разработке ЮМ — это предварительный этап, который задает необходимые условия для выполнения работы На данном этапе

-    определяется область действия;

-    устанавливается подход к разработке;

-    определяются ресурсы,

-    устанавливается план проекта

А.1.2 Определение области действия

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

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

-    Кто может описать эти потребности’

-    Кто будет акторами, каковы их роли и интересы?

-    Как может быть подготовлен и осуществлен обмен информацией’

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

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

Должны быть описаны вопросы обмена практической и правовой информацией, чтобы было ясно, кто что делает и кто за что отвечает Условия соглашений и договорные условия могут препятствовать достижению определенных ранее целей и выполнению условий, необходимых для успешного завершения проекта Возможно, цели могут быть пересмотрены, чтобы они соответствовали соглашениям и стандартным условиям А.1.3 Выработка подхода к разработке ЮМ

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

Ресурсы — это люди, которым необходимо участвовать в разработке ЮМ Ресурсы должны быть правильно сбалансированы между управлением проектами, разработкой компонентов ЮМ и отраслевыми знаниями, чтобы можно было осуществлять руководство как разработкой компонентов, так и разработкой программных решений. Баланс требуемых ресурсов будет зависеть от выбранного пути разработки А.1.5 План работы

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

А.2 Разработка ЮМ А.2.1 Общие сведения

Существует три подхода к разработке ЮМ

-    выявление процесса;

-    настройка информационных ограничений;

-    воспроизведение недокументированного изделия А.2.2 Выявление процесса

А.2.2.1 Общие сведения

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

Этот подход к разработке описан ниже в виде линейной последовательности На практике можно ожидать наличия обратной связи между этапами разработки и циклическими изменениями А.2.2.2 Процесс выявления

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

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

Для достижения удовлетворительного результата этого процесса обычно требуется несколько циклов разработки и проверки После этого технологическая карта или инфраструктура взаимодействия может описывать имеющийся опыт или предложения по улучшению такового В рамках разработки необходимо принять решение — создать процесс «как есть» или процесс «как должно быть»

Технологические карты и карты взаимодействий будут определять «пакеты» данных, которые должны участвовать в обмене в разных точках бизнес-процесса Они представляют собой требования к обмену А.2.2.3 Создание требования к обмену

Затем должны быть созданы требования к обмену По возможности в них должны повторно использоваться ресурсы существующих требований к обмену

А.2.3 Настройка информационных ограничений А.2.3.1 Определение информационных ограничений

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

А.2.3.2 Локализация информационных ограничений

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

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

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

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

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

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

А.2.4.5 Определение информационных ограничений

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

А.2.4.6 Процесс захвата

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

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

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

Если задействованные акторы желают осуществить сертификацию программного обеспечения в соответствии с разработанным ЮМ, то должны быть предприняты определенные действия Во время процесса сертификации программных продуктов необходимо продемонстрировать, что они могут экспортировать и импортировать данные в соответствии с требованиями к обмену информацией С целью обеспечения его надежности процесс сертификации должен контролироваться независимой организацией Для подачи поставщиками программного обеспечения заявки на сертификацию должно быть подготовлено экономическое обоснование, поскольку стоимость собственно подготовки и сертификации может быть высока

Приложение В (справочное)

Примеры упрощенных компонентов ЮМ

В.1 Примеры бизнес-контекста

Представленные ниже примеры даны для иллюстрации каждого из компонентов ЮМ на примере простой бизнес-ситуации, в которой клиент привлекает группу консультантов для выполнения задания на проектирование Задача состоит в том, чтобы определить структуру строительных объектов Результат описывается с помощью трехмерных ограничивающих блоков Фактический справочник по обмену информацией представляет собой набор ограничивающих блоков и оценку стоимости

Этот пример был значительно упрощен и не предназначен для отражения реального применения

В.2 Технологическая карта

Название pm_29481_sample Идентификационное обозначение pm_29481_sample_1 Этап проекта Определение практической реализуемости

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

4.9    Характерное содержимое ЮМ......................................................5

5    Инфраструктура ЮМ.................................................................6

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

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

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

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

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

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

Приложение А (справочное) Процесс разработки ЮМ.......................................12

Приложение В (справочное) Примеры упрощенных компонентов ЮМ.........................15

Приложение С (справочное) Справка по этапам жизненного цикла объекта строительства........20

Приложение D (справочное) Использование в ЮМ методов BPMN............................22

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

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

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

В.З Карта взаимодействия

Название: im_29481_sample

Идентификационное обозначение im_29481_sample_1 Этап проекта Определение практической реализуемости

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

Рисунок В 2 — Карта взаимодействия


Введение

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

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

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

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

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

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

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

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

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

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

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

Ча ст ь1

Методология и формат

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

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

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

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

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

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

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

ISO 6707-1. Buildings and civil engineering worfcs — 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 — сокр. от англ information delivery specification).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по обмену информацией

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

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

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

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

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

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

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

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

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

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

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

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

ИНФОРМАЦИОННАЯ СХЕМА    N

I    I

ИНФОРМАЦИОННАЯ МОДЕЛЬ ОБЪЕКТА СТРОИТЕЛЬСТВА /

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Инфраструктура IDM 5.1 Общие положения

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

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

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

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

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