A DISTRIBUTED SYSTEMS ARCHITECTURE INTEGRATING MULTIPLE TRAFFIC MANAGEMENT CENTRES IN SWEDEN

Transcription

1 A DISTRIBUTED SYSTEMS ARCHITECTURE INTEGRATING MULTIPLE TRAFFIC MANAGEMENT CENTRES IN SWEDEN Andrew Green Principal Consultant, Nicander Limited 5 Chapell Lane, Wynyard Park Business Village, Wynyard, Tees Valley, TS22 5FG, UK , andrew.green@nicander.co.uk ABSTRACT Managing road traffic so as to optimise throughput, minimise delays and maintain safety is a challenging task in the real world, where incidents, events, roadworks and equipment failures all conspire against these goals. Information and Communications Technology has long been employed to assist in many aspects of maintaining a safe and efficient network. Often such systems have been developed in an ad hoc manner, and operators at a traffic management control room will use a number of disparate systems and a great deal of their own knowledge and experience to identify and manage incidents and network flow. This paper considers what a good traffic management system should be. It then describes a framework architecture for such a system, based on the principle of a common user interface integrating a number of cooperating distributed systems a framework used for the National Traffic Management System in Sweden. KEYWORDS Traffic Management, ITS Architecture, Information and Communications Technology BACKGROUND The author is an ICT professional with over twenty years experience in the design and development of traffic related systems mostly as a practitioner but also as a university lecturer in software engineering and real-time systems. He has a long standing involvement with Trafik Stockholm s traffic management system from its initial design in the late 1990s. It is a well reputed, integrated traffic management and decision support system operated 24/7 from the Traffic Management Centre in Stockholm. It facilitates safe and efficient use of the road transport network in Stockholm and the surrounding counties - a mature and developing system with a modular and flexible architecture designed to provide seamless integration of many connected subsystems and functions. Currently it integrates more than 30 subsystems including tunnel monitoring and control (SCADA/PLC), matrix signals, VMS, video wall, road assistance vehicles, CCTV, urban traffic control, congestion charging, traffic modeling and it makes use of - 1 -

2 telephony, SMS, fax and to communicate with cooperating parties. It is now being deployed throughout Sweden as a key component of the National Traffic Management System (NTS). Drawing on his experience of NTS and many other systems, the author presents his views on the important features of an architecture for an integrated traffic management system. TRAFFIC MANAGEMENT SYSTEM REQUIREMENTS The following represent key requirements of the NTS system, and I believe they should be core requirements for any modern traffic management system: It should behave and appear to its users as a single integrated system It should contain expert knowledge and information to give the operator effective decision support It should empower the operator to be able to use the best analytic, monitoring and control tools available including commanding signs and signals It should be able to display all relevant information on the current network status so it is easy to take in, without unnecessary noise and clutter It should alert the operator of incidents and disturbances and should remind him/her when actions are needed It should assist the cooperation between all the parties involved in traffic management, including control office personnel, external authorities and emergency services It should be reliable, configurable and fault tolerant It should be flexible and able to grow and incorporate new functions, systems and devices CENTRALISED AND DISTRIBUTED SYSTEMS Implementing comprehensive traffic management functions as a single monolithic system is rarely practical, even if it were advisable. In the real world any such system will, in all likelihood, need to cater for existing equipment, infrastructure and legacy systems; there is simply no reason, even if there was a budget, to scrap everything and start again

3 Figure 1: Legacy Traffic Management- Multiple Systems One approach is to develop a new instation system, while retaining roadside devices and outstations. This is certainly an approach which can work well, particularly where there is some standardisation of the roadside devices and outstations and if devices use standard communications protocols. It works less well, where there is a large number and diversity of devices and protocols, where the system covers a large area, where it must support many operators, or where a rich set of functions is required. Even if requirements begin quite limited a successful system is one that adapts and grows. It is sure to hit scalability issues at a later date. Figure 2: Single Instation Solution - 3 -

