2.1 Система контроля качества

Процесс инициирования проверок

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

1. Базовый перечень проверок определяется на этапе формирования графика проектирования (смотри Рисунок – Схема проверок по графику в течение разработки проекта).
2. Допускается (приветствуется) инициирование локальных проверок со стороны DM. В таком случае DM направляет запрос на проверку BPM. Перед формированием запроса на проведение проверки в BIM отдел, DM должен убедиться, что DD произвели самостоятельную проверку заполненности параметров внутренними инструментами Revit или с помощью DSM. Запрос оформляется в соответствии с внутренним стандартом коммуникации (схема инициализации и процесса проверок представлена на Рисунок – Схема инициализации и процесса проверок).

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

На Рисунок – Схема проверок по графику в течение разработки проекта представлена графическая схема процесса проведения проверок на жизненном цикле проекта. Верхняя часть схемы описывает проверку на геометрические коллизии, нижняя — на соответствие BIM стандарту. Даты проведения проверок определяются датами, закрепленными в графике проектирования. Дата, определенная графиком, соответствует дате окончания проверки, когда все замечания и коллизии устранены. Проверку рекомендуется инициировать за 2-3 дня до наступления зафиксированной в графике даты.

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

Проверка на соответствие BIM стандарту (заполнение параметров БОС входит в неё) в полном объеме проводится BPM, комментарии на отработку выдаются в соответствии с графиком в дату BIM проверки. К моменту старта проверки, DD должны провести самоконтроль заполненности обязательных параметров внутренними инструментами Revit.

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

При финальной проверке BPM:

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

Файлы взаимодействия и отчётности

• Для любой проверки должна создаваться задача в корпоративном таск-менеджере, где отражается , кто запустил проверку, кто ее проводит или отрабатывает комментарии. Соответствующая задача создаётся BPM при старте очередной проверки, используется для передачи замечаний DM и отслеживания статуса исправлений;
• файл NWF – изменяемый файл проверок, в который BPM загружает файлы NWCи в котором настраивает проверки; DM/DD распределяет ошибки по статусам проверок и отрабатывает критичные коллизии;
• файл NWD – неизменяемый файл отчёта проверки (принцип наименования смотри пункт «Правила наименования»), который сохраняется BPM перед выдачей замечаний для DM/DD;
• файл коллизий сводной модели RVT – изменяемый файл, внутри которого происходит кросс-дисциплинарное взаимодействие DM/DD (подробнее смотри раздел «Регламент работы в файле коллизий»). Необходимость использования файла коллизий на проекте определяет BPM совместно с другими участниками проектирования;
• файл контроля качества в формате Google-таблиц – формализованный перечень проверяемых элементов / категорий на соответствие BIM-стандарту.

Типы проверок

Существует 2 основных типа проверок:

• На коллизии – проводит DM/DD, контролирует BPM.

Проверки на коллизии проводятся в среде Autodesk Navisworks в соответствии с Матрицей коллизий (смотри Таблица — Матрица коллизий ).

BPM создает задачу в корпоративном таск-менеджере, организует инфраструктуру на старте проекта для проверки на коллизии и предоставляет файлы DD/DM. В частности, перед проверками BPM:

• настраивает .bat файлы для автоматической выгрузки моделей в формате .nwc,
• создает файлы сборок .nwf 
• импортирует в файл шаблонные проверки и поисковые наборы (смотри Таблица — Список проверок) и поисковые наборы (смотри Таблица — Поисковые наборы ).

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

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

Цикл проверок осуществляется в следующем порядке:

1. DD предварительно проверяет и устраняет внутренние замечания Revit.
2. В NavisWorks DM/DD создает группы коллизий и присваивает коллизиям статус (описание статусов смотри пункт «Статусы»), определяющий, являются ли коллизии критичными или нет (смотри пункт «Список некритичных пересечений»).
3. DD исправляет коллизии в ПО Revit. При отработанных коллизиях доносит информацию до BPM.
4. BPM проверяет исправлены ли все коллизии. В случае, если при обновлении проверок обнаруживаются конфликты в статусе «активно», модель возвращается на отработку DD.

Подробную инструкцию по работе с Navisworks смотри пункт «Инструкция по работе с Navisworks Manage»

