ПНСТ 634-2022. Предварительный национальный стандарт Российской Федерации. Интеллектуальные транспортные системы. Кооперативные интеллектуальные транспортные системы. Локальная динамическая карта

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

до 1 августа 2025 года

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «ТранснавиСофт» (ООО «ТранснавиСофт») совместно с федеральным государственным бюджетным образовательным учреждением высшего образования «Московский автомобильно-дорожный государственный технический университет (МАДИ)»

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ISO 18750:2018 «Интеллектуальные транспортные системы. Кооперативные интеллектуальные транспортные системы. Локальная динамическая карта» (ISO «Intelligent transport systems — Cooperative ITS: Local dynamic map», NEQ)

Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).

Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее, чем за 4 мес до истечения срока его действия, разработчику настоящего стандарта по адресу: 127083 Москва, ул. Мишина, д. 35, и в Федеральное агентство по техническому регулированию и метрологии по адресу: 109074 Москва, Пресненская набережная, д. 10, стр. 2.

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

Введение

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

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

Подход КИТС обеспечивает синергизм в компонентах блока станции ИТС, например за счет совместного использования инструментов связи, что повышает общую производительность и надежность, а также снижает общую стоимость. С целью защиты различных приложений ИТС КИТС реализует концепцию станции ИТС, работающей как ограниченный защищенный управляемый домен. Совместное использование данных между приложениями достигается с помощью механизмов подписки/публикации, в которых применены по меньшей мере два механизма: один из них позволяет процессам приложений станций ИТС подписываться на стандартизованные сообщения из наборов сообщений ИТС (прямая пересылка при получении таких сообщений в блок станции ИТС); другой — использует локальную динамическую карту (ЛДК) в качестве хранилища стандартизованных объектов данных. Такие объекты именуются объектами данных ЛДК (ОД ЛДК), которые предоставляют самосогласованную информацию о реальных объектах, существующих в данном географическом местоположении в течение заданного интервала времени жизни. Авторизованные процессы приложений станции ИТС могут как добавлять ОД ЛДК в ЛДК, так и извлекать ОД ЛДК из ЛДК. Извлечение ОД ЛДК может быть выполнено в запросах и посредством подписки. Подписка обеспечивает выполнение услуги автоматического уведомления о выбранных ОД ЛДК либо через определенные промежутки времени, либо по событию.

В настоящем стандарте представлен процесс использования ЛДК в КИТС, описаны функциональные возможности ЛДК и определены общие характеристики ОД ЛДК, которые могут храниться в ЛДК. Детальная информация, касающаяся отдельных аспектов практического использования ЛДК, представлена в приложениях А - Е.

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

Настоящий стандарт содержит описание функциональных возможностей локальной динамической карты (ЛДК) в контексте ограниченного защищенного управляемого домена (ОЗУД).

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

а) общие характеристики объектов данных ЛДК (ОД ЛДК), которые могут храниться в ЛДК, т.е. информация о реальных объектах, таких как транспортные средства, участки дорожных работ, участки с медленным движением, участки с особыми погодными условиями и др., для описания которых требуются, как минимум, данные о местоположении и времени;

б) функции точки доступа к услугам, обеспечивающие интерфейсы станции ИТС, для доступа к ЛДК с целью:

1. безопасного добавления, обновления и удаления доступа для процессов приложения станции ИТС,

2. безопасного доступа процессов приложения станции ИТС для чтения (запроса),

3. формирования защищенного уведомления (при подписке) к процессам подачи заявок на станции ИТС;

в) доступ к управлению ЛДК:

1. для безопасной регистрации, отмены регистрации и аннулирования процессов приложения станции ИТС в ЛДК,

2. безопасной подписки и отмены подписок процессов приложения станции ИТС;

г) процедуры в ЛДК с учетом средств поддержки контента и целостности хранилища данных;

д) механизмы поддержки нескольких ЛДК в одном блоке станции ИТС.

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

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

ГОСТ Р 7.0.64 (ИСО 8601:2004) Система стандартов по информации, библиотечному и издательскому делу. Представление дат и времени. Общие требования

ГОСТ Р 52572 Географические информационные системы. Координатная основа. Общие требования

ГОСТ Р ИСО/МЭК 8824-1 Информационная технология. Абстрактная синтаксическая нотация один (АСН.1). Спецификация основной нотации

ГОСТ Р ИСО/МЭК 8825-2 Информационная технология. Правила кодирования АСН.1. Часть 2. Спецификация правил уплотненного кодирования (PER)

ПНСТ 340 Интеллектуальные транспортные системы. Определение стандартизованного набора протоколов, параметров, метода управления обновляемым реестром данных для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций

ПНСТ 459 Интеллектуальные транспортные системы. Кооперативные системы. Глобальная уникальная идентификация

ПНСТ 461 Интеллектуальные транспортные системы. Доступ к системам связи для наземных мобильных объектов (CALM). Архитектура

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

3 Термины и определения

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

3.1

целостность данных: Данные не изменены или уничтожены несанкционированным образом. [ПНСТ 345-2018, пункт 3.44]

3.2 Международное атомное время: Время с 00:00:00 UTC, 1 января 2004 г., идентично UTC, за исключением того, что не требуется добавления дополнительных секунд.

3.3 местоположение области интереса локальной динамической карты: Местоположение, используемое в процессе фильтрации запросов и автоматических уведомлений.

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

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

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

3.7 идентификатор объекта данных локальной динамической карты: Уникальный идентификатор объекта данных локальной динамической карты.

3.8 словарь данных локальной динамической карты: Тезаурус, в котором представлены типы объектов данных локальной динамической карты.

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

3.10 действительное местоположение: Сведения относительно действительного местоположения объекта данных локальной динамической карты.

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

3.12 время интереса: Необходимое локальной динамической карте время, используемое в процессе фильтрации запросов и автоматических уведомлений.

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

3.14 ссылка на местоположение: Описание уникально идентифицируемого местоположения или области в реальном мире.

3.15

метаданные: Информация о ресурсе. [ГОСТ Р 57668-2017, пункт 4.10]

Примечание - Термин «метаданные» неоднозначен, так как он используется для принципиально разных концепций. Структурные метаданные — это информация, связанная с проектированием и спецификацией структур данных, а также упоминаемая как данные о контейнерах данных. Описательные метаданные — это информация об экземплярах данных, т.е. о содержимом данных, а также упоминаемая как данные о содержании данных.

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

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

3.18 время генерации: Время формирования содержимого информационного поля объекта данных локальной динамической карты.

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

4 Сокращения

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

• ИДОД ЛДК — идентификатор объекта данных локальной динамической карты;
• ИТС — интеллектуальные транспортные системы;
• ИУП — инфраструктура управления привилегиями;
• КИТС — кооперативные интеллектуальные транспортные системы;
• КСС — координатная ссылочная система;
• ЛДК — локальная динамическая карта;
• ОД ЛДК — объект данных ЛДК;
• СД ЛДК — словарь данных ЛДК;
• ОЗУД — ограниченный защищенный управляемый домен;
• ОЗУО — ограниченный защищенный управляемый объект;
• ТС — транспортное средство;
• DAB — цифровое аудиовещание (Digital audio broadcasting);
• DATEX II — Европейский стандарт обмена данными между участниками дорожного движения (Data Exchange);
• DENM — распределенное сообщение с уведомлением об окружающей среде (Distributed environmental notification message);
• DVB — цифровое видеовещание (Digital video broadcasting);
• IAT — международное атомное время (International atomic time);
• ICS — заявление о соответствии реализации (Implementation conformity statement);
• IUT — идентификация тестируемой реализации (Implementation under test);
• OoT — обязательства доверия (Obligation of trust);
• RDS — система обмена сообщениями по радио на УКВ-частотах (Radio Data System);
• SAO — подписано принятие обязательств (Signed acceptance of obligations);
• SAP — точка доступа к сервису (Service access point);
• SUT — тестируемая система (System under test);
• TMC — канал сообщений о дорожном движении (Traffic Message Channel);
• TPEG — группа экспертов по транспортному протоколу (Transport protocol expert group);
• UTC — Всемирное координированное время (Universal time coordinated).

5 Архитектурная среда

Этот раздел содержит информацию об архитектурной среде ЛДК.

5.1 Локальная динамическая карта

Локальная динамическая карта (ЛДК) — это сущность, состоящая из ОД ЛДК, сервисов и интерфейсов для управления этими ОД ЛДК, которые различают по типу ОД ЛДК, определяемому путем регистрации в СД ЛДК.

Примечание - ОД ЛДК классифицируют следующим образом:

• тип 1 — статические постоянные объекты данных, например картографические данные;
• тип 2 — статические переходные данные, например временная стоянка на дороге;
• тип 3 — динамические временные объекты данных, например местоположение работ;
• тип 4 — динамические объекты данных, например местоположение, ориентация и скорость окружающих транспортных средств.

Эта классификация не применена в настоящем стандарте. ОД ЛДК предоставляет информацию о тех реальных объектах (автомобилях, дорожных событиях и т.д.), которые существуют в определенном месте, например в конкретной географической области и в течение указанного промежутка времени. В наиболее простом случае информация, предоставляемая об ОД ЛДК, — это тип, его географическое местоположение и временной интервал действия. Данная информация может быть принята в модуле станции ИТС по разным каналам, таким как:

• DATEX II, TPEG, RDS, TMC (унаследованные системы);
• наборы сообщений CEN/ETSI/ISO/SAE ITS EN, которые составлены из разных наборов атрибутов и представлены в различных форматах (кодировках).

Прикладные процессы станций ИТС, способные воспринимать эту информацию, выполняют отображение на ОД ЛДК и перевод форматов атрибутов.

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

5.2 Локальная динамическая карта в интеллектуальной телематической системе станции

Спецификация ЛДК, представленная в настоящем стандарте, предназначена для архитектурной среды станции ИТС, работающей как ОЗУД, описанный в ПНСТ 461 и схематично представленный на рисунке 1.

Функциональные возможности ЛДК, указанные в разделе 6, реализованы на уровне средств станции ИТС. ЛДК взаимодействует с прикладными процессами станции ИТС, описанными ПНСТ 461. Вспомогательные функции ЛДК описаны в 6.6.2 с помощью функций сервисов FA-SAP и MF-SAP; обе точки доступа к сервису (SAP) предлагают идентичные функции.

5.3 Локальная динамическая карта в модуле станции интеллектуальной телематической системы

Различные примеры поддерживаемых конфигураций реализации проиллюстрированы на рисунках 2 - 5. На рисунке 2 показана конфигурация одного модуля станции ИТС с одной ЛДК.

Рисунок 2 — Реализация конфигурации одного модуля станции ИТС с одной ЛДК

На рисунке 4 показана конфигурация модуля станции ИТС с двумя модулями связи ИТС. Один из этих модулей связи выполняет роль хоста, описанную в ПНСТ 461, и содержит одну ЛДК. Другой модуль исполняет роль маршрутизатора и не содержит ЛДК (см. ПНСТ 461).

Рисунок 5 — Реализация конфигурации модуля станции ИТС с двумя блоками связи

5.4 Процессы, связанные с локальной динамической картой

5.4.1 Синхронизация локальной динамической карты

Концепция синхронизации ЛДК выделяет синхронизацию ЛДК, работающих в станциях ИТС различных ТС:

• модулях станции ИТС придорожной инфраструктуры, в центральных офисах и в ТС.

Ссылка делается на те средства, которые использованы для TPEG и DATEX. Такая синхронизация означает обновление ЛДК авторизованной ведущей ЛДК.

5.4.2 Архивация объектов данных локальной динамической карты

5.5 Локальная динамическая карта для дорожной безопасности и приложений «автомобиль-автомобиль»

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

5.6 Обеспечение информационной безопасности локальной динамической карты

5.6.1 Авторизованный доступ к локальной динамической карте

Архитектура ЛДК в контексте ОЗУД с точки зрения безопасности ограничивает доступ к ЛДК с помощью идентифицированных и авторизованных процессов приложений ИТС. Прикладные процессы, не сертифицированные для работы в ОЗУД, могут получить доступ к ЛДК через защищенный шлюз, описанный в ПНСТ 461, где брандмауэр станции ИТС этого шлюза авторизован для доступа на чтение к ЛДК. Основные активы следует рассматривать как уязвимые, и поэтому они подлежат защите, которая принимает форму конкретных механизмов защиты. Защитный механизм, используемый для защиты ЛДК, представляет собой схему управления доступом на основе политики, в которой процессы подачи заявок станции ИТС предварительно регистрируют свою политику в станции ИТС, и если эта политика согласована, то будущий доступ процесса подачи заявок станции ИТС будет проверен на предмет соответствия политике.

5.6.2 Инициализация и установка приложений для ограниченного защищенного управляемого домена

Ядро модуля станции ИТС образует доверительный центр ОЗУО и идентифицируется для процессов применения станции ИТС третьей стороной. Любой прикладной процесс станции ИТС, который должен быть добавлен к модулю станции ИТС в ОЗУО, проверяет идентичность и дееспособность модуля станции ИТС перед установкой. Если инсталляция прикладного процесса допускается, модуль станции ИТС проверяет полномочия, предоставленные станцией ИТС прикладному процессу. Перед загрузкой функции каждого прикладного процесса станции ИТС проверяют и тестируют, а требуемую функциональность, идентичность разработчика и испытателя проверяют перед установкой в соответствии с ПНСТ 459.

Основная модель соответствует требованиям, разработанным как расширение протокола обязательства доверия (ОоТ), который развивает модели, применяемые для распространения приложений для мобильных устройств на языке Java, используемые во многих общих библиотеках приложений ПНСТ 459. Структура защиты представляет собой форму инфраструктуры управления привилегиями (PMI), основанной на общих криптографических модулях и обработке, где авторизация рассмотрена как совокупность взаимно согласованных действий путем назначения разрешений сторонам, т.е. ЛДК и пользователю ЛДК. В протоколе обязательства доверия участвующие стороны обмениваются трудно поддающимися проверке обязательными ограничениями с цифровой подписью, также именуемыми уведомления об обязательствах, в которых подробно изложены требования для отправки их конфиденциальной информации другой стороне, и доказательствами принятия, также именуемыми подписью принятия обязательств (SAO), в которых учтены условия одной стороны для получения конфиденциальной информации другой стороны. Необходимые возможности пользователя ЛДК, т.е. возможности прикладного процесса станции ИТС, подлежащего установке, будут объявлены, и прикладной процесс будет ограничен в использовании только этих возможностей с помощью механизма политики принуждения в ЛДК.

Для защиты данных объекты данных, указанные ниже, используют основные элементы политики: PrivacyPolicyDirective и CounterSignedSecurityPolicy.

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

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

Разрешения, вытекающие из политики, имеют типы «разрешить» и «запретить» на основе авторизации. После применения политики конфиденциальности запрос будет либо разрешен, либо отклонен. Примерами запросов доступа являются чтение данных из ЛДК и запись данных в ЛДК.

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

