Chapter 5. Use Cases

Use cases are used to describe the applications and interactions of stakeholders with the proposed framework, including its relationship to potential operational design domains (ODD) for the ADS-equipped vehicles. Use cases generally need to address perspectives of specific stakeholder groups (e.g., automated driving system [ADS] developers, regulators) as they relate to the system being described or developed. In this case, there are at least two possible views of the system. The most specific view would be that the system in question is the data framework for traffic regulations. That may, however, be insufficient to meet the implied intent of the framework, which is to provide ADS developers with a view of traffic regulations that will be useful in development and deployment of automated vehicles (AV). A more nuanced view of the potential use cases has (at least) two layers: use cases for the framework itself, addressing the perspectives of providers as well as users of the regulations data, and use cases for the regulations data within the framework, focused on the needs of ADS developers. Uses cases for the framework are conditional on use cases for the regulations data. If the data and the way they are represented are not useful in ADS development and operations, the framework itself is not useful.

To that end, the ongoing evolution of ADS and the AV ecosystem suggests a phased approach to the capture, management, and provision of regulations data:

1. Early-stage ADS and AV development is focused on research and demonstration in operational design domains (ODD) selected by the developers. These ODDs are necessarily constrained so that developers can successfully demonstrate automated operations. As such, the ODDs are limited to particular classes of roadways, interactions with other vehicles and other users, and jurisdictions. Developers need to know only the regulations that apply to those particular contexts. It is probably sufficient in this phase to focus on use cases around capture of and access to the enacted traffic regulations for jurisdictions in which the ADS intends to be operating.
2. Traffic controls serve as reminders of and specific pointers to traffic regulations as they apply on the roadways. ADS operations on public roadways will need to have at least sufficient awareness of traffic controls so as to limit their operations to the ODDs for which they are designed. Adding traffic control types to be expected in particular jurisdictions expands the regulations framework so that potential ADS deployments have access to a library of traffic controls that they might encounter and need to understand in those jurisdictions. This library then serves as a reference for further expansion of ODDs to include a broader range of maneuvers and control types.
3. There was a diversity of opinion among interviewed stakeholders as to how regulations (and updates to them) might be provided to AVs. The consensus was that an ADS would need to be able to depend on its sensors to identify deployed traffic controls, but there was a parallel awareness that traffic control locations might also be digitally mapped and provided to ADS-equipped vehicles. This is not a novel idea; it is essentially the concept behind the MAP and Signal Phase and Timing (SPaT) messages defined in the Society of Automotive Engineers (SAE International) J2735™ standard for vehicle-to-infrastructure (V2I) messaging. Mapping deployed traffic controls, especially where the control state or parameter is variable—for example, at traffic signals or with variable speed limits—enables the regulations framework to provide dynamic as well as static regulations data.
4. Traffic statutes as written and enacted in the State and local traffic codes use natural human language to describe their intents. Interpreting those regulations for an ADS must render that intent into a set of instruction based on actors, actions (or maneuvers), and constraints on those actions. The most direct implementation of those interpretations is to hard code the rules of maneuvers needed for the ADS ODDs into the ADS. Much of the concern around variability in traffic regulations derives from the lack of scalability in this approach. It is prescriptive rather than adaptive. Moving beyond this type of implementation will require a data-based representation of the regulation. That interpretative component or database might reside onboard the vehicle, but it could be part of the regulatory framework.

Use cases will be used later in this project to support additional tasks. A demonstration of the framework interfacing with an ADS simulation will address use cases for the framework as they apply to a specific ODD to be defined for that demonstration. Developing a test plan for use in a subsequent framework pilot deployment will need to consider the use cases as part of that planning.

Framework Use Cases

The framework-level use cases describe the interactions with the framework as a whole and may be specific to particular groups of stakeholders. The use case descriptions are intended to be functional and are not meant to imply particular prototype implementations.

Provide Regulations

The regulations framework will respond to a request for regulations with the text of traffic regulations based on jurisdiction or location. Requests are anticipated to come from human ADS developers. As a pre-condition, the text will have been loaded into the framework with its associated jurisdiction, statutory references, and dates of applicability (if appropriate). The response will result in a text report of the regulations being provided to the requestor.

Provide Traffic Control Types

The regulations framework will respond to a request for potentially applicable traffic controls with the names of the control types, the Manual on Uniform Traffic Control Devices (MUTCD) or State and local references, and marking/sign images based on jurisdiction or location. Requests are anticipated to come from human ADS developers. As a pre-condition, the traffic controls will have been loaded into the framework with associated jurisdiction, references, images, and dates of applicability (if appropriate). The response will result in a text report and graphics files for the traffic control types being provided to the requestor.

Provide Deployed Traffic Controls

The regulations framework will respond to a request for deployed traffic controls with the names of the deployed traffic controls, MUTCD or State and local references, and specific location and attributes based on jurisdiction or general location. Requests are anticipated to come from automated systems, or ADS developers using a manual command. As a pre-condition, the deployed traffic controls will have been loaded into the framework with associated types, locations, and dates of applicability (if appropriate). The response will result in a text report and graphics files for the traffic control types being provided to the requestor.

Provide Interpreted Regulations

The regulations framework will respond to a request for interpreted regulations with data describing maneuvers, actor(s), and applicable constraints equivalent to regulations within a jurisdiction or applicable at a location. Requests are anticipated to come from automated systems. As a pre-condition, the regulation will have been interpreted and loaded into the framework with its associated jurisdiction, statutory references, and dates of applicability (if appropriate). The response will result in digital representation of the regulation being provided to the requestor.

ADS Development Use Cases

The fundamental question for the use cases to address is how the regulations framework can inform and represent regulatory constraints on ADS behavior in traffic. The regulations themselves were set up for human drivers based on situations that drivers would be encountering as they proceeded along the roadways. To that extent, the regulations generally align with use cases for driver behavior. However, the use cases approached in this way do not necessarily line up with the concept of ODDs. Thus far, individual ADS development teams have identified and described ODDs without particular regard to standard or systematic ways of assuring that they would eventually address all regulations, use cases, and development needs. As such, it is not possible in the scope of this effort to provide a complete mapping of use cases to ODDs. However, it does appear that use cases based on regulations can be allocated and considered in the definition and scoping of ODDs as they are developed.

It is then reasonable from a regulatory perspective to define use cases for ADS development based on the actors and actions (or maneuvers) described in the regulations themselves. Although the regulations vary among State and local traffic codes, the fundamental driving behaviors are substantially the same. Variability among traffic codes in the United States is primarily in the extents and limits placed on the maneuvers, not on the mechanics. Making a right turn at a signalized intersection is fundamentally the same driving task regardless of whether the maneuver takes place in Connecticut or California. The regulatory differences (if any) lie in the circumstances and constraints under which that right turn is allowed.

Since there is generally structural agreement among the various traffic codes on the descriptions of maneuvers, it is reasonable to use the UVC as a basis for identifying the ADS development use cases for the regulatory data framework. Variability in the traffic codes for particular use cases would then be parameterized to capture the jurisdictional differences. Table 1 suggests classes of use cases based on the sections (Articles) within Chapter 11 of the UVC.

Table 1. Classes of use case based on the Uniform Vehicle Code.

Potential Classes of Use Case [with UVC Section Title]	References
General Traffic Reg Compliance [Obedience to and Effect of Traffic Laws]	UVC Ch. 11 Article I
Interpretation of and Compliance to Traffic Controls [Traffic Control Devices]	UVC Ch. 11 Article II, MUTCD
Work Zones	MUTCD
Incidents and Emergency Operations	UVC Ch. 11 various articles
Highways [Driving on Right Side of Roadway – Overtaking and Passing – Use of Roadway]	UVC Ch. 11 Article III
Intersections [Right of way]	UVC Ch. 11 Article IV
Intersections [Turning and Starting and Signals on Stopping and Turning]	UVC Ch. 11 Article VI
Special Stops Required	UVC Ch. 11 Article VII
Speed Restrictions	UVC Ch. 11 Article VIII
Stopping, Standing, and Parking	UVC Ch. 11 Article X
Miscellaneous Rules	UVC Ch. 11 Article XI
Faulted Operations [DUI and other Serious Traffic Offenses]	UVC Ch. 11 Article IX
Pedestrians' Rights and Duties	UVC Ch. 11 Article V

Source: FHWA
Ch. = chapter, DUI = driving under the influence, MUTCD = Manual on Uniform Traffic Control Devices, UVC = Uniform Vehicle Code.

