I touched on vendor lock-in, but we have plenty of firsthand examples of customers whose choices led them to something even worse: situations where they were no longer able to maintain their software stack to comply with the law.

The law in question is UN Regulation No. 155 (UN R155), and while it comes from the UN Economic Commission for Europe (UNECE), it reaches well beyond Europe – with signatories including the EU, UK, and Japan. South Korea and China have both introduced domestic rules that heavily reflect it, alongside ISO/SAE 21434 (which is more an engineering methodology than a legally binding market access rule). While not legally mandated in the US, it remains highly influential in the American automotive market. The European Union’s Cyber Resilience Act (CRA) adds obligations of its own for many connected components that sit outside vehicle type approval.

UN R155 requires vehicle manufacturers (and, through them, their Tier 1s) to monitor, detect, and respond to cybersecurity threats for the life of every vehicle they sell, long after production ends. Once you put a vehicle model on the road, you’re responsible for keeping it secure until the last of those vehicles leaves it.

The question therefore becomes how long each vehicle will stay on that road. A vehicle platform program might run for five years, meaning some cars on that platform may be bought six or seven years after production began. The average light vehicle on US roads is now 12.8 years old, according to S&P Global Mobility, and many will last far longer. And because the SDV promises drivers a better experience with age, they have every reason to keep their cars longer still. Based on the discussions we’ve had, this legislation is going to have teeth for many OEMs.

The only way to mitigate a wave of future risk is to take steps now to make sure you can continue to deliver security updates, and that starts with choosing a compute architecture that will still be here, open and capable of running your code for decades to come.

Codethink has done a lot of work on functional safety in cars, including a lot of public discourse about what meeting the ISO 26262 standard really means for modern, complex and connected systems. Our bottom line is this: no matter how safe you think your vehicle is, if it relies on software and connects to something else in any way, any security vulnerability is a safety hazard.

Maybe not today, but in five or ten years. Nefarious actors don’t stop searching for loopholes, and we’ve seen a number of high-profile security stories in recent months where security researchers have taken control of critical systems within a vehicle. I don’t need to list out which of those systems a malicious actor might choose to disable at speed for it to become obvious why security and safety go hand in hand.

On that basis, the need to understand what’s in your system, and to know how you’re going to frame your security story, is one of the fundamental building blocks you’ll need for safety. In effect, if you have a proprietary solution and you don’t know what’s in it, you can’t promise anyone that it’s fundamentally, functionally safe.

That’s another vote for RISC-V. The architecture underlying every safety or security case built upon an open standard is published and freely available, rather than hidden behind a vendor’s NDA. How much of each implementation you can see still depends on how you source it, but you start from a foundation anyone can inspect.

This is the part automakers struggle with: An SDV should carry as little software as possible. Given the freedom to add anything and everything in software, automakers end up sucked into deals with tens of suppliers, each promising differentiated features to set the platform apart from its peers – and all you need to do is adopt each supplier’s toolchains and software stacks.

When you try to combine an enormous number of concurrent workloads into a holistic user experience, complexity quickly becomes the enemy of safety, security and scalability. AI adds another layer of complexity entirely, because inference must be kept isolated from the deterministic, certified control loops that retain final authority over critical functions.

I’ve seen independent assessments of a single vehicle program that looked only at the safety suppliers. They found more than 100 Safety Elements out of Context (SEooCs) in that one program: 100 different subsystems, each with its own set of assumptions of use, which the integrator somehow had to handle holistically.

RISC-V’s value here is not simply that it gives automakers another processor architecture to choose from. It creates the possibility of using a common instruction set across many very different classes of compute, from small deterministic controllers and safety islands to application processors and AI accelerators. That alone does not eliminate complexity, but it gives OEMs an opportunity to stop creating complexity simply because different parts of the vehicle happen to use different processor architectures.

One specific example we’ve been laboring for years is that putting a hypervisor into a system doesn’t make it inherently safer. Mixed criticality is genuinely useful for consolidating the number of chips in a car, but there are cases where critical functions are better isolated in hardware, for example through a dedicated safety island.

A few years ago we had exactly this conversation with a customer. They went ahead anyway because, as they told me at the time, “the trouble is, Paul, everyone else is doing it.”

The status quo won, and today that system is in production vehicles. The Wi-Fi security has already needed an update because the underlying protocols have changed. Yet with three different vendors involved, each is looking to the others to deliver it, creating an almost insoluble integration problem.

So from both a safety and security perspective, the simpler you can make the system, the better. RISC-V does not make that simplicity automatic, and there are caveats when you look to add custom extensions. But what it does offer automakers is a common architectural foundation upon which they can simplify, consolidate and retain control over the choices they make.

Automakers struggling with their software stacks are often offered a lifeline: the Board Support Package, or BSP. A primary antagonist throughout my career, the BSP is advertised as everything an OEM needs – boot code, device drivers, low-level components – to run an embedded OS on its chosen IP out of the box.

This isn’t any one architecture’s problem; BSPs exist for all ISAs, from commercial black-box components to fully open designs. The problem is that when a silicon vendor shows up and says, “here you go, I’ve got this BSP, it’ll get you started,” no one asks where it came from or why it’s free. What automakers don’t realize is they’ve just picked a kernel that’s already two to five years out of date at the start of their development process. By the time their platform reaches start of production (SOP), it could be four to seven years old.

The amount of code you rely on permanently from a BSP should be zero. Every bit of software you rely upon to boot an OS on the IP you’re using should be upstream (merged into the main, community-maintained version of a project, such as the mainline Linux kernel). Only then can you have any confidence that the software you’re running will be carried forward and maintained for as long as the vehicle it’s running on remains on the road.

The alternative is as miserable as it is expensive: every line of code not residing upstream will become a line in your ledger. Code you’ll have to maintain yourself, for the operational lifetime of your vehicle, with costs compounding over time. Every patch you carry downstream (kept in your own copy, outside that main project) has to be tracked, security-maintained and re-tested as the upstream project moves on.

When we talk about economic control, we mean your ability to govern the cost, differentiation and roadmap of the compute hardware and software you choose to power your SDV program today. But we also mean the ability to choose how you deal with the challenges and demands of tomorrow, without being held hostage to a decision you made two or three years before SOP.

That’s why we see RISC-V as a strategically better fit for automotive. Only RISC-V can give automakers economic control through a genuinely open ecosystem, built around an open standard instruction set. With it comes the power to choose when and where you source IP, from people with a vested interest in the success of RISC-V and those that adopt it.

If you’re an automaker struggling to navigate the open road, talk to us. You’ll also find a wealth of information at the RISC-V Automotive Hub, and if software is your focus, a good place to start is Codethink’s latest white paper. In it, we explore five years of software engineering on RISC-V. The work it describes is freely available for any team building RISC-V automotive software; it has been tested and contributed upstream, so you can read every line before it goes anywhere near your vehicle. And upstream code gets carried forward with every release, so you won’t be maintaining it on your own.