ГОСТ Р 59524-2021/ISO/IEEE 11073-10408:2010. Национальный стандарт Российской Федерации. Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10408. Специализация прибора. Термометр

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

Утвержден и введен в действие

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

Предисловие

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

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073-10408:2010 «Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10408. Специализация прибора. Термометр» (ISO/IEEE 11073-10408:2010 «Health informatics — Personal health device communication — Part 10408: Device specialization — Thermometer», IDT).

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Международная организация по стандартизации (ИСО) — это всемирная федерация национальных органов по стандартизации (членов ИСО). Работу по подготовке международных стандартов обычно осуществляют технические комитеты ИСО. Любой член ИСО, заинтересованный в том или ином вопросе, по которому был учрежден технический комитет, имеет право на представительство в этом комитете. В этой работе также принимают участие международные, правительственные и неправительственные организации, взаимодействующие с ИСО. По вопросам электротехнической стандартизации ИСО тесно сотрудничает с Международной электротехнической комиссией (МЭК).

Документы по стандартам IEEE разрабатываются в сообществах IEEE и Координационных комитетах по стандартизации Совета по стандартам Ассоциации стандартов IEEE (IEEE-SA). Институт IEEE разрабатывает свои стандарты на основе процесса достижения консенсуса, одобренного Американским национальным институтом стандартов (American National Standards Institute, ANSI), который для достижения конечного результата объединяет добровольцев, представляющих различные точки зрения и интересы. Добровольцы не обязательно являются членами института и работают безвозмездно. Хотя IEEE управляет процессом и устанавливает правила, способствующие обеспечению справедливости в процессе достижения консенсуса, институт не проводит независимую оценку, тестирование или проверку достоверности какой-либо информации, содержащейся в его стандартах.

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

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

ISO/IEEE 11073-10408 был подготовлен Комитетом по стандартам 11073 сообщества IEEE по техническим средствам, применяемым в области медицины и биологии (как IEEE 11073-10417-2015). Он был принят Техническим комитетом ИСО/ТК 215 «Информатизация здоровья» параллельно с его утверждением членами ИСО, в соответствии с ускоренной процедурой, определенной в соглашении о сотрудничестве между ИСО и IEEE в рамках партнерской организации по разработке стандартов. Обе стороны несут ответственность за содержание данного документа.

Серия стандартов ISO/IEEE 11073 под общим названием «Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья» состоит из следующих частей:

• Часть 10101. Номенклатура;
• Часть 10201. Информационная модель предметной области;
• Часть 10404. Специализация прибора. Пульсовой оксиметр;
• Часть 10407. Специализация прибора. Монитор артериального давления;

• Часть 10415. Специализация прибора. Весы;
• Часть 10417. Специализация прибора. Глюкометр;
• Часть 10471. Специализация прибора. Автономный центр обеспечения жизнедеятельности;
• Часть 20101. Прикладные профили. Базовый стандарт;
• Часть 20601. Прикладной профиль. Оптимизированный протокол обмена;
• Часть 30200. Транспортный профиль. Кабельное соединение;
• Часть 30300. Транспортный профиль. Инфракрасный канал связи.

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

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

Настоящий стандарт организации IEEE доступен для применения в соответствии с важными замечаниями и заявлениями об отказе от ответственности. Эти замечания и заявления об отказе от ответственности присутствуют во всех публикациях, содержащих настоящий документ, под заголовком «важное замечание» или «важные замечания и заявления об отказе от ответственности при применении документов организации IEEE». Они могут быть также получены от организации IEEE по запросу или просмотрены на сайте http://standards.ieee.org/IPR/disclaimers.html.

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

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

Настоящий стандарт устанавливает нормативное определение обмена данными между персональными телемедицинскими приборами термометра и вычислительными устройствами (например, сотовыми телефонами, персональными компьютерами, бытовыми медицинскими приборами контроля и телевизионными приставками) таким образом, чтобы обеспечить plug-and-play (подключи-и-работай) совместимость. Он использует соответствующие компоненты существующих стандартов, включая терминологию, информационные модели, стандарты прикладного профиля и транспортные стандарты комплекса стандартов ISO/IEEE 11073. Он определяет использование специфических кодов терминов, форматов и моделей поведения в телемедицинских средах, ограничивающих опциональность в базовых интегрированных системах в интересах интероперабельности. Настоящий стандарт определяет общее ядро коммуникационной функциональности для персональных телемедицинских термометров.

1.2 Назначение

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

1.3 Контекст

Обзор условий, в которых применяется настоящий стандарт, приведен в IEEE 11073-20601.

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

Настоящий стандарт основан на IEEE 1073-20601, который, в свою очередь, использует информацию как из ISO/IEEE 11073-10201:2004 [B3] <1>, так и из ISO/IEEE 11073-20101:2004 [B4]. Правила кодирования медицинских устройств (MDER), используемые в этом стандарте, полностью описаны в IEEE 11073-20601.

<1> Цифры в скобках соответствуют цифрам библиографии в приложении A.

Настоящий стандарт повторяет соответствующие части номенклатуры, содержащейся в ISO/IEEE 11073-10101:2004 [B2], и добавляет новые номенклатурные коды для целей настоящего стандарта. В данном стандарте и в IEEE 11073-20601 задокументированы все необходимые для реализации номенклатурные коды.

