Требования к специальным техническим средствам регистрации в автоматическом режиме движения, которыми оснащаются транспортные средства, осуществляющие перевозки этилового спирта



Скачать 397.05 Kb.
страница1/3
Дата31.05.2019
Размер397.05 Kb.
  1   2   3


Утверждены

приказом Федеральной службы

по регулированию алкогольного рынка

от __________________ №______


Требования к специальным техническим средствам

регистрации в автоматическом режиме движения, которыми оснащаются транспортные средства, осуществляющие перевозки этилового спирта (в том числе денатурата) и нефасованной спиртосодержащей продукции

с содержанием этилового спирта более 25 процентов

объема готовой продукции


  1. Настоящие Требования определяют требования к составу и техническим характеристикам специальных технических средств регистрации в автоматическом режиме движения, которые обеспечивают передачу данных о перемещении такого транспортного средства на территории Российской Федерации, в том числе данных о текущем местоположении, пройденном маршруте, времени и метах стоянок, по спутниковым навигационным системам в автоматизированную систему контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации (далее – технические средства), а также к выполняемым ими функциям.

2.  Технические средства должны обеспечивать:

а) передачу в автоматизированную систему контроля перевозок этилового спирта и спиртосодержащей продукции на территории Российской Федерации (далее – АСКП) данных в автоматическом режиме (с использованием спутниковых навигационных систем) о текущем местоположении, пройденном маршруте, времени и местах стоянок (далее – навигационные данные), а также данных от штатных уровнемеров, которыми оснащены емкости автомобильного транспорта для перевозки этилового спирта (в том числе денатурата) и нефасованной спиртосодержащей продукции с содержанием этилового спирта более 25 процентов объема готовой продукции (далее – продукция);

б) автоматическое переключение питания на внешнее питающее напряжение (аккумулятор автомобильного транспортного средства) в случае его восстановления с внутреннего аккумулятора;

в) автоматическое переключение питания с внутреннего аккумулятора в случае восстановления внешнего питающего напряжения (аккумулятора автомобильного транспортного средства);

г) защиту внутреннего аккумулятора от разряда ниже допустимого, а так же обеспечивать подачу сигнала в АСКП при уровне разряда аккумулятора свыше 80% от номинального уровня;

д) подзарядку источников электропитания технических средств от аккумулятора автомобильного транспортного средства;

е) передачу в АСКП информации о навигационных и иных предусмотренных настоящим порядком данных в течении не менее 168 часов с момента отключения от аккумулятора автомобильного транспортного средства.

3. Технические средства должны состоять из следующих основных функциональных модулей:

а) бортовой контроллер, оснащенный sim-картой для передачи данных по сети GPRS (далее – контроллер);

б) энергонезависимая память для записи и хранения навигационных и иных предусмотренных настоящими Требованиями данных;

в) модем для приема/передачи данных с системой стандарта
GSM /1800/1900/850 Mh;

г) спутниковый навигационный приемник систем ГЛОНАСС/GPS;

д) ГЛОНАСС/GPS антенна.

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

4. Технические средства должны соответствовать следующим техническим характеристикам:

а) объем основной энергонезависимой памяти должен обеспечивать запись и хранение информации не менее 20 000 событий;

б) цифровые входы для подключения к бортовым узлам и агрегатам должны использовать унифицированные токовые сигналы 4-20 мА;

в) напряжение питания при функционировании специальных технических средств должно быть в пределах от 12 до 24 вольт;

г) предусматривать хранение электронно-цифровой подписи с использованием которой осуществлялась передача информации.

4.1. В спутниковом навигационном приемнике ГЛОНАСС/GPS должен использоваться протокол обмена данными, соответствующий Приложению к настоящим Требованиям.

5. Технические средства должны обеспечивать выполнение следующих функций:

а) определение текущего местоположения оснащенного техническими средствами автомобильного транспортного средства по данным спутниковой навигации ГЛОНАСС/GPS;

б) запись и хранение навигационных данных в энергонезависимой памяти;

в) передачу в АСКП навигационных данных с заданной периодичностью (в диапазоне от 5 минут до 24 часов);

г) запись данных о состоянии технических средств (данных об уровне зарядки аккумулятора, о наличии связи с уровнемерами, о наличии сбоев в работе технических средств) и передаваемой в АСКП информации в энергонезависимую память при потере сигнала сотовой сети с последующей автоматической передачей записанной информации при возобновлении сигнала сотовой сети;

д) обмен данными по протоколу GPRS TCP/IP в зоне покрытия сотовой связи;

