Rewiring car electronics and software architecture for the ‘Roaring 2020s’

The automotive industry—including suppliers, OEMs, and new entrants—faces a variety of tough challenges in the Roaring 2020s. One of the most significant is the transition to a software-enabled ecosystem. To operate in that ecosystem, the industry will need to make significant shifts in what it does (technology), what it looks like (competitive dynamics), and how it succeeds (commercial implications and investment in talent).

Already, many OEMs and suppliers have announced initiatives for rebuilding their organizations to put software first. However, this is only the first step in a set of strategic imperatives the automotive industry should address. In this article, we make the case for change, identify the trends that companies should prepare for, and lay out some imperatives for thriving with a software-focused strategy.

Megatrends will push software to the forefront

Major technology leaps in autonomous driving (AD), connectivity, electrification, and shared mobility—the ACES megatrends—will transform vehicle electronics and software-architecture requirements over the next ten years (Exhibit 1). In this new environment, software features are becoming key buying factors and differentiators.

1

Consequently, automotive players must make technology leaps across many functional areas simultaneously. For example, to give customers safe autonomous-driving and advanced driver-assistance systems (ADAS), they will need to manage more complex software under strong governmental regulations. Differentiating by providing the freshest user experience with updated software and new features requires not only new connectivity services but also high-performing in-vehicle networks with back ends for over-the-air (OTA) software updates. On top of this, OEMs aim to increase the range of electric vehicles (EVs) and facilitate the transition to EV and hybrid powertrains, leading to the development of complex battery-management software and charging technologies. Consumer demand for shared mobility will require the industry to develop better vehicle-access technologies and advanced car-sharing and robotaxi applications. Furthermore, regulations such as the UN Economic Commission for Europe’s regulations on cybersecurity (UN R155) and software-update management (UN R156) place new requirements on electrical and electronics systems and software architecture.

To deliver on these expectations quickly, automotive players need a scalable, flexible, and robust platform for vehicle electronics and software. Organizations that achieve this goal will enjoy strong upside potential in the form of new value pools and greater differentiation opportunities. However, companies that pursue this goal also face a substantial risk of failure, because it covers much terrain that is still new for incumbent automotive players (Exhibit 2).

2

We expect the market for car electronics and software to grow much faster than the overall automotive market, opening new opportunities along the value chain for OEMs, tier-one suppliers, and semiconductor and software players.

The business environment for automotive software and electronics is likely to experience significant changes in three major areas:

• Technology. Automotive electrical and electronic (E/E) technology will continue to become more centralized and consolidated. For instance, fourth-generation systems will have centralized domain controllers, and fifth-generation systems will employ a combination of cross-domain vehicle computers and zone controllers. Cross-domain vehicle computers will centralize functionality, which in today’s third-generation systems runs on different electronic control units (ECUs), while zone controllers mainly act as a gateway and consolidate input and output functionality for a specific area within the vehicle. While third-generation systems are expected to dominate the market over the next few years, fourth-generation systems will quickly become standard for premium OEMs (Exhibit 3). Also, for most domains, horizontal technology stacks will replace vertically integrated, embedded systems to reduce complexity, simplify update processes, and increase reuse of software components. Standardization will also benefit the industry by increasing reuse and reducing the cost of adapting software applications for specific customers. So far, however, we have not seen significant moves beyond the infotainment sector, and differences in customer requirements, ecosystem partners, and regulatory boundaries will require different hardware and software stacks in China than in Europe and North America.

3

• Competitive dynamics. The competitive environment will change significantly with the disruption of traditional value chains. New tech players will continue to extend their influence in automotive and bring their consumer-electronics ecosystems to cars, pickups, and SUVs. New OEMs will develop much of their software in-house, and more automakers will directly codevelop their software in cross-organizational teams that include tier-one suppliers, dedicated software suppliers, and chip manufacturers. Instead of the typical industry–supplier relationships, we will see more long-term strategic partnerships among different players in the ecosystem.
• Commercial implications. Developing the next generation of automotive E/E systems will require bold commercial commitments. While the initial development costs for new E/E and software architectures will likely exceed the cost of further developing current ones, such investments will pay off in future generations by permitting greater reuse and lower complexity while maintaining market competitiveness. In this environment, a lifetime total-cost-of-ownership (TCO) perspective can help OEMs make the right architectural decisions. To succeed, companies will likely need to make major investments in talent and capability building and undertake organizational transformations that allow them to differentiate themselves for their software offerings.

