ГОСТ Р 56360—2015
OBFE (Object ID Field Exists)— битовое поле, определяющее наличие вданном пакете поля OID:
1— поле OID присутствует.
0 — поле OID отсутствует;
OID (Object Identifier) — идентификатор объекта, сгенерировавшего данную запись или для которого данная
запись предназначена (уникальный идентификатор АСН), либо идентификатор группы (при GRP =1). При пере
даче от АСН в одном пакете транспортного уровня нескольких записей подряд для разных сервисов, но от одного и
того же объекта, поле OID может присутствовать только в первой записи, а в последующих записях может быть
опущено.
EVID (Event Identifier) — уникальный идентификатор события. Поле EVID задает глобальный идентификатор
события и применяется, когда необходимо логически связать с одним-единственным событием набор несколь ких
информационных сущностей, причем сами сущности могут быть разнесены как по разным информационным
пакетам, так и по времени. При этом прикладное ПО имеет возможность объединить все зги сущности воедино в
момент представления пользователю информации о событии. Например, если с нажатием тревожной кнопки
связывается серия фотоснимков, поле EVID должно быть указано в каждой сервисной записи, связанной с этим
событием на протяжении передачи всех сущностей, связанных с данным событием, независимо от того, какдолго не
длилась передача всего пула информации;
ТМ (Time) — времяформирования записи на сторонеотправителя (секунды с 00:00:00 01.01.2010 UTC). Если
в одном пакете транспортного уровня передаются несколько записей, относящихся к одному объекту и моменту
времени, то попе метки времени ТМ может передаваться только в составе первой записи:
SST (Source Service Type) — идентификатор типа сервиса-отправителя, сгенерировавшего данную запись.
Например, сервис, обрабатывающий навигационные данные на стороне АСН. сервис команд на стороне ТП и т.д.;
RST (Recipient Service Type)— идентификатор типа сервиса-получателя данной записи. Например, сервис,
обрабатывающий навигационные данные на стороне ТП. сервисобработки команд на стороне АСН и т.д.;
RD (Record Data) — поле, содержащее информацию, присущую определенному типу сервиса (одну или
несколько подзаписей сервиса типа, указанного в поле SST или RST. в зависимости от вида передаваемой
информации).
В.2.3 Общая структура подзаписей
В таблице В.2 представлен формат отдельной подзаписи протокола уровня поддержки услуг.
Таблица В.2 — Формат отдельной подзаписи протокола уровня поддержки услуг
Бит 7БитеБит 5Бит 4Бит 3Бит 2Бит 1Бит 0ТипТип данных
Размер.
байт
SRT (Subrecord Туре)
МBYTE
1
SRL (Subrecord Length)
м
USHORT
2
SRD (Subrecord Data)
ОBINARY
0... 65495
Поля таблицы В.2 содержат:
SRT (Subrecord Туре) — тип подзаписи (подтип передаваемых данных в рамках общего набора типов одного
сервиса). Тип 0 — специальный, зарезервирован за подзаписью подтверждения данных для каждого сервиса. Кон
кретные значения номеров типов подзаписей определяются логикой самого сервиса. Протокол указывает лишь то,
что этот номер должен присутствовать, а нулевой идентификатор зарезервирован;
SRL (Subrecord Length) — длина данных в байтах подзаписи в поле SRD;
SRD (Subrecord Data) — данные подзаписи. Наполнение данного поля специфично для каждого сочетания
идентификатора типа сервиса и типа подзаписи.
На каждую информационную запись уровня поддержки услуг должно быть отправлено подтверждение, кото
рое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки.
Описание и формат подтверждения представлены в В.3.2.2. подпункт а).
На рисунке В.З представлен алгоритм работы механизма подтверждений протокола уровня поддержки услуг.
Каждое сообщение протокола содержит в себе заголовок и контрольную сумму транспортного уровня и одну
или несколько записей уровня поддержки услуг. Причем водном сообщении могут содержаться как информацион
ные записи, так и подтверждения на ранее принятые записи.
45