5.6.3 Конфиденциальность

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

5.7 Совместное использование данных в модуле станции интеллектуальной телематической системы

Совместное использование данных между прикладными процессами станции ИТС в модуле станции ИТС может быть достигнуто с помощью механизмов подписки/публикации, при этом различают как минимум два механизма:

а) механизм, позволяющий приложению станции ИТС обрабатывать подписку на уровне средств станции ИТС на стандартизованные сообщения из наборов сообщений ИТС без использования ЛДК;

б) механизм с использованием ЛДК в качестве хранилища стандартизованных объектов данных.

Механизм по перечислению а) стандартизирует обработчик сообщений на уровне объекта станции ИТС, который может:

• напрямую пересылать полные полученные сообщения подписанным процессам приложения станции ИТС без сохранения этих сообщений;
• представлять ОД ЛДК в ЛДК в том случае, если эти объекты данных содержатся в тех сообщениях, которые следуют соглашению о формате их сообщений. Могут быть и другие хранилища данных, которые в основном отличаются от ЛДК, т.е. могут хранить объекты данных, которые не соответствуют определениям ОД ЛДК.

6 Функциональность локальной динамической карты

Данный раздел содержит информативное описание функциональных возможностей ЛДК.

6.1 Термины и соглашения

Согласно 5.1 ЛДК оперирует с информацией о реальных объектах, которые существуют в определенном месте (географической области) и в течение определенного интервала времени. Такая информация о реальном объекте идентифицируется в записи данных ЛДК (см. рисунок 7). Каждая запись данных ЛДК идентифицируется уникальным идентификатором записи данных ЛДК; нулевое значение указывает на «неизвестную запись».

6.1.1 Для установления функциональных возможностей ЛДК используют различные определения местоположения и времени:

а) относящиеся к информации о реальном объекте:

1. информация о достоверности местоположения.

Информация о том, в каком географическом местоположении или в какой географической зоне применяют ОД ЛДК,

2. информация о достоверности времени.

Информация о том, в течение какого интервала времени применяется ОД ЛДК,

3. время генерации.

Информация о времени генерации информации ОД ЛДК, например время, когда система восприятия информации (например, датчик) обнаружила событие «скользкая дорога»,

4) время обязательного удаления.

Информация о времени, по истечении которого запись ЛДК не будет возвращаться в запросе;

б) используемые в запросах:

1. область интересов ЛДК.

Географическая локация (и) или географические области, которые необходимы для запрашивающего процесс приложения станции ИТС,

2. время интереса ЛДК.

Момент времени или интервал(ы) времени, которые необходимы для запрашивающего процесса приложения станции ИТС,

3. возраст интереса.

Возраст записи ЛДК — в соответствии с требованиями запрашивающего прикладного процесса станции ИТС. Возраст вычисляют с помощью числового оператора, представленного процессом приложения станции ИТС, по отношению ко времени генерации ОД ЛДК, если оно доступно, или альтернативно ко времени последнего обновления ОД ЛДК;

в) используемые для целей обслуживания:

1. область обслуживания ЛДК.

Географическая(ие) область(и), рассматриваемая(ые) функциональными средствами поиска ЛДК и определяемая(ые) ЛДК в зависимости от реализации.

Для выполнения запроса необходимо, чтобы области интересов ЛДК перекрывались с областью обслуживания.

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

2. неактивная область ЛДК.

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

3. время создания.

Момент времени, в котором запись ЛДК создана в хранилище данных ЛДК,

4) время удаления.

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

Определено несколько систем отсчета местоположения и систем отсчета времени. Примеры представлены в приложениях Г и Д.

Настоящий стандарт поддерживает любой тип системы отсчета, определяя эталон времени и ссылку на местоположение, используя ASN.1, тип CLASS, который позволяет указать конкретные экземпляры в соответствии с потребностями служб КИТС.

Общий подход к определению местоположения приведен в ASN.1, тип LDMarea, согласно ГОСТ Р ИСО/МЭК 8825-2, а к определению времени — в ASN.1, тип TimeInformation.

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

6.1.2 Так как в настоящем стандарте представлены различные архитектуры реализации, проиллюстрированные в 5.3, в ходе проведения прикладных процессов станции ИТС должна быть возможность выбора соответствующих ЛДК. Для осуществления этой цели:

а) ЛДК имеет идентификатор ЛДК, который уникален в модуле станции ИТС;

б) ЛДК регистрируют в модуле управления станции ИТС, сообщая о возможностях с точки зрения поддерживаемых ОД ЛДК;

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

ЛДК выполняет следующие процедуры для поддержания целостности хранилища данных ЛДК:

• удаление записей данных ЛДК, которые устарели;
• удаление записей данных ЛДК, которые находятся вне зоны обслуживания ЛДК.

Предполагается, что дальнейшая проверка целостности будет выполнена прикладными процессами станции ИТС.

6.2 Структура локальной динамической карты

Функциональные блоки ЛДК представлены на рисунке 6.

Рисунок 6 — Структура локальной динамической карты

Ниже представлено краткое описание основных элементов структуры ЛДК:

а) хранилище данных ЛДК. Это структурный объект ЛДК, который хранит ОД ЛДК, как описано в 6.3;

б) сервис ЛДК. Этот функциональный блок предоставляет средства:

1. для управления запросами на регистрацию, отмену регистрации и отзыв процессов приложений станции ИТС,

2. проверки безопасности в запросах доступа,

3. управления запросами на доступ (добавление, обновление, удаление, подписка, запрос, уведомление) от процессов приложений станции ИТС, как описано в 6.4;

в) обслуживание ЛДК. Этот функциональный блок предоставляет средства:

1. для обновления области обслуживания ЛДК,

2. удаления записей данных ЛДК, как описано в 6.5;

г) база знаний ЛДК, предоставляющая знания, необходимые ЛДК для внутренней обработки данных, как описано в 6.6. Этот функциональный блок включает в себя следующую информацию и средства:

1. метаданные,

2. словарь данных ЛДК,

3. информация о регистрациях и подписках процессов приложений станции ИТС на ЛДК,

4. утилиты ЛДК;

д) интерфейсы:

1. интерфейсы, используемые и предлагаемые ЛДК:

• интерфейс данных для прикладных процессов станции ИТС, обеспечивающий решение следующих задач:
• добавление, обновление и удаление информации доступа,
• обработка запроса доступа,
• обработка запроса на подписной доступ,
• формирование уведомлений при подписке;

2. интерфейсы управления и безопасности, обеспечивающие решение следующих задач:

• регистрация, отмена регистрации, отзыв приложений станции ИТС,
• проверка прав доступа, заявленных приложениями станции ИТС при регистрации,
• управление ЛДК (например, регистрация ЛДК в модуле управления станции ИТС), как описано в 6.6.2;

е) управление ЛДК. Этот функциональный блок предоставляет средства для регистрации ЛДК в станции ИТС.

6.3 Хранилище данных локальной динамической карты

Хранилище данных ЛДК логически содержит записи данных ЛДК, представленные на рисунке 7.

Рисунок 7 — Структура записи в хранилище данных ЛДК

1. тип ОД ЛДК,

2. действительное местоположение реального объекта,

3. срок действия реального объекта,

4. время генерации информации, содержащейся в ОД ЛДК (устанавливается на ноль в том случае, если время генерации не указано),

5. время обязательного удаления записи данных ЛДК.

Примечания

1. Обновление записи данных ЛДК может быть обеспечено только таким же процессом приложения станции ИТС, который первоначально генерировал запись данных ЛДК.

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

б) атрибуты ОД ЛДК, как указано в словаре данных ЛДК:

1. параметры обслуживания ЛДК, которые не могут быть явно заданы прикладным процессом станции ИТС и которые не могут быть получены прикладным процессом станции ИТС:

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

В таблице 1 пояснены и определены элементы записи данных ЛДК, приведенных на рисунке 7. Они относятся к определению типа ASN.1, указанному в приложении А.

Таблица 1

Элементы записи данных локальной динамической карты

Элемент	Спецификация и пояснения
Идентификатор записи ЛДК	Этот элемент уникально идентифицирует конкретную запись в ЛДК. Формат данного элемента задан элементом ASN.1 LDMrecordID, описанным в приложении А
Тип ОД ЛДК	Этот элемент однозначно определяет тип ОД ЛДК. Формат данного элемента задан элементом ASN.1 LDMdataObjectTypeID, описанным в приложении А
Срок действия местоположения	Этот элемент однозначно определяет положение или область, в которых применяется информация, предоставленная ОД ЛДК. В интерфейсных функциях разрешено несколько функций привязки местоположения. Данный элемент состоит из двух частей, одна из которых содержит значения исходной системы отсчета, а другая — систему отчета, применяемую в ЛДК
Срок действия	Этот элемент однозначно определяет период времени, в течение которого применяется информация, предоставленная ОД ЛДК. В функциях интерфейса допускается несколько форматов времени для представления периода времени. Таким образом, данный элемент состоит из двух частей, одна из которых содержит значения исходной системы отсчета, а другая — систему отчета, применяемую в ЛДК. Формат отсчета времени задан в элементе ASN.1 TimeInformation, описанном в приложении А
Время генерации	Этот элемент однозначно определяет время, когда были сгенерированы данные, содержащиеся в ОД ЛДК. Данное время отличается от того времени, когда данные были загружены в ЛДК. Формат отсчета времени задан в элементе ASN.1 TimeGeneration, описанном в приложении А
Время обязательного удаления	Данный элемент используется для указания времени, до которого запись данных может поддерживаться в ЛДК. По истечении этого времени запись данных должна быть удалена из ЛДК. Это позволяет приложениям станции ИТС запрашивать своевременное удаление записей данных ЛДК, например из-за правила конфиденциальности или политики конфиденциальности. Формат этого элемента задан элементом ASN.1 TimeOfDeletion, указанным в приложении А
Объект данных ЛДК	Этот элемент является экземпляром типа данных ЛДК, как указано в ОД ЛДК. Формат данных элемента задан элементом ASN.1 ElementDataObject, указанным в приложении А
Идентификатор прикладного процесса станции ИТС	Этот идентификатор экземпляра процесса приложения станции ИТС, указанного в таблице 2, который представил ОД ЛДК для ЛДК. Формат данного элемента задан элементом ASN.1 ITSsapiid, указанным в приложении А
Время создания	Этот элемент определяет два временных события, т.е. то время, когда запись данных добавлена в ЛДК, и то время, когда существующая запись обновлена. Формат данного элемента задан элементом ASN.1 TimeOfCreation, указанным в приложении А
Время удаления	Время удаления записи данных из ЛДК совпадает со временем обязательного удаления, если оно установлено прикладным процессом станции ИТС или может быть получено из элемента Time Validity. Эта информация о времени указывает время, с которого запись данных ЛДК больше не будет раскрываться процессам приложения станции ИТС и может быть заархивирована и удалена. Формат данного элемента задан элементом ASN.1 TimeOfDelition, указанным в приложении А
Флаг конфиденциальности	Этот элемент является логическим флагом, указывающим при значении true, что запись данных ЛДК должна быть удалена после того, как пройдет время удаления. Флаг конфиденциальности может быть установлен разными способами. Если время обязательного удаления представлено с допустимым значением, для флага конфиденциальности устанавливают значение true. Значением по умолчанию является false. Формат этого элемента задан элементом ASN.1 PrivacyFlag, указанным в приложении А

6.4 Сервисы локальной динамической карты

6.4.1 Регистрация, отмена регистрации и отзыв прикладных процессов станции ИТС

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

6.4.2 Проверка безопасности в запросах доступа

Каждый запрос доступа к ЛДК (см. 6.4.3) связан с набором утверждений, которые проверяются на соответствие локальной политике конфиденциальности в ЛДК. Если какая-либо попытка доступа к данным из приложения выполняется после регистрации и после принятия политики, которая не соответствует политике конфиденциальности, она отклоняется. Нормативная спецификация соответствующей процедуры представлена в 7.1.2.

6.4.3 Управление запросами доступа

6.4.3.1 Обзор управления запросами включает в себя:

• подписку (см. 6.4.3.6) и отмену подписки (см. 6.4.3.7) на обновления ОД ЛДК;
• уведомление об обновлениях ОД ЛДК (см. 6.4.3.8).

В запросах и в подписках в рамках управления запросами применяют их фильтрацию.

Прикладные процессы станции ИТС представляют свойства, по которым выполняются запросы и подписки. При фильтрации первого уровня использованы следующие параметры, представленные на рисунке 7:

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

Процесс фильтрации второго уровня выбирает те предварительно отфильтрованные ОД ЛДК с теми значениями атрибутов, которые удовлетворяют запрошенным условиям (см. 6.4.3.9).

Примечание - Для некоторых приложений, например во избежание столкновения, необходимо отслеживать движение реального объекта. Такие траектории могут быть созданы прикладными процессами станции ИТС на основе ОД ЛДК, связанных с этим реальным объектом.

6.4.3.2 Добавление записи данных ЛДК

После регистрации в ЛДК (см. 6.4.1) процесс приложения станции ИТС может запросить добавление записи данных в ЛДК, используя интерфейсную функцию ASN.1, тип LDMaddRequest, указанную в 6.7.4.1. Если процессу приложения станции ИТС разрешено добавить ОД ЛДК определенного типа ОД ЛДК, запрос удовлетворяется и создается запись данных ЛДК. Этот запрос подтверждается интерфейсной функцией ASN.1, тип LDMaddConfirm, указанной в 6.7.4.1, возвращающей идентификатор записи ЛДК ASN.1, тип LDMrecordID. Нормативная спецификация соответствующей процедуры представлена в 7.1.3.1.

6.4.3.3 Обновление записи данных ЛДК

Процесс приложения станции ИТС, который запросил добавление записи данных в ЛДК (см. 6.4.3.2), может впоследствии обновить запись данных ЛДК, идентифицированную идентификатором записи ЛДК, используя функцию интерфейса ASN.1, тип LDMupdateRequest, указанного в 6.7.4.2. Этот запрос подтверждается интерфейсной функцией ASN.1, тип LDMupdateConfirm (см. 6.7.4.2). Нормативная спецификация соответствующей процедуры представлена в 7.1.3.3.

6.4.3.4 Удаление записи данных ЛДК

Прикладной процесс станции ИТС, который запросил добавление записи данных в ЛДК (см. 6.4.3.2), может впоследствии удалить запись данных ЛДК, идентифицированную идентификатором записи ЛДК, используя функцию интерфейса ASN.1, тип LDMdeleteRequest (см. 6.7.4.3). Этот запрос подтверждается интерфейсной функцией ASN.1, тип LDMdeleteConfirm (см. 6.7.4.3). Нормативная спецификация соответствующей процедуры представлена в 7.1.3.4.

6.4.3.5 Запрос ОД ЛДК

