The Automotive Shift to Software-Defined, Consolidated Controller Architectures

Thomas Bloor

Automotive Business Development Manager
BlackBerry QNX

Electronics in the car have come a long way from the first in-car radio in 1930, and 1978 when Mercedes-Benz introduced the first production car with an optional electronic four-wheel multi-channel anti-lock braking system (ABS) from Bosch.

Today, according to Manfred Broy, a professor at the Technical University of Munich, the cost of electronics and software has increased to 30% of a car's bill of materials. He estimates that 90% of new innovations now come from electronic systems in the car, and projections indicate the cost of electronics will surpass 50% in ten years as we move towards more advanced driver assist and fully autonomous functions in the car. These costs are driven by the electronic architecture of the modern car.

If we were to examine a modern luxury vehicle we would find a very complex interconnected network of between 60 to 100 electronic control units (ECUs) in aggregate running between 6 to 8 different operating systems with around 100 million lines of code. The distributed automotive computing architecture has evolved over many product generations as new features and innovations have been added though new hardware modules. This approach has served the industry well, but being faced with rising costs from more complex infotainment and new driver assist systems the existing model is becoming inefficient and a drag on bringing new features and innovations into the car. Complexity presents serious challenges, not the least of which are safety and security.

Additionally, the vision of urban mobility that will utilize fully electric autonomous cars has brought new competitors to the industry. These new entrants are rooted in hi-tech and are entering the automotive industry with the opportunity to architect the car from a clean sheet. Unencumbered by the burdensome legacy of traditional automotive manufacturers face,  the newcomers are architecting vehicle systems by leveraging advances in silicon technology to make designs with a smaller number of consolidated controllers with larger processing capabilities.

The evolution to these new consolidated controllers will provide a number of cost benefits. According to a study by Roland Berger associates, consolidated controllers will provide $110 of direct cost savings from hardware consolidation alone. An additional $65 of secondary savings will come from a reduction in software licensing and tools. The study did not quantify savings from software reuse, but positioned reuse as the unseen bulk of the iceberg under the water. As software development costs are often the largest single item in terms of time and manpower, a development savings in the software domain can dwarf the $175 of savings quantified by the researchers.

So, both the new entrants and established companies within the industry are moving towards a domain or area controller architecture – consolidating functions into a smaller number of more flexible processing nodes within the vehicles architecture. This consolidation opens the possibility of reducing the number of operating systems in the car to three or four and the total number of controllers to between six to ten.

This enables a more flexible architecture with a high degree of reuse of the software code base between the different domain/area controllers. In turn this allows the complete vehicle architecture to be built in a flexible manner, enabling the same code base to be reused across generations and differing variants within a model range. 

This more efficient vehicle architecture provides benefits such as reducing the number and duplication in development tools and the associated costs. Developers benefit as deeper experience in a smaller number of operating systems will reduce training requirements and improve developer skills and efficiency.  Reducing overall complexity also improves security and safety, because fewer attack surfaces are presented to a hacker with malicious intent, and  it focuses resources to find and fix security vulnerabilities in a smaller number of operating systems.

So, you can probably see that the auto industry is entering a revolutionary period in vehicle architecture.  Vehicle electronics will consolidate, and with that automakers and Tier 1s have the opportunity to build consolidated, adaptable software environments to speed time to market and enable multiple model variants to be derived from a common code base.  To realize the benefits of these changes a software architecture that is applicable across the majority of vehicle functions is desired. 

The choice of an operating system that enables increased reuse and has proven quality and reliability provides a valuable foundation upon which this architecture is built.  Wide applicability guides the choice to an operating system that is capable of providing mission-critical reliability and security for advanced driver assist (ADAS)and autonomous drive functions, while also being capable of underpinning consumer facing infotainment solutions.

BlackBerry's QNX subsidiary has a long history of underpinning the majority of autmotive infotainment systems in production today.  That is in no small part because QNX's common code base supports both safety OS and infotainment requirements, which provides an advantage in developing, reusing, and productizing code across safety and non-safety certified domains.   QNX recognizes that automakers may want to build mixed ASIL environments in their consolidated controllers as well as consumer infotainment offerings such as those from Google or other sources, so we built QNX’s hypervisor solution.

Availability of safety certification on the hypervisor with no changes adds flexibility and reduces development costs as ASIL certification can be completed after the code is partitioned between controllers, knowing that the underlying software complies with ISO26262. This enables a cockpit controller running a cluster application to have mixed ASIL A and B partitions in its software, and combine these in different informational zones in the same display. The obvious example being cluster gauges and navigational maps being displayed side by side with both partitions being run on a single processor.

