ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ

Спецификация требований к организации информационного взаимодействия

Издание официальное

Предисловие

1    РАЗРАБОТАН Обществом с ограниченной ответственностью «НИИ экономики связи и информатики «Интерэкомс» (ООО «НИИ «Интерэкомс»)

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 100 «Стратегический и инновационный менеджмент»

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

4    ВВЕДЕН ВПЕРВЫЕ

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

© Стандартинформ, оформление, 2019

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

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

3.3.8    ICS-проформа (ICS proforma): Документ в виде опросника (анкеты), который после завершения реализации или системы становится ICS-заключением.

3.3.9    ICS-протокол (Protocol ICS, PICS): ICS-заключение для реализации или системы. утвержда-ющее о соответствии данной спецификации на протокол.

3.3.10    декларация о соответствии реализации функциональной совместимости (Interoperability ICS): ICS-декларация для реализации или системы, утверждающая о соответствии IFRS-требованиям.

3.3.11    рабочая группа по управлению объектами (Object Management Group. OMG): Промышленный консорциум, который устанавливает стандарты на распределенные объектно-ориентированные системы, на моделирование программ, систем и бизнес-процессов, а также на стандарты, основанные на моделях.

3.3.12    подтверждение (acknowledgement): Сообщение, формируемое в ответ на полученное сообщение и подтверждающее его прием или отклонение.

Примечание 1 — Подтверждение приема сообщения или положительное квитирование могут свидетельствовать о получении сообщения Кроме того, оно может подтверждать принятие операции и успешность ее выполнения

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

Пример — Механизм открывания дверей подтверждает, что он получил команду на их открытие, но но подтворждаот, что он действовал в соответствии с этой командой.

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

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

3.3.14    режим многоадресной адресации сообщений (broadcast): Режим связи, при котором сообщение адресуется всем объектам системы.

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

Пример — Произошло возгорание, открывайте все двери!

3.3.15    режим выполнения операции типа «не реже одного раза» (at least once): Семантики выполнения, при которых операция, запрашиваемая объектом (или после исполнения которой), может выполняться еще один или несколько раз.

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

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

3.3.16    режим выполнения операции типа «не более одного раза» (at most once): Семантики выполнения, при которых операция, запрашиваемая объектом (или после исполнения которой), может либо вообще не выполняться, либо выполняться еще только один раз.

Примечание — Операция не сможет выполняться более одного раза без перехода объекта в нестабильное состояние и без информирования заявителя (объекта) о том. что запрашиваемая операция была выполнена успешно

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

3.3.17    элементарность, атомарность (atomicity): Возможность разделения операций (или последовательности операций) на несколько субопераций.

Примечание — Последовательность операций называется «элементарной», если ее невозможно прервать или разделить на более дробные последовательности субопераций

3.3.18    согласованность (consistency): Состояние параметров, которые изменились в результате выполнения какой-либо операции (или последовательности операций), и должны находиться в диапазоне отклонений, указанном в приложении.

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

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

3.3.19    долговечность (durability): Сохранение результатов выполнения каких-либо операций и работоспособности системы (и ее элементов) при возникновении неисправностей (отказов) в ней.

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

3.3.20    режим выполнения операции типа «только один раз» (exactly once): Семантики выполнения. при которых операция, запрашиваемая объектом (или после исполнения которой), может выполняться еще только один раз.

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

Пример — Сделайте предварительный заказ, снимите 10 долларов США с моего банковского счета в коммерческом цонтро.

3.3.21    семантики выполнения операций (execution semantics): Определяют конечный результат выполнения операций, запрашиваемых объектом (или операций над объектом).

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

3.3.22    многоадресная передача сообщений (multicast): Режим связи, при котором сообщение адресуется всем объектам, которые подписали соглашение на использование закрепленных за ними адресов.

3.3.23    дистанционный режим работы, дистанционное управление (remote operation): Режим взаимодействия, в котором используется модель типа «Команда/Ответное сообщение об исполнении».

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

3.3.24    режим управления без получения подтверждения (unacknowledged): Вариант модели дистанционного управления, при котором в ответ на полученное сообщение никакое подтверждение (ответное сообщение) не формируется.

3.3.25    одноадресная передача сообщений (unicast): Режим связи, при котором сообщение адресуется единственному объекту, который подписал соглашение на использование закрепленного за ним адреса.

