Automated Driving Systems (ADS) Operational Behavior and Traffic Regulations Information – Proof-of-Concept Demonstration Report

CHAPTER 2. TRAFFIC REGULATIONS DATA FRAMEWORK

This chapter describes the prototype ADS regulations data framework design and implementation of its database, data interface, and administrative interface.

OBJECTIVE

The objective of the traffic regulations data framework implementation is to fulfill the intent of the CoU for data and interfaces to support providing traffic regulations data to ADS.

REGULATIONS DATA FRAMEWORK

The architectural intent and concept for the regulations data framework are described in the CoU. These concepts are implemented in the demonstration framework. Figure 1, reproduced from the CoU, depicts the system entities and relationships involved in regulating driving behaviors.

Source: FHWA.

Figure 1. Illustration. Automated driving systems regulations data concepts.

Challenges and Limitations on Framework Design

Implementing a traffic regulations framework for use by ADS is challenging due to the nature of traffic regulations, which were created for human drivers, and due to the limitations of automation technologies:

• The human language used in traffic regulations is not in a form that ADS can use without additional development in the machine interpretation of legal texts.
• Standardized interpretation of traffic regulations is limited by the variability in the structure of the regulations text among jurisdictions. The regulations texts do not necessarily use common section numbers or titles.
• Although traffic regulations generally use a consistent set of terms and definitions among jurisdictions, those terms may not readily apply to an ADS development context. Regulations for human interpretation are generally based on descriptions of situations, actions, and maneuvers. Some rules are procedural: “do this, then this.” Future work in translation of traffic regulations for ADS applications may need to develop semantic standards for rules and controls.
• As described in the CoU, ADS development environments and simulations do not have “standard” interfaces for traffic rules and controls. Autoware, CARMA, and CARLA, for example, each have their own models. ADS development generally embeds interpretation of rules and controls in the code for specific operational design domains (ODDs).
• Traffic controls generally relate to specific rules within the regulations, but these relationships are not one-to-one. Rules for right turn on a red traffic signal may be confined to a single bounded set of instructions in a traffic code. There may, however, be multiple standard sign configurations associated with a right turn on red, each for a different setting or circumstance.
• Some regulations are interpreted in State-issued driver manuals with more specific guidance. The regulation describes what should or should not be done. The guidance in the manual provides an additional layer of interpretation as to how that regulation can be met.

Design Features and Attributes

From the broad view of its potential use cases, the framework needs to function as a research catalog and a downloadable database. It will provide a structure for capturing traffic regulations from many jurisdictions. The resulting catalog will be most useful as a reference for ADS development and potentially as a local database from which regulations and traffic controls can be accessed for ADS use. Changes to regulations are likely not frequent enough to necessitate real-time updates for vehicles, although changes will be logged and determined from the database.

Similar rules in different jurisdictions need to be linked to the extent that they apply to identical driving situations. Consistency in labels and attributes for driving situations would, at a minimum, enable an ADS to be aware of changes in local regulations for common situations like right turn on red or U-turns. As noted, there is no common reference scheme for traffic regulations, so the approach is to catalog situations within a driving “state space” by maneuver and state variable. Regulations from different jurisdictions readily fall into situations such as, “pass left,” “stop at intersection with a red signal,” and “turn left at intersection with a green signal.”

This approach needs an identified semantic framework to communicate the traffic rules to developers. Creating labels for linking regulations across jurisdictions implies a vocabulary for those situations. Because the regulations apply only to regulated roadway operations, however, the constraints on that state space implies a finite set of potential regulated states and sensed conditions.

The instructions provided by regulations may vary even for those situations that are common to a group of jurisdictions. The intent of the framework, however, is to be able to identify cases where the regulations may vary, and not to parse the variations within those regulations. Some regulations are procedural, such as stopping at a red traffic signal. The details in those procedural descriptions may nonetheless vary among jurisdictions. The framework will capture the various regulations for each situation, but not directly parse them to identify specific differences.

Traffic regulations need to be identified with the applicable traffic controls—markings and signs, and traffic signal indications—as part of describing the “state space” to be expected within a jurisdiction. The ADS needs to be able to identify the applicable controls from its sensors and detection systems. The regulations framework then needs to catalog applicable control types for jurisdictions. There may be future value in cataloging the specific locations of deployed controls, so that control detections can be confirmed with the catalogued control geolocations, or used as a backup to on-board detection.

Current ADS implementations appear to be algorithmic, but not parameterized. Rules for operating within an ODD are captured within the algorithms used in that ODD, but do not appear to be parameterized such that a common set of rules (algorithms) could be applied to multiple ODDs. As such, it does not appear that the regulations framework needs to provide an explicit parameterized procedural breakdown of the rules within particular regulations. This further implies that the guidance in driver manuals does not need to be included in the framework. Such guidance is not regulatory and may not apply to ADS. However, an ADS might violate human driver expectations (e.g., for following distance) if guidance for human drivers is not applied.

The quantity of jurisdictions in the United States and the variability of the traffic regulations among them preclude populating the demonstration regulations framework with all local regulations. Automated collection and ingestion of regulations might be available as a third-party service, at least for those regulations that are available in digital formats. In the meantime, the initial cataloging of regulations will need human interpretation. A complete National ingest and update may warrant investigation of natural language processing and machine learning techniques.

Blockchain Implementation

The prototype implementation of the ADS regulations data framework is based on blockchain technology. Managing records of jurisdictional regulations is inherently public and distributed. The integrity and authority of the regulations must be protected. A blockchain’s published and distributed ledger of records lends itself well to this situation.

A blockchain peer-to-peer network enables jurisdictions to both assert and attach authority to and verify the integrity of published traffic regulations. The network further enables jurisdictions to establish publishing reciprocity, such that jurisdictions can recognize and vouch for the authority of each other’s published regulations.

Regulations published using blockchain methods additionally maintain their change history. Each regulation update is identified by a mathematically immutable identifier created as part of that update. ADS can independently apply the same algorithm to verify that received regulations are authoritative.

The distributed nature of the blockchain network ensures that ADS-equipped vehicles requesting regulations data for a particular jurisdiction receive prompt and authoritative responses from nearby blockchain hosts, even if the request is for a remote jurisdiction. This ensures network responsiveness while reducing the burden on any one host.

PROTOTYPE USER INTERFACE

An ADS traffic regulations data framework requires interfaces for administratively capturing the regulations data and for providing data to end users and systems. As shown in figure 2, a fully developed interface requires user login such that that the system can distinguish between administrative and end-user accounts. The prototype framework acknowledges this distinction by showing a login panel, but has not implemented the underlying account management services. Enforcing those roles and implementing account management is not needed for the prototype demonstration and would unnecessarily complicate the development. All users of the prototype have access to administrative and end-user functions.

Administrative User Interface

In concept, the administrative user has access to create and edit traffic regulation data records, whereas the end user can view, but not edit. The administrative role may eventually involve a more sophisticated process to create, validate, and approve the records. A minimum of two independent reviewers would then be needed to ensure records quality. Creators would not be able to validate new or modified records, and validators would not be able to approve those records.

Source: FHWA.

Figure 2. Screen Capture. Automated driving systems regulations user interface home screen and login.

An administrative user adds new regulation records by selecting the “Create” item from the application top menu, as shown in figure 3. The application then displays a menu of data “Elements” in the left-hand panel. The administrative user then works down the list of elements to create records for the regulations applicable to their jurisdiction. The system contains records of jurisdictions for which boundaries are available, and the administrative user selects one for which to create records of traffic regulations.

Source: FHWA.

Figure 3. Screen Capture. Automated driving systems regulations user interface for addition of a new jurisdiction.

The “Title” data element describes the collective body of traffic regulations for which the records are being created, as shown in figure 4. It provides data entry for the appropriate source bibliographic and internet Uniform Resource Locator (URL) references.

Source: FHWA.

Figure 4. Screen Capture. Automated driving systems regulations user interface for addition of regulatory references.

The “Instruction” element, shown in figure 5, captures the specific text of the traffic regulation from the reference title. An “instruction” will generally be a self-contained section of text, such that it does not depend on the text of another section to be understood or applied to a driving situation. Each text is linked to a list of one or more such situations. New “Situation” elements can be added for the jurisdiction as shown in figure 6.

Source: FHWA.

