🌐Что не так с Design Transfer View (DTV)?

Последнее время в IFC Club периодически вижу обсуждения, в которых пользователи выгружают свои модели в IFC 4, используя MVD (Model view definition, определение модельного вида) - Design Transfer View.

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

☝️А это имеет значение.

📍MVD как подмножество схемы IFC определяет не только "срез" схемы данных для выгружаемых BIM-моделей, но и дальнейшее их поведение при импорте в BIM-систему

📍Для IFC версии 4 создавалось несколько таких MVD, Design Transfer View одна из них. Если очень сильно упрощать, его основной идеей было получение возможности редактирования IFC-моделей в нативном виде. Поэтому туда передаётся очень много данных, необходимых для восприятия модели BIM-системой как "родной". Не буду углубляться в технические нюансы, но вы даже можете заметить насколько эти модели "тяжёлые".

🎧Можно ещё для упрощения понимания в какой-то степени сравнить это как FLAC формат цифрового звука, который передаётся "без потерь".

❗️Проблема заключается в том, что с DTV самые распространённые BIM-системы правильно не взаимодействуют.
Официальный разработчик MVD - buildingSMART - в своих публикациях и на форуме говорит, что этот MVD является экспериментальным и должен использоваться с осторожностью. И если вы его используете, вы должны чётко понимать для чего вы это делаете. Просто загляните на спецификации MVD и вы обнаружите, что напротив DTV стоит статус "Draft". Используя его бездумно вы рискуете столкнуться с проблемой потери данных или некорректного их восприятия вашим BIM-ПО.

❓Что делать?

✅Использовать только официальный MVD - Reference View 1.2.
Он адекватно поддерживается большинством BIM-систем, выгружает только необходимую информацию и риск потери информации в нём ниже.
Да и вес файла модели ниже, чем у DTV.

Естественно, речь уже не идёт про ifc4x3, MVD которых уже есть и другие определения модельных видов, хотя Reference view там тоже есть (и даже входит в основную документацию стандарта)

#информационнаясреда

🔍Почему я не люблю LODы (лонгрид)

Многие уже давно привыкли к этой аббревиатуре, обозначающей уровни проработки элементов информационной модели. Концепция Level of D* (development, detail, design...) по большому счету, пришедшая к нам из первых BIM-методологий, на мой взгляд, имеет ряд "нюансов".

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

🔻Необходимость в спецификации по классификации. Возьмите любую LOD-спецификацию, например от BIMForum, она, наверное, одна из самых известных. Что мы видим? Уровни детализации элементов расписываются применительно к отдельным классам по классификатору CSI Uniformat и Omniclass! В РФ единственная такая "официальная" спецификация есть в СП333...2020 и привязывается она к абстрактным сущностям, там нет конкретных классов или ссылки на классификацию. При отсутствии нормальной связи с классификацией возникает ряд сложностей, как с идентификацией элементов, к которым выставляются требования ("а вот у меня есть вот такая "хрень", а в требованиях про нее ничего нет, мне какие атрибуты в ней заполнять?"), так и с последующим контролем качества, поскольку для проверки заказчику точно так же надо понимать "что проверять". Соответственно надо такую спецификацию иметь, а бездумно использовать "забугорную" классификацию, не понимая как вы ее будете использовать ведет к повышению трудозатрат (а равно и стоимости) на работы, результат которых не будет использован по назначению.

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

🔻Восприятие как лучше/хуже. Многие BIM специалисты в своем опыте встречали требование как "сделайте мне LOD500" чтоб "выглядело круто". Чаще всего люди просто видели избитую картинку про LODы в интернете, где показывалось развитие какой-нибудь цифровой вундервафли в разрезе LOD и, естественно, условный "500" там был самый "красивый". Ну в итоге и получили абсолютно неверную трактовку подхода.

↗️Я не знаю, связано ли это, но... еще в прошлом году был опубликован международный стандарт ISO 7817-1:2024 Level of Information Need - Concept and Principles - Уровни информационной потребности. Понятие далеко не новое, и встречается в стандартах серии ISO19650, но мало у кого было понимание что это и с чем это едят.

