ГОСТ Р 56844-2015 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20101. Прикладные профили. Базовый стандарт

ГОСТ Р 56844-2015
/ISO/IEEE 11073-20101:2004

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

Информатизация здоровья

ИНФОРМАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ С ПЕРСОНАЛЬНЫМИ МЕДИЦИНСКИМИ ПРИБОРАМИ

Часть 20101

Прикладные профили. Базовый стандарт

Health informatics. Point-of-care medical device communication. Part 20101. Application profiles. Base standard

ОКС 35.240.80

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

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации" (ЦНИИОИЗ Минздрава) и обществом с ограниченной ответственностью "Корпоративные электронные системы" на основе собственного аутентичного перевода на русский язык англоязычной версии международного документа, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 "Информатизация здоровья" при ЦНИИОИЗ Минздрава - постоянным представителем ISO ТС 215

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073-20101:2004* "Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20101. Прикладные профили. Базовый стандарт" (ISO/IEEE 11073-20101:2004 "Health informatics - Point-of-care medical device communication - Part 20101: Application profiles - Base standard", IDT).

________________

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

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

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

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

1 Обзор

Настоящий стандарт содержит восемь разделов:

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

- в разделе 2 приведены ссылки на другие стандарты, используемые при применении настоящего стандарта;

- в разделе 3 приведены определения и сокращения;

- в разделе 4 представлены условные обозначения;

- в разделе 5 дано обоснование актуальности настоящего стандарта;

- в разделе 6 описана модель коммуникаций (т.е. протокол и сервис передачи данных);

- в разделе 7 описана информационная модель (модель объекта);

- в разделе 8 представлены требования соответствия.

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

- в приложении А (обязательное) определены специализированные правила кодирования медицинских приборов (MDER);

- в приложении В (обязательное) описано как распределены идентификаторы объектов;

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

- в приложении D представлены диаграммы переходов состояний для динамической модели;

- в приложении Е (обязательное) описан абстрактный синтаксис, который предлагает расширения к стандартам, на которые опирается настоящий стандарт, такие как минимальные взаимодействия открытых систем (mOSI), которые ориентированы на настоящий стандарт.

- в приложении F представлены примеры некоторых PDU.

- в приложении G рассмотрены спецификации языка абстрактного синтаксиса 1 (ASN.1).

- в приложении Н представлена информация о совместимости версий ASN.1 1988/90 г. и 1994 г.

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

Область применения настоящего стандарта распространяется на сервисы и протоколы верхнего уровня (т.е. уровень приложения, уровень представления и сеансовый уровень взаимодействия открытых систем по ИСО), используемые для обмена информацией в соответствии со стандартами ИСО/ИИЭР 11073, регламентирующими коммуникации медицинских приборов (MDC).

Настоящий стандарт является базовым стандартом ИСО/ИИЭР 11073-20000 для прикладных профилей медицинских приборов (MDAP), что было согласовано с Европейским комитетом по стандартизации (ЕКС) и ИСО.

1.2 Назначение

Назначением настоящего стандарта является определение приложения верхнего уровня коммуникаций медицинских приборов (MDC), т.е. профилей А-типа ИСО для обмена данными, которые определяются форматом языка данных медицинских приборов (MDDL), или же профилей F-типа ИСО (серия ИСО/ИИЭР 11073-10000).

1.3 Цели

Основная цель стандартов по прикладным профилям медицинских приборов (MDAP) - поддержать верхний уровень обмена данными между медицинскими приборами (MDC), осуществляемого на языке данных MDDL, между различными по типу и масштабу, будущими и применяемыми приборами, предназначенными для использования в местах оказания медицинской помощи (РОС) в медицинских отделениях интенсивной терапии.

1.4 Пользователи стандарта

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

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

a) комплекс ИСО/ИИЭР 11073, особенно стандарт ИИЭР Стд. 1073, ИСО/ИИЭР 11073-10201 и стандарты нижнего уровня (например, ИСО/ИИЭР 11073-30200);

_______________

Информацию по ссылкам можно найти в разделе 2.

b) по архитектуре уровней взаимодействия открытых систем ИСО, прежде всего для верхних уровней, т.е. уровней приложения, представления и сеансового;

c) по управлению системами;

d) по объектно-ориентированному анализу и проектированию;

e) по теории машинных языков.

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

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

_______________

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

ИИЭР 1073 Стандарт для обмена данными между медицинскими приборами. Обзор и основы (IEEE Std 1073, IEEE Standard for Medical Device Communications - Overview and Framework)

_______________

