Особенности наследования информации в задачах интеграции систем технической подготовки производства

Сложность семантической интеграции корпоративных приложений требует совместного применения принципов объектно-ориентированного моделирования, онтологического проектирования и современных подходов к формализации контекста. Технология объектного моделирования сегодня трактуется как универсальный способ представления знаний о предметной области (ПрО). «Ядро современных информационных технологий составляют объектные методы, искусственный интеллект и модели данных, причём рассматриваемые не по отдельности, а в неразрывной связи» [1]. В статье предпринята попытка объектно- ориентированного описания механизма передачи данных от конструкторской 3D-модели к 3D-модели, используемой технологом при технологической подготовке производства.

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

Аналогично тому, как семантика слов и предложений естественного языка зависят от контекста их применения, передача информации между подсистемами цифрового PLM -пространства ( Product Lifecycle Management - прикладное программное обеспечение для управления ЖЦ продукции) предприятия происходит под воздействием внешнего информационного поля. Игнорирование этого факта приводит к потере или искажению актуальных значений передаваемых данных. Информационное поле предприятия представляет собой внешнюю среду по отношению к интегрируемым приложениям систем автоматизированного проектирования (САПР или CAD, Сomputer-Aided Design ). Эта среда имеет иерархическую структуру, состоящую из вложенных друг в друга информационных контекстов, ближайшими из которых к задачам интеграции являются ПрО этапов ЖЦ изделия. При передаче данных между корпоративными информационными системами необходимо учитывать изменение значений инженерных данных под влиянием этих контекстов.

1    Проблемы интеграции корпоративной информации

Основные аспекты проблемы интеграции информационных систем рассмотрены в публикации [2]. К ним относятся архитектура системы интеграции, уровень взаимодействия данных (физический, логический, семантический), неоднородность источников информации, общая модель данных, способ представления интегрированных данных. Эти аспекты и связанные с ними задачи имеют непосредственное отношение к интеграции САПР и иных корпоративных приложений. При этом область САПР имеет некоторые особенности интеграции. Построение сквозных инженерных проектов предполагает создание между этапами ЖЦ изделия ассоциативных связей по типу «родитель-потомок». Сквозной проект — это когда изменения, внесённые в начальную стадию проекта, автоматически отображаются в последующих стадиях без дублирования информации в ручном режиме. Процессы обмена информацией между корпоративными приложениями следует рассматривать не просто как передачу данных, а как наследование информации, которое характеризуется наличием в этих процессах «родителей» и «потомков» и ассоциативных связей между ними, что делает возможным повторное использование проектных решений.

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

С учётом этих двух обстоятельств в процессе интеграции корпоративной информации можно выделить четыре стадии преобразования данных: считывание информации из приложения-источника, преобразование формата данных через эталонную модель, создание ассоциативных связей, корректировка значений данных с учётом влияния информационных контекстов. Этим стадиям можно сопоставить четыре проблемы интеграции (рисунок 1), расположив их на четырёх уровнях.

Рисунок 1 - Уровни проблемы интеграции корпоративных данных

Недоступность полной информации от приложений САПР является первым препятствием в реализации сквозных инженерных проектов. Под «полной информацией» здесь понимается исчерпывающий набор данных, необходимый для реализации корпоративной системы интеграции в условиях конкретного предприятия. Форматы коммерческих систем, как правило, являются закрытыми. Для обмена 3В-моделями CAD-системы предлагают конвертацию данных через нейтральные форматы, наиболее развитым из которых является протокол STEP (STandardfor Exchange of Product model data), применяемый в рамках технологии CALS (Continuous Acquisition and Lifecycle Support). Несмотря на развитие STEP, в обменные форматы выводится только геометрическая информация и, в лучшем случае, общие метаданные, например, наименование детали, разработчик, обозначение материала. Структура дерева построения модели, параметры формообразующих операций, свойства материала, как правило, остаются в статусе «секретной» информации, хотя соответствующие спецификации STEP для передачи этих данных давно разработаны. Причина такого положения кроется в рыночной конкуренции, под давлением которой разработчики САПР вынуждены создавать искусственные препятствия для интеграции собственных продуктов с продуктами других производителей САПР. Извлечь дополнительную информацию об изделии можно только с использованием API (Application Programming Interface) CAD-системы и только в том объёме, который позволяет функциональность API. Извлекая данные через API, приходится работать с неоднородными источниками данных, связанными с 3В-моделью, например, свойства материала могут находиться в справочнике материалов, к которому требуется отдельный доступ через API [3]. Существенный недостаток нейтральных форматов — это потеря точности геометрических данных, если приложения САПР работают на разных математических ядрах.

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

