ГОСТ Р 55344-2012 /ISO/TS 18876-1:2003 Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 1. Обзор и описание архитектуры.
ГОСТ Р 55344-2012/ISO/TS 18876-1:2003
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Системы промышленной автоматизации и интеграция
ИНТЕГРАЦИЯ ПРОМЫШЛЕННЫХ ДАННЫХ ДЛЯ ИХ ОБМЕНА, ОБЕСПЕЧЕНИЯ ДОСТУПА И КОЛЛЕКТИВНОГО ИСПОЛЬЗОВАНИЯ
Часть 1
Обзор и описание архитектуры
Industrial automation systems and integration. Integration of industrial data for exchange, access and sharing. Part 1. Architecture overview and description
ОКС 25.040.40; 35.240.50
Дата введения 2014-01-01
Предисловие
1 ПОДГОТОВЛЕН АНО "Международная академия менеджмента и качества бизнеса" на основе собственного перевода на русский язык англоязычной версии документа, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 100 "Стратегический и инновационный менеджмент"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ
4 Настоящий стандарт идентичен международному документу ISO/TC 18876-1:2003* "Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 1. Обзор и описание архитектуры" (ISO/TS 18876-1:2003 "Industrial automation systems and integration - Integration of industrial data for exchange, access and sharing - Part 1: Architecture overview and description", IDT).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты, сведения о которых приведены в дополнительном
5 ВВЕДЕН ВПЕРВЫЕ
6 ПЕРЕИЗДАНИЕ. Июнь 2020 г.
Правила применения настоящего стандарта установлены в Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
0.1 Обзор комплекса стандартов ИСО 18876
Комплекс стандартов ИСО 18876 определяет технические требования, архитектуру и методологию для интеграции данных промышленных предприятий с целью обмена, организации доступа к данным и их совместного использования. Область применения настоящего комплекса распространяется:
- на совместное использование данных и их интеграцию;
- технические требования к процессам сопоставления моделей, заложенных в основе промышленных систем;
- трансформацию данных.
0.2 Структура настоящего стандарта
Настоящий стандарт организован следующим образом:
- в разделе 1 определяются цели и область применения настоящего стандарта;
- в разделе 2 указываются ссылочные стандарты по тематике;
- в разделе 3 приводятся термины и определения, используемые в настоящем стандарте;
- в разделе 4 описывается структура настоящего стандарта;
- в разделе 5 указываются фундаментальные понятия и положения, на которых основан настоящий стандарт;
- в разделе 6 приводится описание модели процесса интеграции;
- в разделе 7 устанавливаются компоненты архитектуры интеграции;
- в разделе 8 приводится описание процессов сопоставления данных и их консолидация;
- в разделе 9 устанавливается взаимосвязь с другими стандартами по тематике.
0.3 Целевая аудитория
Настоящий стандарт предназначен для следующих специалистов:
- технических директоров, стремящихся определить степень возможного применения комплекса международных стандартов ИСО 18876 на их предприятиях;
- руководителей проектов (реализаторов) с целью получения общего представления о данных на промышленных предприятиях.
1 Область применения
Настоящий стандарт устанавливает архитектуру, методологию и другие особенности интеграции промышленных данных для их обмена, обеспечения доступа и коллективного использования. Поддерживаются нижеследующие операции:
- интеграция данных:
- взятых из различных источников и различных контекстов,
- описанных различными моделями,
- определенных на различных языках моделирования;
- коллективное использование данных в приложениях с учетом архитектуры системы интеграции;
- разрешение конфликтов между моделями, разработанными с различными целями;
- трансляция данных из одной системы кодирования в другую;
- трансляция моделей из одного языка моделирования в другой.
Настоящий стандарт распространяется:
- на модели интеграции;
- методы создания, расширения и обновления моделей интеграции;
- методы создания спецификаций отображения для распределения элементов данных между моделями интеграции и моделями приложений, находящихся в области их применения;
- кодирование и декодирование данных и моделей в различных форматах, таких как SGML [1], XML [7], EXPRESS [3], UML [6] и ИСО 10303-21 [4];
- метод консолидации наборов данных, полученных из различных источников и различных моделей;
- моделирование и отображение языка спецификации;
- архитектуру и общие понятия методологии.
Настоящий стандарт не распространяется:
- на модели интеграции;
- детальную спецификацию методологии.
Примечание - Такие спецификации имеются в других частях комплекса стандартов ИСО 18876 и в других стандартах ИСО;
- трансляцию данных из одного способа кодирования в другой;
- кодирование и декодирование данных и моделей, представленных в различных форматах;
- моделирование и отображение языка спецификации.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты. Для датированных ссылок применяют только указанное издание ссылочного стандарта, для недатированных - последнее издание (включая все изменения).
ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1) - Part 1: Specification of basic notation [Информационные технологии. Абстрактный синтаксис. Система обозначений. Версия 1 (ASN. 1). Часть 1. Спецификация базовой системы обозначений]
ISO 10303-1:1994, Industrial automation systems and integration - Product data representation and exchange - Part 1: Overview and fundamental principles (Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 1. Обзор и основные принципы)
3 Термины, определения и аббревиатуры
3.1 Термины и определения
В настоящем стандарте применены термины с соответствующими определениями, приведенные в ИСО 10303-1.
Примечание - Определения, скопированные из других стандартов, сопровождаются ссылкой на соответствующий стандарт. В указанных случаях определение, данное в ссылочном документе, является нормативным. Его воспроизведение здесь является справочным. В случае какого-либо несоответствия определение, данное в ссылочном документе, имеет преимущество. За определениями следуют примечания. Они конкретизируют порядок адаптации определения, взятого из другого стандарта. Определение, приводимое ниже, является нормативным для целей, рассматриваемых в настоящем стандарте.
3.1.1 модель приложения; МП (application model; AM): Модель, представляющая информацию, используемую в особых целях.
Примечание - Некоторые модели приложений также являются моделями интеграции (см. пункт 3.1.12).
3.1.2 класс (class): Категория или подразделение сущностей.
Примечание - Класс можно определить несколькими способами. Определение класса должно быть максимально широким, даже шире, чем определение по ИСО 15926-2.
Пример - Насос, электростанция, инженер, фантастический космический аппарат - это примеры классов.
3.1.3 понятие (concept): Общее представление или идея некоторой сущности.
3.1.4 данные (data): Представление информации в некоторой форме, удобной для связи, интерпретации, а также для обработки человеком или компьютером.
3.1.5 модель данных (data model): Набор логических структур (конструктивов) для определения структуры и формата данных, как физических, так и абстрактных, в контексте использования некоторой информационной среды.
3.1.6 производное понятие (derived concept): Понятие модели интеграции, определяемое через примитивные понятия.
3.1.7 преобразование кодирования (encoding transformation): Преобразование способа представления элементов данных на компьютере.
Пример - Примером преобразования кодирования является переход от кодов файла схемы EXPRESS, соответствующей ИСО 10303-21, в коды документа XML.
3.1.8 фундаментальное понятие (foundation concept): Примитивное понятие, определяющее базовую мировую основу модели интеграции.
Примечание - Моделей интеграции может быть несколько. Каждая имеет свою собственную парадигму моделирования, характеризуемую фундаментальным понятием, которое она содержит.
Пример - Понятие класса и понятие индивидуальности - это фундаментальные понятия общих моделей интеграции.
3.1.9 общее понятие (general concept): Примитивное широко используемое понятие, являющееся специализацией некоторого фундаментального понятия.
Примечание - Понятие может считаться фундаментальным одной группой людей, и в то же время оно может считаться общим понятием другой группой людей.
3.1.10 индивидуальность (individual): Сущность, пребывающая в пространстве и времени.
Примечание - Данное понятие включает сущности, которые фактически существуют, реально существовали и которые, возможно, существуют (в прошлом, в настоящем, в будущем) в пространстве и времени.
Пример - Конкретный насос с серийным номером N АВС123, электростанция Battersea, сэр Joseph Whitworth, космический корабль Enterprise - примеры индивидуальностей.
3.1.11 информация (information): Факты, понятия или инструкции.
3.1.12 интеграция (integration): Действие, которое создает, модифицирует или расширяет модель интеграции.
3.1.13 модель интеграции; МИ (integration model; IM): Модель приложения, дающая информацию, представленную двумя или несколькими моделями приложения.
3.1.14 отображение (mapping): Соответствие между элементами одной модели и элементами другой модели, отражающее единое смысловое содержание.
Примечание - Отображение может быть односторонним или двухсторонним.
3.1.15 спецификация отображения (mapping specification): Определение преобразований, необходимых для приема информации в соответствии с одной моделью данных и представления некоторой информации в соответствии с другой моделью данных.
Примечание 1 - Спецификация отображения может включать преобразование структуры данных, преобразование значений данных, преобразование кодирования данных и преобразование терминологии.
Примечание 2 - Спецификация отображений может быть процедурной, декларативной или их комбинацией.
3.1.16 модель (model): Ограниченное информационное представление объекта моделирования, удовлетворяющее условию достижения некоторой цели.
3.1.17 контекст модели (model context): Несколько неявных понятий и ограничений, ограничивающих возможное расширение модели без изменения какой-либо существующей декларации.
Примечание 1 - Контекст модели - это класс всех возможных расширений модели.
Примечание 2 - Этот термин более общий, чем термин "контекст приложения", определенный в ИСО 10303-1.
3.1.18 область применения модели (model scope): Диапазон информации, описываемый моделью приложения.
3.1.19 примитивное понятие (primitive concept): Понятие модели интеграции, не полностью определенное терминами других понятий.
3.1.20 особое понятие (specific concept): Примитивное понятие, являющееся специализацией некоторого общего понятия и имеющее ограниченный диапазон применимости.
Пример - Автомобиль, перерабатывающее предприятие, кварк, заказ на поставку, документ XML - это примеры особых понятий.
Примечание - Граница между общим понятием и особым понятием может быть произвольной. Некоторые понятия можно рассматривать и как общие понятия, и как особые понятия.
3.1.21 структурное преобразование (structural transformation): Тип спецификации отображения, преобразующий его в структуру данных.
Примечание - Изменения в структуре могут происходить вследствие перестановки атрибутов, разбивки атрибутов по типам сущности или вследствие создания новых атрибутов.
3.1.22 преобразование терминологии (terminology transformation): Преобразование термина, используемого для ссылки на некоторую сущность.
Примечание - Данное преобразование может иметь место между синонимами в одном языке и в различных языках.
3.1.23 преобразование (transformation): Изменение формы.
3.1.24 вид (view): Ограниченное представление модели данных.
3.2 Аббревиатуры
В настоящем стандарте используются следующие аббревиатуры:
- МП - модель приложения (application model; AM);
Примечание - В ИСО 10303 аббревиатура МП используется для обозначения "Модуль приложения".
- МИ - модель интеграции (integration model; IM).
4 Структура комплекса международных стандартов ИСО 18876
ИСО 18876 состоит из нескольких частей:
- в ISO/TS 18876-1 приводится общий обзор комплекса. Он определяет архитектуру интеграции промышленных данных;
- в ISO/TS 18876-2 устанавливаются методы интеграции моделей приложений, а также методы разработки и расширения моделей интеграции.
Примечание - Для расширения возможностей комплекса международных стандартов ИСО 18876 могут быть разработаны и прочие спецификации моделей, например:
- модели интеграции двух моделей или более;
- модели для частных приложений;
- спецификация отображения, определяющего порядок передачи совокупности данных из одной модели в другую;
- спецификация отображения, определяющего порядок смены языка моделирования;
- методы и языки программирования, поддерживающие определения моделей и спецификаций отображений на различных языках моделирования;
- методы и спецификации кодирования модели и перехода из одной системы кодирования в другую;
- спецификации сервисных услуг и интерфейсов, удовлетворяющих требования практической реализации.
5 Фундаментальные понятия и допущения
В настоящем стандарте используются следующие фундаментальные понятия и допущения.
5.1 Модели интеграции
5.1.1 Принципы
Трехсхемная архитектура модели данных показывает, что для любой модели данных можно получить представление об исходной модели.
Примечание 1 - Трехсхемная архитектура описана в ISO/TR 9007 [2].
В настоящем стандарте указанный принцип расширен. Он включает и другие типы моделей и языков моделирования. При интеграции моделей данный процесс меняется в обратном направлении: создается модель, для которой начальные модели являются представлениями. Модель, созданная таким способом, является моделью интеграции по отношению к начальным моделям: она дает возможность представлять информацию с областью применения какой-либо одной или нескольких исходных моделей (рисунок 1).
|
 |