Примечание - В настоящем стандарте IEEE 11073-104zz используется для обозначения серии стандартов для устройств различной специализации, которое использует IEEE 11073-20601-2014, где zz может быть любым числом от 01 до 99 включительно <2>.

<2> Примечания в тексте, таблицах и рисунках приведены только для информации и не содержат требований, необходимых для внедрения стандарта.

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

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

IEEE 11073-20601-2008, Health informatics — Personal health device communication — Part 20601: Application Profile — Optimized Exchange Protocol (Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена данными) <3>, <4>

<3> Обозначения стандартов или документов IEEE, указанные в этом разделе, являются товарными знаками Института инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers, Inc.).

<4> Публикации IEEE доступны в Институте инженеров по электротехнике и радиоэлектронике, 445 Hoes Lane, Piscataway, NJ 08854, США.

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

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

В настоящем стандарте применены термины с соответствующими определениями. Термины, не определенные в данном разделе, должны находиться в онлайн-словаре стандартов IEEE.

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

3.1.2 температура тела (body temperature): Измерение внутренней температуры тела человека.

3.1.3 класс (class): В объектно-ориентированном моделировании класс описывает атрибуты, методы и события, присущие объектам, являющимся его экземплярами.

3.1.4 вычислительное устройство (compute engine): См. менеджер.

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

3.1.6 температура конечности (extremity body temperature): Измерение температуры на конечностях тела человека, на пальце руки или ноги.

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

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

3.1.9 дескриптор объекта (obj-handle): См. дескриптор.

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

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

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

3.2 Сокращения

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

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

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

DIM — информационная модель предметной области (domain information model);

