X-in-the-Loop Simulation for Digital Twins of Traffic Signal Controllers (1)
Performance-Oriented Design and Implementation with TransModeler
“天下武功無堅不摧,唯快不破。” 古龍【小李飛刀】
"In the end, the race is against time." - Anna Quindlen
Traffic Signal Controllers Evolution and Standards
Traffic signal controllers are essential for managing urban traffic flow at intersections. They regulate traffic lights, allocate right-of-way, reduce congestion, and improve safety.
Historical Development
Traffic signal controllers have evolved through two primary lineages: NEMA controllers and 2070 controllers.
NEMA Controllers
NEMA controllers conform to the NEMA-TS1/TS2 standards established by the National Electrical Manufacturers Association (NEMA). These standards focus on signal control functionality (such as pretimed and actuated operations), and hardware specifications but do not prescribe a specific software environment.
2070 Controllers
Developed primarily by the California Department of Transportation (Caltrans), 2070 controllers adhere to the TEES 2070 standard which defines a unified hardware specification and software environment, including minimum requirements for the Linux kernel 2.6.35 (for 2070-1C CPU) or OS-9 kernel 4.02 (for 2070-1M/B CPU). However, TEES 2070 standard does not provide specific guidance on signal control functionality, relying instead on the functionalities defined by the NEMA standards.
Both NEMA and 2070 controllers use the SDLC (Synchronous Data Link Control) standard for intra-cabinet serial communication, operating at a speed of 153.6 Kbps.
Modern Standards
Contemporary traffic signal controllers have seen further standardization. The Advance Transportation Controller (ATC) Standard and NTCIP 1202 have emerged as the key standards.
Advanced Transportation Controller (ATC) Standard
Developed collaboratively by the Institute of Transportation Engineers (ITE), the American Association of State Highway and Transportation Officials (AASHTO), and NEMA, the ATC standard integrates elements from both the NEMA and 2070 standards.
The ATC Standard provides flexible hardware and software interoperability, ensuring compatibility among various vendors, while allowing for more versatile and adaptable traffic control systems.
Notably, the ATC Standard enhances intra-cabinet SDLC/HDLC serial communication speed from 153.6 Kbps to 614.4 Kbps, facilitating faster data transfer and improved system performance.
NTCIP 1202
The National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) 1202, once known as NEMA TS-3, specifies the communication protocol (based on SNMP) for the network-wide remote management and monitoring of traffic signal controllers. While still relying on NEMA TS2 for the specifications on signal control functions, this standard provides a centralized communications approach to traffic control and management, enabling traffic management centers to remotely manage and monitor signal controllers efficiently.
The following Table 1: Summary of NEMA, 2070 and ATC Controllers and Communications, highlights that signal control functions are primarily defined in the NEMA TS Standard, and notes the significant upgrade in SDLC speed from 153.6Kbps to 614.4Kbps.
“X-in-the-Loop” Simulation (XILS)
Something to Know about Microscopic Simulation, in General
Microscopic traffic simulation is a detailed modeling approach that replicates the behavior and interactions of individual vehicles within a traffic system, considering factors such as vehicle dynamics, driver behavior, and road conditions.
Microsimulation is time-discrete and space-continuous, with time often discretized into small intervals known as simulation step, typically as short as 0.1 seconds.
Due to its high temporal and behavioral resolution, microsimulation allows for the effective simulation of traffic signal control and the evaluation of various control strategies.
The Need for XILS
A microscopic traffic simulator can provide its own traffic signal controller logic, but it is often desirable to interface the simulator with external signal controller hardware or software for greater realism.
When interfacing the simulator with external signal controller hardware, it is called "hardware-in-the-loop" (HILS). When interfacing with external controller software, it is known as "software-in-the-loop" (SILS). Together, these approaches are referred to as "X-in-the-loop" simulation (XILS).
The XILS approach ensures the most realistic traffic signal controller logic, as the external controllers, whether hardware or software, are typically provided by vendors of real-life traffic signal systems, matching exactly the same controller operations as in the field.
In XILS, the microscopic simulator serves as the virtual traffic environment, offering detailed roadway geometries, intersections, individual vehicle movements, and traffic sensor events. The external controller hardware or software receives inputs from the simulator, such as detector sensor activations, and returns the appropriate traffic signal states to be applied in the simulation model.
Architectural Models for TransModeler XILS
TransModeler implements two architectural models for XILS, focusing on how the clock time is synchronized between the simulator and the external controller (hardware or software) process.
Active Clock Synchronization
Figure 1 illustrates the XILS architectural model of Active Clock Synchronization (PCS). In this model, the simulator runs faster than real-time, with its clock actively synchronized to the external controller process (hardware or software). This means the external controller’s clock is driven by the simulator’s simulation step. For instance, if the simulator runs 100 times faster than real-time, the controller process will also operate 100 times faster than real-time.
Active Clock Synchronization ensures high synchronization accuracy. It also allows for accelerated testing and simulation, especially for the cases where large amount of simulation replications are necessary (such as those for training AI). On the other hand, Active Clock Synchronization requires more complex implementation and API design for the active synchronization mechanisms.
Passive Clock Synchronization
Figure 2 depicts the XILS architectural model of Passive Clock Synchronization (PCS), where both the simulator and the external controller process (hardware, or software) run independently, using real time clock as the common time source. Each synchronizes to the real time clock individually, meaning both the simulator and the external controller process synchronize to the common real time clock source, thus indirectly syncing with each other.
Passive Clock Synchronization is straightforward to implement but may result in less precise time synchronization between the simulator and the external controller process. Apparently, it is limited by the real-time clock, which can hinder accelerated simulation testing.
Performance Implications with Different Communication Protocols
Table 2 provides a summary of different protocols used in various simulation environments, including Hardware-in-the-Loop Simulation (HILS), Software-in-the-Loop Simulation (SILS), and other related scenarios. It focuses on three main protocols: NTCIP, SDLC, and proprietary protocols, evaluating their support for different simulation types, clock synchronization models, simulation speedup capabilities, packet overhead, pros, and cons.
In terms of performance, particularly simulation speed, NTCIP and SDLC-based HILS or SILS are limited by their constraint of operating at real-time speeds (1x). This limitation proves insufficient in scenarios where simulation speed and performance are critical. For example, in applications such as AI training, where extensive and rapid simulation replications are required, or in real-time simulation-based predictive analytics—such as forecasting network-wide traffic conditions for the next 15 minutes and implementing sophisticated signal control strategies—NTCIP and SDLC protocols fall short. In these contexts, the ability to generate and process simulation results efficiently and swiftly is crucial. As such, these protocols are not well-suited for applications demanding high simulation throughput and rapid result generation, which are essential for effective AI training and advanced predictive analytics typical of smart city applications.