allgosts.ru25. МАШИНОСТРОЕНИЕ25.040. Промышленные автоматизированные системы

ГОСТ Р 55344-2012 Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 1. Обзор и описание архитектуры

Обозначение:
ГОСТ Р 55344-2012
Наименование:
Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 1. Обзор и описание архитектуры
Статус:
Действует
Дата введения:
01/01/2014
Дата отмены:
-
Заменен на:
-
Код ОКС:
25.040.40, 35.240.50

Текст ГОСТ Р 55344-2012 Системы промышленной автоматизации и интеграция. Интеграция промышленных данных для их обмена, обеспечения доступа и коллективного использования. Часть 1. Обзор и описание архитектуры



ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

55344—

2012/ISO/TS

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)

Издание официальное

Москва

Стакдартинформ

2014


Предисловие

1    ПОДГОТОВЛЕН АНО «Международная академия менеджмента и качества бизнеса» на основе собственного аутентичного перевода на русский язык международного документа, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК100 «Стратегический и инновационный менеджмент»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2012 г. № 1705-ст

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»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0—2012 (раздел В). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменении и поправок—в ежемесячном информационном указателе «Национальные стан• дарты». В случае пересмотра (замены) или отмены настоящего стандарта соотеетстеующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.nj)

© Стандартннформ. 2014

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

Содержание

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

Введение

0.1 Обзор комплекса стандартов ИСО 18876

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

-    совместное использование данных и их интеграцию:

•    технические требования к процессам сопоставления моделей, заложенных в основе промышленных систем;

-    трансформацию данных.

0.2 Структура настоящего стандарта

Настоящий стандарт организован следующим образом:

•    в разделе 1 определяются цели и область применения настоящего стандарта;

-    в разделе 2 указываются ссылочные стандарты по тематике:

•    в разделе 3 приводятся термины и определения, используемые в настоящем стандарте;

•    в разделе 4 описывается структура настоящего стандарта;

-    в разделе 5 указываются фундаментальные понятия и положения, на которых основан настоящий стандарт;

-    в разделе 6 приводится описание модели процесса интеграции;

-    в разделе 7 устанавливаются компоненты архитектуры интеграции;

-    в разделе 8 приводится описание процессов сопоставления данных и их консолидация;

-    в разделе 9 устанавливается взаимосвязь с другими стандартами по тематике.

0.3 Целевая аудитория

Настоящий стандарт предназначен для следующих специалистов:

-    технических директоров, стремящихся определить степень возможного применения комплекса международных стандартов ИСО 18876 на их предприятиях;

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

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системы промышленной автоматизации и интеграция

ИНТЕГРАЦИЯ ПРОМЫШЛЕННЫХ ДАННЫХ ДЛЯ ИХ ОБМЕНА, ОБЕСПЕЧЕНИЯ ДОСТУПА

И КОЛЛЕКТИВНОГО ИСПОЛЬЗОВАНИЯ

Часть 1

Обзор и описание архитектуры

industrial automation systems and integration. Integration of industrial data for exchange, access and shanng.

Part 1. Architecture overview and description

Дата введения — 2014—01—01

1 Область применения

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

•    интеграция данных:

•    взятых из различных источников и различных контекстов:

•    описанных различными моделями:

- определенных на различных языках моделирования:

•    коллективное использование данных в приложениях суметом архитектуры системы интеграции;

-    разрешение конфликтов между моделями, разработанными с различными целями;

•    трансляция данных из одной системы кодирования в другую;

•    трансляция моделей из одного языка моделирования в другой.

Настоящий стандарт распространяется на:

-    модели интеграции:

•    методы создания, расширения и обновления моделей интеграции:

•    методы создания спецификаций отображения для распределения элементов данных между моделями интеграции и моделями приложений, находящихся в области их применения;

•    кодирование и декодирование данных и моделей в различных форматах, таких как SGML [1], XML [7). EXPRESS [3]. UML [6] и ИСО 10303-21 [4);

-    метод консолидации наборов данных, полученных из различных источников и различных моделей;

•    моделирование и отображение языка спецификации:

-    архитектуру и общие понятия методологии.

Настоящий стандарт не распространяется на:

•    модели интеграции:

•    детальную спецификацию методологии.

