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

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

 

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

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

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

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

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

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

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

6.1.3 Настоящий стандарт содержит описание ППУ (протокола EGTS) версии "02", являющегося развитием предыдущей версии ППУ, версии "01".

Описание ППУ (протокола EGTS) версии "01" приведено в приложении Ж.

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

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

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

Для обеспечения совместимости на стороне УСВ и ТП необходима реализация обеих версий протокола.

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

1 Для обеспечения управления выбором протокола при взаимодействии устройств и систем применяются специализированные команды и параметры УСВ, описанные в 6.7.3.2 (таблицы 35, 36, 37).

2 Для обеспечения совместимости необходима реализация и выполнение следующих процедур:

а) для УСВ, поддерживающих протокол версии "02", - задание или отправка на УСВ конфигурационных команд с указанием адреса ТП одновременно с указанием версии протокола, поддерживаемого данной ТП;

б) для УСВ, поддерживающих протокол версии "02", - отправка на УСВ конфигурационных команд, указывающих приоритет выбора версии протокола при взаимодействии с конкретными ТП;

в) для УСВ, поддерживающих протокол версии "02", - отправка конфигурационных команд, указывающих приоритет выбора версии протокола при взаимодействии со всеми ТП;

г) для ТП, поддерживающей протокол версии "02", - отправка на УСВ подтверждений с указанием поддерживаемой версии протокола "02" при авторизации УСВ;

д) для УСВ, поддерживающих протокол версии "02", - при первичной авторизации на ТП необходимо использовать протокол версии "01" и в случае успешной авторизации и передачи данных необходимо выполнить попытку авторизации согласно протоколу версии "02". При успешной авторизации по протоколу версии "02" - определить для передачи данных протокол версии "02". При неуспешной авторизации по протоколу версии "02" 0150 определить для передачи данных протокол версии "01".

Принципы, определяющие выбор версии протокола для обмена данными:

а) выбирается максимально высокая версия протокола, поддерживаемая обеими сторонами обмена;

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

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

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

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

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

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

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

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

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

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

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

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

 

Данные уровня поддержки услуг
Запись RID = 1	Запись RID = 2	...	Запись RID = N

 

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

 

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

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

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

 

Заголовок записи	Данные записи
	Подзапись 1	...	Подзапись N

 

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

 

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

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

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

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

 

Таблица 15

 

Формат отдельной записи ППУ

 

Бит 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	RPP			TMFE	EVFE	OBFE
OID (Object Identifier)								O	ULONG	8
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... 65494

 

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

- 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 - сервис-получатель расположен на ТП;

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

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

 

 

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

 

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

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

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

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

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

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

Формат отдельной подзаписи в ППУ приведен в таблице 16.

 

Таблица 16

 

Формат отдельной подзаписи ППУ

 

Бит 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 На каждую информационную запись уровня поддержки услуг должно быть отправлено подтверждение, которое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки. Диаграмма, поясняющая работу механизма подтверждений при обмене сообщениями на уровне поддержки услуг, представлена на рисунке 7.

 

 

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

 

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

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

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

 

Таблица 17

 

Список сервисов, поддерживаемых ППУ

 

Код	Название	Описание	Варианты конфигурации УСВ			Спецификация сервиса
			ДО <1>	ШСЭ <2>	ШСД <3>
