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

(утв. и введен в действие Приказом Росстандарта от 26.11.2014 № 1864-ст)

1 января 2016 года

Предисловие

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

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 26 ноября 2014 г. № 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. Аналогично, эти более общие строки также могут быть использованы как идентификаторы. Добавленные новые параметры CBB создают условия для обсуждения условий применения указанных более общих строк;

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

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

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

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

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

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

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

Протокол

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

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

1. синтаксические расширения, определенные сопутствующими стандартами, теперь идентифицированы новыми параметрами CBB вместо отдельного абстрактного синтаксиса. Следовательно, для любых возможностей сопутствующих стандартов, использующих 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). В настоящем стандарте использованы следующие термины:

a) прикладная сущность;

b) прикладной процесс;

c) прикладной сервисный элемент;

d) открытая система;

e) (N) — протокол;

f) (N) — блок данных протокола;

h) (N) — уровень;

i) система.

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

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

a) подтверждение;

b) индикация;

c) примитив;

d) запрос;

e) ответ;

f) примитив услуг;

g) провайдер услуг;

h) пользователь услуг.

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

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

a) значение;

b) тип;

c) простой тип;

d) структурный тип;

e) тип компонента;

f) тег;

g) теговая разметка;

h) ссылочное имя типа (значения);

i) тип строки символов;

j) булевый тип;

k) true (истина);

l) false (ложь);

m) целый тип;

n) тип битовой строки;

o) тип октетной строки;

p) нулевой тип;

q) тип последовательности;

r) последовательный тип;

s) тегированный тип;

t) тип выбора;

u) тип отбора;

v) действительный тип;

w) тип идентификатора объекта;

x) модуль;

y) разработка;

z) правила кодирования ASN.1;

aa) множество символов ASN.1;

ab) внешний тип.

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; CBB): Элементарный блок, используемый для описания требований согласованности 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-пользователь и MMPM

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

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

В настоящем стандарте использованы термины «отправляющий MMPM» и «получающий MMPM». Отправляющий MMPM — это механизм MMPM, отправляющий блок данных производственной спецификации MMS PDU. Получающий MMPM — это механизм MMPM, получающий 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, данные в настоящем стандарте (см. приложение A), являются частью модуля ASN.1 «MMS-Environment-1». Определения ASN.1, данные в настоящем стандарте (приложение B), являются частью модуля ASN.1 «MMS-SCI-Module-1». Определения ASN.1, данные в настоящем стандарте (приложения C, D, и E), являются частью модуля ASN.1 «ISO-9506-1A». Начальные и конечные утверждения, указывающие, что каждое данное определение ASN.1 является частью соответствующего модуля, опущены для читабельности документа. Каждое определение ASN.1, данное неявно, содержит следующее утверждение

ModuleName DEFINITIONS ::= BEGIN

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

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

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

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

• 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 Определение эффективного протокола

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

a) для каждой CBB-услуги и каждого CBB-параметра, объявленного или оговоренного для обмена типа 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) повторяют шаг e) до тех пор, пока не перестанут добавляться новые разработки.

Результирующий модуль ASN.1 — это модуль, являющийся эффективным для рассматриваемой комбинации CBB. Подтверждение получения блока данных 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 показаны диаграммы изменения состояния. Они приложимы ко всем указанным услугам и отдельно к каждой реализации каждого запроса услуги. В любой заданный момент времени одновременно могут ожидать выполнения сразу несколько реализаций запросов услуги. Эти реализации подлежат упорядочиванию в соответствии с правилами, установленными в других разделах настоящего стандарта.

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

Переходы:

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

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

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.3.1.2 Устройство, предоставляющее услуги

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

Переход:

1 — v.request

Uniconfirmed-PDU(y)

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

Переход:

1 — Uniconfirmed-PDU(y)

y.indication

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

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

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

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

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.

Идентификатор задействования InvokeID — это 32-битное целое без знака. Он однозначно идентифицирует запрос услуги среди всех ожидающих выполнения подтвержденных запросов услуги от конкретного MMS-пользователя по заданной прикладной ассоциации. В любой момент времени должен иметь место самое большее один ожидающий выполнения запрос услуги от конкретного MMS-пользователя по некоторой прикладной ассоциации для любого заданного идентификатора задействования InvokeID. Значение InvokeID указано MMS-пользователем в примитиве запроса услуг (см. ИСО 9506-1, раздел 5). Значение InvokeID, указанное в 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 (блок данных подтверждаемого ответа)

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

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

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

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

7.3.2 AdditionalService-Response (ответ на дополнительную услугу)

7.3.3 Response-Detail (подробности ответа)

7.4 Confirmed-ErrorPDU (блок данных протокола подтверждаемой ошибки)

Сущность Confirmed-ErrorPDU — это последовательность трех элементов: целое без знака, целое без знака по выбору и сущность ServiceError (ошибка услуги).

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

Сущность modifierPosition — это 32-битное целое без знака. Данная сущность однозначно идентифицирует модификатор среди всех модификаторов, указанных в перечне модификаторов listOfModifiers блока данных подтверждаемого запроса Confirmed-RequestPDU, идентифицированного сущностью InvokeID. Данный параметр получается из подпараметра modifierPosition параметра ошибки услуги ServiceError из примитива услуги ответа (см. ИСО 9506-1, раздел 24).

