4.6.2 Рекомендации к проведению контроля качества

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основной комплекс проверки на пересечения производится в ПО 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. Исправленные – этим статусом автоматически помечаются конфликты, которые были устранены в процессе отработки комментариев.

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

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

Проверки в Navisworks

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

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

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

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

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

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

Проверка в 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 всегда была актуальная информация о модели, которую он доносит до участников проекта на проектных совещаниях.

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

1. Визуальный  анализ принципов моделирования.
2. Проверить Navisworks на количество коллизий.
3. Оценить коллизии и выбрать основные проблемные точки.
4. Фильтрация спецификаций. Необходимо убедиться, что фильтрация не отсеивает часть необходимых элементов.
5. Проверка спецификаций на листах (выделить всё на листах, отфильтровать категорию «Аннотаций», если они есть, проверить не прописаны ли спецификации вручную).
6. Предупреждения: дублирование элементов.
7. Соответствие геометрии и назначенного материала типоразмеру.
8. Наименование материалов.
9. Проверка наименования ссылочных моделей.
10. Проверка мониторинга осей и уровней.
11. Привязка элементов по уровням.
12. Заполнение обязательных параметров:

• Номер корпуса;
• Номер секции;
• Этаж;
• Код по классификатору.

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

1. Проверить правильность заполнения квартирографии.
2. Проверить границы помещений.
3. Проверить отсутствие «Неокруженных помещений».
4. Проверить соответсвие моделирования фасадов решениям принятым в BEP.

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

1. Заполненные параметры «Марка конструкции».
2. Отдельные модели армирования должны быть расположены в координатах на своем месте.
3. Включенная аналитическая модель.
4. Проверить нет ли арматуры, которая некорректно считается в ведомости расхода стали.

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

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

Регламент работы в файле коллизий

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

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

Файл коллизий располагается в папке 00_ПРОВЕРКИ и подпапке 02_ФК.

Ответственным за распределение коллизий для отработки между проектировщиками назначаются DM-AR и DM-ST.

Подготовка файла для работы

1. Настройка файла осуществляется BIM-отделом при старте проекта – ответственный BPM.
2. В файле совместной работы для каждой ссылочной модели необходимо создать отдельный рабочий набор, а загруженные ссылки закрепить – ответственный BPM.
3. Для моделей раздела ИОС подгружаются не модели RVT, а файлы NWC с помощью инструмента «Координационная модель» во вкладке «Вставить».

В файле заранее преднастроены шаблоны видов, фильтры, виды и спецификации с шаблонами (смотри пункты Виды- и Спецификации-шаблоны ). Для удобства работы DD в дальнейшем выполняет дополнительную настройку видов и планов по необходимости.

Процесс работы с файлом

1. Рекомендуется открывать файл с минимально необходимым количеством загружаемых рабочих наборов.
2. Семейство «ТОЧКА КОЛЛИЗИИ» категории «Обобщённая модель» располагается в месте конфликта, который необходимо проработать (смотри Рисунок).
3. При простановке семейства необходимо своевременно занести информацию в параметры.
4. Повторяющиеся (во всех аналогичных характерных местах или от этажа к этажу) замечания допустимо (и рекомендовано) без необходимости не выделять отдельно, а зафиксировать в параметре «ТК_Описание коллизии».
5. Для корректного специфицирования семейство «Коллизии» (далее «ТК» или «Точка коллизии») должно быть привязано к соответствующему уровню, иметь корректно заполненные параметры, находиться в рабочем наборе «Коллизии».
6. В конце строки в поле многострочного текста рекомендуется ставить Enter. Это связано с невозможностью изменения размеров поля (Рисунок – Поле для многострочного текста).

Рисунок – Поле для многострочного текста

7. Разрешено создание собственных фильтров, видов, спецификаций, шаблонов и прочее с занесением в именной раздел , который регулируется автоматически для видов Типом шаблона и параметром «Раздел проекта» для спецификаций.
8. При устранении замечаний в поле «ТК_Назначение элемента» необходимо поменять статус на «Готово», после чего метка окрасится в синий, благодаря преднастроенному фильтру. Перенос семейства в вариант «Готово» осуществляется тем, кто создал замечание, после подтверждения отработки замечания.

Рисунок – Семейство коллизии и заполняемые параметры

По итогу работы в файле коллизий формируется реестр коллизий 1_Спецификация коллизий_архив (смотри пункт Спецификации-шаблоны). Таблица выявленных несоответствий выгружается Заказчику для анализа.

Параметры Точки Коллизии

1. Типоразмер:

• Высокий приоритет (задача срочная и/или способная особенно расстроить коллегу);
• Средний приоритет;
• Низкий приоритет (задача несрочная, не влияющая на окружающие конструкции, а также задачи-уведомления).

2. Марка – параметр обязателен для заполнения, уникальный коллизии (идентификатор проверяется с помощью спецификации 01_Определение марки, где можно отследить уникальность идентификатора).
3. ТК_Назначение элемента – текстовый параметр, обязателен для заполнения:

• «АР» или «АР-USER1» – задача для отдела архитекторов и именная задача для архитектора соответственно;
• «КЖ» или «КЖ-USER1» – задача для отдела конструкторов и именная задача для конструктора соответственно;
• «ИОС» или «ИОС-USER1» – задача для отдела инженеров и именная задача для инженера соответственно;
• «Готово» – коллизия отработана и проверена.

4. ТК_Описание коллизии – многострочный текст, обязателен для заполнения.

Описание коллизии с пометкой «// 201231[1] user1» (разделение, дата заполнения и имя заполняющего) в начале. Параметр заполняется автором в момент размещения семейства в модели.

5. ТК_Принятое решение – многострочный текст, обязателен для заполнения.

Описание итогового решения проблемы с пометкой «// 201231[1] user1» (разделение, дата заполнения и имя заполняющего) в начале). Параметр заполняется по итогу отработки и тем, кто отработал коллизию.

6. ТК_Кто создал – текстовый параметр, обязателен для заполнения.

Имя автора или ответственного за коллизию от стороны автора.

7. ТК_Обсуждение – текстовый параметр, заполняется по необходимости

Обсуждение между участниками с пометками «// 201231[1] user1» (разделение, дата заполнения и имя заполняющего) в начале каждой итерации.

8. ТК_Корпус – текстовый параметр, обязателен для заполнения

Заполняется в формате одной буквы, например, «А» для корпуса А.

Процесс размещения и отработки коллизий

Процесс размещения коллизий в модели представлен на Рисунок — Схема размещения коллизий. А подробный процесс отработки коллизий и коммуникации между разделами отображен на Рисунок — Схема отработки коллизий.

Виды- и спецификации-шаблоны в файле коллизий

Виды в файле коллизий:

1. 3D виды. Разбиты по соответствующим корпусам
2. 3D вид для навигации. Неудобен для работы, позволяет получить представление о расположении ТК в объёме здания
3. 3D вид для работы. Вид для использования инструмента «Рамка выбора» и оценки ситуации.
4. Планы. Разнесены по корпусам. Пометка АР/КЖ/АР+КЖ отвечает за то, ТК с каким Назначением элемента будут отображены на плане.
5. Поэтажные планы

Спецификации в файле коллизий:

1. Спецификация для заполнения параметра «Марка». Позволяет определить последнее использованное значение и быстро заполнить Марку для новых коллизий.
2. Общая спецификация активных коллизий и архив коллизий соответственно.
3. Спецификации для работы с коллизиями для отдела АР.
4. Спецификации для работы с коллизиями для отдела КР

---

[1] «201231» в примере расшифровывается как «31 декабря 2020 года»