❗️В этом стандарте черным по белому написано (в разделе 5.2) следующее (автоперевод):

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

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

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

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

#информационнаясреда

🎄С новым BIMом!

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

Честно скажу, я не подводил итоги в этом году. Лично для меня год был не самым простым в профессиональном плане. Было много свершившегося и не свершившегося, что еще предстоит сделать в следующем году. Я не хочу делать обзор важных тем этого года, вы найдете их в множестве каналов-аггрегаторов. С вами я просто поделюсь своими субъективными выводами.

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

🌚Полное BIM-ное затмение. Наверняка вы наблюдали когда-нибудь как луна перекрывает солнце, или земля перекрывает свет от солнца и затмевает лунный свет. Это называется затмением. Вот так и в этом году - активное внедрение инструментов ИИ затмило своим взрывным хайпом все эти "ваши сложные BIM-технологии". Экспансия нейросетей, которые еще даже не подошли к пику чрезмерных ожиданий по кривой Гартнера, отодвинула развитие BIM в компаниях на второй план. Но как и в примере с астрономическим затмением, где все равно видно затемненный объект, BIM по прежнему остается в контексте отраслевого интереса к цифровому развитию. Затмение всегда заканчивается, закончится и это. Особенно, когда придет осознание, что BIM-данные - лучшая "пища" для ИИ.

🌐 Расширяется интерес к открытым BIM-данным. И на отечественных ресурсах, и на зарубежных платформах для общения стало заметно больше интереса к работе с открытыми форматами данных, такими как IFC. Развитие нативных платформ для работы с IFC-моделями, таких как bonsai, применение IDS для машиночитаемых требований к IFC-моделям, обмену замечаниями в форме BCF и много всего другого было заметно больше среди публикаций и постов, в том числе и в IFC-клубе - самом большом сегодня openBIM сообществе в России. Вендорозависимость BIM по прежнему высокая, но на мой взгляд она значительно сокращается с приходом новых цифровых инструментов и необходимости их взаимодействия между собой. Надеюсь, что "аппетит приходит во время еды" и с ним придет и осознание больших возможностей и перспектив применения открытых форматов. Не только для синхронизации и поиска коллизий.

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

❤️А еще берегите себя и ваших близких. Пусть они дают вам мотивацию быть сильнее в новом году. И у вас все получится.

С наступающим новым 2026-м годом!🍾

А картинка из вроде бы не очень далекого 2021-го НГ. Кто то в группе делал елочку, я поставил ее у себя в модели. Пусть хоть у меня новогодняя иллюстрация будет сделана не в ИИ.

#информационнаясреда #итоги

⚖️О легитимности BEP

Недавно столкнулся с недопониманием коллег о юридическом статусе такого документа как план информационного моделирования (ПИМ) или, как его знают во всем мире - BIM Execution Plan (BEP).
На этапе согласования корпоративного стандарта, определяющего правила разработки такого документа на строительных проектах компании, получил вопрос, ответ на который вроде бы очевиден, но как оказалось не для всех.

🧐 Зачем нам этот документ, если в информационных требованиях заказчика (EIR) и так все написано? На каком основании участник проекта должен ему следовать?

✅Действительно, EIR, определяющий требования к BIM, как правило является частью контракта на проектирование и в нем должны быть указаны все выходные параметры ожидаемого результата. И его легитимность не оспаривается.

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

☝🏻И вот для этого и формируется такой документ как BEP, который, по сути, и определяет «как» будет обеспечено достижение целей, определенных информационными требованиями заказчика силами участников проекта из разных юридических лиц.

⚠️Но если этот документ уточняет ответственность участников проекта, он должен быть юридически узаконенным. Иначе при любых судебных разбирательствах он не будет приниматься к сведению. Ведь есть EIR, он является частью контракта. По нему и будут спрашивать.
🖋Поэтому BEP это не просто табличка с перечнем участников, матрицы ответственности и графиком передачи моделей. Это полноценный юридический документ, согласованный всеми участниками и закрепленный юридическими механизмами. Допсоглашением к контракту, например. И любые изменения в него точно также должны быть проведены через механизмы легитимизации.

