1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 11 октября 2022 в 15:57
Снять ограничение

ГОСТ Р 56845-2015

Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена
Недействующий стандарт
Проверено:  03.10.2022
Заменён на  -  ГОСТ Р 56845-2019ГОСТ действующий

Информация

Название Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена
Дата актуализации текста 01.01.2021
Дата актуализации описания 01.01.2021
Дата издания 02.06.2016
Дата введения в действие 01.11.2016
Дата завершения срока действия 01.05.2020
Область и условия применения В рамках контекста серии стандартов ИСО/ИИЭР 11073 по взаимодействию приборов настоящий стандарт определяет общую структуру для создания абстрактной модели персональных медицинских данных, доступных в транспортно-независимом синтаксисе передачи, требуемого для установления логических соединений между системами и для обеспечения средств представления и сервисов, необходимых для осуществления задач связи. По мере возможности протокол оптимизируется в соответствии с персональными медицинскими требованиями использования и улучшается за счет общепринятых методов и средств
Опубликован Официальное издание. М.: Стандартинформ, 2016 год
Утверждён в Росстандарт
Заменяющий ГОСТ Р 56845-2019ГОСТ действующий

Расположение в каталоге ГОСТ

     
ГОСТ Р 56845-2015/ISO/IEEE 11073-20601:2010

     
Группа П85

     

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

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

Информационное взаимодействие с персональными медицинскими приборами

Часть 20601

Прикладной профиль. Оптимизированный протокол обмена

Health informatics. Point-of-care medical device communication. Part 20601. Application profile. Optimized exchange protocol



ОКС 35.240.80

ОКСТУ 4002

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

     

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному документу ISO/IEEE 11073-20601:2010* "Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена" (ISO/IEEE 11073-20601:2010 "Health informatics - Point-of-care medical device communication - Part 20601: Application profile - Optimized exchange protocol")

________________

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


Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (пункт 3.5).

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

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


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

     1 Обзор

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


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

     1.2 Цель


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

     1.3 Контекст


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

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

Графическая пунктирная накладка показывает главное направление деятельности Рабочей группы по персональным медицинским приборам ИИЭР 11073. Первостепенный интерес представляет интерфейс и обмен данными между агентами и управляющим устройством. Однако данный интерфейс невозможно создать, игнорируя остальную часть пространства решений. Принимая во внимание всю систему в целом можно обеспечить целесообразную передачу данных от агентов к удаленным службам поддержки. Данный подход может включать конвертацию формата данных, протоколов обмена, и транспортных протоколов на различных интерфейсах. Большая часть мер по стандартизации находится вне области применения Рабочей группы по персональным медицинским приборам; однако объединение мер по стандартизации позволяет осуществлять бесперебойную передачу данных через все множество систем.


Рисунок 1 - Общий контекст работы


Рисунок 2 демонстрирует иерархическое представление архитектуры агента или управляющего устройства с указанием соответствующих стандартов. Уровни приложений в основном не относятся к какому-либо конкретному транспортному протоколу. Там, где это необходимо, настоящий стандарт определяет допущения, которые требуют прямой поддержки транспортным протоколом или некоторого "промежуточного" уровня над ним. Данный подход позволяет оказывать поддержку различным видам транспортных протоколов. Определение транспортного протокола лежит вне рамок области применения настоящего стандарта и рабочей группы.

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

Над протоколом обмена находятся специализации, которые описывают специфические детали относительно конкретного агента (например, монитор артериального давления, весы, педометр). Специализации дают подробную информацию о том, как данные агенты работают и действуют, представленную в виде детального описания для создания конкретного типа агента. А также они дают ссылки на соответствующий стандарт для получения дополнительной информации. Номера стандартов по специализациям приборов варьируются от ИИЭР 11073-10401 до ИИЭР 11073-10499 включительно. При приведении ссылок на стандарты используется следующая схема: ИИЭР 11073-104zz, где zz может быть любым числом от 01 до 99 включительно.

Технический отчет ИСО/ИИЭР P11073-090103 [8] описывает личное пространство персональных медицинских приборов в целом с последующим пояснением базовых вариантов использования и моделей применения.


Рисунок 2 - Общая схема настоящего стандарта


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

- использование базовых идей и/или фрагментов из других документов (пунктирные линии);

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

Настоящий стандарт вносит информацию из ИСО/ИИЭР 11073-10201:2004 [13] и ИСО/ИИЭР 11073-20101:2004 [14] в качестве нормативных приложений. При наличии разногласий между данными стандартами, настоящий стандарт считается приоритетным. В связи с повторным использованием структур из рассматриваемых стандартов, некоторые названия могут быть более ориентированными на медицинские учреждения (например, Система медицинского прибора (MDS) вместо системы персонального медицинского прибора); однако, для сохранения согласованности, были сохранены традиционные названия.

Настоящий стандарт копирует соответствующие параграфы ИСО/ИИЭР 11073-10101 [12] и включает новые номенклатурные коды.


Рисунок 3 - Связь с другими документами ИИЭР 11073

     

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


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

_______________

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


ИИЭР 802-2001 Стандарт ИИЭР для локальных вычислительных сетей и сетей мегаполисов. Обзор и архитектура (ИИЭР Std 802-2001, ИИЭР Standard for Local and Metropolitan Area Networks: Overview and Architecture)

_______________

Публикации ИИЭР доступны в Институте инженеров по электротехнике и радиоэлектронике, 45 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ИИЭР.org/).


Рекомендации сектора электросвязи МСЭ X.667 (сентябрь 2004 г.) Информационная технология. Взаимосвязь открытых систем. Процедуры для работы органов регистрации семиуровневой сетевой модели ВОС: Генерация и регистрация универсально уникальных идентификаторов (UUID) и их использование в качестве компонентов идентификатора объектов языка ASN.1 (ITU-T Rec. X.667 [Sept. 2004], Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: Generation and registration of universally unique identifiers (UUIDs) and their use as ASN.1 object identifier components)

_______________

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

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

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


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

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

3.1.2 вычислительное устройство (compute engine): См. управляющее устройство (manager).

3.1.3 подтвержден (confirmed): Механизм службы уведомления о завершении на уровне приложения. Для сервисов EVENT REPORT (при передаче данных) подтверждение позволяет агенту понять, когда управляющее устройство "приняло на себя ответственность" за данную часть информации, после чего агент может ее удалить. Для сервисов ACTION, GET и SET (при управлении) подтверждение позволяет управляющему устройству понять, когда агент "завершает" запрашиваемую операцию.

3.1.4 прибор (device): Физический прибор, выполняющий роль либо агента, либо управляющего устройства.

3.1.5 идентификатор (handle): Беззнаковое 16-битное число, являющееся уникальным, и идентифицирующее один из объектов-экземпляров внутри агента.

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

3.1.7 персональный медицинский прибор (personal health device): Прибор, используемый для личного медицинского применения.

3.1.8 персональный удаленный медицинский прибор (personal telehealth device): См. персональный медицинский прибор.

     3.2 Сокращения


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

ASCII

- американский стандартный код для обмена информацией;

_______________

В настоящем стандарте термин ASCII используется в значении набора знаков в соответствии с ISO/IEC 646 (1991) [B7].

ASN.1

- язык asn.1 для описания абстрактного синтаксиса;

APDU

- блок данных протокола прикладного уровня;

AVA

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

BER

- правила бинарного кодирования;

DIM

- информационная модель предметной области;

EUI-64

- расширенный уникальный идентификатор (64 бит);

GMDN

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

ICS

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

ID

- идентификатор/идентификационная информация;

LSB

- младший двоичный бит;

MDER

- правила кодирования медицинских приборов;

MDNF

- цифровой формат медицинского прибора;

MDS

- система медицинского прибора;

MOC

- класс медицинского объекта;

MSB

- старший двоичный бит;

NaN

- не число;

NBO

- порядок передачи байтов;

NRes

- не при этом разрешении экрана;

NTP

- временной сетевой протокол;

OID

- идентификатор объекта;

OUI

- идентификатор, уникальный в пределах организации;

PDU

- блок данных протокола;

PER

- правила уплотненного кодирования (ASN.1);

POC

- объект и класс информационной модели предметной области персональных медицинских приборов;

RC

- счетчик повторений в процедуре ассоциации;

RTC

- часы реального времени;

RT-SA

- массив показаний, снятых в режиме реального времени;

SNTP

- простой временной сетевой протокол;

TCP

- управляющий протокол передачи;

TO

- время работы процедуру ассоциации;

TO

- время работы сервиса подтвержденного действия;

TO

- время работы сервиса подтвержденного отчета о событии для объекта системы медицинского прибора;

TO

- время работы сервиса подтвержденного отчета о событии для объекта PM-блока;

TO

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

TO

- время работы сервиса подтвержденного события для очистки объекта PM-блока;

TO

- время выполнения процедуры конфигурации;

TO

- время работы сервиса подтвержденной установки;

TO

- время работы сервиса получения (get);

TO

- время работы процедуры разъединения ассоциации;

TO

- специальный период времени между сервисами для объектов систем медицинского прибора;

TO

- специальный период времени передачи сегмента для объекта PM-сегмента;

UTC

- универсальное время;

UUID

- универсальный уникальный идентификатор;

USB

- универсальная последовательная шина;

XER

- правила кодировки расширяемого языка разметки (XML).

     

     4 Основные принципы


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

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

- медицинские агенты обычно имеют очень ограниченные вычислительные возможности;

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

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

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

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

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

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

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

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

- информационная модель профиля связи строится на информационной модели предметной области (DIM) ИСО/ИИЭР 11073 и включает выбор оптимальных параметров, где это необходимо;

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

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

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

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

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

     5 Введение в персональные медицинские приборы (ИИЭР 11073)

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


Общая системная модель ИСО/ИИЭР 11073 подразделяется на три основных компонента: информационная модель предметной области, сервисная модель и коммуникационная модель. Эти три модели работают вместе для представления данных, определения доступа к данным и методологий команд, а также для передачи данных от агента к менеджеру. По причине тесной связи между моделями информационная модель предметной области, сервисная модель и коммуникационная модель кратко представлены в 5.2, 5.3 и 5.4, соответственно, и более подробно описаны в разделах 6, 7 и 8, соответственно.

     5.2 Информационная модель предметной области (DIM)


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

     5.3 Сервисная модель


Сервисная модель, детально описанная в 7, обеспечивает элементарные процедуры доступа к данным, посылаемые между агентом и менеджером для обмена данными из DIM. Эти элементарные процедуры включают в себя такие команды как Get (Получить), Set (Установить), Action (Действие) и Event Report (Отчет о событии).

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


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

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

     6 DIM персонального медицинского прибора

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


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

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

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

- для отделения спецификации от применения посредством принципа инкапсуляции;

- для поддержки эволюции посредством принципа наследования;

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

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

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

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

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

Настоящий стандарт использует информационные классы и объекты, которые были определены в ИСО/ИИЭР 11073-10201:2004 [13], при этом адаптируя их под область коммуникаций персональных медицинских приборов следующим образом:

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

- могут не приводиться определения сервисов дополнительного объекта;

- могут приводиться определения дополнительных атрибутов;

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

     6.2 Использование номенклатуры


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

Номенклатура ИСО/ИИЭР 11073 определяется как набор контекстно-зависимых разделов. Номенклатурный код в каждом контекстно-зависимом разделе определяется 16-битным кодом, который поддерживает до 65536 независимых терминов в разделе. На разделы ссылаются 16-битным кодом раздела. Если раздел номенклатурного кода определяются посредством контекста, тогда становится возможным использовать только 16-битный код. Если контекст не определен или требуется контекстно-независимый код, тогда эта ситуация задается 32-битным кодом, построенным из 16-битного кода раздела вместе с 16-битным кодом термина. Таблица 1 демонстрирует разделы, которые определены в настоящем стандарте и/или ИСО/ИИЭР 11073-10101 [12].

Коды термина от 0xF000 до 0xFFFF в каждом разделе в номенклатуре предусмотрены для частных номенклатурных кодов.

Для каждого номенклатурного термина ИСО/ИИЭР 11073-10101 [12] определяет систематические названия, которые объясняют этот термин, значение уникального кода, и ссылочный идентификатор (ID). Ссылочный ID указываются в форме MDC_XXX_YYY (MDC указывает на "коммуникацию медицинского прибора"). В тексте настоящего стандарта номенклатурные термины и номенклатурные коды указываются в ссылочном ID.


Таблица 1 - Разделы в номенклатуре

Номер раздела

Номенклатурная категория

1

Объектно-ориентированная (ОО)

2

Дистанционное управление и сбор данных (SCADA)

3

События

4

Размеры (единицы измерения)

5

Виртуальные атрибуты

6

Группы параметров

7

Участки (тела)

8

Инфраструктура

9-127

Резерв

128

Менеджмент заболеваний персонального медицинского прибора

129

Здоровье и фитнес персонального медицинского прибора

130

Достойная старость персонального медицинского прибора

131-254

Резерв

255

Коды возврата

256

Внешние номенклатурные ссылки

257-1023

Резерв

1024

Частная

1025-65535

Резерв

     

     6.3 Определения классов персональных медицинских объектов

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

Схема на рисунке 4 использует Унифицированный язык моделирования (UML) для представления информационных объектов персонального медицинского агента вместе с отношениями классов. Верхний объект представляет информацию и статус системы MDS (см. 6.3.2). Существует ноль или более числовых, массивов показаний, снятых в режиме реального времени (RT-SA), перечислений, сканеров или других объектов PM-блока, ассоциированных с объектом системы MDS. Существует ноль или больше PM-сегментов, которые содержат постоянные метрики, ассоциированные с PM-блоком. Числовые объекты, объекты RT-SA и объекты перечисления происходят из базового класса общей метрики, который содержит общие и разделяемые атрибуты (см. 6.3.3). В общем случае, числовые объекты представляют эпизодические измерения (см. 6.3.4), объекты RT-SA представляют непрерывные показания или биосигналы (см. 6.3.5), объекты перечисления представляют аннотации событий (см. 6.3.6), а PM-блоки (см. 6.3.7) вместе с PM-сегментами (см. 6.3.8) предоставляют постоянные механизмы хранения метрики, доступ к которой позже получает менеджер. Кроме того, объект сканера (подробно определенный в 6.3.9) облегчает сообщения о передаче данных, инициированных агентом.


Рисунок 4 - Персональный медицинский прибор. DIM


Пункты с 6.3.2 по 6.3.9 описывают классы персонального медицинского прибора модели DIM. Каждый подпункт использует следующий формат:

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

- атрибуты, определяемые классом;

- доступные методы;

- потенциальные события, генерируемые объектами инстанциируются от классов;

- доступные сервисы, такие как получение или установка атрибутов.

Каждый тип атрибутных данных определяется при помощи абстрактной синтаксической нотации версии 1 (ASN.1). Определения ASN.1 для всех типов данных и форматов обмена находятся в приложении A.

Атрибуты для каждого класса определены в таблицах, которые представляют название атрибута, его номенклатурную ссылку ID, тип, описание атрибута, и его классификатор. Классификаторы со значением O - необязательный атрибут, M - обязательный атрибут и C - условный атрибут, которые зависят от условий, указанных в столбце "Комментарий". Условные атрибуты могут реализовываться в отношении агента. Обязательные атрибуты должны реализовываться агентом. Условные атрибуты должны реализовываться при действии условия, а также в других случаях.