Сущность ServiceError идентифицирует класс ошибок и код ошибки как для модификатора подтверждаемой услуги, так и для самой подтверждаемой услуги. Параметр ServiceError описан в 7.4.1.

7.4.1 ServiceError (ошибка услуги)

Тип ServiceError идентифицирует класс ошибки и код ошибки. Он доставляет код ошибки, сообщение об ошибке, а также специальную информацию для услуг, требующих дополнительную информацию, передаваемую при возникновении ошибки. Сущность ErrorClass, особые значения ErrorClass, а также параметры дополнительного кода additionalCode и дополнительного описания additionalDescription получаются в соответствии с соглашениями (см. 5.5) в настоящем стандарте и определениями раздела 24 ИСО 9506-1.

Выбор класса ошибки errorClass основан на выборе подпараметра класса ошибок для параметра типа ошибки ErrorType, указанного примитивом услуги ответа. В свою очередь, выбор значения для класса ошибок основан на выборе подпараметра кода ошибки для параметра типа ошибки ErrorType, указанного примитивом услуги ответа. Параметры additionalCode и additionalDescription получены из подпараметров параметра типа ошибки ErrorType с тем же именем.

Особая информация услуги serviceSpecificInformation отсутствует, если параметр modifierPosition присутствует в блоке данных Confirmed-ErrorPDU. Если параметр modifierPosition не присутствует в блоке данных Confirmed-ErrorPDU, то информация serviceSpecificInformation может быть получена из других параметров, описанных как подпараметры параметра Result(-) для конкретных услуг (если такие особые подпараметры услуг существуют).

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

7.4.2 AdditionalService-Error (ошибка дополнительной услуги)

7.5 Типы обычных MMS

В настоящем подразделе определены ряд типов, на которые произведены ссылки в настоящем стандарте.

7.5.1 TimeOfDay

TimeOfDay ::= OCTET STRING (SIZE(4|6))

Тип TimeOfDay — это октетная строка OCTET STRING. Значение типа TimeOfDay может содержать четыре (4) или шесть (6) октетов. Первая форма указывает время как число миллисекунд, прошедших с полуночи текущей даты (дата в значении не содержится). Вторая форма содержит и время, и дату, выраженную относительно 1 января 1984 г. Первые четыре октета содержат значения, указывающие число миллисекунд, прошедших с полуночи текущей даты, для обеих форм. Значение временной области получается путем нумерации битов указанных октетов, начиная с наименее значительного бита последнего октета (как нулевого бита). Нумерация заканчивается наиболее значительным битом первого октета — битом № 31. Каждому биту назначается численное значение, равное 2**N, где N — позиция рассматриваемого бита в настоящей последовательности нумерации. Значение времени получается суммированием численных значений, назначенных каждому биту (для битов со значением, равным единице). Биты с номерами 28 — 31 всегда равны нулю.

Ниже представлены октеты типа TimeOfDay. Если значение содержит дату (6-октетный контент), то представление (в обозначениях ASN.1 bstring) имеет вид:

'0 0 0 0 t t t t t t t t t t t t t t t t t t t t t t t t t t t t d d d d d d d d d d d d d d d d ' B

Если значение не содержит дату (4-октетный контент), то последние два октета («d...d») опускают. В вышеуказанном представлении bstring «t...t» — это относительное число миллисекунд указанного дня. Число миллисекунд для полуночи равно 0. «d...d» — это относительное число дней, начиная с 1 января 1984 г. (когда оно равно 0). Все значения даны в бинарной форме.

Наиболее значительный бит значения рассматриваемой подобласти указан выше в строке bstring. Значения битов уменьшаются для последующих битов этой строки.

Если система использует тип TimeOfDay, то она должна описывать степень дробления подобласти «t...t» в утверждении согласованности практической реализации протокола (см. раздел 18).

7.5.2 Идентификаторы и целые типы

В настоящем стандарте рассмотрены типы «Identifier», «Integer8», «Integer16», «Integer32», «Unsigned8», «Unsigned16» и «Unsigned32». Указанные типы определены следующим образом.

Среда MMS определяет различные типы имен (имя переменной, имя типа и т.д.) в терминах разработки идентификатора. Длина идентификатора ограничена 32 символами. Они выбираются из набора символов, определенных либо типом видимой строки VisibleString (если символы char CBB не поддерживаются), либо типом UTF8String (если символы char CBB поддерживаются). Выбор идентификатора зависит от конкретной ситуации.

Типы Integer8, Integer16, Integer32, Unsigned8, Unsigned16 и Unsigned32 В настоящем стандарте представлены целые в ограниченном диапазоне. Минимальное и максимальное представительные значения описаны в комментариях, следующих за объявлением типа.

7.5.3 ObjectName (имя объекта)

Параметр ObjectName получается в соответствии с правилами 5.5 на основе определения параметра услуги ObjectName, представленного в разделе 7 ИСО 9506-1.

