allgosts.ru33. ТЕЛЕКОММУНИКАЦИИ.АУДИО-И ВИДЕОТЕХНИКА33.070. Подвижные службы

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

Обозначение:
ГОСТ Р 54619-2011
Наименование:
Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протоколы обмена данными автомобильной системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях
Статус:
Действует
Дата введения:
09/01/2012
Дата отмены:
Заменен на:
-
Код ОКС:
33.070.40

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



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ


ГОСТ Р 54619— 2011


НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

ПРИ АВАРИЯХ

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

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

Предисловие

Цегм и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения стандартов организаций — ГОСТ Р1.0—2004 «Стандартизация в Российской Федерации. Основные положения»

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

1    РАЗРАБОТАН Открытым акционерным обществом «Навигационно-информационные системы» (ОАОяНИС»)

2    ВНЕСЕН Техжческим комитетом по стандартизации ТК 363 «Радионавигация»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 8 декабря 2011 г. Ne 754-ст

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

•    Технические требования (TS) Европейского института стандартов электросвязи (European Telecommunications Standards Institute. ETSI) и партнерской Ассоциац>ы групп телекоммуникационных компаний (3rd Generation Partnership Project (3GPP) к системе и протоколам передачи данных применительно к общеевропейской системе еСаВ:

•    Технические требования (TS) Европейского института стандартов электросвязи (European Telecommunications Standards Institute. ETSI) к цифровым телекоммуникационным сетям в части сервиса отправки и приема коротких сообщений

5    ВВЕДЕН ВПЕРВЫЕ

Информация об изменениях к нестоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты». а текст изменений и поправок — в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая инфор-ияцня уяяЛпипяяпя п тялсптк! ра’шящяюгю) тятя* я 1мфприяц1Юн«1Ы1С11стямя пбщярп попкюяяния— на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет

©Стандаргуыформ. 2013

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

Содержание

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

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

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

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

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

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

Введение

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

Система экстренного реагирования при авариях «ЭРА-ГПОНАСС» предназначена для снижения тяжести последствий дорожно-транспортных происшествий и иных чрезвычайных ситуаций на дорогах Российской Федерации посредством уменьшения времени реагирования экстренных оперативных служб.

Настоящий стандарт описывает протокол обмена данными между автомобильной системой вызова экстренных оперативных служб и инфраструктурой оператора системы «ЭРА-ГПОНАСС» и связанный с ним протокол поддержки услуг, включая базовую услугу экстренного реагирования при авариях.

Настоящий стандарт предоставляет все необходимые данные о формате и правилах передачи сообщений и должен использоваться для разработки подсистем передачи данных на стороне автомобильной системы вызова экстренных оперативных служб и оператора системы «ЭРА-ГПОНАСС».

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

ГОСТР 54620—2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях Автомобильная система вызова экстренных оперативных служб. Общие технические требования

ГОСТ Р 54721—2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Общий порядок оказания системой базовой услуги

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

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

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

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

•    производителями автомобильных систем экстренного реагирования при авариях (терминалов «ЭРА-ГПОНАСС»):

•    автопроизводителями.

•    оператором системы «ЭРА-ГПОНАСС»:

•    разработчиками и поставщиками услуг на основе навигационно-информационной платформы систе-IM «ЭРА-ГПОНАСС»

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

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

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

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

Global navigation satellite system.

Accident emergency response system.

Protocols of data transmission from in-vehicle emergency call system to emergency response system infrastructure

Дата введе+ыя — 2012—09—01

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

Настоящий стандарт распространяется на систему экстренного реагирования при авариях «ЭРА-ГЛОНАСС * (далее — система).

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

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

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

ГОСТ Р ИСО/МЭК 7498-1—99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

ГОСТ Р 52928—2010 Система спутниковая навигационная глобальная. Термины и определения

ГОСТ Р 54620—2011 Гпобагъная навигационная спутниковая система. Система экстренного реагирования при авариях. Автомобильная система вызова экстренных оперативных служб. Общие технические требоеажя

ГОСТ Р 54721—2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Общий порядок оказания системой базовой услуги

ГОСТ 7.75—97 Система стандартов по информации, библиотечному и издательскому делу. Кеды наименований языков

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

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

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

3.1    В настоящем стандарте применены термины по ГОСТ Р 52928. ГОСТ Р ИСО/МЭК 7498*1. ГОСТ Р 54620, а также следующие термины с соответствующими определениями:

3.1.1    автомобильная система вызова экстренных оперативных служб «ЭРА-ГЛОНАСС»; АС. Система, устанавшеаемая на колесном транспортном средстве соответствующей категории и предназначенная для определения местоположения и параметров движения транспортного средства по сигналам глобальной навигационной спутниковой системы ГЛОНАСС или ГЛОНАСС совместно с другими ГНСС. передачи сообщения о транспортном средстве при дорожно-транспортном происшествии и обеспечения двухсторонней голосовой связи с экстренными оперативными службами.

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

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

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

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

Примечание — Аналогом системы «ЭРА ГЛОНАСС» является общеевропейская система еСаН (emergency call), с которой система «ЭРА-ГЛОНАСС» гармонизирована по основным фужциональкым свойствам (использование тонального модема как основного механизма передачи данных: унифицированные состав и формат обязательных данных, передаваемых в составе МНД: единообразные правила установления и завершения двустороннего голосового соединения с лицами, находящимися в кабине трмюпортчого сродства, идр.}.

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

3.1.7    система-112: Система обеспечения вызова экстренных оперативных служб по единому номеру «112».

3.1.8    единый номер «112»: Единый номер вызова экстренных оперативных служб, установленный в российской системе и плане нумерации.

3.1.9    оператор системы экстренного реагирования при авариях «ЭРА-ГЛОНАСС» (оператор системы): Юридическое лицо, осуществляющее деятельность по эксплуатащы системы «ЭРА-ГЛОНАСС». в том числе по обработке информации, содержащейся в ее базе данных.

3.2 В настоящем стандарте применены следующие обозначения и сокращения НЛС    —    навигационно-информационные системы;

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

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

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

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

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

1C    —    транспортное средство;

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

цифровая

подпись

ЭРА

СР-1251

CRC-8{16)

DNS

eCali

EGTS

FTP

IP

GSM

HTTP

IMAP

ISDN

Utde-endian NGTP

OSI


PDU

POP3

SC

SIM

SME

SMS

SMSC

SMTP

TCP

IMP

telnet

UDP


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

CodePage СР1251 (набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows);

Cyclic Redundancy Code (циклический избыточный код);

Domain Name System (система доменных имен);

Emergency Call (общеевропейская система экстренного реагирования при авариях);

Era Glonass Tetemafccs Standard (телематический стандарт для системы «ЭРА-ГЛОНАСС»); Fie Transfer Protocol (протокол передачи файлов);

Internet Protocol (межсетевой протокол);

Global System for Mobile communications (глобальный цифровой стандарт для мобильной сотовой связи);

HyperText Transfer Protocol (протокол передачи гипертекста);

Internet Message Access Protocol (протокол прикладного уровня для доступа к электронной почте);

Integrated Services Digital Network (цифровая сеть с интеграцией обслуживания): младший байт вперед (порядок следования байт):

Next Generation Telematics Protocol (телематический протокол следующего поколения. Архитектура и концепция построения).

Open Systems Interconnection Basic Reference Model (базовая эталонная модель взаимодействия открытых систем — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов):

Protocol Description Unit (элемент описания протокола):

Post Office Protocol Version 3 (протокол почтового отделения, версия 3):

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

Subscriber Identification Module (модуль идентификации абонента);

Short Message Entity (объекты, способные отправлять и получать SMS-сообщения);

Short Message Service (сервис коротких сообщений):

Short Message Service Center (центр обработки коротких сообщений);

Simple Май Transfer Protocol (простой протокол передачи почты):

Transmission Control Protocol (протокол управления передачей):

Trivial File Transfer Protocol (простой протокол передачи файлов);

TErminaL NETwork (сетевой протокол для реализации текстового интерфейса по сети):

User Datagram Protocol (протокол пользовательских дейтаграмм).

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

4.1    Сетевая модель взаимодействия открытых систем согласно ГОСТ Р ИСО/МЭК749&-1 определяет следующие уровни обмена данными:

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

•    канальный;

•сетевой;

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

•    сеансовый:

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

4.2    В терминах сетевой модели OSI в системе «ЭРА-ГЛОНАСС» для передачи данных между автомобильной системой вызова экстренных оперативных служб и оператором системы используются следующие протоколы:

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

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

Соответствие сетевой модели OSI. стека протоколов TCP/IP и протоколов передачи данных системы «ЭРА-ГЛОНАСС* представлено в таблице 1.

Таблица 1 — Соответствие уровней модели OSI. стека протоколов ТСРЛР и протоколов системы «ЭРА* ГЛОНАСС»

Модель OSI

Стек протоколов TCP/IP

Протоколы ТСРЛР

Протоколы системы «ЭРАГЛОНАСС.

Номер

гроеня

Нэным уровня

Номер

уровня

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

7

Приложений

4

Приложений

. IMAP, telnet. SMTP. DNS.TFTP

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

6

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

данных

5

Сеансовый

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

уроее»

4

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

3

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

TCP. UDP

TCP

3

Сетевой

2

Межсетевой

IP

р

2

Канальный

1

Доступ к сети

1

Физический

4.3    Настоящий стандарт устанавливает требования к следующим видам протоколов обмена информацией между элементами системы «ЭРА-ГПОНАСС»:

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

•    протокол уровня поддержки услуг, включая базовую услугу, оказываемую системой «ЭРА-ГЛО-НАСС».

Примечание — Описание базовой услуга, оказываемой системой «ЭРА-ГПОНАСС». приведено е ГОСТ Р 54721.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.5.2    Мношбэйювые 1ипы данных USHORT, UINT. ULONG, FLOAT и DOUBLE иинользукл порндок следования байт litfle-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

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

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

Тип данных

Размер. байт

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

Огмсание

INT

4

Минус 2147483648...гиеос 2147483647

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

FLOAT

4

±1.2 Е - 38...3.4 Е + 38

Дробное «мело со знаком

DOUBLE

в

±22 Е-308 ...1.7 Е +308

Дробное «мело со хаком

STRING

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

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

BINARY

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

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

ARRAY OFTYPE

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

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

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

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

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

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

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

Лгкчмтт уровня под-

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

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

держки услуг

уровня поддержки услуг 1

Схема 1 — Состав пакета протокола транспортного ypoatn

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

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

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

Бит 7 I Бит в I Бит S I Бит 4 Бит 3

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

Тип

Тип ДЗТИШХ

PiNtep, быт

PRV (Protocol Version)

M

BYTE

1

SKID (SeartyKey ID)

м

BYTE

1

PRF (Prefix) RTE ENA

CMP | PR

м

BYTE

1

H. (Header Length)

м

BYTE

1

HE (Header Encoding)

м

BYTE

1

FDL (Frame Data Length)

м

USHORT

2

РГО (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. НЕ. FDL. РЮ. РТ. 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>. определяющего ее адрес, по которому данная АС зарегистрирована

ENA (Encryption Algorithm)

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

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

Обохиачеиие параметр* (norm)

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

CMP (Compressed)

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

PR (Priority)

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

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

01    — высокий;

10    — средний;

11    — нижмй.

Установка большего приоритета позволяет передавать пакеты, содержащие срочные данные, такие, например, ка* пакет с минимальным набором данных базовой услуги «ЭВА-ГЛОНАССв игы данные о срабатывании сигнализации на транспортном средстве. При получении пакета диспетчер, анализируя данное попе, проводит маршрутизацию пакета с более высоким приоритетом быстрее, чем пакета с низким приоритетом, тем самьм достигается более оперативная обработка при наступив**** критически важных событий

HL

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

HE

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

FDL

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

РЮ

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

PT

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

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

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

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

2    — EGTS_PT_SK3NЕD_APPOАТА {пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью)

PRA

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

RCA

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

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

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

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

TTL

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

HCS

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

SFRD

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

SFRCS

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

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

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

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

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

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

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

5.6.22 Структура данных пакета EGTS_PT_R£SPONSE

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

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

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

5.62.4    На каждый пакет типа EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA. поступающий от АС на телематическую платформу или от нее на АС. должен быть отправлен пакет типа EGTS_PT_RESPONSE. содержащий в поле PIO номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA.

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


А — маршрутизация я отрава пакета ма другую телеыатжчесхув платформу. В — обработка даиямх протокола у роют

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


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

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

Тип

Тип ДЗТИШХ

Размер, байт

SDR 1(Service Data Record)

О

BINARY

9. .65517

SOR 2

О

BINARY

9. .65517

...

SDRn

О

BINARY

9...65517

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

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

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

Тип

Тип дммх

Размер, байт

RPID (Response Packet ID)

М

USHORT

2

PR (Processing Resist)

М

BYTE

1

SOR 1 (Service Data Record)

О

BINARY

9...65517

SDR 2

о

BINARY

9...65517

...

SDRn

о

BINARY

9...65517

Примечания

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

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

3    Струм ура 3DR 1. SDR 2, SDRn — структуры. мцеичим инфоуииацию ууццчи '* УУ1*Ч,М|“* yuiyi. Тмних структур может быть одна или неооолько. идущих одна за другой

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

Бит 7 Бит 6 Бит S Бит 4 Бит 3 Бит 2 Бит 1 | Бит 0

Тип

Тип »1«м«

Размер, байт

SIGL(Signati*e Length)

М

SHORT

2

SfGD (Signature Data)

О

BINARY

0...512

SDR 1 (Service Data Record)

О

BINARY

9...65515

SDR 2

о

BINARY

9...65515

...

...

SDRn

о

BINARY

9...65515

Примечания

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

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

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

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

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

передачи данных

5.7.1    Структура SMS-сообщения

При использовании SMS для передачи пакетов данных протокола транспортного уровня используется режим ГОи (2). [3]. Режим PDU позволяет передавать не только текстовую, но и бинарную информацию через сервис SMS оператора сотовой связи GSM. Описываемый протокол транспортного уровня оперирует бинарными данными, поэтому режим POU наиболее подходит для использования SMS в качестве резервного канала передачи транспортного уровня.

5.7.1.1    Для переданы SMS-сообщения используется байтовая кодировка. Формат SMS-сообщения для отправки в режиме POU представлен в таблице 8 и использует структуру, описанную в [3. раздел 9].

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

Бит 7

Бит 8

Бит 5

Бит 4 Вит 3

Бит 2 Бит t 1 Бит 0

Тип

Размер, байт

SMSC.AL (SMSC Address Length)

М

1

SMSC.AT (SMSC Address Type)

О

0.1

SMSC.A (SMSC Address)

о

0.6

TP_RP

TPJJDH1

TP_SRR

TPVPF

TP_RD | TP_MTI

м

1

TP_MR (Message Reference)

м

1

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

Бит 7 Бит в Бит S Бмт 4 Бит Э Бит 2 Бит t | Бит 0

Tma

Размер, байт

TP_DA_L (Destination Address Length)

M

1

TP_DA_T (Destination Address Type)

M

1

TP_DA (Destination Address)

M

6

TP_PID (Protocol Identifier)

M

1

TP_DC5 (Data Coding Schema)

M

1

TP.VP (Validity Period)

о

0.1. 7

TPJJDL (User Data Length)

M

1

TP.UD (User Data)

о

0...140

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

- SMSC.AL — длина полезных данных адреса SMSC в октетах.

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

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

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

•    ТР_МТ( (Message Type Indicator)—тип сообщения (должен содержать бинарное значение 01);

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

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

•    TP_3RR (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 представлены в таблице 10:

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

•    TP_PI D—идентификатор протокола (должен содержать значение 00):

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

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

•    TPJJDL — длина данных сообщения из поля TP.DL. в байтах для используемой &-битной кодировки:

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

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

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

Описание

0

0

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

1

0

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

0

1

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

1

1

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

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

Бит 7

Бит б

Бит S

Бит 4

Бит 3

Бит 2

Бит 1

Бит 0

Размер, байт

1

TON

NP1

1

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

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

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

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

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

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

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

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

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

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

•    NPt (Numeric Plan Identification) — тип плана нумерации (применимо для значений поля TON — 000. 001.010). NPI может принимать следующие значения:

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

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

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

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

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

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

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

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

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

Тип

Размер, байт

LUDH (Length of User Data Header)

О

1

IEI «А» (Informatoon-Element-ldentAer «А»)

О

1

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

О

1

IEO «А» (Informabon-Element-Data of «А»)

о

1...П

IEI «В» (Infonnatoon-Elemerrt-Wenrter «В»)

о

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 «N»>

о

1

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

о

1...П

UO (User Data)

м

1...140

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

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

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

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

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

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

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

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

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

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

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

к)    ЕО—FF — зарезервировано:

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

•    1ЕО «А». IED «В», IED «N»—данные информационных элементов «А». «В» и «N* соответственно:

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

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

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

Бит 7

Бит в

Бит 5

Бит 4

Бит Э

Бит 2 | Бит T

Бит 0

Тип

Размер. Байт

CSMRN (Concatenated Short Message Reference Number)

м

1

MNSM (Maximum Number of Short Messages)

м

1

SNCSM (Sequence Number of Current Short Message)

Примечания

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

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

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

м

двое знач<

1жен содер

актируется от 1 до 25 дающая ст

1

эмие для всех

жать значения

при отправке 5. Если знэче-орона должна

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

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

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

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

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

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

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

Иимкие

Тип

ааимыд

Дивпаэо*

значений

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

Описание

TL_RESPONSE_TO

BYTE

0...255

5

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

TL_RESEND_ATTEMPTS

BYTE

0...255

3

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

TL_RECONNECT_TO

BYTE

0...255

30

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

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

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

6.1.1    Протокол уровня поддержки услуг предназначен для обеспечения обмена данными между элементами системы «ЭРА-ГЛОНАСС» а целях обеспечения функционирования системы для оказания информационных услуг потребителям. Каждой услуге соответствует отдельный сервис, который является ключевым элементом в рамках системы, построенной с использованием протокола уровня поддержки услуг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запись RID = 1

Запись RID = 2

...

Запись RID = N

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

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

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

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

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

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

Поозаписъ 1

...

Подзапись N

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

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

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

6.6.2~2 Структура записи

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

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

Бит 7 | б*т в | бит S | бит 4 | Бит 3 бит 2 | бит 1 бит 0

Тип

Тип uiwtu

Pхэмер. 6aki

RL (Record Length)

M

USHORT

2

RN (Record Number)

м

USHORT

2

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

Бит 7 I Бит в I Бит 5 I Бит 4 Бит 3

Бит 2

Бит 1

Бит 0

Тип

ТИП ДЭ1ЧЦЖ

Размер, байт

RFL (Record Flags)

M

BYTE

1

SSOD RSOD GRP RPP

TMFE

EVFE

OBFE

OtO (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 — содержит битовые флаги, определяющие наличие в данном пакете полей OID. EVID и ТМ. характеризующих содержащиеся е записи данные:

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

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

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

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

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

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

•    GRP (Group) — битовый флаг, определяющий принадлежность передаваемых данных определенной группе, идентификатор которой указан в поле OID:

а)    1 — данные предназначены для группы;

б)    0 — принадлежность группе отсутствует;

•    RPP (Record Processes Priority) — битовое поле, определяющее приоритет обработки данной записи сервисом:

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

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

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

г)    11 — низкий:

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

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

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

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

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

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

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

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

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

