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

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

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

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;

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

ГЛОБАЛЬНАЯ НАВИГАЦИОННАЯ СПУТНИКОВАЯ СИСТЕМА

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

ПРОТОКОЛ ОБМЕНА ДАННЫМИ УСТРОЙСТВА/СИСТЕМЫ ВЫЗОВА ЭКСТРЕННЫХ ОПЕРАТИВНЫХ СЛУЖБ С ИНФРАСТРУКТУРОЙ СИСТЕМЫ ЭКСТРЕННОГО РЕАГИРОВАНИЯ ПРИ АВАРИЯХ

Global navigation satellite system. Road accident emergency response system. Data exchange protocol between in-vehicle emergency call device/system and emergency response system infrastructure

ГОСТ 33465-2015

Предисловие

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

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

1 РАЗРАБОТАН Некоммерческим партнерством «Содействие развитию и использованию навигационных технологий» и акционерным обществом «Научно-технический центр современных навигационных технологий „Интернавигация“ (АО „НТЦ „Интернавигация“)»

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

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации по результатам голосования (протокол от 12 ноября 2015 г. № 82-П)

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

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

5 Настоящий стандарт подготовлен на основе применения ГОСТ Р 54619-2011 <*>

<*> Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2016 г. № 2035-ст национальный стандарт ГОСТ Р 54619-2011 отменен с 1 июня 2017 г.

6 ВВЕДЕН ВПЕРВЫЕ

Информация об изменениях к настоящему стандарту публикуется в ежегодном информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Настоящий стандарт входит в комплекс стандартов «Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях» и является одним из базовых стандартов комплекса.

Система экстренного реагирования при авариях предназначена для снижения тяжести последствий дорожно-транспортных происшествий и иных происшествий на дорогах посредством уменьшения времени доведения информации об указанных происшествиях до экстренных оперативных служб. В Республике Беларусь система экстренного реагирования при авариях называется «ЭРА-РБ», в Республике Казахстан — «ЭВАК», в Российской Федерации — «ЭРА-ГЛОНАСС». Аналогом указанных систем является разрабатываемая общеевропейская система eCall, с которой вышеуказанные системы гармонизированы по основным функциональным свойствам (использование тонального модема как основного механизма передачи данных; унифицированные состав и формат обязательных данных, передаваемых в составе минимального набора данных о дорожно-транспортном происшествии, единообразные правила установления и завершения двустороннего голосового соединения с лицами, находящимися в кабине транспортного средства и др.).

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

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

Основные положения настоящего стандарта взаимоувязаны с основополагающим стандартом комплекса стандартов «Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях».

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

• по сетевой модели взаимодействия открытых систем — в части используемых протоколов транспортного и сетевого уровня для передачи данных между устройством/системой вызова экстренных оперативных служб и оператором системы;
• по общеевропейской системе безопасности в экстренных ситуациях eCall — в части состава передаваемого устройством/системой вызова экстренных оперативных служб минимального набора данных;
• по мобильной (подвижной связи) — в части передачи данных с использованием SMS-сообщений.

Настоящий стандарт предназначен для использования:

• производителями устройств/систем экстренного реагирования при авариях;
• автопроизводителями;
• оператором системы экстренного реагирования при авариях;
• разработчиками и поставщиками услуг на основе навигационно-информационной платформы системы экстренного реагирования при авариях.

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

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

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

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

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

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

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

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

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

В настоящем стандарте применены термины по ГОСТ 33464, а также следующие термины с соответствующими определениями:

3.1.1 минимальный набор данных; МНД: Набор данных, передаваемый устройством/системой вызова экстренных оперативных служб при дорожно-транспортном происшествии и включающий в себя информацию о координатах и параметрах движения аварийного транспортного средства и времени аварии, VIN-коде транспортного средства и другую информацию, необходимую для экстренного реагирования.

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

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

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

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

Примечание - В Республике Беларусь система экстренного реагирования при авариях называется «ЭРА-РБ», в Республике Казахстан — «ЭВАК», в Российской Федерации — «ЭРА-ГЛОНАСС». Аналогом вышеуказанных систем является разрабатываемая общеевропейская система eCall, с которой эти системы гармонизированы по основным функциональным свойствам (использование тонального модема как основного механизма передачи данных; унифицированные состав и формат обязательных данных, передаваемых в составе минимального набора данных о дорожно-транспортном происшествии, единообразные правила установления и завершения двустороннего голосового соединения с лицами, находящимися в кабине транспортного средства и др.).

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

Примечания

1 Система вызова экстренных оперативных служб позволяет осуществлять передачу сообщения о транспортном средстве при дорожно-транспортном и ином происшествиях также и в ручном режиме.

2 Категории транспортных средств, подлежащих оснащению системами вызова экстренных оперативных служб, установлены в [1].

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

Примечания

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

2 Категории транспортных средств, подлежащих оснащению устройствами вызова экстренных оперативных служб, установлены в [1].

3.2 Сокращения

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

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

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

• канальный;
• сетевой;
• транспортный;
• сеансовый;
• представления данных и приложений.

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

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

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

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

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

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

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

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

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

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

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

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

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

5.6.2.2 Структура данных пакета EGTS_PT_RESPONSE

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

Таблица 6

Формат поля SFRD для пакета типа EGTS_PT_RESPONSE

5.6.2.3 Структура данных пакета EGTS_PT_SIGNED_APPDATA

Пакет данного типа применяется для передачи помимо структур, содержащих информацию уровня поддержки услуг, также информацию о «цифровой подписи», идентифицирующей отправителя данного пакета. Структура данных поля SFRD пакета EGTS_PT_SIGNED_APPDATA представлена в таблице 7.

Рисунок 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 в октетах;
• SMSC_AT — тип формата адреса SMSC.

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

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

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

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

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

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

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

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

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

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

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

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

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

• SMSC_A — адрес SMSC. Каждая десятичная цифра номера представлена в виде четырех бит (младшие 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;

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

• LUDH — длина заголовка пользовательских данных в байтах без учета размера данного поля;
• IEI «A», IEI «B», IEI «N» — идентификатор информационного элемента «A», «B» и «N» соответственно, который определяет тип информационного элемента и может принимать следующие значения (в шестнадцатеричной системе):

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

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

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

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

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

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

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

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

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

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

На подзапись EGTS_SR_COMMAND_DATA сервиса EGTS_COMMAND_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. Временные и количественные параметры протокола транспортного уровня при использовании пакетной передачи данных

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

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

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

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

• обмен информационными сообщениями, содержащими данные для обработки различными сервисами, а также запросы на выдачу информации сервисами;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 15

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

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

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

6.7.2 Сервис EGTS_AUTH_SERVICE

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

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

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

Таблица 17

Список подзаписей сервиса EGTS_AUTH_SERVICE

6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE

Формат подзаписи EGTS_SR_RECORD_RESPONSE

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

• CRN — номер подтверждаемой записи (значение поля RN из обрабатываемой записи);
• RST — статус обработки записи. Коды результатов обработки приведены в приложении В.

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

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

6.7.2.2 Подзапись EGTS_SR_TERM_IDENTITY.

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

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

• TID — уникальный идентификатор, назначаемый при программировании УСВ. Наличие значения 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных AC (IMSI, IMEI, serialid). В случае использования УСВ в качестве штатного устройства TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);
• HDIDE — битовый флаг, который определяет наличие поля HDID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• IMEIE — битовый флаг, который определяет наличие поля IMEI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• IMSIE — битовый флаг, который определяет наличие поля IMSI в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• LNGCE — битовый флаг, который определяет наличие поля LNGC в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• SSRA — битовый флаг предназначен для определения алгоритма использования сервисов (если бит равен 1, то используется «простой» алгоритм, если 0, то — алгоритм «запросов» на использование сервисов);
• NIDE — битовый флаг определяет наличие поля NID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• BSE — битовый флаг, определяющий наличие поля BS в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• MNE — битовый флаг, определяющий наличие поля MSISDN в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);
• HDID — идентификатор «домашней» телематической платформы (подробная учетная информация об УСВ хранится на данной платформе);
• IMEI — идентификатор мобильного устройства (модема). При невозможности определения данного параметра УСВ должна заполнять данное поле значением 0 во всех 15 символах;
• IMSI — идентификатор мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 16-ти символах;
• LNGC — код языка, предпочтительного к использованию на стороне УСВ, например «rus» — русский;
• NID — идентификатор сети оператора, в которой зарегистрирована УСВ. Используются 20 младших бит. Представляет пару кодов MCC-MNC. Структура поля NID представлена в таблице 20;
• BS — максимальный размер буфера приема УСВ в байтах. Размер каждого пакета информации, передаваемого на УСВ, не должен превышать данного значения. Значение поля BS может принимать различные значения (1024, 2048, 4096) и зависит от реализации аппаратной и программной частей конкретной УСВ;
• MSISDN — телефонный номер мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 15 символах (формат описан в национальных планах нумерации, утверждаемых соответствующими нормативными правовыми актами <1>).

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

6.7.2.3 Подзапись EGTS_SR_MODULE_DATA

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

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

6.7.2.4 Подзапись EGTS_SR_VEHICLE_DATA

Структура подзаписи представлена в таблице 22. В случае использования УСВ в конфигурации штатного оборудования по данным из поля VIN данная подзапись должна передаваться совместно с EGTS_SR_TERM_IDENTITY.

р) 1101 — мотоцикл (Class L7e).

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

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

б) Бит 5:1 — водород;

в) Бит 4:1 — электричество (более 42 В и 100 А/ч);

г) Бит 3:1 — жидкий пропан (LPG);

д) Бит 2:1 — сжиженный природный газ (CNG);

е) Бит 1:1 — дизель;

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

6.7.2.5 Подзапись EGTS_SR_AUTH_PARAMS

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

6.7.2.6 Подзапись EGTS_SR_AUTH_INFO

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

• UNM — имя пользователя;
• D — разделитель строковых параметров (всегда имеет значение 0);
• UPSW — пароль пользователя;
• SS — специальная серверная последовательность байт, передаваемая в подзаписи EGTS_SR_AUTH_PARAMS (необязательное поле, наличие зависит от используемого алгоритма шифрования).

6.7.2.7 Подзапись EGTS_SR_SERVICE_INFO

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

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

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

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

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

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

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

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

г) 11 — низкий.

Таблица 26

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

6.7.2.8 Подзапись EGTS_SR_RESULT_CODE

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

Таблица 27

Структура подзаписи 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 задействуется в случае использования GPRS и подключения к серверу по TCP/IP.

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

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

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

Далее УСВ производит разбор SMS-сообщения, проверяет корректность структур данных, вычисляет и сравнивает с полученными в сообщении значениями контрольные суммы. Если разбор и проверка прошли успешно, УСВ устанавливает GPRS-сессию и соединяется с указанным сервером по TCP/IP.

Алгоритм такого способа конфигурирования УСВ представлен на рисунке 8.

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

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

После процедуры установки параметра УСВ EGTS_UNIT_ID ей отправляется результат авторизации с кодом EGTS_PC_ID_NFOUND, указывающий, что TID = 0 в системе не найден. После этого сервер, не разрывая соединение с УСВ, ожидает повторной авторизации УСВ, но уже с корректным параметром TID. Алгоритм такого способа конфигурирования УСВ представлен на рисунке 9.

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

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

Это означает, что УСВ сразу после авторизации может использовать только перечисленные сервисы, даже если она предполагает «простой» алгоритм поддержи прав использования сервисов.

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

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

Рисунок 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.7.3 Сервис EGTS_COMMANDS_SERVICE

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

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

Таблица 28

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

6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA

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

Таблица 29

Структура подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_SERVICE

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

• CT — тип команды:

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

б) 0010 — CT_MSGCONF — подтверждение о приеме, отображении и/или обработке информационного сообщения,

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

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

е) 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 в подзаписи:

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

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

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

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

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

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

• CCD — код команды при ACT-0 или параметра при ACT-1 ... 4;
• DT — запрашиваемые данные или параметры, необходимые для выполнения команды. Данные записываются в данное поле в формате, зависящем от типа команды.

Подтверждение на ранее переданную команду при CT-CT_COMCONF, если с УСВ передается сопутствующая информация, имеет формат, представленный в таблице 31. Описанная структура содержится в поле CD (таблица 29).

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

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

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

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

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

EGTS_UNIT_SW_VERSION, EGTS_UNIT_VENDOR_ID,

EGTS_UNIT_IMEI.

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

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

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

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

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

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

Таблица 35

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

6.7.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA

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

• 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. Временные и количественные параметры протокола уровня поддержки услуг при использовании пакетной передачи данных

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

Таблица 39

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

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, и передача соответствующих ответов и подтверждений на них;
• передача данных профиля ускорения через GPRS (подзапись EGTS_SR_ACCEL_DATA);
• передача данных траектории движения транспортного средства при ДТП через GPRS (подзапись EGTS_SR_TRACK_DATA);
• обработка команд установки параметров УСВ, отправляемых оператором системы через GPRS и SMS, и передача соответствующих подтверждений на них.

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

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

Таблица 40

Список подзаписей сервиса EGTS_ECALL_SERVICE

7.3.1 Подзапись EGTS_SR_RECORD_RESPONSE

Данная подзапись имеет такую же структуру, как указано в 6.7.2.1.

7.3.2 Подзапись EGTS_SR_ACCEL_DATA

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

Таблица 41

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

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

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

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

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

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

Таблица 42

Формат структуры данных показаний акселерометра подзаписи EGTS_SR_ACCEL_DATA сервиса EGTS ECALL SERVICE

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

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

7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA

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

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

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

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

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

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

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

7.3.4 Подзапись EGTS_SR_TRACK_DATA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7.5.2 Параметры УСВ, перечисленные в подразделах «Запись профиля ускорения при ДТП» и «Запись траектории движения при ДТП» (см. таблицу 47), необязательны, если указанные функции не реализованы в УСВ.

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

• EGTS_ECALL_TEST_NUMBER;
• EGTS_ECALL_SIGNAL_INTERNAL;
• EGTS_ECALL_SIGNAL_EXTERNAL;
• EGTS_ECALL_SOS_BUTTON_TIME;
• EGTS_ECALL_CCFT;
• EGTS_ECALL_INVITATION_SIGNAL_DURATION;
• EGTS_ECALL_SEND_MSG_PERIOD;
• EGTS_ECALL_AL_ACK_PERIOD;
• EGTS_ECALL_MSD_MAX_TRANSMISSION_TIME;
• EGTS_ECALL_NAD_DEREGISTRATION_TIMER;
• EGTS_ECALL_DIAL_DURATION;
• EGTS_ECALL_AUTO_DIAL_ATTEMPTS;
• EGTS_ECALL_MANUAL_DIAL_ATTEMPTS;
• EGTS_ECALL_MANUAL_CAN_CANCEL;
• EGTS_ECALL_SMS_FALLBACK_NUMBER;
• EGTS_CRASH_RECORD_TIME;
• EGTS_CRASH_RECORD_RESOLUTION;
• EGTS_CRASH_PRE_RECORD_TIME;
• EGTS_CRASH_PRE_RECORD_RESOLUTION;
• EGTS_TRACK_RECORD_TIME;
• EGTS_TRACK_RECORD_RESOLUTION;
• EGTS_TRACK_PRE_RECORD_TIME;
• EGTS_VEHICLE_VIN;
• EGTS_VEHICLE_TYPE;
• EGTS_VEHICLE_PROPULSION_STORAGE_TYPE.

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

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

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

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

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

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

Все сервисы в рамках одной телематической платформы соединяются с диспетчером и не имеют непосредственных связей между собой.

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

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

Структурная схема взаимодействия элементов системы, основанной на описываемом протоколе транспортного уровня, представлена на рисунке А.1. Каждый сервис имеет определенный тип, который на рисунке А.1 определяется параметром SID.

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

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

Провайдер телематических сервисов предназначен для обмена данными между сервисами и телематическими устройствами.

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

Заголовок NGTP полностью совпадает с первыми байтами заголовка протокола транспортного уровня: Protocol Version (1 байт), Security Context (2 байта), NGTP Header Length (1 байт), NGTP Header Encoding (1 байт).

В NGTP идентификатором УСВ является VIN/DriveID, в описываемом протоколе — UNIT_ID.

Для идентификации УСВ, исполненной в конфигурации штатного оборудования, используется VIN.

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

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

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

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

Коды результатов обработки приведены в таблице В.1.

ПРИМЕР РЕАЛИЗАЦИИ АЛГОРИТМА РАСЧЕТА КОНТРОЛЬНОЙ СУММЫ CRC16 НА ЯЗЫКЕ C/*

Приложение Д (справочное)

Е.1 Кодировка символов латинского алфавита приведена на рисунке Е.1.

Е.3 Кодировка символов латинского и древнееврейского алфавитов приведена на рисунке Е.3.

БИБЛИОГРАФИЯ