1	EGTS_AUTH_SERVICE	Данный тип сервиса применяется для осуществления процедуры аутентификации УСВ на ТП. При использовании TCP/IP протокола УСВ он должен проходить данную процедуру, и только после успешного завершения данной процедуры происходит дальнейшее взаимодействие	+	+	+	6.7.2
2	EGTS_TELEDATA_SERVICE	Сервис предназначен для обработки телематической информации (координатные данные, данные о срабатывании датчиков и т.д.), поступающей от УСВ	+	+	+	Приложение И
4	EGTS_COMMANDS_SERVICE	Данный тип сервиса предназначен для обработки управляющих и конфигурационных команд, информационных сообщений и статусов, передаваемых между УСВ, ТП и операторами	+	+	+	6.7.3
9	EGTS_FIRMWARE_SERVICE	Сервис предназначен для передачи на УСВ конфигурации и непосредственно самого программного обеспечения аппаратной части самого УСВ, а также различного периферийного оборудования, подключенного к УСВ и поддерживающего возможность удаленного обновления программного обеспечения	+	+	+	6.7.4
10	EGTS_ECALL_SERVICE	Сервис, обеспечивающий выполнение функционала ЭРА. Сервис описан в разделе 7	+	+	+	7.3
11	EGTS_SR_TACHOGRAPH	Сервис, обеспечивающий передачу данных тахографического контроля	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
21	EGTS_FARE_SERVICE	Сервис, обеспечивающий выполнение функций контроля и оплаты проезда в пассажирском транспорте	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
22	EGTS_EUROPROTOCOL_SERVICE	Сервис, предназначенный для определения, регистрации и передачи информации об обстоятельствах ДТП	+	-	+	9
23	EGTS_TELEDATA_OPTIONAL_SERVICE	Сервис, обеспечивающий выполнение расширенных функций контроля за работой дополнительного оборудования ТС	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
24	EGTS_CAR_CONDITION_SERVICE	Сервис, обеспечивающий выполнение функций контроля за состоянием и работой ТС	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
25	EGTS_CARGO_SERVICE	Сервис, обеспечивающий выполнение функций транспортной логистики	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
26	EGTS_TOLL_SERVICE	Сервис, обеспечивающий выполнение функций контроля за проездом по платным дорогам	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
27	EGTS_AUTOPILOT_SERVICE	Сервис, обеспечивающий выполнение функций автопилотирования ТС	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
28	EGTS_DISPATCHING_SERVICE	Сервис, обеспечивающий выполнение функций диспетчерского управления пассажирским транспортом	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
29	EGTS_GSM_SERVICE	Сервис, обеспечивающий выполнение функций передачи данных состояния GSM-сети	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
30	EGTS_RFID_SERVICE	Сервис, обеспечивающий выполнение функций передачи данных считывания RFID меток	+	-	+	Перспективный блок спецификации. Разрабатывается совместно с производителем оборудования
40	EGTS_NOTIFICATION_SERVICE	Сервис передачи на бортовое оборудование сообщений и оповещений	+	-	+	Приложение К
<1> УСВ, исполненная в конфигурации дополнительного оборудования. <2> УСВ, исполненная в конфигурации штатного оборудования и предназначенная для реализации только базовой услуги системой экстренного реагирования при авариях. <3> УСВ, исполненная в конфигурации штатного оборудования и предназначенная для реализации дополнительных, кроме базовой, услуг системой экстренного реагирования при авариях.

 

Код сервиса, указанный в таблице 17, приводится в заголовке записи ППУ (поля SST и RST).

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

6.7.2 Сервис EGTS_AUTH_SERVICE

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

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

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

 

Таблица 18

 

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

 

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

 

6.7.2.1 Подзапись EGTS_SR_RECORD_RESPONSE

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

 

Таблица 19

 

Формат подзаписи 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 и в случае получения статуса об успешной обработке стирает запись из внутреннего хранилища, иначе в случае ошибки и в зависимости от причины производит соответствующие действия.

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

6.7.2.2 Подзапись EGTS_SR_TERM_IDENTITY

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

 

Таблица 20

 

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

сервиса EGTS_AUTH_SERVICE

 

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
TID (TerminalIdentifier)								M	ULONG	8
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
SSLPV (Service Support Level Protocol Version)								O	STRING	2

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--------------------------------

<1> В Российской Федерации "Российская система и план нумерации" утверждены приказом Министерства связи и массовых коммуникаций Российской Федерации от 25 апреля 2017 г. N 205.

 

- SSLPV - Номер версии протокола уровня поддержки услуг (номер версии протокола EGTS). Версия протокола уровня поддержки услуг (номер версии протокола EGTS) состоит из двух символов, левый символ "0" для версий от 1 до 9, "01" ... "09" соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.

 

Таблица 21

 

Формат поля NID подзаписи EGTS_SR_TERM_IDENTITY

сервиса EGTS_AUTH_SERVICE

 

Биты 20...23	Биты 10...19	Биты 0...9	Тип	Тип данных	Размер, байт
-	MCC (Mobile Country Code)	MNC (Mobile Network Code)	M	BINARY	3

 

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

- MCC - код страны;

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

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

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

- взаимодействие с использованием протокола версии "01";

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

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

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

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

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

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

6.7.2.3 Подзапись EGTS_SR_MODULE_DATA

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

 

Таблица 22

 

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

сервиса EGTS_AUTH_SERVICE

 

Бит 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

Структура подзаписи представлена в таблице 23. Данная подзапись должна передаваться совместно с EGTS_SR_TERM_IDENTITY.

 

Таблица 23

 

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

сервиса EGTS_AUTH_SERVICE

 

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

 

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

- VIN - идентификационный номер ТС. Передается в двух полях VINL - последние 17 знаков, VINH - оставшаяся часть;

- VHT - тип ТС:

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),

20 - маломерное судно некоммерческого использования,

21 - маломерное судно коммерческого использования,

22 - 64 - зарезервировано для судов иных типов;

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

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

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

в) бит 4:1 - электричество,

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

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

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

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

6.7.2.5 Подзапись EGTS_SR_AUTH_PARAMS

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

 