Номенклатурный код классов объектов (например, числовой, RT-SA) пересылается менеджеру во время конфигурирования для создания зеркального представления объекта. Каждый объект обладает атрибутом Handle (дескриптор), который используется для идентификации объекта для операций (от и к объекту), а также другими атрибутами для представления и передачи информации на физический прибор и его источники данных. Доступ к атрибутам и возможность внесения изменений предоставляется посредством таких методов, как GET (ПОЛУЧИТЬ) и SET (УСТАНОВИТЬ). Данные передаются при помощи метода EVENTs (СОБЫТИЯ).

6.3.2 Класс MDS

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

Каждый персональный медицинский агент определяется объектно-ориентированной моделью, указанной на рисунке 4. Объект верхнего уровня каждого агента инстанцируются от класса MDS. Каждый агент обладает одним объектом MDS. MDS представляет идентификационную информацию и статус агента посредством его атрибутов.

6.3.2.2 Идентификация класса MDS

Номенклатурный код для обозначения класса MDS:MDC_MOC_VMS_MDS_SIMP.

6.3.2.3 Атрибуты классов MDS

Таблица 2 определяет набор атрибутов MDS, поддерживаемых для связи персональных медицинских агентов. Объект MDS должен поддерживать все обязательные атрибуты, но может иметь поднаборы условных и необязательных атрибутов.


Таблица 2 - Атрибуты MDS

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Handle

MDC_ATTR_ID_HANDLE

Handle

Атрибут Handle представляет ссылочный ID для данного объекта. Значение атрибута MDS Handle должно составлять 0

М

System-Type

MDC_ATTR_SYS_TYPE

System-Type

Данный атрибут определяет тип агента в соответствии с номенклатурой (например, весы). Значения должны быть получены из ИСО/ИИЭР 11073-10101 [12], раздела nom-part-object и подраздела MD-Gen (Медицинский Прибор - Общий).

Должен присутствовать либо Данный атрибут либо System-Type-Spec-List. Данный атрибут должен оставаться неизменным после одобрения конфигурации

С

System-Model

MDC_ATTR_ID_MODEL

System-Model

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

М

System-Id

MDC_ATTR_SYS_ID

OCTET STRING

Данный атрибут принадлежит к ИИЭР EUI-64, который состоит из 24-битного идентификатора, уникального в пределах организации (OUI), сопровождаемого 40-битным ID, определенным производителем. Значение OUI должно быть предписано Регистрационным органом ИИЭР http://standards. ИИЭР.org/regauth/index.html) и должно использоваться в соответствии со стандартом ИИЭР Std 802-2001.6 Данный атрибут должен оставаться неизменным после одобрения конфигурации

M

Dev-Configuration-Id

MDC_ATTR_DEV_CONFIG_ID

Configld

Данный атрибут определяет идентификацию конфигурации прибора-агента. Данный Dev-Configuration-Id является статичным во время работы ассоциации; обычно он меняется в течение процедуры ассоциации. Менеджер может получить данный атрибут во время работы. Если данный атрибут встает в очередь до того, как агент и менеджер одобрят конфигурацию, агент должен вернуть ID конфигурации, предлагаемый в этот момент времени. Для более подробной информации по данному атрибуту, смотреть пункт 8.7.6. Данный атрибут должен оставаться неизменным после одобрения конфигурации

М

Attribute-Value-Map

MDC_ATTR_ATTRIBUTE_VAL_MAP

AttrValMap

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

С

Production-Specification

MDC_ATTR_ID_PROD_SPECN

Production-Spec

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

О

Mds-Time-Info

MDC_ATTR_MDS_TIME_INFO

MdsTimeInfo

Данный атрибут определяет способности обработки времени и статус MDS. Использование этого атрибута требуется при поддержке синхронизации или настройки времени

С

Date-and-Time

MDC_ATTR_TIME_ABS

AbsoluteTime

Данный атрибут определяет дату и время агента с точностью в 1/100 секунды. Для более подробной информации о данном атрибуте, см. 8.12. Если агент сообщает об абсолютном значении времени (AbsoluteTime) в любом из его сообщений, он должен сообщить его текущее значение абсолютного времени в данном атрибуте

C

Relative-Time

MDC_ATTR_TIME_REL

RelativeTime

Если агент сообщает о Относительном времени (RelativeTime) в своем сообщении, он должен сообщить текущее значение Относительного времени (RelativeTime) в данном атрибуте

C

HiRes-Relative-Time

MDC_ATTR_TIME_REL_HI_RES

HighResRelativeTime

Если агент сообщает о HighResRelativeTime в своем сообщении, он должен сообщить текущее значение HighResRelativeTime в данном атрибуте

C

Date-and-Time-Adjustment

MDC_ATTR_TIME_ABS_ADJUST

AbsoluteTimeAdjust

Данный атрибут сообщает о любых настройках даты и времени, которые выполняются в связи с изменением времени человеком или в связи с такими событиями, как переход на летнее время. Используется только в отчетах о событиях. Если запрашивается при помощи команды MDS объекта "Get", данное значение либо не должно присутствовать, либо равно нулю. Если агент осуществляет настройку времени и даты, данный атрибут используется в отчете о событиях для сообщения о таких изменениях

C

Power-Status

MDC_ATTR_POWER_STAT

PowerStatus

Данный атрибут сообщает, осуществляется ли потребление энергии от батареи или от электросетей, а также статус заряда

O

Battery-Level

MDC_ATTR_VAL_BATT_CHARGE

INT-U16

Данный атрибут сообщает процентное соотношение оставшейся емкости батареи, которое не определяется, если значение >100

O

Remaining-Battery-Time

MDC_ATTR_TIME_BATT_REMAIN

BatMeasure

Данный атрибут представляет прогнозируемый объем оставшегося рабочего времени аккумуляторов. В блок BatMeasure устанавливается одно из значений MDC_DIM_MIN, MDC_DIM_HR или MDC_DIM_DAY для указания минут, часов или дней соответственно

O

Reg-Cert-Data-List

MDC_ATTR_REG_CERT_DATA_LIST

RegCert-DataList

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

O

System-Type-Spec-List

MDC_ATTR_SYS_TYPE_SPEC_LIST

TypeVerList

Данный атрибут сообщает тип(-ы) агента, в соответствии с номенклатурой (например, весы). Значения должны происходить из ИСО/ИИЭР 11073-10101 [12], раздела nom-part-in-frastruct, подраздела DEVspec, и ссылка на специализации ИСО/ИИЭР 11073-104zz. Если агент не следует ни одной из специализации, перечень должен остаться пустым. Данный перечень должен также содержать редакции специализации. Должен присутствовать либо данный атрибут, либо Тип Системы (System-Type). Если агент мультифункциональный, то должен присутствовать данный атрибут. Данный атрибут должен оставаться неизменным после одобрения конфигурации

C

Confirm-Timeout

MDC_ATTR_CONFIRM_TIMEOUT

RelativeTime

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

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

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

O


Типы атрибутивных данных определены в приложении A

6.3.2.4 Методы объектов MDS

Таблица 3 определяет методы (действия), доступные для объектов системы MDS. Данные методы запрашиваются при помощи сервиса ACTION. В таблице 3 столбец Метод/Действие определяет наименование метода. Столбец "Режим" определяет, был ли метод запущен как неподтвержденное действие (т.е. roiv-cmip-action из A.10.2) или подтвержденное действие (т.е. roiv-cmip-confirmed-action). Столбец "Тип Действия" определяет ID номенклатуры для использования в поле "тип действия" запроса и ответа действия (см. A.10.6). Столбик action-info-args определяет структуру ассоциированных данных для использования в сообщениях действий для поля запроса action-info-args. Столбец "Результат action-info-args" определяет структуру, используемую для ответа на action-info-args.


Таблица 3 - Методы объектов MDS

Метод/действие

Режим

Тип действия

action-info-args

Результат action-info-args

MDS-Data-Request

подтвержденный

MDC_ACT_DATA_REQUEST

Запрос данных (DataRequest)

Ответ данных (DataRequest)

Set-Time

подтвержденный

MDC_ACT_SET_TIME

Вызов установки времени (SetTimeInvoke)

нет


Запрос данных MDS (MDS-Data-Request).

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

Установка времени (Set-Time).

Данный метод позволяет системе менеджера устанавливать часы реального времени (RTC) с абсолютным временем. Агент указывает, корректна ли команда Установки времени при помощи mds-time-capab-set-clock bit в атрибуте Mds-Time-Info (см. таблицу 2).

6.3.2.5 События объектов MDS

Таблица 4 определяет потенциальные события, переданные объектом MDS. Менеджер должен поддерживать все методы, определенные в таблице 4.

MDS-Data-Request (Запрос данных MDS).

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

Set-Time (Установка времени).

Данный метод позволяет системе менеджера устанавливать часы реального времени (RTC) и абсолютного времени. Агент указывает, активна ли команда Set-Time при помощи mds-time-capab-set-clock bit в атрибуте Mds-Time-Info (см. таблицу 2).


Таблица 4 - События объектов MDS

Событие

Режим

Тип события

Параметр информации о событии

Информация об ответе на событие

MDS-Configuration-Event

Подтвержденный или неподтвержденный

MDC_NOTI_CONFIG

ConfigReport

ConfigReportRsp

MDS-Dynamic-Data-Update-Var

Подтвержденный или неподтвержденный

MDC_NOTI_SCAN_REPORT_VAR

ScanReportInfoVar

-

MDS-Dynamic-Data-Update-Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_SCAN_REPORT_FIXED

ScanReportInfoFixed

-

MDS-Dynamic-Data-Update-MP-Var

Подтвержденный или неподтвержденный

MDC_NOTI_SCAN_REPORT_MP_VAR

ScanReportInfoMPVar

-

MDS-Dynamic-Data-Update-MP-Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_SCAN_REPORT_MP_FIXED

ScanReportInfoMPFixed

-


Событие Конфигурации MDS (MDS-Configuration-Event).

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

Событие MDS-Dynamic-Data-Update-Var.

Данное событие предоставляет динамические данные (обычно измерения) от агента для нескольких или всех объектов, поддерживаемых агентом. Данные о сообщаемых объектах предоставляются, используя переменный формат списка атрибутов параметров настройки (см. 7.4.5 для более подробной информации или для форматов отчетов о событии). Событие запускается Запросом данных MDS-Data-Request из системы менеджера, или запрос пересылается как незапрашиваемое сообщение агентом. Для агентов, которые поддерживают инициированную менеджером передачу данных, см. 8.9.3.3.3 для получения дополнительной информации по контролю активации и/или периода передачи данных. Для информации по ограниченному контролю, который менеджер может подтверждать в отношении агентов, которые не поддерживают инициируемую менеджером передачу измерительных данных, см. 8.9.3.3.2.

Событие MDS-Dynamic-Data-Update-Fixe

Данное событие предоставляет динамические данные (обычно измерения от агента для нескольких или всех метрических объектов или объектов системы MDS, поддерживаемых агентом). Данные сообщаются в фиксированном формате, определенным атрибутом Attribute-Value-Map для сообщаемых метрических объектов или объектов системы MDS (см. 7.4.5 для подробной информации о форматах отчетов о событиях). Событие запускается Запросом данных системы MDS (MDS-Data-Request) от системы менеджера (т.е. инициируемая менеджером передача измерительных данных), или пересылается в качестве незапрашиваемого сообщения агентом (т.e. инициируемая агентом передача измерительных данных). Для агентов, которые поддерживают инициированную менеджером передачу данных, см. 8.9.3.3.3 для получения дополнительной информации по контролю активации и/или периода передачи данных. Для информации по ограниченному контролю, который менеджер может подтверждать в отношении агентов, которые не поддерживают инициируемую менеджером передачу измерительных данных, см. 8.9.3.3.2.

Событие MDS-Dynamic-Data-Update-MP-Var.

Данное событие сходится с MDS-Dynamic-Data-Update-Var, позволяя кроме того включение данных от нескольких лиц.

Событие MDS-Dynamic-Data-Update-MP-Fixed.

Данное событие сходится с MDS-Dynamic-Data-Update-Fixed, позволяя кроме того включение данных от нескольких лиц.

6.3.2.6 Другие сервисы системы MDS

6.3.2.6.1 Сервис GET (ПОЛУЧЕНИЕ)

Любой агент, поддерживающий линии двусторонней связи, должен поддерживать сервис GET (ПОЛУЧЕНИЕ) для извлечения значений всех применимых атрибутов объекта MDS. Сервис GET может быть запущен, как только агент получает Ответ на Ассоциацию и приобретает состояние Ассоциации, включая подсостояния Работа и Настройка.

Менеджер может запросить атрибуты объекта системы MDS агента, в случае которого менеджер должен переслать команду "Запрос удаленной работы|Получить" ("Remote Operation Invoke|Get") (см. roiv-cmip-get в A.10.2) с зарезервированным значением дескриптора 0. Агент должен ответить, сообщая атрибуты своего объекта системы MDS менеджеру, используя команду ответа "Ответ Удаленной Работы | Получить" (см. rors-cmip-get в A.10.2). В ответ на команду Получить Объект MDS, возвращаются только примененные агентом атрибуты.

6.3.2.6.2 Сервис SET

На данный момент устанавливаемые атрибуты не представлены.

6.3.3 Метрический класс

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

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

6.3.3.2 Идентификация метрического класса

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

6.3.3.3 Атрибуты метрического класса

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


Таблица 5 - Метрические атрибуты

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Handle

MDC_ATTR_ID_HANDLE

Handle

Атрибут Handle (дескриптор) представляет собой ссылочный ID для данного объекта. У каждого объекта должен быть уникальный ID, присвоенный агентом. Атрибут handle идентифицирует объект в отчетах о событии, пересылаемых менеджеру. Данный атрибут должен оставаться неизменным после одобрения конфигурации

М

Type

MDC_ATTR_ID_TYPE

Type

Данный атрибут определяет особый статический этого объекта в соответствии с номенклатурой (например, частота импульсов для экземпляра числового объекта). Атрибут Type содержит номенклатурный раздел и lD кода термина для контекстно-свободной, расширяемой идентификации. Данный атрибут должен оставаться неизменным после одобрения конфигурации

М

Supplemental-Types

MDC_ATTR_SUPPLEMENTAL_TYPES

Supplemental-TypesList

Данный атрибут может использоваться для передачи дополнительной информации об объекте за рамками атрибутов Type и Metric-Id. Дополнительная информация покрывает такие условия, как расположение сенсора или уровень, при котором объект реагирует на изменения. Специализации прибора определяют предполагаемое применение данного атрибута.

Например, ИИЭР Std 11073-10471 [5] определяет номенклатуру расположения, указывая расположение сенсора на дому и ИСО/ИИЭРР 11073-10404 [B9] определяет три дополнительных типа для быстрого ответа, медленного ответа и выборочной проверки частоты импульса или насыщенности крови кислородом. Данный атрибут должен оставаться неизменным после одобрения конфигурации

О

Metric-Spec-Small

MDC_ATTR_METRIC_SPEC_SMALL

Metric-Spec-Small

Данный атрибут описывает характеристики измерений

M

Metric-Structure-Small

