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

Я считаю, что на сегодняшний день трудно найти проектировщика, который справится с этой задачей, а если и найдете, то у него в команде будет 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

Почему у консалтеров нет реальных кейсов визуализации и расчета стоимости?

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

Так например программы календарного сетевого планирования предлагают отказаться от ms project'а.

И проблема в том, что пока BIM инструменты менее функциональны и удобны именно в планировании, чем ms project или primavera.

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

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

И тут главное: специалисту кто делает график не требуется наглядности, он итак это в голове у себя визуализирует - ему в программе это не особо требуется.

Отсюда, есть два пути решения задачи по внедрению в работу BIM инструментов для планирования.

Первый: в продукте надо реализовать функционал ms project. И сделать таким же удобным для задач планирования. А потом уже добавлять связку с моделью.

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

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

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

Минусом второго подхода является то, что при связке с ms project'ом приходится завязываться либо на номер строки, либо имя работ, что крайне не стабильно.

Аналогичная ситуация и с расчётом стоимости строительства. Сейчас он ведется в excel.

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

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

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

Но реализовать связку с excel еще сложнее, чем с ms project. Т.ч. скорее всего тут второй вариант и не возможен.

Проблема ответственности в стройке.

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

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

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

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

Но потом он же не может это признать и ищутся крайние.