(Действующий) Приказ Федеральной службы по регулированию алкогольного рынка от 8...

Докипедия просит пользователей использовать в своей электронной переписке скопированные части текстов нормативных документов. Автоматически генерируемые обратные ссылки на источник информации, доставят удовольствие вашим адресатам.

Действующий

Приказ Федеральной службы по регулированию алкогольного рынка от 8 августа 2012 г. N 212 "О формате передачи сведений в электронном виде организациями, осуществляющими перевозку этилового спирта (в том числе денатурата) и нефасованной спиртосодержащей продукции с содержанием этилового спирта более 25 процентов объема готовой продукции автомобильным транспортом, в автоматизированную систему контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации"

В соответствии с пунктом 3 постановления Правительства Российской Федерации от 6 июля 2012 г. N 688 "О Правилах ведения автоматизированной системы контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации" (Собрание законодательства Российской Федерации, 2012, N 29, ст. 4117) приказываю:
1. Утвердить прилагаемый формат передачи сведений в электронном виде организациями, осуществляющими перевозку этилового спирта (в том числе денатурата) и нефасованной спиртосодержащей продукции с содержанием этилового спирта более 25 процентов объема готовой продукции автомобильным транспортом, в автоматизированную систему контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации.
2. Контроль за исполнением настоящего приказа возложить на заместителя руководителя Федеральной службы по регулированию алкогольного рынка А.Ю. Кружалина.
Руководитель
И. Чуян

Формат
передачи сведений в электронном виде организациями, осуществляющими перевозку этилового спирта (в том числе денатурата) и нефасованной спиртосодержащей продукции с содержанием этилового спирта более 25 процентов объема готовой продукции автомобильным транспортом, в автоматизированную систему контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации
(утв. приказом Федеральной службы по регулированию алкогольного рынка от 8 августа 2012 г. N 212)

1. Общие положения

Формат передачи в автоматизированную систему контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации информации, указанной в пункте 7 Правил ведения автоматизированной системы контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации, утвержденных постановлением Правительства Российской Федерации от 06.07.2012 г. N 688, определяется протоколом передачи навигационных данных NDTP (Navigation Data Transfer Protocol) 16.03.2012, версии 1.0.

2. Структура стека протоколов NDTP

Описание протокола обмена данными представлено согласно модели OSI. Все уровни реализованы стандартными средствами:
- для специальных технических средств регистрации в автоматическом режиме движения, устанавливаемых на автомобильные транспортные средства, оснащенные специальными емкостями для перевозки продукции (далее - СТС) - встроенным стеком GPRS модема;
- для сервера сбора данных (далее - ССД) - средствами операционной системы.
УровниСТСССД
Прикладнойкоманды и пакеты данныхкоманды и пакеты данных
СеансовыйNPLNPL
ТранспортныйTCPTCP
Протокол передачи данных NDTP (Navigation Data Transfer Protocol), состоит из двух уровней:
- NPL - Navigation data transfer Protocol (Low level) - протокол нижнего уровня (сеансовый);
- NPH - Navigation data transfer Protocol (High level) - протокол верхнего уровня (представления).
Протокол нижнего уровня (сеансовый) предназначен для передачи обезличенных блоков данных и контроля целостности принимаемых данных. На данном уровне определены правила адресации устройств, правила проверки целостности данных и др.
Протокол верхнего уровня (представления данных) описывает форматы и правила передачи данных для реализуемой услуги. На данном уровне учитывается состав и форматы передаваемых данных.
Все пакеты типа NPH (прикладной уровень), передаваемые со стороны СТС, передаются с подтверждением приема на стороне ССД.
Все данные в пакетах NPL и NPH передаются в little-endian* формате, если не установлено иное. В описаниях структуры пакетов длина полей указывается в байтах, либо var - для полей с переменной длиной.

3. Сеансовый уровень (протокол NPL)