• На соответствие BIM-стандарту – проводит BPM, отрабатывает DD.

Проверки на BIM-стандарт проводятся в Autodesk Revit при помощи встроенных инструментов – спецификации, настроенные 3D-виды, а также при помощи плагинов Экосистемы DS. В процессе проверок формируется отчёт, который передаётся проектировщику для ознакомления и исправления ошибок. Все ошибки, указанные в отчёте, обязательно должны быть исправлены проектировщиком. DD в отчёте должен с указанием даты поставить актуальный статус для каждого замечания.

С перечнем пунктов проверки на BIM-стандарт можно ознакомиться в пункте Чек-лист проверки соблюдение BIM-стандарта.

Настройка видов для проверок

Вид (шаблон вида) Navisworks

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

В рамках проверок необходим визуальный анализ адекватного наполнения 3D вида. Также соблюдаются требования:

• включены все рабочие наборы
• выключены все связи
• отсутствуют фильтры
• все категории включены, в том числе вложенные, кроме:
  • уровни
  • формы
  • подкатегория эргономика для мебели, сантехнических приборов
  • Выключение отдельных категорий фиксировать в BEP

Вид (шаблон вида) BIM360

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

В рамках регулярной проверки необходим визуальный анализ адекватного наполнения 3D вида. Также соблюдаются требования:

• выключены все связи
• включены все рабочие наборы, кроме РН для вспомогательных элементов (включая _USER);
• включены все категории, кроме:
  • эргономика мебели
  • эргономика оборудования
• отсутствуют фильтры

Оба вида, Navisworks и BIM360, публикуются в BIM360.Оба вида, Navisworks и BIM360, публикуются в BIM360.

Процесс работы при проверках в Navisworks

Основной комплекс проверки на пересечения производится в ПО Navisworks через инструмент clash detective. Файлы проверок и отчётов располагаются согласно структуре папок проекта (структур папок смотри раздел «Состав рабочей папки проекта»). Для работы используются три формата – NWF, NWC, NWD.

• Файл формата NWC – файл, в котором модель экспортируется из Revit. При очередной проверке / экспорте информации из Revit старый файл данных должен быть перезаписан. Все выгруженные файлы такого формата подгружаются в файлы формата NWF;
• файл формата NWF – формат файла, который сохраняет в себе пути к экспортированным из Revit моделям формата NWC, точки обзора и отчёты о проверках. Является рабочим файлом, в котором производятся проверки на пересечения. От проверки к проверке файл не меняется, внутри него обновляются только выгруженные NWC;
• файл неизменяемого формата NWD – информация в этом файле не может быть изменена, поэтому используется как файл-архив или файл-отчёт. Создаётся после выдачи результатов каждой проверки и именуется в соответствии с правилами наименования (смотри пункт «Правила наименования» ).

Важно: по завершении проверки и перед выдачей комментариев на отработку BPM сохраняет результаты проверки в неизменяемом формате NWD и присваивает ему имя в соответствии с правилами наименования (смотри пункт «Правила наименования»). После отработки комментариев модель ещё раз перепроверяется и, в случае выявления неотработанных комментариев, выдаётся новый перечень коллизий. Так происходит до тех пор, пока не будут отработаны все коллизии.

Статусы

При устранении комментариев необходимо учитывать логику статусов конфликтов:

1. Создать – этот статус имеют конфликты, выявленные в текущей проверке.
2. Активные – этот статус имеют конфликты, выявленные при предыдущих проверках и не отработанные до текущей проверки.
3. Проверенные – этим статусом помечаются конфликты, которые будут устранены при следующих проверках. ВАЖНО: статус «проверенные» для конфликта назначает только DM (или DD, отрабатывающий комментарии).
4. Подтверждённые – этим статусом помечаются конфликты, которые по своей сути не являются ошибками, список некритичных пересечений располагается в разделе «Некритичные пересечения». Этот статус для конфликта может присвоить как BPM, так и DM (DD), который отрабатывает комментарии.
5. Исправленные – этим статусом автоматически помечаются конфликты, которые были устранены в процессе отработки комментариев.

При финальной проверке моделей (АР-КР-ИОС) все ранее присвоенные конфликтам статусы (Проверенные, Подтверждённые) обнуляются до статуса «Создать» или группируются в одну группу внутри статуса и заново перепроверяются. Это необходимо сделать, чтобы исключить возможность присваивания конфликту неверного статуса. Такое правило обнуления статусов и перегруппировки не применяется при локальной проверке модели.

