Overview and Modeling Capabilities of an Event-Based Signal Controller

Abstract

Developing appropriate signal timing strategies is a primary concern in traffic signal control; however, professionals are constrained by predefined controller options. Existing signal controllers in North America adhere to National Electrical Manufacturers Association (NEMA) standards with ring-barrier control (RBC) design. Due to unique traffic conditions and objectives for each traffic mode, conflicts arise, making it challenging to devise suitable traffic control strategies within current controllers. The limitations include inflexibility in defining pretimed signal diagrams, modifying them, and defining algorithms for modification. This paper introduces the event-based controller (EBC) framework, implemented in DUMKA_E software, capable of replicating NEMA-based RBC functionalities while providing additional flexibility beyond conventional RBC controllers. The EBC eliminates the asymmetry of flexibilities in existing traffic controller frameworks, addressing the challenges mentioned. Overcoming critical limitations of RBC, such as barrier constraints and restricted functionalities to built-in algorithms, the EBC empowers professionals to craft custom traffic signal control strategies. Unlike approaches enhancing RBC with complex computation, the EBC offers flexible functionalities without sacrificing simplicity. The study shows that the EBC’s fundamental concepts are no more intricate than RBC’s, positioning the EBC as a potential traffic controller framework. The paper establishes the EBC’s capability to reproduce RBC controllers’ core logic, showcasing advanced abilities for more efficient control logic than RBC. The EBC’s functionalities enable context-sensitive traffic signal control strategies, catering to special conditions like multi-modal activities and diverse priority requests, highlighting its full potential.

1. Introduction

In recent decades, the importance of traffic signal control systems has steadily increased due to ongoing urbanization and rising traffic congestion. Traffic signal control systems by controlling the flow of traffic at intersections and crosswalks reduce the occurrence and severity of accidents [1], minimize travel time [2], and enhance air quality by curbing emissions from idling vehicles [3,4]. In alignment with the World Health Organization on road safety, implementing robust traffic signal control systems is crucial for promoting safer road conditions [5]. Traffic signal control is the most frequently utilized approach to handle requests, efficiently and safely, for the right-of-way of road users (private vehicles, buses, bikes, pedestrians), both spatially and temporally [6].

Diverse road users, including pedestrians, transit, and emergency vehicles, often come with unique conditions and conflicting priority requests. Meeting these demands requires the incorporation of additional rules and strategies (e.g., traffic signal preemption or priority) within the existing constraints and built-in algorithms of the traffic signal control frameworks. For example, real-time actuation of side street passenger cars may conflict with system-wide signal coordination. Similarly, a request by a pedestrian to cross the street may interfere with well-established coordination enabling the seamless arrival of the platoon of vehicles at the next intersection. A suitable traffic control algorithm should have the capability to, first, control traffic signals with maximum flexibility, and second, offer an efficient method for signal professionals to leverage their expert knowledge in programming such control algorithms. However, it is challenging to achieve these two aspects within the functionalities of the current controllers. The main reason is attributed to the interconnection between traffic signal flexibility and the increasing need to regulate the outcomes of this flexibility (e.g., to prevent critical situations, such as potential conflicts in traffic movements). Consequently, this can lead to an increase in the programming and maintenance efforts of such systems, ultimately resulting in a decline in overall programming efficiency. To mitigate this issue, two categories of traffic signal control frameworks can be identified:

• Signal Stage-Based Traffic Control: This approach relies on the concepts of “signal stages” and “signal interstages” as the minimal units available for manipulation in traffic signal control algorithms [7]. The control algorithm is typically represented as a flowchart that dictates when and which stage (and interstage) should be activated based on various conditions (e.g., detector status, time conditions, etc.). While this method allows signal professionals to control and verify the algorithm results, the inherent restrictions on signal manipulation for different movements can limit flexibility (e.g., the compatibility between all phases in an interval is predetermined and cannot be changed after, even the compatible phases cannot be redefined).
• Signal Group-Based Traffic Control: This approach, based on manufacturer-specific concepts, facilitates more direct manipulation of signals for a group of movements (signal groups) in traffic signal control algorithms. Representative examples include the signal timing interval-based control frameworks (e.g., VS-PLUS), where the signal timing plan is defined by specifying time points and intervals for traffic signal activation by the control algorithm, and the ring-barrier control (RBC) framework (the National Electrical Manufacturers Association (NEMA) standard controllers based on the concept of ring-and-barrier design [8]). This category aims to overcome the limitations associated with signal stages by increasing flexibility in signal manipulation for various movements. However, it is limited mostly to the built-in algorithms.

In North America, signal timing follows the standardized NEMA method for assigning signal phases to traffic movements [3]. Most intersections use the standard eight phases shown in Figure 1. Figure 1b displays an RBC diagram for the intersection shown in Figure 1a, emphasizing the constraint of signal phasing within rings and barriers. Consequently, signal professionals face restricted flexibility in devising and implementing traffic control logic customized for specific traffic conditions and special requests (such as granting special priority to public transit, bicycles, and pedestrians) within the fundamental functionalities of NEMA controllers. Notably, minimal research has been conducted to explore the new capabilities of modern NEMA controllers, including built-in logic and peer-to-peer communications to customize signal operations and enhance traffic signal control flexibility [9,10]. Nevertheless, despite the presence of logic processors, it is challenging to consider it as a comprehensive tool for creating high-level “flow-chart”-like algorithms.

