#Практика #Стандарты Я часто пишу про техническую стандартизацию и Autodesk (прям в руку) реализовал хороший пример таковой.
В BIM360Docs и Docs появилась новая функция - стандартизация наименования загружаемых файлов.
На папку (и автоматом все подпапки) можно навесить правило нэйминга, на которое будут проверяться загружаемые файлы (это делается в Project admin - Services - Document management).
В случае, если имя файла не соответствует нужному, то он будет выведен в новое окно для ренейминга.
Правило наименования можно гибко настраивать (по умолчанию по ISO 19650).
Данный функционал доступен только в новых проектах, которые созданы после какой-то даты типа 24 марта 2021г.
В BIM360Docs и Docs появилась новая функция - стандартизация наименования загружаемых файлов.
На папку (и автоматом все подпапки) можно навесить правило нэйминга, на которое будут проверяться загружаемые файлы (это делается в Project admin - Services - Document management).
В случае, если имя файла не соответствует нужному, то он будет выведен в новое окно для ренейминга.
Правило наименования можно гибко настраивать (по умолчанию по ISO 19650).
Данный функционал доступен только в новых проектах, которые созданы после какой-то даты типа 24 марта 2021г.
#ACC Autodesk Construction Cloud. Часть 1.
Для начала расскажу о линейке продуктов BIM 360, которым приходит на смену новая сборка сервисов.
BIM 360 Docs - облачная CDE от Autodesk.
BIM 360 Design - облачный Revit server с правами доступа, процессами взаимодействия команд и функционалом Docs.
BIM 360 Model Coordination - бывший Glue - облачный Navisworks для проверки моделей на коллизии (который не работает из-за того что проверяет всë со всем, а не по настроенным поисковым наборам).
BIM 360 Field Management - первоначально Build и Field - модуль с чеклистами и ежедневными отчетами, который оказался очень слабым по функционалу (несоразмерно своей стоимости).
BIM 360 Project Management - модуль для согласования пакетов документации в zip архивах (который перестал быть актуальным после появления Reviews), meetings - бестолковая функция, позволяющая создать совещание в бим360 и привязать к нему ссылку на zoom. Не работает из-за того, что требует от всех участников процесса находиться в системе, а это дорого и у многих внешних участников нет аутодеск учетки.
BIM 360 Cost Management - потенциально крутая система для ведения бюджета, но с несколькими проблемами: сильно завязана на коды по классификатору - т.е. прям создание новых позиций ведётся поиском по коду, а не по описанию. Вторая, что требует заведения всех участников строительства и компаний в эту систему, что выглядит очень сложным.
BIM 360 Assets - возможность создавать справочник оборудования по Excel и привязывать к позициям из него замечания и документы. Пока без привязки к элементам моделей выглядит нерабочим.
Для начала расскажу о линейке продуктов BIM 360, которым приходит на смену новая сборка сервисов.
BIM 360 Docs - облачная CDE от Autodesk.
BIM 360 Design - облачный Revit server с правами доступа, процессами взаимодействия команд и функционалом Docs.
BIM 360 Model Coordination - бывший Glue - облачный Navisworks для проверки моделей на коллизии (который не работает из-за того что проверяет всë со всем, а не по настроенным поисковым наборам).
BIM 360 Field Management - первоначально Build и Field - модуль с чеклистами и ежедневными отчетами, который оказался очень слабым по функционалу (несоразмерно своей стоимости).
BIM 360 Project Management - модуль для согласования пакетов документации в zip архивах (который перестал быть актуальным после появления Reviews), meetings - бестолковая функция, позволяющая создать совещание в бим360 и привязать к нему ссылку на zoom. Не работает из-за того, что требует от всех участников процесса находиться в системе, а это дорого и у многих внешних участников нет аутодеск учетки.
BIM 360 Cost Management - потенциально крутая система для ведения бюджета, но с несколькими проблемами: сильно завязана на коды по классификатору - т.е. прям создание новых позиций ведётся поиском по коду, а не по описанию. Вторая, что требует заведения всех участников строительства и компаний в эту систему, что выглядит очень сложным.
BIM 360 Assets - возможность создавать справочник оборудования по Excel и привязывать к позициям из него замечания и документы. Пока без привязки к элементам моделей выглядит нерабочим.
#ACC Autodesk Construction Cloud. Часть 2.
Далее о предпосылках изменений.
Таким образом, мы видим что из перечисленных выше модулей - реально рабочие Docs и Design.
При этом, взяв во внимание тот факт, что половина функционала Docs также мимо (Plans, Sets, Transmittals), можно понять недовольство со стороны руководства.
(Справедливости ради добавлю что в Docs есть функции ради которых его стоит брать и из-за которых я считаю его лучшей CDE на сегодня - Project Files, Permissions, Compare, Issues, Reviews, API, ADC)
В разработке самих модулей тоже все не так гладко, они основаны на платформе Forge и каждая хотелка по функционалу упирается в доработку платформы. Таким образом все разработчики модулей как-бы садились в очередь со своими запросами на доработку платформы к центральной команде.
Внесение каждой новой функции требовало отображение еë и в мобильных версиях для Android и iOS - хотя на это похоже все забили сразу же. И вот несмотря на то, что во всех брошюрах Autodesk позиционирует как мобильное решение, оно по факту было только для модуля Docs и то не для всего функционала.
Недавно Autodesk купил PlanGrid и Assemble Systems, программистов, продакт менеджеров и дизайнеров которых можно подключить к разработке модулей Build и Takeoff.
Далее о предпосылках изменений.
Таким образом, мы видим что из перечисленных выше модулей - реально рабочие Docs и Design.
При этом, взяв во внимание тот факт, что половина функционала Docs также мимо (Plans, Sets, Transmittals), можно понять недовольство со стороны руководства.
(Справедливости ради добавлю что в Docs есть функции ради которых его стоит брать и из-за которых я считаю его лучшей CDE на сегодня - Project Files, Permissions, Compare, Issues, Reviews, API, ADC)
В разработке самих модулей тоже все не так гладко, они основаны на платформе Forge и каждая хотелка по функционалу упирается в доработку платформы. Таким образом все разработчики модулей как-бы садились в очередь со своими запросами на доработку платформы к центральной команде.
Внесение каждой новой функции требовало отображение еë и в мобильных версиях для Android и iOS - хотя на это похоже все забили сразу же. И вот несмотря на то, что во всех брошюрах Autodesk позиционирует как мобильное решение, оно по факту было только для модуля Docs и то не для всего функционала.
Недавно Autodesk купил PlanGrid и Assemble Systems, программистов, продакт менеджеров и дизайнеров которых можно подключить к разработке модулей Build и Takeoff.
#ACC Autodesk Construction Cloud. Часть 3.
Итак подытожим предпосылки пересборки продукта:
1. Многие функции не используются.
2. Всë завязано на платформе.
3. Нет адаптивного интерфейса и надо отдельно разрабатывать приложения для смартфонов и планшетов.
4. Взяты новые команды разработчиков с новыми продактами и дизайнерами.
5. Продажники устали по сто раз на вебинаре произносить "бимфрисиксти"
И перейдем к новым модулям:
Docs - тот же BIM 360 Docs, только в другом интерфейсе, и пока подглючивает местами (но уверен это скоро поправят).
Build - чеклисты из прошлого модуля, с переработанным ежедневным отчетом в функционал Forms, где гибко можно настроить ежедневные отчеты по выполненным работам, технике безопасности, количестве рабочих и прочем. Добавлен функционал Photos - для загрузки фото, видео и фото360 (есть вьювер для фото360 и распознание геопозиции на карте). В Photos легкий принцип загрузки и удобные фильтры для поиска нужных фото.
Takeoff - новый модуль для сбора объемов по 2D чертежам и моделям (типа Quantification в Navisworks, только поудобнее).
Design Collaboration - тот же Design
Model Coordination - тот же
Cost - тот же Cost Management
Insight - тот же Insight, только с возможностью создавать новые дашборды и расшаривать их другим пользователям (3 года мы ждали эту функцию)
Итак подытожим предпосылки пересборки продукта:
1. Многие функции не используются.
2. Всë завязано на платформе.
3. Нет адаптивного интерфейса и надо отдельно разрабатывать приложения для смартфонов и планшетов.
4. Взяты новые команды разработчиков с новыми продактами и дизайнерами.
5. Продажники устали по сто раз на вебинаре произносить "бимфрисиксти"
И перейдем к новым модулям:
Docs - тот же BIM 360 Docs, только в другом интерфейсе, и пока подглючивает местами (но уверен это скоро поправят).
Build - чеклисты из прошлого модуля, с переработанным ежедневным отчетом в функционал Forms, где гибко можно настроить ежедневные отчеты по выполненным работам, технике безопасности, количестве рабочих и прочем. Добавлен функционал Photos - для загрузки фото, видео и фото360 (есть вьювер для фото360 и распознание геопозиции на карте). В Photos легкий принцип загрузки и удобные фильтры для поиска нужных фото.
Takeoff - новый модуль для сбора объемов по 2D чертежам и моделям (типа Quantification в Navisworks, только поудобнее).
Design Collaboration - тот же Design
Model Coordination - тот же
Cost - тот же Cost Management
Insight - тот же Insight, только с возможностью создавать новые дашборды и расшаривать их другим пользователям (3 года мы ждали эту функцию)
#ГосТИМ Обязательный ТИМ с 01.01.2022.
Во-первых, хочу сказать спасибо тем, кто выделил отдельно термин ТИМ. То что происходит сейчас с требованиями к ТИМ и КСИ - никакого отношения к BIM не имеет. Поэтому пусть этот позор дальше ТИМ и называется.
К 01.01.2022 напишут документ, который описывает структуру папок и наименования файлов pdf и назовут это ТИМ. Там конечно будет папочка и для модели, но из требований будет лишь что она должна быть выгружена в IFC.
Эта история будет выглядеть как сдача моделей в fbx на стадии АГР в Москве (которые на проверке никто не смотрит, а вспоминают про них только когда надо для презентации "самому главному" интерактивный экран собрать чтобы покрутить "3D Москву").
IFC файлы будут готовить по чертежам специализированные компании. Сперва подключатся профессионалы и будут выставлять дикие ценники и сроки, а затем найдутся студенты которые тяп-ляп что-то набросают по принципу "и так сойдет".
Несколько госкомпаний конечно, для отчетности обучат специалистов Revit'у, а те сразу уйдут на большую оплату в ПИК (удаленно из дома работать).
Ещё некоторые госкомпании обучат спецов Renga, те попробуют реальный проект сделать, скатятся в автокад, потом выделят пару молодых, чтобы те моделировали по dwg чертежам, чтобы получить ту IFC в папочку, которую никто не будет смотреть, отчего проектировщик будет думать, что он делает "правильный ТИМ".
Но главное, что отчитаются, что "ТИМ внедрен!".
Во-первых, хочу сказать спасибо тем, кто выделил отдельно термин ТИМ. То что происходит сейчас с требованиями к ТИМ и КСИ - никакого отношения к BIM не имеет. Поэтому пусть этот позор дальше ТИМ и называется.
К 01.01.2022 напишут документ, который описывает структуру папок и наименования файлов pdf и назовут это ТИМ. Там конечно будет папочка и для модели, но из требований будет лишь что она должна быть выгружена в IFC.
Эта история будет выглядеть как сдача моделей в fbx на стадии АГР в Москве (которые на проверке никто не смотрит, а вспоминают про них только когда надо для презентации "самому главному" интерактивный экран собрать чтобы покрутить "3D Москву").
IFC файлы будут готовить по чертежам специализированные компании. Сперва подключатся профессионалы и будут выставлять дикие ценники и сроки, а затем найдутся студенты которые тяп-ляп что-то набросают по принципу "и так сойдет".
Несколько госкомпаний конечно, для отчетности обучат специалистов Revit'у, а те сразу уйдут на большую оплату в ПИК (удаленно из дома работать).
Ещё некоторые госкомпании обучат спецов Renga, те попробуют реальный проект сделать, скатятся в автокад, потом выделят пару молодых, чтобы те моделировали по dwg чертежам, чтобы получить ту IFC в папочку, которую никто не будет смотреть, отчего проектировщик будет думать, что он делает "правильный ТИМ".
Но главное, что отчитаются, что "ТИМ внедрен!".
💯1
#Теория BIM - это не 3D. Часть 2.
BIM без 3D практически невозможен. Для инфраструктурных объектов, где рельеф не сильно влияет на объемы, и сооружения одноуровневые, и не надо контролировать геометрические коллизии - может быть, но и то - это становится больше на ГИС похоже.
Да, узлы и принципиальные схемы нужно делать в 2D, но это не противоречит тому, что конструкции с которых снимается объем должны быть в 3D.
Сегодня мы просто не спускаемся до уровня сбора объемов по узлам (хотя в КМ и сборняке спускаемся) и пока допускаем узлы не моделировать, а схемы делаем упрощено без связи с моделью чтобы эксперту было что проверять. Т.е. можно ли узлы выносить в 2D зависит от уровня точности подсчета объемов, вероятности участия узловых элементов в коллизиях и функциональности, производительности программных инструментов.
Т.ч. BIM - это в первую очередь цифровой прототип будущего или существующего (для эксплуатации) объекта. Т.к. мы живëм в трехмерном пространстве, то и объект должен быть в этом виде и все элементы должны быть в геодезических координатах и своём проектном положении.
Конечно, это не означает, что 3D - это уже BIM. 3D - это необходимое но не достаточное условие, чтобы называть модель BIM. Модель из 3Ds Max или в sat формате - это не BIM. Для BIM важно наличие атрибутов в модели, той самой информации. Элементы модели в BIM - это ячейки для заполнения информации - они задают геометрическую структуру объекта, раскладывают информацию по пространственному отношению.
BIM без 3D практически невозможен. Для инфраструктурных объектов, где рельеф не сильно влияет на объемы, и сооружения одноуровневые, и не надо контролировать геометрические коллизии - может быть, но и то - это становится больше на ГИС похоже.
Да, узлы и принципиальные схемы нужно делать в 2D, но это не противоречит тому, что конструкции с которых снимается объем должны быть в 3D.
Сегодня мы просто не спускаемся до уровня сбора объемов по узлам (хотя в КМ и сборняке спускаемся) и пока допускаем узлы не моделировать, а схемы делаем упрощено без связи с моделью чтобы эксперту было что проверять. Т.е. можно ли узлы выносить в 2D зависит от уровня точности подсчета объемов, вероятности участия узловых элементов в коллизиях и функциональности, производительности программных инструментов.
Т.ч. BIM - это в первую очередь цифровой прототип будущего или существующего (для эксплуатации) объекта. Т.к. мы живëм в трехмерном пространстве, то и объект должен быть в этом виде и все элементы должны быть в геодезических координатах и своём проектном положении.
Конечно, это не означает, что 3D - это уже BIM. 3D - это необходимое но не достаточное условие, чтобы называть модель BIM. Модель из 3Ds Max или в sat формате - это не BIM. Для BIM важно наличие атрибутов в модели, той самой информации. Элементы модели в BIM - это ячейки для заполнения информации - они задают геометрическую структуру объекта, раскладывают информацию по пространственному отношению.
#Теория Уровни детализации модели.
Следующий вопрос: с какого момента BIM модель можно считать таковой? С какого уровня детализации?
Например создать кубик в размерах здания и вставить ему с свойства ссылку на комплект документации в pdf - BIM? В масштабах города есть потребность оперировать зданиями как объектами (кубиками), конечно заполнив чуть больше в них информации. Более детализированные модели для этих задач наоборот вредны, т.к. повесят всю систему и не позволят работать через браузер и со смартфонов.
Но описанный выше пример - это чистый ГИС, и выдавливание контуров зданий на высоту для получения кубиков ничего не меняет. Они по прежнему находятся в одной плоскости (ну или на поверхности ровного шара без учёта рельефа).
Т.е. я бы предложил основным критерием когда кубик переходит из ГИС в BIM - считать высотные отметки этих кубиков. Этот уровень ещё можно называть CIM или BIM LOD100.
Такой уровень детализации подходит для задач концептуального проектирования, технико-экономического обоснования и возможно эксплуатации. Такую модель можно как задание выдать для проектирования внешних сетей и инфраструктуры.
Следующий вопрос: с какого момента BIM модель можно считать таковой? С какого уровня детализации?
Например создать кубик в размерах здания и вставить ему с свойства ссылку на комплект документации в pdf - BIM? В масштабах города есть потребность оперировать зданиями как объектами (кубиками), конечно заполнив чуть больше в них информации. Более детализированные модели для этих задач наоборот вредны, т.к. повесят всю систему и не позволят работать через браузер и со смартфонов.
Но описанный выше пример - это чистый ГИС, и выдавливание контуров зданий на высоту для получения кубиков ничего не меняет. Они по прежнему находятся в одной плоскости (ну или на поверхности ровного шара без учёта рельефа).
Т.е. я бы предложил основным критерием когда кубик переходит из ГИС в BIM - считать высотные отметки этих кубиков. Этот уровень ещё можно называть CIM или BIM LOD100.
Такой уровень детализации подходит для задач концептуального проектирования, технико-экономического обоснования и возможно эксплуатации. Такую модель можно как задание выдать для проектирования внешних сетей и инфраструктуры.
#Теория Далее на этапе предпроекта появляются архитектурные элементы (стены, перекрытия, фасады, кровля, окна, двери, помещения), которые задают основные характеристики объекта. С точки зрения BIM это LOD200.
Такой детализации ещё не достаточно для выпуска документации ПД, но например достаточно для согласования АГР, АГО. Или по укрупненным объемам посчитать стоимость и технико-экономическое обоснование, согласовать архитектурную или технологическую концепцию проекта с заказчиком.
Тут я хочу отметить, почему LOD измеряется цифрами 100,200, почему нельзя их на верхнем уровне назвать 1,2,3?
Этот подход предполагает, что участники рынка могут уточнять спущенный "сверху" справочник, добавляя позиции, например - добавили дополнительное требование к LOD100, и назвали это LOD110, и используют в договорах. При этом не нарушают верхний уровень. Сделали требования между 100 и 200 - называйте 150. Т.е. в верхнеуровневых обязательных стандартах оставляется запас разрядов для внутренних корпоративных уточнений.
Да у двух компаний могут получиться свои 150е LODы, но они будут намного ближе и понятнее друг другу чем если у одного это 1+, а у другого 2-. И на такие случаи при обсуждении между компаниями можно использовать 3й разряд (151 и 152 например).
Такой детализации ещё не достаточно для выпуска документации ПД, но например достаточно для согласования АГР, АГО. Или по укрупненным объемам посчитать стоимость и технико-экономическое обоснование, согласовать архитектурную или технологическую концепцию проекта с заказчиком.
Тут я хочу отметить, почему LOD измеряется цифрами 100,200, почему нельзя их на верхнем уровне назвать 1,2,3?
Этот подход предполагает, что участники рынка могут уточнять спущенный "сверху" справочник, добавляя позиции, например - добавили дополнительное требование к LOD100, и назвали это LOD110, и используют в договорах. При этом не нарушают верхний уровень. Сделали требования между 100 и 200 - называйте 150. Т.е. в верхнеуровневых обязательных стандартах оставляется запас разрядов для внутренних корпоративных уточнений.
Да у двух компаний могут получиться свои 150е LODы, но они будут намного ближе и понятнее друг другу чем если у одного это 1+, а у другого 2-. И на такие случаи при обсуждении между компаниями можно использовать 3й разряд (151 и 152 например).
#ГосТИМ СП333. Что не так?
https://minstroyrf.gov.ru/docs/120028/
С 1 июля вступил в действие новый СП333 по информационному моделированию.
Основные замечания:
1. В СП нет разделения на стадии П и РД. Из-за этого требования к модели предъявляются сразу как к РД.
2. Требования по наличию и заполненности параметров завышены - превышают ответственность проектировщика и набор информации в РД.
3. Использование в именовании файлов английских букв. Пользователи будут путаться в переключении языков и включать в эти коды буквы на русском (А, В, К, М, Н, О, Р, С, Т, Х) - это очень большая нестабильность для файловых систем. Когда пользователь пишет всë имя файла только на русском, то этой проблемы не возникает. Современные системы с кириллицей работают нормально.
4. Требование по полному отсутствию коллизий в реальности неосуществимо. Требуется добавить допуски на проверки между системами и проверяемые элементы (чтобы не проверять мелкие трубы, монтируемые по месту и пересечения с потолками и отделкой).
https://minstroyrf.gov.ru/docs/120028/
С 1 июля вступил в действие новый СП333 по информационному моделированию.
Основные замечания:
1. В СП нет разделения на стадии П и РД. Из-за этого требования к модели предъявляются сразу как к РД.
2. Требования по наличию и заполненности параметров завышены - превышают ответственность проектировщика и набор информации в РД.
3. Использование в именовании файлов английских букв. Пользователи будут путаться в переключении языков и включать в эти коды буквы на русском (А, В, К, М, Н, О, Р, С, Т, Х) - это очень большая нестабильность для файловых систем. Когда пользователь пишет всë имя файла только на русском, то этой проблемы не возникает. Современные системы с кириллицей работают нормально.
4. Требование по полному отсутствию коллизий в реальности неосуществимо. Требуется добавить допуски на проверки между системами и проверяемые элементы (чтобы не проверять мелкие трубы, монтируемые по месту и пересечения с потолками и отделкой).
#Теория Одностадийное проектирование.
Часто вижу мнение, что надо переходить на одностадийное проектирование и мол учет этого в СП333 - это первый шаг к счастью и мол будто благодаря BIM что-то меняется и Стадия П уже становится не нужной.
Начнем с того, зачем нужна стадия П?
Чтобы застройщик мог получить согласование экспертизы и приступить к строительству как можно раньше. Т.е. стадия П на средний жилой дом разрабатывается 4 месяца, стадия РД - 6 месяцев. Если сразу начать разрабатывать стадию РД, то можно примерно сэкономить 1 месяц, но это займет 9 месяцев. Т.е. если перейти на одностадийное проектирование, то в экспертизу проект будет заходить не через 4 месяца, а через 9 с момента начала проекта и соответственно стройка начнется на 5 месяцев позже, чем сейчас.
Сегодня в 87 постановлении описано минимально достаточное количество информации о проекте, которого достаточно, чтобы экспертно оценить правильность принятых проектных решений. Т.е. мы понимаем, что в процессе разработки проекта он наполняется информацией, детализируется, если правильно проектировать, то идет от общего, от укрупненных решений к более частным, детализированным. В стадии П должны быть отображены принципиальные решения, которые должна согласовать экспертиза, по которым будет возможно отследить некорректные решения, опасные по несущим характеристикам или пожарным или санитарно-эпидемиалогическим (в общем противоречащим техническому регламенту о безопасности зданий и сооружений).
Т.е. у строительной отрасли есть выбор: либо подготавливать упрощенную версию проекта для проверки экспертами и детализировать уже после - параллельно со стройкой, либо делать полный проект и узнавать о не согласовании решений на 5 месяцев позже, когда эти решения описаны уже очень подробно и детализировано.
При этом хочу напомнить график зависимости стоимости изменений от уровня детализации, наполненности информацией проекта. Так же не стоит забывать, что проверка меньшего количества информации занимает меньше времени у экспертов и трудозатрат.
В то же время мы видим реальную ситуацию, когда на каждом проекте происходят изменения и проект проходит повторно экспертизу уже под конец строительства.
При этом мы видим появление экспертного сопровождения проекта, которое как бы должно упростить и ускорить согласование экспертизой. На практике я думаю это упрется в то, что эксперты станут "вторыми ГИПами, консультантами", и, отдайте этот проект другому эксперту, и он выдаст кучу замечаний, и не согласует проект (просто в качестве теста проведите сопровождение одной экспертизой и отдайте на проверку другой).
Т.е. тогда уж полностью упразднять институт экспертизы, но в текущих реалиях, когда в стране не сложился институт репутации компаний, когда вокруг куча компаний однодневок, генеральными директорами в которых может быть просто человек для подписи, а СРО дают допуски всем кто заплатил деньги и не несут ответственность за тех кому выдали лицензии (потому что СРО организуют "свои люди"), в такой ситуации отмена института экспертизы приведет к многократному увеличению аварий и несчастных случаев.
Есть еще мнение об этом Александра Лапыгина,
https://roseco.net/about/articles/stadijnost-proektirovaniya
но он за одностадийность, но с экспертизой на предпроекте/ТЭО.
Часто вижу мнение, что надо переходить на одностадийное проектирование и мол учет этого в СП333 - это первый шаг к счастью и мол будто благодаря BIM что-то меняется и Стадия П уже становится не нужной.
Начнем с того, зачем нужна стадия П?
Чтобы застройщик мог получить согласование экспертизы и приступить к строительству как можно раньше. Т.е. стадия П на средний жилой дом разрабатывается 4 месяца, стадия РД - 6 месяцев. Если сразу начать разрабатывать стадию РД, то можно примерно сэкономить 1 месяц, но это займет 9 месяцев. Т.е. если перейти на одностадийное проектирование, то в экспертизу проект будет заходить не через 4 месяца, а через 9 с момента начала проекта и соответственно стройка начнется на 5 месяцев позже, чем сейчас.
Сегодня в 87 постановлении описано минимально достаточное количество информации о проекте, которого достаточно, чтобы экспертно оценить правильность принятых проектных решений. Т.е. мы понимаем, что в процессе разработки проекта он наполняется информацией, детализируется, если правильно проектировать, то идет от общего, от укрупненных решений к более частным, детализированным. В стадии П должны быть отображены принципиальные решения, которые должна согласовать экспертиза, по которым будет возможно отследить некорректные решения, опасные по несущим характеристикам или пожарным или санитарно-эпидемиалогическим (в общем противоречащим техническому регламенту о безопасности зданий и сооружений).
Т.е. у строительной отрасли есть выбор: либо подготавливать упрощенную версию проекта для проверки экспертами и детализировать уже после - параллельно со стройкой, либо делать полный проект и узнавать о не согласовании решений на 5 месяцев позже, когда эти решения описаны уже очень подробно и детализировано.
При этом хочу напомнить график зависимости стоимости изменений от уровня детализации, наполненности информацией проекта. Так же не стоит забывать, что проверка меньшего количества информации занимает меньше времени у экспертов и трудозатрат.
В то же время мы видим реальную ситуацию, когда на каждом проекте происходят изменения и проект проходит повторно экспертизу уже под конец строительства.
При этом мы видим появление экспертного сопровождения проекта, которое как бы должно упростить и ускорить согласование экспертизой. На практике я думаю это упрется в то, что эксперты станут "вторыми ГИПами, консультантами", и, отдайте этот проект другому эксперту, и он выдаст кучу замечаний, и не согласует проект (просто в качестве теста проведите сопровождение одной экспертизой и отдайте на проверку другой).
Т.е. тогда уж полностью упразднять институт экспертизы, но в текущих реалиях, когда в стране не сложился институт репутации компаний, когда вокруг куча компаний однодневок, генеральными директорами в которых может быть просто человек для подписи, а СРО дают допуски всем кто заплатил деньги и не несут ответственность за тех кому выдали лицензии (потому что СРО организуют "свои люди"), в такой ситуации отмена института экспертизы приведет к многократному увеличению аварий и несчастных случаев.
Есть еще мнение об этом Александра Лапыгина,
https://roseco.net/about/articles/stadijnost-proektirovaniya
но он за одностадийность, но с экспертизой на предпроекте/ТЭО.
#ГосТИМ СП333. Что не так? Часть 2.
Поправлюсь в п.3 предыдущем, я сперва решил что разработчики предполагают комбинировать имена файлов русско-английскими. Прочитал внимательно, там предлагается закодировать полностью имя на английском (и транслите). Причем так закодировать, что в примерах сами не смогли правильно назвать R20 вместо AR20, Skolkovo из 6 символов, EM вместо EN, в общем, как прокомментировали в @bimchat, получилась одна сплошная опечатка, а не СП.
Пока не ясно, предполагают разработчики стандарта все файлы именовать на английском или только информационные модели, но уже определенно ясно, что это идет в разрез с принципами и целями стандартизации других ведомств.
Но продолжим по сути:
5. Таблица А.1 - название странное мол электронные документы не относящиеся к ЦИМ, а к ИМ они относятся?
Я так понял это текстовое описание xml формата, в котором должны вестись эти документы.
Здесь мы видим, что эти документы состоят из набора основных атрибутов документа. При чем в договоре например Участники 1 и 2 не ИННом прописываются, а названием, валюта суммы договора в денежном формате не важна, но самое интересное что сами документы URL ссылкой прикрепляются. Видать подписанные вручную сканы в PDF, загруженные на Я☁.
Т.е. электронные документы выглядят как набор атрибутов с описательной информацией и ссылками на файлообменник, где "нормальные" документы можно скачать. Наверно в экспертизе появится новая должность: скачивальщик документов.
И как вам атрибут?
"Заверение проектной организации о том, что проектная
документация разработана в соответствии с
градостроительным планом земельного участка, заданием
на проектирование, градостроительным регламентом,
документами об использовании земельного участка для
строительства (в случае если на земельный участок не
распространяется действие градостроительного регламента
или в отношении его не устанавливается градостроительный
регламент), техническими регламентами, в том числе
устанавливающими требования по обеспечению безопасной
эксплуатации зданий, строений, сооружений и безопасного
использования прилегающих к ним территорий, и с
соблюдением ТУ"
Там таких много. Определённо надо имена атрибутов как-то ограничить количеством символов.
Поправлюсь в п.3 предыдущем, я сперва решил что разработчики предполагают комбинировать имена файлов русско-английскими. Прочитал внимательно, там предлагается закодировать полностью имя на английском (и транслите). Причем так закодировать, что в примерах сами не смогли правильно назвать R20 вместо AR20, Skolkovo из 6 символов, EM вместо EN, в общем, как прокомментировали в @bimchat, получилась одна сплошная опечатка, а не СП.
Пока не ясно, предполагают разработчики стандарта все файлы именовать на английском или только информационные модели, но уже определенно ясно, что это идет в разрез с принципами и целями стандартизации других ведомств.
Но продолжим по сути:
5. Таблица А.1 - название странное мол электронные документы не относящиеся к ЦИМ, а к ИМ они относятся?
Я так понял это текстовое описание xml формата, в котором должны вестись эти документы.
Здесь мы видим, что эти документы состоят из набора основных атрибутов документа. При чем в договоре например Участники 1 и 2 не ИННом прописываются, а названием, валюта суммы договора в денежном формате не важна, но самое интересное что сами документы URL ссылкой прикрепляются. Видать подписанные вручную сканы в PDF, загруженные на Я☁.
Т.е. электронные документы выглядят как набор атрибутов с описательной информацией и ссылками на файлообменник, где "нормальные" документы можно скачать. Наверно в экспертизе появится новая должность: скачивальщик документов.
И как вам атрибут?
"Заверение проектной организации о том, что проектная
документация разработана в соответствии с
градостроительным планом земельного участка, заданием
на проектирование, градостроительным регламентом,
документами об использовании земельного участка для
строительства (в случае если на земельный участок не
распространяется действие градостроительного регламента
или в отношении его не устанавливается градостроительный
регламент), техническими регламентами, в том числе
устанавливающими требования по обеспечению безопасной
эксплуатации зданий, строений, сооружений и безопасного
использования прилегающих к ним территорий, и с
соблюдением ТУ"
Там таких много. Определённо надо имена атрибутов как-то ограничить количеством символов.
#Новости #SIGNAL Презентовал свою новую разработку на ИННОПРОМе - SIGNAL TOOLS
Пресс-релиз
https://ardexpert.ru/article/21109
Подробнее про функционал
https://docs.sgnl.pro/instructions/tools
SIGNAL TOOLS - это инструмент для создания строительной модели и работы с ней. Он включает в себя плагины на Revit и Navisworks и позволяет работать с IFC моделями из Civil3D, Tekla, ArchiCAD, Allplan, Renga, PDMS и др.
Запросить демонстрацию или триал можно письмом на почту [email protected] с темой "SIGNAL TOOLS"
Модуль можно будет купить с 02.08.2021 у партнеров SIGNAL (см. на sgnl.pro)
Пресс-релиз
https://ardexpert.ru/article/21109
Подробнее про функционал
https://docs.sgnl.pro/instructions/tools
SIGNAL TOOLS - это инструмент для создания строительной модели и работы с ней. Он включает в себя плагины на Revit и Navisworks и позволяет работать с IFC моделями из Civil3D, Tekla, ArchiCAD, Allplan, Renga, PDMS и др.
Запросить демонстрацию или триал можно письмом на почту [email protected] с темой "SIGNAL TOOLS"
Модуль можно будет купить с 02.08.2021 у партнеров SIGNAL (см. на sgnl.pro)
#Теория Захватки в BIM модели.
Чем не устраивает нарезка на захватки проектировщиком?
Нарезка очередной захватки на строительной площадке зависит от многих факторов: наличия инвентаря, готовности фронта работ, выставленных каркасов, готовности поставки бетона, загруженности крана и количества бетононасосов, количества рабочих, (арматурщиков и бетонщиков), согласования АН и скрытых работ СК.
На этапе проектирования, этой информации у проектировщика нет, он не обладает всей информацией со строительной площадки о располагаемых фронтах и ресурсах, если конечно не является по совместительству службой ПТО генподрядчика и не сидит непосредственно на объекте. Но это тогда и называется нарезка на площадке службой ПТО, а не проектировщиком РД, который по стандартной схеме не сопровождает стройку вместо ПТО, а сидит в рубашечке в офисе.
Т.е. спланировать выполнение захваток можно только накануне за неделю-две, но никак не за месяцы, когда разрабатывается РД (т.к. за месяц-два многие факторы в принципе неизвестны).
Чем не устраивает нарезка на захватки проектировщиком?
Нарезка очередной захватки на строительной площадке зависит от многих факторов: наличия инвентаря, готовности фронта работ, выставленных каркасов, готовности поставки бетона, загруженности крана и количества бетононасосов, количества рабочих, (арматурщиков и бетонщиков), согласования АН и скрытых работ СК.
На этапе проектирования, этой информации у проектировщика нет, он не обладает всей информацией со строительной площадки о располагаемых фронтах и ресурсах, если конечно не является по совместительству службой ПТО генподрядчика и не сидит непосредственно на объекте. Но это тогда и называется нарезка на площадке службой ПТО, а не проектировщиком РД, который по стандартной схеме не сопровождает стройку вместо ПТО, а сидит в рубашечке в офисе.
Т.е. спланировать выполнение захваток можно только накануне за неделю-две, но никак не за месяцы, когда разрабатывается РД (т.к. за месяц-два многие факторы в принципе неизвестны).
#Теория Проблема захваток в проектной модели РД.
Некоторые коллеги думают, что можно в той же модели что проектировщик выполняет проект, выполнять и разбивку модели на захватки.
Есть зоны ответственности, проектировщик отвечает за свою зону (проектные решения), Генподрядчик за свою (реализация и исполнительная документация), но с учётом того, что рабочие швы бетонирования генподрядчик должен согласовывать с авторским надзором (далее АН) (т.к. это может повлиять на проектное решение).
Проектировщик не готов пустить специалистов генподрядчика в свою модель, чтобы тот правил элементы проектной модели, т.к. те могут подправить и проектные решения, и ничего не докажешь.
Если проектировщик будет пересылать проектную модель по степени готовности разделов РД генподрядчику, то специалисты генподрядчика откорректировав одни элементы, нарезав их на захватки, при получении новой модели вынуждены будут повторить операцию на всех ранее обработанных элементах.
Сажать проектировщика моделировать по заданию в dwg от ПТО генподрядчика - это перекладывание на проектировщика функционала генподрядчика и задержка в получении корректных захваток в неделю, две - спустя которые, эти захватки уже никому не нужны, т.к. из автокада в pdf отчеты и исполнительные схемы давно ушли. И двойная работа получается, и никто не готов за это платить.
Выдавать модели по разделам, включая только те элементы, которые входят в выдаваемый комплект - не получается, т.к. плодится куча файлов, усложняется заполнение параметров и корректировки именований элементов, на разрезах появляются линии стыков штриховок из разных файлов (которые выглядят как герметичные разрывы и не допустимы в чертежах на монолитные конструкции (т.к. путают исполнителей).
Авторский надзор не готов моделировать все швы, т.к. никто не готов платить за АН столько во что это выходит.
На сегодняшний день, заработавшее у нас решение на практике - это создание строителями своей строительной модели с подгрузкой связью проектной, взятием из неё элементов и нарезкой забранных элементов на захватки и согласованием с АН.
Некоторые коллеги думают, что можно в той же модели что проектировщик выполняет проект, выполнять и разбивку модели на захватки.
Есть зоны ответственности, проектировщик отвечает за свою зону (проектные решения), Генподрядчик за свою (реализация и исполнительная документация), но с учётом того, что рабочие швы бетонирования генподрядчик должен согласовывать с авторским надзором (далее АН) (т.к. это может повлиять на проектное решение).
Проектировщик не готов пустить специалистов генподрядчика в свою модель, чтобы тот правил элементы проектной модели, т.к. те могут подправить и проектные решения, и ничего не докажешь.
Если проектировщик будет пересылать проектную модель по степени готовности разделов РД генподрядчику, то специалисты генподрядчика откорректировав одни элементы, нарезав их на захватки, при получении новой модели вынуждены будут повторить операцию на всех ранее обработанных элементах.
Сажать проектировщика моделировать по заданию в dwg от ПТО генподрядчика - это перекладывание на проектировщика функционала генподрядчика и задержка в получении корректных захваток в неделю, две - спустя которые, эти захватки уже никому не нужны, т.к. из автокада в pdf отчеты и исполнительные схемы давно ушли. И двойная работа получается, и никто не готов за это платить.
Выдавать модели по разделам, включая только те элементы, которые входят в выдаваемый комплект - не получается, т.к. плодится куча файлов, усложняется заполнение параметров и корректировки именований элементов, на разрезах появляются линии стыков штриховок из разных файлов (которые выглядят как герметичные разрывы и не допустимы в чертежах на монолитные конструкции (т.к. путают исполнителей).
Авторский надзор не готов моделировать все швы, т.к. никто не готов платить за АН столько во что это выходит.
На сегодняшний день, заработавшее у нас решение на практике - это создание строителями своей строительной модели с подгрузкой связью проектной, взятием из неё элементов и нарезкой забранных элементов на захватки и согласованием с АН.
#Теория AWP (advanced work packaging) в строительстве.
Данный подход предполагает, что мы нарезаем на пакеты общий объем работ и затем принимаем все пакеты по очереди и не переходим к следующему, пока не будет реализован, принят и закрыт предыдущий.
Данный подход имеет место быть, но до определенного уровня. На крупных объектах, где работы выполняются годы, необходимо их делить на пакеты, чтобы не происходило накопление отложенных договоренностей, чтобы не произошло ситуации на строительной площадке, когда подрядчику выгоднее уйти, чем погашать отложенные долги.
Но сегодня есть некоторые проблемы с применением данного подхода. Во-первых, увидев в нём здравое зерно и знакомые сущности - элементы, специалисты BIM пробуют натянуть эти элементы-пакеты на элементы информационной модели проектировщика. Здесь происходит сбой, т.к. проектировщик когда моделирует элементы, выполняет их так, как ему нужно для чертежей и спецификаций, а не как нужно их строить (тут обычно возникают споры мол он должен моделировать как будет строиться, а иногда и эксплуатироваться, но если вкратце - он не может, т.к. не обладает информацией о ситуации и ресурсах, т.к. делает это намного раньше чем данная информация появляется в принципе).
Во-вторых, если мы будем принимать работы у генподрядчика пакетами, а не как сейчас по КС-2 по выполненным работам за месяц, то надо закрывать их не в конце месяца, а по приемке пакета, т.к. выполненные, но не принятые в конце месяца пакеты переносятся на следующий и приводят к кредитованию генподрядчиком застройщика (что в текущих бизнес-условиях приводит к банкротству генподрядчика, всех субчиков, остановке стройки, смене генподгрядчика, разбору кранов, бытовых и прочего - в общем +6мес. к сроку реализации проекта). Но такой подход требует перенастройки всех экономических отношений, которые сложились за многие годы.
Сейчас строительные компании обычно платят зарплату своим сотрудникам 2 раза в месяц, выполненные ими работы в прошлом месяце они выставляют в текущем и расчитывают получить оплату в текущем. Если оплата переместится на следующий, то это уже кредитование застройщика за свой счет. У каждой компании свои запасы и пределы таких кредитований (это зависит от размера компании и стоимости её услуг), но обычно через месяц уже встает вопрос: платите или уходим.
И вот в таких условиях если мы не приняли 1 пилон на 2 м3 из 1700 м3, то можно по КСке заплатить за 1698 м3 и работать дальше. Если по логике AWP не должен приниматься и оплачиваться весь пакет, то это ведет к банкротству подрядчиков. А если по ней также можно оплатить 1698, то она ничем не отличается от текущей логики, просто искусственная детализация договора.
Данный подход предполагает, что мы нарезаем на пакеты общий объем работ и затем принимаем все пакеты по очереди и не переходим к следующему, пока не будет реализован, принят и закрыт предыдущий.
Данный подход имеет место быть, но до определенного уровня. На крупных объектах, где работы выполняются годы, необходимо их делить на пакеты, чтобы не происходило накопление отложенных договоренностей, чтобы не произошло ситуации на строительной площадке, когда подрядчику выгоднее уйти, чем погашать отложенные долги.
Но сегодня есть некоторые проблемы с применением данного подхода. Во-первых, увидев в нём здравое зерно и знакомые сущности - элементы, специалисты BIM пробуют натянуть эти элементы-пакеты на элементы информационной модели проектировщика. Здесь происходит сбой, т.к. проектировщик когда моделирует элементы, выполняет их так, как ему нужно для чертежей и спецификаций, а не как нужно их строить (тут обычно возникают споры мол он должен моделировать как будет строиться, а иногда и эксплуатироваться, но если вкратце - он не может, т.к. не обладает информацией о ситуации и ресурсах, т.к. делает это намного раньше чем данная информация появляется в принципе).
Во-вторых, если мы будем принимать работы у генподрядчика пакетами, а не как сейчас по КС-2 по выполненным работам за месяц, то надо закрывать их не в конце месяца, а по приемке пакета, т.к. выполненные, но не принятые в конце месяца пакеты переносятся на следующий и приводят к кредитованию генподрядчиком застройщика (что в текущих бизнес-условиях приводит к банкротству генподрядчика, всех субчиков, остановке стройки, смене генподгрядчика, разбору кранов, бытовых и прочего - в общем +6мес. к сроку реализации проекта). Но такой подход требует перенастройки всех экономических отношений, которые сложились за многие годы.
Сейчас строительные компании обычно платят зарплату своим сотрудникам 2 раза в месяц, выполненные ими работы в прошлом месяце они выставляют в текущем и расчитывают получить оплату в текущем. Если оплата переместится на следующий, то это уже кредитование застройщика за свой счет. У каждой компании свои запасы и пределы таких кредитований (это зависит от размера компании и стоимости её услуг), но обычно через месяц уже встает вопрос: платите или уходим.
И вот в таких условиях если мы не приняли 1 пилон на 2 м3 из 1700 м3, то можно по КСке заплатить за 1698 м3 и работать дальше. Если по логике AWP не должен приниматься и оплачиваться весь пакет, то это ведет к банкротству подрядчиков. А если по ней также можно оплатить 1698, то она ничем не отличается от текущей логики, просто искусственная детализация договора.
#IFC А вы уверены, что IFC - это универсальный формат обмена информационными моделями?
Добрался до экспорта из ArchiCAD'а 24 и приуныл :(
Свой IFC экспорт для разных программ, а для подсчета объемов по модели и работы с ней на стройплощадке нету.
Кто подскажет как выгрузить геометрические свойства объемов элементов IfcQuantityVolume, IfcQuantityWeight? Пробую тупо включить ВСË, но экспорт длится под 4 часа. А Невис конвертирует все 8 и падает.
Точный экспорт геометрии выгрузил без перекрытий и без объемов. Там вообще у каждой настройки экспорта свои приколы - то тут выбивает, то там
К слову, вспомнил про стрим на похожую тему @aleksandrsett
https://www.youtube.com/watch?v=F7veOVAwD4U&feature=youtu.be
Добрался до экспорта из ArchiCAD'а 24 и приуныл :(
Свой IFC экспорт для разных программ, а для подсчета объемов по модели и работы с ней на стройплощадке нету.
Кто подскажет как выгрузить геометрические свойства объемов элементов IfcQuantityVolume, IfcQuantityWeight? Пробую тупо включить ВСË, но экспорт длится под 4 часа. А Невис конвертирует все 8 и падает.
Точный экспорт геометрии выгрузил без перекрытий и без объемов. Там вообще у каждой настройки экспорта свои приколы - то тут выбивает, то там
К слову, вспомнил про стрим на похожую тему @aleksandrsett
https://www.youtube.com/watch?v=F7veOVAwD4U&feature=youtu.be