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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ПРЕДВАРИТЕЛЬНЫЙ

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

ОПРЕДЕЛЕНИЕ СТАНДАРТИЗОВАННОГО НАБОРА ПРОТОКОЛОВ, ПАРАМЕТРОВ, МЕТОДА УПРАВЛЕНИЯ ОБНОВЛЯЕМЫМ

РЕЕСТРОМ ДАННЫХ ДЛЯ ОБЕСПЕЧЕНИЯ ПЕРЕДАЧИ СООБЩЕНИЙ, КАСАЮЩИХСЯ БЕЗОПАСНОСТИ И ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЙ

Издание официальное

Москва

Стандартимформ

2019

ЛИСТ 340—-2018

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «ТранснавиСофт» (ООО «Транс-нави Софт»)

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

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

4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО 24978—2009 «Интеллектуальные транспортные системы. Безопасность ИТС и сообщения об авариях с использованием любой наличной беспроводной среды. Процедуры регистрации данных» (ISO 24978:2009 «Intelligent transport systems — ITS Safety and emergency messages using any available wireless media — Data registry procedures». NEQ)

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

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

© Стацдартинформ. оформление. 2019

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

Содержание

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

2 Соответствие........................................................................1

3 Нормативные ссылки........................... 1

4 Термины и определения...............................................................2

5 Сокращения.........................................................................2

6 Требования к процедурам регистрации данных и управлению обновляемым реестром данных .... 3

6.1 Формат использования.............................................................3

6.2 Общие положения................................................................3

6.3 Структура.......................................................................3

6.4 Организационная структура........................................................5

6.5 Уровни статуса регистрации данных..................................................6

6.6 Процедуры регистрации данных.....................................................7

6.7 Контроль версий..................................................................8

6.8 Общие положения для определения концепций данных.................................8

6.9 Диалоговый интерфейс...........................................................10

6.10 Сообщение....................................................................10

6.11 Таблица данных................................................................10

6.12 Класс объекта..................................................................10

6.13 Соотношение данных............................................................10

6.14 Свойство......................................................................11

6.15 Понятие элемента данных........................................................11

6.16 Область значений...............................................................11

6.17 Элемент данных................................................................11

7 Метаатрибуты представления данных для обеспечения передачи сообщений.

касающихся безопасности и чрезвычайных ситуаций......................................11

7.1 Основные метаатрибуты понятий данных............................................11

7.2 Административные метаатрибуты..................................................13

8 Концепции данных обновляемого реестра данных........................................13

8.1 «Описательные имена»...........................................................13

8.2 Форматы данных описательных имен................................................14

9 Требования к метаатрибутам представления данных для обеспечения передачи сообщений,

касающихся безопасности и чрезвычайных ситуаций......................................14

10 Международные отношения..........................................................14

11 Конфиденциальность...............................................................14

Приложение А (справочное) Функциональные операционные процедуры регистрации данных

для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций..................................................15

Приложение Б (обязательное) Определения метаатрибутов..................................27

Приложение В (обязательное) Требования к метаатрибутам для концепций данных..............35

Приложение Г (обязательное) Определение стандартизованного набора протоколов

для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций..................................................43

Приложение Д (справочное) Спецификация информационных объектов ASN.1. используемых

для формирования и регистрации данных....................................54

Приложение Е (обязательное) Спецификация концепции данных ASN.1........................65

Приложение Ж (обязательное) Представление данных в информационной модели..............69

Приложение И (справочное) Международные и региональные уровни формирования данных......72

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

ЛИСТ 340—2018

Введение

Одной из серьезнейших проблем мирового масштаба является большое количество погибших и получивших травмы на дорогах. В России количество погибших на дорогах остается на очень высоком уровне: смертность на дорогах, согласно статистическим данным на 2018 г., выше, чем в странах Ев» ропы. в три раза. По данным ГИБДД. 2017 г. в стране погибли 19 тыс. и травмированы более 215 тыс. человек. Несмотря на устойчивую положительную динамику на фоне профилактических работ: количество погибших в дорожно-транспортных происшествиях (ДТП) сократилось на треть, раненых — на 17 %. требуется принятие дополнительных мер воздействия на ключевые факторы аварийности.

В настоящее время разрабатывается ряд интеллектуальных транспортных систем (ИТС). систем обеспечения безопасности дорожного движения, таких как системы экстренного оповещения и оказания помощи при ДТП eSafety. eCatl. Одной из основных задач данных систем является автоматическое предоставления единого минимального набора данных (minimum set of data. MSD) службам спасения и экстренного реагирования при возникновении аварий и чрезвычайных ситуаций (ЧС) на дорогах.

Доступная информация может варьироваться в зависимости от модели транспортного средства (ТС), в соответствии со стратегией производителя ТС и. безусловно, будет изменяться с течением времени.

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

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

Для четкой работы автоматизированных систем предотвращения столкновений ТС или других автоматизированных подсистем ИТС. обеспечивающих безопасность дорожного движения, должны действовать следующие технологии обмена данными: «автомобиль — автомобиль» (vehicle-to-vehicle. V2V). «инфраструктура — автомобиль» (infrastructure-to-vehicle. I2V). «автомобиль — инфраструктура» {vehicle-to-inffastructure, V2I), «автомобиль — пешеход» (vehicle-to-pedestrian, V2P). а также «автомобиль — электросеть» (vehicle-to-grid, V2G). «автомобиль — электронное устройство» (vehide-to-device. V2D) и. наконец, «автомобиль — любой объект» (vehicle-to-everything. V2X). В целом крайне важно, чтобы форматы обмена данными передавали сообщения, связанные с безопасностью дорожного движения. ЧС на транспорте, быстро и четко и были абсолютно понятны для всех пользователей.

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

Настоящий стандарт обеспечивает основу для определения стандартизованного набора процедур регистрации данных, протоколов, параметров, метода управления обновляемым реестром данных (РД) для передачи сообщений, касающихся безопасности и ЧС на дорогах. Определения в настоящем стандарте приведены в нормативных документах*, а также в ГОСТ Р 56829.

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

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

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

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

Кроме того, важно учитывать, что оборудование, установленное в ТС в 2010 г., может функцио» нировать и в 2040 г., в то время как средства беспроводной связи имеют более короткий жизненный цикл. Таким образом, благодаря новым и дополнительным концелциям формирования РД технические средства, обеспечивающие беспроводную передачу информации, будут меняться. Поэтому настоящий стандарт является независимым от характеристик и особенностей технической инфраструктуры и средств беспроводной связи, не формирует требований к конкретным подсистемам и средствам беспроводной передачи данных, устанавливая, однако, требования к данным, которые будут однозначно восприниматься получателями сообщений, касающихся безопасности и ЧС на дорогах. Причем для улучшения надежности и достоверности получения данной информации целесообразно использовать не один носитель информации, а каждый из доступных пользователю. Не предполагается, что обязательно должен быть один глобальный обновляемый РД для обеспечения передачи сообщений, касающихся безопасности и ЧС в ИТС. несмотря на целый ряд организационных и других причин.

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

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

\A^V

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

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

ОПРЕДЕЛЕНИЕ СТАНДАРТИЗОВАННОГО НАБОРА ПРОТОКОЛОВ, ПАРАМЕТРОВ, МЕТОДА УПРАВЛЕНИЯ ОБНОВЛЯЕМЫМ РЕЕСТРОМ ДАННЫХ ДЛЯ ОБЕСПЕЧЕНИЯ ПЕРЕДАЧИ СООБЩЕНИЙ, КАСАЮЩИХСЯ БЕЗОПАСНОСТИ И ЧРЕЗВЫЧАЙНЫХ СИТУАЦИЙ

intelligent transport systems. Determination of a standardized set of protocols, parameters, management method of the updated data registry for transfer of safety and emergency messages

Срок действия — с 2019—06—01 до 2022—06—01

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

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

раметров, метод управления обновляемым реестром данных (РД) для обеспечения передачи сообщв-ний. касающихся безопасности и чрезвычайных ситуаций (ЧС), с использованием доступного беспро-водного канала связи.

2 Соответствие

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

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

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

ГОСТ Р 52928 Система спутниковая навигационная глобальная. Термины и определения

ГОСТ Р 56829 Интеллектуальные транспортные системы. Термины и определения

ГОСТ Р 57187 Интеллектуальные транспортные системы. Протокол обмена данными бортового телематического устройства транспортного средства городского пассажирского транспорта с системой диспетчерского управления

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

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

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

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

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

