Настоящая статья - продолжение серии публикаций, начатой нами в # 2'97 журнала
Аналитический обзор международного стандарта ISO 13584 (P_LIB)
В томе 1 документации по P_LIB назначение этого стандарта определяется следующим образом: серии ISO 13584 представляют информацию о библиотеке изделий вместе с необходимыми механизмами и определениями, обеспечивающими обмен, использование и корректировку данных библиотеки. Имеется в виду обмен между различными компьютерными системами и средами, связанными с полным жизненным циклом продукта, включая проектирование, изготовление, эксплуатацию, обслуживание и утилизацию продукта, где могут использоваться объекты библиотеки.
Короче говоря, P_LIB - это стандарт обмена данными об изделиях между поставщиками и потребителями изделий. Под изделием (part) в P_LIB понимается промышленное изделие на той или иной стадии жизненного цикла - однокомпонентное (деталь) либо многокомпонентное (сборная конструкция). В роли поставщика изделий может выступать любая компьютерная система или среда, в частности, "CAD-система" - Express-среда некоторого Application Protocol (АР), конечными продуктами которого являются изделия. Для обеспечения обмена поставщик должен дополнить имеющееся в CAD-системе внутреннее описание изделий (например, конструкторско-технологическое Express-представление) внешним описанием этих изделий, оформив его в виде "библиотеки поставщика", и каталогизировать эту библиотеку в "интегрированную библиотеку", объединяющую библиотеки разных поставщиков.
На стадии эксплуатации интегрированной библиотеки потенциальными потребителями изделий она выступает в роли "библиотеки пользователя". Библиотека пользователя - это содержимое интегрированной библиотеки, возможно, адаптированное пользователем и доступное ему через авторское рабочее место (АРМ). АРМ предоставляет пользователю, во-первых, диалоговый интерфейс доступа к интегрированной библиотеке для поиска нужного изделия и, во-вторых, интерфейс передачи Express-представления выбранного изделия в CAD-систему.
Если в стандарте STEP проблема обмена данными между АР сводилась, по сути, к проблеме расширения границ видимости данных за пределы модели АР, то в P_LIB потребитель должен "видеть" изделие в представлении, трансформированном с учетом условий среды потребителя. Например, форма пружины зависит от габаритов конструкции, в которую она будет помещена. При этом генерацию такого представления должен обеспечить не потребитель, а поставщик, отвечающий за описание изделия.
Для поддержки такой трактовки обмена данными в P_LIB пришлось воспроизводить объектно-ориентированный подход в полном объеме, т. е. моделировать средствами Express-классы в традиционном их понимании - с атрибутами и методами. В интегрированной библиотеке используются, в основном, три вида сущностей подобной структуры, а именно:
Каждый экземпляр сущности "классы общей модели" является классом общей модели, представляющим в библиотеке некоторое семейство изделий - простое или обобщенное. В принципе такое семейство можно было бы представить моделью сущности и ее популяцией. Однако описание семейства в виде класса снимает проблему представления популяции, точнее, перекладывает эту проблему на метод - программу доступа к любому экземпляру класса (общей модели изделия).
Простое семейство изделий - это множество изделий поставщика, объединяемое им под общим наименованием класса и характеризующееся общим составом "атрибутов идентификации", по значениям которых одно изделие семейства можно отличить от остальных. Каждое изделие поставщика - это физическое изделие, имеющееся у поставщика в достаточном количестве эквивалентных копий. Помимо атрибутов идентификации, в описание класса могут входить определяемые атрибуты и функции определения этих атрибутов по значениям атрибутов идентификации. Атрибуты идентификации используются также в соответствии со своим названием, а именно, входят в состав идентификатора изделия, включающего:
Перечень изделий, входящих в класс, не обязательно ограничивается "таблицей определения" класса, каждая строка которой содержит все атрибуты одного экземпляра класса. При необходимости поставщик может заложить в метод генерацию виртуальной таблицы определения, использующую экземпляры класса в качестве опорных узлов для формирования всего "типоразмерного" многообразия изделий в классе.
Обобщенное семейство изделий - это результат объединения поставщиком простых семейств или обобщенных семейств более низкого уровня (потомков) под общим наименованием класса и общим составом обобщенных атрибутов, которые могут наследоваться всеми нижестоящими уровнями. Изделия обобщенного семейства называются абстрактными изделиями. Если поставщик предоставляет метод генерации экземпляров обобщенного семейства, то описание класса дополняется:
Если перечисленные правила представления простых и обобщенных семейств в виде классов общей модели можно расценить как некоторую интерпретацию стандартных элементов описания сущности, то три допустимых уровня библиотеки изделий уже существенно ограничивают возможности такого описания. В библиотеке уровня 1 (однокомпонентные изделия) допустимыми типами атрибутов являются числовой, строковый и логический. В библиотеке уровня 2 (простые сборные изделия) добавляется класс общей модели (изделие). Наконец, в библиотеке уровня 3 (сложные сборные изделия) к перечисленным типам добавляется агрегат этих типов вида list. В существующей версии стандарта библиотека уровня 3 не поддерживается. Разумеется, приведенные ограничения следует рассматривать как результат конкретизации сущности применительно к изделию, а не как дефект проекта P_LIB.
Разнообразные способы представления одного и того же изделия (общей модели) можно разделить по категориям (геометрия, кинематика, конечно-элементный анализ, условия поставки и т. д.). Класс функциональной модели служит для представления свойств всех изделий одного или нескольких классов общей модели в рамках одной категории представления. Класс идентифицируется "логическим именем вида", а при наличии в пределах класса нескольких вариантов представления конкретизация варианта осуществляется "управляющими переменными вида". Например, в категории "геометрия" таковыми, в частности, являются "класс геометрии" (твердотельная, 3D-проволочная, 2D и т. д.) и "уровень детализации" (упрощенный, стандартный, детальный).
Описание класса функциональной модели включает параметры контекста, атрибуты представления, функции определения и методы. Связь класса функциональной модели с классом общей устанавливается на уровне экземпляров этих классов - функциональной и общей моделей изделия. При этом атрибуты общей модели доступны для любой связанной с ней функциональной модели. Параметры контекста характеризуют среду, в которую предполагается поместить изделие, так, что значение этих параметров должно поступать в библиотеку от потребителя. Значения атрибутов представления вычисляются в соответствии с функциями определения по атрибутам общей модели и, возможно, параметрам контекста. Механизм наследования общих свойств действителен и для класса функциональной модели. Можно, например, создать в категории "условия поставки" суперкласс с атрибутами "цена", "количество в заказе" и т. д., используемыми в этой категории для представления любого изделия.
Наконец, методы класса функциональной модели - это параметрические программы, формирующие представление изделия для передачи в CAD-систему пользователя (например, в виде множества экземпляров геометрических сущностей). Вызов метода из CAD-системы осуществляется обращением к "классу функционального вида" с конкретными значениями логического имени вида и управляющих переменных вида. Экземпляром этого класса является передаваемый в CAD-систему функциональный вид изделия, содержащий STEP-представление изделия и значения управляющих переменных вида.
На самом деле функциональный вид связывается не с общей моделью изделия, а с вхождением копии изделия в среду пользователя. Для идентификации каждой копии изделия в CAD-системе стандартом P_LIB предусмотрен "класс общего вида", единственным атрибутом которого является "имя объекта" - идентификатор изделия плюс координаты размещения копии.
Таким образом, методами класса функциональной модели реализуется интерфейс передачи представления изделия из интегрированной библиотеки в CAD-систему пользователя. В первой версии P_LIB определен один из возможных интерфейсов, а именно, интерфейс передачи геометрического представления в STEP-среду пользователя. В библиотеке поставщика предусмотрены возможности ссылок на внешние файлы, представляющие изделие в формате других стандартов, в частности, SGML и VHDL. Для эксплуатации библиотеки в любом случае достаточно двух условий, а именно, что в принимающей CAD-системе поддерживается соответствующий интерфейс передачи представления; в системе управления библиотекой этот интерфейс распознается.
При описании библиотеки изделий невозможно обойтись без привязки изделий к некоторой системе классификации. На первый взгляд, эта задача не из простых, поскольку формирование совершенного классификатора - процесс, неисчерпаемый во времени.
Для решения этой задачи каждое семейство изделий описывается на двух уровнях абстракции - семантическом и логическом. Семантическое описание содержит информацию о наименовании и определении каждого семейства изделий, а также о наименовании, типе и определении всех атрибутов каждого изделия. Каждое наименование связано с кодом идентификации этой абстракции, с версией, характеризующей корректировки, и с дескриптором, определяющим смысл абстракции. Такая информационная структура определяет "базовую семантическую единицу", соответствующую отдельному входу в таблицу, называемую семантическим словарем. Этот словарь и служит аналогом системы классификации.
Логическое описание семейства изделий (в виде класса общей модели), которое может и отсутствовать, дает информацию о фактическом содержимом семейства изделий поставщика. Каждое логическое описание ссылается на вход семантического словаря, и каждый атрибут этого описания ссылается на отдельный "атрибутный" вход в семантическом словаре. В семантическом словаре, в свою очередь, можно установить между различными входами семантические связи одного из следующих типов отношения: "имеет предком", "является подтипом", "является частью", "является видом".
В семантическом описании семейства изделий поставщик может указать, что оно является подтипом семейства абстрактных изделий другого поставщика. В этом случае в описании первого семейства можно ссылаться на атрибуты второго семейства. Семантический словарь может пополняться любым поставщиком библиотеки. Поставщик сам решает, расширять ли словарь новыми входами или воспользоваться ссылками на описания других поставщиков. В качестве таковых могут быть и организации, разрабатывающие стандартные классификаторы изделий. Таким образом, указанная выше проблема привязки библиотеки к классификатору изделий решается предельно просто - на основе децентрализованного механизма интеграции описаний, находящегося вне сферы стандартизации.
Также не регламентируется стандартом программная "система управления библиотекой", обеспечивающая пользователю доступ к содержимому интегрированной библиотеки. Предполагается только, что эта система предоставляет пользователю минимальный сервис (связанный, например, с поддержкой концепции семантического словаря), который необходимо предусмотреть при проектировании системы.
Функции стандарта P_LIB
Функционирование стандарта P_LIB предполагает исполнение следующих видов деятельности, или ролей:
Конечный пользователь должен также иметь возможность адаптировать библиотеку каждого поставщика (удаление ненужных элементов, добавление атрибутов). Результат этой адаптации называется библиотекой пользователя.
Содержимое ИБ полностью определяется поставщиками библиотек и пользователем. Роль же интегратора сводится к разработке программной системы, позволяющей:
Архитектура системы P_LIB может быть определена в терминах следующих пяти подсистем:
1) Диалоговый интерфейс - это подсистема, обеспечивающая пользователю (через АРМ) доступ к ИБ и передачу данных из ИБ на экран пользователя.
2) Интерфейс передачи представления - это множество функций, или механизмов, доступных для определяемых поставщиком представлений и позволяющих по требованию пользователя передавать представление изделия в CAD-систему.
3) Семантический словарь - это таблица с множеством входов, обеспечивающих автоматическую связь дескрипторов (внешних имен, предназначенных для восприятия человеком) и идентификаторов (внутренних имен, предназначенных для машинной программы). В словаре имеются входы следующих типов: поставщик, класс, свойство, тип значений, библиотека программ, документ.
Семантический словарь осуществляет следующие пять функций:
4) Содержимое библиотеки - это информация в библиотеке пользователя. Она состоит из данных и программ. Любой фрагмент этой информации порожден либо поставщиком либо пользователем и соответственно этой принадлежности идентифицируется.
5) Система управления библиотекой LMS (Library Management System) - это программная система, разрабатываемая интегратором и позволяющая пользователю работать с содержимым ИБ. Эта система не стандартизована. Тем не менее, в стандарте P_LIB предполагается, что некоторые элементы сервиса, специфицируемые в P_LIB, будут отражены в концепции реализации LMS.
На самом деле таких элементов спецификации LMS стандартом P_LIB набирается достаточно для того, чтобы рассматривать их как первую версию ТЗ на разработку LMS, а все нестандартные спецификации вынести в последующие версии ТЗ. Вероятно, неполнота первой версии в наибольшей мере проявится в вопросе диалогового интерфейса поставщика. Как показано выше, такой подсистемы стандартом вообще не предусмотрено. В то же время разработка поставщиком описаний изделий и представлений изделий - далеко не простая работа, которую следовало бы поддержать хорошо продуманным сервисом, а не ограничиваться системным средством ввода данных в формате обменного файла.
Архитектура информационной модели
Библиотека P_LIB размещается в одном или нескольких репозиториях данных, или файлах, один из которых, называемый библиотечным файлом или контекстом обмена P_LIB, присутствует всегда. Он содержит как структуру библиотеки P_LIB (семантический словарь), так и ее содержимое.
Некоторые сущности контекста обмена P_LIB ссылаются на другие ("внешние") файлы P_LIB, информационные модели которых ("внешние контексты обмена") описываются другими стандартами (STEP, SGML, VHDL, EDIF и т.д.) и дают различные категории представления классов изделий, образующих библиотеку пользователя.
Библиотечный репозиторий содержит SDAI-модели 11 Express-схем, определяющих логические ресурсы P_LIB ("библиотеку поставщика"), а также модели задействованных в конкретной ИБ протоколов обмена видами VEP (view_ exchangeprotocol).
Концепция семантического словаря и большая часть его функций определяются схемами dictionary и language_resource, приведенными в приложении к тому 42, и схемой ISO_13584_dictionary из библиотеки поставщика (том 24).
Схема dictionary предназначена для моделирования иерархии классов компонент, свойств класса и типов значений свойства, а также для определения понятий, необходимых для расширения семантики объектов P_LIB в других схемах библиотеки поставщика и в перспективе. Схема поддерживает функцию семантического словаря "совместимость внешних имен" на уровне информационной модели, а именно: внешнее имя (dictionary_ element) связывается с абсолютным идентификатором (basic_semantic_unit), уникальность которого обеспечивается его трехзвенной структурой и правилами кодирования этих звеньев, приведенными в томах 26, 42.
Схема ISO_13584_dictionary развивает схему dictionary в следующих аспектах:
Примечание. С вводом структур, определяющих отношения между классами, соответствующие функции семантического словаря поддерживаются на уровне информационной модели. Представляется актуальной поддержка этих функций в LMS на этапе задания экземпляров отношений поставщиком библиотеки, а именно, генерация таких экземпляров диалоговым интерфейсом поставщика.
Наконец, в схеме определяется сущность "библиотека" (library), описывающая общую архитектуру P_LIB. Архитектура конкретной ИБ описывается экземпляром этой сущности. Представленные в нем списки поставщиков, классов, VEP, интерфейсов и семантических отношений обеспечивают связность объекта "библиотека" (возможность просмотра сверху вниз) и позволяют решать разнообразные задачи модификации библиотек единым алгоритмом "компиляция", описываемым ниже.
Схема languge_resource дает средства представления строк на разных языках, необходимые для поддержки функции семантического словаря "перевод внешних имен на разные языки". Эта функция входит в минимальный сервис диалогового интерфейса LMS и должна обеспечить пользователю возможность запрашивать ИБ на языке пользователя и на этом же языке представлять пользователю содержимое библиотеки.
Схема external_file определяет механизм ссылок на внешние файлы и специфицирует способы обработки внешних файлов. Различаются три категории внешних файлов: библиотека программ, содержимое документа и внешний файл содержимого класса. Последняя категория подразделяется на три вида: ссылка на программу, ссылка на представление и диалоговое средство. Каждому внешнему файлу ставятся в соответствие физический адрес размещения его содержимого и интерфейс его обработки, запускаемый LMS.
Каждая категория внешнего файла требует от LMS специального управления. Так, интерфейсом библиотеки программ служит "простой программный интерфейс", с которым библиотеку необходимо связать, чтобы обеспечить поддержку ссылок на программы этой библиотеки. Содержимое документа, помимо интерфейса его обработки, требует спецификации языка, на котором необходимо представлять документ пользователю. Интерфейс ссылки на представление обеспечивает, при необходимости, конвертирование представления в другой формат. Наконец, диалоговое средство (иллюстрация или сообщение) используется в LMS для автоматической выдачи его содержимого на дисплей в определенном контексте работы пользователя.
Остальные шесть схем библиотеки поставщика предназначены для моделирования содержимого библиотеки.
Схема library_content описывает наполнение классов, определенных в семантическом словаре. Наполнение каждого класса характеризуется: множеством свойств, значения которых определяются содержимым класса; множеством операций; множествами диалоговых средств, ссылок на программы и ссылок на представления.
Свойства подразделяются на селективные и вычисляемые. Селективное свойство характеризуется областью допустимых значений, из которых пользователь выбирает требуемое значение. Вычисляемое свойство характеризуется вычислительной функцией, позволяющей определить его значение по значениям других свойств.
Порядок выбора значений селективных свойств в общем случае не произволен и регламентируется так называемыми ограничениями совместности - экземплярами сущностей, описывающих правила продолжения выбора. Каждому продолжению соответствует флаг - булево выражение. При наличии нескольких продолжений со значением флага, равным true, LMS предлагает пользователю выбрать любое из этих продолжений. Если флаги всех продолжений равны false, LMS выбирает первое по списку продолжение. Если продолжение свелось к простому выбору в области значений (в таблице, в интервале значений и пр.), LMS обеспечивает соответствующий диалог с пользователем. Если область допустимых значений вырождается в единственное значение, оно присваивается свойству без участия пользователя.
В схеме определяются два подтипа сущности "содержимое класса" - содержимое класса компонент и содержимое класса функциональной модели. Существенным для LMS элементом структуры "содержимое класса компонент" являются атрибуты "идентификатор поставщика" и "обозначение поставщика", предназначенные для организации прямого доступа к классу по внешнему имени (обозначение используется для диалога с пользователем, идентификатор - для машинного поиска). Значения этих атрибутов могут определяться поставщиком. Если же они не заданы, LMS генерирует эти значения по умолчанию.
Для содержимого класса функциональной модели принципиально важны ссылки на методы создания функционального вида данной категории представления и на список свойств, характеризующих выбранный для формирования вида экземпляр класса компонент. В отличие от содержимого класса компонент, популяция которого всегда содержится в SDAI-модели схемы library_content, популяция содержимого класса функциональной модели может входить в SDAI-модель схемы лишь в случае отсутствия в библиотечном файле схем VEP. Если же таковые имеются (текущая версия P_LIB пока не содержит ни одной модели VEP), то популяция этой сущности распределится по SDAI-моделям VEP, а в схеме library_content этой структуры не будет. Дело в том, что в рамках схемы library_content невозможно гарантировать, что все классы компонент, содержащиеся в ее SDAI-модели, представлены в некоторой категории представления и, например, годятся для формирования видов сборных изделий методами схемы method. В рамках же протокола обмена видами, как и любого стандартного АР, такая гарантия существует.
Схема library_content является информационной основой реализации функции "диалоговый интерфейс пользователя", специфицируемой ниже.
В стандарте P_LIB определены следующие виды операций манипулирования с данными БД: вычислительные функции, ограничения совместности и методы создания видов. Для моделирования операций необходимо иметь средства представления выражений. Такие средства предоставляются схемами instance, instance_operation, expressions и generic_ expressions.
Схема instance, аналогичная по смыслу схеме SDAI_abstract_data_type_schema, определяет типы значений, соответствующих экземплярам классов схемы ditionary, классов общей модели и классов функционального вида. С позиций LMS необходимо выделить сущность "значение экземпляра класса общего вида" - модель представления общего вида в STEP-среде моделирования. Эта сущность предназначена для включения в схему STEP AP. В функции LMS входит формирование экземпляров этой сущности, а также присвоение значений атрибутам "идентификация пользователя" и "обозначение пользователя".
Схема instance_operation дает общие средства описания операций над экземплярами классов библиотеки, а именно:
Схема использует в качестве супертипов понятия "выражение", "обобщенное выражение", определяемые схемами expressions и generic_ expressions соответственно. Эти схемы позволяют моделировать любые арифметические выражения, представимые в языке Express, на уровне метапонятий, т.е. в виде множества взаимосвязанных экземпляров сущностей типа "операнд" и "операция". В задачи LMS входит вычисление выражений по значениям операндов на основе адекватной интерпретации операций и с учетом иерархии их вложенности.
Схема table описывает содержимое таблиц и обобщенных таблиц, столбцы которых соответствуют значениям свойств, определенных в семантическом словаре. Таблица состоит из простых столбцов, содержащих значения простых типов (boolean, real, integer, string). Обобщенная таблица, кроме простых столбцов, имеет комплексные столбцы, значения которых являются экземплярами некоторых сущностей, в частности, ссылками на программу, на представление, на сущность placement. Как и с объектами схемы instance_ operation, с содержимым таблиц LMS связана опосредованно - через интерпретацию операций, определяемых поставщиком.
Наконец, схема method специфицирует методы создания видов компонент (библиотека уровня 1) либо видов сборных изделий (библиотека уровня 2) на основе запуска методов создания видов подобъектов, образующих сборное изделие. Сборное изделие может быть как структурированным (подобъекты заданы вычисляемыми атрибутами), так и ассемблированным (подобъекты заданы атрибутами идентификации). Метод (точнее, тело метода) содержит алгоритм - упорядоченный список команд, которые должны быть выполнены LMS для формирования вида сборного изделия в STEP-среде моделирования. Если подобъектом является компонента, то формирование вида подобъекта осуществляется обращением к программному интерфейсу передачи представления (параметрической программе).
Примечание. Понятие "компонента" в P_LIB несколько перегружено, а именно, используется как синоним не декомпозируемого изделия и в то же время в сочетании "класс компонент" обозначает класс изделий, в том числе декомпозируемых. Поэтому смысл данного понятия следует уточнять по контексту использования.
SDAI-модель схемы method предназначена для непосредственного использования подсистемой LMS "интерфейс передачи представления".
.jpg)