ГОСТ Р ИСО 9506-2-2014 Системы промышленной автоматизации и интеграция. Спецификация производственных сообщений. Часть 2. Спецификация протокола

ГОСТ Р ИСО 9506-2-2014

Группа Т58

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

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

СПЕЦИФИКАЦИЯ ПРОИЗВОДСТВЕННЫХ СООБЩЕНИЙ

Часть 2

Спецификация протокола

Industrial automation systems and integration. Manufacturing message specification. Part 2. Protocol specification

ОКС 25.040.40

Дата введения 2016-01-01

Предисловие

1 ПОДГОТОВЛЕН ООО "НИИ экономики связи и информатики "Интерэкомс" (ООО "НИИ "Интерэкомс") на основе собственного аутентичного перевода на русский язык международного стандарта, указанного в пункте 4

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО 9506-2:2003* "Системы промышленной автоматизации и интеграция. Спецификация производственных сообщений. Часть 2. Спецификация протокола" (ISO 9506-2:2003 "Industrial automation systems - Manufacturing Message Specification - Part 2: Protocol specification").

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

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

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

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

Введение

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

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

a) применимость конкретной услуги к конкретному устройству;

b) сложность услуг и накладываемые требования;

c) сложность обеспечения конкретного класса услуг сети и сложность самого устройства.

Требования безопасности

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

Сложность услуг и требований

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

Ключевые слова

Общие положения

Настоящий стандарт - это один из серии стандартов, обеспечивающих взаимосвязь систем обработки информации. Он позиционируется на прикладном уровне среды взаимосвязи открытых систем по отношению к другим стандартам в качестве прикладного сервисного элемента (ASE) базовой ссылочной модели обеспечения взаимосвязи открытых систем (см. ИСО 7498).

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

a) различных изготовителей;

b) различных форм управления;

c) различных уровней сложности;

d) различных временных интервалов.

Цель

Целью настоящего стандарта является определение спецификаций производственных сообщений. Настоящий стандарт тесно связан с областью применения определения спецификации услуги производственных сообщений (см. ИСО 9506-1). Он использует услуги, обеспечиваемые коммуникационной системой, которая предполагается для передачи элементов PDU.

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

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

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

Издание

Настоящий стандарт отличается от первого издания ИСО 9506-2 тем, что в нем исправлены ошибки в протоколах, связанных с определениями типов ASN.1 и моделированием структур. В настоящем стандарте также исправлены несколько типографских ошибок.

Отличия настоящего стандарта от ИСО/МЭК 9506-2:1990 заключаются в том, что:

a) материалы ИСО/МЭК ТО 13345, описывающие подмножества протокола MMS, включены в настоящий стандарт;

b) все материалы изменений 1 и 2 включены в настоящий стандарт как технические поправки;

c) формальная модель объекта, используемая в ИСО 9506-1, обеспечивает некоторые типы определений для протокола, описанного в настоящем стандарте. Так, утверждение IMPORT включено в модуль ASN.1;

d) услуги и протокол, ранее опубликованные в сопутствующих стандартах (ИСО/МЭК 9506-3, ИСО/МЭК 9506-4 и ИСО/МЭК 9506-6), включены в базовый стандарт.

В результате указанных изменений нет необходимости использовать отдельный абстрактный синтаксис для каждого сопутствующего стандарта. Все сопутствующие стандарты теперь могут ссылаться на единый абстрактный синтаксис базового стандарта. При этом использование других абстрактных синтаксисов остается возможным для обеспечения совместимости. Отпала необходимость и в отдельном определении модуля в разделе 19 первого издания ИСО/МЭК 9506-2 (указанный раздел удален);

e) требования к связи MMS обобщены, и MMS описан с учетом абстрактного множества услуг, необходимых для их поддержки. Соотношение между указанным абстрактным множеством услуг и услугами, обеспечиваемыми семейством протоколов связи модели OSI, приведено в приложении. Это дает возможность обеспечить корректную работу MMS с альтернативными системами связи (уменьшение необходимого объема стековой памяти) путем использования эквивалентности указанных абстрактных услуг;

f) ограничения на обозначения, которые могут быть использованы как идентификаторы, ослаблены. Теперь идентификатор может начинаться с цифры и, как расширение, может состоять только из цифр;

g) многие (но не все) реализации VisibleString заменены на новую реализацию MMSString, которая дает возможность использовать произвольную строку символов, определенных в ИСО 10646. Аналогично, эти более общие строки также могут быть использованы как идентификаторы. Добавленные новые параметры СВВ создают условия для обсуждения условий применения указанных более общих строк;

h) введена новая услуга ReconfigureProgramlnvocation (активизация программы реконфигурации), вставленная в раздел по управлению программами активизации. Данная услуга задает технологию динамического изменения составляющих доменов рассматриваемой вызова программы;

i) добавлена новая область к объектной модели поименованной переменной и поименованного типа. Данная область может быть использована для описания семантики, ассоциированной с поименованной переменной или с поименованным типом. Эта область определена предварительно либо ее значение установлено как имя поименованного типа (используемого для его построения в услуге определения поименованной переменной DefineNamedVariable или в услуге определения поименованного типа DefineNamedType). Настоящая область указана вместе с услугой получения атрибутов доступа к переменной GetVariableAccessAttributes или услугой получения атрибутов поименованного типа GetNamedTypeAttributes, если оговорена величина sem (нового параметра СВВ);

j) текст стандарта отредактирован таким образом, что разделов стало больше, и они стали короче;

k) тип данных Real удален из настоящего стандарта;

I) из текста настоящего стандарта удалены материалы по рассеянному доступу. Они размещены в справочном приложении;

m) в соответствии с рекомендациями ИСО/МЭК 8824-1 все утверждения EXTERNAL в протоколе заменены утверждениями CHOICE {EXTERNAL, EMBEDDED PDV};

n) сущность PICS первого издания заменена разделом, содержащим информацию о конфигурации и инициализации. Настоящий раздел содержит указания по инициализации в некоторых областях (их относительно немного) для VMD и подчиненных объектов, а также обеспечивает отчет (в форме таблицы) о значениях инициализации в других областях (в соответствии с возможностями разработчика). Добавлено новое приложение (см. приложение В). Оно содержит описание модуля ASN.1, используемого при передаче информации, содержащейся в указанной таблице.

Протокол

