Сравнительный анализ функционала API BIM-систем с позиций экономических задач

Введение

В статье рассматриваются результаты анализа существующего состояния программных интерфейсов приложений (API – Application Programming Interface) BIM-систем на основе опыта интеграции с программными продуктами линейки АВС (сметно-экономический раздел строительного проекта).

Работы по интеграции начались в 2012 году с Nemetschek Allplan, так как в его составе уже имелась подсистема BCM (Build Cost Management), ориентированная на немецкую систему ценообразования в строительстве. BCM в то время выступала как один из эффективных примеров совместного решения архитектурно-конструкторских и экономических задач. С расширением круга интегрируемых с АВС BIM-систем стала очевидной необходимость прямого двустороннего взаимодействия с каждой платформой посредством API, и к текущему моменту реализована интеграция с десятью BIM-системами. Этот опыт дал возможность провести сравнительный анализ функционала API BIM-систем по ряду критериев среди таких платформ, как Allplan, Revit, Renga и Archicad. Для BIM-систем, не имеющих открытого API, разработчиками АВС была предложена схема интеграции с использованием собственного API.

Программное обеспечение для BIM

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

• проектирование, расчёты,
• межотраслевая координация и создание сводных моделей,
• поиск пространственных и логических коллизий,
• создание многомерных визуализаций (4-6D),
• подготовка визуализаций и презентаций.

Рис. 1. Спектр программного обеспечения для BIM

Обмен данными между всем имеющимся на сегодняшний день программным обеспечением, как правило, осуществляется с использованием универсальных обменных форматов, таких как IFC, DWG, OBJ, DXF, STEP, IGS, iModels и др [1, 4].

Использование обменных форматов достаточно статично во времени, так как предполагает фиксацию в некотором временном срезе состояния исходной среды с последующим разбором в другой. При изменении исходной среды требуется повторное формирование выгружаемых данных. Вследствие этих недостатков между многими платформами реализовано прямое взаимодействие, реализованное в виде программных надстроек – плагинов. Такие плагины разрабатываются либо одним из производителей программного обеспечения, либо сторонними разработчиками. Помимо этого, существуют и комбинированные схемы, позволяющие использовать оба способа передачи данных [1]. Наличие прямых интеграционных связей между различными программными средами говорит еще и о недостаточности сведений, передаваемых в обменных файлах. Прямое программное взаимодействие позволяет решить вопросы передачи информации более полноценно, так как отраслевые стандарты не всегда успевают своевременно фиксировать в описаниях формата обмена актуальное наполнение данными и реализовывать все возможности технологии информационного моделирования.

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

Примером могут служить многочисленные программные надстройки к проектирующим BIM системам для связи с системами расчёта строительных конструкций, например плагины: ЛИРА-САПР для Revit, SCAD для Tekla и т. п.

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

Автоматизация сметных расчётов в BIM

Вопросом, как связать BIM-модель со сметами и получать стоимость на всех этапах жизни модели автоматически, разработчики и пользователи BIM-систем начали задаваться практически с самого начала появления технологии информационного моделирования. Первые попытки автоматизировать сметные задачи на постсоветском пространстве были сделаны ещё в начале 2000-х годов на платформе Nemetschek Allplan. В то время казалось, что достаточно каждому элементу модели записать в свободное поле шифр сметной расценки и подставить правильный объём из множества предлагаемых системой, и вопрос решён. Тем не менее много лет задача не решалась в силу того, что связь между элементами BIM-модели и сметно-нормативной базой была не такой однозначной, и потребовалось решение, позволяющее алгоритмизировать процесс передачи параметров (атрибутов) в BCM, при этом создавать гибкие наборы правил по применению сметных нормативов как под конкретный проект, так и для универсальных решений для определённых строительных технологий.

Если коротко описать проблему, то можно сформулировать её одной фразой: проектировщики и сметчики живут в разных измерениях и мыслят разными категориями. Проектировщики создают строительный объект в системе моделирования, используя наборы инструментов, представленные в виде проектных категорий – стены, колонны, балки, перекрытия, окна, розетки, кабели, трубы и т.д. Когда дело доходит до стоимостных оценок, то эти же элементы в каких-то случаях начинаются рассыпаться на отдельные материалы, части конструктивов, а в каких-то случаях наоборот, объединяются в единый набор и расцениваются комплексно. Сметчики используют свой набор инструментов, как правило, выраженный в виде систематизированного набора сметных нормативов, сформированных не для законченных конструктивов, а для отдельных видов работ и операций над этими конструктивами. К примеру, изготовление железобетонной монолитной стены на стройке может состоять из десятков различных операций, которые определяются конкретным проектом и могут зависеть от множества параметров такой стены.

