ПНСТ 460-2020 Интеллектуальные транспортные системы. Кооперативные интеллектуальные транспортные системы. Часть 1. Роли и ответственность в контексте архитектуры кооперативных интеллектуальных транспортных систем

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

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

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

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

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

Часть 1

Роли и ответственность в контексте архитектуры кооперативных интеллектуальных транспортных систем

(ISO 17427-1:2018, NEQ)

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

Москва Стандарта нформ 2020

Предисловие

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

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

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

• 4 Настоящий стандарт разработан с учетом основных нормативных положений международного стандарта ИСО 17427-1:2018 «Интеллектуальные транспортные системы. Кооперативные ИТС. Часть 1. Роли и ответственность в контексте архитектуры кооперативных ИТС» (ISO 17427-1:2018 «Intelligent transport systems — Cooperative ITS — Part 1: Roles and responsibilities in the context of cooperative ITS architectures», NEQ)

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

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

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

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

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

Содержание

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

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

• 3 Сокращения

• 4 Соответствие

• 5 Соблюдение требований настоящего стандарта

• 5.1 Роли и обязанности при реализации кооперативных интеллектуальных

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

• 5.2 Руководство для разработчиков и исполнителей стандартов кооперативных

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

• 6 Общие положения

• 6.1 Использование определенной распределенной разработки

• 6.2 Передача ОРР-ролей и обязанностей кооперативных интеллектуальных

транслортных систем

• 6.3 Внешние объекты предприятия

• 6.4 Внутренние объекты предприятия

• 7 Роли и обязанности

• 7.1 Общее описание организационной архитектуры

• 7.2 Общие обязанности субъектов, вовлеченных в кооперативные интеллектуальные

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

• 7.3 Роль «функциональная операция»

• 7.4 Роль «системное управление»

• 7.5 Роль «работа системы»

• 7.6 Роль «политические рамки»

• 7.7 Профили

Приложение А (справочное) Методология и пример ее применения

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

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

Введение

Кооперативные интеллектуальные транспортные системы (КИТС) являются многообещающим усовершенствованием интеллектуальных транспортных систем (ИТС).

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

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

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

В настоящем стандарте описаны функции и обязанности поставщика услуг высокого уровня и представлено соответствие настоящего стандарта другим стандартам и спецификациям КИТС.

ПНСТ 460—2020

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

Интеллектуальные транспортные системы КООПЕРАТИВНЫЕ ИНТЕЛЛЕКТУАЛЬНЫЕ ТРАНСПОРТНЫЕ СИСТЕМЫ Часть 1

Роли и ответственность в контексте архитектуры кооперативных интеллектуальных транспортных систем

Intelligent transportation systems. Cooperative ITS.

Part 1. Roles and responsibilities in the context of cooperative ITS architecture

Срок действия — с 2021—06—01 до 2024—06—01

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

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

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

• 8 настоящем стандарте представлена методология для определения конкретных ролей и соответствующих обязанностей на основе процессно-ориентированного подхода, а также ролей и обязанностей КИТС в целом. Как методология, так и роли, и обязанности для КИТС (см. [2]—(4)) — это эталонная модель открытой распределенной обработки. В рамках открытой распределенной обработки изложены пять точек зрения, из которых точка зрения предприятия соответствует организационной архитектуре, ее ролям и обязанностям.

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

8 настоящем стандарте описана высокоуровневая архитектурная точка зрения на КИТС.

Настоящий стандарт предназначен для использования в качестве образца при реализации си* стем предоставления услуг на базе КИТС и соответствующих организационных структур. Функциональность КИТС позволяет обрабатывать и обмениваться значительным объемом данных/информации при строгом соблюдении конфиденциальности и защиты данных (см. [5]) в соответствии с требованиями действующего законодательства.

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

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

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

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

• 2.1 заинтересованная сторона: Физическое или юридическое лицо, имеющее долю или являющееся участником и наделенное правами в соответствии с его статусом.

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

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

• 2.4 действие: Факт или процесс совершения определенного действия.

Пример —Действие предпринимается, как правило, для достижения цели.

• 2.5 __________________________________________________________________________________________________

действующее лицо (actor): Организационная единица, исполняющая определенные специальные роли при реализации системы.

((6]. пункт 2.2]

• 2.6 домен BSDM: Прикладные процессы, осуществляемые в контролируемой среде, состоящей из уровня средств станции ИТС. уровня сетей и транспорта станции ИТС. уровня доступа и объекта управления и объекта безопасности, который придерживается минимального набора принципов и процедур безопасности кооперативных интеллектуальных транспортных систем.

• 2.7 жизненный цикл данных/процесс: Процесс на основе преобразования элемента данных.

• 2.8 задача: Действие, выполняемое ролью.

• 2.9 __________________________________________________________________________________________________

инфраструктура (infrastructure): Система средств, оборудования и услуг, необходимых для дея-