EUI-64 — расширенный уникальный идентификатор (64 бита) [(extended unique identifier (64 bits)];

ICS — заявление о соответствии реализации (implementation conformance statement);

MDC — обмен данными с медицинским прибором (medical device communication);

MDER — правила кодирования для медицинских устройств (medical device encoding rules);

MDS — система медицинского прибора (medical device system);

MOC — класс управляемых объектов (managed object class);

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

PHD — персональный медицинский прибор (personal health device);

RT-SA — массив считываний в реальном времени (real-time sample array);

VMO — виртуальный медицинский объект (virtual medical object);

VMS — виртуальная медицинская система (virtual medical system).

4 Введение в стандарты комплекса IEEE 11073TM по персональным медицинским приборам

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

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

Стандарт IEEE 11073-20601-2014 поддерживает моделирование и реализацию широкого множества персональных медицинских приборов. Настоящий стандарт определяет требования к прибору термометра. В нем определены все аспекты, необходимые для реализации сервисов прикладного уровня и протокола обмена данными между агентом термометра и менеджером, соответствующих серии стандартов ISO/IEEE 11073, посвященных персональным медицинским приборам (ПМП). Настоящий стандарт определяет подмножество объектов и функциональные возможности, описанные в IEEE 11073-20601-2014, и при необходимости расширяет и добавляет некоторые определения. Все новые определения, приведенные в приложении B, соответствуют абстрактной синтаксической нотации версии 1 (ASN.1). Номенклатурные коды, указанные в настоящем стандарте, которые не определены в ISO/IEEE 11073-20601-2014, представлены в нормативном приложении C.

4.2 Введение в структуры моделирования IEEE 11073-20601

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

В основу серии стандартов ISO/IEEE 11073, и в частности IEEE 11073-20601-2014, положена парадигма управления объектно-ориентированными системами. Общая модель системы состоит из трех основных компонентов: информационная модель предметной области (DIM), сервисная модель и коммуникационная модель. Подробное описание структур моделирования приведено в IEEE 11073-20601.

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

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

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

Сервисная модель определяет концептуальные механизмы сервисов обмена данными. Такие сервисы согласованы с сообщениями, которыми обмениваются агент и менеджер. Сообщения протокола в рамках стандартов серии ISO/IEEE 11073 определены в нотации ASN.1. Сообщения, определенные в IEEE 11073-20601, могут сосуществовать с сообщениями, определенными в других стандартных прикладных профилях, определенных в стандартах серии ISO/IEEE 11073.

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

В общем случае коммуникационная модель поддерживает топологию, при которой один или несколько агентов взаимодействуют с одним менеджером через логические соединения «точка — точка». Для каждого такого логического соединения динамическое поведение системы определено конечным автоматом состояний в соответствии с IEEE 11073-20601.

4.2.5 Реализация моделей

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

5 Концепция устройства термометра и возможные реализации

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

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

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

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

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

5.2 Температура тела

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

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

Основными единицами измерения температуры, используемыми в медицине, являются градусы по Цельсию и по Фаренгейту.

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

6.1 Обзор

Настоящий раздел описывает информационную модель предметной области (domain information model, DIM) термометра.

6.2 Расширение классов

В настоящем стандарте не определены расширения классов по отношению к описанным в IEEE 11073-20601.

6.3 Диаграмма объектов

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

Рисунок 1 — Информационная модель предметной области термометра

Объекты предметной области (DIM), представленные на рисунке 1, описаны в 6.4 - 6.12. К ним относятся объекты системы медицинского прибора (MDS) (см. 6.5) и числовые объекты термометра (см. 6.6). Объекты массивов считываний в реальном времени (RT-SA) (см. 6.7), объекты перечислений (см. 6.8), объекты класса постоянного хранения (PM-store) (см. 6.9), а также объекты класса сканера (см. 6.10) не используются в описании термометра. Каждый раздел, описывающий объект термометра, содержит следующую информацию:

• номенклатурный код, используемый для идентификации класса объекта. Одним из примеров использования этого кода является событие конфигурации, в котором для каждого объекта указывается его класс. Это позволяет менеджеру определить, является ли класс указанного объекта числовым (Numeric), массивом считываний в реальном времени (RT-SA), перечислением (Enumeration), классом сканера (Scanner) или классом постоянного хранения (PM-store);

- атрибуты объекта. Каждый объект имеет атрибуты, которые представляют и передают информацию о физическом устройстве и его источниках данных. Каждый объект имеет атрибут Handle (дескриптор), который идентифицирует экземпляр объекта в агенте. Доступ к значениям атрибутов и их изменение осуществляются с помощью таких методов, как GET (получить) и SET (установить). Типы атрибутов определены в нотации ASN.1. Определения в нотации ASN.1 для новых типов атрибутов, специфичных для настоящего стандарта, содержатся в приложении B, а определения в нотации ASN.1 для существующих типов атрибутов, указанных в настоящем стандарте, приведены в IEEE 11073-20601;

- доступные методы объекта;

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

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

Атрибуты каждого класса описаны в таблицах, в которых указаны имя атрибута, его значение и квалификатор. Квалификаторы означают следующее: M — атрибут является обязательным (mandatory), C — атрибут является условно-обязательным (conditional) и зависит от условия, указанного в графах «Примечание» или «Значение» (если имеется ссылка на IEEE 11073-20601, то условия берутся из него), R — атрибут является рекомендуемым (recommended), NR — атрибут является нерекомендуемым (not recommended), а O — атрибут является необязательным (optional). Обязательные атрибуты должны быть реализованы в агенте. Условно-обязательные атрибуты должны быть реализованы при выполнении условия обязательности и могут быть реализованы в противном случае. Рекомендуемые атрибуты по возможности должны быть реализованы в агенте. Нерекомендуемые атрибуты не должны быть реализованы в агенте. Необязательные атрибуты могут быть реализованы в агенте.

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

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

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

Согласно IEEE 11073-20601 возможны два типа конфигурации. Пункты 6.4.2 и 6.4.3 кратко описывают стандартную и расширенную конфигурации.

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

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

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

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

6.5 Объект системы медицинских приборов (MDS)

6.5.1 Атрибуты объекта MDS

В таблице 1 представлены атрибуты объекта термометр MDS. Номенклатурный код для идентификации класса MDS-MDC_MOC_VMS_MDS_SIMP.

В таблице 1 приведены атрибуты объекта MDS термометра. Для идентификации класса MDS используется номенклатурный код MDC_MOC_VMS_MDS_SIMP.

В ответ на команду Get получения данных объекта MDS возвращаются только реализованные атрибуты и соответствующие им значения. Описание отдельных атрибутов, а также сведения об идентификаторе и типе атрибута приведены в IEEE 11073-20601.

Атрибут Dev-Configuration-Id содержит локально уникальный 16-разрядный идентификатор, определяющий конфигурацию прибора. Для агента термометра, использующего расширенную конфигурацию, этот идентификатор выбирается из диапазона значений от extended-config-start до extended-config-end, как показано в таблице 1 (см. IEEE 11073-20601).

Таблица 1

Атрибуты объекта MDS

Примечание - Информация о том, является атрибут статическим или динамическим, приведена в IEEE 11073-20601-2014.

В состоянии «Ассоциирующий» (Associating) агент передает идентификатор Dev-Configuration-Id (см. 8.3), для идентификации своей конфигурации в течение всего сеанса связи. Если менеджер уже имеет информацию о конфигурации, связанную с идентификатором Dev-Configuration-Id, то он распознает этот идентификатор, пропускает состояние «Конфигурирующий» (Configuring) (см. 8.4), после чего агент и менеджер переходят в состояние «Выполнение» (Operating). Если менеджер не распознает идентификатор Dev-Configuration-Id, то агент и менеджер переходят в состояние «Конфигурирующий» (Configuring).

Если агент реализует несколько типов специализаций IEEE 11073-104zz, то атрибут System-Type-Spec-List содержит список пар тип/версия, каждая из которых указывает соответствующую специализацию устройства и версию этой специализации.

6.5.2 Методы объекта MDS

В таблице 2 приведены методы (действия) объекта MDS. Эти методы вызываются с помощью сервиса Action. В графе «Имя типа субсервиса» (Subservice type name) таблицы 2 указано имя метода; в графе «Режим» (Mode) указано, вызывается ли метод как неподтверждаемое действие (например, roiv-cmip-action из IEEE 11073-20601) или подтверждаемое действие (например, roiv-cmip-confirmed-action); в графе «Тип субсервиса (action-type)» (Subservice type) определен номенклатурный код, используемый в поле action-type запроса на действие и ответа (см. IEEE 11073-20601); в графе «Поле параметров (action-info-args)» (Parameters) указано имя структуры данных, определенной в нотации ASN.1 (определения нотации ASN.1 см. в IEEE 11073-20601), используемое для уведомления о действии в поле action-info-args запроса; и в графе «Поле результатов (action-info-args)» (Results) указано имя структуры данных для использования в поле action-info-args ответа.

Таблица 2

Методы объекта MDS

Set-Time: Этот метод позволяет менеджеру установить абсолютное значение времени на часах реального времени агента. Агент с помощью бита mds-time-capab-set-clock в атрибуте Mds-Time-Info указывает, является ли команда Set-Time допустимой (см. IEEE 11073-20601). Агенты с встроенными часами реального времени (real-time clock, RTC) также должны указать эту возможность с помощью установки бита mds-time-capab-real-time-clock в атрибуте Mds-Time-Info.

6.5.3 События объекта MDS

Агенты, соответствующие только данной и никакой другой специализации устройства, должны передавать отчеты о событиях с использованием передачи данных измерений, инициированной агентом. В процессе процедуры ассоциации в поле data-req-mode-capab должно быть установлено подходящее значение data-req-supp-init-agent, определяющее стиль отчета о событии (см. 8.3). При этом менеджер должен исходить из того, что агент термометра не поддерживает ни одну из функций MDS-Data-Request (дополнительная информация приведена в IEEE 11073-20601). Биту data-req-init-manager-count должно быть присвоено значение 0, а биту datareq-init-agent-count — значение 1.

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

В таблице 3 приведены события, которые могут быть переданы объектом MDS термометра.

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

MDS-Dynamic-Data-Update-Var: это событие предоставляет динамические данные измерений, хранимые агентом термометра в числовых объектах. Они предоставляются в виде общего списка атрибутов с использованием переменного формата. Событие передается агентом в виде незапрашиваемого сообщения (то есть передачи данных измерений, инициированной агентом). Дополнительные сведения о незапрашиваемых отчетах о событиях приведены в 8.5.3. События считывания температуры, хранящиеся в объекте MDS, должны передаваться не чаще одного раза в секунду.

MDS-Dynamic-Data-Update-Fixed: это событие предоставляет динамические данные измерений агента термометра числового объекта температуры тела. Они передаются в фиксированном формате, определяемом атрибутом Attribute-Value-Map объекта. Событие передается агентом в виде незапрашиваемого сообщения (то есть передачи данных измерений, инициированной агентом). Дополнительные сведения о незапрашиваемых отчетах о событиях приведены в 8.5.3.

MDS-Dynamic-Data-Update-MP-Var: это событие аналогично MDS-Dynamic-Data-Update-Var, но позволяет учитывать данные от нескольких человек.

MDS-Dynamic-Data-Update-MP-Fixed: это событие аналогично MDS-Dynamic-Data-Update-Fixed, но позволяет учитывать данные от нескольких человек.

Примечание - Согласно требованиям IEEE 11073-20601 менеджеры должны поддерживать все перечисленные выше события объектов MDS.

6.5.4 Другие сервисы объекта MDS

6.5.4.1 Сервис GET (получить)

Агент термометра должен поддерживать сервис GET, который предоставляется объектом MDS для получения значений всех реализованных атрибутов объекта MDS. Сервис GET может вызываться, как только агент термометра на запрос ассоциации получает ответ Association Response и переходит в состояние «Ассоциирован» (Associated), включая подсостояния «Выполнение» (Operating) и «Конфигурирующий» (Configuring).

Менеджер может запросить атрибуты объекта MDS агента термометра; в этом случае он должен отправить команду «Remote Operation Invoke | Get» (см. roiv-cmip-get в IEEE 11073-20601) с зарезервированным нулевым значением дескриптора MDS. Агент термометра должен передать свои атрибуты объекта MDS менеджеру с помощью сообщения «Remote Operation Response | Get» (см. rors-cmip-get в IEEE 11073-20601-2014). Сводная информация о сервисе GET, включающая в себя некоторые поля сообщений, приведена в таблице 4.

Сервис GET объекта MDS Термометр

Подробнее процедура получения атрибутов объекта MDS описана в 8.5.2.

6.5.4.2 Сервис SET (установить)

Специализация термометра не требует реализации поддержки сервиса SET объекта MDS.

6.6 Числовые объекты

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

Информационная модель предметной области термометра (см. рисунок 1) содержит один необходимый объект температуры тела, описанный в 6.6.2.

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

6.6.2 Температура

В таблице 5 представлены атрибуты числового объекта температуры тела. Для идентификации числового класса Numeric используется номенклатурный код MDC_MOC_VMO_METRIC_NU. Агент термометра должен поддерживать числовой объект температуры тела.

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

6.7 Объекты массива считываний в реальном времени

6.8 Объекты перечисления

6.9 Объекты длительного хранения PM-store

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

6.11 Объекты расширения класса

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

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

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

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

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

Менеджер должен поддерживать отчеты о событиях с одним лицом и с несколькими лицами. Агент термометра может поддерживать один или оба варианта отчета о событиях, с одним и несколькими лицами. В IEEE 11073-20601 описаны форматы для отчетов о событиях с одним лицом и с несколькими лицами.

8 Коммуникационная модель термометра

8.1 Обзор

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

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

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

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

Для агента термометра, не реализующего никакой другой специализации устройства, кроме настоящего стандарта, максимальный размер отправленного блока APDU не должен превышать Ntx, а размер принимаемого блока APDU не должен превышать Nrx. В настоящем стандарте размер Ntx должен составлять 896 байт, а размер Nrx должен составлять 224 байта.

Для агента термометра, реализующего функции приборов других специализаций, на верхний предел размеров блоков APDU накладываются следующие ограничения: размер блока APDU, передаваемого агентом, не должен превышать сумму величин Ntx всех реализованных специализаций устройств, а размер блока APDU, принимаемого агентом, не должен превышать сумму величин Nrx. Если эти значения превышают максимальный размер, определенный в IEEE 11073-20601, должен применяться последний.

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

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

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

Процедура ассоциирования агента термометра и менеджера должна осуществляться в соответствии с требованиями IEEE 11073-20601.

8.3.2 Процедура агента — запрос ассоциации

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

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

• элемент структуры DataProtoList идентификатора протокола передачи данных должен иметь значение data-proto-id-20601 (т.е. data-proto-id = 0x5079);
• поле data-proto-info должно заполняться структурой PhdAssociationInformation, которая содержит значения следующих параметров:

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

2) как минимум, должны поддерживаться правила кодирования MDER (т.е. encoding-rules = 0x8000);

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

