Требования, предъявляемые к функционированию канала управления кпд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

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 настоящего приложения.