Связь с одной из сметных технологий представлена на рис. 2.

Рис. 2. Пример параметрической связи элемента модели со сметной нормой

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

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

В этом кроется ключевое противоречие между системами проектирования и оценки стоимости. На Западе такие противоречия разрешаются в силу того, что системы сметного нормирования имеют не настолько обширную номенклатуру видов работ и зачастую строятся исходя из единых классификационных подходов с этапом проектирования. Примером гармоничного сосуществования проектной и сметной составляющей проекта могут служить системы классификации OmniClass, MasterFormat, UniFormat, DIN 276, DIN277, UniClass и им подобные [2, 3].

В системах строительного проектирования и ценообразования стран ЕАЭС до сих пор не было создано ничего подобного, что позволило бы решать задачи сметного ценообразования на таком же уровне. Причём это характерно как для государственного, так и для корпоративного сектора. Попытки создать классификаторы ведутся, но без пересмотра структуры сметных нормативов и без подчинения системы ценообразования единым классификаторам архитектурно-конструктивных элементов всё будет только усложняться.

Действующая система ценообразования любой из стран ЕАЭС, включая систему Российской Федерации, выдвигает ряд требований к системам информационного моделирования по информационному наполнению элементов. Требования, выдвигаемые системами ценообразования России, Беларуси, Казахстана, Узбекистана, Армении и других стран, использующих в основе структуру сметных нормативов, разработанную в СССР, практически идентичны с очень небольшими точечными отличиями. Поэтому систему информационных требований можно рассматривать как единую для всех стран ЕАЭС.

Информационные требования к элементам моделей

Требования к информационному наполнению элементов BIM-моделей являются ключевым фактором при последующем выборе сметных норм и расценок и определении стоимости строительства [5]. Безусловно, в основе любых требований должна лежать какая-то исходная классификация проектных решений. В своей работе мы выбрали классификацию категорий проектирования BIM-системы Autodesk Revit, как наиболее полную для большинства случаев проектирования зданий и сооружений. Основываясь на этом перечне, успешно решаются задачи по интеграции с любыми другими системами BIM-проектирования, так как категории Revit имеют наиболее общие и понятные всем формулировки.

Пример перечня категорий для архитектурного раздела:

• Потолки
• Двери
• Мебель
• Крыши
• Помещения
• Лестницы
• Стены
• Окна
• Ограждение
• Перила

Пример перечня категорий для конструкторского раздела:

• Несущая арматура
• Несущие колонны
• Каркас несущий
• Фермы
• Вертикальные раскосы
• Горизонтальный раскос
• Фундамент несущей конструкции
• Несущие стены

Пример перечня категорий для инженерных разделов:

• Кабельные лотки
• Шкафы
• Короба
• Воздуховоды
• Воздухораспределители
• Электрооборудование
• Гибкие трубы
• Осветительные приборы
• Арматура трубопроводов
• Трубы
• Соединительные детали трубопроводов
• Сантехнические приборы
• Провода

Аналогичные понятия или близкие к ним присутствуют практически в каждой BIM-системе, поэтому сформулированные информационные требования можно распространить на любую платформу и применять на всех этапах жизненного цикла строительства, которые требуют выполнения стоимостных оценок [6].

Информационные требования были сформулированы на основе данных анализа системы сметных нормативов всех стран ЕАЭС и выражены в виде списка параметров с указанием единиц измерения. Пример требований к категории проектирования «Стены» приведён в таблице 1.

Таблица 1

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

К примеру, часть правил определения объёмов работ по возведению конструкций из кирпича и блоков выглядит так:

2.7 Из объёма кладки стен из кирпича с воздушной прослойкой объём последней не исключается.

2.8 Объём кладки стен из кирпича с утеплением с внутренней стороны теплоизоляционными плитами определяется без учёта толщины плиты утеплителя.

2.9 Объем работ по устройству перегородок следует исчислять по проектной площади за вычетом площадей проемов по наружному обводу коробок.

2.10 Объём работ по расшивке швов определяется по площади расшиваемых стен без вычета площади проёмов.

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

Возможности API BIM-систем по извлечению параметров

