Дата введения
1 июня 2024 года
с правом досрочного применения
Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены"
1 РАЗРАБОТАН Акционерным обществом "ГЛОНАСС" (АО "ГЛОНАСС")
2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии
3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 31 августа 2023 г. N 164-П)
За принятие проголосовали:
4 Приказом Федерального агентства по техническому регулированию и метрологии от 18 октября 2023 г. N 1183-ст межгосударственный стандарт ГОСТ 33465-2023 введен в действие в качестве национального стандарта Российской Федерации с 1 июня 2024 г. с правом досрочного применения
5 ВЗАМЕН ГОСТ 33465-2015
Информация о введении в действие (прекращении действия) настоящего стандарта и изменений к нему на территории указанных выше государств публикуется в указателях национальных стандартов, издаваемых в этих государствах, а также в сети Интернет на сайтах соответствующих национальных органов по стандартизации.
В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном Интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге "Межгосударственные стандарты"
Настоящий стандарт распространяется на устройства вызова экстренных оперативных служб, предназначенные для установки на колесные транспортные средства категорий M и N, а также на системы вызова экстренных оперативных служб, установленные на транспортные средства категорий M и N в соответствии с требованиями [1].
Настоящий стандарт устанавливает требования к протоколам обмена данными между устройством/системой вызова экстренных оперативных служб и инфраструктурой системы экстренного реагирования при авариях (далее - система), включая требования, связанные с предоставлением системой базовой услуги в целях выполнения требований [1] и ГОСТ 33464, а также требования к протоколам обмена данными при выполнении устройством/системой вызова экстренных оперативных служб функций мониторинга транспортного средства и определения, регистрации и передачи информации об обстоятельствах дорожно-транспортного происшествия.
В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:
ГОСТ 33464-2023 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Устройство/система вызова экстренных оперативных служб. Общие технические требования
ГОСТ 33472-2023 Глобальная навигационная спутниковая система. Аппаратура спутниковой навигации для оснащения колесных транспортных средств. Общие технические требования.
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации (www.easc.by) или по указателям национальных стандартов, издаваемым в государствах, указанных в предисловии, или на официальных сайтах соответствующих национальных органов по стандартизации. Если на документ дана недатированная ссылка, то следует использовать документ, действующий на текущий момент, с учетом всех внесенных в него изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то следует использовать указанную версию этого документа. Если после принятия настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение применяется без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.
3.1 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6 протокол передачи данных: Набор правил и соглашений, определяющих содержимое, формат, параметры времени, последовательность и проверку ошибок в сообщениях, которыми обмениваются сетевые устройства.
3.1.7 протокол уровня приложений IPv4: Протокол верхнего (4-го) уровня сетевой модели TCP/IP.
3.1.8
3.1.9 сервис: Элемент инфраструктуры телематической платформы, обеспечивающий функциональное выполнение алгоритма той или иной услуги, оказываемой системой.
3.1.10
3.1.11
3.1.12 сообщение: Совокупность данных, отправляемых одномоментно из телематического устройства в телематическую платформу или из телематической платформы в телематическую платформу.
3.1.13
3.1.14
3.1.15 телематическая платформа; ТП: Техническое решение, которое взаимодействует с телематическими устройствами и другими телематическими платформами в части приема и передачи телематических данных, а также занимается их обработкой.
3.1.16 телематическое устройство; ТУ: Бортовое навигационно-коммуникационное устройство, позволяющее осуществлять экстренные вызовы, отправлять телематическую информацию или информацию о параметрах вождения ТС, а также принимать соответствующую информацию от телематических платформ.
3.1.17
3.2 Сокращения и обозначения
В настоящем стандарте применены следующие сокращения и обозначения:
ГНСС - глобальная навигационная спутниковая система;
А-ГНСС - режим информационной поддержки навигационных определений;
АС - автомобильная система;
ГЛОНАСС - глобальная навигационная спутниковая система Российской Федерации;
ДТП - дорожно-транспортное происшествие;
ДУЖ - датчик уровня жидкости;
ОГРН - основной государственный регистрационный номер;
ПЗ-90.11 - система геодезических параметров "Параметры Земли 1990 года", используемая в ГНСС "ГЛОНАСС";
ПО - программное обеспечение;
ППУ - протокол уровня поддержки услуг;
ПТУ - протокол транспортного уровня;
ПРТС - подвижная радиотелефонная связь;
СПРС - соединение ПРТС с помощью всех доступных для УСВ стандартов связи GSM/GPRS/UMTS/HSDPA/LTE и поколений 2G/3G/4G и пр.;
ТП - телематическая платформа;
ТС - транспортное средство;
УСВ - устройство/система вызова экстренных оперативных служб;
Цифровая подпись - информация в электронной форме, которая используется для идентификации отправителя данных;
AL ACK - подтверждение уровня приложения;
ASN.1 - абстрактная синтаксическая нотация один;
BeiDou - глобальная навигационная спутниковая система Китайской Народной Республики;
CP-1251 - набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows;
CRC-8(16) - циклический избыточный код;
DNS - система доменных имен;
eCall - общеевропейская система экстренного реагирования при авариях;
EGTS - телематический стандарт для системы экстренного реагирования при авариях;
FTP - протокол передачи файлов;
IP - межсетевой протокол;
Galileo - глобальная навигационная спутниковая система Европейского союза;
GPRS - пакетная радиосвязь общего пользования;
GPS - глобальная навигационная спутниковая система Соединенных Штатов Америки;
GSM - глобальный цифровой стандарт для мобильной сотовой связи;
HTTP - протокол передачи гипертекста;
IMAP - протокол прикладного уровня для доступа к электронной почте;
ISDN - цифровая сеть с интеграцией обслуживания;
Little-endian - младший байт вперед (порядок следования байтов);
NGTP - телематический протокол следующего поколения. Архитектура и концепция построения;
OID - идентификатор объекта;
OSI - базовая эталонная модель взаимодействия открытых систем - абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов;
PDU - элемент описания протокола;
POP3 - протокол почтового отделения, версия 3;
SC - сервис-центр, ответственный за обработку, хранение и передачу SMS-сообщений получателям;
SIM - модуль идентификации абонента;
SME - объекты, способные отправлять и получать SMS-сообщения;
SMS - сервис коротких сообщений;
SMSC - центр обработки коротких сообщений;
SMTP - простой протокол передачи почты;
TCP - протокол управления передачей;
TFTP - простой протокол передачи файлов;
telnet - сетевой протокол для реализации текстового интерфейса по сети;
UDP - протокол пользовательских дейтаграмм;
WGS-84 - всемирная геодезическая система координат 1984 г.
4.1 Сетевая модель взаимодействия открытых систем согласно [2] определяет следующие уровни обмена данными:
- физический;
- канальный;
- сетевой;
- транспортный;
- сеансовый;
- представления данных и приложений.
4.2 В терминах сетевой модели OSI в системе экстренного реагирования при авариях для передачи данных между УСВ и оператором системы используются следующие протоколы:
- TCP - транспортный уровень;
- IP - сетевой уровень.
Соответствие сетевой модели OSI, стека протоколов TCP/IP и протоколов передачи данных системы экстренного реагирования при авариях представлено в таблице 1.
Таблица 1
протоколов TCP/IP и протоколов системы
4.3 Настоящий стандарт устанавливает требования к следующим видам протоколов обмена информацией между элементами системы экстренного реагирования при авариях:
- протоколу транспортного уровня;
- протоколу уровня поддержки услуг, включая базовую услугу, оказываемую системой экстренного реагирования при авариях;
- протоколу уровня приложений;
- протоколу определения местоположения пользователей.
4.4 Настоящий стандарт также устанавливает требования к формату сообщения AL-ACK, которое высылается посредством использования тонального модема (см. [3]).
4.5 Нормативные положения настоящего стандарта, связанные с установлением требований к продолжительности временных интервалов при выполнении УСВ соответствующих функций, должны измеряться с погрешностью, не превышающей +/- 2% от предельных значений указанных временных интервалов.
5.1 Назначение протокола транспортного уровня
5.1.1 Протокол транспортного уровня предназначен для обеспечения маршрутизации информации протокола уровня поддержки услуг между пунктами инфраструктуры системы экстренного реагирования при авариях и УСВ, использующих данный протокол, проверки целостности и правильной последовательности данных, а также обеспечения надежности доставки до пункта назначения.
5.1.2 Описание принципа построения системы на основе протокола транспортного уровня приведено в приложении А.
5.1.3 Анализ протокола транспортного уровня на основе концепции NGTP приведен в приложении Б.
5.2 Обеспечение маршрутизации
В основу протокола транспортного уровня положен принцип гибкой маршрутизации пакетов данных между взаимоувязанными элементами распределенной сети ТП, использующих данный протокол. В качестве адресов маршрутизации используются идентификаторы ТП, которые должны быть уникальны в рамках одной взаимоувязанной сети.
5.3 Механизм проверки целостности данных
Проверка целостности передаваемой информации основана на применении контрольных сумм заголовка транспортного уровня и данных уровня поддержки услуг. Принимающая сторона подсчитывает контрольные суммы и сравнивает их с соответствующими значениями, записанными отправляющей стороной в определенные поля пакета. Если контрольные суммы не совпадают, то считается, что целостность нарушена, на что отправляется подтверждение в виде кода ошибки результата обработки.
В целях обеспечения минимизации использования системных ресурсов при обработке пакетов протокола в части транспортного уровня и данных уровня поддержки услуг используются различные поля и алгоритмы обеспечения контроля целостности. При этом используется механизм, основанный на подсчете контрольной суммы, передаваемой последовательности байтов (CRC).
Для части пакета транспортного уровня используется алгоритм вычисления циклического избыточного кода CRC-8.
Для части пакета уровня поддержки услуг используется алгоритм вычисления циклического избыточного кода CRC-16.
5.4 Обеспечение надежности доставки пакетов данных
5.4.1 Механизм обеспечения надежной доставки основан на использовании подтверждений ранее отправленных пакетов. Отправляющая сторона после передачи пакета ожидает на него подтверждения в виде пакета определенного типа, содержащего идентификатор ранее переданного пакета и код результата его обработки на принимающей стороне. Ожидание производится в течение определенного промежутка времени, регламентированного протоколом транспортного уровня и зависящего от типа используемого транспортного протокола нижнего уровня (параметр TL_RESPONSE_TO) (см. 5.8). После получения подтверждения отправляющая сторона производит анализ кода результата.
Коды результатов обработки также регламентированы протоколом транспортного уровня и представлены в приложении В.
5.4.2 В зависимости от результата анализа пакет считается доставленным или недоставленным. Пакет также считается недоставленным, если подтверждение не приходит по истечении времени TL_RESPONSE_TO (см. 5.8). Недоставленные пакеты отправляются повторно (число попыток отправки регламентировано настоящим протоколом и определяется параметром TL_RESEND_ATTEMPTS) (см. 5.8). По достижении предельного числа попыток отправки канал передачи данных считается ненадежным, и производится уничтожение установленной сессии (разрыв соединения в случае использования TCP/IP протокола в качестве транспортного) и попытка создания новой сессии (соединения) через время, определяемое параметром TL_RECONNECT_TO (см. 5.8).
5.5 Описание типов данных, используемых в протоколе транспортного уровня
5.5.1 Протоколом транспортного уровня определены и используются несколько различных типов данных полей и параметров. Состав и описание типов данных, используемых в протоколе транспортного уровня, представлены в таблице 2.
Таблица 2
в протоколе транспортного уровня
5.5.2 Многобайтовые типы данных USHORT, UINT, ULONG, FLOAT и DOUBLE используют порядок следования байтов little-endian (младший байт вперед). Байты, составляющие последовательность в типах STRING и BINARY, должны интерпретироваться как есть, т.е. обрабатываться в порядке их поступления.
5.5.3 В протоколе транспортного уровня определены следующие типы полей и параметров:
- M (mandatory) - обязательный параметр. Параметр должен передаваться всегда;
- O (optional) - необязательный. Параметр может не передаваться, и его присутствие определяется другими параметрами, входящими в пакет.
5.6 Описание структур данных, используемых в протоколе транспортного уровня
5.6.1 Общая структура пакета протокола транспортного уровня определяется составом пакета и его форматом.
5.6.1.1 Пакет протокола транспортного уровня состоит из заголовка, поля "данные уровня поддержки услуг", а также поля контрольной суммы "данных уровня поддержки услуг".
Состав пакета протокола транспортного уровня представлен на рисунке 1.
5.6.1.2 Общая длина пакета протокола транспортного уровня не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP. Такое значение максимального размера пакета позволяет более эффективно использовать каналы передачи данных, базируясь только на стандартном методе управления потоком данных, заложенном в протоколе TCP/IP (см. [3]).
Формат пакета транспортного уровня представлен в таблице 3.
Таблица 3
5.6.1.3 Заголовок протокола транспортного уровня состоит из следующих параметров (полей): PRV, PRF, PR, CMP, ENA, RTE, HL, HE, FDL, PID, PT, PRA, RCA, TTL, HCS. Протокол уровня поддержки услуг представлен полем SFRD, контрольная сумма поля уровня поддержки услуг содержится в поле SFRCS.
Описание вышеуказанных параметров (полей) приведено в таблице 4.
Таблица 4
протокола транспортного уровня
5.6.1.4 Блок-схема алгоритма сборки пакета ПТУ при приеме представлена на рисунке 2.
![]() А - маршрутизация и отправка пакета на другую ТП;
Б - обработка данных протокола уровня поддержки услуг
при приеме
5.6.1.5 Кодировка печатных символов при сборке ПТУ осуществляется с использованием таблиц, приведенных в приложении Е.
5.6.2 Структуры данных в зависимости от типа пакета
В зависимости от типа пакета протокола транспортного уровня структура поля SFRD имеет различный формат.
5.6.2.1 Структура данных пакета EGTS_PT_APPDATA
Пакет данного типа предназначен для передачи одной или нескольких структур, содержащих информацию протокола уровня поддержки услуг. Структура данных поля SFRD пакета EGTS_PT_APPDATA представлена в таблице 5.
Таблица 5
5.6.2.2 Структура данных пакета EGTS_PT_RESPONSE
С помощью данного типа пакета осуществляется подтверждение пакета протокола транспортного уровня. Данный тип пакета содержит информацию о результате обработки данных протокола транспортного уровня, полученного ранее. Структура данных поля SFRD пакета EGTS_PT_RESPONSE представлена в таблице 6.
Таблица 6
5.6.2.3 Структура данных пакета EGTS_PT_SIGNED_APPDATA
Пакет данного типа применяется для передачи помимо структур, содержащих информацию уровня поддержки услуг, также информацию о "цифровой подписи", идентифицирующей отправителя данного пакета. Структура данных поля SFRD пакета EGTS_PT_SIGNED_APPDATA представлена в таблице 7.
Таблица 7
5.6.2.4 На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от УСВ на ТП или от нее на УСВ, должен быть отправлен пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA.
На рисунке 3 представлена последовательность обмена пакетами при взаимодействии УСВ и ТП.
![]() на уровне пакетов транспортного уровня
5.7 Описание структуры данных при использовании SMS в качестве резервного канала передачи данных
5.7.1 Структура SMS-сообщения
При использовании SMS для передачи пакетов данных протокола транспортного уровня используется режим PDU (см. [5], [6]). Режим PDU позволяет передавать не только текстовую, но и бинарную информацию через сервис SMS оператора сотовой связи GSM. Описываемый протокол транспортного уровня оперирует бинарными данными, поэтому PDU-режим наиболее подходит для использования SMS в качестве резервного канала передачи транспортного уровня.
5.7.1.1 Для передачи SMS-сообщения используется 8-битная кодировка. Формат SMS-сообщения для отправки в PDU-режиме представлен в таблице 8 и использует соответствующую структуру (структура представлена в [6] (раздел 9)).
Таблица 8
5.7.1.2 Описание параметров, входящих в состав SMS-сообщения в PDU-режиме, приведено ниже:
- SMSC_AL - длина полезных данных адреса SMSC в октетах;
- SMSC_AT - тип формата адреса SMSC.
Возможные значения параметров SMSC_AT представлены в таблице 9.
Таблица 9
Параметры полей TP_DA_T и SMSC_AT, приведенные в таблице 9, имеют следующие назначения:
- TON (Type Of Number) - тип номера. Параметр TON может принимать следующие значения:
а) 000 - неизвестный;
б) 001 - международный формат;
в) 010 - национальный формат;
г) 011 - специальный номер, определяемый сетью;
д) 100 - номер абонента;
е) 101 - буквенно-цифровой код (коды приведены в [5] с 7-битной кодировкой по умолчанию);
ж) 110 - укороченный;
и) 111 - зарезервировано;
- NPI (NumericPlanIdentification) - тип плана нумерации (применимо для значений поля TON-000,001,010). NPI может принимать следующие значения:
а) 0000 - неизвестный;
б) 0001 - план нумерации ISDN телефонии;
в) 0011 - план нумерации при передаче данных;
г) 0100 - телеграф;
д) 1000 - национальный;
е) 1001 - частный;
ж) 1111 - зарезервировано.
Поле опциональное, и наличие его зависит от значения параметра SMSC_AL (если значение SMSC_AL больше 0, то данное поле присутствует);
- SMSC_A - адрес SMSC. Каждая десятичная цифра номера представлена в виде 4 бит (младшие 4 бита - цифра более старшего разряда, старшие 4 бита - цифра меньшего разряда), при этом если число цифр в номере нечетное, то в битах с 4 по 7 последнего байта номера устанавливается значение 0xF (1111b). Данный параметр опциональный, и его наличие зависит от значения параметра SMSC_AL. В случае отсутствия параметра SMSC_A используется SMSC из SIM-карты;
- TP_MTI - (Message Type Indicator) тип сообщения (должен содержать бинарное значение 01);
- TP_RD - (Reject Duplicates) поле определяет, необходимо ли SMSC принимать данное сообщение на обработку, если существует предыдущее необработанное отправленное с данного номера сообщение, которое имеет такое же значение поля TP_MR и такой же номер получателя в поле TP_DA;
- TP_VPF - (Validity Period Format) формат параметра TP_VP. Возможные значения поля TP_VPF представлены в таблице 10;
Таблица 10
- TP_SRR - (Status Report Request) поле определяет необходимость отправки подтверждения со стороны SMSC на данное сообщение (если данный бит имеет значение 1, то требуется подтверждение);
- TP_UDHI - (User Data Header Indicator) поле определяет, передается ли заголовок пользовательских данных TP_UD_HEADER (если поле имеет значение 1, то заголовок присутствует);
- TP_RP - (Reply Path) поле определяет, присутствует ли поле RP в сообщении;
- TP_MR - идентификатор сообщения (должен увеличиваться на 1 при каждой отправке нового сообщения);
- TP_DA_L - длина полезных данных адреса получателя в октетах;
- TP_DA_T - тип формата адреса получателя. Возможные значения параметров TP_DA_T и SMSC_AT представлены в таблице 9;
- TP_DA - адрес получателя. Кодировка номера производится по тем же правилам, что и в параметре SMSC_A;
- TP_PID - идентификатор протокола (должен содержать значение 00);
- TP_DCS - тип кодировки данных (должен содержать значение 0x04, определяющий 8-битную кодировку сообщения, отсутствие компрессии);
- TP_VP - время актуальности данного сообщения. Формат данного поля определяется значением из таблицы 10. Параметр является опциональным. Его наличие и размер зависят от значения поля TP_VPF;
- TP_UDL - длина данных сообщения из поля TP_DL в байтах для используемой 8-битной кодировки;
- TP_UD - непосредственно передаваемые пользовательские данные. Формат данного поля, в зависимости от значения поля TP_UDHI, представлен в таблице 11.
Таблица 11
Параметры поля TP_UD, приведенные в таблице 11, имеют следующие назначения:
- LUDH - длина заголовка пользовательских данных в байтах без учета размера данного поля;
- IEI "A", IEI "B", IEI "N" - идентификатор информационного элемента "A", "B" и "N" соответственно, который определяет тип информационного элемента и может принимать следующие значения (в шестнадцатеричной системе):
а) 00 - часть конкатенируемого SMS-сообщения;
б) 01 - индикатор специального SMS-сообщения;
в) 02 - зарезервировано;
г) 03 - не используется;
д) 04 - 7F - зарезервировано;
е) 80 - 9F - для специального использования SME;
ж) A0 - BF - зарезервировано;
и) C0 - DF - для специального использования SC;
к) E0 - FF - зарезервировано.
- LIE "A", LIE "B", LIE "N" - параметры, определяющие размер данных информационных элементов "A", "B" и "N" соответственно в байтах без учета размера данного поля;
- IED "A", IED "B", IED "N" - данные информационных элементов "A", "B" и "N" соответственно;
- UD - данные пользователя. Размер данного поля определяется наличием заголовка пользовательских данных TP_UD_HEADER, состоящего из полей LUDH, IEI, LIE, IED. Если заголовок не передается, то размер равен значению поля TP_UDL, указанному в таблице 8. Если заголовок передается, то размер поля вычисляется как разность (TP_UDL - LUDH-1).
В случае, если идентификатор информационного элемента IEI заголовка пользовательских данных TP_UD_HEADER имеет значение 00, структура поля IED будет иметь вид, указанный в таблице 12.
Таблица 12
характеризующего часть конкатенируемого SMS-сообщения
5.7.1.3 УСВ, которые поддерживают функцию мониторинга ТС, при приеме SMS-сообщения используют формат SMS-DELIVER с 8-битной кодировкой. Формат принимаемого SMS-сообщения в PDU режиме должен соответствовать формату, указанному в ГОСТ 33472.
5.7.2 Описание формата передаваемой информации
5.7.2.1 При использовании SMS для обмена данными между УСВ и ТП пакеты, упакованные по правилам протокола транспортного уровня и протокола уровня поддержки услуг, помещаются в поле TP_UD (см. таблицу 8), при этом полный размер пакета протокола не должен превышать 140 байт. В этом случае механизм авторизации не используется и подтверждения протокола транспортного уровня в виде пакета типа EGTS_PT_RESPONSE и уровня поддержки услуг в виде подзаписи EGTS_SR_RECORD_RESPONSE на переданные пакеты не требуются. Признаком успешного прохождения пакета до УСВ является уведомление о доставке SMS.
На подзапись EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE, содержащую команду или сообщение, требуется подтверждающая подзапись EGTS_SR_COMMAND_DATA с соответствующим значением полей CT (CommandType) и CCT (CommandConfirmationType). В случае отправки команды на УСВ через SMS соответствующий пакет EGTS, содержащий подтверждение о приеме команды в виде подзаписи EGTS_SR_COMMAND_DATA, должен быть передан с УСВ через SMS.
5.7.2.2 Для отправки SMS, содержащего "цифровую подпись", используется пакет транспортного уровня типа EGTS_PT_SIGNED_APPDATA.
5.7.2.3 В случае, если размер пакета данных протокола превышает 140 байт, используется механизм конкатенации SMS-сообщений (см. [6], (9.2.3.24.1)). Суть данного механизма состоит в том, что передаваемые пользовательские данные разбиваются на части и отправляются отдельными SMS-сообщениями. При этом каждое такое сообщение содержит специальную структуру, определяющую общее число частей передаваемых данных и порядок их сборки на принимающей стороне. В качестве такой структуры используется поле TP_UD_HEADER, которое содержит информационный элемент, характеризующий часть конкатенируемого SMS-сообщения. Таким образом, исходя из размера заголовка данных пользователя и максимального числа частей длинного сообщения, равного 255, максимально возможный размер пакета при использовании 8-битной кодировки может составлять 255(140 - 6) = 34170 байт.
При использовании SMS в качестве канала передачи пакетов EGTS на УСВ ограничивают размер одного пакета EGTS значением 10(140 - 6) = 1360 байт, т.к. использование большего размера может привести к переполнению внутреннего приемного буфера УСВ. Максимальный размер 1360 байт позволит передавать элементарное сообщение EGTS с использованием цифровой подписи (поля SIGL/SIGD) и кода авторизации (ACL/AC).
5.8 Временные и количественные параметры протокола транспортного уровня при использовании пакетной передачи данных
Наименование и описание временных и количественных параметров протокола транспортного уровня приведены в таблице 13.
Таблица 13
транспортного уровня
5.9 Передача МНД в некорректируемом виде
Передаваемый с использованием тонального модема объем МНД всегда равен 140 байт.
При этом полезная (задействованная) часть блока данных МНД вместе с данными Optional Additional Data, указанными в ГОСТ 33464-2023 (таблица В.1), размещаются в начале блока данных, а незадействованные, оставшиеся свободными байты заполняются буферным значением (как правило, нулевым).
При передаче МНД в некорректируемом виде незадействованные байты используются следующим образом:
- в первые два байта помещается номер ключа шифрования, при помощи которого УВС был сформирован код аутентификации МНД;
- далее следует массив данных кода аутентификации объемом 32 байта, сформированной по алгоритму (см. [7]);
- оставшиеся незадействованными байты заполняются нулевыми значениями до достижения установленного объема блока данных в 140 байт.
Код аутентификации формируется для массива данных от первого байта блока МНД по байт (включая его), предшествующий номеру ключа, т.е. по всем полезным данным МНД.
5.9.2 Передача МНД в некорректируемом виде с использованием SMS
Для передачи МНД по резервному каналу с использованием SMS используется расширение сервиса EGTS_ECALL_SERVICE. При этом должна быть сформирована подзапись EGTS_SR_SIGNED_RAW_MSD_DATA, за которой закреплен идентификационный номер 41.
Структура подзаписи EGTS_SR_SIGNED_RAW_MSD_DATA приведена в таблице 14.
Таблица 14
Описание полей:
- SK# - Security Key Number - номер ключа, при помощи которого УВС был сформирован код аутентификации МНД;
- SD - Signature Data - массив размером 32 байта данных кода аутентификации, сформированный по алгоритму (см. [7]). Код аутентификации формируется по всем данным поля MSD;
- MSD - минимальный набор данных (полезная часть данных МНД и Optional Additional Data указаны в 5.9.1).
6.1 Назначение протокола уровня поддержки услуг
6.1.1 ППУ предназначен для обеспечения обмена данными между элементами системы экстренного реагирования при авариях в целях обеспечения функционирования системы для оказания информационных услуг потребителям. Каждой услуге соответствует отдельный сервис, который является ключевым элементом в рамках системы, построенной с использованием протокола уровня поддержки услуг.
6.1.2 ППУ выполняет следующие основные функции:
- обмен информационными сообщениями, содержащими данные для обработки различными сервисами, а также запросы на выдачу информации сервисами;
- обеспечение уведомления о результатах доставки и обработки данных уровня поддержки услуг;
- идентификацию принадлежности данных определенному типу сервиса;
- определение характеристик данных (число, тип, состав, размер, кодировка и др.).
6.1.3 Настоящий стандарт содержит описание ППУ (протокола EGTS) версии "02", являющегося развитием предыдущей версии ППУ, версии "01".
Описание ППУ (протокола EGTS) версии "01" приведено в приложении Ж.
По мере разработки и ввода в действие ТП и других систем мониторинга, а также по мере разработки и эксплуатации УСВ, обеспечивающих работу в соответствии с данным стандартом по протоколу версии "02", в производственно-технологической среде транспортного комплекса возникнет ситуация взаимодействия УСВ и ТП разных версий.
Для обеспечения совместимости систем и устройств, работающих в соответствии с протоколами разных версий, при обмене данными УСВ с инфраструктурой системы экстренного реагирования при авариях рекомендована процедура обеспечения совместимости, описанная в данном разделе. Аналогичная процедура обеспечения совместимости рекомендована при обмене данными между УСВ, системами мониторинга и/или ТП.
Совместимость устройств и систем, поддерживающих различные версии протокола, должна обеспечиваться за счет реализации и выполнения процедуры выбора поддерживаемого протокола. Такая процедура выбора поддерживаемого протокола должна реализовываться и выполняться на стороне устройств и систем, работающих по протоколу версии "02".
Для обеспечения совместимости на стороне УСВ и ТП необходима реализация обеих версий протокола.
Условия и алгоритмы авторизации, позволяющие реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий:
1 Для обеспечения управления выбором протокола при взаимодействии устройств и систем применяются специализированные команды и параметры УСВ, описанные в 6.7.3.2 (таблицы 35, 36, 37).
2 Для обеспечения совместимости необходима реализация и выполнение следующих процедур:
а) для УСВ, поддерживающих протокол версии "02", - задание или отправка на УСВ конфигурационных команд с указанием адреса ТП одновременно с указанием версии протокола, поддерживаемого данной ТП;
б) для УСВ, поддерживающих протокол версии "02", - отправка на УСВ конфигурационных команд, указывающих приоритет выбора версии протокола при взаимодействии с конкретными ТП;
в) для УСВ, поддерживающих протокол версии "02", - отправка конфигурационных команд, указывающих приоритет выбора версии протокола при взаимодействии со всеми ТП;
г) для ТП, поддерживающей протокол версии "02", - отправка на УСВ подтверждений с указанием поддерживаемой версии протокола "02" при авторизации УСВ;
д) для УСВ, поддерживающих протокол версии "02", - при первичной авторизации на ТП необходимо использовать протокол версии "01" и в случае успешной авторизации и передачи данных необходимо выполнить попытку авторизации согласно протоколу версии "02". При успешной авторизации по протоколу версии "02" - определить для передачи данных протокол версии "02". При неуспешной авторизации по протоколу версии "02" 0150 определить для передачи данных протокол версии "01".
Принципы, определяющие выбор версии протокола для обмена данными:
а) выбирается максимально высокая версия протокола, поддерживаемая обеими сторонами обмена;
б) с целью снижения нагрузки на ТП и обеспечения корректности определения устойчивой связи между УСВ и ТП попытки авторизации и передачи данных выполняются "снизу вверх", от младшей версии к старшей.
6.2 Обмен информационными сообщениями
Основной структурой протокола уровня поддержки услуг, содержащей в себе все необходимые данные для обработки информации или запроса на предоставление той или иной услуги, является запись. Каждая запись может иметь в своем составе несколько подзаписей, содержащих необходимые данные и определяющих действия, которые должен произвести сервис, обрабатывающий данную подзапись.
6.3 Обеспечение уведомления о результате доставки и обработки данных уровня поддержки услуг
На уровне поддержки услуг уведомление отправляющей стороны о результате доставки и обработки данных обеспечивается механизмом подтверждений информационных записей при помощи специальных подзаписей, содержащих идентификатор полученной/обработанной записи.
6.4 Идентификация принадлежности данных, используемых в протоколе уровня поддержки услуг
Для идентификации принадлежности записи тому или иному сервису используется идентификатор типа сервиса, который определяет функциональные особенности и характеристики обрабатываемых данных. Тип сервиса является его идентификатором при внутриплатформенной маршрутизации и уникальным в рамках ППУ.
6.5 Определение характеристик данных в протоколе уровня поддержки услуг
Данные в ППУ записываются в виде подзаписи, имеющей свой уникальный идентификатор в рамках отдельного типа сервиса, а также строго определенную структуру организации данных в зависимости от подзаписи. Использованием такой организации данных в ППУ достигается однозначное определение типа данных, их физического смысла, размера и способа упаковки.
6.6 Структуры данных, используемые в протоколе уровня поддержки услуг
6.6.1 Общая структура
Общая структура ППУ, которая входит в состав пакета ПТУ, может содержать одну или несколько записей, идущих одна за другой и имеющих различный состав данных, предназначенных разным сервисам. Общая структура данных представлена на рисунке 4.
6.6.2 Структура отдельной записи
6.6.2.1 Состав записи
Отдельная запись ППУ состоит из заголовка записи и данных записи. Состав отдельной записи представлен на рисунке 5.
В заголовке записи находятся параметры, определяющие типы сервисов получателя и отправителя, идентификатор записи, идентификатор объекта (например, УСВ), длину передаваемых данных, а также различные флаги, определяющие наличие опциональных параметров и способ обработки.
Данные записи могут содержать одну или несколько подзаписей, определяющих типы и содержащих передаваемые данные.
6.6.2.2 Структура записи
Структура отдельной записи уровня поддержки услуг приведена в таблице 15.
Таблица 15
Параметры отдельной записи ППУ, приведенные в таблице 15, имеют следующие назначения:
- RL - параметр определяет размер данных из поля RD;
- RN - номер записи. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535 следующее значение должно быть 0. Значение из данного поля используется для подтверждения записи;
- RFL - содержит битовые флаги, определяющие наличие в данном пакете полей OID, EVID и TM, характеризующих содержащиеся в записи данные;
- SSOD (Source Service On Device) - битовый флаг, определяющий расположение сервиса-отправителя:
а) 1 - сервис-отправитель расположен на стороне УСВ,
б) 0 - сервис-отправитель расположен на ТП;
- RSOD (Recipient Service On Device) - битовый флаг, определяющий расположение сервиса-получателя:
а) 1 - сервис-получатель расположен на стороне УСВ,
б) 0 - сервис-получатель расположен на ТП;
- RPP (Record Processing Priority) - битовое поле, определяющее приоритет обработки данной записи сервисом. Поле принимает десятичные значения от 0 (наивысший приоритет) до 7 (самый низкий приоритет);
- TMFE (Time Field Exists) - битовое поле, определяющее наличие в данном пакете поля TM:
а) 1 - поле TM присутствует,
б) 0 - поле TM отсутствует;
- EVFE (Event ID Field Exists) - битовое поле, определяющее наличие в данном пакете поля EVID:
а) 1 - поле EVID присутствует,
б) 0 - поле EVID отсутствует;
- OBFE (Object ID Field Exists) - битовое поле, определяющее наличие в данном пакете поля OID:
а) 1 - поле OID присутствует,
б) 0 - поле OID отсутствует;
- OID - идентификатор объекта, сгенерировавшего данную запись или для которого данная запись предназначена (уникальный идентификатор УСВ). В случае, если запись передается УСВ в ответ на команду от ТП, для индикации того, что данные принадлежат правильному объекту и сопоставлению запроса и ответа на стороне ТП, необходимо указать тот же OID, что был принят в команде. Алгоритм такого способа использования OID представлен на рисунке 6.
![]() - EVID - уникальный идентификатор события. Поле EVID задает глобальный идентификатор события и применяется, когда необходимо логически связать с одним-единственным событием набор нескольких информационных сущностей, причем сами сущности могут быть разнесены как по разным информационным пакетам, так и по времени. При этом прикладное программное обеспечение имеет возможность объединить все эти сущности воедино в момент представления пользователю информации о событии. Например, если с нажатием тревожной кнопки связывается серия фотоснимков, поле EVID должно указываться в каждой сервисной записи, связанной с этим событием на протяжении передачи всех сущностей, связанных с данным событием, как бы долго ни длилась передача всего пула информации;
- TM - время формирования записи на стороне отправителя (секунды с 00:00:00 01.01.2010 UTC). Если в одном пакете транспортного уровня передаются несколько записей, относящихся к одному объекту и моменту времени, то поле метки времени TM может передаваться только в составе первой записи;
- SST - идентификатор типа сервиса-отправителя, сгенерировавшего данную запись. Например, сервис, обрабатывающий навигационные данные на стороне УСВ, сервис команд на стороне ТП и т.д.;
- RST - идентификатор тип сервиса-получателя данной записи. Например, сервис, обрабатывающий навигационные данные на стороне ТП, сервис обработки команд на стороне УСВ и т.д.;
- RD - поле, содержащее информацию, присущую определенному типу сервиса (одну или несколько подзаписей сервиса типа, указанного в поле SST или RST, в зависимости от вида передаваемой информации).
6.6.3 Общая структура подзаписей
Формат отдельной подзаписи в ППУ приведен в таблице 16.
Таблица 16
6.6.4 На каждую информационную запись уровня поддержки услуг должно быть отправлено подтверждение, которое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки. Диаграмма, поясняющая работу механизма подтверждений при обмене сообщениями на уровне поддержки услуг, представлена на рисунке 7.
![]() Каждое сообщение ППУ содержит в себе заголовок и контрольную сумму транспортного уровня и одну или несколько записей уровня поддержки услуг. Причем в одном сообщении могут содержаться как информационные записи, так и подтверждения на ранее принятые записи.
6.7 Описание сервисов предоставления услуг
6.7.1 Список поддерживаемых ППУ сервисов предоставления услуг, их идентификаторы в десятичном виде, а также описание представлены в таблице 17.
Таблица 17
Код сервиса, указанный в таблице 17, приводится в заголовке записи ППУ (поля SST и RST).
Взаимодействие УСВ с сервером оператора национальной системы экстренного реагирования при авариях для получения ассистирующей информации, необходимой для расчета местоположения, осуществляется по протоколу SUPL, описание которого приведено в приложении Л.
Сервис EGTS_AUTH_SERVICE применяется для осуществления процедуры аутентификации УСВ на стороне ТП, а также получения учетных данных УСВ и информации об инфраструктуре на стороне УСВ (состав и версии программного обеспечения модулей, блоков, периферийного оборудования, информации о ТС). Сервис должен использоваться УСВ только в случае работы по протоколу TCP/IP после создания каждого нового соединения с ТП.
Требования данного пункта стандарта распространяются только на УСВ, исполненные в конфигурации дополнительного оборудования, и не распространяются на штатные УСВ, которые поддерживают только базовую услугу реагирования при аварии.
Список подзаписей, используемых сервисом EGTS_AUTH_SERVICE, представлен в таблице 18.
Таблица 18
Структура подзаписи приведена в таблице 19.
Таблица 19
Поля подзаписи EGTS_SR_RECORD_RESPONSE имеют следующие назначения:
- CRN - номер подтверждаемой записи (значение поля RN из обрабатываемой записи);
- RST - статус обработки записи. Коды результатов обработки приведены в приложении В.
При получении подтверждения отправителем он анализирует поле RST подзаписи EGTS_SR_RECORD_RESPONSE и в случае получения статуса об успешной обработке стирает запись из внутреннего хранилища, иначе в случае ошибки и в зависимости от причины производит соответствующие действия.
Рекомендуется совмещать подтверждение транспортного уровня (тип пакета EGTS_PT_RESPONSE) с подзаписями - подтверждениями уровня поддержки услуг EGTS_SR_RECORD_RESPONSE.
6.7.2.2 Подзапись EGTS_SR_TERM_IDENTITY
Структура подзаписи приведена в таблице 20.
Таблица 20
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_TERM_IDENTITY имеют следующие назначения:
- TID - уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных АС (IMSI, IMEI, serial_id). В случае использования УСВ в качестве штатного устройства TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);
- HDIDE (Home Dispatcher Identifier Enable) - битовый флаг, который определяет наличие поля HDID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- IMEIE (International Mobile Equipment Identity Enable) - битовый флаг, который определяет наличие поля IMEI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- IMSIE (International Mobile Subscriber Identity Enable) - битовый флаг, который определяет наличие поля IMSI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- LNGCE (Language Code Enable) - битовый флаг, который определяет наличие поля LNGC в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- SSRA - битовый флаг предназначен для определения алгоритма использования сервисов (если бит равен 1, то используется "простой" алгоритм, если 0, то алгоритм "запросов" на использование сервисов);
- NIDE (Network Identifier Enable) - битовый флаг определяет наличие поля NID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- BSE (Buffer Size Enable) - битовый флаг, определяющий наличие поля BS в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- MNE (Mobile Number Enable) - битовый флаг, определяющий наличие поля MSISDN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- HDID - идентификатор "домашней" ТП (подробная учетная информация об УСВ хранится на данной платформе);
- IMEI - идентификатор мобильного устройства (модема). При невозможности определения данного параметра УСВ должна заполнять данное поле значением 0 во всех 15 символах;
- IMSI - идентификатор мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 16 символах;
- LNGC - код языка, предпочтительного к использованию на стороне УСВ, например "rus" - русский;
- NID - идентификатор сети оператора, в которой зарегистрирована УСВ. Используются 20 младших бит. Представляет пару кодов MCC-MNC. Структура поля NID представлена в таблице 21;
- BS - максимальный размер буфера приема УСВ в байтах. Размер каждого пакета информации, передаваемого на УСВ, не должен превышать данного значения. Значение поля BS может принимать различные значения (1024, 2048, 4096) и зависит от реализации аппаратной и программной частей конкретной УСВ;
- MSISDN - телефонный номер мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 15 символах (формат описан в национальных планах нумерации, утверждаемых соответствующими нормативными правовыми актами <1>).
--------------------------------
<1> В Российской Федерации "Российская система и план нумерации" утверждены приказом Министерства связи и массовых коммуникаций Российской Федерации от 25 апреля 2017 г. N 205.
- SSLPV - Номер версии протокола уровня поддержки услуг (номер версии протокола EGTS). Версия протокола уровня поддержки услуг (номер версии протокола EGTS) состоит из двух символов, левый символ "0" для версий от 1 до 9, "01" ... "09" соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.
Таблица 21
сервиса EGTS_AUTH_SERVICE
Параметры поля NID подзаписи EGTS_SR_TERM_IDENTITY имеют следующие назначения:
- MCC - код страны;
- MNC - код мобильной сети в пределах страны.
Расширение функциональности при взаимодействии УСВ и ТП, а также при взаимодействии между ТП реализовано посредством включения в протокол дополнительных команд и сервисов в целях стандартизации актуализируемых версий в виде увеличения номера версии протокола.
Стандарт описывает взаимодействие с помощью протокола версии "02", а также стратегию использования УСВ и ТП, поддерживающих взаимодействие с помощью протокола "02" с учетом совместимости их с УСВ и ТП, работающих с использованием протокола "01". Для этих целей в данном стандарте описаны также:
- взаимодействие с использованием протокола версии "01";
- условия и алгоритмы аутентификации и авторизации, позволяющие реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий.
Условия и алгоритмы аутентификации и авторизации, позволяющие реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий, приведены в разделе 6.1.3.
Передача поля HDID определяется настройками УСВ и целесообразна при возможности подключении УСВ к ТП, отличной от "домашней", например при использовании территориально распределенной сети платформ. При использовании только одной "домашней" платформы передача HDID не требуется.
"Простой" алгоритм использования сервисов подразумевает, что для УСВ доступны все сервисы и в таком режиме УСВ разрешено сразу отправлять данные для требуемого сервиса. В зависимости от действующих на ТП для данного УСВ разрешений в ответ на пакет с данными для сервиса может быть возвращена запись-подтверждение с соответствующим признаком ошибки. В системах с простым распределением прав на использование сервисов рекомендуется применять простой алгоритм. Это сокращает объем передаваемого трафика и время авторизации УСВ.
Алгоритм "запросов" на использование сервисов подразумевает, что перед тем, как использовать тот или иной тип сервиса (отправлять данные), УСВ должна получить от ТП информацию о доступных для использования сервисов. Запрос на использование сервисов может осуществляться как на этапе авторизации, так и после нее. На этапе авторизации запрос на использование того или иного сервиса производится путем добавления подзаписей типа SR_SERVICE_INFO и установки бита 7 поля SRVP в значение 1. После процедуры авторизации запрос на использование сервиса может быть осуществлен также при помощи подзаписей SR_SERVICE_INFO.
Совокупность MCC и MNC определяет уникальный идентификатор оператора сетей ПРТС стандартов GSM, CDMA, TETRA, UMTS, а также некоторых операторов спутниковой связи.
6.7.2.3 Подзапись EGTS_SR_MODULE_DATA
Структура подзаписи представлена в таблице 22.
Таблица 22
сервиса EGTS_AUTH_SERVICE
Поля подзаписи SR_MODULE_DATA имеют следующие значения:
- MT - тип модуля, определяет функциональную принадлежность модуля (1 - основной модуль; 2 - модуль ввода вывода; 3 - модуль навигационного приемника; 4 - модуль беспроводной связи). Здесь указаны рекомендованные правила нумерации типов модулей. Конкретная реализация сервиса авторизации может вводить и расширять собственную нумерацию типов, включая все внешние периферийные контроллеры;
- VID - код производителя;
- FWV - версия аппаратной части модуля (старший байт - число до точки - major version, младший - после точки - minor version, например версия 2.34 будет представлена числом 0x0222);
- SWV - версия программной части модуля (старший байт - число до точки, младший - после точки);
- MD - код модификации программной части модуля;
- ST - состояние [1 - включен, 0 - выключен, больше 127 - неисправность (см. приложение В)];
- SRN - серийный номер модуля;
- D - разделитель строковых параметров (всегда имеет значение 0);
- DSCR - краткое описание модуля.
6.7.2.4 Подзапись EGTS_SR_VEHICLE_DATA
Структура подзаписи представлена в таблице 23. Данная подзапись должна передаваться совместно с EGTS_SR_TERM_IDENTITY.
Таблица 23
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_VEHICLE_DATA имеют следующие значения:
- VIN - идентификационный номер ТС. Передается в двух полях VINL - последние 17 знаков, VINH - оставшаяся часть;
- VHT - тип ТС:
1 - пассажирский (M1),
2 - автобус (M2),
3 - автобус (M3),
4 - легкая грузовая машина (N1),
5 - тяжелая грузовая машина (N2),
6 - тяжелая грузовая машина (N3),
7 - мотоцикл (L1e),
8 - мотоцикл (L2e),
9 - мотоцикл (L3e),
10 - мотоцикл (L4e),
11 - мотоцикл (L5e),
12 - мотоцикл (L6e),
13 - мотоцикл (L7e),
20 - маломерное судно некоммерческого использования,
21 - маломерное судно коммерческого использования,
22 - 64 - зарезервировано для судов иных типов;
- VPST - тип энергоносителя ТС. Может быть установлено более одного бита, если установлены носители нескольких типов. Если все биты 0, то тип не задан:
а) бит 31-6 не используется,
б) бит 5:1 - водород,
в) бит 4:1 - электричество,
г) бит 3:1 - жидкий пропан (LPG),
д) бит 2:1 - сжиженный природный газ (CNG),
е) бит 1:1 - дизель,
ж) бит 0:1 - бензин.
6.7.2.5 Подзапись EGTS_SR_AUTH_PARAMS
Структура подзаписи представлена в таблице 24.
Таблица 24
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_AUTH_PARAMS имеют следующие значения:
- EXE (Exp Enable) - битовый флаг, определяет наличие поля EXP и следующего за ним разделителя D (если 1, то поля присутствуют);
- SSE (Server Sequence Enable) - битовый флаг, определяет наличие поля SS и следующего за ним разделителя D (если 1, то поля присутствуют);
- MSE (Mod Size Enable) - битовый флаг, определяет наличие поля MSZ (если 1, то поле присутствует);
- ISLE (Identity String Length Enable) - битовый флаг, определяет наличие поля ISL (если 1, то поле присутствует);
- PKE (Public Key Enable) - битовый флаг, определяет наличие полей PKL и PBK (если 1, то поля присутствуют);
- ENA (Encryption Algorithm) - битовое поле, определяющее требуемый алгоритм шифрования пакетов. Если данное поле содержит значение 00, то шифрование не применяется, и подзапись EGTS_SR_AUTH_PARAMS содержит только один байт, т.е. в зависимости от типа алгоритма наличие дополнительных параметров определяется остальными битами поля FLG;
- PKL - длина публичного ключа в байтах;
- PBK - данные публичного ключа;
- ISL - результирующая длина идентификационных данных;
- MSZ - параметр, применяемый в процессе шифрования;
- SS - специальная серверная последовательность байтов, применяемая в процессе шифрования;
- D - разделитель строковых параметров (всегда имеет значение 0);
- EXP - специальная последовательность, используемая в процессе шифрования.
Если требуется использование шифрования и запрашиваемый алгоритм шифрования поддерживается, авторизуемой стороной производится формирование и отправка записи EGTS_SR_AUTH_INFO, зашифрованной по указанному алгоритму. При этом биты 11 и 12 в поле KEYS заголовка транспортного уровня устанавливаются в соответствующие значения, и весь последующий обмен данными производится с использованием шифрования.
Если требуемый алгоритм шифрования не поддерживается, инициирующая сторона отправляет подзапись EGTS_SR_RECORD_RESPONSE с соответствующим признаком ошибки.
В записи, в зависимости от используемого алгоритма запроса сервисов, также могут содержаться подзаписи EGTS_SR_SERVICE_INFO, определяющие число и параметры поддерживаемых, а также требуемых инициирующей стороной сервисов.
6.7.2.6 Подзапись EGTS_SR_AUTH_INFO
Структура подзаписи представлена в таблице 25.
Таблица 25
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_AUTH_INFO имеют следующие значения:
- UNM - имя пользователя;
- D - разделитель строковых параметров (всегда имеет значение 0);
- UPSW - пароль пользователя;
- SS - специальная серверная последовательность байтов, передаваемая в подзаписи EGTS_SR_AUTH_PARAMS (необязательное поле, наличие зависит от используемого алгоритма шифрования).
6.7.2.7 Подзапись EGTS_SR_SERVICE_INFO
Структура подзаписи представлена в таблице 26.
Таблица 26
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_SERVICE_INFO имеют следующие значения:
- ST - тип сервиса, определяет функциональную принадлежность (например, EGTS_TELEDATA_SERVICE, EGTS_ECALL_SERVICE и т.д.);
- SST - определяет текущее состояние сервиса (см. таблицу 27);
- SRVP - определяет параметры сервиса;
- SRVA (Service Attribute) - битовый флаг, атрибут сервиса:
а) 0 - поддерживаемый сервис,
б) 1 - запрашиваемый сервис;
- SRVRP (Service Routing Priority) - битовое поле, приоритет с точки зрения трансляции на него данных (в случае масштабирования системы и применения нескольких экземпляров приложений одного типа сервиса) определяется битами 0 и 1:
а) 00 - наивысший,
б) 01 - высокий,
в) 10 - средний,
г) 11 - низкий.
Таблица 27
6.7.2.8 Подзапись EGTS_SR_RESULT_CODE
Структура подзаписи представлена в таблице 28.
Таблица 28
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_RESULT_CODE имеют следующее значение:
- RCD - код, определяющий результат выполнения операции авторизации.
6.7.2.9 Описание процедуры авторизации
Для работы УСВ в инфраструктуре оператора системы УСВ должен быть назначен уникальный идентификатор UNIT_ID, которому соответствуют определенные значения IMEI, IMSI и другие учетные данные УСВ, необходимые для осуществления взаимодействия с оператором системы.
Требование настоящего пункта не распространяется на штатные УСВ, которые поддерживают только базовую услугу реагирования при аварии. В конфигурации штатного оборудования сервис EGTS_AUTH_SERVICE не используется. В этом случае сообщения сервиса EGTS_ECALL_SERVICE могут отправляться сразу. EGTS_AUTH_SERVICE задействуется в случае использования СПРС и подключения к серверу по TCP/IP.
Конфигурирование УСВ может быть произведено одним из следующих способов.
1) В пассивном режиме работы УСВ после нажатия кнопки "Дополнительные функции" и осуществления регистрации УСВ в сети СПРС инфраструктура сотового оператора отслеживает появление нового устройства и инициирует отправку ему SMS с учетными данными. Учетные данные передаются путем установки параметров УСВ при помощи подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE.
Должны быть установлены следующие параметры УСВ: параметр EGTS_GPRS_APN (параметр точки доступа для установления СПРС-сессии), параметр EGTS_SERVER_ADDRESS, определяющий адрес и порт сервера, с которым необходимо установить TCP/IP-соединение, уникальный идентификатор УСВ UNIT_ID.
В случае установки параметров для УСВ, работающего по протоколу версии "02", может быть установлен параметр EGTS_PROTOCOL_CHOICE с массивом данных, определяющих перечень серверов ТП.
В массиве данных параметра EGTS_PROTOCOL_CHOICE будут переданы для каждой принимающей ТП:
- IPv4 адрес и порт для установки TCP/IP-соединения;
- вариант процедуры выбора версии протокола обмена данными:
0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола ("01") заканчивая старшей версией протокола ("02") согласно процедурам и принципам, описанным в 6.1.3,
1 - УСВ использует для обмена данными с указанной ТП версию протокола "01",
2 - УСВ использует для обмена данными с указанной ТП версию протокола "02".
Далее УСВ производит разбор SMS-сообщения, проверяет корректность структур данных, вычисляет и сравнивает с полученными в сообщении значениями контрольные суммы. Если разбор и проверка прошли успешно, УСВ устанавливает СПРС-сессию и соединяется с указанным сервером по TCP/IP. Алгоритм такого способа конфигурирования УСВ представлен на рисунке 8.
![]() Алгоритм конфигурирования для УСВ, работающих по протоколу версии "02" с дополнительными параметрами выбора версии протокола, представлен на рисунке 9.
![]() --------------------------------
<*> Массив данных 1 - массив данных, определяющих перечень серверов телематических платформ, с которыми необходимо установить TCP/IP-соединение. В массиве данных передаются для каждой ТП: IPv4 адрес и порт для установки TCP/IP-соединения; вариант процедуры выбора версии протокола обмена данными
с передачей параметров выбора протокола с использованием SMS
2) После регистрации УСВ в сети GSM или UMTS устанавливаются СПРС-сессия и TCP/IP-соединение с сервером, информация об адресе которого уже записана в памяти УСВ. При прохождении процедуры аутентификации инфраструктура оператора анализирует параметр TID из подзаписи EGTS_SR_TERM_IDENTITY (таблица 18). Если TID имеет значение 0, производится процедура конфигурирования путем установки параметров УСВ при помощи подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE с использованием SMS, как описано в предыдущем способе.
После процедуры установки параметра УСВ EGTS_UNIT_ID ей отправляется результат авторизации с кодом EGTS_PC_ID_NFOUND, указывающий, что TID=0 в системе не найден. После этого сервер, не разрывая соединения с УСВ, ожидает повторной авторизации УСВ, но уже с корректным параметром TID. Алгоритм такого способа конфигурирования УСВ представлен на рисунке 10.
![]() Если авторизация прошла успешно, ТП, в зависимости от алгоритма запроса использования сервисов, может перед подзаписью EGTS_SR_RESULT_CODE добавлять подзаписи типа EGTS_SR_SERVICE_INFO, определяющие состав сервисов, разрешенных для УСВ и поддерживаемых платформой.
Это означает, что УСВ сразу после авторизации может использовать только перечисленные сервисы, даже если она предполагает "простой" алгоритм поддержи прав использования сервисов.
Если используется алгоритм "запросов" использования сервисов, то УСВ не может использовать сервисы, разрешение на использование которых не получено со стороны ТП. Причем разрешение на некоторые запрашиваемые сервисы может прийти позже. Например, когда сервисы находятся на удаленных ТП, от которых в асинхронном режиме приходят ответы на запросы. В таком случае ТП, используя имеющиеся данные маршрутизации, отправляет асинхронный запрос на использование сервисов удаленной платформы, если идентификатор HDID указан в подзаписи EGTS_SR_TERM_IDENTITY при авторизации УСВ.
Алгоритм выбора версии протокола при авторизации УСВ на стороне ТП представлен на диаграмме, приведенной на рисунке 11. Принципы выбора протокола приведены в 6.1.3.
![]() при авторизации УСВ на стороне ТП
Алгоритм обмена сообщениями на этапе авторизации УСВ на стороне ТП представлен на диаграмме, приведенной на рисунке 12.
![]() на этапе авторизации УСВ на ТП
После успешного подключения УСВ к ТП по протоколу TCP/IP УСВ должна быть авторизована. Для передачи первичных аутентификационных данных УСВ должна отправить сообщение, содержащее подзапись EGTS_SR_TERM_IDENTITY (сообщение 1) в течение времени EGTS_SL_NOT_AUTH_TO.
Получив сообщение с подзаписью EGTS_SR_TERM_IDENTITY, ТП отправляет на него сообщение 2 с подтверждением о приеме EGTS_SR_RECORD_RESPONSE на запись с идентификатором ID, равным 1. Далее в зависимости от настроек (используется шифрование или дополнительный алгоритм авторизации) ТП отправляет пакет (сообщение 3) с подзаписью EGTS_SR_AUTH_PARAM, содержащей параметры, необходимые для осуществления шифрования и/или алгоритма расширенной авторизации. Если шифрование и алгоритм расширенной авторизации не используются, то вместо подзаписи EGTS_SR_AUTH_PARAM ТП может отправить подзапись EGTS_SR_RESULT_CODE с результатом проведения процедуры авторизации УСВ.
Далее УСВ отправляет сообщение 4 и подтверждение EGTS_SR_RECORD_RESPONSE на сообщение 3 с ID, равным 2. При использовании расширенного алгоритма авторизации и/или шифрования УСВ передает сообщение 5, закодированное по правилам шифрования, указанным в сообщении 3 от ТП и содержащее подзапись EGTS_SR_AUTH_INFO с данными для расширенной авторизации.
После получения EGTS_SR_AUTH_INFO ТП отправляет сообщение 6 с подтверждением на сообщение 5 с ID, равным 3, и выполняет процедуру авторизации. Платформа формирует сообщение 7 с результатом проведения авторизации в виде подзаписи EGTS_SR_RESULT_CODE, а также в случае успешной авторизации может добавить информацию о разрешенных для использования данной УСВ-услуги в виде подзаписей EGTS_SR_SERVICE_INFO.
УСВ затем формирует сообщение 8 с подтверждением на сообщение 7 с ID, равным 4. УСВ может сформировать сообщение 9 и добавить подзаписи EGTS_SR_SERVICE_INFO, содержащие информацию о требуемых услугах (если используется процедура использования сервисов "по запросу") и/или поддерживаемых сервисах на стороне УСВ.
Далее ТП создает сообщение 10 с подтверждением на сообщение 9 с ID, равным 5.
На этом этап авторизации заканчивается, и УСВ переходит на этап обмена информационными сообщениями с платформой согласно установленному в УСВ режиму работы.
Если процедура авторизации проходит неудачно (неверные аутентификационные данные УСВ, запрет доступа данного УСВ к ТП и т.д.), то после отправки сообщения, содержащего подзапись EGTS_SR_RESULT_CODE с указанием в ней соответствующего кода, ТП должна разорвать установленное автомобильной системой TCP/IP-соединение.
Процедура выбора версии протокола для обмена данными на этапе авторизации УСВ на ТП приведена в 6.1.3.
6.7.2.10 Описание процедуры авторизации (при использовании функций мониторинга ТС)
При использовании УСВ функций мониторинга процедура авторизации должна осуществляться в соответствии с требованиями, приведенными в ГОСТ 33472-2023 (раздел В.3.2.3).
6.7.2.11 Подзапись EGTS_SR_DISPATCHER_IDENTITY
Формат подзаписи EGTS_SR_DISPATCHER_IDENTITY сервиса EGTS_AUTH_SERVICE представлен в таблице 29.
Таблица 29
сервиса EGTS_AUTH_SERVICE
Поля подзаписи EGTS_SR_DISPATCHER_IDENTITY:
- DT - тип диспетчера;
- DID - уникальный идентификатор диспетчера;
- DSCR - краткое описание;
- TID - уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных АС (IMSI, IMEI, serial_id). В случае использования УСВ в качестве штатного устройства TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);
- SSLPV - номер версии ППУ авторизуемого УСВ (номер версии протокола EGTS). Версия ППУ (номер версии протокола EGTS) состоит из двух символов, левый символ "0" для версий от 1 до 9, "01" ... "09" соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.
Расширение функциональности при взаимодействии УСВ и ТП, а также при взаимодействии между ТП, реализовано посредством включения в протокол дополнительных команд и сервисов в целях стандартизации актуализируемых версий в виде увеличения номера версии протокола.
Данная редакция стандарта описывает взаимодействие с помощью протокола версии "02", а также стратегию использования УСВ и ТП, поддерживающих взаимодействие с помощью протокола "02", с учетом совместимости их с УСВ и ТП, работающими с использованием протокола "01". Для этих целей в данном стандарте описаны также:
- взаимодействие с использованием протокола версии "01";
- условия и алгоритмы аутентификации и авторизации, позволяющих реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий.
Условия и алгоритмы аутентификации и авторизации, позволяющих реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий, приведены в разделе 6.1.3.
6.7.2.12 Подзапись EGTS_SR_VEHICLE_DATA_ADD
Структура подзаписи представлена в таблице 30. Данная подзапись должна передаваться совместно с EGTS_SR_TERM_IDENTITY.
Таблица 30
сервиса EGTS_AUTH_SERVICE
- VME (Vehicle Model Enable) - битовый флаг, который определяет наличие поля VM в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- VBE (Vehicle Brand Enable) - битовый флаг, который определяет наличие поля VB в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- VTE (Vehicle Taxpayer Enable) - битовый флаг, который определяет наличие поля VOTIN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- VPE (Vehicle Primary Enable) - битовый флаг, который определяет наличие поля VOPSRN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- VNE (Vehicle Name Enable) - битовый флаг, который определяет наличие поля VON в подзаписи (если бит равен 1, то поле передается, если 0, то не передается).
Поля подзаписи EGTS_SR_VEHICLE_DATA_ADD имеют следующие значения:
- VSRM - государственный регистрационный знак (номер) ТС;
- VM - модель ТС;
- VB - марка ТС;
- VOTIN - ИНН собственника ТС;
- VOPSRN - ОГРН собственника ТС;
- VON - наименование организации - собственника ТС.
Данный тип сервиса предназначен для обработки команд, сообщений и подтверждений, передаваемых между УСВ, ТП и клиентскими приложениями.
Для осуществления взаимодействия в рамках данного сервиса используется одна подзапись EGTS_SR_COMMAND_DATA, описание и код которой представлены в таблице 31.
Таблица 31
6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA
Структура подзаписи представлена в таблице 32.
Таблица 32
сервиса EGTS_COMMANDS_SERVICE
Приведенные в таблице 32 параметры (поля) подзаписи EGTS_SR_COMMAND_DATA имеют следующие назначения:
- CT - тип команды:
а) 0001 - CT_COMCONF - подтверждение о приеме, обработке или результат выполнения команды,
б) 0010 - CT_MSGCONF - подтверждение о приеме, отображении и/или обработке информационного сообщения,
в) 0011 - CT_MSGFROM - информационное сообщение от УСВ,
г) 0100 - CT_MSGTO - информационное сообщение для вывода на устройство отображения ТС,
д) 0101 - CT_COM - команда для выполнения на ТС,
е) 0110 - CT_DELCOM - удаление из очереди на выполнение переданной ранее команды,
ж) 0111 - CT_SUBREQ - дополнительный подзапрос для выполнения (к переданной ранее команде),
и) 1000 - CT_DELIV - подтверждение о доставке команды или информационного сообщения;
- CCT - тип подтверждения (имеет смысл для типов команд CT_COMCONF, CT_MSGCONF, CT_DELIV):
а) 0000 - CC_OK - успешное выполнение, положительный ответ,
б) 0001 - CC_ERROR - обработка завершилась ошибкой,
в) 0010 - CC_ILL - команда не может быть выполнена по причине отсутствия в списке разрешенных (определенных протоколом) команд или отсутствия разрешения на выполнение данной команды,
г) 0011 - CC_DEL - команда успешно удалена,
д) 0100 - CC_NFOUND - команда для удаления не найдена,
е) 0101 - CC_NCONF - успешное выполнение, отрицательный ответ,
ж) 0110 - CC_INPROG - команда передана на обработку, но для ее выполнения требуется длительное время (результат выполнения еще не известен);
- CID - идентификатор команды, сообщения. Значение из данного поля должно быть использовано стороной, обрабатывающей/выполняющей команду или сообщение, для создания подтверждения. Подтверждение должно содержать в поле CID то же значение, что содержалось в самой команде или сообщении при отправке;
- SID - идентификатор отправителя данной команды или подтверждения. В случае передачи от УСВ на ТП подтверждения на команду или результат выполнения команды (тип команды CT_COMCONF, CT_MSGCONF, CT_DELIV) необходимо копировать значение данного поля из ранее пришедшей на УСВ команды. При инициации отправки подзаписи EGTS_SR_COMMAND_DATA на стороне УСВ данное поле имеет значение 0;
- ACFE (Authorization Code Field Exists) - битовый флаг, определяющий наличие полей ACL и AC в подзаписи:
а) 1 - поля ACL и AC присутствуют в подзаписи,
б) 0 - поля ACL и AC отсутствуют в подзаписи;
- CHSFE (Charset Field Exists) - битовый флаг, определяющий наличие поля CHS в подзаписи:
а) 1 - поле CHS присутствует в подзаписи,
б) 0 - поле CHS отсутствует в подзаписи;
- CHS - кодировка символов, используемая в поле CD, содержащем тело команды. При отсутствии данного поля по умолчанию должна использоваться кодировка CP-1251. Определены следующие значения поля CHS (десятичный вид):
а) 0 - CP-1251,
б) 1 - IA5 (CCITT T.50)/ASCII (ANSI X3.4),
в) 2 - бинарные данные,
г) 3 - Latin 1 (рисунок Е.1),
д) 4 - бинарные данные,
е) 5 - JIS (X 0208-1990),
ж) 6 - Cyrillic (рисунок Е.2),
и) 7 - Latin/Hebrew (рисунок Е.3),
к) 8 - UCS2;
- ACL - длина в байтах поля AC, содержащего код авторизации на стороне получателя;
- AC - код авторизации, использующийся на принимающей стороне (автомобильная система), который обеспечивает ограничение доступа на выполнение отдельных команд. Если указанный в данном поле код не совпадает с ожидаемым значением, то в ответ на такую команду или сообщение AC должна отправить подтверждение с типом CC_ILL. Установка кода авторизации на стороне AC производится при помощи команды EGTS_SET_AUTH_CODE;
- CD - тело команды, параметры, данные, возвращаемые на команду-запрос, использующие кодировку из поля CHS или значение по умолчанию.
Размер данного поля определяется исходя из общей длины записи ППУ и длины предшествующих полей в данной подзаписи. Формат команды представлен в таблице 33. Данное поле может иметь нулевую длину (отсутствовать) в тех случаях, когда в ответ на команду или сообщение для УСВ не передаются никакие данные.
Таблица 33
Приведенные в таблице 33 параметры имеют следующие назначения:
- ADR - адрес модуля, для которого данная команда предназначена. Адрес определяется исходя из начальной конфигурации УСВ или из списка модулей, который может быть получен при регистрации УСВ через сервис EGTS_AUTH_SERVICE и передачи подзаписей EGTS_SR_MODULE_DATA;
- SZ - объем памяти для параметра (используется совместно с действием ACT-2). При добавлении нового параметра в УСВ данное поле определяет, что для нового параметра требуется 2SZ байт памяти в УСВ;
- ACT - описание действия, используется в случае типа команды, поле CT-CT_COM подзаписи EGTS_SR_COMMAND_DATA. Значение поля может быть одним из следующих вариантов:
а) 0 - параметры команды. Используется для передачи параметров для команды, определяемой кодом из поля CCD,
б) 1 - запрос значения. Используется для запроса информации, хранящейся в УСВ. Запрашиваемый параметр определяется кодом из поля CCD,
в) 2 - установка значения. Используется для установки нового значения определенному параметру в УСВ. Устанавливаемый параметр определяется кодом из поля CCD, а его значение - полем DT,
г) 3 - добавление нового параметра в УСВ. Код нового параметра указывается в поле CCD, его тип - в поле SZ, а значение - в поле DT,
д) 4 - удаление имеющегося параметра из УСВ. Код удаляемого параметра указывается в поле CCD;
- CCD - код команды при ACT-0 или параметра при ACT-1...4;
- DT - запрашиваемые данные или параметры, необходимые для выполнения команды. Данные записываются в данное поле в формате, зависящем от типа команды.
Подтверждение на ранее переданную команду при CT-CT_COMCONF, если с УСВ передается сопутствующая информация, имеет формат, представленный в таблице 34. Описанная структура содержится в поле CD.
Таблица 34
Приведенные в таблице 34 параметры имеют следующие назначения:
- ADR - адрес модуля, для которого данная команда предназначена. Адрес определяется исходя из начальной конфигурации УСВ или из списка модулей, который может быть получен при регистрации УСВ через сервис EGTS_AUTH_SERVICE и передаче подзаписей EGTS_SR_MODULE_DATA. В командах от оператора системы EGTS_ECALL_REQ, EGTS_ECALL_MSD_REQ поле ADR всегда должно иметь значение 0;
- CCD - код команды, сообщения из таблицы 35 или параметра из таблицы 37, в соответствии с которым передается сопутствующая информация в поле DT;
- DT - сопутствующие данные, тип и состав которых определяются значением поля CCD. Список и состав сопутствующих данных, передаваемых в подтверждении на некоторые команды, представлены в таблице 36.
Список и описание команд для УСВ представлены в таблице 35, список подтверждений на команды и сообщения от УСВ - в таблице 36; список параметров УСВ - в таблице 37.
Таблица 35
Таблица 36
Таблица 37
Таблица 38
Пример заполнения массива параметров процедуры выбора
версии протокола обмена данными EGTS_PROTOCOL_CHOICE
Значения следующих параметров УСВ могут быть запрошены, но не могут быть изменены или удалены при помощи сервиса команд:
- EGTS_UNIT_SERIAL_NUMBER,
- EGTS_UNIT_HW_VERSION;
- EGTS_UNIT_SW_VERSION;
- EGTS_UNIT_VENDOR_ID;
- EGTS_INIT_IMEI.
Значения указанных параметров выставляются производителями соответствующих модулей и блоков УСВ, а также разработчиками ПО для них.
УСВ, установленными в конфигурации штатного оборудования, должна быть реализована поддержка следующих параметров:
- EGTS_GPRS_APN;
- EGTS_SERVER_ADDRESS;
- EGTS_PROTOCOL_CHOICE;
- EGTS_READY_PROFILE;
- EGTS_SIM_PIN;
- EGTS_AUTOMATIC_REGISTRATION;
- EGTS_TEST_MODE_END_DISTANCE;
- EGTS_GARAGE_MODE_END_DISTANCE;
- EGTS_TEST_REGISTRATION_PERIOD;
- EGTS_GNSS_POWER_OFF_TIME;
- EGTS_GNSS_DATA_RATE;
- EGTS_GNSS_MIN_ELEVATION;
- EGTS_UNIT_ID;
- EGTS_UNIT_IMEI;
- EGTS_UNIT_HOME_DISPATCHER_ID;
- EGTS_INT_MEM_TRANSMIT_INTERVAL;
- EGTS_INT_MEM_TRANSMIT_ATTEMPTS;
- EGTS_SELFTEST_INTERVAL;
- EGTS_POST_TEST_REGISTRATION_TIME;
- EGTS_TEST_REGISTRATION_TIMEOUT;
- EGTS_TEST_MODE_WATCHDOG;
- EGTS_USE_GPRS_WHITE_LIST;
- EGTS_UNIT_ANGUAGE_ID.
6.7.3.3 Примеры процедур передачи команд приведены на рисунках 13 и 14.
![]() ![]() Сервис EGTS_FIRMWARE_SERVICE предназначен для передачи на УСВ конфигурации и обновления программного обеспечения аппаратной части модулей и блоков самой УСВ, а также периферийного оборудования, подключенного к УСВ.
Для осуществления взаимодействия в рамках данного сервиса используется несколько подзаписей, описание и код которых представлены в таблице 39.
Таблица 39
6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA
Подзапись EGTS_SR_SERVICE_PART_DATA может использоваться сервисом для передачи сущностей на УСВ. Структура подзаписи представлена в таблице 40.
Таблица 40
сервиса EGTS_FIRMWARE_SERVICE
Параметр EPQ содержит число частей, которое будет передано, а параметр PN - номер текущей части. Поле ID однозначно определяет сущность, которой принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть не более значения из поля EPQ. Если данное условие нарушается, то данные из такой подзаписи игнорируются.
Идентификатор объекта ID, поля PN и EPQ, а также идентификатор источника записи OID из заголовка уровня маршрутизации сервисов позволяют определить, какая часть и какого объекта получена для обработки. Это позволяет при достаточной пропускной способности канала одновременно передавать сущности для обновления программного обеспечения различных аппаратных частей УСВ и периферийного оборудования. Формат заголовка передаваемой сущности подзаписи представлен в таблице 41.
Таблица 41
EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE
В таблице 41 параметры (поля) имеют следующие назначения:
- OA - характеристика принадлежности передаваемой сущности;
- OT - тип сущности по содержанию. Определены следующие значения данного поля:
а) 00 - данные внутреннего программного обеспечения ("прошивка"),
б) 01 - блок конфигурационных параметров;
- MT - тип модуля, для которого предназначена передаваемая сущность. Определены следующие значения данного поля:
а) 00 - периферийное оборудование,
б) 01 - УСВ.
- CMI - номер компонента в случае принадлежности сущности непосредственно УСВ или идентификатор периферийного модуля/порта, подключенного к УСВ, в зависимости от значения параметра MT;
- VER - версия передаваемой сущности (старший байт - число до точки major version, младший - после точки minor version, например версия 2.34 будет представлена числом 0x0222);
- WOS - сигнатура (контрольная сумма) всей передаваемой сущности. Используется алгоритм CRC16-CCITT;
- FN - имя файла передаваемой сущности (данное поле опционально и может иметь нулевую длину);
- D - разделитель строковых параметров (всегда имеет значение 0).
6.7.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA
Структура подзаписи представлена в таблице 42.
Таблица 42
сервиса EGTS_FIRMWARE_SERVICE
В таблице 42 параметры (поля) имеют следующие назначения:
- ODH - заголовок, содержащий параметры, характеризующие передаваемую сущность. Для подзаписи EGTS_SR_SERVICE_FULL_DATA параметр ODH является обязательным и присутствует в каждой такой подзаписи;
- OD - данные непосредственно передаваемой сущности.
6.7.4.3 Подзапись EGTS_SR_RECORD_RESPONSE
Данная подзапись имеет такую же структуру, как описано в 6.7.2.1, и применяется для подтверждения получения и обработки подзаписей EGTS_SR_SERVICE_PART_DATA и EGTS_SR_SERVICE_FULL_DATA. При этом на все подзаписи EGTS_SR_SERVICE_PART_DATA, кроме последней, при успешной обработке в составе EGTS_SR_RECORD_RESPONSE должен передаваться код результата, равный EGTS_PC_IN_PROGRESS. На последнюю подзапись EGTS_SR_SERVICE_PART_DATA и каждую EGTS_SR_SERVICE_FULL_DATA при успешном приеме и обработке со стороны УСВ должна передаваться подзапись EGTS_SR_RECORD_RESPONSE, содержащая код EGTS_PC_OK, что будет воспринято сервисом как удачная попытка отправки всей сущности.
6.8 Временные и количественные параметры протокола уровня поддержки услуг при использовании пакетной передачи данных
Описание временных и количественных параметров протокола уровня поддержки услуг представлено в таблице 43.
Таблица 43
уровня поддержки услуг
7.1 Назначение сервиса экстренного реагирования при аварии
Сервис экстренного реагирования предназначен для обеспечения возможности реализации системой функционала по оказанию базовой услуги, предоставляемой системой. В ППУ этот сервис определен как EGTS_ECALL_SERVICE и имеет код 10.
7.2 Минимально необходимый набор функций УСВ для использования услуги EGTS_ECALL_SERVICE
Для использования АС вызова экстренных оперативных служб сервиса EGTS_ECALL_SERVICE в УСВ должен быть реализован следующий набор функций:
- поддержка сервиса обработки команд EGTS_COMMANDS_SERVICE, указанного в 6.7.3;
- поддержка команд EGTS_ECALL_REQ, EGTS_ECALL_MSD_REQ, отправляемых оператором системы через SMS, и передача соответствующих ответов и подтверждений на них;
- передача данных профиля ускорения через СПРС (подзапись EGTS_SR_ACCEL_DATA);
- передача данных траектории движения ТС при ДТП через СПРС (подзапись EGTS_SR_TRACK_DATA);
- обработка команд установки параметров УСВ, отправляемых оператором системы через СПРС и SMS, и передача соответствующих подтверждений на них.
Для осуществления взаимодействия в рамках сервиса EGTS_ECALL_SERVICE используется несколько подзаписей, описание и код которых представлены в таблице 44.
Таблица 44
7.3.1 Подзапись EGTS_SR_RECORD_RESPONSE
Данная подзапись имеет такую же структуру, как указано в 6.7.2.1.
7.3.2 Подзапись EGTS_SR_ACCEL_DATA
Структура подзаписи представлена в таблице 45.
Таблица 45
сервиса EGTS_ECALL_SERVICE
В таблице 45 параметры (поля) имеют следующие назначения:
- SA - число передаваемых структур данных показаний акселерометра;
- ATM - время проведения измерений первой передаваемой структуры показаний акселерометра (число секунд с 00:00:00 01.01.2010 UTC).
Примечание - Для передачи требуемого числа отсчетов акселерометра можно использовать несколько идущих одна за другой подзаписей EGTS_SR_ACCEL_DATA, каждая из которых содержит различное время начала отсчета (поле "ATM");
- ADS1 ... ADS255 - структуры данных показаний акселерометра. Формат структуры представлен в таблице 46.
В составе подзаписи EGTS_SR_ACCEL_DATA должна передаваться хотя бы одна структура ADS.
Таблица 46
EGTS_SR_ACCEL_DATA сервиса EGTS_ECALL_SERVICE
В таблице 46 параметры (поля) имеют следующие назначения:
- RTM - приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) в миллисекундах (мс);
- XAAV - значение линейного ускорения по оси X; 0,1 м/с2;
- YAAV - значение линейного ускорения по оси Y; 0,1 м/с2;
- ZAAV - значение линейного ускорения по оси Z; 0,1 м/с2. Разрешающая способность полей ускорения должна быть не более 0,1 м/с2 (0,01 g).
7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA
Структура подзаписи EGTS_SR_RAW_MSD_DATA представлена в таблице 47.
Таблица 47
сервиса EGTS_ECALL_SERVICE
В таблице 47 параметры (поля) имеют следующие назначения:
- FM - формат данных, содержащихся в поле MSD данной подзаписи. Данной версией документа определены следующие возможные значения данного поля:
а) 0 - формат неизвестен;
б) 1 - правила кодировки пакета в соответствии с ГОСТ 33464.
Не указанные в настоящем стандарте значения поля FM должны дополнительно согласовываться между производителем УСВ и оператором системы;
- MSD - минимальный набор данных.
Примечание - Подзапись EGTS_SR_RAW_MSD_DATA сервиса EGTS_ECALL_SERVICE используется УСВ также для передачи на ТП сообщения "Отмена реагирования". В этом случае поле "Message Identifier" должно иметь значение 0 (см. ГОСТ 33464-2023, приложение В, таблица В.1).
7.3.4 Подзапись EGTS_SR_TRACK_DATA
Структура подзаписи EGTS_SR_TRACK_DATA представлена в таблице 48.
Таблица 48
сервиса EGTS_ECALL_SERVICE
В таблице 48 параметры (поля) имеют следующие назначения:
- SA - число передаваемых точек траектории движения ТС;
- ATM - опорное время проведения измерений (число секунд с 00:00:00 01.01.2010 UTC). Используется в качестве начального времени для первой передаваемой структуры с точностью 1 с. Более точное время измерения определяется с учетом поля RTM-структуры информации об отдельной точке траектории движения;
- TDS1 ... TDS255 - структуры данных, содержащие параметры отдельной точки траектории движения ТС. Формат структуры представлен в таблице 49.
Таблица 49
ТС подзаписи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE
В составе подзаписи EGTS_SR_TRACK_DATA должна передаваться хотя бы одна структура TDS.
В таблице 49 параметры (поля) имеют следующие назначения:
- TNDE (Track Node Data Exist) - битовый флаг, определяющий наличие компонентов данных о точке траектории движения в данной структуре TDS (поля LAT, LONG, SPDL, DIRH, SPDH, DIR):
а) 1 - данные передаются,
б) 0 - данные не передаются (для указанного времени не удалось получить достоверные координаты и информацию о скорости с требуемой точностью. Или координаты не валидны, или определены с неудовлетворительной точностью). Поля LAT, LONG, SPDL, DIRH, SPDH, DIR не передаются в составе данной структуры, и ее размер составляет 1 байт;
- LOHS - битовый флаг определяет полушарие долготы:
а) 0 - восточная долгота,
б) 1 - западная долгота;
- LAHS - битовый флаг определяет полушарие широты:
а) 0 - северная широта,
б) 1 - южная широта;
- RTM - приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) - 0,1 с. Определяет время проведения измерения параметров данной точки траектории. Максимально возможное значение приращения составляет 3,2 с;
- LAT - широта по модулю, градусы (WGS 84)/90·0xFFFFFFFF и взята целая часть;
- LONG - долгота по модулю, градусы (WGS 84)/180·0xFFFFFFFF и взята целая часть;
- SPDL, SPDH - младшие (SPDL) и старшие (SPDH) биты параметра скорости (используется 15 бит). Измеряется в 0,01 км/ч. Максимальное значение скорости, передаваемое в данном поле, составляет 327,67 км/ч;
- DIRH (Direction the Highest bit) - старший бит (8) параметра DIR;
- DIR - направление движения ТС, выраженное в градусах, относительно севера по часовой стрелке (дополнительно старший бит находится в поле DIRH). Значение параметра направления должно быть в пределах от 0 до 359.
7.4 Использование сервиса EGTS_COMMANDS_SERVICE
Описание, состав и форматы подзаписей сервиса EGTS_COMMANDS_SERVICE, используемого в целях оказания базовой услуги, приведены в 6.7.3.
7.5 Список и описание команд, параметров и подтверждений при использовании сервиса EGTS_ECALL_SERVICE
7.5.1 Список и описание команд УСВ и подтверждений, необходимых для реализации базовой услуги, а также список параметров УСВ представлены в таблицах 50 и 51.
Таблица 50
Таблица 51
7.5.2 Параметры УСВ, перечисленные в подразделах "Запись профиля ускорения при ДТП" и "Запись траектории движения при ДТП" (см. таблицу 50), необязательны, если указанные функции не реализованы в УСВ.
7.5.3 В УСВ, установленных на ТС в конфигурации штатного оборудования, помимо параметров, указанных в 6.7.3.2, должна быть реализована поддержка следующих параметров:
- EGTS_ECALL_TEST_NUMBER;
- EGTS_ECALL_SIGNAL_INTERNAL;
- EGTS_ECALL_SIGNAL_EXTERNAL;
- EGTS_ECALL_SOS_BUTTON_TIME;
- EGTS_ECALL_CCFT;
- EGTS_ECALL_INVITATION_SIGNAL_DURATION;
- EGTS_ECALL_SEND_MSG_PERIOD;
- EGTS_ECALL_AL_ACK_PERIOD;
- EGTS_ECALL_MSD_MAX_TRANSMISSION_TIME;
- EGTS_ECALL_NAD_DEREGISTRATION_TIMER;
- EGTS_ECALL_DIAL_DURATION;
- EGTS_ECALL_AUTO_DIAL_ATTEMPTS;
- EGTS_ECALL_MANUAL_DIAL_ATTEMPTS;
- EGTS_ECALL_MANUAL_CAN_CANCEL;
- EGTS_ECALL_SMS_FALLBACK_NUMBER;
- EGTS_CRASH_RECORD_TIME;
- EGTS_CRASH_RECORD_RESOLUTION;
- EGTS_CRASH_PRE_RECORD_TIME;
- EGTS_CRASH_PRE_RECORD_RESOLUTION;
- EGTS_TRACK_RECORD_TIME;
- EGTS_TRACK_RECORD_RESOLUTION;
- EGTS_TRACK_PRE_RECORD_TIME;
- EGTS_VEHICLE_VIN;
- EGTS_VEHICLE_TYPE;
- EGTS_VEHICLE_PROPULSION_STORAGE_TYPE.
8.1 Сообщение AL-ACK, направляемое системой экстренного реагирования при авариях в сторону УСВ и содержащее подтверждение корректности минимального набора данных, принятого с использованием тонального модема, должно высылаться также посредством использования тонального модема.
8.2 Сообщение AL-ACK должно иметь формат, определенный в таблице 52.
Таблица 52
9.1 Назначение сервиса представления информации об обстоятельствах дорожно-транспортного происшествия
Сервис предназначен для реализации режима УВС по определению, регистрации и передаче информации об обстоятельствах ДТП. В протоколе уровня поддержки услуг этот сервис определен как EGTS_EUROPROTOCOL_SERVICE и имеет код 22 (см. таблицу 17).
9.2 Состав и описание подзаписей сервиса EGTS_EUROPROTOCOL_SERVICE
9.2.1 Список обязательных подзаписей сервиса режима определения, регистрации и передачи информации об обстоятельствах ДТП приведен в таблице 53.
Таблица 53
и передачи информации об обстоятельствах ДТП
9.2.2 Подзапись EGTS_SR_EP_MAIN_DATA
Подзапись EGTS_SR_EP_MAIN_DATA предназначена для передачи основных данных об автоматическом или ручном определении, регистрации и передачи информации об обстоятельствах ДТП.
Структура подзаписи EGTS_SR_EP_MAIN_DATA приведена в таблице 54.
Таблица 54
Описание полей:
FV - версия формата данных (поле должно содержать значение 1);
B# - младшие 8 бит порядкового номера блока;
B#H - старшие 2 бита порядкового номера блока;
Примечания
1 Каждый отдельный фрагмент массива данных (блок) при работе УСВ в режиме определения, регистрации и передачи информации об обстоятельствах ДТП имеет уникальный номер в пределах от 0 до 1023. Номер выделяется УСВ в цикле.
2 Если должна быть обеспечена некорректируемость информации, передаваемой УСВ в режиме определения, регистрации и передачи информации об обстоятельствах ДТП блока с использованием кода аутентификации в соответствии с требованиями ГОСТ 33464, то в подзаписи EGTS_SR_EP_SIGNATURE в структуре, содержащей код аутентификации, передается аналогичный номер блока, указывая, какому блоку информации соответствует данный код аутентификации.
EVID - уникальный идентификатор данного события определения, регистрации и передачи информации об обстоятельствах ДТП (поле должно содержать значение начиная с 1 и увеличиваться на 1 при каждом новом автоматически или вручную фиксируемом событии ДТП);
CN - битовое поле флагов управления опциональными полями (зарезервировано для дальнейшего использования);
LBSN, LOCP, CLT, ACT, ACP, EVP, TRS, AS, RS, WAS, RWP, TRP - битовые флаги, описание которых приведено ниже.
CLT (Call Type) - определяет тип события:
1 - тестовый вызов,
0 - ДТП;
ACT (Activation Type) - определяет тип активации фиксации события:
1 - автоматический;
0 - ручной;
LOCP (Location Present) - битовый признак, определяющий наличие полей местоположения и перемещения ТС на момент фиксации данного события ДТП, определенные по ГНСС (поля LAT, LONG, ALT, SPDL, DIRH, SPDH, DIR):
1 - данные передаются;
0 - данные не передаются.
LBSN (Location Based Social Network) - если отлично от 0, то число структур BSD с информацией о наблюдаемых УСВ в момент фиксации данного события в базовых станциях ПРТС до 5. Если равно 0, то информация о базовых станциях не передается;
EVP (Events Present) - битовый признак, если установлен в 1, то в подзаписи присутствует один или более уникальных идентификационных номеров событий ДТП, зафиксированных автоматически в пределах интервала времени (в подзаписи должны присутствовать поля: EPEVC и одно или более полей EV1, EV2, ..., EVn), если 0, то автоматических событий в пределах установленного периода времени не зафиксировано;
ACP (Acceleration Data Present) - битовый признак отражения в сообщении факта передачи с данным событием ДТП информации о профиле ускорения:
1 - данные о профиле ускорения передаются (стандартное значение),
0 - данные о профиле ускорения передаются;
TRP (Track Data Present) - битовый признак отражения в сообщении факта передачи с данным событием ДТП информации о траектории движения ТС:
1 - данные о траектории движения ТС передаются (стандартное значение),
0 - данные не передаются;
RWP (Raw Data Present) - битовый признак отражения в сообщении факта передачи с данным событием ДТП первичных навигационных данных:
1 - первичные навигационные данные передаются,
0 - не передаются (стандартное значение);
TRS (Track Data Signing) - битовый признак, отражающий факт обеспечения некорректируемости информации с использованием кода аутентификации в блоке данных о траектории движения ТС:
0 - при передаче для блока данных о траектории движения ТС код аутентификации не вычисляется,
1 - при передаче для блока данных о траектории движения ТС код аутентификации вычисляется, т.е. данные передаются в некорректируемом виде.
AS (Acceleration Data Signing) - битовый признак, отражающий факт обеспечения некорректируемости информации с использованием кода аутентификации в блоке данных с профилем ускорения:
0 - при передаче для блока данных с профилем ускорения код аутентификации не вычисляется,
1 - данные с профилем ускорения передаются в некорректируемом виде;
RS (Raw Data Signing) - битовый признак, отражающий факт обеспечения некорректируемости информации для первичных навигационных данных:
0 - первичные навигационные данные не подписываются,
1 - первичные навигационные данные передаются в некорректируемом виде;
WAS (Whole Array Signature) - битовый признак, отражающий факт обеспечения некорректируемости всего массива информации о событии ДТП с использованием одного кода аутентификации или для каждого блока информации вычисляется свой код аутентификации:
1 - для всего массива информации об определении ДТП вычисляется единый код аутентификации (порядок учета данных массива в алгоритме расчета кода аутентификации указан в 6.3.5),
0 - для каждого блока массива информации рассчитывается свой код аутентификации;
TS - момент фиксации ДТП (число секунд с 00:00:00 01.01.2010 UTC);
MSH и MSL - младшие 8 и старшие 2 бита поля, содержащего число миллисекунд, которое нужно прибавить к значению в поле TS, чтобы получить точное время фиксации данного ДТП. Допускается использовать при автоматической фиксации события;
CAU (Cause) - поле, в котором может быть записана дополнительная причина (особый случай) отправки события ДТП. Для автоматически зафиксированных и сгенерированных в момент нажатия кнопки экстренных вызовов в это поле помещается значение 0.
Допустимы следующие варианты:
1 - TAMP (Tamper) - признак отправки события вследствие нарушения целостности корпуса УСВ;
2 - INTB (Internal Battery) - признак отправки события вследствие перехода УСВ в режим работы от внутренней батареи.
Примечания
1 При обнаружении нарушения целостности корпуса (вскрытии) или пропадании напряжения бортовой сети (УСВ отключили от бортовой сети автомобиля) УСВ генерирует специальную подзапись EGTS_SR_EP_MAIN_DATA с установленным в соответствующее значение полем CAU. При этом не генерируются и не передаются данные о траектории движения и профиле ускорений ТС, но формируется код аутентификации и передается соответствующая подзапись EGTS_SR_EP_SIGNATURE, описанная в 9.2.5.
2 Идентификаторы событий, сформированных и отправленных с отличным от нуля значением поля CAU, не должны попадать в перечень идентификаторов событий, передаваемый при ручной активации УСВ (см. описание полей EVP, EPEVC и EV1, ..., EVn);
LAT - широта по модулю, градусы, (WGS 84)/90 0xFFFFFFFF и взята целая часть;
LAHS (Latitude Hemisphere Sign) - битовый флаг определяет полушарие широты:
0 - северная широта,
1 - южная широта.
LONG - долгота по модулю, градусы, (WGS 84)/180 0xFFFFFFFF и взята целая часть;
LOHS (Latitude Hemisphere Sign) - битовый флаг определяет полушарие долготы:
0 - восточная долгота,
1 - западная долгота.
SPDL, SPDH - младшие (SPDL) и старшие (SPDH) биты параметра скорости (используется 13 бит). Измеряется в км/ч с дискретностью 0,1 км/ч;
ALT - высота над уровнем моря, м;
DIRH (Direction the Highest Bit) - старший бит (8) параметра.
DIRL (Direction Low Bits) - младшие восемь бит - совместно с DIRH определяют направление, выраженное в градусах относительно севера, отсчитываемое по часовой стрелке. Значение параметра направления должно быть в пределах от 0° до 359°;
BSD1, ..., BSD5 - структуры данных информации о наблюдаемых УСВ базовых станциях ПРТС. Формат структуры данных представлен в таблице 55;
EPEVC - число уникальных идентификаторов ДТП, сформированных автоматически в интервале времени.
Если EPEVC отлично от нуля, то далее следует соответствующее число уникальных идентификационных номеров автоматически сформированных ДТП (поля EV1, ..., EVn).
Сформированный состав идентификаторов применяется для подтверждения одного или более автоматически зафиксированных при ДТП ударов перед ручной активацией УСВ. Состав идентификаторов показывает, по каким именно ДТП массивы данных подтверждаются и должны быть сгружены на сервер.
Массивы данных об автоматически зафиксированных ДТП должны быть отправлены УСВ на сервер до того, как начнется отправка события, сгенерированного при ручной активации УСВ.
Таблица 55
сервиса EGTS_EUROPROTOCOL_SERVICE
Описание полей:
NID - идентификатор базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент. Используются 20 младших бит (MCC+MNC);
LAC - идентификатор локальной зоны базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент;
CID - идентификатор ячейки базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент;
SS - модуль уровня силы сигнала данной базовой станции сети подвижной радиотелефонной связи, выраженный в дБм. Например, значение "80" соответствует уровню сигнала "минус 80 дБм".
В момент фиксации события ДТП УСВ формирует буфер для информации подзаписи EGTS_SR_EP_MAIN_DATA, выделяет данному событию очередной номер, если необходимо, определяет параметры наблюдаемых базовых станций сети ПРТС, помещает эту информацию в буфер, присваивает полученному массиву информации очередной номер B#, заполняет им поля B# и B#H и передает данный буфер на определение кода идентификации, дожидается получения кода аутентификации и сохраняет его вместе с данными буфера, осуществляет последующую отправку данных буфера, выполнив обрамление заголовочными данными уровня поддержки услуг транспортного уровня EGTS.
9.2.3 Подзапись EGTS_SR_EP_TRACK_DATA
9.2.3.1 Подзапись EGTS_SR_EP_TRACK_DATA, структура которой приведена в таблице 56, предназначена для передачи массива последовательных точек траектории перемещения ТС за период времени.
Таблица 56
Описание полей:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
RSA - число передаваемых структур RTDS изменения траектории движения ТС;
AT - момент времени (с точностью до 1 с) определения начальной точки траектории для структуры TDS данной подзаписи (число секунд с 00:00:00 01.01.2010 UTC);
RTU (Relative Time Units) - выбор единиц определения относительного смещения времени в структурах TDS:
0 - в секундах (стандартное значение),
1 - в десятых долях секунды с дискретностью 0,1 с;
B#H - старшие 2 бита порядкового номера блока, с кодом аутентификации для проверки его некорректируемости;
CS (Coordinate System) - признак системы координат, в которых представлены координаты точек траектории данной подзаписи:
0 - WGS-84,
1 - ПЗ-90.11;
TS - в дополнение к полю AT устанавливает смещение момента определения начальной точки траектории движения ТС структуры TDS. Смещение задается в единицах, установленных полем RTU;
TDS - структура данных, содержащая параметры начальной точки траектории движения ТС, передаваемой в данной подзаписи. Формат структуры представлен в таблице 57;
RTDS1, ..., RTDS255 (Relative Track Data Structure) - структуры, представляющие изменения траектории движения ТС от точки к точке. Форматы этих структур приведены в таблицах 58 и 59.
Таблица 57
движения ТС подзаписи EGTS_SR_EP_TRACK_DATA
сервиса EGTS_EUROPROTOCOL_SERVICE
Описание полей:
TDE (Track Data Exists) - битовый флаг:
0 - на момент определения координатно-временных параметров первой точки траектории, связанный со временем данной подзаписи, УСВ не удалось получить корректное навигационное решение (координаты и скорость ТС определены с неудовлетворительной точностью или координаты недопустимы). В этом случае все остальные поля структуры не имеют смысла и не передаются;
1 - имеется корректное навигационное решение, все поля структуры обязательны к передаче;
LOHS - битовый флаг, определяет полушарие долготы:
0 - восточная долгота,
1 - западная долгота;
LAHS - битовый флаг, определяет полушарие широты:
0 - северная широта,
1 - южная широта;
LAT - широта по модулю, градусы, (WGS 84)/90·0xFFFFFFFF и взята целая часть;
LONG - долгота по модулю, градусы, (WGS 84)/180·0xFFFFFFFF и взята целая часть;
SPDL, SPDH - младшие 8 (SPDL) и старшие 5 (SPDH) биты параметра скорости движения ТС (всего 13 бит). Измеряется в км/ч с дискретностью 0,1 км/ч;
ALTL, ALTH - младшие 8 бит и старшие 6 бит модуля значения высоты над уровнем моря, м;
ALTS (Altitude Sign) - признак знака значения высоты над уровнем моря:
0 - положительная высота,
1 - отрицательная высота.
DIRH (Direction Low bits) - старший бит (8) параметра DIR;
DIRL - направление, выраженное в градусах относительно севера, отсчитываемое по часовой стрелке (дополнительно старший бит находится в поле DIRH). Значение параметра направления должно быть в пределах от 0° до 359°.
Таблица 58
движения ТС от точки к точке подзаписи
EGTS_SR_EP_TRACK_DATA сервиса EGTS_EUROPROTOCOL_SERVICE
при неизменном навигационном решении
Описание полей:
RST (Relative Track Data Structure Type) - тип структуры данных изменения траектории движения ТС. Для структуры, описанной в таблице 9, значение равно 0;
TMS - приращение ко времени определения предыдущей структуры RTDS (для первой записи RTDS приращение к полю AT), указанное в единицах, установленных полем RTU. Максимальный диапазон приращения равен 63 интервалам, установленным полем RTU;
TDV (Track Data Valid) - битовый флаг, показывающий корректность или некорректность навигационного решения в течение периода TMS:
1 - навигационное решение корректно,
0 - навигационное решение некорректно.
Структуры данного типа передаются, когда состояние и параметры навигационного решения не меняются и совпадают с информацией в предыдущей структуре RTDS или TDS (навигационное решение может быть корректным или нет).
Если навигационное решение не изменяется после 63 интервалов, установленных полем RTU (ТС стоит с включенным зажиганием или по каким-то причинам долго не удается получить корректное навигационное решение), то необходимо формировать последовательно, друг за другом, несколько таких структур.
Структуру данного типа (или несколько таких структур подряд) следует формировать в том случае, если корректное навигационное решение было получено, а затем пропало. Все время от момента потери навигационного решения до момента его восстановления следует перекрыть структурами данного типа с установленным в 0 полем TDV.
Если навигационное решение было некорректным, а затем было получено корректное решение, то следует закончить формировать данную подзапись и начать формировать новую, в которой необходимо указать в поле AT момент времени восстановления навигационного решения и привести структуру TDS, заполненную параметрами навигационного решения.
Рекомендуется очередную подзапись включать в тот же пакет EGTS.
Таблица 59
движения ТС от точки к точке подзаписи EGTS_SR_EP_TRACK_DATA
сервиса EGTS_EUROPROTOCOL_SERVICE при определении
навигационного решения
Описание полей:
RST (Relative Track Data Structure Type) - тип структуры данных для передачи изменений параметров движения и точек траектории движения ТС. Для структуры, описанной в таблице 10, равно 1;
TMS (Time Shift) - приращение ко времени определения предыдущей структуры RTDS (для первой записи RTDS приращение к полю AT), указанное в единицах, установленных полем RTU. Максимальный диапазон приращения равен семи интервалам, установленным полем RTU. Если навигационное решение остается неизменным в течение более длительного периода, то следует применить структуру, описанную в таблице 57;
LATDL, LATDH - младшие 8 бит и старшие 6 бит изменения широты соответственно (изменение WGS 84 в градусах)/90·0xFFFFFFFF и взята целая часть по модулю. Изменения вычисляются относительно значений, зафиксированных на момент передачи предыдущей структуры RTDS. Изменение широты может быть не больше 0,000343°;
LATS - битовый признак знака значения изменения широты:
1 - широта увеличилась,
0 - широта уменьшилась;
LONDL, LONDH - младшие 8 бит и старшие 6 бит изменения долготы соответственно (изменение WGS 84°)/180·0xFFFFFFFF и взята целая часть по модулю. Изменения вычисляются относительно значений, зафиксированных на момент передачи предыдущей структуры RTDS. Изменение долготы может быть не больше 0,000686°;
LONS - битовый признак знака значения изменения долготы:
1 - долгота увеличилась,
0 - долгота уменьшилась;
DIRL, DIRH - младшие 8 бит и старший 1 бит, соответственно значение направления, выраженное в градусах относительно севера, отсчитываемое по часовой стрелке (дополнительно старший бит находится в поле DIRH). Значение параметра направления должно быть в пределах от 0° до 359°;
SPDE (Speed Delta Exists) - битовый флаг, показывающий, присутствует ли в структуре изменение скорости ТС или нет:
1 - изменение скорости присутствует, поля SPDH, SPDL, SPDS должны присутствовать и интерпретироваться,
0 - изменение скорости не присутствует в структуре;
SPDL, SPDH - младшие 8 бит и старшие 2 бита изменений показания скорости в десятых долях км/ч. Изменения вычисляются относительно значений, зафиксированных на момент передачи предыдущей структуры RTDS. Максимальное изменение скорости может быть 102,3 км/ч.
SPDS (Speed Delta Sign) - битовый признак знака изменения значения скорости:
1 - скорость увеличилась,
0 - скорость уменьшилась;
ALTE (Altitude Exists) - признак, характеризующий наличие в структуре показания изменения высоты над уровнем моря, м:
0 - показания изменения высоты отсутствуют,
1 - показания изменения высоты присутствуют (поля ALT и ALTS должны присутствовать и интерпретироваться);
ALTD - модуль значения изменения высоты над уровнем моря, м. Изменение высоты может быть в пределах 127 м;
ALTS (Altitude Sign) - признак знака значения изменения высоты над уровнем моря:
1 - высота увеличилась,
0 - высота уменьшилась.
Структура RTDS передается, если с момента формирования предыдущей структуры в пределах от одного до семи отрезков времени RTU значения широты, долготы, высоты (над уровнем моря) и скорости ТС изменились не слишком значительно (без превышения максимального значения изменений, установленных в соответствующих полях).
Если в какой-то период времени зажигание автомобиля было выключено и координаты ТС не определялись, то необходимо в один пакет транспортного уровня в одну запись уровня поддержки услуг помещать две сервисные подзаписи EGTS_SR_EP_TRACK_DATA, не содержащие ни одной структуры RTDS и содержащие только структуру TDS. Такие подзаписи должны следовать в пакете непосредственно друг за другом. Первая из них должна ссылаться на последний момент времени, когда зажигание ТС еще было включено, вторая - на момент времени, когда зажигание снова включили.
Если в пределах семи промежутков времени обнаружено изменение в навигационном решении, превышающее максимальный диапазон значений любого из полей, то следует передать структуру, приведенную в таблице 10, закончить данную сервисную подзапись EGTS_SR_EP_TRACK_DATA и начать новую подзапись EGTS_SR_EP_TRACK_DATA с соответствующими значениями абсолютного времени и навигационным решением. Новую подзапись следует размещать в той же записи уровня поддержки услуг с учетом того, что общая длина пакета EGTS на транспортном уровне не должна превышать 1441 байт.
9.2.3.2 Алгоритм работы УСВ при формировании траектории движения ТС
а) в начале нового цикла в новом буфере формируется начало подзаписи EGTS_SR_EP_TRACK_DATA, включая структуру TDS, но не заполняется поле RSA;
б) УСВ (на регулярной основе) определяет координатно-временные параметры навигационного решения, и с установленной дискретностью времени, определяемой значением поля RTU (см. таблицу 52), принимается решение о дописывании в буфер структуры RTDS одного из двух форматов (в зависимости от условий и скорости изменения параметров навигационного решения);
в) если обнаруживается, что после добавления очередной структуры RTDS размер буфера превысит 1413 байт, то формирование данного буфера заканчивается, при этом:
1) данному буферу присваивается очередное значение B# (в цикле от 0 до 1023), которое помещается в поля B# и B#H в начале подзаписи EGTS_SR_EP_TRACK_DATA, заполняется поле RSA по числу реально накопленных в буфере структур, и буфер передается на формирование кода аутентификации, требующее определенных затрат времени;
2) одновременно с этим начинается формирование следующего буфера информации о траектории движения ТС;
3) сформированный буфер данных, а также его код аутентификации сохраняются вместе.
Алгоритм а) - в) реализуется циклически. Буферы данных и их коды аутентификации удаляются по прошествии интервала времени.
9.2.3.3 При ручной активации УСВ или при получении команды немедленно завершается формирование текущих буферов данных и инициируется определение их кодов аутентификации, а также начинают формироваться новые экземпляры буферов данных. Все буферы данных и их коды аутентификации в пределах установленного интервала времени помечаются как запрещенные к удалению. Аналогично помечаются и последние буферы данных по завершении определения их кодов аутентификации. Позже все буферы (блоки с данными, включая блоки с кодами аутентификации, помещенные в энергонезависимую память и помеченные как запрещенные для удаления) будут использованы для обрамления данными заголовков уровня поддержки услуг, транспортного уровня EGTS и отправлены на сервер после отправки пакета с информацией об основных параметрах события ДТП. После успешной доставки на сервер со всех данных буферов и их кодов аутентификации снимаются метки защиты от удаления.
9.2.4 Подзапись EGTS_SR_EP_ACCEL_DATA
9.2.4.1 Структура подзаписи EGTS_SR_EP_ACCEL_DATA приведена в таблице 60.
Таблица 60
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
AT - время проведения определений передаваемой структуры ADS показаний акселерометра (число секунд с 00:00:00 01.01.2010 UTC);
ATMSL и ATMSH - младшие 8 бит и старшие 2 бита поля, содержащего число миллисекунд, которое надо прибавить к полю AT, чтобы получить точный момент времени, соответствующий структуре Accelerometer Data Structure;
RSAL - младшие 8 бит числа передаваемых структур ARDS относительных данных показаний акселерометра;
B#H - старшие 2 бита порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
RTU (Relative Time Units) - единицы определения смещения момента времени (поле TMS) в структурах ARDS:
0 - 1 мс (стандартное значение),
1 - 10 мс,
2 - 100 мс,
3 - 1 с;
MU (Measurement Units) - единицы определения (дискретизации) значений ускорений в полях XAVV, YAVV, ZAVV структур ADS и полей XAVD, YAVD, ZAVD структуры ARDS:
0 - 0,001 g,
1 - 0,01 g (стандартное значение),
2 - 0,1 g,
3 - 0,01 м/с2,
4 - 0,1 м/с2,
5 - 1 м/с2,
6 - 0,025 g,
7 - 0,25 g;
RSAH (Relative Structures Amount High Bit) - 2 старших бита (младшие 8 бит находятся в поле RSAL) числа передаваемых структур ARDS относительных данных показаний акселерометра. Максимально возможное число структур ARDS в одной подзаписи равно 1023;
ADS - структура Accelerometer Data Structure показаний акселерометра, формат которой приведен в таблице 61;
ARDS1, ..., ARDS1023 - структуры Accelerometer Relative Data Structure данных изменений показаний акселерометра, формат которых приведен в таблицах 62 и 63.
Таблица 61
подзаписи EGTS_SR_EP_ACCEL_DATA
Описание полей:
XAAV - значение линейного ускорения по оси x в единицах и с дискретностью измерений, установленных полем MU (см. таблицу 59);
YAAV - значение линейного ускорения по оси y в единицах и с дискретностью измерений, установленных полем MU (см. таблицу 59);
ZAAV - значение линейного ускорения по оси z в единицах и с дискретностью измерений, установленных полем MU (см. таблицу 59).
Примечания
1 Ось x направлена параллельно к продольной оси ТС. Положительное направление оси x соответствует движению вперед.
2 Ось y направлена перпендикулярно к оси x в плоскости, параллельной поверхности Земли. Положительному направлению оси y соответствует направление влево.
3 Ось z перпендикулярна к осям x и y. Положительному направлению оси z соответствует направление вверх.
Возможны два варианта структур ARDS:
- структура, содержащая изменения показаний акселерометра по осям (поле RST равно 0);
- структура, показывающая, что в течение определенного времени изменений показаний акселерометра нет ни по одной из осей (поле RST равно 1).
Таблица 62
акселерометра подзаписи EGTS_SR_EP_ACCEL_DATA
Описание полей:
RST (Relative Accelerometer Data Structure Type) - тип структуры данных изменения показаний акселерометра. Для структуры, описанной в таблице 61, значение равно 0;
TMS (Time Shift) - приращение ко времени определения предыдущей структуры ARDS (для первой записи ARDS приращение к полю AT), указанное в единицах, установленных полем RTU;
XAS, YAS, ZAS (X Axis Acceleration Delta Sign) - обозначает знак изменения значений ускорения по осям x, y и z соответственно:
0 - положительное приращение,
1 - отрицательное приращение.
XAADL (X Axis Acceleration Delta Low Bits), XAADH (X Axis Acceleration Delta Higs Bits) - младшие 5 и старший один бит (всего 6 бит) значений изменения (относительно предыдущей структуры ARDS) показаний акселерометра по оси x. Диапазон значений - от 0 до 63 единиц, установленных полем MU (в стандартном случае это соответствует значениям от 0 до 0,63 g;
YAADL, YAADH - младшие 3 и старшие 3 бита (всего 6 бит) значений изменения (относительно предыдущей структуры ARDS) показаний акселерометра по оси y. Диапазон значений - от 0 до 63 единиц, установленных полем MU (в стандартном случае это соответствует значениям от 0 до 0,63 g);
ZAAD - значение (5 бит) изменения (относительно предыдущей структуры ARDS) показаний акселерометра по оси z. Диапазон значений - от 0 до 31 единицы, установленной полем MU (в стандартном случае это соответствует значениям от 0 до 0,31 g).
Данная структура передается, если с момента формирования предыдущей структуры в пределах от одного до семи отрезков времени RTU по одной или более осям были зафиксированы небольшие (не превышающие максимального значения для диапазона полей) изменения ускорений.
Если ускорения не изменяются дольше семи промежутков времени (с погрешностью представления измеренного значения ускорения в одну единицу дискретизации, установленную для поля MU в соответствии с таблицей 59), то должны передаваться структуры, указанные в таблице 62.
Если в определенный период времени зажигание автомобиля было выключено и ускорения не измерялись, то при очередной передаче информации с ТС необходимо в один транспортный пакет, в одну запись уровня поддержки услуг, помещать две сервисные подзаписи EGTS_SR_EP_ACCEL_DATA, не содержащие ни одной структуры ARDS, а содержащие только структуру ADS. Такие подзаписи должны следовать в пакете непосредственно друг за другом. Первая из них должна ссылаться на последний момент времени, когда зажигание еще было включено, вторая - на момент времени, когда зажигание снова включили.
Если в пределах семи промежутков времени установлено изменение ускорения, превышающее максимальные значения для диапазона полей, то следует передать структуру в соответствии с таблицей 62, закончить данную сервисную подзапись EGTS_SR_EP_ACCEL_DATA и начать новую подзапись EGTS_SR_EP_ACCEL_DATA с соответствующими значениями абсолютного времени и абсолютными показаниями ускорения. Новую подзапись следует размещать в той же сервисной записи с учетом того, что общая длина пакета EGTS на транспортном уровне не должна превышать 1441 байт.
Структура, указанная в таблице 62, применима к периодам движения ТС с частыми, но не резкими (незначительными) изменениями ускорения. С учетом максимального размера пакета передачи данных в сетях ПРТС в одном пакете EGTS может быть размещено до 466 структур ARDS.
Таблица 63
акселерометра в течение длительного периода времени
Описание полей:
RST (Relative Accelerometer Data Structure Type) - тип структуры данных изменения показаний акселерометра. Для структуры, описанной в таблице 59, равно 1;
TMS (Time Shift) - приращение ко времени определения предыдущей структуры ARDS (для первой записи ARDS приращение к полю AT), указанное в единицах, установленных полем RTU. В течение всего этого времени по всем трем осям ТС значения показаний акселерометра были такими же, что и в предыдущей структуре ARDS в пределах погрешности измерения и дискретности представления показаний акселерометра, установленных полем RTU.
Максимальное значение поля равно 127 единицам RTU. Если ускорение остается неизменным в период времени, превышающий значение 127 единиц RTU, то следует формировать подряд несколько структур ARDS данного типа, следующих друг за другом.
Структуры данного типа передаются, как правило, в тех случаях, когда ТС стоит с включенным зажиганием или движется равномерно по ровной дороге.
Подзапись EGTS_SR_EP_ACCEL_DATA будет содержать структуры ARDS и с типом RST, равным 0 (при движении), и с типом RST, равным 1 (при остановках), покрывающими без пропусков во времени некий интервал периода записи профиля ускорения.
9.2.4.2 Подзапись EGTS_SR_EP_ACCEL_DATA2
Данная подзапись применяется с целью уменьшения объема информации о профиле ускорения для тех периодов стоянки или движения ТС, когда от измерения к измерению соблюдается условие, что значение ускорения изменяется больше, чем значение дискретности, установленное полем MU (см. таблицу 59), по одной или любым двум осям ТС, но не по всем трем сразу.
Структура подзаписи EGTS_SR_EP_ACCEL_DATA2 приведена в таблице 64. Она аналогична структуре подзаписи EGTS_SR_EP_ACCEL_DATA (см. 9.1.4.1), за исключением того, что в своей динамической части с данными об истории ускорения содержит массив более коротких структур ARSDS (Accelerometer Relative Short Data Structure).
Таблица 64
Физический смысл, размерность и формат всех полей от начала записи и до структуры ADS включительно полностью совпадают с описанием соответствующих полей подзаписи EGTS_SR_EP_ACCEL_DATA (см. описание к таблице 60).
Структуры ARSDS имеют два варианта представления:
а) структура, показывающая, что в течение определенного времени изменений измеренных акселерометром значений ускорений нет ни по одной из осей ТС (значение поля RST равно 1). Формат структуры представлен в таблице 63, а содержание и описание полей аналогичны соответствующей структуре ARDS подзаписи EGTS_SR_EP_ACCEL_DATA по 9.1.4.1;
б) структура, содержащая изменения измеренных акселерометром значений ускорений по осям ТС (значение поля RST равно 0).
Описание формата структуры, указанной в перечислении а), содержащее состав, последовательность представления и значения полей, приведено ниже.
Структура ARSDS представляет собой последовательный поток битов. При этом первый бит должен быть установлен в 0 (значение RST равно 0).
Далее следует однобитовое поле XAP (X Accel data Present). Если оно равно 0, то в структуре не передается приращение величины ускорения по оси x (поля XAS и XAD не присутствуют в битовом потоке, а далее следует сразу поле ZAP).
Если бит XAP установлен в 1, то далее в битовом потоке должны быть представлены поля XAS и XAD следующего формата:
- XAS (X Accel data Sign) - однобитовое поле, определяющее знак приращения величины ускорения по оси x:
0 - соответствует положительному приращению ускорения,
1 - соответствует отрицательному приращению ускорения;
- XAD (X Accel Data) - поле длиной 5 бит, содержащее величину приращения ускорения по оси x, выраженное в единицах, установленных полем MU подзаписи EGTS_SR_EP_ACCEL_DATA2.
Примечание - При стандартном значении параметра дискретности 0,01 g поле позволяет вместить приращения ускорения до 0,31 g.
Далее следует однобитовое поле ZAP (Z Accel data Present). Если оно равно 0, то в структуре не передается приращение величины ускорения по оси z (поля ZAS и ZAD не присутствуют в битовом потоке, а далее следует сразу поле YAS).
Если бит ZAP установлен в 1, то далее в битовом потоке в обязательном порядке следуют поля ZAS и ZAD следующего формата:
- ZAS (Z Accel data Sign) - однобитовое поле, определяющее знак приращения величины ускорения по оси z:
0 - соответствует положительному приращению ускорения,
1 - соответствует отрицательному приращению ускорения;
- ZAD (Z Accel Data) - поле длиной 5 бит, содержащее значение приращения ускорения по оси z, выраженное в единицах, установленных полем MU подзаписи EGTS_SR_EP_ACCEL_DATA2.
Примечание - При стандартном значении параметра дискретности 0,01 g поле позволяет вместить приращения ускорения величиной до 0,310 g.
В связи с тем, что структура ARSDS используется для передачи приращения ускорений не более чем по двум осям ТС, при условии помещения в битовый поток информации о приращениях по осям x и z приращение по оси y в битовый поток не упаковывается.
И наоборот, если значениями полей XAP и ZAP определено отсутствие приращения ускорений по одной из этих осей (x или z), то информация о приращении ускорения по оси y должна быть помещена в битовый поток, включающий следующие поля:
- YAS (Y Accel data Sign) - однобитовое поле, определяющее знак приращения значения ускорения по оси y:
0 - соответствует положительному приращению ускорения,
1 - соответствует отрицательному приращению ускорения;
- YAD (Y Accel Data) - поле длиной 5 бит, содержащее значение приращения ускорения по оси y, выраженное в единицах, установленных полем MU подзаписи EGTS_SR_EP_ACCEL_DATA2.
Примечание - При стандартном значении параметра дискретности 0,01 g поле позволяет вместить приращения ускорения величиной до 0,310 g.
Далее, независимо от того, по какой из осей передавались приращения ускорений, в битовый поток упаковывается однобитовое поле TMS, указывающее, на сколько интервалов времени, установленных полем RTU, отстает от предыдущего определение ускорений, представленное данным экземпляром структуры. Значение 0 соответствует интервалу в одну единицу времени, значение 1 соответствует интервалу в две единицы времени. Если ускорение не имело приращений в течение большего числа единиц времени, то следует разместить структуру ARSDS, у которой поле RST равно 1 (см. таблицу 63).
Значения приращений ускорений XAD, YAD и ZAD упаковываются в битовый поток младшими битами вперед, а общий размер упакованного битового потока структуры ARSDS данного формата равен двум байтам.
9.2.4.3 Подзапись EGTS_SR_EP_ACCEL_DATA3
Данная подзапись применяется для тех интервалов движения ТС, когда ускорения по осям претерпевают существенные изменения (по осям x и z свыше 63 единиц, установленных полем MU, по оси y - свыше 31 единицы) от определения к определению, отстоящим по времени на интервал, установленный полем RTU.
Структура подзаписи EGTS_SR_EP_ACCEL_DATA3 аналогична структуре подзаписи EGTS_SR_EP_ACCEL_DATA указанной в 9.1.4.1, за исключением того, что в своей динамической части с данными о профиле ускорения содержит массив структур AD (Accelerometer Data). Структура подзаписи EGTS_SR_EP_ACCEL_DATA3 приведена в таблице 65.
Таблица 65
Назначение, размерность и формат всех полей от начала записи и до структуры ADS включительно полностью совпадают с описанием соответствующих полей подзаписи EGTS_SR_EP_ACCEL_DATA (см. описание полей к таблице 60).
Структуры AD имеют два варианта представления:
а) структура, показывающая, что в течение определенного времени изменений измеренных акселерометром значений ускорений нет ни по одной из осей ТС (значение поля RST равно 1). Формат структуры представлен в таблице 63, а назначение и описание полей аналогичны соответствующей структуре ARDS подзаписи EGTS_SR_EP_ACCEL_DATA, указанной в 9.1.4.1;
б) структура, содержащая изменения показаний акселерометра по осям (значение поля RST равно 0).
Формат структуры приведен в таблице 66.
Таблица 66
подзаписи EGTS_SR_EP_ACCEL_DATA 3
Описание полей:
RST (Relative Accelerometer Data Structure Type) - должно быть установлено в 0;
TMS (Time Shift) - приращение ко времени определения предыдущей структуры AD (для первой записи AD приращение к полю AT), указанное в единицах времени, установленных полем RTU. В течение всего этого времени по всем трем осям измеренные акселерометром значения ускорений были точно такими же, что и в предыдущей структуре AD, в пределах погрешности и дискретности представления показаний, установленных полем RTU. Максимальное значение поля равно 127 единицам RTU;
XAAV - значение линейного ускорения по оси x в единицах и с дискретностью, установленных полем MU (см. таблицу 59);
YAAV - значение линейного ускорения по оси y в единицах и с дискретностью, установленных полем MU (см. таблицу 59);
ZAAV - значение линейного ускорения по оси z в единицах и с дискретностью, установленных полем MU (см. таблицу 59).
9.2.4.4 Алгоритм работы УСВ при подготовке данных о профиле ускорения
Подготовка данных о профиле ускорения осуществляется следующим образом:
а) в начале нового цикла в новом буфере формируется начало подзаписей EGTS_SR_EP_ACCEL_DATA, EGTS_SR_EP_ACCEL_DATA2, EGTS_SR_EP_ACCEL_DATA3 (они одинаковы по структуре), включая структуру ADS, но не заполняются поля RSAL, RSAH;
б) на регулярной основе осуществляется определение ускорения и с установленной периодичностью, определяемой полем RTU, принимается решение об описывании в буфере структуры ARDS, ARSDS или AD одного из двух форматов (в зависимости от условий изменения ускорений);
в) при превышении объема очередного буфера величины 1413 байт после добавления очередной структуры ARDS, ARSDS или AD:
1) данному буферу присваивается очередное значение B# (в цикле от 0 до 1023), которое помещается в поля B# и B#H в начале подзаписи EGTS_SR_EP_ACCEL_DATA, EGTS_SR_EP_ACCEL_DATA2 или EGTS_SR_EP_ACCEL_DATA3, заполняются поля RSAL и RSAH по числу накопленных в буфере структур, буфер может передаваться на формирование кода аутентификации, которое занимает определенное время;
2) одновременно с процедурой, указанной в перечислении 1), начинается формирование следующего буфера данных с профилем ускорения;
3) сформированный буфер данных с профилем ускорения, а также его код аутентификации сохраняются вместе в энергонезависимой памяти.
Алгоритмы 1) - 3) реализуются циклически. Буферы данных и их коды аутентификации удаляются по истечении интервала времени.
Подзапись EGTS_SR_EP_SIGNATURE, структура которой приведена в таблице 67, предназначена для предоставления информации о коде аутентификации одного или более массивов данных, передаваемых об одном событии (об одном событии ДТП).
Таблица 67
Описание полей:
VER - версия формата блока информации о коде аутентификации (значение для поля VER должно быть установлено в 0);
SA - число структур с массивами данных, соответствующих коду аутентификации. Может быть от одной и более, в зависимости от требуемой схемы подписания массива данных о событии ДТП;
ASD1...ASD255 - структуры, содержащие информацию о коде аутентификации одного массива.
Состав структуры ASD приведен в таблице 68.
Таблица 68
Описание полей:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
B#H (Block Number High Bit) - старшие 2 бита порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
KEY# - номер ключа из массива ключей, доступных УСВ, с помощью которого сформирован код аутентификации данного блока данных. В данной версии УСВ поддерживает один ключ.
Примечание - Рекомендуемое значение для включения в поле KEY# должно выбираться исходя из условия, что УСВ поддерживает один ключ;
ALGID - идентификатор алгоритма генерации кода аутентификации.
Примечание - Рекомендуемое значение для включения в поле ALGID - 0x8034, что соответствует алгоритму (см. [7]);
SLNL, SLNH - младшие 8 бит и старшие 6 бит значения длины данных кода аутентификации;
SD - данные кода аутентификации массива данных.
Примечания
1 Если требуется определение кода аутентификации всего массива информации о событии ДТП, перед вычислением кода аутентификации указанный массив информации объединяется без выравнивания содержимого всех сервисных подзаписей (их полезной нагрузки - поля SDR (Subrecord Data)) в следующем порядке:
- подзапись EGTS_SR_EP_MAIN_DATA;
- подзаписи EGTS_SR_EP_TRACK_DATA, если передаются;
- подзаписи EGTS_SR_EP_ACCEL_DATA, EGTS_SR_EP_TRACK_DATA2, EGTS_SR_EP_TRACK_DATA3, если передаются;
- подзаписи EGTS_SR_EP_RAW_DATA, если передаются.
2 Информация подзаписей о траектории движения ТС упорядочивается по времени в порядке возрастания.
3 Информация подзаписей о профиле ускорения упорядочивается по времени без учета типа подзаписи.
4 Информация подзаписей о первичных навигационных данных упорядочивается по времени в порядке возрастания.
5 Сформированный массив данных используется для вычисления кода аутентификации.
6 Если требуется определение кодов аутентификации информации о событии ДТП по блокам, то определение кодов аутентификации осуществляется по мере формирования блоков, при этом порядок вычисления кодов аутентификации блоков разного типа (с разными подзаписями) не имеет значения. В массив информации одного события ДТП можно включить и подписать не более 1024 блоков.
9.2.6 Подзапись EGTS_SR_EP_RAW_DATA
Подзапись EGTS_SR_EP_RAW_DATA предназначена для передачи дополнительных данных по каждому навигационному спутнику, используемому при определении координатно-временных параметров ТС: условного номера спутника, определенных значений псевдодальности и доплеровского сдвига, соотношения сигнал/шум, времени определения. Структура подзаписи EGTS_SR_EP_RAW_DATA приведена в таблице 69.
Таблица 69
Описание полей:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
B#H - старшие 2 бита порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
MSA - число передаваемых в данной подзаписи структур данных об одном изменении первичных навигационных данных (номера спутников, время измерения, соотношение сигнал/шум, псевдодальность, доплеровский сдвиг);
ATM - время проведения измерений первой передаваемой структуры первичных навигационных данных (номера спутников, время измерения, соотношение сигнал/шум, псевдодальность, доплеровский сдвиг) (число секунд с 00:00:00 01.01.2010UTC);
DATA_GNSS - идентификатор ГНСС, от которой представлены первичные навигационные данные;
TIME_GNSS - идентификатор ГНСС, по шкале времени которой представлено время данных определений (значение в совокупности поля ATM и полей RTM структур Measurement Structure). Используются следующие идентификаторы:
1 - ГЛОНАСС;
2 - GPS;
3 - Beidou;
4 - Galileo;
MS1, MS2, ..., MS64 - структуры данных об одном определении первичных навигационных параметров (номера спутников, время определения, соотношение сигнал/шум, псевдодальность, доплеровский сдвиг).
Структура данных MS приведена в таблице 70.
Таблица 70
Описание полей:
RTM - смещение времени в миллисекундах относительно значения ATM;
MSA - число передаваемых в данной подзаписи структур данных об одном изменении первичных навигационных данных (номера спутников, время измерения, соотношение сигнал/шум, псевдодальность, доплеровский сдвиг);
SATA - число блоков информации о видимых спутниках, следующих далее. Наличие хотя бы одного видимого спутника обязательно;
SAT# - номер видимого спутника;
SNR - отношение сигнал/шум сигнала от спутника с номером SAT#;
PR - измеренная псевдодальность от спутника, см;
DOP - доплеровский сдвиг, МГц.
9.2.7 Подзапись EGTS_SR_EP_COMP_DATA
9.2.7.1 Подзапись EGTS_SR_EP_COMP_DATA, структура которой приведена в таблице 71, предназначена для передачи в сжатом виде информации других сформированных подзаписей сервиса EGTS_EUROPROTOCOL_SERVICE, кроме подзаписей EGTS_SR_RECORD_RESPONCE и EGTS_SR_EP_MAIN_DATA.
Таблица 71
Данные для подзаписи EGTS_SR_EP_COMP_DATA формируются на основе данных какой-либо сформированной подзаписи до момента определения ее кода аутентификации. Ко всему массиву данных сформированной подзаписи применяется алгоритм сжатия данных. Сжатые данные помещаются в поле CD.
Поле CM (Compression Method) служит для указания примененного алгоритма сжатия данных.
Примечание - В поле CM рекомендуется помещать значение, равное 0, что соответствует применению алгоритма deflate, определенного в RFC 1951, и упаковыванию в формат zlib, определенный в RFC 1950.
Данные полученного сжатого массива помещаются в поле CD, а его длина - в поле CDL.
В поля B# и B#H переносятся без изменения значения аналогичных полей из исходной подзаписи. В поле SRT помещается тип исходной подзаписи, данные которой были подвергнуты сжатию.
9.2.7.2 Применение процедуры сжатия данных позволяет уменьшить объем трафика и время передачи данных о событии ДТП на сервер, а также сократить время вычисления кода аутентификации сформированного блока данных.
Сжатие данных рекомендуется применять для всех формируемых подзаписей, кроме специально оговоренных подзаписей.
Наиболее эффективным является применение передачи со сжатием следующих данных подзаписей:
- EGTS_SR_EP_ACCEL_DATA;
- EGTS_SR_EP_ACCEL_DATA2;
- EGTS_SR_EP_ACCEL_DATA3;
- EGTS_SR_EP_RAW_DATA.
Не допускается применять сжатие следующих подзаписей:
- EGTS_SR_RECORD_RESPONCE;
- EGTS_SR_EP_MAIN_DATA;
- EGTS_SR_EP_COMP_DATA.
Примечания
1 Сжатие блока данных перед вычислением его кода аутентификации рекомендуется применять, если текущий массив информации о траектории движения ТС размером не более 1413 байт формируется УСВ за отрезок времени не более 6,9 с.
2 Определение кода аутентификации блока информации размером в 1413 байт осуществляется за интервал времени не более 7,6 с.
(справочное)
СИСТЕМЫ НА ОСНОВЕ ПРОТОКОЛА ТРАНСПОРТНОГО УРОВНЯ
Минимальным и достаточным элементом системы, использующей протокол транспортного уровня, является ТП. В качестве основной составной части ТП, выполняющей функции координации внутриплатформенного взаимодействия и маршрутизации, используется такое понятие как диспетчер.
Протоколом различается логический уровень межплатформенной маршрутизации, данные в котором (информационные пакеты) передаются на уровне отдельных ТП, а также уровень внутриплатформенной маршрутизации, информация в котором передается между отдельными сервисами одной платформы. Под "сервисом" понимается отдельная составная часть ТП, обеспечивающая функциональное выполнение алгоритма той или иной услуги с использованием описываемого протокола транспортного уровня. Во всех указанных типах маршрутизации взаимодействие происходит через диспетчера.
Генераторами и потребителями данных в системе, построенной на основе протокола транспортного уровня, являются сервисы, которые на стороне-отправителе создают пакеты, а на стороне-получателе производят обработку пакетов, полученных от других сервисов. Каждый сервис реализует различную бизнес-логику в зависимости от функционала той или иной услуги. Тип сервиса является его главной функциональной характеристикой и используется диспетчером для внутриплатформенной маршрутизации данных. Как правило, во взаимодействии участвуют комплементарная пара сервисов, один из которых расположен на стороне абонентского терминала (применительно к настоящему стандарту - УСВ), например генерирует пакеты с координатными данными и показаниями датчиков, а другой на стороне ТП такие данные обрабатывает.
Все сервисы в рамках одной ТП соединяются с диспетчером и не имеют непосредственных связей между собой.
ТП может иметь связи с другими платформами и производить обмен данными на основе данных маршрутизации. Для осуществления маршрутизации диспетчер обращается к локальному хранилищу, содержащему данные о соседних ТП и доступных на них сервисах, а также информацию о сервисах, функционирующих в рамках своей платформы. При организации связи между диспетчерами различных ТП происходит обмен информацией о типах сервисов, доступных на каждой из сторон, а также их статусе. Поиск маршрута сводится к поиску направления (соединения) по типу запрашиваемого сервиса. Если запрашиваемый сервис находится на той же ТП, что и диспетчер, то взаимодействие происходит с использованием только внутриплатформенной маршрутизации. То есть, если имеются соответствующие разрешения, поиск сервиса ведется по данным маршрутизации на соседних ТП, и на нахождении такого маршрута и доступности маршрута происходит трансляция запроса на найденную платформу, при этом в качестве адреса используется идентификатор диспетчера удаленной платформы.
УСВ также осуществляет взаимодействие с сервисами ТП через диспетчера. При этом УСВ идентифицируется по специальным пакетам, содержащим уникальный номер УСВ, назначаемый ей при регистрации в системе, а также другие учетные данные и информацию о внутренней инфраструктуре и состоянии модулей и блоков УСВ.
Структурная схема взаимодействия элементов системы, основанной на описываемом протоколе транспортного уровня, представлена на рисунке А.1. Каждый сервис имеет определенный тип, который на рисунке А.1 определяется параметром SID.
![]() системы, основанной на протоколе транспортного уровня
(справочное)
НА ОСНОВЕ КОНЦЕПЦИИ NGTP
Согласно концепции построения телематических систем на основе NGTP различают три основных элемента взаимодействия: телематическое устройство, провайдер телематических сервисов и диспетчер. Взаимодействие осуществляется через стандартизованные интерфейсы и является элементами протокола за исключением провайдера телематических сервисов, который объединен в протоколе с диспетчером.
Телематическое устройство (применительно к настоящему стандарту - УСВ) интегрируется в ТС, но также может быть персональным навигационным устройством или мобильным телефоном.
Провайдер телематических сервисов предназначен для обмена данными между сервисами и телематическими устройствами.
Диспетчер согласно NGTP является посредником между ПТС и ПУ и обеспечивает стандартный интерфейс связи ТУ с другими компонентами системы, обеспечивающими выполнение функционала сервисов. Диспетчер оперирует только данными своего уровня и не анализирует состав данных уровня сервисов.
Заголовок NGTP полностью совпадает с первыми байтами заголовка протокола транспортного уровня: Protocol Version (1 байт), Security Context (2 байта), NGTP Header Length (1 байт), NGTP Header Encoding (1 байт).
В NGTP идентификатором УСВ является VIN/DriveID, в описываемом протоколе - UNIT_ID.
Для идентификации УСВ, исполненной в конфигурации штатного оборудования, используется VIN.
Как и NGTP, протокол направлен на гибкую маршрутизацию данных сервисов между УСВ и ТП. При этом внедрение нового сервиса не требует доработки протокола, т.к. протоколом производятся только маршрутизации данных, а сама обработка ведется непосредственно в самом сервисе. Необходимо лишь настроить правильную маршрутизацию диспетчера на новый тип сервиса, что реализуется средствами администрирования системы, построенной на основе протокола транспортного уровня.
NGTP оперирует таким понятием, как событие, определяющее некоторую общую характеристику данных и предназначенное для интеграции информации различного типа в некий массив обобщенных данных. Каждому идентификатору события также соответствует признак, идентифицирующий время генерации события. Использование такого механизма обобщения заложено в протоколе транспортного уровня, в котором каждая запись протокола уровня поддержки сервисов (услуг) может содержать идентификатор события, который генерируется источником таких записей в определенный срез времени, например при возникновении ДТП.
В отличие от NGTP, который использует различные интерфейсы между ТУ и диспетчером, диспетчером и ПТС и между ПТС и сервисами, протокол транспортного уровня УСВ использует один интерфейс для связи компонентов.
NGTP использует такое понятие как "триггер", подразумевающий некое уведомление компонентов системы о том, что для них принята информация. Приняв такой "триггер", получатель информации должен запросить данную информацию и обработать. В протоколе транспортного уровня не используются "триггеры", и информация сразу же передается получателю.
(обязательное)
Коды результатов обработки приведены в таблице В.1.
Таблица В.1
(справочное)
КОНТРОЛЬНОЙ СУММЫ CRC-16 НА ЯЗЫКЕ C/*
(справочное)
КОНТРОЛЬНОЙ СУММЫ CRC-8 НА ЯЗЫКЕ C/*
(справочное)
Е.1 Кодировка символов латинского алфавита приведена на рисунке Е.1.
![]() Е.2 Кодировка символов латинского и кириллического алфавитов приведена на рисунке Е.2.
![]() и кириллического алфавитов
Е.3 Кодировка символов латинского и древнееврейского алфавитов приведена на рисунке Е.3.
![]() и древнееврейского алфавитов
(обязательное)
(ПРОТОКОЛА EGTS) ВЕРСИИ "01"
Описание ППУ (протокола EGTS) версии "02", являющегося развитием предыдущей версии ППУ версии "01".
В приложении приведены описания сервисов в части отличий от версии "02". Реализуя приведенные в данном приложении отличия - обеспечивается работа согласно версии протокола "01".
Ж.1 Перечень сервисов и подсервисов, в части которых внесены изменения при переходе с протокола версии "01" на протокол версии "02".
Таблица Ж.1
Перечень сервисов и подзаписей, в части которых внесены
изменения при переходе с протокола версии "01"
к протоколу версии "02"
Ж.2 Структуры данных, используемые в протоколе уровня поддержки услуг для версии протокола "01"
Структура записи
Структура отдельной записи уровня поддержки услуг приведена в таблице Ж.2.
Таблица Ж.2
уровня поддержки услуг для версии протокола "01"
Ж.3 Сервис EGTS_AUTH_SERVICE
Подзапись EGTS_SR_TERM_IDENTITY
Структура подзаписи приведена в таблице Ж.3.
Таблица Ж.3
EGTS_AUTH_SERVICE для версии протокола "01"
Подзапись EGTS_SR_VEHICLE_DATA
Таблица Ж.4
Формат подзаписи EGTS_SR_VEHICLE_DATA сервиса
EGTS_AUTH_SERVICE для версии протокола "01"
Поля подзаписи EGTS_SR_VEHICLE_DATA имеют следующие значения:
- VIN - идентификационный номер ТС
- VHT - тип ТС:
а) Бит 31-5 не используется,
б) Бит 4-0,
в) 0001 - пассажирский (Class M1),
г) 0010 - автобус (Class M2),
д) 0011 - автобус (Class M3),
е) 0100 - легкая грузовая машина (Class N1),
ж) 0101 - тяжелая грузовая машина (Class N2),
и) 0110 - тяжелая грузовая машина (Class N3),
к) 0111 - мотоцикл (Class L1e),
л) 1000 - мотоцикл (Class L2e),
м) 1001 - мотоцикл (Class L3e),
н) 1010 - мотоцикл (Class L4e),
о) 1011 - мотоцикл (Class L5e),
п) 1100 - мотоцикл (Class L6e),
р) 1101 - мотоцикл (Class L7e).
Ж.4 Сервис EGTS_TELEDATA_SERVICE
Таблица Ж.5
Формат подзаписи EGTS_SR_POS_DATA сервиса
EGTS_TELEDATA_SERVICE для версии протокола "01"
Таблица Ж.6
Формат подзаписи EGTS_SR_POS_DATA_SIG сервиса
EGTS_TELEDATA_SERVICE для версии протокола "01"
(обязательное)
МОНИТОРИНГОВОЙ ИНФОРМАЦИИ EGTS_TELEDATA_SERVICE
И.1 Состав сервиса EGTS_TELEDATA_SERVICE
Сервис EGTS_TELEDATA_SERVICE предназначен для передачи мониторинговой информации между УСВ и телематическими системами (аппаратно-программными комплексами), а также между двумя телематическими системами мониторинговой информации, полученной от УСВ.
Список подзаписей, используемых сервисом EGTS_TELEDATA_SERVICE, представлен в таблице И.1.
Таблица И.1
В случае подключения дополнительного бортового оборудования к УСВ на борту ТС включение в состав мониторинговой информации и передача соответствующих данных от этого оборудования могут быть реализованы через передачу данных в подзаписях EGTS_SR_AD_SENSORS_DATA, или EGTS_SR_COUNTERS_DATA, или EGTS_SR_LOOPIN_DATA, или EGTS_SR_ABS_DIG_SENS_DATA, или EGTS_SR_ABS_AN_SENS_DATA, или EGTS_SR_ABS_CNTR_DATA, или EGTS_SR_ABS_LOOPIN_DATA и других. В этом случае при осуществлении подключения передачи данных между телематическими системами (аппаратно-программными комплексами телематических систем) необходимо обеспечить настройку принимающей ТП для интерпретации соответствующих параметров выше указанных подзаписей.
В перечень мониторинговой информации могут входить следующие данные:
- показания датчика включения/выключения зажигания;
- показания датчиков оценки состояния груза (датчиков температуры, давления, влажности, перегрузок и др.);
- показания датчиков контроля наличия специальных грузов на ТС;
- показания датчиков выгрузки;
- показания датчиков уровня заряда основного и резервного источника питания (аккумуляторной батареи);
- показания датчиков контроля технического состояния ТС от специализированных бортовых датчиков и устройств контроля состояния узлов и агрегатов;
- показания датчиков включения/выключения оборудования;
- показания датчиков контроля нахождения перевозимого груза на грузовой платформе ГТС;
- показания датчиков мониторинга внутрисалонного состояния среды (датчик температуры и датчик задымления);
- показания идентификации водителя;
- показания датчиков контроля физиологического состояния водителя.
Перечень данных от дополнительного бортового оборудования, включаемый в состав мониторинговой информации, в зависимости от функций, выполняемых УСВ, определяет заказчик или изготовитель УСВ.
В случае подключения дополнительного бортового оборудования к УСВ на борту ТС, а также в случае реализации дополнительных датчиков в составе УСВ, включение их показаний в состав мониторинговой информации и передачу соответствующих данных от датчиков может быть реализовано через передачу данных в специализированных подзаписях:
- показания датчика включения/выключения зажигания - EGTS_SR_EXT_DATA;
- показания датчиков оценки состояния груза (датчиков температуры, давления, влажности, перегрузок и др.) - EGTS_SR_CARGO_DATA;
- показания датчиков контроля наличия специальных грузов на ТС - EGTS_SR_CARGO_DATA;
- показания датчиков выгрузки - EGTS_SR_EXT_DATA;
- показания датчиков уровня заряда основного и резервного источника питания (аккумуляторной батареи) - EGTS_SR_EXT_DATA;
- показания датчиков контроля технического состояния ТС от специализированных бортовых датчиков и устройств контроля состояния узлов и агрегатов - EGTS_SR_CAM_DATA;
- показания датчиков включения/выключения оборудования - EGTS_SR_CAM_DATA или EGTS_SR_EXT_DATA;
- показания датчиков контроля нахождения перевозимого груза на грузовой платформе грузового ТС - EGTS_SR_EXT_DATA или EGTS_SR_CARGO_DATA;
- показания датчиков мониторинга внутрисалонного состояния среды (датчик температуры и датчик задымления) - EGTS_SR_EXT_DATA;
- показания идентификации водителя - EGTS_SR_EXT_DATA;
- показания датчиков контроля физиологического состояния водителя - EGTS_SR_EXT_DATA.
Подзапись EGTS_SR_RECORD_RESPONSE
Данная подзапись имеет такую же структуру, как описано в 6.7.2.1, и применяется для подтверждения получения и обработки подзаписей сервиса. При этом на УСВ при успешном приеме и обработке должна передаваться подзапись EGTS_SR_RECORD_RESPONSE, содержащая код EGTS_PC_OK или иная в соответствии с итогом обработки (см. приложение В, таблица В.1).
Подзапись EGTS_SR_POS_DATA
Структура подзаписи представлена в таблице И.2.
Таблица И.2
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.2 содержат:
NTM - время навигации (число секунд с 00:00:00 01.01.2010 UTC);
LAT - широта по модулю, градусы/90·0xFFFFFFFF и взята целая часть;
LONG - долгота по модулю, градусы/180·0xFFFFFFFF и взята целая часть;
FLG - определяет дополнительные параметры навигационной посылки;
ALTE - битовый флаг определяет наличие поля ALT в подзаписи:
1 - поле ALT передается,
0 - не передается;
LOHS - битовый флаг определяет полушарие долготы:
0 - восточная долгота,
1 - западная долгота;
LAHS - битовый флаг определяет полушарие широты:
0 - северная широта,
1 - южная широта;
MV - битовый флаг, признак движения:
1 - движение,
0 - ТС находится в режиме стоянки;
BB - битовый флаг, признак отправки данных из памяти ("черный ящик"):
0 - актуальные данные,
1 - данные из памяти ("черный ящик");
FIX - битовое поле, тип определения координат:
0 - 2D fix,
1 - 3D fix;
CS - битовое поле, тип используемой системы:
0 - система координат WGS-84,
1 - государственная геоцентрическая система координат (ПЗ-90.11);
VLD - битовый флаг, признак "валидности" координатных данных:
1 - данные "валидные",
0 - данные "невалидные";
SPD - скорость в км/ч с дискретностью 0,1 км/ч (используется 14 младших бит);
ALTS (Altitude Sign) - битовый флаг, определяет высоту относительно уровня моря и имеет смысл только при установленном флаге ALTE:
0 - точка выше уровня моря,
1 - ниже уровня моря;
DIRH (Direction the Highest bit) - старший бит (8) параметра DIR;
DIR - направление движения. Определяется как угол в градусах, который отсчитывается по часовой стрелке между северным направлением географического меридиана и направлением движения в точке измерения (дополнительно старший бит находится в поле DIRH);
ODM - пройденное расстояние (пробег) в км, с дискретностью 0,1 км;
DIN - битовые флаги, определяют состояние основных дискретных входов 1 ... 8 (если бит равен 1, то соответствующий вход активен, если 0, то неактивен). Данное поле включено для удобства использования и экономии трафика при работе в системах мониторинга транспорта базового уровня;
SRC - определяет источник (событие), инициировавший посылку данной навигационной информации, информация представлена в таблице И.4;
NID - идентификатор базовой станции сети ПРСТ, наблюдаемой УСВ на текущий момент. Используются 20 младших бит (MCC+MNC). Структура поля NID представлена в таблице И.3.
Таблица И.3
LAC - идентификатор локальной зоны базовой станции сети ПРСТ, наблюдаемой УСВ на текущий момент;
CID - идентификатор ячейки базовой станции ПРСТ, наблюдаемой УСВ на текущий момент;
ALT - высота над уровнем моря, м (опциональный параметр, наличие которого определяется битовым флагом ALTE);
SRCD - данные, характеризующие источник (событие) из поля SRC. Наличие и интерпретация значения данного поля определяется полем SRC.
Таблица И.4
сервиса EGTS_TELEDATA_SERVICE
Подзапись EGTS_SR_EXT_POS_DATA
Структура подзаписи представлена в таблице И.5.
Таблица И.5
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.5 содержат:
NSFE (Navigation System Field Exists) - определяет наличие данных о типах используемых навигационных спутниковых систем:
1 - поле NS передается,
0 - не передается;
SFE (Satellites Field Exists) - определяет наличие данных о текущем количестве видимых спутников SAT и типе используемой навигационной спутниковой системы NS:
1 - поля SAT и NS передаются,
0 - не передаются;
PFE (PDOP Field Exists) - определяет наличие поля PDOP:
1 - поле PDOP передается,
0 - не передается;
HFE (HDOP Field Exists) - определяет наличие поля HDOP:
1 - поле HDOP передается,
0 - не передается;
VFE (VDOP Field Exists) - определяет наличие поля VDOP:
1 - поле VDOP передается,
0 - не передается;
VDOP - снижение точности в вертикальной плоскости (значение, умноженное на 100);
HDOP - снижение точности в горизонтальной плоскости (значение, умноженное на 100);
PDOP - снижение точности по местоположению (значение, умноженное на 100);
SAT - число видимых спутников;
NS - битовые флаги, характеризующие используемые навигационные спутниковые системы. Значение битов "0" соответствует значению "Данные указанной системы не использовались". Может быть установлено в "1" более одного, в соответствии с данными систем, использованных для определения местоположения. Определены следующие значения (десятичные) флагов:
0 - система не определена,
1 - ГЛОНАСС,
2 - GPS,
4 - Galileo,
8 - Compass,
16 - Beidou (BDS),
32 - DORIS,
64 - IRNSS,
128 - QZSS,
256 - Технология поддержки потребителей А-ГНСС (Assisted GNSS).
Остальные значения зарезервированы.
Подзапись EGTS_SR_AD_SENSORS_DATA
Структура подзаписи представлена в таблице И.6.
Таблица И.6
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.6 содержат:
DIOE1 - DIOE8 (Digital Inputs Octet Exists) - битовые флаги, определяющие наличие соответствующих полей дополнительных дискретных входов. Всего в одной подзаписи данного типа может быть передана информация о состоянии дополнительных 64 входов:
1 - соответствующее поле ADIO передается,
0 - не передается;
DOUT - битовые флаги дискретных выходов (если бит установлен в 1, то соответствующий этому биту выход активен);
ASFE1 ... ASFE8 (Analog Sensor Field Exists) - битовые флаги, определяющие наличие показаний от соответствующих аналоговых датчиков (если бит установлен в 1, то данные от соответствующего датчика присутствуют, если 0, данные отсутствуют). Если, например, поля ASFE1 = 1 и ASFE3 = 1, то в подзаписи после байта флагов ASFE8 - ASFE1 будут переданы 3 байта значений ANS1 и 3 байта значений ANS3. Значения для датчика ANS2, а также датчиков ANS4...ANS8 не будут передаваться в данной подзаписи;
ADIO1 ... ADIO8 - показания дополнительных дискретных входов. Поля представляют собой битовую маску, в которой значение каждого бита определяет активность соответствующего дискретного входа:
1 - соответствующий вход активен,
0 - не активен;
ANS1 ... ANS8 - значение аналоговых датчиков с 1 по 8 соответственно.
Каждая подзапись EGTS_SR_AD_SENSORS_DATA позволяет передать состояния 64 дополнительных дискретных входов и 8 аналоговых датчиков. Если требуется передать данные от большего числа дискретных или аналоговых входов, то необходимо в одной записи передавать несколько следующих друг за другом подзаписей EGTS_SR_AD_SENSOR_DATA. При этом интерпретация полученных данных производится следующим образом:
- в первой подзаписи EGTS_SR_AD_SENSOR_DATA содержатся данные от дискретных входов с 9 по 72, аналоговых входов с 1 по 8;
- во второй - дискретные входы с 73 по 136 и аналоговые входы с 9 по 16 и т.д.
Подзапись EGTS_SR_COUNTERS_DATA
Структура подзаписи представлена в таблице И.7.
Таблица И.7
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.7 содержат:
CFE1 ... CFE8 (CounterFieldExists) - битовые флаги определяют наличие соответствующих полей счетных входов:
1 - соответствующее поле CN передается,
0 - не передается;
CN1 ... CN8 - значение счетных входов с 1 по 8 соответственно.
Подзапись EGTS_SR_STATE_DATA
Структура подзаписи представлена в таблице И.8.
Таблица И.8
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.8 содержат:
ST - текущий режим работы. Список режимов представлен в таблице И.9;
MPSV - значение напряжения основного источника питания, В, с дискретностью 0,1 В;
BBV - значение напряжения резервной батареи, В, с дискретностью 0,1 В;
IBV - значение напряжения внутренней батареи, В, с дискретностью 0,1 В;
NMS - битовый флаг, определяющий состояние навигационного модуля:
1 - навигационный модуль включен,
0 - навигационный модуль выключен;
IBU - битовый флаг, определяющий, что в качестве источника питания УСВ используется внешний резервный источник:
1 - используется внешний резервный источник,
0 - внешний резервный источник не используется;
BBU - битовый флаг, определяющий, что в качестве источника питания УСВ используется внутренняя батарея:
1 - используется внутренняя батарея,
0 - внутренняя батарея не используется.
Таблица И.9
EGTS_SR_STATE_DATA сервиса EGTS_TELEDATA_SERVICE
Подзапись EGTS_SR_ACCEL_DATA
Структура подзаписи представлена в таблице И.10.
Таблица И.10
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.10 содержат:
SA - число передаваемых структур данных показаний акселерометра;
ATM - время проведения измерений первой передаваемой структуры показаний акселерометра (число секунд с 00:00:00 01.01.2010 UTC);
ADS1 ... ADS255 - структуры данных показаний акселерометра, формат структуры представлен в таблице И.11. В составе подзаписи передается минимум одна структура ADS.
Таблица И.11
EGTS_SR_ACCEL_DATA сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.11 содержат:
RTM - приращение к времени измерения предыдущей записи (для первой записи приращение к полю ATM), мс;
XAAV - значение линейного ускорения по оси x (старший бит определяет знак, 1 указывает на отрицательное значение), м/с2, с дискретностью 0,1 м/с2;
YAAV - значение линейного ускорения по оси y (старший бит определяет знак, 1 указывает на отрицательное значение), м/с2, с дискретностью 0,1 м/с2;
ZAAV - значение линейного ускорения по оси z (старший бит определяет знак, 1 указывает на отрицательное значение), м/с2, с дискретностью 0,1 м/с2;
разрешающая способность полей ускорения - 0,1 м/с2 (0,01 g).
Подзапись EGTS_SR_LOOPIN_DATA
Структура подзаписи представлена в таблице И.12.
Таблица И.12
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.12 содержат:
LIFE 1 ... LIFE 8 (LoopInFieldExists) - битовые флаги, определяющие наличие информации о состоянии шлейфовых входов;
LISn ... LISn+7 (LoopInState) - значение состояния соответствующего шлейфового входа. Предусмотрены следующие состояния шлейфового входа (бинарное представление):
0 - "норма";
0001 - "тревога";
0010 - "обрыв";
0100 - "замыкание на землю";
1000 - "замыкание на питание".
Подзапись EGTS_SR_ABS_DIG_SENS_DATA
Структура подзаписи представлена в таблице И.13.
Таблица И.13
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.13 содержат:
DSN - номер дискретного входа;
DSST - состояние дискретного входа:
0000 - не активен,
остальные значения - активен.
Подзапись EGTS_SR_ABS_AN_SENS_DATA
Структура подзаписи представлена в таблице И.14.
Таблица И.14
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.14 содержат:
ASN - номер аналогового входа;
ASV - значение показаний аналогового входа.
Подзапись EGTS_SR_ABS_CNTR_DATA
Структура подзаписи представлена в таблице И.15.
Таблица И.15
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.15 содержат:
CN - номер счетного входа;
CNV - значение показаний счетного входа.
Подзапись EGTS_SR_ABS_LOOPIN_DATA
Структура подзаписи представлена в таблице И.16.
Таблица И.16
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.16 содержат:
LIN - номер шлейфового входа;
LIS - значение состояния шлейфового входа.
Подзапись EGTS_SR_LIQUID_LEVEL_SENSOR
Структура подзаписи представлена в таблице И.17.
Таблица И.17
Сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.17 содержат:
LLSEF (Liquid Level Sensor Error Flag) - битовый флаг, определяющий наличие ошибок при считывании значения ДУЖ:
0 - ошибок не обнаружено,
1 - ошибка при считывании показаний ДУЖ;
LLSVU (Liquid Level Sensor Value Unit) - битовый флаг, определяющий единицы измерения показаний ДУЖ:
00 - нетарированное показание ДУЖ,
01 - показания ДУЖ в процентах от общего объема емкости,
10 - показания ДУЖ в литрах с дискретностью в 0,1 литра;
RDF (Raw Data Flag) - флаг, определяющий формат поля LLSD данной подзаписи:
0 - поле LLSD имеет размер 4 байта (тип данных UINT) и содержит показания ДУЖ в формате, определяемом полем LLSVU,
1 - поле LLSD содержит данные ДУЖ в неизменном виде, как они поступили из внешнего порта УСВ (размер поля LLSD при этом определяется исходя из общей длины данной подзаписи и размеров, расположенных перед LLSD полей);
LLSN (Liquid Level Sensor Number) - порядковый номер датчика;
MADDR - адрес модуля, данные о показаниях ДУЖ с которого поступили в УСВ (номер внешнего порта УСВ);
LLSD - показания ДУЖ в формате, определяемом полем RDF.
Подзапись EGTS_SR_PASSENGERS_COUNTERS
Структура подзаписи представлена в таблице И.18.
Таблица И.18
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.18 содержат:
RDF (Raw Data Flag) - флаг, определяющий формат поля PCD данной подзаписи:
0 - поле PCD имеет формат, определяемый полем DPR, описание которого представлено в таблице И.19;
1 - поле PCD содержит данные счетчика пассажиропотока в неизменном виде, как они поступили из внешнего порта УСВ (размер поля PD при этом определяется исходя из общей длины данной подзаписи и размеров, расположенных перед PD полей);
DPR (Doors Presented) - битовое поле, определяющее наличие счетчиков на дверях и структуру поля PCD (бит 0 определяет наличие счетчика на первой двери, бит 1 на второй и т.д.). Если бит имеет значение 1, то счетчик используется, если 0 - не используется;
DRL (Doors Released) - битовое поле, определяющее двери, которые открывались и закрывались при подсчете пассажиров (например, 00000000 - ни одна из дверей не открывалась, 00000001 - открывалась только 1-я дверь, 00001001 - открывались 1-я и 4-я двери);
MADDR - адрес модуля, данные от счетчиков пассажиропотока, с которого поступили в УСВ (номер внешнего порта УСВ);
PCD - данные счетчиков пассажиропотока.
Таблица И.19
сервиса EGTS_TELEDATA SERVICE
Поля таблицы И.19 содержат:
IPQ1...IPQ8 - число пассажиров, вошедших через 1 ... 8 дверь;
OPQ1...OPQ8 - число пассажиров, вышедших через 1 ... 8 дверь.
Наличие или отсутствие полей IPQ и OPQ определяется битами поля DPR подзаписи EGTS_SR__PASSENGERS_COUNTERS. Если в поле DPR бит, соответствующий определенному номеру двери, имеет значение 1, то соответствующие поля IPQ и OPQ присутствуют в структуре. Если в поле DPR бит имеет значение 0, то соответствующие поля IPQ и OPQ отсутствуют в структуре. Если определенное поле IPQ присутствует, то и соответствующее поле OPQ присутствует.
Подзапись EGTS_SR_SIGNATURE
Подзапись EGTS_SR_SIGNATURE, структура которой приведена в таблице И.20, предназначена для предоставления информации о коде аутентификации передаваемых массивов данных.
Таблица И.20
Описание полей:
VER - версия формата блока информации о коде аутентификации (значение для поля VER должно быть установлено в 0);
SA - число структур с массивами данных, соответствующих коду аутентификации. Может быть от одной и более, в зависимости от требуемой схемы подписания массива данных;
ASD1...ASD255 - структуры, содержащие информацию о коде аутентификации одного массива.
Состав структуры ASD приведен в таблице И.21.
Таблица И.21
Описание полей:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
B#H (Block Number High Bit) - старшие 2 бита порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
KEY# - номер ключа из массива ключей, доступных ACH, с помощью которого сформирован код аутентификации данного блока данных. В данной версии ACH поддерживает один ключ.
Примечание - Рекомендуемое значение для включения в поле KEY# должно выбираться исходя из условия, что ACH поддерживает один ключ;
ALGID - идентификатор алгоритма генерации кода аутентификации.
Примечание - Рекомендуемое значение для включения в поле ALGID - 0x8034;
SLNL, SLNH - младшие 8 бит и старшие 6 бит значения длины данных кода аутентификации;
SD - данные кода аутентификации массива данных.
Примечания
1 Если требуется определение кода аутентификации всего массива мониторинговой информации, перед вычислением кода аутентификации указанный массив информации объединяется без выравнивания содержимого всех сервисных подзаписей (их полезной нагрузки - поля SDR (Subrecord Data)) в следующем порядке:
- подзапись EGTS_SR_EP_MAIN_DATA;
- подзаписи EGTS_SR_EP_TRACK_DATA, если передаются;
- подзаписи EGTS_SR_EP_ACCEL_DATA, EGTS_SR_EP_TRACK_DATA2, EGTS_SR_EP_TRACK_DATA3, если передаются;
- подзаписи EGTS_SR_EP_RAW_DATA, если передаются.
2 Информация подзаписей о траектории движения ТС упорядочивается по времени в порядке возрастания.
3 Информация подзаписей о профиле ускорения упорядочивается по времени без учета типа подзаписи.
4 Информация подзаписей о первичных навигационных данных упорядочивается по времени в порядке возрастания.
5 Сформированный массив данных используется для вычисления кода аутентификации.
6 Если требуется определение кодов аутентификации мониторинговой информации по блокам, то определение кодов аутентификации осуществляется по мере формирования блоков, при этом порядок вычисления кодов аутентификации блоков разного типа (с разными подзаписями) не имеет значения. В массив мониторинговой информации можно включить и подписать не более 1024 блоков.
Подзапись EGTS_SR_ACCEL_DATA_SIG
Структура подзаписи представлена в таблице И.22.
Таблица И.22
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.22 содержат:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
SA - число передаваемых структур данных показаний акселерометра;
ATM - время проведения измерений первой передаваемой структуры показаний акселерометра (число секунд с 00:00:00 01.01.2010 UTC);
ADS1 ... ADS255 - структуры данных показаний акселерометра, формат структуры представлен в таблице И.2. В составе подзаписи передается минимум одна структура ADS.
Таблица И.23
EGTS_SR_ACCEL_DATA_SIG сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.23 содержат:
RTM - приращение к времени измерения предыдущей записи (для первой записи приращение к полю ATM), мс;
XAAV - значение линейного ускорения по оси x (старший бит определяет знак, 1 указывает на отрицательное значение), м/с2, с дискретностью 0,1 м/с2;
YAAV - значение линейного ускорения по оси y (старший бит определяет знак, 1 указывает на отрицательное значение), м/с2, с дискретностью 0,1 м/с2;
ZAAV - значение линейного ускорения по оси z (старший бит определяет знак, 1 указывает на отрицательное значение), м/с2, с дискретностью 0,1 м/с2;
разрешающая способность полей ускорения - 0,1 м/с2 (0,01 g).
Примечания
1 Ось x направлена параллельно к продольной оси ТС. Положительное направление оси x соответствует движению вперед.
2 Ось y направлена перпендикулярно к оси x в плоскости, параллельной поверхности Земли. Положительному направлению оси y соответствует направление влево.
3 Ось z перпендикулярна к осям x и y. Положительному направлению оси z соответствует направление вверх.
Подзапись EGTS_SR_POS_DATA_SIG
Структура подзаписи представлена в таблице И.24.
Таблица И.24
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.24 содержат:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
NTM - время навигации (число секунд с 00:00:00 01.01.2010 UTC);
LAT - широта по модулю, градусы/90·0xFFFFFFFF и взята целая часть;
LONG - долгота по модулю, градусы/180·0xFFFFFFFF и взята целая часть;
FLG - определяет дополнительные параметры навигационной посылки;
ALTE - битовый флаг определяет наличие поля ALT в подзаписи:
1 - поле ALT передается,
0 - не передается;
LOHS - битовый флаг определяет полушарие долготы:
0 - восточная долгота,
1 - западная долгота;
LAHS - битовый флаг определяет полушарие широты:
0 - северная широта,
1 - южная широта;
MV - битовый флаг, признак движения:
1 - движение,
0 - ТС находится в режиме стоянки;
BB - битовый флаг, признак отправки данных из памяти ("черный ящик"):
0 - актуальные данные,
1 - данные из памяти ("черный ящик");
FIX - битовое поле, тип определения координат:
0 - 2D fix,
1 - 3D fix;
CS - битовое поле, тип используемой системы:
0 - система координат WGS-84,
1 - государственная геоцентрическая система координат (ПЗ-90.11);
VLD - битовый флаг, признак "валидности" координатных данных:
1 - данные "валидные",
0 - данные "невалидные";
SPD - скорость, км/ч, с дискретностью 0,1 км/ч (используется 14 младших бит);
ALTS (Altitude Sign) - битовый флаг, определяет высоту относительно уровня моря и имеет смысл только при установленном флаге ALTE:
0 - точка выше уровня моря,
1 - ниже уровня моря;
DIRH (Direction the Highest bit) - старший бит (8) параметра DIR;
DIR - направление движения. Определяется как угол в градусах, который отсчитывается по часовой стрелке между северным направлением географического меридиана и направлением движения в точке измерения (дополнительно старший бит находится в поле DIRH);
ODM - пройденное расстояние (пробег), км, с дискретностью 0,1 км;
DIN - битовые флаги, определяют состояние основных дискретных входов 1...8 (если бит равен 1, то соответствующий вход активен, если 0, то неактивен). Данное поле включено для удобства использования и экономии трафика при работе в системах мониторинга транспорта базового уровня;
SRC - определяет источник (событие), инициировавший посылку данной навигационной информации, информация представлена в таблице И.4 подзаписи EGTS_SR_POS_DATA;
NID - идентификатор базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент. Используются 20 младших бит (MCC+MNC). Структура поля NID представлена в таблице И.25;
Таблица И.25
LAC - идентификатор локальной зоны базовой станции сети ПРСТ, наблюдаемой УСВ на текущий момент;
CID - идентификатор ячейки базовой станции сети подвижной радиотелефонной связи, наблюдаемой УСВ на текущий момент;
SS (Signal Strength) - модуль уровня силы сигнала данной базовой станции сети подвижной радиотелефонной связи, дБм. Например, значение "80" соответствует уровню сигнала "минус 80 дБм";
ALT - высота над уровнем моря, м (опциональный параметр, наличие которого определяется битовым флагом ALTE);
SRCD - данные, характеризующие источник (событие) из поля SRC. Наличие и интерпретация значения данного поля определяется полем SRC.
Подзапись EGTS_SR_EXT_POS_DATA_SIG
Структура подзаписи представлена в таблице И.26.
Таблица И.26
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.26 содержат:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
NSFE (Navigation System Field Exists) - определяет наличие данных о типах используемых навигационных спутниковых систем:
1 - поле NS передается,
0 - не передается.
SFE (Satellites Field Exists) - определяет наличие данных о текущем количестве видимых спутников SAT и типе используемой навигационной спутниковой системы NS:
1 - поля SAT и NS передаются,
0 - не передаются;
PFE (PDOP Field Exists) - определяет наличие поля PDOP:
1 - поле PDOP передается,
0 - не передается;
HFE (HDOP Field Exists) - определяет наличие поля HDOP:
1 - поле HDOP передается,
0 - не передается;
VFE (VDOP Field Exists) - определяет наличие поля VDOP:
1 - поле VDOP передается,
0 - не передается;
VDOP - снижение точности в вертикальной плоскости (значение, умноженное на 100);
HDOP - снижение точности в горизонтальной плоскости (значение, умноженное на 100);
PDOP - снижение точности по местоположению (значение, умноженное на 100);
SAT - число видимых спутников;
NS - битовые флаги, характеризующие используемые навигационные спутниковые системы. Определены следующие значения (десятичные) флагов:
0 - система не определена,
1 - ГЛОНАСС,
2 - GPS,
4 - Galileo,
8 - Compass,
16 - Beidou (BDS),
32 - DORIS,
64 - IRNSS,
128 - QZSS.
Остальные значения зарезервированы.
Подзапись EGTS_SR_WEIGHT_CONTROL
Подзапись EGTS_SR_WEIGHT_CONTROL используется для передачи данных от систем мониторинга осевой нагрузки (данных от датчиков нагрузки на оси) ТС и аналогичных.
Структура подзаписи представлена в таблице И.27.
Таблица И.27
сервиса EGTS_TELEDATA_SERVICE
Поля таблицы И.27 содержат:
TWM - время измерения (определения) передаваемых значений (число секунд с 00:00:00 01.01.2010 UTC);
MTTW - технически допустимая максимальная масса тягача, кг;
MRTW - технически допустимая максимальная масса прицепа, кг;
AXC - конфигурация осей ТС (автопоезда).
Значение конфигурации осей ТС (автопоезда) формируют исходя из максимального количества осей автомобиля-тягача, равного 6, и максимального количества осей прицепа (полуприцепа), равного 7.
Для информации о каждой оси выделяется 2 бита. Последние 6 бит не используют. Два бита, выделенные для каждой оси, могут содержать следующие значения:
- комбинация "00" означает, что для данной оси ТС (автопоезда) отсутствует возможность измерения массы, приходящейся на эту ось;
- комбинация "01" означает, что данная ось ТС (автопоезда) отсутствует;
- комбинация "10" означает, что для данной оси ТС (автопоезда) имеется возможность измерения массы, приходящейся на эту ось, и соответствующее значение записано в элементе передаваемых данных AXW;
- комбинация "11" не используется.
Структура передаваемых данных представлена в таблице И.28.
Таблица И.28
о конфигурации осей ТС (автопоезда)
AXW - данные о нагрузках на оси, кг.
Для передачи значения массы, приходящейся на каждую ось, выделяют по 4 байта. Значениям "00" и "01" в конфигурации осей ТС (автопоезда) (см. поле AXC) для соответствующей оси должно соответствовать значение "0". Последовательность данных значений массы, приходящейся на каждую ось, соответствует указанной в таблице И.28;
SCE (SMON Communication Errors) - битовый признак наличия ошибок передачи данных от УСВ (системы мониторинга осевой нагрузки) в течение последних 30 суток:
1 - ошибки имелись,
0 - ошибки отсутствуют;
SE (SMON Errors) - битовый признак наличия ошибок обработки данных о нагрузке на ось ТС в УСВ (системе мониторинга осевой нагрузки) в течение последних 30 суток:
1 - ошибки имелись,
0 - ошибки отсутствуют;
SBA (Security Breach Attempt) - битовый признак наличия попыток нарушения работы системы мониторинга осевой нагрузки (компонентов, осуществляющих сбор и обработку информации о нагрузках на оси ТС) в течение последних 2 лет:
1 - попытки зафиксированы,
0 - попытки не зафиксированы;
LAE - битовый флаг определяет наличие поля LAT в подзаписи:
1 - поле LAT передается,
0 - поле LAT не передается;
LOE - битовый флаг определяет наличие поля LONG в подзаписи:
1 - поле LONG передается,
0 - поле LONG не передается;
PWM - погрешность определения данных о нагрузке на ось, %;
LAT - широта местоположения ТС по модулю в момент измерения нагрузки на оси, градусы/90·0xFFFFFFFF и взята целая часть;
LONG - долгота по модулю в момент измерения нагрузки на оси, градусы/180·0xFFFFFFFF и взята целая часть;
ALTE (Altitude enable) - битовый флаг определяет наличие поля ALT в подзаписи:
1 - поле ALT передается,
0 - не передается;
LOHS - битовый флаг определяет полушарие долготы:
0 - восточная долгота,
1 - западная долгота;
LAHS - битовый флаг определяет полушарие широты:
0 - северная широта,
1 - южная широта;
ALTS (Altitude Sign) - битовый флаг, определяет высоту относительно уровня моря и имеет смысл только при установленном флаге ALTE:
0 - точка выше уровня моря,
1 - ниже уровня моря;
ALT - высота над уровнем моря в момент измерения нагрузки на оси, м (опциональный параметр, наличие которого определяется битовым флагом ALTE);
DTE - битовый флаг определяет наличие поля DT в подзаписи:
1 - поле DT передается,
0 - поле DT не передается;
DT - тип измерительного устройства. Определены следующие значения:
0 - тип не определен,
1 - тензодатчик,
2 - линейного перемещения с вертикальным ходом плеча и потенциометрического типа,
3 - акселерометры (инклиномеры).
Значения 4 - 255 - зарезервированы для дальнейшего использования.
Использование EGTS_COMMANDS_SERVICE для реализации услуги EGTS_TELEDATA_SERVICE
Список и описание команд, подтверждений на команды, а также список параметров УСВ, необходимых для реализации услуги EGTS_TELEDATA_SERVICE, представлены в таблицах (см. таблицу И.29, таблицу И.30 и таблицу И.31 соответственно).
Таблица И.29
Таблица И.30
Таблица И.31
(обязательное)
СООБЩЕНИЙ И ОПОВЕЩЕНИЙ EGTS_NOTIFICATION_SERVICE
Состав сервиса EGTS_NOTIFICATION_SERVICE
Сервис EGTS_NOTIFICATION_SERVICE предназначен для передачи на УСВ сообщений и оповещений от телематических систем (аппаратно-программных комплексов).
Для осуществления взаимодействия в рамках сервиса EGTS_NOTIFICATION_SERVICE используется несколько подзаписей, описание и код которых представлены в таблице К.1.
Таблица К.1
Подзапись EGTS_SR_RECORD_RESPONSE
Данная подзапись имеет такую же структуру, как описано в 6.7.2.1, и применяется для подтверждения получения и обработки подзаписей сервиса. При этом на УСВ при успешном приеме и обработке должна передаваться подзапись EGTS_SR_RECORD_RESPONSE, содержащая код EGTS_PC_OK, или иная в соответствии с итогом обработки в соответствии с приложением В (Таблица В.1).
Подзапись EGTS_SR__NOTIFICATION_FORMDATA
Подзапись EGTS_SR__NOTIFICATION_FORMDATA предназначена для передачи на УСВ для сохранения/обновления/замены в энергонезависимой памяти данных предзаписываемых формализованных сообщений.
Структура подзаписи представлена в таблице К.2.
Таблица К.2
сервиса EGTS_NOTIFICATION_SERVICE
В таблице К.2 параметры (поля) имеют следующие назначения:
- NI - уникальный идентификатор формализованного сообщения/уведомления. Зарезервированные коды формализованных сообщений приведены в таблицах К.3 и К.4. Указанные в таблицах К.3 и К.4 сообщения должны быть предзаписаны в энергонезависимой памяти УСВ при его настройке без возможности изменения;
- ND - данные формализованного сообщения/уведомления.
Таблица К.3
формализованных сообщений
Таблица К.4
для водителя и пассажиров при функционировании УСВ
Подзапись EGTS_SR_NOTIFICATION_DATA
Подзапись EGTS_SR_NOTIFICATION_DATA предназначена для передачи на УСВ формализованных сообщений. Структура подзаписи представлена в таблице К.5.
Таблица К.5
сервиса EGTS_NOTIFICATION_SERVICE
В таблице К.5 параметры (поля) имеют следующие назначения:
- NC - число сообщений/уведомлений, передаваемых в подзаписи, предназначенных для совместного последовательного воспроизведения;
- NI - массив уникальных идентификаторов формализованных сообщений/уведомлений, сохраненных в энергонезависимой памяти УСВ при его настройке или загруженных в УСВ с использованием подзаписи EGTS_SR_NOTIFICATION_FORMDATA.
При отправке на УСВ сообщений и уведомлений рекомендуется отправка сообщений с использованием массива NI, содержащего 4 идентификатора сообщений, предназначенных для совместного воспроизведения:
- тип оповещения (коды 0x0001 - 0x0012 по таблице К.3);
- содержание оповещения (коды 0x0065 - 0x006C по таблице К.3);
- расстояние до объекта оповещения (коды 0x00C9 - 0x00CD по таблице К.3);
- уточнение по времени актуальности оповещения (коды 0x012D - 0x0130 по таблице К.3);
- NM - битовый флаг, который определяет обязательность воспроизведения сообщения на УСВ (десятичное):
0 - воспроизведение после подтверждения со стороны пользователя,
1 - сообщение обязательно для воспроизведения (автоматическое воспроизведение без подтверждения со стороны пользователя),
2 - воспроизведение сообщения в зависимости от настроек УСВ,
3 - воспроизведение сообщения по запросу пользователя;
- NE - срок хранения оповещения, часы;
- NRC - число повторений сообщения;
- NRP - период повторения сообщения, минуты.
Подзапись EGTS_SR_NOTIFICATION_PART_DATA
Подзапись EGTS_SR_NOTIFICATION_PART_DATA предназначена для передачи неформализованных сообщений больших размеров частями на УСВ для воспроизведения. Структура подзаписи представлена в таблице К.6
Таблица К.6
сервиса EGTS_NOTIFICATION_SERVICE
Параметр EPQ содержит число частей, которое будет передано, а параметр PN - номер текущей части. Поле NID однозначно определяет сущность, которой принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть не более значения из поля EPQ. Если данное условие нарушается, то данные из такой подзаписи игнорируются.
Идентификатор объекта NID, поля PN и EPQ, а также идентификатор источника записи OID из заголовка уровня маршрутизации сервисов позволяют определить, какая часть и какого сообщения/уведомления получена для обработки. Это позволяет при достаточной пропускной способности канала одновременно передавать несколько сообщений/уведомлений. Формат заголовка представлен в таблице К.7.
Таблица К.7
подзаписи EGTS_SR_NOTIFICATION_PART_DATA
сервиса EGTS_NOTIFICATION_SERVICE
В таблице К.7 параметры (поля) имеют следующие назначения:
- NF - код формата передаваемого аудиофайла сообщения/уведомления может принимать следующие значения:
01 - WAV,
02 - AIFF,
03 - APE,
04 - FLAC,
05 - MP3,
06 - OGG,
07 - иное, определяется УСВ на основании данных передаваемого файла;
- WOS - сигнатура (контрольная сумма) передаваемого сообщения/уведомления. Используется алгоритм CRC16-CCITT;
- FN - имя передаваемого файла (данное поле опционально и может иметь нулевую длину).
Подзапись EGTS_SR_NOTIFICATION_FULL_DATA
Подзапись EGTS_SR_NOTIFICATION_FULL_DATA предназначена для передачи неформализованных сообщений и уведомлений, которые не разбиваются на части, а передаются одним пакетом. Структура подзаписи представлена в таблице К.8.
Таблица К.8
сервиса EGTS_NOTIFICATION_SERVICE
В таблице К.8 параметры (поля) имеют следующие назначения:
- NDHL - длина заголовка в байтах;
- NDH - заголовок, содержащий параметры сообщения. Формат заголовка приведен в таблице К.7. Для подзаписи EGTS_SR_NOTIFICATION_FULL_DATA параметр NDH является обязательным и присутствует в каждой такой подзаписи;
- NM - признак, который определяет обязательность воспроизведения сообщения на УСВ, имеет следующие значения (десятичные):
0 - воспроизведение после подтверждения со стороны пользователя,
1 - сообщение обязательно для воспроизведения (автоматическое воспроизведение без подтверждения со стороны пользователя),
2 - воспроизведение сообщения в зависимости от настроек УСВ,
3 - воспроизведение сообщения по запросу пользователя;
- NE - срок хранения оповещения, часы;
- NRC - число повторений сообщения;
- NRP - период повторения сообщения, минуты;
- ND - данные передаваемого сообщения/уведомления.
(обязательное)
SUPL (Secure User Plane Location)
Технология поддержки потребителей А-ГНСС (Assisted GNSS) имеет различные реализации и уровни сервисов. Для передачи ассистирующей информации используется универсальный стандартизированный протокол SUPL.
SUPL (Secure User Plane Location) - это защищенный протокол определения местоположения пользователей, представляет собой эффективный способ передачи информации о местоположении, необходимой для расчета местоположения мобильной станции. Данный протокол использует канал передачи данных пользователя для передачи оперативной ассистирующей информации о местоположении. Персонифицирующей информацией является IP-адрес, с которого выполняется запрос на SUPL сервер. Мобильному устройству присваивается индивидуальный IP-адрес, который сопоставляется с общедоступным, с которого происходит запрос. Общедоступный IP-адрес используется совместно с другими пользователями. Таким образом, сетевой оператор может определить пользователя, который инициировал запрос, а у SUPL сервера такой возможности нет.
Для реализации on-line режима А-ГНСС на SUPL сервер требуется передать единичную информацию о примерном местоположении терминала. SUPL сервер получает информацию об идентификаторе базовой станции связи, так называемой Cell ID, в пределах которой обслуживается абонент, текущий идентификатор сотовой сети (MCC) и идентификатор используемой ячейки (MNC). Местоположение базовой станции связи доступно при помощи базы данных Cell ID операторов связи. Данные о месте ячейки, сети и Cell ID являются достаточным для формирования ассистирующей информации, которая возвращается абоненту по установленному соединению и подается в навигационный приемник.
Технология А-ГНСС позволяет навигационному приемнику получить по сетям связи ассистирующую информацию:
- эфемериды спутников;
- время;
- доплеровский сдвиг;
- первую производную доплеровского сдвига;
- список видимых спутников;
- возвышение и азимут спутника;
- альманах;
- приблизительное расположение абонента;
- оценку кодовой задержки;
- расширенные эфемериды;
- параметры ионосферной модели;
- временной сдвиг между временем GPS и UTC;
- временной сдвиг между различными ГНСС и GPS;
- сообщение целостности из навигационного кадра.
Благодаря этой информации сокращается время формирования первого решения до нескольких секунд. Точный состав информации, способ обмена данными и протоколы передачи описываются рядом стандартов 3GPP и OMA. Один из наиболее распространенных протоколов - OMA SUPL, он используется большинством современных смартфонов для получения A-GNSS данных через сеть Интернет.
В информационной системе определения местоположения сеть с определением местоположения через протокол SUPL включает в себя:
- исполнительное устройство определения местоположения (далее - Агент SUPL);
- домашнюю платформу определения местоположения с использованием SUPL (далее - платформа H-SLP);
- терминал с поддержкой определения местоположения защищенной пользовательской плоскости (SUPL Enabled Terminal, далее SET).
Агент SUPL представляет собой логическую точку доступа к услуге, используя информацию об измерении действительного местоположения.
Платформа H-SLP является компонентом в сети доступа к услуге определения местоположения посредством SUPL, предназначенным для доступа к сетевым ресурсам с целью получения информации о местоположении.
SET представляет собой устройство, способное взаимодействовать с мобильной сетью с возможностью определения местоположения с использованием интерфейса SUPL. Например, SET может представлять собой пользовательский терминал универсальной мобильной телекоммуникационной системы (UMTS), мобильную станцию системы GSM, мобильную систему системы стандарта IS-95 или смартфон. SET может представлять собой различные мобильные терминалы, подключенные к широкополосной локальной вычислительной сети (ЛВС/WLAN). SET поддерживает различные процедуры, определенные протоколом SUPL путем взаимодействия с сетью по каналу передачи данных.
Пример обмена сообщениями по протоколу SUPL приведен на рисунке Л.1.
![]() A. Агент SUPL на SET получает запрос позиции от приложения, работающего на SET. SET устанавливает безопасное соединение с H-SLP.
B. SET отправляет сообщение ULP SUPL START, чтобы начать сеанс SUPL с H-SLP. Сообщение ULP SUPL START содержит возможности SET и идентификатор местоположения.
C. H-SLP отвечает сообщением ULP SUPL RESPONSE на SET. Сообщение содержит запрошенный метод позиционирования. Он также может содержать информацию о местоположении, которая не соответствует QoP, запрошенному агентом SUPL, но дает приблизительную оценку местоположения на основе информации, полученной в сообщении ULP SUPL START.
D. SET отправляет сообщение ULP SUPL POS INIT, чтобы начать сеанс позиционирования с H-SLP. Сообщение содержит возможности SET и идентификатор местоположения.
E. H-SLP определяет метод позиционирования и обменивается несколькими последовательными сообщениями ULP SUPL POS, содержащими используемый протокол позиционирования (например, RRLP, RRC, TIA-801), необходимый для определения позиции.
F. Когда вычисление местоположения завершено, H-SLP отправляет сообщение ULP SUPL END на SET, информируя его, что сессия SUPL завершена. Затем SET завершает безопасное соединение с H-SLP.
Л.1 Сообщения ULP
Параметры сообщений ULP
Все сообщения, определенные в ULP, содержат общую часть и дополнительную часть.
Общая часть сообщения присутствует во всех сообщениях ULP. Список параметров, содержащихся с общей части сообщения ULP, представлен в таблице Л.1.
Таблица Л.1
Описание поля Версии протокола SUPL (Version) приведено в таблице Л.2.
Таблица Л.2
Описание поля Уникальный идентификатор сеанса (Session ID) приведено в таблице Л.3.
Таблица Л.3
Л.2 Дополнительная часть сообщения
Дополнительная часть сообщения содержит дополнительные параметры, уникальные для каждого сообщения ULP. Следующие подразделы описывают специфичную для сообщения часть сообщений ULP.
Начальное сообщение SUPL START
Начальное сообщение SUPL START от SET к SLP имеет следующие параметры, представленные в таблице Л.4.
Таблица Л.4
Значения поля SET capabilities представлены в таблице Л.5.
Таблица Л.5
Значения поля уникального идентификатора ячейки самой последней обслуживающей соты Location ID представлены в таблице Л.6.
Таблица Л.6
Значения GSM Cell Info приведены в таблице Л.7.
Таблица Л.7
Значения QoP приведены в таблице Л.8.
Таблица Л.8
Л.3 Сообщение SUPL RESPONSE
Сообщение SUPL RESPONSE является ответом на SUPL START. Значения параметров SUPL RESPONSE приведены в таблице Л.9.
Таблица Л.9
Л.4 SUPL POS INIT
Сообщение SUPL POS INIT посылается после сообщения SUPL INIT, когда сеть провайдера является инициатором вызова сервиса, и после сообщения SUPL RESPONSE, когда инициатором является SET. Значения параметров сообщения SUPL POS INIT приведены в таблице Л.10.
Таблица Л.10
Значения параметров Position представлены в таблице Л.11.
Таблица Л.11
Значения Requested Assistance Data для методов определения местоположения A-GPS приведены в таблице Л.12.
Таблица Л.12
Значения Requested Assistance Data описывают запрошенные вспомогательные данные A-GPS:
- альманах;
- время UTC;
- параметры ионосферной модели;
- доплеровский сдвиг;
- приблизительное расположение абонента;
- временной сдвиг между различными ГНСС и GPS;
- оценка кодовой задержки;
- сообщение целостности из навигационного кадра;
- список видимых спутников.
Л.5 SUPL POS
Сообщение SUPL POS передает упакованные данные в формате TIA-801, RRLP, RRC или LPP/LPPe и может содержать дополнительно скорость, помощь по опорному времени UTRAN GPS/GANSS или результат опорного времени UTRAN GPS/GANSS. Значения параметров сообщения SUPL POS приведены в таблице Л.13.
Таблица Л.13
Л.6 Сообщение SUPL END
Сообщение SUPL END заканчивает сеанс SUPL при нормальном окончании или ошибке. Значение параметров SUPL END представлено в таблице Л.14.
Таблица Л.14
Значения параметра Status Code представлены в таблице Л.15.
Таблица Л.15
Л.7 Описание обмена сообщениями при сеансе связи (пример)
Вернуться в "Каталог нормативных документов"
Источник информации: https://internet-law.ru/documents/dop_documents/12/gost_39625/0/gost_98495.html
На правах рекламы:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||