• ■    игнорирование возможностей нейтральных форматов для передачи полной информации всеми разработчиками коммерческих САПР (обменные форматы используются на практике главным образом для передачи геометрии);

• ■    нейтральные форматы имеют жёсткую структуру, фиксированные синтаксис и семантику, но всегда будут существовать объекты, процессы и наборы данных, не совпадающие полностью с актуальными спецификациями этих форматов;

• ■    нейтральные форматы плохо предназначены для сжатия информации и передачи по сетям Интернет, а также визуализации в HTML -браузерах.

Перспективный путь решения данной проблемы — это разработка интеллектуальных конверторов данных, принимающих в качестве обменного протокола онтологические спецификации ПрО на базе стандарта XML ( extensible Markup Language ). Причём эти онтологии могут иметь различный уровень детализации ПрО и различную таксономию понятий в зависимости от требований конкретной системы интеграции. Поскольку разнообразие корпоративных приложений весьма обширно, процесс разработки подобных конверторов должен быть автоматизирован с использованием новейших тенденций в области автоматизации программирования на основе онтологического подхода [4].

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

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

Проблема семантики и контекста последовательно рассматривалась при анализе текстов в работах [5-9] и др. Современные исследователи выдвигают проблемы формализации контекста цифровой информации [10], потребности в интеграции и интероперабельности [11], обработки больших данных [12]. Простейшим способом формализации цифрового контекста является добавление к описанию предмета сопроводительной информации (метаданных). Более сложные подходы предлагают использование онтологий верхнего уровня, исчисления предикатов, теории математических категорий, дескрипционной логики и их расширений.

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

2    UML-представление наследования конструкторской информации

К разряду систем технологической подготовки производства относятся САПР ТП ( CAPP -системы, Computer-Aided Process Planning ) и системы автоматизированной разработки управляющих программ для станков с числовым программным управлением (ЧПУ) или CAM -системы ( Computer-Aided Manufacturing ). Эти системы в качестве исходных данных могут принимать как 2D-, так и 3D-информацию, полученную из систем конструкторского проектирования CAD . Но для целей построения сквозных конструкторско-технологических проектов целесообразнее использовать твёрдотельную модель, поскольку она несёт в себе не только полную информацию о геометрии объекта, но и допускает больше возможностей для включения в свой состав дополнительных метаданных.

Особенности наследования конструкторской информации можно представить на примере интеграции CAM -системы для платформы АСКОН с её базовым продуктом КОМПАС-3D. Автором статьи разрабатывается CAM -система с использованием среды программирования Visual Studio C++, API КОМПАС-3D и функций геометрического ядра C3D [13]. В настоящее время CAM -система включает в себя два модуля: CAM -приложение для токарной двухкоординатной обработки [14] и CAM -модуль для трёхосевого фрезерования [15]. CAM -система полностью интегрирована в пользовательский интерфейс КОМПАС-3D и использует в качестве источника конструкторской информации CAD -модель, созданную в КОМПАС-3D. Траектории обработки, которые генерирует CAM -система, ассоциативно связаны с опорными объектами обрабатываемой детали и автоматически перестраиваются при изменении положения и размеров элементов детали.

При моделировании технологического процесса рекомендуется работать не напрямую с конструкторской 3D-моделью, а с её ассоциативной копией, которая называется моделью технолога (рисунок 2). Это связано с тем, что технолог вынужден вносить изменения в 3D-модель обрабатываемой детали: необходимо поставить локальную систему координат, задающую направление осей станка; может потребоваться создать дополнительные построения на модели, например, сечение детали для удобства выбора внутренних поверхностей при программировании токарной обработки и др. Чтобы отделить изменения, сделанные технологом, и не загромождать конструкторскую модель технологическими данными, рекомендуется использовать копию исходной модели. Для построения сквозных конструкторско-технологических проектов 3D-модель технолога должна зависеть от модели конструктора, т.е. являться не просто копией файла конструкторской модели, а её ассоциативной копией. Ассоциативная связь в данном случае означает, что изменения, внесённые конструктором в собственную модель, автоматически передаются в модель технолога, т.е. модель конструктора выступает в качестве «родителя» для технологической модели. В общем случае модель технолога может зависеть от нескольких конструкторских моделей (например, при групповой обработке нескольких деталей на одной операции) и даже от параметров заготовки.

