A new system architecture for cooperative traffic centres - the sim TD field trial

Transcription

1 19th ITS World Congress, Vienna, Austria, 22/26 October 2012 EU A new system architecture for cooperative traffic centres - the sim TD field trial Dr. Dirk Hübner 1, Dipl.-Ing. Gerd Riegelhuth 2 1. Heusch/Boesefeldt GmbH, Tempelhofer Str. 4, D Aachen, Germany, +49 (0) , dirk.huebner@heuboe.de 2. Hessen Mobil Straßen- und Verkehrsmanagement, Wiesbaden, Germany Abstract Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication has been a research and development topic for many years now. Today technological improvements offer the required communication bandwidth and allow serial production of in-car-equipment. The R&D project sim TD (safe & intelligent mobility test field Germany) aims to test V2X technology in real life with more than 100 vehicles. It is thus the first V2X project conducting a field trial with a sufficient number of vehicles to achieve significant evaluation results. The field trial is not the only thing, which made sim TD unique: the main project goal is not to test technologies, but to evaluate cooperative applications in real environment including infrastructure and especially the traffic centre to be fully integrated into these applications. Therefore a new cooperative traffic centre was designed and implemented as well, requiring new technical approaches to cope with new functional and non-functional requirements, like information constantly flowing in from a high number of moving probes. This paper presents the approach taken in sim TD concerning the general system architecture of the traffic centre. It then focuses on specific problem areas, like location referencing or software deployment in a cooperative environment. Requirements in sim TD have led to a new hybrid system architecture and made it necessary to choose a completely new approach for location referencing on the traffic centre side. Keywords System architecture, cooperative systems, V2V and V2I based applications, location referencing, service oriented architecture, SOA, enterprise service bus, ESB Introduction Autonomous driver assistance systems have a positive influence on road safety and management. This effect can be enhanced if vehicles are networked both with each other and elements of the road infrastructure. For this reason, R&D work in the field of intelligent vehicles and intelligent roads focuses on cooperative systems, which enable this networking (so called V2X communications). Cooperative systems can improve the quality and reliability of information about vehicles, their location and their surroundings. For the first time, the R&D project Safe & Intelligent Mobility Test Field Germany (sim TD ) is going to test and evaluate cooperative applications. The sim TD system consists of the subsystems test fleet (ITS Vehicle Stations IVS), roadside stations (ITS Roadside Stations IRS) and the cooperative traffic centre (ITS Central Station ICS). The ICS is implemented in and directly linked to the Traffic Center Hesse (VZH), one of the most effective traffic control centres in Europe, and to the urban traffic management centre of the city of Frankfurt (IGLZ). The ICS gathers all information available from cooperative vehicles as well as traffic data, traffic messages and roadwork information provided by the

2 extensive traffic management systems of VZH and IGLZ. It performs a fusion of the available information sources and provides harmonised real-time information to the vehicles via mobile WLAN (via IRS) and UTMS communication. Figure 1 shows an overview of the sim TD system environment. Figure 1 Overview of the sim TD system environment This paper presents the new approach taken in sim TD to implement a cooperative traffic centre, leading to a new type of architecture for ITS centres. First, the new functional and non-functional requirements of the sim TD project are taken into account, leading to architectural decisions taken in the design process for the ICS. Different alternatives are evaluated and the resulting architecture is motivated. Requirements for the System Architecture Looking at system architectures the non-functional requirements of a system are fundamental. Examples are Performance Adaptability Maintainability Flexibility/Expandability Availability Robustness For the first traffic systems requirements like adaptability, maintainability and flexibility were no big issue. Most of the systems were still comparably small and easy to handle. Availability and robustness of course have always been important requirements for any kind of traffic system. Traffic management operation may be classified into two main philosophies, when looking at the early years of traffic management: 2

3 mainly automatic traffic data processing with automatic decision and measure activation mainly operator driven decision and manual activation of traffic measures For automatic operation a reasonable amount of input data about traffic has to be acquired and processed. Therefore, focus is on processing performance, leading to the following requirements and already suggesting architectural patterns to be used: real-time processing of a large amount of data with reasonable processing power separation of graphical user interface (GUI) and server: client-server-architecture distributed system architecture (load distribution) With focus on manual operation, video was the main source of information in early systems. Here, workflow and operator support is more important: integration and interaction of different subsystems (especially video) supporting operator decisions implementation of the required workflows Modern ITS systems are combining both approaches in order to provide automatic decision support for operators on one hand without giving away the possibility for manual intervention. On the other hand the development in the market is getting faster. Type and amount of data and information to be handled is constantly growing. New and improved methods, techniques and algorithms are available. Without reaction to this development, a system will be outdated very soon. This further development in traffic management and information technology leads to additional requirements for the system architecture: access to the system for a larger number of users (for different departments or even other organisations) o zero-installation clients o external access, e.g. via internet increasing focus on maintainability, adaptability, flexibility and expandability o loosely coupled components o standard interfaces and protocols more complex workflows have to be supported, with interaction of different systems or even traffic centres; workflows should be configurable Last, but not least, cooperative systems are making vehicles intelligent and introduce communication between them and the infrastructure. This requires a more flexible way of handling information. Sensors are no longer restricted to fixed numbers and places, but may appear, disappear, and circulate all over the network. Architecture Decisions General choices The basic principle of a system architecture, i.e. structure and interaction of the different components of a system, may be described via so called architectural patterns. The aim of such patterns is 3