Публикации ИИЭР доступны в Институте инженеров по электротехнике и радиоэлектронике, Хос Лэйн, Пискатавэй, NJ 08854, США (http://standards.ieee.org/).

ИСО/МЭК 8327-1 Информационные технологии. Взаимодействие открытых систем. Протокол сеансового уровня в режиме с установлением соединения. Часть 1. Спецификация протокола (то же, что и Рекомендации сектора электросвязи МСЭ Х.225) (ISO/IEC 8327-1, Information technology - Open systems interconnection - Connection-oriented session protocol - Part 1: Protocol specification (same as ITU-T Recommendation X.225))

_______________

Публикации ИСО/МЭК доступны в Центральном Секретариате ИСО (Case Postale 56, 1 rue de , CH-1211, 20, Switzerland/Suisse (http://www.iso.ch/)). Также публикации ИСО/МЭК доступны в США в Global Engineering Documents (Всемирная инженерная документация), 15 Inverness Way East, Englewood, CO 80112, USA (http://global.ihs.com/). Электронные копии доступны в США в Американском национальном институте стандартов, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/).

ИСО/МЭК 8650-1 Информационная технология. Взаимосвязь открытых систем. Сетевой протокол передачи с установлением соединения для протокола прикладного уровня, используемого в OSI для организации связи между двумя приложениями. Часть 1. Протокол (то же, что и Рекомендации сектора электросвязи МСЭ Х.227) (ISO/IEC 8650-1, Information technology - Open systems interconnection - Connection-oriented protocol for the association control service element - Part 1: Protocol. (same as ITU-T Recommendation X.227))

ИСО/МЭК 8824-1 Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации (то же, что и Рекомендации сектора электросвязи МСЭ Х.680) (ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation (same as ITU-T Recommendation X.680))

ИСО/МЭК 8824-2 Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2: Спецификация информационных объектов (то же, что и Рекомендации сектора электросвязи МСЭ Х.681) (ISO/IEC 8824-2, Information technology - Abstract Syntax Notation One (ASN.1) - Part 2: Information object specification. (same as ITU-T Recommendation X.681))

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

ИСО/МЭК) 9072-2 Системы обработки информации. Передача текста. Удаленные операции. Часть 2. Спецификация протокола (ISO/IEC 9072-2, Information processing systems - Text communication - Remote operations - Part 2: Protocol specification)

ИСО/МЭК 9595 Информационная технология. Взаимосвязь открытых систем. Определение общих услуг информации административного управления (ISO/IEC 9595, Information technology - Open systems interconnection - Common management information service definition)

ИСО/МЭК 9596-1 Информационная технология. Взаимосвязь открытых систем. Протокол общей управляющей информации. Часть 1. Спецификация (ISO/IEC 9596-1, Information technology - Open systems interconnecton - Common Management Information Protocol - Part 1: Specification)

ИСО/МЭК 9899 Языки программирования - С (ISO/IEC 9899, Programming languages - С)

ИСО/МЭК 11188-3 Информационные технологии. Профиль международной стандартизации. Распространенные требования для верхнего уровня. Часть 3. Минимальные возможности верхнего уровня взаимодействия открытых систем (OSI) (ISO/IEC ISP 11188-3, Information technology - International standardization profile - Common upper layer requirements - Part 3: Minimal OSI upper layer facilities)

ИСО/ИИЭР 11073-10101 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10101. Номенклатура (ISO/IEEE 11073-10101 Health informatics - Point-of-care medical device communication - Part 10101: Nomenclature)

_______________

Публикации ИСО/МЭК доступны в Центральном секретариате ИСО (Case Postale 56, 1 rue de , CH-1211, 20, Switzerland/Suisse (http://www.iso.ch/)), в США в отделе продаж Американского национального института стандартов (25 West 43rd Street, 4th Floor, New York, NY 10036, USA (http://www.ansi.org/)) и в Институте инженеров по электротехнике и радиоэлектронике (445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/)).

ИСО/ИИЭР 11073-10201 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10201: Информационная модель предметной области (DIM) (Health informatics - Point-of-care medical device communication - Part 10201: Domain information model (DIM))

ИСО/ИИЭР 11073-30200 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 30200. Транспортный профиль. Приборы, подключенные кабелем (ISO/IEEE 11073-30200, Health informatics - Point-of-care medical device communication - Part 30200: Transport profile - Cable connected)

ИСО/ИИЭР 11073-30300 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами 30300. Транспортный профиль. Инфракрасная беспроводная связь (ISO/IEEE 11073-30300, Health informatics - Point-of-care medical device communication - Part 30300: Transport profile - Infrared Wireless)

Рекомендации сектора электросвязи МСЭ Х.681. Информационные технологии. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 2: Спецификация информационных объектов (то же, что и ИСО/МЭК 8824-2) (ITU-T Recommendation Х.681, Information Technology - Abstract Syntax Notation One (ASN.1) - Information Object Specification (same as ISO/IEC 8824-2)

_______________

Публикации ITU-T доступны в Международном союзе электросвязи (Place des Nations, CH-1211, Geneva 20, Switzerland/Suisse (http://www.itu.int/)).

3 Термины, определения и сокращения

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

В настоящем стандарте применяются следующие термины и определения. Для получения информации о терминах, не указанных в данном разделе, см. [3].

3.1.1 абстрактный синтаксис (abstract syntax): Спецификация структуры элемента данных, которая не ссылается или не содержит требования к конкретной технологии реализации.

3.1.2 обратный порядок байтов (big endian): Последовательность передачи байтов, при которой наиболее старший байт передается первым. Например, при передаче 32-битового целого числа первым передается наиболее старший байт (24-31 бит), а последним - самый младший байт (0-7 бит).

3.1.3 порядок следования байтов (byte order): Последовательность, в которой многобайтные простейшие элементы данных передаются в блоке данных протокола (PDU). Например, 32-битовое целое число содержит 4 байта. См. также 3.1.2.

3.1.4 объединение (coalescing): Функция объединения нескольких блоков данных протокола на уровне представлений (PPDU блоки) в один блок данных протокола на уровне сеанса (SPDU), который затем передается по коммуникационной сети.

3.1.5 правила кодирования (encoding rules): Спецификация преобразования простейших элементов данных, используемых в абстрактном синтаксисе, в формат реализации. В основном повторяет синтаксис передаваемых данных.

3.1.6 связанный ответ (linked reply): Ответ на команду, для передачи данных которого требуется более одного блока данных протокола (PDU). Например, отдельная команда выборки всего системного журнала может привести к получению нескольких, связанных между собой ответов от блоков данных протоколов, которые предоставляют запрашиваемую информацию.

_______________

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

3.1.7 значения данных уровня представления (presentation data value - PDV): Объединение множеств значений во всех возможных абстрактных синтаксисах.

3.1.8 синтаксис передачи (transfer syntax): Спецификация структуры данных, во время их передачи в коммуникационной или физической среде.

3.2 Сокращения

В дополнении к сокращениям стандарта ИИЭР 1073 в настоящем стандарте используются следующие сокращения:

4 Условные обозначения

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

5 Обоснование

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

5.1 Коммуникационная модель

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

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

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

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

Данное требование также строго связано с требованием к оптимизированным правилам кодирования;

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

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

Желательно определить транспортно-независимый интерфейс, хотя конкретные отображения блоков PDU верхнего уровня на сервисы транспортного профиля ИСО/ИИЭР 11073-30000, при необходимости, адресуются через подуровни, зависящие от транспортного протокола.

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

Подразумевается, что сложные протоколы сеансового уровня не требуются для коммуникации между медицинскими приборами, тем более что некоторые механизмы восстановления работоспособности системы после ошибки уже определены прикладными объектами, указанными в языке данных медицинских приборов (MDDL) (например, объектами scanner, т.е. "сканер").

Однако, для поддержания стандартного сервисного элемента управления ассоциацией (ACSE) требуется минимальный набор стандартных служб сеансов (SS) ИСО/ВОС, как минимум на время ассоциации.

Кроме того, требуется определить конкретные расширения сеансового уровня для оптимизации его процессов во время нормальной передачи данных (после ассоциации), которые будут совместно выполняться с протоколом сеансового уровня, определенным в ИСО/МЭК 8327-1.

Данная оптимизация касается, например:

- упрощения нормальных PDU уровня сеанса;

- объединения прикладных данных в единые PDU сеансового уровня для сокращения скорости передачи сообщений на уровне транспортного интерфейса и ниже.

5.2 Информационная модель

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

- как и объекты, определенные в языке данных медицинских приборов (MDDL), объекты, определенные в данной модели, представляют информацию, которой приборы обмениваются через коммуникационный канал. Определенные здесь объекты являются частью информационной базы медицинских данных (MDIB) (доступные прямо или косвенно), по сути, являющиеся информационными контейнерами;

- объектная модель фокусируется на обобщенных концептах для представления возможностей коммуникационного интерфейса (варьирующихся от, например, скорости связи до общих параметров качества обслуживания (QoS)), вопросах конфигурации интерфейса и статистических данных (например, для выявления и устранения ошибок). Модель должна быть независимой от конкретных реализаций нижнего уровня, но может содержать адаптации, характерные для более низких уровней ИИЭР;

- коммуникационный контроллер медицинского прибора (MDCC) наследует от коммуникационного контроллера (СС) язык данных медицинских приборов (MDDL), как определено в MDDL.1 (IEEE Std 1073.3.1 [5]); для внесения ясности и удобства использования ссылок настоящий стандарт может повторять определения из этого стандарта;

- в качестве нотации используется унифицированный язык моделирования (UML).

Атрибуты объектов и поведение будут определены в нотации, которая согласуется со стандартом языка данных медицинских приборов (MDDL), в частности в вопросах:

- форм статического представления: наследования, отношения включения, присваивания атрибутов;

- форм динамического представления в виде:

- конечного автомата соединения приборов со всеми обменами сообщениями;

- динамического поведения конкретных объектов, например, объектов scanner, определенных в языке данных MDDL.

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

Кроме того, для упрощения поддержки необходимо определить информационные объекты, относящиеся к управляющей информации, например, объекты конфигурации, доступа, характеристик работы и информации, связанной с отказоустойчивостью, как указано в ИСО/ИИЭР 11073-30200.

6 Коммуникационная модель

Настоящий раздел предназначен для определения служб (сервисов) и протоколов.

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

На рисунке 1 показан верхний уровень коммуникационного стека, т.е. многоуровневый набор компонентов протокола и сервиса.

Рисунок 1 - Стек MDC

На рисунке показаны компоненты коммуникационного стека, а именно:

- ACSE (сервисный элемент управления ассоциацией) является стандартом ИСО/ВОС для управления ассоциациями.

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

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

- сервисный элемент общей информации о медицинских приборах (CMDISE) - это служба управления объектами и по сути является упрощенной версией ИСО/ВОС сервисного элемента общей управляющей информации (CMISE);

- сервисный элемент удаленной операции (ROSE) предоставляет основные услуги, используемые сервисным элементом общей информации о медицинских приборах (CMDISE) (вызов операции, возврат результата операции, возврат ошибки, отклонение операции). В соответствии с определением оптимизированных правил кодирования, модифицированная версия сервисного элемента удаленной операции (ROSE) необходима для работы с сервисным элементом общей информации о медицинских приборах (CMDISE);

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

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

Компоненты информационной базы медицинских приборов (MDIB) нормативно определяются в документах элементов информационной модели предметной области (DIM) и базы управляющей информации (MIB) и кратко описываются следующим образом:

- система медицинского прибора (MDS) - объект включения наивысшего уровня, представляющий устройство в целом;

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

- коммуникационный контроллер прибора (DCC) - специализация, представляющая из себя агента коммуникационного контроллера прибора;

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

- интерфейс прибора (DIF) - абстрактное представление точки доступа к транспортному сервису;

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

Сообщение приложения, например, сообщение с отчетом о событии объекта scanner, как определено в языке данных медицинских приборов (MDDL), проходит через этот коммуникационный стек, как показано на рисунке 2.

Объект scanner извлекает данные из базы данных медицинской информации (MDIB) и преобразует их в поле информации о событии объекта scanner.

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

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

Рисунок 2 - Поток данных, проходящий через коммуникационный стек

6.2 Сервисный элемент управления ассоциацией (ACSE)

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

Для управления ассоциациями предполагается использовать стандартные сервисные элементы управления ассоциацией (ACSE), определенные в ИСО/МЭК 8650-1.

В дополнение к стандартным элементам ACSE необходимо определить набор полей информации пользователя, зависящих от приложения, а также минимальный (и обязательный) набор дополнительных элементов в блоках PDU ACSE.

6.2.2 Службы ACSE

В таблице 1 приведены службы (сервисы), предоставляемые сервисным элементом управления ассоциацией (ACSE).

Таблица 1 - Сводка сервисов ACSE

Службы отображаются в сообщения, то есть в протокольные блоки данных (PDU) приложения. Для служб A-ASSOCIATE, например, имеются два сообщения: сообщение запроса на ассоциацию (AARQ) и сообщение ответа на ассоциацию (AARE).

Каждая служба (и таким образом полученный APDU) имеет определенное число полей данных или параметров. Таблицы 2 и 3 содержат фактические параметры сообщения запроса ассоциации (AARQ) и ответного сообщения ассоциации (AARE) для вызовов сервисов, которые определены в ACSE. Обозначения полей: М - обязательное, О - дополнительное, U - на усмотрение пользователя.

Таблица 2 - Поля AARQ блока данных APDU

Таблица 3 - Поля AARQ блока APDU

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

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

6.2.3 Определение сообщения ACSE ASN.1

Для получения более подробной информации см. приложение Е.

Для обеспечения полной интероперабельности сообщения ACSE должны быть закодированы с помощью основных правил кодирования (BER). Кроме того, они должны быть преобразованы в соответствующий уровень представления протокольного блока данных PDU (Блок данных протокола уровня представления (PPDU)) (СР: Подключения уровня представления, СРА: Принятие подключения уровня представления) и блок данных протокола сеансового уровня (SDPU) (CN: сеанс подключения, АС: сеанс принятия), как определено в приложении Е.

6.2.4 Поля информации о пользователе в ACSE

Информационные поля конкретного пользователя (то есть зависящие от определенного приложения) в определении сообщения ACSE для использования в коммуникационном стеке интероперабельности определены в приложении Е.

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

6.3 Протокол сеансового уровня

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

6.3.2 Службы сеансового уровня

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

- подключение сеанса (Session connect);

- принятие сеанса (Session accept);

- передача данных сеанса (Session data transfer).

Может быть использовано несколько дополнительных услуг и протокольных блоков данных. Этот вопрос требует дальнейшего рассмотрения, особенно в отношении отображений элементов между ACSE, PPDU и SPDU.

6.3.3 Определения сообщений сеансового уровня

Для всех необходимых стандартных служб сеанса (SSs), а также для оптимизированного расширения сеансового уровня будет определена структура PDU (заголовок сеанса).

SPDU блоки построены из простых элементов в форме, указанной на рисунке 3.

Условные обозначения:

LI - индикатор длины (длина 0-254: один октет; иначе 3 октета, начиная с 255); PGI - идентификатор группы параметров (определяет группу параметров сеансового уровня); PI - идентификатор параметров (определяет отдельный параметр сеансового уровня); SI - идентификатор SPDU (уникальный идентификатор, определяющий тип сообщения сеансового уровня)

Рисунок 3 - Формат протокольного блока данных сеансового уровня (SPDU)

Поля параметров составлены из блоков PGI и PI по определенным правилам (в соответствии с ИСО/МЭК 8327-1).

Пример сообщения сеансового уровня представлен в п.6.3.3.1.

6.3.3.1 Подключение сеанса (CN) SPDU

Формат и содержание блока SPDU представлен следующим образом:

6.4 Протокол уровня представления

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

Протокол уровня представления позволяет согласовать абстрактный синтаксис (например, выбрать между MDDL и CMDISE ASN.1) и синтаксис передаваемых данных (т.е. оптимизированные правила кодирования, например, MDER) между системами.

Что касается протокола сеансового уровня, для поддержки ACSE необходимы некоторые ограниченные стандартные службы.

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

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

6.4.2 Службы уровня представления

Уровень представления предоставляет, например, следующие службы:

- Подключение уровня представления (Connect presentation);

- Принятие подключения уровня представления (Connect presentation accept);

- Предоставление данных (Presentation data).

6.4.3 Сообщения уровня представления

Определения следующих блоков PDU см. в приложении Е:

- Подключение уровня представления (СР) PPDU;

- Принятие подключения уровня представления (СРА) PPDU;

- Отклонение подключения уровня представления (CPR) PPDU;

- Протокол аварийного разъединения по инициативе провайдера (ARP) PPDU;

- Протокол аварийного разъединения по инициативе пользователя (ARU) PPDU;

- Предоставление данных (TD) PPDU.

6.5 Протокол ROSE

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

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

ROSE использует тот же абстрактный синтаксис, который рассматривается для применения в CMDIP и структур данных из ИСО/ИИЭР 11073-10201. Поэтому для соблюдения ограничений оптимизированных правил кодирования ASN.1 необходимо внести некоторые модификации в ROSE ИСО/ВОС.

6.5.2 Службы ROSE

Протокол ROSE является относительно простым протоколом, определяющим следующие службы (сервисы):

- Вызов удаленной операции (Remote operation invoke);

- Результат удаленной операции (Remote operation result);

- Ошибка удаленной операции (Remote operation error);

- Отклонение удаленной операции (Remote operation reject).

6.5.3 Определения сообщений протокола ROSE

Определения ROSE PDU см. в приложении Е.

6.6 Протокол CMDISE (CMDIP)

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

6.6.2 Сервисы CMDISE

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

- Возвращение значения атрибута объекта (Retrieve object attribute value);

- Модификация значения атрибута объекта (Modify object attribute value);

- Вызов заданных функций объекта (Invoke object defined functions);

- Создание и удаление экземпляров объекта (Create and delete object instances);

- Создание отчетов о событиях, произошедших внутри объекта (Report events that occurred within an object).

Параметры каждой из служб и соответствующие результаты определены в языке данных медицинских приборов (MDDL). В таблице 4 приведен пример службы event report (отчет о событии).

Таблица 4 - Параметры службы event report

6.6.3 Определения сообщений CMDIP

Определения типов данных ASN.1 для всех служб CMDIP определены в приложении Е.

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

Примеры блоков PDU приведены в приложении Е.

6.6.4 Простой сетевой протокол времени SNTP

См. приложение С.

7 Информационная модель

7.1 Модель объекта

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

- коммуникационный контроллер (СС), например коммуникационный контроллер прибора (DCC), прикроватный коммуникационный контроллер (ВСС);

- база управляющей информации (MIB).

- Для получения подробной информации об определении см. информационную модель предметной области (DIM).

7.2 Модель формата

7.2.1 Синтаксис

7.2.1.1 Синтаксис передаваемых данных

Синтаксис передаваемых данных определен в приложении А.

Отображения на ИСО АСН.1 приведены в приложении G.

7.2.1.2 Абстрактный синтаксис

Абстрактный синтаксис определен в приложении Е.

7.2.2 Совместимость

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

Таблица 5 - Проблемы совместимости

8 Соответствие

Настоящий раздел предназначен для определения критериев соответствия.

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

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

8.2 Администрирование идентификатора объекта

Настоящий стандарт выделяет административные полномочия идентификатора объекта для других стандартов, особенно для языка MDDL. Управление полномочиями требует обращения сначала к набору MDAP, а затем к спецификациям расширений, определенных более широким стандартом.

8.3 Соответствие подмножества MDAP

Профили MDAP должны определить степень соответствия с настоящим стандартом с помощью следующих категорий исключения:

а) отсутствие исключений. Подмножество не принимает никаких исключений к настоящему стандарту;

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

8.4 Соответствие реализации

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

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

Правила кодирования медицинских приборов (MDER)

А.1 Общие положения

Настоящее приложение определяет специализированные правила MDER, связанные с представлением последовательных двоичных строк, таким образом, каким они должны быть представлены в сети в сравнении с соответствующей организацией в памяти компьютера, с представлением в абстрактном синтаксисе, то есть в языке программирования или диаграмм, которые используются в спецификациях. Предполагается, что данная спецификация должна быть согласована с любой и каждой из альтернатив нижнего уровня ИСО/ИИЭР 11073. Таким образом, реализация на верхних уровнях может обеспечивать прозрачность на основе конкретного профиля нижнего уровня.

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

А.2 Поддерживаемый синтаксис ASN.1

ASN.1 является стандартным обозначением, которое используется для определения типов данных, значений и ограничений значений. Данное обозначение широко используется в стандартах ВОС и в серии стандартов ИСО/ИИЭР 11073 (например, в ИСО/ИИЭР 11073-10201, где все определения данных формируются с помощью ASN.1).

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

В отличие от других стандартов ИСО/ВОС для правил кодирования ASN.1 (например, основные правила кодирования или BER, правила компактного кодирования или PER) правила MDER оптимизированы только для подмножества ASN.1. Правила MDER не поддерживают полный набор типов данных ASN.1, а лишь определенный ограниченный набор конструкций ASN.1.

Стандарты ИСО/ИИЭР 11073 используют этот ограниченный набор ASN.1 для определения типов данных, применяемых только в управляемых медицинских объектах, таким образом, правила MDER подходят и являются достаточными для кодирования структур данных в рамках этих стандартов.

Ограниченный набор ASN.1, используемый для компонентов PDU стандартов ИСО/ИИЭР 11073, является строгим подмножеством допустимых типов данных ASN.1, поэтому другие общие стандартные правила кодирования (например, BER, PER) можно также использовать, как согласованные для конкретного профиля коммуникаций на более высоких уровнях.

Таблица А.1 определяет специализацию ASN.1, подходящую для кодирования MDER. Все компоненты ASN.1 PDU, предназначенные для кодирования MDER, являются предметами этой специализации.

Для каждого типа данных ASN.1 эта специализация сопровождается символом "I" для включенного с ограничением, "R" - для ограничений по использованию и "Е" - для исключения.

Более подробную информацию о специализации типов ASN.1 в MDER см. в приложении Н.

Таблица А.1 - Типы данных, поддерживаемые ASN.1

А.3 Порядок передачи байтов

На рисунке А.1 показано, как различные двоичные строки сети отображаются в строках памяти. На диаграммах представлен порядок передачи байтов в сети (Network byte order, NBO). Следующие правила пронумерованы для удобства использования ссылок:

- представление в диаграммах использует формат NBO, показанный на рисунке А.1;

- в MDER не используется выравнивание. То есть в строки байтов дополнительные байты не добавляются, например для получения длин, которые делятся на два или четыре. Тем не менее переменная длина элементов данных, то есть строк, должна содержать четное число байтов из соображений эффективности. Например, поскольку большинство элементов данных 16-битные, они не будут неправильно выровненными, если строки имеют четную длину;

- передачи данных в MDAP ограничены использованием соглашения NBO (обратный порядок передачи);

- для обеспечения общей интероперабельности протокол ассоциации должен использовать ИСО BER при согласовании условных обозначений MDER. Все остальные блоки PDU, которыми обменивается в период своей работы хост-устройство, будут основаны на MDER, например PDU CMIP* и ROSE*. Суффикс звездочка (*) означает, что MDER используется для оптимизации протокола ИСО, который, как правило, базируется на BER.

Многобайтовые структуры отображаются между сетью и компьютерной памятью и упорядочиваются в памяти компьютера двумя основными способами, называемыми big endian (формат с порядком следования байтов, начиная со старшего) и little endian (формат с порядком следования байтов, начиная с младшего). Формат big endian согласуется с NBO, a little endian - не согласуется. Например, в последнем примере на рисунке А.1 структура ABCD была бы упорядочена как DCBA. В этом случае если big endian является согласованным протоколом, то компьютер с little endian должен был бы переставлять компоненты этой структуры при получении их из памяти и передаче их в память, в случае необходимости. Макросы языка программирования и команды компьютера, выполняющие байтовый свопинг, которые, как правило, способствуют нормализации, являются проблемами реализации и могут быть упрощены ненормативными определениями, взятыми из настоящего стандарта или стандартов, связанных с ним.

Рисунок А.1 - NBO. Условные обозначения представления двоичной строки

А.4 Кодирование

А.4.1 Общие положения

В MDER отсутствует тегирование для простых типов. Теги используются только там, где дешифратору (декодеру) необходимо различать типы (например, для типа CHOICE). Поля длины используются только для элементов с переменной длиной и ограничены 64 КБайтами (16 битами), которых должно быть достаточно для передачи данных.

Простые типы определены из-за ограничений по размеру и имеют фиксированную длину. Типы SEQUENCE, имеющие фиксированную длину, поддерживаются при условии, если отсутствуют компоненты синтаксиса типа OPTIONAL. Если это неприемлемо, то должны быть определены стандартные правила кодирования для использования в стандартном профиле.

А.4.2 Тип INTEGER

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

На рисунке А.2 представлено поддерживаемое в MDER кодирование октет для ограниченных по размеру целочисленных значений.

_______________

Для стандартизации языка программирования С для целочисленных типов данных необходимо использовать определения ИСО/МЭК 9899.

Рисунок А.2 - Кодирование целых чисел

Октеты содержат представление закодированного целочисленного значения в дополнительном двоичном коде.

А.4.3 Тип BIT STRING

Кодирование значения битовой строки, относящейся к базовому типу, является простым. Содержимое октеты представляет множество битов в битовой строке. Битовая строка может содержать 8, 16, или 32 бита.

Бит 0 в кодировке представлен наиболее значимым битом (MSB), бит 1 представлен следующим битом в октете и т.д.

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

Рисунок А.3 - Кодирование битовой строки

Пример - Определение

state : : = BITS-16 {open (0), locked (1) }

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

short unsigned int state;

#define locked 0x4000

#define open 0x8000

(по аналогии с именованными битами в битовых строках).

А.4.4 Тип OCTET STRING

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

Будучи зависимы от этого типа октеты могут содержать печатаемые символы ASCII (в случае 16-битовых наборов символов символ использует 2 октета в кодировке) или строка может содержать больший объем инкапсулированных двоичных данных.

На рисунке А.4 представлено поддерживаемое в MDER кодирование октет для ограниченных по размеру значений битовых строк.

Как показано на рисунке А.4, MDER различают тип OCTET STRING с переменной длиной строки и тип OCTET STRING ограниченного размера.

Рисунок А.4 - Кодирование типов OCTET STRING

Тип OCTET STRING с фиксированной (т.е. ограниченной по размеру) длиной строки кодируется только соответствующим набором октет содержания.

Типы OCTET STRING переменной длины кодируются с полем длиной 16 бит (целое число без знака в дополнительном двоичном коде), за которым следует определенное число октет содержания.

Пример - Следующие определения

fixed-sized-label : : = OCTET STRING (SIZE(12) )

variable-label : : = OCTET STRING

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

typedefunsigned char fixed_size_label [12];

typedef struct {

unsigned short length;

unsigned chardata [1];/* здесь нужно вставить массив подходящего размера

*/

} variable_label;

А.4.5 Тип SEQUENCE

Кодирование значения последовательности конструируется, а октеты содержания представляют закодированные значения элементов типа SEQUENCE, без каких-либо дополнительных закодированных данных. Пробелы (например, для выравнивания) не добавляются.

Значения компонентов должны появляться в порядке их определения в типе SEQUENCE.

Пример - Следующие определения

IdentType : : = SEQUENCE {

id INT-U16,

instanceINT-U16

}

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

typedef struct {

unsigned shortid,

unsigned shortinstance

} IdentType;

и кодирование no MDER будет иметь вид, представленный на рисунке А.5.

Рисунок А.5 - Образец кодирования типа SEQUENCE

А.4.6 Тип SEQUENCE OF

Кодирование значения SEQUENCE OF конструируется, а октеты содержания представляют закодированные значения элементов типа SEQUENCE OF таким образом, чтобы ему предшествовало поле счетчика, указывающее на число элементов, и поле длины, указывающее полную длину структуры данных (в которой не учитываются сами счетчик и длина).

Кодирование должно сохранить порядок значений компонентов. См. рисунок А.6.

Рисунок А.6 - Кодирование типа SEQUENCE OF

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

Пример - Следующие описания:

Array1 : : = SEQUENCE OF Entry

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

typedef struct {

unsigned shortcount;

unsigned shortlength;

Entry data[1]; /* здесь нужно вставить достаточное число записей */

} Array1;

А.4.7 Тип CHOICE

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

Рисунок А.7 - Кодирование типа CHOICE

Пример - Следующие описания

ChoiceType : : = CHOICE {

one OneType,

two TwoType

}

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

typedef struct {

unsigned shortchoice_id;

unsigned shortlength;

union {

OneTypeone;

TwoTypetwo;

} data;

} ChoiceType;

#define one_type_chosen1

#define two_type_chosen2

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

- теги могут быть заданы явно или неявно;

- абстрактный синтаксис для неявно заданных тегов не содержит явно заданного номера выбора и, следовательно, требуется правило для присвоения значений полю choice_id. Для неявно заданных тегов значения поля choice_id начинаются со значения 1 и последовательно размещаются в порядке абстрактных синтаксических выборов. В приведенном выше примере значения поля choice_id для полей one_type_chosen и two_type_chosen будут равны 1 и 2 соответственно;

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

choice-type : : = CHOICE {

one [1] OneType, - - defines tag value 1 in MDER

four [4] FourType - - defines tag value 4 in MDER

}

A.4.8 Тип ANY DEFINED BY и Instance-of

ANY DEFINED BY (ASN.1 1988/90) или тип instance-of (ASN.1 1994) кодируется заголовком поля длины, чтобы задать число октет в кодировании выбранного значения, как представлено ниже. См. рисунок А.8.

Данные типы, как правило, представляют встроенные синтаксисы, посредством зарегистрированного идентификатора объекта. См. приложение Н для случаев совместимости.

Рисунок А.8 - Кодирование типа ANY DEFINED BY (Instance-of)

Пример - Следующие описания

TestType ::= SEQUENCE {

type - idOIDType,

value ANY DEFINED BY type-id

}

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

typedef struct {

OIDTypetype-id,

unsigned shortany_length;

char any_data;/* здесь нужно вставить закодированный тип данных*/

} TestType;

Данный пример показывает кодирование байтов последовательности SEQUENCE, содержащей идентификатор объекта, зависящий от контекста, и значение ANY DEFINED BY.

В предыдущем преобразовании поле type-id является идентификатором объекта, не зависящим от контекста. Приложение должно использовать поле идентификатора, чтобы привести поле any_data к правильному типу данных. Символьный тип данных для поля any_data, по существу, не несет значения и предоставляет только адрес поля. Следует отметить, что длина может быть 0, что означает, что поле any_data не существует.

Тип instance-of кодирует конструкцию TYPE-IDENTIFIER из ASN.1 и идентичен кодированию ANY DEFINED BY для обеспечения обратной совместимости (совместимости с предыдущими версиями).

А.5 Структура данных с плавающей точкой

Ограниченное подмножество ASN.1, которое может быть отображено с MDER, не содержит данных типа FLOAT.

Вместо этого в ИСО/ИИЭР 11073-10201 для чисел с плавающей точкой определяется универсальный тип данных FLOAT.

Тип FLOAT отображается как 32-битная структура, форматированная в соответствии с цифровым форматом медицинских приборов (MDNF).

MDNF - это 32-битное слово, содержащее 8-битную целочисленную экспоненту (показатель степени) со знаком, за которой следует 24-битная целочисленная величина со знаком. См. рисунок А.9.

Рисунок А.9 - Кодирование MDNF

Представленное число будет (величина)(10). И показатель степени, и величина представлены в двоичном дополнительном коде. Нормализация величины не обязательна.

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

Таблица А.2 - Специальные значения MDNF

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

- -128 показатель степени 127;

- -2(2-3) < величина +(2-3);

- NaN=+(2-1);

- NRes=-2(2);

- ±INIFNITY=±(2-2).

Ниже приведены определения числа значащих цифр для представления на дисплее:

- если показатель степени <0, то целочисленное значение показателя степени отображает число значащих цифр после запятой. См. примеры в таблице А.3;

Таблица А.3 - Примеры при показателе <0

- если показатель 0, то число значащих цифр после запятой равно нулю. См. примеры в таблице А.4.

Таблица А.4 - Примеры при показателе 0

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

Распределение идентификаторов

В.1 Введение

Настоящее приложение предусмотрено для составителей и разработчиков группы стандартов ИСО/ИИЭР 11073-20000 в качестве руководства для формирования идентификаторов объектов для стандартов ИСО/ИИЭР 11073 (определение и использование идентификаторов объектов см. в ИСО/МЭК 8824-2).

В.2 Основа распределения идентификаторов

Для простоты идентификаторы объектов, присвоенные в настоящем приложении, используют структурированную табличную форму, в которой каждый отступ соответствует ответвлению. См. рисунок В.1.

Корневой объект для идентификаторов объектов в настоящем документе:

Рисунок В.1 - Присвоение идентификаторов объектов. Корневой путь

Дуги ниже корневого объекта mdap-0 показаны на рисунке В.2.

_______________

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

Примечание - Дополнительные ответвления, определенные в стандарте ИИЭР 1073, опущены для краткости.

Рисунок В.2 - Распределение идентификаторов объекта. Конкретные стандартные расширения

В.3 Примеры получения идентификаторов

Настоящий подраздел демонстрирует получение нескольких идентификаторов объектов, используя определение, представленное на рисунке В.1.

Примеры

1 Контекст представления определяется как пара абстрактный синтаксис - синтаксис передачи, например:

- Абстрактный синтаксис:

nomem16 (device not otherwise specified [NOS] )

iso (1) member-body(2) US (840) ieee1073 (10004) mdap (2) version1 (1)

mdap-0(0) standardSpecificExt (0) modules (0) abstractSyntax (1) 1

- Синтаксис передачи: mderBigEndian

iso (1) member-body (2) US (840) ieee1073 (10004) mdap (2) version1 (1)

mdap-0(0) standardSpecificExt (0) modules (0) transferSyntax (2) 1

2 Контекст приложения, например,

- Контекст приложения: нормальный режим работы контроллера DCC

iso (1) member-body (2) US (840) ieee1073 (10004) mdap (2) version1 (1)

mdap-0(0) standardSpecificExt (0) modules (0) applicationContext (3) dcc (2) 1

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

Временная синхронизация

С.1 Цель

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

С.2 Область применения

Настоящий стандарт в текущий период не определяет метод для временной синхронизации между медицинскими приборами, что позволило бы обеспечить реализации на нижних уровнях (например, ИСО/ИИЭР 11073-30200, ИСО/ИИЭР 11073-30300) и объектно-ориентированную реализацию в профилях форматов, основанных на прикладном уровне (например, DIM).

С.3 Спецификация

Чтобы облегчить реализацию интероперабельности, профили приложений, применяющие SNTP, должны быть согласованы с соответствующими определениями в ИСО/ИИЭР 11073-30200, связанными с протоколами, и определениями в DIM, связанными с объектом clock (часы).

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

Динамическая модель

Общие определения можно найти в DIM. Настоящее приложение включает в себя дополнительную информацию.

В таблицах настоящего приложения представлена модель конечного автомата (FSM) в табличной форме. Таблица D.1 представляет FSM только для DCC агента, а таблица D.2 только для ВСС менеджера. В данных таблицах "только" означает, что ни одна из сторон не обеспечивает симметричные функциональные возможности взаимодействия клиент-сервер.

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

Таблица D.1 представляет таблицу переходов состояний для системы агента прибора (например, для инфузионной помпы). События, выделенные курсивом, являются внешними событиями (например, сгенерированными системой-менеджером). Другие события являются внутренними событиями. Например, если агент в состоянии Disconnected (Отсоединен) получает connect event (событие подключения), то затем он отправляет уведомление о начальной загрузке и меняет свое состояние на Unassociated (Неассоциированный).

Пустые поля в таблице D.1 означают, что событие не привело ни к каким действиям или изменениям состояния.

Таблица D.2 представляет таблицу перехода состояний хоста DCC, т.е. менеджера ВСС, (например, хоста инфузионной помпы).

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

Примечание - Специальное состояние горячего запуска (hot start), которое позволяет пропустить состояние Configuring (Настройка), еще не было определено и возможно будет добавлено в данные таблицы позже.

_______________

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

Таблица D.1 - Состояние только DCC агента

Таблица D.2 - Состояние только ВСС менеджера

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

Абстрактный синтаксис

Настоящее приложение определяет несколько специализаций абстрактного синтаксиса, а именно:

- расширения mOSI, относящиеся к сеансовому уровню и уровню представления (см. Е.1);

- модули языка ASN.1, относящиеся к удаленному функционированию приложения, а также к сервисам и протоколам общей управляющей информации (например, ROSE*, CMIP*) (см. Е.2);

- расширения абстрактного синтаксиса и синтаксиса передачи, относящиеся к языку MDDL и правилам MDER (см. Е.3);

- определения прокси MIB (см. Е.4).

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

a) воспроизведены синтаксисы ИСО и приведены шестнадцатеричные аннотации (дампы) строк октет. Несмотря на то, что данные определения слишком сложные для детального разъяснения, они упрощают реализацию, предоставляя более точную компиляцию отображений между абстрактным синтаксисом и синтаксисом передачи данных. Кодирование правил ИСО BER и правил MDER профиля MDAP рассматривается, основываясь на контексте представления данных, в частности ИСО ACSE/BER и ИСО/ИИЭР 11073 MDDL/MDER;

b) для соответствия определениям прикладного уровня расширения сеансового уровня и уровня представления могут быть определены в раздельных модулях ASN.1 (в Е.1.1 и Е.1.2).

Е.1 Расширения mOSI

Расширения профиля MDAP, ориентированные на стандарт, принадлежат к модификациям сеансового уровня и уровня представления mOSI, которые были оптимизированы для использования в медицинских приборах.

Е.1.1 Сеансовый уровень

Полную спецификацию требований mOSI к устройствам сеансового уровня можно найти в ИСО/МЭК ISP 11188-3.

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

Базовая конкатенация означает, что сеансовый уровень соединяет только один блок SPDU Категории 0 с одним блоком SPDU Класса 2 (в отличие от расширенных конкатенаций, которые могут содержать в себе множественные блоки данных SPDU Категории 2).

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

Используются следующие сокращения (в соответствии с ИСО/МЭК 8327-1):

- LI: индикатор длины (длина 0-254: один октет, иначе 3 октета, начиная с 255);

- PGI: идентификатор группы параметров (определяет группу параметров сеансового уровня);

- PI: идентификатор параметров (определяет один параметр сеансового уровня);

- SI: идентификатор блока SPDU (уникальный идентификатор, который определяет тип сообщения сеансового уровня).

Е.1.1.1 Подключение сеансового уровня (Connect - CN) SPDU

Ниже представлен формат и содержание блока CN SPDU:

Обычно данный блок SPDU содержит сообщение о представлении соединения (см. Е.1.2.1), которое, в свою очередь, содержит запрос ассоциации элемента ACSE (см. Е.1.3.1).

Е.1.1.2 Приемка сеансового уровня (Accept - AC) SPDU

Ниже представлен формат и содержание блока AC SPDU:

Обычно данный блок AC SPDU содержит сообщение о представлении соединения (см. Е.1.2.2), которое, в свою очередь, содержит запрос ассоциации элемента ACSE (см. Е.1.3.1).

Е.1.1.3 Отказа сеансового уровня (Refuse - RF) SPDU

Ниже представлен формат и содержание блока RF SPDU:

Блок данных RF SPDU используется в качестве ответа в случае использования не поддерживаемых опций сеанса или поврежденных данных заголовка сеанса (в профиле MDPA используется только такой одиночный блок данных SPDU отказа).

Е.1.1.4 Окончание сеансового уровня (Finish - FN) SPDU

Ниже представлен формат и содержание блока FN SPDU:

Как правило, данный блок FN SPDU содержит обычное значение данных уровня представления (PDV), которое, в свою очередь, содержит запрос на разъединение связи ACSE (см. Е.1.3.1). См. пример на рисунке F.3.

Е.1.1.5 Отключение сеансового уровня (Disconnect - DN) SPDU

Ниже представлен формат и содержание блока DN SPDU:

Обычно данный блок DN SPDU содержит обычное значение PDV, которое в свою очередь содержит запрос освобождения ассоциации элемента ACSE (см. Е.1.3.1). См. пример на рисунке F.4.

Е.1.1.6 Передача данных сеансового уровня (Data Transfer - DT) SPDU

Ниже представлен формат и содержание блока DT SPDU:

Передача данных - это блок SPDU Категории 2, которому должен предшествовать блок SPDU Категории 0 (token give (маркер передача), который имеет такое же значение поля SI). Поля LI указывают на то, что нет никаких параметров (например, поля PGI, PI). Информация пользователя просто добавляется к настоящему сообщению.

Блок данных DT SPDU содержит

a) TD PPDU или

b) MDAP-TD PPDU.

Е.1.1.7 Прекращение сеансового уровня (Abort - AB) SPDU

Существуют две основные формы блока АВ SPDU. Первая - в сообщении нет данных пользователя (см. 8.3.9.3 в ИСО/МЭК 8327-1):

Вторая форма используется, когда предоставляется информация пользователя:

Блок данных АВ SPDU второй формы может содержать одно из следующего:

а) аварийное разъединение связи по инициативе поставщика услуг (ARP) PPDU без данных пользователя;

b) аварийное разъединение по инициативе пользователя (ARU) PPDU, которое содержит аварийное прекращение работы (ABRT) APDU;

