Описание протокола взаимодействия ККТ и ОФД

ФЕДЕРАЛЬНАЯ НАЛОГОВАЯ СЛУЖБА РОССИЙСКОЙ ФЕДЕРАЦИИ
Описание протокола взаимодействия
между контрольно-кассовой техникой и
информационной (автоматизированной) системой
оператора фискальных данных
[Проект. Версия 0.5 от 22.09.2015]
Дата введения 01.01.2016
1. ОБЩИЕ ПОЛОЖЕНИЯ
1.1 Назначение документа
Описание протокола взаимодействия между контрольно-кассовой
техникой и информационной (автоматизированной) системой оператора
фискальных данных предназначено для обеспечения совместимости технических
средств при взаимодействии между контрольно-кассовой техникой и
автоматизированной системой оператора фискальных данных.
В документе представлены описания протоколов прикладного, сеансового
и транспортного уровней для обмена информацией между объектами
взаимодействия. Описания основываются на декомпозиции управления и
терминологии стандартов Эталонной модели взаимодействия открытых систем
[1].
Протоколы базируются на транспорте сетей TCP/IP и криптографическом
протоколе защиты фискальных данных.
1
Сведения о криптографическом протоколе защиты фискальных данных
изложены в отдельном документе ограниченного доступа.
1.2 Описание области применения
В
новом
порядке
устанавливаются требования:
применения
контрольно-кассовой
техники
 Некорректируемой регистрации фискальных данных.
 Передачи фискальных данных в налоговые органы при посредстве оператора
фискальных данных.
 Обработки фискальных данных оператором фискальных данных, в том числе
проверки подлинности фискальных данных после их приема оператором
фискальных данных.
Для решения этих задач протоколы прикладного, сеансового и
транспортного уровней для обмена информацией между контрольно-кассовой
техникой и автоматизированной системой оператора фискальных данных
должны соответствовать следующим требованиям:
 Процессы обслуживания покупателей и передачи фискальных данных должны
выполняться контрольно-кассовой техникой независимо и асинхронно. Агент
передачи фискальных данных составе в контрольно-кассовой техники не
должен оказывать влияния на процесс формирования фискальных документов
и выдачи их покупателю.
 Фискальные данные должны передаваться оператору фискальных данных по
мере возможности немедленно по мере их формирования.
 При передаче фискальных данных должны выполняться необходимые
требования информационной безопасности. Фискальные данные должны
передаваться в защищенном сообщении.
 Передача сообщений должна завершаться достоверным подтверждением их
приема от оператора фискальных данных.
 Система передачи данных должна обеспечивать двусторонний обмен
сообщениями между контрольно-кассовой техникой и оператором
фискальных данных по инициативе любого из участников взаимодействия.
 Система передачи данных должна обеспечивать гарантированную доставку
сообщений.
 Для обеспечения совместимости между техническими средствами, различных
поколений, свободного изменения функциональности протоколов сеансового
2
и прикладного уровней, состава и форматов фискальных документов
протоколы каждого из уровней должны поддерживать версионность.
1.3 Термины и определения
В прикладной области обработки фискальных данных используются
следующие термины и определения:
Контрольно-кассовая
техника
–
Оператор
данных
–
фискальных
Сведения о расчетах
–
Фискальные данные
–
электронные вычислительные машины, иные
компьютерные устройства и их комплексы,
формирующие электронные документы со
сведениями о расчетах, обеспечивающие
запись таких сведений в фискальные
накопители и их передачу в налоговые органы
через оператора фискальных данных, а также
печать документов с этими сведениями на
бумажных носителях в виде кассовых чеков
или
бланков
строгой
отчетности
в
соответствии с правилами, установленными
законодательством Российской Федерации.
юридическое лицо, созданное в соответствии с
законодательством Российской Федерации,
имеющее место нахождения в Российской
Федерации, получившее в соответствии с
законодательством Российской Федерации
разрешение на обработку фискальных данных,
осуществляющее хранение и обработку этих
фискальных данных на территории Российской
Федерации с использованием технических
средств, принадлежащих ему на праве
собственности.
информация о расчетах, осуществляемых
организациями
и
индивидуальными
предпринимателями
в
соответствии
с
законодательством Российской Федерации, в
том числе об организации и индивидуальном
предпринимателе, осуществляющем расчет, и
о контрольно-кассовой технике, применяемой
при осуществлении расчета.
сведения о расчетах, подписанные фискальным
признаком.
3
Обработка фискальных
данных
–
любое действие (операция) или совокупность
действий
(операций),
совершаемых
оператором
фискальных
данных
при
формировании
и
использовании
базы
фискальных
данных
с
применением
информационных технологий и технических
средств, в том числе средств формирования и
проверки фискального признака, включая
получение, проверку достоверности, сбор,
запись, систематизацию, накопление, хранение
в некорректируемом виде, извлечение,
использование, передачу в адрес налоговых
органов, предоставление таких данных и
доступа к таким данным налоговым органам,
исключая модификацию (корректировку),
обезличивание, блокирование, удаление и
уничтожение
фискальных
данных
и
информации о расчетах.
Фискальный накопитель – шифровальные (криптографические) средства
защиты
фискальных
данных
в
опломбированном корпусе, содержащие ключ
фискального
признака,
обеспечивающие
запись
перечня
фискальных
данных,
установленного
законодательством
Российской Федерации, в некорректируемом
виде, их энергонезависимое долговременное
хранение,
формирование
фискального
признака,
аутентификацию
электронных
документов, направляемых в контрольнокассовую технику оператором фискальных
данных, а также при необходимости
пользователя обеспечивающие шифрование
фискальных данных, в целях обеспечения
конфиденциальности
информации,
передаваемой оператору фискальных данных.
Термины и определения, вводимые в описаниях протоколов передачи
фискальных данных, основаны на понятиях и определениях Эталонной модели
взаимодействия открытых систем (ЭМ ВОС), [1]. В тех случаях, когда в разделе
«Термины и определения» производится прямое заимствование термина ЭМ
ВОС, непосредственно вслед за использованным термином указывается ссылка
«[1]».
4
В соответствии с декомпозицией сетевого управления ЭМ ВОС в
настоящем протоколе используется семиуровневая иерархическая модель
управления. Для решения задач настоящего протокола достаточно адресоваться
к понятиям и услугам верхних четырех уровней:
А
P
S
T
прикладной (application) уровень.
уровень представления (presentation) [данных].
сеансовый (session) уровень.
транспортный (transport) уровень.
Таким образом, для описания процессов формирования, передачи,
обработки фискальных данных используются четыре описания протоколов:
Прикладной протокол
–
–
–
–
–
А-протокол
[1],
обеспечивающий
взаимодействие прикладных процессов [1],
решающих задачи формирования, передачи,
обработки [фискальных] документов.
Формат документа
– Р-протокол [1], обеспечивающий описание
форматов
и
правила
интерпретации
документов.
Протокол
сеансового – S-протокол [1], обеспечивающий обмен
уровня
сообщениями между Клиентом ККТ и
Сервером.
Протокол транспортного – T-протокол [1], обеспечивающий дуплексный
уровня
потоковый обмен бинарными данными между
Т-логическими объектами [1] Клиента ККТ и
Сервера.
Для краткости перечисленные протоколы могут именоваться по тексту как
A-, P-, S-, T-протокол, соответственно.
Для выполнения требования версионности (сосуществования и
совместимости
в
рамках
парка
контрольно-кассовой
техники
и
автоматизированной системы оператора фискальных данных продуктов,
исполняющих различные функции) принята следующая декомпозиция описаний
протоколов:
 Протоколы прикладного, сеансового и транспортного уровней издаются