The cumulative effect of these trends is to push software to the forefront of what automotive companies make and how they compete. To highlight the changes ahead, we have formulated ten hypotheses about the future of the industry, categorized by the three business areas described above.

Technology trends

The industry will further consolidate and standardize automotive E/E technology. The influx of new systems from new suppliers is making obsolete the proprietary “walled gardens” that OEMs have constructed over the years.

Hypothesis 1: The technology landscape will converge

As automotive E/E technology evolves, the landscape will move toward architectures with fewer ECUs. These will likely take the form of domain-centered designs in the fourth generation and zone- or vehicle-centered configurations in the fifth (Exhibit 4). We believe future automotive-electronics architectures will become more centralized to facilitate the development of highly autonomous driving (HAD) and to reduce complexity and costs in the long run.

4

Many OEMs are currently launching vehicles with the first centralized-domain E/E systems, which we characterize as fourth-generation designs. These systems focus on a domain view and consolidate functionalities within domains, clustered according to requirements. This setup reduces the number of ECUs required: a small number of domain control units (DCUs) can replace the ECUs, because DCUs are much more powerful and can cover more functionalities and handle more complex tasks (Exhibit 5).

5

Some greenfield architectures of new electric-vehicle OEMs are already using several elements of the fifth-generation architecture (Exhibit 6), such as cross-domain vehicle computers or distributed-zone computers. A distributed-zone architecture with dedicated zone-control units consolidates the functionality of several ECUs in a specific area of the vehicle (a zone). This enables companies to reduce the size and weight of the wiring harness; reduce complexity in hardware variances, thereby easing field-software updates; and ultimately reduce the number of control units. In addition, vehicle assembly costs should be lower because of the reduced complexity of the harness and because fewer control units need to be installed. The decoupling of the application software from the computing platform through the use of operating systems and middleware leads to faster innovation cycles, reduces the effort for system integration, and enables new functionalities.

6

Hypothesis 2: Horizontal technology stacks will replace vertically integrated, embedded systems

Future automotive-software architectures will, in general, consist of horizontally interlinked technology stacks (see the horizontal layers in Exhibit 5), representing a move away from integrated, embedded systems. These stacks will feature IT components and processes like those proven in today’s consumer-electronics applications (such as smartphones) or cloud applications with managed and stable abstractions and APIs between layers. Instead of 50 to 100-plus dedicated ECUs, each with its own embedded applications, we will see horizontally integrated software stacks on DCUs and cross-domain vehicle computers.

This new technology stack will likely include the following main layers:

• sensors and actuators, such as acceleration sensors or small motors for windows or wiper systems
• data and power distribution, such as an automotive Ethernet as a backbone connecting the domain control units, central computer, and zone control units, or a Controller Area Network (CAN) bus and FlexRay communications protocol to connect additional control units to the backbone
• computing platforms, such as ECUs, DCUs, cross-domain central computers, and zone computers, including high-performance computing architectures with microprocessors, microcontrollers, and additional hardware accelerators such as graphics processing units (GPUs)
• operating systems (OSs), middleware, and communication elements, including drivers, communication protocols, and cybersecurity layers featuring technologies such as hypervisors, containerization (such as Docker), and APIs to abstract the software from the hardware layer and consequently reduce the overall system complexity—with different operating systems for different domains (ADAS/AD, body, powertrain) if necessitated by differences in performance and safety requirements
• applications, which could include image-recognition systems for ADAS or autonomous driving, voice controls for infotainment, battery-management systems within the powertrain domain, and heating, ventilation, and air-conditioning (HVAC) controls in the body domain
• human-machine interfaces (HMI), as well as visual, acoustic, or haptic interfaces between the driver and vehicle
• offboard infrastructure, such as public, private, or hybrid clouds
• back-end platforms on top of the offboard infrastructure that provide basic enablers and services for connected-car back-end services
• connected-car back-end services running on offboard infrastructure—for example, real-time traffic monitors, road-hazard warnings, remote control, or predictive maintenance
• edge devices, including connected hardware that can extend the scope of the connected vehicle to road infrastructure such as charge points or parking meters