•    ОЮ — идентификатор объекта, сгенерировавшего данную запись или для которого данная запись предназначена (уникальны* идентификатор АС), либо идентификатор группы (при GRP = 1). При передаче от АС а одном пакете транспортного уровня нескольких записей подряд для разных сервисов, но от одного и того же объекта, поле OID может присутствовать только в первой записи, а в последующих записях может быть опущено;

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

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

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

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

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

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

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

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

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

Тип

Тип П1>14||'п

Размер, бЫт

SRT (Subrecord Туре)

м

BYTE

1

SRL (Subrecord Length)

м

USHORT

2

SRD (Subrecord Data)

о

BINARY

0.. .65495

Примечания

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

2    SRL — длта дэмшх в бейтах подэагыси в поле SRD.

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

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

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

<*ппЛци чвштпг«да| [ariCbl ID* 1,.

NK>"NQ


АС


ТП


ПфГМрЭфВННВ М CDQgipiW ЯПОРМШРН [рОДШврКД.1 Ю :Нг..|Л0ДПИРИД' ND = И]

Ответ« еххАцвнив ввторямхаы {«ляс*. 1ID“1]

Понгицццаиш ответа на гасЛдиме аитп|ваец»в» [падпиравд. 110=1]

СплИцивш ипниториж 1 [илиоьЫН С«МИ]

Подтпор^т»НС нВ С00бкт»м»*0«пориже 1 (пСнгаефВД. МИ Os МИ]

СооСцим исжторинш 8 |шиоь Н*2 Ш • М»3

1Уцтв|Щ',нмв чвеоойцвниа навпорта&[лодтаярц. N*2 ID = N*2]



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

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

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

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

Код

Назван»*

Описями*

ДО”

шсэ"

ШСД5'

1

EGTS

AUTH

SERVICE

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

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

+

+

2

EGTS

TELEDATA

SERVICE

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

+

+

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

Код

Назнпае

Описание

ДО'>

ШСЭг'

шсда;

4

EGTS

COMMANDS

SERVICE

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

+

+

9

EGTS

FIRMWARE

SERVICE

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

+

+

10

EGTS

ECALL

SERVICE

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

+

+

+

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

1    АС. испогменная в конфигурации допотитегъного оборудования.

2    АС. исполненная а конфигурации штатного оборудовав» и предназначенная для реалиэащы только базовой услуги системой «ЭРА-ГЛОНАСС».

3    АС. исполненная в конфигурации штатного оборудования и предназначенная для реализации дополнительных. кроме базовой, услуг системой «ЭРА-ГЛОНАСС».

6.7Л Сервис EGTS.AUTH.SERVICE

Сервис EGTS_AUTH_SERVICE применяется для осуществления процедуры аутентификации АС ка стороне телематической платформы, а также для получения учетных данных АС и информации об инфраструктуре на стороне АС (состав и версии программного обеспечения модулей, блоков, периферийного оборудования, информации о транспортном средстве). Сервис должен использоваться АС только в случае работы по протоколу ТСРЛР после создания каждого нового соединения с телематической платформой.

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

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

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

Код

Нажаиме

Описание

0

EGTS_SR_RECORD_RESPONSE

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

1

egts.sr.termjdentity

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

2

EGTS_SR_MODULE_DATA

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

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

Код

Нажато

Описание

3

EGTS_SR_VEH1CLE_DATA

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

4

EGTS_SR_AUTH_PARAMS

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

5

EGTS_SR_AUTH_INFO

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

6

EGTS_SR_SERVTCE_INFO

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

7

EGTS_SR_RESULT_COOE

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

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

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

Бит 7 | Бит 6 | Бит б | Бит 4 | Бит 3 Бит 2 | Бит t Бит 0

Тип

Тип nwniirr

Размер. 6wr

CRN (Confirmed Record Number)

M

USHORT

2

RST (Record Status)

M

BYTE

1

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

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

•    RST — статус обработки записи.

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

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

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

Таблица 19 — Формат подзаписи EGTS_SR_TERM_IDENTiTY сервиса EGTS_Aim-i_SERVTCE

Бит 7 1 Бит 6 1 Бит S I Бит 4 1 Бит 3

Бит 2 | Бит 1

Бит 0

Тип

Тип nwniirr

Размер. 6wr

TID (Terminal Identifier)

M

UINT

4

Rags

M

BYTE

1

MNE BSE NIDE SSRA LNGCE

IMSIE 1MEIE

HDIDE

HDID (Home Dispatcher Identifier)

О

USHORT

2

IMEI (International МоЫе Equipment Identity)

О

STRING

15

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

Виг 7 Бит 6 Бмт S Вит 4 Бит 3 Бит 2 | Бит 1 | Бит 0

Тип

Тип двтыа

Рикер, байт

IMSI (International МоЫв Subscriber Identity)

О

STRING

16

LNGC (Language Code)

О

STRING

Э

NID (Network Identifier)

О

BINARY

э

BS (Buffer Size)

О

USHORT

2

MSISDN (Mobile Stabon Integrated Services Digdal Network Number)

О

STRING

15

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

•    TID — уникальный идентификатор, назначаемый при программировании АС. Наличие значения 0 в данном поле означает, что АС не прошла процедуру конфигурирования или прошла ее не полностью. Дан* ный идентификатор назначается оператором системы «ЭРА-ЛТОНАСС» и однозначно определяет набор учетных данных АС. TID назначается при инсталляции АС как дополнительного оборудования и передаче оператору учетных данных AT (IMS1. IMEI. serial _id). В случае использования АС в качестве штатного устройства НО сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI. IMEI):

•    HOIDE — битовый флаг, который определяет наличие поля НОЮ в подзаписи (если бит равен 1. то поле передается, если 0. то не передается);

•    IMEIE — битовый флаг, который определяет наличие поля IMEI в подзаписи (если бит равен 1. то поле передается, если 0. то не передается);

•    IMSIE — битовый флаг, который определяет наличие поля IMSI в подзаписи (если бит равен 1. то поле передается, если 0. то не передается);

•    LNGCE — битовый флаг, который определяет наличие поля LNGC в подзаписи (если бит равен 1. то поле передается, если 0. то не передается):

•    SSRA — битовый флаг, предназначенный для определения алгоритма использования сервисов (если бит равен 1. то используется простой алгоритм, если 0. то алгоритм запросов на использование сервисов):

•    NIDE — битовый флаг, определяющий наличие поля NID в подэалиси (если бит равен 1. то поле передается, если 0. то не передается):

•    BSE — битовый флаг, определяющий наличие поля BS в подзаписи (earn бит равен 1. то поле передается, если 0. то не передается):

•    MNE — битовый флаг, определяющий наличие поля MSISDN в под записи (если бит равен 1. то поле передается, если 0. то не передается):

•    НОЮ — идентификатор домашней телематической платформы (подробная учетная информация об АС хранится на данной платформе):

•    IMEI — идентификатор мобильного устройства (модема). При невозможности определения данного параметра АС должна заполнять дан ное поле значением 0 ео всех 15 символах:

•    IMSI — идентификатор мобильного абонента. При невозможности определения данного параметра, устройство должно заполнять данное поле значением 0 во всех 16 символах:

•    LNGC — код языка, предпочтительного к использованию на стороне АС. в соответствии с [4]. например. «rus* — русский:

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

•    BS — максимальный размер буфера приема АС в байтах. Размер каждого пакета информации, передаваемого на АС. не должен превышать данного значения. Значение поля BS может принимать различные значения (1024.2048,4096) и зависит от реализации аппаратной и программной частей конкретной АС:

- MSISDN — телефонный номер мобильного абонента. При невозможности определения данного параметра устройство должно заполнять данное поле значением 0 во всех 15 символах (формат описан в HD-

Передача поля НОЮ определяется настройками АС и целесообразна при возможности подключении АС к телематической платформе, отличной от домашней, например, при использовании территориально распределенной сети платформ. При исло/ъэоеании только одной домашней платформы передача НОЮ не требуется.

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

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

Таблица 20 — Формат поля NIO под затеи EGTS_SR_TERM_IDENTTTY сервиса EGTS_AUTH_SERVIC Е

биты 20 .23

Бит 10..19

Биты 0. 9

Тип

Тип данных

Риаид, баш

МСС (МоЫе Country Code)

MNC (МоЫе Network Code)

М

BINARY

3

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

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

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

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

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

Таблица 21— Формат подзаписи EGTS_SR.MODULE.DATA сервиса EGTS.AUTH.SERV1CE

Бит 7 | Бит 6 | Бит S | Бит 4 Бит 3 Бит 2 Бит 1 Бит 0

Тип

Тип датитыж

Ражер, байт

МТ (МогЫе Туре)

M

BYTE

1

VTD (Vendor Identifier)

M

UINT

4

FWV (Firmware Version)

M

USHORT

2

SWV (Software Version)

M

USHORT

2

MD (Motfcation)

M

BYTE

1

ST (State)

M

BYTE

1

SRN (Serial Number)

О

STRING

0...32

D (Debmrter)

M

BYTE

1

DSCR (Description)

О

STRJNG

0...32

D (DefcnHer)

M

BYTE

1

Поля подзаписи SR.MODULE.DATA имеют следующее значение.

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

•    VID — код производителя:

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

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

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

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

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

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

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

6.72.4 Подзапись EGTS_SR_VEHICLE_DATA

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

Таблица 22 — Формат пздзалиси EGTS.SR_VEHfCLE.OATA сервиса EGTS.AUTH.SERVTCE

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

Тип

Тип miiimin

Размер, байт

VIN (Vehicle Identification Number)

M

STRING

17

VHT (VeNcte Type)

M

UINT

4

VPST (Vehicle Prop<Jsion Storage Type)

M

UINT

4

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

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

•    VHT — IM1i рани upi ниш среди iu<j.

а)    биты 31 —5: не используются;

б)    биты 4—<У.;

в)    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 L5eX

р)    1100 — мотоцикл (Class L6e):

с)    1101 — мотоцикл (Class L7e):

•    VPST—тип энергоносителя транспортного средства. Если все биты 0. то тип не задан:

а)    биты 31—6: не используются;

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

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

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

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

в) бит 1:1 —дизель: ж) бит 0:1 — бензин.

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

Таблица 23 — Формат псезаписи EGTS_SR_AUTH_PARAMS сервиса EGTS_AUTH_SERVJCE

Бит 7 I Бит в I Бит 5 I Бит 4 I Бит 3

Бит 2

Бит 1 Бит 0

Тип

Тип п ~»i ■ oiiit

Ражер. байт

FLG (Flags)

M

BYTE

1

— EXE SSE MSE ISLE

PKE

ENA

PKL (Public Key Length)

О

USHORT

2

PBK (Public Key)

О

BINARY

0...512

ISL (identity Sting Length)

О

USHORT

2

MSZ (Mod Size)

о

USHORT

2

SS (Server Sequence)

О

STRING

0...255

D (Deimrter)

О

BYTE

1

EXP (Exp)

о

STRING

0...255

D (Deimrter)

О

BYTE

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•    UNM — имя пользователя.

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

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

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

Таблица 24— Структура под записи EGTS_SR_AUTH_IN FO сервиса EGTS_AUTH_SERVtCE

Бмг 7 | Бит в | виг б | вит 4 Бит 3 вит 2 вит 1 | вит 0

Тип

Тип niwmin

Размер, байт

UNM (User Name)

M

STRING

0...32

О (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_SERVTCE_INFO сервиса EGTS_AUTH_SERVICE

Бит 7 I Бит в I Бит S I Бит 4 I Бит 3 Бит 2

Бит 1 Бит 0

Тип

ТИП ДВ1 ■ ■■ IX

Раэмер, байт

ST (Service Type)

M

BYTE

1

SST (Service Statement)

M

BYTE

1

SRVP (Service Parameters)

м

BYTE

1

SRVA —

SRVRP

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

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

128

EGTS_SST_OUT_OF_SERVICE

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

129

EGTS_SST_DEN1ED

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

130

EGTS_SST_NOCONF

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

131

EGTS_SST_TEMP_UNAVAIL

Сервис врешхаю недоступен

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

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

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

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

Бит 7

Бит в

Бит 5

Бит 4

Бит 3

Бит 2 | Бит 1 | Бит 0

Тип

ТИП ДВ1ЧЫХ

Размер, бит

RCD (ResiJt Code)

М

BYTE

1

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

Для работы в инфраструктуре оператора системы «ЭРА-ГЛОНАСС» АС должен быть назначен уни-кагъный идентифмсатор UNIT JD. которому соответствуют определенные значения IMEI. IMSI и другие учет* ные данные АС. необходимые для осуществления взаимодействия в системе оператора.

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

1)0 пассивном режиме работы АС после нажатия кнопки «Дополнительные функции» и осуществления регистрации АС е сети GSM или UMTS инфраструктура сотового оператора отслеживает появление нового устройства и инициирует отправку ему зашифрованного SMS с учетными данными. Шифрование проводится ключом и алгоритмом, известным данному образцу АС и сохраненным к моменту конфигурирования в хранилище оператора. Для определения ключей и алгоритмов шифрования на стороне АС используются соответствующие поля из заголовка протокола транспортного уровня, а также данные о ключах, зашитых в памяти АС. Учетные данные передаются в виде конфигурационного файла с использованием подзаписи EGTS_SR_SERVICE_FULL_DATA или EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE.

Файл конфигурации должен содержать: параметр EGTS_GPRS_APN (параметры точки доступа для установления GPRS-сессии), параметр EGTS_SERVER_ADORESS. определяющий адрес и порт сервера, с которым необходимо установить ТСРЛР соединение, уникальный идентификатор АС UN[TJD. В конфигурационном файле также могут присутствовать другие параметры, необходимые для работы АС.

Далее АС проводит расшифровку SMS-сообщения, проверяет корректность структур данных, вычисляет и сравнивает с полученными е сообщении значениями контрольные суммы. Если расшифровка и проверка прошли успешно. АС устанавливает GPRS-сессию и соединяется с указанным сервером по ТСРЛР.

После прохождения процедуры аутентификации отправляет подтверждение об успешной конфигурации е виде подзаписи EGTS_SR_RECORD_RESPONSE с кедом EGTS_PC_OK на полученную запись EGTS_SR_SERVICE_FULL_DATA или EGTS_SR_SERV1CE_PART_DATA сервиса EGTS FIRMWARE SERVICE.

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

2) После регистрации АС в сети GSM или UMTS устанавливается GPRS сессия и TCP/IP соединение с сервером, информация об адресе которого уже записана в памяти АС. При прохождении процедуре аугемтификацим инфраструктура оператора амапитирует параметр ИГ) ит ппд.тапигм EGTS_SR_TERM_IDENTITY (таблица 18). ЕслиТЮ имеет значение0. проводится процедура конфигурирования при помощи сервиса EGTS_FIRMWARE_SERVICE. как описано в предыдущем способе, отправляя файл конфигурации с использованием подзаписи EGTS_SR_SERVICE_FULL_DATA или EGTS_SR_SERViCE_PART_DATA. Далее после прихода подтверждения получения конфигурационного файла от АС ей отправляется результат авторизацкм с кодом EGTS_PC_ID_NFOUND. указывающий, что TID = 0 в системе не найден. После этого сервер, не разрывая соединения с АС. ожидает повторной авторизации АС. но уже с корректным параметром TID. Алгоритм такого способа конфигурирования АС представлен на рисунке 5.

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

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

