1.2 Многообразие методов информационной совместимости

1.3 Проблемы информационной совместимости различных программных средств

1.4 Выводы

Глава 2. Методология информационной совместимости программных средств автоматизации

2.1 Подходы к преобразованию данных в CAD/CAM-систем

2.2 Реализация и преимущества предлагаемого метода

2.3 Объектно-ориентированная среда программирования CASCADE

2.4 Структуризация начальных этапов проектирования изделий

2.5 Выводы

Глава 3. Вопросы разработки программно-математического обеспечения метода информационной совместимости

3.1 Внутренние структуры данных

3.2 Внутренний формат представления данных

Глава 1. Современное состояние проблемы информационной совместимости программных средств автоматизации начальных этапов проектирования изделий

В первой главе проводится обзор состояния вопроса, анализ существующих методов и актуальность решаемой задачи. Рассматриваются аспекты влияния разнообразных форматов на функционирование CAD/CAM систем.

Стандарт ISO 10303 STEP (Standard for Exchange of Product data) является ключевым стандартом среди информационных стандартов. Для некоторых из стандартов STEP определяет единые используемые во всех этих стандартах средства описания данных и общую идеологию, для других стандартов (SGML, EDIFACT) должна быть обеспечена совместимость со стандартом STEP как с ключевым стандартом [38, 39, 40].

Формат STEP интегрирует понятия в предметной области «промышленное производство продукции», то есть представляет единую информационную модель этих понятий в виде, формализованном на уровне спецификаций объектно-ориентированного языка Express. STEP обеспечивает единое представление информации модели изделия в форме группы ресурсов, которые вместе поддерживают полное и однозначное определение изделия.

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

Форматы IGES и DXF были разработаны для обмена данными технических требований, а не данными о продукте. Под данными о продукте понимаются данные, относящиеся ко всему жизненному циклу продукта (например, проектирование, производство, контроль качества, испытания и поддержка). Хотя спецификации IDES и DXF были расширены с целью включения некоторых из этих данных, информации, содержащейся в этих файлах, по существу недостаточно для описания всего жизненного цикла продукта. Вследствие этого в США в 1983 году началась разработка нового стандарта под названием PDES (Product Data Exchange Specification -- спецификация для обмена данными о продуктах). Основной упор в PDES делался не на обмен данными технических требований, а на то, чтобы исключить человеческое присутствие из обмена данными о продукте. Иначе говоря, целью PDES было устранить потребность в инженерных чертежах и других бумажных документах при обмене информацией о различных фазах жизненного цикла продукта между сходными или различающимися САПР. Между тем в июле 1984 г. в Международной организации по стандартизации (ISO) были образованы технический комитет ТС 184 (Системы промышленной автоматизации) и его подкомитет SC4 (Внешнее представление данных о модели продукта) для установления единого международного стандарта обмена данными о модели продукта -- STEP (STandard for Exchange of Product model data). Цели PDES и STEP были идентичны, поэтому в июне 1985 г. Управляющий комитет IGES решил, что интересы США в программе STEP должен представлять стандарт PDES. В результате значение акронима PDES поменяли на «обмен данными о продукте с использованием STEP» (Product Data Exchange using STEP), чтобы подчеркнуть идентичность целей PDES и STEP.

В основе разработки STEP лежат следующие принципы:

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

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

* Для определения структуры данных должен использоваться формальный язык. Спецификации IGES и DXF описывают формат физического файла, в котором хранятся все геометрические и прочие данные. В STEP данные описываются на языке EXPRESS, а затем результат преобразовывается в физический файл. Таким образом, можно избежать неоднозначностей при интерпретации данных о продукте, извлеченных из файла.

STEP разрабатывается рядом комитетов и рабочих групп, занимающихся разными частями стандарта. Эти части группируются по методам описания, интегрированным информационным ресурсам, прикладным протоколам, методам реализации и методологией согласования (рис. 1.6 и рис. 1.7). Статус каждой части показан рядом с ее номером. Статус обозначается буквами от «О» (предварительная стадия ISO) до «I» (международный стандарт -- высшая стадия разработки и принятия стандартов). Части, обозначенные буквами «Е», «F» (проект международного стандарта) и «I», считаются находящимися на достаточно высоком уровне для того, чтобы позволить разработчикам приступить к их реализации.

Рисунок 1.6. Архитектура STEP

Группа методов описания образует фундамент STEP. Она включает часть 1 «Обзор», которая содержит также определения, являющиеся в STEP универсальными. Принадлежащая той же группе часть 11 «Справочное руководство по языку EXPRESS» описывает язык моделирования данных, который используется в STEP. Части, относящиеся к группе методов описания, имеют номера от 1 до 9.

На следующем уровне находится группа интегрированных информационных ресурсов -- части, содержащие фактическое описание моделей данных STEP. Эти модели данных являются «кирпичиками» STEP. Интегрированные информационные ресурсы включают обобщенные ресурсы, прикладные ресурсы и конструкции, интерпретируемые приложением.

Рисунок 1.7. Архитектура STEP