Примечание — Взаимодействия в модели типа «Комамда/Ответмое сообщение об исполнении* часто реализуются с использованием одноадресных сообщений.

Пример — Контроллер комфорт-системы запрашивает установленный в кухне датчик о температуре на ней.

3.4 Сокращения

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

АС — переменный ток (alternating current);

ACID — элементарность (атомарность) (А), согласованность (С), изолированность (I). долговечность (D) — это свойства взаимодействий, включая одновременное и совместное использование ресурсов нескольких распределенных объектов (atomic, consistent, isolated, durable);

ADSL — асимметричная цифровая абонентская линия связи (asymmetric DSL);

API — интерфейс прикладного программирования (application programming interface);

АРР — прикладной, представительский, транспортный и сеансовый уровни, характерные для настоящего стандарта (application, presentation, transport and session layers, specific to this technical specification);

AS — автономная система (autonomous system);

ASN.1 — абстрактная синтаксическая нотация, версия 1 (abstract syntax notation one);

ATM — асинхронный режим передачи данных (asynchronous transfer mode);

CDU — потребительский модуль индикации (дисплей) (consumer display unit);

DLC — управление каналом передачи данных (DLC-протокол) (data link control);

DLNA — альянс цифровых сетей для дома (digital living network alliance);

DOS — отказ от обслуживания (denial of service);

DSL — цифровая абонентская линия связи (DSL-протокол) (digital subscriber link);

DVB — цифровой широковещательный видеосигнал (цифровое телевидение) (digital video broadcast);

ETSI — европейский институт телекоммуникационных стандартов (european telecommunications standards institute);

FDL — язык формализованного описания (formal description language);

GPRS — пакетная радиосвязь общего пользования (general packet radio service);

GSM — глобальный стандарт цифровой мобильной сотовой связи (groupe special mobile, global system for mobiles);

HAN —домашняя локальная сеть (home area network):

HBES — электронные системы для жилых домов и общественных зданий (home and building electronic system);

HDMI — мультимедийный интерфейс высокого разрешения (HDMI-слецификация) (high-definition multimedia interface);

HES — домашние электронные системы (home electronic systems);

HSPA — высокоскоростная пакетная передача данных (high speed packet access);

HTTPS — протокол защищенной передачи гипертекстовой информации (hypertext transfer protocol-secure);

ЮТ — информационно-коммуникационные технологии (information and communications technologies);

I EC — международная электротехническая комиссия (international electrotechnical commission);

IEEE — институт инженеров электротехники и электроники (institute of electrical and electronics engineers);

IFRS — спецификация на базовые требования к функциональной совместимости (interoperability framework requirements specification);

IICS —декларация о соответствии реализации функциональной совместимости (interoperability implementation conformance statement);

IP — интернет-протокол (internet protocol);

IR — инфракрасный (infra-red);

IS — международный стандарт (international standard);

ISO — Международная организация no стандартизации (International standards organisation);

ISP — интернет-провайдер (internet service provider);

ITU-T — сектор стандартизации электросвязи Международного союза электросвязи (international telecommunications union-telecommunications);

LAN — локальная вычислительная сеть (local area network);

MAC — управление доступом к среде передачи или к каналу связи (medium access control);

MAC — код проверки подлинности сообщения (message authentication code);

Mbps — мегабит в секунду (megabit per second);

NWK — сеть (уровень эталонной модели взаимодействия открытых систем (OSI-RM)) (network (layer of the osi-rm));

OMG — группа по управлению объектами (OMG-стандарт) (object management group);

OSI — взаимодействие открытых систем (OSI-стандарт) (open system interconnection);

OSI-RM — эталонная модель взаимодействия открытых систем (reference model (for osi));

PC — персональный компьютер (ПК) (personal computer);

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

PGP — программа защиты сообщений с шифрованием («надежная конфиденциальность») (pretty good privacy);

PHY — физический уровень OSI-RM (physical (layer of the osi-rm));

PICS — заявка о соответствии реализации протоколу (protocol implementation conformance statement);

PIN — персональный идентификационный номер (personal identification number);

PIXIT — дополнительные данные о реализации протокола (protocol implementation extra information for testers);

PLC — технология связи по линиям электропередачи (powerline communications);