Таблица 24

 

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

сервиса EGTS_AUTH_SERVICE

 

Бит 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

 

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

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

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

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

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

- PKE (Public Key Enable) - битовый флаг, определяет наличие полей PKL и PBK (если 1, то поля присутствуют);

- ENA (Encryption Algorithm) - битовое поле, определяющее требуемый алгоритм шифрования пакетов. Если данное поле содержит значение 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

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

 

Таблица 25

 

Структура подзаписи EGTS_SR_AUTH_INFO

сервиса EGTS_AUTH_SERVICE

 

Бит 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

 

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

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

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

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

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

6.7.2.7 Подзапись EGTS_SR_SERVICE_INFO

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

 

Таблица 26

 

Структура подзаписи EGTS_SR_SERVICE_INFO

сервиса EGTS_AUTH_SERVICE

 

Бит 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

 

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

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

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

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

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

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

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

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

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

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

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

г) 11 - низкий.

 

Таблица 27

 

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

 

Код	Название	Описание
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

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

 

Таблица 28

 

Структура подзаписи EGTS_SR_RESULT_CODE

сервиса EGTS_AUTH_SERVICE

 

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

 

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

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

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

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

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

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

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

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

В случае установки параметров для УСВ, работающего по протоколу версии "02", может быть установлен параметр EGTS_PROTOCOL_CHOICE с массивом данных, определяющих перечень серверов ТП.

В массиве данных параметра EGTS_PROTOCOL_CHOICE будут переданы для каждой принимающей ТП:

- IPv4 адрес и порт для установки TCP/IP-соединения;

- вариант процедуры выбора версии протокола обмена данными:

0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола ("01") заканчивая старшей версией протокола ("02") согласно процедурам и принципам, описанным в 6.1.3,

1 - УСВ использует для обмена данными с указанной ТП версию протокола "01",

2 - УСВ использует для обмена данными с указанной ТП версию протокола "02".

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

 

 

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

 

Алгоритм конфигурирования для УСВ, работающих по протоколу версии "02" с дополнительными параметрами выбора версии протокола, представлен на рисунке 9.

 

 

--------------------------------

<*> Массив данных 1 - массив данных, определяющих перечень серверов телематических платформ, с которыми необходимо установить TCP/IP-соединение. В массиве данных передаются для каждой ТП: IPv4 адрес и порт для установки TCP/IP-соединения; вариант процедуры выбора версии протокола обмена данными

 

Рисунок 9 - Алгоритм конфигурации УСВ версии "02"

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

 

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

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

 

 

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

 

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

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

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

Алгоритм выбора версии протокола при авторизации УСВ на стороне ТП представлен на диаграмме, приведенной на рисунке 11. Принципы выбора протокола приведены в 6.1.3.

 

 

Рисунок 11 - Алгоритм выбора версии протокола

при авторизации УСВ на стороне ТП

 

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

 

 

Рисунок 12 - Обмен сообщениями

на этапе авторизации УСВ на ТП

 

После успешного подключения УСВ к ТП по протоколу 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.1.3.

6.7.2.10 Описание процедуры авторизации (при использовании функций мониторинга ТС)

При использовании УСВ функций мониторинга процедура авторизации должна осуществляться в соответствии с требованиями, приведенными в ГОСТ 33472-2023 (раздел В.3.2.3).

6.7.2.11 Подзапись EGTS_SR_DISPATCHER_IDENTITY

Формат подзаписи EGTS_SR_DISPATCHER_IDENTITY сервиса EGTS_AUTH_SERVICE представлен в таблице 29.

 

Таблица 29

 

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

сервиса EGTS_AUTH_SERVICE

 

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
DT (Dispatcher Type)								M	BYTE	1
DID (Dispatcher ID)								M	UINT	4
TID (TerminalIdentifier)								M	ULONG	8
SSLPV (Service Support Level Protocol Version)								O	STRING	2
DSCR (Description)								O	STRING	0...255

 

Поля подзаписи EGTS_SR_DISPATCHER_IDENTITY:

- DT - тип диспетчера;

- DID - уникальный идентификатор диспетчера;

- DSCR - краткое описание;

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

- SSLPV - номер версии ППУ авторизуемого УСВ (номер версии протокола EGTS). Версия ППУ (номер версии протокола EGTS) состоит из двух символов, левый символ "0" для версий от 1 до 9, "01" ... "09" соответственно, далее оба поля заполняются согласно цифрам двузначного числа номера версии.

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

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

- взаимодействие с использованием протокола версии "01";

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

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

6.7.2.12 Подзапись EGTS_SR_VEHICLE_DATA_ADD

Структура подзаписи представлена в таблице 30. Данная подзапись должна передаваться совместно с EGTS_SR_TERM_IDENTITY.

 

