Файл ifc что это

Industry Foundation Classes. Краткое введение

Введение

В связи с политикой Партии и Правительства, происходит активное изменение законодательства в целях внедрения технологии BIM — Информационное моделирование Зданий. В продолжении линии Партии рассмотрим открытый формат представления BIM — IFC (Industry Foundation Classes).

История IFC начинается в 1995 (на самом деле — летом 1993 [1]), когда корпорация Autodesk с группой «товарищей» организовала Картельный сговор с целью разработки обменного формата для различных САПР для проектирования зданий. Через год, товарищи пришли к пониманию, что этот формат должен быть открытым и разрабатываться организацией с открытым членством, так в 1996 появилась International Alliance for Interoperability. Позже, в 2008 году, организация была переименована в buildingSMART — для большей гламурности.

Разработчики IFC не обладали богатым воображением, да и не имели возможности его применить – им были поставлены весьма скромные сроки, а задача выглядела весьма глобально. Поэтому, они взяли за основу формат STEP (Standard for the Exchange of Product model data), а точнее Application Protocol 225: Building Elements. Надо сказать, что вокруг STEP создана богатая инфраструктура в виде кучи спецификаций в статусе ИСО-стандартов. В основе этой инфраструктуры лежит язык моделирования данных EXPRESS и его графическая инкарнация EXPRESS-G, этот язык разрабатывался для удобства автогенерации кода на различных языках программирования.

Разработка IFC началась в Сентябре 1995, IFC 1.0 опубликован в Июне 1996, окончательная редакция в Январе 1997. Фактически целью первой версии IFC — была демонстрации самой возможности реализации задуманной цели, различные компании представили свои демонстрации экспорта/импорта в этот формат.

В Ноябре 1997 вышла следующая версия — 1.5, но попытка её реализация быстро выявило множество ошибок, которые потребовали разработки исправленной версии 1.5.1, которая ввелась параллельно с разработкой версией 2.0 — которая была представлена в Марте 1999.

Все эти версии сейчас признаны устаревшими.

В Ноябре 2000 вышла версия 2.1, это самая старая версия, по которой доступна документация. Позже она была опубликована как ISO/PAS 16739:2005.

Сейчас наиболее распространённая версия (которую понимает большинство программ) — IFC 2.3.

Для чтения IFC пригодится текстовый редактор с подсветкой синтаксиса, например я использовал n++ и vs code со своими корявыми настройками синтаксиса IFC.

Но ещё необходимым инструментом будет программа способная визуализировать графику в IFC. Сейчас появилось множество вьюверов для этого и даже бесплатных, лично я предпочитаю XbimXplorer от проекта xBIM. Также я использовал Revit, но надо сказать, что чистый Revit не очень дружит с IFC — он даже не способен прочитать файл, который сам создал (да, Revit от Autodesk’а не умеет работать с форматом придуманным Autodesk’ом — это визитная карточка Autodesk’а, просто они не придумали Revit, а купили его — как обычно), но у него есть не плохой плагин для этого — IFC for Revit (пока писал статью — нащёл несколько ошибок, нужно будет исправить, когда будет время. )

Надо сказать, что формат IFC настолько запутанный, что ни одна программа не обрабатывает его правильно — каждая это делает по своему. Так XbimXplorer игнорирует 2d-графику и некоторые синтаксические ошибки.

Описание

Структура файла IFC-SPF описана в ISO 10303-21 (существует ГОСТ ИСО 10303-21-2002) в нотации Вирта. Это текстовый файл, в котором используется только символы с кодами в диапазоне 32-126 (третье издание допускает использование символов с кодами 127-255, но не рекомендуется — для совместимости)
Многострочные комментарии отмечаются парами символов /* */

Для записи символов в другой кодировке предусмотрено несколько способов

