Тезисы наших выступлений на конференции ТИМИ 2024 в Санкт-Петербурге:

🔹 Новый этап автоматизации проектирования и валидации моделей должен включать в себя работу по переводу требований в машиноинтерпретируемый вид.
🔹 Это возможно только при условии привязки языка требований к схеме данных, описывающей структуру модели. Иначе это путь в никуда.
🔹 Такой схемой де-факто и де-юре является стандарт IFC (ГОСТ Р 10.0.02).
🔹 В текущих реалиях качественная поддержка открытых стандартов описания данных даст конкурентное преимущество отечественным ПО.
🔹 Российским разработчикам стоило бы отойти от закрытых форматов описания проверок к моделям, так как это ведет к ненужным рискам и неудобствам со стороны пользователей.
🔹 А для улучшения своих позиций над западным софтом вендорам полезнее влиться в работу по тем самым 300 XML-схемам ИМ ОКС, которые планируются Минстроем.

До встречи на Technobuild 100+ и на форуме «Сила платформы»! 💪

👥 @IFC_ru
👥 @IFC_club

🎯 Обогнать, не догоняя

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

Поэтому коллеги из НТЦ "Платформа" пошли другим путем:
1️⃣ Сконцентрировались на узкой и прибыльной специфике - многоквартирных жилых домах.
2️⃣ Создали робот-проектировщик, позволяющий создавать проект здания за день в открытых форматах данных (IFC, DXF) путем задания необходимых параметров и выбора предлагаемых вариантов.

Такое решение может стать «импортоопережающим», так как:
🔹снижается трудоемкость создания чертежей (они генерируются автоматически);
🔹при создании модели учитываются российские нормы проектирования, поддающиеся автоматизации;
🔹таким образом, снизится нагрузка на экспертов, и процесс экспертизы может ускориться (правда для этого понадобится сертификация данного продукта на соответствие нормам);
🔹возможная интеграция этого продукта с российскими ПО позволит выиграть конкурентную гонку среди САПР для ниши МКЖД, а далее и для других типов объектов;
🔹появляется возможность кастомизации за счет того, что до отечественных разработчиков ПО сегодня достучаться легче, чем до зарубежных;
🔹создание модели в IFC позволит стандартизовать данные в проекте с учетом требований заказчика еще на стадии его генерации.

Ну а компаниям, проектирующие МКЖД на стадии концепции и П, первым стоит задуматься о том, какие перспективы их ждут на рынке, после того, как продукт начнут активно применять.

📢 @IFC_ru
👥 @IFC_club

IDS for everyone

Это подробное руководство, посвященное спецификации доставки информации (IDS), стандарту openBIM.

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

📢 @ifc_ru
👥 @ifc_club

#IFC просмотрщик (от Helen Kwok) для VSCode теперь способен обеспечить двустороннюю связь между строкой IFC-данных и ее отображением в окне просмотра.

Теперь при выделении строки с элементом в Visual Studio подсвечивается соответствующий элемент в модели, и наоборот!

Кроме того, любые изменения в файле IFC будут сразу обновлять модель.
Фактически мини-редактор IFC прямо в среде разработки.

📢 @IFC_ru

О внешних ссылках в IFC

Благодаря потомкам класса IfcExternalReference стандарт #IFC позволяет вставлять ссылки на различные источники информации. Это могут быть ссылки на библиотечную информацию, чертежи, инструкции и прочие документы прямо в модели IFC с привязкой к конкретным элементам.

Кроме того, на базе IFC можно создать сводную модель, сформированную из одних лишь ссылок на другие модели (по аналогии с файлом NWF в Navisworks).

Функционал создания сводной модели реализован в бесплатном просмотрщике XbimXplorer. Как выглядит внутрянка такой сводной модели - см. скриншот. Для этого используется класс IfcDocumentInformation, в атрибутах которого прописываются модели, входящие в состав сводной (подчеркнуто красным).

✈️ Большинство ПО эти возможности не поддерживает, оставляя IFC лишь роль отображения геометрии и свойств элементов. Но развивая далее мысль о ссылках, в теории появляется возможность формировать информационную модель ОКС как "совокупность взаимосвязанных сведений, документов, материалов". Такой файл в данном случае будет служить неким структурным скелетом ИМ ОКС, к которому крепятся остальные модели по разделам и вся необходимая документация, образуя те самые информационные контейнеры по ISO 19650.

📢 @IFC_ru
👥 @IFC_club

Простой способ сравнения версий модели

🔍 С помощью Get The Code от That Open Company появляется возможность создавать инновационное и в то же время простое решение, позволяющие загружать две версии модели в просмотрщик и сравнивать их, передвигая слайдер.

Благодаря ему сравнение геометрии в модели #IFC становится более удобным и простым.

✈️ Так, открытые решения помогают индивидуальным разработчикам внедрять функционал, который им необходим, без лишних затрат и с адаптацией под свои задачи, предпочитая максимальную свободу в развитии продукта. А появление на рынке удобных инструментов на базе OpenSource стимулирует коммерческих разработчиков ПО к более активной работе над улучшением своих BIM-продуктов.