4) поле functional-units может содержать набор битов тестового соединения, но не должно содержать каких-либо других наборов битов;

5. в поле system-type должно быть установлено значение sys-type-agent (т.е. system-type = 0x00800000);

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

7. в поле dev-config-id должно быть установлено значение атрибута Dev-Configuration-Id объекта MDS агента;

8) если агент поддерживает только специализацию термометра, то в поле, указывающем режимы запроса данных (data-req-mode-capab), поддерживаемые агентом термометра, должно быть установлено значение data-req-supp-init-agent. Если агент поддерживает только специализацию термометра, то в поле data-req-init-manager-count должно быть установлено значение 0, а в поле data-req-init-agent-count — значение 1.

8.3.3 Процедура менеджера — ответ на запрос ассоциации

В ответном сообщении на запрос ассоциации, отправленном менеджером:

• в поле result должно быть передано значение соответствующего ответа, выбранное из вариантов, описанных в IEEE 11073-20601. Например, если менеджер распознает идентификатор dev-config-id агента, то при выполнении всех других условий протокола запроса ассоциации возвращается значение accepted, а в противном случае — значение accepted-unknown-config;
• в элементе структуры DataProtoList идентификатора протокола данных должно быть передано значение data-proto-id-20601 (т.е. data-proto-id = 0x5079);
• поле data-proto-info должно заполняться структурой PhdAssociationInformation, содержащей значения следующих параметров:

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 должно содержать уникальный системный идентификатор устройства менеджера, который должен быть действительным идентификатором типа EUI-64;

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

