What is it?

Structured diagrammatic methods are a family of visual “thought tools” that organize complex systems into clear, reviewable models. Typical notations include data-flow diagrams, statecharts/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 modeling interfaces, states, timing, and error handling, they also surface manifestations of random/common-cause hardware faults in data paths so the safety function does not silently act on corrupted or stale information.

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 & Outputs

Procedure

1. Scope & context: Draw a context view of the safety function boundary, actors, and external events; record assumptions and safe states.
2. Decompose: Create structured views:
   • Data-flow/functional decomposition (what transforms what).
   • Statechart(s) for modes, interlocks, and fault reactions with timing guards.
   • Timing view for event-response and watchdogs.
3. Specify reactions: For each hazardous condition and input anomaly, define the SAFE REACTION (e.g., de-energize to trip; hold last safe output; ignore frame).
4. Validate: Walk through accident scenarios with stakeholders; apply checklists for completeness and consistency.
5. Trace & baseline: Link model elements to safety requirements and test cases; record design decisions.
6. Tool-assisted checks: Use CASE tools for consistency checks and optional simulation of real-time behavior.

Worked Example

High-level

A burner management system (BMS) must trip (close the fuel valve) if the flame is lost for >1 s, if pressure data are invalid/out-of-range, or if the watchdog times out. Operator commands “Start/Stop”; interlocks include Purge Complete and Fuel Pressure OK.

Code-level

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/timeout) 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. Mitigation: define a house style (symbols, guards, error reactions) and enforce it in reviews.
• Missing error paths. Mitigation: apply an “invalid data/watchdog” checklist per interface.
• Over-decomposition. Mitigation: keep depth shallow; prefer orthogonal views (DFD + statechart).
• No timing. Mitigation: add guards/time budgets and an explicit watchdog path.
• Unlinked to tests. Mitigation: add test IDs on transitions/blocks and verify them.

Related techniques

• Formal specification — Higher rigor 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

FAQ