Удобным средством для описания подобных зависимостей является унифицированный язык моделирования UML ( Unified Modeling Language ), который позволяет построить наглядное графическое представление внутреннего состава класса и его отношений с другими классами.

Если рассматривать состав 3D-модели с точки зрения структуры данных, используемых для моделирования обработки в CAM -системе, то в списке атрибутов класса 3D-модели можно выделить пять элементов детали (рисунок 2):

• ■    геометрию ( geometry );

• ■    параметрические переменные, объявляемые пользователем ( variables );

• ■    аннотации, т.е. обозначения размеров, допусков, шероховатостей ( annotation );

• ■    свойства материала ( material);

• ■    метаданные, т.е. сопроводительную текстовую и числовую информацию ( metadata ).

Рисунок 2 - Схема передачи информации от модели конструктора к модели технолога

Геометрия модели представляет собой математическое описание поверхностей и структуру топологических связей между гранями, рёбрами и вершинами модели в граничном представлении Brep ( Boundary Representation ). Геометрия технологической 3В-модели может включать в себя два вида геометрии: ассоциативную геометрию, переданную из модели конструктора, и собственную геометрию, добавленную технологом (эта геометрия может отсутствовать, если технологу нет необходимости во вспомогательных построениях). Ассоциативная геометрия представляет собой полную копию Brep -представления конструкторской модели без истории её построения. Изменить её технолог не может, но может дополнить собственными построениями на технологической модели, например, сделать технологические отверстия с помощью операции вырезания или создать операцию прямого редактирования поверхностей. Ассоциативная геометрия и геометрия конструкторской модели находятся в отношении наследования, благодаря чему модель технолога обладает свойствами модели конструктора. Изменения, сделанные конструктором в геометрии изделия, автоматически передаются в ассоциативную геометрию технологической модели. Поскольку геометрия любой 3В-модели в системе КОМПАС-3В доступна в качестве ассоциативной геометрии для других моделей, то атрибут geometry следует считать открытым (публичным) членом класса 3D-model.

Отличительной особенностью рассматриваемой CAM-системы является поддержка многоуровневой конструкторско-технологической параметризации [16], которая позволяет на стороне пользователей автоматизировать некоторые действия, например, расчёт режимов резания, создание собственных траекторий и упростить разработку постпроцессоров с помощью специальных макросов и параметрических формул. В рамках конструкторско-технологической параметризации можно использовать атрибуты variables, annotation, material и metadata. Извлечение негеометрической информации из технологической модели через API КОМПАС-3В подробно описано в статье [3]. Ни один из этих атрибутов не наследуется из конструкторской модели через команду «Копировать объекты». Доступ открыт только к атрибуту variables, который рассматривается как открытый член класса 3D-model, остальные считаются закрытыми (приватными) членами класса 3D-model.

Атрибут material содержит строку с обозначением материала, а свойства материала хранятся в справочнике «Материалы и сортаменты» системы КОМПАС-3В. Поэтому свойства материала выносятся в отдельный класс, связанный с классом 3В-модели отношением агрегации. Аналогичным образом можно представить переменные, аннотации и метаданные отдельными классами, связанными с классом 3В-модели отношением композиции. Чтобы не загромождать диаграммы классов, эти атрибуты представлены упрощённо в виде списков в составе класса 3D-model.

На рисунке 3 показаны два варианта наследования информации от конструктора к технологу. Как видно из этого рисунка штатными средствами КОМПАС-3В из конструкторской модели наследуются только два атрибута: geometry и variables . Аннотации, материал и метаданные технолог вынужден переопределять в собственной модели. Аннотации и метаданные могут не совпадать с исходной моделью (конструкторские обозначения могут быть излишни для технологической модели, а технолог может использовать свои аннотации), тогда материал, наименование и обозначение детали технологу приходится дублировать вручную. Открыть доступ ко всем элементам модели можно только через программный интерфейс приложения API CAD -системы, если реализовать в составе функций CAM -системы команду, аналогичную команде «Копировать объекты», но с расширенными возможностями передачи состава 3В-модели. При этом необходимо принимать во внимание возможные коллизии при наследовании информации от нескольких конструкторских моделей. Например, если исходные модели имеют разный материал, то в этом случае материал технологической модели должен назначить технолог.