Рисунок 1 - Модель интеграции
Модель интеграции может быть создана, если может быть достигнуто общее понимание интегрируемых моделей приложения.
Примечание 2 - Указанные результаты получены в работе Barwise и Seligman [9].
Примечание 3 - Трудности создания такой модели указывают на пробел в человеческом понимании сущности модели приложения.
Для некоторой модели приложения может быть несколько моделей интеграции. Эти модели интеграции поддерживают различные варианты точек зрения (рисунок 2).
|
 |
Рисунок 2 - Интеграция с помощью нескольких моделей интеграции
Модели, созданные как модели интеграции, сами могут быть интегрированы. Это означает, что любое произвольное множество моделей может быть в принципе интегрировано путем создания новой модели. Архитектура, определенная в настоящем стандарте, поддерживает данный процесс.
Примечание 4 - Возможным применением архитектуры, определенной в настоящем стандарте, является разработка модели интеграции, устойчивой к процедуре интеграции дополнительной модели. Эта устойчивость означает, что существующая модель интеграции не требует дополнительных изменений по мере интегрирования дополнительных моделей, хотя может потребоваться расширение указанной модели интеграции.
Модели интеграции иногда представляют понятия более общие, чем модели, которые они интегрируют. Это тот самый случай, когда интегрируемые модели имеют конфликтующие ограничения, влияющие на представляемую информацию. Данные ограничения должны сохраняться в процессе интеграции. Они сохраняются в некоторой форме, отличной от исходной формы в структуре модели интеграции.
Примечание 5 - Указанные ограничения могут сохраняться либо в спецификации отображений, либо как данные внутри модели интеграции.
5.1.2 Область применения и контекст
Область применения модели - это то, что модель фактически собой покрывает. Контекст модели - это сумма ограничений на расширение области применения модели без изменения какой-либо существующей декларации. Данные ограничения включают:
- действия, производящие или использующие данные;
- организации, производящие или использующие данные;
- понятия, используемые данной моделью, но не представленные в модели явным образом;
- ограничения, наследуемые в структуре модели.
Модели интеграции могут учитывать две или несколько моделей приложений. Область применения и контекст такой модели интеграции должны быть не менее, чем объединенные области применения и контексты интегрируемых моделей приложений. Соотношение между моделью интеграции и моделями приложений, которые она интегрирует, показано на рисунке 3.
|
 |
