Формате ifc что это

Формат IFC

Если коротко, то формат Industry Foundation Classes (IFC) предназначен для описания данных об архитектуре, проектировании и строительстве и был создан по инициативе Autodesk.

Сразу надо отметить, что IFC не является форматом обмена данными для дальнейшего редактирования. Т.е модель в формате IFC не подходит для продолжения работы с ней после импорта в любую BIM программу. Для чего же можно его использовать? Например, если вашему заказчику понадобится весь проект или его раздел в формате IFC.

Richard Junge взяв за основу STEP, поставил задачу разработать формат, который станет независимым от производителей САПР. Его идея заключалась в том, чтобы весь процесс от проекта до строительства и управления зданием упростить и ускорить. В отличие от традиционного обмена 2D-линиями и 3D-данными объема, IFC должен был предоставить пользователю кросс-программную «интеллектуальную» модель данных. Например, инженер-строитель мог бы изменить или расширить модель данных с учетом статических требований и вернуть изменения архитектору без потерь. Планировщик строительных услуг также мог бы использовать эту информацию для планирования маршрута. Также должны были бы учитываться все изменения модели, т.е. документироваться. Patrick MacLeamy, американский архитектор и председатель BuildingSMART, перенес тему в Соединённые Штаты. Дальнейшая разработка формата IFC осуществлялась Autodesk и в 1994 году Autodesk зарегистрировала формат IFC на своё имя.

Борьба за рынок CAD продолжается по всему миру. Сегодня всё BIM можно разделить на два типа: ClosedBIM – использование в проектировании программы одного производителя, OpenBIM – работа с открытым форматом данных, который должен автоматически читаться другими программами.

Ярким представителем ClosedBIM сегодня является Revit. Он безвозвратно изменил представление пользователей CAD-программ об интерфейсе, простоте использования и быстроте проектирования. Его прародитель, софт Pro/Engineer в середине 90-х был глобальным лидером на западном рынке конструкторского проектирования машиностроительной промышленности. Цель его состояла в том, чтобы создать систему, которая была бы достаточно гибкой, чтобы побудить инженера легко рассматривать различные конструкции, а затраты на внесение изменений в проект должны быть минимальны. Начав в 1996 году команда разработчиков Revit, используя твердотельное параметрическое моделирование с концепцией единой модели данных для всего проекта, создала радикально новый подход к программному обеспечению для строительства. В 2002 году стартап Revit купила компания Autodesk. К сожалению, и, как ни странно, формат IFC трудно стыкуется c программами от Autodesk.

Европейские производители САПР после опубликования формата IFC пытаются его использовать. Например, Graphisoft утверждает, что программа ArchiCAD идеально подходит для работы с этим форматом и говорит о “99 процентной” работе с IFC данными. Правительства многих европейских стран уже давно сделали использование формата IFC обязательным для проектов строительства с государственной помощью. Главным по ОpenBIM в Европе является Nemetschek Group с двумя подразделениями Allplan и Archicad.

Какую роль играет наше государство в вопросах контроля и установления правил по обменным форматам? Оно следует примеру европейцев и похоже, заинтересовано в развитии OpenBIM. Министерство строительства и жилищно-коммунального хозяйства РФ и ФАУ «Федеральный центр нормирования, стандартизации и оценки соответствия в строительстве» в 2017 г разработало методические указания по обеспечению интероперабельности при информационном моделировании объектов строительства.

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

Статической модели IFC оказывается достаточно для выполнения анализа с помощью аналитического программного обеспечения. Однако если вы хотите изменить модель на основе результатов анализа, то IFC не позволит этого сделать. Так, на сайте Archicad отмечается, что при импорте IFC-модели некоторые элементы, определенные как IfcWall, IfcSlab и т.д., импортируются как объекты, а не как стены, перекрытия и т.д. Причина заключается в их упрощенном геометрическом BREP-представлении, задающем «наружную поверхность» или «контурное представление». Это означает, что кроме геометрической формы элемент не включает никакой другой информации, например, нет его привязки к осевым линиям. Таким образом, при проектировании конструкций со сложной геометрией в случае обмена данными по стандарту IFC приходится сталкиваться с потерей информации.

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

Существует ряд инициатив по созданию стандартов компонентов BIM, таких как Национальная библиотека BIM в Великобритании NBS (UK NBS National BIM Library). Но в NBS Великобритании пришлось использовать файлы проприетарного формата из-за отсутствия необходимой функциональности файлов IFC. Тем не менее, возможно появится способ для создания файловой схемы компонента IFC.

Альтернативой использованию формата IFC для обмена данными является использование специальных инструментов программного обеспечения для обмена данными:

– программные решения одного производителя САПР на основе внутренних форматов и прямых API-интерфейсов (интерфейс прикладного программирования);

– программные решения различных производителей САПР на основе проприетарных форматов и прямых API-интерфейсов.

