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

(утв. и введен в действие Приказом Росстандарта от 08.12.2011 № 754-ст)

Утвержден и введен в действие

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

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

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

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

ГОСТ Р 54619-2011

ОКС 33.070.40

Дата введения 1 сентября 2012 года

Предисловие

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

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

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

3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 8 декабря 2011 г. № 754-ст.

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

5. Введен впервые.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

НИС	- навигационно-информационные системы
ОЗУ	- оперативное запоминающее устройство;
ПО	- программное обеспечение;
ППУ	- протокол уровня поддержки услуг;
ПТУ	- протокол транспортного уровня;
ТП	- телематическая платформа;
ТС	- транспортное средство;
цифровая подпись	- информация в электронной форме, которая используется для идентификации отправителя данных;
ЭРА	- экстренное реагирование на аварии;
CP-1251	- CodePageCP1251 (набор символов и кодировка, являющаяся стандартной 8-битной кодировкой для всех русских версий Microsoft Windows);
CRC-8(16)	- Cyclic Redundancy Code (циклический избыточный код);
DNS	- Domain Name System (система доменных имен);
eCall	- Emergency Call (общеевропейская система экстренного реагирования при авариях);
EGTS	- Era Glonass Telematics Standard (телематический стандарт для системы «ЭРА-ГЛОНАСС»);
FTP	- File Transfer Protocol (протокол передачи файлов);
IP	- Internet Protocol (межсетевой протокол);
GSM	- Global System for Mobile communications (глобальный цифровой стандарт для мобильной сотовой связи);
HTTP	- HyperText Transfer Protocol (протокол передачи гипертекста);
IMAP	- Internet Message Access Protocol (протокол прикладного уровня для доступа к электронной почте);
ISDN	- Integrated Services Digital Network (цифровая сеть с интеграцией обслуживания);
Little-endian	- младший байт вперед (порядок следования байт);
NGTP	- Next Generation Telematics Protocol (телематический протокол следующего поколения. Архитектура и концепция построения);
OSI	- Open Systems Interconnection Basic Reference Model (базовая эталонная модель взаимодействия открытых систем — абстрактная сетевая модель для коммуникаций и разработки сетевых протоколов);
PDU	- Protocol Description Unit (элемент описания протокола);
POP3	- Post Office Protocol Version 3 (протокол почтового отделения, версия 3);
SC	- Service Center (сервис-центр, ответственный за обработку, хранение и передачу SMS-сообщений получателям);
SIM	- Subscriber Identification Module (модуль идентификации абонента);
SME	- Short Message Entity (объекты, способные отправлять и получать SMS-сообщения);
SMS	- Short Message Service (сервис коротких сообщений);
SMSC	- Short Message Service Center (центр обработки коротких сообщений);
SMTP	- Simple Mail Transfer Protocol (простой протокол передачи почты);
TCP	- Transmission Control Protocol (протокол управления передачей);
TFT	- Trivial File Transfer Protocol (простой протокол передачи файлов);
telnet	- TErminaL NETwork (сетевой протокол для реализации текстового интерфейса по сети);
UDP	- User Datagram Protocol (протокол пользовательских дейтаграмм).

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

Модель OSI		Стек протоколов TCP/IP		Протоколы TCP/IP	Протоколы системы «ЭРА-ГЛОНАСС»
Номер уровня	Название уровня	Номер уровня	Название уровня
7	Приложений	4	Приложений	FTP, HTTP, POP3, IMAP, telnet, SMTP, DNS, TFTP	Уровень поддержки услуг
6	Представления данных
5	Сеансовый				Транспортный уровень
4	Транспортный	3	Транспортный	TCP, UDP	TCP
3	Сетевой	2	Межсетевой	IP	IP
2	Канальный	1	Доступ к сети	-	-
1	Физический				-

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

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

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

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

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

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

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

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

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

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

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

Тип данных	Размер, байт	Диапазон значений	Описание
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	Целое число со знаком
INT	4	Минус 2147483648... плюс 2147483647	Целое число со знаком
FLOAT	4	+/- 1,2 E — 38... 3,4 E + 38	Дробное число со знаком
DOUBLE	8	+/- 2,2 E — 308... 1,7 E + 308	Дробное число со знаком
STRING	Переменный. Размер определяется внешними параметрами или применением специального символа-терминатора (код 0x00)	-	Содержит последовательность печатных символов в кодировке по умолчанию CP-1251, если явно не указана другая кодировка (при помощи дополнительного параметра)
BINARY	Переменный. Размер определяется внешними параметрами	-	Содержит последовательность данных типа BYTE
ARRAY OF TYPE	Переменный. Размер определяется внешними параметрами	-	Может содержать последовательность одного из вышеуказанных типов (TYPE), кроме BINARY. Порядок следования байт и размер каждого элемента используемого типа определяются самим типом. Экземпляры типов идут последовательно один за другим. Например: ARRAY OF STRING содержит в своем составе 10 экземпляров типа STRING, при этом размер каждого экземпляра определяется разделителем (код 0x00), который должен присутствовать между экземплярами

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

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

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

Заголовок протокола транспортного уровня	Данные уровня поддержки услуг	Контрольная сумма данных уровня поддержки услуг

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
PRV (Protocol Version)								M	BYTE	1
SKID (Security Key ID)								M	BYTE	1
PRF (Prefix)		RTE	ENA		CMP	PR		M	BYTE	1
HL (Header Length)								M	BYTE	1
HE (Header Encoding)								M	BYTE	1
FDL (Frame Data Length)								M	USHORT	2
PID (Packet Identifier)								M	USHORT	2
PT (Packet Type)								M	BYTE	1
PRA (Peer Address)								O	USHORT	2
RCA (Recipient Address)								O	USHORT	2
TTL (Time To Live)								O	BYTE	1
HCS (Header Check Sum)								M	BYTE	1
SFRD (Services Frame Data)								O	BINARY	0... 65517
SFRCS (Services Frame Data Check Sum)								O	USHORT	0, 2

