3. Структура разделения видов отчетов кпд2 приведена на схеме 3.

Схема 3

4. Структура модулей протокола взаимодействия ПУ и ПТС ОРИ (ASN.1) приведена на схеме 4.

5. Модуль Classification.asn должен задавать правила, в соответствии с которыми:

1) выполняется расширение:

списка типов запросов к ПТС ОРИ;

списка видов поисковых критериев ПТС ОРИ;

списка типов отчетов, формируемых ПТС ОРИ;

2) выполняется ввод новых версий сообщений протокола.

6. В соответствии со схемами 2, 3 в модулях протокола взаимодействия ПУ и ПТС ОРИ (ASN.1) должна выполняться подстановка соответствующих версий форматов поисковых критериев, отчетов, справочников, "сообщений" интерфейса взаимодействия ПУ и ПТС ОРИ (ASN.1).

7. Модуль "Classification.asn" протокола взаимодействия ПУ и ПТС ОРИ (ASN.1) должен содержать кодированные в иерархическом виде идентификаторы:

1) видов "Сообщений" верхнего уровня интерфейса взаимодействия ПУ и ПТС ОРИ, составляющих кпд1, кпд2, кпд3, кпд4;

2) видов поисковых критериев для формирования задач к ПТС ОРИ;

3) видов форматов отчетов, формируемых ПТС ОРИ.

8. Соответствующие идентификаторы используются в других модулях интерфейса взаимодействия ПУ с ПТС ОРИ (ASN.1), при этом идентификатор должен определять конкретную версию и расширения формата соответствующего элемента (поисковых критериев, отчетов, справочников "сообщений").

9. При создании сессии ПТС ОРИ должны предоставить ПУ на согласование перечень идентификаторов; подмножество согласованных ПУ идентификаторов определяет конкретные возможности взаимодействия ПУ и ПТС ОРИ.

Схема 4

10. Расширение интерфейса взаимодействия ПУ с ПТС ОРИ должно обеспечиваться введением новых идентификаторов, определяющих соответствующие расширенные элементы (поисковые критерии, отчеты, справочники, "сообщения"). Кодирование новых вводимых идентификаторов элементов осуществляется в соответствии со структурами, представленными на схемах 2 и 3, и стандартным кодированием модуля "Classification.asn".

Описание протокола взаимодействия ПУ и ПТС ОРИ

См. приложение в редакторе Adobe Reader

Требования, предъявляемые к функционированию канала управления кпд1

1. ПТС ОРИ должны обеспечивать подключение ПУ и обработку поступающих запросов по каналу кпд1 в соответствии с приведенными диаграммами состояний переходов.

2. Диаграмма состояний переходов ПТС ОРИ по кпд1 приведена на схеме 1 настоящего приложения:

1) ПТС ОРИ по TCP-порту кпд1 должны находиться в ожидании входящих соединений; после установления соединения с ПУ должна выполняться взаимная SSL/TLS-аутентификация;

2) если SSL/TLS-соединения по каналам управления и данных установлены, а сессия не открыта, ПТС ОРИ следует реагировать только на сообщение "Запрос на открытие сессии"; при попытке посылок каких-либо других сообщений со стороны ПУ ПТС ОРИ должны разорвать TCP-соединения по каналу управления и каналу данных и перевести канальный уровень подключения в исходное состояние;

3) при получении сообщения "Запрос на открытие сессии" ПТС ОРИ должны создать список поддерживаемых ПТС ОРИ типов запросов, отчетов и сигналов (в том числе и предыдущих версий) и отослать его на ПУ;

4) после отсылки списка поддерживаемых типов ПТС ОРИ должны ожидать от ПУ списка поддерживаемых им запросов, отчетов и сигналов; список поддерживаемых ПУ типов является подмножеством списка типов в ПТС ОРИ;

5) при получении от ПУ списка поддерживаемых ПУ запросов ПТС ОРИ должны послать сообщение "Ответ на согласование списка поддерживаемых типов" и создать сессию;

