Third-party software plays a key role in the modern vehicle
The automotive software solution landscape is undergoing a fundamental shift as the industry
moves towards software-defined vehicles. The amount of software integrated into vehicles is
growing quickly as architectures move away from function-specific control units to central andzonal controllers that create virtual machines, using hypervisors and/or containers to combine
the functionality of multiple ECUs. Virtualization in software is the key to the architectural
enablement of the softwaredefined vehicle and enables
mixed-criticality systems suchas infotainment and safety
cameras to share the same
hardware.
OEMs such as Tesla, BMW, VW,
OF OEMS INTEGRATE MAJOR VENDOR
Mercedes, Stellantis, and Volvo
SOFTWARE COMPONENTS
have all announced initiatives
to develop their own softwarebase as part of this shift. But
do traditional vertical stacksoftware development paradigms scale enough to allow OEMs to do what they want to do? Will
integrating third-party software into those OEM stacks help make that scaling possible?
One of the big challenges that comes with this seismic change is that the global industry is trying
to access a very limited resource (developers). Going forward, all OEMs and Tier 1s cannot eachdevelop their own unique software stack – it is just not a sustainable model for the industry as awhole. Instead, they are combining their own developments with code and artifacts from third
parties – including commercial
off-the-shelf products, opensource code, and commercial
implementations of open
standards. But how do theydecide what kind of software
to put where, and does it really
OF OEMS INTEGRATE MAJOR OPEN-SOURCE
matter whether software is
COMPONENTS (SBD Automotive, 2021)
commercially managed orcommunity managed?
The continued move towards
features defined by software rather than hardware will bring even more code into the car. A
large part of that software, though, is not visibly differentiating to consumers. Software thatprovides the foundational layers of the software-defined vehicle, from drivers and boardsupport packages to operating systems, virtualization and middleware layers may differentiate
among themselves for what they allow OEMs and Tier 1s to develop, as shown in Figure 1. Thisis the part of the software stack where third-party software, or software developed outside the
OEM/Tier 1, offers the greatest value to the industry. Software that works across manufacturers
and components maximize commonality at the enabler level, allowing the feature-focused
software developers to concentrate their time on consumer-facing functionality and branddifferentiation.

100%

60%

2

END-TO-END
SOFTWARE-DEFINEDVEHICLE
Differentiating
Software/Features
Digital Services

END-TO-END SOFTWARE-DEFINED VEHICLE

CloudServices

OTA
Services

Connected &LocationBased
Services

Personalization& Identity
Services

AV/ADAS
Services

VehicleData Lake& Digital
Twin

DigitalServices

Cockpit UX
Safety Services
Cabin Features

Edge Data Services

SharedServices(In-Vehicle)

5G & V2X Connectivity
Over-the-Air Updates

Valuecreation
OEM/Tier 1 Software

Optimization& eﬃciency
Third-Party

VehicleApplications

Platforms &Middleware

Data
Applications

Container Runtime

IVI
Applications

Application Middleware
Services Middleware

Operating
System &Virtulization
3rd Party S/W
Opportunity

ADAS
Applications

Hardware& E/E

Real-TimeOperating System(RTOS)

General Purpose
Operating System(GPOS)

High-Performance
Computer (HPC)

Hypervisor

Digital Cockpit
Controller (IVI)High Performance
Computer (HPC)

Middleware Domains & Components
Non-Differentiating Software
Security Software

App Platform and Middleware

Deployment & OTA Tools

OS & Device Drivers

Hypervisor

Figure 1: OEMs and Tier 1s have an opportunity to integrate a range of third-party software to
improve their ability to scale their software stack
All OEMs integrate some level of vendor software into the lower half of their software stack,whether it is managing network traffic, enabling virtualization, at the OS level, or in middleware.
At the same time, 60% of OEMs reviewed by SBD Automotive integrate significant community
managed components at the OS level such as Linux® or Android™ – particularly within infotainment– and many integrate commercially managed implementations of open platforms and code (SBD
Automotive, 2021).
Given the global ceiling on developer availability and the relatively high proportion of nondifferentiating software in a vehicle, OEMs and Tier 1s can scale their software development mostefficiently when they combine their internally developed differentiating software with a mixture ofcommercially managed and community managed software at the enabler levels.