Furthermore, flexibility alone is insufficient for achieving efficiency within such a system. It is crucial to consider the cost associated with this flexibility, specifically evaluating the effort required for a practitioner to program, test, and, if needed, modify the operational algorithm during the ongoing exploitation process. Considering the differences in the geometric layout, complex fluctuating traffic patterns at the intersections, and conflicting priority requests from multimodal users, existing controllers are not always flexible and/or efficient enough to address the challenges at intersections and provide the highest efficiency in multimodal operations and uncommon traffic conditions.

To address shortcomings of the existing frameworks, this paper introduces the innovative signal event-based controller (EBC) framework, categorized as type 2. It serves as a platform for crafting efficient user-defined traffic control algorithms, offering a flexibility level akin to that provided by stage-based control flowcharts. EBC overcomes limitations presented in conventional signal control systems by being customizable to execute various phasing and timing logics, catering to user needs, and overcoming potential constraints.

Table 1. Comparison of signal control frameworks.

Flexibility to:	Stage-Based Traffic Control	Signal Group-Based Traffic Control
		Ring-and-Barrier Control (NEMA)	Interval-Based Control	Event-Based Control
1–Define Pretimed (Cyclic) Signal Diagram
	Highly limited to comply with stage-interstage structure.	* Limited to comply with ring-barrier structure
2–Modify the Pretimed (Cyclic) Signal Diagram While Operating
	Highly limited–Signal groups are constrained by stages and interstages.	* Limited–Phases are needed to comply with the ring-barrier structure.	* Limited to modify only some part of signal intervals (e.g., early start)
3–Define the Algorithm for Modifying the Pretimed (Cyclic) Signal Diagram
	Algorithm presented in the form of flow charts consists of stages and interstages.	Limited to predefined/built-in algorithms only.	Limited to predefined/built-in algorithms only.

summarizes the comparison between stage-based traffic control, interval-based control, ring-and-barrier control, and the proposed event-based control framework. The EBC can be considered as a framework that was created to eliminate the asymmetry of the flexibilities of types 1 and 2 in the existing traffic controller frameworks. The emphasis of the table is on examining the flexibility offered by each framework.

Given that RBC is the most mature and well-known traffic signal control framework in Category 2, it will serve as the reference point for benchmarking the EBC and will underscore the unique characteristics of it. This paper aims to achieve its goal through the following objectives:

• Demonstrate that the basic concepts and principles of the EBC are not significantly more complex than those of RBC, establishing the EBC as a potential traffic controller framework. Additionally, validate the EBC as a traffic controller framework by introducing an EBC virtual controller, DUMKA_E, equipped with programming tools that implement the EBC concept. The functionality of DUMKA_E will be showcased using the PTV microsimulation tool [11].
• Illustrate that the EBC, as a traffic controller framework, can replicate the core logic of the RBC controller (by comparing the traffic outcomes of EBC DUMKA_E with the same operations coded in the NEMA-based control framework called Econolite ASC/3 [12,13]. Both Econolite software-in-the-loop (SIL) signal control simulation and EBC DUMKA_E are implemented in the PTV Vissim microsimulation tool for further analysis).
• Highlight that the EBC’s advanced capabilities can be harnessed to establish a more efficient and flexible control logic that RBC is unable to implement (through an advanced scenario that uses upstream intersection vehicle counts (e.g., via exit detector) to terminate/postpone a phase based on the desired demand).

The paper starts with a literature review of existing traffic signal controllers and their features. It then compares the main architectures of RBC and the EBC, explaining the EBC’s concepts and architecture in the DUMKA_E software framework. The methodology section covers EBC DUMKA_E’s capabilities and experimental design. The results and discussion of them are presented in detail afterward. The last section summarizes the main findings of the paper and future research.

2. Literature Review

Today, a wide range of hardware and software alternatives are available to transportation engineers or control system designers for creating alternative traffic control systems. In North America, signal timing follows the standardized NEMA method for assigning signal phases to traffic movements [3]. While NEMA controllers operate with predetermined signal control parameters, some adjustments can be made during the day/year. They are programmed firstly by providing schedules (e.g., time of day plans in a feature called “pattern”). Within patterns, through some parameters such as vehicle extension timers, duration of green, etc., some changes could be achieved. The same process is carried out in a simulation, where the RBC is often a default emulator for standard signal controller logic (e.g., in Vissim) [14]. Some limitations of the early versions of RBC controllers in Vissim have been recently addressed by providing the ability to modify controller parameters during the run time [15].

A couple of studies employed the ASC/3 logic processor to manage built-in traffic signal priority (TSP) during conflicting requests and to create custom TSP strategies independent of the built-in functionality. The same group of researchers has employed the logic control processor to handle conflicting transit signal priority requests, particularly for bus rapid transit (BRT) or light rail transit (LRT) systems [16,17]. In other studies, real-time predictive priority setting is achieved using overlap intersection phasing through a series of logical commands set within the Siemens NextPhase traffic controllers [18,19].

