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

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

Утвержден и введен в действие Приказом Федерального

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

Intelligent transport systems. Determination

ОКС 35.240

Предисловие

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

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

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

Введение

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

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

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

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

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

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

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

<*> См. [1] - [4].

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

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

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

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

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

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

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

Настоящий стандарт распространяется на интеллектуальные транспортные системы (ИТС).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Сокращения

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

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

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

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

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

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

<*> См. [2].

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

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

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

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

6.3 Структура

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

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

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

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

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

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

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

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

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

6.4.1 Общий обзор

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

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

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

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

а) «Карта»

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

б) «Проект»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<*> См. [2] - [4].

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

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

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

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

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

6.10 Сообщение

Сообщение должно представлять собой структурированную группировку элементов данных и/или таблиц данных. На рисунке 3 показан пример сообщения «Когда (в какое время)-автобус-nnn_прибудет-на-перекресток-yyy:сообщение». В приложении Д рассмотрены особенности и примеры использования информационных объектов в 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» — это также уникальный идентификатор для каждой концепции данных.

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

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

• идентификатор концепции данных;
• версия концепции данных;
• описательное имя;
• синонимичные описательные имена;
• символические имена;
• имя ASN.1;
• идентификатор объекта ASN.1;
• единый указатель ресурсов (URL).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• статус регистрации;
• дата регистрации;
• дата последнего изменения;
• пользователь последнего изменения;
• название организации регистратора;
• телефонный номер регистратора;
• название организации сервиса данных (оператора системы);
• номер телефона организации сервиса данных (оператора системы);
• название организации-отправителя;
• номер телефона отправителя;
• пользователь;
• просмотр;
• связанные группы;
• класс безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А.1 Введение

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

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

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

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

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

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

в) рассмотрение операторами системы РД процедуры и стандартных форматов РД;

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

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

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

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

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

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

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

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

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

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

п) контроль списка кодов РД.

А.1.2 Сервис

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А.1.5 Структура контроля за изменениями

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А.3.1 Обзор

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А.5.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• шаг 5а: каждый сервис, связанный с решением проблем данных, несет ответственность за получение соответствующих разрешений комитета по стандартизации (в соответствии с их собственными внутренними процедурами) для решения проблем элементов данных, требующих изменений или добавлений в их сервисе элементов данных. Промежуточные статусы решения прогнозируются, пока сервисы работают с конкретными стандартами технического комитета при их наличии;
• шаг 6: не менее чем за 2 нед до проведения собрания операторов системы регистратор должен распространить сводные перечни всех концепций данных, потенциально предназначенных к рассмотрению, вместе с текущими статусами решений по каждой концепции данных и изложить все метаатрибуты для каждой рассматриваемой концепции данных. Этот список должен быть направлен в электронном виде всем сервисам;
• шаг 7: сервисы могут сообщать о любых проблемах, связанных с этим списком РД по крайней мере за 1 нед до проведения собрания операторов системы, для того чтобы подготовить полный пакет документов для собрания, отражая самые последние статусы согласования проблем. Регистратор должен направить оригинал списка и все замечания, полученные от сервиса, оператору системы как минимум за 1 нед до собрания;
• шаг 8: оператор системы должен распространить согласованный список среди операторов системы;
• шаг 9: операторы системы рассматривают результаты согласования и направляют указания регистратору. Для тех концепций данных, по которым достигнуто согласование между необходимыми сервисами, операторы системы пересматривают и утверждают согласованный статус сервера или требуют те согласованные добавления, которые необходимы. Операторы системы пересматривают концепции данных, которые не компетентны решить или предложить решения при необходимости. Регистратор оставляет такие концепции данных вместе с текущим статусом согласования на листе согласования до конца принятия решения до тех пор, пока технический комитет не утвердит решение, а операторы системы — окончательный статус согласования. Эти концепции данных включаются в следующий список согласования проблем шага 2;
• шаг 10: элементы данных, которые в итоге утверждены при согласовании, удаляются из списка согласования и помещаются в архивный файл в качестве постоянной записи решения согласования. Регистратор обеспечивает размещение всех согласованных статусов всех рассматриваемых концепций данных в соответствующие концепции данных РД.

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

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

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

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

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

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

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

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

Таблица А.1

Пример списка обобщения

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

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

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

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

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

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

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

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

Это описательное слово или словосочетание, которое помечает концепцию данных. Описательные имена должны быть оформлены в соответствии с требованиями раздела 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, не внесена в запросы ИТС по безопасности РД и/или к данным словарей, то URL вычисляет месторасположение и способ входа в концепцию данных.

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

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

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

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

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

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

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

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

Б.3.4 Источник

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

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

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

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

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

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

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

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

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

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

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

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

б) свойство;

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

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

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

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

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

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

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

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

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

Б.3.10 Контекст

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Б.4.3 Преемник

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

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

Б.4.4 Синоним

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

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

Б.4.5 Резюме

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

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

Б.4.6 Роли

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

«<object class[1] name>»,«<role[1] name>»,«<object class[2] name>»,«<role[2] name>», ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сообщения должны быть идентифицированы с использованием метаатрибута объекта идентификатора 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. Как правило, встречающиеся последовательности или другие группировки элементов данных могут обрабатываться с использованием концепции «Таблицы данных».

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

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

Б.5.1.2 Описание для таблиц данных

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

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

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

ITS-DD-Type::=

ITS-DD-BuiltinType |

ITS-DD-ReferencedType |

ITS-DD-ConstrainedType

ITS-DD-BuiltinType::=

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

IntegerType | -- see ISO/IEC 8824-1, Clause 18

EnumeratedType | -- see ISO/IEC 8824-1, Clause 19

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

BitStringType | -- see ISO/IEC 8824-1, Clause 21

OctetStringType | -- see ISO/IEC 8824-1, Clause 22

NullType | -- see ISO/IEC 8824-1, Clause 23

TaggedType | -- see ISO/IEC 8824-1, Clause 30

ObjectIdentifierType | -- see ISO/IEC 8824-1, Clause 31

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

IA5String | -- 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

Externaltypereference | — see ISO/IEC 8824-1, Clause 13.4

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

ObjectDescriptor -- see ISO/IEC 8824-1, Clause 43

ITS-DD-ConstrainedType::=

ITS-DD-Type Constraint -- see ISO/IEC 8824-1, Clause 44.5

• for definition of constraint

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

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

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

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

Типы BMPString и IA5String — это подмножества типа UTF8String. Использование ограничений для алфавитов BMPString (для Unicode) и IA5String (для ASCII) может быть более эффективным кодированием, чем использование UTF8String; если ограничение отсутствует, UTF8String может быть более эффективным кодированием, чем 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 Действующее правило допустимого значения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Б.6.9 Вид

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

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

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

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

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

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

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

ТРЕБОВАНИЯ К МЕТААТРИБУТАМ ДЛЯ КОНЦЕПЦИЙ ДАННЫХ

В.1 Введение

В приложении представлены таблицы В.1 - В.4, которые определяют требования для включения метаатрибутов в РД для каждой концепции данных. В данных таблицах определены требования для включения метаатрибутов в ГД для каждой концепции данных. Определение данных метаатрибутов приведено в приложении Б.

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

Ячейки 3 - 11 таблицы В.1 содержат код, который указывает, является ли метаатрибут определенной строки обязательным, необязательным, условным, индикативным, автоматически назначенным или неприменимым для концепции данных в конкретном столбце.

Коды выглядят следующим образом:

• M — обязательный (mandatory). Обязательные метаатрибуты необходимы для ссылок на все концепции данных без исключения;
• O — необязательный (optional). Необязательные метаатрибуты могут быть реализованы при желании по направлению функциональной области ГД;
• C — условный (contingent). Условными метаатрибутами являются те, которые зависят от реализации необязательных метаатрибутов. Они требуются, когда реализуется необязательный метаатрибут, от которого они зависят;
• I — индикативный (indicative). Индикативные метаатрибуты зависят от условия «если», которое не зависит от другого метаатрибута. Если условие «если» применимо, тогда метаатрибут «I» является обязательным, в противном случае он не используется;
• A — назначенный (assigned). Значение этого метаатрибута автоматически назначается для ввода информации о типах данных, введенных в РД;
• N/A — неприменяемый (not applicable).

Графа «Примечания» таблиц В.1 - В.4 объясняет характер каждого метаатрибута и предоставляет другую пояснительную информацию.

Примечание - Для каждого метаатрибута разрешено использовать только одно значение, если только оно не относится к категории «Разрешено множество значений».

В.2 Требования к метаатрибутам для реестра данных

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

Таблица В.1

Основные метаатрибуты для РД

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

    name       PersonName

    age       Age,

    address    HomeAddress

}<br>

    PersonName    : : = VisibleString (SIZE(1..64))

    Age     ::= INTEGER (0..160)

    HomeAddress   ::= VisibleString (SIZE(1..100))

или иначе,<br>
PersonnelInfo::=SEQUENCE {<br>

    name        VisibleString (SIZE(1..64)),

    age       INTEGER (0..160),

    address     VisibleString (SIZE(1..100))

}

    typedef  char                   PersonName[65];

    typedef  unsigned short        Age;

    typedef  char                   HomeAddress[101];

    typedef  struct {

    PersonName       name;

    Age       age;

    HomeAddress      address;

}PersonnelInfo;

Таблица Г.1

Структура информационного пакета

Поле <data_size> определяет размер данных, находящихся в поле . Для незашифрованных пакетов поле <data_size> всегда равно размеру передаваемых данных. Если данные передаются в зашифрованном виде, размер поля равен длине данных, выровненной по границе 8 байт, при этом дополнительные байты в расшифрованном пакете не используются.

Поле определяет опции пакета:

• NPL_FLAG_CRC, которая устанавливает, что для данного пакета рассчитано CRC (0 — нет, 1 — да). Если отправитель пакета рассчитывает CRC, он должен выставить данный флаг; в таком случае получатель имеет возможность проверить валидность пакета;
• NPL_FLAG_ENCRYPTION, которая устанавливает, что поле зашифровано (0 — нет, 1 — да). Поле шифруется по алгоритму Blowfish;
• остальные биты не используются.

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

Поле определяет тип данных в поле :

• NPL_TYPE_ERROR — ошибка протокола NPL;
• NPL_TYPE_NPH — пакет NPH;
• NPL_TYPE_DEBUG — отладочная информация.

Поле <peer_address> определяет адрес (а также тип) участника соединения или широковещательный адрес:

• NPL_ADDRESS_SERVER — сервер;
• NPL_ADDRESS_BROAD_DISPATHERS — все диспетчеры в группе;
• NPL_ADDRESS_BROAD_DEVICES — все мобильные устройства в группе;
• NPL_ADDRESS_BROAD_ALL — все участники-клиенты в группе;
• NPL_ADDRESS_RESERVED_MIN... ---NPL_ADDRESS_RESERVED_MAX — зарезервированные адреса;
• NPL_ADDRESS_DEVICE_MIN... NPL_ADDRESS_DEVICE_MAX — адреса мобильных устройств;
• NPL_ADDRESS_DISPATHCER_MIN... NPL_ADDRESS_DISPATHCER_MAX — адреса диспетчеров;
• NPL_ADDRESS_INVALID — не используется.

Сервер и клиент интерпретируют данное поле по-разному:

• для сервера поле <peer_address> входящего пакета указывает, кому адресован пакет. Если <peer_address> равно нулю, то данный пакет адресован серверу, поэтому сервер должен обработать такой пакет. Иначе <peer_address> указывает адрес клиента, которому адресован пакет, тогда сервер должен ретранслировать такой пакет указанному клиенту, указав в поле <peer_address> пакета адрес клиента, от которого данный пакет получен. В случае ошибки, к примеру целевой клиент недоступен или занят, сервер должен уведомить об этом клиента, отправившего пакет;
• для клиента поле <peer_address> входящего пакета указывает, от кого поступил данный пакет. В исходящем пакете указывается, кому предназначен данный пакет (см. таблицу Г.3).

Таблица Г.3

Поле <peer_address>

Далее представлены примеры передачи пакетов: в круглых скобках указан адрес участника соединения; в квадратных — пакеты, > и < — направление передачи.

Передача клиент-сервер:

• запрос

CLIENT(100)>[peer_address = 0 [data]]>SERVER(0)

• ответ

CLIENT(100)<[peer_address = 0 [data]]<SERVER(0)

Передача клиент-клиент (сервер ретранслирует пакеты, заменяя в них поле <peer_address>):

• запрос

CLIENT(100)>[peer_address = 200 [data]]>SERVER(0)>[peer_address = 100 [data]]>CLIENT(200)

• ответ

CLIENT(100)<[peer_address = 200 [data]]<SERVER(0)<[peer_address = 100 [data]]<CLIENT(200)

Ошибка передачи клиент-клиент:

• запрос

CLIENT(100)>[peer_address = 200 [data]]>SERVER(0) ---//no conneciton//--- CLIENT(200)

• ответ

CLIENT(100)<[peer_address = 0 [error]]<SERVER(0)

Для защищенного соединения сервер выполняет перешифровку пакетов в передаче клиент-клиент.

Типы пакетов:

• ошибки протокола нижнего уровня передаются в пакетах NPL_TYPE_ERROR. Формат поля представлен в таблице Г.4.

Таблица Г.4

Формат поля протокола нижнего уровня

• пакеты протокола верхнего уровня передаются в пакетах NPL_TYPE_NPH. Формат поля представлен в таблице Г.5.

Таблица Г.5

Формат поля протокола верхнего уровня

Г.4.3 Уровень представления

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

Рекомендуется ID (поле <request_id>) пакетов делать уникальным как минимум в рамках одной сессии передачи данных. Например, выбрать некоторое значение ID при установке соединения и для каждого последующего пакета увеличивать его ID на единицу. При достижении 0xFFFFFFFF следующее значение ID будет равно 0x00000000 и т.д.

Поле является необязательным. Наличие и структура поля должны однозначно определяться типом обслуживания (<service_id>) и типом пакета (поле ).

Обмен данными на уровне представления ведется с помощью пакетов NPH. Формат пакета NPH представлен в таблице Г.6.

Таблица Г.6

Формат пакета NPH

Г.4.4 Прикладной уровень (типы обслуживания)

Типы обслуживания:

• NPH_SRV_GENERIC_CONTROLS — основные команды. Данная услуга должна поддерживаться всеми участниками соединения;
• NPH_SRV_NAVDATA — передача данных;
• NPH_SRV_EXTERNAL_DEVICE — передача данных от дополнительных устройств;
• NPH_SRV_FILE_TRANSFER — передача файла;
• NPH_SRV_SERVER_GENERIC — команды, предназначенные для обработки сервером сбора данных;

[destination] --- <запрос на передачу данных> ----> [source]

[destination] <--- NPH_RESULT ---- [source]

• передача данных идет как последовательность операции «данные — подтверждение»:

[source] --- <данные> ----> [destination]

[source] <--- NPH_RESULT ---- [destination]

• запрос окончания передачи:

[destination] <--- <конец передачи данных> ---- [source]

[destination] --- NPH_RESULT ---> [source]

В случае отказа или ошибки передачи любая из сторон должна послать пакет NPH_RESULT с кодом ошибки.

Г.4.5 Основные команды

Г.4.5.1 Установка соединения с сервером

Соединение с сервером может быть защищенным или незащищенным. Параметры соединения задаются инициатором соединения в поле <connection_flags> пакета NPH_SGC_CONN_REQUEST.

В первом случае все пакеты передаются в зашифрованном виде, за исключением пакетов установки соединения:

• NPH_SGC_CONN_REQUEST
• NPH_SGC_CONN_AUTH_STRING

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

• клиент посылает запрос на установку незащищенного соединения:

[client] --- NPH_SGC_CONN_REQUEST ---> [server]

• сервер проверяет настройки и тип клиента, а также разрешение использовать незащищенное соединение данному клиенту и посылает подтверждение:

[client] <--- NPH_RESULT --- [server]

Пакет запроса установки соединения представлен в таблице Г.8.

Таблица Г.8

Пакет запроса установки соединения

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

• клиент посылает запрос на установку защищенного соединения:

[client] --- NPH_SGC_CONN_REQUEST ---> [server]

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

[client] <--- NPH_SGC_CONN_AUTH_STRING --- [server]

• клиент шифрует своим ключом blowfish полученный массив данных и отправляет его серверу:

[client] --- NPH_SGC_CONN_AUTH_STRING ---> [server]

• сервер расшифровывает своим ключом blowfish полученный массив данных, сравнивает его с данными, отправленными в пакете NPH_SGC_CONN_AUTH_STRING, и посылает подтверждение клиенту:

[client] <--- NPH_RESULT --- [server]

Пакет с массивом данных для аутентификации клиента представлен в таблице Г.9.

Таблица Г.9

Пакет с массивом данных для аутентификации клиента

В случае отказа в установке соединения (на любом этапе) сервер посылает клиенту незашифрованный пакет NPH_RESULT с кодом ошибки.

Поля <proto_version_high> и <proto_version_low> определяют версию протокола, по которой собирается работать клиент.

Поле <connection_flags> определяет настройки соединения, которые будут использованы после установки соединения.

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

СПЕЦИФИКАЦИЯ ИНФОРМАЦИОННЫХ ОБЪЕКТОВ ASN.1, ИСПОЛЬЗУЕМЫХ ДЛЯ ФОРМИРОВАНИЯ И РЕГИСТРАЦИИ ДАННЫХ

Д.1 Общие положения

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

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

Д.2 Спецификация концепции данных

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

Д.3 Рекомендуемая практика

В подразделе Д.4 представлена спецификация информационных объектов ASN.1 для концепции данных обновляемого РД на основе метаатрибутов, приведенных в таблицах В.1 и В.2 и указанных как обязательные. РД требуются в спецификации информационных объектов, тогда как необязательные, условные и индикативные метаатрибуты считаются необязательными в данной спецификации.

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

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

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

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

В этом подразделе приведена спецификация информационных объектов ASN.1 для концепции данных обновляемого РД в ИТС:

BEGIN

• ЭКСПОРТ в ИТС СООБЩЕНИЙ, КАСАЮЩИХСЯ БЕЗОПАСНОСТИ И ЧС: диалоговый интерфейс, сообщение, таблица данных, класс объекта, соотношение данных, свойство, понятие элемента данных, область значений, элемент данных -

ITS SAFETY MESSAGES -OBJECT-CLASS, ITS SAFETY MESSAGES -PROPERTY, ITS SAFETY MESSAGES -VALUE-DOMAIN, ITS SAFETY MESSAGES -DATA-ELEMENT-CONCEPT, ITS SAFETY MESSAGES -DATA-ELEMENT, ITS SAFETY MESSAGES -DATA-FRAME, ITS SAFETY MESSAGES -MESSAGE, ITS SAFETY MESSAGES -INTERFACE-DIALOGUE, ITS SAFETY MESSAGES -ASSOCIATION;

• Типовые ссылки для часто используемых типов: Integer32::=INTEGER (0..2147483647) Name::=UTF8String (SIZE(0..160)) OID::=OBJECT IDENTIFIER Url::=UTF8String (SIZE(0..63)) Text::=UTF8String (SIZE(0..2147483647)) String::=UTF8String (SIZE(0..255)) DataConceptType::=ENUMERATED {-- см. раздел В.3.8 object-class, property, value-domain, data-element-concept, data-element,

      data-frame,<br>
      message,<br>
      interface-dialogue,<br>
      association,

      ...}

MetaDataSource::=ENUMERATED {-- see clause В.3.12 direct,

      **indirect,**<br>
      **embedded }**<br>
      **DataConceptReference::=String**<br>

      Проект draft,
      Записанный recorded,
      Соответствующий qualified,
      Предпочтительный preferred},
      administrative ENUMERATED {
      provisionally-qualified,
      provisionally-preferred,
      retired }}

ITS SAFETY MESSAGES -DATA-CONCEPT::=CLASS

• Этот класс используется для спецификации в ИТС базы данных сообщений, касающихся безопасности и ЧС (ITS SAFETY MESSAGES data) -
• включая:
• идентификационный метаатрибут «Описательное имя»;
• метаатрибут «Определение»;
• репрезентативный метаатрибут «Область значений»;
• метаатрибуты администрирования для ведения записей.
• Версия: .._
• Дата: _ _ _ - - _
• примечание:
• Концепция данных сообщений, касающихся безопасности и ЧС в ИТС, содержит необязательные поля, кроме данных, указанных в таблице В.1 и В.2 и определяющих соответствующий метаатрибут как обязательный для всех концепций данных -
• Если поле помечено как необязательное, его наличие или отсутствие в определении экземпляра любой заданной концепции данных зависит от аннотации в соответствующей ячейке этих таблиц следующим образом:
• M или A: должны быть представлены в спецификации информационных объектов (IOS);
• N/A: не должны быть представлены в IOS (отсутствуют);
• I или C: должны присутствовать в IOS тогда и только тогда, когда это удовлетворяет условиям записи;
• O: Присутствие в IOS необязательно.

{

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

&dataConceptIdentifier Integer32 UNIQUE,

&dataConceptVersion Integer32,

&descriptiveName Name,

&synonymousDescriptiveNames SEQUENCE (SIZE (1..15)) OF Name OPTIONAL,

• Ограничение размера ограничивает количество имен в последовательности.

&symbolicNames SEQUENCE (SIZE (1..15)) OF Name OPTIONAL,

&aSNName Name OPTIONAL,

&asnObjectIdentifier OBJECT IDENTIFIER,

&uniformResourceLocator Url OPTIONAL,

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

&definition Text,

&descriptiveNameContext SEQUENCE (SIZE (1..15)) OF Name,

&symbolicNameUsage SEQUENCE (SIZE (1..15)) OF Name OPTIONAL,

&source SEQUENCE (SIZE (1..15)) OF String OPTIONAL,

&architectureReference SEQUENCE (SIZE (1..15)) OF Name OPTIONAL,

&architectureName SEQUENCE (SIZE (1..15)) OF String OPTIONAL,

&architectureVersion SEQUENCE (SIZE (1..15)) OF String OPTIONAL,

&dataConceptType DataConceptType,

&remarks Text OPTIONAL,

&context Text OPTIONAL,

&standard String OPTIONAL,

&metaDataSource MetaDataSource OPTIONAL,

&priority String OPTIONAL,

&frequencyOrMessageMode String OPTIONAL,

&deliveryVerification String OPTIONAL,

&dataQuality String OPTIONAL,

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

&precursor SEQUENCE (SIZE (1..15)) OF DataConceptReference OPTIONAL,

&successor SEQUENCE (SIZE (1..15)) OF DataConceptReference OPTIONAL,

&synonym SEQUENCE (SIZE (1..15)) OF DataConceptReference OPTIONAL,

&abstract BOOLEAN OPTIONAL,

&roles Text OPTIONAL,

&Multiplicity Integer32 OPTIONAL,

• Множество значений (подтип Integer32) содержит допустимые значения — см. Б.4.7

&associationConstraints String OPTIONAL,

&aggregate BOOLEAN OPTIONAL,

&roleKey String OPTIONAL,

&referencedMessages SEQUENCE (SIZE(1..255)) OF OID OPTIONAL,

&referencedDataFrames SEQUENCE (SIZE(1..255)) OF OID OPTIONAL,

&referencedDataElements SEQUENCE (SIZE(1..255)) OF OID OPTIONAL,

&referencedObjectClasses SEQUENCE (SIZE(1..255)) OF OID OPTIONAL,

&referencedAssociations SEQUENCE (SIZE(1..255)) OF OID OPTIONAL,

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

&dataType Text OPTIONAL,

&format Text OPTIONAL,

&unitOfMeasure String OPTIONAL,

&validValueRule Text OPTIONAL,

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

&registrationStatus RegistrationStatus,

&dateRegistered GeneralizedTime,

&lastChangeDate GeneralizedTime,

&lastChangeUser Name,

&registrarOrganizationName Name,

&registrarPhoneNumber String,

&stewardOrganizationName Name,

&stewardPhoneNumber String,

&submitterOrganizationName Name,

&submitterPhoneNumber String,

&user SEQUENCE (SIZE (1..15)) OF Name,

&view String OPTIONAL,

&relatedGroups SEQUENCE (SIZE (1..15)) OF Name OPTIONAL,

&securityClass String OPTIONAL

}

WITH SYNTAX {

DATA-CONCEPT-IDENTIFIER &dataConceptIdentifier

DATA-CONCEPT-VERSION &dataConceptVersion

DESCRIPTIVE-NAME &descriptiveName

[SYNONYMOUS-DESCRIPTIVE-NAMES &synonymousDescriptiveNames]

[SYMBOLIC-NAMES &symbolicNames]

[ASN-NAME &aSNName]

ASN-OBJECT-IDENTIFIER &asnObjectIdentifier

[URL &uniformResourceLocator]

DEFINITION &definition

DESCRIPTIVE-NAME-CONTEXT &descriptiveNameContext

[SYMBOLIC-NAME-USAGE &symbolicNameUsage]

[SOURCE &source]

[ARCHITECTURE-REFERENCE &architectureReference]

[ARCHITECTURE-NAME &architectureName]

[ARCHITECTURE-VERSION &architectureVersion]

DATA-CONCEPT-TYPE &dataConceptType

[REMARKS &remarks]

[CONTEXT &context]

[STANDARD &standard]

[META-DATA-SOURCE &metaDataSource]

[PRIORITY &priority]

[FREQUENCY-OR-MESSAGE-MODE &frequencyOrMessageMode]

[DELIVERY-VERIFICATION &deliveryVerification]

[DATA-QUALITY &dataQuality]

[PRECURSOR &precursor]

[SUCCESSOR &successor]

[SYNONYM &synonym]

[ABSTRACT &abstract]

[ROLES &roles]

[MULTIPLICITY &Multiplicity]

[ASSOCIATION-CONSTRAINTS &associationConstraints]

[AGGREGATE &aggregate]

[ROLE-KEY &roleKey]

[REFERENCED-MESSAGES &referencedMessages]

[REFERENCED-DATA-FRAMES &referencedDataFrames]

[REFERENCED-DATA-ELEMENTS &referencedDataElements]

[REFERENCED-OBJECT-CLASSES &referencedObjectClasses]

[REFERENCED-ASSOCIATIONS &referencedAssociations]

[DATA-TYPE &dataType]

[FORMAT &format]

[UNIT-OF-MEASURE &unitOfMeasure]

[VALID-VALUE-RULE &validValueRule]

REGISTRATION-STATUS &registrationStatus

DATE-REGISTERED &dateRegistered

LAST-CHANGE-DATE &lastChangeDate

LAST-CHANGE-USER &lastChangeUser

REGISTRAR-ORGANIZATION-NAME &registrarOrganizationName

REGISTRAR-PHONE-NUMBER &registrarPhoneNumber

STEWARD-ORGANIZATION-NAME &stewardOrganizationName

STEWARD-PHONE-NUMBER &stewardPhoneNumber

SUBMITTER-ORGANIZATION-NAME &submitterOrganizationName

SUBMITTER-PHONE-NUMBER &submitterPhoneNumber

USER &user

[VIEW &view]

[RELATED-GROUPS &relatedGroups]

[SECURITY-CLASS &securityClass]

}

ITS SAFETY MESSAGES -OBJECT-CLASS::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Класс объекта» таблиц В.1 и В.2

ITS SAFETY MESSAGES -PROPERTY::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Свойство» таблиц В.1 и В.2

ITS SAFETY MESSAGES -VALUE-DOMAIN::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Область значений» таблиц В.1 и В.2

ITS SAFETY MESSAGES -DATA-ELEMENT-CONCEPT::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Понятие элемента данных» таблиц В.1 и В.2

ITS SAFETY MESSAGES -DATA-ELEMENT::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Элемент данных» таблиц В.1 и В.2

ITS SAFETY MESSAGES -DATA-FRAME::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Таблица данных» таблиц В.1 и В.2

ITS SAFETY MESSAGES -MESSAGE::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Сообщение» таблиц В.1 и В.2

ITS SAFETY MESSAGES -INTERFACE-DIALOGUE::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Диалоговый интерфейс» таблиц В.1 и В.2

ITS SAFETY MESSAGES -ASSOCIATION::=ITS SAFETY MESSAGES -DATA-CONCEPT

• Ограничено графой «Соотношение данных» таблиц В.1 и В.2

END

Д.5 Пример модуля элементов данных ИТС

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

BEGIN

• Версия: .._
• Дата: _ _ _ - - _

ИМПОРТ в ИТС СООБЩЕНИЙ, КАСАЮЩИХСЯ БЕЗОПАСНОСТИ И ЧС

{modules(0) class-definition(1)};

transportObjectType ITS SAFETY MESSAGES -DATA-ELEMENT::=

{

DATA-CONCEPT-IDENTIFIER 1234

DATA-CONCEPT-VERSION 1

DESCRIPTIVE-NAME

«TransportObject.type:code»

SYNONYMOUS-DESCRIPTIVE-NAMES

{«TransportObjectTypeCode»}

SYMBOLIC-NAMES {«TOTC»}

ASN-NAME

«transportObjectType»

ASN-OBJECT-IDENTIFIER

DEFINITION

«Тип транспортного объекта является классификатором для типа устройства (товарного элемента, упаковки, или единицы загрузки, или ТС, которое относится к транспортному процессу»

DESCRIPTIVE-NAME-CONTEXT {«AVI/AEI»}

SYMBOLIC-NAME-USAGE {«Monitoring application»}

SOURCE {«17262»}

ARCHITECTURE-REFERENCE {«Object Interaction number x»}

ARCHITECTURE-NAME {«AVI/AEI Intermodal Goods»

Transport Architecture»}

ARCHITECTURE-VERSION {«17261v14»}

DATA-CONCEPT-TYPE data-element

REMARKS «Транспортный объект определяется как представляющий груз, доставляемый ТС. Он имеет несколько атрибутов, которые описывают объект реального мира. Этот элемент данных относится к типу устройства. Декодирование идентификатора транспортного объекта зависит от типа устройства».

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

DATA-TYPE»

DEFINITIONS

AUTOMATIC TAGS::=

BEGIN

EXPORTS TransportObjectType;

TransportObjectType::=ENUMERATED{

goodsItem (0),

package (1), -- or load unit

transportMeans (2),

...}

-- See...

END

«»

FORMAT «ASN.1 encoding»

UNIT-OF-MEASURE «Not applicable»

VALID-VALUE-RULE «see the ASN.1 DATA-TYPE»

REGISTRATION-STATUS qualitative:draft

DATE-REGISTERED «200202200000Z»

LAST-CHANGE-DATE «200202200000Z»

LAST-CHANGE-USER «WG4 Editor»

REGISTRAR-ORGANIZATION-NAME «ISO TC204»

REGISTRAR-PHONE-NUMBER «+1 111-222-3333»

STEWARD-ORGANIZATION-NAME «ISO TC204 WG4»

STEWARD-PHONE-NUMBER «+1 111-222-3333»

SUBMITTER-ORGANIZATION-NAME «ISO TC204 WG4»

SUBMITTER-PHONE-NUMBER «+1 111-222-3333»

USER {«CWLuser1»}

VIEW «AVI/AEI»

RELATED-GROUPS {«Freight»}

SECURITY-CLASS «Type 1, Level 1»

}

END

Д.6 Пример модуля данных ИТС

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

BEGIN

• Версия: .._
• Дата: _ _ _ - - _

ИМПОРТ ТАБЛИЦ ДАННЫХ ИТС

transportObjectData ITS-DATA-FRAME::=

{

DATA-CONCEPT-IDENTIFIER 2345

DATA-CONCEPT-VERSION 1

DESCRIPTIVE-NAME «TransportObjectData:frame»

SYNONYMOUS-DESCRIPTIVE-NAMES {«LoadData»}

SYMBOLIC-NAMES {«TransportObjectMessageType»}

ASN-NAME «TransportObjectData»

ASN-OBJECT-IDENTIFIER

DEFINITION

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

DESCRIPTIVE-NAME-CONTEXT {«AVI/AEI»}

SYMBOLIC-NAME-USAGE {«Monitoring application»}

DATA-CONCEPT-TYPE data-frame

REMARKS

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

CONTEXT

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

REFERENCED-DATA-ELEMENTS

{{iso standard 17262 registry(1) entry(8)},

{iso standard 17262 registry(1) entry(9)},

{iso standard 17262 registry(1) entry(10)}}

DATA-TYPE»

ISO17262M2 {iso standard 17262 modules(0) dc2(2)}

DEFINITIONS

AUTOMATIC TAGS::=

BEGIN

EXPORTS TransportObjectData;

IMPORTS

TransportObjectType

FROM ISO17262M1

{iso standard 17262 modules(0) dc1(1)}

TransportObjectIdentifier

FROM ISO17262M9

{iso standard 17262 modules(0) dc9(9)}

TransportComponentStatus

FROM ISO17262M10

{iso standard 17262 modules(0) dc10(10)};

TransportObjectData::=SEQUENCE {

identifier TransportObjectIdentifier,

classification TransportObjectType OPTIONAL,

status TransportComponentStatus OPTIONAL,

...

}

END

«»

REGISTRATION-STATUS qualitative:draft

DATE-REGISTERED «200202200000Z»

LAST-CHANGE-DATE «200202200000Z»

LAST-CHANGE-USER «WG4Editor»

REGISTRAR-ORGANIZATION-NAME «ISO TC204»

REGISTRAR-PHONE-NUMBER «+1-222-333-4444»

STEWARD-ORGANIZATION-NAME «TK 057»

STEWARD-PHONE-NUMBER «+1-222-333-4444»

SUBMITTER-ORGANIZATION-NAME « TK 057»

SUBMITTER-PHONE-NUMBER«+1-222-333-4444»

USER{«CWLUser1»}

VIEW«AVI/AEI»

RELATED-GROUPS {«Freight»}

SECURITY-CLASS «type 1 level 1»

}

END

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

В данном подразделе представлен пример модуля сообщений, касающихся безопасности и ЧС, подготовленного в соответствии со спецификацией информационных объектов. Модуль основан на спецификации информационного объекта, представленной в подразделе Д.4:

BEGIN

• Версия: .._
• Дата: _ _ _ - - _

ИМПОРТ СООБЩЕНИЙ В ИТС

transponderInterrogateReturn ITS SAFETY MESSAGES -MESSAGE::=

{

DATA-CONCEPT-IDENTIFIER 3456

DATA-CONCEPT-VERSION 1

DESCRIPTIVE-NAME

«TransponderInterrogateReturn:message»

SYNONYMOUS-DESCRIPTIVE-NAMES {«TransportObjectMessageType»}

ASN-NAME «TransponderInterrogateReturn»

ASN-OBJECT-IDENTIFIER

{iso standard 17262 registry(1) entry(16)}

DEFINITION

«Это ответное сообщение содержит элементы, которые идентифицируют бортовое устройство в ответ на запрос. Эти элементы включают: TransportOjectIdentifier, TransportObjectType и TransportComponentStatus, которые встроены в таблицу данных TransportObjectData. В целях безопасности добавлен отдельный код проверки, импортированный как элемент данных».

DESCRIPTIVE-NAME-CONTEXT {«AVI/AEI»}

SYMBOLIC-NAME-USAGE {«Monitoring application»}

ARCHITECTURE-REFERENCE

{«Object interaction number 1»}

ARCHITECTURE-NAME

{«AVI/AEI Intermodal Goods Transport Architecture»}

ARCHITECTURE-VERSION {«17261v14»}

DATA-CONCEPT-TYPE message

META-DATA-SOURCE direct

PRIORITY «routine»

FREQUENCY-OR-MESSAGE-MODE «on demand»

DELIVERY-VERIFICATION «shall, retry three times»

REFERENCED-DATA-FRAMES

{{iso standard 17262 registry(1) entry(14)}}

REFERENCED-DATA-ELEMENTS

{{iso standard 17262 registry(1) entry(21)}}

DATA-TYPE»

ISO17262M3 {iso standard 17262 modules(0) dc3(3)}

DEFINITIONS

AUTOMATIC TAGS::=

BEGIN

EXPORTS TransponderInterrogateReturn;

IMPORTS TransportObjectData

FROM ISO17262M2

{iso standard 17262 modules(0) dc2(2)}

TransportValidationCode

FROM ISO17262M7

{iso standard 17262 modules(0) dc7(7)};

TransponderInterrogateReturn::=SEQUENCE{

objectdata TransportObjectData,

validationcode TransportValidationCode,

...

}

END

«»

REGISTRATION-STATUS qualitative:draft

DATE-REGISTERED «200202200000Z»

LAST-CHANGE-DATE «200202200000Z»

LAST-CHANGE-USER «TK 057»

REGISTRAR-ORGANIZATION-NAME «TK 057»

REGISTRAR-PHONE-NUMBER «+1 222-333-4444»

STEWARD-ORGANIZATION-NAME «TK 057»

STEWARD-PHONE-NUMBER «+1 222-333-4444»

SUBMITTER-ORGANIZATION-NAME «TK 057»

SUBMITTER-PHONE-NUMBER «+1 222-333-4444»

USER {«CWLuser1»}

}

END

Д.8 Пример описания области значений

Д.8.1 Область значений для идентификационного метаатрибута «имя ASN.1» представлена в таблице Д.1.

Таблица Д.1

Область значений для идентификационного метаатрибута «имя ASN.1»

Д.8.2 Логические области значений представлены в таблице Д.2.

Таблица Д.2

Логистические области значений

Д.8.3 Тип концепции данных для области значений представлен в таблице Д.3.

Таблица Д.3

Тип концепции данных для областей значений

Д.8.4 Память области значений представлена в таблице Д.4.

Множество области значений

Д.8.7 Тип области значений представлен в таблице Д.7.

Таблица Д.7

Тип области значений