Примечание — Такие спецификации имеются в других частях комппекса стандартов ИСО 16876 и в других стандартах ИСО:

•    трансляцию данных из одного способа кодирования в другой.

-    кодирование и декодирование данных и моделей, представленных в различных форматах:

•    моделирование и отображение языка спецификации.

Издание официальное

2    Нормативные ссылки

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

ИСО/МЭК 8824-1 Информационные технологии — Абстрактный синтаксис. Система обозначений. Версия 1 (ASN. 1) — Часть 1: Спецификация базовой системы обозначений (ISO/IEC 8824-1 Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification of basic notation)

ИС0 10303-1:1994 Системы промышленной автоматизации и интеграция — Представление данных о продукции и обмен данными — Часть 1: Обзор и основные принципы (ISO 10303-1:1994 Industrial automation systems and integration — Product data representation and exchange — Part 1: Overview and fundamental principles)

3    Термины, определения и аббревиатуры

3.1    Термины и определения

В настоящем стандарте используются термины с соответствующими определениями, приведенные в ИСО 10303-1.

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

3.1.1    модель приложения; МП (application model; AM): Модель, представляющая информацию, используемую в особых целях.

Примечание — Некоторые модели приложений также являются моделями интеграции (см. пункт 3.1.12).

3.1.2    класс (class): Категория или подразделение сущностей.

Примечание — Класс можно определить несколькими способами. Определение класса должно быть максимально широким, даже шире, чем определение по ИСО 15926-2.

Пример — Насос, электростанция, инженер, фантастический космический аппарат — это примеры классов.

3.1.3    понятие (concept): Общее представление или идея некоторой сущности.

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

[ИСО 10303-1]

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): Сущность, пребывающая в пространстве и времени.

Примечание — Данное понятие включает сущности, которые фактически существуют, реально существовали и которые, возможно, существуют (в прошлом, в нестоящем, в будущем) в пространстве и времени.

Пример — Конкретный насос с серийным номером Ns АВС123, электростанция Battersea, сэр Josepn Whitworth, космический корабль Enterprise — примеры индивидуальностей.

3.1.11    информация (information): Факты, понятия или инструкции.

[ИСО 10303-1]

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).

Примечание — 8 ИСО 10303 аббревиатура МП используется для обозначения «Модуль приложения»:

•    МИ - модель интеграции (integration model; IM).

4    Структура комплекса международных стандартов ИСО 18876

ИСО 18876 состоит из нескольких частей:

-    е ИСО/ТС 18876-1 приводится общий обзор комплекса. Он определяет архитектуру интеграции промышленных данных.

•    в ИСО/ТС 18876-2 устанавливаются методы интеграции моделей приложений, а также методы разработки и расширения моделей интеграции.

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

•    модели интеграции двух ипи более моделей:

•    модели для частных приложений.

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

•    спецификация отображения, определяющего порядок смены языка моделирования:

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

•    методы и спецификации кодирования модели и перехода из одной системы кодирования в другую:

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

5    Фундаментальные понятия и допущения

В настоящем стандарте используются следующие фундаментальные понятия и допущения.

5.1    Модели интеграции

5.1.1    Принципы

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

Примечание 1 — Трехсхемная архитектура описанв в ИСО/ТО 9007 [2].

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

Модель интеграции может быть создана, если может быть достигнуто общее понимание интегрируемых моделей приложения.

Примечание 2 — Указанные результаты получены в работе Barwlse и Settgman [9].

Примечание 3 — Трудности созданий такой модели указывают на пробел в человеческом понимании сущности модели приложения.

Для некоторой модели приложения может быть несколько моделей интеграции. Эти модели интеграции поддерживают различные варианты точек зрения (рисунок 2).

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

Рисунок 1 — Модель интеграции

Рисунок 2 — Интеграция с помощью нескольких моделей интеграции

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

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

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

5.1.2 Область применения и контекст

Область применения модели — это то. что модель фактически собой покрывает. Контекст модели — это сумма ограничений на расширение области применения модели без изменения какой-либо существующей декларации. Данные ограничения включают:

•    действия, производящие или использующие данные;

•    организации, производящие или использующие данные;

•    понятия, используемые данной моделью, но не представленные в модели явным образом:

•    ограничения, наследуемые в структуре модели.

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

