Основные проблемы с OpenBIM и в частности с IFC заключаются в том, что мало описать формат, еще нужно чтобы все программы в него единообразно выгружали данные, и чтобы правильно считывали выгрузки из других программ. Что на практике не всегда оказывается решаемой задачей. Еще одна проблема, что у формата по сути нет редактора (кроме блокнота). Т.е. данный формат статичен и годится разве что для передачи или хранения данных. Третья сложность заключается в том, что данный формат тяжелый и при подгрузке в программу не из которой был выгружен, он ее изрядно вешает.
Проще говоря, BIM, построенный на основе OpenBIM больше похож на обмен данными через PDF. Это как если бы вы не могли запросить у контрагента договор в word или спецификацию в excel, т.е. перебивали ручками с соседнего экрана или распознавали файнридером текст и разметку. А теперь представьте что файнридер пару страниц не распознает, а часть страниц и в PDF не выгрузилась - каково? А завтра сдавать...

Нужен ли нам свой отечественный формат для OpenBIM? Типа IFCrus? Для ответа нам потребуется понять что из себя представляет данный формат. Это текстовый файл (в более новой версии xml), в который выгружается описание об элементах модели, вроде ifcWall, points(34,35), height(2800), thickness(200) и т.д. подробнее можете сами посмотреть открыв блокнотом. В программах же, которые читают этот формат класс ifcWall распознается на том языке, на котором надо, например на русском: Стена. Параметр height - Высота, соответственно и Толщина и Объем все на русском.
Т.е. сегодня стоит вопрос перед профессиональным сообществом и Министроем: надо ли Одинэсить BIM? Переводить IFC классы на русский. Т.е. надо ли создавать свой новый псевдоязык на кириллице для описания элементов Информационной модели? Потом ведь потребуется учить разработчиков программного обеспечения в него выгружать свои данные. Сами мы можем частично написать плагины для экспорта разве что для Revit'а и Tekla, потому что разработчики дали нам программный доступ к своим элементам, а с остальными самим не получится.

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

Что касается инструментов, которые требуются для взаимодействия на основе модели, то они начали появляться ещё в машиностроении -- речь идёт о PLM (англ. Product Lifecycle Management -- управление жизненным циклом продукта). Такие системы включают и создание компьютерных прототипов будущих продуктов, и их тестирование, и контроль за созданием деталей с помощью ЧПУ, и последующую сборку, и эксплуатацию с помощью датчиков. В строительстве, где в реализации проекта могут участвовать десятки и сотни людей, ко всему этому добавляется ещё одна важная возможность -- удобные средства коммуникации на любом этапе жизненного цикла. К таким средствам относится комментирование, совместный просмотр, назначение заданий с настраиваемыми маршрутами согласований, прикрепление файлов различных форматов и многие другие. И всё это на основе элементов модели, в том числе на классических чертёжных видах. Примеры реализации таких систем уже есть -- это BIM 360 от Autodesk, BIMx от Graphisoft, Teamcenter от Bentley и Siemens и некоторые другие. Есть и отечественные разработки, выполненные в основном под крупные девелоперские компании, в которых такие системы особенно необходимы. Таким образом, при разработке отечественного софта необходимо задумываться не только об инструментах создания модели, но и не забывать о PLM. Как правило, PLM являются мультиплатформенными (могут работать с моделями, разработанными в различном ПО), причём взаимодействие на их основе можно назвать OpenBIM без IFC. Однако встречаются и такие системы, которые заточены под работу только с форматом IFC. Вообще же идеальный вариант системы, к которому нужно стремиться, это когда у каждого участника ИДП есть свой интерфейс и свои функции для работы с моделью, а сама модель при этом одна, одного формата, включающая все имеющиеся данные о проекте.

Вторая важная составляющая прозрачного взаимодействия на основе модели -- юридическая. Здесь не годятся традиционные формы договоров между инвестором, заказчиком, ген. подрядчиком, ген. проектировщиком и субчиками, при которых каждый участник ИДП несёт ответственность только за свою часть проекта, а качественный результат нужен только инвестору и пользователю объекта. Нет, все участники должны нести пропорциональные обязательствам риски, равно как и получать пропорционально увеличенные гонорары за успешно реализованный в срок проект. То есть все должны быть равно вовлечены в процесс -- только тогда имеет смысл всё, что сказано про PLM. Такой подход к реализации ИДП, основанный на доверии между участниками, с соответствующей формой договора называется IPD (англ. Integrated Project Delivary -- объединённая реализация проекта). Конечно, запустить такой процесс -- непростая задача, особенно между юридически не связанными друг с другом компаниями-участниками (хотя за рубежом встречаются проекты, выполненяемые по контракту IPD). Для этого нужны крепкие партнёрские связи и высокий профессионализм участников. Пока похожий процесс можно наблюдать опять же внутри крупных девелоперов, где эти связи существуют. Именно в таких компаниях быстрее всего окупается BIM, именно в них нужны такие инструменты, как PLM. Можно сказать, что принцип IPD без BIM не реализуем, и обратно, эффект от BIM наиболее сильный в проектах IPD.