MDC_ATTR_METRIC_STRUCT_SMALL

MetricStructureSmall

Данный атрибут описывает структуру измерения.

В случае отсутствия менеджер должен принять MetricStructureSmall:={ms-struct-simple, 0}.

О

Measurement-Status

MDC_ATTR_MSMT_STAT

MeasurementStatus

Данный атрибут указывает точность конкретного значения или набор считываний

О

Metric-Id

MDC_ATTR_ID_PHYSIO

OID-Type

Данный атрибут может использоваться для удержания идентификации, которая более конкретна по сравнению с общим ID в атрибуте Type. Если оценивается атрибут Metric-Id-Partition, он определяет номенклатурный раздел для Данного атрибута. В противном случае, Тип OIDType совпадает с номенклатурным разделом, в соответствии с атрибутом Type в поле раздела.

Данный атрибут требуется, только если меняется во время работы и атрибут Type не содержит полной идентификации. Например, если атрибут Type содержит общий температурный класс (MDC_TEMP), данный атрибут может сообщить отдельную, но изменяющуюся идентификацию MDC_TEMP_ORAL или MDC_TEMP_RECT.

Должен присутствовать только один атрибут Metric-Id и Metric-Id-List

О

Metric-Id-List

MDC_ATTR_ID_PHYSIO_LIST

MetricIdList

Данный атрибут должен использоваться, когда используется сложное наблюдаемое значение и включается напрямую Metric-Id (например, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value) таким образом, чтобы элементы в списке наблюдаемых значений могли идентифицироваться индивидуально. Порядок списка Metric-Id-List должен соответствовать порядку элементов в сложном наблюдаемом значении. Должен присутствовать только один атрибут of Metric-Id и Metric-Id-List

С

Metric-Id-Partition

MDC_ATTR_METRIC_ID_PART

NomPartition

Данный атрибут может использоваться для определения раздела, из которого были взяты номенклатурные термины Metric-Id или Metric-Id-List. Если атрибут отсутствует, раздел совпадает с номенклатурным разделом, определенным в поле раздела атрибута Type

О

Unit-Code

MDC_ATTR_UNIT_CODE

OID-Type

Данный атрибут определяет номенклатурный код для единиц измерения из раздела nom-partdim (например, MDC_DIM_KILO_G)

О

Attribute-Value-Map

MDC_ATTR_ATTRIBUTE_VAL_MAP

AttrValMap

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

C

Source-Handle-Reference

MDC_ATTR_SOURCE_HANDLE_REF

HANDLE

Данный атрибут устанавливает отношение данного экземпляра объекта к первичному объекту. Данный атрибут используется, когда требуется смоделировать явное соотношение между экземплярами объекта для определения зависимостей. Использование данного атрибута определяется специализацией прибора

О

Label-String

MDC_ATTR_ID_LABEL_STRING

OCTET STRING

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

O

Unit-Label-String

MDC_ATTR_UNIT_LABEL_STRING

OCTET STRING

Данный атрибут определяет текстовое представление размера кода блока Unit-Code в печатном ASCII. Значение Данного атрибута полностью зависит от выбора производителя агента. Это может быть потенциально полезным для менеджера в качестве строки дисплея или в качестве помощи по выбору поведения, когда он не может понять MDC_ATTR_UNIT_CODE, отправленного агентом

O

Absolute-Time-Stamp

MDC_ATTR_TIME_STAMP_ABS

AbsoluteTime

Данный атрибут определяет дату и время наблюдения с точностью в 1/100 секунды, если это применимо. За более подробной информацией по Данному атрибуту обратитесь к п.8.12. Если агент сохраняет данные (в объекте PM-блока или как "временно хранимые измерения"), он должен ассоциировать отметку времени (Absolute-Time-Stamp, Relative-Time-Stamp или HiRes-Time-Stamp) с данными

С

Relative-Time-Stamp

MDC_ATTR_TIME_STAMP_REL

RelativeTime

Данный атрибут определяет время наблюдения (отметку времени в формате относительного времени/количества тика часов в соответствии с типом данных RelativeTime). Если агент сохраняет данные, он должен ассоциировать отметку времени (Absolute-Time-Stamp, Relative-Time-Stamp или HiRes-Time- Stamp) с данными

С

HiRes-Time-Stamp

MDC_ATTR_TIME_STAMP_REL_HI_RES

HighResRelative-Time

Данный атрибут определяет время наблюдения (отметку времени в формате высокоточного относительного времени/с количеством тактов часов в соответствии с типом данных HighResRelativeTime). Если агент хранит данные, он должен ассоциировать отметку времени (Absolute-Time-Stamp, Relative-Time-Stamp или HiRes-Time-Stamp) с данными

C

Measure-Active-Period

MDC_ATTR_TIME_PD_MSMT_ACTIVE

FLOAT-Type

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

O

6.3.3.4 Методы метрического объекта

Нет

6.3.3.5 События метрического объекта

Объекты, которые происходят из метрического класса, не сообщают напрямую о своих наблюдениях; чаще всего наблюдения передаются посредством другого объекта, такого как объект системы MDS, объект сканера или объект PM-блока.

6.3.3.6 Другие метрические сервисы

Нет

6.3.4 Числовой класс

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

Экземпляр числового класса представляет числовое измерение. Значения числового объекта пересылаются от агента менеджеру, используя сервис ОТЧЕТ О СОБЫТИЯХ (EVENT REPORT) (см. 7.3). Данный класс происходит от метрического базового класса.

6.3.4.2 Идентификация числового класса

Номенклатурный код для идентификации числового класса: MDC_MOC_VMO_METRIC_NU.

6.3.4.3 Атрибуты числового класса

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


Таблица 6 - Числовые атрибуты

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Simple-Nu-Observed-Value

MDC_ATTR_NU_VAL_OBS_SIMP

SimpleNuObsValue

Данный атрибут определяет числовое наблюдаемое значение объекта без какой-либо вложенной информации о статусе, наблюдаемой в Nu-Observed-Value. Должно присутствовать одно из значений Simple-Nu-Observed-Value, Basic-Nu-Observed-Value, Nu-Observed-Value, Compond-Nu-Observed-Value, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value

С

Compound-Simple-Nu-Observed-Value

MDC_ATTR_NU_CMPD_VAL_OBS_SIMP

SimpleNuObsValueCmp

Данный атрибут представляет матрицу Simple-Nu-Observed-Values. Должно присутствовать одно из значений Simple-Nu-Observed-Value, Basic-Nu-Observed-Value, Nu-Observed-Value, Compond-Nu-Observed-Value, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value

С

Basic-Nu-Observed-Value

MDC_ATTR_NU_VAL_OBS_BASIC

BasicNuObsValue

Данный атрибут определяет числовое наблюдаемое значение объекта без какой-либо вложенной информации о статусе, но с небольшим числовым представлением, по сравнению с значением Simple-Nu-Observed-Value.

Должно присутствовать одно из значений Simple-Nu-Observed-Value, Basic-Nu-Observed-Value, Nu-Observed-Value, Compound-Nu-Observed-Value, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value

С

Compound-Basic-Nu-Observed-Value

MDC_ATTR_NU_CMPD_VAL_OBS_BASIC

BasicNuObsValueCmp

Данный атрибут представляет собой матрицу Basic-Nu-Observed-Values. Должно присутствовать одно из значений Simple-Nu-Observed-Value, Basic-Nu-Observed-Value, Nu-Observed-Value, Compond-Nu-Observed-Value, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value

С

Nu-Observed-Value

MDC_ATTR_NU_VAL_OBS

NuObsValue

Данный атрибут определяет числовое наблюдаемое значение объекта и объединяет статус измерения и информацию о единице измерения. Он используется, когда статус/единица динамичные и всегда представляются вместе со значением. Должно присутствовать одно из значений Simple-Nu-Observed-Value, Basic-Nu-Observed-Value, Nu-Observed-Value, Compond-Nu-Observed-Value, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value

С

Compound-Nu-Observed-Value

MDC_ATTR_NU_CMPD_VAL_OBS

NuObsValueCmp

Данный атрибут сочетает матрицу значения, статуса и единицы. Данный атрибут доступен для использования только в отчетах о событиях в переменном формате. Должно присутствовать одно из значений Simple-Nu-Observed-Value, Basic-Nu-Observed-Value, Nu-Оbserved-Value, Compond-Nu-Observed-Value, Compound-Simple-Nu-Observed-Value или Compound-Basic-Nu-Observed-Value

С

Accuracy

MDC_ATTR_NU_ACCUR_MSMT

FLOAT-Type

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

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

О


Атрибуты Compound-Simple-Nu-Obs-Value, Compound-Basic-Nu-Obs-Value и Compound-Nu-Observed-Value представляют список концептов для наблюдаемых значений. Данный концепт должен использоваться, когда между отдельными наблюдаемыми значениями дана сильная взаимосвязь, которая может быть зависима от номенклатуры и/или применения. Сложные наблюдаемые значения разделяют общий контекст статической атрибуции, за исключением идентификации элементов. Примером этого может служить применение артериального давления, где номенклатурный базовый термин выражает "Артериальное давление", а более специфические термины выражают "Артериальное давление Систолическое", "Артериальное давление Диастолическое", и "Артериальное давление Среднее". Соответствующий DIM должен содержать только один экземпляр числового объекта, который использовал бы один из форматов сложных числовых значений наблюдений для представления "систолической", "диастолической" и "средней" частей "Артериального давления".

6.3.4.4 Методы числового объекта

Нет

6.3.4.5 События числового объекта

Нет

6.3.4.6 Другие числовые сервисы

Нет

6.3.5 Класс RT-SA

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

Экземпляр класса RT-SA представляет измерение формы сигнала. Значения объекта RT-SA пересылаются от агента менеджеру с помощью сервиса ОТЧЕТ О СОБЫТИЯХ (EVENT REPORT) (см. 7.3). Данный класс происходит от метрического базового класса.

6.3.5.2 Идентификация класса RT-SA

Номенклатурный код для идентификации класса RT-SA: DC_MOC_VMO_METRIC_SA_RT.

6.3.5.3 Атрибуты класса RT-SA

Таблица 7 определяет набор атрибутов RT-SA, поддерживаемых для связи персонального медицинского устройства.

Показаний, снятых в режиме реального времени


Таблица 7 - Атрибуты RT-SA

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Sample-Period

MDC_ATTR_TIME_PD_SAMP

RelativeTime

Данный атрибут определяет интервал времени между последовательными показаниями, осуществляющимися каждые 1/8 мс. Следовательно, 8000=1 с.

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

М

Simple-Sa-Observed-Value

MDC_ATTR_SIMP_SA_OBS_VAL

OCTET STRING

Данный байтовый массив содержит показания, которые сообщаются агентом в формате, описанном в спецификации Sa-Specification и спецификации масштаба и диапазона (Scale-and-Range-Specification). Длина должна быть с дополняющими байтами в конце. Sa-Specification определяет текущее количество используемых байтов

М

Scale-and-Range-Specification

MDC_ATTR_SCALE_SPECN_I8

MDC_ATTR_SCALE_SPECN_I16

MDC_ATTR_SCALE_SPECN_I32

ScaleRangeSpec8

ScaleRangeSpec16

ScaleRangeSpec32

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

М

Sa-Specification

MDC_ATTR_SA_SPECN

SaSpec

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

М


Характеристика объекта RT-SA может быть получена путем исследования атрибута Sa-Specification. Данный атрибут определяет число элементов в матрице и размер элементов, более подробная информация дана в A.3.4.

Об агентах, которые поддерживают инициированную менеджером передачу данных, см. в 8.9.3.3.3 дополнительную информацию по контролю активации и/или периода передачи данных. Информацию по ограниченному контролю, который менеджер может подтверждать в отношении агентов, которые не поддерживают инициируемую менеджером передачу измерительных данных, см. в 8.9.3.3.2.

Атрибут Scale-and-Range-Specification.

Атрибут Scale-and-Range-Specification определяет коэффициент алгоритма для преобразования измеренных значений в их абсолютные значения. Менеджер должен применить следующий алгоритм:

,


где Y - преобразованное абсолютное значение;

M=(наибольшее абсолютное значение - наименьшее абсолютное значение)/(наибольшее измеренное значение - наименьшее измеренное значение);

B=наибольшее абсолютное значение - (M х наибольшее измеренное значение);

X - измеренное значение.

Пример работы данного алгоритма приведен в приложении B.

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

6.3.5.4 Методы объекта RT-SA

Нет

6.3.5.5 События объекта RT-SA

Нет

6.3.5.6 Другие сервисы RT-SA

Нет

6.3.6 Класс перечисления

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

Экземпляр класса перечисления представляет статусную информацию и/или аннотационную информацию. Значения объектов перечисления кодируются в форме нормативных кодов (в соответствии с ИСО/ИИЭР 11073-10101 [12]) или в свободной форме. Значения объекта перечисления пересылаются от агента менеджеру с помощью сервиса ОТЧЕТ О СОБЫТИЯХ (EVENT REPORT) (см. 7.3). Данный класс происходит от метрического базового класса.

6.3.6.2 Идентификация класса перечисления

Номенклатурный код для идентификации класса перечисления: MDC_MOC_VMO_METRIC_ENUM.

6.3.6.3 Атрибуты класса перечисления

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


Таблица 8 - Атрибуты перечисления

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Enum-Observed-Value-Simple-OID

MDC_ATTR_ENUM_OBS_VAL_SIMP_OID

OID-Type

Данное значение сообщается как номенклатурный код. Если атрибуту Enum-Observed-Value-Partition присваивается значение, он определяет номенклатурный раздел для данного атрибута. В противном случае, OID-Type берется из того же номенклатурного раздела, определенного в поле раздела атрибута Type. Должно присутствовать одно из значений Enum-Observed-Value-Simple-OID, Enum-Observed-Value-Simple-Bit-Str, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Str или Enum-Observed-Value

С

Enum-Observed-Value-Simple-Bit-Str

MDC_ATTR_ENUM_OBS_VAL_SIMP_BIT_STR

BITS-32

Данное значение сообщается в виде 32-битовой строки. Должно присутствовать одно из значений Enum-Observed-Value-Simple-OID, Enum-Observed- Value-Simple-Bit-Str, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Str или Enum-Observed-Value

С

Enum-Observed-Value-Basic-Bit-Str

MDC_ATTR_ENUM_OBS_VAL_BASIC_BIT_STR

BITS-16

Данное значение сообщается в виде 16-битовой строки. Должно присутствовать одно из значений Enum-Observed-Value-Simple-OID, Enum-Observed-Value-Simple-Bit-Str, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Str или Enum-Observed-Value

С

Enum-Observed-Value-Simple-Str

MDC_ATTR_ENUM_OBS_VAL_SIMP_STR

EnumPrintableString

Данное значение сообщается в виде ASCII печатной строки. Должен присутствовать один из Enum- Observed-Value-Simple-OID, Enum-Observed-Value-Simple-Bit-Str, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Str или Enum-Observed-Value

С

Enum-Observed-Value

MDC_ATTR_VAL_ENUM_OBS

EnumObsValue

