ГОСТ 33465-2023
МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ
Глобальная навигационная спутниковая система
СИСТЕМА ЭКСТРЕННОГО РЕАГИРОВАНИЯ ПРИ АВАРИЯХ
Протоколы обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях
Global navigation satellite system. Road accident emergency response system. Data exchange protocols between in-vehicle emergency call device/system and emergency response system infrastructure
МКС 33.020
Дата введения 2024-06-01
с правом досрочного применения
Предисловие
Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены"
Сведения о стандарте
1 РАЗРАБОТАН Акционерным обществом "ГЛОНАСС" (АО "ГЛОНАСС")
2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии
3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 31 августа 2023 г. N 164-П)
За принятие проголосовали:
Краткое наименование страны по МК (ИСО 3166) 004-97 | Код страны по МК (ИСО 3166) 004-97 | Сокращенное наименование национального органа по стандартизации |
Армения | AM | ЗАО "Национальный орган по стандартизации и метрологии" Республики Армения
|
Беларусь | BY | Госстандарт Республики Беларусь
|
Киргизия | KG | Кыргызстандарт
|
Россия | RU | Росстандарт
|
Таджикистан | TJ | Таджикстандарт
|
Узбекистан | UZ | Узстандарт |
4 Приказом Федерального агентства по техническому регулированию и метрологии от 18 октября 2023 г. N 1183-ст межгосударственный стандарт ГОСТ 33465-2023 введен в действие в качестве национального стандарта Российской Федерации с 1 июня 2024 г. с правом досрочного применения
5 ВЗАМЕН ГОСТ 33465-2015
Информация о введении в действие (прекращении действия) настоящего стандарта и изменений к нему на территории указанных выше государств публикуется в указателях национальных стандартов, издаваемых в этих государствах, а также в сети Интернет на сайтах соответствующих национальных органов по стандартизации.
В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном Интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге "Межгосударственные стандарты"
1 Область применения
Настоящий стандарт распространяется на устройства вызова экстренных оперативных служб, предназначенные для установки на колесные транспортные средства категорий M и N, а также на системы вызова экстренных оперативных служб, установленные на транспортные средства категорий M и N в соответствии с требованиями [1].
Настоящий стандарт устанавливает требования к протоколам обмена данными между устройством/системой вызова экстренных оперативных служб и инфраструктурой системы экстренного реагирования при авариях (далее - система), включая требования, связанные с предоставлением системой базовой услуги в целях выполнения требований [1] и ГОСТ 33464, а также требования к протоколам обмена данными при выполнении устройством/системой вызова экстренных оперативных служб функций мониторинга транспортного средства и определения, регистрации и передачи информации об обстоятельствах дорожно-транспортного происшествия.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:
ГОСТ 33464-2023 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Устройство/система вызова экстренных оперативных служб. Общие технические требования
ГОСТ 33472-2023 Глобальная навигационная спутниковая система. Аппаратура спутниковой навигации для оснащения колесных транспортных средств. Общие технические требования.
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации (www.easc.by) или по указателям национальных стандартов, издаваемым в государствах, указанных в предисловии, или на официальных сайтах соответствующих национальных органов по стандартизации. Если на документ дана недатированная ссылка, то следует использовать документ, действующий на текущий момент, с учетом всех внесенных в него изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то следует использовать указанную версию этого документа. Если после принятия настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение применяется без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.
3 Термины, определения, сокращения и обозначения
3.1 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1.1
ключ: Изменяемый параметр в виде последовательности символов, определяющий криптографическое преобразование.
[ГОСТ 34.12-2018, пункт 2.1.8] |
3.1.2
код аутентичности; имитовставка: Строка бит фиксированной длины, полученная применением симметричного криптографического метода к сообщению, добавляемая к сообщению для обеспечения его целостности и аутентификации источника данных.
[ГОСТ 33464-2023, пункт 3.1.12] |
3.1.3
минимальный набор данных; МНД: Набор данных, передаваемый УСВ при дорожно-транспортном происшествии и включающий в себя информацию о координатах и параметрах движения аварийного транспортного средства и времени аварии, VIN-коде транспортного средства и другую информацию, необходимую для экстренного реагирования.
[ГОСТ 33464-2023, пункт 3.1.14] |
3.1.4
некорректируемость (информации): Состояние защищенности информации, формируемой и обрабатываемой УСВ, от несанкционированного изменения в процессе хранения, обработки и передачи.
[ГОСТ 33464-2023, пункт 3.1.17] |
3.1.5
оператор системы (экстренного реагирования при авариях): Юридическое лицо, осуществляющее деятельность по эксплуатации системы экстренного реагирования при авариях, в том числе по обработке информации, содержащейся в ее базе данных.
[ГОСТ 33464-2023, пункт 3.1.18] |
3.1.6 протокол передачи данных: Набор правил и соглашений, определяющих содержимое, формат, параметры времени, последовательность и проверку ошибок в сообщениях, которыми обмениваются сетевые устройства.
3.1.7 протокол уровня приложений IPv4: Протокол верхнего (4-го) уровня сетевой модели TCP/IP.
3.1.8
режим информационной поддержки навигационных определений; режим А-ГНСС: Алгоритм функционирования устройства/системы вызова экстренных оперативных служб, предусматривающий для навигационных определений на основе приема и обработки радионавигационных сигналов возможность использования дополнительной навигационной информации о текущем состоянии ГНСС в месте расположения транспортного средства (время, альманахи, эфемериды, опорные координаты), получаемой от оператора национальной системы экстренного реагирования по сетям подвижной радиотелефонной связи.
[ГОСТ 33464-2023, пункт 3.1.22] |
3.1.9 сервис: Элемент инфраструктуры телематической платформы, обеспечивающий функциональное выполнение алгоритма той или иной услуги, оказываемой системой.
3.1.10
система вызова (экстренных оперативных служб); СВ: Устройство вызова экстренных оперативных служб, установленное на транспортное средство.
[ГОСТ 33464-2023, пункт 3.1.23] |
3.1.11
система экстренного реагирования при авариях: Государственная территориально-распределенная автоматизированная информационная система, обеспечивающая оперативное получение с использованием сигналов глобальной навигационной спутниковой системы ГЛОНАСС совместно с другой действующей ГНСС информации о дорожно-транспортных происшествиях и иных чрезвычайных ситуациях на автомобильных дорогах, обработку, хранение и передачу этой информации экстренным оперативным службам, а также доступ к указанной информации заинтересованных государственных органов, органов местного самоуправления, должностных лиц, юридических и физических лиц.
Примечание - В Республике Беларусь система экстренного реагирования при авариях называется "ЭРА-РБ", в Республике Казахстан - "ЭВАК", в Российской Федерации - "ЭРА-ГЛОНАСС". Аналогом вышеуказанных систем является общеевропейская система eCall, с которой эти системы гармонизированы по основным функциональным свойствам (использование тонального модема как основного механизма передачи данных; унифицированные состав и формат обязательных данных, передаваемых в составе минимального набора данных о дорожно-транспортном происшествии, единообразные правила установления и завершения двустороннего голосового соединения с лицами, находящимися в кабине транспортного средства и др.).
[ГОСТ 33464-2023, пункт 3.1.24] |
3.1.12 сообщение: Совокупность данных, отправляемых одномоментно из телематического устройства в телематическую платформу или из телематической платформы в телематическую платформу.
3.1.13
сообщение "Отмена реагирования": Набор данных, передаваемый устройством/системой вызова экстренных оперативных служб по каналам спутниковой связи по команде водителя или пассажира транспортного средства в ситуации, когда реагирование экстренных оперативных служб после осуществления экстренного вызова не требуется.
[ГОСТ 33464-2023, пункт 3.1.27] |
3.1.14
телематическая информация: Совокупность данных, передаваемых с контролируемого транспортного средства в навигационно-информационные системы, о состоянии транспортного средства и/или установленного на нем оборудования и обстановки в нем и/или вокруг него.
Примечание - Состав данных определяется в зависимости от категории транспортного средства и функций, выполняемых устройством/системой вызова экстренных оперативных служб в рамках навигационно-информационных систем.
[ГОСТ 33464-2023, пункт 3.1.28] |
3.1.15 телематическая платформа; ТП: Техническое решение, которое взаимодействует с телематическими устройствами и другими телематическими платформами в части приема и передачи телематических данных, а также занимается их обработкой.
3.1.16 телематическое устройство; ТУ: Бортовое навигационно-коммуникационное устройство, позволяющее осуществлять экстренные вызовы, отправлять телематическую информацию или информацию о параметрах вождения ТС, а также принимать соответствующую информацию от телематических платформ.
3.1.17
устройство вызова (экстренных оперативных служб); УВ: Блок или комплекс компонентов, выполняющих следующие функции:
- прием информации или определение координат местоположения и направления движения транспортного средства с помощью сигналов не менее трех действующих глобальных навигационных спутниковых систем;
- прием и/или генерацию в автоматическом и ручном режиме инициирующих логических сигналов с запросом на операцию экстренного вызова оперативных служб;
- передачу сообщения о транспортном средстве при аварийной (экстренной) ситуации, содержащего, как минимум, минимальный набор данных (МНД);
- выдачу предупреждающего сигнала;
- обеспечение двусторонней голосовой связи с экстренными оперативными службами.
[ГОСТ 33464-2023, пункт 3.1.31] |
3.2 Сокращения и обозначения
В настоящем стандарте применены следующие сокращения и обозначения:
ГНСС | - глобальная навигационная спутниковая система;
|
А-ГНСС | - режим информационной поддержки навигационных определений;
|
АС | - автомобильная система;
|
ГЛОНАСС | - глобальная навигационная спутниковая система Российской Федерации;
|
ДТП | - дорожно-транспортное происшествие;
|
ДУЖ | - датчик уровня жидкости;
|
ОГРН | - основной государственный регистрационный номер;
|
ПЗ-90.11 | - система геодезических параметров "Параметры Земли 1990 года", используемая в ГНСС "ГЛОНАСС";
|
ПО | - программное обеспечение;
|
ППУ | - протокол уровня поддержки услуг;
|
ПТУ | - протокол транспортного уровня;
|
ПРТС | - подвижная радиотелефонная связь;
|
СПРС | - соединение ПРТС с помощью всех доступных для УСВ стандартов связи GSM/GPRS/UMTS/HSDPA/LTE и поколений 2G/3G/4G и пр.;
|
ТП | - телематическая платформа;
|
ТС | - транспортное средство;
|
УСВ | - устройство/система вызова экстренных оперативных служб;
|
Цифровая подпись | - информация в электронной форме, которая используется для идентификации отправителя данных;
|
ALACK | - подтверждение уровня приложения;
|
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 Общие положения
4.1 Сетевая модель взаимодействия открытых систем согласно [2]* определяет следующие уровни обмена данными:
- физический;
- канальный;
- сетевой;
- транспортный;
- сеансовый;
- представления данных и приложений.
4.2 В терминах сетевой модели OSI в системе экстренного реагирования при авариях для передачи данных между УСВ и оператором системы используются следующие протоколы:
- TCP - транспортный уровень;
- IP - сетевой уровень.
Соответствие сетевой модели OSI, стека протоколов TCP/IP и протоколов передачи данных системы экстренного реагирования при авариях представлено в таблице 1.
Таблица 1 - Соответствие уровней модели OSI, стека протоколов TCP/IP и протоколов системы
Модель OSI | Стек протоколов TCP/IP | Протоколы | Протоколы системы | ||
Номер уровня | Название уровня | Номер уровня | Название уровня | TCP/IP |
|
7 | Приложений | 4 | Приложений | FTP, HTTP, | Уровень поддержки услуг |
6 | Представления данных |
|
| POP3, IMAP, telnet, SMTP, |
|
5 | Сеансовый |
|
| DNS, TFTP | Транспортный уровень |
4 | Транспортный | 3 | Транспортный | TCP, UDP | TCP |
3 | Сетевой | 2 | Межсетевой | IP | IP |
2 | Канальный | 1 | Доступ к сети | - | - |
1 | Физический |
|
|
| - |
4.3 Настоящий стандарт устанавливает требования к следующим видам протоколов обмена информацией между элементами системы экстренного реагирования при авариях:
- протоколу транспортного уровня;
- протоколу уровня поддержки услуг, включая базовую услугу, оказываемую системой экстренного реагирования при авариях;
- протоколу уровня приложений;
- протоколу определения местоположения пользователей.
4.4 Настоящий стандарт также устанавливает требования к формату сообщения AL-ACK, которое высылается посредством использования тонального модема (см. [3]).
4.5 Нормативные положения настоящего стандарта, связанные с установлением требований к продолжительности временных интервалов при выполнении УСВ соответствующих функций, должны измеряться с погрешностью, не превышающей ±2% от предельных значений указанных временных интервалов.
5 Протокол транспортного уровня
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 - Состав и описание типов данных, используемых в протоколе транспортного уровня
Тип данных | Размер, байт | Диапазон значений | Описание |
BOOLEAN | 1 | TRUE-1, FALSE-0 | Логический тип, принимающий только два значения, TRUE или FALSE |
BYTE | 1 | 0 ... 255 | Целое число без знака |
USHORT | 2 | 0 ... 65535 | Целое число без знака |
UINT | 4 | 0 ... 4294967295 | Целое число без знака |
ULONG | 8 | 0... 18446744073709551615 | Целое число без знака |
SHORT | 2 | -32768... +32767 | Целое число со знаком |
INT | 4 | -2147483648 ... +2147483647 | Целое число со знаком |
FLOAT | 4 | ± 1,2 E - 38 ... 3,4 E + 38 | Дробное число со знаком (см. [4]) |
DOUBLE | 8 | ±2,2 E - 308 ... 1,7 E + 308 | Дробное число со знаком (см. [4]) |
STRING | Переменный. Размер определяется внешними параметрами или применением специального символа-терминатора (код 0x00) | - | Содержит последовательность печатных символов в кодировке по умолчанию CP-1251, если явно не указана другая кодировка (при помощи дополнительного параметра) |
BINARY | Переменный. Размер определяется внешними параметрами | - | Содержит последовательность данных типа BYTE |
ARRAYOFTYPE | Переменный. Размер определяется внешними параметрами | - | Может содержать последовательность одного из вышеуказанных типов (TYPE), кроме BINARY. Порядок следования байтов и размер каждого элемента используемого типа определяются самим типом. Экземпляры типов идут последовательно один за другим. Например: ARRAY OF STRING содержит в своем составе 10 экземпляров типа STRING, при этом размер каждого экземпляра определяется разделителем (код 0x00), который должен присутствовать между экземплярами |
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.
 |
Рисунок 1 - Состав пакета протокола транспортного уровня
5.6.1.2 Общая длина пакета протокола транспортного уровня не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCR. Такое значение максимального размера пакета позволяет более эффективно использовать каналы передачи данных, базируясь только на стандартном методе управления потоком данных, заложенном в протоколе TCP/IP (см. [3]).
Формат пакета транспортного уровня представлен в таблице 3.
Таблица 3 - Состав пакета протокола транспортного уровня
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
PRV (Protocol Version) | M | BYTE | 1 | |||||||
SKID (Security Key ID) | M | BYTE | 1 | |||||||
PRF(Prefix) | RTE | ENA | CMP | PR | M | BYTE | 1 | |||
HL (Header Length) | M | BYTE | 1 | |||||||
HE (Header Encoding) | M | BYTE | 1 | |||||||
FDL (Frame Data Length) | M | USHORT | 2 | |||||||
PID (Packet Identifier) | M | USHORT | 2 | |||||||
PT (Packet Type) | M | BYTE | 1 | |||||||
PRA (Peer Address) | O | USHORT | 2 | |||||||
RCA (Recipient Address) | O | USHORT | 2 | |||||||
TTL (Time To Live) | O | BYTE | 1 | |||||||
HCS (Header Check Sum) | M | BYTE | 1 | |||||||
SFRD (Services Frame Data) | O | BINARY | 0 ... 65517 | |||||||
SFRCS (Services Frame Data Check Sum) | O | USHORT | 0,2 | |||||||
5.6.1.3 Заголовок протокола транспортного уровня состоит из следующих параметров (полей): PRV, PRF, PR, CMP, ENA, RTE, HL, HE, FDL, PID, PT, PRA, RCA, TTL, HCS. Протокол уровня поддержки услуг представлен полем SFRD, контрольная сумма поля уровня поддержки услуг содержится в поле SFRCS.
Описание вышеуказанных параметров (полей) приведено в таблице 4.
5.6.1.4 Блок-схема алгоритма сборки пакета ПТУ при приеме представлена на рисунке 2.
5.6.1.5 Кодировка печатных символов при сборке ПТУ осуществляется с использованием таблиц, приведенных в приложении Е.
Таблица 4 - Описание параметров (полей), входящих в состав пакета протокола транспортного уровня
Обозначение параметра (поля) | Назначение параметра (поля) |
PRV | Параметр определяет версию используемой структуры заголовка и должен содержать значение 0x01. Значение данного параметра инкрементируется каждый раз при внесении изменений в структуру заголовка |
SKID | Параметр определяет идентификатор ключа, используемый при шифровании |
PRF | Параметр определяет префикс заголовка транспортного уровня и для данной версии должен содержать значение 00 |
RTE (Route) | Битовое поле определяет необходимость дальнейшей маршрутизации данного пакета на удаленную ТП, а также наличие опциональных параметров PRA, RCA, TTL, необходимых для маршрутизации данного пакета. Если поле имеет значение 1, то необходима маршрутизация и поля PRA, RCA, TTL присутствуют в пакете. Данное поле устанавливает диспетчер той ТП, на которой сгенерирован пакет, или УСВ, сгенерировавшая пакет для отправки на ТП (в случае установки в ней параметра HOME_DISPATCHER_ID, определяющего ее адрес, на который данная УСВ зарегистрирована). В случае отсутствия в УСВ параметра HOME_DISPATCHER_ID маршрутизация пакета производится по внутренним правилам диспетчера, обрабатывающего пакет |
ENA (Encryption Algorithm) | Битовое поле определяет код алгоритма, используемый для шифрования данных из поля SFRD. Если поле имеет значение 00, то данные в поле SFRD не шифруются. Состав и коды алгоритмов не определены в данной версии протокола |
CMP (Compressed) | Битовое поле определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1, то данные в поле SFRD считаются сжатыми. Алгоритм сжатия не определен в данной версии протокола |
PR (Priority) | Битовое поле определяет приоритет маршрутизации данного пакета и может принимать следующие значения:
00 - наивысший;
01 - высокий;
10 - средний;
11 - низкий.
Установка большего приоритета позволяет передавать пакеты, содержащие срочные данные, такие как, например, пакет с минимальным набором данных базовой услуги системы экстренного реагирования при авариях или данные о срабатывании сигнализации на ТС. При получении пакета диспетчер, анализируя данное поле, производит маршрутизацию пакета с более высоким приоритетом быстрее, чем пакета с низким приоритетом, тем самым достигается более оперативная обработка при наступлении критически важных событий |
HL | Длина заголовка протокола транспортного уровня в байтах с учетом байта контрольной суммы (поля HCS) |
HE | Определяет применяемый метод кодирования следующей за данным параметром части заголовка протокола транспортного уровня. Зарезервировано |
FDL | Определяет размер в байтах поля данных SFRD, содержащего информацию протокола уровня поддержки услуг |
PID | Содержит номер пакета протокола транспортного уровня, увеличивающийся на 1 на стороне отправителя при отправке каждого нового пакета. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535 следующее значение должно быть 0 |
PT | Тип пакета протокола транспортного уровня.
Поле РТ может принимать следующие значения:
0 - EGTS_PT_RESPONSE (подтверждение на протокол транспортного уровня);
1 - EGTS_PT_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг);
2 - EGTS_PT_SIGNED_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью) |
PRA | Адрес ТП, на которой данный пакет сгенерирован. Данный адрес является уникальным в рамках связной сети и используется для создания пакета-подтверждения на принимающей стороне |
RCA | Адрес ТП, для которой данный пакет предназначен. По данному адресу производится идентификация принадлежности пакета определенной ТП и его маршрутизация при использовании промежуточных ТП |
TTL | Время жизни пакета при его маршрутизации между ТП. Использование данного параметра предотвращает зацикливание пакета при ретрансляции в системах со сложной топологией адресных пунктов. Первоначально TTL устанавливается ТП, сгенерировавшей данный пакет. Значение TTL устанавливается равным максимально допустимому числу ТП между отправляющей и принимающей платформами. Значение TTL уменьшается на единицу при трансляции пакета через каждую ТП, при этом пересчитывается контрольная сумма заголовка протокола транспортного уровня. При достижении данным параметром значения 0 и при обнаружении необходимости дальнейшей маршрутизации пакета происходит уничтожение пакета и выдача подтверждения с соответствующим кодом (PC_TTLEXPIRED, см. приложение В) |
SFRCS | Контрольная сумма.
Для подсчета контрольной суммы по данным из поля SFRD используется алгоритм CRC-16-CCITT Данное поле присутствует только в том случае, если есть поле SFRD. Пример программного кода расчета CRC-16 приведен в приложении Г. |
SFRD | Структура данных, зависящая от типа пакета и содержащая информацию протокола уровня поддержки услуг |
HCS | Контрольная сумма заголовка протокола транспортного уровня (начиная с поля PRV до поля HCS, не включая последнего). Для подсчета значения поля HCS ко всем байтам указанной последовательности применяется алгоритм CRC-8. Пример программного кода расчета CRC-8 приведен в приложении Д |
5.6.2 Структуры данных в зависимости от типа пакета
В зависимости от типа пакета протокола транспортного уровня структура поля SFRD имеет различный формат.
5.6.2.1 Структура данных пакета EGTS_PT_APPDATA
Пакет данного типа предназначен для передачи одной или нескольких структур, содержащих информацию протокола уровня поддержки услуг. Структура данных поля SFRD пакета EGTS_PT_ APPDATA представлена в таблице 5.
5.6.2.2 Структура данных пакета EGTS_PT_RESPONSE
С помощью данного типа пакета осуществляется подтверждение пакета протокола транспортного уровня. Данный тип пакета содержит информацию о результате обработки данных протокола транспортного уровня, полученного ранее. Структура данных поля SFRD пакета EGTS_PT_RESPONSE представлена в таблице 6.
5.6.2.3 Структура данных пакета EGTS_PT_SIGNED_APPDATA
Пакет данного типа применяется для передачи помимо структур, содержащих информацию уровня поддержки услуг, также информацию о "цифровой подписи", идентифицирующей отправителя данного пакета. Структура данных поля SFRD пакета EGTS_PT_SIGNED_APPDATA представлена в таблице 7.
5.6.2.4 На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от УСВ на ТП или от нее на УСВ, должен быть отправлен пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA.
На рисунке 3 представлена последовательность обмена пакетами при взаимодействии УСВ и ТП.
 |
А - маршрутизация и отправка пакета на другую ТП; Б - обработка данных протокола уровня поддержки услуг
Рисунок 2 - Блок-схема алгоритма сборки пакета ПТУ при приеме
Таблица 5 - Формат поля SFRD для пакета типа EGTS_PT_APPDATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SDR 1 (Service Data Record) | O | BINARY | 9 ... 65517 | |||||||
SDR 2 | O | BINARY | 9 ... 65517 | |||||||
... | ... | ... | ... | |||||||
SDRn | O | BINARY | 9 ... 65517 | |||||||
Примечание - Структуры SDR 1, SDR 2, SDRn содержат информацию протокола уровня поддержки услуг. Таких структур в составе поля SFRD может быть одна или несколько, идущих одна за другой. Описание внутреннего состава структур представлено в разделе 6.
| ||||||||||
Таблица 6 - Формат поля SFRD для пакета типа EGTS_PT_RESPONSE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RPID (Response Packet ID) | M | USHORT | 2 | |||||||
PR (Processing Result) | M | BYTE | 1 | |||||||
SDR 1 (Service Data Record) | O | BINARY | 9 ... 65514 | |||||||
SDR 2 | O | BINARY | 9 ... 65514 | |||||||
... | ... |
|
| |||||||
SDRn | O | BINARY | 9 ... 65514 | |||||||
Примечания
1 Параметр RPID - идентификатор пакета транспортного уровня, подтверждение на который формируется.
2 Параметр PR - код результата обработки части пакета, относящейся к транспортному уровню (подсчет контрольных сумм заголовка транспортного уровня и данных уровня поддержки услуг, проверка размера пакета и т.д.). Список возможных кодов результата обработки представлен в приложении В.
3 Структуры SDR 1, SDR 2, SDRn - структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой.
| ||||||||||
Таблица 7 - Формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SIGL(Signature Length) | M | USHORT | 2 | |||||||
SIGD (Signature Data) | O | BINARY | 0 ... 512 | |||||||
SDR 1 (Service Data Record) | O | BINARY | 9 ... 65515 | |||||||
SDR 2 | O | BINARY | 9 ... 65515 | |||||||
... | ... | ... | ... | |||||||
SDRn | O | BINARY | 9 ... 65515 | |||||||
Примечания
1 Параметр SIGL - определяет длину данных "цифровой подписи" из поля SIGD.
2 Параметр SIGD - содержит непосредственно данные "цифровой подписи".
3 Структуры SDR 1, SDR 2, SDRn - структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой.
| ||||||||||
 |
Рисунок 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 - Формат SMS с использованием PDU-режима
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
SMSC_AL (SMSC Address Length) | M | 1 | |||||||
SMSC_AT (SMSC Address Type) | O | 0,1 | |||||||
SMSC_A(SMSC Address) | O | 0,6 | |||||||
TP_RP | TP_UDHI | TP_SRR | TP_VPF | TP_RD | TP_MTI | M | 1 | ||
TP_MR (MessageReference) | M | 1 | |||||||
TP_DA_L (Destination Address Length) | M | 1 | |||||||
TP_DA_T (Destination Address Type) | M | 1 | |||||||
TP_DA(Destination Address) | M | 6 | |||||||
TP_PID (Protocolldentifier) | M | 1 | |||||||
TP_DCS (Data Coding Schema) | M | 1 | |||||||
TP_VP (ValidityPeriod) | O | 0, 1, 7 | |||||||
TP_UDL (User Data Length) | M | 1 | |||||||
TP_UD (UserData) | O | 0...140 | |||||||
5.7.1.2 Описание параметров, входящих в состав SMS-сообщения в PDU-режиме, приведено ниже:
- SMSC_AL - длина полезных данных адреса SMSC в октетах;
- SMSC_AT - тип формата адреса SMSC.
Возможные значения параметров SMSC_AT представлены в таблице 9.
Таблица 9 - Формат полей TP_DA_T и SMSC_AT (тип адреса)
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Размер, байт |
1 | TON | NPI | 1 | |||||
Параметры полей TP_DA_T и SMSC_AT, приведенные в таблице 9, имеют следующие назначения:
- TON (Type Of Number) - тип номера. Параметр TON может принимать следующие значения:
а) 000 - неизвестный;
б) 001 - международный формат;
в) 010 - национальный формат;
г) 011 - специальный номер, определяемый сетью;
д) 100 - номер абонента;
е) 101 - буквенно-цифровой код (коды приведены в [5] с 7-битной кодировкой по умолчанию);
ж) 110 - укороченный;
и) 111 - зарезервировано;
- NPI (NumericPlanldentification) - тип плана нумерации (применимо для значений поля 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_VP в зависимости от значения поля TP_VPF
Значение битов | Описание | |
0 | 0 | Поле TP_VP не передается |
1 | 0 | Поле TP_VP имеет формат "относительное время" и размер 1 байт |
0 | 1 | Поле TP_VP имеет формат "расширенное время" и размер 7 байт |
1 | 1 | Поле TP_VP имеет формат "абсолютное время" и размер 7 байт |
- 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 - длина данных сообщения из поля ТР_DL_в байтах для используемой 8-битной кодировки;
- TP_UD - непосредственно передаваемые пользовательские данные. Формат данного поля, в зависимости от значения поля TP_UDHI, представлен в таблице 11.
Таблица 11 - Формат поля TP_UD
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
LUDH (Length of User Data Header) | O | 1 | |||||||
IEI "A" (Information-Element-ldentifier "A") | O | 1 | |||||||
LIE "A" (Length of Information-Element "A") | O | 1 | |||||||
IED "A" (Information-Element-Data of "A") | O | 1 ... n | |||||||
IEI "B" (Information-Element-ldentifier "B") | O | 1 | |||||||
LIE "B" (Length of Information-Element "B") | O | 1 | |||||||
IED "B" (Information-Element-Data of "B") | O | 1 ... n | |||||||
IEI "N" (Information-Element-ldentifier "N") | O | 1 | |||||||
LIE "N" (Length of Information-Element "N") | O | 1 | |||||||
IED "N" (Information-Element-Data of "N") | O | 1 ... n | |||||||
UD (User Data) | M | 1...140 | |||||||
Параметры поля 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 "В" , 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-сообщения
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Размер, байт |
CSMRN (Concatenated Short Message Reference Number) | M | 1 | |||||||
MNSM (Maximum Number of Short Messages) | M | 1 | |||||||
SNCSM (Sequence Number of Current Short Message) | M | 1 | |||||||
Примечания
1 CSMRN - номер конкатенируемого SMS-сообщения должен иметь одинаковое значение для всех частей длинного SMS-сообщения.
2 MNSM - общее количество сообщений, из которых состоит длинное SMS. Должен содержать значения в диапазоне от 1 до 255.
3 SNCSM - номер передаваемой части длинного SMS-сообщения. Инкрементируется при отправке каждой новой части длинного сообщения. Должен содержать значение в диапазоне от 1 до 255. Если значение данного поля превышает значение из поля MNSM или равно нулю, то принимающая сторона должна игнорировать весь информационный элемент.
| |||||||||
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) и ССТ (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 - Временные и количественные параметры протокола транспортного уровня
Название | Тип данных | Диапазон значений | Значение по умолчанию | Описание |
TL_RESPONSE_TO | BYTE | 0 ... 255 | 5 | Время ожидания подтверждения пакета на транспортном уровне, отсчитываемое с момента его отправки стороной, сгенерировавшей пакет, с |
TL_RESEND_ATTEMPTS | BYTE | 0 ... 255 | 3 | Число повторных попыток отправки неподтвержденного пакета |
TL_RECONNECT_TO | BYTE | 0 ... 255 | 30 | Время, по истечении которого будет осуществляться повторная попытка установления канала связи после его разрыва, с |
5.9 Передача МНД в некорректируемом виде
5.9.1 Передача МНД в некорректируемом виде с использованием тонального модема
Передаваемый с использованием тонального модема объем МНД всегда равен 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 - Структура подзаписи EGTS_SR_SIGNED_RAW_MSD_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт | |
SK# (Security Key Number) | M | SHORT | 2 | ||||||||
SD (Signature Data) | M | BINARY | 32 | ||||||||
MSD (Minimal Set of Data) | M | BINARY | 0...83 | ||||||||
Описание полей:
- SK# - Security Key Number - номер ключа, при помощи которого УВС был сформирован код аутентификации МНД;
- SD - Signature Data - массив размером 32 байта данных кода аутентификации, сформированный по алгоритму (см. [7]). Код аутентификации формируется по всем данным поля MSD;
- MSD - минимальный набор данных (полезная часть данных МНД и Optional Additional Data указаны в 5.9.1).
6 Протокол уровня поддержки услуг (общая часть)
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.
 |
Рисунок 4 - Общая структура данных уровня поддержки услуг
6.6.2 Структура отдельной записи
6.6.2.1 Состав записи
Отдельная запись ППУ состоит из заголовка записи и данных записи. Состав отдельной записи представлен на рисунке 5.
 |
Рисунок 5 - Состав отдельной записи уровня поддержки услуг
В заголовке записи находятся параметры, определяющие типы сервисов получателя и отправителя, идентификатор записи, идентификатор объекта (например, УСВ), длину передаваемых данных, а также различные флаги, определяющие наличие опциональных параметров и способ обработки.
Данные записи могут содержать одну или несколько подзаписей, определяющих типы и содержащих передаваемые данные.
6.6.2.2 Структура записи
Структура отдельной записи уровня поддержки услуг приведена в таблице 15.
Таблица 15 - Формат отдельной записи ППУ
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RL (Record Length) | M | USHORT | 2 | |||||||
RN (Record Number) | M | USHORT | 2 | |||||||
RFL (Record Flags) | M | BYTE | 1 | |||||||
SSOD | RSOD | RPP | TMFE | EVFE | OBFE |
|
|
| ||
OID (Object Identifier) | O | ULONG | 8 | |||||||
EVID (Event Identifier) | O | UINT | 4 | |||||||
TM (Time) | O | UINT | 4 | |||||||
SST (Source Service Type) | M | BYTE | 1 | |||||||
RST (Recipient Service Type) | M | BYTE | 1 | |||||||
RD (Record Data) | M | BINARY | 3... 65494 | |||||||
Параметры отдельной записи ППУ, приведенные в таблице 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) - битовое поле, определяющее наличие в данном пакете поля ТМ:
а) 1 - поле ТМ присутствует,
б) 0 - поле ТМ отсутствует;
- EVFE (Event ID Field Exists) - битовое поле, определяющее наличие в данном пакете поля EVID:
а) 1 - поле EVID присутствует,
б) 0 - поле EVID отсутствует;
- OBFE (Object ID Field Exists) - битовое поле, определяющее наличие в данном пакете поля OID:
а) 1 - поле OID присутствует,
б) 0 - поле OID отсутствует;
- OID - идентификатор объекта, сгенерировавшего данную запись или для которого данная запись предназначена (уникальный идентификатор УСВ). В случае, если запись передается УСВ в ответ на команду от ТП, для индикации того, что данные принадлежат правильному объекту и сопоставлению запроса и ответа на стороне ТП, необходимо указать тот же OID, что был принят в команде. Алгоритм такого способа использования OID представлен на рисунке 6.
 |
