Autonomous vehicles are threatening to disrupt the automotive, aerospace, and industrial equipment industries with the emergence of self-driving cars. They promise to drastically reduce accidents, minimize congestion, bring mobility to the immobile, and perform mundane or hazardous tasks in a fraction of the time required by human-controlled vehicles. This opportunity is open to traditional industry players as well as new entrants, particularly from the high-tech sector.
Ultimately, for an autonomous vehicle to be accepted and certified for widespread use, its software must be verified and validated as being as safe or safer than a human equivalent. This requirement can be quantified statistically. A study by RAND4 revealed that in typical cases it would take between 8 billion and 11 billion miles of road testing over a period of 400 to 500 years to demonstrate the safety of autonomous cars to appropriate levels of statistical confidence. Clearly this is not practical. Simulating miles driven is the only feasible way to overcome this limitation, so companies have turned to simulation.
Waymo, a division of Alphabet Inc. and one of the front-runners in the race, reported the impact that simulation is making in its development efforts.1 This is summarized in Fig. 1.
1. The unrivalled power of simulating miles driven: the only way to market for an autonomous vehicle.1
While physical road testing and scenarios where the original situation has been replayed with a perturbation have an important role to play in the overall safety demonstration process, simulations that provide an accurate interpretation of the physical reality of the autonomous vehicle and its environment to validate performance against safety requirements are the only practical way to market.
Open- and Closed-Loop Simulation
Besides the already-complex systems on board today’s vehicles, components that make a vehicle autonomous are sensors (radar, lidar, cameras, etc.); electronics and semiconductors; and software and actuators. Designing and developing these components requires high-fidelity, physics-based simulations conducted in an open-loop environment. Such simulations ensure that the performance of the sensor and its interaction with the environment is captured in the most accurate way possible.
They also ensure that in the real world, these sensors perform as expected and are able to survive the harsh operational environment they will be exposed to. Likewise, the embedded software associated with these devices can be developed with model-based methods and verified via simulation, speeding up compliance with standards such as ISO 26262 in automotive and DO-178C in aerospace applications.
In a closed-loop simulation, a virtual representation of the autonomous vehicle, complete with high-fidelity virtual sensors and actuators, is placed in a virtual environment and driven by the same software as the real-world autonomous vehicle. As the vehicle drives in this environment, accurate sensor models replicate what the vehicle will “see” in the real world; the perception, localization, planning and execution software drives the car as it would in the real world. Multiple virtual autonomous vehicles can be driven for millions of miles in this virtual environment in a much faster, safer, and economic way when compared with road tests.
Developing Autonomous Vehicle Software
The embedded software responsible for perception, localization, motion planning, and motion execution is the brain of the autonomous vehicle. Artificial intelligence (AI), machine learning (ML), and deep learning (DL) are key techniques being used to create the brain of the vehicle. However, being non-deterministic, these techniques face significant challenges:
- There is a lack of clear traceability between the outputs of the algorithms and the functional safety requirements of the system
- Complying with accepted best practices for high-integrity, safety-critical software such as model based systems engineering (MBSE), safety analyses, and certified code generation.
A solution to these challenges is the Command-Monitor (or COM-MON) architecture. A simple analogy can be made to the left and right sides of the brain. The command side—equivalent to the creative left side of the brain—contains the AI/ML/DL algorithms and is in normal control of the vehicle, responding creatively to the demands placed upon it. However, should the command side fail by instructing a dangerous operation, the monitor side takes over and produces a short-duration mission that ends in a safe state. This is the equivalent of the logical right side of the human brain taking over. The monitor side is developed using best practices for safety-critical software engineering and functional safety analysis.
According to Intel, “a flood of data is coming”5 as a result of the shift to autonomous vehicles. A single autonomous car will generate 4,000 GB of data per day. This figure grows significantly higher when the physical world data from the car are combined with the virtual world and virtual sensor data generated through the simulated experience. Managing and mining these data to derive actionable insight and connecting to the open-loop and closed-loop vehicle simulations are fundamental capabilities for the successful simulation of miles driven.
Simulating Autonomous Vehicles Miles Driven
Delivering the promise of autonomous vehicles means validating performance against safety through simulation. This requires connecting the software brain of the vehicle to open-loop and closed-loop vehicle and environment simulations, and managing vast quantities of physical and virtual data. It also requires bringing hardware components into the simulation loop and adapting to specific development environments, vehicle architectures, and network connections. In short, it means a solution that is open and that can be configured to the end user’s requirements
This requires building a comprehensive solution for simulating autonomous vehicle miles driven. This solution is open and configurable to validate vehicle performance against safety requirements through simulated miles driven. Its open nature integrates an ecosystem that includes, but is not limited to, high-fidelity physics, sensor models, vehicle dynamics, world scenarios, embedded software, connectivity, data analytics, and functional safety analysis. It can be configured to a given development environment, hardware-in-the-loop requirements, and vehicle architecture. The solution is shown schematically in Fig. 2.
2. Illustration of the ANSYS comprehensive solution for simulating autonomous vehicles miles driven.
Simulating the Components
Assessing the overall system is required to demonstrate safety through simulated miles driven. However, simulation also plays a key role in the design and development of the discrete components of the vehicles that enable autonomy. A self-driving car contains a number of these common components that benefit from simulation. Accurate capabilities with component accuracy is the foundation for the demonstration of safety in the overall system representation.
Simulation plays a fundamental role in the development of radar, lidar, camera, and ultrasonic sensors as well as GPS and V2X systems. This extends from sensor module design, to studying the module’s installed performance on the vehicle, to understanding what the sensor reports for moving and stationary targets on a full, dynamic scene. In Fig. 2’s left image, we see the relative motion of vehicles at an intersection. The above right image shows how simulation can be used to assess the complexity and effectiveness of a radar on one of the vehicles.
Semiconductors are evolving rapidly to support the specific needs of autonomous vehicles, pushing the limits of system reliability. Increased functionality and power density in next-generation GaN or SiC designs can lead to self-heating of the devices and Joule heating of the wires, causing wide variations in on-chip temperatures. Higher temperature, higher current, and higher resistances are pushing the limit for electromigration (EM) and electrostatic discharge (ESD) failures on-chip.
In addition, advanced 2.5/3D and wafer-level packaging technologies are bringing the die and wafer together while creating more thermal hot spots that can impact both the chip- and system-level EM and ESD. This requires a comprehensive, thermal-aware EM solution that models self-heat effects and overall junction temperature variation of the die for accurate signoff. ESD integrity analysis from the device level—all the way to IO, IP. and SoC—is also provided, along with modeling capabilities for IO and IP for SoC level analysis and full-chip modeling capability for system-level ESD verification and signoff.
The requirements for robust performance of electronic systems on the vehicle from the chip all the way to the installed sensor places new demands on the reliability of the electronics system. This requires a simulation-driven chip-package-system (CPS) development methodology that is multiscale, Multiphysics, and multi-user.
The methodology is multiscale in that it provides simulation technologies that range from the nanometer scale, used in IC and other chip designs, to the meter scale of autonomous vehicles. Multiphysics solutions can simulate various physical phenomena across chips, packages and systems, including power optimization, signal power and thermal integrity, electrostatic discharge (ESD), electromagnetic interference/electromagnetic compatibility (EMI/EMC), heat transfer, fluid dynamics, and structural mechanics.
The multi-user aspect enables chip, package, and system designers to use the simulation platform to simulate and collaborate on various physical phenomenon to create increasingly complex products.
With more electronics comes more software. Ensuring the reliability of the embedded software code within systems becomes critical to the safety of passengers and pedestrians. The development of an ISO 26262-qualified code generator helps automotive OEMs and suppliers drastically reduce development costs while ensuring that their embedded software applications will meet stringent safety standards. The same is true for DO-178C in aerospace. ANSYS SCADE tools provide a code generator that is part of a model-based design solution in which modeling and simulation are used throughout the product development lifecycle as the authoritative definition and verification of the product design.
Engineers at Piaggio Aerospace, a multinational aerospace manufacturing company headquartered in Villanova d’Albenga (Liguria), Italy, were tasked with developing a new P.1HH HammerHead unmanned aerial vehicle (UAV). This required developing approximately 300,000 lines of code for the vehicle control and management system (VCMS)—the digital infrastructure performing aircraft command and control — which had to meet DO-178B standards.
ANSYS SCADE was selected as the development environment for the VCMS, since SCADE automatically generates source code from the model and minimizes the effort required to verify that the source code corresponds to the system model. The SCADE KCG code generator is qualified as a DO-178B development tool, so conformance of the code to the input model is trusted, eliminating the need for verification activities related to the coding phase. The project was completed in only 18 months. The VCMS was developed and verified in an estimated one-third the time that would have been required had the code been handwritten.
Whether you are designing and developing a component, a subsystem, or an entire autonomous vehicle, simulation is the key to winning the race to market. This requires leveraging a history of high-fidelity simulations for component, subsystem, and system design to build a comprehensive solution for simulating autonomous vehicle miles driven, flown, or maneuvered.
- On the Road to Fully Self-Driving, WAYMO Safety Report, 2017
- http://www.businesswire.com/news/home/20170711005684/ en/126.8-Billion-Autonomous-Vehicle-Market-2017-2023--
- RAND Corporation, Driving to Safety: How Many Miles of Driving Would it Take to Demonstrate Autonomous Vehicle Reliability?, Kalra and Paddock, 2016