Why a new architecture makes sense. The key benefit of this new software architecture is that it enables engineers to build applications that rely on stable, well-maintained APIs. By reducing dependency on the underlying hardware, the new architecture will significantly expand the reuse of software among various hardware implementations. In consequence, OEMs can rely on best-in-class hardware implementations, such as chips for AD, and developers can take advantage of best-practice implementations of certain algorithms made available via the middleware layer or artificial intelligence (AI) libraries. If programmers use standard operating systems, they can adopt development processes and tools from the nonautomative-software world to accelerate software development and streamline testing. Furthermore, de facto standards in the infotainment operating system and middleware allow developers to focus on differentiation or customer-facing functions.

Types of software stacks. We expect four distinct types of software stacks to take shape within the overall automotive stack:

• Time-driven software mainly involves automotive-specific applications and guarantees the processing of a certain functionality within a given time frame. This time-driven code is primarily used for software with high-level requirements regarding functional safety, such as braking or steering controls, and for fast cycle times, such as combustion-engine controls.
• Event- and time-driven software focuses on high-performance safety applications such as systems that support ADAS or highly automated driving (HAD) capabilities. These safety-critical applications need to run on isolated systems with a clear separation from other applications within the car.
• Event-driven software activates when certain events, such as customer interactions, occur. Event-driven software, including within the infotainment system, is not safety critical.
• Offboard software stack finds uses in software that is neither time critical nor safety relevant, and that usually has high computation or data-exchange needs, remote diagnostics, or location-based functions. Offboard software enables access to car data and functions including communications, security, and safety checks.

The specific hardware requirements in AD may delay the transition from the vertical integration of the AD domain controller for one more vehicle generation, however.

Hypothesis 3: Over-the-air vehicle-software updates will proliferate

OTA updates of vehicle software will cover more domains and devices, imposing new requirements on cybersecurity across the vehicle. OTA updates help overcome the shortcomings of today’s vehicle-electronics systems and provide a basis for future life-cycle management and monetization. Life-cycle management can increase customer satisfaction and experience, provide improved value stability for used cars, reduce warranty costs, and decrease variances among software versions in the field and thereby maintenance costs and effort. We see three main application areas for OTA updates:

• Security updates. A critical reason to update software is to address newly discovered security issues. Companies could flash them without recalls or customer visits to dealerships. Security updates reduce the risk of hacks, lower costs for OEMs, and can boost customer satisfaction.
• Rollout of new features. Software features such as those in the infotainment and ADAS domains also can be updated over the air. This approach would keep vehicles up to date with current consumer-electronics trends, which would support their ongoing attractiveness relative to future competing products. OEMs could also monetize new distinctive functions through paid updates, subscriptions, and similar plays.
• Bug fixing. Fixing bugs after the start of production (SOP) and before delivery would use the vehicle’s transport time to reduce the number of critical SOP delays caused by software issues. These bug fixes are also cheaper than today’s manual updating of postproduction cars.

A successful OTA update-management system requires a modern E/E architecture. This might include elements such as a consolidated domain or central computers with strong API consistency across models, backward-compatible software, and the availability of additional computing resources and the ability to handle differential updates. Also, engineering principles and decision-making processes will need to be adapted to enable the increased number of field updates. Future goals should include creating a clear post-SOP feature road map and focusing on lifetime value and TCO instead of one-time costs.

A systematic approach to over-the-air updates and sound mechanisms for their actual deployment to vehicles are both important, as noted by regulators and addressed by the recently adopted UN Regulation 156 on software updates and software-update management systems. As a result, OEMs will have to maintain not only a road map for software updates but also full oversight over which components and vehicles are affected by each update, ultimately demonstrating full control over interdependencies and potential side effects.