Практически каждая проектирующая BIM-система позволяет сегодня решать задачи расширения функционала с использованием встроенных средств для разработчиков. Такой функционал имеет общее название – API (Application Programming Interface) или программный интерфейс приложения. Фактически API создаётся для того, чтобы можно было решать любые задачи, которые невозможно напрямую решить с использованием стандартных средств программы или с использованием обменных форматов в другом программном обеспечении. Возможности API BIM-систем достаточно широки и в первую очередь ориентируются, конечно же, на решение повседневных задач, связанных с проектированием. Важной составляющей взаимодействия с элементами модели как через интерфейс программы, так и через средства API является получение существующей и генерация новой атрибутивной информации, помещаемой в информационную модель. К примеру, вычисление площади подоконной доски для окна, вставленного в проём стены, является результатом вычислений, основанных на геометрических параметрах как самого окна, так и стены, в котором оно находится. Вычисленное значение может быть внесено в элемент модели в виде нового значения либо храниться в элементе в виде параметрической формулы.

Опираясь на созданный ранее перечень информационных требований, авторы провели объёмную работу по созданию программных инструментов для извлечения всех необходимых параметров из элементов моделей с использованием API наиболее популярных BIM-систем. В ходе решения этой непростой задачи многие параметры, явно отсутствующие в элементах модели, приходится вычислять с использованием различных функциональных возможностей и математических операций. В некоторых случаях авторы столкнулись с невозможностью получения параметров ни одним из способов. В таком случае в перечне информационных требований для данной BIM-системы параметр помечался как «пользовательский», т.е. перед специалистом, создающим BIM-модель, ставится задача по внесению такого параметра вручную.

На сегодняшний день разработчиками сметной системы АВС проведена работа по интеграции с десятью BIM-платформами [7], из которых можно выделить четыре наиболее популярные в странах ЕАЭС: Nemetschek Allplan, Graphisoft Archicad, Renga и Autodesk Revit. Ежедневная работа по совершенствованию алгоритмов и инструментов сметчиков для работы с BIM-моделями позволила провести сравнительный анализ по насыщенности параметрами элементов, возможностям функций API по вычислениям и извлечению необходимых для сметчиков сведений. Пример такого сравнения по категории проектирования «Стены» приведён в таблице 2.

Таблица 2

Зелёным цветом и знаком «+» отмечены те параметры, которые извлекаются из элементов модели напрямую с использованием стандартной функции API соответствующей BIM-системы без проведения дополнительных вычислений.

Жёлтым цветом и знаком «*» отмечены те параметры, которые не могут быть извлечены стандартными методами API, но могут быть вычислены на основании геометрии элемента либо вычислены на основе других имеющихся параметров элемента путём сложения, умножения, вычитания, деления или применения коэффициента.

Красным цветом и знаком «-» отмечены те параметры, которые могут быть извлечены из элемента только в случае их внесения в элемент пользователем в явном виде. Такие параметры чаще всего стараются внести в элементы модели на этапе создания библиотек элементов, так как ручной ввод этой информации в проект является достаточно трудоёмким процессом.

Наличие большого количества вычисляемых параметров (жёлтого цвета) создаёт значительную нагрузку на ресурсы компьютера при обработке большого объёма проектных данных, что, конечно, не так существенно, как нагрузка на специалистов, подготавливающих модель, но всё-таки по сравнению с другими BIM-системами является негативным фактором. Кроме этого, необходимость проведения дополнительных вычислений усложняет разработку программных инструментов и увеличивает время разработки.

Различная информационная насыщенность по разным категориям проектирования перекликается с распространённостью определённых BIM-систем при решении различных задач. К примеру, традиционно сильной стороной системы Archicad является архитектура, сильной стороной Allplan является железобетон, а сильной стороной Revit являются внутренние инженерные системы. Похожую картину мы видим и при работе с API этих BIM-систем. Информационная насыщенность категории «Трубы» представлена в таблице 3.

Таблица 3

Для формирования общей картины по средней насыщенности API BIM-платформ был проведён комплексный анализ по всем ключевым категориям и выведены средние значения по разделам проектирования.

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

Рис. 3. Средняя насыщенность API по архитектурному разделу

Средняя насыщенность показывает, что наибольшее количество встроенных и вычисляемых параметров имеет система Renga. Несмотря на то что некоторые параметры приходится вычислять, применение этой системы для архитектурного проектирования создаст наименьшую нагрузку на проектные подразделения по наполнению элементов информацией. Система Revit в целом находится на том же уровне насыщения, но за счёт более высокой нагрузки на вычислительные ресурсы компьютера. Системы Archicad и Allplan схожи в этой части и по большей части тоже удовлетворяют требованиям по информационному наполнению для решения сметных задач.