Design model 2

* geometry

+ vanablies; list

• -    annotation ; list

• -    material; string - metadata; list

Design model 3

+ geometry

+ vanablies ; list

• -    annotation ^: list

• -    material^: string

• -    metadata; list

' Design model + geometry + vanablies : list - annotation ■ list - material ■ string - metadata; list

а)

Technology model

+ geometry

Material

+ HB

. + HRC

+ density

+ vanablies; list

• -    annotation : list

• -    material ; siring ■

• -    metadata ■ list

б)

a) - вариант с единственной исходной моделью; б) - вариант, когда технологическая 3D-модель наследует данные от двух и более конструкторских моделей (этот вариант соответствует групповому методу обработки)

Рисунок 3 - Варианты наследования данных от конструкторских моделей к модели технолога

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

(рисунок 4 б ). В этом примере реализована схема наследования информации, приведённая на рисунке 2, когда и заготовка, и технологическая модель одновременно зависят от конструкторской модели. Заготовка содержит ссылочные переменные на размеры исходной детали и собственные переменные. Топология 3D-модели заготовки не является фиксированной, например, при достижении минимальной разницы между диаметрами ступеней детали выключается построение соответствующих ступеней заготовки. На рисунке 4б поверхности заготовки показаны прозрачными, сквозь которые видна ассоциативная геометрия, полученная от исходной детали. При изменении формы исходной модели перестраивается и модель технолога, и заготовка, а вслед за ними и ассоциативные траектории обработки, сгенерированные CAM -системой по технологической модели (рисунок 5). Модель заготовки CAM -система перестраивает автоматически через API КОМПАС-3В перед расчётом траекторий обработки.

а)

б)

Рисунок 4 - Деталь в форме диска ( а ) и ассоциативно связанная с ней заготовка ( б)

Рисунок 5 - Автоматическое перестроение ассоциативных траекторий обработки

Возможна ситуация, когда технологическая модель наследует данные одновременно и от конструкторской модели, и от заготовки. Обычно передавать геометрию от заготовки в технологическую модель нецелесообразно, потому что геометрия заготовки закроет геометрию детали. Наследовать информацию из заготовки имеет смысл только в том случае, если для технологических расчётов требуется получить какие-либо переменные заготовки или пара- метры аннотаций. На рисунке 6 показаны два варианта наследования данных с использованием модели заготовки. В каждом варианте вместо одной конструкторской модели может присутствовать несколько исходных моделей (такой случай является объединением рисунков 3б и 6).

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

а)                                                           б)

a) – вариант, когда модель заготовки не зависит от конструкторской модели; б) – вариант, когда модель заготовки зависит от CAD-модели

Рисунок 6 – Варианты наследования данных с использованием модели заготовки

Рисунок 7 – Пример ромбовидного наследования данных от детали к заготовке

Модель штамповки, показанная на рисунке 4 б, имеет плоскость разъёма перпендикулярно оси детали. Путём изменения значений параметрических переменных деталь (рисунок 4 а ) может трансформироваться из диска в вал, у которого длина может в несколько раз превышать наибольший диаметр. Но для вала требуется другой вид штамповки, у которой плоскость разъёма должна проходить через ось детали.

Таким образом, для данной детали требуется два варианта штамповки (модели заготовки). Алгоритмы их трёхмерного моделирования различны и должны быть реализованы в двух разных параметризованных 3D-моделях. Для создания сквозного конструкторско-технологического проекта необходимо иметь одну модель заготовки, подключенную к CAM -системе. Эта общая 3D-модель заготовки должна наследовать ассоциативную геометрию от обоих вариантов штамповки и содержать в своём дереве построения две операции копирования объектов, из которых только одна должна быть включена в расчёт в зависимости от соотношения габаритов детали. Такая схема представляет собой классический пример ромбовидного наследования (рисунок 7). Габаритные размеры детали могут быть унаследованы как от первого варианта, так и от второго варианта заготовки с помощью ссылочных переменных. В этих переменных указывается путь к файлу родительской 3D-модели, поэтому ссылки обеспечивают однозначный доступ к одноименным атрибутам класса 3D-модели.