В настоящее время в результате использования методики моделирования объекта ASN.1 протокол существуете в виде трех отдельных модулей. Один модуль является частью объектной модели, описанной в ИСО 9506-1. Два других модуля определены в настоящем стандарте, содержащем описания контента и структуры всех корректных блоков данных PDU. Несмотря на то что формулировка ASN.1 может быть различной в некоторых случаях, сущности PDU, полученные с помощью приложений, описанных в первом издании ИСО 9506, идентичны соответствующим сущностям настоящего издания. По этой причине настоящий стандарт по-прежнему идентифицируют в качестве основной версией N 1 (номера других версий изменены, чтобы соответствовать всем новым добавлениям к настоящему стандарту).

Необходимо указать два исключения:

1) синтаксические расширения, определенные сопутствующими стандартами, теперь идентифицированы новыми параметрами СВВ вместо отдельного абстрактного синтаксиса. Следовательно, для любых возможностей сопутствующих стандартов, использующих MMS, имеет место изменение в пусковом PDU. При этом если указанные возможности сопутствующего стандарта не используются, то пусковой PDU остается тем же, что определен в первом издании;

2) некоторые небольшие изменения внесены в теговую разметку услуги ChangeAccessControl (управление изменением доступа, часть изменения 2) для приведения ее в соответствие с протоколом услуги GetNameList (получение перечня имен) и услуги Rename (переименование).

Кодирование PDU с помощью PER (см. ИСО/МЭК 8825-2) может быть не полностью совместимо с PDU, генерированным в первом издании ИСО/МЭК 9506. Дело в том, что замена некоторого типа сущностью CHOICE (выбор), содержащей данный тип, приводит к различным вариантам кодирования на базе PER. То же самое имеет место при BER-кодировании для рассматриваемых двух ситуаций. Таким образом, если PDU содержит элементы типа EXTERNAL, то они будут заменены сущностью CHOICE (выбор), используемой при PER-кодировании.

Модуль ASN.1

Модули ASN.1, определенные в ИСО 9506, можно получить в секретариате ПК4 в электронном формате. Модули доступны в двух видах: 1) в опубликованном виде; 2) с удаленными скобками типа IF-ENDIF.

Указанные файлы доступны на сайте: http://forums.nema.org:8080/~iso_tc184_sc5.

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

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

1.1 Спецификации

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

a) процедуры одинарного протокола передачи данных и управляющей информации из одной сущности приложения в другую одноранговую прикладная сущность в рассматриваемом MMS-контексте;

b) средств выбора услуг для сущностей приложения при обеспечении связи в MMS-контексте;

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

1.2 Процедуры

Указанные выше процедуры определены в терминах:

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

b) взаимодействий MMS-провайдеров и MMS-пользователей в той же системе путем обмена MMS-примитивами;

c) взаимодействий MMS-провайдеров и абстрактных услуг, предоставляемых нижележащими системами связи.

1.3 Применимость

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

1.4 Соответствие

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

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

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

________________

* Таблицу соответствия национального стандарта международному см. по ссылке. - .

ИСО/МЭК 646 Информационные технологии. 7-битный набор кодированных символов ИСО для обмена информацией (ISO/IEC 646 Information technology - ISO 7-bit coded character set for information interchange)

ИСО/МЭК 7498-1 Информационные технологии. Взаимодействие открытых систем. Базовая эталонная модель. Часть 1. Базовая модель (ISO/IEC 7498-1 Information technology - Open Systems Interconnection - Basic reference model. Part 1: The basic model)

ИСО 7498-2 Системы обработки информации. Взаимодействие открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты (ISO 7498-2 Information processing systems - Open Systems Interconnection; basis reference model; Part 2: Security architecture)

ИСО/МЭК 7498-3 Информационные технологии. Взаимодействие открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация (ISO/IEC 7498-3 Information technology - Open Systems Interconnection - Basic reference model. Part 3: Naming and addressing)

ИСО 8571 (все части) Системы обработки информации. Взаимодействие открытых систем. Передача, доступ и управление файлами (ISO 8571 Information processing systems; Open Systems Interconnection; file transfer, access and management)

ИСО/МЭК 8650-1 Системы обработки информации. Машинная графика. Привязки к языку базовой графической системы (GKS). Часть 1. ФОРТРАН (ISO/IEC 8650-1 Information processing systems; computer graphics; graphical kernel system (GKS) language bindings; part 1: FORTRAN)

ИСО/МЭК 8822 Информационные технологии. Взаимосвязь открытых систем. Определение службы представления данных (ISO/IEC 8822 Information technology - Open Systems Interconnection - Presentation service definition)

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

ИСО/МЭК 8824-2 Информационные технологии. Нотация абстрактного синтаксиса один (ASN.1). Часть 2. Спецификация информационных объектов (ISO/IEC 8824-2 Information technology - Abstract Syntax Notation One (ASN.1): Information object specification)

ИСО/МЭК 8825-1 Информационные технологии. Правила кодирования ASN.1. Часть 1. Спецификация основных (BER), канонических (CER) и различительных правил кодирования (DER) (ISO/IEC 8825-1 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER))

ИСО/МЭК 8825-2 Информационные технологии. Правила кодирования ASN.1. Часть 2. Спецификация правил уплотненного кодирования (PER) (ISO/IEC 8825-2, Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER))

ИСО 9506-1 Системы промышленной автоматизации. Спецификация производственных сообщений. Часть 1. Определение услуг (ISO 9506-1, Industrial automation systems - Manufacturing Message Specification - Part 1: Service definition)

ИСО/МЭК 9545 Информационные технологии. Взаимосвязь открытых систем. Структура прикладного уровня (ISO/IEC 9545, Information technology - Open Systems Interconnection - Application Layer structure)

ИСО/МЭК 10731 Информационные технологии. Взаимосвязь открытых систем. Базовая эталонная модель. Соглашения, касающиеся определения услуг в OSI (ISO/IEC 10731, Information technology - Open Systems Interconnection - Basic Reference Model - Conventions for the definition of OSI services)

ANSI/IEEE 754 Стандарт IEEE на бинарную арифметику с плавающей точкой (ANSI/IEEE 754, Binary floating-point arithmetic)

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

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

Примечание - Определения, содержащиеся в настоящем разделе, используют сокращения, приведенные в разделе 4.

3.1 Определения ссылочных моделей

Настоящий стандарт базируется на понятиях, разработанных в Базовой эталонной модели взаимосвязи открытых систем (см. ИСО 7498). В настоящем стандарте использованы следующие термины:

3.2 Определение соглашения об услугах

Настоящий стандарт использует следующие термины, определенные конвенциями по определению услуг OSI (см. ИСО/МЭК 10731). Эти термины применяются для спецификации производственных сообщений:

3.3 Определения абстрактных синтаксических обозначений