АС



9ш1рктщттт. Ооабтеив 1.0*1 [BQTBJ81^_THWJDEimTY (ТО ■ 0. №. IMSIJ


ftmieqw— СаЬВлтш 2.0 * 1 [EGT8_a^_REC0RD_PESP0N8£na птбн.иыв 1. ID*1]


Файл вгфчурацм.Саойщшм 9. ID*2 [EGTB.SR^SBTYIC^FULL.DATA через GPRS]


Пктсятт*. Свабим» 4.0 • 2 £Е0та_«ИЛЕССПО_Л£8РСГ«£н*сообщаем Л ID■ 2)


Рцттг торимом. ГтиЯцмм fi, О=6 [EOT8_SA_RESULT_CODE - EGrT*_PC_NOT_AtJTH]


Сообщение 6, ID ■3[ECTTB_6R_RECORD_REiBPOH8E м сообаюмв б, D>S]


Запрос твршацж. Сообщение 7,0=4 (EQT8_6a_reRM_l D EKTV П (ТО = кагт*_имп_Ю,

№1 IH9J


пгиш^вди— ГтАщим 8.0*4 [EGTS.Sf^RECORD.RESPONSE на пппЛциме 7. ID ■ 4


RHpibWTCpMaijM. Сообщение 8,0 = 5lEQTa_8R_RESULT_COOe = КЗТЗ.РС.ОК]


Cadtomm 10.0 ■ Б [EGT8_3Rk_R£C0RD_RE8PON8EiMaooemM4&,ID*£]

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


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

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

Получив сообщение с подзаписью EGTS.SR.TERM .IDENTITY телематическая платформа отправляет на него сообщение 2 с подтверждением о приеме EGTS_SR_RECORD_RESPONSE на запись с идентификатором ID. равным 1. Далее в зависимости от настроек (используется шифрование или дополнительный алгоритм авторизации) телематическая платформа отправляет пакет (сообщение 3) с подзаписью EGTS.SR.AUTHPARAM. содержащей параметры, необходимые для осуществления шифрования и/или алгоритма расширенной авторизации. Если шифрование и алгоритм расширенной авторизации не используются. то вместо подзаписи EGTS.SR.AUTH.PARAM телематическая платформа может отправить поддались EGTS_SR.RESULT.CODE с результатом проведения процедуры авторизации АС.

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

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

АС


ТП


СаДдам 1, ID-1 (Е0Т^ДОТВДМ_БЕеттГ4 [EG7Sj9R_MODULE_Om4^..

pEffre_6R_MOOlAJE_QATAJ


UD-1]


Сеа6щмм2. ID*1 IEGT3_8R_RECORD_RE9PONSE т

ГвпЯнршв 3.ID-2 [B3T9_8RJWTH-P«?AM]

Соа6щете4.10 -2 [EOT^.eFUSCORDJCBPONeE т сообщом ЭсЮ»1]

Саддама. ID «3 [ЕШ9_Вр_ЛтН-№0]

садим» в. i d - г [EGra_a^R£ooRD_Rfcapo«ae на еоебщвмм б в ю ■ ц


СоДдат 7, D ■ 4 {EGfTS_£R R££ULT_COCЦ. lEGTS.SR^SERVlCE №01....

[02Та_вВ_8 EHVXJEJ »FO]


Саддам a, ID ■ 4 [EGTajBRJESPOtieE m xotomm 7 о © ■ 4J

C00Qu*m* 0,0 = 5 |£ОТЧ_вЯ_вЕ MKXJNFQ),..., [EtJT8_0Rj8 EHVtOEJ W=0]


Сообща»» 10, ID ■ 6 [ЕвГв.ЯЩЕвРйНвЕ не а»бщм»9 в ID • 6]




Рисунок в — Обмен сообщениями на этапе эеторизэщм АС на телематической платформе

АС затем формирует сообщение 8 с подтверждением на сообщение 7 с ID. равным 4. АС может сформировать сообщение 9 и добавить подзаписи EGTS.SR.SERVICEJNFO. содержащие информацию о требуемых услугах (если используется процедура использования сервисов по запросу) и/или поддерживаемых сервисах на стороне АС.

Далее телематическая платформа создает сообщение 10 с подтверждением на сообщение 9 с Ю. равным 5.

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

В случае если процедура авторизации проходит неудачно (неверные аутентификационные данные АС. запрет доступа данного АС к телематической платформе и т. д.). то после отправки сообщения, содержащего подзапись EGTS.SR.RESULT.CODE с указанием в ней соответствующего кода, телематическая платформа должна разорвать установленное автомобильной системой ТСРЛР соединение.

6.7.3 Сервис EGTS.COMMANDS.SERVICE

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

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

Та б л и ц а 28 — Описание подзаписей сервиса EGTS.COMMAND.SERVICE

Код

Ндэмиие

Описание

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 Бит в Бит S бит 4

Бит 3 Бит 2

Бит i

Бит 0

Тип

Тип датам

Размер, байт

СТ (Command Туре)

CCT (Command С

^onfirmatk

)n Type)

M

BYTE

1

CID (Command Identifier)

М

UINT

4

SID (Source Identifier)

м

UINT

4

ACFE

CHSFE

м

BYTE

1

CHS (Charset)

о

BYTE

1

ACL (Authorization Code Length)

о

BYTE

1

AC (Authorization Code)

о

BINARY

0...255

CD (Command Data)

о

BINARY

0...6525

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

•    СТ — тип команды.

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

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

в)    0011 — CT_MSGFROM — информационное сообщение от АС:

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

д)    0101 — СТ_СОМ — команда для выполнения на АС:

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

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

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

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

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

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

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

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

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

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

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

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

•    SIO — идентификатор отправителя данной команды или подтверждения:

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

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

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

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

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

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

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

а)    0 —СР-1251;

б)    1 — IAS(CCITTT.50yASCN (ANSI Х3.4);

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

г) 3— Latin 1 (таблица Е.1 (приложение Е));

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

6)5—JIS(X 0208-1990);

ж) 6 — Cyrifcc (табл «да Е.1 (приложение Е));

и)    7 — LatMVHetxew (таблица Е.З(приложение Е));

к)    6 — UCS2.

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

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

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

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

Даннов поле может иметь нулевую длину (отсутствовать) в тех случаях, когда в ответ на команду или сообщение для АС не передаются никакие данные.

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

Бит 7 Бит в Бит S Бит 4

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

Тип

Тип miiimin

Размер. б»*т

ADR (Address)

M

USHORT

2

SZ (Size)

ACT (Action)

м

BYTE

1

CCD (Command Code)

м

USHORT

2

DT (Data)

О

BINARY

0...65200

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

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

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

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

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

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

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

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

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

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

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

I юдтверждеиие на ранее переданную команду при с I -с 1 _CUMCONK если с АС передается сопутствующая информация, имеет формат, представленный в таблице 31. Описанная структура содержится в поле CD (таблица 29).

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

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

Тип

ТИП Д31ЧЦД

Размер, байт

ADR (Address)

M

USHORT

2

CCD (Command Code)

M

USHORT

2

DT (Data)

о

BINARY

0..65200

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

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

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

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

6.7.32 Описание команд, параметров и подтверждений Список и описание команд АС представлены в таблице 32.

Значения следующих параметров АС могут быть запрошены, но не могут быть изменены или удалены при помощи сервиса команд; EGTS_UNIT_SERIAL_NUMBER. EGTSJJNIT_HW_VERS»ON. EGTS_UNfT_SW_VERSION. EGTS_UNIT_VENDORJD. EGTSJJNITJMEI.

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

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

Название

■оманды

Код

Тип. ЧМСПО и предельные зиаче*а>« параметров

Описание

EGTS_RAW_DATA

0x0000

EHNARY

(до 65200 байт)

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

EGTS_TEST_MOOE

0x0001

BYTE

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

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

EGTS_CONFIG_RESET

0x0006

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

EGTS_SET_AUTH_COOE

0x0007

BMARY

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

EGTS.RESTART

0x0008

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

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

Название to манды

Коя

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

Описание

EGTS_RAW_OATA

0x0000

BMARY

(до 65200 байт)

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

EGTS SELF TEST RESULT

0x0002

STRING

Сообщемю о результатах самодиагностики. Генерируется АС автоматически без запроса от оператора

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

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

Код

Тип параметра

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

Описание

Радио mute (только для конфигурации дополнительного оборудования)

EGTS_RADK5_MUTE_DELAY

0x0201

NT

0

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

EGTS RADIO UNMUTE DELAY

0x0202

NT

0

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

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

EGTS.GPRS.APN

0x0203

STRING

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

EGTS_SERVER_ADORESS

0x0204

STRING

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

EGTS_SIM_PIN

0x0205

NT

0

РМ код SIM-карты

EGTS AUTOMATIC REGISTRATION

0x0207

BOOLEAN

1

Флаг, разрешающий автоматическую регистрацию SIM в сети после включения питатыя

EGTS_SELFTEST_NTERVAL

0x0208

NT

0

Интервал проведения периодической самодиагностиш. часов. Если эючение установлено в 0. то самодиагностика не проводится

EGTS POST TEST REGISTRATION_T1ME

0x0209

NT

120

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

EGTS TEST MOOE END DISTANCE

0x020A

NT

300

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

EGTS GARAGE MODE BX> DISTANCE

0x0206

NT

300

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

EGTS_GARAGE_MODE_PN

0x020C

ENUM {NONE-0. P1N_1 -1.

PIN.8-8)

0

Лим», сигнализирующая, что система находится в режиме «Автосервис» NONE — нет сигнали-зацю« режима PIN_X — PIN_X линия активная, когда система находится в данном режиме

EGTS TEST MODE WATCHDOG

0x020E

NT

10

Интервал тревожного счетчика в режиме тестированы*, минут

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

Код

Тип параметра

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

Опясаиие

Конфигурация и конфигурационные данные услуг. Пакетная передача данных

EGTS USE GPRS WHITE_LIST

0x0230

BOOLEAN

FALSE

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

EGTS_GPRS_WHITE_LIST

0x0231

ARRAY OF STRING

* ♦ ♦ t «М ^ «•

*« ^ «Р

BM

Hf •• MB «Я

1 • 1

Список сетей, в которых разрешена пакетная передача данных. Если список GPRS_WHITE_UST пуст, то пакетная передача данных запрещена. MCC (Mobile Country Code) 3 символа + MNC (Mobile Network Code)

Режим тестировался

EGTS TEST

REGISTRATION.PERIOD

0x0242

INT

5

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

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

EGTS GNSS POWER OFF.TIME

0x0301

NT

500

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

EGTS_GNSS_DATA_RATE

0x0302

INT/1.2. 5. 10

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

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

EGTS GNSS MIN ELEVATION

0x0303

INT/5 . .15

15

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

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

EGTS UNIT SERIAL NUMBER

0x0400

STRING

Серийный номер устройства

EGTS UNIT HW VERSION

0x0401

STRING

Версия аппаратной платформы

EGTS UNIT SW VERSION

0x0402

STRING

"

Версия программного обеспечения

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

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

Код

Тип параметра

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

Опясаиие

EGTS_UNIT_VENDORJD

0x0403

INT

0

Идентификатор поставщика устройства

EGTSJJNITJO

0x0404

WT

0

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

EGTS_UNJT_MEI

0x0405

STRING

• •

Ноыер IMEI

EGTS UNIT RS485 BAUD.RATE

0x0406

INT

19200

Скорость порта RS485

EGTS UNIT RS485 STOP.BrTS

0x0407

INT

1

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

EGTS UNIT RS465 PARITY

0x0408

INT/0.1.2

0

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

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

1    — проверка типа ООО:

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

EGTS UNIT LANGUAGE,©

0x0410

INT

0

Предпочтительный язык для голосового общения в соответствии с ГОСТ 7.75.

0х5Р— русский

EGTS UNIT HOME Dl SPATCHER.©

0x0411

INT

0

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

EGTS SERVICE AUTH_METHOO

0x0412

INT

1

Метод испогъзования услуг 1—простой метод (подразумевает. что все услуги по умолчание доступны АС):

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

EGTS SERVER CHECK IN_PERIOO

0x0413

NT

30

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

EGTS SERVER CHECK IN.ATTEMPTS

0x0414

NT

5

‘-Мело попыток установления TCP/IP соединения с сервером. по достижении которого будет проведена повторная установка сессии верхнего уровня (GPRS)

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

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

Код

Тип параметра

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

Опясаиие

EGTS SERVER PACKETTOUT

0x0415

INT

5

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

EGTS SERVER PACKET RETRANSMIT ATTEMPTS

0x0416

INT

3

'■Мело попыток повторной отправки меподтверждежого пакета. по достижении которого АС проводит повторную ижциагызэ-цию сессии на уровне TCP/IP

EGTS UNIT MIC LEVEL

0x0417

INT/0...10

8

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

EGTS UNIT SPK

level"

0x0418

INT/0...10

6

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

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

•    EGTS_GPRS_APN;

•    EGTS_SERVER_ADORESS;

•    EGTS_SIM_PIN;

-    EGTS_AUTOMATlC_REGISTRATION:

•    EGTS_SELFTEST_INTERVAL:

•    EGTS_POSTTEST_REGISTRATION_T]ME:

•    EGTS_TEST_MOOE_END_CMSTANCE;

-    EGTS_GARAGE_MOOE_END_DISTANCE;

•    EGTS_TEST_MODE_WATCHDOG;

. EGTSJJSE_GPRS_WHITEJJST:

•    EGTS_GPRS_WHITE_LIST;

-    EGTS_TEST_REGISTRATlON_PERIOO;

•    EGTS_GNSS_POWER_OFF_TIME;

•    EGTS_GNSS_DATA_RATE;

•    EGTSj3NSS_MIN_EL£VATlON:

•    EGTS_UN(T_SERIAL_NUMBER:

•    EGTS_UNfT_HW_VERSION;

•    EGTS_UNIT_SW_VERSION;

•    EGTS_UNfT_VENDOR_ID:

•    EGTS.UNITJD;

•    EGTS_UNfT_LANGUAGE_IO:

•    EGTS_UNIT_IMEI:

•    EGTS_UNIT_HOME_DISPATCHERJD.

6.7.4 Сервис EGTS_FIRMWARE_SERV1CE

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

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

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

Коя

Назаамие

Описание

0

EGTS SR RECORD RESPONSE

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

33

EGTS SR SERVICE PART.OATA

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

34

EGTS SR SERVICE FULL.DATA

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

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

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

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

Тип

Тип дн чих

Размер, байт

ID (Identity)

М

USHORT

2

PN (Part Number)

М

USHORT

2

EPQ (Expected Pets Quantity)

М

USHORT

2

ODH (Object Data Header)

О

BINARY

0...71

OO (Object Data)

м

BINARY

1...65400

Примечания

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

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

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

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

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

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

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

Таблица 37 — Формат заголовка передаваемой сущности подзаписи EGTS SR_SERVICE_PART_DATA сервиса EGTS FIRMWARE SERVICE

Бит 7 Бит в Бит S Бит 4

Бит 3 Бит 2

Бит 1 Бит 0

Тип

ТИП 1ТПЧ||11Г

Размер, байт

ОА (Object Attribute)

M

BYTE

1

ОТ (Object Type)

MT (Modiie Type)

CMI (Component or Module Identifier)

М

BYTE

1

VER (Version)

М

USHORT

2

WOS (Whole Object Signature)

М

USHORT

2

FN (Fie Name)

О

STRING

0...64

0 (Dehmrter)

м

BYTE

1

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

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

•    ОТ—тип сущности по содержанию. Определены следующие значения данного поля;

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

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

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

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

б)    01 — АС:

•    CMI — номер компонента в случае принадлежности сущности непосредственно АС или идентификатор периферийного модуля/порта. подключенного к АС. в зависимости от значения параметра МТ;

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

•    WOS — сигнатура (контрольная сумма) всей передаваемой сущности. Используется алгоритм CRC16-CCnT:

•    FN — имя файла передаваемой сущности (данное поле опционально и может иметь нулевую длину);

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

6.7.42 Подзапись EGTS_SR_SERVICE_FULL_DATA

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