Многие специалисты BIM считают, что формат обмена IFC не соответствует в полной мере их требованиям к обмену данными. Обсуждение данного вопроса и совместной работы постоянно ведется основными BIM-вендорами, такими как, Trimble, Graphisoft, Hexagon, Nanosoft, Aveva, Renga, Dassault Systemes, Allplan, Cadmatic, CSoft Development и пр. В основном ими приветствуется концепция OpenBIM. Причин тому много. И то, что нет такой ClosedBIM (или SuperBIM) которая бы в полной мере обеспечивала все разделы проектной документации, расчет и дальнейшую эксплуатацию. И то, что чем больше проект, тем больше независимых участников. Многие производители САПР понимают, что увеличения использования их софта можно добиться, если предлагать помощь своим клиентам в интеграции и сами разрабатывают какие-либо решения. Именно европейские вендоры активно развивают конвертеры, адаптеры и сервисы с сохранением всей геометрией и атрибутивной информацией. Например, eShare – веб-портал для визуализации, обмена и интеграции проектных, строительных и эксплуатационных данных о промышленном объекте на основе BIM модели компании Cadmatic, Bimplus – открытая платформа для совместной работы над проектами на основе BIM-модели для строительной отрасли компании Allplan.

Заказчики строительства, производители строительных материалов и инженерного оборудования используют решения различных САПР и заинтересованы в том, чтобы все САПР в полном объеме интегрировались друг с другом. Или хотя бы быстрее появлялись цепочки использования программных решений.

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

Источник

Формат IFC как инструмент контроля: целеполагание, устройство, интероперабельность

Активное развитие и внедрение технологий информационного моделирования (Building Information Modeling, BIM) во многом способствовало росту интереса к формату IFC (Industry Foundation Classes), тем не менее, количество доступной информации о формате на русском языке остается довольно ограниченным. В открытых источниках можно прочитать о том, как именно функционирует формат, а в данной статье мы предлагаем разобраться, что же такое IFC формат, чем обусловлено его появление, где и как именно он применяется, и когда мы можем ожидать его повсеместное использование.

В начале 1990-х годов рядом компаний-разработчиков САПР-систем была поставлена задача по созданию объектно-ориентированного интерфейса, позволяющего интегрировать приложения в отрасли архитектурного и технического проектирования и строительства путем создания большой группы непротиворечивых данных. Результат такой интеграции должен был представлять собой модель данных здания и обеспечивать эффективный обмен информацией между производителями программного обеспечения для отрасли. В рамках решения поставленной задачи был сформирован международный альянс по интероперабельности (IAI), существующий сегодня как консорциум buildingSMART. Важной миссией стали создание, поддержка и развитие IFC формата как нейтральной модели данных перевода, стандартизировавшего совместно используемую информацию.

Консорциум buildingSMART метафорически описывает IFC как замороженную копию реального объекта, как PDF файл к BIM модели: он статичный и не предполагает изменений. В IFC файле содержатся необходимые данные для анализа модели на разных этапах жизненного цикла объекта.

Несмотря на то, что IFC формат был зарегистрирован Международной организацией по стандартизации (ISO) еще в 2005 г. и принят в качестве официальной нормы, он зачастую продолжает использоваться проектными компаниями только для внутренних нужд, а в Российской Федерации к нему обращаются крайне редко и на очень точечных проектах. Такое использование не отвечает основным причинам и целям создания формата и не отражает основные задачи, которые решает IFC.

Задачи, которые решает IFC

Главной целью обращения к IFC файлам является контроль: формат позволяет контролировать потоки информации, сроки работ и денежные средства. Контроль оказывается максимально упрощен благодаря структуре и опыту, заложенному в него международными девелоперами. Консорциум buildingSMART, стейкхолдер формата, стимулирует его обновление и развитие именно как инструмента контроля над капитальными затратами на каждый объект.

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

Сферы применения IFC

Главными сферами применения IFC формата являются крупные региональные и сложные международные проекты, в свете этого меняется отношение к самому формату, некоторым возможным ошибкам, связанным с импортом или экспортом, к деталям, связанным с настройкой таблиц внутри САПР-систем. Сложный и масштабный международный проект, объединяющий множество подрядных компаний (например, аэропорт в Кувейте или проект Pontsteiger в Амстердаме), требует построения сложной структуры обмена данными и тонкой настройки информационных потоков. В этом случае именно IFC послужит инструментом, позволяющим интегрировать системы между собой и осуществлять эффективный обмен информацией и контроль за сроками и затратами.

IFC используется при управлении объектами капитального строительства, поскольку он представляет собой текстовый формат, совместимый с любой ERP-системой. На основании свойств продуктов и детальности модели ERP- система ТСЖ, нефтеперерабатывающего завода или атомной электростанции сможет управлять информацией и сообщать о требующихся текущих или капитальных ремонтах оборудования. Данный процесс может масштабироваться и на государственное управление или управление информацией об объектах капитального строительства: выдачу разрешений на строительство, построение процессов, связанных с управлением объектами капитального строительства и др. Такие примеры сегодня известны: одной из передовых стран здесь является Финляндия, где вся столица, Хельсинки, и несколько близлежащих городов управляются на основании геоинформационных систем и систем, построенных на базе IFC. На них основаны все государственные мероприятия, касающиеся объектов капитального строительства, а значит, государственному заказчику не потребуется закупка программного обеспечения, не требуется техническая поддержка вендоров и в этот момент не будет осуществляться лоббирование какого-либо продукта.

Устройство IFC файла

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

Нам бы очень хотелось, чтобы в Российской Федерации IFC стал ключевым форматом для обмена данными и чтобы максимальное количество компаний, заинтересованных в крупных региональных проектах, принимали участие в работе buildingSMART Россия и существующих в консорциуме рабочих группах.

Источник

Интероперабельность имеет решающее значение для успеха 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б.

Источник