Рисунок 6 - Алгоритм способа использования OID
- EVID - уникальный идентификатор события. Поле EVID задает глобальный идентификатор события и применяется, когда необходимо логически связать с одним-единственным событием набор нескольких информационных сущностей, причем сами сущности могут быть разнесены как по разным информационным пакетам, так и по времени. При этом прикладное программное обеспечение имеет возможность объединить все эти сущности воедино в момент представления пользователю информации о событии. Например, если с нажатием тревожной кнопки связывается серия фотоснимков, поле EVID должно указываться в каждой сервисной записи, связанной с этим событием на протяжении передачи всех сущностей, связанных сданным событием, как бы долго ни длилась передача всего пула информации;
- TM - время формирования записи на стороне отправителя (секунды с 00:00:00 01.01.2010 UTC). Если в одном пакете транспортного уровня передаются несколько записей, относящихся к одному объекту и моменту времени, то поле метки времени TM может передаваться только в составе первой записи;
- SST - идентификатор типа сервиса-отправителя, сгенерировавшего данную запись. Например, сервис, обрабатывающий навигационные данные на стороне УСВ, сервис команд на стороне ТП и т.д.;
- RST - идентификатор тип сервиса-получателя данной записи. Например, сервис, обрабатывающий навигационные данные на стороне ТП, сервис обработки команд на стороне УСВ и т.д.;
- RD - поле, содержащее информацию, присущую определенному типу сервиса (одну или несколько подзаписей сервиса типа, указанного в поле SST или RST, в зависимости от вида передаваемой информации).
6.6.3 Общая структура подзаписей
Формат отдельной подзаписи в ППУ приведен в таблице 16.
Таблица 16 - Формат отдельной подзаписи ППУ
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SRT (Subrecord Type) | M | BYTE | 1 | |||||||
SRL (Subrecord Length) | M | USHORT | 2 | |||||||
SRD (Subrecord Data) | O | BINARY | 0... 65495 | |||||||
Примечания
1 SRT - тип подзаписи (подтип передаваемых данных в рамках общего набора типов одного сервиса). Тип 0 - специальный, зарезервирован за подзаписью подтверждения данных для каждого сервиса. Конкретные значения номеров типов подзаписей определяются логикой самого сервиса. Протокол оговаривает лишь то, что этот номер должен присутствовать, а нулевой идентификатор зарезервирован.
2 SRL - длина данных в байтах подзаписи в поле SRD;
3 SRD - данные подзаписи. Наполнение данного поля специфично для каждого сочетания идентификатора сервиса и типа подзаписи.
| ||||||||||
6.6.4 На каждую информационную запись уровня поддержки услуг должно быть отправлено подтверждение, которое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки. Диаграмма, поясняющая работу механизма подтверждений при обмене сообщениями на уровне поддержки услуг, представлена на рисунке 7.
 |
Рисунок 7 - Диаграмма обмена сообщениями
Каждое сообщение ППУ содержит в себе заголовок и контрольную сумму транспортного уровня и одну или несколько записей уровня поддержки услуг. Причем в одном сообщении могут содержаться как информационные записи, так и подтверждения на ранее принятые записи.
6.7 Описание сервисов предоставления услуг
6.7.1 Список поддерживаемых ППУ сервисов предоставления услуг, их идентификаторы в десятичном виде, а также описание представлены в таблице 17.
Код сервиса, указанный в таблице 17, приводится в заголовке записи ППУ (поля SST и RST).
Взаимодействие УСВ с сервером оператора национальной системы экстренного реагирования при авариях для получения ассистирующей информации, необходимой для расчета местоположения, осуществляется по протоколу SUPL, описание которого приведено в приложении Л.
6.7.2 Сервис EGTS_AUTH_SERVICE
Сервис EGTS_AUTH_SERVICE применяется для осуществления процедуры аутентификации УСВ на стороне ТП, а также получения учетных данных УСВ и информации об инфраструктуре на стороне УСВ (состав и версии программного обеспечения модулей, блоков, периферийного оборудования, информации о ТС). Сервис должен использоваться УСВ только в случае работы по протоколу TCP/IP после создания каждого нового соединения с ТП.
Таблица 17 - Список сервисов, поддерживаемых ППУ
Код | Название | Описание | Варианты конфигурации УСВ | Спецификация | ||
|
|
| ДО  | ШСЭ  | ШСД  | сервиса |
1 | EGTS_AUTH_ SERVICE | Данный тип сервиса применяется для осуществления процедуры аутентификации УСВ на ТП.
При использовании TCP/IP протокола УСВ он должен проходить данную процедуру, и только после успешного завершения данной процедуры происходит дальнейшее взаимодействие | + | + | + | 6.7.2 |
2 | EGTS_TELEDATA_ SERVICE | Сервис предназначен для обработки телематической информации (координатные данные, данные о срабатывании датчиков и т.д.), поступающей от УСВ | + | + | + | Приложение И |
4 | EGTS_COMMANDS_ SERVICE | Данный тип сервиса предназначен для обработки управляющих и конфигурационных команд, информационных сообщений и статусов, передаваемых между УСВ, ТП и операторами | + | + | + | 6.7.3 |
9 | EGTS_FIRMWARE_ SERVICE | Сервис предназначен для передачи на УСВ конфигурации и непосредственно самого программного обеспечения аппаратной части самого УСВ, а также различного периферийного оборудования, подключенного к УСВ и поддерживающего возможность удаленного обновления программного обеспечения | + | + | + | 6.7.4 |
10 | EGTS_ECALL_ SERVICE | Сервис, обеспечивающий выполнение функционала ЭРА. Сервис описан в разделе 7 | + | + | + | 7.3 |
11 | EGTS_SR_ TACHOGRAPH | Сервис, обеспечивающий передачу данных тахографического контроля | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
21 | EGTS_FARE_ SERVICE | Сервис, обеспечивающий выполнение функций контроля и оплаты проезда в пассажирском транспорте | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
22 | EGTS_ EUROPROTOCOL_ SERVICE | Сервис, предназначенный для определения, регистрации и передачи информации об обстоятельствах ДТП | + | - | + | 9 |
23 | EGTS_TELEDATA_ OPTIONAL_SERVICE | Сервис, обеспечивающий выполнение расширенных функций контроля за работой дополнительного оборудования ТС | + | " | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
24 | EGTS_CAR_ CONDITION_ SERVICE | Сервис, обеспечивающий выполнение функций контроля за состоянием и работой ТС | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
25 | EGTS_CARGO_ SERVICE | Сервис, обеспечивающий выполнение функций транспортной логистики | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
26 | EGTS_TOLL_ SERVICE | Сервис, обеспечивающий выполнение функций контроля за проездом по платным дорогам | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
27 | EGTS_AUTOPILOT_ SERVICE | Сервис, обеспечивающий выполнение функций автопилотирования ТС | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
28 | EGTS_ DISPATCHING_ SERVICE | Сервис, обеспечивающий выполнение функций диспетчерского управления пассажирским транспортом | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
29 | EGTS_GSM_ SERVICE | Сервис, обеспечивающий выполнение функций передачи данных состояния GSM-сети | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
30 | EGTS_RFID_ SERVICE | Сервис, обеспечивающий выполнение функций передачи данных считывания RFID меток | + | - | + | Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
40 | EGTS_ NOTIFICATION_ SERVICE | Сервис передачи на бортовое оборудование сообщений и оповещений | + | - | + | Приложение К |
УСВ, исполненная в конфигурации дополнительного оборудования. УСВ, исполненная в конфигурации штатного оборудования и предназначенная для реализации только базовой услуги системой экстренного реагирования при авариях. УСВ, исполненная в конфигурации штатного оборудования и предназначенная для реализации дополнительных, кроме базовой, услуг системой экстренного реагирования при авариях. | ||||||
Требования данного пункта стандарта распространяются только на УСВ, исполненные в конфигурации дополнительного оборудования, и не распространяются на штатные УСВ, которые поддерживают только базовую услугу реагирования при аварии.
Список подзаписей, используемых сервисом EGTS_AUTH_SERVICE, представлен в таблице 18.
Таблица 18 - Список подзаписей сервиса EGTS_AUTH_SERVICE
Код | Название | Описание |
0 | EGTS_SR_RECORD_ RESPONSE | Подзапись применяется для осуществления подтверждения процесса обработки записи протокола уровня поддержки услуг. Данный тип подзаписи должен поддерживаться всеми сервисами |
1 | EGTS_SR_TERM_ IDENTITY | Подзапись используется УСВ при запросе авторизации на ТП и содержит учетные данные УСВ |
2 | EGTS_SR_MODULE_ DATA | Подзапись предназначена для передачи на ТП информации об инфраструктуре на стороне УСВ, о составе, состоянии и параметрах блоков и модулей УСВ. Данная подзапись является опциональной, и разработчик УСВ сам принимает решение о необходимости заполнения полей и отправки подзаписи. Одна подзапись описывает один модуль. В одной записи может передаваться последовательно несколько таких подзаписей, что позволяет передать данные об отдельных составляющих всей аппаратной части УСВ и периферийного оборудования |
3 | EGTS_SR_VEHICLE_ DATA | Подзапись применяется УСВ для передачи на ТП информации о ТС |
5 | EGTS_SR_ DISPATCHER_IDENTITY | Подзапись используется только авторизуемой ТП при запросе авторизации на авторизующей ТП и содержит учетные данные авторизуемого УСВ (для устройств с функциями мониторинга ТС) |
6 | EGTS_SR_AUTH_ PARAMS | Подзапись используется ТП для передачи на УСВ данных о способе и параметрах шифрования, требуемого для дальнейшего взаимодействия |
7 | EGTS_SR_AUTH_INFO | Подзапись предназначена для передачи на ТП аутентификационных данных УСВ с использованием ранее переданных со стороны платформы параметров для осуществления шифрования данных |
8 | EGTS_SR_SERVICE_ INFO | Данный тип подзаписи используется для информирования принимающей стороны, УСВ или ТП, в зависимости от направления отправки, о поддерживаемых сервисах, а также для запроса определенного набора требуемых сервисов (от УСВ к ТП) |
9 | EGTS_SR_RESULT_ CODE | Подзапись применяется ТП для информирования УСВ о результатах процедуры аутентификации УСВ |
12 | EGTS_SR_VEHICLE_ DATA_ADD | Подзапись применяется УСВ для передачи на ТП дополнительной информации о ТС |
6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE
Структура подзаписи приведена в таблице 19.
Таблица 19 - Формат подзаписи EGTS_SR_RECORD_RESPONSE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
CRN (Confirmed Record Number) | M | USHORT | 2 | |||||||
RST (Record Status) | M | BYTE | 1 | |||||||
Поля подзаписи 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_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
TID (Terminalldentifier) | M | ULONG | 8 | |||||||
Flags | M | BYTE | 1 | |||||||
MNE | BSE | NIDE | SSRA | LNGCE | IMSIE | IMEIE | HDIDE |
|
|
|
HDID (Home Dispatcher Identifier) | O | USHORT | 2 | |||||||
IMEI (International Mobile Equipment Identity) | O | STRING | 15 | |||||||
IMSI (International Mobile Subscriber Identity) | O | STRING | 16 | |||||||
LNGC (Language Code) | O | STRING | 3 | |||||||
NID (Network Identifier) | O | BINARY | 3 | |||||||
BS (Buffer Size) | O | USHORT | 2 | |||||||
MSISDN (Mobile Station Integrated Services Digital Network Number) | O | STRING | 15 | |||||||
SSLPV (Service Support Level Protocol Version) | O | STRING | 2 | |||||||
Поля подзаписи EGTS_SR_TERM_IDENTITY имеют следующие назначения:
- TID - уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных AC (IMSI, IMEI, serial_id). В случае использования УСВ в качестве штатного устройства TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);
- HDIDE (Home Dispatcher Identifier Enable) - битовый флаг, который определяет наличие поля HDID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
- IMEIE (International Mobile Equipment Identity Enadle) - битовый флаг, который определяет наличие поля 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) и зависит от реализации аппаратной и программной частей конкретной УСВ;
_______________
- SSLPV - Номер версии протокола уровня поддержки услуг (номер версии протокола EGTS). Версия протокола уровня поддержки услуг (номер версии протокола EGTS) состоит из двух символов, левый символ "0" для версий от 1 до 9, "01" ... "09" соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.
Таблица 21 - Формат поля NID подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE
Биты 20...23 | Биты 10...19 | Биты 0...9 | Тип | Тип данных | Размер, байт |
- | МСС (Mobile Country Code) | MNC (Mobile Network Code) | M | BINARY | 3 |
Параметры поля 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.
Совокупность МСС и MNC определяет уникальный идентификатор оператора сетей ПРТС стандартов GSM, CDMA, TETRA, UMTS, а также некоторых операторов спутниковой связи.
6.7.2.3 Подзапись EGTS_SR_MODULE_DATA
Структура подзаписи представлена в таблице 22.
Таблица 22 - Формат подзаписи EGTS_SR_MODULE_DATA сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
MT (Module Type) | M | BYTE | 1 | |||||||
VID (Vendor Identifier) | M | UINT | 4 | |||||||
FWV (Firmware Version) | M | USHORT | 2 | |||||||
SWV (Software Version) | M | USHORT | 2 | |||||||
MD (Modification) | M | BYTE | 1 | |||||||
ST (State) | M | BYTE | 1 | |||||||
SRN (Serial Number) | O | STRING | 0 ... 32 | |||||||
D (Delimiter) | M | BYTE | 1 | |||||||
DSCR (Description) | O | STRING | 0 ... 32 | |||||||
D (Delimiter) | M | BYTE | 1 | |||||||
Поля подзаписи 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_SR_VEHICLE_DATA сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
VINL (Vehicle Identification Number - LOW) | M | STRING | 17 | |||||||
VHT (Vehicle Type) | M | UINT | 4 | |||||||
VPST (Vehicle Propulsion Storage Type) | M | UINT | 4 | |||||||
VINH (Vehicle Identification Number - HI) | O | STRING | 0..255 | |||||||
Поля подзаписи EGTS_SR_VEHICLE_DATA имеют следующие значения:
- VIN - идентификационный номер ТС. Передается в двух полях VINL - последние 17 знаков, VINH - оставшаяся часть;
- VHT - тип TC:
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_SR_AUTH_PARAMS сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
FLG (Flags) | M | BYTE | 1 | |||||||
- | EXE | SSE | MSE | ISLE | PKE | ENA |
|
|
| |
PKL (Public Key Length) | O | USHORT | 2 | |||||||
PBK (Public Key) | O | BINARY | 0...512 | |||||||
ISL (Identity String Length) | O | USHORT | 2 | |||||||
MSZ (Mod Size) | O | USHORT | 2 | |||||||
SS (Server Sequence) | O | STRING | 0...255 | |||||||
D (Delimiter) | O | BYTE | 1 | |||||||
EXP (Exp) | O | STRING | 0...255 | |||||||
D (Delimiter) | O | BYTE | 1 | |||||||
Поля подзаписи EGTS_SR_AUTH_PARAMS имеют следующие значения:
- EXE (Exp Enable) - битовый флаг, определяет наличие поля ЕХР и следующего за ним разделителя 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 (Encriptrion 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_SR_AUTH_INFO сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
UNM (User Name) | M | STRING | 0...32 | |||||||
D (Delimiter) | M | BYTE | 1 | |||||||
UPSW (User Password) | M | STRING | 0...32 | |||||||
D (Delimiter) | M | BYTE | 1 | |||||||
SS (Server Sequence) | O | STRING | 0...255 | |||||||
D (Delimiter) | O | BYTE | 1 | |||||||
Поля подзаписи EGTS_SR_AUTH_INFO имеют следующие значения:
- UNM - имя пользователя;
- D - разделитель строковых параметров (всегда имеет значение 0);
- UPSW - пароль пользователя;
- SS - специальная серверная последовательность байтов, передаваемая в подзаписи EGTS_SR_AUTH_PARAMS (необязательное поле, наличие зависит от используемого алгоритма шифрования).
6.7.2.7 Подзапись EGTS_SR_SERVICE_INFO
Структура подзаписи представлена в таблице 26.
Таблица 26 - Структура подзаписи EGTS_SR_SERVICE_INFO сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ST (Service Туре) | M | BYTE | 1 | |||||||
SST (Service Statement) | M | BYTE | 1 | |||||||
SRVP (Service Parameters) | M | BYTE | 1 | |||||||
SRVA | - | SRVRP |
|
|
| |||||
Поля подзаписи 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 - Список возможных состояний сервиса
Код | Название | Описание |
0 | EGTS_SST_IN_SERVICE | Сервис в рабочем состоянии и разрешен к использованию |
128 | EGTS_SST_OUT_OF_SERVICE | Сервис в нерабочем состоянии (выключен) |
129 | EGTS_SST_DENIED | Сервис запрещен для использования |
130 | EGTS_SST_NO_CONF | Сервис не настроен |
131 | EGTS_SST_TEMP_UNAVAIL | Сервис временно недоступен |
6.7.2.8 Подзапись EGTS_SR_RESULT_CODE
Структура подзаписи представлена в таблице 28.
Поля подзаписи EGTS_SR_RESULT_CODE имеют следующее значение:
- RCD - код, определяющий результат выполнения операции авторизации.
Таблица 28 - Структура подзаписи EGTS_SR_RESULT_CODE сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RCD (Result Code) | M | BYTE | 1 | |||||||
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.
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 с результатом проведения процедуры авторизации УСВ.
 |
Рисунок 8 - Алгоритм конфигурации УСВ с использованием SMS
 |
*Массив данных 1 - массив данных, определяющих перечень серверов телематических платформ, с которыми необходимо установить TCP/IP-соединение. В массиве данных передаются для каждой ТП: IPv4 адрес и порт для установки TCP/IP-соединения; вариант процедуры выбора версии протокола обмена данными
Рисунок 9 - Алгоритм конфигурации УСВ версии "02" с передачей параметров выбора протокола с использованием SMS
 |
Рисунок 10 - Алгоритм конфигурации УСВ с использованием СПРС
 |
Рисунок 11 - Алгоритм выбора версии протокола при авторизации УСВ на стороне ТП
 |
Рисунок 12 - Обмен сообщениями на этапе авторизации УСВ на ТП
Далее УСВ отправляет сообщение 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_SR_DISPATCHER_IDENTITY сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
DT (Dispatcher Туре) | M | BYTE | 1 | |||||||
DID (Dispatcher ID) | M | UINT | 4 | |||||||
TID (Terminalldentifier) | M | ULONG | 8 | |||||||
SSLPV (Service Support Level Protocol Version) | O | STRING | 2 | |||||||
DSCR (Description) | O | STRING | 0...255 | |||||||
Поля подзаписи EGTS_SR_DISPATCHER_IDENTITY:
- DT - тип диспетчера;
- DID - уникальный идентификатор диспетчера;
- DSCR - краткое описание;
- TID - уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных AC (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_SR_VEHICLE_DATA_ADD сервиса EGTS_AUTH_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
|
|
| VNE | VPE | VTE | VBE | VME | M | BYTE | 1 |
VSRM (Vehicle State Registration Mark) | M | STRING | 32 | |||||||
VM (Vehicle Model) | O | STRING | 64 | |||||||
VB (Vehicle Brand) | O | STRING | 32 | |||||||
VOTIN (Vehicle Owner Taxpayer Identification Number) | O | STRING | 12 | |||||||
VOPSRN (Vehicle Owner Primary State Registration Number) | O | STRING | 15 | |||||||
VON (Vehicle Owner Name) | O | STRING | 64 | |||||||
- 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 - наименование организации - собственника ТС.
6.7.3 Сервис EGTS_COMMANDS_SERVICE
Данный тип сервиса предназначен для обработки команд, сообщений и подтверждений, передаваемых между УСВ, ТП и клиентскими приложениями.
Для осуществления взаимодействия в рамках данного сервиса используется одна подзапись EGTS_SR_COMMAND_DATA, описание и код которой представлены в таблице 31.
Таблица 31 - Описание подзаписей сервиса EGTS_COMMANDS_SERVICE
Код | Название | Описание |
0 | EGTS_SR_RECORD_RESPONSE | Подзапись применяется для подтверждения процесса обработки записи ППУ. Данный тип подзаписи должен поддерживаться всеми сервисами |
51 | EGTS_SR_COMMAND_DATA | Подзапись используется УСВ и ТП для передачи команд, информационных сообщений, подтверждений доставки, подтверждений выполнения команд, подтверждения прочтения сообщений |
6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA
Структура подзаписи представлена в таблице 32.
Таблица 32 - Структура подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
CT (Command Type) | CCT (Command Confirmation Type) | М | BYTE | 1 | ||||||
CID (Command Identifier) | М | UINT | 4 | |||||||
SID (Source Identifier) | M | UINT | 4 | |||||||
- | ACFE | CHSFE | M | BYTE | 1 | |||||
CHS (Charset) | О | BYTE | 1 | |||||||
ACL (Authorization Code Length) | О | BYTE | 1 | |||||||
AC (Authorization Code) | О | BINARY | 0 ... 255 | |||||||
CD (Command Data) | О | BINARY | 0 ... 65205 | |||||||
Приведенные в таблице 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 - подтверждение о доставке команды или информационного сообщения;
- ССТ - тип подтверждения (имеет смысл для типов команд 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 и АС в подзаписи:
а) 1 - поля ACL и AC присутствуют в подзаписи,
б) 0 - поля ACL и AC отсутствуют в подзаписи;
- CHSFE (Charset Field Exists) - битовый флаг, определяющий наличие поля CHS в подзаписи:
а) 1 - поле CHS присутствует в подзаписи,
б) 0 - поле CHS отсутствует в подзаписи;
- CHS - кодировка символов, используемая в поле CD, содержащем тело команды. При отсутствии данного поля по умолчанию должна использоваться кодировка СР-1251. Определены следующие значения поля CHS (десятичный вид):
а) 0 - СР-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 (рисунок Е.З),
к) 8 - UCS2;
- ACL - длина в байтах поля AC, содержащего код авторизации на стороне получателя;
- AC - код авторизации, использующийся на принимающей стороне (автомобильная система), который обеспечивает ограничение доступа на выполнение отдельных команд. Если указанный в данном поле код не совпадает с ожидаемым значением, то в ответ на такую команду или сообщение AC должна отправить подтверждение с типом CC_JLL. Установка кода авторизации на стороне AC производится при помощи команды EGTS_SET_AUTH_CODE;
- CD - тело команды, параметры, данные, возвращаемые на команду-запрос, использующие кодировку из поля CHS или значение по умолчанию.
Размер данного поля определяется исходя из общей длины записи ППУ и длины предшествующих полей в данной подзаписи. Формат команды представлен в таблице 33. Данное поле может иметь нулевую длину (отсутствовать) в тех случаях, когда в ответ на команду или сообщение для УСВ не передаются никакие данные.
Таблица 33 - Формат команд автомобильной системы
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ADR (Address) | M | USHORT | 2 | |||||||
SZ (Size) | ACT (Action) | M | BYTE | 1 | ||||||
CCD (Command Code) | M | USHORT | 2 | |||||||
DT (Data) | O | BINARY | 0...65200 | |||||||
Приведенные в таблице 33 параметры имеют следующие назначения:
- ADR - адрес модуля, для которого данная команда предназначена. Адрес определяется исходя из начальной конфигурации УСВ или из списка модулей, который может быть получен при регистрации УСВ через сервис EGTS_AUTH_SERVICE и передачи подзаписей EGTS_SR_MODULE_DATA;
- ACT - описание действия, используется в случае типа команды, поле CT-CT_COM подзаписи EGTS_SR_COMMAND_DATA. Значение поля может быть одним из следующих вариантов:
а) 0 - параметры команды. Используется для передачи параметров для команды, определяемой кодом из поля CCD,
б) 1 - запрос значения. Используется для запроса информации, хранящейся в УСВ. Запрашиваемый параметр определяется кодом из поля CCD,
в) 2 - установка значения. Используется для установки нового значения определенному параметру в УСВ. Устанавливаемый параметр определяется кодом из поля CCD, а его значение - полем DT,
г) 3 - добавление нового параметра в УСВ. Код нового параметра указывается в поле CCD, его тип - в поле SZ, а значение - в поле DT,
д) 4 - удаление имеющегося параметра из УСВ. Код удаляемого параметра указывается в поле CCD;
- CCD - код команды при АСТ-0 или параметра при АСТ-1 ...4;
- DT - запрашиваемые данные или параметры, необходимые для выполнения команды. Данные записываются в данное поле в формате, зависящем от типа команды.
Подтверждение на ранее переданную команду при CT-CT_COMCONF, если с УСВ передается сопутствующая информация, имеет формат, представленный в таблице 34. Описанная структура содержится в поле CD.
Таблица 34 - Формат подтверждения на команду УСВ
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ADR (Address) | M | USHORT | 2 | |||||||
CCD (Command Code) | M | USHORT | 2 | |||||||
DT (Data) | O | BINARY | 0...65200 | |||||||
Приведенные в таблице 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.
6.7.3.2 Описание команд, параметров и подтверждений
Список и описание команд для УСВ представлены в таблице 35, список подтверждений на команды и сообщения от УСВ - в таблице 36; список параметров УСВ - в таблице 37.
Значения следующих параметров УСВ могут быть запрошены, но не могут быть изменены или удалены при помощи сервиса команд:
- EGTS_UNIT_SERIAL_NUMBER,
- EGTS_UNIT_HW_VERSION;
- EGTS_UNIT_SW_VERSION;
- EGTS_UNIT_VENDOR_ID;
- EGTS_INIT_IMEI.
Значения указанных параметров выставляются производителями соответствующих модулей и блоков УСВ, а также разработчиками ПО для них.
Таблица 35 - Список команд для УСВ
Название команды | Код | Тип, число и предельное значение параметра | Описание |
EGTS_RAW_DATA | 0x0000 | BINARY (до 65200 байт) | Команда для передачи произвольных данных. Применяется, например, для передачи команд, сообщений и данных на периферийные устройства, модули, подключенные к основному блоку УСВ, в определяемом данным модулем формате. При этом УСВ не должна анализировать данные из поля DT и в неизменном виде передавать их по адресу, определяемому полем ADR |
EGTS_TEST_MODE | 0x0001 | BYTE | Команда начала/окончания тестирования УСВ:
1 - начало тестирования;
0 - окончание тестирования |
EGTS_CONFIG_RESET | 0x0006 | - | Возврат к заводским установкам. Удаляются все установленные пользователем параметры, и производится возврат к заводским установкам. Для обработки данной команды оператор должен установить корректные значения полей ACL и AC, указанных в таблице 29 |
EGTS_SET_AUTH_CODE | 0x0007 | BINARY | Установка кода авторизации на стороне УСВ. Для обработки данной команды оператор должен установить корректные значения полей ACL и AC, указанных в таблице 29. После подтверждения данной команды УСВ будет использовать уже новые данные для сравнения со значением из поля AC в некоторых присылаемых на УСВ командах |
EGTS_RESTART | 0x0008 | - | Команда производит перезапуск основного программного обеспечения УСВ. Для обработки данной команды оператор должен установить корректные значения полей ACL и AC, указанных в таблице 29 |
EGTS_TEST_GET_ERRORS | 0x0004 | - | Запрос кодов ошибок |
EGTS_TEST_CLEAR_ERRORS | 0x0005 | - | Очистка кодов ошибок. Для обработки данной команды оператор должен установить корректные значения полей ACL и ACH |
EGTS_SET_ON_READY | 0x050A | - | Команда включения для УСВ режима постоянной регистрации в сети связи. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS |
EGTS_SET_OFF_READY | 0x050B | - | Команда отключения для УСВ режима постоянной регистрации в сети связи.
Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS |
EGTS_SET_ON_ACCIDENT | 0x060A | - | Команда включения для УСВ режима сбора информации об обстоятельствах ДТП. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS |
EGTS_SET_OFF_ACCIDENT | 0x060B | - | Команда отключения для УСВ режима сбора информации об обстоятельствах ДТП.
Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS |
EGTS_SEND_ACCIDENT_DATA | 0x060C | - | Команда запроса УСВ для передачи информации об обстоятельствах ДТП |
EGTS_SET_ON_MONITOR | 0x070A | - | Команда включения для УСВ режима передачи мониторинговой информации. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS |
EGTS_SET_OFF_MONITOR | 0x070B | - | Команда отключения для УСВ режима передачи мониторинговой информации. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS |
EGTS_SET_PROTOCOL_CHOICE | 0x080A | - | Команда установки правила выбора версии протокола поддержки услуг (версии протокола EGTS). Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS.
Команда реализует условия выбора версии согласно установленным параметрам УСВ (см. таблицу 37, параметр EGTS_PROTOCOL_CHOICE).
Без использования команды EGTS_SET_PROTOCOL_CHOICE при взаимодействии со всеми ТП УСВ реализует вариант процедуры выбора версии протокола обмена данными:
0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола ("01") и заканчивая старшей версией протокола ("02"), согласно процедурам и принципам, описанным в разделе 6.1.3 |
Таблица 36 - Список подтверждений на команды и сообщения от УСВ
Название команды | Код | Тип и число параметра | Описание |
EGTS_RAW_DATA | 0x0000 | BINARY (до 65200 байт) | Данные, поступающие от периферийных устройств, модулей, подключенных к основному блоку УСВ, в определяемом данным модулем формате |
EGTS_SELF_TEST_RESULT | 0x0002 | STRING | Сообщение о результатах самодиагностики. Генерируется УСВ автоматически без запроса от оператора |
EGTS_TEST_GET_ERRORS | 0x0004 | BINARY (16 байт) | Список кодов ошибок состояний блоков, модулей и подсистем терминала |
EGTS_SET_ON_READY | 0x050A | BINARY (1 байт) | Подтверждение включения для УСВ режима постоянной регистрации в сети. Если команда EGTS_SET_ON_READY принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. Параметр интерпретируется как битовое поле, определяющее состояние регистрации в сети и успешное установление TCP соединения с сервером. Бит 0 соответствует установлению постоянной регистрации в сети сотовой связи, бит 1 соответствует установлению постоянного TCP соединения с сервером. Если бит имеет значение 0 - условие не выполнено, 1 - выполнено. На данную команду может быть отправлено несколько подтверждений с разным значением флагов (при задержках в установлении TCP соединения) |
EGTS_SET_OFF_READY | 0x050B | BINARY (1 байт) | Подтверждение отключения для УСВ режима постоянной регистрации в сети. Если команда EGTS_SET_OFF_READY принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. Параметр интерпретируется как битовое поле, определяющее состояние постоянной регистрации в сети и успешное отключение TCP соединения с сервером. Бит 0 соответствует установлению постоянной регистрации в сети сотовой связи, бит 1 соответствует установлению постоянного TCP соединения с сервером. Если бит 0 имеет значение 0 - постоянная регистрация не установлена, 1 - постоянная регистрация установлена (не может быть отключена в данный момент). Если бит 1 имеет значение 0 - постоянное TCP соединение отключено, 1 - постоянное TCP соединение поддерживается (не может быть отключено в данный момент). На данную команду может быть отправлено несколько подтверждений с разными значениями флагов (при задержках в завершении TCP соединения) |
EGTS_SET_ON_ACCIDENT | 0x060A | BOOLEAN | Подтверждение включения для УСВ режима сбора информации об обстоятельствах ДТП. Если команда EGTS_SET_ON_ACCIDENT принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS.
TRUE - успешное установление УСВ режима сбора информации об обстоятельствах ДТП.
FALSE - при установлении УСВ режима сбора информации об обстоятельствах ДТП возникла ошибка |
EGTS_SET_OFF_ACCIDENT | 0x060B | BOOLEAN | Подтверждение отключения для УСВ режима сбора информации об обстоятельствах ДТП. Если команда EGTS_SET_OFF_ACCIDENT принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS.
TRUE - успешное отключение УСВ режима сбора информации об обстоятельствах ДТП.
FALSE - при отключении УСВ режима сбора информации об обстоятельствах ДТП возникла ошибка |
EGTS_SEND_ACCIDENT_DATA | 0x060C | BOOLEAN | Подтверждение приема запроса УСВ для передачи информации об обстоятельствах ДТП.
TRUE - УСВ готова к передаче информации об обстоятельствах ДТП.
FALSE - УСВ не готова к передаче информации об обстоятельствах ДТП или возникла ошибка |
EGTS_SET_ON_MONITOR | 0x070A | BOOLEAN | Подтверждение включения для УСВ режима передачи мониторинговой информации. Если команда EGTS_SET_ON_MONITOR принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS.
TRUE - успешное установление УСВ режима передачи мониторинговой информации.
FALSE - при установлении УСВ режима передачи мониторинговой информации возникла ошибка |
EGTS_SET_OFF_MONITOR | 0x070В | BOOLEAN | Подтверждение отключения для УСВ режима передачи мониторинговой информации. Если команда EGTS_SET_OFF_MONITOR принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS.
TRUE - успешное отключение УСВ режима передачи мониторинговой информации.
FALSE - при отключении УСВ режима передачи мониторинговой информации возникла ошибка |
EGTS_SET_PROTOCOL_CHOICE | 0x080B | BOOLEAN | Подтверждение установки режима выбора версии протокола согласно установленным параметрам.
Если команда EGTS_SET_PROTOCOL_CHOICE принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS.
TRUE - успешное применение параметров выбора версии протокола с учетом установленных параметров EGTS_PROTOCOL_CHOICE.
FALSE - при применении параметров выбора версии протокола возникла ошибка или параметры EGTS_PROTOCOL_CHOICE некорректны |
Таблица 37 - Список параметров УСВ
Имя параметра | Код | Тип параметра | Значение по умолчанию | Описание | Применимость | Возможность изменения |
Радио mute | ||||||
EGTS_RADIO_MUTE_DELAY | 0x0201 | INT | 0 | Задержка между установкой сигнала радио mute и началом проигрывания звука, мс | ДО | Да |
EGTS_RADIO_UNMUTE_DELAY | 0x0202 | INT | 0 | Задержка между снятием сигнала радио mute и окончанием проигрывания звука, мс | ДО | Да |
Установки общего назначения | ||||||
EGTS_GPRS_APN | 0x0203 | STRING | "" | Параметр, определяющий точку доступа СПРС | ДО, ШСД | Да |
EGTS_SERVER_ADDRESS | 0x0204 | STRING | "" | Адрес и порт сервера для связи с использованием TCP/IP протокола | ДО, ШСЭ, ШСД | Да |
EGTS_SIM_PIN | 0x0205 | INT | 0 | PIN-код SIM-карты | ДО, ШСЭ, ШСД | Да |
EGTS_INT_MEM_TRANSMIT_ INTERVAL | 0x0206 | INT | 60 | Интервал между повторными попытками отправки сообщений в случае неудачной отправки посредством пакетной передачи или через SMS, мин | ДО, ШСЭ, ШСД | Да |
EGTS_INT_MEM_TRANSMIT_ ATTEMPTS | 0x0207 | INT | 10 | Максимальное число попыток передачи сообщения посредством пакетной передачи или через SMS в случае ошибок передачи | ДО, ШСЭ, ШСД | Да |
Режим тестирования | ||||||
EGTS_TEST_REGISTRATION_ PERIOD | 0x0242 | INT | 5 | Если УСВ была зарегистрирована в сети посредством нажатия на кнопку "Дополнительные функции", то последующая регистрация УСВ в сети при нажатии на эту кнопку возможна не ранее, чем через данный промежуток времени. Если значение установлено в 0, то ограничений на последующую регистрацию УСВ в сети не накладывается, мин | ДО, ШСЭ, ШСД | Да |
EGTS_TEST_MODE_END_ DISTANCE | 0x020A | INT | 300 | Дистанция, на которой режим тестирования выключается автоматически, м | ДО, ШСЭ, ШСД | Да |
Режим "Автосервис" | ||||||
EGTS_GARAGE_MODE_END_ DISTANCE | 0x020B | INT | 300 | Дистанция, на которой режим "Автосервис" выключается автоматически, м | ДО | Да |
EGTS_GARAGE_MODE_PIN | 0x020C | INT/{NONE=0, PIN 1 =1, ... PIN 8=8} | 0 | Линия, сигнализирующая, что УСВ находится в режиме "Автосервис":
NONE - нет сигнализации режима;
X - PIN_X линия активная, когда система находится в данном режиме | ДО | Да |
Прочие параметры | ||||||
EGTS_GNSS_POWER_OFF_TIME | 0x0301 | INT | 500 | Промежуток времени, через который отключается питание ГНСС приемника после выключения зажигания, мс | ДО | Да |
EGTS_GNSS_DATA_RATE | 0x0302 | INT/1, 2, 5, 10 | Определяется производителем УСВ | Темп выдачи данных ГНСС приемником, Гц | ДО, ШСЭ, ШСД | Нет |
EGTS_GNSS_MIN_ELEVATION | 0x0303 | INT/5... 15 | 15 | Минимальное значение угла возвышения (угла отсечки) навигационных космических аппаратов, градусы | ДО, ШСЭ, ШСД | Нет |
Параметры устройства | ||||||
EGTS_UNIT_ID | 0x0404 | INT | 0 | Уникальный идентификатор УСВ, назначаемый оператором системы при первой авторизации | ДО, ШСЭ, ШСД | Да |
EGTS_UNIT_IMEI | 0x0405 | STRING | "" | Номер IMEI | ДО, ШСЭ, ШСД | Нет |
EGTS_UNIT_RS485_BAUD_RATE | 0x0406 | INT | 19200 | Скорость порта RS485, бит/с | ДО, ШСЭ, ШСД | Да |
EGTS_UNIT_RS485_STOP_BITS | 0x0407 | INT | 1 | Число стоп-битов при передаче данных через порт RS485 | ДО, ШСЭ, ШСД | Да |
EGTS_UNIT_RS485_PARITY | 0x0408 | INT/0,1, 2 | 0 | Способ проверки на четность при передаче данных через порт RS485:
0 - проверка не производится;
1 - проверка типа ODD;
2 - проверка типа EVEN | ДО, ШСЭ, ШСД | Да |
EGTS_UNIT_HOME_ DISPATCHER_ID | 0x0411 | INT | 0 | Идентификатор ТП, в хранилище которой находится информация об учетных данных устройства, списке предоставляемых услуг и их статусах | ДО, ШСЭ, ШСД | Да |
EGTS_SERVICE_AUTH_ METHOD | 0x0412 | INT | 1 | Метод использования услуг:
1 - простой метод (все услуги по умолчанию доступны УСВ);
0 - с подтверждением (реализуются только те услуги, информация о разрешении использования которых пришла с ТП) | ДО, ШСЭ, ШСД | Да |
EGTS_SERVER_CHECK_IN_ PERIOD | 0x0413 | INT | 30 | Время между попытками установить TCP/IP соединение с сервером, с | ДО, ШСД | Да |
EGTS_SERVER_CHECK_IN_ ATTEMPTS | 0x0414 | INT | 5 | Число попыток установления TCP/IP соединения с сервером, по достижении которого будет произведена повторная установка сессии верхнего уровня (СПРС) | ДО, ШСД | Да |
EGTS_SERVER_PACKET_TOUT | 0x0415 | INT | 5 | Время, в течение которого УСВ ожидает подтверждения с сервера на отправленный пакет, с | ДО, ШСД | Да |
EGTS_SERVER_PACKET_ RETRANSMIT_ATTEMPTS | 0x0416 | INT | 3 | Число попыток повторной отправки неподтвержденного пакета, по достижении которого УСВ производит повторную инициализацию сессии на уровне TCP/IP | ДО, ШСД | Да |
EGTS_UNIT_MIC_LEVEL | 0x0417 | INT/0... 10 | 8 | Уровень чувствительности микрофона | ДО, ШСЭ, ШСД | Да |
EGTS_UNIT_SPK_LEVEL | 0x0418 | INT/0... 10 | 6 | Уровень громкости динамика | ДО, ШСЭ, ШСД | Да |
ERA_TO_EMERGENCY_CALL_ AUTO_TRANSITION |
| INT | 10 | Количество переходов УСВ из режима "ЭРА" в режим "Экстренный вызов" при автоматическом срабатывании системы | ДО, ШО | Да |
ERA_TO_EMERGENCY_CALL_ MANUAL_TRANSITION |
| INT | 20 | Количество переходов УСВ из режима "ЭРА" в режим "Экстренный вызов" при ручном срабатывании системы | ДО, ШО | Да |
ERA_TO_EMERGENCY_CALL_ TRANSITION_PERIOD |
| INT | 1440 | Временной интервал, в течение которого производится подсчет переходов УСВ из режима "ЭРА" в режим "Экстренный вызов", мин | ДО, ШО | Нет |
EGTS_SELFTEST_INTERVAL | 0x0208 | INT | 0 | Интервал проведения внутреннего тестирования, ч. Если значение установлено в 0, то самотестирование не проводится | ДО, ШСЭ, ШСД | Да |
EGTS_POST_TEST_ REGISTRATION_TIME | 0x0209 | INT | 0 | Промежуток времени, в течение которого устройство остается зарегистрированным в сети после передачи результатов самотестирования оператору системы, с | ДО, ШСЭ, ШСД | Да |
EGTS_TEST_REGISTRATION_ TIMEOUT | 0x0241 | INT | 5 | Если устройство было зарегистрировано в сети посредством нажатия на кнопку включения дополнительных услуг и команда на запуск сессии тестирования не была получена со стороны оператора системы в течение данного промежутка времени, то устройство должно прекратить регистрацию в сети, мин | ДО, ШСЭ, ШСД | Да |
EGTS_TEST_MODE_WATCHDOG | 0x020E | INT | 10 | Интервал тревожного счетчика в режиме тестирования, мин | ДО, ШСЭ, ШСД | Да |
EGTS_USE_GPRS_WHITE_LIST | 0x0230 | BOOLEAN | 1 | Параметр, указывающий на необходимость использования GPRS_WHITE_LIST при организации пакетной передачи данных | ДО, ШСЭ, ШСД | Да |
EGTS_GPRS_WHITE_LIST | 0x0231 | ARRAY OF STRING | "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "" | Список сетей, в которых разрешена пакетная передача данных. Если список GPRS_WHITWE_ LIST пуст, то пакетная передача данных запрещена, MCC (Mobile Country Code) 3 символа + MNC (Mobile Network Code) 3 символа | ДО, ШСЭ, ШСД | Да |
EGTS_UNIT_ANGUAGE_ID | 0x0410 | INT | 0 | Предпочтительный язык для голосового общения (см. [8]):
0x5F - русский | ДО, ШСЭ, ШСД | Да |
EGTS_READY_PROFILE | 0x0501 | INT | 0 | Значение номера профиля передачи данных в сервисе EGTS_TELEDATA_ SERVICE, в котором УСВ ведет передачу данных сразу после получения команды на включение режима постоянной регистрации в сети. По умолчанию 0 - не ведет передачу данных сразу после получения команды на включение режима постоянной регистрации в сети до получения соответствующей команды на режим передачи данных сервиса EGTS_TELEDATA_ SERVICE | ДО, ШСЭ, ШСД | Да |
EGTS_MONITOR_PROFILE | 0x0701 | INT | 1 | Значение номера профиля передачи данных в сервисе EGTS_TELEDATA_ SERVICE, в котором УСВ ведет передачу данных сразу после получения команды на включение режима передачи мониторинговой информации. По умолчанию 1 - ведет передачу данных сразу после получения команды на включение режима передачи мониторинговой информации в профиле N 1 | ДО, ШСЭ, ШСД | Да |
EGTS_CONNECT_ACCIDENT | 0x066B | ARRAY OF INT | 0, 0, 0, 0, 0 | Элементы массива определяют адрес и порт сервера приема данных для режима передачи информации об обстоятельствах ДТП:
- первое слева направо число адреса IPv4
- второе слева направо число адреса IPv4
- третье слева направо число адреса IPv4
- четвертое слева направо число адреса IPv4
- номер порта | ДО, ШСД | Да |
EGTS_PROTOCOL_CHOICE | 0x0801 | ARRAY OF INT | 1, 0, 0, 0, 0, 0, 0 | Элементы массива определяют адрес и порт серверов ТП и режимы выбора версии протокола для каждой из них.
Первый элемент массива - номер профиля ТП. По умолчанию используется один профиль N 1.
Следующие элементы массива определяют адрес и порт сервера приема данных для данного профиля:
- первое слева направо число адреса IPv4
- второе слева направо число адреса IPv4
- третье слева направо число адреса IPv4
- четвертое слева направо число адреса IPv4
- номер порта
Следующие элементы определяют вариант процедуры выбора версии протокола обмена данными:
0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на телематическую платформу, начиная с младшей версии протокола ("01") и заканчивая старшей версией протокола ("02"), согласно процедурам и принципам, описанным в разделе 6.1.3 данного стандарта.
1 - УСВ использует для обмена данными с указанной ТП версию протокола "01".
2 - УСВ использует для обмена данными с указанной ТП версию протокола "02".
| ДО, ШСЭ, ШСД | Да |
|
|
|
| При передаче на УСВ параметров с первым элементом массива = 0 для всех ТП, не указанных в массиве профилей, будет применяться вариант процедуры выбора версии протокола обмена данными, указанный в данной записи, то есть в ячейке профиля с N 0.
Например, при передаче на УСВ массива 0,0,0,0,0,0,1 для всех ТП (кроме записанных в памяти с другими номерами профиля) будет применена процедура выбора 1 - УСВ использует для обмена данными версию протокола "01".
Пример организации хранения параметров приведен в таблице 35 |
|
|
ДО - для УСВ, исполненной в конфигурации дополнительного оборудования; ШСЭ - для УСВ, исполненной в конфигурации штатного оборудования и предназначенной для реализации только базовой услуги системой; ШСД - для УСВ, исполненной в конфигурации штатного оборудования и предназначенной для реализации дополнительных, кроме базовой, услуг системой. "Да" в этой графе означает, что установленное начальное значение параметра УСВ может изменяться после начальной установки УСВ, "Нет" - что установленные начальные значения не подлежат изменению в процессе применения УСВ. | ||||||
Таблица 38 - Пример заполнения массива параметров процедуры выбора версии протокола обмена данными EGTS_PROTOCOL_CHOICE
Первая позиция массива - номер профиля ТП | Вторая позиция массива - первое слева направо число адреса IPv4 | Третья позиция массива - первое слева направо число адреса IPv4 | Четвертая позиция массива - первое слева направо число адреса IPv4 | Пятая позиция массива - первое слева направо число адреса IPv4 | Шестая позиция массива - номер порта | Седьмая позиция массива - вариант процедуры выбора версии протокола обмена данными | Примечание |
0 | 0 | 0 | 0 | 0 | 0 | 1 | Для всех платформ, кроме указанных в других ячейках массива (10.5.64.100 и 10.0.0.20), будет применяться вариант выбора 1 - УСВ использует для обмена данными версию протокола "01" |
1 | 10 | 5 | 64 | 100 | 80 | 0 | Для платформы 10.5.64.100 будет применяться вариант выбора 0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола ("01") и заканчивая старшей версией протокола ("02"), согласно процедурам и принципам, описанным в разделе 6.1.3 |
2 | 10 | 0 | 0 | 20 | 80 | 2 | Для платформы 10.0.0.20 будет применяться вариант выбора 2 - УСВ использует для обмена данными с указанной ТП версию протокола "02" |
УСВ, установленными в конфигурации штатного оборудования, должна быть реализована поддержка следующих параметров:
- 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.
 |
