Computer-Aided Specification and Design Tools — IEC 61508
Computer-aided specification and design tools help engineers capture, structure, analyse, and maintain the requirements and design of safety-related systems. They control systematic failures by reducing ambiguity, inconsistency, and incompleteness — and they produce the traceability and verification evidence needed for SIL justification.
What are computer-aided specification and design tools?
IEC 61508 (Part 3, B.2.4) recognises several families of tools for this purpose:
- Method-independent specification tools — structured editors, traceability, reviews
- Model-oriented tools — state machines, block diagrams, continuous-time models, hierarchical analysis
- Entity-relationship-attribute (ERA) data models — for data-rich domains
- Stimulus–response notations — formal tables and logic for event-driven behaviour
Good tools provide automated inspections (e.g. missing cases, contradictions), simulation or animation, and strong traceability to decisions and safety requirements.
How it supports functional safety
These tools directly target systematic failures by reducing ambiguity, inconsistency, and incompleteness in specifications and designs. Automated checks and model analysis expose defects before implementation, preventing latent errors from propagating into code, tests, and operations.
When models include diagnostics and data handling, they can also reveal manifestations of random or common-cause hardware faults in signals — such as impossible state transitions or out-of-range values — ensuring the safety function does not silently act on corrupted information.
The key question is: does your specification tool actually detect defects — or does it just store text in a structured format?
When to use
- During system and software requirements and architectural design, especially for SIL-rated functions
- When multiple abstraction levels (system → subsystem → component) must stay consistent
- Where interfaces are complex (sensor fusion, interlocks, communication protocols)
- When formal traceability and verification evidence are needed for assessment or audit
- When change impact analysis must be reliable and quick
Inputs and outputs
Inputs
- Functional and safety requirements (including hazards, safety goals, constraints)
- Operational scenarios, interfaces, assumptions, and environmental conditions
- Standards and policies for modelling, naming, and traceability
Outputs
- Structured specifications and/or models with clear semantics
- Analysis reports (ambiguity, completeness, consistency, coverage)
- Traceability links (requirements ⇄ architecture ⇄ verification)
- Review and simulation/animation artifacts for validation
Procedure
- Select the tool family that matches your objective and SIL context: method-independent specification, model-oriented, ERA data models, or stimulus–response.
- Establish modelling rules. Define notation, naming, levels of abstraction, and traceability conventions (IDs, link types, change control).
- Capture requirements and design in the tool. Link safety requirements to hazards and to architectural elements.
- Run automated checks. Look for missing transitions, conflicting constraints, orphaned or duplicate requirements, and undefined interfaces.
- Validate with stakeholders using simulations, animations, or scenario walk-throughs. Record review findings in the tool.
- Maintain alignment as design evolves. Enforce bi-directional traceability and re-run checks after changes.
- Generate evidence for assessment: exports of traceability matrices, analysis reports, and review records.
Worked example — process shutdown function
A high-integrity process shutdown function must close valves on high pressure or high temperature. The team models the logic using a hierarchical state machine in a model-oriented tool and documents interlock conditions in a stimulus–response table.
The tool flags an unspecified transition from "Voting=2oo3 FAIL" to "Shutdown Pending," and highlights an orphaned requirement with no linked verification. After review, the team resolves the missing transition and adds a test case.
Result: Early removal of ambiguity and stronger evidence for SIL justification — before a single line of code is written.
Tooling walk-through
- Capture safety requirements in a requirements tool and link them to hazards and acceptance criteria.
- Model sensor processing and shutdown logic in a state-based or model-based tool. Auto-check for unreachable states and missing transitions.
- Document data entities (sensors, votes, alarms) in an ERA model to clarify ownership and interface contracts.
- Generate traceability and coverage reports for the assessor.
Quality criteria
- Clarity and semantics: Notation is defined. Every model element and requirement is unambiguous and reviewable by domain experts.
- Completeness and consistency: Automated checks show no missing cases, no contradictions, and no orphaned or duplicate items.
- Traceability: End-to-end links (hazard → safety requirement → design element → verification) are complete and current.
- Change control: Versioning, baselines, and impact analysis are used and auditable.
- Evidence quality: Reports are reproducible. Review records are linked to specific artifacts and decisions.
Common pitfalls
Over-modelling
Too much detail at the wrong abstraction level creates maintenance burden without improving safety decisions.
Mitigation: Keep the level of abstraction aligned to decisions and hazards. Defer implementation detail to later artifacts.
Tool without method
A powerful tool with no defined modelling rules and review checklists gives a false sense of security.
Mitigation: Define modelling rules and review checklists before using the tool. Automated checks are only as good as the rules behind them.
Poor traceability hygiene
Links between requirements, design, and tests break silently as the project evolves.
Mitigation: Enforce link types and IDs. Run periodic orphan and duplicate reports.
Insufficient expertise
Practitioners use the tool without understanding the notation or the safety context.
Mitigation: Train practitioners and appoint modelling owners for consistency and quality.
No evidence strategy
The team produces models but cannot extract the reports and records the safety case needs.
Mitigation: Plan upfront how reports, baselines, and review records will feed the safety case.
Frequently asked questions
What concrete tools fit each family?
Method-independent specification: IBM DOORS / DOORS Next, Jama Connect. Model-oriented: MATLAB/Simulink & Stateflow, SCADE Suite, Enterprise Architect (statecharts). ERA modelling: ER/Studio, Enterprise Architect (ER/UML). Stimulus–response: SCR Toolset and similar tabular or contract-based notations.
Do these tools replace reviews or testing?
No. They complement structured reviews and verification. Use them to make reviews sharper and tests more targeted by exposing gaps early.
Are they mandatory under IEC 61508?
They are recommended techniques and measures. Selection and rigour should reflect the claimed SIL and the project's risk profile.
Related techniques
- Formal methods — higher mathematical rigour for proofs of properties
- Simulation and animation — dynamic validation of behaviour and scenarios
References
- IEC 61508-3 (ed.2) — Annex B.2.4: Computer-aided specification tools
- Grady — System Requirements Analysis (2006)
- Wiegers — Software Requirements (2003)
Go deeper — IEC 61508 Certification Course
Our IEC 61508 course covers specification techniques, software safety lifecycle, verification methods, and safety case preparation — for engineers who need to get it right from the start.
Explore the course → Ask us a question