гельнисти организации.

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

[(7]. пункт 3.5.2]

• 2.10 сервис кооперативных интеллектуальных транспортных систем: Сервис, предоставляющий преимущества получателю услуги.

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

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

• 2.13 ________________________________________________________________________________________

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

Примечание — В качестве альтернативы подмножеству КИТС можно рассматривать как «парадигму» в общем составе интеллектуальных транспортных систем.

[[6]. пункт 2.1]

• 2.14 обслуживание в режиме нажатия: Служба интеллектуальных транспортных систем, работающая с данными. поступившими без запроса со стороны субъекта или его системы.

• 2.15 сервис в режиме отпускания: Сервис интеллектуальных транспортных систем, оперативно запрашивающий данные, необходимые для его работы.

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

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

• 2.18 ответственность: Уровень ответственности для объекта, функции, системы, службы безопасности или установленные обязательства.

Примечание — Ответственность может заключаться в юридически обоснованном назначении действий и ролей.

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

• 2.20 поведение: Совокупность действий, ограниченных временем их действия.

• 2.21 последовательная обработка: Процесс, основанный на последовательном выполнении действий.

• 2.22 точка зрения: Точка зрения на систему открытой распределенной обработки и ее среду, которая фокусируется на цели, области применения и политике этой системы.

• 2.23 ________________________________________________________________________________________

приложение (application/app): Программный механизм предоставления некоторых или всех частей определенной услуги.

Ц7]. пункт 3.2]

• 2.24 ________________________________________________________________________________________

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

П6]. пункт 3.4.1]

• 2.25 цепочка; Последовательность процессов, ожидающих в фоновом режиме события.

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

• 2.26 роль: Исполнение задачи, соответствие поведению и обязанностям, определяемым действующим лицом.

• 2.27 система: Набор взаимодействующих или взаимозависимых компонентов, образующих единое целое.

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

• 2.28 сообщество: Конфигурация объектов, сформированная для достижения цели.

• 2.29 суброль: Подчиненная роль, состоящая из определенного фрагмента общей роли.

• 2.30 сценарий: Общее описание действий, совершаемых субъектами.

• 2.31 услуга: Услуга, предоставляемая действующему лицу.

• 3 Сокращения

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

КИТС — кооперативные интеллектуальные транспортные системы (cooperative ITS);

ГНСС — глобальная навигационная спутниковая система (global navigation satellite system);

ИТС — интеллектуальные транспортные системы (Intelligent transport systems. ITS);

OPP — открытая распределенная разработка (open distributed processing, OOP);

ОРО — открытая распределенная обработка (open distributed processing, ODP):

ЭМОРО — эталонная модель открытой распределенной обработки (reference model of open distributed processing. RM-ODP);

HMi — человеко-машинный интерфейс (human machine);

LDM — локальная динамическая карта (local dynamic map);

PKI — инфраструктура открытых ключей (public key infrastructure);

UML— унифицированный язык моделирования (unified modeling language).

• 4 Соответствие

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

• 5 Соблюдение требований настоящего стандарта

  • 5.1 Роли и обязанности при реализации кооперативных интеллектуальных транспортных систем

Эффективность внедрения КИТС определена последовательностью реализации их функционала.

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

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

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

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

В настоящем стандарте не рассмотрены такие аспекты КИТС, как базовая система, ответственность. конфиденциальность, управление рисками и т. д.

Примечание — Подробное описание вышеперечисленных аспектов в [8]. [9].

В 7.2 определены контекст, роли и обязанности и представлены контрольные списки, рекомендованные для использования при разработке результатов стандартов КИТС или при реализации приложения КИТС.

• 5.2 Руководство для разработчиков и исполнителей стандартов кооперативных интеллектуальных транспортных систем

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

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

• 6 Общие положения

  • 6.1 Использование определенной распределенной разработки

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

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

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

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

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

Примечания

• 1 См. также приложения и стандарты, которые должны быть отображены между этим обзором ОРР и более конкретными спецификациями приложений UML. в [12].

• 2 В [13] определено использование UML 2 для перевода специфических открытых распределенных систем в определения, имеющие различное описание, приведенное в ЭМОРО. UML 2 устанавливает набор профилей унифицированного языка моделирования: один — для каждого языка, а другой — для соответствия между различными параметрами, и в совокупности подход к их структурированию в соответствии с принципами ЭМОРО; UML 4 ОРО позволяет разработчикам моделей ОРР использовать записи UML для выражения спецификаций ОРР стандартным графическим способом, чтобы разработчики UML могли использовать концепции и механизмы ЭМОРО для структурирования богъших спецификаций системы UML в соответствии с развитым и стандартным предложением. Инструменты UML можно применять для обработки спецификаций точек зрения, облегчая процесс проектирования программного обеспечения, и спецификации архитектуры предприятия для крупных программных систем.

