Ifc interface flash control что это такое

Обновлено: 02.07.2024

Уверены, что у многих такой акцент на этот формат вызывает недоумение. Поговорим об этом.

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

Но мы понимаем, что необходимо взаимодействие:

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

В заметке Экспорт по вашим правилам мы рассказывали о том, как передать в IFC4 всю модель с необходимой информацией. После этого, в версиях 4.1 и 4.2, мы добавили возможность фильтрации по типам объектов при экспорте, и распределение объектов по слоям в IFC-модели. В Renga 4.3 мы работаем над возможностью выбора геометрического представления модели при экспорте в IFC4.

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

Design Transfer View используется для передачи модели из одной системы автоматизированного проектирования в другую, требующую точного математического представления. Теоретически можно будет продолжить работу с такой моделью в другой системе.

Кроме того, совершенно не обязательно ограничиваться стандартными описаниями модели. Вы вместе с коллегами можете определить, какие данные нужны при выполнении совместных задач, и настроить экспорт в соответствии с выработанными требованиями.

Помимо атрибутов, о которых мы уже говорили в блоге, в документации IFC4 описано, какие типы геометрических данных можно использовать для разных представлений модели. Не волнуйтесь, чтобы определить какие геометрические представления использовать, вам не придется заполнять JSON. Вам нужно будет ставить галочки в настройках, а остальное мы берём на себя. Но и к галочкам надо относиться серьезно.

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

Даже пользователи Renga (да и других систем), экспортируя и импортируя IFC туда-обратно, получат разное изображение и содержание модели в зависимости от настроек экспорта.

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

А экспорт Reference View из Renga и загрузка полученной модели в Pilot BIM будет оправдана, так как тогда можно будет продолжить работу в этой системе.

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

Все возможности экспорта в IFC4 на данный момент описаны в справке и этот раздел, разумеется, будет дополняться.

В Renga 4.3 мы перестанем поддерживать экспорт в IFC2x3, поэтому обязательно попробуйте экспорт в IFC4 сейчас. А если при этом что-то пойдет не так, пишите в Службу технической поддержки, так как сейчас именно тот момент, когда мы можем учесть все требования пользователей.

Настройка Revit

Для корректного импорта в СПДС необходимо предварительно настроить Revit.
Сначала в параметрах экспорта необходимо задать соответствие для координационных осей классу IFCGrid .

Если предполагается использовать в ходе экспорта пользовательские семейства Revit, то для этих семейств также необходимо задать соответствие классу IFC. Для этого создается файл общих параметров и параметр IFCExportAs .

Для необходимых семейств в режиме редактирования выбирается общий параметр и задается тип экспорта IFC. Например, для плит перекрытия это класс IFCSlab .

Далее производится экспорт в IFC через меню Revit.

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

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.

Релиз	Дата	Идентификатор	Документация	ИСО-Стандарт
4.2.0.0	2019	IFC4X2	IFC 4.2
4.1.0.4	2018	IFC4X1	IFC 4.1
4.0.2.1	2017	IFC4	IFC 4.0 Addendum 2 TC1	ISO 16739-1:2017
4.0.2.0	2016	IFC4	IFC 4.0 Addendum 2
4.0.1.0	2015	IFC4	IFC 4.0 Addendum 1
4.0.0.5	2013	IFC4	IFC 4.0	ISO 16739:2013
2.3.0.1	2007	IFC2X3_FINAL	IFC 2x3 TC1
2.3.0.0	2006	IFC2X3_FINAL	IFC 2x3
2.2.1.0	2004	IFC2X2_FINAL	IFC 2x2 Addendum 1
2.2.0.0	2003	IFC2X2_FINAL	IFC 2x2
2.1.1.0	2001	IFC2X_FINAL	IFC 2x Addendum 1
2.1.0.0	2000	IFC2X_FINAL	IFC 2x	ISO/PAS 16739:2005
2.0.0.0	1999	IFC 2.0
1.5.1.0	1998	IFC 1.5.1
1.5.0.0	1997	IFC 1.5
1.0.0.0	1996	IFC 1.0

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

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

Описание

Формат IFC существует в трёх ипостасях: IFC-SPF (.ifc), IFC-XML (.ifcXML), IFC-ZIP (.ifcZIP)
IFC-SPF — это текстовый формат, определённый в ISO 10303-21 — фактически это STEP-файл
IFC-XML — это XML-формат определённый в ISO 10303-28 («STEP-XML»)
IFC-ZIP — zip-архив который может содержать .ifc или .ifcXML

Структура файла 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_name;
name : STRING (256) ;
time_stamp : time_stamp_text ;
author : LIST [ 1 : ? ] OF STRING (256) ;
organization : LIST [ 1 : ? ] OF STRING (256) ;
preprocessor_version : STRING (256) ;
originating_system : STRING (256) ;
authorization : STRING (256) ;
END_ENTITY;

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

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

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

Пустой 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.

IFCPROJECT(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>, <LongName>,<Phase>, (<RepresentationContexts>),<UnitsInContext>);

Следующие элементы <Имя>, <Описание>, <ObjectType>, <LongName>,<Phase> — опциональные и текстовые (IfcLabel, IfcText) — описание проекта для человека

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

IFCGEOMETRICREPRESENTATIONCONTEXT(<Имя>,<Тип>,<Размерность пространства>,<Точность - расстояние на котором точки считаются идентичными>,<Система координат>,<Направление на север>)

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

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