Рисунок 13 - Отправка команды EGTS_ECALL_MSD_REQ по SMS
 |
Рисунок 14 - Запрос значения параметра
6.7.4 Сервис EGTS_FIRMWARE_SERVICE
Сервис EGTS_FIRMWARE_SERVICE предназначен для передачи на УСВ конфигурации и обновления программного обеспечения аппаратной части модулей и блоков самой УСВ, а также периферийного оборудования, подключенного к УСВ.
Для осуществления взаимодействия в рамках данного сервиса используется несколько подзаписей, описание и код которых представлены в таблице 39.
Таблица 39 - Список подзаписей сервиса EGTS_FIRMWARE_SERVICE
Код | Название | Описание |
0 | EGTS_SR_RECORD_ RESPONSE | Подзапись применяется для осуществления подтверждения записи ППУ из пакета типа EGTS_PT_APPDATA |
33 | EGTS_SR_SERVICE_ PART_DATA | Подзапись предназначена для передачи на УСВ данных, которые разбиваются на части и передаются последовательно. Данная подзапись применяется для передачи больших объектов, длина которых не позволяет передать их на УСВ одним пакетом |
34 | EGTS_SR_SERVICE_ FULL_DATA | Подзапись предназначена для передачи на УСВ данных, которые не разбиваются на части, а передаются одним пакетом |
6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA
Подзапись EGTS_SR_SERVICE_PART_DATA может использоваться сервисом для передачи сущностей на УСВ. Структура подзаписи представлена в таблице 40.
Таблица 40 - Структура подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ID (Identity) | M | USHORT | 2 | |||||||
PN (Part Number) | M | USHORT | 2 | |||||||
EPQ (Expected Parts Quantity) | M | USHORT | 2 | |||||||
ODH (Object Data Header) | O | BINARY | 0...71 | |||||||
OD (Object Data) | M | BINARY | 1...65400 | |||||||
Примечания
1 ID - уникальный идентификатор передаваемой сущности. Инкрементируется при начале отправки новой сущности. Данный параметр позволяет однозначно идентифицировать, какой именно сущности данная часть принадлежит.
2 PN - последовательный номер текущей части передаваемой сущности.
3 EPQ - ожидаемое число частей передаваемой сущности.
4 ODH - заголовок, содержащий параметры, характеризующие передаваемую сущность. Данный заголовок передается только для первой части сущности. При передаче второй и последующих частей данное поле не передается. Структура заголовка ODH представлена в настоящей таблице.
5 OD - данные непосредственно передаваемой сущности.
| ||||||||||
Параметр EPQ содержит число частей, которое будет передано, а параметр PN - номер текущей части. Поле ID однозначно определяет сущность, которой принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть не более значения из поля EPQ. Если данное условие нарушается, то данные из такой подзаписи игнорируются.
Идентификатор объекта ID, поля PN и EPQ, а также идентификатор источника записи OID из заголовка уровня маршрутизации сервисов позволяют определить, какая часть и какого объекта получена для обработки. Это позволяет при достаточной пропускной способности канала одновременно передавать сущности для обновления программного обеспечения различных аппаратных частей УСВ и периферийного оборудования. Формат заголовка передаваемой сущности подзаписи представлен в таблице 41.
Таблица 41 - Формат заголовка передаваемой сущности подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
OA (Object Attribute) | M | BYTE | 1 | |||||||
- | OT (Object Type) | MT (Module Type) |
|
|
| |||||
CMI (Component or Module Identifier) | M | BYTE | 1 | |||||||
VER (Version) | M | USHORT | 2 | |||||||
WOS (Whole Object Signature) | M | USHORT | 2 | |||||||
FN (File Name) | O | STRING | 0...64 | |||||||
D (Delimiter) | M | BYTE | 1 | |||||||
В таблице 41 параметры (поля) имеют следующие назначения:
- OA - характеристика принадлежности передаваемой сущности;
- OT - тип сущности по содержанию. Определены следующие значения данного поля:
а) 00 - данные внутреннего программного обеспечения ("прошивка"),
б) 01 - блок конфигурационных параметров;
- МТ - тип модуля, для которого предназначена передаваемая сущность. Определены следующие значения данного поля:
а) 00 - периферийное оборудование,
б) 01 - УСВ.
- CMI - номер компонента в случае принадлежности сущности непосредственно УСВ или идентификатор периферийного модуля/порта, подключенного к УСВ, в зависимости от значения параметра МТ;
- 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_SR_SERVICE_FULL_DATA сервиса EGTS_FIRMWARE_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ODH (Object Data Header) | M | BINARY | 7...71 | |||||||
OD (Object Data) | M | BINARY | 1... 65400 | |||||||
В таблице 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 - Временные и количественные параметры протокола уровня поддержки услуг
Название | Тип данных | Диапазон значений | Значение по умолчанию | Описание |
EGTS_SL_NOT_AUTH_TO | BYTE | 0... 255 | 6 | Время ожидания прихода сообщения от УСВ, содержащего данные для осуществления процедуры авторизации на стороне ТП после установления УСВ нового подключения по протоколу TCP/IP, с.
Если в течение данного времени сообщение не поступает, платформа должна разорвать установленное с УСВ TCP/IP соединение |
7 Сервис экстренного реагирования при аварии протокола уровня поддержки услуг
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, и передача соответствующих подтверждений на них.
7.3 Состав и описание подзаписей сервиса EGTS_ECALL_SERVICE
Для осуществления взаимодействия в рамках сервиса EGTS_ECALL_SERVICE используется несколько подзаписей, описание и код которых представлены в таблице 44.
Таблица 44 - Список подзаписей сервиса EGTS_ECALL_SERVICE
Код | Название | Описание |
0 | EGTS_SR_RECORD_RESPONSE | Подзапись применяется для осуществления подтверждения записи ППУ из пакета типа EGTS_PT_APPDATA |
20 | EGTS_SR_ACCEL_DATA | Подзапись предназначена для передачи на ТП данных профиля ускорения УСВ |
40 | EGTS_SR_RAW_MSD_DATA | Подзапись используется УСВ для передачи МНД на ТП в исходном виде |
62 | EGTS_SR_TRACK_DATA | Подзапись применяется для передачи данных о траектории движения ТС при ДТП на ТП |
7.3.1 Подзапись EGTS_SR_RECORD_RESPONSE
Данная подзапись имеет такую же структуру, как указано в 6.7.2.1.
7.3.2 Подзапись EGTS_SR_ACCEL_DATA
Структура подзаписи представлена в таблице 45.
Таблица 45 - Структура подзаписи EGTS_SR_ACCEL_DATA сервиса EGTS_ECALL_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SA (StructuresAmount) | M | BYTE | 1 | |||||||
ATM (AbsoluteTime) | M | UINT | 4 | |||||||
ADS1 (Accelerometer Data Structure 1) | M | BINARY | 8 | |||||||
ADS2 (Accelerometer Data Structure 2) | O | BINARY | 8 | |||||||
... | ... | ... | ... | |||||||
ADS255 (Accelerometer Data Structure 255) | O | BINARY | 8 | |||||||
В таблице 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
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RTM (RelativeTime) | M | USHORT | 2 | |||||||
XAAV (X Axis Acceleration Value) | M | SHORT | 2 | |||||||
YAAV (Y Axis Acceleration Value) | M | SHORT | 2 | |||||||
ZAAV (Z Axis Acceleration Value) | M | SHORT | 2 | |||||||
В таблице 46 параметры (поля) имеют следующие назначения:
- RTM - приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) в миллисекундах (мс);
7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA
Структура подзаписи EGTS_SR_RAW_MSD_DATA представлена в таблице 47.
Таблица 47 - Формат подзаписи EGTS_SR_RAW_MSD_DATA сервиса EGTS_ECALL_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
FM (Format) | M | BYTE | 1 | |||||||
MSD (Minimal Set of Data) | M | BINARY | 0...116 | |||||||
В таблице 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_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SA (Structures Amount) | M | BYTE | 1 | |||||||
ATM (Absolute Time) | M | UINT | 4 | |||||||
TDS1 (Track Data Structure 1) | M | BINARY | 1...12 | |||||||
TDS2 (Track Data Structure 2) | O | BINARY | 1...12 | |||||||
... | ... | ... | ... | |||||||
TDS255 (Track Data Structure 255) | O | BINARY | 1...12 | |||||||
В таблице 48 параметры (поля) имеют следующие назначения:
- SA - число передаваемых точек траектории движения ТС;
- ATM - опорное время проведения измерений (число секунд с 00:00:00 01.01.2010 UTC). Используется в качестве начального времени для первой передаваемой структуры с точностью 1 с. Более точное время измерения определяется с учетом поля RTM-структуры информации об отдельной точке траектории движения;
- TDS1 ... TDS255 - структуры данных, содержащие параметры отдельной точки траектории движения ТС. Формат структуры представлен в таблице 49.
Таблица 49 - Формат структуры данных отдельной точки траектории движения ТС подзаписи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт | |
TNDE | LOHS | LAHS | RTM (Relative Time) | M | BYTE | 1 | |||||
LAT (Latitude) | O | UINT | 4 | ||||||||
LONG (Longitude) | O | UINT | 4 | ||||||||
SPDL (Speed Low Bits) | O | USHORT | 2 | ||||||||
DIRH | SPDH (Speed Hi Bits) |
|
|
| |||||||
DIR (Direction) | O | BYTE | 1 | ||||||||
В составе подзаписи 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.
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.
Таблица 50 - Список команд для УСВ
Название команды | Код | Тип, число и предельное значение параметра | Описание |
EGTS_ECALL_REQ | 0x0112 | BYTE/0,1 | Команда на осуществление экстренного вызова с УСВ. Используется только через SMS.
Команда содержит один параметр, который определяет тип события:
0 - ручной вызов;
1 - автоматический вызов |
EGTS_ECALL_MSD_REQ | 0x0113 | BINARY (MID INT, TRANSPORT BYTE) | Команда на осуществление повторной передачи МНД. Используется только через SMS. Команда содержит два параметра:
- MID - идентификатор сообщения запрашиваемого МНД. Если параметр MID=0, то отправляется новое сообщение;
- TRANSPORT - тип используемого УСВ канала при отправке МНД:
0 - любой, на усмотрение УСВ,
2 - через SMS.
Примечание - При получении данной команды с параметром TRANSPORT=2 отправка подтверждающей подзаписи EGTS_SR_COMMAND_DATA с кодом подтверждения CC_OK в поле CCT (Command Confirmation Туре) не является обязательной
|
EGTS_ACCEL_DATA | 0x0114 | - | Команда на осуществление передачи данных профиля ускорения. Используется только через SMS |
EGTS_TRACK_DATA | 0x0115 | - | Команда на осуществление передачи данных траектории движения. Используется только через SMS |
EGTS_ECALL_DEREGISTRATION | 0x0116 | - | Команда на осуществление дерегистрации УСВ в сети ПРТС |
Таблица 51 - Список параметров УСВ
Имя параметра | Код | Тип параметра | Значение по умолчанию | Описание | Применимость | Возможность изменения |
Установки общего назначения | ||||||
EGTS_ECALL_TEST_NUMBER | 0x020D | STRING | "" | Телефонный номер для тестовых звонков в системе экстренного реагирования при авариях | ДО, ШСЭ, ШСД | Да |
Конфигурация и конфигурационные данные услуг. Базовая услуга системы экстренного реагирования при авариях | ||||||
EGTS_ECALL_ON | 0x0210 | BOOLEAN | TRUE | Возможность осуществления экстренного вызова | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_CRASH_ SIGNAL_INTERNAL | 0x0211 | BOOLEAN | TRUE | Если для определения события аварии используется встроенный в УСВ измеритель ускорения | ДО | Да |
EGTS_ECALL_CRASH_SIGNAL_ EXTERNAL | 0x0212 | BOOLEAN | TRUE | Если для определения события аварии используется внешний по отношению к УСВ датчик в автомобиле, например, датчик срабатывания подушки (подушек) безопасности или других систем пассивной безопасности | ДО | Да |
EGTS_ECALL_SOS_BUTTON_ TIME | 0x0213 | INT | 200 | Длительность, в течение которой должна быть нажата кнопка "Экстренный вызов", для инициации экстренного вызова независимо от состояния линии зажигания, мс | ДО | Да |
EGTS_ECALL_NO_AUTOMATIC_ TRIGGERING | 0x0214 | BOOLEAN | FALSE | Процедура инициализации режима "Экстренный вызов" в автоматическом режиме отключена | ДО, ШСЭ, ШСД | Да |
EGTS_ASI15_TRESHOLD | 0x0215 | FLOAT | 0.7 | Порог срабатывания датчика автоматической идентификации события ДТП в значения индекса возможного ущерба ASI 15 | ДО | Да |
EGTS_ECALL_MODE_PIN | 0x0216 | INT/0... 8 | 0 | Линия, сигнализирующая, что система находится в режиме "ЭРА":
- NONE - нет сигнализации режима;
- X - PIN_X активная линия, когда система находится в данном режиме | ДО | Да |
EGTS_ECALL_CCFT | 0x0217 | INT | 60 | Длительность счетчика автоматического прекращения звонка, мин | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_INVITATION_ SIGNAL_DURATION | 0x0218 | INT | 2000 | Длительность сигнала INVITATION, мс | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_SEND_MSG_ PERIOD | 0x0219 | INT | 5000 | Период сообщения SEND MSG, мс | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_AL_ACK_PERIOD | 0x021A | INT | 5000 | Период AL-ACK, мс | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_MSD_MAX_ TRANSMISSION_TIME | 0x021 В | INT | 20 | Максимальная длительность передачи МНД, с | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_NAD_ DEREGISTRATION_TIMER | 0x021D | INT | 8 | Время, по истечении которого GSM или UMTS модуль прекращает регистрацию в сети, ч | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_DIAL_ DURATION | 0x021E | INT | 5 | Общая продолжительность дозвона при инициации экстренного вызова, мин | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_AUTO_DIAL_ ATTEMPTS | 0x021F | INT | 10 | Число попыток дозвона при автоматически инициированном вызове. Значение не может быть установлено в 0 | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_MANUAL_ DIAL_ATTEMPTS | 0x0220 | INT | 10 | Число попыток дозвона при экстренном вызове, инициированном вручную. Значение не может устанавливаться в 0 | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_MANUAL_CAN_ CANCEL | 0x0222 | BOOLEAN | TRUE | TRUE - экстренный вызов, инициированный вручную, может быть прекращен со стороны пользователя | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_MANUAL_CAN_ CANCEL | 0x0222 | BOOLEAN | TRUE | TRUE - экстренный вызов, инициированный вручную, может быть прекращен со стороны пользователя | ДО, ШСЭ, ШСД | Да |
EGTS_ECALL_SMS_FALLBACK_ NUMBER | 0x0223 | STRING | "112" | Номер, по которому УСВ посылает SMS с минимальным набором данных по запросу от оператора системы | ДО, ШСЭ, ШСД | Да |
Запись профиля ускорения при ДТП | ||||||
IGNITION_OFF_FOLLOW_UP_ TIME1 | 0x0224 | INT | 120 | Промежуток времени, в течение которого осуществляется запись профиля ускорения при ДТП при выключенном зажигании, мин | ДО | Да |
IGNITION_OFF_FOLLOW_UP_ TIME2 | 0x0225 | INT | 240 | Промежуток времени, в течение которого осуществляется определение события аварии при выключенном зажигании, мин | ДО | Да |
EGTS_CRASH_RECORD_TIME | 0x251 | INT/0...250 | 250 | Время записи информации о профиле ускорения при ДТП, мс | ДО | Да |
EGTS_CRASH_RECORD_ RESOLUTION | 0x0252 | INT/1...5 | 1 | Продолжительность одного отсчета при записи профиля ускорения при ДТП, мс | ДО | Да |
EGTS_CRASH_PRE_RECORD_ TIME | 0x0253 | INT/ 0...20000 | 20000 | Время записи информации о профиле ускорения до того, как событие ДТП наступило, мс | ДО | Да |
EGTS_CRASH_PRE_RECORD_ RESOLUTION | 0x0254 | INT/5...100 | 5 | Продолжительность одного отсчета при записи профиля ускорения до того, как событие ДТП наступило, мс | ДО | Да |
Запись траектории движения при ДТП | ||||||
EGTS_TRACK_RECORD_TIME | 0x025A | INT/0... 180 | 10 | Время записи информации о траектории движения ТС при наступлении события ДТП, с. Установка значения данного параметра, равного 0, означает, что запись данных о траектории движения при ДТП не производится | ДО | Да |
EGTS_TRACK_PRE_RECORD_ TIME | 0x025B | INT/0...600 | 20 | Время записи информации о траектории движения ТС до того, как событие ДТП наступило, с. Установка значения данного параметра, равного 0, означает, что запись данных о траектории движения до того как событие ДТП наступило, не производится | ДО | Да |
EGTS_TRACK_RECORD_ RESOLUTION | 0x025C | INT/1... 30 | 10 | Продолжительность одного отсчета при записи траектории движения ТС, 100 мс | ДО | Да |
Параметры ТС | ||||||
EGTS_VEHICLE_VIN | 0x0311 | STRING | "" | VIN в соответствии с [1] (приложение 7) или иной уникальный идентификатор ТС | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_PROPULSION_ STORAGE_TYPE | 0x0313 | INT | 0 | Тип энергоносителя ТС. Может быть установлено более одного бита, если установлены носители нескольких типов. Если все биты 0, то тип не задан:
а) бит 31-6: не используется;
б) бит 5: 1 - водород;
в) бит 4: 1 - электричество (более 42 В и 100 А/ч);
г) бит 3: 1 - жидкий пропан (LPG);
д) бит 2: 1 - сжиженный природный газ (CNG);
е) бит 1: 1 - дизель;
ж) бит 0: 1 - бензин | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_TYPE | 0x0312 | UINT | 0 | Тип ТС:
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 - зарезервировано для судов иных типов |
|
|
EGTS_VEHICLE_VSRM | 0x0314 | STRING | "" | Государственный регистрационный знак (номер) ТС | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_VM | 0x0315 | STRING | "" | Модель ТС | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_VB | 0x0316 | STRING | "" | Марка ТС | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_VOTIN | 0x0317 | STRING | "" | ИНН собственника ТС | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_VOPSRN | 0x0318 | STRING | "" | ОГРН собственника ТС | ДО, ШСЭ, ШСД | Да |
EGTS_VEHICLE_VON | 0x0319 | STRING | "" | Наименование организации - собственника ТС | ДО, ШСЭ, ШСД | Да |
ДО - для УСВ, исполненной в конфигурации дополнительного оборудования; ШСЭ - для УСВ, исполненной в конфигурации штатного оборудования и предназначенной для реализации только базовой услуги системой; ШСД - для УСВ, исполненной в конфигурации штатного оборудования и предназначенной для реализации дополнительных услуг, кроме базовой. "Да" означает, что установленное начальное значение параметра УСВ может изменяться после начальной установки УСВ, "Нет" - что установленные начальные значения не подлежат изменению в процессе применения УСВ. | ||||||
8 Формат сообщения AL-ACK
8.1 Сообщение AL-ACK, направляемое системой экстренного реагирования при авариях в сторону УСВ и содержащее подтверждение корректности минимального набора данных, принятого с использованием тонального модема, должно высылаться также посредством использования тонального модема.
8.2 Сообщение AL-ACK должно иметь формат, определенный в таблице 52.
Таблица 52 - Формат сообщения AL_ACK
Поле данных AL-ACK | Номер бита, представляющего поле данных | Значение |
Зарезервированное поле N 1 | 4 | Поле не используется |
Зарезервированное поле N 2 | 3 | Поле не используется |
Признак корректности полученных данных | 2 | 0 - полученные данные корректны (Positive АСК);
1 - завершение вызова (Cleardown) |
Версия формата данных | 1 | 0 - текущий формат;
1 - зарезервировано для будущего использования |
9 Сервис представления информации об обстоятельствах дорожно-транспортного происшествия
9.1 Назначение сервиса представления информации об обстоятельствах дорожно-транспортного происшествия
Сервис предназначен для реализации режима УВС по определению, регистрации и передаче информации об обстоятельствах ДТП. В протоколе уровня поддержки услуг этот сервис определен как EGTS_EUROPROTOCOL_SERVICE и имеет код 22 (см. таблицу 17).
9.2 Состав и описание подзаписей сервиса EGTS_EUROPROTOCOL_SERVICE
9.2.1 Список обязательных подзаписей сервиса режима определения, регистрации и передачи информации об обстоятельствах ДТП приведен в таблице 53.
Таблица 53 - Список подзаписей сервиса определения, регистрации и передачи информации об обстоятельствах ДТП
Код | Наименование | Описание |
0 | EGTS_SR_RECORD_RESPONSE | Применяется для осуществления подтверждения записи протокола уровня поддержки услуг из пакета типа EGTS_PT_APPDATA |
1 | EGTS_SR_EP_MAIN_DATA | Подзапись используется УСВ для передачи основных сведений при определении, регистрации и передаче информации об обстоятельствах ДТП |
2 | EGTS_SR_EP_TRACK_DATA | Применяется для передачи данных о траектории движения ТС при ДТП |
3 | EGTS_SR_EP_ACCEL_DATA | Применяется для передачи данных истории ускорения ТС, в том числе профиля ускорения при ДТП |
4 | EGTS_SR_EP_SIGNATURE | Применяется для передачи информации по коду аутентификации массива данных при определении, регистрации и передаче информации об обстоятельствах ДТП |
5 | EGTS_SR_EP_RAW_DATA | Применяется для передачи первичных навигационных данных (номеров спутников, измерения времени, соотношения сигнал/шум, псевдодальности, доплеровского сдвига) от ГНСС приемника УСВ |
6 | EGTS_SR_EP_COMP_DATA | Применяется для передачи в сжатом виде данных других подзаписей сервиса режима определения, регистрации и передачи информации об обстоятельствах ДТП |
7 | EGTS_SR_EP_ACCEL_DATA2 | Применяется для передачи профиля ускорения в периоды времени, когда изменения ускорения между моментами времени измерения ускорения акселерометром в рамках указанного периода признаются незначительными (не превышают установленного значения) |
8 | EGTS_SR_EP_ACCEL_DATA3 | Применяется для передачи профиля ускорения в периоды времени, когда изменения ускорения между моментами времени измерения ускорения акселерометром в рамках указанного периода признаются значительными (превышают установленное значение) |
9.2.2 Подзапись EGTS_SR_EP_MAIN_DATA
Подзапись EGTS_SR_EP_MAIN_DATA предназначена для передачи основных данных об автоматическом или ручном определении, регистрации и передачи информации об обстоятельствах ДТП.
Структура подзаписи EGTS_SR_EP_MAIN_DATA приведена в таблице 54.
Таблица 54 - Структура подзаписи EGTS_SR_EP_MAIN_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
FV (Format Version) | M | BYTE | 1 | |||||||
B# (Block Number) | M | BYTE | 1 | |||||||
EVID (Event Identifier) | M | UINT | 4 | |||||||
CN (Control) | M | BYTE | 1 | |||||||
B#H | LBSN | LOCP | CLT | ACT | M | BYTE | 1 | |||
ACP | EVP | TRS | AS | RS | WAS | RWP | TRP | M | BYTE | 1 |
TS (Time Stamp) | M | BINARY | 4 | |||||||
MSL (Milliseconds Low Bits) | M | BYTE | 1 | |||||||
- | CAU (Cause) | MSH | M | BYTE | 1 | |||||
LAT (Latitude) | O | UINT | 4 | |||||||
LONG (Longitude) | O | UINT | 4 | |||||||
SPDL (Speed Low Bits) | O | BYTE | 1 | |||||||
DIRH | LOHS | LAHS | SPDH (Speed Hi Bits) | O | BYTE | 1 | ||||
ALT (Altitude) | O | SHORT | 2 | |||||||
DIRL (Direction Low Bits) | O | BYTE | 1 | |||||||
BSD1 (Base Station Data 1) | O | BINARY | 10 | |||||||
BSD2 (Base Station Data 2) | O | BINARY | 10 | |||||||
... |
|
|
| |||||||
BSD5 (Base Station Data 5) | O | BINARY | 10 | |||||||
EPEVC (Europrotocol Events Count) | O | BYTE | 1 | |||||||
EV1 (Event ID 1) | O | UINT | 4 | |||||||
EV2 (Event ID 2) | O | UINT | 4 | |||||||
... |
|
|
| |||||||
EVn (Event ID n) | O | UINT | 4 | |||||||
Описание полей:
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 Туре) - определяет тип события:
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 - Формат структуры данных отдельной структуры BSD сервиса EGTS_EUROPROTOCOL_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
NID (Network Identifier) | M | BINARY | 3 | |||||||
LAC (Local Area Code) | M | UINT | 4 | |||||||
CID (Cell Identifier) | M | SHORT | 2 | |||||||
SS (Signal Strength) | M | BYTE | 1 | |||||||
Описание полей:
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 - Структура подзаписи EGTS_SR_EP_TRACK_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
AT (Absolute Time) | M | UINT | 4 | |||||||
RSA (Relative Structures Amount) | M | BYTE | 1 | |||||||
TS (Time Shift) | CS | B#H | RTU | M | BYTE | 1 | ||||
TDS (Track Data Structure ) | M | BINARY | 1, 13 | |||||||
RTDS1 (Relative Track Data Structure 1) | O | BINARY | 1, 9 | |||||||
... |
|
|
| |||||||
RTDS255 (Relative Track Data Structure 255) | O | BINARY | 1, 9 | |||||||
Описание полей:
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
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
LOHS | LAHS | SPDH (Speed High Bits) | TDE | M | BYTE | 1 | ||||
LAT (Latitude) | O | UINT | 4 | |||||||
LONG (Longitude) | O | UINT | 4 | |||||||
SPDL (Speed Low Bits) | O | BYTE | 1 | |||||||
ALTL (Altitude Low Bits) | O | BYTE | 1 | |||||||
DIRH | ALTS | ALTH (Altitude High Bits) | О | BYTE | 1 | |||||
DIRL (Direction Low Bits) | O | BYTE | 1 | |||||||
Описание полей:
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 - Формат структуры RTDS данных точки изменения траектории движения ТС от точки к точке под-записи EGTS_SR_EP_TRACK_DATA сервиса EGTS_EUROPROTOCOL_SERVICE при неизменном навигационном решении
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
TDV | TMS (Time Shift) | RST | M | BYTE | 1 | |||||
Описание полей:
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 - Формат структуры RTDS данных точки определения траектории движения ТС от точки к точке подзаписи EGTS_SR_EP_TRACK_DATA сервиса EGTS_EUROPROTOCOL_SERVICE при определении навигационного решения
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SPDS | SPDH | SPDE | TMS | RST | M | BYTE | 1 | |||
LATDL (Latitude Delta Low Bits) | M | BYTE | 1 | |||||||
DIRH | M | LATDH (Latitude Delta High Bits) | M | BYTE | 1 | |||||
LONDL (Longitude Delta Low Bits) | M | BYTE | 1 | |||||||
ALTE | M | LONDH (Longitude Delta High Bits) | M | BYTE | 1 | |||||
DIRL (Direction Low Bits) | M | BYTE | 1 | |||||||
SPDL (Speed Delta Low Bits) | O | BYTE | 1 | |||||||
ALTS | ALTD (Altitude Delta) | O | BYTE | 1 | ||||||
Описание полей:
RST (Relative Ttrack Data Structure Type) - тип структуры данных для передачи изменений параметров движения и точек траектории движения ТС. Для структуры, описанной в таблице 10, равно 1;
TMS (Time Shift) - приращение ко времени определения предыдущей структуры RTDS (для первой записи RTDS приращение к полю AT), указанное в единицах, установленных полем RTU. Максимальный диапазон приращения равен семи интервалам, установленным полем RTU. Если навигационное решение остается неизменным в течение более длительного периода, то следует применить структуру, описанную в таблице 57;
LATDL, LATDH - младшие 8 бит и старшие 6 бит изменения широты соответственно (изменение WGS 84 в rpaflycax)/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 - Структура подзаписи EGTS_SR_EP_ACCEL_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
AT (Absolute Time) | M | UINT | 4 | |||||||
ATMSL (Absolute Time Milliseconds Low Bits) | M | BYTE | 1 | |||||||
B#H | - | ATMSH | M | BYTE | 1 | |||||
RSAL (Relative Structures Amount Low Bits) | M | BYTE | 1 | |||||||
- | RSAH | RTU | MU | M | BYTE | 1 | ||||
ADS (Accelerometer Data Structure) | M | BINARY | 6 | |||||||
ARDS1 (Accelerometer Relative Data Structure 1) | O | BINARY | 1, 3 | |||||||
... |
|
|
| |||||||
ARDS1023 (Accelerometer Relative Data Structure 1023) | O | BINARY | 1, 3 | |||||||
Описание полей:
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,
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 - Формат структуры ADS данных показаний акселерометра подзаписи EGTS_SR_EP_ACCEL_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
XAAV (X Axis Acceleration Value) | M | SHORT | 2 | |||||||
YAAV (Y Axis Acceleration Value) | M | SHORT | 2 | |||||||
ZAAV (Z Axis Acceleration Value) | M | SHORT | 2 | |||||||
Описание полей:
XAAV - значение линейного ускорения по оси х в единицах и с дискретностью измерений, установленных полем MU (см. таблицу 59);
YAAV - значение линейного ускорения по оси у в единицах и с дискретностью измерений, установленных полем MU (см. таблицу 59);
ZAAV - значение линейного ускорения по оси z в единицах и с дискретностью измерений, установленных полем MU (см. таблицу 59).
Примечания
1 Ось x направлена параллельно к продольной оси ТС. Положительное направление оси х соответствует движению вперед.
2 Ось y направлена перпендикулярно к оси x в плоскости, параллельной поверхности Земли. Положительному направлению оси y соответствует направление влево.
3 Ось z перпендикулярна к осям x и y. Положительному направлению оси z соответствует направление вверх.
Возможны два варианта структур ARDS:
- структура, содержащая изменения показаний акселерометра по осям (поле RST равно 0);
- структура, показывающая, что в течение определенного времени изменений показаний акселерометра нет ни по одной из осей (поле RST равно 1).
Таблица 62 - Формат структуры ARDS данных изменения показаний акселерометра подзаписи EGTS_SR_EP_ACCEL_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт | ||
XAADH | ZAS | YAS | XAS | TMS | RST | M | BYTE | 1 | ||||
YAADL | XAADL | M | BYTE | 1 | ||||||||
ZAAD | YAADH | M | BYTE | 1 | ||||||||
Описание полей:
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 - Формат структуры ARDS данных при неизменности показаний акселерометра в течение длительного периода времени
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
TMS | RST | M | BYTE | 1 | ||||||
Описание полей:
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 - Структура подзаписи EGTS_SR_EP_ACCEL_DATA2
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
AT (Absolute Time) | M | UINT | 4 | |||||||
ATMSL (Absolute Time Milliseconds Low Bits) | M | BYTE | 1 | |||||||
B#H | - | ATMSH | М | BYTE | 1 | |||||
RSAL (Relative Structures Amount Low Bits) | M | BYTE | 1 | |||||||
- | RSAH | RTU | MU | М | BYTE | 1 | ||||
ADS (Accelerometer Data Structure) | M | BINARY | 6 | |||||||
ARSDS1 (Accelerometer Relative Short Data Structure 1) | O | BINARY | 1, 2 | |||||||
... |
|
|
| |||||||
ARSDS1023 (Accelerometer Relative Short Data Structure 1023) | O | BINARY | 1, 2 | |||||||
Физический смысл, размерность и формат всех полей от начала записи и до структуры 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, то в структуре не передается приращение величины ускорения по оси х (поля XAS и XAD не присутствуют в битовом потоке, а далее следует сразу поле ZAP).
Если бит XAP установлен в 1, то далее в битовом потоке должны быть представлены поля XAS и XAD следующего формата:
- XAS (X Accel data Sign) - однобитовое поле, определяющее знак приращения величины ускорения по оси х:
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 - Структура подзаписи EGTS_SR_EP_ACCEL_DATA 3
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
AT (Absolute Time) | M | UINT | 4 | |||||||
ATMSL (Absolute Time Milliseconds Low Bits) | M | BYTE | 1 | |||||||
B#H | - | ATMSH | М | BYTE | 1 | |||||
RSAL (Relative Structures Amount Low Bits) | M | BYTE | 1 | |||||||
- | RSAH | RTU | MU | М | BYTE | 1 | ||||
ADS (Accelerometer Data Structure) | M | BINARY | 6 | |||||||
AD1 (Accelerometer Data 1) | O | BINARY | 1, 7 | |||||||
... |
|
|
| |||||||
AD1023 (Accelerometer Data 1023) | O | BINARY | 1, 7 | |||||||
Назначение, размерность и формат всех полей от начала записи и до структуры 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 - Структура AD (Accelerometer Data) подзаписи EGTS_SR_EP_ACCEL_DATA 3
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
TMS | RST | M | BYTE | 1 | ||||||
XAAV (X Axis Acceleration Value) | M | SHORT | 2 | |||||||
YAAV (Y Axis Acceleration Value) | M | SHORT | 2 | |||||||
ZAAV (Z Axis Acceleration Value) | M | SHORT | 2 | |||||||
Описание полей:
RST (Relative Accelerometer Data Structure Type) -должно быть установлено в 0;
TMS (Time Shift) - приращение ко времени определения предыдущей структуры AD (для первой записи AD приращение к полю AT), указанное в единицах времени, установленных полем RTU. В течение всего этого времени по всем трем осям измеренные акселерометром значения ускорений были точно такими же, что и в предыдущей структуре AD, в пределах погрешности и дискретности представления показаний, установленных полем RTU. Максимальное значение поля равно 127 единицам RTU;
XAAV - значение линейного ускорения по оси х в единицах и с дискретностью, установленных полем MU (см. таблицу 59);
YAAV - значение линейного ускорения по оси у в единицах и с дискретностью, установленных полем 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) данному буферу присваивается очередное значение В#(в цикле от 0 до 1023), которое помещается в поля В# и В#Н в начале подзаписи EGTS_SR_EP_ACCEL_DATA, EGTS_SR_EP_ACCEL_DATA2 или EGTS_SR_EP_ACCEL_DATA3, заполняются поля RSAL и RSAH по числу накопленных в буфере структур, буфер может передаваться на формирование кода аутентификации, которое занимает определенное время;
2) одновременно с процедурой, указанной в перечислении 1), начинается формирование следующего буфера данных с профилем ускорения;
3) сформированный буфер данных с профилем ускорения, а также его код аутентификации сохраняются вместе в энергонезависимой памяти.
Алгоритмы 1)-3) реализуются циклически. Буферы данных и их коды аутентификации удаляются по истечении интервала времени.
9.2.5 Подзапись EGTS_SR_EP_SIGNATURE
Подзапись EGTS_SR_EP_SIGNATURE, структура которой приведена в таблице 67, предназначена для предоставления информации о коде аутентификации одного или более массивов данных, передаваемых об одном событии (об одном событии ДТП).
Таблица 67 - Структура подзаписи EGTS_SR_EP_SIGNATURE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
VER (Version) | M | BYTE | 1 | |||||||
SA (Structures Amount) | M | BYTE | 1 | |||||||
ASD1 (Array 1 Signature Data) | M | BINARY | VAR | |||||||
ASD2 (Array 2 Signature Data) | O | BINARY | VAR | |||||||
... | ... | ... | ... | |||||||
ASD255 (Array 255 Signature Data) | O | BINARY | VAR | |||||||
Описание полей:
VER - версия формата блока информации о коде аутентификации (значение для поля VER должно быть установлено в 0);
SA - число структур с массивами данных, соответствующих коду аутентификации. Может быть от одной и более, в зависимости от требуемой схемы подписания массива данных о событии ДТП;
ASD1 ...ASD255 - структуры, содержащие информацию о коде аутентификации одного массива.
Состав структуры ASD приведен в таблице 68.
Таблица 68 - Состав полей структуры ASD подзаписи EGTS_SR_EP_SIGNATURE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# | M | BYTE | 1 | |||||||
KEY# (Key Number) | M | USHORT | 2 | |||||||
ALGID (Algorithm Identifier) | M | UINT | 4 | |||||||
SLNL (Signature Length Low Bits) | M | BYTE | 1 | |||||||
B#H | SLNH (Signature Length High Bits) | M | BYTE | 1 | ||||||
SD (Signature Data) | M | BINARY | VAR | |||||||
Описание полей:
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 - Структура подзаписи EGTS_SR_EP_RAW_DATA
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт | |
B# (Block Number) | M | BYTE | 1 | ||||||||
B#H | MSA (Measurement Structures Amount-1) | M | BYTE | 1 | |||||||
ATM (Absolut Time) | M | UINT | 4 | ||||||||
DATA_GNSS | TIME_GNSS | M | BYTE | 1 | |||||||
MS1 (Measurement Structure 1) | M | BINARY | VAR | ||||||||
MS1 (Measurement Structure 2) | O | BINARY | VAR | ||||||||
... |
|
|
| ||||||||
MS255 (Measurement Structure 64) | O | BINARY | VAR | ||||||||
Описание полей:
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 - Состав структуры MS
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RTM (Relative Time) | M | USHORT | 2 | |||||||
SATA (Satellites Amount) | M | BYTE | 1 | |||||||
SAT# 1 (Number of 1  Satellite) | M | BYTE | 1 | |||||||
SNR 1 (Signal to Noise Ratio 1) | M | BYTE | 1 | |||||||
PR 1 (Pseudo Range 1) | M | UINT | 4 | |||||||
DOP 1 (Dopler 1) | M | INT | 4 | |||||||
SAT# 2 (Number of 2  Satellite) | O | BYTE | 1 | |||||||
SNR 2 (Signal to Noise Ratio 2) | O | BYTE | 1 | |||||||
PR 2 (Pseudo Range 2) | O | UINT | 4 | |||||||
DOP 2 (Dopler 2) | O | INT | 4 | |||||||
... | ... | ... | ... | |||||||
SAT# Last (Number of 2 Satellite) | O | BYTE | 1 | |||||||
SNR Last (Signal to Noise Ratio Last) | O | BYTE | 1 | |||||||
PR Last (Pseudo Range Last) | O | UINT | 4 | |||||||
DOP Last (Dopier Last) | O | INT | 4 | |||||||
Описание полей:
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
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
SRT (Subrecord Type) | M | BYTE | 1 | |||||||
B#H | - | CM | M | BYTE | 1 | |||||
CDL (Compressed Data Length) | M | USHORT | 2 | |||||||
CD (Compressed Data) | M | BINARY | VAR | |||||||
Данные для подзаписи EGTS_SR_EP_COMP_DATA формируются на основе данных какой-либо сформированной подзаписи до момента определения ее кода аутентификации. Ко всему массиву данных сформированной подзаписи применяется алгоритм сжатия данных. Сжатые данные помещаются в поле CD.
Поле CM (Compression Method) служит для указания примененного алгоритма сжатия данных.
Примечание - В поле СМ рекомендуется помещать значение, равное 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.
 |