• 6.2 Передача ОРР-ролей и обязанностей кооперативных интеллектуальных транспортных систем

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

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

Внутренний объект предприятия связан с различными внешними объектами предприятия. Диа-грамма (см. рисунок 2) иллюстрирует как внешние объекты предприятия, так и внутренние объекты предприятия (см. рисунок 1) и ключевые отношения в контексте КИТС между внутренним объектом и внешними объектами предприятия.

Рисунок 2—Внешни» и внутренние корпоративны» объекты в коыыунмевцнк КИТС

• 6.2.1 Роль и обязанность КИТС на предприятии

Овал в центре на рисунке 2 представляет корпоративный домен КИТС (на рисунке 1 — «внутренний объект» в верхней части рисунка).

• 6.2.2 Датчики и приводы КИТС

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

В контексте ОРР — это внутренние объекты.

• 6.2.3 Приложения КИТС

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

В контексте ОРР — это внутренние объекты.

• 6.2.4 Станция ИТС (беспроводная или проводная)

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

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

• 6.3 Внешние объекты предприятия

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

а) Получатель услуг ИТС

Это пользователь, который получает услугу. Получатель услуги по определению является внешним объектом (см. рисунок 1).

б) Другие системы ИТС

Системы ИТС. которые вполне могут использовать коммуникационные возможности транспортного средства, но не предоставляют или не применяют данные или процессы КИТС (например, монито-ринг/реэервирование услуг, мониторинг температуры, управление парком машин и т. д.).

Другие ИТС являются внешним объектом (см. рисунок 1).

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

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

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

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

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

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

д) Юрисдикции/органы власти

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

Юрисдикция является внешним объектом (см. рисунок 1).

е) Органы стандартизации

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

Органы стандартизации являются внешним объектом (см. рисунок 1).

ж) Коммерческие/финансовые системы

Оплата большинства услуг КИТС производится по событию или подписке (например, плата за парковку, оптимизация маршрута и т. д.).

Коммерческие/финансовые системы являются внешним объектом (см. рисунок 1).

Следует учитывать, что КИТС — это средство достижения доставки услуг приложения.

Примечание — Отношения внешних и внутренних объектов КИТС (см. рисунок 2) также могут быть сопоставлены с другими подсистемами ИТС. Это подразумевает. что расположение объектов и их назначение внутренним и внешним объектом может быть изменено в других парадигмах.

• 6.4 Внутренние объекты предприятия

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

• 7 Роли и обязанности

  • 7.1 Общее описание организационной архитектуры

В общем виде организационной архитектуры определены четыре основные роли (см. рисунок 3).

• 7.1.1 Системные операции

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

• 7.1.1.1 Взаимодействие ролей

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

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

Работа ролевых систем взаимосвязана с ролью «функциональные операции». В этой взаимосвязи. обозначенной термином «используется» на рисунке 3. субъект(ы) с ролью «операции системы ролей» предоставляют(ет) систему субъекту(ам) с ролью «функциональной операции».

• 7.1.2 Функциональные операции

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

• 7.1.3 Системное управление

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

• 7.1.3.1 Взаимодействие ролей

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

• 7.1.4 Основы политики

Роль «основы политики» отвечает за все меры управления и институциональные мероприятия, требуемые в системе.

• 7.1.4.1 Взаимодействие ролей

Взаимосвязь структуры ролевой политики с работой ролевой системы и управлением ролевой системой определена в 8.1.1 и 8.1.3.

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

• 7.2 Общие обязанности субъектов, вовлеченных в кооперативные интеллектуальные транспортные системы

  • 7.2.1 Регистрация и авторизация

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

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

- оформление запроса на регистрацию в системе;

• • получение сертификатов для зарегистрированных станций ИТС.

• 7.2.1.2 Авторизация определена как авторизация перед каждым использованием системы, а именно:

• • оформление запроса на авторизацию;

• • Получение подтверждения авторизации.

Подробная информация о действиях относительно запроса на регистрацию или авторизацию и получения разрешения или подтверждения должна быть основана на стандартных механизмах регистрации и авторизации (см. [8]).

• 7.2.2 Конфиденциальность и защита данных

В определении КИТС (см. (14]) представлены их две основные характеристики:

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

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

Оба свойства приводят к серьезным последствиям для КИТС в отношении конфиденциальности и защиты данных.

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

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

Примечание — Каждая роль и. следовательно, каждый участник КИТС должны соблюдать [5].

Б целом это относится к следующим действиям;

■ сбор данных/информации (контента). Каждый участник, ответственный за собор данных/информации (включая передачу данных/информации от других сторон), обрабатывает эти данные/информа-цию с четким соблюдением конфиденциальности авторов (см. [5] и международные соглашения);

• - обработка данных/информации (контента). Каждый субъект, обрабатывающий данные/информацию. соблюдает установленные лри осуществлении данных действий принципы (см. [5] и международные соглашения);

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