Таблица 30

 

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

сервиса EGTS_AUTH_SERVICE

 

Бит 7	Бит 6	Бит 5	Бит 4	Бит 3	Бит 2	Бит 1	Бит 0	Тип	Тип данных	Размер, байт
			VNE	VPE	VTE	VBE	VME	M	BYTE	1
VSRM (Vehicle State Registration Mark)								M	STRING	32
VM (Vehicle Model)								O	STRING	64
VB (Vehicle Brand)								O	STRING	32
VOTIN (Vehicle Owner Taxpayer Identification Number)								O	STRING	12
VOPSRN (Vehicle Owner Primary State Registration Number)								O	STRING	15
VON (Vehicle Owner Name)								O	STRING	64

 

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

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

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

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

- VNE (Vehicle Name Enable) - битовый флаг, который определяет наличие поля VON в подзаписи (если бит равен 1, то поле передается, если 0, то не передается).

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

- VSRM - государственный регистрационный знак (номер) ТС;

- VM - модель ТС;

- VB - марка ТС;

- VOTIN - ИНН собственника ТС;

- VOPSRN - ОГРН собственника ТС;

- VON - наименование организации - собственника ТС.

6.7.3 Сервис EGTS_COMMANDS_SERVICE

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

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

 

Таблица 31

 

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

 

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

 

6.7.3.1 Подзапись EGTS_SR_COMMAND_DATA

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

 

Таблица 32

 

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

сервиса EGTS_COMMANDS_SERVICE

 

Бит 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...65205

 

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

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

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

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

в) 0011 - CT_MSGFROM - информационное сообщение от УСВ,

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

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

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

а) 1 - поля ACL и AC присутствуют в подзаписи,

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

- 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 (рисунок Е.2),

и) 7 - Latin/Hebrew (рисунок Е.3),

к) 8 - UCS2;

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

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

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

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

 

Таблица 33

 

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

 

Бит 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

 

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

- 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, если с УСВ передается сопутствующая информация, имеет формат, представленный в таблице 34. Описанная структура содержится в поле CD.

 

Таблица 34

 

Формат подтверждения на команду УСВ

 

Бит 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

 

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

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

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

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

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

Список и описание команд для УСВ представлены в таблице 35, список подтверждений на команды и сообщения от УСВ - в таблице 36; список параметров УСВ - в таблице 37.

 

Таблица 35

 

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

 

Название команды	Код	Тип, число и предельное значение параметра	Описание
EGTS_RAW_DATA	0x0000	BINARY (до 65200 байт)	Команда для передачи произвольных данных. Применяется, например, для передачи команд, сообщений и данных на периферийные устройства, модули, подключенные к основному блоку УСВ, в определяемом данным модулем формате. При этом УСВ не должна анализировать данные из поля DT и в неизменном виде передавать их по адресу, определяемому полем ADR
EGTS_TEST_MODE	0x0001	BYTE	Команда начала/окончания тестирования УСВ: 1 - начало тестирования; 0 - окончание тестирования
EGTS_CONFIG_RESET	0x0006	-	Возврат к заводским установкам. Удаляются все установленные пользователем параметры, и производится возврат к заводским установкам. Для обработки данной команды оператор должен установить корректные значения полей ACL и AC, указанных в таблице 29
EGTS_SET_AUTH_CODE	0x0007	BINARY	Установка кода авторизации на стороне УСВ. Для обработки данной команды оператор должен установить корректные значения полей ACL и AC, указанных в таблице 29. После подтверждения данной команды УСВ будет использовать уже новые данные для сравнения со значением из поля AC в некоторых присылаемых на УСВ командах
EGTS_RESTART	0x0008	-	Команда производит перезапуск основного программного обеспечения УСВ. Для обработки данной команды оператор должен установить корректные значения полей ACL и AC, указанных в таблице 29
EGTS_TEST_GET_ERRORS	0x0004	-	Запрос кодов ошибок
EGTS_TEST_CLEAR_ERRORS	0x0005	-	Очистка кодов ошибок. Для обработки данной команды оператор должен установить корректные значения полей ACL и ACH
EGTS_SET_ON_READY	0x050A	-	Команда включения для УСВ режима постоянной регистрации в сети связи. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS
EGTS_SET_OFF_READY	0x050B	-	Команда отключения для УСВ режима постоянной регистрации в сети связи. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS
EGTS_SET_ON_ACCIDENT	0x060A	-	Команда включения для УСВ режима сбора информации об обстоятельствах ДТП. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS
EGTS_SET_OFF_ACCIDENT	0x060B	-	Команда отключения для УСВ режима сбора информации об обстоятельствах ДТП. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS
EGTS_SEND_ACCIDENT_DATA	0x060C	-	Команда запроса УСВ для передачи информации об обстоятельствах ДТП
EGTS_SET_ON_MONITOR	0x070A	-	Команда включения для УСВ режима передачи мониторинговой информации. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS
EGTS_SET_OFF_MONITOR	0x070B	-	Команда отключения для УСВ режима передачи мониторинговой информации. Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS
EGTS_SET_PROTOCOL_CHOICE	0x080A	-	Команда установки правила выбора версии протокола поддержки услуг (версии протокола EGTS). Данная команда может быть принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. Команда реализует условия выбора версии согласно установленным параметрам УСВ (см. таблицу 37, параметр EGTS_PROTOCOL_CHOICE). Без использования команды EGTS_SET_PROTOCOL_CHOICE при взаимодействии со всеми ТП УСВ реализует вариант процедуры выбора версии протокола обмена данными: 0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола ("01") и заканчивая старшей версией протокола ("02"), согласно процедурам и принципам, описанным в разделе 6.1.3

 