c) пустые данные пользователя, в данном случае длина будет равна нулю (например, 0хС1 0x00).

Так как настоящий стандарт не определяет данные о преждевременном прекращении по инициативе пользователя в языке MDDL, информация, содержащаяся PPDU ARP или PPDU ARU, несет минимальную значимость для получателя АВ SPDU. Поэтому первая форма только для сессии предпочитает формат АВ SPDU.

Независимо от того какая форма используется (т.е. с использованием данных пользователя или без них), получения АВ SPDU (SI = 25) будет достаточно для прекращения сеанса.

Е.1.1.8 Приемка прекращения сеансового уровня (Abort Accept - АА) SPDU

Блок АА SPDU не используется.

Е.1.1.9 Расширения сеансового уровня MDAP

MDAP устанавливает дополнительные службы сеансового уровня. Цель использования расширения сеансового уровня заключается в обеспечении простого и эффективного демультипексирования* (распределения каналов) стандартных (mOSI) и нестандартных блоков данных (MDAP) PPDU. В данном случае демультиплексирование возможно посредством единичного бита, и что еще более важно, в заголовке представления можно не указывать правила кодирования BER, которые потребовали бы наличия поля переменной длины.

_______________

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

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

Е.1.1.9.1 Элементы соединения/приемки сеанса профиля MDAP

