Software for automotive design - the questions and answers

Beyond code, the number of chips in vehicles is expected to triple as autonomous vehicles integrate additional ECUs with SoCs, microcontrollers for cameras, sensors, LiDAR, mapping, and more. All those require software to function properly.

All this is having - and will continue to have - huge implications on software development processes for any organisation involved in the design of automotive products, both culturally and technically. Creating and delivering increasingly sophisticated and complex vehicles also has to happen in a highly regulated and competitive industry, which simultaneously is being disrupted from several directions.

For instance, electrified, autonomous, shared, connected, and regularly updated vehicles will become a standard expectation among consumers, rather than the luxury they are today. At the same time, the economic model around car purchase is changing. The move from outright purchase or leasing to rental and car sharing is bringing in new players, such as Car2Go, now owned by Daimler.

As vehicles become more connected, including vehicle-to-everything (V2X), infotainment, and traffic systems, this too will pave the way for new business models and services. Innovations like Android Auto and Apple Car Play are just the beginning, so automotive OEMs and Tier 1 suppliers will need to support that connectivity. Updates will become more frequent, and over-the-air (OTA) updates will become a necessity, rather than a nice-to-have.

Implications for software development 

For the people creating the software to support this brave new world, there are some fundamental challenges to address. For instance, as vehicles become increasingly connected and autonomous, the need to ensure safety and security is obviously paramount.

When Perforce surveyed over 400 automotive professionals in 2019, 40% of them cited safety as their top concern, with security rated their third greatest concern (after quality in second place).

Ensuring adherence to functional safety standards such as ISO 26262 can be challenging at the best of times. In the same Perforce survey, of those who cited safety as their top concern, 49% said it was difficult and time consuming to meet every requirement for ISO 26262. As codebases grow, that will become even harder. New standards such as Safety of the Intended Functionality (SOTIF) for automotive vehicles are also emerging.

The challenge for development teams in any industry is that the creation of software is the root cause of many vulnerabilities, which in the future, can lead to failure, malfunction, or create opportunities for hackers. In a vehicle, these problems can obviously have catastrophic, tragic consequences.

With new entrants in the automotive supply chain, the need for greater collaboration across even more types of contributor will escalate, so finding ways for disparate, dispersed teams and organisations to work as one unit on a project becomes even more difficult than it is already. Each component may require someone else to build it, and no matter who is building each piece of hardware and software, everything will need to work together.

Big data and Kubernetes will need to be leveraged and there will be a range of programming languages required: C, C++, Python, and Java, for starters. While C is still the top programming language used by Perforce’s survey respondents, almost 50% of automotive professionals say their organisation is using C++. While this programming language gives developers a lot of scope for innovation, it also introduces far more room for interpretation, challenging even the most skilled individual. This can exacerbate the risk of software vulnerabilities occurring.

A new look at software development 

The good news that there are ways in which to tackle what may seem insurmountable challenges. Organisations involved in automotive software development are already reassessing and changing the processes, methodologies, and tools they use.

For example, to deal with the volume and diversity of digital assets across disparate teams and siloed systems, they are adopting what is often referred to as a ‘single source of truth’. Usually with a version control engine as its basis, this approach provides visibility into what changes are made, by who, what, when, and where. Also, people waste less time looking for assets and it becomes easier to reuse components, and at a local level, all of which contributes towards faster work.

In automotive projects, the beauty of a single source of truth is that both software and hardware teams, whether in-house or externally can collaborate more efficiently, without having to change the way they work or their tools. As well as real-time insight into a project’s status, it is possible to roll back to a previous version of the project, either to discover the source of an issue, or to provide evidence to auditors, for instance to demonstrate ISO 26262 compliance.

DevOps pioneer Gene Kim cited version control as an important part of DevOps, the methodology that is gradually transforming software development across all kinds of industries with software at the core, by helping to break down the barriers between development and operational teams.

Using version control is critical for success in DevOps, especially in automotive. This includes adopting continuous integration/continuous delivery, often by integrating with Jenkins, to improve performance. Developers improve productivity and spend less time waiting when they use the right version control, even increasingly distributed teams involved in automotive hardware/software development. The size and complexity of assets involved in automotive will continue to grow, and using the right version control helps teams manage assets and scale up. All of this also supports teams using Agile.

When it comes to security, there are several practical steps that can be taken during software development. While the ‘single source of truth’ can help to surface any issues, access to IP can also be restricted and allowed on a granular basis, for instance by user, file, location, and so on. This provides better control, especially around the risks of the ‘insider threat’, where problems can be either maliciously or accidentally incurred. However, not all version control systems have the same level of inherent security, plus in the automotive sector, it is essential to choose one that is able to accommodate all the different assets involved, not one that is really only optimised for code.

Modernising automotive development - at scale

The tools that hardware and software developers have utilised in the past will not be enough to support innovation in an even more competitive era. Carefully considering which version control tool to use will be imperative to success. Legacy tools may offer scalability, but it is important to make sure that they have the modern features needed to accelerate development, drive innovation, and shift ahead of the competition. Open source tools will have those modern features, but struggle to handle the size and complexity of code and files used in automotive design.

Tackling the challenges involved requires a plan of attack on a number of fronts, and at every stage of the software lifecycle. No one would claim it is easy, but given the right tools, methodologies and processes, it is possible to create safer, more secure, and high quality software in the increasingly regulated, complex, competitive, and fast moving automotive industry.