¬аше окно в мир —јѕ–
 
Ќовости —татьи јвторы —обыти€ ¬акансии Ёнциклопеди€ –екламодател€м
—татьи

13 сент€бр€ 2016

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

јнализируем, критикуем, предлагаем...

ƒенис ќжигин, технический директор «јќ ЂЌанософтї

ƒенис ќжигин

¬ начале сент€бр€ незаметно произошло весьма знаменательное событие: на сайте ‘едерального центра нормировани€, осуществл€ющего де€тельность в сфере технического регулировани€ в строительстве (ћинстрой), в публичный доступ были выложены первые редакции сводов правил, касающихс€ технологии информационного моделировани€ (позже переложены на сайт ‘едерального агентства по техническому регулированию и метрологии (–осстандарт)). — целью обсуждени€, согласовани€ и сбора обратной св€зи. Ёти документы мы ждали очень долго: над частью из них трудились уважаемые мной авторы и регул€рно анонсировали на различных BIM-меропри€ти€х. ѕоэтому € потратил немало времени на изучение и анализ документов Ц в предлагаемой статье то, на что € обратил внимание и на что € хотел бы обратить общественное внимание.

¬ведение

—разу хотел бы подчеркнуть, что всЄ приведенное в статье Ц мое личное мнение. я вижу, что авторы документов проделали громадную работу, за что им огромное спасибо. Ќо подобные документы неминуемо вызывают споры и критику; € тоже не смог обойти этого в своей статье. ¬озможно, € в чем-то € заблуждаюсь, что-то не понимаю или неверно прочитал. ѕоэтому ожидаю в ответ некого разумного диалога Ц давайте обсуждать и рождать истину.

Ќа момент написани€ статьи четыре —ѕ, разработанные по заказу ћинистерства строительства и ∆ ’ –‘, выложены по следующим адресам:

  1. ѕравила организации работ производственно-техническими отделами.
  2. ѕравила формировани€ информационной модели объектов на различных стади€х жизненного цикла.
  3. ѕравила обмена между информационными модел€ми объектов и модел€ми, используемыми в программных комплексах.
  4. ѕравила описани€ компонентов.
ƒокументы выложены 23 августа (хот€ лично €, будучи членом рабочей группы ћинстро€ по теме BIM, увидел ссылки на эти —ѕ в одном из блогов аж 4 сент€бр€ Ц официального оповещени€ ни €, ни мои коллеги не получали). —рок обсуждени€ Ц 60 календарных дней, заканчиваетс€ в окт€бре 2016 года. ¬ремени на реакцию катастрофически мало. ѕоэтому € очень рекомендую скачать документы (или получить их по запросу на e-mail tk465-bim@mail.ru) и начать их изучение, чтобы не сложилась ситуаци€, когда все обсуждали, а вы даже не знали.

» еще одна ремарка. ѕоследовательность чтени€ документов не очень пон€тна, номеров у них нет. я читал так, как перечислил выше, и поэтому в тексте буду ссылатьс€ на документы как на первый, второй, третий, четвертый Ц в соответствии с приведенной последовательностью.

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

¬нимательно читаем документ Ђѕравила организации работ ѕ“ќї

ѕервый документ начинаетс€ с терминов, и тут мы первый раз удивл€емс€ (надо сразу сказать Ц не последний). ѕунктом 3.4 вводитс€ определение, что такое информационна€ модель:

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

¬ам не кажетс€, что это достаточно абстрактно? ѕо сути, под такое определение свободно подпадает обычна€ проектна€ либо рабоча€ документаци€ в PDF-формате, поскольку она также комплексно описывает здание и содержит текстовую и графическую информацию. ќтсюда € делаю первую заметку в голове: этот документ не описывает концепцию BIM и ее внедрение. Ётот документ описывает по сути более общее пон€тие Ђинформационна€ модельї, котора€ объедин€ет в себе любую информацию об объекте строительства. Ќикаких требований к св€занности, обновл€емости, согласованности нет. Ќет, например, и намека на то, что информационна€ модель должна собиратьс€ в какую-нибудь базу данных. Ќо ведь это неправильно! ≈сли мы говорим о будущем, то модель должна собиратьс€ в единую базу данных, многие разработчики BIM систем уже сейчас представл€ют информационную модель именно как базу данных. ќтсюда вытекает перва€ опасность: большинство людей, которые не разбираютс€ в таких тонкост€х, автоматически св€жут концепцию BIM и термин Ђинформационна€ модельї, счита€, что одно и то же. » будут жестоко разочарованы...

¬торой пункт, на который имеет смысл обратить пристальное внимание, Ц определение пон€ти€ Ђпроизводственно-технический отделї:

3.14. ѕроизводственно-технический отдел: ѕодразделение «аказчика/√енерального подр€дчика/подр€дной организации, отвечающее за анализ, проверку и координацию технической документации сопровождени€ строительства здани€.

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

„итаем далее. ¬ы€сн€етс€ интересное разделение на этапы жизненного цикла объекта строительства. ѕо сути в пункте 4.3 жизненный цикл разбиваетс€ на три этапа: стади€ проектировани€, стади€ строительства и стади€ эксплуатации. —оответственно, вывод€тс€ и три типа информационной модели: проектна€, строительна€ и эксплуатационна€. «абега€ вперед скажу, что документ Ђѕравила формировани€ информационной модели объектов на различных стади€х жизненного циклаї определ€ет несколько другие этапы, но, наверное, дл€ такого документа это не страшно, так как в сущности описываетс€ один этап Ц строительный, а термины можно согласовать потом. »так, что же строители делают с информационной моделью?

ƒл€ начала, в соответствии с пунктом 8.1, ѕ“ќ принимает от заказчика проектную информационную модель.

„то такое проектна€ информационна€ модель?
¬ разделе 8 расписаны разделы проектной информационной модели и требовани€ к ней:
  • —остоит из архитектурной модели, конструктивной модели, инженерного оборудовани€ и сетей инженерно-технического обеспечени€, строительной площадки, строительной техники и приспособлений. Ќасколько понимаю, линейные объекты и местность не рассматриваем, ок...
  • ќт проектной модели требуетс€ отсутствие пересечений между всеми видами конструктивных элементов (а как же армирование внутри стены, например?), определена иерархи€ подсистем и элементов вплоть до атомарных элементов (где определение нового термина?), а дл€ каждого атомарного элемента необходимо задать информацию о поставщиках, стоимости материалов, стоимости работ, технологии монтажа либо технологии производства. ¬ процессе перечислени€ у мен€ лично глаза округл€лись Ц мы точно говорим о стадии Ђѕроектї?..
Ќадо сказать, что по требовани€м новых —ѕ должна предоставл€тьс€ весьма подробна€ проектна€ информационна€ модель. ¬се понимают, что если эти требовани€ будут утверждены, то проектные организации должны будут сдавать информационную модель с существенно большим наполнением по сравнению с текущими требовани€ми? ¬се понимают, что все это в рамках неизменных бюджетов? Ћично € уже уверен в том, что никакого дополнительного бюджетировани€ на внедрение информационного моделировани€ не предусмотрено.

ќбращаю внимание, что в документе нет определений архитектурной и конструктивной модели! ”читыва€, что информационна€ модель Ц это не база данных (как многие ожидали), а просто комплексное описание здани€, хотелось бы знать, что под архитектурной и конструктивной моделью подразумевают авторы. ¬ каком виде предоставл€ютс€ остальные разделы Ц еще более непон€тно: в определени€х даже нет слова Ђмодельї. ¬ итоге на данном этапе пон€тно, что собираетс€ (многое), но непон€тно во что... Ќапример, если € всЄ сложу в папочку на жестком диске, то пока вписываюсь в концепцию информационного моделировани€.

ƒалее: в структуре ѕ“ќ должна быть создана группа информационного моделировани€ (пункт 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)
—амый интересный раздел, на мой взгл€д. ¬начале перечисл€ютс€ верные вещи: модель должна быть в масштабе 1:1, проектирование в метрической системе единиц (линейные же объекты не трогаем), модели по разным разделам должны иметь согласованные системы координат и т.д.

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

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 Ђ“ребовани€ к форматам выдачи результатов проектаї
Ётот раздел мен€ вообще удивил.  то мне может объ€снить, зачем он в правилах формировани€ BIM-модели на различных стади€х жизненного цикла? ћы хотим законодательно зафиксировать форматы выдачи результатов?

Ќо тогда тут должны быть указаны только открытые форматы! Ќи одного проприетарного формата, принадлежащего какому-либо вендору! ј теперь смотрим, например, пункты 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 в частности ограничивают свободный рынок, заставл€€ проектировщиков работать в программных продуктах, продиктованных заказчиком, и коррумпируют рынок, создава€ предпосылки дл€ формировани€ нерыночных отношений. Ќа мой взгл€д, это очень серьезно.

„то дальше?
≈сли честно, то дальше мне уже не особо хотелось читать этот документ. ¬озникает ощущение, что материалы не просто сырые и несогласованные. ћатериалы получились заточенными под определенные задачи и технологии. Ётого ли мы хотим?

¬нимательно читаем документ Ђѕравила обмена между информационными модел€ми объектов и модел€ми, используемыми в программных комплексахї

