Autonomous Cars Drive New Software

Autonomous driving and other advanced features will require much more sophisticated software than what is used in vehicles today. To make this all work will require complex algorithms as well as co-designed hardware, which can make real-time decisions to avoid accidents and adjust to changing road conditions.

Automobiles already take advantage of sophisticated software executed by a variety of microcontrollers, but while these software designs are quite complex, cars are still considered to be standalone and self-contained systems. Interaction with the outside world is quite limited. But in order to efficiently and safely perform new complex operations, future cars will require much better interaction with their environment, with other vehicles (V2V), and with roads, traffic lights and signs (V2I).

“The comprehensive interaction of the car with its environment will allow vehicles to take advantage of valuable information coming from different external sources, and to share information with others,” said Asaf Ashkenazi, senior director of products in the security division at Rambus. “Unfortunately, the benefits of sharing information comes at great risk. V2V and V2I will expose the car to hackers and malicious payload, manipulating the external communication channels.”

To ensure the security for future cars, automotive software will require a transformation, Ashkenazi explained. “First, the car’s different software components will have to authenticate external systems it interacts with, and trust the data it receives. This can be done with cryptography and keys, backed by a hardware root of trust. Second, a car’s software quality will have to be improved to reduce the number of bugs and vulnerabilities. This can be done by adopting secure coding methods and practices, as well as tighter code quality reviews. Third, different software systems in the vehicle will have to be separated and contained, to assure that a compromise of one software system does not spread and compromise other systems in the car— similar to how ships use compartments to contain a torpedo damage.”

This evolution will be essential for autonomous driving to work.

Fig. 1: NHTSA’s concept of how an autonomous vehicle will look. Source: U.S. Department of Transportation

“It will require innovation in the areas of software and algorithms and broader platform architectures,” said Juergen Jagst, senior segment manager for automotive at ARM. “We anticipate an exponential growth in the electronic content of cars including sensors, radar, camera and LiDAR, all driving the need for high-performance computing and data fusion. At the same time, automotive platforms are becoming more complex, with high-end vehicles rapidly approaching up to 100 ECUs (electronic control units) per vehicle. The industry is combining the functionality of these ECUs into consolidated platforms with mixed criticality functions. The platform architecture requires a flexible SoC platform that can deliver support for hardware virtualization, robust security, such as ARM TrustZone technology, and functional safety capability. This platform enables Tier-1 and OEM partners to consolidate multiple ECUs onto one SoC, allowing a safety critical control function to be securely isolated from other functions running on the same SoC, simplifying their designs, and accelerating their time-to-market.”

This is an ambitious engineering agenda in a relatively short period of time. Most carmakers expect to have some level of autonomy available within the next four years. And while automotive security now controls the powertrain, braking system, suspension and other systems, significant changes are required in terms of reliability, safety, and cost-reduction. “We are seeing the electronics for doing those classic automotive tasks being consolidated, and taking advantage of multicore processors or heterogeneous multiprocessor SoCs,” said Larry Lapides, vice president of sales at Imperas Software.

The last big shift in automotive software occurred a decade ago with the advent of AUTOSAR. “It’s really only been widely deployed in the last couple of years, but now there are new multicore, multiprocessor, real-time operating systems, and AUTOSAR is being changed to go on top of that,” Lapides said. “Then you add in more vendors contributing software to the software stack, ISO 26262 and various other things. You’re seeing more software, more software complexity, and more testing requirements even just at the classical automotive area, to say nothing of the autonomous driving side of it. This is a significant development because those are the functions, no matter what car you’re driving anywhere in the world, that need to be there.”

On the autonomous driving side, Lapides pointed to the acquistion of Mobileye by Intel as illustrative of what’s happening. “You can think of it to some degree in the same way as you think of IoT. In IoT there are effectively three levels of device—a sensor level or an edge level, a gateway or consolidation level, and the cloud and the big data processing. In the car there is a similar dynamic. There are sensors for autonomous driving, some level of data consolidation and data processing in the car, and then you have it going to the cloud outside of the car. With Mobileye, Intel was trying to understand the edge or the sensor level, and the communication from that level up to the consolidation level. Mobileye was even starting to work at that consolidation level, but there Intel thinks their understanding of computing problems is going to help them with that consolidation/computation problem in the car. Plus, Intel wants to be at that cloud level in the communication there.”