Hypothesis 4: Regional stack differences will be limited, except in China

Companies will limit regional stack differences to a dedicated set of applications and services crucial for respective regional ecosystems or legislation. One market is an exception: China, which most players will likely treat as a stand-alone technology ecosystem. In fact, China is becoming a key market at the forefront of software innovations for the vehicle of the future, increasing its relevance. Following global trends, Chinese OEMs are seeing increased adoption of ECU consolidation, Ethernet penetration, and OTA capabilities.

When developing systems for China, OEMs should consider five key factors:

1. Customer preferences. Customers’ openness to digital solutions and features requires swift reactions, especially on application layers (Exhibit 7). Chinese customers are tech savvy and show the greatest willingness of customers in any market to change brands for better autonomous or connectivity features. At the same time, many Chinese customers are price sensitive, especially on digital features that require new architectural configurations to achieve cost-effectiveness.
7

2. Technology. Chinese OEMs have started to build software teams and acquire talent to adopt global software-defined vehicle trends such as ECU consolidation, Ethernet penetration, and OTA software updates. They differentiate in their software features according to Chinese customer preferences and regulations—for example, in ADAS based on differences in driving style and government regulations and incentives. Also, some communication standards in China differ from those in other markets, so companies will need to adapt communication technologies such as telematic control units.
3. Ecosystem. The decoupled online ecosystem in China requires specific partnerships and technology adjustments for third-party-enabled applications, mainly resulting in changes to the infotainment software stack. Meanwhile, tech giants are actively pushing into the vehicle-software space, requiring OEMs to work hard to keep up in terms of innovation and execution speed.
4. Local regulation. China-specific regulations, especially those for data-related technologies and cloud infrastructure, require partly localized solutions in software and E/E architecture. For instance, companies may need to use approved Chinese cloud suppliers. These requirements pose challenges for international players addressing the market (including joint ventures), as well as for local players aiming to export.
5. Potential trade issues. Changes in governmental trade policies can affect decisions about vehicle technology. For example, China-specific hardware may be necessary for tech-stack elements that require the shipping of critical components, such as chips for the AD domain, from the United States to China.

In China, global OEMs will probably develop different ADAS/AD software, given different requirements (for example, different traffic flows) and specific regulatory barriers. They also will likely deploy different AD hardware in China, because of the need for hardware and software codesign in AD and the potential risks of export restrictions. Also, within the in-vehicle infotainment (IVI) and cockpit domain, we will see the emergence of a China-specific software stack to address different customer requirements and regulatory barriers, such as those affecting cloud providers. Different communication standards will require that the telematics-control-unit (TCU) box will be different for China. China’s unique cloud ecosystem and the requirement to keep the data in China will drive the use of different connectivity software, cloud infrastructure, and cloud back-end services.

The competitive arena

In the years ahead, new players will disrupt traditional value chains. As a consequence, the incumbent industrial players will have to significantly change how they compete in the automotive industry.

Hypothesis 5: New players will attack the traditional value chain

The established automotive value chain faces new competitors, with specialist hardware and software players overcoming traditional entry barriers throughout the layered horizontal technology stack. In addition, the clear separation of hardware and software allows pure players in these areas to assume a significant role in the ecosystem. These companies continue to enter the automotive market and challenge the status quo by employing established technologies from nonautomotive products, such as the consumer-electronics space.

Today, major consumer-electronics companies dominate the infotainment stack with screen-mirroring solutions and new automotive solutions. In fact, a currently ubiquitous global smartphone operating system will likely become the dominant solution in the infotainment domain, attracting more partners, while OEMs using this solution will significantly reduce their own development efforts in this area.

