Office of Operations
21st Century Operations Using 21st Century Technologies

Chapter 4. Traffic Regulation Data Exchange Concepts

Traffic Regulations Data and the Uniform Vehicle Code

Although the Uniform Vehicle Code (UVC) is not prescriptive for traffic regulations across the United States, it is archetypical and can be used to identify the essential elements of traffic control regulations. Chapter 1 begins by defining the words and phrases for the transportation system users, vehicle types, roadway types, and other elements used in the regulations. Chapter 11, Rules of the Road, describes in its individual sections the regulations for the interactions of road users with each other, the roadway, and the flow of traffic. The intended readers include human drivers, regulators, administrators, and enforcement officers, so the regulations implicitly describe the interactions between those user roles. They are expressed in text and, in most cases, rely on subjective measures of caution or safety. Many of these regulations provide constraints on driver and vehicle behaviors, but these constraints are seldom specific or measurable.

For example, the UVC Section 11–310 on “Following too closely” states, in part, that: “The driver of a vehicle shall not follow another vehicle more closely than is reasonable and prudent, having due regard for the speed of such vehicles and the traffic upon and the condition of the highway.”32

The UVC does not, however, provide or suggest interpretations of or measurable values for “more closely than is reasonable and prudent” or “due regards for the speed of such vehicles.” As such, the UVC and similar traffic codes are not directly reducible to algorithmic expression. They may be interpretable as such where they are supported or extended to include specific operational performance measures.

Proposed Traffic Regulation Data Elements and Definitions

Figure 5 depicts entities and relationships involved in regulating automated driving systems (ADS). This section first describes the entities and then the inter-relationships among them.

State and local government entities enact and enforce traffic statutes. As infrastructure owneroperators (IOO), they interpret traffic regulations and accordingly deploy traffic control signals and signs. State and local governments have jurisdictions that can be defined by geographical boundaries and enact statutes that can be interpreted as regulations.

A jurisdiction is a specific region over which government and IOOs have authority. It determines the area within which statutes and regulations apply and is defined by one or more boundaries.

A boundary encloses a jurisdiction and is defined by a set of geo-coordinates. Boundaries are generally shared with adjacent jurisdictions, and a particular location may be contained within more than one boundary (e.g., within a municipality, a county, and a State).

A statute is an element of law enacted by a legislative body that sets forth general propositions that can be applied to specified situations.

Regulations codify the particular situations, actors, actions, and constraints that the statutes require. Regulations can help inform the traffic control types, but the behaviors that result from the traffic control are sometimes not explicitly stated in the associated regulations. However, not all regulations applicable to vehicles and their operation necessarily imply a related traffic control type. For example, the length that externally carried cargo can protrude to the front or rear of a vehicle may be regulated, but does not constitute a traffic control.

Diagram shows data concepts' relationship to eachother.

Source: FHWA

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

The Manual on Uniform Traffic Control Devices33 (MUTCD) defines traffic control types. Traffic control types apply to classes of transportation infrastructure users and facilities, and enable or restrict maneuvers. They specify the classes and types of controls that may be deployed within a jurisdiction to enact the regulations. They define constraints on driving behavior such as maximum speed for commercial tractor/trailers. They are associated with visual renditions such as signage graphics and striping; frequently limit direction of movement; and apply to various classifications of vehicles, roadways, and pedestrians. Traffic control types may also include a human controlling traffic, such as a police officer, school crossing guard, or flagman.

A visual rendition is a set of geometric parameters and styling (e.g., shape, color, size) that describes how a traffic control will be visibly presented based on the MUTCD. Graphical elements typically use vector parameters to define size and location within the rendition so that they are easy to scale and transform into different contexts.

Traffic controls for ADS may also be deployed as a set of logical components, referred to here as the ADS rendition. Vehicles, pedestrians, and roadways refer to classes of transportation infrastructure users and types. Familiar vehicle classes include passenger car, bicycle, motorcycle, bus, and commercial tractor/trailer. Pedestrian classes include people in general, school children, and people who have a physical impairment. Roadway classes include freeways, highways, arterials, and neighborhood roads.

Maneuvers are longitudinal and lateral vehicular movements such as passing, stopping, merging, and turning at intersections. Regulations can allow, disallow, or constrain maneuvers under particular conditions.

Traffic controls are instances of traffic control types deployed to particular locations on the roadway network. Traditional traffic controls typically involve visual markings, signs, and signals. They inherit the properties defined by their traffic control types, including their visual and ADS renditions. The traffic controls may have times during which they are in effect and specific physical locations. Many traffic control instances can be created from a few traffic control types.

Each traffic control has a schedule during which it is active. Schedules may represent continuous application, specific days and hours of a day for operations, or cycles of operation (e.g., traffic signal and ramp meters). The schedule for a maximum speed allowed in a school zone, for example, could be as complex as weekdays between 2 and 4 p.m. bounded by the beginning and ending dates of the jurisdiction’s school year.

Placement describes the physical location (i.e., longitude, latitude, height above grade) and orientation (which direction a sign faces) of a traffic control. If a traffic control does not have a specific placement, it may apply within a jurisdiction’s boundaries as a policy. For example, U-turns may be prohibited within a jurisdiction regardless of whether a sign is placed at an intersection.

Proposed Traffic Regulation Interfaces

Based on the stakeholder needs and the use cases discussed in this document, the system described below is proposed to enable storage and retrieval of regulations, regulations interpreted as affected actors and expected maneuvers, traffic control types, and deployed traffic controls. Interfaces are needed for human administrator users representing the stakeholder groups, for developers, for ADS and other systems using the regulations data, and potentially for existing sources of digital regulations data. A secure web browser application is proposed for the human administrator users. A web browser application enables the interface to be developed and distributed with low-cost tools and relatively high assurance of user access and acceptance. Figure 6 illustrates the conceptual relationships among users, data sources, framework components, and ADS.

Regulations data framework interface.

Source: FHWA

Figure 6. Illustration. Regulations data framework and interfaces.

An interface using standard web-based request-response patterns will similarly provide access to digital interpretations of regulations for ADS and other systems. Interfaces for existing sources of online regulations data may be provided where the development effort can be leveraged to multiple sources or be reused to update the regulations data on a regular basis.

Populating the data elements of this model requires cataloging and interpreting the regulations. Some of the data needed for enabling development and operations of the regulations data framework and interfaces are readily available from authoritative sources. For the proposed model to operate correctly, some underlying information sources are necessary to enable it. In the case of named jurisdictions and their boundaries, the United States Census Bureau publishes legal boundaries and names, and their related Federal Information Processing Standards (FIPS), Zone Improvement Plan (ZIP), and geo-coordinate boundaries in shape file (SHP) format. Visual representations of signs from the MUTCD are published by the Federal Highway Administration (FHWA) as downloadable Encapsulated PostScript (EPS) and portable document format (PDF) files. Pedestrian, vehicle, and roadway classifications and allowed maneuvers can also be derived from the MUTCD in conjunction with published government standards.

Regulations data exist in digital forms ranging from scanned paper and merged-text documents to elemental and combined PDF documents and Hypertext Markup Language (HTML) snippets. Whether implemented as a dedicated software interface or through a human system administrator, a regulations ingest interface will record the jurisdiction associated with the data, a source reference, available reference numbering and labels, and, optionally, the regulatory text itself. An interpretive process for regulations is likely performed by a qualified human analyst, and fulfilled through associating each regulation with application actor classifications (pedestrians, vehicles, roadways) and maneuvers chosen from lists set up in the system library.

The administrator interface will include a means to configure traffic control types, with a related interface to configure traffic control instances based on those types. Each traffic control type will have a unique identifier and name, an optional expanded description, associations with related regulations, associations with actor classification and maneuvers, and visual representations from the MUTCD. ADS renditions will be generated by the traffic control data.

Each traffic control instance will have a unique identifier and reference the traffic control type on which it is based. Traffic control instances will have a default continuous schedule that can be overridden with flexible day-of-week, affected hours, and repeating intervals. Traffic control placement will consist of a latitude, longitude, elevation, and orientation and applicable approach vectors.

Output interfaces for ADS and other systems will be selected based on a jurisdiction or geocoordinate region, and the output will be in a common data exchange format such as JavaScript Object Notation (JSON) or eXtensible Markup Language (XML).

Even a sparsely-populated ADS regulation data framework provides a valuable basis for AV-related information. The proposed application could be used to select a jurisdiction and be presented with a list of regulations and their corresponding interpretations, a list of traffic control types and their visual presentations, or a list of traffic control instances and their locations. Report views can be exported to a text file format, such as a comma-separated values (CSV) format. External software systems such as AV fleet managers or AVs can request the same information as human users.

Simulations Methodology

Validating a conceptual regulations data framework does not necessarily need physical ADS-equipped vehicles operating on public roadways. The intent in this project is to develop the concept to a level at which it can be demonstrated for select use cases within a defined and documented operational design domain (ODD) using a small sample data set in a simulated ADS-roadway environment. The simulation environment may then have specific interfaces that need to be fulfilled to complete the demonstration. The ADS regulations data framework proposed in the prior section will provide data for those use cases by means of the simulator application programming interfaces (API). This section briefly introduces the CARLA simulator for autonomous driving, to be applied in this context to ADS-equipped vehicles.

CARLA is an open-source platform that supports independent research in and development of AV environments and behaviors. It enables developers to build detailed models of an operations environment, actors (e.g., vehicles and pedestrians), and behaviors. CARLA uses the OpenDRIVE® standard (version 1.4, as of the date of this report) to define the roadway environment and the Unreal Engine to simulate vehicle operations. The simulation controls use an API accessible in Python® and C++.

A complete CARLA simulation consists of client use case models, the server physics computations, and the user scripts that relate the two. The server components deal with the simulation rendering, computations, world-state, and actor. The client manages the behavioral logic of the use case actors and the roadway setting.

Screenshot of a simulator shows a car turning left with C++ and Unreal Engine logos. This screenshot is interacting with user scripts, which is 4 different Python files.

Source: CARLA.

Figure 7. Illustration. Relationship between CARLA core simulator and Python® application programming interfaces.34

As described in the CARLA documentation,35 key features and elements of CARLA include the following:

  • Traffic manager. This component models the roadway environment using realistic physical behaviors of the ADS-equipped vehicle and other vehicles in the surrounding traffic.
  • Sensors. Cameras, red-green-blue (RGB) images, radar, light detection and ranging (LiDAR), and other sensors are modeled as specific actor objects attached to vehicles. This method enables data captured by those sensors in the model to be provided to the simulated vehicles and to be retrieved as output from the simulation.
  • Robot Operating System™ (ROS) bridge and Autoware implementation. The CARLA project provides integration with other development, simulation, and machine learning environments with bridges to the ROS and Autoware.
  • Open assets. The CARLA architecture enables modeling of roadway environments, including weather, through a library with templates for simulation actors and conditions.
  • Scenario runner. CARLA’s scenario component enables developing route models that can run iterative simulations to feed machine learning processes for ADS.

Data can be collected directly from the client in real time through the API. The API provides access to the simulated sensors and to measurements associated with the state of the environment, such as vehicle location, velocity, acceleration, traffic signal state, lane locations, and speed limits at any location. These measurements are essential to modeling realistic behavior.

Traffic laws and regulations can be modeled as part of the use case traffic environment through Python APIs and sent directly to the subject ADS-equipped vehicles. The vehicle control algorithms (i.e., motion or trajectory planning) will use this information to plan and implement maneuvers that comply with traffic laws and regulations as part of the dynamic world model created by the environment sensing module.

32 Uniform Vehicle Code (Alexandria, VA: National Committee on Uniform Traffic Laws and Ordinances, 2000), 134. [ Return to note 32. ]

33 FHWA, Manual on Uniform Traffic Control Devices for Streets and Highways (Washington, DC: USDOT, 2012). [ Return to note 33. ]

34 “CARLA,” CARLA Simulator, accessed May 18, 2020, https://carla.readthedocs.io/en/latest/start_introduction/. [ Return to note 34. ]

35 “CARLA,” https://carla.readthedocs.io/en/latest/start_introduction/. [ Return to note 35. ]