3

Community managed versus commercially managed software –are they actually in competition?
The third-party software in cars today covers a variety of systems, mission criticality, and functional use
cases. Third-party components range from cross-industry open-source products such as Android OS andLinux to automotive-specific open platforms implemented on a commercial basis, such as Classic and
Adaptive AUTOSAR, to commercially managed, automotive-focused products such as the QNX® Neutrino®
Real-Time Operating System and the QNX® Hypervisor from BlackBerry and Wind River VxWorks. By digging
into automotive system and software architectures, we can see patterns emerging of how different thirdparty contributions complement each other to deliver software-defined functionality.

GPOS» Continental» DENSO» ETAS» QNX® Neutrino RTOS
» Red Hat
» Wind River» Yocto ProjectApps, Middleware

Digital Twins» Apex.AI» AUTOSAR» BlackBerry QNX» Bosch» Continental» ETAS» Harman
» ZF

» AWS
» Bosch» Continental» DENSO» NVIDIA» Microsoft

ADAS/AV
Platform, SW

RTOS» aiMotive» Apollo» Aptiv» Autoware.AI» CARLA Team» Elektrobit» Google» Mobileye» QNX® Sensor
Framework» ROS» Veoneer» AUTOSAR» QNX® Neutrino® RTOS
» Green Hills» ROS» Wind River» Zephyr Project

Virtualization

GPU, Neural
Networks» QNX® Advanced
Virtualization Frameworks» Oasis VIRTIO» OpenSynergy» SOAFEE» Wind River» Xen Project» aiMotive» Cruise» NVIDIA» Open Neural
Networks» TensorFlow» Khronos Group

Figure 2: OEMs and Tier 1s will integrate many components from therange of available third-party software solution options4

Different approaches to making the “where should I source my software” decision play out intoday’s market, exemplified by three broad company personae:
The “Integrators”: OEMs or leading Tier 1s integrate a range of third-party
platforms and software components with their own differentiating layers.
These developments tend to rely heavily on commercially managed solutions tocomplement the internal development, such as those shown in Figure 2.
The “Slow-growers”: These companies invest heavily and carefully in coretechnology enablers for some domains, taking time to develop their own“home-grown” technology stack. These companies, invest significant time andmoney in standards-based or open-source software that provide the majorityof its non-differentiating layers, but still integrate a range of commerciallymanaged software to get the best blend of functionality to suit their strategies.
The “Need-it-Nows”: These manufacturers want a fast turnaround on theirdevelopment effort. They are more likely to combine community managed
software like Linux or Android for fast-change domains like infotainment withmature commercially managed solutions such as QNX for the slower-cycle andquality-critical areas such as safety/control systems.
All three manufacturer types show a tendency to integrate commercially managed software forsafety-critical components and systems and as virtualization layers to enable mixed-criticality
systems - particularly where developing an alternative to the existing solutions requires a longterm investment to create something a third party already has on the shelf. Open-source software,
where integrated, is typically focused on non-safety systems such as infotainment or in a few cases
as a foundation for own-built software.

All software needs to be managed
Given all the different software sources coming into modern vehicles, OEMs are now also facedwith the challenge to manage and monitor their software inventory. With over-the-air updates
allowing increasingly frequent software revisions to deliver both quality improvements and newfunctionality, vehicle lifecycles are quickly diverging from software lifecycles. Whether software ishome-grown, commercially managed, or community managed, someone in the vehicle ecosystem
has to look after the specific implementations that are on the roads for as long as they are active.

Tesla 100%

Volvo 100%

Polestar 100%50%

