Building the Electric Vehicle: Software Architecture Matters

The quality of a project’s software architecture makes a world of difference in a developer’s ability to understand, write, fix, and modify that software. Poorly architected software – often derisively called spaghetti code – introduces bugs, imposes delays, and increases cost, while a strong software architecture enables a company to react quickly and confidently to market changes. As software takes an ever-increasing role in the car’s perceived value, a strong vehicle software architecture has become paramount to continued automaker growth.

Most electric vehicle (EV) makers have picked BlackBerry^® QNX^® as a key architectural component of one of their biggest assets: their code base. To understand why, we need to dive a bit deeper into how car software is built.

Modules, Modules, Everywhere

While well-designed cars can feel like a single unified machine to the driver, under the hood are dozens of individual modules – each containing software – that provide the car’s functions. These modules have a diverse mix of performance requirements as well as unique demands on how they’re built.

Table 1. Requirements differ for different types of vehicle modules.

While module variety enables cars to be multi-talented, it can be problematic to maximize software investments with a unified software architecture since the software that’s necessary for each category can point in vastly different directions. For example, an infotainment system that needs lots of third-party software and frequent updates would need a powerful and modern operating system. Yet an engine control module that has a single job of monitoring performance thousands of times a second within exacting tolerances, needs something fast, lean, and deterministic.

Supporting Diversity

The ability to build software for any part of the car is a big reason why EV makers have chosen the QNX^® Neutrino^® RTOS and our fully compatible safety-certified variant, the QNX^® OS for Safety as the foundation of their software architecture. Our RTOS can support reliable real-time execution for under-the-hood and safety critical applications. Yet it is also POSIX compliant (it uses the same system-level APIs as Linux®), supports the newest graphical tools and libraries, has a large developer ecosystem, and is supported by many third-party suppliers.

The blend of automotive-grade real-time performance with consumer-friendly features allows for the creation of a single consistent software architecture, regardless of where in the vehicle it resides. This maximizes software reuse and software library sharing, shortens development time and improves productivity. It also makes effective use of engineering resources, since all developers in the company can use the same tools, skills, and knowledge.

Merge Ahead

There’s another major architectural concern that modern automakers need to consider, especially when developing the advanced software systems that electric vehicles require. That is whether the vehicle’s software architecture can readily support module consolidation. But what is module consolidation?

Cars today contain many separate modules. In fact, a car is like a server farm with dozens of computers networked together, albeit on a much smaller (and more mobile) scale. The comparison with the cloud is very purposeful, since there is a powerful insight that automakers have borrowed from the modern cloud infrastructure. With one single technology change, you can simultaneously increase capability, reduce hardware complexity, and dramatically cut costs.

Cutting Costs without Cutting Corners

What if you could remove 20, 40, or even 70 modules from a car and replace them with one larger processor? This bigger, more powerful processor would do the tasks of the many less-capable machines. A huge amount of money can be saved by removing unneeded processors, RAM and flash chips, module housing plastic, support electronics, wiring harnesses and connectors, not to mention drastically simplifying the overall software environment.

How does cloud technology do it? A cloud-based server runs multiple virtual machines (VMs), each a separate software image running in its own sandbox. A sandbox is an environment that protects the software inside as well as contains it. The software within the VM doesn’t change – it can’t tell that it’s sharing the processor with 20 other VMs. Cloud-based VM technology uses a hypervisor and hardware assistance to help pull off this wizardry.

Hypervisor: Bringing the Cloud to the Car

The embedded software realm doesn’t need the overkill of a full virtual machine to implement a module consolidation strategy. Instead, a car can use the power of lighter-weight hypervisors to keep the bits of independent functionality in their own sandboxes. (Even cloud-based servers have, in many cases, scaled down from full VMs to a slimmer alternative – containers.)

The strength of a module consolidation architecture requires a hypervisor, but because so many of the functions have safety implications, it must be one that’s certified for safety-critical applications. Our QNX^® Hypervisor for Safety is the industry’s first commercially available ISO 26262 ASIL-D safety-certified hypervisor.

Why do 24 of the top 25 EV OEMs choose BlackBerry QNX for their automotive software? Learn the top 10 reasons in the white paper Why BlackBerry QNX Has Become a Leading EV Automotive Software Supplier.