• передача данных/информации (контента). Каждый участник, предоставляющий услугу, которая передает данные/информацию. четко соблюдает установленные принципы (см. (35] и международные соглашения).

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

• 7.3 Роль «функциональная операция»

  • 7.3.1 Общие сведения

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

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

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

Рисунок 4 — Взаимосвязь между общей и конкретной функциональной операциями

• 7.3.2 Суброль «общая функциональная операция»

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

• 7.3.2.1 Суброль «контент-провайдер»

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

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

• - на подлиску на предоставление контента;

• * отмену активности предоставления контента;

• * регистрацию контента (данных/информации);

• * отмену регистрации контента (данных/информации).

Примечание — Подробная информация о деятельности, связанной с регистрацией контента (данных/ информации), приведена в [1].

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

• - в получении запроса на контент;

• * получении контента (данных/информации) и предоставлении контента (данных/информации).

При этом предоставление содержимого суброли подразумевает обеспечение целостности данных.

• 7.3.2.2 Суброль «поставщик услуг»

Суброль «поставщик услуг» должна связывать поставщика содержимого суброли с субролью «получатель услуги».

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

До предоставления услуги ИТС требуется ее регистрация с ролью «управление каталогом услуг». Поставщик субролей несет ответственность за следующие действия:

• - подписание на предоставление ноеой услуги ИТС;

■ отмена регистрации сервиса ИТС.

Примечание — Детали данных действий описаны в [9].

Обязанности, связанные с поставщиком субролей, тесно увязаны с выполнением самой услуги, такой как:

• * получение запроса на обслуживание:

• * выбор услуги/приложения/алгоритма;

• - управление услугой/приложением/алгоритмом ИТС (генерация услуги);

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

• 7.3.2.3 Суброль «получатель услуги»

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

Следовательно, обязанности, связанные с субролью «получатель услуги», тесно увязаны с операцией обслуживания, например:

• * оформление запроса на обслуживание.

• - информация о предоставлении услуги;

• * принятие решения о предоставлении услуги;

• * подписка на услугу.

• 7.3.2.4 Суброль «специфическая функциональная операция»

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

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

• 7.3.2.5 Суброль «участник дорожного движения»

Суброль «участник трафика» суммирует участников трафика в конкретном сценарии КИТС.

Суброль «участник дорожного движения» состоит из субролей «водитель» и «водитель специального транипортниги средства».

• • субрсг\ь «водитель» участвует в конкретном сценарии КИТС в качестве водителя транспортного средства:

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

• 7.3.2.6 Суброль «оператор инфраструктуры»

Суброль «оператор инфраструктуры» объединяет объекты инфраструктуры, вовлеченные в конкретный сценарий КИТС.

Суброль «оператор инфраструктуры» состоит из субролей «оператор дороги» и «оператор дорожных работ»:

• - суброль «дорожный оператор» отвечает за эксплуатацию дороги;

• - суброль «оператор дорожных работ» отвечает за организацию дорожных работ.

• 7.3.2.7 Суброль «производитель»

Суброль «производитель» отвечает за производство продуктов, используемых в конкретном сценарии КИТС.

Суброль «производитель» состоит из субролей «производитель оборудования С2Х». «производитель транспортных средств» и «производитель инфраструктуры», эона ответственности которых следующая:

• - суброли «производительоборудования С2Х» — производство оборудования С2Х;

• - суброли «производитель транспортных средств» — производство транспортных средств;

• • суброли «производитель инфраструктуры» — производство продуктов инфраструктуры, используемых в конкретном сценарии КИТС.

• 7.4 Роль «системное управление»

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

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

Роль «системное управление» — это распределенная роль, состоящая из нескольких объектов.

• 7.4.1 Суброль «менеджер каталога услуг»

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

• - добавление новой услуги ИТС в каталог услуг;

• - удаление всех своих услуг из каталога услуг.

Примечание — Подробное описание приведено в [9].

• 7.4.2 Суброль «архитектор КИТС»

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

• 7.4.3 Суброль «менеджер изменений»

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

• 7.4.4 Суброль «менеджер тестирования»

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

• 7.4.5 Суброль «менеджер уровня сервиса»

Эта суброль должна отвечать за согласование договоренностей об уровне обслуживания КИТС и за обеспечение их соблюдения.

• 7.4.6 Суброль «менеджер по омологации»

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

• 7.4.7 Суброль «диспетчер соответствия»

Зона ответственности этой суброли — обеспечение соблюдения и применения стандартов, руководств и правил, установленных для КИТС.

• 7.4.8 Суброль «финансовый менеджер»

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

• 7.4.9 Суброль «владелец сервиса»

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

• 7.4.10 Суброль «руководитель проекта»

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

• 7.4.11 Суброль «менеджер информационной безопасности»

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

• 7.4.12 Суброль «менеджер конфиденциальности»

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