IFCRELAGGREGATES(<GlobalId>, <OwnerHistory>, <Имя>, <Описание>, <Родительский элемент>, (<список потомков>));

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

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

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

IfcProductDefinitionShape(<Имя>,<Описание>,(<Representations>))
IfcMaterialDefinitionRepresentation(<Имя>, <Описание>,<Representations>),<RepresentedMaterial>)

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

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

IFCSHAPEREPRESENTATION(<контекст>,<RepresentationIdentifier>,<тип геометрии>,<список элементов>);

Это тело полученное выдавливанием исходного плоского контура SweptArea размещённого в пространстве Position выдавленного в направлении ExtrudedDirection на глубину Depth. Атрибут SweptArea имеет тип IfcProfileDef – это абстрактный класс, имеющий большое количество потомков «на все случаи жизни», в данном случае используется IfcRectangleProfileDef(<ProfileType>,<ProfileName>,<Position>,<XDim>,<YDim>)

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

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

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

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

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

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

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

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

Объект IfcRoof подразумевается сложным объектом – он должен описывать всю кровлю, для связи всех дочерних элементов с ним – нужно использовать IfcRelAggregates. Но при этом IfcRoof может иметь собственую геометрию Representation.
IFCSLAB(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<PredefinedType>);
IFCROOF(<GlobalId>,<OwnerHistory>,<Имя>,<Описание>,<ObjectType>,<ObjectPlacement>,<Representation>,<Tag>,<IfcRoofTypeEnum>);

Пишем 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;

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

IFCPROJECT, IFCUNITASSIGNMENT, IFCGEOMETRICREPRESENTATIONCONTEXT IFCBUILDING=>IFCBUILDINGSTOREY=>IFCRELCONTAINEDINSPATIALSTRUCTURE

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

Заключение

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

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

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

Обзор CIMC — Cisco Integrated Management Controller

Для удалённого администрирования серверов компания CISCO предлагает CIMC — Cisco Integrated Management Controller. Посмотрим, что эту штука умеет.

Наконец-то я добрался до CIMC. Давайте вместе с вами посмотрим, что оно умеет:

Запускаем в Google Chrome — логин прошёл. Попадаем внутрь.

Мы попадаем на вкладку Server в раздел Summary . В правом верхнем углу видим hostname и имя залогиненного пользователя.

Импорт модели в СПДС

Боковая панель проекта в СПДС Менеджер проектов предназначена для отображения структуры и состава модели.

Приступаем к импорту данных Revit в СПДС: В боковой панели нужно создать проект типа Архитектура и выбрать инструмент Импорт IFC.

В результате такого импорта автоматически создаются поэтажные планы модели, содержащие как интеллектуальные СПДС-объекты: стены, окна, двери, колонны, помещения, так и объекты IFC.

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

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

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

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

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

Server Summary

Вверху есть малозаметные кнопки-пиктограммы:

Обновление экрана, включение-выключение питания сервера, KVM, Ping — полезная штука, помощь - подробный хелп, инфо о версии.

Actions

В блоке Actions можно управлять питанием:

Power On Server
Power Off Server
Shut Down Server
Power Cycle Server
Hard Reset Server
Launch KVM Console
Turn On Locator LED

Launch KVM Console - здесь можно запустить KVM Viewer и попасть в консоль сервера. Есть некоторые моменты, джава-плагин скачивается с неудобным расширением, приходится его переименовывать руками перед запуском.

Примечание: в версии 2.0(10k) уже нет проблемы с переименовыванием плагина. Он сразу скачивается как нужно.

KVM очень похож на такой же от IBM.

Здесь же можно примаунтить папку, диск или ISO файл.

Server Properties

Здесь можно посмотреть:

Product Name (у меня пустой).
Cерийный номер .
IPD.
UUID.
Версию BIOS.
Можно ввести описание.

Server Status

Здесь можно посмотреть статус сервера по питанию, температуре, ОЗУ.

Server Utilization

Использование CPU, Memory, IO и общий в процентах.

Cisco Integrated Management Controller (Cisco IMC) Information

СПДС GraphiCS 2019 и nanoCAD СПДС 10. Работа с IFC из Revit

Autodesk Revit (далее – Revit) является одной из программ, осуществляющей автоматизированное проектирование в технологии информационного моделирования зданий (BIM). Вместе с тем, основным результатом проектирования являются плоские чертежи, для оформления которых используются СПДС GraphiCS 2019 и nanoCAD СПДС 10 (далее – СПДС). Совместная работа СПДС и Revit является предметом обсуждения данной статьи.

Передача информационной модели Revit происходит путем конвертации в формат IFC – универсальный обменный формат. К слову говоря, СПДС может использовать IFC из любой BIM-системы, а не только из Revit. Это может быть ArchiCAD от Graphisoft и ModelStudio от CSoft Development.

Итак, если проектная организация:

Использует несколько BIM-систем, координируемых через обмен IFC в рамках технологии OPEN BIM,
Еще не полностью перешла на цифровое моделирование,
Часто обменивается двухмерной документацией со смежными отделами или субподрядными организациями,

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

Программы СПДС позволяют создавать поэтажные планы из трехмерной модели посредством импорта из формата IFC. IFC — это стандарт передачи строительных моделей, поддерживаемый большинством BIM-систем, в том числе и Revit.

Читайте также: