Национальное российское ПО для BIM – ключ к лидерству в экспорте инжиниринговых услуг

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

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

Что касается уникальных атрибутов отнесения ПО к BIM-технологиям, то это точно не 3D-графика. С таким же успехом тогда к BIM можно отнести и Paint-3D, например, или иные аналоги. А где тогда 4D и 5D? Трёхмерное ПО появилось 30 лет назад, а значит и старый AutoCAD надо относить к BIM-технологиям? Наконец, BIM-Level-0 в принципе предполагает возможность использования изометрической информации на бумаге, так давайте и кульманы отнесем к BIM-технологиям? Как видите, количество измерений не есть обязательный атрибут BIM-технологий, а потому это краеугольный камень внедрения BIM в целом!

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

Среди прочих, мы выделяем следующие признаки:

1. коллаборативность – возможность работать в одной модели всем участникам процесса,
2. интероперабельность во всех трёх направлениях – возможность использовать готовые файлы не в нативном ПО,
3. отсутствие электронного разрыва, то есть отказ от создания управляющих документов на бумаге вне электронного потока данных,
4. использование внешних баз данных – это способность работать с ИМ в будущем без привязки к локальным корпоративным базам, которые к тому же могут вообще исчезнуть,
5. возможность работы с ИМ в облачных или распределенных сетях и другие свойства.

Как только вендор сможет сказать, что моё ПО полностью соответствует требованиям отнесения к BIM – можно говорить о том, что он создает BIM-технологии... Что касается интероперабельности, то интероперабельность – это свойство ПО, а не ИМ, то есть ПО должно давать возможность открывать и работать с ИМ в любом другом ПО и через 10, и через 20 и более лет...

Абсолютного решения сегодня нет ни у западных, ни у российских вендоров. Но если зарубежные поставщики ПО медленно, но верно идут к созданию платформенных решений, то есть такого ПО, на основе которого создается ИМ путем объединения данных и файлов из разных видов ПО, то в России пока у наших главных вендоров для этого нет сил. И если вернуться к вопросу создания инструментов национальной независимой базы, то надо подталкивать наше Правительство к поддержке решений компаний Nanosoft, «АСКОН» и даже Росатом (у корпорации есть свой комплект инженерного ПО), в том числе в части создания платформ с указанным требованиями по BIM-соответствию. Уверен, они справятся с этим.

С другой стороны, нет никакой необходимости пытаться соответствовать требованиям на 100% сразу, можно приближаться к цели постепенно, параллельно с развитием законодательства, баз данных, инструментария взаимодействия и облачных технологий в целом. Дорога «мелких шагов» к BIM – более понятна и перспективна с точки зрения оценки рисков для инвесторов в BIM-технологии.

Именно так, как я казал выше. Давайте начнем с того, что реализация проектов МЧС – это весьма узкоспециализированная задача, которая включает в себя широкий набор строительно-монтажных и проектных работ, от бетона, до КИПиА (контрольно-измерительных приборов и автоматизации), от монтажа оборудования до пуско-наладки и тестирования.

Именно поэтому МЧС вполне могло бы выступить заказчиком создания специального приложения или отдельного 3D-параметрического графического сервиса именно для противопожарного проектирования. Зачем нужен такой сервис? Во-первых, он учитывает специфику проектирования и проверяет не столько на геометрические коллизии, сколько на технические ограничения. Во-вторых, и это важно, – создание уникальной базы данных противопожарного оборудования, материалов, каталог поставщиков и система их сертификации. Такая база нужна обязательно, и она должна быть перманентно обновляемой чуть ли не в автоматическом режиме.

Например, новый поставщик получает разрешение на применение оборудования в МЧС, а это значит, его оборудование в 3D-формате занесено в каталог, имеет свой код в классификаторе и параметры для отбора и сравнения. А отсюда вытекает вся перспективная работа МЧС в области BIM: обновление библиотеки материалов и оборудования для МЧС, обучение работы с редактором, верификация ПО на совместимость, выдача сертификатов и разрешений для учета материалов в классификаторе МЧС. В общем, задач сразу появляется много.

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

Все эти вопросы решает формат открытого обмена данных – IFC-стандарт, детище известной международной структуры BuildingSMART Int., российское отделение которой я в свое время организовывал.

Разумеется, есть много форматов открытого обмена данными, не менее 10 точно, но для строительства IFC-стандарт признали наиболее гибким и открытым для развития. Потому пока нет смысла говорить о развитии альтернатив – это дорогая и долгосрочная задача. Гораздо важнее нам занять лидирующие позиции в этом процессе, поскольку тот, кто станет лидером в интероперабельности ПО, будет и лидером в экспорте инжиниринговых услуг.

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

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

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

ГГЭ как участник проектов входит в документооборот конкретного проекта и каждое её письмо или заключение зеркалится в собственном документообороте и навсегда остается в документообороте актива.

Это хороший вопрос, ответ на который дает дорогу в будущее BIM-технологий, скажем – следующего десятилетия. Дело в том, что объем информации в ИМ будет постоянно возрастать, как по мере сложности проектов, так и по мере сложности ПО для этого. А это значит, будет возрастать и стоимость сервиса ИМ на всех этапах жизненного цикла объекта (ЖЦ).

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

По сути, коэффициент уникальности в 100% говорит о том, что все проектные решения, элементы, расчеты и сведения уникальны для данного проекта. Это плохое решение. По мере роста объемов ИМ они должны становится менее уникальными и более универсальными, а это значит, что большая часть информации в ИМ будет представлена в виде ссылок на типовые реестры, библиотеки, описания, регламенты, базы данных наконец. Тогда ИМ будет по объему невелика, а по составу – огромна. А это как раз и означает как развитие блокчейн-технологий в BIM, так и использование распределенных реестров библиотек, баз данных виртуальных Центров обработки данных (ЦОДов) и сетей.

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