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

ГОСТР

57310-

2016

(ИСО 29481-1:2010)

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

Руководство по доставке информации. Методология и формат

(ISO 29481-1:2010,

Building information models — Information delivery manual — Part 1: Methodology and format,

MOD)

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

Москва

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

2017

Предисловие

1    ПОДГОТОВЛЕН структурными подразделениями Акционерного общества «Научно-исследовательский центр «Строительство» (АО «НИЦ «Строительство») ЦНИИСК им. В.А. Кучеренко совместно с НИИЖБ им. А.А. Гвоздева на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 465 «Строительство»

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

4    Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 29481-1:2010 «Моделирование информационное зданий и сооружений. Руководство по доставке информации. Часть 1. Методология и формат» (ISO 29481-1:2010 «Building information models — Information delivery manual. Part 1: Methodology and format», MOD). При этом в него не включены разделы А.4 и А.5 приложения А примененного международного стандарта, являющиеся либо ссылками на внешние интернет-ресурсы, либо информацией, не упоминаемой в контексте основной части настоящего стандарта. Указанные разделы приложения, не включенные в основную часть настоящего стандарта, приведены в дополнительном приложении ДА.

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

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

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

© Стандартинформ, 2017

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

ГОСТ P 57310—2016

Карта процессов включает в себя следующую административную информацию:

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

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

5.5.3    Определение процессов

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

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

5.5.4    Определение объекта данных

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

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

5.5.5    Определение требований к обмену информацией

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

Требования к обмену информацией должны включать в себя следующее:

-    имя, которое позволяет идентифицировать цель (правила именования приведены в А.З);

-    описание, дающее понятие о целях и содержании.

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

5.5.6    Определение точек согласованного входа

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

Решения, принятые в точках согласованного входа могут обеспечивать:

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

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

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

5.6.1    Общая информация

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

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

5.6.2    Содержание

Требования к обмену информацией содержат следующую информацию:

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

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

7

5.6.3 Блоки информации

Необходимая информация предоставляется в блоках. Блок информации обычно имеет дело с одним типом информации или концепцией интересов, такой как проект в целом, стены, окна и пр.

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

Блоки информации затем разбиваются для обеспечения:

-    идентификационного имени;

-    описания изменений информации;

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

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

5.7 Функциональные части

5.7.1    Основная информация

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

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

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

5.7.2    Содержание

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

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

5.7.3    Техническая информация

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

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

Таблица 1 — Техническая информация в функциональной части

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

Окончание таблицы 1

Техническая информация Описание Соглашение, определенное руководством для выражения объекта/атрибута/гипа данных и набора свойств/свойства/гипа данных, имеет следующую схему: -    функциональный объект.атрибут —>■ тип данных; -    набор свойств.свойство —>■ тип данных Обязательная/ дополнительная/ запрашиваемая/ исключенная Указания функциональной части о том, является ли информация обязательной (должна быть предоставлена), дополнительной (может быть предоставлена), запрашиваемой (по желанию, в рамках информационной модели) или не должна быть заявлена для функциональной части

5.7.4 Перечень разделов

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

Таблица 2 — Перечень разделов

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

5.7.5    Раздел схемы

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

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

5.7.6    Пример раздела

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

5.8 Функциональные блоки

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

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

9

Функциональная часть

1ММГ А А А

Функциональные блоки

Рисунок 5 — Функциональные блоки внутри функциональной части

6 Реализация и проверка компонентов руководства

6.1 Модель требований к обмену информацией

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

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

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

-    найдут применение внутри программных приложений;

-    формируют часть определенного сертифицированного вида модели;

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

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

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

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

-    где и кем оно было определено;

-    уровень применимости. Например, оно применимо к объекту, перечисленным типам данных или для свойства в наборе свойств;

-    индекс или другую ссылку.

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

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

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

6.3 Проверочные тесты

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

Требования обмена

Бизнес-тесты Проверочные испытания

Рисунок 8 — Применение общего руководства и дополнительных указаний

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

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

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

12

ГОСТ P 57310—2016

-    улучшение качества информации решений бизнес-систем;

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

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

7    Общие и частные руководства

7.1    Общее руководство

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

7.2    Применение частных руководств

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

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

8    Процесс разработки руководства

8.1    Цель разработки