Настоящий стандарт использует следующие термины, определенные спецификацией (см. ИСО/МЭК 8824) абстрактных синтаксических обозначений N 1 (ASN.1):

3.4 Прочие определения

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

3.4.1 специализированный в части прикладной ассоциации (Application Association specific; AA-specific): Прилагательное, используемое для описания объекта с областью применения, которой является прикладная ассоциация (то есть на данное имя можно ссылаться только из прикладной ассоциации, через которую определен объект).

3.4.2 атрибут (attribute): Именованная характеристика (параметр) элемента, системы, подсистемы, которая может приобретать конкретное значение на заданном множестве (числа, векторы, символьные выражения, логические значения и т.д.).

3.4.3 вызываемый MMS-пользователь (Called MMS-user): MMS-пользователь, выдающий примитив услуги инициирования ответа Initiate.response.

3.4.4 вызывающий MMS-пользователь (Calling MMS-user): MMS-пользователь, выдающий примитив услуги инициирования запроса Initiate.request.

3.4.5 клиент (Client): Одноранговая сущность, поддерживающая связь, которая использует VMD с некоторой конкретной целью посредством экземпляра запроса услуги.

3.4.6 структурный элемент согласованности (conformance building block; СВВ): Элементарный блок, используемый для описания требований согласованности MMS.

3.4.7 данные (data): Информация, представленная в формализованном виде, пригодном для передачи, интерпретации или обработки с участием человека или автоматическими средствами.

3.4.8 домен (domain): Абстрактный объект, представляющий подмножество возможностей VMD, используемых для особых целей.

3.4.9 специализированный в части домена (предметно-ориентированный) (Domain-specific): Прилагательное, используемое для описания объекта, имя которого имеет область применения, являющуюся простым доменом (т.е. ссылаться на данное имя можно из всех прикладных ассоциаций, установленных вместе с VMD, которое может ссылаться на указанную область).

3.4.10 загрузка (download): Процесс передачи контента домена, включая любые подчиненные объекты, посредством загрузки данных MMS-пользователю.

3.4.11 управление событием (event management): Управление условиями события, действиями события, регистрацией события и перечнем условий события.

3.4.12 файл (file): Однозначно поименованный объем информации, имеющий обычный набор атрибутов.

3.4.13 управление файлом (file operation): Передача файла между открытыми системами, его инспекция, модификация, замена части контента файла, работа с файлом и его атрибутами.

3.4.14 файлохранилище (filestore): Организованное множество файлов, включая их атрибуты и имена, расположенное в конкретной открытой системе.

3.4.15 информация (information): Комбинация данных и передаваемого ими смысла.

3.4.16 некорректный PDU (invalid PDU): Блок данных PDU, не соответствующий требованиям настоящего стандарта в части структуры и/или содержания.

3.4.17 журнал (journal): Множество зарегистрированных событий, изменяемые данные и/или комментарии с временной отметкой, которые могут быть логически упорядочены в процессе получения.

3.4.18 локальные обстоятельства (local matter): Решение, принимаемое системой, касающееся ее поведения в спецификации производственных сообщений и не удовлетворяющее требованиям настоящего стандарта.

3.4.19 механизм протокола производственного сообщения (Manufacturing Message Protocol Machine; MMPM): Абстрактный механизм выполнения процедур, описанных в настоящем стандарте.

3.4.20 MMS-контекст (MMS-context): Спецификация элементов MMS-услуг и семантика связи, используемых в течение срока службы прикладной ассоциации.

3.4.21 MMS-провайдер (MMS-provider): Часть сущности приложения, которая концептуально обеспечивает MMS-услуги путем обмена элементов MMS PDU.

3.4.22 MMS-пользователь (MMS-user): Часть прикладного процесса, концептуально задействующая спецификацию производственных сообщений.

3.4.23 отслеживаемое событие (monitored event): Выявленное изменение состояния условия события.

3.4.24 событие, запускаемое в сети (network-triggered event): Запуск, производимый по требованию клиента.

3.4.25 станция управления (operator station): Абстрактный объект, представляющий собой оборудование, ассоциированное с VMD и обеспечивающее взаимодействие типа "вход/выход" с оператором.

3.4.26 предварительно определенный объект (predefined object): Объект, инстанцированный путем использования механизма, отличного от MMS услуги.

3.4.27 активизация (вызов) программы (program Invocation): Абстрактный объект, представляющий собой динамический элемент, наиболее точно соответствующий потоку исполнения в многозадачной среде и составленный из множества доменов.

3.4.28 ошибка протокола (protocol error): Блок данных PDU, не соответствующий требованиям настоящего стандарта.

3.4.29 получающий MMPM (Receiving MMPM): Механизм MMPM, получающий блоки данных производственных спецификаций MMS PDU.

3.4.30 получающий MMS-пользователь (Receiving MMS-user): MMS-пользователь, получающий примитив услуги отображения или подтверждения.

3.4.31 удаленное устройство управления и мониторинга (remote device control and monitoring): Изменение или контроль состояния устройства, прикрепленного к ответчику запроса услуги.

3.4.32 запрашивающий MMS-пользователь (Requesting MMS-user): MMS-пользователь, выдающий примитив услуги запроса для исполнения.

3.4.33 ответающийся MMS-пользователь (Responding MMS-user): MMS-пользователь, выдающий примитив услуги ответа для исполнения.

3.4.34 семафор (semaphore): Концептуальный замок, ассоциированный с логическим или физическим ресурсом. Доступ к ресурсу может разрешить только собственник замка.

3.4.35 управление семафором (semaphore management): Управление семафором.

3.4.36 отправляющий MMPM (Sending MMPM): Механизм MMPM, отправляющий MMS PDU.

3.4.37 отправляющий MMS-пользователь (Sending MMS-user): MMS-пользователь, выдающий примитив услуги запроса или ответа.

3.4.38 сервер (Server): Одноранговая обобщающая сущность, ведущая себя как VMD агент для конкретного экземпляра запроса услуги.

3.4.39 стандартизованный объект (standardized object): Реализация объекта, определение которого приведено в ИСО 9506-1 или в сопутствующем MMS стандарте.

3.4.40 тип (type): Абстрактное описание множества значений, выражаемых значением переменой.

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

3.4.42 корректный PDU (valid PDU): PDU, удовлетворяющий требованиям настоящего стандарта к структуре и смыслу.

3.4.43 переменная (variable): Один или несколько элементов данных, на которые производится ссылка одним именем или описанием.

3.4.44 доступ к переменной (variable access): Рассмотрение или модификация переменных (их компонентов), определенных на VMD.