Рисунок 3 - Ограниченная модель интеграции
|
 |
Рисунок 4 - Интеграция модели приложения и ограниченной модели интеграции
Начальная модель интеграции (МИ) может иметь широкий контекст. Это означает, что она может поддерживать особенности информации любых других приложений, даже если начальная область применения модели ограничена возможностями моделей, которые она интегрирует (рисунок 5). Потенциальная модель интеграции может быть протестирована путем проверки ее утверждений. Данные утверждения должны быть истинными при всех обстоятельствах, а не только в одном частном случае (контексте). Маловероятно, что это потребует изменения модели интеграции. Но в этом нельзя быть уверенным в случае, если не все требования для полного диапазона моделей приложения в конечном итоге были интегрированы.
|
 |
Рисунок 5 - Использование модели интеграции с широким контекстом
|
 |
Рисунок 6 - Интеграция дополнительных моделей приложений
Если модель интеграции изменена, чтобы удовлетворить требованиям новой модели приложений, и если предшествующая версия модели интеграции не является подмножеством новой версии, то предшествующие спецификации отображений для моделей интеграции уже недействительны. Одна модель является подмножеством другой модели, если каждая декларация первой модели является также декларацией и второй модели. Тогда вторая модель является расширением первой.
Если изменения модели интеграции не являются ее расширением, то новая модель интеграции создается вместе со спецификацией отображений для исходной модели интеграции. При этом сохраняются любые спецификации отображений, которые могут быть созданы для данной модели.
Следовательно, модели интеграции нужно конструировать так, чтобы интеграция последующих моделей приложений приводила к расширению указанной модели. Это справедливо для моделей интеграции с широким контекстом. Ниже представлены их характеристики:
- Каждый объект моделируется в терминах своего естественного смысла, на основе особой парадигмы с учетом особенностей моделируемого окружающего мира.
Примечание 1 - Моделирование некоторой сущности в терминах ее естественного смысла означает, что она остается элементом одного и того же класса в течение всего времени своего существования, не больше и не меньше. В ряде случаев сущности моделируются в терминах некоторой роли, играемой в указанном контексте (например, служащий, работающий по найму). Однако здесь имеется в виду не служащий, который нанимается на всю жизнь, а некоторый субъект.
Пример - Система выплаты жалованья может быть расширена с обслуживания служащих до обслуживания неработающих пенсионеров. Для этого модель должна учитывать различие в статусах служащего и пенсионера.
Названия, выбранные для конструктивов модели, отражают естественный смысл предмета модели.
Примечание 2 - Несоответствующие имена могут ввести пользователя в заблуждение.
- Определения конструктивов модели должны быть четкими и недвусмысленными.
Примечание 3 - Нечеткие или двусмысленные определения могут ввести пользователя в заблуждение.
- В структуре модели должны быть представлены только ограничения, применимые ко всему контексту модели и области применения модели.
Примечание 4 - Если ограничения встроены в структуру модели и если там, где ограничение уже не работает, необходимо расширение, то эту модель нужно менять. Это нежелательно.
- Классы представляются как подклассы/суперклассы (специализация/обобщение) в иерархии, имеющей корни в одном классе.
Примечание 5 - Положение в иерархии "подтип/супертип" - это ключевой элемент при формальном определении понятия. Оно поддерживает соответствующие характеристики наследования и поведения.
- Модель представляет текущее состояние и его изменение и управляет им.
Примечание 6 - Управление изменением состояния модели может быть комплексным. Существует много способов управления с учетом изменения эффективности. Для некоторых целей это может оказаться необходимым. Решение об адресности управления должно приниматься как можно раньше.
- Важно корректное использование языка моделирования, выбранного для представления модели интеграции.
Примечание 7 - Некорректность при использовании языка привносит неопределенность в части интерпретации конструктивов процессором.
5.1.3 Понятие модели интеграции
Понятия, представленные моделью интеграции, могут быть классифицированы как примитивные понятия (см. 3.1.19) и производные понятия (см. 3.1.6). Примитивные понятия - это строительные блоки для определения других понятий. Они могут быть классифицированы следующим образом:
- фундаментальные понятия (см. 3.1.8);
- общие понятия (см. 3.1.9);
- особые понятия (см. 3.1.20).
Данный подход представлен на рисунке 7.
Особые понятия зависят от общих понятий, которые, в свою очередь, зависят от фундаментальных понятий, так как все понятия более низкого уровня определяются существованием одного или нескольких понятий более высокого уровня.
Пример - На верхнем уровне иерархии модель интеграции должна иметь такие фундаментальные понятия, как классификация, соединение и композиция. Общие понятия могут включать и физические понятия. Особые понятия конкретных дисциплин - это те, что ограничены диапазоном их приложения.
|
 |
