Реферат Выпускная квалификационная работа, 40 страниц, 19 рисунков, 6 таблиц, 10 источников. САПР, BIM, СТАНДАРТ IFC4, IFC ALIGNMENT, INDORCAD, ПОПЕРЕЧНЫЙ ПРОФИЛЬ ДОРОГИ, ПРОДОЛЬНЫЙ ПРОФИЛЬ ДОРОГИ, BUILDINGSMART, OMNICLASS Объект разработки модуль импорта/экспорта данных системы IndorCAD Цель работы разработать модуль обмена данными для системы IndorCAD в расширенном IFC формате, позволяющий описывать специфические для дорожной отрасли типы объектов. Результат работы модуль разработан и встроен в систему, проект расширения стандарта оформлен в виде статьи и будет доложен на международной конференции. 2
3 Содержание Реферат… 2 Введение Обзор технологий и стандартов BIM технологии IFC формат Продукты, реализующие поддержку IFC Форматы файлов IFC Версии IFC IFC Alignment Расширение стандарта IFC Alignment Прилегающие объекты PointObject LineObject PolygonObject Surface Сложные линейно протяженные объекты Поперечный профиль Создание массива для кодов классификатора Изменение стандартного описания отрезка Полное описание линейно протяженного объекта Расширение классификатора OmniClass Исследование существующих типов Типы объектов по функции Типы объектов по форме Добавление новых типов в классификатор Расширение модуля импорта/экспорта данных системы IndorCAD Схема IFC4x Новые типы сущностей Новое свойство для отрезка Модуль IfcUtils Имена новых сущностей Процедуры создания новых сущностей Процедуры присвоения свойств для новых сущностей Добавление нового свойства для отрезка Заключение Список использованных источников и литературы
4 Введение На сегодняшний день во многих сферах производства процесс проектирования и документации происходит не на бумаге, а в электронном виде. В дорожной отрасли начали внедрять САПР, системы автоматизированного проектирования, которые смогли сделать процесс проектирования объектов строительства гораздо более удобным. Говоря о дорожной отрасли, стоит отметить, что информация по уже построенным дорогам в России хранится в бумажных архивах, электронных паспортах и чертежах. Однако нет электронной модели уже построенных дорог. Жизненный цикл объекта строительства состоит из множества этапов: планирование концептуальный дизайн проектирование анализ документирование строительство управление временем и ресурсами при строительстве строительная логистика содержание ликвидация или обновление. Представленные этапы соответствуют концепции BIM (англ. Building Information Modeling).
Сущность системы стандартов безопасности труда
... стандартизации в области безопасности труда (цели, задачи и структура системы, внедрение и контроль за соблюдением стандартов ССБТ, терминология в области безопасности труда, ... должны иметь групповой заголовок: «Система стандартов безопасности труда». Объекты стандартизации ССБТ Объектами стандартизации ССБТ являются правила, нормы ... к отдельным классам, видам и типам средств защиты; методы контроля и ...
В1987 году появилась первая коммерческая реализация BIM, технологии информационного моделирования здания. Ее отличительной особенностью является возможность работы с электронной моделью изделия на каждом этапе его жизненного цикла. На сегодняшний день BIM широко используется для комплексного проектирования и эксплуатации зданий во многих продуктах, таких как: ArchiCAD (GraphiSoft, Венгрия), Revit (Autodesk, США) и других. Для передачи данных на разных этапах проектирования объектов и в целом их жизненного цикла используется стандартизованная модель данных IFC, Industry Foundation Classes, имеющая несколько форматов файлов. Таким образом, в этом файле хранится вся информация, связанная с объектом строительства, и может быть изменена на любом этапе: от планирования до ликвидации. 4
5 Однако очевидно, что жизненный цикл зданий сильно отличается от жизненного цикла автомобильных дорог, поэтому передавать информацию, основываясь на одной модели, неудобно. На данный момент BIM в чистом виде не подходит для инфраструктуры, так как не учитываются особенности отрасли. А значит при проектировании и эксплуатации объектов компании, занимающиеся разработкой, используют собственные программные продукты, не совместимые друг с другом. Это усложняет процесс взаимодействия и повторного использования проектов разными САПР. Поэтому, как и в других отраслях производства, необходимы стандарты для обменного формата в том числе в сфере дорожного строительства. В 2015 году компанией BuildingSMART был создан проект IFC для инфраструктуры IFC Alignment. Предполагается, что этот проект войдет в новую версию стандарта IFC5 и позволит упростить работу с проектами строительства в том числе автодорог. Однако первая версия стандарта имеет несовершенства, устранение которых, а также добавление необходимых с точки зрения компании аспектов позволило бы сделать работу еще удобнее. Цель данной работы расширение существующего стандарта IFC Alignment и внедрение изменений в модуль импорта/экспорта данных системы IndorCAD. Для достижения поставленной цели были выявлены следующие задачи: Ознакомиться с BIM технологиями и IFC форматом Выявить недостатки существующего стандарта IFC Alignment для дорожной отрасли Расширить стандарт IFC Alignment Внедрить изменения в модуль импорта/экспорта данных для системы IndorCAD Результаты исследований оформить в виде статьи и доложить о них на международной конференции Как было сказано ранее, важно, чтобы в отрасли существовали единые стандарты. Поэтому последний пункт в списке задач очень важен: публикация результатов исследований поспособствует развитию BIM технологий в целом и более быстрому утверждению новых стандартов IFC в частности. 5
6 1 Обзор технологий и стандартов 1.1 BIM технологии Building information modeling (BIM) это процесс, включающий в себя создание и управление электронным представлением физических и функциональных характеристик объектов [1].
На данный момент продукты, реализующие BIM, используются для планирования, дизайна, создания и поддержания различных объектов инфраструктуры, таких как электричество, газ, коммуникации в коммунальном хозяйстве, дороги, мосты, туннели и прочих. Концепция BIM появилась в 1970х годах. Однако сам термин стал использоваться только в начале XXI века, когда компания Autodesk выпустила документацию под названием «Building Information Modeling». После этого и другие поставщики программного обеспечения стали заявлять о своей причастности к этой сфере. Традиционное проектирование основывается на двумерных моделях объектов, тогда как BIM расширяет уже трехмерные модели, дополняя три базовых измерения (ширина, высота и глубина) осью времени и стоимости (соответственно, четвертым и пятым измерением).
Незавершенное строительство как объект недвижимости
... в строительство недвижимости, но, к сожалению, не всегда доходят до логического завершения этого процесса, нельзя игнорировать вопрос, связанный с определением правового статуса объектов, незавершенных строительством. По существу в данный момент ...
В том числе BIM охватывает расположение объекта в пространстве, анализ света, географическую информацию, а также количество и свойства частей объекта. В сфере строительства существует большое количество типов объектов. Для структуризации и более удобной работы с ними в том числе на стадии проектирования создаются системы, нацеленные на классификацию объектов в определенной отрасли. На данный момент существует множество подобных систем в сфере строительства: OmniClass (США) [2], Uniclass (Великобритания) и др. Они устроены таким образом, что все объекты строительства являются частью иерархии: например, тип «конструкция» содержит в себе тип «мост», который в свою очередь содержит тип «пешеходный мост». Такой способ организации типов позволяет группировать объекты одного уровня и в дальнейшем добавлять новые, более детализированные типы. Несмотря на то что они изначально были созданы для строительства зданий, в таблицах классификаторов содержится довольно много типов, относящихся и к дорожной отрасли. На рисунке представлен фрагмент Таблицы 12 системы OmniClass, классифицирующей объекты по форме: 6
7 Табл. 1. Классификатор OmniClass, фрагмент Таблицы 12 В настоящий момент проблема создания единого классификатора пока не решена, однако в данной работе при описании объектов будут использованы коды классификатора OmniClass, используемого в рамках отрасли. Информационные модели зданий это, как правило, файлы, которые можно извлекать, передавать или связывать с целью поддержки принятия решений на всех этапах жизненного цикла объектов строительства. Для обмена данными между различными приложениями по работе с объектами строительства была создана модель данных Industry Foundation Classes (IFC).
1.2 IFC формат Industry Foundation Classes (IFC) это формат данных, используемый для описания и обмена информацией об объектах в сфере строительства и управления объектами промышленности [3].
Разработкой спецификации для стандарта IFC занимается компания BuildingSMART. IFC улучшает взаимодействие, производительность, скорость и качество работы на протяжении всего жизненного цикла объекта строительства. 7
8 1.2.1 Продукты, реализующие поддержку IFC Первой программой, позволяющей обмениваться данными в формате IFC, стала программа ArchiCAD компании GraphiSoft (Венгрия).
На данный момент IFC формат поддерживают следующие продукты: ArchiCAD компании GraphiSoft (Венгрия) Tekla Structures компании Tekla (Финляндия) VectorWorks компании Nemetschek (Германия) AllPlan компании Nemetschek (Германия) SCIA компании Nemetschek (Германия) Revit компании Autodesk (США) Autocad компании Autodesk (США) Openbim, открытый инструмент BIM для разработки приложений, основанных на IFC ScetchUp компании Trimble (США) FreeCAD, пакет трехмерного проектирования с открытыми исходными кодами с архитектурным модулем на базе ядра OpenCASCADE Форматы файлов IFC Импорт и экспорт данных между приложениями может происходить с помощью одного из следующих форматов файлов [4]:.ifc файл стандартного формата для обмена данными, основан на файловой структуре STEP, согласно стандарту ISO Пример фрагмента файла в данном формате приведен ниже: ISO ; HEADER; FILE_DESCRIPTION ((‘ViewDefinition [CoordinationView, QuantityTakeOffAddOnView]’), ‘2;1’); FILE_NAME (‘example.ifc’, ‘ T21:53:56’, (‘Architect’), (‘Building Designer Office’), ‘IFC Engine DLL version 1.02 beta’, ‘IFC Engine DLL version 1.02 beta’, ‘The authorising person’); FILE_SCHEMA ((‘IFC2X3’)); ENDSEC; DATA; #1 = IFCPROJECT(‘3MD_HkJ6X2EwpfIbCFm0g_’, #2, ‘Default Project’, ‘Description of Default Project’, $, $, $, (#20), #7); #2 = IFCOWNERHISTORY(#3, #6, $,.ADDED., $, $, $, ); #3 = IFCPERSONANDORGANIZATION(#4, #5, $); #4 = IFCPERSON(‘ID001’, ‘Bonsma’, ‘Peter’, $, $, $, $, $); 8
Анализ новых требований международного стандарта ISO 14001 версии ...
... большим количеством нововведений. Переходный период означает возможность применения старой версии стандарта ISO 14001: 2004 теми компаниями, которые имеют действующие сертификаты соответствия, при том, что новая ... проанализировать на какой стадии подготовки компания находиться, чтобы принять одно из решений: 1. Или пройти сертификацию на соответствие ISO 14001 версии 2004 года, что возможно сделать ...
9 #5 = IFCORGANIZATION($, ‘TNO’, ‘TNO Building Innovation’, $, $); #6 = IFCAPPLICATION(#5, ‘0.10’, ‘Test Application’, ‘TA 1001’); #7 = IFCUNITASSIGNMENT((#8, #9, #10, #11, #15, #16, #17, #18, #19)); #8 = IFCSIUNIT(*,.LENGTHUNIT., $,.METRE.); #9 = IFCSIUNIT(*,.AREAUNIT., $,.SQUARE_METRE.); #10 = IFCSIUNIT(*,.VOLUMEUNIT., $,.CUBIC_METRE.); #11 = IFCCONVERSIONBASEDUNIT(#12,.PLANEANGLEUNIT., ‘DEGREE’, #13); #12 = IFCDIMENSIONALEXPONENTS(0, 0, 0, 0, 0, 0, 0); #13 = IFCMEASUREWITHUNIT(IFCPLANEANGLEMEASURE(1.745E-2), #14); #14 = IFCSIUNIT(*,.PLANEANGLEUNIT., $,.RADIAN.); #15 = IFCSIUNIT(*,.SOLIDANGLEUNIT., $,.STERADIAN.); #16 = IFCSIUNIT(*,.MASSUNIT., $,.GRAM.); #17 = IFCSIUNIT(*,.TIMEUNIT., $,.SECOND.); #18 = IFCSIUNIT(*,.THERMODYNAMICTEMPERATUREUNIT., $,.DEGREE_CELSIUS.); #19 = IFCSIUNIT(*,.LUMINOUSINTENSITYUNIT., $,.LUMEN.); #20 = IFCGEOMETRICREPRESENTATIONCONTEXT($, ‘Model’, 3, 1.000E-5, #21, $); #21 = IFCAXIS2PLACEMENT3D(#22, $, $); #22 = IFCCARTESIANPOINT((0., 0., 0.)); #23 = IFCSITE(‘3rNg_N55v4CRBpQVbZJoHB’, #2, ‘Default Site’, ‘Description of Default Site’, $, #24, $, $,.ELEMENT., (24, 28, 0), (54, 25, 0), $, $, $); #24 = IFCLOCALPLACEMENT($, #25); #25 = IFCAXIS2PLACEMENT3D(#26, #27, #28); #26 = IFCCARTESIANPOINT((0., 0., 0.)); #27 = IFCDIRECTION((0., 0., 1.)); #28 = IFCDIRECTION((1., 0., 0.)); #29 = IFCBUILDING(‘0yf_M5JZv9QQXly4dq_zvI’, #2, ‘Default Building’, ‘Description of Default Building’, $, #30, $, $,.ELEMENT., $, $, $); #30 = IFCLOCALPLACEMENT(#24, #31); #31 = IFCAXIS2PLACEMENT3D(#32, #33, #34); #32 = IFCCARTESIANPOINT((0., 0., 0.)); #33 = IFCDIRECTION((0., 0., 1.)); #34 = IFCDIRECTION((1., 0., 0.)); #35 = IFCBUILDINGSTOREY(‘0C87kaqBXF$xpGmTZ7zxN$’, #2, ‘Default Building Storey’, ‘Description of Default Building Storey’, $, #36, $, $,.ELEMENT., 0.); #36 = IFCLOCALPLACEMENT(#30, #37); #37 = IFCAXIS2PLACEMENT3D(#38, #39, #40); #38 = IFCCARTESIANPOINT((0., 0., 0.)); #39 = IFCDIRECTION((0., 0., 1.)); 9
10 #40 = IFCDIRECTION((1., 0., 0.)); ENDSEC; END-ISO ;.ifcXML файл, имеющий структуру документа XML. Может быть создан в исходном приложении или сконвертирован из файла формата.ifc, согласно стандарту ISO Недостаток файла данного формата заключается в том, что его объем на % больше объема аналогичного файла в формате.ifc. Далее так же представлен фрагмент файла в данном формате: <?xml version=»1.0″ encoding=»utf-8″?> <ex:iso_10303_28 xmlns:xlink=» xmlns:xsi=» xmlns:ex=»urn:iso.org:standard:10303:part(28):version(2):xmlschema:common» xmlns=» xsi:schemalocation=» version=»2.0″> <ex:iso_10303_28_header> <ex:name>example.ifcxml</ex:name> <ex:time_stamp> t23:24:27</ex:time_stamp> <ex:author>architect</ex:author> <ex:organization>building Designer Office</ex:organization> <ex:documentation>viewdefinition [CoordinationView, QuantityTakeOffAddOnView]</ex:documentation> </ex:iso_10303_28_header> <uos id=»uos_1″ description=»» edo=»» configuration=»default» xmlns=» xsi:schemalocation=» <IfcProject id=»i1″> <GlobalId>2ed7deT153aRxe9mZWpFs7</GlobalId> <OwnerHistory> <IfcOwnerHistory xsi:nil=»true» ref=»i2″/> </OwnerHistory> <Name>Default Project</Name> <Description>Description of Default Project</Description> <RepresentationContexts ex:ctype=»set»> <IfcGeometricRepresentationContext pos=»0″ xsi:nil=»true» ref=»i20″/> </RepresentationContexts> 10
Температура воздуха и её влияние на хозяйственные и природные объекты
... При этом происходит некоторое запаздывание роста и понижения температуры воздуха по сравнению с изменением температуры почвы. Минимальная температура воздуха на высоте 2 м наблюдается перед восходом солнца. ... правильно решать задачи мелиорации или улучшения климата. Актуальностью данной курсовой работы, Объектом изучения курсовой работы, Предметом изучения является, Для реализации поставленной цели, ...
11 </IfcProject> <UnitsInContext> <IfcUnitAssignment xsi:nil=»true» ref=»i7″/> </UnitsInContext> <IfcCartesianPoint id=»i26″> <Coordinates ex:ctype=»list»> </Coordinates> </IfcCartesianPoint> </uos> </ex:iso_10303_28> <IfcLengthMeasure pos=»0″>0.</ifclengthmeasure> <IfcLengthMeasure pos=»1″>0.</ifclengthmeasure> <IfcLengthMeasure pos=»2″>0.</ifclengthmeasure>.ifczip сжатый.ifc или.ifcxml файл. Для сжатия необходимо, чтобы в директории.zip архива находился один файл.ifc /.ifcxml. Обычно исходные.ifc файлы сжимаются на 60-80%,.ifcXML файлы на 90-95% Версии IFC На данный момент последняя спецификация — IFC4 Add2 (второе дополнение версии IFC4), вышедшая в июле 2016 года [5].
Она включает в себя необходимые исправления, которые потребовались в ходе стандартизации IFC4 Reference View и IFC4 Design Transfer View. Эта версия стала основой для ранее упомянутых IFC Reference View V1.1 и IFC4 Design Transfer View V1.1. Предыдущие версии в хронологическом порядке: IFC4 Add1 первое дополнение версии IFC4, включившее в себя необходимые изменения, которые потребовались после пилотных выпусков Model View Definitions. Версия была выпущена в июле 2015 года и стала основой для IFC Reference View V1.0 и IFC4 Design Transfer View V1.0. IFC4 (официальное название IFC2x4) была выпущена в марте 2013 года как новая платформа IFC для будущих версий. Она включила в себя несколько расширений IFC для зданий, сервиса и других сфер в строительстве, улучшения геометрии и других компонент, а также многочисленные качественные улучшения, полностью взаимосвязанную спецификацию для ifcxml и новый формат документации 11
Производство гнутых профилей
... полосы к профилегибочному стану. Профилегибочный стан предназначен для формовки из полосы гнутых профилей различных размеров и конфигураций. Рабочие клети стана смонтированы на общей ... продукция круглых и профильных труб по трубной технологии, производство сварных замкнутых профилей, производство швеллеров и специальных профилей растет в различных сферах промышленности особенно в строительстве. ...
12 IFC2x3-TC1 технические исправления третьей версии IFC2x. Обновленный IFC2x3-TC1 и IFC2x3 release одинаковы в отношении обмена данными и оба готовы к реализации IFC2x3 третья версия IFC2x была выпущена в феврале 2006 года, отличается лишь качественными улучшениями версии IFC2x2 IFC2x2 Add1 первое, незначительное дополнение второй версии IFC2x, исправившее ошибки реализации от июля 2004 года, далее эта версия была использована в реализации и стандартизации IFC2x2 IFC2x2 вторая версия IFC2x, выпущена в мае 2003 года IFC2x-Add1 первое, незначительное дополнение версии платформы IFC2x, исправившее ошибки реализации от октября 2001 года, далее эта версия была использована в реализации и стандартизации IFC2x IFC2x первая версия платформы IFC2x, задачей которой было создание стабильной платформы, выпущена в октябре 2000 года более ранние версии (IFC2.0, IFC1.5 и IFC1.0) на данный момент устарели и не котируются. Предстоящая версия IFC5 на данный момент находится на стадии планирования. Ожидается, что эта версия обеспечит полную поддержку для различных сфер инфраструктуры. Первый проект, который позволит расширить IFC формат для инфраструктуры, — IFC Alignment. 1.3 IFC Alignment IFC Alignment представляет собой стандарт, который станет основой для будущих проектов, таких как IFC-Bridge и IFC-Road, и предоставит модель данных для представления двумерной и трехмерной информации об объектах инфраструктуры [6].
12
13 Общая структура стандарта приведена на диаграмме ниже. Рис. 1. Общая структура Alignment Согласно текущему стандарту, объект может быть представлен в следующих видах: в плане (horizontal alignment) Рис. 2. Кривые в плане 13
14 Файл формата.ifc, содержащий информацию об объекте: в продольном профиле (vertical alignment) 14
15 Рис. 3. Кривая в продольном профиле Файл формата.ifc, содержащий информацию об объекте: в трехмерном виде (3D alignment) в совокупности вида в продольном профиле, в плане и трехмерного вида 15
16 В январе 2015 года появилась финальная версия проекта стандарта (IFC Alignment Extension candidate standard), а 28 марта 2015 года этот стандарт был одобрен и получил название IFC Alignment 1.0 [7].
Важность данного проекта состоит в том, что объекты инфраструктуры имеют не свойственную зданиям форму (например, клотоид).
Поэтому в стандарте содержится модель данных о типах сущностей (сегментов), встречающихся при проектировании объектов инфраструктуры, таких как: отрезок в плане (IfcLineSegment2D [8], рис. 4) дуга в плане (IfcCircularArcSegment2D [9], рис. 5) клотоида в плане (IfcClothoidalArcSegment2D [10], рис. 6) Таким образом, модели данных, которые описаны в стандарте, являются основой для многих типов объектов инфраструктуры, например, железных и автомобильных дорог, мостов, туннелей, трубопроводов и прочих. Рис. 4. Сегмент прямой 16
17 Рис. 5. Сегмент дуги Рис. 6. Сегмент клотоиды IFC Alignment содержит лишь базовые элементы проектирования, которые неудобно использовать в реальных проектах. Эти неудобства вызваны недостаточным содержанием при описании объектов: сегменты, входящие в стандарт IFC Alignment, могут описать лишь ось линейно протяженного объекта без его качественного содержания. Поэтому одна из задач данной работы расширить данный стандарт для более удобного его использования при проектировании объектов дорожной отрасли. 17
Геодезические работы при трассировании линейных объектов. Геодезические ...
... трассы проектируемого сооружения, Трассирование линейных сооружений, Геодезическое трассирование План – проекция трассы на горизонтальную плоскость. Продольный профиль трассы План ... хода по трассе, разбивку пикетажа и поперечных профилей, нивелирование, закрепление трассы, а также при ... ценность для народного хозяйства. Технология изысканий линейных объектов. Методика, точность и порядок инженерных ...
18 2 Расширение стандарта IFC Alignment Прежде всего необходимо определить базовый элемент описания трёхмерных объектов. Это точка XYZ[i] с координатами, соответственно, (x, y, z).
Общий вид точки в IFC формате выглядит следующим образом: #i=ifc3dpoint((x,y,z)); Также основой для описания объектов является свойство State. Оно может принимать одно из двух значений: Initial (исходное) или Project (проектное).
Исходное состояние означает, что объект уже существует на момент начала проектирования, проектное состояние то, которое требуется для данного проекта, но отличается от исходного. В дальнейшем для каждого объекта должно быть указано его состояние. Рассмотрим теперь виды объектов, для которых необходимо расширить стандарт. 2.1 Прилегающие объекты В рассматриваемой отрасли к прилегающим объектам относятся, например, дорожные знаки, изгороди, природные объекты (деревья, водоемы).
Разобьем их на три вида: точечные объекты, линейно протяженные объекты и площадные объекты PointObject Такие объекты описываются одной точкой в трехмерном пространстве. В дорожной отрасли к ним относятся, например, деревья и дорожные знаки. Каждый PointObject должен иметь состояние: проектное или исходное. Кроме того, такие объекты должны иметь тип, значением которого является ссылка на классификатор. В данной работе будет использована классификация OmniClass, рассмотренная ранее. Каждый тип объекта в данной классификации имеет свой код, который является ссылкой на классификатор в описании. Ниже представлено описание такого объекта в IFC формате на примере дорожного знака: #13=IFC3DPOINT((100.13,2.48,204.93)); #14=IFCPOINTOBJECT(‘INITIAL’,#13,’ ‘); Параметры объекта: 1. State: INITIAL или PROJECT 2. координата объекта точка 3. тип объекта ссылка на классификатор. Здесь, ‘ ‘ ссылка на классификатор Outdoor sign, взятая из Таблицы 12 OmniClass, классифицирующей объекты по форме 18
19 2.1.2 LineObject Таким образом описываются линейно протяженные объекты, не требующие дальнейшей детализации в данной отрасли. К таким объектам относятся, например, ограждения, зеленые изгороди, трубопроводы. Описание этих объектов отличается от одиночных тем, что они характеризуются не одной точкой, а массивом точек. В остальном параметры объектов данного вида совпадают с единичными. Рассмотрим описание линейно протяженного объекта в IFC формате на примере трубопровода: #15=IFC3DPOINT((98.22,2.48,188.20)); #16=IFC3DPOINT((99.94,2.53,192.03)); #17=IFC3DPOINT((100.13,2.51,194.34)); #18=IFC3DPOINT((102.02,2.50,195.39)); #19=IFCLINEOBJECT(‘PROJECT’,(#15,#16,#17,#18),’ ‘); Параметры объекта: 1. State: INITIAL или PROJECT 2. координаты объекта массив точек 3. тип объекта ссылка на классификатор. Здесь, ‘ ‘ ссылка на классификатор Pipe line, взятая из Таблицы 11 OmniClass, классифицирующей объекты по функции PolygonObject Такие объекты моделируют замкнутые поверхности, такие как, например, лес и водоем. Они описываются так же, как и линейно протяженные объекты: состоянием, массивом точек и типом объекта. Помимо кода классификатора, отличие от линейных объектов состоит только в том, что эти объекты замкнутые. Ниже представлен пример описания леса в IFC формате: #20=IFC3DPOINT((110.30,2.45,225.32)); #21=IFC3DPOINT((115.59,2.52,224.65)); #22=IFC3DPOINT((112.43,2.48,226.32)); #23=IFC3DPOINT((114.31,2.52,221.43)); #24=IFC3DPOINT((114.30,2.49,226.50)); #25=IFC3DPOINT((113.90,2.50,224.37)); #26=IFCPOLYGONOBJECT(‘INITIAL’,(#20,#21,#22,#23,#24,#25),’ ‘); 19
Технология производства гнутых уголков и профилей
... кривизну и выпрямляя на оправке плоские участки профиля до получения требуемой формы поперечного сечения. По предлагаемому способу можно получать профили с размерами повышенной точности и стабильным по ... агрегаты, в состав которых входит оборудование для придания профилям требуемых свойств, например устройства для продольной и поперечной сварки, прессы или валковые устройства для пробивки отверстий ...
20 Параметры объекта: 1. State: INITIAL или PROJECT 2. координаты объекта массив точек 3. тип объекта ссылка на классификатор. Здесь, ‘ ‘ ссылка на классификатор Forest, взятая из Таблицы 12 OmniClass, классифицирующей объекты по форме Surface Поверхность представляет собой совокупность рассмотренных выше объектов: точечных, линейно протяженных и полигональных. Кроме массивов объектов, поверхность также должна иметь состояние: Initial или Project, как и остальные объекты группы. В отличии от других объектов, поверхность не имеет ссылки на классификатор. Ниже представлен пример описания поверхности, содержащей дорожный знак и лес: #13=IFC3DPOINT((100.13,2.48,204.93)); #14=IFCPOINTOBJECT(‘INITIAL’,#13,’ ‘); #20=IFC3DPOINT((110.30,2.45,225.32)); #21=IFC3DPOINT((115.59,2.52,224.65)); #22=IFC3DPOINT((112.43,2.48,226.32)); #23=IFC3DPOINT((114.31,2.52,221.43)); #24=IFC3DPOINT((114.30,2.49,226.50)); #25=IFC3DPOINT((113.90,2.50,224.37)); #26=IFCPOLYGONOBJECT(‘INITIAL’,(#20,#21,#22,#23,#24,#25),’ ‘); #27=IFCSURFACE(‘INITIAL’,(#14,#26)); Параметры объекта: 1. State: INITIAL или PROJECT 2. массив объектов, находящихся на данной поверхности 20
21 Для наглядности описание структуры прилегающих объектов представлено на диаграмме классов: Рис. 7. Диаграмма классов прилегающих объектов 2.2 Сложные линейно протяженные объекты Выше были рассмотрены и описаны классы простых объектов инфраструктуры, не требующих дальнейшей детализации в рамках отрасли. Теперь опишем более сложные линейно протяженные объекты дорожной отрасли. К ним относятся автомобильные дороги, железные дороги и так далее. Прежде всего стоит отметить, что ось линейно протяженного объекта в плане и в профиле позволяет описать существующий стандарт IFC Alignment. Однако очень важным аспектом при проектировании дорог является поперечный профиль объекта, который нельзя описать с помощью IFC4. 21
22 2.2.1 Поперечный профиль Поперечный профиль объекта это срез объекта в определенной точке. Для наглядности на рисунке показана схема дороги в плане. Отрезки, расположенные перпендикулярно оси дороги, как раз представляют собой эти срезы: Рис. 8. Схема автодороги в плане Сам поперечный профиль выглядит следующим образом: Рис. 9. Поперечный профиль дороги Как мы видим, дорога описывается не только осью, но и качественным составом: количеством полос движения, наличием и шириной обочин, кюветов и так далее. Значит поперечный профиль очень важен при проектировании дорог. Поэтому, кроме описания оси в плане и в профиле, дорогу необходимо описывать и в поперечном профиле. Для этого расширим существующий стандарт IFC Alignment. 22
Технический проект участка автомобильной дороги от пункта А до пункта Б
... слой плодородного грунта на участках строительства дороги; предусматривать снегозащитные и ... и воды. строительство автодорога полотно профиль 1. Общая часть 1.1 ... работы автомобилей. Особенно значительная роль автомобильного транспорта в освоении малонаселенных районов и новых сельскохозяйственных территорий, в разработке больших месторождений полезных ископаемых. В процессе выполнения проекта ...
23 Основное свойство каждого пикета трассы расстояние от начала оси, поэтому прежде всего включим его в описание поперечного профиля и назовем его Picket. Значением этого свойства является число типа Double. Как видно на Рис. 9. Поперечный профиль дороги поперечный профиль состоит из сегментов. Для простоты каждый сегмент представляет собой отрезок, который может быть объявлен как объект IfcLineSegment2D, описанный в IFC Alignment. Однако в дорожной отрасли каждый сегмент поперечного профиля имеет свой тип: полоса движения, обочина, кювет и так далее. Поэтому к существующим свойствам отрезков нужно добавить ссылку на классификатор, как это было сделано при описании простых точечных объектов. При выполнении разбивки трассы можно руководствоваться разными принципами: например, пикеты (срезы) на трассе могут располагаться на определенном расстоянии друг от друга. Однако на практике удобно отмечать срезы в ключевых точках: там, где меняются траектория оси и/или размеры сегментов поперечного профиля. Ниже показан фрагмент трассы, где пикеты расположены в ключевых точках: Рис. 10. Дорога в плане с ключевыми срезами Так как, кроме ключевых точек, могут понадобиться пикеты в других точках, при описании поперечного профиля необходим логический параметр Key. Если этот срез ключевой, значение параметра положительное, иначе отрицательное. Таким образом мы описали все свойства поперечного профиля. В ходе работы было найдено два варианта описания пикета: это связано со способами размещения 23
24 ссылки на классификатор каждого отрезка, входящего в профиль. Рассмотрим оба варианта с примерами Создание массива для кодов классификатора Первый и довольной простой вариант реализации помещение всех кодов классификатора в отдельный массив. Так, первый элемент массива будет соответствовать первому по счету отрезку, указанному в описании поперечного профиля, и так далее. Рассмотрим этот случай на примере: Пусть для простоты #13, #14, #15, #16 сегменты поперечного профиля (отрезки), описанные на основе стандарта IFC Alignment. Значит в массиве кодов классификатора будет содержаться 4 элемента. В данном случае при описании типа объекта не удастся использовать таблицы OmniClass, так как составляющие трассы специфические для данной отрасли объекты и таких кодов в таблицах нет. Вернемся к этому вопросу позже, а пока условно обозначим типы сегментов type1, type2, type3, type4. Тогда при описании поперечного профиля будем ссылаться на массив: #17=IFCTYPES( type1, type2, type3, type4 ); Пусть расстояние от начала оси трассы равно Также отметим, что данный поперечный профиль является ключевым. Таким образом, все параметры пикета учтены, описание поперечного профиля будет выглядеть следующим образом: #18=IFCCROSSECTION(205.49,( #13, #14, #15, #16),#17, key ); Плюсом такого варианта реализации является его наглядность, так как, даже не зная свойств каждого сегмента, легко понять, сколько отрезков в профиле и какого типа каждый из них. Однако этот способ имеет очевидный недостаток: при изменении количества сегментов профиля (например, при добавлении еще одной полосы движения) будет сложно синхронизировать информацию о типах сегментов, так как они описываются отдельно. Поэтому был выявлен еще один вариант реализации Изменение стандартного описания отрезка Второй способ описания отрезков профиля состоит в том, чтобы дополнить существующее стандартное описание IfcLineSegment2D, добавив свойство Type, значением которого является ссылка на классификатор, как и в предыдущем случае. Тогда в нашем примере описания поперечного профиля не будет массива IFCTYPES, а тип объекта будет описан наряду с другими свойствами отрезка. Это сократит объем описания, а главное позволит легче и быстрее изменять модель. Возвращаясь к примеру, описание поперечного профиля в данном случае будет выглядеть следующим образом: 24
25 #18=IFCCROSSECTION(205.49,( #13, #14, #15, #16), key ); Таким образом, был выбран второй вариант реализации описания поперечного профиля. На диаграмме ниже представлена модель описания поперечного профиля дороги, на диаграмме опущены несущественные на данном этапе атрибуты IFCLineSegment2D: Рис. 11. Диаграмма классов для поперечного профиля Полное описание линейно протяженного объекта На данном этапе мы уже описали поперечный профиль линейно протяженного объекта, значит можно наиболее полно описать сложный объект: для этого нужно описать объект в плане, в продольном профиле (модель данных для этого содержится в существующем IFC Alignment) и в поперечном профиле. На схеме показан пример трассы в трех видах (отображен только один из пикетов): Рис. 12. Модель дороги в плане 25
26 Рис. 13 Продольный профиль дороги Рис. 14. Поперечный профиль дороги Теперь, имея модель объекта в трех видах, можно в совокупности описать линейно протяженный объект, назовем его LinearObjectSurface. Пусть #20 объект в плане, #21 объект в продольном профиле, #22, #23, #24, #25, #26 продольные профили объекта. Тогда общее описание трассы будет выглядеть так: #27=IFCLINEAROBJECTSURFACE(#20,#21,( #22, #23, #24, #25, #26)); Для наглядности ниже представлена диаграмма классов для полного описания линейно протяженного объекта: Рис. 15. Диаграмма классов для полного описания дороги 26
27 3 Расширение классификатора OmniClass В ходе рассмотрения параметров поперечного профиля было отмечено, что таблицы классификатора OmniClass не содержат специфических для дорожной отрасли классов, таких как откос, кювет, разделительная полоса и так далее. Без этих классов нельзя будет указать типы сегментов профиля. Поэтому необходимо расширить существующую классификацию. 3.1 Исследование существующих типов Для начала нужно определить, какую таблицу расширять, как так существует множество таблиц, классифицирующих объекты инфраструктуры по разным признакам. Наиболее подходящими для рассматриваемой отрасли являются таблица 11, классифицирующая объекты по функции, и таблица 12, классифицирующая объекты по форме Типы объектов по функции В таблице 11 содержится класс Roadway, потомки которого различные виды дорог. Все подклассы представлены ниже: Табл. 2. Классификатор OmniClass, фрагмент таблицы 11 Несмотря на то что перечисленные классы соответствуют отрасли, сложно определить, от какого класса наследовать типы сегментов поперечного профиля. 27
28 3.1.2 Типы объектов по форме Рассмотрим теперь фрагмент таблицы 12, содержащую классификацию объектов по функции. Наиболее подходящий класс для описания дорог Pavement/Track, он и его потомки представлены ниже: Табл. 3. Классификатор OmniClass, фрагмент таблицы 12 Класс Pavement описывается как твердое покрытие на ровной поверхности, используемое, например, для дороги, шоссе, аэродрома, тротуара, автостоянки или другого объекта, используемого для транспортировки или хранения транспортных средств. Оно включает в себя все виды твердого покрытия, включая асфальт и бетон. Это описание не подходит для модели трассы, так как включает в себя только твердое покрытие, а именно бетон и асфальт, и не учитывает сегменты, состоящие из других материалов. Рассмотрев наиболее подходящие для отрасли классы OmniClass, мы выяснили, что их семантика не позволяет наследовать от них сегменты поперечного профиля дороги. Поэтому, рассматривая второй вариант, а именно таблицу 11 с классификацией объектов по функции, необходимо подняться на уровень выше (это класс Transportation Facility) и в нем создать отдельный класс для элементов поперечного профиля, назовем его Road Elements. 3.2 Добавление новых типов в классификатор Теперь необходимо выяснить, какие классы добавить в таблицу. Система IndorCAD/Road содержит набор линий, используемых в реальных проектах при описании поперечного профиля, поэтому будем использовать этот список для расширения таблицы. Типы линий представлены на рисунке ниже: 28
29 Табл. 4 Типы сегментов поперечного профиля в системе IndorCAD/Road Объединим все элементы откоса в один класс, в остальном сохраним иерархию, представленную в системе IndorCAD/Road. Имена линий отличаются от имен сегментов, которым они соответствуют, в расширении будут использованы имена сегментов, поэтому имена в нем будут не совпадать с приведенными выше. Кроме того, по аналогии с системой нумерации классов OmniClass присвоим каждому классу код классификатора. Так как класс Road Elements является потомком класса Transportation Facility, префикс для всех элементов Далее используем коды, которые еще не заняты в таблице. Таким образом, получим следующую таблицу: 29
30 Табл. 5. Расширение таблицы 11 классификатора OmniClass Так как созданная таблица расширяет классификатор OmniClass, исходный язык которого английский, необходимо перевести имя каждого элемента на английский язык. В результате таблица выглядит следующим образом: 30
31 Табл. 6. Расширение классификатора OmniClass на английском языке Таким образом, разработано расширение классификатора OmniClass, что позволит использовать новые типы для описания сегментов поперечного профиля дороги. 31
32 4 Расширение модуля импорта/экспорта данных системы IndorCAD Расширив стандарт IFC Alignment, необходимо внести изменения во внутренний обменный формат линейки продуктов компании ИндорСофт. Благодаря этому в системе IndorCAD можно будет использовать добавленные в стандарт типы объектов в новых проектах. Для этого должны быть расширены два файла: 1. Схема стандарта IFC4x1. Она создана компанией BuildingSMART, которая занимается разработкой стандартов IFC формата 2. Модуль IfcUtils, разработанный непосредственно компанией ИндорСофт для интерпретации описанной выше схемы IFC4x1. Перед тем как вносить изменения в схему и модуль, необходимо вновь перечислить сущности, расширяющие стандарт: IFC3DPOINT, точка в трехмерном пространстве IFCPOINTOBJECT, точечный прилегающий объект IFCLINEOBJECT, линейно протяженный прилегающий объект IFCPOLYGONOBJECT, площадной прилегающий объект IFCSURFACE, поверхность как совокупность прилегающих объектов IFCCROSSECTION, поперечный профиль дороги IFCLINEAROBJECTSURFACE, полное описание дороги а также добавлено новое опциональное свойство type для отрезка IfcLineSegment2D, описанного в стандарте Теперь можно приступать к расширению схемы и модуля. 4.1 Схема IFC4x1 Схема IFC4x1 представляет собой XML-подобный файл, в котором содержится описание всех типов и сущностей, используемых в строительной отрасли. Эта схема является официальным стандартом, разработанным и утвержденным, как и все стандарты IFC формата, компанией BuildingSMART. Ниже представлены фрагменты этой схемы: 32
33 Рис. 16. Фрагмент схемы IFC4x1 с описанием типов Рис. 17. Фрагмент схемы IFC4x1 с описанием сущностей На основании проекта расширения стандарта IFC Alignment все изменения были внесены в схему. Рассмотрим их подробнее Новые типы сущностей На основании созданных типов объектов схема была расширена описанием этих объектов и их свойств. Общую структуру описания сущности рассмотрим на примере трехмерной точки и площадного объекта: ENTITY Ifc3DPoint SUBTYPE OF (IfcCartesianPoint); Coordinates : LIST [3] OF IfcLengthMeasure; END_ENTITY; ENTITY IfcPolygonObject State : String; 33
34 Position : Array[3:?] of Ifc3DPoint; OmniClassClassifier : STRING; END_ENTITY Схема для описания сущности довольно лаконичная: после объявления названия объекта указываются Сущность, от которой он наследуется. В случае с трехмерной точкой это IfcCartesianPoint, так как она содержит необходимые для трехмерно точки параметры, однако размерность ее координат — нефиксированная величина. Нам же нужно, чтобы точка имела ровно три координаты, поэтому наследуем 3D точку от IfcCartesianPoint и изменяем размерность списка координат. Все свойства и типы их значений, в данном случае полигональный объект содержит массив трехмерных точек, состояние и код классификатора OmniClass. Остальные объекты расширения объявляются аналогично Новое свойство для отрезка Также нужно добавить новое свойство отрезка IfcLineSegment2D для качественного описания сегментов поперечного профиля дороги: это свойство — тип, значением которого является код классификатора. Ниже представлен новый вариант объявления данной сущности (жирным выделено новое свойство): ENTITY IfcLineSegment2D SUBTYPE OF (IfcCurveSegment2D); Type: OPTIONAL STRING; END_ENTITY; Стоит отметить, что это необязательное свойство отрезка, его предлагается использовать только при описании сегментов поперечного профиля дороги, а в остальных случаях опускать. 4.2 Модуль IfcUtils IfcUtils модуль для обмена данными, используемый программными продуктами компании ИндорСофт. Он необходим для: 1. импорта данных, то есть корректного чтения файлов в IFC формате для последующей обработки данных о проекте и использования полученной информации программным продуктом 2. экспорта данных, то есть записи информации о продукте, измененной программными средствами, в.ifc файл в таком же стандартном виде 34
35 Ниже представлена структура модуля IfcUtils, жирным выделен раздел, расширенный в ходе работы. Рис. 18. Структура модуля IfcUtils С помощью IfcProject происходит обмен данными между компонентами IndorCAD и IndorGIS, таким образом модуль позволяет использовать один.ifc файл на разных этапах жизненного цикла автодороги. Рис. 19. Связь модуля с другими компонентами системы Модуль IfcUtils опирается на стандартную схему IFC4x1, интерпретирует ее содержимое и позволяет создавать и описывать указанные в стандарте сущности. Данный модуль написан на языке Delphi, что упрощает процесс внесения изменений. На основании содержащихся в модуле процедурах создания и описаниях объектов были добавлены новые типы объектов и процедуры создания этих объектов Имена новых сущностей Имена новых типов сущностей необходимо добавить в модуль для его корректной интерпретации схемы IFC4x1, объявление всех имен представлено ниже: EntityNameAlignment3DPoint = ‘IFC3DPOINT’; EntityNameAlignmentPointObject = ‘IFCPOINTOBJECT’; EntityNameAlignmentLineObject = ‘IFCLINEOBJECT’; EntityNameAlignmentPolygonObject = ‘IFCPOLYGONOBJECT’; 35
36 EntityNameAlignmentSurface = ‘IFCSURFACE’; EntityNameAlignmentCrossection = ‘IFCCROSSECTION’; EntityNameAlignmentLinearObjectSurface = ‘IFCLINEAROBJECTSURFACE’; Процедуры создания новых сущностей процедуры создания новых типов сущностей. Все они имеют схожую структуру, поэтому рассмотрим для примера одну из них, а именно процедуру добавления поперечного профиля: procedure TIfcAlignmentWriter.AddCrossection(Picket: Double; Boolean; Segments: TArray of EntityNameLineSegment2D); Key: var SegmentGeometry: TIfcHandle; begin SegmentGeometry := Ifc.CreateInstanceByName(Model, EntityNameAlignmentCrossection); FillCommonCrossectionProperties(SegmentGeometry, Picket, Key, Segments); end; Общий вид процедуры создания новой сущности выглядит следующим образом: 1. объявляется процедура с указанием параметров, которыми являются свойства объектов, они были рассмотрены в предыдущих главах. 2. объявляется общая для всех сущностей переменная SegmentGeometry, являющаяся идентификатором объекта 3. в теле процедуры создается объект с указанием типа (в данном случае crossection) 4. вызывается процедура присвоения этому объекту свойств, указанных в качестве параметров на входе (для поперечного профиля это Picket, Key и Segments) Далее представлены сигнатуры остальных процедур добавления объектов: procedure TIfcAlignmentWriter.AddPointObject(State: String; OmniClassClassifier: String; Position: EntityNameAlignment3DPoint); procedure TIfcAlignmentWriter.AddLineObject(State: String; OmniClassClassifier: String; Position: TArray of EntityNameAlignment3DPoint); procedure TIfcAlignmentWriter.AddPolygonObject(State: String; OmniClassClassifier: String; Position: TArray of EntityNameAlignment3DPoint); procedure TIfcAlignmentWriter.AddSurface(State: String; PointObjects: TArray of EntityNameAlignmentPointObject; LineObjects: 36
37 TArray of EntityNameAlignmentLineObject; PolygonObjects: TArray of EntityNameAlignmentPolygonObject); procedure TIfcAlignmentWriter.AddLinearObjectSurface(HorizontalAlignment: EntityNameAlignment2DHorizontal; VerticalAlignment: EntityNameAlignment2DVertical; Crossections: TArray of EntityNameAlignmentCrossection); Процедуры присвоения свойств для новых сущностей В предыдущем пункте составляющей всех процедур создания объектов была процедура заполнения свойств этих объектов. До начала внесения изменений существовали такие функции для свойств разного рода кривых, которые имеют свойства, отличные от свойств новых сущностей. Поэтому было необходимо написать свои процедуры для каждой группы сущностей, рассмотренных в предыдущих главах: прилегающих объектов, поверхности, поперечного профиля и полного описания дороги. Они так же выглядят аналогично друг другу, поэтому рассмотрим для примера одну из них, а именно процедуру заполнения свойств прилегающего объекта (она одинакова для всех трех типов прилегающих объектов, что очень удобно): procedure TIfcAlignmentWriter.FillCommonUtilityObjectProperties(const SegmentGeometry: TIfcHandle; const State: String; OmniClassClassifier: String; Position: TArray of EntityNameAlignment3DPoint); begin Ifc.PutAdbAttrByName(SegmentGeometry, ‘State’, State); Ifc.PutAdbAttrByName(SegmentGeometry, ‘OmniClassClassifier’, OmniClassClassifier); Ifc.PutAdbAttrByName(SegmentGeometry, ‘Position’, Position); end; Заполнение свойств сущностей происходит путем добавления идентификатору SegmentGeometry новых параметров и их имен (в нашем случае параметры и имена совпадают) Добавление нового свойства для отрезка Также для качественного описания поперечного профиля линейно протяженного объекта было добавлено еще одно свойство для отрезка: его тип. Значение этого свойства код классификатора OmniClass. Теперь сигнатура данной процедуры выглядит так (новый параметр выделен жирным): procedure TIfcAlignmentWriter.AddHorizontalLineSegment(const StartPoint: TModelPoint; StartDirection, SegmentLength: Double; OmniClassClassifier: String); 37
38 Благодаря этому параметру, теперь каждый отрезок имеет семантику и можно качественно описать сегменты поперечного профиля дороги. Таким образом, в схеме стандарта IFC4x1 и в модуле импорта/экспорта данных системы IndorCAD был успешно реализован предложенный проект расширения стандарта IFC Alignment. 38
39 Заключение В ходе работы были поставлены и выполнены следующие задачи: Ознакомиться с BIM технологиями и IFC форматом Выявить недостатки существующего стандарта IFC Alignment для дорожной отрасли Расширить стандарт IFC Alignment Внедрить изменения в модуль импорта/экспорта данных для системы IndorCAD Результаты исследований оформить в виде статьи и доложить о них на международной конференции Существенными результатами Выпускной квалификационной работы являются: Расширенный модуль обмена данными, встроенный в систему IndorCAD Статья, содержащая подготовленный проект расширения стандарта IFC Alignment и доклад для международной конференции, которые поспособствуют развитию BIM технологий Таким образом, все поставленные задачи были выполнены, а цель работы достигнута. 39
40 Список использованных источников и литературы 1. Скворцов А.В. BIM для дорожной отрасли: что-то новое или мы этим уже занимаемся? // САПР и ГИС (2).
С OmniClass: a strategy for classifying the built environment [Electronic resource] // OmniClass. URL: 3. IFC Industry Foundation Classes [Electronic resource] // IFC Wiki. URL: 4. IFC Overview summary [Electronic resource] // BuildingSMART International Limited. URL: 5. Summary of IFC releases [Electronic resource] // BuildingSMART International Limited. URL: 6. IFC Alignment 1.0: public review [Electronic resource] // BuildingSMART International Limited. URL: 7. IFC4x1 Alignment Extension : Annex E [Electronic resource] // BuildingSMART International Limited. URL: 8. IfcLineSegment2D [Electronic resource] // BuildingSMART International Limited. URL: clinesegment2d.htm/. 9. IfcCircularArcSegment2D [Electronic resource] // BuildingSMART International Limited. URL: ccirculararcsegment2d.htm/. 10. IfcClothoidalArcSegment2D [Electronic resource] // BuildingSMART International Limited. URL: cclothoidalarcsegment2d.htm/. 40
41