Еще пару слов про PLM-системы. Они реализуют одну из составляющих BIM-процесса, называемую CDE (Common Data Environment), или Среда общих данных. Все мы слышали фразу "находиться в одном информационном поле". CDE и есть такое общее поле для всех участников проекта. Суть концепции как раз в том, что все данные находятся в одном месте, не дублируясь, а каждый участник проекта имеет к ним доступ в соответствии с назначенными правами. Если какой-то файл обновляется, его новая версия публикуется там же где была предыдущая (поэтому PLM-системы обязательно поддерживают версионность, то есть хранят все предыдущие версии файлов, очевидным образом показывая только последнюю версию). Эта модель гораздо лучше традиционного "вышли мне последнюю версию на почту"

Михаил Косарев подготовил карту русского BIM'а, где описал стандарты по BIM, основных участников, кто сейчас двигает процесс и много другой полезной информации. Рядом с каждой записью есть ссылочка, по которой можно перейти непосредственно к документам и сайтам. https://cloud.mail.ru/public/6FVz/Am8viuBM6

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

Зачем вообще нужны государственные стандарты по BIM?
Во-первых, BIM сделал бы прозрачнее процессы на гос. контрактах, т.е. BIM нужен государству как заказчику. Для этого нужны стандарты.
Во-вторых, проектировщики, кто работает в BIM, хотели бы использовать модель и при прохождении экспертизы (чтобы удобнее общаться с проверяющим экспертом) и для общения с госстройнадзором.
В-третьих, хочется как-то в отрасли договориться о единых правилах работы (как ГОСТ на оформление и 87 постановление), и кому как не государству выступить в роли регулятора данных взаимоотношений, кто скажет: "что есть BIM"? И кто что в нем делает?
В связи с этим возникает ряд вопросов:
1. Нужна ли государству на контрактах прозрачность?
2. Готовы ли возрастные эксперты в экспертизе и гсн общаться по модели? Или им бы до пенсии досидеть и чтобы никто не трогал?
3. Может ли регулировать сектор отрасли тот кто меньше остальных в этом секторе разбирается?

Часто мы слышим высказывания, что развитие Информационного моделирования тормозится государством. Несколько раз даже в профессиональных BIM-кругах начинали собираться предложения по совершенствованию законодательства в области BIM (был вопрос: "что мешает бизнесу внедрять bim?"). Еще в 2016 году проводились пилотные проекты по прохождению экспертизы с BIM-моделями. По итогу было несколько основных предложений:
Упростить требования на оформление чтобы в 21 веке не подстраиваться под высоту каретки печатной машинки и толщину стержня карандаша. Точнее, допустить отступления от Советских ГОСТов при сохранении читаемости. Заменить схемы, которые составлены в неструктурированном виде (в виде: чтобы вписаться в лист) на структурированные (условно табличные). Разрешить использовать изометрические схемы (3D виды) вместо архаизма из ручного черечения - аксонометрических схем. Разработать национальный классификатор элементов модели. Утвердить набор элементов в модели и их параметры.
Все эти и другие запросы можно охарактеризовать как: адаптировать нормативы под компьютерное черчение и моделирование (сейчас они заточены под ручное), а также сделать более эффективным применение иностранного программного обеспечения (т.к. сейчас в целях начертить "по ГОСТ" проектировщик зачастую перечерчивает вручную линиями, то, что уже имеется на 3D виде в более понятном отображении), т.е. нормы на оформление являются своеобразным сжиганием времени и ресурсов и риском возникновения ручной ошибки, которых можно было бы избежать.

Михаил Косарев снова радует нас проделанным титаническим трудом. В этот раз это карта по Revit. Смотрим, изучаем. И как и в прошлый раз можно переходить по ссылкам рядом с надписями.

Обновленные карты по BIM и Revit

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

https://rb.ru/opinion/ot-yakutska-do-minska/

В продолжение темы работы распределёнными командами - BIM технология даёт для удалённой работы гораздо больше инструментов, чем традиционное проектирование. Сегодня можно наладить совместную работу проектировщиков в единой модели, которые находятся в разных офисах, или даже в разных странах. Один из вариантов уже был подробно рассмотрен - это опыт компании ПИК. Они выбрали хранение всей документации на своих серверах, и предоставляют проектировщикам только доступ к ним через удалённые рабочие столы. Второй вариант - менее дорогостоящий, и потому более доступный для компаний поменьше: общее хранилище информации можно организовать в облачном сервисе, доступ к которому может быть организован через интернет-браузер - для просмотра моделей, и через интерфейс программ для проектирования - для проектирования. Один из примеров такого облачного сервиса - BIM360 от Autodesk. Файлы моделей в Revit могут там храниться, открываться и из Ревита для редактирования, и из браузера (или специальных приложений для iOS или Android) - для просмотра например руководителями. Сейчас такие платформы активно развиваются и дополняются функционалом. В России есть примеры компаний, который с помощью таких облачных сервисов организовали удалённую работу команд из более чем 50 проектировщиков. География распределения - Петербург, Москва, Екатеринбург, Тюмень, Псков, Петрозаводск. Каждый подключается к своим файлам в удобное время. Вся информация о подключении и изменениях пишется в лог, доступный администратору проекта (ГИПу). Сохраняются предыдущие версии файлов, для отслеживания истории изменений, версии можно наглядно сравнивать. Для сохранности информации можно настроить локальный бэкап на свои сервера. Минус этой технологии лишь в том что она не подойдёт для работы с государственной тайной, так как без интернета не работает. Такие платформы сейчас развиваются всё активнее, разными вендорами, и видится, что в ближайшее время их функционал будет расширяться.