Рисунок 7 - Примитивные понятия
5.1.4 Полная модель интеграции
Полная модель интеграции (рисунок 8) - это больше, чем набор примитивных понятий. Она включает производные понятия - полезные и действительные комбинации примитивных понятий. Регистрируются только производные понятия.
|
 |
Рисунок 8 - Полная модель интеграции
Рассматриваемая архитектура не требует, чтобы примитивные понятия все время оставались примитивными. Если понятие, изначально бывшее примитивным, перестает быть таковым, то понятия, из которых оно выведено, могут быть идентифицированы/добавлены, а также может быть добавлено и производное. В результате получается производное понятие путем использования передней грани пирамиды. Таким образом, необходима гибкость для отражения нового знания о мире. Это лучше, чем просто констатация знания о мире, ограниченного знанием исследователя в конкретный момент времени. Следовательно, модель интеграции необходимо поддерживать и расширять. Необходимо также иметь механизм ее поддержки и расширения.
5.2 Спецификации отображений
Спецификации отображений устанавливают преобразования, определяющие порядок отображения элементов одной модели на элементы другой модели. Спецификации отображений используются двумя способами:
а) спецификации отображений могут описывать преобразования взаимных отображений подмножества некоторой модели интеграции и ранее созданной модели приложения, управляющей данными, обособленными от данных, управляемых моделью интеграции. В настоящем случае спецификация отображения определяет преобразования на множество элементов одной модели для создания эквивалентного множества элементов другой модели;
b) спецификация отображения может описывать преобразование взаимного отображения подмножества некоторой модели интеграции и модели приложения, используемой как представление. В настоящем случае спецификация отображения описывает, как элементы представления приложения создаются из элементов модели интеграции.
Нижеследующие фундаментальные понятия используются для спецификации отображений, созданных в процессе интеграции.
- Новые примитивные понятия не представлены в спецификациях отображений. Возможности спецификаций отображений ограничены понятиями модели приложения в терминах модели интеграции, а также преобразованиями структуры, терминологией и кодированием.
- Спецификации отображений являются либо декларативными, либо процедурными:
- декларативная спецификация отображения идентифицирует шаблон для элементов одной модели, соответствующий шаблону для элементов другой модели (спецификация отображения является двухсторонней).
Пример 1 - Определение неформальной декларативной спецификации отображения: для каждой сущности модели А, классифицируемой термином "красный" и термином "автомобиль", существует модель В, содержащая объект, являющийся элементом "красный автомобиль".
Пример 2 - Спецификация отображения в таблице отображений, определенной ИСО 10303-214, является декларативным отображением;
- процедурная спецификация отображения определяет процесс, с помощью которого элемент целевой модели может быть создан из элементов модели источника. Для процедурных спецификаций отображений необходима своя спецификация отображения для каждого направления.
Пример 3 - Определение неформальной процедурной спецификации отображения в одном направлении: для каждой сущности модели А, классифицируемой как "красный автомобиль", в модели В можно создать объект, являющийся элементом класса "автомобиль" и элементом класса "красный".
Пример 4 - Спецификация отображения, созданная на языке EXPRESS-X с помощью конструктива отображения, является процедурной спецификацией отображения.
6 Обзор модели процесса интеграции
Модель процесса интеграции включает несколько моделей приложений и модель интеграции. Поэтому все понятия моделей приложений должны быть представлены в модели интеграции, т.е. создается спецификация взаимного отображения между моделью интеграции и каждой моделью приложения.
Существуют три возможных варианта процесса интеграции:
- и модель интеграции, и модели приложений уже существуют до начала процесса интеграции;
- интегрируемые модели приложений уже существуют до начала процесса интеграции, но модели интеграции еще нет;
- модель интеграции уже существует до начала процесса интеграции, но моделей приложений еще нет, их нужно разработать с учетом наложенных требований.
Первый вариант из трех вышеуказанных включает все элементы двух других вариантов. Он описан здесь на схеме для одной модели приложения. Другие два процесса описаны более детально в ИСО/ТС 18876-2.
Интеграция модели приложения с моделью интеграции приведена на рисунке 9. Цель данного процесса интеграции - позволить информации, представленной в моделях приложений, быть представленной в модели интеграции без потери смысла, а также разрешить взаимные преобразования данных представлений. Результатом процесса интеграции является создание спецификации взаимных отображений моделей приложений и части модели интеграции. Для определения настоящей спецификации отображения может оказаться необходимым расширить модель интеграции, чтобы последняя точно представляла понятия, имеющиеся в модели приложения.
|
 |