Использование расширений сеансового уровня профиля MDAP согласовывается во время установления соединения сеанса. В элементе соединения/приемки определяются два дополнительных поля PI:

_______________

Метод согласования определяется для каждого используемого прикладного профиля. Однако в большинстве случаев система менеджера может указывать на наличие у нее поддержки объединения. Если система агента также указывает на то, что она поддерживает объединение, сообщая об этом в своем ответе на запрос ассоциации, то объединение запускается. Менеджер и агент указывают период сброса на диск (flush period), который будет применяться, независимо друг от друга. См. Е. 1.1.9.3.

Ниже приведен пример CN SPDU:

Е.1.1.9.2 SPDU передачи данных профиля MDAP

Расширение сеансового уровня профиля MDPA определяет дополнительные поля SI для передачи обычных и срочных данных. Ниже приведены варианты формата этих полей:

- SPDU передачи нормальных данных MDPA (MDAP-DT)

- блок SPDU передачи срочных данных MDPA (MDAP- XT)

Данные сообщения содержат сообщение с представлением профиля MDAP и передаются в расширение уровня представления профиля MDAP вместо нормального уровня представления. Поля PGI и PI не задаются и, следовательно, поле LI равно 0. Эти сообщения определяются как блоки данных SPDU Категории 1, не требующие маркера передача (подобно типизированным данным при обычном сеансе).