Проверки на дублирование

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

• при старте разработки проекта и после выдачи первого задания – дублирование несущих стен, колонн и перекрытий в архитектурном и конструктивном разделах. Все дублирующиеся элементы модели разделяются по соответствующим рабочим наборам, например в КЖ РН «Вспомогательные элементы». Впоследствии дублирующиеся элементы удаляются из моделей: все несущие конструкции, а также окна и двери, для которых они являются основой располагаются в моделях КР;
• дублирование лестничных маршей в разделах АР и КР;
• дублирование сантехники в разделах АР и ИОС. Сантехнические приборы в моделях АР располагаются условно для уточнения по месту подключения в моделях ИОС ;
• допускается дублирование финишной отделки в разделах АР, АИ;
• допускается дублирование оконечного инженерного оборудования в разделах АР, АИ;
• допускается дублирование оборудования ОВ/ВК в моделях разделов ЭОМ/СС. В данном случае необходимо проконтролировать исключение данного оборудования из спецификаций моделей ЭОМ/CC.

Все дублирования описываются в BEP.

Проверки эвакуационных путей

Проверки в Navisworks

В соответствии с «СП 1.13130.2020 Системы противопожарной защиты. Эвакуационные пути и выходы» предъявляются требования к эвакуационным путям (смотри Таблица – Пример требований к эвакуационным путям жилых зданий). Для автоматической проверки соответствия требованиям, созданы проверки в Navisworks по эргономике и специальные типоразмеры ограждений, которые необходимо расставить по эвакуационным путям.

Также разработана система проверки высоты паркинга от чистого пола до выступающих инженерных конструкций в соответствии с «СП 113.13330.2016 Стоянки автомобилей. Актуализированная редакция СНиП 21-02-99* (с Изменением N 1)». Для этих целей создана проверка в Navisworks по эргономике и специальный типоразмер перекрытия, который размещается на необходимой высоте.

Для создания корректной проверки в модели заранее необходимо создать пути эвакуации, по следующей схеме:

1. Зайти в рабочий набор АР_Пути эвакуации;
2. Для проверки лестниц и коридоров выбираются соответствующие типоразмеры ограждений. После чего DM создает пути по краю стенки с чистовой отделкой (смотри Рисунок – Эвакуационный путь в ЛК в Revit )
3. Для проверки высоты паркинга создается перекрытие от чистого пола на весь объем помещения;
4. После данной подготовки можно переносить модель в Navisworks и запускать проверки:
5. 25_Эвак. пути_Лестничные клетки (смотри Рисунок – Пересечение эвакуационного пути с лотком );
6. 26_Эвак. пути_Коридор;
7. 27_Эвак. пути_Паркинг.

Данная проверка и подготовка проверки перед выгрузкой в Navisworks – создание путей– проводится перед выдачей задания инженерам непосредственно проектировщиком.

В приведенной ниже таблице указаны требования к эвакуационным путям жилых зданий (класс функциональной пожарной опасности Ф1.3). Остальные типы зданий см. в СП 1.13130 актуальной версии

Проверка в Revit

Для дополнительной проверки путей в паркинге предусматривается отдельная проверка в Revit. BPM настраивает в отдельной директории планы по паркингу (количество планов согласуется с PM/DM), на которых устанавливает зону подрезки в соответствии с необходимой высотой (смотри Рисунок – Планы в Revit для проверки паркинга). Таким образом на планах будут видны пути проезда машин и сети, расположенные ниже критической отметки. Далее PM/DM определяют критичность коллизии и выбирают статус – критично или некритично (смотри Рисунок – Статус коллизии).

Проверочные спецификации и 3D виды

В шаблонах АР и КР разработаны проверочные спецификации и 3D-виды для внутреннего контроля качества.

1. Спецификации располагаются в директории 00_Контроль качества, используются для проверки заполненности параметров (смотри Рисунок – Проверочные спецификации).

Проверочные 3D виды (смотри Рисунок – Проверочные 3D-виды ) делятся на проверки:

1. рабочих наборов (в наименовании есть РН_АР) – на видах отображаются элементы, находящиеся не в своем рабочем наборе, при представлен на Рисунок – Проверка рабочего набора «Двери» (подробнее про рабочие наборы смотри пункт «Рабочие наборы»);
2. корректности заполнения параметров по этажам, секциям;
3. расстановки перемычек.

Проверки задания на отверстия

Перед выдачей моделей заданий на инженерные отверстия DM-MEP необходимо убедиться:

•  в актуальности значений параметра ИНЖ_Отв_Номер_Изм. Для этого необходимо воспользоваться сервисом BIM360 и сравнить две версии модели: последнюю и предпоследнюю;
• в наличии отверстий во всех местах пересечений инженерных сетей с конструкциями.

Проверка на значение итерации выдачи заданий

Последовательность действий:

1. Открыть модель задания в BIM
2. Воспользоваться инструментом Compare
3. Настроить режим сравнения версий.

Важно выбрать правильные версии модели.

4. По окончанию настройки появится окно сравнения двух версий.

1 – окно с информацией об изменениях, произошедших с элементом (активируется при выборе экземпляра);

2 – окно с информацией об изменениях во всей модели;

3 – экспорт отчета в формате CSV.

5. Экспортировать отчёт в формате CSV для удобства анализа в удобную директорию/папку.

Экспортированный отчёт должен открываться с помощью программы «Блокнот». Перед использованием отчета его необходимо обработать.

6. Удаление символов «»» из текста отчета.

 

Для удобства необходимо выделить значения ID элементов запятыми

7. Файл отчета необходимо «Сохранить как» в папке с кодировкой ANSI (с заменой исходного файла).

8. Создать пустой файл Excel и импортировать данные из обработанного файла CSV.

9. На данном этапе сформирован отчет о всех изменениях, произошедших в модели в последнюю итерацию. При любых изменениях в экземпляре необходимо указывать номер последней итерации в значении параметра ИНЖ_Отв_Номер_Изм.

Необходимо в файле Excel оставить только те элементы, чьи значения параметра ИНЖ_Отв_Номер_Изм не редактировались. Для этого каждый столбец таблицы фильтруется по значению в столбце «ИНЖ_Отв_Номер_Изм to 1».

После фильтрации каждого столбца необходимо удалять строки, содержащие значение «ИНЖ_Отв_Номер_Изм to 1»

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

11. Для пакетного обновления значений параметра ИНЖ_Отв_Номер_Изм необходимо использовать инструмент Revit «Выбрать по коду» . Для этого следует объединить все ID элементы в строку через запятую.

12. В таблице Excel создать столбец с запятыми

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

14. Получившиеся значения переносим в Revit, находим все необходимые элементы и назначаем им актуальный номер изменения в параметре ИНЖ_Отв_Номер_Изм.

Модель трассировки инженерных систем

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

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

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

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

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

Промежуточный мониторинг моделей

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

Еженедельные проверки

Общие триггерные точки

• Проверить настройки 3D видов Navisworks и BIM360
  • Выключены все связи
  • Navis — Включены все рабочие наборы
  • BIM360 – Включены все рабочие наборы, кроме РН для вспомогательных элементов (включая _USER)
  • Navis — Включены все категории, в том числе вложенные, кроме Уровни, Формы, Эргономика мебели/сантехники (Выключение отдельных категорий фиксировать в BEP)
  • BIM360 – Включены все категории, кроме эргономики мебели/оборудования
  • Отсутствуют фильтры
• Уровни:
  • Наименование уровней, сравнить с BEP
  • Отсутствие несогласованных уровней
  • Корректное заполнение параметра «Этаж»
• Оси:
  • Все оси под мониторингом и закреплены
  • Нет уведомлений в координации с БФ

• Проверка наименования ссылочных моделей и их рабочие наборы
• Отсутствие несогласованных рабочих наборов
• Визуальный анализ принципов моделирования
• Navisworks:
  • Количество коллизий и занести их в еженедельный отчет по проекту
  • Визуальная проверка на критические коллизии
  • Список моделей, обновляемых через bat-файл, соответствует актуальному списку рабочих моделей

 Каждые две недели