Таблица 38 — Структура подзаписи EGTS_SR_SERV»CE_FULL_DATA сервиса EGTS.FIRMWARE.SERVICE

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

Тип

Тип aaneu

Размер, байт

ООН (Object Data Header)

M

BINARY

7...71

OD (Object Data)

M

BINARY

1...65400

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

•    ООН — заголовок, содержащий параметры, характеризующие передаваемую сущность. Для под* записи EGTS_SR_SERVICE_FULLJ3ATA параметр ООН является обязательным и присутствует в каждой такой подзаписи;

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

6.7.4.3 Подзапись EGTS_SR_RECORD_RESPONSE

Данная лодзапись имеет такую же структуру, как указано в 6.7.2.1 и применяется для подтвержден*» получения и обработки подзаписей EGTS_SR_SERVTCE_PART_DATA и EGTS_SR_SERVICE_FULL_DATA. При этом на все подзаписи EGTS_SR_SERV1CE_PART_DATA. кроме последней, при успешной обработке в составе EGTS_SR_RECORO_RESPONSE должен передаваться код результата, равный

EGTS_PC_IN_PROGRESS. На последнюю подзались EGTS_SR_SERVICE_PART_DATA и каждую EGTS_SR_SERVfCE_FULL_DATA при успешном приеме и обработке со стороны АС должна передаваться подзапись EGTS_SR_RECORD_RESPONSE. содержащая код EGTS_PC_OK. что будет воспринято сервисом как удачная попытка отправка всей сущности.

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

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

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

Название

Тип

данных

Диапазон

значений

Эп*49ние то умолчание

Описание

EGTS SL NOT AUTH.TO

BYTE

0...255

6

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

Если в течение дамюго времени сообщение не поступает, платформа должна ра»рвэтъ установленное с АС ТСРЛР соединение

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

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

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

Сервис экстренного реагирования предназначен для обеспечения возможности реализации системой «ЭРА-ГПОНАСС» функционала по оказанию базовой услуги, предоставляемой системой. В протоколе уровня поддержки услуг этот сервис определен как EGTS_ECALL_SERVICE и имеет код 10.

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

EGTS_ECALL_SERV»CE

Для использования автомобильной системой вызова экстренных оперативных служб сервиса EGTS_ECALL_SERVICE е АС должен быть реализован следующий набор функций:

7.2.1    Поддержка сервиса обработки команд EGTS_COMMANDS_SERV)CE. указанного в 6.7.4.

7.22 Поддержка команд EGTS_ECALL_REQ. EGTS_ECALL_MSO_REQ. отправляемых оператором системы «ЭРА-ГПОНАСС» через SMS. и передача соответствующих ответов и подтверждений на них.

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

7.2.4    Передача данных профиля ускорения через GPRS (подзались EGTS_SR_ACCEL_DATA).

7.2.5    Передача данных траектории движения транспортного средства при ДТП через GPRS (подзапись EGTS_SR_TRACK_DATA).

7.2.6    Обработка команд установки параметров АС. отправляемых оператором системы «ЭРА-ГПОНАСС» через GPRS и SMS. и передача соответствующих подтверждений на них.

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

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

7.3.1    Подзались EGTS_SR_RECORD_RESPONSE

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

7.3.2    Подзапись EGTS_SR_ACCEL_DATA

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

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

Ход

Название

Описание

0

EGTS SR RECORD RESPONSE

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

20

EGTS_SR_ACCEL_DATA

Подзапись предназначена для передачи на телематическую платформу данных профиля ускорения АС

40

EGTS_SR_RAW_MSD_DATA

Подзапись испогъзуется АС для передачи МИД на телематическую платформу а исходном виде

50

EGTS_SR_MSO_DATA

Подзапись испогъзуется АС для передачи МИД на телематическую платформу

62

EGTS_SR_TRACK_DATA

Подэапись применяется для передачи данных о траектории движения транспортжхо средства при ДТП на телематическую платформу

Таблица 41 — Структура подзаписи EGTS_SR_ ACCEL.OATA сервиса EGTS_ECALL_SERVTCE

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

Тип

ТИП ДИЧЬ1Ж

Размер, байт

SA (Structures Amount)

M

BYTE

1

ATM (Absolute Time)

M

UINT

4

ADS1 (Accelerometer Data Sbucture 1)

M

BINARY

8

ADS2 (Accelerometer Data Structure 2)

0

BINARY

8

...

...

ADS255 (Accelerometer Data Structure 255)

о

BINARY

8

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

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

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

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

8 составе подэалиси EGTS_SR_ ACCEL_DATA должна передаваться хотя бы одна структура ADS.

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

Бит 7 | Бит 6 | Б*т б | Бит 4 Бит 3 Бит 2 | Бит t Бит 0

Тип

Тип HWIliITT

Размер. 6air

RTM (RelatrveTime)

M

USHORT

2

XAAV (X Axis Acceleration Nfelue)

M

SHORT

2

YAAV (Y Axis Acceleration Value)

M

SHORT

2

ZAAV (Z Axis Acceleration Value)

M

SHORT

2

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

•    RTM — приращение ко времени измерения предыдущей записи (для первой записи приращение к полю АТМ). е миллисекундах:

•    XAAV — значение линейного ускорения по оси X (старший бит определяет знак. 1 указывает на отрицательное значение). 0.1 м/с2:

•    YAAV — значение линейного ускорения по оси Y (старший бит определяет знак. 1 указывает на отрицательное значение). 0.1 м/с2:

•    ZAAV — значение линейного ускорения по оси Z (старший бит определяет знак. 1 указывает на отрицательное значение). 0.1 м/с2. Разрешающая способность полей ускорения должна быть не более 0.016.

7.3.3 Подзапись EGTS_SR_RAW_MSO_OATA

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

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

Бит 7 | Бит в | Бит S | Бит 4 | Бит 3

Бит 2

Бит 1

Бит 0

Тип

ТИП ДД'ЧЫХ

Размер, байт

FM (Format)

М

BYTE

1

MSD (Minimal Set of Data)

м

BINARY

0...1024

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

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

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

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

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

•    MSD — массив данных (размер данного поля определяется исходя из размера поля FM данной под записи, а также значения поля SRL в соответствии с [2]. таблица 3).

7.3.4 Подзапись EGTS_SR_MSD_DATA

Структура гвдзаписи EGTS_SR_MSD_DATA представлена в таблице 44 и соответствует требованиям к мнд. указанным в I ОС I Н &462U.

Таблица 44 — Структуре пвдзаписи EGTS.SR.MSO.OATA сервиса EGTS_ECALL_SERVTCE

Бит 7 I Бит в I Бит S I Бит 4 I Бит 3

Бит 2

Бит 1

Бит 0

Тип

Тип miiimin

Размер, байт

FV (Format Version)

M

BYTE

1

Ml (Message identifier)

M

BYTE

1

CN (Control)

M

BYTE

1

— VT(Veh»de Type)

POCN

CLT

ACT

VIN (Vefvde Identification Nunber)

M

STRING

17

VPST (Vetede Propulsion Storage Type)

M

BYTE

1

TS (Time Stamp)

M

BINARY

4

PLAT (Position Latitude)

M

BINARY

4

PL ON (Position Longitude)

M

BINARY

4

VD (Vehicle Direction)

M

BYTE

1

RVP n-1 LA.TD (Recent Vehicle Position n-1 Latitude Delta)

о

BINARY

2

Бит 7 Бот в Бит S бит 4 Бит 3 Бит 2 | Бит 1 | Бит 0

Тип

Тип детых

Размер, байт

RVP п-1 LOND (Recent Vehicle Position n-1 Longrtude Delta)

О

BINARY

2

RVP n-2 LATD (Recent Vehicle Position n-2 Latitude Delta)

О

BINARY

2

RVP n-2 LOND (Recent Vehicle Position n-2 Longiude Delta)

О

BINARY

2

NOP (Number Of Passengers)

о

BYTE

1

AD (Adtfrbonal Data)

о

STRING

0...56

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

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

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

•    CN — битовое поле управления;

•    VT — битовые флаги, характеризующие тип транспортного средства [5];

а) 0001 — пассажирский (категория М1);

б) 0010 — автобус (категория М2);

в) 0011 — автобус (категория М3):

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

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

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

ж) 0111 — мотоцикл (категория Lie);

и)    1000 — мотоцикл (категория L2e):

к)    1001 — мотоцикл (категория L3e);

л)    1010 — мотоцикл (категория L4e);

м) 1011 — мотоцикл (категория LSe);

н) 1100 — мотоцикл (категория L6e); п> 1101 — мотоцикл (категория |_7е);

•    POCN — (Position Confidence) битовый флаг, определяющий достоверность данных о местоположении:

а)    1 — данные местоположения недостоверны (если местоположение не могло быть определено с точностью не более ♦ 150 м с достоверностью 95 %у.

б)    0 — данные местоположения достоверны:

•    CLT (Call Туре)—битовый флаг, определяющий тип вызова:

а)    1 — тестовый вызов:

б)    0 — экстренный вызов:

•    ACT (Activation Туре)—битовый флаг, определяющий тип активации события:

а)    1 — автоматически:

б)    0 — вручную;

•    V1N — идентификатор транспортного средства:

•    VPST—тип энергоносителя транспортного средства:

а)    если все биты 0, то тип не задан;

б)    бит 7:6 — не используется;

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

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

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

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

ж)    бит 1:1 — дизель: и) бит 0:1 — бензин:

•    TS — время события. Число секунд с 00:00:00 01.01.1970 согласно универсальному синхронизированному времени (UTC). При отсутствии возможности определения времени события устанавливается равным 0. Данное поле должно интерпретироваться на приемной стороне как тип UINT с порядком следования байт big-endian:

•    PLAT — широта местоположения транспортного средства в момент события, в угловых миллисекундах. При отсутствии или невозможности определить значение широты все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип INT с порядком следования байт big-endian:

•    PL ON —долгота местоположения транспортного средства в момент события, в угловых миллисекундах. При отсутствии или невозможности определить значение широты все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип INT с порядком следования байт big-endian:

•    VO — направление движения транспортного средства от направления на северный магнитный полюс по ходу часовой стрелки, с шагом 2*. Диапазон возможных значений 0...129. При отсутствии или невозможности определения значение поле должно содержать значение 255:

•    RVP п-1 LATD—разность широты местоположения транспортного средства относительно значения поля PLAT с шагом 100 мс. Положительные значения — севернее, отрицательные — южнее. Диапазон возможных значемм от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian:

•    RVP n-1 LOND — разность долготы местоположения транспортного средства относительно значения поля PLON с шагом, установленным в ГОСТ Р 54620 (приложение В). Положительные значения — восточнее. отрицательные — западнее. Диапазон еозможюде значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian;

•    RVP п-2 LATD—разность широты местоположения транспортного средства относительно значения поля RVP п-1 LATD с шагом, установленным в ГОСТ Р 54620 (приложение В). Положительные значения -севернее, отрицательные - южнее. Диапазон возможных значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Дамное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian:

•    RVP п-2 LOND — разность долготы местоположения транспортного средства относительно значения поля RVP п-1 LOND с шагом, установленным в ГОСТ Р 54620 (приложение В). Положительные значения— восточнее, отрицательные — западнее. Диапазон возможных значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение асе биты поля должны содержать значение 1. Данное поле должно интерпретироваться ню приемной стороне как тип SHORT с порядком следования байт big-endian:

•    NOP — число застегнутых ремней безопасности. При отсутствии информации поле должно содержать значение 255:

•    AD — дополнительные данные.

Наличие необязательных параметров е подзаписи EGTS_SR_MSD_DATA должно определяться исходя из общего размера подзаписи. При этом, если необходимо передать необязательный параметр, например поле NOP, то все предшествующие необязательные поля RVP п-1 LATD. RVP п-1 LOND. RVP п-2 LATD. RVP n-2 LOND таюке должны передаваться, но с соответствующими заполнителями.

7.3.5 Подзапись EGTS_SR_TRACK_DATA

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

Таблица 45 — Структура подзатси EGTS_SR_ TRACK.DATA сервиса EGTS_ECALL_SERV)CE

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

Тип

Тип датмыж

Размер. 6**r

SA (Structures Amount)

M

BYTE

1

ATM (Absolute Tine)

M

UINT

4

TDS1 (Trade Data Structure 1)

M

BINARY

8

TDS2 (Track Data Structure 2)

о

BINARY

8

...

IDS 255 (Track Data Structure 255)

0

BINARY

8

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

. SA — число передаваемых точек траектории движения транспортного средства:

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

• TDS1. ..TDS2S5 — структуры данных, содержащие параметры отдельной точки траектории движения транспортного средства. Формат структуры представлен в таблице 46.

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

Таблица 46 — Формат структуры дань*** отдельной точен травкторьы движения транспортного средства подзаписи EGTS_SR_TRACK_DATA сервиса EGTS_ECALL_SERVTCE

Бит 7

Бит в

Бит S

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

Тип

Тип дмьх

Раямар, байт

TNDE

LOHS

LAHS

RTM (Rotative Time)

M

BYTE

1

LAT (Labtude)

О

UINT

4

LONG (Longitude)

о

UINT

4

SPDL (Speed Low 8<ts)

о

USHORT

2

DIRH

SPDH (Speed Hi BAs)

DIR (Direction)

О

BYTE

1

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

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

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

б) 0—данные не передаются (для указанного времени не удалось полупить достоверные координаты и информацию о скорости с требуемой точностью. Либо координаты не валидны, либо определены с неудовлетворительной точностью). Поля LAT. LONG. SPDL. DIRH. SPDH. DIR не передаются e составе данной структуры, и ее размер составляет 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 kWh:

•    DIRH (Direction the Highest bit)—старший бит (8) параметра DIR:

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

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

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

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

Список и описание команд АС и подтверждений, необходимых для реализации базовой услуги системой «ЭРА-ГЛОНАСС», представлены в табгыцах 47 и48 соответствен*).

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

•    EGTS_ECALL_BLACK_LIST;

•    EGTS_ECALL_TEST_NUMBER;

•    EGTS_ECALL_ON;

•    EGTS_ECALL_SIGNALJNTERNAL;

•    EGTS_ECALL_SIGNAL_EXTERNAL:

•    EGTS_ECALL_SOS_BUTTON_TIM&

•    EGTS__ECALL_CCFT:

•    EGTS_ECAJJ_JNVTTATHDN_SIGNAL_DURAT1C)N:

•    EGTS_ECALL_SENO_MSG_PERIOD:

•    EGTS_ECALL_AL_ACK_PERtOO:

•    EGTS_ECALL_MSO.MAX_TRANSMISSION_TlME;

•    EGTS_ECALL_NAD_DEREGISTRAT10N_TIMER:

•    EGTS_ECALL_D!AL_DURATtON;

•    EGTS_ECALL_AUTO_DlAL_ATTEMPTS:

•    EGTS_ECALL_MANUAL_DIAL_ATTEMPTS;

•    EGTS_ECALL_MANUAL_CAN_CANCEL:

•    EGTS_ECALL_SMS_FALLBACK_NUMBER;

•    EGTS_CRASH_RECORD_TlME;

•    EGTS_CRASH_RECORD_RESOLirnON;

•    EGTS_CRASH_PR£_RECORD_TIME;

•    EGTS_CRASH_PRE_RECORD_RESOLUTION;

•    EGTS_TRACK_RECORD_TIME;

•    EGTS_TRACK_RECORD_RESOLUTK5N:

•    EGTS_TRACK_PRE_RECORD_TIME:

•    EGTS_ECALL_BLACKJJST;

•    EGTS VEHICLE VIN;

•    EGTS_VEHICLE_TYPE;

•    EGTS VEHICLE PROPULSION STORAGE TYPE.

Таблица 47 — Список команд для AC

Намаиие

еомэиды

Код

ТИП, <авСЛО И предельные ъпъчыт** параметров

Описание

EGTS_ECALL_REQ

0x0112

Команда на осуществление повторного экстренного вызова. Используется тогъко через SMS

EGTS_ECALL_MSO_REQ

0x0113

Команда на осуществление повторной передачи МНД Используется только через SMS

EGTS_ ACCEL.DATA

0x0114

Команда на осуществление передачи данных профиля ускорения. Используется только через SMS

EGTS_TRACK_DATA

0x0115

Команда на осуществление передачи данных траектории движения. Используется только через SMS

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

Код

Тип. чмсло * предельные эначе«шя параметров

Описание

EGTS TEST МООЕ START.TEST

0x0003

BYTE/0...8

Команда, осуществляющая запуск тестов в «тестовом режиме». Может приммать следующие значения:

0    — запуск последовательно всех тестов:

1    — проверка центра обслуживания эеомсое:

2    — проверка внешнего (коммерческого) центра обслуживания зеомсов:

3    — тест (Мфофона:

4    — тест джамиков:

5    — тест вхлючения'1выключежя зажигания:

6    — расширенный тест БИП:

7    — тест встроенной резервной аккумуляторной батареи:

в — тест датчика автоматической идентификации ДТП

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

Нвэммме to манды

Код

Тип и ЧИСЛО параметров

Описание

EGTS TEST МООЕ START.TEST

0x0003

BNARY (8 байт)

Результаты проведения тестов. Каждый байт содержит код. определяющий результат теста (см. описание TEST_MODE_START_TEST из табгм-цы 35). 1-й бейт — тест 1. 2-й байт —тест 2 и т. д.

Таблица 49 — Слисок параметров АС

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

Код

Тип

Знамение no

ywелчфмцф

Описание

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

EGTS_ECALL_BLACK_LIST

0x0206

ARRAY OF STRING

If ие M* «9*

♦    * ♦ t м «о

♦    ♦ * ♦ и ее e* en

м *«* a* «*• * * ♦ * el* «ее ее am

Список сетей, e которых нет возможности осуществить экстренный вызов

EGTS ECALL TEST_NUMBER

0x0200

STRING

112

Тепефожый номер для тестовых эеожое ЭРА-ГЛОНАСС

Конфигурация и конфигурационные дажые услуг

Базовая услуга системы «ЭРА-ГЛОНАСС»

EGTS_ECALL_ON

0x0210

BOOLEAN

TRUE

Возможность осущесгвлежя экст-режого вызова

EGTS ECALL

CRASH_SIGNALJNTERNAL

0x0211

BOOLEAN

TRUE

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

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

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

Код

Тип

параметр*

Значение no умопчаии«

Описание

EGTS ЕСЛИ.

CRASH_SK3NAL_EXTERNAL

0x0212

BOOLEAN

TRUE

Только транспортные средства категории М. — для определения события аварш используется внешний дат-'em в автомобиле

EGTS ECALL

sos.button.tTme

0x0213

INT

200

Длительность, в течение котором должна быть нажата кнопха «экстренный вызов» для инициалы экстренного вызова независимо от состоят* линии зажигания, миллисекунд

EGTS_ECALL_MOOE_PIN

0x0216

ENUM

{NONE-0.

PIN_1-1.

PlN_8-8}

NONE

Линия, сигналмзирующая. что система находится в режиме ЭРА: NONE — нет сигнализации режима: PIN_X - PN_X — номер активной лы-hw. когда система находится а данном режиме

EGTS_ECALL_CCFT

0x0217

INT

80

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

EGTS ECALL INVITATION SIGNAL DURATION

0x0218

INT

200

Длитегьность сигнала INVITATION, миллисекунд

EGTS ECALL SEND MSG.PERfOO

0x0219

INT

200

Период сообщения SEND MSG. миллисекунд

EGTS ECALL AL_ACK_PERIOO

0x021A

INT

200

Период AL-ACK. миллисекунд

EGTS ECALL MSD MAX TRANSMISSION.TIME

0x02IB

NT

20

Максимальная длительность передачи MSD. секунд

EGTS ECALL NAD DEREGISTRATION TIMER

0x021D

NT

8

Время, по истечети которого мо-дульСБМ или UMTS прекращает регистрацию в сети, часов

EGTS ECALL DIAL.DURATION

0x021E

NT

5

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

EGTS ECALL AUTO DIAL ATTEMPTS

0x021F

NT

10

Только транспортные средства категории М, — число попыток дозвона при автоматически инициированном вызове.

Значение не может быть установлено в 0

EGTS ECALL MANUAL DIAL ATTE*ff»TS

0x0220

INT

10

Число попыток дозвона при экстренном вызове, икциироса »юм вручную. Значение не мажет быть установлено в 0

EGTS ECALL MANUAL CAN CANCEL

0x0222

BOOLEAN

TRUE

TRUE — экстренный вызов, ижци-ироеанньм вручную, может быть прекращен со стороны пользователя

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

Код

Тип

параметра

Зиачепи no умолчэи««

Описание

EGTS ECALL SMS.FALLBACK.NUMBER

0x0223

STRING

112

Номер, no которому АС посылает SMS с минимальны набором данных по запросу от оператора системы

Запись профиля уосоропия при ДТП

IGNITION OFF FOLLOW_UP_TlME1

Мжуты

nt

120

Промежуток времени, в течение которого осуществляется запись профиля ускорения при ДТП при выкгьо-ченном зажигании

IGNITION OFF FOLLOW_UP_T1ME2

Мтмуты

NT

240

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

EGTS CRASH RECORD.T1ME

0x0251

INT/ 0.-250

250

Время записи информации о профиле ускорения при ДТП. миллисекунд

EGTS CRASH RECORD RESOLUTION

0x0252

INT/1...5

1

Продолжительность одного отсчета при загмси профиля ускорения при ДТП. миллисекунд

EGTS CRASH PRE.RECORD.TIME

0x0253

INT/ 0...20000

20000

Время записи информации о профиле ускорения до того, как событие ДТП наступило, миллисекунд

EGTS CRASH PRE RECORD RESOLUTION

0x0254

INT/5...100

5

Продолжительность одного отсчета при записи профиля ускорения до того, как событие ДТП наступило, миллисекунд

Запись траектории движенмя при ДТП

EGTS TRACK RECORD.TIME

0x02SA

INT/0...180

10

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

EGTS TRACK PRE RECORD" TIME

0x0256

INT/0...600

20

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

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

EGTS TRACK RECORD RESOLUTION

0x02SC

INT/1...30

10

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

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

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

Код

Тип

параметра

Эиачепме no умопчаим«

Описание

Параметры транспортного средства

EGTS VEHICLE VIN

0x0311

STRING

VIN в соответствии с [5]

EGTS VEHICLE TYPE

0x0312

INT

0

Тип транспортного средства:

1    — пассажирами (класс М1)

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

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

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

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

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

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

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

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

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

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

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

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

EGTS VEHICLE PROPULSION STORAGE TYPE

0x0313

1NT

0

Тип энергоносителя (эсты все биты 0. то тип не задан):

бит 7: не испогъзуется бит б: не испогъзуется бит 5:1 — водород бит 4:1 — электричество (более 42 В и 100 А-ч)

бит 3: 1 — жидкий пропан (LPG) бит 2: 1 — сжиженный природный газ (CNG)

бит 1:1 — диэегъ оит 0:1 — оенэы

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

8.1    Сообщетмв AL-ACK. содержащее подтверждение корректности полученного минимального набора данных. высылается системой «ЭРА-ППОНАСС» в сторону АС посредством использования тонального модема.

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

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

Поле данных AL-ACK

Номер бита, представляющего попе дяям»

Значение

Зарезервированное поле N9 1

4

Поле не используется

Зарезервированное попе № 2

3

Поле не используется

Признак корректности полученных данных

2

0    — полученные данные корректны:

1    — полученные данные не коррегпы

Версия формата данных

1

0    — текущий формат;

1    — зарезервировано для будущего использования

Описание принципа построения навигационно-информационной системы на основе протокола транспортного уровня

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

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

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

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

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

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

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


Рисунок А.1 — Структурная схема взаимодействия элементов системы, основанной на

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


Анализ протокола транспортного уровня на основе концепции NGTP

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

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

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

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

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

В NGTP идентификатором АС является VIN/DriveC. в описываемом протоколе — U№T_ID.

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

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

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

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

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

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

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

Значение

Обозначение

Описание

0

EGTS_PC_OK

Успешно обработаю

1

EGTS_PCJN_PROGRESS

В процессе обработки (результат обработки виде не известен)

128

EGTS_PC_UNS_PROTOCOL

Неподдерживаемый протокол

129

EGTS_PC_DECRYPT_ERROR

Ошибка декодирования

130

EGTS_PC_PROC_DENIED

Обработка запрещена

131

EGTS_PC_JNC_HEADERFORM

Неверный формат заголовка

132

EGTS_PC_INC_DATAFORM

Неверным формат данных

133

EGTS_PC_UNS_TYPE

Неподдерживаемый тип

134

EGTS_PC_NOTEN_PARAMS

Неверное количество параметров

135

EGTS_PC_DBL_PROC

Попытка повторной обработки

136

EGTS_PC_PROC_SRC_DENIED

Обработка данных от источнжа запрещена

137

EGTS_PC_HEADERCRC_ERROR

Ошибка контрольной сумт заголовка

138

EGTS_PC_DATAC RC_ERROR

Ошибка контрольной сумьы дэнтх

139

EGTS_PC_INVDATALEN

Некорректная дтана дантх

140

EGTS_PC_ROUTE_NFOUND

Маршрут не найден

141

CGTe_nC_ROUTC_CLOSCO

Маршрут закрыт

142

EGTS_PC_ROUTE_DENIED

Маршрутизация запрещена

143

EGTS.PCJNVADOR

Не верти адрес

144

EGTS_PC_TTL EXPIRED

Превышено число ретрансляции да ■ 1ых

145

EGTS_PC_NO_ACK

Нет подтверждения

146

EGTS_PC_OBJ_NFOUND

Объект не найден

147

EGTS_PC_EVNT_NFOUND

Событие не найдено

148

EGTS_PC_SRVC_NFOUND

Сервис не найден

149

EGTS_PC_SRVC_DENIED

Сервис запрошен

150

EGTS_PC_SRVC_UNKN

Неизвестный тип сервиса

151

EGTS_PC_AUTH_DENIED

Авторизация запрещена

152

EGTS_PC_ALREADY_EXISTS

Объект уже существует

153

EGTS_PC_ID_NFOUND

Идентификатор не найден

154

EGTS_PC_1NC_DATET1ME

Непраеи/ъная дата и время

155

EGTS_PC_IO_ERROR

Ошибка ввода/вывода

156

EGTS_PC_NO_RES_AVAfl.

Недостаточно ресурсов

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

Значение

Обозначение

Описа*ые

157

EGTS_PC_MODULE_FAULT

Внутрений сбой модуля

158

EGTS_PC_MOOULE_PWR_FLT

Сбой в работе цепи питамя модуля

159

EGTS_PC_MODULE_PROC_FLT

Сбой в работе микроконтроллера модуля

160

EGTS_PC_MODULE_SW_FLT

Сбой в работе программы модуля

161

EGTS_PC_MODULE_FW_FLT

Сбой в работе внутреннего программного обеспечения модуля

162

EGTS_PC_MOOULE_KD_FLT

Сбой в работе блока ввода/вьеода модуля

163

EGTS_PC_MODOlE_MEM_FLT

Сбой в работе внутренней памяти модуля

164

EGTS_PC_TEST_FA1LED

Тест не пройден

Примечание — Пакеты сообщений об ошибках (EGTS PC DECRYPT ERROR. EGTS PC UNS.PROTOCOL EGTS_PCJNC_DATAFORM. EGTS_PC_DATACRC_ERROR. EGTS_PC_INC_H EADERFORM. EGTS_PC_HEADERCRC_ERROR) предназначены для целей тестирования оборудования и в рабочей верст программного обеспечения и АС могут быть исключош.

Пример реализации алгоритма расчета контрольной суммы CRC16

на языке С Г


Name : CRC-16 CCITT Poly : 0x1021 хА16 + х*12 + х*5+ 1 Imt : OxFFFF Revert false XorOut 0x0000

Check: 0x29B1 ("123456789")*/ const unsigned short Сгс16ТаЫе(256] - {

0x0000. 0x1021. 0x2042. 0x3063. 0x4084. 0x50A5, ОхбОСб. 0x70E7, 0x8106.0x9129. 0xA14A. 0xS168. 0xC18C. 0xD1AD. OxEICE, OxFIEF.

0x1231. 0x0210. 0x3273. 0x2252. 0x5285. 0x4294. 0x72F7. 0x62D6. 0x9339.0x8318. 0xB37B. 0xA35A_ 0x0380.0xC39C. 0xF3FF. ОхЕЗОЕ. 0x2462. 0x3443. 0x0420. 0x1401. 0x64E6. 0x74C7. 0x44A4. 0x5485. 0xA56A. 0xB548. 0x8528.0x9509.0xE5EE. OxFSCF. 0xC5AC. 0x0580. 0x3653. 0x2672. 0x1611. 0x0630. 0x7607. 0x66F6. 0x5695. 0x4684. 0x8758.0xA77A. 0x9719.0x8738.0xF7DF. 0xE7FE. 0xD79D. 0xC7BC. 0x48C4. 0x58E5. 0x6886. 0x78A7. 0x0840. 0x1861. 0x2802. 0x3823. ОхСЭСС, ОхОЭЕО. 0xE98E. 0xF9AF. 0x8948. 0x9969. ОхАЭОА. 0xB928. 0xSAF5.0x4AD4.0x7AB7.0x6A96.0x1 A71.0xQA50. ОхЗАЗЗ. 0x2A12. OxOBFO. OxCSDC. 0xFB8F. 0xEB9E. 0x9879.0x8858.0xBB38.0xA81 A. ОхбСАб. 0x7C87. 0x4CE4. 0x5CC5. 0x2C22. ОхЗСОЗ. ОхОСбО. 0x1041. OxEDAE. 0xFO6F. OxCOEC. OxOOCD. 0xAO2A. 0x8006.0x8068.0x9049. 0x7E97. ОхбЕВб. 0x5ED5. 0x4EF4. 0x3E13. 0X2E32.0x1E5t. 0x0£70. 0xFF9F, OxEFBE. OxOFDD. OxCFFC. 0xBF1 В. 0xAF3A. 0x9F59.0x8F78. 0x9188. 0x81A9. OxBICA. OxAIEB. OxDIOC. 0xC12O. 0xF14E. 0xE16F. 0x1080. OxOOAI. 0x30C2. Ox20E3. 0x5004. 0x4025. 0x7046. 0x6067. 0x8389.0x9398. 0xA3FB. ОхВЗОА. ОхСЗЗО. Ox031C. 0xE37F. 0xF35E. 0x0281. 0x1290. 0x22F3. 0x3202. 0x4235. 0x5214. 0x6277. 0x7256. 0xS5EA. 0xA5C8.0x95A8. 0x8589. 0xF56E. 0xE54F. 0xO52C. 0xC50D. 0x34E2. 0x24C3. 0x14A0. 0x0481. 0x7466. 0x6447. 0x5424. 0x4405. 0xA7DD, Chd37TA. 0x6799.0x9700. 0xC7ST. 0хГ77С. 0xC71D. OxD73C. 0x2603. 0x36F2. 0x0691. 0x1680. 0x6657. 0x7676. 0x4615. 0x5634. 0xO94C. 0x0960.0xF90E. 0xE92F. 0x99C8.0x89E9.0xB98A. 0xA9AB. 0x5844. 0x4865. 0x7806. 0x6827. 0x18C0. OxO&EI. 0x3882. 0x28A3. 0xC87D. 0x0850,0xEB3F. OxFBIE. 0x88F9.0x9808.0xAB88.0xB89A. 0x4A75.0x5A54.0x6A37.0x7A16. OxOAFi. 0x1 ADO. 0x2AB3.0x3A92. 0xFD2E. OxEOOF. ОхООбС. 0xCD4D. OxBOAA. 0xAO8B. Ox90E8. 0x8009. 0x7026, 0x6007. 0x5C64. 0x4045. 0x3CA2. 0x2083. OxICEO. 0x0001, OxEFIF. 0xFF3E. 0xCF5D. OxOF7C. 0xAF9B. OxBFBA. Ox8FD9.0x9FF8. 0x6E17.0x7E36.0x4E55.0x5E74. 0x2E93. 0x3EB2. OxOEDI. Ox1EFO>: unsigned short Crc16(unsigned char * pcStock, unsigned short len)

{ Lrtsigned short crc • OxFFFF: while (len- -)

ere - (crc « 8)A Сгс16ТаЫе((сгс » 8) * *pc8lock*+J: гекжпеге:}

Пример реализации алгоритма расчета контрольной суммы CRC8

на языке С Г


Name : CRC-8 Poly :0x31 х*8 + х*5 + хА4 + 1 In* ;0xFF Revert false XorOut 0x00

Check : 0xF7 C123456789*)

V

oonst unsigned char CRC8Table{256j - {

0x00.0x31.0x62.0x53.0xC4, OxFS. 0xA6.0x97.

0xB9.0x88.0x06. OxEA. 0x7D. 0x4C. 0x1F. 0x2E.

0x43.0x72.0x21.0x10.0x87. 0xB6.0xE5.0xD4.

OxFA OxCB. 0x98.0xA9.0x3E. OxOF. 0x5C. 0x6D.

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.0x1E. 0x2F. 0xB8.0x89. OxOA. OxEB.

0x30. OxOC. 0x5F, 0x6E. 0xF9.0xC8.0x96. OxAA.

0x84.0xB5.0xE6.0x07. 0x40. 0x71.0x22.0x13.

0x7E. 0x4F. 0x1C. 0x20. OxBA 0x88.0x08.0xE9.

0xC7.0xF6.0xA5.0x94.0x03.0x32.0x61.0x50.

0xB8. OxSA. 0x09.0xE8.0x7F. 0x4E. 0x10.0x2C.

0x02.0x33.0x60.0x51.0xC6.0xF7.0xA4.0x95.

0xF8.0xC9. OxSA. OxAB. 0x3C. 0x00,0x5E. 0x6F.

0x41.0x70.0x23.0x12. 0x85. 0xB4.0xE7.0xD6.

0x7A. 0x4B. 0x18.0x29. OxBE. 0x8F. OxOC. OxEO.

0xC3.0xF2.0xA1.0x90.0x07.0x36.0x65.0x54.

0x39.0x08.0x56, ОхбА. OxFO. OxCC. 0x9F. OxAE.

0x80.0xB1.0xE2.0x03.0x44. 0x75.0x26. 0x17.

OxFC. OxCD. 0x9E. OxAF. 0x38.0x09.0x5A 0x66.

0x45.0x74. 0x27,0x16. 0x81. OxOO. 0xC3. OxD2.

OxBF. Ox8E. OxDD. OxEC. 0x7B. 0x4A. 0x19. 0x28.

0x06.0x37.0x64.0x55.0xC2.0xF3. OxAO. 0x91.

0x47.0x76.0x25.0x14. 0x83, 0xB2. OxE1. OxDO.

OxFE. OxCF. 0x9C. OxAO. ОхЗА. 0x06.0x58.0x69.

0x04.0x35.0x66.0x57. OxCO, OxF1.0xA2.0x93.

OxBO. 0x8C. OxDF. OxEE. 0x79.0x48. Ox1B. 0x2A.

OxC 1. OxFO. OxA3.0x92.0x05.0x34. 0x67.0x56.

0x78.0x49. Ox1A. 0x26. OxBC. 0x80. OxOE. OxEF.

0x82. ОхВЭ.ОхЕО. 0x01.0x46. 0x77.0x24.0x15.

0x36. OxOA. 0x59.0x68. OxFF. OxCE. 0x90. OxAC

}:

unsigned char CRC8(uns*gned char ‘ipBlock. unsigned char ten)

{

unsigned char ere - OxFF; wMe (ten- -)

ere - CRC8Tabte(crc A *1рВ1оск++]; retun crc;

}

Таблицы кодировки символов

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

0

1

СМ

3

4

5

6

7

СО

9

А

в

с

D

Е

и.

«01

соо?

имо

ои*

ciKt*

ах»г.

0077

позе

вою

ООО*

0008

ооос

0800

0006

ООМ

X’ ?

ве«

С012

Xt>

вен

C0U

лл

"0’?

WB

0019

ж**

0016

001С

оею

0086

0017

f

в

и

#

$

%

&

1

(

)

*

+

9

/

ж»

ООП

«22

0023

осе*

СОЙ

«не

ссс?

ЖСв

0029

Ж2А

003

озес

0820

0026

007

0

1

2

3

4

5

6

7

8

9

*

<

>

9

KN

0031

СС32

лв

009*

СОИ

X*

СО’?

жов

0039

I1A

0038

оовс

0830

0036

003F

<2;

А

В

с

D

Е

F

G

н

I

J

К

L

м

N

о

ха:

.С*'

СС42

»3

00*4

СО*5

Х*>6

С04?

оме

0049

зои

со«

ОМС

ООО

00*6

ОМЕ

Р

Q

R

S

т

и

V

W

X

Y

Z

1

\

]

л

ССЯ

х«

сои

006*

С055

Х56

3057

0068

0069

ЭЭ5А

0068

096С

006Е

00SF

*

а

ь

с

d

е

f

g

h

в

1

j

к

1

ш

п

0

X*j

0М1

СС62

•совз

008*

«365

0065

0067

оа*

0069

006*

оом

008С

оно

0066

оом

Р

ч

Г

$

t

и

V

W

X

у

Z

{

1

}

Xfj

оси

ос??

"Г?5

007*

«175

JCJb

0077

0078

0079

Ж7*

0078

007С

вето

0076

0076

0СЯ2

ахи

008*

«ИЙ

<хт

007?

ООМ

0069

006*

0008

оовс

0060

оом

оом

язю

от<

СС82

ТОЧЗ

ГГ»4

«КП

оом

со»?

осе*

009»

008*

со»

009С

0080

0096

оом

1

i

£

¥

j

§

••

€>

8_

«

-1

-

®

XAD

00*1

00*2

жми

сом

00*3

0О*в

0М7

оом

00*9

ОМ*

00*8

ООАС

(0*0

00*6

ОСА»

о

±

2

3

г

м

1

»

1

о

»

*/4

Уз

3/4

6

оом

0081

0092

«83

сен

осе 5

отав

осе*

ООМ

осев

сов*

осев

соес

0080

0086

осе»

Ч

' У

А

*

}

А

9

А

вв

А

А

А

А

А

AL

с

Е

Е

Е

Е

1

I

1

1

х«

ООС1

0X2^

Ж!

сос^

0X5

0Х£

же?

0008

эхе

ООСЛ

0СС8

ооос

оосо

90С6

OOCF

«к

ч

0

А

00

ч

0

0

0

D

N

о

О

О

О

О

X

0

L)

и

и

Y

1>

Й

хос

эх-

ох»

МОЗ

ЭХ5

ЛХ36

же?

сосе

жсо

оос*

эхе

ооос

оооо

особ

OOOF

ч

0

А

О

ч

щ

А

0

А

а

а

а

а

а

а

it‘

¥

С

е

е

е

1

1

1

1

дХС

east

00Е2

УЖ'л

•:сЕ4

осе 5

эОЕо

0067

СОЕЙ

0069

СОСА

осев

СОЕС

•060

0С66

006F

Ж

ч

0

А

ш

ч

0

А

0

6

11

О

О

О

О

О

0

и

и

и

и

V

|>

у

ах?

ООП

СОТ?

«I* Я

ах * \ оо»5

00» в

ООН

<1*8

core

XX*

оогв

соте

вето

0066

0MF


0

1

2

3

4

5

6

7

8 9 А В С D Е F

Е.2 Кодировка символов латинского и кириллического алфавитов приведена в таблице Е.2. Таблица Е2

0

1

2

3

4

5

6

7

СО

9

А

В

С

D

Е

F

0081

0003

0DC3

0034

0005

мм

0087

0006

0008

0084

оосе

ооос

0000

оосс

оом

х-s

ООП

0012

ЯМЗ

ООН

0015

»16

0017

ООП

0010

Q8M

00»

вис

0810

оо»

0017

I

в

II

#

$

%

&

1

(

)

+

У

_

/

жм

0021

0022

тез

оое*

те?

3326

0027

0026

оое»

ста*

002»

оогс

082D

0Q2E

0027

0

1

2

3

4

5

6

7

8

9

9

<

>

9

0031

Ж02

тез

ООН

0035

0336

0057

с<ш

кое

«за

0038

ооэс

0830

0036

0037

%

А

В

С

D

Е

F

G

н

I

J

К

L

м

N

О

тез

00*1

те:

тез

00*4

00*5

0346

00*7

со*;

004»

00*4

0048

004С

00*0

0046

0047

р

Q

R

S

т

и

V

W

X

Y

Z

[

\

]

л

хвз

*51

«62

Х^1

0054

0055

0056

0067

СОМ

0058

0054

0058

006С

COSO

006S

0057

а

ь

с

d

е

f

g

h

в

1

в

J

к

1

ш

п

0

тез

0081

ожг

тез

005*

0065

0365

3367

0086

0068

0054

0066

овес

0MD

0OSE

0067

Р

q

Г

$

t

(1

V

W

X

У

Z

{

1

}

X7J

осп

»7?

XT3

0074

M7S

0376

0077

0078

007В

087А

007В

007С

вето

0876

0077

•*ЧМ

0081

оовг

ж»

0084

0С85

0366

0087

сове

9068

0084

0068

ОООС

0880

00*

0017

УЖ'

0081

хвг

зсез

оое*

осев

0396

0087

0096

0098

СОЯ4

оовв

008С

08)0

оове

0097

Ё

ъ

Г

е

S

I

I

J

л>

н>

ъ

t

К

-

W

У

U

■УМ

00*1

тег

тез

00*4

те 5

УМ

00*7

СОМ

004»

00*4

0048

004С

08*0

00*8

0047

А

Б

В

Г

д

Е

ж

3

и

W

И

К

Л

м

н

о

П

МО

0*11

•3**2

1413

04U

04*S

Г4'0

0*17

С41 *

041»

0*14

0*«

041C

0*10

0*16

0*17

р

с

т

У

Ф

X

Ц

ч

ш

щ

ъ

ы

ь

э

ю

Я

мп

«м*1

Л4»

МП

мм

«ми

-аж

«М*Т

Г4?Ж

га»

«мм

<МЭА

<м>с

1МЭП

IMS*

(М?С

а

б

В

Г

д

е

ж

3

И

И

к

Л

м

н

О

11

з*»

3431

3432

3433

0*3*

0435

3436

0437

0*36

0*38

0*34

о*зе

04ЭС

0*30

0*36

0437

Р

с

т

у

ф

X

ж

Ц

III

щ

Ъ

Ы

ь

э

ю

Я

'M'J

0441

3442

-34*3

0*44

0445

34*6

0*47

04М

044»

0444

С44в

044С

0*40

0446

0*47

Ns

ё

1)

Р

Г

S

в

1

• в 1

J

Л»

н>

h

Р

К

§

у

U

; v*.

0*51

C4S2

-3*53

0*54

:и55

3*56

345*

0456

3458

0454

6456

case

•-Ч347

0*56

IM57


0

1

2

3

4

5

6

7

8 9 А В С D Е F

Е.З Кодировка символов лапмоюго и древнееврейского алфавитов приведена в тэбгмцв Е.З. Таблица Е.З

0

1

2

СО

4

5

6

7

СО

9

А

В

с

D

Е

F

00*1

соог

споз

оом

0004

0004

0007

осев

ООО»

ЭОС*

0000

ооос

coco

0006

00(6

зек»

ООН

0012

0<ИЗ

оом

сот*

даю

0017

омо

0019

001А

0019

001С

0010

0016

001F

I

»»

#

$

%

&

1

(

)

*

+

9

/

тэт

овг1

согг

осгз

осе*

ссгт-

хге

(ХСГ

оая

0029

32*

согв

осес

0020

0026

0Q2F

0

1

2

3

4

5

6

7

8

9

*

<

>

9

ссз:

■Х02

жзз

хи

сс*

X*

0037

ОХИ

С0Э9

ха*

соэв

ОООС

0030

0036

003F

&

А

В

с

D

Е

F

G

н

I

J

к

L

м

N

о

ХАЗ

00*2

:о*з

ООН

С№

Х*6

0Ы7

ЗОИ

00*9

Х4А

со*в

0О4С

оом

00*6

00*6

р

Q

R

S

т

и

V

W

X

Y

Z

1

\

1

л

ЭС60

CC£i

Xii

Х64

CG45

Х-96

х»

006*

009»

Эйб*

С098

ООбС

0090

0066

OOSF

*

а

ь

с

d

е

f

g

h

в

1

в

J

к

1

ш

п

0

Х№

Clht

СС&

.063

ось*

С064

■Ju&b

сны

оом

сова

306А

оом

оовс

ооео

0096

0046

р

Ч

г

$

t

U

V

W

X

У

Z

{

1

}

оста

осм

<072

ОС 73

ом*

СС74

ооте

вот?

0078

«7»

007*

007В

007С

0070

0076

007F

*ПЦ1

ССЯ1

ссвг

СОК)

ОСИ*

со»

оом

00*7

ООМ

оов»

ООО*

ООМ

ооос

оом

00«6

00(6

эоао

00*1

W92

ООП

оом

ооэд

оом

00*7

ОСМ

0099

оса*

ООМ

осес

оом

оом

0099

0

£

¥

1

1

§

ее

©

X

«

-1

®

тело

00*2

00*3

ш*

0CIA5I OOU

ах*

оом

00*9

0007

00*0

0QAC

оме

00*6

2036

О

±

2

3

0

м

11

1

-Г-

»

ХА

Уз

3/4

■3*90

0«1

0*82

о*ез

**•*

0484

3«8в

2022

0*М

о*ев

00F7

ооев

ооес

ооео

осее

той

К

2

}

п

*\

т

п

о

ч

1

э

!?

п

1

ОШ

«От

0402

СбО*

0404

мое

мст

С508

040»

040*

04Св

0SOC

0400

0406

0406

э

V

V

ч

0

Ч

*

р

*1

л

34*0

0442

04£3

C66*

ОМ 5

эзее

ЗМ7

06U

ОМ»

СМ*


0

1

2

3

4

5

6

7

8 9 А В С D Е F

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


ГЧ

PI

СТ

HI

И


ETSITS126 267 Группа техтчеошх специфика^*! услуги и систетые аспекты; передача дзжых при экстренном вызове (еСа>): тональный модем: общее огысание. издание 8 (3GPP TS 26-267) (Technical Specification Group Services and System Aspects: eCail Data Transfer: In-band modem solution; General description, Release 8)

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

(Digital cellular lete communicator system (Phase 2):    Alphabets and language-specific

information)

Правила отправки и приема сервиса коротких сообщений (Dtgrtal ceBuiar telecommunication system (Phase 2))

Российская система и план нумерации (утверждена приказом Министерства тформаиюжых технологий и связи Российской Федерации от 17 ноября 2006 г. Ые 142)

Технический регламент о безопасности колесных транспортных средств (утвержден постановлением Правительства Российской Федерации от 10 сентября 2009 г. № 720)


GSM 03.38

(ETS 300 628)

GSM 03.40 (ETS 300 536)


УДК 656.13:004:006.354    ОКС 33.070.40

Ключевые слова: автомобильная система вызова экстренных оперативных служб, дорожно-транспортное происшествие, маршрутизация, минимальным набор данных, протокол уровня поддержки услуг, протокол транспортного уровня, система экстренного реагирования при авариях «ЭРА-ППОНАСС». экстренный вызов. экстренная оперативная служба, экстренное сообщение


Редактор Е. С. Котлярова Технический редактор В. Н. Прусакова Корректор Н. И. Гаврищук Компьютерная верстка Т. Ф. Кузнецовой


Сдано а набор 28.11.2012. Подписано • мчат» 07.022013. Формат 80x84'/*. Бумага офсетная Лечат» офсетная. )Ъп. леч. л. 7.44. Уч.-мад. п. 7.10, Тирах 78 зи Зая. 1887


Гарнитура Ариал


•ГУП «СТАНДАЯТИН«ОРМ*. 123905 Моем. Гранатный пер. 4 www.90stnfo.1u    info£90Stinfo.ru

Набрано я отпечатано а Калужской типографии стаидартое. 248021 Калуга, уп. Московская. 258


Изменение № 1 ГОСТ Р 54619—2011 Глобальная навигационная спутниковая система. Система экстренного реагирования при авариях. Протоколы обмена данными автомобильной системы вызова экстренных оперативных служб с инфраструктурой системы экстренного реагирования при авариях

Утверждено и введено в действие Приказом Федерального агентства по техническому регулированию и метрологии от 22.04.2014 Ns 397-ст

Дата введения — 2014—09—01

Наименование стандарта. Заменить слова: «автомобильной системы» на «автомобильной системы'’ устройства», «in-vehicle emergency call system» на «irv-vehide emergency call system/device».

Предисловие. Первый абзац. Заменить ссылку. ГОСТ Р1.0—2004 на ГОСТ Р 1.0—2012;

пумст 1 дополнить словами, «и Некоммерческим партнерством «Содействие развитию и использованию навигационных технологий».

Раздел «введение». Третий абзац. Заменить слова: «автомобильной системой» на «автомобильной системой/устройством »;

четвертый абзац. Заменить слова: «автомобильной системы» на «автомобильной системы/устрой-ства»;

шестой абзац. Заменить слова: «Автомобильная система» на «Автомобильная система/устройстэо»:

двенадцатый абзац. Заменить слова: «автомобильныхсистем» на «автомобильных систем/устройств».

Раздел 1. Второй абзац изложить в новой редакции:

«Настоящий стандарт устанавливает требования к протоколам обмена данными между автомобильной системой/устройством вызова экстренных оперативных служб и инфраструктурой системы «ЭРА-ГЛО-НАСС». включая требования к протоколу обмена данными, связанными с предоставлением системой «ЭРА-ГЛОНАСС» базовой услуги по ГОСТ Р 54721 в целях выполнения требований технического регламента [6] и ГОСТ Р 54620».

Раздел 2. Для ссылки на ГОСТ Р 54620—2011 заменить слова: «Автомобильная система» на «Автомобильная система/устройство».

Пункт 3.1.1 изложить в новой редакции.

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

Примечания

1    Автомобитъная система вызова экстренных оперативных служб предназначена для оснащения транспортных средств категории Ml. входящих в область применения Правил ЕЭК ООН [7J. (8). и N1. входящих в область применения Правил ЕЭК ООН [8].

2    Автомобильное устройство вызова экстренных оперативных служб гредназначено для оснащения транспортных средств категории М1. не входящих в область применены Правил ЕЭК ООН [7]. [8]. и N1. не входящих в область приме не имя Правил ЕЭК ООН [8]. а также транспортных средств категорий М2. М3. N2 и N3.

3    Сроки оснащения транспортах средств системами/устройствами вызова экстренных оперативных служб устанавливаются а (6].

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

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

Пункт 3.1.2. Запенить слово: «системой» на «системой/устройством».

Пумст 3.1.5 изложить в новой редакции (кроме примечания):

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

Пункт 5.5.3. Таблицу 2 для типа данных FLOAT и DOUBLE изложить в новой редакции:

Тип мим

Р*эм«р. байт

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

Описание

FLOAT

4

± \2 Е - 38 3.4 Е + 38

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

DOUBLE

8

± 22 Е — 308 ... 1.7 Е ♦ 308

Дробное '-мело со знаком в соответствии с [9]

Подпункт S.6.1.3. Таблицу 4 для обозначений параметров RTE (Route) и НЕ изложить в новой редак-до:

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

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

RTE (Route)

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

НЕ

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

Подпункт 5.6.1.4. Рисунок 1 изложить в новой редакции:

А- мрирупошвм И оттфвеп пшата кадогуюТГЪ В ~ обработка дин ьд гуотодтуроаш nrtwpini>qiyr

Рисунок 1 — Блок схема алгоритма сборки пакета протокола транспортного уровня при привив

Подпункт 5.622. Таблица 6. Графа «Размер, байт». Для обозначений «SOR1 (Service Data Record)». «SDR2». «SDRn» заменить значение: 65517 на 65514.

Подпункт 5.62.3. Таблица 7. Графа «Тип данных». Для обозначения «SIGL (Signature Length)» заменить обохачение: SHORT на USHORT.

Подпункт 5.72.1 изложить е новой редакции:

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

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

Подпункт 5.72.3 дополнить абзацем:

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

Пункт 5.8. Таблица 13. Графу «Олисамге» для параметра «TL_RECONNECT_TO» изложить в новой редакции.

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

Подпункт 6.62.2. Таблицу 14 изложить в новой редакции:

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

Вит 7

Бит 6

Бит 5 Бит 4 Бит 3

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

Тип

Тип данных

Риме, байт

RL (Record Length)

М

USHORT

2

RN (Record Number)

М

USHORT

2

RFL (Record Flags)

М

BYTE

1

SSOD

RSOD

RPP

TMFE EVFE OSFE

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)

м

BNARY

3... 65498

абзац «GRP» и относящиеся к нему перечисления а), б) исключить:

абзац «RPP» и относящиеся к нему перечисления а) — г) изложить в новой редакции:

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

абзац «OID» изложить в новой редакции: дологхить рисунком —2а:

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



Кожмпрос EBTejTWCKLDWA. Сообцмю 1.

ЕВквпош »ш уровня потерт услуг (GBFE*1, (Я№Ы21); ECT8_SR_Cafc*WCJWA [СПЧГТ^СОК ССТЧХ.ОК. ИЭИ* Commend 09» (AOR=S, SZ=0, ACT=0, CCTW3jrejECAIJL_TRACK_QMAg

Покгаермрте. (^обцзтв 2. (ЕвТ&_т_ООММ№_Р*1Л не Сообыам» t

сст»сг_сомооир. cCT"CC_ok gp»ii

E9re_9R_TRACKJV0A С00бц»ие 3-ESawoHi шж уровня rmmepwni учуг (0ВЛ>1. ОМШ]

— i -    — -    — -    i    *

Рисунок 2a — Алгоритм способа испольэосаип OID*. Пункт 6.7.2. Таблицу 17 изложить в новой редакции:


Таблица 17 — Список подззписей сервиса EGTS.AUTH.SERVICE

Коп

Название

Описание

0

EGTS.SR.RECORD.RESPONSE

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

1

EGTS.SR.TERMJDENTITY

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

2

EGTS.SR_MODULE.DATA

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

3

EGTS.SR.VEHICLE.DATA

Подзапись применяется АС для передач! на телемашчоосую платформу информации о транспортном средстве

б

EGTS.SR.AUTH.PARAMS

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

7

EGTS.SR.ALfTH.lNFO

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

8

EGTS.SR.SERVTCE.INFO

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

9

EGTS.SR.RESULT.CODE

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

Подпункт 6.7.2.1. Абзац «RST» изложить в новой редакции;

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

дополнить абзацем (после последнего):

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

Подпункт 6.72.2. Абзац «ТЮ» изложить в новой редакции:

«* TID—уникальный идентификатор, назначаемый при программировании АС. Наличие мачения 0 в данном поле означает, что АС не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы «ЭРА-ГЛОНАСС» и однозначно определяет на» бор учетных данных АС. TID назначается при инсталляции АС как дополнительного оборудования и пере» даче оператору учетных данных АС (IMSI. IMEI. senal.id). В случае использования АС в качестве штатного устройства. ТЮ сообщается оператору автопроизводителем вместе с учетным данными (VIN. IMSI. IMEI);».

Подпункт 6.72.3. Таблица 21. Графа «Тип данных». Для «МТ (Module Туре)» заменить обозначение: «BYTE» на «SHORT».

Подпункт 6.72.4. Абзац «VPST» изложить в новой редакции (кроме перечислений а)—ж)):

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

Подпункт 6.7.2.8. Второй абзац изложить в новой редакции:

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

Подпункт 6.72.9. Первый абзац изложить в новой редакции:

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

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

перечисления 1), 2) и рисунки 4.5 изложить в новой редакции:

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

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

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

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

2) После регистрации АС в сети GSM или UMTS устанавливается GPRS сессия и TCP/IP соединение с сервером, информация об адресе которого уже записана в памяти АС. При прохождении процедуры аутентификации инфраструктура оператора анализирует параметр TID из подзаписи EGTS_SR_TERM_ IDENTITY (таблица 17). Если ТЮ имеет значение О. производится процедура конфигурирования путем установки параметров АС при помощи подзаписи EGTS_SR_COMMAND_DATA сервиса EGTS_COMMANDS_ SERVICE с использованием SMS. как описано в предыдущем способе.

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