• 7.5 Роль «работа системы»

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

Прим еча ни© — Под ролью «работа системы» подразумеваются те суброли, которые определены в {15]. Причем КИТС будут использованы в отношении уровня их детализации и характеристик. При необходимости роли могут быть объединены и переименованы.

• 7.5.1 Суброль «менеджер мощности»

Зона ответственности этой суброли — обеспечение целевых показателей производительности.

• 7.5.2 Суброль «менеджер доступности»

Зона ответственности этой суброли — определение, анализ, планирование, измерение и улучшении всех аспектов Доступности системы.

• 7.5.3 Суброль «технический аналитик»

Зона ответственности этой суброли — предоставление технической экспертизы и поддержки для технического управления инфраструктурой КИТС.

• 7.5.4 Суброль «менеджер конфигурации»

Зона ответственности этой суброли — ведение информации об инфраструктуре/оборудовании. необходимых для обеспечения услуг КИТС.

• 7.5.5 Суброль «менеджер по ИТ-операциям»

Зона ответственности этой суброли — четкое функционирование и исполнение процессов.

• 7.5.6 Суброль «менеджер доступа»

Зона ответственности этой суброли — предоставление права использования услуги КИТС авторизованным пользователям и блокирование доступа неавториэованных пользователей.

• 7.6 Роль «политические рамки»

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

• 7.6.1 Суброль «нерегулируемые организации»

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

• 7.6.2 Суброль «кооперативная система управления учетными данными»

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

• 7.6.3 Орган конфиденциальности

Зона ответственности этой суброли — определение политики конфиденциальности.

• 7.6.4 Орган информационной безопасности

Зона ответственности этой суброли — определение политики информационной безопасности.

• 7.6.5 Суброль «власты»

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

• 7.6.5.1 Суброль «законодательные органы»

Законодательство определяется как учреждение, которое отвечает за принятие законов в государстве.

• 7.6.5.2 Суброль «юрисдикция»

Юрисдикция определяется как право или полномочия по урегулированию норм путем рассмотрения и разрешения спорив.

• 7.6.5.3 Суброль «исполнительная власть»

Исполнительная власть определена как исполнительная власть государства.

• 7.7 Профили

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

Различные профили демонстрируют ключевые характеристики организационной архитектуры:

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

• - один пользователь может выполнять несколько ролей.

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

Методология и пример ее применения

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

АЛЛ Введение

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

А.1.2 Заинтересованные стороны

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

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

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

• • группы субъектов (например, пользователь);

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

• • отраслевые ассоциации.

A.U.1 Действующие лица

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

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

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

• • за операцию;

• • функциональные возможности управления системой, такие как обслуживание и установка/разборка;

• • функциональные возможности структуры политики, такие хак согласование структур.

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

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

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

а) аппаратные средства:

• 1) операция:

• • дорожный оператор.

• • радиостанция.

• • оператор связи.

• • водитель.

• • путешественник.

• • производитель автомобилей.

• • поставщик транспортных средств.

• • производитель мобильных устройств;

• 2) система управления:

• • обслуживающий персонал.

• • обслуживающий персонал связи.

• • дилерская сеть OEM,

• • инфраструктура производителя.

• • производитель автомобилей.

• • поставщик услуг.

• - менеджер дорожного движения.

• - менеджер по грузоперевозкам и флоту.

• - полиция;

• 3) политическая основа:

• - организации по стандартизации.

• • сертификационная организация.

• • национальные судебные органы.

• - консорциум заинтересованных сторонГучастников:

6) программное обеспечение:

• 1) операция:

• - поставщик программного обеспечения.

• • водитель.

• • дорожный оператор:

• 2) система управления:

• • поставщик программного обеспечения.

• • производитель автомобилей.

• - инфраструктура производителя.

• - менеджер проблем:

• 3) основа политики:

• - инфраструктура открытых ключей'доверенная третья сторона.

• - организации по стандартизации.

• - консорциум заинтересованных сторон/субьектов.

А.1.3 Основные сервисно независимые описания процессов

А. 1.3.1 Прикладной подход

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

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

А. 1.3.2 Последовательное описание процесса

Режимы нажатия и отпускания

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

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

• - сбор данных (например, периодически запускаемых в течение определенного интервала времени) и их временное хранение в базе данных для использования в будущем:

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

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

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

--------------------Ь|

«ИНМ0МНП (гмрмдошж» нмалв}

рмцмт

Рисунок А. 1

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

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

А.1.3.3 Модули

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

Таблица А.1 — Базовые модули

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

А.1.3.4 Описание жизненного цикла

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

Рисунок А.З — Подробное описание жизненного цикла

Это абстрактное описание базового жизненного цикла адаптировано из цепочки добавленной стоимости ИБАдля информации о дорожном движении {см. [16]).

А.1.3.5 Преобразование последовательности е описании процесса жизненного цикла

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

речмнт

