Industry safety and security standards

Quick Cap

Embedded safety standards define how to develop, verify, and certify firmware that people's lives depend on. IEC 61508 is the parent standard for functional safety, spawning domain-specific variants: ISO 26262 for automotive, IEC 62304 for medical devices, and DO-178C for aerospace. MISRA C complements all of them by restricting the C language to a safer subset.

Interviewers test whether you understand the purpose and scope of each standard, how integrity levels (SIL, ASIL, DAL) map to development rigor, and what MISRA C actually requires in day-to-day firmware work.

Key Facts:

• IEC 61508: Generic functional safety, SIL 1 (lowest) through SIL 4 (highest)
• ISO 26262: Automotive-specific, ASIL A through ASIL D, based on severity/exposure/controllability
• IEC 62304: Medical device software, safety classes A (no injury) through C (death or serious injury)
• DO-178C: Aerospace software, Design Assurance Levels A (catastrophic) through E (no effect)
• MISRA C: Coding standard restricting unsafe C constructs -- required by most safety standards
• V-model: Development lifecycle used across standards -- requirements flow down, verification flows up

Deep Dive

At a Glance

IEC 61508 -- The Parent Standard

IEC 61508 defines the functional safety lifecycle for electrical, electronic, and programmable electronic (E/E/PE) systems. It introduced Safety Integrity Levels (SIL 1 through SIL 4) based on the probability of dangerous failure per hour. SIL 4 demands the most rigorous development process -- formal methods, independent verification, and exhaustive testing.

For firmware engineers, IEC 61508 matters because every domain-specific standard borrows its core concepts: hazard and risk analysis, systematic capability ratings, hardware fault tolerance requirements, and verification rigor scaled to integrity level. If you understand IEC 61508's lifecycle, you have a map for all the others.

ISO 26262 -- Automotive Functional Safety

ISO 26262 adapts IEC 61508 for road vehicles. Instead of SIL, it uses ASIL (Automotive Safety Integrity Level) determined by three factors:

• Severity (S0-S3): How bad is the harm?
• Exposure (E1-E4): How often does the hazardous situation occur?
• Controllability (C1-C3): Can the driver mitigate it?

The combination yields ASIL A (lowest) through ASIL D (highest), or QM (Quality Management -- no safety requirement).

ASIL decomposition allows splitting a high-ASIL requirement across redundant components. For example, an ASIL D function can be decomposed into two ASIL B(D) channels, each independently developed. This is how most automotive brake and steering ECUs are architected -- dual-core lockstep processors running independent software paths.

The V-model structures the development lifecycle: requirements cascade down the left side (system, hardware, software), implementation happens at the bottom, and verification cascades up the right side (unit test, integration test, system test). Each left-side artifact has a corresponding right-side verification activity.

IEC 62304 -- Medical Device Software

IEC 62304 classifies medical device software into three safety classes based on the hazard caused by software failure:

• Class A: No injury possible (e.g., a data logger)
• Class B: Non-serious injury possible (e.g., a patient monitor with clinician oversight)
• Class C: Death or serious injury possible (e.g., an infusion pump controller)

The key firmware impact: Class C requires full software architecture documentation, detailed design, unit testing, integration testing, and comprehensive risk traceability. Class A requires only basic software development planning. The gap between Class A and Class C effort is typically 5-10x in documentation and verification.

DO-178C -- Aerospace Software Assurance

DO-178C assigns Design Assurance Levels (DAL) based on the failure condition severity:

• DAL A: Catastrophic (aircraft loss) -- requires Modified Condition/Decision Coverage (MC/DC)
• DAL B: Hazardous (serious injury) -- requires decision coverage
• DAL C: Major -- requires statement coverage
• DAL D: Minor -- requires basic testing
• DAL E: No effect -- minimal requirements

DAL A certification is among the most expensive and time-consuming processes in embedded software. MC/DC coverage alone can double the testing effort compared to statement coverage. Tools used for development and verification must themselves be qualified to the appropriate level.

MISRA C -- The Coding Standard

MISRA C restricts the C language to a safer subset by banning constructs that lead to undefined behavior, implementation-defined behavior, or common bugs. While not a safety standard itself, it is referenced or required by ISO 26262, IEC 62304, and DO-178C.

Top 5 rules firmware engineers encounter:

1. No pointer arithmetic beyond array bounds -- prevents buffer overflows
2. No implicit type conversions that lose data -- forces explicit casts
3. Every switch must have a default case -- catches unexpected values
4. No recursive functions -- guarantees bounded stack usage
5. No dynamic memory allocation (malloc/free) -- eliminates heap fragmentation and use-after-free

/* MISRA-compliant switch example */
typedef enum { STATE_IDLE, STATE_RUN, STATE_ERROR } state_t;

void handle_state(state_t s) {
    switch (s) {
        case STATE_IDLE:
            start_motor();
            break;
        case STATE_RUN:
            monitor_motor();
            break;
        case STATE_ERROR:
            stop_motor();
            break;
        default:
            /* MISRA: unreachable, but default is mandatory */
            stop_motor();
            break;
    }
}

Debugging Story