4 The approach adopted with NTS is that of a modular set of cooperating systems each with its own particular functions and business logic. An integrating system then provides the functions to connect all these systems together, to provide a generalised way to view and manage all the subsystems and abstract away the detail. At its core it maintains a rich but generalised road network model, updated in real-time with status data and a knowledge base and expert system. The latter provides decision support and the means to safely and efficiently execute complex action plans in response to incidents and the network conditions. Equally importantly it provides the single user interface, which displays all relevant information in real-time in a clear and visual manner using a modern GIS (Carmenta) maps, schematics and dialogs. It alerts operators to critical incidents or actions which are now due. Since it holds a generalised view of the road network, and since it employs a real-time expert system (based on Gensym s G2) its business logic (scenarios and action plans) is not hard-coded but entered and maintained in the system by expert planners. Similarly much of its knowledge of the capability of subsystems is defined in data and in interface specifications, so that new subsystems can often be added with little or no change to the core software. Figure 3: Integrating Multiple Systems NTS actually takes this architecture a step further: it deploys four separate instations, each of which is capable of cooperating and sharing data with its peers. In theory any one could handle the whole network, though in practice each takes charge of a region of Sweden, as each region has its own control centre (TLC), local subsystems and operational requirements. Nevertheless the system allows (subject to appropriate security constraints) any NTS user to log onto any region s instation, regardless of the physical location of his/her workstation. Users can view incidents and roadworks for all regions, not just their own

5 Figure 4: NTS Cooperating Distributed Systems In the following sections we discuss some of the key elements and principles of the NTS architecture, including: Communication infrastructure and protocols Hardware and virtualisation Subsystem integration Distributed systems and redundancy Databases and the road network model Data synchronisation Decision support and expert systems GIS and visual displays NTS COMMUNICATIONS ARCHITECTURE The NTS integrates systems at four control offices and numerous other sites and provides comprehensive traffic management for the whole of Sweden. It was designed to operate as four systems, each deployed on a separate Local Area Network (LAN), and capable of operating in isolation from the other control offices. They are then connected together via a high-speed Wide - 5 -

6 Area Network (WAN) to allow interoperability and the exchange of data, including CCTV video and voice. The following diagram illustrates this design: Figure 5: NTS Basic Communications Architecture While this does not reflect the actual deployment, it illustrates the basic design principles for the hardware and network. LAN and WAN use Ethernet. This diagram does not show the numerous systems and countless devices deployed at the roadside or at the local tunnel equipment rooms. The main points to draw from this diagram are: Traffic Management for Sweden is provided via NTS Each Control Office (TLC) has its own servers and subsystems NTS integrates 4 separate TLC systems on a WAN Each TLC integrates several subsystems with a core supervisory system Each TLC is capable of operating independently Operational and configuration data is synchronised between the different TLCs Users workstations can connect to any TLC s system - 6 -

7 VIRTUALISATION NTS is logically a set of cooperating systems, each of which in turn integrates a number of specialist subsystems. From the hardware and deployment viewpoint the most significant development in NTS is the movement to virtualised servers - i.e. replacing individual hardware machines with virtual machines, implemented in software. Even for one TLC several servers are required to support a number of separate systems each performing different functions, namely: Live - operational traffic management Training Testing - e.g. new data and Action Plans Development and Configuration Each of these systems generally operates independently, although means are provided to transfer data and configurations between them. Each requires a number of servers, such as: System Application Server System Database Server Other Databases & File Servers Subsystems (or Subsystem Simulators) Network, Directory and Communications Servers For the Operational system in Stockholm this amounts to more than 35 servers (including subsystems). Since each TLC requires several systems and there are four TLCs, NTS employs many servers. In order to manage the number of servers and associated costs, NTS was seen as an ideal opportunity to move to a virtualised solution for the instation servers. This means that instead of more than a hundred host machines all the servers can be deployed as virtualised hosts on a much smaller number of physical platforms which are more than capable of meeting performance requirements as well as providing improved redundancy and failover solutions. Moreover, given a high performance WAN, the physical location of the servers becomes less significant and in practice most of the physical hosts could be deployed at one location, with a second site for disaster recovery. For this reason only the operator workstations and some local subsystems are actually deployed at the separate TLCs

8 Figure 6: NTS Virtualisation User Login This architecture fits in well with the operator s view of NTS. At login he/she is presented with the following dialog: This presents the available options of: Figure 7: NTS User Login Dialog Traffic Centre (TLC) - i.e. East, West, North or South System e.g. Live, Test, Training or Development Role e.g. Traffic Management, Fault Management, System Administration System and Role options vary, depending on the TLC, and the operator s access rights