Digitally native OEMs benefit from new E/E architectures with a high degree of centralization and no legacy platforms. They have state-of-the-art OTA software-update capabilities and thus can sell upgrades to customers and generate revenues within the existing fleet while exciting customers in the process. In terms of digital skills and capabilities, these new OEMs also outperform incumbent automakers, especially in the quality of software developers they can attract, their software-development tool chains, and their large-scale agile development processes. They typically have a software-first mindset and access to huge amounts of field data for development. The industry has already observed new entrants in the automotive value chain from the software and consumer-electronics space, with major tech players introducing tailored systems specifically for automotive applications.

Leading electric-vehicle OEMs have challenged the current status quo of today’s vehicles. Besides blazing the way on e-mobility and battery technologies, they have developed a radical new electronics architecture that facilitates OTA updates and vehicle-feature downloads on demand and that allows them to optimize hardware resources for use cases such as autonomous driving. We expect improvements in autonomous-driving capabilities to power the next big wave of new players entering the market.

These developments will come in handy as OEMs confront multiple challenges simultaneously:

• Cost. With all ACES trends currently accelerating, the cost to keep pace and develop required features puts intense new pressure on OEMs’ R&D budgets, especially in software development.
• Complexity. The proliferation of features in the vehicle and the complexity of the hardware architecture are making the development of new software increasingly difficult.
• Legacy code. Old software and electronics architectures, combined with established supplier relationships, restrict OEM agility. Much of the required knowledge for a potential redevelopment resides with existing suppliers or is embedded within legacy ECUs.
• Time to market. All ACES trends require fast time to market and agile performance surpassing the innovation cycles previously known in the automotive space.
• Regulation. In parallel, new regulations on data, software, and security are creating additional challenges for OEMs.
• Infotainment stack commoditization. The rise of screen-mirroring solutions and the entrance of new tech players are causing the infotainment stack to become commoditized, leading to less differentiation and less revenue from high-margin features.

In response to these challenges, OEMs have embarked on a variety of strategic paths. For example, they’re collaborating more, forming new partnerships, and evolving existing partnerships to share the cost and risk of new development projects. Potential OEM partners include large technology players and tier-one suppliers, as well as innovative tier-two players. Automakers are making leaps when it comes to building in-house capabilities. Some have started to establish large in-house software departments with organic and inorganic growth initiatives. Companies are also focusing their own activities on specific functional domains while partnering in others.

Hypothesis 6: The industry will transform its traditional value chains

The automotive industry will transform its traditional, linear value chain by default, since no player can alone solve the technical and commercial challenges the sector currently faces. Instead, alliances and partnerships will evolve concerning key technological control points.

Historically, the roles of an OEM and its tier-one and tier-two suppliers have been clearly delineated. With the huge challenges ahead in automotive electronics and software development, those interfaces are becoming more intertwined. For example, OEMs have begun insourcing large shares of the software development previously sourced from suppliers. To safeguard these investments in software development, organizations are establishing multigenerational partnerships with corresponding technology suppliers, such as cloud companies. Depending on the purpose, these partnerships may take different organizational shapes. Nonequity development partnerships or alliances continue to emerge to address issues such as the development of joint standards; examples include the AUTOSAR Adaptive Platform, Android Automotive within the GENIVI Alliance, and ASAM standards for labeling training data for autonomous driving. These arrangements facilitate the development of distributed applications and ecosystems. Joint ventures and co-investment plays also are seen as reasonable strategies, mainly to share the risks of product development or to benefit from the experiences and assets of the partnering company.

Furthermore, the borders separating semiconductor players from tier-one suppliers are blurring with the growing importance of chipsets as a distinguishing factor for vehicle electronics, especially in autonomous driving. Consequently, partnerships are evolving as well. Another effect is that OEMs have started to skip the value chain by designing chips themselves and ordering them directly from semiconductor foundries. As a result, the value-add offered by a tier-one supplier increasingly centers on its ability to integrate.

These new relationships and ecosystem-integration challenges result from new business models and offerings. The basis for many “as a service” (XaaS) offerings is a strong partnership covering cloud and software elements and the ability to combine capabilities from engineering all the way to service. The automotive industry is developing more of these new business models, including content as a service (CaaS) in after-sales and subscription offerings, data monetization as a service (DaaS), software as a service (SaaS), and platform as a service (PaaS) in CPU licensing models. Even though specific customer adoption is still under discussion in the industry, we expect that successful players will monetize these predictable (from a cash-flow perspective) revenue streams and benefit from their additional upsell potential, thus capturing increased value from the resulting ecosystem integration.

