Информационная модель СОД: единый файл или информационный контейнер?

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

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

Если хранить разные версии с шагами развития информационной модели, то все изменения в итоге накапливаются в сотни гигабайт информации. Это дорого, занимает много времени и требует много места на обработку такого объема данных.

И последнее: работая в логике одного файла, мы попадаем в самое главное ограничение — открыть для просмотра такой проект можно будет только на серьезном оборудовании, потребуется производительная графическая карта, мощные процессор и оперативная память, чтобы эти гигабайты информации загрузить и обрабатывать. У большинства потребителей такой модели этого оборудования нет и не появится. Тут получается ситуация, когда файл есть, но нет подходящих устройств для его просмотра — всё либо будет очень сильно «тормозить», либо не откроется вовсе.

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

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

В «ИНГИПРО» мы используем именно такую технологию. Перед нами была задача повысить вариативность работы — сделать независимые от используемых САПР изменения, чтобы можно было быстро и дешево их «протаскивать» в информационную модель, размещенную в СОД. Поскольку инженеров и специалистов, работающих с моделью, много, и у каждого свои задачи, не всегда требующие загрузки всей модели целиком, нужно позволить им выбирать только частные сводные модели, которые полезны для конкретной работы. Благодаря такому подходу, в подавляющем большинстве случаев всё будет работать плавно даже на дешевых офисных компьютерах. На практике это единственный правильный путь, которым можно идти.

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

По поводу редактирования IFC. К IFC необходимо относиться как к «твердому» срезу структурированной информации, как к результату труда. К примеру, попытка изменять чертежи в PDF, а не в исходнике, ведет к тому, что в исходниках будет содержаться одна информация, а в PDF — другая. При этом непонятно, где актуальная информация. Тем самым порождаются новые коллизии. В случае внесения изменений в исходник очень вероятно забыть внести согласованные изменения сделанные в PDF, что порождает новые коллизии при производстве новой версии PDF из новой версии исходного нативного файла. Мы придерживаемся принципа, что точка для внесения изменений должна быть одна — это нативный файл и специализированное для работы с ним ПО.

С IFC то же самое. Предположим, мы в какую-то из IFC-версий документа внесли изменения. А потом, при появлении новых замечаний, появилась необходимость редактирования исходной модели внутри САПР. В итоге генерируется новая версия модели с той же изначальной ошибкой, потому что изменения были внесены в файл с результатом, а не в исходник. Мы снова попадаем в издержки выявления этой ошибки, её исправления, внесения согласованных изменений и т.д.

Технически IFC можно менять, как и PDF-чертежи, но это неправильно с точки зрения технологии. Необходимо иметь инструмент поставки замечаний автору, чтобы он внес изменения в модель с помощью САПР, чтобы и в IFC было так, как надо. Только благодаря правильно выстроенному процессу можно получить качественную модель. Поэтому в «ИНГИПРО» нет инструментов редактирования, мы принципиально придерживаемся описанной технологии.

На практике не осуществима идея «растягивания» одной единой информационной модели на весь жизненный цикл ОКС.

Идея кажется хорошей, а на деле выходит во много раз дороже, чем делать несколько целеориентированных моделей. Рабочая документация подготавливается на основе проектной, но всё равно практически с самого начала. Нельзя взять те же самые файлы и их детализировать. Переиспользование этой информации в создании рабочей документации возможно в ограниченном объеме, но, по большому счету, создается новая система описаний, и то же самое со строительной информационной моделью. Нюанс в том, что строителю важно иметь информационную модель для декомпозиции по объектам, учитывая их способ производства, или план производства. Грубо говоря, надо иметь модель плана работ и производить декомпозицию с учетом тех операций, которые там содержатся. Границы элементов в модели и границы работ должны совпадать. Без участия конкретного строительного подрядчика, у которого этот план есть, полезную информационную модель сделать невозможно. Проектировщики обычно делают укрупненные проекты, не залезая в детализацию, даже проект организации строительства — это некая модель строительства, для ответа на общие вопросы, а в реальности будет по-другому.

Зачем нужна модель проектировщику? На сегодняшний день сложилась пагубная практика — у нас сначала объект «запроектировали» по традиционной технологии, а потом «подняли» 3D-модель. Это дополнительная работа со своими издержками, непонятно, зачем и кому она нужна.

Если же сразу начать проектирование в «логике» 3D-моделирования, то из неё автоматизированным образом производятся различные описания объекта. Это в итоге повысит качество междисциплинарного взаимодействия между проектировщиками и выступит в качестве механизма более дешёвого удержания коллективного понимания и знаний о том, над чем же эти проектировщики работают в данный момент.

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

По ходу проектных работ над информационной моделью постоянно требуется увязывать взаимные решения. Ключевая идея BIM/ТИМ — выявлять коллизии не в материи на строительной площадке, а в виртуальном пространстве через коллективно воображаемую сборку объекта в 3D-модели.

В системе «ИНГИПРО» мы работаем не совсем с файлами, а с информационным контейнером, который совмещает в себе PDF-файл как результат, и исходник, из которого он получен, модель формата IFC и т.д. Это срез информации, собранный в целое из двух и более представлений в единый момент времени, и, соответственно, это уже не файл, а версия информационного объекта со своим жизненным циклом.

Движение такой информации по жизненному циклу происходит через статусы. Они отражают контрольные состояния этой информации в том производственном процессе, который принят в проекте. Это очень важная вещь, потому что у файлов как сущностей, понятия жизненного цикла нет. Попадая в «ИНГИПРО», информация уже живет по выстроенным процессам.

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

При создании информационной 3D-модели возникает задача насыщения её объектов атрибутивной информацией. Часть этой информации удобно заполнять в САПР, но есть достаточно большой объем информации, для создания и управления которой удобно использовать табличную форму в Excel. Например, объемы или площади элементов из 3D модели в САПР не всегда совпадают с объемами, которые используются для сметных расчетов. Также это могут быть какие-нибудь классификаторы элементов, которые подчиняются некоторой логике, которую удобно реализовать с помощью таблиц. Из-за большого количества вычисляемых атрибутов становится необходимым эти сущности явно вводить в информационную модель, а так как процесс проектирования включает в себя постоянный процесс внесения изменений, то потребуется их постоянная доводка до целевого состояния.

В СОД «ИНГИПРО» планируется поддержать возможность прикладывать Excel-файл с атрибутами к IFC. При открытии 3D-модели в «ИНГИПРО» эти атрибуты будут агрегированно с остальными свойствами выводиться на экран.

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