Данные пользователя просто прикрепляются к этим сообщениям и содержат PDV профиля MDAP (MDAP-PPDU), которое рассматривается как значения PDU протокола CMIP*/элемента ROSE*.

Е.1.1.9.3 Объединение сеанса профиля MDAP

Чтобы уменьшить общее количество сообщений профиля MDAP, сеансовый уровень профиля MDAP поддерживает объединение, при котором множество PPDU MDAP-DT объединяется и отправляется в одном SPDU. Если размер буфера превысит MTU (максимальный передаваемый блок данных), то буфер SPDU отправляется (передается на нижние уровни) со следующей частью MDAP-DT или спустя определенное количество времени, соответствующее периоду сбрасывания на диск, которое можно установить во время выполнения подключения сеанса.

Если множество PPDU MDAP-DT объединяются, то к компонентам необходимо добавить поля длины такие, чтобы сеансовый уровень мог разделить их на отдельные части (демультиплексировать). Для этого используется поле LI, которое указывает на общую длину блока данных SPDU. В соответствии с ИСО/МЭК 8327-1, используется поле LI длиной в 3 октета с 0xFF в качестве первого октета для кодирования длины в диапазоне 255-65535. Расширение сеансового уровня профиля MDAP использует эту форму представления длины для кодирования длины в диапазоне 0-65535. С учетом этого, начальный октет идентификатора длины LI блока данных SPDU можно использовать для обозначения того, имеет ли блок SPDU один или множество блоков PPDU (обычно это 0x00; 0xFF указывает на объединенные PPDU).

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