Researchers have already recognized (and addressed) the fact that conventional signal controllers do not easily provide enough flexibility to address all the necessities of any intersection with different conditions and needs. For example, in the context of bicyclists and pedestrians, Furth et al. investigated a phasing system known as “protected-yet concurrent phasing”, in which right turns have their phase and bike and pedestrian crossings operate in their own separate phases simultaneously with the parallel traffic phase [20]. Based on another paper from the same authors, traditional phasing methods permit conflicts with right-turning traffic either throughout the entire crossing phase or not at all [21]. Therefore, they addressed this gap by comparing two signalization techniques, providing a short, conflict-free interval for crossing pedestrians and bikes. In another recent study, researchers focused on the lack of flexibility for a fully actuated coordination strategy and recognized that the default operations of the coordinated phase are rarely modified in practice [22]. In another study, the authors developed a new signal control approach, allowing pedestrian overlap phases with vehicles using barrier-free ring structures. While the RBC serves as a valuable simplification for typical intersection layouts, it can also be constraining when a movement on one side of a barrier conflicts with some, but not all, of the movements on the other side, creating unnecessary delay to those movements. Evaluations found the use of pedestrian overlaps can significantly reduce pedestrian delays compared to basic traditional signal control [23]. This limitation cannot be addressed within the fundamental structure of RBC unless introducing additional phases and overlap phasing [24]. They proposed a new strategy aiming to combine uncoordinated with coordinated control in low to medium traffic while the coordination cycle is long. Additionally, Gavric et al. introduced two novel pedestrian timing treatments utilizing the EBC concept, which accommodates pedestrian timing within the cycle length optimized for vehicular phases. These pedestrian treatments are relevant for pretimed fixed signal timing plans where only pedestrian calls are actuated [25].

Several other approaches have been proposed to design and implement innovative signal control systems to address the limitations of the commonly available traffic control systems. For the first time, Pappis and Mamdani proposed the application of a fuzzy logic controller (FLC) to control traffic characterized by randomness [26]. The findings of their implementation of an FLC at a single intersection of two one-way streets demonstrated that the system performs better with a fuzzy logic controller over an effective conventional vehicle-actuated controller. Nakatsuyama et al. introduced the phase (offset) controller, employing fuzzy control statements to control adjacent chains of intersections with one-way movements [27]. This controller determines when the green signal for the downstream intersection should be terminated depending on the demand from the upstream intersection. For the first time, Chiu applied fuzzy logic to control multiple intersections in a network of two-way streets without turning movements to adjust the cycle time, phase split, and offset parameters based on the degree of saturation on each intersection approach [28]. More studies have been conducted using a fuzzy logic-based controller, focusing on phase sequence controllers for traffic control systems, controlling the timing of a pedestrian crossing signal, determining whether to extend or terminate the current signal phase, freeway adaptive ramp metering, and controlling the diverging diamond interchange [29,30,31].

This paper intends to introduce a flexible concept of an event-based signal controller. The software framework utilized in this study as a representative of the EBC, known as DUMKA_E (the virtual traffic controller and programming user interface), underscores the importance of logical thinking in traffic signal control development. Unlike the RBC, which requires that a user simply define parameters for a preset logic, the EBC involves more engaged decision making and algorithm development to identify an appropriate traffic signal control strategy. The innovation behind the EBC lies in its ability to provide greater programming flexibility (e.g., flexible start/end of each phase or the phase orders), enabling signal professionals to devise customized signal control strategies suited to specific conditions, especially multimodal users.

3. Architectural Contrasts and EBC Framework

This section begins with a comparison between the conventional RBC and EBC, elucidating the foundational principles of the EBC through an examination of both shared and distinct attributes with the widely recognized RBC. Subsequently, it introduces the novel functionalities inherent in the EBC, providing the sequential steps involved in its implementation.

3.1. Comparison of RBC and EBC Architectures

This section explains the principle architecture of the RBC and EBC to introduce the fundamentals of the EBC for both fixed-time control and actuated control. An exemplary three-leg intersection has been chosen to illustrate the similarities and differences between the RBC and EBC. The scheme of the intersection is shown in Figure 2 below.

In the realm of traffic signal control, both traditional NEMA-based controllers and event-based traffic signal controllers (EBC) share foundational differences and similarities. Figure 3 illustrates the building process of signal diagrams within the RBC and EBC for the intersection depicted in Figure 2.

The RBC signal timing workflow architecture (Figure 3a) can be considered as follows. The following steps are required to construct a fixed-time signal control in RBC:

• All signal groups for associated movements are assigned to phases.
• A ring-barrier structure is defined to propose precedence relations between different movements based on potential conflicts.
• Phase green times are defined (such as minimum green, maximum green, etc.).
• Constant duration intervals (such as yellow change and red clearance) for each phase are defined.
• Master clock settings are defined, in the case of coordinated operations (configuring coordination timing settings such as offsets and splits).

The abovementioned process is depicted in Figure 3a.

After completing the steps, RBC builds the corresponding signal diagram. Figure 3a-ii illustrates essentially the same RBC signal diagram shown in Figure 3a-i but with a focus on signal group-based timings. The signal group-based diagram is presented because it is the best way to illustrate the EBC concept to an unfamiliar reader.