5.6.1.3. Заголовок протокола транспортного уровня состоит из следующих параметров (полей): PRV, PRF, PR, CMP, ENA, RTE, HL, HE, FDL, PID, PT, 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 не шифруются. Состав и коды алгоритмов не определены в данной версии протокола
CMP (Compressed)	Битовое поле определяет, используется ли сжатие данных из поля SFRD. Если поле имеет значение 1, то данные в поле SFRD считаются сжатыми. Алгоритм сжатия не определен в данной версии протокола
PR (Priority)	Битовое поле определяет приоритет маршрутизации данного пакета и может принимать следующие значения: 0 — наивысший; 01 — высокий; 10 — средний; 11 — низкий. Установка большего приоритета позволяет передавать пакеты, содержащие срочные данные, такие, например, как пакет с минимальным набором данных базовой услуги «ЭРА-ГЛОНАСС» или данные о срабатывании сигнализации на транспортном средстве. При получении пакета диспетчер, анализируя данное поле, проводит маршрутизацию пакета с более высоким приоритетом быстрее, чем пакета с низким приоритетом, тем самым достигается более оперативная обработка при наступлении критически важных событий
HL	Длина заголовка протокола транспортного уровня в байтах с учетом байта контрольной суммы (поля HCS)
HE	Определяет применяемый метод кодирования следующей за данным параметром части заголовка протокола транспортного уровня
FDL	Определяет размер в байтах поля данных SFRD, содержащего информацию протокола уровня поддержки услуг
PID	Содержит номер пакета протокола транспортного уровня, увеличивающийся на 1 при отправке каждого нового пакета на стороне отправителя. Значения в данном поле изменяются по правилам циклического счетчика в диапазоне от 0 до 65535, т.е. при достижении значения 65535 следующее значение должно быть 0
PT	Тип пакета протокола транспортного уровня. Поле PT может принимать следующие значения: 0 — EGTS_PT_RESPONSE (подтверждение на протокол транспортного уровня); 1 — EGTS_PT_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг); 2 — EGTS_PT_SIGNED_APPDATA (пакет, содержащий данные протокола уровня поддержки услуг с цифровой подписью)
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

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

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
SDR 1 (Service Data Record)								O	BINARY	9... 65517
SDR 2								O	BINARY	9... 65517
...								...	...	...
SDRn								O	BINARY	9... 65517
Примечание — Структуры SDR 1, SDR 2, SDRn содержат информацию протокола уровня поддержки услуг. Таких структур в составе поля SFRD может быть одна или несколько, идущих одна за другой. Описание внутреннего состава структур представлено в разделе 6.

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
RPID (Response Packet ID)								M	USHORT	2
PR (Processing Result)								M	BYTE	1
SDR 1 (Service Data Record)								O	BINARY	9... 65517
SDR 2								O	BINARY	9... 65517
...								...	...	...
SDRn								O	BINARY	9... 65517
Примечания 1 Параметр RPID — идентификатор пакета транспортного уровня, подтверждение на который формируется. 2 Параметр PR — код результата обработки части пакета, относящейся к транспортному уровню (подсчет контрольных сумм заголовка транспортного уровня и данных уровня поддержки услуг, проверка размера пакета, определение необходимости дальнейшей маршрутизации пакета и т.д.). Список возможных кодов результата обработки представлен в Приложении В. 3 Структуры SDR 1, SDR 2, SDRn — структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
SIGL (Signature Length)								M	SHORT	2
SIGD (Signature Data)								O	BINARY	0... 512
SDR 1 (Service Data Record)								O	BINARY	9... 65515
SDR 2								O	BINARY	9... 65515
...								...	...	...
SDRn								O	BINARY	9... 65515
Примечания 1 Параметр SIGL — определяет длину данных «цифровой подписи» из поля SIGD. 2 Параметр SIGD — содержит непосредственно данные «цифровой подписи». 3 Структуры SDR 1, SDR 2, SDRn — структуры, содержащие информацию уровня поддержки услуг. Таких структур может быть одна или несколько, идущих одна за другой.

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

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].

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Размер, байт
SMSC_AL (SMSC Address Length)								M	1
SMSC_AT (SMSC Address Type)								O	0,1
SMSC_A (SMSC Address)								O	0,6
TP_RP	TP_UDHI	TP_SRR	TP_VPF		TP_RD	TP_MTI		M	1
TP_MR (Message Reference)								M	1
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_DCS (Data Coding Schema)								M	1
TP_VP (Validity Period)								O	0, 1, 7
TP_UDL (User Data Length)								M	1
TP_UD (User Data)								O	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_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;
• TP_PID — идентификатор протокола (должен содержать значение 00);
• TP_DCS — тип кодировки данных (должен содержать значение 0x04, определяющее 8-битную кодировку сообщения, отсутствие компрессии);
• TP_VP — время актуальности данного сообщения. Формат данного поля определяется значением из таблицы 9. Параметр является опциональным. Его наличие и размер зависят от значения поля TP_VPF;
• TP_UDL — длина данных сообщения из поля TP_DL, в байтах для используемой 8-битной кодировки;
• TP_UD — непосредственно передаваемые пользовательские данные. Формат данного поля в зависимости от значения поля TP_UDHI представлен в таблице 11.

Таблица 9

Значение битов		Описание
0	0	Поле TP_VP не передается
1	0	Поле TP_VP имеет формат «относительное время» и размер 1 байт
0	1	Поле TP_VP имеет формат «расширенное время» и размер 7 байт
1	1	Поле TP_VP имеет формат «абсолютное время» и размер 7 байт

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Размер, байт
1	TON			NPI				1

Параметры полей 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 — частный;

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Размер, байт
LUDH (Length of User Data Header)								O	1
IEI «A» (Information-Element-identifier «A»)								O	1
LIE «A» (Length of Information-Element «A»)								O	1
IED «A» (Information-Element-Data of «A»)								O	1... n
IEI «B» (Information-Element-identifier «B»)								O	1
LIE «B» (Length of Information-Element «B»)								O	1
IED «B» (Information-Element-Data of «B»)								O	1... n
IEI «N» (Information-Element-identifier «N»)								O	1
LIE «N» (Length of Information-Element «N»)								O	1
IED «N» (Information-Element-Data of «N»)								O	1... n
UD (User Data)								M	1... 140

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

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

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

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

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

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

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

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

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

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

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

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

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Размер, байт
CSMRN (Concatenated Short Message Reference Number)								M	1
MNSM (Maximum Number of Short Messages)								M	1
SNCSM (Sequence Number of Current Short Message)								M	1
Примечания 1 CSMRN — номер конкатенируемого SMS-сообщения, должен иметь одинаковое значение для всех частей длинного SMS-сообщения. 2 MNSM — общее количество сообщений, из которых состоит длинное SMS. Должен содержать значения в диапазоне от 1 до 255. 3 SNCSM — номер передаваемой части длинного SMS-сообщения. Инкрементируется при отправке каждой новой части длинного сообщения. Должен содержать значение в диапазоне от 1 до 255. Если значение данного поля превышает значение из поля MNSM или равно нулю, то принимающая сторона должна игнорировать весь информационный элемент.

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

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

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 байт.

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

Наименование и описание временных и количественных параметров протокола транспортного уровня указаны в таблице 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.

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
RL (Record Length)								M	USHORT	2
RN (Record Number)								M	USHORT	2
RFL (Record Flags)								M	BYTE	1
SSOD	RSOD	GRP	RPP		TMFE	EVFE	OBFE
OID (Object Identifier)								O	UINT	4
EVID (Event Identifier)								O	UINT	4
TM (Time)								O	UINT	4
SST (Source Service Type)								M	BYTE	1
RST (Recipient Service Type)								M	BYTE	1
RD (Record Data)								M	BINARY	3... 65498

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

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

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

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

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

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

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

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

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

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

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

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

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

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

г) 11 — низкий;

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 15

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
SRT (Subrecord Type)								M	BYTE	1
SRL (Subrecord Length)								M	USHORT	2
SRD (Subrecord Data)								O	BINARY	0... 65495
Примечания 1 SRT — тип подзаписи (подтип передаваемых данных в рамках общего набора типов одного сервиса). Тип 0 — специальный, зарезервирован за подзаписью подтверждения данных для каждого сервиса. Конкретные значения номеров типов подзаписей определяются логикой самого сервиса. Протокол оговаривает лишь то, что этот номер должен присутствовать, а нулевой идентификатор зарезервирован. 2 SRL — длина данных в байтах подзаписи в поле SRD. 3 SRD — данные подзаписи. Наполнение данного поля специфично для каждого сочетания идентификатора сервиса и типа подзаписи.

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

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

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

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

Таблица 16

