2 - 2022

Технология BIM и сметы


Александр Попов, технический директор SIGNAL

Петр Манин,
к.т.н., эксперт в цифровом строительстве

Отступления

Представленная в статье методология применима к программному обеспечению (ПО) различных разработчиков, в том числе к продуктам, взаимодействующим через формат IFC в рамках OpenBIM. Для используемой терминологии авторы выбирают названия сущностей одного из ПО, однако могут применяться и их эквиваленты. Например, Категория, Семейство и Типоразмер могут в других пакетах иметь названия Слой, Компонент, Стиль и т.п.

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

Исходные данные

Проектная организация разрабатывает полноценный BIM­проект. Требования к информационной модели (далее — ИМ), которую она готовит, включают требования к ее составу и содержанию (элементы и атрибуты для этих элементов, необходимые к моделированию для данной конкретной стадии, например, в рамках BEP). В проектной организации есть BIM­специалист (например, BIM­координатор), который умеет с помощью определенного инструмента проверять ИМ на коллизии, полноту параметров и их дублирование. В этой организации разработан корпоративный классификатор элементов, который помогает описать однозначное обращение к каждому элементу, например, в рамках поиска или выборки. Стандартной разбивки на категории/стили при этом в современных САПР недостаточно: иногда при использовании сортировки по категории отображается совершенно другой строительный элемент из­за особенностей ПО или непреднамеренной ошибки проектировщика.

Итак, организация разработала ИМ, ее элементы заполнены необходимой атрибутивной информацией и кодом по классификатору, из данной модели оформлены чертежи и спецификации (что часто бывает далеко не очевидным) — рис. 1.

Рис. 1. Проверка элементов информационной модели и их атрибутивной информации

Рис. 1. Проверка элементов информационной модели и их атрибутивной информации

Далее BIM­специалист проверяет ИМ на коллизии, наличие необходимых элементов в модели согласно регламенту, дублирующиеся элементы и полноту обязательных параметров. Следующий уровень — проверить формат заполненных значений и их проектную корректность (рис. 2).

Рис. 2. Проверка информационной модели на полноту параметров

Рис. 2. Проверка информационной модели на полноту параметров

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

Классификатор работ при этом берется из структуры WBS (Work Breakdown Structure), в которой ведется бюджет и контролируются сроки по календарно­сетевому плану проекта. В некоторых случаях он может до определенного уровня соответствовать структуре классификатора элементов, но в других вполне может отличаться (рис. 3).

Рис. 3. Пример таблицы маппинга элементов и работ

Рис. 3. Пример таблицы маппинга элементов и работ

Виды работ и сметы

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

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

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

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

Рис. 4. Пример таблицы маппинга сметных позиций и элементов

Рис. 4. Пример таблицы маппинга сметных позиций и элементов

В дальнейшем при проставлении отметки о выполнении работ на строительной площадке (выбор элемента ИМ и указание, что работы выполнены) пользователю выводится окно с выбором той работы, которая привязана к данному элементу и передала объем в сметную позицию (рис. 5).

Рис. 5. Проставление отметки о выполнении работ на строительной площадке

Рис. 5. Проставление отметки о выполнении работ на строительной площадке

Таким способом выполняется привязка статуса работ к сметным позициям (через объемы закрытых элементов ИМ), что позволяет генерировать формы КС­2 и закрывать работы в цифровом виде (без бумаги).

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

Расчет количественных параметров

При подсчете количественных значений можно столкнуться с тем, что у различных элементов эти значения берутся из разных параметров. Это может быть связано с различным способом описания и моделирования элементов: наличия у них системных параметров или индивидуальных параметров проекта, которые вычисляются или автоматически в ПО, или с помощью разработанных плагинов, скриптов по определенным алгоритмам, например с учтенным запасом на усадку или подрезку. Кроме того, проблемы в таких расчетах могут возникнуть, если сводная ИМ или ИМ раздела получена из различного ПО, каждое из которых именует стандартные количественные параметры по­своему.

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

Наиболее стабильным авторы считают подход с реализацией функции сумматора. В нем имеется возможность указания, какие параметры элементов брать при расчете и в каком порядке. Например, в одних элементах нужно брать параметр «объем» из вкладки Объект, параметра -> Объем, а у другого Element -> Volume, у третьего TeklaQuantity -> NetVolume, а у четвертого IfcBaseQuantities -> IfcVolume. Таким образом, из каждого элемента будет взят нужный для расчета объем, а в результате найден корректный суммарный, независимо от того, в каком ПО моделирования была разработана ИМ (рис. 6).  

Рис. 6. Настройки сумматора свойств

Рис. 6. Настройки сумматора свойств

Регистрация | Войти