Предложение о проведении разработки руководства по доставке информации является предварительным этапом, на котором устанавливается, какую работу предстоит сделать. Это связано:

-    с определением сферы деятельности;

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

-    определением ресурсов;

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

8.1.1    Определение объемов работ

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

8.1.2    Основы подхода к разработке

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

8.1.3    Определение ресурсов

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

8.1.4    План проекта

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

13

8.2 Этапы разработки руководства

8.2.1    Общая информация

Три подхода к разработке руководства по доставке информации:

-    создание процесса;

-    определение бизнес-правила;

-    обратное проектирование.

8.2.2    Создание процесса

8.2.2.1    Общая информация

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

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

8.2.2.2    Процесс создания

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

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

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

8.2.2.3    Разработка требований к обмену информацией

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

8.2.2.4    Создание функциональных частей

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

8.2.3    Настройка бизнес-правил

8.2.3.1    Определение бизнес-правил

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

8.2.3.2    Локализация бизнес-правил

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

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

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

8.2.4    Обратное проектирование

8.2.4.1 Общая информация

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

ГОСТ Р 57310-2016

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

82.4.2 Определение сценария

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

8.2.4.3    Восстановление данных

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

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

8.2.4.4    Создание требования к обмену информацией

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

8.2.4.5    Создание функциональных частей

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

8.2.4.6    Определение бизнес-правил

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

8.2.4.7    Процесс объединения

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

9 Составление компонентов руководства

9.1    Общая информация

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

9.2    Добавление функциональных частей

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

Каждая функциональная часть имеет полностью определенную схему, которая включает в себя набор объектов. Например, функциональная часть Р2, показанная ниже, может включать в себя набор объектов {U, V, W, Z}, в то время как функциональная часть РЗ может включать в себя набор объектов {Т, U, V, X, У}. Необходимо отметить, что обе функциональные части включают в себя объекты {U, V} в своих схемах. Это типичный случай для объектов, используемых в функциональных частях схем.

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

Схема функциональной части, которая включает в себя другие функциональные части, эффективно суммирует все наборы объектов. Например, когда функциональная часть Р1 включает в себя Р2 и РЗ, Р1 будет суммой наборов объектов для Р2 и РЗ, как показано на рисунке 9. Схема Р1 содержит набор объектов {U, V, W, Z} + {Т, U, V, X, У}.

Рисунок 9 — Функциональная часть, включающая в себя другие функциональные части

Так же, как и включенные функциональные части Р2 и РЗ, часть Р1 может содержать локально расположенные объекты, например, {S, X}. Тот факт, что {X} используется в РЗ, не исключает его использования в Р1. В таком случае схема Р1 содержит набор объектов, которые точно определены, и наборы объектов, включенные в функциональные части. Таким образом, схема Р1 содержит набор объектов {S, X} + [{U, V, W, Z} + {Т, U, V, X, У}]. Расширение даст набор объектов внутри схемы PI {S, X, U, V, W, Z, Т, U, V, X, У}.

Получается, что схема Р1 включает в себя по два вхождения объектов {X}, {U} и {V}, что недопустимо. Набор объектов, образующих схему, может содержать только одно вхождение каждого объекта. Это значит, что совпадение вхождений должно быть урегулировано. Для Р1 решением схемы будет {S, Т, U, V, W, X, У Z} при вхождении каждого объекта по одному разу.

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

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

R1 = PI + Р2.

Однако если функциональная часть Р1 включает в себя функциональные части А, В, С, а Р2 включает в себя D, Е, F, то, следовательно

R1 = A+ B + C + D + E + F.

ГОСТ P 57310—2016

Содержание

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

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

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

4    Руководство по доставке информации...................................................2

4.1    Полная схема....................................................................2

4.2    Разбиение полной схемы на составляющие...........................................3

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

4.4    Поддержка бизнес-требований......................................................4

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

4.6    Поддержка строительного процесса..................................................4

4.7    Определение связи между компонентами руководства..................................4

4.8    Содержание конкретных руководств..................................................4

4.9    Пользователи настоящего стандарта.................................................5

5    Структура руководства................................................................5

5.1    Краткий обзор....................................................................5

5.2    Составляющие заголовков частей руководств..........................................6

5.3    Описание варианта использования...................................................6

5.4    Карты взаимодействий.............................................................6

5.5    Карты процессов..................................................................6

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