На сеансовом уровне осуществляется шифрование и маршрутизация пакетов.
Пакета NPL, протокола нижнего уровня (NPL) имеет следующий формат:
Поле
Длина
Тип
Описание
Может ли данное поле (значение) изменяться
заголовок пакета NPL
2
int16
Сигнатура - предопределенное поле данных в начале пакета, предназначенное для проверки на принимающей стороне того, что по данному адресу в памяти находятся данные соответствующего пакета. Наличие сигнатуры является обязательным.
Нет. В поле всегда должно быть установлено значение 7E7E
2
unsigned int16
Определяет размер данных, находящихся в поле . Для незашифрованных и зашифрованных пакетов всегда равно размеру NPH данных. Если данные передаются в зашифрованном виде, размер поля равен длине данных выровненной по границе 8 байт (требования алгоритма Blowfish). При этом дополнительные байты в расшифрованном пакете не используются. Пример: если длина NPH пакета равна 18, то = 18, а длина поля равна 24.
Нет. В поле всегда должно быть установлено значение 0 - дополнительных данных в пакете не содержится.
2
int16
NPL_FLAG_CRC- определяет расчет контрольной суммы пакета (CRC) для обеспечения возможности проверки валидности пакета получателем. Принимает значения: 0 - нет, 1- да.
Нет. В поле всегда должно быть установлено значение 1
2
unsigned int16
Значение контрольной суммы поля , либо 0x0000, если флаг NPL_FLAG_CRC не установлен.
1
Byte
Указывает тип передаваемых данных. NPL_TYPE_ERROR - ошибка протокола NPL NPL_TYPE_NPH - пакет данных NPH
Да
4
unsigned int32
Определяет адрес участника соединения: NPL_ADDRESS_SERVER - сервер. Другие значения - мобильные устройства
Да
2
unsigned int16
Идентификатор пакета (ID) рекомендуется делать уникальным хотя бы в рамках одной сессии передачи данных. Например, выбрать некоторое значение ID при установке соединения и для каждого последующего пакета увеличивать его ID на единицу. При достижении 0 x FFFFFFFF следующее значение ID будет равно 0 x 00000000 и т.д.
Да
Var
Пакеты протокола NPL однонаправленные, подтверждения не требуют.
входящего пакета указывает адрес отправителя пакета. В данном поле может передаваться либо адрес ССД (для пакетов, приходящих со стороны ССД на СТС), либо адрес СТС (для пакетов, приходящих со стороны СТС на ССД).

4. Типы пакетов NPL

Пакеты NPL имеют следующие типы:
- NPL_TYPE_ERROR - ошибка протокола NPL;
- NPL_TYPE_NPH - пакет данных NPH.

4.1. Тип пакета: NPL_TYPE_ERROR

Коды об ошибке протокола NPL передаются пакетами NPL_TYPE_ERROR, которые при передаче не шифруются. Поле передачи данных содержит код ошибки и имеет следующий формат:
Поле
Д лина
Тип
Описание
Может ли данное поле (значение) изменяться
4
unsigned int32
Содержит коды ошибки:
NPL_ERR_OK
NPL_ERR_UNDEFINED
NPL_ERR_INVALID_ PEER _ADDRESS
NPL_ERR_PEER_NOT_AVAILABLE
NPL_ERR_PEER_PERM_DENIED
Да
Существуют следующие ошибки протокола NPL:
Общие ошибки:
- NPL_ERR_OK - запрос выполнен успешно;
- NPL_ERR_UNDEFINED - код для ошибок, не имеющих описания;
Ошибки маршрутизации пакетов:
- NPL_ERR_INVALID_ PEER _ADDRESS - недопустимый адрес участника соединения;
- NPL_ERR_PEER_NOT_AVAILABLE - участник соединения недоступен;
- NPL_ERR_PEER_PERM_DENIED - доступ запрещен.

4.2. Тип пакета: NPL_TYPE_NPH

Тип пакета NPL_TYPE_NPH - пакет NPH, передается на уровне представления (протокол NPH).

4.3. Уровень представления (протокол NPH)

Каждый участник соединения (СТС) обладает набором функций (услуг), которые он может предоставить другим участникам соединения. Все функции логически разделены на группы услуг мониторинга. Набор услуг мониторинга, которые поддерживает определенный участник соединения, определяет интерфейс его взаимодействия с другими участниками соединения.
Для каждого типа услуг мониторинга определены свои типы пакетов и логика работы. Отдельные типы пакетов могут использоваться в нескольких типах услуг мониторинга (например: пакет NPH_RESULT - пакет подтверждения, отсылающийся на не требующий получения данных запрос). Участник соединения может не поддерживать отдельные пакеты в определенном типе услуг мониторинга.
Обмен данными на уровне представления ведется с помощью пакетов NPH.
Пакет NPH имеет следующий формат:
Поле
Длина
Тип
Описание
Может ли данное поле (значение) изменяться
заголовок пакета NPH
2
unsigned int16
Тип услуги
Нет. В поле всегда должно быть установлено значение 0100 - NPH_SRV_NAVDATA
2
unsigned int16
Тип пакета
Да
2
unsigned int16
Флаги пакета (определяет необходимость подтверждения).
Bit 0
NPH_FLAG_REQUEST - определяет необходимость подтверждения пакета. Принимает значения:
0 - пакет не требует подтверждения;
1 - пакет требует подтверждения.
Возможен случай, когда бит установлен, но подтверждение не высылается. Подтверждение высылается только в том случае, когда направление подтверждения предусматривается протоколом обмена.
Нет. В поле всегда должно быть установлено значение 1 - пакет требует подтверждения
4
unsigned int32
Идентификатор пакета, используется для подтверждения запроса. ID пакетов рекомендуется делать уникальным хотя бы в рамках одной сессии передачи данных. Например, выбрать некоторое значение ID при установке соединения и для каждого последующего пакета увеличивать его ID на единицу. При достижении 0xFFFFFFFF следующее значение ID будет равно 0x00000000 и т.д.
Да
данные пакета NPH
var
var
Поле содержит данные, является необязательным. Наличие и структура поля должны однозначно определяться типом услуг () и типом пакета ().
Да