UML -представление позволяет наглядно описать различные варианты наследования информации в задачах интеграции CAM -систем с системами конструкторского проектирования. Эти схемы наследования необходимо учитывать при реализации сквозных конструкторско -технологических проектов с высоким уровнем ассоциативности данных.

3    PLM-контекст цифрового пространства предприятия

В рамках концепции Индустрия 5.0 ЖЦ изделия представляет собой пространство интеграции Интернета знаний и Интернета вещей. При этом этапы конструирования, технологической подготовки и планирования производства существуют в виртуальном мире, что делает возможным применение к ним Интернета знаний, а процессы изготовления продукта используют средства производства, рассматриваемые как вещи, что ведёт к возможности совместного применения Интернета знаний и Интернета вещей [17].

С точки зрения системного подхода любые этапы и стадии ЖЦ изделия следует рассматривать как элементы ( E) его структуры. Элементы, взаимодействуя друг с другом путём обмена данными, находятся под влиянием всего информационного пространства предприятия и его неявных семантических полей. Например, конструктор, учитывая явные функциональные требования заказчика, изложенные в техническом задании, находится под влиянием собственного опыта, интуиции и культуры производства, принятой на данном предприятии. Технолог вынужден учитывать доступность оборудования, загруженного изготовлением других изделий, не связанных с его технологическим процессом. Инженер, занимающийся планированием производства, должен принимать во внимание загруженность складов с учётом сложных логистических связей предприятия с поставщиками и потребителями. Воздействие таких факторов, которые явно не специфицированы в рамках конкретного элемента ЖЦ изделия и находятся на метауровне относительно рассматриваемого процесса или явления, следует считать контекстным влиянием. Структура этого влияния сложная, трудно формализуема и обусловлена структурой конкретного предприятия. Эта структура имеет вложенность контекстов, например конструкторский контекст вложен в технологический, технологический — в организационный, некоторые контексты пересекаются между собой или дополняют друг друга.

Предлагается следующее определение PLM -контекста.

Определение : Пусть E 1 и E 2 — произвольные элементы ЖЦ изделия, участвующие в интеграции данных. Если при передаче информации от элемента E 1 к элементу E 2 данные меняют свои значения под влиянием третьего элемента E 3 , то онтология ПрО элемента E 3 , называется PLM-контекстом Cont(E 3 ) для элемента E 2 .

ПрО PLM -контекста и элемента E 2 могут находиться в трёх отношениях множеств (см. рисунок 8).

а)                                  б)                                    в)

а) - контекст содержит ПрО элемента E 2 е Cont(E 3 ) ; б) - ПрО пересекаются E 2 О Cont(E 3 ) ; в) - ПрО не пересекаются E 2 £ Cont(E 3 )

Рисунок 8 - Отношения ПрО элемента ЖЦ изделия и влияющего на него PLM -контекста

На рисунке 9 представлена схема передачи информации внутри фрагмента PLM -пространства, состоящего из четырёх элементов: конструкторское проектирование изделия ( CAD ), технологическая подготовка ( CAPP ), планирование и организация производства ( MES, Manufacturing Execution System ), технико-экономическое обоснование ( ERP, Enterprise Resource Planning ). Разработка операций для станков с ЧПУ в CAM -системах является стадией этапа технологической подготовки производства, т.е. ПрО( CAM) е ПрО( CAPP ).

Рисунок 9 - Схема передачи информации внутри фрагмента PLM -пространства

Результаты конструкторского проектирования ( CAD ) используются практически всеми элементами ЖЦ изделия. Потенциально любой элемент ЖЦ может выступать в качестве контекста для любых других элементов PLM -пространства (на рисунке 9 потоки данных от контекстов обозначены штриховыми дугами). Поскольку в рамках данного исследования в первую очередь представляет интерес интеграция CAM -систем c системами CAD , то ниже приведены примеры контекстно-зависимой передачи данных для задач из области CAM.

Пример 1: учёт свойств обрабатываемых материалов.