Данный атрибут определяет структурное наблюдаемое значение, которое позволяет дополнительную гибкость типа данных сообщаемого значения. Должно присутствовать одно из значений Enum-Observed-Value-Simple-OID, Enum-Observed-Value-Simple-Bit-Str, Enum-Observed-Value-Basic-Bit-Str, Enum-Observed-Value-Simple-Str или Enum-Observed-Value

С

Enum-Observed-Value-Partition

MDC_ATTR_ENUM_OBS_VAL_PART

NomPartition

Данный атрибут может использоваться для определения раздела, из которого был взят наблюдаемый номенклатурный термин OID значений Enum-Observed-Value-Simple-OID или Enum-Observed-Value. В противном случае, OID-Type берется из того же номенклатурного раздела, определенного в поле раздела атрибута Type

О

6.3.6.4 Методы объекта перечисления

Нет

6.3.6.5 События объекта перечисления

Нет

6.3.6.6 Другие сервисы перечисления

Нет.

6.3.7 Класс PM-блока

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

Экземпляр класса PM-блока предоставляет возможности долгосрочного хранения метрических данных. Данные хранятся в переменном числе объектов PM-сегмента (см. 6.3.8). Хранимые данные объекта PM-блока запрашиваются от агента менеджером, используя сервисы доступа к объектам (см. 7.3). Если концепт PM-блока неизвестен, можно обратиться к приложению C для концептуального обзора перед тем, как ознакомиться со следующими подпунктами.

6.3.7.2 Идентификация класса PM-блока

Номенклатурный код для идентификации класса PM-блока: MDC_MOC_VMO_PMSTORE.

6.3.7.3 Атрибуты класса PM-блока

Таблица 9 определяет набор атрибутов PM-блока, поддерживаемых для связи персонального медицинского устройства:


Таблица 9 - Атрибуты PM-блока

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Handle

MDC_ATTR_ID_HANDLE

HANDLE

Атрибут Handle (дескриптор) представляет собой ссылочный ID для данного объекта.

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

М

PM-Store-Capab

MDC_ATTR_PM_STORE_CAPAB

PmStoreCapab

Данный атрибут определяет базовые возможности экземпляра объекта PM-блока. Данный атрибут должен оставаться неизменным после одобрения конфигурации

М

Store-Sample-Algorithm

MDC_ATTR_METRIC_STORE_SAMPLE_ALG

StoSampleAlg

Данный атрибут описывает, как обрабатываются значения считываний, хранимых в PM-сегменте. Структура StoSampleAlg описывает доступные алгоритмы выборки. Если не применяется специфического алгоритма выборки (другими словами, значения считывания являются необработанными данными), то данный атрибут должен иметь значение st-alg-no-downsampling. Данный атрибут должен оставаться неизменным после одобрения конфигурации

М

Store-Capacity-Count

MDC_ATTR_METRIC_STORE_CAPAC_CNT

INT-U32

Данный атрибут это максимальное количество хранимых записей в PM-сегменте (записи во всех сегментах РМ).

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

О

Store-Usage-Count

MDC_ATTR_METRIC_STORE_USAGE_CNT

INT-U32

Данный атрибут дает текущее (актуальное) количество хранимых записей РМ-сегмента (записи во всех сегментах РМ)

О

Operational-State

MDC_ATTR_OP_STAT

OperationalState

Данный атрибут указывает, вносятся ли в данный момент новые записи в этот PM-сегмент. Если в данный момент PM-сегмент добавляет новые данные, данный атрибут должен быть активирован. В противном случае, он должен дезактивироваться

М

PM-Store-Label

MDC_ATTR_PM_STORE_LABEL_STRING

OCTET STRING

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

О

Sample-Period

MDC_ATTR_TIME_PD_SAMP

RelativeTime

Данный атрибут определяет частоту, с которой в РМ-сегменты добавляются новые записи. Данный атрибут должен присутствовать либо в PM-блоке (в случае чего он относится ко всем периодически хранимым PM-сегментам в PM-блоке), либо в каждом PM-сегменте, если значения отбираются периодически, таким образом разница во времени двух записей в фиксированном сегменте данных постоянна (т.е. установлен бит записей pmsc-periseg-entries в атрибут Pm-Store-Capab). Данный атрибут должен оставаться неизменным после одобрения конфигурации

С

Number-Of-Segments

MDC_ATTR_NUM_SEG

INT-U16

Данный атрибут это число актуально инстанцируемых PM-сегментов, содержащихся в PM-блоке. Необходимо отметить, что Номер экземпляра Instance-Number атрибута PM-сегмента НЕ относится к этому числу (т.е. он не должен находиться в диапазоне от 0 до Числа сегментов), но должен извлекаться методом Get-Segment-Info

М

Clear-Timeout

MDC_ATTR_CLEAR_TIMEOUT

RelativeTime

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

М


Атрибуты Handle и PM-Store-Capab являются частью конфигурации агента; следовательно, менеджер знает соответствующие значения атрибута после процедуры конфигурации.

6.3.7.4 Методы объекта PM-блока

Таблица 10 определяет методы (действия) объекта PM-блока. Данные методы могут быть запущены, используя сервис ACTION.


Таблица 10 - Методы объекта PM-блока

Метод/действие

Режим

Тип действия

action-info-args

Resulting action-info-args

Clear-Segments

подтвержденный

MDC_ACT_SEG_CLR

SegmSelection

(пусто)

Get-Segment-Info C

подтвержденный

MDC_ACT_SEG_GET_INFO

SegmSelection

SegmentInfoList

Trig-Segment-Data-Xfer

подтвержденный

MDC_ACT_SEG_TRIG_XFER

TrigSegmDataXfer-Req

TrigSegmDataXferRsp


Если агент поддерживает класс PM-блока, поддержка методов Get-Segment-Info и Trig-Segment-Data-Xfer обязательна. Поддержка метода Clear-Segments является условной и указывается в атрибуте PM-Store-Capab.

Метод очистка сегментов (Clear-Segments)

Данный метод позволяет менеджеру удалять данные, хранимые в одном или нескольких сегментах PM. Все записи в выбранных сегментах PM удаляются. Если агент поддерживает переменное число PM-сегментов, агент может удалить пустые PM-сегменты. Кроме того, агент может очистить PM-сегменты без команды от менеджера (например, пользователь агента может выбрать удалить хранимые агентом данные); однако, если эта операция производится в ассоциированном состоянии, номер экземпляра (Instance-Number) должен оставаться пустым в ходе ассоциации. Номер экземпляра (Instance-Number) всех остальных PM-сегментов должен оставаться нетронутым при чистке сегмента. Если данный метод запускается на PM-сегменте, у которого атрибут Operational-State активирован, агент должен ответить ошибкой not-allowed-by-object error (roer) с кодом возврата MDC_RET_CODE_OBJ_BUSY.

Необходимо отметить, что поведение метода Clear-Segments ориентировано на конкретное приложение. Метод может очистить все записи от предусмотренного PM-сегмента, оставляя его пустым или может полностью очистить указанный PM-сегмент. Данное поведение определяется в атрибуте PM-Store-Capab. Для определенных приложений рекомендации определяются в специализациях соответствующих приборов, применяющих PM-блок.

Метод Get-Segment-Info

Данный метод позволяет менеджеру извлечь атрибуты PM-сегмента одного или нескольких PM-сегментов, за исключением данных атрибута фиксированного сегмента, который содержит актуальные данные и извлекается при помощи метода Trig-Segment-Data-Xfer. В частности, метод Get-Segment-Info позволяет менеджеру извлечь атрибуты Instance-Numbe экземпляров объекта PM-сегмента и содержание их данных.

Метод Trig-Segment-Data-Xfer

Данный метод позволяет менеджеру начать передачу данных атрибута фиксированного сегмента определенного PM-сегмента. Агент указывает в ответ, принимает ли он или отклоняет этот запрос. Если агент принимает запрос, агент посылает сообщения Segment-Data-Event в соответствии с описанием в 6.3.7.5. Если данный метод запускается на PM-сегменте, у которого активирован атрибут Operational-State, агент должен ответить ошибкой not-allowed-by-object error (roer) с кодом возврата MDC_RET_CODE_OBJ_BUSY.

6.3.7.5 События объекта PM-блока

Таблица 11 определяет потенциальные события, пересылаемые объектом PM-блока:


Таблица 11 - Событие объекта PM-блока

Событие

Режим

Тип события

Параметр информации о событии

Информация об ответе

Segment-Data-Event

подтвержденный

MDC_NOTI_SEGMENT_DATA

SegmentDataEvent

SegmentDataResult


Событие Segment-Data-Event

Данное событие посылает хранимые в фиксированном сегменте PM-сегмента данные от агента менеджеру. Данное событие запускается менеджером методом Trig-Segment-Data-Xfer. Как только передача данных запускается, агент посылает сообщения Segment-Data-Event до тех пор, пока данные фиксированного сегмента полностью не будут переданы или если передача не будет отменена менеджером или агентом. Для более полной информации о содержании передачи PM-сегмента обратитесь к п.8.9.3.4.2.

Рекомендуется размещать как можно больше записей сегмента, содержащихся в Segment-Data-Event для сокращения количества сообщений, требуемых для передачи сегмента.

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

6.3.7.6 Другие сервисы PM-блока

6.3.7.6.1 Сервис GET

Поддержка сервиса GET должна обеспечиваться любым агентом, поддерживающим один и более объектов РМ-блока только во время состояния работы. Менеджер использует сервис GET для извлечения значений всех атрибутов объекта PM-блока.

Менеджер может запросить атрибуты объекта PM-блока агента, в случае чего менеджер должен послать команду "Remote Operation Invoke | Get" (см. roiv-cmip-get в A.10.2) со значением дескриптора объекта PM-блока, определенного в конфигурации агента. Агент должен ответить, сообщая свои атрибуты объекта PM-блока менеджеру, используя ответ "Remote Operation Response | Get" (см. rors-cmip-get в A.10.2).

6.3.8 Класс PM-сегмента

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

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

6.3.8.2 Идентификация класса PM-сегмента

Номенклатурный код для идентификации класса PM-сегмента: MDC_MOC_PM_SEGMENT.

6.3.8.3 Атрибуты класса PM-сегмента

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


Таблица 12 - Атрибуты PM-сегмента

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Instance-Number

MDC_ATTR_ID_INSTNO

InstNumber

Номер экземпляра (Instance-Number) это ID определенного экземпляра объекта PM-сегмента. Он используется менеджером для обращения к сегменту PM

М

PM-Segment-Entry-Map

MDC_ATTR_PM_SEG_MAP

PmSegmentEntryMap

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

М

PM-Seg-Person-Id

MDC_ATTR_PM_SEG_PERSON_ID

PersonId

Настоящий стандарт поддерживает приборы, которые обладают поддержкой простых данных от нескольких лиц. ID лица используется для различия этих лиц. Если PM-блок способен сохранять данные нескольких лиц, он должен установить бит mscmultiperson в атрибуте PMStore-Capab. При установке этого бита все экземпляры PM-сегмента, содержащихся в PM-блоке, должны поддерживать атрибут PM- Seg-Person-Id. В противном случае данный атрибут не определяется

С

Operational-State

MDC_ATTR_OP_STAT

OperationalState

Данный атрибут указывает, вносятся ли в данный момент новые записи в этот PM-сегмент. Если в данный момент PM-сегмент добавляет новые данные, данный атрибут должен быть активирован. В противном случае, он должен дезактивироваться

М

Sample-Period

MDC_ATTR_TIME_PD_SAMP

RelativeTime

Данный атрибут определяет частоту, с которой добавляются записи PM-сегмента.

Данный атрибут должен присутствовать либо в PM-блоке (в случае чего он применяется ко всем периодически хранимым PM-сегментам в PM-блоке), либо в каждом PM-сегменте. Значения дискретные, в атрибуте PM Store-Capab должен быть установлен бит записей pmsc-periseg-entries

С

Segment-Label

MDC_ATTR_PM_SEG_LABEL_STRING

OCTET STRING

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

O

Segment-Start-Abs-Time

MDC_ATTR_TIME_START_SEG

AbsoluteTime

Данный атрибут определяет начальное время сегмента

O

Segment-End-Abs-Time

MDC_ATTR_TIME_END_SEG

AbsoluteTime

Данный атрибут определяет конечное время сегмента

O

Date-and-Time-Adjustment

MDC_ATTR_TIME_ABS_ADJUST

AbsoluteTimeAdjust

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

C

Segment-Usage-Count

MDC_ATTR_SEG_USAGE_CNT

INT-U32

Данный атрибут дает текущее (актуальное) количество хранимых записей

O

Segment-Statistics

MDC_ATTR_SEG_STATS

SegmentStatistics

Данный атрибут определяет матрицу для сообщения минимальной, средней и максимальной статистики для каждого элемента под маркировку

O

Fixed-Segment-Data

MDC_ATTR_SEG_FIXED_DATA

Не применимо.

Эти данные хранятся внутри в устройстве и, таким образом, этот тип данных никогда не появляется непосредственно ни в каком определении протокола

Данный атрибут определяет данные сегмента, переданные в качестве матрицы записей в формате, указанном атрибутом PM-Segment-Entry-Map. Здесь он определен в качестве прозрачной структуры данных без определенного типа данных. Обратите внимание, что данный атрибут доступен опосредованно; он извлекается менеджером при помощи метода PM-блока Trig-Segm-Data-Xfer

M

Confirm-Timeout

MDC_ATTR_CONFIRM_TIMEOUT

RelativeTime

Данный атрибут информационного тайм-аута определяет минимальное время, в течение которого агент должен ожидать сообщения ответа от менеджера после выдачи сообщений запроса Подтвержденного Отчета о Событиях до тайм-аута и перевода в неассоциированное состояние. Это информационный атрибут в пользу менеджера. Если поставляется данный атрибут, он должен соответствовать текущему значению тайм-аута, который используется агентом для Подтвержденного Отчета о Событиях, выдаваемого объектом PM-блока. Данный атрибут является информационным для менеджера в том смысле, что менеджер не использует данный атрибут в текущей реализации протокола (т.e. менеджер не производит тайм-аут на Подтвержденный Отчет о Событиях, сгенерированный агентом). Однако менеджер может пожелать использовать данную информацию для назначения приоритетов обработки агента "короткого" тайм-аута над агентом "долгого" тайм-аута

O

Transfer-Timeout

MDC_ATTR_TRANSFER_TIMEOUT

RelativeTime

Данный атрибут тайм-аута определяет минимальное время, в течение которого менеджер ждет полной передачи информации PM-сегмента. Если тайм-аут закончится до получения полного PM-сегмента, менеджер должен совершить передачу в неассоциированном состоянии в соответствии с описанием в п.8.9.5.6

M


Атрибут Fixed-Segment-Data хранит матрицу записей единого формата. В случаях, когда измерение не может быть предоставлено за требуемый период времени, значение для числового измерения предоставленного типом данных (S) FLOAT-type должно использовать специальное значение NaN (не число), чтобы указать на то, что значение не доступно.

Атрибут Fixed-Segment-Data может удерживать достаточно большие объемы данных в зависимости от возможностей и применения агента. Агент может ограничить максимальный размер атрибута Fixed-Segment-Data, чтобы таким образом выровнять его с максимальным размером блока передачи транспортной системы. Чтобы поддерживать данный тип поведения, менеджер должен быть в состоянии поддерживать передачу атрибутов Fixed-Segment-Data сообщений многократного использования.

