Six safety components are published on GitHub. They are free to read and to evaluate. Putting one into a programme that ships is a commercial licence, and this page says what that covers before you have to ask.
Each repository carries its own hazard analysis, requirements traced through to unit tests, an SPDX bill of materials, and a CI pipeline that fails the build on a MISRA violation, an unbounded stack path or a missing licence header. What a licence adds is the paperwork an assessor asks for and the engineering time to fit the component to your architecture.
All six are published under the norxs Reference Implementation Licence v1.0. Reading and evaluating costs nothing; shipping requires a licence.
| Component | What it does | Standards |
|---|---|---|
safety-supervisor |
ASIL-D arbitration of AI-computed driving commands against a physics-based safety envelope, inside a 10 ms cycle. | ISO 26262 · AUTOSAR R25-11 |
sotif-plausibility-gate |
Plausibility gate for perception output, with an ML-KEM extension on the validation path. | ISO 21448 |
autosar-soa-gateway |
Service-oriented gateway bridging the AI domain and the safety-critical domain over SOME/IP and DDS. | ISO 26262 · AUTOSAR |
automotive-idps-agent |
Intrusion detection over SOME/IP and TSN with zero-copy capture, sized for an in-vehicle budget. | UN R155 · ISO/SAE 21434 |
zonal-zero-trust-auth |
AUTOSAR C++14 authenticator for zonal ECUs, per-message across the zone boundary. | ISO/SAE 21434 · UN R155 |
tsn-zonal-backbone |
TSN backbone with IEEE 802.1Q shaping and measured end-to-end latency verification. | IEEE 802.1Q · ISO 26262 |
A timing or latency claim has to be measured on a specific part, and each repository names its own in the safety manual, versioned alongside the code that produced it. Naming it on this page instead would date the page every time we port, and would read as a supported-hardware list, which it is not.
At the level this page works at: programmes have run on Renesas, NXP (including Freescale-era parts) and Texas Instruments automotive silicon, across both microcontrollers and application processors. Each component is written against an abstraction layer, and the safety argument belongs to the component rather than to the silicon.
Porting is scoped integration work. The safety manual states which evidence has to be re-measured on a new part — usually the timing claims and the hardware metrics, rarely the logic. Tell us your part and we will tell you what the port involves and how much of the existing evidence survives it, including when the answer is that it is not worth doing.
More useful than a list of part numbers, and it does not go stale. Each row names something that is demonstrated on this site or in the public repositories, so it can be checked rather than taken on trust.
| Architecture class | Where it shows up in the work |
|---|---|
| Lockstep real-time MCU | Dual-core comparison carrying the ASIL-D claim. The FMEDA on the platform is built around one, and its diagnostic coverage is the largest single lever on SPFM. |
| Motor-control MCU with gate-driver and resolver interfaces | Traction inverter work: DESAT protection, resolver plausibility, current-sense redundancy. The digital twin models the current loop it closes. |
| Zonal or gateway controller with a hardware security module | SecOC key handling and per-message authentication across a zone boundary, with the firewall rules that decide what may cross it. |
| Application processor beside a real-time core | A safety supervisor on the real-time side arbitrating commands produced by an application domain running a POSIX RTOS. |
| TSN-capable network processor | IEEE 802.1Q shaping with end-to-end latency measured rather than asserted. |
A part that does not fit one of these is not a refusal, it is a conversation about what the abstraction layer has to grow. Silicon we have delivered on to date: Renesas, NXP including Freescale-era parts, and Texas Instruments.
The difference between the tiers is not the code. It is the evidence that comes with it and who carries the argument in front of an assessor.
The fee depends on which component, how many ECUs it ships in, and whether we carry the argument at assessment. We give an indicative range on the first call rather than after a discovery phase, because a number you cannot plan around is not useful to you.
What we do not do is price by seat or by developer. A safety component is licensed to a programme.
| Not included | Why |
|---|---|
| A certificate | Components are developed as SEooC. Certification applies to an item in a vehicle, not to a library. The safety manual states what has to be true in your system for the component's claims to hold. |
| Automatic ASIL for your item | The component's integrity is one input to your safety case. Your item-level HARA, architecture and integration decide the rest. |
| Tool qualification | Nothing we ship is a qualified software tool under ISO 26262-8 clause 11, and none of it substitutes for one. |
| Indefinite support on an old baseline | Support tracks the baseline you licensed. Moving to a newer one is an impact analysis, and we quote it as work rather than pretending it is free. |
One call about your item, your target ASIL and your hardware. We say whether the component fits before anyone writes a contract.
Programme name, ECU count, tier, and whether we attend assessment. Indicative range at this point, fixed fee after.
Configuration review against your architecture, and any adaptation the safety concept requires, re-verified before handover.
A tagged baseline, the safety manual, and the evidence package your safety case cites, with a hash you can check.
Evaluation happens under your own roof. Nothing about your programme reaches us until you decide to talk about scope. See the procurement questions for contracting, IP and export-control detail.
Tell us the item and the target ASIL and we will tell you whether it fits, including when it does not.