TCSS System Architecture Objectives of Route 8 TCSS

Transcription

1

2 TCSS System Architecture Objectives of Route 8 TCSS 1. Monitor the highway and tunnel sections to determine actual traffic flow conditions. 2. Reduce delays and accident risks due to non-recurrent congestion through rapid detection and appropriate management of incidents. 3. Improve safety for motorists using the road network by providing timely and accurate motorway and tunnel information. 4. Support the rapid and efficient implementation of traffic control strategies pertaining to the following traffic management operations: e.g. Normal traffic flow operation, Lane closure and re-opening, Tube closure and reopening, Contra-flow operation, Ramp closure and re-opening. 5. Generate weather management responses to bad weather advisories received from WASHMS, visibility sensors and other sources. 6. Detect over-height vehicles for tunnels. 7. Interface with external systems such as Tsing Ma Control centre (TMCA), Transportation Information System (TIS), etc. 2

3 TCSS System Architecture Route 8 Major Sub-systems Closed Circuit Television Surveillance System (CCTV) Detection System: Vehicle detection system (VDS) Over-height vehicle detection system (OHVD) Visibility sensor Traffic Control Devices: Lane control signals (LCS) Variable speed limit signs (VSLS) Prismatic variable message signs (PVMS) Turn on radio signs (TOR) Traffic signals (TS) Manual barriers (BAR) 3

4 TCSS System Architecture Route 8 Major Sub-systems (cont.) Voice Communications Systems Tunnel emergency telephone system Emergency private Branch exchange system O & M Radio system Tunnel radio re-broadcast system Building public address system Private Branch Exchange system Speed enforcement camera system Central computer system with manual fall back panels Main communications network Other control centre equipment Other equipment, e.g. power supply 4

5 TCSS System Architecture Traffic Control Devices 5

6 TCSS System Architecture Traffic Control Devices 6

7 TCSS System Architecture Detection Systems AID Vehicle Detection Over-height Vehicle Detection 7

8 TCSS System Architecture System Design Features 1. Central System Hardware (characteristics): (a) (b) (c) (d) (e) Distributed Processing (Scalability) Allocates software processing to different computer nodes in a multi-level hierarchy. System consists of central servers, operator workstations, communication processors, and data archive server. Redundant Server Design (Stability) Design includes both hot standby servers and cold standby servers. PC based computer technology Based on most commonly used PC server and workstation technology that are widely support in the market. Allows for easy future upgrade of the hardware. Dedicated Purpose Servers With large secondary storage in the dedicated DAS, generation of large reports or database enquiry will not occupy the processing power of the central servers. Common PC LAN/WAN architecture The complex net architecture between the central servers and the field equipment/remote processing nodes is transparent by treating them as IP-based connections. 8

9 TCSS System Architecture System Design Features 2. Central System Software The specific architecture of the software is based on Delcan s TCSS software modules with the following characteristics: (a) (b) (c) (d) (e) Event Driven Design Practically all processing within the TCSS system is driven from events that may be generated from physical conditions either as a result of equipment status changes or user control requests. Use of real-time database (RTDB) and message queue for real time inter-process communications. Provides inter-process communications and real-time data storage. Use of ODBC compliance Relational Database (RDB) for historical data storage and external interface. Stores various types of data such as real-time data, summary traffic data, incident data, environmental data, system event data, alarm actions, etc. Use of Windows based technology for operator interface. Reduces the learning curve for operators new to the system by using widely used OS. Modular software design Provides a clear set of interfaces to the external world. 9

10 !"##

11 Special Design System Redundancy Central TCSS System Schematic Diagram Open road only 11 (Refer to drawing DIG/6711-TH/EM/A181)

12 Special Design System Redundancy Redundancy SDH System 10 x Remote Nodes Serial Hub Switch FE FE SDH SDH SDH SDH FE FE Switch LAN 10/100Mbps LAN 10/100Mbps 2 x Core Nodes 12

13 Special Design System Redundancy Redundancy SDH Ring S S S S S S (Node 1) West Portal Kiosk of NW Tunnel (Node 12) RC Full Enclosure Kiosk S2 (Node 11) Shatin Heights Tunnel North Portal Building (Node 10) Shatin Heights Tunnel South Portal Building (Node 9) Administration Building (Node 8) Eagle s Nest Tunnel North Portal Building S S S S S S (Node 2) Comm. Room of West Control Building of NW Tunnel (Node 3) East Portal Building of NW Tunnel (Node 4) Chainage 5350 of Ngong Shuen Chau Viaduct Westbound (Node 5) Chainage 6950 of Ngong Shuen Chau Viaduct Westbound (Node 6) Chainage 7140 of Ngong Shuen Chau Viaduct Westbound (Node 7) Eagle s Nest Tunnel South Portal Buiding 13