Запись ISO 8859:
Директива \S\ — код символа после директивы указывает код символа в таблице ISO 8859-1
Директива \P*\ — здесь вместо * должна стоять заглавная латинская буква, она указывает номер таблицы ISO 8859 которая используется для директивы \S\, A означает ISO 8859-1, B означает ISO 8859-2 и т. д.

Запись ISO 10646:
Директива \X\ — за директивой следует двузначное шестнадцатеричное число указывающее символ в диапазоне от U+0000 до U+00FF
Директивы \X2\*\X0\ и \X4\*\X0\ — здесь вместо * идёт последовательность двузначных (X2) или четырёхзначных (X4) шестнадцатеричных чисел, которые обозначают соответствующие символы

Привет, Мир! => \X2\041F04400438043204350442\X0\, \X2\041C04380440\X0\!

Максимальная длина сырой строки — 32769 байт

Структура файла — файл начинается строкой ISO-10303-21; и заканчивается строкой END-ISO-10303-21; правда после ещё может быть секция подписи SIGNATURE_SECTION, но этот вариант я не буду рассматривать.
Между этими строками должна быть секция заголовка HEADER_SECTION, после неё могут быть секции ANCHOR_SECTION и/или REFERENCE_SECTION, а также одна или несколько DATA_SECTION (в IFC только одна)

Структура заголовочной секции HEADER_SECTION — IFC допускает лишь три элемента в этой секции: FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA

ENTITY file_description;
description : LIST [1:?] OF STRING (256) ;
implementation_level : STRING (256) ;
END_ENTITY;

Минимальный вариант:
FILE_DESCRIPTION((‘ViewDefinition [CoordinationView_V2.0]’),’2;1′);
Содержимое description очень важно для IFC – здесь перечисляются используемые дополнения ViewDefinition, содержание ExchangeRequirement и опции Option[2], но обязательным является только элемент ViewDefinition
implementation_level состоит из двух цифр, первая обозначает редакцию ISO-10303-21 (их три), вторая – режим совместимости (их два), описаны в п.4.3 ISO-10303-21. Для IFC implementation_level всегда имеет значение — 2;1

Ещё вариант:
FILE_DESCRIPTION( (‘ViewDefinition [CoordinationView_V2.0, QuantityTakeOffAddOnView]’, ‘ExchangeRequirement[Structural]’),’2;1′);

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

ENTITY file_schema;
schema_identifiers : LIST [1:?] OF UNIQUE schema_name;
END_ENTITY;

Имя схемы, в которой описано содержание секции данных (смотри столбец Идентификатор в таблице выше)

Секция данных начинается с ключевого слова DATA; и заканчивается ENDSEC;. Содержимым этой секции является последовательность сущностей следующего синтаксиса:
# = ( );
Возможные сущности и их параметры описаны в IFC-схеме.

Пустой IFC файл:
ISO-10303-21;
HEADER;
FILE_DESCRIPTION((‘ViewDefinition [CoordinationView_V2.0]’),’2;1′);
FILE_NAME(»,»,(»),(»),»,»,»);
FILE_SCHEMA((‘IFC2X3’));
ENDSEC;
DATA;
ENDSEC;
END-ISO-10303-21;

Секция данных

Корневым элементом IFC является IfcProject. Тут надо рассказать, как формируется список атрибутов, нужный для создания сущности, во-первых, сущность может иметь собственные атрибуты, а во-вторых она может унаследовать их от предка, порядок атрибутов задаётся — от предка к потомку. Для IfcProject цепочка наследования будет следующая: IfcRoot=>IfcObjectDefinition=>IfcObject=>IfcProject.

— опциональные и текстовые (IfcLabel, IfcText) — описание проекта для человека