При анализе конструкторского раздела смещение в сторону лидерства системы Renga ещё более явное. Диаграмма насыщенности по этому разделу представлена на рис. 4. Эта система предлагает извлекать в явном виде такое же количество параметров, что и Allplan, но при этом позволяет немного больше вычислить, разгружая тем самым проектировщиков. Тем не менее, в этом разделе Allplan отстаёт незначительно, а системы Revit и Archicad предлагают решать вопросы получения сметной атрибутики за счёт ресурсов компьютера либо за счёт ресурсов человека.

Рис. 4. Средняя насыщенность API по конструкторскому разделу

Анализ насыщенности параметрами по инженерным разделам полностью меняет картину. На рис. 5 показана диаграмма, из которой следует, что лидером является Revit.

Рис. 5. Средняя насыщенность API по инженерным разделам

Явное отставание системы Renga от всех остальных объясняется тем, что инструменты для создания инженерных разделов появились в ней совсем недавно. Системы Archicad и Allplan, безусловно, позволяют решать и эти задачи, но ценой нагрузки на вычислительные ресурсы. Авторы отмечают широкое применение для создания инженерных разделов именно системы Revit, что подтверждает вывод о более глубокой проработке не только инструментов API, но и инструментов для разработчиков по этим разделам.

Выводы

Любое сравнение, конечно же, является в какой-то мере субъективным и основывается на принятых для сравнения критериях. Субъективность нашего подхода кроется, в первую очередь, в направленности на ценообразование и сметное нормирование. Оценки не претендуют на всеобъемлющие и комплексные оценки BIM-систем и соответствуют текущему времени. Выведенные средние показатели демонстрируют степень насыщенности параметрами и инструментами именно API, что иногда не строго соответствует возможностям BIM-системы по решению этой же задачи стандартными средствами проектировщика. Тем не менее картина отражает текущее состояние возможностей API BIM-систем и позволяет спрогнозировать трудоёмкость создания сметного раздела строительного проекта в той или иной системе с использованием средств автоматизации.

Инструменты АВС для BIM в полной мере используют все имеющиеся возможности API всех представленных BIM-систем. Разработанная методология, в основе которой лежит систематизированный набор информационных требований по категориям проектирования, позволяет решать задачи по извлечению необходимых параметров практически одновременно во всех системах. Изменения в системе сметного нормирования, правилах исчисления объёмов работ находят отражение и в способах извлечения параметров элементов BIM-модели. Постоянный контакт разработчиков АВС с разработчиками многих BIM-систем способствует непрерывному совершенствованию и развитию инструментов и алгоритмов API BIM-систем.

Литература

1. M. Wijayakumar, H.S. Jayasena. Automation of BIM Quantity Take-Off to suit QS’s requirements // Department of Building Economics, University of Moratuwa, Sri Lanka. The Second World Construction Symposium 2013: Socio-Economic Sustainability in Construction. 14 – 15 June 2013, Colombo, Sri Lanka, p. 70-80.
2. Song Wu, Gerard Wood, Kanchana Ginige, Siaw Wee Jong. A technical review of BIM based cost estimating in UK quantity surveying practice, standards and tools // Journal of Information Technology in Construction - ISSN 1874-4753 ITcon Vol. 19 (2014), Wu et al., pg. 534.
3. Dr. Peter Smith. BIM & the 5D Project Cost Manager // Procedia - Social and Behavioral Sciences 119 ( 2014 ) p. 475 – 484.
4. Daniel Forgues, Ivanka Iordanova, Fernando Valdivesio, Sheryl Staub-French. Rethinking the Cost Estimating Process through 5D BIM: a Case Study // Materials of Construction Research Congress 2012 © ASCE 2012, p. 778 – 786.
5. Воронин И.А., Изатов В.А., Пурс Г.А. Требования технологий информационного моделирования к сметно-нормативной базе Республики Беларусь. Строительство и ценообразование №3 (47). Минск, 2021 г.
6. Воронин И.А., Изатов В.А., Пурс Г.А. Ценообразование и технология информационного моделирования в строительстве на этапах жизненного цикла строительной продукции. Строительство и ценообразование №2 (30). Минск, 2019 г.
7. Автоматизированные интеллектуальные экспертные системы экономики строительства в работе BIM-систем. Шершнёв А.В., Пурс Г.А., Изатов В.А., Воронин И.А. Материалы международной научно-практической конференции БНТУ "Информационные технологии в технических, правовых, политических и социально-экономических системах". Минск, 2017 г.