Новые своды правил по информационному моделированию: много ли работы еще требуется?

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

Введение

На момент написания статьи четыре СП, разработанные по заказу Министерства строительства и ЖКХ РФ, выложены по следующим адресам:

1. Правила организации работ производственно-техническими отделами.
2. Правила формирования информационной модели объектов на различных стадиях жизненного цикла.
3. Правила обмена между информационными моделями объектов и моделями, используемыми в программных комплексах.
4. Правила описания компонентов.

И еще одна ремарка. Последовательность чтения документов не очень понятна, номеров у них нет. Я читал так, как перечислил выше, и поэтому в тексте буду ссылаться на документы как на первый, второй, третий, четвертый – в соответствии с приведенной последовательностью.

Замечание по окончанию написания статьи: в этой статье обсуждаю подробно только первый и второй документы – как, на мой взгляд, самые фундаментальные; два последних документа я практически опустил: разобраться бы с первыми двумя...

Внимательно читаем документ «Правила организации работ ПТО»

3.4. Информационная модель: комплексное описание здания, которое содержит полную проектную информацию (текстовую, графическую) о материальных и нематериальных элементах.

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

Второй пункт, на который имеет смысл обратить пристальное внимание, – определение понятия «производственно-технический отдел»:

3.14. Производственно-технический отдел: Подразделение Заказчика/Генерального подрядчика/подрядной организации, отвечающее за анализ, проверку и координацию технической документации сопровождения строительства здания.

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

Читаем далее. Выясняется интересное разделение на этапы жизненного цикла объекта строительства. По сути в пункте 4.3 жизненный цикл разбивается на три этапа: стадия проектирования, стадия строительства и стадия эксплуатации. Соответственно, выводятся и три типа информационной модели: проектная, строительная и эксплуатационная. Забегая вперед скажу, что документ «Правила формирования информационной модели объектов на различных стадиях жизненного цикла» определяет несколько другие этапы, но, наверное, для такого документа это не страшно, так как в сущности описывается один этап – строительный, а термины можно согласовать потом. Итак, что же строители делают с информационной моделью?

Для начала, в соответствии с пунктом 8.1, ПТО принимает от заказчика проектную информационную модель.

Что такое проектная информационная модель?

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

Обращаю внимание, что в документе нет определений архитектурной и конструктивной модели! Учитывая, что информационная модель – это не база данных (как многие ожидали), а просто комплексное описание здания, хотелось бы знать, что под архитектурной и конструктивной моделью подразумевают авторы. В каком виде предоставляются остальные разделы – еще более непонятно: в определениях даже нет слова «модель». В итоге на данном этапе понятно, что собирается (многое), но непонятно во что... Например, если я всё сложу в папочку на жестком диске, то пока вписываюсь в концепцию информационного моделирования.

Далее: в структуре ПТО должна быть создана группа информационного моделирования (пункт 5.2), которая начинает разрабатывать строительную информационную модель путем «наполнения новыми атрибутами элементы проектной информационной модели» (пункт 9.1). Тут мой мозг начал взрываться...

Что происходит в строительной информационной модели?

• иметь базу данных элементов проектной информационной модели в согласованном между проектировщиками и ПТО формате (в моем понимании понятие «атрибут» подразумевает наличие какой-нибудь базы данных – или можно как-то по-другому?);
• иметь инструменты редактирования (!) проектной информационной модели.

Раздел 6 определяет требования к программному обеспечению, которое используется в ПТО для информационного моделирования. Итак, это ПО должно: проверять на ошибки, просматривать, осуществлять документооборот и проводить контроль качества. Оно не должно редактировать! Как мы будем наполнять информационную модель атрибутами?

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

По текущим правилам, насколько я знаю, проектировщики сдают заказчику проектно-сметную документацию (ПСД). Далее заказчик передает ПСД строителям, а проектировщик находится на авторском надзоре (проектировщик, ответственный за ПСД!). В процессе строительства строитель вносит замечания и делает исполнительную документацию (as-build), а иногда исполнительную делают сами проектировщики по отдельному договору с заказчиком. Но в любом случае четко понятно, кто что сделал и кто за что отвечает, а в случае проблем ясно, кого привлекать к ответственности.

Тут же по новому своду правил изменения в строительную информационную модель вносят и строители, и проектировщики! И нет никаких правил ответственности и последовательности. По-моему, этот документ фундаментально изменяет отношения «проектировщик – строитель». Нет? Хорошо... Тогда попробуем найти ответственного. Читаем дальше...