RepresentationContexts – это список пространств/контекстов, идея была в том, что у нас может быть несколько пространств/контекстов, например: эскиз, проект и рабочая документация. И разные объекты могут иметь разное представление в разных контекстах. Например, стена в эскизе – просто линия, в проекте уже имеет толщину, а в рабочей документации – состоит из разных слоёв. Но в IFC2x3 концепция поменялась, контексты ‘Sketch’, ‘Outline’, ‘Design’, ‘Detail’ или отменили или они переехали в IfcGeometricRepresentationSubContext. А сам класс IfcRepresentationContext стал абстрактным, с единственным потомком – IfcGeometricRepresentationContext, который может быть объёмным ContextType = ‘Model’, CoordinateSpaceDimension = 3, плоским ContextType = ‘Plan’, CoordinateSpaceDimension = 2 и фиг знает каким ContextType = ‘NotDefined’.

UnitsInContext – объект IfcUnitAssignment, формирующий список элементов IfcUnit с описанием единиц измерения проекта, нужно для правильного импорта, иначе софт будет применять свои настройки по умолчанию – в Revit’е например стоят футы (он всё хранит в футах).

#2= IFCSIUNIT(*,.LENGTHUNIT. MILLI. METRE.);
#3= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#4= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#5= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#6= IFCUNITASSIGNMENT((#2,#3,#4,#5));

От корневого элемента IfcProject формируется дерево элементов, наследников типа IfcSpatialStructureElement (IfcBuilding (здание), IfcBuildingStorey (этаж), IfcSpace (пространство или помещение), IfcSite (участок)). Но эти элементы связываются не на прямую, а через специальный элемент IfcRelAggregates, отношением один-к-многим.

Эти элементы могут быть связанны только в следующем порядке: IfcSite=>IfcBuilding=>IfcBuildingStorey=>IfcSpace, а также могут быть связанны однотипные элементы, но тогда их атрибут CompositionType должен иметь разное значение и только в определённом порядке COMPLEX=>ELEMENT=>PARTIAL

Полная возможная структура проекта:
IfcSite.COMPLEX=>IfcSite.ELEMENT=>IfcSite.PARTIAL=> IfcBuilding.COMPLEX=>IfcBuilding.ELEMENT=>IfcBuilding.PARTIAL=> IfcBuildingStorey.COMPLEX=>IfcBuildingStorey.ELEMENT=>IfcBuildingStorey.PARTIAL=> IfcSpace.COMPLEX=> IfcSpace.ELEMENT=>IfcSpace.PARTIAL

ifc-файл

Хотя все элементы не обязательные, обязателен лишь порядок наследования
Предпологоается, что вы описываете Здание (Building), которое состоит из этажей (Storey) и в которых существуют помещения (Space), вам нужно показать существующий рельеф (Site) в который вы вписываете своё здание

Атрибут Representation, унаследованный от IfcProduct, указывает на объект IfcProductRepresentation, имеет двух потомков IfcProductDefinitionShape – для описания формы объекта и IfcMaterialDefinitionRepresentation – описания материала (стиля визуализации), они через атрибут Representations связывают различные представления.

IfcMaterialDefinitionRepresentation для Representations принимает только IfcStyledRepresentation — описания стиля
Атрибут RepresentedMaterial даёт текстовое описание материала объекта.
IfcProductDefinitionShape для Representations принимает только IfcShapeRepresentation или IfcTopologyRepresentation (IfcShapeModel)

IfcShapeRepresentation самый важный в IFC класс, потому что отвечает за геометрическое представление объектов. Доступные типы геометрии: Curve2D (плоские линии), GeometricSet (точки, линии, поверхности, 2d и 3d), SurfaceModel (поверхности), SolidModel (тела), дополнительные типы (BoundingBox, SectionedSpine, MappedRepresentation)

ProfileType – тип профиля enum-значение типа IfcProfileTypeEnum (Значения: CURVE,AREA). Опциональное имя профиля ProfileName, размещение Position и размер по координатам X Y – XDim, YDim.

Или более сложный IfcFacetedBrep он состоит из одной закрытой оболочки IfcClosedShell, которая в свою очередь состоит из списка граней IfcFace, которые состоят из рёбер IfcFaceBound, которые описаны петлями IfcLoop, которые уже состоят из точек IfcCartesianPoint. Граничное представление (brep) диктует массу условий на свою структуру – подробно описанные в документации и соответствующей литературе.

