Информационное моделирование в России

Поручение Президента (лично знаю автора строк) считаю максимально выверенным и очень перспективным документом, который обязательно будет еще долгие годы направляющим для колеблющихся госструктур, внедряющих то BIM, то ИМ, то ТИМ, то ЦИМ.

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

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

Расскажу один случай. Как известно – ПП РФ № 614 рождался в муках (собственно грубейшей ошибкой было сократить срок 1431 и допустить полтора года безвременья), но наконец он вышел на финишную прямую, а там уже и в организованном «СиСофт Девелопмент», и в одном из подкастов в телеграм-канале НОТИМ (?правильно?) было его обсуждение. Нужно отдать должное смелости ведущему разработчику Инге Александровне Яценко – она представляла спорный документ в прямом эфире. Задал и я свой вопрос, уточнив, что в тексте проекта постановления и пояснительной записки выражение «технологии информационного моделирования» встречается трижды, но один раз из этих трех – в единственном числе. Прошу определиться. Инга Александровна кивнула и, с улыбкой на лице, записала мой вопрос, а уже в конечном документе все было правильно – множественное число.

Поясню такую «битву за численность». Подробнее можно почитать в статье журнала «Информационное моделирование» 2025 года № 1 «Технология информационного моделирования: камень преткновения или этап развития?»[29], а если кратко – попробую сейчас изложить самостоятельно. От названия очень много зависит, например, дальнейшее понимание сути. Возьмем тот же BIM, название удовлетворяло очень короткое время, а потом его начали расширять, расшифровывая букву «М» – как моделирование, методологию и так далее, видимо пытаясь придать больше смыслов. Но кроме «маркетинга» в самом BIM уже больше ничего нет, и признать это – значит усомниться в достигнутом технологическом «превосходстве» запада, позволяющем на пустом (хотя пока еще не совсем пустом) месте зарабатывать огромные деньги. Итак, множественное число ТИМ предполагает самое главное, чего нет в названии BIM – градацию технологий. Это очень важно. Нам доступны теперь не только градации, но и чёткие границы, а значит – взаимозаменяемость отдельных, более конкурентно успешных технологий. Выиграет от этого потребитель, да и производитель «бронзоветь» не будет, а это инструмент развития, которого BIM себя лишил. Читайте статью, про которую я написал выше, там подробнее. Вспоминаю один разговор с представителем компании «Сименс» на одной из конференций. На его вопрос о будущем платформенных решений я ответ – его нет, он очень удивился и улыбнулся. Наивные, они еще верят в свою исключительность, а ведь это легко предсказать – монополизм сам себя изживает в любом виде и нужно вовремя перестраиваться, иначе тупик.

Заговорив о монополизме, нельзя не отметить еще одну проблему OpenBIM, о которой мы подробнее говорили раньше – зацикленность на СОД и IFC. Взглянем на эти же факторы с другой стороны – они не дают нормально работать с данными, не выпуская саму информационную модель из «цепких рук» определенных разработок программных продуктов, захвативших весь мир. Поэтому возникает такая ненависть к определению информационной модели в Градостроительном кодексе, как к отдельной «живой» сущности – редактируемой, длительно хранимой и участвующей в обмене данными в более широком диапазоне возможностей, чем прокрустово ложе OpenBIM, которое распадается на данные и процессы. Сторонниками OpenBIM, чтобы не выступать с лозунгами луддитов, была вброшена тема о том, что информационная модель из Градкодекса – это сборник папочек и файлов типа PDF, и ее определение нужно обязательно разбавить некоей трехмерной ЦИМ. Для любителей трехмерной графики, которая, кстати, не везде и не всегда нужна, сообщу, что в определении Градостроительного кодекса есть все виды графиков и главное, что они взаимосвязаны. Типичное манипулирование массами, которые под надуманными предлогами подталкивают на оказание давления на «регуляторов» разного уровня. Замена ИМ на ЦИМ не просто лукавое непонимание действующего федерального закона (ФЗ-190 Градостроительный кодекс), а шаг назад от технологического суверенитета.