Таблица 36

 

Список подтверждений на команды и сообщения от УСВ

 

Название команды	Код	Тип и число параметра	Описание
EGTS_RAW_DATA	0x0000	BINARY (до 65200 байт)	Данные, поступающие от периферийных устройств, модулей, подключенных к основному блоку УСВ, в определяемом данным модулем формате
EGTS_SELF_TEST_RESULT	0x0002	STRING	Сообщение о результатах самодиагностики. Генерируется УСВ автоматически без запроса от оператора
EGTS_TEST_GET_ERRORS	0x0004	BINARY (16 байт)	Список кодов ошибок состояний блоков, модулей и подсистем терминала
EGTS_SET_ON_READY	0x050A	BINARY (1 байт)	Подтверждение включения для УСВ режима постоянной регистрации в сети. Если команда EGTS_SET_ON_READY принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. Параметр интерпретируется как битовое поле, определяющее состояние регистрации в сети и успешное установление TCP соединения с сервером. Бит 0 соответствует установлению постоянной регистрации в сети сотовой связи, бит 1 соответствует установлению постоянного TCP соединения с сервером. Если бит имеет значение 0 - условие не выполнено, 1 - выполнено. На данную команду может быть отправлено несколько подтверждений с разным значением флагов (при задержках в установлении TCP соединения)
EGTS_SET_OFF_READY	0x050B	BINARY (1 байт)	Подтверждение отключения для УСВ режима постоянной регистрации в сети. Если команда EGTS_SET_OFF_READY принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. Параметр интерпретируется как битовое поле, определяющее состояние постоянной регистрации в сети и успешное отключение TCP соединения с сервером. Бит 0 соответствует установлению постоянной регистрации в сети сотовой связи, бит 1 соответствует установлению постоянного TCP соединения с сервером. Если бит 0 имеет значение 0 - постоянная регистрация не установлена, 1 - постоянная регистрация установлена (не может быть отключена в данный момент). Если бит 1 имеет значение 0 - постоянное TCP соединение отключено, 1 - постоянное TCP соединение поддерживается (не может быть отключено в данный момент). На данную команду может быть отправлено несколько подтверждений с разными значениями флагов (при задержках в завершении TCP соединения)
EGTS_SET_ON_ACCIDENT	0x060A	BOOLEAN	Подтверждение включения для УСВ режима сбора информации об обстоятельствах ДТП. Если команда EGTS_SET_ON_ACCIDENT принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. TRUE - успешное установление УСВ режима сбора информации об обстоятельствах ДТП. FALSE - при установлении УСВ режима сбора информации об обстоятельствах ДТП возникла ошибка
EGTS_SET_OFF_ACCIDENT	0x060B	BOOLEAN	Подтверждение отключения для УСВ режима сбора информации об обстоятельствах ДТП. Если команда EGTS_SET_OFF_ACCIDENT принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. TRUE - успешное отключение УСВ режима сбора информации об обстоятельствах ДТП. FALSE - при отключении УСВ режима сбора информации об обстоятельствах ДТП возникла ошибка
EGTS_SEND_ACCIDENT_DATA	0x060C	BOOLEAN	Подтверждение приема запроса УСВ для передачи информации об обстоятельствах ДТП. TRUE - УСВ готова к передаче информации об обстоятельствах ДТП. FALSE - УСВ не готова к передаче информации об обстоятельствах ДТП или возникла ошибка
EGTS_SET_ON_MONITOR	0x070A	BOOLEAN	Подтверждение включения для УСВ режима передачи мониторинговой информации. Если команда EGTS_SET_ON_MONITOR принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. TRUE - успешное установление УСВ режима передачи мониторинговой информации. FALSE - при установлении УСВ режима передачи мониторинговой информации возникла ошибка
EGTS_SET_OFF_MONITOR	0x070B	BOOLEAN	Подтверждение отключения для УСВ режима передачи мониторинговой информации. Если команда EGTS_SET_OFF_MONITOR принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. TRUE - успешное отключение УСВ режима передачи мониторинговой информации. FALSE - при отключении УСВ режима передачи мониторинговой информации возникла ошибка
EGTS_SET_PROTOCOL_CHOICE	0x080B	BOOLEAN	Подтверждение установки режима выбора версии протокола согласно установленным параметрам. Если команда EGTS_SET_PROTOCOL_CHOICE принята УСВ с помощью SMS - в этом случае подтверждение необходимо отправить по SMS. TRUE - успешное применение параметров выбора версии протокола с учетом установленных параметров EGTS_PROTOCOL_CHOICE. FALSE - при применении параметров выбора версии протокола возникла ошибка или параметры EGTS_PROTOCOL_CHOICE некорректны

 

