Комаров В.В., Гараган С.А. Архитектура и стандартизация ИТС. Зарубежный опыт и отечественная практика (2012) (1142010), страница 24
Текст из файла (страница 24)
Инновации могут быть включены в более позднюю версию архитектуры FRAME,как уже было сделано для кооперативных систем проектом Е-FRAME.Системное проектирование – Технологии [63]Ряд мероприятий Плана действий по ИТС связан с определенными технологиями, например, система позиционирования EGNOS/Galileo, RFID иоткрытая архитектура платформы транспортного средства. Такая зависимость от технологий не должна быть характерна для АрхитектурыИТС, но функциональность, которую они обеспечивают, должна бытьи чаще всего уже включена в Архитектуру FRAME. Архитектура ИТСопределяет различные интерфейсы, которые существуют между компонентами, и использование определенной технологии в этих интерфейсахдолжно быть предусмотрено стандартами, использование которых может быть разрешено Директивой ИТС.COOPERS – Cooperative Systems for intelligent road safety (Кооперативные системыинтеллектуальной дорожной безопасности) – проект, софинансировавшийся ЕСв 2006-2010 гг..25124Архитектура ИТСАрхитектура ИТС – это проект высокого уровня, который определяетструктуру, поведение и интеграцию данной системы в ее окружающемконтексте.
Она формирует основу для класса систем и, следовательно,для ряда проектов низкого уровня. Различные проекты низкого уровня могут быть созданы различными изготовителями. Приверженность архитектуре ИТС гарантирует способность к взаимодействию, открытыйрынок для услуг и оборудования, поскольку имеются «стандартные» интерфейсы между компонентами.Использование Архитектуры FRAME [63]Архитектура FRAME предназначена для использования в нижней частиверхнего уровня подхода к планированию и развертыванию интегрированнойИТС (рис. 1.17). Общая концепция может быть представлена в виде формальной (эталонной) модели или ином виде.Общая концепция и структура системы должны быть описаны независимым от технологии способом, чтобы при развитии технологии всевысокоуровневые требования остались неизменными. Информация, содержащаяся в пределах структуры системы, позволяет промышленностиИТС производить оборудование и системы, которые окажут услуги, желаемые заинтересованными сторонами, каждые с их собственными отличительными особенностями, но соответствующие целям, выраженнымв общей концепции и структуре системы.
Таким образом, услуги интегрированных и/или взаимодействующих ИТС могут быть оказаны на всейтерритории ЕС.Рисунок 1.17. Использование архитектуры FRAMEв процессе разработки системы.125Структура системы содержит много аспектов. Функциональность,необходимая для реализации услуг ИТС, обеспечивается функциональнойструктурой26, которая не требует использования определенных технических решений от его пользователей.
Каждое определенное внедрение требует, чтобы заинтересованными сторонами был сделан выбор, в особенноститого, какие компоненты будут использоваться для внедрения ИТС и связеймежду ними (аппаратное обеспечение).Дальнейший анализ, также основанный на определенном выборе или решениях, может тогда обеспечить:–– Коммуникационное обеспечение – требования к связям между компонентами.–– Организационную структуру – кому принадлежит, кто управляет иприменяет каждый компонент и другие организационные проблемы.–– Информационное обеспечение – используемая информация, ее атрибуты и отношения.Содержание аппаратного и коммуникационного обеспечения можетбыть включено в объявления о торгах для обеспечения и развертываниякомпонентов и коммуникаций.
Организационная структура используетсяв управленческой структуре и нормативно- правовом обеспечении предоставления услуг.Создание Архитектуры ИТС с использованием FRAME [63]Методология создания архитектуры ИТС из архитектуры FRAME показана на рис. 1.18. Использование особых технологий или продуктов поставщика не включено в архитектуру FRAME.
Это важно по двум причинам.Во-первых, архитектура ИТС, созданная с использованием такого подхода,не будет устаревать в случаях достижений в технологии или разработкепродуктов, и, во-вторых, это открывает возможность для развития новых технологий, чтобы обеспечивать лучшую функциональность.Стремления заинтересованных сторонСтремления заинтересованных сторон (Stakeholder Aspirations) – требования, которые выражают ожидания и желания различных заинтересованных сторон в отношении услуг, которые окажет внедренная ИТС. Онидолжны быть написаны заинтересованными сторонами, но опыт показал,что часто необходима помощь от команды архитектуры. Есть следующиечетыре класса заинтересованных сторон:26Методология FRAME использует термин «Точки зрения» для частей, которые составляют Архитектуру FRAME и получаемую из нее Архитектуру ИТС.
Это соответствует рекомендациям IEEE 1471.126Рисунок 1.18. Методология создания Архитектуры ИТСиз Архитектуры FRAME.инициаторы ИТС – этот класс включает организации, которые нуждаются в услугах ИТС, чтобы обеспечить безопасное и эффективное использование дорожных сетей. Он также включает операторов общественноготранспорта и грузовых операторов, которым ИТС может позволить улучшить эффективность перевозки людей и грузов.пользователи ИТС – этот класс включает конечных пользователей, которые используют услуги ИТС и/или управляют оборудованием.
Он включаетпассажиров в мультимодальной поездке, так же, как водителей всех классовтранспортных средств; грузоотправителей; менеджеров общественноготранспорта и специалистов системных операторов.законодатели ИТС – этот класс представляет тех, кто создает правила и стандарты. Он включает национальные правительства и различныеорганы, выпускающие стандарты.127изготовители ИТС – класс включает производителей систем и оборудования, коммуникационных поставщиков и системных интеграторов.Поставщики услуг, например, информации о поездке и планировании поездок, могут относиться к одному или более классам.Пользовательские потребностиНормальным является то, что стремления заинтересованных сторонбудут написаны во множестве стилей.
Иногда они могут также быть неясными и непоследовательными. Таким образом, необходимо переписать ихв последовательной манере, которая является подходящей для следующейстадии процесса. В результате формируется ряд потребностей пользователей, которые выражают стремления заинтересованных сторон в последовательной и стилизованной манере, с измеряемыми показателями.В проекте KAREN в конце 1990-ых годов было рассмотрено приблизительно 550 пользовательских потребностей, охватывающих приложения иуслуги ИТС. В проекте Е-FRAME – приблизительно 230 пользовательских потребностей в кооперативных системах. Таким образом, используя архитектуру FRAME, команда архитектуры может использовать пользовательскиепотребности из существующего списка. [63]Объединение пользовательских потребностей для кооперативных систем должно быть выполнено тщательно, чтобы не получить отрицательного воздействия на существующую архитектуру FRAME, и так, чтобы онисоответствовали существующей структуре.
Основными источниками информации были coфинансируемые EC интегрированные проекты COOPERS,CVIS и SAFESPOT, у которых было немного сходства и много различий. Поэтому было необходимо рассматривать их индивидуально на начальной фазеи затем объединить их отдельные списки пользовательских потребностейво время второй фазы.Приложения и услуги кооперативных систем были изучены другими проектами, использующими отличающуюся терминологию.
Поэтомубыла создана таксономия для объединения терминов, использованных вETSI TR 102 638 и PRE-DRIVE C2X, с теми, которые уже используют вархитектуре FRAME. В результате стало возможно включить новые пользовательские потребности в существующую структуру пользовательскихпотребностей FRAME. [45]Функциональная структура [63]Функциональная структура (иногда называемая логической структурой)показывает функции, которые требуются для выполнения пользователь128ских потребностей, и, следовательно, желаний заинтересованных сторон.Используя архитектуру FRAME, функциональную структуру изображаютв виде диаграмм потоков данных, которые содержат функции, хранилища данных, терминаторы и данные, которые перемещаются между ними.Каждому из элементов сопоставляют его собственное описание, котороев случае функций включает утверждения, объясняющие, что они делают.Так как архитектура FRAME включает функциональную структуру, которая удовлетворяет все ее пользовательские потребности, команда архитектуры должна только выбрать те ее части, которые удовлетворяютпользовательские потребности.