Этот документ описывает информационное моделирование и реализацию широкого спектра персональных медицинских приборов. Настоящий стандарт конкретизирует его требования для приборов, осуществляющих мониторинг артериального давления. В нем описаны все аспекты, необходимые для реализации служб прикладного уровня и протокола обмена данными между агентом монитора артериального давления, соответствующим настоящему стандарту, и менеджером измеренных данных. Настоящий стандарт определяет подмножество объектов и функций, описанных в документе IEEE Std 11073-20601, и при необходимости дополняет и расширяет эти описания. Все новые определения приведены в приложении Б, используя Абстрактную синтаксическую нотацию версии один (АСН.1) [B7]. Нормативные определения тех номенклатурных кодов, что использованы в настоящем стандарте, но отсутствуют в документе IEEE Std 11073-20601, приведены в приложении В.
4.2.1 Общие сведения
Серия стандартов ИСО/ИИЭР 11073 и, в частности, документ IEEE Std 11073-20601 основаны на объектно-ориентированной парадигме управления системами. Общая модель системы делится на три принципиально важных компонента: информационную модель предметной области DIM (domain information model), сервисную модель и коммуникационную модель. Детальное описание конструкций этих моделей см. в документе IEEE Std 11073-20601.
4.2.2 Информационная модель предметной области
Информационная модель DIM представляет собой иерархическую модель, описывающего агента в виде совокупности объектов. Эти объекты и их атрибуты представляют элементы, управляющие поведением агента, информирующие о статусе агента и данных, которые агент может передать менеджеру. Обмен данными между агентом и менеджером определен прикладным протоколом, описанным в документе IEEE Std 11073-20601.
4.2.3 Сервисная модель
Сервисная модель описывает концептуальные механизмы служб обмена данными. Такие службы отображаются на сообщения, которыми обмениваются агент и менеджер. В серии стандартов ИСО/ИИЭР 11073 протокольные сообщения определены на языке АСН.1. Сообщения, определенные в документе IEEE Std 11073-20601, могут сосуществовать с сообщениями, определенными в других стандартных прикладных профилях, описанных в серии стандартов ИСО/ИИЭР 11073.
4.2.4 Коммуникационная модель
В целом коммуникационная модель поддерживает топологию, при которой один или несколько агентов взаимодействуют с одним менеджером по логическим соединениям точка-точка. Для каждого такого соединения динамическое поведение системы определяется машиной перехода состояний, описанной в документе IEEE Std 11073-20601.
4.2.5 Реализация моделей
Агент, соответствующий настоящему стандарту, должен реализовать все обязательные элементы информационной, сервисной и коммуникационной модели, а также все условно обязательные элементы в случае выполнения соответствующего условия. Агенту следует обеспечить реализацию рекомендованных элементов. Он может обеспечить реализацию любого сочетания необязательных элементов. Менеджер, соответствующий настоящему стандарту, должен использовать хотя бы один из обязательных, условных, рекомендованных или необязательных элементов. В данном контексте "использовать" означает использование элемента как части основной функции устройства менеджера. Например, менеджер, основной функцией которого является визуализация данных, должен отображать на устройстве вывода часть данных элемента.
В настоящем разделе представлены основные понятия, описывающие приборы мониторинга артериального давления. В контексте персональных медицинских приборов, описываемых в данном семействе стандартов, монитор артериального давления представляет собой прибор, который неинвазивно измеряет кровяное давление (то есть систолическое, диастолическое и среднее артериальное давление (САД)) и необязательно пульс. Приборы, предназначенные для мониторинга артериального давления и рассматриваемые в настоящем стандарте, обычно накачивают воздухом манжету, сжимающую артерию, и затем измеряют реакцию артерии на постепенное падение давления, чтобы получить значения систолического и диастолического давления, а также САД. Кроме того, в то же самое время может определяться частота пульса.
Для измерения артериального давления и частоты пульса мониторы могут использовать разные методы. Типичным является осциллометрический метод, при котором для получения значений давления анализируются колебания давления в манжете. При другом методе - автоматизированном аускультативном - прибор с помощью микрофона обнаруживает тоны Короткова в процессе падения давления в манжете. Аускультативные приборы измеряют систолическое и диастолическое давления, а также САД.
В домашних мониторах обычно используется осциллометрический метод, позволяющий осуществлять электронные измерения давления. По этому методу анализируются малые изменения давления (осцилляции), происходящие в манжете в результате толчков кровяного давления в процессе ее накачивания или спуска. Эти осцилляции, которые сначала возрастают, а затем убывают, хранятся вместе с соответствующими значениями давления в манжете, измеряемые автоматизированным сфигмоманометром. С помощью математических методов по сохраненным значениям осцилляции и давления могут быть получены значения систолического и диастолического давления, а также САД.
Исторически единицами измерения кровяного давления служат миллиметры ртутного столба (мм. рт. ст.). Могут также использоваться килопаскали (кПа). Настоящий стандарт допускает использование как мм. рт. ст., так и мм. рт. ст.
Измерения систолического и диастолического давления указывают наибольшее и наименьшее значение давления в течение сердечного цикла. Обычно для полной информации о состоянии сердца и сердечно-сосудистой системы одного числа недостаточно, поэтому предусматриваются измерения как систолического, так и диастолического давления. Согласно настоящему стандарту, оба этих значения давления всегда передаются вместе.
Среднее артериальное давление передается в тех же единицах измерения, что и систолическое и диастолическое давление. Оно передается одновременно с систолическим и диастолическим давлением. В настоящем стандарте оно является обязательным.
Единицами измерения частоты пульса служат удары в минуту (уд/мин). В настоящем стандарте поддерживается передача частоты пульса, но в некоторых конфигурациях она является необязательной.
В настоящем разделе описана информационная модель предметной области мониторинга артериального давления.
В настоящем стандарте нет расширений классов, описанных в документе IEEE Std 11073-20601.
Диаграмма классов объектов информационной модели DIM, представляющей предметную область мониторинга артериального давления в целях настоящего стандарта, показана на рисунке 1.
![]() модель предметной области
Объекты модели DIM, показанной на рисунке 1, описаны в подразделах 6.4 - 6.12. Они включают в себя объект системы медицинского прибора (СМП) (подраздел 6.5), числовые объекты (подраздел 6.6), объекты массива показателей, снимаемых в режиме реального времени (МП-РВ) (подраздел 6.7), объекты перечислимых значений (подраздел 6.8), объекты хранилища постоянных метрик (ПМ-хранилища, подраздел 6.9) и объекты сканера (подраздел 6.10). Правила расширения информационной модели мониторинга артериального давления, представленной в настоящем стандарте, описаны в подразделе 6.11. Каждый подраздел, описывающий объект монитора артериального давления, содержит следующую информацию:
- номенклатурный код, используемый для идентификации класса объекта. Примером его использования служит событие конфигурации, при котором для каждого объекта передается его класс. Это позволяет менеджеру определить, является ли данный объект числовым, массивом показателей реального времени, перечислением, сканером или классом ПМ-хранилища;
- атрибуты объекта. Каждый объект имеет атрибуты, представляющие и передающие информацию о физическом устройстве и источниках его данных. Каждый объект имеет атрибут Handle, идентифицирующий экземпляр данного объекта в агенте. Значения атрибутов считываются и модифицируются, используя такие методы, как GET и SET. Типы атрибутов определены с помощью нотации АСН.1. Определения новых типов атрибутов, специфичных для настоящего стандарта, приведены в приложении Б, а определения уже существующих типов атрибутов, используемых в настоящем стандарте, приведены в документе IEEE Std 11073-20601;
- доступные методы объекта;
- потенциальные события, генерируемые объектом. Данные передаются менеджеру при наступлении событий;
- доступные службы, например, чтение атрибутов или присвоение им значений.
Атрибуты каждого класса определены в таблицах, указывающих имя атрибута, его значение и его квалификатор. Квалификаторы имеют значения "О" - атрибут обязателен, "У" - атрибут обязателен при условии, описанном в столбце "Примечание" или "Значение" (при ссылке на документ IEEE Std 11073-20601 условия берутся из него), "Р" - атрибут рекомендован, "НР" - атрибут не рекомендован и "Н" - атрибут не обязателен. В агенте должны быть реализованы обязательные атрибуты. Условные атрибуты должны быть реализованы при выполнении условия и могут быть реализованы, если условие не выполнено. Рекомендованные атрибуты следует реализовать. Не рекомендованные атрибуты реализовать не следует. Необязательные атрибуты могут быть реализованы в агенте.
Атрибуты могут быть статическими, то есть они остаются неизменными после согласования конфигурации, или динамическими, то есть они могут изменяться в какие-то моменты после конфигурации.
Информационная модель предметной области монитора кровяного давления показана на рисунке 1.
6.4.1 Общие сведения
Как указано в документе IEEE Std 11073-20601, имеются два доступных стиля конфигурации. Стандартная и расширенная конфигурация кратко описаны в 6.4.2 и 6.4.3 соответственно.
6.4.2 Стандартная конфигурация
Стандартные конфигурации определяются в специализациях стандартов IEEE 11073-104zz (например, в данном стандарте). Им присваивается хорошо известный идентификатор (Dev-Configuration-Id). Использование стандартной ситуации согласуется в момент осуществления ассоциации между агентом и менеджером. Если менеджер подтверждает, что он распознал и готов использовать конфигурацию, то агент может немедленно начать передачу измеренных данных. Если менеджер не распознал конфигурацию, то агент передает ее до передачи информации об измерениях.
Расширенные конфигурации агента не являются предопределенными в стандарте. Агент описывает объекты, атрибуты и значения, которые он собирается использовать в конфигурации, и присваивает идентификатор конфигурации. В процессе ассоциирования с менеджером агент согласует приемлемую конфигурацию. Обычно при первом соединении менеджер не распознает конфигурацию агента, поэтому он отвечает, что агент должен передать информацию конфигурации в форме отчета о событии конфигурации. Если же менеджер уже распознал конфигурацию, поскольку она уже была каким-либо образом загружена либо агент уже был ассоциирован с менеджером ранее, то менеджер отвечает, что конфигурация известна и дальнейшую информацию конфигурации передавать не требуется.
В таблице 1 перечислены атрибуты объекта монитора кровяного давления MDS. Классу MDS присвоен код номенклатуры MDC_MOC_VMS_MDS_SIMP.
Таблица 1
Примечание - Информацию о том, является ли атрибут статическим или динамическим, см. в IEEE Std 11073-20601.
В ответ на команду Get MDS Object (получить объект СМП) возвращаются только реализованные атрибуты и их значения.
Полное описание отдельных атрибутов, а также информацию об идентификаторе и типе атрибута см. в IEEE Std 11073-20601.
Атрибут Dev-Configuration-Id содержит местный уникальный 16-битовый идентификатор конфигурации прибора. Как показано в таблице 1, для агента монитора кровяного давления этот идентификатор выбирается из диапазона значений [extended-config-start, extended-config-end].
Находясь в состоянии Associating ("ассоциирующий", см. 8.3), агент передает атрибут Dev-Configuration-Id для идентификации своей конфигурации в течение ассоциации. Если менеджер уже содержит информацию об ассоциации с идентификатором Dev-Configuration-Id, то он распознает эту конфигурацию. Тогда переход в состояние Configuring ("конфигурирую") пропускается, после чего агент и менеджер переходят в состояние Configuring ("конфигурирую").
Если агент реализует несколько спецификаций IEEE 11073-104zz, то атрибут System-Type-Spec-List содержит список пар "тип" - "версия", каждая из которых ссылается на соответствующую специализацию устройства и версию этой специализации.
6.5.2 Методы объекта MDS
Методы (действия) объекта MDS приведены в таблице 2. Эти методы вызываются с помощью службы Action. В таблице 2 графа "Имя компонента службы" содержит имя метода; в графе "Режим" указано, вызывается ли метод как неподтверждаемое действие (то есть задан атрибут roiv-cmip-action) или как подтверждаемое действие (то есть задан атрибут roiv-cmip-confirmed-action); в графе "Тип компонента службы (action-type)" указан номенклатурный код, используемый в поле action-type запроса действия и ответа результата (см. IEEE Std 11073-20601); в графе "Параметры (action-info-args)" содержится ассоциированная структура данных АСН.1 (см. определения на языке АСН.1 в IEEE Std 11073-20601), используемая в поле сообщения запроса действия action-info-args; в графе "Результаты (action-info-args)" структура, используемая в поле action-info-args ответа.
Таблица 2
Методы объекта MDS
Метод Set-Time
Этот метод позволяет менеджеру установить абсолютное время на часах реального времени, встроенных в агент. Признак, что время может быть установлено, передается агентом в бите mds-time-capab-set-clock атрибута Mds-Time-Info (см. IEEE Std 11073-20601). Агенты, у которых есть встроенные часы реального времени, должны указывать это в бите mds-time-capab-real-time-clock атрибута Mds-Time-Info.
Если в агенте поддерживается атрибут штампа абсолютного времени Absolute-Time-Stamp, то этот метод следует реализовать.
Агенты, у которых нет других специализаций, кроме данной, должны передавать отчеты о событиях (см. 6.5.3), используя передачу измеренных данных, ассоциируемую агентом. При выполнении процедуры ассоциирования (см. 8.3) параметру ata-req-modecapab должно быть присвоено соответствующее значение, описывающее стиль отчета о событиях. Вследствие этого менеджер должен считать, что агент монитора кровяного давления не поддерживает никакие функции MDS-Data-Request (дополнительную информацию см. в IEEE Std 11073-20601). Счетчику ata-req-init-manager-count должно быть присвоено нулевое значение, а счетчику data-req-init-agent-count - значение 1).
Агенты, имеющие другие специализации, кроме данной, должны передавать отчеты о событиях соответствующим образом. При выполнении процедуры ассоциирования (см. 8.3) параметру ata-req-modecapab должно быть присвоено соответствующее значение, описывающее стиль отчета о событиях.
В таблице 3 приведены события, которые может передавать объект MDS монитора кровяного давления.
Таблица 3
В таблице приведены 3 следующие события:
- MDS-Configuration-Event: информация об этом событии передается агентом монитора кровяного давления при выполнении процесса конфигурирования, если менеджер еще не распознал конфигурацию этого агента при предшествующих ассоциациях или его реализация не позволяет распознать конфигурацию в соответствии со специализацией монитора кровяного давления. По этому событию передается статическая информация о возможностях измерений, поддерживаемых агентом монитора кровяного давления;
- MDS-Dynamic-Data-Update-Var: по этому событию агент монитора кровяного давления передает динамические измеренные значения числовых объектов диастолического давления, систолического давления, пульса и, необязательно, САД. Эти данные передаются в формате общего атрибута списка переменных как незатребованное сообщение (то есть передача измеренных данных, инициированная агентом). Дополнительные сведения о незатребованном отчете о событии см. в 8.5.3;
- 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, только позволяет включать данные нескольких лиц.
6.5.4 Другие службы MDS
6.5.4.1 Служба GET
Агент монитора кровяного давления должен поддерживать службу GET, предусмотренную в объекте MDS для извлечения значений всех его реализованных атрибутов. Служба GET может вызываться, как только агент монитора кровяного давления получит ответ об ассоциации и перейдет в состояние Associated ("ассоциирован"), включая подсостояния Operating ("выполнение") и Configuring ("конфигурирую").
Менеджер может запросить у агента монитора кровяного давления атрибуты объекта MDS. Для этого он должен послать агенту сообщение "Remote Operation Invoke | Get" (см. описание параметра roiv-cmip-get в IEEE Std 11073-20601), в котором идентификатор handle объекта MDS имеет зарезервированное значение 0. Агент монитора кровяного давления должен возвратить менеджеру реализованным им атрибуты объекта MDS, используя сообщение "Remote Operation Response | Get" (см. описание параметра rors-cmip-get в IEEE Std 11073-20601). Сводка параметров службы GET, включая некоторые поля сообщений, приведена в таблице 4.
Таблица 4
Детали процедуры получения атрибутов объекта MDS см. в 8.5.2.
6.5.4.2 Служба SET
Для специализации монитора кровяного давления не требуется реализация службы SET объекта MDS.
6.6.1 Общие сведения
Модель предметной области кровяного давления (см. рисунок 1) содержит два числовых объекта: обязательный составной объект для систолического давления, диастолического давления и САД, и необязательный числовой объект для частоты пульса. Они описаны в пунктах 6.6.2 - 6.6.3.
Иногда интерпретация значения одного атрибута объекта зависит от значений других атрибутов этого же объекта. Например, значения атрибутов Unit-Code и Unit-LabelString служат контекстом для измеренных значений. Если значение атрибута, входящего в контекст изменилось, то агент должен сообщить эти изменения менеджеру, используя события объекта MDS (см. 6.5.3), до передачи любого зависимого значения.
В таблице 5 приведены атрибуты составного числового объекта, в котором передаются значения систолического давления, диастолического давления и САД. Класс этого объекта идентифицируется номенклатурным кодом MDC_MOC_VMO_METRIC_NU. Агент монитора кровяного давления должен поддерживать этот составной числовой объект.
Таблица 5
"систолическое/диастолическое/САД"
Примечание - Информацию о том, является ли атрибут статическим или динамическим, см. в IEEE Std 11073-20601.
Измерения систолического давления, диастолического давления и САД передаются вместе с общим штампом даты и времени несмотря на то, что значения давления измеряются в разное время из-за сдувания манжеты и регистрации стабильного значения. Если агент не измеряет какой-либо из этих параметров, то в качестве его значения должно передаваться особое значение NaN (Not a Number - не число). Важно группировать значения, которые передаются как множество.
В стандартной конфигурации монитора кровяного давления структура AttrValMap (см. IEEE Std 11073-20601) атрибута Attribute-Value-Map должна содержать идентификатор атрибута и длину информации, содержащейся в атрибутах Compound-Basic-Nu-Observed-Value и Absolute-Time-Stamp, в том же порядке, что указан в таблице 5. Атрибут Metric-Id-List должен содержать все три значения и в том же порядке, что указан в этой таблице.
Составной числовой объект "систолическое/диастолическое/САД" не поддерживает никаких методов, событий или других служб.
Описательные разъяснения отдельных атрибутов, а также информацию об идентификаторе и типе каждого атрибута см. в IEEE Std 11073-20601.
В таблице 6 приведены атрибуты числового объекта, в котором передаются значения частоты пульса. Класс этого объекта идентифицируется номенклатурным кодом MDC_MOC_VMO_METRIC_NU. Агенту монитора кровяного давления следует поддерживать этот числовой объект. Он должен присутствовать в стандартной конфигурации.
Таблица 6
В стандартной конфигурации монитора кровяного давления структура AttrValMap (см. IEEE Std 11073-20601) атрибута Attribute-Value-Map должна содержать идентификатор атрибута и длину информации, содержащейся в атрибутах Basic-Nu-Observed-Value и Absolute-Time-Stamp, в том же порядке, что указан в таблице 6.
Числовой объект "частота пульса" не поддерживает никаких методов, событий или других служб.
Описательные разъяснения отдельных атрибутов, а также информацию об идентификаторе и типе каждого атрибута см. в IEEE Std 11073-20601.
Объекты массива считываний реального времени не требуются настоящим стандартом.
Объекты массива перечислений не требуются настоящим стандартом.
Объекты РМ-блока не требуются настоящим стандартом.
Объекты сканера не требуются настоящим стандартом.
В настоящем стандарте не определены объекты расширения класса, соответствующие IEEE Std 11073-20601.
При необходимости модель предметной области монитора кровяного давления, определенная в настоящем стандарте, может быть расширена метриками и атрибутами, специфичными для производителя. Любое реализованное расширение объекта или атрибута должно следовать указаниям настоящего стандарта как можно точнее.
В соответствии с настоящим стандартом идентификатор конфигурации агента монитора кровяного давления, имеющей расширения по отношению к стандартной конфигурации, должен находиться в диапазоне идентификаторов, зарезервированном для расширенных конфигураций (см. IEEE Std 11073-20601).
Сервисная модель определяет концептуальные механизмы служб обмена данными. Эти службы отображаются на сообщения, которыми обмениваются агент и менеджер. В серии стандартов ИСО/ИИЭР 11073 определения сообщения даются в нотации АСН.1. Детальное описание сервисной модели персонального медицинского прибора приведено в IEEE Std 11073-20601. В подразделах 7.2 и 7.3 определена специфика служб доступа к объектам и сообщений о событиях для монитора кровяного давления, соответствующая этому документу.
Для доступа к объектам, определенным в модели предметной области монитора кровяного давления, используются службы доступа к объектам, описанные в IEEE Std 11073-20601.
В соответствии с настоящим стандартом агент монитора кровяного давления поддерживает следующие общие службы доступа к объектам:
- GET: используется менеджером для извлечения значений атрибутов объекта MDS, которым оперирует агент. Список этих атрибутов приведен в 6.5.1;
- SET: используется менеджером для задания значений атрибутов объекта, которым оперирует агент. В соответствии с настоящим стандартом для агента монитора кровяного давления не заданы никакие атрибуты, изменяемые менеджером;
- EVENT REPORT: используется агентом для передачи менеджеру сведений о конфигурации и измеренных данных. Список сообщений о событиях, определенных для специализации монитора кровяного давления, приведен в 6.5.3;
- ACTION: используется менеджером для вызова действий (или методов), поддерживаемых агентом. Примером может служить действие Set-Time, используемое для установки абсолютного времени на часах реального времени агента.
В таблице 7 приведены службы доступа к объектам, описанные в настоящем стандарте.
Службы сообщений о событиях (см. таблицу 7) используются агентом для передачи своей информации (например, измеренных данных). В настоящем стандарте сообщения о событиях являются свойствами только объекта MDS. Сообщения о событиях, используемые в настоящем стандарте, определены в IEEE Std 11073-20601.
Таблица 7
В соответствии с настоящим стандартом агент монитора кровяного давления должен удовлетворять следующим условиям:
- сообщения о событиях должны использоваться в режиме подтверждения (confirmed);
- для передачи измеренных данных должен использоваться режим инициации агентом.
Агент монитора кровяного давления, рассчитанный на среду, в которой данные могут собираться о нескольких лицах, может использовать один из нескольких стилей передачи сообщений о нескольких лицах для передачи всех данных о каждом лице в одном событии. Если эта функциональность не требуется, то агент может использовать стили передачи сообщений об одном лице, имеющие пониженные накладные расходы.
Менеджер должен поддерживать получение сообщений о событиях, в которых передаются данные об одном лице или о нескольких лицах. Форматы сообщений данных об одном лице и о нескольких лицах описаны в IEEE Std 11073-20601.
В настоящем разделе описана общая коммуникационная модель и процедуры агента монитора кровяного давления в соответствии с определениями, приведенными в IEEE Std 11073-20601. Поэтому соответствующие части IEEE Std 11073-20601 не воспроизводятся; изложение ограничено специфичным выбором и ограничениями для необязательных элементов (а именно, объектов, атрибутов и действий) и описанием специфичных расширений (например, номенклатурных терминов).
Иллюстративный обзор различных транзакций передачи сообщений в типичном сеансе измерений приведен в форме диаграмм последовательности в приложении D, а примеры соответствующих блоков данных протокола PDU (protocol data unit) приведены в приложении E.
В настоящем подразделе определены ограничения размера блоков данных протокола прикладного уровня APDU (application protocol data unit), передаваемых или получаемых агентом монитора кровяного давления. Небольшие размеры позволяют упростить реализацию в терминах меньшей стоимости и сложности.
Для агента монитора кровяного давления, не реализующего других специализаций приборов, кроме описанной в настоящем стандарте, максимальный размер передаваемого блока APDU не должен превышать Ntx. В настоящем стандарте Ntx = 896 октетов. Агент, удовлетворяющий данному определению, должен быть способен принимать блоки APDU размером до Nrx включительно. В настоящем стандарте Nrx = 224 октета.
Для агента монитора кровяного давления, реализующего функции специализаций других приборов, верхняя оценка размеров блоков APDU определяется следующим образом: агент не должен передавать блоки APDU, размер которых превышает сумму ограничений Ntx всех реализованных им специализаций приборов, и должен принимать блоки APDU, размер которых не превышает сумму ограничений Nrx всех реализованных им специализаций приборов. Если эти границы превышают максимальные размеры, определенные в IEEE Std 11073-20601, то должны применяться эти размеры.
Если ограничение на размер блока APDU не позволяет агенту включить в одно сообщение все результаты текущих измерений, то он должен посылать эти результаты в виде нескольких сообщений. Максимальное число измеренных данных, которые разрешается включать в одно сообщение о событии, приведено в 8.5.3.
8.3.1 Общие сведения
Если в настоящем стандарте не указано иное, процедура ассоциирования агента монитора кровяного давления и менеджера должна осуществляться в соответствии с IEEE Std 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 (то есть protocol-version = 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 field должно быть присвоено значение атрибута System-Id объекта MDS, которым оперирует агент. Менеджер может использовать это поле для определения идентичности монитора артериального давления, с которым он ассоциируется, и, необязательно, реализовать простую политику ограничения доступа;
7) полю dev-config-id должно быть присвоено значение атрибута Dev-Configuration-Id объекта MDS, которым оперирует агент;
8) если агент поддерживает только специализацию монитора кровяного давления, то полю, указывающему режимы запроса данных (data-req-mode-capab), поддерживаемые агентом монитора кровяного давления, должно быть присвоено значение data-req-supp-init-agent;
9) если агент поддерживает только специализацию монитора кровяного давления, то счетчику data-req-init-manager-count должно быть присвоено значение 0, а полю data-req-init-agent-count shall должно быть присвоено значение 1.
8.3.3 Процедура менеджера. Ответ на запрос ассоциирования
К ответу на запрос ассоциации, передаваемому менеджером, предъявляются следующие требования:
- полю result должно быть присвоено значение из числа тех, что определены в IEEE Std 11073-20601. Например, если все другие условия протокола ассоциирования выполнены, то возвращается значение accepted, если менеджер распознал идентификатор конфигурации агента (dev-config-id), и значение 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 должно быть присвоено значение 0;
9) полю data-req-init-*-count должно быть присвоено значение 0.
8.4.1 Общие сведения
Агент переходит в состояние Configuring ("конфигурирую"), если получен ответ "accepted-unknown-config" на запрос ассоциации. В этом случае должна быть выполнена процедура конфигурирования, специфицированная в IEEE Std 11073-20601. В подразделах 8.4.2 - 8.6 описаны сообщения уведомления о конфигурации и ответного сообщения для агента монитора кровяного давления, имеющего стандартную конфигурацию с идентификатором 0x02BC. Обычно менеджер должен уже знать стандартную конфигурацию. Однако приборы, имеющие стандартную конфигурацию, должны посылать ее по запросу. Это покрывает тот случай, когда менеджер еще не имеет заранее предоставленного знания стандартной конфигурации (например, из-за несовпадения версий агента и менеджера).
Агент выполняет процедуру конфигурирования, передавая менеджеру сообщение "Remote Operation Invoke | Confirmed Event Report" о событии MDC_NOTI_CONFIG (см. IEEE Std 11073-20601). В поле event-info используется структура ConfigReport (см. таблицу 3). Для агента монитора кровяного давления со стандартной конфигурацией, имеющей идентификатор 0x02BC, сообщение уведомления о конфигурации имеет следующие формат и содержание:
8.4.3 Процедура менеджера
Менеджер должен ответить на сообщение с уведомлением о конфигурации, используя сообщение "Remote Operation Response | Confirmed Event Report" о событии MDC_NOTI_CONFIG. В поле event-info используется структура ConfigReportRsp (см. таблицу 3). Ответ на сообщение уведомления о стандартной конфигурации, описанное в 8.4.2.1, имеет следующие формат и содержание:
8.5.1 Общие сведения
Измеренные данные и информация о статусе передаются агентом монитора кровяного давления, находящемся в состоянии Operating ("выполнение"). Если в настоящем стандарте не указано иное, процедура выполнения измерений агентом монитора кровяного давления должна осуществляться в соответствии с IEEE Std 11073-20601.
Краткие сведения о службе 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 Std 11073-20601), в котором поле ошибки error-value содержит значение "no-such-action" (9).
Краткие сведения о службах сообщений о событиях, предназначенных для передачи измеренных данных приведены в таблице 3. В соответствии с настоящим стандартом передача измеренных данных агентом монитора кровяного давления всегда должна инициироваться монитором кровяного давления (см. описание передачи измеренных данных, инициируемой агентом, в IEEE Std 11073-20601). Чтобы ограничить число данных, передаваемых в блоке APDU, агент монитора кровяного давления не должен включать в одно сообщение о событии более 25 временно хранящихся результатов измерений. Если для передачи доступно более 25 текущих измерений, то они должны передаваться в нескольких сообщениях о событиях. Если доступно несколько текущих измерений, то до 25 результатов измерений следует передавать в одном сообщении о событии. Как альтернатива, можно передавать каждый результат измерения в одном сообщении о событии. Однако рекомендуется предыдущая стратегия, поскольку он снижает суммарный размер сообщений и потребление электропитания.
Синхронизация времени между агентом монитора кровяного давления и менеджером может использоваться для координации показаний часов, используемых при регистрации физиологических событий. Следует иметь в виду, что механизм синхронизации агента и менеджера не входит в область применения настоящего стандарта. Если синхронизации времени используется, то она должна отражаться в атрибуте Mds-Time-Info объекта MDS.
В мониторе кровяного давления может быть реализован широкий спектр поведения при тестовой ассоциации, позволяющий производителю тщательно тестировать возможности изделия. Монитор кровяного давления может вообще не поддерживать тестовую ассоциацию. В настоящем разделе описано простое поведение, которое симулирует генерация измеренных данных в контексте стандартной конфигурации прибора.
Для облегчения стандартизованных процессов автоматического тестирования монитору кровяного давления, представляющему идентификатор стандартной конфигурации и входящему в тестовую ассоциацию, следует иметь возможность симулировать получение измеренных данных от сенсоров прибора. Такое симулирование, обеспечивающее генерацию измеренных данных, не обязательно должно осуществляться оператором.
Когда агент перейдет в состояние "Operating" (выполнение), он симулирует получение от сенсоров события измерения систолического давления, диастолического давления, САД и пульса со значениями 60 мм рт. ст., 40 мм рт. ст., 46 мм рт. ст. и 210 ударов в минуту (BPM) соответственно. По возможности это измерение должно быть видимо только теми компонентами агента, которые распознают тестовую ассоциацию. Когда событие распространяется на числовой объект, то бит test-data атрибута measurement-status должен быть установлен (при условии, что этот атрибут поддерживается). От агента не требуется использование атрибута measurement-status, если он обычно не делает это вне тестовой ассоциации.
Агент должен передать сообщения о событиях для всех симулированных измерений в течение 30 с после перехода в состояние "Operating". Тестовая ассоциация завершается способом, совместимым с нормальным поведением агента при завершении ассоциации.
Настоящий стандарт не определяет тестовую ассоциацию для расширенных конфигураций.
Настоящий стандарт должен использоваться совместно с IEEE Std 11073-20601.
Реализация или система может соответствовать следующим элементам настоящего стандарта:
- иерархия классов информационной модели предметной области и определения объектов (атрибуты объектов, уведомления, методы и определения типов данных);
- значения номенклатурных кодов;
- протокол и сервисные модели;
- коммуникационная сервисная модель (ассоциация и конфигурация).
Настоящий стандарт предусматривает уровни соответствия относительно строго следования стандартному прибору и следующего использования расширений:
- для информационной модели конкретного прибора;
- для использования атрибутов, диапазонов значений и методов доступа.
Производитель может специфицировать уровень соответствия его реализации, основываясь на настоящем стандарте, и предоставить детали способа применения определений настоящего стандарта и всех расширений.
Спецификации должны быть предоставлены в форме набора объявлений соответствия реализации (ОСР), детализированных в 9.4.
Поскольку настоящий стандарт используется совместно с IEEE Std 11073-20601, то ОСР должны быть созданы сначала для этого стандарта. ОСР, созданные для IEEE Std 11073-20601, могут при необходимости содержать ссылки на ОСР, созданные для настоящего стандарта.
10.3.1 Общие сведения
Настоящий стандарт определяет описанные ниже уровни соответствия.
Приложение использует элементы информационной, сервисной и коммуникационной модели (иерархия объектов, действия, сообщения о событиях и определения типов данных) и схему номенклатуры, определенную в стандартах IEEE Std 11073-20601 и IEEE 11073-104zz. Все обязательные свойства, указанные в таблицах определения объектов и таблицах ОСР, реализованы. Кроме того, все реализованные условные, рекомендованные или необязательные свойства должны следовать требованиям документов IEEE Std 11073-20601 и IEEE 11073-104zz.
На уровне соответствия 2 выполнены все требования уровня соответствия 1, но, кроме того, использованы или добавлены расширения по крайней мере в одну из моделей, указанных в 9.3.2. Эти расширения должны соответствовать номенклатурным кодам, описанным в нотации АСН.1 и/или в документе ИСО/ИИЭР 11073-10101 [B4] (0xF000 - 0xFFFF). Эти расширения должны быть определены в таблицах ОСР в форме ссылок.
10.4.1 Общий формат
ОСР предоставляются как общий документ объявления соответствия, состоящий из ряда таблиц в форме, заданной шаблонами в следующих разделах.
Каждая таблица ОСР имеет следующие графы:
Заголовки граф имеют следующее значение:
- "Индекс": идентификатор (например, тег) конкретного свойства;
- "Свойство": краткое описание характеристики, для которой делается объявление о соответствии;
- "Ссылка": указание раздела/абзаца в настоящем документе или внешнем источнике, содержащем определение свойства (может быть пустым);
- "Требование/статус": указание требования соответствия (например обязательное или рекомендованное) - в некоторых случаях стандарт не описывает требование соответствия, но требует предоставление статуса конкретного свойства;
- "Поддержка": указывает наличие или отсутствие свойства в реализации и содержит произвольное описание реализованных характеристик этого свойства. Данная графа должна заполняться реализующей стороной;
- "Примечание": содержит любые дополнительные сведения о свойстве. Данная графа должна заполняться реализующей стороной.
В пунктах 10.4.2 - 10.4.6 приведен формат конкретных таблиц ОСР.
10.4.2 Общее объявление соответствия реализации
В общем ОСР указаны версии/редакции, поддерживаемые реализацией, и высокоуровневое поведение системы.
Общие ОСР приведены в таблице 8.
Таблица 8
Таблица общих ОСР настоящего стандарта
--------------------------------
10.4.3 Объявление соответствия реализации информационной модели классов управляемых объектов
В объявлении соответствия реализации информационной модели классов управляемых объектов указано, какие объекты реализованы. Информация о каждом объекте должна быть записана в отдельной строке шаблона, представленного таблицей 9.
Таблица 9
управляемых объектов
Для реализаций, имеющих предопределенные объекты, в качестве "n" в графе "Индекс" должен быть указан идентификатор объекта. В противном случае в этой графе должен быть указан просто уникальный номер (1..m).
Должны быть указаны все местные объекты. Графа "Ссылка" должна содержать ссылку на определение объекта, а если общедоступного документа нет, то к объявлению соответствия должно быть добавлено определение объекта.
В графе "Поддержка" должны быть указаны все ограничения на реализацию объекта.
Как часть ОСР информационной модели классов управляемых объектов должна быть представлена диаграмма объектов (диаграмма экземпляров классов).
10.4.4 Объявление соответствия реализации атрибутов классов управляемых объектов
Для каждого поддерживаемого объекта, описанного в ОСР информационной модели классов управляемых объектов, должно быть подготовлено ОСР атрибутов классов управляемых объектов, в котором описано, какие атрибуты используются/поддерживаются данной реализацией (включая унаследованные атрибуты). Таблица служит только шаблоном.
Таблица 10
Шаблон таблицы ОСР атрибутов классов управляемых объектов
Должны быть указаны все местные атрибуты. Графа "Ссылка" должна содержать ссылку на определение атрибута, а если общедоступного документа нет, то к объявлению соответствия должно быть добавлено определение атрибута.
В графе "Поддержка" должно быть указано, реализован ли атрибут; для местного атрибута должно быть указано, является ли значение атрибута статическими или динамическим, приведены диапазоны допустимых значений, ограничения доступа или доступности атрибута и любая прочая информация.
Буква "n" в графе "Индекс" означает идентификатор управляемого объекта, для которого предоставлена таблица атрибутов (то есть индекс управляемого объекта, указанный в ОСР информационной модели классов управляемых объектов. Для каждого поддерживаемого управляемого объекта создается отдельная таблица.
Буква "n" в графе "Индекс" означает уникальный последовательный номер (1..m).
Примечание - Таблицы определения атрибутов в стандарте определяют минимальный обязательный набор атрибутов каждого объекта.
10.4.5 Объявление соответствия реализации уведомлений классов управляемых объектов
В ОСР уведомлений классов управляемых объектов указаны все реализованные уведомления (обычно в форме службы сообщений о событиях), инициируемые агентом. В таблице 11 предложен шаблон для использования. Для каждого объекта, поддерживающего специальные уведомления о себе, должна быть предоставлена одна таблица. Каждое уведомление описано одной строкой этой таблицы.
Таблица 11
Шаблон таблицы ОСР уведомлений классов управляемых объектов
Буква "n" в графе "Индекс" означает идентификатор управляемого объекта, для которого предоставлена таблица уведомлений (то есть индекс управляемого объекта, указанный в ОСР информационной модели классов управляемых объектов. Для каждого управляемого объекта, поддерживающего специфичные уведомления об объекте (то есть события)), создается отдельная таблица.
Буква "n" в графе "Индекс" означает уникальный последовательный номер (1..m).
Должны быть указаны все местные уведомления. Графа "Ссылка" должна содержать ссылку на определение уведомления, а если общедоступного документа нет, то к объявлению соответствия должно быть добавлено определение уведомления.
В ОСР номенклатуры классов управляемых объектов указаны все нестандартные номенклатурные коды, используемые агентом. В таблице 12 предложен шаблон для использования. Каждый номенклатурный элемент описан одной строкой этой таблицы.
Таблица 12
управляемых объектов
Буква "n" в графе "Индекс" означает уникальный последовательный номер (1..m).
(справочное)
--------------------------------
<1> Публикации IEC можно получить в департаменте продаж Международной электротехнической комиссии (Sales Department of the International Electrotechnical Commission, 3, rue de
, P.O. Box 131, CH-1211 Geneva 20, Switzerland, /template/go.php?url=https://www.iec.ch/). В США Публикации IEC можно также получить в департаменте продаж Американского национального института стандартов (Sales Department, American National Standards Institute, 25 West 43rd Street, 4th Floor, New York, NY 10036, USA, /template/go.php?url=https://www.ansi.org/). Публикации в стадии утверждения FDIS можно получить в Центральном секретариате ИСО (ISO Central Secretariat, 1, ch. de la Voie-Creuse, Case postale 56, CH-1211, Geneva 20, Switzerland, /template/go.php?url=https://www.iso.ch/).<2> Публикации IEEE можно получить в Институте инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854, USA, /template/go.php?url=https://standards.ieee.org/).
<3> Публикации ISO/IEEE можно получить в Центральном секретариате ИСО (ISO Central Secretariat, 1, ch. de la Voie-Creuse, Case postale 56, CH-1211, Geneva 20, Switzerland, /template/go.php?url=https://www.iso.ch/). В США Публикации ISO/IEEE можно также получить в Институте инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854, USA, /template/go.php?url=https://standards.ieee.org/).
<4> Публикации ITU можно получить в Международном союзе электросвязи (International Telecommunications Union, Place des Nations, 1211 Geneva 20, Switzerland, /template/go.php?url=https://www.itu.in/).
(обязательное)
Дополнительные определения в нотации АСН.1 отсутствуют.
(обязательное)
Настоящее приложение содержит номенклатурные коды, используемые в настоящем стандарте и отсутствующие в документе IEEE Std 11073-20601. Коды, не указанные в настоящем приложении, должны быть взяты из IEEE Std 11073-20601.
Используемый здесь формат позаимствован из IEEE Std 11073-10101.
(справочное)
На рисунке D.1 показана диаграмма последовательности обмена сообщениями, соответствующая следующему сценарию. Пользователь агента монитора кровяного давления собирается впервые соединиться с менеджером. Монитор кровяного давления способен измерять давление и пульс. Конфигурация аналогична стандартной, но в данном примере включает в сообщение конфигурации дополнительные атрибуты, например, точность. Таким образом, агент действует в расширенной конфигурации. Обмен сообщениями в этом случае осуществляется следующим образом:
a) когда пользователь инициирует соединение монитора кровяного давления с менеджером, то менеджер не распознает конфигурацию агента и посылает ответ "accepted-unknown-config" на запрос ассоциации, полученный от агента. Соответствующие примеры блоков PDU см. в E.2.2.2 и E.2.2.3;
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.1.2 и E.4.1.3. Менеджер может запросить атрибуты объекта MDS, как только агент перейдет в состояние "Associated", охватывающее состояния "Configuring" и "Operating";
d) на следующем шаге пользователь монитора выполняет одно измерение. Измеренные данные передаются менеджеру, используя подтверждаемое сообщение о событии. После успешного получения измеренных данных менеджер посылает агенту подтверждение. Соответствующие примеры блоков PDU см. в E.5.1 и E.5.2;
e) пользователь завершил сеанс измерения (например, нажал на приборе соответствующую кнопку или просто в течение некоторого времени не использовал прибор). В этом случае агент завершает ассоциацию с менеджером, послав ему запрос завершения ассоциации. Менеджер возвращает ему подтверждение завершения ассоциации. Соответствующие примеры блоков PDU см. в E.6.1 и E.6.2;
f) когда при следующем сеансе измерений (например, на следующий день) агент посылает менеджеру запрос ассоциации, то менеджер возвращает ему позитивное подтверждение, поскольку он уже знает конфигурацию агента по предыдущему сеансу измерений. Оба прибора - агент и менеджер - переходят в состояние "Operating";
g) в заключение выполняются два шага, аналогичные описанным в d) и e). Пользователь выполняет одно подтверждаемое измерение, после чего ассоциация завершается.
![]() использования монитора кровяного давления
(справочное)
E.1 Общие положения
В настоящем приложении показаны примеры двоичных сообщений в кодировке MDER, которыми обмениваются агент монитора кровяного давления и менеджер. Три разных сценария обменов информации об ассоциации и конфигурации представлены в E.2 и E.2.3. Первый сценарий иллюстрирует случай, когда агент собирается действовать в расширенной конфигурации. При этом у менеджера нет информации о его конфигурации, которая могла бы быть получена при предыдущей ассоциации. Во втором сценарии агент вновь передает менеджеру идентификатор той же самой расширенной конфигурации. Менеджер уже имеет ее, получив при предыдущем обмене данными конфигурации. Наконец, агент передает менеджеру идентификатор стандартной конфигурации, и менеджер распознает ее, поскольку он запрограммирован для ее использования.
E.2 Обмен информацией ассоциации
E.2.1 Общие сведения
Когда между менеджером и агентом устанавливается транспортное соединение, оба переходят в состояние "Unassociated" (не ассоциирован). Когда агент передает запрос ассоциации, оба переходят в состояние "Associating" (установка ассоциации).
E.2.2.1 Общие сведения
При этом обмене агент отправляет запрос ассоциации, намереваясь использовать расширенную конфигурацию при передаче измеренных данных. Однако менеджеру эта конфигурация еще не известна.
Агент монитора кровяного давления намерен использовать расширенную конфигурацию и отправляет менеджеру следующее сообщение.
Менеджер отвечает агенту, что может ассоциироваться, но не распознал расширенную конфигурацию монитора кровяного давления (то есть нужно, чтобы агент передал свою конфигурацию).
E.2.3.1 Общие сведения
Этот обмен иллюстрирует транзакцию, имеющую место после того, как сеанс начался с обмена, подобного описанному в E.2.2.
E.2.3.2 Запрос ассоциации
Агент монитора кровяного давления намерен использовать расширенную конфигурацию и отправляет менеджеру следующее сообщение.
E.2.3.3 Ответ на запрос ассоциации
Менеджер отвечает агенту, что может ассоциироваться, распознал расширенную конфигурацию монитора кровяного давления и подтвердил, что имеет ее (то есть не нужно, чтобы агент передал свою конфигурацию).
E.2.4 Стандартная конфигурация
E.2.4.1 Общие сведения
Эта транзакция происходит, когда агент отправляет запрос ассоциации, в котором идентификатор dev-config-id соответствует стандартной конфигурации. Менеджер распознает ее, поскольку он запрограммирован для ее использования в соответствии с информацией, предоставленной в настоящем стандарте.
E.2.4.2 Запрос ассоциации
Агент монитора кровяного давления намерен использовать стандартную конфигурацию и отправляет менеджеру следующее сообщение. В нем он запрашивает тестовую ассоциацию в соответствии с определением, приведенным в разделе 10.
E.2.4.3 Ответ на запрос ассоциации
Менеджер отвечает агенту, что может ассоциироваться, распознал стандартную конфигурацию монитора кровяного давления и подтвердил, что имеет ее (то есть не нужно, чтобы агент передал свою конфигурацию). Менеджер не начинает тестовую ассоциацию.
E.3 Обмен информацией конфигурации
E.3.1 Общие сведения
Если запрос ассоциации не отклонен и не прерван, то агент и менеджер переходят из состояния "Associating" в одно из двух состояний. Если код результата AssociateResult равен "accepted", то агент и менеджер переходят в состояние "Operating". Если код результата AssociateResult равен "accepted-unknown-config", то агент и менеджер переходят в состояние "Configuring".
E.3.2 Расширенная конфигурация
E.3.2.1 Общие сведения
Этот обмен имеет место, если менеджер возвратил код результата AssociateResult, равный "accepted-unknown-config". Агент предоставляет менеджеру описание своей конфигурации, соответствующей идентификатору dev-config-id, который он передал в запросе ассоциации. В данном примере конфигурация агента почти эквивалентна стандартной конфигурации. Единственное отличие состоит в том, что в оба объекта добавлен атрибут точности accuracy.
Агент монитора кровяного давления передает описание своей расширенной конфигурации, отправляя подтверждаемое сообщение о событии типа MDC_NOTI_CONFIG.
Менеджер отвечает, что может использовать конфигурацию агента, посылая подтверждаемое сообщение о событии ответа, в котором поле config-result имеет значение "accepted-config".
E.3.3 Известная конфигурация
E.3.3.1 Общие сведения
Этот обмен имеет место, если менеджер возвратил код AssociateResult, имеющий значение "accepted", поскольку ранее он уже получил и обработал конфигурацию с идентификатором, переданным агентом в поле dev-config-id. В этом случае информация конфигурации не передается, а менеджер и агент переходят в состояние "Operating".
E.3.3.2 Дистанционная операция инициирования сообщения о событии конфигурации
Поскольку менеджер уже распознал конфигурацию агента, то переход в состояние "Configuring" пропускается, и агент не инициирует передачу сообщения о событии.
E.3.3.3 Дистанционная операция сообщения ответа на событие конфигурации
Состояние "Configuring" было пропущено, агент не инициировал передачу сообщения о событии, поэтому менеджер не генерирует никакой ответ.
E.3.4 Стандартная конфигурация
E.3.4.1 Общие сведения
Этот обмен имеет место, если менеджер возвратил код AssociateResult, имеющий значение "accepted", поскольку ранее он запрограммирован на документированную в стандарте конфигурацию с идентификатором, переданным агентом в поле dev-config-id. В этом случае нет обмена информацией конфигурации, а менеджер и агент переходят в состояние "Operating". Если же менеджер возвратил значение "accepted-unknown-config", то осуществляется передача информации конфигурации, описанная в 8.4.2.
E.3.4.2 Дистанционная операция инициирования сообщения о событии конфигурации
Поскольку менеджер запрограммирован на конфигурацию агента, то переход в состояние "Configuring" пропускается, и агент не инициирует передачу сообщения о событии.
E.3.4.3 Дистанционная операция сообщения ответа на событие конфигурации
Состояние "Configuring" было пропущено. Агент не инициировал передачу сообщения о событии, поэтому менеджер не генерирует никакой ответ.
E.4 Сервис GET запроса атрибутов объекта MDS
E.4.1.1 Общие сведения
Сервис GET запроса атрибутов объекта MDS инициируется в любое время, пока монитор находится в состоянии "Associated".
Менеджер запрашивает у агента атрибуты объекта MDS.
Агент монитора кровяного артериального давления возвращает менеджеру сведения о своих атрибутах. Кроме того, в его сообщении заполнены некоторые необязательные поля.
E.5 Передача данных
Агент спонтанно передает менеджеру сообщение о событии измерения показателей.
Менеджер подтверждает получение от агента сообщения о событии.
E.6 Завершение ассоциации
Агент монитора кровяного давления передает менеджеру следующее сообщение.
Менеджер сообщает агенту, что может завершить ассоциацию.
Использование стандарта ИИЭР всецело добровольное. ИИЭР не несет ответственности за любой вред, причиненный здоровью или собственности, либо за другие убытки любого характера, будь то особые, косвенные, вытекающие или возмещаемые, прямо или косвенно связанные с публикацией, ее использованием или доверием к ней, а также к другим стандартизующим документам ИИЭР.
ИИЭР не гарантирует и не формулирует точность или содержания приведенного здесь материала, и полностью отрицает любую гарантию, в том числе любую подразумеваемую гарантию его коммерческой ценности или пригодности для конкретной цели, а также не гарантирует, что содержащейся здесь материал не нарушает какие-либо патенты. Стандарты ИИЭР предоставляются "как есть".
Из существования стандарта ИИЭР не следует, что не существуют другие способы производства, тестирования, измерения, приобретения, выпуска на рынок или предоставления иных товаров и услуг, относящихся к области применения стандарта ИИЭР. Далее, точка зрения, выраженная во время утверждения и публикации стандарта, может быть изменена после тщательного анализа положения дел и получения комментариев от пользователей стандарта. Каждый стандарт ИИЭР должен рассматриваться на предмет пересмотра или подтверждения не реже, чем один раз в пять лет. Если документу более пяти лет и он не был подтвержден, то разумно предполагать, что его содержание, хотя и может иметь определенную ценность, не полностью соответствует текущему положению дел. Пользователям рекомендуется проверять, имеется ли у них последняя редакция стандарта ИИЭР.
Публикуя и делая доступным этот документ, ИИЭР не преследует и не предоставляет профессиональные или иные услуги для какого-либо лица либо организации или по их поручению. Равным образом ИИЭР не собирается выполнять какую-либо деятельность вместо любого другого лица или организации. Любое лицо, использующие настоящий стандарт или другие стандартизующие документы ИИЭР, должно полагаться на совет компетентного специалиста в части применения правильного лечения в любых конкретных обстоятельствах.
Интерпретации: время от времени могут возникать вопросы о значении частей стандартов применительно к конкретным приложениям. Если потребность в интерпретации представлена вниманию ИИЭР, то Институт инициирует действия по подготовке соответствующего ответа. Поскольку ИИЭР представляет консенсус различных интересов, то важно понимать, что любая интерпретация также представляет собой баланс определенных интересов. По этой причине ИИЭР, члены его сообщества и Координирующие комитеты по стандартам (Standards Coordinating Committees) не в состоянии дать немедленный ответ на запрос интерпретации, за исключением тех случаев, когда такой же запрос ранее уже был формально рассмотрен. Лицо, представляющее информацию из стандартов ИИЭР на лекциях, симпозиумах, семинарах или учебных курсах, должно дать разъяснение, что его точка зрения должна рассматриваться как личная и не является формальной позицией, разъяснением или интерпретацией ИИЭР.
Комментарии для пересмотра стандартов ИИЭР приветствуются от любой стороны независимо от ее членства в ИИЭР. Предложения по изменению документов должны быть представлены в форме предлагаемых изменений текста в сочетании с соответствующими обоснованиями. Комментарии к стандартам и запросы интерпретации должны направляться по следующему адресу: Secretary, IEEE-SA Standards Board, 445 Hoes Lane, Piscataway, NJ 08854, USA.
Законодательство и регулирование. Пользователи этих документов должны консультироваться со всем применимым законодательством и регулированием. Соответствие положениям настоящего стандарта не влечет за собой соответствие любым применимым регуляторным требованиям. Лица и организации, реализующие настоящий стандарт, несут ответственность за ознакомление с применимыми регуляторными требованиями и за ссылки на них. Публикуя свои стандарты, ИИЭР не имеет намерения побуждать к действиям, не совместимым с применимым законодательством, и эти документы не могут быть истолкованы как побуждающие.
Авторские права. Авторские права на настоящий стандарт принадлежат ИИЭР. Он сделан доступным для широкого спектра публичного и частного использования, включая использование по ссылке в законах и других нормативных документах, а также для частного саморегулирования, стандартизации и продвижения в инженерной практике и методах. Делая настоящий стандарт доступным для использования и одобрения публичными органами и частными лицами, ИИЭР не передает им какую-либо часть авторских прав на него.
Внесение изменений в документы ИИЭР. Пользователи стандартов ИИЭР должны отдавать себе отчет, что эти документы могут быть в любое время пересмотрены выпуском новых изданий или изменены путем выпуска изменений, исправлений или устранения опечаток. В каждый момент времени официальный документ ИИЭР состоит из текущего издания и всех введенных в действие дополнений, исправлений и списков опечаток. Чтобы установить, является ли данный документ текущим изданием и были ли введены в действие дополнения, исправления и списки опечаток, следует посетить веб-сайт ИИЭР /template/go.php?url=https://ieeexplore.ieee.org/xpl/standards.jsp или обратиться к ИИЭР по указанному выше адресу.
Дополнительную информацию об Ассоциации стандартизации ИИЭР (IEEE Standards Association) или о процессе разработки стандартов ИИЭР можно получить на веб-сайте IEEESA /template/go.php?url=https://standards.ieee.org.
Опечатки. Список опечаток, если таковые были обнаружены, могут быть получены по следующему адресу в сети Интернет: /template/go.php?url=https://standards.ieee.org/reading/ieee/updates/errata/index.html. Пользователям рекомендуется периодически посещать этот адрес на предмет получения списка опечаток.
Интерпретации. Текущие интерпретации могут быть получены по следующему адресу в сети Интернет: /template/go.php?url=https://standards.ieee.org/reading/ieee/interp/index.html.
Патенты. Следует иметь в виду, что при реализации настоящего стандарта может потребоваться использование предметов патентных прав. При публикации настоящего стандарта не проводится никакое исследование существования или действительности патентных прав, связанных с его содержанием. ИИЭР не несет ответственности за идентификацию патентов, существенных для стандарта и требующих лицензионных отчислений, за проведение исследований правомерности или области применения заявок на патенты, а также определяет, являются ли термины или условия лицензирования, предложенные в гарантийном письме, если таковое имеется, или в лицензионных соглашениях разумными и недискриминационными. Пользователям настоящего стандарта настоятельно рекомендуется отдавать себе отчет, они несут полную ответственность за определение действительности любых патентных прав и риска их нарушения. Дополнительную информацию можно получить от Ассоциации стандартизации ИИЭР.
Участники. Список участников ИИЭР можно получить по следующему адресу в сети Интернет: /template/go.php?url=https://standards.ieee.org/downloads/11073/11073-10415/11073-10415-2010_wg_participants.pdf.
Важное замечание. Настоящий стандарт не предназначен для обеспечения физической и информационной безопасности, здоровья или защиты окружающей среды. Разработчики, реализующие настоящий стандарт, несут ответственность за применение необходимых мер, обеспечивающих физическую и информационную безопасность, защиту здоровья и окружающей среды, а также за соответствие нормативным требованиям.
Настоящий стандарт ИИЭР доступен для использования с важными замечаниями и юридическими оговорками. Эти замечания и оговорки присутствуют во всех публикациях, содержащих данный документ, под заголовками "Важное замечание" ("Important Notice") или "Важные замечания и юридические оговорки к документам ИИЭР" ("Important Notices and Disclaimers Concerning IEEE Documents"). Они могут быть также получены от ИИЭР по запросу или прочитаны по адресу /template/go.php?url=https://standards.ieee.org/IPR/disclaimers.html.
(справочное)
НАЦИОНАЛЬНЫМ СТАНДАРТАМ
Таблица ДА.1
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/prod/gost-r_gosudarstvennyj-standart/31/gost_89874.html
На правах рекламы:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||