СП РК 1.02-115 2018 ПРАВИЛА ОРГАНИЗАЦИИ СОВМЕСТНОГО СОЗДАНИЯ ИНФОРМАЦИИ О СТРОИТЕЛЬСТВЕ (ҚР ҚЖ 1.02-115 2018) - 5

СП РК 1.02

-115 2018 

7 

Примечание 

– 

Функциональный вид верхнего уровня СОД (CDE) показан на Рисунок 1 

— , 

а подробное 

описание показано на Рисунок 

2 — . 

7.1.4

 

Процессы  СОД  (CDE)  также  гарантируют,  что  информация  генерируется 

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

 

7.1.5

 

Процессы  СОД  (CDE)  обеспечивают  постоянное  обновление  и  дополнение 

информации для дальнейшего использования на этапе эксплуатации строительного объекта 

(FM). 

7.1.6

 

СОД  (CDE)  может  быть  предоставлен  одним  из  подрядчиков  (например, 

генеральным  подрядчиком)  в  рамках  основного  договора.  В  качестве  альтернативы  и, 
возможно, более правильно, если СОД (CDE) будет

 

предоставляться и управляться самим 

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

 

(CDE) для внутреннего пользования или управления активами.

 

7.1.7

 

СОД  (CDE)  может  представлять  собой  различные  виды  систем:  от  базовой 

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

, 

предоставляющего  сервисы  посредством  глобальной 

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

 

7.1.8

 

Специализированные  решения  для  СОД  (CDE)  могут  иметь  такие 

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

 

7.1.9

 

Выбор  СОД  (CDE)  может  определяться  бюджетом  и/или  тем,  насколько 

доступной должна быть информация. 

 

7.1.10

 

Существует несколько сценариев использования СОД (CDE):

 

а)

 

Специализированная  дисциплина 

– 

СОД  (CDE)  внедряется  в  проектной 

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

; 

б)

 

Междисциплинарное взаимодействие (физически размещены в одном месте) 

– 

для 

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

; 

в)

 

Многодисциплинарное и много

-

проектное взаимодействие (физически размещены 

в одном месте) 

– 

управление специализированными проектными отделами, размещенными 

физически в одном месте, в рамках множества проектов

; 

г)

 

Многодисциплинарное и много

-

проектное взаимодействие (физически размещены 

в различных местах) 

- 

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

проектной среде через сеть Интернет или VPN 

- 

виртуальная проектная среда.

 

Примечание 

– 

На Рисунок 1 

— 

показан функциональный вид верхнего уровня СОД 

(CDE). 

В таком 

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

находятся в одном месте.

 

СП РК 1.02

-115 2018 

8 

Рисунок 1 

— 

 

Среда общих данных верхнего уровня

 

СП РК 1.02

-115 2018 

9 

7.1.11

 

К преимуществам использования данного вида СОД (CDE) можно отнести:

 

а)

 

право собственности на информацию остается у автора информации, несмотря на 

общий доступ к этой информации и её повторное использование;

 

б)

 

общая информация сокращает время и затраты при подготовке скоординированной 

информации; а также

; 

в)

 

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

моделей.

 

 

Функциональные разделы

 

СОД (CDE)

 

7.2.1

 

Основные положения

 

7.2.1.1

 

В  настоящем  своде  правил  рассматриваются  сценарии  использования  СОД 

(CDE) с двухмерными (2

D

) и трёхмерными (3

D

) проектными представлениями моделей.

 

7.2.1.2

 

Сценарии  использования  СОД  (CDE)  не  ограничиваются  работой 

исключительно с графической информацией. 

 

7.2.1.3

 

СОД (CDE)

 

используется для хранения различного вида информации.

 

7.2.1.4

 

В СОД (CDE) используется четыре области, и три контрольные точки, которые 

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

2 — ): 

а)

 

Из  области  «В  работе»  в  область  «В  общем  доступе»  посредством  проверок  и 

утверждений;

 

б)

 

Из области «В общем доступе» в область «Опубликовано» посредством процедуры 

авторизации;

 

в)

 

Из области «Опубликовано» в область «Архив» посредством повторных проверок.

 

7.2.2

 

В работе

 

7.2.2.1

 

Область «В работе» используется непосредственно членами проектного отдела 

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

 

7.2.2.2

 

Процессы управления, применяемые в больших проектах, используются и для 

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

 

7.2.2.3

 

Проектные  отделы  сами  отвечают  за  качество  информации  в  области  «В 

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

7.2.2.4

 

Каждый файл модели должен содержать только ту информацию, за которую 

отвечают те или иные проектировщики.

 

7.2.2.5

 

К  проектным  отделам  относятся  также  субподрядчики,  нанимаемые 

проектными организациями.

 

СП РК 1.02

-115 2018 

10 

7.2.2.6

 

Информация из САПР может быть разбита на ряд моделей. Например, файл 

2D-