At each of those three levels, there is new software such as communications software that goes between the levels, there is an interface between the car and the humans, and there is an application level processing with the vehicle, he said. “You’ve got the machine learning/AI cloud-based work. You’ve got the V2V/V2I/V2x, 5G or other communication. You’ve got a new security software, as well as privacy software.”

Paolo Piacentini, applications engineer manager at Kilopass Technology agreed. “One of major challenges within the vehicle in general — autonomous or not — are the data paths between different ECUs in the automobile and the security of the communications. The CAN bus is really basic. By the time the amount of information has to transfer from different elements on the vehicle, the CAN bus becomes a bottleneck so there’s no more information to be transferred and one way or another. That bus will be revised sooner or later. On top of that the CAN bus is very insecure. Not only is it is unencrypted, it is totally clean. But even today there is not a protected or secure boot system on the ECUs. Basically, changing the boot software on the ECU is pretty straightforward. There’s no encryption or keys and that, I believe, is going to change because security until now was not taken into consideration because the priority was somewhere else. Now that we have the idea of the vehicle and all the requirements for functionality in place, security comes into the loop.”

This translates to a whole new category of software that’s outside the vehicle and communicated in through a central gateway so the latest vehicle architectures will have a single secure gateway to the outside world so software can be beamed in, transferred in over the air either to update existing ECUs or download services or to provide new functionality, noted Andrew Patterson, automotive business development manager at Mentor, a Siemens Business. “All of that transfer needs security at both ends so that’s a whole range of new developments with boot loaders, the ability to roll back if something goes wrong — so all of the things that have happened in the IT world like when you update your Windows systems and want to roll back to the previous one — those technologies are now being deployed in automotive so that we can update ECUs and work with upgrade policies and certificates and authentication.”

Complexity grows
But additional software also translates to system complexity.

Kumar Venkatramani, vice president of business development at Silexica, noted that the National Highway Traffic Safety Administration (NHTSA) has adopted a six-level classification system based upon how much driver attention and intervention is required for a vehicle. “Some level 0 systems (those that issue warnings but take no action, like blind-spot monitoring), or level 1 systems (where driver and automated systems share control, like adaptive cruise control, or lane-keep assist) have been available in high-end luxury cars for several years now, and more of these features are now migrating down to standard features onto lower priced models. However, level 4 systems (fully autonomous but only in limited areas or ‘geo-fenced’ areas), or Level 5 (fully autonomous everywhere) are yet to be available, though several OEM are announcing that that such cars will be in the market within the next 5 years.”

“These autonomous driving systems have high amounts of software processing that is required, starting from sensor fusion systems—where information from multiple sensors like radar, LiDAR and cameras have to be integrated to build higher-order semantic objects—all the way to route planning and the necessary actions to control speed, and direction of the vehicle,” he said. “Currently, these kinds of software systems are being built, and many models are being experimented with. Learning from adjacent markets where computation speed (such as high-performance computing) and graphic rendering (in gaming) were key, these software systems are being built with multi-threaded Linux clusters running on CPUs, as well as Open GL and Open CL systems running on GPUs. And given the complexity of these software systems and the simultaneous need for high throughput, low latency, and low average power dissipation, we believe some form of heterogenous computing platforms (namely, combinations of CPUs, GPUs, DSPs) are going to be required. As such, expertise in developing software for these complex heterogenous computing platforms is going to be a crucial need of the hour.”

Fitting this into the stated timetable isn’t going to be easy, though. Dean Drako, president and CEO of Drako Motors, maintained there still are not a lot of computers fast enough and sophisticated enough to be used in this kind of safety-critical situation. “Airplanes all have moved to fly-by-wire, but cars are not fly-by-wire. You’ve got to get to the place where the car could be fly-by-wire or self-driving, so you need crazy levels of reliability in the software and the hardware. We just don’t have that in Windows or even in Linux so you’ve got a reliability issue.”

Another issue is the real-time response or nature of operating system, he said. “Linux is not a real-time OS. Windows is not a real-time OS. They can’t guarantee anything to anybody—ever. They can’t guarantee that the braking system is going to get so much CPU so it can do the right things to brake. There’s no guarantee. The way the auto manufacturers have dealt with this is to put hundreds of little CPUs in, so there’s one CPU that’s controlling the brake system, one controlling the lights, one controlling the power steering. They do dedicated little systems. The theory is that eventually that’s all going to have to collapse into one more central CPU because you’re going to want to have things interact in more complicated and sophisticated ways than you can do with the separate things. And you’re going to want to save the money.”