При регистрации в ЛДК (см. 6.4.1) процесс приложения станции ИТС может запросить извлечение ОД ЛДК из ЛДК, используя функцию интерфейса ASN.1, тип LDMqueryRequest (см. 6.7.4.6). Если процессу приложения станции ИТС разрешено запрашивать ОД ЛДК конкретного типа ОД ЛДК, запрос удовлетворяется и ОД ЛДК запрашиваемого типа ОД ЛДК извлекаются с помощью функции интерфейса ASN.1, тип LDMqueryConfirm (см. 6.7.4.6), с учетом параметров фильтра, представленных в запросе. Нормативная спецификация соответствующей процедуры представлена в 7.1.3.5.

6.4.3.6 Подписка на обновления ОД ЛДК

После регистрации в ЛДК (см. 6.4.1) процесс приложения станции ИТС может запросить подписку на обновления ОД ЛДК от ЛДК, используя функцию интерфейса ASN.1, тип LDMsubscribeRequest (см. 6.7.4.6). Если процессу приложения станции ИТС разрешено подписываться на автоматические уведомления об обновлениях ОД ЛДК конкретного типа ОД ЛДК, запрос удовлетворяется и подтверждается с помощью функции интерфейса ASN.1, тип LDMsubscribeConfirm (см. 6.7.4.5). После обновлений ОД ЛДК, подлежащих подписке, эти обновления будут автоматически уведомляться в процессе подачи заявки на станции ИТС. Нормативная спецификация соответствующей процедуры представлена в 7.1.3.6.

6.4.3.7 Отмена подписки на обновления ОД ЛДК

После успешной подписки на обновления ОД ЛДК процесс приложения станции ИТС может отказаться от подписки, используя функцию интерфейса ASN.1, тип LDMunsubscribeRequest, указанного в 6.7.4.5. Этот запрос подтверждается интерфейсной функцией ASN.1, тип LDMunsubscribeConfirm. Нормативная спецификация соответствующей процедуры представлена в 7.1.3.7.

6.4.3.8 Уведомление об обновлениях ОД ЛДК

После успешной подписки на обновления ОД ЛДК (см. 6.4.3.6) процесс приложения станции ИТС будет уведомлен об обновлениях ОД ЛДК с помощью функции интерфейса указанного ASN.1, тип LDMnotifyRequest (см. 6.7.4.7). Это уведомление не подтверждается процессом подачи заявления станции ИТС. Нормативная спецификация соответствующей процедуры представлена в 7.1.3.8.

6.4.3.9 Фильтрация второго уровня

Фильтрацию второго уровня применяют к значениям атрибутов ОД ЛДК, возникающих в результате фильтрации первого уровня, выполняемой в запросах и уведомлениях об обновлениях (см. 6.4.3.5 и 6.4.3.8). Набор возвращаемых данных из фильтрации первого уровня дополнительно уменьшается только для тех ОД ЛДК, которые соответствуют фильтрации атрибутов второго уровня. Отфильтрованный результат будет возвращен в интерфейсных функциях ASN.1, типы LDMqueryConfirm и LDMnotifyRequest, указанных в 6.7.4.6 и 6.7.4.7 соответственно. Фильтрация второго уровня представляет собой логическую комбинацию одного или нескольких операторов фильтрации. Оператор фильтрации — это оператор сравнения, в котором атрибут из ОД ЛДК проверяют по контрольному значению. Тест определяется оператором сравнения. Ссылочное значение является абсолютным значением типа данных атрибута. Оператор фильтрации логически оценивается как истина или ложь, т.е. оператор фильтрации равен true, если атрибут ОД ЛДК соответствует тесту, и false, если он не проходит тест.

Составной оператор фильтрации — это логическая операция над двумя операторами фильтрации. Логический оператор — это оператор И или ИЛИ. Составной оператор также логически оценивается как true или false. Более сложные выражения фильтра могут быть созданы и представлены в параметре фильтра ASN.1, тип FilterSecondLevel. Параметр фильтра ASN.1, тип FilterSecondLevel позволяет указать последовательность логических операций, которые объединяются с логическим И (последовательность ASN.1 типа AND), где каждая из этих логических операций представляет собой последовательность основных логических операций, которые объединяются с логическим ИЛИ (последовательность OR типа ASN.1). Базовая логическая операция (ASN.1, тип FilterPrimitive) позволяет представить:

• уникальный идентификатор атрибута данного типа ОД ЛДК;
• числовую операцию (АСН.1, тип Operators);
• эталонное значение, указанное как Octet String, для преобразования в соответствующий формат.

Нормативная спецификация соответствующей процедуры представлена в 7.1.4.

6.5 Обслуживание локальной динамической карты

6.5.1 Область обслуживания ЛДК

Управление областью поддерживает соответствующие значения области обслуживания ЛДК.

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

Примечание — Область интересов ЛДК описана в запросе станции ИТС (см. также 6.1). Нормативная спецификация соответствующей процедуры представлена в 7.2.1.

6.5.2 Обработка устаревших данных

Сервис удаления устаревших данных отвечает за удаление информации из ЛДК, которая больше не является действительной и подлежит удалению. Решение об удалении записи данных ЛДК не требует проверки ОД ЛДК. Нормативная спецификация соответствующей процедуры представлена в 7.2.2.

6.6 База знаний локальной динамической карты

6.6.1 Метаданные

Метаданные — это либо данные о структуре других данных, либо о содержании данных, например:

• форматы местоположения;
• форматы времени;
• дополнительные форматы информации;
• словарь данных ЛДК;
• реестр процесса подачи заявления станции ИТС;
• обслуживание ЛДК.

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

Примечание - Метаданные могут быть обновлены с использованием удаленного управления станцией ИТС.

6.6.2 Вспомогательные функции

Вспомогательные функции ЛДК выполняют внутреннюю обработку, включая:

а) функции управления идентификатором записи данных ЛДК: создание и удаление значений, обеспечивающих уникальность;

б) функции пространственной привязки:

1. перевод в методе, используемом в ЛДК,

2. перевод в методе, запрашиваемом в запросе;

в) функции ссылки на время:

1. перевод в методе, используемом в ЛДК,

2. трансляция в методе, запрашиваемом в запросе;

г) функция регистрации ЛДК в модуле управления станции ИТС;

д) функция управления обновлениями ЛДК (например, обновление встроенного программного обеспечения, обновление словаря данных ЛДК).

6.7 Интерфейсы

6.7.1 Типы интерфейсов

ЛДК доступна через интерфейсы, показанные на рисунке 6. Различают четыре типа интерфейсов, применимых для ЛДК:

а) интерфейс управления приложениями ЛДК, описанный в 6.7.3, позволяющий процессу приложения станции ИТС:

• изначально регистрироваться в ЛДК и отменять регистрацию из ЛДК;

б) интерфейс данных ЛДК, описанный в 6.7.4, позволяющий:

1. процессу приложения станции ИТС:

• добавлять, обновлять и удалять запись данных в ЛДК,
• запрашивать ОД ЛДК из ЛДК,
• подписываться на ЛДК для автоматического предоставления ОД ЛДК этой ЛДК,

2. ЛДК выполнять уведомления ОД ЛДК прикладного процесса станции ИТС;

в) интерфейс безопасности, описанный в 6.7.5, позволяющий выполнять услуги безопасности путем уведомления:

1. об отзыве авторизации прикладных процессов станции ИТС,

2. аннулировании авторизации процессов приложений станции ИТС;

г) интерфейс управления, описанный в 6.7.6, позволяющий:

1. ЛДК зарегистрироваться в модуле управления станции ИТС и представлять свои услуги в терминах поддерживаемых типов ОД ЛДК,

2. ЛДК пользоваться услугами модуля управления станции ИТС.

6.7.2 Параметры функций интерфейса

Параметры функций интерфейса представлены и описаны в таблице 2. Подробная информация в отношении ASN.1 приведена в приложении А.

Таблица 2

Параметры интерфейсных функций

Наименование	Тип ASN.1	Описание
1 Age of Interest	AgeOfInterest	Требуемый возраст ОД ЛДК. Используют в запросах для фильтрации времени генерации (см. 6.1.2)
2 ITS-S application process instance identifier	ITSsapiid	Уникальная идентификация экземпляра прикладного процесса станции ИТС для данной ИТС
3 LDM Area of Interest AreaOfInterest
Используется в запросах и в подписках для фильтрации допустимости местоположения (см. 6.1.4)	4 LDM capabilities	LDMcapabilities
Используют во время регистрации ЛДК при управлении станцией ИТС (см. 6.7.6.1)	5 LDM data	LDMinterfaceRecords
Информация, возвращаемая в приложение станции ИТС по запросу или в уведомлении о подписке	6 LDM Data Object	LDMdataObject
Информация, представленная процессом приложения станции ИТС, для хранения в записи данных ЛДК	7 LDM ID	LDMid
Уникальный идентификатор ЛДК в модуле станции ИТС. Нулевое значение указывает на неизвестную ЛДК	8 LDM Permissions	LDMpermissionList
Информация о том, как процессу приложения станции ИТС разрешается использовать ЛДК. Используется процессом приложения станции ИТС для регистрации в ЛДК и процессом отзыва для указания оставшихся разрешений. Детали, по которым типы ОД ЛДК могут быть доступны, должны быть определены регистрирующим органом	9 ID record	LDMrecordID
Идентификатор записи, который является уникальным в ЛДК. Нулевое значение указывает на несуществующую/неизвестную запись данных ЛДК	10 Time of Generation	TimeOfGeneration
Время создания информации, содержащейся в записи данных ЛДК (см. 6.1)	11 LDM Time of Interest	TimeOfInterest
Момент времени или интервал(ы) времени, которые представляют интерес для процесса запроса станции ИТС	12 LDM-DT ID	LDMdataObjectTypeID
Идентификатор типа данных ЛДК. Используют в запросах	13 List of supported LDMDTs	ListOfLDMDTids
Информация о типах данных ЛДК содержится в локальном словаре данных ЛДК. Используют во время регистрации ЛДК при управлении станции ИТС (см. 6.7.6.1)	14 Location Validity	LocationValidity
Информация о географическом местоположении или о географическом районе применения ОД ЛДК, предоставленная приложением станции ИТС (см. 6.1)	15 Notification interval	NotificationInterval
Интервал времени между последующими уведомлениями при подписке. Если значение установлено равным нулю, уведомление применимо только после обновления. В противном случае уведомление о периоде выполняется без учета настройки уведомления при обновлении	16 Notification upon update	NotificationUponUpdate
Флаг, фиксирующий выполнение уведомления при обновлении или его отсутствие. Если интервал уведомления установлен на ноль, то уведомление об обновлении имеет значение true	17 Priority	UserPriority
Указывает приоритет обработки запроса от процесса приложения станции ИТС ЛДК. Максимально допустимое значение присваивается регистром процессу приложения станции ИТС и предоставляется ЛДК во время регистрации в ЛДК	18 Reason for revocation	RevocationReason
Указывает причины, по которым разрешения и приоритет были отозваны или изменены	19 Result code	ResultCode
Указывает код результата запроса	20 Second level filtering	FilterSecondLevel
Информация о том, как фильтровать значения атрибутов ОД ЛДК	21 Security credentials	LDMsecurityCredential
Используется для проверки разрешений ЛДК, заявленных прикладным процессом станции ИТС	22 Subscription ID	SubscriptionID
Идентификатор подписки, уникальный в ЛДК	23 Time of Mandatory Deletion	TimeOfMandatoryDeletion
Информация о времени, требующая удаления записи данных ЛДК (см. 6.1)	24 Time Validity	ValidityTimeInterval
Информация о том, в каком временном интервале может быть применен ОД ЛДК (см. 6.1)		6.7.3 Интерфейс управления приложениями локальной динамической карты

6.7.3.1 Функция «Регистрация прикладного процесса станции ИТС»

Функция «Регистрация прикладного процесса станции ИТС» с возможностями ASN.1, указанными в приложении А, позволяет прикладному процессу станции ИТС регистрироваться в ЛДК для последующего доступа.

Данная функция состоит:

а) из части запроса ASN.1, тип LDMregisterRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор ЛДК — тип ASN.1 LDMid,

3. применимый максимальный приоритет — ASN.1, тип UserPriority,

4. список разрешений — ASN.1, тип LDMpermissionList,

5. учетные данные безопасности для проверки заявленных разрешений — ASN.1, тип LDMsecurityCredential;

б) часть подтверждения ASN.1, тип LDMregisterConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор отвечающей ЛДК — ASN.1, тип LDMid,

3. список подтвержденных разрешений — ASN.1, тип LDMpermissionList,

4. код результата — ASN.1, тип ResultCode.

6.7.3.2 Функция «Отмена регистрации прикладного процесса станции ИТС»

Функция «Отмена регистрации прикладного процесса станции ИТС» с особенностями ASN.1, указанными в приложении А, позволяет прикладному процессу станции ИТС отменять регистрацию из ЛДК, в которой она ранее зарегистрирована. Данная функция состоит:

а) из части запроса ASN.1, тип LDMderegisterRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса ИТС-С — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid;

б) часть подтверждения ASN.1, тип LDMderegisterConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. код результата — ASN.1, тип ResultCode.

Прикладной процесс станции ИТС может отменить регистрацию в ЛДК с помощью функции отмены регистрации.

6.7.3.3 Функция «Отмена уведомления прикладного процесса станции ИТС»

Функция «Отмена уведомления прикладного процесса станции ИТС» с особенностями ASN.1, указанными в приложении А, позволяет ЛДК полностью или частично отозвать ранее принятую регистрацию прикладного процесса станции ИТС. Данная функция состоит:

а) из части запроса ASN.1, тип LDMrevokeAppNotifyRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. применяемый максимальный приоритет — ASN.1, тип UserPriority,

4. список применимых разрешений — ASN.1, тип LDMpermissionList,

5. причина отзыва — ASN.1, тип RevocationReason;

б) части подтверждения ASN.1, тип LDMrevokeAppNotifyConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. код результата — ASN.1, тип ResultCode.

Если применяемые разрешения отсутствуют, это означает отмену регистрации процесса подачи заявок на станции ИТС.

6.7.4 Интерфейс данных ЛДК

6.7.4.1 Функция «Добавление записи данных ЛДК»

Функция «Добавление записи данных ЛДК» с подробностями ASN.1, указанными в приложении А, позволяет зарегистрированному прикладному процессу станции ИТС с соответствующими разрешениями представлять ОД ЛДК для записи в хранилище данных ЛДК. Данная функция состоит:

а) из части запроса ASN.1, тип LDMaddRequest с нижеперечисленными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. записываемые данные ЛДК — ASN.1, тип LDMdataObject,

4. действительность местоположения — ASN.1, тип LocationValidity,

5. срок действия — ASN.1, тип ValidityTimeInterval,

6. время генерации — ASN.1, тип TimeOfGeneration,

7. время обязательного удаления — ASN.1, тип TimeOfMandatoryDeletion;

б) части подтверждения ASN.1, тип LDMaddConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор записи данных ЛДК — ASN.1, тип LDMrecordID,

4. код результата — ASN.1, тип ResultCode.

6.7.4.2 Функция «Обновление записи данных ЛДК»

Функция «Обновление записи данных ЛДК» с указанием подробностей ASN.1 в приложении А позволяет зарегистрированному прикладному процессу станции ИТС с соответствующими разрешениями обновить запись данных ЛДК, которую она ранее записала в хранилище данных ЛДК. Данная функция состоит:

а) из части запроса ASN.1, тип LDMupdateRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор обновляемой записи данных ЛДК — ASN.1, тип LDMrecordID,

4. записываемые данные ЛДК — ASN.1, тип LDMdataObject,

5. действительное местоположение — ASN.1, тип LocationValidity,

6. срок действия — ASN.1, тип ValidityTimeInterval,

7. время генерации — ASN.1, тип TimeOfGeneration,

8. время обязательного удаления — ASN.1, тип TimeOfMandatoryDeletion;

б) части подтверждения ASN.1, тип LDMupdateConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор записи ЛДК — ASN.1, тип LDMrecordID,

4. код результата — ASN.1, тип ResultCode.

6.7.4.3 Функция «Удаление записи данных ЛДК»

Функция «Удаление записи данных ЛДК» с указанием деталей ASN.1 в приложении А позволяет зарегистрированному прикладному процессу станции ИТС с соответствующими разрешениями удалить ранее записанную или обновленную запись данных ЛДК из хранилища данных ЛДК. Данная функция состоит:

а) из части запроса ASN.1, тип LDMdeleteRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор записи ЛДК для записи данных ЛДК, подлежащей удалению, — ASN.1, тип LDMrecordID;

б) части подтверждения ASN.1, тип LDMdeleteConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор записи ЛДК — ASN.1, тип LDMrecordID,

4. код результата — ASN.1, тип ResultCode.

6.7.4.4 Функция «Подписка»

Функция «Подписка» с деталями ASN.1, указанными в приложении А, позволяет зарегистрированному прикладному процессу станции ИТС с соответствующими разрешениями на подписку на автоматические уведомления ОД ЛДК от ЛДК. Данная функция состоит:

а) из части запроса ASN.1, тип LDMsubscribeRequest с нижеприведенными параметрами:

1. идентификатор процесса приложения станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. приоритет запроса — ASN.1, тип UserPriority,

4. идентификатор записи ЛДК — ASN.1, тип LDMrecordID,

5. идентификатор типа данных ЛДК — ASN.1, тип LDMdataObjectTypeID,

6. область интересов ЛДК — ASN.1, тип AreaOfInterest,

7. время интереса ЛДК — ASN.1, тип TimeOfInterest,

8. возраст записи данных ЛДК — ASN.1, тип AgeOfInterest,

9. фильтрация второго уровня — ASN.1, тип FilterSecondLevel,

10. интервал уведомления — ASN.1, тип NotificationInterval,

11. уведомление при обновлении — ASN.1, тип NotificationUponUpdate;

б) части подтверждения ASN.1, тип LDMsubscribeConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор подписки — ASN.1, тип SubscriptionID,

4. код результата — ASN.1, тип ResultCode.

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

6.7.4.5 Функция «Отмена подписки»

Функция «Отмена подписки» с подробностями ASN.1, указанными в приложении А, позволяет зарегистрированному прикладному процессу станции ИТС с соответствующими разрешениями отписаться от ранее выполненной подписки для автоматических уведомлений ОД ЛДК от ЛДК. Данная функция состоит:

а) из части запроса ASN.1, тип LDMunsubscribeRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. приоритет запроса — ASN.1, тип UserPriority,

4. идентификатор подписки — ASN.1, тип SubscriptionID;

б) части подтверждения ASN.1, тип LDMunsubscribeConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор подписки — ASN.1, тип SubscriptionID,

4. код результата — ASN.1, тип ResultCode.

6.7.4.6 Функция «Запрос»

Функция «Запрос» с подробностями ASN.1, указанными в приложении А, позволяет прикладному процессу станции ИТС с соответствующими разрешениями запросить ОД ЛДК из ЛДК. Запрос состоит:

а) из части запроса ASN.1, тип LDMqueryRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса ИТС-С — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. приоритет запроса — ASN.1, тип UserPriority,

4. идентификатор записи ЛДК — ASN.1, тип LDMrecordID,

5. идентификатор типа данных ЛДК — ASN.1, тип LDMdataObjectTypeID,

6. область интересов ЛДК — ASN.1, тип AreaOfInterest,

7. время интереса ЛДК — ASN.1, тип TimeOfInterest,

8. возраст записи данных ЛДК — ASN.1, тип AgeOfInterest,

9. фильтрация второго уровня — ASN.1, тип FilterSecondLevel;

б) части подтверждения ASN.1, тип LDMqueryConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. последовательность данных ЛДК — ASN.1, тип LDMinterfaceRecords,

4. код результата — ASN.1, тип ResultCode.

6.7.4.7 Функция «Уведомление»

Функция «Уведомление» с подробностями ASN.1, указанными в приложении А, позволяет ЛДК уведомлять ОД ЛДК процесса приложения станции ИТС, который ранее подписался на эту услугу уведомления.

Данная функция состоит:

а) из части запроса ASN.1, тип LDMnotifyRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. идентификатор подписки — ASN.1, тип SubscriptionID,

4. последовательность данных ЛДК — ASN.1, тип LDMinterfaceRecords, подтверждение не ожидается.

6.7.5 Интерфейс безопасности

6.7.5.1 Функция «Проверка прав доступа»

Функция «Проверка прав доступа» с подробностями ASN.1, указанными в приложении А, позволяет ЛДК запрашивать точку применения политики (PEP) и точку принятия политики (PDP) (архитектурно расположенные в модуле безопасности станции ИТС) для того, чтобы проверить, правильно ли запрашиваются разрешения, заявленные процессом приложения станции ИТС во время регистрации и во время выполнения. Проверка включает в себя проверку максимально допустимого значения приоритета процесса приложения станции ИТС. Данная функция состоит:

а) из части запроса ASN.1, тип LDMcheckAuthorizationRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. приоритет запроса — ASN.1, тип UserPriority,

4. список разрешений — ASN.1, тип LDMpermission,

5. учетные данные безопасности для проверки заявленных разрешений — ASN.1, тип LDMsecurityCredential;

б) части подтверждения ASN.1, тип LDMcheckAuthorizationConfirm с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid;

2. идентификатор отвечающей ЛДК — ASN.1, тип LDMid,

3. подтвержденный максимальный приоритет — ASN.1, тип UserPriority,

4. список подтвержденных разрешений — ASN.1, тип LDMpermissionList,

5. код результата — ASN.1, тип ResultCode.

6.7.5.2 Функция «Отмена авторизации»

Функция «Отмена авторизации» с подробностями ASN.1, указанными в приложении А, позволяет модулю безопасности станции ИТС уведомлять ЛДК о том, что авторизация прикладного процесса станции ИТС отменена полностью или частично. Данная функция состоит:

а) из части запроса ASN.1, тип LDMrevokeAuthorizationRequest с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор выбранной ЛДК — ASN.1, тип LDMid,

3. применимый приоритет — ASN.1, тип UserPriority,

4. список применимых разрешений — разрешение ЛДК типа ASN.1;

б) части подтверждения ASN.1, тип LDMrevokeAuthorizationConf с нижеприведенными параметрами:

1. идентификатор прикладного процесса станции ИТС — ASN.1, тип ITSsapiid,

2. идентификатор отвечающей ЛДК — ASN.1, тип LDMid,

3. код результата — ASN.1, тип ResultCode.

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

6.7.6 Интерфейс управления локальной динамической картой

6.7.6.1 Функция «Регистрация ЛДК в модуле управления станцией ИТС»

Функция «Регистрация ЛДК в модуле управления станцией ИТС» с подробностями ASN.1, указанными в приложении А, позволяет ЛДК регистрироваться в модуле управления станцией ИТС для уведомления поддерживаемых типов ОД ЛДК и возможностей. Данная функция состоит:

а) из части запроса ASN.1, тип LDMregisterManagementRequest с нижеприведенными параметрами:

1. идентификатор ЛДК — ASN.1, тип LDMid,

2. список поддерживаемых типов ОД ЛДК — ASN.1, тип ListOfLDMDTids,

3. возможности ЛДК — возможности ЛДК типа ASN.1;

б) части подтверждения ASN.1, тип LDMregisterManagementConfirm с нижеприведенными параметрами:

1. идентификатор отвечающей ЛДК — ASN.1, тип LDMid,

2. код результата — ASN.1, тип ResultCode.

На данный момент определены следующие возможности ЛДК:

• основные возможности (LDMcapabilities = 0);
• возможность электронного горизонта (LDMcapabilities = 1);
• возможность фильтрации второго уровня (LDMcapabilities = 2);
• любая комбинация вышеуказанных возможностей.

В дальнейшем могут быть определены шесть дополнительных возможностей, на которые ссылаются LDMcapabilities = 4, 8, 16, 32, 64 и 128. Нормативная спецификация соответствующей процедуры представлена в 7.5.1.

6.7.7 Точки доступа к услугам

Интерфейсы реализованы как функции сервисных примитивов точек доступа к сервису (Service Access Point SAP) эталонной архитектуры станции ИТС, указанных в ПНСТ 461. Примитив службы MF-COMMAND.request используют для предоставления команды в ЛДК, что может быть подтверждено примитивом сервиса MF-COMMAND.confirm. Типы ASN.1 для применимых функций указаны в приложении А и представлены в таблице 3.

Таблица 3

Функции, используемые сервисом MF-COMMAND

& mxref	& MXParam (функция интерфейса)	Описание
MF-Command-request
100	LDMregisterRequest	Реализует функцию «Регистрация прикладного процесса станции ИТС» (см. 6.7.3.1)
101	LDMderegisterRequest	Реализует функцию «Отмена регистрации прикладного процесса станции ИТС» (см. 6.7.3.2)
102	LDMaddRequest	Реализует функцию «Добавление записи данных ЛДК» (см. 6.7.4.1)
103	LDMupdateConfirm	Реализует функцию «Обновление записи данных ЛДК» (см. 6.7.4.2)
104	LDMdeleteRequest	Реализует функцию «Удаление записи данных ЛДК» (см. 6.7.4.3)
105	LDMsubscribeRequest	Реализует функцию «Запрос на подписку» (см. 6.7.4.4)
106	LDMunsubscribeRequest	Реализует функцию «Отмена подписки» (см. 6.7.4.5)
107	LDMqueryRequest	Реализует функцию «Запрос» (см. 6.7.4.6)
MF-Command-confirm
100	LDMregisterConfirm	Реализует функцию «Регистрация прикладного процесса станции ИТС» (см. 6.7.3.1)
101	LDMderegisterConfirm	Реализует функцию «Отмена регистрации прикладного процесса станции ИТС» (см. 6.7.3.2)
102	LDMaddConfirm	Реализует функцию «Добавление записи данных ЛДК» (см. 6.7.4.1)
103	LDMupdateConfirm	Реализует функцию «Обновление записи данных ЛДК» (см. 6.7.4.2)
104	LDMdeleteConfirm	Реализует функцию «Удаление записи данных ЛДК» (см. 6.7.4.3)
105	LDMsubscribeConfirm	Реализует функцию «Подписка» (см. 6.7.4.4)
106	LDMunsubscribeConfirm	Реализует функцию «Отмена подписки» (см. 6.7.4.5)
107	LDMqueryConfirm	Реализует функцию «Запрос» (см. 6.7.4.6)

Примитив службы MF-REQUEST.request используют для предоставления команды ЛДК модулю управления станцией ИТС, что может быть подтверждено примитивом службы MF-REQUEST.confirm. Типы ASN.1 для соответствующей функции указаны в приложении А и представлены в таблице 4.

Таблица 4

Функции, используемые в сервисе MF-REQUEST

& mxref	& MXParam (интерфейсная функция)	Описание
MF-Request-request
108	LDMrevokeAppNotifyRequest	Реализует функцию «Отмена уведомления прикладного процесса станции ИТС» (см. 6.7.3.3)
109	LDMnotifyRequest	Реализует функцию «Уведомление» (см. 6.7.4.7)
110	LDMregisterManagementRequest	Реализует функцию «Регистрация ЛДК в модуле управления станцией ИТС» (см. 6.7.6.1)

Примитив службы SF-COMMAND.request используют для предоставления команды безопасности для ЛДК и подтверждается примитивом службы. Типы ASN.1 для применимых функций указаны в приложении А и представлены в таблице 5.

& mxref	& MXParam (функция интерфейса)	Описание
SF-Command-request
100	LDMrevokeAuthorizationRequest	Реализует функцию «Отмена авторизации» (см. 6.7.5.2)
SF-REQUEST.confirm
100	LDMrevokeAuthorizationConfirm	Реализует функцию «Подтверждение отмены авторизации»

Примитив сервиса SF-REQUEST.request используют для предоставления команды безопасности ЛДК модулю безопасности станции ИТС, что подтверждено примитивом сервиса SF-REQUEST.confirm.ASN.1 и значения для применимых функций указаны в приложении А и представлены в таблице 6.

&mxref	&MXParam (Interface function)	Описание
SF-request
100	LDMcheckAuthorizationRequest	Реализует функцию «Проверка прав доступа» (см. 6.7.5.1)
SF-confirm
100	LDMcheckAuthorizationConfirm	Реализует функцию «Проверка прав доступа» (см. 6.7.5.1)

В таблице 7 перечислены функции сервисных примитивов FA-SAP, применимых для настоящего стандарта, с подробностями ASN.1, указанными в приложении А. Эти сервисные примитивы упомянуты как FASAPDOWN и FASAPUP.

Таблица 7

Функции, используемые в сервисах FA-SAP