Таблица 37

 

Список параметров УСВ

 

Имя параметра	Код	Тип параметра	Значение по умолчанию	Описание	Применимость <1>	Возможность изменения <2>
Радио mute
EGTS_RADIO_MUTE_DELAY	0x0201	INT	0	Задержка между установкой сигнала радио mute и началом проигрывания звука, мс	ДО	Да
EGTS_RADIO_UNMUTE_DELAY	0x0202	INT	0	Задержка между снятием сигнала радио mute и окончанием проигрывания звука, мс	ДО	Да
Установки общего назначения
EGTS_GPRS_APN	0x0203	STRING	""	Параметр, определяющий точку доступа СПРС	ДО, ШСД	Да
EGTS_SERVER_ADDRESS	0x0204	STRING	""	Адрес и порт сервера для связи с использованием TCP/IP протокола	ДО, ШСЭ, ШСД	Да
EGTS_SIM_PIN	0x0205	INT	0	PIN-код SIM-карты	ДО, ШСЭ, ШСД	Да
EGTS_INT_MEM_TRANSMIT_INTERVAL	0x0206	INT	60	Интервал между повторными попытками отправки сообщений в случае неудачной отправки посредством пакетной передачи или через SMS, мин	ДО, ШСЭ, ШСД	Да
EGTS_INT_MEM_TRANSMIT_ATTEMPTS	0x0207	INT	10	Максимальное число попыток передачи сообщения посредством пакетной передачи или через SMS в случае ошибок передачи	ДО, ШСЭ, ШСД	Да
Режим тестирования
EGTS_TEST_REGISTRATION_PERIOD	0x0242	INT	5	Если УСВ была зарегистрирована в сети посредством нажатия на кнопку "Дополнительные функции", то последующая регистрация УСВ в сети при нажатии на эту кнопку возможна не ранее, чем через данный промежуток времени. Если значение установлено в 0, то ограничений на последующую регистрацию УСВ в сети не накладывается, мин	ДО, ШСЭ, ШСД	Да
EGTS_TEST_MODE_END_DISTANCE	0x020A	INT	300	Дистанция, на которой режим тестирования выключается автоматически, м	ДО, ШСЭ, ШСД	Да
Режим "Автосервис"
EGTS_GARAGE_MODE_END_DISTANCE	0x020B	INT	300	Дистанция, на которой режим "Автосервис" выключается автоматически, м	ДО	Да
EGTS_GARAGE_MODE_PIN	0x020C	INT/{NONE=0, PIN_1 =1, ... PIN_8=8}	0	Линия, сигнализирующая, что УСВ находится в режиме "Автосервис": NONE - нет сигнализации режима; X - PIN_X линия активная, когда система находится в данном режиме	ДО	Да
Прочие параметры
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_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_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 соединения с сервером, по достижении которого будет произведена повторная установка сессии верхнего уровня (СПРС)	ДО, ШСД	Да
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	Уровень громкости динамика	ДО, ШСЭ, ШСД	Да
ERA_TO_EMERGENCY_CALL_AUTO_TRANSITION		INT	10	Количество переходов УСВ из режима "ЭРА" в режим "Экстренный вызов" при автоматическом срабатывании системы	ДО, ШО	Да
ERA_TO_EMERGENCY_CALL_MANUAL_TRANSITION		INT	20	Количество переходов УСВ из режима "ЭРА" в режим "Экстренный вызов" при ручном срабатывании системы	ДО, ШО	Да
ERA_TO_EMERGENCY_CALL_TRANSITION_PERIOD		INT	1440	Временной интервал, в течение которого производится подсчет переходов УСВ из режима "ЭРА" в режим "Экстренный вызов", мин	ДО, ШО	Нет
EGTS_SELFTEST_INTERVAL	0x0208	INT	0	Интервал проведения внутреннего тестирования, ч. Если значение установлено в 0, то самотестирование не проводится	ДО, ШСЭ, ШСД	Да
EGTS_POST_TEST_REGISTRATION_TIME	0x0209	INT	0	Промежуток времени, в течение которого устройство остается зарегистрированным в сети после передачи результатов самотестирования оператору системы, с	ДО, ШСЭ, ШСД	Да
EGTS_TEST_REGISTRATION_TIMEOUT	0x0241	INT	5	Если устройство было зарегистрировано в сети посредством нажатия на кнопку включения дополнительных услуг и команда на запуск сессии тестирования не была получена со стороны оператора системы в течение данного промежутка времени, то устройство должно прекратить регистрацию в сети, мин	ДО, ШСЭ, ШСД	Да
EGTS_TEST_MODE_WATCHDOG	0x020E	INT	10	Интервал тревожного счетчика в режиме тестирования, мин	ДО, ШСЭ, ШСД	Да
EGTS_USE_GPRS_WHITE_LIST	0x0230	BOOLEAN	1	Параметр, указывающий на необходимость использования GPRS_WHITE_LIST при организации пакетной передачи данных	ДО, ШСЭ, ШСД	Да
EGTS_GPRS_WHITE_LIST	0x0231	ARRAY OF STRING	"", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", "", ""	Список сетей, в которых разрешена пакетная передача данных. Если список GPRS_WHITE_LIST пуст, то пакетная передача данных запрещена, MCC (Mobile Country Code) 3 символа + MNC (Mobile Network Code) 3 символа	ДО, ШСЭ, ШСД	Да
EGTS_UNIT_ANGUAGE_ID	0x0410	INT	0	Предпочтительный язык для голосового общения (см. [8]): 0x5F - русский	ДО, ШСЭ, ШСД	Да
EGTS_READY_PROFILE	0x0501	INT	0	Значение номера профиля передачи данных в сервисе EGTS_TELEDATA_SERVICE, в котором УСВ ведет передачу данных сразу после получения команды на включение режима постоянной регистрации в сети. По умолчанию 0 - не ведет передачу данных сразу после получения команды на включение режима постоянной регистрации в сети до получения соответствующей команды на режим передачи данных сервиса EGTS_TELEDATA_SERVICE	ДО, ШСЭ, ШСД	Да
EGTS_MONITOR_PROFILE	0x0701	INT	1	Значение номера профиля передачи данных в сервисе EGTS_TELEDATA_SERVICE, в котором УСВ ведет передачу данных сразу после получения команды на включение режима передачи мониторинговой информации. По умолчанию 1 - ведет передачу данных сразу после получения команды на включение режима передачи мониторинговой информации в профиле N 1	ДО, ШСЭ, ШСД	Да
EGTS_CONNECT_ACCIDENT	0x066B	ARRAY OF INT	0, 0, 0, 0, 0	Элементы массива определяют адрес и порт сервера приема данных для режима передачи информации об обстоятельствах ДТП: - первое слева направо число адреса IPv4 - второе слева направо число адреса IPv4 - третье слева направо число адреса IPv4 - четвертое слева направо число адреса IPv4 - номер порта	ДО, ШСД	Да
EGTS_PROTOCOL_CHOICE	0x0801	ARRAY OF INT	1, 0, 0, 0, 0, 0, 0	Элементы массива определяют адрес и порт серверов ТП и режимы выбора версии протокола для каждой из них. Первый элемент массива - номер профиля ТП. По умолчанию используется один профиль N 1. Следующие элементы массива определяют адрес и порт сервера приема данных для данного профиля: - первое слева направо число адреса IPv4 - второе слева направо число адреса IPv4 - третье слева направо число адреса IPv4 - четвертое слева направо число адреса IPv4 - номер порта Следующие элементы определяют вариант процедуры выбора версии протокола обмена данными: 0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на телематическую платформу, начиная с младшей версии протокола ("01") и заканчивая старшей версией протокола ("02"), согласно процедурам и принципам, описанным в разделе 6.1.3 данного стандарта.	ДО, ШСЭ, ШСД	Да
				1 - УСВ использует для обмена данными с указанной ТП версию протокола "01". 2 - УСВ использует для обмена данными с указанной ТП версию протокола "02". При передаче на УСВ параметров с первым элементом массива = 0 для всех ТП, не указанных в массиве профилей, будет применяться вариант процедуры выбора версии протокола обмена данными, указанный в данной записи, то есть в ячейке профиля с N 0. Например, при передаче на УСВ массива 0,0,0,0,0,0,1 для всех ТП (кроме записанных в памяти с другими номерами профиля) будет применена процедура выбора 1 - УСВ использует для обмена данными версию протокола "01". Пример организации хранения параметров приведен в таблице 35