⛔️Соглашусь, минус есть – лишняя бюрократия. Но без этого возникает серьезный риск того, что договоренности будут саботироваться участниками и никакой законной возможности заставить их работать по согласованным правилам не будет.

ℹ️Я встречался с подходом, при котором BEP – «живой» документ, который является чем-то вроде канбан-доски, на которой участники постоянно что-то меняют и уточняют. На мой взгляд это возможно при ограничении участников проектной командой в одной компании, использование BIM в которой ограничивается парой базовых сценариев.

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

#информационнаясреда

🎯Как связать цели с атрибутами?

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

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

Возьмем для примера сценарий 3D-координации. Когда мы проверяем модель на коллизии, мы можем ориентироваться на имя файла или классы элементов. Во многих случаях так и поступают, например, когда один файл модели — это один раздел проекта или, может быть, просто формируют проверки по категориям элементов Revit. Но что есть категория или имя файла с точки зрения машины? Это их атрибуты. Просто мы не вносим их в соответствующие поля, но машина это уже знает. И по сути это неявные части информационных требований.

Таким же образом можно использовать множество различных классификаторов (например, классы IFC, ISO81346, КСИ, KKS, Uniformat, Omniclass и т.д. и т.п) в качестве атрибутов элементов и детализировать проверку через поиск соответствующих этим классам элементов. Просто здесь это все уже явное информационное требование.

⚠️Все что я сказал выше – не ново. Просто как правило большинство указанных требований не увязано с целями. Чаще всего в каком-нибудь EIR мы видим просто перечень атрибутов, который требует заказчик. Но как они будут использованы нигде не говорится. Возвращаясь к примеру выше - какие конкретно атрибуты участвуют в проверке на коллизии? Кто и когда поставляет эту информацию в модель? Обычно это не раскрывается.

❓Так почему бы не взять и не связать цели с атрибутами через те же самые таблицы в требованиях?

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

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

❗️Далеко за примерами ходить не надо, так, например, сделали в ПНСТ 909-2024 (требования к ЦИМ на жилые здания), иллюстрация как раз оттуда. Только единственное, что сценарии в этом стандарте просто описательные и удостовериться действительно ли нужны указанные атрибуты для их реализации не получится. Но вы в своих документах вполне можете их отражать, вам же будет удобнее.

#информационнаясреда

🎓База знаний на статичном вебе

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

🔐Но не всегда есть возможность сделать, например, сайт в открытой сети и раздать его пользователям. Так случалось и у меня, когда я работал в крупной компании, где сеть абсолютно закрытая, а чтобы выбить себе сервер, с которого был бы доступен веб сайт базы знаний, требуется много бюрократии, времени, нервов, да еще и денег (да, денег!)

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

❇️ Я пошел немного другим путем и решил сделать базу знаний на статичном веб-сайте, который разместил в защищенной сети в общедоступной папке компании. Это позволило мне предоставить коллегам доступ к информации в удобочитаемой веб-среде без необходимости разворачивания веб-сервера и всей сопутствующей инфраструктуры. Потом еще и кнопочку с программистом прикрутили в интерфейс СОДа, которая переводит его сразу на веб-портал, работающий "оффлайн".

🌐А для разработки такого веб-сайта я использовал open source платформу Quarto, которая используется (обычно) для публикации научных исследований в различных форматах, в том числе и веб. Но она оказалась очень пригодной и для формирования базы знаний.
Синтаксис Quarto довольно простой, потому что использует язык разметки Markdown. Этот язык используется в очень многих программах для написания и редактирования текстов в веб-формате (в том числе, например, Notion, Obsidian и т.п.).

🖥Чтобы начать работать требуется установить:
- Quarto (как основной обработчик);
- Python (нужен не для всего, но если есть возможность, стоит поставить);
- Visual Studio Code и плагин Quarto;
👨‍💻А затем просто начинаете описывать страницы, используя визуальные инструменты – да, здесь не требуется досконально знать правила синтаксиса Markdown (хотя, в целом это полезно). Есть превью, чтобы посмотреть, как будет выглядеть то, что вы сделали. Вот тут подробная инструкция как создать первую веб страницу.
Меню и содержание наполняются автоматически из метаданных ваших страниц.
↗️В итоге получается полноценный статичный веб-портал, который не требует веб-сервера и запускается в оффлайн режиме.