модели  может  содержать  ряд  слоев,  которые  представляют  собой,  например, 

координатную сетку, колонны или стены, как показано на Рисунок 

3 — . 

7.2.2.7

 

В  случае  3D

-

моделей  информация  описывается  на  уровне  объектов  или 

элементов, которые представляют собой, например, колонну, стену, дверь или окно.

 

7.2.2.8

 

Внутри  системы  управления  областью  «В  работе»  должен  обеспечиваться 

контроль версий для каждого обновления файла данных. 

 

7.2.2.9

 

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

минорных версий в виде последовательности чисел, например. 1.1, 1.2, 1.3 и т.д., где первая 
цифра  является  старшим  номером  версии  документа  (мажорная  версия),  а  вторая  его 
вспомогательным номером (минорная версия). 

 

7.2.2.10

 

Для  данных,  которые  все  еще  находятся  в  предварительных  проектных 

итерациях,  следует  использовать  буквенно

-

цифровую  нумерацию,  обозначающую 

редакцию (ревизию), например, 

P1.1, P1.2, P

1.3 и т.д.

 

Примечание 

– P 

в данном случаем может означать, например, стадию П

. 

7.2.2.11

 

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

 

другой группе проектировщиков

 

в область «В общем 

доступе», инкрементируется старший номер версии документа, например, 

P

1 до 

P2, P

2 до 

P

3  и  т.д.  Далее  работа  продолжается  уже  с  новой  версией  документа,  и  нумерация 

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

P2.1, P

2.2 и так до следующей передачи в общий доступ.

 

7.2.2.12

 

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

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

 

7.2.2.13

 

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

типов данных, хранящихся в СОД (CDE).

 

СП РК 1.02

-115 2018 

11 

Рисунок 2 

— 

 

Развернутая схема СОД (CDE)

 

СП РК 1.02

-115 2018 

12 

Примечания

 

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

 

1

 

Область  «В  общем  доступе» 

- 

работа  с  мажорными  версиями  документов.  Версия  P1  в  данном 

примере является последней версией документа, начавшем свой путь в области «В работе» с версиями P1.1, 
P1.2 и т.д. На данном этапе создатель информации является единственным, кто может ею управлять, изменять 
или удалять. Для определения, каким образом информация может использоваться в СОД (CDE) на различных 
этапах работы следует использовать обозначения статуса. В области «В работе» используются следующие 
обозначения:

 

а)

 

 

S1  - 

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

статус назначается исключительно моделям.

 

б)

 

S2  - 

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

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

 

в)

 

S3 - 

Выпущено для внутреннего аудита и комментариев. Документы с таким статусом должны быть 

проверены перед выдачей заказчику. 

 

г)

 

S4  - 

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

заказчику для согласования.

 

2

 

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

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

EIR

). Моделям в области «В работе» присваивается статус S0 (исходные данные)

. 

3

 

Область  «В  работе».  Данная  область  содержит  минорные  версии  рабочих  документов  с 

соответствующей  нумерацией,  начиная  с 

P

1.1  с  последующей  инкрементацией  вспомогательного  номера: 

P1.2, P

1.3 и т.д. 

 

4

 

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

попадании  документа  в  область  «Опубликовано»  он  получает  новую  буквенно

-

цифровую  нумерацию, 

например, 

A, B, C 

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

документом  и  является  источником  информации  для  ревизии  со  стороны  заказчика.  Это  не  означает,  что 
документы  готовы  для  использования  на  строительной  площадке,  если  только  ему  не  присвоен  статус  A. 
Документам, отправленным заказчику для предварительного согласования, присваивается статус D:

 

а)

 

D1 – 

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

– 

юридический документ

; 

б)

 

D2 – 

Выпущено для тендера 

– 

юридический документ

; 

в)

 

D3 – 

Выпущено для проектирования подрядчиком 

– 

юридический документ

; 

г)

 

D4 – 

Выпущено для производства/закупок 

– 

юридический документ

. 

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

на  запросы  заказчика  к  главному  инженеру  (архитектору)  проекта.  Документы  с  таким  статусом  не 

предназначены

 

для строительства или применения в качестве конструкторских решений. Такие документы не 

подписываются

 

заказчиком и не попадают в область «В общем доступе», а передаются напрямую заказчику

.  

Документы, подписанные заказчиком, имеют следующие обозначения статуса:

 

д)

 

A – 

Выпущено для строительства. Без замечаний.

 

е)

 

B – 

Частично завизировано с замечаниями. Для строительства с незначительными замечаниями со 

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

 

ж)

 

AB – 

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

СП РК 1.02

-115 2018 

13 

 

Рисунок 3 

— 

 

Пример архитектурной модели в области «В работе»

 

7.2.3

 

В общем доступе

 

7.2.3.1

 

Модели, готовые к выпуску для согласования, следует загружать в раздел СОД 

(CDE)  «В  общем  доступе»  со  статусом  «выпущено  для  согласования»,  как  показано  на 
Рисунок 