&mxref	&MXParam (Interface function)	Описание
FASAPDOWN
100	LDMcheckAuthorizationRequest	Реализует функцию «Проверка прав доступа» (см. 6.7.5.1)
101	LDMderegisterRequest	Реализует функцию «Отмена регистрации прикладного процесса станции ИТС» (см. 6.7.3.2)
102	LDMaddRequest	Реализует функцию «Запрос на добавление» (см. 6.7.4.1)
103	LDMupdateRequest	Реализует функцию «Добавление записи данных ЛДК» (см. 6.7.4.2)
104	LDMdeleteRequest	Реализует функцию «Удаление записи данных ЛДК» (см. 6.7.4.3)
105	LDMsubscribeRequest	Реализует функцию «Подписка» (см. 6.7.4.4)
106	LDMunsubscribeRequest	Реализует функцию «Отмена подписки» (см. 6.7.4.5)
107	LDMqueryRequest	Реализует функцию «Запрос» (см. 6.7.4.6)
108	NullType	Подтверждение функции запроса «Отмена уведомления прикладного процесса станции ИТС» не ожидается. Если в SAP представлено подтверждение, используют функцию NullType
109	NullType	Подтверждение функции «Уведомление» не ожидается. Если подтверждение представлено в SAP, используют функцию NullType
110	LDMregisterManagementConfirm	Реализует функцию «Регистрация ЛДК в модуле управления станцией ИТС» (см. 6.7.6.1)
FASAPUP
101	LDMderegisterConfirm	Реализует функцию «Отмена регистрации прикладного процесса станции ИТС» (см. 6.7.3.2)
102	LDMaddConfirm	Реализует функцию «Добавление записи данных ЛДК» (см. 6.7.4.1)
103	LDMupdateConfirm	Реализует функцию «Обновление записи данных ЛДК» (см. 6.7.4.2)
104	LDMdeleteConfirm	Реализует функцию «Удаление записи данных ЛДК» (см. 6.7.4.3)
105	LDMsubscribeConfirm	Реализует функцию «Подписка» (см. 6.7.4.4)
106	LDMunsubscribeConfirm	Реализует функцию «Отмена подписки» (см. 6.7.4.5)
107	LDMqueryConfirm	Реализует функцию «Запрос» (см. 6.7.4.6)
108	LDMrevokeAppNotifyRequest	Реализует функцию отзыва запроса на уведомление приложения
109	LDMnotifyRequest	Реализует функцию запроса уведомления
110	LDMregisterManagementRequest	Реализует функцию «Регистрация ЛДК в модуле управления станцией ИТС» (см. 6.7.6.1)

7 Процедуры

7.1 Услуги локальной динамической карты

7.1.1 Регистрация, отмена регистрации и отзыв прикладных процессов станции ИТС

Безопасная регистрация должна быть выполнена по запросу, представленному функцией «Регистрация прикладного процесса станции ИТС» (см. 6.7.3.1), при поддержке модуля безопасности станции ИТС, запрошенного с первоначальной проверкой функции авторизации (см. 6.7.5.1). Отмена регистрации должна быть выполнена по запросу, представленному функцией «Отмена регистрации» (см. 6.7.3.2), или по запросу модуля безопасности станции ИТС, представленному в функции «Отмена уведомления прикладного процесса станции ИТС» (см. 6.7.3.3).

7.1.2 Проверка безопасности в запросах на доступ

Все попытки прикладного процесса станции ИТС получить доступ к локальной динамической карте должны быть основаны на механизме применения политики, описанном в 5.6, 6.4.1 и 6.4.2, который охватывает все вызовы функций в ЛДК и разрешает их, только если вызов соответствует ранее зарегистрированной политике.

7.1.3 Управление запросами доступа

7.1.3.1 Проверка авторизации и достоверности

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

• 3 — неизвестный процесс подачи заявления в станции ИТС;
• 5 — недопустимый приоритет (представленный приоритет выше максимально допустимого приоритета);
• 6 — недопустимый фильтр (фильтрация второго уровня не поддерживается или выбран неподходящий оператор);
• 9 — неизвестный тип ОД ЛДК (не поддерживается ЛДК);
• 10 — авторизация для данного запроса отсутствует;
• 11 — недостоверная информация о времени (например, время в прошлом). В качестве альтернативы запрашиваемое действие должно быть выполнено.

7.1.3.2 Добавление записи данных ЛДК

Доступ для добавления должен быть выполнен по запросу, представленному функцией «Добавление записи данных ЛДК» ASN.1, тип LDMaddRequest (см. 6.7.4.1). После проверки авторизации, указанной в 7.1.3.1, ЛДК должна:

• создать новую запись данных с уникальным идентификатором записи ЛДК;
• установить:
• значение поля идентификатора записи ЛДК на соответствующее значение этой новой записи данных ЛДК,
• время создания записи на текущее время,
• значения типа ОД ЛДК, срок действия местоположения, срок действия времени, время генерации, время обязательного удаления, ОД ЛДК, идентификатор прикладного процесса станции ИТС, как указано в соответствующих параметрах запроса.

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

Флаг политики должен быть определен в true, если время обязательного удаления определено в допустимое значение.

Примечание - Флаг Policy также может быть установлен в true другими способами, которые выходят за рамки настоящего стандарта. Выполнение запроса должно быть подтверждено кодом результата, равным 0 (успех), представленным в функции подтверждения ASN.1, тип LDMaddConfirm.

7.1.3.3 Обновление записи данных ЛДК

Доступ к обновлению должен быть выполнен по запросу, представленному функцией «Обновление записи данных ЛДК» ASN.1, тип LDMupdateRequest (см. 6.7.4.2). После проверки авторизации, описанной в 7.1.3.1, ЛДК должна обновить те поля записи данных ЛДК, которые указаны уникальным идентификатором записи ЛДК. Обновление должно быть выполнено для тех параметров (действительность местоположения, срок действия времени, время генерации, время обязательного удаления, ОД ЛДК), для которых соответствующие параметры интерфейса показывают действительные значения (отличные от нулевого значения). Преобразование формата и хранение обоих форматов должны быть выполнены таким образом, как указано в 7.1.3.2. Время удаления должно быть установлено равным времени обязательного удаления, если оно доступно, или получено исходя из срока действия. Флаг политики должен быть указан в true, если время обязательного удаления установлено в допустимое значение.

Примечание - Флаг Policy также может быть установлен в true другими способами, которые выходят за рамки настоящего стандарта. Выполнение запроса должно быть подтверждено кодом результата, равным 0 (успех), представленным в функции подтверждения ASN.1, тип LDMupdateConfirm.

7.1.3.4 Удаление записи данных

Доступ к удалению записи данных должен быть выполнен по запросу, представленному функцией «Удаление записи данных ЛДК» ASN.1, тип LDMdeleteRequest (см. 6.7.4.3). Запись данных ЛДК должна быть полностью удалена из активной области ЛДК. Выполнение запроса должно быть подтверждено кодом результата = 0 (успех), представленным в функции подтверждения ASN.1, тип LDMdeleteConfirm.

7.1.3.5 Запрос ОД ЛДК

Запросы должны быть выполнены по запросу, представленному функцией «Запрос» ASN.1, тип LDMqueryRequest, описанной в 6.7.4.6. Функция «Запрос» реализует обязательную функцию фильтрации первого уровня и дополнительную функцию фильтрации второго уровня, как указано в 7.1.4. Фильтрация первого уровня должна быть выполнена по представленным ниже параметрам:

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

Все вышеперечисленные требования должны быть выполнены одновременно для того, чтобы предварительно выбрать соответствующий ОД ЛДК и переслать его на дополнительную фильтрацию второго уровня.

Если запрашивающее приложение станции ИТС представляет область интереса ЛДК или время интереса ЛДК в формате, отличающемся либо от исходного формата области действия и времени действия соответственно, либо от формата, используемого ЛДК, надлежащее преобразование формата должно быть выполнено. После завершения поиска в хранилище данных ЛДК все обращения должны быть возвращены запрашивающему прикладному процессу станции ИТС, представленному в функции подтверждения ASN.1, тип LDMqueryConfirm с кодом результата, равным 0 (успех). В случае сбоя должен быть возвращен соответствующий код результата, указывающий на ошибку.

7.1.3.6 Подписка на обновления ОД ЛДК

Подписка должна быть выполнена по запросу, представленному функцией подписки ASN.1, тип LDMsubscribeRequest, описанной в 6.7.4.4. Функция подписки идентична функции запроса, за исключением того, что не выполняется ни один запрос из хранилища данных ЛДК. Подписка должна приводить либо к периодическим уведомлениям о доступных ОД ЛДК, либо к уведомлениям, управляемым событиями (т.е. при доступных обновлениях ОД ЛДК). ЛДК должна подтвердить принятие запроса на подписку с кодом результата, равным 0 (успех), представленным в функции подтверждения ASN.1, тип LDMsubscribeConfirm. После этого подтверждения должны быть выполнены уведомления, как указано в 7.1.3.8, до тех пор, пока ЛДК не получит запрос на выполнение функции отмены подписки, как указано в 7.1.3.7.

7.1.3.7 Отмена подписки на обновления ОД ЛДК

Отмена подписки должна быть выполнена по запросу, представленному функцией отмены подписки ASN.1, тип LDMunsubscribeRequest, указанной в 6.7.4.5. ЛДК должна прекратить направлять соответствующие уведомления об обновлениях ОД ЛДК и подтвердить это с помощью кода результата, равного 0 (успех), в функции подтверждения ASN.1, тип LDMunsubscribeConfirm.

7.1.3.8 Уведомление об обновлениях ОД ЛДК

Уведомление должно быть ограничено подписанными приложениями станции ИТС и авторизованными ОД ЛДК в соответствии с запросом во время подписки. Уведомление должно быть выполнено с помощью функции уведомления ASN.1, тип LDMnotifyRequest, указанной в 6.7.4.7. Процесс подачи заявления станции ИТС не подтверждает такие уведомления.

7.1.4 Фильтрация второго уровня

Фильтрация второго уровня — это дополнительная функция, основанная на параметре интерфейса фильтра ASN.1, тип FilterSecondLevel. Наличие этой функции должно быть указано во время регистрации ЛДК (см. 7.5.1). Фильтрацию второго уровня применяют к тем ОД ЛДК, которые возникают в результате фильтрации первого уровня в функциях «запрос» и «подписка» (см. 6.4.3.1, 7.1.3.5 и 7.1.3.6). В процессе фильтрации второго уровня должно быть выполнено сравнение значений атрибутов предварительно выбранных ОД ЛДК с эталонными значениями в соответствии с требованиями фильтра, представленными в параметре фильтра. Эталонные значения представлены в виде OCTET STRING.

Представление значения OCTET STRING должно быть преобразовано в определенный формат соответствующего атрибута для того, чтобы можно было сравнивать значения выбранных атрибутов с эталонными значениями. ОД ЛДК, которые проходят фильтрацию первого и второго уровней, должны быть представлены запрашивающему прикладному процессу станции ИТС.

7.2 Обслуживание локальной динамической карты

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

7.2.2 Удаление устаревших данных

Управление устаревшими данными заключается в удалении записи данных ЛДК в момент времени, равный или более поздний, чем время удаления, указанное в параметрах обслуживания ЛДК, показанных на рисунке 7.

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

7.3 База знаний локальной динамической карты

База знаний ЛДК — это база данных. Таким образом обновления базы данных ЛДК могут быть выполнены центром управления конфигурацией модуля станции ИТС, представленным в ПНСТ 459, с использованием управления удаленными станциями ИТС. Более подробно обновления не рассматриваются в настоящем стандарте. Информация о создании словаря данных ЛДК представлена в приложении Б.

7.4 Интерфейсы

Спецификации интерфейсов не применимы, так как все интерфейсы определены в 6.6.2 как функции сервисных примитивов точек доступа к сервису (SAP). Поддержка SAP с деталями ASN.1, указанными в приложении А (А.2), является необязательной.

7.5 Управление локальной динамической картой

7.5.1 Регистрация ЛДК в модуле управления станции ИТС

ЛДК должна зарегистрироваться в модуле управления станции ИТС с помощью функции регистрации ЛДК ASN.1, тип LDMregisterManagementRequest, указанной в 6.7.6. ЛДК должна представить управлению станцией ИТС:

• свой идентификатор ЛДК, назначенный во время инсталляции или обновления программного обеспечения ЛДК;
• список поддерживаемых типов ОД ЛДК;
• свои возможности (см. 6.7.6).

Регистрация будет подтверждена модулем управления станцией ИТС со статусом возврата 0 (успех) в функции подтверждения типа ASN.1 LDMregisterManagementConfirm.

7.5.2 Модули станции ИТС

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

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

МОДУЛИ ASN.1

А.1 Обзор

Базовая нотация ASN.1 определена в ГОСТ Р ИСО/МЭК 8824-1. В настоящем приложении указан следующий модуль ASN.1 — CITSldm2 {ISO (1) standard (0) cits-ldm (18750) asnm-1 (1) version2 (2)}. Спецификации ASN.1, приведенные в данном приложении, имеют преобладающее значение над спецификациями, представленными в настоящем стандарте.

А.2 Модуль CITSldm

Правила невыровненного упакованного кодирования (PER), как указано в ГОСТ Р ИСО/МЭК 8825-2, применяют к модулю ASN.1 CITSldm2 в том случае, если элементы данных и элементы значений используют в примитивах обслуживания SAP модуля станции ИТС. Правила кодирования, применяемые в других целях, выходят за рамки настоящего стандарта. CITSldm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}DEFINITIONS AUTOMATIC TAGS::=BEGIN IMPORTS -- C-ITS Data Dictionary (still in ISO 17419) UserPriority, NullType, Time48IAT FROM CITSdataDictionary1 {iso(1) standard(0) cits-applMgmt (17419) dataDictionary (1) version1 (1)} --ISO 17419 ITSsapiid, GeoPolygonArea FROM CITSapplMgmtApplReg {iso(1) standard(0) cits-applMgmt (17419) applRegistry (2) version2 (2)} ; -- End of IMPORTS -- Types -- Interface parameters -- ITS-S application process identifier -- ITSsapiid imported from ПНСТ 459-2020 -- LDM Area of Interest AreaOfInterest::=LDMarea -- LDM Authorizations / permissions LDMpermissionList::=SEQUENCE OF LDMpermission LDMpermission::= LDMdataObjectTypeID -- Security credentials to check permissions SECCRED::=CLASS { &ref Ref-SecCredLDM, &Value } Ref-SecCredLDM::=INTEGER{ c-LDMsecCred-Null (0), c-LDMsecCred-AuthID (1)} (0..255)

LDMsecurityCredential::=SEQUENCE{
refSec SECCRED.&ref({LDMsecCredentials}),
secCred SECCRED.&Value({LDMsecCredentials}{@refSec})
}
LDMsecCredentials SECCRED::={noSecCred | authID, ...}
noSecCred SECCRED::={&ref c-LDMsecCred-Null, &Value NullType}
authID SECCRED::={&ref c-LDMsecCred-AuthID, &Value AuthID}
AuthID ::=  BIT STRING (SIZE(256)) -- originally defined in ETSI EN 302 895

-- LDM record ID: EN 302 895 uses the name DataObjectID LDMrecordID::=INTEGER{
ldmRecordIDunknown (0)} -- value zero is reserved for the unknown record.

-- LDM Data Dictionary
DataDictionaryID::=INTEGER{
ddID-LDMdd (1) -- LDM-DD
} -- needs to be maintained in a registry
LDMDATADICTIONARY::=CLASS {
&ref LDMdataObjectTypeID UNIQUE,
&Value
}
LDMdataObjectTypeID::=INTEGER{
unknown (0)
}(0..МАХ)
-- reserved for CEN/ISO standardized usage (1) - (1023)
-- reserved for ETSI standardized usage (1024) - (2047)
-- reserved for IEEE/SAE standardized usage (2048) - (3071)
-- reserved for further standardized usage (3072) - (8191)
-- reserved for registered usage (8192) - (64511)
-- reserved for private unregistered usage (64512) - (65535)
c-ldmdoNull LDMdataObjectTypeID::=0
LDMdataObject::=SEQUENCE{
  ldmdotRef LDMDATADICTIONARY.&ref({LDMdataObjectTypes}),
  lDMdataObType LDMDATADICTIONARY.&Value ({LDMdataObjectTypes} {@ldmdotRef})
}
-- The set of LDM Data Objects
LDMdataObjectTypes LDMDATADICTIONARY::={
/* ldmdoAnotherLdmDataObject | */
ldmdoNull,...}
ldmdoNull LDMDATADICTIONARY::={&ref c-ldmdoNull, &Value NullType}
-- LDM DA Class - used to create LDM-DO types
LDMDOA::=CLASS {
&ref INTEGER,
&Value
}
-- further types to be added as needed by real implementations
/* The ASN.1 code presented in this comment is to be used as a template to generate new LDM Data Object Types
   -- An LDM Data Object of a given type consists of a sequence of zero or more attributes. Attributes are TLV encod-

ed, i.e. specified with ASN.1 type CLASS — one CLASS per LDM Data Object Type. In the examples below the terms An- otherLdmDataObject / ANOTHERLDMOBJECT must be replaced by the intended name of the LDM Data Object Type. -- Example of another LDM Data Object Type with attributes AnotherLdmDataObject::=SEQUENCE OF Another- LDMdataObjectAttribute -- Example of assigning a LDM DO type ID c-ldmdoAnotherLdmDataObject LDMdataObjectTypeID::=65535 -- Example on how to identify the instantiation of AnotherLdmDataObject ldmdoAnotherLdmDataObject LDM- DATADICTIONARY::={&ref c-ldmdoAnotherLdmDataObject, &Value AnotherLdmDataObject} -- Example of LDM DA Class for AnotherLdmDataObject ANOTHERLDMOBJECTCLASS::= LDMDOA -- Example of one single LDM DO Attribute for AnotherLdmDataObject AnotherLDMdataObjectAttribute::=SE- QUENCE} ldmDoAttRef ANOTHERLDMOBJECTCLASS.&ref({AnotherLDMdataObjectAttributes}), ldmDoAtt ANOTHERLDMOBJECTCLASS.&Value ({AnotherLDMdataObjectAttributes}{@ldmDoAttRef}) } -- Example of the set of all LDM DO Attributes for AnotherLdmDataObject AnotherLDMdataObjectAttributes AN- OTHERLDMOBJECTCLASS::={ldmDoAtTy0 | ldmDoAtTy1 | ldmDoAtTy2, ...{ -- as example an empty / unknown LDM Attribute ldmDoAtTy0 ANOTHERLDMOBJECTCLASS::={&ref 0, &Value NullType} ldmDoAtTy1 ANOTHERLDMOBJECT- CLASS::={&ref 1, &Value INTEGER}ldmDoAtTy2 ANOTHERLDMOBJECTCLASS::={&ref 2, &Value OCTET STRING} End of the template code */

-- Result code
ResultCode::=INTEGER{
  success (0), -- For authorization interpreted as PERMIT
  failure (1), -- For authorization interpreted as DENY
  invalidApp (2),
  unknownApp (3),
  invalidType (4),
  invalidPriority (5),
  invalidFilter (6),
  invalidOrder (7),
  areaFailure (8),
  unknownType (9),
  noAuthorization (10),
  invalidTime (11),
  unspecifiedError (255)
  } (0..255)
-- Subscription ID
SubscriptionID::=Int2
-- LDM data
LDMinterfaceRecordRead::=SEQUENCE{
  recordID LDMrecordID, -- LDM record ID
  geoRefs LDMgeoRefs, -- Location Validity / reference
  timeRefs LDMtimeRefs, -- Time Validity / reference
  genTime TimeOfGeneration, -- time of generation
  data LDMdataObject -- type and data
  }
LDMgeoRefs::=SEQUENCE{
  internal LDMarea, -- LDM internal format
  original LDMarea, -- Original format presented at time of writing
  requested LDMarea -- Format requested
  }

LDMtimeRefs::=SEQUENCE{
   internal Validity TimeInterval, -- LDM internal format
   original Validity TimeInterval, -- Original format presented at time of writing

requested ValidityTimeInterval -- Format requested }

LDMinterfaceRecords::=SEQUENCE OF LDMinterfaceRecordRead

-- end of Interface parameters
-- interface functions
-- Registration / deregistration / revocation
LDMregisterRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priority UserPriority,
  permissions LDMpermissionList,
  secCredentials LDMsecurityCredential
  }
LDMregisterConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid, -- set to the value of the LDM that confirms
  permissions LDMpermissionList,
  result ResultCode
  }
LDMderegisterRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid
  }
LDMderegisterConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid, -- set to the value of the LDM that confirms
  result ResultCode
  }
LDMrevokeAppNotifyRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priority UserPriority, -- maximum still applicable or zero
  permissions LDMpermission, -- still applicable (may be empty)
  reason RevocationReason
  }

RevocationReason::=INTEGER{
  registrationRevokedByRegistrationAuthority (0),
  registrationPeriodExpired (1),
  unspecifiedReason (255)
  } (0..255)
LDMrevokeAppNotifyConfirm::=SEQUENCE{
itssAppProcess ITSsapiid,
ldmID LDMid,
result ResultCode
}
-- Data providers
LDMaddRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  data LDMdataObject, -- type and data
  geoRef LDMarea, -- Location Validity / reference
  timeRef ValidityTimeInterval, -- Time Validity / reference
  genTime TimeInformation, -- time of generation
  timeMandDelete TimeInformation -- if time provided, then privacy flag = true
  }
LDMaddConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  ldmRecordID LDMrecordID,
  result ResultCode
  }
LDMupdateRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  ldmRecordID  LDMrecordID,
  data LDMdataObject, -- type and data
  geoRef LDMarea, -- Location Validity / reference
  timeRef ValidityTimeInterval, -- Time Validity / reference
  genTime TimeInformation, -- time of generation
  timeDelete TimeInformation -- if time provided, then privacy flag = true
  }
LDMupdateConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  ldmRecordID LDMrecordID,
  result ResultCode
  }
LDMdeleteRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  ldmRecordID LDMrecordID,
  }
LDMdeleteConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  ldmRecordID LDMrecordID,
  result ResultCode
  }
-- Data users
LDMsubscribeRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priority UserPriority,
  ldmRecordID LDMrecordID,
  ldmDoTypeID LDMdataObjectTypeID,
  areaInterest AreaOfInterest,
  timeInterest TimeOfInterest,
  ageInterest  AgeOfInterest,
  filter FilterSecondLevel,
  notifyInterval NotificationInterval,
  notifyUpdate NotificationUponUpdate
  }
-- Flag for notification upon update
NotificationUponUpdate::=Flag

LDMsubscribeConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  subscribeID SubscriptionID,
  result ResultCode
  }
LDMunsubscribeRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priority UserPriority,
  subscribeID SubscriptionID
  }
LDMunsubscribeConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  subscribeID SubscriptionID,
  result ResultCode
  }
LDMqueryRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priority UserPriority,
  ldmRecordID LDMrecordID,
  ldmDoTypeID LDMdataObjectTypeID,
  areaInterest AreaOfInterest,
  timeInterest TimeOfInterest,
  ageInterest AgeOfInterest,
  filter FilterSecondLevel
  }
LDMqueryConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  ldmData LDMinterfaceRecords,
  result ResultCode
  }
LDMnotifyRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  subscribeID SubscriptionID,
  ldmData LDMinterfaceRecords
  }
LDMnotifyConfirm::=NullType
-- Security entity
LDMcheckAuthorizationRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priority UserPriority,
  permissions LDMpermissionList,
  secCredentials LDMsecurityCredential
  }

LDMcheckAuthorizationConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priorityConf UserPriority,
  permissionsConf LDMpermissionList,
  result ResultCode
  }
LDMrevokeAuthorizationRequest::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  priorityRemain UserPriority,
  permissionsRemain LDMpermissionList
  }
LDMrevokeAuthorizationConfirm::=SEQUENCE{
  itssAppProcess ITSsapiid,
  ldmID LDMid,
  result ResultCode
  }
-- Management entity
-- Register LDM at management
LDMregisterManagementRequest::=SEQUENCE{
  ldmID LDMid, -- assigned at time of implementation of LDM
  ldmDTs ListOfLDMDTids,
  ldmCapabilities LDMcapabilities
  }
ListOfLDMDTids::=SEQUENCE OF LDMdataObjectTypeID
LDMcapabilities::=INTEGER{
  basic (0),
  electronicHorizon (1),
  secondLevelFiltering (2)
  } (0..255) -- used as a bit field indicating up to eight features
LDMregisterManagementConfirm::=SEQUENCE{
  ldmID LDMid,
  result ResultCode
  }
-- end of interface functions
-- General area definition
-- Geo-coordinate systems
GEOCOORD::=CLASS {
  &ref Ref-GeoCoordLDM,
  &Value
  }
Ref-GeoCoordLDM::=INTEGER{
  c-GeoCoord-Null (0),
  c-GeoCoord-Polygon (1)
  } (0..255)
LocationValidity::=LDMarea
LDMarea::=SEQUENCE{
  geoRef GEOCOORD.&ref({GeoCoordinates}),
  geoCoordinates GEOCOORD.&Value({GeoCoordinates}{@geoRef})
  }
GeoCoordinates GEOCOORD::={geoCoordNull | geoCoordPolygon, ...}
geoCoordNull GEOCOORD::={&ref c-GeoCoord-Null, &Value NullType}
geoCoordPolygon GEOCOORD::={&ref c-GeoCoord-Polygon, &Value GeoPolygonArea}

-- General time system specification
  TIMEINFO::=CLASS {
  &ref Ref-TimeInfoLDM,
  &Value
  }
Ref-TimeInfoLDM::=INTEGER{
  c-LDM-noTimeInfo (0),
  c-LDM-Time48IAT (1),
  c-LDM-doubleTime48IAT (2)
   } (0..255)
TimeInformation::=SEQUENCE{
  timeRef TIMEINFO.&ref({TimeInfos}),
  timeInfo TIMEINFO.&Value({TimeInfos}{@timeRef})
  }
TimeInfos TIMEINFO::={noTimeInfo | time48IAT | doubleTime48IAT, ...}
  noTimeInfo TIMEINFO::={&ref c-LDM-noTimeInfo, &Value NullType}
  time48IAT TIMEINFO::={&ref c-LDM-Time48IAT, &Value Time48IAT}
  doubleTime48IAT TIMEINFO::={&ref c-LDM-doubleTime48IAT, &Value DoubleTime48IAT}

DoubleTime48IAT::=SEQUENCE{
  firstTime Time48IAT, -- e.g. start of time interval
  secondTime Time48IAT -- e.g. stop of time interval
  }
-- Time of Generation
TimeOfGeneration::= TimeInformation
-- Time relative to time of generation
  AgeOfInterest::=SEQUENCE{
  operator Operators, -- e.g. <time of birth> "It" timeReference
  timeReference TimeInformation
  }
-- Time of interest (select either no info or a single info)
TimeOfInterest::=TimeInformation
-- Validity time interval(s)
ValidityTimeInterval::=SEQUENCE (SIZE(0..255)) OF TimeInformation -- start/stop types only
-- Time definitions based on International Atomic Time
TimeOfCreation::= SEQUENCE{
  timeAdd Time48IAT,
  timeLastUpdate Time48IAT
  }
TimeOfMandatoryDeletion::= TimeInformation
TimeOfDeletion::=Time48IAT

-- Time interval between subsequent notifications
NotificationInterval::=Int2 -- time span in milliseconds

-- Filter mechanism
Operators::=INTEGER{
  equal (0),
  notequal (1),
  gt (2),
  lt (3),
  gte (4),
  lte (5),
  like (6),
  notlike (7)
  } (0..255) -- End of Operators
FilterSecondLevel::=ANDsequence
ANDsequence::=SEQUENCE OF ORsequence
ORsequence::= SEQUENCE OF FilterPrimitive
FilterPrimitive::=SEQUENCE{
ldmAttributeID LDMattributeID,
operator Operators, refValue OCTET STRING -- to be converted into format given by ldmAttributeID }
LDMattributeID::=INTEGER
-- Utility types definitions
Int1::=INTEGER(0..255)
Int2::=INTEGER(0..65535)
Int4::=INTEGER(0..4294967295)
Flag::=INTEGER{
  false (0),
  true (255)
  } (0..255)
PrivacyFlag::=Flag
-- LDM identifier LDMid::=INTEGER{ c-ldmidUnknown (0), c-ldmidDefault (255)} (0..255)

-- Values version Int1::=1 -- version of this ASN.1 module END

А.3 Дополнительные определения

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

Нижеприведенные определения являются динамическими расширениями типов.

А.3.2 MF-command

Применимый модуль ASN.: ITSsapCmdMf {ISO (1) standard (0) calm-management (24102) msap (3) commands (3) mf (2) version0 (0)}

Предложение IMPORT, которое будет добавлено: LDMregisterRequest, LDMderegisterRequest, LDMaddRequest, LDMupdateRequest, LDMdeleteRequest, LDMsubscri- beRequest, LDMunsubscribeRequest, LDMqueryRequest, LDMregisterConfirm, LDMderegisterConfirm, LDMDubMirFM- MMDMConfirmMBMDMConfirmMid LDMqueryConfirm FROM CITSldm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

Будет добавлено к MF-command: ldmRegisterMFSAP-CR::={&mxrefc-ldmRegisterMF,&MXParamLDMregisterRequest}ldmDeregisterMFSAP-CR::={&mx- ref c-ldmDeregisterMF, &MXParam LDMderegisterRequest} ldmAdd MFSAP-CR::={&mxref c-ldmAddMF, &MXParam LDMaddRequest) ldmUpdate MFSAP-CR::={&mxref c-ldmUpdateMF, &MXParam LDMupdateRequest) ldmDelete MF- SAP-CR::={&mxref c-ldmDeleteMF, &MXParam LDMdeleteRequest) ldmSubscribe MFSAP-CR::={&mxref c-ldmSub- scribeMF, &MXParam LDMsubscribeRequest) ldmUnsubscribe MFSAP-CR::={&mxref c-ldmUnsubscribeMF, &MXParam LDMunsubscribeRequest) ldmQuery MFSAP-CR::={&mxref c-ldmQueryMF, &MXParam LDMqueryRequest)