14 Special Design System Redundancy Redundancy Distributed Computer Groups 1. Central Servers (CSS) hot standby configuration, providing core system functions; Provide the centralized interface between field equipment and central control room; Centralizes functions that require coordination among multiple traffic controllers. 2. Operator Workstations (WS): Provides graphical user interface with pan/til/zoom functions to the TCSS; Redundancy is provided by multiple workstations across different regions. 3. Communication Processors (CP): Support interfaces with field equipment; Off-load the Central Servers by polling information from the field equipment regularly; configured in hot-standby pairs. 4. Data Archive Server (DAS): Installed with PostgreSQL for Relational Database management (RDBMS); Provides history database support, system configuration, etc; Off-loads the Central Server for handling of relational database functions. 14

15 Special Design System Redundancy Redundancy Data Control Centers Parallel set of warm standby components consisting of a Central Server (CSS) and communications processors (CP s) which are used upon total failure of the main CSS and CP s. 15

16 Special Design System Redundancy Redundancy Data Control Centers (cont d) TCSS Central System Data Flow Diagram 16

17 Special Design System Redundancy Redundancy Central System vs. MFCS Manual Fallback Control System Overview: is not intended to be a fully featured replacement for the Central TCSS; is designed to reliably provide basic control and monitoring of field equipment in the event of full or partial loss of the Central System; will be able to function either with or without an operational Central System; is used to control and monitor specific tunnel, tunnel portal and tunnel approach road traffic devices. MFCS Communications: The MFCS uses a completely independent set of communication paths (network and serial) between the Control Panels and the field controllers; Communication processors are provided close to field equipment in NWT, ENT and SHT/RCFE; Each communication processor is connected to its respective MFCPs and communicates to the field equipment via dedicated serial communications. 17

18 Special Design System Redundancy Redundancy MFCS Architecture (Cont d) 18

19 Special Design System Redundancy Redundancy MFCS Architecture (Cont d) Dual LANs if inside Tunnel TCSS MFCS System Architecture 19

20 Special Design System Redundancy Redundancy MFCS Architecture (Cont d) MFCS Overview Dual LANs if inside Tunnel (Refer to drawings DIG/6711-TH/EM/A180 & A182) 20

21 Special Design System Redundancy Redundancy MFCS Architecture (Cont d) MFCS Data Flow Diagram Dual LANs if inside Tunnel (Refer to drawings DIG/6711- TH/EM/A180 & A182) 21

22 Special Design System Redundancy Redundancy Multi-port Controller Architecture Field Controllers Connections to Central and MFCS-CP Central Equipment Fibre Optic Rings SDH Node Dual LANs if inside Tunnel Serial Hub Central to Field Equipment RS485 Multidrop Arrangement Fibre Optic to RS485 Media Converters Field Controller Field Controller Field Controller MFCS to Field Equipment RS485 Arrangement MFCS Equipment MFCS Comm. Processor A MFCS Comm. Processor B 22

23 Other System Design Features - Software

24 Other System Design Features Software Automatic Incident Detection (AID) Main Functions of Automatic Incident Detection: FUNCTION Detection Configuration Simulation Mode DESCRIPTION Uses APID, McMaster, QEWA, and VIP alert to detect incidents or queues on the roadway sections. Sets parameter sets and schedules. Re-runs the traffic cycle data with different configuration. 24

25 Other System Design Features Software Automatic Incident Detection (cont d) Vehicle Detection System, HTD, AID and IMS High Level Data Flow Incident Management System Vehicle Detection System Smoke Alarms Traffic Data Processing (HTD) AID Alarms Automatic Incident Detection (AID) Traffic Cycle Data AID Cycle Data Stopped Vehicle, Wrong Way Vehicle 25

26 Other System Design Features Software Automatic Incident Detection (cont d) Sample Incident Timeline AID Alarm VDS Stopped Vehicle Alarm raised APID Algorithm Incident raised VVD Stopped Vehicle Alarm lowered QEW Algorithm Incident raised 26 APID Algorithm Incident lowered Time (with Traffic Cycle intervals) QEW Algorithm Incident lowered

27 Other System Design Features Software Rule-based Traffic Plans Traffic plans in Route 8 are defined by the combination of responses of various TCSS field subsystems SUBSYSTEM Fully Variable Message Signs Variable Direction Signs Arterial Advisory Signs Variable Airport Signs Variable Speed Limit Signs Lane Control Signal (Matrix Type) Lane Control Signal (3 Aspect) Tunnel Closed Signs Variable Warning Signs (Contraflow) Variable Regulatory Signs Variable Warning Signs (Overheight) Traffic Signals Turn on Radio Signs Radio Break-In Messages 27 ACRONYM FVMS VDS AAS VAS VSLS MAT LCS TCS VWS VRS OHS TS TOR RBI

28 Other System Design Features Software Rule-based Traffic Plans (cont d) Stage 1: Subsystem Selection rules Selecting relevant subsystems Event/Queue Info Stage 2: Sign/signal selection rules Selecting sign(s)/signals FVMS Sign ID LCS ID Other Sign ID Stage 3: Message priority and display rule Determining message priority and message display for each sign Stage 4: Message activation rule Message queuing and priorities in message queue at each sign FVMS Message Type and Priority Selecting sign/signal display based on individual display rule Recommended Traffic Plan Sign/Signal Display FVMS Message LCS Display Other Sign Display 28

29 $#%