Structured Diagrammatic Methods in Functional Safety
Structured diagrammatic methods are visual, structured notations — such as data-flow diagrams, statecharts, and Ward–Mellor — used to model requirements and designs in a logical, checkable way. They control systematic failures by making assumptions visible, enforcing structure, and exposing ambiguity before implementation.
What are structured diagrammatic methods?
Structured diagrammatic methods are a family of visual "thought tools" that organise complex systems into clear, reviewable models. Typical notations include data-flow diagrams, statecharts and UML state machines, and Ward–Mellor (Real-time Yourdon).
They help partition functionality, make assumptions visible, and document interactions with the environment early — when defects are cheaper to fix. IEC 61508-3 references these methods for requirements and design activities.
How it supports functional safety
These methods help control systematic failures by enforcing structure, consistency, and reviewable models that expose ambiguity, omissions, and conflicting assumptions before implementation.
By explicitly modelling interfaces, states, timing, and error handling, they also surface manifestations of random or common-cause hardware faults in data paths — so the safety function does not silently act on corrupted or stale information.
The key question is: does every external stimulus — including invalid inputs and timeouts — lead to a defined, reviewable safe reaction in your diagrams?
When to use
- Concept through architectural design, when stakeholder alignment and hazard-driven requirements must be validated
- Safety functions with significant mode logic, timing constraints, or interlocks (e.g. ESD, multi-sensor voting)
- Multi-team environments where one shared system model must drive requirements, design, and verification
Inputs and outputs
Inputs
- Hazard analysis and safety requirements (safe states, fault hypotheses, timing budgets)
- Operational context: environment, interfaces, external events, and assumptions
Outputs
- Diagram set (context, data-flow, state/sequence) with documented assumptions and safe reactions
- Traceability from hazards → safety requirements → model elements → verification tests
Procedure
- Scope and context. Draw a context view of the safety function boundary, actors, and external events. Record assumptions and safe states.
- Decompose. Create structured views: data-flow and functional decomposition (what transforms what), statechart(s) for modes, interlocks, and fault reactions with timing guards, and a timing view for event-response and watchdogs.
- Specify reactions. For each hazardous condition and input anomaly, define the safe reaction (e.g. de-energise to trip, hold last safe output, ignore frame).
- Validate. Walk through accident scenarios with stakeholders. Apply checklists for completeness and consistency.
- Trace and baseline. Link model elements to safety requirements and test cases. Record design decisions.
- Tool-assisted checks. Use CASE tools for consistency checks and optional simulation of real-time behaviour.
Worked example — burner management system
A burner management system (BMS) must trip (close the fuel valve) if the flame is lost for > 1 s, if pressure data are invalid or out-of-range, or if the watchdog times out. Operator commands include Start and Stop. Interlocks include Purge Complete and Fuel Pressure OK.
Result: Every hazardous or abnormal stimulus is mapped to a defined, reviewable safe transition with clear timing and interlock semantics.
Quality criteria
- Completeness: Every external stimulus (including invalid inputs and timeouts) leads to a defined reaction.
- Consistency: No conflicting transitions; a single source of truth for safe states and priorities.
- Traceability: Diagram elements link to safety requirements and verification tests.
- Simplicity: Limited notation; keep each view readable on one page.
- Reviewability: Scenarios can be simulated or walked through for top hazards.
Common pitfalls
Pretty pictures, no semantics
Diagrams look professional but lack defined symbols, guards, or error reactions.
Mitigation: Define a house style (symbols, guards, error reactions) and enforce it in reviews.
Missing error paths
Normal operation is modelled but invalid data and timeout conditions are omitted.
Mitigation: Apply an "invalid data/watchdog" checklist per interface.
Over-decomposition
Excessive depth makes the model harder to review than the code it describes.
Mitigation: Keep depth shallow. Prefer orthogonal views (DFD + statechart).
No timing
Diagrams show logic but not time budgets, guards, or watchdog paths.
Mitigation: Add timing guards and an explicit watchdog path.
Unlinked to tests
Model elements exist but are not traced to verification test cases.
Mitigation: Add test IDs on transitions and blocks and verify them.
Frequently asked questions
Are structured diagrammatic methods sufficient for SIL 3/4 software?
Often not on their own. Combine with stronger verification (e.g. formal checks, MC/DC testing) and rigorous configuration and traceability to meet higher SIL claims.
Which notation should we choose — UML, statecharts, or Ward–Mellor?
Use the smallest disciplined subset that makes hazards, timing, and safe reactions obvious to your stakeholders. Ward–Mellor and statecharts are strong for real-time behaviour; UML is fine if you enforce a clear subset and house style.
Related techniques
- Formal specification — higher rigour for SIL 3/4; can be derived from structured diagrams
- FMEA / FMEDA — supplies fault hypotheses and safe reactions that diagrams must encode
References
- Hull, Jackson, Dick — Requirements Engineering (CORE concepts)
- Cameron, J.R. — "An Overview of JSD," IEEE TSE (1986)
- Ward, P.T.; Mellor, S.J. — Structured Development for Real-Time Systems
Go deeper — IEC 61508 Certification Course
Our IEC 61508 course covers specification techniques, software safety lifecycle, verification methods, and safety case preparation — for engineers building safety-related systems.
Explore the course → Ask us a question