Пособие НМ



Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования

«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ

АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ

имени академика С.П. КОРОЛЕВА

(национальный исследовательский университет)»

ОНТОЛОГИИ: СОВРЕМЕННОЕ СОСТОЯНИЕ, СТАНДАРТЫ, СРЕДСТВА ПОДДЕРЖКИ

САМАРА

2013

УДК СГАУ 004.9(075)

Составители: Н.М. Боргест, М.Д. Коровин

Рецензенты: к.т.н. Симонова Е.В.

д.т.н. Смирнов С.В.

Онтологии: современное состояние, стандарты, средства поддержки: учеб. пособие / сост. Н.М. Боргест, М.Д. Коровин. СГАУ – Самара, 2013. – 84 с.

Пособие предназначено для использования в учебном процессе специальности 220305 – Автоматизированное управление жизненным циклом продукции при изучении курса «Онтология производственной сферы», а также для обучения и переобучения специалистов предприятия по управлению современным машиностроительным предприятием на основе новых интеллектуальных технологий.

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

УДК СГАУ 004.9(075)

«Авторы-составители выражают благодарность Министерству науки и образования РФ, поддержавшего разработки по созданию интеллектуальных систем управления в реальном времени по государственному контракту Минобрнауки РФ № 07.524.12.4022 и государственному контракту Минобрнауки РФ №14.514.11.4005»

(с) СГАУ, 2013

СОДЕРЖАНИЕ

ВВЕДЕНИЕ5

ПРИМЕНЕНИЕ ОНТОЛОГИЙ5

МУЛЬТИАГЕНТНЫЕ СИСТЕМЫ6

Постановка проблемы6

Понятия и принципы6

Семантическая сеть6

СТАНДАРТЫ6

ISO 103036

Структура стандарта6

Основные элементы языка EXPRESS6

Стандарт ISO 13584 (PLIB)6

Стандарт ISO 15531 (MANDATE)6

Стандарт ISO 8879 (SGML)6

ISO 159266

Архитектура ISO 159266

Концептуальные модели данных6

Справочные данные6

Регистрация и сопровождение справочных данных6

Язык описания онтологий OWL6

Обзор современных онторедакторов и средств поддержки онтологий6

COLORE6

HyQue6

Makleod6

OntoHub6

OntologyTest6

OntoQA6

OOPS6

OOR6

RepOSE6

SigmaKEE6

Прикладные задачи, решаемые с использованием онтологий6

Конструктор онтологий компании Magenta6

Protégé6

Конструктор онтологий Smart solutions6

Система планирования «Smart factory»6

Список использованных источников6

Приложение . Коммюнике Онтологического саммита 2013. Оценка онтологий в течение всего жизненного цикла6

ВВЕДЕНИЕ

Развитие наукоемких областей человеческой деятельности в современном обществе сопровождается возрастанием роли компьютерных технологий. Сейчас значительно увеличивается поток информации, появилась необходимость поиска новых способов ее хранения, представления, формализации и систематизации, а также автоматической обработки. Таким образом, растет интерес к всеобъемлющим базам знаний, которые возможно использовать для различных практических целей. Огромный интерес вызывают системы, способные без участия человека извлечь какие-либо сведения из текста и других массивов информации. Как результат, на фоне вновь возникающих потребностей развиваются новые технологии, призванные решить заявленные проблемы. Наряду с World Wide Web появляется его расширение, Semantic Web, в котором гипертекстовые страницы снабжаются дополнительной разметкой, несущей сведения о семантике включаемых в страницы элементов. Неотъемлемым компонентом Semantic Web является понятие онтологии, описывающее смысл семантической разметки.

Применение онтологий

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

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

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

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

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

глоссарий;

простая таксономия;

тезаурус (таксономия с терминами);

понятийная структура с произвольным набором отношений;

полностью аксиоматизированная теория.

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

