Industry Foundation Classes ( IFC ) — это схема обмена данными САПР, предназначенная для описания данных архитектурной, строительной и производственной отраслей.
Это платформенно-нейтральная, открытая спецификация схемы данных, которая не контролируется одним поставщиком или группой поставщиков. Это объектно-ориентированная схема данных с моделью данных, разработанная buildingSMART (ранее Международный альянс по совместимости, IAI) для облегчения взаимодействия в архитектурной , инженерной и строительной (AEC) отрасли, и является широко используемым форматом совместной работы в проектах на основе информационного моделирования зданий (BIM). Спецификация модели IFC открыта и доступна. [1] Она зарегистрирована ISO и является официальным международным стандартом ISO 16739-1:2024.
Из-за своей ориентации на совместимость датское правительство в 2010 году сделало использование формата(ов) IFC обязательным для государственных строительных проектов. [2] В 2017 году финская государственная компания по управлению объектами Senate Properties начала требовать использования совместимого с IFC программного обеспечения и BIM во всех своих проектах. [3] Кроме того, норвежское правительство, организации-клиенты здравоохранения и обороны требуют использования IFC BIM во всех проектах, а многие муниципалитеты, частные клиенты, подрядчики и проектировщики интегрировали IFC BIM в свой бизнес. [ необходима цитата ] . Популярность схемы данных IFC в строительстве продолжает расти, в первую очередь для целей обмена геометрией.
Инициатива IFC началась в 1994 году, когда Autodesk сформировала отраслевой консорциум для консультирования компании по разработке набора классов C++, которые могли бы поддерживать разработку интегрированных приложений. К консорциуму присоединились двенадцать американских компаний. В число этих компаний вошли AT&T, HOK Architects, Honeywell, Carrier, Tishman и Butler Manufacturing. [4] Первоначально названный Industry Alliance for Interoperability, Альянс открыл членство для всех заинтересованных сторон в сентябре 1995 года и изменил свое название в 1997 году на International Alliance for Interoperability. Новый Альянс был преобразован в некоммерческую отраслевую организацию с целью публикации Industry Foundation Class (IFC) в качестве нейтральной модели продукта AEC, отвечающей жизненному циклу здания AEC. Дальнейшее изменение названия произошло в 2005 году, и теперь спецификация IFC разрабатывается и поддерживается buildingSMART .
Доступны следующие версии спецификации IFC [5]
IFC определяет несколько форматов файлов, которые могут использоваться, поддерживая различные кодировки одних и тех же базовых данных. [7]
IFC-SPF находится в формате ASCII , который, хотя и понятен человеку, страдает от распространенных проблем с файлами ASCII, а именно: размеры файлов раздуты, файлы должны читаться последовательно от начала до конца, извлечение из середины файла невозможно, файлы медленно анализируются, а определения не являются иерархическими. [8] Помимо ifcXML и ifcZIP, современные форматы данных включают RDF/XML или Turtle (использующий онтологию ifcOWL), ifcJSON ( JavaScript Object Notation , широко доступен) и ifcHDF5 ( Hierarchical Data Format v5, двоичный). [8] В 2020 году у buildingSmart было два проекта JSON в стадии реализации: ifcJSON v4 (прямое отображение из основанного на EXPRESS IFC v4) и ifcJSON v5, а также исследовательский проект, экспериментирующий с преобразованием IFC в двоичный формат. [8]
IFC определяет модель сущности-связи на основе EXPRESS , состоящую из нескольких сотен сущностей, организованных в объектно-ориентированную иерархию наследования. Примерами сущностей являются элементы здания, такие как IfcWall, геометрия, такая как IfcExtrudedAreaSolid, и базовые конструкции, такие как IfcCartesianPoint. [9]
На самом абстрактном уровне IFC делит все сущности на корневые и некорневые. Корневые сущности происходят от IfcRoot и имеют концепцию идентичности (имея GUID ), а также атрибуты для имени, описания и контроля версий. Некорневые сущности не имеют идентичности, а экземпляры существуют только в том случае, если на них ссылаются из корневого экземпляра напрямую или косвенно. IfcRoot подразделяется на три абстрактных понятия: определения объектов, отношения и наборы свойств:
IfcObjectDefinition делится на вхождения объектов и типы объектов. IfcObject фиксирует вхождения объектов, такие как установка продукта, имеющая серийный номер и физическое размещение. IfcTypeObject фиксирует определения типов (или шаблоны), такие как тип продукта, имеющий определенный номер модели и общую форму. Вхождения и типы далее подразделяются на шесть основных концепций: субъекты («кто»), элементы управления («почему»), группы («что»), продукты («где»), процессы («когда») и ресурсы («как»).
IfcRelationship фиксирует отношения между объектами. Существует пять основных типов отношений: композиция, назначение, связность, ассоциация и определение.
IfcPropertyDefinition захватывает динамически расширяемые наборы свойств. Набор свойств содержит одно или несколько свойств, которые могут быть одним значением (например, строкой, числом, единицей измерения), ограниченным значением (имеющим минимум и максимум), перечислением, списком значений, таблицей значений или структурой данных. В то время как IFC определяет несколько сотен наборов свойств для определенных типов, пользовательские наборы свойств могут определяться поставщиками приложений или конечными пользователями.
IfcProduct является базовым классом для всех физических объектов и подразделяется на пространственные элементы, физические элементы, элементы структурного анализа и другие концепции. Продукты могут иметь связанные материалы, представления формы и размещение в пространстве. Пространственные элементы включают IfcSite, IfcBuilding, IfcBuildingStorey и IfcSpace. Физические элементы здания включают IfcWall, IfcBeam, IfcDoor, IfcWindow, IfcStair и т. д. Элементы распределения ( HVAC , electrical , plumbing ) имеют концепцию портов, где элементы могут иметь определенные соединения для различных служб и соединяться вместе с помощью кабелей, труб или воздуховодов для формирования системы. Различные отношения связности используются для элементов здания, таких как стены с проемами, заполненными дверями или окнами.
Материалы могут быть определены для изделий в целом или в виде слоев, профилей или компонентов для определенных частей.
Представления могут быть определены для явной 3D-формы и, опционально, как параметрические ограничения. Каждое представление идентифицируется IfcShapeRepresentation с известным именем.
Размещение может указывать на положение, вертикальный угол и горизонтальный угол.
Для целей расчета могут быть определены такие величины, как общая площадь, общий объем, общий вес, чистый вес и т. д. IFC определяет различные величины, специфичные для каждого типа элемента, а также метод расчета в соответствии с геометрией и отношениями.
IfcProcess — базовый класс для процессов, подразделяемый на задачи, события и процедуры. Процессы могут иметь длительность и быть запланированы на выполнение в определенные периоды времени. Процессы могут быть упорядочены таким образом, что последующая задача может начаться после завершения предшествующей задачи, следуя методу критического пути . Процессы могут быть вложены в подпроцессы для сводного свертывания. Процессы могут быть назначены продуктам, указывающим на результат, произведенный выполненной работой.
IfcResource — базовый класс для ресурсов, подразделяющийся на материалы, рабочую силу, оборудование, субподряды, бригады и т. д. Ресурсы могут иметь различную стоимость и календари доступности. Ресурсы могут быть вложены в подресурсы для детального распределения. Ресурсы могут быть назначены процессам, указывающим задачи, выполняемые от имени ресурса.
IfcProject инкапсулирует общий проект и указывает имя проекта, описание, единицы измерения по умолчанию, валюту, систему координат и другую контекстную информацию. Действительный файл IFC всегда должен включать ровно один экземпляр IfcProject, с которым все остальные объекты связаны напрямую или косвенно. Проект может включать несколько зданий, нескольких участников и/или несколько фаз в зависимости от конкретного использования.
В дополнение к информации, специфичной для проекта, IfcProject может также ссылаться на внешние проекты, из которых могут быть импортированы общие определения, такие как типы продуктов. Каждый внешний проект инкапсулируется с использованием IfcProjectLibrary [IFC2x4] вместе с IfcRelAssociatesLibrary и IfcLibraryInformation для идентификации конкретной ревизии импортированной библиотеки проекта.
Проекты поддерживают контроль ревизий , где любая сущность на основе IfcRoot имеет уникальный идентификатор и может быть помечена как добавленная, измененная, удаленная или не имеющая изменений. Такая возможность позволяет детерминированно объединять несколько файлов IFC, обеспечивая целостность данных без вмешательства человека.