Рисунок 3 — Ограниченная модель интеграции

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

Рисунок 4 — Интеграция модели приложения и ограниченной модели интеграции

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

Рисунок S — Использование модели интеграции с широким контекстом


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

Обпклъ лрмммаиип «мели


Коишевт жимы


шшшрам^    интеграции

йнымрамная

»

1

шййльмнтяпмцми

1

1


Шпж*

И вдет*

Мадвгъ

тщтпатт^

притоми^

прцтотаеыд

Рисунок 6 — Интеграций дополнительных моделей приложений

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

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

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

• Каждый объект моделируется в терминах своего естественного смысла, на основе особой парадигмы с учетом особенностей моделируемого окружающего мира.

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

Пример — Система выплаты жалования может быть расширена с обслуживания служащих до обслуживания неработающих пенсионеров. Для этого модель должна учитывать различие в статусах служащего и пенсионера.

•    Названия, выбранные для конструктивов модели, отражают естественный смысл предмета модели.

Примечание 2 — Несоответствующие имена могут ввести пользователя в заблуждение

-    Определения конструктивов модели должны быть четкими и недвусмысленными.

Примечание 3 — Нечеткие или двусмысленные определения могут ввести пользователя в заблуждение.

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

Примечание Л — Если ограничения встроены в структуру модели и если там. где ограничение уже не работает, необходимо расширение, то эту модель нужно менять. Это нежелательно.

-    Классы представляются как лодклассы/суперклассы (слециализация/обобщение) в иерархии, имеющей корни в одном классе.

Примечание 5 — Положение а иерархии «оодтил/супертил» — это ключевой элемент при формальном определении понятия. Оно поддерживает соответствующие характеристики наследования и поведения.

•    Модель представляет текущее состояние и его изменение и управляет им.

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

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

Примечание 7 — Некорректность при использовании языка привносит неопределенность в части интерпретации конструктивов процессором.

5.1.3 Понятие модели интеграции

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

•    фундаментальные понятия (см. 3.1.8);

•    общие понятия (см. 3.1.9):

-    особые понятия (см. 3.1.20).

Данный подход представлен на рисунке 7.

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

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

5.1.4 Полная модель интеграции

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

Рисунок в — Полная модель интеграции

Рассматриваемая архитектура не требует, чтобы примитивные понятия все время оставались примитивными. Если понятие, изначально бывшее примитивным, перестает быть таковым, то понятия, из которых оно выведено, могут быть идентифицироеаны/добавлены. а также может быть добавлено и производное. 3 результате получается производное понятие путем использования передней грани пирамиды. Таким образом, необходима гибкость для отражения нового знания о мире. Это лучше, чем просто констатация знания о мире, ограниченного знанием исследователя в конкретный момент времени. Следовательно, модель интеграции необходимо поддерживать и расширять. Необходимо также иметь механизм ее поддержки и расширения.

5.2 Спецификации отображений

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

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

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

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

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

Спецификации отображений являются либо декларативными, либо процедурными:

•    декларативная слецификация отображения идентифицирует шаблон для элементов одной модели. соответствующий шаблону для элементов другой модели (спецификация отображения является двухсторонней).

Пример 1 — Определение неформальной деклерет иеной спецификации отображения: для каждой сущности модели А, классифицируемой термином «красный» и термином «автомобиль», существует модель В. содержащая объект, являющийся элементом «красный автомобиль».

Пример 2 — Спецификация отображения в таблице отображений, определенной ИСО 10303-214. является декларативным отображением;

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

Пример 3 — Определение неформальной процедурной спецификации отображения в одном нвлрае-лении: для каждой сущности модели А. классифицируемой как «красный автомобиль*, в модели В можно создать объект, являющийся элементом классе «автомобиль» и элементом класса «красный».

Пример 4 — Спецификация отображения, созданная на языке EXPRESS-X с помощью конструктива отображения, является процедурной спецификацией отображения.

6 Обзор модели процесса интеграции

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

Существуют три возможных варианта процесса интеграции:

-    и модель интеграции, и модели приложений уже существуют до начала процесса интеграции;

-    интегрируемые модели приложений уже существуют до качала процесса интеграции, но модели интеграции еще нет;