Hypothesis 7: Technology stacks will consolidate as they move toward common archetypes

The technology stack and the number of suppliers will consolidate when the industry settles on a preferred archetype. For each major geography, two or three types of ecosystems will evolve for each domain, leading to a narrowing of the value that will drive future standards and regulation. We anticipate that consolidation will occur along the complete technology stack, from hardware to application software.

Hardware, especially chips. The high costs for chip design, which can range from $50 million to $500 million depending on the domain and required performance, will pay off only with high sales numbers. Leading players can distribute these costs across a larger number of devices and thus reduce the price point even further. We assume that the greatest consolidation will occur in the infotainment domain, followed by the autonomous-driving domain. We expect that the body domain, with its lower performance requirements, will experience the least consolidation.

Operating systems. Scale is important to attract an ecosystem of independent software developers for the operating system. For most OEMs, internal development would likely cost more than buying a standard solution, which can spread development costs across several customers.

Application software. Some application software, such as location-based services or voice control, improves as more data are shared with it, becoming more up to date or benefiting from having more “training” data. The largest players with the best data access will provide the preferred solutions and attract more customers. Application software used in a fully autonomous driving stack is so expensive that companies will increasingly consider sharing the development costs with other players. Standardized and proven APIs in the infotainment domain will link the E/E and software platform to the developer ecosystem, as happened with mobile devices. The creation of a vital developer community requires scale, so players in that space need to enter R&D partnerships and alliances. They should also drive the standardization process to attract third-party developers to the ecosystem.

Commercial implications

Developing the next generation of automotive E/E systems will require firm commercial commitments. These include the investment decisions based on new business cases with post-SOP revenue, investments across several vehicle generations, and investments in the necessary talent.

Hypothesis 8: Expansive new business cases will seek ongoing revenues

Next-generation architectures will require a comprehensive business case that looks far beyond the vehicle’s SOP and initial bill of materials. Unlike current automotive software, these next-gen solutions can be constantly advanced, so they enable continuous application development and monetization. Consequently, software’s share in the OEM’s business case will increase dramatically in the future, especially when it comes to the share of revenue generated after the purchase of a car, since OTA technologies will allow companies to install or “unlock” a feature after purchase (Exhibit 8).

8

With the development of non-embedded software, new business models are appearing. A perspective on full life-cycle monetization will be relevant for service offerings such as connected-car features via subscription fees or one-time purchase options. OTA updates focus on installing or unlocking features such as greater range or faster charging speeds in an electric vehicle or new ADAS/AD features. Such revenues could take the form of fixed fees or pay-per-use options. Another play involves data monetization from the sale of vehicle data collected through third-party services to provide usage-based insurance and other services.

Today’s decision basis primarily focuses on cost optimization and revenue optimization at scale, so it does not consider this more complex business case. Consequently, companies need to face the challenges of considering full lifetime cost and full lifetime value.

Full lifetime cost. Hardware and software costs will increase dramatically if OEMs do not address increased complexity on legacy platforms by investing in new E/E architectures. Furthermore, existing tool chains and processes are usually not yet laid out for fast, iterative software development, which makes integration and validation steps increasingly effort intensive. Shifting to centralized hardware will create synergy effects for the required processors and housing systems. It will also help reduce required wiring harness elements, the proliferation of which constitutes one of the thorniest problems in modern car design.

A new centralized, horizontal architecture will reduce development effort, because users can develop complex functions more easily with fewer communication interfaces between hardware components. The integration of software functions, especially in testing, will become easier, thanks to clear APIs and decoupling from hardware. Service-oriented architecture helps to further reduce integration and testing efforts, as formerly complex tasks break down into easily manageable software units with clearly defined interfaces. Maintenance cost is affected in two ways. On the one hand, extending the lifetime of the vehicle and the time during which updates are provided leads to an increase in total maintenance cost (managing many versions, backward compatibility, complying with Economic Commission for Europe requirements). On the other hand, the centralized architecture will reduce the average yearly maintenance costs per vehicle, because functionalities will be deployed to a much larger fleet and developers can more easily implement bug fixes or updates such as engineering change requests, since complexity has been reduced.

