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

Рисунок 1. Объемное геологическое картирование в СССР в 1970 году.
Ой, мы поторопились. На самом деле пока никто не называет изображённое на рисунке 1 объемное геологическое картирование времен Советского Союза «трехмерной частью информационной модели». Для многих более привычны либо западные названия, либо винегрет смыслов из выдуманных терминов. Когда сказать уже нечего, но надо, используют сакральное слово – «знание».
Так что же такое BIM и почему мы должны его вспоминать? Есть некоторые экзотические объяснения, типа «таинство», «магия», «волшебство», но кто-то идет еще дальше и проводит аналогии с театром или даже с помидорами в банке. Собственно, оставим это без комментариев, все это можно найти в сети интернет, и мы не будем здесь останавливаться.
Современное понимание BIM (англ. Building Information Model), если верить американской Википедии – это объектно-ориентированная модель объекта, как правило, в трёхмерном виде, с элементами которой связаны данные геометрических, физических и функциональных характеристик объекта. Целью создания такой модели является принятие решений в строительном проекте, как на этапе создания такой модели, так и на последующих этапах жизненного цикла объекта. Да, существуют и дополнительные расшифровки буквы «М» – моделирование и даже методология, хотя я бы предложил еще одно – маркетинг, которого в современном BIM довольно много. Ведь что бы удачно продавать нужно, чтобы покупатель был уверен в том, что это – лучший продукт, здесь маркетинговые бюджеты компаний мировых вендоров тоже в помощь. Не поверите – работает до сих пор.
Но тем не менее BIM – часть нашей истории, и мы начнём с известных о нем фактов:
«…В 1974 года профессор Технологического института Чарльз Истман с несколькими соавторами написал работу «An Outline of the Building Description System. Research Report No. 50». Некоторые из высказанных там идей легли в основу так называемой BIM.
В 1975 году журнал AIA («American Institute of Architects») опубликовал статью, в которой упоминалась информационная модель здания (Building Description System). Идея создания такой модели буквально носилась в воздухе, правда, под разными названиями. В США ее называли Building Product Model, а, например, в Финляндии в начале 1980-х – Product Information Model. И лишь позднее сформировалось общее понятие – Building Information Modeling (BIM).
В 1986 году англичанин Роберт Эйш сформулировал основные принципы информационного подхода к проектированию: автоматическое составление чертежей; создание трехмерных объектов; интеллектуальная параметризация зданий; сведение баз данных; распределение этапов строительства во времени и прочее…»[7].
Давайте сопоставим даты. В 1970 году СССР уже во всю использовал принцип трехмерного моделирования, но из-за приостановки разработки компьютерной техники (известная борьба с кибернетикой во время хрущевской слякоти), отстал от западных разработок. Кстати, это подтверждают и сегодняшние события – стоило только ослабнуть технологическому хомуту, как сразу же отечественное информационное моделирование оказывается впереди, идейно, технически догнав западные разработки практически сразу, т. к. основные российские игроки не сидели все эти годы сложа руки. Именно по этому поводу происходит такая реакция на отечественные разработки в определенных кругах. Их, кстати, можно определить очень просто – они упорно не произносят слово ТИМ, только BIM, ну или иногда ЦИМ, как говорится – «истерикой … удовлетворен».
Если кому-то интересно подробнее изучить вопрос, лучше прочитать статью из журнала «Информационное моделирование» 2023 года № 1, «BIM – аналог или прототип информационного моделирования в России?»[8], в которой вопрос раскрыт подробно, со ссылками на первоисточники и логическим анализом.
Для тех, кому это неинтересно, можно проанализировать вышеприведенные цитаты.
Итак:
• Современный BIM – принятие решений в строительном проекте, как на этапе создания такой модели, так и на последующих этапах жизненного цикла объекта.
• Зарождение BIM – основные принципы информационного подхода к проектированию: автоматическое составление чертежей; создание трехмерных объектов; интеллектуальная параметризация зданий; сведение баз данных; распределение этапов строительства во времени и прочее.
Если под словом «прочее» не иметь в виду беспредельный размах (космос), накрученный маркетингом, получается место, где был нужен и где закончился реальный BIM – это стройка.
Кто хоть раз был в современном проектном институте или смотрел про него в кино, или кому доводилось побывать на стройке, прекрасно представляют происходящие там процессы. Давайте начнем с самого простого наблюдения – в институте, как правило, работают сидя в чистом офисе, у каждого один, а то и два продвинутых компьютера (мониторов точно несколько). На стройке же не посидишь, да и с компьютерами там тоже не очень, максимум можно найти планшет у мастера или не очень современный ноутбук в прорабской, да и внешние погодные условия далеки от стабильного офисного микроклимата. В проектном институте каждый сотрудник имеет высшее образование, а также минимум два повышения квалификации, а на стройке… Скажем честно, хорошо, что хотя бы все понимают русский язык. Немного меняется обстановка и коллектив на шефмонтаже и пуско-наладке, но эти процессы, как и процессы изысканий мы намеренно не станем делать целями нашего анализа. Подобная ситуация в проектировании и строительстве продлится еще долго и не только у нас, благодаря конкретной специфике этих двух этапов.
Проектировщики очень легко приспособили компьютеры к своему процессу и первое, что имело особый спрос – электронные кульманы, или чертилки, и первый из них это AutoCAD, появившийся в 1982 году. Компьютер очень хорошо и четко, с соблюдением всех правил чертил линии, круги и дуги, легко стирал неправильно начертанное и не портил бумагу зря – печатал только проверенный чертеж. На заре компьютеризации это воспринималось как настоящее чудо. И вот опять даты: 1982 – в США уже есть AutoCAD, но лишь в 1986 году англичанин Роберт Эйш сформулировал основные принципы информационного подхода к проектированию. И что же это за принципы, которые сформировали якобы новое чудо – BIM? В источнике скромно указано: «…автоматическое составление чертежей; создание трехмерных объектов; интеллектуальная параметризация зданий; сведение баз данных; распределение этапов строительства во времени и прочее…».
Что из вышесказанного было уже известно к тому времени очень хорошо, а что действительно заслуга Эйша, мы детально разбирать не станем, Все-таки Эйш занял свою нишу в истории. Давайте посмотрим на современность, ведь на дворе 2025 год, и прошло уже почти 40 лет. Что же нового было в этом BIM?
Итак, по заявлению маркетологов (буква «М» в аббревиатуре) – это принятие решений в строительном проекте, как на этапе создания такой модели, так и на последующих этапах жизненного цикла объекта. Итак, принятие решений вовсе не означает полную поддержку процессов и данных инвестпроекта, и, кстати, для этого в западной терминологии имеются соответствующие концепции PLM (Product Lifecycle Management) – концепция управления жизненным циклом изделия; EPC и даже EPC-M (Engineering, procurement and construction) – способ контрактования в строительной отрасли; под эти концепции написаны свои системы программного обеспечения, и они не называют себя BIM. Правильно это или нет, разберем чуть ниже, а пока излагаем концепции западных маркетологов. Значит не все так просто и, появившись на свет как чудо с большим потенциальным продолжением, электронный кульман с добавлением трехмерной графики и кучей разнообразных «компьютерных ништяков» по обработке данных, названный BIM, не смог стать строительным «всем».
И причиной всему уровень знаний, который был положен в основу BIM и который громко назвали OpenBIM. Открытость здесь, конечно, распространяется лишь ровно до уровня коммерческого интереса основных бенефициаров. Хотя некоторые в это верят до сих пор, или уже не верят, но продолжают козырять словом «открытость», четко при этом осознавая, что им уже практически мало кто верит. Так что можно, конечно, наделить букву «М» некоторым количеством смыслов, но сутьот этого не меняется – она очень ограниченная.
Итак, что нам известно про OpenBIM и прочее? Если кратко – мутная история борьбы мировых кланов, корпораций и разведок за деньги, информацию и власть. Об этом в ряде публикаций хорошо написано Артемом Бойко[9]. А если говорить про техническую сторону, то это пафосная история с кучей ненужных для реальных дел функциональных наворотов, методологически изложенная в ряде стандартов ISO 19650. Основными китами которого (которой?) являются два понятия, или принципа – среда общих данных (СОД) и безликий транспортный формат (стандарт) IFC. И за эти два понятия OpenBIM и организация, переходящая из рук в руки, «buildingSMART», держатся очень крепко, хотя западные здравые умы прекрасно осознают, что это тупик и пытаются искать выходы. Этому, опять в привычной хлёсткой манере, дал анализ Артем Бойко[10], да и у нас уже начали, не поняв разницы между машиночитаемостью и машинопонимаемостью продвигать очередное чудо «IDS» под видом решения всех проблем.
Но это слова и маркетинг, а что же в СОД неправильно с технической стороны? Вернемся к нашим строителям и проектировщикам. В красивом теплом офисе есть сервер, на котором базируется СОД как программная среда обеспечения работы всех проектировщиков одновременно. Есть нюансы, но основное предназначение СОД – формирование информационной модели (ИМ) одновременно, параллельно и с прочими прелестями совместной работы, когда изменения одного видны либо сразу всем, либо тем, кому положено видеть, а главные могут регулировать процессы проектирования и формирования[11] ИМ по своему усмотрению – очень удобно. При необходимости привлечь стороннюю помощь от стороннего ПО, например, сложный инженерный или сметный расчет, поступают просто – выгружают в необходимом виде необходимые данные, выводят их из СОД и отдают на обработку другому ПО (иногда расположенному на том же компьютере), а результат возвращают в СОД, и он становится вновь доступен всем причастным. Возможны различные варианты, но в принципе этот так – просто и удобно, однако, где же здесь IFC – эта большая «удобная» обменно-транспортная корзина? Он тоже может пригодиться для совмещения несовместимых форматов, про стандарты пока промолчим – там еще хуже. Итак, выходя и входя в СОД используем IFC, но только в крайнем случае, когда все остальные варианты уже исчерпаны. Плохо ли это? Да, но об этом чуть позже. А пока можно опять вернуться к многосерийной дискуссии на страницах журнала «Информационное моделирование»[12]. Кто-то из защитников IFC напрямую высказывался на страницах журнала, кто-то «шипел и брызгал слюной» в кулуарах конференции, но итог плачевный – не убедительно! Кроме одного факта – международная BIM-мафия подсадила на этот пока еще выгодный для части глобальных корпораций формат весь мир и теперь всеми силами старается в нем удержать и Россию, препятствуя технологическому суверенитету страны.
Но перейдем из проектного офиса на стройплощадку и попробуем перенести с собой СОД вместе с ИМ уровня «как спроектировано». Теоретически это легко, а практически? Сразу опустим те очень частые моменты, когда стройка идет параллельно с проектированием или экспертизой – это точно не те случаи, когда OpenBIM может заявить не то что о преимуществах, а вообще о состоятельности, но об этом ниже. Поэтому для рассмотрения возможности по использованию СОД будем разбирать самый простой и редкий случай, когда проектирование закончилось, необходимые экспертизы пройдены и разрешения получены, а стройка еще не началась.
Итак, мы – строительная организация (в обобщенном виде) и у нас на руках ИМ, то есть проектная и рабочая документация (см. ст. 48 Градостроительного кодекса), которая находится в СОДе на сервере в нормальном редактируемом виде, т. е. готовая к дальнейшему формированию и ведению[13] и либо исправленная после проблематики IFC, либо избежавшая этой участи. Если при проектировании участниками проекта, работавшими в СОД, были все сотрудники (обобщенно) и каждый через свое рабочее место (компьютер) с рабочими инструментами (клавиатура и мышь) мог участвовать в формировании ИМ, то на стройплощадке все немного по-другому. Появились другие рабочие инструменты (лопата, мастерок, молоток, топор, лом и прочее), а условия кондиционированного офиса изменись на реальные погодные условия (дождь, снег, грязь, холод, жара) и даже гнус и комаров. При этом изменились производственные процессы: объект или, например, его часть – стена, теперь формируется не в виртуальном пространстве ИМ за секунды легким движением мышки, а выкладывается из кирпича в течение дня, при этом быть в курсе рабочего процесса, производимого штукатуром или соседним каменщиком, занятых с другой стеной совершенно не нужно, если только они работают не над одной стеной. Да, и современный компьютер или планшет каменщику не нужен, а смартфон он сможет вытащить из кармана, когда снимет грязные рукавицы.
Так и где же здесь СОД? Он конечно же остался, но в другом функционале и только у тех, у кого есть компьютер и соответствующая квалификация, а вернее у тех, кому эта квалификация необходима – это важно. Если брать типовые структуры строительных организаций (крупные девелоперы и госпредприятия с раздутыми штатами могут не читать), то это: главный инженер или заместитель по производству, производственно-технический отдел, желательно прорабы и мастера, и все по направлениям качества, контроля, смет и так далее. Конечно, и прорабу и мастеру основные компетенции по информационному моделированию нужны, особенно когда по утрам и вечерам, присутствуя на планёрках, нужно докладывать об уб уже выполненных работах или получать задания на будущее по ИМ на большом экране, расположенном за спиной у главного. Тут, нужно разбираться и понимать, иначе можно заработать клеймо профессиональной непригодности. Так, что читаем эту книжку и изучаем ПО, которое используется в вашей организации, а если кто будет на таких планерках умничать и сыпать ИТ-терминами, относящимися к его ИТ-специализации, показывая свое интеллектуальное превосходство – вы знаете, что ответить, есть понятные и доходчивые русские слова.
Вернемся к СОД. Да, в строительной организации она есть, и в ней имеется модель в редактируемом формате, позволяющем нормально (без чудес от IFC) формировать и вести ИМ при строительстве объекта капитального строительства (ОКС). Но появились нюансы, связанные со специализацией различных строителей, монтажников, пуско-наладчиков, снабженцев, логистов и прочих подрядчиков и субподрядчиков. Сколько их сегодня было на строй площадке, даже если объект – маленький детский садик в районном центре? И что же – всем предоставим доступ в нашу СОД? Вы уверены? Ведь отдаваемая невесть кому ИМ это единственный вариант того, что потом нам сдавать эксплуатанту в виде ИМ – «как построено» и отвечать за документацию, генерируемую из возвратившейся к нам от этих подрядчиков ИМ? Нет, конечно, если вы доверяете, то да – СОД в варианте от OpenBIM сработает, но как передавать данные или куски ИМ – неужели через IFC? Еще не смешно? Попробуйте и точно смешно не будет. Но это лирика, а вот какие именно куски ИМ и кому вы булете передавать? Да, если связываться с IFC, то придется держать дополнительных высокооплачиваемых специалистов, типа BIM-менеджеров. Есть на это деньги и есть ли такие специалисты на рынке? Если кто-то хочет подробнее изучить вопрос, то лучше прочитать статью из журнала «Информационное моделирование» № 1 от 2023 года: «К вопросу о цифровизации строительства на основе принципов детализации информационной модели»[14]. Написанное в этой статье не реализовывалось нигде в мире и специально не патентовалось, а уже размещено в публичном открытом доступе, исключающем в будущем ее присвоение, как собственности, любым из производителей программных продуктов.
Все «современные» BIM структуры, продающие свои услуги для строительного этапа (не хочу называть и делать рекламу), действуют по принципу – мы себе (в свое ПО) забираем вашу ИМ и что-то там с ней делаем: обеспечиваем календарно-сетевое планирование, разбиваем на захватки, даем никому не нужные дашборды (как без них стройка жила раньше?), заполняем электронные формы отчетности, осмечиваем – в общем, пользуясь моментом, «обилечивают» пока еще не сильно грамотную строительную публику. Польза, конечно, от этого есть – народ знакомится с компьютерным технологиями, позволяющим в будущем прейти на нормальное ПО. «Лохов» (извините, но так) становится все меньше, но они еще есть. Есть еще вариант с использованием искусственного интеллекта, но об этом ниже.
Очень надеюсь насокращение количества инфоцыган, возможное после введения в работу структуры, которую сейчас модно ругать – информационную систему управления проектами (ИСУП) от РосКапСтроя[15]. Вернее, надеюсь не на саму ИСУП, а на принцип доверенного (трастового) управления в интересах клиентов некоей структурой типа ИСУП, прототипом которойявляется «национальная библиотека информационных моделей», а одним из функциональных предназначений является функция архивного хранения (актуализации) информационных моделей, например, по заказу государственных структур, в том числе и по трастовому признаку (термин взят из проекта стандарта «Термины и определения»[16]).
Чтобы закончить тему СОД на стройке, а в дальнейшим и при эксплуатации, нужно вспомнить еще одно западное пророчество, так называемый график уровней зрелости BIM, составленный в 2008 году Мервином Ричардсом и Марком Бью, известный сегодня как «Модель Бью-Ричардса». Этот график и постулаты ИСО 19650 за неимением лучшего придают некий флер научности OpenBIM – ибо больше там ничего нет. Приводить этот график я сейчас не стану, рассмотрим его чуть позже, хотя это тоже можно назвать бессмысленной тратой времени, но всё-таки нужно проанализировать. Почему я так резко отзываюсь о том, что для некоторых свято, а многие и вовсе бездумно приводят это график даже в диссертациях, как что-то незыблемо верное? Для них нужно напомнить незабвенного Френсиса Фукуяму и его предсказание о конце истории. При такой чудовищной промашке у него вполне хватает совести предсказывать дальше. Кстати, остальные перлы западных предсказателей[17] тоже поражают своим выстрелом в пустоту, хотя людидалеко не глупцы. Итак, почему эта модель пустое или устаревшее понятие – приведу лишь два соображения: первое – там все основано на западных стандартах (они ужесами от них отказываются, а основная масса россиян, кроме авторов переводов, их просто не использует и даже не знает о их существовании); второе, и более концептуальное (одно из направлений данной книги) – мы уже давно решили, что переходим от моделей к бесшовной интероперабельности в управлении данных, даже национальный проект назван «Экономика данных». Кто не верит, тот должен самостоятельно прикинуть объемы современных ИМ в байтах и будущие принципы их управления и размещения через механизмы OpenBIM. Об этом уже говорят даже большие чиновники[18]. Еще быстрее эту проблему поймут, когда ГИСОГД (государственная информационная система обеспечения градостроительной деятельности или Стройкомплекс. РФ) начнет вбирать в себя ИМ всех объектов всех регионов.
Если резюмировать вышесказанное по OpenBIM на строительном этапе, то СОД уже не та, что на проектном. Она стала меньше и «отдала» большую часть функционала другим СОД иных (подрядны и даже субподрядных) ИСУП, ГИСОГД, а также ряду ГИС (государственных информационных систем), входящих в цифровую вертикаль Минстроя, и других федеральных, региональных и прочих структур. Вы говорите, что таких пока нет? Они уже планируются, даже созданы и готовы общаться с вашей «сод» (маленькими буквами) уже завтра. Вы планируете кредит в банке? Вот вам и первый соглядатай в автоматическом режиме. Пускать его полностью в свою «сод» (опять маленькими буквами) вы не будете, и он вас в свою «сод» тоже не пустит, значит – будем общаться как договоритесь, и уверен, что не через IFC, в крайнем случае – через XML-схемы, хотя тоже сомнительное удовольствие. В общем нужны новые правила, и они уже не только есть, но и работают, например, те же ИСУП и ГИСОГД.
Вообще вся цифровая вертикаль не учитывает концепцию OpenBIM. Она осталась в восторженных статьях, постах в телеграм-чатах и в неотмененных стандартах, которые, когда их замечают, моментально начинают мешать реальной жизни.
Зачем нам идти своим путем – исторический парадокс повторяется
Риторический вопрос, который многие задавали себе после событий февраля 2022 года. Вернее, даже не после начала специальной военной операции на Украине, а после демарша ряда западных вендоров в области информационного моделирования и обслуживающих их организаций, типа buildingSMART. Кстати, что эта организация сделала полезного для России, кроме сбора средств за сертификацию? Была ли у российской организации такая возможность илиона такой возможностью не воспользовалась – мы не знаем. Но основные фигуранты известны, кэшы Google помнят все, так давайте же посмотрим на лица «buildingSMART» в России на базе НАИКС (Росатома) на рисунке 2(много «на»). Среди этих лиц нет – Г. С. Сахарова, у него сейчас проблемы с правоохранителями, хотя здесь (на момент окончания написания книги – январь 2025) он до сих пор «числится» президентом НАИКС[19].