_______________

См. Е.1.1.9.

Поэтому SPDU с тремя встроенными PPDU будет иметь следующую структуру:

Использование объединения увеличивает задержку сообщения, но благодаря этому уменьшается расход пропускной способности (меньшее количество блоков PDU).

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

Е.1.2 Уровень представления

Как и в случае с протоколом сеансового уровня, у уровня представления профиля MDAP имеется два разных элемента или части. Элемент mOSI обеспечивает стандартное представление базовых и дуплексных функциональных блоков.

Элемент представления профиля MDAP, который должен рассматриваться как расширение обычного протокола уровня представления, можно использовать только для нормальных данных пользователя. Он принимает данные от сеансового элемента профиля MDAP и отправляет данные в сеансовый элемент MDAP. Он не работает со стандартным сеансовым элементом mOSI.

Полную спецификацию требований mOSI для обеспечения уровня представления можно найти в приложении В ИСО/МЭК ISP 11188-3. Как было уже отмечено, уровень представления поддерживает только базовые и дуплексные функциональные блоки.

Поддерживаемые блоки данных PPDU определяются в Е.1.2.1-Е.1.2.7. Описания блоков PPDU, указанные здесь, являются не полными. Они предназначены лишь для того, чтобы дать представление об основном содержании блоков PDU. Полные определения можно найти в ИСО/МЭК 8327-1. Поддерживаемые опции соответствуют ИСО/МЭК МФС 11188-3. Блоки PPDU кодированы согласно BER, даже если само поле данных пользователя не закодировано согласно BER. Примеры закодированных блоков PPDU можно найти в приложении F.

Е.1.2.1 Подключение уровня представления (Connection Presentation - СР) PPDU

Блок СР PPDU определяется следующим образом:

Данный блок PPDU содержит сообщение запроса ассоциации в виде данных пользователя (см. Е.1.3.1). Оно содержится в блоке CN SPDU (см. Е.1.1.1).

Список определения контекста уровня представления (см. Е.1.2.8) определяет кортежи абстрактного синтаксиса (например, MDAP) и синтаксис передачи (например, синтаксис передачи MDAP с обратным порядком байтов), идентифицированные как объектные идентификаторы, и назначает идентификатор контекста представления (целое число) для каждой из данных комбинаций. Данный идентификатор состоит максимум из 16 бит.

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

Дополнительные (необязательные) данные пользователя контекста уровня представления (см. Е.1.2.8) определяют контекст приложения с сообщением запроса ACSE (см. AARQ-apdu в Е.1.3.1). В свою очередь, AARQ-apdu содержит ассоциативные сведения о пользователе (см. MDSEUserlnfo в Е.2.3).

Е.1.2.2 Принятие подключения уровня представления (Connect Presentation Accept - СРА) PPDU

Блок СРА PPDU определяется следующим образом:

Настоящий блок данных PPDU содержит (положительное) сообщение association response в виде данных пользователя (см. Е.1.2.8). Он содержится в AC SPDU (см. Е.1.1.2).

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

Список результатов контекста представления данных должен принимать контекст ACSE и MDAP. Для контекста MDAP должен быть выбрать* один синтаксис передачи.

_______________

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

После этого в ассоциации определяются два контекста представления данных. Другими словами существуют только два действительных идентификатора p-context (контекста представления данных). (Эти два контекста определяют контекстный набор, определенный представлением).

Е.1.2.3 Отклонение подключения уровня представления (Connect Presentation Reject - CPR) PPDU

Блок CPR PPDU определяется следующим образом:

Настоящий блок данных PPDU содержит ответное сообщение с отклонением ассоциации в виде данных пользователя, а именно AARE с полем результатов, установленным как rejected-permanent (окончательное отклонение) или rejected-transient (временное отклонение). Он содержится в блоке AC SPDU (несмотря на то, что он не участвует в принятии подключения).

Е.1.2.4 Протокол аварийного разъединения по инициативе провайдера (ARP PPDU)

ARP PPDU не содержит данные пользователя. Они содержатся в блоке АВ SPDU.

ARP PPDU посылается в случае получения неверно сформированного PPDU по одной из следующих причин:

a) PPDU содержит недопустимое значение параметра PPDU;

b) PPDU содержит непредусмотренный параметр PPDU;

c) PPDU включает в себя непредусмотренный идентификатор контекста представления данных;

d) значение PDV не допустимо.

Е.1.2.5 Протокол аварийного разъединения по инициативе пользователя (ARU PPDU)

ARU PPDU содержит сообщение аварийного прекращения ассоциации в виде данных пользователя. Он содержится в SPDU АВ.

ARU PPDU посылается, когда приложение требует аварийного разъединения контекста представления данных.

Е.1.2.6 Представление данных (TD) PPDU

TD PPDU определяется следующим образом:

TD-PPDU : : = User-data

Настоящий блок PPDU содержит сообщение user data PDV. Он содержится в DT SPDU. Для определения типов данных пользователя см. Е.1.2.8.

Примечание - TD PPDU определяется как часть данного профиля, так как он требуется для минимального уровня представления OSI (ИСО/МЭК ISP 11188-3). Тем не менее, предполагается, что все данные медицинских приборов будут использовать службу расширения уровня представления MDAP-TD. На данный момент не были установлены определенные области применения для TD PPDU.

Е.1.2.7 MDAP-TD (представление данных для расширения уровня представления MDAP)

Расширение уровня представления определяет один дополнительный тип блока PPDU следующим образом:

MDAP-PPDU кодируется с помощью MDER, но не BER.

Идентификатор контекста представления данных является 16-битным (тип "big endian") целым числом. Само значение идентификатора определяется в СР PPDU.

Поле данных пользователя является непрозрачным. Нет конкретной структуры данных (например, нет поля длины). Тем не менее, содержанием обычно является блок APDU ROSE*, который в свою очередь размещает в себе блок АРDU протокола CMIP* (см. Е.2.1).

Например, начальная часть неподтвержденного отчета о событии будет представлена в MDER следующим образом:

MDAP-PPDU может содержать только одно значение PDV. Оно содержится в блоке SPDU MDAP-DT и включает приложение MDAP (ROSE* PDU) в качестве данных пользователя.

Расширение уровня представления MDAP согласовывается во время выполнения presentation connect. Версия протокола должна быть явно указана как version-mdap (15).

Е.1.2.8 Определения типа данных пользователя уровня представления.

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

Определения PDU требуют дополнительные типы данных, указанные ниже:

E.1.3 Приложение

E.1.3.1 Ассоциация

Ассоциация использует только обязательные поля и данные пользователя, полученные из определений ASN.1 ITU-T Рекомендации Х.227.

E.2 Модули ASN.1

Модули ASN.1, ориентированные на MDAP, относятся к данным пользователя ассоциации и протоколу удаленной операции, а также протоколу CMIP, а именно к ROSE* и CMIP*.

_______________

Scope (область применения) - это диапазон объектов, к которым применяется операция, например, единичный объект или набор объектов, содержащийся в единичном объекте. О дополнительных технических характеристиках см. Е.2.2.

Указанные ниже определения используются для различных полей-идентификаторов в сообщении:

E.2.1.1 Отличия от ROSE ИСО/МЭК

Данные определения в настоящем стандарте имеют следующие отличия от ИСО/МЭК 9072-2:

- Invoke APDU: поле Invoke APDU в ИСО/МЭК 9072-2 содержит дополнительное поле связанного идентификатора, которое используется для механизма связанного ответа. Для элемента CMISE (и CMISE*) данный механизм используется только, если во время ассоциации выбирается функциональный блок множественного ответа (не обязательная опция) (см. 7.2.3, а определения полей ассоциации пользователя MDSE в ИСО/МЭК 9595).

- Правила кодирования языка MDDL не допускают применение дополнительных элементов. Поэтому был определен дополнительный (нестандартный) связанный вызов блока APDU;

- Result APDU: SEQUNECE (последовательность), которая содержит значение операции и поле результата, не являются дополнительными в настоящем стандарте. CMIP требует наличия этих полей в своих сообщениях-ответах;

- Reject APDU: по сравнению со стандартным элементом ROSE Reject APDU в настоящем стандарте более простой. Его структура такая же, как и у других блоков APDU.

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

- Linked invoke APDU: Linked invoke APDU используется, когда ответ на вызов операции приводит к образованию множественных сообщений-ответов. ИСО/МЭК ROSE использует нормальный invoke APDU со связанным полем идентификатора, установленным вместо этого специального блока APDU. Другими словами ИСО/МЭК ROSE не требует Linked invoke APDU.

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

- InvokelDType, OPERATION, ERROR: данные типы отображаются на ограниченные целые типы (вместо отображения на неограниченный целый тип для идентификатора вызова или на выбор между идентификатором объекта и неограниченным целым типом для других типов).

Таким образом, основным отличием от стандартного протокола ROSE является наличие необязательных элементов, которые либо присутствуют либо отсутствуют в определении ROSE*, в зависимости от того, используются или не используются они протоколом CMIP*. Определение операции (operation) и ошибки (error) упрощены согласно способу их использования протоколом CMIP*. Определен новый блок данных APDU для взаимодействия со связанными ответами.