Для обобщения и «осмысления» разделов информации необходимо определить свою онтологию, которая должна описывать терминологию, использующуюся в содержимом портала, и аксиомы, задающие правила использования этих терминов в контексте других терминов.

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

Ресурсом называют все, что описывается средствами RDF. Это может быть обыкновенная Web-страница или какая-то ее часть, например, отдельный элемент HTML или XML разметки, являющийся частью описываемого документа. Также ресурсом может быть целая коллекция страниц, например, отдельно взятый Web-сайт. И, наконец, в качестве ресурса может выступать нечто, не являющееся доступным непосредственно через Интернет, например, произвольный предмет из мира вещей. Одним словом, все, чему можно приписать некоторый URI (универсальный идентификатор) или URI с добавлением внутреннего имени объекта (имени якоря в HTML) может стать ресурсом и быть описано при помощи RDF.

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

Согласно спецификации, значение свойства может иметь один из двух типов. Первый – это ресурс, задаваемый некоторым URI. Второй тип – литерал – есть некоторое текстовое значение характеристики. Впрочем, литерал может выражать собой значение любого примитивного типа данных, присутствующего в XML. Его тест также может содержать в себе некую разметку, например, XML, но отличительной особенностью такой разметки является то, что она не обрабатывается RDF-процессором и воспринимается как обычная строка.

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

МУЛЬТИАГЕНТНЫЕ СИСТЕМЫ

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

Постановка проблемы

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

Понятия и принципы

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

Онтологические подходы становятся все более популярными, расширяется сфера их применения – современные онтологические модели позволяют описывать нечеткие предметные области [2].

Существует два основных подхода к проектированию онтологии – восходящее и нисходящее проектирование. Сущность восходящего проектирования заключается в последовательном описании предметной области с самых частных концептов, например, для машиностроительного предприятия это может быть описанием рабочего места токаря, с последующим объединением получающихся «минионтологий» в общую систему. Онтологии, получающиеся таким путем, являются узкоспециализированными и трудно применимыми в смежных предметных областях [3]. Нисходящее проектирование онтологий заключается в предварительном построении онтологии на высоком уровне абстракции, где бы описывались наиболее базовые концепты, такие как «класс», «свойство класса», «отношение», общие для многих предметных областей, с последующим доопределением концептов по уже имеющейся классификации. Такие онтологии высокого уровня абстракции называют онтологиями верхнего уровня или «top level ontology» в зарубежной литературе [4].

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

На сегодняшний день создано множество онтологических систем верхнего уровня. Среди наиболее известных систем можно назвать SUMO, онтологию Sowa, Dolce, Clip и ISO 15926-2. Вышеперечисленные онтологии объединяет возможность определения ключевых концептов через описание их поведения и сценариев использования. Затем эти концепты определяются на основании более общих концептов, заложенных в онтологии верхнего уровня [6]. Такой подход позволяет с одной стороны, избежать необходимости каждый раз «изобретать велосипед» при определении классов сущностей, а с другой предоставляет широкие возможности адаптации онтологии под конкретную задачу и в значительной мере упрощает её поддержку.

На рисунке 1 представлена многоуровневая структура онтологии машиностроительного предприятия. Онтологии верхнего и нижнего уровней создаются экспертами в предметной области в тесном сотрудничестве со специалистами-онтологами, тогда как задача наполнения онтологии концептами нижнего уровня решается пользователями без привлечения дополнительных специалистов. На практике, наиболее хорошо зарекомендовавшим себя методом является наполнение онтологии через специально спроектированные формы-шаблоны, позволяющие человеку без навыков программирования или представлений о том, как устроена онтологическая база знаний, эффективно решать задачу её наполнения [7].

Рисунок 1 – Структура онтологии машиностроительного предприятия

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

Для обеспечения и поддержания семантической интеграции информационных ресурсов предприятия используемая онтология должна соответствовать следующим основным принципам [8]:

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

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

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

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

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

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

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

