Среда общих данных как основа BIM/ТИМ

Аббревиатура BIM (в русскоязычном варианте ТИМ, т.е. технологии информационного моделирования) чаще всего расшифровывается как Building information modeling. Но есть и другое прочтение: Building information management. Различия в последнем слове определяют разные подходы. В первом мы только создаем информацию, а во втором мы ей управляем. К сожалению, внедрение BIM в строительную отрасль для многих ее участников происходило и до сих пор уверенно происходит только на уровне применения специального программного обеспечения для создания информационных моделей. Методология обмена информацией и совместного управления данными зачастую упускается из виду. 

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

Один из способов организации единого пространства для хранения, передачи и согласования информационных контейнеров – это создание среды общих данных (далее – СОД) и описание методик ее работы. 

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

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

 

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

 

Программное решение СОД должны поддерживать несколько основных функций:

Когда мы говорим о хранении, чаще всего имеем в виду физический уровень. Для многих компаний при выборе такого рода систем достаточно важно, где будут находиться аппаратные средства, на которых развернута СОД. На рынке представлены как on-cloud, так и on-premise решения. Второй важный момент – резервирование аппаратных средств. В облачных решениях резервирование чаще всего обеспечивается поставщиком или разработчиком системы, а в локальных ложится на плечи внутренней ИT-службы.

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

Особо выделяются СОД, которые позволяют взаимодействовать с BIM-данными, причем не только хранить, но также просматривать и анализировать компоненты информационных моделей. Загрузка информационных контейнеров с BIM-данными в СОД осуществляется как через форматы разработки информационных моделей, так и через промежуточные форматы (рис. 3). В качестве общепринятого интероперабельного формата чаще всего используются файлы спецификации IFC.

 

Версионность информационных контейнеров зачастую поддерживается по умолчанию. Однако можно выделить несколько подходов. Самый простой и распространенный – указание номера версии в формате 1, 2,… n в качестве дополнительного атрибута контейнера. Менее распространено, но достаточно подробно описано в международном документе ISO 19650 масочное формирование версий, при котором указываются текущая зона хранения и статус контейнера (рис. 4). Рассмотрим пример со следующими зонами:

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

Хранения информационных контейнеров и поддержки их версионности недостаточно. Еще одна необходимая функция – доступ для просмотра информационных контейнеров или взаимодействия сними. Стандартные форматы, предназначенные для просмотра, – векторные PDF, XPS или растровые JPEG и PNG. Некоторые документы (тексты, таблицы и т.п.) зачастую не подлежат редактированию в системе СОД, так как это выходит за рамки основных функций системы и требует специальных редакторов. Многие системы поддерживают работу с информационными контейнерами, содержащими BIM-данные, на уровне сведения их компонентов и предоставляют отдельный инструмент для их просмотра. Некоторые системы поддерживают связку информационных контейнеров в СОД с различными графиками проектирования или производства работ, что позволяет более гибко использовать эти системы и более тесно интегрировать данные между собой. 

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

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

 

Некоторые СОД при согласовании контейнеров поддерживают работу с электронной цифровой подписью (ЭЦП), также нанесение на графические документы штампов или QR-кодов. Это позволяет даже при переводе информации в «бумажный» вариант сохранять связку с СОД.

Поскольку системы СОД по сути своей – базы данных, большая часть из них имеет возможности анализа информационных контейнеров, процессов или замечаний. Ряд разработчиков СОД предоставляют API для пользовательского анализа данных или интеграций. Другие же имеют собственные модули для демонстрации отчетов и графиков. Раньше я бы сказал, что аналитика – это дополнительная функция, но она уже давно из тренда превратилась в полноценный инструмент по работе с данными. А данных у вас может быть очень много. В проектах зачастую участвуют десятки компаний, сотни специалистов, и все они выпускают тысячи страниц с комментариями, изменениями и пр. Если все эти тысячи помножить на число проектов в портфеле, то цифра получится внушительная.

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

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

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!