В пердыдущей статье я обещал рассказать про протокол 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, так как в нем содержится основная информация.
Данное поле является набором стуруктур вида:
Описание полей данной структуры приведено в ГОСТ Р 54619 - 2011 в разделе 6.6 Структуры данных, используемые в протоколе уровня поддержки услуг
Самыми полезными тут являются OID - идентификатор устройства и 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