In previous decades, infrastructure owners and operators (IOOs) in urban areas have seen an exponential increase in vehicular traffic volumes. By 2050, the US population in urban areas is projected to grow to 89%, up from 80.7% in 20101.
Today, with more than 300 urban areas having populations exceeding 100,000, the challenge of managing urban levels of traffic congestion is expected to include more IOOs, with existing urban area IOOs facing the prospect of even higher densities of vehicular traffic2.
Urban centre growth has placed new levels of pressure on transportation management, including severe traffic congestion that is having profound negative impacts on mobility for our most vulnerable communities, fuel/energy consumption, traffic/pedestrian safety risks, vehicle emissions, and quality of life.
The emergence of innovative data-driven technologies making their way into the traffic management industry has made great inroads in addressing some of these challenges.
New solutions, such as advanced transportation management systems (ATMS) that provide traffic signal optimisation, adaptive signal control, and connected and automated vehicle (C/AV) systems, are proving highly effective at reducing urban travel times and congestion.
These applications rely heavily on computing and communications at the intersections, particularly the computing and communication capabilities of the traffic controller.
Technology pressures
As more technology-based ATMS and sensors come online, the often-overlooked part of the equation is how to cost-effectively incorporate and make these technologies functional and practical in the existing infrastructure, particularly for data-hungry C/AV systems. Despite the advancements and capabilities of C/AV on-board vehicle and roadside equipment, there are two very substantial challenges the traffic management industry faces to make C/AV a reality. These technologies are rendered mostly unusable if: 1) the fundamental part of intersection management – the traffic controller – is not C/AV-ready; or 2) if the transportation agency must replace all of its installed traffic controllers with new C/AV-ready controllers.
There are thousands of 2070 Advanced Transportation Controller (ATC) units currently in use. For many IOOs, replacing their fleet of traffic controllers all at once is cost-prohibitive. As a result, the challenge moving forward is enhancing communications and computing capabilities of existing traffic controller infrastructure, particularly at the intersections.
In order to take advantage of the benefits of new data-driven solutions, traffic signal operations must be able to manage the abundance of new traffic data available from both traditional detector-point sources, as well as a whole host of new sensors – vehicle-based and infrastructure-located – installed and yet to be deployed.
The promise of C/AV systems is that they can help perceive and predict the overall traffic environment in real time. With the advent of new data sources, traffic controllers will play an even more critical role as more C/AV technologies are developed and deployed. Traffic controllers must be able to make smarter decisions, as well as adequately handle future computing capabilities.
One question still remains - what to do with the thousands of 2070 ATCs that are currently operating traffic signals that were not originally designed to handle the advanced communication and computing requirements of C/AV systems and applications?
C/AV-ready ATC software
Advances in wireless communication technology, such as Vehicle to Vehicle (V2V), and Vehicle to Infrastructure (V2I) systems, have helped create a broader ITS ecosystem that includes Vehicle to Everything (V2X), whereby connected vehicles have become a significant part of the ITS framework.
In the V2X environment, C/AVs can instantly and simultaneously communicate with other vehicles and the infrastructure through dedicated short-range communications (DSRC), or other wireless communications networking technology.
Data from C/AVs provides a more complete picture or situational awareness of the vehicle state, including location, speed, trajectory and other vehicle information. Multiplied over hundreds or even thousands of vehicles, the onslaught of processing traffic data becomes readily apparent.
The most cost-effective way to upgrade the capabilities of existing installed ATC 2070 controllers so they can handle the expanded communication and computing necessary for V2X systems, is to upgrade the controllers with C/AV-ready software. While this may sound simple in theory, it is quite complex in application. As expected, several issues are encountered while porting C/AV-ready ATC software to different controller manufacturers and platforms.
For the purposes of this article, software porting activities focus on 2070-1C platforms based on e300 Power PC cores since these comprised the existing installed base of traffic signal controllers for a prominent state department of transportation (DoT).
The primary issues addressed in porting C/AV-ready software to other 2070 controller platforms are related to: 1) controller card; 2) Linux O/S version; and 3) driver version. As all the other manufacturers’ device drivers are bound to specific O/S versions, the data space and porting processes addressed are reduced to two dimensions: 1) controller; and 2) O/S version. Through the successful porting and testing of new controller software, we can take a closer look at the functional differences between controller platforms and makers, and how these differences could be resolved to successfully port the CAV-ready software.
Different controller platforms
The software porting work that was completed centred around Design Acceptance Testing (DAT), which ran on third-party traffic controllers to identify areas where the controllers differed. The DAT tests were then modified to function correctly on the test controllers. This work was completed as part of a joint effort with the state DoT that owned the controllers.
The goal was to update an existing fleet of 2070 ATC traffic controllers, from several different manufacturers and platforms, with new C/AV-ready software. While the deployed 2070 controllers that were tested included several manufacturers and operating systems, this is not an uncommon representation of existing fleets of 2070 controllers currently installed at intersections across the US. The deployed 2070 controllers tested included the following OS operating systems in Table 1.
| Table 1: Installed Controller OS Platforms |
| Linux 2.6.9 |
| Linux 2.6.34 |
| Linux 3.4.33+ |
| Linux 3.14 |
Notable porting and testing observations
DAT testing
Each of the DAT tests are designed to verify compliance with the ATC Standards 5.2 specification. In some cases, ambiguities in the specification were found, rather than non-compliance3.
General controller differences
For the basis of this paper, the software porting work centred around DAT tests, which were run on third-party traffic controllers in order to identify areas where the controllers differ. The DAT tests were then modified to function correctly on the test controllers. Functional differences between the controllers were relatively minimal, although critical enough to cause C/AV-ready software failure until resolved. A number of the differences caused failure of the DAT. However, the capabilities involved are not used in the C/AV-ready software as it currently stands.
Real-time clock and line synchronisation
For all ATC controllers, the time-of-day clock is supposed to be synchronised with the powerline frequency and should be capable of generating ‘tick’ signals as expected from the device driver [/dev/tod]. In all cases, it was determined and confirmed that the controllers tested passed the real-time tests in the DAT. There is a requirement in the ATC Specification 6.25, section B.7 specification for the /dev/tod device node4.This requirement is not in ATC 5.2b.
The controllers support the clock requirements as follows:
- Linux 2.6.34 and 3.4.33
- /dev/tod – absent
- ‘tick’ signal – should be available
- from CLOCK_MONOTONIC
- with Posix
- Linux 3.14
- /dev/tod – status is unknown
- 'tick’ signal – should be available
- from CLOCK_MONOTONIC
- ‘tick’ signal – may be available if /dev/tod is present
Front-panel LCD operation
The front panel of a 2070 crate is designed to behave as a serial terminal. Access to the panel is performed using a serial port device [/dev/sp6]. This test verifies the ability to send commands, read responses, and present reasonably legible output to the user. As the front panel is independent of the controller card, this test illuminates port-handling differences between the controllers. In all cases the tested commands and displays functioned correctly. The one notable difference is that the controller running Linux 3.4.33 would not correctly receive responses from the front panel until the “read delay” was increased by approximately 50%, from 120 msec to 180 msec, in the DAT test. Whether the root cause is CPU speed, UART performance, port configuration, clock granularity, O/S efficiency, O/S thread dispatch, or otherwise, is unknown.
Verify flash storage size and capability
Under the ATC 5.2 standard, the flash storage requirement is 6 MB for O/S and application storage. Under the ATC 6.25, this was increased to 16 MB. All systems meet the ATC 5.2 specification for total storage. This is adequate storage to host the C/AV-ready software tested and ported and provide for its correct function.
Linux 2.6.x operating system builds have been in the field just under 10 years, and the embedded FAT file system support likely includes FAT16 and FAT32, even though the specification is FAT16. Current, COTS USB storage devices should be supported, not just those under 2 GB. Note that “auto-mount” is not a requirement of the ATC, except at boot time as specified in the ATC 6.25.
Conclusion
While C/AV technology has demonstrated its potential to improve traffic flow efficiency, enhance safety, decrease fuel consumption, and reduce vehicle emissions, it has also brought to light the necessity to upgrade existing infrastructure technology. V2X-based communications and computing requirements, as well as new sources of sensor data, are putting tremendous pressure on the traffic controller.
Until now, IOOs were faced with replacing entire fleets of controllers with new, connected vehicle-ready traffic controllers to accommodate and implement CAV systems. This prospect becomes even more complex with the projected extended period where the combination of conventional vehicles, manned connected vehicles, and automated vehicles coexist on the same roadways. Fortunately, there is a way to upgrade the capabilities of the existing installed base of 2070 controllers to handle the expanded communications and computing necessary for V2X systems. Work has been done as part of continuing development to upgrade installed fleets of traffic controllers by porting CAV-ready software across manufacturers and operating platforms, helping to provide IOOs a cost-effective solution to being CAV ready.
References
- United Nations (UN) Population Division (2018) World Urbanization Prospects: The 2018 Revision
- U.S. Census (2011) “Incorporated Places with 100,000, or More Inhabitants in 2010”
- Advanced Transportation Controller Working Group, ATC Joint Committee, ATC Standards (2006). ATC Standard
- 2b, Final Standard
- Advanced Transportation Controller Working Group, ATC Joint Committee, ATC Standards (2018). ATC 5201 Advanced Transportation Controller Standard v06
About the Authors:
Snehasis ‘Sunny’ Chakravarty (left) is VP of engineering at Econolite; Dustin DeVoe is VP, controller product management at Econolite