-    модель интеграции уже существует до начала процесса интеграции, но моделей приложений еще нет. их нужно разработать с учетом наложенных требований.

Первый вариант из трех вышеуказанных включает все элементы двух других вариантов. Он описан здесь на схеме для одной модели приложения. Другие два процесса описаны более детально в ИСО/ТС 18876-2.

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

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

Процесс интеграции модели приложения с моделью интеграции включает следующие шаги:

-    анализ модели приложения и идентификация эквивалентного понятия модели интеграции, включая любые наложенные ограничения (рисунок 10);

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

Примечание 2 — Для объектов моделей приложений и модели интеграции используются различные символы, указывающие, что данные объекты являются информационными. Это имеет место, даже если они относятся к одним и тем же реальным объектам окружающего мира.

• при необходимости расширения модели интеграции так. чтобы она включала все понятия модели приложения (рисунок 11);

Ю


Акали понятий ыопалигфмлаиим


Понятия    пента

■сдал» прилежания    ждали митаредаи


Рисунок 10 — Анализ моделей приложения

Понятие

ждали притомим

Претив

медик икггряиии

Рмширяим»

ОНТОГрйДИЯ яетогимпк-ыла понятой медик цмпгямпия}


Ломтя

Помтш

модам пряккииин    модели ингаляции

«кщелпикгефими    выбор

щщнсашагт

Рисунок 12 — Идентификация подмножества модели интеграции


• идентификация части модели интеграции, представляющей понятия а каждой модели приложения (рисунок 12);

- создание спецификаций взаимных отображений а каждом направлении всех моделей приложения и соответствующего подмножества модели интеграции (рисунок 13):

Примечание 3 — Идентификация подмножества модели интеграции — ото побочный продукт процесса интеграции.

Поилмл    Поют»

модем гфнпоония    модем шшршжи

модеииите грации

Рисунок 13 — Создание спецификации взаимного отображения подмножества модели интеграции

и модели приложения


Пример 1 — Если модель приложения задана на языка определений XML Schama, а модель интеграции. на которую она отображается, определена не языке EXPRESS (3). то преобразования между указанными языками будут необходимы для езаимных отображений между различными предстаелениями одних и тех же понятий.

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

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

7 Интеграция компонентов архитектуры

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

Примечание 1— Объектно-ориентированные модели рассматриваются в данном международном стандарте как модели комбинации «сущность — атрибут — соотношение».

• модели интеграции:

Примечание 2 — Это может быть одиночная модель с несколькими уровнями абстракции, использующая приемлемый языке логической базой (например, KIF (16)). или многослойная модель, использующая язык типа EXPRESS (3) для описания комбинации «сущность — соотношение», а также модель данных и библиотеки ссылочных данных. Рисунок 14 иллюстрирует порядок использования модели для определения структуры библиотеки ссылочных данных, которая может содержать ссылочные классы и ссылочные индивидуальности.

Примечание 3 — Ссылочные классы и ссылочные индивидуальности могут быть собраны вместе е библиотеку ссылочных данных. Библиотек ссылочных данных может быть несколько. Если указанные библиотеки предназначены для совместного использования, то они не должны перекрываться. Необходимо также организовать ссылки из одной библиотеки в другую;

- спецификации отображений.

Примечание 4 — Спецификации отображений могут включать идентификацию подмножеств модели интеграции.

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

Примечание 6 — Спецификации отображений могут включать структурные преобразования между структурой модели интеграции и структурой модели приложения

Примечание 7 — Спецификации отображений могут включать терминологические преобразования между моделью интеграции и моделью приложения.

Примечание 8 — Могут потребоваться спецификации двухсторонних отображений языков спецификации моделей;

• модели приложений.

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

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

Пример — ИСО 10303-28 содержит несколько спецификаций взаимных отображений моделей, представленных на языках EXPRESS (см. ИСО 10303-11) и XML.

8 Отображение данных и их консолидация

Создания спецификаций взаимных отображений моделей недостаточно для интеграции. Необходимо согласование информации, представленной различными моделями. Этот процесс иллюстрируется на рисунке 15;

-    транслируйте совокупности данных 1 и 2 в соответствии с источниками их моделей в совокупности данных Т и 2 в соответствии с моделью IM,;

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

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

