Это уже третья статья (см. # 2 и # 3 за 1997 г. журнала) из серии публикаций о столь важной проблеме, как CALS-технологии.
Основные функции системы управления библиотекой в стандарте P_LIB
Компиляция интегрированной библиотеки
Связь P_LIB с внешней средой осуществляется единственным способом - посредством компиляции (слияния) библиотеки принимающей системы с одной или несколькими библиотеками поставщика. Все эти библиотеки представляют собой экземпляры сущности library, так что библиотека принимающей системы отличается от остальных только ролью или направлением передачи информации.
Каждая из компилируемых библиотек может содержать, кроме контекста обмена P_LIB, внешние файлы, которые должны быть включены в библиотеку принимающей системы, если их там нет. Процедура пополнения библиотеки принимающей системы недостающими внешними файлами, предшествующая компиляции контекстов обмена (библиотечных файлов) библиотек поставщиков, в общем случае не сводится к копированию этих файлов - может потребоваться обработка того или иного файла с помощью приданного ему интерфейса.
Общий принцип модификации данных в библиотеке P_LIB - полная замена информации, связанной с идентификатором BSU, на информацию более поздней версии. Поэтому в контексте обмена не требуется задавать какие-либо признаки вставки или замены - они вырабатываются автоматически с учетом следующих правил интерпретации структуры контекста обмена:
1) если в структуре обмена имеется только BSU, то предполагается, что дескриптор (dictionary_element) и содержимое (content_item) находятся в семантическом словаре принимающей системы и BSU служит для ссылки на эти элементы;
2) если заданы BSU и дескриптор, то предполагается, что в принимающей системе content_item отсутствует, а структура контекста обмена служит для вставки в семантический словарь принимающей системы либо для корректировки в словаре прежней структуры;
3) если заданы BSU, дескриптор и содержимое, то предлагается занесение либо корректировка всех трех элементов в принимающей системе.
Схема алгоритма компиляции
Процесс компиляции представляет собой двух шаговый процесс.
На первом шаге в контексте обмена должны быть сформированы все инверсные ссылки, предусмотренные информационной моделью тома 24 P_LIB. Кроме того, если в экземпляре library контекста обмена значение атрибута is_reference_ hierarchy равно true, то для этой библиотеки необходимо определить и создать инверсные атрибуты от class_BSU к экземплярам property_BSU, domain_specification_BSU и table_BSU, которые ссылаются на этот class_BSU по атрибутам name_scope.
Примечание. Причина отсутствия указанных инверсных атрибутов в информационной модели ISO_13584_dictionary_ schema состоит в том, что они нужны не всегда, в частности, не нужны для поддержки электротехнического стандарта IEC 1360.
На втором шаге при наличии нескольких библиотек они компилируются последовательно в порядке возрастания уровня библиотеки (атрибута library_level) и для каждого уровня в любом порядке. Процесс компиляции каждой библиотеки состоит в последовательной компиляции каждого атрибута экземпляра сущности library, а для агрегативных атрибутов типа list - в компиляции элементов агрегата в порядке list. Компиляция каждого элемента состоит в его обработке (вставка либо замена в принимающей библиотеке) и затем в компиляции всех элементов, связанных с данным элементом прямыми или инверсными ссылками.
Правила семантического контроля
Обработка любого элемента может быть прервана. Прерывание не означает, что прекращается процесс компиляции в целом, и сопровождается следующими действиями:
1) процесс возвращается в состояние, соответствующее началу компиляции текущего элемента, на который ссылается library;
2) этот элемент пропускается и процесс компиляции продолжается.
Обработка базового интерфейса прерывается, если в библиотеке пользователя в атрибуте base_interfaces не оказывается интерфейса, указанного в библиотеке поставщика.
Обработка view_exchange_protocol_id прерывается, если в атрибуте supported_vep библиотеки пользователя не оказывается протокола VEP, описанного в библиотеке поставщика.
Обработка поставщика прерывается, если его dictionary_element отсутствует в библиотеке поставщика и в библиотеке пользователя.
Обработка program_library_BSU прерывается, если
1) его dictionary_element отсутствует в библиотеке поставщика и в библиотеке пользователя, либо
2) его content_item отсутствует в библиотеке поставщика и в библиотеке пользователя, либо
3) его версия больше, чем версия соответствующего BSU в библиотеке пользователя, а его dictionary_element отсутствует в библиотеке поставщика, либо
4) его версия больше, чем версия соответствующего BSU в библиотеке пользователя, а его content_item отсутствует в библиотеке поставщика, либо
5) его dictionary_element существует и ссылается на интерфейс, обработка которого прервана.
Обработка редактируемого интерфейса прерывается, если
1) обработка его базового интерфейса прервана либо
2) прервана обработка какого-либо program_library_ BSU, на который идет ссылка из его link_libraries.
Обработка class_BSU прерывается, если
1) его dictionary_element отсутствует в библиотеке поставщика и в библиотеке пользователя либо
2) его версия больше, чем версия соответствующего BSU в библиотеке пользователя, и его dictionary_element отсутствует либо
3) его dictionary_element имеется в библиотеке поставщика, библиотека пользователя содержит content_item с соответствующим BSU, а content_item с соответствующим BSU в библиотеке поставщика отсутствует, либо
4) прервана обработка какого-либо BSU, явно или неявно связанного с class_BSU (например, через name_scope или supplier_BSU) либо с элементом content_item этого класса, либо
5) прервана обработка какого-либо интерфейса или протокола VEP, на которые ссылается content_item этого класса.
Обработка BSU, связанного с dictionary_ele-ment класса, прерывается, если
1) его dictionary_element отсутствует в библиотеке поставщика и в билиотеке пользователя, либо
2) его версия больше, чем версия соответствующего BSU в библиотеке пользователя, и его dictionary_element отсутствует, либо
3) его версия больше, чем версия соответствующего BSU в библиотеке пользователя, библиотека пользователя содержит content_item с соответствующим BSU, а в библиотеке поставщика content_item с соответствующим BSU отсутствует, либо
4) это table_BSU, которая не имеет соответствующего BSU в библиотеке пользователя и ее table_content отсутствует, либо
5) это document_BSU, который не имеет соответствующего BSU в библиотеке пользователя и его document_content отсутствует.
Обработка семантического отношения прерывается, если прервана обработка какого-либо class_ BSU, указанного в отношении.
Адаптация библиотеки пользователем
Адаптация пользователем библиотеки поставщика состоит в выполнении следующих манипуляций над библиотекой:
1) удаление классов изделий;
2) удаление изделий из класса;
3) добавление атрибутов в описание класса.
Поддержка этих манипуляций непроста, если учесть, что представление данных определения класса изделий в библиотеке поставщика может иметь форму виртуальной таблицы, т.е. нескольких базовых таблиц, связанных правилами объединения. За неимением лучшего стандартом предлагается следующее решение.
Множество таблиц, определяющих библиотеку поставщика, сохраняется неизменным и дополняется по запросу пользователя, дубликатами некоторых таблиц. Над дубликатами пользователь осуществляет необходимые изменения (удаление строк, добавление атрибутов). В случае виртуальных таблиц правила объединения должны быть переключены на обработку дубликатов.
После модификации дубликаты таблиц используются вместо исходных таблиц, представляя, тем самым, библиотеку пользователя вместо библиотеки поставщика.
Предложенное решение позволяет создавать новые версии библиотеки пользователя при неизменном содержимом библиотеки поставщика. Следует, кроме того, обеспечить возможность автоматической реконструкции библиотеки пользователя при изменении библиотеки поставщика. В случае несовместимости этих изменений с прежней модификацией библиотеки необходимо выдавать пользователю диагностические сообщения.
Диалоговый интерфейс пользователя
Диалоговый интерфейс поддерживает следующие операции пользователя:
1) поиск нужного класса изделий в ИБ;
2) поиск нужного изделия в классе;
3) выбор нужной категории представления изделия (класса функциональной модели);
4) запуск метода для вставки выбранного представления изделия в STEP-модель проектируемой конструкции.
Как указывалось ранее, диалог пользователя с LMS осуществляется на языке, выбранном пользователем.
Для поиска изделия LMS предоставляет пользователю следующие методы доступа к ИБ:
1) по иерархии классов изделий;
2) прямой доступ к классу (или изделию) по внешнему идентификатору класса (или изделия);
3) реляционный доступ к изделию по булевым выражениям, связанным со значениями атрибутов.
Для поддержки реляционного доступа необходимо организовать в системе словари наименований классов и атрибутов.
Иерархический поиск предполагает выдачу на экран пользователя в каждом узле дерева следующих данных:
а) меню, содержащих текстуальное и (или) графическое представление класса;
б) неформального описания класса, облегчающего пользователю процесс поиска.
Эти данные формируются поставщиком. Объем данных, вводимых по изделиям, может быть по требованию пользователя дополнен данными по одному или нескольким классам функциональной модели, определенным для данного класса компонент, а при выборе изделия в классе - данными неинстанциируемых функциональных видов (схема ISO_13584_ dictionary), если таковые представлены поставщиком.
Хотя запуск метода генерации представления входит в диалоговые средства пользователя, удобнее рассмотреть эту операцию в контексте системы управления интерфейсом передачи представления.
Как свойства самого изделия, так и свойства его представления, вообще говоря, зависят от контекста его использования в системе моделирования. Однако передача пользователем параметров контекста в ИБ, предшествующее поиску изделия, не является специальной операцией LMS, поскольку соответствующий диалог с пользователем обеспечивается средствами поставщика либо CAD-системы.
Интерфейс передачи представления в STEP-среду моделирования
В первой версии P_LIB определен программный интерфейс передачи геометрического представления компоненты в STEP-среду моделирования (в SDAI-модель любого АР), Этот интерфейс представлен библиотекой фортран-программ, на базе которой поставщиком составляется параметрическая фортран-программа, осуществляющая отображение представления класса изделий из пространства параметров в пространство геометрических объектов принимающей среды (2D, 3D-проволочная модель, твердотельная 3D-модель). Наряду с геометрической моделью компоненты, в принимающей системе генерируется визуальное представление компоненты в контексте модели сборной конструкции с учетом необходимости удаления невидимых линий и соблюдения оформительского стиля принимающей системы (толщина линий, цвета, font). Разработка данного программного интерфейса сводится к разработке библиотеки фортран-подпрограмм, спецификации которых представлены в томе 31 P_LIB. Этот интерфейс не зависит ни от принимающей системы ни от логических ресурсов P_LIB и может функционировать на основе SDAI-интерфейса.
Система управления интерфейсами передачи представления, в частности, рассмотренным геометрическим интерфейсом, функционирует по алгоритму "метод", основанному на нижеследующих предположениях и правилах.
1. Определяемые поставщиком методы предназначены только для формирования функциональных видов.
2. Функциональные виды - это представления, определяемые в их собственном контексте представления, называемом object view coordinate (OVC).
3. При запуске метода пользователем с помощью LMS системой выполняется неспецифицируемый процесс позиционирования, позволяющий пользователю специфицировать преобразование из контекста представления вида в контекст представления системы моделирования. В конце запущенного пользователем метода функциональный вид создается в пользовательской системе моделирования и LMS возвращается в начальное состояние.
4. Метод состоит из двух сущностей: сущности "спецификация метода", которая определяет все функциональные виды, генерация которых доступна методу, и сущности "тело метода", которая определяет алгоритм метода в виде упорядоченного списка команд. Каждая команда списка может иметь флаг. Команды с флагом позволяют реализовать конструкцию "if then else".
5. Команды, составляющие метод - это
а) нуль-команда моделирования, которая специфицирует преобразование OVC: преобразование применяется ко всем элементам представления, образующим вид, после того как это преобразование специфицировано;
б) команда вызова предопределенного представления, которая специфицирует вызов явного или неявного (генерируемого программой) представления;
в) команда присваивания, присваивающая значение переменной;
г) команда "вид подобъекта", которая позволяет методу запускать методы подобъектов, образующих сборное изделие. Вид, создаваемый этим методом, отображается в контекст встраивающего вида посредством текущего преобразования OVC этого вида.
6. Метод может генерировать только функциональные виды одной и той же категории представления, идентифицируемой сущностью class_BSU.
7. Метод может генерировать разные функциональные виды одной категории представления.
8. Функциональный вид содержит ряд атрибутов и, будучи подтипом representation, наследует атрибут items. Этот атрибут либо может иметь значения либо заполняется одним из трех способов: через внешнее представление, программой, связанной с интерфейсом и через определенное внутри представление.
9. Методы запускаются передачей сообщения. Сообщение содержит следующую информацию:
а) требуемый функциональный вид, представленный соответствующим class_BSU;
б) список переменных управления видом, однозначно специфицирующий требуемый функциональный вид.
10. При запуске метод связывается с единственным функциональным видом, а именно, видом, заданным в запускающем сообщении. Этот вид называется открытым видом выполняемого метода.
11. При выполнении метод всегда связывается с одним экземпляром класса функциональной модели, который может содержать среди своих атрибутов копии атрибутов одного экземпляра класса общей модели. Если последняя является сборным изделием, метод может посылать сообщения подобъектам этого изделия или может инстанциировать функциональные модели этих подобъектов.
12. Если метод запускается из другого метода, новый открытый вид связывается с этим методом. Текущее преобразование OVC открытого метода, связанного со встраивающим методом, специфицирует преобразование, которое должно быть выполнено над контекстом представления открытого вида, связанного со встраивающим методом, чтобы обеспечить адекватное отображение создаваемого вида в контекст представления встраивающего вида. По завершении метода этот вид закрывается.
13. Сообщение может быть послано либо в общую модель (экземпляру component_class_con-tent) либо в функциональную модель (экземпляру function_model_class_content).
14. Если общая модель получает сообщение, LMS находит среди классов функциональной модели, являющихся видами класса этой общей модели, класс, экземпляры которого поддерживают данное сообщение. Этот класс инстанциируется и созданному экземпляру посылается сообщение. В результате генерируется новый функциональный вид. Общая модель идентифицируется параметром self_attribute_variable_value экземпляра, запустившего метод.
15. Если экземпляр function_model_class_con-tent получает сообщение, этот экземпляр должен поддерживать метод, указанный в сообщении. Экземпляр класса функциональной модели специфицируется его классом BSU, параметром self_attribute_variable_value, идентифицирующим общую модель, на которую экземпляр ссылается, и, возможно, параметрами контекста, этот класс инстанциируется и созданный экземпляр получит сообщение. Затем запускается метод и генерируется функциональный вид.
ЗАКЛЮЧЕНИЕ
Авторы сознают неисчерпаемость поставленной задачи, частично раскрытой в опубликованном "сериале". Также они понимали, что журнальные публикации не позволят детально рассмотреть интереснейшую с их точки зрения проблему с достаточной полнотой.
Но состояние мировой научной и практической деятельности в области CALS-технологий, тенденции интеграции бизнеса, правительственных учреждений, общественных объединений для решения задач современного промышленного развития во всех цивилизованных странах и мирового сообщества в целом требуют фиксации внимания на проблемах стандартизации соответствующих специалистов и организаций России.
Последние разработки Верховной управляющей группы Международного Конгресса по вопросам CALS (ICC)* посвящены определению требований к общей модели виртуального предприятия для реализации CALS. Так как модель будет определена на высоком уровне общности , то на этом уровне определятся достаточно общие семейства стандартов, например, STEP для данных об изделии и т. п.
В дальнейшем, указанная модель становится основой для конкретных разработок в отраслях со своими специфическими особенностями. Соответственно конкретизируются и стандарты, например, прикладные протоколы STEP.
Масштабы работы оцениваются ICC как столь значительные, что под силу лишь объединенным усилиям всего мирового сообщества. И в этой ситуации России не следует игнорировать вызов к интеллекту своих специалистов.