Базовое описание работы с протоколом ЕГТС

В пердыдущей статье я обещал рассказать про протокол EGTS. Это один из множества протоколов, который применятся передачи телеметрических данных. Особенность его в том, что он законодательно закреплен на территории Российской Федерации.

Для описания протокола используется в основом 2 докумета:

Первый документ, содержит описание межсетевого взаимодействия и структуры пакетов авторизации (об этом ниже).

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

Краткое описание взаимодействия

Указанный протокол является протоколом траспортного уровня. Общая длина пакета протокола транспортного уровняне превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP.

В протоколе предусморено 3 типа пакетов:

  • EGTS_PT_APPDATA - предназначен для передачи одной или нескольких структур, содержащих информацию.
  • EGTS_PT_RESPONSE - c помощью данного типа пакета осуществляется подтверждения пакета протокола транспортного уровня.
  • EGTS_PT_SIGNED_APPDATA - отвечает за передачу с применением цифровой площпди

Взаимодействие абонентского терминала (АТ) с сервевером происходит следующим образом:

  • АТ отправляет пакет авторизации на сервер
  • Сервер отправляет ответ о получении пакета
  • Затем сервер отправляет пакет EGTS_SR_RESULT_CODE с результатом авторизации.
  • Если авторизация пройдена, то АТ начинает отправку пакетов с данными.
  • На каждый пакет севрер отвечает пакетом типа EGTS_SR_RECORD_RESPONSE.

Схематично процесс изображен на рисунке ниже:

схема пакета протокола

Подробное описание процесса авторизации и пакетов которые учавствуют в этом процессе, можно получить в ГОСТ Р 54619 - 2011 в пункте 6.7.2.9 Описание процедуры авторизации.

Описание структуры пакета

Каждый пакет состоит из 3-х частей:

  • заголовок
  • тело пакета (поле SRFD на схеме)
  • контрольная сумма (поле SFRCS на схеме).

Схематично это выглядит следующим образом (рис. 1):

схема пакета протокола

Описание данных полей можно без проблем найти в приведенных выше документах, поэтому описавать их здесь я не буду.

Подробней я хотел бы остановиться на поле SRFD, так как в нем содержится основная информация.

Данное поле является набором стуруктур вида:

структура SRFD

Описание полей данной структуры приведено в ГОСТ Р 54619 - 2011 в разделе 6.6 Структуры данных, используемые в протоколе уровня поддержки услуг

Самыми полезными тут являются OID - идентификатор устройства и RD - набор подзаписей данных, которая имеет следующий формат:

структура RD

Как видно тут структура простая название типа записи, длина секции данных и cами данные. По сути структура похожа на TLV формат в карте тахографа.

Типы подзаписей могут взависимости от типа пакета могут быть следующие:

Код Название Тип пакета Документ
0 EGTS_SR_RECORD_RESPONSE Авторизация ГОСТ Р 54619
1 EGTS_SR_TERM_IDENTITY Авторизация ГОСТ Р 54619
2 EGTS_SR_MODULE_DATA Авторизация ГОСТ Р 54619
3 EGTS_SR_VEHICLE_DATA Авторизация ГОСТ Р 54619
6 EGTS_SR_AUTH_PARAMS Авторизация ГОСТ Р 54619
7 EGTS_SR_AUTH_INFO Авторизация ГОСТ Р 54619
8 EGTS_SR_SERVICE_INFO Авторизация ГОСТ Р 54619
9 EGTS_SR_RESULT_CODE Авторизация ГОСТ Р 54619
0 EGTS_SR_RECORD_RESPONSE Данные Приказ №285
16 EGTS_SR_POS_DATA Данные Приказ №285
17 EGTS_SR_EXT_POS_DATA Данные Приказ №285
18 EGTS_SR_AD_SENSORS_DATA Данные Приказ №285
19 EGTS_SR_COUNTERS_DATA Данные Приказ №285
20 EGTS_SR_STATE_DATA Данные Приказ №285
22 EGTS_SR_LOOPIN_DATA Данные Приказ №285
23 EGTS_SR_ABS_DIG_SENS_DATA Данные Приказ №285
24 EGTS_SR_ABS_AN_SENS_DATA Данные Приказ №285
25 EGTS_SR_ABS_CNTR_DATA Данные Приказ №285
26 EGTS_SR_ABS_LOOPIN_DATA Данные Приказ №285
27 EGTS_SR_LIQUID_LEVEL_SENSOR Данные Приказ №285
28 EGTS_SR_PASSENGERS_COUNTERS Данные Приказ №285

Для удобства я свел их в одну таблицу, с указанием, где можно посмореть описание.

Пример разбора пакета

Для примера разберем один пакет типа EGTS_PT_APPDATA, а затем соберем пакет EGTS_PT_RESPONSE в ответ на этот пакет.