3.4.45 виртуальное производственное устройство (Virtual Manufacturing Device; VMD): Абстрактное представление особого множества ресурсов и функциональности действительного производственного устройства, а также отображение указанного абстрактного представления на физические и функциональные аспекты реального производственного устройства.

3.4.46 удовлетворяющий требованиям VDM* (VMD-specific): Прилагательное, используемое для описания объекта, имя которого имеет область применения, являющуюся реализацией VMD (т.е. на данное имя могут ссылаться все прикладной ассоциации*, установленные вместе с VMD).

________________

* Текст документа соответствует оригиналу. - .

4 Сокращения

AA - прикладная ассоциация (application association);

ACSE - сервисный элемент управления ассоциацией (Association Control Service Element);

AE - прикладной логический объект (прикладная сущность) (application entity);

AP - прикладной процесс (application process);

APDU - блок данных прикладного протокола (application protocol data unit);

ASE - прикладной сервисный элемент (application service element);

ASN.1 - абстрактная синтаксическая нотация версия 1 (Abstract Syntax Notation One);

CBB - структурный элемент согласованности (conformance building block);

CIS - утверждение конфигурации и инициализации (Configuration and Initialization Statement);

FRSM - механизм считывания конечного состояния файла (file read state machine);

MMPM - протокольная машина производственного сообщения (Manufacturing Message Protocol Machine);

MMS - спецификация производственных сообщений (Manufacturing Message Specification);

OSI - взаимосвязь открытых систем (Open Systems Interconnection);

PDU - протокольный блок данных (protocol data unit);

ULSM - механизм подкачки конечного состояния (upload state machine);

VMD - виртуальное производственное устройство (Virtual Manufacturing Device).

5 Соглашения

5.1 Соглашения об услугах

Настоящий стандарт основан на положениях, приведенных в соглашениях по определению услуг модели OSI (ИСО/МЭК 10731). Данная модель определяет взаимодействие между MMS-пользователем и MMS-провайдером. Информация передается между MMS-пользователем и MMS-провайдером в виде примитивов услуг с параметрами.

5.2 База числовых значений

Настоящий стандарт использует десятичное представление (систему счисления) всех числовых значений, если не оговорено иное.

5.3 Обозначение

Настоящий стандарт использует абстрактное синтаксическое обозначение, определенное в ИСО/МЭК 8824 (рассматривающем спецификацию ASN.1).

В соответствии с требованиями ASN.1 все ссылки на тип начинаются с большой буквы, все ссылки на значение - с маленькой буквы.

5.4 Поддерживающие разработки

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

5.5 Сквозные параметры

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

5.5.1 Параметры сквозного запроса

Тип, идентифицируемый именем ссылочного типа, должен быть параметром того же имени примитива запроса услуги. Его следует рассматривать как параметр того же имени примитива услуг отображения (при наличии). Значения параметра примитива запроса, примитива отображения и запроса PDU - семантически эквивалентны.

Если это параметр по выбору и он опущен в примитиве запроса услуги, то он должен отсутствовать в запроса* PDU. Если параметр по выбору отсутствует в запроса PDU, то он должен отсутствовать в примитиве услуги отображения.

________________

* Текст документа соответствует оригиналу. - .

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

________________

* Текст документа соответствует оригиналу. - .

5.5.2 Сквозной параметр ответа

Тип, идентифицируемый именем ссылочного типа, должен быть параметром примитива ответа того же имени. Его следует рассматривать как параметр примитива подтверждения услуги (при наличии) того же имени. Значения параметров примитива ответа, примитива подтверждения и ответа PDU должны быть семантически эквивалентными.

Если это параметр по выбору и он опущен в примитиве ответа услуги, то он должен отсутствовать в ответе PDU. Если параметр по выбору отсутствует в ответе PDU, то он должен отсутствовать в примитиве подтверждения услуги.

Если параметр имеет значение по умолчанию в ответа PDU и данное значение по умолчанию имеется в примитиве ответа услуги, то этот параметр может отсутствовать в ответа PDU. Если параметр имеет значение по умолчанию в PDU ответа и данный параметр отсутствует в ответа PDU, то он должен описывать значение по умолчанию примитива подтверждения услуги*.

________________

* Текст документа соответствует оригиналу. - .

5.5.3 Перенумерованные значения параметра

Если значения параметров описания услуги перенумерованы, то значения соответствующего параметра протокола должны иметь то же имя (см. 5.5) в примитиве услуги, содержащем указанный параметр. Значения, указанные в примитиве услуги, определенном PDU, и в примитиве услуги, определенном в результате получения примитива услуги, должны быть семантически эквивалентными.

Примечание - Соответствие указанных значений идентифицировано в настоящем стандарте путем использования одинаковых имен в примитивах услуг и в протоколе. В спецификации услуги указанные значения описаны символами верхнего регистра. В спецификации протокола регистр символов имени выбирают в соответствии с синтаксическими требованиями ASN.1. При этом в комментариях после упоминания протокола имя пишут большими буквами.

5.6 Отрицательное подтверждение

Большинство подтвержденных MMS-услуг дают отрицательное подтверждение, если ошибка имеет место при обработке запроса услуги ответающимся* MMS-пользователем. Такое отрицательное подтверждение указано параметром Result(-) и параметром ErrorType (тип ошибки) примитива ответа услуги. Параметр Result(-) и параметр ErrorType (семантически эквивалентные параметрам примитива ответа) должны быть указаны в примитиве подтверждения услуги.

________________

* Текст документа соответствует оригиналу. - .

Абстрактным синтаксисом отрицательного подтверждения является сущность ErrorPDU услуги. При этом поле error берется из параметра Problem примитива ответа услуги.

5.7 Модификатор запроса услуги

MMS-услуги предоставляют возможность использовать модификаторы вместе с экземплярами запросов услуг.

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

5.8 Представление данных об ошибках

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

5.9 Вызывающий и вызванный MMS-пользователи

В настоящем стандарте использованы термины "вызывающий MMS-пользователь" и "вызванный MMS-пользователь". Вызывающий MMS-пользователь - это MMS-пользователь, инициирующий примитив запроса услуг Initiate.request. Вызванный MMS-пользователь - это MMS-пользователь, инициирующий примитив ответа услуг Initiate.response.

Примечание - Использование термина "вызванный" (called) в среде MMS отличается от использования данного термина в среде OSI. В среде MMS термин "вызванный" (called) соответствует термину "ответающийся"* (responding) в среде OSI. Различные термины используют для того, чтобы избежать путаницы при определении запрашивающего/ответающегося* MMS-пользователя.