4 to structure the components of a complex system to define methods for distribution of components in network and over resources to structure the interaction between user and system to support maintainability, adaptability and flexibility of the system Examples for such patterns are distribution, client-server, layering, service oriented architecture etc. Different patterns may appear in parallel within big systems in order to support different non-functional requirements. Today, layered architectures are standard. The basic principle of layering is to introduce abstraction by restricting communication to neighbouring layers. Commonly used is the 3- tier-architecture, structuring a system into the three layers presentation, application processing and data management (see Figure 2 3-tier-architecture). Figure 2 3-tier-architecture The layering pattern can be used independent from other architectural patterns. As the focus will now be on communication patterns, the following figures will not show the layers any more. Based on the requirements listed above, different approaches for the system architecture of ITS centres can be found: Data centred architectures (focusing on efficient data processing) Centres based on SCADA systems (Supervisory Control and Data Acquisition) Service oriented architectures (SOA) Data centred architectures are based on a central component responsible for inter-process communication, called data bus or data distributor, which works based on the publishsubscribe-pattern (see Figure 3). Data modelling and interface definition and capabilities are data driven. The user representation, i.e. an object view on information, has to be produced by the GUI, as the GUI is similar to any other module concerning its pure data interfaces. 4

5 Figure 3 Data centred architecture For SCADA systems the type of architecture depends on the SCADA product. Early systems even started as monolithic applications, evolving to distributed/networked system architectures today. SCADA systems are intended to control industrial installations, interfacing to programmable logic controllers / process automation controllers (PLC/PAC, see Figure 4). Figure 4 SCADA system overview In traffic management SCADA systems can mainly be found in tunnel centres. The controlled environment is expected to be static concerning number, type and location of objects. Anyway, processing performance for a large number thousands of sensors often is a major challenge for these products. SOA approaches implement the functionality of a system via different services. The communication pattern is different to data centred architectures; it is called request-response. A service implements a specific functionality, which may be used via a request to it. After completion of the functionality a response is sent, including return data resulting from the request (see Figure 5). 5

6 Figure 5 Request-response communication pattern Compared to data centred architectures, SOA allow a much easier modelling of workflows, but this may result in complex service interactions (see Figure 6). Due to the object oriented approach, performance often is a critical point, too. The SOA pattern is not well suited for processing large amounts of data. Figure 6 Service Oriented Architecture The Enterprise Service Bus (ESB) is a further development of the SOA, eliminating major disadvantages. A central service bus is implemented handling communication between services, GUI and external systems. An important aspect of ESB architectures is manageability. Services only interface to other services via the ESB as a broker (see Figure 7). In addition to this ESB provides a generic message interface and takes care of routing (normalized message router NMR). Anyway, it sticks to the request-response-pattern and therefore performance still is a critical issue for ESB architectures. 6

7 Figure 7 Enterprise Service Bus architecture Decisions induced by sim TD In cooperative systems vehicles function as mobile probes, but also offer information to other vehicles via V2I communication, somehow making them a mobile sign as well. When a vehicle is started it suddenly appears in the system, and it disappears when it is switched off. Therefore, the static, often very complex system configuration of classical ITS centres is no longer sufficient. Compared to standard, dynamic traffic information, vehicle based information is much more dynamic concerning changes in content and location. For V2I communication no fixed location referencing method should be applied. Therefore, vehicles are also supposed to work with coordinates, preferably using so-called traces providing a polygon of the vehicle movement and thereby offering additional information on direction and allowing more precise map matching. In order to comply with these requirements it was decided to reduce the complexity of the configuration and to make it flexible for integration of vehicles. In addition to statically generated configuration layers on top of the basic digital map, a service has been introduced performing on-the-fly mapping. Another architecture decision results from the need for integration of components implemented by different project partners. Here, a single standard framework should be used and compatibility between development frameworks (in-car and centre) had to be guaranteed. For project partners standard interfaces implement functionality as well as data transfer. As a solution, a SOA based on an ESB product has been chosen. Anyway, sim TD induces high performance requirements on data processing due to a large amount of input data, which cannot be handled via ESB architecture. In addition to fixed sensor data, especially mobile data from vehicles has to be processed in real-time, consisting of floating car data and vehicle generated messages (PVD - Probe Vehicle Data, CAN - Cooperative Awareness Message, DEN - Decentralized Environmental Notification). Therefore, a data centred subsystem is used, performing data acquisition, storage, and fusion. 7

