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

(введен в действие Приказом Росстандарта от 18.10.2023 № 1183-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р 54619-2011"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-54619-2011" "ГОСТ Р 54619-2011. Национальный стандарт Российской Федерации. Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протоколы обмена данными."
  n1["ГОСТ 33465-2015"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-33465-2015" "ГОСТ 33465-2015. Межгосударственный стандарт. Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протокол обмена данными устройства/системы"
  n2["ГОСТ 33465-2023"]:::notEnt
  click n2 "https://bukva.ai/docs/protokol-gost-33465-2023" "ГОСТ 33465-2023. Межгосударственный стандарт. Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протоколы обмена данными устройства/систем"
  n1 --> n2
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

emergency call device/system and emergency response

Дата введения 1 июня 2024 года с правом досрочного применения

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 Термины и определения

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

[ГОСТ 34.12-2018, пункт 2.1.8]

[ГОСТ 33464-2023, пункт 3.1.12]

[ГОСТ 33464-2023, пункт 3.1.14]

[ГОСТ 33464-2023, пункт 3.1.17]

[ГОСТ 33464-2023, пункт 3.1.18]

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

3.1.7 протокол уровня приложений IPv4: Протокол верхнего (4-го) уровня сетевой модели TCP/IP.

[ГОСТ 33464-2023, пункт 3.1.22]

3.1.9 сервис: Элемент инфраструктуры телематической платформы, обеспечивающий функциональное выполнение алгоритма той или иной услуги, оказываемой системой.

[ГОСТ 33464-2023, пункт 3.1.23]

[ГОСТ 33464-2023, пункт 3.1.24]

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

[ГОСТ 33464-2023, пункт 3.1.27]

[ГОСТ 33464-2023, пункт 3.1.28]

3.1.15 телематическая платформа; ТП: Техническое решение, которое взаимодействует с телематическими устройствами и другими телематическими платформами в части приема и передачи телематических данных, а также занимается их обработкой.

3.1.16 телематическое устройство; ТУ: Бортовое навигационно-коммуникационное устройство, позволяющее осуществлять экстренные вызовы, отправлять телематическую информацию или информацию о параметрах вождения ТС, а также принимать соответствующую информацию от телематических платформ.

[ГОСТ 33464-2023, пункт 3.1.31]

3.2 Сокращения и обозначения

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

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

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

АС — автомобильная система;

ГЛОНАСС — глобальная навигационная спутниковая система Российской Федерации;

ДТП — дорожно-транспортное происшествие;

ДУЖ — датчик уровня жидкости;

ОГРН — основной государственный регистрационный номер;

ПЗ-90.11 — система геодезических параметров «Параметры Земли 1990 года», используемая в ГНСС «ГЛОНАСС»;

ПО — программное обеспечение;

ППУ — протокол уровня поддержки услуг;

ПТУ — протокол транспортного уровня;

ПРТС — подвижная радиотелефонная связь;

СПРС — соединение ПРТС с помощью всех доступных для УСВ стандартов связи GSM/GPRS/UMTS/HSDPA/LTE и поколений 2G/3G/4G и пр.;

ТП — телематическая платформа;

ТС — транспортное средство;

УСВ — устройство/система вызова экстренных оперативных служб;

Цифровая подпись — информация в электронной форме, которая используется для идентификации отправителя данных;

AL ACK — подтверждение уровня приложения;

ASN.1 — абстрактная синтаксическая нотация один;

BeiDou — глобальная навигационная спутниковая система Китайской Народной Республики;

CP-1251 — набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows;

CRC-8(16) — циклический избыточный код;

DNS — система доменных имен;

eCall — общеевропейская система экстренного реагирования при авариях;

EGTS — телематический стандарт для системы экстренного реагирования при авариях;

FTP — протокол передачи файлов;

IP — межсетевой протокол;

Galileo — глобальная навигационная спутниковая система Европейского союза;

GPRS — пакетная радиосвязь общего пользования;

GPS — глобальная навигационная спутниковая система Соединенных Штатов Америки;

GSM — глобальный цифровой стандарт для мобильной сотовой связи;

HTTP — протокол передачи гипертекста;

IMAP — протокол прикладного уровня для доступа к электронной почте;

ISDN — цифровая сеть с интеграцией обслуживания;

Little-endian — младший байт вперед (порядок следования байтов);

NGTP — телематический протокол следующего поколения. Архитектура и концепция построения;

OSI — базовая эталонная модель взаимодействия открытых систем — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов;

SC — сервис-центр, ответственный за обработку, хранение и передачу SMS-сообщений получателям;

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 Протокол транспортного уровня

5.1 Назначение протокола транспортного уровня

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

5.1.2 Описание принципа построения системы на основе протокола транспортного уровня приведено в приложении А.

5.1.3 Анализ протокола транспортного уровня на основе концепции NGTP приведен в приложении Б.

5.2 Обеспечение маршрутизации

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

5.3 Механизм проверки целостности данных

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

В целях обеспечения минимизации использования системных ресурсов при обработке пакетов протокола в части транспортного уровня и данных уровня поддержки услуг используются различные поля и алгоритмы обеспечения контроля целостности. При этом используется механизм, основанный на подсчете контрольной суммы, передаваемой последовательности байтов (CRC).

5.4 Обеспечение надежности доставки пакетов данных

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

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

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

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

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

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

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

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

5.6.2 Структуры данных в зависимости от типа пакета

5.6.2.1 Структура данных пакета EGTS_PT_APPDATA

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.

Таблица 7

5.6.2.4 На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA, поступающий от УСВ на ТП или от нее на УСВ, должен быть отправлен пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA. На рисунке 3 представлена последовательность обмена пакетами при взаимодействии УСВ и ТП.

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

5.7.1.2 Описание параметров, входящих в состав SMS-сообщения в PDU-режиме, приведено ниже:

• SMSC_AL — длина полезных данных адреса SMSC в октетах;

• TON (Type Of Number) — тип номера. Параметр TON может принимать следующие значения:

а) 000 — неизвестный;

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

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

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

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

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

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

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

• NPI (NumericPlanIdentification) — тип плана нумерации (применимо для значений поля TON-000,001,010). NPI может принимать следующие значения:

а) 0000 — неизвестный;

б) 0001 — план нумерации ISDN телефонии;

в) 0011 — план нумерации при передаче данных;

г) 0100 — телеграф;

д) 1000 — национальный;

е) 1001 — частный;

ж) 1111 — зарезервировано.

Поле опциональное, и наличие его зависит от значения параметра SMSC_AL (если значение SMSC_AL больше 0, то данное поле присутствует);

• SMSC_A — адрес SMSC. Каждая десятичная цифра номера представлена в виде 4 бит (младшие 4 бита — цифра более старшего разряда, старшие 4 бита — цифра меньшего разряда), при этом если число цифр в номере нечетное, то в битах с 4 по 7 последнего байта номера устанавливается значение 0xF (1111b). Данный параметр опциональный, и его наличие зависит от значения параметра SMSC_AL. В случае отсутствия параметра SMSC_A используется SMSC из SIM-карты;
• TP_MTI — (Message Type Indicator) тип сообщения (должен содержать бинарное значение 01);
• TP_RD — (Reject Duplicates) поле определяет, необходимо ли SMSC принимать данное сообщение на обработку, если существует предыдущее необработанное отправленное с данного номера сообщение, которое имеет такое же значение поля TP_MR и такой же номер получателя в поле TP_DA;
• TP_VPF — (Validity Period Format) формат параметра TP_VP. Возможные значения поля TP_VPF представлены в таблице 10;

Таблица 10

Формат поля TP_VP в зависимости от значения поля TP_VPF

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

• 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-битной кодировки;

характеризующего часть конкатенируемого SMS-сообщения

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

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

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

На подзапись EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE, содержащую команду или сообщение, требуется подтверждающая подзапись EGTS_SR_COMMAND_DATA с соответствующим значением полей CT (CommandType) и CCT (CommandConfirmationType). В случае отправки команды на УСВ через SMS соответствующий пакет EGTS, содержащий подтверждение о приеме команды в виде подзаписи EGTS_SR_COMMAND_DATA, должен быть передан с УСВ через SMS.

5.7.2.2 Для отправки SMS, содержащего «цифровую подпись», используется пакет транспортного уровня типа EGTS_PT_SIGNED_APPDATA.

5.7.2.3 В случае, если размер пакета данных протокола превышает 140 байт, используется механизм конкатенации SMS-сообщений (см. [6], (9.2.3.24.1)). Суть данного механизма состоит в том, что передаваемые пользовательские данные разбиваются на части и отправляются отдельными SMS-сообщениями. При этом каждое такое сообщение содержит специальную структуру, определяющую общее число частей передаваемых данных и порядок их сборки на принимающей стороне. В качестве такой структуры используется поле TP_UD_HEADER, которое содержит информационный элемент, характеризующий часть конкатенируемого SMS-сообщения. Таким образом, исходя из размера заголовка данных пользователя и максимального числа частей длинного сообщения, равного 255, максимально возможный размер пакета при использовании 8-битной кодировки может составлять 255(140 — 6) = 34170 байт.

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

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

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

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.

6.1 Назначение протокола уровня поддержки услуг

6.1.2 ППУ выполняет следующие основные функции:

6.1.3 Настоящий стандарт содержит описание ППУ (протокола EGTS) версии «02», являющегося развитием предыдущей версии ППУ, версии «01».

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

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

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

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

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

1 Для обеспечения управления выбором протокола при взаимодействии устройств и систем применяются специализированные команды и параметры УСВ, описанные в 6.7.3.2 (таблицы 35, 36, 37).

2 Для обеспечения совместимости необходима реализация и выполнение следующих процедур:

а) для УСВ, поддерживающих протокол версии «02», — задание или отправка на УСВ конфигурационных команд с указанием адреса ТП одновременно с указанием версии протокола, поддерживаемого данной ТП;

б) для УСВ, поддерживающих протокол версии «02», — отправка на УСВ конфигурационных команд, указывающих приоритет выбора версии протокола при взаимодействии с конкретными ТП;

в) для УСВ, поддерживающих протокол версии «02», — отправка конфигурационных команд, указывающих приоритет выбора версии протокола при взаимодействии со всеми ТП;

г) для ТП, поддерживающей протокол версии «02», — отправка на УСВ подтверждений с указанием поддерживаемой версии протокола «02» при авторизации УСВ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• RL — параметр определяет размер данных из поля RD;
• RN — номер записи. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535 следующее значение должно быть 0. Значение из данного поля используется для подтверждения записи;
• RFL — содержит битовые флаги, определяющие наличие в данном пакете полей OID, EVID и TM, характеризующих содержащиеся в записи данные;
• SSOD (Source Service On Device) — битовый флаг, определяющий расположение сервиса-отправителя:

а) 1 — сервис-отправитель расположен на стороне УСВ,

б) 0 — сервис-отправитель расположен на ТП;

• RSOD (Recipient Service On Device) — битовый флаг, определяющий расположение сервиса-получателя:

а) 1 — сервис-получатель расположен на стороне УСВ,

б) 0 — сервис-получатель расположен на ТП;

• RPP (Record Processing Priority) — битовое поле, определяющее приоритет обработки данной записи сервисом. Поле принимает десятичные значения от 0 (наивысший приоритет) до 7 (самый низкий приоритет);
• TMFE (Time Field Exists) — битовое поле, определяющее наличие в данном пакете поля TM:

а) 1 — поле TM присутствует,

б) 0 — поле TM отсутствует;

• EVFE (Event ID Field Exists) — битовое поле, определяющее наличие в данном пакете поля EVID:

а) 1 — поле EVID присутствует,

б) 0 — поле EVID отсутствует;

• TM — время формирования записи на стороне отправителя (секунды с 00:00:00 01.01.2010 UTC). Если в одном пакете транспортного уровня передаются несколько записей, относящихся к одному объекту и моменту времени, то поле метки времени TM может передаваться только в составе первой записи;
• SST — идентификатор типа сервиса-отправителя, сгенерировавшего данную запись. Например, сервис, обрабатывающий навигационные данные на стороне УСВ, сервис команд на стороне ТП и т.д.;
• RST — идентификатор тип сервиса-получателя данной записи. Например, сервис, обрабатывающий навигационные данные на стороне ТП, сервис обработки команд на стороне УСВ и т.д.;
• RD — поле, содержащее информацию, присущую определенному типу сервиса (одну или несколько подзаписей сервиса типа, указанного в поле SST или RST, в зависимости от вида передаваемой информации).

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

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

Таблица 16

Формат отдельной подзаписи ППУ

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

6.7.2 Сервис EGTS_AUTH_SERVICE

6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE

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

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

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

6.7.2.2 Подзапись EGTS_SR_TERM_IDENTITY

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

Таблица 20

Формат подзаписи EGTS_SR_TERM_IDENTITY сервиса EGTS_AUTH_SERVICE

• TID — уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных АС (IMSI, IMEI, serial_id). В случае использования УСВ в качестве штатного устройства TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);
• HDIDE (Home Dispatcher Identifier Enable) — битовый флаг, который определяет наличие поля HDID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• IMEIE (International Mobile Equipment Identity Enable) — битовый флаг, который определяет наличие поля IMEI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• IMSIE (International Mobile Subscriber Identity Enable) — битовый флаг, который определяет наличие поля IMSI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• LNGCE (Language Code Enable) — битовый флаг, который определяет наличие поля LNGC в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• SSRA — битовый флаг предназначен для определения алгоритма использования сервисов (если бит равен 1, то используется «простой» алгоритм, если 0, то алгоритм «запросов» на использование сервисов);
• NIDE (Network Identifier Enable) — битовый флаг определяет наличие поля NID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• BSE (Buffer Size Enable) — битовый флаг, определяющий наличие поля BS в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• MNE (Mobile Number Enable) — битовый флаг, определяющий наличие поля MSISDN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• HDID — идентификатор «домашней» ТП (подробная учетная информация об УСВ хранится на данной платформе);
• IMEI — идентификатор мобильного устройства (модема). При невозможности определения данного параметра УСВ должна заполнять данное поле значением 0 во всех 15 символах;
• IMSI — идентификатор мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 16 символах;
• LNGC — код языка, предпочтительного к использованию на стороне УСВ, например «rus» — русский;
• NID — идентификатор сети оператора, в которой зарегистрирована УСВ. Используются 20 младших бит. Представляет пару кодов MCC-MNC. Структура поля NID представлена в таблице 21;
• BS — максимальный размер буфера приема УСВ в байтах. Размер каждого пакета информации, передаваемого на УСВ, не должен превышать данного значения. Значение поля BS может принимать различные значения (1024, 2048, 4096) и зависит от реализации аппаратной и программной частей конкретной УСВ;
• MSISDN — телефонный номер мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 15 символах (формат описан в национальных планах нумерации, утверждаемых соответствующими нормативными правовыми актами <1>).

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

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

Таблица 21

сервиса EGTS_AUTH_SERVICE

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

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

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

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

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

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

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

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

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

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

6.7.2.3 Подзапись EGTS_SR_MODULE_DATA

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

Таблица 22

Формат подзаписи EGTS_SR_MODULE_DATA сервиса EGTS_AUTH_SERVICE

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

• MT — тип модуля, определяет функциональную принадлежность модуля (1 — основной модуль; 2 — модуль ввода вывода; 3 — модуль навигационного приемника; 4 — модуль беспроводной связи). Здесь указаны рекомендованные правила нумерации типов модулей. Конкретная реализация сервиса авторизации может вводить и расширять собственную нумерацию типов, включая все внешние периферийные контроллеры;
• VID — код производителя;
• FWV — версия аппаратной части модуля (старший байт — число до точки — major version, младший — после точки — minor version, например версия 2.34 будет представлена числом 0x0222);
• SWV — версия программной части модуля (старший байт — число до точки, младший — после точки);

• ST — состояние [1 — включен, 0 — выключен, больше 127 — неисправность (см. приложение В)];

6.7.2.4 Подзапись EGTS_SR_VEHICLE_DATA

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

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

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

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

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

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

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

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

8 — мотоцикл (L2e),

9 — мотоцикл (L3e),

10 — мотоцикл (L4e),

11 — мотоцикл (L5e),

12 — мотоцикл (L6e),

13 — мотоцикл (L7e),

20 — маломерное судно некоммерческого использования,

21 — маломерное судно коммерческого использования,

• VPST — тип энергоносителя ТС. Может быть установлено более одного бита, если установлены носители нескольких типов. Если все биты 0, то тип не задан:

а) бит 31-6 не используется,

ж) бит 0:1 — бензин.

6.7.2.5 Подзапись EGTS_SR_AUTH_PARAMS

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

Таблица 24

сервиса EGTS_AUTH_SERVICE

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

• EXE (Exp Enable) — битовый флаг, определяет наличие поля EXP и следующего за ним разделителя D (если 1, то поля присутствуют);
• SSE (Server Sequence Enable) — битовый флаг, определяет наличие поля SS и следующего за ним разделителя D (если 1, то поля присутствуют);
• MSE (Mod Size Enable) — битовый флаг, определяет наличие поля MSZ (если 1, то поле присутствует);
• ISLE (Identity String Length Enable) — битовый флаг, определяет наличие поля ISL (если 1, то поле присутствует);
• PKE (Public Key Enable) — битовый флаг, определяет наличие полей PKL и PBK (если 1, то поля присутствуют);
• ENA (Encryption Algorithm) — битовое поле, определяющее требуемый алгоритм шифрования пакетов. Если данное поле содержит значение 00, то шифрование не применяется, и подзапись EGTS_SR_AUTH_PARAMS содержит только один байт, т.е. в зависимости от типа алгоритма наличие дополнительных параметров определяется остальными битами поля FLG;
• PKL — длина публичного ключа в байтах;
• PBK — данные публичного ключа;
• ISL — результирующая длина идентификационных данных;
• MSZ — параметр, применяемый в процессе шифрования;
• SS — специальная серверная последовательность байтов, применяемая в процессе шифрования;
• D — разделитель строковых параметров (всегда имеет значение 0);
• EXP — специальная последовательность, используемая в процессе шифрования.

Если требуется использование шифрования и запрашиваемый алгоритм шифрования поддерживается, авторизуемой стороной производится формирование и отправка записи EGTS_SR_AUTH_INFO, зашифрованной по указанному алгоритму. При этом биты 11 и 12 в поле KEYS заголовка транспортного уровня устанавливаются в соответствующие значения, и весь последующий обмен данными производится с использованием шифрования.

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

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

6.7.2.6 Подзапись EGTS_SR_AUTH_INFO

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

Таблица 25

Структура подзаписи EGTS_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

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

• ST — тип сервиса, определяет функциональную принадлежность (например, EGTS_TELEDATA_SERVICE, EGTS_ECALL_SERVICE и т.д.);
• SST — определяет текущее состояние сервиса (см. таблицу 27);
• SRVP — определяет параметры сервиса;
• SRVA (Service Attribute) — битовый флаг, атрибут сервиса:

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

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

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

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

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

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

г) 11 — низкий.

Таблица 27

Список возможных состояний сервиса

6.7.2.8 Подзапись EGTS_SR_RESULT_CODE

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

Таблица 28

Структура подзаписи EGTS_SR_RESULT_CODE сервиса EGTS_AUTH_SERVICE

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

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

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

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

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

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

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

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

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

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

• IPv4 адрес и порт для установки TCP/IP-соединения;
• вариант процедуры выбора версии протокола обмена данными:

0 — выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола («01») заканчивая старшей версией протокола («02») согласно процедурам и принципам, описанным в 6.1.3,

1 — УСВ использует для обмена данными с указанной ТП версию протокола «01»,

2 — УСВ использует для обмена данными с указанной ТП версию протокола «02». Далее УСВ производит разбор SMS-сообщения, проверяет корректность структур данных, вычисляет и сравнивает с полученными в сообщении значениями контрольные суммы. Если разбор и проверка прошли успешно, УСВ устанавливает СПРС-сессию и соединяется с указанным сервером по TCP/IP. Алгоритм такого способа конфигурирования УСВ представлен на рисунке 8.

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

Алгоритм конфигурирования для УСВ, работающих по протоколу версии «02» с дополнительными параметрами выбора версии протокола, представлен на рисунке 9.

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

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

2. После регистрации УСВ в сети GSM или UMTS устанавливаются СПРС-сессия и TCP/IP-соединение с сервером, информация об адресе которого уже записана в памяти УСВ. При прохождении процедуры аутентификации инфраструктура оператора анализирует параметр TID из подзаписи EGTS_SR_TERM_IDENTITY (таблица 18). Если TID имеет значение 0, производится процедура конфигурирования путем установки параметров УСВ при помощи подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE с использованием SMS, как описано в предыдущем способе. После процедуры установки параметра УСВ EGTS_UNIT_ID ей отправляется результат авторизации с кодом EGTS_PC_ID_NFOUND, указывающий, что TID=0 в системе не найден. После этого сервер, не разрывая соединения с УСВ, ожидает повторной авторизации УСВ, но уже с корректным параметром TID. Алгоритм такого способа конфигурирования УСВ представлен на рисунке 10.

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

Получив сообщение с подзаписью EGTS_SR_TERM_IDENTITY, ТП отправляет на него сообщение 2 с подтверждением о приеме EGTS_SR_RECORD_RESPONSE на запись с идентификатором ID, равным 1. Далее в зависимости от настроек (используется шифрование или дополнительный алгоритм авторизации) ТП отправляет пакет (сообщение 3) с подзаписью EGTS_SR_AUTH_PARAM, содержащей параметры, необходимые для осуществления шифрования и/или алгоритма расширенной авторизации. Если шифрование и алгоритм расширенной авторизации не используются, то вместо подзаписи EGTS_SR_AUTH_PARAM ТП может отправить подзапись EGTS_SR_RESULT_CODE с результатом проведения процедуры авторизации УСВ.

Далее УСВ отправляет сообщение 4 и подтверждение EGTS_SR_RECORD_RESPONSE на сообщение 3 с ID, равным 2. При использовании расширенного алгоритма авторизации и/или шифрования УСВ передает сообщение 5, закодированное по правилам шифрования, указанным в сообщении 3 от ТП и содержащее подзапись EGTS_SR_AUTH_INFO с данными для расширенной авторизации.

После получения EGTS_SR_AUTH_INFO ТП отправляет сообщение 6 с подтверждением на сообщение 5 с ID, равным 3, и выполняет процедуру авторизации. Платформа формирует сообщение 7 с результатом проведения авторизации в виде подзаписи EGTS_SR_RESULT_CODE, а также в случае успешной авторизации может добавить информацию о разрешенных для использования данной УСВ-услуги в виде подзаписей EGTS_SR_SERVICE_INFO.

УСВ затем формирует сообщение 8 с подтверждением на сообщение 7 с ID, равным 4. УСВ может сформировать сообщение 9 и добавить подзаписи EGTS_SR_SERVICE_INFO, содержащие информацию о требуемых услугах (если используется процедура использования сервисов «по запросу») и/или поддерживаемых сервисах на стороне УСВ.

Далее ТП создает сообщение 10 с подтверждением на сообщение 9 с ID, равным 5.

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

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

Процедура выбора версии протокола для обмена данными на этапе авторизации УСВ на ТП приведена в 6.1.3.

6.7.2.10 Описание процедуры авторизации (при использовании функций мониторинга ТС)

6.7.2.11 Подзапись EGTS_SR_DISPATCHER_IDENTITY

Формат подзаписи EGTS_SR_DISPATCHER_IDENTITY сервиса EGTS_AUTH_SERVICE представлен в таблице 29.

• TID — уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных АС (IMSI, IMEI, serial_id). В случае использования УСВ в качестве штатного устройства TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);
• SSLPV — номер версии ППУ авторизуемого УСВ (номер версии протокола EGTS). Версия ППУ (номер версии протокола EGTS) состоит из двух символов, левый символ «0» для версий от 1 до 9, «01» ... «09» соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.

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

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

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

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

6.7.2.12 Подзапись EGTS_SR_VEHICLE_DATA_ADD

• 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 — ИНН собственника ТС;

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

6.7.3 Сервис EGTS_COMMANDS_SERVICE

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

Таблица 31

Описание подзаписей сервиса EGTS_COMMANDS_SERVICE

6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA

г) 0100 — CT_MSGTO — информационное сообщение для вывода на устройство отображения ТС,

д) 0101 — CT_COM — команда для выполнения на ТС,

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

ж) 0111 — CT_SUBREQ — дополнительный подзапрос для выполнения (к переданной ранее команде),

и) 1000 — CT_DELIV — подтверждение о доставке команды или информационного сообщения;

• CCT — тип подтверждения (имеет смысл для типов команд CT_COMCONF, CT_MSGCONF, CT_DELIV):

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

б) 0001 — CC_ERROR — обработка завершилась ошибкой,

в) 0010 — CC_ILL — команда не может быть выполнена по причине отсутствия в списке разрешенных (определенных протоколом) команд или отсутствия разрешения на выполнение данной команды,

г) 0011 — CC_DEL — команда успешно удалена,

д) 0100 — CC_NFOUND — команда для удаления не найдена,

е) 0101 — CC_NCONF — успешное выполнение, отрицательный ответ,

ж) 0110 — CC_INPROG — команда передана на обработку, но для ее выполнения требуется длительное время (результат выполнения еще не известен);

• CID — идентификатор команды, сообщения. Значение из данного поля должно быть использовано стороной, обрабатывающей/выполняющей команду или сообщение, для создания подтверждения. Подтверждение должно содержать в поле CID то же значение, что содержалось в самой команде или сообщении при отправке;
• SID — идентификатор отправителя данной команды или подтверждения. В случае передачи от УСВ на ТП подтверждения на команду или результат выполнения команды (тип команды CT_COMCONF, CT_MSGCONF, CT_DELIV) необходимо копировать значение данного поля из ранее пришедшей на УСВ команды. При инициации отправки подзаписи EGTS_SR_COMMAND_DATA на стороне УСВ данное поле имеет значение 0;
• ACFE (Authorization Code Field Exists) — битовый флаг, определяющий наличие полей ACL и AC в подзаписи:

а) 1 — поля ACL и AC присутствуют в подзаписи,

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

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

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

• ADR — адрес модуля, для которого данная команда предназначена. Адрес определяется исходя из начальной конфигурации УСВ или из списка модулей, который может быть получен при регистрации УСВ через сервис EGTS_AUTH_SERVICE и передачи подзаписей EGTS_SR_MODULE_DATA;
• SZ — объем памяти для параметра (используется совместно с действием ACT-2). При добавлении нового параметра в УСВ данное поле определяет, что для нового параметра требуется 2SZ байт памяти в УСВ;
• ACT — описание действия, используется в случае типа команды, поле CT-CT_COM подзаписи EGTS_SR_COMMAND_DATA. Значение поля может быть одним из следующих вариантов:

а) 0 — параметры команды. Используется для передачи параметров для команды, определяемой кодом из поля CCD,

б) 1 — запрос значения. Используется для запроса информации, хранящейся в УСВ. Запрашиваемый параметр определяется кодом из поля CCD,

в) 2 — установка значения. Используется для установки нового значения определенному параметру в УСВ. Устанавливаемый параметр определяется кодом из поля CCD, а его значение — полем DT,

г) 3 — добавление нового параметра в УСВ. Код нового параметра указывается в поле CCD, его тип — в поле SZ, а значение — в поле DT,

д) 4 — удаление имеющегося параметра из УСВ. Код удаляемого параметра указывается в поле CCD;

• DT — запрашиваемые данные или параметры, необходимые для выполнения команды. Данные записываются в данное поле в формате, зависящем от типа команды. Подтверждение на ранее переданную команду при CT-CT_COMCONF, если с УСВ передается сопутствующая информация, имеет формат, представленный в таблице 34. Описанная структура содержится в поле CD.

Формат подтверждения на команду УСВ

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

Таблица 36

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

Таблица 37

Список параметров УСВ

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

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

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

• OA — характеристика принадлежности передаваемой сущности;
• OT — тип сущности по содержанию. Определены следующие значения данного поля:

а) 00 — данные внутреннего программного обеспечения («прошивка»),

б) 01 — блок конфигурационных параметров;

• MT — тип модуля, для которого предназначена передаваемая сущность. Определены следующие значения данного поля:

а) 00 — периферийное оборудование,

б) 01 — УСВ.

• CMI — номер компонента в случае принадлежности сущности непосредственно УСВ или идентификатор периферийного модуля/порта, подключенного к УСВ, в зависимости от значения параметра MT;
• VER — версия передаваемой сущности (старший байт — число до точки major version, младший — после точки minor version, например версия 2.34 будет представлена числом 0x0222);
• WOS — сигнатура (контрольная сумма) всей передаваемой сущности. Используется алгоритм CRC16-CCITT;
• FN — имя файла передаваемой сущности (данное поле опционально и может иметь нулевую длину);
• D — разделитель строковых параметров (всегда имеет значение 0).

6.7.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA

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

Таблица 42

Структура подзаписи EGTS_SR_SERVICE_FULL_DATA сервиса EGTS_FIRMWARE_SERVICE

6.7.4.3 Подзапись EGTS_SR_RECORD_RESPONSE

Данная подзапись имеет такую же структуру, как описано в 6.7.2.1, и применяется для подтверждения получения и обработки подзаписей EGTS_SR_SERVICE_PART_DATA и EGTS_SR_SERVICE_FULL_DATA. При этом на все подзаписи EGTS_SR_SERVICE_PART_DATA, кроме последней, при успешной обработке в составе EGTS_SR_RECORD_RESPONSE должен передаваться код результата, равный EGTS_PC_IN_PROGRESS. На последнюю подзапись EGTS_SR_SERVICE_PART_DATA и каждую EGTS_SR_SERVICE_FULL_DATA при успешном приеме и обработке со стороны УСВ должна передаваться подзапись EGTS_SR_RECORD_RESPONSE, содержащая код EGTS_PC_OK, что будет воспринято сервисом как удачная попытка отправки всей сущности.

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

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

Таблица 43

Временные и количественные параметры протокола уровня поддержки услуг

7.1 Назначение сервиса экстренного реагирования при аварии

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

7.2 Минимально необходимый набор функций УСВ для использования услуги EGTS_ECALL_SERVICE

7.3 Состав и описание подзаписей сервиса EGTS_ECALL_SERVICE

7.3.1 Подзапись EGTS_SR_RECORD_RESPONSE

7.3.2 Подзапись EGTS_SR_ACCEL_DATA

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

• RTM — приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) в миллисекундах (мс);
• XAAV — значение линейного ускорения по оси X; 0,1 м/с2;
• YAAV — значение линейного ускорения по оси Y; 0,1 м/с2;
• ZAAV — значение линейного ускорения по оси Z; 0,1 м/с2. Разрешающая способность полей ускорения должна быть не более 0,1 м/с2 (0,01 g).

7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA

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

Таблица 47

Формат подзаписи EGTS_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.

Таблица 48

Структура подзаписи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE

• SA — число передаваемых точек траектории движения ТС;
• ATM — опорное время проведения измерений (число секунд с 00:00:00 01.01.2010 UTC). Используется в качестве начального времени для первой передаваемой структуры с точностью 1 с. Более точное время измерения определяется с учетом поля RTM-структуры информации об отдельной точке траектории движения;
• TDS1 ... TDS255 — структуры данных, содержащие параметры отдельной точки траектории движения ТС. Формат структуры представлен в таблице 49.

Таблица 49

Формат структуры данных отдельной точки траектории движения ТС подзаписи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE

• RTM — приращение ко времени измерения предыдущей записи (для первой записи приращение к полю ATM) — 0,1 с. Определяет время проведения измерения параметров данной точки траектории. Максимально возможное значение приращения составляет 3,2 с;
• LAT — широта по модулю, градусы (WGS 84)/90·0xFFFFFFFF и взята целая часть;
• LONG — долгота по модулю, градусы (WGS 84)/180·0xFFFFFFFF и взята целая часть;
• SPDL, SPDH — младшие (SPDL) и старшие (SPDH) биты параметра скорости (используется 15 бит). Измеряется в 0,01 км/ч. Максимальное значение скорости, передаваемое в данном поле, составляет 327,67 км/ч;
• DIRH (Direction the Highest bit) — старший бит (8) параметра DIR;
• DIR — направление движения ТС, выраженное в градусах, относительно севера по часовой стрелке (дополнительно старший бит находится в поле DIRH). Значение параметра направления должно быть в пределах от 0 до 359.

7.4 Использование сервиса EGTS_COMMANDS_SERVICE

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

7.5 Список и описание команд, параметров и подтверждений при использовании сервиса EGTS_ECALL_SERVICE

7.5.1 Список и описание команд УСВ и подтверждений, необходимых для реализации базовой услуги, а также список параметров УСВ представлены в таблицах 50 и 51.

Таблица 50

Список команд для УСВ

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_AL_ACK_PERIOD;

• EGTS_ECALL_DIAL_DURATION;

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

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

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

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

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

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

9.2.2 Подзапись EGTS_SR_EP_MAIN_DATA