Рисунок А.1 - Структурная схема взаимодействия элементов системы, основанной на протоколе транспортного уровня
Приложение Б
(справочное)
Анализ протокола транспортного уровня на основе концепции NGTP
Согласно концепции построения телематических систем на основе NGTP различают три основных элемента взаимодействия: телематическое устройство, провайдер телематических сервисов и диспетчер. Взаимодействие осуществляется через стандартизованные интерфейсы и является элементами протокола за исключением провайдера телематических сервисов, который объединен в протоколе с диспетчером.
Телематическое устройство (применительно к настоящему стандарту - УСВ) интегрируется в ТС, но также может быть персональным навигационным устройством или мобильным телефоном.
Провайдер телематических сервисов предназначен для обмена данными между сервисами и телематическими устройствами.
Диспетчер согласно NGTP является посредником между ПТС и ПУ и обеспечивает стандартный интерфейс связи ТУ с другими компонентами системы, обеспечивающими выполнение функционала сервисов. Диспетчер оперирует только данными своего уровня и не анализирует состав данных уровня сервисов.
Заголовок NGTP полностью совпадает с первыми байтами заголовка протокола транспортного уровня: Protocol Version (1 байт), Security Context (2 байта), NGTP HeaderL ength (1 байт), NGTP Header Encoding (1 байт).
В NGTP идентификатором УСВ является VIN/DrivelD, в описываемом протоколе - UNIT_ID.
Для идентификации УСВ, исполненной в конфигурации штатного оборудования, используется VIN.
Как и NGTP, протокол направлен на гибкую маршрутизацию данных сервисов между УСВ и ТП. При этом внедрение нового сервиса не требует доработки протокола, т.к. протоколом производятся только маршрутизации данных, а сама обработка ведется непосредственно в самом сервисе. Необходимо лишь настроить правильную маршрутизацию диспетчера на новый тип сервиса, что реализуется средствами администрирования системы, построенной на основе протокола транспортного уровня.
NGTP оперирует таким понятием, как событие, определяющее некоторую общую характеристику данных и предназначенное для интеграции информации различного типа в некий массив обобщенных данных. Каждому идентификатору события также соответствует признак, идентифицирующий время генерации события. Использование такого механизма обобщения заложено в протоколе транспортного уровня, в котором каждая запись протокола уровня поддержки сервисов (услуг) может содержать идентификатор события, который генерируется источником таких записей в определенный срез времени, например при возникновении ДТП.
В отличие от NGTP, который использует различные интерфейсы между ТУ и диспетчером, диспетчером и ПТС и между ПТС и сервисами, протокол транспортного уровня УСВ использует один интерфейс для связи компонентов.
NGTP использует такое понятие как "триггер", подразумевающий некое уведомление компонентов системы о том, что для них принята информация. Приняв такой "триггер", получатель информации должен запросить данную информацию и обработать. В протоколе транспортного уровня не используются "триггеры", и информация сразу же передается получателю.
Приложение В
(обязательное)
Коды результатов обработки
Коды результатов обработки приведены в таблице В.1.
Таблица В.1 - Коды результатов обработки
Значение | Обозначение | Описание |
0 | EGTS_PC_OK | Успешно обработано |
1 | EGTS_PC_IN_PROGRESS | В процессе обработки (результат обработки еще не известен) |
128 | EGTS_PC_UNS_PROTOCOL | Неподдерживаемый протокол |
129 | EGTS_PC_DECRYPT_ERROR | Ошибка декодирования |
130 | EGTS_PC_PROC_DENIED | Обработка запрещена |
131 | EGTS_PC_INC_HEADERFORM | Неверный формат заголовка |
132 | EGTS_PC_INC_DATAFORM | Неверный формат данных |
133 | EGTS_PC_UNS_TYPE | Неподдерживаемый тип |
134 | EGTS_PC_NOTEN_PARAMS | Неверное число параметров |
135 | EGTS_PC_DBL_PROC | Попытка повторной обработки |
136 | EGTS_PC_PROC_SRC_DENIED | Обработка данных от источника запрещена |
137 | EGTS_PC_HEADERCRC_ERROR | Ошибка контрольной суммы заголовка |
138 | EGTS_PC_DATACRC_ERROR | Ошибка контрольной суммы данных |
139 | EGTS_PC_INVDATALEN | Некорректная длина данных |
140 | EGTS_PC_ROUTE_NFOUND | Маршрут не найден |
141 | EGTS_PC_ROUTE_CLOSED | Маршрут закрыт |
142 | EGTS_PC_ROUTE_DENIED | Маршрутизация запрещена |
143 | EGTS_PC_INVADDR | Неверный адрес |
144 | EGTS_PC_TTLEXPIRED | Превышено число ретрансляции данных |
145 | EGTS_PC_NO_ACK | Нет подтверждения |
146 | EGTS_PC_OBJ_NFOUND | Объект не найден |
147 | EGTS_PC_EVNT_NFOUND | Событие не найдено |
148 | EGTS_PC_SRVC_NFOUND | Сервис не найден |
149 | EGTS_PC_SRVC_DENIED | Сервис запрещен |
150 | EGTS_PC_SRVC_UNKN | Неизвестный тип сервиса |
151 | EGTS_PC_AUTH_DENIED | Авторизация запрещена |
152 | EGTS_PC_ALREADY_EXISTS | Объект уже существует |
153 | EGTS_PC_ID_NFOUND | Идентификатор не найден |
154 | EGTS_PC_INC_DATETIME | Неправильная дата и время |
155 | EGTS_PC_IO_ERROR | Ошибка ввода/вывода |
156 | EGTS_PC_NO_RES_AVAIL | Недостаточно ресурсов |
157 | EGTS_PC_MODULE_FAULT | Внутренний сбой модуля |
158 | EGTS_PC_MODULE_PWR_FLT | Сбой в работе цепи питания модуля |
159 | EGTS_PC_MODULE_PROC_FLT | Сбой в работе микроконтроллера модуля |
160 | EGTS_PC_MODULE_SW_FLT | Сбой в работе программы модуля |
161 | EGTS_PC_MODULE_FW_FLT | Сбой в работе внутреннего программного обеспечения модуля |
162 | EGTS_PC_MODULE_IO_FLT | Сбой в работе блока ввода/вывода модуля |
163 | EGTS_PC_MODULE_MEM_FLT | Сбой в работе внутренней памяти модуля |
164 | EGTS_PC_TEST_FAILED | Тест не пройден |
Примечание - Пакеты сообщений об ошибках (EGTS_PC_DECRYPT_ERROR, EGTS_PC_UNS_PROTOCOL, EGTS_PC_INC_DATAFORM, EGTS_PC_DATACRC_ERROR, EGTS_PC_INC_HEADERFORM, EGTS_PC_HEADERCRC_ERROR) предназначены для целей тестирования оборудования и в рабочей версии программного обеспечения и УСВ могут быть исключены.
| ||
Приложение Г
(справочное)
Пример реализации алгоритма расчета контрольной суммы CRC-16 на языке С/*
Name : CRC-16 CCITT
Poly : 0x1021 х^16 + х^12 + х^5 + 1
Init : 0xFFFF
Revert: false
XorOut: 0x0000
Check: 0x29B1 ("123456789")*/
const unsigned short Crc16Table[256] - {
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
0x7E97, 0X6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
0xEFIF, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0};
unsigned short Crc16(unsigned char * pcBlock, unsigned short len)
{ unsigned short crc - 0xFFFF;
while (len--)
crc - (crc << 8) ^ Crc16Table[(crc >> 8) ^ *pcBlock++];
returncrc;}
Приложение Д
(справочное)
Пример реализации алгоритма расчета контрольной суммы CRC-8 на языке C/*
Name : CRC-8
Poly : 0x31 х^8 + х^5 + х^4 + 1
Init : 0xFF
Revert: false
XorOut: 0x00
Check: 0xF7 ("123456789")
*/
const unsigned char CRC8Table[256] - {
0x00, 0x31, 0x62, 0x53, 0xC4, 0xF5, 0xA6, 0x97,
0xB9, 0x88, 0xDB, 0xEA, 0x7D, 0x4C, 0x1F, 0x2E,
0x43, 0x72, 0x21, 0x10, 0x87, 0xB6, 0xE5, 0xD4,
0xFA, 0xCB, 0x98, 0xA9, 0x3E, 0x0F, 0x5C, 0x6D,
0x86, 0xB7, 0xE4, 0xD5, 0x42, 0x73, 0x20, 0x11,
0x3F, 0x0E, 0x5D, 0x6C, 0xFB, 0xCA, 0x99, 0xA8,
0xC5, 0xF4, 0xA7, 0x96, 0x01, 0x30, 0x63, 0x52,
0x7C, 0x4D, 0x1 E, 0x2F, 0xB8, 0x89, 0xDA, 0xEB,
0x3D, 0x0C, 0x5F, 0x6E, 0xF9, 0xC8, 0x9B, 0xAA,
0x84, 0xB5, 0xE6, 0xD7, 0x40, 0x71, 0x22, 0x13,
0x7E, 0x4F, 0x1C, 0x2D, 0xBA, 0x8B, 0xD8, 0xE9,
0xC7, 0xF6, 0xA5, 0x94, 0x03, 0x32, 0x61, 0x50,
0xBB, 0x8A, 0xD9, 0xE8, 0x7F, 0x4E, 0x1 D, 0x2C,
0x02, 0x33, 0x60, 0x51, 0xC6, 0xF7, 0xA4, 0x95,
0xF8, 0xC9, 0x9A, 0xAB, 0х3C, 0x0D, 0x5E, 0x6F,
0x41, 0x70, 0x23, 0x12, 0x85, 0xB4, 0xE7, 0xD6,
0x7A, 0x4B, 0x18, 0x29, 0xBE, 0x8F, 0xDC, 0xED,
0хC3, 0xF2, 0xA1, 0x90, 0x07, 0x36, 0x65, 0x54,
0x39, 0x08, 0x5В, 0x6A, 0xFD, 0xCC, 0x9F, 0xAE,
0x80, 0xB1, 0xE2, 0xD3, 0x44, 0x75, 0x26, 0x17,
0xFC, 0xCD, 0x9E, 0xAF, 0x38, 0x09, 0x5A, 0x6B,
0x45, 0x74, 0x27, 0x16, 0x81, 0xB0, 0xE3, 0xD2,
0xBF, 0x8E, 0xDD, 0xEC, 0x7B, 0x4A, 0x19, 0x28,
0x06, 0x37, 0x64, 0x55, 0xC2, 0xF3, 0xA0, 0x91,
0x47, 0x76, 0x25, 0x14, 0x83, 0xB2, 0xE1, 0xD0,
0xFE, 0xCF, 0x9C, 0xAD, 0x3A, 0x0B, 0x58, 0x69,
0x04, 0x35, 0x66, 0x57, 0xC0, 0xF1, 0xA2, 0x93,
0xBD, 0x8C, 0xDF, 0xEE, 0x79, 0x48, 0x1 B, 0x2A,
0xC1, 0xF0, 0xA3, 0x92, 0x05, 0x34, 0x67, 0x56,
0x78, 0x49, 0x1A, 0x2B, 0xBC, 0x8D, 0xDE, 0xEF,
0x82, 0xB3, 0xE0, 0xD1, 0x46, 0x77, 0x24, 0x15,
0x3B, 0x0A, 0x59, 0x68, 0xFF, 0xCE, 0x9D, 0xAC
};
unsigned char CRC8(unsigned char *IpBlock, unsigned char len)
{
unsigned char crc - 0xFF;
while (len--)
crc - CRC8Table[crc ^ *lpBlock++];
return crc;
}
Приложение Е
(справочное)
Таблицы кодировки символов
Е.1 Кодировка символов латинского алфавита приведена на рисунке Е.1.
 |