Running this type of mixed environment requires full separation and isolation between domains and a safety certified hypervisor solution.  With QNX’s safe, secure, and reliable software solutions you can build an adaptable and dependable vehicle architecture. With safety certification available without the need for code base changes you can develop flexibly with the knowledge of being able to achieve ASIL certification where required.

The changes in vehicle architectures towards more consolidated domain/areas controllers enables am evolution in the software development methodology for the car, namely a shift to a continuous platform development methodology that will enable automakers to compete with new entrants from the high-tech world.  The new architectures will also allow the increased complexity of vehicle systems evolve safety and securely as we move towards the fully autonomous car. 
 

The ability to drive a flexible architecture and derive multiple vehicle platforms from a common code base and set of hardware controllers will be a competitive advantage to automakers and Tier 1s who embrace this approach.  They seem to already know that. Additional benefits of this approach include cost reduction and time to market acceleration stemming from reuse and improved security through the elimination of attack surfaces and the ability to embed cryptographic countermeasures security into the more capable controllers and ECUs.

This may be quite a challenge but we see many automakers and Tier 1s today accepting the challenge and adopting these practices.

Anchoring Trust in the Increasingly Software-Based Car

Bill Boldt
Business Development Manager, Security 
Blackberry

Electronic Control Units (ECUs) started out in the 1970s as discrete modules with each one doing one particular thing, at that time mainly for emissions controls and mileage.  Then they became connected via in-car networks with the invention of the CAN bus in 1985.  In-car networking represented a big improvement in capability.  However, being networked means that ECUs became vulnerable to mischief and thus they, and what the connect to (such as domain and area controllers) need to be secured cryptographically to ensure that the signals being sent have not been tampered with or corrupted, and perhaps most importantly, that they are authentic.   There is also the emerging need for confidentiality (i.e. encryption/decryption).

The picture below shows the top attack points.  This range or targets indicates just how vulnerable cars have become: 

With a car having so many places to attack, how can trusted security be implemented and why is it so important?  Well, the main thing is that trust leads to safety, especially as cars become more connected and autonomous.  Hacked or corrupted signals can have dire consequences in a car, which is obvious.  In a car, safety is related to security and security comes to a  large extent from cryptography.  (Note that safety and security are not exactly the same thing, but there is tremendous overlap and interplay, and safety is becoming much more dependent on cryptographic security as cars become more connected and autonomous.  For more on functional safety look here.)

Trust
Trust is paramount in digital systems, and increasingly so in automotive. Trust comes from cryptographic solutions that:

• Securely store secret keys
• Securely issue, manage, renew and revoke security certificates
• Include a mix of software and security hardened hardware devices, and
• Are manufactured in highly secure facilities

What Creates Trust?
A major tenet of security is that each system and sub-system will have different types of threats and a range of options to provide countermeasures to those. This means that the automotive security equation has many variables and thus is difficult to solve.

However, two things are always common to trustable cryptographic security, and they form the basic foundation of modern security:

1. A proven algorithm (e.g. Elliptic Curve Cryptography (ECC)), and  
2. A secret cryptographic key  (to provide the required level of security for the selected algorithm). 

The challenge for the automaker is to choose the right algorithm and key length for the available processing resources and to securely issue, manage/store, renew, and revoke the security certificates. Cryptographic strength comes from the combination and application of these principles, processes, and techniques. 
 
Trust Anchor
On a CAN bus, which was designed without security in mind, ECUs are exposed.   So, connected cars should employ best practices for security, but cost, complexity (especially of the supply chain) and time get in the way. Having said that, best practices will eventually prevail and that will likely include a hardware trust anchor system to establish, maintain, and update cryptographic processes.

 
From the diagram you can see the four basic things that create a PKI-based hardware trust anchor:

1. A trusted hardware anchor that stores the key
2. That key, which becomes the root of trust
3. The certificate chain anchored by the root of trust, and
4. A signing mechanism that creates the anchored certificate chain

Multi-level Security

Because there are so many systems in the increasingly software-defined car, security has to be multi-layered and fit the specific application. In other words — it must be tailored. You have to figure out what you are securing, what threats that system will face, and what countermeasures should be employed. You have to pick what pillars of security to apply; namely, confidentiality, data integrity, authentication, and non-revocation. Making sure you are doing the right security things on each system is what Blackberry is positioned to help you with, from consulting, to design, testing, certificate management, securing the supply chain, making updates, and applying cryptography to the in-car and around-the-car networks.

To learn more about cryptography for automotive please contact Blackberry's Certicom
subsidiary, and for more information and/or help regarding reliable, secure, and trusted software for safety- and mission-critical applications such as automotive please contact QNX. 

The bottom line is that BlackBerry, Certicom, and QNX can help your system become not just secure, but BlackBerry secure.