Семантическая сеть

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

Задачей онтологии в этом случае является обеспечение взаимодействия агентов, не обязательно оперирующих в рамках одной общей теории. Агент действует в рамках онтологии, если его наблюдаемые действия укладываются в классификацию этой онтологии. Таким образом, онтология определяет «словарь» общения между агентами. Онтологическое согласование может происходить на разных уровнях абстракции, то есть агенты, оперирующие в близких предметных областях, обмениваются более конкретными данными, тогда как слабосвязанные агенты при обмене оперируют сущностями типа «класс», «отношение» и т.п. Использование онтологий позволяет достичь согласованности между агентами, однако не гарантирует полноты описаний. Множественность онтологий реального мира в данном контексте обусловлена различиями внутренних интерпретаций предметных областей разными исследователями [9].

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

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

Онтологические модели в силу своей природы, как правило, достаточно объемны. «Масштабный фактор» — возрастание сложности системы из-за увеличения количества связей между её частями, диктует необходимость в новых подходах к управлению сложными системами. Мультиагентный подход, позволяет значительно сократить количество связей в системе, являясь одним из наиболее перспективных способов управления сложными распределенными системами.

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

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

Стоит отметить, что «агент» — более общее понятие, чем система. Это позволяет при необходимости представлять любую часть сложной системы в качестве агента. Представленная модель благодаря особенностям онтологического редактора пригодна для машинной обработки, что значительно расширяет возможности её использования. Агенты взаимодействуют между собой в рамках общей внутрицеховой онтологии, которая в свою очередь входит в более общую онтологию предприятия.

В приведенной на рисунке 2 схеме взаимодействия агентов Заказ – более общее понятие, чем ДСЕ (деталь, сборочная единица), так как один заказ может включать в себя несколько ДСЕ. Визуализация результата планирования может быть выполнена в форме диаграммы Ганта, как показано на рисунке 3.

Рисунок 2 – Схема взаимодействия агентов

Рисунок 3 – Фрагмент цехового расписания в форме диаграммы Ганта

Знания об объекте соотносится не только с особенностями его взаимодействия со средствами наблюдения, но и с ценностно-целевыми структурами деятельности субъекта. Таким образом, можно вести речь о необходимости создания интерсубъективной теории [10], представляющей собой интеграционную платформу для достижения консенсуса неоднородными агентами относительно способа регулирования проблемной ситуации. Включение человека, его онтологических свойств: восприятия, способностей, возможностей, мотивации и потребностей, в систему, в процесс управления предприятием, существенно расширяет потенциал возможностей самой системы.

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

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

СТАНДАРТЫ

ISO 10303

Структура стандарта

ISO 10303 (STEP — Standard for the Exchange of Product Model Data) — это международный стандарт для компьютерного представления и обмена данными о продукте (изделии). Цель стандарта — дать нейтральный механизм описания данных о продукте на всех стадиях его ЖЦ, не зависящий от конкретной системы. Природа такого описания делает его подходящим не только для нейтрального файла обмена, но и в качестве базиса для реализации и распространения баз данных о продукте, а также для архивирования [11].

В соответствии с названием, STEP определяет «нейтральный» формат представления данных об изделии в виде информационной модели. Для обеспечения возможности единообразного описания изделий в различных прикладных областях, предполагается, что информационные модели (в терминах стандарта «прикладные протоколы») создаются на базе типовых блоков («интегрированных ресурсов»), причем для описания схем данных используется специально введенный язык EXPRESS. Язык EXPRESS является одним из разделов стандарта ISO 10303 STEP и описан в 11 томе стандарта ISO 10303. Он регламентирует черчение (прямое и ассоциативное), проектирование конструкций, инженерный анализ, технологическую подготовку, производство, тестирование данных и обмен ими (в том числе с IDEF-моделями) в специальном текстовом формате, который обеспечивает безопасность и надежность передачи информации по Интернет партнерам.