Рисунок Е.1 - Кодировка символов латинского алфавита
Е.2 Кодировка символов латинского и кириллического алфавитов приведена на рисунке Е.2.
 |
Рисунок Е.2 - Кодировка символов латинского и кириллического алфавитов
Е.3 Кодировка символов латинского и древнееврейского алфавитов приведена на рисунке Е.3.
 |
Рисунок Е.3 - Кодировка символов латинского и древнееврейского алфавитов
Приложение Ж
(обязательное)
Описание протокола уровня поддержки услуг (протокола EGTS) версии "01"
Описание ППУ (протокола EGTS) версии "02", являющегося развитием предыдущей версии ППУ версии "01".
В приложении приведены описания сервисов в части отличий от версии "02". Реализуя приведенные в данном приложении отличия - обеспечивается работа согласно версии протокола "01".
Ж.1 Перечень сервисов и подсервисов, в части которых внесены изменения при переходе с протокола версии "01" на протокол версии "02".
Таблица Ж.1 - Перечень сервисов и подзаписей, в части которых внесены изменения при переходе с протокола версии "01" к протоколу версии "02"
N | Раздел | Характер изменений |
1 | Список сервисов, поддерживаемых протоколом | Добавлен сервис передачи сообщений EGTS_NOTIFICATION_SERVICE
Добавлен сервис представления информации об обстоятельствах ДТП EGTS_EUROPROTOCOL_SERVICE |
2 | Список подзаписей сервиса EGTS_AUTH_SERVICE | Добавлены подзаписи EGTS_SR_DISPATCHER_IDENTITY, EGTS_SR_VEHICLE_DATA_ADD |
3 | Структуры данных, используемые в протоколе уровня поддержки услуг | OID (Object Identifier) изменена длина поля с 4 до 8 байт |
4 | Сервис EGTS_AUTH_SERVICE
Подзапись EGTS_SR_TERM_IDENTITY | TID (Terminalldentifier) изменена длина поля с 4 до 8 байт Добавлено поле SSLPV (Service Support Level Protocol Version) |
5 | Сервис EGTS_AUTH_SERVICE
Подзапись EGTS_SR_VEHICLE_DATA | Изменены состав и идентификаторы полей |
6 | Сервис EGTS_TELEDATA_SERVICE
Подзапись EGTS_SR_POS_DATA | Расширен состав полей |
7 | Сервис EGTS_COMMANDS_SERVICE
Список команд для УСВ | Расширен список команд и соответствующих подтверждений команд:
EGTS_TEST_GET_ERRORS
EGTS_TEST_CLEAR_ERRORS
EGTS_SET_ON_READY
EGTS_SET_OFF_READY
EGTS_SET_ON_ACCIDENT
EGTS_SET_OFF_ACCIDENT
EGTS_SEND_ACCIDENT_DATA
EGTS_SET_ON_MONITOR
EGTS_SET_OFF_MONITOR
EGTS_SET_PROTOCOL_CHOICE
EGTS_START_SEND_READY
EGTS_STOP_SEND_RAEDY
EGTS_SEND_MONITOR |
8 | Сервис EGTS_COMMANDS_SERVICE
Список параметров УСВ | Расширен список параметров:
ERA_TO_EMERGENCY_CALL_AUTO_TRANSITION
ERA_TO_EMERGENCY_CALL_MANUAL_TRANSITION
ERA_TO_EMERGENCY_CALL_TRANSITION_PERIOD
EGTS_SELFTEST_INTERVAL
EGTS_POST_TEST_REGISTRATION_TIME
EGTS_TEST_REGISTRATION_TIMEOUT
EGTS_TEST_MODE_WATCHDOG
EGTS_USE_GPRS_WHITE_LIST
EGTS_GPRS_WHITE_LIST
EGTS_UNIT_ANGUAGE_ID
EGTS_READY_PROFILE
|
|
| EGTS_MONITOR_PROFILE
EGTS_CONNECT_ACCIDENT
EGTS_PROTOCOL_CHOICE
EGTS_VEHICLE_VSRM
EGTS_VEHICLE_VM
EGTS_VEHICLE_VB
EGTS_VEHICLE_VOTIN
EGTS_VEHICLE_VOPSRN
EGTS_VEHICLE_VON
EGTS_FLEET_IGN_ON_PERIOD_READY
EGTS_FLEET_IGN_OFF_PERIOD_READY
EGTS_FLEET_DIST_THRESHOLD_READY
EGTS_FLEET_COURSE_THRESHOLD_READY
EGTS_FLEET_MAX_SPEED_THRESHOLD_READY
EGTS_FLEET_MIN_SPEED_THRESHOLDS_READY
EGTS_FLEET_MIN_BATTERY_VOLTAGE_READY
EGTS_FLEET_POS_ACCEL_THRESHOLD_READY
EGTS_FLEET_NEG_ACCEL_THRESHOLD_READY
EGTS_CONNECT_READY
EGTS_FLEET_IGN_ON_PERIOD_MONITOR
EGTS_FLEET_IGN_OFF_PERIOD_MONITOR
EGTS_FLEET_DIST_THRESHOLD_MONITOR
EGTS_FLEET_COURSE_THRESHOLD_MONITOR
EGTS_FLEET_MAX_SPEED_THRESHOLD_MONITOR
EGTS_FLEET_MIN_SPEED_THRESHOLDS_MONITOR
EGTS_FLEET_MIN_BATTERY_VOLTAGE_MONITOR
EGTS_FLEET_POS_ACCEL_THRESHOLD_MONITOR
EGTS_FLEET_NEG_ACCEL_THRESHOLD_MONITOR
EGTS_CONNECT_MONITOR |
9 | Сервис EGTS_TELEDATA_SERVICE | Добавлено описание сервиса EGTS_TELEDATA_SERVICE приложением к стандарту |
10 | Сервис EGTS_TELEDATA_SERVICE Список подзаписей | Расширен список подзаписей, добавлены следующие подзаписи:
EGTS_SR_SIGNATURE
EGTS_SR_ACCEL_DATA_SIG
EGTS_SR_POS_DATA_SIG
EGTS_SR_EXT_POS_DATA_SIG
EGTS_SR_WEIGHT_CONTROL
Расширен список подзаписей, добавлены декларации перспективных блоков спецификации, разрабатываемых совместно с производителем оборудования:
EGTS_SR_CARGO_DATA
EGTS_SR_AUTOPILOT
EGTS_SR_CAN_DATA
EGTS_SR_CAM_DATA
EGTS_SR_CLEANING_DATA
EGTS_SR_DIAG
EGTS_SR_DISPATCHING
EGTS_SR_MESSAGES
EGTS_SR_PAYMENT_DATA
EGTS_SR_RFID_DATA
EGTS_SR_TOLL_DATA
EGTS_SR_EXT_DATA |
11 | Сервис EGTS_TELEDATA_SERVICE Подзапись EGTS_SR_POS_DATA | Расширен состав полей |
12 | Сервис EGTS_TELEDATA_SERVICE
Подзапись EGTS_SR_POS_DATA_SIG | Расширен состав полей |
13 | Список источников посылок координатных данных сервиса EGTS_TELEDATA_SERVICE | Добавлен источник 36 срабатывания датчика задымления и/ или быстрого повышения температуры на борту транспортного средства |
Ж.2 Структуры данных, используемые в протоколе уровня поддержки услуг для версии протокола "01"
Структура записи
Структура отдельной записи уровня поддержки услуг приведена в таблице Ж.2.
Таблица Ж.2 - Формат отдельной записи протокола уровня поддержки услуг для версии протокола "01"
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RL (Record Length) | M | USHORT | 2 | |||||||
RN (Record Number) | M | USHORT | 2 | |||||||
RFL (Record Flags) | M | BYTE | 1 | |||||||
SSOD | RSOD | RPP | TMFE | EVFE | OBFE |
|
|
| ||
OID (Object Identifier) | O | ULONG | 4 | |||||||
EVID (Event Identifier) | O | UINT | 4 | |||||||
TM (Time) | O | UINT | 4 | |||||||
SST (Source Service Type) | M | BYTE | 1 | |||||||
RST (Recipient Service Type) | M | BYTE | 1 | |||||||
RD (Record Data) | M | BINARY | 3... 65494 | |||||||
Ж.3 Сервис EGTS_AUTH_SERVICE
Подзапись EGTS_SR_TERM_IDENTITY
Структура подзаписи приведена в таблице Ж.3.
Таблица Ж.3 - Формат подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE для версии протокола "01"
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
TID (Terminalldentifier) | M | ULONG | 4 | |||||||
Flags | M | BYTE | 1 | |||||||
MNE | BSE | NIDE | SSRA | LNGCE | IMSIE | IMEIE | HDIDE |
|
|
|
HDID (Home Dispatcher Identifier) | O | USHORT | 2 | |||||||
IMEI (International Mobile Equipment Identity) | O | STRING | 15 | |||||||
IMSI (International Mobile Subscriber Identity) | O | STRING | 16 | |||||||
LNGC (Language Code) | O | STRING | 3 | |||||||
NID (Network Identifier) | O | BINARY | 3 | |||||||
BS (Buffer Size) | O | USHORT | 2 | |||||||
MSISDN (Mobile Station Integrated Services Digital Network Number) | O | STRING | 15 | |||||||
Подзапись EGTS_SR_VEHICLE_DATA
Таблица Ж.4 - Формат подзаписи EGTS_SR_VEHICLE_DATA сервиса EGTS_AUTH_SERVICE для версии протокола "01"
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
VIN (Vehicle Identification Number) | M | STRING | 17 | |||||||
VHT (Vehicle Type) | M | UINT | 4 | |||||||
VPST (Vehicle Propulsion Storage Type) | M | UINT | 4 | |||||||
Поля подзаписи 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"
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
NTM (Navigation Time) | M | UINT | 4 | |||||||
LAT (Latitude) | M | UINT | 4 | |||||||
LONG (Longitude) | M | UINT | 4 | |||||||
FLG (Flags) | M | BYTE | 1 | |||||||
ALTH | LOHS | LAHS | MV | BB | CS | FIX | VLD |
|
|
|
SPD (Speed) младшие биты | M | USHORT | 2 | |||||||
DIRH | ALTS | SPD (Speed) старшие биты |
|
|
| |||||
DIR (Direction) | M | BYTE | 1 | |||||||
ODM (Odometer) | M | BINARY | 3 | |||||||
DIN (Digital Inputs) | M | BYTE | 1 | |||||||
SRC (Source) | M | BYTE | 1 | |||||||
ALT (Altitude) | O | BINARY | 3 | |||||||
SRCD (Source Data) | O | SHORT | 2 | |||||||
Таблица Ж.6 - Формат подзаписи EGTS_SR_POS_DATA_SIG сервиса EGTS_TELEDATA_SERVICE для версии протокола "01"
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт | |
# (Block Number) | M | BYTE | 1 | ||||||||
NTM (Navigation Time) | M | UINT | 4 | ||||||||
LAT (Latitude) | M | UINT | 4 | ||||||||
LONG (Longitude) | M | UINT | 4 | ||||||||
FLG (Flags) | M | BYTE | 1 | ||||||||
ALTH | LOHS | LAHS | MV | BB | CS | FIX | VLD |
|
|
| |
SPD (Speed) младшие биты | M | USHORT | 2 | ||||||||
DIRH | ALTS | SPD (Speed) старшие биты |
|
|
| ||||||
DIR (Direction) | M | BYTE | 1 | ||||||||
ODM (Odometer) | M | BINARY | 3 | ||||||||
DIN (Digital Inputs) | M | BYTE | 1 | ||||||||
SRC (Source) | M | BYTE | 1 | ||||||||
ALT (Altitude) | O | BINARY | 3 | ||||||||
SRCD (Source Data) | O | SHORT | 2 | ||||||||
Приложение И
(обязательное)
Спецификация сервиса передачи и обработки мониторинговой информации EGTS_TELEDATA_SERVICE
И.1 Состав сервиса EGTS_TELEDATA_SERVICE
Сервис EGTS_TELEDATA_SERVICE предназначен для передачи мониторинговой информации между УСВ и телематическими системами (аппаратно-программными комплексами), а также между двумя телематическими системами мониторинговой информации, полученной от УСВ.
Список подзаписей, используемых сервисом EGTS_TELEDATA_SERVICE, представлен в таблице И.1.
Таблица И.1 - Список подзаписей сервиса EGTS_TELEDATA_SERVICE
Код | Наименование | Описание |
0 | EGTS_SR_RECORD_RESPONSE | Применяется для осуществления подтверждения приема и передачи результатов обработки записи уровня поддержки услуг |
16 | EGTS_SR_POS_DATA | Используется при передаче основных данных определения местоположения |
17 | EGTS_SR_EXT_POS_DATA | Используется при передаче дополнительных данных определения местоположения |
18 | EGTS_SR_AD_SENSORS_DATA | Применяется для передачи информации о состоянии дополнительных дискретных и аналоговых входов |
19 | EGTS_SR_COUNTERS_DATA | Используется для передачи данных о значении счетных входов |
20 | EGTS_SR_STATE_DATA | Используется для передачи информации о состоянии УСВ |
21 | EGTS_SR_ACCEL_DATA | Применяется для передачи данных истории ускорения ТС, в том числе профиля ускорения при ДТП |
22 | EGTS_SR_LOOPIN_DATA | Применяется для передачи данных о состоянии шлейфовых входов |
23 | EGTS_SR_ABS_DIG_SENS_DATA | Применяется для передачи данных о состоянии одного дискретного входа |
24 | EGTS_SR_ABS_AN_SENS_DATA | Применяется для передачи данных о состоянии одного аналогового входа |
25 | EGTS_SR_ABS_CNTR_DATA | Применяется для передачи данных о состоянии одного счетного входа |
26 | EGTS_SR_ABS_LOOPIN_DATA | Применяется для передачи данных о состоянии одного шлей-фового входа |
27 | EGTS_SR_LIQUID_LEVEL_SENSOR | Применяется для передачи данных о показаниях ДУЖ |
28 | EGTS_SR_PASSENGERS_COUNTERS | Применяется для передачи данных о показаниях счетчиков пассажиропотока |
29 | EGTS_SR_SIGNATURE | Применяется УСВ для передачи информации по коду аутентификации массива данных о мониторинговой информации |
30 | EGTS_SR_ACCEL_DATA_SIG | Применяется для передачи данных истории ускорения ТС, в том числе профиля ускорения при ДТП в некорректируемом виде |
31 | EGTS_SR_POS_DATA_SIG | Используется УСВ при передаче основных данных определения местоположения в некорректируемом виде |
32 | EGTS_SR_EXT_POS_DATA_SIG | Используется УСВ при передаче дополнительных данных определения местоположения в некорректируемом виде |
33 | EGTS_SR_CARGO_DATA | Применяется для передачи данных о показаниях датчиков состояния перевозимого груза. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
34 | EGTS_SR_AUTOPILOT | Применяется для передачи данных для реализации управления автопилотируемым ТС. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
35 | EGTS_SR_CAN_DATA | Применяется для передачи данных о состоянии узлов и агрегатов ТС. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
36 | EGTS_SR_CAM_DATA | Применяется для передачи данных о состоянии, событиях видеорегистратора и видеокамер наблюдения, а также управления приемом, накоплением и передачей видеоизображений с видеокамер, аудиосигналов с микрофонов (в режиме фотографий и/или в режиме реального времени). Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
37 | EGTS_SR_CLEANING_DATA | Применяется для передачи данных датчиков специализированных ТС, в том числе ТС коммунальных служб. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
38 | EGTS_SR_DIAG | Применяется для передачи диагностических сообщений. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
39 | EGTS_SR_DISPATCHING | Применяется для передачи данных диспетчирования общественного транспорта. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
40 | EGTS_SR_MESSAGES | Применяется для передачи данных формализованных и неформализованных сообщений. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
41 | EGTS_SR_PAYMENT_DATA | Применяется для передачи данных контроля оплаты проезда. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
42 | EGTS_SR_RFID_DATA | Применяется для передачи данных считывания RFID меток. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
43 | EGTS_SR_TOLL_DATA | Применяется для передачи данных информации с платных дорог. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
44 | EGTS_SR_EXT_DATA | Применяется для передачи данных для передачи расширенного набора показаний датчиков и/или расчетных на стороне УСВ параметров. Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования |
45 | EGTS_SR_WEIGHT_CONTROL | Используется для передачи данных от систем мониторинга осевой нагрузки (данных от датчиков нагрузки на оси ТС) и аналогичных |
В случае подключения дополнительного бортового оборудования к УСВ на борту ТС включение в состав мониторинговой информации и передача соответствующих данных от этого оборудования могут быть реализованы через передачу данных в подзаписях 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_SR_POS_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
NTM (Navigation Time) | M | UINT | 4 | |||||||
LAT (Latitude) | M | UINT | 4 | |||||||
LONG (Longitude) | M | UINT | 4 | |||||||
FLG (Flags) | M | BYTE | 1 | |||||||
ALTH | LOHS | LAHS | MV | BB | CS | FIX | VLD |
|
|
|
SPD (Speed) младшие биты | M | USHORT | 2 | |||||||
DIRH | ALTS | SPD (Speed) старшие биты |
|
|
| |||||
DIR (Direction) | M | BYTE | 1 | |||||||
ODM (Odometer) | M | BINARY | 3 | |||||||
DIN (Digital Inputs) | M | BYTE | 1 | |||||||
SRC (Source) | M | BYTE | 1 | |||||||
NID (Network Identifier) | M | BINARY | 3 | |||||||
LAC (Local Area Code) | M | UINT | 4 | |||||||
CID (Cell Identifier) | M | SHORT | 2 | |||||||
SS (Signal Strength) | M | BYTE | 1 | |||||||
ALT (Altitude) | O | BINARY | 3 | |||||||
SRCD (Source Data) | O | SHORT | 2 | |||||||
Поля таблицы И.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 - Формат поля NID подзаписи EGTS_SR_POS_DATA
Биты 20...23 | Биты 10...19 | Биты 0...9 | Тип | Тип данных | Размер, байт |
- | МСС (Mobile Country Code) | MNC (Mobile Network Code) | M | BINARY | 3 |
LAC - идентификатор локальной зоны базовой станции сети ПРСТ, наблюдаемой УСВ на текущий момент;
CID - идентификатор ячейки базовой станции ПРСТ, наблюдаемой УСВ на текущий момент;
ALT - высота над уровнем моря, м (опциональный параметр, наличие которого определяется битовым флагом ALTE);
SRCD - данные, характеризующие источник (событие) из поля SRC. Наличие и интерпретация значения данного поля определяется полем SRC.
Таблица И.4 - Список источников посылок координатных данных сервиса EGTS_TELEDATA_SERVICE
Код | Описание |
0 | Таймер при включенном зажигании |
1 | Пробег заданной дистанции |
2 | Превышение установленного значения угла поворота |
3 | Ответ на запрос |
4 | Изменение состояния входа X |
5 | Таймер при выключенном зажигании |
6 | Отключение периферийного оборудования |
7 | Превышение одного из заданных порогов скорости |
8 | Перезагрузка центрального процессора (рестарт) |
9 | Перегрузка по выходу Y |
10 | Сработал датчик вскрытия корпуса прибора |
11 | Переход на резервное питание/отключение внешнего питания |
12 | Снижение напряжения источника резервного питания ниже порогового значения |
13 | Нажата "кнопка связи (тревожная кнопка)" |
14 | Запрос на установление голосовой связи с оператором |
15 | Экстренный вызов |
16 | Появление данных от внешнего сервиса |
17 | Зарезервировано |
18 | Зарезервировано |
19 | Неисправность резервного аккумулятора |
20 | Резкий разгон |
21 | Резкое торможение |
22 | Отключение или неисправность навигационного модуля |
23 | Отключение или неисправность датчика автоматической идентификации события ДТП |
24 | Отключение или неисправность антенны GSM |
25 | Отключение или неисправность антенны навигационной системы |
26 | Зарезервировано |
27 | Снижение скорости ниже одного из заданных порогов |
28 | Перемещение при выключенном зажигании |
29 | Таймер в режиме "экстренное слежение" |
30 | Начало/окончание навигации |
31 | "Нестабильная навигация" (превышение порога частоты прерывания режима навигации при включенном зажигании или режиме экстренного слежения) |
32 | Установка IP соединения |
33 | Нестабильная регистрация в сети ПРТС |
34 | "Нестабильная связь"(превышение порога частоты прерывания/восстановления IP соединения при включенном зажигании или режиме экстренного слежения) |
35 | Изменение режима работы |
36 | Срабатывания датчика задымления и/или быстрого повышения температуры на борту ТС |
Подзапись EGTS_SR_EXT_POS_DATA
Структура подзаписи представлена в таблице И.5.
Таблица И.5 - Формат подзаписи EGTS_SR_EXT_POS_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
- | NSFE | SFE | PFE | HFE | VFE | M | BYTE | 1 | ||
VDOP (Vertical Dilution of Precision) | O | USHORT | 2 | |||||||
HDOP (Horizontal Dilution of Precision) | O | USHORT | 2 | |||||||
PDOP (Position Dilution of Precision) | O | USHORT | 2 | |||||||
SAT (Satellites) | O | BYTE | 1 | |||||||
NS (Navigation System) | O | USHORT | 2 | |||||||
Поля таблицы И.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_SR_AD_SENSORS__DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
DIOE8 | DIOE7 | DIOE6 | DIOE5 | DIOE4 | DIOE3 | DIOE2 | DIOE1 | M | BYTE | 1 |
DOUT (Digital Outputs) | M | BYTE | 1 | |||||||
ASFE8 | ASFE7 | ASFE6 | ASFE5 | ASFE4 | ASFE3 | ASFE2 | ASFE1 | M | BYTE | 1 |
ADIO1 (Additional Digital Inputs Octet 1) | O | BYTE | 1 | |||||||
ADIO2 (Additional Digital Inputs Octet 2) | O | BYTE | 1 | |||||||
ADIO3 (Additional Digital Inputs Octet 3) | O | BYTE | 1 | |||||||
ADIO4 (Additional Digital Inputs Octet 4) | O | BYTE | 1 | |||||||
ADIO5 (Additional Digital Inputs Octet 5) | O | BYTE | 1 | |||||||
ADIO6 (Additional Digital Inputs Octet 6) | O | BYTE | 1 | |||||||
ADIO7 (Additional Digital Inputs Octet 7) | O | BYTE | 1 | |||||||
ADIO8 (Additional Digital Inputs Octet 8) | O | BYTE | 1 | |||||||
ANS1 (Analog Sensor 1) | O | BINARY | 3 | |||||||
ANS2 (Analog Sensor 2) | O | BINARY | 3 | |||||||
ANS3 (Analog Sensor 3) | O | BINARY | 3 | |||||||
ANS4 (Analog Sensor 4) | O | BINARY | 3 | |||||||
ANS5 (Analog Sensor 5) | O | BINARY | 3 | |||||||
ANS6 (Analog Sensor 6) | O | BINARY | 3 | |||||||
ANS7 (Analog Sensor 7) | O | BINARY | 3 | |||||||
ANS8 (Analog Sensor 8) | O | BINARY | 3 | |||||||
Поля таблицы И.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_SR_COUNTERS_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
CFE8 | CFE7 | CFE6 | CFE5 | CFE4 | CFE3 | CFE2 | CFE1 | M | BYTE | 1 |
CN1 (Counter 1) | O | BINARY | 3 | |||||||
CN2 (Counter 2) | O | BINARY | 3 | |||||||
CN3 (Counter 3) | O | BINARY | 3 | |||||||
CN4 (Counter 4) | O | BINARY | 3 | |||||||
CN5 (Counter 5) | O | BINARY | 3 | |||||||
CN6 (Counter 6) | O | BINARY | 3 | |||||||
CN7 (Counter 7) | O | BINARY | 3 | |||||||
CN8 (Counter 8) | O | BINARY | 3 | |||||||
Поля таблицы И.7 содержат:
CFE1 ... CFE8 (CounterFieldExists) - битовые флаги определяют наличие соответствующих полей счетных входов:
1 - соответствующее поле CN передается,
0 - не передается;
CN1 ... CN8 - значение счетных входов с 1 по 8 соответственно.
Подзапись EGTS_SR_STATE_DATA
Структура подзаписи представлена в таблице И.8.
Таблица И.8 - Формат подзаписи EGTS_SR_STATE_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ST (State) | M | BYTE |
| |||||||
MPSV (Main Power Source Voltage) | M | BYTE |
| |||||||
BBV (Back Up Battery Voltage) | M | BYTE |
| |||||||
IBV (Internal Battery Voltage) | M | BYTE |
| |||||||
- | NMS | IBU | BBU | M | BYTE |
| ||||
Поля таблицы И.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
Код | Название режима работы УСВ |
0 | "Пассивный" |
1 | "ЭРА" |
2 | "Активный" |
3 | "Экстренный вызов" |
4 | "Экстренное слежение" |
5 | "Тестирование" |
6 | "Автосервис" |
7 | "Загрузка ПО" |
Подзапись EGTS_SR_ACCEL_DATA
Структура подзаписи представлена в таблице И.10.
Таблица И.10 - Формат подзаписи EGTS_SR_ACCEL_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
SA (Structures Amount) | M | BYTE | 1 | |||||||
ATM (Absolute Time) | M | UINT | 4 | |||||||
ADS1 (Accelerometer Data Structure 1) | M | BINARY | 8 | |||||||
ADS2 (Accelerometer Data Structure 2) | O | BINARY | 8 | |||||||
. | . | . | . | |||||||
ADS255 (Accelerometer Data Structure 255) | O | BINARY | 8 | |||||||
Поля таблицы И.10 содержат:
SA - число передаваемых структур данных показаний акселерометра;
ATM - время проведения измерений первой передаваемой структуры показаний акселерометра (число секунд с 00:00:00 01.01.2010 UTC);
ADS1 ... ADS255 - структуры данных показаний акселерометра, формат структуры представлен в таблице И.11. В составе подзаписи передается минимум одна структура ADS.
Таблица И.11 - Формат структуры данных показаний акселерометра подзаписи EGTS_SR_ACCEL_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RTM (Relative Time) | M | USHORT | 2 | |||||||
XAAV (X Axis Acceleration Value) | M | SHORT | 2 | |||||||
YAAV (Y Axis Acceleration Value) | M | SHORT | 2 | |||||||
ZAAV (Z Axis Acceleration Value) | M | SHORT | 2 | |||||||
Поля таблицы И.11 содержат:
RTM - приращение к времени измерения предыдущей записи (для первой записи приращение к полю ATM), мс;
Подзапись EGTS_SR_LOOPIN_DATA
Структура подзаписи представлена в таблице И.12.
Таблица И.12 - Формат подзаписи EGTS_SR_LOOPIN_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
LIFE8 | LIFE7 | LIFE6 | LIFE5 | LIFE4 | LIFE3 | LIFE2 | LIFE1 | M | BYTE |
|
LIS n+1 | LIS n | O | BYTE |
| ||||||
LIS n+3 | LIS n+2 | O | BYTE |
| ||||||
LIS n+5 | LIS n+4 | O | BYTE |
| ||||||
LIS n+7 | LIS n+6 | O | BYTE |
| ||||||
Поля таблицы И.12 содержат:
LIFE 1 ... LIFE 8 (LooplnFieldExists) - битовые флаги, определяющие наличие информации о состоянии шлейфовых входов;
LISn ... LISn+7 (LooplnState) - значение состояния соответствующего шлейфового входа. Предусмотрены следующие состояния шлейфового входа (бинарное представление):
0 - "норма";
0001 - "тревога";
0010 - "обрыв";
0100 - "замыкание на землю";
1000 - "замыкание на питание".
Подзапись EGTS_SR_ABS_DIG_SENS_DATA
Структура подзаписи представлена в таблице И.13.
Таблица И.13 - Формат подзаписи EGTS_SR_ABS_DIG_SENS_DATA сервиса EGTS_TEEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
DSN (Digital Sensor Number) младшие | DSST (Digital Sensor State) | M | SHORT | 2 | ||||||
DSN (Digital Sensor Number) старшие биты |
|
|
| |||||||
Поля таблицы И.13 содержат:
DSN - номер дискретного входа;
DSST - состояние дискретного входа:
0000 - не активен,
остальные значения - активен.
Подзапись EGTS_SR_ABS_AN_SENS_DATA
Структура подзаписи представлена в таблице И.14.
Таблица И.14 - Формат подзаписи EGTS_SR_ABS_AN_SENS_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
ASN (Analog Sensor Number) | M | BYTE | 1 | |||||||
ASV (Analog Sensor Value) | M | BINARY | 3 | |||||||
Поля таблицы И.14 содержат:
ASN - номер аналогового входа;
ASV - значение показаний аналогового входа.
Подзапись EGTS_SR_ABS_CNTR_DATA
Структура подзаписи представлена в таблице И.15.
Таблица И.15 - Формат подзаписи EGTS_SR_ABS_CNTR_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
CN (Counter Number) | M | BYTE | 1 | |||||||
CNV (Counter Value) | M | BINARY | 3 | |||||||
Поля таблицы И.15 содержат:
CN - номер счетного входа;
CNV - значение показаний счетного входа.
Подзапись EGTS_SR_ABS_LOOPIN_DATA
Структура подзаписи представлена в таблице И.16.
Таблица И.16 - Формат подзаписи EGTS_SR_ABS_LOOPIN_DATA сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
LIN (Loop In Number) младшие | LIS (Loop In State) | M | SHORT | 2 | ||||||
LIN (Loop In Number) старшие биты |
|
|
| |||||||
Поля таблицы И.16 содержат:
LIN - номер шлейфового входа;
LIS - значение состояния шлейфового входа.
Подзапись EGTS_SR_LIQUID_LEVEL_SENSOR
Структура подзаписи представлена в таблице И.17.
Таблица И.17 - Формат подзаписи EGTS_SR_LIQUID_LEVEL_SENSOR Сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
- | LLSEF | LLSVU | RDF | LLSN | M | BYTE | 1 | |||
MADDR (Module Address) | M | USHORT | 2 | |||||||
LLSD (Liquid Level Sensor Data) | M | BINARY | 4...512 | |||||||
Поля таблицы И.17 содержат:
LLSEF (Liquid Level Sensor Error Flag) - битовый флаг, определяющий наличие ошибок при считывании значения ДУЖ:
0 - ошибок не обнаружено,
1 - ошибка при считывании показаний ДУЖ;
LLSVU (Liquid Level Sensor Value Unit) - битовый флаг, определяющий единицы измерения показаний ДУЖ:
00 - нетарированное показание ДУЖ,
01 - показания ДУЖ в процентах от общего объема емкости, 1
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_SR_PASSENGERS_COUNTERS сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
- | RDF | M |
|
| ||||||
DPR (Doors Presented) | M | BYTE | 1 | |||||||
DRL (Doors Released) | M | BYTE | 1 | |||||||
MADDR (Module Address) | M | USHORT | 2 | |||||||
PCD (Passengers Counters Data) | M | BINARY | 2... 512 | |||||||
Поля таблицы И.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 - Формат поля PCD подзаписи TS_SR_PASSENGERS_COUNTERS сервиса EGTS_TELEDATA SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
IPQ1 (In Passengers Quantity 1) | O | BYTE | 1 | |||||||
OPQ1 (Out Passengers Quantity 1) | O | BYTE | 1 | |||||||
. | O | . | . | |||||||
IPQ8 (In Passengers Quantity 8) | O | BYTE | 1 | |||||||
OPQ8 (Out Passengers Quantity 8) | O | BYTE | 1 | |||||||
Поля таблицы И.19 содержат:
IPQ1...IPQ8 - число пассажиров, вошедших через 1 ... 8 дверь;
OPQ1...0PQ8 - число пассажиров, вышедших через 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 - Структура подзаписи EGTS_SR_SIGNATURE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
VER (Version) | M | BYTE | 1 | |||||||
SA (Structures Amount) | M | BYTE | 1 | |||||||
ASD1 (Array 1 Signature Data) | M | BINARY | VAR | |||||||
ASD2 (Array 2 Signature Data) | O | BINARY | VAR | |||||||
... | ... | ... | ... | |||||||
ASD255 (Array 255 Signature Data) | O | BINARY | VAR | |||||||
Описание полей:
VER - версия формата блока информации о коде аутентификации (значение для поля VER должно быть установлено в 0);
SA - число структур с массивами данных, соответствующих коду аутентификации. Может быть от одной и более, в зависимости от требуемой схемы подписания массива данных;
ASD1...ASD255 - структуры, содержащие информацию о коде аутентификации одного массива.
Состав структуры ASD приведен в таблице И.21.
Таблица И.21 - Состав полей структуры ASD подзаписи EGTS_SR_SIGNATURE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# | М | BYTE | 1 | |||||||
KEY# (Key Number) | М | USHORT | 2 | |||||||
ALGID (Algorithm Identifier) | М | UINT | 4 | |||||||
SLNL (Signature Length Low Bits) | М | BYTE | 1 | |||||||
B#H | SLNH (Signature Length High Bits) | М | BYTE | 1 | ||||||
SD (Signature Data) | М | BINARY | VAR | |||||||
Описание полей:
B# - младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
B#H (Block Number High Bit) - старшие 2 бита порядкового номера блока с кодом аутентификации для проверки его некорректируемости;
KEY# - номер ключа из массива ключей, доступных АСН, с помощью которого сформирован код аутентификации данного блока данных. В данной версии АСН поддерживает один ключ.
Примечание - Рекомендуемое значение для включения в поле KEY# должно выбираться исходя из условия, что АСН поддерживает один ключ;
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_SR_ACCEL_DATA_SIG сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
SA (Structures Amount) | M | BYTE | 1 | |||||||
ATM (Absolute Time) | M | UINT | 4 | |||||||
ADS1 (Accelerometer Data Structure 1) | M | BINARY | 8 | |||||||
ADS2 (Accelerometer Data Structure 2) | O | BINARY | 8 | |||||||
. | . | . | . | |||||||
ADS255 (Accelerometer Data Structure 255) | O | BINARY | 8 | |||||||
Поля таблицы И.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
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
RTM (Relative Time) | M | USHORT | 2 | |||||||
XAAV (X Axis Acceleration Value) | M | SHORT | 2 | |||||||
YAAV (Y Axis Acceleration Value) | M | SHORT | 2 | |||||||
ZAAV (Z Axis Acceleration Value) | M | SHORT | 2 | |||||||
Поля таблицы И.23 содержат:
RTM - приращение к времени измерения предыдущей записи (для первой записи приращение к полю ATM), мс;
Примечания
1 Ось x направлена параллельно к продольной оси ТС. Положительное направление оси x соответствует движению вперед.
2 Ось y направлена перпендикулярно к оси x в плоскости, параллельной поверхности Земли. Положительному направлению оси y соответствует направление влево.
3 Ось z перпендикулярна к осям x и y. Положительному направлению оси z соответствует направление вверх.
Подзапись EGTS_SR_POS_DATA_SIG
Структура подзаписи представлена в таблице И.24.
Таблица И.24 - Формат подзаписи EGTS_SR_POS_DATA_SIG сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
B# (Block Number) | M | BYTE | 1 | |||||||
NTM (Navigation Time) | M | UINT | 4 | |||||||
LAT (Latitude) | M | UINT | 4 | |||||||
LONG (Longitude) | M | UINT | 4 | |||||||
FLG (Flags) | M | BYTE | 1 | |||||||
ALTH | LOHS | LAHS | MV | BB | CS | FIX | VLD |
|
|
|
SPD (Speed) младшие биты | M | USHORT | 2 | |||||||
DIRH | ALTS | SPD (Speed) старшие биты |
|
|
| |||||
DIR (Direction) | M | BYTE | 1 | |||||||
ODM (Odometer) | M | BINARY | 3 | |||||||
DIN (Digital Inputs) | M | BYTE | 1 | |||||||
SRC (Source) | M | BYTE | 1 | |||||||
NID (Network Identifier) | M | BINARY | 3 | |||||||
LAC (Local Area Code) | M | UINT | 4 | |||||||
CID (Cell Identifier) | M | SHORT | 2 | |||||||
SS (Signal Strength) | M | BYTE | 1 | |||||||
ALT (Altitude) | O | BINARY | 3 | |||||||
SRCD (Source Data) | O | SHORT | 2 | |||||||
Поля таблицы И.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 - Формат поля NID подзаписи EGTS_SR_POS_DATA_SIG
Биты 20...23 | Биты 10... 19 | Биты 0...9 | Тип | Тип данных | Размер, байт |
- | МСС (Mobile Country Code) | MNC (Mobile Network Code) | M | BINARY | 3 |
LAC - идентификатор локальной зоны базовой станции сети ПРСТ, наблюдаемой УСВ на текущий момент;
CID - идентификатор ячейки базовой станции сети подвижной радиотелефонной связи, наблюдаемой УСВ на текущий момент;
SS (Signal Strength) - модуль уровня силы сигнала данной базовой станции сети подвижной радиотелефонной связи, дБм. Например, значение "80" соответствует уровню сигнала "минус 80 дБм";
ALT - высота над уровнем моря, м (опциональный параметр, наличие которого определяется битовым флагом ALTE);
SRCD - данные, характеризующие источник (событие) из поля SRC. Наличие и интерпретация значения данного поля определяется полем SRC.
Подзапись EGTS_SR_EXT_POS_DATA_SIG
Структура подзаписи представлена в таблице И.26.
Таблица И.26 - Формат подзаписи EGTS_SR_EXT_POS_DATA_SIG сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
В# (Block Number) | M | BYTE | 1 | |||||||
- | NSFE | SFE | PFE | HFE | VFE | M | BYTE | 1 | ||
VDOP (Vertical Dilution of Precision) | O | USHORT | 2 | |||||||
HDOP (Horizontal Dilution of Precision) | O | USHORT | 2 | |||||||
PDOP (Position Dilution of Precision) | O | USHORT | 2 | |||||||
SAT (Satellites) | O | BYTE | 1 | |||||||
NS (Navigation System) | O | USHORT | 2 | |||||||
Поля таблицы И.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_SR_WEIGHT_CONTROL сервиса EGTS_TELEDATA_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
TWM (Time of Weight Measure) | M | UINT | 4 | |||||||
FLG (Flags) | M | BYTE | 2 | |||||||
SCE | SE | SBA | DTE |
|
|
|
|
|
|
|
LAE | LOE | ALTE | LOHS | LAHS | ALTS |
|
|
|
|
|
MTTW (Maximum Tracktor Technical Weight) | M | UINT | 4 | |||||||
MRTW (Maximum Trailer Technical Weight) | M | UINT | 4 | |||||||
AXC (Axles Configuration) | M | BYTE | 4 | |||||||
AXW (Axles Weight) | M | BYTE | 52 | |||||||
PWM (Precision of Weight Measure) | M | BYTE | 1 | |||||||
LAT (Latitude) | О | UINT | 4 | |||||||
LONG (Longitude) | О | UINT | 4 | |||||||
ALT (Altitude) | О | BINARY | 3 | |||||||
DT (Detector Type) | О | BYTE | 1 | |||||||
Поля таблицы И.27 содержат:
TWM - время измерения (определения) передаваемых значений (число секунд с 00:00:00 01.01.2010 UTC);
MTTW - технически допустимая максимальная масса тягача, кг;
MRTW - технически допустимая максимальная масса прицепа, кг;
AXC - конфигурация осей ТС (автопоезда).
Значение конфигурации осей ТС (автопоезда) формируют исходя из максимального количества осей автомобиля-тягача, равного 6, и максимального количества осей прицепа (полуприцепа), равного 7.
Для информации о каждой оси выделяется 2 бита. Последние 6 бит не используют. Два бита, выделенные для каждой оси, могут содержать следующие значения:
- комбинация "00" означает, что для данной оси ТС (автопоезда) отсутствует возможность измерения массы, приходящейся на эту ось;
- комбинация "01" означает, что данная ось ТС (автопоезда) отсутствует;
- комбинация "10" означает, что для данной оси ТС (автопоезда) имеется возможность измерения массы, приходящейся на эту ось, и соответствующее значение записано в элементе передаваемых данных AXW;
- комбинация "11" не используется.
Структура передаваемых данных представлена в таблице И.28.
Таблица И.28 - Структура передаваемых данных о конфигурации осей ТС (автопоезда)
| Конфигурация осей ТС (автопоезда) | ||||||||||||
| Конфигурация осей автомобиля-тягача | Конфигурация осей прицепа (полуприцепа) | |||||||||||
Условный номер оси | 1 | 2 | 3 | 4 | 5 | 6 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
Возможные значения | 00/01/10 | ||||||||||||
AXW - данные о нагрузках на оси, кг
Для передачи значения массы, приходящейся на каждую ось, выделяют по 4 байта. Значениям "00" и "01" в конфигурации осей ТС (автопоезда) (см. поле АХС) для соответствующей оси должно соответствовать значение "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 - Список команд для УСВ
Название команды | Код | Тип | Описание |
EGTS_FLEET_DOUT_ON | 0x0009 | USHORT | Активация дискретных выходов. Параметр интерпретируется как битовое поле, определяющее, какие выходы активировать. Бит 0 соответствует первому выходу, 1 - второму выходу. Если бит имеет значение 1, то выход активируется, если 0, то состояние выхода не изменяется |
EGTS_FLEET_DOUT_OFF | 0x000A | USHORT | Деактивация дискретных выходов. Параметр интерпретируется как битовое поле, определяющее, какие выходы деактивировать. Бит 0 соответствует первому выходу, 1 - второму выходу. Если бит имеет значение 1, то выход деактивируется, если 0, то состояние выхода не изменяется |
EGTS_FLEET_GET_DOUT_DATA | 0x000B | - | Команда запроса состояния дискретных выходов |
EGTS_FLEET_GET_POS_DATA | 0x000C | - | Команда запроса текущих данных местоположения. При получении данной команды помимо подтверждения в виде подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE УСВ отправляет телематическое сообщение, содержащее подзапись EGTS_SR_POS_DATA сервиса EGRS_TELEDATA_SERVICE |
EGTS_FLEET_GET_SENSORS_DATA | 0x000D | - | Команда запроса состояния дискретных и аналоговых входов. При получении данной команды помимо подтверждения в виде подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_ SERVICE УСВ отправляет телематическое сообщение, содержащее подзаписи EGTS_SR_POS_DATA и EGTS_SR_AD_SENSORS сервиса EGRS_TELEDATA_SERVICE |
EGTS_FLEET_GET_LIN_DATA | 0x000E | - | Команда запроса состояния шлейфовых входов. При получении данной команды помимо подтверждения в виде подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE УСВ отправляет телематическое сообщение, содержащее подзаписи EGTS SR POS_DATA и EGTS_SR_LOOPIN_DATA сервиса EGRS_TELEDATA_SERVICE |
EGTS_FLEET_GET_CIN_DATA | 0x000F | - | Команда запроса состояния счетных входов. При получении данной команды помимо подтверждения в виде подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_ SERVICE УСВ отправляет телематическое сообщение, содержащее подзаписи EGTS_SR_POS_DATA и EGTS_SR_COUNTERS_DATA сервиса EGRS_TELEDATA_SERVICE |
EGTS_FLEET_GET_STATE | 0x0010 | - | Команда запроса состояния УСВ. При получении данной команды помимо подтверждения в виде подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE УСВ отправляет телематическое сообщение, содержащее подзаписи EGTS_SR_POS_DATA и EGTS_SR_STATE_DATA сервиса EGRS_TELEDATA_SERVICE |
EGTS_FLEET_ODOM_CLEAR | 0x0011 | - | Команда для обнуления показаний внутреннего одометра УСВ. Для обработки данной команды оператор отправляет корректные значения полей ACL и AC из таблицы Б.17 спецификации протокола Поддержки услуг |
EGTS_START_SEND_READY | 0x0510A | INT | Команда для начала передачи координатно-временной информации в режиме постоянной регистрации в сети связи. В параметре передается значение номера профиля передачи данных для режима постоянной регистрации в сети связи. Начало передачи данных также может быть инициировано в зависимости от значения параметра EGTS_READY_PROFILE после получения команды EGTS_SET_ON_READY |
EGTS_STOP_SEND_RAEDY | 0x510B | - | Команда для завершения передачи координатно-временной информации в режиме постоянной регистрации в сети связи |
EGTS_SEND_MONITOR | 0x0710A | INT | Команда для передачи координатно-временной информации в режиме передачи мониторинговой информации согласно номеру профиля. Изменяет номер текущего передающего профиля. В параметре передается значение номера профиля передачи данных. Начало передачи данных в определенном профиле также может быть инициировано в зависимости от значения параметра EGTS_MONITOR_PROFILE после получения команды EGTS_SET_ON_MONITOR |
Таблица И.30 - Список подтверждений на команды и сообщения от УСВ
Название команды | Код | Тип | Описание |
EGTS_FLEET_DOUT_ON | 0x0009 | USHORT | Параметр интерпретируется как битовое поле, определяющее состояние дискретных выходов. Бит 0 соответствует первому выходу, 1 - второму выходу. Если бит имеет значение 1, то выход активирован, 0 - не активирован |
EGTS_FLEET_DOUT_OFF | 0x000A | USHORT | Параметр интерпретируется как битовое поле, определяющее состояние дискретных выходов. Бит 0 соответствует первому выходу, 1 - второму выходу. Если бит имеет значение 1, то выход активирован, 0 - не активирован |
EGTS_FLEET_GET_DOUT_DATA | 0x000B | USHORT | Параметр интерпретируется как битовое поле, определяющее состояние дискретных выходов. Бит 0 соответствует первому выходу, 1 - второму выходу. Если бит имеет значение 1, то выход активирован, 0 - не активирован |
EGTS_START_SEND_READY | 0x0510A | INT | Подтверждение начала передачи координатно-временной информации в режиме постоянной регистрации в сети связи. В параметре передается значение номера профиля передачи данных, активированного для режима постоянной регистрации в сети связи. Передает 0 в случае ошибки и невозможности активировать указанный в команде профиль |
EGTS_STOP_SEND_RAEDY | 0x510B | - | Подтверждение завершения передачи координатно-временной информации в режиме постоянной регистрации в сети связи |
EGTS_SEND_MONITOR | 0x0710A | INT | Подтверждение начала передачи координатно-временной информации в режиме передачи мониторинговой информации. В параметре передается значение номера профиля передачи данных, активированного для режима передачи мониторинговой информации. Передает 0 в случае ошибки и невозможности активировать указанный в команде профиль |
Таблица И.31 - Список параметров УСВ
Параметр | Код | Тип параметра | Значение по умолчанию | Описание |
Конфигурация и конфигурационные данные услуг | ||||
Мониторинг ТС | ||||
EGTS_FLEET_ON | 0x0261 | BOOLEAN | 1 | 1 - разрешает использование услуги мониторинговой информации |
EGTS_FLEET_IGN_ON_PERIOD | 0x0262 | INT | 60 | Период передачи телематических сообщений на сервер при включенном зажигании, с |
EGTS_FLEET_IGN_OFF_PERIOD | 0x0263 | INT | 300 | Период передачи телематических сообщений на сервер при выключенном зажигании, с |
EGTS_FLEET_DIST_THRESHOLD | 0x0264 | INT | 10 | Значение пройденного пути, по достижении которого производится отправка телематического сообщения на сервер с признаком "пробег заданной дистанции", 100 м |
EGTS_FLEET_COURSE_THRESHOLD | 0x0265 | INT | 20 | Значение изменения курса, по достижении которого производится отправка телематического сообщения на сервер с признаком "превышение установленного значения угла поворота", градусы |
EGTS_FLEET_MAX_SPEED_THRESHOLD | 0x0266 | ARRAY OF INT | 60,0,0,0,0 | Значения порогов скорости, при превышении одного из которых производится передача телематического сообщения на сервер с признаком "превышение одного из заданных порогов скорости", км/ч. Нулевые значения не учитываются при обработке |
EGTS_FLEET_MIN_SPEED_THRESHOLDS | 0x0267 | ARRAY OF INT | 0,0,0,0,0 | Значения порогов скорости, при превышении одного из которых производится передача телематического сообщения на сервер с признаком "снижение скорости ниже одного из заданных порогов", км/ч. Нулевые значения не учитываются при обработке |
EGTS_FLEET_MIN_BATTERY_VOLTAGE | 0x0268 | INT | 110 | Пороговое значение напряжения на резервном аккумуляторе, при достижении которого производится передача телематического сообщения на сервер с признаком "снижение напряжения источника резервного питания ниже порогового значения", 0,1 В |
EGTS_FLEET_POS_ACCEL_THRESHOLD | 0x0269 | INT | 100 | Пороговое значение положительного продольного ускорения, при достижении которого производится передача телематического сообщения на сервер с признаком "резкий разгон", 0,1 м/с |
EGTS_FLEET_NEG_ACCEL_THRESHOLD | 0x026A | INT | 100 | Пороговое значение отрицательного продольного ускорения, при достижении которого производится передача телематического сообщения на сервер с признаком "резкое торможение", 0,1 м/с |
EGTS_FLEET_EM_MON_PERIOD | 0x026B | INT | 10 | Период передачи телематических сообщений на сервер в режиме "экстренное слежение", с |
EGTS_FLEET_NAVI_TRB_THRESHOLD | 0x026C | INT | 6 | Пороговое значение частоты прерывания режима навигации при включенном зажигании или режиме экстренного слежения, при достижении которого производится передача телематического сообщения на сервер с признаком "нестабильная навигация", 1/ч |
EGTS_FLEET_CONN_TRB_THRESHOLD | 0x026D | INT | 30 | Пороговое значение частоты прерывания/восстановления IP соединения при включенном зажигании или режиме экстренного слежения, при достижении которого производится передача телематического сообщения на сервер с признаком "нестабильная связь", 1/ч |
EGTS_FLEET_GSM_REG_TRB_THRESHOLD | 0x026E | INT | 3 | Пороговое значение частоты регистрации в сети связи стандартов GSM при включенном зажигании или режиме экстренного слежения, при достижении которого производится передача телематического сообщения на сервер с признаком "нестабильная регистрация в сети сотовой связи", 1/ч |
EGTS_FLEET_POS_USE_ALT | 0x026F | BOOLEAN | 1 | 1 - указывает, что параметр "Altitude" передается в телематическом сообщении от УСВ |
EGTS_FLEET_EXT_POS_DATA_FLAGS | 0x0270 | INT | 255 | Определяет, какие из опциональных параметров передаются в подзаписи EGTS_SR_EXT_POS_DATA сервиса EGTS_TELEDATA_SERVICE. Представляет собой битовую маску, формат которой совпадает с форматом первого байта подзаписи EGTS_SR_EXT_POS_DATA |
EGTS_FLEET_SR_MASK | 0x0271 | INT | 255 | Определяет состав данных, передаваемый с УСВ с каждым телематическим сообщением (подзапись EGTS_SR_POS_DATA). Представляет собой битовое поле:
0 - EGTS_SR_EXT_POS_DATA;
1 - EGTS_SR_AD_SENSORS_DATA;
2 - EGTS_SR_COUNTERS_DATA;
3 - EGTS_SR_ACCEL_DATA;
4 - EGTS_SR_STATE_DATA;
5 - EGTS_SR_LOOPIN_DATA.
Если соответствующий бит имеет значение 1, то подзапись передается |
EGTS_FLEET_DIN_MASK | 0x0272 | INT | 1 | Определяет состав дискретных входов, анализируемых УСВ. Представляет собой битовое поле:
0 - дискретные входы 1 ... 8;
1 - входы 9 ... 16;
2 - входы 17 ... 24 и т.д.
Если бит имеет значение 1, то соответствующие дискретные входы (если они физически присутствуют) анализируется УСВ |
EGTS_FLEET_AIN_MASK | 0x0273 | INT | 15 | Определяет состав аналоговых входов, анализируемых УСВ. Представляет собой битовое поле:
бит 0 - аналоговый вход 1;
1 - вход 2;
2 - вход 3 и т.д.
Если бит имеет значение 1, то соответствующий аналоговый вход (если он физически присутствует) анализируется УСВ |
EGTS_FLEET_CIN_MASK | 0x0274 | INT | 0 | Определяет состав счетных входов, анализируемых УСВ. Представляет собой битовое поле:
бит 0 - счетный вход 1;
1 - вход 2;
2 - вход 3 и т.д.
Если бит имеет значение 1, то соответствующий счетный вход (если он физически присутствует) анализируется УСВ |
EGTS_FLEET_LIN_MASK | 0x0275 | INT | 0 | Определяет состав шлейфовых входов, анализируемых УСВ. Представляет собой битовое поле:
бит 0 - счетный вход 1;
1 - вход 2;
2 - вход 3.
Если бит имеет значение 1, то соответствующий шлейфовый вход (если он физически присутствует) анализируется УСВ |
EGTS_FLEET_USE_ABS_SENS_DATA | 0x0276 | INT | 0 | Определяет необходимость использования подзаписей
EGTS_SR_ABS_DIG_SENS_DATA,
EGTS_SR_ABS_AN_SENS_DATA,
EGTS_SR_ABS_CNTR_DATA
и
EGTS_SR_ABS_LOOPIN_DATA
вместо
EGTS_SR_AD_SENSORS_DATA,
EGTS_SR_COUNTERS_DATA
и
EGTS_SR_LOOPIN_DATA
для передачи информации о состоянии соответствующих сенсоров.
Представляет собой битовое поле:
0 - EGTS_SR_ABS_DIG_SENS_DATA;
1 - EGTS_SR_ABS_AN_SENS_DATA;
2 - EGTS_SR_ABS_CNTR_DATA;
3 - EGTS_SR_ABS_LOOPIN_DATA.
Если бит имеет значение 1, то используется соответствующая подзапись |
Режим постоянной регистрации в сети связи | ||||
EGTS_FLEET_IGN_ON_PERIOD_READY | 0x0562 | ARRAY OF INT | 1, 60 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - период передачи телематических сообщений на сервер при включенном зажигании, с |
EGTS_FLEET_IGN_OFF_PERIOD_READY | 0x0563 | ARRAY OF INT | 1, 300 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - период передачи телематических сообщений на сервер при выключенном зажигании, с |
EGTS_FLEET_DIST_THRESHOLD_READY | 0x0564 | ARRAY OF INT | 1, 10 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - значение пройденного пути, по достижении которого производится отправка телематического сообщения на сервер с признаком "пробег заданной дистанции", 100 м |
EGTS_FLEET_COURSE_THRESHOLD_READY | 0x0565 | ARRAY OF INT | 1, 20 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - значение изменения курса, по достижении которого производится отправка телематического сообщения на сервер с признаком "превышение установленного значения угла поворота", градусы |
EGTS_FLEET_MAX_SPEED_THRESHOLD_READY | 0x0566 | ARRAY OF INT | 1, 60,0,0,0,0 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - значения порогов скорости, при превышении одного из которых производится передача телематического сообщения на сервер с признаком "превышение одного из заданных порогов скорости", км/ч. Нулевые значения не учитываются при обработке |
EGTS_FLEET_MIN_SPEED_THRESHOLDS_READY | 0x0567 | ARRAY OF INT | 1, 0,0,0,0,0 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - значения порогов скорости, при превышении одного из которых производится передача телематического сообщения на сервер с признаком "снижение скорости ниже одного из заданных порогов", км/ч. Нулевые значения не учитываются при обработке |
EGTS_FLEET_MIN_BATTERY_VOLTAGE_READY | 0x0568 | ARRAY OF INT | 1, 110 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - пороговое значение напряжения на резервном аккумуляторе, при достижении которого производится передача телематического сообщения на сервер с признаком "снижение напряжения источника резервного питания ниже порогового значения", 0,1 В |
EGTS_FLEET_POS_ACCEL_THRESHOLD_READY | 0x0569 | ARRAY OF INT | 1,100 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - пороговое значение положительного продольного ускорения, при достижении которого производится передача телематического сообщения на сервер с признаком "резкий разгон", 0,1 м/с |
EGTS_FLEET_NEG_ACCEL_THRESHOLD_READY | 0x056A | ARRAY OF INT | 1, 100 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N1. Следующие элементы массива - пороговое значение отрицательного продольного ускорения, при достижении которого производится передача телематического сообщения на сервер с признаком "резкое торможение", 0,1 м/с |
EGTS_CONNECT_READY | 0x056B | ARRAY OF INT | 1, 0, 0, 0, 0, 0 | Первый элемент массива - номер профиля режима постоянной регистрации в сети связи, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива определяют адрес и порт сервера приема данных:
- первое слева направо число адреса IPv4;
- второе слева направо число адреса IPv4;
- третье слева направо число адреса IPv4;
- четвертое слева направо число адреса IPv4;
- номер порта |
Режим передачи мониторинговой информации | ||||
EGTS_FLEET_IGN_ON_PERIOD_MONITOR | 0x0762 | ARRAY OF INT | 1, 60 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - период передачи телематических сообщений на сервер при включенном зажигании, с |
EGTS_FLEET_IGN_OFF_PERIOD_MONITOR | 0x0763 | ARRAY OF INT | 1, 300 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - период передачи телематических сообщений на сервер при выключенном зажигании, с |
EGTS_FLEET_DIST_THRESHOLD_MONITOR | 0x0764 | ARRAY OF INT | 1, 10 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - значение пройденного пути, по достижении которого производится отправка телематического сообщения на сервер с признаком "пробег заданной дистанции", 100 м |
EGTS_FLEET_COURSE_THRESHOLD_MONITOR | 0x0765 | ARRAY OF INT | 1, 20 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Второй элемент массива - значение изменения курса, по достижении которого производится отправка телематического сообщения на сервер с признаком "превышение установленного значения угла поворота", градусы |
EGTS_FLEET_MAX_SPEED_THRESHOLD_MONITOR | 0x0766 | ARRAY OF INT | 1, 60,0,0,0,0 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - значения порогов скорости, при превышении одного из которых производится передача телематического сообщения на сервер с признаком "превышение одного из заданных порогов скорости", км/ч. Нулевые значения не учитываются при обработке |
EGTS_FLEET_MIN_SPEED_THRESHOLDS_MONITOR | 0x0767 | ARRAY OF INT | 1, 0,0,0,0,0 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - значения порогов скорости, при превышении одного из которых производится передача телематического сообщения на сервер с признаком "снижение скорости ниже одного из заданных порогов", км/ч. Нулевые значения не учитываются при обработке |
EGTS_FLEET_MIN_BATTERY_VOLTAGE_MONITOR | 0x0768 | ARRAY OF INT | 1, 110 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - пороговое значение напряжения на резервном аккумуляторе, при достижении которого производится передача телематического сообщения на сервер с признаком "снижение напряжения источника резервного питания ниже порогового значения", 0,1 В |
EGTS_FLEET_POS_ACCEL_THRESHOLD_MONITOR | 0x0769 | ARRAY OF INT | 1, 100 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - пороговое значение положительного продольного ускорения, при достижении которого производится передача телематического сообщения на сервер с признаком "резкий разгон", 0,1 м/с |
EGTS_FLEET_NEG_ACCEL_THRESHOLD_MONITOR | 0x076A | ARRAY OF INT | 1, 100 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива - пороговое значение отрицательного продольного ускорения, при достижении которого производится передача телематического сообщения на сервер с признаком "резкое торможение", 0,1 |
EGTS_CONNECT_MONITOR | 0x076B | ARRAY OF INT | 1, 0, 0, 0, 0, 0 | Первый элемент массива - номер профиля режима передачи мониторинговой информации, для которого устанавливается параметр. По умолчанию используется один профиль N 1. Следующие элементы массива определяют адрес и порт сервера приема данных:
- первое слева направо число адреса IPv4;
- второе слева направо число адреса IPv4;
- третье слева направо число адреса IPv4;
- четвертое слева направо число адреса IPv4;
- номер порта |
Приложение К
(обязательное)
Спецификация сервиса передачи на бортовое оборудование сообщений и оповещений EGTS_NOTIFICATION_SERVICE
Состав сервиса EGTS_NOTIFICATION_SERVICE
Сервис EGTS_NOTIFICATION_SERVICE предназначен для передачи на УСВ сообщений и оповещений от телематических систем (аппаратно-программных комплексов).
Для осуществления взаимодействия в рамках сервиса EGTS_NOTIFICATION_SERVICE используется несколько подзаписей, описание и код которых представлены в таблице К.1.
Таблица К.1 - Список подзаписей сервиса EGTS_NOTIFICATION_SERVICE
Код | Наименование | Описание |
0 | EGTS_SR_RECORD_RESPONSE | Применяется для осуществления подтверждения приема и передачи результатов обработки записи уровня поддержки услуг |
2 | EGTS_SR_NOTIFICATION_FORMDATA | Подзапись предназначена для передачи на УСВ (обновления) данных предзаписанных формализованных сообщений |
3 | EGTS_SR_NOTIFICATION__DATA | Подзапись предназначена для передачи на УСВ формализованных сообщений и уведомлений |
4 | EGTS_SR_NOTIFICATION_PART_DATA | Подзапись предназначена для передачи на УСВ данных неформализованных сообщений и уведомлений, которые разбиваются на части и передаются последовательно. Данная подзапись применяется для передачи больших объектов, длина которых не позволяет передать их на УСВ одним пакетом |
5 | EGTS_SR_NOTIFICATION_FULL_DATA | Подзапись предназначена для передачи на УСВ данных неформализованных сообщений и уведомлений, которые не разбиваются на части, а передаются одним пакетом |
Подзапись 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_SR_NOTIFICATION_FORMDATA сервиса EGTS_NOTIFICATION_ SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
Nl (Notification Identity) | M | USHORT | 2 | |||||||
ND (Notification Data) | M | BINARY | 1... 65400 | |||||||
В таблице К.2 параметры (поля) имеют следующие назначения:
- NI - уникальный идентификатор формализованного сообщения/уведомления. Зарезервированные коды формализованных сообщений приведены в таблицах К.3 и К.4. Указанные в таблицах К.3 и К.4 сообщения должны быть предзаписаны в энергонезависимой памяти УСВ при его настройке без возможности изменения;
- ND - данные формализованного сообщения/уведомления.
Таблица К.3 - Зарезервированные коды и содержание формализованных сообщений
Идентификатор | Содержание сообщения |
0x0001 | Впереди авария, будьте внимательны, сбросьте скорость |
0x0002 | Впереди повреждение участка дороги, сбросьте скорость |
0x0003 | Будьте внимательны, зафиксировано землетрясение, сбросьте скорость |
0x0004 | Будьте внимательны, впереди оползень, обвал дороги и осыпь, сбросьте скорость |
0x0005 | Будьте внимательны, впереди просадка земной поверхности, сбросьте скорость |
0x0006 | Будьте внимательны, впереди эрозия, склоновые смывы, сбросьте скорость |
0x0007 | Будьте внимательны, сильный ливень, сбросьте скорость |
0x0008 | Будьте внимательны, очень сильный снег, сбросьте скорость |
0x0009 | Будьте внимательны, на дороге гололед, сбросьте скорость |
0x000A | Будьте внимательны, на дороге туман, сбросьте скорость |
0x000B | Будьте внимательны, на дороге может быть камнепад, сбросьте скорость |
0x000C | Будьте внимательны, зафиксирован сход снежных лавин. Воспользуйтесь иным маршрутом |
0x000D | Будьте внимательны, впереди высокий уровень воды, сбросьте скорость |
0x000E | Будьте внимательны, впереди лесные пожары, сбросьте скорость |
0x000F | Будьте внимательны, зафиксирован акт терроризма |
0x0010 | Будьте внимательны, зафиксирована забастовка, могут быть проблемы на дороге |
0x0011 | Будьте внимательны, зафиксирована нештатная ситуация на дороге. Воспользуйтесь иным маршрутом |
0x0012 | Впереди ремонтные работы, будьте внимательны, сбросьте скорость |
0x0065 | Число пострадавших более 10 человек |
0x0066 | Повреждено более 10 автомобилей |
0x0067 | Пострадал рейсовый автобус |
0x0069 | Дорога перекрыта на более чем 12 часов |
0x006A | Столкновение на ЖД переезде |
0x006В | Дорога перекрыта более чем на час |
0x006C | Более 5 баллов |
0x00C9 | Информация актуализирована 10 мин назад |
0x00CB | Информация актуализирована 30 мин назад |
0x00CC | Информация актуализирована 1 час назад |
0x00CD | Информация актуализирована 2 часа назад |
0x012D | Расстояние менее 1 км |
0x012Е | Расстояние менее 5 км |
0x012F | Расстояние менее 10 км |
0x0130 | Расстояние менее 20 км |
0xFF01 | Сообщение МЧС |
0xFF02 | Сообщение Росавтодор |
0xFF03 | Сообщение ГИБДД |
Таблица К.4 - Зарезервированные голосовые сообщения, воспроизводимые для водителя и пассажиров при функционировании УСВ
Идентификатор | Содержание сообщения |
0XFF10 | Идет передача данных об аварии в систему реагирования |
0xFF11 | Данные об аварии отправлены в систему реагирования через сотовую связь с использованием тонального модема |
0xFF12 | Данные об аварии отправлены в систему реагирования через сотовую связь с использованием SMS |
0xFF13 | Данные об аварии не могут быть отправлены в систему реагирования через сотовую связь. Данные будут отправлены через спутниковую связь. Нажмите кнопку "Экстренный вызов" для отмены отправки данных |
0xFF14 | Отправка данных об аварии в систему реагирования через спутниковую связь отменена |
0xFF15 | Данные об аварии отправлены в систему реагирования через спутниковую связь |
0xFF16 | Идет передача данных об отмене реагирования в систему реагирования |
0xFF17 | Данные об отмене реагирования отправлены в систему реагирования через сотовую связь с использованием тонального модема |
0xFF18 | Данные об отмене реагирования не могут быть отправлены в систему реагирования через сотовую связь. Данные будут отправлены через спутниковую связь. Нажмите кнопку "Экстренный вызов" для отмены отправки данных |
0xFF19 | Отправка данных об отмене реагирования в систему реагирования через спутниковую связь отменена |
0xFF1A | Данные об отмене реагирования отправлены в систему реагирования через спутниковую связь |
0xFF1B | Данные о факте аварии отправлены в систему реагирования. Если вы хотите отправить в систему информацию об обстоятельствах ДТП, то в течение 10 минут нажмите кнопку "Обстоятельства ДТП" |
0xFF1C | Данные о факте аварии не могут быть отправлены в систему реагирования через сотовую связь. Данные сохранены и будут отправлены позднее по мере восстановления связи |
0xFF1D | Данные об обстоятельствах ДТП отправлены в систему реагирования |
0xFF1E | Данные об обстоятельствах ДТП не могут быть отправлены в систему реагирования через сотовую связь. Данные сохранены и будут отправлены позднее по мере восстановления связи. Не нажимайте на кнопку повторно |
0xFF1F | Связь с диспетчером не может быть установлена. В данный момент осуществляется экстренный вызов в систему реагирования |
0xFF20 | Возможность совершать вызовы диспетчеру восстановлена |
0xFF21 | Связь с диспетчером не может быть установлена. Попробуйте позднее |
0xFF22 | Устройство перешло в режим "Тестирование" |
0xFF23 | Устройство перешло в режим "Автосервис" |
Подзапись EGTS_SR_NOTIFICATION_DATA
Подзапись EGTS_SR_NOTIFICATION_DATA предназначена для передачи на УСВ формализованных сообщений. Структура подзаписи представлена в таблице К.5.
Таблица К.5 - Структура подзаписи EGTS_SR_NOTIFICATION_DATA сервиса EGTS_NOTIFICATION_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
|
|
|
|
|
| NM | M | BYTE | 1 | |
NC (Notification count) | M | BYTE | 1 | |||||||
NI (Notification Identity) | M | ARRAY OF USHORT | VAR | |||||||
NE (Notification expiration) | M | BYTE | 1 | |||||||
NRC (Notification repeat count) | M | BYTE | 1 | |||||||
NRP (Notification repeat period) | M | BYTE | 1 | |||||||
В таблице К.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_SR_NOTIFICATION_PART_DATA сервиса EGTS_NOTIFICATION_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
NID (Identity) | M | USHORT | 2 | |||||||
PN (Part Number) | M | USHORT | 2 | |||||||
EPQ (Expected Parts Quantity) | M | USHORT | 2 | |||||||
NDHL (Notification Data Header Length) | M | BYTE | 1 | |||||||
NDH (Notification Data Header) | O | BINARY | 0...68 | |||||||
NM (Notification mandatory) | M | BYTE | 1 | |||||||
NE (Notification expiration) | M | BYTE | 1 | |||||||
NRC (Notification repeat count) | M | BYTE | 1 | |||||||
NRP (Notification repeat period) | M | BYTE | 1 | |||||||
ND (Notification Data) | M | BINARY | 1... 65400 | |||||||
Примечания
1 NID - уникальный идентификатор передаваемого сообщения. Инкрементируется при начале отправки нового сообщения. Данный параметр позволяет однозначно идентифицировать, какому именно сообщению данная часть принадлежит.
2 PN - последовательный номер текущей части передаваемого сообщения.
3 EPQ - ожидаемое число частей передаваемого сообщения.
4 NDHL - длина заголовка в байтах. При передаче второй и последующих частей данное поле не передается.
5 NDH - заголовок, содержащий параметры, характеризующие передаваемое сообщение. Данный заголовок передается только для первой части сообщения. При передаче второй и последующих частей данное поле не передается. Структура заголовка NDH представлена в таблице К.7.
6 NM - признак, который определяет обязательность воспроизведения сообщения на УСВ (десятичное): 0 - воспроизведение после подтверждения со стороны пользователя,
1 - сообщение обязательно для воспроизведения (автоматическое воспроизведение без подтверждения со стороны пользователя),
2 - воспроизведение сообщения в зависимости от настроек УСВ,
3 - воспроизведение сообщения по запросу пользователя. При передаче второй и последующих частей данное поле не передается.
7 NE - срок хранения оповещения, часы. При передаче второй и последующих частей данное поле не передается.
8 NRC - число повторений сообщения. При передаче второй и последующих частей данное поле не передается.
9 NRP - период повторения сообщения, мин. При передаче второй и последующих частей данное поле не передается.
10 ND - данные передаваемого сообщения/уведомления (файл в одном из аудиоформатов, который указан в поле NDH).
| ||||||||||
Параметр EPQ содержит число частей, которое будет передано, а параметр PN - номер текущей части. Поле NID однозначно определяет сущность, которой принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть не более значения из поля EPQ. Если данное условие нарушается, то данные из такой подзаписи игнорируются.
Идентификатор объекта NID, поля PN и EPQ, а также идентификатор источника записи OID из заголовка уровня маршрутизации сервисов позволяют определить, какая часть и какого сообщения/уведомления получена для обработки. Это позволяет при достаточной пропускной способности канала одновременно передавать несколько сообщений/уведомлений. Формат заголовка представлен в таблице К.7.
Таблица К.7 - Формат заголовка сообщения/уведомления подзаписи EGTS_SR_NOTIFICATION_PART_DATA сервиса EGTS_NOTIFICATION_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
NF (Notification format) | M | USHORT | 2 | |||||||
WOS (Whole Object Signature) | M | USHORT | 2 | |||||||
FN (File Name) | O | STRING | 0...64 | |||||||
В таблице К.7 параметры (поля) имеют следующие назначения:
- NF - код формата передаваемого аудиофайла сообщения/уведомления может принимать следующие значения:
01 - WAV,
02 - AIFF,
03 - APE,
04 - FLAC,
05 - MPЗ,
06 - OGG,
07 - иное, определяется УСВ на основании данных передаваемого файла;
- WOS - сигнатура (контрольная сумма) передаваемого сообщения/уведомления. Используется алгоритм CRC16-CCITT;
- FN - имя передаваемого файла (данное поле опционально и может иметь нулевую длину).
Подзапись EGTS_SR_NOTIFICATION_FULL_DATA
Подзапись EGTS_SR_NOTIFICATION_FULL_DATA предназначена для передачи неформализованных сообщений и уведомлений, которые не разбиваются на части, а передаются одним пакетом. Структура подзаписи представлена в таблице К.8.
Таблица К.8 - Структура подзаписи EGTS_SR_NOTIFICATION_FULL_DATA сервиса EGTS_NOTIFICATION_SERVICE
Бит 7 | Бит 6 | Бит 5 | Бит 4 | Бит 3 | Бит 2 | Бит 1 | Бит 0 | Тип | Тип данных | Размер, байт |
NDHL (Notification Data Header Length) | M | BYTE | 1 | |||||||
NDH (Notification Data Header) | M | BINARY | 0...68 | |||||||
NM (Notification mandatory) | M | BYTE | 1 | |||||||
NE (Notification expiration) | M | BYTE | 1 | |||||||
NRC (Notification repeat count) | M | BYTE | 1 | |||||||
NRP (Notification repeat period) | M | BYTE | 1 | |||||||
ND (Notification Data) | M | BINARY | 1...65400 | |||||||
В таблице К.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, в пределах которой обслуживается абонент, текущий идентификатор сотовой сети (МСС) и идентификатор используемой ячейки (MNC). Местоположение базовой станции связи доступно при помощи базы данных Cell ID операторов связи. Данные о месте ячейки, сети и Cell ID являются достаточным для формирования ассистирующей информации, которая возвращается абоненту по установленному соединению и подается в навигационный приемник.
Технология А-ГНСС позволяет навигационному приемнику получить по сетям связи ассистирующую информацию:
- эфемериды спутников;
- время;
- доплеровский сдвиг;
- первую производную доплеровского сдвига;
- список видимых спутников;
- возвышение и азимут спутника;
- альманах;
- приблизительное расположение абонента;
- оценку кодовой задержки;
- расширенные эфемериды;
- параметры ионосферной модели;
- временной сдвиг между временем GPS и UTC;
- временной сдвиг между различными ГНСС и GPS;
- сообщение целостности из навигационного кадра.
Благодаря этой информации сокращается время формирования первого решения до нескольких секунд. Точный состав информации, способ обмена данными и протоколы передачи описываются рядом стандартов 3GPP и ОМА. Один из наиболее распространенных протоколов - ОМА 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.
 |