________________

* Текст документа соответствует оригиналу. Здесь и далее. - .

5.10 Отправляющий и получающий MMS-пользователь и ММРМ

В настоящем стандарте использованы термины "отправляющий MMS-пользователь" и "получающий MMS-пользователь". Отправляющий MMS-пользователь - это MMS-пользователь, инициирующий примитив услуги запроса или примитив услуги ответа. Получающий MMS-пользователь - это MMS-пользователь, получающий примитив услуги отображения или примитив подтверждения услуги.

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

В настоящем стандарте использованы термины "отправляющий ММРМ" и "получающий ММРМ". Отправляющий ММРМ - это механизм ММРМ, отправляющий блок данных производственной спецификации MMS PDU. Получающий ММРМ - это механизм ММРМ, получающий MMS PDU (расшифровка аббревиатур представлена в разделе 4).

5.11 Запрашивающий и ответающийся MMS-пользователь

В настоящем стандарте использованы термины "запрашивающий MMS-пользователь" и "ответающийся MMS-пользователь". Запрашивающий MMS-пользователь - это MMS-пользователь, инициирующий примитив услуги запроса; ответающийся MMS-пользователь - это MMS-пользователь, инициирующий примитив услуги ответа.

Примечание - Важно отметить, что используемый термин "ответающийся MMS-пользователь" отличается от термина "ответающаяся сущность" в стандарте ACSE и других стандартах. В указанных стандартах данный термин используется для ссылок на сущность, которая ответается на запрос о соединении.

5.12 Клиент и сервер услуг

В настоящем стандарте использованы термины "клиент" и "сервер" для описания модели MMS VMD. Сервер - это одноранговая обобщающая сущность, ведущая себя как VMD для конкретного экземпляра запроса услуги. Клиент - это одноранговая обобщающая сущность, использующая VMD для некоторой конкретной цели посредством экземпляра запроса услуги. Модель VMD преимущественно используется при описании работы сервера и, следовательно, при описании команд и ответов, используемых клиентом. Реальная оконечная система может принять роль клиента, либо роль сервера, либо обе роли в течение срока службы прикладной ассоциации.

5.13 Определения ASN.1

Определения ASN.1, данные в настоящем стандарте (см. разделы 7-23), являются частью модуля ASN.1 "ISO-9506-MMS-1". Определения ASN.1, данные в настоящем стандарте (см. приложение А), являются частью модуля ASN.1 "MMS-Environment-1". Определения ASN.1, данные в настоящем стандарте (приложение B), являются частью модуля ASN.1 "MMS-SCI-Module-1". Определения ASN.1, данные в настоящем стандарте (приложения C, D, и E), являются частью модуля ASN.1 "ISO-9506-1А". Начальные и конечные утверждения, указывающие, что каждое данное определение ASN.1 является частью соответствующего модуля, опущены для читабельности документа. Каждое определение ASN.1, данное неявно, содержит следующее утверждение

ModuleName DEFINITIONS ::= BEGIN

в начале этого определения. Оно также содержит ключевое слово "END" в конце этого определения. Здесь сущность ModuleName - это имя модуля ASN.1, для которого рассматриваемое определение является частью.

Примечание - Сущность ISO-9506-MMS-1 указывает на пересмотр N 1 абстрактного синтаксиса ядра MMS, представленного в настоящем стандарте.

5.14 Обозначения подмножества протоколов

Обозначение, представленное в настоящем стандарте, имеет форму языка препроцессора, в который встроено обозначение ASN.1. Это аналогично ситуации в макропрепроцессоре языка С. В рассматриваемой системе символов использованы только три команды:

- IF (<список аргументов>);

- ELSE;

- ENDIF.

Команда IF требует указания списка аргументов (в скобках). Аргументы - это структурные элементы согласованности, услуги или параметры. Должны быть указаны один или несколько аргументов. Если имеется более чем один аргумент, то они отделены одним или несколькими пробелами. Аргумент рассмотрен как булева переменная. Она имеет значение true, если соответствующая услуга или структурный элемент параметра поддерживается как результат обмена инициированием MMS. Если аргумент только один, то строки, идущие за утверждением IF до утверждения ELSE (или соответствующего утверждения ENDIF, когда утверждение ELSE отсутствует), должны быть включены в результирующее определение ASN.1, если поддерживается структурный элемент согласованности с тем же именем. Если имеется более чем один аргумент, то строки, идущие за утверждением IF, должны быть включены, если в списке аргументов поддерживается определенный структурный элемент согласованности. Это можно рассматривать как логическую функцию OR структурного элемента согласованности.

Утверждения IF могут образовывать вложения любой глубины. Смысл функций IF(x) и IF(y) заключается в том, чтобы включить строки, следующие за указанными командами, если x и y имеют значение true, то есть если блок согласованности x и блок согласованности y (оба блока) включены. Это можно рассматривать как логическую функцию AND структурного элемента согласованности.

Утверждение ELSE можно использовать, чтобы предоставить возможность включения утверждения ASN.1, если структурный элемент согласованности не имеет значения true. Его использование аналогично нормальному использованию утверждения ELSE в языках программирования.

Утверждение ENDIF используется для указания конца области применения утверждения IF или утверждения ELSE. Каждое утверждение IF должно иметь соответствующее утверждение ENDIF.

5.15 Определение эффективного протокола

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

a) для каждой СВВ-услуги и каждого СВВ-параметра, объявленного или оговоренного для обмена типа Initiate, задают значение соответствующего аргумента равным true;

b) переделывают весь модуль ASN.1, описанный в настоящем стандарте. Для каждого утверждения IF оценивают его аргумент:

i) если любой из элементов аргумента имеет значение true, то оставляют утверждения, расположенные между утверждением IF и соответствующим утверждением ENDIF (утверждением ELSE, если оно есть). Отменяют утверждения, расположенные между утверждением ELSE и соответствующим утверждением ENDIF,

ii) если все элементы аргумента имеют значение false, то отменяют следующие утверждения до соответствующего утверждения ELSE (утверждения ENDIF). Если имеется утверждение ELSE, то удерживают утверждения, расположенные далее между ним и соответствующим утверждением ENDIF,

iii) отменяют утверждение IF и соответствующее ему утверждение ENDIF (и утверждение ELSE, если оно есть). В итоге получается модуль ASN.1, лишенный утверждений IF, ELSE и ENDIF;

c) в каждой разработке заменяют все комбинации "запятая+правая скобка" на правую скобку;

d) формируют рабочий модуль разработок ASN.1, содержащий только первую разработку (то есть разработку MMSpdu раздела 7);