6) после создания сессии кпд1 ПТС ОРИ должны быть переведены в режим ожидания команд от ПУ; при поступлении команды со стороны ПУ ПТС ОРИ должны ее выполнить и сформировать результат, который в виде сообщения "ответа" должен поступить на ПУ;

Схема 1

7) в случае сбоя в функционировании ПТС ОРИ, вызванного причинами, не предусмотренными режимом нормального функционирования системы, по каналу управления должен передаваться "сигнал" - "Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна" с соответствующим описанием проблемы; все задачи, которые были в процессе выполнения, когда произошел сбой, а также данные выполненных задач, поврежденные в результате произошедшего сбоя, имеют "признак результата выполнения задачи" (TaskResult), равный значению "ошибка" (error), с соответствующим описанием проблемы. В случае, если для восстановления работоспособности ПТС ОРИ требуется их перезагрузка, то по каналу управления следует активировать команду "Перезапуск ПО". При этом ПТС ОРИ и ПУ должны закрыть все открытые на текущий момент сессии;

8) в случае наличия признаков сбоя или ошибки выполнения конкретной задачи ПТС ОРИ в режиме нормального функционирования по каналу управления должны передать прерывание "Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна" с соответствующим описанием проблемы. Результат выполнения данной задачи имеет "признак результата выполнения задачи" (TaskResult), соответствующий режиму "ошибка" (error), с описанием причин сбоя или ошибки;

9) на каждый "сигнал", переданный ПТС ОРИ, ПУ должен ответить сообщением "подтверждение сигнала" по кпд1. Отсутствие подтверждения в течение времени RequestResponseTimeout, которое задается при открытии сессии, свидетельствует о прерывании соединения и активирует операции, описанные в пункте 12 приложения N 2 к настоящим требованиям;

10) при отсутствии команд ПУ в течение "максимального времени неактивности" (session-timeout, задается в ConnectRequest) ПТС ОРИ должны направить на ПУ "сигнал" Heartbeat и ожидать его подтверждения согласно подпункту 9 настоящего пункта.

2. ПУ с задаваемым интервалом должен выполнять попытки установления TCP-соединения с ПТС ОРИ по заданному порту кпд1. Диаграмма состояний переходов ПУ по кпд1 приведена на схеме 2 настоящего приложения:

1) ПУ должен ожидать установления соединения по кпд1. После установления соединения выполняется взаимная SSL/TLS-аутентификация;

2) после установления TCP-соединения по кпд1 и проведения взаимной аутентификации ПТС ОРИ и ПУ по кпд1 должны направить команду создания сессии (ConnectRequest);

3) ПУ должен ожидать сообщения "ответ" от ПТС ОРИ на отправленную команду в течение времени "таймаут ответа на запрос" (request-response-timeout);

4) если сообщение не получено в течение времени "таймаут ответа на запрос", ПУ должен разорвать соединения к ПТС ОРИ по кпд1 и кпд2 и перевести их в начальное состояние согласно подпункту 1 настоящего пункта. Период ожидания сообщения "ответ" не должно зависеть от приема сообщений "сигналов", поступающих в этот интервал времени;

5) при получении сообщения "Ответ на запрос создания сессии" ПУ должен создать список поддерживаемых ПУ типов запросов, отчетов и сигналов и отправить его ПТС ОРИ;

6) после отправки сообщения "Согласование поддерживаемых типов со стороны ПУ" ПУ должен ожидать ответа на сообщение от ПТС ОРИ. Поведение ПУ при ожидании ответа должно соответствовать подпункту 4 настоящего пункта;

7) во время ожидания сообщения "ответ" ПТС ОРИ должны послать на ПУ сообщение "сигнал" (в том числе HeartBeat), а ПУ направить "подтверждение" о принятии "сигнала" (в том числе HeartBeat) и продолжать ожидать сообщение "ответ" на отосланную команду;

8) после создания сессии ПУ должен послать поступающие команды на ПТС ОРИ и ожидать сообщений "ответов" на них согласно подпунктам 3, 4 и 7 настоящего пункта;

Схема 2