8 Architecture for a Cooperative Traffic Centre The hybrid architecture The sim TD ICS incorporates the requirements mentioned before most efficient. An implementation using one of the architecture paradigms (data centred or SOA) exclusively will not lead to the desired requirement coverage. Therefore, a hybrid architecture, taking advantage of both architecture paradigms, has been chosen for the implementation of the sim TD ICS. The basic type of architecture chosen is an ESB-based SOA. The Fuse ESB product used supports OSGi TM (OSGi TM Alliance - former Open Services Gateway initiative) for deployment of components, which is also used for the in-car systems. In order to fulfil performance requirements, a data centred subsystem (based on the GeoDyn2 middleware) has been additionally integrated, performing data acquisition, storage and fusion. Integration has been done via a data bus interface to the ESB (see Figure 8). Providing service interfaces using request-response pattern as well as high performance data distribution interfaces made it possible to choose the communication pattern per component according to its non-functional requirements. Even hybrid components may be implemented, if required. Figure 8 Hybrid architecture incorporating enterprise service bus and data bus Location referencing and system configuration As stated before, the sim TD ICS must handle dynamic, non-static data sources and receivers. Instead of static location referencing, e.g. via RDS/TMC or digital map road elements, an onthe-fly map matching service was implemented, which is based on WSG84 coordinates. This mechanism is applied in both directions, from vehicle to centre and centre to vehicle. In the centre on-the-fly map matching is done as solution for location referencing of vehicle data. Coordinate matching is done in combination with a routing algorithm increasing matching precision by using coordinate traces instead of single point matching (see Figure 9). 8

9 Figure 9 Static vs. dynamic location referencing applying map matching When delivering information to vehicles, the centre indicates the area of relevance via different area types or polygons. This way, the vehicle is able to determine, whether the information is relevant, and if so, when it has to be presented to the driver. As a by-product map matching allows strong simplification of data model and digital map configuration, because map matching may also be used to integrate standard location referencing and thereby reduces the number of fixed configuration layers. In addition to this, the architecture is open for enhancement by improving on-the-fly location referencing by using standardised techniques like AGORA-C (ISO Standard ) or OpenLR TM ( Central ICS services Here is an overview of the most important services and components implemented in the sim TD ICS: Enterprise Service Bus o Fuse ESB, standards-based enterprise service bus based on Apache ServiceMix Data management layer o DataService, offering access to any data in the system (storage and retrieval) and interconnecting service bus and data bus o Data bus, realized by the GeoDyn2 product, including database access, data history o PostgreSQL relational database management Application layer o MapMatching service (see above), providing dynamic and static location referencing methods o TrafficMessageManagement services, implementing message lifecycle management and access to traffic information objects (input and output) o DataFusion component performing fusion of fixed sensor based and vehicle based traffic data and information Presentation layer o Browser-based GUI o GUI services, like WebMapService (digital map representation), ShapeFileService (dynamic generation of shape files for online traffic information), ObjectInfoService (providing object-oriented access to capabilities and attributes). 9

10 Summary The sim TD field trial appears to be the first trial evaluating the complete system environment and architecture needed to implement cooperative applications, including the cooperative traffic center which had to be newly designed and implemented. Size and scope of the project raise a wide range of non-functional requirements for the central system. During the systen design phase these requirements had to be analyzed carefully and a suitable system architecture had to be chosen. Standard approaches, which can be found looking at existing traffic centers, were not able to fulfil requirements in a sufficient way. Therfore a new, hybrid approach has been chosen based on ESB-SOA together with a high-performance subsystem using a data centered architecture. The system has already been implemented and integrated in the overall sim TD system. During implementation, system test, and preparation for field trial the approach has proved to incorporate the wide-spread requirements most efficient. Perspectives In sim TD V2I communication is supposed to be done using WLAN technology. Mobile radio communication (today via UMTS) is used to bridge the gap in case roadside infrastructure is not available. Future implementations will be based on a hybrid approach, depending on the type of application to be supported. For example, immediate hazard warning from infrastructure to vehicle may be done via WLAN for danger spots. Applications without strict realtime requirements but requiring area-wide coverage, like routing advices via navigation, will be based on mobile radio. LTE (Long-Term-Evolution) will be the next step here, together with load balancing via virtual subcenters. For traffic management, the future surely will be in cooperative systems. Therefore, the project findings concerning system architecture and technologies will have to be applied for productive use in the operational Traffic Center Hessen in order to be prepared for the future of mobility. Acknowledgement(S) Project sim TD is a collaboration between German car makers, automotive suppliers, communications companies, research institutes and the public sector. The project is sponsored and supported by Germany s Federal Ministries of Economics and Technology (BMWi), Education and Research (BMBF), and Transport, Building and Urban Development (BMVBS), as well as the Federal State of Hessen. References 1. Dunkel, J. (2008). Systemarchitekturen für verteilte Anwendungen, Hanser, München 2. Bell, M. (2008). Service-Oriented Modeling: Service Analysis, Design, and Architecture, Wiley, Hoboken, NJ, USA. 3. Demolsky, M. (2008). Enterprise Service Bus Die Konzepte, article on jaxenter, artikel/enterprise-service-bus-1662.html 4. sim TD : shaping the future of road safety and mobility via car-to-x communication, sim TD Consortium, 5. OSGi TM - The Dynamic Module System for Java, OSGi TM Alliance, 6. GeoDyn2 middelware, Heusch/Boesefeldt GmbH, 10