Прежде, чем ответить на данный вопрос, определимся зачем вообще нам это делать.
Основной проверкой, имеющей глобальное значение на практике, является проверка 3D-модели на коллизии или простым языком проверка на пересечения. Этими пересечениями могут быть и пересечения инженерных коммуникаций, и просто недопустимые вещи, которые бывает тяжело проверить на этапе проектной документации, если плохо развито пространственное мышление. Как правило, людям, долгое время работавшим в 2D, тяжело это делать, ведь нужно заранее учитывать и держать в голове отметки заложенных коммуникаций и, желательно, не только своих, но и отметки коллег смежных разделов, чтобы избежать ошибок на стройке.
К недопустимым коллизиям может, например, относится пересечение инженерных сетей и капители колонны, которые при большом количестве приводят к потере несущей способности всего здания в целом. Именно такие ошибки являются самыми дорогостоящими по их устранению и увеличивают время, затраченные на их исправление, что приводит к увеличению сроков строительства.
К следующим по значимости я бы отнесла коллизии дублирования, так как они увеличивают стоимость строительства объекта, а ни для кого не секрет, что сейчас большинство организаций оценило быстроту формирования и получения объемов работ именно из цифровой информационной модели.
Так как мы движемся в сторону глобальной цифровизации, то не менее важной становятся проверки на информационную наполняемость. Ведь модель становится точной копией будущего объекта, источником данных по каждому ее элементу и своего рода хранилищем этой информации, поэтому достоверность этих данных важна. Постепенно все идет к общей оцифровке и созданию единого цифрового двойника каждого города России, а затем и страны в целом. Это позволит достаточно быстро выявлять пятна возможной застройки, перспективные области для этого и грамотно вписывать все в окружающую среду, а также управлять городом, именно для этого и будут использоваться информация, полученная из параметров 3D-модели.
Важной целью на сегодняшний день является разработка нормативных проверок, которые смогу проверять технические решения на соответствие нормативно-правовой базе, чтобы снизить процент нарушений на стройке.
Кроме перечисленных выше проверок, есть базовые проверки, касающиеся координации и определения местоположения модели в пространстве и привязок ее элементов.
Чек-лист проверки цифровой информационной модели
1. Координация
Объекты должны иметь привязку к местности и углу истинного севера, с указанием абсолютной отметки, принятую за относительную 0.000 проекта, в Балтийской системе высот.
Координация должна быть обеспечена во всех файлах модели, так как как правило, каждому разделу документации соответствует своя модель, которые затем собираются в сводную
2. Привязка к уровням
Все элементы должны быть привязаны к уровню этажа, на котором они находятся
3. Наименования
Модели, уровни, элементы должны называться единообразно и в соответствии с требованиями, прописанными в техническом задании.
4. Классификация
Все элементы модели должны быть присвоены соответствующему классу и иметь код по классификатору.
Если строящийся объект находится на территории Москвы, то это МССК, если в регионах - КСИ
5. Информационная наполняемость
Все элементы здания должны иметь параметры в том объёме, который устанавливает техническое задание или экспертиза.
6. Коллизии
Должны отсутствовать коллизии, не превышающие допуск, установленный требованиями к разработке модели, как правило, это 80 мм для стадии П и 15 мм для стадии Р.
Так какие же программы существуют на рынке для таких проверок?
Долгое время многие задачи, касающиеся проверок моделей, решал Navisworks от компании Autodesk, где создавались поисковые наборы, включающие в себя категории элементов информационных моделей для каждого раздела проектирования. Затем через функцию Clash Detective выполнялась проверка на пересечения между данными наборами, а также на их дублирование с учетом допусков, также была возможно проверять пересечения по разделам в целом, после чего формировался отчет о проверке.
Сейчас на рынке примерами таких аналогов являются Larix.Manager, Tangl.Control, 7Dmodeler и т.д.
Все они имеют схожий принцип работы: создание рабочих наборов по классам элементов, а затем их проверку.