№пкагрвцм а сети ЭВМ, UWTSpUB, IH8I] черва инфраструктуру штшогоогнригфа

— -    — ——    »


Июш> па РОИ агро. СоавшвпИЭ 1.

[EQT9_SR COMMANDJMIA {СТ^Г.СОН. ССРЮС..ОК. «МЛ Carmwid Data 0CT-2. СС&СОП_вГ MJIM. СП^'Тми доетут GPR81

Пфтинвп)И1ЯИ. C00SugMa'B2. [ECrrS_£2^_QQUUAMD_ОАТАмв юобцм*» 1.

(сгмгг.самсагг ccpcclok, ctxn

М; читав пврангре. Сообщение 9.

RUSTS SR COMAAND_QATA<CT<T СО«. CCTHX.OK, Ct>1); Сояи1Н^&(<ЬТ^са>ВВ10а1ДС^»8.ОТ"»яиоипорга>рмр>,И

Поатвераленм. Сообщат*. [RQre_aR_OOUMAMD_OOTiMa cnafkmv 3.

(CT-ctjccmconf. сетчаток. ссм д

Vtittwa переищи. Сообщение 1 [EOTS_sa_CCMIiWJ>jyjrA <CT-CT_CCW. CCT*CC_OK CD-2); Ommd Ml (АСТ-в. Са^СОПЦМГЦО. DTNJNfTJDJ

Портвервавм». Сообщат 6. [EOTS_SfLC<AiUAN D_DATA w т-Лтш* S

(CT-ct_comc»f. cci*ccjk cmh

ДАННЬЕ А/ТЕНТИФИКАЦИИ. Оаобщат 7. IE 07в_8я_твчмj aeimTY]

Пспгверао)внт.Соовщат& [E(n^_6^JCGORD_REBPOH6E Hi шобцмв 7]

ДОННЫЕ АУТЕНТИФИКАЦИИ- СовВирм» В.

{E<3re_SR_v&iaEjaAwj

Пвдпервдааа. Сообирне 10.

_[EgTgjB^JEOORD_RESPOWSE № сообцаав В]

РвяъглгАУга1Ш*нКАЦии. сообщат 11. PGT8_S*_RE3U.T..G00E]

Педтвералаав. Сообщение 12. №ЭТ9_В1_РЕС0П?_гевР0КЭЕ * сообщение 11]

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



^^teraw*T22P£5SttS2S£2E5SBS!^—

ДЦННЬОУШГГИОЖМ»». СтгЛтшт 1. [EGT8jaHJTERMJ0EHTTTY {!■>*. IMEL M8I)]

Подтворит»! ив. Coo&newo 2. [E<nS_S^_REG0RQJESP0N5E ю иообщечв 1]

ДАННЫЕ АУТЕНПЮИСЛЦИИ. Сообщим Э. [ЕОТ8_8 HJJB4 CLE_pAW]

Под1ввмацаи на. Сообщим*

(ЕОгга_&В_ЯЕОСМО_Ю9РОН8Е не еообцми Э]

Ц|нш ламмтра. СсхДценив В. {E0T9^8^COMi4IWJ>«A{C1^Cr.COM. ССП^СС^ОК. CCW): СапттшкЗ Pete (АСТ«2. CCO«teiB_UHfTJP. РТеЦНПЦ&Я

Под1еар»оавмаГппбп1им& (EOre.ea.CSMUAMO.CMTA    5

(СГ=СТ СОмСО№, ССГ=СС OK,CD*g

PBMIbTXT АУТЕНТИММЩИИ. Совбщмш Г. [E)STS_8RJS8ULT_COQE (И2>»«ПВ_РСJDJFOUND3

Подпертой ив. СкЯцвнт& [BTTS_9R_RECORD„№SPOHBE m свобщмя 7] fl№HbEjWTBmW§(AI*«. Cae6LW*0. [ЕСГГ^_8Я_ТЕЯА1_Ю0ЛТТУ (П MKFW.U И ГТ_Б. IUEI, №Qi]]

ПздгирцДиЧ. C«06u|tHM 10.

(OTS_SR_№QOfta_№8PO«8E ^    g]

ДАННЫЕ АУТЕНП40ИСАЦИИ. СооОщмя 11. [EGTS_SRJVB1CLEJ3Xn]

ГУдт—рщш—- Сообщение 12. [Earr8_afU«CORD_PESPOMSE на сообщение 11]

РЕЗУЛЬТАТ АУТЕНТИФИКАЦИИ. Саобщм 13. _(Е<ЛЕ_ЗР^?£Зи1Т_СОО EJ_

Подтпосиюжио. Сообщение 14. [EOTB_$RJ^ECORP_H£aPONBe на сообщим» 13]

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


в


Подпункт 6.7.3.1. Абзац «СТ-тип команды». Перечисления г), д) изложить в новой редакции:

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

д) 0101 — СТ_СОМ — команда для выполнения на транспортном средстве:»;

абзац «SID» изложить в новой редакции:

«- SJD — идентификатор отправителя данной команды или подтверждения. В случае передачи от АС на ТП подтверждения на команду или результат выполнения команды (тип команды CT.COMCONF. CT_MSGCONF. CT_DEL1V) необходимо копировать значение данного поля из ранее пришедшей на АС команды. При инициации отправки подэаписи EGTS_SR_COMMAND_DATA на стороне АС данное поле имеет значение 0;»:

абзац «АС» (после таблицы 29) изложить в новой редакции:

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

абзац «ADR» (после таблицы 31) изложить в новой редакции:

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

Подпункт 6.7.3.2. Первый абзац изложить в новой редакции:

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

таблицу 32 изложить в новой редакции

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

Название гоыанд»

Код

Тип. чюо и предельнее знечони»

параметров

Описание

EGTS_RAW_DATA

0x0000

BINARY (до 65200 байт)

Команда для передачи произвольных данзшх. Применяется. например, для передам команд, сообщений и данных на периферийные устройства, модули, подключении» к основному блоку АС. е определяемом данным модулем формате. При этом АС не должна анализировать данные из поля ОТ и а неизмо» ■ юм виде передать их по адресу, определяемому полем ADR

EGTS_TEST_MODE

0x0001

BYTE

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

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

EGTS_CONFlG_RESET

0x0006

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

EGTS SET AUTH CODE

0x0007

BINARY

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

EGTS_REST ART

0x0008

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

таблица 33. Название команды EGTS_SELF_TEST_RESULTh соответствующие параметры исключить; таблицу 34 изложить в новой редакции:

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

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

код

Тип

па р«ме тра

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

Описание

Применимость"

Возможность

изменения^

Радио mule

EGTS_RADIO_MUTE_DELAY

0x0201

INT

0

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

ДО

Да

EGTS_RAOIO_UNMUTE_OEIAY

0x0202

INT

0

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

ДО

Да

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

£GTS_GPRS_Af>N

0x0203

STRING

и»

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

ДО.ШСД

Да

EGTS^SERVER. ADDRESS

0x0204

STRING

Адрес и порт сервера для связи с использованием ТСР/Р протокола

ДО.ШСД

Да

EGTS_SIM_PIN

0x0206

INT

0

PIN-код SIM-карты

ДО.ШСЭ.ШСД

Да

EGTS_INT_MEM_TRANSMIT_INTERVAI.

0x0206

INT

60

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

ДО.ШСЭ.ШСД

Да

EGTS..INT. MEM TRANSM ГГ ATTEMPTS

0x0207

INT

10

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

ДО.ШСЭ.ШСД

Да

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

£GTS_TEST_REGlSTRATlON_P£RlOO

0x0242

INT

5

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

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

ДО.ШСЭ.ШСД

Да


(Продолжение Изллеивния N?1 к ГОСТ Р 54619—2011)


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

код

Гип

па рема тре

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

Описание

Применимость'*

ВОЗМОЖНОСТЬ

изменения*'

EGTS.TEST_MOOE_ENO_OISTANCE

0х020А

INT

300

тестирования еыкпочаетсяавтома-тичвски. м

ДО.ШСЭ.ШСД

Да

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

EGTS.GARAGE.MODE.END.DISTANCE

0x020В

INT

300

«Автосервис* выключается автоматически, м

до

Да

EGTS.GARAGE_MOOE.PIN

охогос

INT/0..A

0

Л tw ия. сигнализирующая, что АС находится в режиме «Автосервис*: NONE — нет сигнализации режима; X — PIN.X линия активная, когда система находится в данном режиме

ДО

Да

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

EGTS.GNSS.POWER.OFF.TIME

0x0301

INT

500

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

ДО

Да

EGTS_GNSS_OATA_RATE

0x0302

INT/1.2.5.10

Определяет* си производителем АС

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

ДО.ШСЭ.ШСД

Нет

EOTS_GNSS_MIN_ELEVATION

0x0303

INT.5. .15

15

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

ДО.ШСЭ.ШСД

Нет

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

EGTS.UNITJO

0x0404

INT

0

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

ДО.ШСЭ.ШСД

Да


UI ог—6 V 9PS d 10OJ » t *N ЬП№


Имя переметов

код

Гил

периметре

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

Описание

Применимость"

Возможность

изменения*'

EGTSJJNIT JMEI

0x0405

STRING

Номер IMEI

ДО.ШСЭ.ШСД

Нет

EGTS_UNIT_RS465_BAU0_RATE

0x0406

INT

19200

Скорость порта RS485. биТАС

ДО.ШСЭ.ШСД

Да

EGTS_UNIT_RS465_STOP_BITS

0x0407

INT

1

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

ДО.ШСЭ.ШСД

Да

EGTS„UNIT_R$4e5J»ARITY

0x0406

INTO.1.2

0

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

0 — проверка типа ООО.

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

ДО.ШСЭ.ШСД

Да

EGTS_UNIT_HOME_OISPATCHER JO

0X0411

INT

0

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

ДО.ШСЭ.ШСД

Да

EGTS.SE RVICE _AUTH _ME THOD

0x0412

INT

1

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

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

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

ДО.ШСЭ.ШСД

Да

EGT5_SERVER_CHECK_IN_PERIOO

0x0413

INT

30

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

до. ШСД

Да

EGTS_SERVER_CHECKJN_ATT£MPTS

0x0414

INT

5

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

ДО. ШСД

Да

EGT8_SERVER_PACKET_TOllT

0x0415

INT

5

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

ДО. ШСД

Да


'ив Изменения N?1 к ГОСТ Р 54619—2011)


Имя переметов

код

Тип

пареметрв

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

Описание

Применимое »ьп

Возможность

изменения*'

EOTS SERVER PACKET RETRANSMIT ATTEMPTS

0x0416

INT

3

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

ДО. ШСД

Да

EGTS_UNIT_M IC_LEVEL

0x0417

INT.0 10

8

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

ДО.ШСЭ.ШСД

Да

EGTS_UNIT_SPK_LEVEL

0x0418

INT.0...10

в

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

ДО.ШСЭ.ШСД

Да

11 «ДО» — для АС. исполненной • конфигурации дополжтельного оборудования, «ШСЭ* — для АС. исполненной я конфигурации штатного оборудовав я и предназначенной для реализации только базовой услуги системой «ЭРА-ГЛОНАСС»; «ШСД» — для АС. исполненной в конфигурации штатного оборудования и предназначенной для реализации дополнительных, кроме базовой, услуг системой «ЭРА-ГЛОНАСС»

й «Да» ■— а этой графе охачает. что установленное начальное значение параметра АС может изменяться после начальной установки АС. «Нет* — что установление начальные значения не подлежат изменению е процессе применения АС.


-EGTS GPRS WHITE LIST;

(l tOZ—6 V 9PS d lOOJ »14N ЬП№


-    EGTS_UNIT_SERIAL NUMBER;

-EGTS UNIT_HW VERSION;

♦    EGTS UNIT SW VERSION;

-    EGTS_UNIT_VENOOR_ID;

-    EGTS_UNIT_LANGUAGE_ID;»; дополнить обозначениями параметров:

«- EGTS_INT_MEM_TRANSMIT_INTERVAL;

-    EGTS_INT_MEM_TRANSMIT_ATTEMPTS».

w

Пункт 6.7.3 дополнить подпунктом — 6.7.3.3 и рисунками 7а. 76:

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

[




Квтя ЕОТЗ_ECAi-kJ*33_RECl СппАциив 1. [ЕОТа.вЯ.ССЗМААЮ »ТА(СТ=еУ_СОЫ, ССГ=СС_ОК, СО=1); ОогштгЛ ОАДООД shj.act-ю. СО>EGTS^EWLLJ4BDJCOJ

Пц)|гщицри1в Сообщи—2. [EGT8_8fL.C0MM№pJMTA т тобомнна 1 (CT^CT_COMOO№. ССТ«СС_ОК, СОЧI_

мао

Рисунок 7з — Отправка команды EGTS_ECALL_MSO_REQ no SMS



АС

Эти—горимцииАСиат—туигт* ши форы

Зепроо «им пвр—грк. СваОщи— 1. (Е]ЭТв_8а_СОММАМ>_СЛТА (СТ=СТ_СОИ, ССТ=СС_ОК, СОМ); СвпишМ D*i (A0R-0.32*0, АСТИ. ССР«ГЯЦ*ЯГ-J№01

Псятввцтдииа Сообцвшей. [EGT8_£B^_REC0RD_РЕДР0Ы8Е на оообщшиа 1] [KrrajSR.COUMANO-QATAт rrnffi wuiK t

_(CM7T_C0MC0NF. CCT-CC.0K. C«>S):_

Conrand Oau (ADR»*, ССО«Щ_имг_ЯЕ1| 0T-4UB number]

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


Пункт 7.2.3 исключить.

Подраздел 7.3. Табгмца 40. Название «EGTS_SR_MSD_DATA*. код 50 и описание исключить.

Пункт 7.3.2. Абзац «АТМ» (после таблицы 41) дополнить примечанием:

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

абзацы «XAAV, YAAV. ZAAV» (после таблицы 42) изложить в новой редакции:

«♦ XAAV — значение линейного ускорения по оси X: 0.1 м/с2;

• YAAV — значение линейного ускорения по оси Y: 0.1 м/с3;

- ZAAV—значение линейного ускорения по оси Z: 0.1 м/с2. Разрешающая способность полей ускорения должна быть не более 0,01 G ».

Пункт 7.3.3. Табгмца43. Графа «Размер, байт». Для «MSD» заменить значение: «0...1024» на «0...116»:

абзац «MSD» (после таблицы 43) изложить в новой редакции:

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

Пункт 7.3.4 исключить.

Пункт 7.3.5. Таблица 45. Графа «Размер, байт». Для «TDS1, TDS2, TDS25S» заменить значение: 8 на «1...12».

Подраздел 7.5 изложить е новой редакции (кроме наименования, таблиц 47.49): таблицу 48 исключить:

«7.5.1 Список и описание команд АС и подтверждений, необходимых для реализации базовой услуги в соответствии с ГОСТ Р 54721. а также список параметров АС. представлены в таблицах 47 и 49.

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

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

•    EGTS_ECALL_TEST_NUMBER;

-    EGTS_ECALL_SIGNAL_INTERNAL;

-    EGTS_ECALL SIGNAL.EXTERNAL.

•    EGTS_ECALL_SOS_BUTTON_TlME:

-    EGTS_ECALL_CCFT;

-    EGTS_ECALL_INVTTATX3N_S*GNAL_CXJ RATION:

•    EGTS_ECALL_SEND_MSG_PERIOD:

-    EGTS ECALL.AL ACK_PERIOO;

-    EGTS_ECALL_MSD_MAX_TRANSMISSION_TIME;

•    EGTS_ECALL_NAD_DEREGISTRAT10N_TIMER

-    EGTS_ECALL_DIAL_DU RATION;

•    EGTS_ECALL_AUTO_DlAL_ATTEMPTS;

-    EGTS_ECALL_MANUAL DIAL_ATTEMPTS:

•    EGTS_ECALL_MANUAL_CAN_CANCEL;

•    EGTS_ECALL_SMS_FALLBACK_NUMBER:

•    EGTS_CRASH_RECORD_TlME:

-    EGTS_CRASH_RECORD_RESOLimON;

•    EGTS_CRASH_PRE_RECORO_T!ME

-    EGTS_CRASH_PRE_RECORD_RESOLUTION:

-    EGTS_TRACK_RECORD TIME;

•    EGTS_TRACK_RECORD_RE SOLUTION;

•    EGTS_TRACK_PRE_RECORD_TIME;

-    EGTS_ECALL_BLACK_LIST:

•    EGT3_VEHKM_E_VTN.

-    EGTS_VEHCLE_TYPE:

•    EGTS_VEhUCLE_PROPULSION_STORAGE_TYPE.»: таблицу 47 изложить в новой редакции.

Таблица 47 — Список команд для АС

Название

команды

Коя

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

Описание

EGTS.ECALL.REQ

0x0112

ВУТЕ/0,1

Команда на осуществление экстренного вызова с АС. Используется только через SMS.

Команда содержит один параметр, который определяет тип события:

0    — ручной вызов:

1    — автоматический вызов

EGTS_ECALL_MSO_REQ

0x0113

BINARY (MID INT. TRANSPORT BYTE)

Команда на осуществление повторной передачи МНД. Используется только через SMS.

Команда содержит два параметра:

MD — идентификатор сообщения запрашиваемого МНД. Если параметр MID = 0. то отправляется новое сообщение:

Намаяна

команды

Код

Тмл. ЧДСЛО и прсд*пь«ъ#е ян ачешм параметров

Описями*

TRANSPORT — тип испо/ъзуемого АС канала при отправке МНД:

0    — любой, на усмотрение АС:

1    — через голосовой канал:

2    — через SMS

EGTS.ACCEL.DATA

0x0114

Команда на осуществление передачи данных профиля ускорения. Используется только через SMS

EGTS_TRACK_DATA

0x0115

Команда на осуществление передачи данных траектории движения. Используется только через SMS

EGTS ECALL DEREGISTRATION

0x0116

Команда на осуществление дерегистрации АС в сети подвижной радиотелефонной связи

таблицу 49 изложить в новой редакции:

Таблица 49 — Список параметров АС

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

код

Тип

ларяме тря

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

Описание

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

Возможность

изменения'

Уст»<оаки общего м аз качания

EGTS_ECALL_TEST_N UMBER

0x0200

STRING

Телефонный номер для тестовых звомтСв а системе «ЭРА-ГЛОНАССя

ДО.ШСЭ.ШСД

Д«

Конфигурация и ксмфигурвциом»шв данные услуг Базовая услув системы «ЭРА-ГЛОНАСС» по ГОСТ Р 54721

EGTS_ECAll_ON

0x0210

BOOLEAN

TRUE

возможиость осуществления зк-стремного вызова

ДО.ШСЭ.ШСД

Да

EGTS_ECALL.CRASH .SIGNAL. INTERNAL

0x0211

BOOLEAN

TRUE

Если для определения события вварит используется встроенный в АС измеритель ускорены я

ДО

Да

EGTS_ECALL_CRA8H_SIGNAL_EXTERNAL

0x0212

BOOLEAN

TRUE

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

ДО

Д«

EGTS_ECALL_SOS_BUTTON_TIME

0x0213

INT

200

Длительность втечеитекоторой должка быть нажата кнопка «Экет-реитый вызов», для инициации эк-стреигого вызова независимо от состояния литии зажигайте. мс

ДО

Д«

EGTS _ECAU.NO .AUTOMATIC. TRIGGER! NO

0x0214

BOOLEAN

FALSE

Процедура инициализации режима «Экстренный вызов* в автоматическом режиме отключена

ДО.ШСЭ.ШСД

Да

EGT8.ASM5.TRE8HOLO

0x0215

FLOAT

1.5

Порог срабатывания датчика автоматической идентификации события ДТП в значения нтдекса возможного ущерба ASI15

до

Да


(tlOZ—6t9PSd 10OJ* t W WHt


Имя перемете

Код

Гип

периметра

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

Описание

Применимость"

Возможность

изменения*'

EGTS.ECALL.MODE.PIN

0x0218

INT/О.. Л

0

Линия, сигнализирующая, что система находится в режиме «ЭРА».

NONE — нет сигнализации режима:

X — pin.X лим» активная, когда система находится а данном режиме

ДО

Да

EGTS.ECALL.CCFT

0x0217

INT

80

Длительность счетчика автоматического прекращения звонка, мин

до.шсэ.шсд

Да

EGTS_ECALL_NVITATlON_SIGNAL_

OURATION

0x0218

INT

200

Длительность сигнале INVITATION, мс

до.шсэ.шсд

Да

EGTS.ECALL.SENO. MSG.PERIOO

0x0219

INT

200

Период сообщения SENO MSG. мс

до.шсэ.шсд

Да

EG TS _ EC All. At _ACK _P E RIOO

Ox 021A

INT

200

Период AL-ACK.mc

до.шсэ.шсд

Да

EGTS.ECALL.MSO.MAX. TRANSM ISSION_TIME

0x021В

INT

20

Максимальная длительность передачи мнд, с

до.шсэ.шсд

Да

EGTS_ECAU_NAO_OE REGISTRATION. TIMER

0x0210

INT

8

Время, по истечении которого GSM или UMTS модуль прекращает регистрацио а сети.ч

до.шсэ.шсд

Да

EOTS_ECAU._OIAL.OUR AT ION

0X021E

INT

8

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

до.шсэ.шсд

Да

EGTS_E CALL. AUTO. OlAL. ATTEMPTS

0x021F

INT

10

Число попыток дозвона при автоматически инициированном вызове.

Значение не может быть установлено е 0

до.шсэ.шсд

Да

EGTS..ECALL.MANUAL. OIAL..ATTEMPTS

0x0220

INT

10

Число попыток дозвона при экстренном вызове, инициированном вручную.

Значение не может устанавливаться в 0

до.шсэ.шсд

Да


'ив Изменения N?1 к ГОСТ Р 54619—2011)


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

Код

Тип

пареме грв

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

Описание

Применимое тьп

ВОЗМОЖНОСТЬ

изменения*'

EGTS.ECALL MANUAL,CAN.CANCEL

0x0222

BOOLEAN

TRUE

TRUE — экстренный вызов, ним* циированный вручную, может быть превращай со стороны по/ъэоаате-ля

ДО.ШСЭ.ШСД

Да

EGTS.ECALL.SMS FALLBACK NUMBER

0x0223

STRING

‘112"

Номер, по которому АС посылает SMS с минимальным набором данных по запросу от оператора системы

ДО.ШСЭ.ШСД

Да

Запись профиля ускоретыя при ДТП

IGNITION_OFF_FOLLOW_UP_TIM£1

0x0224

INT

120

Промежуток времени, а течение которого осуществляется запись профиля ускорения при ДТП при выключенном эажигэиж. мин

до

Да

IGNITlON_OFF_FOLLOW_UP_T1ME2

0x0225

INT

240

Промежуток времени, в течение

кот ор ого осуществляв тс* огределе-

ном зажигании, мин

до

Да

EGTS_CRASH_RECORO_TIME

0x0251

INTA .250

250

Время записи информации о профиле ускорения при ДТП. мс

до

Да

EGTS_CRASH_RECORO_RE SOLUTION

0x0252

INT/1..S

1

Продолжительность одного отсчета при записи профиля ускорятся при ДТП. мс

ДО

Да

EGT S,CRASH_PRE_RECORD_TIME

0x0253

INT/0..20000

20000

время записи информации о профиле ускоретя до того, как со-Сытив ДТП наступило, мс

ДО

Да

EGTS. CRASH, PRE.RECORO RESOLUTION

0x0254

INT5.. 100

5

Продолжительность одного отсчета при записи профиля ускорения до того, каксобытие ДТП наступило. мс

ДО

Да


UI ог—6 V 9PS d 10OJ » t W ЬП№


N)

О


Имя перемета

код

Гип

первметра

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

Описание

Применимое гъп

ВОЗМОЖНОСТЬ

изменения*'

Запись траектории движения при ДТП

EGTS.TRACK_RECORO.TIME

0x 025A

INTJ0..-1S0

10

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

Установка значения данного параметра. равного 0. означает, что запись данных о траектории демке-ни я при ДТП не производится

ДО

Да

EQTS_TRACK_PRE_RECORD_TlM£

0x025B

INTO..600

20

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

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

ДО

Да

EGTS_TRACK_RECORO .RESOLUTION

0X025C

INT.1 30

10

Продолжительность одного отсчета при записи траектории движения транспортного средства.

100 мс

ДО

Да

Параметры транспортного средства

EGTS.VEH ICLE.VN

0x0311

STRING

VIN а соответствии с (б {приложение 7)]

ДО.ШСЭ.ШСД

Да

EGTS.VEHICLE PROPULSION. STORAGE. TYPE

0x0313

INT

0

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

а} бит 31—в: не используется; 6} бит 5: 1 — водород; в) бит 4; 1 — электричество (более 42 в и 100 А/ч>;

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

до.шсэ.шсд

Да


(Продолжение Изллеивния N?1 к ГОСТ Р 54619—2011)


м


Имя переметов

код

Гип

периметре

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

Описание

Применимость"

ВОЗМОЖНОСТЬ

изменения?

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

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

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

EG Т S_V EH ICL £_ TYP Е

0x0312

INT

0

Тит транспортного средства:

1    — пассажирский. <М1>;

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

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

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

$ — тяжелая грузовая машина

(N2);

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

(N3);

7    — мотоцикл (Не);

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

0 — мотоцикл {13а};

10    — мотоцикл (14е);

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

12    — мотоцикл (16а);

13    — мотоцикл <17е)

ДО.ШСЭ.ШСД

Да

11 «ДО* — для АС. исполненной е конфигурации дополнительного оборудования. «ШСЭ» — для АС. исполненной а конфигурации шт аеиия и предназначенной для рвализацп* только базовой услуги системой «ЭРА-ГЛОНАСС»; «ШСД» — для АС. исполненной в коифигу оборудования и предназначенной для реализация* дополнительных услуг, кроме базовой по ГОСТ Р 54721

з «Да» — в этой графе означает, что установленное начальное значение параметра АС монет изменяться после иачагънойустанов что установленные начальные зкачемня не подлежат изменению в процессе применения АС

атногооборудо-рации штатного

«и АС. «нет» —


UI ог—6 V 9PS d 10OJ » t *N ЬП№


Пункт 8.1 изложить 8 новой редакции:

«8.1 Сообщение AL-ACK, направляемое системой «ЭРА-ГЛОНАСС* в сторону АС и содержащее подтверждение корректности минимального набора данных, принятого с использованием тонального модема. должно высылаться также посредством использования тонального модема».

Пункт 8.2. Таблица 50. Графу «Значение» для наименования «Признак корректности полученных

данных» изложить в новой редакции:

«0 — полученные данные корректны (Positive АСК):

1 — завершение вызова (Oeardown)».

Элемент «Библиография» дополнить позициями —[6] — (9]:

«[6] Технический регламент Таможенного союза о безопасности колесных транспортных средств ТР ТС (018/2011) (Утвержден решением Комиссии Таможенного союза от 9 декабря 2011 г. № 877 (в редакции решения Совета Евразийской экономической комиссии от 30.01.2013 Мв 6)

[7]    Правила ЕЭК ООН N9 94-01

[8]    Правила ЕЭК ООН Ne 95-02

[9]    ISO/IEC 10967-1:2012


Единообразные предписания, касающиеся официального утверждения пассажирских транспортных средств в отношении защиты водителя и пассажиров при фронтальном столкновении, включая дополнения 1—3 Единообразные преописания, касающиеся официального утверждения пассажирских транспортных средств в отношении защиты водителя и пассажиров в случае бокового столкновения, включая дополнение 1 Информационные технологии. Арифметика, не зависимая от языка. Часть 1. Арифметические операции с комплексными целыми числами и с плавающей запятой (Information technology — Language independent arithmetic — Part 1: Integer and floating point arithmetic)».

Библиографические данные. Заменить слова: «автомобильная система» на «автомобильная систе-ма/устройство».

(ИУС N9 92014 г.)

22