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

ПНСТ 634-2022

ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Интеллектуальные транспортные системы

КООПЕРАТИВНЫЕ ИНТЕЛЛЕКТУАЛЬНЫЕ ТРАНСПОРТНЫЕ СИСТЕМЫ

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

Intelligent transport systems. Cooperative ITS. Local Dynamic Map

ОКС 03.220.20

Срок действия с 2022-08-01

до 2025-08-01

Предисловие

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

(Поправка. ИУС N 7-2022).

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

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 1 февраля 2022 г. N 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)

ВНЕСЕНА поправка, опубликованная в ИУС N 7, 2022 год, введенная в действие с 29.05.2022

Введение

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

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

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

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

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

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

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

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.

Рисунок 1 - Локальная динамическая карта в станции ИТС, функционирующая как ограниченный защищенный управляемый домен

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

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

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

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

На рисунке 3 показана конфигурация одного блока станции ИТС с двумя ЛДК.

Рисунок 3 - Реализация конфигурации одного блока станции ИТС с двумя ЛДК

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

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

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

Рисунок 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, тип Timelnformation.

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

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 - Элементы записи данных локальной динамической карты

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.2);

- обновление записи данных ЛДК (см. 6.4.3.3);

- удаление записи данных ЛДК (см. 6.4.3.4);

- запрос ОД ЛДК (см. 6.4.3.5);

- подписку (см. 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, тип LDMrecordlD. Нормативная спецификация соответствующей процедуры представлена в 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 - Параметры интерфейсных функций

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

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

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

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

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

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

2) идентификатор ЛДК - TnnASN.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, тип Location Validity,

5) срок действия - ASN.1, тип ValidityTimelnterval,

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, тип ValidityTimelnterval,

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, тип LDMdataObjectTypelD,

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

7) время интереса ЛДК - ASN.1, тип TimeOflnterest,

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

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, тип LDMdataObjectTypelD,

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

7) время интереса ЛДК - ASN.1, тип TimeOflnterest,

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

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

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

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

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

Таблица 5 - Функции, используемые в SF-COMMAND.confirm

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

Таблица 6 - Функции, используемые в сервисе SF-REQUEST

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

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

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, тип L DM update Request (см. 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 - CITSIdm2 {ISO (1) standard (0) cits-ldm (18750) asnm-1 (1) version2 (2)}. Спецификации ASN.1, приведенные в данном приложении, имеют преобладающее значение над спецификациями, представленными в настоящем стандарте.

А.2 Модуль CITSIdm

Правила невыровненного упакованного кодирования (PER), как указано в ГОСТ Р ИСО/МЭК 8825-2, применяют к модулю ASN.1 CITSIdm2 в том случае, если элементы данных и элементы значений используют в примитивах обслуживания SAP модуля станции ИТС. Правила кодирования, применяемые в других целях, выходят за рамки настоящего стандарта.

CITSIdm2 {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) versionl (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 AreaOflnterest::=LDMarea

- - LDM Authorzations / permissions

LDMpermissionList::=SEQUENCE OF LDMpermission

LDMpermission::=LDMdataObjectTypelD

- - 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 LDMrecordlD::=INTEGER{

IdmRecordlDunknown (0)} - - value zero is reserved for the unknown record.

- - LDM Data Dictionary

DataDictionarylD::=INTEGER{

ddlD-LDMdd(1) - - LDM-DD

} - - needs to be maintained in a registry

LDMDATADICTIONARY::=CLASS {

&ref LDMdataObjectTypelD UNIQUE,

&Value

}

LDMdataObjectTypelD::=INTEGER{

unknown (0)

} (0..MAX)

- - 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 LDMdataObjectTypelD::=0

LDMdataObject::=SEQUENCE{

ldmdotRef LDMDATADICTIONARY.&ref({LDMdataObjectTypes}),

IDMdataObType LDMDATADICTIONARY.&Value ({LDMdataObjectTypes} {@IdmdotRef})

}

- - The set of LDM Data Objects

LDMdataObjectTypes LDMDATADICTIONARY::={

/* IdmdoAnotherLdmDataObject | */

IdmdoNull , ...}

IdmdoNull 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 encoded, i.e. specified with ASN.1 type CLASS - one CLASS per LDM Data Object Type. In the examples below the terms AnotherLdmDataObject/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 LDMdataObjectTypelD::=65535

- - Example on how to identify the instantiation of AnotherLdmDataObject IdmdoAnotherLdmDataObject 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{

ldmDoAttRefANOTHERLDMOBJECTCLASS.&ref({AnotherLDMdataObjectAttributes}),

ldmDoAttANOTHERLDMOBJECTCLASS.&Value({AnotherLDMdataObjectAttributes}{@ldmDoAttRef})

}

- - Example of the set of all LDM DO Attributes for AnotherLdmDataObject AnotherLDMdataObjectAttributes ANOTHERLDMOBJECTCLASS::={ldmDoAtTy0 | IdmDoAtTyl | ldmDoAtTy2, ...}

- - as example an empty / unknown LDM Attribute

IdmDoAtTyO ANOTHERLDMOBJECTCLASS::={&ref 0, &Value NullType} IdmDoAtTyl ANOTHERLDMOBJECTCLASS::={&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

SubscriptionlD::=lnt2

- - 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 ValidityTimelnterval, - - LDM internal format

original ValidityTimelnterval, - - Original format presented at time of writing requested ValidityTimelnterval - - Format requested

}

LDMinterfaceRecords::=SEQUENCE OF LDMinterfaceRecordRead

- - end of Interface parameters

- - interface functions

- - Registration / deregistration / revocation

LDMregisterRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmlDLDMid,

priority UserPriority

permissions LDMpermissionList,

secCredentials LDMsecurityCredential

}

LDMregisterConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid, - - set to the value of the LDM that confirms

permissions LDMpermissionList,

result ResultCode

}

LDMderegisterRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmlDLDMid

}

LDMderegisterConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid, - - set to the value of the LDM that confirms

result ResultCode

}

LDMrevokeAppNotifyRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

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

IdmID LDMid,

result ResultCode

}

- - Data providers

LDMaddRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

data LDMdataObject, - - type and data

geoRef LDMarea, - - Location Validity / reference

timeRef ValidityTimelnterval, - - Time Validity / reference

genTime Timelnformation, - - time of generation

timeMandDelete Timelnformation - - if time provided, then privacy flag = true

}

LDMaddConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

IdmRecordID LDMrecordID,

result ResultCode

}

LDMupdateRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

IdmRecordID LDMrecordID,

data LDMdataObject, - -type and data

geoRef LDMarea, - - Location Validity / reference

timeRef Validity Timelnterval, - - Time Validity / reference

genTime Timelnformation, - - time of generation

timeDelete Timelnformation - - if time provided, then privacy flag = true

}

LDMupdateConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

IdmRecordID LDMrecordID,

result ResultCode

}

LDMdeleteRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

IdmRecordID LDMrecordID

}

LDMdeleteConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

IdmRecordID LDMrecordID,

result ResultCode

}

- - Data users

LDMsubscribeRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

priority UserPriority

IdmRecordID LDMrecordID,

IdmDoTypelD LDMdataObjectTypelD,

arealnterest AreaOflnterest,

timelnterest TimeOflnterest,

agelnterest AgeOflnterest,

filter FilterSecondLevel,

notifyInterval NotificationInterval,

notifyUpdate NotificationUponUpdate

}

- - Flag for notification upon update

NotificationUponUpdate: :=Flag

LDMsubscribeConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

subscribelD SubscriptionID,

result ResultCode

}

LDMunsubscribeRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

priority UserPriority,

subscribelD SubscriptionID

}

LDMunsubscribeConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

subscribelD SubscriptionID,

result ResultCode

}

LDMqueryRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

priority UserPriority,

IdmRecordID LDMrecordID,

IdmDoTypelD LDMdataObjectTypelD,

arealnterest AreaOflnterest,

timelnterest TimeOflnterest,

agelnterest AgeOflnterest,

filter FilterSecondLevel

}

LDMqueryConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

IdmData LDMinterfaceRecords,

result ResultCode

}

LDMnotifyRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

subscribelD SubscriptionID,

IdmData LDMinterfaceRecords

}

LDMnotifyConfirm::=NullType

- - Security entity

LDMcheckAuthorizationRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

priority UserPriority,

permissions LDMpermissionList,

secCredentials LDMsecurityCredential

}

LDMcheckAuthorizationConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

priorityConf UserPriority,

permissionsConf LDMpermissionList,

result ResultCode

}

LDMrevokeAuthorizationRequest::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

priorityRemain UserPriority

permissionsRemain LDMpermissionList

}

LDMrevokeAuthorizationConfirm::=SEQUENCE{

itssAppProcess ITSsapiid,

IdmID LDMid,

result ResultCode

}

- - Management entity

- - Register LDM at management

LDMregisterManagementRequest::=SEQUENCE{

IdmID LDMid, - - assigned at time of implementation of LDM

IdmDTs ListOfLDMDTids,

IdmCapabilities LDMcapabilities

}

ListOfLDMDTids::=SEQUENCE OF LDMdataObjectTypelD

LDMcapabilities::=INTEGER{

basic (0),

electronicHorizon (1),

secondLevelFiltering (2)

} (0..255) - - used as a bit field indicating up to eight features

LDMregisterManagementConfirm::=SEQUENCE{

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

geoCoordinatesGEOCOORD.&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-TimelnfoLDM,

&Value

}

Ref-TimelnfoLDM::=INTEGER{

c-LDM-noTimelnfo (0),

c-LDM-Time48IAT (1),

c-LDM-doubleTime48IAT (2)

} (0..255)

Timelnformation::=SEQUENCE{

timeRefTIMEINFO.&ref({Timelnfos}),

timelnfoTIMEINFO.&Value({Timelnfos}{@timeRef})

}

Timelnfos TIMEINFO::={noTimelnfo | time48IAT | doubleTime48IAT, ...}

noTimelnfo TIMEINFO::={&ref c-LDM-noTimelnfo, &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::=Timelnformation

- - Time relative to time of generation

AgeOflnterest::=SEQUENCE{

operator Operators, - - e.g. <time of birth> "It" timeReference

timeReference Timelnformation

}

- - Time of interest (select either no info or a single info)

TimeOflnterest::=Timelnformation

- - Validity time interval(s)

ValidityTimelnterval::=SEQUENCE (SIZE(0..255)) OF Timelnformation - - start/stop types only

- - Time definitions based on International Atomic Time

TimeOfCreation::=SEQUENCE{

timeAdd Time48IAT,

timeLastllpdate Time48IAT

}

TimeOfMandatoryDeletion::=Timelnformation

TimeOfDeletion::=Time48IAT

- - Time interval between subsequent notifications

Notificationlnterval::=lnt2 --time span in milliseconds

- - Filter mechanism

Operators::=INTEGER{

equal (0),

notequal (1),

gt (2),

It (3),

gte (4),

Ite (5),

like (6),

notlike (7)

} (0..255) - - End of Operators

FilterSecondLevel::=ANDsequence

ANDsequence::=SEQUENCE OF ORsequence

ORsequence::=SEQUENCE OF FilterPrimitive

FilterPrimitive::=SEQUENCE{

IdmAttributelD LDMattributeID,

operator Operators, refValue OCTET STRING - - to be converted into format given by IdmAttributelD }

LDMattributelD::=INTEGER

- - Utility types definitions

lnt1::=INTEGER(0..255)

lnt2::=INTEGER(0..65535)

lnt4::=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, LDMsubscribeRequest, LDMunsubscribeRequest, LDMqueryRequest, LDMregisterConfirm, LDMderegisterConfirm, LDMDubMirFM-MMDMConfirmMBMDMConfirmMid

LDMqueryConfirm FROM CITSIdm2 {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} IdmAdd MFSAP-CR::={&mxref c-ldmAddMF, &MXParam LDMaddRequest} IdmUpdate MFSAP-CR::={&mxref c-ldmUpdateMF, &MXParam LDMupdateRequest} IdmDelete MF-SAP-CR::={&mxref c-ldmDeleteMF, &MXParam LDMdeleteRequest} IdmSubscribe MFSAP-CR::={&mxref c-ldmSub-scribeMF, &MXParam LDMsubscribeRequest} IdmUnsubscribe MFSAP-CR::={&mxref c-ldmUnsubscribeMF, &MXParam LDMunsubscribeRequest} IdmQuery MFSAP-CR::={&mxref c-ldmQueryMF, &MXParam LDMqueryRequest}

Будет добавлено к MF-CmdConfirm:

To be added to MF-CmdConfirm: IdmRegisterConf MFSAP-CC::={&mxref c-ldmRegisterMF, &MXParam LDMregisterConfirm} IdmDeregisterConf MFSAP-CC::={&mxref c-ldmDeregisterMF, &MXParam LDMderegisterConfirm} IdmAddConf MFSAP-CC::={&mxref c-ldmAddMF, &MXParam LDMaddConfirm} IdmUpdateConf MFSAP-CC::={&mxref c-ldmUpdateMF, &MXParam LDMupdateConfirm} IdmDeleteConf MFSAP-CC::={&mxref c-ldmDeleteMF, &MXParam LDMdeleteConfirm} IdmSubscribeConf MFSAP-CC::={&mxref c-ldmSubscribeMF, &MXParam LDMsubscribeConfirm} IdmUnsubscribeConf MFSAP-CC::={&mxref c-ldmUnsubscribeMF, &MXParam LDMunsubscribeConfirm} IdmQueryConf MFSAP-CC::={&mxref c-ldmQueryMF, &MXParam LDMqueryConfirm}

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

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 CITSIdm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

Будет добавлено к MF-Request: IdmRevokeAppNotify MFSAP-RR::={&mxref c-ldmRevokeAppNotify, &MXParam LDM-revokeAppNotifyRequest} IdmNotify MFSAP-RR::={&mxref c-ldmNotify, &MXParam LDMnotifyRequest} IdmRegisterManagement MFSAP-RR::={&mxref c-ldmRegisterManagement, &MXParam LDMregisterManagementRequest}

Будет добавлено к MF-ReqConfirm: IdmRevokeAppNotifyConf MFSAP-RC::={&mxref c-ldmRevokeAppNotify, &MX-Param LDMrevokeAppNotifyConfirm} - не используется

IdmNotifyConf MFSAP-RC::={&mxref c-ldmNotify, &MXParam LDMnotifyConfirm} - не используется

IdmRegisterManagementConf MFSAP-RC::={&mxref c-ldmRegisterManagement, &MXParam LDMregisterManagementConfirm}- не используется

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

c-ldmRevokeAppNotify RefMFSAP-R ::= <’i’ tbd>

c-ldmNotify RefMFSAP-R ::= <’j’ tbd>

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

А.3.4 Функция FA-SAP

Применимый модуль 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 CITSIdm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

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

IdmRegisterFA FASAPDOWN::={&primitiveRef c-ldmRegisterFA, &Primitive LDMregisterRequest} IdmDeregisterFA FASAPDOWN::={&primitiveRef c-ldmDeregisterFA, &Primitive LDMderegisterRequest} IdmAddFA FASAPDOWN::={&primitiveRef c-ldmAddFA, &Primitive LDMaddRequest} IdmUpdateFA FASAPDOWN::={&primitiveRef c-ldmUpdateFA, &Primitive LDMupdateRequest} ldmDeleteFA FASAPDOWN::={&primitiveRef c-ldmDeleteFA, &Primitive LDMdeleteRequest} IdmSubscribeFA FASAPDOWN::={&primitiveRef c-ldmSubscribeFA, &Primitive LDMsubscribeRequest} IdmUnsubscribeFA FASAPDOWN::={&primitiveRef c-ldmUnsubscribeFA, &Primitive LDMunsubscribeRequest} Id-mQueryFA FASAPDOWN::={&primitiveRef c-ldmQueryFA, &Primitive LDMqueryRequest} IdmRevokeAppNotifyConfFA FASAPDOWN::={&primitiveRef c-ldmRevokeAppNotifyFA, &Primitive LDMrevokeAppNotifyConfirm} IdmNotifyConfFA FASAPDOWN::={&primitiveRef c-ldmNotifyFA, SPrimitive LDMnotifyConfirm} IdmRegisterManagementConfFA FASAPDOWN::={&primitiveRef c-ldmRegisterManagementFA, &Primitive LDMregisterManagementConfirm} To be added to FAsapspsup: IdmRegisterConfFA FASAPUP::={&primitiveRef c-ldmRegisterFA, &Primitive LDMregisterConfirm} IdmDeregisterConfFA FASAPUP::={&primitiveRef c-ldmDeregisterFA, &Primitive LDMderegisterConfirm} IdmAddConfFA FASAPUP::={&primitiveRef c-ldmAddFA, &Primitive LDMaddConfirm} ldmUpdateConfFAFASAPUP::={&primitiveRefc-ld-mUpdateFA, &Primitive LDMupdateConfirm} ldmDeleteConfFAFASAPUP::={&primitiveRef c-ldmDeleteFA, &Primitive LDMdeleteConfirm} IdmSubscribeConfFA FASAPUP::={&primitiveRef c-ldmSubscribeFA, &Primitive LDMsubscribeConfirm} IdmUnsubscribeConfFA FASAPUP::={&primitiveRef c-ldmUnsubscribeFA, &Primitive LDMunsubscribeConfirm}

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

IdmRegisterConfFA FASAPUP::={&primitiveRef c-ldmRegisterFA, &Primitive LDMregisterConfirm} IdmDeregisterConfFA FASAPUP::={&primitiveRef c-ldmDeregisterFA, &Primitive LDMderegisterConfirm} IdmAddConfFA FASAPUP::={&primitiveRef c-ldmAddFA, &Primitive LDMaddConfirm} IdmUpdateConfFA FASAPUP::={&primitiveRef c-ldmUpdateFA, &Primitive LDMupdateConfirm} IdmDeleteConfFA FASAPUP::={&primitiveRef c-ldmDeleteFA, &Primitive LDMdeleteConfirm} IdmSubscribeConfFA FASAPUP::={&primitiveRef c-ldmSubscribeFA, &Primitive LDMsubscribeConfirm} IdmUnsubscribeConfFA FASAPUP::={&primitiveRef c-ldmUnsubscribeFA, &Primitive LDMunsubscribeConfirm}

IdmQueryConfFA FASAPUP::={&primitiveRef c-ldmQueryFA, &Primitive LDMqueryConfirm} IdmRevokeAppNotifyFA FASAPUP::={&primitiveRef с-ldmRevokeAppNotifyFA, &Primitive LDMrevokeAppNotifyRequest} IdmNotifyFA FASAPUP::={&primitiveRef c-ldmNotifyFA, &Primitive LDMnotifyRequest}ldmRegisterManagementFA FASAPUP::={&prim-itiveRef c-ldmRegisterManagementFA, &Primitive LDMregisterManagementRequest}

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

c-ldmRegisterFA RefFASAP ::=<’a’ tbd>

c-ldmDeregisterFA RefFASAP ::=<’b’ tbd>

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 CITSIdm2 {iso(1) standard(0) cits-ldm (18750) asnm-1(1) version2 (2)}

Будет добавлено к SF-Command: IdmRevokeAuthorization SFSAP-CR::={&mxref

c-ldmRevoceAuthorizationSF, &MXParam LDMrevokeAuthorizationRequest}

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

IdmRevokeAuthorizationConf SFSAP-CC::={&mxref c-ldmRevoceAuthorizationSF, &MXParam LDMrevokeAuthorizationConfirm}

Работа над нижеприведенными определениями значений ASN.1 (значения ’I’) будет завершена рабочей группой WG16 ISO ТС204, результат которой будет опубликован в соответствующем реестре.

c-ldmRevoceAuthorizationSF RefSFSAP-C::=<’l’ tbd>

А.3.6 SF-Request

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

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

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

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

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

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

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

Работа над приведенными определениями значений ASN.1 (values ’m’) будет завершена рабочей группой WG16 ISO ТС204, результат которой будет опубликован в соответствующем реестре.

c-ldmCheckAuthorizationSF RefSFSAP-R::=<’m’ tbd>

Приложение Б

(обязательное)

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

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

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

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

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

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

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

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

Содержимое, идентифицированное этим двумерным адресным пространством, не рассматривается в настоящем стандарте. Словарь данных ЛДК поддерживается посредством общедоступного реестра.

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

- создать впоследствии глобальный словарь данных ЛДК в соответствии с потребностями рынка;

- использовать подмножества глобального словаря данных ЛДК или всего словаря данных ЛДК в реализациях;

- учитывать существующие словари данных.

Рисунок Б.1 - Концепция словаря данных ЛДК

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

- впоследствии создать глобальный словарь данных ЛДК в соответствии с потребностями рынка;

- использовать подмножества глобального словаря данных ЛДК или всего словаря данных ЛДК в реализациях;

- рассматривать существующие словари данных, выполнив соответствующее преобразование в элементы глобального словаря данных ЛДК;

- использовать существующие источники информации (DATEX, JPEG, RDS-TMC, ...) без необходимости что-либо изменять в этих устаревших спецификациях;

- использовать для КИТС источники информации (CEN/ISO, ETSI, SAE);

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

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

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

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

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

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

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

Приложение В

(справочное)

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

В.1 Модуль станции ИТС может получать данные из различных источников и с разными форматами, указанными в различных словарях данных. Эти словари либо уже существуют (например, DATEX II, TPEG), либо предназначены для КИТС, либо в настоящее время разрабатываются. Примерами таких словарей являются SPaT, IVI, САМ, 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;

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

- эмитент из атрибутов SituationRecord.

Время генерации определено временем наблюдения situationrecord.

Рисунок В.1 - Пример объекта данных дорожных работ в разделе события словаря DATEX II

В.2.2 TPEG-TEC

Словарь данных TPEG поддерживает информацию о дорожном движении, об участниках дорожного движения, о необходимой информации о дорожно-транспортном потоке, препятствиях или местных опасностях. Данные о дорожном движении могут быть предоставлены в виде сообщений о дорожном движении с использованием формата TPEG-RTM (Road Traffic Message) или TPEG-TEC (Traffic Event Comact). Такие сообщения транслируются, например, через ТМС, DAB (Digital Audio Broadcast) или DVB (Digital Video Broadcasting) и могут быть приняты в блоке станции ИТС, реализующем соответствующие технологии доступа. Сообщение TPEG-TEC добавляет информацию о дорожных работах в качестве части описательной информации информационных потоков. Пример объекта данных дорожных работ в событии TPEG-TEC представлен на рисунке В.2. Дорожные работы рассматривают как прямые и связанные причины возникновения дорожно-транспортного происшествия. Классификация вида дорожных работ обеспечена кодом причины и кодом подкласса.

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

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

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

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

- временная валидность из атрибутов startTime и stopTime;

- эмитент должен быть принят от отправителя сообщения;

- время генерации должно быть принято от заголовка сообщения TPEG-TEC.

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

В.2.3 Сообщение DENM

Распределенное сообщение с уведомлением об окружающей среде DENM может передаваться между транспортными средствами и блоками станции ИТС на стороне дороги для того, чтобы информировать пользователей дороги о дорожных работах. DENM состоит из нескольких контейнеров. Контейнер управления однозначно идентифицирует событие и отправителя в actionlD. Информация о времени предоставляется для первого обнаружения и продолжительности события предупреждения о дорожных работах и генерации сообщения. Контейнер ситуаций определяет ситуацию с трафиком аналогично информации TPEG-TEC. Коды причины и подосновы заимствованы из кодов TPEG-TEC. Данная причина позволяет связать эту дорожную работу с другими событиями, что в некоторой степени связано с комбинацией ситуационных записей в DATEX II. Информация о местоположении дорожных работ обеспечивается глобальной информацией о местоположении и релевантности в ManagementContainer и в LocationContainer. Данная информация определяет ту область и то направление движения, о которых должен быть предупрежден водитель. EventSpeed устанавливает, является ли дорога работоспособной (см. DATEX II и TPEG-TEC). Следует обращать внимание на то, что позиционирование событий DENM отличается от ссылок на местоположения в DATEX II и TPEG-TEC.

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

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

- действительное местоположение из атрибутов eventPosition и релевантности и из атрибутов LocationContainer;

- действительное время из атрибута validityDuration;

- эмитент из идентификатора станции-отправителя из атрибута actionlD.

Время генерации определено из referenceTime.

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

В.2.4 Объект данных L DM Roadworks

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

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

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

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

Таблица В.1 - Атрибуты LdmRoadworks (пример)

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

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

Таблица В.2 - Атрибуты LdmSituation (пример)

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

Приложение Г

(справочное)

Ссылки на местоположение

Г.1 Введение

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

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

- метка, ссылка с местоположением.

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

- предварительное кодирование указателей местоположения (они являются частью дорожной сети);

- динамические подходы, которые выполняют кодирование "на лету". Процедуры включают создание кода по требованию (коды удаляют после использования).

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

Г.2 Ссылка на местоположение

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

- объект реального мира, который связан с транспортной сетью;

- применимость на международном уровне, а не в отношении конкретной страны;

- поддержка приложений станции ИТС (например, навигация, информация о трафике).

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

- кодирование может начинаться на уровне детализации дорожных объектов (дорожные элементы, POI);

- кодирование не может добавить ошибки к информации;

- кодирование может обеспечить точность, требуемую приложениями;

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

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

- кодирование может сохранить отношения между объектами.

Г.3 Методы, основанные на географической информации

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

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

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

Рисунок Г.1 - Координатная ссылочная система

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

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

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

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

Приложение Д

(справочное)

Ссылки на время

Системы привязки времени (форматы времени) необходимы для эффективной поддержки различных приложений ИТС. Информация о времени типа ASN.1, указанная в приложении А, поддерживает разные форматы времени и позволяет добавлять новые форматы на более позднем этапе. Формат IAT ASN.1 - Time48IAT. Этот формат времени используют в качестве основного формата в модуле станции ИТС. На основе данного формата могут быть определены временные интервалы. Относительные единицы времени предпочтительнее устанавливать, применяя единицу времени IAT, которая составляет 1 мс. Преимущество IAT по сравнению с UTC (см. ГОСТ Р 7.0.64) состоит в том, что IAT заботится о високосных секундах. Абстрактный формат времени может использовать обозначения года, месяца, дня в месяце, часа дня, минуты часа, секунды минуты, миллисекунды секунды. Определение абстрактных форматов времени выходит за рамки настоящего стандарта.

Приложение Е

(обязательное)

Проформа заявления о соответствии реализации

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

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

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

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

- идентификация реализации;

- глобальное заявление о соответствии.

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

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

Таблица Е.1

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

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

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

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

Е.2.1 Дата заявления

Е.2.2 Идентификация IUT

Наименование тестируемой реализации (IUT):

Версия IUT:

Е.2.3 Идентификация SUT

Название тестируемой системы (SUT):

Конфигурация оборудования:

Операционная система:

Е.2.4 Наименование поставщика продукта

Адрес:

Номер телефона:

Номер факсимильного аппарата:

Адрес электронной почты:

Дополнительная информация:

Е.2.5 Имя клиента

Адрес:

Номер телефона:

Номер факса:

Адрес электронной почты:

Дополнительная информация:

Е.2.6 Контактное лицо ICS

Имя:

Номер телефона:

Номер факса:

Адрес электронной почты:

Дополнительная информация:

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

Примечание - Данная форма ICS применяется к [1].

Е.4 Глобальное заявление о соответствии

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

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

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

Е.5.1 Выбор конструкции (см. таблицу Е.2)

Таблица Е.2 - Выбор конструкции

o.1: Обязательно поддерживать минимум один из этих пунктов.

cF.101: IFF.1 /2THEN m ELSE 0

Е.5.2 Процедуры, связанные с прикладными процессами станции ИТС (см. таблицу Е.3)

Таблица Е.3 - Поддерживаемые процедуры прикладных процессов станции ИТС

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

Таблица Е.4 - Поддерживаемые процедуры управления

Е.5.4 Формат и кодировка (см. таблицу Е.5)

Таблица Е.5 - Поддерживаемые формат и кодировка

cF.401: IF(F.1/2 OR F.1/4) THEN m ELSE о

Е.5.5 Словарь данных локальной динамической карты (см. таблицу Е.6)

Таблица Е.6 - Поддерживаемые элементы словаря данных ЛДК

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