norxs designs safety-critical electronics for OEMs, Tier 1 suppliers and industrial manufacturers — and designs them safety-first. Hazard analysis, schematic and layout, FPGA logic, firmware, OS integration and certification evidence come from the same engineers, rather than from three suppliers who have never spoken to each other.
Hardware, FPGA fabric, firmware, operating system and application. We design all of it, and we design it from the safety concept outward rather than adding the safety work once the board already exists. That order is the difference between a safety case that describes the product and one that argues around it.
HARA and safety case development, TARA and CSMS build-out, the software safety lifecycle, and requirements traceability, worked to ISO 26262, ISO/SAE 21434 and UN R155/156.
View Services → 02 / CORE PRACTICEEmbedded firmware, real-time control algorithms, board support packages, and the integration work above them — Linux, QNX and AUTOSAR Classic or Adaptive. Written MISRA C compliant, with unit-test and MC/DC coverage evidence produced alongside the code rather than after it.
View Services → 03 / CORE PRACTICESchematic capture through multilayer layout, power electronics, prototype bring-up and DFM review — and the programmable logic beside it, on Xilinx Zynq-7000 and Zynq UltraScale+, with timing closure and safety-island partitioning.
View Services →Scope, applicable standards and target deliverables are agreed in writing before any design work starts, so both sides are working to the same definition of finished.
System architecture and the decisions that constrain everything downstream are settled and reviewed with you before detailed work begins.
Component-level engineering, verified against the requirements set in step one. Nothing is handed over before that check has been run and recorded.
A traceable documentation package assembled as the work happens, usable for your internal review or for a third-party assessment.
Every engagement runs under NDA, which is why the work described on this site is described without client names.
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. Free to evaluate, licensable for integration into a production programme.
Validates AI-computed driving commands against a physics-based safety envelope derived from live road conditions, and rejects any command outside safe limits within a 10 ms cycle. Runs on the real-time core of a zonal controller, alongside a QNX application on the same package.
View on GitHub →We also publish interactive specimens of the deliverables themselves — hazard analysis, fault tree, requirements traceability, and a vehicle SOC view. These run on synthetic data and exist to show the shape of the output, not real programme results.
Seven screens covering hazard analysis, threat analysis, fault trees, traceability, the CI pipeline, vehicle security operations and a powertrain digital twin. It ships loaded with a synthetic project so you can see the shape of the output, and it will take yours instead. The interface is translated into six languages; standard vocabulary such as ASIL, SPFM and PMHF stays in English in all of them, as ISO 26262 itself does.
The hazard analysis stores only severity, exposure and controllability. The rating is applied from the ISO 26262-3 risk graph, so the table cannot show an ASIL the classification behind it does not support.
No stored percentages. Move a claimed diagnostic coverage on the what-if sliders and all three ISO 26262-5 metrics recompute together, because they come from the same parts list rather than from three separate assertions.
The fault tree is data and the cut sets are solved from it. Building it that way is how we found a basic event that the old diagram never drew while its total still counted it.
The bundled project is synthetic and every screen says so. The computation is not: the same engines run on whatever data you give them, and they carry 243 assertions checked against the tables in the standards.
Programmes are described by domain rather than by client, for the reason given above.
Starting an ISO 26262 project, working through UN R155 type approval, scoping a hardware design engagement, or just not sure where to begin — reach out and we'll have a direct conversation.
Please keep this first message free of programme-confidential material. We put an NDA in place before anything sensitive moves. Every enquiry gets a reply within two working days.
We'll get back to you as soon as we can — usually within a day or two.