Рисунок 9 - Интеграция моделей приложений с моделью интеграции
Функции модели интеграции следуют из той роли, которую она играет по отношению к другим моделям. Фундаментальная характеристика модели интеграции заключается в том, что она интегрирует две или несколько моделей приложений.
Процесс интеграции модели приложения с моделью интеграции включает следующие шаги:
- анализ модели приложения и идентификация эквивалентного понятия модели интеграции, включая любые наложенные ограничения (рисунок 10).
Примечание 1 - Большая часть моделей приложений имеет модельный контекст, внутри которого модель воспринимается. В явном виде данный контекст в модели не обозначен. Обычно не совсем корректно добавлять данную информацию в модель приложения в явном виде. В данном случае указанные требования накладываются в спецификации отображения как часть процесса интеграции.
|
 |
Рисунок 10 - Анализ моделей приложения
Примечание 2 - Для объектов моделей приложений и модели интеграции используются различные символы, указывающие, что данные объекты являются информационными. Это имеет место, даже если они относятся к одним и тем же реальным объектам окружающего мира;
- при необходимости расширения модели интеграции так, чтобы она включала все понятия модели приложения (рисунок 11);
|
 |
Рисунок 11 - Добавление отсутствующих понятий в модель интеграции
- идентификация части модели интеграции, представляющей понятия в каждой модели приложения (рисунок 12);
|
 |