Для подтверждения еще напомню, что согласно Градкодексу в экспертизу принимается информационная модель, а не суррогат без определения в виде ЦИМ. Существует множество и других отклонений как от закона, так и от здравой логики, подробнее об этом можно почитать в статье «Цифровая информационная модель – что это теперь?»[30] журнала «Информационное моделирование» 2024 года № 2.

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

Подводя итог этой главы, можно сделать два вывода и два предложения.

Вывод: виновность в некачественной и хаотической нормативке лежит на всех.

Предложения:

• Остановиться и понять, что отечественные разработчики так называемого «тяжелого САПР» всегда передают клиенту методическую базу о том «как работать и что делать» с купленным ПО. В зависимости от собственных задач и требований вышестоящих организаций и государственных систем, клиент сам или с помощью производителя ПО разрабатывает внутреннюю регламентационную базу, так называемую «цифровую горизонталь». Она не нуждается в регламентациях со стороны государства, тем более на данном этапе развития! Поэтому все мусорные ГОСТы и СП там, где работают с настоящими технологиями информационного моделирования, как правило, не нужны.

• Государству необходимо выстраивать обобщенные требования «государственных информационных систем», давайте назовем это цифровой вертикалью, с «цифровыми горизонталями» по направлениям, этапам и отраслям. Требования минимальные: когда, в каком объеме и виде предоставят те или иные сведения или ответят на запрос – все! Отстаньте от бизнеса – мы сами выправим ситуацию, а нормативный мусор нужно отменить, воспользовавшись ПП РФ 614, где в п.2 сказано – «…Федеральным органам исполнительной власти в 6-месячный срок обеспечить приведение своих нормативных правовых актов в соответствие с настоящим постановлением…». Время уже пошло, до 1 марта 2025 года можно только отменить, и это будет правильно.

Импортозамещать или импоротоулучшать? И где пределы?

Ну, всех и все раскритиковали, а что же тогда делать? Мы идем вперёд или нет? Если нет науки, то чего будем ждать?

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

Есть объективное желание потребителя идти в ногу со временем и получать имиджевые и финансовые дивиденды от всего, чего можно, в частности от BIM, который хорошо показал себя на этапе проектирования, когда не нужно было передавать ИМ дальше. Продукция мировых вендоров заполонила весь мировой рынок, попутно прикармливая почитателей, обожателей и просто сторонников по всем направлениям, с намерениями в дальнейшем занять этапы строительства и эксплуатации. Технически пока что это не сильно получалось, но «поляна лидера» была занята прочно, и никто не сомневался – все лучшее придет именно из-за рубежа. Отечественным производителям программного обеспечения осталась лишь роль интеграторов на местном рынке, и миссия закрыть «белые пятна», куда «великим» было неинтересно и невыгодно соваться. Этими «белыми пятнами» оказалась промышленность России, которую некоторые пренебрежительно называют «промкой». Зачем России эта «промка» – из Китая привезем, а из России лучше сделать мировую бензоколонку.

Помню высказывания части руководителей «Газпром ВНИИГАЗ», когда закрывали созданный с таким трудом «Центр цифровизации»: «Зачем это? Что нужно купим за рубежом». Ну что, купили? Как-то незаметно для либеральной тусовки, недалёких руководителей и их западных покровителей эта самая «промка» понемногу двигалась вперед и ей потребовалось программное обеспечение, сначала, конечно, западное, но затем и российское, в том числе и для замены западных BIM-систем. А собственно никаких систем-то и не было. Да, проектировщики выполняли расчеты технологического оборудования, геологии (инженерной и промысловой) на специализированном ПО, потом была строительная часть, которая тоже требовала того, чего не было на западе. Например, расчеты многомёрзлых грунтов, вибрационных фундаментов, Газпром ведь не офисные центры строил. Тут, конечно, нельзя не вспомнить пафосный проект «Лахта-центр» в Санкт-Петербурге. Очень много знаю о том, как подбирались проектировщики и естественно программное обеспечение, но промолчу – в Газпроме многое делалось с расчётом на бешенные деньги, которые в одночасье кончились. Там, где были реальные люди и реальные дела, все шло иначе.

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