9 Соотношения с другими стандартами

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

Пример 1 — ИСО 15926-2 (5J определяет модель денных а библиотеку ссылочных денных, которые вместе формируют модель интеграции для технологических приложений.

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

Пример 2— Методология, описанная в ИСО/ТС 13876-2. может использоваться для интеграции возможности обмена данных о продукте, определенной протоколом приложения (см. ИСО 10303), и возможности обмене данных, установленной определением типа данных документа XML.

Приложение А (обязательное)

Регистрация информационного объекта

Для идентификации информационного объекта а открытой системе настоящему стандарту присвоен следующий идентификатор объекта:

{ISO standard 18876 part {1} version (1))

Смысл значения настоящего идентификатора определен е ИСО/МЭК 8824-1 и описан в ИСО 10303-1.

Приложение ДА (справочное)

Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Таблица ДА.1

Обозначение ссылочное© международного стандарта

Степень

соответствия

Обозначение и наименование соответствующего национального стандарта

ИСО/МЭК 8824-1

IDT

ГОСТ Р ИСО/МЭК 8824-1:2001 «Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации*

ИСО 10303-1:1094

IDT

ГОСТ Р ИСО 10303-1:1999 «Системы автоматизации производства и их интеграция. Представление денных об изделии и обмен этими данными. Часть 1. Общие представления и основополагающие принципы*

Примечание — 8 настоящей таблице использовано следующее условное обозначение степени соответствия стандартов:

IDT — идентичные стандарты.

библиография

[1]    ИСО 8879:1986 ISO 6879:1986

[2]    СОЯО 9007:1987 ISO/TR 9007:1987

[3]    ИСО 10303-11:2004


Обработке информации. Текстовые и офисные системы. Стандартный обобщенный язык разметки (SGML)

Information processing — Text and office systems — Standard Generalized Markup Language (SGML)

Системы обработки информации. Понятия и терминология для концептуальной модели базы данных

Information processing systems — Concepts and terminology for the conceptual schema and the information base

Системы промышленной автоматизации и интеграция. Представление данных о продукции и обмен данными. Часть 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


(5) ИСО 15926-2:2003


industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure Системы промышленной автоматизации и интеграция. Интеграция данных о сроке службы нефтехимических установок, включая установки по добыче нефти и газа. Часть 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:20045 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:/to ww.w3.org/TR/REC-xml>

(8)    integration Definition for information Modeling (IDEF1X). Federal information Processing Standards Publication 184, December 1993

(9)    8ARWISE. 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 20014)5-09). Available from the Internet: <>

(11)    GUARINO. Nicola. Some Organizing Principles for a Unified Top Level Ontology. Proceedings of AAAI Spnng Symposium on Ontological Engineering. Stanford. CA: AAAI Press. 1997

(12)    GUARINO. Nicole. Some Ontological Principles for Designing Upper Level Lexical Resources. Padua: 1998 (cited 2001-05-09]. available from the internet: <>

(13)    PARTRIDGE. Chris. Business objects: re-engineering for reuse. Oxford: Butterworth Hememann. 1996

(14)    SOWA. John F. Knowledge representation: logical, philosophical and computational foundations.

(15)    WEST. Matthew; FOWLER. Julian. Developing High Ouality Data Models. Version 2.0, issue 2.1. EPISTLE. 1996 (cited 2001-05-09]. Available from the internet: <>

(16)    Knowledge interchange Format, draft proposed American National Standard (dpANS). NCITS.T2/98-004. (cited 2002-02-04]. Available from the internet: <http:Moglc.stanford.edu/kit/dpans.html>

УДК 658.52.011.56:006.354    ОКС 25.040.40    Т58

35.240.50

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

Редактор Г.И. Колобова Технической редактор Е.в. Веолроманная Корректор М.И. Першина Коыпыотерная аерстка В.И. Грищенко

Сдано е набор 10.07.2014. Подписано а печать 09.09.2014.    Форы а т 60x64’/,.    Гарнитура Лриал. Уел. печ. л. 2.70.

Уч.-иэд. л. 2.35. Тирах 67 ли Зак. 3600.

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ». 123095 Москва, Гранатный лер . 4. info^goslinfo.ru

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

•    задание необходимых взаимных преобразований в представленных моделях.