⚠️Минус есть – здесь нет встроенных редакторов, позволяющих прямо в браузере создать и отредактировать статью, как вики. Если вы инструкции обновляете не так часто, то и не страшно. Ну и надо немного изучить функции Quarto и какие фичи в ней есть. Но на это прям одного дня обычно хватает.
👀Ну и да, quarto иногда медленно открывается с российских IP адресов. Но это проблема решаемая 😇

❗️Резюмируя – если вы еще ведете ваши инструкции в ворде, потому что нет возможности размещать базу знаний в вебе, пробуйте статичный сайт. Чуть труднее делать, зато гораздо удобнее использовать.

P.S. Кстати говоря, весь сайт и справка по Quarto сделана в нем же, так что здесь же вы сразу можете познакомиться с примером такой базы знаний на статичном вебе.

#информационнаясреда

✈️ Про работу в Telegram

👋Коллеги, друзья, товарищи, прошу минутку вашего внимания.

❗️Ввиду тревожных новостей про возможные трудности работы Telegram в России, подкрепляющимися сообщениями о массовых проблемах в работе сервиса, хочу вам сказать, что пока планирую наблюдать за развитием событий и, пока это еще возможно, буду продолжать писать свои мысли здесь.
Надеюсь, что и у вас сохранятся желание и возможность читать мой канал и дальше.

✍🏻 При каких-то изменениях буду держать вас в курсе!

@bimspoint

🖋 Про ИУЛы, УКЭП и форму основной надписи

Пост-рассуждение

✉На прошлой неделе по всем профильным каналам пролетели новости о письме Минстроя, в котором указывается, что, попросту говоря, любые информационно-удостоверяющие листы (ИУЛы), которыми заменяли электронные подписи проектной документации при сдаче в экспертизу больше не должны приниматься. Вслед за этими новостями та же ГГЭ сразу сообщила, что с 1 марта больше не принимает документацию, «подписанную ИУЛами».

👥Возможность подписываться в ИУЛах в свое время было своего рода льготой для небольших проектных команд, позволяющей не тратить свои бюджеты генерацию и продление усиленных квалифицированных электронных подписей (УКЭП). Это определялось ГОСТ, это допускалось экспертизой. Теперь времена меняются и подписывать документацию всем придется УКЭП. Благо, есть бесплатная возможность сделать себе УКЭП в приложении «Госключ».

💬Мнение на этот счет у многих специалистов расходятся, лично мне кажется, что просто время уже наступило. Большинство из нас имеет смартфоны и доступ в «Госуслуги», на ПК давно существует множество способов подписи документов при помощи УКЭП. В крайнем случае, например для консервативных специалистов с "кнопочными телефонами" можно сделать УКЭП и за счет фирмы, если этот специалист так важен, при этом речь идёт о единицах и на таком фирма не разорится.

🤔Мне вот интересен другой аспект этого вопроса. Если уж нас потихоньку переводят на подписание УКЭПами, какой смысл в подписях в форме основной надписи документов? Отдельные экспертизы по-прежнему отказываются рассматривать документацию, если в форме основной надписи отсутствуют «живые» подписи или хотя бы факсимиле (сделанный по лекалу в автокаде). Объяснялось это тем, что эти документы будут распечатаны и переданы в архив и по правилу на них должны стоять подписи специалистов.

💡Если файл подписывается целиком, то подписывается всё его содержимое, т.е. если это том ПД, то все листы считаются подписанными. Так не станет ли логичным следующий шаг – внесение изменений в ГОСТ 21.101 , в котором указать, что при подписании ПД с применением УКЭП собственноручные подписи не являются обязательными, а рассматриваться такая документация может только в электронном виде? А следующим этапом – внесение изменений в саму форму, где должны появиться блоки для установки штампов подписывающих УКЭПом специалистов, чтобы при печати документа, сведения о его подписании сохранились «на бумаге»?

ℹ️Иначе это получается, как в свое время в школах заставляли учителей вести «электронный журнал», но параллельно все равно заполнять бумажный, «а то мало ли чего».
*Иллюстрация сгенерирована ИИ.

