ГОСТ 33465-2023 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протоколы обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях

МЕЖГОСУДАРСТВЕННЫЙ СОВЕТ ПО СТАНДАРТИЗАЦИИ, МЕТРОЛОГИИ И СЕРТИФИКАЦИИ (МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

ГОСТ

33465—

2023

Глобальная навигационная спутниковая система

СИСТЕМА ЭКСТРЕННОГО РЕАГИРОВАНИЯ ПРИ АВАРИЯХ

Протоколы обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях

Издание официальное

Москва

Российский институт стандартизации 2023

ГОСТ 33465—2023

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Акционерным обществом «ГЛОНАСС» (АО «ГЛОНАСС»)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 31 августа 2023 г. № 164-П)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 18 октября 2023 г. № 1183-ст межгосударственный стандарт ГОСТ 33465—2023 введен в действие в качестве национального стандарта Российской Федерации с 1 июня 2024 г. с правом досрочного применения

5 ВЗАМЕН ГОСТ 33465—2015

Информация о введении в действие (прекращении действия) настоящего стандарта и изменений к нему на территории указанных выше государств публикуется в указателях национальных стандартов, издаваемых в этих государствах, а также в сети Интернет на сайтах соответствующих национальных органов по стандартизации.

В случае пересмотра, изменения или отмены настоящего стандарта соответствующая информация будет опубликована на официальном Интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации в каталоге «Межгосударственные стандарты»

© Оформление. ФГБУ «Институт стандартизации», 2023

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

II

ГОСТ 33465—2023

Содержание

1 Область применения..................................................................1

2 Нормативные ссылки..................................................................1

3 Термины, определения, сокращения и обозначения.........................................2

4 Общие положения....................................................................5

5 Протокол транспортного уровня.........................................................6

6 Протокол уровня поддержки услуг (общая часть)..........................................18

7 Сервис экстренного реагирования при аварии протокола уровня поддержки услуг...............56

8 Формат сообщения AL-ACK............................................................65

9 Сервис представления информации об обстоятельствах дорожно-транспортного происшествия.......................................................................65

Приложение А (справочное) Описание принципа построения навигационно-информационной системы на основе протокола транспортного уровня...........................84

Приложение Б (справочное) Анализ протокола транспортного уровня на основе концепции NGTP.........................................................86

Приложение В (обязательное) Коды результатов обработки...................................87

Приложение Г (справочное) Пример реализации алгоритма расчета контрольной суммы CRC-16 на языке С/*......................................................89

Приложение Д (справочное) Пример реализации алгоритма расчета контрольной суммы CRC-8 на языке С/*.......................................................90

Приложение Е (справочное) Таблицы кодировки символов...................................91

Приложение Ж (обязательное) Описание протокола уровня поддержки услуг (протокола EGTS) версии «01».............................................94

Приложение И (обязательное) Спецификация сервиса передачи и обработки мониторинговой информации EGTS_TELEDATA_SERVICE......................99

Приложение К (обязательное) Спецификация сервиса передачи на бортовое

оборудование сообщений и оповещений EGTS_NOTIFICATION_SERVICE...........................................126

Приложение Л (обязательное) Защищенный протокол определения местоположения пользователей SUPL (Secure User Plane Location).............................132

Библиография.......................................................................148

III

ГОСТ 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

Дата введения — 2024—06—01 с правом досрочного применения

1 Область применения

Настоящий стандарт распространяется на устройства вызова экстренных оперативных служб, предназначенные для установки на колесные транспортные средства категорий М и N, а также на системы вызова экстренных оперативных служб, установленные на транспортные средства категорий М и N в соответствии с требованиями [1].

Настоящий стандарт устанавливает требования к протоколам обмена данными между устрой-ством/системой вызова экстренных оперативных служб и инфраструктурой системы экстренного реагирования при авариях (далее — система), включая требования, связанные с предоставлением системой базовой услуги в целях выполнения требований [1] и ГОСТ 33464, а также требования к протоколам обмена данными при выполнении устройством/системой вызова экстренных оперативных служб функций мониторинга транспортного средства и определения, регистрации и передачи информации об обстоятельствах дорожно-транспортного происшествия.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие межгосударственные стандарты:

ГОСТ 33464—2023 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Устройство/система вызова экстренных оперативных служб. Общие технические требования

ГОСТ 33472—2023 Глобальная навигационная спутниковая система. Аппаратура спутниковой навигации для оснащения колесных транспортных средств. Общие технические требования.

Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов и классификаторов на официальном интернет-сайте Межгосударственного совета по стандартизации, метрологии и сертификации (www.easc.by) или по указателям национальных стандартов, издаваемым в государствах, указанных в предисловии, или на официальных сайтах соответствующих национальных органов по стандартизации. Если на документ дана недатированная ссылка, то следует использовать документ, действующий на текущий момент, с учетом всех внесенных в него изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то следует использовать указанную версию этого документа. Если после принятия настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение применяется без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку.

Издание официальное

1

ГОСТ 33465—2023

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________________________________________________________________________________________________________

система экстренного реагирования при авариях: Государственная территориально-распределенная автоматизированная информационная система, обеспечивающая оперативное получение с использованием сигналов глобальной навигационной спутниковой системы ГЛОНАСС совместно с другой

2

ГОСТ 33465—2023

действующей ГНСС информации о дорожно-транспортных происшествиях и иных чрезвычайных ситуациях на автомобильных дорогах, обработку, хранение и передачу этой информации экстренным оперативным службам, а также доступ к указанной информации заинтересованных государственных органов, органов местного самоуправления, должностных лиц, юридических и физических лиц.

Примечание — В Республике Беларусь система экстренного реагирования при авариях называется «ЭРА-РБ», в Республике Казахстан — «ЭВАК», в Российской Федерации — «ЭРА-ГЛОНАСС». Аналогом вышеуказанных систем является общеевропейская система 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 Сокращения и обозначения

В настоящем стандарте применены следующие сокращения и обозначения:

ГНСС — глобальная навигационная спутниковая система;

А-ГНСС — режим информационной поддержки навигационных определений;

3

ГОСТ 33465—2023

4

ГОСТ 33465—2023

4 Общие положения

4.1 Сетевая модель взаимодействия открытых систем согласно [2] определяет следующие уровни обмена данными:

- физический;

- канальный;

- сетевой;

- транспортный;

- сеансовый;

- представления данных и приложений.

4.2 В терминах сетевой модели OSI в системе экстренного реагирования при авариях для передачи данных между УСВ и оператором системы используются следующие протоколы:

- TCP — транспортный уровень;

- IP — сетевой уровень.

Соответствие сетевой модели OSI, стека протоколов TCP/IP и протоколов передачи данных системы экстренного реагирования при авариях представлено в таблице 1.

Таблица 1 — Соответствие уровней модели OSI, стека протоколов TCP/IP и протоколов системы

4.3 Настоящий стандарт устанавливает требования к следующим видам протоколов обмена информацией между элементами системы экстренного реагирования при авариях:

- протоколу транспортного уровня;

- протоколу уровня поддержки услуг, включая базовую услугу, оказываемую системой экстренного реагирования при авариях;

- протоколу уровня приложений;

- протоколу определения местоположения пользователей.

4.4 Настоящий стандарт также устанавливает требования к формату сообщения AL-ACK, которое высылается посредством использования тонального модема (см. [3]).

4.5 Нормативные положения настоящего стандарта, связанные с установлением требований к продолжительности временных интервалов при выполнении УСВ соответствующих функций, должны измеряться с погрешностью, не превышающей ±2 % от предельных значений указанных временных интервалов.

5

ГОСТ 33465—2023

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_RECONNЕСТ_ТО (см. 5.8).

5.5 Описание типов данных, используемых в протоколе транспортного уровня

5.5.1 Протоколом транспортного уровня определены и используются несколько различных типов данных полей и параметров. Состав и описание типов данных, используемых в протоколе транспортного уровня, представлены в таблице 2.

6

Таблица 2 — Состав и описание типов данных, используемых в протоколе транспортного уровня

ГОСТ 33465—2023

ГОСТ 33465—2023

5.5.2 Многобайтовые типы данных USHORT, UINT, ULONG, FLOAT и DOUBLE используют порядок следования байтов little-endian (младший байт вперед). Байты, составляющие последовательность в типах STRING и BINARY, должны интерпретироваться как есть, т. е. обрабатываться в порядке их поступления.

5.5.3 В протоколе транспортного уровня определены следующие типы полей и параметров:

- М (mandatory) — обязательный параметр. Параметр должен передаваться всегда;

- О (optional) — необязательный. Параметр может не передаваться, и его присутствие определяется другими параметрами, входящими в пакет.

5.6 Описание структур данных, используемых в протоколе транспортного уровня

5.6.1 Общая структура пакета протокола транспортного уровня определяется составом пакета и его форматом.

5.6.1.1 Пакет протокола транспортного уровня состоит из заголовка, поля «данные уровня поддержки услуг», а также поля контрольной суммы «данных уровня поддержки услуг».

Состав пакета протокола транспортного уровня представлен на рисунке 1.

Рисунок 1 — Состав пакета протокола транспортного уровня

5.6.1.2 Общая длина пакета протокола транспортного уровня не превышает значения 65535 байт, что соответствует максимальному значению параметра Window Size (максимальный размер целого пакета, принимаемый на стороне приемника) заголовка протокола TCP. Такое значение максимального размера пакета позволяет более эффективно использовать каналы передачи данных, базируясь только на стандартном методе управления потоком данных, заложенном в протоколе TCP/IP (см. [3]).

Формат пакета транспортного уровня представлен в таблице 3.

Таблица 3 — Состав пакета протокола транспортного уровня

5.6.1.3 Заголовок протокола транспортного уровня состоит из следующих параметров (полей): PRV, PRF, PR, CMP, ENA, RTE, HL, HE, FDL, PID. PT, PRA, RCA, TTL, HCS. Протокол уровня поддержки услуг представлен полем SFRD, контрольная сумма поля уровня поддержки услуг содержится в поле SFRCS.

Описание вышеуказанных параметров (полей) приведено в таблице 4.

8

ГОСТ 33465—2023

5.6.1.4 Блок-схема алгоритма сборки пакета ПТУ при приеме представлена на рисунке 2.

5.6.1.5 Кодировка печатных символов при сборке ПТУ осуществляется с использованием таблиц, приведенных в приложении Е.

Таблица 4 — Описание параметров (полей), входящих в состав пакета протокола транспортного уровня

9

ГОСТ 33465—2023

Окончание таблицы 4

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 представлена последовательность обмена пакетами при взаимодействии УСВ и ТП.

10

Начало

Чтение заголовка

Код EGTS_PC_UNS_PROTOCOL

Код EGTS_PC_INC_HEADERFORM

ГОСТ 33465—2023

Версия PRV и PRF поддерживается?

а

Код EGTS_PC_ HEADERCRC _ERROR <

TTL=TTL-1, Пересчет HCS, Отправка на другую ТП

Код EGTS_PC_TTLEXPIRED

Код EGTS_PC_OK

Код EGTS_PC_DATACRC_ERROR

10<HL<17

CRC8==HC

TTL>0

RTE==0

FDL>0

Код EGTS_PC_DECRYPT_ERROR

Чтение данных SFRD, Вычисление CRC16

SKID найден?

CRC16=

Декодирование поля SFRD

ENA поддерживается?

=SFRCS

ENA==0

Декодировано успешно?

CMP==0

Код EGTS_PC_INC_DATAFORM

Распаковка данных

Отправка EGTS_PT_RESPONSE

Конец

Код EGTS_PC_OK

Распаковано успешно?

А — маршрутизация и отправка пакета на другую ТП; Б — обработка данных протокола уровня поддержки услуг

Рисунок 2 — Блок-схема алгоритма сборки пакета ПТУ при приеме

11

ГОСТ 33465—2023

Таблица 5 — Формат поля SFRD для пакета типа EGTS_PT_APPDATA

Таблица 6 — Формат поля SFRD для пакета типа EGTS_PT_RESPONSE

Таблица 7— Формат поля SFRD для пакета типа EGTS_PT_SIGNED_APPDATA

12

ГОСТ 33465—2023

АС ТП

Пакет PT_APPDATAPID=1 (Авторизация)

Пакет PT RESPONSE на PID=1 (Подтверждение Авторизации) ◄-------------------------------------------------------------

Пакет PT_APPDATAPID=2 (Телематические данные)

Пакет PT RESPONSE на PID=2 (Подтверждение Телематических данных) 4---------------------------------------------------------

Пакет PT_APPDATAPID=n (Команда) 4-------------------------------------------------

Пакет PT_RESPONSE на PID=n (Подтверждение пакета с Командой) -----------------------------------------------------------►

Рисунок 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-режима

13

ГОСТ 33465—2023

Окончание таблицы 8

5.7.1.2 Описание параметров, входящих в состав SMS-сообщения в PDU-режиме, приведено ниже: - SMSC_AL — длина полезных данных адреса SMSC в октетах;

- SMSC_AT — тип формата адреса SMSC.

Возможные значения параметров SMSC_AT представлены в таблице 9.

Таблица 9 — Формат полей TP_DA_T и SMSC_AT (тип адреса)

Параметры полей TP_DA_T и SMSC_AT, приведенные в таблице 9, имеют следующие назначения: - TON (Type Of Number) — тип номера. Параметр TON может принимать следующие значения: а) ООО — неизвестный;

б) 001 — международный формат;

в) 010 — национальный формат;

г) 011 — специальный номер, определяемый сетью;

д) 100 — номер абонента;

е) 101 — буквенно-цифровой код (коды приведены в [5] с 7-битной кодировкой по умолчанию);

ж) 110 — укороченный;

и) 111 —зарезервировано;

- NPI (NumericPIanldentification) — тип плана нумерации (применимо для значений поля 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 последнего байта номера устанавливается значение OxF (1111b). Данный параметр опциональный, и его наличие зависит от значения параметра SMSC_AL. В случае отсутствия параметра SMSC_A используется SMSC из SIM-карты;

- ТР_МТ1 — (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

14

Окончание таблицы 10

ГОСТ 33465—2023

- TP_SRR — (Status Report Request) поле определяет необходимость отправки подтверждения со стороны SMSC на данное сообщение (если данный бит имеет значение 1, то требуется подтверждение);

- TP_UDHI — (User Data Header Indicator) поле определяет, передается ли заголовок пользовательских данных TP_UD_HEADER (если поле имеет значение 1, то заголовок присутствует);

- TP_RP — (Reply Path) поле определяет, присутствует ли поле RP в сообщении;

- TP_MR — идентификатор сообщения (должен увеличиваться на 1 при каждой отправке нового сообщения);

- TP_DA_L — длина полезных данных адреса получателя в октетах;

- TP_DA_T — тип формата адреса получателя. Возможные значения параметров TP_DA_T и SMSC_AT представлены в таблице 9;

- TP_DA — адрес получателя. Кодировка номера производится по тем же правилам, что и в параметре SMSC_A;

- TP_PID — идентификатор протокола (должен содержать значение 00);

- TP_DCS — тип кодировки данных (должен содержать значение 0x04, определяющий 8-битную кодировку сообщения, отсутствие компрессии);

- TP_VP — время актуальности данного сообщения. Формат данного поля определяется значением из таблицы 10. Параметр является опциональным. Его наличие и размер зависят от значения поля TP_VPF;

- TP_UDL — длина данных сообщения из поля TP_DL в байтах для используемой 8-битной кодировки;

- TP_UD — непосредственно передаваемые пользовательские данные. Формат данного поля, в зависимости от значения поля TP_UDHI, представлен в таблице 11.

Таблица 11—Формат поля TP_UD

Параметры поля TP_UD, приведенные в таблице 11, имеют следующие назначения:

- LUDH — длина заголовка пользовательских данных в байтах без учета размера данного поля;

- IEI «А», IEI «В» , IEI «N» — идентификатор информационного элемента «А», «В» и «N» соответственно, который определяет тип информационного элемента и может принимать следующие значения (в шестнадцатеричной системе):

а) 00 — часть конкатенируемого SMS-сообщения;

б) 01 — индикатор специального SMS-сообщения;

в)02 — зарезервировано;

15

ГОСТ 33465—2023

г) 03 — не используется;

д) 04—7F — зарезервировано;

е) 80—9F — для специального использования SME;

ж) АО—BF — зарезервировано;

и) СО—DF — для специального использования SC;

к) Е0—FF — зарезервировано.

- LIE «А», LIE «В», LIE «N» — параметры, определяющие размер данных информационных элементов «А», «В» и «N» соответственно в байтах без учета размера данного поля;

- IED «А», IED «В» , IED «N» — данные информационных элементов «А», «В» и «N» соответственно;

- UD — данные пользователя. Размер данного поля определяется наличием заголовка пользовательских данных TP_UD_HEADER, состоящего из полей LUDH, IEI, LIE, IED. Если заголовок не передается, то размер равен значению поля TP_UDL, указанному в таблице 8. Если заголовок передается, то размер поля вычисляется как разность (TP_UDL- LUDH -1).

В случае, если идентификатор информационного элемента IEI заголовка пользовательских данных TP_UD_HEADER имеет значение 00, структура поля IED будет иметь вид, указанный в таблице 12.

Таблица 12 — Формат поля данных информационного элемента, характеризующего часть конкатенируемого SMS-сообщения

5.7.1.3 УСВ, которые поддерживают функцию мониторинга ТС, при приеме SMS-сообщения используют формат SMS-DELIVER с 8-битной кодировкой. Формат принимаемого SMS-сообщения в PDU режиме должен соответствовать формату, указанному в ГОСТ 33472.

5.7.2 Описание формата передаваемой информации

5.7.2.1 При использовании SMS для обмена данными между УСВ и ТП пакеты, упакованные по правилам протокола транспортного уровня и протокола уровня поддержки услуг, помещаются в поле TP_UD (см. таблицу 8), при этом полный размер пакета протокола не должен превышать 140 байт. В этом случае механизм авторизации не используется и подтверждения протокола транспортного уровня в виде пакета типа EGTS_PT_RESPONSE и уровня поддержки услуг в виде подзаписи EGTS_SR_ RECORD_RESPONSE на переданные пакеты не требуются. Признаком успешного прохождения пакета до УСВ является уведомление о доставке SMS.

На подзапись EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE, содержащую команду или сообщение, требуется подтверждающая подзапись EGTS_SR_COMMAND_DATA с соответствующим значением полей СТ (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, которое содержит информационный элемент, характеризующий часть

16

ГОСТ 33465—2023

конкатенируемого SMS-сообщения. Таким образом, исходя из размера заголовка данных пользователя и максимального числа частей длинного сообщения, равного 255, максимально возможный размер пакета при использовании 8-битной кодировки может составлять 255(140 - 6) = 34170 байт.

При использовании SMS в качестве канала передачи пакетов EGTS на УСВ ограничивают размер одного пакета EGTS значением 10(140 - 6) = 1360 байт, т.к. использование большего размера может привести к переполнению внутреннего приемного буфера УСВ. Максимальный размер 1360 байт позволит передавать элементарное сообщение EGTS с использованием цифровой подписи (поля SIGL/ SIGD) и кода авторизации (ACL/AC).

5.8 Временные и количественные параметры протокола транспортного уровня при использовании пакетной передачи данных

Наименование и описание временных и количественных параметров протокола транспортного уровня приведены в таблице 13.

Таблица 13 — Временные и количественные параметры протокола транспортного уровня

5.9 Передача МНД в некорректируемом виде

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

17

ГОСТ 33465—2023

Описание полей:

- 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».

18

ГОСТ 33465—2023

Принципы, определяющие выбор версии протокола для обмена данными:

а) выбирается максимально высокая версия протокола, поддерживаемая обеими сторонами обмена;

б) с целью снижения нагрузки на ТП и обеспечения корректности определения устойчивой связи между УСВ и ТП попытки авторизации и передачи данных выполняются «снизу вверх», от младшей версии к старшей.

6.2 Обмен информационными сообщениями

Основной структурой протокола уровня поддержки услуг, содержащей в себе все необходимые данные для обработки информации или запроса на предоставление той или иной услуги, является запись. Каждая запись может иметь в своем составе несколько подзаписей, содержащих необходимые данные и определяющих действия, которые должен произвести сервис, обрабатывающий данную подзапись.

6.3 Обеспечение уведомления о результате доставки и обработки данных уровня поддержки услуг

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

6.4 Идентификация принадлежности данных, используемых в протоколе уровня поддержки услуг

Для идентификации принадлежности записи тому или иному сервису используется идентификатор типа сервиса, который определяет функциональные особенности и характеристики обрабатываемых данных. Тип сервиса является его идентификатором при внутриплатформенной маршрутизации и уникальным в рамках ППУ.

6.5 Определение характеристик данных в протоколе уровня поддержки услуг

Данные в ППУ записываются в виде подзаписи, имеющей свой уникальный идентификатор в рамках отдельного типа сервиса, а также строго определенную структуру организации данных в зависимости от подзаписи. Использованием такой организации данных в ППУ достигается однозначное определение типа данных, их физического смысла, размера и способа упаковки.

6.6 Структуры данных, используемые в протоколе уровня поддержки услуг

6.6.1 Общая структура

Общая структура ППУ, которая входит в состав пакета ПТУ, может содержать одну или несколько записей, идущих одна за другой и имеющих различный состав данных, предназначенных разным сервисам. Общая структура данных представлена на рисунке 4.

Рисунок 4 — Общая структура данных уровня поддержки услуг

6.6.2 Структура отдельной записи

6.6.2.1 Состав записи

Отдельная запись ППУ состоит из заголовка записи и данных записи. Состав отдельной записи представлен на рисунке 5.

Рисунок 5 — Состав отдельной записи уровня поддержки услуг

В заголовке записи находятся параметры, определяющие типы сервисов получателя и отправителя, идентификатор записи, идентификатор объекта (например, УСВ), длину передаваемых данных, а также различные флаги, определяющие наличие опциональных параметров и способ обработки.

19

ГОСТ 33465—2023

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

6.6.2.2 Структура записи

Структура отдельной записи уровня поддержки услуг приведена в таблице 15.

Таблица 15 — Формат отдельной записи ППУ

Параметры отдельной записи ППУ, приведенные в таблице 15, имеют следующие назначения:

- RL — параметр определяет размер данных из поля RD;

- RN — номер записи. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т. е. при достижении значения 65535 следующее значение должно быть 0. Значение из данного поля используется для подтверждения записи;

- RFL — содержит битовые флаги, определяющие наличие в данном пакете полей OID, EVID и ТМ, характеризующих содержащиеся в записи данные;

- 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.

20

AC

Команда-запрос EGTSTRACKDATA. Сообщение 1.

[Заголовок записи уровня поддержки услуг (OBFE=1, OID=Oxl23); EGTS_SR_COMMAND_DATA (СТ=СТ_СОМ, ССГ=ССОК, CID=1);

Command Data (ADR=0, SZ=O, ACT=O, CCD=EGTS_ECALL_THACK_DATA|] ■

ГОСТ 33465—2023

ТП

Подтверждение. Сообщение 2.

[EGTSSRCOMMANDDATA на сообщение 1

(CT=CT COMCONF, ССГ=СС OK, CID=1)] ,

EGTS_SR_TRACK_DATA. Сообщение 3.

[Заголовок записи уровня поддержки услуг (OBFE=1, OID=Oxl23)] -------------------------------------------►

Рисунок 6 — Алгоритм способа использования OID

- EVID — уникальный идентификатор события. Поле EVID задает глобальный идентификатор события и применяется, когда необходимо логически связать с одним-единственным событием набор нескольких информационных сущностей, причем сами сущности могут быть разнесены как по разным информационным пакетам, так и по времени. При этом прикладное программное обеспечение имеет возможность объединить все эти сущности воедино в момент представления пользователю информации о событии. Например, если с нажатием тревожной кнопки связывается серия фотоснимков, поле EVID должно указываться в каждой сервисной записи, связанной с этим событием на протяжении передачи всех сущностей, связанных сданным событием, как бы долго ни длилась передача всего пула информации;

- ТМ — время формирования записи на стороне отправителя (секунды с 00:00:00 01.01.2010 UTC). Если в одном пакете транспортного уровня передаются несколько записей, относящихся к одному объекту и моменту времени, то поле метки времени ТМ может передаваться только в составе первой записи;

- SST — идентификатор типа сервиса-отправителя, сгенерировавшего данную запись. Например, сервис, обрабатывающий навигационные данные на стороне УСВ, сервис команд на стороне ТП и т. д.;

- RST — идентификатор тип сервиса-получателя данной записи. Например, сервис, обрабатывающий навигационные данные на стороне ТП, сервис обработки команд на стороне УСВ и т. д.;

- RD — поле, содержащее информацию, присущую определенному типу сервиса (одну или несколько подзаписей сервиса типа, указанного в поле SST или RST, в зависимости от вида передаваемой информации).

6.6.3 Общая структура подзаписей

Формат отдельной подзаписи в ППУ приведен в таблице 16.

Таблица 16 — Формат отдельной подзаписи ППУ

6.6.4 На каждую информационную запись уровня поддержки услуг должно быть отправлено подтверждение, которое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки. Диаграмма, поясняющая работу механизма подтверждений при обмене сообщениями на уровне поддержки услуг, представлена на рисунке 7.

21

ГОСТ 33465—2023

AC

ТП

Рисунок 7 —Диаграмма обмена сообщениями

Каждое сообщение ППУ содержит в себе заголовок и контрольную сумму транспортного уровня и одну или несколько записей уровня поддержки услуг. Причем в одном сообщении могут содержаться как информационные записи, так и подтверждения на ранее принятые записи.

6.7 Описание сервисов предоставления услуг

6.7.1 Список поддерживаемых ППУ сервисов предоставления услуг, их идентификаторы в десятичном виде, а также описание представлены в таблице 17.

Код сервиса, указанный в таблице 17, приводится в заголовке записи ППУ (поля SST и RST).

Взаимодействие УСВ с сервером оператора национальной системы экстренного реагирования при авариях для получения ассистирующей информации, необходимой для расчета местоположения, осуществляется по протоколу SUPL, описание которого приведено в приложении Л.

6.7.2 Сервис EGTS_AUTH_SERVICE

Сервис EGTS_AUTH_SERVICE применяется для осуществления процедуры аутентификации УСВ на стороне ТП, а также получения учетных данных УСВ и информации об инфраструктуре на стороне УСВ (состав и версии программного обеспечения модулей, блоков, периферийного оборудования, информации о ТС). Сервис должен использоваться УСВ только в случае работы по протоколу TCP/IP после создания каждого нового соединения с ТП.

22

Таблица 17 — Список сервисов, поддерживаемых ППУ

м

W

ГОСТ 33465—2023

Окончание таблицы 17

ГОСТ 33465—2023

¹>УСВ, исполненная в конфигурации дополнительного оборудования.

2) УС в, исполненная в конфигурации штатного оборудования и предназначенная для реализации только базовой услуги системой экстренного реагиро

вания при авариях.

³) УС В, исполненная в конфигурации штатного оборудования и предназначенная для реализации дополнительных, кроме базовой, услуг системой экстренного реагирования при авариях.

ГОСТ 33465—2023

Требования данного пункта стандарта распространяются только на УСВ, исполненные в конфигурации дополнительного оборудования, и не распространяются на штатные УСВ, которые поддерживают только базовую услугу реагирования при аварии.

Список подзаписей, используемых сервисом EGTS_AUTH_SERVICE, представлен в таблице 18.

Таблица 18 — Список подзаписей сервиса EGTS_AUTH_SERVICE

6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE Структура подзаписи приведена в таблице 19.

Таблица 19 — Формат подзаписи EGTS_SR_RECORD_RESPONSE

Поля подзаписи EGTS_SR_RECORD_RESPONSE имеют следующие назначения:

- CRN — номер подтверждаемой записи (значение поля RN из обрабатываемой записи);

- RST — статус обработки записи. Коды результатов обработки приведены в приложении В.

При получении подтверждения отправителем он анализирует поле RST подзаписи EGTS_SR_ RECORD_RESPONSE и в случае получения статуса об успешной обработке стирает запись из внутреннего хранилища, иначе в случае ошибки и в зависимости от причины производит соответствующие действия.

25

ГОСТ 33465—2023

Рекомендуется совмещать подтверждение транспортного уровня (тип пакета EGTS_PT_ RESPONSE) с подзаписями — подтверждениями уровня поддержки услуг EGTS_SR_RECORD_ RESPONSE.

6.7.2.2 Подзапись EGTS_SR_TERM J DENTITY

Структура подзаписи приведена в таблице 20.

Таблица 20 — Формат подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE

Поля подзаписи 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 символах;

26

ГОСТ 33465—2023

- LNGC — код языка, предпочтительного к использованию на стороне УСВ, например «rus» — русский;

- NID — идентификатор сети оператора, в которой зарегистрирована УСВ. Используются 20 младших бит. Представляет пару кодов MCC-MNC. Структура поля NID представлена в таблице 21;

- BS — максимальный размер буфера приема УСВ в байтах. Размер каждого пакета информации, передаваемого на УСВ, не должен превышать данного значения. Значение поля BS может принимать различные значения (1024, 2048, 4096) и зависит от реализации аппаратной и программной частей конкретной УСВ;

- MSISDN — телефонный номер мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 15 символах (формат описан в национальных планах нумерации, утверждаемых соответствующими нормативными правовыми актами¹^).

- SSLPV — Номер версии протокола уровня поддержки услуг (номер версии протокола EGTS). Версия протокола уровня поддержки услуг (номер версии протокола EGTS) состоит из двух символов, левый символ «0» для версий от 1 до 9, «01» ... «09» соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.

Таблица 21 — Формат поля NID подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE

Параметры поля NID подзаписи EGTS_SR_TERM_IDENTITY имеют следующие назначения:

- МСС — код страны;

- MNC — код мобильной сети в пределах страны.

Расширение функциональности при взаимодействии УСВ и ТП, а также при взаимодействии между ТП реализовано посредством включения в протокол дополнительных команд и сервисов в целях стандартизации актуализируемых версий в виде увеличения номера версии протокола.

Стандарт описывает взаимодействие с помощью протокола версии «02», а также стратегию использования УСВ и ТП, поддерживающих взаимодействие с помощью протокола «02» с учетом совместимости их с УСВ и ТП, работающих с использованием протокола «01». Для этих целей в данном стандарте описаны также:

- взаимодействие с использованием протокола версии «01»;

- условия и алгоритмы аутентификации и авторизации, позволяющие реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий.

Условия и алгоритмы аутентификации и авторизации, позволяющие реализовать выбор версии протокола для взаимодействия между УСВ и ТП разных версий, приведены в разделе 6.1.3.

Передача поля HDID определяется настройками УСВ и целесообразна при возможности подключении УСВ к ТП, отличной от «домашней», например при использовании территориально распределенной сети платформ. При использовании только одной «домашней» платформы передача HDID не требуется.

«Простой» алгоритм использования сервисов подразумевает, что для УСВ доступны все сервисы и в таком режиме УСВ разрешено сразу отправлять данные для требуемого сервиса. В зависимости от действующих на ТП для данного УСВ разрешений в ответ на пакет с данными для сервиса может быть возвращена запись-подтверждение с соответствующим признаком ошибки. В системах с простым распределением прав на использование сервисов рекомендуется применять простой алгоритм. Это сокращает объем передаваемого трафика и время авторизации УСВ.

Алгоритм «запросов» на использование сервисов подразумевает, что перед тем, как использовать тот или иной тип сервиса (отправлять данные), УСВ должна получить от ТП информацию о доступных для использования сервисов. Запрос на использование сервисов может осуществляться как на этапе авторизации, так и после нее. На этапе авторизации запрос на использование того или иного сервиса производится путем добавления подзаписей типа SR_SERVICE_INFO и установки бита 7 поля SRVP в значение 1. После процедуры авторизации запрос на использование сервиса может быть осуществлен также при помощи подзаписей SR_SERVICE_INFO.

¹) В Российской Федерации «Российская система и план нумерации» утверждены приказом Министерства связи и массовых коммуникаций Российской Федерации от 25 апреля 2017 г. № 205.

27

ГОСТ 33465—2023

Совокупность МСС и MNC определяет уникальный идентификатор оператора сетей ПРТС стандартов GSM, CDMA, TETRA, UMTS, а также некоторых операторов спутниковой связи.

6.7.2.3 Подзапись EGTS_SR_MODULE_DATA

Структура подзаписи представлена в таблице 22.

Таблица 22 — Формат подзаписи EGTS_SR_MODULE_DATA сервиса EGTS_AUTH_SERVICE

Поля подзаписи SR_MODULE_DATA имеют следующие значения:

- МТ — тип модуля, определяет функциональную принадлежность модуля (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

Поля подзаписи EGTS_SR_VEHICLE_DATA имеют следующие значения:

- VIN — идентификационный номер ТС. Передается в двух полях VINL — последние 17 знаков, VINH — оставшаяся часть;

- VHT —тип ТС:

1 — пассажирский (М1),

28

ГОСТ 33465—2023

2 — автобус (М2),

3 — автобус (М3),

4 — легкая грузовая машина (N1),

5 — тяжелая грузовая машина (N2),

6 — тяжелая грузовая машина (N3),

7 — мотоцикл (Lie),

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

Поля подзаписи 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, то поле присутствует);

- РКЕ (Public Key Enable) — битовый флаг, определяет наличие полей PKL и РВК (если 1, то поля присутствуют);

29

ГОСТ 33465—2023

- ENA (Encriptrion Algorithm) — битовое поле, определяющее требуемый алгоритм шифрования пакетов. Если данное поле содержит значение 00, то шифрование не применяется, и подзапись EGTS_ SR_AUTH_PARAMS содержит только один байт, т.е. в зависимости от типа алгоритма наличие дополнительных параметров определяется остальными битами поля FLG;

- PKL — длина публичного ключа в байтах;

- РВК —данные публичного ключа;

- ISL — результирующая длина идентификационных данных;

- MSZ — параметр, применяемый в процессе шифрования;

- SS — специальная серверная последовательность байтов, применяемая в процессе шифрования;

- D — разделитель строковых параметров (всегда имеет значение 0);

- ЕХР — специальная последовательность, используемая в процессе шифрования.

Если требуется использование шифрования и запрашиваемый алгоритм шифрования поддерживается, авторизуемой стороной производится формирование и отправка записи 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

Поля подзаписи 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

30

ГОСТ 33465—2023

Поля подзаписи EGTS_SR_SERVICE_INFO имеют следующие значения:

- ST — тип сервиса, определяет функциональную принадлежность (например, EGTS_TELEDATA_ SERVICE, EGTS_ECALL_SERVICE и т. д.);

- SST — определяет текущее состояние сервиса (см. таблицу 27);

- SRVP — определяет параметры сервиса;

- SRVA (Service Attribute) — битовый флаг, атрибут сервиса:

а) 0 — поддерживаемый сервис,

б) 1 —запрашиваемый сервис;

- SRVRP (Service Routing Priority) — битовое поле, приоритет с точки зрения трансляции на него данных (в случае масштабирования системы и применения нескольких экземпляров приложений одного типа сервиса) определяется битами 0 и 1:

а) 00 — наивысший,

б) 01 — высокий,

в) 10 — средний,

г) 11 — низкий.

Таблица 27 — Список возможных состояний сервиса

6.7.2.8 Подзапись EGTS_SR_RESULT_CODE

Структура подзаписи представлена в таблице 28.

Поля подзаписи EGTS_SR_RESULT_CODE имеют следующее значение:

- RCD — код, определяющий результат выполнения операции авторизации.

Таблица 28 — Структура подзаписи EGTS_SR_RESULT_CODE сервиса EGTS_AUTH_SERVICE

6.7.2.9 Описание процедуры авторизации

Для работы УСВ в инфраструктуре оператора системы УСВ должен быть назначен уникальный идентификатор UNIT_ID, которому соответствуют определенные значения IMEI, IMSI и другие учетные данные УСВ, необходимые для осуществления взаимодействия с оператором системы.

Требование настоящего пункта не распространяется на штатные УСВ, которые поддерживают только базовую услугу реагирования при аварии. В конфигурации штатного оборудования сервис EGTS_AUTH_SERVICE не используется. В этом случае сообщения сервиса EGTS_ECALL_SERVICE могут отправляться сразу. EGTS_AUTH_SERVICE задействуется в случае использования СПРС и подключения к серверу по TCP/IR

Конфигурирование УСВ может быть произведено одним из следующих способов.

1) В пассивном режиме работы УСВ после нажатия кнопки «Дополнительные функции» и осуществления регистрации УСВ в сети СПРС инфраструктура сотового оператора отслеживает появление нового устройства и инициирует отправку ему SMS с учетными данными. Учетные данные передаются путем установки параметров УСВ при помощи подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE.

Должны быть установлены следующие параметры УСВ: параметр EGTS_GPRS_APN (параметр точки доступа для установления СПРС-сессии), параметр EGTS_SERVER_ADDRESS, определяющий адрес и порт сервера, с которым необходимо установить TCP/IP-соединение, уникальный идентификатор УСВ UNITJD.

31

ГОСТ 33465—2023

В случае установки параметров для УСВ, работающего по протоколу версии «02», может быть установлен параметр EGTS_PROTOCOL_CHOICE с массивом данных, определяющих перечень серверов ТП.

В массиве данных параметра EGTS_PROTOCOL_CHOICE будут переданы для каждой принимающей ТП:

- IPv4 адрес и порт для установки ТСР/1Р-соединения;

- вариант процедуры выбора версии протокола обмена данными:

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 с результатом проведения процедуры авторизации УСВ.

32

ГОСТ 33465—2023

AC

ТП

Регистрация в сети ПРС [IMEI, IMSI] через инфраструктуру сотового оператора --►

Установка параметра. Сообщение 1.

[EGTS_SR_COMMAND_DATA(CT=CT_COM, ССГ=СС_ОК, CID=0);

Command Data (АСГ=2, CCD=EGTS_GPRS_APN_/ ОТ^очка доступа ПРС')]

Подтверждение. Сообщение 2. [EGTS_SR_COMMAND_DATA на сообщение!; {CT=CT COMCONF, ССГ=СС ОК, CID=1)]

Установка параметра. Сообщение 3.

[EGTS_SR_COMMAND_DATA (СТ=СТ_СОМ, ССГ=СС_ОК, CID=1);

Command Data (АСТ=2, CCD=EGTS_SERVER_AD DRESS, DT="Aflpec и порт сервера")]

Подтверждение. Сообщение 4.

[EGTS_SR_COMMAND_DATA на сообщение 3;

(CT=CT COMCONF, ССГ=СС ОК, CID=1)]

Установка параметра. Сообщение 5.

[EGTS_SR_COMMAND_DATA(CT=CT_COM,ССТ=СС_ОК, CID=2); Command Data (АСГ=2, CCD=EGT5 UNITJD_/ DT=UNfTJD)]

Подтверждение. Сообщение 6.

[EGTS_SR_COMMAND_DATA на сообщение 5;

(CT=CT COMCONF, ССГ=СС ОК, CID=2)]

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 7. [EGTS SR TERMJDENTnY]

Подтверждение. Сообщение 8.

[EGTS SR RECORD RESPONSE на сообщение 7]

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 9. [EGTS SR VEHICLE DATA]

Подтверждение. Сообщение 10.

[EGTS SR RECORD RESPONSE на сообщение 9]

РЕЗУЛЬТАТ АУТЕНТИФИКАЦИИ. Сообщение 11. [EGTS SR RESULT CODE]

Подтверждение. Сообщение 12.

[EGTS SR RECORD RESPONSE на сообщение 11]

Рисунок 8 — Алгоритм конфигурации УСВ с использованием SMS

33

ГОСТ 33465—2023

★Массив данных 1 - массив данных, определяющих перечень серверов телематических платформ, с которыми необходимо установить TCP/IP-соединение. В массиве данных передаются для каждой ТП: IPv4 адрес и порт для установки TCP/iP-соединения; вариант процедуры выбора версии протокола обмена данными

Рисунок 9 — Алгоритм конфигурации УСВ версии «02» с передачей параметров выбора протокола с использованием SMS

34

AC

Установка TCP/IP соединения с сервером

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 1. [EGTS_SR_TERMJDENTITY (T1D=O, IMEI, IMSI)]

Подтверждение. Сообщение 2.

[EGTS_SR_RECORD_RESPONSE на сообщение 1]

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 3. [EGTS_SR_VEHICLE_DATA]

Подтверждение. Сообщение 4.

[EGTS_SR_RECORD_RESPONSE на сообщение 3]

Установка параметра. Сообщение 5.

[EGTS_SR_COMMAND_DATA (СТ=СТ_СОМ, ССТ=СС_ОК, СЮ=0);

Command Data (АСТ=2, ccD=EGTS_UNrr_iD, dt=unit_id)]

Подтверждение. Сообщение б.

[EGTSSRCOMMANDDATA на сообщение 5 (CT=CT_COMCONF, ССТ=СС_ОК, CID=O)]

РЕЗУЛЬТАТ АУТЕНТИФИКАЦИИ. Сообщение 7. [EGTS_SR_RESULT_CODE (RCD=EGTS_PCJD_N FOUND)]

Подтверждение. Сообщение 8.

[EGTS_SR_RECORD_RESPONSE на сообщение 7]

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 3.

[EGTS_SR_TERM-IDENTITY (TID=EGTS_UN!TJD, IMEI, IMSI)]

Подтверждение. Сообщение 10. [EGTS_SR_RECORD_RESPONSE на сообщение 9]

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 11. [EGTS_SR_VEHICLE_DATA]

Подтверждение. Сообщение 12.

[EGTS_SR_RECORD_RESPONSE на сообщение 11]

РЕЗУЛЬТАТ АУТЕНТИФИКАЦИИ. Сообщение 13. [EGTS_SR_RESULT_CODE]

Подтверждение. Сообщение 14.

[EGTS_SR_RECORD_RESPONSE на сообщение 13]

ГОСТ 33465—2023

тп

Рисунок 10 — Алгоритм конфигурации УСВ с использованием СПРС

35

ГОСТ 33465—2023

Рисунок 11 —Алгоритм выбора версии протокола при авторизации УСВ на стороне ТП

36

ГОСТ 33465—2023

AC

ТП

Сообщение 1, ID=1 [EGTS_SR_TERMJDENTITY], [EGTS_SR_MODULE_DATA],..., [EGTS_$R_MODULE_DATA]

Сообщение 2, ID=1 [egts_SR_record_response на сообщение lclD=l]

Сообщение 3, ID=2 [EGTS_SR_AUTH_PARAM]

Сообщение 4, ID=2 [EGTS_SR_RECORD_RESPONSE на сообщение 3clD=l]

Сообщение 5, ID=3 [EGTS_SR_AUTH_INFO]

Сообщение 6, ID=3 [EGTS_SR_RECORD_RESPONSE на сообщение 5 c ID=3] 4 ----- ---

Сообщение 7 ID=4[EGTS_SR_RESULT_CODE],[EGTS_SR_SERVICE_INFO],..., [EGTS_SR_SERVICE_INFO]

4---------------------------------------------------------------

Сообщение 8, ID=4 [EGTS_SR_RESPONSE на сообщение 7clD=4] -------- ►

Сообщение 9, ID=5 [EGTS_SR_SERVICE_INFO],... ,[EGTS_SR_SERVICEJNFO] -------------------------------------------------------------►

Сообщение 10, ID=5 [EGTS_SR_RESPONSE на сообщение 9, ID=5]

Рисунок 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, содержащие информацию о требуемых услугах (если используется процедура использования сервисов «по запросу») и/или поддерживаемых сервисах на стороне УСВ.

37

ГОСТ 33465—2023

Далее ТП создает сообщение 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

Поля подзаписи EGTS_SR_DISPATCHER_IDENTITY:

- DT — тип диспетчера;

- DID — уникальный идентификатор диспетчера;

- DSCR — краткое описание;

- TID — уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных AC (IMSI, IMEI, serialjd). В случае использования УСВ в качестве штатного устройства 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.

38

ГОСТ 33465—2023

Таблица 30 — Формат подзаписи EGTS_SR_VEHICLE_DATA_ADD сервиса EGTS_AUTH_SERVICE

- VME (Vehicle Model Enable) — битовый флаг, который определяет наличие поля VM в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);

- VBE (Vehicle Brand Enable) — битовый флаг, который определяет наличие поля VB в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);

- VTE (Vehicle Taxpayer Enable) — битовый флаг, который определяет наличие поля VOTIN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);

- VPE (Vehicle Primary Enable) — битовый флаг, который определяет наличие поля VOPSRN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);

- VNE (Vehicle Name Enable) — битовый флаг, который определяет наличие поля VON в подзаписи (если бит равен 1, то поле передается, если 0, то не передается).

Поля подзаписи EGTS_SR_VEHICLE_DATA_ADD имеют следующие значения:

- VSRM — государственный регистрационный знак (номер) ТС;

- VM — модель ТС;

- VB — марка ТС;

- VOTIN — ИНН собственника ТС;

- VOPSRN — ОГРН собственника ТС;

- VON — наименование организации — собственника ТС.

6.7.3 Сервис EGTS_COMMANDS_SERVICE

Данный тип сервиса предназначен для обработки команд, сообщений и подтверждений, передаваемых между УСВ, ТП и клиентскими приложениями.

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

Таблица 31 — Описание подзаписей сервиса EGTS_COMMANDS_SERVICE

6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA

Структура подзаписи представлена в таблице 32.

Таблица 32 — Структура подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE

39

ГОСТ 33465—2023

Окончание таблицы 32

Приведенные в таблице 32 параметры (поля) подзаписи EGTS_SR_COMMAND_DATA имеют следующие назначения:

- СТ — тип команды:

а) 0001 — CT_COMCONF — подтверждение о приеме, обработке или результат выполнения команды,

б) 0010 — CT_MSGCONF — подтверждение о приеме, отображении и/или обработке информационного сообщения, в) 0011 — CT_MSGFROM — информационное сообщение от УСВ, г) 0100 — CT_MSGTO — информационное сообщение для вывода на устройство отображения ТС, д) 0101 — СТ_СОМ — команда для выполнения на ТС,

е) 0110 — CT_DELCOM — удаление из очереди на выполнение переданной ранее команды,

ж) 0111 — CT_SUBREQ — дополнительный подзапрос для выполнения (к переданной ранее команде), и) 1000 — CT_DELIV — подтверждение о доставке команды или информационного сообщения;

- ССТ — тип подтверждения (имеет смысл для типов команд CT_COMCONF, CT_MSGCONF, СТ_ DELIV):

а) 0000 — СС_ОК — успешное выполнение, положительный ответ,

б) 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 и АС присутствуют в подзаписи,

б) 0 —поля ACL и АС отсутствуют в подзаписи;

- CHSFE (Charset Field Exists) — битовый флаг, определяющий наличие поля CHS в подзаписи:

а) 1 —поле CHS присутствует в подзаписи,

б) 0 —поле CHS отсутствует в подзаписи;

- CHS — кодировка символов, используемая в поле CD, содержащем тело команды. При отсутствии данного поля по умолчанию должна использоваться кодировка СР-1251. Определены следующие значения поля CHS (десятичный вид):

а) 0 —СР-1251,

б) 1 — IA5 (CCITTT.50)/ASCII (ANSI Х3.4),

40

ГОСТ 33465—2023

в) 2 — бинарные данные,

г) 3 — Latin 1 (рисунок Е.1),

д) 4 — бинарные данные,

е) 5—JIS (X 0208-1990),

ж) 6 — Cyrillic (рисунок Е.2),

и) 7 — Latin/Hebrew (рисунок Е.З),

к)8 —UCS2;

-ACL — длина в байтах поля АС, содержащего код авторизации на стороне получателя;

-АС — код авторизации, использующийся на принимающей стороне (автомобильная система), который обеспечивает ограничение доступа на выполнение отдельных команд. Если указанный в данном поле код не совпадает с ожидаемым значением, то в ответ на такую команду или сообщение АС должна отправить подтверждение с типом CC_ILL. Установка кода авторизации на стороне АС производится при помощи команды EGTS_SET_AUTH_CODE;

- CD — тело команды, параметры, данные, возвращаемые на команду-запрос, использующие кодировку из поля CHS или значение по умолчанию.

Размер данного поля определяется исходя из общей длины записи ППУ и длины предшествующих полей в данной подзаписи. Формат команды представлен в таблице 33. Данное поле может иметь нулевую длину (отсутствовать) в тех случаях, когда в ответ на команду или сообщение для УСВ не передаются никакие данные.

Таблица 33 — Формат команд автомобильной системы

Приведенные в таблице 33 параметры имеют следующие назначения:

- ADR — адрес модуля, для которого данная команда предназначена. Адрес определяется исходя из начальной конфигурации УСВ или из списка модулей, который может быть получен при регистрации УСВ через сервис EGTS_AUTH_SERVICE и передачи подзаписей EGTS_SR_MODULE_DATA;

- SZ — объем памяти для параметра (используется совместно с действием АСТ-2). При добавлении нового параметра в УСВ данное поле определяет, что для нового параметра требуется 2^SZ байт памяти в УСВ;

- ACT — описание действия, используется в случае типа команды, поле СТ-СТ_СОМ подзаписи 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.

41

ГОСТ 33465—2023

Таблица 34 — Формат подтверждения на команду УСВ

Приведенные в таблице 34 параметры имеют следующие назначения:

-ADR — адрес модуля, для которого данная команда предназначена. Адрес определяется исходя из начальной конфигурации УСВ или из списка модулей, который может быть получен при регистрации УСВ через сервис EGTS_AUTH_SERVICE и передаче подзаписей EGTS_SR_MODULE_DATA. В командах от оператора системы EGTS_ECALL_REQ, EGTS_ECALL_MSD_REQ поле ADR всегда должно иметь значение 0;

- CCD — код команды, сообщения из таблицы 35 или параметра из таблицы 37, в соответствии с которым передается сопутствующая информация в поле DT;

- DT — сопутствующие данные, тип и состав которых определяются значением поля CCD. Список и состав сопутствующих данных, передаваемых в подтверждении на некоторые команды, представлены в таблице 36.

6.7.3.2 Описание команд, параметров и подтверждений

Список и описание команд для УСВ представлены в таблице 35, список подтверждений на команды и сообщения от УСВ — в таблице 36; список параметров УСВ — в таблице 37.

Значения следующих параметров УСВ могут быть запрошены, но не могут быть изменены или удалены при помощи сервиса команд:

- EGTS_UNIT_SERIAL_NUMBER,

- EGTS_UNIT_HW_VERSION;

- EGTS_UNIT_SW_VERSION;

- EGTS_UNIT_VENDOR_ID;

- EGTSJNITJMEI.

Значения указанных параметров выставляются производителями соответствующих модулей и блоков УСВ, а также разработчиками ПО для них.

42

Таблица 35 — Список команд для УСВ

ГОСТ 33465—2023

Окончание таблицы 35

ГОСТ 33465—2023

Таблица 36 — Список подтверждений на команды и сообщения от УСВ

Продолжение таблицы 36

ГОСТ 33465—2023

-^ со

Окончание таблицы 36

ГОСТ 33465—2023

Таблица 37 — Список параметров УСВ

Продолжение таблицы 37

ГОСТ 33465—2023

£ Продолжение таблицы 37

ГОСТ 33465—2023

Продолжение таблицы 37

ГОСТ 33465—2023

g Продолжение таблицы 37

ГОСТ 33465—2023

Окончание таблицы 37

ГОСТ 33465—2023

ГОСТ 33465—2023

Таблица 38 — Пример заполнения массива параметров процедуры выбора версии протокола обмена данными EGTS_PROTOCOL_CHOICE

УСВ, установленными в конфигурации штатного оборудования, должна быть реализована поддержка следующих параметров:

- 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.

52

ГОСТ 33465—2023

6.7.3.3 Примеры процедур передачи команд приведены на рисунках 13 и 14.

АС ТП

Команда EGTS_ECALL_MSD_REQ, Сообщение 1.

[EGTS_SR_COMMAND_DATA (СТ=СТ_СОМ, ССГ=СС_ОК, CID=1);

Command Data (ADR=0, SZ=O, ACT=0, CCD=EGTS_ECALL_MSD_REQ)]

(Опционально) Подтверждение. Сообщение 2.

[EGTS_SR_COMMAND_DATA на сообщение 1

(СТ=СТCOMCONF, ССТ=СС OK, CID=1)J __к

MSD

Рисунок 13 — Отправка команды EGTS_ECALL_MSD_REQ по SMS

АС

Этап авторизации АС на телематической платформе

Запрос значения параметра. Сообщение 1.

[EGTS_SR_COMMAND_DATA (СТ=СТ_СОМ, ССГ=СС_ОК, CID=N);

с Command Data (ADR=O,SZ=O,ACT=1,CCD=EGTS UNIT IMEI)]

Подтверждение. Сообщение 2.

[EGTS_SR_RECORD_RESPONSE на сообщение 1] [EGTS_SR_COMMAND_DATA на сообщение 1 (СТ=СГ COMCONF, ССГ=СС OK, CID=N);

Command Data (ADR=0, CCD=EGTSUNITJMEI, DT=<IMEI number>)]

Рисунок 14 — Запрос значения параметра

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

Сервис EGTS_FIRMWARE_SERVICE предназначен для передачи на УСВ конфигурации и обновления программного обеспечения аппаратной части модулей и блоков самой УСВ, а также периферийного оборудования, подключенного к УСВ.

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

Таблица 39 — Список подзаписей сервиса EGTS_FIRMWARE_SERVICE

53

ГОСТ 33465—2023

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

Подзапись EGTS_SR_SERVICE_PART_DATA может использоваться сервисом для передачи сущностей на УСВ. Структура подзаписи представлена в таблице 40.

Таблица 40 — Структура подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE

Параметр EPQ содержит число частей, которое будет передано, а параметр PN — номер текущей части. Поле ID однозначно определяет сущность, которой принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть не более значения из поля EPQ. Если данное условие нарушается, то данные из такой подзаписи игнорируются.

Идентификатор объекта ID, поля PN и EPQ, а также идентификатор источника записи OID из заголовка уровня маршрутизации сервисов позволяют определить, какая часть и какого объекта получена для обработки. Это позволяет при достаточной пропускной способности канала одновременно передавать сущности для обновления программного обеспечения различных аппаратных частей УСВ и периферийного оборудования. Формат заголовка передаваемой сущности подзаписи представлен в таблице 41.

Таблица 41 —Формат заголовка передаваемой сущности подзаписи EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE

В таблице 41 параметры (поля) имеют следующие назначения:

- ОА — характеристика принадлежности передаваемой сущности;

-ОТ — тип сущности по содержанию. Определены следующие значения данного поля: а) 00 — данные внутреннего программного обеспечения («прошивка»),

54

ГОСТ 33465—2023

б) 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

В таблице 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 — Временные и количественные параметры протокола уровня поддержки услуг

55

ГОСТ 33465—2023

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

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

56

ГОСТ 33465—2023

В таблице 45 параметры (поля) имеют следующие назначения:

- SA — число передаваемых структур данных показаний акселерометра;

-ATM — время проведения измерений первой передаваемой структуры показаний акселерометра (число секунд с 00:00:00 01.01.2010 UTC).

Примечание — Для передачи требуемого числа отсчетов акселерометра можно использовать несколько идущих одна за другой подзаписей EGTS_SR_ACCEL_DATA, каждая из которых содержит различное время начала отсчета (поле «АТМ»);

- ADS1 ... ADS255 — структуры данных показаний акселерометра. Формат структуры представлен в таблице 46.

В составе подзаписи EGTS_SR_ACCEL_DАТА должна передаваться хотя бы одна структура ADS.

Таблица 46 — Формат структуры данных показаний акселерометра подзаписи EGTS_SR_ACCEL_DATA сервиса EGTS_ECALL_SERVICE

В таблице 46 параметры (поля) имеют следующие назначения:

- RTM — приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) в миллисекундах (мс);

- XAAV — значение линейного ускорения по оси X; 0,1 м/с²;

- YAAV — значение линейного ускорения по оси Y; 0,1 м/с²;

- ZAAV — значение линейного ускорения по оси Z; 0,1 м/с². Разрешающая способность полей ускорения должна быть не более 0,1 м/с² (0,01 д).

7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA

Структура подзаписи EGTS_SR_RAW_MSD_DATA представлена в таблице 47.

Таблица 47 — Формат подзаписи EGTS_SR_RAW_MSD_DATA сервиса EGTS_ECALL_SERVICE

В таблице 47 параметры (поля) имеют следующие назначения:

- FM — формат данных, содержащихся в поле MSD данной подзаписи. Данной версией документа определены следующие возможные значения данного поля:

а) 0 — формат неизвестен;

б) 1 — правила кодировки пакета в соответствии с ГОСТ 33464.

Не указанные в настоящем стандарте значения поля FM должны дополнительно согласовываться между производителем УСВ и оператором системы;

- MSD — минимальный набор данных.

Примечание — Подзапись EGTS_SR_RAW_MSD_DATAсервиса EGTS_ECALL_SERVICE используется УСВ также для передачи на ТП сообщения «Отмена реагирования». В этом случае поле «Message Identifier» должно иметь значение 0 (см. ГОСТ 33464—2023, приложение В, таблица В.1).

7.3.4 Подзапись EGTS_SR_TRACK_DATA

Структура подзаписи EGTS_SR_TRACK_DATA представлена в таблице 48.

57

ГОСТ 33465—2023

Таблица 48 — Структура подзаписи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE

В таблице 48 параметры (поля) имеют следующие назначения:

- SA — число передаваемых точек траектории движения ТС;

- ATM — опорное время проведения измерений (число секунд с 00:00:00 01.01.2010 UTC). Используется в качестве начального времени для первой передаваемой структуры с точностью 1 с. Более точное время измерения определяется с учетом поля RTM-структуры информации об отдельной точке траектории движения;

- TDS1 ... TDS255 — структуры данных, содержащие параметры отдельной точки траектории движения ТС. Формат структуры представлен в таблице 49.

Таблица 49 — Формат структуры данных отдельной точки траектории движения ТС подзаписи EGTS_SR TRACK_DATA сервиса EGTS_ECALL_SERVICE

В составе подзаписи EGTS_SR_TRACK_DATA должна передаваться хотя бы одна структура TDS.

В таблице 49 параметры (поля) имеют следующие назначения:

- TNDE (Track Node Data Exist) — битовый флаг, определяющий наличие компонентов данных о точке траектории движения в данной структуре TDS (поля LAT, LONG, SPDL, DIRH, SPDH, DIR):

а) 1 —данные передаются,

6)0 — данные не передаются (для указанного времени не удалось получить достоверные координаты и информацию о скорости с требуемой точностью. Или координаты не валидны, или определены с неудовлетворительной точностью). Поля LAT, LONG, SPDL, DIRH, SPDH, DIR не передаются в составе данной структуры, и ее размер составляет 1 байт;

- LOHS — битовый флаг определяет полушарие долготы:

а) 0 — восточная долгота,

б) 1 — западная долгота;

- LAHS — битовый флаг определяет полушарие широты:

а) 0 — северная широта,

б) 1 — южная широта;

- RTM — приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) — 0,1 с. Определяет время проведения измерения параметров данной точки траектории. Максимально возможное значение приращения составляет 3,2 с;

- LAT — широта по модулю, градусы (WGS 84) / 90 • OxFFFFFFFF и взята целая часть;

- LONG — долгота по модулю, градусы (WGS 84) / 180 • OxFFFFFFFF и взята целая часть;

58

ГОСТ 33465—2023

- 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.

59

g Таблица 50 — Список команд для УСВ

ГОСТ 33465—2023

Таблица 51—Список параметров УСВ

Продолжение таблицы 51

ГОСТ 33465—2023

® Продолжение таблицы 51

ГОСТ 33465—2023

Продолжение таблицы 51

ГОСТ 33465—2023

g Окончание таблицы 51

ГОСТ 33465—2023

ГОСТ 33465—2023

8 Формат сообщения AL-ACK

8.1 Сообщение AL-ACK, направляемое системой экстренного реагирования при авариях в сторону УСВ и содержащее подтверждение корректности минимального набора данных, принятого с использованием тонального модема, должно высылаться также посредством использования тонального модема.

8.2 Сообщение AL-ACK должно иметь формат, определенный в таблице 52.

Таблица 52 — Формат сообщения AL_ACK

9 Сервис представления информации об обстоятельствах дорожно-транспортного происшествия

9.1 Назначение сервиса представления информации об обстоятельствах дорожно-транспортного происшествия

Сервис предназначен для реализации режима УВС по определению, регистрации и передаче информации об обстоятельствах ДТП. В протоколе уровня поддержки услуг этот сервис определен как EGTS_EUROPROTOCOL_SERVICE и имеет код 22 (см. таблицу 17).

9.2 Состав и описание подзаписей сервиса EGTS_EUROPROTOCOL_SERVICE

9.2.1 Список обязательных подзаписей сервиса режима определения, регистрации и передачи информации об обстоятельствах ДТП приведен в таблице 53.

Таблица 53 — Список подзаписей сервиса определения, регистрации и передачи информации об обстоятельствах ДТП

65

ГОСТ 33465—2023

Окончание таблицы 53

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

66

ГОСТ 33465—2023

Описание полей:

FV — версия формата данных (поле должно содержать значение 1);

B# — младшие 8 бит порядкового номера блока;

В#Н — старшие 2 бита порядкового номера блока;

Примечания

1 Каждый отдельный фрагмент массива данных (блок) при работе УСВ в режиме определения, регистрации и передачи информации об обстоятельствах ДТП имеет уникальный номер в пределах от 0 до 1023. Номер выделяется УСВ в цикле.

2 Если должна быть обеспечена некорректируемость информации, передаваемой УСВ в режиме определения, регистрации и передачи информации об обстоятельствах ДТП блока с использованием кода аутентификации в соответствии с требованиями ГОСТ 33464, то в подзаписи EGTS_SR_EP_SIGNATURE в структуре, содержащей код аутентификации, передается аналогичный номер блока, указывая, какому блоку информации соответствует данный код аутентификации.

EVID — уникальный идентификатор данного события определения, регистрации и передачи информации об обстоятельствах ДТП (поле должно содержать значение начиная с 1 и увеличиваться на 1 при каждом новом автоматически или вручную фиксируемом событии ДТП);

CN — битовое поле флагов управления опциональными полями (зарезервировано для дальнейшего использования);

LBSN, LOCP, CLT, ACT, АСР, 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, то автоматических событий в пределах установленного периода времени не зафиксировано;

АСР (Acceleration Data Present) — битовый признак отражения в сообщении факта передачи с данным событием ДТП информации о профиле ускорения:

1 —данные о профиле ускорения передаются (стандартное значение),

0 — данные о профиле ускорения передаются;

TRP (Track Data Present) — битовый признак отражения в сообщении факта передачи с данным событием ДТП информации о траектории движения ТС:

1 —данные о траектории движения ТС передаются (стандартное значение),

0 — данные не передаются;

RWP (Raw Data Present) — битовый признак отражения в сообщении факта передачи с данным событием ДТП первичных навигационных данных:

1 — первичные навигационные данные передаются,

0 — не передаются (стандартное значение);

TRS (Track Data Signing) — битовый признак, отражающий факт обеспечения некорректируемости информации с использованием кода аутентификации в блоке данных о траектории движения ТС:

0 — при передаче для блока данных о траектории движения ТС код аутентификации не вычисляется,

1 — при передаче для блока данных о траектории движения ТС код аутентификации вычисляется, т.е. данные передаются в некорректируемом виде.

67

ГОСТ 33465—2023

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 OxFFFFFFFF и взята целая часть;

LAHS (Latitude Hemisphere Sign) — битовый флаг определяет полушарие широты:

0 — северная широта,

1 — южная широта.

LONG — долгота по модулю, градусы, (WGS 84)/180 OxFFFFFFFF и взята целая часть;

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).

68

ГОСТ 33465—2023

Сформированный состав идентификаторов применяется для подтверждения одного или более автоматически зафиксированных при ДТП ударов перед ручной активацией УСВ. Состав идентификаторов показывает, по каким именно ДТП массивы данных подтверждаются и должны быть сгружены на сервер.

Массивы данных об автоматически зафиксированных ДТП должны быть отправлены УСВ на сервер до того, как начнется отправка события, сгенерированного при ручной активации УСВ.

Таблица 55 — Формат структуры данных отдельной структуры BSD сервиса EGTS_EUROPROTOCOL_SERVICE

Описание полей:

NID — идентификатор базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент. Используются 20 младших бит (MCC+MNC);

LAC — идентификатор локальной зоны базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент;

CID — идентификатор ячейки базовой станции сети ПРТС, наблюдаемой УСВ на текущий момент;

SS — модуль уровня силы сигнала данной базовой станции сети подвижной радиотелефонной связи, выраженный в дБм. Например, значение «80» соответствует уровню сигнала «минус 80 дБм».

В момент фиксации события ДТП УСВ формирует буфер для информации подзаписи EGTS_SR_ EP_MAIN_DATA, выделяет данному событию очередной номер, если необходимо, определяет параметры наблюдаемых базовых станций сети ПРТС, помещает эту информацию в буфер, присваивает полученному массиву информации очередной номер В#, заполняет им поля B# и В#Н и передает данный буфер на определение кода идентификации, дожидается получения кода аутентификации и сохраняет его вместе сданными буфера, осуществляет последующую отправку данных буфера, выполнив обрамление заголовочными данными уровня поддержки услуг транспортного уровня 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

Описание полей:

B# — младшие 8 бит порядкового номера блока с кодом аутентификации для проверки его не-корректируемости;

RSA— число передаваемых структур RTDS изменения траектории движения ТС;

АТ — момент времени (с точностью до 1 с) определения начальной точки траектории для структуры TDS данной подзаписи (число секунд с 00:00:00 01.01.2010 UTC);

69

ГОСТ 33465—2023

RTU (Relative Time Units) — выбор единиц определения относительного смещения времени в структурах TDS:

0 — в секундах (стандартное значение),

1 — в десятых долях секунды с дискретностью 0,1 с;

В#Н — старшие 2 бита порядкового номера блока, с кодом аутентификации для проверки его не-корректируемости;

CS (Coordinate System) — признак системы координат, в которых представлены координаты точек траектории данной подзаписи:

0 — WGS-84,

1 — ПЗ-90.11;

TS — в дополнение к полю АТ устанавливает смещение момента определения начальной точки траектории движения ТС структуры TDS. Смещение задается в единицах, установленных полем RTU;

TDS — структура данных, содержащая параметры начальной точки траектории движения ТС, передаваемой в данной подзаписи. Формат структуры представлен в таблице 57;

RTDS1, ..., RTDS255 (Relative Track Data Structure) — структуры, представляющие изменения траектории движения ТС от точки к точке. Форматы этих структур приведены в таблицах 58 и 59.

Таблица 57 — Формат структуры данных отдельной точки траектории движения ТС подзаписи EGTS_SR_EP TRACK_DATA сервиса EGTS_EUROPROTOCOL_SERVICE

Описание полей:

TDE (Track Data Exists) — битовый флаг:

0 — на момент определения координатно-временных параметров первой точки траектории, связанный со временем данной подзаписи, УСВ не удалось получить корректное навигационное решение (координаты и скорость ТС определены с неудовлетворительной точностью или координаты недопустимы). В этом случае все остальные поля структуры не имеют смысла и не передаются;

1 — имеется корректное навигационное решение, все поля структуры обязательны к передаче;

LOHS — битовый флаг, определяет полушарие долготы:

0 — восточная долгота,

1 — западная долгота;

LAHS — битовый флаг, определяет полушарие широты:

0 — северная широта,

1 — южная широта;

LAT — широта по модулю, градусы, (WGS 84)/90 0xFFFFFFFF и взята целая часть;

LONG — долгота по модулю, градусы, (WGS 84)/180 0xFFFFFFFF и взята целая часть;

SPDL, SPDH — младшие 8 (SPDL) и старшие 5 (SPDH) биты параметра скорости движения ТС (всего 13 бит). Измеряется в км/ч с дискретностью 0,1 км/ч;

ALTL, ALTH — младшие 8 бит и старшие 6 бит модуля значения высоты над уровнем моря, м;

ALTS (Altitude Sign) — признак знака значения высоты над уровнем моря:

0 — положительная высота,

1 — отрицательная высота.

DIRH (Direction Low bits) — старший бит (8) параметра DIR;

70

ГОСТ 33465—2023

DIRL — направление, выраженное в градусах относительно севера, отсчитываемое по часовой стрелке (дополнительно старший бит находится в поле DIRH). Значение параметра направления должно быть в пределах от 0° до 359°.

Таблица 58 — Формат структуры RTDS данных точки изменения траектории движения ТС от точки к точке подзаписи EGTS_SR_EP_TRACK_DATA сервиса EGTS_EUROPROTOCOL_SERVICE при неизменном навигационном решении

Описание полей:

RST (Relative Track Data Structure Type) — тип структуры данных изменения траектории движения ТС. Для структуры, описанной в таблице 9, значение равно 0;

TMS — приращение ко времени определения предыдущей структуры RTDS (для первой записи RTDS приращение к полю АТ), указанное в единицах, установленных полем RTU. Максимальный диапазон приращения равен 63 интервалам, установленным полем RTU;

TDV (Track Data Valid) — битовый флаг, показывающий корректность или некорректность навигационного решения в течение периода TMS:

1 — навигационное решение корректно,

0 — навигационное решение некорректно.

Структуры данного типа передаются, когда состояние и параметры навигационного решения не меняются и совпадают с информацией в предыдущей структуре RTDS или TDS (навигационное решение может быть корректным или нет).

Если навигационное решение не изменяется после 63 интервалов, установленных полем RTU (ТС стоит с включенным зажиганием или по каким-то причинам долго не удается получить корректное навигационное решение), то необходимо формировать последовательно, друг за другом, несколько таких структур.

Структуру данного типа (или несколько таких структур подряд) следует формировать в том случае, если корректное навигационное решение было получено, а затем пропало. Все время от момента потери навигационного решения до момента его восстановления следует перекрыть структурами данного типа с установленным в 0 полем TDV.

Если навигационное решение было некорректным, а затем было получено корректное решение, то следует закончить формировать данную подзапись и начать формировать новую, в которой необходимо указать в поле АТ момент времени восстановления навигационного решения и привести структуру TDS, заполненную параметрами навигационного решения.

Рекомендуется очередную подзапись включать в тот же пакет EGTS.

Таблица 59 — Формат структуры RTDS данных точки определения траектории движения ТС от точки к точке подзаписи EGTS_SR_EP_TRACK_DATA сервиса EGTS_EUROPROTOCOL_SERVICE при определении навигационного решения

71

ГОСТ 33465—2023

Описание полей:

RST (Relative Ttrack Data Structure Type) — тип структуры данных для передачи изменений параметров движения и точек траектории движения ТС. Для структуры, описанной в таблице 10, равно 1;

TMS (Time Shift) — приращение ко времени определения предыдущей структуры RTDS (для первой записи RTDS приращение к полю АТ), указанное в единицах, установленных полем RTU. Максимальный диапазон приращения равен семи интервалам, установленным полем RTU. Если навигационное решение остается неизменным в течение более длительного периода, то следует применить структуру, описанную в таблице 57;

LATDL, LATDH — младшие 8 бит и старшие 6 бит изменения широты соответственно (изменение WGS 84 в градусах)/90-OxFFFFFFFF и взята целая часть по модулю. Изменения вычисляются относительно значений, зафиксированных на момент передачи предыдущей структуры 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. Такие подзаписи должны следовать в пакете непосредственно друг за другом. Первая из них должна ссылаться на последний момент времени, когда зажигание ТС еще было включено, вторая — на момент времени, когда зажигание снова включили.

72

ГОСТ 33465—2023

Если в пределах семи промежутков времени обнаружено изменение в навигационном решении, превышающее максимальный диапазон значений любого из полей, то следует передать структуру, приведенную в таблице 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# и В#Н в начале подзаписи 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