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) параметры для серверного оборудования (на момент формирования запроса ПУ):

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

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

общее количество процессоров, текущую загрузку;

общий объем дискового пространства, объем свободного пространства;

4) параметры технических средств хранения данных:

перечень модулей, составляющих средства хранения данных с их идентификацией;

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

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

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

2) для каждой точки подключения предоставляет информацию о:

виде поступающих в ПТС ОРИ сведений (о соединениях абонентов, о платежах, об абонентах, иные сведения);

состоянии точки подключения (ввода информации) (штатное функционирование, сбой, не функционирует), текстовую расшифровку сбоя;

объеме информации, поступающей в секунду, в том числе количестве записей, объеме (байт);

периоде времени, в течение которого на точку подключения/ввода информации в ПТС ОРИ не поступала информация.

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