6.3.8.4 Методы объекта PM-segment

Нет

6.3.8.5 События объектов PM-segment

Нет

6.3.8.6 Другие сервисы PM-segment

Нет

6.3.9 Классы сканера

6.3.9.1 Общая информация

Объект сканера является наблюдателем и "сумматором" значений атрибутов объекта. Он наблюдает атрибуты метрических объектов (например, числовые объекты) и генерирует сводки в форме отчетов о событиях. См. на рисунке 5 иерархию классов сканера. Каждый класс описан в 6.3.9.2-6.3.9.5 соответственно.


Рисунок 5 - Персональный медицинский прибор. DIM. Модель сканера


Должны использоваться различные классы сканера (периодические и эпизодические), а также различные экземпляры для распространения данных различных типов по одному или нескольким потокам данных, представленных экземпляром сканера. Приложение пульсовой оксиметрии может выбрать периодический конфигурируемый сканер для объектов RT-SA с интервалом отправки отчета каждые 50 мс, периодический конфигурируемый сканер с интервалом сообщения отчета в 1 сек для числовых объектов и объектов перечисления, а также конфигурируемый эпизодический сканер для импульсных метрических объектов (числовых объектов и объектов перечисления).

6.3.9.2 Класс сканера

6.3.9.2.1 Общая информация

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

Концепт сканера обеспечивает три разных сообщения отчета о событиях: переменный формат, фиксированный формат и сгруппированный формат. См. в 7.4.5 информацию о сообщениях атрибутов наблюдаемых объектов. Форматы отчетов о событиях описаны ниже в 6.3.9.4.5, 6.3.9.5.5 и A.11.5, соответственно.

Более специализированные классы сканера происходят от базового класса сканера.

6.3.9.2.2 Идентификация класса сканера

Номенклатурный код для идентификации класса сканера: MDC_MOC_SCAN.

6.3.9.2.3 Атрибуты класса сканера

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


Таблица 13 - Атрибуты сканера

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Handle

MDC_ATTR_ID_HANDLE

HANDLE

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

М

Operational-State

MDC_ATTR_OP_STAT

OperationalState

Данный атрибут определяет, активен ли сканер и может ли он быть установлен менеджером

М

Scan-Handle-List

MDC_ATTR_SCAN_HANDLE_LIST

HANDLEList

Данный атрибут определяет объекты с метрическим происхождением, которые могут сообщаться в отчетах Unbuf-Scan-Report-Var, Buf-Scan-Report-Var, Unbuf-Scan-Report-Fixed, Buf-Scan-Report-Fixed или в любом из четырех эквивалентов нескольким лицам. В случае эпизодических сканеров, специальный объект включается в отчет о событиях, как только вносятся изменения одного или нескольких значений атрибута. В случае периодических сканеров, сканируемые объекты и значения атрибутов вносятся в каждый из периодов. Менеджер не должен принимать порядок объектов, содержащихся в отчетах о событиях. Порядок совпадает со списком Scan-Handle-List. Данный атрибут должен предоставить информацию, используется ли сканером какой-либо из восьми стилей отчетов

С

Scan-Handle-Attr-Val-Map

MDC_ATTR_SCAN_HANDLE_ATTR_VAL_MAP

HandleAttrValMap

Данный атрибут определяет метрические производные объекты, атрибуты и порядок, значения объектов и атрибутов которого сообщаются в Unbuf-Scan-Report-Grouped, Buf-Scan-Report-Grouped, Unbuf-Scan-Report-MP-Grouped или Buf-Scan-Report-MP-Grouped.

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

С

6.3.9.2.4 Методы объектов сканера

Нет

6.3.9.2.5 События объекта сканера

См. описания события производного класса в 6.3.9.4.5 и 6.3.9.5.5.

6.3.9.2.6 Другие сервисы сканера

Сервис SET

Агенты, которые обладают производными объектами сканера должны поддерживать набор сервисов атрибута Operational-State объектов сканера.

6.3.9.3 Класс CfgScanner

6.3.9.3.1 Общая информация

Класс CfgScanner является абстрактным классом, определяющим атрибуты, методы, события и сервисы, которые являются типичными для его подклассов. В частности, он определяет коммуникационное поведение объекта настраиваемого сканера. Будучи таковым, он не может инстанцироваться.

6.3.9.3.2 Идентификация класса конфигурируемого сканера

Номенклатурный код для идентификации класса конфигурируемого сканера: MDC_MOC_SCAN_CFG.

6.3.9.3.3 Атрибуты класса конфигурируемого сканера

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


Таблица 14 - Атрибуты конфигурируемого сканера

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Confirm-Mode

MDC_ATTR_CONFIRM_MODE

ConfirmMode

Данный атрибут определяет, являются ли пересланные отчеты о событиях подтвержденными или неподтвержденными

М

Confirm-Timeout

MDC_ATTR_CONFIRM_TIMEOUT

RelativeTime

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

С

Transmit-Window

MDC_ATTR_TX_WIND

INT-U16

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

О


Рисунок 6 демонстрирует выполнение вспомогательной очереди передачи, когда значение Transmit-Window более чем 1.


Рисунок 6 - Работа окна передачи (Transmit-Window) конфигурируемого сканера

6.3.9.3.4 Методы объекта конфигурируемого сканера

Нет

6.3.9.3.5 События объекта конфигурируемого сканера

См. описания событий производного класса в 6.3.9.4.5 и п.6.3.9.5.5.

6.3.9.3.6 Другие события конфигурируемого сканера

Нет

6.3.9.4 Класс EpiCfgScanner

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

Класс EpiCfgScanner представляет собой класс, который может инстанцироваться. Объекты EpiCfgScanner используются для отправки отчетов, содержащих эпизодические данные, то есть данные, не имеющие фиксированного периода между каждым значением данных. Отчет пересылается, как только один из наблюдаемых атрибутов меняет значение; однако временной интервал между двумя последовательными отчетами о событиях не должен быть меньше значения атрибута Min-Reporting-Interval.

6.3.9.4.2 Идентификация класса эпизодического конфигурируемого сканера

Номенклатурный код для идентификации класса эпизодического конфигурируемого сканера: MDC_MOC_SCAN_CFG_EPI.

6.3.9.4.3 Атрибуты класса эпизодического конфигурируемого сканера

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


Таблица 15 - Атрибуты эпизодического конфигурируемого сканера

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Min-Reporting-Interval

MDC_ATTR_SCAN_REP_PD_MIN

RelativeTime

Данный атрибут предоставляет расчет ожидаемого минимального времени между двумя последовательными отчетами о событиях

О

6.3.9.4.4 Методы объекта эпизодического конфигурируемого сканера

Нет

6.3.9.4.5 События объекта эпизодического конфигурируемого сканера

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


Таблица 16 - События объекта эпизодического конфигурируемого сканера

Событие

Режим

Тип события

Параметр информации о событиях

Инфор-
мация об ответе

Unbuf-Scan-Report-Var

подтвержденный или неподтвержденный

MDC_NOTI_UNBUF_SCAN_REPORT_VAR

ScanReportInfoVar

-

Unbuf-Scan-Report-Fixed

подтвержденный или неподтвержденный

MDC_NOTI_UNBUF_SCAN_REPORT_FIXED

ScanReportInfoFixed

-

Unbuf-Scan-Report-Grouped

подтвержденный или неподтвержденный

MDC_NOTI_UNBUF_SCAN_REPORT_GROUPED

ScanReportInfoGrouped

-

Unbuf-Scan-Report-MP-Var

подтвержденный или неподтвержденный

MDC_NOTI_UNBUF_SCAN_REPORT_MP_VAR

ScanReportInfoMPVar

-

Unbuf-Scan-Report-MP-Var

подтвержденный или неподтвержденный

MDC_NOTI_UNBUF_SCAN_REPORT_MP_FIXED

ScanReportInfoMPFixed

-

Unbuf-Scan-Report-MP-Grouped

подтвержденный или неподтвержденный

MDC_NOTI_UNBUF_SCAN_REPORT_MP_GROUPED

ScanReportInfoMPGrouped

-

Примечания

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

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


Событие Unbuf-Scan-Report-Var

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

Событие Unbuf-Scan-Report-Fixed

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

Событие Unbuf-Scan-Report-Grouped

Стиль данного события используется, когда используется объект сканера для пересылки данных в их наиболее компактном формате. Атрибут Handle-Attr-Val-Map описывает включенные объекты и атрибуты, а также формат сообщения.

Событие Unbuf-Scan-Report-MP-Var

Стиль данного события полностью совпадает с Unbuf-Scan-Report-Var, но позволяет также включение данных от нескольких лиц.

Событие Unbuf-Scan-Report-MP-Fixed

Стиль данного события полностью совпадает с Unbuf-Scan-Report-Fixed, но позволяет также включение данных от нескольких лиц.

Событие Unbuf-Scan-Report-MP-Grouped

Стиль данного события полностью совпадает Unbuf-Scan-Report-Grouped, но позволяет также включение данных от нескольких лиц.

6.3.9.4.6 Другие сервисы эпизодически конфигурируемого сканера

Нет.

6.3.9.5 Класс PeriCfgScanner

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

Класс PeriCfgScanner представляет собой класс, из которого могут быть созданы экземпляры. Объекты PeriCfgScanner используются для пересылки отчетов, содержащих периодические данные, то есть данные, полученные в установленные периоды. Он буферизует любые изменения значений данных, которые должны пересылаться как часть периодического отчета. Отчеты о событиях должны пересылаться с временным интервалом, равным значению атрибута Reporting-Interval.

Количество наблюдений для каждого метрического объекта зависит от интервала обновления метрического объекта и интервала сообщения отчета сканера.

Пример - Периодически конфигурируемый сканер установлен на "сканирование" двух метрических объектов с интервалом сообщения отчетов в 1 сек. Два объекта периодически обновляют их соответствующие наблюдаемые значения с интервалом в 1 сек и сек, соответственно. Затем периодически конфигурируемый сканер выпускает отчеты о событиях каждую секунду, сообщая один скан наблюдения метрического объекта #1 и два скана наблюдения метрического объекта #2.

6.3.9.5.2 Идентификация объекта периодического конфигурируемого сканера

Номенклатурный код для идентификации класса периодического конфигурируемого сканера: MDC_MOC_SCAN_CFG_PERI.

6.3.9.5.3 Атрибуты объекта периодического конфигурируемого сканера

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


Таблица 17 - Атрибуты объекта периодического конфигурируемого сканера

Название атрибута

ID атрибута

Тип атрибута

Комментарий

Клатор

Reporting-Interval (интервал отправки отчета)

MDC_ATTR_SCAN_REP_PD

RelativeTime

Период сообщения отчета о событии

М

6.3.9.5.4 Методы объекта периодического конфигурируемого сканера

Нет

6.3.9.5.5 События объекта периодического конфигурируемого сканера

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


Таблица 18 - События объекта периодического конфигурируемого сканера

Событие

Режим

Тип события

Event-info parameter

Event-reply-info

Buf-Scan-Report-Var

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_REPORT_VAR

ScanReportInfoVar

-

Buf-Scan-Report-Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_REPORT_FIXED

ScanReportInfoFixed

-

Buf-Scan-Report-Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_REPORT_GROUPED

ScanReportInfoGrouped

-

Buf-Scan-Report-MPVar

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_REPORT_MP_VAR

ScanReportInfoMPVar

-

Buf-Scan-Report-MPFixed

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_REPORT_MP_FIXED

ScanReportInfoMPFixed

-

Buf-Scan-Report-MPGrouped

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_REPORT_MP_GROUPED

ScanReportInfoMPGrouped

-


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

6.3.9.5.6 Другие сервисы периодического конфигурируемого сканера

Нет.

     6.4 Правила расширения информационной модели


Информационная модель расширяет свою сферу применения при помощи дополнительных атрибутов объектов для объектов, определенных в настоящем стандарте, определенных в ИСО/ИИЭР 11073-10201 [13].

Другим возможным расширением может стать использование частных (например, специфицированных производителем) атрибутов объектов и/или методов для объектов, определенных в настоящем стандарте. Частные атрибуты должны идентифицироваться путем присвоения номенклатурных кодов из частного пространства нумерации (0xF000 - 0xFFFF) в рамках соответствующего раздела в соответствии с ИСО/ИИЭР 11073-10101 [12].

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

     7 Сервисная модель персонального медицинского прибора

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


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

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

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

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

- протокол, при использовании правил MDER, позволяет агентам хранить заранее определенные шаблоны передачи и изменять только стабильное размещение, изменяя детали до отправки.

     7.2 Сервис ассоциации


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

- Запрос Ассоциации устанавливает соединение верхнего уровня над существующим транспортным соединением;

- Ответ на Ассоциацию принимает Запрос на Ассоциацию, если соединение двунаправленное;

- Запрос на Разъединение корректно завершает ассоциацию верхнего уровня;

- Ответ на Разъединение подтверждает завершение ассоциации верхнего уровня, если соединение двунаправленное;

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

     7.3 Сервисы доступа к объектам


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

Поддерживаются следующие сервисы доступа обобщенного объекта:

- сервис GET: используется менеджером для извлечения значений объекта MDS агента и атрибутов PM-блока. Список атрибутов объекта системы MDS указан в 6.3.2.3, список атрибутов PM-блока указан в 6.3.7.3;

- сервис SET: используется менеджером для установки значений атрибутов объекта агента. Как правило, только объекты сканера поддерживают сервис SET (см. 6.3.9.2.6);

- сервис EVENT REPORT: используется агентом для пересылки обновлений конфигурации и измерительных данных менеджеру. Список отчетов о событиях указан в 6.3.2.5, 6.3.7.5, 6.3.9.4.5 и 6.3.9.5.5;

- сервис ACTION: используется менеджером для запуска действий (или методов), поддерживаемых агентом. Примером служит действие MDS-Data-Request, используемая для запроса измерительных данных у агента. Список методов указан в 6.3.2.4 и 6.3.7.4.

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

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

- агент находится в состоянии ассоциации и сервис GET ссылается на объект MDS.

Менеджер, получающий подтвержденный отчет о событиях от агента, должен ответить либо rors-cmipconfirmed-event-report, либо соответствующим сообщением об ошибке roer с подходящим обратным кодом.

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

     7.4 Специальная реализация доступа к объекту сервисов EVENT REPORT для персональных медицинских приборов

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

Сервис EVENT REPORT является главным механизмом для агента посылающим отчеты как о данных измерений так и о данных конфигурации. Отчеты о событиях в настоящем стандарте являются собственностью системы MDS и объектов сканера. Такие особые отчеты о событиях могут иметь разные формы и свойства, в соответствии с 7.4.2 по 7.4.7.

7.4.2 Подтвержденные и неподтвержденные отчеты о событиях

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

7.4.3 Отчеты о событиях конфигураций

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

Подпункты 7.4.3.2-7.4.3.4 описывают конфигурации, отчеты о событиях конфигураций, и специализации прибора, используемые для описания объектов в агенте.

7.4.3.2 Конфигурация прибора-агента