Стандарт ISO 10303 включает в себя 8 разделов, тесно связанных друг с другом, каждый из которых, в свою очередь, состоит из томов. Перечень разделов включает в себя:

методы описания (язык EXPRESS);

стандартные решения (способы применения);

структура и методология проверки на совместимость;

общие интегрированные ресурсы;

прикладные интегрированные ресурсы ;

прикладные протоколы (в различных отраслях);

набор абстрактных тестов (абстрактные примеры);

элементы для конкретных приложений

Каждый том документации по ISO 10303 начинается с одной и той же преамбулы, определяющей назначение и структуру ISO 10303, а именно: «ISO 10303 — международный стандарт для компьютерного представления и обмена данными о продукте». Цель стандарта—дать нейтральный механизм описания данных о продукте на всех стадиях его ЖЦ, не зависящий от конкретной системы.

Приведенное определение ISO 10303 нуждается в комментариях:

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

2. Утверждать, что ISO 10303 является стандартом обмена данными о продукте, можно лишь при расширенной трактовке STEP (ISO 10303) как стандарта, включающего в себя стандарты PLIB и MANDATE. С технологической точки зрения это так и есть, поскольку PLIB и MANDATE строятся на базе стандарта STEP, заимствуя из него методы описания (язык EXPRESS), формы реализации (обменный файл и интерфейс доступа к данным) и, при необходимости, интегрированные ресурсы (информационные структуры). С потребительской же точки зрения каждый из трех стандартов имеет свою предметную область:

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

ISO 15331(MANDATE) описывает динамику производства как снаружи (связи производства с внешней средой), так и изнутри (материальные и информационные потоки в организационно-производственной структуре, короче — интегрированная модель производства).

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

CALS-технологии, в частности стандарт ISO 10303 STEP, предлагают способ решения этой проблемы при помощи использования стандартизованного интегрированного описания изделия.

Интегрированное электронное описание изделия — это набор данных различного типа, полученных в ходе проектирования различными способами, а затем преобразованных в стандартизованный вид и достаточных для решения задач последующих этапов ЖЦ. Например, конструкторское электронное описание в соответствии со стандартом STEP содержит структуру и варианты конфигурации изделия, геометрические модели и чертежи, свойства и характеристики составных частей и др. (см. рисунок 4).

Рисунок 4 – Конструкторское электронное описание изделия в соответствии со стандартом STEP [12]

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

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

Стандарт STEP регламентирует: логическую структуру базы данных (БД), номенклатуру информационных объектов, хранимых в БД, их связи и атрибуты. Типовые информационные объекты, такие как данные, о составе изделия, материалах, геометрических изделиях, независимые от характера описания изделия, называются в стандарте «интегрированными ресурсами», на основе которых строятся схемы баз данных об изделии для разных предметных областей автомобилестроения, судостроения, аэрокосмической промышленности и т.д..

Готовые схемы баз данных называются в стандарте «протоколами применения» (или прикладными протоколами) и представляют собой типовые решения.

Практически, стандарт STEP может быть применен несколькими способами:

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

2. Структуры данных могут быть созданы в готовой PDM системе путем ее соответствующей настройки и разработки соответствующих визуальных приложений.

3. Могут быть использованы готовые решения.

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

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

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

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

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

Основные элементы языка EXPRESS

Накопленные человечеством знания всегда формулируются в контексте иерархической системы (более строго — ациклической сети) понятий и функциональных связей между этими понятиями. Такая структура представления знаний моделируется при объектно-ориентированном подходе в виде иерархии классов с механизмом наследования общих свойств [13].

Реализация объектно-ориентированного подхода возможна в двух вариантах.

Первый вариант — некоторый набор знаний сразу доводится до уровня машинной программы. В этом случае необходим язык программирования, поддерживающий функционально полное описание класса. Практически это означает, что описание класса должно включать как данные (перечень атрибутов класса), так и «методы» (программы, реализующие полный набор операций над объектами данного класса). C++, Симула-67 — примеры языков объектно-ориентированного программирования, то есть реализации подхода по первому варианту.

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

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