В пунктах 11.5, 11.6 написано, что ответственность за формирование финальной (передаваемой в эксплуатацию) строительной информационной модели несет руководитель проекта, который подписывает ее электронной подписью. Теперь понятно? Ответственность за проект полностью лежит на строителях! Архитекторы с авторской задумкой, проектировщики, продумывающие проектное решение – вам спасибо, вы свободны. Мы построим то, что построим...

Подходим к концу документа

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

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

1. Пункт 9.6 сообщает, что детализацию строительной информационной модели задает приложение Г. Идем в приложение Г и видим четыре типа детализации: модель не требуется (модель? да что ж такое, черт возьми, «модель»?), низкая, высокая, локально высокая. Ух, я не сталкивался с такими формулировками по детализации. Спасибо, что там же в приложении расписали, что это означает. Но, забегая вперед, скажу, что документ «Правила формирования информационной модели объектов на различных стадиях жизненного цикла» определяет совершенно другие степени детализации: LOD100, LOD200 и т.д.). Кто-нибудь пытался согласовать терминологию?

2. Приложение А. Укрупненные функции участников процесса строительства. Ради интереса стал подробнее читать функции проектировщика. Вы не поверите! Там нет ни слова о разработке информационной модели. Только проектно-сметная документация, авторский надзор, разработка дополнительных проектных решений и т.д. Так делает проектировщик информационную модель или только ПСД?

Итак, первый документ оставил у меня впечатление рассогласованности и общего непонимания процесса. Переходим ко второму...

Внимательно читаем документ «Правила формирования ИМ на различных стадиях ЖЦ»

Почему-то тут сразу бросается в глаза, что документ не предназначен для информационного моделирования линейных объектов, а также цифровых моделей местности (пункт 1.4). А что у нас остается? Гражданские и общественные здания в рамках территориально-нераспределенных строительных площадок? Вернулся к первому документу – там примерно то же самое: строительство новых, реконструкция и снос существующих зданий и сооружений, а также благоустройство и инженерная подготовка территорий. Ок.

В целом документ должен задавать правила формирования информационной модели для проектировщиков (проектная информационная модель), для строителей (строительная информационная модель) и для эксплуатации (эксплуатационная информационная модель). Мои ожидания верны? Проверим...

Читаем терминологию. Угадайте, что я начал читать первым? Правильно – определение термина «Информационная модель здания». И тут намного интереснее:

3.3 информационная модель здания или сооружения (building information model, BIM): Цифровое представление физических и функциональных характеристик здания или сооружения при помощи совокупности элементов и информации, служащее коллективным ресурсом знаний о нем на протяжении полного жизненного цикла.

Обращает на себя внимание англоязычный термин – это обнадеживает, что хотя бы говорим сейчас об одном и том же. Очень важное примечание:

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

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

Еще один термин – LOD (level of development, уровень проработки модели):

3.15 уровень проработки (level of development, LOD): Определяет полноту проработки элемента информационной модели. Уровень проработки задает минимальный объем геометрической, пространственной, количественной, а также любой атрибутивной информации, необходимой и достаточной для решения задач моделирования на конкретном этапе жизненного цикла объекта строительства.

Это американский термин, введенный, если не ошибаюсь, Американским институтом архитектуры (AIA). Напомню, что англичане этот термин уточнили, разбив его на LOD (Level of Detail, уровень детализации) и LOI (Level of Information, уровень информатизации). Ок, мы идем пока по более широкой американской терминологии...

Снова забегая немного вперед, хочется сказать, что все-таки по документу отсутствует расшифровка многих терминов: ТОиР (пункт 5.7.1), ЧС (таблица 5.1), СМР (пункт 5.6.1), КР (пункт 6.1.14). Думаю, всем очевидно, что в этом плане нужна еще очень большая работа по выработке единых терминов и расшифровок.

Пойдем далее...

Общие положения (раздел 4)

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

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

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

Получается, что именно заказчик будет задавать, в каком программном обеспечении должны работать проектировщик и строитель, как они должны именовать файлы, какими форматами обмениваться, как кодировать элементы модели и т.д.! Ой-ой-ой... А я думал, что это будет делать Минстрой – формировать правила взаимодействия рынка, определяя ключевые требования. В итоге все сводится к тому, что придумает заказчик. Это первый звоночек в моей голове.

Кстати, пункт 4.12 делает информационную модель главнее технической документации:

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

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

Требования к информационным моделям (раздел 6)