During a certification audit for an ASIL C automotive sensor module, the assessor's MISRA static analysis tool flagged a pointer arithmetic violation in our CAN message parser. The code used *(msg_ptr + offset) where offset could exceed the buffer length if a malformed CAN frame arrived with a DLC mismatch. The fix was straightforward -- add a bounds check before the pointer dereference -- but the incident delayed certification by two weeks. The lesson: run MISRA checks as part of CI, not just before the audit. Static analysis catches bugs that unit tests miss because they exercise paths you did not think to test.

What interviewers want to hear: that you understand which standard applies to which industry, can explain integrity levels and what they demand in terms of process rigor, know the practical impact on firmware development (code coverage targets, MISRA compliance, documentation), and recognize that standards are not just paperwork -- they shape architecture decisions like dual-core lockstep, defensive coding, and redundancy.

Interview Focus

Classic Interview Questions

Q1: "What is the difference between SIL, ASIL, and DAL?"

Model Answer Starter: "They are all integrity level schemes but scoped to different industries. SIL (IEC 61508) is the generic functional safety level from 1 to 4, based on dangerous failure probability. ASIL (ISO 26262) is automotive-specific from A to D, derived from a severity/exposure/controllability matrix. DAL (DO-178C) is aerospace-specific from A to E, based on failure condition category. A rough equivalence: ASIL D and DAL A both demand the highest rigor in their respective domains, but the specific requirements differ -- DAL A mandates MC/DC code coverage, while ASIL D emphasizes hardware fault metrics and FMEA."

Q2: "What is ASIL decomposition and why is it used?"

Model Answer Starter: "ASIL decomposition lets you split a high-ASIL safety requirement across two or more independent elements, each developed to a lower ASIL. For example, an ASIL D braking function can be decomposed into two ASIL B(D) channels on separate processor cores, each running independently developed software. This reduces the per-element development cost while achieving the same system-level safety. The catch is that the elements must be truly independent -- freedom from interference must be demonstrated, typically through hardware separation (dual-core), memory protection (MPU), and temporal isolation."

Q3: "How does MISRA C make firmware safer?"

Model Answer Starter: "MISRA C restricts the C language to eliminate constructs that cause undefined behavior, implementation-defined behavior, or common bug patterns. For example, it bans pointer arithmetic outside array bounds to prevent buffer overflows, prohibits recursive calls to guarantee bounded stack depth, and forbids dynamic memory allocation to eliminate heap fragmentation. In practice, I integrate MISRA checking into CI so violations are caught before code review. The rules force developers to write more explicit, predictable code -- every cast is visible, every switch has a default, every conditional path is considered."

Q4: "What does the V-model look like for an ISO 26262 project?"

Model Answer Starter: "The V-model has requirements flowing down the left side and verification flowing up the right. At the top left you have vehicle-level safety requirements derived from HARA. These decompose into system-level technical safety requirements, then hardware and software requirements. Implementation sits at the bottom. Coming back up, unit tests verify software detailed design, integration tests verify software architecture, system tests verify technical safety requirements, and vehicle-level tests verify the safety goals. Each left-side artifact maps to a right-side verification activity, creating full traceability from safety goal to test case."

Q5: "When would you choose IEC 62304 Class C vs. Class B for a medical device?"

Model Answer Starter: "Class C applies when software failure could directly cause death or serious injury -- for example, an infusion pump controller that miscalculates drug dosage. Class B applies when software failure could cause non-serious injury, typically with some external mitigation like clinician oversight. The determination comes from the overall system risk analysis, not just the software. If hardware safeguards independently prevent the hazardous situation, the software class might be reduced. But this requires rigorous documentation of the mitigation chain, and regulatory auditors scrutinize these justifications heavily."

Trap Alerts

• Don't say: "Standards are just documentation overhead" -- they fundamentally shape architecture decisions like redundancy, coverage, and coding rules
• Don't forget: ASIL decomposition is a key cost-reduction strategy in automotive -- interviewers expect you to know it
• Don't ignore: MISRA C applies across industries, not just automotive -- medical and aerospace teams use it too

Follow-up Questions

• "How do you handle a system that must comply with both ISO 26262 and IEC 62304?"
• "What tool qualification means under ISO 26262 and why your compiler matters?"
• "How does agile development fit within the V-model framework?"

Practice

Real-World Tie-In

Automotive Brake ECU (ISO 26262 ASIL D) -- Developed firmware for a brake-by-wire controller rated ASIL D. Used ASIL decomposition to split the braking function across dual lockstep Cortex-R5 cores, each running independently developed software. MISRA C compliance was enforced via CI with zero tolerance for mandatory rule violations. The V-model lifecycle produced over 3,000 traceable requirement-to-test-case links. Full certification took 18 months, with static analysis catching 47 potential defects that unit testing had missed.

Infusion Pump Controller (IEC 62304 Class C) -- Built the dosage calculation module for a Class C infusion pump. The risk analysis identified seven software-related hazardous situations, each traced to specific safety requirements with corresponding test cases. MISRA C was mandatory, and we additionally banned floating-point arithmetic in the dosage path, using fixed-point math to guarantee deterministic results. FDA 510(k) submission included the full software development lifecycle documentation as required by IEC 62304.