Интегрированные обобщенные ресурсы -- это элементы, которые используются по необходимости прикладными протоколами. Номера частей, относящихся к обобщенным ресурсам, начинаются с 40 и используются всей гаммой прикладных протоколов STEP.

Интегрированные прикладные ресурсы содержат элементы, имеющие несколько больший объем контекста, чем обобщенные элементы. Номера частей, относящихся к прикладным ресурсам, начинаются со 100. Части с номерами от 500 -- это конструкции, интерпретируемые приложением. Они представляют собой многократно используемые группы информационных ресурсов, облегчающие представление одной и той же семантики в различных прикладных протоколах.

На верхнем уровне иерархии STEP находятся более сложные модели данных, используемые для описания конкретных данных о продукте. Эти части называются прикладными протоколами и описывают не только то, какие данные должны использоваться при описании продукта, но и то, как эти данные должны использоваться в модели. Прикладные протоколы используют интегрированные информационные ресурсы в четко очерченных сочетаниях и конфигурациях для представления определенной модели данных или некоторой фазы жизненного Цикла продукта. Прикладные протоколы нумеруются, начиная с 200. В настоящее время используются такие прикладные протоколы, как «Явное черчение» (201) и «Проектирование с управлением конфигурацией» (203).

Группа методов реализации STEP, части в которой нумеруются с 20, описывает соответствие между формальными спецификациями STEP и представлением, используемым для реализации STEP. Еруппа методологии проверки соответствия, части в которой нумеруются с 30, предоставляет информацию о методах проверки соответствия программных продуктов стандарту STEP, дает указания по созданию абстрактных испытательных пакетов и описывает задачи испытательных лабораторий. Часть 31, описывающая методологию выполнения проверки соответствия, принята в качестве международного стандарта (см. рис. 1.6). Стандарты STEP уникальны в том отношении, что они делают упор на испытания и содержат в себе описания методов испытаний.

Группа частей с номерами от 300 (абстрактные испытательные пакеты), состоит из данных и критериев, используемых для проверки соответствия программного продукта, реализующего стандарт STEP, его прикладному протоколу. Номера, присваиваемые абстрактным испытательным пакетам, превышают номера прикладных протоколов ровно на 100. Таким образом, абстрактный испытательный пакет с номером 303 относится к прикладному протоколу 203. Более подробную информацию о STEP можно получить на сайте http://www. nist. gov/sc4.

Сегодня STEP привлекает к себе повышенное внимание, так как ожидается, что он войдет в систему стандартов технологий CALS (Computer-aided Acquisition and Logistics Support -- Непрерывные поставки и информационная поддержка жизненного цикла продукции) как стандарт обмена данными о продуктах. Цель инициативы CALS, автором которой является Министерство обороны США, -- компьютеризация процесса формирования требований, заказа, эксплуатации, поддержки и обслуживания систем вооружений, используемых в армии США. Основное внимание эта инициатива уделяет заданию форматов, которые будут использоваться для хранения и обмена компьютерными данными. Хотя CALS создавалась для военных целей, она становится промышленным стандартом хранения и обмена компьютерными данными в организации.

Стандарт VDA FS

VDA FS появился в связи с тем, что существовала задача организовать обмен графическими данными между разработчиками автомобилей и станкостроительными предприятиями [37]. Тем самым последние могли выпускать необходимое оборудование и оснастку для автостроительных компаний, а кроме того закладывать необходимое представление графической информации в программное обеспечение своего оборудования. Также в качестве дополнительного требования была выдвинута простота работы с VDA FS и простота его реализации внутри автоматизированных систем CAD, САМ и CAD/CAM. Разработка осуществлялась в отделах CAD/CAM - систем таких автомобильных фирм, как «BMW», «VW», «Opel», «Porsche», «Daimler - Benz» и на станкостроительных фирмах или фирмах связанных со станкостроением «Hella», «Bosch». Сами разработчики надеялись, что за счёт своей простоты употребления формат VDA FS получит мировое распространение.

Стандарт DXF

DXF является обменном форматом, используемом в системе AutoCAD фирмы AutoDesk, впервые появившейся на рынке в 1982 г. [7]. С тех пор система получила необычайно широкое распространение. Она успешно применяется в различных областях приложений: машиностроении, архитектуре, электронике. DXF - это основной формат для обмена чертежами между AutoCAD и другими системами. Формат внутренних файлов системы - файлов чертежей (DWG-файлы) является конфиденциальной информацией фирмы AutoDesk Inc.

Структура файла DXF эквивалентна структуре файла чертежа (DWG), имеющего двоичный формат. Файлы обмена описаниями чертежей содержат почти всю информацию, необходимую для воспроизведения чертежа. Это основной источник документированной графической информации. Одним необходимым элементом, отсутствующим в DXF файлах, является описание графических символов и шрифтов. Эти описания могут быть найдены в файлах графических символов и шрифтов.

1.2 Многообразие методов информационной совместимости

До момента заполнения рынка системами проектирования вопрос совместимости с уже существующими системами не рассматривался. Каждая новая система стремится занять лидирующее положение на рынке.

Однако методика вытеснения конкурентов с рынка себя не оправдала и встал вопрос об унификации (стандартизации) обменных форматов данных.