#57= IFCSHAPEREPRESENTATION(#7, ‘Body’, ‘Brep’, (#58));
#58= IFCFACETEDBREP(#59);
#59= IFCCLOSEDSHELL((#80, #81, #82, #83, #84, #85));

#60 = IFCCARTESIANPOINT((0.,0.,0.));
#61 = IFCCARTESIANPOINT((1.,0.,0.));
#62 = IFCCARTESIANPOINT((1.,1.,0.));
#63 = IFCCARTESIANPOINT((0.,1.,0.));
#64 = IFCCARTESIANPOINT((0.,0.,1.));
#65 = IFCCARTESIANPOINT((1.,0.,1.));
#66 = IFCCARTESIANPOINT((1.,1.,1.));
#67 = IFCCARTESIANPOINT((0.,1.,1.));

#68= IFCPOLYLOOP((#60, #61, #62, #63));
#69= IFCPOLYLOOP((#64, #65, #66, #67));
#70= IFCPOLYLOOP((#60, #61, #65, #64));
#71= IFCPOLYLOOP((#61, #62, #66, #65));
#72= IFCPOLYLOOP((#62, #63, #67, #66));
#73= IFCPOLYLOOP((#63, #60, #64, #67));

#80= IFCFACE((#74));
#81= IFCFACE((#75));
#82= IFCFACE((#76));
#83= IFCFACE((#77));
#84= IFCFACE((#78));
#85= IFCFACE((#79));

В IFC4 появился IfcAdvancedBrep, грани которого могут быть описаны NURBS-кривыми

Объекты IfcSpatialStructureElement могут иметь собственную геометрию, но вообще то здания состоят из других объектов: стен, полов, крыш, окон, дверей и т. д. В IFC все эти объекты описываются соответствующими объектами: IfcWall, IfcSlab, IfcRoof, IfcWindow, IfcDoor – все они являются потомками IfcProduct. Все эти объекты могут быть связанны с соответствующим объектом IfcSpatialStructureElement, через специальный объект IfcRelContainedInSpatialStructure

Для стен постоянной толщины принято использовать IfcWallStandardCase (в IFC4 считается устаревшим), для остальных случаев используем IfcWall. В случае IfcWallStandardCase нужно использовать SweptSolid – выдавливающий контур стены на заданную высоту

#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#10= IFCCARTESIANPOINT((0.,0.,0.));
#13= IFCLOCALPLACEMENT($,#8);
#22= IFCDIRECTION((0.,0.,1.));
#23= IFCAXIS2PLACEMENT2D(#24,#25);
#24= IFCCARTESIANPOINT((0.,0.));
#25= IFCDIRECTION((1.,0.));
#26= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs107′,$,’wall1’,$,»,#13,#27,»);
#27= IFCPRODUCTDEFINITIONSHAPE($,$,(#28));
#28= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#29));
#29= IFCEXTRUDEDAREASOLID(#30,#32,#22,1000.);
#30= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,100.,1000.);
#31= IFCCARTESIANPOINT((500.,0.,100.));
#32= IFCAXIS2PLACEMENT3D(#31,$,$);

Дверь описывается объектом IfcDoor, его можно добавить в IfcRelContainedInSpatialStructure, но этот объект не делает «вырез» в стене для себя

За «вырез» отвечает специальный объект IfcOpeningElement, который связывается с «родительским» объектом через IfcRelVoidsElement. В IfcOpeningElement можно «вставить» дверь, с помощью объекта IfcRelFillsElement. С помощью IfcOpeningElement можно делать не только сквозные отверстия, но и углубления.

Объект IfcWindow сильно похож в использовании, на IfcDoor, OverallHeight, OverallWidth — номинальные габариты, можно не указывать – тогда эти значения будут браться из геометрии

Пишем IFC