9 Availability The NTS, like most modern Traffic Management Systems, is required to operate 24/7 with very limited down time. Several levels of redundancy ensure this is a realistic objective, i.e.: Multiple Control Centres each handling one region, but showing national information Multiple Server Sites - providing disaster recovery Multiple Systems separating operational and test/training use Virtualised Server Platforms virtual servers and subsystems will failover to an alternative platform, in the event of a hardware failure Redundant Data Storage use of RAID disks, employing striping/mirroring Spare Workstations extra operator workstations at various locations Software a range of software, bespoke and third party is used to manage and monitor the availability of system, communications and directories SUBSYSTEM INTEGRATION At each NTS Traffic Centre the core system integrates a number of different subsystems. Also known as cooperating systems each subsystem provides a specialised function or a range of functions for a specific location. Examples of the former include: CCTV Telephony Matrix Signal Control Variable Message Signs UTC Signals Congestion Charging Traffic Monitoring Weather Stations Road User Information Road Assistance Vehicles Examples of the latter are typically systems for the monitoring and control of a specific tunnel or bridge, for example Stockholm s Södra Länken Göteborg s Tingstad Tunnel Tunnel management systems, such as that for Södra Länken (Southern Link) manage a range of different devices including: - 9 -

10 Power Supplies Lighting Ventilation Water Pumps Fire Detectors Environmental Sensors Access Doors Emergency Telephones Loudspeakers Barriers Dynamic Message Signs Each subsystem is a sophisticated system in its own right and it handles direct communications with roadside devices and provides much of the function specific business logic. The subsystem exchanges information and receives commands and instructions from the core system at a higher, more abstracted level. Information about the status of devices regardless of which subsystem controls them are shown on common map and schematic displays at operators workstations. Control is via Action Plans, which may integrate commands to several different subsystems. The following diagram illustrates an example configuration for a single centre: Figure 8: NTS Subsystem Integration

11 The diagram shows the main levels for a single TLC system (e.g. Stockholm Live): Client Workstations Core (Integrating) System Subsystems/Cooperating Systems Roadside Devices In Stockholm, there are more than 30 subsystems and thousands of roadside devices. The interfaces to the subsystems use protocols based upon established standards. Some subsystems (e.g. many of the tunnel control systems) share a common interface specification. This makes it relatively simple to add new subsystems. How information about devices is displayed and how they are controlled are also standardised within NTS - the operator rarely needs to know how control is actually achieved at the lowest levels. Operational Data Synchronisation NTS is a set of cooperating systems. Each is capable of operating independently, but treats the other control centre s systems like other subsystems (i.e. as a source and sync for data). A TLC displays the events and incidents from other TLCS as external events. In practice the TLCs do not communicate directly with each other, but rather report all new and updated events to a central synchronisation server, which forwards that information to the other TLCs. Figure 9: NTS Live (Primary) Synchronisation Server GIS & VISUAL DISPLAYS NTS workstations provide a common user interface integrating the display of information and control of devices, regardless of the actual systems which provide the communications and low level control. Key components of the displays are:

12 Microsoft style dialogs GIS displays with both schematic and geographic style maps Other Graphical displays Video/CCTV Map Displays (Geokarta) Regardless of the actual traffic centre and region being controlled, map displays (based on the Carmenta GIS engine) cover the whole of Sweden: Figure 10: NTS Map Display Sweden In practice maps will be zoomed into areas of interest within the region being controlled. (The user can zoom down as far as street level if required). Figure 11: NTS Map Display Stockholm Centre

13 Locations with complex road layouts and high density of equipment (such as Södra Länken) are also modeled in a schematic form where all devices (and their status) can be seen: Figure 12: NTS Schematic Display - Detail NTS systems collect a very large amount of current information. Dynamic and static information is overlaid on the map in a hierarchy of layers, so an operator can elect to filter out information not directly of interest or of lesser importance. Information displayed on the maps includes: Background Geography Road Network Traffic Flows Road Condition Control & Monitoring Equipment Incidents & Roadworks Road Assistance & Maintenance Vehicles Ferries Diversion Routes Most objects on the map are selectable and have an associated property sheet or dialog where both static and operational information can be reviewed. Icons and colour are used to provide summary status. STATIC DATA & ROAD NETWORK MODEL Key to the successful integration of the display of information from so many different systems and in providing a consistent means for handling incidents and events is NTS s own road