A complete list of ADS development use cases based on the UVC and its State and local variations would entail a review of all those traffic codes to identify degrees of variability and edge cases. As that type of review is beyond the scope of this study, typical cases that might be used in demonstrating the framework are suggested here. The emphasis is nonetheless on cases that need data that vary among jurisdictions. The focus of the use case is on the availability of traffic regulation and control data to the ADS, not on the design or implementation of algorithms within the ADS. The key questions are: Can the ADS determine constraints on maneuvers (regulations) applicable to the jurisdiction in which it is operating at the moment of decision?

Can the ADS recognize the traffic controls it encounters in its local operations? These and other similar questions will become part of the basis for the proof-of-concept demonstration and the framework testing plan.

Comply with Speed Limits

An ADS-equipped vehicle moves along a roadway with no apparent local indication of the speed limit and crosses the boundary with an adjacent jurisdiction, also without a posted speed limit. The ADS will have a local database of speed limits for the jurisdictions in which it expects to operate, or will have remote access to a service providing the speed limit data. As the vehicle approaches the boundary, the ADS will query the database/server to determine the speed limit with which it needs to comply. The ADS will then change the vehicle speed as appropriate to remain within the locally applicable limit.

Comply with Left-Turn Controls at Signalized Intersections

An ADS-equipped vehicle approaches a signalized intersection and moves into the left-turn lane. The ADS recognizes the red signal and stops at the stop line. The ADS monitors the signal status and initiates movement through the intersection when allowed by the green left arrow on the signal. It proceeds along that roadway to an intersection coincident with the boundary with an adjacent jurisdiction. The vehicle moves into the left-turn lane. The signal is indicating a flashing amber left-turn arrow. In this use case, the ADS will need to have information and algorithms for left-turn traffic controls in both jurisdictions. The ADS monitors oncoming vehicle and local pedestrian traffic to determine a safe interval for completing the left turn. The vehicle completes its left turn and proceeds along the new roadway.

Comply with Right-Turn-on-Red Regulations at Signalized Intersections

An ADS-equipped vehicle approaches a signalized intersection with the intent of turning right. The signal is red, and the vehicle stops at the stop line. The ADS queries whether a right turn on a red signal is permitted in this jurisdiction. There is no sign indicating that a right turn on red is not permitted at this location. If the right turn on red is permitted, the ADS monitors oncoming vehicle and local pedestrian traffic to determine a safe interval for completing the right turn. The vehicle completes its turn and proceeds along the new roadway.

As a variant use case, the ADS-equipped vehicle will approach a signalized intersection where right turn on red is not permitted, as signed at the intersection. The ADS monitors the traffic signal, oncoming vehicles, and local pedestrian traffic to determine a safe interval for completing the right turn. The vehicle completes its turn and proceeds along the new roadway.

Identify and Comply with Non-standard Pedestrian Crosswalk

An ADS-equipped vehicle approaches a signalized intersection with the intent of turning right at the intersection. The signal is red, and the vehicle stops at the stop line. The pedestrian crosswalk does not have the standard pavement markings or pedestrian crossing signs expected for this jurisdiction (Figure 8). The ADS must monitor the traffic signal, vehicle cross-traffic, and the atypical presence of pedestrians to determine a safe interval for completing the right turn. The vehicle completes its turn and proceeds along the new roadway.

Comply with Non-specific Headway Regulations on Highway

An ADS-equipped vehicle is moving along a highway and approaches a vehicle ahead of it that is moving more slowly. There is no opportunity to legally pass the slow vehicle on the left (or right). The local regulations do not specify a minimum following distance or time interval. Due to the subjective nature of safe following distance, a law enforcement officer could pull over an ADS if the officer determines the following interval set by the ADS’s algorithm is too close for conditions.

Comply with Regulations on School Bus Interactions

An AV is moving along a single-lane highway and approaches a school bus ahead of it that is stopped in the lane. The ADS does not detect any pedestrians in its path or along the edges of the roadway. The ADS queries its regulations database to determine the constraints on its maneuvers in the jurisdiction through which it is traveling. Are there stop signs being extended by the bus? Are there flashing red indicators on the bus? Is the ADS required in this jurisdiction to stop behind the bus and proceed only after the bus has moved and no pedestrians are detected? Is the ADS allowed to pass the bus on the left if there are no stop indications on the bus and there are no pedestrians detected?