Рисунок 12 - Идентификация подмножества модели интеграции
- создание спецификаций взаимных отображений в каждом направлении всех моделей приложения и соответствующего подмножества модели интеграции (рисунок 13).
Примечание 3 - Идентификация подмножества модели интеграции - это побочный продукт процесса интеграции.
|
 |
Рисунок 13 - Создание спецификации взаимного отображения подмножества модели интеграции и модели приложения
- задание необходимых структурных преобразований, терминологических преобразований или преобразований кодирования, используемых внутри спецификации отображений;
- задание необходимых взаимных преобразований в представленных моделях.
Пример 1 - Если модель приложения задана на языке определений XML Schema, а модель интеграции, на которую она отображается, определена на языке EXPRESS [3], то преобразования между указанными языками будут необходимы для взаимных отображений между различными представлениями одних и тех же понятий.
Большая часть моделей приложения имеет контекст модели, внутри которого модель воспринимается. Данный контекст не представляется в модели приложения явно. Для успешного отображения в обе стороны необходимо, чтобы и явная модель, и соответствующий модельный контекст отображались на модель интеграции. Возможно задание спецификации двусторонних отображений, если все элементы моделей приложения могут быть отображены на модель интеграции и если обратная спецификация отображения позволяет всем элементам модели интеграции (или только ее элементам, соответствующим контексту модели приложения) отображаться в обратном направлении.
Пример 2 - Система выплаты жалованья может иметь тип данных сущности, называемой "служащий". Однако часто неявно, что каждое лицо, представленное элементами указанного типа данных сущности, является служащим компании, управляющей системой и имеющей законное право нанимать работников в рамках политики, проводимой данной компанией и правительством страны.
7 Интеграция компонентов архитектуры
На рисунке 14 показаны элементы рисунка 9 для случая, когда язык моделирования комбинации "сущность-атрибут-соотношение" используется вместе со ссылочными данными. Для каждой поименованной клетки может быть создан стандартный элемент в соответствии с нижеследующим:
Примечание 1 - Объектно-ориентированные модели рассматриваются в настоящем стандарте как модели комбинации "сущность-атрибут-соотношение";
- модели интеграции.
Примечание 2 - Это может быть одиночная модель с несколькими уровнями абстракции, использующая приемлемый язык с логической базой (например, KIF [16]), или многослойная модель, использующая язык типа EXPRESS [3] для описания комбинации "сущность-соотношение", а также модель данных и библиотеки ссылочных данных. Рисунок 14 иллюстрирует порядок использования модели для определения структуры библиотеки ссылочных данных, которая может содержать ссылочные классы и ссылочные индивидуальности.
|
 |
