Chapter 6. Implications for Implementation

This concept of use (COU) describes the need and concepts for the design of a traffic regulations framework to support automated driving system (ADS) development and deployment. However, the implications of those concepts and design may represent challenges for prototype implementation. This section assesses the implications of the proposed approach relative to design and deployment, testing, system operations and maintenance, revision control, system performance measures, security and privacy, and future considerations for new technology.

Design and Deployment

Vehicle Function Regulations

Some traffic laws imply required vehicle equipment or functions. For example, some States require the use of windshield wipers when it rains, which implies that the vehicle must be equipped with wipers. The study authors assume that the original equipment manufacturer (OEM) responsible for the vehicle using the ADS will comply with all Federal motor vehicle safety standards (FMVSS) or exemption specifications for safety systems, equipment, and performance as the National Highway Traffic Safety Administration (NHTSA) requires. However, FMVSS are being updated in response to ADS needs, which makes the FMVSS another evolving list of requirements that OEMs must track as changes are made. This is significant for the demonstration use case only to the extent that the vehicles are equipped as needed to complete the use case.

Regulations Data Access and Collection

As described previously, State traffic codes are generally available and able to be collected from the regulatory sources, though not necessarily in forms convenient for developing a database. Local government codes are unlikely to be so readily available and will present additional challenges for identification and collection. Data on regulatory traffic controls within a jurisdiction are significantly less available in database form, though the traffic controls are generally observable in field deployments. As such, a prototype demonstration may be constrained to specific examples of regulations and their variation across jurisdictions.

Limitations in Matching Regulations and Traffic Control Devices with Automated Driving System Behavior

Traffic codes are written for human interpretation and application and may face challenges in being interpreted for ADS. The interpretation will need to identify specific driving tasks and maneuvers and different roadway environments and scenarios in which the regulations apply, and specify the operational limits associated with those tasks. Similarly, traffic control devices are currently deployed as marked or signed indications along roadways. Conceptually, an ADS will need to be able to identify the applicable regulations and roadside control devices from its own imaging systems, static controls associated with mapped locations, or static and dynamic control data provided in infrastructure-to-vehicle (I2V) exchanges. For use case demonstrations, any traffic control devices to be recognized by the ADS will need to be catalogued and known to the vehicle for matching with its perceptions, mappings, or traffic control messages.

Coordination across Jurisdictions

Just as human drivers need to know the rules of the road in the various jurisdictions through which they travel, an ADS will need to be aware of its current location and the applicable regulations. In practice, much of the local variability will take the form of signed controls on the roadway. Some allowed behaviors and constraints, however—like right turn on red or speed limits based on road classification—are permissible unless otherwise precluded by an explicit traffic control indication. Use case demonstrations will need to accommodate and demonstrate the regulations framework’s requirements for working across jurisdictions.

Testing

Technology testing is an integral part of deployment and represents the process of analyzing a system or component by providing defined inputs and comparing the results with the desired outputs.

In this context, testing can have variable degrees of manual testing and automation. Manual testing requires human input, analysis, and evaluation. Automated testing uses automated steps to reduce human errors in the testing process. These errors may occur due to humans getting tired of a repeated process, while automated testing will not miss a test by mistake. The automated test program will also provide the means of accurately storing test results, which can be fed into a database that provides necessary statistics on how the new data system is performing. Automated testing can detect errors in the database, which may have a major impact on ADS traffic law compliance and affect ADS behavior and safety.

Objectives of automated testing are as follows:

• Perform repetitive and tedious tasks to accurately reproduce tests.
• Validate requirements and functionality at various levels.
• Simulate multiple users exercising system functionality.
• Execute more tests in a short amount of time.
• Reduce test team head count.

System Operations and Maintenance

There are many independent and overlapping jurisdictions with governing bodies that can independently enact statutes and interpret regulations to facilitate the safe use of common transportation infrastructure. The result is that an ADS regulations system will benefit from being decentralized, regardless of choosing traditional relational database management with replication, durable stream processing, blockchain distributed ledger, or other similar technology.

Diffusing system implementation provides valuable benefits. No single agency is burdened with the expense of hosting and maintaining communication infrastructure as well as propagating data updates. The large complex problem of interpreting regulations is broken into the optimal effort encouraging participation. System responsiveness and resilience is maximized by keeping information consumers as close as possible to information producers with no single points of disruption.

Revision Control

The ADS regulations system contains information elements that can change somewhat frequently (traffic control instances and traffic control types), and much less frequently (statutes, regulations, the Manual on Uniform Traffic Control Devices [MUTCD], published traffic engineering standards). The mechanism to handle changes is the same. System records maintain a time range over which they are considered valid and references to previously superseded entries. There is also a transaction log that stores what information was changed, when it was changed, and who changed it.

Developed software follows common open-source version-control practice. Design documentation, deployment and administration documentation, and source code will be uploaded and maintained through the Open Source Application Development Portal (OSADP) GitHub process.

System Performance Measures

Web applications handling millions of transactions every day are commonplace. Human-scale interaction with the system will meet present day user expectations of a few seconds to update data, and receive report output. Timing for user interface elements can be monitored using many available log analysis tools.