• Наименование материалов.
• Соответствие геометрии и назначенного материала типоразмеру. Выполнить проверку между всеми моделями, включая транслятор.
• Предупреждения: дублирование элементов.
• Привязка элементов по уровням. Проверить через спецификации в сборке
• Заполнение обязательных параметров:
  • Описание;
  • Код по классификатору (999+000+верхний код).
  • Номер корпуса;
  • Номер секции;
  • Этаж;

Триггерные точки АР

• Помещения:
  • Отсутствие неокружённых и неразмещенных помещений
  • Наименование помещений соответствует EIR
  • Высота помещения (Проверить через спецификации)
  • У витражей проставлена граница помещений (Визуальная проверка через 3D вид, включив витражи и границы помещения)
  • Проверить правильность заполнения квартирографии (плагин)
• Проверить соответствие моделирования фасадов решениям принятым в BEP.

Триггерные точки КЖ

• Выключенная аналитическая модель
• Проверить нет ли арматуры, которая некорректно считается в ведомости расхода стали.

Триггерные точки ИОС

• Тип количественных параметров в спецификации НЕ «Текст».
• Соответствие параметра наименования типу элемента.
• Геометрические характеристики элементов не равны нулю.
• На листах не размещены ключевые спецификации.

Реестр замечаний

На старте проекта, в процессе формирования ВЕР, нужно принять решение о методе фиксации замечаний к моделям. В случае, отсутствия со стороны заказчика опыта работы с BIM360 или если процесс обмена происходит на сервере заказчика, создается Google — таблица реестра замечаний. Принятый способ фиксации замечаний фиксируется в ВЕР.

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

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

Наименование реестра: [Шифр проекта]_[Стадия]_[Реестр замечаний по BIM данным]

Пример: 10181_К_Реестр замечаний по BIM данным

В реестре выделяются 4 вкладки:

• АР — комментарии к моделям АР;
• КР — комментарии к моделям КР;
• ИОС — комментарии к моделям ИОС – при необходимости вкладка ИОС множится на разделы (ОВиК, ЭОМ, СС и т.д.);
• Автор — контактный лист BIM-отдела с обеих сторон.

На вкладках с комментариями расположена таблица. Таблицу смотри «EIR_Приложение 09_РЕЕСТР ЗАМЕЧАНИЙ ПО BIM ДАННЫМ».

На каждом листе с комментариями расположена таблица:

Столбцы в таблице для Заказчика:

• №п/п – номер замечания;
• Модель – наименование проверяемого файла;
• Версия модели в BIM360 – указывается версия передаваемого файла из BIM360 в формате «vНомер» Пример: v8
• Автор замечания – пользователь со стороны заказчика, оставивший комментарий;
• Дата выдачи комментария — дата выдачи комментария со стороны заказчика;
• Код по классификатору – используется в случае, когда необходимо выдать замечания к конкретному коду по классификатору;
• Категория – используется в случае, когда необходимо выдать замечания к конкретной категории Revit;
• Комментарий – описывается суть проблемы / замечания;
• Статус заказчика – статус, который присваивает Заказчик после устранения комментария (Принято / Отклонено);
• Статус для BIM – анализ комментария BIM-отделом, столбец определяет стоит ли учитывать данный комментарий на будущих проектах (Учесть в EIR/ Не учитывать)

Столбцы в таблице для Подрядчика:

• Ответ на комментарий – ответ со стороны генпроектировщика / подрядчика на оставленный комментарий, в случае отклонения или уточнения замечания;
• Дата ответа/устранения – дата отработки замечания генпроектировщиком / подрядчиком;
• Статус подрядчика – статус, который присваивает генпроектировщик / подрядчик после устранения проблемы (Исправлено / Отклонено / На паузе);

Порядок внесения замечаний:

1. Комментарий оставляет Заказчик, указывая дату выдачи и суть проблемы. На почту генпроектировщика / подрядчика должно прийти оповещение о занесении пула замечаний в реестр.
2. Генпроектировщик / подрядчик отрабатывает комментарий с указанием даты ответа / устранения, присваивая статус замечанию, а именно отработан ли комментарий или отклонен. После отработки генпроектировщик / подрядчик оповещает Заказчика об отработке комментария.
3. Заказчик проверяет устранена ли проблема и присваивает статус замечанию со своей стороны. Если статус «Отклонено», то генпроектировщик / подрядчик должен заново отработать замечание.