Код	Название	Описание	ДО <1>	ШСЭ <2>	ШСД <3>
1	EGTS_ AUTH_ SERVICE	Данный тип сервиса применяется для осуществления процедуры аутентификации АС на телематической платформе. При использовании протокола TCP/IP АС должен проходить данную процедуру, и только после успешного завершения данной процедуры происходит дальнейшее взаимодействие	+	-	+
2	EGTS_ TELEDATA_ SERVICE	Сервис предназначен для обработки телематической информации (координатные данные, данные о срабатывании датчиков и т.д.), поступающей от АС	+	-	+
4	EGTS_ COMMANDS_ SERVICE	Данный тип сервиса предназначен для обработки управляющих и конфигурационных команд, информационных сообщений и статусов, передаваемых между АС, телематической платформой и операторами	+	+	+
9	EGTS_ FIRMWARE_ SERVICE	Сервис предназначен для передачи на АС конфигурации и непосредственно самого программного обеспечения аппаратной части самого АС, а также различного периферийного оборудования, подключенного к АС и поддерживающего возможность удаленного обновления программного обеспечения	+	+	+
10	EGTS_ ECALL_ SERVICE	Сервис, обеспечивающий выполнение функционала ЭРА. Сервис описан в разделе 7	+	+	+
Примечание — Варианты конфигурации АС: 1 АС, исполненная в конфигурации дополнительного оборудования. 2 АС, исполненная в конфигурации штатного оборудования и предназначенная для реализации только базовой услуги системой «ЭРА-ГЛОНАСС». 3 АС, исполненная в конфигурации штатного оборудования и предназначенная для реализации дополнительных, кроме базовой, услуг системой «ЭРА-ГЛОНАСС».

6.7.2 Сервис EGTS_AUTH_SERVICE

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

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

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

Код	Название	Описание
0	EGTS_SR_RECORD_RESPONSE	Подзапись применяется для осуществления подтверждения процесса обработки записи протокола уровня поддержки услуг. Данный тип подзаписи должен поддерживаться всеми сервисами
1	EGTS_SR_TERM_IDENTITY	Подзапись используется АС при запросе авторизации на телематическую платформу и содержит учетные данные АС
2	EGTS_SR_MODULE_DATA	Подзапись предназначена для передачи на телематическую платформу информации об инфраструктуре на стороне АС, о составе, состоянии и параметрах блоков и модулей АС. Данная подзапись является опциональной, и разработчик АС сам принимает решение о необходимости заполнения полей и отправки подзаписи. Одна подзапись описывает один модуль. В одной записи может передаваться последовательно несколько таких подзаписей, что позволяет передать данные об отдельных составляющих всей аппаратной части АС и периферийного оборудования
3	EGTS_SR_VEHICLE_DATA	Подзапись применяется АС для передачи на телематическую платформу информации о транспортном средстве
4	EGTS_SR_AUTH_PARAMS	Подзапись используется телематической платформой для передачи на AT данных о способе и параметрах шифрования, требуемого для дальнейшего взаимодействия
5	EGTS_SR_AUTH_INFO	Подзапись предназначена для передачи на телематическую платформу аутентификационных данных АС с использованием ранее переданных со стороны платформы параметров для осуществления шифрования данных
6	EGTS_SR_SERVICE_INFO	Данный тип подзаписи используется для информирования принимающей стороны, АС или телематической платформы в зависимости от направления отправки, о поддерживаемых сервисах, а также для запроса определенного набора требуемых сервисов (от АС к ТП)
7	EGTS_SR_RESULT_CODE	Подзапись применяется телематической платформой для информирования АС о результатах процедуры аутентификации АС

6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
CRN (Confirmed Record Number)								M	USHORT	2
RST (Record Status)								M	BYTE	1

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

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

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

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

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
TID (Terminal Identifier)								M	UINT	4
Flags								M	BYTE	1
MNE	BSE	NIDE	SSRA	LNGCE	IMSIE	IMEIE	HDIDE
HDID (Home Dispatcher Identifier)								O	USHORT	2
IMEI (International Mobile Equipment Identity)								O	STRING	15
IMSI (International Mobile Subscriber Identity)								O	STRING	16
LNGC (Language Code)								O	STRING	3
NID (Network Identifier)								O	BINARY	3
BS (Buffer Size)								O	USHORT	2
MSISDN (Mobile Station Integrated Services Digital Network Number)								O	STRING	15

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

• TID — уникальный идентификатор, назначаемый при программировании АС. Наличие значения 0 в данном поле означает, что АС не прошла процедуру конфигурирования или прошла ее не полностью. Данный идентификатор назначается оператором системы «ЭРА-ГЛОНАСС» и однозначно определяет набор учетных данных АС. TID назначается при инсталляции АС как дополнительного оборудования и передаче оператору учетных данных AT (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... 23	Биты 10... 19	Биты 0... 9	Тип	Тип данных	Размер, байт
-	MCC (Mobile Country Code)	MNC (Mobile Network Code)	M	BINARY	3

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

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

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

6.7.2.3 Подзапись EGTS_SR_MODULE_DATA

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
MT (Module Type)								M	BYTE	1
VID (Vendor Identifier)								M	UINT	4
FWV (Firmware Version)								M	USHORT	2
SWV (Software Version)								M	USHORT	2
MD (Modification)								M	BYTE	1
ST (State)								M	BYTE	1
SRN (Serial Number)								O	STRING	0... 32
D (Delimiter)								M	BYTE	1
DSCR (Description)								O	STRING	0... 32
D (Delimiter)								M	BYTE	1

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

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

6.7.2.4 Подзапись EGTS_SR_VEHICLE_DATA

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
VIN (Vehicle Identification Number)								M	STRING	17
VHT (Vehicle Type)								M	UINT	4
VPST (Vehicle Propulsion Storage Type)								M	UINT	4

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

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

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

б) биты 4 — 0;

в) 0001 — пассажирский (Class M1);

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

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

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

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

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

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

л) 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 — бензин.

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

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

Таблица 23

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
FLG (Flags)								M	BYTE	1
-	EXE	SSE	MSE	ISLE	PKE	ENA
PKL (Public Key Length)								O	USHORT	2
PBK (Public Key)								O	BINARY	0... 512
ISL (Identity String Length)								O	USHORT	2
MSZ (Mod Size)								O	USHORT	2
SS (Server Sequence)								O	STRING	0... 255
D (Delimiter)								O	BYTE	1
EXP (Exp)								O	STRING	0... 255
D (Delimiter)								O	BYTE	1

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

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

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

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

6.7.2.6 Подзапись EGTS_SR_AUTH_INFO

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

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

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

Таблица 24

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
UNM (User Name)								M	STRING	0... 32
D (Delimiter)								M	BYTE	1
UPSW (User Password)								M	STRING	0... 32
D (Delimiter)								M	BYTE	1
SS (Server Sequence)								O	STRING	0... 255
D (Delimiter)								O	BYTE	1

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

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

Таблица 25

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
ST (Service Type)								M	BYTE	1
SST (Service Statement)								M	BYTE	1
SRVP (Service Parameters)								M	BYTE	1
SRVA	-					SRVRP

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

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

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

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

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

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

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

г) 11 — низкий.

Таблица 26

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

Код	Название	Описание
0	EGTS_SST_IN_SERVICE	Сервис в рабочем состоянии и разрешен к использованию
128	EGTS_SST_OUT_OF_SERVICE	Сервис в нерабочем состоянии (выключен)
129	EGTS_SST_DENIED	Сервис запрещен для использования
130	EGTS_SST_NO_CONF	Сервис не настроен
131	EGTS_SST_TEMP_UNAVAIL	Сервис временно недоступен

6.7.2.8 Подзапись EGTS_SR_RESULT_CODE

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

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

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
RCD (Result Code)								M	BYTE	1

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

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

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

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

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

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

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

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

