THE future of mobility promises nothing short of seamless, automated, personalised travel on demand. Various elements of the extended automotive ecosystem are combining to realise that dream sooner than expected, meaning that incumbents and newcomers to the automotive industry need to move at top speed. Deloitte’s Future of Mobility series (e.g., The future of mobility: What's next? ¹ and Forces of change: The future of mobility²) has laid the groundwork for a discussion of the broader impact of future mobility solutions on industry, government, society and connected stakeholders. With this technically oriented article, we address an emerging group in this landscape: pure-play software (software-only) companies, which gain importance with every new product or process that incorporates software; automotive solutions are firmly part of this equation.

When Silicon Valley’s major technology companies entered automotive markets, they instilled the concept of a software-driven electric and electronic (E/E) vehicle architecture into the automotive industry – significantly affecting the strategic agenda of traditional original equipment manufacturers (OEMs). Industry titans announced that future market differentiators would be software-driven product and service innovations. Autonomous driving is one of the most prominent examples of advanced software development and a key enabler for radical change in the mobility ecosystem.

However, there are a few challenges presented by the ever-evolving arena of autonomous driving, which this article breaks down into four categories. By confronting these pain points, pure-play software companies can deftly position themselves in the automotive industry supply chain, helping steer the E/E revolution.

Reinventing the wheel: New architecture and platform strategies

Vehicle developers today face obvious challenges in terms of technological advancement, but longstanding obstacles are also presenting new problems. It’s clear that on-board processing power and data flow capacity need to increase massively, mostly to process data from advanced driver assistance systems (ADAS), in-vehicle infotainment (IVI) and information systems (such as head-up displays), as well as manage battery and energy levels. But as automated driving functionality ascends even further (Level 3 and higher, as shown in figure 1), this processing workload will demand even more. Near-universal connectivity in future mobility scenarios will require vehicles to communicate with other vehicles, infrastructure, and cloud services with minimal latency. Additionally, this connectivity must show vigilance with regard to cyber-security threats.

Consequently, a new type of electronic architecture is evolving: from distributed function-specific electronic control units (ECUs) to a handful of domain-specific control units (DCUs) and – as the target-state vision – to only one central, or a few zone-oriented, domain-independent vehicle computers (VCs) with cloud connectivity (figure 2).

One might think that establishing such integrated platform architectures should encourage the re-use of software applications. Consider the analogy of a personal computing application: A photo editor is developed, tested, verified and validated once, but deployed many times on various hardware configurations (such as an individual’s home PC, or over the cloud), based on well-defined standard interfaces. Now consider conventional distributed E/E architectures…this simple concept can’t be applied in that case because each application is developed as a monolithic, embedded system. It works in the vehicle it was designed for but can’t be reused in another vehicle or domain without major rework.

Regardless of this limitation, developers can’t deny the advantages of reusing software, and they persist in their efforts to standardise platforms to:

• enable application development that is independent of the start of production (SOP)
• provide software updates over-the-air (OTA) and thus de-couple application/platform improvements from expensive physical recalls during a vehicle’s life cycle
• increase scalability by standardising hardware components that no longer feature OEM-specific hardware characteristics
• potentially open up application development to third parties with strong software-engineering expertise but no previous automotive hardware experience.

The last aspect, in particular, leads us back to our initial question about whether developments will open up opportunities for pure-play software companies in the automotive industry. Some OEMs and large automotive Tier-1 suppliers have already outlined their thoughts on this point, as described in the next section. The demand for software expertise is growing, but there is a general shortage of capabilities and people with the right skill sets, both in-house and externally, which reveals strong potential points of entry for pure-play software companies.

The shifting gears of OEM requirements and value-chain dynamics

Establishing standardised platforms leads to gradually replacing classic components that feature function-specific, embedded, monolithic software. Instead, more separated hardware and software development modes are ideal – ones that are clearly defined by standard interfaces allowing for easy integration, similar to a plug-and-play approach. Platform concepts, derived from Silicon Valley-inspired consumer electronics and software system architectures, are being introduced by OEMs, Tier-1 companies and other key players in the automotive E/E field. Potential new players can look to these concepts for an idea of where to tap into new business opportunities in the future (figure 3).

With their traditionally dominant role in the value chain, automotive OEMs are attempting to maintain the role of key orchestrators. In this context, some have publicly outlined their hypotheses for future strategic sourcing and partnership strategies. According to Thomas M. Müller, executive vice-president of R&D for Volkswagen China and former head of development for electrics/electronics and Car-IT at Audi, they’re aiming to⁴:

• bundle OEM-specific functional characteristics from formerly separated ECUs as differentiators on the DCU level or (in future vehicle generations) VC level
• avoid sourcing black-box embedded systems, by which responsibility for hardware development and software integration stays exclusively with Tier-1 suppliers
• source ‘generic’ hardware components (such as sensors or actuators) separately from differentiating features
• get actively involved in chip selection, considering strong recent efforts from semiconductor producers to provide systems on a chip (SoC)
• develop new capabilities of classic Tier-1 suppliers to transition them from ‘black-box system providers’ into overall integrators (while still bearing overall product liability for the system)
• establish more OEM-proprietary, in-house capabilities in the fields of application software, functions and services, as well as semiconductor know-how
• in parallel, strengthen working models and commercial models with specialised software suppliers and software developers.

This is how (some) OEMs plan to make the ‘smartphone on wheels’ a reality – with the help of their value-chain partners, and there does seem to be real automotive business opportunities for software specialists. However, in Deloitte’s experience, and given our knowledge of the automotive value chain, there are still a few significant obstacles to be overcome before achieving vibrant, sustainable, software-only markets in the automotive industry.

The four challenges pure-play software companies must negotiate

The automotive market is still a tough one for software specialists; many market practices seem to be potential roadblocks for pure-play software companies, standing in the way of attractive and vibrant market opportunities. But keep this in mind: Passenger vehicles already use four times as many lines of code as commercial aircrafts – which is going to increase by a factor of 10,000 in the next few years.⁵ OEMs can neither master the giant task of complex embedded software development posed by autonomous driving alone, nor rely on the handful of large Tier-1 suppliers holding strong market positions as integrated system suppliers. Bear that in mind as we examine the following roadblocks, then delve into strategic options to overcome them.

1. Quality and safety requirements demanding huge verification and validation efforts

Strict automotive quality standards take into account that the life cycle of a vehicle is significantly longer than that of, say, a smartphone. What’s more, the vehicle’s systems must be reliable in much more challenging conditions (such as being exposed to weather), and stringent functional safety requirements apply, as outlined in ISO standard 26262. A great number of software-supported vehicle functions occur frequently (e.g., braking) or are hard to control (e.g., emergency braking on an icy road) and can result in severe incidents, such as passenger injuries; they must be precisely engineered.

ASIL risk classifications dictate software safety requirements with which OEMs and suppliers must comply. In our experience, the cost of integration, testing, verifying and validating functions to meet these requirements can easily amount to 40 per cent, or more, of overall development budgets (from the start of development to the start of production).⁶

Upcoming regulations targeting cyber-security risk management (for example, the UNECE WP.29⁷) add to the already high requirements; from 2021, OEMs will be required to have certified cyber-security management systems (CSMS) and software update management systems (SUMS). To name a few of the necessary actions for OEMs: They will have to ensure that suppliers provide detailed product descriptions for installed software, from product development all the way to the end of the vehicle’s lifetime, as well as proactive software updates and patches to ensure information security.

Such industry-specific, regulation-driven requirements pose high entry barriers for new automotive software suppliers. OEM-imposed prerequisites for supplier qualification are very strict. And once qualified, after a lengthy period marked by significant supplier effort and investment, dependency on the newly won OEM customer is almost inevitable, as is the grudging acceptance of more and more commercial control imposed by the OEM.

2. No clear visibility of software value in a vehicle’s bill of material

In traditional distributed E/E architectures, procurement of software embedded in hardware systems can be measured in cost per piece in the bill of material. The cost of software is not intuitively measurable, nor is its value, by piece or even by vehicle. Typical automotive pricing works from the bottom up (figure 4): All cost positions are analysed (more or less) transparently and allocated to cost positions per piece; a mark-up (margin) is finally added on top of that. From an OEM perspective, this has clear advantages – namely, commercial control and a strong negotiation position.

The typical software pricing approach in other industries, such as consumer electronics, works from the top down with a value-based pricing strategy. The price derives from the customers’ willingness to pay for the product or feature. This requires software developers to retain intellectual property, or risk endangering their competitive advantage, value proposition and business model. It is exactly this aspect that stands at odds with many OEM strategies: OEMs generally view features pertaining to driving dynamics (e.g., driving assistance or autonomous driving) as strategic core areas and key differentiators. IVI solutions or digital maps, on the other hand, are generally seen as commodities.

The alternative for pure-play software companies is to act as development partners to OEMs or large Tier-1 suppliers, based on hourly fees. Although this is an easy opportunity to generate business, it is no different from traditional business models of engineering service providers, and presents pure-play software companies with little to no potential for additional business advantage. It’s more lucrative to focus on higher-margin ADAS feature development, as elaborated in the next section.

3. Substantial upfront investment, lengthy amortisation

Strong financial stamina is required as an automotive software supplier, given OEM procurement regulations and practices left over from the days of embedded software procurement. Software development costs are often considered upfront supplier investments, only compensated along the product life cycle as part of the unit price (figure 5). This puts suppliers at significant financial risk, considering that volume developments may end up lower than initially forecasted. Amortisation periods of five years are common and a heavy burden for small and mid-sized suppliers.

Far-reaching product liability commitments are an additional factor to consider. In the past, black-box embedded systems from Tier-1 suppliers were accepted by OEMs for – among other reasons – clear liability for products. In other words, somebody had to be the first in line for OEMs to claim money back in case of quality or functional failures. This requires deep pockets, as well as overall vehicle integration and legal expertise.

4. Lack of collaboration standards along the software value chain

OEMs, traditional Tier-1 suppliers, new software-focused market entrants, engineering service providers and even semiconductor manufacturers – they’re all pushing to market services and products that involve vehicle software development. Frustratingly, all potential customers of a pure-play software company, mainly OEMs or large Tier-1 companies, are following different strategies when it comes to application software.

Some are developing in-house talent and capabilities (for example, BMW’s Car-IT and, more recently, Volkswagen’s Car.Software.org⁸). Some are entering long-term partnerships or joint ventures with application software specialists (consider e.solutions, an Audi-Elektrobit joint venture). Still others are engaging in classic outsourcing, calling on engineering service providers for software development tasks while the OEMs retain intellectual property of the produced source code. Roles in the automotive software value chain remain highly fluid.

To attract software-only players, more stability of automotive stakeholder roles is needed, and predictability of what automotive software customers require. For this purpose, standardising platform concepts for easier (third-party) software integration is crucial, as is establishing industry-wide collaboration models and technology interfaces to bring OEMs, suppliers, pure-play software companies and other automotive players closer together. Efforts in this direction so far have included AUTOSAR Classic and AUTOSAR Adaptive platforms, and are driven mostly by European OEMs and Tier-1 suppliers.

Without more actions that encourage stability and predictability, the only feasible commercial model for pure-play software companies – outside the aforementioned long-term partnerships – comprise service contracts directly determined by hourly development effort. But this model provides little incentive for software experts to invest time and money in new automotive-specific solutions. This is especially true if they are used to consumer electronics markets, which are far less regulated and not as commercially dominated by a small number of potential business-to-business customers.

The missing link: Finding opportunity in the automotive software value chain

The automotive industry is largely aware of its challenges, and traditional players (the potential clients of pure-play software companies) are working on solutions, to some extent. They’re aiming to establish industry-wide collaboration standards and solidify clear roles for in-vehicle software development, which is in all players’ interests. The same applies to achieving standardised hardware-software interfaces and interfaces within the software stack, which will, in turn, help cut verification costs by facilitating software re-use.

Apart from being involved in industry-wide initiatives for establishing standards, alongside OEMs (such as AUTOSAR, as mentioned above), large Tier-1 suppliers are embracing the role of system integrators by providing joint software development and integration platforms.⁹ OEMs, for their part, are also working on new processes and commercial models to extend traditional OEM-supplier relationships and make it easier for pure-play software companies to deliver their value contribution.¹⁰

And that takes us back to our initial question: What are the sweet spots along the automotive software value chain for pure-play software companies? The answer is best derived from understanding their potential clients’ needs – for the sake of clarity, we’ll focus on OEMs. See figure 6 for a simple matrix illustrating OEMs’ strategic options when it comes to external support for vehicle software. The y-axis displays the level of strategic value (differentiation vs. competitor vehicles) offered by a software feature or application. The x-axis displays today’s level of an OEM’s in-house capabilities in this area.

Core business (high strategic value and high OEM capabilities):

Potential automotive clients of pure-play software companies have already undertaken significant efforts to build their software competency in highly relevant domains. Well-publicised examples can be found in the area of autonomous driving, where many major OEMs have invested enormous resources to build in-house capabilities in recent years. But it’s not too late to find attractive entry points for pure-play software companies.

On the one hand, pure-play software companies can share best practices for effective organisation design, drive performance in agile development settings or offer operational tools for software development adapted to automotive needs. Such business models are typically service based (for performance improvement of software development operations) or license based (for development tools).

On the other hand, the prospect of network effects (e.g., a product’s value increases with the number of users) can lead to attractive options for partnership with OEMs. Examples include a software company offering access to its consumer electronics customer base, to enhance the reach of an OEM’s mobility services or IVI applications. Software companies should strive to identify such potential network effects, especially considering their typically much larger private customer base and OEMs’ relatively small fleet sizes (such as for the quality of traffic information or object detection).

‘Low hanging fruit’ (low strategic value and high OEM capabilities):

Potential automotive clients are seeking opportunities to increase the flexibility of their workforce (growing without hiring new internal employees) or to gradually reduce using their own resources for tasks that add little value. In this industry, this has traditionally meant a large market for engineering service providers, and OEMs will require even more support in the future, such as for testing, verification and validation of software, or for coding tasks at the OEM’s instruction (with the OEM retaining the intellectual property).¹¹

New pure-play software companies have the chance to secure the low-hanging fruit of this market with their well-trained and substantial software development talent – especially while traditional engineering service providers struggle to build size and capability in relevant areas. However, as mentioned above, such time-and-material–based business models might offer scant business advantage as compared to, for example, business-to-consumer ventures, in which development resources might be allocated more profitably.

Commodity (low strategic value and low OEM capabilities): Potential automotive clients seek to source standard vehicle software products or services but don’t regard these commodities as differentiating features for car customers. Examples (naturally, OEM specific) may include software for payment services, for subscription management, or for weather, news or real-time traffic information. Pricing such essentially ‘off-the-shelf’ software and data products would preferably follow license-based models: The use of proprietary code or data is remunerated per vehicle, user or amount of data transmitted.

A key advantage for pure-play software companies in this regard is that, in many cases, necessary investments in automotive-specific product adaptations are not too high. Other advantages include the possibility to retain intellectual property, not hand over one’s unique value proposition to the OEM and be able to capture a potential business advantage in a vehicle’s life cycle, by monetising data or via software licenses.

Capability development (high strategic value and low OEM capabilities): Potential automotive clients have an urgent need to build new capabilities quickly, ensuring future vehicles remain attractive and unique in their markets. This is generally a favourable situation for pure-play software companies with the necessary skills and assets. Strategic partnerships, joint ventures and even company takeovers are highly common, spurred by OEMs’ desire to grow crucial new software development capabilities in house, and by the lack of standard hardware-software interfaces in the industry. To name just a couple of examples: Volkswagen’s acquisitions of WirelessCar (a telematics specialist)¹² and Argo AI (an autonomous vehicle platform) with Ford.¹³

However, not only large, industry-shaping partnerships fall under this category. Technology scouting among smaller, even start-up–stage software companies has become a standard process for many OEMs.¹⁴ In this context, what pure-play software companies should remember is the benefit of profit-sharing business models.

Considering all the above pathways for entry to the automotive industries, there remains no question about the existence of business opportunities for pure-play software companies. The race for future business claims is not yet decided, but automotive software markets are tough to thrive in, especially with missing architecture and interface standards. It’s worth participating early and actively in efforts to support shaping these future standards, before consolidation and standardisation activities shut the barriers to market entry.

Traditional automotive giants will not be able to achieve the transition to becoming data-driven technology companies by themselves, meaning their future success in furthering technology integration could very well lie in the hands of pure-play software companies. And the success of those pure-play companies will, in turn, depend on how well they can surmount the four major challenges described above.

However, this is a trend affecting not just the automotive industry. Insurance, healthcare, energy, media and manufacturing in general are among the others going through their own digital transformations, which naturally brings the need for increased software capabilities. As software “is eating the world”,¹⁵ pure-play software companies find themselves on an upward trajectory with significant growth potential. Still, there are fundamental challenges similar to those in the automotive industry: coping with entry barriers in highly competitive markets and finding the right spot in established supply chains and business models.

Obstacles aside, the future looks bright for pure-play software companies that have the right mindset and an adaptive business approach. Now if all industry leaders can identify their own software capability shortcomings and actively work on solutions that leverage the potential of pure-play companies, both sides will enjoy a win-win situation.

Deloitte's Global Automotive Sector

Deloitte’s global automotive team helps automotive companies execute innovative ideas in exceptional ways. We offer a global, integrated approach combined with business and industry knowledge to help our clients excel anywhere in the world. Our experts work with companies across the entire automotive value chain – OEMs, suppliers, dealerships, logistics, and captive finance providers – to address the full range of challenges the industry must confront. Contact the authors for more information or read more about our automotive sector–specific services on Deloitte.com.