Automotive & Rail
Safe across every change — over the air or over decades.
Your software controls things that move, often with people inside them. In automotive it ships in millions of units and updates over the air. In rail it runs for decades on infrastructure that cannot stop for long. Either way, safety has to be argued, not assumed.
The argument rests on work done across OEMs, tier suppliers and integrators. Each holds part of the evidence. The safety case has to hold all of it together.
Three recur on road and rail alike — from component suppliers to operators.
Each supplier delivers its part to its own reading of the standard. Integrating that evidence into one argument is where gaps surface — between the parties rather than inside any one of them.
A security vulnerability can now be a safety hazard. Regulation expects both to be managed together, by teams that were organized apart.
Over-the-air updates in automotive and long-lifecycle changes in rail both test an approval granted to a fixed baseline. Every change needs an impact argument that keeps the approval valid.
You answer to functional safety standards, type-approval or authorization regimes, and cybersecurity rules that now sit alongside them. Certification has to demonstrate both safety and security, for the use the system will actually be put to.
Functional safety for road vehicles, with integrity levels from ASIL A to D setting the rigor required. A third edition is in drafting.
Safety of the intended functionality, and its extension to AI-based elements — hazards arising from the limits of sensing, learning and automated functions rather than from faults.
Cybersecurity and software update management, required for EU type approval of all new vehicles since July 2024, with 21434 as the engineering standard behind them.
Railway software and safety-related electronic systems. EN 50716 has replaced EN 50128 and EN 50657.
Cybersecurity for railway applications, building on IEC 62443.
One safety case, many suppliers, and an approval that has to survive the next update. These three engagements work on that sequence.
Independent verification against ISO 26262 and EN 50716 at the ASIL or SIL the function actually carries — including the parts of the argument your suppliers delivered.
- Verification independence at the integrity levels where the standard requires it
- ISO 21448 analysis where the hazard is not a fault but the intended behavior
What arrived inside the delivered software, and whether the evidence that came with it supports the claim being made for it.
- SBOM analysis across tiers, including components your supplier also inherited
- ISO/SAE 21434 supplier interface agreements tested against what is actually exchanged
Update paths, trust boundaries and the separation between what can change over the air and what carries the safety argument — reviewed before an approval comes to depend on them.
- Over-the-air update design assessed against UN R155 and R156
- Security controls placed where they do not invalidate the safety case
A smaller chance of a costly physical recall or a third-party supply chain compromise, and a defensible argument that autonomous decisions stay inside the safety parameters set for them.
Where our work in automotive and rail concentrates.
Designed and scaled complex distributed systems, hardware module integrations and embedded software architectures within national safety and defense contexts.
Published empirical findings on the impact of software security in highly regulated environments, and authored industry-standard DevSecOps maturity models — the basis of our own independent maturity rating.
Led research on automated supply chain integrity, container hardening and multi-tier vulnerability mitigation for mission-critical software deployment platforms.
Contributed to the Linux Foundation OpenSSF secure software development guidelines and to the SPDX SBOM framework.
Verification at the ASIL the function carries, across requirements, architecture, software and integration.
EN 50716 and EN 50129 assessed together with CLC/TS 50701, rather than as separate submissions.
Cybersecurity engineering and the management systems type approval now depends on.
ISO 21448 and ISO/PAS 8800 for perception and decision functions that behave as designed and still get it wrong.