Обзор методов проектирования архитектур интеллектуальных
транспортных систем
В.С. Лапшин, Д.М.Елькин, С.А. Кучеров, Ю.И. Рогозов Южный федеральный университет, Ростов-на-Дону
Аннотация: В данной работе приводится обзор и анализ методов проектирования архитектур для интеллектуальных транспортных систем. Рассматриваются два основных подхода к проектированию архитектур, используемых в США и Европейском союзе. Определена роль этапа проектирования архитектуры в процессе разработки проектов для интеллектуальных транспортных систем. Сделано разграничение между высокоуровневым и низкоуровневым подходом к проектированию архитектур интеллектуальных транспортных систем. Определены перспективные направления развития для методов проектирования архитектур такого типа.
Ключевые слова: архитектура, интеллектуальные транспортные системы, подсистемы, функциональная и физическая архитектура, сервисы.
Введение
В конце 2017 года, по данным ГИБДД, в Москве было зарегистрировано порядка 5,6 млн. автомобилей при этом, ежегодный прирост составляет 8-10%. Схожая динамика наблюдается и в других крупных городах по всему миру, что приводит к множеству проблем в транспортной сфере и как следствие к снижению экономической эффективности регионов [1]. На сегодняшний день, самым перспективным из способов решения транспортных проблем является внедрение интеллектуальных транспортных систем (ИТС) [2]. Согласно нормативному документу Российской Федерации (ГОСТ Р 56294-2014 Интеллектуальные транспортные системы. Требования к функциональной и физической архитектурам интеллектуальных транспортных систем)под ИТС понимается система, интегрирующая современные информационные, коммуникационные и телематические технологии, технологии управления и предназначенные для автоматизированного поиска и принятия к реализации максимально эффективных сценариев управления транспортной системой региона, конкретным транспортным средством или группой транспортных средств с
целью обеспечения заданной мобильности населения, максимизации показателей использования дорожной сети, повышения безопасности и эффективности транспортного процесса, комфортности для водителей и пользователей транспорта. В процессе проектирования систем такого типа, основополагающим этапом является разработка её архитектуры. Поскольку транспортная отрасль является особо динамичной системой, то и архитектура для этой системы должна учитывать особенности такой динамики, иными словами, обладать адаптивными свойствами [3]. В данной работе будут рассматриваться два основных подхода к проектированию архитектуры ИТС, с акцентом на реализации адаптивных свойств таких систем.
Концепция архитектуры для интеллектуальной транспортной системы
Основной особенностью любой интеллектуальной системы является возможность выполнения творческих функций, которые традиционно принято считать прерогативой человека. Другими словами, интеллектуальная система, в отличие от информационной системы, способна проявлять активность при отсутствии воздействия или прямых указаний человека. Любая интеллектуальная система, это прежде всего техническая или программно-техническая система, способная получать творческие решения задач, принадлежащие конкретной предметной области, знания о которой хранятся в памяти такой системы. Частным примером интеллектуальной системы является ИТС, поскольку в ней используются различные инновационные разработки для управления автомобильными потоками с целью решения широкого спектра задач, причем алгоритмы решений таких задач могут быть формализованы не четко, или же совсем не формализованы.
Для организации систем такого рода, на начальном этапе необходимо спроектировать ее архитектуру. Поскольку процессы проектирования интеллектуальных систем тесно связаны с особенностями сфер, в которых
такие системы будут функционировать, процессы построения архитектуры ИТС также имеют свои особенности.
Архитектура ИТС определяет основные принципы организации и взаимосвязи компонентов как между собой, так и с внешней средой, а также принципы и руководство по их разработке, внедрению и оценке эффективности использования. Она представляет собой некую рамочную структуру, в границах которой могут быть предложены различные подходы к проектированию с учетом индивидуальных потребностей заказчика и необходимых пользовательских сервисов. Стандартизация архитектуры способствует систематическому и последовательному внедрению и непрерывному усовершенствованию подсистем (сервисов) ИТС.
Принято определять два типа архитектур: высокого и низкого уровня. Высокоуровневая архитектура представляет под собой идеализированную общую схему организации ИТС включающую в себя описание процессов планирования, определения, и интеграции интеллектуальных транспортных систем [4,5]. Поскольку она является базисом для разработки ИТС, то формируется с учетом обеспечения ее актуальности на долгосрочный период. Низкоуровневая архитектура представляет собой схему организации ИТС для конкретного региона, включающую в себя формализованные процессы интеграции, поддержки и развития такой системы. Далее рассмотрим два основных подхода, используемых при проектировании архитектуры ИТС -это американский и европейский подходы.
Исследование процесса проектирования архитектуры интеллектуальной
транспортной системы в США
Высокоуровневая архитектура
Высокоуровневая архитектура в США определяется как «национальная архитектура» (National ITS Architecture). Под национальной архитектурой
II Инженерный вестник Дона, №4 (2018) Н| ivdon.ru/ru/magazine/arcliive/n4y2018/5422
США понимается структура, вокруг которой могут быть построены различные элементы ИТС. В частности, она определяет компоненты и связи, которые входят в состав ИТС, без неоправданных ограничений определенными технологическими решениями, используемыми при внедрении [6].
Logical Architecture
rjtH
Processes
Data Flows
Physical Architecture
м Physical Entities
■Я ЯШМ
Architecture Flows Equipment Packages
Market Packages
Market Packages
Standards t
V,
Рис. 1. - Национальная архитектура ИТС США Как можно увидеть на рис. 1 национальная архитектура США состоит из логической и физической ее составляющих частей, обеспечивающих реализацию пользовательских сервисов. Под пользовательскими сервисами понимается функционал системы, предназначенный для конечного потребителя, в данном случае, самым массовым потребителем услуг оказываемых ИТС является водитель автотранспортного средства. Примером такого сервиса может служить система автоматического распознавания дорожно-транспортного происшествия и оперативный вызов служб экстренного реагирования. Логическая архитектура отвечает за четкое определение процессов - действий и функций необходимых для реализации пользовательских сервисов. Важно понимать, что в логической архитектуре определяется именно то, «что» должен делать сервис, но не указываются
конкретные варианты его реализации. В физической архитектуре определятся основные технические компоненты, необходимые для реализации пользовательского функционала, а также реализуются функции, описанные в логической архитектуре. На сегодняшний день существуют отдельные программно-аппаратные комплексы, призванные решать определенные транспортные проблемы. Такие технические решения могут устанавливаться на отдельных участках улично-дорожной сети, и функционировать автономно друг от друга. В национальной архитектуре ИТС США также предусмотрена возможность для интегрирования различных систем такого рода (на рис. 1 пул таких систем отображается в виде блока «MarketPakeges») в общую архитектуру. Поскольку четкое определение стандартов и требований, является необходимым условием для обеспечения совместимости между подсистемами ИТС, фундамент для их создания также определяется в национальной архитектуре с учетом сформированной логической и физической архитектуры.
Низкоуровневая архитектура
Низкоуровневая архитектура в США определяется как «региональная архитектура» (Regional ITS Architecture). Концепция построения региональной архитектуры является очень удобным инструментом для разработки и внедрения проектов ИТС в регионах. Проект региональной архитектуры включает в себя все требования региональных заказчиков, которые должны будут удовлетворяться с течением определенного периода времени. Реализация локального проекта интеллектуальной транспортной системы - это последовательный процесс, в котором определены механизмы для привлечения инвестиций и пул технологических решений. Этап по построению региональной архитектуры необходим для получения формализованного представления о структуре системы для обеспечения понимания о том, как такую систему возможно масштабировать или
Il Инженерный вестник Дона, №4 (2018) Н| ivdon.ru/ru/magazine/arcliive/n4y2018/5422
сопрягать с другими системами такого типа. Процесс разработки региональной архитектуры [5] схематично представлен на рис. 2.
STEP #1 : СЕТ STARTED
(See Section 3)_
Identify Meed Define Scope Identify Stakeholders Identify Champions
STEP #2: GATHER DATA
_(See Section 4)_
Define Inventory Determine Needs and Services Develop Operational Concept Define Functional Requirements
STEP #3: DEFINE INTERFACES
_(See Section S)_
Identify Interconnects Define Information Flows
i/} un
<u и О
> 4-J
nj
L—
OJ
STEP#4: IMPLEMENTATION
_(See Section 6)_
Define Project Sequencing Develop List of Agency Agreements ^Identify ITS Standards
STEP #5: USE THE REGIONAL ARCHITECTURE
(See Section 7)_
STEP #6: MAINTAIN THE REGIONAL ARCHITECTURE
_(See Section 8)_
Рис. 2. - Процесс разработки региональной архитектуры ИТС США
Как можно видеть на рис. 2, процесс создания региональной архитектуры включает шесть основных шагов, четыре из которых определяют процессы ее разработки (с шага№1 по шаг№4), и два последних - процессы поддержки необходимые при ее функционировании.
Таким образом, процесс проектирования архитектуры ориентирован на анализ требований заинтересованных сторон, на основе которого строится проектирование конкретных технических реализаций систем. В связи с
бурным развитием транспортной отрасли, часто возникают ситуации, когда сформированные на начальном этапе требования оказываются неполными и спроектированная система не может осуществить их выполнение. Таким образом, системы, построенные в рамках данной концепции, не смогут отвечать современным требованиям реализации адаптивных свойств.
Исследование процесса проектирования архитектуры интеллектуальной транспортной системы в странах Европы
Высокоуровневая архитектура
В европейском подходе высокоуровневая архитектура называется FRAMEARCHITECTURE (что можно перевести как рамочная архитектура). Она была разработана в 2000 году в результате реализации проекта KAREN (Keystone Architecture Required for Evropean Networks) [7]. Основным замыслом FRAME архитекторы является обеспечение возможностей для:
• снижения затрат при разработке низкоуровневых архитектур за счет использования функционального базиса, сформированного в FRAME архитектуре;
• снижения рисков при интеграции функционала сервисов двух разных архитектур, поскольку сформированные на одной базе различные низкоуровневые архитектуры обладают такими же свойствами, как и базовая архитектура. Также, использование одного базиса при создании низкоуровневых архитектур облегчает использование аналогичного оборудования в разных вариантах исполнения и, таким образом, расширяет их потенциальный рынок.
Европейская архитектура независима от конкретных технологий, благодаря этому фактору она остается актуальной в течение длительного периода времени и ориентирована на использование как текущих современных технологических решений, так и технологий, которые
II Инженерный вестник Дона, №4 (2018) Н| ivdon.ru/ru/magazine/arcliive/n4y2018/5422
возможно появятся в будущем. В процессе проектирования конкретных ИТС на базе архитектуры FRAME учитываются условия и амбиции всех заинтересованных лиц, которые так или иначе будут затронуты в процессе эксплуатации такой системы. Такие условия и амбиции, в, конечном итоге, преобразуются в сервисы удовлетворения потребностей пользователей. В высокоуровневой архитектуре европейского типа определено и формализовано более пяти сотен потребностей пользователей, которые
можно удовлетворить за счет организации сервисов в ИТС.
FRAME Architecture
Stakeholder Aspirations
I
User Needs
I
Functional Viewpoint
\
ITS Architecture Subset
Selected Sub-set of User Needs
i
Selected Sub-set of Functions
±
I
Extra User Needs
I
Extra Functions
I
Physical, Communications and other Viewpoints
Рис. 3. - Процесс создания подсистемы архитектуры ITS
Как можно видеть на рис. 3, содержание FRAME архитектуры можно разделить на два логических блока - «потребности пользователей» (UserNeeds) и «функциональное обеспечение» (FunctionalViewpoint). Блок «потребности пользователей» - описывает сервисы, которые может предоставить ИТС, а в блоке «функциональное обеспечение» описывается как можно такие сервисы реализовать. С начала своего создания европейский подход к построению высокоуровневой интеллектуальной транспортной системы развивается и постоянно модернизируется. На момент проведения
IH Инженерный вестник Дона. №4 (2018) Н| ivdon.ru/ru/magazine/arcliive/n4y2018/5422
данного исследования была опубликована версия архитектуры 4.1 которая была дополнена сервисами кооперативных ИТС и другими приложениями из развивающихся проектов в этой области [8].
Далее рассмотрим процесс создания локальных ИТС на базе архитекторы FRAME.
Низкоуровневая архитектура
Процесс создания конкретной архитектуры ИТС на базе FRAME архитектуры начинается с формализации пожеланий всех субъектов, которых так или иначе затрагивает разрабатываемая система (заинтересованных сторон), и продолжается до тех пор, пока не будут разработаны технические требования для отдельных компонентов такой системы и связей между ними
FRAME архитектуры
В данной схеме процесса создания низкоуровневой архитектуры, используется термин «Viewpoint», что дословно можно перевести как «точка зрения», использование которого обусловлено требованиями стандарта [10]. В контексте проектирования архитектур информационных систем, данный термин применяется для определения локальных «промежуточных» архитектур, являющихся частями конечной, более глобальной архитектуры ИТС. Как можно увидеть, процесс, представленный на рис. 4, состоит из четырех основных этапов:
• сбор требований к системе от заинтересованных сторон (Stake holders aspirations)
• формализация требований заинтересованных сторон (User Needs)
• создание функциональной архитектуры (Functional Viewpoint)
• создание физической архитектуры (Physical Viewpoint)
• создание архитектуры коммуникаций (Communications Viewpoint)
Поскольку задача создания системы, которая обладала бы функционалом и инструментами для решения всевозможных транспортных проблем, является сверхкомплексной и требующей вливания колоссального объема материальных ресурсов, то, как правило, такого рода системы реализуются для решения конкретного набора задач. В связи с этим, на первом этапе создания локального проекта ИТС решается вопрос, связанный с определением требований к такой системе, от всех заинтересованных сторон. Обычно, такими заинтересованными сторонами могут являться:
• компании, занимающиеся обслуживанием участков улично-дорожной сети и представители гос. служб, отвечающие за контроль над результатами такого обслуживания;
• пассажиры и водители, которые являются основными пользователями услуг, предоставляемых ИТС;
• гос. структуры, отвечающие за разработку нормативно-правовых документов и правил для использования транспортной системы;
• компании, занимающиеся производством различного оборудования и услуг для транспортной системы.
После определения всех требований от всех заинтересованных сторон, необходимо их представить в едином формате и структурировать по группам. Для этого, все требования пользователей переписываются последовательно, в едином стиле, с возможностью построения первичной картины будущей системы. Далее, в соответствии с определенными требованиями строится функциональная «картина» будущей системы, которая показывает, какие функциональные блоки необходимы для реализации требований заинтересованных сторон и как эти блоки взаимосвязаны между собой. После определения функциональной архитектуры идет процесс разработки физической архитектуры, которая является описанием модулей и подсистем. На основе одной функциональной архитектуры, можно составить насколько разных по структуре физических ее воплощений. Это является очень удобной особенностью, поскольку это позволяет найти наилучшее решение, которое сможет максимально равноправно удовлетворять потребности всех заинтересованных сторон. Одной из особенностей построения функциональной архитектуры является разграничение описания функций и хранилищ данных. В связи с этим можно четко определить, какие потоки данных проходят внутри подсистемы или модуля, а какие отвечают за связь с другими подсистемами. Поэтому, на одном из завершающих этапов на основе анализа каждого потока физических данных определяются структура и спецификации для каналов связи. Результаты этого анализа можно сравнить со списком соответствующих и
доступных стандартов связи, чтобы найти тот, который наиболее удовлетворяет структуре архитектуры. Однако, если это не представляется возможным, результаты этого анализа могут быть использованы в качестве основы для определения нового стандарта. После выполнения описанных этапов составляется перечень требований к используемому в проектируемой системе техническому оборудованию и к стандартам каналов связи. На этом процесс проектирования архитектуры завершается.
Таким образом, в отличие от американского подхода, европейская архитектура не ориентирована на конкретные технологические решения. В процессе проектирования таких архитектур делается акцент на обеспечении «гибкости» реализуемых физических систем, с целью обеспечения возможности для их дальнейших модификаций. Такой подход обеспечивает условия и возможности для «перестройки» существующих систем под вновь возникающие требования, однако этот процесс требует определенных финансовых и временных затрат.
Заключение
Как можно увидеть из приведённого обзора, процесс проектирования архитектуры для любой интеллектуальной транспортной системы основывается на анализе требований заинтересованных сторон, на основе которых формируется функциональный базис такой системы. Основное отличие европейского подхода к проектированию архитектуры ИТС от американского заключается в использовании полностью технологически-независимой стратегии формирования локальной архитектуры ИТС, с целью увеличения срока ее актуальности и возможностей использования различной элементной базы. Однако стоит отметить, что такая «нечеткость» в представлении архитектуры системы усложняет процессы ее физического воплощения, поскольку в условиях отсутствии хорошо формализованного
пула «технологических решений» повышает уровень сложности обеспечения такого важного свойства систем такого рода как «интероперабельность».
По итогам выполненного обзора можно сделать вывод, что проанализированные подходы к проектированию архитектур основываются на классической модели проектирования информационных систем, в которой не учитываются реализация возможностей автоматической организации под складывающуюся дорожную обстановку. В связи с тем, что темпы развития транспортного комплекса постоянно увеличиваются, по-прежнему остается актуальной проблема разработки методов проектирования архитектур для интеллектуальных транспортных систем, обладающих адаптивными свойствами.
Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 1S-37-00367.
Литература
1. Зырянов В.В., Моделирование при транспортном обслуживании мега-событий // Инженерный вестник Дона, 2011, №4. URL: ivdon.ru/magazine/archive/n4y2011/709
2. Жанказиев, С.В. Разработка проектов интеллектуальных транспортных систем: учеб. пособие. - М.: МАДИ, 2016. - 104 с.
3. Draganescu C., Popa C., Tundrea A. C. Context-Aware Adaptive System for Intelligent Transport Management //Control Systems and Computer Science (CSCS), 2017 21st International Conference on. - IEEE, 2017. - pp. 379384.
4. Зырянов В.В., Семчугова Е.Ю. Применение информационных технологий при повышении мобильности и обеспечении транспортной безопасности // Инженерный вестник Дона, 2012, №4. URL: ivdon.ru/magazine/archive/n4p1y2012/1083
5. National ITS Architecture Team. Regional ITS Architecture Guidance — Developing, Using and Maintaining on ITS Architecture for Your Region. FHWA-H0P-06-112 EDL-14317July 2006
6. Комаров В.В., Гарагагн С.А. Архитектура и стандартизация телематических и интеллектуальных транспортных систем. Зарубежный опыт и отечественная практика. - М.: НТБ «ЭНЕРГИя», 2012. - 352 с.
7. Nauman Ahmad Khan. Real Time Predictive Monitoring System for Urban Transport, Faculty of Science, Engineering and Computing, Kingston University London, United Kingdom, March 2017- pp. 41-43.
8. An official website of the frame architecture, URL: frame-online.eu (date of access: 22.10.2018).
9. Richard Bossom, Peter Jesty, Angela Spence, Alexander Frotscher and Robert Ebner. Extend FRAME work architecture for cooperative systems, Dissemination Level Public, FP7-ICT-2007.6.2 Nr. 224383, September 2011
10. EEE 1471-2000. Recommended Practice for Architectural Description of Software-Intensive Systems. URL: standards.ieee.org/findstds/standard/1471- 2000.html. (date of access: 22.10.2018).
References
1. Zyrjanov V.V.Inzenernyj vestnik Dona (Rus), 2011, №4. URL: ivdon.ru/magazine/archive/n4y2011/709
2. Zhankaziev, S.V. Razrabotka proektov intellektual'nykh transportnykh system [Project development of intelligent transport systems]: ucheb. posobie. M.: MADI, 2016. 104 p.
3. Draganescu C., Popa C., Tundrea A. C. Control Systems and Computer Science (CSCS), 2017 21st International Conference on. IEEE, 2017. pp. 379-384.
4. Zyryanov V.V., Semchugova E.Yu. Inzenernyj vestnik Dona (Rus), 2012, №4. URL: ivdon.ru/magazine/archive/n4p1y2012/1083
5. National ITS Architecture Team. Regional ITS Architecture Guidance — Developing, Using and Maintaining on ITS Architecture for Your Region. FHWA-H0P-06-112 EDL-14317July 2006
6. Komarov V.V. Arkhitektura i standartizatsiya telematicheskikh i intellektual'nykh transportnykh sistem. Zarubezhnyy opyt i otechestvennaya praktika [Architecture and standardization of telematic and intelligent transport systems. Foreign experience and domestic practice]. M.: NTB «ENERGIya», 2012. 352 p.
7. Nauman Ahmad Khan. Real Time Predictive Monitoring System for Urban Transport, Faculty of Science, Engineering and Computing, Kingston University London, United Kingdom, March 2017- pp. 41-43.
8. An official website of the frame architecture, URL: frame-online.eu (date of access: 22.10.2018).
9. Richard Bossom, Peter Jesty, Angela Spence, Alexander Frotscher and Robert Ebner. Extend FRAMEwork architecture for cooperative systems, Dissemination Level Public, FP7-ICT-2007.6.2 Nr. 224383, September 2011
10.EEE 1471-2000. Recommended Practice for Architectural Description of Software-Intensive Systems, URL: standards.ieee.org/findstds/standard/1471- 2000.html. (date of access: 22.10.2018).