2. После регистрации АС в сети GSM или UMTS устанавливается GPRS сессия и TCP/IP соединение с сервером, информация об адресе которого уже записана в памяти АС. При прохождении процедура аутентификации инфраструктура оператора анализирует параметр TID из подзаписи EGTS_SR_TERM_IDENTITY (таблица 18). Если TID имеет значение 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, определяющие состав сервисов, разрешенных для АС и поддерживаемых платформой. Это означает, что АС сразу после авторизации может использовать только перечисленные сервисы, даже если она предполагает простой алгоритм поддержки прав использования сервисов.

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

Алгоритм обмена сообщениями на этапе авторизации АС на стороне телематической платформы представлен на диаграмме, приведенной на рисунке 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 соединение.

6.7.3 Сервис EGTS_COMMANDS_SERVICE

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

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

Код	Название	Описание
0	EGTS_SR_RECORD_RESPONSE	Подзапись применяется для подтверждения процесса обработки записи протокола уровня поддержки услуг. Данный тип подзаписи должен поддерживаться всеми сервисами
51	EGTS_SR_COMMAND_DATA	Подзапись используется АС и телематической платформой для передачи команд, информационных сообщений, подтверждений доставки, подтверждений выполнения команд, подтверждений прочтения сообщений

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

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
CT (Command Type)				CCT (Command Confirmation Type)				M	BYTE	1
CID (Command Identifier)								M	UINT	4
SID (Source Identifier)								M	UINT	4
-						ACFE	CHSFE	M	BYTE	1
CHS (Charset)								O	BYTE	1
ACL (Authorization Code Length)								O	BYTE	1
AC (Authorization Code)								O	BINARY	0... 255
CD (Command Data)								O	BINARY	0... 6525

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• CID — идентификатор команды, сообщения. Значение из данного поля должно быть использовано стороной, обрабатывающей/выполняющей команду или сообщение, для создания подтверждения. Подтверждение должно содержать в поле CID то же значение, что содержалось в самой команде или сообщении при отправке;
• SID — идентификатор отправителя данной команды или подтверждения;
• ACFE (Authorization Code Field Exists) — битовый флаг, определяющий наличие полей ACL и АС в подзаписи:

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

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

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

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

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

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

а) 0 — CP-1251;

б) 1 — IA5 (CCITT T.50)/ASCII (ANSI X3.4);

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

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

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

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

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

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

к) 8 — UCS2.

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

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

Таблица 30

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
ADR (Address)								M	USHORT	2
SZ (Size)				ACT (Action)				M	BYTE	1
CCD (Command Code)								M	USHORT	2
DT (Data)								O	BINARY	0... 65200

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

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

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

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

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

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

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

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

Таблица 31

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
ADR (Address)								M	USHORT	2
CCD (Command Code)								M	USHORT	2
DT (Data)								O	BINARY	0... 65200

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

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

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

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

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

Таблица 32

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

Название команды	Код	Тип, число и предельные значения параметров	Описание
EGTS_RAW_DATA	0x0000	BINARY (до 65200 байт)	Команда для передачи произвольных данных. Применяется, например, для передачи команд, сообщений и данных на периферийные устройства, модули, подключенные к основному блоку АС, в определяемом данным модулем формате. При этом АС не должна анализировать данные из поля DT и в неизменном виде передать их по адресу, определяемому полем ADR
EGTS_TEST_MODE	0x0001	BYTE	Команда начала/окончания тестирования АС: 1 — начало тестирования, 0 — окончание тестирования
EGTS_CONFIG_RESET	0x0006	-	Возврат к заводским установкам. Удаляются все установленные пользователем параметры, и производится возврат к заводским установкам. Для обработки данной команды оператор должен установить корректные значения полей ACL и АС, указанных в таблице 29
EGTS_SET_AUTH_CODE	0x0007	BINARY	Установка кода авторизации на стороне АС. Для обработки данной команды оператор должен установить корректные значения полей ACL и АС, указанных в таблице 29. После подтверждения данной команды АС будет использовать уже новые данные для сравнения со значением из поля АС в некоторых присылаемых на АС командах
EGTS_RESTART	0x0008	-	Команда проводит перезапуск основного программного обеспечения АС. Для обработки данной команды оператор должен установить корректные значения полей ACL и АС, указанных в таблице 29

Название команды	Код	Тип и число параметров	Описание
EGTS_RAW_DATA	0x0000	BINARY (до 65200 байт)	Данные, поступающие от периферийных устройств, модулей, подключенных к основному блоку АС, в определяемом данным модулем формате
EGTS_SELF_TEST_RESULT	0x0002	STRING	Сообщение о результатах самодиагностики. Генерируется АС автоматически без запроса от оператора