7.5.4 ObjectClass (класс объекта)

Параметр ObjectClass получается в соответствии с правилами 5.5. Определение параметра услуги ObjectClass представлено в разделе 7 ИСО 9506-1.

7.5.5 ApplicationReference (ссылка приложения)

Форма типа ApplicationReference зависит от используемой системы связи. Для определений, совместимых с OSI-связью, представлены в приложении A.

7.5.6 MMSString (строка MMS)

Строка MMSString используется для хранения пользовательских строк в соответствующих наборах символов. Ее тип определен следующим образом:

Если аргумент char не описан, то строка MMSString дает известное множество 94 символов, используемое в английском языке. Если аргумент char описан, то MMSString делает возможным полную спецификацию в соответствии с требованиями UNICODE.

7.5.7 FileName (имя файла)

filename ::= SEQUENCE OF GraphicString

Тип FileName включает последовательность графических строк. Определение семантики элементов указанной последовательности графических строк имени файла — это локальная тема. Любые ограничения, наложенные системой, удовлетворяющей требованиям ИСО 9506-1 и настоящего стандарта, на длину и корректные обозначения сущности FileName, описаны утверждением конфигурации и инициализации системы (см. раздел 25). Как минимум, каждая практическая реализация, использующая тип FileName, определенный в настоящем пункте, должна поддерживать имена файлов, содержащие один элемент, включающий от одной до восьми заглавных букв или цифр. Имя всегда начинается с буквы.

Примечание - ИСО 9506-1 и настоящий стандарт не дают интерпретацию компонент сущности FileName. Указанные компоненты доставляют прозрачный механизм поименования заказчику и ответчику. Соотношение между компонентами, определенное в виртуальном файлохранилище, и любое деление сущности на компоненты в реальной среде функционирования системы — это локальный выбор практической реализации. Рассматриваемая практическая реализация может отображать локальную структуру компонентов на компоненты сущности FileName. Также она может отображать существующий синтаксис FileName на сущность FileName с однокомпонентным именем. Практическая реализация может отражать компоненты FileName среды MMS путем выбора пути доступа к реальному файлу. Однако данный выбор не всегда очевиден при обеспечении взаимосвязи в среде MMS.

8 Среда и протокол общего управления

8.1 Введение

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

инициирование;

завершение;

прерывание;

отмена;

выбраковка.

8.2 Инициирование

Абстрактный синтаксис запроса (ответа, ошибки) инициирования услуги описан типами Initiate-RequestPDU, Initiate-ResponsePDU и Initiate-ErrorPDU соответственно, представленными ниже. В 5.5 описан порядок получения всех параметров, не приведенных явно в настоящем разделе. Любые дополнительные корректные помеченные значения ASN.1, полученные как элементы последовательности Initiate-RequestPDU, Initiate-ResponsePDU и Initiate-ErrorPDU, игнорируются для обеспечения требуемого уровня совместимости.

8.2.1 Initiate-RequestPDU (блок данных запроса инициирования)

Абстрактный синтаксис запроса инициирования услуги — это Initiate-RequestPDU.

8.2.2 Initiate-ResponsePDU (блок данных ответ инициирования)

Абстрактный синтаксис ответа услуги инициирования — это Initiate-ResponsePDU.

8.2.3 Initiate-ErrorPDU (блок данных ошибки инициирования)

Абстрактный синтаксис ошибки услуги инициирования — это Initiate-ErrorPDU.

8.3 Завершение

Абстрактный синтаксис запроса (ответа, ошибки) услуги завершения описан типами Conclude-RequestPDU, Conclude-ResponsePDU и Conclude-ErrorPDU соответственно, приведенными ниже. В 5.5 представлено описание порядка получения всех параметров, не описанных в настоящем подразделе.

Conclude-RequestPDU ::= NULL

Conclude-ResponsePDU ::= NULL

Conclude-ErrorPDU ::= ServiceError

8.3.1 Conclude-RequestPDU (блок данных запроса завершения)

Абстрактный синтаксис запроса услуги завершения — это Conclude-RequestPDU.

8.3.2 Conclude-ResponsePDU (блок данных ответа завершения)

Абстрактный синтаксис услуги ответа завершения — это Conclude-ResponsePDU.

8.3.3 Conclude-ErrorPDU (блок данных ошибки завершения)

Абстрактный синтаксис ошибки услуги завершения — это Conclude-ErrorPDU.

8.4 Прерывание

Услуга прерывания прямо отображается на услугу M-U-Abort (см. раздел 24).

8.5 Отмена

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

8.5.1 Cancel-RequestPDU (блок данных запроса отмены)

Абстрактный синтаксис запроса услуги отмены — это Cancel-RequestPDU.

8.5.2 Cancel-ResponsePDU (блок данных ответа отмены)

Абстрактный синтаксис ответа услуги отмены — это Cancel-ResponsePDU.

8.5.3 Cancel-ErrorPDU (блок данных ошибки отмены)

Абстрактный синтаксис ошибки услуги отмены — это Cancel-ErrorPDU.

8.6 Выбраковка

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