8. значения полей data-req-mode-capab и data-req-init-manage-count должны быть равны 0. Если агент поддерживает только специализацию термометра, то значение поля data-req-init-agent-count должно иметь значение 1.

8.4 Процедура конфигурирования

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

Если в ответ на запрос ассоциации агент получает сообщение accepted-unknown-config, то он переходит в состояние «Конфигурирующий» (Configuring). После этого должна начаться процедура конфигурации, приведенная в IEEE 11073-20601. В 8.4.2 описаны уведомления о конфигурации и ответные сообщения для агента термометра стандартной конфигурации 800, имеющей идентификатор 0x0320. Как правило, менеджер уже распознает стандартную конфигурацию. Однако в данном примере менеджер этого не делает.

8.4.2 Термометр — стандартная конфигурация

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

Для передачи своей конфигурации менеджеру агент должен использовать сообщение «Remote Operation Invoke | Confirmed Event Report» с типом события MDC_NOTI_CONFIG (см. IEEE 11073-20601). В поле события event-info используется структура «ConfigReport» (см. таблицу 3). У агента термометра, имеющего стандартную конфигурацию 800 с идентификатором 0x0320, формат и содержание сообщения уведомления о конфигурации выглядят следующим образом:

В тех местах сообщения, где содержание не является фиксированным, «0xXX» обозначает заполнитель и его значение зависит от реализации или от предыдущего сообщения агента.

8.4.2.2 Процедура менеджера

В ответ на сообщение уведомления о конфигурации менеджер должен отправить информационное сообщение «Remote Operation Response | Confirmed Event Report» с типом события MDC_NOTI_CONFIG, используя структуру ConfigReportRsp в поле event-info (см. таблицу 3). Формат и содержание ответного сообщения менеджера на уведомление о стандартной конфигурации, приведенное в 8.4.2.1, выглядят следующим образом:

Значение «0xXX» обозначает заполнитель и указывает фиксированное место переменных частей содержания сообщения.

8.5 Процедура выполнения

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