РРРоАТМ— протокол двухточечной связи (передачи) в ATM-режиме (point-to-point protocol over atm);

PSTN — коммутируемая телефонная сеть общего пользования (public switched telephone network);

QoS — качество сервиса (quality of service);

RJ45 — телекоммуникационное гнездо № 45. стандартизированное как TIA/EIA-568-B и используемое в телефонии и системах связи (registered jack no. 45 — standardised as tia/eia-568-b. used for telephony and communications applications);

RPC — дистанционный вызов процедур (remote procedure call);

RPC IDL — язык описания интерфейса для RPC (rpc interface definition language);

RS 232 — стандарт на последовательное соединение между терминальным оборудованием и терминальным оборудованием канала передачи данных. Стандартом ITU-T является V.24 (recommended standard 232. a standard for serial connection between a data tenninal equipment and a data circuit-terminating equipment, the itu-t standard is v.24.);

SDU — блок служебных данных (service data unit);

SLA — соглашение об уровне обслуживания (service level agreement);

SLR — требования к уровню обслуживания (service level requirement);

SMS — служба коротких сообщений (short message service);

SSL — уровень защищенных разъемов (SSL-протокол) (secure socket layer);

STB — ресивер цифрового телевидения (STB-декодер) (set top box);

TCP — протокол управления передачей данных (TCP-протокол) (transmission control protocol);

TRS — транспортный уровень OSI-RM (transport (layer of the osi-rm));

TS — техническая спецификация (technical specification);

UPnP — универсальный разъем (режим) Plug and Play (universal plug and play);

USB — универсальная последовательная шина (universal serial bus);

VC — виртуальная схема (канал) (virtual circuit);

VP — виртуальный путь (virtual path);

WAN — глобальная вычислительная сеть (wide area network);

WFi — беспроводный интернет, соответствующий IEEE 802.11 (wireless fidelity, ieee 802.11);

WiMAX —телекоммуникационная технология, разработанная с целью предоставления универсальной беспроводной связи на больших расстояниях для широкого спектра устройств (worldwide interoperability for microwave access);

XML — расширяемый язык разметки (extensible markup language).

4 Принципы функциональной совместимости

4.1    Функциональные этапы

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

В данном разделе описаны этапы обнаружения, конфигурирования, эксплуатации (функционирования) и управления, которые более подробно рассмотрены в А.З.

4.1.2    Этап обнаружения

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

4.1.3    Этап конфигурирования

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

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

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

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

4.1.4    Этап эксплуатации (функционирования)

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

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

4.1.5    Этап управления

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

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

4.2 Уровни функциональной совместимости

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

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

Для ныне предлагаемых приложений (а также для перспективных открытых систем) ситуация является полностью «прозрачной» из-за отсутствия набора всеобъемлющих, общих, открытых пользовательских требований, из которых вытекают системные/технические решения и требования к функциональной совместимости, которая должна поддерживаться на протяжении всего жизненного цикла системы, сохраняя при этом изменения, дополнения и обновления, предлагая «обратную» функциональную совместимость. Уровни 4—6 функциональной совместимости относятся к системам, которые отвечают этому требованию. В настоящем стандарте определены также требования к функциональной совместимости для систем, которые претендуют на соответствие Уровням 4—6.

Таблица 1 — Уровни функциональной совместимости

