Протокол взаимодействия БО и АСУ ГПТ

Протокол взаимодействия БО и АСУ ГПТ.
Введение
Документ описывает взаимодействие между бортовым оборудованием
(БО) и сервером, осуществляющим первичную обработку данных для системы
«АСУ ГПТ». Сервер предназначен для управления подключениями БО,
получения данных и их передачи в обработку.
Принцип взаимодействия
Взаимодействие ведется по принципу ведущий-ведомый, причем ведущий
всегда сервер. Сервер отправляет запросы, а БО обрабатывает их и отправляет в
ответ требуемые данные.
Для организации взаимодействия каждое устройство использует два
соединения (канала данных), подключаясь к двум различным TCP портам – по
умолчанию 8221 и 8231. Оба подключения должны иметь одинаковую
функциональность на стороне устройства. Назначение каналов может
изменяться. В настоящее время по первому каналу производится получение геопространственных данных и данных диагностики, а по второму – получение
срабатываний тревожной кнопки.
Представление данных
Данные упаковываются в контейнеры (см. «Типы данных и структуры
TML»). Контейнеры могут содержать другие контейнеры (если не содержат
бинарные данные), но такое вложение должно быть ограничено правилами:
1. Контейнерами нулевого уровня являются контейнеры ReqRead, ReqWrite и
Reply.
2. Контейнерами
1-го
уровня
являются
контейнеры
DeviceDiag,
DeviceSWVersion, ServerSWVersion, GeoData, AlarmData, AuthData и т.п.
Контейнеры верхнего (нулевого) уровня не могут быть вложены в другие
контейнеры.
Фигурные скобки {} в описании контейнеров обозначают вложение,
квадратные скобки [] обозначают опциональные элементы. Принцип
организации структур TML похож на XML.
Контейнеры нулевого уровня
ReqRead = { [контейнеры 1-го уровня пустые или содержащие TimeBegin, TimeEnd]
}
ReqWrite = { [контейнеры 1-го уровня с данными] }
Reply = {[контейнеры 1го уровня с данными, если ответ на Read] или [контейнеры
1го без данных, если ответ на Write]}
Контейнеры из ReqRead могут содержать [TimeBegin] [TimeEnd] для получения выборки
за заданный интервал времени.
Наличие одного или двух опциональных значений времени влияет на алгоритм
формирования ответа – определяет, диапазон выбираемых из очереди данных (см. ниже).
В данной версии протокола можно выделить следующие логические потоки данных:
1
2
Идентификационная информация. Включает данные о версии ПО устройства, его
структурном составе, возможностях, уникальном идентификаторе, и поддерживаемой
версии протокола TML.
Данные о местоположении. Включают данные о широте/долготе от ГЛОНАСС
(GeoData)
3
4
5
Данные с датчиков. Включают состояние цифровых портов ввода/вывода, состояние
аналоговых входов (SensorsData)
Данные самодиагностики БО. Включают данные о наличии подключения GSM,
GLONASS, и др. (DeviceDiag)
Данные с КТС.
Порядок передачи данных
Транспортный уровень
1. Установление двух TCP соединений БО.
2. Передача данных, имеющихся у БО (ReqRead, ReqWrite, Reply) по запросу сервера.
3. Восстановление соединений при возникновении ошибок.
Запросы на чтение - ReqRead
Запросы к очередям на чтение могут запрашивать:
1. Верхние контейнеры очереди
2. Контейнеры, попадающие в запрашиваемый диапазон величин
Пример запроса:
ReqRead = { GeoData{ [TimeBegin], [TimeEnd] }, DeviceDiag{ }}
Указанный запрос обязывает БО выбрать из очередей контейнеров GeoData все данные в
интервале TimeBegin; TimeEnd и DeviceDiag – только последнее значение. Обе границы
временного интервала включены– могут быть точки соответствующие этим границам.
Ответ:
Reply = {
GeoData{ TimeBegin 1, …data…},
…,
GeoData{ TimeBegin N, …data…},
DeviceDiag{ TimeBegin, …data…}
}
где TimeBegin1 < TimeBegin_N-1 < TimeBeginN – временные метки.
Запросы на запись - ReqWrite
Запросы к очередям «на запись» содержат данные, которые БО должно сохранить или
передать далее по локальной шине конкретному модулю. В случае успешной записи, БО
должно отправить контейнер Reply, содержащий контейнеры данных, которые были
записаны:
где: Cnt1, Cnt2 – любые контейнеры первого уровня, вложенные в запрос/ответ; data –
указание на присутствие данных.
Пример:
ReqWrite = {Text{data}}- запрос сервера передать данные
Reply = {Text{}} – подтверждение от БО, что пакет запроса принят в обработку.
Работа с очередями
Во время работы БО, вне зависимости от наличия или отсутствия связи с сервером на
данный момент, производится накопление данных. Данные формируются в очереди на
отправку, по принципам FIFO. Ниже приведен пример работы с очередью на отправку:
Вариант запроса зависит от отсутствия или наличия в пакете значений меток времени –
TimeBegin и TimeEnd. При отсутствии меток времени в ответ оборудование отправляет
последний прибывший в очередь контейнер.
Если в запросе присутствуют метки времени – в ответ отправляется группа контейнеров
из очереди, попадающая в заданный метками времени диапазон (включительно).
Если по конкретному запросу ReqRead данные в очереди устройства отсутствуют, то в
ответ Replay не вкладываются контейнеры (так, при запросе из единственной очереди
Reply ={}).
Получение статуса очередей
Сервер запрашивает состояние очередей для выбора стратегии получения накопленных
данных.
В запросе статуса очередей может указываться временной интервал, за который
необходимо предоставить данные. Пример запроса на чтение статуса очереди:
Запрос статуса очередей (может указываться временной интервал):
ReqRead = {
QueueStatus {
GeoData{[TimeBegin], [TimeEnd]},
SensorsData{}
}
}
Ответ содержит информацию по указанным очередям:
Reply = {
QueueStatus {
GeoData {TimeBegin, TimeEnd, ItemsCount },
SensorsDataQueue{ TimeBegin, TimeEnd, ItemsCount }
},
}
Где: ItemsCount – количество элементов очереди; GeoDataQueue, SensorsDataQueue примеры специальных контейнеров для работы с очередями.
Очистка очередей
Очистка очередей производится по запросу сервера.
Устройство может само очищать очереди в случае соблюдения условий:
1. текущее состояние очередей не позволяет БО функционировать (переполнение);
2. уничтожение конкретных данных допустимо.
Запрос очистки:
ReqWrite = {
QueueClean{
GeoData{ TimeBegin, TimeEnd },
SensorsDataQueue {}
}
}
Ответ (отправляется после проведения очистки):
Reply = {
QueueClean {
GeoData{ TimeBegin, TimeEnd, ItemsCount },
SensorsData{ TimeBegin, TimeEnd, ItemsCount }
}
}
Авторизация
При подключении БО по любому из двух каналов сервер запрашивает данные устройства.
В ответ БО должно предоставить данные авторизации.
Обработка ошибок
В случае получения на стороне БО запроса, который противоречит каким-либо правилам
(см. ограничения), БО упаковывает данный запрос в контейнер «Ошибка» и отправляет
его на сервер.
Типы данных и структуры в TML
Представление логических типов данных
Данные представлены двумя основными видами:
1. простые типы - данные фиксированной длинны (формат type-value = TL);
2. контейнеры - данные переменной длинны (форматы type-length-value = TLV и
формат type-length-X-value = TLXV). Контейнеры подразделяются на:
1. обычные - включающие в себя другие (вложенные) контейнеры и элементы;
2. бинарные - содержащие только данные в виде массива байт.
Где: T – тип (тег), размер 1 байт (для контейнеров бит 7 тега всегда установлен в 1); L –
длина данных, двухбайтовое целое без знака; X – метаданные, их длина заранее известна и
включена в L; V – данные.
Контейнеры содержат либо вложенные элементы, либо вложенные бинарные данные – в
зависимости от типа контейнера. Бинарные контейнеры не могут содержать вложений
кроме массива байт. Специальные контейнеры могут быть как обычными, так и
бинарными, они содержат метаданные (например, характеристики алгоритма
шифрования, ЭЦП и т.п.) в формате TLXV.
Запись многобайтовых величин производится в Big Endian.
Байтовые массивы (bin) являются контейнерами TLV. Все строки (string) представлены в
кодировке UTF-8, хранятся точно также как и байтовые массивы - TLV.
Типы данных
Простые логические типы данных
Тип Название Тип Размер Описание
0x01 Latitude int32 4 Нормированная широта.
0x02 Longitude int32 4 Нормированная долгота.
0x03 PosDecision uint8 1 Источник и тип принятого решения по позиционированию
(аналог A/V в NMEA).
bit0 = 0: A
bit0 = 1: V
0x04 PosDirection uint16 2 Направление (из NMEA)
0x05 PosSpeed uint16 2 Скорость в сотых долях км/ч.
0x06 PosSatel uint8 1 кол-во видимых спутников
0x07 PosSatelDecision uint8 1 кол-во спутников участвовавших в решении
0x08 DeviceID uint32 4 Номер коробки в БД заказчика
0x10 TimeBegin uint32 4 POSIX timestamp (точка, или начало промежутка)
0x11 TimeEnd uint32 4 POSIX timestamp (окончание промежутка)
0x12 ItemsCount uint32 4 Количество элементов в очереди.
0x14 DeviceUptime uint32 4 Время работы изделия с момента включения
0x16 DeviceGNSS bin 1 Состояние ГЛОНАСС модуля
0x17 DeviceGSM bin 1 Состояние GSM модуля
0x18 DeviceSOFT bin 4 Состояние программного обеспечения.
0x1C DeviceRS485 bin 1 Состояние RS485
0x1D ADCData bin 2 бит поле с данными АЦП/цифрового входа: 4 бита - Номер Входа, 12
бит - показания/значение
0x20 ProtocolVersion * uint16 2 Версия протокола, старший и младший байты. 1.30 =
0x011E
0x21 Alarm uint8 1 Источник тревоги
1 – Alarm.
0x25 SerialNumber uint32 4 Серийный номер устройства.
0x26 ModVersion uint16 2 Версии модуля, старший и младший байты. 1.30 = 0x011E
0x27 PDOP uint8 1 Снижение точности измерения местоположения.
0x28 BatteryStatus uint32 1 Бит 0 - есть внешнее питание;
Бит 1 - устройство засыпает (пишется в базу непосредственно перед засыпанием);
Биты 2 и 3 - статус заряда батареи (00 - заряжается, 01 - разряжается, 10 -заряжена, 11 заряд приостановлен);
Бит 4 - слишком низкое внешнее питание;
Бит 5 - слишком высокое внешнее питание (сейчас не реализовано);
Бит 6 - температура вне диапазона;
Бит 7 - с т.зр. БО, батарея разряжена;
Биты 8..15 - зарезервированы;
Биты 16..25 - напряжение на батарее;
Биты 26..31 - зарезервированы;
* - Для текущей версии ProtocolVersion должен быть 0x100.
При нормировании долготы и широты используется множитель 10^7. Т.о. значения
долготы: -180*10^7…+180*10^7, широты: -90*10^7…+90*10^7.
Таблица. Контейнеры с бинарными данными переменной длинны.
Тип Название
Тип Размер Описание
0x81 PosNMEA string
10-80 TLV.
Строка формата NMEA-0183
0x82 NetAddress string 1-100 TLV.
IP или host для подключения.
0x86 Version string
1-100 TLV. Строка с названием подсистемы и ее версией
0x87 ModName string
1-15 TLV.
Строка с названием модуля.
0x88 SmsText string 1-140 TLV. Строка с содержимым SMS: команда устройству/ответ
устройства на команду.
0x89 QueueList bin
1-16 TLV.
присутствуют в устройстве, включая GeoData.
Перечисление типов очередей, которые
Один байт – один тип.
0x8A WayBill bin
1-512 TLV.
Данные маршрутного задания.
Структуры данных
Протокол TML позволяет группировать данные в структуры. Таким образом, одни и те же
типы данных могут иметь различное прикладное значение, в зависимости от структуры, в
которой они находятся. Структура данных находится внутри соответствующего
контейнера. В структуру могут входить как простые типы данных, так и другие структуры
(контейнеры). Структуры могут содержать как обязательные поля, так и опциональные.
Набор вложенных данных в контейнерах.
Тип Название Описание/содержимое
0xB1 DiagGNSS (TimeBegin)
(DeviceGNSS)
0xB2 DiagGSM (TimeBegin)
(DeviceGSM)
0xB3 DiagSOFT Отладочная очередь, отсутствует при эксплуатации.
(TimeBegin)
(DeviceSOFT)
0xB6 DiagETH (TimeBegin)
(DeviceEth)
0xB7 DiagRS485 (TimeBegin)
(DeviceRs485)
0xB9 DeviceSWVersion [ModInfo 1]
…[
ModInfo N]
0xBA ModInfo (ModName)
(ModVersion)
0xBC GeoData (TimeBegin)
(Latitude)
(Longitude)
(PosDirection)
(PosSpeed)
(PDOP)
[PosDecision]
[PosSatel]
[PosSatelDecision]
0xBD SensorsData (TimeBegin)
[ADCData1]
…[
ADCData8]
0xBE AlarmData (TimeBegin)
(Alarm)
(GeoData)
Вложенная GeoData содержит данные на момент тревоги.
Если нет тревог, то на запрос AlarmData БО возвращается пустой контейнер AlarmData.
0xBF WayBillData (TimeBegin)
(WayBill)
0xC0 AuthData (TimeBegin)
(DeviceID)
(SerialNumber)
(DeviceSWVersion)
(QueueList)
(ProtocolVersion)
0xC2 QueueStatus Состояние указанных очередей. Например, если было вложено GeoData:
(GeoData)
(TimeBegin)
(TimeEnd)
(ItemsCount) – только в ответе БО.
0xC3 QueueClean Очистка указанных очередей.
0xC4 OldProtocol Контейнер содержит бинарные данные (и запросы, и ответы)
старых устройств. Помещается внутрь ReqRead и Reply.
0xC5 DiagBattery (TimeBegin)
(BatteryStatus)
0xE1 ContainerCrc16 TLXV, специализированный контейнер, отличающийся от
TLV наличием 2 байт CRC16-CCITT (см. приложение 1)
0xE2…0xE8 Зарезервировано для сжатия данных, шифрования.
0xE9 Error Содержит запрос, который не удалось обработать или любая другая отладочная
информация – контейнер предназначен для «ручной» обработки.
0xEA ReqRead (ЗапрашиваемыйКонтейнер1 – с пустым содержимым)
[ЗапрашиваемыйКонтейнер2 – с пустым содержимым]
…
[ЗапрашиваемыйКонтейнерN – с пустым содержимым]
0xEB Reply [ЗапрашиваемыйКонтейнер1 – содержащий данные]
[ЗапрашиваемыйКонтейнер2 – содержащий данные]
…
[ЗапрашиваемыйКонтейнерN– содержащий данные]
0xEC ReqWrite [ЗаписываемыйКонтейнер1 – содержащий данные]
[ЗаписываемыйКонтейнер2 – содержащий данные]
…
[ЗаписываемыйКонтейнерN– содержащий данные]
где обязательное содержимое контейнера обозначено “ ( ) ”, а опциональное – “ [ ] ”
Приложение 1. Пример обмена данными
Примеры приведены в формате идентичном XML.
Авторизация
Request 6 bytes:
EA 00 03 C0 00 00 ......
<ReqRead>
<AuthData>
</AuthData>
</ReqRead>
Response 88 bytes:
EB 00 55 C0 00 52 10 4C BC 2D 68 08 01 D7 7F B7 ..U..R.L .-h.....
25 01 D7 7F B7 B9 00 36 BA 00 0C 87 00 06 63 6C %......6 ......cl
69 65 6E 74 26 00 02 BA 00 0B 87 00 05 61 6C 61 ient&... .....ala
72 6D 26 01 00 BA 00 0A 87 00 04 67 65 6F 73 26 rm&..... ...geos&
00 02 BA 00 09 87 00 03 73 6D 73 26 00 02 20 01 ........ sms&.. .
00 89 00 04 BC BE B1 B2 ........
<Reply>
<AuthData>
TimeBegin [4CBC2D68] 2010-10-18 15:20:08
DeviceID [01D77FB7]
SerialNumber [01D77FB7]
<DeviceSWVersion>
<ModInfo>
<ModName>
DATA[636C69656E74] 'client'
</ModName>
ModVersion [0002]
</ModInfo>
<ModInfo>
<ModName>
DATA[616C61726D] 'alarm'
</ModName>
ModVersion [0100]
</ModInfo>
<ModInfo>
<ModName>
DATA[67656F73] 'geos'
</ModName>
ModVersion [0002]
</ModInfo>
<ModInfo>
<ModName>
DATA[736D73] 'sms'
</ModName>
ModVersion [0002]
</ModInfo>
</DeviceSWVersion>
ProtocolVersion [0100]
<QueueList>
DATA[BCBEB1B2]
</QueueList>
</AuthData>
</Reply>
Запрос текущих точек
Request 12 bytes:
EA 00 09 BC 00 00 B1 00 00 B2 00 00 ........ ....
<ReqRead>
<GeoData>
</GeoData>
<DiagGNSS>
</DiagGNSS>
<DiagGSM>
</DiagGSM>
Response 49 bytes:
EB 00 2E BC 00 17 10 4C BC 01 87 01 23 AC B4 CD .......L ....#...
02 12 11 F3 D9 04 03 D6 05 00 04 27 02 B1 00 07 ........ ...'....
10 4C BB F1 91 16 03 B2 00 07 10 4C BB F1 72 17 .L...... ...L..r.
13 .
<Reply>
<GeoData>
TimeBegin [4CBC0187] 2010-10-18 12:12:55
Latitude [23ACB4CD]
Longitude [1211F3D9]
PosDirection [03D6]
PosSpeed [0004]
PDOP [02]
</GeoData>
<DiagGNSS>
TimeBegin [4CBBF191] 2010-10-18 11:04:49
DeviceGNSS [03]
</DiagGNSS>
<DiagGSM>
TimeBegin [4CBBF172] 2010-10-18 11:04:18
DeviceGSM [13]
</DiagGSM>
</Reply>
Запрос статуса очередей
Request 15 bytes:
EA 00 0C C2 00 09 BC 00 00 B1 00 00 B2 00 00 ........ .......
<ReqRead>
<QueueStatus>
<GeoData>
</GeoData>
<DiagGNSS>
</DiagGNSS>
<DiagGSM>
</DiagGSM>
</QueueStatus>
</ReqRead>
Response 60 bytes:
EB 00 39 C2 00 36 BC 00 0F 10 4C BB AF 52 11 4C ..9..6.. ..L..R.L
BC 02 77 12 00 00 10 94 B1 00 0F 10 00 00 00 00 ..w..... ........
11 00 00 00 00 12 00 00 00 00 B2 00 0F 10 00 00 ........ ........
00 00 11 00 00 00 00 12 00 00 00 00 ........ ....
<Reply>
<QueueStatus>
<GeoData>
TimeBegin [4CBBAF52] 2010-10-18 06:22:10
TimeEnd [4CBC0277] 2010-10-18 12:16:55
ItemsCount [00001094]
</GeoData>
<DiagGNSS>
TimeBegin [00000000] 1970-01-01 03:00:00
TimeEnd [00000000] 1970-01-01 03:00:00
ItemsCount [00000000]
</DiagGNSS>
<DiagGSM>
TimeBegin [00000000] 1970-01-01 03:00:00
TimeEnd [00000000] 1970-01-01 03:00:00
ItemsCount [00000000]
</DiagGSM>
</QueueStatus>
</Reply>
Запрос диапазона точек
Request 42 bytes:
EA 00 27 BC 00 0A 10 4C BB A5 EC 11 4C BB AA 9C ..'....L ....L...
B1 00 0A 10 4C BB F1 69 11 4C BB F1 91 B2 00 0A ....L..i .L......
10 4C 93 22 F9 11 4C BB F1 72 .L."..L. .r
<ReqRead>
<GeoData>
TimeBegin [4CBBA5EC] 2010-10-18 05:42:04
TimeEnd [4CBBAA9C] 2010-10-18 06:02:04
</GeoData>
<DiagGNSS>
TimeBegin [4CBBF169] 2010-10-18 11:04:09
TimeEnd [4CBBF191] 2010-10-18 11:04:49
</DiagGNSS>
<DiagGSM>
TimeBegin [4C9322F9] 2010-09-17 12:12:41
TimeEnd [4CBBF172] 2010-10-18 11:04:18
</DiagGSM>
</ReqRead>
Response 6283 bytes:
EB 18 88 BC 00 17 10 4C BB A5 ED 01 23 AD 0F F3 .......L ....#...
02 12 19 D0 13 04 04 C6 05 00 01 27 01 BC 00 17 ........ ...'....
…
<Reply>
<GeoData>
TimeBegin [4CBBA5ED] 2010-10-18 05:42:05
Latitude [23AD0FF3]
Longitude [1219D013]
PosDirection [04C6]
PosSpeed [0001]
PDOP [01]
</GeoData>
<GeoData>
TimeBegin [4CBBA5F2] 2010-10-18 05:42:10
Latitude [23AD13BE]
Longitude [1219F74C]
PosDirection [03FD]
PosSpeed [0001]
PDOP [01]
</GeoData>
…
<DiagGNSS>
TimeBegin [4CBBF169] 2010-10-18 11:04:09
DeviceGNSS [02]
</DiagGNSS>
<DiagGNSS>
TimeBegin [4CBBF191] 2010-10-18 11:04:49
DeviceGNSS [03]
</DiagGNSS>
<DiagGSM>
TimeBegin [4CBBF16A] 2010-10-18 11:04:10
DeviceGSM [05]
</DiagGSM>
<DiagGSM>
TimeBegin [4CBBF172] 2010-10-18 11:04:18
DeviceGSM [13]
</DiagGSM>
</Reply>
Запрос очистки очередей
Request 19 bytes:
EC 00 10 C3 00 0D BC 00 0A 10 00 00 00 00 11 4C ........ .......L
BB BE 6B ..k
<ReqWrite>
<QueueClean>
<GeoData>
TimeBegin [00000000] 1970-01-01 03:00:00
TimeEnd [4CBBBE6B] 2010-10-18 07:26:35
</GeoData>
</QueueClean>
</ReqWrite>
Response 24 bytes:
EB 00 15 C3 00 12 BC 00 0F 10 4C BB BB EB 11 4C ........ ..L....L
BB BE 6B 12 00 00 00 81 ..k.....
<Reply>
<QueueClean>
<GeoData>
TimeBegin [4CBBBBEB] 2010-10-18 07:15:55
TimeEnd [4CBBBE6B] 2010-10-18 07:26:35
ItemsCount [00000081]
</GeoData>
</QueueClean>
</Reply>