В состав исходных данных для расчёта режимов резания входят свойства обрабатываемого материала. Например, такой параметр как твёрдость материала включён во многие методики расчёта технологических режимов. Если твёрдость материала брать из конструкторской 3 D-модели, то это значение может быть неадекватным реальным свойствам материала во время обработки. Конструктор назначает твёрдость исходя из функциональных требований, предъявляемых к изделию. Операции механической обработки часто производятся для материала в состоянии поставки. При передаче информации из конструкторской модели могут быть пропущены некоторые промежуточные операции технологического процесса. Узнать истинные свойства материала, можно, если обратиться к параметрам технологического процесса, в состав которого входит данная операция. В этом случае ПрО CAPP-системы выступает в качестве контекста по отношению к CAM-системе. Таким образом, свойства материала, извлечённые из CAD-модели, должны изменить свои значения под воздействием технологического контекста CAPP-системы. В свою очередь CAPP-система может находиться под влиянием организационного контекста MES-системы, например, если технолог вынужден учитывать загрузку оборудования. Это влияние MES-системы через технологический контекст передаётся и на CAM-систему.

Пример 2: автоматизированный подбор режущих инструментов.

Как правило, CAM -системы, содержат собственные базы инструментов. Эти базы могут не учитывать текущее наличие инструментов в цехе или возможность их поставки к моменту запуска изделия в производство. Для подбора инструментов необходима сверка инструментальной базы CAM -системы с базами ERP - или MES -систем. Такая сверка может быть произведена с использованием MDM-систем ( Mater Data Manager ), предназначенных для совместного доступа и управления единой нормативно-справочной информацией [18].

4    Стратегия автоматизации процесса влияния PLM-контекстовна передаваемые данные

Предлагаемая стратегия автоматизации процесса влияния PLM -контекстов на значения передаваемых данных включает следующие этапы.

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

Во-вторых, необходимо проработать концепцию хранения информации об этапах ЖЦ изделия непосредственно в 3D-модели изделия. Существенным отличием предлагаемой концепции от известной методологии CALS является отказ от протокола STEP и замена его онтологическими спецификациями на базе XML -стандарта. Для хранения данных об этапах ЖЦ изделия можно использовать архивы 3D-моделей. Если открыть файлы деталей в форматах SolidWorks и КОМПАС-3D ZIP-архиватором, то можно увидеть содержимое этих архивов (рисунок 11).

Можно предположить, что геометрическая информация хранится внутри элемента данных Contents (это и есть атрибут geometry класса 3D -model на рисунке 2). Анализ содержимого архивов показывает, что все файлы внутри 3D-модели SolidWorks являются бинарными, а внутри модели КОМПАС-3D элемент данных MetaProductInfo представляет собой текстовый XML -файл, содержащий общую информацию о составе изделия.

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

PDM - или MDM -системам. Хранение знаний об этапах ЖЦ изделия внутри 3D-модели является необходимым условием реализации многоагентных систем проектирования и управления производством [19]. Выступая в качестве интеллектуального агента среды проектирования и обладая при этом свойствами реактивности и целенаправленности, деталь должна все свои знания содержать внутри себя. Предварительный вариант онтологического содержания интеллектуального агента (детали) представлен на рисунке 12.

Рисунок 10 – Онтология ПрО технологического процесса

Имя	Размер	Сжатый	Файлов	Имя	Размер	Сжатый	Версия
.Contents i	44 498	45 504	11	ijContents i	420 081	420 081	0
. SwDocMgrTempStorage	0	0	0	_ Fileinfo	602	602	0
. swXmlContents	768	832	2	MetaInfo	214	120	0
. ThirdPty	198	256	4	_ MetaProductinfo	26 690	2 917	0
J, ThirdPtyStore	457	512	2	П Preview	63 450	63 450	0
, _DL_VERSION_4100	6	64	1	П Syslnfo	3 508	3 508	0
. _MO_VERSION_4100	1656	1728	2
__] Config-O-Properties	164	192
_ Header2	1924	1984

а)                                                                   б)

Рисунок 11 – Содержимое 3D-модели в форматах SolidWorks (а) и КОМПАС-3D (б)

Рисунок 12 – Онтология знаний интеллектуального агента (детали)

В-третьих, необходима программная реализация интеллектуальных конверторов данных, принимающих в качестве интегрирующих моделей данных онтологии элементов ЖЦ изделия на базе стандарта XML . Разработка архитектуры таких конверторов должна быть основана на современных методах автоматизации программирования с применением UML -представлений объектов и онтологического подхода к разработке программного обеспечения.

Заключение

Особенности наследования инженерных данных необходимо учитывать при разработке САПР-приложений и создании на их основе систем интеграции корпоративного уровня. Приведено наглядное описание различных схем наследования информации с использованием UML -представлений на примере интеграции систем технической подготовки производства.

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