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

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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

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

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

2019

Предисловие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• «Карта»;

-    «Проект»;

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

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

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

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

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

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

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

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

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

а)    «Карта»

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

б)    «Проект»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и чрезвычайных ситуаций

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

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

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

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

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

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

6.10    Сообщение

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

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

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

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

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

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

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

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

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

6.14    Свойство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-    имя ASN.1;

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

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

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

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

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

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

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

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

-    источник;

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

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

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

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

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

-    контекст;

-    стандарт;

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

-    приоритет;

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

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

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

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

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

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

-    прекурсор;

-    преемник;

-    синоним;

-    аннотация;

-    роли;

-    кратность;

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

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

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

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

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

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

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

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

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

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

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

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

-    тип данных;

-    формат;

-    единица измерения;

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

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

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

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

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

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

-    статус регистрации;

-    дата регистрации;

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

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

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

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

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

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

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

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

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

-    просмотр;

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

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

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

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

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

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

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

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

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

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

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

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

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

Концепция данных Формат данных описательных имен Класс объекта ObjectClassTerm Свойство propertyTerm Область значений value-domain-term Понятие элемента данных ObjectClassTerm propertyTerm Элемент данных ObjectClassTerm propertyTerm value-domain-term Таблица данных DataFrameTerm frame Сообщение MessageTerm message Диалоговый интерфейс SourceName<-lnterfaceDialog->DestinationName Соотношение данных RoteAObjectClassTerm <<associationtype»RoleBObjectClassTerm

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

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

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

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

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

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

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

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

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

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

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

А.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А.1.2 Сервис

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

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

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

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

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

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

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

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

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

ных

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

для обеспечения передачи сообщений, касающихся безопасности

и чрезвычайных ситуаций..................................................15

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

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

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

и чрезвычайных ситуаций..................................................43

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

Одной из серьезнейших проблем мирового масштаба является большое количество погибших и получивших травмы на дорогах. В России количество погибших на дорогах остается на очень высоком уровне: смертность на дорогах, согласно статистическим данным на 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Сокращения
В настоящем стандарте применены следующие сокращения:
ГД	— глоссарий данных;
ГЛОНАСС	— глобальная навигационная спутниковая система;
ДТП	— дорожно-транспортное происшествие;
итс	— интеллектуальная транспортная система;
тк	— технический комитет;
тс	— транспортное средство;
чс	— чрезвычайная ситуация;
РД	— реестр данных;
ASN.1	— abstract Syntax Notation One;
GPS	— global Positioning System;
М	— mandatory (обязательный);
О	— optional (необязательный);
с	— contingent (условный);
1	— indicative (индикативный);
А	— assigned (назначенный);
N/A	— not applicable (неприменяемый);
UML	— Unified Modeling Language.

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

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

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

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

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

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

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

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

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

6.3    Структура

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

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

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

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

-    РД:

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

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

См [2]

Разработчик и погъэоеа-вгм имтеппветуалыкай транспортной системы

Рисунок 1 — Операционная структура реестра данных интеллектуальной транспортной системы

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

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

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

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

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

Глоссарий данных Реестр данных Имеет множество источников Является единым (международным) реестром Охватывает единую функциональную область Охватывает множество источников Регулируется посредством сервисных структур единой функциональной области Регулируется структурами контроля изменений

Окончание таблиць11

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

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

6.4.1 Общий обзор

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

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

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

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

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

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

6.4.3    Сервис

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

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

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

1

См (2] {4).

2

См [1Н4]