Digital transformation currently completely turns the Automotive industry upside down – as software becomes the centerpiece of vehicle functionality, the accompanying services start to dominate the customer’s perception of experience and value. These services require ubiquitous connectivity and transform every vehicle not only into a “smartphone on wheels” but also into a “rolling data center” due to the amount of data generated, processed and exchanged with various cloud- or edge-based backends. On top of that, digital services are also a vital part of two megatrends in the automotive industry: electrification and autonomous driving.
OEMs started to adapt to these challenges, but with respect to over 100 years of “the art of engineering”, metal working and heavy combustion engines, they are facing a huge transformation challenge. And they need to change fast if they are looking to stay competitive with new digital market entrants and technology hyperscalers.
We get cues on how this could play out, if we take a look at an industry that was forced to start its digital transformation ca. 15 years prior to the automotive industry in order to apply the lessons learnt and avoid pitfalls along the route. The telecommunications industry had to enter a digital transformation in the early 2000s, when IP technology rapidly replaced circuit-switched connections and mobile connectivity – ubiquitous and with dizzy speed and data volumes – became the absolute must to fulfil their customers’ expectations. Telcos continue the transformation journey today by adopting a new way to build mobile network infrastructure.
One of the most crucial challenges for the automotive industry concerns the vehicle itself, or rather its basic electronic architecture. Within the vehicle system, one can see a clear trend towards consolidation of electronic control units (ECUs), going from around 100 ECUs to a much smaller amount of high-performance compute clusters, running industry-specific vehicle operating systems. Accordingly, we can expect a sharp increase in abstraction between hardware and software layers, largely eliminating the prevalent firmware components within contemporary ECUs in favor of flexible application and service layers as part of the vehicle operating system. Done the right way, this could be a significant step towards making connected vehicles a true contender in the contest for customer attention span. But what is the right way? And once found, how can we ensure that organizations stay on the right path? To answer these questions, it makes sense to consider examples from other industries.
O-RAN is short for Open Radio Access Network – a telecommunications initiative to create a virtualized, fully interoperable RAN architecture based on open standards, software components and as many as possible off-the-shelf hardware components put together using the latest system engineering approaches. But why is this relevant for automotive OEMs? Simply put, modern vehicles are essentially special-purpose networks: in and of themselves as well as a whole fleet. Therefore, web-scale system thinking and network technology knowhow are not only critical for their day-to-day operation, but can provide guidance on how to build and manage them. And while certainly there are several industry-specific questions and challenges, we believe that some best practices and overall learnings from the O-RAN approach may be of value in the automotive industry as well.
Softwarization and Disaggregation
The major idea behind O-RAN is to open up the interfaces in the hitherto tightly coupled RAN vendor offerings – coming along as “black boxes” – and to reinvigorate the innovation capacity of the entire industry instead of being limited to the ideas of some large vendors. The target picture is a thriving technological ecosystem with all “monolithic” hardware-bound units decomposed, softwarized, and modularized thus enabling new end-to-end solutions based on best-in-class individual network functions. Today’s picture is the exact opposite: Telco carriers need to rely upon closed end-to-end solutions from a couple of leading vendors. Each carrier roadmap is almost exclusively dependent on the one of the selected vendor(s), dramatically slowing down innovation and time-to-market. O-RAN takes some pages from the softwarization and cloudification playbook, adds the carrier experience, and introduces a new way to build the next generation of mobile network infrastructure.
Figure 1: The idea behind O-RAN. Source: Timotheus Höttges, Deutsche Telekom AG, Townhall Meeting 02.10.2020.
Figure 1 illustrates the disaggregation process taking hold in the telco industry. Today’s fronthaul is closed: black boxes implement implicit network function chains without any transparency or APIs allowing deep instrumentation and possibilities to flexibly integrate new functionality. The result: rollout decisions that restrict carrier options for the next 5-10 years, a situation that no software or cloud leader would ever contemplate. Closed-boxed vendors offer so-called cloudified options today but regardless of the implementation, the key principle is proprietary and closed architecture and implementation. O-RAN on the other hand, explicitly opens up the black boxes, establishes clear interfaces, adopts modern deployment methodologies, invites new vendors to join the ecosystem and bring new innovations as well as a modern operating model.
Open Systems promote Dynamism
O-RAN strives for an open system, allowing for a greater variety of ideas and participants. This directly translates into a more dynamic system, as new participants will introduce new perspectives, solution approaches and expertise, creating alternative pathways and forcing existing participants to adapt in order to stay relevant. At the same time, the open nature of the system allows competitors to build on each other’s solutions, rather than being locked into their own proprietary ecosystem. Open source software in particular allows all system participants to benefit from the results, thus promoting open collaboration on new and creative approaches. The result is a more resilient system, with not only a greater degree of evolvability, development velocity, and adaptability which today is unheard of in the OEM space, but also an overall increase in quality and efficiency.
In an industry known for long product lifecycles, extensive supplier relationships and firmly established process landscapes, open systems can provide vital new impulses for the development of new platforms and technologies. Open Source is not a panacea – not all automotive use cases may be well-suited to development activities that are open to partners, competitors and potentially malicious users alike. But since coexistence of closed and open source projects is entirely possible, a smart combination may provide just the right amount of openness to kickstart a necessary evolution in automotive software development.
Enable a Flexible Split Along Functional Lines
The question of interoperability affords another way to think about these open systems. In order to become a feasible alternative to a proprietary end-to-end ecosystem, component suppliers in an open system require the ability to seamlessly integrate with other component providers. The target picture is a system able to accommodate a split of functionality between different competitors without the need for significant dedicated integration efforts. This requires a careful assessment of the underlying vehicle architecture. Rather than thinking about vehicle functionality in terms of self-contained ECUs, one should consider whether the features provided by one ECU could be conceivably provided more efficiently by multiple partners.
It might for example be reasonable to target a split between sensor data processing and actuator logic, rather than persisting with a fixed pairing of sensor and actuator control inside one ECU-like construct. Conversely, new functionality implemented in one component should be accessible and easily consumed through standard APIs anywhere on the vehicle system. For example, the sensors in the front lights that manage the adaptive high beam lightning, might also be useful for in-car lightning, collision warning or automated sun visors in case of dazzling sunlight.
Promote Standardization of Interfaces
This flexible functional split can be accommodated through version-controlled, standardized interfaces, rather than rigid standards for overall system functionality. Provided with clear standards for interface design and implementation, different suppliers can now focus on developing components within their specific area of expertise. Not only does this create greater flexibility with regards to component usage, but it also allows simplified and automated testing and streamlines multi-component development activities, which are some of the dominant drivers of dependencies, alignment needs and overall complexity in contemporary automotive software development. Enabling a flexible split of functionality through standardized interfaces and open architecture principles has also been a defining feature of this approach in system design from web-scale apps to O-RAN. A similar approach could also help automotive players to preserve their industry’s long-term viability.
Remove entry-barriers to the supplier market
Much of the innovation capacity within the automotive industry hinges on complex supplier networks. Different tiers of suppliers promote research and development within their business areas, allowing the automotive OEM to act primarily as an integrator and assembler of various supplier systems. Originally devised as a means to increase the efficiency of component production, this has led to a situation in which a limited group of entrenched suppliers provide a highly integrated (in some cases even end-to-end) portfolio to different OEM customers. While this does enable significant economies of scale and the associated efficiency gains, the effects on overall innovation potential are somewhat questionable. New entrants to this market are invariably hindered by substantial entry barriers, decreasing the system’s overall dynamism and limiting competition.
As a result, OEMs may face issues with regards to vendor lock-in, high component pricing and low innovation speed. Particularly in the realm of digital platforms and services, this may lead to significant dependencies, causing issues with vertical re-integration or an exchange of suppliers down the line. Unsurprisingly, we can observe similar dynamics in the telecommunications industry. Initiatives like O-RAN however have the potential to mitigate these developments by removing entry barriers through open standards, thus allowing new entrants to increase competition and overall dynamism.
Leverage Open Source Projects to focus on customer-facing differentiation
O-RAN is not just a set of open standards defined by expert working groups. The O-RAN Alliance, an industry group led by major carriers, also supports the O-RAN Software Community, an Open Source development project hosted by the Linux Foundation. Open Source is an excellent way for industry associations to go beyond a pure knowledge exchange and actually start developing the components they will need to succeed as an industry. Contributing resources to these development projects allows immediate progress on these components without the need for extensive oversight, management bottlenecks and lengthy partner- and contract alignment that would typically result from joint ventures etc. And although Open Source projects do not necessarily build intellectual property and competitive advantages for their participants (as the results are shared to all interested parties), they are an excellent way to build digital capabilities and prevent dependencies on oligopolistic platform and service providers.
Considering that the basic vehicle architecture is not a customer-facing functionality, but rather a key enabler for OEM-specific differentiation later on, this should not be seen as a limitation, but rather as an advantage for an industry that is increasingly facing competition by digital service providers and internet hyperscalers. If automotive players wish to compete with these new market entrants on customer-facing features, they must be able to provide underlying platform and commodity layers as efficiently as possible, while still retaining a sufficient degree of sovereignty over these enablers. Limited investments into automotive open source software may enable significant cost-savings down the road based on readily available software assets as well as the necessary development and operations capacities for subsequent vertical reintegration.
The automotive and telecommunications industries are not the same. But they face some challenges that are quite similar. By learning from each other’s successes and failures, both industries stand to gain not only important lessons, but also useful capabilities for future initiatives. O-RAN could very well serve as a blueprint for automotive initiatives looking to develop the future in-car operating system. And although many automotive OEMs have indicated that they might want to pursue a more proprietary route with dedicated OEM operating systems, the successes of open-source projects in other industries would suggest a somewhat different route. Harnessing the potential of alternative open-source projects such as Automotive Grade Linux is an option that could provide tremendous value not only to OEMs and their partner ecosystems, but also automotive customers in general.