Automakers’ Control Over Software Outweighs the Risks

As with any technology, the ability to develop software in-house means that the developer, in this case the automaker, can control the ecosystem.

Additionally, systems developed in-house provide a suitable platform to evolve the functionality of these systems as the carmaker sees fit in the future, essentially, allowing it to retain future control of the direction of development. However, a number of challenges stand in the way between the drive to develop in-house software for autonomous vehicles and it’s not the only cost automakers need to bear when deploying these capabilities.

Incorrectly balancing or betting internal resources on the wrong sub-segment of autonomy or ADAS development can limit or introduce constraints that impact the automaker’s ability to lead the market, or in some cases, catch up. “Autonomous systems developers will continue to expand their solutions portfolio, either through in-house development or through acquisitions,” Juniper Research senior analyst Sam Barker told TU-Automotive. “However, given that autonomous vehicle solutions are very niche, we anticipate that the majority of this expansion will occur through in-house development.”

He noted that acquisitions of other specialists may look to bolster this in-house development and automakers with a clear picture of their software environment will be able to better identify software and capability gaps, as well as which vendors can actually fill them. When it comes to ADAS systems and autonomous vehicle capabilities of increasing sophistication, Barker noted the code behind software solutions will be as complex as the solution requires it to be. “The demand for the code comes from the demand to develop a new solution,” he said.

However, one of the potential pitfalls for developing systems in-house is the relatively limited knowledge compared to looking to outside sources. This is notable in the development of autonomous systems, given the specialist nature of many roles. For example, a large part of automotive software relationships fail because of the required additional work needed to adapt third party software for the automaker or supplier.

Automakers can’t do everything and the evolution of the automotive industry, which includes AVs and ADAS and mobility as a service (MaaS), is already spreading automakers thin in terms of their potential to do list. “We are already seeing a combination of approaches to help OEMs bridge the software capabilities and expertise around ADAS and AVs,” noted IDC’s Matt Arcano.

This includes acquisitions. Following the lead of General Motors with the acquisition of Cruise, some carmakers see the importance of bringing the technology and expertise of a tech companies in-house. Arcano explained this provides the manufacturer the greatest amount of control and integration capabilities with the third party, as well as a defined line of future funding to the tech company. “However, this strategy can also introduce additional risks in terms of governance, bureaucracy, traditional automotive timelines, as well as cultural fit for the tech company,” he noted.

Following the lead of Ford, as well as Volkswagen, by taking a substantial investment position in a tech company offering a self-driving stack provides (in this case Argo AI), an automaker looks to formalize a relationship with a tech company with ADAS and AV capabilities without outright control. “This helps to reduce some of the challenges around corporation oversight risk, while allowing the tech company to remain largely in control of their development and customer and business development pathways,” Arcano said.

He also pointed out that with examples including both Waymo and Mobileye, the market has seen automakers, often working alongside tier suppliers, develop supplier or vendor relationships with tech companies to introduce AV/ADAS capabilities. In these relationships, the role of the automaker can vary greatly from merely being a supplier to the AV stack provider, for example Jaguar Land Rover and Fiat Chrysler Automobiles with Waymo, to developing a production vehicle program with custom hardware and software capabilities, as BMW did with Mobileye.

Furthermore, as machine-learning (ML) is introduced into ADAS and AV function development, Arcano said there is a line drawn between the addition of discrete codified functions versus the use of ML libraries and models. “Of course, there needs to be a balance between the two but while striking that balance, automakers and tech companies need to understand what functions and capabilities need discrete coding versus the use of tools like ML,” he said.

In addition, the challenge around adding source lines of code (SLOC) in general is that the more code you have, the greater the challenge it is to document, test, debug, scan for vulnerabilities and, ultimately, maintain and lifecycle manage your code base. “With pretty consistent error rates typically found over large amounts of SLOC, the greater the number of lines, the more active and comprehensive a vendor needs to be to ensure that they code remains secure from a cyber security standpoint,” Arcano said.

From the perspective of future proofing, automakers that are able to control and define more and more of the vehicle’s software themselves, will be in a better position to evolve as customer expectations continue to grow. “By bringing software development in-house, automakers have the ability to deploy and test new ways to interact with their customers without requiring the cooperation, contracts, or aligned vision of third parties,” he said. “This may include MaaS, new infotainment or car-control features, or even the development of data monetization frameworks.”