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? 1 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), 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.
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.
By Dr. Harald Proff, Thomas Pottebaum & Philipp Wolff
Read the full report here.