единой спецификацией и содержат единую версию.
 Протокол уровня представления выделен в отдельную спецификацию с тем,
чтобы налоговые органы имели возможность изменять форматы и содержание
фискальных документов (например, с целями раздельного учета расчетных
операций для различных видов товаров и услуг) без изменения логики
функционирования и изменения бинарного кода программного обеспечения
функциональной среды ВОС [1] за исключением фискальных документов и
5
синтаксических анализаторов (парсеров), выступающих в качестве Рлогических объектов [1].
При этом протоколы A-, S- и Т-уровней заданной версии должны быть
совместимы с различными независимо разработанными версиями Р-протокола.
При описании протокола прикладного уровня используются следующие
термины и определения:
Клиент ККТ
–
Клиент ФН
–
Интерфейс ФН
–
Сервер
–
Адрес сервера
ПКЗ сервера
–
–
Интерфейс ПКЗ
–
Документ
–
Реальная открытая система [1], выполняющая в
составе контрольно-кассовой техники функции
формирования и передачи фискальных данных.
Реальная система [1], выполняющая функции
защиты фискальных данных, обработки
сообщений,
при
помощи
которых
осуществляется
взаимодействие
между
Клиентом ФН и ПКЗ сервера. (Взаимодействие
осуществляется при посредстве Клиента ККТ и
Сервера на основе Криптографического
протокола).
Физический стык и система команд, при
помощи которых Клиент ККТ взаимодействует
с Клиентом ФН. Описание Интерфейса ФН
разрабатывается изготовителем ФН.
Реальная открытая система [1], выполняющая в
составе
автоматизированной
системы
оператора фискальных данных функции
приема и обработки фискальных данных.
Реальная система [1], выполняющая проверки
фискальных данных, обработки сообщений,
при
помощи
которых
осуществляется
взаимодействие между Клиентом ФН и ПКЗ
сервера. (Взаимодействие осуществляется при
посредстве Клиента ККТ и Сервера на основе
Криптографического протокола).
Система команд (сетевых взаимодействий),
при помощи которых Сервер взаимодействует
с ПКЗ сервера. Описание Интерфейса ФН
разрабатывается изготовителем ПКЗ сервера.
объект прикладного уровня, содержащий
фискальные данные.
6
Квитанция
–
Команда
–
Код исполнения
–
Контейнер
–
объект прикладного уровня, подтверждающий
прием фискальных данных.
объект прикладного уровня, содержащий
данные (запрос) управления и мониторинга.
объект прикладного уровня, содержащий
данные (код ошибки, блок данных) управления
и мониторинга.
любой из перечисленных выше объект
прикладного уровня, подготовленный для
передачи протоколу сеансового уровня.
При описании протокола сеансового уровня используются следующие
термины и определения:
Сообщение
–
Криптографический
протокол
–
объект сеансового уровня, содержащий в
защищенном виде Документы (Команды,
Квитанции, Коды исполнения) протокола
прикладного уровня а также служебную
информацию криптографического протокола.
протокол сеансового уровня, действующий
между Клиентом ФН и ПКЗ сервера и
выполняющий
функции
формирования,
защиты, приема, проверки Сообщений и
управления
S-ассоциациями
[1],
обеспечивающими
работу
с
криптографическими ключами.
При описании протокола транспортного уровня используются следующие
термины и определения:
Соединение
Порт ТСР
–
–
IP-адрес
–
Установление связи для обмена данными.
Натуральное число, записываемое в заголовках
протоколов транспортного уровня модели OSI
(TCP, UDP, SCTP, DCCP). Используется для
определения процесса-получателя пакета в
пределах одного хоста
Уникальный
идентификатор
узла
в
компьютерной сети, построенной по IP
1.4 Список сокращений
АС
–
автоматизированная система.
7
ККТ
ОФД
ПКЗ
ФД
ФН
ЭМ ВОС
–
–
–
–
–
–
контрольно-кассовая техника.
оператор фискальных данных.
подсистема криптографической защиты.
фискальные данные.
фискальный накопитель.
эталонная модель взаимодействия открытых
систем.
1.5 Структура спецификации
Описание протокола взаимодействия между контрольно-кассовой техникой и
информационной (автоматизированной) системой оператора фискальных данных в настоящем
документе представлены в последовательности:
1. В разделе 2 представлено описание протокола прикладного уровня.
2. В разделе 3 представлено описание протокола сеансового уровня.
3. В разделе 4 представлено описание протокола транспортного уровня.
4. В справочном приложении 5 представлена библиография.
Описание(я) протокола уровня представления вынесено в отдельную(ые)
спецификацию(и) «Описание протокола уровня представления данных. Форматы
фискальных документов».
2. ПРОТОКОЛЫ ПРИКЛАДНОГО УРОВНЯ
2.1 Состав взаимодействующих объектов прикладного уровня
Прикладной протокол реализуется, как взаимодействие между двумя
типами объектов: Клиентом ККТ и Сервером.
Взаимодействие между этими объектами производится при посредстве
объектов Клиент ФН и ПКЗ сервера, обеспечивающих формирования Сообщений
S-протокола.
Объекты прикладного уровня Документ, Квитанция, Команда и Код
исполнения требуют защиты в части обеспечение целостности и аутентификации
источника данных. Для применения к этим объектам функции защиты
информации в составе ККТ (АС ОФД) выполняются следующие операции:
1. Клиент ККТ (Сервер) передает в Клиент ФН (ПКЗ сервера) запрос на
защиту объекта (например, данные кассового чека без фискального
признака).
8
2. Клиент ФН (ПКЗ сервера) возвращает Клиенту ККТ (Серверу) прикладной
объект (Документ, Квитанцию, Команду, Код исполнения) в защищенном
виде (например, кассовый чек с присвоенным ему фискальным признаком).
В дальнейшем полученные в результате выполнения этих операций
объекты прикладного уровня для передачи равнозначному объекту прикладного
уровня включаются в Контейнер.
2.2 Система именования объектов прикладного уровня
Объекты прикладного уровня именуются (идентифицируются) при
помощи следующих структур адресной информации:
 Клиент ККТ идентифицируется по серийному номеру ФН и серийному