<1> ДО - для УСВ, исполненной в конфигурации дополнительного оборудования; ШСЭ - для УСВ, исполненной в конфигурации штатного оборудования и предназначенной для реализации только базовой услуги системой; ШСД - для УСВ, исполненной в конфигурации штатного оборудования и предназначенной для реализации дополнительных, кроме базовой, услуг системой. <2> "Да" в этой графе означает, что установленное начальное значение параметра УСВ может изменяться после начальной установки УСВ, "Нет" - что установленные начальные значения не подлежат изменению в процессе применения УСВ.

 

Таблица 38

 

Пример заполнения массива параметров процедуры выбора

версии протокола обмена данными EGTS_PROTOCOL_CHOICE

 

Первая позиция массива - номер профиля ТП	Вторая позиция массива - первое слева направо число адреса IPv4	Третья позиция массива - первое слева направо число адреса IPv4	Четвертая позиция массива - первое слева направо число адреса IPv4	Пятая позиция массива - первое слева направо число адреса IPv4	Шестая позиция массива - номер порта	Седьмая позиция массива - вариант процедуры выбора версии протокола обмена данными	Примечание
0	0	0	0	0	0	1	Для всех платформ, кроме указанных в других ячейках массива (10.5.64.100 и 10.0.0.20), будет применяться вариант выбора 1 - УСВ использует для обмена данными версию протокола "01"
1	10	5	64	100	80	0	Для платформы 10.5.64.100 будет применяться вариант выбора 0 - выбор осуществляется последовательным выполнением попыток авторизации и передачи данных на ТП, начиная с младшей версии протокола ("01") и заканчивая старшей версией протокола ("02"), согласно процедурам и принципам, описанным в разделе 6.1.3
2	10	0	0	20	80	2	Для платформы 10.0.0.20 будет применяться вариант выбора 2 - УСВ использует для обмена данными с указанной ТП версию протокола "02"

 

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

