На стратегической сессии ДОМ.РФ «Переход на ТИМ для застройщиков», состоявшейся 24.04.2024, выступал Начальник отдела технологий информационного моделирования СПб ГАУ «Центр государственной экспертизы» Шерстенников Игорь Александрович. Среди прочего им была обозначена следующая проблематика: ЦИМ и проектная документация - разные вещи. По материалам его выступления а так же поле личного общения написана эта статья.
Исходным посылом стала фраза, высказанная Игорем Александровичем::
".. идея настройки отдельных видов в BCF с включенными определенными аннотациями меня не покидает."
По прежнему и на текущий момент времени, в рамках цифровизации строительной области и перехода на технологии информационного моделирования не звучит описание вектора и конечные решения по преобразованию проектной документации в формат цифрового двойника; с сохранением, а - исходя из логики цифровой трансформации - и улучшением качества проектной информации.
Рассматривая проектную документацию глобально как взаимоувязанный объем технической информации, применим известные критерии качества информации. Таковыми критериями могут выступать: целостность, точность, релевантность, интерпретируемость, доступность, проверяемость. Таким образом, говоря о цифровой трансформации строительной отрасли, останавливаясь на трансформации формы (формата) Проектной документации, и процессов связанных с проектной документации (ПД) - следует рассматривать преобразование как улучшение указанных критериев.
Однако любые критерии оценки объекта (а в нашем случае - системы), не определяют ни вектор ни механизм, ни результат преобразования. Механизмы и требования определяются на основании некоторого предполагаемого результирующего состояния трансформируемой системы.
Понятие "трансформации" говорит так же о ограничении связанном с работоспособностью системы в процессе преобразования.
С точки зрения автора, одним из определяющих критериев для формирования представления о результирующей системе ПД, будет являтся применимость подобной "трансформированной" проектной документации в всех известных и предполагаемых процессах отрасли. А так же соответствие стратегическим целям, обозначенным в том числе в стратегическом плане мероприятий : "Распоряжение Правительства Российской Федерации от 20.12.2021 № 3719-р."
Возъмем на заметку сформированное направление по предоставлению документов информационной модели в форме XML документов, что является безусловно обязательным при переходе в цифровизацию. Хочется лишь упомянуть один момент:
Проектировщик не должен разбираться в форматах и тратить свой драгоценный ресурс на перипетии преобразования информации. (прим.) Этот постулат автор выносит во главу угла, как важный фактор повышения качества и производительности.
XML всего лишь машиночитаемый результат работы заполнения предустановленной схемы нужными данными. Эту задачу выполняет любой человеко-машинный интерфейс, который определяет что именно и в какое поле должен ввести пользователь. Для передачи информации о структуре и данных пользователя и существует один из вариантов представления внутренний "машинный" формат XML. Понимание этого факта позволяет читать НД с требованиями к предоставлению в формате XML, как требование к предоставлению данных в структурированном электронном виде. Для выполнения этого надо дать проектировщику интерфейс с этой структурой и полями, а не требовать результирующий машинный формат данных. Если утрировать - попросите бухгалтера заполнить таблицу 1С с помощью SQL запросов.
Возвращаясь к цифровой трансформации проектной документации постараемся предположить результат такового преобразования.
ПД в текущей форме состоит из текстовой, графической частей и смет. Преположим текстовая часть унифицируется и передается в машиночитаемом формате. Хотя надо понимать, что писание того или иного проектного решения невозможно полностью унифицировать, но большинство типовых решений возможно описывать строгими полями значений. Что дальше делать с этой информацией рассмотрим далее...
Добавляем в проектную документацию цифровую информационную модель. На текущий момент ЦИМ это сферический конь в вакууме. Она не привязана ни к чему. Предполагается, что графическая часть получена из предоставленной модели. На текущий момент это не соответствует истине в большинстве случаев. Для эксперта (далее эксперт как внутренний специалист про проверке, так и внешний государственный контроль) верификация модели и чертежей становиться дополнительной задачей.
Будем исходить из того, что инженеры проектировщики действительно выпускаю чертежи из модели, и при внесении изменений по требованиям эксперта корректируют модель и автоматически пере-выпускают графическую часть. Как должен выглядеть механизм, позволяющий однозначно эксперту быть уверенным в соответствии чертежа и модели.
Ответ очевиден - графическая чать должна формироваться на стороне эксперта - на "лету" из модели. Как, применяя данное решение, станет выглядеть графический формат ПД попадающий к эксперту - это аннотации, текстовые и графические примитивы, наложенные на видовой экран ссылающийся на модель.
По сути любая программа BIM моделирования предоставляет 4 базовые функции - построение модели, задание атрибутивной информации, консолидация информации (ВОР, спецификации) и, разумеется, оформление чертежей. Функционал просмотра модели и проверки на коллизии по определению есть и у эксперта. Дооснащение некоторыми функциями среды анализа ПД позволит в корне преобразовать работу с документацией, при том, что эти функции уже реализованы в Российских ПО! Разумеется, ПД будет направляться к эксперту в форме связанных ограниченных и подписанных файлов, и развертываться в среде общих данных, предоставляющих функционал рабочего места.
Промоделируем на "рабочем месте эксперта" анализ ПД:
1. ГЧ в форме ссылочного видового экрана. Автор общался с различными экспертами и с заказчиком и может сделать вывод. Без отображения планов и разрезов ГЧ строительной документации не читаема. Т.е. имеется ввиду, что просмотр 3D не может заменить это плоское отображение. Так что принимаем, что эксперт смотрит раздел, там есть чертежи. Но что мы получаем!
2. 3D аннотированные виды. По сути тот же аннотированный вид - графическая чать, но уже в 3D представлении. Еще раз упоминаем принцип - "отрисовка" идет на стороне эксперта. Т.е. "подложка" чертежа - это ссылка на модель. размеры, выноски, линии, текст - объекты в составе чертежа. Аннотирование в модель добавить можно, но таковое аннотирование для каждого раздела, чертежа или участка чертежа различное. Настройка аннотаций в ЦИМ для читаемости каждого конкретного раздела по сути превратится в аннотирование каждого конкретного чертежа + фильтрация лишних сущностей.
3. ВОР и спецификации ссылающиеся на объемы из модели. Т.е. строятся "на лету" на стороне эксперта. При этом оформление листов выполнено проектировщиком, а результаты заполняются на стороне эксперта.
4. ТЧ в структурированном формате с полями, заполненными выгрузками данных из той же модели. Пример - некоторые значения ТЭП, которые являются расчетными параметрами объектов модели.
Надо ли упоминать, что подобная структура проектной документации решает несколько задач:
1.Сохраняется структура и нормативное оформление ПД согласно действующих нормативов. Т.е. решаются проблемы перехода к новой структуре ПД. При необходимости все листы ГЧ и ТЧ "выгружаются" в стандартный ПДФ формат.
2.Однозначность применения модели и ее верификация с ПД.
3. Возможность применения системы интерактивных замечаний для эксперта и инженера проектировщика (замечания ссылаются на точки обзора, ГЧ и ТЧ, интерактивные ссылки на документацию Информационной Модели (ТУ, изыскания, например)
4. Интерактивность для анализа экспертом документации - на графической части можно "вызвать" атрибуты элемента, перейти в точку обзора. В смете - отобразить элемент, его атрибуты, выборку и т.д.
5. Снижение объема повторного внесения информации инженером проектировщиком, а в дальнейшем всеми участниками строительного процесса.
Данная статья призвана сформировать менение сообщества о цифровой трансформации в срезе взаимодействия инженера-проектировщика и эксперта, - специалистов которые и закладывают в проект выполнение требований 384-ФЗ.
Хитров Константин. Санкт Петербург. 04.2024 г.