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

ГОСТ Р 54619-2011

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

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

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

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

Global navigation satellite system. Accident emergency response system. Protocols of data transmission from in-vehicle emergency call system/device to emergency response system infrastructure*

_____________

* Измененная редакция, Изм. N 1.

ОКС 33.070.40

Дата введения 2012-09-01

Предисловие

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

(Измененная редакция, Изм. N 1).

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

1 РАЗРАБОТАН Открытым акционерным обществом "Навигационно-информационные системы" (ОАО "НИС") и Некоммерческим партнерством "Содействие развитию и использованию навигационных технологий".

(Измененная редакция, Изм. N 1).

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

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

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

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

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

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

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

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

ВНЕСЕНО Изменение N 1, утвержденное и введенное в действие Приказом Росстандарта от 22.04.2014 N 397-ст c 01.09.2014

Изменение N 1 внесено изготовителем базы данных по тексту ИУС N 9, 2014 год

Введение

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

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

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

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

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

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

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

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

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

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

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

- производителями автомобильных систем/устройств экстренного реагирования при авариях (терминалов "ЭРА-ГЛОНАСС");

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

- оператором системы "ЭРА-ГЛОНАСС";

- разработчиками и поставщиками услуг на основе навигационно-информационной платформы системы "ЭРА-ГЛОНАСС".

(Измененная редакция, Изм. N 1).

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

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

Настоящий стандарт устанавливает требования к протоколам обмена данными между автомобильной системой/устройством вызова экстренных оперативных служб и инфраструктурой системы "ЭРА-ГЛОНАСС", включая требования к протоколу обмена данными, связанными с предоставлением системой "ЭРА-ГЛОНАСС" базовой услуги по ГОСТ Р 54721 в целях выполнения требований технического регламента [6] и ГОСТ Р 54620.

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

Примечания

1 Автомобильная система вызова экстренных оперативных служб предназначена для оснащения транспортных средств категории М1, входящих в область применения Правил ЕЭК ООН [7], [8], и N1, входящих в область применения Правил ЕЭК ООН [8].

2 Автомобильное устройство вызова экстренных оперативных служб предназначено для оснащения транспортных средств категории М1, не входящих в область применения Правил ЕЭК ООН [7], [8], и N1, не входящих в область применения Правил ЕЭК ООН [8], а также транспортных средств категорий М2, М3, N2 и N3.

3 Сроки оснащения транспортных средств системами/устройствами вызова экстренных оперативных служб устанавливаются в [6].

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

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

(Измененная редакция, Изм. N 1).

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

(Измененная редакция, Изм. N 1).

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

- канальный;

- сетевой;

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

- сеансовый;

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

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

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

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

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

Таблица 1 - Соответствие уровней модели OSI, стека протоколов TCP/IP и протоколов системы "ЭРА-ГЛОНАСС"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

(Измененная редакция, Изм. N 1).

5.6.2.4 На каждый пакет типа ЕСТS_РТ_АРРDАТА или EGTS_PT_SIGNED_APPDATA, поступающий от АС на телематическую платформу или от нее на АС, должен быть отправлен пакет типа EGTS_PT_RESPONSE, содержащий в поле PID номер пакета из пакета EGTS_PT_APPDATA или EGTS_PT_SIGNED_APPDATA

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

Рисунок 2 - Взаимодействие АС и телематической платформы на уровне пакетов транспортного уровня

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

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

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

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

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

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_AL. В случае отсутствия параметра SMSC_A используется SMSC из SIM карты;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ж) А0-BF - зарезервировано;

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

к) Е0-FF - зарезервировано;

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

а) 1 - поле EVID присутствует;

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

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

а) 1 - поле OID присутствует;

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

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

6.7.2 Сервис EGTS_AUTH_SERVICE

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

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

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

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

(Измененная редакция, Изм. N 1).

6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

- TID - уникальный идентификатор, назначаемый при программировании АС. Наличие значения 0 в данном поле означает, что АС не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы "ЭРА-ГЛОНАСС" и однозначно определяет набор учетных данных АС. TID назначается при инсталляции АС как дополнительного оборудования и передаче оператору учетных данных АС (IMSI, IMEI, serial_id). В случае использования АС в качестве штатного устройства, TID сообщается оператору автопроизводителем вместе с учетными данными (VIN, IMSI, IMEI);

- HDIDE - битовый флаг, который определяет наличие поля HDID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);

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

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

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

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

- NIDE - битовый флаг, определяющий наличие поля NID в подзаписи (если бит равен 1, то поле передается, если 0, то не передается);

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

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