Рисунок А.4 — Трансформация — эго последовательное описание процесса

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

Риоужж А.В —’1)рамсфод1мцмя — олминив процкюажтненнопв цикпв

Действия на рисунках А.4 и А.5 соответствуют:

• - сбор информации — обнаружению;

• - доставка информации —доставке и приему данных.

• • хранение и извлечение информации — агрегации данных, объединению датшых. проверке качества, а также доставке и приему контента:

• • модуль «запуск сервиса» — слиянию контента, генерации информационного сервиса, предварительному форматированию;

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

• - полученные результаты — предоставлению информационного сервиса, презентации сервиса.

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

АЛ .3.6 Шаги от описания процесса жизненного цикла до создания базовой организационной модели

На рисунке А.6 показан процесс упрощения описания процесса жизненного цикла (см. рисунок А.З) (подробное описание базового процесса жизненного цикла). В общем описании жизненного цикла:

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

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

• • обнаружение.

• • обработка контента.

• • генерация информационных услуг.

• • презентация услуги.

Рисунок А.6 — Общее описание жизненного цикла

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

А.1.4 Базовая организационная модель

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

Рисунок А.7 — Определение ролей. Структурирование цепочки процессов обслуживания ИТС

Структурирование действий, представленных в описании процесса жизненного цикла, приводит к трем основным ролям и обязанностям (см. рисунок А.7):

• • предоставление контента:

• • предоставление сервиса:

• • презентация сервиса.

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

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

А.2 Пример применения методологии «предупреждение об опасной зоне»

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

Данная методология проверяется в качестве образца службы ИТС «предупреждение об опасной зоне».

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

А.2.2 Определение заинтересованных сторон и участников

А.2.2.1 Заинтересованные стороны

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

А.2.2.2 Действующие лица

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

• • транспортное средство или мобильные устройства (включая датчики, процессор. дисплей/НМ1);

• • инфраструктура как общедоступная, так и частная (включая датчик, точку доступа к беспроводной сети (станция ИТС). центр управления движением, дисплей/знак с изменяемым сообщением];

• • при нагычии инфраструктур сетевой провайдер/оператор.

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

А.2.3 Базовые, независимые от службы описания процессов

А.2.3.1 Последовательное описание процесса а режимах нажатия и отпускания

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

Отдельными шагами процесса представлены действия, приведенные на рисунке А.8.

Якупьгат

— триггерное событие — это опасное место, например опасная дорожная ситуация, погодная ситуация или опасный объект;

• — дапмк обнаруживает событие (например, датчик транспортного средства, датчик дороги. датчик погоды);

• — предоставление собранных данных посредством общедоступных или частных интерфейсов:

• — хранилище данных — это может быть, например. LDM. реагмэованный на станции ИТС. Хранилище данных может объединять данные из разных источников, объединять данные, предварительно обрабатывать данные, проводить проверку их качества;

• — триггер основного процесса — это зависящий от времени сигнал, периодически запускающий службу;

— объект, запускающий основной процесс, выдает запрос на обслуживание;

• — запрос на обслуживание доставляется субъекту, выполняющему службу предупреждения об опасно*! месте, выбирается реализация службы, отвечающая требованиям обслуживания;

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

—выполнил» anrapimi вередов лродтфведмп об опасном ымлж Полученный кон

тент обрабатывается информационным сервисом и вычисляется результат.

• — доставка результата обслуживания из предыдущего модуля действующему субъекту;

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

Рисунок А.8 — Шаговый процесс

Этапы в процессе описания жизненного цикла представлены в таблице А.2.

Таблица А.2 — Описание жизненного цикла

Окончание таблицы А.2

А.2.4 Преобразование последовательности в описание процесса жизненного цикла

Служба предупреждения об опасном месте может быть смоделирована с помощью описания последовательных процессов и процесса жизненного цикла (см. 5.U.1 и Б.1.2.2 приложения Б). Следовательно, возможно преобразование, подобное приведенному в Б.1.2.Э приложения Б.

А.2.5 От описания процесса жизненного цикла к созданию базовой организационной модели

Служба предупреждения об опасном месте может быть смоделирована с помощью описания абстрактного процесса жизненного цикла (см. Б.1.2.2 приложения Б). Следовательно, возможно преобразование. подобное приведенному в приложении Б.1.2.4 приложения Б.

А.2.6 Базовая организационная модель

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

• • поставщик контента, ответственный за обеспечение сбора и предварительной обработки данных:

• • поставщик услуг, ответственный за предоставление услуг;

• • провайдер презентаций, ответственный за предоставление результатов услуг.

Работа системы поддерживается действиями по управлению системой и по основам политики с соответствующими ролями.

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

Профили

Б.1 Профили

Б.1.1 Общее описание

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

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

Б.1.1.1 Действующие лица

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

Б.1.1.2 Сценарии