Рисунок 2. Организационная структура buildingSMART в России (бывший сайт buildingSMART в России)
Не могу упрекать или осуждать отмеченных коллег – это уже история, но из песни слов не выкинешь, ведь многие и сейчас успешно работают в Росатоме, и стандарты всей стране пишут. Просто тогда былодругое время – мы верили в то, что сейчас уже вызывает смех, иногда гнев, а кто-то просто зарабатывал деньги. Надеюсь, что вышеупомянутые коллеги тоже излечились от заблуждений.
Итак, западные вендоры BIM и прочие прозападные структуры официально покинули территорию России, повинуясь строгим санкциям. Для нормального бизнеса особенно неприятен тот факт, что, помимо брошенных потребителей, были отозваны лицензии, что лишило клиентов всего, что было накоплено в западных облачных хранилищах. Подробнее с наследством (или последствиями нахождения в России) всех этих сбежавших и некоторых их ожидающих (т. н. ждунов) разберёмся в следующей главе, а пока поговорим про исторический парадокс и подумаем – зачем нам идти своим путем.
Парадоксом называют формально-логические противоречия, которые возникают при сохранении логической правильности рассуждения. Парадокс возникает, когда два взаимоисключающих (противоречащих) суждения оказываются в равной мере доказуемыми.
Это определение парадокса, так в чем его значение в информационном моделировании? Кто читал предыдущие главы – тому легче, а для остальных кратко поясню. На нашем отечественном информационном пространстве столкнулись два разных определения: западное BIM, где собственно уже в названии есть проблемы роста, из-за чего «М» начали расшифровывать и «модель», и «моделирование», и «методология», хотя это чистый «маркетинг» по продвижению устаревшей парадигмы многомерного проектирования, где от безысходности начали размножать уровни «D», хоть мы и живем в 3-х мерном мире, а дальше пошли «D» на выбор до уровня – «nD», причем у всех и названия разные. Только вот зачем, ведь это смыслы и понятия разного уровня? Однако маркетологи западных вендоров люди без особых комплексов и знаний. Кроме западного BIM, также появился отечественный ТИМ (технологии информационного моделирования) или еще проще (а также для тех, у кого ТИМ почему-то в единственном числе) – информационное моделирование. Итак, BIM и информационное моделирование – чья возьмёт и для чего, собственно, соревноваться?
Понимая, что существующий BIM с целями и задачами современного управления данными стройки и эксплуатации (см. главы выше) справляется слабо, западные вендоры ничего не будут делать под цифровую вертикаль России, да и парадигма OpenBIM тормозит бесшовность управления данными. Остается одно – всячески ругать и хаять информационное моделирование.
И в чем же парадокс? В разнице управления данными, и сейчас скажу то, о чем не говорил в предыдущих главах:
• информационное моделирование понимает разделение процессов управления данными и их хранение, причем хранение, упорядоченное во взаимосвязи внутри ИМ, без процессов формирования и ведения (подробнее в следующих главах), а взаимосвязь – это не только связь объекта с данными, но и объектов между собой в одно-, двух- и трехмерном виде, при этом управление данными ИМ происходит в разных информационных пространствах (пусть пока СОДах) с четкой фиксацией «авторов» изменений; также управление данными не терпит «транспортных» форматов (это уже понятно по принципу XML-схематизации от Минстроя);