Дальше, мы должны наполнить содержанием DATA-секцию. Первым обязательным обектом должен быть IFCPROJECT (хотя он может быть и в конце файла, но он просто должен быть), также нам понадобится IFCUNITASSIGNMENT, если мы конечно хотим, что бы программы читали модель в тех еденицах измерения, которые мы задумали. Так же нам понадобится, хотя бы один IFCGEOMETRICREPRESENTATIONCONTEXT — иначе мы не сможем добавить описание геометрии.

/* Единицы измерений модели */
#2= IFCSIUNIT(*,.LENGTHUNIT. MILLI. METRE.);
#3= IFCSIUNIT(*,.AREAUNIT.,$,.SQUARE_METRE.);
#4= IFCSIUNIT(*,.VOLUMEUNIT.,$,.CUBIC_METRE.);
#5= IFCSIUNIT(*,.PLANEANGLEUNIT.,$,.RADIAN.);
#6= IFCUNITASSIGNMENT((#2,#3,#4,#5));

/* Контекст */
#7= IFCGEOMETRICREPRESENTATIONCONTEXT($,’Model’,3,0.01,#8,#9);
#8= IFCAXIS2PLACEMENT3D(#10,$,$);
#9= IFCDIRECTION((0.,1.));
#10= IFCCARTESIANPOINT((0.,0.,0.));

#16= IFCRELCONTAINEDINSPATIALSTRUCTURE(‘abcdefghijklmnopqrs105’,$,$,$,(#17, #26, #33, #39, #46, #57, #94, #101),#14);

#26= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs107′,$,’wall1’,$,»,#13,#27,»);
#27= IFCPRODUCTDEFINITIONSHAPE($,$,(#28));
#28= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#29));
#29= IFCEXTRUDEDAREASOLID(#30,#32,#22,1000.);
#30= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,100.,1000.);
#31= IFCCARTESIANPOINT((500.,0.,100.));
#32= IFCAXIS2PLACEMENT3D(#31,$,$);

#33= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs108′,$,’wall2’,$,»,#13,#34,»);
#34= IFCPRODUCTDEFINITIONSHAPE($,$,(#35));
#35= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#36));
#36= IFCEXTRUDEDAREASOLID(#30,#38,#22,1000.);
#37= IFCCARTESIANPOINT((-500.,0.,100.));
#38= IFCAXIS2PLACEMENT3D(#37,$,$);

#39= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs110′,$,’wall3’,$,»,#13,#40,»);
#40= IFCPRODUCTDEFINITIONSHAPE($,$,(#41));
#41= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#42));
#42= IFCEXTRUDEDAREASOLID(#43,#45,#22,1000.);
#43= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,1000.,100.);
#44= IFCCARTESIANPOINT((0.,-500.,100.));
#45= IFCAXIS2PLACEMENT3D(#44,$,$);

#46= IFCWALLSTANDARDCASE(‘abcdefghijklmnopqrs109′,$,’wall4’,$,»,#13,#47,»);
#47= IFCPRODUCTDEFINITIONSHAPE($,$,(#48));
#48= IFCSHAPEREPRESENTATION(#7,’Body’,’SweptSolid’,(#49));
#49= IFCEXTRUDEDAREASOLID(#50,#52,#22,1000.);
#50= IFCRECTANGLEPROFILEDEF(.AREA.,$,#23,1000.,100.);
#51= IFCCARTESIANPOINT((0.,500.,100.));
#52= IFCAXIS2PLACEMENT3D(#51,$,$);

#57= IFCDOOR(‘abcdefghijklmnopqrs111′,$,’door’,$,»,#88,#86,»,$,$);
#86= IFCPRODUCTDEFINITIONSHAPE($,$,(#87));
#87= IFCSHAPEREPRESENTATION(#7,’Body’,’Brep’,(#58));

#58= IFCFACETEDBREP(#59);
#59= IFCCLOSEDSHELL((#80, #81, #82, #83, #84, #85));