Для создания единого стандарта в международной организации ИСО был организован специальный комитет. В его задачу входила разработка унифицированного подхода к созданию форматов хранения данных путем описания их объектно-ориентированным языком Express [38].

Существует несколько направлений стандарта (протоколы), которые описывают соответствующие прикладные области. Большинство протоколов STEP (рис.1.8) находятся в состоянии разработки [36].

Рисунок 1.8. Состояние завершенности разработки различных протоколов STEP

Основные производители систем не спешат переходить на новые стандарты из-за нежелания отказываться от существующих наработок и отсутствием окончательного варианта стандарта.

Можно выделить несколько уровней информационной совместимости программных средств:

* возможность хранения в системе документов (файлов), созданных в других приложениях, или ссылок на них. Это минимальный уровень интеграции, поддерживаемый большинством систем;

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

* передача информации о параметрах модели в систему с синхронизацией данных в автоматическом или ручном режиме;

* корректная работа с компонентными (многофайловыми) документами и с документами, содержащими ссылки на другие документы.

Очевидно, что различные программные продукты обеспечивают разный уровень информационной совместимости.

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

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

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

Краткий перечень основных критериев сравнения систем по основным признакам:

* поддержка неограниченной глубины уровней структуры изделия неограниченной сложности;

* возможности многовариантного проектирования. Возможности хранения вариантов, не вошедших в основной проект;

* работа с исполнениями и конфигурациями изделий. Возможности формирования обозначения исполнений в автоматическом режиме в соответствии с требованиями ЕСКД;

* возможность создания проекта на основе существующего;

* наличие средств визуального сравнения двух и более проектов;

* возможности получения информации о вхождениях объекта в проекты;

* возможности классификации узлов, деталей и документов. Возможность формировать обозначение из классификатора или в автоматическом режиме. Возможность формирования обозначений в соответствии с требованиями ЕСКД, СПДС и другими отечественными стандартами. Возможности контроля неповторяемости обозначений;

* наличие функций учета изменений;

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

* возможности по ведению истории создания изделия;

* наличие средств для формирования специализированных режимов представления информации о проекте для различных групп сотрудников.

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

1.3 Проблемы информационной совместимости различных программных средств

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

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

В действительности же проблема заключается в том, что, используя какую-либо одну систему (будь то PDM, PDM II или PLM), в настоящее время не представляется возможным решить все задачи поддержки информации о продукте на протяжении всего его жизненного цикла. Поэтому поставщики систем предлагают теперь заказчикам не один продукт, а несколько систем, связанных между собой. И если убрать маркетинговые изыскания, то вместо одного продукта заказчику предлагается комплект из нескольких систем, связанных между собой (например, CAD + САМ + CAE + САР + PDM + ERP). За счет предложения более широкого спектра интегрированных решений снижаются затраты на передачу данных между приложениями. Минусы обычно состоят в том, что внедрение такого комплекса может потребовать отказа от уже существующих на предприятии систем (что приведет к дополнительным затратам), а заказчик окажется более тесно связанным с единственным поставщиком выбранного решения.

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

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

Казалось бы, несложная задача, но, как показывает практика, в настоящее время она не решена на подавляющем большинстве отечественных предприятий. Более того, даже между конструкторской и технологической подсистемами почти всегда существует разрыв в потоке данных (не считая подготовки программ для станков с ЧПУ). Следовательно, одним из первых шагов для обеспечения информационной совместимости программных средств должна стать организация единых справочников в рамках предприятия. Здесь возможны два пути решения:

1.обеспечить интеграцию данных из различных конструкторской и технологической систем подготовки производства через интерфейсы к различным системам;

2.построить единую САПР на базе решения одного производителя.

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

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

Внедрение систем в масштабах предприятия всегда затрагивает интересы различных групп сотрудников, интеграция же в рамках единой системы конструкторских, технологических и управленческих данных неизбежно приводит к конфликтам интересов. Как показывает практика, прежде всего конфликты вызывают распределение прав доступа к информации между службами (проблема «кто главный») и перевод данных, ранее являвшихся достоянием отдельных сотрудников, на корпоративный уровень (проблема «незаменимых людей»).

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

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

Определяющее значение приобретают стандартные решения. Так, ряд отечественных разработчиков решений по управлению документами уже включили в свои продукты поддержку систем управления документацией (ODMA), активно развивается поддержка стандарта STEP, а некоторые разработчики автоматизированных систем заявили об ориентации на соблюдение требований международных стандартов (WfMC). Сразу несколько компаний в том или ином объеме включили в свои продукты поддержку классификатора ЕСКД. Выдвинут ряд предложений по созданию единого интерфейса между отечественными системами TDM/PDM. Разработаны интерфейсы между популярными системами САПР, PDM и ERP, причем как самими разработчиками этих систем, так и их партнерами.

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

1.4 Выводы

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

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

2) В части информационного обеспечения следует создавать максимально обширные базы данных существующих форматов обмена данными.

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

Глава 2. Методология информационной совместимости программных средств автоматизации

2.1 Подходы к преобразованию данных в CAD/CAM-систем