Зачастую проектировщик хочет упростить себе жизнь, и BEP напрочь убивает требования EIR.

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

Проектировщик в таких случаях начинает шантажировать сроками и что не выполнит работы: мол выбирайте или как мы скажем или никак.

Обычно это происходит из-за того что при заключении договора проектировщик не читал EIR. Но таких становится все меньше - естественный отбор.

Если вам попался такой проектировщик, то находите компромисс и больше с ним не работайте.

В обычных же случаях проектировщик прописывает, что у него параметр Этаж - это ADSK_Этаж и т.п. И заказчика это устраивает.

Если у проектировщика свой порядок, то его всегда можно программно превратить в чужой порядок. Главное чтобы нужное количество информации и полей для классификации было заполнено.

BIM между заказчиком и техзаказчиком.

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

Также техзаказчику следует проверять объемы по модели, сравнивая с тем, что отображается в спецификациях по РД.

Информационная модель позволяет техзаказчику контролировать изменения на проекте (от первоначальной модели, стадии П) и о существенных информировать заказчика.

Специалисты ПТО техзаказчика могут подготавливать 3D отчеты, используя модель. А лучше и присылать в виде NWD модели.

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

Замечания стройконтроля лучше всего выдавать в BIM360 на основе модели, но если его нет или нельзя, то можно и Точками обзора в NWD или параметрами в элементах, с подкраской красным и настроенными поисковыми наборами.

Также появляется возможность периодической фиксации ситуации на площадке с помощью фотографий на 360 градусов.

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

Важный вопрос, с которым все сталкиваются, при внедрении BIM на стройке - это то, что КЖ модель выполнена без учета нарезки на захватки.

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

Как итог, на площадке появится своя Строительная модель. В которой выполняется дополнительная нарезка элементов на части. В ревите это можно выполнять инструментом Части, но лучше разработать плагин.

Кто готовит эту модель?

По идее, указание рабочих швов бетонирования - это функционал проектировщика КЖ. При изменениях рабочего шва генподрядчиком, его согласует авторский надзор (и вносит в рабочую документацию?! - если так, то и в рабочую модель)

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

Сегодня чаще получается, что этим занимается либо техзаказчик, либо BIM-консалтер.

Требования EIR к модели КЖ на стадии РД.

Модель должна содержать Котлован (твердотельным элементом землю с выполненным котлованом, выемку, насыпь и обратную засыпку), Шпунтовые ограждения, Распорки шпунта и опоры, Подпорные стены.

Также должны быть Сваи, Песчаная подсыпка, Бетонная подготовка, Одиночные фундаменты, Фундаментная плита, Приямки (загружаемым семейством на основе пола), Откосы бетонные в ФП, Стены, Пилоны (выполненные инструментом Стена), Колонны, Перекрытия, Балки, Капители (выполненные каждое отдельным перекрытием, либо загружаемым семейством на основе пола), Лестничные марши и Лестничные площадки (выполненные семействами для типовых решений и элементом в контексте для нетиповых);

Гидроизоляция (выполненные стенками, перекрытиями и контекстными семействами в категории Перекрытие, условной толщиной 10мм), Утеплитель (аналогично гидроизоляции).

В элементах должны быть заполнены параметры локации (Корпус, Секция, Этаж).

Все монолитные элементы должны содержать заполненный параметр Объем.

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

В монолитных элементах должны быть заполнены параметры массы каждого типа арматуры, содержащихся в них. Также должен быть заполнен параметр принадлежности к альбому РД, в котором они учтены.

В бетонных конструкциях должен быть указан Класс бетона, в стальных - Марка стали.

Не допускается моделирование нескольких строительных конструкций внутри одного элемента в контексте.

В требованиях к модели КЖ я не предъявил: "В модели должна быть Несущая арматура, поддерживающие каркасы и лягушки, Закладные детали".

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

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

Проанализировав потребность в такой детализации на стройке, я считаю что достаточно будет вписывать массу арматуры в элементы (скорее всего программно). При закрытии работ и для отчетов расчеты ведут от кубов бетона, а арматуру наоборот просят скрывать, чтобы не мешалась.

Возможно, когда инструменты для автоматизации армирования в Revit станут более доступными и стабильными, а также появится больше специалистов, кто умеет, то надо будет добавить этот пункт.

Требования EIR к модели АР на стадии РД.

Должны моделироваться кладочные стены, утеплитель (элементом стена), фасадная внешняя отделка (аналогично утеплителю), двери и окна, витражи, кровельный пирог покрытия, лифты, металлические ограждения, которых нет в КМ (заводского изготовления).

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

Также моделируются архитектурные элементы фасадов.

Двери в несущих стенах (для которых нет стен в АР) вставляются в псевдостены, с указанием в названии "Не учитывать".

Покрытие и полы, где перепад свыше 50мм моделируются с уклоном.

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

В кладочных стенах моделируются отверстия размером 100х100мм и более.

