Приложение В (справочное). Примеры профилей транзакций

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

Примеры профилей транзакций

Упомянутый выше монитор кровяного давления (специализация 10407) служит еще и хорошим примером демонстрации сервисной модели и профилей транзакций. Сервисная модель определяет концептуальные механизмы для сервисов обмена данными. Эти сервисы обрабатывают сообщения, которыми обмениваются агент и менеджер. Протокольные сообщения в рамках серии стандартов ИСО/ИИЭР 11073 определены в нотации АСН.1. Подробное описание сервисной модели персональных медицинских приборов см. в ISO/IEEE 11073-20601:2010(E) [В48] и IEEE Std 11073-20601аТМ-2010 [В36].

В.1 Пример сервисной модели монитора кровяного давления

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

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

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

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

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

В.2 Пример коммуникационной модели монитора кровяного давления

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

- при процедуре ассоциации;

- при процедуре конфигурации;

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

- при синхронизации часов.

На рисунке В.1 показаны примеры соответствующих диаграмм последовательности.

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

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

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

- затем менеджер может запросить атрибуты MDS объекта агента, отправив сообщение данных с командой "Remote Operation Invoke Get" (дистанционный вызов операции Get). В качестве ответа агент возвращает менеджеру отчет, содержащий атрибуты объекта MDS, используя сообщение данных с командой "Remote Operation Response Get";

- на следующем шаге пользователь прибора агента выполняет одно измерение. Результат измерения передается менеджеру в форме отчета о подтверждаемом событии. После успешного получения результата измерения менеджер отправляет агенту подтверждение;

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

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

Согласно ISO/IEEE 11073-10407:2010(E) [В44] запрос на ассоциацию, отправляемый агентом менеджеру, имеет следующую структуру:

- значение версии процедуры ассоциации, используемой агентом, должно быть равно assoc-version1 (т.е. assoc-version = 0x80000000);

- значение структурного элемента DataProtoList в идентификаторе протокола данных должно быть равно data-proto-id-20601 (т.е. data-proto-id = 0x5079);

- поле data-proto-info должно содержать структуру PhdAssociationlnformation со следующими значениями параметров:

Рисунок В.1 - Диаграмма последовательности монитора кровяного давления, соответствующего специализации 10407

1) в поле functional-units могут быть установлены биты тестирования ассоциации. Никакие другие биты не должны быть установлены;

2) поле system-type должно быть равно sys-type-agent (т.е. system-type = 0x00800000);

3) поле System-Id должно быть равно значению атрибута System-Id объекта MDS агента. Менеджер может воспользоваться этим полем для идентификации монитора кровяного давления, с которым он ассоциируется, и при необходимости реализовать простую политику ограничения доступа;

4) поле dev-config-id должно быть равно значению атрибута Dev-Configuration-ld объекта MDS агента;

5) если агент поддерживает только специализацию монитора кровяного давления, то поле, указывающее режимы запроса данных (data-req-mode-capab), поддерживаемые агентом монитора кровяного давления, должно иметь значение data-req-supp-init-agent;

6) если агент поддерживает только специализацию монитора кровяного давления, то поле data-req-initmanager-count должно иметь значение 0, а поле data-req-init-agent-count - значение 1.

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

0хЕ2 0x00	Тип APDU CHOICE (AarqApdu)
0x00 0x32	CHOICE.Iength = 50
0x80 0x00 0x00 0x00		assoc-version
0x00 0x01 0x00 0х2А		data-proto-list.count = 1 длина = 42
0x50 0x79	data-proto-id = 20601
0x00 0x26	длина data-proto-info = 38
0x80 0x00	0x00 0x00 protocolVersion
0хА0 0x00	правила кодирования = MDER или PER
0x80 0x00	0x00 0x00 nomenclatureVersion
0x40 0x00 0x00 0x00		functionalUnits, имеет возможность тестирования ассоциации
0x00 0x80 0x00 0x00		systemType = sys-type-agent
0x00 0x08	длина system-id = 8 и значение
0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x07
0x02 0хВС	dev-config-id - стандартная конфигурация
0x00 0x01	data-req-mode-flags
0x01 0x00	data-req-init-agent-count, data-req-manager count
0x00 0x00 0x00 0x00 optionList.count = 0 option List, length = 0

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

- поле результата должно иметь одно из значений вариантов ответа, определенных в ИСО/ИИЭР 11073-20601:2010(Е) [В48] и ИИЭР Std 11073-20601аТМ-2010 [В36]. Например, если все условия протокола ассоциации выполнены, то возвращается значение accepted (принято), если менеджер распознал идентификатор конфигурации агента dev-config-id, и accepted-unknown-config (подтверждена неизвестная конфигурация) в противном случае:

- значение структурного элемента DataProtoList в идентификаторе протокола данных должно быть равно data-proto-id-20601 (т.е., data-proto-id = 0x5079);

- поле data-proto-info должно содержать структуру PhdAssociationlnformation со следующими значениями параметров:

1) версия протокола обмена данными должна быть равна protocol-version1 (т.е. protocol-version = 0x80000000);

2) менеджер должен возвратить идентификатор одного правила кодирования, которое поддерживается и им, и агентом. Менеджер должен поддерживать как минимум правила кодирования MDER;

3) используемая версия номенклатуры должна быть равна nom-version1 (т.е. nomenclature-version = 0x80000000);

4) в поле functional-units должны быть сброшены все биты, кроме тех, что относятся к тестированию ассоциации;

5) поле system-type должно быть равно sys-type-manager (т.е. system-type = 0x80000000);

6) поле System-Id должно содержать уникальный идентификатор системы устройства менеджера, имеющий формат расширенного уникального идентификатора (64 бита) (EUI-64);

7) поле dev-config-id должно быть равно manager-config-response (0);

8) поле data-req-mode-capab должно быть равно 0;

9) поля data-req-init-*-count должны быть равны 0.

Ниже приведен пример кодирования ответа менеджера на запрос ассоциации при неизвестной конфигурации агента:

0хЕ3 0х00	Тип APDU CHOICE (AareApdu)
0x00 0х2С	CHOICE.Iength = 44
0x00 0x03	результат = accepted-unknown-config
0x50 0x79	data-proto-id = 20601
0x00 0x26	data-proto-info length = 38
0x80 0x00 0x00 0x00		protocol-version
0x80 0x00	encoding-rules = MDER
0x80 0x00 0x00 0x00		nomenclature-version
0x00 0x00 0x00 0x00		functional-units
0x80 0x00 0x00 0x00		system-type = sys-type-manager
0x00 0x08	длина svstem-id = 8 и значение
0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88
0x00 0x00	dev-config-id в ответе менеджера всегда равно 0
0x00 0x00 0x00 0x00		data-req-mode-capab в ответе менеджера всегда равно 0
0x00 0x00 0x00 0x00		option-list.count = 0 option-list.length = 0