Имя параметра	Код	Тип параметра	Значение по умолчанию	Описание
Радио mute (только для конфигурации дополнительного оборудования)
EGTS_RADIO_MUTE_DELAY	0x0201	INT	0	Задержка между установкой сигнала радио mute и началом проигрывания звука, миллисекунд
EGTS_RADIO_UNMUTE_DELAY	0x0202	INT	0	Задержка между снятием сигнала радио mute и окончанием проигрывания звука, миллисекунд
Установки общего назначения
EGTS_GPRS_APN	0x0203	STRING	«»	Параметр, определяющий точку доступа GPRS
EGTS_SERVER_ADDRESS	0x0204	STRING	«»	Адрес и порт сервера для связи с использованием протокола TCP/IP
EGTS_SIM_PIN	0x0205	INT	0	PIN код SIM-карты
EGTS_AUTOMATIC_REGISTRATION	0x0207	BOOLEAN	1	Флаг, разрешающий автоматическую регистрацию SIM в сети после включения питания
EGTS_SELFTEST_INTERVAL	0x0208	INT	0	Интервал проведения периодической самодиагностики, часов. Если значение установлено в 0, то самодиагностика не проводится
EGTS_POST_TEST_REGISTRATION_TIME	0x0209	INT	120	Промежуток времени, в течение которого АС остается зарегистрированной в сети после передачи результатов самодиагностики оператору системы, секунд
EGTS_TEST_MODE_END_DISTANCE	0x020A	INT	300	Дистанция, на которой режим тестирования выключается автоматически, метров
EGTS_GARAGE_MODE_END_DISTANCE	0x020B	INT	300	Дистанция, на которой режим «автосервис» выключается автоматически, метров
EGTS_GARAGE_MODE_PIN	0x020C	ENUM {NONE-0, PIN_1-1, .. PIN8-8}	0	Линия, сигнализирующая, что система находится в режиме «Автосервис» NONE — нет сигнализации режима PIN_X — PIN_X линия активная, когда система находится в данном режиме
EGTS_TEST_MODE_WATCHDOG	0x020E	INT	10	Интервал тревожного счетчика в режиме тестирования, минут
Конфигурация и конфигурационные данные услуг. Пакетная передача данных
EGTS_USE_GPRS_WHITE_LIST	0x0230	BOOLEAN	FALSE	Параметр, указывающий на необходимость использования GPRS_WHITE_LIST при организации пакетной передачи данных
EGTS_GPRS_WHITE_LIST	0x0231	ARRAY OF STRING	«», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «»	Список сетей, в которых разрешена пакетная передача данных. Если список GPRS_WHITE_LIST пуст, то пакетная передача данных запрещена, MCC (Mobile Country Code) 3 символа + MNC (Mobile Network Code)
Режим тестирования
EGTS_TEST_REGISTRATION_PERIOD	0x0242	INT	5	Если АС была зарегистрирована в сети посредством нажатия на кнопку включения дополнительных услуг, то последующая регистрация АС в сети при нажатии на кнопку включения дополнительных услуг возможна не ранее чем через данный промежуток времени. Если значение установлено в 0, то ограничений на последующую регистрацию АС в сети не накладывается, минут
Прочие параметры
EGTS_GNSS_POWER_OFF_TIME	0x0301	INT	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	«»	Версия программного обеспечения
EGTS_UNIT_VENDOR_ID	0x0403	INT	0	Идентификатор поставщика устройства
EGTS_UNIT_ID	0x0404	INT	0	Уникальный идентификатор устройства, назначаемый оператором системы при первой активизации устройства
EGTS_UNIT_IMEI	0x0405	STRING	«»	Номер IMEI
EGTS_UNIT_RS485_BAUD_RATE	0x0406	INT	19200	Скорость порта RS485
EGTS_UNIT_RS485_STOP_BITS	0x0407	INT	1	Число стоп-битов при передаче данных через порт RS485
EGTS_UNIT_RS485_PARITY	0x0408	INT/0, 1, 2	0	Способ проверки на четность при передаче данных через порт RS485: 0 — проверка не проводится; 1 — проверка типа ODD; 2 — проверка типа EVEN
EGTS_UNIT_LANGUAGE_ID	0x0410	INT	0	Предпочтительный язык для голосового общения в соответствии с ГОСТ 7.75. 0x5F — русский
EGTS_UNIT_HOME_DISPATCHER_ID	0x0411	INT	0	Идентификатор телематической платформы, в хранилище которой находится информация об учетных данных устройства, списке предоставляемых услуг и их статусах
EGTS_SERVICE_AUTH_METHOD	0x0412	INT	1	Метод использования услуг: 1- простой метод (подразумевает, что все услуги по умолчанию доступны АС); 0 — с подтверждением (разрешены к использованию только те услуги, информация о разрешении использования которых пришла с телематической платформы)
EGTS_SERVER_CHECK_IN_PERIOD	0x0413	INT	30	Время между попытками установить TCP/IP соединение с сервером, секунд
EGTS_SERVER_CHECK_IN_ATTEMPTS	0x0414	INT	5	Число попыток установления TCP/IP соединения с сервером, по достижении которого будет проведена повторная установка сессии верхнего уровня (GPRS)
EGTS_SERVER_PACKET_TOUT	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_ADDRESS;
• EGTS_SIM_PIN;
• EGTS_AUTOMATIC_REGISTRATION;
• EGTS_SELFTEST_INTERVAL;
• EGTS_POST_TEST_REGISTRATION_TIME;
• EGTS_TEST_MODE_END_DISTANCE;
• EGTS_GARAGE_MODE_END_DISTANCE;
• EGTS_TEST_MODE_WATCHDOG;
• EGTS_USE_GPRS_WHITE_LIST;
• EGTS_GPRS_WHITE_LIST;
• EGTS_TEST_REGISTRATION_PERIOD;
• EGTS_GNSS_POWER_OFF_TIME;
• EGTS_GNSS_DATA_RATE;
• EGTS_GNSS_MIN_ELEVATION;
• EGTS_UNIT_SERIAL_NUMBER;
• EGTS_UNIT_HW_VERSION;
• EGTS_UNIT_SW_VERSION;
• EGTS_UNIT_VENDOR_ID;
• EGTS_UNIT_ID;
• EGTS_UNIT_LANGUAGE_ID;
• EGTS_UNIT_IMEI;
• EGTS_UNIT_HOME_DISPATCHER_ID.

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

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

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

Код	Название	Описание
0	EGTS_SR_RECORD_RESPONSE	Подзапись применяется для осуществления подтверждения записи протокола уровня поддержки услуг из пакета типа EGTS_PT_APPDATA
33	EGTS_SR_SERVICE_PART_DATA	Подзапись предназначена для передачи на АС данных, которые разбиваются на части и передаются последовательно. Данная подзапись применяется для передачи больших объектов, длина которых не позволяет передать их на АС одним пакетом
34	EGTS_SR_SERVICE_FULL_DATA	Подзапись предназначена для передачи на АС данных, которые не разбиваются на части, а передаются одним пакетом

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
ID (Identity)								M	USHORT	2
PN (Part Number)								M	USHORT	2
EPQ (Expected Parts Quantity)								M	USHORT	2
ODH (Object Data Header)								O	BINARY	0... 71
OD (Object Data)								M	BINARY	1... 65400
Примечания 1 ID — уникальный идентификатор передаваемой сущности. Инкрементируется при начале отправки новой сущности. Данный параметр позволяет однозначно идентифицировать, какой именно сущности данная часть принадлежит.
2 PN — последовательный номер текущей части передаваемой сущности. 3 EPQ — ожидаемое число частей передаваемой сущности. 4 ODH — заголовок, содержащий параметры, характеризующие передаваемую сущность. Данный заголовок передается только для первой части сущности. При передаче второй и последующих частей данное поле не передается. Структура заголовка ODH представлена в таблице 36. 5 OD — непосредственно данные передаваемой сущности. Параметр EPQ содержит число частей, которое будет передано, а параметр PN — номер текущей части. Поле ID однозначно определяет сущность, которому принадлежит передаваемая часть. Значения параметров EPQ и PN для данной подзаписи должны содержать значения в диапазоне от 1 до 65535, причем значение из поля PN должно быть меньше или равно значению из поля EPQ. Если данное условие нарушается, то данные из такой подзаписи игнорируются.

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
OA (Object Attribute)								M	BYTE	1
-				OT (Object Type)		MT (Module Type)
CMI (Component or Module Identifier)								M	BYTE	1
VER (Version)								M	USHORT	2
WOS (Whole Object Signature)								M	USHORT	2
FN (File Name)								O	STRING	0... 64
D (Delimiter)								M	BYTE	1

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

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

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

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

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

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

б) 01 — АС;

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

6.7.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
ODH (Object Data Header)								M	BINARY	7... 71
OD (Object Data)								M	BINARY	1... 65400

В таблице 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.

Название	Тип данных	Диапазон значений	Значение по умолчанию	Описание
EGTS_SL_NOT_AUTH_TO	BYTE	0... 255	6	Время ожидания прихода сообщения от АС, содержащего данные для осуществления процедуры авторизации на стороне телематической платформы после установления АС нового подключения по протоколу TCP/IP, (секунды). Если в течение данного времени сообщение не поступает, платформа должна разорвать установленное с АС TCP/IP соединение

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. Обработка команд 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

Код	Название	Описание
0	EGTS_SR_RECORD_RESPONSE	Подзапись применяется для осуществления подтверждения записи протокола уровня поддержки услуг из пакета типа EGTS_PT_APPDATA
20	EGTS_SR_ACCEL_ DATA	Подзапись предназначена для передачи на телематическую платформу данных профиля ускорения АС
40	EGTS_SR_RAW_MSD_DATA	Подзапись используется АС для передачи МНД на телематическую платформу в исходном виде
50	EGTS_SR_MSD_DATA	Подзапись используется АС для передачи МНД на телематическую платформу
62	EGTS_SR_TRACK_DATA	Подзапись применяется для передачи данных о траектории движения транспортного средства при ДТП на телематическую платформу

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
SA (Structures Amount)								M	BYTE	1
ATM (Absolute Time)								M	UINT	4
ADS1 (Accelerometer Data Structure 1)								M	BINARY	8
ADS2 (Accelerometer Data Structure 2)								O	BINARY	8
...								...	...	...
ADS255 (Accelerometer Data Structure 255)								O	BINARY	8

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

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

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
RTM (RelativeTime)								M	USHORT	2
XAAV (X Axis Acceleration Value)								M	SHORT	2
YAAV (Y Axis Acceleration Value)								M	SHORT	2
ZAAV (Z Axis Acceleration Value)								M	SHORT	2

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

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