JLR 100%

75%

VW 77%

Skoda 90%

Share of brand’s models with OTA

100%

BMW 100%

OTA Update Availability of Selected Brands’ 2021 Model Year Vehicle Sales

25%

0%
Annually

Bi-Annual

QuarterlyMonthlyFrequency of update

Figure 3: OTA updates enable an update cadence that will test automotive software management systems
Source: SBD Automotive OTA & SW-Delivered Features Guide EU: Q1 2022
5

Even updating annually presents OEMs with multiple third-party software components withtraceability and maintainability issues. But as the industry moves towards monthly updates acrossdifferent domains and functionalities or sees periods of high-frequency cybersecurity patching due
to non-automotive factors, the ability to maintain a cohesive software integration will be tested evenfurther.
Global automotive regulations such as UNECE R155 and China’s GB/T series require manufacturers
and suppliers to provide an extensive software bill of materials (SBOM) on new vehicle types (UNECE
WP.29, 2020) (Biden, 2021), (General Office of the Ministry of Industry and Information Technology,2022). So, regardless of persona or software sourcing strategy, manufacturers need more from theirsoftware enabler ecosystem than just the software. Integrators at OEMs and Tier 1s increasingly
rely on software composition analysis tools such as BlackBerry® Jarvis® and Black Duck® to scan andunderstand the content of binary images going into cars.

DesignReleaseDevelop

RetireVehicle Platform Lifecycle

15-20 years from first build to last build

IVI Platform
Software

IVI Platform
Software~1-5 years with
updates andmodiﬁcations

Vehicle Control
Software1-5 years with
updates andmodiﬁcations

IVI Platform
Software~1-5 years with
updates andmodiﬁcations

Vehicle Control
Software~ 1-5 years with
updates andmodiﬁcations

Vehicle Control
Software1-5 years with
updates andmodiﬁcations

1-5 years with
updates andmodiﬁcations

Vehicle Control
Software1-5 years with
updates andmodiﬁcations

Cyber
Security
UpdatesFigure 4: Vehicle platforms lifecycles encapsulate several different software lifecycles

6The combination of commercially managed and community managed software means that even“proprietary” software can have significant levels of open-source components, and many open-sourcecomponents are only actually viable in vehicles over a full lifecycle when managed either by theOEM, a Tier 1, or a commercial software partner. As they are blended into mixed-criticality systems,
certainty of what is “in the box” becomes even more important.
The differentials among lifecycles amplify the complexity of understanding what is in the vehicle atany time and comparing that with what should be there. OEMs and their key software providers andintegrators are implementing processes to manage this complexity. Software vendors, who generally
have a clear product release model, are well-placed to support this non-functional regulatory
requirement. For example, the OpenChain ISO / IEC 5230:2020 standard provides a self-certification
framework to help companies (OEMs and suppliers) demonstrate that their license complianceprograms include all relevant artefacts and materials governed by open-source licensing. BlackBerrywas the first North American company to gain OpenChain accreditation across its entire productportfolio.
For open-source groups and developer communities, this combination of component traceability
and different product lifecycles within a single vehicle offer a significant challenge. The number ofsoftware recalls issued by U.S. NHTSA continues to grow. Recalls require no-cost repair for vehicles up
to 10 years old, but recall actions can extend to vehicles well beyond that age. Someone, somewhere,
has to maintain those software components for much longer than the originating developers typicallycommit to doing.

Debian (est.)
UbuntuRed Hat
SUSE
0

2

4
Full

6
Years
Maintenance

8

10

12

14

Extended

Figure 5: Long-term support among open-source OS may not always match automotive needs