Набор объектов и атрибутов, который существует в агенте, обозначает конфигурацию агента и ассоциируется со значением Dev-Configuration-Id (см. таблицу 2). В случае если агент обладает множественными конфигурациями прибора, присвоенные значения Dev-Configuration-Id должны быть локально-уникальными. В течение срока работы ассоциации, конфигурация агента должна оставаться стабильной, то есть набор объектов должен оставаться неизменным. Однако агент может добавить новые атрибуты объекту или изменить значения атрибута в соответствии с 7.4.3.3. Агент, который запрашивает другую конфигурацию, должен остановить ассоциацию и установить новую ассоциацию с желаемой конфигурацией.

7.4.3.3 Отчет о событиях конфигураций

Конфигурация, которую агент желает использовать во время ассоциации с менеджером, указывается при помощи значения Dev-Configuration-Id для поля dev-config-id в сообщении Запрос ассоциации. Если менеджер еще не знаком с конфигурацией прибора-агента (например, на основе предыдущих фаз ассоциации), менеджер запрашивает конфигурацию прибора агента. Агент направляет свои конфигурации менеджеру при помощи отчета о событиях конфигураций. Отчет описывает все объекты конфигурации прибора агента вместе с ассоциированным значением Dev-Configuration-Id. В течение ассоциации, конфигурации агента остаются стабильными в отношении количества объектов. В случае если агент намеревается использовать другую конфигурацию или желает изменить текущую конфигурацию путем добавления или удаления объектов, агент должен прервать ассоциацию и произвести новую ассоциацию с новой конфигурацией. Для каждого объекта конфигурация должна содержать также атрибуты, используемые данным объектом. Обычно, редко изменяемые атрибуты включаются в отчет конфигурации, а динамические значения как, например, измерения, пересылаются в последующих отчетах об измерениях. Агент может добавлять новые атрибуты объекту или изменять значения атрибутов в ходе ассоциации без пересылки новой конфигурации. Добавление новых атрибутов может случиться только при помощи отчета о событиях переменного формата (см. 7.4.5 для подробной информации о форматах отчетов о событиях). Изменяемые значения атрибутов могут использовать переменные, фиксированные или групповые отчеты о событиях в зависимости от конфигурации.

Изменения, вносимые в текущую конфигурацию, как стандартную, так и расширенную, имеют силу только в течение той ассоциации, и не считаются устойчивым изменением конфигурации. Следовательно, Dev-Configuration-Id представляет собой конфигурацию, согласованную на время конфигурации. В последующих ассоциациях, когда указывается ранее используемый Dev-Configuration-Id, текущая конфигурация не включает каких-либо изменений, внесенных в ходе предыдущей ассоциации. Устойчивые изменения конфигурации могут быть внесены только после установления новой ассоциации и указания другого Dev-Configuration-Id, и желаемой новой конфигурации во время настройки.

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

7.4.3.4 Специализации прибора

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

7.4.3.5 Типы конфигурации

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

7.4.3.5.1 Стандартная конфигурация

Стандартная конфигурация - это конфигурация, оговоренная в одной из специализации ИСО/ИИЭР 11073-104zz и со значением Dev-Configuration-Id, присвоенным из диапазона между standard-config-start и standardconfig-end, включительно. Этот диапазон ниже подразделен, резервируя 100 ID на каждую специализацию ИСО/ИИЭР 11073-104zz в диапазоне от zz100 до zz100+99, включительно. Например, диапазон 1500-1599 зарезервирован под ИИЭР Std 11073-10415 [B4]. Все неиспользуемые значения в стандартном диапазоне зарезервированы под будущее использование. Менеджер, который поддерживает одну из специализаций прибора ИСО/ИИЭР 11073-104zz, знаком со всеми конфигурациями стандартных приборов, указанных в конкретной специализации. Каждый раз, как агент запрашивает ассоциацию с менеджером при помощи значения Dev-Configuration-Id стандартной конфигурации, менеджер может принять ассоциацию без необходимости запроса конфигураций агента, т.к. они уже известны. После успешной ассоциации менеджер и агент входят в режим Работы.

Важно отметить, что при наличии запроса приборы со стандартными конфигурациями должны отправлять свои конфигурации. Это требование покрывает случай, когда агент ассоциируется с менеджером, в который не была встроена информация о стандартных конфигурациях (например, версия менеджера 1.0, а специализация прибора - версия 2.0 и выше). Способность менеджера применять конфигурации зависит от реализации менеджера.

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

7.4.3.5.2 Расширенная конфигурация

При расширенных конфигурациях, конфигурация агента не является стандартной; он может иметь различный набор объектов, различные атрибуты и/или различные значения атрибутов. Расширенная конфигурация(-ии) применения агента должна выбрать уникальное значение Dev-Configuration-Id из диапазона между extended-configstart и extended-config-end, включительно для каждой расширенной конфигурации. За время ассоциации агент отправляет Dev-Configuration-Id для определения конфигурации, выбранной агентом, на период проведения ассоциации. Если менеджер уже понимает эту конфигурацию, либо потому, что она была загружена ранее при помощи программы установки, либо потому, что агент ранее устанавливал ассоциацию с менеджером, то менеджер должен ответить принятием конфигурации без необходимости пересылки дальнейшей информации о конфигурациях.

Однако, если менеджер не знаком с конфигурацией агента, менеджер должен ответить реакцией accepted-unknown-config, после чего агент должен передать информацию о своих конфигурациях, отправляя отчет о событии конфигурации. См. 8.7 и 8.8 для подробной информации о процедурах ассоциации и конфигурации. Как только менеджер получает конфигурацию, агент может передать измерительные данные. Для экономии времени ассоциации, агентом должен использоваться тот же Dev-Configuration-Id для последующих ассоциаций при условии неизменности конфигурации прибора.

В отличие от стандартных конфигураций, два агента с одинаковым расширенным Dev-Configuration-Id не обязательно представляют одну и ту же конфигурацию. Менеджер должен различать расширенные конфигурации на базе каждого агента. System-Id агента может использоваться для различия расширенных конфигураций, т.к. System-Id является обязательной и должна быть уникальной, и высылается во время ассоциации; однако вместо них могут использоваться другие техники, как например, производитель/модель/серийный номер, только если они не вынуждают менеджера использовать некорректную конфигурацию для агента.

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

7.4.4 Передача измерительных данных, инициируемая агентом или менеджером

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

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

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

________________

* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.


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

7.4.5 Переменный, фиксированный и групповой форматы отчетов о событиях

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

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

Фиксированный формат отчета о событиях оптимизирован, за счет определения формата сообщения в карте Attribute-Value-Map объекта в предыдущих сообщениях конфигурации до начала пересылки. Когда агент передает данные в фиксированном формате отчета о событиях, он должен сообщать дескриптор объекта и значения атрибута в порядке и размере, указанном в карте значений атрибута Attribute-Value-Map. Таким образом, предотвращается расход операции при отправке идентификации и длины атрибута в каждом отчете о событиях. По получении отчета о событиях в фиксированном формате, менеджер использует дескриптор объекта для извлечения карты Attribute-Value-Map, выданной ранее во время конфигурации, чтобы получить информацию о способе извлечения данных.

Групповой формат отчета о событиях оптимизирован дополнительно за счет определения формата сообщения, содержащего один и более объектов, в объекте сканера Handle-Attr-Val-Map в отдельном сообщении конфигурации до начала передачи. Когда агент передает данные в групповом фиксированном формате отчета о событиях, он должен сообщать дескриптор объекта сканера вместе со значениями атрибута объектов в порядке и размере, указанном в карте значений атрибута Handle-Attr-Val-Map. Таким образом, предотвращаются издержки операции при отправке дескрипторов объекта сканера, идентификации атрибута и длины данных в каждом отчете о событиях. По получении отчета о событиях в групповом формате, менеджер использует дескриптор объекта сканера для извлечения карты the Handle-Attr-Val-Map, выданной ранее во время конфигурации, чтобы получить информацию о способе извлечения данных.

Менеджер должен поддерживать переменный формат, фиксированный формат и групповой формат отчетов о событиях. Агент может поддерживать любой или все отчеты о событиях с переменным форматом, фиксированным форматом и групповым форматом. Менеджер определяет, какой из форматов может использовать агент, проверяя карты объектов Attribute-Value-Map, определенной в MDSConfiguration-Event от агента или проверяя атрибут Handle-Attr-Val-Map на объекты сканера, определенных в MDS-Configuration-Event.

7.4.6 Отчеты о событиях одного и нескольких лиц

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

Менеджер должен поддерживать отчеты о событиях как для одного, так и нескольких лиц. Агент может поддерживать, как только один из этих вариантов, так и оба варианта отчета о событиях для одного и нескольких лиц. В A.11.5 описаны форматы для отчетов о событиях одного или нескольких лиц.


Рисунок 7 - Связи переменного, фиксированного и группового формата

7.4.7 Временно хранимые измерения

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

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


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

- только объекты с метрическим происхождением, не являющиеся RT-SAs (например, числовые объекты и объекты перечисления), поддерживаются как временно хранимые измерения;

- использование атрибутов временных отрезков (т.е. Date-and-Time, Relative-Time или HiRes-Relative-Time) требуется для временно хранимых измерений;

- агент не должен пересылать временно хранимые измерения, если известно, что временной отрезок не соблюдается (например, если временная база, используемая для отсчета временного отрезка значений, притерпела между* измерениями изменения значительные для типа измерения), если только он не включает соответствующие настройки Date-and-Time-Adjustment в начале отчета о событии;

________________     

* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.


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

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

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

     8 Модель коммуникаций

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


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

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

     8.2 Контекст системы


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

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


Рисунок 8 - Контекст системы


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

- Тип 1. Транспортные профили, содержащие "надежные" и "лучшие из возможных" транспортные сервисы, в которых должен быть один или несколько виртуальных каналов "надежных" транспортных сервисов и ноль или более виртуальных каналов "лучших из возможных" транспортных сервисов;

- Тип 2. Транспортные профили, содержащие только однонаправленные транспортные сервисы;

- Тип 3. Транспортные профили, содержащие только "лучшие из возможных" транспортные сервисы, в которых должен быть один или несколько виртуальных каналов "лучших из возможных" транспортных сервисов.

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

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

     8.3 Коммуникационные характеристики

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

В настоящем стандарте должен быть использован транспортный профиль 1-го типа.

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

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

- все сообщения, относящиеся к процедуре ассоциации:

- aare, aarq, rlre, rlrq, abrt;

- все сообщения, относящиеся к утвержденному сервисному механизму:

- prst.roiv-cmip-confirmed-action, prst.roiv-cmip-confirmed-event-report, prst.roiv-cmip-get, prst.roiv-cmip-confirmed-set;

- prst.rors-cmip-confirmed-action, prst.rors-cmip-confirmed-event-report, prst.rors-cmip-get, prst.rors-cmip-confirmed-set;

- все сообщения, относящиеся к условиям сбоя, аварийным условиям:

- roer, rorj.

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

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

- prst.roiv-cmip-action, prst.roiv-cmip-event-report, prst.roiv-cmip-set

Как правило, термин метаданные означает данные о данных. В контексте коммуникационных характеристик ИСО/ИИЭР 11073-20601, термин метаданные означает подтверждающую информацию или данные, относящиеся к пакету данных протокола прикладного уровня (APDU). Примеры включают следующее:

- специфический транспортно-технологический адрес для передачи данного пакета APDU данному агенту или менеджеру;

- надежность и/или скрытость, необходимая для данного пакета APDU;

- размер или длина данного пакета APDU.

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

- APDU-metadata.address (для конечной точки USB)=1-1023;


Рисунок 9 - Общая модель коммуникации


- APDU-metadata.address (для сети IPv4)=0.0.0.0-255.255.255.255;

- APDU-metadata.size=1-64512.

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

- APDU-metadata.latency=(10ms | 100ms | 1sec | 10sec);

- APDU-metadata.reliability=(high | medium | low);

- APDU-metadata.bandwidth=(100 бит/с | 1 Кбит/с | 10 Кбит/с | 100 Кбит/с | 1 Мбит/с).

В последующих подразделах описываются общие характеристики (см. 8.3.2) и уникальные характеристики надежных (см. 8.3.3) лучших из возможных (см. 8.3.4) виртуальных каналов применительно к настоящему стандарту.

8.3.2 Общие коммуникационные характеристики

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

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

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

c) пакеты данных APDU, отправляемые от агента к менеджеру, должны составлять не более 63 Кбайт (64512). Особые специализации устройств или реализации могут оценить сообщения, переданные с целью определения конкретного размера реализации для приемного буфера менеджера, меньшего, чем максимальный размер пакета APDU, переданного от агента к менеджеру. Если менеджер получает больший по размеру пакет данных APDU, то он должен ответить, указав код ошибки (Roer) из протокола-нарушения;

d) пакеты данных APDU, отправляемые от менеджера к агенту, должны составлять не более 8 Кбайт (8192). Особые специализации устройств или реализации могут анализировать сообщения, которыми обмениваются с целью определения конкретного размера реализации для приемного буфера агента, меньшего, чем максимальный размер пакета APDU, передаваемый от менеджера к агенту. Если агент получает больший пакет данных APDU, то он должен ответить, указав код ошибки (Roer) из протокола-нарушения;

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

f) коммуникационные уровни должны указывать общую длину пакета данных APDU аналогичному коммуникационному уровню.

8.3.3 Характеристика надежных коммуникаций

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

a) пакеты данных APDU должны быть получены в том же порядке, в котором были отправлены;

b) пакеты данных APDU не должны содержать обнаруживаемых ошибок;

c) Пакеты данных APDU не должны копироваться;

d) Пакеты данных APDU не должны быть утеряны;

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

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

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

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

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

j) управление потоком между отправляющим и получающим приложением должно поддерживаться для полного пакета APDU. Нижние слои могут реализовать управление потоком для небольших подклассов APDU.

8.3.4 Характеристика лучших из возможных коммуникаций

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

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

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

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

     8.4 Конечные автоматы

8.4.1 Конечный автомат агента

На рисунке 10 представлен общий вид конечного автомата агента.

Подробная таблица состояний агента описана в приложении E.2.

В таблице 19 дано описание каждого состояния.

В таблице 20 дано описание каждого изменения состояния.


Рисунок 10 - Диаграмма конечного автомата агента



Таблица 19 - Описание состояний агента

Состояние

Описание

Разъединен

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

Соединен

Когда транспортное соединение установлено, агент получает индикацию транспортного соединения из транспортного уровня, вызывая переход в состояние соединения (см. 8.4.3). Агент остается в состоянии соединения, пока транспортное соединение установлено. Изначально агент начинает работу в неассоциированном состоянии, в подсостоянии состояния соединения

Неассоциированный

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

- новое соединение было только что установлено;

- менеджер отвергает запрос на ассоциацию;

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

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

Ассоциирование

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

Ассоциированный

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

Выполнение

Когда менеджер признает конфигурацию агента, он информирует его, посылая ответ на ассоциацию с параметром "accepted", чтобы перевести агента в рабочее состояние. В ином случае, если конфигурация не признана, она передается. Если конфигурация будет принята, агент переходит в состояние выполнения. См. 8.9 для получения описания возможных процедур в состояние выполнения

Конфигурирующее

Когда менеджер не признает конфигурацию агента, он информирует его, посылая ответ на ассоциацию с параметром "accepted-unknown-config", с целью указать, что ассоциация была принята, но, что конфигурация должна быть передана. Агент остается в конфигурирующем состоянии до тех пор, пока агент не передаст информацию о конфигурации и менеджер признает конфигурацию (см. 8.7.6)