In order to do that, a “mega-robust” real-time operating system is needed, which is built for that application — and that’s not going to happen with Linux or Windows, Drako stressed. “The real-time operating system that everyone has been using has been the WindRiver stuff, but it’s getting dated.”

As far as what is being used today, Patterson has seen that Linux is emerging as an OS of choice by the OEMs in complex ECUs. “It’s a common platform for application developers and it’s reusable. We’re seeing a very strong trend now toward Linux at the expense of some of the legacy operating systems. Also, Linux itself is changing. We think Linux will change to support more complex use cases around safety as well. Safety is an area that is a challenge for software developers; it’s very expensive to certify software, so the more they can create reusable certified components that saves them money. If you’ve got new software and you have to certify it and test it — that’s a very expensive business so safety is an essential agreement. Gradually the components are getting more and more complex that can be certified and even certifying Linux is now a realistic value proposition. In the past that was viewed as something that would never happen — there were just too many lines of code and too many use cases but there’s now work underway to look for a safety certified Linux.”

Art Dahnert, managing consultant at Synopsys, agreed that software today isn’t resilient enough. But he is more optimistic about the progress being made. “We are getting there. It’s not secure, it’s not robust, but over time we will get there. We will need to get there in the near future for the automated self-driving vehicles of the future.”

Also, Dahnert observed that the design and testing processes for software are a bit behind some of the other parts of the industry, such as military and aerospace, but a clean-slate approach just starts the clock all over again.

“First off, you get a robust operating system, and there are many different operating systems per [auto] manufacturer,” he said. “They use different suppliers and have different OSes, but if you recall, over the years your desktop operating system got more robust and more secure as time went on and as the various vendors fixed the problems. It’s the same with your phone. The same will happen with the automotive suppliers, as well. Customers will demand better reliability and performance out of their equipment, so over time software will get better as we fix those issues.”

Beyond the operating system, what’s going to be difficult are the integration points—the applications and the functionality of software as it relates to the various capabilities in a vehicle. “Your AVS system is pretty much dialed in. There isn’t going to be a lot of functionality upgrades. It’s just doing a lot of command processing. But your head units, your IVI systems, your ECUs and the automation part—that’s going to be where we see a lot of work coming. That’s where a lot of the nascent part of development is going to occur.”

Today, Dahnert sees the real innovation happening at the sensor level—radar, LiDAR and computer vision technology. “Those kinds of processing, taking that in and deciding what to do, that’s where it gets really interesting. Then you throw in the Ubers of the world, too. Survival of the fittest will actually pair down those who can succeed and those who don’t have the stomach for it.”

Automotive software security
Last but not least, the security aspects of automotive software are tremendously important. Dahnert believes it’s well understood how important that is, even if it’s not just for security reasons. “Whether it’s problematic or not, it’s a perception, and customers are not going to buy an unsafe product. That’s what it comes down to. If my car is going to randomly crash while I’m driving down the road, then I’m not going to trust it. The [automotive OEMs] understand that.”

What they’re actually doing is another story, he added. “It’s slower. It takes a while for software to actually be updated in the field. It takes time for that software to go through the various checks and gates and processes that need to happen to verify that it’s actually secure. So they’re going to take some time. But they are engaging outside companies to help them develop secure software, develop the processes for creating secure software, and validating and verifying that the software is indeed safe and secure.”

Given all of the new, or revised, pieces of software needed, the only thing that’s clear at this point is that it will take some years to put all of this together. And when it comes to autonomous vehicles, it makes the most sense to take the time to get it right because lives will depend on it.

Related Stories
Auto Security And Technology Questions Persist
Fallout could be slower adoption of autonomous vehicles as ecosystem proceeds with caution.
Why Auto Designs Take So Long
A design for safety methodology is essential to trim automotive design costs, but at this point it’s a work in progress.
Work Remains To Enable Connected Cars, Automotive Security
There is progress with connected cars, and automotive security, but we’re not there yet.
LiDAR Completes Sensing Triumvirate
Technology will complement cameras and radar in autonomous vehicles.