Продолжение серии интервью с создателями «ИНГИПРО». В этот раз беседуем с генеральным директором компании о некоторых аспектах работы в СОД, о роли в этих процессах системы «ИНГИПРО» и о принципах ее развития.
Павел Владимирович Черенков, генеральный директор «ИНГИПРО» имеет богатый опыт участия в сложных строительных проектах мирового уровня. Принимал участие в проектах: мост на остров Русский, Керченский мост в Крым, олимпийские объекты. С 2013 года занимается развитием отечественных систем для технологии информационного моделирования в строительстве.
— Павел, хотелось бы обсудить тему, касающуюся работы внутри СОД с файлами нативных форматов. Многие хотят получить информационную модель в формате одного файла, в которой будут все элементы модели. Как вы оцените такой подход к работе, какие в нем плюсы и минусы?
Если говорить коротко, то это ложный путь.
Во-первых, в комплексном проекте, как правило, используется несколько САПР-решений. Из всех них нативно произвести один общий файл невозможно. Поэтому мы попадаем в ситуацию, когда требуется трудоемкая работа по сведению, как бы “склеиванию” разрозненных частей в смысловое целое, размещенное в одном файле.
Во-вторых, если нам удалось собрать такой файл, объем его может составлять десятки гигабайт. Вносить изменения в модель придется, работая с таким большим объемом. К примеру, изменилась одна цифра, но изменения будут вноситься во все десятки гигабайт.
Если хранить разные версии с шагами развития информационной модели, то все изменения, в итоге, накапливаются в сотни гигабайт информации. Это дорого, занимает много времени и требует много места на обработку такого объема данных.
И последнее: работая в логике одного файла, мы попадаем в самое главное ограничение — открыть для просмотра такой проект можно будет только на серьезном оборудовании, потребуется производительная графическая карта, мощные процессор и оперативная память, чтобы эти гигабайты информации загрузить и обрабатывать. У большинства потребителей такой модели этого оборудования нет и не появится. Тут получается ситуация, когда файл есть, но нет подходящих устройств для его просмотра — всё либо будет очень сильно “тормозить”, либо не откроется вовсе.
Это всё порождает сложность, огромные ненужные издержки, которые не приближают к результату, а, наоборот, отдаляют от него, понижая при этом производительность труда и выгоду от использования информационной модели.
— По вашему мнению, как лучше решить эту задачу работы со сводными моделями?
Из нашего опыта, самое лучшее решение – “дробить” модель на множество небольших файлов и иметь ПО, которое позволяет эти файлы динамически “склеивать”.
В «ИНГИПРО» мы именно по такой технологии пошли. Перед нами была задача повысить вариативность работы — сделать независимые от используемых САПР изменения, чтобы можно было быстро и дешево их “протаскивать” в информационную модель, размещенную в СОД. Поскольку инженеров и специалистов, работающих с моделью, много, и у каждого свои задачи, не всегда требующие загрузки всей модели целиком, нужно позволить им выбирать только частные сводные модели, которые полезны для конкретной работы. Благодаря такому подходу, в подавляющем большинстве случаев, всё будет работать плавно даже на дешевых офисных компьютерах. На практике, это единственный правильный путь, которым можно идти.
Даже если обратиться к нормативной документации, мы увидим, что, информационной моделью называют совокупность структурированной информации, то есть не один файл, а множество.
— А что касается популярного запроса на редактирование IFC-моделей?
По поводу редактирования IFC. К IFC необходимо относиться как к “твердому” срезу структурированной информации, как к результату труда. К примеру, попытка изменять чертежи в PDF, а не в исходнике, ведет к тому, что в исходниках будет содержаться одна информация, а в PDF - другая. При этом непонятно где актуальная информация. Тем самым порождаются новые коллизии. В случае внесения изменений в исходник очень вероятно забыть внести согласованные изменения сделанные в PDF, что порождает новые коллизии при производстве новой версии PDF из новой версии исходного нативного файла. Мы придерживаемся принципа, что точка для внесения изменений должна быть одна — это нативный файл и специализированное для работы с ним ПО.
С IFC то же самое. Предположим, мы в какую-то из IFC-версий документа внесли изменения. А потом, при появлении новых замечаний, появилась необходимость редактирования исходной модели внутри САПР. В итоге, генерируется новая версия модели с той же изначальной ошибкой, потому что изменения были внесены в файл с результатом, а не в исходник. Мы снова попадаем в издержки выявления этой ошибки, её исправления, внесения согласованных изменений и т.д.
Технически IFC можно менять, как и PDF-чертежи, но это неправильно с точки зрения технологии. Необходимо иметь инструмент поставки замечаний автору, чтобы он внес изменения в модель с помощью САПР, чтобы и в IFC было так как надо. Только благодаря правильно выстроенному процессу можно получить качественную модель. Поэтому в «ИНГИПРО» нет инструментов редактирования, мы принципиально придерживаемся описанной технологии.
— На конференциях много говорят о моделировании, охватывающем все этапы проекта. Можете ли вы поделиться своим мнением о практической реализуемости этой идеи?
На практике не осуществима идея “растягивания” одной единой информационной модели на весь жизненный цикл ОКС.
Идея кажется хорошей, а на деле выходит во много раз дороже, чем делать несколько целеориентированных моделей. Рабочая документация подготавливается на основе проектной, но всё равно практически с самого начала. Нельзя взять те же самые файлы и их детализировать. Переиспользование этой информации в создании рабочей документации возможно в ограниченном объеме, но, по большому счету, создается новая система описаний и то же самое со строительной информационной моделью. Нюанс в том, что строителю важно иметь информационную модель для декомпозиции по объектам, учитывая их способ производства, или план производства. Грубо говоря, надо иметь модель плана работ и производить декомпозицию с учетом тех операций, которые там содержатся. Границы элементов в модели и границы работ должны совпадать. Без участия конкретного строительного подрядчика, у которого этот план есть, полезную информационную модель сделать невозможно. Проектировщики обычно делают укрупненные проекты, не залезая в детализацию, даже проект организации строительства, это некая модель строительства, для ответа на общие вопросы, а в реальности будет по-другому.
— Как вы считаете, какую ценность может предоставить общая информационная модель на этапе проектирования?
Зачем нужна модель проектировщику? На сегодняшний день сложилась пагубная практика — у нас сначала объект “запроектировали” по традиционной технологии, а потом “подняли” 3D-модель. Это дополнительная работа со своими издержками, непонятно зачем и кому она нужна.
Если же сразу начать проектирование в ”логике” 3D-моделирования, то из неё автоматизированным образом производятся различные описания объекта. Это, в итоге, повысит качество междисциплинарного взаимодействия между проектировщиками и выступит в качестве механизма более дешёвого удержания коллективного понимания и знаний о том, над чем же эти проектировщики работают в данный момент.
При данном подходе разного рода коллизии можно отслеживать визуально гораздо быстрее, чем на чертежах. Конечно, не все коллизии благодаря этому получится выявить, но какие-то бросаются в глаза сразу. Когда эти все процессы настроены с самого начала с помощью среды общих данных, как некой технологии частого обмена промежуточной информацией между участниками, модель позволяет значительно сократить так называемую “работу” в корзину». Это когда работа производится несколько недель по устаревшим данным.
По ходу проектных работ над информационной моделью постоянно требуется увязывать взаимные решения. Ключевая идея BIM/ТИМ — выявлять коллизии не в материи на строительной площадке, а в виртуальном пространстве через коллективно воображаемую сборку объекта в 3D-модели.
— Вы сказали о среде общих данных и об «ИНГИПРО» как инструменте для ее организации. Можете ли вы объяснить, как это работает и какие преимущества предоставляет СОД в процессе проектирования?
В системе «ИНГИПРО» мы работаем не совсем с файлами, а с информационным контейнером, который совмещает в себе PDF-файл, как результат, и исходник, из которого он получен, модель формата IFC и т.д. Это срез информации, собранный в целое из двух и более представлений в единый момент времени и, соответственно это уже не файл, а версия информационного объекта со своим жизненным циклом.
Движение такой информации по жизненному циклу происходит через статусы. Они отражают контрольные состояния этой информации в том производственном процессе, который принят в проекте. Это очень важная вещь, потому что у файлов, как сущностей, понятия жизненного цикла нет. Попадая в «ИНГИПРО», информация уже живет по выстроенным процессам.
В этом и есть суть среды общих данных, она учитывает шаги производственного процесса над информацией и она обеспечивает правила коммуникации участников проекта на информации как на частях информационной модели.
— Расскажите немного о планах развития вашего продукта.
При создании информационной 3D-модели возникает задача насыщения её объектов атрибутивной информацией. Часть этой информации удобно заполнять в САПР, но есть достаточно большой объем информации, которую удобно создавать и управлять в табличной форме через Excel. Например, объемы или площади элементов из 3D модели в САПР не всегда совпадают с объемами, которые используются для сметных расчетов. Также, это могут быть какие-нибудь классификаторы элементов, которые подчиняются некоторой логике, которую удобно реализовать с помощью таблиц.. Из-за большого количества вычисляемых атрибутов становится необходимым эти сущности явно вводить в информационную модель, а так как процесс проектирования включает в себя постоянный процесс внесения изменений, то потребуется их постоянная доводка до целевого состояния.
В СОД «ИНГИПРО» планируется поддержать возможность прикладывать Excel-файл с атрибутами к IFC. Ри открытии 3D-модели в «ИНГИПРО», эти атрибуты будут агрегировано с остальными свойствами выводиться на экран.
В итоге будет единая большая общая модель, насыщенная всеми требуемыми атрибутами, которая состоит из связанных между собой актуальных версий файлов. И благодаря возможности делать динамическую сборку частных сводных моделей можно будет эффективно работать с информацией через браузер на обычных офисных компьютерах.
— Спасибо за интересную беседу.
Интервью провели:
Д.В. Медведев - руководитель проектов (e-mail: )
А.А. Ислам - менеджер проектов (e-mail: )
Больше интересных статей и материалов о технологиях информационного моделирования в Telegram-канале «ИНГИПРО»:
ООО«Ингипро» www.ingipro.com
Комментарии (0)