Safety First. Compliance Always.
Having worked across standards like ISO 26262 (ASIL A–D), IEC 61508 (SIL 3), IEC 62304 (Class A/B), and FDA 510(k)/EUA, I’ve collected five top tips and tricks for developing a safety-compliant product
1. Tip: Adopt a Safety Mindset from Day Zero
Safety is not just documentation; it’s about having a certain level of confidence (e.g., ASIL C, SIL 3, Class B) that the product will not fail to meet its safety goals.
I’ve seen two recurring traps:
- Overengineering: Some teams develop their product to reach the highest level of confidence, leading to budget overruns or a product with low performance and poor maintainability.
- Procrastination: Postponing the safety topic entirely, which ends up requiring a lot of rework for certification. Sometimes, the rework becomes catastrophic due to a non-compliant system architecture or incompatible hardware targets.
Trick: At project kickoff, run a gap analysis across People, Process, and Product.
- People: Are all stakeholders trained for the required safety level (e.g., ASIL C, SIL 3, Class B)?
- Process: Is your development lifecycle aligned with the relevant safety standard?
- Product: If your product is reused, what must be done to reach compliance?
2. Tip: Choose Tools Based on Safety Needs, Not Popularity
Tool selection should be driven by the specific requirements of your safety activities, not by brand reputation or complexity. A tool is only valuable if it supports the processes needed for compliance with your safety standard (e.g., ISO 26262, IEC 61508, IEC 62304). In some cases, a simple spreadsheet or custom script may be sufficient — high-end tools are not always necessary or justified.
Trick: At project kickoff, perform a tool impact analysis
Determine whether tool qualification is required based on the safety standard being followed.
3. Tip: Safety-Graded Doesn’t Mean Plug-and-Play
If you purchase a safety-graded hardware or software component, or a Safety Element out of Context (SEooC), it does not mean that no integration effort is required. You must ask the supplier for the safety manual to determine whether the listed constraints can be fulfilled within your project context. In some cases, even a safety-graded component may not be suitable for your use case. For example, an ASIL D operating system may provide a safe execution context but might not ensure correct task monitoring, which could be critical for your system.
Trick 1: Perform safety analysis activity before purchasing the SEooC.
During the safety analysis, each component’s undesired event and its impact on the safety goal is determined. Sometimes the system already includes alternative safety mechanisms, making the purchase unnecessary. The safety analysis helps justify whether the buy decision is technically needed or not.
Trick 2: Consider safety specification activities within your project planning.
Once a SEooC is selected, it’s important to define corresponding software or hardware safety requirements early in the planning phase. This ensures traceability, helps evaluate supplier deliverables properly, and prevents costly rework late in development.
4. Tip: Make V&V Reports a Living Part of Your Safety Strategy
Verification and Validation (V&V) activities are not just checkpoints for compliance — they are essential tools for ensuring that safety requirements are properly addressed throughout development. Treating V&V reports as static documents risks overlooking critical gaps, assumptions, or missed test cases that could compromise safety.
Trick: Integrate regular V&V report reviews into your project rhythm.
By undergoing independent functional safety assessments for V&V outputs periodically — not just at major milestones — you maintain continuous alignment with safety goals, improve test traceability, and reduce the likelihood of costly late-stage rework.
5. Tip: Empower the Functional Safety Manager with Clear Authority and Responsibility
A weak or symbolic safety role can lead to unclear accountability and fragmented decision-making. The Functional Safety Manager (FSM) must have a clearly defined role with the authority to make safety-related decisions and resolve conflicts across teams.
Trick: Define and communicate the FSM’s responsibilities early in the project.
Ensure the FSM is involved in key decisions, safety planning, and audits to avoid gaps in ownership and to maintain safety integrity throughout the development lifecycle. Effective functional safety management helps ensure that the product is confidently released and ready for certification.