Пакет EGTS_PT_APPDATA:

0100030B001300860001B608005F0099020000000101010500B0090200100DCE

Если данный пакет разобрать в соответствии со спецификацией, то в нем будет следующая информация следующее:

EGTS Transport Layer
---------------------

  Protocol Version    - 1
  Security Key ID     - 0
  Flags               - 00000011b (0x03)
       Prefix         - 00
       Route          -   0
       Encryption Alg -    00
       Compression    -      0
       Priority       -       11 (low)
  Header Length       - 11
  Header Encoding     - 0
  Frame Data Length   - 19
  Packet ID           - 134
  Header Check Sum    - 0xB6

EGTS Service Layer:
---------------------
  Packet Type         - EGTS_PT_APPDATA
  Service Layer CS    - 0xCE0D

    Service Layer Record:
    ---------------------
    Record Length               - 8
    Record Number               - 95
    Record flags                -     10011001b (0x99)
        Sourse Service On Device    - 1
        Recipient Service On Device -  0
        Group Flag                  -   0
        Record Processing Priority  -    11 (low)
        Time Field Exists           -      0
        Event ID Field Exists       -       0
        Object ID Field Exists      -        1
    Object Identifier           - 2
    Source Service Type         - 1 (EGTS_AUTH_SERVICE) from ST
    Recipient Service Type      - 1 (EGTS_AUTH_SERVICE)

       Subrecord Data:
       ------------------
       Subrecord Type      - 1 (EGTS_SR_TERM_IDENTITY)
       Subrecord Length    - 5

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

В данном примере можно увидеть увидеть что это пакет авторизации c PID=134 пришел от клиента с идентификатором 2 (Object Identifier). Соответственно при его получении клиент ждет соответствующий пакет подтвеждения операции.

Даный пакет будет выглядеть так:

0100000B0010008600001886000006005F002001010003005F00001373

Если разобрать его получим следующую информацию:


EGTS Transport Layer:
---------------------
  Protocol Version    - 1
  Security Key ID     - 0
  Flags               - 00000000b (0x00)
       Prefix         - 00
       Route          -   0
       Encryption Alg -    00
       Compression    -      0
       Priority       -       00 (the highest)
  Header Length       - 11
  Header Encoding     - 0
  Frame Data Length   - 16
  Packet ID           - 134
  No route info       -
  Header Check Sum    - 0x18

EGTS Service Layer:
---------------------
  Packet Type         - EGTS_PT_RESPONSE
  Service Layer CS    - 0x7313
  Responded Packet ID - 134
  Processing Result   - 0 (OK)

    Service Layer Record:
    ---------------------
    Record Length               - 6
    Record Number               - 95
    Record flags                -     00100000b (0x20)
        Sourse Service On Device    - 0
        Recipient Service On Device -  0
        Group Flag                  -   1
        Record Processing Priority  -    00 (the highest)
        Time Field Exists           -      0
        Event ID Field Exists       -       0
        Object ID Field Exists      -        0
    Source Service Type         - 1 (EGTS_AUTH_SERVICE)
    Recipient Service Type      - 1 (EGTS_AUTH_SERVICE)

       Subrecord Data:
       ------------------
       Subrecord Type      - 0 (EGTS_SR_RESPONSE)
       Subrecord Length    - 3
       Confirmed Record Number- 95
       Record Status          - 0 (OK)

По составу он очень похож на предыдущий, но у нас появляется поле Responded Packet ID в котором указывается PID пришедшего пакета, а в секции Subrecord Data отправляем подтвеждение о том что корректо обработали запись с запросом на авторизацию с id=95 ( Record Number из пакета авторизации).

Примечания по идентификатору пакета

Как правило инденификатор пакета передается в заголовке пакета в поле nph_request_id, но в некоторых случаях идентификатор пакета передается через счетчик в подзаписи EGTS_SR_ABS_CNTR_DATA в поле CNV. В CN=110 передаются три младших байта. В CN=111 передается один старший байт. Если старший байт отсутсвует, то CN=111 не передается.

Заключение

Надо отметить, что схема подтверждения пакетов может быть разная на разных устройствах, где-то подтвеждается каждая запись (Record Number), а где-то пакет целиком (Responded Packet ID).

Несколько записей появляется в тот моммент когда на устройстве начинают копиться точки и оно их отправляет разом все. Такое может быть при потери связи или же когда ТС заходит в резкий поворот.

Для работы с данным протоколом мной было реализовано небольшое приложение GitHub, которое извлекает необходимую информацию и пакета ЕГТС, а также осуществляет базовую авторизацию с устройством. Также есть возможность подключить разные хранилища для выходных данных (из готовых RabbitMQ, PostgreSQL) а также создавать плагины для работы с хранилищем.

 
comments powered by Disqus