Все это время за этими и другими процессами наблюдали (знаю лично) ряд отечественных компаний производителей ПО, например, «СиСофт Девелопмент» и «Неолант», и там, где это было возможно в условиях западного засилья, протискивались со своими решениями. Конечно, у всех получалось по-разному, но тут уж извините. Иными словами, в эпоху безраздельного царствования западных продуктов, говорю в первую очередь для экспертов, пренебрежительно отзывающихся об отечественной промышленности или просто не понимающих ее роль, предусмотрительные разработчики ПО не дремали. Поэтому для компании «СиСофт Девелопмент» после 2022 года слова импортозамещение практически не существовало, было понятие того, что открылся рынок, на котором продукты функционально слабее, чем продукты «СиСофт Девелопмент». Помню один разговор, чуть более предметный чем обычное огульное «у вас все плохо», в котором собеседник сообщил, что существует очень мало архитектурных заготовок и что для него подтверждением качества продукта будет тогда, когда он сделает крышу на отечественном ПО, как у комплекса Ирины Винер, находящегося в Лужниках. Ну что скажешь такому? Хотя тут нужно начинать издалека, с экономики. Если промышленность уже давно готова к импортозамещению, то общегражданская стройка и девелопмент – нет, и всячески саботируют переход. Тогда тратить средства на разработку библиотеки архитектурных излишеств в горячее время и при ограниченности кадровых ресурсов – не самое первостепенное дело. Нам выгоднее делать нефтеперабатывающие заводы, а на уговоры сомневающихся мало и времени, и желания. Вот как созреют для импортозамещения, так и увидят сделанное своими глазами.

Лучше поговорить об импортоулучшении. Здесь есть несколько направлений, и они могут добавляться при развитии смежных технологий, например технологий искусственного интеллекта (ТИИ). Подробнее поговорим ниже, а пока обозначим и кратко прокомментируем каждое из направлений импортоулучшений:

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

2. Эволюционное № 2, отчасти тупиковое – использование новейших технологий из параллельных ИТ-отраслей, например, ТИИ, а также переход к неким малолюдным или безлюдным технологиям, например, к тем, которые сейчас называют «генеративным дизайном». Здесь, конечно, реальнее отечественное направление «машиночитаемости – машинопонимаемости», но это временный выход, а затем тупики другого рода, например, кто будет следить и проверять и это новый виток «дегенеративного дизайна».

3. Эволюционное № 3, отчасти уже революционное, но тупика не избежать – им станет современный вид строительной вертикали. Рвем ИМ на нужные части (XML-схемы) и с этими частями работаем. Это может стать временным выходом, но тут прилетит сразу с трех сторон: первое – эти части будут из IFC, а значит мы быстро получим проблему по типу «эволюционное № 1», и рука помощи от новомодного IDS не справится; второе – нарушаем законодательство, с частями ИМ нельзя работать, начиная с уровня экспертизы, не говоря уже о более высоком, на части ИМ рвать может только владелец, который здесь не определен, в общем с этим пока все сложно; третье – ИМ практически сразу отправляем в ГИСОГД (а теперь вроде в ЕИСЖС) и что получим (?) – бардак и невозможность работы, а также безответственность и правовой тупик.

4. Революционный № 1, промежуточный, а поэтому более реальный (см. предложение в конце предыдущей главы) – отказ от избыточного госрегулирования внутри цифровых экосистем бизнеса и выстраивания государственной вертикали с четкими параметрами входа / выхода. Пока нет национально ориентированной науки, отечественные производители программных продуктов справляются сами и, совместно с потребителями, наведут элементарный порядок, который потом нужно переводить на научные рельсы.

5. Революционный № 2, хоть и реальный, но более сложный и длительный, т. к. для него необходимы научные исследования и отработка положительных практик в содружестве с отечественными производителями ПО. Речь идет об управлении данными ИМ, при этом формирование и ведение никто не отменяет, а не об эффективном управлении данными на уровне машинопонимаемости, однозначности КСИ и разумности реестра требований. Подробно распространяться на эту тему не буду, интересующимся порекомендую изучить принципы (ключевое слово) организации открытого формата «СиСофт Девелопмент» XPG и его вариаций, но и это еще не все.

Почти четыре года назад был еще один вариант, части которого актуальны и сегодня, а тогда они опередили свое время. Некоторая часть их отпала, в связи с появлением цифровой вертикали (в 2021 году ее не было). Что это за вариант и как он возник? Этот впорос нуждается в подробном анализе, и он будет рассмотрен в главе «Браво СиСофт!» Пока коротко – речь идёт о концептуальном понимании развития информационного моделирования (без цифровой вертикали), изложенной в четырех проектах стандартов, которые были названы «альтернативными ГОСТами ЕСИМ» и были подготовлены в течение трёхмесячного срока обсуждения аналогичных ГОСТов ЕСИМ, подготовленных Росатомом, а затем предоставлены публично. Такое решение было принято не только из-за категорического несогласия с вариантами, предоставленными Росатомом членов ПК 5 ТК 465 «Строительство», но и желания помочь коллегам, т. к. отсутствие этих стандартов (до сих пор) привело к тому хаосу, который мы сейчас наблюдаем. Итак, получив проекты от Росатома, было принято решение не писать отдельные замечания к откровенно сырым документам, а сформировать свои с нуля. Пришло время огласить авторов этих стандартов. Коллектив был маленький, хотя возможность критики давали и другим коллегам. Авторами этих стандартов были И. О. Орельяна Урсуа, С. В. Ергопуло и М. Е. Бочаров.

Очень хорошо помню новогодние праздники 2022 года, которых не было, начиная со 2 января 2022 пошли окончательные согласовании текстов и формулировок, а 7 января в Росатом (обсуждение заканчивалось 10 января и нужно было успеть до его конца, иначе бы по формальному признаку не приняли наши «поправки») ушло официальное письмо и проекты новых ГОСТ. Выдержав время до 26 января, разместили наше пояснение и проекты стандартов на сайте «СиСофт Девелопмент»[31], а в начале февраля информация появилась на одном из популярных строительных ресурсов АН «Строительный бизнес»[32]. Помню шок коллег и ПК 5 ТК 465, и в Росатоме. Первое, что сразу началось, даже еще не читая самих документов – истошные крики, что это СиСофт сделал стандарты под себя и хочет под шумок их принять. Ну-ну – про прием шельмования (не читал, но осуждаю) мы уже помним.

Что было дальше? Через почти три месяца после 7 января (срок достаточный, чтобы принять эти варианты или утвердиться в более ранних мыслях) властями было принято кардинальное решение по «спасению» положения. Уже 29 марта 2022 года приказом Росстандарта № 788 был создан новый и отдельный ТК 505 «Информационное моделирование», вместо «не оправдавшего доверие» ПК 5 ТК 465 «Строительства», а историю с обсуждением и альтернативными ГОСТами от СиСофт красиво нивелировали (слили). Совпадение? Не думаю! СиСофт также вошёл в состав нового ТК, но была принята другая стратегия: наши предложения на общем столе – смотрите, думайте, мы готовы сотрудничать. Ведь отрасль не может жить без стандартов, кроме того, была надежда на ЕСИМ, в том плане, что принимая хотя бы что-то в виде единой системы, мы уберем явный мусор. Все четыре альтернативных стандарта от СиСофт, выложенные в публичном доступе[33], рассмотрены в настоящей книге.

В заключение главы добавим, что импортоулучшение неизбежно, и даже на западе это поняли, но пока наши власти находятся в некоей «обороне», считая всех вокруг врагами. И хотя иногда они благодарят за критику, но всё-таки делают по-своему. Это происходит, зачастую, по банальным причинам: кто-то из минстроевских подведов, к примеру ФАУ «ФЦС», объявляет НИР на два – три миллиона, и потом, приняв «результат», претворяет его в жизнь и «крепко стоит на этом». Здесь используется принцип: НИР защищён, деньги уплачены, результаты воплощены – и весь аппарат начинает работать на новую «истину», считая всех сомневающихся, как минимум, неконструктивными людьми. Потом результаты всплывают во всевозможных реестрах, требованиях в классификаторах строительной информации, сводах правил и прочих очень значимых вещах, где убытки от «некачественности» которых многократно превышают копеечные стоимости НИР.

Полностью игнорируется простая истина – источников мудрости не может быть много, и кто-то один условно должен быть мозговым центром. Но ведь есть успешные примеры – внедрение ИСУП. Взялись и внедрили, и наплевали на лоббистов IFC. Подробности же все знают. Хотя проблемы у ИСУПа есть, и очень большие, а на административном ресурсе долго не протянешь, и если не получится исправить в течение этого года – схему придется менять (см. пункты 1, 4 и 5 выше).

Почему существуют полярные мнения о формате IFC?

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

Для понимания темы нужно начать с предназначения этого формата и стандарта. Кто был первый и кто больше всех внес или вынес, в смысле заработал – немцы, англичане или американцы, а также технические подробности и недостатки IFC мы здесь рассматривать не будем, а сразу отошлем к ряду статей, опубликованных в журнале «Информационное моделирование», например, статья Артема Бойко[34]. Организационно-технические преимущества и недостатки формата рассматривались в журнале «Информационное моделировании», в ряде специально организованных дискуссий[35]. Хотя уже со второй серии «дискуссий» сторонников IFC находить стало практически невозможно. Это и понятно, писать о «магии» и «волшебстве» постоянно – сложная задача, да и не верят уже в эти сладкие речи. У защитников есть еще один, вроде как весомый аргумент: «вы не умеете работать с IFC». В ответ приведу небольшой списочек основных видов несоответствий IFC стандарту, по которым необходима верификация ИМ. Итак, основные виды ошибок:

• синтаксические ошибки;

• нарушения ссылочной целостности;

• несоответствие типов объектов;

• несоответствие числа и типов атрибутов;

• недопустимая длина строковых и бинарных последовательностей;

• недопустимый размер коллекций, включая обратные ассоциации;

• повторяемые элементы коллекций-множеств;

• неустановленные значения плотных массивов;

• нарушение правил для простых и объектных типов;

• нарушения правил уникальности и глобальных правил.

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

Тем не менее, и в защиту IFC есть два аргумента. Первый из них – это действительно практически (ключевое слово) единственное транспортное средство, особенно для общегражданской стройки, плотно подсевшей на продукты Autodesk. Как-никак, общее для всех строек – это строительная часть. Второе – это принцип классификации и внутренней архитектуры формата. При всех минусах там есть и положительные моменты, которые можно учитывать при переходе на другие, более простые способы транспортировки. Что-то уже сейчас пытаются использовать разработчики XML-схем, но в основном повторяют те же ошибки, но будут замены. Причин несколько: мало времени и нет научно обоснованного курса.

У сторонников IFC, когда их уже прижимают к стенке фактами, есть еще один, на первый взгляд убедительный аргумент: в IFC вложены огромные ресурсы, которые нам не потянуть, если он нам не понравится. Что же, видимо денег потрачено немало, но кто сказал, что нам нужно повторять ошибки других, а самое главное «пилить» такие ресурсы? А ошибками являются не недоработки или проблемы формата, а он сам!

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

Карго-культ – это надолго?

Для тех, кто позабыл некоторые детали этого выражения, приведу часть статьи из Википедии, которая описывает карго-культ (от англ. cargo cult – поклонение грузу), как религию самолётопоклонников или культ Даров небесных – термин, которым называют группу религиозных движений в Меланезии. В культах карго верят, что западные товары созданы духами предков и предназначены для меланезийского народа. Считается, что белые люди нечестным путём получили контроль над этими предметами. В культах карго проводятся ритуалы, похожие на действия белых людей, чтобы этих предметов стало больше[36]. Если короче, то история следующая – грузы для снабжения размещенных на островах военных доставлялись, в основном, по воздуху. Часть товаров доставалась островитянам. Когда все кончилось, то наивные люди имитировали действия солдат, моряков и лётчиков. Они делали наушники из половинок кокоса и прикладывали их к ушам, находясь на построенных из дерева контрольно-диспетчерских вышках. Они изображали сигналы посадки, находясь на деревянной взлётно-посадочной полосе. Они зажигали факелы для освещения этих полос и маяков. Островитяне строили из дерева самолёты в натуральную величину, взлётно-посадочные полосы для привлечения самолётов.