Завершение ассоциации

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



Таблица 20 - Описание изменения состояний агента

Состояние

Описание

Индикация транспортного соединения

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

assocReq

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

RxAssocRsp (принята или принята-неизвестная-конфигурация)

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

RxAssocRsp (отклонено)

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

RxAssocRelReq/TxAssocRelRsp

Если агент связан с менеджером и получает запрос на выпуск ассоциации, агент отвечает и переходит в состояние разъединения

RxAssocAbort или TxAssocAbort

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

assocRelReq

Когда агент решает прекратить ассоциацию, он переходит в состояние разъединения и посылает запрос на выпуск ассоциации. Этот переход используется при обычной последовательности отключения путем отправки ReleaseRequestReason при обычных условиях, или, если конфигурация агента изменилась и ему необходимо прервать ассоциацию, агент использует ReleaseRequestReason об изменении конфигурации.

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

RxAssocRelRsp

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

Индикация разъединения передачи данных

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

8.4.2 Конечный автомат менеджера

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

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

- если менеджер не принимает конфигурацию, он должен послать ответ на конфигурацию с результатом - unsupported-config;

- если менеджер принимает конфигурацию, он должен отправить ответ на конфигурацию с указанием результата - accepted-config.

Подробная таблица о состояниях менеджера приведена в приложении E.3.


Рисунок 11 - Диаграмма конечного автомата менеджера

     8.4.3 Переменные тайм-аута


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


Таблица 21 - Переменные тайм-аута


Коммуникационные сервисы

Тайм-аут

Подраздел



Переменная

Значение


Процедура ассоциации


Ассоциация

TO

10с (и RC=3)

8.7.5


Конфигурация

TO

10с

8.8.5


Выпуск ассоциации

TO


8.10.5

Процедура работы

Объект системы мед. прибора (MDS)

Подтвержденное действие

ТО


8.9.5.2


Подтвержденный отчет о событии

TO

Подтвержденный тайм-аут MDS

8.9.5.3


Получение

TO


8.9.5.4


Подтвержденная установка

TO


8.9.5.5


<inter-service timeout>

TO


8.9.5.6

Объекты хранения PM

Подтвержденное действие

ТО


8.9.5.2


Подтвержденный отчет о событии

TO

Подтвержденный тайм-аут сегмента

8.9.5.3


Получение

TO


8.9.5.4


Подтвержденная установка

TO


8.9.5.5


<end of Segm timeout>

TO

Тайм-аут передачи сегмента

8.9.5.6


Подтвержденное действие - SegmClear

TO

Тайм-аут очистки сегмента

8.9.5.6

Объект сканера

Подтвержденная установка

TO


8.9.5.5


Подтвержденный отчет о событии

TO

Подтвержденный тайм-аут сканера

8.9.5.3

     

     8.5 Процедура соединения

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

В 8.5.2-8.5.5 описываются условия входа, нормальные процедуры, условия выхода, и условия ошибок, которые могут возникнуть в состоянии Соединен в диаграммах состояний.

8.5.2 Условия входа

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

8.5.3 Нормальные процедуры

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

8.5.4 Условия выхода

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

8.5.5 Условия возникновения ошибок

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

     8.6 Неассоциированная процедура

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

В 8.6.2-8.6.5 описываются условия входа, нормальные процедуры, условия выхода, и условия ошибок, которые могут возникнуть для состояния не ассоциирован в диаграммах состояния.

8.6.2 Условия входа

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

8.6.3 Нормальные процедуры

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

8.6.4 Условия выхода

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

8.6.5 Условия возникновения ошибок

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

     8.7 Ассоциированная процедура

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

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

8.7.2 Условия входа

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

8.7.3 Нормальные процедуры

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

В 8.7.3.1-8.7.3.2 описываются условия работы для ролей двух разных устройств: агента и менеджера.

8.7.3.1 Процедура агента

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

Когда агент намерен создать ассоциацию, он должен начать с перехода в состояние Ассоциации и отправить сообщение с запросом ассоциации менеджеру. Определение AarqApdu (см. А.8) поясняет формат сообщения с запросом ассоциации. Пример запроса ассоциации см. в H.2.1.1.

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

- версию используемого протокола ассоциации (assoc-version). Это поле позволяет агенту и менеджеру убедиться в том, что они используют одну и ту же версию протокола обмена;

- перечень протоколов передачи данных, которые поддерживает агент (data-proto-list). Агенту разрешено поддерживать один или несколько протоколов передачи данных для обмена информацией. Агент должен заказать перечень протоколов передачи данных, начиная с наиболее предпочтительного протокола, и заканчивая наименее предпочтительным протоколом.

Менеджер выбирает предпочтительный протокол и сообщает об этом агенту.


Рисунок 12 - Ассоциированная процедура (известная конфигурация)


 
Рисунок 13 - Ассоциированная процедура (неизвестная конфигурация)


Чтобы разрешить выбор протокола передачи данных в ходе ассоциации, перечень data-proto-list содержит идентификатор, который обозначает, что протокол данных определяется одним стандартом из серии ИСО/ИИЭР 11073 или определяется производителем. Эти параметры описаны в двух следующих подразделах. Дополнительные коды доступны, но сохранены для будущих расширений.

8.7.3.1.2 Протокол обмена данными, определенный настоящим стандартом

Если агент устанавливает data-proto-id в А.8 до data-proto-id-20601, то он должен придерживаться абстрактных определений синтаксиса, содержащихся в настоящем стандарте для типов данных и обмена сообщениями. Кроме того, поле data-proto-info заполняется вместе со структурой PhdAssociationInformation, которая определяет следующую информацию:

- версия протокола обмена данными;

- конкретное правило(а) кодирования DataApdu, поддерживающиеся агентом. Агент должен установить один или несколько битов encoding-rules:

- агент должен всегда поддерживать правила MDER (правила кодирования медицинских приборов), т.е. бит MDER в поле encoding-rules должен устанавливаться агентом;

- агент может предложить другие правила кодирования, помимо MDER, менеджеру, установив другие биты в поле encoding-rules;

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

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

- тип системы (в данном случае агента);

- уникальный идентификатор System-Id (см. таблицу 2) агента. Формат EUI-64 используется для идентификации агента. Менеджер может использовать это поле для определения идентификации агента, с которым он осуществляет коммуникацию и, возможно, для реализации простой политики ограничения доступа;

- dev-config-id, обозначающий текущую конфигурацию агента, описан в разделе 7.4.3. Значение dev-config-id для стандартных конфигураций должно находиться между standard-config-start и standard-config-end, включительно. Для расширенных конфигураций, значение dev-config-id должно находиться между extended-config-start and extended-config-end включительно;

- data-req-mode-capab, который определяет режимы запроса данных, поддерживаемые агентом (см. 8.9.3.3.3);

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

8.7.3.1.3 Протокол обмена данными, определенный производителем

Другие спецификации могут использовать первоначальный запрос на ассоциацию с целью договориться об использовании протоколов, определенных производителем. В этом случае агент устанавливает data-proto-id в А.8 до data-proto-id-external. Чтобы различать многие возможные протоколы, определенные изготовителем, агент использует информационную структуру ManufSpecAssociation, чтобы предоставить УУИд (универсально уникальный идентификатор), который обозначает конкретный протокол.

Реальное поведение протокола за пределами изначальной ассоциации находится вне сферы действия серии стандартов ИСО/ИИЭР 11073. УУИд должен быть сформирован в соответствии с ITU-T Запись. X.667 (сентябрь 2004).

8.7.3.2 Ответ на ассоциацию

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

Определение AareApdu (см. А.8) описывает формат сообщения с ответом на ассоциацию. Пример ответа на ассоциацию можно найти в H.2.1.2. Сообщение с ответом на ассоциацию содержит следующее:

- поле результата, представляющее исход процедуры объединения;

- версия общего протокола данных, выбранного менеджером, если поле результата эквивалентно accepted или accepted-unknown-config;

- одно и только одно правило кодирования DataApdu, выбранное менеджером, если поле результата эквивалентно accepted или accepted-unknown-config;

- менеджер должен всегда поддерживать правила MDER для обеспечения способности к взаимодействию;

- кроме того, менеджер может выбрать одно из других правил кодирования, помимо правил MDER, предложенных агентом.

Примечание - MDER всегда поддерживается как агентом, так и менеджером. Однако если агент предлагает дополнительные правила кодирования менеджеру, можно сделать вывод, что у агента была на то веская причина (т.е. разработка дополнительной поддержки правил кодирования не выполняется без веских причин продукта). Таким образом, если агент предлагает дополнительные правила кодирования помимо MDER, предполагается, что менеджер выполнит одно из дополнительных предложенных правил кодирования, если это возможно. Например, если агент предлагает MDER и правила уплотненного кодирования (PER), предполагается, что менеджер выполнит кодировку PER, если это возможно. Если агент предлагает MDER и правила кодирования XML (XER - Правила кодировки расширяемого языка разметки), предполагается, что менеджер выполнит правила кодирования XER, если это возможно. На случай, если агент предлагает MDER, PER и XER, этот стандарт не дает рекомендаций относительно выбора предпочтительного правила кодирования;


- версия номенклатуры, выбранная менеджером, если поле результата эквивалентно accepted или accepted-unknown-config;

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

- уникальный идентификатор системы (см. таблицу 2) менеджера. EUI-64 используется для уникальной идентификации менеджера. Агент может использовать это поле для определения того, установлена ли связь с требуемым менеджером;

- поле dev-config-id должен выглядеть как manager-config-response в ответе;

- Data-req-mode-capab должен быть пустым в ответе;

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

Поле результата в сообщении с ответом на ассоциацию указывает результат запроса. Возможные исходы (см. AssociateResult в А.8) могут быть следующими:

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

- accepted-unknown-config означает, что конфигурация принята, но агенту необходимо направить свою конфигурацию менеджеру. Когда агент получает ответ с сообщением о том, что конфигурация неизвестна, он должен перейти в состояние конфигурации и следовать процедурам, описанным в разделе 8.7.6 для передачи конфигурации;

- rejected-unsupported-assoc-version означает, что агент и менеджер не разделяют общую версию ассоциации;

- rejected-no-common-protocol означает, что менеджер отклоняет запрос на ассоциацию, потому что не найден единый протокол данных в перечне DataProtoList, разделенном между менеджером и агентом;

- rejected-no-common-parameter означает, что менеджер отклоняет запрос на ассоциацию, потому что менеджер и агент не имеют общего набора рабочих параметров в информации об ассоциации, специфичной для протокола (PhdAssociationInformation);

- rejected-unauthorized используется, когда менеджер определяет, что агент не авторизован для подключения. Способ принятия решения устанавливается поставщиком;

- rejected-transient используется, когда менеджер не может принять ассоциацию из-за переходных режимов, таких как ограниченность ресурсов;

- rejected-permanent означает, что менеджер не может общаться с агентом, но никакой дальнейшей информации касательно причины не доступно;

- rejected-unknown следует использовать с осторожностью и только тогда, когда вышеуказанные коды возврата не применяются.

При всех rejected-* условиях, агент должен перейти в неассоциированное состояние.

8.7.3.3 Процедура менеджера

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

Возможные причины отклонения перечислены в пункте 8.7.3.2. Если менеджер отклоняет ассоциацию, он должен перейти в неассоциированное состояние.

Если запрос не отклоняется менеджером, поле результата в сообщении с ответом на ассоциацию, исходящее от менеджера, указывает на то, понимает ли менеджер конфигурацию. Если менеджер признает dev-config-id в качестве известного стандартной специализации устройства или как предыдущую ассоциацию, менеджер высылает сообщение с ответом на ассоциацию с указанием "accepted" в поле результата и переходит в рабочее состояние.

Если менеджер не признает dev-config-id, менеджер высылает сообщение с ответом на ассоциацию с указанием accepted-unknown-config в поле результата и переходит в конфигурирующее состояние.

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

8.7.4 Условия выхода

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

8.7.5 Условия возникновения ошибок

Агент должен ждать сообщения с ответом на ассоциацию в течение периода TOassoc (тайм-аут: процедура ассоциация). Если период TO истекает, агент должен повторно передать сообщение с запросом ассоциации до RC раз (счётчик повторов: процедура ассоциации) после первого тайм-аута, с периодом TO между каждым последующим сообщением. Если после данной последовательности повторных попыток агент не может успешно получить любые сообщения с ответом на ассоциацию, то он направляет сообщение о разрыве ассоциации с менеджером и переходит обратно в неассоциированное состояние.

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

8.7.6 Тестовая ассоциация

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

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

- установить бит test-data или бит demo-data атрибута MeasurementStatus при создании моделированных данных измерений. Если атрибут MeasurementStatus не поддерживается, должны быть использованы альтернативные средства выделения таких данных;

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

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

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

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

На первом этапе агент передает менеджеру два бита информации в поле fun-units структуры PhdAssociationInformation. Бит fun-unit-createtestassociation указывает, что агент имеет возможности для испытаний, которые можно использовать в тестовой ассоциации. Бит fun-unit-createtestassociation используется агентом в качестве запроса менеджеру на установку тестовой ассоциации. Агент не должен устанавливать бит fun-unit-createtestassociation, если он также не установил бит fun-unit-havetestcap. Если агент вводит бит fun-unit-havetestcap в структуру PhdAssociationInformation, он не должен завершать ассоциацию вследствие получения ответа с установленным битом fun-unit-createtestassociation. Это означает, что если агент устанавливает бит fun-unit-havetestcap и предлагает более одной конфигурации, в которых определены стандартизированные возможности испытания, агент должен быть готов вступить в тестовую ассоциацию, используя одну из этих конфигураций.

На втором этапе протокола менеджер обратно сигнализирует агенту о своем намерении установить тестовую ассоциацию. Менеджер передает эту информацию агенту через бит fun-unit-createtestassociation. Бит устанавливается менеджером для того, чтобы указать, что он вступил в тестовую ассоциацию. Менеджер должен установить этот бит, только в случае если fun-unit-havetestcap установлен в запросе от агента. В соответствии с данным стандартом менеджер не обязан входить в тестовую ассоциацию даже по просьбе агента. Агент должен игнорировать бит fun-unit-havetestcap в ответе на ассоциацию.

Заключительный шаг протокола тестовой ассоциации включает в себя решение агента о продолжении тестовой ассоциации или ее завершении. Агент не вступает в состояние тестовой ассоциации, если менеджер не установил бит fun-unit-createtestassociation. Тестовая ассоциация завершается, когда машина состояний ассоциации входит в неассоциированное состояние.

     8.8 Процедура конфигурирования

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

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

8.8.2 Условия входа

Сообщение с ответом на ассоциацию с результатом accepted-unknown-config должны инициировать агента войти в конфигурирующее состояние и отправить его конфигурацию менеджеру. Менеджер входит в конфигурирующее состояние сразу же после отправки ответа на ассоциацию с результатом accepted-unknown-config.

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

8.8.3 Нормальные процедуры

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

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

- все объекты, поддерживаемые агентом, за исключением объекта системы MDS, и

- набор статических атрибутов для каждого объекта.