Уровень 0 Одиночная система со структурой, определяемой поставщиком и сформированной с помощью устройств, которые используют одну и ту же HBES-спецификацию и локально определяют функциональную совместимость, проверенную поставщиком для одного или нескольких доменов приложений При этом уверенность в сосуществовании объектов/при-ложений отсутствует Уровень 1 Система Уровня 0, функционирующая в одном или нескольких доменах приложений При этом необходима верификация сосуществования объектов/лриложений Уровень 2 Системы с несколькими Уровнями 1. которые взаимодействуют между собой для обмена информацией и функционально совместимы в различных доменах приложений и, с учетом различных спецификаций, верифицированы поставщиками с использованием спецификаций на соответствие, согласованных с помощью каждой из используемых HBES-спецификаций Уровень 3 Аналогичен Уровню 2. за исключением того, что функциональная совместимость проверяется на соответствие международным стандартам, которые распространяются на используемые в системе HBES-спецификации X в) (О X Ж Уровень 4 Аналогичен Уровню 3. но на котором лриложения/устройства соответствуют IFRS-спецификациям по функциональным возможностям и допускают установку, управление и внесение изменений квалифицированным установщиком в процессе функционирования системы <й ZT т о р С 89 О <0 ОС и. Уровень 5 Аналогичен Уровню 4. но на котором все изменения в приложениях/устройствах будут выполняться автоматически Уровень 6 Аналогичен Уровню 5. но при наличии дистанционного управления, диагностики и обслуживания (автоматической установки, эксплуатации и технической поддержки)

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

5 Условия соответствия

5.1    Требования соответствия к функциональной совместимости

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

Настоящий стандарт применим к системам/устройствам, для которых необходима функциональная совместимость на Уровнях 4. 5 и 6, однако для систем/устройств на Уровнях 0—3 какие-либо требования отсутствуют.

Ниже рассмотрены следующие общие требования к соответствию на Уровнях 4. 5 и 6.

5.1.2    Идентификатор объекта

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

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

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

Подробные требования к идентификатору приведены в 5.2.1.

5.1.3    Описание объекта

Любой идентифицируемый объект должен (при условии наличия прав доступа к нему) предоставлять сервисам/приложениям какой-либо системы (а также сервисам/приложениям, не принадлежащим

этой системе) свою спецификацию, информацию о состоянии (статусе) объекта и другую запрашиваемую информацию.

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

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

Подробные требования к состоянию (статусу) объекта см. 5.2.2 и ниже.

5.1.4    Обнаружение объекта

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

Подробные требования к этапу обнаружения приведены в 5.2.3.

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

5.1.5    Конфигурирование объекта

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

Подробные требования к процессу конфигурирования приведены в 5.2.4.

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

5.1.6    Эксплуатация объекта

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

Подробные требования к функционированию объекта приведены в 5.2.5.

5.1.7    Управление объектом

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

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

5.1.8    Требования безопасности и доступ к объекту

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

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

Подробные требования безопасности, доступа и защиты объекта приведены в 5.2.7.

5.2 Частные условия соответствия

5.2.1    Требования к описанию идентификатора объекта

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

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

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

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

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

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

• Другие постоянные идентификаторы, например, серийный номер.

5.2.2    Требования к функциональному описанию объекта

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

В соответствии с настоящим стандартом необходимый объем информации об объектах всегда должен быть доступен. За исключением случаев, когда четко не оговорено иное, к Уровням 4, 5 и 6 должны применяться следующие частные требования.

5.2.2.2    Классификация объектов

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

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

Операции должны определяться сигнатурой функции, включая входные, выходные и входные/ выходные данные и возвращаемые данные-результаты, а также определять принимаемые входные данные и данные, сформированные на выходе. Атрибуты могут включать в себя время на прием (ответ) запрашиваемой операции; скорость, с которой допускается запрос операции; ограничения на доступ к считыванию/записи информации; идентификаторы, используемые в протокольных блоках данных (PDU) для выделения (разграничения) полей, из которых они составлены, а также другую информацию, которую можно считать достаточной для обеспечения функциональной совместимости. Допустимые FDL-языки — это языки ASN.1, XML (при этом необходимо указывать стандартные OMG-схемы), Corba IDL, ISO RPC IDL, JSON. SENML. В тех случаях, когда тот или иной язык не позволяет работать с обязательной информацией, в описании следует указывать синтаксис, который можно использовать для описания этой информации. Кроме того, подобное описание должно содержать все необходимые данные в виде комментариев в тексте.

5.2.2.3    Функциональный интерфейс объекта

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

5.2.2    4 Интерфейс для обнаружения обьекта

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

5.2.2.5    Интерфейс для конфигурирования объекта

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

5.2.2.6    Интерфейс для управления объектом

Обьект должен предоставлять описание своих типов данных, операций и атрибутов, поддерживающих процесс управления им. Соответствие этому требованию является необязательным на Уровне 4. но обязательным — на Уровнях 5 и 6.

5.2.3    Требования к процессу обнаружения

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

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

5.2.3.2    Описания обьекта: самоописание и описание объектов, подлежащих обнаружению

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

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

5.2.3.3    Режим связи

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

5.2.3.4    Процесс обнаружения

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

5.2.3.5    Область обнаружения

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

5.2.3.6    Безопасность и конфиденциальность

См. 5.2.7.

5.2.4 Требования к процессу конфигурирования

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

За исключением случаев, когда иное однозначно не оговорено, следующие подпункты применимы к Уровням 4. 5 и 6.

5.2.4.2    Привязки

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

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

5.2.4.3    Режим связи

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

Содержание

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

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

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

3.1    Определения, связанные с безопасностью............................................2

3.2    Определения, связанные с процессами..............................................4

3.3    Определения, связанные с функциональной совместимостью............................5

3.4    Сокращения.....................................................................8

4    Принципы функциональной совместимости.............................................10

4.1    Функциональные этапы...........................................................10

4.2    Уровни функциональной совместимости.............................................11

5    Условия соответствия................................................................12

5.1    Требования соответствия к функциональной совместимости............................12

5.2    Частные условия соответствия....................................................14

Приложение А (справочное) Этапы обнаружения, конфигурирования, эксплуатации

и управления............................................................17

Приложение Б (справочное) Пример декларации о соответствии требованиям функциональной

совместимости......................................................... 44

5.2.4 4 Процесс конфигурирования

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

5.2.4.5    Безопасность и конфиденциальность

См. 5.2.7.

5.2.5    Требования к процессу эксплуатации

5.2.5.1    Эксплуатация приложения

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

5.2.5.2    Безопасность и конфиденциальность

См. 5.2.7.

5.2.6    Требования к процессу управления

5.2.6.1    Режим связи

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

5.2.6    2 Процесс управления

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

5.2.6.3    Безопасность и конфиденциальность

См. 5.2.7.

5.2.7    Требования к безопасности информации, ее защите, приоритету и доступу к информации объекта

5.2.7.1    Безопасность информации об объекте

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

5.2.7.2    Защита информации об объекте

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

5.2.7.3    Права доступа к информации объекта

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

5.2.7.4    Приоритет при контроле доступа к информации объекта

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

Для получения более подробной информации об этом см. А.7

Введение

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

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

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

-    взаимодействие — этап, на котором различные технологии объединяются для «сквозной» передачи данных. Это. прежде всего, относится к техническому решению, относящемуся к разъемам, протоколам. шлюзам и т. п.;

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

W Различные системы эффективно работают в собственных средах, связь между ними отсутствует

. ,шШт

■Mb' ⁷    НЯ

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

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

В настоящем стандарте не рассматривается вопрос сосуществования или взаимодействия систем на основе технологических стандартов.

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

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

СИСТЕМЫ ПРОМЫШЛЕННОЙ АВТОМАТИЗАЦИИ И ИНТЕГРАЦИЯ

Спецификация требований к организации информационного взаимодействия

Industrial automation systems and integration Requirement specification for organization of interoperability

Дата введения — 2020—01—01

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

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

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

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

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

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

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

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

ГОСТ Р ИСО/МЭК 9646 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования

Издание официальное

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

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

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

3.1    Определения, связанные с безопасностью

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

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

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

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

3.1.2    права доступа (access rights): Разрешение и возможность использования объекта для определенной цели — запроса информации от него, изменения значений параметров или изменения его состояния.

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

Пример —Доступ с правом считывания информации об общем параметре; разрешение на включе-нив/или выключение, т. е. выполнение определенных операций.

3.1.3    аутентификация (authentication): Процесс надежного установления подлинности объектов путем защищенного сопоставления предъявленного и хранящегося идентификатора объекта.

Примечание — Подтверждение предъявляемой идентификационной информации пользователя может выполняться путем проверки некоторых секретных сведений, ключа или свойства, связанных с этим пользователем, например, пароля, SSL-клкна, секретного PGP-ключа или подписи руки

3.1.4    авторизация (authorization): Решение о разрешении пользователю не выполнять никаких операций над объектом (запретить доступ), или выполнять над объектом операции одного или нескольких типов (разрешить доступ).

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

3.1.5    конфиденциальность (confidentiality): Свойство, позволяющее не предоставлять или не раскрывать информацию неавторизованным физическим лицам, организациям или процессам.

3.1.6    отказ от обслуживания (несанкционированное блокирование доступа к информации)

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

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

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

3.1.8    шифрование (encryption): Процесс маскировки данных для скрытия их содержания.

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

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

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

3.1.10    целостность (информации) (integrity): Состояние информации, при котором отсутствует любое ее изменение либо изменение осуществляется только преднамеренно субъектами, имеющими на него право.

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

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

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

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

3.1.13    приоритет (priority): Относительное упорядочение, придаваемое процессу/операции по отношению к другим процессам (операциям).

Пример — Жизненно важные процессы могут обладать более высоким приоритетом по отношению к другим пользовательским процессам.

3.1.14    конфиденциальность (защита информации от несанкционированного доступа)

(privacy): Защита информации, которая может быть реализована путем отслеживания операций в сети (см. термин «прослушивание»),

3.1.15    атака повторного воспроизведения сообщений (replay attack): Перехват и запись сообщений для их отправки в более поздние сроки с тем. чтобы их получатель, не осознавая этого, считал, что фиктивный трафик является законным.

3.1.16    непризнание участия (repudiation): Отрицание одним из субъектов информационного обмена причастности ко всему сообщению или к его частям.

3.1.17    защищенность (safety): Состояние уверенности в том. что при определенных условиях какой-либо агент не будет оказывать неблагоприятных воздействий.

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

3.1.18    безопасность (security): Правила и методики, устанавливаемые владельцами, которые призваны обеспечивать контроль за использованием их собственности другими владельцами.

Пример — Автовладельцам, которым выделены машиноместа, разрешено открывать гаражные ворота, а всем другим автовладельцам — запрещено.

3.1.19    требования безопасности (security requirements): Цель, задача и критерии успеха, относящиеся к приложению или сервису.

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

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

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

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

3.2 Определения, связанные с процессами

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

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

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

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

3.2.3    конфигурация (configuration): Набор параметров состояния объекта или устройства.

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

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

Пример — Объединение объектов одного устройства с объектами в других устройствах.

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

Примечание — Объекты могут предоставлять и указывать свои параметры или реагировать на широковещательную передачу для получения информации об определенных типах объектов

Пример — Набор сетевых протоколов UPnP.

3.2.6    процесс обнаружения (discovery process): Процесс выполнения операций по обнаружению.

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

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

Пример 1 — Функциональность IP-маршрутизации домашнего шлюза к ISP-службам позволяет межплатформенному программному обеспечению соединяться с интернет-провайдером с цолью регистрации локальных устройств, получения доступа к интернет-сервисам и маршрутизации IP-пакетов между локальными и внешними процессами.

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

3.2.8    операции (operations): Сервисные средства поддержки приложений, запрашиваемые объектами в системе, которые совместно реализуют какую-либо функцию.

3.2.9    управление системой (системный менеджмент) (system management): Сервисные средства поддержки приложений, запрашиваемые объектами в системе, которые не связаны с выполняемыми приложениями.

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

3.3 Определения, связанные с функциональной совместимостью

3.3.1    сосуществование (coexistence): Объекты и приложения, существующие в одной и той же операционной среде и не конфликтующие между собой.

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

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

3.3.2    функциональная совместимость (интероперабельность) (interoperability): Способность двух или более сетей, систем, устройств, приложений или компонентов обмениваться информацией и, при этом, использовать полученную информацию.

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

Пример — Домашний шлюз к ISP-сервисам обеспечивает взаимодействие между сетью Ethernet и WiFi-средой в домо, а также с ADSL-средой вне дома, с цолью поддержки маршрутизации IP-пакетов для взаимодействия между объектами-приложениями в доме (с помощью IP-протокола) и другими объектами-приложениями.

3.3.4    открытый стандарт (open standard): Общедоступный документ, утвержденный уполномоченными международными органами по стандартизации, в котором определены архитектура, функции, протоколы и критерии соответствия характеристик систем связи.

3.3.5    единая архитектура программы брокера объектных запросов (CORBA): Система для распределенной обработки, определенная рабочей группой OMG по управлению ОМ1-объектами.

3.3.6    язык формализованного описания (Formal Description Language, FDL): Машинно-обра-батываемые и формально определенные синтаксис и семантика для выражения абстрактных свойств системы.

3.3.7    декларация о соответствии реализации (Implementation Conformance Statement. ICS): Заключение. выдаваемое поставщиком реализации или системы, утверждающее их соответствие данной спецификации (с указанием, какие функциональные возможности реализованы).