14 network model. The NTS model is based on the GDF standard and is partly derived from Trafikverket s NVDB data, which it effectively supplements. It differs from networks designed for in-car navigation in that it has a number of hierarchical levels: National Route New Optional level for National Roads only Route(s) County Roads & County Stretches of National Routes Sub-Route(s) (slip roads) Aggregated Section Aggregated Section(s) Optional levels - parts of a Route defined as a set of Links Link(s) Bidirectional stretches of a Route between major junctions Aggregated Segment Aggregated Segment(s) Optional levels: unidirectional parts of a Link defined as a set of Segments Segment(s) Optional level: unidirectional part of a Link (e.g. Between two MCS gantries) Figure 13: Road Section Hierarchy The most detailed levels - Segments (e.g. sections of carriageway between signal gantries) are only modeled where lane level control is required and available. All static devices and externally defined road sections are mapped to the NTS road network, and whenever a traffic related event or alarm is reported to NTS its location is translated internally into the NTS format. This may be a single point or a precise extent along the road network: Figure14: Unconfirmed Traffic Event with a Location Extent

15 When communicating events and location related information to cooperating systems, NTS automatically translates the location into the format expected by the remote system (whether that is NVDB, RDS/TMC or a device address). Static Data Dependencies The Road network model is core to the static data maintained by NTS and is generally common to all TLC systems. Other static data builds upon and depends on the road model: Figure15: NTS Static Data Dependencies Static data is maintained in a centralised configuration database, and copies made for each TLC in Oracle databases, which also manage operational and historic data. EXPERT SYSTEM & DECISION SUPPORT NTS main function is to provide information about the state of the road traffic network and to offer decision support and the means to manage incidents and disturbances to the traffic flow. In the NTS, much of the business logic for handling traffic events (known as reports or situations) is embodied in a Real-Time Expert System, implemented using Gensym s G2. An expert system, is a computer application which combines rules and data to represent expert knowledge. It uses this knowledge to provide advice and decision support to a human operator. The benefit of an expert system over traditional programming languages, is that the logic which determines the proposed response to an event is not embedded in computer code, where it needs a programmer to change, but in data and rules, which can be entered and updated directly in the system (or in a test system) by traffic management experts. In NTS the expert system

16 understands the road network model and the capabilities of the roadside devices and subsystems. Traffic experts define how the system should respond to events by defining: Scenarios a set of conditions which if they occur may require a specific response Action Plans a predefined plan of action, defined as an executable flowchart When an incident is entered into the system and confirmed, the Expert System compares the location and conditions to the predefined scenarios and presents a prioritised list of Action Plans which might be used to handle the event. The operator decides which, if any, of the plans to execute. The plan will then automatically perform the actions required, prompting the operator when and if required. The system comes into its own, when rarely occurring events, such as a tunnel fire, require widespread and complex responses involving hundreds of devices and many third parties. The following shows a typical action plan (diagram), selected for a report, prior to execution: Figure 16: Action Plan (ATR001+VX) This plan contains a number of different types of step and executes three strands in parallel: 1. Communicates the situation with maintenance contractors and road assistance vehicles. 2. Runs a sub-plan which notifies other parties. 3. Implements a lane closure (via MCS) and notifies the TRISS subsystem. In this case the defined action plan, is location independent, but when executed for a specific incident at a specific location the system automatically determines the appropriate parties to contact and the required MCS signal gantries to control

17 SUMMARY To summarise, the author believes the following architectural features provide a framework which is very flexible and can meet current and future traffic management needs: Multiple Systems a complex system should be built from separate specialised components Distribution systems, databases and devices should all be deployed at the most appropriate locations for performance and maintainability Integration systems can be integrated into a single system via common communications standards, by a common user interface and by a common abstracted model, handled by an integrating system Virtualisation virtualising hardware has significant benefits both for cost, ease of maintenance and reliability Redundancy multiple levels of redundancy ensure high availability Graphical Displays the user display should be clear and intuitive and make use of modern GIS software such as the Carmenta map engine Expert Systems the use of an expert system (such as Gensym s G2) allows much more flexibility in defining the core business logic for Traffic Management Decision support and provides a powerful supervisor for managing subsystems and roadside devices Road Network Model the core of any ITS system is its underlying network model, which should provide the right abstracted level, or as NTS does variable levels, easily mapped to other models Databases underlying any successful modern system are the databases which maintain all configuration, static and historical data and which may also be a source for the current network state - NTS uses several Oracle databases Simplicity no sophisticated ITS system will actually be simple, but it should appear so to its users! CONCLUSIONS An architecture which employs best practice for ICT systems, including modularisation and distribution, virtualisation, knowledge-based business logic and uses the right tools (e.g. GIS and databases) is an excellent basis for a successful ITS system, such as Sweden s National Traffic Management System (NTS)