7.3.3 Подзапись EGTS_SR_RAW_MSD_DATA

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
FM (Format)								M	BYTE	1
MSD (Minimal Set of Data)								M	BINARY	0... 1024

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

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

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

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

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

• MSD — массив данных (размер данного поля определяется исходя из размера поля FM данной подзаписи, а также значения поля SRL в соответствии с [2], таблица 3).

7.3.4 Подзапись EGTS_SR_MSD_DATA

Структура подзаписи EGTS_SR_MSD_DATA представлена в таблице 44 и соответствует требованиям к МНД, указанным в ГОСТ Р 54620.

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
FV (Format Version)								M	BYTE	1
MI (Message Identifier)								M	BYTE	1
CN (Control)								M	BYTE	1
-	VT (Vehicle Type)				POCN	CLT	ACT	-	-	-
VIN (Vehicle Identification Number)								M	STRING	17
VPST (Vehicle Propulsion Storage Type)								M	BYTE	1
TS (Time Stamp)								M	BINARY	4
PLAT (Position Latitude)								M	BINARY	4
PLON (Position Longitude)								M	BINARY	4
VD (Vehicle Direction)								M	BYTE	1
RVP n-1 LATD (Recent Vehicle Position n-1 Latitude Delta)								O	BINARY	2
RVP n-1 LOND (Recent Vehicle Position n-1 Longitude Delta)								O	BINARY	2
RVP n-2 LATD (Recent Vehicle Position n-2 Latitude Delta)								O	BINARY	2
RVP n-2 LOND (Recent Vehicle Position n-2 Longitude Delta)								O	BINARY	2
NOP (Number Of Passengers)								O	BYTE	1
AD (Additional Data)								O	STRING	0... 56

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

• FV — версия формата данных (поле должно содержать значение 1);
• MI — идентификатор сообщения (поле должно содержать значение, начиная с 1, и увеличиваться на 1 при каждой отправке сообщения после наступления события);
• CN — битовое поле управления;
• VT — битовые флаги, характеризующие тип транспортного средства [5]:

а) 0001 — пассажирский (категория M1);

б) 0010 — автобус (категория M2);

в) 0011 — автобус (категория M3);

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

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

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

ж) 0111 — мотоцикл (категория L1e);

и) 1000 — мотоцикл (категория L2e);

к) 1001 — мотоцикл (категория L3e);

л) 1010 — мотоцикл (категория L4e);

м) 1011 — мотоцикл (категория L5e);

н) 1100 — мотоцикл (категория L6e);

п) 1101 — мотоцикл (категория L7e);

• POCN — (Position Confidence) битовый флаг, определяющий достоверность данных о местоположении:

а) 1 — данные местоположения недостоверны (если местоположение не могло быть определено с точностью не более +/- 150 м с достоверностью 95%);

б) 0 — данные местоположения достоверны;

• CLT (Call Type) — битовый флаг, определяющий тип вызова:

а) 1 — тестовый вызов;

б) 0 — экстренный вызов;

• ACT (Activation Type) — битовый флаг, определяющий тип активации события:

а) 1 — автоматически;

б) 0 — вручную;

• VIN — идентификатор транспортного средства;
• 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;
• PLON — долгота местоположения транспортного средства в момент события, в угловых миллисекундах. При отсутствии или невозможности определить значение широты все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип INT с порядком следования байт big-endian;
• VD — направление движения транспортного средства от направления на северный магнитный полюс по ходу часовой стрелки, с шагом 2°. Диапазон возможных значений 0... 129. При отсутствии или невозможности определения значение поле должно содержать значение 255;
• RVP n-1 LATD — разность широты местоположения транспортного средства относительно значения поля PLAT с шагом 100 мс. Положительные значения — севернее, отрицательные — южнее. Диапазон возможных значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian;
• RVP n-1 LOND — разность долготы местоположения транспортного средства относительно значения поля PLON с шагом, установленным в ГОСТ Р 54620 (Приложение В). Положительные значения — восточнее, отрицательные — западнее. Диапазон возможных значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian;
• RVP n-2 LATD — разность широты местоположения транспортного средства относительно значения поля RVP n-1 LATD с шагом, установленным в ГОСТ Р 54620 (Приложение В). Положительные значения — севернее, отрицательные — южнее. Диапазон возможных значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian;
• RVP n-2 LOND — разность долготы местоположения транспортного средства относительно значения поля RVP n-1 LOND с шагом, установленным в ГОСТ Р 54620 (Приложение В). Положительные значения — восточнее, отрицательные — западнее. Диапазон возможных значений от минус 512 до плюс 511. При отсутствии или невозможности определить значение все биты поля должны содержать значение 1. Данное поле должно интерпретироваться на приемной стороне как тип SHORT с порядком следования байт big-endian;
• NOP — число застегнутых ремней безопасности. При отсутствии информации поле должно содержать значение 255;
• AD — дополнительные данные.

Наличие необязательных параметров в подзаписи EGTS_SR_MSD_DATA должно определяться исходя из общего размера подзаписи. При этом, если необходимо передать необязательный параметр, например поле NOP, то все предшествующие необязательные поля RVP n-1 LATD, RVP n-1 LOND, RVP n-2 LATD, RVP n-2 LOND также должны передаваться, но с соответствующими заполнителями.

7.3.5 Подзапись EGTS_SR_TRACK_DATA

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

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
SA (Structures Amount)								M	BYTE	1
ATM (Absolute Time)								M	UINT	4
TDS1 (Track Data Structure 1)								M	BINARY	8
TDS2 (Track Data Structure 2)								O	BINARY	8
...								...	...	...
TDS255 (Track Data Structure 255)								O	BINARY	8

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

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

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

Таблица 46

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
TNDE	LOHS	LAHS	RTM (Relative Time)					M	BYTE	1
LAT (Latitude)								O	UINT	4
LONG (Longitude)								O	UINT	4
SPDL (Speed Low Bits)								O	USHORT	2
DIRH	SPDH (Speed Hi Bits)
DIR (Direction)								O	BYTE	1

• 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 — направление движения TC, выраженное в градусах, относительно севера по ходу часовой стрелки (дополнительно старший бит находится в поле DIRH). Значение параметра направления должно быть в пределах от 0 до 359.

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

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

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

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

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

• EGTS_ECALL_BLACK_LIST;
• EGTS_ECALL_TEST_NUMBER;
• EGTS_ECALL_ON;
• 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

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

Название команды	Код	Тип, число и предельные значения параметров	Описание
EGTS_ECALL_REQ	0x0112	-	Команда на осуществление повторного экстренного вызова. Используется только через SMS
EGTS_ECALL_MSD_REQ	0x0113	-	Команда на осуществление повторной передачи МНД. Используется только через SMS
EGTS_ACCEL_DATA	0x0114	-	Команда на осуществление передачи данных профиля ускорения. Используется только через SMS
EGTS_TRACK_DATA	0x0115	-	Команда на осуществление передачи данных траектории движения. Используется только через SMS
EGTS_TEST_MODE_START_TEST	0x0003	BYTE/ 0... 8	Команда, осуществляющая запуск тестов в «тестовом режиме». Может принимать следующие значения: 0 — запуск последовательно всех тестов; 1 — проверка центра обслуживания звонков; 2 — проверка внешнего (коммерческого) центра обслуживания звонков; 3 — тест микрофона; 4 — тест динамиков; 5 — тест включения/выключения зажигания; 6 — расширенный тест БИП; 7 — тест встроенной резервной аккумуляторной батареи; 8 — тест датчика автоматической идентификации ДТП

