В первых номерах нашего журнала читатель имел возможность познакомиться с системой взглядов и подходов, активно развиваемых в мире и получивших название CALS-технологии. Настоящей статьей мы начинаем серию публикаций, углубляющих наше представление о столь важной проблеме.
Фундаментом CALS-технологий является система единых международных стандартов ISO 10303 (STEP) и ISO 13584 (P_LIB).
ISO 10303 - это международный стандарт для компьютерного представления и обмена данными о продукте. Цель стандарта - дать нейтральный механизм описания данных о продукте на всех стадиях его Жизненного Цикла, не зависящий от конкретной системы. Природа такого описания делает его подходящим не только для нейтрального файла обмена, но и в качестве базиса для реализации и распространения баз данных о продукте, а также для архивирования.
ISO 13584 представляет информацию о библиотеке изделий вместе с необходимыми механизмами и определениями, обеспечивающими обмен, использование и корректировку данных библиотеки изделий. Имеется в виду обмен между различными компьютерными системами и средами, связанными с полным Жизненным Циклом Продукта, где могут использоваться изделия библиотеки, включая проектирование, изготовление, эксплуатацию, обслуживание и утилизацию продукта.
По существу CALS-стандарты включают в себя три группы:
На сегодня в качестве функциональных стандартов в CALS рассматриваются стандарты, определяющие функциональные требования для ввода изделий в эксплуатацию и их поддержки в течение всего Жизненного Цикла. Данная группа стандартов охватывает область разработки функциональных требований к следующим процессам:
Область действия рассматриваемых стандартов включает также информацию, необходимую для работы организаций заказчика и поставщика, а также для обмена данными между ними. Международные стандарты создаются на основе опыта разработки множества существующих стандартов в разных странах.
Помимо вышеуказанных стандартов, охватывающих функциональные спецификации в области логистики, в CALS широко используется способ функционального моделирования, разработанный ранее в проекте USAF "Интегрированное производство" и называемый IDEF0.
IDEF - подмножество самой известной и широко используемой методологии SDAT (Structured Analysis and Design Technique). Он принят в качестве Федерального Стандарта Обработки Информации США, используется в Министерстве обороны Великобритании, НАТО и множеством других различных корпораций, осуществляющих в своей практике функциональное моделирование.
IDEF предназначен для описания различных этапов Жизненного Цикла Изделий и представляет собой графический язык и набор процедур анализа, которые могут быть использованы для понимания и проектирования Жизненного Цикла Изделий как в структуре реального предприятия, так и виртуального.
Особую роль, и пожалуй на сегодня центральную, играют международные информационные стандарты по описанию данных об Изделиях и Процессах. К их числу относят ISO 10303 (STEP), ISO 13584 (P_LIB) и разрабатываемый в настоящее время проект M_DATE.
Общие сведения о стандартах
STEP (STandard, Exchange, Product) - неофициальное название стандарта ISO 10303. Каждый том документации по ISO 10303 начинается с одной и той же преамбулы, определяющей назначение и структуру ISO 10303, а именно: "ISO 10303 - международный стандарт для компьютерного представления и обмена данными о продукте". Цель стандарта - дать нейтральный механизм описания данных о продукте на всех стадиях его Жизненного Цикла, не зависящий от конкретной системы. Природа такого описания делает его подходящим не только для нейтрального файла обмена, но и в качестве базиса для реализации и распространения баз данных о продукте, а также для архивирования.
ISO 10303 организован в серии томов, каждый из которых публикуется отдельно. Тома этого международного стандарта распределены по следующим сериям: методы описания, интегрированные ресурсы, протоколы приложений, наборы абстрактных тестов, формы реализации и тестирование соответствия".
Приведенное определение ISO 10303 нуждается в комментариях.
1. Под продуктом не обязательно понимать материальный продукт производства - продуктом считается результат любого процесса, в частности, разработки технологического плана.
2. Утверждать, что ISO 10303 является стандартом обмена данными о продукте, можно лишь при расширенной трактовке STEP (ISO 10303) как стандарта, включающего в себя стандарты P_LIB и MANDATE. С технологической точки зрения это так и есть, поскольку P_LIB и MANDATE строятся на базе стандарта STEP, заимствуя из него методы описания (язык EXPRESS), формы реализации (обменный файл и интерфейс доступа к данным) и, при необходимости, интегрированные ресурсы (информационные структуры). С потребительской же точки зрения каждый из трех стандартов имеет свою предметную область:
Таким образом, роли обсуждаемых стандартов в моделировании производства распределены следующим образом:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Разработка стандартов P_LIB и MANDATE была инициирована практически одновременно (в 1991 г.). Однако имеющиеся на данный момент результаты несопоставимы.
При почти завершенном стандарте P_LIB по MANDATE нет материалов вообще. Поэтому далее рассматриваются только STEP и P_LIB.
Объектно-ориентированный подход и интеграция знаний
Накопление человечеством знания всегда формулируются в контексте иерархической системы (более строго - ациклической сети) понятий и функциональных связей между этими понятиями. Такая структура представления знаний моделируется при объектно-ориентированном подходе в виде иерархии классов с механизмом наследования общих свойств.
Реализация объектно-ориентированного подхода возможна в двух вариантах. Первый вариант - некоторый набор знаний сразу доводится до уровня машинной программы. В этом случае необходим язык программирования, поддерживающий функционально полное описание класса. Практически это означает, что описание класса должно включать как данные (перечень атрибутов класса), так и "методы" (программы, реализующие полный набор операций над объектами данного класса). Симула-67, С++ - примеры языков объектно-ориентированного программирования, т.е. реализации подхода по первому варианту.
Второй вариант - моделирование иерархии понятий и функциональных связей раздельно. В этом случае из описания класса исключаются методы. Описание становится декларативным и уже не связано с использующей его программой. Независимость описания классов от программной реализации делает излишней конкретизацию формата внутреннего преставления данных в ЭВМ. В итоге приходим к языку Express, предназначенному для описания иерархических систем понятий. Поскольку разнообразие таких систем определяется только разнообразием предметных областей знания, интеграция понятий в единую международную (стандартную) систему понятий становится реально достижимой целью, приближающей к решению глобальной проблемы представления знаний в ЭВМ.
Во втором варианте проектирование программного продукта включает три вида деятельности: информационное моделирование, функциональное моделирование и программную реализацию. Стандарт STEP (в расширенной трактовке) должен обеспечить интеграцию понятий в предметной области "промышленное производство продукции", т. е. представить единую информационную модель этих понятий в виде, формализованном на уровне спецификаций Express.
Функциональное моделирование отвечает за второй элемент представления знаний - функциональные связи между понятиями. Интеграция знаний в этой области пока осуществляется без привлечения ЭВМ (в основном, это интеграция логистических проработок под эгидой SOLE), хотя предпринимаются попытки как-то регламентировать представление знаний, в частности, средствами IDEF0. В стандарте STEP средства IDEF0 используются для иллюстративного представления сферы использования приложения - программной реализации стандартного протокола приложения (АР), содержащего специализированную информационную модель.
Наконец, стандарт STEP касается и третьей компоненты проектирования - программной реализации стандартного АР. Для каждого стандартного протокола его разработчиками составляется набор абстрактных тестов, по которому проверяется реализация протокола на соответствие требованиям АР. Следует отметить, что структура функциональной модели приложения (значит, и представление в ЭВМ функциональных связей между понятиями) не определяется стандартом STEP, а лишь ограничивается снизу требованием, чтобы ЭВМ "владела" понятиями информационной модели, по крайней мере, на уровне минимальных требований, заданных набором абстрактных тестов.
Основные элементы языка Express
В разработке первой версии языка Express участвовало порядка 20 человек в период с 1985 по 1991 гг, так что проблема, разумеется, не ограничивалась изъятием методов из структуры описания класса. Требовалось разработать специализированный язык информационного моделирования, достаточно полный для описания любой системы понятий, связанных с производственной деятельностью, достаточно простой для освоения пользователем-непрограммистом и, наконец, достаточно технологичный для работы приложений с языковыми конструкциями. Конкретизация предметной области использования языка Express была необходима по существу, т. к. имеются области знания с более сложными структурами понятий (например, семиотика), ориентация на которые могла бы привести к чрезмерному усложнению проблемы.
Итак, язык Express предназначен для описания информационных моделей. Информационная модель описывается одной или несколькими взаимосвязанными схемами. Содержимым схемы могут быть следующие элементы:
Все эти описания действительны в пределах схемы.
База данных (БД), формируемая в соответствии с описанием Express-схем, предназначена для хранения произвольного количества экземпляров каждой из сущностей, представленных в схемах. Сущность - информационный объект, характеризующийся идентификатором и списком атрибутов, определяющих свойства каждого из экземпляров сущности, т.е. сущность - это объект, соответствующий вышеупомянутому понятию класса без методов. Остальные элементы описания схемы играют вспомогательную роль, а именно: type-объявления определяют структуру представления атрибутов сущности. Алгоритмы и правила служат для проверки соответствия содержимого БД информационной модели, а интерфейс предназначен для унификации описания объектов (типов, алгоритмов, правил), используемых более чем в одной схеме.
Возможности описания информационных структур в языке Express сводятся, в основном, к следующим. Прежде всего, имеется набор стандартных (встроенных в Express) данных, состоящий из группы простых типов, включающей типы number, integer, real, logical, boolean, binary, string, и из группы агрегативных типов, включающей типы array, bag, list, set - разновидности множества однотипных компонент. При использовании в схеме простых типов real, binary, string можно специфицировать их формат, а при использовании агрегативных типов - их размеры (границы). При этом формат указанных простых типов и размеры агрегативных типов могут быть как фиксированными (для всех экземпляров данного типа), так и переменными (за исключением типа array, имеющего фиксированные границы).
С помощью entity-объявлений и type-объявлений разработчик схемы вводит собственный набор "именованных" типов, дополняя набор стандартных типов до набора "базовых". Базовый тип может использоваться в качестве компоненты агрегативного, а также в entity-объявлении для описания атрибута посредством конструкции
идентификатор атрибута : базовый тип
В type-объявлениях определяемый тип описывается ссылкой на "определяющий" тип, который может быть простым, агрегативным, определяемым, перечисления или селекторным. Тип перечисления - это упорядоченный список конкретных строк-наименований. Селекторный тип - это любой из именованных типов, перечисленных в объявлении селекторного типа.
Каждому типу данных соответствует определенная область допустимых значений - домен. Областью допустимых значений атрибута является домен соответствующего базового типа, который определяется деревом определений типов, связывающих базовый тип с терминальными типами (простыми типами и/или entity-типами), которые и определяют структуру атрибута. В этой структуре каждому простому типу в атрибуте экземпляра сущности должно соответствовать конкретное значение из домена этого типа и каждому entity-типу - ссылка (указатель) на конкретный экземпляр соответствующей сущности.
Домен стандартных типов может иметь переменные размеры. Поэтому структура атрибута может варьироваться по размерам в разных экземплярах сущности. Более того при наличии в entity-объявлении необязательных (optional) атрибутов их структуры в некоторых экземплярах сущности могут отсутствовать вообще. По аналогии с использованием термина "популяция" в документации по Express для обозначения содержимого БД назовем популяцией сущности совокупность всех имеющихся в БД ее экземпляров. Если трактовать популяцию сущности как файл записей - экземпляров сущности, - то, как видим, придется уточнить, что запись может варьироваться в файле по размерам и составу атрибутов (в пределах максимального состава).
Ограниченность значений атрибута рамками домена соответствующего базового типа является необходимым, но не всегда достаточным условием соответствия БД информационной модели. Во-первых, область допустимых значений атрибута может быть частью домена, зависящей от значений других атрибутов экземпляра. Такая зависимость описывается в entity-объявлении "локальными правилами" (where-правила) - логическими выражениями, истинность конъюнкции которых является дополнительным условием соответствия экземпляра сущности информационной модели. Локальные правила используются также в type-объявлениях для сужения домена определяющего типа. Во-вторых, возможны ограничения на допустимость популяций, не представимые на уровне локальных правил, например, требование взаимной согласованности популяций нескольких сущностей. Для описания подобных ограничений в языке предусмотрены логические функции типа глобальных правил (rules).
Для спецификации локальных и глобальных правил язык Express дополнен широким набором операций с данными, тремя формами описания алгоритмов (функция, процедура, правило), наконец, набором стандартных функций и процедур оперирования с данными, короче - средствами функционального моделирования, присущими процедурным языкам программирования.
Примечание. Функции и процедуры имеют в качестве параметров локальные объекты - экземпляры базовых типов. При этом носителем результата выполнения функции является ее идентификатор, а в процедуре перечень возвращаемых (изменяемых) параметров указывается с помощью спецификации var. Правило - это логическая функция с популяциями сущностей в качестве входных параметров.
Возникает вопрос, почему бы теперь не отказаться от исходного принципа декларативности языка Express и использовать его в качестве языка программирования всех функциональных связей y = F(x) между локальными объектами x, y (для спецификации в Express-схеме соответствующих функций и процедур), оставив для дальнейшего программирования только последовательность операций обмена с БД локальными объектами.
К сожалению, при таком подходе не обеспечивается необходимая однозначность интерпретации стандарта, представленного Express-схемой, т. к. результат ряда преобразований типа y = F(x), вообще говоря, зависит от контекста (например, очередности) их выполнения. С использованием же функций для проверки соответствия БД информационной модели таких проблем не возникает в силу вложенности всех функций в контекст проверяемых условий и определенности контекста проверок (для получения однозначного результата проверки необходимо и достаточно наличие проверяемого объекта).
Описание языка Express начинается с утверждения, что значение атрибута не может служить ключом поиска нужного экземпляра. Очевидно, это утверждение не следует понимать как отрицание необходимости процедур поиска по ключу в вычислительном процессе. Скорее всего, это намерение разделить проблему установления связей между экземплярами (это сфера программирования) и проблему описания информационной структуры, позволяющей зафиксировать установленную связь в виде соответствующей ссылки (это сфера применения языка Express). На самом деле полного разделения этих проблем достичь не удается. В связи с этим в Express вводится понятие уникальности значений группы атрибутов в популяции сущности, очевидным образом коррелируемое с понятием ключевых атрибутов для процедуры поиска. Кроме того, если не в самом языке, то в интегрированных ресурсах (том 41 - основы описания и поддержки продукта) в типе string выделяются подтипы identifier и label, первый их которых предназначен для поддержки машинного поиска экземпляра, а второй - для поиска экземпляра экспертом.
Рассмотренный выше тип связи между экземплярами сущностей по атрибутам (с помощью ссылок на необходимые экземпляры) является одним из двух имеющихся в языке Express типов связей. Второй тип связи - "генетический", или механизм множественного наследования, - состоит в следующем. С помощью subtype-предложения в entity-объявлении можно указать список сущностей - непосредственных "предков" (супертипов) данной сущности, от которых она наследует все свойства - атрибуты, правила и алгоритмы. Отношение наследования транзитивно, т.е. вместе с наследованием свойств непосредственных предков наследуются свойства предков вышестоящего уровня, а в итоге - свойства всей "родословной". Наследование атрибутов означает их непосредственное включение в структуру собственных атрибутов сущности, в результате чего образуется "сложный" экземпляр.
При формировании сложного экземпляра необходимо задать значения как собственным атрибутам сущности, так и атрибутам всех предков. Следует заметить, что структура сложного экземпляра, относящаяся ко всей совокупности предков и рассматриваемая с уровня одного из предков сущности, однозначно определена информационной моделью лишь в сторону его предков, но не потомков, состав которых может зависеть от экземпляра. Поэтому при работе со сложным экземпляром на уровне сущности-предка доступу к атрибутам потомков предшествует обращение к стандартной функции typeof, возвращающей список сущностей, представленных в экземпляре.
Помимо механизма наследования, язык Express заимствовал из генетики и идею мутации, реализованную следующим образом: при наличии в одной схеме нескольких подтипов некоторой сущности по умолчанию считается, что в популяции этой сущности возможны экземпляры со свойствами, характерными для любого сочетания указанных подтипов, в связи с чем система обеспечивает автоматическую генерацию entity-объявлений всех возможных подтипов-мутантов. Если какие-то сочетания подтипов заведомо невозможны, это можно указать в entity-объявлении с помощью supertype-предложения.
Полное количество возможных комбинаций подтипов растет с их количеством n по зависимости 2n и при n к [20, 30] оказывается чрезмерным для самой мощной ЭВМ. Строгим решением этой проблемы была бы генерация объявлений необходимых подтипов по факту их появления в популяции сущности, т. е., по сути, переход к концепции динамической информационной модели, перечень типов которой управляется популяцией. Вероятно, такая концепция существенно отклонялась от целей разработки Express, либо для предметной области STEP проблема большой размерности практически не актуальна, в связи с чем ограничились средствами первой необходимости (supertype-предложение, метод усечения множества подтипов при копировании entity-объявлений из других схем).
Остается перечислить языковые средства, обусловленные необходимостью компромисса между объемом памяти (длиной описания) и эффективностью вычислений.
Во-первых, это вычисляемые (derive) атрибуты, функционально зависящие от явных атрибутов экземпляра-сущности. Хранение derive-атрибутов в БД привело бы к избыточности информационной структуры, но их наличие в структуре экземпляра может сократить объем вычислений. Компромисс достигается следующим образом: в структуре хранения популяции сущности в БД derive-атрибуты отсутствуют, а при загрузке экземпляра в оперативную память системой обеспечивается пополнение структуры derive-атрибутами и вычисление из значений.
Во-вторых, это инверсные атрибуты сущности, или "обратные" ссылки. При работе с экземпляром сущности может потребоваться доступ к другим экземплярам той или иной сущности, из которых исходят "прямые" ссылки (по атрибуту) на данный экземпляр. Хотя в системе предусмотрена стандартная функция usedin, формирующая множество таких экземпляров на основе полного просмотра популяции сущности, меньших вычислительных затрат потребовала бы технология фиксации всех "обратных" ссылок на эти экземпляры на этапе появления прямых ссылок при формировании популяции сущности. Такая технология реализуется системой по "заказу" разработчика схемы, представленному в виде соответствующих инверсных атрибутов.
Информационные объекты ISO 10303
Как уже указывалось, цель ISO 10303 - дать стандарт описания данных о продукте на всех стадиях его Жизненного Цикла. Поскольку состав данных о продукте существенно зависит как от дисциплины (классификационной группы) продукта, так и от стадии его Жизненного Цикла, конечной целью ISO 10303 является разработка множества частных информационных моделей протоколов приложений (АР), каждый из которых характеризуется своим контекстом - дисциплиной и стадией Жизненного Цикла Продукта. В то же время было бы неверно разрабатывать АР без учета их частичной пересекаемости по информационным объектам, т. е. возможности выделения в каждом АР контекстно-независимой части и объединения этих частей в группу моделей верхнего уровня - интегрированных ресурсов.
Подкомитетом ТС184/SC4 выбран наиболее простой способ реализации этой возможности, а именно:
Состав документации по информационным моделям ISO 10303 открыт для пополнения новыми томами в рамках соглашения о том, что для ИР отводятся номера томов в интервале 41-199, а для АР - в интервале 201-1199. Кроме того, документация по ИР разделяется на серию общих ресурсов (тома 41-99) и серию ресурсов приложения (тома 101-199). В отличие от общих ресурсов, сфера применимости которых полностью контекстно-независима, ресурсы приложения ориентированы на конкретные области применения. Наконец, к категории ИР можно отнести и библиотеку AIC - Express-схем, описывающих отдельные понятия предметной области, используемые в двух и более АР. Такая форма обеспечения информационной совместимости различных АР поддерживается централизованным ведением этой библиотеки специальной службой SC4.
В настоящее время наиболее проработана как по составу, так и по статусу документов (большая часть томов этой серии уже имеет статус утвержденного стандарта - IS) серия интегрированных общих ресурсов. Серия представлена следующими томами:
Ключевую роль в этой серии играет том 41, определяющий предметную специализацию стандарта STEP. Том состоит из следующих разделов:
Под продуктом понимается результат любого процесса. К ресурсам описания продукта относятся следующие схемы:
Контекстом продукта является его "дисциплина", контекстом определения продукта - спецификация стадии Жизненного Цикла. Определение свойства продукта и представление свойства продукта описываются раздельно в связи с тем, что одно и то же свойство (например, геометрическая форма) может быть представлено разными способами.
Ресурсы поддержки продукта - это перечень понятий, имеющих отношение к продукту в сфере производства. Эти ресурсы представлены следующими схемами:
Наконец, ресурсы управления предназначены для связи перечисленных ресурсов поддержки с данными о продукте при интерпретации ИР на уровне АР. Подчеркнем, что ИР предназначены исключительно для их интерпретации в АР, в связи с чем популяция сущностей ИР в БД возможна только в составе данных того или иного АР.
В томе 49 схема "действие" тома 41 развивается до понятия "процесс", определяется структура процесса и определяются свойства самого процесса, потребляемых ресурсов и производимого продукта. Остальные тома серии общих ресурсов предназначены для описания свойств продукта безотносительно к способу его создания и касаются материального продукта, поскольку речь идет о материалах и геометрической форме элементарных тел и сборных конструкций.
Интегрированные ресурсы серии ресурсов приложения представлены в настоящее время следующими томами:
Большая часть АР, проработанных в настоящее время до уровня Express-модели AIM, связана с поддержкой продукта на стадии конструирования. К этой группе относятся следующие тома:
Стадия проектирования технологий в машиностроении представлена томом 213 - "План изготовления детали на основе процессов ЧПУ". Специальных дисциплин продукта касаются следующие тома:
Судя по представленному списку АР, процесс полномасштабной разработки АР только начинается и пока еще предметная область STEP не намного шире области САПР. Перечень запланированных в SC4 разработок АР на период до 2000-го года также не претендует на охват основных потребностей в информационных моделях. Возможно, этот план пополнится предложениями по разработке взаимосвязанных АР, прорабатываемыми "по горизонтали", и пока не готовыми для принятия на уровне CS4. Однако, не исключено, что причины недостаточной активности в расширении списка АР связаны с несовершенством принципов проектирования системы STEP и, в первую очередь, с недооценкой проблемы информационного обмена между АР.
В изложенной концепции проектирования STEP все АР находятся на одном уровне иерархии. Информационная модель каждого АР - это независимое от остальных АР "натуральное хозяйство", а взаимосвязь между такими хозяйствами происходит посредством "товарообмена" конечными продуктами каждого АР. В эту схему хорошо вписывается типовая задача САПР - конструирование деталей (с помощью программных средств поддержки АР 204, АР 205) с последующей сборкой этих деталей в единую конструкцию (с помощью средств поддержки АР 203). Действительно, "продуктообмен" в данном случае состоит в передаче геометрических моделей деталей из АР 204, АР 205 в АР 203, что обеспечивается как стандартными методами реализации STEP (обменный файл, программный интерфейс доступа), так и стандартными средствами обмена данными между поставщиком и пользователем в системе P_LIB.
На случай более сложных вариантов взаимосвязи АР, чем обмен конечными продуктами, в методах реализации STEP предусмотрена возможность создания программного продукта, имеющего доступ к данным нескольких АР. И в самом деле, почему бы не решить данный вопрос простейшим образом, а именно: взаимосвязь АР - это проблема не информационного, а функционального моделирования и, в конечном счете, программирования.
В неудовлетворительности такого решения пришлось убедиться при разработке конкретных АР, взаимосвязь которых не сводится к продуктообмену. Выяснилось, например, что взаимосвязанная система понятий, включающая продукты, процессы, ресурсы, оргструктуру, такова, что соответствующие ей данные (экземпляры сущностей) невозможно распределить по отдельным АР и необходимо использовать совместно всеми АР либо группами АР. Значит, исходная одноуровневая архитектура моделей АР не годится - требуется структуризация этих моделей, достаточная, по крайней мере, для выделения информационной модели более высокого уровня, содержащей данные общего назначения.
Для решения этой проблемы, получившей название "кооперативное использование АР", в структуре SC4 в марте 1995 г. образована новая группа # 10. В связи с этим в ближайший год следует ожидать появления нового методического руководства по разработке АР.