To meet long vehicle platform lifecycles, software needs long-term support versions, which will
receive updates beyond the 6-month to 2-year support typical in consumer electronics. The opensource community has established extended support for key software packages, such as the Civil
Infrastructure Platform’s goal of 10 years or more for the Linux kernel (The Civil Infrastructure
Platform). However, such projects do not yet have the proven history that automotive-focused
software vendors have provided since the 1990s. OEMs or Tier 1s who are blending softwarefrom different sources across mixed-criticality systems will pick up the long-term management ofcommunity managed software components, at least for the next several years.
Both commercially and community managed software will continue to adapt to market demands,
fueled by the increased level of software both in vehicles and linked to them. Mixed-source software
will continue to blend different strengths to provide solutions for vehicles, systems, and individual7

ECUs. OEMs and Tier 1s will invest in their futures, selecting commercial partners and community
managed code to deliver architectures with support from multiple third parties. Virtualization
will become increasingly common to allow these software components to run together on mixedcriticality systems.
Whether the full vehicle software stack is designed at an OEM or a trusted Tier 1 partner, bestin-class software partnerships across the third-party solution landscape will be needed to create,
maintain and improve software for the life of the vehicle in a way that meets customer andregulatory expectations.

Case Study: BlackBerry QNXQNX software has been a part of the embedded automotive ecosystem for more than 20 years,
predating its ownership by BlackBerry. Over that time, the QNX Neutrino operating system hasformed a key part of the software strategy for most OEMs at some point in their own journey
towards a software-defined vehicle. The OS enables functionality across domains, and is well-known
for use in telematics, infotainment, info-safety, and increasingly, ADAS. These products operate
in over 195 million vehicles on the road today (BlackBerry QNX, 2021). This history and breadth ofexperience offers the company a good view of the challenges the automotive embedded software
industry will face in the next 5-10 years.
Apps, Middleware
GPOS» QNX® OS for Safety» QNX® Acoustics
Management Platform» QNX® Multimedia Suite» QNX® Speech
Framework» QNX® SDK forsmartphone
Connectivity» BlackBerry QNX OTA» BlackBerry IVY™

» QNX® Neutrino® OS» QNX® Hypervisor» QNX® Hypervisor for Safety» QNX® Advanced
Virtualization Frameworks» BlackBerry® Certicom®
Security Credential
Management System(SCMS)

ADAS/AV
Platform, SW

RTOS

Virtualization

SecureConnectivity» QNX® Sensor
Framework

GPU, Neural
Networks

Figure 6: BlackBerry(r) QNX®
in-vehicle software components(BlackBerry QNX, 2021)

8» aiMotive» Cruise» NVIDIA» Open Neural
Networks» TensorFlow» Khronos GroupToday, as architectures move away from function-focused ECUs to high-performance centralized
and/or zonal controllers, the company has identified a key need among OEMs for reliable software
components and enablers off-the-shelf that can operate effectively in a mixed-criticality system,
regardless of its source, as shown in Figure 6. Bringing together functionality for infotainment
functions such as media streaming and navigation and info-safety displays such as clusters andhead-up displays has challenged the embedded software ecosystem for some time. Within the ADAS
domains, running low-criticality functions like lane-keeping assistance and high-criticality functions
like piloted driving alongside each other can be equally complex.

Figure 7: QNX Hypervisor with Advanced Virtualization Frameworks for Android, Linux and
QNX guests supporting a range of third-party software components in an automotive softwareenvironment (BlackBerry QNX)
Pouring all of those into a single multi-domain, centralized compute resource offers significant
potential savings by reducing the number of high-powered ECUs in the vehicle, but it also increases
conceptual complexity in that the different domains and functions have very different reliability
and performance requirements. The QNX virtualization capability, as shown in Figure 7, helps OEMs
and Tier 1s approach the complexity of blending commercially and community managed software
to enable mixed-criticality systems that share the same hardware components. For example, byfollowing open standards like VIRTIO, infotainment services based on Android or Linux can sharedevices like displays and cameras with safety-focused functions like reversing cameras or lanekeeping warnings.