#60 = IFCCARTESIANPOINT((0.,0.,0.));
#61 = IFCCARTESIANPOINT((200.,0.,0.));
#62 = IFCCARTESIANPOINT((200.,200.,0.));
#63 = IFCCARTESIANPOINT((0.,200.,0.));
#64 = IFCCARTESIANPOINT((0.,0.,500.));
#65 = IFCCARTESIANPOINT((200.,0.,500.));
#66 = IFCCARTESIANPOINT((200.,200.,500.));
#67 = IFCCARTESIANPOINT((0.,200.,500.));

#68= IFCPOLYLOOP((#60, #61, #62, #63));
#69= IFCPOLYLOOP((#64, #65, #66, #67));
#70= IFCPOLYLOOP((#60, #61, #65, #64));
#71= IFCPOLYLOOP((#61, #62, #66, #65));
#72= IFCPOLYLOOP((#62, #63, #67, #66));
#73= IFCPOLYLOOP((#63, #60, #64, #67));

#80= IFCFACE((#74));
#81= IFCFACE((#75));
#82= IFCFACE((#76));
#83= IFCFACE((#77));
#84= IFCFACE((#78));
#85= IFCFACE((#79));

#88= IFCLOCALPLACEMENT($,#89);
#89= IFCAXIS2PLACEMENT3D(#90,$,$);
#90= IFCCARTESIANPOINT((-100.,400.,100.));

#91= IFCRELVOIDSELEMENT(‘abcdefghijklmnopqrs112’,$,$,$,#46,#92);
#92= IFCOPENINGELEMENT(‘abcdefghijklmnopqrs113′,$,$,$,’Opening’,#88,#86,$);
#93= IFCRELFILLSELEMENT(‘abcdefghijklmnopqrs114’,$,$,$,#92,#57);

Для описания двери мы используем IFCFACETEDBREP и его используем для IFCOPENINGELEMENT в который вставленна наша дверь. Используя разные IFCLOCALPLACEMENT мы можем вставить одну и туже геометрию в разные места и для представления разных объектов — например можем использовать тот же IFCFACETEDBREP для окна.

#94= IFCWINDOW(‘abcdefghijklmnopqrs115’,$,$,$,$,#95,#86,$,$,$);
#95= IFCLOCALPLACEMENT($,#96);
#96= IFCAXIS2PLACEMENT3D(#97,$,$);
#97= IFCCARTESIANPOINT((-100.,-600.,400.));

#98= IFCRELVOIDSELEMENT(‘abcdefghijklmnopqrs116’,$,$,$,#39,#99);
#99= IFCOPENINGELEMENT(‘abcdefghijklmnopqrs117′,$,$,$,’Opening’,#95,#86,$);
#100= IFCRELFILLSELEMENT(‘abcdefghijklmnopqrs118’,$,$,$,#99,#94);

Заключение

Теперь, мой дорогой читатель, ты можешь написать дом свой мечты. К сожалению я не расмотрел IfcMaterialDefinitionRepresentation который отвечат за стиль отображения объектов, не расмотрел IfcTopologyRepresentation — не очень понимаю для чего он служит и не знаю как его визуалезировать. Не расмотрел опции IFC и дополнительный набоы свойств. Но иначе это не было бы кратким введением.

Формат IFC содержит огромное количество объектов, которое становится лишь больше от версии к версии. В тексте спецификации встречаются примечания, которые не отраженны в EXPRESS-схеме, но при этом сильно влияют на обработку файла. По этому трудно реализовать этот формат, не прочитав внимательно всю документацию, но это врядли возможно одному человеку, по этому не существует программы — которая читает его абсолютно правильно, каждая имеет свои особенности. И если в случае open source программ всегда есть возможность исправить обнаруженные ошибки, для проприетарных программ это приводит к невозможности полноценного использования формата IFC.