Передача данных измерений и информации о статусе агента термометра происходит в состоянии «Выполнение» (Operating). Если не указано иное, то процедура «Выполнение» агента термометра настоящего стандарта должна соответствовать требованиям IEEE 11073-20601.

8.5.2 Сервис GET получения атрибутов объекта MDS

Общие сведения о сервисе GET приведены в таблице 4.

Если менеджер оставляет поле списка attribute-id-list в сообщении службы roiv-cmip-get пустым, то агент термометра должен ответить сообщением сервиса rors-cmip-get, в котором атрибут attribute-list содержит список всех реализованных атрибутов объекта MDS.

Если менеджер запрашивает определенные атрибуты объекта MDS, указанные в поле списка attribute-id-list, и агент поддерживает эту возможность, то агент термометра должен ответить сообщением сервиса rors-cmip-get, в котором атрибут attribute-list содержит список реализованных атрибутов объекта MDS из числа запрашиваемых. Поддержка такой возможности для агента термометра не обязательна. Если эта возможность не реализована, то агент термометра должен ответить сообщением сервиса «Remote Operation Error Result» (roer) (см. IEEE 11073-20601-2014) с указанием значения ошибки no-such-action (9) в поле error-value.

8.5.3 Передача данных измерений

Общие сведения о сервисах отчетов о событиях, доступных для передачи данных измерений, приведены в таблице 3.

Для агента термометра, соответствующего настоящему стандарту с временным хранением данных измерений, передача этих данных всегда должна инициироваться термометром (передачу данных измерений, инициированную агентом, приведена в IEEE 11073-20601). Чтобы ограничить объем данных, передаваемых в APDU, агент термометра не должен включать в один отчет о событии более 25 временно хранящихся измерений. Если для передачи доступно более 25 измерений, ожидающих отправки, то они должны быть переданы с использованием нескольких отчетов о событиях. Если доступны многократные измерения температуры, то в одном отчете о событии может быть передано до 25 измерений. Кроме того, они могут передаваться с использованием одного отчета о событиях для каждого измерения температуры. Однако для уменьшения общего объема сообщений и энергопотребления рекомендуется использовать первую стратегию.

8.6 Синхронизация времени

Для согласования показаний часов, используемых при передаче сообщений о физиологических событиях, может использоваться синхронизация времени между агентом термометра и менеджером. Следует учесть, что способ реализации синхронизации агента с менеджером выходит за рамки настоящего стандарта. Если синхронизация времени используется, то об этом сообщается в атрибуте Mds-Time-Info объекта MDS.

9 Тестовые ассоциации

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

9.1 Поведение при стандартной конфигурации

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

Агент термометра в течение 30 секунд после входа в состояние «Выполнение» (Operating) должен передать одно имитированное значение температуры со значением 59,99 °C (значение, никогда не встречающееся при нормальном использовании и выходящее за пределы нормального диапазона). Если реализован атрибут measurement-status числового объекта, то должен быть установлен бит test-data.

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

9.2 Поведение при расширенных конфигурациях

Данная спецификация не описывает тестовую ассоциацию, использующую расширенную конфигурацию.

10 Соответствие

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

Настоящий стандарт должен использоваться в сочетании с IEEE 11073-20601.

Реализация или система может соответствовать следующим элементам настоящего стандарта:

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

10.2 Спецификация соответствия

Настоящий стандарт предлагает уровни соответствия, требующие строгого соблюдения, в отношении стандартного устройства и использования расширений для следующих областей:

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

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

Спецификации должны быть представлены в виде заявлений о соответствии реализации (ICSs), подробно описанных в разделе 10.4.

Данный стандарт используется в сочетании с IEEE 11073-20601. Рекомендуется формировать заявление о соответствии реализации (ICS) в первую очередь для настоящего стандарта, чтобы заявления ICS, сформированные для IEEE 11073-20601, могли затем ссылаться на заявления ICS для настоящего стандарта, где это применимо.

10.3 Уровни соответствия

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

Настоящий стандарт определяет следующие уровни соответствия.

10.3.2 Уровень соответствия 1. Базовое соответствие

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

10.3.3 Уровень соответствия 2. Расширенная номенклатура (нотация ASN.1 и/или ISO/IEEE 11073-10101:2004)

Уровень соответствия 2 удовлетворяет уровню соответствия 1, а также использует расширения по крайней мере в одной из информационных, сервисных, коммуникационных или номенклатурных моделей или добавляет их к ним. Расширения номенклатурных кодов должны соответствовать ISO/IEEE 11073-10101 и находиться в пределах частного диапазона расширения номенклатуры (0xF000 — 0xFFFF).

Там, где это уместно, расширения информационных или сервисных моделей должны быть полностью определены с использованием нотации ASN.1 и их поведение должно быть полностью описано в соответствии с положениями IEEE 11073-20601 и/или ISO/IEEE 11073-20101. Все расширения должны быть указаны и должны включать ссылку на описание расширения, а при отсутствии общедоступной ссылки к заявлению о соответствии должно быть приложено само описание расширения.

10.4 Заявления о соответствии реализации

10.4.1 Общий формат

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

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

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

a) индекс: идентификатор (например, метка) конкретного элемента;

