CC BY
71
УДК 69:004.652
А.С. Павлов, Г.Г. Малыха, О.В. Игнатьев*, Е.Н. Куликова
ФГБОУ ВПО «МГСУ», *ФГБОУ ВПО «РУДН»
УНИФИЦИРОВАННЫЙ ФОРМАТ ПРЕДСТАВЛЕНИЯ ДАННЫХ В АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ
Обозначены проблемы передачи данных между САПР различного назначения. Сделан вывод о том, что в программное обеспечение, используемое в строительном проектировании и производстве, необходимо внедрять протокол формата STEP, предусмотренный международным стандартом ISO 1030.
Ключевые слова: строительство, САПР, системы обработки данных, программное обеспечение для САПР, информационное обеспечение для САПР
Рассмотрим функции ядра интегрированных информационных систем (ИИС), которые обеспечивают обмен данными между отдельными элементами, входящими в систему. Эти функции выполняются подсистемой ядра ИИС, ответственной за обеспечение связности содержания информационных объектов. Элементами системы являются серверы, сетевые шлюзы и автоматизированные рабочие места исполнителей. Для обмена информацией между участниками строительного процесса ядро ИИС предоставляет функции коммуникационного строительного канала.
Такая информационная сеть позволяет выполнять как обычный обмен информацией, так и специфические функции для соблюдения особых требований в строительстве. Например, коммуникационный канал рассматривается как дополнительная функция для распределенной обработки нескольких копий одного и того же строительного документа в различных точках информационной сети, а также служит для предоставления в сети комплектной актуальной строительной документации.
При разработке концепции коммуникационного обмена информацией в строительстве должен учитываться особый характер строительной информации: большой объем документации, коллективность принятия решения, частые изменения документации в ходе работ и т.д.
Основной задачей, которая решается при унификации передачи данных, является обеспечение связности содержания информационных объектов. Это является основой построения соответствующей подсистемы ядра ИИС.
Поскольку в международном строительном проекте могут применяться самые различные системы автоматизации проектирования (САПР), необходимо обеспечить передачу информации от одного элемента ИИС другому с минимальными потерями информации. К сожалению, в большинстве случаев обменные форматы передают только графическую информацию, не касаясь ее содержания. Так, распространенный формат DXF, разработанный Autodesk, поддерживает передачу графических примитивов, шрифтов, стилей, видов, а в последних версиях — информации об объемных телах. Такой формат может быть использован для передачи чертежа в окончательном варианте, когда его требуется только напечатать и передать на стройку. Для некоторых предметных областей применялся формат IGES (Intermediate Graphics Exchange Standard).
Однако для многих строительных САПР информационные объекты имеют значительный объем внутренней, не графической информации, которую также необходимо хранить и передавать. В частности, к ней относится информация о материале и
© Павлов А.С., Малыха Г.Г., Игнатьев О.В., Куликова Е.Н., 2012
211
ВЕСТНИК 3/2012
структуре тел, о примененных покрытиях, об использованных типовых элементах, о способе изготовления и сборки элементов и т.п.
Например, для арматурного чертежа необходима информация о классе арматуры, ее диаметре, радиусе и форме изгиба крюков, количестве стержней одной позиции, марке сеток, форме закладных деталей и т.п. Естественно, передать эту информацию только с помощью внешнего вида нельзя.
Значительные трудности представляю также распространенные в строительных чертежах приемы символического изображения деталей и даже крупных узлов: окон, дверей, лестниц и т.п. Символическое или реалистическое изображение зависит от масштаба чертежа, проекции, стадии чертежа и т.п. При этом графические форматы могут передать только внешние атрибуты символического изображения и не передают его содержания.
Представим, что чертеж А, содержащий внутреннюю смысловую информацию, передается, например, от программы проектирования конструкций другой системе проектирования (архитектурной), а затем должен быть возвращен обратно с изменениями в виде чертежа В. При преобразовании чертежа А во внутреннее представление второй системы смысловая информация чертежа А, как правило, безвозвратно теряется, так как другая система не распознает ее и в лучшем случае просто уничтожает, а в худшем — трактует в непредсказуемом смысле.
Внутреннюю информацию могут передавать только некоторые специальные форматы, разработанные для обмена информацией между версиями одного программного продукта, например, EXC программы unicad. Но они, во-первых, не могут передавать информацию от более поздних версий к более ранним, и, во-вторых, не могут быть использованы для передачи информации между разнородными системами, так как существенно учитывают особенности одной системы.
Для текстовой информации наиболее близко к решению упомянутой задачи стоит формат RTF (Rich Text Format), разработанный для линии программных продуктов Microsoft Word. Однако при его применении также иногда возникают коллизии при передаче файлов к более ранним версиям продукта.
Рассмотрим некоторые другие универсальные форматы.
Протокол передачи гипертекста HTTP (Hypertext Transport Protocol) — отрытый от пользователя протокол Интернет, отвечающий за доставку данных в сети Web. Этот протокол делает возможным использование адресов URL и гиперссылок для получения текста, графики, звука и других данных в цифровом виде с Web-серверов.
Формат GIF (Graphics Interchange Format) — это растровый формат графических файлов. Формат GIF включает в себя два отдельных формата, GIF 87 и GIF 89a, которые предназначены для передачи прозрачности и чередования (поэтапная загрузка изображения). Файлы GIF хорошо подходят для эмблем, значков и рисунков. Так как формат ограничивается 256 цветами, он не слишком хорошо подходит для фотографий.
Формат JPEG (Joint Photographic Experts Group) — это растровый формат изображения, предусмотренный в большинстве средств просмотра Web. Этот формат лучше других подходит для записи фотоизображений, так как позволяет использовать неограниченное число цветов. Кроме того, его процедура сжатия предназначена специально для обработки фотографий. Сжатие может быть менее эффективным при работе с графикой или с изображениями, содержащими большие участки одного цвета.
Для прослушивания звукового сопровождения пользователем должна быть предусмотрена работа с файлами используемого формата записи звука. В частности, применяются файлы звукозаписи форматов WAV, MID, AU, AIF, RMI, SND и MP2 (MPEG audio).
В результате проведенного анализа установлено, что ни один из применяемых обменных форматов чертежей САПР или иных форматов данных не учитывает всего многообразия данных, которые необходимо передавать по коммуникационному каналу. В связи с этим предлагается применить для унификации передачи данных протокол формата STEP, предусмотренный международным стандартом ISO 1030.
Стандарт ISO 10303 STEP (STandard for the Exchange of Product model data) — один из первых в семействе специализированных стандартов безбумажной технологии. STEP определяет «нейтральный» формат представления данных о продукте в виде информационной модели. Данные о продукте включают в себя состав и конфигурацию продукта, геометрические модели разных типов, административные данные, специальные данные.
Интегрированная модель продукта обеспечивает информацией множество процессов, протекающих в ходе жизненного цикла строительного объекта: обоснование, проектирование, возведение, пусконаладочные работы, ввод в эксплуатацию, освоение, реконструкцию, ликвидацию.
Стандарт ISO 10303 включает в себя 8 разделов, тесно связанных друг с другом, каждый из разделов, в свою очередь, состоит из томов. Перечень разделов включает в себя методы описания; стандартные решения (способы применения); структуру и методологию проверки на совместимость; общие интегрированные ресурсы; прикладные интегрированные ресурсы; прикладные протоколы; набор абстрактных тестов; элементы для конкретных приложений.
По сравнению с IGES стандарт STEP охватывает гораздо больший набор предметных областей. Он поддерживает большое количество типов данных, что позволяет выполнить формальное описание типов данных и их автоматизированную обработку.
Множество томов STEP можно разделить на тома, обеспечивающие инструмент описания предметных областей и тома, описывающие конкретные области. К основным относятся тома, содержащие прикладные протоколы, т.е. описания предметных областей. В остальных томах изложены средства, служащие для создания прикладных протоколов, моделей и для обмена данными о моделях, проверки соответствия прикладных систем стандарту. Эти средства соответственно представляют собой методы описания и ресурсы, методы реализации, методы тестирования и наборы тестов.
Все данные в STEP описываются на специальном объектно-ориентированном языке EXPRESS, напоминающем язык программирования. Доступ к EXPRESS-дан-ным может быть обеспечен с помощью специально описанных в стандарте методов. Корректность EXPRESS-данных можно проверить согласно тестам. С помощью EXPRESS-данных описываются некоторые смысловые конструкции — базовые типы, из которых, в свою очередь складываются информационные модели предметных областей — прикладные протоколы.
Язык EXPRESS предназначен для описания модели мира на концептуальном уровне. При этом глобальное описание разбито на предметные области — схемы. Схема (SCHEMA) является самым верхним уровнем описания информационной модели. Собственно информационная модель состоит из связанных между собой схем. Модель создается в независимом от реализации виде (Application Reference Model).
Прикладной протокол (AP, Application Protocol) — это схема, описывающая некоторую предметную область. Прикладной протокол включается в стандарт как один из томов стандарта. Так, для передачи графической двумерной информации чертежей используется протокол AP 201 Explicit draughting.
Схема состоит из набора элементов, который может включать в себя объекты (Entity), типы (Type), константы (Constant), правила (Rule), функции (Function) и про-
ВЕСТНИК 3/2012
цедуры (Procedure), необходимые для проверки правил и для вычисления значений производных атрибутов. Имена объектов, констант, функций, процедур, правил и типов должны быть уникальны в пределах данной схемы.
В свою очередь, объект может включать в себя атрибуты (Attribute), константы, правила, типы и переменные (Variable). Функции и процедуры могут содержать атрибуты, константы, параметры (Parameter) и переменные.
Одним из основных понятий EXPRESS является Объект (Entity), который представляет из себя информационный объект как совокупность атрибутов и методов. Каждый объект определяется набором его атрибутов. Объект может быть подтипом другого объекта, при этом он наследует атрибуты родительского объекта (т.е. того объекта, подтипом которого является). Помимо унаследованных, этот объект может иметь и свои собственные атрибуты. В определении объекта приводятся только собственные атрибуты объекта. Наследуемые атрибуты в определении самого объекта не приводятся. Вложенность подтипов не ограничена.
Атрибут (Attribute) — это свойство объекта, присущее объектам данного типа. Набор атрибутов для объектов каждого типа фиксирован и задается при определении объекта. Объекты разных типов могут иметь совпадающие имена атрибутов.
В настоящее время Технический комитет ISO разрабатывает классификационную схему основных понятий для строительства «BCCMT100», которая может быть положена в основу обменного формата ИИС. Схема содержит верхние уровни понятийного аппарата и может быть впоследствии дополнена. Некоторые системы САПР для промышленности (IMAN, Mechanical Desktop, ProEngineer, SolidWorks и др.) уже создают переходные модули для записи документов в формате STEP. Переходные модули являются программной основой системы обеспечения связности содержания информационных объектов в ИИС.
Для передачи данных в формате STEP используется так называемый обменный файл. Для создания обменного файла применяется автоматическая генерация, выполняемая с помощью специальных программных средств — STEP-TOOLS. Для подготовки модели вручную существует специальное расширение языка Express — Express-I, предназначенное для генерации экземпляров объектов и присвоения значений атрибутам экземпляров объектов.
Обменный файл предназначен для передачи данных между различными прикладными системами, совместимыми с ISO-10303 STEP. Обменный файл является текстовым и независим от конкретного программного обеспечения и используемых платформ. Формат обменного файла регламентирован стандартом ISO-10303, что гарантирует его совместимость с любым программным обеспечением, совместимым со стандартом STEP.
Это позволяет использовать обменный файл для связи не интегрированных приложений STEP, использующих одинаковые или интероперабельные между собой схемы.
Кроме реализации стандарта в виде текстового обменного файла имеется и реализация в виде базы данных. Такой метод реализации получил название SDAI (Standard Data Access Interface). SDAI определен в нескольких томах стандарта.
Стандартный интерфейс SDAI ориентирован на использование технологии динамических сетей для построения моделей STEP. Динамическая сеть предполагает существование модели в виде однородных элементарных экземпляров объектов. На физическом уровне экземпляры объектов поддерживаются одним механизмом. Каждый экземпляр объекта состоит из трех компонент:
набора значений атрибутов, характеризующих этот объект; идентификатора экземпляра объекта, описывающего объекты данного типа; идентификатора ассоциации, в которую входит данный экземпляр объекта.
Таким образом, разрабатываемый в настоящее время международный стандарт STEP является самым перспективным средством для обеспечения связности содержания данных в пределах интегрированной информационной системы международного строительного проекта.
Моделирование документооборота чертежей. Основная часть всего потока информации для строительных объектов — строительные чертежи. Далее описана концепция обеспечения согласованности информационных объектов, которая затрагивает в основном документооборот чертежной продукции как наиболее сложных информационных объектов ИИС. Однако она может быть применена и для текстовой проектной или коммерческой информации. Поэтому целесообразно отнести систему обеспечения согласованности информационных объектов к подсистемам ядра ИИС.
Коммуникационная сеть может быть представлена схемой узлов со связями, по которым осуществляется обмен данными. В качестве узлов могут быть рассмотрены как фирмы, так и отдельные исполнители в проектных группах, или же менеджеры, представляющие проектные группы. Узлы могут быть подразделены следующим образом:
Источник — узел, разрабатывающий проектные решения в виде оригиналов чертежей; только сам узел может вносить в эту документацию окончательные изменения и передавать ее к исполнению. Он несет ответственность за окончательный согласованный вариант проектного решения;
Цель (или Целевой узел) — узел, получающий чертеж для целенаправленной оценки и последующей обработки; он имеет право передачи своего отзыва (замечания) в Источник.
Очевидно, что различные узлы могут попеременно выполнять различные функции, т.е. быть в отношении одного вида данных Источником, а в отношении другого вида данных Целевым узлом. Однако следует отметить, что в отношении конкретного вида данных (чертежа) всегда присутствуют один Источник и один или несколько Целевых узлов. В каждом конкретном проекте возможно существование нескольких Источников и нескольких Целевых узлов, но, тем не менее, при выпуске конкретной документации эти отношения жестко определены.
При этом нужно отметить, что в общей коммуникационной схеме проекта могут существовать узлы, не являющиеся формально Источником, так как они не разрабатывают оригиналов чертежей, но дают определенные обязательные указания (заказчик, экспертиза и т.д.). Однако информация, приходящая от этих узлов, может быть приравнена к Источнику и непосредственно вносится в Целевом узле в чертежную документацию.
Необходимым условием при определении коммуникационной схемы проекта является когерентность информационного базиса, заложенного в чертежах для различных участников строительства. Для обеспечения этого условия необходимо:
жесткое присвоение приоритетов Источника и Целевого узла, участвующих в проекте;
обеспечение своевременной передачи данных всем задействованным участникам при внесении изменений в документацию;
ведение полной базы данных чертежей и их изменений;
возможность централизованного управления модулями узла.
Каждый чертеж рассматривается как объект, состоящий из одного оригинала и многочисленных копий, которые сохраняются в различных точках информационной сети. В этих узлах они могут либо только просто использоваться (например, на строительной площадке), либо дорабатываться (например, у специалистов по внутренним инженерным системам). Чертежи возникают в ходе непрерывного про-
вестник 3/2012
цесса проектирования, который характерен частыми изменениями существующих чертежей, добавлением новых чертежей и аннулированием (удалением) ранее существующих. В ходе такого процесса возникают связи между оригиналом и копиями чертежа, а также связи между разными чертежами. Коммуникационный строительный канал должен предоставить такие инструменты, которые позволят обеспечить устойчивость таких связей для участников строительного процесса.
Концепция предусматривает, что для одного чертежа имеется один оригинал и несколько копий, которые сохранены в разных точках информационной сети. Каждый участник может использовать свою копию чертежа. При соответствующей авторизации ему разрешается также изменять и сам чертеж. При этом в одной из точек сети возникает разность между оригиналом чертежа и копией: связность чертежа в канале в этом случае нарушена. Для восстановления связности предлагается следующий подход: сравнение содержимого чертежа происходит между оригиналом и измененной копией, после чего источник оригинала информирует все другие станции копии об изменениях. Станции копии решают сами, в какое время они перенесут появившиеся изменения оригинала в свои чертежи. Сравнение содержимого чертежей между станциями копий, таким образом, не происходит.
Поскольку изменение чертежа обычно невелико по объему, то нет смысла пересылать по линиям связи весь чертеж: достаточно выделить измененные элементы (чертеж-разность) и переслать их, а затем объединить. Это существенно экономит ресурсы сетей, однако требует разработки специальных способов осуществления логических операций над чертежами: вычитания и объединения.
В соответствии с рассмотренным выше характером информации, которой обмениваются Источник и Целевой узел можно выделить следующие типы файлов формата STEP:
оригинал (первая версия) чертежа передаваемого Источником в Целевые узлы;
фрагмент чертежа с изменениями, которые вносит Источник;
фрагмент чертежа с изменениями, которые предлагает Источнику какой-либо Целевой узел;
протокол отказа, который Источник направляет в Целевой узел с указанием причин отказа в изменении.
Каждый из перечисленных типов файлов должен иметь разный статус и соответствующий маркер, который определяет порядок срабатывания программ. При этом важно исключить возможность случайных ошибок или несанкционированных ситуаций, которые могут нарушить работу коммуникационного канала.
Библиографический список
1. ГусаковА.А. Системотехника строительства. М. : Стройиздат, 1993. 368 с.
2. Малыха Г.Г. Научно-методологические основы автоматизации проектирования в международных строительных проектах : дисс. ... докт. техн. наук. М. : МГСУ, 1999. 299 с.
3. Павлов А.С. Научные основы передачи информации и распознавания объектов в системах строительного проектирования : дисс. ... докт. техн. наук. М. : МГСУ, 2003. 357 с.
4. Вайнштейн М.С. Методология многофункциональной автоматизации поэлементно-инвариантного проектирования зданий и сооружений : дисс. ... докт. техн. наук. М. : МГСУ, 2005. 377 с.
Поступила в редакцию в марте 2012 г.
Об авторах: Павлов Александр Сергеевич — доктор технических наук, главный научный сотрудник НИЦ «ИСАПСИТ», ФГБОУ ВПО «Московский государственный строительный университет», 129337, г. Москва, Ярославское шоссе, д. 26, [email protected];
Малыха Галина Геннадьевна — доктор технических наук, профессор, заведующая кафедрой строительной информатики, ФГБОУ ВПО «Московский государственный строительный университет», 129337, г. Москва, Ярославское шоссе, д. 26, [email protected];
Игнатьев Олег Владимирович — доктор технических наук, заведующий кафедрой информационных технологий в образовании, ФГБОУ ВПО «Российский университет дружбы народов», 117198, г. Москва, ул. Миклухо-Маклая, д. 6, [email protected];
Куликова Екатерина Николаевна — кандидат технических наук, доцент кафедры информационных систем, технологий и автоматизации в строительстве, ФГБОУ ВПО «Московский государственный строительный университет», 129337, г Москва, Ярославское шоссе, д. 26, [email protected].
Для цитирования: Унифицированный формат представления данных в автоматизированных системах / А.С. Павлов, Г.Г. Малыха, О.В. Игнатьев, Е.Н. Куликова // Вестник МГСУ 2012. № 3. С. 211—217.
A.S. Pavlov, G.G. Malykha, O.V. Ignat'ev, E.N. Kulikova
UNIFIED DATA FORMAT IN CAD SYSTEMS
The main problem of data transmission unification is assurance of content consistency for information objects. Data consistency is necessary for development of a subsystem in integrated information systems. The analysis completed by the authors demonstrates that there is no data exchange format in CAD systems covering the whole variety of data to be transmitted via the communication channel. Therefore, STEP protocol (Standard for) (provided by international standard ISO 1030) is proposed for data transmission unification. The protocol determines a "neutral" data format realized through the product information model. This model incorporates the elements and the configuration of the product, different geometrical models, administrative and special data.
All data are described in STEP using object-oriented language EXPRESS similar to the programming language. Access to EXPRESS data is provided by standard methods. EXPRESS language is designated for the conceptual description of the model. Global description is split into subject domains, or schemes. The information model represents interconnected schemes.
A scheme consists of a set of elements that may include entities, types, constants, rules, functions and procedures.
Key words: construction, CAD system, data processing systems, software and dataware for CAD systems.
References
1. Gusakov A.A. Sistemotekhnika stroitel'stva [System Engineering of Construction]. Moscow, Stroyizdat Publ., 1993, 368 p.
2. Malykha G.G. Nauchno-metodologicheskie osnovy avtomatizatsii proektirovaniya v mezhdun-arodnykh stroitel'nykh proektakh [Scientific and Methodological Foundations of Design Automation in International Construction Projects]. Moscow, Moscow State University of Civil Engineering, 1999, 299 p.
3. Pavlov A.S. Nauchnye osnovy peredachi informatsii i raspoznavaniya ob"ektov v sistemakh stroitel'nogo proektirovaniya [Scientific Principles of Information Transmission and Objects Identification in Computer Aided Design Systems]. Moscow, Moscow State University of Civil Engineering, 2003, 357 p.
4. Vaynshteyn M.S. Metodologiya mnogofunktsional'noy avtomatizatsii poelementno-invariantnogo proektirovaniya zdaniy i sooruzheniy [Methodology of Multifunctional Automation of Per-element and Invariant Design of Structures and Buildings]. Moscow, Moscow State University of Civil Engineering, 2005, 377 p.
About the authors: Pavlov Aleksandr Sergeevich, Moscow State University of Civil Engineering (MSUCE), 26 Yaroslavskoe shosse, Moscow, 129337, Russian Federation; [email protected];
Malykha Galina Gennad'evna, Moscow State University of Civil Engineering (MSUCE), 26 Yaroslavskoe shosse, Moscow, 129337, Russian Federation; [email protected];
Ignat'ev Oleg Vladimirovich, Moscow State University of Civil Engineering (MSUCE), 26 Yaroslavskoe shosse, Moscow, 129337, Russian Federation; [email protected];
Kulikova Ekaterina Nikolaevna, Moscow State University of Civil Engineering (MSUCE), 26 Yaroslavskoe shosse, Moscow, 129337, Russian Federation; [email protected].
For citation: Pavlov A.S., Malykha G.G., Ignat'ev O.V., Kulikova E.N. Unifitsirovannyy format pred-stavleniya dannykh v avtomatizirovannykh sistemakh. [Unified data format in cad systems]. Vestnik MGSU [Proceedings of Moscow State University of Civil Engineering], 2012, no. 3, pp. 211—217.