Для того чтобы пользователи не зависели от предлагаемых вариантов реализации, необходимо представить полный набор сценариев для операционной части системы. Согласно положениям раздела 8. подразделам А.1 и А.2 приложения А каждый сценарий состоит из основных этапов обработки, предназначенных для ролей «поставщик контента», «поставщик услуг» и «поставщик презентаций». Каждая из групп участников, представленных в А. 1.2 приложения А (система транспортного средства, система инфраструктуры), или их комбинация (система транспортного средства и система инфраструктуры) обрабатывает один из упомянутых этапов обработки. Отдельные этапы обработки являются независимыми, поэтому участники могут быть произвольно объединены. Это приводит к созданию нижеприведенных возможных комбинаций разных действующих лиц.

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

Примечание — В цепях упрощения термин «система транспортного средства» сокращен до термина «транспортное средство», а термин «система инфраструктуры» —до термина «инфраструктуры».

Рисунок Б.1 — Комбинации участников для описания сценариев

Рисунок Б.2 — Комбинации действующих лиц для основных сценариев

Одни сценарии, предназначенные для участников системы транспортного средства и/или для инфраструктуры одного этапа обработки, но не для участников системы транспортного средства и инфраструктуры (транспортное средство и жфраструктура). именуют базовым сценарием. Возможные комбинации показаны на рисунках Б.1 и Б.2. Другие сценарии являются сложными сценариями, так как состоят из двух или более соответствующих базовых компонентов сценария.

В пункте Б.1.2 реализация услуги ИТС смоделирована для всех основных сценариев. Комплексные сценарии не создают из-за большого количества вероятных вариантов, но процесс для идентификации сценариев потенциально представлен в Б. 1.1.3 или Б. 1.1.4.

Б.1.1.3 Комплексные сценарии

Первый вариант, который может быть представлен комбинацией базовых сценариев, влияет на переход «поставщик контента» — «поставщик услуг». Данные, собранные системой транспортного средства и инфраструктуры. могут быть доставлены для обработки в транспортное средство или систему инфраструктуры (см. рисунок Б.З).

Рисунок Б.З — Доставка данных из нескольких источников одному получателю

Также вполне вероятно, что транспортное средство или система инфраструктуры доставляет данные как на транспортное средство, так и на систему инфраструктуры (см. рисунок Б.4).

Рисунок Б.4 —Доставка данных из одного источника нескольким получателям

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

«Поставщик услуг» может иметь место либо в системе транспортного средства, либо в инфраструктуре, но затем доставляется как в транспортное средство, так и в систему инфраструктуры для предоставления результатов (см. рисунок Б.5).

Пр*ИНТВЦМЙ

Рисунок Б.5 — Доставка одного результата услуги нескольким получателям

Кроме того, результаты, отображаемые в системе транспортного средства или инфраструктуры, могут быть получены как от транспортного средства, так и от системы инфраструктуры (см. рисунок Б.6).

Рисунок Б.6 — Доставка нескогъких результатов обслуживания одному получателю

Одиночные сценарии могут быть объединены с большим количеством различных сценариев.

Б.1.1.4 Пример сложного сценария

Как указано в Б.1.1.2. существует большое количество возможных сложных сценариев. Следующий пример иллюстрирует принципы декомпозиции на базовые сценарии (см. рисунок Б.7).

РноунсжБ.7—Окхзсмыйсцвшрмй,осыпан i fl неосновныхсценариях

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

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

Таблица Б.1 — Альтернативная комбинация основных сценариев для сложного сценария, представленного на рисунке Б.7

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

Б.1.1.5 Вспомогательные действия — управление системой и структура политики

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

Б.1.2 Предупреждение об опасной зоне. Примеры сценариев

Б.1.2.1 Определение предупреждения местонахождения опасности

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

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

Б.1.2.2 Сценарий 1

Сценарий 1 характеризуется выбором групп участников, представленным на рисунке Б.8.

Рисунок Б.8 — Группы участников, представленные в сценарии 1

Образное описание

Сбор, обработка и представление данных приведены в системе транспортного средства (см. рисунок Б.9).

Рисунок Б.9 — Иллюстрация сценария 1 при направлении предупреждения об опасном месте службы

Назначение ролей группам участников

В сценарш 1 система транспортного средства является единственным действующим лицом, поэтому все роли назначаются действующим лицам в системе транспортного средства (см. рисунок Б. 10).

Рисунок Б.10 — Назначение ролей и обязанностей группам участников в сценарии 1

Б.1.2.3 Сценарий 2