Рисунок 14 - Интеграция компонентов архитектуры
Примечание 3 - Ссылочные классы и ссылочные индивидуальности могут быть собраны вместе в библиотеку ссылочных данных. Библиотек ссылочных данных может быть несколько. Если указанные библиотеки предназначены для совместного использования, то они не должны перекрываться. Необходимо также организовать ссылки из одной библиотеки в другую;
- спецификации отображений.
Примечание 4 - Спецификации отображений могут включать идентификацию подмножеств модели интеграции.
Примечание 5 - Спецификации отображений могут включать ограничения, определяющие подмножество элементов модели интеграции, отображаемой на модель приложения.
Примечание 6 - Спецификации отображений могут включать структурные преобразования между структурой модели интеграции и структурой модели приложения.
Примечание 7 - Спецификации отображений могут включать терминологические преобразования между моделью интеграции и моделью приложения.
Примечание 8 - Могут потребоваться спецификации двухсторонних отображений языков спецификации моделей;
- модели приложений.
Существует большое число различных языков моделирования. Может оказаться необходимым интегрировать данные между моделями, определенными в соответствии с требованиями различных языков моделирования. Соответственно может оказаться необходимым определить спецификации взаимных отображений различных языков моделирования.
Примечание 9 - Может оказаться возможным использовать несколько спецификаций взаимных отображений двух различных языков моделирования.
Пример - ИСО 10303-28 содержит несколько спецификаций взаимных отображений моделей, представленных на языках EXPRESS (см. ИСО 10303-11) и XML.
8 Отображение данных и их консолидация
Создания спецификаций взаимных отображений моделей недостаточно для интеграции. Необходимо согласование информации, представленной различными моделями. Этот процесс иллюстрируется на рисунке 15:
|
 |