Full lifetime value. The business case will require a long-term perspective that considers the total cost of ownership, rather than simply the immediate improvement in material costs. Cost-optimization decisions will not lead to profit optimization, since the additional revenue streams should be factored into today’s discussion about the future offering structure to support investment in value-adding services down the line.

Hypothesis 9: Investments will require taking a bet beyond a single generation

Introducing the next generation of automotive E/E architectures will take significantly more upfront investments than incrementally updating an existing architecture would. The high costs for developing a greenfield architecture with low reuse of existing components will pay off only in future generations. Savings from the new E/E architecture have four main drivers:

1. The new architecture will make it possible to reuse elements of the system across vehicle platforms and E/E architecture generations, including hardware allowing OEMs to scale advantages in purchasing.
2. Separating application software from hardware allows OEMs to keep the same software while changing hardware suppliers for commercial reasons such as reducing change costs and lock-in effects.
3. The next-gen architecture will reduce software complexity by introducing clear abstraction layers in the form of APIs instead of point-to-point connections that require redevelopment for every functional change.
4. The new approach will enable a less complex wiring harness, leading to a less complicated bill of materials and reduced weight while increasing communication speeds.

The first generation of a new E/E architecture will require substantial upfront investments to renovate the architecture completely or redesign it from scratch, and will result in a more expensive platform. Higher costs in software development will result from the strong development effort needed for the implementation of new features based on new APIs and data-abstraction functionality. In addition to redeveloping legacy functions, companies need to introduce new tooling and reskill or upskill the workforce. Companies face learning-curve challenges on integration and the validation and verification of new architecture. However, they should see hardware costs decline, because reduced hardware needs should help to untangle wiring-harness requirements.

By the second generation, investments will start to pay off as a result of increasing reuse of software and reducing variants and complexity in both software and hardware. Variant reduction and volume effects will generate savings opportunities on processors. Effort expended on development, integration and validation, and verification will also decline, thanks to the limited number of software variants needed and the reduced complexity of integrating new features.

In sum, automotive companies can see significant benefits from making a courageous decision for one architecture, which will be applied and further developed for several generations to come. Conversely, reinventing the E/E architecture too often will lead to a large commercial risk that may not pay off.

Hypothesis 10: Success will require major talent and skill investment

For players in the automotive industries, software capabilities—from R&D-stage software maintenance to procurement and after-sales service—will be key. To achieve these capabilities, though, players will need to make large investments in acquiring, developing, and retaining new software and system-engineering talent and capabilities.

Comparing today’s hiring profiles across OEMs, suppliers, and emerging players, we identified a clear gap: emerging players have a far greater share of employees focused on software, compared with incumbent automotive companies (Exhibit 9).

9

To address this major gap, automotive incumbents need to consider three major strategic actions:

1. Prioritize. Given the limited talent available and the funds needed, most players are investing in key differentiating domains such as ADAS/AS and infotainment and connectivity. Additionally, investments in integration capabilities and cross-domain expertise—that is, software architects—will be critical.
2. Adapt the organization and its processes. Many automotive companies are creating dedicated software organizations at locations that are known for being tech friendly, thus supporting the long-term retention of talent.
3. Access talent via partnering and investments. Automotive companies can secure additional software talent and expertise by partnering and through targeted M&A plays.

Strategic imperatives

Automotive players, including OEMs, traditional suppliers, semiconductor companies, and high-tech giants, face a fast-evolving landscape, and most feel enormous pressure to play along. Given this pressure-cooker environment, we identified two strategic imperatives companies should follow to become software-enabled organizations (Exhibit 10).

10

1. Generate short-term returns now

