How Can We Trust Software in Cars?How Can We Trust Software in Cars?

Much of our lives today run on software. The very backbone of our healthcare and transportation systems is digital. Today’s vehicles, from farm machinery to the modern family car, run on software just as surely as they run on fuel. As patients, passengers, and drivers, we are expected to simply trust that the software is safe. The question we need to ask is whether that is a “safe” assumption to make and, if not, what needs to be done to make the software our lives depend on worthy of our trust.

The rules and assumptions applied to automotive and commercial truck software are different from those in other fields. In the physical world, we expect and anticipate third-party review and analysis of all engineering that goes into designing and developing the products we buy. In business, we expect auditors to review the books, prepare statements of account, and certify that the statements are accurate.

And yet, in the world of proprietary software in general, it is assumed that we should trust that the company behind the software is doing things right. Why? Especially when so much of our lives are dependent on digital systems — as demonstrated most recently by the massive CrowdStrike outage — why should we trust that software is safe?

At least for now, automotive companies have concluded they take certifications — such as IEC 61508 and ISO 26262 — to mean that a given piece of software is safe. The unfortunate reality is that in essence, such certifications only mean that an auditor saw ample evidence that the company followed approved processes.

Related:Why Software-Defined Vehicles Are the Future

The fact is that complying with IEC or ISO standards or other industry certifications does not, in itself, make a digital system safe. Some of the recommended processes are no longer considered best practices, and standards generally do not cope well with software at scale. In some cases, software integration is barely considered as part of the certification process, which can mean missing significant risks. Certifications also struggle to keep up with system updates and upgrades.  As written, they presume bespoke software development rather than existing code or open-source software development.

In sum, confusing certification for safety leaves companies and consumers vulnerable to future software failures, cyberattacks, financial loss, and a potential erosion of public confidence. So, what can we, and should we, do differently?

Shifting from safe software to trustable software

Instead of talking in vague terms about software safety, there needs to be a higher bar: building software that is trustable — meaning evidence is available to support every single one of these six claims:

Related:Software-Defined Vehicle Technology Lets Rivian Dress Its EVs in Halloween Costumes

1.         Provenance. We know where the software comes from and who is responsible for it, and we have confidence in them.

2.         Construction. We know how to build the software, reproducibly, from the source.

3.         Changes. We can upgrade the software and be confident that it will not break or regress.

4.         Expectations. We know what the software must do, and what it must not do.

5.         Results. The software does what it must do, and it does not do what it must not do.

6.         Confidence. We measure and declare our confidence that the software will not cause harm.

A trustable process is one that can be audited at any point during design, construction, and operation to assess the degree to which it can be trusted. That is a much higher standard than is currently used, and it provides a solid platform to establish trust in our software-driven digital world moving forward.

Real-world challenges, trustable solutions

Here’s a fairly common scenario: An automotive OEM is struggling to get adequate technical support and maintenance from a software supplier. The reason is that the vendor can’t supply the support profitably, so they often want to increase their fees while reducing the scope of their work, leaving the OEM to cope independently without resolution.

Related:Three Factors to Consider When Using Automated Tools to Accelerate Software-Defined Vehicle Development

In another instance, an agri-tech company that relies on software to optimize irrigation systems can’t keep up with updates and integrations needed as the farms they support expand. Ultimately, the vendor begins increasing fees and scaling back their once-included support services, leaving the company vulnerable during critical growing seasons.

Similarly, a medical technology company that uses software to manage real-time patient data from wearable devices. As new regulatory requirements for data privacy and security are passed, the company must update its software to comply with the latest standards. However, the software vendor is slow to adapt and demands significant fees to implement the changes, putting the company at risk of non-compliance and patient trust declines.

When you dig into impasses like these, the problem often originates with the supplier’s source code. If vendors can be convinced to release it (with an appropriately restricted license), companies can institute a trustable process and handle its maintenance at a lower cost over the long term. This means they gain access to the IP and improve the quality of their support and maintenance, while the vendor is motivated by a desire to be freed from a commitment they would otherwise struggle to satisfy.

Another common issue for automotive OEMs is unreliable and inefficient upgrades to in-market software systems. OEMs often find out too late that upgrade procedures frequently involve manual processes and software solutions from multiple vendors that don’t play well together. Using open-source tools and trustable practices, it’s possible to develop custom solutions that reduce update failure rates, save time, and make it possible to introduce new market features into older vehicles.

Building a trustable future

If all this sounds simple or straightforward, I can assure you that it is not. But as more systems run AI and other software of growing complexity, we must do more to ensure customer safety and long-term maintainability. That starts with acknowledging that certification does not equal safety, and that software must be more than safe—it must be trustable.