The automotive industry is going through several disruptions simultaneously; electrification, carsharing, autonomous driving, and personalization fuel the definition of the Software-defined Vehicle (SDV).
All major OEMs, Tier1s, and the broader industry are striving to stay ahead in this technology race, increasingly being defined by software and Autonomous Vehicles (AVs). Especially for AVs, the winners will be those who get to market and scale a production-grade solution first.
For the automotive and autonomous vehicle industries, the key question, therefore, becomes: how can you shorten the time to market and innovate faster in software and AVs to meet more demanding customer requirements?
To answer this question, one must look at how software plays a role in vehicles, today and in the future.
Software is not new in the automotive industry. What is new, however, is the essential role it will play in the ability to differentiate and compete going forward, especially with the development of AVs.
With autonomous vehicles, an additional major software system is introduced: the automated (AI) driver. Thus, at a high level, you can divide an AV architecture into two major systems:
1) the vehicle and
2) the AI driver.
Software plays a very different role in these components.
Growing vehicle component software complexity
A modern vehicle itself already contains a considerable amount of software, up to 100 million lines of code and increasing. Today’s vehicles already possess an order of magnitude more software than airplanes, the Mars Rover, or a space shuttle, to put this into perspective.
That being said, this is not an apples-to-apples comparison. For many of the companies shown on the chart above, software is central to the business and they produce the software entirely in-house (e.g., Microsoft and Meta).
In a vehicle, however, there are Tier1 suppliers that traditionally have written or integrated the bulk of the component software for OEMs. For example, many automotive models use Android, and in doing so, simply reusing an operating system for the In-Vehicle Infotainment (IVI) system can contribute significantly in terms of lines of code. While quicker, incorporating software through this method, still creates a major software maintenance complexity for the OEM, especially in terms of cybersecurity and managing discovered software vulnerabilities across all components.
Over time, the most challenging aspect of managing the vehicle software becomes the exponentially growing number of software-hardware component combinations. A single vehicle model will have annual revisions, where some hardware components are changed. Therefore, each vehicle model year requires a different combination of these potential 100s of hardware components with matching required software.
While the growth in software complexity is likely to continue as vehicle components (such as, braking controllers) gradually become smarter, it is important to note this is not where main innovation happens.
AI software complexity
Although the amount of software in the vehicle itself can look close to unmanageable, unless properly planned for, introducing an AI driver takes this an order of magnitude higher.
When considering autonomous vehicles, software can be divided further: 1) subsystems, 2) the AI framework, and 3) the AI itself (core software, model, and data).
Subsystems are the sensors that are needed for the AI to understand its environment. For example, Lidar, radar, and cameras are each considered a subsystem, and they have several components each. As an analogy to a human driver, these are sensors that function as the “eyes and ears”.
The AI framework contains the software and applications required to operate. The framework includes the operating system and all libraries needed for the main AI application software to function.
Finally, the AI itself is the “brain” of the driver, that relies on these other components to sense its environment and act accordingly. The AI can contain software, models, and any additional data needed, like mapping data.
To give an indication of the relative complexity, the graph below shows the autonomous vehicle software size from a real autonomous vehicle in pilot today.
As can easily be seen, the AI - that includes the main software and mapping data - is the vast majority of software to manage. Note that the use and size of mapping data can vary depending on the AV technology deployed.
Innovating with short software iteration cycles
With that context in mind, back to the original question: How can you innovate faster in autonomous vehicles and stay ahead of the competition?
As it turns out, this is a well-known challenge in the software industry, especially for cloud applications, from which there are several lessons learned that can be applied to AV innovation.
Thus, Operations created a significant process around testing and deploying the software. But, the repercussions of Operations’ solution to their issue meant Development could wait indefinitely for their software to go into production. As such, friction and inefficient back-and-forth between the departments occurred. When release dates were missed or the website went down, who was responsible?
In simple terms, the solution Allspaw and Hammond outlined in their presentation was to break down those silos and reduce the risk by deploying many small changes every day, rather than a big set of changes that would go through testing every quarter. The counter-intuitive reality was that deploying frequently is less risky than deploying seldomly.
For example, if the website went down at any given point under frequent deployment, you could quite accurately narrow down to the specific software changes that probably caused it. One simply looked at which deployment(s) performed right before the website went down; and since those deployments made very small changes, one would know where to look for problems, more quickly and accurately identifying the culprit.
Today's web organizations have evolved greatly and embody this DevOps movement. The core philosophy and resulting infrastructure embedded in today’s organizations is a Continuous Integration (CI) / Continuous Deployment (CD) pipeline. Automated end-to-end, the CI/CD pipeline takes the latest development code and puts it into the production environment.
A CI/CD pipeline
An implementation of a CI/CD pipeline varies across organizations and generally comprises many different solutions. The goal is to automatically take code from a developer and get it into production, with as little risk and time spent as possible.
DevOps for automotive and AV
In the context of the automotive industry and especially autonomous vehicles, what can one learn from the DevOps movement?
The core premise for the original Velocity presentation was the value of shorter release cycles (i.e., new updates to production users faster) outweighed the risks (potentially more frequent but smaller, manageable issues). Breaking or short outages were tolerable, maybe not even noticeable by anyone. Therefore, the risk of going more-or-less straight to production, and then reverting in case of a failure could be acceptable for quick releases, faster innovation, and more seamless operations.
This is, of course, not uniformly true for a vehicle, which has massive safety and human life implications. Likewise, certain regulations also don’t allow this mode of operation.
So, at least, there needs to be a split between safety-related and non-safety-related software. Safety-related software requires its own, more rigorous process that may also involve regulators. And, the good news is that the safety-related software typically does not need to be updated frequently. It is usually quite simple by design, so that it can easily be analyzed and certified. In addition, it is not normally directly interfacing with the user. Overall, updating safety-related software is more risky and there is often little in terms of innovation to be gained.
Non-safety related software generally relates to features that cannot directly threaten life, even if it goes wrong. For example, the software on the UI of displays (IVI system) even the AV can be considered non-safety related (as it can be overridden). Also, this software that interacts more directly with the user, or implements the key components of the AV are much more important to frequently iterate on. This software is the crucial differentiator for the organization, and where competence and innovation should focus. In addition, this software is normally not directly safety-related.
In summary, we should focus on shortening iteration cycles for software that 1) is directly interfacing with the user, and 2) where we can innovate and differentiate.
How short should development cycles be in AV?
Of course, there are probably many answers to this question and a “one size fits all” does not exist. Development cycle length depends on many factors, such as the maturity of the software team and the infrastructure available to them as well as the budget and competitive situation of the organization.
As a real-world example, however, it is interesting to consider the frequency of deployments from one autonomous vehicle organization.
Clearly, the software that differentiates the autonomous vehicle (the AI driver itself) is the one that, by far, receives the most frequent updates. And this software is indeed approaching the level of update frequency described in the 2009 Velocity presentation that sparked the DevOps movement.
From DevOps to AVs: Lessons learned
Automotive and autonomous vehicle manufacturers must focus on their core competence and differentiation in order to win in the marketplace. For software development and releases, this means focusing on short software iteration cycles on the autonomy software and what the user interacts with.
Over-the-air (OTA) updates are not new in the automotive industry; they have been justified for over a decade as a method to save money and lower risk (i.e., during a recall event). However, with the acceleration of AI, AVs, and technology, OTA updates will transition from a nice-to-have to must-have.
Going forward innovation will be the key driver for everything related to automotive software and OTA updates: shorten software iteration cycles in order to learn and innovate faster in the marketplace. To do this in practice, OEMs need to implement continuous and short iteration cycles from their software developers to production vehicles, aligned with the goals of the DevOps movement.