By building new connected services and data-monetization use cases, companies can generate additional revenue potential for an existing fleet in only a few months to learn and “fail early” (in the best agile tradition). This approach can develop into a full life-cycle methodology that encompasses developing, launching, and scaling new software features, as well as building a life-cycle monetization unit.

2. Invest in transforming the business

To be competitive and secure the future of the vehicle platform, automotive players should take actions along several transformational dimensions:

Define a clear strategy, architecture, and road map. Companies should build a clear strategic direction to drive business transformation. In this context, choosing the right architecture and a complementary make-or-buy strategy is a strategic necessity, one that can lead to long-term success for OEMs and suppliers. Establishing an end-to-end view will play a key role in achieving that success, so companies should focus not just on current cost and competitor benchmarks but also on future industry standards, the company’s full business model (including future revenue and cost streams), and customer needs. Disruptions in the industry can cause intense uncertainty, highlighting the need for a strong and clear commitment to the chosen strategy backed up by senior leadership. Most important, this strategy must align with the organization’s current and future strengths and capabilities.

Make software the industry’s new quality standard. Industry players should ensure excellence in all software-development processes from requirement engineering to integration to validation to testing and beyond. They should invest in processes, methods, tools, and the required capabilities, and they should examine how well the organization performs in key areas. This will require regular project-health surveys; identification of opportunities for improvement in projects, processes, and tools; and regular surveys of employee satisfaction and learning needs.

With the increasing importance of OTA updates for quick bug fixes or new software functionalities, OEMs need to adapt their traditional processes to the new capabilities. Agile work processes in cross-functional teams (across the organization and suppliers) will support fast development cycles. Companies should enable these abilities beyond development applications by establishing continuous-integration and continuous-deployment (CI/CD) processes that rely on appropriate functional support.

To become software enabled, organizations will need state-of-the-art tools for software development and validation. Likewise, organizations should establish key software competencies, including system architecture, by hiring new people or upskilling current talent via learning journeys.

Position software as the driver of company-wide change. Organizational decision makers should consider the impact of software on the complete value chain (procurement, quality assurance, budgeting, sales, and after-sales) and adapt new development methods, such as agile development. They should ensure that customer needs and real customer research inform the complete process from the start. Customer forums, sounding boards, and surveys can facilitate a true rethinking of the product.

Establish a dedicated portfolio- and product-management team that defines software and hardware road maps based on strategic decisions and customer needs. Organizations should decouple hardware and software timelines to facilitate faster software-update cycles. It is important to optimize processes in software sourcing and procurement. Organizations also should define clear key performance indicators (KPIs) that allow cross-functional teams, including their own and suppliers’ engineers, to update software quickly. Organizations will also need to adapt their decision-making processes, moving from a pure-cost and pre-SOP perspective to a cross-life-cycle, full-value perspective.

Make talent and organizational excellence fundamental. Players would benefit from developing an overview regarding all required roles and skills and from reducing siloed thinking between domains. With respect to software talent, the automotive industry is in fierce competition with large pure-software players. In this situation, a targeted talent-sourcing strategy is key. Companies should develop one based on a talent-to-value analysis that allows for the identification of their key talent.

Talent acquisition goes beyond pure software talent. Experienced project managers who consistently ensure the timely delivery of software projects, system and software architects, scrum masters, and other related capabilities throughout the entire organization are necessary to translate between the “traditional automotive” and the “new software world.”

The increased importance of software and the decoupling of hardware- and software-development processes may require a reorganization—for example, by creating dedicated software units or conducting an agile transformation. Having chief architects at a department leadership level will help establish a consistent architecture design based on the strategic decisions taken. Trusted and empowered leaders need to lead these units to ensure the success of the organizational redesign.

The automotive industry will ultimately become a software-enabled industry, either transformed by its traditional players or reimagined by new entrants. To succeed, automotive players must act now, enabling flat organizational hierarchies, making software the priority for top management, creating a cross-functional project setup instead of a line organization, redefining the hardware and software architecture, and tapping into new sources of talent. While the new game is just starting, players—especially incumbents—need to put the pedal to the metal now to win this digital race.