Отделка стен моделируется отдельными элементами Категории Стена, либо плагином в Категории Части. Полы моделируются на каждое помещение. Допускается моделирование стен и полов условной, примерной толщиной (округленной до 10мм).

Плинтуса, фартуки и водоотливы не моделируются.

Пару слов о нормативной документации и её связи с BIM. Сейчас на уровне министерств активно обсуждают два вопроса – «гармонизация нормативной документации» и «перевод норм в машиночитаемый вид». Это две задачи, но они тесно связаны.

Понятно, что чтобы проектировать какие-то вещи, автоматически учитывая нормы, эти нормы должна понимать программа в которой проектируют.

И так же программа должна понимать нормы при проверке – именно это планируют делать экспертизы в Solibri Model Checker, задавать правила для проверки (например «трубы водоснабжения и канализации не должны проходить через электрощитовые») и выводить отчёты из модели, если условие нарушено – писать замечание.

Как к этому прийти, и как вообще подружить нормативную документацию и автоматизированное проектирование в BIM – несколько мыслей в следующих постах.

Первая проблема которая у нас имеется с нормативами - нигде нет исчерпывающего перечня действующих документов (НТД). 1521 ПП РФ не в счёт, т.к. оно касается только документов относящихся к 384-ФЗ. Кроме них есть ещё 123-ФЗ, толстая пачка СанПиНов, региональные нормы, ведомственные и прочее.

Соответственно задача №1 - создать единую электронную онлайн-базу НТД, которая будет иметь статус государственной, и все документы в ней будут автоматически считаться легитимными. Из неё должны быть кликабельные ссылки на каждый конкретный нормативный документ.

И из этого вытекает задача №2 - поиск всех действующих НТД, перевод их в единообразную текстовую форму, и публикация в этой самой онлайн-базе.

Обязательна возможность организация поиска по ключевым словам (в тексте, в названии), по дате принятия, по любой категории, по области применения, по ведомству, по типу документа и т.п.

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

Следующий шаг в «цифровизации нормативных документов» - задача №3 - из каждого нормативного документа в едином реестре сделать кликабельными все упомянутые в нём термины, чтобы просто щёлкнув по ним можно было перейти к определению. (Получится что-то типа такой нормативной «Википедии»).

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

Потребуется привлечение экспертов для решения вопроса - следует ли где-то объединять определения, или нужно создать разные термины.

Так, например, понятие "высота здания" в СП по общественным зданиям подразумевает высоту от отметки 0.000 до верха парапета, в 123-ФЗ (пожарном) это высота от уровня земли до нижа подоконника последнего этажа, а в 73-ФЗ (о культурном наследии) это высота от уровня земли до конька кровли, или до верха выступающего оборудования.

Я сейчас могу чуть ошибаться, т.к. не смотрел детально, но суть именно в том что есть такие определения, и их много.

После решения проблем «разных определений» для терминов и заведения всех определений в единый перечень можно будет перейти к задаче №4 - превращение нормативных документов в наборы условий, в основном вида "если... то..." (фактически они и сейчас ими являются, но написано всё так что не каждый человек поймёт, не то что машина).

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

Все условия должны быть сведены в единую базу, в которой должна быть возможность поиска условий по параметру, который они описывают, по нормативному документу откуда они взяты, по типу объекта к которому они относятся и т.п.

После создания такой базы её нужно будет проверить на взаимоисключающие условия. На этом этапе тоже возникнет ряд сложностей, которые нужно будет решать с привлечением экспертов и законодателей.

Так например в Петербурге долгое время по ПЗЗ проектировщики детских садов были обязаны предусматривать на их территории не менее 50% парковочных мест для посетителей и персонала, при том что по СанПиН на территории ДОУ парковка в принципе запрещена (и на расстоянии 25м от него тоже). Как сейчас, уже не знаю, но уверен что таких мест ещё предостаточно, так как инструмент контроля их отсутствия ещё не изобрели).

После проверки базы и корректировки всех взаимоисключающих условий можно перейти наконец к задаче №5 - перевода условий в фрагменты программного кода, который можно куда-либо встроить.

Конечно, реализовывать эту задачу нужно по частям, как и есть слона: начать с одного документа, и с первых трёх пунктов – задач. Затем постепенно добавлять нормативы, и пробовать решать задачи 4 и 5 в тестовом режиме.

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

Это обязательный путь, который придётся пройти для введения автоматических проверок в экспертизах (и внутри организаций – проектировщиков, генподрядчиков и техзаказчиков).

Почему в РФ не нужно внедрять BIM на гос. уровне - с таким заголовком на прошлой неделе вышла статья Альберта Сумина.

https://zen.yandex.ru/media/id/5ac209cbad0f22cf63310792/pochemu-v-rossii-ne-nujno-vnedriat-bim-na-gosudarstvennom-urovne-5ddc3c15d7657134590e4078

Статья получилось эмоциональной и провокационной (один заголовок чего стоит?).

Альберт собирает комментарии и критику по интернету и отвечает на них, продолжением статьи. Задам и я пару вопросов:

1. С какого года в BIM стало возможно выполнить основные разделы проектирования (АР, КР, ОВ, ВК) и проверить их на коллизии? Какие есть примеры?

2. Каким образом государство, являющееся самым крупным заказчиком, может регулировать BIM на своих проектах, если не через гос. стандарты?

3. Имеются ли случаи в РФ, когда проектировщик компенсировал свои ошибки или его представители понесли наказание из-за аварии? Вообще, работает ли система ответственности в строительной сфере или это страшилки для совещаний?

Выскажу свое мнение по указанным выше вопросам:

1. В начале 2000х не было возможности выполнять BIM проекты т.к. инструменты были не готовы. Честно говоря и сейчас мало кто может выполнить проект в архикаде или аллплане. В 2008 в архикаде не было инструмента Морф (произвольная геометрия), которым сейчас в нем всё моделируется. Мебель выполнялась стенками и перекрытиями.

У них не было нормального экспорта в ifc. Сам IFC 2х3, который мы сейчас используем, только с 2008 начал появляться в этих ПО.

Не было инструментов для моделирования инженерных систем и конструктива. То, что некоторые называют тогдашним BIM'ом, не более чем 3D моделирование для визуализации. Использовали ArchCAD вместо 3ds Max и теперь примазываются мол в BIM'е давно.

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

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

Ну и эксперты в начале 2000-х в экспертизах превышали свои полномочия и могли требовать обязательного применения рекомендательных документов, т.к. они чаще всего были возрастные и по-другому, иначе как в СССР не умели. А их наделили полномочиями: без обоснования и права на апелляцию останавливать проект (что приводило к убыткам и "лучше давайте сделаем как они хотят").

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

продолжение завтра...

Про увеличение ответственности проектировщика.

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

В РФ не принято решать вопросы в судах, не принято каждое изменение в ТЗ прикреплять допником. На стройках сейчас идет взаимодействие: "ты мне я тебе" - закрываются глаза на косяки в документации, взамен на внесение доп. изменений по инициативе заказчика. Главное - дружить и искать компромисы.

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

А поход в суд с целью возмещения затрат проектировщиком дополнительных отверстий в бетоне - это его смена и остановка стройки на пару месяцев.

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

Виды отображения информации.

Отображение информации в BIM делится на 2 вида: мобильное отображение и рабочее. Рабочее отображение должно быть быстрым, должно отображать большое количество информации и позволять быстро с удобными интерфейсами управлять информацией.

Мобильное отображение должно быть сжатое: только суть, как можно меньшим объемом. Оно будет использоваться для оперативных согласований решений, выдачи замечаний, контроля хода работ.

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

Рабочее отображение нужно в основном для работы с геометрией (внести фактические отклонения, нарезать на новые захватки под ресурсы генподрядчика).

Самое главное, что оба отображения должны смотреть в одни и те же данные, что приводит к необходимости единого сервера, как на стороне редактора информации (рабочая), так и просмотрщика (мобильная).

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

В марте 2018 я ушел из ПИК-Проекта. Мой уход оброс слухами со стороны недоброжелателей, в связи с чем я бы хотел их развеять и написать как все было на самом деле.

1. Алексей Сёмин, мой непосредственный руководитель, увольняется (причины того оставлю за скобками, да я и сам не знаю).

2. Я встречаюсь с Тихомировым Директором по ИТ ДИТ ГК ПИК и договариваюсь с ним о переходе к нему, чтобы внедрять BIM в ГК ПИК через его департамент.

Причины:

- Я шел в ПИК работать с Семиным, из тех, с кем мне еще было бы интересно поработать там, были Фуксман и Тихомиров.

- В ПИК-Проекте мы уже автоматизировали к тому моменту все (кроме КР), что было эффективно автоматизировать.

- Писать системы контроля людей и генерации красивых отчетов мне было не интересно.

- Я понял, что дальнейшее развитие BIM - на стройке.

3. На совещании с Алмазовым, Семиным и Меремкуловым я говорю им, что ухожу в ГК ПИК.

4. Алмазов идет к Прыгункову (заму Гордеева) и договораивается, чтобы меня не брали в ГК ПИК, т.к. он обиделся (из-за того, что я принял решение о переходе не обсудив заранее с ним).

5. Мне пишет Прыгунков в телеграм и предлагает извиниться перед Алмазовым и вернуться в ПИК-Проект, то же предложение от Меремкулова лично, когда я принес заявление.

7. Я увольняюсь в течении 3 часов в тот же день, что и Сёмин.

Как отличить рабочую визуализацию строительства от выдуманной?

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

Фасады будут появляться не поэтажно по всему зданию, а по сторонам.

Инженерные сети не будут появляться в один момент разом.

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

Консалтеры же реализуют в графике по очереди каждый вид работ с появлением элементов по правилам зависимостей от этажей.

https://m.facebook.com/story.php?story_fbid=2135132426586276&id=773922306040635