Сценарий 2 характеризуется определенным выбором групп участников (см. рисунок Б.11 >.

Пмшнтацм

Рисунок Б.11 — Группы участников, вовлеченные в сценарий 2

Образное описание

Сбор и обработка данных осуществляет система автомобиля. Результат услуги доставляется в инфраструктурную систему (см. рисунок Б.12).

Присвоение ролей группам участников

В сценарии 2 субъект группирует транспортное средство и систему инфраструктуры, разделяя роли и обязанности (см. рисунок Б.13).

Поставщик контента:

действующее лицо из системы автомобиля

Поставщик услуг:

действующее лицо из системы автомобиля

действующее лицо из системы инфраструктуры

Рисунок Б.13 — Назначение ролей и обязанностей групп участников в сценарии 2

Б.1.2.4 Сценарий 3

Сценарий 3 характеризуется определенным выбором трупп участников (см. рисунок Б.14).

Рисунок Б.14 — Участники группы, вовлеченной в сценарий 3

Образное описание

Данные собираются в системе автомобиля, в которой отображен результат. Служба выполняется е системе инфраструктуры (см. рисунок Б.15).

Рисунок Б.15 — Образное описание сценария 3

Назначение ролей группам участников

В сценарии 3 субъект группирует транспортное средство и систему инфраструктуры, назначая роли и обязанности (см. рисунок Б.16).

Б.1.2.5 Сценарий 4

Сценарий 4 характеризуется определенным выбором групп участников (см. рисунок Б.17).

Сервис

ГЪммнтацмя

Рисунок Б.17 — Участник группы, вовлеченный в сценарий 4

Образное описание

Данные собираются системой автомобиля, затем обрабатываются и представляются в системе инфраструктуры (см. рисунок Б.18).

Рисунок Б.18 — Образное описание сценария 4

Назначение ролей группам действующих лиц

В сценарии 4 субъект группирует транспортное средство и систему инфраструктуры, разделяя роли и обязанности (см. рисунок Б.19).

БД.2.6 Сценарий 5

Сценарий 5 характеризуется следующим выбором групп действующих лиц (см. рисунок Б.20).

Рисунок Б.20 — Группы действующих лиц. вовлеченные в сценарий 5

Образное описание

Данные собираются системой инфраструктуры. Система транспортного средства оценивает данные и предоставляет результат пользователю (см. рисунок Б.21).

Рисунок Б.21 — Образное описание сценария 5

Присвоение ролей группам субъектов

В сценарии 5 субъект группирует транспортное средство и систему инфраструктуры, назначая роли и обязанности (см. рисунок Б.22).

Б.1.2.7 Сценарий 6

Сценарий 6 характеризуется определенным выбором групп субъектов (см. рисунок Б.23).

Рисунок Б.23 — Группы, вовлеченные в сценарий 6

Присвоение ролей группам субъектов

В сценарии 6 субъект группирует транспортное средство и систему инфраструктуры. назначая роли и обязанности (см. рисунок Б.24).

Рисунок Б.25 — Группы субъектов, вовлеченные в сценарий 7

Образное описание

Сбор, оценку данных осуществляет система инфраструктуры, которые затем представлены в системе транспортного средства (см. рисунок Б.26).

Рисунок Б.26 — Образное списание сценария 7

Присвоение ролей группам субъектов

В сценарии 7 субъект группирует транспортное средство и систему инфраструктуры, назначая роли и обязанности (см. рисунок Б.27).

Б.1.2.9 Сценарий 8

Сценарий 8 характеризуется определенным выбором групп субъектов (см. рисунок Б.28).

Контакт

Сврвмо

Првмитация

Рисунок Б.28 — Группы, вовлеченные в сценарий 8

Образное описание

Система инфраструктуры собирает, обрабатывает данные и отображает результат е системе инфраструктуры. (см. рисунок Б.29).

Рисунок Б.29 — Образное описание сценария 8 — «предупреждение об опасной эоне»

Присвоение ролей группам субъектов

В сценарии 8 система инфраструктуры является единственным действующим лицом, поэтому все роли назначаются действующим лицам в системе инфраструктуры (рисунок Б.ЗО}.

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

Рисунок Б.ЗО — Назначение ролей группам субъектов в сценарии 8

УДК 656.13:006.354 ОКС 35.240.60

Ключевые слова: интеллектуальные транспортные системы, электронный сбор платы за проезд, архитектура систем сбора платы за проезд, бортовое оборудование

БЗ 11—2020/160

Редактор Л. С. Зиминова Технические редакторы В.Н. Прусакова. И.Е. Черепкова Корректор Е.Р. Ароян Компьютерная верстка Ю.В. Поповой

Сдано в набор T9.10.2020. Подписано в печать 16.11.2020. Формат 60 * 84 Vg. Гарнитура Ариал.

Усл. печ. п. 4.65. Уч.-изд. п. 4.30.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

ИД «Юриспруденция*. 115419. Москва, ул. Орджоникидзе. 11. wwwpjneizdat.ru у-Ьоок^тай ги

Создано в единичном исполнении во ФГУП «СТАНДАРТИНФОРМ* .

117418 Москва. Нахимовский пр-т, д. 31. ж. 2. www.goslinfo.ru [email protected]