Who is Driving Autonomous Cars Anyway?

In this Industry Article, Mark Forbes of Altium explores the problems, solutions, and safety standards surrounding autonomous vehicles.

As we are on the threshold of becoming more “passenger” than “driver” in our vehicles, the question of “how safe is this ‘thing’ driving me around?” starts nagging the neurons. We all acknowledge intellectually that in most situations, automation can probably make the correct decision more quickly than a (potentially distracted) human driver. But what if it fails?
Is the hardware that’s being designed and manufactured to be the “smarts” of autonomous vehicles designed for safety first? The hardware must not only be reliable but also able to detect faults and take corrective (or emergency) actions. The hardware must also assure that protected memory, used for safety-critical purposes, is never touched by unauthorized requestors.
Are embedded software developers paying enough attention to safety concerns? I’m certain that the overwhelming majority make it a top priority. However, there are some standards that can help developers assure that their code is not only safe as written but is likewise safe after compilation and when it runs on the target hardware.

Some Vehicles Have Been Autonomous for Years

Because of all the press surrounding the soon-to-be-realized autonomously driven cars, many people think that is the first foray into self-driving vehicles. In fact, they have been around for quite a while, just not in consumer environments.

Figure 1. Autonomous vehicles like this self-driving lawn mower have been around for some time. Their operating environment is much different from what autonomous cars will encounter.

John Deere began the foundational work for self-driving tractors in the 1990s and had tractors making turns by themselves by 2000. Now, the tractors are capable of complete autonomous operation, including plowing and harvesting, in addition to making turns. Other autonomous vehicles in widespread use are the “product pickers” used by many online retailers and wholesalers. Amazon, for example, operated more than 45,000 of these robots at the beginning of 2017.

Your Next Car?

Despite the decades of work by robotics and tractor companies, your next car is not likely to be self-driving. There is a laundry list of items that have very different problems than the autonomous vehicles mentioned earlier, but at the top of that list is one simple fact – warehouses, your home, and farms are private, controlled access environments, whereas automobile travel entails a completely different set of problems to address:

• Traffic: Of course, traffic is the most frequently encountered problem that doesn’t affect tractors and robots. Cars must first detect and then determine what to do in response to the sensed information.
• Signal interference: Out in the big world, things like buildings and trees can interfere with sensor signals and create unexpected results.
• Hacking: Secure internet communication is necessary for autonomous cars for applications such as over-the-air software updates. Hacking could potentially be deadly.
• Unexpected experience: Perhaps the most nefarious problem is what decision should be made when a new, unexpected experience occurs. In a tractor or robot, it could just stop, but in a car, that might not be the safest thing to do.

All of these existing problems must be addressed for one reason: people are riding in the cars so safety has to be the absolute number one priority.
For decades, cars have had integrated electronics and embedded software for things such as powertrain control, transmission control and fuel injection. Now, Advanced Driver Assistance Systems (ADAS) such as intelligent cruise control and lane departure warnings are beginning to show up in vehicles, which are baby steps toward autonomy. While there are safety issues that have been dealt with in powertrain control, the risk to human life that ADAS failures could cause has driven several standards to be developed to mitigate that risk as much as possible.

Standards Ensure Safety and Interoperability

The primary standard relating to autonomous automobiles is ISO 26262. Its purpose is to ensure proper safety management throughout automotive systems. Part of ISO 26262 is a prioritized set of Automotive Safety Integrity Level (ASIL) classifications. The ASIL level classification is set by the severity of the harm that could result from a failure of the hardware (or software controlling the hardware) in different scenarios, and run from A (least stringent) to D (most stringent).
Compliance with ISO 26262 requires that hardware and software be designed for safety, such as using fallback paths, self-monitoring and redundancy. Hardware is required to be tested according to the ASIL level in which it is operating. Hardware or software that does not impact any safety-critical function (for example the GUI for a car’s touch screen) have a lower ASIL classification than ADAS functions that can have a significant impact on safety. Because ADAS functions make high-level decisions for the driver, they usually must be certified to a high ASIL classification, such as ASIL-D.

Figure 2. ASIL compliance levels assess the potential danger of a failure. Level A has marginal safety issues whereas Level D is likely to result in multiple fatalities and major injuries.

That means that getting safety certification of an ADAS product can take quite a long time. The logical way to reduce the time and cost to get certification is to use hardware that has been pre-certified and software development tools (such as compilers and performance libraries like LAPACK) to make full-system-level ISO 26262 certification more expedient and raise the level of safety.
There is a standard for software development as well. Automotive SPICE (ASPICE) is a standard framework for designing and assessing automotive software development processes. Effective implementations lead to better processes and better product quality.

Figure 3. Using safety-certified hardware and software development tools can expedite system certification.

One other standard that bears mentioning is IEEE 2020. This standard is currently in draft form. It specifies methods and metrics for measuring and testing the quality of automotive images to ensure consistency and create cross-industry reference points. This is a future-looking standard that is not yet published but will have an important impact on ADAS functions that rely on cameras, image processing, computer vision and other vehicle perception technologies.

Choosing Hardware and Software with Standards in Mind

When choosing hardware and software for automotive applications, especially ADAS applications that require stringent safety certification, the best solution is to rely on proven suppliers with products optimized for the application.
For automotive and especially ADAS systems, it is critical to use processors and other hardware specifically designed for the safety and power consumption constraints. There are several proven processor options for automotive applications. These are all ISO 26262-compliant and make excellent choices. For ADAS applications, most contain multiple cores for both safety and for offloading specific duties to co-processors.
Multiple-core processors can significantly increase safety as well as improve performance. Some have hardware safety cores integrated to ensure memory integrity. Some also have DSP capabilities for processing sensor data. Choosing a targeted processors that is already ISO 26262-compliant can greatly simplify your design as well as save time when it comes to certification.
While at first glance, “a compiler is a compiler” might seem true, but it certainly is not. All compilers make choices about the code to generate from the C/C++ input. With the myriad of built-in features and cores in automotive-oriented processors, it’s important that the compiler be aware of those features and produce code that is optimized for those features.
Choosing a compiler that is ASPICE-certified at Level 2 means that you can rest assured that the product has been developed according to processes that are proven and enable you to meet the required safety standards, which means your application is more likely to be error-free. Not only does using an ASPICE-certified compiler result in better code, it can also save money.

Standards: Too Limiting?

I’ve been asked the question “Do standards limit the creativity of engineers?” Frankly, I believe it to be just the opposite. Standards are like any other design constraint: they take the ambiguity out of the design and let the designer focus on the problem and how to creatively solve that problem within the scope of the constraints.
When safety and operational standards become constraints, it is abundantly clear what performance levels must be achieved. There is no need to define those constraints that have already been defined by a standards committee — that time is now available to define and design creative solutions. Using ISO 26262-compliant hardware and ASPICE-certified compilers also gives time benefits to designers.
All-in-all, the automotive safety standards in place, as well as those being developed, are a key to achieving safer, more efficient and eventually self-driven vehicles.

Cover image courtesy of Steve Jurvetson.