ИСМ-06-2:
10. а) Виды обмена информацией
Организация прямого обмена информацией между приложениями
Это называется «прямой интерфейс». Когда число приложений растет, картина станет еще более ужасающей. Тем не менее, сейчас многие пары приложений имеют прямые интерфейсы.
Обмен информацией между приложениями с применением унифицированного представления данных
Это – применение «унифицированного представления данных», т.е. такого представления, которое достаточно распространено, имеет подробное описание, и с этим представлением может работать большое количество приложений. Естественно, что для того, чтобы приложение могло работать с определенным представлением, должна быть реализована специальная функция конвертации (преобразования) данных. Создание такой функции – непростая задача. Стоимость такой специальной опции может быть сопоставима со стоимостью самого приложения.
Представление данных – это комбинация физического, логического и концептуального уровней представления. Часто представление называют «формат», например, формат dxf, формат rtf и т.д. Можно так и говорить, понимая при этом, что кроме формата имеются ввиду структура и смысл.
Форматы обмена данных можно классифицировать по нескольким признакам:
Символьные и двоичные. Данные в символьном формате, по статистике, занимает на 20% больше места, и обрабатываются в 5 раз медленнее. Несмотря на это, символьные форматы более распространены, поскольку они обеспечивают высокую степень независимости от аппаратной и программной платформ. Например, мы свободно передавали данные между VAX, ЕС1060 и СМ-2 (Hewlett-Packard).
Корпоративные, национальные и международные. Некоторые из форматов являются стандартом и утверждены или национальными или международными органами стандартизации. Утверждение формата в качестве стандарта имеет большое значение – стандарт пересматривается примерно раз в пять лет, и это является гарантией того, что не нужно переделывать конверторы при частых изменениях формата.
Форматы функционального плана и форматы, передающие конечную модель. Что такое форматы функционального плана: в прежние времена существовали библиотеки стандартных функций: Графор, GKS, PHIGS. Можно было записать набор обращений к стандартным функциям, который приводит к генерации каких-то данных, передать исходный текст партнеру по обмену. Партнер вставляет исходный текст в свою программу, компилирует его, собирает, запускает на исполнение, и получает у себя необходимые данные. Сейчас такими форматами практически не пользуются, т.к. конечные пользователи работают с готовыми программными приложениями.
О каких конкретных форматах мы говорим. В Word, например, есть пункт «сохранить как файл rtf». В любом САПР в пункте «сохранить как» или «экспорт» есть набор форматов: dxf, iges, step, stl, vrml и некоторые другие.
Поэтому в описании любого формата большое место уделяется концептуальному уровню, т.е. описанию того, какой смысл какое поле имеет. В большинстве форматов такое описание дается в виде текста, понимаемого человеком, но не очень понятного для программы. Из-за этого форматы имеют ограниченный набор понятий, которые можно с их помощью передавать. Очень часто это – геометрия, в которой набор понятий невелик и давно устоялся.
Это относится к самым распространенным форматам:
dxf – формат фирмы AutoDesk. Изначально он создавался для того, чтобы можно было делать в AutoCAD иллюстрации и вставлять их в текстовые документы. Потом назначение формата стало расширяться, и сейчас он часто используется для обмена между CAD-системами.
iges – национальный стандарт США, который применяется во всем мире. В формат iges постоянно добавляются новые понятия, но процесс этот очень медленный из-за того, что описание новых понятий добавляются только в виде текста на обычном языке.
stl – это узкоспециализированный формат, предназначенный для загрузки в специальные стереолитографические машины, которые иногда называют «объемные принтеры». Геометрия детали в этом формате передается в виде большого числа мелких плоских граней.
vda-fs – специальный геометрический формат, разработанный германской ассоциацией автомобилестроителей. Принципы примерно те же самые, что и в stl.
vrml – специальный формат, предназначенный для просмотра объемных изображений с помощью Internet-браузеров.
Но сейчас задачи обмена данными между приложениями гораздо грандиознее. Нужно передавать уже не только одну геометрию, но и данные о составе изделия, технологические данные, расчетные модели, информацию об электронных компонентах, данные о процессе разработки и утверждения и т.д. Многие из этих проблем до сих пор не решены.
В условиях реального производства часто между разработчиком изделия (конструкторским бюро) и разработчиком технологии (технологическим бюро цеха) получается передавать через компьютер только геометрическую информацию. Все прочее идет на бумаге, хотя большинство конструкторов и технологов уже работают на компьютерах. Получается так, что огромные объемы данных, которые конструктор уже ввел в CAD-систему, технолог должен вводить в компьютер заново. Из-за этого тратятся большие ресурсы, снижается надежность процесса – все-таки человек ошибается чаще, чем компьютер.
Для решения этой коммуникационной проблемы необходима возможность преобразовывать данные технических требований одной системы в форму, понятную для других систем, и наоборот. Чтобы облегчить преобразование и не разрабатывать программы-конверторы для всех возможных пар САПР, было предложено несколько стандартных форматов для храпения данных технических требований.
В
IGES был первым стандартным форматом обмена данными, разработанным для нужд передачи данных технических требований между различными САПР. Ранние версии IGES были неявным образом ориентированы на CAD/CAM-системы 1970-х и начала 1980-х гг., то есть главным образом на обмен чертежами. В более поздних версиях спектр типов данных, подлежащих обмену, был расширен. Например, версия 2.0 поддерживала обмен данными анализа по методу конечных элементов и данными печатных плат, в версии 3.0 были расширены возможности пользовательских макрокоманд, играющих важную роль при обмене стандартными библиотеками деталей, в версии 4.0 была введена поддержка C-Rep, а в версии 5.0 появилась обработка данных структуры B-Rep.
IGES-файл состоит из шести разделов, которые должны идти в следующем порядке: Flag (Флаг, необязательный раздел), Start (Начало), Global (Глобальные данные). Directory Entry, или DE (Запись в каталоге), Parameter Data, или PD (Параметрические данные) и Terminate (Конец).
При использовании препроцессоров и постпроцессоров с нейтральным форматом IGES на практике возникают следующие проблемы. Во-первых, внутренний способ представления элемента в системе может отличаться от того, как элемент представляется в IGES. Например, дуга окружности в какой-то системе может быть определена через центр, радиус и начальный и конечный углы, но в IGES она определяется через центр, начальную точку и конечную точку. Таким образом, специализированный IGES-конвертор должен выполнить преобразование с использованием параметрического уравнения дуги. Такое преобразование должно выполняться дважды (при прямой и обратной конвертации), и каждый раз значения параметров дуги искажаются из-за ошибок усечения и округления. Вторая проблема более серьезна: она возникает, когда элемент не поддерживается явно, и поэтому его необходимо преобразовать в ближайший по форме доступный элемент. Эта проблема часто имеет место при обмене данными между двумя системами через IGES-файл, если конверторы этих систем поддерживают разные версии IGES. Типичный пример — потеря символьной информации в случае, когда одна из двух систем использует более старую версию IGES, не поддерживающую макросы.
Формат DXF
Формат DXF (Drawing interchange Format — формат обмена чертежами) изначально разрабатывался для того, чтобы предоставить пользователям гибкость в управлении данными и преобразовании чертежей программы AutoCAD и форматы файлов, которые могли читаться и использоваться другими САПР. Из-за популярности AutoCAD формат DXF стал фактическим стандартом обмена файлами CAD-чертежей почти для всех САПР. На самом деле почти в каждой из появляющихся новых САПР имеется транслятор в формат DXF и обратно.
DXF-файл — это текстовый ASCII-файл, состоящий из пяти разделов: Header (Заголовок), Table (Таблица), Block (Блок), Entity (Элемент) и Terminate (Конец). В разделе Header описывается среда AutoCAD, в которой был создан DXF-файл. В разделе Table содержится информация о типах линий, слоях, стилях текста и видах, которые могут быть определены на чертеже. В разделе Block содержится список графических элементов, определенных как группа. Конкретные данные по каждому элементу хранятся в соответствующем разделе Entity, который следует сразу за разделом Block. Раздел Entity — это главный раздел DXF-файла, в котором описываются все элементы, присутствующие на чертеже.
Аналогично тому как это происходило с IGES файлами, с появлением новых версий AutoCAD список возможных элементов DXF-файлов расширялся. DXF-файл, созданный более поздней версией AutoCAD, не может быть прочитан другими системами, использующими более старые версии формата DXF.
Формат STEP
Форматы IGES и DXF были разработаны для обмена данными технических требований, а не данными о продукте. Под данными о продукте мы понимаем данные, относящиеся ко всему жизненному циклу продукта (например, проектирование, производство, контроль качества, испытания и поддержка). Хотя спецификации IGES и DXF были расширены с целью включения некоторых из этих данных, информации, содержащейся в этих файлах, по существу недостаточно для описания всего жизненного цикла продукта. Вследствие этого и США в 1983 году началась разработка нового стандарта под названием PDES (Product Data Exchange Specification — спецификация для обмена данными о продуктах). Основной упор в PDES делался не на обмен данными технических требований, а на то, чтобы исключить человеческое присутствие из обмена данными о продукте. Иначе говоря, целью PDES было устранить потребность в инженерных чертежах и других бумажных документах при обмене информацией о различных фазах жизненного цикла продукта между сходными или различающимися САПР. Между тем в июле
В основе разработки STEP лежат следующие принципы.
STEP разрабатывается рядом комитетов и рабочих групп, занимающихся разными частями стандарта. Эти части группируются по методам описания, интегрированным информационным ресурсам, прикладным протоколам, методам реализации и методологией согласования.
Сегодня STEP привлекает к себе повышенное внимание, так как ожидается, что он войдет в систему стандартов технологий CALS (Computer-aided Acquisition and Logistics Support — Непрерывные поставки и информационная поддержка жизненного цикла продукции) как стандарт обмена данными о продуктах. Цель инициативы CALS, автором которой является Министерство обороны США, — компьютеризация процесса формирования требований, заказа, эксплуатации, поддержки и обслуживания систем вооружений, используемых в армии США. Основное внимание эта инициатива уделяет заданию форматов, которые будут использоваться для хранения и обмена компьютерными данными. Хотя CALS создавалась для военных целей, она становится промышленным стандартом хранения и обмена компьютерными данными в организации.
© ism-06-2.ru