An estimate of record count can be determined from the number of jurisdictions, number of regulations per jurisdiction, and number of traffic controls. If an average of three traffic controls (i.e., actuated signal, speed limit sign, mile marker, left- and right-lane markings) exist per road mile in each direction, then approximately 24 million total traffic controls exist. On the low end, there could be 50 jurisdictions with 1,000 regulations totaling 50,000 records. On the high end, there could be 10,000 jurisdictions with 10,000 regulations totaling 100 million records. Current transaction processing software and data storage hardware is handily capable of sustaining 200 million records.

The key system performance indicator is more closely related to the instantaneous demand for traffic regulation information by ADS, i.e., queries per second. It would be truly spectacular if 300 million vehicles simultaneously requested 200 million records—and totally unnecessary. Distributed deployments mitigate this situation.

ADS-equipped vehicles in New Mexico do not need traffic control information about West Virginia, for example. Each ADS-equipped vehicle does not even need every traffic control defined by a given jurisdiction. An automated vehicle (AV) does need traffic control information for its planned route, which it monitors many times per second but updates every few minutes.

System implementations will support delta queries that quickly determine what has changed since the ADS’s last local database update, and subsequently deliver the reduced set of traffic control differences. In a simplistic model, if an average response is 100 kilobit (Kbits), then one service node having 1 gigabit per second (Gbit/s) communication bandwidth can handle 10,000 traffic control queries per second. This is the equivalent of meeting the immediate needs for every vehicle within the State of Virginia or within New York City in under 10 minutes, and is well within the performance capabilities of contemporary online transaction processing software.

Security and Privacy Considerations for an Automated Driving System Traffic Regulation Ecosystem

For any advanced data system, many of the primary ownership and maintenance (O&M) considerations involve the management and security of data. The Federal Highway Administration (FHWA) Reliability Data Guide’s section on Data Ownership and Maintenance³⁶ presented a sample list of fundamental considerations likely to govern O&M levels of effort and expense:

• Who will pay to collect, store, and share the data?
• Who (if anyone) can sell the data, and to whom may it be sold?
• Are there any privacy issues in the data that must be addressed?
• Who is allowed to access the data, and what data may they access (all of it? only a subset?)?
• What purposes are the data allowed to be used for (e.g., if they are collected for analysis purposes only, could they also be used for enforcement?)?

The Real-Time Data Capture and Management State of the Practice Assessment and Innovations Scan³⁷ addressed issues related to data capture, data management, archiving, and sharing collected data to encourage collaboration, research, and operational development and improvement. The scan documented the following best practices for access, security, and privacy:

• Generally, the holder of the data controls access to them. Within the transportation and logistics community, this access is carefully controlled.
• There are systems in place that ensure that data can be accessed only by the intended people and only to the degree that they need it. The type of data used by the transportation and logistics industry makes it extremely sensitive, with disastrous consequences for a business if accessed by persons with malicious intentions.
• Usually, data access is password-protected, and the following is true:
  • Because data generated within the logistics systems are often financial, strong encryption is placed on such data when they are sent.
  • However, several applications can retrieve aircraft and vessel tracking data, often with other identifying information. The security clearance or password protection to access data through these applications is often minimal.
• The protection of data sources is extremely important. In the search engine industry, it is so heavily protected that there is not even disclosure of how exactly it is protected.

The scan documented the following best practices for data storage and backup:

• Frequent backups and off-site storage are typical.
• Preventative maintenance should be performed regularly.
• Careful consideration should be devoted to determining how much and for how long data should be stored. In aviation, for instance, data are kept for a relatively short time frame because the need is for real-time rather than historical information. At the same time, data can be available for revision if there is an incident to investigate.

The scan documented the following best practices for operations and maintenance:

• Deployment should be started on a reasonable scale, such as implementing in a small geographical area or using easily manageable data.
• Multiple servers should be used to distribute real-time loads. Several technologies enable this load distribution.
• It is important to consider determining the needed resolution or granularity of the data. This may vary depending on the context and use of the data.
• It is necessary to determine what is critical to communicate and what is not. For instance, railroad and airline alert systems only collect the necessary data that can alert an operator of a particular problem.

The scan documented the following best practice for critical failures:

• A common issue is that correcting a problem is often dependent on a single person, meaning its solution depends on the person’s availability. It is therefore important to have staff available around the clock to solve potentially catastrophic failures. The higher labor cost is a necessary expense if the system needs to be highly available at all times.

Future Considerations

As described in the introduction to this COU, the field of ADS is in its early stages of development. Attention to regulations for ADS-equipped vehicles has been largely structured around allowances and permits for testing in various jurisdictions. Legal reviews of the applicability of existing rules of the road to AVs are just beginning.

The ADS regulations framework described in this COU will therefore be designed to link directly back to the actual traffic regulations in the contributing jurisdictions to provide traceability and a path for adding new regulations as they are enacted.

The framework is similarly designed to facilitate adding new traffic control types and deployments, should those become desirable or necessary. The components that catalog deployed traffic control elements are designed to support a virtual traffic controls infrastructure if that interface were to be requested by ADS developers and deployers.

Parametric interpretation of the traffic statutes is included in the framework design for prototype demonstration and for future development. A fully implemented translation of Federal, State, and local statutes into parametric forms may be achievable, but it is beyond the scope of this prototype effort.