Если вы видели подобную функцию в каком-либо ПО, напишите в комментариях.

📢 @IFC_ru
👥 @IFC_club

🔍 BIMчат с моделью с помощью ИИ. Двигаемся дальше.

Помните проект по внедрению ИИ для работы с данными в модели?

Дарья Гречишникова (ВитроСофт), победитель конкурса ТИМ-лидеры 2024, добралась до того, что найденные по запросу элементы теперь отображаются во вьюере. А по полученным таблицам можно найти нужный элемент, воспользовавшись поиском.

Также есть возможность поправить сгенерированный код руками и запустить его снова.

Это ли не круто, коллеги? И все это делает один человек (а мы немножко тестируем).

Всё еще достаточно сырое, и много предстоит дорабатывать. Но тут важен сам факт, что это работает.

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

📢 @IFC_ru
👥 @IFC_club

Как правильно выбирать ПО для анализа моделей

Поделимся мыслями для тех, кто рассматривает отечественные ПО для дальнейшего приобретения.

Мы тестировали разные программные продукты. И наш текущий вердикт для них таков:

Отечественные ПО для анализа моделей сегодня находятся в стадии бета-тестирования.

Но у всех из них есть большой потенциал, ценные функции и неоспоримый плюс: они ближе к нашему пользователю и нашим реалиям.

Так, например, в силу надвигающейся государственной "XML-изации" они быстро сообразят и напишут необходимый инструментарий для работы с XML.

На что следует обратить внимание при выборе ПО:

1️⃣ Отзывчивость разработчика. Во время тестирования и в дальнейшей работе он охотно собирает обратную связь от пользователей, своевременно исправляет баги и добавляет необходимый функционал.

2️⃣ Нацеленность разработчика на удобство и простоту использования. Например, реализовать функционал по обновлению файла в сводной модели можно в 10 кликов, а можно одним кликом или вообще автоматически. Такие мелочи в конечном счете сильно влияют на вашу продуктивность. Сюда же отнесем и приятный интерфейс.

3️⃣ Отказ от изобретения велосипеда. Разработчик понимает, что выдумывать свои "новинки" не имеет смысла, так как большинство пользователей применяли иностранное ПО и привыкли к нему. Разумнее сделать точно так же. Во многих ПО есть функционал, который давно себя зарекомендовал и менять его обычно не приводит ни к чему хорошему. Например, такая простая функция как "видовой куб". Удобно и понятно.

4️⃣ Инновационность. Данный пункт не противоречит предыдущему. Если разработчик ПО ведет работу над новым и перспективным функционалом, к примеру, применение ИИ для работы с моделью или отслеживание изменений в версиях моделей с помощью слайдера, то это большой плюс.

5️⃣ Скорость обработки данных. Проблемы со скоростью есть у всех. Здесь важно понаблюдать, активно ли разработчик работает над ней, увеличивается ли скорость проверок на коллизии, какова быстрота загрузки моделей и так далее.

