Safety-Critical Firmware

No. We develop to and audit against these standards and produce the verification evidence. Certification is issued by an accredited body.

It covers the microcontroller self-tests, which is a real and useful part of the work. It does not cover your application: whether your control logic reaches a safe state when a sensor fails, whether the fault response is correct, or whether the hazard was identified in the requirements. Assessors look at the application-level safety argument, and that is where most of the effort sits.

We have worked on medical device programmes, covering standards review, hazard analysis against ISO 14971, and EMC pre-compliance to IEC 60601-1-2. We know the regime well, and we will say so early if a project needs a specialist medical software house.

No. It removes a category of C-language risk, which is worth doing. Standards are a floor, not the goal. MISRA, code review, and unit tests create value when tied to real risk and measurable outcomes.

Yes. Changes to certified products need impact analysis before any code changes, so the scope of re-verification is understood before work starts rather than discovered afterwards.

Most of the cost is unit testing, review gates, and requirements traceability, which we do on every project regardless of whether a standard is involved. The additional work is the standard’s specific evidence requirements and the gap between them and the current codebase, which the initial assessment sizes.

Yes, and it is a sensible first engagement. What the standard requires, what your current codebase gives you, and what the gap costs in effort.