b) свойство: кратко описывает характерную особенность, о которой делается заявление о соответствии;

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

d) требование/статус: определяет требование соответствия (обязательное, рекомендуемое и т.д.), в некоторых случаях настоящий стандарт не указывает требования соответствия, но требует определения статуса характерного свойства;

e) поддержка: указывает на наличие или отсутствие свойства и содержит характеристики свойства реализации. Эта графа должна быть заполнена разработчиком;

f) комментарий: содержит любую дополнительную информацию об этом свойстве. Эта графа должна быть заполнена разработчиком.

Подразделы 10.4.2 - 10.4.6 определяют формат конкретных таблиц заявления о соответствии реализации ICS.

10.4.2 Общее заявление о соответствии реализации

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

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

Таблица 8

Таблица общих заявлений о соответствии реализации IEEE 11073-10408

10.4.3 Заявления о соответствии реализации класса управляемых объектов информационной модели предметной области

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

Шаблон таблицы заявления о соответствии реализации класса

В реализации, имеющей предварительно определенные объекты, вместо буквы n в графе «Индекс» должен быть указан дескриптор объекта. В противном случае вместо нее должен быть указан просто уникальный номер (1...m).

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

В графе «Поддержка» необходимо указывать любые ограничения на реализацию объекта.

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

10.4.4 Заявление о соответствии реализации атрибутов класса управляемых объектов

Заявление о соответствии реализации атрибутов класса управляемых объектов определяет, какие атрибуты, включая любые унаследованные атрибуты, используются/поддерживаются в каждом реализованном объекте. Информация о каждом атрибуте объекта должна быть предоставлена отдельной строкой в шаблоне таблицы 10. По каждому объекту должно предоставляться отдельное заявление о соответствии реализации атрибутов объектов управляемых классов.

Таблица 10

Шаблон таблицы заявления о соответствии реализации атрибутов класса управляемых объектов

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

Буква n в графе «Индекс» обозначает идентификатор управляемого объекта, для которого предоставляется таблица (т.е. индекс управляемого объекта, указанный в заявлении о соответствии реализации объекта управляемого класса). Для каждого поддерживаемого управляемого объекта составляется отдельная таблица.

Буква x в графе «Индекс» обозначает уникальный порядковый номер (1...m).

10.4.5 Заявление о соответствии реализации уведомлений класса управляемых объектов

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

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

Буква x в графе «Индекс» обозначает уникальный порядковый номер (1...m).

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

10.4.6 Заявление о соответствии номенклатуры класса управляемых объектов

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

Шаблон для таблицы заявления о соответствии номенклатуры класса управляемых объектов

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

БИБЛИОГРАФИЯ

<6> Обозначения стандартов или документов IEEE, упомянутые в этом пункте, являются товарными знаками Института инженеров электротехники и радиоэлектроники (Institute of Electrical and Electronics Engineers, Inc.)

<7> Публикации ISO/IEEE можно получить в Центральном секретариате ИСО, Case Postale 56, 1 rue de Varembé , CH-1211, Genève 20, Швейцария/Suisse (http://www.iso.ch/). Публикации ISO/IEEE можно также получить в Соединенных Штатах Америки в Институте электротехники и инженеров-электроников, 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/).

<8> Публикации ITU можно получить в Международном союзе электросвязи, Place des Nations, 1211 Geneva 20, Switzerland. (http://www.itu.in/).

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

ПРИСВОЕНИЕ ИДЕНТИФИКАТОРОВ

В данном приложении приведены номенклатурные коды, используемые в настоящем стандарте и отсутствующие в IEEE 11073-20601. Нормативные определения, отсутствующие в данном приложении, приведены в IEEE 11073-20601-2014.

Использованный ниже формат соответствует формату ISO/IEEE 11073-10101.

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

b) Вследствие этого агент передает менеджеру информацию о своей конфигурации. После получения подтверждения от менеджера, принявшего конфигурацию агента, прибор агента готов передавать измерения. Оба прибора переходят в состояние «Выполнение» (Operating). Соответствующие примеры PDU приведены в E.3.2.2 и E.3.2.3.

c) Затем менеджер запрашивает атрибуты объекта MDS агента, отправляя сообщение, содержащее команду «Remote Operation Invoke | Get». В ответ агент передает менеджеру свои атрибуты объекта MDS, используя сообщение, содержащее команду «Remote Operation Response | Get». Соответствующие примеры PDU приведены в E.4.2 и E.4.3.

d) На следующем этапе пользователь прибора агента выполняет одно измерение. Данные измерения передаются менеджеру с помощью подтверждаемого отчета о событии. После успешного получения данных измерения менеджер отправляет агенту подтверждение. Соответствующие примеры PDU приведены в E.5.1 и E.5.2.

e) Пользователь завершает сеанс измерения (например, нажав соответствующую кнопку на устройстве или просто не используя устройство более определенного периода времени). В результате агент разъединяется с менеджером, отправляя запрос на завершение ассоциации. Менеджер возвращает ответ на завершение ассоциации. Соответствующие примеры PDU приведены в E.6.1 и E.6.2.

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