- HDID - идентификатор домашней телематической платформы (подробная учетная информация об АС хранится на данной платформе);

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

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

- LNGC - код языка, предпочтительного к использованию на стороне АС, в соответствии с [4], например, "rus" - русский;

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

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

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

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

6.7.2.3 Подзапись EGTS_SR_MODULE_DATA

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

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

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

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

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

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

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

- MD - код модификации программной части модуля;

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

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

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

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

(Измененная редакция, Изм. N 1).

6.7.2.4 Подзапись EGTS_SR_VEHICLE_DATA

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

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

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

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

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

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

б) биты 4-0;

в) 0001 - пассажирский (Class М1);

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

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

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

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

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

к) 0111 - мотоцикл (Class L1е);

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

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

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

п) 1011 - мотоцикл (Class L5e);

р) 1100 - мотоцикл (Class L6e);

с) 1101 - мотоцикл (Class L7e);

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

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

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

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

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

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

е) бит 1: 1 - дизель;

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

(Измененная редакция, Изм. N 1).

6.7.2.5 Подзапись EGTS_SR_AUTH_PARAMS.

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

Таблица 23 - Формат подзаписи EGTS_SR_AUTH_PARAMS сервиса EGTS_AUTH_SERVICE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.7.2.6 Подзапись EGTS_SR_AUTH_INFO

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

Таблица 24 - Структура подзаписи EGTS_SR_AUTH_INFO сервиса EGTS_AUTH_SERVICE

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

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

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

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

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

6.7.2.7 Подзапись EGTS_SR_SERVICE_INFO.

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

Таблица 25 - Структура подзаписи EGTS_SR_SERVICE_INFO сервиса EGTS_AUTH_SERVICE

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

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

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

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

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

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

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

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

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

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

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

г) 11 - низкий.

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

6.7.2.8 Подзапись EGTS_SR_RESULT_CODE

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

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

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

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

(Измененная редакция, Изм. N 1).

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

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

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

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

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

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

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

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

Рисунок 4 - Алгоритм конфигурации АС с использованием SMS

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

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

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

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

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

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

Рисунок 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_AUTH_PARAM, содержащей параметры, необходимые для осуществления шифрования и/или алгоритма расширенной авторизации. Если шифрование и алгоритм расширенной авторизации не используются, то вместо подзаписи EGTS_SR_AUTH_PARAM телематическая платформа может отправить подзапись EGTS_SR_RESULT_CODE с результатом проведения процедуры авторизации АС.

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

6.7.3 Сервис EGTS_COMMANDS_SERVICE

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

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

Таблица 28 - Описание подзаписей сервиса EGTS_COMMAND_SERVICE

6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA.

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

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

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

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

а) 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_DELIV):

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

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

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

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

д) 0100 - CC_NFOUND - команда для удаления не найдена;

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

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

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

- SID - идентификатор отправителя данной команды или подтверждения. В случае передачи от АС на ТП подтверждения на команду или результат выполнения команды (тип команды CT_COMCONF, CT_MSGCONF, CT_DELIV) необходимо копировать значение данного поля из ранее пришедшей на АС команды. При инициации отправки подзаписи EGTS_SR_COMMAND_DATA на стороне АС данное поле имеет значение 0;

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

а) 1 - поля ACL и АС присутствуют в подзаписи;

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

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

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

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

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

а) 0 - СР-1251;

б) 1 - IA5 (CCITT T.50)/ASCII (ANSI Х3.4);

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

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

д) 4 - бинарные данные;

е) 5 - JIS (X 0208-1990);

ж) 6 - Cyrillic (таблица Е.1 (приложение Е));

и) 7 - Latin/Hebrew (таблица Е.3 (приложение Е));

к) 8 - UCS2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблицы 32, 33, 34. (Измененная редакция, Изм. N 1).

(Измененная редакция, Изм. N 1).

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

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

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

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

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

- EGTS_GPRS_APN;

- EGTS_SERVER_ADDRESS;

- EGTS_SIM_PIN;

- EGTS_AUTOMATIC_REGISTRATION;

- EGTS_TEST_MODE_END_DISTANCE;

- EGTS_GARAGE_MODE_END_DISTANCE;

- EGTS_TEST_REGISTRATION_PERIOD;

- EGTS_GNSS_POWER_OFF_TIME;

- EGTS_GNSS_DATA_RATE;

- EGTS_GNSS_MIN_ELEVATION;

- EGTS_UNIT_ID;

- EGTS_UNIT_IMEI;

- EGTS_UNIT_HOME_DISPATCHER_ID;

- EGTS_INT_MEM_TRANSMIT_INTERVAL;