Figure 6. Screen Capture. Automated driving systems regulations user interface for addition of situations.

Traffic control types link the traffic regulations to those devices—signs, signals, and pavement markings—that are deployed to roadways to indicate that those controls (and the regulations behind them) are in force at particular locations. As shown in figure 7, the “Traffic Control Device Type” elements describe the types of controls that may be encountered by a driver or ADS within a jurisdiction. Traffic control devices will be defined by the Manual on Uniform Traffic Control Devices⁶ (MUTCD) or the jurisdictional equivalent as specified in its traffic regulations.

Source: FHWA.

Figure 7. Screen Capture. Automated driving systems regulations user interface for addition of traffic control device types.

End-user Interface

The end-user interface enables those users to view the ADS traffic regulations data captured within the framework. As shown in figure 8, selecting the “Regulations” item on the top menu presents a list of jurisdictions for which regulations have been captured in the data framework. Selecting a jurisdiction from the left-hand panel then displays a list of regulatory system “instructions” in the right-hand panel. Selecting a particular instruction displays the text of that instruction in an overlaying panel, as shown in figure 9. The overlay panel can be closed with the “x” button to select a different instruction.

Source: FHWA.

Figure 8. Screen Capture. Automated driving systems regulations user interface displaying jurisdictions and instructions (sections).

Source: FHWA.

Figure 9. Screen Capture. Automated driving systems regulations user interface displaying the text of regulations.

Situations to which regulations may apply are displayed using the “Situations” item in the top menu. The results, as shown in figure 10, are presented in a table listing situations defined in the system with the sections of regulations (instructions) that apply to each situation for each jurisdiction. Situations for which instructions have not been identified in the system are indicated by “TBD” (“to be determined”). The button labeled “CSV” (“comma-separated values”) initiates a download of the table in CSV format.

Source: FHWA.

Figure 10. Screen Capture. Automated driving systems regulations user interface displaying the association of situations with jurisdictions.

Selecting a particular instruction in the table opens an overlay of the text of that instruction, as shown in figure 11.

Source: FHWA.

Figure 11. Screen Capture. Automated driving systems regulations user interface displaying the text of regulations for a particular jurisdiction and situation.

Selecting the “Traffic Controls” item in the top menu displays the list of jurisdictions in the left-hand panel, as shown in figure 12. Selecting a jurisdiction provides a list of traffic control types associated with that jurisdiction in the right-hand panel.

Source: FHWA.

Figure 12. Screen Capture. Automated driving systems regulations user interface displaying the association of jurisdictions and traffic control types.

Selecting a traffic control type displays an image of the associated traffic control device, as shown in figure 13.

Source: FHWA.

Figure 13. Screen Capture. Automated driving systems regulations user interface displaying a traffic control image associated with a jurisdiction.

PROTOTYPE APPLICATION PROGRAMMING INTERFACE

The ADS regulations data framework is accessed using three application programming interfaces: jurisdiction, boundaries, and situations. The interfaces are accessed through Hypertext Transport Protocol (HTTP) and post specifically named parameters to a URL endpoint. Responses are JavaScript Object Notation (JSON) formatted text. The jurisdiction interface Uniform Resource Identifier (URI) endpoint is api/jurisdiction, and its parameters are "lat" and "lon," to specify a latitude and longitude point of interest, such as the vehicle's current location. Latitude and longitude are in decimal degrees. The response is a list of unique identifiers and names for geographic boundaries included in the jurisdiction encompassing the requested location.

The boundaries interface URI endpoint is api/boundaries, and its parameter is "id." The "id" is the unique identifier for a jurisdiction determined by the jurisdiction interface. The response contains the geo-coordinates (in decimal degrees) of a bounding box for the requested boundary, plus the list of geo-coordinates that define the region.

The situations interface URI endpoint is api/situations, and its parameter is "id". In this case, the "id" is also the unique identifier for a jurisdiction determined by the jurisdiction interface. The response is a list of valid situations active for the given jurisdiction.

PROTOTYPE FRAMEWORK REPOSITORY

The prototype ADS traffic regulations data framework is maintained in a GitHub repository at https://github.com/usdot-fhwa-stol/ads-traffic-regs/tree/cherneysp-initial.