- EGTS_UNIT_SERIAL_NUMBER,

- EGTS_UNIT_HW_VERSION;

- EGTS_UNIT_SW_VERSION;

- EGTS_UNIT_VENDOR_ID;

- EGTS_INIT_IMEI.

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

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

- EGTS_GPRS_APN;

- EGTS_SERVER_ADDRESS;

- EGTS_PROTOCOL_CHOICE;

- EGTS_READY_PROFILE;

- EGTS_SIM_PIN;

- EGTS_AUTOMATIC_REGISTRATION;

- EGTS_TEST_MODE_END_DISTANCE;

- EGTS_GARAGE_MODE_END_DISTANCE;

- EGTS_TEST_REGISTRATION_PERIOD;

- EGTS_GNSS_POWER_OFF_TIME;

- EGTS_GNSS_DATA_RATE;

- EGTS_GNSS_MIN_ELEVATION;

- EGTS_UNIT_ID;

- EGTS_UNIT_IMEI;

- EGTS_UNIT_HOME_DISPATCHER_ID;

- EGTS_INT_MEM_TRANSMIT_INTERVAL;

- EGTS_INT_MEM_TRANSMIT_ATTEMPTS;

- EGTS_SELFTEST_INTERVAL;

- EGTS_POST_TEST_REGISTRATION_TIME;

- EGTS_TEST_REGISTRATION_TIMEOUT;

- EGTS_TEST_MODE_WATCHDOG;

- EGTS_USE_GPRS_WHITE_LIST;

- EGTS_UNIT_ANGUAGE_ID.

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

 

 

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

 

 

 

 

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

 

6.7.4 Сервис EGTS_FIRMWARE_SERVICE

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

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

 

Таблица 39

 

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

 

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

 

6.7.4.1 Подзапись EGTS_SR_SERVICE_PART_DATA

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

 

Таблица 40

 

Структура подзаписи EGTS_SR_SERVICE_PART_DATA

сервиса EGTS_FIRMWARE_SERVICE

 

Бит 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 представлена в настоящей таблице. 5 OD - данные непосредственно передаваемой сущности.

 

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

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

 

Таблица 41

 

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

EGTS_SR_SERVICE_PART_DATA сервиса EGTS_FIRMWARE_SERVICE

 

Бит 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

 

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

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

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

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

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

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

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

б) 01 - УСВ.

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

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

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

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

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

6.7.4.2 Подзапись EGTS_SR_SERVICE_FULL_DATA

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

 

Таблица 42

 

Структура подзаписи EGTS_SR_SERVICE_FULL_DATA

сервиса EGTS_FIRMWARE_SERVICE

 

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

 

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

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

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

 

Таблица 43

 

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

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

 

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