Формат IFC абсолютно не приспособлен для хранения информации раздела генплана, но в настоящее время идёт активная работа над этим разделом, эта работа должна быть закончена к концу Апреля 2020 и войти в состав IFC5. Так же сейчас идёт работа над IFC Road, IFC Airport и IFC4precast (сборный железобетон). В IFC4x2 появился IFC Bridge, для котрого придумали специальный геометрический объект — IfcSectionedSolidHorizontal

Последние изменения IFC сильно сближают его с GML, даже появился IfcCoordinateReferenceSystem — описание геодезической системы координат. При этом IFC делает упор на описание внутренних структур объекта, а GML описывает его внешнее представление. Но главным отличием IFC является возможномть ссылатся на одни и тежи объекты в разных местах — одна и таже точка, может быть использованна в описании геометрии стены и окна. В GML же, каждый геометрический объект — абсолютно независим.

Источник

Интероперабельность имеет решающее значение для успеха BIM. Разработка открытых стандартов данных и «незарегистрированного» доступа к данным BIM является внеочередным приоритетом для отрасли, если мы хотим избежать недостатков и повторения нерешенных проблем повторного ввода данных. Интероперабельность вместе с IFC позволит повторно использовать проектные данные, которые уже разработаны и, таким образом, обеспечить согласованность между каждой из моделей для различных представлений одного и того же здания. Последовательные, точные и доступные данные для всей проектной группы внесут значительный вклад в смягчение последствий задержек и дополнительных расходов, по словам.

Есть и другие приложения, такие как Bentley Architecture и Autodesk Architectural Desktop, которые разработали свои модели данных здания на основе своих оригинальных платформ в CAD: MicroStation и Auto CAD соответственно.

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

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

buildingSMART определяет IFC как схему данных, которая позволяет хранение данных и обмен информацией между различными приложениями BIM.

Схема IFC является расширяемой и располагает информацией, охватывающей множество дисциплин, которые вносят вклад в здание в течение его жизненного цикла с момента разработки концепции, проектирования, строительства, до реконструкции или сноса.
IFC зарегистрирован Международный организацией по стандартизации (ИСО) как ISO-PAS-16739 (2005) и принят в качестве официальной нормы.

IFC – это схема спецификаций, которая обеспечивает способы определения и понимания информации, отношений и конкретных свойств объектов здания, а также то, что они находятся в модели BIM.

IFC, с технической точки зрения, определен с помощью спецификации нормы ISO 10303-11 для моделирования и обмена данными, также именуемой Стандартом для обмена данными по изделию STEP. ISO начала разработку спецификации (формата данных) STEP в 1984 г. с целью определения стандартов для общего представления и обмена информацией, а также стандарт STEP используется во многих сферах, таких как машиностроение и проектирование. Специалисты, которые первоначально были вовлечены в разработку стандарта STEP, создали МАИ (Международный альянс по интероперабельности) для разработки конкретных стандартов отрасли архитектурного и технического проектирования и строительства.

IFC использует ресурсы на основе стандарта STEP и такой же язык моделирования, который называется EXPRESS.

Из всех технологий преобразования 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).

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

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

Сложность языка IFC

Язык IFC весьма обширен и сложен. Текущая версия 2×4 RC4, buildingSMART (2012d) включает в себя:

Сложность языка усугубляется возможностью существующих альтернативных форм моделирования для одного и того же объекта: например, структурный блок может быть смоделирован как с помощью представления, ограниченного четырьмя планами, так и посредством сжатия поверхности и вектора. Каждый из этих объектов имеет различные семантические значения, и, хотя они могут иметь такой же вид в объемном изображении, они будут рассматриваться по-разному в структурном методе анализа.
В тех случаях, в которых ifc не имеет конкретного объекта, язык содержит в себе механизм моделирования, называемый IfcProxy, который работает в качестве механизма для его расширения.

Если не принимать во внимание сложность языка, модели IFC, как правило, имеют большие размеры файлов. Например, здание с 19-ю панелями, полная модель которого составляет около 360 Mб.

Источник