С появлением цифровых данных в 90-е годы строительная отрасль начала активно трансформироваться. Компьютерные технологии стали внедряться в процессы проектирования, управления и строительства, что привело к появлению таких концепций, как CAD (системы автоматизированного проектирования), PLM (управление жизненным циклом) и, позже, BIM (информационное моделирование зданий).
Однако, как и любые инновации, они не являются конечной точкой развития. Концепции вроде BIM стали важным этапом в истории строительной отрасли, но рано или поздно они уступят место более совершенным инструментам и подходам, которые будут лучше отвечать вызовам будущего.
Поглощённый влиянием CAD-вендоров и запутавшись в сложностях собственной реализации, концепт BIM, появившийся в 2002 году, вполне может не дожить до своего тридцатилетия, подобно рок-звезде, которая ярко вспыхнула, но быстро угасла. Причина проста: запросы специалистов по работе с данными изменяются быстрее, чем к ним успевают адаптироваться CAD вендоры.
Сталкиваясь с нехваткой качественных данных, современные специалисты в строительной отрасли требуют кроссплатформенной совместимости и доступа к открытым данным для упрощения их анализа и обработки. Недостаток данных и их сложность негативно сказываются на всех участниках строительного процесса: проектировщиках, менеджерах проектов, строителях на площадке и, в конечном итоге, на заказчике.
Вместо полноценного набора данных для эксплуатации сегодня заказчик и инвестор получают контейнеры в форматах, которые требуют сложных геометрических ядер, понимания схем данных, ежегодно обновляемой API-документации и специализированного программного обеспечения CAD-BIM для работы с данными. При этом большая часть проектных данных остается неиспользованными.
Этот подход устарел и уже не отвечает требованиям современной цифровой среды. Будущее разделит компании на два типа: те, кто эффективно использует данные, и те, кто уйдёт с рынка.
В этой статье мы рассмотрим как существующий BIM-концепт, включая использование форматов CAD (BIM), IFC и USD, так и альтернативные и будущие подходы к работе с данными и процессами и ответим на ключевые вопросы, которые сегодня интересуют специалистов работающих с данными в строительной отрасли:
Что такое BIM - маркетинг или реальная инновация для строительной отрасли
Почему CAD форматы убивают интероперабельность и концепт BIM
USD против IFC: зачем вендоры навязывают новые форматы?
Почему новые форматы от CAD-вендоров IFC и USD не решают ключевых проблем интеропербаельности
Почему CAD-вендоры с 2023 году отказываются от файлов и переходят на гранулярные данные?
Почему параметрические форматы CAD и BREP-геометрия не являются необходимыми для строительной отрасли
Как Strabag и Züblin бросили вызов CAD вендорам и что из этого вышло
Почему использование семантики и онтологий в управлении данными не оправдывает себя.
Почему строительный бизнес будет против использования открытых данных
И что является инструментами будущего по работе с данными строительных проектов
Спасибо большое за ценные дискуссии и обсуждение поднятых вопросов Rasso Steinmann, Trir, Thomas Liebich, Ulf-Günter Krause, Bernd Müller-Jürries, Simon Dihlas, Michael Maass, уважаемые члены BuildingSMART, коммьюнити OSArch и группы DataDrivenConstruction Chat.
Содержание:
БИМ — это данные и процессы, но зачем тогда аббревиатура?
Каждый пользователь данных CAD (BIM) обслуживает десять потребителей данных
Любая CAD (BIM) программа — это компилятор данных, визуализирующий геометрию через геометрическое ядро
CAD, IFC и геометрические ядра: кто здесь главный?
IFC это CAD внутри CAD с зависимостью от геометрического ядра и SDK
Зачем строителям геометрия? Когда линии превращаются в деньги
Основы расчётов в строительстве или от линий до объёмов: как площадь и объём становятся числами
Зачем нам треугольники? Вся правда о тесселяции в строительстве
Попытка Zublin-Strabag подчинить CAD (BIM) вендоров интересам строительной отрасли
Появление семантики и онтологии в строительстве
Семантика и онтология: как заставить данные говорить?
От графов к таблицам: трудозатраты в группировки и фильтрации
В тени ISO и buildingSMART: война за контроль над форматом данных
Зачем строителям и заказчикам контролировать данные?
Уберизация и открытые данные это угроза для строительного бизнеса
Существует ли BIM, openBIM, BIM 3 level, noBIM на самом деле или это маркетинговый трюк?
Что будет дальше? Простые форматы и удобные инструменты
-
Появляение LLM и ChatGPT в процессах обработки проектных данных
Вместо заключения
1. БИМ — это данные и процессы, но зачем тогда аббревиатура?
Концепция BIM (Building Information Modeling), воскресла в строительной отрасли с публикацей Whitepaper BIM от Autodesk в 2002 году и дополнившись машиностроительной концепцией BOM (Bills of Materials) взяла свое начало из параметрического подхода к созданию и обработки данных проекта. Параметрический подход к созданию и обработке проектных данных впервые был реализован в системе Pro/Engineer для машиностроительного проектирования (MCAD). Эта система стала прототипом для многих современных CAD-решений, включая те, что сегодня применяются в строительной отрасли.
Цитата Самуэля Гейзенберга — основателя компании PTC, разработчика MCAD-продукта Pro/ENGINEER и наставника Леонида Райца, создателя Revit:
Цель состоит в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции. А затраты на внесение изменений в проект должны быть как можно ближе к нулю. Традиционные CAD / CAM программное обеспечение того времени нереально ограничивает внесение недорогих изменений только в самый начальный этап процесса проектирования
Уже в конце 1980-х годов цель состояла в устранении ограничений, существовавших в тогдашних CAD-программах. Основной задачей было снизить трудозатраты на внесение изменений параметров элементов проекта и обеспечить возможность обновления модели на основе данных вне CAD программ. При этом ключевую роль должна была играть параметризация задачи и автоматическое поступление параметров из базы данных для актуализации модели в CAD-системе.
После завершения Autodesk сделки по покупке Revit (с унаследованным BOM концептом из Pro/ENGINEER) двумя вице президентами компании Автодеск был подготовлен Whitepaper, который и ознаменовал приход в 2002 году концепции BIM в строительную отрасль.
На сайте с опубликованным WhitePaper по BIM компания Autodesk фактически воспроизвела маркетинговые материалы концепта BOM (Bills of Materials) из продуктов Pro/ENGINEER, использованных ещё в начале 1990-х годов.
BIM описывается как управление информацией о здании, где все обновления и все изменения происходят в базе данных. Таким образом, имеешь ли ты дело со схемами, разрезами или чертежами на листах, все всегда скоординировано, согласовано и актуально.
Почти все современные концепции добавлению и обработке параметров в строительстве, такие как IFC, BIM, openBIM и buildingSMART, были поддержаны в создании и продвигаются поставщиками CAD решений. Однако многие из этих идей заимствованы из других отраслей или приобретены у стартапов. Например, Autodesk не создавала Revit, концепцию BIM, AutoCAD Architecture, Navisworks, Civil 3D и Advanced Steel самостоятельно, а приобрела эти решения у стартапов.
Аналогично, buildingSMART не создавала формат IFC и аббревиатуру openBIM®. IFC был адаптирован техническим университетом Мюнхена из машиностроительного формата STEP, и позже переоформлен компанией HOK для создания яльянса IAI, а openBIM был переоформлен buildingSMART торговой маркой только в начале 2020х после его изначальной регистрации несколькими CAD вендорами в 2012 году. Формат IFC-STEP, в свою очередь, основан на IGES, созданном в 1979 году группой CAD-пользователей и поставщиков при поддержке NIST и Министерства обороны США. Связи между разработчиками и идеями современных концепций представлены на карте «History of BIM».
Машиностроение, откуда пришли основные инструменты и концепты, постепенно уходит от работы с терминами CAD, CAM и PLM к цифровым двойникам и сквозным процессам управления данными. Процессы проектирования, производства и эксплуатации рассматриваются не через призму конкретных инструментов (от таких компаний как PTC, Siemens и Dassault Systemes), а через единые подходы к данным и процессам. Вместо специализированных терминов, таких как BOM, PLM или PDM, всё чаще используется понятие управления данными, процессами и аналитики данных. Не только в машиностроении и других отраслях экономики наблюдается подобный переход от узких аббревиатур поставщиков ПО к универсальным понятиям во главе которых стоят «данные» и «процессы».
Пользователи и разработчики в строительной отрасли, подобно своим коллегам из других отраслей экономики, будут неизбежно отходить от расплывчатой терминологии поставщиков ПО, которая доминировала последние 20 лет, сосредотачиваясь на ключевых аспектах цифровизации — «данных» и «процессах».
Без свободного доступа к качественным структурированным данным в будущем невозможно будет выстроить эффективные процессы и автоматизировать их. Поэтому первоочередной задачей станет открытие, упорядочение, унификация и организация данных, что создаст основу для автоматизации и оптимизации бизнес-процессов.
Чтобы разобраться в сложности и запутанности существующей концепции CAD-BIM по управлению данными и процессами, мы обратимся к основам создания геометрии и метаинформации, которыми наполняются проектные данные. Это позволит ответить на вопрос почему использование, автоматизация и стандартизация проектных данных оставалось сложной задачей последние 30 лет.
2. Каждый пользователь данных CAD (BIM) обслуживает десять потребителей данных
Если до начала 2000х доля данных, хранящихся в цифровом виде, была крайне мала, и вопросы по использованию этих данных в других системах практически не поднимались, то благодаря появлению CAD (BIM), PLM, ERP, Excel-, SQL-подобных программ сегодня ситуация кардинально изменилась. Количество систем, потребляющих данные, выросло в десятки раз, вызывая настоящий кризис у менеджеров и специалистов, которым приходится принимать, обрабатывать и передавать дальше данные.
С начала 2000-х годов число офисных сотрудников, занятых обслуживанием различных систем и баз данных с пользовательским интерфейсом, росло экспоненциально, что привело к резкому увеличению значимости темы доступа и обмена данными. Как отметила ещё в 2002 году CEO Autodesk, на каждого CAD-инженера уже в начале 2000х приходится как минимум с десяток других специалистов, которым необходимо работать с данными, созданными в CAD-системах (Цитата):
Нужно уметь управлять всеми этими данными (CAD - примечание автора), хранить их в цифровом виде и продавать программное обеспечение для управления жизненным циклом и процессами, ведь на каждого инженера, который что-то создает, приходится десять человек, которые должны работать с данными.
К началу 2020-х количество специалистов, работающих с данными из CAD и BIM программ возросло экспоненциально, в крупных компаниях достигая сотен специалистов — от менеджеров систем GIS, ERP и CAFM до прорабов на стройках.
Все эти пользователи и их менеджеры, работающие с данными в строительной отрасли, стремятся к полной совместимости между различными программами и платформами, а точнее базами данных и форматами данных. И несмотря на то, что почти все системы и базы данных в строительной отрасли открыты для инженеров и IT-специалистов, только CAD (BIM) по-прежнему остаются закрытыми базами данных с проприетарными форматами. Эти закрытые форпосты проектной информации на протяжении последних 30 лет влияют на десятки других отделов и сотни специалистов, создавая зависимость от ограниченного доступа к информации.
Вопросы настоящей кроссплатформенности и интероперабельности сталкиваются с фундаментальной проблемой закрытости CAD-программ и используемых ими сложных проприетарных геометрических ядер, сторонних SDK инструментов и различных схем данных в проприетарных форматах.
А зачем вообще нужны CAD- (BIM)-системы в строительстве? Их основная задача — помочь проектировщику по исходным параметрам задач в проекте создавать новые данные, которые включают как геометрию проектных элементов, так и связанную с ними метаинформацию.Согласно определению из Википедии:
Информационное моделирование зданий (BIM) — это метод создания и управления цифровыми представлениями физических и функциональных характеристик зданий и других объектов.
Для создания и хранения этих характеристик и параметров большинство CAD (BIM) систем используют закрытые базы данных и собственные форматы хранения. Кроме того, они задействуют сложные проприетарные геометрические ядра, обеспечивающие визуализацию и интерактивное взаимодействие с геометрией проекта.
3. Любая CAD (BIM) программа — это компилятор данных, визуализирующий геометрию через геометрическое ядро
Каждая CAD (BIM) программа либо использует собственное геометрическое ядро, либо опирается на стороннее проприетарное решение, что существенно усложняет обмен данными между различными платформами.
Любая CAD (BIM) программа является компилятором данных о геометрии, которая отображается при помощи геометрического ядра.
На рынке доминируют такие геометрические ядра, как Siemens Parasolid, Dassault Systèmes CGM, PTC ProEngineer, ADSK ShapeManager и АСКОН C3D. Единственными бесплатными геометрическими ядрами с открытым исходным кодом являются OpenCascade и библиотека CGAL под лицензией GPL.
Проблем с построением геометрии по параметрам не возникает, если речь идет о простых геометрических элементах — таких как линии или плоскости. Однако при работе со сложными или составными элементами ситуация меняется. Даже при одинаковых входных параметрах разные геометрические ядра могут давать разные результаты из-за особенностей их работы и алгоритмов обработки. В итоге геометрические сущности проект, сохранённые в виде параметрической геометрии будет отображаться в разных CAD (BIM) продуктах по разному.
Полная кроссплатформенная совместимость на уровне параметрической геометрии остаётся недостижимой для большинства CAD-вендоров. Это связано с отсутствием стандартизации алгоритмов, используемых в геометрических ядрах систем, которые часто не принадлежат CAD-вендорам (а больше MCAD вендорам), а также с необходимостью создания открытых спецификаций обмена и разработки универсальных конвертеров. В настоящее время подобными задачами занимаются лишь несколько инициатив, включая OpenCascade, Open Design Alliance и CADExchanger. Исторически, инициативы по конвертации и унификации разноформатных данных подвергались активному давлению со стороны CAD-вендоров. Однако многие из этих конфликтов завершались судебными разбирательствами, в которых решения выносились не в пользу вендоров.
Давайте разберёмся, а зачем в работе с данными вообще нужно геометрическое ядро, которое является настолько сложным, что даже разработчики CAD (BIM) систем вынуждены обращаться за решениями и разработкой к сторонним вендорам и разработчикам.
4. CAD, IFC и геометрические ядра: кто здесь главный?
Геометрическое ядро необходимо для визуализации и обработки геометрии. Одним из наиболее распространённых методов предоставлении геометрии в CAD (BIM) системах является Boundary Representation (BREP или B-rep).
BREP (Boundary Representation) — это способ описания геометрии объекта через параметры-границы: поверхности, ребра и вершины.
В формате IFC и внутренних контейнерах CAD-программ используются и другие формы представления геометрии, такие как CSG и Swept Solids, которые находят своё применение в определённых задачах. Однако именно BREP благодаря своей универсальности занимает лидирующие позиции, став стандартом для большинства инженерных и архитектурных решений в среде CAD (BIM).
В любой CAD программе, действия пользователя, такие как клики мышкой в интерфейсе программы для выбора точек или линий преобразуются в BREP с помощью геометрического (математического) ядра и отображаются в виде готовой фигуры в окне программы.
Однако, поскольку каждый CAD-вендор использует собственное геометрическое ядро с уникальной кодовой базой, зачастую состоящей из десятков миллионов строк, перенос BREP-параметров между программами не гарантирует их идентичное отображение в другой CAD-системе.
BREP (Boundary Representation) внутри формата IFC — это не фундаментальный формат, так как он описывается параметрически без использования конкретного или существующего для этого геометрического ядра. Это создает ситуацию, при которой одна и та же параметрическая модель IFC может интерпретироваться по-разному в различных программных продуктах, использующих разные геометрические ядра, например OpenCascade, Shape manager, Siemens Polarsolid которые используется в CAD (BIM) программах.
Ключевым элементом процесса создания реальной кроссплатформенности может потенциально стать утопичная идея создание универсального геометрического ядра, к которому можно привязывать параметрику элементов. Это обеспечит корректную интерпретацию одной и той же геометрии в любых CAD (BIM) системах.
Поэтому или у buildingSMART должно появится собственное бесплатное и открытое геометрическое ядро или один и тот же BREP элемент из IFC формата будет и дальше отображаться по-разному в разных инструментах и программах.
Cам IFC можно рассматривать как своего рода CAD внутри CAD или скелет для системы автоматизированного проектирования, которой за 30 лет официально для IFC не появилось.
5. IFC это CAD внутри CAD с зависимостью от геометрического ядра и SDK
В формате IFC используются различные способы представления геометрии, такие как CSG и Swept Solids, однако BREP стал также лидирующим стандартом для передачи геометрии элементов в IFC формате, так как такой формат поддерживается при экспорте из CAD (BIM) программ и позволяет потенциально (реализовано лишь в экспериментальных продуктах) редактировать элементы при обратном импорте IFC в CAD программы.
В большинстве случаев, когда геометрия в IFC задана параметрически (BREP), получить свойства, такие как объём или площадь сущностей проекта, становится невозможно имея только файл IFC, потому что для работы с геометрией и его визуализацией в таком случае потребуется геометрическое ядро, которое изначально отсутствует.
Для поддержки IFC в любой программы фактически необходимо создать ещё одну идеальную IFC CAD внутри уже существующего решения cо своим геометрическим ядром и своей логикой работы с геометрией.
И если с примитивными элементами в IFC-BREP формате может не возникать проблем, то помимо проблем с разными движками геометрических ядер существует достаточно элементов, которые имеют свои особенности для правильного отображения. Эта проблема подробно рассмотрена в международном исследовании “Reference study of IFC software support”, опубликованным 2019 года. Цитата:
Одни и те же стандартизированные наборы данных дают противоречивые результаты, мало обнаруживаемых общих закономерностей, и серьезные проблемы найдены в поддержке стандарта (IFC - примечание автора), вероятно, из-за той самой высокой сложности стандартной модели данных. Отчасти здесь виноваты сами стандарты, поскольку они часто оставляют некоторые детали неопределенными, с высокой степенью свободы и различными возможными интерпретациями. Они допускают высокую сложность в организации и хранении объектов, что не способствует эффективному универсальному пониманию, уникальным реализациям и согласованному моделированию данных
Правильное понимание “определённых положений” доступно платным членам buildingSMART и часто в кулуарных дискуссиях. Как следствие, тот, кто хочет получить доступ к важным знаниям об определенных особенностях IFC, будет пытаться кооперироваться с крупными компаниями, либо доходить до этого своими исследованиями. Из интервью разработчика CAD-программы Renga:
Ты натыкаешься на вопрос об импорте и экспорте данных через формат IFC и спрашиваешь у коллег-вендоров: “А почему так в файле IFC передаётся информация про параметрическую передачу помещений? В открытой спецификации от buildingSMART ничего про это не сказано”. Ответ от "более знающих” европейских вендоров: “Да, не сказано, но допустимо"
Все особенности отображения и генерации параметров IFC в ядре геометрии могут быть реализованы только большими командами разработчиков. Поэтому нынешняя практика особенностей и сложности формата IFC, выгодна прежде всего CAD вендорам и имеет много общего со стратегией Microsoft «adopt, extend, destroy», когда растущая сложность стандарта фактически создает барьеры для небольших игроков рынка. Стратегия Microsoft заключалась в адаптации открытых стандартов, добавлении собственных расширений и функций, чтобы создать зависимость пользователей от своих продуктов, а затем вытеснить конкурентов. Microsoft долгое время навязывала собственные стандарты (например, Internet Explorer), что замедляло внедрение более прогрессивных и универсальных технологий, таких как CSS, HTML5, или независимых браузеров.
В итоге сегодня полноценная реализация онтологии IFC под силу только крупным поставщикам CAD, которые могут вложить значительные ресурсы в поддержку всех сущностей и их маппинга с их внутренним геометрическим ядром. Крупные вендоры также имеют возможность согласовывать между собой технические детали особенностей, которые могут быть недоступны даже самому активному участнику buildingSMART.
Подробнее о сложностях с которыми сталкиваются команды разработчиков, работающие с IFC форматов в исследовании “Reference study of IFC software support”
Для небольших независимых команд и проектов с открытым исходным кодом, стремящихся поддерживать развитие интероперабельных форматов, отсутствие собственного геометрического ядра превращается в серьёзную проблему. Без него практически невозможно учесть всё многообразие тонкостей и нюансов, связанных с межплатформенным обменом данными.
На текущий момент единственным широко используемым open-source ядром, лежащим в основе популярных openBIM-инструментов — таких как IfcOpenShell, BlenderBIM-Bonsai, IFC.js и FreeCAD — остаётся OpenCascade. Однако и у него есть свои ограничения. Организация BuildingSMART не имеет непосредственных инструментов влияния на развитие OpenCascade (OCC) и его лицензирование. Исторически команда разработчиков OCC была сосредоточена в Нижнем Новгороде, но в последние годы часть специалистов OCC переехала в Португалию, а большая и оставшаяся часть команды сконцентрировалась на развитии ответвления проекта OpenCascade (OCC) под маркой нового китайского open-source геометрического ядра OGG.
А для чего нам вообще нужна, с таким большим трудом добытая, геометрия в строительстве и нужна ли она нам именно в параметрическом виде?
6. Зачем строителям геометрия? Когда линии превращаются в деньги
Геометрия, помимо визуализации, дополняет существующие списки параметров элементов ключевыми объёмными характеристиками, такими как площадь и объём, которые автоматически рассчитываются на основе формы объекта-cущности проекта. Эти параметры играют важнейшую роль, так как служат основой для последующих вычислений, расчётов и анализа.
Автоматический расчёт геометрии становится связующим звеном между абстрактными данными в виде параметров задачи и их физической реализацией.
Геометрия исторически была основой инженерной коммуникации, обеспечивая возможность расчёта длин, площадей и объёмов. От первых чертежей на папирусе до современных цифровых форматов, чертежи всегда служили ключевым инструментом для передачи информации об объёмах материалов и работ между инженерами, прорабами и сметчиками. На протяжении тысячелетий, вплоть до 1980-х годов, сметчики вручную собирали количественные и объёмные данные, опираясь исключительно на визуальные представления, используя линейки и транспортиры как основные инструменты измерения.
С появлением компьютеров ручная и трудоемкая задача по расчётом объемных характеристик теперь решается путем полной автоматизации благодаря появлению объемного моделирования в современных инструментах CAD (BIM), которое позволяет автоматически получать объемные атрибуты любого элемента, без необходимости вычислять эти значения вручную с калькулятором.
Работая в CAD-программах создание геометрических элементов для расчётов происходит через пользовательский интерфейс CAD-BIM программ. Для преобразования точек и линий в объемные тела используется геометрическое ядро. Геометрическое ядро выполняет ключевую задачу — преобразование геометрии в объемные модели, из которых, после аппроксимации автоматически рассчитываются объемы элемента.
Как и тысячи лет назад при строительстве пирамид, где для измерений использовались локоть и кубит, так и сегодня в CAD-программах точность интерпретации геометрии играет ключевую роль: от неё зависят точность расчётов бюджета проекта, корректное определение стоимости и сроков выполнения работ из которых состоит любой строительный проект.
Точность расчётов — это ключевой фактор выживания в строительной отрасли. В условиях жёсткой конкуренции доступ к качественным данным об объёмах становится решающим условием для успешной реализации проектов и поддержания конкурентоспособности.
Если точность расчётов играет ключевую роль в определении ресурсов, материалов и временных параметров проекта, то важно разобраться, как именно осуществляется этот расчёт.
7. Основы расчётов в строительстве или от линий до объёмов: как площадь и объём становятся числами
На практике для вычисления площадей и объемов геометрических поверхностей, заданных аналитически или через NURBS в BREP, часто используется триангуляция, которая преобразует сложные поверхности в сетку треугольников.
NURBS (Non-Uniform Rational B-Splines) это математический способ описания кривых и поверхностей, тогда как BREP — это структура для описания полной трёхмерной геометрии объекта, включая его границы, которые могут быть определены с использованием NURBS.
Даже если поверхность задана аналитически или через NURBS, её чаще всего аппроксимируют тесселяцией, так как точные вычисления через интегралы или сложные аналитические методы на практике реализуются редко из-за их сложности и больших вычислительных затрат.
Суть тесселяции заключается в разбиении сложных поверхностей на более простые элементы — треугольники или полигоны. Этот подход используется для расчётов поверхностей и объёмов, визуализации на экране, для экспорта в форматы вроде MESH ( "сетка"), и системы анализа столкновений и коллизий. В играх тесселяция используется для создания реалистичных ландшафтов, а в системах CAD/CAE — для вычислений и визуализации. В природе примером тесселяции являются пчелиные соты.
BREP (NURBS), применяемая в CAD (в том числе BIM-системах), не является фундаментальной моделью геометрии. Этот метод был создан как удобный инструмент для представления окружностей и рациональных сплайнов. Однако у него есть ограничения — например, невозможность точно описать синусоиду, которая лежит в основе винтовых линий и поверхностей. В результате BREP (NURBS) остаётся лишь способом аппроксимации, но не фундаментальным средством описания геометрии.
Треугольные сетки (triangle mesh) и тесселяция параметрических фигур напротив отличаются простотой, эффективным использованием памяти и способностью обрабатывать большие объёмы данных. Эти преимущества позволяют обходиться без сложных и дорогих геометрических ядер, и заложенных в них сотен миллионов строк кода, при расчётах геометрических форм.
При этом в строительной отрасли, не имеет принципиального значения, каким образом определяются объёмные характеристики — за счёт параметрических моделей во внутренних форматах CAD или IFC, либо с использованием упрощённых геометрических представлений в форматах USD, glTF, DAE или OBJ.
Геометрия, заданная в виде полигонов или BREP (NURBS), — это способы приближённого описания непрерывной формы. Подобно тому, как интегралы Френеля не имеют точного аналитического выражения, дискретизация геометрии через полигоны или NURBS всегда является аппроксимацией, такой же как и триангулярный MESH.
И полигональнй MESH и параметрический BREP имеют свои преимущества и ограничения, но цель у них одна — эффективно и удобно описывать геометрию с учётом задач пользователя.В конечном счёте, точность геометрической модели зависит не только от метода её представления, но и от требований конкретной задачи.
Параметрическая геометрия в формате BREP необходима в основном там, где важен минимальный размер данных и есть возможность использовать ресурсоёмкие и дорогие геометрические ядра для её обработки и отображения. Чаще всего это характерно для CAD-программ, которые применяют для этого геометрические ядра MCAD-вендоров.
В большинстве строительных задач потребность в параметрической геометрии и сложных геометрических ядрах возникает редко, если только её значимость не продвигается самими вендорами CAD или производителями геометрических ядер, которые и разрабатывают эти инструменты.
В итоге, внутри CAD (BIM) программ параметрическая геометрия (BREP, RVT, IFC, PLN) для расчётов всё равно преобразуется в MESH треугольники и полигоны через процесс тесселяции. За пределами среды CAD (BIM) в большинстве случаев, для визуализации, расчётов и поиска коллизий используется также триангулированная MESH геометрия (USD, SVF, glTF, CPIXML, DAE, NWC), что делает необходимость параметрической геометрии ещё менее очевидной.
Так какой формат следует выбрать в качестве стандарта для обмена данными и является ли IFC подходящим форматом для обмена - триангулярный IFC-MESH (gLTF, OBJ, DAE, SVF) или параметрический IFC-BREP (RVT, PLN, DGN)?
8. Зачем нам треугольники? Использование тесселяции в строительстве
В основе обменного формата, который будет использоваться как в отделах калькуляций, так и на стройплощадке - не должна подразумеваться конкретная CAD (BIM) программа. Геометрическая информация должна быть представлена в формате напрямую, без привязки к геометрическому ядру или архитектуре CAD.
В строительной отрасли, в системах и базах данных использующих проектные данные зависимость от редактора CAD и геометрического ядра должна быть минимальной.
Параметрика геометрии из CAD программ может быть частью процесса, но лишь как исходные данные, а не основа обменного формата. Только так можно обеспечить универсальность и независимость геометрических описаний. Большинство параметрических геометрий, включая BREP и NURBS, для расчетов и визуализации преобразуются в треугольную сетку (тесселяцию). После тесселяции всё равно получается triangle MESH. Если в итоге разницы не видно, то зачем усложнять процесс?
Параметрические форматы не фундаментальны и наоборот такие форматы как OBJ, STL, gLTF, SVF, CPIXML, USD и DAE, остаются фундаментальными, поскольку используют простую и универсальную структуру Triangle MESH. Она понятна и эффективна в архитектуре компьютерной графики, а также не требует дополнительных геометрических ядер с десятками миллионами строк кода для визуализации или расчётов элементов.
Из за проблем с интерпретацией IFC и разности геометрических ядер все CAD вендоры, без исключения, используют SDK обратного инжениринга для передачи данных между решениями различных вендоров и никто не использует для целей интероперабельности сложный IFC или USD формат.
MESH формат USD, предлагаемый с 2023 года CAD вендорами в новом альянсе AOUSD, который обсуждался в прошлой статье (An Era of Change: IFC is a thing of the past or why Autodesk and other CAD vendors are willing to give up IFC for USD in 14 key facts), потенциально может стать новым стандартом для замены параметрической геометрии в проприетарных форматах. Он также может служить средством для описания BREP-геометрии в IFC, с чем до сих пор не справились сами CAD-вендоры.
Но вместо того, чтобы использовать концепты, продвигаемые альянсами CAD вендоров, которыми они сами не пользуются- продуктивнее сосредоточиться на понимании преимуществ каждого подхода в конкретном контексте и выбирать тот или иной вид геометрии в зависимости от кейса использования.
Выбор между различными геометрическими представлениями - это компромисс между точностью, вычислительной эффективностью и практическими потребностями конкретной задачи.
Сложность и использование геометрических ядер, которые навязывают строительной отрасли CAD-вендоры в обработке проектных данных, возможно, вовсе не нужна. Формат USD с MESH-геометрией может стать своего рода "ящиком Пандоры" для отрасли, открывая разработчикам подходы , альтернативные от IFC и BREP, к обмену данными. Оказалось, что есть и другие, более простые и открытые форматы, которые могут обеспечить качественное взаимодействие CAD (BIM) инженеров с десятками других специалистов.
Существующим примером подобного эффективного применения MESH-геометрии в бизнес процессах строительных компаний является одна из самых популярных строительных ERP-систем — ITWO/MTWO. Этот продукт, принадлежащий франко-немецкому объединению Schneider Electric и RIB Software, ещё в середине 2000-х продемонстрировал использование MESH формата с упрощённой схемой хранения метаинформации. Вместо IFC и USD форматов в ITWO/MTWO используется проприетарный, но открытый для чтения формат CPIXML.
За разработкой ERP-системы iTWO/MTWO стоит строительная корпорация Strabag, а точнее её дочерняя компания Züblin из Штутгарта. Именно Züblin была инициатором разработки iTWO, которая на тот момент позиционировалась не просто как ERP-система, а как интернациональная платформа для 4D-5D BIM — интеграции проектных данных с графиками и сметами.
9. Попытка Zublin-Strabag подчинить CAD (BIM) вендоров интересам строительной отрасли
Züblin-Strabag — одна из крупнейших строительных компаний Европы, обладающая глубоким пониманием всех этапов строительного процесса. Оборот STRABAG SE достиг 17,67 миллиарда евро в 2023 году. Для сравнения, общий объем мирового рынка компаний, занимающихся разработкой программного обеспечения для CAD, в том числе Autodesk, в 2021 году оценивался примерно в $18,54 млрд,.
Разработчики Zublin (Strabag) и RIB Software в Штутгарте смогли создать конвертеры-плагины для основных CAD-программ, которые получают геометрические данные и тесселируют их в формате OBJ - CPIXML (похожий на USD). В результате такие триангулированные геометрии позволили уже вне рамок CAD (BIM) программ в табличной ERP рассчитывать дополнительно более 150 различных объемных характеристик на основе примитивной MESH OBJ-геометрии, помимо тех, что уже были получены внутри самой CAD-программы. После продажи ITWO французской Schneider Electric за 1,5 млрд евро компания Züblin (Strabag) сосредоточила усилия на создании нового продукта для интероперабельности в строительной отрасли.
С середины 2010-х годов Züblin (Strabag) разрабатывает платформу под названием SCOPE, которая через API-подключения и SDK реверсинжениринга получает геометрию из различных CAD-программ и конвертирует её в нейтральный формат на базе OpenCascade. Это позволяет использовать геометрические данные в различных бизнес-кейсах без привязки к конкретным программам CAD (BIM). Основная идея проекта — отделить управление данными проекта от CAD-приложений и обеспечить независимость пользователей от инструментов конкретных вендоров. Описание проекта SCOPE перекликается с идеей Самуэля Гайзберга (создателя PTC и ментора проекта Revit), который стремился снизить влияние CAD-программ на процессы изменения и добавления данных:
В течение первых восьми месяцев проекта консорциуму удалось составить первые полные описания компонентов в форматах World Wide Web RDF и OWL. С этой целью функциональные возможности геометрического ядра openCASCADE были преобразованы в адресуемые веб-структуры. Заявленной целью SCOPE является создание веб-структур для преодоления барьеров цифровизации. Для этого все компоненты цифрового двойника здания отображаются независимо от программного обеспечения и становятся доступными через веб-интерфейсы. В случае успеха это означает, что все действия по оцифровке, необходимые для создания двойника здания всеми вовлеченными компаниями, специализированными дисциплинами и отраслями, могут выполняться независимо друг от друга и при этом могут быть объединены в сеть. При условии, что контент предоставляется на одной технической основе, а именно на единой структуре сервера и единой схеме данных.
Идея SCOPE проекта, безусловно, перспективная и нужная для отрасли, но проект реализуется в рамках закрытой экосистемы Zublin-Strabag, командами у которых сменяются разработчики и менеджеры. Это потенциально приводит к созданию громоздкой и неэффективной системы с растянутыми сроками реализация проекта. Таже проект Züblin на базе OpenCascade наталкиваются на технические ограничения самого геометрического ядра OpenCascade и постоянно меняющегося API CAD программ. Возможно ли справится с этими вопросами одной компании безусловно талантливых специалистов остаётся вопросом.
В итоги учитывая ограничения с которыми сталкиваются разработчики, SCOPE на данный момент нельзя назвать полноценным решением. Разработка, созданная частной организацией для внутреннего использования, не является универсальным инструментом.
С другой стороны и уже сами CAD вендоры делают шаг в сторону упрощения и хотят подарить строительной отрасли новый формат обмена USD, который похож на CPIXML формат, уже охвативший все процессы 4D-7D в строительных компаниях Центральной Европы.
В итоге компании строительной отрасли оказываются в будущем перед выбором: следовать подходам, предлагаемым Züblin и Институтом Фраунгофера, или же принять решения, продвигаемые HOK и вендорами CAD через альянс buildingSMART или AOUSD.
Однако оба подхода, независимо от их происхождения — из строительной отрасли или мира CAD — приходят к единому выводу: для эффективного обмена данными есть смысл использовать простые плоские форматы храненения метаинформации и триангулированные форматы, такие как OBJ, CPIXML, DAE, SVF, gLTF или USD, которые хранят одни и те же данные элементов.
После рассмотрения передачи геометрии и связанных с этим сложностей, перейдём к обсуждению второй неотъемлемой части CAD (BIM) форматов - метаинформации и семантической онтологии элементов, которая упоминаются в официальных пресс-релизах команды SCOPE и buildingSMART.
Подобно подходу buildingSMART, компания Züblin применила концепцию семантики данных в своей платформе SCOPE. Основой этого подхода является идея семантического веба, предложенная Тимом Бернерс-Ли. Его цель — создать «умную» семантику, где данные структурируются таким образом, чтобы их могли понимать не только люди, но и машины.
10. Появление семантики и онтологии в строительстве
Стандартизация и унификация в строительстве заимствовали внедрение семантики и онтологии у концепции семантической паутины в конце 1990х. Эта концепция была адаптирована в контексте buildingSMART для стандарта IFC. Основная идея семантики заключается в том, что данные должны иметь смысл не только для человека, но и для машин, позволяя им "понимать" информацию, а не просто передавать её. Онтология, в свою очередь, создаёт чёткие определения терминов и их взаимосвязей, что обеспечивает единую основу для всех систем.
buildingSMART попытался масштабировать этот подход на всю строительную отрасль. В одном из ключевых документов о будущем формата IFC5 под названием "Future of the Industry Foundation Classes: towards IFC 5" семантический подход упоминается 32 раза, подчёркивая его значимость для дальнейшего развития стандарта.
Особенно в области Семантического веба много сил было вложено в преобразование, модулизацию и упрощение схемы (или онтологии; по типичной идиоме в этой области) IFC. Начиналось все с прямого преобразования схемы IFC EXPRESS и модификаций, которые привели к созданию более идиоматичной онтологии (Beetz et al. 2009), а также анализов, направленных на внедрение модульности (Terkaj and Pauwels 2017).
Цель buildingSMART — создать единый универсальный стандарт для описания объектов и их взаимосвязей. Такой подход должен быть применим по всему строительному миру, обеспечивая унификацию данных и улучшая их интерпретацию различными системами. Покупка членства в buildingSMART даёт компаниям-участникам не просто возможность приобщиться к будущему, но и активно влиять на его формирование уже сегодня.
Однако внедрение семантики и онтологий не всегда приводит к успеху. Реальность оказалась куда сложнее. В игровой индустрии попытки описать игровые объекты и взаимодействия через онтологии столкнулись с проблемами из-за высокой динамики изменений и креативной природы отрасли. В результате стандартные форматы данных (XML, JSON) и алгоритмы оказались более эффективными. Аналогичная ситуация наблюдалась на рынке недвижимости, где разнообразие локальных терминов и быстрые изменения сделали онтологии избыточно сложными. Простые базы данных и стандарты, такие как RETS, лучше справлялись с задачами обмена и обработки данных.
Не следует привлекать новые сущности без крайней на то необходимости
Бри́тва О́ккама
Технические трудности, такие как сложность разметки и высокая трудоёмкость поддержки, а также низкая мотивация разработчиков, тормозили развитие этой идеи в других отраслях экономики. RDF (Resource Description Framework) не стал массовым стандартом, а онтологии оказались избыточно сложными и экономически неоправданными. В результате амбиции по созданию глобального семантического веба не оправдались. Некоторые идеи были адаптированы в корпоративных решениях, но изначальная цель создания единого всеобъемлющего графа так и не была достигнута.
Онтологии и семантические технологии обещали создать смысл из данных, но на практике они работают скорее как механизм унификации и стандартизации. Переход от таблиц к графам данных позволяет улучшить поиск и унифицировать модель данных, но не делает данные более осмысленными для машин. Вопрос не в том, нужно ли использовать семантические технологии, а в том, где они действительно приносят пользу.
Интерес к семантическим технологиям и онтологиям в строительстве поддерживается благодаря инициативам buildingSMART. Однако необходимость полной формальной логики и создание единой онтологии для всей отрасли остаётся спорным моментом. Опыт проектов CYC ("encyclopedia") и семантического веба показывает, что отказ от идеи единой универсальной онтологии в пользу локальных микротеорий, применимые только в рамках конкретной задачи, проекта или компании, может быть более продуктивным подходом.
11. Семантика и онтология: как заставить данные говорить?
Благодаря усилиям buildingSMART, семантика и онтологии стали не только ключевой идеей, лежащей в основе стандартизации, управляемой CAD-вендорами, но и фундаментом для таких проектов, как SCOPE, продвигаемый Züblin (Strabag), и направленный на освобождение строительной отрасли от зависимости CAD-систем.
Семантические технологии это унификация, стандартизация и модификация больших массивов разнородных данных, а также реализация сложного поиска. Однако семантика никак не связана с созданием нового смысла или знаний — в этом плане они ничем не превосходят другие технологии хранения и обработки данных.
Представление данных из реляционной базы данных в виде набора триплетов не добавляет осмысленности самим данным. Замена таблиц на граф может быть полезна для унификации модели данных, реализации сложного поиска и безопасной модификации бизнес-моделей. Однако это не делает данные более "умными" — компьютер не начинает лучше понимать их смысл.
Когда дело доходит до хранения «OWL-данных», эти данные хранятся с помощью RDF-триплетов (RDF — Resource Description Framework и OWL — Web Ontology Language).
Теоретически, логический вывод ризонеров (программы для автоматического логического вывода) позволяет получать новые утверждения на основе онтологий. Например, если в строительной онтологии записано, что "фундамент — это опора для стены", а "стена — это опора для крыши", ризонер способен автоматически сделать вывод, что "фундамент — это опора для крыши". Этот механизм действительно полезен для оптимизации анализа данных, поскольку исключает необходимость явно прописывать каждую зависимость. Однако, это не создание новых знаний, а лишь автоматическое сопоставление уже известных фактов.
Логические связи в онтологии, если они нужны, можно организовать и без сложных семантических технологий, например, используя реляционные базы данных (SQL) или таблицы CSV и XLSX. В колончатых базах данных и форматах можно добавить колонку "опора крыши" и программно обеспечить добавление факта связи крыши с фундаментом при создании стены. Это достигается без применения RDF, OWL, графов или ризонеров.
Решение buildingSMART и Strabag (Zublin) следовать концепции семантического веба, который в конце 1990х казался перспективным и популярным, повлияло на всю строительную отрасль. Однако, парадокс в том, что сама концепция семантического веба, изначально предложенная для интернета, не получила широкого применения даже в своей родной среде. В интернете, для которого и разрабатывались RDF и OWL, эти концепции сегодня практически не используются. Полноценного семантического веба в изначальной архитектуре так и не появилось, и его создание уже возможно не предвидится.
Идея создания интернета, где компьютеры будут понимать смысл контента, оказалась слишком сложной и экономически невыгодной. Именно поэтому корпорации, которые первоначально поддерживали семантический веб, оставили только полезные элементы технологии — такие как онтологии и SPARQL — и применили их для корпоративных целей, а не для интернета в целом. Если посмотреть в Google Trends, например за последние 20 лет, можно увидеть что перспектив там возможно уже не осталось.
Здесь возникает логичный вопрос: зачем вообще использовать триплеты, ризонеры и SPARQL в строительстве, если можно обрабатывать данные с помощью популярных структурированных запросов (SQL, Pandas, Apache)? В корпоративных приложениях SQL является стандартом для работы с базами данных. SPARQL, напротив, требует сложных графовых структур и специализированного программного обеспечения и по трендам в Google не привлекает к себе интереса разработчиков.
Графовые базы данных и деревья классификаций могут быть полезны в отдельных случаях, но их применение не всегда оправдано для большинства повседневных задач. В итоге, создание графов знаний и использование технологий семантического веба имеет смысл только в тех случаях, когда требуется унифицировать данные из разных источников или реализовать сложные логические выводы. Для повседневных задач, таких как управление строительными данными, реляционные базы данных, CSV, SQL и Excel остаются более простыми, доступными и эффективными инструментами.
12. От графов к таблицам: трудозатраты в группировки и фильтрации
Любая онтология и отношение фундаментально описывает параметры элементов и сущностей проекта с помощью пар «ключ-значение». Вопрос лишь в том, как передать эти параметры словарей ключ-значение и в какой форме. Различие заключается не в механизме хранения или структуре, а в глубине семантического понимания и способности устанавливать значимые связи между понятиями. Является ли экспресс-разметка и онтология IFC идеальным инструментом для этого - большой вопрос.
В других отраслях экономики существуют те же самые элементы с параметрами, геометрическими формами и аналогичные проблемы передачи онтологии. Однако специалисты этих отраслей передают метаинформацию с использованием популярных форматов, таких как XML, DB, JSON, CSV, HD5 и XLSX. Возникает логичный вопрос: почему в строительной отрасли мы решили передавать метаинформацию с помощью технологий, разработанных ещё в 70-х годах для формата IGES-STEP в построчной EXPRESS разметке, которая была придумана ещё во времена перфокарт? Да, существуют конвертеры для преобразования данных из IFC в JSON, XML, CSV или XLSX. Однако возникает вопрос — зачем вообще использовать промежуточный этап с IFC?
Гораздо логичнее выгружать данные из CAD-программ напрямую в JSON, XML или структурированные форматы CSV/XLSX с помощью SDK реверсинжениринга, которыми пользуются все CAD вендоры без исключения. В таком случае использование IFC как промежуточного этапа теряет смысл. И если разницы в полноте информации между графами и таблицами нет, то выбор будет сводиться только к выбору схемы данных и формата записи.
Форма и схема данных должна подходить под кейс использования для решения тех или иных задач.
Семантический, графовый формат лишь упрощает создание новых связей, то есть позволяет добавлять в граф новые типы данных без каких-либо изменений в структуре хранилища.
По сравнению с реляционными таблицами в графе нет никакой особой, дополнительной связанности данных — перевод данных двумерных баз данных в граф не увеличивает количество связей и не позволяет получить новую информация.
Для получения данных в бизнес процессах мы должны стремится использовать те инструменты, которые помогают максимально быстро и просто получить результат.
Основная задача при обработке данных из моделей CAD (BIM) и баз данных остаётся неизменной — это быстрая группировка и фильтрация из общей базы данных проекта определённой группы с целью извлечения ключевой информации. Результаты этой работы представляются в виде таблиц, графиков или документов, что позволяет принимать обоснованные бизнес-решения, основанные на данных.
Несмотря на идентичные входные и выходные данные - подходы и затраты времени на выполнение этих операций могут существенно различаться в зависимости от используемых систем CAD (BIM), а точнее используемых в них форматах, схемах данных и концептуальных подходов.
Например, задача получения из проекта таблицы объёмов для всех типов элементов одной категории (возьмем пример категории стен - OST_Walls, IfcWalls) выглядит по-разному в зависимости от инструмента. В графическом интерфейсе Revit для группировки и получения таблицы потребуется сделать 17 кликов мышкой. Использование Dynamo для Revit позволяет автоматизировать процесс, но для этого нужно импортировать и связать 13 блоков кода в специальном IDE IronPython. В случае написания скрипта на Python для Revit потребуется уже 40 строк кода и знание APU, что предоставляет большую гибкость, но требует больше усилий со стороны инженера или программиста.
Работа с IFC-файлами через интерфейс программы Solibri по трудоёмкости аналогична Revit — здесь, для получения простой таблицы с объёмами из проекта, также потребуется выполнить 17 кликов мышкой. При использовании Python-библиотеки IfcOpenShell или JavaScript IFC.js обработка становится автоматизированной, но для этого снова нужно написать около 40 и более 100 строк кода соответственно.
Кроме того, проблема с проприетарными форматами и форматами инструментов САПР (BIM) заключается в том, что, с одной стороны, они предоставляют удобную среду для разработки собственных алгоритмов автоматизации производственных процессов. Однако, с другой стороны, эти алгоритмы становятся жестко привязанными к конкретному формату данных или способу их интерпретации. В результате автоматизация теряет свою универсальность и начинает зависеть от специфики формата, вместо того чтобы работать с сущностями и быть независимой от технических ограничений.
Нормализуя и структурируя данные из форматов CAD-проектов, не открывая сами CAD (BIM) программы, а используя, например, инструменты обратной инженирии мы получаем доступ к использованию инструментов аналитики данных для группировки, фильтрации и анализа. С помощью инструментов аналитики данных операции группировки, фильтрации и обработки выполняются буквально одной строкой кода, тогда как в традиционных CAD-системах и BIM-концепциях, где данные представлены в виде графиков, тебе приходится проходить через иерархии и классы, чтобы добраться до элементов. В результате те же действия, которые требуют десятков кликов в пользовательском интерфейсе, сотен строк скрипта, можно выполнить быстрее и проще, обрабатывая данные в структурированных форматах.
Именно структурированные и нормализованные данные дают инженерам возможность быстро и эффективно перемещаться между различными типами данных, устраняя необходимость изучать уникальные схемы форматов, особенностей интерфейсов, API подключений и геометрических ядер.
Нормализация и структурирование данных даёт гибкость в обработке не требуя значительных усилий для понимания схемы данных под каждый отдельный сценарий использования. Эту же идею подхватил в 2023 году и Autodesk заявив о начале новой эре гранулярных данных, где больше не будет файловой системы - а проекты будут дробиться до минимальных элементов, как это происходит в дата аналитике и структурированных форматах.
Если CAD вендоры разрабатывают новые форматы и способы работы с данными для своих клиентов, то кто же отвечает за форматы и процессы обработки данных для всей строительной отрасли и кто занимается созданием стандартов по их использованию?
13. В тени ISO и buildingSMART: война за контроль над форматом данных
С проблемами кроссплатформенности данных CAD-MCAD столкнулись впервые специалисты в машиностроительной области, которые часто вынуждены работать со STEP и IGES форматами (идейного предшественника IFC) для передачи информации между MCAD продуктами, где также как и в строительной отрасли, специалисты борются с кроссплатформенностью геометрических ядер. Цитата из статьи “Choosing the Best CAD File Format”:
Все системы CAD также имеют ядро геометрического моделирования, которое лежит в основе родного формата и позволяет создавать геометрию и манипулировать ею. В CATIA используется Convergence Geometric Modeler (CGM), в Creo - Granite (g), а в Siemens NX и SOLIDWORKS - ядро Parasolid (x_t).
Ядро геометрического моделирования точно такое же, как и родной формат с точки зрения чистой геометрии, так как родной формат для любой CAD-системы основан на ее ядре геометрического моделирования. Ты не сможешь добиться лучшей геометрической точности, чем в формате ядра, до тех пор, пока ты используешь ядро для исходного или конечного приложения. Например, если у тебя есть деталь из CATIA и ты хочешь открыть ее в MasterCam, сохрани ее в формате ядра Parasolid, так как именно на нем основано программное приложение MasterCam.
Программы, такие как Revit (основанный на Pro/Engineer) и AutoCAD (основанный на CADDS 3), а также большинство современных геометрических ядер, включая open-source OpenCascade, пришли в строительство из машиностроения. Именно в этой отрасли были созданы стандарты обмена данными, такие как STEP (аналог IFC для машиностроения).
В целом, хотя проблемы машиностроителей при работе с форматами схожи и приводят нас к вопросам использования геометрических ядер, подходы к стандартизации и продвижению этих форматов в машиностроительной и строительной отрасли заметно различаются.
В отличие от строительства, где разработкой и продвижением стандарта IFC занимается организация buildingSMART, стандарты в машиностроении формируются на уровне Международной организации по стандартизации (ISO). В ISO стандарты разрабатываются с равноправным участием всех стран-членов, что делает этот процесс глобальным и более независимым. ISO можно рассматривать как "ООН по стандартизации" с центральным офисом в Женеве.
Стандарт STEP разрабатывается комитетом TC 184, который связан с American National Standards Institute (ANSI). Его история восходит к проекту IGES, запущенному в 1979 году группой пользователей и поставщиков CAD, включая Boeing, General Electric, Xerox, Computervision и Applicon. Проект получил поддержку от Национального института стандартов и технологий США (NIST) и Министерства обороны США, причём разработка финансировалась военно-промышленным комплексом и контролировалась военными. Позже на основе IGES был создан стандарт STEP, а его ответвлением в 90-х стал IFC. В отличие от открытых инициатив, все ключевые решения по разработке стандарта STEP принимались кулуарно, без излишней публичности и шума.
STEP — это откровенно североамериканский стандарт: его использование не навязывается машиностроителям, хочешь — применяй, не хочешь — не проблема. В отличие от него, buildingSMART, изначально созданной в 1994 году для продвижения интересов HOK и Autodesk, со строительным STEP-IFC позиционирует себя как глобальная инициатива, выступающая за интероперабельность и универсальные решения для всего мира.
В отличие от buildingSMART, разработчики STEP не занимаются продажей абонементов или созданием подразделений вроде chapters и rooms, через которые собираются взносы на продвижение параметрического формата без собственного геометрического ядра и семантической онтологии, которая должна сделать то, что не смог осилить семантический веб.
Но даже попытка пристроить STEP-IFC в строительстве, и создание альянсов не даёт преодолеть хаос, созданный обменными форматами. Ситуация дошла до того, что даже сами CAD-вендоры уже не способны поддерживать IFC внутри своих продуктов без использования специальных SDK, о которых мы подробно говорили в статье Борьба за открытые данные в строительной индустрии. История AUTOLISP, intelliCAD, openDWG, ODA и openCASCADE
14. Зачем строителям и заказчикам контролировать данные?
Создание данных в строительстве — это непрерывный процесс генерации параметров и их преобразования в удобочитаемые форматы. Каждая сущность проекта — стена, окно или фундамент — это объект с набором атрибутов, таких как материал, тип, стоимость, объём и площадь. Эти данные нужно где-то хранить, обрабатывать и предоставлять конечным пользователям.
Разработчики CAD (BIM) программ стремятся удержать пользователей в своей экосистеме и с каждым годом будут уводить всё больше процессов обработки данных на облачные хранилища партнёров Amazon, Microsoft Azure и Huawei. Основным маркетинговым преимуществом закрытых систем становится наличие качественно переноса геометрии из геометрического ядра CAD (BIM) решений в облачный MESH формат и возможности импорта/экспорта сторонних форматов других вендоров при помощи дорогих SDK для реверсинжениринга.
Но зачем обычным инженерам, логистам, строителям, прорабам и сметчикам геометрические ядра и облачные технологии? Точности теселлированных форматов хватает для большинства строительных задач, а использование сложных геометрических ядер и SDK лишь усложняет процесс.
Большинство современных графических движков работают именно с треугольными сетками, а не с BREP-геометрией. Ирония заключается в том, что все CAD-вендоры продолжают упорно продвигать сложные геометрические ядра, иногда им не принадлежащие, тогда как визуализация, симуляции и анимация постепенно переезжает в популярные и бесплатные инструменты для некоммерческого использования - Blender, Unity, Unreal Engine и Omniverse.
Если отказаться от параметрической геометрии при обмене и обработке данных в пользу MESH-геометрии, зависимость от CAD-программ и геометрических ядер значительно сократится. Это позволит сделать работу с данными более прозрачной и ускорит развитие уже популярных форматов, таких как OBJ, gLTF, DAE и USD. Осознавая эту тенденцию, CAD-вендоры стремятся удержать пользователей внутри своих экосистем. Для этого они продвигают "удобные" форматы интероперабельности, которые формально позиционируются как открытые. Однако на практике для их экспорта требуется подписка на CAD (BIM) программы, а для обработки — знания API и навыки по маппингу особенностей сложных геометрических ядер.
Сегодня в мире проектирования и строительства сложность доступа к данным привела к чрезмерной инженерии в управлении проектами. Средние и крупные строительные и проектировачные компании вынуждены либо поддерживать тесные отношения с поставщиками CAD (BIM) решений для доступа к данным через API и такие продукты, как Forge и ACC, либо обходят ограничения поставщиков CAD, используя дорогие SDK-конвертеры для реверс-инжиниринга.
Доступ к собственным проектным данным не должен требовать специального ключа, абонентской платы на облачное решение или волшебного заклинания в виде запроса API.
Доступ к информации — это право, а не привилегия.
Тим Бернерс-Ли, изобретатель World Wide Web
Доступ к открытым к данным откроет для строительного бизнеса следующий ящик пандоры, который неизбежно приведёт к трансформация всей строительной отрасли.
15. Уберизация и открытые данные это угроза для строительного бизнеса
Инвесторы и заказчики, финансирующие строительство, в будущем неизбежно поймут ценность открытых данных и аналитики исторических данных. Это откроет возможности для автоматизации расчётов сроков и стоимости проектов, что позволит лучше контролировать расходы и быстрее выявлять избыточные затраты. Например, если объёмы бетона на стройплощадке можно будет автоматически проверять по простым плоским MESH данным проекта со структурированной метаинформацией без использования CAD (BIM) и их сложных геометрических ядер, станет сразу очевидно, насколько завышены сметные расчёты.
Такая открытость и прозрачность данных представляет угрозу для строительных компаний, которые привыкли зарабатывать на непрозрачности процессов и запутанных отчётах, где можно спрятать спекуляции и скрытые издержки за сложными и закрытыми форматами и платформами передачи данных. Поэтому строительные компании вряд ли будут заинтересованы в полноценном внедрении открытых данных в свои бизнес процессы. Если данные будут доступны и легко обрабатываемы для заказчика, их можно будет проверять автоматически, что исключит возможность завышать объёмы и манипулировать сметами.
Потеря контроля над расчётами объёмов и стоимости уже обернулась трансформацией в других отраслях экономики, позволяя клиентам напрямую достигать своих целей. Цифровизация и прозрачность данных трансформировали многие традиционные бизнес-модели, как это произошло с таксистами после появления Uber, с отельерами после прихода Airbnb и с розничными продавцами после развития Amazon, где прямой доступ к информации и автоматизация расчетов существенно снизили роль посредников.
Инвесторы, заказчики и банки уже начали требовать прозрачности и в строительной отрасли. Процесс открытия и неограниченного доступа к данным неизбежен, и со временем открытые данные станут новым стандартом. Поэтому вопросы внедрения открытых форматов будут наиболее востребованны именно у инвесторов, заказчиков, банков и частных инвестиционных фондов (private equity) — тех, кто в итоге является конечным пользователем построенных объектов.
Движение инвестора, заказчика от идеи до готового здания, в будущем будет сродни путешествию на автопилоте - без водителя в виде строительной компании, обещает стать независимым от спекуляций и неопределенности.
Данные и процессы во всех видах экономической деятельности человека ничем не отличаются от того, с чем приходится иметь дело профессионалам в строительной отрасли. Эра открытых данных и автоматизации неизбежно изменит строительный бизнес так же, как это уже произошло в банковском деле, торговле, сельском хозяйстве и логистике. В этих отраслях роль посредников и традиционные способы ведения бизнеса уступают место автоматизации и роботизации, не оставляя места для неоправданных наценок и спекуляций.
В долгосрочной перспективе строительные компании, которые сегодня доминируют на рынке, устанавливая стандарты цены и качества услуг, могут потерять свою роль ключевого посредника между заказчиком и его строительным проектом.
Открытые структуированные данные и процессы станут для заказчиков и инвесторов основой для точных оценок стоимости и сроков проекта, устраняя возможность для строительных компаний спекулировать на непрозрачных данных и сложных форматах. Это одновременно и вызов, и возможность для индустрии переосмыслить свою роль и адаптироваться к новой среде, где прозрачность и эффективность станут ключевыми факторами успеха. Но где в этой истории останется BIM?
16. Существует ли BIM, openBIM, BIM 3 level, noBIM на самом деле или это маркетинговый трюк?
Когда мы говорим о BIM, в голове невольно всплывают образы трёхмерных моделей, инструментов по обнаружению коллизий и просмоторщики моделей в ACC. Но если копнуть глубже, возникает вопрос: а что такое BIM на самом деле? Это набор данных, параметров и процессов или просто маркетинговый слоган? Чтобы ответить на этот вопрос, нужно выйти за рамки аббревиатур и концептов, которые продвигают CAD-вендоры, и взглянуть на суть работы с проектной информацией — данные и процессы.
Любой бизнес процесс в строительстве не начинается с работы в CAD- (или BIM-) инструментах. В любом бизнес процессе мы сначала формируем параметры задачи и определяем требования к будущим элементам: задаём перечень сущностей, их начальные характеристики и граничные значения. Обычно это делается в виде нескольких колонок таблицы, базы данных или списков пар «ключ–значение» (1-2).
И только на основании этих первоначальных параметров с помощью API автоматически или вручную создаются объекты в CAD/BIM-программах (3-4), после чего их вновь проверяют на соответствие исходным требованиям (5-6). Этот цикл — определение, создание, проверка и корректировка (2-6) — повторяется до тех пор, пока качество данных не достигнет нужного уровня для целевой системы - документов, таблиц или дашбордов (7).
Если рассматривать CAD (BIM) как способ передачи параметров, представляющих собой наборы ключей и значений, изначально сформированных вне CAD-среды (1-2), то становится очевидным, что мы работаем фактически с базой данных параметров (2-3, 5-6), которая дополняется различными инструментами и в какой то момент переходит из простых требований в набор элементов с параметрами, которые в CAD программе обрабатываются обычно в виде закрытой базы данных. Подходя к BIM сквозь призму такого определения, мы обнаруживаем принципы, схожие с теми, что применяются в аналитике данных, а также в ETL-процессах (извлечение, трансформация и загрузка данных). Возникает вопрос: в чём же уникальность BIM, если в других отраслях экономики не существует подобных подходов?
Последние 20 лет поставщики CAD позиционировали BIM как что-то большее, чем просто базу данных. Маркетингово BIM продаётся как параметрически инструмент, способный автоматизировать процессы проектирования, моделирования и управления жизненным циклом объектов строительства. Однако в реальности BIM стал больше инструментом удержания пользователей на платформе вендоров, нежели удобным методом управления данными и процессами. Вендоры фактически изолировали качественные CAD (BIM) данные внутри своих платформ, скрывая их за проприетарными API, SDK и геометрическими ядрами. Это лишило пользователей возможности самостоятельно извлекать, анализировать и передавать данные в обход этих экосистем.
Сегодня большинство процессов анализа данных в строительной отрасли аналогичны процессам из других отраслей экономики. Это типичные ETL-циклы (Extract, Transform, Load) и аналитика данных. В банковской сфере, например, данные извлекаются, преобразуются в понятные форматы и загружаются в BI-платформы для визуализации и анализа. В строительстве это были и будут те же самые действия — извлечение данных из баз данных CAD (BIM) программ (Extract), нормализация и структуирование, последующий анализ, трансформация (Transform) и выгрузка в другие системы и базы данных (Load).
Имея полный доступ к базе данных CAD и используя инструменты обратного инжиниринга, мы можем получить плоский набор сущностей с атрибутами и экспортировать их в любой удобный открытый формат, содержащий как геометрию, так и атрибуты проектных элементов, подобно тому как это реализовано в проекте SCOPE. Когда BIM-данные трансформируются в удобные для анализа форматы структурированные представления таблиц, баз данных, DWH, DL — разработчики перестают зависеть от специфических схем данных и закрытых экосистем. Так выглядит будущее строительной отрасли — сбор данных, их анализ, проверка и автоматизация процессов при помощи инструментов аналитики данных.
Информация — это нефть 21 века, а аналитика — это двигатель внутреннего сгорания.
Возможно BIM (CAD) - это не конечная цель, а лишь этап эволюции. Когда специалисты в строительстве осознают, что они могут работать непосредственно с данными, минуя традиционные CAD-инструменты, «BIM» как термин растворится в потоках информации. Мы начнём говорить о гранулированных или структуированных данных строительного проекта, но это уже не будет тот BIM, который мы знаем сегодня.
17. Что будет дальше? Простые форматы и удобные инструменты
Ключевым направлением развития может стать переход к открытым и независимым решениям, свободным от проприетарных SDK и геометрических движков. Вместо попыток "допилить" формат IFC, который остается сложным для работы без специальных знаниях об особенностях формата и специализированного геометрического ядра, индустрии следует обратить внимание на уже существующие универсальные форматы, доказавшие свою эффективность: MESH, OBJ, gLTF, DAE, FBX или USD для геометрии, а также CSV, JSON, XML, XLSX, SQL, YAML для метаданных и параметров.
Будущее строительной отрасли связано с созданием простых и доступных инструментов, аналогичных тем, что появились в сфере 2D-графики в конце 2010х после двух десятилетий доминирования Photoshop. Появление плоских форматов JPEG, PNG и GIF, свободных от избыточной логики внутренних движков 2D-редакторов, привело к развитию тысяч совместимых решений для обработки изображений.
Аналогичным образом, стандартизация и упрощение 3D-форматов и метаинформации будут стимулировать появление множества удобных и независимых инструментов для работы со строительными проектами. Отказ от сложной логики "вендорских ядер" и переход к универсальным, открытым форматам создаст условия для более гибкой и эффективной работы, а также откроет доступ к данным для всех участников процесса строительства.
В Open Source сообществе есть перспективные проекты, которые могут послужить примерами развития лёгких геометрических решателей: SolveSpace с потенциалом работы в браузере, Web-CAD.org на JavaScript, различне бесплатные CSG-редакторы. Особого внимания заслуживает платформа Unity, предоставляющая готовую базу для создания сложных инструментов с возможностью настройки рендеринга и добавления необходимого функционала. В моём примере 2021 года был переработан движок браузерной CAD программы Unity NoteCAD с собственным геометрическим решателем для максимального соответствия функциональности бесплатного онлайн SketchUp. Получился легкий бесплатный продукт с открытым исходным в кодом, с быстрым запуском на любом сервере.
Главный принцип развития отрасли должен заключаться не в создании новых форматов, а в эффективном использовании и доработке уже существующих решений. Важно опираться на интернациональные сообщества, такие как OsArch и FreeCAD, а также поддерживать команды, занимающиеся разработкой открытых геометрических ядер.
Для тех, кому необходима работа с BREP-геометрией, ключевую роль могут сыграть геометрические ядра Open Source, такие как OCC и OGG . А для задач, где достаточно MESH-геометрии, перспективным решением станет использование CGAL, OpenMesh и MeshLib. Для получения и записи данных в различные CAD и MCAD форматы используйте SDK реверс-инжиниринга от таких компаний, как OpenDesignAliance, CADExchanger или HOOPS. Эти SDK были созданы с целью предоставить разработчикам равный доступ к данным и обеспечить всем желающим возможность разрабатывать решения в области CAD и MCAD на уровне ведущих CAD (BIM) разработчиков.
В сочетании с LLM-моделями такие инструменты значительно повысят эффективность процессов создания, преобразования и экспорта данных в целевые системы.
18. Появляение LLM и ChatGPT в процессах обработки проектных данных
В дополнение к развитию открытых форматов и универсальных инструментов, революционные изменения в отрасль обработки данных вносят Large Language Models (LLM), такие как LLaMA, ChatGPT, Gemini и Claude. Эти технологии кардинально меняют подход к работе с проектными данными и аналитикой этих данных, делая процесс обработки и автоматизации доступными для всех участников строительного процесса.
Если раньше доступ к информации осуществлялся исключительно через сложные API и SDK-интерфейсы, требующие специальных навыков программирования, то теперь появилась возможность взаимодействовать с данными на естественном языке.
В течение нескольких лет неизбежно произойдёт демократизация доступа к данным. Простые инженеры, менеджеры и проектировщики смогут получать необходимую информацию из проектных данных в структуированных форматах, просто формулируя запросы на обычном языке. Например, достаточно будет спросить в чате: «Покажи в виде таблицы с группировкой по типам все стены с объемом более 10 кубических метров», — и LLM самостоятельно преобразует этот запрос в SQL- или Pandas-запрос, преобразовав структуированные данные проекта через группировку в нужный формат таблицы, графика или готового документа.
С каждым днем все чаще в строительной отрасли можно будет услышать о гранулированных структурированных данных, DataFrame и колончатах базах данных. Унифицированные двухмерные DataFrame, сформированные из различных баз данных и форматов CAD (BIM), станут идеальным топливом для современных аналитических инструментов. А инструменты вроде Pandas и аналогичные библиотеки для работы с двумерными таблицами и столбчатыми базами данных идеально подходят для использования в LLM благодаря мощным возможностям обработки данных и эффективному индексированию. Такие данные не требуют понимания схем форматов и становятся идеальным источником для RAG, LLM и ChatGPT.
Существенно упростится сам процесс автоматизации – вместо изучения API закрытых продуктов и написания сложных скриптов на Python, C# или JavaScript для анализа или трансформации параметров, теперь достаточно будет сформулировать задачу в виде набора отдельных текстовых команд, которые будут складываться в нужный Pipeline или Workflow процесса для нужного языка программирования.
Больше не будет необходимости ждать выпуска новых продуктов, форматов, плагинов или обновлений от вендорвов CAD (BIM) инструментов. Инженеры и строители получат возможность независимо работать с данными, используя простые, бесплатные и понятные инструменты, в работе с которыми помогут LLM чаты.
Современные инструменты дата аналитики, в сочетании с открытыми форматами данных создадут новую парадигму работы в строительной отрасли, где главным станет не владение определенным программным обеспечением и понимание его API, а умение эффективно формулировать-параметризировать задачи и быстро анализировать полученные данные.
Вместо заключения
Ситуация с интероперабельностью и кроссплатформенностью в строительной отрасли наглядно демонстрирует глубинные проблемы, связанные с передачей и использованием данных между различными CAD (BIM) системами. Ярким примером этого является Autodesk, который активно продвигает открытый формат IFC, но сам не способен обеспечить его корректный экспорт из собственных продуктов и вынужден обращаться к SDK реверс-инжиниринга от OpenDesignAlliance — организации, которая изначально создавалась в 1998 году для противодействия монополии Autodesk над данными. Парадоксально, но эта ситуация вынуждает всех игроков отрасли использовать аналогичные SDK для извлечения и адаптации данных конкурентов CAD решения под свои платформы, что фактически подрывает идею кроссплатформености, ради которой создавался формат интероперабельности IFC.
Формат IFC, призванный стать универсальным мостом между различными CAD (BIM) системами, в реальности выполняет роль индикатора проблем совместимости между геометрическими ядрами различных CAD-платформ, подобно STEP формату, из которого он изначально появился. Несмотря на активное продвижение формата организацией buildingSMART, основные усилия направлены на стандартизацию геометрии (что требует единого геометрического ядра, которого до сих пор не существует), и на унификацию семантики и онтологий для строительной отрасли. Однако эти усилия повторяют нереализованные амбиции концепции семантического интернета, где ожидания значительно превзошли реальность.
Отраслевая специфика усугубляет эту проблему. Строительная отрасль, традиционно отстающая на 10-20 лет в освоении новых технологий от других отраслей экономики, рискует повторить этот путь. Если в сфере IT неудачи семантического веба были компенсированы появлением новых технологий (больших данных, IoT, машинного обучения, AR/VR), то строительная отрасль таких поводов не имеет.
Однако есть и единичные примеры альтернативных подходов. Компания Züblin со своим проектом SCOPE демонстрирует, как можно выйти за рамки классической логики CAD (BIM) систем. Вместо того чтобы пытаться подчинить IFC или полагаться на проприентарные геометрические ядра, они используют API и SDK реверсинжениринга для извлечения данных из различных CAD-программ, преобразуют их в нейтральные форматы, такие как OBJ или CPIXML на базе open source ядра OpenCascade, и далее применяют их в сотнях бизнес-процессов строительных и проектных компаний. Тем не менее, несмотря на прогрессивность идеи, подобные проекты остаются частью замкнутых экосистем, которые воспроизводят логику моновендорных решений. В итоге строительная индустрия снова оказывается в ловушке, где межплатформенные стандарты, подобные IFC, не справляются со своей миссией, а локальные инициативы лишь частично смягчают эту проблему.
И с большой степенью вероятности, CAD-вендорам вновь удастся сместить дискуссию о доступе к открытым данным в сторону "новых" концепций, форматов и альянсов, которые, подобно BIM и openBIM, будут служить прежде всего инструментом удержания пользователей в проприетарных экосистемах, что в очередной раз затормозит рост производительности, и без того непроизводительной отрасли, поскольку ресурсы будут направлены не на упрощение и оптимизацию процессов, а на поддержание контроля над экосистемами и привлечение пользователей к новому концепту.
Цель этого анализа не в критике существующих подходов, а в инициировании дискуссии по главному вопросу — как повысить производительность в строительной отрасли и возможно ли это в принципе. С глубоким уважением отношусь к разработчикам CAD (BIM) решений и компании Autodesk, а также к участникам и членам buildingSMART. Однако, возможно, пришло время отказаться от ожидания новых концепций от ПО вендоров и сосредоточиться на самостоятельном развитии. Освободившись от проблем с доступом к данным, отрасль сможет перейти к современным и удобным инструментам для работы и анализа данных. Это позволит двигаться в направлении, которое ещё в конце 1980-х указал Самуэль Гайзберг.
Традиционные CAD / CAM программное обеспечение нереально ограничивает внесение недорогих изменений в самый начальный этап процесса проектировани. Цель состоит в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции. А затраты на внесение изменений в проект должны быть как можно ближе к нулю.
Это начало дискуссии о трансформации отрасли. Только решив вопросы доступа к данным, мы сможем двигаться дальше к изучению бизнес процессов и их автоматизации.
Открытые данные и форматы неизбежно станут стандартом в строительной отрасли — вопрос лишь времени. Этот переход будет ускорен, если мы все будем распространять информацию об открытых форматах, инструментах доступа к базам данных и SDK для реверс-инжиниринга. Помочь в этом процессе может каждый из вас. Если вы считаете полезной информацию, которую прочитали, пожалуйста, поделитесь ею с коллегами.
Если вы хотите следить за новыми обновлениями и статьями, подписывайте на рассылки на сайте DataDrivenConstruction или подписывайте на рассылку в LinkedIn и Medium.
? Буду признателен за ваши комментарии и мнения! Если какие-то факты и источники вызывают у вас вопросы или вы хотите поделиться собственным взглядом - пожалуйста пишите ваши мысли в комментариях или в личные сообщения. Ваша точка зрения, замечания и комментарии важны для обсуждения. Буду рад продолжить диалог.
? Книга «DataDrivenConstruction. Навигация в эпоху данных в строительной отрасли»
itGuevara
Какие есть Open Source инструменты BIM с поддержкой RDF \ SPARQL (семантика в строительстве)? Типа CIMtool (семантика в энергетике).
ArtemBoiko Автор
Наверно один из самых популярных - ifcOWL. Им занимается buildingSMART, который занимается стандартизацией формата IFC - https://github.com/buildingsmart-community/ifcOWL