е) сбор, накопление и передача данных в АСКП от уровнемеров, которыми оснащены емкости автомобильного транспорта для перевозки продукции.

6. Технические средства должны соответствовать требованиям к оборудованию для работы во взрывоопасных средах, установленным Техническим регламентом Таможенного союза "О безопасности оборудования для работы во взрывоопасных средах", утвержденным решением Комиссии Таможенного союза от 18 октября 2011 г. № 825.

7. Технические средства должны быть предназначены для работы в диапазонах температур от минус 40 до плюс 60 градусов по Цельсию.

8. Контроллер должен обеспечивать опрос технических средств с заданной периодичностью (в диапазоне от 5 секунд до 24 часов) и запись цифровых данных в энергонезависимой памяти с привязкой ко времени и координатам местонахождения автомобильного транспортного средства.

9. Технические средства должны осуществлять передачу сведений о перевозках продукции, обеспечивая предотвращение искажения и подделки передаваемой информации.

10. Технические средства должны быть опломбированы (опечатаны) должностным лицом территориального органа Федеральной службы по регулированию алкогольного рынка до начала осуществления деятельности по перевозке продукции транспортным средством, на котором установлены данные технические средства.

____________

Приложение

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

от ____________ №_______



Протокол передачи навигационных данных NDTP

(Navigation Data Transfer Protocol)

16.03.2012, версия 1.0

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

Участниками обмена данными являются:

- Специальные технические средства, устанавливаемые на автомобильные транспортные средства, оснащенные специальными емкостями для перевозки продукции (далее – СТС);

- сервер сбора данных (далее - ССД);
Протокол обмена данными между участниками системы, согласно модели OSI, представлен ниже. Все уровни реализованы стандартными средствами, для СТС – встроенным стеком GPRS модема, для ССД – средствами ОС.


Уровни

СТС

ССД

Прикладной

команды и пакеты данных

команды и пакеты данных

Сеансовый

NPL

NPL

Транспортный

TCP

TCP

Протокол передачи данных 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 - для полей с переменной длиной.