4.2 Государственная автоматизированная информационная система «ЭРА-ГЛОНАСС»: Федеральная государственная территориально распределенная автоматизированная информационная система экстренного реагирования при авариях, обеспечивающая оперативное получение формируемой в некорректируемом виде на основе использования сигналов глобальной навигационной спутниковой системы Российской Федерации информации о дорожно-транспортных и иных происшествиях на автомобильных дорогах в Российской Федерации, обработку этой информации, ее хранение и передачу в экстренные оперативные службы, а также доступ к этой информации со стороны государственных органов, органов местного самоуправления, должностных лиц. юридических лиц. физических лиц. решение иных задач в области получения, обработки, хранения и передачи информации, не связанной с дорожно-транспортными и иными происшествиями на автомобильных дорогах в Российской Федерации.

4.3 устройство вызова экстренных оперативных служб: Устройство или система, установленные на транспортном средство, осуществляющие определение координат места нахождения транспортного средства, скорости и направления его движения и обеспечивающие формирование, передачу в некорректируемом виде информации о транспортном средстве при дорожно-транспортных и иных происшествиях на автомобильных дорогах в Российской Федерации, а также двустороннюю голосовую связь транспортного средства с экстренными оперативными службами по сетям подвижной радиотелефонной связи.

4.4 экстренные оперативные службы: Система обеспечения вызова экстренных оперативных служб по единому номеру «112». или в случае отсутствия в субъекте Российской Федерации такой системы государственный орган данного субъекта Российской Федерации, уполномоченный на организацию централизованной обработки вызовов экстренных оперативных служб, или организация, осуществляющая централизованную обработку вызовов экстренных оперативных служб в данном субъекте Российской Федерации, либо в случае отсутствия указанных органа или организации экстренные оперативные службы данного субъекта Российской Федерации.

5 Сокращения

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

ГД — глоссарий данных:

ГЛОНАСС — глобальная навигационная спутниковая система;

ДТП -дорожно-транспортное происшествие;

ИТС — интеллектуальная транспортная система:

ТК — технический комитет:

ТС — транспортное средство;

ЧС — чрезвычайная ситуация:

РД —реестр данных;

ASN.1 — abstract Syntax Notation One;

GPS — global Positioning System;

M — mandatory (обязательный):

О — optional (необязательный);

С — contingent (условный);

I — indicative (индикативный);

A — assigned (назначенный);

N/A — not applicable (неприменяемый);

UML — Unified Modeling Language.

б Требования к процедурам регистрации данных и управлению обновляемым реестром данных

6.1 Формат использования

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

6.2 Общие положения

Реестр данных должен быть согласован с элементами данных разных групп заинтересованных сторон (терминология приведена в нормативном документе').

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

В настоящем стандарте не определены вид и форма сообщений, касающихся безопасности и ЧС. равно как и обстоятельства, при которых данные сообщения передаются, и назначение передаваемых сообщений.

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

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

6.3 Структура

Общая структура РД и ГД представлена на рисунке 1.

Рисунок 1 иллюстрирует взаимосвязи:

- между элементами архитектуры ИТС е части обеспечения безопасности (и информационными моделями);

- ГД (который должен включать в себя все структуры данных):

• РД;

- всеми приложениями безопасности ИТС.

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

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

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

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

В таблице 1 приведено краткое описание отличительных характеристик ГД и РД.

Таблица 1 — Отличительные особенности глоссария данных и реестра данных

Окончание таблицы 1

6.4 Организационная структура

6.4.1 Общий обзор

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

На рисунке 2 представлена структура верхнего уровня с описанием указанных элементов организационной структуры для управления обновляемым РД.

Рисунок 2 — Организационная структура реестра данных интеллектуальной транспортной системы и взаимодействие ее элементов

В приложении Б описано содержание РД с точки зрения определения метаатрибутов. В приложении В приведено описание цели, конкретных обязанностей, критериев членства или отбора для каждого элемента организационной структуры с учетом требований к метаатрибутам для концепций данных.

6.4.2 Регистратор

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

6.4.3 Сервис

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

6.4.4 Отправитель

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

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

6.4.5 Пользователь «только для чтения»

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

6.4.6 Контроль изменения данных

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

6.4.7 Исполнительный совет

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

6.5 Уровни статуса регистрации данных

6.5.1 Сводка уровней статуса регистрации данных

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

« «Карта»,

- «Проект»;

- «Записанный»:

- «Соответствующий»;

- «Предпочтительный».

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

Таблица 2 — Уровни и критерии статуса регистрации сообщений, касающихся безопасности и чрезвычайных ситуаций

Несмотря на то что основная цель заключается в том. чтобы продвигать уровень статуса концепций данных все выше, например от уровня «Проект» к уровню «Предпочтительный», в отдельных случаях переход к уровню статуса выше, чем «Записанный» или «Соответствующий», не всегда может быть уместным. То есть необходимая метаатрибутная документация для концепции данных может быть недоступна для установки документации для уровня статуса «Записанный», не соответствовать по своим качественным характеристикам уровню статуса «Соответствующий». Более того, идентификация такой информации на уровне статуса «Предпочтительный» может оказаться неприемлемой. Эти концепции данных должны храниться на их текущем уровне статуса в РД, для того чтобы способствовать пониманию и представлению этих данных широкому кругу пользователей.

6.5.2 Описание уровней статуса регистрации данных

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

а) «Карта»

Регистрация данных на уровне статуса «Карта» указывает на то, что отправитель информирует пользователей обновляемого РД для обеспечения передачи сообщений, касающихся безопасности и ЧС. о существовании данных в своей локальной области. Концепция данных на уровне статуса «Карта» в РД должна поддерживаться с учетом контроля актуальной версии глоссария отправителя. Отправитель может в любой момент удалить концепцию данных на уровне статуса «Карта» из РД. Минимальные мета-атрибуты для уровня статуса «Карта» в РД должны быть следующие: «Описательное имя», «Организация отправителя (имя)», «Телефонный номер отправителя» и «Адрес электронной почты отправителя».

б) «Проект»

Регистрация данных на уровне статуса «Проект» указывает на то. что отправитель хочет предложить концепцию данных для перехода на верхние уровни регистрации данных в РД. Концепции данных на уровне статуса «Проект» не поддерживаются при управлении версиями, что означает, что обновления полностью заменят исходную запись без сохранения записи оригинала. Отправитель может запросить удаление концепции данных на уровне статуса «Проект» в любое время, что полностью исключит концепцию данных из активной версии обновляемого РД. Минимальные метаатрибуты для уровня статуса «Проект» следующие: «Описательное имя» и «Организация отправителя (имя)».

в) «Записанный»

Регистрация данных на уровне статуса «Записанный» указывает на то. что отправитель произвел ввод всех обязательных метаатрибутов. Концепция данных на уровне статуса «Записанный» подразумевает. что концепция данных может быть использована совместно всеми пользователями сервисных подсистем ИТС. Содержимое обязательных метаатрибутов в данном случае может не соответствовать требованиям качества. Отправитель может в любой момент отказаться от концепции данных на уровне статуса «Записанный». Концепции данных на уровне статуса «Записанный» или выше поддерживаются при управлении версиями обновляемого РД.

г) «Соответствующий»

Регистрация данных на уровне статуса «Записанный» указывает на то. что структуры контроля изменения данных подтвердили, что обязательные метаатрибуты являются полными и соответствуют применимым требованиям к качеству. Если структуры контроля изменения данных не одобрят концепцию данных для уровня статуса «Соответствующий», она останется на уровне статуса «Записанный».

д) «Предпочтительный»

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

6.6 Процедуры регистрации данных

Регистрирующий орган РД должен установить необходимые процедуры регистрации данных для выполнения следующих функциональных действий:

а) «Представление концепций данных для регистрации»

Отправители должны представить концепции данных для включения в РД. Эти группы данных могут иметь уровень статуса «Записанный», или «Карта», или «Проект» согласно определению отправителя.

Уровень статуса «Карта» означает использование, ограниченное областью значений отправителя только в информационных целях. Уровень статуса «Проект» подразумевает, что отправитель намерен продвинуть концепцию данных на более высокие уровни статуса регистрации РД. Отправители или структуры сервиса данных (сервис) могут продвигать концепции данных на уровне статуса «Проект» на уровень «Записанный», заполняя все обязательные метаатрибуты. необходимые для этой концепции данных.

б) «Продвижение концепций данных на верхний уровень»

Отправители должны продвигать концепции данных до уровня статуса «Записанный». Для про» движения концепции данных на уровень статуса «Соответствующий» или выше требуются поддержка со стороны структур сервиса данных (сервис) и утверждение со стороны структур контроля изменения данных.

в) «Гармонизация концепций данных»

Цель гармонизации заключается е устранении дублирования или некорректных толкований дан» ных обновляемого РД. Должны быть созданы процедуры для облегчения процессов гармонизации и повторного использования концепции данных.

г) «Модификация концепций данных»

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

д) «Удаление концепций данных»

Должны быть установлены процедуры для удаления данных.

е) «Администрирование данных»

В обновляемом РД должны быть реализованы процедуры администрирования для сопроеожде» ния и отслеживания текущего состояния концепции данных.

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

6.7 Контроль версий

6.7.1 Техническое обслуживание версий

В этом пункте представлены требования к синхронизации метаатрибутных структур ГД и РД.

Конфигурационные версии РД должны поддерживаться для метаатрибутов. Текущие версии и разрабатываемая версия должны быть установлены и поддерживаться для метаатрибутов РД.

6.7.2 Текущая версия

Текущая версия должна состоять из тех метаатрибутов. которые одобрены структурами контроля изменения данных для текущего использования в ГД и в РД.

6.7.3 Разрабатываемая версия

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

6.8 Общие положения для определения концепций данных

Примечание — Термин «концепция(и) данных» используется в настоящем стандарте для обозначения типафа) данных.

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

На рисунке 3 представлена структура концепций данных и их взаимосвязь с использованием ASN.1 {при описании типов данных и их значений в открытых системах связи). В целях иллюстрации фигурные скобки, т. е. {и}, изображают конкретные отношения между концепциями данных. Числовая аннотация, связанная с каждой фигуркой скобкой, указывает количество каждой концепции данных, которая может быть реализована. Например, в диалоговом окне интерфейса может быть от 2 до л сообщений. где п — любое целое число. В качестве другого примера сообщение может содержать от 0 до и элементов данных и от 0 до п таблиц данных.

Рисунок 3 — Структура концепции данных для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций

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

Рисунок 4 — Концепции данных интерфейса интеллектуальной транспортной системы

На рисунке 5 представлены концептуальные модели данных и их отношения. В поддержку концепций данных обмена информацией предлагаются дополнительные концепции данных для моделирования. Эти концепции моделирования поддерживают реализацию организации различных концепций данных, характеризуя ключевые отношения между понятиями данных (см. приложение Д).

Область «немений

Элемент денных

Рисунок 5 — Концептуальная модель данных для обеспечения передачи сообщений е интеллектуальной транспортной системе

6.9 Диалоговый интерфейс

Диалоговым интерфейсом является временная последовательность сообщений, включая варианты. между двумя системными компонентами или более, обеспечивающими процессы предоставления информационного сервиса или наблюдения. На рисунке 3 примером диалога является следующий диалог: «Пассажир (участник дорожного движения)<-Обмен-автобус-информация->интернет-лровайдер». Конкретный пример обеспечения передачи сообщений е ИТС: «Транспортное средстео<-Обмен-местоположение-информация->интернет-проеайдер».

6.10 Сообщение

Сообщение должно представлять собой структурированную группировку элементов данных и/или таблиц данных. На рисунке 3 показан пример сообщения «Когда (в какое время)-автобус-ппп_прибудвт-на-перекресток-ууу.сообщение». В приложении Д рассмотрены особенности и примеры использования информационных объектов в ASN.1 для формирования таблиц данных РД.

6.11 Таблица данных

Таблица данных представляет собой структурированную группировку элементов данных в основном для запроса информации к группе с единственным именем для эффективного повторного использования таких групп элементов данных, которые, как правило, появляются в передаваемом сообщении. На рисунке 3 примером таблицы данных является «Перекрестостаблица». В приложении Д рассмотрен пример спецификации информационных объектов в ASN.1 для формирования таблиц данных.

6.12 Класс объекта

Класс объекта является описанием набора объектов, которые имеют одни и те же свойства, отношения и семантику в пределах определенной области значений для представления информации. Могут быть использованы модификаторы, которые определяют или дополнительно уточняют класс объекта. Класс объекта — это одна из трех концепций данных, используемых для характеристики элемента данных. На рисунке 3 показаны иллюстрированные классы объектов: «Автобус» и «Транспортное средство».

6.13 Соотношение данных

Соотношение данных должно быть структурированным отношением между классами объектов. Определенный тип соотношения называется «композиция», в которой объект «целого» класса находится в «целой или частичной» связи с объектами класса «части». На рисунке 3 примером соотношения данных является «Автобус«специализация»Транспортное средство».

Когда класс объектов участвует в соотношении данных, он имеет определенную роль, которую играет в этих отношениях. В приложении Д рассмотрены примеры моделирования информации.

6.14 Свойство

В концепции данных «Свойство» указана информация, которая относится к одному или нескольким классам объектов. Интересующая информация может представлять собой факт, предложение или наблюдение за каждым объектом класса. Понятие «Свойство» является одним из трех понятий данных, используемых для характеристики элемента данных. На рисунке 3 примером свойства является «Идентификация».

6.15 Понятие элемента данных

Понятие элемента данных должно состоять из класса объектов и свойства, хотя в форме, подобной концепции данных «Элемент данных», понятие элемента данных лишено области значения или представления. На рисунке 3 примером концепции данных «Понятие элемента данных» является «Автобус.идентификация».

6.16 Область значений

Термин «Область значений» — это термин, который указывает точно и однозначно формат и синтаксическую форму для значений термина «Концепция(и) данных». Область значений является одной из трех концепций данных, используемых для характеристики элемента данных. На рисунке 3 примером области значений является «:идентификатор».

6.17 Элемент данных

Элемент данных должен быть формализованным представлением определенной информации (т. е. свойства, например факт, предложение или наблюдение) о классе объектов (например, о человеке. месте, процессе, концепции, соотношении данных, состоянии или событии) с явным представлением «Область значений». «Элемент данных» (существенный экземпляр концепции данных) должен характеризоваться тремя понятиями данных (см. рисунок 3): «класс объекта», «свойство» и «область значений» с признаком описательного имени (и ссылка на область значений, при возможности применения. описывая основные характеристики передаваемой информации). На рисунке 3 примером элемента данных является «Автобус. идентификация:идентификатор». На рисунке 4 приведен пример концепции данных интерфейса ИТС в терминах приложения Д.

7 Метаатрибуты представления данных для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций

7.1 Основные метаатрибуты понятий данных

7.1.1 Категории метаатрибутов

В ГД и РД должны быть использованы основные метаатрибутиеные категории идентификации, а также определения, как реляционные, так и репрезентативные.

Определение каждого метаатрибута. а также стандартизованного набора протоколов для обеспечения передачи сообщений, касающихся безопасности и ЧС, приведено в приложении Г.

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

В приложении Е рассмотрена спецификация концепции данных ASN.1.

Базовые метаатрибуты могут быть представлены в одной или нескольких метамоделях данных. для того чтобы более полно отражать отношения между данными. Несмотря на то что выбранные мегаатрибуты основаны на синтаксисе ASN.1 для представления данных, альтернативные (мета)модели данных могут приводить к альтернативному синтаксису. Следовательно, в будущих версиях могут быть добавлены дополнительные метаатрибуты для поддержки других синтаксисов (например, графические) и некоторые существующие обязательные атрибуты могут стать необязательными.

7.1.2 Идентификационные метаатрибуты

Идентификационные метаатрибуты должны отличать одну концепцию данных от другой.

Например, концепций «Идентификатор типа данных» совместно с концепцией «Версия концепции данных» является уникальным идентификационным тэгом для концепции данных в обновляемом РД для обеспечения передачи сообщений, касающихся безопасности и ЧС. «Идентификатор объекта ASN.1» — это также уникальный идентификатор для каждой концепции данных.

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

Метаатрибуты идентификации:

- идентификатор концепции данных;

- версия концепции данных;

- описательное имя;

- синонимичные описательные имена.

- символические имена.

- hmaASN.I;

- идентификатор объекта ASN.1;

- единый указатель ресурсов (URL).

7.1.3 Метаатрибуты определения

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

Метаатрибуты определения:

- определение;

- контекст «Описательное имя»;

- использование символического имени;

- источник;

- ссылка на архитектуру;

- наименование архитектуры;

- архитектурная версия;

- тип концепции данных:

- примечания;

• контекст;

- стандарт;

- источник метаданных:

- приоритет;

- режим частоты сообщений;

- проверка доставки;

- качество данных.

7.1.4 Реляционные метаатрибуты

Реляционные метаатрибуты должны документировать соотношение данных между концепциями данных.

Реляционные атрибуты:

- прекурсор;

- преемник;

- синоним;

- аннотация;

- роли;

- кратность:

- ограничения соотношений данных;

- совокупность;

- ключевая роль.

- реферируемые сообщения:

- связанные таблицы данных;

- связанные элементы данных;

- связанные классы объектов;

- связанные соотношения данных.

7.1.5 Репрезентативные метаатрибуты

Репрезентативные метаатрибуты должны описывать требования к физическому представлению для таких концепций данных, как «Элемент данных» и «Область значений».

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

Репрезентативные метаатрибуты:

> тип данных:

• формат:

• единица измерения:

- правило допустимого значения (допустимое значение).

7.2 Административные метаатрибуты

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

Статус регистрации определяет уровень состояния концепции данных.

Административные метаатрибуты. указанные ниже, должны использоваться в РД. для того чтобы облегчить административное управление обновляемым РД. Административные метаатрибуты являют* ся необязательными для ГД.

Административные метаатрибуты:

« статуи регистрации:

• дата регистрации:

> дата последнего изменения;

- пользователь последнего изменения;

• название организации регистратора;

- телефонный номер регистратора;

- название организации сервиса данных (оператора системы);

• номер телефона организации сервиса данных (оператора системы);

- название организации-отправителя;

- номер телефона отправителя;

- пользователь;

• просмотр;

- связанные группы:

- класс безопасности.

8 Концепции данных обновляемого реестра данных

8.1 «Описательные имена»

Описательные имена должны формулироваться при разработке концепций данных. Требования к разработке описательных имен для концепций данных, их составные части и их сокращения описаны в приложении Е; представление данных в информационной модели — в приложении Ж.

Эти требования распространяются на всю среду передачи в ИТС сообщений, касающихся безопасности ЧС.

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

Примеры использования подобных разделителей: точка, двоеточие, левый карет (знак вставки), правый карет (знак вставки) и тире, представлены в приложении Е.

Описательные имена должны быть уникальными.

8.2 Форматы данных описательных имен

Описательные имена должны быть построены путем объединения соответствующих компонентов описательных имен с конкретными разделителями.

Форматы данных приведены в таблице 3.

Таблица 3 — Форматы данных описательных имен для представления данных для передачи в ИТС сообщений, касающихся безопасности и чрезвычайных ситуаций

9 Требования к метаатрибутам представления данных для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций

Реестр данных и ГД должны состоять из метаданных для каждой концепции данных, как указано в приложении Б.

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

10 Международные отношения

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

Международные и региональные уровни формирования данных рассмотрены в приложении И.

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

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

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

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

Функциональные операционные процедуры регистрации данных для обеспечения передачи сообщений, касающихся безопасности и чрезвычайных ситуаций

А.1 Введение

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

А.1.1 Регистратор

Эпеменг «регистратор» обеспечивает единую регистрацию для передачи данных и отвечает за управление и содержание информации в РД. а также за выполнение следующих функций:

а) мониторинг и управление данными, содержащимися в PQ.

Примечание — РД создается, испотъзуется и хранится с помощью руководящего органа (структуры, организации, оператора системы) регистрации сообщений в ИТС:

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

г) фиксирование текущего статуса регистрации концепции данных РД:

д) предоставление доступа к содержанию РД авторизироаанным пользователям:

е) содействие в прохождении этапов регистрации концепциям данных:

ж) содействие в обнаружении и решении вопросов, связанных с дублированием и определением концепций данных РД;

и) исполнение поручений, направленных руководящим органом регистрации данных в ИТС:

к) регистрация концепций данных е ИТС для передачи сообщений во внешних РД или ГД:

л) отслеживание процедур регистрации данных для их представления РД при решении следующих вопросов:

- каким образом подготовить данные, внести их. т. е. непосредственно процесс внесения данных:

- как именно использовать РД для предотвращения дублирования вносимых данных:

• как использовать РД для гармонизации данных через ГД для переда*-*) в ИТС данных участвующих организаций;

• каким образом внешние реестры используются в качестве источника концепций данных для повторного применения в РД:

м) ведение отдельного документа, в котором фиксируется контактная информация всех операторов системы и исполнителей:

н) добавление новых пользователей или организаций, которые могут получить доступ к РД: п) контроль списка кодов РД.

А.1.2 Сервис

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

Структуры сервиса данных должны:

а) координировать идентификацию и оформление концепций данных 8 пределах установленной области:

б) обеспечивать правильную регистрацию концепций данных в их установленной области;

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

г) рассматривать все концепции данных, ранее имевшие уровень статуса «Записанный», и стремиться исправлять конфликты между концепциями данных разных областей;

д) обеспечивать качество метаатрибутов для концепций данных, предлагаемых для статуса регистрации уровень «Соответствующий», повторно используя соответствующие стандартизованные данные внешних РД:

е) предлагать для концепций данных в заданной области уровень статуса регистрации «Предпочтительный»;

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

А. 1.3 Отправители

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

Отправители сообщений в ИТС ответственны за выполнение следующих функций:

а) в письменной форме процесс идентификации себя в структуре регистрации данных:

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

в) передача концепций данных в структуру регистрации данных:

г) обеспечение в полном объеме метаатрибутами концепции данных ИТС передачи сообщений, которые предложены для получения ими уровня статуса «Записанный».

А. 1.4 Пользователи «только для чтения»

Данный организационный элемент утверждается PQ для просмотра содержания реестра ИТС. Эта категория пользователей не может дополнять, удалять или выполнять иные модификации с содержанием РД.

A.1.S Структура контроля за изменениями

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

Структура контроля за изменениями ответственна:

а) за общее руководство операциями, связанными с регистрацией в ИТС:

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

в) переход зарегистрированных в РД концепций данных на уровни статуса «Соответствующий» и «Предпочтительный»:

г} выявление данных, которые зарегистрированы во внешних РД или ГД:

д) разрешение технических вопросов, связанных с регистрацией данных, например совмещение, дублирование данных:

е) обновление концепций данных, ранее помещенных в РД. на уровне в статусе регистрации «Соответствующий» и «Предпочтительный»:

ж) предложение принципов административного управления «ИТС РД» на их утверждение:

и) утверждение авторизированных «отправителей», «пользователей только для чтения» и категории пользователей «ИТС РД»:

к) утверждение содержания, процедур и формата ИТС РД:

п) представление рекомендаций, связанных с управлением и вопросами административного правления:

м) исполнение требований администрации:

н) периодическое проведение собраний, дополнительных встреч и видеоконференций по мере необходимости.

Структуры контроля изменения данных должны исполнять свои обязанности путем согласования в соответствии с установленными процедурами. Неразрешимые вопросы решаются в соответствии с установленными процедурами путем консенсуса.

А.1.6 Исполнительный орган

Исполнительный орган отвечает за общую политику и бизнес-управление РД. включая следующее:

а) установление всех правил РД:

б) разрешение всех бизнес-вопросов, касающихся РД. в том числе авторского права, руководства, финансирования. состава исполнительного органа:

в) обеспечение долгосрочного успеха и эффективности работы РД:

г) создание и обновление устава и стратегии планов РД:

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

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

А.2 Порядок регистрации

А.2.1 Краткий обзор

В пунктах данного подраздела изложены эксплуатационные процедуры регистрации данных РД. Эти процедуры описывают методы регистрации и согласования данных в РД (см. раздел 9). а также определения уровня статуса регистрации данных. В данном пункте перечислены действия по регистрации, связанные со следующими элементами: «отправители», «сервис», «реестр сообщений ИТС» и «структуры контроля изменения данных». На рисунке А.1 проиллюстрированы данные функциональные действия.

PikjhmAI—Фунщмонагыив структура ратестрвции информации для реестра данных ингагш«пуапм»я

транспортной системы

А.2.2 Начало регистрации данных

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

А.2.3 Проверка качества

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

А.2.4 Руководство реестром

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

а) «Предварительно соответствующий»

Идентификация данных в качестве предварительно соответствующих означает, что сервис подтверждает наличие в полном объеме обязательных метаагрибутов. а также их соответствие установленным требованиям качества. Сервис уполномочен переводить данные с уровня статуса «Записанный» на уровень статуса «Предварительно соответствующий» в тот момент, когда сервис получил подтверждение того, что все требования, предъявляемые к качеству, соблюдены. Для данных уровня статуса «Предварительно соответствующий» и более высокого уровня название организации сервиса является обязательным и «имя ASN.1» должно быть уникальным в процедурах РД.

б) «Предварительно предпочтительный»

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

в) «Удалежый»

Идентификация данных в качестве удаленных означает, что оператор системы не рекомендует эти концепции данных для использования в базе сообщений ИТС. Концепции данных на уровне статуса «Удаленный» также включают данные, которые имели уровень статуса «Записанный», но были удалены отправителем. Такие концепции данных сохраняются в хранилище архивных данных РД в качестве исторической справхи. Уровень статуса «Удаленный» идентифицирует концепции данных, которые не считаются подходящими для использования в базе сообщений ИТС. Концепции данных на уровне статуса «Удаленный» включают в себя справку (например, мета-атрибуты последующих данных) о замененных данных, если это необходимо. Изменения на уровне статуса «Удаленный» в концепциях данных недопустимы.

А.З Процедуры регистрации данных ИТС

А.3.1 Обзор

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

Отпрмтпь *' Сервис ” АапютшпфЛвггрт

{ui^Mruyi'iinvi) «имени» данных

Рисунок А.З — Процесс регистрации данных {часть 2)

А.3.2 Уровни статуса регистрации «Карта» или «Проект»

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

Шаг 2а: отравитель рассматривает концепции данных, для того чтобы определить, следует ли продвигать данные с уровня статуса регистрации «Проект». Если данные не обновляются, они признаются актуальными в РД.

Шаг За: Как минимум ежеквартально сервис также анализирует концепции данных, для того чтобы установить соответствие с нужным отправителем, а также действительно ли данные были изменены на данные уровня статуса регистрации «Проект». Если данные на изменены, они признаются актуальными в РД.

А.3.3 Записанные концепции данных

Шаг 26: отправитель определяет, приобретают ли концепции данных уровень статуса регистрации «Записанный». Отправитель подтверждает. что обязательные метаатрибуты присутствуют в полном составе, обновляя их по мере необходимости (шаг 2в). Затем отправитель запрашивает для данных уровень статуса «Записанный».

Шаг 36: сервис определяет, приобретают ли концепции данных уровень статуса регистрации «Записанный». Для этих концепций данных сервис подтверждает, что обязательные метаагрибуты присутствуют в потом объеме, обновляя их по мере необходимости (шаг Зв). Затем сервис запрашивает для данных уровень статуса «Записанный».

Примечания

1 Ест диаграмма на рисунка А2 идентифицирует условие передачи концепции данных а состояние «Удержание» (функция удержания данных), то эго означает, что рассматриваемые данные хранятся на последнем одобренном уровне статуса регистрации. «Удержание» на является дополнительным уровнем статуса регистрации.

2 Размещение любых концепций данных от любого отравителя в РД на регистрационном уровне статуса «Карта» или «Проект» полностью зависит от соответствующего уполномоченного органа отправителя или сервиса, который решает сделать это. Кроме того, переход от одного из этих уровней статуса к другому более высокому уровню статуса регистрации полностью зависит от того, заинтересован ли отправитель/сереис а продвижении этих данных. Это означает, что именно отравитель кУили сервис предлагают продвигать концепции данных. В настоящем стандарте не указывается временной ряд. по которому должно происходить развитие любого уровня статуса регистрации.

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

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

Шаг 4: для уровня статуса регистрации «Записанный» по запросу от отправителя или сервиса система РД должна проверять наличие обязательного набора мвтаатрибутов концепций данных и точное описание данных, которые представлены, и изменять уровень статуса регистрации на «Записанный» для данных с записями, содержащими все обязательные метаатрибуты.

Если в обязательном метазтрибуте отсутствует запись. РД должен уведомить запрашивающую сторону о недостающих метаатрибутах.

А.3.4 Соответствующие концепции данных

Шаг 5: сервис для тех данных, которые подходят для перехода на уровень статуса регистрации «Соответствующий». рассматривает метаатрибуты, исходя из их соответствия положениям настоящего стандарта и другим требованиям, которые могут быть согласованы структурами контроля изменения данных и опубликованы в правилах управления техническими данными РД.

Если метаатрибуты не соответствуют требованиям качества, сервис содействует отправителю 8 достижении соответствия данным требованиям (шаг ба).

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

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

Когда элементы данных иностранных РД повторно используются в РД. они могут рассматриваться на уровне статуса «Проект» и на уровне статуса «Записанный» в их исходном веде (при условии, что минимальные мвтаатри-буты, необходимые для внешних данных, полноценны).

Внешние процессы сервиса проиллюстрированы на рисунке А.4.

Примечание — Если диаграмма на рисунке А.З идентифицирует условия передачи данных в состояние «удержание», то это означает, что рассматриваемые концепции данных хранятся на последнем одобренном уровне статуса регистрации. «Удержание» не является дополнительным уровнем статуса регистрации.

РткдмжА.4— Ввмкхаяи внешют глоссарии данных и реестра данных

Шаг 7; внешние данные вносятся и повторно используются вместо конкретных данных, предложенных отправителем. ест эти данные идентифицированы таким образом, как показано на рисунке А.4. Сервис комплектует следующие метаатрибуты для внешних данных, повторно используемых в РД: «описательное имя», «определение». «регистрационное имя организации» и «регистрационный номер телефона» {вводится для записи во внешний реестр или другой необходимой информации), «синонимичное имя» (имя в той форме, в которой представил отправитель и источник, вводя слово «внешний»). Внешние данные могут продвигаться на уровне статуса регистрации с условием, что эти данные имеют полный необходимый набор метаатрибутов. Когда данные имеют вое соответствующие метазтрибуты надлежащего качества, сервис обновляет уровень статуса регистрации этих данных, и они становятся предварительно соответствующими.

Шаг 8: регистратор просматривает все предварительно соответствующие данные по крайней мере один раз в квартал для повторной проверки полноты обязательных метаатрибутов и подтверждения требований к их качеству. включая уникальность их обнаружения и качества описательного имени, а также уникальность объекта «Имя ASN.1».

Если требования к качеству соблюдены, регистратор должен продвинуть концепции данных до уровня статусе «Соответствующий».

Если требования к качеству не соблюдены, регистратор оказывает помощь сервису и отправителю 8 достижении необходимых стандартов качества метаатрибутов концепций данных при возможности. В противном случав данные удерживаются на уровне статуса «Записанный». Когда необходимый уровень качества достигнут. регистратор отправляет перечень концепций данных, предлагаемых как соответствующие, вместе со всеми метаатрибута-ми на рассмотрение операторам системы на собрании {или по средствам электронного взаимодействия) при необходимости. для утверждения уровня статуса концепции данных «Соответствующий». Если данные не утверждены оператором системы, то им возвращается уровень статуса «Записанный».

А.3.5 Предпочтительные концепции данных

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

Шаг 10: регистратор пересматривает все данные, имеющие уровень статусе регистрации «Предварительно предпочтительный» минимум один раз в квартал для подтверждения их соответствия уровню статуса «Предпочтительный».

Регистратор отправляет список всех концепций данных, предлагаемых для уровня статуса регистрации «Предпочтительный», вместе с их метаэтрибутами и заявлением сервиса. Оператор системы, который рассматривает эти концепции данных на собранж (или по средствам электронного взаимодействия), подтверждает и устанавливает уровень статуса регистрации концепции данных как «Предпочтительный». Ключевыми направлениями анализа регистратора и оператора системы являются обнаружение и урегулирование наложения ит изменения концепции данных между сервисами. Регистратор затем меняет уровень статуса регистрации концепции данных и утверждает их как уровень статуса «Предпочтительный». Если концепции данных не утверждаются оператором системы как предпочтительные, то они переходят обратно на уровень статуса «Соответствующий». Если требования качества соблюдены, то регистратор должен продвинуть данные нв уровень статуса регистрации «Предпочтительный».

Окончательное решение об утверждении уровня статуса регистрации «Предпочтительный» может заключаться в подтверждении того, что эти концепции данных являются новой версией прежних предпочтительных концепций данных, или в признании таких данных уже закрепленными на уровне статуса «Предпочтительный». В этом случав при условии, что зарегистрированные концепции данных были ранее закреплены на уровне статусе «Предпочтительный» в РД сервис и отправитель, а также взаимосвязанные системные разработчики могут повторно использовать эти концепции данных для развития. Данное разрешение может повторно назначать ответственным другой сервис.

После того как зарегистрированные данные получают уровень статуса «Предпочтительный» и если во внешних РД эти данные признаны тахже рекомендованными, регистратор должен переадресовать эти концепции данных в соответствующие внешние РД.

А.4 Процедуры управления изменениями

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

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

А.4.2 Процедуры изменения концепций данных в РД

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

А.4.3 Процедуры удаления концепций данных в реестре данных

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

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

Удаленные концепции данных (за исключением тех. которые относятся к уровню статуса регистрации «Карта») будут связаны с заменяющей концепцией данных, при наличии отправителя или сервиса, таким образом, что фактическая дата замены данных будет записана с датой последних изменений, поэтому отображение старых и новых концепций в РД сохраняется.

Для концепций данных, имеющих уровень статуса регистрации «Соответствующий» или выше, после их представления оператору системы уровень статуса концепции данных, предложенный для удаления, меняется регистратором на «Удаленный».

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

Концепция данных с уровнем статуса «Удаленный» сохраняется в РД или ИТС архивирует их. для того чтобы иметь представление об этих данных в будущем. Когда концепция данных помещается в архив, ее идентификатор и описательное имя будут сохранены автоматически в РД.

А.4.4 Процедуры контроля изменений данных

А.4.4.1 Назначение

В данном подпункте процедуры контроля изменений данных применяются для РД и при необходимости для определенных элементов конфигураций в фумсциональкых областях ГД.

А.4.4.2 Идентификация элементов конфигурации

Цель идентификации элемента конфигурации заключается а том. что концепции данных подлежат улравле-нмо изменениями.

Существует два типа конфигурации: ИТС передачи концепции данных и метаатрибуты концепции данных РД. а также {если требуется) ГД по функциональным подсистемам ИТС. Оба типа элементов конфигурации управляются в соответствии с этими процедурами.

А.4.4.Э Концепция передачи данных ИТС

Управление формальными изменениями ИТС передачи концепций данных выполняется только для управления изменениями данных на уровнях статуса регистрации «Записанный». «Соответствующий* или «Предпочтительный».

Изменения концепций данных на административном уровне статуса «Удаленный» на разрешены. Концепция данных на уровне статуса «Карта» формально не изменяется в зависимости от участия или одобрения оператора системы. Записи на уровне статуса «Карта» контролируются ГД с использованием метаатрибугое ИТС.

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

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

А.4.4.4 Метаатрибуты концепций данных

Элементами конфигурации метаданных являются метаатрибуты. используемые для документирования данных в РД и в ГД. Все метаатрибуты управляются изменениями для РД и ГД.

Идентификационными номерами конфигураций для элементов конфигурации метаатрибуга являются их идентификатор данных и номер версии.

Для обеспечения функциональной совместимости между ГД и РД может потребоваться формальное управление изменениями элементов конфигураций метаатрибутов.

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

А.4.5 Управление элементами конфигураций

А.4.5.1 Исходные данные

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

А.4.5.2 Элементы конфигурации исходных данных

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

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

А.4.5.3 Контроль за изменениями элементов конфигураций

Изменение или добавление элементов конфигураций метаагрибутов запрашивается в соответствии со следующими процедурами:

а) сервис или регистратор собирает, оценивает и документирует запросы на изменение элементов конфигурации метаатрибугов или добавления, включающие изменения стандартных значений метазтрибутов. используя контрольный перечень слов, например «ключевые слова», «тип концепции данных», «тип взаимоотношений»;

б) сервис перенаправляет данный запрос регистратору вместе с рекомендацией преимуществ данного предложения;

в) регистратор представляет данные предложения оператору системы вместе с рекомендацией по их размещению:

г) оператор системы определяется с размещением этих предложений:

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

А.4.6 Уведомление о статусе конфигурации

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

КАЛ Проверка элементов конфигураций

Регистратор ответственен за проверку метаагрибутов текущих исходных данных. Это реализуется путем периодического выполнения регистратором один раз в полгода оценки:

а) метаатрибугов РД с элементами конфигураций метаатрибутов текущих данных:

б) дополнительно — хаяздой функциональной области метаатрибугов ГД с элементами конфигурации метаатрибугов текущих исходных данных.

Регистратор обеспечивает отчет оператору системы о результатах всех оценок вместе с рекомендациями по корректировке при необходимости.

А.5 Гармонизация и процедуры повторного использования концепций данных для обеспечения передачи сообщений в интеллектуальные транспортные системы А.5.1 Введение

Данные процедуры описывают, каким образом оператор системы и сервисы выполняют свои обязанности (см. рисунок А.2): идентифицируют, согласовывают и документируют наложения концепций данных и дублирование между сервисами осведомленных областей {повторно используя концепцию данных среди сервисов соответствующих подсистем ИТС. см. рисунок А.5).

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

Сначала предполагалось, что Rfl будет содержать только элементы данных, однако приведенное выше содержание РД может быть объяснено включением другой концепции данных.

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

Примечание — Пунктирные линии — необязательные действия: сплошные линии — обязательные действия.

Рисунок А.5 — Процесс процедуры согласования

А.5.2 Идентификация запросов на передачи данных в интеллектуальные транспортные системы

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

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

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

- шаг 0а: сервис мажет пересмотреть содержание потенциальных проблем концепций данных РД:

- швг Об: сервис отчитывается о потенциальных запросах концепций данных регистратору:

- швг 1: регистратор должен использовать возможности РД для идентификации потенциальных наложений или дублирования концепций данных. Идентифмсация потенциальных проблем концепций данных является результатом анализа регистратором понятий элементов данных, определений, общих сеойств/обьектое/срокое представления и общих или аналогичных областей значений:

- шаг 2: регистратор должен подготовить сводный перечень потенциальных запросов концепций данных вместе с другими задокументированными метаатрибутами для каждой концепции данных из сводного листа (см. таблицу АЛ. в котором представлен пример сводного листе). Перечень, приведенный в сводном листе, будет содержать любые новые потенциальные проблемы элементов данных за последние месяцы, включая последние согласования для ранее выявленных проблем элементов данных. Этот перечень включает следующие метаатрибуты: идентификатор концепции данных, идентификатор сервиса (при его наличии), описательное имя. определение. срок области значений, заметки (в которых сохранены замечания статуса гармонизации) и описание (с каким сервисом взаимодействует обнаруженный проблемный элемент данных).

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

■ шаг 3: регистратор отправляет перечень на сайт РД:

• шаг 4: оператор РД должен объявить о доступности списка вопросов по электронной почте сервисам и другим операторам системы;

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

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

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

- шаг 6: не менее чем за 2 нед до проведения собрания операторов системы регистратор должен распространить сводные перечни всех концепций данных, потенциально предназначенных к рассмотрению, вместе с текущими статусами решений то каждой концепции данных и изложить все метаатрибуты для каждой рассматриваемой концепции данных. Этот список должен быть направлен в электронном виде всем сервисам:

- шаг 7: сервисы могут сообщать о любых проблемах, связанных с этим списком РД по крайней мере за 1 нвд до проведения собрания операторов системы, для того чтобы подготовить полный пакет документов для собрания, отражая самые последние статусы согласования проблем. Регистратор должен направить оригинал списка и все замечания, полученные от сервиса, оператору системы как минимум за 1 нед до собрания;

• шаг 8: оператор системы должен распространить согласованный список среди операторов системы:

- шаг 9: операторы системы рассматривают результаты согласования и направляют указания регистратору. Для тех концепций данных, то которым достигнуто согласование между необходимыми сервисами, операторы системы пересматривают и утверждают согласованный статус сервера или требуют те согласованные добавления, которые необходимы. Операторы системы пересматривают концепции данных, которые не компетентны решить или предложить решения при необходимости. Регистратор оставляет такие концепции данных вместе с текущим статусом согласования на листе согласования до конца принятия решения до тех лор. пока технический комитет не утвердит решение, а операторы системы — окончательный статус согласования. Эти концепции данных включаются в следующий список согласования проблем шага 2;

- шаг 10: элементы данных, которые 8 итоге утверждены при согласовании, удаляются из списке согласования и помешаются в архивный файл 8 качестве постоянной записи решения согласования. Регистратор обеспечивает размещение всех согласованных статусов всех рассматриваемых концепций данных в соответствующие концепции данных РД.

А.5.Э Повторное использование концепций данных интеллектуальной транспортной системы

Повторное использование концепций данных ИТС связано с одной из следующих ситуаций:

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

б) технический комитет может повторно использовать существующую концепцию данных в их собственной среде:

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

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

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

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

Таблица А.1—Пример списка обобщения

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

Определения метаатрибутов

Б.1 Введение

В приложении представлены определения метаатрибутов для РД и ГД. Мегаатрибуты в указанной категории должны служить для определения количества видов концепций данных, например уникальный идентификатор концепции данных, уникальное имя ASN.1. уникальное описательное имя и единый указатель ресурсов (URL). Метаагрибуты в определенной категории должны предоставлять точную информацию о концепции данных. Реляционные метаатрибуты должка устанавливать связи между концепциями данных. Репрезентативные мегаатрибуты должны документировать представление некоторых аспектов концепции данных. Метаагрибуты администрирования должны предоставлять адьмнистративную информацию, относящуюся к концепции данных.

В приложена В рассмотрены требования, относящиеся к концепции данных мегаатрибутов.

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

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

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

Б.2 Идентификационные метаатрибуты

Б.2.1 Идентификация концепции данных

Для идентификации концепции данных используется уникальный идентификатор, исключающий двоякое толкование, назначенный менеджером по запросам данных в ИТС и относящийся к каждой концепции данных. Для сообщений идентификатор концепции данных должен быть цельным и уникальным в своем роде в соответствии со спецификацией ASN.1. которая, в свою очередь, зависит от запросов данных и их регистрации. Символьные строки Alpha/alphanumeric/ASCII недопустимы.

Оценка данного мегаатрибута автоматически присваивается концепции данных, которая вписывается в РД.

Б.2.2 Версии концепции данных

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

Неоемаигичесте/репрезентациокные версии изменений данных концепции официально утверждены п«иь по некоторым направлениям. Изменения е административных метаатрибутах не влияют на изменение версии. Значимость этих метаатрибутов автоматически присваивается концепции данных, вписанных в запросах ИТС о безопасности РД.

Б.2.3 Описательное имя

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

Описательные имена показывают значения концепции данных и содействуют семантическому пониманию.

Б.2.4 Описательные имена синонимов

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

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

Примечание — Синонимичные описательные имена должны быть представлены только в тех местах, в которых это требуется. Например, они могут быть полезными, когда содержание некоторых функциональных областей ГД лросинтезированы в запросы РД и тот же самый элемент данных (исходя из его перспектив семантического и оценочного значения) проявляется в более чем одном ГД. но с отличающимся описательным именем. Это может быть полезным при выборе одного имени из нескольких (либо при выборе «нейтрального» имени) для определения главного отмсательного имени и при приведении одного имени или более в качестве синонима описательного имени.

Б.2.5 Символическое имя

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

Б.2.6Имя ASN.1

Имя ASN.1 должно являться именем концепции данных, которая выражена как действующая ссылка. Имя ASN.1 уникально в пределах запросов ИТС о безопасности РД.

Имя концепции данных описано в синтаксисе ASN. 1.

Примечание — Информация по ASN.1 о наименованиях соглашений и изменениях ГД приведена в приложении Г.

Б.2.7 Идентификатор объекта ASN.1

Уникальный идентификатор объекта ASN.1 предназначен для каждой специфицированной концепции данных один раз.

Б.2.8 Единый указатель ресурсов

Единый указатель ресуроов (URL) — это представление о входе и методе доступа к ресурсам, доступным через Интернет.

Если концепция данных, хоторая подключается к URL. не внесена е запросы ИТС по безопасности PQ и/или к данным словарей, то URL вычисляет месторасположение и способ входа в концеодию данных.

Б.З Метаатрибуты определения

Б.3.1 Определение

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

Б.3.2 Описательное имя контекста

Обозначение функциональной зоны по запросам ИТС о безопасности РД. 8 котором описательное имя будет релевантным.

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

Б.3.3 Использование символьных имен

Эго имена приложений, е которых использованы символы элементов данных.

Б.3.4 Источник

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

Б.3.5 Структурные отсылки

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

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

Б.3.6 Структурные имена

Это указатель (например, заголовок или число) запросов ИТС о безопасности или другой структуры, которая состоит из структурных отсылок.

Б.3.7 Версии структур

Эго то количество версий, е которых запросы о безопасности ИТС или другие структуры содержат ссыгжи.

Б.З.8 Типы концепций данных

В данном пункте представлен перечень видов концепций данных.

Виды правовых ценностных концепций данных:

а) класс объектов:

б) свойство:

в) область значений:

г) понятие элемента данных:

д) элемент данных:

е) таблица данных:

ж) сообщение:

и) диалоговый интерфейс:

к) соотношение данных.

Б.3.9 Примечания

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

Б.3.10 Контекст

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

Б.3.11 Стандарты

Это алфавитно-цифровое обозначение стандарта или другая ссылка, которые устанавливают и описывают концепцию данных. Для этого могут быть использованы акронимы или идентификаторы.

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

Б.3.12 Источник метаданных

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

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

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

Имя «встроенные» означает, что образцы содержат данные, в то время как метаданные как часть сообщений образцов не могут быть обнаружены в ГД и/или в РД либо отнесены косвенно к внешнему ресурсу. В этом случае, если известно, в какое время характеристика произведена, метаданные должны быть указаны в сообщении спецификации. Когда метаданные уточнены заранее (т. в. специальные сообщения, в которых данные и их метаданные не могут быть установлены до того, как образцы сообщений не будут созданы), должностное лицо должно указать данные встроенных сообщений. Пример такого сообщения должен содержать встроенные спецификации своих элементов данных. Достижение этого зависит от среды реализации идеи, например самоописыввющвй системы данных.

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

Б.3.13 Очередность

Очередность указывает на то. должен ли запрос получать приоритетную обработку. При ее наличии должны быть указаны схема приоритетов и/или приоритет запроса.

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

Б.3.14 Частота/режим сообщений

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

Б.3.15 Проверка доставки

Этот мвтаагрибут показывает, должны/обязаны ли требовать подтверждения экземпляры запросов доставки. Сюда таюке входят критерии повторной попытки. Могут быть использованы слова «должен» и «обязан». Разработчики запросов должны оповещать исполнителя с помощью инструкции о том. как именно этот мвтаагрибут должен быть использован.

Б.3.16 Качество данных

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

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

Б.4 Реляционные метаатрибуты

Б.4.1 Моделирование реляционных метаатрибутов

Первые три реляционных метазтрибуга {прекурсор, преемник, синоним) вводятся для идентификации определенных отношений между связями определенных стереотипов (расширения в режиме UML). которые выполняют работу на метауровне, т. е. используются для определения связей между концепциями данных, а не между их экземплярами. Любые отношения могут быть другими мегаатрибутами, описанными в этом пункте. На рисунке Б.1 представлены выбранные UML концепции данных.

Рисунок Б.1 — Взаимоотношения метаагрибутов

Б.4.2 Прекурсор

Эго историческая, семантически подобная концепция данных, которая заменила или заменяет эту концепцию данных.

Разрешены множественные значения. Применяется ко всем понятиям данных и должно быть описательным именем концепции данных, которое заменено.

Б.4.3 Преемник

Это более новая семантически подобная концепция данных, которая заменила или заменит эту концепцию данных.

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

Б.4.4 Синоним

Это семантически похожая концепция данных.

Разрешены множественные значения. Применяется ко всем понятиям данных и должно быть описательным именем концепции синонимичных данных.

Б.4.5 Резюме

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

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

Б.4.6 Роли

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

‘«object dassfl] name^.^rolellj name>", "«object dass(2) name>*."<rote[2J name>‘....