номеру ККТ. Тип данных – строка цифр (ASCII) с фиксированной длиной 10
символов.
 Клиент ФН идентифицируется по серийному номеру ФН Тип данных – строка
цифр (ASCII) с фиксированной длиной 10 символов.
 Сервер идентифицируется при помощи идентификатора, описанного в
формате URI [2].
 ПКЗ сервера для равноправных логических объектов по взаимодействию
самостоятельным идентификатором не обладает и идентифицируется при
помощи того же URI, который описывает Сервер.
Примечание.
В практических реализациях объект ПКЗ сервера может быть
резервирован и (или) иметь распределенную структуру. В этом случае
допускается идентификация для Сервера компонентов объекта ПКЗ
сервера при помощи отдельных URI. Однако это должна быть система
идентификации с локальной областью видимости (Сервер – ПКЗ
сервера). Для равноправных логических объектов ПКЗ сервера должен
идентифицироваться только при помощи URI Сервера.
URI Сервера должен статически конфигурироваться при регистрации ККТ
и сохраняться в памяти Клиента ФН.
При изменении URI Сервера запись нового (или дополнительного
альтернативного) значения URI должна вноситься в память Клиента ФН при
помощи специальной Команды управления Сервера.
Для распознания сетевых (IPv4 [3], IPv6[4]) адресов Сервера Клиент ККТ
должен использовать протокол системы доменных имен DNS [5,6].
Для конфигурирования сетевых (IP-) адресов должен использоваться
частный DNS-сервер в составе АС ОФД. IP-адрес этого DNS-сервера должен
статически конфигурироваться при регистрации ККТ и сохраняться в памяти
Клиента ФН.
9
Клиент ККТ для доступа к частному DNS-серверу АС ОФД должен
использовать не адреса DNS, сконфигурированные в составе IP-стека Клиента
ККТ провайдером коммуникаций, а запрашивать этот IP-адрес у Клиента ФН.
При изменении IP-адреса частного DNS-сервера АС ОФД запись нового
(или дополнительного альтернативного) значения IP-адреса частного DNSсервера АС ОФД должна вноситься в память Клиента ФН при помощи
специальной Команды управления Сервера.
2.3 Протокол обмена фискальными документами
В составе протокола прикладного уровня обеспечиваются два вида
взаимодействий:
1. Передача фискальных данных.
2. Управление и мониторинг.
Структура информационных обменов во взаимодействии «Передача
фискальных данных» выполняется при помощи взаимодействий, показанных на
рис. 1.
Рис. 1
Примечание.
В процессах, где учет приема Квитанций ведет объект Клиент ФН,
Квитанция объекту Клиент ККТ не возвращается. Если особо не
оговорено иное, эта логика принята для всех обменов фискальными
документами.
10
Структура информационных обменов во взаимодействии «Управление и
мониторинг» выполняется при помощи взаимодействий, показанных на рис. 2.
Рис. 2
На рис. 1 и 2 сплошными линиями показаны функции протокола
прикладного уровня, штриховыми – сеансового и нижележащих протоколов.
Для передачи данных равноправному логическому А-объекту каждый Аобъект упаковывает свои данные в Контейнер. Структура Контейнера показана
на рис. 3.
Рис. 3
Контейнер представляет собой структуру тип-длина-значение (TLV).
Структура контейнера показана в таблице 1.
Таблица 1
Поле
Тип данных
Длина данных
Значение данных
Формат
Длина
Int16, LE
Int16, LE
byte array
2
2
Задано полем «Длина данных»
11
В Контейнер упаковываются Документы или Команды управления и
мониторинга, типы данных для которых описаны в таблице 2.
Таблица 2
Тип
данных
0
Наименование типа данных
Значение
данных
Фиксир.
Длина
Формат
Обязательный
Источник
Зарезервировано
1
Кассовый чек
структура
нет
65535
STLV
да
Клиент ФН
2
Регистрационные сведении
структура
нет
65535
STLV
да
Клиент ФН
3
структура
нет
65535
STLV
да
Клиент ФН
4
Уведомление
смены
Внесение
структура
нет
65535
STLV
да
Клиент ФН
5
Инкассация
структура
нет
65535
STLV
да
Клиент ФН
6
Закрытие смены
структура
нет
65535
STLV
да
Клиент ФН
7
Закрытие архива
структура
нет
65535
STLV
да
Клиент ФН
101
Сервисные параметры
структура
нет
65535
STLV
да
Клиент ФН
102
Квитанция
структура
нет
65535
STLV
да
ПКЗ сервера
201
Команда
структура
нет
65535
STLV
да
Сервер
об
открытии
Значения данных Контейнера для типов данных 1..8 описаны в документе
«Описание протокола уровня представления данных. Форматы фискальных
документов».
Эта спецификация может обновляться в независимом жизненном цикле и
публиковаться в новых версиях. Выпуск новой версии протокола уровня
представления данных не должен требовать изменения содержания и
функциональности протоколов прикладного, сеансового и транспортного
уровней.
При наличии нескольких действующих версий документа «Описание
протокола уровня представления данных. Форматы фискальных документов»
прикладной объект Сервер должен обеспечивать поддержку всех действующих
версий протоколов уровня представления данных, описывающих форматы
фискальных документов.
В текущей версии протокола поддерживаются следующие команды
управления и мониторинга:
Организация команд управления и мониторинга предполагает
использование структуры «сервисных параметров». Это структура позволяющая
передавать параметры в виде ключа и значения.
12
Рис 4.
Ключи Команд управления и мониторинга приведены в пункте 3.7
документа Форматы ФД .
3. ПРОТОКОЛ СЕАНСОВОГО УРОВНЯ
3.1 Структура Сообщения протокола сеансового уровня
Равноправные логические объекты сеансового уровня обмениваются
Сообщениями. Сообщения передаются в защищенном виде с обеспечением
свойств аутентификации источника данных, целостности и, при необходимости,
конфиденциальности. Сообщения в защищенном виде формируются объектами
Клиент ФН и ПКЗ сервера.
Структура Сообщения протокола сеансового уровня имеет структуру,
показанную на рис. 4.
Рис. 4
Типы данных для структуры заголовка Сообщения приведены в таблице 3.
Таблица 3
13
Поле
Версия S-протокола
Серийный номер ФН
Версия A-протокола
Тело пакета
Длина
4
10
4
Формат
ASCII
ASCII
ASCII
Byte array
Описание
Строка цифр
Строка цифр
Строка цифр
Бинарные данные
3.2 Инициатива передачи данных, управление приоритетом
Источниками данных для передачи может выступать любой из объектов
сеансового уровня (Клиент ККТ, Клиент ФН, Сервер, ПКЗ сервера).
Подготовку данных для передачи и инициативой передачи данных
обладают только объекты Клиент ФН и ПКЗ сервера.
В случае если отдельные виды сообщений требуют приоритетной
передачи, неявное управление приоритетом выполняют Клиент ФН и ПКЗ
сервера, устанавливая соответствующее сообщение в переднюю позицию
очереди для передачи.
Передача приоритетных сообщений производится без прерывания
обслуживания (т.е. приоритетное сообщение передается первым вслед за
завершением передачи предыдущего сообщения вне зависимости от его
приоритета).
3.3 Описание конечного автомата S-объекта Клиент ККТ
Конечный автомат объекта сеансового уровня Клиент ККТ показан на рис.
5.
14
Рис. 5
Примечание.
На рис. 5 и далее на всех диаграммах конечных автоматов S-объектов
для простоты показаны основные состояния S-объектов. Состояния,
связанные с установлением и пересинхронизацией соединений
транспортного уровня, переходы, вызванные обрывом связи и другие
состояния обработки ошибок на диаграмме не показаны.
Ветвь «Расчет», показанная на рис. 5 штриховой линией, отображает цикл
формирования фискального документа, в котором вырабатывается Сообщение
Клиента ФН и постановка его в очередь на передачу S-объекта Клиент ФН.
Описание конечного автомата объекта сеансового уровня Клиент ККТ
приведено в таблице 5.
15
Таблица 5
Наименование Описание состояния
состояния
ОЖИДАНИЕ
Основное, начальное и конечное («холостое») состояние
автомата
Периодически, по таймеру («Таймер ФН» с периодом
K_MFP1 (K_MFP2, K_MFP3, K_MFP4) секунд (здесь и
далее см. «Форматы ФД» пункт 3.7)) Клиент ККТ
обращается к объекту Клиент ФН с запросом на передачу
данных Серверу. Для этого используется специальная
команда Интерфейса ФН
Периодически, по таймеру («Таймер С» с периодом S_OFD
секунд) Клиент ККТ формирует запрос к Серверу на
предмет приема Сообщений от Сервера, если у него таковые
имеются
Данные
Клиент ККТ принимает данные для формирования
фискального документа
Передача
Клиент ККТ сформировал данные для фискального
данных ФН
документа и передает их, при необходимости – поблочно, в
объект Клиент ФН, используя команды Интерфейса ФН
Ожидание
Клиент ККТ передал объекту Клиент ФН данные и ожидает,
Документа
когда Клиент ФН сформирует документ, снабженный
фискальным признаком
Прием
Клиент ККТ принимает Документ из объекта Клиент ФН,
Документа
используя команды Интерфейса ФН
Печать
Клиент ККТ печатает документ.
Документа
16
Входное
слово
Расчет
Переход в
состояние
Данные
Таймер ФН
Запрос Клиента
ФН
Таймер С
Запрос Сервера
по завершении Передача
данных ФН
по завершении Ожидание
Документа
по завершении Прием
Документа
по завершении Печать
Документа
по завершении ОЖИДАНИЕ
Наименование Описание состояния
состояния
Входное
слово
Переход в
состояние
П р и м е ч а н и е . Для некоторых видов Документов это состояние
может быть «пустым», т.е. операция печати может не выполняться
Запрос Клиента В случае, если очередь Клиента ФН на передачу не пуста, Таймер ФН
ФН
начинается передача Сообщений Серверу.
Прием
Сообщения ФН
П р и м е ч а н и е 1 . Объект Клиент ККТ формирует запрос объекту
Клиент ФН на передачу данных только в случае установления
соединения транспортного уровня с объектом Сервер. В отсутствие
соединения (объект Сервер не доступен по сети) запросы на передачу
данных объекту Клиент ФН не подаются.
П р и м е ч а н и е 2 . В очереди Клиента ФН могут находиться как
Сообщения, содержащие вновь сформированные Документы, так и
ранее сформированные документы, на которые в установленный срок
не поступили квитанции Сервера, так и служебные сообщения
криптографического протокола
В случае, если очередь Клиента ФН на передачу пуста, Оч. ФН = 0
Клиент ККИ возвращается в начальное состояние
Прием
До тех пор, пока Клиент ФН имеет информацию для Оч. ФН > 0
Сообщения ФН передачи Серверу, Клиент ККТ поблочно выполняет
операцию приема данных от объекта Клиент ФН и передачи
их Серверу.
ОЖИДАНИЕ
Передача
Сообщения ФН
П р и м е ч а н и е . Операция поблочных обменов между объектом
Клиент ФН и Клиент ККТ введена для обеспечения совместимости с
контрольно-кассовой
техникой
с
ограниченным
объемом
оперативной памяти, не допускающим приема Сообщения целиком.
Для контрольно-кассовой техники, обладающей достаточным
ресурсом оперативной памяти, рекомендуется устанавливать размер
блока данных равным размену Сообщения
По завершении передачи Сообщений, полученных от Оч. ФН = 0
объекта Клиент ФН, Серверу объект Клиент ККТ
17
Запрос Сервера
Наименование Описание состояния
состояния
запрашивает Сервер на предмет наличия у Сервера
Сообщений для Клиента ККТ
Передача
Клиент ККТ передает блок данных Сообщения (или
Сообщения ФН Сообщение целиком) Серверу
Запрос Сервера Клиент ККТ устанавливает с Сервером соединение для
приема Сообщений. Если у Сервера есть Сообщения для
данного Клиента ККТ, Клиент ККТ начинает их прием
Клиент ККТ устанавливает с Сервером соединение для
приема Сообщений. Если у Сервера нет Сообщений для
данного Клиента ККТ, Клиент ККТ возвращается в
начальное состояние
Входное
слово
Переход в
состояние
Блок передан
Прием
Сообщения ФН
Прием
Сообщения
Сервера
ОЖИДАНИЕ
Оч. С > 0
Оч. С = 0
П р и м е ч а н и е . В очереди Клиента ФН могут находиться как
Сообщения, содержащие вновь сформированные Документы, так и
ранее сформированные документы, на которые в установленный срок
не поступили квитанции Сервера, так и служебные сообщения
криптографического протокола
Прием
Сообщения
Сервера
До тех пор, пока Сервер имеет информацию для передачи Оч. С > 0
Клиенту ККТ, Клиент ККТ выполняет операцию приема
данных от Сервера и поблочно передает их объекту Клиент
ФН.
П р и м е ч а н и е . Операция поблочных обменов между объектом
Клиент ФН и Клиент ККТ введена для обеспечения совместимости с
контрольно-кассовой
техникой
с
ограниченным
объемом
оперативной памяти, не допускающим приема Сообщения целиком.
Для контрольно-кассовой техники, обладающей достаточным
ресурсом оперативной памяти, рекомендуется устанавливать размер
блока данных равным размену Сообщения
18
Передача
Сообщения
Сервера
Наименование Описание состояния
Входное
состояния
слово
По завершении приема Сообщений Сервера Клиент ККТ Оч. С = 0
возвращается в начальное состояние
Передача
Клиент ККТ передает блок данных Сообщения (или Блок передан
Сообщения
Сообщение целиком) Клиенту ФН
Сервера
3.4 Описание конечного автомата S-объекта Клиент ФН
Конечный автомат объекта сеансового уровня Клиент ФН показан на рис. 6.
19
Переход в
состояние
ОЖИДАНИЕ
Прием
Сообщения
Сервера
Рис. 6
Ветвь «Данные», показанная на рис. 6 штриховой линией, отображает цикл формирования фискального
документа, в котором вырабатывается Сообщение и постановка его в очередь на передачу.
Описание конечного автомата объекта сеансового уровня Клиент ККТ приведено в таблице 6.
20
Таблица 6
Наименование Описание состояния
состояния
ОЖИДАНИЕ
Основное, начальное и конечное («холостое») состояние
автомата
Клиент ККТ запрашивает Сообщение на передачу
Клиент ККТ передает Сообщение, принятое от Сервера
Прием данных
Документ
Передача
Документа
Защита
Сообщения
Входное
слово
Данные
Переход в
состояние
Прием Данных
Запрос ККТ
Прием > 0
Очередь+?
Прием
Сообщения
Ревизия
Периодически, по таймеру («Таймер Р» с периодом R_MFP Таймер Р
секунд) Клиент ФН проверяет список Сообщений,
ожидающих квитанцию Сервера
Клиент ФН принимает, при необходимости – поблочно, от по завершении Документ
объекта Клиент ККТ данные для формирования Документа
Клиент ФН создает защищенный фискальный документ
по завершении Передача
Документа
Клиент ФН передает, при необходимости – поблочно, по завершении Защита
фискальный документ объекту Клиент ККТ
Сообщения
Клиент ФН выполняет предписанные политикой по завершении Сообщение
безопасности операции защиты Сообщения и формирует
очередь
Сообщение сеансового уровня и ставит его в очередь на
передачу.
П р и м е ч а н и е . Клиент ФН может включить в Сообщение несколько
Документов, а также собственное сообщение криптопротокола
Сообщение
очередь
в Клиент ФН ставит Сообщение в очередь на передачу.
П р и м е ч а н и е . Сообщения, по мере получения от Клиента ККТ
запроса на передачу данных. Передача Сообщения будет выполнена
впоследствии, асинхронно процессу формирования
21
по завершении ОЖИДАНИЕ
в
Наименование Описание состояния
состояния
Очередь+?
Клиент ФН проверяет состояние очереди срочных
сообщений. В случае, если очередь на передачу срочных
сообщений Клиента ФН не пуста, начинается передача
срочных Сообщений Клиенту ККТ
В случае, если очередь Клиента ФН на передачу срочных
сообщений пуста, Клиент ФН переходит к проверке очереди
сообщений с нормальным приоритетом
Передача
До тех пор, пока Клиент ФН имеет информацию в очереди
Сообщения+
срочных сообщений для передачи Серверу, Клиент ФН
поблочно выполняет операцию передачи данных объекту
Клиент ККТ
По завершении передачи Сообщений из очереди срочных
сообщений Клиент ФН переходит к проверке состояния
очереди с нормальным приоритетом
Передача
Клиент ФН передает блок данных Клиенту ККТ
блока+
Очередь?
Клиент ФН проверяет состояние очереди сообщений с
нормальным приоритетом. В случае, если очередь
сообщений с нормальным приоритетом не пуста, Клиент
ФН начинает передачу Сообщений Клиенту ККТ
В случае, если очередь сообщений с нормальным
приоритетом пуста, Клиент ФН переходит в начальное
состояние
Передача
До тех пор, пока Клиент ФН имеет информацию в очереди
Сообщения
сообщений с нормальным приоритетом для передачи
Серверу, Клиент ФН поблочно выполняет операцию
передачи данных объекту Клиент ККТ
22
Входное
слово
Оч. С+ > 0
Переход в
состояние
Передача
Сообщения+
Оч. С+ = 0
Очередь?
Оч. С+ > 0
Передача
блока+
Оч. С+ = 0
Очередь?
по завершении Передача
Сообщения+
Оч. С > 0
Передача
Сообщения
Оч. С = 0
ОЖИДАНИЕ
Оч. С > 0
Передача блока
Наименование Описание состояния
состояния
По завершении передачи Сообщений из очереди
сообщений с нормальным приоритетом Клиент ФН
переходит в начальное состояние
Передача блока Клиент ФН передает блок данных Клиенту ККТ
Прием
Сообщения
Прием блока
Квитанция
Другая
операция
Ревизия
Входное
слово
Оч. С = 0
Переход в
состояние
ОЖИДАНИЕ
по завершении Передача
Сообщения
Клиент ФН получает от Клиента ККТ запрос на прием Прием > 0
Прием блока
данных от Сервера. До тех пор, пока Сообщение не принято,
ведется его поблочный прием
По мере завершения приема Сообщения из него Команда
Другая
извлекаются Команды и Квитанции
операция
По мере завершения приема и обработки всех Сообщений Квитанция
Квитанция
из него извлекаются Команды и Квитанции
По завершении приема данных Клиент ФН переходит в Прием = 0
ОЖИДАНИЕ
начальное состояние
Клиент ФН принимает блок данных от Клиента ККТ
по завершении Прием
Сообщения
В случае, если принята Квитанция, Клиент ФН сохраняет ее по завершении Прием
и снимает квитированное Сообщение из очереди на
Сообщения
повторную передачу
В случае, если принята Команда, Клиент ФН ее выполняет по завершении Прием
или передает исполнительному объекту (например, ККТ,
Сообщения
криптопротоколу). Детали исполнения этой команды
выходят за границы регулирования настоящего протокола
В этом состоянии Клиент ФН проверяет список Сообщений, по завершении ОЖИДАНИЕ
ожидающих квитанцию Сервера и, если время ожидания
квитанций превышает лимит 168 часов, Клиент ФН
повторно ставит эти Сообщения в очередь на передачу
23
3.5 Описание конечного автомата S-объекта Сервер
Конечный автомат объекта сеансового уровня Сервер показан на рис. 7.
Рис. 7
Описание конечного автомата объекта сеансового уровня Клиент ККТ
приведено в таблице 7.
24
Таблица 7
Наименование Описание состояния
состояния
ОЖИДАНИЕ
Основное, начальное и конечное («холостое») состояние
автомата. При приеме Сообщения от Клиента ККТ автомат
начинает его обработку
Запрос от Клиента ККТ на прием данных
Прием
Сообщения
Проверка
Сообщения
Защита
Сообщения
Входное
слово
Прием
сообщения
Запрос
клиента
Запрос приложения на формирование сообщения Запрос
от
(Документа, Квитанции, Команды)
приложения
Сервер принимает Сообщение от Клиента ККТ. По по завершении
завершении – передает его объекту ПКЗ сервера
ПКЗ сервера производит проверку целостности, при по завершении
необходимости
–
дешифрование
контейнера
криптопротокола Сообщения, экстракцию из контейнера
Документов и Команд и передачу этих данных объектам адресатам
ПКЗ сервера выполняет предписанные политикой по завершении
безопасности операции защиты Сообщения и формирует
Сообщение сеансового уровня.
Переход в
состояние
Прием
Сообщения
Формирование
Сообщения
Защита
Сообщения
Проверка
Сообщения
ОЖИДАНИЕ
Буферизация
П р и м е ч а н и е . ПКЗ сервера может включить в Сообщение
несколько Документов, а также собственное сообщение
криптопротокола
Буферизация
Сервер или ПКЗ сервера ставит
Сообщение в очередь на передачу.
сформированное по завершении ОЖИДАНИЕ
П р и м е ч а н и е . Функция буферизации Сообщений требуется для
решения задач передачи Команд. Квитанции на документы могут
формироваться как путем обработки запросов приложений на
формирование Квитанций, так и путем выполнения автоматом
25
Наименование Описание состояния
состояния
Входное
слово
Переход в
состояние
объекта
Сервер
операций,
соответствующих
состоянию
«Формирование Сообщения». Выбор способа реализации не влияет на
общую логику протокола сеансового уровня и относится на
усмотрение разработчиков систем.
Формирование
Сообщения
Передача
Сообщения
В это состояние Сервер приходит, получив запрос Клиента Сообщение
ККТ на прием данных. По мере получения запроса Сервер
проверяет наличие для данного Клиента ККТ Сообщений,
созданных в состоянии «Буферизация» или наличие
неотквитированных
Документов.
При
наличии
неотквитированных Документов Север готовит для них
Квитанции и формирует из них Сообщение при помощи
объекта ПКЗ сервера
Сервер передает Сообщение Клиенту ККТ. Сервер Оч. С > 0
проверяет, есть ли информация на передачу для данного
Клиента ККТ. При информации – повторяет операцию
формирования Сообщения
Если Сервер не имеет информации для передачи Клиенту Оч. С = 0
ККТ, автомат возвращается в начальное состояние
26
Передача
Сообщения
Формирование
Сообщения
ОЖИДАНИЕ
3.6 Описание конечного автомата S-объекта ПКЗ сервера
Конечный автомат объекта сеансового уровня ПКЗ сервера показан на рис.
8.
Рис. 8
Описание конечного автомата объекта сеансового уровня ПКЗ сервера
приведено в таблице 8.
27
Таблица 8
Наименование Описание состояния
состояния
ОЖИДАНИЕ
Основное, начальное и конечное («холостое») состояние
автомата. Прикладные системы могут формировать
запросы на передачу данных. В этом случае прикладной
сервер передает ПКЗ Серверу запрос
Сервер, принявший запрос Клиента ККТ, начинает
формировать Квитанции и обслуживать очередь
Документов
Приняв Сообщение от Клиента ККТ, объект Сервер
передает полученное Сообщение для обработки
Защита
ПКЗ, получив данные приложения для передачи Клиенту
Сообщения
ККТ (Команду), формирует защищенное Сообщение для
запрошенного Клиента ККТ
На
Сформированное Сообщение устанавливается в очередь на
буферизацию
передачу.
Входное
слово
Запрос на
буферизацию
Переход в
состояние
Защита
Сообщения
Формирование Прием
Сообщения
Документа
Сообщение
Прием
Сообщения
по завершении На
буферизацию
по завершении ОЖИДАНИЕ
П р и м е ч а н и е . В качестве владельца очереди Сообщений на
передачу может выступать как объект Сервер, так и объект ПКЗ
сервера. Выбор того или иного владельца не влияет на общую логику
протокола сеансового уровня и относится на усмотрение
разработчиков систем
Прием
Документа
Сообщение
ПКЗ сервера принимает от объекта Сервер Документ по завершении Сообщение
(например, Квитанцию, формируемую в процессе
динамического поиска по базе данных принятых, но не
отквитированных документов)
ПКЗ сервера помещает один или несколько Документов Оч. Д > 0
Прием
(Квитанций) в защищенное Сообщение. Объект ПКЗ
Документа
28
Наименование Описание состояния
состояния
сервера может запрашивать у объекта Сервер
дополнительные документы на включение в Сообщение
Если Сообщение относится к типу несущих один Документ
(например, срочное Сообщение), или достигнута
максимальная длина Сообщения, или у объекта Сервер
больше нет Документов для данного Клиента ККТ,
Сообщение отправляется на передачу
Передача
ПКС сервера отправляет защищенное Сообщение Клиенту
Сообщения
ККТ. В случае, если для данного Клиента ККТ имеются еще
Документы на передачу, они включаются в новое
Сообщение
В случае, если для данного Клиента ККТ отсутствуют
Документы на передачу, автомат объекта ПКЗ сервера
возвращается в начальное состояние
Прием
ПКЗ сервера принимает Сообщение. Далее следует его
Сообщения
обработка
Если Сообщений на прием нет, автомат объекта ПКЗ
сервера переходит в начальное состояние
Обработка
После того, как Сообщение принято, объект ПКЗ сервера
Сообщения
проверяет
его
целостность,
снимает
защиту,
применявшуюся для передачи по сетям связи и выделяет из
Сообщения Контейнеры Документов
Если Документов в Сообщении нет, автомат ПКЗ сервера
переходит в начальное состояние
Документ?
В зависимости от содержания Контейнера производится его
обработка. Первым шагом такой обработки является
проверка аутентичности и целостности содержимого
29
Входное
слово
Переход в
состояние
На передачу
Передача
Сообщения
Оч. Д > 0
Прием
Документа
Оч. Д = 0
ОЖИДАНИЕ
Принято
Оч. С = 0
Обработка
Сообщения
ОЖИДАНИЕ
Контейнер
Документ?
Оч. С = 0
ОЖИДАНИЕ
Ошибка
Сброс
Документа
Наименование Описание состояния
состояния
контейнера. Если проверка дает положительный результат,
объект ПКЗ сервера предпринимает действия в зависимости
от типа содержимого контейнера. Если проверка дает
отрицательный результат, контейнер использованию не
подлежит
В случае, если контейнер содержит Документ, он
передается объекту Сервер для выработки Квитанции
В случае, если контейнер содержит Команду (блок данных
приложений управления и мониторинга) ПКЗ сервера
передает данные приложению-владельцу
В случае, если контейнер содержит сообщение,
адресованное ПКЗ, его обрабатывает криптографическая
система
Сброс
Документ,
проверка
целостности
которого
дала
Документа
отрицательный результат, возвращается объекту Сервер
вместе с кодом ошибки и сбрасывается из памяти ПКЗ.
Далее автомат ПКЗ сервера проверяет, есть ли еще
Документы в Сообщении
Входное
слово
Переход в
состояние
Документ
Квитирование
Команда
Передача
Команды
приложению
Криптограмма Операция ПКЗ
по завершении Обработка
Сообщения
П р и м е ч а н и е . При этом объект Сервер может выполнять
дополнительные операции с ошибочным пакетом, например, давать
сигнал приложениям фискального контроля о подозрительном
событии. Логика этих взаимодействий выходит за рамки протокола
сеансового уровня
Операция ПКЗ
Обрабатывается криптосистемой. Далее автомат ПКЗ Контейнер не Обработка
сервера проверяет, есть ли еще Документы в Сообщении
пуст?
Сообщения
П р и м е ч а н и е . Описание криптопротокола не существенно для
понимания логики протокола сеансового уровня и описания выходит
за рамки протокола сеансового уровня
30
Наименование
состояния
Передача
Команды
приложению
Квитирование
cервером
Буферизация
Квитанции
Описание состояния
Входное
Переход в
слово
состояние
ПКЗ
сервера
передает
данные
приложению, Контейнер не Обработка
обрабатывающему Команду. Далее автомат ПКЗ сервера пуст?
Сообщения
проверяет, есть ли еще Документы в Сообщении
Сервер ПКЗ передает объекту Сервер документ для по завершении Передача
выработки квитанции на документ
Документа
приложению
Квитанция устанавливается в очередь на передачу объекту- Контейнер не Обработка
отправителю типа Клиент ККТ. Далее автомат ПКЗ сервера пуст?
Сообщения
проверяет, есть ли еще Документы в Сообщении
31
3.7 Описание потока активностей протокола сеансового уровня при
передаче данных
Поток активностей сеансового протокола при передаче данных между
объектами Клиент ККТ и Сервер показан на рис. 9. Активности смежных по
отношению к сеансовому уровню протоколов показаны штриховыми линиями.
Рис. 9
4. ПРОТОКОЛ ТРАНСПОРТНОГО УРОВНЯ
В качестве протокола транспортного уровня используется протокол ТСР со
стандартными настройками стека.
Клиентское соединение устанавливается на 8655 порт протокола TCP.
32
IP-адрес Сервера устанавливается из открытой (публично доступной)
системы DNS.
URI Сервера конфигурируется в контрольно-кассовой технике и
записывается в энергонезависимую защищенную область памяти фискального
накопителя при регистрации (перерегистрации) ККТ.
5. ПРИЛОЖЕНИЕ 1 (СПРАВОЧНОЕ). ТИПЫ ДАННЫХ
Типы данных, применяемые в описании протоколов, приведены в таблице
П1.1.
Таблица П1.1
Тип
Наименование
Byte
Int32, LE
Беззнаковое целое число 0..255
Беззнаковое целое число
0..4294967295
Беззнаковое целое число
0..65535
Вложенная структура TLV в виде
байтового массива
Время в секундах с 1 января
1970 года представленное как
беззнаковое целое число (Int32,
LE)
Беззнаковое целое число в
байтовом формате варьируемой
длины с порядком следования
байтов от младшего к старшему
Беззнаковое число с точкой в
байтовом формате варьируемой
длины с порядком следования
байтов от младшего к старшему.
Первый байт определяет
положение десятичной точки в
числе
Строка с кодировкой CP866
Int16, LE
STLV
UnixTime
VLN
FVLN
ASCII
Пример
33
0x03
0x01 0x00
0x00 0x00
0x05 0x00
3
1
0x55 0x9E
0x02 0x8A
09.07.2015,
8:11:38
0xE9 0x2D
0x06
404969
0x02 0x15
0xCD 0x5B
0x07
123456.78
0x92 0xA5
0xE1 0xE2
Тест
5
Кодировка символов CP866 приведена в таблице П1.2.
Таблица П1.2
.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
8.
А Б В Г Д Е Ж З И Й К Л М Н О П
9.
Р
A.
А б
в
г
д
е
ж
З И й
к
л
м
н
E.
Р
с
т
у
ф
х
ц
Ч Ш щ ъ
ы
ь
э Ю я
F.
Ё
ё
С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я
о
П
6. ПРИЛОЖЕНИЕ 2 (СПРАВОЧНОЕ). БИБЛИОГРАФИЯ
1. ГОСТ Р ИСО/МЭК 7498-1-99. - «ВОС. Базовая эталонная модель. Часть 1.
Базовая модель», ГОСТ Р ИСО 7498-2-99.
2. RFC 3986, «Uniform Resource Identifier (URI): Generic Syntax».
3. IPv4
4. IPv6
5. DNS
6. TCP
7. SCP
34