4 — . 

7.2.3.2

 

Чтобы иметь возможность перемещать информацию в эту область, все файлы 

моделей  следует  тщательно  проверить

 

и  утвердить  со  стороны  главного  архитектора 

(инженера) проекта. 

 

7.2.3.3

 

Рекомендуется обеспечить соответствие файлов моделей  стандарту  ТИМСО 

или САПР в рамках проекта.

 

7.2.3.4

 

Общий  раздел  СОД  (CDE) 

- 

это  область,  где  информация  может  быть 

предоставлена третьим лицам в «безопасной» среде. 

 

7.2.3.5

 

Своевременная

 

разработка

 

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

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

 

7.2.3.6

 

Информационный  статус  определяет  право  собственности  на  данные 

проектировщика и ограничивает доступ к ним непосредственно строителей до тех пор,

 

пока 

информация не будет скоординирована и авторизована (со стороны заказчика). 

 

7.2.3.7

 

Описание  каждого  статуса,  приведено  в  Таблица  8 

—   

раздела 

8.4.10 

настоящего свода правил. 

 

7.2.3.8

 

Следует  обратить  внимание,  что  «информационные  статусы»  и  статусы 

авторизации заказчика / строительства «A», «B» или «C» имеют разное назначение. 

 

СП РК 1.02

-115 2018 

14 

7.2.3.9

 

Данные,  опубликованные  со  статусом  «

S1  - 

Выпущено  для  согласования», 

следует передавать

 

в родном формате ПО САПР, например, 

DWG 

или 

DGN

, как и файлы 

2D 

или 3

D 

моделей.

 

7.2.3.10

 

Все данные или информация со статусом 

S

2 и далее 

Sn

, где 

n – 

номер статуса, 

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

DWF,  PLT 

или 

PDF

,  или  если  это  3

D 

модели  соответствующего

 

ПО  САПР,  в 

формате 

IFC  2x3,  IFC4  Add

2 или более новом. Данный процесс можно использовать для 

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

 

Примечание 

– 

Более подробный пример создания файлов моделей смотрите в Приложении Б

. 

7.2.3.11

 

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

версии моделей из общего

 

раздела СОД (CDE) «В общем доступе» в своей рабочей области 

«В работе», как показано на Рисунок 

5 — . 

СП РК 1.02

-115 2018 

15 

Рисунок 4 

— 

 

Выгрузка архитектурной модели в область «В

 

общем доступе»

 

7.2.3.12

 

В случае, если программное обеспечение, имеет отличную от одно

-

файловой 

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

 

СП РК 1.02

-115 2018 

16 

Рисунок 5 

— 

 

Работа с общедоступной моделью

 

7.2.3.13

 

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

которого получатель может наложить свою проектную информацию (см. Рисунок 

6 — )  

Примечание 

– 

Более подробный пример обмена файлами моделей см. в Приложении В

 

СП РК 1.0

2-115 2018 

17 

Рисунок 6 

— 

 

Междисциплинарная координация модели / файлов модели

 

7.2.3.14

 

Следует  ссылаться  на  файлы  моделей  в  тех  случаях,  когда  ПО  позволяет 

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

 

7.2.3.15

 

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

специалистами  проектного  отдела  (см.  Рисунок

  7  —  ), 

следует  убедиться,  что  это  не 

СП РК 1.02

-115 2018 

18 

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

- 

например,  в  слоях  2

D-

моделей  или 

объектах в 3

D-

моделях. 

 

7.2.3.16

 

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

правила, которые обеспечат создание

 

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

 

Примечание 

– 

Более подробный пример совместной работы с файлами моделей см. в Приложении Г.

 

СП РК 1.02

-115 2018 

19 

 

Рисунок 7 

— 

 

Загрузка конструкторской модели в общую область

 

СП РК 1.02

-115 2018 

20 

Примечание 

– 

В  данном  примере,  инженер

-

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

элементов  и,  тем  самым,  стал  собственником  структурного  слоя  колонн.  Когда  инженер

-

конструктор 

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

 

пересмотреть и повторно 

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

— ). 

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

передачи права собственности смотрите в Приложении Д.

 

 

Рисунок 8 

— 

 

Удаление архитектурных колонн

 

7.2.3.17

 

На Рисунок 9 

—  

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

модели.

 

7.2.3.18

 

Руководители  проектных  отделов  обеспечивают  контроль  темпов 

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

 

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

 

7.2.3.19

 

Управление  процессом  создания

 

информации  необходимо  производить 

посредством  утвержденного  вспомогательного  плана

-

графика  или  ведомости  основных 

документов проекта (см. Приложение А)

 

СП РК 1.02

-115 2018 

21 

 

Рисунок 9 

— 

 

Процесс загрузки и использования моделей

 

СП РК 1.02

-115 2018 

22 

 

Рисунок 10 

— 

 

Создание чертежей с общих моделей