Every engagement runs on the same process, whichever discipline it's in. The three scenarios below show that process in practice — the methodology, the standards, and the deliverables — at a level of technical depth that speaks for itself.
A traction inverter needs a defensible ASIL-D safety case before Type Approval — the kind of gap that surfaces when hardware development outpaces the safety work behind it.
Traction inverters sit squarely in ASIL-D territory: an unintended torque event has vehicle-level consequences, and a Type Approval submission does not move without a hazard analysis, a derived safety concept, and traceable evidence connecting the two. The common failure mode is a safety case built after the design is frozen, forcing rework late in the program when it is most expensive to absorb.
We run the HARA against every operating mode the unit is exposed to, derive the ASIL rating per ISO 26262-3, and decompose it into functional and technical safety requirements the hardware and software teams can actually implement. Diagnostic coverage is designed into the architecture from the outset, not retrofitted — and every requirement carries a traceable link to the verification evidence that closes it.
| Without a Structured Safety Case | With norxs | |
|---|---|---|
| Hazard coverage | Assessed informally, based on the last similar design | Full HARA per ISO 26262-3, against every operating mode the unit is exposed to |
| Traceability | Requirements and test evidence live in separate documents | One matrix — every requirement linked to the evidence that closes it |
| Timing | Safety case written after the design is already frozen | Safety concept derived before the hardware/software split, not after |
| Audit readiness | Assembled under deadline pressure ahead of submission | Structured for Type Approval from the first HARA onward |
A control algorithm that behaves in simulation and one that closes the loop correctly on the target MCU, inside a hard real-time budget, are two different problems — the gap between them is where firmware validation earns its keep.
A field-oriented control loop has to sample, transform, and issue a new PWM command inside a fixed interrupt window, every cycle, without exception — ADC noise, fixed-point rounding, and interrupt jitter that never show up in a model all show up on real hardware. A control law that is stable on paper still has to be proven stable running as compiled, certifiable C code on the actual target.
We implement the control algorithm directly against the target's real-time constraints, not as a port from a simulation environment afterward — fixed-point or floating-point decisions, interrupt budget, and MISRA C compliance are design inputs from the first line of code. Step response and loop-stability data are captured on the actual target and checked against the requirement, the same way the hardware and safety teams verify their own work.
| Without This Process | With norxs | |
|---|---|---|
| Real-time validation | Control law verified in simulation, assumed to hold on target | Step response and loop stability measured on the actual target hardware |
| Code quality | MISRA compliance checked once, near release | Static analysis integrated from the first commit |
| Coverage evidence | Unit tests written after the fact to satisfy an audit | Unit test and MC/DC coverage produced alongside the code |
| Traceability | Firmware behavior and requirements tracked separately | Every control requirement linked to its verification evidence |
A BMS board is where power electronics, safety requirements, and manufacturability all have to agree at once — get the layout wrong and it shows up on the bench, not in review.
Cell voltage sensing, isolation, and high-current switching share the same board at tolerances tight enough that a layout mistake reads as noise on the ADC, not a hard failure — the kind of problem that is expensive to trace once boards are already built.
We work the layout for signal integrity and thermal margin from the schematic stage on — isolation barriers, current-sense placement, and stack-up decisions made before the first prototype is ordered, not fixed after. Bring-up follows a defined bench sequence: power-on verification, isolation testing, then functional test against the requirement set.
| Without This Process | With norxs | |
|---|---|---|
| Signal integrity | Found during EMC pre-compliance — expensive to fix once boards exist | Designed in at layout: isolation barriers, current-sense placement, stack-up |
| Bring-up | Ad hoc debug on the first-article board | Defined bench sequence — power-on, then isolation, then functional test |
| DFM | Reviewed after the first prototype spin comes back | DFM-reviewed before the first prototype is ever ordered |
| Verification | Bench results not tied back to the requirement set | Every bench result carries a traceable link to its requirement |
Tell us what you're building — we'll tell you honestly whether it's a fit.
Get in Touch