Будет добавлено к MF-CmdConfirm: To be added to MF-CmdConfirm: ldmRegisterConf MFSAP-CC::={&mxref c-ldmRegisterMF, &MXParam LDMregisterConfirm) ldmDeregisterConf MFSAP-CC::={&mxref c-ldmDeregisterMF, &MXParam LDMderegisterConfirm) ldmAddConf MFSAP-CC::={&mxref c-ldmAddMF, &MXParam LDMaddConfirm) ldmUpdateConf MFSAP-CC::={&mxref c-ldmUpdateMF, &MXParam LDMupdateConfirm} ldmDeleteConf MFSAP-CC::={&mxref c-ldmDeleteMF, &MXParam LDMdeleteConfirm) ldmSubscribeConf MFSAP-CC::={&mxref c-ldmSubscribeMF, &MXParam LDMsubscribeConfirm} ldmUnsubscribeConf MFSAP-CC::={&mxref c-ldmUnsubscribeMF, &MXParam LDMunsubscribeConfirm) ldmQueryConf MFSAP-CC::={&mxref c-ldmQueryMF, &MXParam LDMqueryConfirm)

Работа над нижеприведенными определениями значений ASN.1 (values 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h') будет завершена рабочей группой WG16 ISO TC204, результат которой будет опубликован в соответствующем реестре.

c-ldmRegisterMF RefMFSAP-C ::= <'a' tbd>

c-ldmDeregisterMF RefMFSAP-C ::= <'b' tbd>

c-ldmAddMF RefMFSAP-C ::= <'c' tbd>

c-ldmUpdateMF RefMFSAP-C ::= <'d' tbd>

c-ldmDeleteMF RefMFSAP-C ::= <'e' tbd>

c-ldmSubscribeMF RefMFSAP-C ::= <'f' tbd>

c-ldmUnsubscribeMF RefMFSAP-C ::= <'g' tbd>

c-ldmQueryMF RefMFSAP-C ::= <'h' tbd>

А.3.3 MF-Request

Применимый ASN.1 модуль: ITSsapReqMf {ISO (1) standard (0) calm-management (24102) msap (3) requests (4) mf (2) version0 (0)} Предложение IMPORT, которое будет добавлено: LDMrevokeAppNotifyRequest, LDMregisterManagementRequest, LDMnotifyRequest, LDMrevokeAppNotifyConfirm, LDMregisterManagementConfirm, LDMnotifyConfirm FROM CITSldm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)} Будет добавлено к MF-Request: ldmRevokeAppNotify MFSAP-RR::={&mxref c-ldmRevokeAppNotify, &MXParam LDM- revokeAppNotifyRequest} ldmNotify MFSAP-RR::={&mxref c-ldmNotify, &MXParam LDMnotifyRequest} ldmRegisterMan- agement MFSAP-RR::={&mxref c-ldmRegisterManagement, &MXParam LDMregisterManagement-Request} Будет добавлено к MF-ReqConfirm: ldmRevokeAppNotifyConf MFSAP-RC::={&mxref c-ldmRevokeAppNotify, &MX- Param LDMrevokeAppNotifyConfirm} — не используется ldmNotifyConf MFSAP-RC::={&mxref c-ldmNotify, &MXParam LDMnotifyConfirm} — не используется ldmRegisterManagementConf MFSAP-RC::={&mxref c-ldmRegisterManagement, &MXParam LDMregisterManagement- Confirm} — не используется

Работа над нижеприведенными определениями значений ASN.1 (values 'i', 'j', 'k') будет завершена рабочей группой WG16 ISO TC204, результат которой будет опубликован в соответствующем реестре.

c-ldmRegisterManagement RefMFSAP-R ::= <'k' tbd>

Применимый модуль ASN.1: ITSfasapfunctions {ISO (1) standard (0) calm-management (24102) msap (3) fasap (5) version0 (0)}

Предложение IMPORT, которое будет добавлено: LDMregisterRequest, LDMderegisterRequest, LDMaddRequest, LDMupdateRequest, LDMdeleteRequest, LDMsubscribeRequest, LDMunsubscribeRequest, LDMqueryRequest, LDMregisterConfirm, LDMderegisterConfirm, LDMaddConfirm, LDMupdateConfirm, LDMdeleteConfirm, LDMsubscribeConfirm, LDMunsubscribeConfirm, LDMqueryConfirm, LDMrevokeAppNotifyRequest, LDMregisterManagementConfirm, LDMnotifyRequest, LDMregisterManagementRequest FROM CITSldm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

Будет добавлено к FAsapspsdown:

ldmRegisterFA FASAPDOWN::={&primitiveRef c-ldmRegisterFA, &Primitive LDMregisterRequest}

ldmDeregisterFA FASAPDOWN::={&primitiveRef c-ldmDeregisterFA, &Primitive LDMderegisterRequest} ldmAddFA FASAPDOWN::={&primitiveRef c-ldmAddFA, &Primitive LDMaddRequest} ldmUpdateFA FASAPDOWN::={&primitiveRef c-ldmUpdateFA, &Primitive LDMupdateRequest} ldmDeleteFA FASAPDOWN::={&primitiveRef c-ldmDeleteFA, &Primitive LDMdeleteRequest} ldmSubscribeFA FASAPDOWN::={&primitiveRef c-ldmSubscribeFA, &Primitive LDMsubscribeRequest} ldmUnsubscribeFA FASAPDOWN::={&primitiveRef c-ldmUnsubscribeFA, &Primitive LDMunsubscribeRequest} ldmQueryFA FASAPDOWN::={&primitiveRef c-ldmQueryFA, &Primitive LDMqueryRequest} ldmRevokeAppNotifyConfFA FASAPDOWN::={&primitiveRef c-ldmRevokeAppNotifyFA, &Primitive LDMrevokeAppNotifyConfirm} ldmNotifyConfFA FASAPDOWN::={&primitiveRef c-ldmNotifyFA, &Primitive LDMnotifyConfirm} ldmRegisterManagementConfFA FASAPDOWN::={&primitiveRef c-ldmRegisterManagementFA, &Primitive LDMregisterManagementConfirm} To be added to FAsapspsup: ldmRegisterConfFA FASAPUP::={&primitiveRef c-ldmRegisterFA, &Primitive LDMregisterConfirm} ldmDeregisterConfFA FASAPUP::={&primitiveRef c-ldmDeregisterFA, &Primitive LDMderegisterConfirm} ldmAddConfFA FASAPUP::={&primitiveRef c-ldmAddFA, &Primitive LDMaddConfirm} ldmUpdateConfFA FASAPUP::={&primitiveRef c-ldmUpdateFA, &Primitive LDMupdateConfirm} ldmDeleteConfFA FASAPUP::={&primitiveRef c-ldmDeleteFA, &Primitive LDMdeleteConfirm} ldmSubscribeConfFA FASAPUP::={&primitiveRef c-ldmSubscribeFA, &Primitive LDMsubscribeConfirm} ldmUnsubscribeConfFA FASAPUP::={&primitiveRef c-ldmUnsubscribeFA, &Primitive LDMunsubscribeConfirm}

Будет добавлено к FAsapspsup:

ldmRegisterConfFA FASAPUP::={&primitiveRef c-ldmRegisterFA, &Primitive LDMregisterConfirm} ldmDeregisterConfFA FASAPUP::={&primitiveRef c-ldmDeregisterFA, &Primitive LDMderegisterConfirm} ldmAddConfFA FASAPUP::={&primitiveRef c-ldmAddFA, &Primitive LDMaddConfirm} ldmUpdateConfFA FASAPUP::={&primitiveRef c-ldmUpdateFA, &Primitive LDMupdateConfirm} ldmDeleteConfFA FASAPUP::={&primitiveRef c-ldmDeleteFA, &Primitive LDMdeleteConfirm} ldmSubscribeConfFA FASAPUP::={&primitiveRef c-ldmSubscribeFA, &Primitive LDMsubscribeConfirm} ldmUnsubscribeConfFA FASAPUP::={&primitiveRef c-ldmUnsubscribeFA, &Primitive LDMunsubscribeConfirm}

ldmQueryConfFA FASAPUP::={&primitiveRef c-ldmQueryFA, &Primitive LDMqueryConfirm} ldmRevokeAppNotifyFA FASAPUP::={&primitiveRef c-ldmRevokeAppNotifyFA, &Primitive LDMrevokeAppNotifyRequest) ldmNotifyFA FASAPUP::={&primitiveRef c-ldmNotifyFA, &PrimitiveLDMnotifyRequest} ldmRegisterManagement FAFASAPUP::={&primitiveRef c-ldmRegisterManagementFA, &Primitive LDMregisterManagementRequest}

Работа над нижеприведенными определениями значений ASN.1 (values 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k') будет завершена рабочей группой WG16 ISO TC204, результат которой будет опубликован в соответствующем реестре.

c-ldmAddFA RefFASAP ::= <'c' tbd>

c-ldmUpdateFA RefFASAP ::= <'d' tbd>

c-ldmDeleteFA RefFASAP ::= <'e' tbd> c-ldmSubscribeFA RefFASAP ::= <'f' tbd> c-ldmUnsubscribeFA RefFASAP ::= <'g' tbd> c-ldmQueryFA RefFASAP ::= <'h' tbd> c-ldmRevokeAppNotifyFA RefFASAP ::= <'i' tbd> c-ldmNotifyFA RefFASAP ::= <'j' tbd> c-ldmRegisterManagementFA RefFASAP ::= <'k' tbd>

А.3.5 SF-Command

Применимый модуль ASN.1 из ISO 24102-3: ITSsapCmdSf {ISO (1) standard (0) calm-management (24102) msap (3) commands (3) sf (6) version0 (0)}

Предложение IMPORT, которое будет добавлено: LDMrevokeAuthorizationConfirm, LDMrevokeAuthorizationRequest FROM CITSldm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

Применимый модуль ASN.1: ITSsapReqSf {ISO (1) standard (0) calm-management (24102) msap (3) requests (4) sf (6) version0 (0)}

Предложение IMPORT, которое будет добавлено:

LDMcheckAuthorizationConfirm, LDMcheckAuthorizationRequest FROM CITSldm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

Будет добавлено к SF-Request:

ldmCheckAuthorization SFSAP-RR::={&mxref c-ldmCheckAuthorizationSF, &MXParam LDMcheckAuthorizationRequest}

Будет добавлено к SF-ReqConfirm:

ldmCheckAuthorizationConf SFSAP-RC::={&mxref c-ldmCheckAuthorizationSF, &MXParam LDMcheckAuthorizationConfirm}

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

Словарь данных ЛДК однозначно идентифицируется с помощью идентификатора словаря данных (DataDictionaryID) ASN.1, тип DataDictionaryID, указанного в приложении А.

Идентификационный номер словаря данных ЛДК — DataDictionaryID = 1, указанный в настоящем стандарте.

Подход к представлению данных в словарях данных не определен однозначно, а предназначен для конкретного словаря данных согласно ПНСТ 340.

Пример - Примеры словарей данных от SAE, ETSI, CEN/ISO, DATEX, JPEG, RDS-TMC.

Настоящий стандарт определяет подход к представлению данных в словаре данных ЛДК. Двумерное адресное пространство, как показано на рисунке Б.1, должно быть использовано с двумя измерениями:

а) идентификатор типа данных ЛДК;

б) идентификатор типа атрибута данных ЛДК.

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

Такой подход позволяет:

• впоследствии создать глобальный словарь данных ЛДК в соответствии с потребностями рынка;
• использовать подмножества глобального словаря данных ЛДК или всего словаря данных ЛДК в реализациях;
• рассматривать существующие словари данных, выполнив соответствующее преобразование в элементы глобального словаря данных ЛДК;
• использовать существующие источники информации (DATEX, JPEG, RDS-TMC, ...) без необходимости что-либо изменять в этих устаревших спецификациях;
• использовать для КИТС источники информации (CEN/ISO, ETSI, SAE);
• определять не существующую в данный момент информацию в глобальном ОД ЛДК.

Диапазон номеров ОД ЛДК указан в таблице Б.1.

Диапазон номеров	Назначение
0	Неизвестный тип ОД ЛДК
1 — 64511	Зарезервировано для зарегистрированных использований <а>
64512 — 65535	Зарезервировано для частных незарегистрированных использований <б>
<а> Орган регистрации, отвечающий за управление запросами на регистрацию, до сих пор не указан. Зарегистрированные и стандартизованные задания будут опубликованы на портале поддержки настоящего стандарта. <б> Незарегистрированное использование отключает общую переносимость приложений ИТС. Преобразование устаревших форматов в глобальный формат ОД ЛДК целесообразно.

Преобразование устаревших форматов в глобальный формат ОД ЛДК целесообразно выполнять с помощью синтаксических анализаторов сообщений, обладающих знаниями об унаследованных форматах и формате ОД ЛДК. Каждый тип ОД ЛДК должен быть уникальным образом идентифицирован идентификатором типа данных ЛДК ASN.1, тип LDMdataObjectTypeID, указанным в приложении А.

Тип данных ЛДК является глобально уникальным идентификатором.

ОД ЛДК должен быть представлен с объектом ASN.1, тип LDMdataObject, указанным в приложении А (кодированное значение длины типа). Он должен состоять из последовательности нуля или более типов атрибутов данных ЛДК. Каждый тип атрибутов данных ЛДК должен быть уникально идентифицирован его идентификатором ASN.1, тип LDMattributeID, указанным в приложении А.

Идентификатор типа атрибутов данных ЛДК уникален только для конкретного типа ОД ЛДК. Общий подход для определения экземпляров ОД ЛДК должен соответствовать ASN.1, тип AnotherLdmDataObject, который определяет структуру ОД ЛДК в словаре данных ЛДК (последовательность длины типа закодированных атрибутов).

В.1 Модуль станции ИТС может получать данные из различных источников и с разными форматами, указанными в различных словарях данных. Эти словари либо уже существуют (например, DATEX II, TPEG), либо предназначены для КИТС, либо в настоящее время разрабатываются. Примерами таких словарей являются SPaT, IVI, CAM, DENM.

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

В.2 Пример объектов данных дорожных работ

В.2.1 DATEX II

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

На рисунке В.1 приведен пример объекта RoadWorks. В DATEX II ситуация с дорожными работами представлена в ситуационной записи категории OperatorAction. SituationRecord определяет уникальную идентификацию ситуации, а также идентификационную информацию об отправителе и издателе записи, каждая из которых с отметкой времени. Ситуация также имеет причину, влияние, значимость, вероятность, конфиденциальность и источник. Поле groupOfLocations допускает несколько ссылок на местоположения, включая ALERT-C, линейные и TPEG-системы определения местоположения.

Дорожные работы — это специфический оператор действия. Типичными для дорожных работ являются продолжительность, масштаб, мобильность и срочность работы, а также то, выполняются ли дорожные работы в условиях движения. Атрибут субъектов определяет, относятся ли дорожные работы к самой дороге, порталу, дорожным знакам или туннелю. Дорожные работы подразделяют на строительные и эксплуатационные. Ситуационная запись содержит общую информацию DATEX II о времени и местоположении, которая отличается от приведенных ниже сообщений TPEG и DEN. Атрибуты для достоверности и вероятности возникновения событий указывают на целостность и достоверность той информации, которая отсутствует в сообщениях TPEG или DEN. Информация о дорожных работах DATEX II также может храниться в виде ОД ЛДК с использованием структуры объекта на рисунке В.1. Параметры интерфейса для записи данных ЛДК на рисунке 7 также могут быть извлечены из сообщения DATEX II, например:

• допустимость местоположения из атрибута groupOfLocations;
• временная валидность из подобъекта валидности и продолжительности дорожных работ;

Рисунок В.2 — Пример объекта данных дорожных работ в событии TPEG-TEC

Кроме того, предоставляется дополнительная информация, имеющая отношение к транспортному потоку и пользователю дороги. Предусмотрено время начала и остановки события транспортного потока, которое отличается от временных рамок дорожных работ, указанных в сообщении DATEX II. TPEG добавляет информацию о местоположении в событие приложения с помощью ссылки на местоположение TPEG (TPEG-LOC).

В TPEG-TEC дорожных работ информация также может быть сохранена в качестве ОД ЛДК, используя структуру объекта, представленную на рисунке В.2.

Параметры интерфейса для записи данных ЛДК на рисунке 7 также могут быть извлечены из сообщения TPEG-TEC, например:

• валидность местоположения из ссылки местоположения TPEG-EC и атрибута lengthAffected;

В.2.4 Объект данных LDMRoadworks

Событие дорожных работ может публиковаться параллельно от разных издателей, например в сообщениях DATEX II, TPEG-TEC и DEN, и все сообщения могут храниться в виде ОД ЛДК, как описано в приложении Б. Также может существовать прикладной процесс, который может объединить эти три объекта в новый ОД ЛДК для объекта реального мира, например объект LdmRoadworks. Так как словарь данных ЛДК еще не определен, ниже приведен пример того, как можно это сделать LdmRoadworks.

Цель объекта данных LdmRoadworks состоит в том, чтобы предоставить приложениям полный набор функций об одном событии дорожных работ и тем самым избежать необходимости обращаться к трем исходным сообщениям объектов данных по отдельности. Структура и атрибуты объекта LdmRoadworks — это расширенный набор атрибутов исходных сообщений. На рисунке В.4 приведен пример, в котором приняты наиболее распространенные имена подобъектов и атрибутов.

Рисунок В.4 — Пример объекта данных ЛДК Roadworks

Формат ЛДК по умолчанию для времени и местоположения используется исходя из записи ЛДК и преобразуется согласно таблице В.1.

Атрибуты LdmRoadworks (пример)

Элемент	Описание
FirstDetectionTime (время первого обнаружения)	Информация, в какое время впервые обнаружены дорожные работы или когда они начаты. Это может быть время обнаружения DENM, время начала события TPEG или первая отметка времени ситуации DATEX II
Location Validity (действительное местоположение)	Местоположение или область дорожных работ. Местоположение может быть получено как объединение DATEX II groupdOfLocations, ссылки на местоположение из TPEG-TEC и lengthActed, а также eventPosition и LocationContainer DENM. Местоположение включает в себя релевантную область, в которой следует предупреждать водителей, например определенную посредством релевантности Distance и релевантности TrafficDirectino DENM. Определение Location Validity изложено в таблице 1. Формат систем определения местоположения задается элементом LDMarea ASN.1, указанным в приложении А
Time Validity (срок действия)	Период времени, в течение которого проходят дорожные работы. Период времени может быть получен как объединение объекта достоверности DATEX II, времени начала и окончания объекта TPEG-TEC или validityDuration DENM. Срок действия определен в таблице 1, а также предоставлен формат систем отсчета времени
Time of Generation (время генерации)	Информация о последнем времени обновления исходных ОД ЛДК или последнем временем генерации любого из исходных ОД ЛДК. Предполагается, что данные других исходных объектов данных еще действительны. Время генерации определено в таблице 1. Формат этого элемента задается элементом ASN.1 TimeOfGeneration, указанным в приложении А
OriginalEvent (исходное событие)	Это ссылка на ОД ЛДК, содержащий данные исходного сообщения, которые объединены в этот объект данных LdmRoadworks. Ссылка содержит LDMrecordID записи ЛДК, имеющей исходный ОД ЛДК

Объект LdmSituation содержит подробную информацию о ситуации, включая причину и следствие дорожных работ. Коды причин и вспомогательных причин, а также оценка значимости и вероятности ситуации более подробно описаны в таблице В.2. Ситуация на полосу определена несколькими способами в исходных форматах сообщений и может включать ограничения на полосу, такие как закрытие полосы, ограничение скорости, а также тип ТС или ограничение веса. Информация о рекомендуемых отклонениях также установлена несколькими способами и может быть извлечена из TPEG DiversionAdvice и рекомендованного пути DENM.

Влияние на поток трафика определено в объекте TPEG TrafficFlowEffect и может быть уточнено с помощью атрибутов DATEX II Roadworks, таких как масштабирование, интенсивность движения, мобильность.

Таблица В.2

Атрибуты LdmSituation (пример)

Элемент	Описание
reasonCode (код причины)	Код причины для определения типа дорожных работ, полученный из кода причины объекта данных DATEX II, TPEG-TEC или DENM
subCauseCode (код вспомогательной причины)	Код вспомогательной причины для уточнения типа дорожных работ, полученный из вспомогательной причины, код объекта данных TPEG-TEC или DENM
severity (значимость)	Значимость события, полученного, например, как максимальная значимость объектов DATEX II, TPEGTEC или DENM. Значимость объекта DATEX II также определена воздействием, дорожными работами и типом обслуживания
probabilityOfOccurrence (вероятность возникновения)	Указание вероятности того, что будет зарегистрировано событие, которое может быть получено из probabilityOfOccurrence и состояния объекта DATEX II, а также из протокола DENM

Объект LdmRoadworks не зависит от исходного формата данных и не содержит данных, относящихся к исходным протоколам управления сообщениями или связи. Он не содержит специфических данных DATEX II для contextRecord, таких как VersionTime, CreationTime, FirstSupplierVersionTime и CreationReference, а также источник и конфиденциальность информации DATEX II. Объект данных не содержит специфической информации DENM, например actionID. Прикладной процесс, который объединяет объект DENM в объект LdmRoadworks, может оценить ситуацию события дорожных работ на основе логики операций протокола DENM, таких как управление отрицанием, отменой и интервалом передачи. Объект LdmRoadworks также имеет список ссылок на записи ЛДК трех исходных событий. Это позволяет прикладному процессу извлекать специфическую информацию сообщений из оригинальных источников.

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

Глобальная ЛДК может быть создана в соответствии с несколькими конфигурациями (см. 5.2 и 5.3) с учетом разных станций ИТС (т.е. платформ), таких как персональные устройства, устройства ТС, придорожные единицы и центральные станции. Методы определения местоположения объекта реального мира (например, транспортный затор) зависят от различных факторов, включая: станции ИТС; ресурсы (в частности, наличие и использование карт); ограничения, налагаемые приложениями (например, запрашиваемая точность определения местоположения). Возможны различные методы геолокации информации, в частности угловое местоположение с использованием координат долготы, широты и высоты (например, местоположение GPS), а также такие, как:

• методы ссылки на местоположение, цель которых состоит в том, чтобы однозначно связать код (синонимы);
• метка, ссылка с местоположением.

Эти методы включают в себя:

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

ASN.1, тип LDMarea, указанный в приложении А, поддерживает различные форматы местоположения и позволяет добавлять новые форматы на более позднем этапе.

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

• применимость на международном уровне, а не в отношении конкретной страны;
• поддержка приложений станции ИТС (например, навигация, информация о трафике).

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

• кодирование может начинаться на уровне детализации дорожных объектов (дорожные элементы, POI);
• кодирование не может добавить ошибки к информации;
• кодирование может обеспечить точность, требуемую приложениями;
• кодирование может не увеличивать сложность обработки (например, оно не может увеличивать использование времени центрального процессора и памяти);
• кодирование может позволить ссылаться на те объекты, которые взаимодействуют (например, сохранять топологические ссылки);

Г.3.1 Пространственная привязка по координатам

Схема на рисунке Г.1 представляет геодезическую модель (т.е. местоположения выражены в координатах).

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

Г.3.2 Пространственная привязка по географическим идентификаторам

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

Г.3.3 Линейные ссылки

Линейные ссылки — это механизмы назначения значений переменных атрибутам по длине линейных объектов и линейных элементов (реальный объект, который можно измерить с помощью линейных ссылок). Местоположение может быть указано с учетом линейной привязки (например, с учетом местоположения некоторого придорожного объекта). Данный механизм установления местоположения также применим к определенным событиям, например к аварии, местоположение которой может быть указано в соответствии с конкретным линейным объектом.

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

ССЫЛКИ НА ВРЕМЯ

Е.1 Руководство по заполнению проформы ICS

Е.1.1 Цели и структура

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

• руководство по заполнению формы ICS;
• идентификация реализации;
• глобальное заявление о соответствии.

Е.1.2 Сокращения и условные обозначения

Проформа ICS состоит из информации в табличной форме (см. таблицу Е.1).

Таблица Е.1

Столбец элемента	Столбец элемента содержит число, которое идентифицирует элемент в таблице
Столбец описания элемента	Столбец описания элемента описывает в свободном тексте каждый соответствующий элемент (например, параметры)
Столбец состояния	В столбце состояния использованы следующие обозначения: - m — обязательно (эта возможность должна поддерживаться); - o — необязательно (возможность может либо поддерживаться, либо нет); - n/a — не применимо (в данном контексте невозможно использовать эту возможность); - x — запрещено (исключено) (существует требование не использовать эту возможность в данном контексте); o.i — необязательный параметр (для взаимоисключающих или выбираемых опций из набора); «i» — это целое число, которое идентифицирует уникальную группу связанных необязательных элементов и логику их выбора, которая определяется непосредственно после таблицы; - ci — условный (требование к возможности («m», «o», «x» или «n/a») зависит от поддержки других необязательных или условных элементов. «i» — это строка, содержащая номер соответствующей таблицы, за которой следует порядковый номер, идентифицирующий уникальное выражение условного состояния, которое указывается после номера этой таблицы
Ссылочный столбец	Ссылка на настоящий стандарт, за исключением тех случаев, когда указано иное
Столбец поддержки	Столбец поддержки заполняется поставщиком реализации. Используют следующие общие обозначения для столбца поддержки: - Y или y, поддерживаемые при реализации; - № или n, не поддерживаемые при реализации; - Н/Д, н/д или ответ не требуется (допускается, только если статус «н/д», непосредственно или после оценки условного статуса)
Столбец допустимых значений	Столбец допустимых значений содержит тип, список, диапазон или допустимую длину значений. Используют следующие обозначения: - диапазон значений: <минимальное значение> .. <максимальное значение> - список значений: , , ..., - список именованных значений: (), (), ..., () - длина: размер (<минимальный размер> .. <максимальный размер>)
Столбец элемента	Столбец элемента содержит число, которое идентифицирует элемент в таблице
Столбец поддерживаемых значений	Столбец поддерживаемых значений заполняется поставщиком реализации. В этом столбце должны быть указаны значения или диапазоны значений, поддерживаемые реализацией
Ссылки на элементы	Для каждого возможного ответа элемента (ответ в столбце поддержки) в пределах формы ICS существует уникальная ссылка, используемая, например, в условных выражениях. Ссылка определяется как идентификатор таблицы, за которым следует символ «/», за ним — номер элемента в таблице. Если в таблице, определяемой уникальной ссылкой, имеется более одного вспомогательного столбца, столбцы различают по буквам (a, b и т.д.) соответственно
Строка предварительных требований	Строка предварительного условия принимает следующую форму: предварительное условие: <предикат>. Обязательная строка после предложения или заголовка таблицы указывает, что не требуется заполнять весь пункт или всю таблицу, если предикатом является false

Е.1.3 Инструкции по заполнению проформы ICS

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

Е.2 Идентификация реализации

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

Все ли обязательные возможности реализованы? (Да/нет)

Примечание - Ответ «Нет» на этот вопрос указывает на несоответствие спецификации реализации. Неподдерживаемые обязательные возможности должны быть идентифицированы в ИТС.

Е.5 Подробные заявления о соответствии

Элемент	Поддерживаемый тип модуля станции ИТС	Ссылка	Статус	Поддержка
1	Одиночный модуль станции ИТС	7.5.2	o.1	-
2	Несколько модулей связи станции ИТС	7.5.2	o.1	-
3	Неактивные области хранилища данных ЛДК	7.2.1	o	-
4	Поддержка SAP	7.4	cF.101	-

Элемент	Поддерживаемые процедуры	Ссылка	Состояние	Поддержка
1	Регистрация прикладных процессов станции ИТС	7.1.1	m	-
2	Отмена регистрации прикладных процессов станции ИТС	7.1.1	m	-
3	Отзыв прикладных процессов станции ИТС	7.1.1	m	-
4	Проверка безопасности в запросах на доступ	7.1.2	m	-
5	Проверка полномочий и достоверности	7.1.3.1	m	-
6	Добавление записи данных ЛДК	7.1.3.2	m	-
7	Обновление записи данных ЛДК	7.1.3.3	m	-
8	Удаление записи данных ЛДК	7.1.3.4	m	-
9	Запрос ОД ЛДК	7.1.3.5	m	-
10	Подписаться на обновления ОД ЛДК	7.1.3.6	m	-
11	Отписаться от обновления ОД ЛДК	7.1.3.7	m	-
12	Уведомление об обновлениях ОД ЛДК	7.1.3.8	m	-
13	Фильтрация второго уровня	7.1.4	o	-

Е.5.3 Процедуры управления (см. таблицу Е.4)

Таблица Е.4

Элемент	Поддерживаемые процедуры	Ссылка	Состояние	Поддержка
1	Управление областью	7.2.1	cF.301	-
2	Удаление устаревших данных	7.2.2	m	-
3	Регистрация ЛДК в модуле управления станцией ИТС	7.5.1	m	-

Поддерживаемые формат и кодировка

Элемент	Поддерживаемые формат и кодировка	Ссылка	Состояние	Поддержка
1	Модуль ASN.1 CITSldm	По А.1 приложения А	m	-
2	Правила кодирования невыровненных пакетов	По А.2 приложения А	cF.401	-

Элемент	Поддерживаемые элементы	Ссылка	Состояние	Поддержка
1	Идентификатор типа объекта данных ЛДК (тип ASN.1 LDMdataObjectTypeID)	По приложению Б	m	-
2	Идентификатор типа атрибута данных ЛДК (тип ASN.1 LDMattributeID)	-	-	-
3	Формат ОД ЛДК (тип ASN.1 LDMdataObject)	По приложению Б	m	-
4	Общий подход для определения нового ОД ЛДК, например, тип ASN.1 AnotherLdmDataObject	По приложению Б	m	-

БИБЛИОГРАФИЯ

[1]	ISO 18750:2018 Intelligent transport systems — Cooperative ITS: Local dynamic map

УДК 656.035.21:006.354	ОКС 03.220.20
Ключевые слова: интеллектуальная транспортная система, локальная динамическая карта, динамический объект, транспортные средства, услуги

---