In introducing the EBC signal timing workflow, the architecture of the EBC can be similarly considered (Figure 3b). The development of fixed-time signal control in the EBC entails the following steps, which vary slightly from those in RBC:

• Define a signal event map comprising precedence relations between signal events. Each signal event specifies the activation of a particular traffic signal for the designated signal group (depicted as green circles or red squares in Figure 3b-i).
• Specify signal event reserved times—the time duration after activating a signal event reserved exclusively for that event—preventing the switch to other signals (represented by the purple line in Figure 3b-i).
• Determine constant time intervals, such as yellow-change timings, and intervals within the “intergreen matrix” based on conflicting movements. It should be noted that the constant intervals between the conflicting movements are another flexibility of the EBC over traditional NEMA-based controllers (RBC). For instance, the EBC can alter yellow timings after one phase depending on what phase will start after that.
• Establish coordination timing settings, including the synchronization time point for a signal event (synchronization time point indicates the specific moment in the cycle when the signal events are synchronized to start). In this context, the signal event should be activated precisely at that designated point (similar to offset in RBC with some additional capabilities such as achieving the synchronization point by adjusting the reserved time).

Upon completing these steps, the EBC constructs the corresponding signal diagram, as illustrated in Figure 3b-i.

It is important to observe that both signal diagrams depict identical signal timings and phasing orders. In Figure 3a-i, the blue ribbons symbolize the barriers in the RBC diagram. In Figure 3b-i, the green circles and red squares represent signal events, denoting the initiation and termination points of each signal group, respectively, as determined by the signal professionals’ requests to activate the corresponding signal groups. (Distinct shapes, such as circles and squares, along with variations in form, plain or inscribed, in signal events are associated with additional control settings. Specifically, a circle denotes urgency, implying it should promptly occur to grant the right-of-way in a timely manner, while a square signifies an “inversely” urgent event, suggesting it should be delayed as much as possible. The distinction between plain and inscribed forms is linked to the urgency’s “weight”). The purple lines in Figure 3b-i indicate the reserved times, both minimum and maximum.

The comparison between the two systems focuses on the flexibility provided by the EBC, which has no constraints on the signal events precedence graph, as opposed to NEMA controllers, which have predefined independent rings bounded by a barrier. The EBC is based on the signal events precedence graph, whereas NEMA controllers are based on the right-of-way events precedence graph.

The essence of non-fixed-time control, crucial for semi/fully actuated and adaptive systems, is, however, intricately tied to the development of fixed-time control. The workflow architecture for non-fixed-time control in the RBC signal timing, specifically for actuated control, involves the following steps (illustrated in Figure 4).

• Develop the foundational fixed-time control, as mentioned earlier.
• Activate and fine-tune the built-in algorithm capable of adjusting basic operational timings through common “changing actions”, including
  • Modifying green interval durations (e.g., shortening/lengthening).
  • Omitting phases.

The process of adjusting the signal diagram in the RBC based on the detectors’ information is constrained by the fact that

• Predefined algorithms are integrated into the system.
• Changing actions are not directly accessible to a signal professional.

In contrast, the EBC, with advanced functionalities over RBC, can overcome these limitations and offer flexibility in fundamental aspects. Notably, the EBC not only utilizes detector information as input but also incorporates a detector data processor (logical sensor). This sensor processes raw detection data after collection but before it reaches the controller control logic, receiving data from one or more detectors within the EBC system and generating high-level logical quantity values based on the received data. Following the processing of information through a dedicated unit (based on the specific condition), a signal professional can define their own control algorithm for execution. The key distinction between the EBC and RBC, contributing to the flexibility of the EBC, lies in the user’s ability to define his/her own control algorithm based on the given situation. Figure 5 illustrates the process of changing the signal diagram in the EBC based on the detector information and user-defined control algorithm.

The user-defined control algorithm is seamlessly implemented through a user-friendly control flowchart. This includes

• Condition blocks that determine “when to change” the signal diagram by adjusting the corresponding signal event map.
• Execution blocks that decide “what to change”—specifying the modifications to be applied to the operational signal diagram.

The step-by-step guide for constructing such an algorithm in the EBC, given its straightforward and user-friendly nature, is beyond the scope of this paper. However, more explanation is provided in the next subsection.

Overall, the critical features of RBC mentioned in this section that result in limitations are the fact that

• RBC is restricted to a barrier, which requires the signal professional to go beyond the traditional features of the controller to develop flexible logic based on the desired conditions.
• RBC’s functionalities are restricted to the built-in algorithms, and signal professionals are required to only input parameters but cannot change the predefined algorithm.

The EBC, on the other hand, allows signal professionals to create their own desired traffic signal control logic. Unlike other innovative approaches, which attempt to improve RBC functionalities and produce results with difficult and time-consuming computation and development procedures, the EBC provides flexible functionalities without sacrificing simplicity.

EBC DUMKA_E distinguishes itself from universal coding languages (e.g., utilizing coding languages in the Vissim COM interface) by recognizing the challenge of balancing three crucial goals:

• Expressiveness: The degree to which a programming language allows a programmer to communicate their intentions and logic clearly and efficiently.
• Simplicity: The ease with which a programmer can comprehend and utilize the fundamental concepts and principles of a programming language.
• Brevity: The quality of conciseness of code written in a programming language.

While universal languages, such as C++ and Java, may excel in one or two of these aspects, achieving all three simultaneously proves challenging. Expressiveness must harmonize with the language’s simplicity and conciseness. EBC DUMKA_E represents an endeavor to establish an efficient and declaratively programmable system for controlling traffic signals. This means that DUMKA_E requires users to define the desired output rather than specifying how to achieve it. Declarative programming within EBC DUMKA_E aims to minimize programming efforts and costs by efficiently collecting and inputting only necessary information. The goal is to minimize required input while ensuring comprehensive coverage of various aspects of traffic control. Moreover, the system is designed to be internationally applicable, meeting the standards outlined in the Vienna Convention. This makes it suitable for implementation in traffic control systems across different countries.

3.2. EBC Overall Programming Workflow

EBC DUMKA_E stands as an efficient programmable system for traffic signal control based on specified rules. With minimal essential information (discussed later in this section), DUMKA_E can offer a complete range of programmable actions suitable for standard traffic control systems. The subsequent section provides a detailed breakdown of the overall architecture of EBC DUMKA_E. Figure 6 illustrates the DUMKA_E interface consisting of several modules where the user’s input is required to develop logic for a traffic signal controller. The minimum information needed to program the desired signal control in DUMKA_E is explained in the following.

Step 1:

Defining Signal Groups: To establish well-defined signal groups, it is necessary to provide qualitative data (e.g., road user type, geometrical directions/approaches, etc.) and quantitative data (e.g., signal phase changing times, minimum greens, etc.).

Step 2:

Defining Conflicting Signal Groups: To prevent potential conflicts, it is crucial to meticulously define signal groups with conflicting rights of way. Additionally, careful consideration should be given to the intergreen times, the duration between the end of the right-of-way for one signal group, and the commencement of the right-of-way for the conflicting group.

Step 3:

Defining Signal Events Map: Constructing a signal events map hinges on the creation of a map detailing every signal event. This map is a chronological compilation of signal events linked by precedence relations based on their occurrences in a timely manner.

Step 4:

Defining Detector Data Processor (if needed): Defining the detector data processor (logical sensor) is a step that involves the postprocessing of detection data and the preprocessing of controller data. This step takes place only if there are physical detectors installed in the field. It interprets detectors’ values and prepares them for use as high-level data in the controller logic, such as the two examples: (i) the right-of-way demand analyzer or (ii) the right-of-way gap analyzer explained below.

• “Right-of-Way-Demand-Detector”: This detector data processor outputs zero if, at the moment, there are no unserved road users in the detection zone; otherwise, it outputs 1.
• “Right-of-Way-Usage-Gap-Out-Detector”: This detector data processor reports a 0 if, during the green phase, there is no gap exceeding the given threshold value for traffic related to the specified signal group; otherwise, it outputs 1.

Step 5:

Defining User-Defined Algorithm: This section offers a set of actions to modify the specified operational signal diagram and to implement a desired algorithm. Based on the signal events map and the desired algorithm, the following information should be specified:

• The part of the signal event map that is under consideration for flexible changes (e.g., phase 1 gaps out, and the unused green time is transferred to phase 2).
• The actions that are intended to be applied (e.g., early green, red truncation, etc.)
• The moment when the changes should be applied to the signal event map.

An operational signal diagram is a display, showing in real time which signal is assigned or should be assigned (planned events) to each signal group at any moment. Operational signal diagrams are updated in real time based on relevant algorithms, information from detectors, etc.

Step 6:

Defining Signal Control Plan: Defining the signal control plan is another important section of the process in EBC DUMKA_E. It provides the signal professional an opportunity to determine a basic signal timing diagram based on the signal map. Additionally, in the case of a non-fixed-time control, it is possible to make further operational modifications (e.g., adaptive behavior algorithms).

Step 7:

Emulating the Controller’s Performance: EBC DUMKA_E can emulate any of the developed control logics. The emulation is helpful for the following purposes: fine-tuning operations of the controller, observing detection status, and tracing and debugging the algorithm (if needed) before implementing it.

In summary, for DUMKA_E to formulate and customize the desired signal plan, it necessitates two key pieces of information:

(1)

When to change the parameters.

(2)

How to change the corresponding parameters on the signal event map.

3.3. EBC Building Process, Methodology and Concept

The building process of the EBC is clearly explained in this section. To enhance clarity, consider the signal map in Figure 7 (showing the signal events map for the intersection in Figure 2) as an abstract physical construct, conceptualized across an infinite number of cycles. This map encompasses the following elements for ease of understanding:

• A green round balloon, heavier than air, tends to descend towards the ground.
• A pink square balloon, designed to be lighter than air (e.g., filled with helium), tends to ascend upwards (flying).
• A vertical stick, composed of two segments, with the lower end affixed to the balloon.
• Imaginary directed connections between these elements enforce specific spatial constraints.

It is assumed that the weight of the heavy (round) balloon exceeds the lifting force of the flying (square) balloon; therefore, this combination tends to descend toward the ground. These forces are represented by arrows in Figure 7. In this context, the final vertical positions of the balloons, once their movements have concluded (i.e., the equilibrium state has been attained), precisely correspond to the temporal positions of the respective signal events in the signal diagram after the building process.

The flexible building processes, coupled with the attributes influencing the building outcome, enable users to modify the resulting signal diagram by adjusting these attributes. The EBC facilitates such modifications through the ability to execute one or several simultaneous “changing actions”. Explicitly, the fundamental changing actions in the EBC can be presented as follows (A-1 to A-6 are depicted in Figure 8 based on the same analogy of balloons).

A-1

Shorten the balloon stick to its minimum length.

A-2

Manually stabilize a balloon to prevent it from descending during transitions between equilibrium states.

A-3

Lengthen a balloon stick to its maximum length without disrupting the equilibrium state.

A-4

Alter the size of the balloon and/or switch the balloon type from “heavy” to “flying” and vice versa.

A-5

Change the balloon to transparent (invisible).

A-6

Minimize the balloon stick to its utmost minimum value.

With this set of changing actions, implementing common modifications to the signal diagram becomes straightforward. For example:

Modification 1:

Shortening the green time for one signal group to its minimum value and reallocating the unused time to the green time of another signal group, thereby maintaining the cycle length.

Modification 2:

Skipping the green activation for one signal group and reallocating the unused time to the green time of another signal group, thereby maintaining the cycle length.

The depictions of these two modifications are presented below. To elaborate further, Figure 9 showcases Modification 1, providing both an analog representation (a) and its equivalent presentation in EBC DUMKA_E (b) for clarity. Figure 10 exclusively illustrates Modification 2 in EBC DUMKA_E.

Now that the process for making modifications is understood, it becomes crucial to understand how to instruct DUMKA_E regarding when and what changes to make. As previously discussed in Section 3.1 and Section 3.2, the EBC employs not only detector information as input but also integrates a detector data processor (logical sensor). This processor analyzes the data from the detectors, determining, through the user-defined algorithm, “when to change” the signal diagram (by modifying the corresponding signal event map) and “what to change” (which changing actions should be applied to the active signal diagram).

To define the algorithm, the following elements are required:

• Define “what to change” (in this example, Modifications 1 and 2 are already defined, as in Figure 9 and Figure 10).
• Define “when to change” as an if-then flowchart (Figure 11).

Similarly, one can articulate more intricate control logic to accommodate various conditions. For instance, a more complex actuated control scenario may involve the decision to skip or shorten the green duration of one signal group contingent upon whether the concurrent signal group has met the condition for skipping or shortening its green time. (It is reasonable to shorten the green time for the straight movement signal group only when the opposing straight movement signal group’s green time is also shortened).

In addition to the detector data processor (logical sensor) and functions that enable the design of high-level conditions in the control logic flowchart, the EBC also furnishes the capability to assess expressions utilized in these conditions within the contexts of various signal diagrams. For example, consider a signalized intersection with basic actuated logic for the left turn movement, as discussed earlier. Additionally, assume that the through movements are coordinated. To mitigate the adverse impact of an early start of green, it is essential to ensure that the signal group following the left turn signal group does not start earlier than Δ seconds (relative to the original time point), where Δ is a value determined by specific traffic data, such as traffic counts for the given movement. This method is used further in the advanced scenario.

4. Experimental Set-Up

4.1. Simulation Testbed

A high-fidelity Vissim microsimulation model of a real-world arterial with two signalized intersections (#5200 and #4800) along 3500 South in Utah, developed previously, [32] was used as a testbed for these two scenarios. The turning movement counts are depicted in the figure, and the speed limit was set to 45 mph, representing the conditions of the study area. This 2-intersection network was chosen because it both offers enough details for exploring the functionalities of signals at the intersection level and provides a chance to investigate the coordinated operations at the corridor level. The PTV Vissim was employed to interface both a field-like controller Econolite ASC/3 and the event-based external controller DUMKA_E in identical conditions. Figure 12 shows the study area.

In addition, two scenarios were developed to introduce EBC DUMKA_E capabilities. These scenarios are described in detail in the section below.

4.2. Experimental Design

The first subsection provides an example demonstrating the capability of DUMKA_E in developing a control logic that can replicate the output of the standard RBC controller (in this case, Econolite ASC/3). Following this, a scenario is proposed aiming to address some of the limitations of common NEMA-based controllers. The signal control for this scenario was modeled in EBC DUMKA to illustrate how the EBC concept could be useful in addressing RBC’s shortcomings in a special condition, as described in this example.

4.2.1. Replicating RBC Operations through EBC/DUMKA_E

To showcase the modeling capabilities of DUMKA_E, an actuated-coordinated operation was selected that encompasses all crucial aspects of RBC operations (e.g., properly functioning offset values, cycle lengths, green splits, detection, etc.). Two signalized intersections, namely #4800 and #5200, were specifically chosen to fulfill this objective. The traffic demands for these scenarios are moderate, with low pedestrian activities. Figure 13 illustrates the scheme of intersection #4800 in Vissim developed based on the NEMA phasing (Figure 13a) and the layout of signal groups, as designed in the DUMKA_E corresponding to the same intersection (Figure 13b).

The modeled intersection has ten signal groups (in DUMKA_E signal groups 1 to 6 are vehicular phases, while signal groups 7 to 10 belong to pedestrians). After defining the signal groups, to develop and specify conflicts, a table of intergreen times was created to ensure safe operation at the intersections. Next, to establish an actuated operation in DUMKA_E, the detectors and their functionalities were specified. Afterward, the user-defined algorithms for coordinated actuated operations within the DUMKA_E were built (as discussed thoroughly in Section 3.3). Following a similar approach, algorithms for the remaining phases were constructed in the EBC to emulate the operations observed in the RBC. Figure 14 illustrates the RBC signal diagram for the identical intersection (#4800) in which the EBC replicates the same signal timings and phasing as shown in the figure below.

4.2.2. Advanced EBC Control Strategy for Coordinated Phase Initialization

This scenario offers a new method for deciding when to terminate a phase and/or initialize another phase based on the accumulated number of vehicles turning at the intersection instead of the common vehicle extension method in RBC. While the user can set a value for the vehicle extension to terminate a phase if no demand is detected, this option alone may not suffice for all scenarios. Figure 15 shows an example of this condition. For instance, a queue may form at a downstream intersection (#5200) in a coordinated corridor, particularly if many vehicles turn left or right from side streets (vehicles are shown in red turning from the red arrows at the #4800 intersection). Such a queue may need to wait until the next cycle is served, even after the vehicles from the coordinated phase at the upstream intersection are released (vehicle in green at #4800). Depending on the size of the queue, the vehicles arriving from the upstream signal during the coordinated phase may need to stop fully or partially at the downstream intersection due to the existing queue. To address this issue, DUMKA_E can determine whether to terminate or initiate a phase based on the accumulated number of vehicles turning at the upstream intersection using a detector data processor unique to EBC DUMKA_E instead of relying solely on the common vehicle extension method, which is common within RBC functionalities.

In this scenario, the controller counts the number of vehicles turning left and right from side streets (red vehicles turning NBL and SBR, respectively, in Figure 15) at the upstream intersection (#4800) and decides when to start the coordinated phase φ2 at the upstream intersection based on the predicted size of the formed queue at the downstream intersection (#5200). This way, the EBC control logic prevents the platoon from being stopped at the downstream intersection, leading to more efficient coordination.

The same network with two signalized intersections was used for evaluating the advanced proposed controller strategy. The existing turning movement counts and signal timings from the field were not suitable for this scenario. This strategy attempts to solve the traffic issue in the case of considerable turning movements from NBL and SBR at the upper intersection, resulting in a queue at the downstream intersection. Therefore, traffic volumes for the NBL and SBR movements at intersection #4800 were increased for the sake of this case study. Consequently, the signal timings for the network with the new volumes were optimized by using PTV Vistro to enable the Econolite ASC/3 controller to work with the optimal signal timings.

5. Results and Discussion

Each of the mentioned scenarios was compared with its counterparts in Econolite. The following section presents the results of the evaluation of DUMKA_E with actuated coordinated operations, followed by the customized signal control logic developed in DUMKA_E. Each of these result sections consists of several subsections that present the investigated performance measure.

5.1. Replicating RBC Operations through EBC DUMKA_E

5.1.1. Duration of Green

To compare DUMKA_E and Econolite in terms of how similarly/differently the signal timings change, the average duration of green from the Vissim outputs for all signal groups on both intersections for one hour of simulation (consisting of 40 cycles) was investigated. The results indicate that the developed actuated-coordinated controller in DUMKA_E performs the same as the actuated-coordinated controller in Econolite ASC/3. Figure 16 illustrates the results for the average duration of green for both intersections.

As depicted in Figure 16, the outcomes reveal that DUMKA_E’s actuated-coordinated controller operates on par with the actuated-coordinated controller in the Econolite controller. The only deviations occurred in less than five instances, contributing to less than 4% differences, which were attributed to occasional minor inconsistencies. In the remaining cycles, a consistent phasing pattern was maintained, with identical start and end times for green lights, resulting in almost identical average green durations. Detailed explanations for these occasional inconsistencies are provided in the subsequent section.

5.1.2. Detection Inconsistency

These minor changes in detector status between DUMKA_E and Econolite can be explained as a discrepancy in detection (Figure 17). Figure 17a illustrates the detector status for signal group 6 for a full hour in Econolite and DUMKA_E. Figure 17b,c show two selected cycles illustrating one of these cases on the detector status diagram and signal status diagram. It should be noted that the detection itself is not necessarily the original cause of these discrepancies. Each controller has a particular timing when it processes detector data and decides which signal status (for each phase) must be set for the next second. Therefore, these decision timings in DUMKA_E and Econolite are slightly different and, occasionally, may result in different decisions. Nevertheless, this does not imply any errors in DUMKA_E or its inability to replicate Econolite properly.

Additionally, the controllers might have distinct signal revision schedules (e.g., one with time points at 0.0 s, 1.0 s, 2.0 s, ..., and another with 0.1 s, 1.1 s, 2.1 s, …). To investigate this discrepancy in detail, the previous cycle was examined. Figure 18 depicts 3354 s of simulation in both scenarios, focusing on active signal groups 4 and 8. The blue ovals highlight the same vehicle traveling from south to west. Despite the screenshots being captured at the exact simulation second and both controllers replicating the same signal control logic, there is a discrepancy in the location of the specific vehicle. This discrepancy could result from drivers in Vissim reacting differently to signal statuses, influenced by minor operational disparities between controllers or related to the startup state and transition logic of ASC/3, introducing slight perturbations. The ASC/3 may occasionally experience force-off errors and transitions, even without apparent reasons, justifying the mentioned discrepancies.

5.1.3. Average Green and Red Time

Figure 19 and Figure 20 represent the average duration of green and red for each signal group for intersections #4800 and #5200, respectively, modeled in DUMKA_E and Econolite ASC/3. Comparing the reported results proves that DUMKA_E has 97.6% accuracy in replicating RBC operations in terms of the average duration of green and red times between these two control methods for all the signal groups. These results again demonstrate that the DUMKA_E as an EBC can almost fully replicate an actuated-coordinated controller (in this case Econolite ASC/3).

5.2. Advanced EBC Control Strategy for Coordinated Phase Initialization

Average Delay per Movement

Figure 21 displays the average delay per movement for each phase at both intersections. The proposed strategy adjusts the start point of phase 2 at intersection #4800 based on the right (phase 8) and left (phase 4) turns at that intersection. This modification significantly reduces delay by over 30% between intersections #4800 and #5200 in the E–W direction (WBL and WBT at #5200). While this control strategy benefits vehicles approaching intersection #5200 by postponing phase 2 and phase 5 at intersection #4800, it does lead to increased average delays for these phases at intersection #4800, as evident in Figure 16 (WBL, WBR, WBT). It should be noted that the advanced scenario was developed for the sake of showing the advanced capabilities of the EBC and not necessarily for improving the operations at all phases of the investigated intersections. The average delay for intersection #5200 has notably decreased (highlighted in green). This novel strategy in DUMKA_E results in a 42.3% lower delay for the E–W approach (WBT at #5200) compared to a typical actuated-coordinated RBC controller. Other movement delays remain nearly the same in both controllers, as indicated by the remaining results.

Figure 22 illustrates the average number of stops per movement at both intersections. The proposed strategy involves adjusting the starting point of SG 2 at intersection #4800 based on the right (phase 8) and left (phase 4) turns at that intersection. The objective is to decrease the average stops for intersection #5200 in the westbound (WB) approach, highlighted in green. In DUMKA_E, this new strategy achieves a 26.6% reduction in the average number of stops for the east–west (E–W) approach at intersection #5200 compared to a typical actuated-coordinated RBC controller. However, the strategy’s primary goal of delaying the green start for the WB approach at #4800 results in an increase in the average number of stops for SG 2 and SG 5 at intersection #4800, as shown in Figure 22 (WBL, WBR, WBT). This trade-off aligns with the strategy’s intended outcome. Importantly, the results indicate consistent average stops for the remaining movements between both controllers.

6. Conclusions

This paper introduces the novel event-based controller (EBC) framework, utilized in virtual controller DUMKA_E software, which can replicate the basic functionalities of NEMA-based RBC controllers and can provide additional flexibility that may not be achievable with common RBC controllers. While the RBC controllers are limited, the EBC is unrestricted in its application in developing a desired traffic signal control strategy. RBC is restricted to a barrier, which does not enable the controller to develop flexible logic based on the desired conditions. Also, RBC’s functionalities are limited to the built-in algorithms, and the signal professionals are required to only input parameters but cannot change the predefined algorithm.

The EBC, on the other hand, allows practitioners to create their own desired traffic signal control logic. Unlike other innovative approaches, which attempt to improve RBC functionalities and produce results with difficult and time-consuming computation and development procedures, the EBC provides flexible functionalities without sacrificing simplicity.

This study provides a comparison between an RBC and an EBC and explains the concept of an EBC and the architecture of the DUMKA_E, an EBC software, which has been utilized in this study. To illustrate the capabilities of an EBC, two individual scenarios were developed. The first scenario demonstrates the capability of an EBC in replicating the output of the RBC standard controller using the example of Econolite ASC/3. Then, an advanced scenario developed in DUMKA_E illustrates how the EBC concept can be used to address some of the limitations of the common NEMA-based controllers. The results show that EBC DUMKA_E replicates the actuated-coordinated operations almost identically (with 97.6% accuracy) to a state-of-the-art RBC controller.

Additionally, the evaluation was conducted on the performance of an advanced EBC signal control strategy that goes beyond the functionalities of common RBC controllers. This approach allows greater flexibility in terminating and initializing phases, depending on the status of a downstream queue, making it suitable for specific field conditions.

The flexible functionalities of the EBC open the door to the development of even more customized traffic signal control strategies for special conditions, encompassing multi-modal activities and differing priority requests, wherein the EBC is anticipated to demonstrate its full potential. Future research should consider developing and implementing advanced scenarios on a larger scale network to investigate the benefits of the EBC under different traffic conditions.