Схема 2

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

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

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

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

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

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

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

3) если количество переданных без получения "подтверждения" о принятии серии блоков "отчетов" по всем задачам, по которым выполняется загрузка на ПУ данных, меньше "окна канала передачи данных" (параметр data-packet-window-size в запросе ПУ "Запрос на открытие сессии" ConnectRequest), то ПТС ОРИ должны выполнить подготовку новых блоков отчетов по загружаемым задачам и послать их на ПУ. Количество подготовленных и переданных без получения "подтверждения" блоков не должно превышать "размер окна канала передачи данных";

Схема 1

4) максимальная задержка подтверждения приема блока данных со стороны ПУ не должна превышать параметр "таймаут подтверждения приема блока данных отчета" (data-packet-response-timeout), указываемый при создании сессии. Если задержка подтверждения превысила заданное значение, то оставшиеся для передачи блоки данных не должны отправляться, а по каналу управления должен передаваться "сигнал" "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" с соответствующим описанием проблемы. При этом в поле "reference-message" сообщения "сигнал" должен указываться идентификатор сообщения блока отчета, по которому не поступило подтверждение приема;

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

6) в случае разрыва TCP/IP соединения кпд2 при существующем соединении кпд1, по кпд1 должно быть передано сообщение "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" с соответствующим описанием проблемы. В данном случае должно продолжаться выполнение установления соединения по кпд2 согласно пункту 10 приложения N 2 к настоящим требованиям;

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

8) если по кпд2 не производится передача блоков отчетов в течение "максимального времени неактивности" (session-timeout при создании сессии ConnectRequest), ПТС ОРИ должна направить на ПУ "сигнал" (HeartBeat) и ожидать его подтверждения согласно подпункту 9 пункта 1 приложения N 5 к настоящим требованиям.

3. Диаграмма состояний переходов ПУ по кпд2 приведена на схеме 2:

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

2) при поступлении запроса ПУ "Запрос загрузки данных" (DataLoadRequest) ПУ должен ожидать начала передачи данных в течение времени "таймаут начала передачи блоков отчетов" (data-load-timeout в ConnectRequest). Если данные не поступают в течение вышеописанного периода, то ПУ должен разорвать соединения по каналам кпд1 и кпд2 и перевести соединения в начальное состояние согласно подпункту 1 пункта 1 приложения N 5 к настоящим требованиям и подпункту 1 настоящего пункта;

3) при поступлении блока отчета ПУ должен произвести декодирование полученного блока и сохранение декодированных данных;

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

Схема 2

5) если при ожидании поступления в ПУ блоков отчетов ПТС ОРИ не посылали "сигнал" HeartBeat в течение трех интервалов "максимального времени неактивности" (session-timeout, задается в ConnectRequest), ПУ должен разорвать соединения к ПТС ОРИ по кпд1 и кпд2 и перевести их в начальное состояние согласно подпункту 1 пункта 1 приложения N 5 к настоящим требованиям и подпункту 1 пункта 2 настоящего приложения.

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

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

1) запрос на получение структуры ПТС ОРИ и списка модулей ПТС ОРИ ("GetStructureRequest");

2) запрос на получение конфигурации модуля ПТС ОРИ ("GetModuleConfigRequest");

3) запрос на изменение конфигурации модуля ПТС ОРИ ("SetModuleConfigRequest");

4) запрос на получение состояния модуля ПТС ОРИ ("CheckModuleRequest").

2. На каждый запрос по кпд3 ПТС ОРИ должны посылать ответ, содержащий результат обработки соответствующего запроса - "ManagementResponse".

3. Диаграммы состояний перехода ПТС ОРИ и ПУ по кпд3 соответствуют диаграммам для кпд1, представленным на схеме 1 и схеме 2 приложения N 5 к настоящим требованиям:

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

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

3) после создания сессии ПТС ОРИ должны быть переведены в режим ожидания команд от ПУ. Обработка поступающих команд и посылка сигналов должна производиться в соответствии с подпунктами 6-10 пункта 1 приложения N 5 к настоящим требованиям;

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

5) ПУ по каналу кпд3 должен направить команду для создания сессии (ConnectRequest);

6) ожидание подтверждения создания сессии, согласование списка поддерживаемых типов, отправка команд, ожидание ответов и обработка полученных от ПТС ОРИ сигналов по кпд3 должно производиться ПУ согласно подпунктам 3-9 пункта 2 приложения N 5 к настоящим требованиям.

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

1) о структуре и составе ПТС ОРИ, составе и состоянии интерфейсов взаимодействия ПТС ОРИ с ПУ;

2) об установленном в ПТС ОРИ общесистемном ПО ПТС ОРИ, перечне и состоянии программных модулей в составе ПО ПТС ОРИ;

3) о точках подключения ПТС ОРИ к ИС ОРИ и интерфейсах ввода информации в ПТС ОРИ.

5. ПТС ОРИ по запросу ПУ должна предоставить следующую информацию в части структуры и состава ПТС ОРИ, состава и состоянии интерфейсов взаимодействия ПТС ОРИ с ПУ:

1) перечень коммутационного и серверного оборудования, средств хранения данных с его идентификацией;

2) идентификацию интерфейсов подключения оборудования ПТС ОРИ друг к другу;

3) параметры для серверного оборудования (на момент формирования запроса ПУ):

общий и занятый объем оперативной памяти;

количество сетевых интерфейсов с их идентификацией, текущую нагрузку;