В случае обобщения связей. <rote[1 J name> = parent. <role{2J name> = child.

Применяется только к концепциям данных ассоциации.

Б.4.7 Множественность

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

Б.4.8 Ограничения ассоциации

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

- «скрытое» — только концептуальные связи;

• «упорядоченное» — множество объектов одной ассоциации находится е строгом порядке;

- «изменчивость» — связи могут быть добавлены, убраны или изменены:

- «только добавление» — новые связи могут быть добавлены гогъко с объектов противоположных ассоциаций:

- «удержание» — связи могут быть модифицированы или удалены:

• «искгеочение» — ровно один набор для каждого связанного класса объектов.

Применяется только к ассоциации концепции данных.

Б.4.9 Совокупность

Этот метзагрибут указывает на то. что обозначает класс объехта целым в ассоциации «целая часть». Если значение равно «false», то класс объекта не является целой частью — простая истина или ложь.

Применяется только к концепции данных ассоциации.

Примечание — Агрегация — это особый вид ассоциации, в которой один класс объектов представляет собой нечто большее {кцелое»), состоящее из скопления меньших вещей {«частей»}.

Б.4.10 Главный объект

Механизм, посредством которого главный объект класса в ассоциации определяет себя как отдельный экземпляр класса предметного объекта.

Он должен быть указан, если роль является управляемой. Упорядоченный список элементов данных определяет класс объекта ассоциации и применяется только к концепции данных ассоциации.

Примечание — Роль — это лицо, которое класс объектов предоставляет классу объекта другой ассоциации.

Б.4.11 Ссылочные сообщения

Набор сообщений, которые используются в интерфейсе.

Сообщения должны быть идентифицированы с использованием метаатрибута объекта идентификатора ASN.1 для соответствующих сообщений. Они применяются только к концепции данных интерфейса. Разрешены множественные значения.

Примечание — Когда применяются правила кодирования ASN.1, существует гарантия того, что значения сообщения должны быть недвусмысленно переданы. Когда диалог интерфейса должен использовать набор сообщений, однозначность может быть сохранена путем определения единственного сообщения: «ВЫБОР» в сообщениях в наборе.

Б.4.12 Ссылочные таблицы данных

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

Таблицы данных должны быть идентифицированы с испогъзованием их метаатрибута объекта ASN. 1.

Б.4.13 Ссылочные элементы данных

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

Элементы данных должны быть идентифицированы с использованием метаатрибуга ID объекта ASN.1. Разрешены множественные значения.

Б.4.14 Ссылочные объекты классов

Эго набор объектов класса, который участвует в разработке других концепций данных, таких как ассоциации.

Объекты классов должны быть идентифицированы с помощью метаатрибута объекта ASN.1. Разрешены множественные значения.

Б.4.15 Ссылочные ассоциации

Набор предприятий, который участвует в разработке диалога интерфейса.

Ассоциации должны быть идентифицированы с использованием их метаатрибутов IDN объекта ASN.1. Разрешены множественные значения.

Б.5 Репрезентативные метаатрибуты

Б.5.1 Тип данных

Эго логическое представление концепции данных, выраженное как действительный пример концепции данных типа ASN.1.

Форма данного метаатрибута для запросов, таблиц данных, элементов данных и области значений указана в Б.5.1.1—Б.5.1.4.

Б.5.1.1 Описание запросов

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

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

Метадажые и таблицы данных — это единственные спецификации, используемые для запросов (которые, в свою очередь, представляют собой низкоуровневые концепции данных, считающиеся мизерными в некотором контексте для определенной цели). Однако более слажнью структуры данных могут быть указаны в запросе путем создания групп элементов данных с использованием конструкторов ASN.1. Как правило, встречающиеся последовательности или другие трупгыровки элементов дажых могут обрабатываться с использованием концелцют «Таблицы данных».

Распределение или группировка концепций данных (элементы данных, таблицы данных и/или другие типы данных) по запросам могут включать указания определенных или всех из нижеперечисленных пунктов:

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

- повторяемость концепций данных в порядке следования или сегментов последовательностей, содержащих запросы;

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

• повторяющиеся последовательности понятий данных допускаются как часть спецификации запроса.

B.5.U Описание для таблиц данных

Текст этого метаатрибута должен состоять из полного и синтаксически правильного определения модуля ASN.1. Идентификатор для этого модуля предоставляется определителем модуля и не совпадает с метаатрибутом «Идентификатор объекта ASN.1». который идентифицирует запись регистрации. Определение модуля может содержать инструкции IMPORT, но они должны ссылаться только на модули, приведенные в РД. как на элементы данных и на таблицы данных. Он должен содержать одно определение типа ASN.1. В определении этого типа должны использоваться только импортированные виды ссылок и конструкторы ASN.1: последовательность, последовательность чего-либо и выбор.

Б.5.1.3 Описание для элементов данных

Текст этого метаатрибута должен состоять из полного и синтаксически правильного определения модуля ASN.1. Идентификатор для этого модуля предоставляется определителем модуля и не совпадает с метаатрибутом «Идентификатор объекта ASN.1*. который идентифицирует запись регистрации. Определение модуля может содержать инструкции, но они должны ссылаться только на модули, приведенные в РД в качестве области значений. Модугъ должен содержать одно определение типа ASN.1. Этот тип экспортирует и определяет элемент данных. В рамках данного типа должны использоваться только конструкторы ASN.1: последовательность, последовательность чего-либо и выбор, вместе с базовыми типами ASN.1. с допущением ограничений, применяемым к ним. или с использованием конструкции «последовательность». В этом контексте термин «базовый тип ASN Л» означает один из следующих типов данных, который является подмножеством типов ASN.1:

ITS-DD-Type

ITS-DD-BuiltinType |

ITS-DD-ReferencedType |

ITS-DD-ConsIrainedType

ITS-DD-8uiftinType :;=

BooleanType | - see ISO/IEC 8824-1. Clause 17

IntegerType \ - see ISO/IEC 8824-1. Clause 18

EnumeraledType | - see ISO/IEC 8824-1. Clause 19

RealType | - see ISO/IEC 8824-1. Clause 20

BUStringType | - see ISO/IEC 8824-1. Clause 21

OctetStringType ( - see ISO/IEC 8824-1. Clause 22

NutIType I - see ISO/IEC 8824-1. Clause 23

TaggedType | — see ISO/IEC 8824-1. Clause 30

ObjectldentifierType | — see ISO/IEC 8824-1. Clause 31

BMPStnng | - see ISO/IEC 8824-1. Clause 36 lASStnng | - see ISO/IEC 8824-1. Clause 36

NumericString | - see ISO/IEC 8824-1, Clause 36

UTF8String - see ISO/IEC 8824-1. Clause 36

ITS-DD-ReferencedType ::=

typereference | - see ISO/IEC 8824-1. Clause 11.2

Extemaltypereference ( - see ISO/IEC 8824-1. Clause 13.4

GeneralizedTime | -see ISO/IEC 8824-1. Clause 41

ObjedDescriptor - see ISO/IEC 8824-1. Clause 43

ITS-DD-ConstrainedType

ITS-DD-Type Constraint - see ISO/IEC 8824-1. Gause 44.5

- for definition of constraint

Если тип является ссылочным типом или внешним ссылочным типом, то ссылка должна быть типом наименования ASN. 1.

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

Десятичное число с перемещаемой запятой может быть получено из реального типа.

UTF8Stnng используется для типа символьной строки е случае обмена информацией на международном уровне. BMPString и lASString могут использоваться в регисгре/РД сграны/словаре данных.

Типы BMPString и IA5String — это подмножества типа UTFSString. Испогъэование ограничений для алфавитов BMPStnng (для Unicode) и lASString (для ASCII) может быть более эффективным кодированием, чем испогъэование UTF8String: если ограничение отсутствует. UTFSString мажет быть более эффективным кодированием, чем BMPString.

Допустимые диапазоны значений, списки значений для перечисленных типов или правила для значений о валидации для области значений элементов данных как часть метаданных присутствуют в ГД и/или РД, а также в определении модуля ASN.1.

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

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

Примечание — Для отправителей версии ASN.1 настоятельно рекомендуется указывать маркеры расширения при необходимости. Например, в элементе «ТС типа ENUMERATED (неизвестный. ТС. тяжеловесный транспорт.....)» для включения возможных дополнений необходимо поставить многоточие.

Б.5.1.4 Описание области значений данных

Текст этого метаатрибута должен состоять из полного и синтаксически правильного определения модуля ASN.1. Идентификатор для этого модуля предоставляется определителем модуля и не совпадает с метаатрибутом идентификатора модуля ASN.1, который определяет регистрационную запись. Определение модуля не должно содержать формулировки импорта данных. Модуль должен содержать одно определение типа ASN.1. Это понятие определяет тип области значения, и после этого оно должно быть экспортировано. В рамках определения этого типа должны использоваться только конструкторы ASN.1: последовательность, последовательность чего-либо и выбор, вместе с базовыми типами ASN.1, определенными е Б.5.1.3. возможно, с применением ограничения ко всем типам или тогъко к использованию конструкции «последовательность чего-либо».

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

Б.5.2 Формат

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

Конкретное размещение зависит от типа данных в области значений.

Б.5.3 Единица измерения

Это описание единиц измерения. Для единиц, которые возможно пересчитать, таких как оборудование или единицы выпуска, стандарт определяется с использованием этого метаагрибута.

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

Б.5.4 Действующее правило допустимого значения

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

ЛИСТ 340—-2018

Несмотря на то что точный формат абстрактного обмена данными определяется метаатрибутом «тип данных». допустимое правило значения может использоваться для дальнейшего ограничения допустимых значений (например, из-за взаимодействий с другими понятиями данных) или обеспечения определения текста на языке формата данных.

Б.6 Метаатрибуты администрирования

Б.6.1 Регистрационный статус

Эго административный или качественный уровень, присвоенный концепции данных в соответствии с его статусом в качественной иерархии (или промежуточный административный статус между качественными уровнями).

Правовые ценности для уровней качественного статуса регистрации — это «Карта». «Проект», «Записанный». «Соответствующий» и «Предпочтительный»: правовые ценности для уровней статуса административной регистрации — это «Предварительно соответствующий», «Предварительно предпочтительный» и «Удаленный».

Б.6.2 Дата регистрации

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

Значение этого мвтаагрибута автоматически назначается РД ИТС.

Б.6.3 Дата последнего изменения

Это дата, занесенная в РД последней версии концепции данных.

Значение этого мвтаагрибута автоматически назначается РД.

Б.6.4 Пользователь, который внес последнее изменение

Имя доступа лица, внесшего последнее изменение в концепцию данных. Значение этого мвтаагрибута автоматически назначается РД.

Б.6.5 Имя организации-регистратора

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

Б.б.в Номер регистратора

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

Б.6.7 Имя оператора системы

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

Б.6.8 Пользователь

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

Значения этого метаатрибута поддерживаются через список контролируемых слов авторизованных пользователей.

Б.6.9 Вид

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

Б.6.10 Связанные группы

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

Б.6.11 Качество безопасности

Это уровень защиты информации от несанкционированного доступа, связанного с концепцией данных. Такая защита относится к степени доступа, допустимой к концепции данных.

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

34

1

См. (2|—(4).