e) добавляют к рабочему модулю ASN.1 любые разработки, на которые производятся ссылки в указанном рабочем модуле и которые в рассматриваемом модуле не содержатся;

f) повторяют шаг е) до тех пор, пока не перестанут добавляться новые разработки.

Результирующий модуль ASN.1 - это модуль, являющийся эффективным для рассматриваемой комбинации СВВ. Подтверждение получения блока данных PDU, не соответствующего настоящему модулю, приведет к выбраковке.

6 Элементы протокольной процедуры

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

6.1 Описательные соглашения

На рисунках настоящего подраздела использован описательный механизм для стандартной диаграммы состояний. Ниже дано описание данного механизма. Все диаграммы состояний показаны с точки зрения MMS-провайдера.

Каждое состояние представлено прямоугольником. Имя состояния - внутри прямоугольника. Каждая стрелка указывает переход в данное состояние или из данного состояния. Головка стрелки указывает результирующее состояние, как результат перехода.

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

Примитивы услуг с плюсом "+" указывают примитив услуг, содержащий параметр Result(+). Примитивы услуг с минусом "-" указывают примитив услуг, содержащий параметр Result(-).

6.2 Вход и выход из среды MMS

Услуги инициирования, завершения и прерывания доставляют механизмы входа и выхода из среды MMS. Модель указанных услуг (описывающая допустимые последовательности событий) описана в ИСО 9506-1, раздел 8.

6.3 Работа в среде MMS

В среде MMS может быть несколько услуг, одновременно ожидающих выполнения в любой момент времени. ИСО 9506 дает независимое описание диаграммы состояний каждого экземпляра такого запроса услуги.

Примечание - В других разделах настоящего стандарта определены дополнительные ограничения на допустимые последовательности примитивов услуг. Они могут дополнительно ограничивать MMS-пользователей.

6.3.1 Подтверждаемые MMS-услуги

Настоящий пункт содержит описание изменений состояния для всех подтверждаемых услуг (услуг с подтверждением), которые могут быть задействованы в среде MMS. Рассматриваемое множество услуг включает все услуги, запрошенные при использовании PDU с подтверждаемым запросом.

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

Все блоки данных PDU, ассоциированные с выполнением одной реализации подтверждаемой MMS-услуги (рассматриваемые PDU имеют типы Confirmed-RequestPDU, Confirmed-ResponsePDU, Confirmed-ErrorPDU, Cancel-RequestPDU, Cancel-ResponsePDU, Cancel-ErrorPDU и RejectPDU) отсылаются в одном и том же контексте представления данных.

Переходы:

Рисунок 1 - Подтверждаемый запрос услуги с точки зрения устройства, запрашивающего услуги

6.3.1.1 Устройство, запрашивающее услуги

Порядок получения блоков информации Cancel-ResponsePDU и Confirmed-ErrorPDU(x) в переходе 5 (см. 6.3.1) не вполне соответствует установленным требованиям.

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

После получения блока Confirmed-ResponsePDU с подтверждаемым ответом, описывающего предварительно запрошенную услугу, и идентификатора вызова, описывающего реализацию данной услуги, MMS-провайдер выдает примитив подтверждения услуги (дающий описание предварительно запрошенного типа услуги и идентификатора вызова) MMS-пользователю, содержащий параметр Result(+). После этого происходит переход в состояние "запрашивающее устройство не активировано".

После получения блока Confirmed-ErrorPDU, дающего описание предварительно запрошенной услуги, и идентификатора вызова, содержащего описание реализации услуги, MMS-провайдер выдает примитив подтверждения услуги (дающий описание предварительно запрошенного типа услуги и идентификатора вызова) MMS-пользователю, содержащий параметр Result(-). После этого происходит переход в состояние "запрашивающее устройство не активировано".

После получения примитива услуги отмены запроса от MMS-пользователя, MMS-провайдер отправляет блок Cancel-RequestPDU, содержащий идентификатор задействования отменяемого запроса (данная информация содержится в параметрах примитива отмены запроса). При этом система переходит в состояние "отмена запрашивающего устройства".

Состояние "отмена запрашивающего устройства" снимается после подтверждаемого получения одного из четырех возможных входных действий (см. далее).

После получения блока Cancel-ErrorPDU, содержащего описание идентификатора активизации, соответствующего рассматриваемой реализации запроса отмены услуги, MMS-провайдер выдает MMS-пользователю примитив услуги отмены подтверждения, содержащий параметр Result(-), и возвращается в состояние "ожидание услуги". В данном случае считается, что запрос отмены является неудачным.

Если запрос отмены удачный, то имеют место следующие события:

a) получение блока Cancel-ResponsePDU, идентификатор задействования которого соответствует правильной реализации запроса отмены услуги;

b) получение блока Confirmed-ErrorPDU, содержащего описание типа отмененной услуги и идентификатор задействования, соответствующий отмененной услуге;

c) MMS-провайдер выдает MMS-пользователю примитив услуги отмены подтверждения, содержащий параметр Result(+), и примитив подтверждения отменяемой услуги, содержащий параметр Result(-) (поясняющий причину отказа);

d) MMS-провайдер переходит в состояние "запрашивающее устройство неактивно".

Если получен блок Confirmed-ResponsePDU, содержащий описание типа отменяемой услуги, и идентификатор задействования, соответствующий отменяемой услуге, то MMS-провайдер выдает примитив подтверждения услуги, содержащий параметр Result(+) услуги, находящейся в процессе отмены. В данном случае запрос отмены считается неудачным, и блок Cancel-ErrorPDU будет получен в процессе активизации отмены услуг.

Примечание 1 - Обычно блок Confirmed-ResponsePDU подтверждаемого ответа и блок отмены запроса Cancel-RequestPDU выдаются одновременно двумя MMS-пользователями в процессе двустороннего диалога.

Если получен блок Confirmed-ErrorPDU, содержащий описание типа отменяемой услуги с соответствующим идентификатором активизации, и возникающая ошибка не относится к классу SERVICE-PREEMPT и коду CANCEL, то MMS-провайдер выдает примитив подтверждения услуги, содержащий параметр Result(-) для услуги, находящейся в процессе отмены. В данном случае запрос отмены считается неудачным, и блок Cancel-ErrorPDU получается в процессе активизации отмены услуг.

Примечание 2 - Обычно блок Confirmed-ErrorPDU подтверждаемой ошибки отменяемой услуги и блок отмены запроса Cancel-RequestPDU выдаются одновременно двумя MMS-пользователями в процессе двустороннего диалога.