Название команды	Код	Тип и число параметров	Описание
EGTS_TEST_MODE_START_TEST	0x0003	BINARY (8 байт)	Результаты проведения тестов. Каждый байт содержит код, определяющий результат теста (см. описание TEST_MODE_START_TEST из таблицы 35). 1-й байт — тест 1, 2-й байт — тест 2 и т.д.

Таблица 49

Имя параметра	Код	Тип параметра	Значение по умолчанию	Описание
Установки общего назначения
EGTS_ECALL_BLACK_LIST	0x0206	ARRAY OF STRING	«», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «», «»	Список сетей, в которых нет возможности осуществить экстренный вызов
EGTS_ECALL_TEST_NUMBER	0x020D	STRING	112	Телефонный номер для тестовых звонков ЭРА-ГЛОНАСС
Конфигурация и конфигурационные данные услуг
Базовая услуга системы «ЭРА-ГЛОНАСС»
EGTS_ECALL_ON	0x0210	BOOLEAN	TRUE	Возможность осуществления экстренного вызова
EGTS_ECALL_CRASH_SIGNAL_INTERNAL	0x0211	BOOLEAN	TRUE	Только транспортные средства категории M_{1} — для определения события аварии используется встроенный измеритель ускорения
EGTS_ECALL_CRASH_SIGNAL_EXTERNAL	0x0212	BOOLEAN	TRUE	Только транспортные средства категории M_{1} — для определения события аварии используется внешний датчик в автомобиле
EGTS_ECALL_SOS_BUTTON_TIME	0x0213	INT	200	Длительность, в течение которой должна быть нажата кнопка «экстренный вызов» для инициации экстренного вызова независимо от состояния линии зажигания, миллисекунд
EGTS_ECALL_MODE_PIN	0x0216	ENUM {NONE-O, PIN_1-1, ... PIN_8-8}	NONE	Линия, сигнализирующая, что система находится в режиме ЭРА; NONE — нет сигнализации режима; PIN_X — PIN_X — номер активной линии, когда система находится в данном режиме
EGTS_ECALL_CCFT	0x0217	INT	60	Длительность счетчика автоматического прекращения звонка, минут
EGTS_ECALL_INVITATION_SIGNAL_DURATION	0x0218	INT	200	Длительность сигнала INVITATION, миллисекунд
EGTS_ECALL_SEND_MSG_PERIOD	0x0219	INT	200	Период сообщения SEND MSG, миллисекунд
EGTS_ECALL_AL_ACK_PERIOD	0x021A	INT	200	Период AL-ACK, миллисекунд
EGTS_ECALL_MSD_MAX_TRANSMISSION_TIME	0x021B	INT	20	Максимальная длительность передачи MSD, секунд
EGTS_ECALL_NAD_DEREGISTRATION_TIMER	0x021D	INT	8	Время, по истечении которого модуль GSM или UMTS прекращает регистрацию в сети, часов
EGTS_ECALL_DIAL_DURATION	0x021E	INT	5	Общая продолжительность дозвона при инициации экстренного вызова, минут
EGTS_ECALL_AUTO_DIAL_ATTEMPTS	0x021F	INT	10	Только транспортные средства категории M_{1} — число попыток дозвона при автоматически инициированном вызове. Значение не может быть установлено в 0
EGTS_ECALL_MANUAL_DIAL_ATTEMPTS	0x0220	INT	10	Число попыток дозвона при экстренном вызове, инициированном вручную. Значение не может быть установлено в 0
EGTS_ECALL_MANUAL_CAN_CANCEL	0x0222	BOOLEAN	TRUE	TRUE — экстренный вызов, инициированный вручную, может быть прекращен со стороны пользователя
EGTS_ECALL_SMS_FALLBACK_NUMBER	0x0223	STRING	112	Номер, по которому АС посылает SMS с минимальным набором данных по запросу от оператора системы
Запись профиля ускорения при ДТП
IGNITION_OFF_FOLLOW_UP_TIME1	Минуты	INT	120	Промежуток времени, в течение которого осуществляется запись профиля ускорения при ДТП при выключенном зажигании
IGNITION_OFF_FOLLOW_UP_TIME2	Минуты	INT	240	Промежуток времени, в течение которого осуществляется определение события аварии при выключенном зажигании
EGTS_CRASH_RECORD_TIME	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	0x025A	INT/ 0... 180	10	Время записи информации о траектории движения транспортного средства при наступлении события ДТП, секунд. Установка значения данного параметра, равного 0, означает, что запись данных о траектории движения при ДТП не производится
EGTS_TRACK_PRE_RECORD_TIME	0x025B	INT/ 0... 600	20	Время записи информации о траектории движения транспортного средства до того, как событие ДТП наступило, секунд. Установка значения данного параметра, равного 0, означает, что запись данных о траектории движения до того, как событие ДТП наступило, не производится
EGTS_TRACK_RECORD_RESOLUTION	0x025C	INT/ 1... 30	10	Продолжительность одного отсчета при записи траектории движения транспортного средства, 100 миллисекунд
Параметры транспортного средства
EGTS_VEHICLE_VIN	0x0311	STRING	«»	VIN в соответствии с [[5]](#p102957)
EGTS_VEHICLE_TYPE	0x0312	INT	0	Тип транспортного средства: 1 — пассажирский (класс M1) 2 — автобус (класс M2) 3 — автобус (класс M3) 4 — легкая грузовая машина (класс N1) 5 — тяжелая грузовая машина (класс N2) 6 — тяжелая грузовая машина (класс N3) 7 — мотоцикл (класс L1e) 8 — мотоцикл (класс L2e) 9 — мотоцикл (класс L3e) 10 — мотоцикл (класс L4e) 11 — мотоцикл (класс L5e) 12 — мотоцикл (класс L6e) 13 — мотоцикл (класс L7e)
EGTS_VEHICLE_PROPULSION_STORAGE_TYPE	0x0313	INT	0	Тип энергоносителя (если все биты 0, то тип не задан): бит 7: не используется бит 6: не используется бит 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.

Поле данных AL-ACK	Номер бита, представляющего поле данных	Значение
Зарезервированное поле № 1	4	Поле не используется
Зарезервированное поле № 2	3	Поле не используется
Признак корректности полученных данных	2	0 — полученные данные корректны; 1 — полученные данные не корректны
Версия формата данных	1	0 — текущий формат; 1 — зарезервировано для будущего использования

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

ОПИСАНИЕ ПРИНЦИПА ПОСТРОЕНИЯ НАВИГАЦИОННО-ИНФОРМАЦИОННОЙ СИСТЕМЫ НА ОСНОВЕ ПРОТОКОЛА ТРАНСПОРТНОГО УРОВНЯ

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

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

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

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

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

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

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

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

АНАЛИЗ ПРОТОКОЛА ТРАНСПОРТНОГО УРОВНЯ

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

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

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

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

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

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

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

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

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

Значение	Обозначение	Описание
0	EGTS_PC_OK	Успешно обработано
1	EGTS_PC_IN_PROGRESS	В процессе обработки (результат обработки еще не известен)
128	EGTS_PC_UNS_PROTOCOL	Неподдерживаемый протокол
129	EGTS_PC_DECRYPT_ERROR	Ошибка декодирования
130	EGTS_PC_PROC_DENIED	Обработка запрещена
131	EGTS_PC_INC_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_DATACRC_ERROR	Ошибка контрольной суммы данных
139	EGTS_PC_INVDATALEN	Некорректная длина данных
140	EGTS_PC_ROUTE_NFOUND	Маршрут не найден
141	EGTS_PC_ROUTE_CLOSED	Маршрут закрыт
142	EGTS_PC_ROUTE_DENIED	Маршрутизация запрещена
143	EGTS_PC_INVADDR	Неверный адрес
144	EGTS_PC_TTLEXPIRED	Превышено число ретрансляции данных
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_INC_DATETIME	Неправильная дата и время
155	EGTS_PC_IO_ERROR	Ошибка ввода/вывода
156	EGTS_PC_NO_RES_AVAIL	Недостаточно ресурсов
157	EGTS_PС_MODULE_FAULT	Внутренний сбой модуля
158	EGTS_PC_MODULE_PWR_FLT	Сбой в работе цепи питания модуля
159	EGTS_PC_MODULE_PROC_FLT	Сбой в работе микроконтроллера модуля
160	EGTS_PC_MODULE_SW_FLT	Сбой в работе программы модуля
161	EGTS_PC_MODULE_FW_FLT	Сбой в работе внутреннего программного обеспечения модуля
162	EGTS_PC_MODULE_IO_FLT	Сбой в работе блока ввода/вывода модуля
163	EGTS_PC_MODULE_MEM_FLT	Сбой в работе внутренней памяти модуля
164	EGTS_PC_TEST_FAILED	Тест не пройден
Примечание — Пакеты сообщений об ошибках (EGTS_PC_DECRYPT_ERROR, EGTS_PC_UNS_PROTOCOL, EGTS_PC_INC_DATAFORM, EGTS_PC_DATACRC_ERROR, EGTS_PC_INC_HEADERFORM, EGTS_PC_HEADERCRC_ERROR) предназначены для целей тестирования оборудования и в рабочей версии программного обеспечения и АС могут быть исключены.

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

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

Name : CRC-16 CCITT

Poly : 0x1021 x16 + x12 + x5 + 1

Init : 0xFFFF

Revert: false

XorOut: 0x0000

Check : 0x29B1 («123456789»)*/

const unsigned short Crc16Table[256] — {

0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,

0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,

0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,

0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,

0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,

0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,

0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,

0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,

0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,

0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,

0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,

0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,

0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,

0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,

0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,

0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,

0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,

0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,

0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,

0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235,0x5214, 0x6277, 0x7256,

0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,

0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,

0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,

0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,

0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,

0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,

0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,

0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,

0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,

0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,

0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,

0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0};

unsigned short Crc16(unsigned char * pcBlock, unsigned short len)

{ unsigned short crc — 0xFFFF;

while (len- -)

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

Name: CRC-8

Poly: 0x31 x8 + x5 + x4 + 1

Init: 0xFF

Revert: false

XorOut: 0x00

Check: 0xF7 («123456789»)

*/

const unsigned char CRC8Table[256] — {

0x00, 0x31, 0x62, 0x53, 0xC4, 0xF5, 0xA6, 0x97,

0xB9, 0x88, 0xDB, 0xEA, 0x7D, 0x4C, 0x1F, 0x2E,

0x43, 0x72, 0x21, 0x10, 0x87, 0xB6, 0xE5, 0xD4,

0xFA, 0xCB, 0x98, 0xA9, 0x3E, 0x0F, 0x5C, 0x6D,

0x86, 0xB7, 0xE4, 0xD5, 0x42, 0x73, 0x20, 0x11,

0x3F, 0x0E, 0x5D, 0x6C, 0xFB, 0xCA, 0x99, 0xA8,

0xC5, 0xF4, 0xA7, 0x96, 0x01, 0x30, 0x63, 0x52,

0x7C, 0x4D, 0x1E, 0x2F, 0xB8, 0x89, 0xDA, 0xEB,

0x3D, 0x0C, 0x5F, 0x6E, 0xF9, 0xC8, 0x9B, 0xAA,

0x84, 0xB5, 0xE6, 0xD7, 0x40, 0x71, 0x22, 0x13,

0x7E, 0x4F, 0x1C, 0x2D, 0xBA, 0x8B, 0xD8, 0xE9,

0xC7, 0xF6, 0xA5, 0x94, 0x03, 0x32, 0x61, 0x50,

0xBB, 0x8A, 0xD9, 0xE8, 0x7F, 0x4E, 0x1D, 0x2C,

0x02, 0x33, 0x60, 0x51, 0xC6, 0xF7, 0xA4, 0x95,

0xF8, 0xC9, 0x9A, 0xAB, 0x3C, 0x0D, 0x5E, 0x6F,

0x41, 0x70, 0x23, 0x12, 0x85, 0xB4, 0xE7, 0xD6,

0x7A, 0x4B, 0x18, 0x29, 0xBE, 0x8F, 0xDC, 0xED,

0xC3, 0xF2, 0xA1, 0x90, 0x07, 0x36, 0x65, 0x54,

0x39, 0x08, 0x5B, 0x6A, 0xFD, 0xCC, 0x9F, 0xAE,

0x80, 0xB1, 0xE2, 0xD3, 0x44, 0x75, 0x26, 0x17,

0xFC, 0xCD, 0x9E, 0xAF, 0x38, 0x09, 0x5A, 0x6B,

0x45, 0x74, 0x27, 0x16, 0x81, 0xB0, 0xE3, 0xD2,

0xBF, 0x8E, 0xDD, 0xEC, 0x7B, 0x4A, 0x19, 0x28,

0x06, 0x37, 0x64, 0x55, 0xC2, 0xF3, 0xA0, 0x91,

0x47, 0x76, 0x25, 0x14, 0x83, 0xB2, 0xE1, 0xD0,

0xFE, 0xCF, 0x9C, 0xAD, 0x3A, 0x0B, 0x58, 0x69,

0x04, 0x35, 0x66, 0x57, 0xC0, 0xF1, 0xA2, 0x93,

0xBD, 0x8C, 0xDF, 0xEE, 0x79, 0x48, 0x1B, 0x2A,

0xC1, 0xF0, 0xA3, 0x92, 0x05, 0x34, 0x67, 0x56,

0x78, 0x49, 0x1A, 0x2B, 0xBC, 0x8D, 0xDE, 0xEF,

0x82, 0xB3, 0xE0, 0xD1, 0x46, 0x77, 0x24, 0x15,

0x3B, 0x0A, 0x59, 0x68, 0xFF, 0xCE, 0x9D, 0xAC

};

unsigned char CRC8(unsigned char *lpBlock, unsigned char len)

{

unsigned char crc — 0xFF;

while (len- -)

crc — CRC8Table[crc *lpBlock++];

return crc;

}

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

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

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

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

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

[1]	ETSI TS 126 267	Группа технических спецификаций услуги и системные аспекты; передача данных при экстренном вызове (eCall); тональный модем; общее описание, издание 8
	(3GPP TS 26.267)	(Technical Specification Group Services and System Aspects; eCall Data Transfer; In-band modem solution; General description, Release 8)
[2]	GSM 03.38	Правила кодирования: структура алфавитов и языков, используемых при передаче сервиса коротких сообщений
	(ETS 300 628)	(Digital cellular telecommunication system (Phase 2); Alphabets and language-specific information)
[3]	GSM 03.40	Правила отправки и приема сервиса коротких сообщений
	(ETS 300 536)	(Digital cellular telecommunication system (Phase 2))
[4]	Российская система и план нумерации (утверждены Приказом Министерства информационных технологий и связи Российской Федерации от 17 ноября 2006 г. № 142)
[5]	Технический регламент о безопасности колесных транспортных средств (утвержден Постановлением Правительства Российской Федерации от 10 сентября 2009 г. № 720)

---