#информационнаясреда #мысли

📊 О дашбордах и достоверности

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

🤔 Но я решил порассуждать о другом – о достоверности тех данных, которые мы видим на этих дашбордах.

📊Одним из самых первых удобных инструментов визуализации данных стали диаграммы в офисных пакетах. В частности – в электронных таблицах. Просто потому, что это самый доступный инструмент формирования диаграмм самого различного вида и наполнения.
Более сложные системы, такие как Power-BI, требуют уже определенной подготовки, в зависимости от задачи, но предоставляют гораздо больше возможностей для работы с данными.
При этом Power-BI это один из самых распространенных инструментов на рынке BI-систем. Помимо него есть еще множество платных и бесплатных конкурентов: Tableau, Qlik, Datalens, superset и т.д. Я как раз пользовался последним, который распространяется как open-source решение. Все они могут использовать как данные из различных баз данных, так и Excel-таблицу в качестве источника.

⚠️Главная проблема в работе с дашбордами это не их формирование и даже не структура данных (хотя это тоже добавляет трудности). Главное – это то, откуда данные приходят в источник.

⬇️Когда источником данных является электронная таблица, которую, например, прислали по почте без какой-либо подтверждающей достоверность информации (ЭЦП, ИУЛ, отчет из СЭД и т.п.), содержание такой таблицы может быть скомпрометировано и тогда таким данным верить нельзя. Если в качестве источника данных является база данных из какой-либо информационной системы, где люди вносят информацию вручную «в карточки» каких-либо объектов – такие данные точно так же не являются достоверными. По сути разницы с электронной таблицей нет, просто поменялась форма внесения данных.

❇️ Решения у этой проблемы разные, но я приведу на мой взгляд парочку важных.

1️⃣ Первое – это обеспечить получение автоматически генерируемых данных. Банальный пример, вам точно понятный: если это данные о геометрии объектов из BIM-модели, то такие данные должны быть получены автоматически. Хотя это напрямую и не влияет на достоверность, но отчасти все же сюда же можно отнести и классифицируемые данные, т.е. получаемые из многочисленных справочников, что повысит как удобство работы вносящего, так и нормализованность данных. Добейтесь минимума ввода «руками».

2️⃣ А второе – для меня даже более важное – обеспечить подтверждение данных бизнес-процессом. Как пример, в среде общих данных, где любой процесс можно грамотно маршрутизировать, получать автоматические статусы, замораживать от изменений и видеть всю цепочку согласований. Если нет возможности – хотя бы через цепочку подтверждений по электронной почте. Без наличия внешнего подтверждения данным доверять не стоит.

ℹ️ Пример из практики. На прошлой работе была задача расширить аналитику план-факта системы управления проектами Plan-R через дашборды. Я сформировал расширенные дашборды, которые работали напрямую с базой данных (PostgreSQL). И все план-фактные значения мгновенно отображались в дашборде, с одним важным НО: отражался только подтвержденный «факт». А для этого внутри самой системы существует механизм подтверждения, при наличии у проверяющей стороны доступа. Разработал регламент, описал бизнес-процесс и показал пользователям как он работает в системе. Таким образом достоверность данных подтверждается самим заказчиком прямо внутри информационной системы и таким данным в дашбордах уже можно доверять.
*Иллюстрация сгенерирована ИИ.

#информационнаясреда

💳Про требования к ЦИМ АГР

💬Вот уже второй месяц сообщество взбудоражено новостью о том, что со 2 апреля сего года вступают в силу новые требования к материалам для согласования архитектурно-градостроительного решения (АГР) в г. Москва, в частности по новым требованиям должны предоставляться цифровые информационные модели (ЦИМ) в формате IFC, соответствующие утвержденным требованиям.

🔍Я изучил эти требования и они по структуре и формату представления довольно похожи на требования к ЦИМ от Мосгосэкспертизы, выполнение которых обязательно для проектов, финансируемых городом. Но вот для согласования АГР в Москве, как я понимаю, попотеть придется всем, вне зависимости от способа финансирования проекта. Посмотреть эти требования вы можете на портале СтроимПросто .

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