- EGTS_INT_MEM_TRANSMIT_ATTEMPTS.

(Измененная редакция, Изм. N 1).

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

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

Рисунок 7б - Запрос значения параметра

(Введен дополнительно, Изм. N 1).

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

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

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

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

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

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

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

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

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

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

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

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

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

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

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

а) 00 - периферийное оборудование;

б) 01 - АС;

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

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

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

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

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

6.7.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA

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

Таблица 38 - Структура подзаписи EGTS_SR_SERVICE_FULL_DATA сервиса EGTS_FIRMWARE_SERVICE

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

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

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

6.7.4.3 Подзапись EGTS_SR_RECORD_RESPONSE

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

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

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

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

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

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

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

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

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

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

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

7.2.3 (Исключен, Изм. N 1).

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.

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

(Измененная редакция, Изм. N 1).

7.3.1 Подзапись EGTS_SR_RECORD_RESPONSE

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

7.3.2 Подзапись EGTS_SR_ACCEL_DATA

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

Таблица 41 - Структура подзаписи EGTS_SR_ACCEL_DATA сервиса EGTS_ECALL_SERVICE

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

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

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

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

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA

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

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

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

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

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

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

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

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

(Измененная редакция, Изм. N 1).

7.3.4 (Исключен, Изм. N 1).

7.3.5 Подзапись EGTS_SR_TRACK_DATA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- SPDL, SPDH - младшие (SPDL) и старшие (SPDH) биты параметра скорости (используется 15 бит). Измеряется в 0,01 км/ч. Максимальное значение скорости, передаваемое в данном поле, составляет 327,67 км/ч;

- DIRH (Direction the Highest bit) - старший бит (8) параметра DIR;

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

(Измененная редакция, Изм. N 1).

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

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

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

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

- EGTS_ECALL_CCFT;

- EGTS_ECALL_INVITATION_SIGNAL_DURATION;

- EGTS_ECALL_SEND_MSG_PERIOD;

- EGTS_ECALL_AL_ACK_PERIOD;

- EGTS_ECALL_MSD_MAX_TRANSMISSION_TIME;

- EGTS_ECALL_NAD_DEREGISTRATION_TIMER;

- EGTS_ECALL_DIAL_DURATION;

- EGTS_ECALL_AUTO_DIAL_ATTEMPTS;

- EGTS_ECALL_MANUAL_DIAL_ATTEMPTS;

- EGTS_ECALL_MANUAL_CAN_CANCEL;

- EGTS_ECALL_SMS_FALLBACK_NUMBER;

- EGTS_CRASH_RECORD_TIME;

- EGTS_CRASH_RECORD_RESOLUTION;

- EGTS_CRASH_PRE_RECORD_TIME;

- EGTS_CRASH_PRE_RECORD_RESOLUTION;

- EGTS_TRACK_RECORD_TIME;

- EGTS_TRACK_RECORD_RESOLUTION;

- EGTS_TRACK_PRE_RECORD_TIME;

- EGTS_ECALL_BLACK_LIST;

- EGTS_VEHICLE_VIN;

- EGTS_VEHICLE_TYPE;

- EGTS_VEHICLE_PROPULSION_STORAGE_TYPE.

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

Таблица 48 (Исключена, Изм. N 1).

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

Подраздел 7.5. (Измененная редакция, Изм. N 1).

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

8.1 Сообщение AL-ACK, направляемое системой "ЭРА-ГЛОНАСС" в сторону АС и содержащее подтверждение корректности минимального набора данных, принятого с использованием тонального модема, должно высылаться также посредством использования тонального модема.

(Измененная редакция, Изм. N 1).

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

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

(Измененная редакция, Изм. N 1).

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

Описание принципа построения навигационно-информационной системы на основе протокола транспортного уровня

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

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

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

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

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

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

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

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

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

Анализ протокола транспортного уровня на основе концепции NGTP

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

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

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

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

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

В NGTP идентификатором AC является VIN/DrivelD, в описываемом протоколе - UNIT_ID.

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

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

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

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

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

Приложение В
(обязательное)

Коды результатов обработки

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

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

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

Пример реализации алгоритма расчета контрольной суммы CRC16 на языке С/*

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

Пример реализации алгоритма расчета контрольной суммы CRC8 на языке С/*

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

Таблицы кодировки символов

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

Таблица Е.1

Е.2 Кодировка символов латинского и кириллического алфавитов приведена в таблице Е.2.

Таблица Е.2

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

Таблица Е.3

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

(Измененная редакция, Изм. N 1).

Электронный текст документа

и сверен по:

, 2013

Редакция документа с учетом
изменений и дополнений подготовлена