OpenGL is a registered trademark, and the OpenGL ES logo is a trademark of Hewlett Packard Enterprise used by permission by Khronos.
2
Vulkan and the Vulkan logo are registered trademarks of the Khronos Group Inc.
3
The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.
19How to decide what type of third-party software is most appropriate
for a specific component or function
OEMs and Tier 1s need to combine the best of both community managed and commercially managed
software to create a full software stack (even if they’re making their own).
To find your way through the options of what software to integrate and how you might need to blendcommercially and community managed components, it can help to understand where you fit best
among the three personae (“Integrator”, “Slow-grower”, or “Need-it-Now”) and apply that approachto the following questions.

Reliability:»»

Does the software component have the proofs/guarantees your organization or
intended use requires?
Does the software component meet internal and regulatory safety, stability,
recoverability, and cybersecurity requirements in line with the relevant system
criticality?

Financial:»»

Does the software component meet both initial and long-term cost targets forusage, internal development and maintenance resources (are external companies
looking after it for the long haul, or is that an internal cost)?
Does the hardware implication of the software component match your hardware
strategy and cost target?

Service and Support Outlook:»»

Does the software component provider or another identified organization(internal or external) have an understood plan for updating, maintaining, andpatching the software for its entire intended lifespan in the vehicle?
Does the upgrade frequency and issue responsiveness meet your needs?

Time-to-market»

Does the software do what you need it to for your time-to-market targets?

Differentiation»»

Does the software component offer you an opportunity to differentiate?
Is the software component significantly different to other available alternatives?

If the answers to the above questions are typically yes, then the software component you are looking
at is likely to be appropriate, regardless of its source. If it is no, then the persona alignment gives anindication of the right course of action:

10Persona

Potential approach to turn “No” into “Yes”

Look for commercially managed software to integrate

Integrator
Target internal + open-source / standardized development,
and bridge any time gaps with off-the-shelf software from acommercial partner

Slow-grower

Need-it-Now

Select the fastest turnaround / most flexible software source,
for example, internal management of open-source components
for IVI and non-critical functions and commercially managed
software for safety, security, and critical functions.

While each organization makes choices differently based on a combination of short-term
functional needs and long-term software support requirements, those choices will reflect theiroverall approach to software development and ownership. Whether the full vehicle software
stack is designed at an OEM or by a trusted Tier 1 partner, best-in-class components from a
range of third-party solutions are integral to creating, maintaining and improving software atscale across the automotive industry in all vehicle domains and for the full vehicle lifecycle. In
today’s market, mixed-criticality systems rely on commercially managed virtualization solutions
to ensure the blended software components run smoothly alongside each other. OEMs require
the same long-term maintenance expectations for their hypervisors as for their other key
software enablers. In a world of software-defined functionality and mixed-criticality systems, thesoftware has to work like new for as long as the cars are on the road. So, unless an OEM or Tier
1 wants to maintain its virtualization solutions for 15+ years in the same way they will look after
their application software, the commercially managed hypervisor route is a cost-effective way forcarmakers to manage risk when deploying mixed-criticality vehicle systems.

About SBD Automotive
SBD Automotive is a global consultancy firm specializing in automotive technologies. For
over 20 years, our independent research, insight, and consultancy has been helping vehicle
manufacturers and their partners to create smarter, more secure, better connected, andincreasingly autonomous cars. With a reputation for robust data and expert advice, as well as anability to attract and retain the industry’s most talented specialists, SBD Automotive operates
a network of local offices in key automotive hubs, including the UK, Japan, North America,
Germany, China, and India.

11