Информационное моделирование (на базе методологии IDEF1Х) представляет информацию о сущностях, их связях и атрибутах, которое может быть использовано далее при создании спецификаций EXPRESS.

Функциональное моделирование отвечает за второй элемент представления знаний — функциональные связи между понятиями. Интеграция знаний в этой области пока осуществляется без привлечения ЭВМ, хотя предпринимаются попытки как-то регламентировать представление знаний, в частности, средствами IDEFO. В стандарте STEP средства IDEFO используются для иллюстративного представления сферы использования приложения — программной реализации стандартного протокола приложения АР, содержащего специализированную информационную модель.

Наконец, стандарт STEP касается и третьей компоненты проектирования — программной реализации стандартного АР. Для каждого стандартного протокола его разработчиками составляется набор абстрактных тестов, по которому проверяется реализация протокола на соответствие требованиям АР (см. Рисунок8). Следует отметить, что структура функциональной модели приложения (и, следовательно, представление в ЭВМ функциональных связей между понятиями) не определяется стандартом STEP, а лишь ограничивается снизу требованием, чтобы ЭВМ «владела» понятиями информационной модели, по крайней мере, на уровне минимальных требований, заданных набором абстрактных тестов. Второй вариант является предпочтительным для использования в CALS, поскольку информация для создания информационных систем предварительно систематизируется и верифицируется.

В разработке первой версии языка EXPRESS участвовало порядка 20 человек в период с 1985 по 1991 год. Проблема не ограничивалась изъятием методов из структуры описания класса. Требовалось разработать специализированный язык информационного моделирования, достаточно полный для описания любой системы понятий, связанных с производственной деятельностью, достаточно простой для освоения пользователем-непрограммистом и, наконец, достаточно технологичный для работы приложений с языковыми конструкциями. Конкретизация предметной области использования языка EXPRESS была необходима по существу, так как имеются области знания с более сложными структурами понятий (например, семиотика), ориентация на которые могла бы привести к чрезмерному усложнению проблемы.

Итак, язык EXPRESS предназначен для описания информационных моделей (как и метод IDEF1Х) [14]. Информационная модель описывается одной или несколькими взаимосвязанными схемами. Схема состоит из набора элементов, который может включать в себя:

объекты (ENTITY);

типы (Type);

константы (Constant);

правила (Rule);

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

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

База данных (БД), формируемая в соответствии с описанием EXPRESS -схем, предназначена для хранения произвольного количества экземпляров каждой из сущностей, представленных в схемах. Сущность — информационный объект, характеризующийся идентификатором и списком атрибутов, определяющих свойства каждого из экземпляров сущности. Остальные элементы описания схемы играют вспомогательную роль, а именно: type-объявления определяют структуру представления атрибутов сущности. Алгоритмы и правила служат для проверки соответствия содержимого БД информационной модели, а интерфейс предназначен для унификации описания объектов (типов, алгоритмов, правил), используемых более чем в одной схеме.

Возможности описания информационных структур в языке EXPRESS сводятся, в основном, к следующим. Прежде всего, имеется набор стандартных (встроенных в EXPRESS) данных, состоящий из группы простых типов, включающей типы number, integer, real, logical, boolean, binary, string, и из группы агрегативных типов, включающей типы array, bag, list, set — разновидности множества однотипных компонент. При использовании в схеме простых типов real, binary, string можно специфицировать их формат, а при использовании агрегативных типов — их размеры (границы).

С помощью entity-объявлений и type-обьявлений разработчик схемы вводит собственный набор именованных типов, дополняя набор стандартных типов до набора «базовых». Базовый тип может использоваться в качестве компоненты агрегативного, а также в entity-объявлении для описания атрибута посредством конструкции: идентификатор атрибута: базовый тип