В настоящем стандарте отсутствуют нестандартные поля, что является результатом адаптации ROSE для конкретных целей РОС MDC.

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

Е.2.1.2 Поля сообщения ROSE*

Объяснение полей в блоках данных APDU элемента ROSE дано в Е.2.1.2.1-Е.2.1.2.5.

Е.2.1.2.1 Поле Invoke identifier (идентификатор вызова)

Поле идентификатора вызова - это числовое поле, которое идентифицирует сообщение со стороны отправителя. Если, к примеру, клиент отправляет сообщение-вызов на сервер, то сервер помещает данный идентификатор вызова в получившееся сообщение (например, в результат GET или подтверждение Event Report). Данный механизм позволяет клиенту соотнести ответ с его запросом. (Идентификатор вызова дублируется обратно клиенту в сообщении-ответе.)

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

Другими словами для реализации процесс получения или процедура получения может быть зарегистрирована в компоненте АЕ языка MDDL на вызываемом клиенте, как только придет сообщение-ответ.

Е.2.1.2.2. Поле Linked identifier (связанный идентификатор)

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

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

Е.2.1.2.3 Поле Operation value (значение операции)

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

Е.2.1.2.4 Поле Error value (значение ошибки)

Как и значение операции, числовые значения устанавливаются для определенных условий ошибок. Допустимые значения ошибок для языка MDDL определены в CMIP*. Необходимо отметить, что значение ошибки не является значением операции.

Примечание - Требуется некоторое разъяснение. Рассмотрим команду GET протокола CMIP* в качестве примера. Предположим, что поле класса управляемого объекта в данном сообщении неправильное, тогда APDU ошибки удаленной операции (remote operation error, ROER) отправляется обратно, а значение ошибки это noSuchObjectClass. Другими словами блок APDU не передает информацию, которая бы указывала на то, что он поступил в ответ на запрос GET. Данную информацию можно извлечь при изучении идентификатора вызова, который является ссылкой на исходное сообщение-запрос GET: отсюда следует требование, чтобы (активные) идентификаторы вызова в системе были уникальными.

Е.2.1.2.5 Поле Argument (аргумент)

Удаленный вызов операции можно рассматривать как (удаленный) вызов процедуры. Аргументы, которые передаются процедуре, просто прикрепляются к сообщению элемента ROSE*. В языке MDDL блоки PDU протокола CMIP* являются аргументами сообщений ROSE*.

Е.2.1.3 Обработка связанных ответов

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

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

- для всех сообщений-ответов, кроме самого последнего:

- используется вызов линии передачи удаленной операции (ROLIV) APDU;

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

- поле связанного идентификатора имеет значение поля идентификатора вызова запроса;

- для самого последнего сообщения:

- используется APDU remote operation result (RORS);

- поле идентификатора вызова в данном ответе имеет значение поля идентификатора вызова запроса.

Примечание - Если необходимы два сообщения в ответе, первое - это APDU ROLIV с последним битом вызова с установленным значением 1 и со счетчиком, установленным на 1;

- для ROLIV APDU поле идентификатора вызова имеет следующую семантику:

С помощью этого определения можно обнаружить недостающие части полного набора сообщений-ответов.

Е.2.2 CMIP*

Также как и в случае с ROSE*, CMISE* является частью прикладного уровня. CMISE предоставляет услуги управления объектами, которые обеспечивают доступ к значениям атрибутов, функциям вызова объектов и т.д. Ассоциированный протокол (CMIP) определяет сообщения прикладного уровня (блоки APDU), которые инициируют работу данных служб. Для выполнения своих функций CMISE располагается на уровне, расположенном поверх ROSE.

Поэтому сообщения протокола CMIP обычно задаются посредством ASN.1 макросов ROSE (ИСО/МЭК 9596-1). Для облегчения понимания в настоящем подразделе не используется нотация макрокоманд (макросов) ROSE. Используемые в настоящем пункте определения ASN.1 можно рассматривать как макрорасширения. Однако, как было уже разъяснено, определения сообщений здесь не полностью соответствуют стандартному протоколу CMIP. Несмотря на то, что все поля данных, отправляемые в блоках APDU протокола CMIP*, существуют также в стандартном протоколе CMIP, для упрощения определений типы данных были изменены.

Сообщение протокола CMIP* (более точно: структура данных аргумента операции протокола CMIP*) просто присоединяют в качестве поля аргумента к блоку данных APDU элемента ROSE*. Поле значения операции ROSE* должно быть для определения типа присоединенного аргумента.

В таблице Е.1 показаны, какие типы аргументов (типы сообщений) определяются или используются в протоколе CMIP*.

- Тип данных вызова добавляется к APDU вызова удаленной операции (ROIV).

- Тип данных ответа прилагается к APDU RORS.

- Сообщения об ошибке в APDUS ROER обрабатываются по-разному.

Таблица Е.1 - Типы аргумента протокола CMIP*

Значения операции соответствуют ИСО/МЭК 9596-1.

Значение операции в таблице Е.1 является значением, которое присваивается полю значения операции в блоках данных APDU вызова и ответа ROSE*. (В данном случае не требуется операция связанного ответа.)

Если, к примеру, хост-система требует значение атрибута какого-либо объекта из сервера, то она отправляет APDU ROIV элемента ROSE* со значением операции 3 и присоединенный к нему GetArgument. Сервер отвечает блоком RORS APDU со значением операции 3 и присоединенным GetResult. Поэтому и тип PDU элемента ROSE* и значение операции требуются для определения типа присоединенных данных (т.е. типа сообщения CMIP*).

В случае возникновения ошибки в качестве ответа высылается PDU ROER элемента ROSE*, а поле значения ошибки содержит код ошибки (см. определения ниже). Дополнительно, если длина поля ANY DEFINED BY>0, то предоставляется дополнительная информация.

Все сообщения-ответы и сообщения-вызовы (сообщения об ошибке) протокола CMIP* определены ниже в данном пункте. Определения взяты из ИСО/МЭК 9596-1 с объяснением различий.

Типы данных, которые присоединяются к блоку данных APDU элемента ROSE* (т.е. блоку вызова, результата или ошибки), в следующих определениях ASN.1 выделены жирным шрифтом:

_______________

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

E.2.3 Ассоциированные сведения о пользователе

Информация о пользователе присоединяется к сообщениям с запросами и ответами на ассоциации. В случае MDSE определение этих полей пользователя имеет минимальный размер по причине сложности кодирования и обработки сообщений ACSE. Необходимо отметить, что поля пользователя в MDSE закодированы в согласованном синтаксисе передачи (MDER), а не в BER.

Информация о пользователе для MDSE определяются следующим образом (в виде модуля ASN.1):

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

Примечания

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

2 Версия номенклатуры здесь требует изменения только в том случае, если какие-либо номенклатурные коды, которые используются в поле информации о пользователе или в исходном сообщении MDS create event, были модифицированы. Другие версии (незначительные изменения версии) кодируются в соответствующем атрибуте объекта MDS.

3 Данная информация о пользователе сервисного элемента ACSE ссылается на контекст представления MDER, заданный в определении контекста представления данных и на список результатов сообщений ACSE. Поле информации о пользователе не использует правила BER.

4 Идентификаторы атрибутов в структурах списков optionList и supportedAProfiles определены в таблице номенклатуры элементов инфраструктуры.

Е.3 Расширения абстрактного синтаксиса

Большинство абстрактных синтаксисов, специфичных для медицинских приборов, определено в MDDL объектно-ориентированной модели DIM. По традиции, классы объекта, атрибуты, группы атрибутов, уведомления, действия и другие номенклатуры определяются в общей номенклатуре языка MDDL (ИСО/ИИЭР 11073-10101).

Тем не менее, идентификация контекста представления управления ассоциацией ИСО требует одного идентификатора объекта для отображения абстрактного синтаксиса. В результате в языке MDDL выделяются расширения для идентификатора объекта MDAP для абстрактного синтаксиса, в частности 16-битные зависящие от контекста и 32-битные контекстно-независимые разделы.

Е.4 Определения базы MIB

В состав определений базы MIB входят расширения идентификаторов объектов и абстрактный синтаксис, представляющий содержание информации.

Идентификаторы объектов для расширений MIB выделяются из asn1Modules(2) mib(4), как указано на рисунке В.2. Затем номенклатура присоединяется к ребру mib(4), согласно определению в Таблицах коммуникационной инфраструктуры номенклатуры стандарта ИСО/ИИЭР 11073-10101.

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

Примеры блоков PDU

Настоящее приложение дает представление о блоках PDU с учетом абстрактного и конкретного синтаксиса (кодирования) для облегчения понимания и реализации.

Первые примеры представляют блоки PDU стадии ассоциации ИСО, которые основаны на языке ASN.1 и правилах BER (см. F.1). Дополнительные примеры показывают блоки PDU стадии конфигурации и функционирования (см. F.2 и F.3, соответственно). Подробные данные по абстрактному синтаксису содержатся в модели DIM, а информация о правилах кодирования (MDER) в приложении А.

В настоящем приложении используются два типа форматов блоков PDU:

- первый формат обеспечивает декомпозицию абстрактного синтаксиса, связанное с ней кодирование (шестнадцатеричный формат) и соответствующие примечания. Пример данного формата см. на рисунках F.1-F.5;

- второй формат для краткости не сопровождается абстрактным синтаксисом, но просто предоставляет кодирование с примечаниями. В подобных случаях для получения подробной информации по абстрактному синтаксису см. модель DIM. Пример данного формата см. на рисунках F.6-F.7, на которых показаны примеры блоков PDU object create notification event report и create notification event report response соответственно.

Примеры были переняты из проектов демонстрации медицинских вентиляционных и инфузионных приборов. Насколько это практически возможно, значения полей являются точными, хотя некоторые погрешности и необходимы для представления информации в данном формате. В частности, показаны ответвления ИСО/ИИЭР 11073, основанные на списке в приложении В, но шестнадцатеричные списки не показаны.

F.1 Ассоциация