References
Apex.AI. (2021). Toyota creates a visionary vehicle OS, Arene. Retrieved from Apex.AI:
https://www.apex.ai/toyota-woven-planet
Automotive Grade Linux. (2018, January 18). Automotive Grade Linux Hits the Road Globally with Toyota. Retrieved from PR
Newswire: https://www.prnewswire.com/news-releases/automotive-grade-linux-hits-the-road-globally-with-toyotaamazon-alexa-joins-agl-to-support-voice-recognition-300580361.html
Baker, E. (2022, February 8). High security: Interview with Adam Boulton, chief technology officer, BlackBerry Technology
Solutions. Retrieved from Automotive Testing Technology International:
https://www.automotivetestingtechnologyinternational.com/features/high-security-interview-with-adam-boultonchief-technology-officer-for-blackberry-technology-solutions.html
Biden, J. R. (2021, May 12). Executive Order on Improving the Nation’s Cybersecurity. The White House. Retrieved fromhttps://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-thenations-cybersecurity/
BlackBerry. (2020, August 24). BlackBerry Teams Up with Desay SV Automotive to Enable an Intelligent and Safe Driving
Experience for the new Xpeng P7 - a Leading Level 3 Autonomous EV. Retrieved from BlackBerry: https://www.blackberry.
com/us/en/company/newsroom/press-releases/2020/blackberry-teams-up-with-desay-sv-automotive-to-enable-anintelligent-and-safe-driving-experience-for-the-new-xpeng-p7-a-leading-level-3-autonomous-ev
BlackBerry QNX. (2021, April 19). Foundational Software Solutions for the Modern Vehicle.
BlackBerry QNX. (n.d.). QNX Advanced Virtualization Frameworks. Retrieved from BlackBerry QNX:
https://blackberry.qnx.com/en/products/foundation-software/qnx-hypervisor/advanced-virtualization-frameworks
General Office of the Ministry of Industry and Information Technology. (2022, March 7). Notice of the General Office of the
Ministry of Industry and Information Technology on Issuing the Guidelines for the Construction of the Internet of Vehicles
Network Security and Data Security Standard System.
Lambert, F. (2016, October 6). Tesla vehicles to get a much-needed updated browser with new Linux OS in December, says
Musk. Retrieved from Elektrek: https://electrek.co/2016/10/06/tesla-updated-browser-linux-os-december-says-musk
Li Auto. (2021, August). FORM 6-K/A. Retrieved from Li Auto:https://ir.lixiang.com/static-files/b184f5fe-c7dd-4815-85c2-f3d75d45cfa4Man, H. (2020, June 22). Volkswagen to develop in-house software for next-gen cars. Retrieved from CarExpert:
https://www.carexpert.com.au/car-news/volkswagen-to-develop-in-house-infotainment-software
SBD Automotive. (2021). The business, technology and supply chain of The Software-defined Vehicle. SBD Automotive.
SBD Automotive. (2022). SBD Automotive OTA & SW-Delivered Features Guide EU: Q1 2022.
Stellantis. (2021, December 7). Stellantis Software Day. Retrieved from Stellantis: https://www.stellantis.com/content/
dam/stellantis-corporate/investors/events/stellantis-sw-day/Software_Day_2021_Presentation_final.pdf
Stellantis. (2022, January 5). Amazon and Stellantis Collaborate to Introduce Customer-Centric Connected Experiences
Across Millions of Vehicles, Helping Accelerate Stellantis’ Software Transformation. Retrieved from Stellantis: https://www.
stellantis.com/en/news/press-releases/2022/january/amazon-stellantis-collaborate-on-software-solutions
The Civil Infrastructure Platform. (n.d.). The Civil Infrastructure Platform FAQ. Retrieved from The Linux Foundatino:
https://www.cip-project.org/faq
UNECE WP.29. (2020, March 3). Draft new UN Regulation on uniform provisions concerning the approval of vehicles withregard to cyber security and of their cybersecurity management systems. ECE/TRANS/WP.29/GRVA. Retrieved fromhttps://unece.org/fileadmin/DAM/trans/doc/2020/wp29grva/GRVA-06-19r1e.pdf
Volkswagen AG. (2021, January). Transformers. Retrieved from Volkswagen Aktiengesellschaft:https://www.volkswagenag.com/en/news/fleet-customer/2021/01/transformers.html

12