Обработка ошибочных отмен производится в соответствии с 6.4.

Переходы:

Рисунок 2 - Подтверждаемый запрос услуги с точки зрения устройства, предоставляющего услуги

6.3.1.2 Устройство, предоставляющее услуги

Порядок, в котором в переходе 6 на рисунке 2 выдаются примитивы услуг Cancel.response+ и x.response-, может не соответствовать установленным требованиям.

На рисунке 2 показан процесс прохождения подтверждаемого запроса MMS-услуги с точки зрения устройства, предоставляющего услуги. До получения блока данных Confirmed-RequestPDU услуги, услуга считается находящейся в состоянии "Ответчик не активирован". После получения блока Confirmed-RequestPDU для любой подтверждаемой услуги, идентифицированной выше, MMS-провайдер выдает примитив отображения (дающий спецификацию конкретной запрошенной услуги и идентификатора активизации, содержащего описание реализации услуги) и входит в состояние "ожидание услуги".

После получения примитива услуги ответа, содержащей параметр Result(+) (представляет спецификацию ранее указанной услуги и идентификатора активизации, содержащего описание реализации данной услуги), MMS-провайдер отправляет блок данных Confirmed-ResponsePDU (представляет спецификацию типа услуги и идентификатора активизации для рассматриваемого примитива ответа). Далее система переходит в состояние "ответчик не активирован".

После получения примитива услуги ответа, содержащей параметр Result(-) (представляет спецификацию ранее указанной услуги и идентификатора активизации, содержащего описание реализации данной услуги), MMS-провайдер отправляет блок данных Confirmed-ErrorPDU (представляет спецификацию типа услуги и идентификатора активизации из примитива ответа). Далее система переходит в состояние "ответчик не активирован".

После получения блока данных Cancel-RequestPDU, представляющего спецификацию идентификатора активизации соответствующей реализации услуги, MMS-провайдер выдает примитив услуги отмены отображения, представляющий спецификацию идентификатора активизации запроса отменяемой услуги (данная информация предоставляется параметром блока Cancel-RequestPDU). Далее система переходит в состояние "отмена активизации ответчика".

Примечание 1 - Действия, предпринимаемые при получении блока данных Cancel-RequestPDU, идентификатор задействования которого не соответствует ожидающим выполнения реализациям услуги, описаны в 6.4.

Состояние "отмена активизации ответчика" снимается после получения одного из двух возможных входных действий. Они описаны в двух следующих пунктах.

Когда запрос отмены достигает ответающегося MMS-пользователя, имеет место нижеследующая последовательность событий:

a) ответающийся MMS-пользователь выдает ответ отмены, дающий спецификацию идентификатора активизации соответствующей реализации услуги и содержащий параметр Result(+), MMS-провайдеру. Он также выдает примитив услуги ответа, содержащий параметр Result(-) (представляет спецификацию класса ошибок SERVICE-PREEMPT и кода ошибки CANCEL) отменяемой услуги;

b) MMS-провайдер отправляет блоки данных Cancel-ResponsePDU и Confirmed-ErrorPDU, представляющих спецификацию реализации отменяемой услуги (с классом ошибок SERVICE-PREEMPT и кодом ошибки CANCEL);

c) MMS-провайдер возвращается в состояние "ответчик не активирован".

MMS-пользователь не должен выдавать примитив услуги отмены ответа, содержащий параметр Result(+), без выдачи примитива услуги ответа, содержащей параметр Result(-), дающий описание класса ошибок SERVICE-PREEMPT и кода ошибки CANCEL. И наоборот, MMS-пользователь не должен выдавать примитив услуги ответа, содержащей параметр Result(-), представляющий описание класса ошибок SERVICE-PREEMPT и кода ошибки CANCEL, а также примитив услуги отмены ответа, содержащий параметр Result(+). Таким образом, указанные два события логически происходят вместе.

Если получен ответ отмены, дающий спецификацию идентификатора активизации соответствующей реализации услуги, содержащего параметр Result(-), то MMS-провайдер отправляет блок данных Cancel-ErrorPDU и возвращается к состоянию "ожидание услуги". В данном случае запрос отмены считается неудачным.

Примечание 2 - Обработка ошибочных запросов отмены и некорректных блоков данных PDU описана в 6.4.

6.3.2 Неподтверждаемые MMS-услуги

Настоящий пункт содержит описание порядка выполнения неподтвержденных MMS-услуг. Данное множество услуг определено как услуги, совершающие выбор UnconfirmedService, определенный в разделе 7.

На рисунках 3-4 даны диаграммы изменения состояния, приложенные к каждой указанной выше услуге и используемые отдельно для каждой реализации каждого запроса услуги.

Рисунок 3 - Неподтвержденная услуга с точки зрения устройства, запрашивающего услуги

6.3.2.1 Устройство, запрашивающее услуги

На рисунке 3 показан процесс прохождения неподтверждаемой MMS-услуги с точки зрения устройства, запрашивающего эти услуги. Перед выдачей примитива запроса услуги считается, что услуга находится в состоянии "запрашивающее устройство не активировано". После получения примитива запроса для любой из вышеуказанных неподтверждаемых услуг, MMS-провайдер отправляет блок данных Unconfirmed-PDU (представляющий спецификацию конкретной запрашиваемой услуги) и переходит назад в состояние "запрашиваемое устройство не активировано".

Для неподтвержденных MMS-услуг ответа PDU или ошибки PDU не доставляются. Далее показано, что отменить неподтвержденную MMS-услугу невозможно.

Рисунок 4 - Неподтвержденная услуга с точки зрения устройства, предоставляющего услуги

6.3.2.2 Устройство, предоставляющее услуги

На рисунке 4 показан процесс прохождения неподтверждаемой MMS-услуги сточки зрения устройства, предоставляющего эти услуги. Перед получением блока данных Unconfirmed-PDU считается, что услуга находится в состоянии "ответчик не активирован". После получения примитива запроса для любой вышеуказанной неподтверждаемой услуги, MMS-провайдер выдает примитив услуги отображения (представляющий спецификацию конкретной запрашиваемой услуги, основанной на информации полученного блока Unconfirmed-PDU) и переходит из состояния "ответчик не активирован" в состояние "ответчик не активирован" (в то же самое состояние!).

Для неподтвержденных MMS-услуг, MMS-пользователь может не выдавать какого-либо примитива ответа. Ниже показано, что отменить неподтвержденную MMS-услугу невозможно.

6.3.3 Услуга отмены