2. Сеансовый уровень (протокол 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- да. Если отправитель пакета рассчиывает CRC он должен выставить данный флаг (1), в таком случае получатель имеет возможность проверить валидность пакета.

Нет. Данное поле всегда должно быть установлено в 1






2

unsigned int16

Значение контрольной суммы поля , либо 0x0000 если флаг NPL_FLAG_CRC не установлен. NPL_FLAG_CRC - определяет расчет контрольной суммы пакета (CRC). Принимает значения: 0 – нет, 1- да. Если отправитель пакета рассчитывает CRC, он должен выставить данный флаг (1), в таком случае получатель имеет возможность проверить валидность пакета.

Нет. Данное поле всегда должно быть установлено в 1






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 однонаправленные, подтверждения не требуют.

входящего пакета указывает адрес, от кого пришел данный пакет. В данном поле может передаваться либо адрес ССД (для пакетов, приходящих со стороны ССД на СТС), либо адрес СТС (для пакетов, приходящих со стороны СТС на ССД).

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

Пакеты NPL имеют следующие типы:

- NPL_TYPE_ERROR - ошибка протокола NPL

- NPL_TYPE_NPH - пакет данных NPH.
3.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 - доступ запрещен

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

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


    1. . Уровень представления (протокол 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

Поле содержит данные, является необязательным. Наличие и структура поля должны однозначно определяться типом услуг () и типом пакета ().

Да

- Тип пакета NPH_RESULT относится ко всем типам услуг.

3.4. Общий пакет подтверждения: NPH_RESULT

Пакет NPH_RESULT является общим для всех типов услуг, если запрос не предусматривает получения каких либо данных, в ответ на пакет запроса посылается пакет подтверждения NPH_RESULT.


Пакет подтверждения NPH_RESULT имеет следующий формат поля данных:

поле

длина

тип

описание

может ли данное поле (значение) изменяться в текущей реализации



4

unsigned int32

0 в случае успешного выполнения запроса или код ошибки

Да

Поле пакета NPH_RESULT может принимать следующие значения:

0 - успешное выполнение запроса;

Общие ошибки:

NPH_RESULT_OK - запрос выполнен успешно;

NPH_RESULT_UNDEFINED - код для ошибок не имеющих описания;

NPH_RESULT_BUSY - участник соединения не может обработать пакет в данный момент;

NPH_RESULT_SERVICE_NOT_SUPPORTED - тип услуг не поддерживается;

NPH_RESULT_SERVICE_NOT_ALLOWED - тип услуг запрещен для данного участника соединения;

NPH_RESULT_SERVICE_NOT_AVIALABLE - тип услуг не доступен в данный момент;

NPH_RESULT_PACKET_NOT_SUPPORTED - неизвестный тип пакета, либо тип пакет не поддерживается;

NPH_RESULT_PACKET_INVALID_FORMAT - неверный формат пакета;

NPH_RESULT_PACKET_INVALID_PARAMETER - неверный параметр пакета;

Ошибки установки соединения:

NPH_RESULT_PROTO_VER_NOT_SUPPORTED - версия протокола не поддерживается;

NPH_RESULT_CLIENT_NOT_REGISTERED - клиент не зарегистрирован на сервере (в БД);

NPH_RESULT_CLIENT_TYPE_NOT_SUPPORTED - тип клиента не поддерживается;

NPH_RESULT_CLIENT_AUTH_FAILED - ошибка аутентификации клиента.


4. Установка соединения с сервером.


Соединение с сервером может быть защищенным или незащищенным. Параметры соединения задаются инициатором соединения в поле пакета NPH_SGC_CONN_REQUEST. В первом случае все пакеты передаются в зашифрованном виде за исключением пакетов установки соединения:

- NPH_SGC_CONN_REQUEST,

- NPH_SGC_CONN_AUTH_STRING.
В случае отказа в установке соединении (на любом этапе) сервер посылает клиенту незашифрованный пакет NPH_RESULT с кодом ошибки.
Пакет запроса установки соединения NPH_SGC_CONN_REQUEST имеет следующий формат поля :


поле

длина

Тип

описание

может ли данное поле (значение) изменяться в текущей реализации




2

unsigned int16

версия протокола NDTP (старший номер)

Нет. Всегда должно быть установлено в 1




2

unsigned int16

версия протокола NDTP (младший номер)

Да



2

unsigned int16

опции соединения, определяет настройки соединения, которые будут использоваться после установки соединения. На данный момент их две:

  • бит2: рассчитывать CRC пакетов (0 - нет, 1 — да)




Нет. Все значения битов кроме второго должны быть установлены в 0. Значение второго бита должно быть установлено в 1




4

unsigned int32

адрес участника соединения, пославшего данный пакет

Да



4

unsigned int32

максимальный размер пакета, который сможет обработать этот участник соединения

Нет. Все значения битов должны быть установлены в 0















Так как сервер не устанавливает соединения, то пакет запроса соединения посылают только клиенты(СТС).

Поля
и
определяют версию протокола, по которой собирается работать клиент. В данной реализации
всегда должно быть установлено в 1.
Пакет с массивом данных для аутентификации клиента NPH_SGC_CONN_AUTH_STRING, имеет следующий формат поля :


поле

длина

тип

Описание

может ли данное поле (значение) изменяться в текущей реализации



var

char[]

массив данных. Длина массива определяется по полю пакета NPL

Да

5.  Мониторинг транспортных средств: NPH_SRV_NAVDATA
Навигационные данные передаются в типе передачи NPH_SRV_NAVDATA.

Существует два типа пакетов:

- NPH_SND_REALTIME – передача навигационных данных в реальном времени;

- NPH_SND_HISTORY – передача навигационных данных сохраненной в памяти устройства («ретроспективы»).

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


поле

длина

тип

описание

может ли данное поле (значение) изменяться в текущей реализации

< Type >

1

unsigned int8

Тип ячейки (определяет длину и содержимое). Различаются следующие типы:

0 – основные навигационные данные;

2 – данные от внутренних портов;

8 – данные от датчиков уровня продукта в отсеках.



Да

< Number >

1

unsigned int8

Определяет навигационный приемник: N=0 – GPS приемник, N=1 – GLONASS приемник.

Если Type=13, данное поле определяет номер отсека, к которому подключен уровнемер.



Да

< Data >

var

сhar[]

Данные от датчика. Структура определяется полем .

Да

Пакеты передачи навигационных данных NPH_SND_HISTORY, NPH_SND_REALTIME, имеют следующий формат поля :

Структура поля состоит из ячеек, каждая из которых имеет поля: , и переменной длины. Длина каждой ячейки поля определяется полем .

Порядок следования ячеек строго по увеличению поля для того, чтобы сервер смог разобрать известные пакеты, если не знает пакеты с определенного номера . Также могут идти несколько ячеек с одинаковым полем , но обязательно разными полями , которое определяет номер датчика, от которого идет данный пакет. Время формирования данных от внешних датчиков определяется пакетом навигационных данных.

Ячейка 2

Ячейка 1




Поделитесь с Вашими друзьями:
  1   2   3


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница