База ГОСТовallgosts.ru » 33. ТЕЛЕКОММУНИКАЦИИ.АУДИО-И ВИДЕОТЕХНИКА » 33.020. Телекоммуникации в целом

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

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

Дата введения: 01/01/2017
Дата отмены: -
Заменен на: -
Код ОКС: 33.020
Скачать PDF: ГОСТ 33465-2015 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протокол обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях.pdf
Скачать Word:ГОСТ 33465-2015 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протокол обмена данными устройства/системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях.doc


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



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

(МГС)

INTERSTATE COUNCIL FOR STANDARDIZATION, METROLOGY AND CERTIFICATION

(ISC)

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

СТАНДАРТ

ГОСТ

33465-

2015

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

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

ПРИ АВАРИЯХ

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

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

СШ1ЛТТМ1фП[М

2И7

ГОСТ 33465—2015

Предисловие

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

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

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

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

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

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

Краткое наименование страны по МК (ИСО 3163) 004-97

Код страны по МК (ИСО 3166)004-97

Сокращенное наименование национального органа по стандартизации

Армения

AM

Минэкономики Республики Армения

Беларусь

BY

Госстандарт Республики Беларусь

Киргизия

KG

Кыргызстаедарт

Россия

RU

Росстандарт

Таджикистан

TJ

Тэджикстандарт

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

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

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

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

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

© Стандартинформ. 2017

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

II

ГОСТ 33465—2015

Содержание

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

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

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

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

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

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

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

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

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

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

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

5.7    Описание структуры данных при использовании SMS в качестве резервного канала передачи

данных.........................................................................12

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

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

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

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

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

услуг...........................................................................17

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

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

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

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

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

при использовании пакетной передачи данных........................................42

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

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

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

системы на основе протокола транспортного уровня...........................53

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

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

Приложение Г (справочное) Пример реализации алгоритма расчета контрольной суммы CRC16

на языке СГ............................................................58

Приложение Д (справочное) Пример реализации алгоритма расчета контрольной суммы CRC8

на языке СГ............................................................59

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

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

ГОСТ 33465—2015

Введение

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

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

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

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

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

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

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

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

-    ло мобильной (подвижной связи) — в части передачи данных с использованием SMS-сообщений.

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

-    производителями устройств/систем экстренного реагирования при авариях;

-    автопроизводителями;

• оператором системы экстренного реагирования при авариях;

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

«V

ГОСТ 33465—2015

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

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

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

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

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

Дата введения — 2017—01—01

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

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

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

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

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

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

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

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

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

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

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

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

1

ГОСТ 33465—2015

мени аварии, VIN-коде транспортного средства и другую информацию, необходимую для экстренного реагирования.

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

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

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

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

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

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

Примечания

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

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

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

Примечания

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

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

3.2 Сокращения

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

НИС    —    навигационно-информационные системы;

ОЗУ    —    оперативное запоминающее устройство;

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

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

2

ГОСТ 33465—2015

ПТУ

тп

тс

УСВ

Цифровая

подпись

ЭРА

СР-1251

CRC-&(16)

DNS

еСаИ

EGTS

FTP

IP

GSM

HTTP

IMAP

ISDN

Little-endian

NGTP

OSI

PDU

POP3

SC

SIM

SME

SMS

SMSC

SMTP

TCP

TFTP

telnet

UDP

протокол транспортного уровня: телематическая платформа: транспортное средство:

устройство/система вызова экстренных оперативных служб:

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

экстренное реагирование при авариях;

набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows; циклический избыточный код; система доменных имен;

общеевропейская система экстренного реагирования при авариях: телематический стандарт для системы экстренного реагирования при авариях; протокол передачи файлов: протокол Интернет;

глобальный цифровой стандарт для мобильной сотовой связи; протокол передачи гипертекста;

протокол прикладного уровня для доступа к электронной почте: цифровая сеть с интеграцией обслуживания: младший байт вперед (порядок следования байт);

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

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

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

модуль идентификации абонента;

объекты, способные отправлять и получать SMS-сообщения:

сервис коротких сообщений;

центр обработки коротких сообщений;

простой протокол передачи почты;

протокол управления передачей:

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

сетевой протокол для реализации текстового интерфейса по сети; протокол пользовательских дейтаграмм.

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

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

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

- канальный;

•    сетевой;

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

•    сеансовый:

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

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

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

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

3

ГОСТ 33465—2015

Соответствие сетевой модели OSI. стека протоколов ТСРЛР и протоколов передачи данных системы экстренного реагирования при авариях представлено в таблице 1.

Таблица 1 — Соответствие уровней модели OSI. стека протоколов ТСРЛР и протоколов системы

Модель OSI

Стек протоколов ТСРЛР

Протоколы

ТСРЛР

Протоколы системы

Номер уровня

Название уровня

Номер уровня

Название уровня

7

Приложений

4

Приложений

FTP. HTTP. POP3. IMAP, telnet. SMTP. DNS.TFTP

Уровень поддержки услуг

6

Представления

данных

5

Сеансовый

Транспортный уровень

4

Транспортный

3

Транспортный

TCP. UDP

TCP

3

Сетевой

2

Межсетевой

IP

IP

2

Канальный

1

Доступ к сети

1

Физический

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4

ГОСТ 33465—2015

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

Для части пакета транспортного уровня используется алгоритм вычисления циклического избы* точного кода CRC-8.

Для части пакета уровня поддержки услуг используется алгоритм вычисления циклического из* быточного кода CRC-16.

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

5.4.1    Механизм обеспечения надежной доставки основан на использовании подтверждений ранее отправленных пакетов. Отправляющая сторона после передачи пакета ожидает на него подтверждения в виде пакета определенного типа, содержащего идентификатор ранее переданного пакета и код результата его обработки на принимающей стороне. Ожидание производится в течение определенного промежутка времени, регламентированного протоколом транспортного уровня и зависящего от типа используемого транспортного протокола нижнего уровня (параметр TL_RESPONSE_TO) (см. 5.8). После получения подтверждения отправляющая сторона производит анализ кода результата.

Коды результатов обработки также регламентированы протоколом транспортного уровня и представлены в приложении В.

5.4.2    В зависимости от результата анализа пакет считается доставленным или недоставленным. Пакет также считается недоставленным, если подтверждение не приходит по истечении времени TL_RESPONSE_TO (см. 5.8). Недоставленные пакеты отправляются повторно (число попыток отправки регламентировано настоящим протоколом и определяется параметром TL_RESEND_ATTEMPTS) (см. 5.8). По достижению предельного числа попыток отправки канал передачи данных считается ненадежным. и производится уничтожение установленной сессии (разрыв соединения в случае использования TCP/IP протокола в качестве транспортного) и попытка создания новой сессии (соединения) через время, определяемое параметром TL_RECONNECT_TO (см. 5.8).

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

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

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

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

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

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

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

Тип ванных

Размер, байт

Диапазон значений

Описание

BOOLEAN

1

TRUE-1. FALSE-0

Логический тип. принимающий только два значения TRUE или FALSE

BYTE

1

0... 255

Целое число без знака

USHORT

2

0... 65535

Целое число без знака

UINT

4

0... 4294967295

Целое число без знака

ULONG

8

0... 18446744073709551615

Целое число без знака

SHORT

2

-32768... +32767

Целое число со знаком

5

ГОСТ 33465—2015

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

Тип данных

Pajuep. байт

Диапазон значений

Описание

INT

4

-2147483648...+2147483647

Целое число со знаком

FLOAT

4

± 1.2 Е — 38 ... 3.4 Е + 38

Дробное число со знаком в соответствии с [4]

DOUBLE

6

±2.2Е —308... 1,7 Е +308

Дробное число со знаком в соответствии с [4]

STRING

Переменный. Размер определяется внешними параметрами или применением специального символа-терминатора (код 0x00)

Содержит последовательность печатных символов в кодировке по умолчанию СР-1251. если явно не указана другая кодировка (при помощи дополнительного параметра)

BINARY

Переменный. Размер определяется внешними параметрами

Содержит последовательность данных типа BYTE

ARRAYOFTYPE

Переменный. Размер определяется внешними параметрами

Может содержать последовательность одного из вышеуказанных типов (TYPE), хроме BINARY. Порядок следования байт и размер каждого элемента используемого типа определяется самим типом. Экземпляры типов идут последовательно один за другим. Например: ARRAY OF STRING содержит в своем составе 10 экземпляров типа STRING, при этом размер каждого экземпляра определяется разделителем (ход 0x00), который должен присутствовать между экземплярами

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

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

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

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

Заголовок протокола

Данные уровня поддержки

Контрольная сумма данных уровня

транспортного уровня

услуг

поддержки услуг

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

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

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

6

ГОСТ 33465—2015

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

Бит 7 Бит В

Бит 6

Бит 4 Бит Э

Бит 2

Бит t Бит 0

Тип

Тип данных

Размер, байт

PRV (Protocol Version)

M

BYTE

1

SKID (Security Key ID)

М

BYTE

1

PRF (Prefix)

RTE

ENA

CMP

PR

М

BYTE

1

HL (Header Length)

М

BYTE

1

HE (Header Encoding)

М

BYTE

1

FDL (Frame Data Length)

М

USHORT

2

PID (Packet Identifier)

м

USHORT

2

PT (Packet Type)

М

BYTE

1

PRA (Peer Address)

О

USHORT

2

RCA (Recipient Address)

О

USHORT

2

TTL (Time To Live)

О

BYTE

1

HCS (Header Check Sum)

м

BYTE

1

SFRD (Services Frame Data)

о

BINARY

0... 65517

SFRCS (Services Frame Data Check Sum)

о

USHORT

0.2

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

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

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

Обозначение параметра (поля)

Назначение параметра (поли)

PRV

Параметр определяет версию используемой структуры заголовка и должен содержать значение 0x01. Значение данного параметра инкрементируется каждый раз при внесении изменений в структуру заголовка

SKID

Параметр определяет идентификатор ключа, испогъзуемый при шифровании

PRF

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

RTE (Route)

Битовое поле определяет необходимость дальнейшей маршрутизации данного пакета на удаленную телематическую платформу, а также наличие опциональных параметров PRA. RCA. TTL. необходимых для маршрутизации данного пакета. Если поле имеет значение 1. то необходима маршрутизация и поля PRA. RCA. TTL присутствуют в пакете. Данное поле устанавливает диспетчер той телематической платформы, на которой сгенерирован пакет, или УСВ, сгенерировавшая пакет для отправки на телематическую платформу (в случае установки в ней параметра HOME_DISPATCHER_ID. определяющего ее адрес, на который данная УСВ зарегистрирована). В случае отсутствия в УСВ параметра HOME_DISPATCHER_ID маршрутизация пакета производится по внутренним правилам диспетчера, обрабатывающего пакет

ENA (Encryption Algorithm)

Битовое поле определяет код алгоритма, используемый для шифрования данных из поля SFRD. Если полв имеет значение 0 0. то данные в поле SFRD не шифруются. Состав и коды алгоритмов не определены в данной версии протокола

7

ГОСТ 33465—2015

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

Обозначение параметра (пега)

Назначение параметра (поля)

СМР

(Compressed)

Битовое поле определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1. то данные в none SFRO считаются сжатыми. Алгоритм сжатия не определен в данной версии протокола

PR (Priority)

Битовое поле определяет приоритет маршрутизации данного пакета и может принимать следующие значения:

00    — наивысший:

01    —высокий:

10    — средний:

11    — низкий.

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

HL

Длина заголовка протокола транспортного уровня в бейтах с учетом байта контрольной суммы (поля HCS)

HE

Определяет применяемый метод кодирования следующей за данным параметром части заголовка протокола транспортного уровня. Зарезервировано

FDL

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

PJD

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

PT

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

Поле РТ может принимать следующие значения:

0    — EGTS_PT_RESPONSE (подтверждение на протокол транспортного уровня):

1    — EGTS_PT_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг):

2    — EGTS_PT_SIGNED_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью)

PRA

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

RCA

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

TTL

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

8

ГОСТ 33465—2015

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

Обозначение параметра (поля)

Назначение параметра (поля)

SFRCS

Контрольная сумма.

Для подсчета контрольной суммы по денным из поля SFRD используется алгоритм CRC16—CCITT. Данное поле присутствует только 8 том случае, если есть поле SFRD. Пример программного кода расчета CRC-16 приведен в приложении Г.

SFRD

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

HCS

Контрольная сумма заголовка протокола транспортного уровня (начиная с поля PRV до поля HCS. не включая последнего). Для подсчета значения поля HCS ко воем байтам указанной последовательности применяется алгоритм CRC-8. Пример программного хода расчете CRC-8 приводен 8 приложении Д

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

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

8 зависимости от типа пакета протокола транспортного уровня структура поля SFRD имеет различный формат.

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

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

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

Вит 7 Вит в Вит S Бит 4 Бит Э Вит 2 бит Т бит 0

Тип

Тип данных

Размер, бант

SDR 1{ServK» Data Record)

О

BINARY

9... 65517

SDR 2

О

BINARY

9...65517

SORn

О

BINARY

9... 65517

Примечание — Структуры SDR 1. SDR 2. SDRn содержат информацию протокола уровня поддержки услуг. Таких структур в составе поля SFRD может быть одна или несколько, идущих одна за другой. Описание внутреннего состава структур представлено в разделе б.

S.6.2.2 Структура данных пакета EGTS_PT_RESPONSE

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

9

ГОСТ 33465—2015

Огпмйм

еетьет wsKwse

Г

нонш

А - маршрутизация и отправка пакета на другую ТП;

В - обработка данных протокола уровня поддержки услуг

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

уровня при приеме

10

ГОСТ 33465—2015

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

Бит 7 битв бит 5 бит 4 Бит 3 Бит 2 Бит 1 битО

Тип

Тип данных

Размер, байт

RPID (Response Packet ID)

М

USHORT

2

PR (Processing Result)

М

BYTE

1

SDR 1 (Service Data Record)

О

BINARY

9... 65514

SDR 2

О

BINARY

9... 65514

SDRn

О

BINARY

9... 65514

Примечания

1    Параметр RPID — идентификатор пакета транспортного уровня, подтверждение на который формируется.

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

3    Структуры SDR 1. SDR 2. SDRn — структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой.

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

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

5.6.2.4    На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA. поступающий от УСВ на телематическую платформу или от нее на УСВ. должен быть отправлен пакет типа EGTS_PT_RESPONSE. содержащий в none PID номер пакета иэ пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA.

На рисунке 3 представлена последовательность обмена пакетами, при взаимодействии УСВ и телематической платформы.

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

бит 7 бит в бит S бит 4 Бит 3 Бит 2 Бит t Бит 0

Тип

Тип данных

Размер, байт

SIGL (Signature Length)

М

USHORT

2

SIGO (Signature Data)

О

BINARY

0... 512

SDR 1{Servioe Data Reoord)

о

BINARY

9... 65515

SOR 2

о

BINARY

9... 65515

SDRn

О

BINARY

9... 65515

Примечания

1    Параметр SIGL — определяет длину данных «цифровой подписи» из поля SIGD.

2    Параметр SIGD — содержит непосредственно данные «цифровой подписи».

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

11

ГОСТ 33465—2015

Рисунок 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).

Таблица 6 — Формат SMS с использованием POU-режима

Бит 7

Бит в

Бит S

Бит 4 Бит 3

Бит 2

Бит 1 Бит 0

Тип

Рынер. Байт

SMSC.AL (SMSC Address Length)

М

1

SMSC.AT (SMSC Address Type)

О

0.1

SMSC.A (SMSC Address)

О

0.6

TP_RP

TPJJDHI

TP_SRR

TP_VPF

TP_RD

TP_MTI

М

1

TP_MR (MessageReference)

М

1

TP_DA_L (Destination Address Length)

М

1

TP_DA_T (Destination Address Type)

М

1

12

ГОСТ 33465—2015

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

Бит 7 Битв Битв Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Размер, байт

TP_DA {Destination Address)

M

6

TP_PID (Protocolldentifier)

M

1

TP_DCS (Data Coding Schema)

M

1

TP_VP (VaUdrtyPeriod)

0

0. 1.7

TPJJDL (User Data Length)

M

1

TP.UD (UserData)

0

0...140

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

ниже:

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

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

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

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

Бит 7

Битв

Бит 5

Бит 4

Бит 3

Бит 2

Бит 1

Бит 0

Размер, байт

1

TON

N

PI

1

Параметры полей ТР_ОА_Т и SMSC_AT. приведенные в таблице 9. имеют следующие назначения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•    SMSC_A — адрес SMSC. Каждая десятичная цифра номера представлена в виде четырех бит (младшие 4 бита — цифра более старшего разряда, старшие 4 бита — цифра меньшего разряда), при атом, если число цифр в номере нечетное, то в битах с4 по 7 последнего байта номера устанавливается значение OxF (1111b). Данный параметр опциональный и его наличие зависит от значения параметра SMSC_AL. В случае отсутствия параметра SMSC_A. используется SMSC из SIM-карты;

- TP_MTI — (Message Type Indicator) тип сообщения (должен содержать бинарное значение 01);

•    TP_RD — (Reject Duplicates) поле определяет, необходимо ли SMSC принимать данное сообщение на обработку, если существует предыдущее необработанное отправленное с данного номера сообщение. которое имеет такое же значение поля TP_MR и такой же номер получателя в поле TP_DA;

13

ГОСТ 33465—2015

• TP_VPF — (Validity Period Format) формат параметра TP_VP. Возможные значения поля TP_VPF представлены е таблице 10;

Таблица 10 — Формат поля TP_VP 8 зависимости от значения поля TP_VPF

Значение битое

Описание

0

0

Поле TP_VP не передается

1

0

Поле TP_VP имеет формат «относительное время» и размер 1 байт

0

1

Поле TP_VP имеет формат «расширенное время» и размер 7 байт

1

1

Поле TP_VP имеет формат «абсолютное время» и размер 7 байт

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

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

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

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

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

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

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

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

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

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

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

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

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

Бит 7 Битв Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Битв

Тип

Размер, байт

ШОН (Length of User Data Header)

О

1

IEI «А* (Informabon-Element-tdentifier «А»)

О

1

LIE «А» (Length of Information-Element «А»)

О

1

IED «А» (Information-Element-Data of «А»)

О

1 ... п

IEI «8» (Informabon-Element-ldentifer «В»)

О

1

LIE «В» (Length of Information-Element «8»)

о

1

IED «В» (Information-Element-Data of «В»)

о

1... п

IEI «N» {Information-Element-Identifier «N»)

о

1

LIE *N* (Length of Information-Element «М»)

о

1

IED «N» (Information-Element-Data of «N»)

о

1... п

UD (User Data)

м

1...140

14

ГОСТ 33465—2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бит 7 Вит в Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 БитО

Тип

Размер. Байт

CSMRN (Concatenated Short Message Reference Number)

М

1

MNSM (Maximum Number of Short Messages)

М

1

SNCSM (Sequence Number of Current Short Message)

М

1

Примечания

1    CSMRN — номер конкатенируемого SMS-сообщения должен иметь одинаковое значение для всех частей длинного SMS-сообщения.

2    MNSM — общее число сообщений, из которых состоит длинное SMS. Должен содержать значения в диапазоне от 1 до 255.

3    SNCSM — номер передаваемой части длинного SMS-сообщения. Инкрементируется при отправке каждой новой части длинного сообщения. Должен содержать значение в диапазоне от 1 до 255. Если значение данного поля превышает значение из поля MNSM игы равно нулю, то принимающая сторона должна игнорировать весь информационный элемент.

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

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

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

15

ГОСТ 33465—2015

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

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

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

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

при использовании пакетной передачи данных

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

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

Название

Тип

данных

Диапазон

значении

Значение по умолчанию

Описание

TL.RESPONSE.TO

BYTE

0 ... 255

5

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

TL.RESEND.ATTEMPTS

BYTE

0 ... 255

3

Число повторных попыток отправки неподтвержденного пакета

TL.RECONNECTTO

BYTE

0 ... 255

30

Время, по истечении которого будет осуществляться повторная попытка установления канала связи после его разрыва, с

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

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

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

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

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

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

•    идентификация принадлежности данных определенному типу сервиса;

•    определение характеристик данных (число, тип. состав, размер, кодировка и др.).

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

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

16

ГОСТ 33465—2015

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

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

поддержки услуг

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

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

поддержки услуг

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

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

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

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

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

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

Данные уровня поддержки услуг

Запись RID = 1

Запись RID = 2

Запись RID = N

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

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

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

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

Заголовок записи

Данные записи

Подзапись 1

Подзапись N

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

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

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

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

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

17

ГОСТ 33465—2015

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

Бит 7

б«т e

Бит S Биг 4 Бит Э

Бит 2

Бит 1

Биг 0

Тип

Тип данных

Размер, байт

RL (Record Length)

M

USHORT

2

RN (Record Number)

М

USHORT

2

RFL (Record Flags)

М

BYTE

1

SSOD

RSOD

RPP

TMFE

EVFE

OBFE

OID (Object Identifier)

О

UINT

4

EVID (Event identifier)

О

UINT

4

TM (Time)

О

UINT

4

SST (Source Service Type)

М

BYTE

1

RST (Recipient Service Type)

М

BYTE

1

RD (Record Data)

М

BINARY

3... 65498

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

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

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

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

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

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

б)    0 — сервис-отправитель расположен на телематической платформе;

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

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

б)    0 — сервис-получатель расположен на телематической платформе;

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

•    TMFE (Time Field Exists) — битовое поле, определяющее наличие в данном пакете поля ТМ:

а)    1 — поле ТМ присутствует.

б)    0 — поле ТМ отсутствует:

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

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

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

•    OBFE (Object ID Field Exists}— битовое поле, определяющее наличие в данном пакете поля OID:

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

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

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

18

ГОСТ 33465—2015

АС

Комэцда-мпрос EGTS.TftACK.DATA. Сообщение 1. (Заголовок записи уровня поддержки услуг (06fe*i. оюымгз). Eeis_«_coMMANO_dATA (стка.сом. сст*сс_о«. cio*iv

Commend Dal* |A0ft=0, S2*0, ACTsO, CCteEGTS ECALL TRACK 0ATA)|

ТП

ПоА'веркдкже. Сообщение 2. (EOT5.SR_COMMANO.OATA на Сообщение 1 (CTsCT.COMCONf. ССТ*СС_ОК, сим» _

EGTS.5R_TRACK.0ATA. Сообщение 3.

(Заголовок записи уровня поддержки услуг <obfe«i. оюшхшн

*

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

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

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

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

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

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

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

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

вит 7 Битв Биг 5 Битв Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

SRT (Subrecord Тура)

М

BYTE

1

SRL {Subrecord Length)

М

USHORT

2

SRD (Subrecord Data)

О

BINARY

0... 65495

Примечания

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

2    SRL — длина данных в байтах подзаписи в none SRD:

3    SRD — данные подзаписи. Наполнение данного поля специфично для каждого сочетания идентификатора сервиса и типа подзаписи.

19

ГОСТ 33465—2015

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

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

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

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

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

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

Код

Название

Описание

до1»

шсэ2»

шсд3»

1

EGTS_AUTH_SERV1CE

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

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

+

20

ГОСТ 33465—2015

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

Код

Название

Описание

ДО1'

шсэ2'

шсдэ»

2

EGTS_TELEDATA_SERV1CE

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

+

+

4

EGTS.COMMANDS.SERVICE

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

*■

+

+

9

EGTS_FIRMWARE_SERVICE

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

*

+

+

10

EGTS_ECALL_SERVICE

Сервис, обеспечивающий выполнение функционала ЭРА Сервис описан в разделе 7

*

+

+

Примечание — Варианты конфигурации УСВ:

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

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

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

6.7.2 Сервис EGTS_AUTH_SERVICE

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

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

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

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

Код

Название

Описание

0

EGTS_SR_RECORD_RESPONSE

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

1

egtssr.termjdentity

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

2

EGTS_SR_MODULE_DATA

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

21

ГОСТ 33465—2015

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

Км

Название

Описание

3

EGTS_SR_VEHICLE_DATA

Подзапись применяется УСВ для передачи на телематическую платформу информации о транспортном средстве

6

EGTS_SR_AUTH_PARAMS

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

7

EGTS_SR_AUTH_lNFO

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

8

EGTS_SR_SERVtCE_INFO

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

9

EGTS_SR_RESULT_CODE

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

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

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

Бит 7

Бит в

Бит 5

Бит *

Бит Э

Бит 2

Бит 1

БитО

Тип

Тип авнных

Размер, байт

CRN (Confirmed Record Number)

М

USHORT

2

RST (Record Status)

М

BYTE

1

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

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

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

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

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

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

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

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

Бит 7 Бит б

Бит S

Бит 4

Бит 3

Бит 2

Бит 1

БитО

Тип

Тип данных

Размер, бейт

TID (Terminalldentifier)

M

UINT

4

Flags

M

BYTE

1

MNE BSE

NIDE

SSRA

LNGCE

IMSIE

IMEIE

HDIDE

HDIO (Home Dispatcher Identifier)

0

USHORT

2

IMEI (International Mobile Equipment identity)

о

STRING

15

IMSI (International Mobile Subscriber Identity)

0

STRING

16

LNGC (Language Code)

о

STRING

3

22

ГОСТ 33465—2015

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

бит 7 битв Бит 5 Бит 4 бит 3 Бит 2 Бит 1 БитО

Тип

Тип аанкых

Размер, байт

NID (Network Identifier)

О

BINARY

3

BS (Buffer Size)

О

USHORT

2

MSISON (Mobile Station Integrated Services Digital Network Number)

О

STRING

15

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

•    TID — уникальный идентификатор, назначаемый при программировании УСВ. Наличие эначе-ния 0 в данном поле означает, что УСВ не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы и однозначно определяет набор учетных данных УСВ. TID назначается при инсталляции УСВ как дополнительного оборудования и передаче оператору учетных данных АС (IMSI, IMEI, serialjd). В случае использования УСВ в качестве штатного устройства ТЮ сообщается оператору автопроизводителем вместе с учетными данными (VIN. IMSI. IMEI);

•    HDIDE — битовый флаг, который определяет наличие поля HDIO в подзаписи (если бит равен 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 — код языка, предпочтительного к использованию на стороне УСВ . например «гив» — русский;

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

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

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

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

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

23

ГОСТ 33465—2015

риториальмо распределенной сети платформ. При использовании только одной «домашней» платфор* мы. передача HDID не требуется.

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

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

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

Биты 20..23

Биты 10... 19

Биты0...9

Тип

Тип данных

Размер, байт

МСС (Mobile Country Code)

MNC (Mobile Network Code)

M

BINARY

3

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

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

• МСС — код страны:

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

6.7.2.3 nofl3annCbEGTS_SR_MODULE_DATA

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

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

-    МТ — тип модуля, определяет функциональную принадлежность модуля (1 — основной модуль: 2 — модуль ввода вывода: 3 — модуль навигационного приемника; 4 — модуль беспроводной связи). Здесь указаны рекомендованные правила нумерации типов модулей. Конкретная реализация сервиса авторизации может вводить и расширять собственную нумерацию типов, включая все внешние периферийные контроллеры;

-    VID — код производителя;

-    FWV — версия аппаратной части модуля (старший байт — число до точки — major version, младший — после точки — minor version, например версия 2.34 будет представлена числом 0x0222);

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

Бит 7 Бит б Бит 5 Бит * Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

МТ (Module Туре)

M

SHORT

1

VID (Vendor Identifier)

M

HINT

4

FWV (Firmware Version)

M

USHORT

2

SWV (Software Version)

M

USHORT

2

MD (Modification)

M

BYTE

1

ST (State)

M

BYTE

1

SRN (Serial Number)

о

STRING

0... 32

D (Delimiter)

M

BYTE

1

DSCR (Description)

о

STRING

0... 32

D (Delimiter)

M

BYTE

1

24

ГОСТ 33465—2015

•    SVW — версия программной части модуля (старший байт — число до точки, младший — после точки);

•    МО — код модификации программной части модуля;

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

•    SRN — серийный номер модуля;

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

•    DSCR — краткое описание модуля.

67.2.4 Подзапись EGTS_SR_VEHICLE_DATA.

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

Таблица 22 — Формат подэаписи EGTS_SR_VEHICLE_DATA сервиса EGTS_AUTH_SERVJCE

вит 7 Бит в Бит S Бит 4 вит 3 вит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

VIN (Vehicle Identification Number)

M

STRING

17

VHT (Vehicle Type)

M

U1NT

4

VPST (Vehicle Propulsion Storage Type)

M

UINT

4

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

•    VIN — идентификационный номер транспортного средства;

•    VHT — тип транспортного средства:

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

б)    Бит 4-0;

в)    0001 — пассажирский (Class М1):

г)    0010 — автобус (Class М2);

д)    0011 — автобус (Class М3);

е)    0100 — легкая грузовая машина (Class N1);

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

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

к)    0111 — мотоцикл (Class Lie);

л)    1000 — мотоцикл (Class L2e);

м)    1001 — мотоцикл (Class L3e);

н)    1010 — мотоцикл (Class L4e);

о)    1011 — мотоцикл (Class L5e): л) 1100 — мотоцикл (Class L6e); р) 1101 — мотоцикл (Class L7e).

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

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

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

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

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

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

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

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

67.2.5 Подзапись EGTS_SR_AUTH_PARAMS Структура подэаписи представлена в таблице 23.

25

ГОСТ 33465—2015

Таблица 23 — Формат подзаписи EGTS_SR_AUTH_PARAMS сервиса EGTS.AUTH.SERVICE

Биг 7

Бит 6

Бит S

Бит 4

Бит 3

Бит 2

Бит 1 Бит 0

Тип

Тип ванных

Размер. Байт

FLG (Flags)

M

BYTE

1

-

EXE

SSE

MSE

ISLE

PKE

ENA

PKL (Public Key Length)

О

USHORT

2

РВК (Public Key)

О

BINARY

0...512

ISL (Identity String Length)

О

USHORT

2

MSZ (Mod Size)

О

USHORT

2

SS (Server Sequence)

О

STRING

0...255

D (Delimiter)

О

BYTE

1

EXP {Exp)

О

STRING

0...255

D (Delimiter)

О

BYTE

1

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

•    ЕХЕ — битовый флаг, определяет наличие поля ЕХР и следующего за ним разделителя D (если 1, то поля присутствуют);

•    SSE — битовый флаг, определяет наличие поля SS и следующего за ним разделителя D (если 1. то поля присутствуют);

•    MSE — битовый фпаг. определяет наличие поля MSZ (если 1, то поле присутствует);

•    ISLE — битовый фпаг. определяет наличие поля ISL (если 1. то поле присутствует);

•    РКЕ — битовый флаг, определяет наличие попей PKL и РВК (если 1. то поля присутствуют):

•    ENA — битовое поле, определяющее требуемый алгоритм шифрования пакетов. Если данное поле содержит значение 00. то шифрование не применяется, и под запись EGTS_SR_AUTH_PARAMS содержит только один байт, иначе, в зависимости от типа алгоритма, наличие дополнительных параметров определяется остальными битами поля FLG:

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

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

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

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

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

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

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

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

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

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

6.7.2.6 Подзапись EGTS_SR_AUTHJNFO

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

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

-    UNM — имя пользователя;

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

•    UPSW — пароль пользователя:

-    SS — специальная серверная последовательность байт, передаваемая в подэаписи EGTS_SR_ AUTH_PARAMS (необязательное поле, наличие зависит от используемого алгоритма шифрования).

26

ГОСТ 33465—2015

Таблица 24 — Структура подэаписи EGTS_SR_AUTH_INFOсервиса EGTS.AUTH.SERVICE

Бит 7 Битв Бит S Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

UNM (User Name)

M

STRING

0...32

D (Delimiter)

M

BYTE

1

UPSW (User Password)

M

STRING

0...32

D (Delimiter)

M

BYTE

1

SS (Server Sequence)

О

STRING

0...255

D (Delimiter)

О

BYTE

1

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

Таблица 25 — Структура подэаписи EGTS.SR.SERVICE.INFOсервиса EGTS_AUTH_SERV!CE

Бит 7

Битв Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 БитО

Тип

Тип данных

Размер, байт

ST (Service Type)

М

BYTE

1

SST (Service Statement)

М

BYTE

1

SRVP (Service Parameters)

М

BYTE

t

SRVA

— SRVRP

Поля подэаписи 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 — Список возможных состояний сервиса

Код

Назаание

Описание

0

EGTS_SST_IN_SERVICE

Сервис в рабочем состоянии и разрешен к использованию

128

EGTS_SST_OUT_OF_SERVtCE

Сервис в нерабочем состоянии (выключен)

129

EGTS_SST_DENIED

Сервис запрещен для использования

130

EGTS_SST.NO.CONF

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

131

EGTS.SST.TEMP.UNAVAIL

Сервис временно не доступен

67.2.8 Подзапись EGTS.SR_RESULT.CODE Структура подэаписи представлена в таблице 27.

Поля подзаписи EGTS.SR_RESULT.CODE имеют следующее значение:

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

27

ГОСТ 33465—2015

Таблица 27 —Структура подзагмси EGTS_SR_ RESULT_CODE сервиса EGTS_AUTH_SERVICE

Бит 7

Бит в

Бит S

Бит 4

Бит 3

Бит 2

Бит 1

Бит 0

Тип

Тип ванных

Размер, байт

RCD (Res

jH Code)

М

BYTE

1

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

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

Требование настоящего пункта не распространяется на штатные системы, которые поддерживают только базовую услугу реагирования при аварии. В конфигурации штатного оборудования сервис EGTS_AUTH_SERV1CE не используется. В этом случае сообщения сервиса 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-соединение, уникальный идентификатор УСВ UNITJD.

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

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

28

ГОСТ 33465—2015

АС

ТП

Регистрация а сети GSM, UMTS |lM£l, IMSi) через имфрэструктуру сотового оператора

Установка параметр». Сдебщвн»* 1. KOIS.SH.COMMANO.MTft {СТ-СТ.СОМ, ССТ-СС.ОКОО-М: .Command оаы [АСТ*2. CCD-EGTS.GPKS.APN. ОТ.Точм доегущ GPRS*))

Подщсрмщсмяс. Сообщение 2.

|6GTS SR COMMAND DATA на Сообщение 1

_ {ct.ct_comconm:ct«ccjx сю-он _

Установка параметра. СооСн^мм 3. KGIS.SR.COMMftNO.MTA ICT-CT.COM. <СТ»СС.ОК,С©*1Ь

Command Оэм |АСТ*2. CCtteEGTS.SERVERJWORESS, ОТ:*Адрес и порт сервера*)!.

оодтвертчаечне Смбикя-с *. ICGTS.SR.COMMANO.MTA на Сообщение 3

{ст-ст_<омсомГсст-сс_о*,ао«1Н .

Устаимма rapawerpa. Сообщение S. |EGTS_SR_COM4AND_MTA {СТ-СТ.СОМ. ССГ-СС.ОК. 00-21. Command Оеи(АСТ-2,ССОт|ОТ*1иа(П_Ю.ОТП1М>Т.Ю)) _

Педгеерадение. СссРм»ме 6. [CGTS.SA.COMMANO.OATA на Сообщепие Ь (CTsCT.COMCOW. ССТКС.ОК. С10*2)|

ДАННЫЕ АУТЕНТИФИКАЦИИ. Сообщение 7. leGTS.SR.TERMjOENKTYl

*

■4-

Подтеерид«м1е. Сообщение в IEGTS.SR. RECORD .RESPONSE на сообщение 7]

ДАНШ АУТЕНТИФИКАЦИИ. Сообщение 9. (E6IS.SS.VEWCtE_OATA)

-*

гкщтверхдение Сообщат» 10. |EGT$_SR.ftCCOftD.RESPONSE на юобщенм» 9)

рейЛьтат АУтеитивимини Сообщение И. IEGTS_Sfl.RESUl.T_CO ОС)

Паотаеридеиие.Сообщеыие 12. lEGTS.SR.AKORO.RFSPONM на сообщение П|

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

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

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

29

ГОСТ 33465—2015

АС

ТП

УС*»«ОвИ» TCP/IP    С С*р«?рОМ

ДМ НМ) АУПИТК«ИКЫ*4И Сое6иИ”»*1 |£«TS.«.TIHM,eiMTlTV {ЯО-0. IMClIMSlH

ПсшгмриАМН. C<w6uriliti 2. l«STS_SR_lttC0«O_Rf5rOMSC и* cocftutfMW 1|

ДАЖШК АУНН1Ж>тАи»И.Соойч*—< 1 lKT5_S*_VtHIClE_0ATA)

ncup«ep»ww*w« CmAwemwA [fCTS.SA.RtCORO.IKSAONSt Mi ax6ta-M* t)

Vcmmom* ntpaw'w (ооби*ми* i lteTS.SR_COMMANO.OAT» ICTKT.COM, CCT iCCJX OCoO); Command CMIe (ACT»}. CCD-MT5.0NIT_K>, DIHIMt JD)|

П«дЯ1<|ц<М111M. Conftunaч 6. ttC1SJA.C0MMAN0.0ATA »> СбСвиКние S _ (СТ-СТ.СОАЮОМ), CCT*CC.O)t. 000)1 _

PtIVNbtAT АУПН1ИФИКА)1ИИ Гоо6и*~и» ? ICCTS.SR.RCSUIT.COOC {KO-RGTS.KJOJMOUHOI!

Пед’КДОКИог С«ОвиЛ~"?в [fOTS.SR.RICOHO.mSPONM «octwM n

>■

ДДШК ЛУШ4ПМИ<ЛЩ1И. Смбмсмв 9. IteTS.SA.TtRM.IMNTI1Y(ПОКвП.ЦМТJO. Mtl.lMW)

OMisepHAMie CootaitMM 1ft ltCTS.9».RtCORO.«SAO)et -и сообиеи* Ц

AAlMHt АУПНтММАЦИИ C«0«UUMltll {CeTS.SA.VfHiOt.OATA)

пмпввсчм**. Ссобисм^ 12. |IOTS.SR.RICO*O.U;SPO*n( •« сообкгмч 11)

ИЗУЛЫА1 AVItHIWKKAlJHM.CootuMt-M* 11

IC6Ts.sR.*eswT.cocei

Пмнионвснм*. Ссебииня* 14. ItCTS.SR.RtCORP.RtSAONSt hi <«o6u«hi« 13)

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

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

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

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

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

30

ГОСТ 33465—2015

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

Рисунок 10 — Обмен сообщениями на этапе аегоризации УСВ на телематической платформе

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

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

31

ГОСТ 33465—2015

После получения 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_SERVlCE

Код

Название

Описание

0

EGTS_SR_RECORD_RESPONSE

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

51

EGTS_SR_COMMAND_DATA

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

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

Таблица 29 — Структура подзагыси EGTS_SR_COMMAND_DATA сервиса EGTS.COMMANDS.SERVICE

Бит 7 Битв Бит 5 Бит 4

Бит 3 Бит 2

Бит 1

БитО

Тип

Тип дан них

Размер, байт

СТ (Command Туре)

CCT (Command Confirmation Type)

M

BYTE

1

СЮ (Command Identifier)

M

UINT

4

SID (Source Identifier)

M

UINT

4

ACFE

CHSFE

M

BYTE

1

CHS (Charset)

0

BYTE

1

ACL (Authorization Code Length)

о

BYTE

1

AC (Authorization Code)

о

BINARY

0...255

CD (Command Data)

о

BINARY

0...65205

32

ГОСТ 33465—2015

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

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

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

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

в)    0011 — CT.MSGFROM — информационное сообщение от УСВ,

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

д)    0101 — CT.COM — команда для выполнения на транспортном средстве.

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

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

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

•    ССТ — тип подтверждения (имеет смысл для типов команд CT.COMCONF. CT.MSGCONF. CT.DELIV):

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

б)    0001 — CC.ERROR — обработка завершилась ошибкой.

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

г)    0011 — CC.DEL — команда успешно удалена.

д)    0100 — CC.NFOUND — команда для удаления не найдена.

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

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

•    CID — идентификатор команды, сообщения. Значение изданного поля должно быть использова* но стороной, обрабатывающей/еыполняющей команду или сообщение, для создания подтверждения. Подтверждение должно содержать в поле CID то же значение, что содержалось в самой команде или сообщении при отправке;

•    SID — идентификатор отправителя данной команды или подтверждения. В случае передачи от УСВ на ТП подтверждения на команду или результат выполнения команды (тип команды CT_COMCONF. CT.MSGCONF, CT.DELIV) необходимо копировать значение данного поля из ранее пришедшей на УСВ команды. При инициации отправки подзаписи EGTS_SR_COMMAND_DATA на стороне УСВ дан* кое поле имеет значение 0;

•    ACFE (Authorization Code Fteld Exists) — битовый флаг, определяющий наличие полей ACL и АС в подэаписи:

а)    1 — поля ACL и АС присутствуют в подэаписи.

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

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

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

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

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

а)    0 — СР-1251,

б)    1 — IAS (CCITT T.50VASCII (ANSI Х3.4).

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

г)    3 — Latin 1 (рисунок Е.1. приложение Е).

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

е)    5» JIS (X 0208-1990).

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

и)    7 — Latin/Hebrew (рисунок Е.З. приложение Е).

к)    8 — UCS2;

33

ГОСТ 33465—2015

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

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

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

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

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

Бит 7 битв Бит $ Бит 4

Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер. байт

ADR (Address)

M

USHORT

2

SZ (Size)

ACT (Action)

М

BYTE

1

CCO (Command Code)

М

USHORT

2

DT (Data)

О

BINARY

0... 65200

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

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

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

•    ACT — описание действия, используется в случае типа команды, поле СТ-СТ_СОМ подзаписи EGTS_SR_COMMAND _DATA. Значение поля может быть одним из следующих вариантов:

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

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

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

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

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

CCD;

•    CCD — код команды при АСТ-0 или параметра при АСТ-1...4;

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

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

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

Бит 7 Битв Битв Бит 4 Бит Э Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер.байт

ADR (Address)

M

USHORT

2

CCD (Command Code)

M

USHORT

2

DT (Data)

о

BINARY

0...65200

34

ГОСТ 33465—2015

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

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

. CCD — код команды, сообщения из таблицы 32 или параметра из таблицы 34. в соответствии с которым передается сопутствующая информация в поле ОТ;

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

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

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

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

EGTS_UNIT_SW_VERS!ON. EGTS_UNIT_VENDOR_ID.

EGTSJJNITJMEI.

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

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

Название команды

Код

Тип. чиспо и предельное значение параметра

Описание

EGTS_RAW_DATA

0x0000

BINARY {до 65200 байт)

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

egts_test_mooe

0x0001

BYTE

Команда начала /окончания тестирования УСВ: 1 — начало тестирования:

0 — окончание тестирования

EGTS.CONFIG.RESET

0x0006

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

EGTS_SET_AUTH_CODE

0x0007

BINARY

Установка кода авторизации на стороне УСВ. Для обработки данной команды оператор должен установить корректные значения полей ACL и АС. указанных в таблице 29. После подтверждения данной команды УСВ будет использовать уже новые данные для сравнения со значением из поля АС в некоторых присылаемых на УСВ командах

EGTS.RESTART

0x0008

Команда производит перезапуск основного программного обеспечения УСВ. Для обработки данной команды оператор должен установить корректные значения полей ACL и АС. указанных е таблице 29

35

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

название команды

КОД

Тил и число параметра

Огысаниа

EGTS_RAW_DATA

0x0000

BINARY {до 65200 байт)

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

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

Имя параметра

Код

Тил

параметра

Значение no умолчанию

Описание

Применимость1!

Возможность

изменения2'

Радио mule

EGTS_RADIO_MUTE_DELAY

0x0201

INT

0

Задержка между установкой сигнала радио mute и началом проигрывания звука, мс

до

Да

EGTS_RADIO_UNMUTE_DELAY

0x0202

INT

0

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

ДО

Да

Установки общего на знамения

EGTS_GPRS_APN

0x0203

STRING

•0$

Параметр, определяющий точку доступа GPRS

до.шсд

Да

EGTS.S ERV Е R.ADORESS

0x0204

STRING

«#•

Адрес и порт оереера для связи с испо/ъэованием TCP/IP протокола

до.шсд

Да

EGTS_SIM_PIN

0x0205

INT

0

Р114-код$1Мнсарты

до. шсэ, шсд

Да

EGTSJNT_MEM_TRANSMIT_INTERVAL

0x0206

INT

60

Интервал между повторны км попытками отправки сообщений е случае неудачной отправки посредством пакетной передачи или через $м$. мин

до. шсэ. шсд

Да

EGTS_INT_MEM_TRANSMIT_ATTEMPTS

0x0207

INT

10

Максимальное число попыток передои сообщения посредством пакетной передачи или через $м$ в случае ошибок передачи

до. шсэ. шсд

Да

Рехмм тестирования

EGTS_TEST_REGISTRATION_PERIOD

0x0242

INT

5

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

до. шсэ. шсд

Да

ГОСТ 33465—2015

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

Имя параметра

Код

Тип

параметр*

Значение no умолчанию

Описание

Применимость1)

Возможность

изменения21

EGTS_TEST_MODE_EN D.DISTANC Е

0x020A

INT

300

Дистанция, на которой режим тестирования выключается автоматически, м

ДО. ШСЭ. шсд

Да

Режим «Автосервис»

EGTS_GARAGE_MODE_END_DISTANCE

0x020B

INT

300

Дистанция, на которой реямм «Автосервис» выключается автоматически, м

ДО

Да

EGTS_GARAGE_MODE_PW

0x020C

INT/0...6

0

Пиния, сигнализирующая, что УСВ находотся в режиме «Автооервис»: NONE — нет симатзации режима; X — PIN_X линия активная, когда система находится в данном режиме

ДО

Да

Прочие параметры

EGTS_GNSS_POWER_OFF_TIME

0x0301

INT

500

Промежуток ер вмени,через который о тк по чается питание ГНСС приемника после выключения зажигания, мс

до

Да

EGTS_GN$S_DATA_RATE

0x0302

INT/1.2.5.

10

Определяется производителем УСВ

Темп выдачи данных ГНСС приемником. Гц

ДО. ШСЭ. шсд

Нет

EGTS_GNS$_MIN_EtEVATION

0x0303

INT/5.-.15

15

Минимальное значение угла возвышения (угла отсечки) навигационных космических аппаратов, град

ДО. ШСЭ. шсд

Нет

EGTS_GNSS_MIN_ELEVATION

0x0303

INT/5...15

15

Минимальное значение угла возвышения (угла отоечт) навигационных космических аппаратов, град

ДО. ШСЭ. шсд

Нет

Параметры устройства

EGTS_l)NIT_ID

0x0404

INT

0

Уникальный идентификатор УСВ. назначаемый оператором системы при первой авторизации

ДО. ШСЭ. шсд

Да

EGTS.UNITJMEI

0x0405

STRING

Номер IMEI

ДО. ШСЭ. шсд

Нет

EGTS_UNIT_RS4S5_BAUD_RATE

0x0406

INT

19200

Скорость порта RS465. бит/с

ДО. ШСЭ. шсд

Да

EGTS_UNIT_R$465_$TOP_BIT$

0x0407

INT

1

Число стоп-битов при передаче данных через порт RS485

ДО. ШСЭ. шсд

Да

ы

*4

ГОСТ 33465—2015

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

Имя параметре

код

Тип

параметра

Знании* no умолчанию

Описание

применимое*»11

ВОЗМОЖНОСТЬ

изменения*1

EGTSJJNfT.RS485_PARITY

0x0408

INTjO.1,2

0

Способ проверки на четность при передаче данных через порт RS465:

0    — проверка не производится;

1    — проверка типа ODD;

2    — проверка типа EVEN

ДО. ШСЭ. ШСД

Да

EGTS.UN fT.HOME.DISPATCH ER_ID

0x0411

INT

0

Идентификатор телематической платформы, в хранилище которой на* ходится информация об учетных данных устройства, списке предоставляемых услуг и их статусах

ДО. ШСЭ. ШСД

Да

EGTS_SERVICE_AUTH_METHOD

0x0412

I NT

1

Метод использования услуг:

1 — простой метод {все услуги по умолчанию доступны УСВ):

0 — с подтверждением (реализуются только те услуги, информация о разрешении использования которых пришла с телематической платформы)

ДО. ШСЭ. ШСД

Да

EGTS_SERVER_CHECK_IN_PERIOD

0x0413

INT

30

Время между попытками установить TCP/IP соединение с сервером, с

ДО. ШСД

Да

EGTS_SERVER_CHECK_IN_ ATTEMPTS

0x0414

INT

5

Число попыток установления ТСР/ IP соединения с оереером. по достижению которого будет произведена повторная установка сессии верхнего уровня (GPRS)

ДО. ШСД

Да

E GTS _S ERV E R_ PACK E TTO UT

0x0415

INT

5

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

ДО. ШСД

Да

EGTS SERVER PACKET RETRANSMIT ATTEMPTS

0x0416

INT

3

Число попыток повторной отправки неподтвержденного пакета, по достижению которого УСВ производит повторную инициализацию сессии на уровне TCP/IP

ДО. ШСД

Да

EGTS_UNfT_MIC_LEVEL

0x0417

INT/0...10

8

Уровень чувствительности микрофона

ДО. ШСЭ. ШСД

Да

EGTS_UNfT_SPK_LEVEl

0x0416

INT/0.-.10

6

Уровень громкости динамика

ДО. ШСЭ. ШСД

Да

ГОСТ 33465—2015

ГОСТ 33465—2015

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

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

2> Да означает, что установленное начальное значение параметра УСВ может изменяться после начальной установки УСВ. Her — что установленные начальные значения не подлежат изменению в процессе применения УСВ.

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

-    EGTS_GPRS_APN:

-    EGTS_SERVER_ADDRESS;

-    EGTS_SIM_PIN;

-    EGTS_AUTOMATIC_REGISTRATION;

-    EGTS_TEST_MODE_END_DISTANCE;

-    EGTS_GARAGE_MODE_END_DISTANCE;

-    EGTS_TEST_REGtSTRATION_PERIOD;

-    EGTS_GNSS_POWER_OFF_TIME;

-    EGTS_GNSS_DATA_RATE;

-    EGTS_GNSS_MIN_ELEVATION;

• EGTS.UNITJD;

-    EGTS.UNITJMEI;

-    EGTS_UNIT_HOME_DISPATCHER_ID;

-    EGTSJNT_MEM_TRANSMIT_INTERVAL;

-    EGTS_INT_MEM_TRANSMIT_ATTEMPTS.

67.3.3 Примеры процедур передачи команд приведены на рисунках 11 и 12.

АС

Команд» £GTS_£CAlL_MSD_Rta Сообщение 1. (EGTS.SR.COMMAND.DATA {СТ*СТ_СОМ, ССТ«СС_0К, OD-1); Command Рам (AQR=0.~S2rQ, ACTsQ, CCO=£GTS_ECALL_MSO_REQ}]

ТП

(Опционально) подтверждение. Сообщение 2. {EOrs_SR.COMMAND.OATA на Сообщены* 1 (СТ*СТ COMCONF. ССТ*СС OK. CIO=l|)

MSD

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

39

ГОСТ 33465—2015

АС

ТП

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

Запрос значения параметра. Сообщение 1. lEGIS_SR_COMMANO_OATA {CT-CT.COM,ССТ-СС.ОК.СЮ-N);

_ Command Data (ADfi=0. S2=0, ACTsi, CCD=£<jTS_UNTT_IM£I>| _

подтверждение, сообщение 7. (£GTS_$R_R£CORD_RE$POWS£ м» Сообщение Ц ]£GTS_SR_COMMANO_OATA на Сообщение 1 {cf*CT.COMCONF, CCT*CCJDK, С!ОЩ;

Command Data (AMsO, CC0=£6TSJJNIT_IMEI. DT=<IM£I number»))

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

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

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

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

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

Код

Название

Описание

0

EGTS SR RECORD RESPONSE

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

33

EGTS SR SERVICE PART.DATA

Подзапись предназначена для передачи на УСВ данных, которые разбиваются на части и передаются последовательно. Данная подзапись применяется для передачи богъших объектов, длина которых не позволяет передать их на УСВ одним пакетом

34

EGTS SR SERVICE FULL.DATA

Подзапись предназначена для передачи на УСВ данных, которые не разбиваются на части, а передаются сдоим пакетом

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

Таблица 36 — Структура подзагыси EGTS_SR_SERVICE_PART_OATA сервиса EGTS_FIRMWARE_SERVICE

Бит 7 Битв Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

ID {Identity)

М

USHORT

2

PN (Part Number)

М

USHORT

2

EPQ {Expected Parts Quantity)

М

USHORT

2

ODH (Object Data Header)

О

BINARY

0...71

OD (Object Data)

М

BINARY

1...65400

Примечания

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

40

ГОСТ 33465—2015

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

2    PN — последовательный номер текущей части передаваемой сущности.

3    EPQ — ожидаемое число частей передаваемой сущности.

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

5    ОО—данные непосредственно передаваемой сущности.

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

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

Таблица 37 — Формат заголовка передаваемой сущности подзаписи EGTS_SR_SERV1CE PART_DATA сервиса EGTS FIRMWARE SERVICE

Бит 7 Битв Бит 5 Бит 4

Бит 3 Бит 2

Бит 1 Бит 0

Тип

Тип данных

Размер, байт

ОА {Object Attribute)

M

BYTE

1

ОТ (Object Type)

MT (Module Type)

CMI (Component or Module Identifier)

М

BYTE

1

VER (Version)

М

USHORT

2

WOS (Whole Object Signature)

М

USHORT

2

FN (File Name)

О

STRING

0...64

0 (Dekmiter)

М

BYTE

1

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

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

•    ОТ — тип сущности по содержанию. Определены следующие значения данного поля:

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

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

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

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

б)    01 — УСВ.

•    CMI — номер компонента в случае принадлежности сущности непосредственно УСВ или идентификатор периферийного модуля/порта. подключенною к УСВ. в зависимости от значения параметра МТ;

•    VER — версия передаваемой сущности (старший байт — число до точки major version, младший. — после точки minor version, например версия 2.34 будет представлена числом 0x0222);

•    WOS — сигнатура (контрольная сумма) всей передаваемой сущности. Используется алгоритм CRC16-CCITT;

•    FN — имя файла передаваемой сущности (данное поле опционально и может иметь нулевую длину);

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

67.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA

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

41

ГОСТ 33465—2015

Таблица 38 — Структура подзагтиси EGTS_SR_SERVICE_FULL_DATA сервиса EGTS_FIRMWARE_SERVlCE

Бит 7

Бит в

Бит 5

Бит 4

Бит 3

Бит 2

Бит 1

БигО

Тип

Тип данных

Размер. Байт

ООН (Object Data Header)

М

BINARY

7...71

OD (Object Data)

м

BINARY

1...65400

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

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

-    ОО — данные непосредственно передаваемой сущности.

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_DATAn каждую EGTS_SR_SERVICE_FULL_DATA при успешном приеме и обработке со стороны УСВ должна передаваться подзапись EGTS_SR_RECORD_RESPONSE. содержащая код EGTS_PC_OK. что будет воспринято сервисом как удачная попытка отправки всей сущности.

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

при использовании пакетной передачи данных

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

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

Название

Тип

данных

Диапазон

значений

Значение по умолчанию

Описание

EGTS SL NOT AUTH.TO

BYTE

0... 255

6

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

Если в течение данного времени сообщение не поступает, платформа должна разорвать установленное с УСВ TCP/IP соединение

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

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

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

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

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

• поддержка сервиса обработки команд EGTS_COMMANDS_SERVICE. указанного в 6.7.3;

- поддержка команд EGTS_ECALL_REQ. EGTS_ECALL_MSD_REQ. отправляемых оператором системы через SMS. и передача соответствующих ответов и подтверждений на них:

42

ГОСТ 33465—2015

. передача данных профиля ускорения через 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

Код

Название

Описание

0

EGTS_SR_RECORD_RESPONSE

Подэапись применяется для осуществления подтверждения записи протокола уровня поддержки услуг из пакета типа EGTS РТ APPDATA

20

EGTS_SR_ACCEL_DATA

Подэапись предназначена для передачи на телематическую платформу данных профиля ускорения УСВ

40

EGTS_SR_RAW_MSD_DATA

Подэапись используется УСВ для передачи МНД на телематическую платформу в исходном виде

62

EGTS_SR_TRACK_DATA

Подэапись применяется для передачи данных о траектории движения транспортного средства при ДТП на телематическую платформу

7.3.1    Подзапись EGTS_SR_RECORD_RESPONSE

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

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

Таблица 41 — Структура подзаписи EGTS_SR_ACCEL_DATAсервиса EGTS_ECALL_SERV(CE

вит 7 Битв Бит 5 Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип данных

Размер, байт

SA (StructuresAmount)

M

BYTE

1

ATM (AbsduteTime)

M

UINT

4

ADS1 (Accelerometer Data Structure 1}

M

BINARY

8

ADS2 (Accelerometer Data Structure 2)

0

BINARY

8

ADS2S5 (Accelerometer Data Structure 255}

О

BINARY

8

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

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

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

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

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

8 составе подзаписи EGTS_SR_ ACCEL_DATA должна передаваться хотя бы одна структура

ADS.

43

ГОСТ 33465—2015

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

вит 7 Битв Битв Бит 4 Бит 3 вит 2 Бит 1 БитО

Тип

Тип данных

Размер, байт

RTM (RelativeTime)

M

USHORT

2

XAAV (X Axis Acceleration Value)

M

SHORT

2

YAAV (Y Axis Acceleration Value)

M

SHORT

2

ZAAV (Z Axis Acceleration Value)

M

SHORT

2

В таблице 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 — Формат подзаписи EGTS_SR_RAW_MSO_DATA Сервиса EGTS_ECALL_SERV!CE

Бит 7

Бит в

Бит 5

Бит 4

Бит Э

Бит 2

Бит 1

БитО

Тип

Тип данных

Размер, байт

FM (Format)

М

BYTE

1

MSD (Minimal Set of Data)

м

BINARY

0...116

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

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

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

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

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

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

7.3.4 Подзапись EGTS_SR_TRACK_DATA

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

Таблица 44 —Структура подэаписи EGTS_SR_ TRACK_DATA сервиса EGTS_ECALL_SERVICE

Бит 7 Битв Битв Бит 4 Бит 3 Бит 2 Бит 1 БитО

Тип

Тип данных

Размер, байт

SA (Structures Amount)

M

BYTE

1

ATM (Absolute Time)

M

UINT

4

TDS1 (Track Data Structure 1)

M

BINARY

1...12

TDS2 (Track Data Structure 2)

О

BINARY

1...12

TDS 255 (Track Data Structure 255)

О

BINARY

1...12

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

•    SA — число передаваемых точек траектории движения транспортного средства:

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

44

ГОСТ 33465—2015

точное время измерения определяется с учетом поля RTM-структуры информации об отдельной точке траектории движения:

• TDS1 ... TDS25S — структуры данных, содержащие параметры отдельной точки траектории движения транспортного средства. Формат структуры представлен в таблице 45.

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

Таблица 45 — Формат структуры данных отдельной точки траектории движения транспортного средства гкадза-писи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVICE

Бит 7

Бит 6

Бит 5

Бит 4 Бит 3 Бит 2 Бит 1 БитО

Тип

Тип данных

Размер, байт

TNDE

LOHS

LAHS

RTM (Relative Time)

M

BYTE

1

LAT (Latitude)

О

U1NT

4

LONG (Longitude)

о

U1NT

4

SPDL (Speed Low Bits)

о

USHORT

2

DIRH

SPDH (Speed Hi Bits)

DIR (Direction)

о

BYTE

1

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

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

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

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

45

ГОСТ 33465—2015

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_ECALLJNVITATION_SIGNAL_DURATION:

-    EGTS_ECALL_SEND_MSG_PERIOD;

-    EGTS_ECALL_AL_ACK_PERIOD;

♦    EGTS_ECALL_MSD_MAX_TRANSMISSION_TIME;

♦    EGTS_ECALL_NAD^DEREGISTRATION_TIMER:

♦    EGTS_ECALLJ)IAL_DURATION;

♦    EGTS_ECALL_AUTO_OlAL_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_RECORO_TIME;

-    EGTS_CRASH_PRE_RECORO_RESOLUTION;

-    EGTS_TRACK_RECORD_TIME:

♦    EGTS_TRACK_RECORD_RESOLUTION;

-    EGTS_TRACK_PRE_RECORD_TIME;

♦    EGTS_VEHICLE_VIN;

♦    EGT S_ VE HIC LE_TYPE;

-    EGTS VEHICLE PROPULSION STORAGE TYPE.

46

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

Название

команды

код

Тип. число и предал иное значение параметра

Описание

EGTS.ECALL.REQ

0x0112

BYTE/0.1

Команда на осуществление экстренного вызова с УСВ. Используется только через SMS. Команда содержит один параметр, которым определяет тип события:

0    —ручной вызов:

1    —автоматический вызов

EGTS ECALL MSD REQ

0x0113

BINARY (MID INT.

TRANSPORT BYTE)

Команда на осуществление повторной передав МИД. Используется только через SMS.

Команда содержит два параметра:

МЮ — идентификатор сообщения запрашиваемого МНД. Если параметр MIDs0, то отправляется новое сообщение:

TRANSPORT — тип используемого УСВ канала при отправке МНД:

0 — любой, на усмотрение УСВ:

2 —через SMS

Примечание — При получении данной команды с параметром TRANSPORT=2 отправка подтверждающей подзаписи EGTS.SR_COMMAND.DATA с кодом подтверждения СС_ОК в поле СОТ (Command Conftrmafon Туре) не является обязательным.

EGTS_ ACC EL_DATA

0x0114

Команда на осуществление передачи данных профиля ускорения. Используется только через SMS

EGTS.TRACK .DATA

0x0115

Команда на осуществление передачи данных траектории движения. Используется только через SMS

EGTS ECALL DEREGISTRATION

0x0116

Ком&да на осуществление дерегистрации УСВ в оети подвижной радютелефомной связи

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

Имя параметра

Код

Тип парам erpa

Эначениг no умолчанию

Описание

применимость11

Возможность

изменения21

Установки общего назначения

EGTS.ECALL.TEST.NUMBER

0x020D

STRING

«<

Телефонный номер для тестовых звонков в системе экстренною реагирования при авариях

ДО. ШСЭ. ШСД

Да

Конфигурация и конфигураштоннью данные услуг. Базовая услуга системы экстренною реагирования при авариях

EGTS_ECALL_ON

0x0210

BOOLEAN

TRUE

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

ДО. ШСЭ. ШСД

Да

EGTS ECALL CRASH SIGNAL.INTERNAL

0x0211

BOOLEAN

TRUE

Если для определения события аварии используется встроенный в УСВ измеритель ускорения

ДО

Да

ГОСТ 33465—2015

&

се

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

Имя параметра

Код

Тип параметра

Значение no умолчанию

Описание

Применимость1!

Возможность

изменения?1

EGTS ЕС ALL CRASH SIGNAL.EXTERNAL

0x0212

BOOLEAN

TRUE

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

ДО

Да

EGTS ECALL SOS BUTTON tTme

0x0213

INT

200

Длительность, в течение которой должна быть нажата кнопка в Экстренный вызов», для инициации экстренного вызова независимо от состояния линии заямгания. мс

до

Да

EGTS ECALL NO AUTOMATiC.TRIGGERING

0x0214

BOOLEAN

FALSE

Процедура инициализации реямма «Экстренный вызов» в автоматическом режиме отключена

до.шсэ.шсд

Да

EGTS_ASI15_TRESH0LD

0x0215

FLOAT

1.6

Порог срабатывания датчика автоматической идентификации события ДТП в значения индекса возможного ущерба ASI15

до

Да

EGTS_ECAll_MODE_PIN

0x0216

INT/0...8

0

Линия, сигнализирующая, что система находится в режиме "ЭРА':

NONE — нет сигна/ыэации режима;

X — PIN.X активная линия, когда система находится в данном режиме

до

Да

EGTS.ECALL.CC FT

0x0217

INT

60

Дштельностъ счетчика автоматического прекращения звонка, мин

до.шсэ.шсд

Да

EGTS ECALL INVITATION SIGNAL.DURATION

0x0216

INT

2000

Дштельность сигнала INVITATION, мс

до.шсэ.шсд

Да

EGTS ECALL SEND MSG PERIOD

0x0219

INT

5000

Период сообщения SEND MSG. мс

до.шсэ.шсд

Да

EGTS ECALL AL ACK PERIOD

0x021A

INT

5000

nepMOflAL-ACK. мс

до.шсэ.шсд

Да

EGTS ECALL MSD MAX TRANSMISSION .TIME

0x021B

INT

20

Максимальная дштельность передачи МИД. с

до.шсэ.шсд

Да

EGTS ECALL NAD DEREGISTRATION.TIMER

0x021D

INT

6

Время, по истечении которою GSM или UMTS модуль прэсращает регистрацию в сети, ч

до.шсэ.шсд

Да

ГОСТ 33465—2015

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

Имя параметра

Код

Тип парам «тра

Значение no умолчанию

Описание

Применимость1!

Возможность

изменения2'

EGTS_ECALL_DIAL_DU RATION

0x021E

I NT

5

Общая продолжительность доэеона при инициации экстренною вызова, мин

ДО. ШСЭ. ШСД

Да

EGTS ЕСЛИ AUTO DIAL ATTEMPTS

0x021F

I NT

10

Число попыток доэеона при автоматически инициированном вызове.

Значение не может быть установлено е 0

ДО. ШСЭ. ШСД

Да

EGTS ECALL MANUAL DIAL ATTEMPTS

0x0220

INT

10

Число попыток дозвона при экстренном вызове. инициированном вручную.

Значение не может устанавливаться в 0

ДО. ШСЭ. ШСД

Да

EGTS ECALL MANUAL CAN CANCEL

0x0222

BOOLEAN

TRUE

TRUE — экстренный вызов, инициированный врущую. мажет быть прекращен со стороны пользователя

ДО. ШСЭ. ШСД

Да

EGTS ECALL MANUAL CAN

CANCa

0x0222

BOOLEAN

TRUE

TRUE — экстренный вызов, инициированный вручную, может быть прекращен со стороны пользователя

ДО. ШСЭ. ШСД

Да

EGTS ECALL SMS FALLBACK.NUMBER

0x0223

STRING

"112'

Номер, по которому УСВ посылает SMS с минимальным набором данных по запросу от оператора системы

ДО. ШСЭ. ШСД

Да

Запись профиля ускорения при ДТП

IGNITION OFF FOLLOW UP TIME1

0x0224

INT

120

Промежуток времени, в течение которою осуществляется запись профиля ускорения при ДТП при выключенном зажигании. мин

ДО

Да

IGNITION OFF FOLLOW UP TIME2

0x0225

INT

240

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

ДО

Да

EGTS CRASH RECORD TIME

0x251

INT/0...250

250

Время записи информации о профиле ускорения при ДТП, мс

до

Да

EGTS CRASH RECORD RESOLUTION

0x0252

INT/1...5

1

Продолжительность одного отсчета при записи профиля ускорения при ДТП. мс

до

Да

EGTS CRASH PRE RECORD TIME

0x0253

INT/0.. .20000

20000

Время записи информации о профиле ускорения до тою. как событие ДТП наступило, мс

ДО

Да

ГОСТ 33465—2015

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

ИМЯЛврОМОТрО

код

Тип ларей «гое

ЛО

умолчанию

Описание

применимость1*

Возможность

изменения51

EGTS CRASH PRE RECORD RESOLUTION

0x0254

INT/5...100

5

Продолжительность одного отсчета при записи профиля ускорения до того, как событие ДТП наступило, мс

ДО

Да

Запись траектории движения при ДТП

EGTS TRACK RECORD TIME

0x025A

INT/0...180

10

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

ДО

Да

EGTS TRACK PRE RECORD.TIME

0x0258

INT/О...еОО

20

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

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

ДО

Да

EGTS TRACK RECORD RESOLUTION

0x025C

INT/1...30

10

Продолжительность одного отсчета при записи траектории движения транспортного средства. 100 мс

ДО

Да

Параметры транспортного средства

EGTS_VEHICLE_VIN

0x0311

STRING

--

VIN е соответствии с |1] (приложение 7)

до. шсэ. шсд

Да

EGTS VEHICLE PROPULSION STORAGE TYPE

0x0313

INT

0

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

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

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

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

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

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

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

ж)    битО: 1 — бензин

до.шсэ.шсд

Да

ГОСТ 33465—2015

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

Имя параметра

Код

Тип параметра

Значение по умолчанию

Описание

Применимость1)

возможность

изменения2'

EGT$_VEHICIE_TYPE

0x0312

INT

0

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

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

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

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

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

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

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

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

8    — мотоцжл (L2e);

9    — мотоцжл (L3e);

Ю — мотоцикл (14е):

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

12    — мотоцикл (U6e):

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

ДО. ШСЭ. ШСД

Да

1> до — для УСВ, исполненной е конфигурации дополнительного оборудования: ШСЭ — для УСВ, исполненной е конфигурации штатного оборудования и предназначенной для реализации только базовой услуги системой: ШСД — для УСВ. исполненной в конфигурации штатного оборудования и предназначенной для реализадеи дополнительных услуг, кроме базовой.

31 Да означает, что установленное начальное значение параметра УСВ может изменяться после начальной установки УСВ: Нет — что установленные начальные значения не подлежат изменению е процессе доименения УСВ.

ГОСТ 33465—2015

ГОСТ 33465—2015

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

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

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

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

Лоле данных AL-ACK

Номер бита, представляющего попе даниых

Значение

Зарезервированное поле № 1

4

Поле не используется

Зарезервированное поле № 2

3

Поле не используется

Признак корректности полученных данных

2

0    — полученные данные корректны {Positive АСК);

1    — завершение вызова (Cleardown)

Версия формата данных

1

0    — текущий формат:

1    — зарезервировано для будущего использования

52

ГОСТ 33465—2015

Приложение А

(справочное)

Описание принципа построения навигационно-информационной системы на основе протокола

транспортного уровня

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

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

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

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

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

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

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

53

ГОСТ 33465—2015

Т«леметическ«я Лла>фортв 4

Те/>емвгич«сидо Платформе 3

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

54

ГОСТ 33465—2015

Приложение Б

(справочное)

Анализ протокола транспортного уровня на основа концепции NGTP

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

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

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

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

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

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

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

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

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

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

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

55

ГОСТ 33465—2015

Приложение В

(обязательное)

Коды результатов обработки

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

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

Значение

Обозначение

Описание

0

EGTS_PC_OK

Успешно обработано

1

EGTS_PC_IN_PROGRESS

В процессе обработки (результат обработки еще не известен)

126

EGTS_PC_UNS_PROTOCOL

Неподдерживаемый протокол

129

EGTS_PC_DECRYPT_ERROR

Ошибка декодирования

130

EGTS_PC_PROC_DENIED

Обработка запрошена

131

EGTS_PC_lNC_HEADERFORM

Неверный формат заголовка

132

EGTS_PC_INC_DATAFORM

Неверный формат данных

133

EGTS_PC_UNS_TYPE

Неподдерживаемый тип

134

EGTS_PC_NOTEN_PARAMS

Неверное число параметров

135

EGTS_PC_DBL_PROC

Попытка повторной обработки

136

EGTS_PC_PROC_SRC_DENiED

Обработка данных от источника запрещена

137

EGTS_PC_HEAOERCRC_ERROR

Ошибка контрольной суммы заголовка

136

EGTS_PC_DATACRC_ERROR

Ошибка контрольной суммы данных

139

EGTS_PC_INVDATALEN

Некорректная длина данных

140

EGTS_PC_ROUTE_NFOUND

Маршрут не найден

141

EGTS_PC_ROUTE_CLOSED

Маршрут закрыт

142

EGTS_PC_ROUTE_DENIED

Маршрутизация запрещена

143

EGTS.PCJNVADDR

Неверный адрес

144

EGTS_PC_TTLEXPIRED

Превышено число ретрансляции данных

145

EGTS_PC_NO_ACK

Нет подтверждения

146

EGTS_PC_OBJ_N FOUND

Объект не найден

147

EGTS_PC_EVNT_NFOUND

Событие не найдено

146

EGTS_PC_SRVC_NFOUND

Сервис не найден

149

EGTS_PC_SRVC_DENIED

Сервис запрещен

150

EGTS_PC_SRVC_UNKN

Неизвестный тип сервиса

151

EGTS_PC_AUTH_DENIED

Авторизация запрещена

152

EGTS_PC_ALREADY_EXISTS

Объект уже существует

153

EGTS_PC_ID_NFOUND

Идентификатор не найден

154

EGTS_PC_INC_DATETIME

Неправильная дата и время

56

ГОСТ 33465—2015

Окончание таблицы В. 1

Значение

Обозначение

Описание

155

EGTS_PC_IO_ERROR

Ошибка ввода/вывода

156

EGTS_PC_NO_RES_AVA!L

Недостаточно ресурсов

157

EGTS_PC_MODULE_FAULT

Внутренний сбой модуля

158

EGTS_PC_MODULE_PWR_FLT

Сбой в работе цели питания модуля

159

EGTS_PC_MODULE_PROC_FLT

Сбой в работе микроконтроллера модуля

160

EGTS_PC_MODULE_SW_FLT

Сбой в работе программы модуля

161

EGTS_PC_MODULE_FW_FLT

Сбой в работе внутреннего программного обеспечения модуля

162

EGTS_PC_MODULE_IO_FLT

Сбой в работе блока веода/вьеода модуля

163

EGTS_PC_MODULE_MEM_FLT

Сбой в работе внутренней памяти модуля

164

EGTS_PC_TEST_FA1LED

Тест не пройден

Примечание — Пакеты сообщений об ошибках (EGTS PC DECRYPT ERROR. EGTS PC UNS PROTOCOL. EGTSPCJNC.DATAFORM. EGTS_PC_DATACRC_ERROR. EGTS_PC_INC_HEA5ERFORM. EGTS_PC_HEADERCRC_ERROR) предназначены для целей тестирования оборудования и в рабочей версии программного обеспечения и УСВ могут быть исключены.

57

ГОСТ 33465—2015

Приложение Г

(справочное)

Пример реализации алгоритма расчета контрольной суммы CRC16 на языке С Г

Name :CRC-16CCITT Poly : 0x1021 хА16 + хА12 + хА5 + 1 Init : OxFFFF Revert: false XorOut 0x0000

Check: 0x29B1 («123456789»)*/ const unsigned short Crc16Table[256] • {

0x0000.0x1021.0x2042. 0x3063.0x4084. 0x50A5. ОхбОСб. 0x70E7.

0x8108.0x9129.0xA14A. 0xB16B. 0xC18C. OxOIAD. 0xE1CE. 0xF1EF.

0x1231.0x0210. 0x3273. 0x2252. 0x52B5. 0x4294.0x72F7, 0x62D6.

0x9339. 0x8318.0xB37B, 0xA35A. 0xD3BD. 0xC39C. 0xF3FF. ОхЕЗОЕ.

0x2462.0x3443. 0x0420. 0x1401. 0x64E6. 0x74C7. 0x44A4. 0x5485.

0xA56A. 0xB54B. 0x8528. 0x9509. 0xE5EE. 0xF5CF. 0xC5AC. 0x0580.

0x3653. 0x2672.0x1611.0x0630.0x7607. 0x66F6.0x5695. 0x46B4.

0xB75B. 0xA77A, 0x9719. 0x8738. 0xF7DF. 0xE7FE. 0x0790.0xC7BC.

0x48C4, 0x58E5. 0x6886. 0x78A7.0x0840. 0x1861. 0x2802. 0x3823.

0xC9CC. 0xD9ED. 0xE98E. 0xF9AF. 0x8948.0x9969. 0xA90A. 0xB92B.

0x5AF5. 0x4AD4, 0x7AB7. 0x6A96.0x1A71. 0x0A50. ОхЗАЗЗ. 0x2A12,

OxDBFD. OxC80C. OxFBBF. ОхЕВЭЕ, 0x9B79. 0x8B58. ОхВВЗВ. OxABIA.

ОхбСАб, 0x7C87. 0x4CE4.0x5CC5. 0x2C22. ОхЗСОЗ. 0x0060. 0x1 C41.

OxEOAE. OxFOBF. OxCOEC. OxDDCO. 0xAD2A. OxBOOB. 0x8D68.0x9D49.

0x7E97. ОхбЕВб. 0x5ED5, 0x4EF4. 0x3E13. 0x2E32. 0x1 E51.0x0E70.

0xFF9F. OxEFBE. OxDFDD. OxCFFC. OxBFIB. 0xAF3A. 0x9F59. 0x8F78.

0x9188.0x81A9. OxBICA. OxAIEB. ОхОЮС. 0xC12D, 0xF14E. 0xE16F.

0x1080. OxOOAl. 0x3OC2. 0x2OE3.0x5004. 0x4025. 0x7046. 0x6067.

0x83B9.0x9398. 0xA3FB. ОхВЗОА. ОхСЗЭО. 0xD31C. 0xE37F. 0xF35E.

0x02B1.0x1290. 0X22F3.0x3202. 0x4235. 0x5214.0x6277. 0x7256.

OxBSEA. 0xA5CB. 0x95A6.0x8589. 0xF56E. 0xE54F. 0xD52C. 0xC50D.

0x34E2.0x24C3.0x14A0, 0x0481.0x7466. 0x6447. 0x5424. 0x4405.

0xA7DB. 0xB7FA. 0x8799. 0x97B8. OxE75F. 0xF77E. 0xC71D. 0xD73C.

0x2603. 0x36F2. 0x0691. 0x16B0. 0x6657. 0x7676. 0x4615. 0x5634.

0xD94C. 0xC96D. 0xF90E. 0xE92F. 0x99C8.0x89E9. 0xB98A. ОхАЭАВ,

0x5844.0x4665. 0x7806. 0x6827. 0x18C0.0x08E1.0x3882.0x28A3.

OxCB7D. OxDB5C. OxEBSF. OxFBIE. 0x8BF9. 0x9BD8. OxABBB. ОхВВЭА.

0x4A75.0x5A54. 0x6A37. 0x7A16. OxOAFI. 0x1 ADO. Ox2AB3.0x3A92.

OxFD2E. OxEDOF. 0xDD6C. 0xCD4D. OxBDAA. OxADSB. 0x9DE8. Ox80C9.

0x7C26. 0x6C07, 0x5C64, 0x4045, 0x3CA2.0x2083. OxICEO. OxOCd.

OxEFIF, OxFF3E, 0xCF5D. 0xDF7C. 0xAF9B. OxBFBA. 0x8FD9. 0x9FF8.

0x6E17.0x7E36. 0x4E55. 0x5E74. 0x2E93.0x3EB2. OxOEDI. 0x1 EFO):

unsigned short Crc16(unsigned char ‘ pcBlock, unsigned short len) { unsigned short crc - OxFFFF; while (len-)

crc - (crc « 8)A Crc16Tabte((crc » 8)A *pcBlock++|; retumcrc;}

58

ГОСТ 33465—2015

Приложение Д

(справочное)

Пример реализации алгоритма расчета контрольной суммы CRC8 на языке С Г

Name : CRC-8

Ро»у : 0x31 хА8 ♦ хА5 + хЛ4 +1 trwl : OxFF Revert: false XorOut: 0x00

Chech: 0xF7 (“123456789")

7

const unsigned char CRC8Tabte(256) - {

0x00. 0x31.0x62.0x53.0xC4.0xF5. 0xA6.0x97.

0xB9. 0x68. OxOB. OxEA, 0x70.0x4C. 0x1F. 0x2E.

0x43. 0x72. 0x21.0x10.0x87. 0xB6. 0xE5. 0x04.

OxFA. OxCB. 0x98. 0xA9. 0x3E. 0x0F. 0x5C. 0x60.

0x86. 0xB7. 0xE4. 0x05.0x42.0x73, 0x20. 0x11.

0x3F. OxOE. 0x50. 0x6C. OxFB. OxCA. 0x99.0xA8.

0xC5. 0xF4. 0xA7.0x96. 0x01. 0x30.0x63.0x52.

0x7C. 0x40. Ox IE. 0x2F. 0xB8. 0x89. OxDA. OxEB.

0x30. OxOC. OxSF, 0x6E. 0xF9. 0xC8. 0x9B. OxAA.

0x84. 0xB5. 0xE6. 0xD7.0x40.0x71.0x22. 0x13.

0x7E. 0x4F. 0x1C. 0x20. OxBA. 0x8B. 0x08. 0xE9.

0xC7. 0xF6. 0xA5. 0x94. 0x03. 0x32.0x61.0x50.

OxBB. 0x8A. 0x09.0xE8.0x7F. 0x4 E. 0x10.0x2C.

0x02. 0x33, 0x60.0x51.0xC6.0xF7, 0xA4.0x95.

0xF8.0xC9. ОхЭА. OxAB. Ox3C. 0x00. Ox5E. 0x6F.

0x41.0x70. 0x23.0x12.0x85. 0xB4. 0xE7. 0x06.

0x7A. 0x4B. 0x18. 0x29. OxBE. OxSF, OxDC. OxED.

OxC3. 0xF2. OxA1.0x90. 0x07. 0x36.0x65.0x54.

0x39. 0x08, 0x58. ОхбА. OxFD. OxCC. 0x9F. OxAE.

0x80. OxB1. 0xE2. 0x03. 0x44.0x75. 0x26. 0x17.

OxFC. OxCO. 0x9E. OxAF. 0x38. 0x09. Ox5A. 0x6B.

0x45. 0x74. 0x27.0x16.0x81. OxBO. OxE3. OxD2.

OxBF. Ox8E. OxDD. OxEC. Ox7B. 0x4A. 0x19. 0x28.

0x06. 0x37. 0x64.0x55. OxC2.0xF3. OxAO. 0x91.

0x47. 0x76. 0x25.0x14.0x83. 0xB2. OxE1. OxDO.

OxFE. OxCF. 0x9C. OxAO. 0x3A. OxOB. 0x58.0x69.

0x04. 0x35. 0x66.0x57. OxCO. OxF1. 0xA2.0x93.

OxBO. 0x8C. OxOF. OxEE. 0x79.0x48. Ox1B. Ox2A.

OxC1. OxFO. OxA3.0x92. 0x05. 0x34.0x67.0x56.

0x78. 0x49. Ox1A. 0x2B. OxBC. 0x80. OxOE. OxEF.

0x82. 0xB3. OxEO. 0x01.0x46.0x77. 0x24. 0x15.

0x3B. OxOA. 0x59. 0x68. OxFF. OxCE. 0x90. OxAC

}:

unsigned char CRC8(unsigned char ‘IpBlock. unsigned char ten)

{

unsigned char crc - OxFF: while <len~)

crc - CRC8Tabie{crc A •|pBlock++): return crc:

}

59

ГОСТ 33465—2015

Приложение Е

(справочное)

Таблицы кодировки символов

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

0

1

2

3

4

5

6

7

СО

9

А

в

С

D

Е

F

0

С061

ООО

осе?

:хч

хм

ОЗУ

оссо

ХМ

;<*>

хс*

хо:

Ж

004С

1

х':

ей*

й.';

V*4

;:м

«С'«

W

«*#

X’*

Х*К

х*с

X*?

ееч

«14

2

1

п

#

$

%

&

1

(

)

*

+

»

.

0

/

«он

>;«

ХМ

0«Г

хз»

мм

«в»

«<

Х*0

«ом

С««

3

0

1

2

3

4

5

6

7

8

9

9

<

s

>

*>

\У.

«0)1

СС34

....

«av

А»

/ '■*

X*

Ж 30

«вес

е»у

4

@

А

В

С

I)

Е

F

G

Н

I

J

К

L

м

N

О

«Ч.

Mil

х*;

ХЛ4

ум

>4*

«*.•

V4t

»*4>

*1 44

.<*4*

хле

Л 4*

еом

ХА*

5

Р

Q

К

S

т

и

V

VV

X

Y

Z

[

\

]

А

.«.* *

УА‘

X*-*

V4

>•*

««*>

хм

сем

*•<!*

«ем

ичх

6

ч

а

1)

с

(1

е

Г

g

h

i

j

к

1

m

п

о

00*1

.ом

...е*

УЖ

-i.<4

></

.ом

.<Х*

ОМС

сом

7

р

ч

г

S

t

и

V

W

X

У

Z

{

1

>

А*

> ’«

;:*з

Л 4

XI

«V

X't

*?

<•0

ем

ее»

со

:л*.

ом>

S-X.*

л;«з

.ем

хм

ее».*

хм

ут

ХМ

;«ч

X4L.

ееи

гг»*

«ей

ts*>

:ои

мм

еег

хм

.ом

>4С

:ол

«ем

:ov

А

4

(f

£

а

¥

;

§

м

©

a

«

-

х**

•X«*i

Хм

V41

хм

4MI

хм

ХМ

ОСА*

Хлв

0С4С

село

«04

«ом

В

о

±

2

д

*

Р

И

1

о

»

W

в

<,

же:

оса<

xt:

же:

>£4

:;и

х<*

с«.'

ХС4

XOJ

х*л

ХвА

Х4С

х»о

вом

сом

с

к

А

*

А

А

А

А

л

6

А

с

к

Ё

Ё

Ё

1

f

i

]f

сое»

Ол «

:с*. з

Ж».4

хо

«.«

эм1

04 ♦

V* А

v>.*

»:с

эхо

axi

сос»

D

4)

N

0

6

А

О

б

б

X

0

ч

V

й

0

0

Р

8

«0^

чи*

•Ч 3

Хч-4

лее

ХС4

ОХУ

»»

«со»

се и

•лес

оеос

«ее*

ч

*

А

ш

о

ч

А

ч

*

А

Е

а

а

а

а

a

a

Ж

ч

е

е

е

е

1

I

1

1

1

0К»

«ч.

^ * 1

••И

«'

хы

«ос*

я* ft

мС

РАО

«еч«

•*{*

F

0

п

6

6

А

О

б

б

0

й

*

и

й

«4

U

у

•><:

ее*»

VI)

:<*з

* .*4

хг:

У.* А

щеп

«и

хо

X/ +

> #к*

«ем

tiX#

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

60

ГОСТ 33465—2015

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

0 1 2

3

4

5

6

7

8 9 А В С D Е F

Рисунок Е.2 — Кодировка символов латинского и кириллического алфавитов

0

1

2

3

4

5

6

7

8

9

А

в

с

D

Е

F

т'

0QU

WC)

ХМ

ММ

оси

;«х»

хм

XCJ

ХАА

ж»

мс

3X0

ом

«0»

«О

00*1

1

••о, ч**

K'J

ХМ

ос*

«♦с

х*с

хз

««

401'

и

#

$

%

&

1

(

)

*

+

»

.

/

>•;:

СО'

>::з

Хо'1

х;с

ЯСС

х«

гео

094

осс*

0

1

2

3

4

5

6

7

8

9

*

»

9

<

=

>

7

s'

«><

ЛЧ

•*д

У J

х>»

0*У

?0*1

ч>:

vx>

:•«

(ОН

@

А

В

С

D

Е

F

G

н

I

J

к

L

м

N

0

«ОС’

:<л:

С41

.C4I

:м*

м<

*'4*

;<4>

\4»

:о**1

Х4:<

«о»

Р

Q

К

S

Т

и

V

W

X

Y

Z

[

\

]

л

«*:

«и

со;

W*

:ч*.

скч

V4

и? с

ж*?

у/,г

s

а

ь

с

d

е

f

R

h

I

j

к

1

m

п

О

АЛ.

1Л?

ffl

;л*.(

У»/

>40

::v

40«

Р

q

г

S

t

и

V

W

X

У

Z

{

}

**

> *:

У. *0

«•}

> *«

:< •«

хм

XI*

N4

((Ш

А*.

мм

оае

XCi

кв

ХМ

.и*

хм

XV

мч

осо

сом

>♦:

«0*1

ож

ММ

ЯМ

13И

мм

>•»

XV

V+A

>*:

4VO

((Ot

Ё

ъ

<

Г

S

I

I

J

Л

Ъ

К

у

и

ХАТ

«01

их

мс>

:*м

••♦и

«м

им

и 4

ММ

>

**ч.

ХА?

ЧА

о*

А

Б

В

Г

Д

Е

Ж

3

И

Й

К

Л

м

н

О

П

м*:

МИ

М’«

им

M*l

мн

ич

и**

им

им

U‘i'

и*с

им

«1»

Р

С

Т

У

Ф

X

и

ч

ш

Щ

ъ

ы

Ь

Э

Ю

я

ип

мл

и;*

МЛ

мл

и,'

м;«

мл

ил

м-г'

4^

м«

ом

ои<

а

б

в

г

д

е

ж

3

И

Й

к

л

м

н

0

Л

«СИ

их

мч

4>1

и И

ии

ии

*^оэ

ии

ж*э

их

м»

MX

«У

Р

С

т

У

Ф

X

ц

ч

ш

ш

ъ

ы

ь

э

to

Я

’*л:

ми

(4«2

Ы«>

U4I

ии

U4C

и**

М«<

М4»

и**

М«С

U4C

МО

44»

04'

м

,

,

*

N-

е

1)

г

е

S

1

1

J

л>

н>

п

К

§

У

и

ОМ

ии

им

им

им

ми

•иг

им

ии

:*и*

•и«

ХА*

ом

МУ

61

ГОСТ 33465—2015

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

0

1

2

3

4

5

6

7

8

9

А

в

С

D

Е

F

0

сев1

«в

м:з

от

мм

мм

МО?

мм

то

мм

ом*

ом;

«00

ом«

м«

1

л'1

ее»?

хм

Nil

Л-1

ем?

«■4

OOU

«•о

х*с

м-с

2

!

и

#

$

%

&

1

(

)

*

+

»

/

мл

0М<

«1

:<н

в»?

«о»

к»

хль

*;;а

;«о

омг

«С

3

0

1

2

3

4

5

6

7

8

9

4

<

>

•>

У,’.‘

ми

*•*53

мм

г»: у»

ММ

ом г

Ж»

ООН

«>Л

х*с

Я»

*>:х

ty. :*

4

@

А

В

С

О

К

F

G

н

I

J

К

L

м

N

О

«0И

л*:

УА>

ОСИ

мм

ж«е

ом?

М*1

;<4Р

ООН

««S

АС

0*.4f

А»

5

Р

Q

К

S

Т

и

V

W

X

Y

Z

[

\

1

Л

МЛ

«61

XV

\*<»Л

осы

ш

ом?

ООО*

■Ж'.’

У/С

ГУЛ

С*Ч«

6

а

Ь

с

d

е

f

g

h

i

j

к

1

т

п

О

Ж

«е»<

А?

С‘ХО

МИ

УМ

Х<*

Сч**

МО»

•м

004*

УлА

УМ

iv«*

7

Р

q

Г

S

t

и

V

w

X

У

г

{

>

0+

>. *1

о: \

я*з

оом

МП

ОМ?

Ж?1

у •>

»•*

XX

:с -г

с:ч

со

ОМ'

««

•:<«

мм

«н

«и

ом?

ОМ»

моо

004*

1W

‘Л4

УК

Г.’Л

ом»

9

СОИ

мм

:-зо*

:«е

мл

'.•*9

:<*и

та

>*С

:ок

ож

0У*

А

*

£

П

¥

J

§

••

©

X

«

ш

®

ха:

СГЛЗ

MU

«А*

«Д6

ООО

Я*!

ООО?

«*9

»*с

К*0

4СА1

>У»

В

О

+

2

3

0

Р

и

>

1

»

•л

%

о:<5

«•*

0С«С

х«

VXA

5С?6

ООП

КМ

ом»

ом?

осея

тс

УЛО

С

D

ш

N

2

Л

*1

л

*1

t

п

V

э

1

2

>

а

]

ууу

«01

«оо

МЛ

МО?

V-X4

ж»

ООО*

И-С

:',л

у,1ч

F

2

V

V

<1

D

V

р

л

л

■-'У. С

М«1

9Я?

«<3

<40

4U5

«40

М’

9KI

94»

oot*

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

62

ГОСТ 33465—2015

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

(1]    Технический регламент Таможенного союза о безопасности колесных транспортных средств ТР ТС (018/2011) (Утвержден решением Комиссии Таможенного союза от 9 декабря 2011 г. N9 877 (в редакции, принятой решение*! Совета Евразийской экономической комиссии от 30.01.2013 N9 6)

(2]    ИСО/МЭК 7498-1- 94 Информационные технологии. Взаимодействие открытых систем. Базовая эталон

ная модель. Часть. 1. Базовая модель (Information technology — Open Systems Interconnection — Basic reference model. Part 1: The basic model)

(3] ETSITS 126 267    Группа технических спецификаций услуги и системные аспекты; передача данных

(3GPPTS 26.267)    при экстренном вызове (eCail); тональный модем: общее описание, издание 8 (Tech

nical Specification Group Services and System Aspects: eCalt Data Transfer In-band modem solution: General description. Release 8)

(4] ИСО/МЭК 10967-1:2012 Информационные технологии. Арифметика, не зависимая от языка. Часть 1. Арифметические операции с комплексными целыми числами и с плавающей запятой (Information technology — Language independent arithmetic — Pari 1: Integer and floating point arithmetic)

(5] GSM 03.38 (ETS 300 628)

(6) GSM 03.40 (ETS 300 536)

Правила кодирования: структура алфавитов и языке», используемых при передаче сервиса коротких сообщений (Digital celutar telecommunication system (Phase 2): Alphabets and language-specific information)

Правила отправки и приема сервиса коротких сообщений (Digital cellular telecommunication system (Phase 2)

63

ГОСТ 33465—2015

УДК 656.13:004:006.354    МКС 33.020

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

64

Редактор А.К. Бэздов Технический редактор В.Ю. Фотиева Корректор М.В. Бучная Компьютерная верстка Е.Е. Кругова

Свано а набор 22.12.2016. Подписано в печать 11.01.2017. Формат 60 *64Vg, Гарнитура Ариал Уел. печ. п. 7.90. Уч.-мд. и. 7.15. Тираж 25 э«.    Зак.42.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта.

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ*. 12399S Москва. Гранатный пер.. 4.