Рисунок Л.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. Список параметров, содержащихся с общей части сообщения UPL, представлен в таблице Л.1.
Таблица Л.1 - Общая часть сообщения ULP
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Message Length | Да | Длина всего сообщения ULP в октетах.
Примечание - Первые два октета сообщения PER содержат длину всего сообщения. Эти октеты устанавливаются на длину сообщения, когда кодирование PER завершено и вся длина сообщения известна.
|
Version | Да | Версия протокола в формате: версия, расширение, сервисный индикатор |
Session ID | Да | Уникальный идентификатор Session ID |
Message Payload | Да | Параметр содержит сообщение из определенных в ULP:
- SUPL INIT
- SUPL START
- SUPL RESPONSE
- SUPL POS INIT
- SUPL POS
- SUPL END
- SUPL AUTH REQ
- SUPL AUTH RESP |
Описание поля Версии протокола SUPL (Version) приведено в таблице Л.2.
Таблица Л.2 - Описание поля Версии протокола SUPL (Version)
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Version | Да | Версия протокола. Принимающая сторона определяет, какие версии протокола поддерживаются принимающей стороной. Если версии протокола не поддерживаются, выдается ошибка |
Maj | Да | Номер поддерживаемой версии (0..255), должен быть 2 для описываемой версии 2.1 |
Min | Да | Расширение поддерживаемой версии (0..255), должен быть 1 для описываемой версии 2.1 |
Serv_ind | Да | Сервисный индикатор, должен быть 0 для текущей версии |
Описание поля Уникальный идентификатор сеанса (Session ID) приведено в таблице Л.3.
Таблица Л.3 - Описание поля Уникальный идентификатор сеанса (Session ID)
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Session ID | Да | Уникальный идентификатор сеанса. Значение ДОЛЖНО быть уникальным по всем одновременно активным сеансам ULP на этом конкретном SET.
Значение может быть повторно использовано SET после завершения сеанса ULP |
SET ID | Да | Идентификатор SET
Может принимать значения:
- MSISDN
- MDN
- MIN
- IMSI
- IMEI
- NAI
- IPAddress:
IPv4
IPv6 |
Л.2 Дополнительная часть сообщения
Дополнительная часть сообщения содержит дополнительные параметры, уникальные для каждого сообщения ULP Следующие подразделы описывают специфичную для сообщения часть сообщений ULP
Начальное сообщение SUPL START
Начальное сообщение SUPL START от SET к SLP имеет следующие параметры, представленные в таблице Л.4.
Таблица Л.4 - Начальное сообщение от SET к SLP (SUPL START)
Параметр | Наличие обязательный/ необязательный | Значение/описание |
SET capabilities | Да | Перечень возможностей SET |
Location ID | Да | Местоположение обслуживающей БС, точки WLAN или WiMAX |
QoP | Нет | Точность позиционирования |
Multiple Location IDs | Нет | Местоположение видимых или ранее подключенных обслуживающих ВС, точек WLAN или WiMAX в зависимости от доступных значений в сети обслуживающего оператора, а также информация о местоположении из предыдущего сеанса |
Third Party | Нет | Не требуется |
Значения поля SET capabilities представлении в таблице Л.5.
Таблица Л.5 - Значения поля SET capabilities
Параметр | Наличие обязательный/ необязательный | Значение/описание |
>Pos Technology | Да | Определяет технологию определения позиции ни одной или несколько:
- SET-assisted A-GPS
- SET-based A-GPS
- Autonomous GPS
- AFLT
- E-CID
- E-OTD
- OTDOA |
>Pref Method | Да | Один из предпочитаемых методов:
- SET-assisted preferred
- SET-based preferred
- No preferred mode |
>Pos Protocol | Да | Один из протоколов:
- RRLP
- RRC
- TIA-801 |
Значения поля уникального идентификатора ячейки самой последней обслуживающей соты Location ID представлены в таблице Л.6.
Таблица Л.6 - Значения поля Location ID
Параметр | Наличие обязательный/ необязательный | Значение/описание |
>Cell Info | Да | Поддерживаются следующие данные:
- GSM Cell Info
- WCDMA Cell Info
- CDMA Cell Info |
>Status | Да | - Not Current, информация по последней известной соте
- Current, текущая сота
- Unknown, неизвестная (последняя или текущая) |
>Pos Protocol | Да | Один из протоколов:
- RRLP
- RRC
- TIA-801 |
Значения GSM Cell Info приведены в таблице Л.7.
Таблица Л.7 - Значения поля GSM Cell Info
Параметр | Наличие обязательный/ необязательный | Значение/описание |
>MCC | Да | Мобильный код страны (Mobile Country Code), Integer (0..999) |
>MNC | Да | Мобильный код сети (Mobile Network Code), Integer (0..999) |
>LAC | Да | Код локальной зоны (Location Area Code), Integer (0..65535) |
>CI | Да | Номер соты (Cell Identity), Integer (0..65535) |
>NMR | Нет | Отчет об измерении (Network Measurement Report) - от 1 до 15 сот |
>>ARFCN | Да | ARFCN, Integer (0.. 1023) |
>>BSIC | Да | BSIC, Integer (0..63) |
>>RXLev | Да | RXLev, Integer (0..63) |
>TA | Нет | Timing Advance, Integer (0..255) |
Значения QoP приведены в таблице Л.8.
Таблица Л.8 - Значения поля QoP
Параметр | Наличие обязательный/ необязательный | Значение/Описание |
>Horizontal accuracy | Да | Точность по горизонтали |
>Vertical accuracy | Нет | Точность по вертикали |
> Maximum Location Age | Нет | Максимальный возраст данных о позиции, используется для сохраненных данных в секундах Integer (0..65535) |
>Delay | Нет | Время ответа в секундах |
Л.3 Сообщение SUPL RESPONSE
Сообщение SUPL RESPONSE является ответом на SUPL START. Значения параметров SUPL RESPONSE приведены в таблице Л.9.
Таблица Л.9 - Значения параметров SUPL RESPONSE
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Positioning Method | Да | Метод позиционирования
- только A-GPS SET Assisted
- только A-GPS SET Based
- предпочтительный A-GPS SET Assisted (A-GPS SET Based в случае недоступности)
- предпочтительный A-GPS SET Based (A-GPS SET в случае недоступности)
- только A-GNSS SET Assisted
- только A-GNSS SET Based
- предпочтительный A-GNSS SET Assisted (A-GANSS SET Based в случае недоступности)
- предпочтительный A-GNSS SET Based (A-GANSS SET Assisted в случае недоступности)
- Autonomous GPS
- Autonomous GNSS
- AFLT
- Enhanced Cell/sector
- EOTD
- OTDOA
- MBS
- No position
- Historical Data Retrieval
- Session-Info Query |
SLP Address | Нет | Адрес сервиса SUPL
- IPAddress
IPv4
IPv6
- FQDN |
SET Auth key | Нет | Ключ авторизации в сервисе SUPL |
Key Identity 4 | Нет | Ключ SET |
Л.4 SUPL POS INIT
Сообщение SUPL POS INIT посылается после сообщения SUPL INIT, когда сеть провайдера является инициатором вызова сервиса, и после сообщения SUPL RESPONSE, когда инициатором является SET. Значения параметров сообщения SUPL POS INIT приведены в таблице Л.10.
Таблица Л.10 - Значения параметров сообщения SUPL POS INIT
Параметр | Наличие обязательный/ необязательный | Значение/описание |
SET capabilities | Да | Перечень возможностей SET |
Requested Assistance Data | Нет | Определяет запрошенные вспомогательные данные GPS и GANSS.
Присутствие этого элемента указывает, что SET хочет получить определенные вспомогательные данные GPS и GANSS от SLP. SET может использовать этот элемент в любой комбинации с помощью A-GPS SET/на основе A-GPS SET/с помощью A-GANSS SET/на основе A-GANSS SET и позиционирования, инициированного сетью/SET.
Параметр Requested Assistance Data не применим к TIA-801 [TIA-801] и LPP/LPPe [3GPP LPP/3GPP LPPe] |
Location ID | Нет | Определяет текущую обслуживающую соту, текущую обслуживающую точку WLAN или текущую обслуживающую информацию БС WiMAX для SET |
Position | Нет | Определяет текущее местоположение SET |
SUPLPOS | Нет | Содержит сообщение SUPLPOS.
Примечание - Используется только при отправке SET значения Position
|
Ver | Нет | Хэш функция сообщения SUPL INIT
Используется, когда инициатор сеанса - сеть провайдера. SET вычисляет хэш полученного SUPL INIT и включает результат хеширования в сообщение |
Значения параметров Position представлены в таблице Л.11.
Таблица Л.11 - Значения параметров Position
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Position | Да |
|
>Timestamp | Да | Время фиксации позиции |
>Position Estimate | Да |
|
>>Sign of latitude | Да | Направление Север или Юг |
>>Latitude | Да | Значение широты, Integer (от 0 ° до 223 °-1°). Вычисляется из актуальной широты в градусах (от 0 ° до 90°) по формуле N  223 °·X/90<N+1 |
>>Longitude | Да | Значение долготы, Integer (от -223 ° до 223° -1°). Вычисляется из актуальной долготы в градусах (от -180 ° до +180 °) по формуле N 224 °·X/360<N+1 |
>>Uncertainty ellipse (semi major, semi minor, major axis) | Нет | Погрешность широты/долготы, по основной оси эллипса, погрешность малой оси эллипса и ориентация в градусах большой оси по отношению к северу. Соответствие между погрешностью широты/долготы и счетчиками см. в [3GPP GAD] |
>>Confidence | Нет | Достоверность положения целевого объекта в пределах описания формы (т.е. Эллипса неопределенности для 2D-описания и 3D-описания),%
Integer (от 0% до 100%) |
>>Altitude information | Нет | Только для 3D position |
>>>Altitude direction | Да | Высота (над эллипсоидом WGS84) или глубина (под эллипсоидом WGS84), м |
>Velocity | Нет | Значения скорости и азимута определено в [3GPP GAD] |
Значения Requested Assistance Data для методов определения местоположения A-GPS приведены в таблице Л.12.
Значения Requested Assistance Data описывают запрошенные вспомогательные данные A-GPS:
- альманах;
- время UTC;
- параметры ионосферной модели;
- доплеровский сдвиг;
- приблизительное расположение абонента;
- временной сдвиг между различными ГНСС и GPS;
- оценка кодовой задержки;
- сообщение целостности из навигационного кадра;
- список видимых спутников.
Таблица Л.12 - Значения параметров Requested Assistance Data
Параметр | Наличие обязательный/необязательный | Значение/описание |
>Timestamp | Да | Время фиксации позиции |
>Position Estimate | Да |
|
>Sign of latitude | Да | Направление Север или Юг |
>Latitude | Да | Значение долготы, Integer (от 0 ° до 223 °-1°). Вычисляется из актуальной долготы в градусах (от 0 ° до 90°) по формуле N 223 °·X/90<N+1 |
>>Longitude | Да | Значение широты, Integer (от -223 ° до 223 °-1°). Вычисляется из актуальной долготы в градусах (от -180 ° до +180 °) по формуле N 224 °·X/360<N+1 |
Л.5 SUPL POS
Сообщение SUPL POS передает упакованные данные в формате TIA-801, RRLP, RRC или LPP/LPPe и может содержать дополнительно скорость, помощь по опорному времени UTRAN GPS/GANSS или результат опорного времени UTRAN GPS/GANSS. Значения параметров сообщения SUPL POS приведены в таблице Л.13.
Таблица Л.13 - Значения параметров сообщения SUPL POS
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Positioning Payload | Да | Пакет в формате TIA-801, RRLP, RRC или LPP/LPPe |
Velocity | Нет | Скорость SET, необходимая для преодоления недостатка этой информации в RRLP и RRC. Определено в [3GPP GAD] Поддерживается один из четырех форматов:
- горизонтальная скорость
азимут
горизонтальная скорость;
- горизонтальная и вертикальная скорости вектор по вертикали
азимут
горизонтальная скорость
вертикальная скорость;
- погрешность горизонтальной скорости
азимут
горизонтальная скорость погрешность
горизонтальной скорости;
- погрешность горизонтальной и вертикальной скорости
вектор по вертикали
азимут
горизонтальная скорость
вертикальная скорость
горизонтальная скорость |
UTRAN GPS Reference Time Assistance | Нет | SLP отправляет на SET, если это запрошено, SET в параметре запрошенных вспомогательных данных (в SUPL POS INIT), если обслуживающая сота - WCDMA/TD-SCDMA, а RRLP используется в качестве протокола позиционирования |
UTRAN GPS Reference Time Result | Нет | Этот параметр отправляется SET на SLP, если он доступен и запрашивается SLP в параметре поддерживаемой сетевой информации (в SUPL INIT, SUPL RESPONSE и SUPL TRIGGERED RESPONSE), если обслуживающая сота - WCDMA/TD-SCDMA и RRLP используется как протокол позиционирования |
UTRAN GANSS Reference Time Assistance | Нет | SLP отправляет на SET, если это запрошено SET в параметре запрошенных вспомогательных данных (в SUPL POS INIT), если обслуживающая сота - WCDMA/TD-SCDMA, а RRLP используется в качестве протокола позиционирования |
UTRAN GANSS Reference Time Result | Нет | Этот параметр отправляется SET на SLP, если он доступен, и запрашивается SLP в параметре поддерживаемой сетевой информации (в SUPL IN IT, SUPL RESPONSE и SUPL TRIGGERED RESPONSE), если обслуживающая сота - WCDMA/TD-SCDMA и RRLP используется как протокол позиционирования |
Л.6 Сообщение SUPL END
Сообщение SUPL END заканчивает сеанс SUPL при нормальном окончании или ошибке. Значение параметров SUPL END представлено в таблице Л.14.
Таблица Л.14 - Значение параметров сообщения SUPL END
Параметр | Наличие обязательный/ необязательный | Значение/описание |
Position | Нет | Определяет местоположение SET |
Status Code | Нет | Статус сообщения или ошибки.
Сообщения об ошибках имеютзначения от 0 до 99, информационные сообщения имеют значения от 100 до 199 |
Ver | Нет | Этот параметр содержит хэш сообщения SUPL INIT и рассчитывается SET. Этот параметр ДОЛЖЕН присутствовать в ситуациях, когда сообщение SUPL END отправляется как прямой ответ на SUPL INIT (как в режиме прокси, так и в режиме без прокси) |
SET Capabilities | Нет |
|
| Нет |
|
Значения параметра Status Code представлены в таблице Л.15.
Таблица Л.15 - Значения параметра Status Code
Status Code | Описание |
Значение ошибок | |
unspecified | Неизвестная ошибка |
systemFailure | Сбой системы |
protocol Error | Ошибка декодирования протокола |
dataMissing | Отсутствуют необходимые данные |
unexpectedData Value | Неверное значение данных |
posMethodFailure | Выбранный метод позиционирования недоступен |
posMethodMismatch | Не поддерживаются методы определения местоположения с запрошенной точностью QoS, возможностями SET и методом позиционирования SLP |
posProtocolMismatch | Не найден протокол позиционирования, поддерживаемый одновременно SET и SLP |
targetSETnotReachable | SET не отвечает на запрос |
versionNotSupported | Не поддерживаемая версия ULP |
resourceShortage | Не достаточно ресурсов для обслуживания SET |
invalidSessionld | Неверный Sessionld |
unexpectedMessage | Полученное сообщение не в списке ожидаемых |
nonProxyModeNotSupported | SET не поддерживает режим "NonProxy" |
proxyModeNotSupported | SET не поддерживает режим "Proxy" |
positioningNotPermitted | SET не авторизован SLP для получения данных |
authNetFailure | SET не авторизован сетью провайдера, используется только в сообщении SUPL AUTH_RESP |
Информационные значения | |
consentDeniedByUser | Пользователь отказал в согласии на сеанс определения местоположения |
consentGrantedByUser | Пользователь согласился на сеанс определения местоположения |
Л.7 Описание обмена сообщениями при сеансе связи (пример)
==== SUPL SESSION START ================================================================>
=== mobile => server ===
<ULP-PDU>
<length>29</length>
<version>
<maj>2</maj>
<min>1</min>
<servind>0</servind>
</version>
<sessionlD>
<setSessionlD>
<sessionld>23376</sessionld>
<setld>
<iPAddress>
<ipv4Address>7F 00 01 01</ipv4Address>
</iPAddress>
</setld>
</setSessionlD>
</sessionlD>
<message>
<msSUPLSTART>
<sETCapabilities>
<posTechnology>
<agpsSETassisted><false/></agpsSETassisted>
<agpsSETBased><true/></agpsSETBased>
<autonomousGPS><true/></autonomousGPS>
<aFLT><false/></aFLT>
<eCID><false/></eCID>
<eOTD><false/></eOTD>
<oTDOA><false/></oTDOA>
</posTechnology>
<prefMethod><agpsSETBasedPreferred/></prefMethod>
<posProtocol>
<tia801><false/></tia801>
<rrlp><true/></rrlp>
<rrc><false/></rrc>
<ver2-PosProtocol-extension>
<lpp><true/></lpp>
</ver2-PosProtocol-extension>
</posProtocol>
</sETCapabilities>
<locationld>
<celllnfo>
<ver2-Celllnfo-extension>
<wlanAP>
<apMACAddress>
111111111111111111111111111111111111111111111111
</apMACAddress>
</wlanAP>
</ver2-Celllnfo-extension>
</celllnfo>
<status><current/></status>
</locationld>
</msSUPLSTART>
</message>
</ULP-PDU>
=== server => mobile ===
<ULP-PDU>
<length>33</length>
<version>
<maj>2</maj>
<min>1</min>
<servind>0</servind>
</version>
<sessionlD>
<setSessionlD>
<sessionld>23376</sessionld>
<setld>
<iPAddress>
<ipv4Address>70 8E 2F 0E</ipv4Address>
</iPAddress>
</setld>
</setSessionlD>
<slpSessionlD>
<sessionlD>37 37 34 00</session ID>
<slpld>
<fQDN>supl.ficom-it.info</fQDN>
</slpld>
</slpSessionlD>
</sessionlD>
<message>
<msSUPLRESPONSE>
<posMethod><agpsSETbased/></posMethod>
</msSUPLRESPONSE>
</message>
</ULP-PDU>
====SUPL POSINIT
=====================================================================>
=== mobile => server ===
<ULP-PDU>
<length>181<llength>
<version>
<maj>2</maj>
<min>1</min>
<servind>0</servind>
</version>
<sessionlD>
<setSessionlD>
<sessionld>23376</sessionld>
<setld>
<iPAddress>
<ipv4Address>70 8E 2F 0E</ipv4Address>
</iPAddress>
</setld>
</setSessionlD>
<slpSessionlD>
<sessionlD>37 37 34 00</sessionlD>
<slpld>
<fQDN>supl.ficom-it.info</fQDN>
</slpld>
</slpSessionlD>
</sessionlD>
<message>
<msSUPLPOSINIT>
<sETCapabilities>
<posTechnology>
<agpsSETassisted><false/></agpsSETassisted>
<agpsSETBased><true/></agpsSETBased>
<autonomousGPS><true/></autonomousGPS>
<aFLT><false/></aFLT>
<eCID><false/></eCID>
<eOTD><false/></eOTD>
<oTDOA><false/></oTDOA>
</posTechnology>
<prefMethod><agpsSETBasedPreferred/></prefMethod>
<posProtocol>
<tia801><false/></tia801 >
<rrlp><true/></rrlp>
<rrc><false/></rrc>
<ver2-PosProtocol-extension>
<lpp><true/></lpp>
<posProtocolVersionLPP>
<majorVersionField>14</majorVersionField>
<technicalVersionField>0</technicalVersionField>
<editorialVersionField>1</editorialVersionField>
</posProtocolVersionLPP>
</ver2-PosProtocol-extension>
</posProtocol>
</sETCapabilities>
<requestedAssistData>
<almanacRequested><false/></almanacRequested>
<utcModelRequested><false/></utcModelRequested>
<ionosphericModelRequested><true/></ionosphericModelRequested>
<dgpsCorrectionsRequested><false/></dgpsCorrectionsRequested>
<referenceLocationRequested><true/></referenceLocationRequested>
<referenceTimeRequested><true/></referenceTimeRequested>
<acquisitionAssistanceRequested><true/></acquisitionAssistanceRequested>
<realTimelntegrityRequested><false/></realTimelntegrityRequested>
<navigationModelRequested><true/></navigationModelRequested>
<navigationModelData>
<gpsWeek>0</gpsWeek>
<gpsToe>0</gpsToe>
<nSAT>0</nSAT>
<toeLimit>0</toeLimit>
</navigationModelData>
<ver2-RequestedAssistData-extension>
<ganssRequestedGenericAssistanceDataList>
<GanssReqGenericData>
<ganssld>4</ganssld>
<ganssRealTimelntegrity><false/></ganssRealTimelntegrity>
<ganssAlmanac><false/></ganssAlmanac>
<ganssNavigationModelData>
<ganssWeek>0</ganssWeek>
<ganssToe>0</ganssToe>
<t-toeLimit>0</t-toeLimit>
</ganssNavigationModelData>
<ganssReferenceMeasurementlnfo><false/></ganssReferenceMeasurementlnfo>
<ganssUTCModel><false/></ganssUTCModel>
<ganssAuxiliarylnformation><true/></ganssAuxiliarylnformation>
</GanssReqGenericData>
<GanssReqGenericData>
<ganssld>0</ganssld>
<ganssRealTimelntegrity><false/></ganssRealTimelntegrity>
<ganssAlmanac><false/></ganssAlmanac>
<ganssNavigationModelData>
<ganssWeek>0</ganssWeek>
<ganssToe>0</ganssToe>
<t-toeLimit>0</t-toeLimit>
</ganssNavigationModelData>
<ganssReferenceMeasurementlnfo><false/></ganssReferenceMeasurementlnfo>
<ganssUTCModel><false/></ganssUTCModel>
<ganssAuxiliarylnformation><true/></ganssAuxiliarylnformation>
</GanssReqGenericData>
</ganssRequestedGenericAssistanceDataList>
</ver2-RequestedAssistData-extension>
</requestedAssistData>
<locationld>
<celllnfo>
<ver2-Celllnfo-extension>
<wlanAP>
<apMACAddress>
111111111111111111111111111111111111111111111111
</apMACAddress>
</wlanAP>
</ver2-Celllnfo-extension>
</celllnfo>
<status><current/></status>
</locationld>
<position>
<timestamp>211013141128Z</timestamp>
<positionEstimate>
<latitudeSign><north/></latitudeSign>
<latitude>3487983</latitude>
<longitude>-5689535</longitude>
</positionEstimate>
</position>
<sUPLPOS>
<posPayLoad>
<ver2-PosPayLoad-extension>
<IPPPayload>
<OCTET_STRING>
92 07 08 21 E4 00 28 05 04 14 02 81 8A 01 4C 01
10 6C 03 62 C4 4A 1B 48 06 04 1B 06 C4 44 40 82
</OCTET_STRING>
<OCTET_STRING>
92 08 10 62 62 12 60 44 20 E0 26 E0 80 41 81 06
60 21 FF FF FF FF FF FF FF FC 02 CE 40 05 0F FF
FF FF FF FF FF FF E0 03 30 D0 FF FF FF FF FF FF
FF FE 00
</OCTET_STRING>
</IPPPayload>
</ver2-PosPayLoad-extension>
</posPayLoad>
</sUPLPOS>
</msSUPLPOSINIT>
</message>
</ULP-PDU>
=== server => mobile ===
<ULP-PDU>
<length>0</length>
<version>
<maj>2</maj>
<min>1</min>
<servind>0</servind>
</version>
<sessionlD>
<setSessionlD>
<sessionld>23376</sessionld>
<setld>
<iPAddress>
<ipv4Address>70 8E 2F 0E</ipv4Address>
</iPAddress>
</setld>
</setSessionlD>
<slpSessionlD>
<sessionlD>37 37 34 00</sessionlD>
<slpld>
<fQDN>supl.ficom-it.info</fQDN>
</slpld>
</slpSessionlD>
</sessionlD>
<message>
<msSUPLPOS>
<posPayLoad>
<ver2-PosPayLoad-extension>
<IPPPayload>
<OCTET_STRING>
10 C1 19 40 00 EC 80 0F E2 84 64 00 0C 05 64 00
1C 00 04 50 03 00 00 2F 81 3A 02 40 3F D0 E3 BB
DF 16 28 1D 01 29 0D 59 A2 AA 10 BA D9 7B EA 1F
EB E5 81 6A 6C 8F E0 00 A1 0D 71 F0 A8 2B F0 DB
92 F7 24 E3 79 09 7F AD 9E 2F 8E 08 7F EF 79 F7
80 00 00 00 00 00 00 00 00 00 00 3E 04 00 58 04
E8 09 00 FF 0A AC CF CC 20 A0 74 04 A8 94 90 7A
B4 44 BC AB 1B 5E 7F A6 3B 01 FC E7 1D 80 02 84
37 F5 EE 9E 29 C9 AE F4 BE CB F6 13 5A 00 42 34
FE 83 1D FF 42 10 46 00 00 00 00 00 00 00 00 00
00 00 F8 18 02 C0 13 A0 24 04 00 1B 2A 3A 21 22
81 D0 10 07 5C C6 16 CF B4 D4 8F 45 BD FE 9C 78
02 EC 4B 4E 00 0A 10 D7 87 DA 72 68 FC 8E 93 F0
BA 77 A2 98 00 89 09 D9 C4 88 00 17 AC B8 00 00
00 00 00 00 00 00 00 00 03 E1 00 02 E0 4E 80 90
0F FF CA 12 EB 41 8A 07 40 4C 9D 68 0A 7B 73 B5
80 4B 39 37 FA 4D D0 12 6A 2B 88 00 28 43 60 DE
69 B7 11 7B 39 C8 6C F3 5E 75 E0 04 23 B7 A7 6E
E0 00 5E A1 A0 00 00 00 00 00 00 00 00 00 00 0F
8A 80 0C 81 3A 02 40 40 28 9F 9A DA 4C 28 1D 01
16 F1 C3 5A AE DF 86 4C 21 7F 5F E8 F2 80 DC 50
8C A0 00 A1 0D AA 36 A6 25 C6 AC B8 F0 94 3D 86
A0 80 4C 8D FB 9D 71 80 00 85 DB 80 00 00 00 00
00 00 00 00 00 00 3E 32 00 A4 04 E8 09 01 00 49
25 66 0C 78 A0 74 04 8C 03 4A D6 B8 FC 93 22 AD
DB 7F A0 06 03 2F B9 33 80 02 84 34 55 A2 99 2F
BE 3C EC E0 55 66 31 6A 01 2A 16 5E 9D C6 01 3E
2B D6 00 00 00 00 00 00 00 00 00 00 00 F8 F0 02
C0 13 A0 24 03 FF 7B 69 26 23 82 81 D0 12 31 E9
F0 AA B8 F6 FE AD5 1 C5 FE A7 4C 14 FF 5E 4A 00
0A10 D0 FB 0A 6F 38 A4 A1 38 36 23 88 A3 C8 02
E9 AC E9 0B C7 FD 28 96 F8 00 00 00 00 00 00 00
00 00 00 03 ED 06 1E 7C 40 16 A9 A7 16 9F 59 00
28 43 46 63 7F F3 A9 0F 85 16 AA BE B1 D3 FD 10
1A 68 68 E5 87 D4 E0 0A 10 DD 58 A7 8D 14 35 59
F6 4B 96 C2 C8 FF C4 08 7F 1A 49 49 F5 74 02 84
36 9A E0 DF 86 A2 67 70 AF A2 15 58 3F C1 03 0B
CB 8B FA 7D 4C 00 A1 0D 05 E4 46 CF 01 A7 61 A4
A3 71 65 50 00 41 0C 67 E2 75 DF 54 C0 28 43 17
AD A9 13 2A 41 1F 71 50 53 5E 24 00 10 51 25 29
BF 97 D6 20 0A 10 C6 D8 DA 9B F5 5F C5 D6 9B B7
88 C1 00 84 19 F4 BA 17 FD F5 54 02 84 35 D0 37
50 CC 88 8D C1 04 EE D6 88 C0 21 07 35 F5 8F 62
7D 34 00 A1 0C E9 62 21 23 82 39 71 B9 C2 A7 7A
D0 00 42 04 A0 21 D5 DF 51 00 28 43 43 B8 8A 51
72 7F 2C 71 CB 65 94 2C 00 10 93 9A B9 23 97 D5
B0 0A 10 D0 2B 81 A5 91 6A EB 00 B0 3C 06 30 FF
84 28 0F 46 30 35 F5 3C 02 84 35 6E 3F 9C 5F 71
AD B7 31 5D 1A 0B 40 01 0B 43 B1 93 03 7D 4E 00
A1 0C FE 3B 21 7C B2 12 E9 24 43 F4 71 AF FC 43
0B 64 24 3D 1F 55 40 28 43 3F ЗA 13 7F E9 E5 74
27 D1 13 E6 7C 02 10 D0 92 C8 83 A7 D4 00 0A 10
CC 43 9E FD 1F FB 44 42 19 5F A7 DE FF 84 39 C3
91 DD F5 F4 B4 02 84 33 BF 77 E9 DE A9 56 9E 43
60 19 C3 C0 11 0F 64 A6 93 04 7D 4C 00 A1 0D CD
3B E4 82 9B B1 A4 D9 25 E3 4B 0F F8 44 1B EE 26
4B 5F 50 C0 28 43 44 19 58 D8 D0 33 9C 2D D6 88
B0 F4 02 11 11 08 89 1C 17 D5 70 0A 10 CD 38 E6
4F FF 9B 74 96 66 E7 4A 8E FF C4 49 28 46 61 41
F5 08 02 84 33 8D 9C E2 FF 3E CF 08 5E FB CE 21
C0 11 13 2D 5D 7E 31 7D 43 00 A1 0C E5 B2 17 41
FA 3A 1F 8A 87 41 C4 10 00 45 31 60 22 A4 1F 52
C0 28 43 2C A2 9C 19 15 10 7F 6E CA FA 24 D4 01
11 53 71 47 C0 87 D4 00 0A 10 D3 FB 3F 7F E5 BC
9C D8 87 90 93 F9 00 C4 58 3A 46 3B ED F5 58 02
84 34 0E DC 77 7F BC 36 B9 1F DF D2 18 BF F1 17
60 25 7B 39 7D 45 00 A1 0D 39 0A 8C 1B 9F 25 90
69 36 3B A0 F0 08 46 14 37 A2 BЗ 9F 51 80 28 43
72 0E 04 3A 69 CD 76 C7 6F 0F 67 4C 02 11 93 31
17 E5 D7 D3 60 0A 10 CA C3 63 F4 B8 C0 ЗE F0 27
93 39 2D 00 44 69 39 92 54 21 F4 EC 02 84 33 19
8B 83 2A 66 FE C6 D2 9D 51 95 3F F1 1B 9C 65 98
4C 7D 4B 00 A1 0D 51 30 09 A7 45 83 40 EE 12 9C
E2 CF FC 47 03 E6 66 9C 9F 50 C0 28 43 0C 19 7A
0E 38 17 4D ED 97 53 D2 1B FE 11 D2 BC 07 C5 77
D4 90 0A 10 CA 60 E7 18 41 08 A5 B3 DA 7E 24 10
FF C4 79 50 4A 23 1D F5 74 02 84 32 6C ЗA 2E 7A
32 3D DC BB B9 95 B4 BF F1 1F 29 EF 89 E6 7D 48
00 A1 0D 51 E2 98 1F 1E E2 9D D3 70 49 7E EF FC
00 00 00
</OCTET_STRING>
</IPPPayload>
</ver2-PosPayLoad-extension>
</posPayLoad>
</msSUPLPOS>
</message>
</ULP-PDU>
====SUPL POS
=====================================================================>
=== mobile => server ===
<ULP-PDU>
<length>41</length>
<version>
<maj>2</maj>
<min>0</min>
<servind>0</servind>
</version>
<sessionlD>
<setSessionlD>
<sessionld>23376</sessionld>
<setld>
<iPAddress>
<ipv4Address>70 8E 2F 0E</ipv4Address>
</iPAddress>
</setld>
</setSessionlD>
<slpSessionlD>
<sessionlD>37 37 34 00</sessionlD>
<slpld>
<fQDN>supl.ficom-it.info</fQDN>
</slpld>
</slpSessionlD>
</sessionlD>
<message>
<msSUPLPOS>
<posPayLoad>
<ver2-PosPayLoad-extension>
<IPPPayload>
<OCTET_STRING>92 08 28 00</OCTET_STRING>
</IPPPayload>
</ver2-PosPayLoad-extension>
</posPayLoad>
</msSUPLPOS>
</message>
</ULP-PDU>
=== server => mobile ===
<ULP-PDU>
<length>32</length>
<version>
<maj>2</maj>
<min>1</min>
<servind>0</servind>
</version>
<sessionlD>
<setSessionlD>
<sessionld>23376</sessionld>
<setld>
<iPAddress>
<ipv4Address>70 8E 2F 0E</ipv4Address>
</iPAddress>
</setld>
</setSessionlD>
<slpSessionlD>
<sessionlD>37 37 34 00</sessionlD>
<slpld>
<fQDN>supl.ficom-it.info</fQDN>
</slpld>
</slpSessionlD>
</sessionlD>
<message>
<msSUPLEND>
</msSUPLEND>
</message>
</ULP-PDU>
==== SUPL SESSION END
=====================================================================>
Библиография
[1] | Технический регламент Таможенного союза ТР ТС 018/2011
| O безопасности колесных транспортных средств |
[2] | ISO/IEC 7498-1:94* | Information technology - Open Systems Interconnection - Basic reference model - Part 1: The basic model (Информационные технологии. Взаимодействие открытых систем. Базовая эталонная модель. Часть. 1. Базовая модель) |
| ||
[3] | ETSI TS 126 267 (3GPPTS 26.267) | Technical Specification Group Services and System Aspects; eCall Data Transfer; In-band modem solution; General description, Release 8 (Группа технических спецификаций услуги и системные аспекты; передача данных при экстренном вызове (eCall); тональный модем; общее описание, издание 8)
|
[4] | ISO/IEC 10967-1:2012 | Information technology - Language independent arithmetic - Part 1: Integer and floating point arithmetic (Информационные технологии. Арифметика, не зависимая от языка. Часть 1. Арифметические операции с комплексными целыми числами и с плавающей запятой)
|
[5] | GSM 03.38 (ETS 300 628) | Digital cellular telecommunication system (Phase 2); Alphabets and language-specific information (Правила кодирования: структура алфавитов и языков, используемых при передаче сервиса коротких сообщений)
|
[6] | GSM 03.40 (ETS 300 536) | Digital cellular telecommunication system (Phase 2 (Правила отправки и приема сервиса коротких сообщений)
|
[7] | IETF RFC 7836 | Guidelines on Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2010 and 34.11-2012 (Руководство по криптографическим алгоритмам, сопровождающее использование стандартов ГОСТ Р 34.10-2010 и 34.11-2012)
|
[8] | ISO 639-2:1998 | Codes for the representation of names of languages - Part 2: Alpha-3 code (Коды для представления названий языков. Часть 2. Трехбуквенный код) |
УДК 656.13:004:006.354 | МКС 33.020 |
| |
Ключевые слова: устройство/система вызова экстренных оперативных служб, дорожно-транспортное происшествие, маршрутизация, минимальный набор данных, протокол уровня поддержки услуг, протокол транспортного уровня, система экстренного реагирования при авариях, экстренный вызов, экстренная оперативная служба, экстренное сообщение | |