The data management implications of the Federal Automated Vehicles Policy
The recently published Department of Transportation (DOT) Federal Automated Vehicles Policy provides regulatory guidelines for autonomous – or self driving – vehicle development. While autonomous technologies have been rapidly advancing in recent years, regulatory laws had not kept pace. This policy resolves the regulatory uncertainty and provides a clear roadmap for deploying autonomous vehicles on public roadways. Autonomous vehicle developers will need a comprehensive data management plan in order to comply with DOT guidelines, pave the way for quick feature enhancements and updates, and provide for legal protection.
The operation of a fully autonomous vehicle creates and processes a large amount of data. Multiple cameras and sensors, including RADAR, LiDAR, SONAR, and GPS, are deployed on a single car to execute various sub-tasks in support of the overall driving task. While humans don’t have eyes in the back of their heads, autonomous vehicles have lots of “eyes” simultaneously looking in 360 degrees. Different types of sensors are designed for specific tasks and conditions, such as distance, lighting, weather, etc., and provide inputs for software algorithms to process and determine the appropriate vehicle response – i.e. acceleration, braking and steering. Test cars today can typically generate between 4 and 6 TBs of data daily, with some generating double that amount depending on the quantity of mounted devices and their resolutions.
The DOT policy includes guidance for 15 specific focus areas related to vehicle safety and asks manufacturers to submit a safety assessment letter defining how they are meeting each focus area. Manufacturers are expected to submit new safety assessment letters anytime a significant update is made, including software and hardware updates. It is incumbent upon the manufacturer to retain data and documents to support each safety assessment submission.
Three of the focus areas address the definition of vehicle automation functions. The first, vehicle Operational Design Domain (ODD), specifies the conditions the automated system is intended to operate within. This includes types of roads, speed, lighting, weather, and any other domain constraints. The second is Object and Event Detection and Response (OEDR) functions necessary to safely operate within the vehicle ODD; including under normal driving conditions as well as with unexpected hazards or events. And finally, Fall Back to a minimal risk condition defines vehicle performance when it encounters a system failure or if the vehicle encounters conditions outside its ODD, including human notification to take control and vehicle response if manual control doesn’t occur within the intended time frame.
Testing and validation
Testing and validation of performance is required to verify the vehicle can operate safely within its intended design parameters and will safely fall back to a minimum risk condition as needed. Testing will likely include a combination of simulation, on-track, and on-road elements. Anyone who drives today should appreciate that the amount of variables needed to validate the three automation functions listed above is not trivial. Having a good data management plan is critical to an efficient and effective validation process. As noted earlier, the data sets generated during vehicle testing can be very large. In-vehicle data storage must accommodate uninterrupted test cycles and vehicle environmental conditions, which exceed those of a typical data center. Ensuring data is readily accessible by the engineering team is the lifeblood of the development process. Prompt access to new test data as well as access to older data for back testing is equally important. Manufacturers will need a plan to meet the capacity and performance requirements of the active testing and development processes, while also providing access to a large capacity store for longer-term.
Data recording and sharing
According to the policy, manufacturers should retain data from testing and operational events and ensure it remains readily retrievable by the manufacturer and by DOT for crash reconstruction. DOT recommends collecting data in the event of a crash with injuries or fatalities, when vehicles are damaged such that towing is required, and in cases of “near misses” where the vehicle responded favorably. In these cases the vehicles should retain enough data to reconstruct the event and system performance, including whether the system or a human driver was in control of the car. The policy states manufacturers should have technical and legal capability of sharing any relevant data. The policy also encourages the industry to work together with standards organizations to establish a uniform approach to data recording and sharing.
Putting it all together
The development and the operation of autonomous vehicles are both data intensive processes requiring a comprehensive data management plan. It’s imperative that manufacturers have well-defined processes and access to data for system enhancements as more vehicles are deployed and when the inevitable events occur placing the automated system performance into question. The potential legal issues put greater responsibilities on manufacturers, since the vehicle’s automated systems are responsible for driving the cars, not the humans. A well designed data management plan will benefit the vehicle manufacturers’ ability to advance the technology and to respond promptly and to new events, ultimately improving vehicle performance and safety.
- » Augury listens in to detect if your thing is going to break
- » IoT predictions for 2017: Big data, orchestration, standardisation, and more
- » Brazil to focus on smart lighting with Gooee and Lumicenter partnership
- » IDC: Spend on the IoT will reach $1.29 trillion by 2020
- » HARMAN launches Ignite to manage in-car apps and their IoT communications