Общий знаменатель. IFC - это намного больше, чем простой формат файла
Интероперабельность имеет решающее значение для успеха BIM. Разработка открытых стандартов данных и «незарегистрированного» доступа к данным BIM является внеочередным приоритетом для отрасли, если мы хотим избежать недостатков и повторения нерешенных проблем повторного ввода данных. Интероперабельность вместе с IFC позволит повторно использовать проектные данные, которые уже разработаны и, таким образом, обеспечить согласованность между каждой из моделей для различных представлений одного и того же здания. Последовательные, точные и доступные данные для всей проектной группы внесут значительный вклад в смягчение последствий задержек и дополнительных расходов, по словам.
Разработка такой модели данных здания как IFC, является относительно новым предприятием. Первым приложением, задуманным с этой концепцией - от венгерской компании Graphisoft - был ArchiCAD. Revit является самым последним приложением, и Autodesk приобрел компанию, ответственную за его разработку, Revit Technology Corporation, в 2002 году.
Есть и другие приложения, такие как Bentley Architecture и Autodesk Architectural Desktop, которые разработали свои модели данных здания на основе своих оригинальных платформ в CAD: MicroStation и Auto CAD соответственно.
Все эти приложения имеют свои внутренние структуры данных в «формате заказчика». Это означает, что они не могут обмениваться информацией друг с другом, если для того нет переводчика.
IFC был разработан для того чтобы создать большую группу непротиворечивых данных, способных представлять собой модель данных здания, позволяя, тем самым, обмен информацией между различными производителями программного обеспечения в отрасли архитектурного и технического проектирования и строительства. IFC проявляется в этом контексте в качестве модели данных перевода, в формате, который «никому не принадлежит», доступном для определения объектов в сфере архитектурного и технического проектирования и строительства. Тем не менее, это не стандартизирует структуры данных в программных приложениях, и ограничивается только стандартизациями совместно используемой информации.
buildingSMART определяет IFC как схему данных, которая позволяет хранение данных и обмен информацией между различными приложениями BIM.
Схема IFC является расширяемой и располагает информацией, охватывающей множество дисциплин, которые вносят вклад в здание в течение его жизненного цикла с момента разработки концепции, проектирования, строительства, до реконструкции или сноса.
IFC зарегистрирован Международный организацией по стандартизации (ИСО) как ISO-PAS-16739 (2005) и принят в качестве официальной нормы.
Каждая реализация обмена в IFC должна следовать так называемым «требованиям к обмену». Такие требования задают информацию, которая должна быть представлена в обмене данными на определенном этапе проектирования, прогнозируя неопределенность.
Посредством IFC также возможно создание «просмотров информации» или подгрупп данных, используя только необходимые данные для определенной сферы, с помощью процесса «Представления модели» - ModelView.
IFC – это схема спецификаций, которая обеспечивает способы определения и понимания информации, отношений и конкретных свойств объектов здания, а также то, что они находятся в модели BIM.
IFC, с технической точки зрения, определен с помощью спецификации нормы ISO 10303-11 для моделирования и обмена данными, также именуемой Стандартом для обмена данными по изделию STEP. ISO начала разработку спецификации (формата данных) STEP в 1984 г. с целью определения стандартов для общего представления и обмена информацией, а также стандарт STEP используется во многих сферах, таких как машиностроение и проектирование. Специалисты, которые первоначально были вовлечены в разработку стандарта STEP, создали МАИ (Международный альянс по интероперабельности) для разработки конкретных стандартов отрасли архитектурного и технического проектирования и строительства.
IFC использует ресурсы на основе стандарта STEP и такой же язык моделирования, который называется EXPRESS.
Стандарт STEP - это диапазон спецификаций, обладающий простым текстовым языком по спецификации схемы данных STEP/EXPRESS, ISO 10303-11 (2004), на котором также задан язык IFC; преобразование ISO 10303-21 (2002) для текстовых файлов, который представляет модели в соответствии со схемой данных; преобразование StepXML, ISO 10303-28 (2007) для файлов в формате XML (расширяемого языка разметки); преобразование для интерфейса прикладного программирования (API), ISO 10303 22 (1998) для получения доступа к моделям по программированию, известное как стандартный интерфейс доступа к данным (SDAI).
Из всех технологий преобразования ISO 10303 21 (2002) является одной из наиболее значимых в условиях интероперабельности, которая эффективно определяет формат файла IFC. Текущая разработка модели IFC находится в ведении buildingSMART.
IFC разрабатывается с 1997 года, когда еще была выпущена версия 1.0, и в наши дни после последовательных и систематических обновлений IFC был выпущен под версией 4×2 Addendum 2 в начале 2015 года. Версии проходят через модификации и разработки для того, чтобы лучше представить сущности и отношения в здании и в его жизненном цикле.
Поскольку это нейтральный и открытый формат данных, компании-разработчики программного обеспечения могут разрабатывать способы экспортирования данных IFC. Для того чтобы это осуществить, приложение должно быть «IFC-совместимым», процесс сертификации должен производиться путем создания технологии SMART. В наши дни существуют около 204 программ, сертифицированных в качестве «IFC-совместимых».
Обзор архитектуры IFC
Для того чтобы понять суть IFC в целом используется концептуальная схема Рисунка 1. Для упрощенного описания данной структуры пересматривались и резюмировались концепции в работах Истмана и др. (2008 г.), Хемлани (2004 г.), а также информация справочного сайта buildinSMART по IFC (2012b).
Рисунок 1: Общая схема IFC версии 2х3
Источник: Взято из buildingSMART
В данной структуре представлены четыре слоя, которые будут описаны последовательно сверху вниз:
Слой ресурсов > Основной слой > Слой совместимости: Общие элементы > Слой доменов
Слой ресурсов
Данный слой является основой, состоящей из сущностей, которые, как правило, используются в объектах отрасли архитектурного и технического проектирования и строительства, таких как геометрия, топология, материалы, системы измерений, ответственные посредники, представление, расходы, и т.д.
Основной слой
Все сущности данного слоя исходят из корневого каталога IFC и содержат в себе абстрактные сущности, на которые ссылаются более высокие слои в иерархии. Основной слой подразделяется на четыре дополнительных подслоя: Контроль, Продукт, Процесс и Основа.
Подслой Основа представляет собой базовую структуру, которая является отношением и общими основными понятиями для всех дополнительных специализаций в конкретных моделях, в которых основные понятия определяются как группа, процесс, продукт и отношения.
Дополнительная схема продукта определяет абстрактные строительные компоненты, такие как пространственные, локальные, строительные, элементные. Дополнительная схема процесса получает представление о преобразовании процессов в логической последовательности планирования работы и программирования, а также необходимых задач для своих выводов. Дополнительная схема контроля работает с понятиями, которые относятся к контролю процесса.
Общие элементы или слой совместимости
В этом слое находятся категории сущностей, которые представляют собой физические элементы здания.
Он используется для обмена специальностей и приложений обслуживания, и располагает физическими элементами здания. Он имеет определения сущностей, таких как балки, колонны, стены, двери и прочие физически элементы здания, так же как и свойства по управлению потоком, акустические свойства наряду с некоторыми другими.
Слой доменов
Это наивысший слой, который имеет дело с сущностями конкретных дисциплин, таких как Архитектура, Структура, Оборудование наряду с некоторыми другими.
Как определяются сущности IFC?
Для демонстрации этого понятия, приведем пример. Будут использованы две основные сущности «стена» и «пространство», и появится возможность увидеть, как каждая из них представлена по отдельности, и как представлено отношение между ними, как показано на Рисунке 2.
На Рисунке 2 прямоугольники представляют собой определения сущностей, показывающих некоторые из своих атрибутов: небольшие кружки представляют собой примеры сущностей «стены» и «пространства», а также ромбы представляют собой отношения между сущностями.
Рисунок 2: Сущность «стена» и сущность «пространство» в модели IFC и их отношения
Иерархия сущностей определяет сущность «стена» и прочие физические сущности, такие как плиты, балки, колонны.
Практически это означает, что сущность «стена» (ifcWall) задается как подтип сущности «элементы здания» (ifcBuildingElement), который является подтипом сущности «элемент» (ifcElement) и так далее до сущности «корневой каталог» (ifcRoot).
Атрибуты связаны с каждым типом сущности, и сущность «стена» наследует атрибуты всех сущностей выше, или «родительских сущностей», известных как «супертипы».
В этом случае все сущности на превосходящем уровне являются абстрактными; это означает, что это невозможно для создания примера сущности такого типа. Вот почему такие сущности находятся на Основном слое. Однако сущность «стена» не является абстрактной, что означает, что на нее нельзя сослаться для создания объектов «стены», которые существуют в модели здания. По большей части атрибуты стены, такие как ее тип, форма, локализация, количество, соединительные детали, проемы, и т.д. первоначально определяются их «супертипами».
Сущность «пространство» (ifcSpace) определяется как подтип «пространственный конструктивный элемент» ifcSpatialStructureElement), который является подтипом сущности «продукт» (ifcProduct), который также существует в иерархии сущности «стена».
В случае с сущностью «пространство», все сущности ее супертипа являются абстрактными, и сущность «пространство» наследует все свойства супертипов. Однако так же как и сущность «стена», сущность «пространство» не является абстрактной, и на нее можно сослаться для создания различных пространств здания.
Различные типы отношений могут быть связаны с сущностями, используемыми в примере. Отношение «агрегация» применимо для примеров сущности «пространство» для того, чтобы сгруппировать их в панели здания, а отношение «инкапсуляция» применимо для сущности «мебель» для того, чтобы расположить ее в определенном пространстве.
Если сущность «стена» должна быть связана с сущностью «пространство», будет применяться отношение «инкапсуляция» (ifcRelContainedSpatialStructure).
Как показано на Рисунке 2, отношение происходит на уровнях ifcElement и ifcSpatialStructureElement, это означает, что любой другой элемент - стена, балка, колонна, дверь и т.д. - могут быть связаны с пространственной структурой - участком, зданием, панелью, пространством.
Поскольку формат IFC позволяет создавать все эти типы отношений, ответственность за гарантию того, что такие отношения созданы надлежащим образом, несет автор приложения, которому придется экспортировать модель в формат ifc.
Так как формат IFC весьма гибок и не задает форму ассоциации, стена должна быть связана с пространством, но также может быть связана с панелью.
В то же самое время, приложение, которому необходимо найти стену, связанную с пространством, возможно, не найдет ее, если такая ассоциация не создана явным образом. Таким образом, способ, которым создается файл IFC для экспортирования посредством приложения, является очень важным, и это является решающим фактором успеха интероперабельности среди приложений, использующих IFC.
Сложность языка IFC
Язык IFC весьма обширен и сложен. Текущая версия 2×4 RC4, buildingSMART (2012d) включает в себя:
- 126 определяемых типов,
- 206 перечисляемых типов,
- 59 типов по выбору,
- 764 определения сущностей,
- 43 функции,
- 408 групп свойств,
- 91 группу величин
- 1691 индивидуальное свойство.
Сложность языка усугубляется возможностью существующих альтернативных форм моделирования для одного и того же объекта: например, структурный блок может быть смоделирован как с помощью представления, ограниченного четырьмя планами, так и посредством сжатия поверхности и вектора. Каждый из этих объектов имеет различные семантические значения, и, хотя они могут иметь такой же вид в объемном изображении, они будут рассматриваться по-разному в структурном методе анализа.
В тех случаях, в которых ifc не имеет конкретного объекта, язык содержит в себе механизм моделирования, называемый IfcProxy, который работает в качестве механизма для его расширения.
Если не принимать во внимание сложность языка, модели IFC, как правило, имеют большие размеры файлов. Например, здание с 19-ю панелями, полная модель которого составляет около 360 Mб.