Услуга отмены (в этом случае, если это подтвержденная услуга) работает не так, как другие подтверждаемые услуги. Если услуга отмены задействована, то механизм перехода в нужное состояние не работает. И действительно, здесь оказывается поврежденным механизм перехода отменяемой услуги в требуемое состояние. Запрос услуги отмены не может быть отменен повторным задействованием услуги отмены. Идентификатор задействования, описанный в запросе услуги отмены, не может быть идентификатором повторного задействования услуги отмены, так как данная услуга работает только с теми услугами, где сделан запрос подтверждаемой услуги ConfirmedServiceRequest (определение приведено в разделе 7).

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

Особенности работы услуги отмены описаны в предшествующих разделах настоящего документа: это работа устройства, запрашивающего услуги, и устройства, предоставляющего услуги для подтвержденных MMS-услуг.

6.4 Обработка условий ошибок

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

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

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

Примечание 1 - Возможно возникновение ситуации, при которой блоки Cancel-RequestPDU, Confirmed-ResponsePDU или Confirmed-ErrorPDU рассматриваемой отменяемой услуги выдаются одновременно двумя общающимися MMS-пользователями. Тогда одна сторона считает, что услуга выполнена, а другая сторона считает, что услуга ожидает отмены. В данном случае запрос отмены срывается, и услуга выполняется в нормальном режиме.

После получения блока данных Cancel-ErrorPDU, где механизм смены состояний (на который производится ссылка идентификатором задействования отменяемой услуги) находится в состоянии "запрашиваемое устройство не активировано", MMS-провайдер выдает примитив услуги отмены подтверждения MMS-пользователю.

Примечание 2 - Данный случай имеет место, когда блок данных Confirmed-ResponsePDU (блок данных Confirmed-ErrorPDU) отменяемой услуги считает корректным блок Cancel-RequestPDU данной услуги.

6.5 Услуга выбраковки и блок данных RejectPDU

Услугу выбраковки используют для уведомления MMS-пользователя об имеющихся ошибках протокола. Работа настоящей услуги описана в ИСО 9506-1, раздел 7.

Примечание - Действия, предпринимаемые MMS-пользователем после получения примитива услуги выбраковки отображения, имеют локальный характер. Важно отметить, что вследствие возможности выбраковки запроса, ответа или ошибки, два общающихся MMS-пользователя могут по-разному понимать состояние объектов, ожидающих транзакции (см. ИСО 9506-1, раздел 7). Услуга прерывания может использоваться в любой момент MMS-пользователем для завершения пребывания в среде MMS-Environment и завершения прикладной ассоциации.

7 Блоки данных протокола спецификации производственных сообщений MMS PDU

Настоящий раздел описывает блоки данных PDU, используемые для обработки протокола MMS. Отображение указанных PDU на услуги нижнего уровня описано в разделе 24. Отображение MMS-услуг на указанные блоки данных PDU описано в разделах 8-23.

Существуют 14 типов блоков данных протоколов PDU в MMS. В разделе 8 определены блоки Initiate-RequestPDU, Initiate-ResponsePDU, Initiate-ErrorPDU, Conclude-RequestPDU, Conclude-ResponsePDU, Conclude-ErrorPDU, RejectPDU, Cancel-RequestPDU, Cancel-ResponsePDU и Cancel-ErrorPDU. Оставшиеся типы PDU определены в 7.1-7.4.

7.1 Confirmed-RequestPDU (подтверждение запроса)

Confirmed-RequestPDU - это последовательность, содержащая четыре элемента: целое без знака, перечень модификаторов по выбору, подтверждаемый запрос услуги ConfirmedServiceRequest и подробности запроса Request-Detail.

Идентификатор задействования InvokelD - это 32-битное целое без знака. Он однозначно идентифицирует запрос услуги среди всех ожидающих выполнения подтвержденных запросов услуги от конкретного MMS-пользователя по заданной прикладной ассоциации. В любой момент времени должен иметь место самое большее один ожидающий выполнения запрос услуги от конкретного MMS-пользователя по некоторой прикладной ассоциации для любого заданного идентификатора задействования InvokelD. Значение InvokelD указано MMS-пользователем в примитиве запроса услуг (см. ИСО 9506-1, раздел 5). Значение InvokelD, указанное в Confirmed-ResponsePDU и Confirmed-ErrorPDU, предоставляет возможность MMS-провайдеру и MMS-пользователю коррелировать указанные PDU с рассматриваемым запросом услуги.

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

________________

* Текст документа соответствует оригиналу. - .

Запрос подтверждаемой услуги ConfirmedServiceRequest нужен для ее идентификации и аргумента. Данный параметр описан в 7.1.1.

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

7.1.1 ConfirmedServiceRequest (запрос подтверждаемой услуги)

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

7.1.2 AdditionalService-Request (запрос дополнительной услуги)

7.1.3 Request-Detail (подробности запроса)

7.2 The Unconfirmed-PDU (неподтверждаемый блок данных)

Неподтверждаемый блок данных Unconfirmed-PDU представляет из себя последовательность, содержащую неподтверждаемые услуги UnconfirmedService и неподтверждаемые подробности (детали) Unconfirmed-Detail.

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

7.2.1 UnconfirmedService (неподтверждаемая услуга)

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

7.2.2 Unconfirmed-Detail (неподтверждаемые подробности)

Блок данных подтверждаемого ответа Confirmed-ResponsePDU - это последовательность, содержащая три элемента: целое без знака, сущность ConfirmedServiceResponse и сущность Response-Detail.

7.3 Confirmed-ResponsePDU (блок данных подтверждаемого ответа)

Идентификатор задействования InvokelD - это 32-битное целое без знака. Он однозначно идентифицирует запрос услуги среди всех ожидающих выполнения подтвержденных запросов услуги от конкретного MMS-пользователя по заданной прикладной ассоциации. В любой момент времени должен иметь место самое большее один ожидающий выполнения запрос услуги от конкретного MMS-пользователя по некоторой прикладной ассоциации для любого заданного идентификатора задействования InvokelD. Значение InvokelD указано MMS-пользователем в примитиве запроса услуг (см. ИСО 9506-1, раздел 5). Значение InvokelD, указанное в Confirmed-ResponsePDU и Confirmed-ErrorPDU, предоставляет возможность MMS-провайдеру и MMS-пользователю коррелировать указанные PDU с рассматриваемым запросом услуги.

Сущность ConfirmedServiceResponse нужна для идентификации подтверждаемой услуги и ответа по данной подтверждаемой услуги. Данный параметр описан далее в 7.3.1.

7.3.1 ConfirmedServiceResponse (ответ на подтвержденную услугу)