1️⃣ Не опять, а снова. Все свойства элементов моделей – пользовательские. Более того – пунктом 5.3.16 системные свойства классов IFC (входящие в наборы Pset_, Qto_) при рассмотрении не учитываются! Но при этом, разбор элементов по классам IFC используется, а класс IfcBuildingElementProxy вообще запрещен, за исключением абстрактного понятия как «Вспомогательное 3D-тело».

🆗 Да, пользовательские свойства допускаются стандартом IFC, но неиспользование системных параметров снижает интероперабельность между системами. Национальное расширение – ок, ну добавляйте туда те свойства, которых нет в стандарте IFC.
❓Но для чего выводить туда количественные параметры (типа RUS_Height, RUS_Width), которые автоматически рассчитываются из геометрии элементов и выводятся в стандартые свойства наборов типа Qto_*? К тому же можно и ручками в них что угодно вписывать.

🤷🏻‍♂️Да и в целом без системных параметров можно игнорировать и сами классы IFC (кроме базовых проекта). Классы то имеют свою специфику и типизацию, атрибуты и специфические набор свойств. Но если нет разницы, зачем платить больше нет смысла и разделять, тем более что классификация по МССК по прежнему требуется. Конечно, это не смертельно, но это однозначно повышает трудоемкость при формировании модели, утрачивая при этом преимущества, которые дает стандарт IFC.

2️⃣ Требования к технико-экономическим показателям (ТЭП) в XML. Несмотря на то, что в требованиях явно указывается, что ЦИМ АГР является «источником формирования ТЭП», связи между XML-схемой и элементами ЦИМ как таковой не усматривается. При этом мы все понимаем, что XML формат текстовый. Таким образом, все что необходимо для получения XML из ЦИМ можно получать из ЦИМ. А в данном случае мы получаем два разорванных источника данных, которые могут просто друг другу не соответствовать.

💁🏻‍♂️Лучше бы задали требования к ЦИМ АГР в части ТЭП и сами выгружали из них нужные ТЭП. Тогда бы и источник не дублировался, и нагрузка на разработчика была бы ниже. Хорошо, что есть умельцы, которые делают бесплатные сервисы для формирования такой XMLки. Но исходную проблему это всё же не решает.

😒Возвращаясь выше, мне эта ситуация с пользовательскими свойствами напоминает Оруэлловский новояз. Ведь метафорически, стандарт IFC это единый «язык», который можно дополнять, так скажем «диалектами», т.е. свойствами, которых не хватает. Но тотальное игнорирование системных параметров приводит именно к такому неутешительному сравнению…

#информационнаясреда

🔃 Верификация VS Валидация BIM

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

📚Почитать подробнее про саму валидацию и верификацию вы можете во внешних источниках. С точки зрения различия этих терминов, мне в целом нравится такое объяснение:

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

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

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

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

🤔При этом вы частенько можете встретить ситуацию, при которой то, что вроде должно быть верификацией, называют валидацией: например, валидация IDS, валидация IFC… Я пришел к такому выводу - просто зачастую в IT сфере валидацией называют проверку данных. Я же оперирую терминологией системы менеджмента качества, т.к. данные в нашем случае — это способ представления содержания, качества которого мы добиваемся.

☝🏻Почему важно их различать? Потому что верификация в большинстве случаев должна предшествовать валидации. Без подтверждения того, что модель выполнена корректно, ожидать от нее получения требуемых эффектов не приходится. Валидация модели без предшествующей верификации ведет к непредвиденным проблемам и результатам такой валидации я бы не доверял.

ℹ️ Ну и напоследок. «Куда относить проверку на коллизии?», спрашивают меня коллеги. Я думаю так. Когда сами модели создаются ради внешней цели, например для проверки на коллизии, то возможность устранения пересечений является функцией этой модели. А значит, мы требуем от модели только реально то, что нужно для проверки, а сама проверка на коллизии будет относиться уже к валидации. Но если модель должна быть лишена всяких коллизий «на входе», то отсутствие коллизий является предметом верификации модели.
👀 А вот должна ли она быть такой идеальной «на входе» - отдельный вопрос (который при желании можно обсудить в комментариях).

#информационнаясреда