Но есть и пункты, которые вызывают удивление. Например:

6.1.13 Как правило, любой объект, который помещается в куб 100 x 100 x 100 мм, не моделируется или заменяется условным 2D графическим объектом, с необходимым набором атрибутов.

Во-первых, это противоречит пункту 4.12, описанному чуть выше: если мы не моделируем что-либо, то это надо вносить в техническую документацию, а она является вторичной по отношению к информационной модели – вас не расстраивает такая логическая нестыковка?

Во-вторых, не очень понятно, что это за 2D-представление: это 2D-представление в трехмерном пространстве или просто 2D-представление на рабочей документации (чертежах)? Логика говорит, что это должно быть в 3D-пространстве, однако почему тогда нельзя ставить 3D-объекты, но с малой детализацией (коробка, шар, конус и т.д.)? Но если упор делается именно на 2D-представлении, то получается, что это не заносится в 3D. Тогда образуется в-третьих...

В-третьих, почему мелкие объекты, «как правило», не моделируются? Например, охранно-пожарная часть почти целиком состоит из объектов, вписывающиеся в упомянутые габариты, – она не должна включаться в BIM? Да и вся инженерная часть: фитинги на трубах, коробки разветвительные, извещатели, розетки, выключатели, контрольно-измерительные приборы – очень многие объекты инженерной части имеют достаточно малые габариты. Их не проектируем в BIM? На мой взгляд, технология BIM очень хороша для задач инженеров: расчеты оповещения, освещения, падения напряжения, моделирование чрезвычайных ситуаций, проектирование спринклерных систем и многие другие инженерные задачи удобно решать именно через связанную модель, трехмерное пространство и единую базу данных для раздела. Как эти задачи решать с помощью чистого 2D (даже с атрибутами)? Как в конце концов с помощью чистого 2D с атрибутами закладывать технологию монтажа и/или производства, цены, стоимость работ, которые требуются по предыдущему документу?

Далее пункт 6.1.14:

6.1.14 На текущем уровне развития программно-аппаратных ресурсов 3D-моделирование арматуры железобетонных изделий и 3D-деталировка узлов металлоконструкций не должны быть обязательными требованиями при проектировании раздела КР.

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

При этом пункт 6.1.14 противоречит пункту 6.3 («Требования к составу элементов информационной модели»), в котором указано, что для раздела КР в состав информационной модели включается арматура. Она должна быть двумерной?

Пункт 6.7 «Требования к форматам выдачи результатов проекта»

Но тогда тут должны быть указаны только открытые форматы! Ни одного проприетарного формата, принадлежащего какому-либо вендору! А теперь смотрим, например, пункты 6.7.1 и 6.7.2:

6.7.1 Требования к форматам выдачи результатов BIM-проекта или отдельных работ по информационному моделированию должны быть указаны в Информационных требованиях технического заказчика и зафиксированы в Плане реализации BIM-проекта.

6.7.2 Форматы выдачи информационных моделей (включая сводные модели) могут быть: нередактируемыми, например, IFC (версии 2x3 и выше), 3D PDF, 3D DWFx и другие) и нативными.

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

А теперь другой взгляд – со стороны проектировщиков. Стандарт не фиксирует требования к BIM-моделям, а фиксирует форматы, в которых все должно сдаваться, и разрешает использовать нативные форматы различных вендоров. Получается, что проектная организация, свободно работающая на рынке, теперь должна либо заточиться на какой-то формат файлов определенного вендора и участвовать только в таких тендерах, где требуется этот формат, либо уметь работать под различные форматы файлов, используя различные BIM-инструменты! Понятно, что у нас не получится сегодня делать модель в Revit, завтра в ARCHICAD, а послезавтра в Tekla – сложно найти на рынке таких универсальных специалистов, которые легко меняют проектный инструмент в зависимости от заказчика. А помним, что закупка лицензионного программного обеспечения – это задача проектных организаций. При этом выбирают решение не они, а заказчики. Весело? Как долго при таких законах мы будем говорить о свободном рынке?

Есть и другая проблема с форматами файлов и достаточно частным представлением задачи в своде правил: технологическая. У ряда вендоров уже сейчас идет отрыв от файлов и форматов и происходит переход на базы данных. Например, в Graphisoft ARCHICAD и Trimle Tekla создается сетевая база данных, представляющая информационную модель по разделу. Когда я разговаривал с членами рабочей группы по внедрению BIM в Англии, они рассказывали о том, что есть идеи собирать сводную BIM-модель на сервере в виде базы данных (используя открытый формат IFC в качестве импортирующего формата). Это очень логичный шаг – сводную информационную модель надо (!) собирать в виде базы данных на общем сервере. Тогда открываются широкие перспективы централизации информации, настройки различных уровней доступа в модель, анализа модели, оперативного обновления информации и т.д.

