ПНСТ 878-2023 (ИСО 14813-5:2020). Предварительный национальный стандарт Российской Федерации. Интеллектуальные транспортные системы. Архитектура эталонной модели для интеллектуальных транспортных систем. Часть 5. Требования к описанию архитектуры в стандартах на интеллектуальные транспортные системы
(утв. и введен в действие Приказом Росстандарта от 29.11.2023 № 74-пнст)
Примечание
Документ введен в действие с 01.06.2024 с правом досрочного применения на период до 01.06.2027 (Приказ Росстандарта от 29.11.2023 № 74-пнст). Срок действия данного документа ограничен 01.06.2027 (Приказ Росстандарта от 29.11.2023 № 74-пнст).
Утвержден и введен в действие
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 29 ноября 2023 г. № 74-пнст
ПРЕДВАРИТЕЛЬНЫЙ НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНТЕЛЛЕКТУАЛЬНЫЕ ТРАНСПОРТНЫЕ СИСТЕМЫ
АРХИТЕКТУРА ЭТАЛОННОЙ МОДЕЛИ
ДЛЯ ИНТЕЛЛЕКТУАЛЬНЫХ ТРАНСПОРТНЫХ СИСТЕМ
ТРЕБОВАНИЯ
К ОПИСАНИЮ АРХИТЕКТУРЫ В СТАНДАРТАХ
НА ИНТЕЛЛЕКТУАЛЬНЫЕ ТРАНСПОРТНЫЕ СИСТЕМЫ
Intelligent transport systems. Reference model architecture
for the intellectual transport systems. Part 5. Requirements
for architecture description in intellectual transport
systems standards
(ISO 14813-5:2020 Intelligent transport systems — Reference
model architecture(s) for the ITS sector — Part 5:
Requirements for architecture description in ITS
standards, MOD)
(ИСО 14813-5:2020)
до 1 июня 2027 года
Предисловие
1 ПОДГОТОВЛЕН Инфраструктурным центром Московского политехнического университета с привлечением творческого коллектива специалистов кафедры «Транспортная телематика» МАДИ на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 57 «Интеллектуальные транспортные системы»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 ноября 2023 г. № 74-пнст
4 Настоящий стандарт является модифицированным по отношению к международному стандарту ИСО 14813-5:2020 «Интеллектуальные транспортные системы. Архитектура эталонной модели для интеллектуальных транспортных систем. Часть 5. Требования к описанию архитектуры в стандартах на интеллектуальные транспортные системы» (ISO 14813-5:2020 «Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 5: Requirements for architecture description in ITS standards», MOD) путем изменения отдельных фраз (слов, значений показателей, ссылок), которые выделены в тексте курсивом. Внесение указанных технических отклонений направлено на учет особенностей российской национальной стандартизации.
Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2012 (пункт 3.5).
Сведения о соответствии ссылочных национальных стандартов международным стандартам, использованным в качестве ссылочных в примененном международном стандарте, приведены в дополнительном приложении ДА
Правила применения настоящего стандарта и проведения его мониторинга установлены в ГОСТ Р 1.16-2011 (разделы 5 и 6).
Федеральное агентство по техническому регулированию и метрологии собирает сведения о практическом применении настоящего стандарта. Данные сведения, а также замечания и предложения по содержанию стандарта можно направить не позднее чем за 4 мес до истечения срока его действия разработчику настоящего стандарта по адресу: 127083 Москва, ул. Мишина, д. 35, и/или в Федеральное агентство по техническому регулированию и метрологии по адресу: 123112 Москва, Пресненская набережная, д. 10, стр. 2.
В случае отмены настоящего стандарта соответствующая информация будет опубликована в ежемесячном информационном указателе «Национальные стандарты» и также будет размещена на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
Введение
Архитектура является неотъемлемым элементом сложного объекта любой природы — физического объекта (например, здание), действующего объекта (например, компания или организация), системного объекта (например, программная система) или бизнес-объекта (например, коммерческая бизнес-операция). Архитектура объекта может быть явно определена его конструкцией в результате процесса проектирования или может формироваться в результате незапланированной серии событий, в том числе и комбинацией обоих подходов.
Архитектура системы определяется как «фундаментальное понятие или свойства системы, воплощенные в ее элементах, отношениях и принципах ее проектирования и развития (см. ГОСТ Р 57100-2016, пункт 3.2).»
Интеллектуальные транспортные системы (ИТС) — это системы, внедряемые в транспортной среде для улучшения как качества вождения, так и безопасности водителей, пассажиров и пешеходов. ИТС также повышают эффективность транспортных процессов, позволяют снизить затраты энергии, затраты на транспорт и уменьшить загрязнение окружающей среды.
Особенностью большинства ИТС является то, что их архитектура направлена на сбор, использование и обмен информацией/данными внутри программных систем и между ними с целью влияния на поведение или управление физическим оборудованием в процессе предоставления услуг субъектам, участвующим в транспортных процессах или взаимодействующим с транспортным сектором.
Сервисы ИТС быстро развиваются и изменяются. Поэтому необходимо предусматривать не только их взаимодействие с другими сервисами, но и возможность перехода от одного поколения технологий к более поздним в процессе развития сервисных услуг.
Для поддержания и обеспечения совместимости и/или возможности взаимодействия, а также устранения конфликтов, системы должны сосуществовать и работать в пределах известной и поддерживающей архитектуры.
Настоящий стандарт разработан с целью поддержания и обеспечения совместимости и/или возможности взаимодействия, а также устранения конфликтов. Системы для достижения этих целей и обеспечения максимальной функциональной совместимости, эффективности и возможности миграции должны сосуществовать и работать в пределах известной и поддерживающей архитектуры, разработанной на основе определения процесса описания эталонных архитектур ИТС для использования в стандартах на ИТС.
Слово «архитектура» неофициально используется для обозначения множества различных концепций, с другой стороны, в формальном проектировании архитектур существуют разные методологии и мнения относительно их пригодности для использования в самой ИТС и разработке стандартов. Такое положение ограничивает эффективную коммуникацию в секторе интеллектуальных транспортных систем, вызывая неопределенность в отношении значения слова «архитектура», когда оно используется.
Цель настоящего стандарта заключается в предоставлении согласованной терминологии, которая будет использоваться при описании архитектурных аспектов стандартов на ИТС, а также в предоставлении согласованной формы для описания эталонной архитектуры ИТС в стандартах из области ИТС.
Настоящий стандарт не отдает предпочтение какой-либо одной методологии разработки и описания архитектуры. Стандарт предполагает, что рассмотрение архитектуры ИТС является важным процессом, который учитывает взаимосвязь и функциональную совместимость ИТС, а также то, что описание архитектуры предоставляется в рамках стандартов на ИТС. Также предполагается, что архитектурные аспекты стандартов на ИТС подробно описываются в каждом стандарте на ИТС, и что все стандарты связаны с одним или несколькими ИТС сервисами, для включения или поддержки которых они предназначены.
1 Область применения
Архитектура эталонной модели интеллектуальной транспортной системы (ИТС) представляет собой инструмент, описывающий, как ИТС предоставляет один или несколько сервисов. Она включает высокоуровневое описание основных элементов и взаимосвязи между ними, которые необходимы для предоставления услуги (услуг) заинтересованным сторонам. На основе эталонной архитектуры могут быть разработаны стандартизованные интерфейсы, спецификации и подробные проекты ИТС. Несмотря на то что разработка этих стандартов может быть инициирована потребностью одного пользователя ИТС, они часто (и должным образом) записываются в общем формате, позволяющем применять их в широком диапазоне контекстов.
Стандарт устанавливает правила документирования для стандартов, определяющих интерфейсы между системными элементами эталонной архитектуры ИТС.
Правила документирования для стандартов, определяющих интерфейсы между системными элементами эталонной архитектуры ИТС включают в себя:
a) требования к документированию аспектов эталонной архитектуры ИТС;
b) терминологию, используемую при документировании или ссылке на аспекты эталонной архитектуры ИТС.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие стандарты:
ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 Системная и программная инженерия. Описание архитектуры
ГОСТ Р ИСО 14813-1 Интеллектуальные транспортные системы. Схемы построения архитектуры интеллектуальных транспортных систем. Часть 1. Сервисные домены в области интеллектуальных транспортных систем, сервисные группы и сервисы
ГОСТ Р ИСО/МЭК 8824-1 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации
ГОСТ Р ИСО/МЭК 9834-1 Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных по регистрации ВОС. Часть 1. Общие процедуры и верхние дуги дерева идентификатора объекта АСН.1
ГОСТ Р ИСО/МЭК 11179-3 Информационная технология. Регистры метаданных (РМД). Часть 3. Метамодель регистра и основные атрибуты
ГОСТ Р МЭК 62264-1 Интеграция систем управления предприятием. Часть 1. Модели и терминология
Примечание - При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку.
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 архитектура: Фундаментальные понятия или свойства системы в ее окружении, воплощенные в ее элементах, отношениях, а также в принципах ее построения и эволюции.
3.2 описание архитектуры: Часть проекта, используемая для выражения особенностей архитектуры.
3.3 модель архитектуры: Часть проекта, содержащая одно или несколько архитектурных представлений и выраженная в формате, регулируемом видом модели.
3.4 представление архитектуры: Часть проекта, содержащая описание архитектуры системы с точки зрения конкретных задач системы.
3.5 точка зрения на архитектуру: Часть проекта, устанавливающая соглашения для построения, интерпретации и использования представлений архитектуры для определения конкретных системных беспокойств.
3.6 коммуникационное представление: Точка зрения на архитектуру, представленная с коммуникационной точки зрения.
3.7 коммуникационная точка зрения: Точка зрения на архитектуру, используемая для определения проблем интерфейса связи, включая все уровни стека OSI и связанные с ними вопросы управления и безопасности.
3.8 беспокойство: Заинтересованность в системе, относящаяся к одному или нескольким заинтересованным сторонам.
Примечание - Беспокойство относится к любому влиянию на систему в ее окружении, включая развитие, технологические, деловые, операционные, организационные, политические, экономические, правовые, регулирующие, экологические и социальные воздействия.
3.9 архитектура развертывания; архитектура проекта; низкоуровневая архитектура; архитектура на уровне дизайна: Архитектура, обеспечивающая видение конкретного развертывания системы в пределах географической области.
Примечание - Эксперты используют различные термины для описания данного понятия; ИСО/ТК 204 предпочитает термин «архитектура развертывания».
3.10 элемент: Компонент — член архитектуры.
3.11 функциональное представление: Представление архитектуры с функциональной точки зрения.
3.12 функциональная точка зрения: Точка зрения на архитектуру, используемая для определения функциональных задач, включая определение процессов, выполняющих транспортные функции, и потоков данных, совместно используемых этими процессами.
3.13 обмен информацией: Информационный поток от физического объекта, выступающего в качестве источника информации, посылаемый другому физическому объекту, действующему как приемник информации.
3.14 информационный поток: Информация, которой обмениваются физические объекты.
3.15 интеллектуальная транспортная система; ИТС: Технологическая система, предназначенная для использования в системе наземного транспорта.
3.16 интерфейс: Граница между двумя элементами системы или между двумя системами.
3.17 эталонная архитектура ИТС: Эталонная архитектура для одного или нескольких сервисов ИТС.
3.18 вид модели: Соглашение для типа моделирования.
Примечание - Примеры типов моделей включают в себя диаграммы потоков данных, диаграммы классов, сети Петри, балансовые отчеты, организационные диаграммы и модели перехода состояний.
3.19 физический объект: Элемент в физическом представлении эталонной архитектуры ИТС, представляющий физический объект, взаимодействующий с другими физическими объектами при предоставлении ИТС сервисов.
3.20 физическое представление: Представление архитектуры с физической точки зрения.
3.21 физическая точка зрения: Точка зрения на архитектуру, используемая для формулирования вопросов системного проектирования.
Примечание - Вопросы системной инженерии включают в себя определения физических объектов, назначение, функциональность для физических объектов, интерфейсы между этими физическими объектами, а также вопросы безопасности и конфиденциальности, связанные с этими сущностями и их интерфейсами.
3.22 архитектура планирования; региональная архитектура; архитектура высокого уровня: Архитектура, обеспечивающая долгосрочное видение системных элементов, которые могут быть развернуты и управляться различными проектами и/или организациями в пределах географической области.
Примечание - Термин «региональная архитектура» широко используют в США, но «региональный» становится довольно двусмысленным применительно к международным стандартам. Также иногда используют термин «архитектура высокого уровня», но предпочтительным термином для технического комитета ИСО/ТК 204 является «архитектура планирования».
3.23 эталонная архитектура: Шаблонное решение для архитектуры системы в конкретной области.
3.24 сервис: Выполнение одной или нескольких задач, которые удовлетворяют потребность пользователя ИТС.
3.25 заинтересованная сторона: Человек, команда, организация или их группы, заинтересованные в системе.
3.26 потребность пользователя: Потребность сущности, внешней по отношению к интеллектуальной транспортной системе, в полезных свойствах системы наземного транспорта, которая может быть удовлетворена с использованием некоторой технологической системы.
3.27 ИТС станция: Носимое устройство, обеспечивающее связь с использованием такого оборудования, как сотовые телефоны, мобильная беспроводная широкополосная связь (WiMAX, HC-SDMA и т.д.) или Wi-Fi.
4 Сокращения
В настоящем стандарте применены следующие сокращения:
ARC-IT — эталонная архитектура для совместной и интеллектуальной транспортировки;
CIDCR — центральный реестр концепций данных ИТС;
CVRIA — эталонная архитектура реализации подключенного транспортного средства;
CIA — конфиденциальность, целостность и доступность;
FRAME — инфраструктурная архитектура европейской ИТС;
FIPS 199 — стандарты категоризации безопасности федеральной информации и информационных систем;
HARTS — справочник по гармонизированной архитектуре для технических стандартов.
5 Соответствие
В данном стандарте отсутствуют специальные тесты на соответствие, указанные или связанные с ним.
6 Предпосылки и общие положения
6.1 Общие положения
Разработка архитектуры ИТС рассматривалась как часть процесса внедрения ИТС более 20 лет. Архитектура ИТС дает заинтересованным сторонам четкое представление о том, как должны предоставляться услуги ИТС, чтобы обоснованные решения принимались как можно раньше в процессе внедрения ИТС. Содержание, формат, точки зрения и другие детали архитектуры со временем менялись, чтобы лучше соответствовать потребности промышленности. В настоящем разделе представлен обзор текущих лучших практик.
6.2 Уровень абстракции
В отрасли ИТС архитектуры часто представлены на трех различных уровнях абстракции, как показано на рисунке 1.
Эталонные архитектуры отражают требования, установленные отраслевым сообществом заинтересованных сторон. Эти архитектуры обеспечивают относительно общий шаблон, характеризующий то, как элементы ИТС обычно взаимодействуют друг с другом для предоставления услуг, которые широко используются. На данном уровне абстракции системные элементы концептуальны — они описывают типы элементов, которые могут быть развернуты. Поскольку эталонная архитектура представляет типичные развертывания, она полезна для определения интерфейсов между элементами системы, которые можно стандартизировать.
Архитектуры планирования предназначены для решения проблем заинтересованных сторон при разработке долгосрочного видения (например, от 5 до 20 лет) развертывания ИТС в географической области на уровне, который облегчает реализацию планирования проекта.
На данном уровне абстракции архитектура идентифицирует конкретные элементы системы, которые необходимо развернуть, и определяет, какие элементы и сервисы ИТС существуют, если таковые имеются, а какие просто необходимо запланировать.
Архитектуру планирования рекомендуется использовать в качестве основного источника планов развертывания (например, временных рамок) для каждого запланированного элемента системы.
Архитектура планирования, как правило, должна быть получена из эталонной архитектуры, чтобы извлечь выгоду из предыдущей работы и стандартизации, но в процессе создания, как правило, не учитываются некоторые сервисы ИТС, которые не предусмотрены для региона. Возможно также добавление новых услуг ИТС, специфичных для региона.
Архитектуры развертывания предназначены для решения проблем местных заинтересованных сторон, связанных с конкретным проектом развертывания ИТС. На данном уровне абстракции архитектура должна идентифицировать системные элементы, которые будут закупаться отдельно, и определять, как эти системные элементы будут взаимодействовать друг с другом (рекомендуется с использованием некоторого набора стандартов, созданных в ответ на связанную эталонную архитектуру). Архитектуры развертывания, как правило, должны быть получены из архитектуры планирования, чтобы обеспечить согласованность с долгосрочным видением, но, как правило, они отражают только подмножество планируемой архитектуры, которое должно быть развернуто как часть проекта.
Архитектуры развертывания используют в качестве основы для разработки спецификаций закупок для каждого из отдельно приобретаемых системных элементов.
6.3 Различные точки зрения на архитектуру
Описание современной архитектуры выполняется в соответствии с принципами, изложенными в ГОСТ Р 57100, которые рекомендуют определять архитектуру с помощью нескольких представлений архитектуры. Каждое представление описывается в соответствии с некоторой точкой зрения на архитектуру, определяющей набор правил, отвечающих целям определенной группы заинтересованных сторон, использующих одну или несколько архитектурных моделей. Полная архитектура определяется как сумма всех представлений, соответствующих различным точкам зрения.
Поскольку эталонные архитектуры ИТС постепенно развивались с начала 90-х годов, существует множество методов моделирования, используемых в соответствующих архитектурах. Рекомендуемый набор соглашений о моделировании для трех точек зрения, определенных в данном стандарте, приведен в приложении B.
Примечание — Поскольку в настоящем стандарте описаны архитектуры в рамках стандартов на ИТС, стандарты на ИТС должны быть основаны на эталонных архитектурах ИТС. Стандарт касается только точек зрения и соглашений о моделировании, относящихся к эталонным архитектурам ИТС. Архитектуры планирования и развертывания могут включать дополнительные точки зрения, не приведенные в настоящем стандарте.
7 Требования к описанию архитектуры
7.1 Описание архитектуры
Все стандарты, относящиеся к ИТС, должны включать раздел, содержащий описание части(ей) эталонной архитектуры ИТС, в которой должно использоваться содержание стандарта.
Полное описание архитектуры может быть включено в стандарт или допускается приводить ссылку на внешний общедоступный источник, такой как веб-сайт. Описание архитектуры может содержаться в основной части стандарта или в справочном приложении. В большинстве случаев описание архитектуры должно быть представлено как справочная информация и не препятствовать использованию стандарта для других целей.
Описание архитектуры должно включать информацию, детализирующую видение и задачи, которые должны быть достигнуты путем применения стандарта, с учетом описания архитектурных аспектов стандарта. Данная информация должна включать в себя все компоненты, указанные в 7.2. Такую информацию допускается приводить либо в разделе «Область применения», либо в разделе «Требования» и в любом формате, который разработчики стандарта сочтут подходящим.
Примеры изложения части эталонной архитектуры ИТС, в которой должно использоваться содержание стандарта на примере описания архитектуры стандартов, таких как словарь данных, спецификация интерфейса приложения и спецификация базового интерфейса, приведены в приложении A.
7.2 Элементы описания архитектуры
7.2.1 Область применения архитектуры
В описании архитектуры должна быть указана область применения сервисов ИТС, рассматриваемых эталонной архитектурой; полную эталонную архитектуру допускается включать в стандарт или приводить ссылку на внешний источник.
Пример - В стандарте допускается приводить ссылку на справочник по гармонизированной архитектуре для технических стандартов (HARTS) путем указания интернет-сайта http://htg7.org.
7.2.2 Сервисы
Разделы, описывающие сервисы, к которым относится стандарт на ИТС, должны содержать общее описание того, что обеспечит реализация ИТС, включая рабочие концепции и требования пользователя, а также известные взаимосвязи с другими системами, некоторые из которых могут находиться за пределами области ИТС.
Примечание — Соответствующие домены сервисов ИТС, группы сервисов и сервисы из ГОСТ Р ИСО 14813-1 могут использоваться в качестве отправной точки для определения этих сервисов при отсутствии каких-либо других определенных услуг.
7.2.3 Функциональное представление интерфейса
Описание архитектуры должно включать описание функционального представления интерфейса для тех, кому предназначен стандарт. Стандарты, которые определяют только нижние уровни коммуникационного стека, как правило, определяют функциональные возможности, не определенные непосредственно в эталонной архитектуре. Стандарт может описывать эти функциональные возможности и то, как они относятся к дизайну более высокого уровня. Стандарты, определяющие сервисы ИТС, должны определять конкретные функциональные возможности эталонной архитектуры, на которые, в соответствии с утверждением, ориентирован стандарт.
Раздел должен описывать характер системы, основанной на требуемых входных данных, функциях управления и обработки, а также данных, которые должны быть выведены. Также должны быть описаны взаимосвязи между этими аспектами. Оба описания должны быть независимы от какой-либо ссылки на конкретные аппаратные или программные технологии.
При необходимости описание данных следует относить к концепциям данных, уже включенным в Центральный репозиторий концепций данных ИТС (CIDCR), который предоставляется для использования ИСО ТК 204. Если ссылка невозможна, то должна быть создана новая концепция данных и представлена для включения в CIDCR.
7.2.4 Физическое представление интерфейса
Следуя объяснению функциональных возможностей, данное описание должно распределять их в общих чертах по физическим объектам, которые легко прослеживаются до физических объектов в указанной эталонной архитектуре ИТС (например, HARTS). Эти ссылки должны быть как можно более подробными с учетом контекста стандарта. Если стандарт предназначен только для использования в контексте конкретной услуги или класса системы, то должна быть приведена ссылка на эту систему. Если стандарт не является таким узконаправленным, то он должен ссылаться на классы физических объектов, к которым применяют требования стандарта, например «От центра к периферии».
Несмотря на то что конфигурации физических объектов должны быть описаны в терминах системы, они не должны быть привязаны к какому-либо конкретному местоположению.
Описание архитектуры должно описывать физический вид интерфейса(ов), для которого предназначен стандарт. В зависимости от точного характера стандарта интерфейс может относиться к конкретному обмену информацией, изображенному в архитектуре, или может относиться к более абстрактному интерфейсу, реализуемому несколькими информационными тройками. При необходимости описание интерфейса может сопровождаться цифрой. При включении рисунков рекомендуется в них использовать соглашения о моделях архитектуры, определенные в приложении B.
7.2.5 Коммуникационное представление интерфейса
7.2.5.1 Краткий обзор
Краткий обзор должен обеспечить высокоуровневое описание требований к связи, необходимых для любого обмена информацией, определенного в стандарте. Данный обзор не должен включать спецификации конкретных протоколов, если отсутствует явная зависимость, хотя информативный контент, описывающий ожидаемое содержание, является разумным. В большинстве случаев в данном разделе должны быть указаны ссылки на другие стандарты и, как и в физическом представлении, обзор должен быть как можно более широким.
7.2.5.2 Безопасность и защита данных
Описание архитектуры должно объяснять, как будут обеспечиваться безопасность и защита данных для интерфейса и физических объектов. Часто это достигается путем проведения анализа конфиденциальности, целостности и доступности (CIA) в рамках стандарта, который формирует требования безопасности и конфиденциальности для интерфейса.
7.3 Использование терминов
Во избежание путаницы описание архитектуры ИТС не должно включать определения любых терминов, уже определенных в следующих стандартах:
(справочное)
В то время как 7.2 предоставляет разработчику стандарта свободу структурировать стандарт в соответствии с конкретными потребностями, относящимися к данному стандарту, примеры оформления и изложения отдельных положений стандарта могут быть полезны для разработчиков. Данное приложение содержит примеры изложения разделов стандартов, таких как словарь данных, спецификация интерфейса и базовая спецификация интерфейса.
Первый пример относится к стандарту, который определяет данные для использования различными протоколами. Пример описания области применения (раздел 1) такого стандарта представлен на рисунке A.1.
словаря данных
Настоящий стандарт определяет данные для управления электронными дорожными информационными табло (ДИТ). Дорожные информационные табло являются элементами придорожной инфраструктуры, которые могут управляться на основе определенного интерфейса. Система, управляющая ДИТ, может быть центральной управляющей системой или другим элементом придорожной инфраструктуры, ноутбуком, с помощью которого производится техническое обслуживание ДИТ, или каким-либо другим устройством, поддерживающим интерфейс.
Дорожное информационное табло должно иметь связь с системой управления и может иметь связь с другими информационными системами, представляющими услуги сервисов ИТС.
Рисунок X — Физическое представление интерфейса
Рисунок A.1 — Пример оформления раздела «Область применения»
словаря данных
Пример описания архитектуры стандарта представлен на рисунке A.2 в виде приложения A.
(справочное)
A.1 Справочная информация по архитектуре
В настоящем стандарте рассмотрены технические детали, приведенные в справочнике по гармонизированной архитектуре для технических стандартов (HARTS). Область применения данной архитектуры доступна по адресу: http://htg7.org/html/analysis/servicepackages.html.
A.2 Функциональное представление интерфейса
Настоящий стандарт определяет концепции данных, используемые при управлении информационными табло и не включает логику, используемую для управления информационными табло, или протоколов, используемых для обмена определенными элементами данных; однако концепции данных, определяемых в данном стандарте, разработаны в предположении о том, что обмен этими данными будет с использованием интерфейса, подобного SNMP.
A.3 Физическое представление интерфейса
В настоящем стандарте рассмотрены интерфейсы между информационными табло и физическими объектами, которые могут ими управлять, как правило, центрами или другими объектами придорожной архитектуры.
Основные информационные потоки, рассматриваемые с учетом области применения настоящего стандарта, включают:
- данные динамических вывесок проезжей части; информацию, используемую для инициализации, настройки и управления знаками динамических сообщений. Этот поток может предоставлять содержимое сообщений и атрибуты доставки, запросы на обслуживание локального хранилища сообщений, команды режима управления, запросы о состоянии и другие команды и связанные параметры, поддерживающие удаленное управление этими устройствами;
- состояние динамических вывесок проезжей части: текущее рабочее состояние знаков с динамическими сообщениями.
A.4 Коммуникационное представление интерфейса
На рисунке Y представлены данные, используемые прикладными сущностями эталонной модели архитектуры сервисов ИТС.
Аутентификация и авторизация зависят от схемы безопасности транспортного уровня (DTLS)/безопасности транспортного уровня (TLS) с учетом требований [4] или [5]. Шифрование допускается проводить в соответствии с требованиями с использованием любого метода шифрования с зарегистрированным OBJECT IDENTIFIER.
Рисунок A.2 — Пример описания архитектуры стандарта
словаря данных
A.3 Пример спецификации ИТС приложения
Второй пример относится к стандарту, определяющему спецификацию приложения ИТС. Пример описания области применения представлен на рисунке A.3.
Настоящий стандарт определяет интерфейс между системой управления и оборудованием придорожной инфраструктуры. Система управления может быть любого типа, но, как правило, это либо центральная управляющая система или другой объект придорожной инфраструктуры.
Объект придорожной инфраструктуры должен иметь связь с системой управления и может иметь связь с другими внешними системами, предоставляющими услуги ИТС сервисов.
Рисунок X — Физическое представление интерфейса
Рисунок A.3 — Пример описания области применения стандарта
спецификации ИТС приложения
Пример описания архитектуры стандарта представлен на рисунке A.4 в виде приложения A.
(справочное)
A.1 Справочная информация по архитектуре
В настоящем стандарте рассмотрены технические детали, приведенные в справочнике по гармонизированной архитектуре для технических стандартов (HARTS). Область применения данной архитектуры доступна по адресу: http://htg7.org/html/analysis/servicepackages.html.
A.2 Функциональное представление интерфейса
Настоящий стандарт определяет функциональность, рабочие характеристики и другие требования к информационным табло и не включает логику, используемую системой управления при определении длительности показа или содержания выводимых сообщений или протокола, используемого при обмене элементами данных. Специфические процессы HARTS, относящиеся к области применения стандарта, включают:
A.3 Физическое представление интерфейса
В настоящем стандарте рассмотрены интерфейсы между информационными табло и физическими объектами, которые могут ими управлять, как правило, центрами или другими объектами придорожной архитектуры. Особенности информационных потоков, рассматриваемые в настоящем стандарте, включают:
- динамические данные табло: информация, используемая для инициализации, конфигурации и управления динамическими информационными табло. Данный поток может обеспечить информационный контент и атрибуты передачи, запросы на обслуживание, команды режима управления, запросы состояния и все другие команды и связанные параметры, которые поддерживают удаленное управление этими устройствами:
- состояние динамических табло на проезжей части: текущее рабочее состояние динамических информационных табло.
A.4 Коммуникационное представление интерфейса
На рисунке Y представлены данные, используемые прикладными сущностями эталонной модели архитектуры ИТС сервисов.
A.5 Безопасность и защита данных
Аутентификация и авторизация зависят от схемы безопасности транспортного уровня (DTLS)/безопасности транспортного уровня (TLS) с учетом требований [4] или [5]. Шифрование допускается проводить в соответствии с требованиями с использованием любого метода шифрования с зарегистрированным OBJECT IDENTIFIER.
A.4 Пример спецификации базового интерфейса
Последний пример относится к стандарту, определяющему протокол уровня объектов. Данный пример представлен на рисунке A.5.
Настоящий стандарт определяет интерфейс между системой управления и оборудованием придорожной инфраструктуры. Система управления может быть любого типа, но, как правило, это либо центральная управляющая система или другой объект придорожной инфраструктуры.
Объект придорожной инфраструктуры должен иметь связь
с системой управления и может иметь связь с другими внешними
системами, предоставляющими услуги ИТС сервисов
Рисунок X — Физическое представление интерфейса
Рисунок A.5 — Пример описания области применения стандарта
уровня объектов
Пример описания архитектуры в виде приложения представлен на рисунке A.6.
(справочное)
A.1 Справочная информация по архитектуре
В настоящем стандарте рассмотрены технические детали, приведенные в справочнике по гармонизированной архитектуре для технических стандартов (HARTS). Область применения данной архитектуры доступна по адресу: http://htg7.org/html/analysis/servicepackages.html.
A.2 Функциональное представление интерфейса
В настоящем стандарте рассмотрены сеансовые, представительные и прикладные уровни эталонной модели OSI; стандарт определяет операции данных слоев, а также данных, используемых при управлении этими операциями, но не включает функциональность ядра оборудования придорожной инфраструктуры. Стандарт определяет, как оборудование придорожной инфраструктуры принимает и отвечает на сообщения. Стандарт устанавливает два механизма, используя которые управляющая станция взаимодействует с оборудованием придорожной инфраструктуры: формирование содержания информационного сообщения (настройка, конфигурация и т.д.), получение содержания информационного сообщения (данные, конфигурация и т.д.).
A.3 Физическое представление интерфейса
В настоящем стандарте рассмотрен интерфейс между оборудованием придорожной инфраструктуры и физическими объектами, управляющими этим оборудованием; как правило, это центры и другие объекты придорожной инфраструктуры.
A.4 Коммуникационное представление интерфейса
Данный стандарт распространяется на слои объектов эталонной модели архитектуры сервисов ИТС.
A.5 Безопасность и защита данных
Аутентификация и авторизация зависят от схемы безопасности транспортного уровня (DTLS)/безопасности транспортного уровня (TLS) с учетом требований стандартов [4] или [5]. Шифрование допускается проводить в соответствии с требованиями с использованием любого метода шифрования с зарегистрированным OBJECT IDENTIFIER.
Аутентификация осуществляется дополнительно в самом приложении в соответствии с RFC 6353 [3].
(справочное)
B.1 Функциональная точка зрения
Функциональная точка зрения относится к анализу абстрактных функциональных элементов и их логических взаимодействий, а не к инженерным проблемам того, как реализованы функции, где они распределены, как они передают информацию, какие протоколы используются и какой метод используется для их реализации.
Функциональная точка зрения раскрывает поведение, структуру и взаимодействие функций, выполняемых в среде кооперативных ИТС.
Поведение функции (т.е. процесса) — это набор действий, выполняемых этой функцией для достижения цели. Процесс выполняет действия для достижения цели приложения или для поддержки действий другого процесса. Эти действия могут включать сбор данных, преобразование данных, генерацию или обработку данных. Функциональная точка зрения определяет процессы для контроля и управления поведением системы, такие как мониторинг и другие активные функции управления, которые являются частью описания функционального поведения системы. Она также описывает функции обработки данных, хранилища данных и логические потоки информации между этими элементами.
Функциональная точка зрения согласуется с содержанием HARTS, эталонной архитектурой реализации подключенного транспортного средства (CVRIA), архитектурой справочника по кооперативной и интеллектуальной транспортировке (ARC-IT), также известной как Национальная архитектура ИТС США, Европейской инфраструктурной архитектурой ИТС (FRAME) и другими основными эталонными архитектурами ИТС. На рисунке B.1 приведена схема функционального представления Европейской инфраструктурной архитектуры ИТС FRAME.
Физическая точка зрения представляет физические элементы, которые работают в мобильной внешней среде и в служебных помещениях с отображением связи между элементами и взаимодействием с объектами внешней среды.
Физическая точка зрения имеет дело с составом этих физических объектов (включая серверы приложений, хранилища данных, сетевые компоненты, мобильные и немобильные устройства, транспортные элементы, а также проводные и беспроводные соединения), их физические соединения и взаимодействия, а также распределение функциональных возможностей этих элементов.
Каждая диаграмма физического представления включает физические объекты, которые участвуют в предоставлении и выполнении набора одной или нескольких услуг ИТС. На рисунке B.2 приведена диаграмма физического представления сигнала приоритета для транзитного транспортного средства.
Рисунок B.2 — Пример диаграммы физического представления
сигнала приоритета для транзитного транспортного средства
Имеется ряд соглашений, касающихся графического представления информации физической точки зрения, как показано на рисунке B.3.
К основным категориям физических объектов относятся:
- центр: объект, обеспечивающий прикладные, управленческие, административные и вспомогательные функции из фиксированного местоположения, не находящегося в непосредственной близости от дорожной сети. Термины «бэк-офис» и «центр» взаимозаменяемые;
- окружение: объект, расположенный рядом с транспортной сетью или вдоль нее, который осуществляет: - наблюдение (например, с помощью детекторов движения, камер); - управление движением (например, с помощью обработки сигналов); - предоставление информации [например, с помощью динамических информационных табло (ДИТ)]; - локальные транзакции (например, взимание платы за проезд, парковку); - предоставление услуг беспроводной связи между мобильными элементами и стационарной инфраструктурой. Как правило, их работа регулируется функциями управления, работающими в центрах;
- поддержка: объект, как правило, с фиксированным местоположением, предоставляющий услуги поддержки для одного или нескольких других объектов;
- путешественник: оборудование, используемое путешественниками для доступа к транспортным услугам перед поездкой и в пути. Оно включает в себя оборудование, которое находится в собственности и под управлением путешественника, а также оборудование, которое принадлежит транспортным и информационным провайдерам;
- транспортное средство: элементы, относящиеся к транспортным средствам, на борту транспортных средств. Физические объекты транспортного средства включают в себя общую информацию о водителе и системы безопасности, применимые ко всем типам транспортных средств.
B.3 Коммуникационная точка зрения
Коммуникационная точка зрения определяет стандарты связи, которые необходимы для поддержки связи между физическими объектами, участвующими в кооперативных ИТС. Эти протоколы должны соответствовать требованиям к производительности и ограничениям, налагаемым физической связью, окружающей средой, операционными проблемами и соответствующими политиками (таких как обеспечение анонимности предоставляемых обязательных данных). Предпочтительный формат для изображения информации с коммуникационной точки зрения заключается в размещении необходимых стандартов связи в схеме архитектуры станции ИТС, пример которого показан на рисунке B.4.
Рекомендации для руководства в отношении методологии конкретной архитектуры в контексте ИТС приведены в [6].
(справочное)
СВЕДЕНИЯ О СООТВЕТСТВИИ ССЫЛОЧНЫХ НАЦИОНАЛЬНЫХ СТАНДАРТОВ
МЕЖДУНАРОДНЫМ СТАНДАРТАМ, ИСПОЛЬЗОВАННЫМ В КАЧЕСТВЕ
ССЫЛОЧНЫХ В ПРИМЕНЕННОМ МЕЖДУНАРОДНОМ СТАНДАРТЕ
| Обозначение ссылочного национального стандарта | Степень соответствия | Обозначение и наименование ссылочного международного стандарта |
| ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 | IDT | ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры» |
| ГОСТ Р ИСО/МЭК 8824-1-2001 | IDT | ISO/IEC 8824-1:1998 «Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации» |
| ГОСТ Р ИСО/МЭК 9834-1-2009 | IDT | ISO/IEC 9834-1:2005 «Информационная технология. Взаимосвязь открытых систем. Процедуры действий уполномоченных по регистрации ВОС. Общие процедуры и верхние дуги дерева идентификатора объекта АСН.1» |
| ГОСТ Р ИСО/МЭК 11179-3-2012 | IDT | ISO/IEC 11179-3:2003 «Информационная технология. Регистры метаданных (РМД). Часть 3. Метамодель регистра и основные атрибуты» |
| Примечание — В настоящей таблице использовано следующее условное обозначение степени соответствия стандартов: - IDT — идентичные стандарты. | ||
БИБЛИОГРАФИЯ
| УДК 656.035:006.354 | ОКС 03.220.20 |
| Ключевые слова: интеллектуальная транспортная система, архитектура эталонной модели, сервис ИТС, представление архитектуры, точка зрения на архитектуру | |