ГОСТ Р 56361—2015
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Бит 6Бит 5Бит 4Бит 3Бит 2Бит 1Бит 0ТипТип данныхРаамер. байт
SRT (Subrecord Туре)
MBYTE
1
SRL (Subrecord Length)
MUSHORT
2
SRD (Subrecord Data)
ОBINARY
0... 65495
Поля таблицы В.2 содержат:
SRT (Subrecord Туре) — тип подзаписи (подтип передаваемых данных в рамках общего набора типов одного
сервиса). Тип 0 — специальный, зарезервирован за подзаписью подтверждения данных для каждого сервиса. Кон
кретные значения номеров типов подзаписей определяются логикой самого сервиса. Протокол указывает лишь то,
что этот номер должен присутствовать, а нулевой идентификатор зарезервирован;
SRL (Subrecord Length) — длина данных в байтах подзаписи в поле SRD:
SRD (Subrecord Data) — данные подзаписи. Наполнение данного поля специфично для каедого сочетания
идентификатора типа сервиса и типа подзаписи.
На каждую информационную запись уровня поддержки услугдолжно быть отправлено подтверждение, кото
рое содержит подзапись с информацией об идентификаторе подтверждаемой записи и результате ее обработки.
Описание и формат подтверждения представлены в В.3.2.2, подпункт а) На рисунке В.З представлен алго
ритм работы механизма подтверждений протокола уровня поддержки услуг.
45