5.7    Функциональные части.............................................................8

5.8    Функциональные блоки............................................................9

6    Реализация и проверка компонентов руководства.........................................10

6.1    Модель требований к обмену информацией..........................................10

6.2    Бизнес-правила..................................................................11

6.3    Проверочные тесты..............................................................12

7    Общие и частные руководства.........................................................13

7.1    Общее руководство..............................................................13

7.2    Применение частных руководств...................................................13

8    Процесс разработки руководства.......................................................13

8.1    Цель разработки.................................................................13

8.2    Этапы разработки руководства.....................................................14

9    Составление компонентов руководства..................................................15

9.1    Общая информация..............................................................15

9.2    Добавление функциональных частей................................................15

9.3    Добавление моделей требований к обмену информацией...............................17

9.4    Блоки информационной модели....................................................18

Приложение А (справочное) Справочный    раздел...........................................19

Приложение ДА (справочное) Пункты примененного международного стандарта, не приведенные

в настоящем стандарте..................................................26

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

III

ГОСТ P 57310—2016

Введение

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

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

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

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

IV

ГОСТ Р 57310-2016 (ИСО 29481-1:2010)

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

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

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

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

Building information models. Information delivery manual. Methodology and format

Дата введения — 2017—07—01

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

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

Настоящий стандарт включает в себя:

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

-    форму, в которую информацию следует сводить;

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

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

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

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

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

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

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

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

3.3    информационная модель объекта строительства (building information model): Совместно используемое цифровое представление физических и функциональных характеристик какого-либо объекта капитального строительства (включая здания, мосты, дороги и прочее), формирующее надежную основу для принятия решений на протяжении всего жизненного цикла: от первоначальной идеи до вывода объекта из эксплуатации.

3.4    информационная система здания (building information system): Система, используемая для создания, сопровождения, определения или исключения элементов информационной модели объекта строительства.

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

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

3.5    нотация моделирования бизнес-процессов (business process modelling notation, BPMN): Нотация для создания диаграмм бизнес-процессов, которая разработана для легкого понимания всеми пользователями.

3.6    бизнес-требования (business requirements): Требования, которые описывают в бизнес-терминах то, что необходимо предоставить или реализовать.

3.7    бизнес-правило (business rule): Утверждение, которое формально определяет или ограничивает некоторые аспекты бизнеса, правило, согласно которому функционирует организация, или политика организации, или решения, влияющие на бизнес-процессы.

3.8    требования к обмену информацией (exchange requirement, ER): Набор информации, необходимый для обмена в процессе поддержания конкретного бизнес-требования на определенной фазе или стадии процесса.

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

3.9    модель требования к обмену информацией (exchange requirement model, ERM): Техническое выражение требования к обмену информацией в виде схемы.

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

3.10    функциональная часть (functional part, FP): Часть информации, входящая в требования к обмену информацией, которая может быть полностью самостоятельно определена.

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

3.12    управленческий информационный обмен (management communication): Совместное использование информации в целях управления.

3.13    модель (model): Изображение системы, которое позволяет исследовать ее свойства.

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

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

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

3.16    схема (schema): Схема является формальным отображением структуры определенного набора информации.

3.17    транзакция (transaction): Акт взаимодействия между двумя ролями, соответствующий отношениям между ними.

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

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

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

2

Рисунок 1 — Информационная схема, поддерживащая все бизнес-процессы на всех стадиях жизненного цикла объекта

4.2 Разбиение полной схемы на составляющие

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

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

3

4.4 Поддержка бизнес-требований

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

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

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

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

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

4.6 Поддержка строительного процесса

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

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

4.7    Определение связи между компонентами руководства

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

4.8    Содержание конкретных руководств

Содержание конкретного руководства должно:

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

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

4

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

5.2    Составляющие заголовков частей руководств

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

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

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

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

5.3    Описание варианта использования

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

5.4    Карты взаимодействий

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

Карта взаимодействий определяет соответствующие роли, транзакции и отношения между инициатором и исполнителем.

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

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

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

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

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

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

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

5.5    Карты процессов

5.5.1    Основная информация

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

Для представления карты процессов рекомендован подход нотаций моделирования бизнес-процессов (BPMN).

Карта процессов внутри руководств:

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

-    устанавливает деятельность в рамках процесса;

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

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

5.5.2    Содержание

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