6️⃣ Приверженность открытым стандартам передачи данных, как фундаменту технологии (#IFC, #BCF, #IDS и т.д.). Это сделает BIM таким, каким он должен быть. Открытым, прозрачным, доступным.

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

Есть еще один пункт, но о нем будет отдельный пост.

📢 @IFC_ru
👥 @IFC_club

О роли OpenSource наработок в программных продуктах

Как и обещали, седьмой пункт, на который следует обратить внимание при выборе ПО:

7️⃣Объем OpenSource решений в ПО.

OpenSource-наработки сегодня играют важную роль в развитии IT-продуктов, особенно для индивидуальных разработчиков. И собственные разработки "с нуля" при современном ритме почти не встречаются.

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

Развитие такого продукта будет затруднено в виду того, что разбираться в OpenSource-библиотеках бывает трудно, и они тянут за собой баги.

Поэтому перед приобретением ПО стоит спросить разработчика, на какой базе развивается его продукт.

Яркий пример такому применению OpenSource-решений: внедрение готовых IFC-вьюеров и BCF-редакторов замечаний в различные платформы.

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

📢 @IFC_ru
👥 @IFC_club

В ТК 505 стали обсуждать необходимость актуализации СП 333.

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

1️⃣ Идти по пути создания универсальных обязательных государственных атрибутов в одном СП - тупиковый путь. Таких атрибутов не существует из-за огромного разнообразия видов ОКС.

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

2️⃣ СП333, исходя из названия, должен описывать правила формирования ИМ ОКС, а не требования к ней. Требования отвечают на вопрос "что?" (должно быть в модели). Правила - на вопрос "как?".

Как и каким образом должны формироваться сведения, документы и материалы, входящие в ИМ ОКС описывается в ПП РФ 614 "О правилах формирования и ведения ИМ ОКС..."

Зачем тогда еще раз писать правила в СП, если они описаны в постановлении?

Так, есть риск получить смысловые коллизии с ПП РФ 614 либо фактический повтор положений.

Исходя из 1 и 2, напрашивается вывод, что нет смысла переписывать документ, актуализируя атрибутивный состав. И сегодня нужно писать не правила формирования ИМ ОКС и не требования к каждому документу/элементу/файлу.

Нужно поменять сам подход с "административно-требовательного" на методический и писать правила создания цифровых требований к ИМ ОКС, которыми будут пользоваться все.

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

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

Все это реализуется на базе открытых стандартов IFC и IDS. И хотя подход еще достаточно молодой и не единственный, но уже сейчас в России и мире есть работающие IT-решения и есть пользователи, которые используют это на практике.

📢 @IFC_ru
👥 @IFC_club

Повторяешь информацию в модели?

Раскроем 4ый пункт поста о связах.

Вы наверняка сталкивались с необходимостью наполнения элементов избыточными свойствами.

К примеру, присвоение элементу воздуховода марки инженерной сети приводит к дополнительной работе и возможным ошибкам. Достаточно скопировать элемент, забыть исправить марку системы - и мы получаем расхождение данных.

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

🔍 Эффективнее и проще сгруппировать элементы в систему (IfcDistributionSystem) с помощью связей. Марка задается один раз всей системе и распространяется на вложенные элементы. Так легче отследить корректность данных и уменьшить вероятность ошибок.

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

✈️ Но почему многие требуют дублировать информацию непосредственно в элемент? И как решить эту проблему?

👥 @ifc_ru
👥 @ifc_club

Причины излишнего дублирования данных в модели

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

Корни этой проблемы лежат в следующем:

1️⃣ Мы слишком поверхностно воспринимаем концепцию, что модель - это элементы с геометрией и свойствами.

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

В результате появляются многочисленные СП, ПНСТ и прочие требования, где всё заточено на максимальное наполнение элементов атрибутами. Это вызывает допнагрузку на исполнителей, которым приходится «вручную» контролировать такие данные, что требует неоправданных издержек.

И вторая причина:

2️⃣ Мы упираемся в несовершенства ПО, которые не позволяют организовать более эффективную работу с данными.

Многие ПО сегодня ограничены в части создания и обработки правильной структуры IFC-моделей.

Яркий пример этому: Свойства типов, инженерных систем, зон, квартир, групп, материалов и т.д. заносятся не в специальный для этого класс, а в каждый элемент по отдельности.

И некоторые отечественные разработчики зачем-то тянут эти «костыли» в свои системы.

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

Решение может быть следующим:
🔍САПР необходимо научиться формировать связи по структуре IFC.
🔍ПО для анализа моделей (чекеры) должны научиться извлекать данные с применением связей.

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

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

👥 @ifc_ru
👥 @ifc_club

Ежемесячный подкаст "BIM-среда" в IFC Клубе!

🗓️ Среда, 6 ноября, в 16-00 МСК

🔊 Тема: "IFC для объектов улично-дорожной сети"

Гость:
👤 Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"

Поговорим о:
🛑применимости IFC для объектов транспортной инфраструктуры;
🛑требованиях к классификации элементов;
🛑возможностях экспорта в IFC из отечественных ПО;
🛑принципах автоматических проверок;
🛑и перспективах использования IFC-моделей для дорог и улиц.

Присоединяйтесь!
Встреча будет проходить в группе в формате видео-чата.

👥 @IFC_ru
👥 @IFC_club

Применение стандарта IFC для объектов улично-дорожной сети (Дмитрий Ушаков, МКУ "УКС г. Екатеринбурга")

👥 @IFC_ru
👥 @IFC_club

✈️ Запись прошедшего эфира "BIM-среда"

✈️ Тема: Использование стандарта IFC для объектов улично-дорожной сети
✈️ Гость: Дмитрий Ушаков, главный специалист МКУ "УКС г. Екатеринбурга"

📹 Youtube
📺 Rutube

✈️ Презентация

Тайминг:
00:01 Введение и представление докладчика
01:29 Основная деятельность Дмитрия
04:12 Специфика работы с улицами
06:26 Использование стандарта IFC
08:09 Развитие отечественных программ
10:49 Проблемы и решения
11:41 Введение в IFC
12:54 Примеры использования классов и предопределенных типов
13:55 Проблемы с детализацией моделей
15:22 Дорожные знаки и текстуры
17:18 Земляные работы и дорожная одежда
20:31 Маппинг и стандартизация
22:40 Вопросы по маппингу
25:00 Возможности экспорта и маппинга в Кредо
26:21 Маппинг и классы в Кредо
27:13 Различия в обработке 2D и 3D информации
28:43 Проблемы с геометрией и атрибутами
30:38 Необходимые функциональные возможности
33:53 Программное обеспечение для проверки
36:56 Бесплатные просмотрщики IFC
38:29 Проверка цифровой модели
39:22 Ручная и автоматическая проверка
41:30 Проверка атрибутов и объемов
43:30 Коллизии, проверка, автоматизация
50:38 Заключение
50:54 Ответы на вопросы