Но в России после ввода таких стандартов подобная технология будет объявлена несоответствующей требованиям BIM (а значит несоответствующими окажутся и поддерживающие ее программные продукты). Не приведет ли это к тому, что весь мир через 5-10 лет убежит вперед, а мы, зафиксировав в стандартах форматы файлов, зависнем позади? Тем более что одного из крупнейших вендоров (Autodesk) такая ситуация будет полностью устраивать – их-то продукты работают на файловой структуре. Например, Revit создает так называемый центральный файл для совместной работы (то есть BIM-модель собирается в расшаренном на сети RVT-файле), и разработки уровня, например, BIM-сервера у них сейчас нет. NavisWorks – это сбор разных по форматам файлов (в основном файлов, поддерживаемых продуктами Autodesk) в сводную модель, построенную на файловой структуре. Собственно, требования к правильному наименованию, расположению в сети, которые меня очень удивили в начале документа, идут именно из этих особенностей программных продуктов Autodesk.

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

Что дальше?

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

Что я ожидал увидеть? Об этом чуть ниже...

Выводы

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

Ощущение пустоты

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

На мой взгляд, свод правил должен определять:

• Какие разделы должны быть внесены в идеальную информационную модель, а какие рекомендуются (это пытаются зафиксировать в таблице 6.3 второго документа, но очень скупо; и даже в этой таблице есть ошибки). Понятно, что в идеале надо вносить всё, но давайте тогда разобьем этот процесс во времени и на первых порах будем требовать объединять архитектуру, конструкции и инженерию – существующие на данный момент инструменты это позволяют. И покажем, что можно было бы собирать в информационную модель в будущем. Это приведет к развитию инструментов – пользователи будут ожидать, а разработчики ПО подтягивать свои решения к требованиям.
• Если раздел внесен в проектную BIM-модель, то какие минимальные параметры он должен содержать, чтобы разработчики следующих разделов могли бы использовать эти данные для своей работы. Например:
  • если архитектор спроектировал помещения с окружающими стенами, то какие параметры должны быть заданы в такой модели, чтобы инженер по отоплению и вентиляции смог автоматически рассчитать свою часть;
  • теоретически сметчик может в автоматическом режиме забрать задание на смету из информационной модели, так что именно проектировщики обязаны занести в модель, чтобы это случилось? Указать виды работ? Контролировать объемы материала? Разместить все необходимое оборудование в модели?
• Как формируется BIM-модель? Не в каких форматах она хранится, а какие типы объектов должны быть туда заложены! По какой классификации и иерархии объектов? С каким набором параметров? С какой детализацией на каждом этапе проектирования? По сути, к этому подошли англичане – не просто уровень проработки модели, а уровень детализации проекта (LOD в понятии «detail») и уровень заложенной информации (LOI) на каждом этапе. И в России сейчас нужен единый каталог элементов строительной индустрии с четкой классификацией, иерархией и кодировкой – с этого надо начинать!
• Как информационная модель соотносится с рабочей документацией? Как она соотносится сегодня и как должна соотноситься в будущем? Глобальный вопрос, ответ на который надо искать сейчас.
• Какова общая схема работы отрасли? Кто-кому-что передает? Кто-от-кого-что требует? Где работает сейчас информационная модель, а где еще может работать классическая документация? У нас есть представление, как процесс построен на классической ПСД, но мы до сих пор не представляем, как это работает (или теоретически должно работать) с информационной моделью.

Ознакомьтесь, например, с документами по информационному моделированию на официальном сайте английского правительства: https://www.gov.uk/search?q=Building+information+modelling. Обратите внимание насколько глубоко, универсально, ярко и понятно поданы материалы.

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

И более практический вопрос к последнему абзацу: документ, описывающий стандарт IFC (ISO 16739:2013). Марина Георгиевна, в начале года Вы говорили на собраниях, что готовится перевод стандарта IFC на русский язык. Где он? Почему этот стандарт до сих пор не представлен общественности? С этого же надо начинать! Как можно писать стандарты формирования BIM-модели, когда у нас нет стандарта на содержание этой модели?

Заключение

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

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