Рисунок 15 - Консолидация (объединение) данных
- определите, какие элементы в двух указанных наборах данных представляют одни и те же сущности, и объедините (консолидируйте) их в совокупность данных 3.
Примечание - Для выполнения указанной операции необходим универсальный, надежный, работоспособный механизм идентификации. Для этого нет необходимости определять какие-либо новые атрибуты, используемые в различных системах. Допускается использование существующих атрибутов. Возможно существование набора атрибутов и соотношений, которые вместе обеспечивают уникальную идентификацию. Любой из них может быть отображен на независимой схеме идентификации.
9 Соотношения с другими стандартами
Настоящий стандарт может быть использован совместно с другими стандартами. Прежде всего, это случай, когда интеграция нескольких моделей достижима путем конструирования.
Пример 1 - ИСО 15926-2 [5] определяет модель данных и библиотеку ссылочных данных, которые вместе формируют модель интеграции для технологических приложений.
Настоящий стандарт может также использоваться для интеграции существующих информационных стандартов в случае, когда интеграция путем конструирования недостижима.
Пример 2 - Методология, описанная в ИСО/ТС 18876-2, может использоваться для интеграции возможности обмена данных о продукте, определенной протоколом приложения (см. ИСО 10303), и возможности обмена данными, установленной определением типа данных в документе XML.
Приложение А
(обязательное)
Регистрация информационного объекта
Для идентификации информационного объекта в открытой системе настоящему стандарту присвоен следующий идентификатор объекта:
{ISO standard 18876 part {1} version {1}}
Смысл значения настоящего идентификатора определен в ИСО/МЭК 8824-1 и описан в ИСО 10303-1.
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
|
|
|
Обозначение ссылочного международного стандарта | Степень соответствия | Обозначение и наименование соответствующего национального стандарта |
ISO/IEC 8824-1 | IDT | "Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации" |
ISO 10303-1:1994 | IDT | "Системы автоматизации производства и их интеграция. Представление данных об изделии и обмен этими данными. Часть 1. Общие представления и основополагающие принципы" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:
- IDT - идентичные стандарты.
| ||
Библиография
|
|
|
[1] | ИСО 8879:1986 | Обработка информации. Текстовые и офисные системы. Стандартный обобщенный язык разметки (SGML) |
| ISO 8879:1986 | Information processing - Text and office systems - Standard Generalized Markup Language (SGML) |
[2] | ISO/TR 9007:1987 | Системы обработки информации. Понятия и терминология для концептуальной модели базы данных |
| ISO/TR 9007:1987 | Information processing systems - Concepts and terminology for the conceptual schema and the information base |
[3] | ИСО 10303-11:2004 | Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 11. Методы описания. Справочное руководство по языку EXPRESS |
| ISO 10303-11:2004 | Industrial automation systems and integration - Product data representation and exchange - Part 11: Description methods: The EXPRESS language reference manual |
[4] | ИСО 10303-21:2002 | Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 21. Методы реализации. Кодирование открытого текста структуры обмена |
| ISO 10303-21:2002 | Industrial automation systems and integration - Product data representation and exchange - Part 21: Implementation methods: Clear text encoding of the exchange structure |
[5] | ИСО 15926-2:2003 | Системы промышленной автоматизации и интеграция. Интеграция данных о сроке службы нефтехимических установок, включая установки по добыче нефти и газа. Часть 2. Модель данных |
| ISO 15926-2:2003 | Industrial automation systems and integration - Integration of life-cycle data for process plants including oil and gas production facilities - Part 2: Data model |
[6] | ИСО/МЭК 19501:2005 | Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2 |
| ISO/IEC 19501:2005 | Information technology - Open Distributed Processing - Unified Modeling Language (UML). Version 1.4.2 |
[7] | Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation 6 October 2000 [cited 2001-05-16]. Available from the Internet: <http://www.w3.org/TR/REC-xml> | |
[8] | Integration Definition for Information Modeling (IDEF1X). Federal Information Processing Standards Publication 184, December 1993 | |
[9] | BARWISE, Jon; SELIGMAN, Jerry. Information flow: the logic of distributed systems. Cambridge: Cambridge University Press, 1997 | |
[10] | FOWLER, Julian. Industry requirements for SC4 standards. ISO TC184/SC4/WG10 N173, 1998 [cited 2001-05-09]. Available from the Internet: <http://www.nist.gov/sc4/wg_qc/wg10/current/n173/wg10n173.htm> | |
[11] | GUARINO, Nicola. Some Organizing Principles for a Unified Top Level Ontology. Proceedings of AAAI Spring Symposium on Ontological Engineering, Stanford, CA: AAAI Press, 1997 | |
[12] | GUARINO, Nicola. Some Ontological Principles for Designing Upper Level Lexical Resources. Padua: 1998 [cited 2001-05-09], available from the Internet: <http://www.ladseb.pd.cnr.it/infor/Ontology/Papers/LREC98.pdf> | |
[13] | PARTRIDGE, Chris. Business objects: re-engineering for reuse. Oxford: Butterworth Heinemann, 1996 | |
[14] | SOWA, John F. Knowledge representation: logical, philosophical, and computational foundations | |
[15] | WEST, Matthew; FOWLER, Julian. Developing High Quality Data Models. Version 2.0, Issue 2.1. EPISTLE, 1996 [cited 2001-05-09]. Available from the Internet: <http://www.matthew-west.org,uk/Documents/princ03.pdf> | |
[16] | Knowledge Interchange Format, draft proposed American National Standard (dpANS), NCITS.T2/98-004, [cited 2002-02-04]. Available from the Internet: <http://logic.stanford.edu/kif/dpans.html> | |
|
|
УДК 658.52.011.56 | ОКС 25.040.40; 35.240.50 |
| |
Ключевые слова: автоматизированные промышленные системы, интеграция, жизненный цикл систем, управление производством | |