Chapter 2. Automated Driving Systems and Highway Automation

This chapter introduces national highway automation and automated driving systems (ADS) technologies and behavior.

Automated Driving Systems and Behavior

As cyber-physical systems, ADS-equipped vehicles can be abstracted into sensing, computing, and actuation modules, as shown in figure 1. Sensing devices, such as laser scanners (light detection and ranging [LiDAR]) and cameras, are typically used for driving automation in urban areas. Actuation modules handle steering and throttle, and the trajectory planning and tracking module typically generate the control commands. Computation is a major component of self-driving technology. Scene recognition, for instance, requires the localization, detection, and prediction modules, whereas path planning is handled by mission- and motion-based modules. Each module employs its own set of algorithms. Combined, the modules are exemplified by the well-known open-source automated driving software, Autoware™. Figure 1 shows the basic control and data flow for an autonomous vehicle. Sensors record environmental information that serves as input data for the artificial intelligence core, which includes data fusion for vehicle localization based on filtering techniques, machine learning methods for predicting other vehicle’s behavior, and intelligent decision-making in mission/motion planning using optimal control or reinforcement learning approaches. Three-dimensional maps are becoming commonplace for self-driving systems, particularly in urban areas, as a complement to the planning data available from sensors. External data sources can improve the accuracy of localization and detection without increasing the complexity of the vehicle’s algorithms. Artificial intelligence cores typically output values for angular and linear velocities, which serve as commands for steering and braking, respectively.

Another important concept related to ADS operational behavior is the operation design domain (ODD). In SAE’s definitions of automation levels, a driving mode is a type of driving scenario with specific dynamic driving task requirements (e.g., expressway merging, high-speed cruising, low-speed traffic jam, and closed-campus operations). In SAE’s levels of driving automation, shown in Figure 2, a particular shift occurs from SAE Level 2 to SAE Level 3: the human driver no longer has to actively drive when the corresponding automated driving features are activated. This is the final aspect of the dynamic driving task that is now passed over from the human to the automated system. At SAE Level 3, the human driver still has the responsibility to intervene when asked to do so by the automated system. At SAE Level 4, the human driver is relieved of that responsibility, and at SAE Level 5, the automated system will never need to ask for an intervention.

Source: Autoware³
Figure 1. Diagram. Automated driving vehicle platform (Autoware).

Source: © 2020 SAE International. The summary table may be freely copied and distributed provided SAE International and J3016 are acknowledged as the source and must be reproduced AS-IS.⁴
Figure 2. Illustration. SAE International definition of levels of automation.

Based on the understanding of ADS software structure, any ADS component under different rules and regulations can affect ADS operational behavior. For example, yellow signal legends and timing may vary along and among urban corridors, such that when an AV detects a yellow light, how it interprets the rule may be dramatically different, which will then change the time when the vehicle can pass the stop bar at the intersection and, in turn, have an effect on the trajectory planning process of the AVs. Another example involves use of the left-most lane on freeways (e.g., overtaking only or regular driving). If the lane can only be used as an overtaking lane, the ADS planning module will always ask the vehicle to change back to the original lane after it passes the front slow-moving vehicle. Compared with the other condition (i.e used as regular driving lane), this traffic rule will potentially result in frequent lane-change behavior on freeways, causing inefficient traffic operations, demonstrating that different traffic laws and regulations may result in dramatically different ADS behaviors, even with the same ADS software. It is critical to provide ADS vehicles with accurate traffic regulation information and to design ADS software to explicitly incorporate the regulations to ensure safe and efficient behavior.

Additionally, ADS only involves single-vehicle automation through onboard sensing and computing. However, SAE is working on a new standard, J3216,⁵ to define cooperative driving automation (CDA), which enables and supports ADS automation through machine-to-machine communications. In fact, CDA becomes even more relevant when traffic regulation databases are shared with AVs enabled with CDA to communicate this information. FHWA CARMA^SM research vehicles, shown in Figure 3, are designed using open-source software to test CDA concepts to improve transportation system management and operations (TSMO) using CARMA Cloud^SM, a cloud-based framework. Figure 4 shows the CARMA program paradigm, which enables collaboration among industry, academia, IOOs, and public agencies on cooperative automation applications. Information from databases of traffic regulations can be shared with ADS-equipped vehicles enabled with CDA through vehicle-to-infrastructure (V2I) communication.

Source: FHWA
Figure 3. Photo. CARMA vehicles.

Source: FHWA
Figure 4. Illustration. CARMA program paradigm.

Automated Vehicle Data Framework

The U.S. Department of Transportation (USDOT) has facilitated agreements among industry and non-Federal governments on common data formats that lower the cost of data exchange. This process for rapid deployment of an open data specification has been modeled on the General Transit Feed Specification,⁶ which enables third parties and USDOT to access consistent transit data across the nation. This model encourages incremental adoption of data elements from the broader specification documented in the Work Zone Activity Data (WZAD) dictionary developed through FHWA’s Work Zone Data Initiative (WZDI),⁷ which addresses the role of these data in use cases spanning the entire project delivery life cycle.

USDOT launched Data for Automated Vehicle Integration⁸ (DAVI) as an initiative to identify, prioritize, monitor, and, where necessary, address data exchange needs for AV integration across the modes of transportation. Access to data is a critical enabler of safe, efficient, and accessible integration of AVs into the transportation system. Lack of access to data could impede AV integration and delay safe introduction. In December 2017, USDOT hosted the Roundtable on Data for Automated Vehicle Safety to discuss potential priorities for voluntary data exchanges to accelerate safe AV integration. The department kicked off the Work Zone Data Exchange⁹ (WZDx) project in March 2018 to take on one of the priorities identified at the roundtable. The summary notes also call for enhanced inventories for roadways, which include high-definition maps already being developed. Developing inventories of fixed objects on the road, such as traffic signs, is not a difficult task and it has been done for many locations by the private sector. The rules behind the infrastructure (i.e., traffic laws and regulations) also need to be part of the map. Unfortunately, no complete digital database exists that addresses this key issue.

Data for Automated Vehicle Integration

The USDOT DAVI framework provides a common language for identifying and prioritizing data exchange needs across traditional silos. It is designed to help stakeholders working on diverse aspects of AV integration understand each other’s data needs and learn from successful exchanges as they emerge. The framework defines key categories, goals, participants, and priorities of data exchanges identified by the department’s stakeholders, such as work zone data needed for AVs to navigate safely. USDOT continues to refine and update the framework based on stakeholder inputs.

Source: USDOT¹⁰
Figure 5. Illustration. Framework of Data for Automated Vehicle Integration.

Work Zone Data Exchange and Initiative

Up-to-date information about dynamic road conditions, such as construction events, can help ADS and humans navigate safely and efficiently. Many IOOs maintain data on work zone activity. However, a lack of common data standards and convening mechanisms makes it difficult and costly for third parties—including original equipment manufacturers (OEM) and navigation applications—to access and use these data across various jurisdictions.

The purpose of FHWA’s WZDI is to develop a recommended practice for managing WZAD and to create a consistent language, through the development of a data dictionary and supporting implementation documents, for communicating work zone activity information across jurisdictional and organizational boundaries. The effort promotes a stakeholder- and systems-driven perspective for WZAD that serves the emerging need for improved real-time road condition information as well as traditional operations management, which benefits from improved data portability throughout project life cycles. This initiative seeks a shared approach to managing WZAD to benefit the broad spectrum of potential uses and users, acknowledging ADS as one of the key use categories.

Implementation of this language is occurring through the USDOT Intelligent Transportation System Joint Program Office’s (ITS–JPO) WZDx. The WZDx is a publicly available basic work zone data specification intended to jump-start voluntary adoption of a common data language by data producers and users across the country. By using WZDI guidance to determine agency-specific needs and uses for work zone data, and subsequently developing a customized specification using the WZDx as a foundation, there can be standardization for data sharing across organizational and geographical boundaries. The relationship between the two efforts is shown in Figure 6.

Source: Colorado Department of Transportation
Figure 6. Illustration. Overview of national work zone data management efforts.¹¹

The WZDx specification¹² enables IOOs to make harmonized work zone data available for third-party use. The intent is to make travel on public roads safer and more efficient through ubiquitous access to work zone activity data. Specifically, the project aims to get data on work zones into vehicles to help ADS and human drivers navigate more safely.

The WZDx working group is working to describe a set of common core data concepts, meanings, and enumerations to standardize a data feed specification to be used to publish work zone information. Common core is defined in this context as data elements needed for most (if not all) work zone data use cases that could possibly be defined. The data specification includes data elements that data producers (i.e., State transportation agencies and other IOOs) are already producing (required) as well as those not currently produced (optional). This common core is also considered extensible, meaning both required and optional data elements can be added to support specific use cases now and in the future.

The WZDx data feed will be incrementally enhanced to evolve into a data feed that supports advanced warnings to AVs in and around work zones. The current version (WZDx v1.1) is a first step in this effort and highlights common core elements that serve as a foundation for required data for effective data exchange. This version addresses data currently supported by existing data feeds published by public and private sector organizations.

WZDx data producers will use the specification to make their active work zone data feeds available to non-government users. These users will then use the harmonized data in a meaningful way, which will result in establishing the voluntary date exchange of work zone data. This approach is intended to be repeatable, leading to accelerated harmonization of local data.