В type-объявлениях определяемый тип описывается ссылкой на «определяющий» тип, который может быть простым, агрегативным, определяемым, перечисления или селекторным. Тип перечисления — это упорядоченный список конкретных строк-наименований. Селекторный тип — это любой из именованных типов, перечисленных в объявлении селекторного типа.

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

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

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

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

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

Рассмотренный выше тип связи между экземплярами сущностей по атрибутам (с помощью ссылок на необходимые экземпляры) является одним из двух имеющихся в языке EXPRESS типов связей. Второй тип связи — «генетический», или механизм множественного наследования, — состоит в следующем. С помощью subtype-предложения в entity-объявлении можно указать список сущностей — непосредственных «предков» данной сущности, от которых она наследует все свойства — атрибуты, правила и алгоритмы. Отношение наследования транзитивно, то есть вместе с наследованием свойств непосредственных предков наследуются свойства предков вышестоящего уровня, а в итоге — свойства всей «родословной». Наследование атрибутов означает их непосредственное включение в структуру собственных атрибутов сущности, в результате чего образуется «сложный» экземпляр.

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

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

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

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

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

Как уже указывалось, цель ISO 10303 — дать стандарт описания данных о продукте на всех стадиях его ЖЦ. Поскольку состав данных о продукте существенно зависит как от дисциплины (классификационной группы) продукта, так и от стадии его ЖЦ, конечной целью ISO 10303 является разработка множества частных информационных моделей АР, каждый из которых характеризуется своим контекстом — дисциплиной и стадией ЖЦ продукта. В то же время было бы неверно разрабатывать АР без учета их частичной пересекаемости по информационным объектам, то есть возможности выделения в каждом АР контекстно-независимой части и объединения этих частей в группу моделей верхнего уровня — интегрированных ресурсов.

Выбран наиболее простой способ реализации этой возможности, а именно: сначала разработать в достаточно полном объеме структуру и состав интегрированных ресурсов и соответствующий набор первичных сущностей, разработку каждого АР регламентировать условием, что сущностями EXPRESS -схемы АР (так называемой «интерпретированной модели приложения» —AIM) могут быть только подтипы (потомки сущностей, представленных интегрированными ресурсами (ИР), при возникновении исключительной ситуации, когда для сущности, необходимой приложению, не удается найти предков в ИР, его состав пополняется необходимыми о6ъектами.

Состав документации по информационным моделям ISO 10303 открыт для пополнения новыми томами в рамках соглашения о том, что для ИР отводятся номера томов в интервале 41-199, а для АР — в интервале 201-1199 (см. Приложение). Кроме того, документация по ИР разделяется на серию общих ресурсов (тома 41-99) и серию ресурсов приложения (тома 101-199). В отличие от общих ресурсов, сфера применимости которых полностью контекстно-независима, ресурсы приложения ориентированы на конкретные области применения. Наконец, к категории ИР можно отнести и библиотеку А1С EXPRESS-схем, описывающих отдельные понятия предметной области, используемые в двух и более АР. Такая форма обеспечения информационной совместимости различных АР поддерживается централизованным ведением этой библиотеки специальной службой.

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

Стандарт ISO 13584 (PLIB)

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

ISO 13584 Parts Library — это серия международных стандартов для представления и обмена доступными для компьютерной интерпретации данными о поставляемых компонентах и комплектующих изделиях (узлах, деталях). Схема информационного взаимодействия с поставщиком деталей (комплектующих изделий) в соответствии с ISO 13584 приведена на рисунке 5 [15].

Стандарт ISO 13584 PLIB включает в себя 7 разделов:

общий обзор и основополагающие принципы;

концептуальная модель библиотеки деталей;

основные ресурсы;

логическая модель библиотеки поставщика;



Страницы: Первая | 1 | 2 | 3 | ... | Вперед → | Последняя | Весь текст




map