Атрибуты включают идентификацию номенклатуры классов объекта (см. 6.3.4.2, 6.3.5.2 и 6.3.6.2), физиологический идентификатор (код номенклатуры), идентификатор единицы/размера (код номенклатуры), дополнительно, строки для маркировки, а также любые другие статические атрибуты, которые могут быть полезными. Эта информация рассматривает плоское (неиерархическое) и статическое дерево состава агента. Объект системы MDS исключается из конфигурации, так как большая часть информации является динамической или специфичной для производителя. Отдельная команда Get MDS Object (Получение объекта системы MDS) побуждает механизм загружать данную информацию (см. 6.3.2.6.1).

Для объектов, о которых сообщается на тех же атрибутах каждый раз, рекомендуется отчет о событии фиксированного формата (см. 7.4.5), и агент должен отправить карту Attribute-Value-Map, описывающую структуру сообщения. Касательно объектов сканера, которые используют отчеты о событиях группированного формата, агент направляет карту andle-Attr-Val-Map с описанием структуры.

Если набор переданных атрибутов объекта не является фиксированным, рекомендуется отчет о событии переменного формата. Этот формат позволяет сообщать атрибуты конфигурации как часть обновления значений. В этом случае Attribute-Value-Map не предоставляется в отчете о событии конфигурации или предоставляется как пустой список.

Агент должен использовать сообщение данных "Remote Operation Invoke | Confirmed Event Report" (см. A.10.3 для начального определения EventReportArgumentSimple) с типом события MDC_NOTI_CONFIG при передаче своей конфигурации (см. ConfigReport в A.11.5 для остальной части структуры). Менеджер должен ответить сообщением "Remote Operation Response | Confirmed Event Report" (см. A.10.3 для определения EventReportResultSimple) с указанием типа события MDC_NOTI_CONFIG, внесенного в структуру ConfigReportRsp. См. Н.2.2 для получения примера запроса события конфигурации, отправленного агентом, за которым следует пример ответа от менеджера.


Рисунок 14 - Процедура конфигурации


Агенты могут поддерживать более одной конфигурации. В этом случае агент должен послать каждую из имеющихся конфигураций, начиная с предпочтительной конфигурации. Если менеджер принимает конфигурацию, он отвечает сообщением accepted-config, затем менеджер и агент переходят в рабочее состояние. Если менеджер не принимает конфигурацию, то он должен отправить ответ unsupported-config. По получении ответа unsupported-config агент отправляет следующую конфигурацию. Этот процесс повторяется до тех пор, пока агент не попытается отправить все конфигурации. Затем он должен отправить сообщение о выпуске ассоциации с кодом причины no-more-configurations, с целью указать, что он не может работать с менеджером.

Агент, который соответствует одному или нескольким специализациям устройств, которые определяют стандартные конфигурации (то есть специализации ИСО/ИИЭР 11073-104zz) должен поддерживать одну или несколько стандартных конфигураций и может поддерживать одну или несколько расширенных конфигураций. Для совместимости этот агент направляет поддерживаемые стандартные конфигурации как запасные, если расширенные конфигурации не поддерживаются.

Если агент соответствует стандартной конфигурации, то он должен использовать dev-config-id, как определено в конкретной специализации устройства ИСО/ИИЭР 11073-104zz. Эти значения dev-config-id стандартной конфигурации назначаются в диапазоне между standard-config-start и standard-config-end включительно. Когда агент предоставляет dev-config-id, соответствующий стандартной конфигурации, сообщение о конфигурации не должно содержать информацию о конфигурации и тип события MDC_NOTI_CONFIG может быть отправлен со стандартным идентификатором конфигурации и пустым списком ConfigObjectList. Если менеджер не узнает стандартную конфигурацию (например, менеджер был выпущен перед тем, как была выпущена специализации устройства), то он должен отправить ответ standard-config-unknown. Агент может повторить конфигурацию для стандартного устройства, отправив полную информацию о конфигурации.

Агент, имеющий нестандартную конфигурацию, должен присвоить уникальный идентификатор своей конфигурации путем создания значения для dev-config-id в диапазоне между extended-config-start и extended-config-end, включительно.

Агент может использовать то же значение для dev-config-id в последующих запросах на ассоциацию с менеджером, чтобы обозначить ту же конфигурацию устройства. Выбранное значение dev-config-id должно быть сообщено в атрибуте Dev-Configuration-Id объекта MDS.

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

8.8.4 Условия выхода

Когда менеджер принимает предпочтительную конфигурацию, он должен отправить ответ accepted-config агенту и перейти в рабочее состояние. Если менеджер получает запрос на выпуск ассоциации с указанием причины no-more-configurations, чтобы указать, что агент не имеет следующих конфигураций, менеджер должен перейти в неассоциированное состояние.

Когда агент получает ответ accepted-config от менеджера, он должен перейти в рабочее состояние. Если агент получает ответ от менеджера unsupported-config, он должен посылать следующую конфигурацию менеджеру до тех пор, пока не останется больше конфигураций. Тогда он должен послать сообщение с запросом на выпуск ассоциации с указанием причины no-more-configurations и войти в неассоциированное состояние.

8.8.5 Условия возникновения ошибок

Агент должен ожидать получения сообщения "Remote Operation Invoke | Confirmed Event Report" MDC_NOTI_CONFIG в течение периода TO (время выполнения процедуры конфигурации). Если период TO истекает, агент направляет сообщение о разрыве ассоциации менеджеру и переходит обратно в неассоциированное состояние.

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

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

     8.9 Процедура Выполнения

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

Передача данных о текущем состоянии и информации о статусе агента происходит во время процедуры Выполнения.

8.9.2 Условия входа

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

8.9.3 Нормальные процедуры

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

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

8.9.3.2 Атрибуты объекта системы MDS

В любое время в рабочем и ассоциированном состоянии менеджер может запросить атрибуты объекта системы MDS агента, отправив сообщение с данными, по команде "Remote Operation Invoke | Get" и полученное значение дескриптора 0. Агент должен сообщить менеджеру о введении им атрибута объекта системы MDS, используя сообщение данных с ответом "Remote Operation Response | Get". См. Н.2.3 для получения примера использования данного набора сообщений. Агенты должны поддерживать команду Get, которая запрашивает все атрибуты (т.е. список attribute-id-list пуст). Агенты могут поддерживать извлечение конкретного перечня идентификаторов атрибута.

На рисунке 15 показана схема последовательности запроса атрибутов объекта системы MDS менеджером от агента.


Рисунок 15 - Схема последовательности получения атрибутов объекта системы MDS

8.9.3.3 Передача данных измерений

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

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

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

Все варианты двух методов, подробно описаны в пунктах 8.9.3.3.2-8.9.3.3.8.

8.9.3.3.2 Передача данных измерений, инициированная агентом.

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

Агент

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

Для передачи данных измерений, инициированной агентом, поле data-req-id в отчете сканера (MDC_NOTI_SCAN_REPORT_*) должно быть установлено на data-req-id-agent-initiated.

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


Рисунок 16 - Передача данных измерений, инициированная агентом

8.9.3.3.3 Обзор передачи данных измерений, инициированной менеджером

Когда агент поддерживает передачу, инициированную менеджером, он должен указать, какие функции он поддерживает, используя структуру DataReqModeCapab. Если агент не предоставляет DataReqModeCapab, менеджер должен допускать, что ни одно из свойств не поддерживается агентом.

При передаче данных измерений, инициированной менеджером, менеджер использует сервис ACTION (см. 7.3), предоставленный агентом, с целью запросить передачу данных измерений у агента. Когда менеджер намерен сделать это, он должен послать подтвержденный запрос DataApdu ActionArgumentSimple с типом действия MDC_ACT_DATA_REQUEST, за которым следует информация DataRequest. Этот запрос данных может являться запросом на начало или запросом на остановку, в соответствии с указанием бита data-req-start-stop режима data-req-mode (см. A.11.5) или запросом на продолжение в соответствии с указанием бита data-req-continuation.

Для запроса на начало могут использоваться три режима: одиночный ответ (data-req-mode-single-rsp), период времени (data-req-mode-time-period), и без ограничения по времени (data-req-mode-time-no-limit). В зависимости от режима запроса на начало агент может отправить один или несколько отчетов о событиях менеджеру. Когда менеджер запускает режим передачи данных, он предоставляет идентификатор data-req-id, который должен использоваться агентом во всех отчетах событий. Если, в то время как режим передачи данных запущен, приходит новый запрос на начало с тем же data-req-id, этот запрос будет считаться приоритетным, а новый инициирован. Агент рассматривает новый запрос на начало, как если бы это была остановка с последующим началом. Режимы одиночного ответа и периода времени имеют четко определенные конечные точки, после чего ресурсы, поддерживающие эти запросы, могут быть выпущены. Запрос без ограничения по времени не имеет четко определенной конечной точки. Менеджер должен выпустить запрос на остановку, если больше не заинтересован в потоке измерения, в частности для запроса без ограничения по времени, для того чтобы высвободить ресурсы на агенте.

Для каждого из этих режимов может выбираться один из трех различных вариантов для сферы действия объекта, к которому относится запрос на передачу данных: все данные, имеющиеся у агента (data-req-scope-all), данные, имеющиеся у агента в соответствии с конкретным классом объекта (data-req-scope-class), и данные, имеющиеся у агента в соответствии с конкретными объектами, определенными их дескрипторами (data-req-scope-handle).

При использовании data-req-scope-all агент должен рассмотреть все объекты, за исключением объекта системы MDS, при определении содержания каждого отчета о событии.

При использовании data-req-scope-class менеджер должен использовать data-req-class с целью определения класса объектов для создания отчета. При формировании отчетов о событиях агент должен рассматривать только те объекты, что описаны данным классом.

Идентификаторы разрешенного класса включают MDC_MOC_VMO_METRIC_NU, MDC_MOC_VMO_METRIC_SA_RT и MDC_MOC_VMO_METRIC_ENUM.

Когда data-req-scope-handle отправлен, менеджер должен предоставить список дескрипторов в data-req-obj-handle-list. Агент должен рассматривать только объекты, описанные действительными дескрипторами в списке дескрипторов при создании отчета о событиях. В данном контексте термин "действительный" относится ко всем дескрипторам, ассоциированным с метрически-производными объектами (например, числовые, РТ-SA (матрица отсчета часов реального времени) или перечисления) поддерживаемыми агентом.

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

При использовании установленного по времени режима, если менеджер хочет продлить время, которое предоставлено агенту для передачи данных, менеджер должен установить бит data-req-continuation в режиме и установить data-req-time, до значения количества времени, отведенного агенту для непрерывной передачи.

Поле data-req-id в запросе данных используется для дифференциации ответов из нескольких запросов данных того же агента (если агент позволяет несколько одновременных запросов данных). Менеджер должен установить значение поля data-req-id на значение в диапазоне от data-req-id-manager-initiated-min до data-req-id-managerinitiated-max, включительно. Агент должен использовать то же значение data-req-id во всех ассоциированных отчетах о событиях.

Следует отметить, что менеджер может установить значение поля данных data-req-id на любое значение в пределах допустимого диапазона. Тогда агент не будет опираться на поле data-req-id для того, чтобы вывести, например, порядок, в котором различные запросы данных были созданы менеджером.

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

Три режима передачи данных измерений менеджера, инициированной менеджером, описаны в пунктах 8.9.3.3.4-8.9.3.3.6.

8.9.3.3.4 Режим одиночного ответа, инициированный менеджером

Режим одиночного ответа позволяет менеджеру запрашивать данные у агента и получать их в ответном сообщении (см. рисунок 17). Не существует требований к тому, чтобы агент собирал какие-либо данные (например, надувка манжетки для измерения кровяного давления) для составления ответа. Если агент не имеет доступных данных, он возвращает пустой список данных. Если агент имеет данные и статус результата - data-req-result-no-error, он должен послать сообщение DataResponse, которое содержит статус результата запроса (DataReqResult), а также данные измерений (ScanReportInfo*). Это ответное сообщение должно закрыть доступ к данным измерений.

Режим одиночного ответа не позволяет агенту подтверждать то, что менеджер получает данные измерений. Там, где необходимо такое подтверждение, используется срочная команда со значением тайм-аута от 0 (см. 8.9.3.3.5).


Рисунок 17 - Передача данных измерений, инициированная менеджером (data-req-mode-single-rsp)

8.9.3.3.5 Режим периода времени, инициированный менеджером

Режим периода времени используется менеджером для того, чтобы разблокировать агента для передачи данных, которые он собирает на протяжении указанного периода времени (см. рисунок 18). Когда агент получает начальное сообщение DataRequest от менеджера, агент должен отправить сообщение DataResponse, подтверждающее статус результата запроса (DataReqResult) без передачи каких-либо данных измерений в ответном сообщении. Если DataReqResult является data-req-result-no-error, каждый раз, когда данные становятся доступными, агент должен использовать сервис EVENT REPORT (Отчет о событиях) для оправки отчета(ов) о событии, содержащий данные измерений менеджеру, прежде чем истечет период времени, указанный в запросе данных, он получает запрос от менеджера на остановку или связь между агентом и менеджером прекращается. Агент определяет, использовать ли сообщение с подтвержденным или неподтвержденным отчетом о событии для передачи данных.

Если менеджер хочет продлить период времени, он должен перейти в data-req-id, установить data-req-continuation в режиме, и установить data-req-time, до такого значения времени, чтобы агент мог продолжить передачу данных. Все остальные параметры в DataRequest должны игнорироваться, и должны использоваться настройки исходной команды начала. Агент должен применять каждый новый период времени, измеренный с момента принятия команды. Если команда на продолжение получена для data-req-id, который не функционирует в заданном режиме, агент должен ответить data-req-result-continuation-not-supported. Если команда на продолжение получена для несуществующего data-req-id, агент должен ответить data-req-result-invalid-req-id. Например, если время истекает до приема команды продолжения, data-req-id останавливается и удаляется.

В режиме установленного периода времени, если data-req-time установлен на 0, агент должен подтвердить запрос. В случае подтверждения немедленно начните передачу любых данных, доступных в настоящее время в отчетах событий, а затем остановите. В отличие от режима одиночного ответа (см. 8.9.3.3.4), режим установленного периода времени позволяет агенту использовать сообщения с подтвержденными или неподтвержденными отчетами о событиях. Например, агент может использовать подтвержденный отчет о событии, чтобы убедиться, что данные были получены менеджером до их удаления из локального кэша.

При получении запроса на остановку передачи данных для разблокированного enabled data-req-id, агент должен прекратить отправку отчетов о событии для data-req-id immediately.

Поле data-req-id в этих отчетах о событии используется менеджером для связи этих данных измерений с соответствующим запросом данных.


Рисунок 18 - Передача данных измерений, инициированная менеджером (data-req-mode-time-period)

8.9.3.3.6 Режим без ограничения времени, инициированный менеджером

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


Рисунок 19 - Передача данных измерений, инициированная менеджером (data-req-mode-time-no-limit)

8.9.3.3.7 Управление номерами отчетов о сканировании

Закупки не найдены
Свободные
Р
Заблокированные
Р
Роль в компании Пользователь

Для продолжения необходимо войти в систему

После входа Вам также будет доступно:
  • Автоматическая проверка недействующих стандартов в закупке
  • Создание шаблона поиска
  • Добавление закупок в Избранное