ƒалее € открыл документ третий, уперс€ в англо€зычный термин Ђинтероперабельностьї (зачем? есть, на мой взгл€д, вполне нормальный русский термин Ђвзаимодействиеї), пролистал до скриншотов с Revit (рисунок 4, экспорт модели в STARK), увидел отсылку на AutoCAD Civil 3D (программный продукт компании Autodesk), увидел какое-то подробное описание форматов, возможных путей взаимодействи€ и пон€л, что это совсем не то, что € ожидал увидеть.

„то € ожидал увидеть? ќб этом чуть ниже...

¬ыводы

ƒавайте соберем все выводы, которые мы разбросали по всей статье, в единый кусок.
  • ¬ документах нет четкого ответа на вопрос Ђ„то такое информационна€ модель?ї. Ёто набор документов? ‘айлов? ≈дина€ база данных? »ли набор баз данных? Ќи из определений, ни из описаний процессов, ни из описани€ об€занностей участников процесса этот вопрос не про€сн€етс€, а только все больше запутываетс€.
  • —формулированные в представленном виде правила существенно перестраивают взаимоотношени€ между строител€ми и проектировщиками. ‘актически, как € понимаю, проектировщикам предлагаетс€ вливатьс€ в строительные организации и становитьс€ их частью, а архитекторов с авторским видением проекта вообще убирают (они будут полностью подчинены строител€м). ’орошо это или плохо Ц не берусь судить. Ќо сейчас документы очень сильно смещены в сторону интересов строительных компаний.
  • ѕереход на информационное моделирование никак не финансируетс€ Ц все будет осуществл€тьс€ по законам рынка. »нформационные модели, насыщенные архитектурой, конструкци€ми, инженерией + ценами на оборудование и стоимостью работ по строительству + технологи€ми монтажа и производства (то есть существенно более подробно проработанный проект) создаютс€ силами проектных организаций бесплатно. » у проектных организаций есть выбор: либо за свой счет включатьс€ в игру по развитию информационного моделировани€ в строительстве, либо отказыватьс€ от участи€ в крупных тендерах.
  • ‘иксаци€ нативных (проприетарных) форматов файлов в правилах приведет к понижению конкурентоспособности рынка и развитию коррупционной составл€ющей. ≈сли и фиксировать какие-либо форматы, то это должны быть только свободные открытые форматы.
  • Ќужны глубоко проработанные требовани€ к описанию информационных моделей с единой классификацией строительных элементов, уровн€ми детализации и информатизации на каждом этапе. ƒа и этапы проектировани€ должны быть согласованы.
  • —тандарты нужно оторвать от форматов файлов, требований к именованию документов и т.п. ќни должны описывать принципиальные правила взаимодействи€ групп, участвующих в строительном процессе, Ц тогда будут интересны участникам рынка и ими востребованы.

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

«наете, чего мне глобально не хватает? Ёти документы пытаютс€ описать частности, да еще путаютс€ в терминах, противоречат друг другу и самим себе. Ќет единого взгл€да сверху, нет требований к сдаваемым на каждом этапе материалам. Ќет глобального понимани€, дл€ чего же нужна информационна€ модель, чем она лучше ѕ—ƒ и нынешнего процесса проектировани€-строительства. ј эти документы и должны в процессе изложени€ отвечать на все эти вопросы.

Ќапример, если мы ввели пон€тие Ђпроектна€-строительна€-эксплуатационна€ информационна€ модельї, то как минимум хотелось бы понимать Ц разорваны они в процессе или в итоге €вл€ютс€ продолжением одна другой? ƒаже на такой простой вопрос свод правил не дает ответа, хот€ что может быть проще, если ты представл€ешь себе весь процесс целиком. ќтсюда € делаю вывод, что авторы не представл€ют...

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

  •  акие разделы должны быть внесены в идеальную информационную модель, а какие рекомендуютс€ (это пытаютс€ зафиксировать в таблице 6.3 второго документа, но очень скупо; и даже в этой таблице есть ошибки). ѕон€тно, что в идеале надо вносить всЄ, но давайте тогда разобьем этот процесс во времени и на первых порах будем требовать объедин€ть архитектуру, конструкции и инженерию Ц существующие на данный момент инструменты это позвол€ют. » покажем, что можно было бы собирать в информационную модель в будущем. Ёто приведет к развитию инструментов Ц пользователи будут ожидать, а разработчики ѕќ подт€гивать свои решени€ к требовани€м.
  • ≈сли раздел внесен в проектную BIM-модель, то какие минимальные параметры он должен содержать, чтобы разработчики следующих разделов могли бы использовать эти данные дл€ своей работы. Ќапример:
    • если архитектор спроектировал помещени€ с окружающими стенами, то какие параметры должны быть заданы в такой модели, чтобы инженер по отоплению и вентил€ции смог автоматически рассчитать свою часть;
    • теоретически сметчик может в автоматическом режиме забрать задание на смету из информационной модели, так что именно проектировщики об€заны занести в модель, чтобы это случилось? ”казать виды работ?  онтролировать объемы материала? –азместить все необходимое оборудование в модели?
  •  ак формируетс€ BIM-модель? Ќе в каких форматах она хранитс€, а какие типы объектов должны быть туда заложены! ѕо какой классификации и иерархии объектов? — каким набором параметров? — какой детализацией на каждом этапе проектировани€? ѕо сути, к этому подошли англичане Ц не просто уровень проработки модели, а уровень детализации проекта (LOD в пон€тии Ђdetailї) и уровень заложенной информации (LOI) на каждом этапе. » в –оссии сейчас нужен единый каталог элементов строительной индустрии с четкой классификацией, иерархией и кодировкой Ц с этого надо начинать!
  •  ак информационна€ модель соотноситс€ с рабочей документацией?  ак она соотноситс€ сегодн€ и как должна соотноситьс€ в будущем? √лобальный вопрос, ответ на который надо искать сейчас.
  •  акова обща€ схема работы отрасли?  то-кому-что передает?  то-от-кого-что требует? √де работает сейчас информационна€ модель, а где еще может работать классическа€ документаци€? ” нас есть представление, как процесс построен на классической ѕ—ƒ, но мы до сих пор не представл€ем, как это работает (или теоретически должно работать) с информационной моделью.
ј еще мне не хватает исследовательской работы.  огда € читаю западные документы, то вижу не просто красиво оформленные, согласованные и структурированные материалы. я вижу, что над этими документами работало огромное число людей, которые стремились не создать преференции определенным технологи€м или вендору, а действительно прорабатывали теорию с научной точки зрени€, искали ответы на вопросы Ђчто нужно дл€ этого? как объединить это?ї. —оответственно, все материалы логично св€заны и позвол€ют опиратьс€ на них в дальнейшей работе. ” нас же пока документы даже сами себе противоречат.

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

ƒавайте начнем с того, что переведем на русский €зык несколько фундаментальных западных документов по BIM Ц мы же знаем список этих документов. ¬ этих документах есть определение BIM-модели и информационного моделировани€. ќбсудим, вникнем и начнем говорить на одном €зыке. ѕока же мы пытаемс€ изобрести велосипед, а не использовать уже разработанные колеса и педали.

» более практический вопрос к последнему абзацу: документ, описывающий стандарт IFC (ISO 16739:2013). ћарина √еоргиевна, в начале года ¬ы говорили на собрани€х, что готовитс€ перевод стандарта IFC на русский €зык. √де он? ѕочему этот стандарт до сих пор не представлен общественности? — этого же надо начинать!  ак можно писать стандарты формировани€ BIM-модели, когда у нас нет стандарта на содержание этой модели?

«аключение

» все-таки хотел бы завершить на позитивной ноте.

јвторы документов большие молодцы Ц они попытались подн€ть огромный пласт работы. »нформационное моделирование необходимо внедр€ть, развивать, стандартизировать. ќбсуждаемые документы показали, насколько это сложный и громадный труд. Ћично € не ожидал, что очевидные вещи требуют такого прозрачного описани€. Ќе ожидал, что надо не просто представить весь процесс целиком, но и €сно представл€ть каждый кусок процесса Ц и только тогда они сложатс€ воедино.

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



¬акансии:

јктуальное обсуждение

RSS-лента комментариев

ƒавид Ћевин
ƒавид Ћевин
ќт редактора: Ѕумажный isicad.ru?
ѕроект ЂЌародное —јѕ–-интервьюї

—лучайна€ стать€:

isicad Top 10

—амые попул€рные материалы

   ‘орумы isicad:

isicad-2010 isicad-2008
isicad-2006 isicad-2004

ќ проекте

ѕриглашаем публиковать на сайте isicad.ru новости и пресс-релизы о новых решени€х и продуктах, о проводимых меропри€ти€х и другую информацию. јдрес дл€ корреспонденции - info@isicad.ru

ѕроект isicad нацелен на

  • укрепление контактов между разработчиками, поставщиками и потребител€ми промышленных решений в област€х PLM и ERP...
ѕодробнее

»нформаци€ дл€ рекламодателей


¬се права защищены. © 2004-2017 √руппа компаний «Ћ≈ƒј—»

ѕерепечатка материалов сайта допускаетс€ с согласи€ редакции, ссылка на isicad.ru об€зательна.
¬ы можете обратитьс€ к нам по адресу info@isicad.ru.