Поскольку преимущества BIM наиболее полно проявляются, когда модель созданная при проектировании далее используется в строительстве и при эксплуатации, наиболее передовые строительные компании в России (и в мире) сейчас осваивают работу с моделью на стройплощадке. Во всем мире при этом сталкиваются с одними и теми же сложностями: модель существует только в электронном виде, при распечатке в виде чертежей теряется суть BIM в некотором роде, при этом все стандартные процедуры верификации, контроля и т.п. основаны на традиционном подходе - чертёж должен иметь оригинальные подписи и печать "в производство работ", журнал авторского надзора должен быть прошит и пропечатан и храниться в вагончике у генподрядчика, а кроме него там же должны храниться бумажные оригиналы ещё десятков и десятков документов.
Во многих отраслях сейчас уже удалось почти полностью уйти с бумажного на электронный документооборот: банковский сектор, налоговая система, госуслуги для населения и для бизнеса - всё это сейчас почти на 100% делается в электронном виде, с использованием интернета для коммуникации и электронно-цифровых подписей - для верификации данных. Строительная отрасль очень инертна, поэтому здесь замена бумажных журналов цифровыми ещё пока только предстоит, и часто такие идею встречают сопротивление со стороны участников процесса - "как вы себе это представляете", "это очень сложно организовать", "электронный документооборот в стройке не закреплён законодательно". Последний аргумент здесь самый весомый, и против него действительно нечего возразить - поэтому среди задач по "цифровизации стройки" очень важным является законодательное закрепление инструментов электронного документооборота в стройке: как может выглядеть электронный журнал (общий журнал производства работ, журнал авторского надзора и многие другие), электронные акты (скрытых работ, приёмки и т.п.), где они могут и должны храниться, кто и как их должен подписывать ЭЦП. После такого законодательного "разрешения" на работу только в электронном виде наиболее передовые компании получат возможность наконец перестать печатать тонны макулатуры и работать в едном цифровом пространстве - Среде общих данных по проекту - и с официальными документами тоже. Возможно, это потребует большого обновления кадрового состава на стройплощадках, но это уже следующий вопрос, который придётся решать каждой компании в отдельности.

Раньше стандарты писались на бумаге, теперь в электронном виде в компьютере. Это позволило организовать поиск по словам в тексте, что сэкономило много времени. В будущем, пункты в стандартах будут классифицированы, что позволит получать только те нормы, которые нужны в данный момент. В этом может помочь и запись истории поисков для определения на каком этапе разработки проекта находился специалист, чтобы в дальнейшем ему сразу предлагать возможные нормы, подходящие под этап разработки проекта, т.е. программы начнут как-бы подсказывать, где есть вероятность ошибки. Еще может помочь единая база замечаний от экспертизы, которая могла бы накапливать, либо в режиме онлайн (если создать такую как сервис), либо выгрузкой из баз данных экспертиз в определенном формате, если разработать и утвердить таковой. А затем можно будет эту базу использовать для оценки вероятности нарушения норм.
Дальше нормативы должны будут переводиться в электронный вид в алгоритмы, которые можно будет подключать к проверяющей программе и получать результат. Таким образом можно будет организовать первичный фильтр приемки проектов. Таким примером в BIM является программа Solibri, а также в Сингапуре уже несколько лет назад заявили что внедрили в работу экспертизы такую программу (но как работает не показали и попробовать никому не дали). Еще подобная программа есть у Autodesk - называется Revit Model Checker (RMC) и в Allplan'е.
Начать переход к таким "цифровым проверкам" можно с простого: перевода классификаций зданий и типов нагрузок в электронный формат (xml, json). Также можно перевести таблицы площадей помещений и их категорий по СанПинам, Инсоляционные линейки, допуски по расстояниям между зданиями или системами. Затем крупным блоком оцифровки станут Санитарно-защитные зоны, которые надо перевести в векторный формат (пока они в растровом виде и виде текста).
Если говорить еще проще, то нормативы, которые можно перевести в Excel, нам нужны в нем. Так же видится большой объем работ по наведению порядка в том, что уже есть. Требуется выработать единую терминологию и принципы в написании, уменьшить задублированности и противоречия.