В число примеров ассоциаций входят запрос и ответ ассоциации (см. рисунки F.1 и F.2, соответственно), запрос на разъединение и ответ на разъединение ассоциации (см. рисунки F.3 и F.4, соответственно) и прекращение ассоциации (см. рисунок F.5).

F.2 Настройка

Примеры включают в себя отчет о событии уведомления создания объекта системы MDS и ответ на данный отчет (см. рисунки F.6 и F.7, соответственно).

F.3 Операция

Примеры включают в себя периодический отчет о сканере событий и буферизированный отчет о сканере событий (см. рисунки F.8 и F.9 соответственно).

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

Рисунок F.1 - Пример форматирования запроса ассоциации (Association request)

Рисунок F.1, лист 2

Рисунок F.1, лист 3

Рисунок F.2 - Пример форматирования ответа ассоциации (Association response)

Рисунок F.2, лист 2

Рисунок F.2, лист 3

Рисунок F.3 - Пример форматирования запроса на разъединение ассоциации (Association release request)

Рисунок F.4 - Пример форматирования ответа на разъединение ассоциации (Association release response)

Рисунок F.5 - Пример форматирования прекращения ассоциации (Association abort)

Рисунок F.6 - Пример форматирования отчета о событии уведомления о создании объекта системы MDS (MDS object create notification event report)

Рисунок F.7 - Пример форматирования ответа на отчет о событии уведомления о создании объекта системы MDS (MDS object create notification event report response)

Рисунок F.8 - Пример форматирования отчета о конфигурируемом периодическом сканере событий (Configured periodic scanner event report)

Рисунок F.9 - Пример форматирования отчета о периодическом сканере, буферизирующего просматриваемые события (Periodic scanner buffered scan event report)

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

Специализация ASN.1

G.1 Введение

ASN.1 - это стандартная нотация, которая используется для определения типов данных, значений и ограничений на значения. Данная нотация широко используется в стандартах OSI. Нотация также является ключевым компонентом DIM и семейства ИСО/ИИЭР 11073-10300 стандартов по специализации приборов.

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

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

G.2 Специализация ASN.1

Для каждого типа данных языка ASN.1 данная специализация сопровождается символом "I" для включения с ограничениями, "R" для ограничений по использованию или "Е" для исключения.

Специализация типов данных языка ASN.1 дана в таблице G.1. См. приложение А для связей с кодированием MDER.

Таблица G.1 - Специализация типов данных языка ASN.1

Таблица G.2 - Поддерживаемые типы integer, bitstring и float

Ниже кратко описаны элементы таблицы G.1:

- BOOLEAN (логическое значение): тип BOOLEAN не является частью специализации языка ASN.1;

- INTEGER (целочисленная переменная): тип ASN.1 INTEGER не является частью специализации ASN.1. Вместо этого в MDER предлагается кодирование для типов INTEGER, представленное в таблице G.2. Эти типы следуют синтаксису, показанному в таблице;

- ENUMERATED (перечисление): тип ASN.1 ENUMERATED не является частью специализации языка ASN.1, в MDER предлагается кодирование для типов INTEGER, представленное в таблице G.2. Эти типы INTEGER можно использовать с NamedNumberList, который является аналогичным типу ENUMERATED;

- REAL (реальный): тип ASN.1 REAL не является частью специализации языка ASN.1. Вместо этого, в MDER предлагается кодирование для FLOAT-Type, которое является 32-битным типом с плавающей точкой. Данный тип есть в таблице G.2;

- BITSTRING (битовая строка): тип BIT STRING не является частью специализации языка ASN.1. Вместо этого, в MDER предлагается кодирование для типов BIT STRING, которое является 32-битным типом с плавающей запятой. Данный тип представлен в таблице G.2;

- OCTETSTRING (строка октет): тип OCTET STRING является частью специализации языка ASN.1. Нет ограничений по его использованию;

- NULL (ноль): нулевой базисный элемент обычно исключают из правил MDER, но включают с ограничениями в примитивы CHOICE и ANY DEFINED BY в MDER;

- SEQUENCE (последовательность): тип SEQUENCE является частью специализации языка ASN.1 с определенными ограничениями. Компонент SEQUENCE может не определяться вместе с ключевыми словами OPTIONAL, DEFAULT или COMPONENTS OF. Автоматическое тегирование не поддерживается;

- SEQUENCE OF (последовательность ч-л.): тип SEQUENCE OF является частью специализации языка ASN.1. Нет ограничений по его использованию;

- SET (набор инструкций): тип SET не является частью специализации языка ASN.1. Тип SEQUENCE является его рекомендуемой заменой;

- SET OF (набор инструкций ч-л.): тип SET OF не является частью специализации языка ASN.1. Тип SEQUENCE OF является его рекомендуемой заменой;

- CHOICE (выбор): тип CHOICE является частью специализации языка ASN.1 с определенными ограничениями. Каждая альтернатива в CHOICE должна быть типом TAGGED. Автоматически теги не поддерживаются;

- SELECTION (выбор): оператор типа SELECTION не является частью специализации языка ASN.1;

- TAGGED (тегированный): в общем, типы TAGGED не являются частью специализации языка ASN.1. Однако каждый альтернативный тип CHOICE должен быть типом TAGGED;

- OBJECT IDENTIFIER (идентификатор объекта): тип OBJECT IDENTIFIER не является частью специализации языка ASN.1;

- EMBEDDED PDV (встроенное PDV): тип EMBEDDED PDV не является частью специализации языка ASN. 1;

- EXTERNAL (внешний объект): тип EXTERNAL не является частью специализации языка ASN.1;

- CHARACTER STRING (строка символов): типы CHARACTER STRING не являются частью специализации языка ASN.1. Вместо этого рекомендуется использовать тип OCTETSTRING;

- ANY DEFINED BY (любое значение, определенное с помощью): тип ANY DEFINED BY является частью специализации языка ASN.1. ANY DEFINED BY должен определять компонент, содержащей его SEQUENCE. Этот компонент должен быть OBJECT IDENTIFIER (номенклатура). OBJECT IDENTIFIER может быть контекстно-независимым или контекстно-зависимым. В приложении Н дано больше информации об использовании ANY DEFINED BY.

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

Вопросы совместимости

Настоящее приложение представляет информацию для логического обоснования вопросов и решений совместимости.

Н.1 Тип ANY DEFINED BY

Изменения в языке ИСО ASN.1 и связанных с ним правилах кодирования (например, правила BER), произошедшие между версиями 1988/90 и 1994, привели к определенным изменениям в синтаксисе определения ANY DEFINED BY (версия 1988/90). Указанные ниже пункты являются выдержками из соответствующих документов ИСО, затрагивающих эти изменения. См. основной текст стандарта для получения информации по нормативным спецификациям, связанным с влиянием на MDAP.

Н.1.1 Переход к текущей нотации языка ASN.1

Ниже дана выдержка из приложения А стандарта ИСО/МЭК 8824-1:1994:

"А.3 Переход к текущей нотации ASN.1

При модификации модуля (изначально написанного согласно нотации ASN.1-88/90) с целью приведения его в соответствие с текущей нотацией необходимо учесть следующее:

…

b) Все применения ANY и ANY DEFINED BY должны поддерживаться соответствующим определением класса информационного объекта (information object class definition), в котором ANY и ANY DEFINED BY (и компонент, на который делается ссылка) заменяются на соответствующие ссылки на поля этого класса объектов. В большинстве случаев спецификацию можно в значительной степени улучшить, если уделять должное внимание включению таблиц и ограничений на отношения компонента. Во многих случаях спецификацию можно еще улучшить, если таблицы или ограничение на отношения компонента выполнены в виде параметра данного типа."

Н.1.2 Класс информационного объекта TYPE-IDENTIFER в языке ASN.1

Ниже дана выдержка из приложения А ИСО/МЭК 8824-2:1994:

"А.1 Настоящее приложение описывает класс объектов полезной информации со ссылочным описанием класса TYPE-IDENTIFIER (Идентификатор типа).

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

А.2 Класс информационного объекта TYPE-IDENTIFIER определяется следующим образом:

TYPE-IDENTIFIER : : = CLASS

{

&id OBJECT IDENTIFIER UNIQUE,

&Type

}

WITH SYNTAX {&Type IDENTIFIED BY &id}

А.3 Данный класс определяется как класс "полезного" информационного объекта и присутствует в каждом модуле, без необходимости его импортировать.

А.4 Пример

Тело коммуникации MHS можно определить следующим образом:

MHS-BODY-CLASS : : = TYPE-IDENTIFIER

g4FaxBody MHS-BODY-CLASS : : =

{BIT STRING IDENTIFIED BY {mhsbody 3}}

Проектировщик протокола, как правило, определяет компонент для переноса MHS-BODY-CLASS путем указания типа "INSTANCE OF MHS-BODY-CLASS", определенного в С.9."

Н.1.3 Кодирование типа instance-of в BER

Ниже дана выдержка из стандарта ИСО/МЭК 8825-1:1994:

"8.16 Кодирование значения instance-of

8.16.1 Кодирование значения instance-of должно быть кодированием BER следующего типа последовательности со значением, указанным в 8.16.2:

[UNIVERSAL 8] IMPLICIT SEQUENCE

{

type-id <DefinedObjectClass>.&id,

value [0] EXPLICIT <DefinedObjectClass>.&Type

},

где "<DefinedObjectClass>" заменен определенным "DefinedObjectClass", используемым в нотации "InstanсеOfTуре".

Примечание - Когда значение является значением одного типа ASN.1, и для этого значения применяется кодирование BER, то кодирование данного типа идентично кодированию соответствующего значения внешнего типа, где для представления абстрактного значения используется альтернатива "синтаксиса".

8.16.2 Значение компонентов типа последовательности в 8.16.1 должно быть таким же, как и значения соответствующих компонентов ассоциированного типа в МСЭ-Т Рек. Х.681 или ИСО/МЭК 8824-2, С.7."

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

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

Таблица ДА.1

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

Электронный текст документа

и сверен по:

, 2016