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

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

Building information models. Information delivery manual. Methodology and format

ОКС 35.240.01

Дата введения - 1 июля 2017 г.
Введен впервые

Предисловие

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

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

3 Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 2 декабря 2016 г. N 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 Введен впервые

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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). В таком виде, как правило, проектная информация не используется.

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

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

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

Рисунок 2 - Требования к поддержке бизнес-требований на всех стадиях жизненного цикла объекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке 4 показан основной вид главных компонентов, используемых в руководствах, и их зависимость друг от друга. Организация этих компонентов внутри структуры базируется на двух идеях:

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

Рисунок 4 - Структура базовых руководств

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.5.2 Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.6.2 Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.7.2 Содержание

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

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

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

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

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

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