g) Наконец, два последних показанных шага аналогичны действиям, описанным в перечислениях d) и e). Пользователь выполняет одно подтверждаемое измерение, за которым следует завершение ассоциации.

Рисунок D.1 — Диаграмма последовательности для примера использования термометра

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

ПРИМЕРЫ БЛОКА ДАННЫХ ПРОТОКОЛА

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

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

E.2 Обмен информацией об ассоциации

E.2.1 Общие положения

Когда установлено транспортное соединение между менеджером и агентом, то они оба переходят в состояние «Не ассоциирован (Unassociated). Когда агент передает запрос ассоциации, то менеджер и агент переходят в состояние „Ассоциирующий“ (Associating).»

E.2.2 Расширенная конфигурация

E.2.2.1 Общие положения

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

E.2.2.2 Запрос ассоциации

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

E.2.2.3 Ответ на запрос ассоциации

Менеджер отвечает агенту, что он может установить ассоциацию, но не имеет расширенной конфигурации термометра (т.е. агент должен послать свою конфигурацию).

E.2.3 Ранее известная расширенная конфигурация

E.2.3.1 Общие положения

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

E.2.3.2 Запрос ассоциации

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

Это точно такое же сообщение, как и в E.2.2.2; коды приведены там.

E.2.3.3 Ответ на запрос ассоциации

Менеджер отвечает агенту, что он может установить ассоциацию, распознает, принимает и имеет расширенную конфигурацию термометра (т.е. агенту не нужно передавать свою конфигурацию).

E.2.4 Стандартная конфигурация

E.2.4.1 Общие положения

Данная транзакция может произойти, если агент представит запрос ассоциации, содержащий идентификатор dev-config-id, соответствующий стандартной конфигурации. Менеджер имеет конфигурацию, поскольку он запрограммирован на эту конфигурацию в соответствии с информацией, представленной в настоящем стандарте.

E.2.4.2 Запрос ассоциации

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

E.2.4.3 Ответ на запрос ассоциации

Менеджер отвечает агенту, что может установить ассоциацию, распознает, принимает и имеет стандартную конфигурацию термометра (т.е. агенту не нужно передавать свою конфигурацию). Менеджер не начинает тестовую ассоциацию.

E.3 Обмен информацией о конфигурации

E.3.1 Общие положения

Если ассоциация не отклонена или не прекращена, то агент и менеджер переходят из состояния «Ассоциирующий» (Associating) в одно из двух состояний. Если менеджер возвращает код результата ассоциирования «accepted», то агент и менеджер переходят в состояние «Выполнение» (Operating). Если менеджер возвращает код результата ассоциирования «accepted-unknown-config», то агент и менеджер переходят в состояние «Конфигурирующий» (Configuring).

E.3.2 Расширенная конфигурация

E.3.2.1 Общие положения

Данный обмен имеет место, когда менеджер возвращает код результата ассоциирования «accepted-unknown-config». Агент предоставляет описание своей конфигурации, соответствующей идентификатору dev-config-id, который он представил в запросе ассоциации.

E.3.2.2 Удаленный вызов операции события отчета о конфигурации

Агент термометра передает описание своей расширенной конфигурации. Он делает это с помощью передачи подтверждаемого отчета о событии типа MDC_NOTI_CONFIG.

E.3.2.3 Ответ на удаленный вызов операции отчета о событии конфигурации

Менеджер отвечает, что может использовать конфигурацию агента. Менеджер делает это, передавая ответ на подтверждаемый отчет о событии, в котором поле config-result имеет значение «accepted-config».

E.3.3 Известная конфигурация

E.3.3.1 Общие положения

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

E.3.3.2 Удаленный вызов операции события отчета о конфигурации

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

E.3.3.3 Ответ на удаленный вызов операции события отчета о конфигурации

Состояние «Конфигурирующий» (Configuring) было пропущено. Агентом не сформирован отчет о событии, поэтому менеджер не генерирует никакого ответа.

E.3.4 Стандартная конфигурация

E.3.4.1 Общие положения

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

E.3.4.2 Удаленный вызов операции события отчета о конфигурации

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

E.3.4.3 Ответ на удаленный вызов операции события отчета о конфигурации

Состояние «Конфигурирующий» (Configuring) было пропущено. Агентом не сформирован отчет о событии, поэтому менеджер не генерирует никакого ответа.

E.4 Сервис GET для получения атрибутов системы медицинского прибора (MDS)

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

Сервис GET для получения атрибутов MDS вызывается в любое время, когда агент находится в состоянии «Ассоциирован» (Associated).

E.4.2 Запрос сервиса GET на получение всех атрибутов MDS

Менеджер запрашивает у агента его атрибуты объекта MDS.

E.4.3 Ответ на запрос сервиса GET всех атрибутов MDS

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

E.5 Предоставление данных

E.5.1 Подтверждаемая передача данных измерений

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

E.5.2 Ответ на подтверждаемую передачу данных измерений

Менеджер подтверждает получение от агента отчета о событии.

E.6 Завершение ассоциации

E.6.1 Запрос завершения ассоциации

Агент термометра отправляет менеджеру следующее сообщение:

СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ НАЦИОНАЛЬНЫМ СТАНДАРТАМ

Таблица ДА