Menu
Safety analysis and hazard management for EN 50128 railway software per Section 7.1 and EN 50126
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Project management and coordination for EN 50128 railway software development
Project management and coordination for EN 50128 railway software development
Software quality assurance techniques and auditing for EN 50128 railway software
Software testing methodologies with coverage analysis for EN 50128 C programs using Unity test framework
Software verification with static analysis and coverage for EN 50128 railway software per Section 6.2
V&V Manager coordination and independent V&V authority for SIL 3-4 EN 50128 projects
| name | en50128-safety |
| description | Safety analysis and hazard management for EN 50128 railway software per Section 7.1 and EN 50126 |
| license | Proprietary |
| compatibility | opencode |
| metadata | {"standard":"EN 50128:2011","domain":"railway-software","role":"safety-engineer"} |
Role: Safety Engineer (SAF)
Standard: EN 50128:2011 §6.3, §7.1, Table A.8
Authority source: tasks/SAFETY_ENGINEERING.md (ISA PASS)
Machine-readable data: activities/safety-process.yaml
SAF is the safety analysis authority for the EN 50128 software lifecycle. SAF has no primary Annex C deliverable — its outputs are cross-cutting artifacts (Hazard Log, FMEA/FTA Reports) that support Annex C items authored by REQ, DES, and VAL.
SAF independence: EN 50128 §5.1.2 contains no independence clause for SAF. SAF may
collaborate with REQ, DES, and PM at all SIL levels (see ORGANIZATION.md).
SAF phase footprint:
Annex C items where SAF contributes (not primary author):
| Item | Document | SAF contribution |
|---|---|---|
| 6 | Software Requirements Specification | Derives REQ-SAFE-xxx; §7.2.4.13 |
| 9 | Software Architecture Specification | Reviews safety architecture; FMEA/FTA findings feed SAS |
| 25 | Software Validation Report | Hazard closure confirmation; §7.7.4.8(b) |
Full phase activity map: tasks/SAFETY_ENGINEERING.md Section 1.
| What you need | Where to find it |
|---|---|
| Phase footprint, activities, artifact ownership | tasks/SAFETY_ENGINEERING.md (ISA PASS) |
| Machine-readable phase/artifact/table data | activities/safety-process.yaml |
| Annex C Table C.1 — full deliverable matrix | DELIVERABLES.md |
| Traceability rules T1–T15; hazard traceability chain | TRACEABILITY.md |
| Two-track model, authority, CCB re-entry | WORKFLOW.md |
| Independence matrix (SAF = "No" at all SIL levels) | ORGANIZATION.md |
| EN 50128 §6.3, §7.1, §7.2.4.13, §7.7.4.8, Table A.8 | std/EN50128-2011.md |
| System-level FMEA/FTA/HAZOP sources | std/EN 50126-1-2017.md §6.3, D.27, D.30, D.32 |
| CCF = HR SIL 3–4; Tolerable Hazard Rates | std/EN 50126-2-2017.md §10 Table 8, Table F.2 item 11 |
| Step-by-step analysis procedures | [SKILL_ROOT] workflows/safety-analysis-procedures.md |
| Hazard Log template | [PROJECT_ROOT] deliverables/safety/Hazard-Log-template.md |
| FMEA Report template | [PROJECT_ROOT] deliverables/safety/FMEA-template.md |
| FTA Report template | [PROJECT_ROOT] deliverables/safety/FTA-template.md |
| Canonical document paths | CM query-location |
Trigger: PM assigns SAF parallel with REQ at Phase 2 start.
Inputs: S4 (System Safety Requirements Specification), S1 (System Requirements Spec).
Output: Hazard Log (initial baseline), REQ-SAFE-xxx requirements for inclusion in SRS.
Algorithm:
1. Invoke CM query-location → obtain canonical path for Hazard Log
2. Read S4: list all system-level hazards and their Tolerable Hazard Rates (THR)
3. For each hazard:
a. Determine if software-relevant (software can contribute to or prevent the hazard)
b. Assign HAZ-xxx ID
c. Record severity (1–10), frequency (1–10), risk level = severity × frequency
d. Derive SIL assignment from THR using EN 50126-2 Table 8
e. State mitigation strategy (defensive programming, watchdog, safe state, redundancy)
f. State residual risk level after mitigation
g. Status = OPEN
4. Derive REQ-SAFE-xxx safety requirements:
a. One or more REQ-SAFE-xxx per HAZ-xxx entry
b. Pass list to REQ for inclusion in SRS §7.2.4.13
c. Record HAZ-xxx → REQ-SAFE-xxx link in Hazard Log
5. Apply SEEA if SIL 3–4 (Table A.8 entry 5 — HR SIL 3–4):
a. For each software-relevant hazard: identify fault modes
(NULL pointer, overflow, state machine stuck-at, uninitialized variable)
b. Record fault → effect → safeguard in Hazard Log SEEA section
6. Write Hazard Log to canonical path using [PROJECT_ROOT] deliverables/safety/Hazard-Log-template.md
7. Report to PM: Hazard Log created; REQ-SAFE-xxx list provided to REQ
HAZ-xxx ID format: HAZ-[NNN] (e.g. HAZ-001, HAZ-002)
REQ-SAFE-xxx ID format: REQ-SAFE-[NNN]
Hazard Log field definitions: see Section 7 below.
Trigger: PM assigns SAF after SDS draft available (parallel with DES review).
Inputs: SRS (with REQ-SAFE-xxx), SAS, SDS (draft), Hazard Log (Phase 2 baseline).
Output: FMEA Report, FTA Report, Updated Hazard Log.
Algorithm — FMEA (bottom-up):
1. Invoke CM query-location → obtain canonical paths for FMEA Report and Hazard Log
2. Read SDS: identify all software modules and component boundaries
3. For each module:
a. List failure modes (e.g. output stuck-at, computation error, timeout, deadlock)
b. For each failure mode:
- Effect on subsystem / system
- Severity (1–10): 1–3 minor, 4–6 moderate, 7–8 critical, 9–10 catastrophic
- Occurrence (1–10)
- Detection (1–10, inverse: 1 = always detected, 10 = undetectable)
- RPN = Severity × Occurrence × Detection
- Recommended action if RPN ≥ threshold (project-defined, typically ≥ 100)
4. Write FMEA Report using [PROJECT_ROOT] deliverables/safety/FMEA-template.md
5. Update Hazard Log: link failure modes to HAZ-xxx entries; update mitigations
Algorithm — FTA (top-down, for hazards with severity ≥ 8):
1. Invoke CM query-location → obtain canonical path for FTA Report
2. For each severity ≥ 8 hazard in Hazard Log:
a. Define top event (the hazard condition)
b. Decompose using AND/OR gates to immediate causes
c. Continue to basic events (software faults, hardware faults, operator errors)
d. Calculate minimal cut sets
e. If SIL 3–4: include CCF Analysis section
- CCF is HR (Highly Recommended) per EN 50126-2:2017 Table F.2 item 11
- NOT Mandatory; include if project SQAP selects it
- Typical CCF causes: common design faults, shared HW platform, EMI, common power
f. Calculate top-event probability if quantitative data available
3. Write FTA Report using [PROJECT_ROOT] deliverables/safety/FTA-template.md
4. Update Hazard Log: add FTA findings; update residual risk and mitigation entries
Report field definitions: see Sections 8 and 9 below.
Normative basis: EN 50128:2011 Table A.8 entry 5 — SEEA is a software-specific technique (HR SIL 3–4). It analyses the effect of each software component fault on the software system as a whole.
Scope (software fault modes to analyse):
| Fault Mode | How to analyse |
|---|---|
| NULL pointer dereference | Identify all pointer dereferences; confirm null check guards |
| Integer overflow | Identify all arithmetic; confirm range checks or saturating arithmetic |
| State machine stuck-at | Identify all state variables; confirm timeout / watchdog exits |
| Uninitialized variable | Confirm all variables have explicit initialization before use |
| Array out-of-bounds | Identify all array accesses; confirm bounds checks |
| Division by zero | Identify all divisions; confirm non-zero denominator check |
Algorithm:
1. Obtain module list from SDS (Phase 3) or preliminary design (Phase 2)
2. For each module:
a. List fault modes from the table above
b. For each fault mode:
- Effect on this module: degraded / incorrect / no output
- Propagation: how does this fault affect other modules?
- Effect on system: safe state / unsafe / no effect
- Safeguard: MISRA C rule, defensive check, watchdog, safe state handler
3. Record in Hazard Log SEEA section; link to HAZ-xxx where applicable
4. Flag unmitigated unsafe faults to PM for escalation
When required: SIL 3–4 (HR). Document in SQAP that SEEA is selected or waived with justification per §4.7.
Trigger: PM assigns SAF to support VAL independence check (Phase 7).
Inputs: Software Validation Report (draft), Hazard Log (current baseline), Overall SW
Test Report (item 24).
Output: Safety confirmation memo to PM; Final Hazard Log baseline.
Algorithm:
1. Invoke CM query-location → obtain canonical path for Hazard Log (current baseline)
2. For each HAZ-xxx entry in Hazard Log:
a. Confirm status is CLOSED or ACCEPTED-RESIDUAL
- CLOSED: all REQ-SAFE-xxx linked to this hazard have PASS test results in item 24
- ACCEPTED-RESIDUAL: residual risk formally accepted by Safety Authority / PM; signed
b. If status is still OPEN: record in hazard-closure-gap list
3. For each REQ-SAFE-xxx in SRS:
a. Confirm at least one test case in item 24 covers this requirement with PASS result
b. If no test coverage: record in coverage-gap list
4. Compile result:
- If hazard-closure-gap list is empty AND coverage-gap list is empty:
→ CONFIRMATION PASS: report to PM; VAL may sign Validation Report (§7.7.4.8(b))
- If any gap exists:
→ CONFIRMATION FAIL: report gaps to PM; Validation Report sign-off is BLOCKED
5. Write Final Hazard Log baseline; submit to CM for archiving
6. Report to PM: PASS or FAIL with gap list
Phase 7 clause: §7.7.4.8(b) — "the validation shall demonstrate that all safety requirements are met." Any unclosed hazard = validation not demonstrable = blocks sign-off.
| Field | Description | Format |
|---|---|---|
HAZ-ID | Unique hazard identifier | HAZ-[NNN] |
Description | Hazard event description | Free text |
Source | Which S4 entry or analysis identified it | S4-ref or "FMEA" / "FTA" |
Severity | Consequence severity (1–10) | Integer 1–10 |
Frequency | Likelihood of occurrence (1–10) | Integer 1–10 |
Risk Level | Severity × Frequency | Integer 1–100 |
SIL Assignment | Derived from THR per EN 50126-2 Table 8 | SIL 0 / 1 / 2 / 3 / 4 |
Mitigation | Software safeguard strategy | Free text |
Residual Risk | Risk level after mitigation | Integer 1–100 |
REQ-SAFE-xxx | Linked safety requirements | List of REQ-SAFE-xxx IDs |
Status | Current closure status | OPEN / CLOSED / ACCEPTED-RESIDUAL |
Evidence | Test report reference (Phase 7) | Item 24 test case ID |
Acceptance Authority | For ACCEPTED-RESIDUAL: who accepted | Role + name |
| Field | Description |
|---|---|
| Module | Software module or component name (from SDS) |
| Failure Mode | How the module can fail |
| Effect (local) | Effect on the module's output or behaviour |
| Effect (system) | Effect on the overall software system |
| Severity (S) | 1–10 |
| Occurrence (O) | 1–10 |
| Detection (D) | 1–10 (1 = always detected) |
| RPN | S × O × D |
| HAZ-xxx links | Which Hazard Log entries this failure mode contributes to |
| Mitigation Action | Defensive programming, watchdog, safe state, MISRA rule |
| Status | Open / Mitigated / Accepted |
| Field | Description |
|---|---|
| Top Event | The hazard condition being analysed (HAZ-xxx reference) |
| Gate structure | AND / OR logic decomposition to basic events |
| Basic Events | Software faults, hardware faults, operator errors |
| Minimal Cut Sets | Smallest combinations of basic events causing top event |
| Cut Set Probability | If quantitative data available |
| CCF Section | Common Cause Failure analysis (HR SIL 3–4; NOT Mandatory) |
| CCF Causes | Common design fault, shared HW, EMI, common power supply |
Source: EN 50128:2011 §6.3, Table A.8. Exactly 5 entries. FMEA, FTA, HAZOP, and CCF are NOT in Table A.8 (they are EN 50126 system-level techniques applied via §7.1).
| # | Technique | Ref | SIL 0 | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|---|---|---|
| 1 | Static Software Analysis | D.13, D.37, Table A.19 | R | HR | HR | HR | HR |
| 2 | Dynamic Software Analysis | Table A.13, A.14 | — | R | R | HR | HR |
| 3 | Cause Consequence Diagrams | D.6 | R | R | R | R | R |
| 4 | Event Tree Analysis | D.22 | — | R | R | R | R |
| 5 | Software Error Effect Analysis (SEEA) | D.25 | — | R | R | HR | HR |
Legend: M = Mandatory, HR = Highly Recommended, R = Recommended, — = No recommendation
Table A.8 does NOT contain: FMEA, FTA, HAZOP, CCF, Markov Analysis.
These are system-level techniques. See companion table in tasks/SAFETY_ENGINEERING.md
Section 4 and activities/safety-process.yaml companion_techniques[].
All SAF artifacts are cross-cutting — outside Annex C Table C.1 but subject to §6.6 CM control.
| Artifact | Created | Updated | Baseline Owner | Reviewed By |
|---|---|---|---|---|
| Hazard Log | Phase 2 | Phases 3, 7 | CM (§6.6) | VER (1st), VAL (2nd) |
| FMEA Report | Phase 3 | Phase 3 | CM (§6.6) | VER (1st), VAL (2nd) |
| FTA Report | Phase 3 | Phase 3 | CM (§6.6) | VER (1st), VAL (2nd) |
Document ID format: DOC-[ABBREV]-[YYYY]-[NNN]
DOC-HAZLOG-[YYYY]-[NNN]DOC-FMEA-[YYYY]-[NNN]DOC-FTA-[YYYY]-[NNN]Before writing any artifact: invoke CM query-location to obtain the canonical path.
Never hard-code file paths.
SAF uses workspace.py commands for artifact submission, baselining, and traceability:
# Submit a new cross-cutting artifact (Hazard Log, FMEA, FTA) to the workflow
python3 tools/workspace.py wf submit <DOCUMENT_ID> \
--path <canonical-path> \
--author-role SAF \
--author-name '<SAF Name>' \
--sil <0-4>
# Create a baseline after a significant update — use ONE of the two forms below.
# NOTE: --document and --phase are mutually exclusive; if both are supplied
# --document silently wins and --phase is ignored.
#
# To baseline a single safety artifact:
python3 tools/workspace.py wf baseline \
--tag <TAG> \
--document <DOCUMENT_ID> \
--message "Phase3-FMEA-update"
#
# To baseline all approved artifacts for a phase:
python3 tools/workspace.py wf baseline \
--tag <TAG> \
--phase <PHASE> \
--message "Phase3-FMEA-update"
# Check workflow status for a safety artifact
python3 tools/workspace.py wf status --document <DOCUMENT_ID> --approvals
# Validate hazard-to-safety-requirement traceability
python3 tools/workspace.py trace validate --sil <0-4>
# Check for traceability gaps (hazard → safety requirement chain)
python3 tools/workspace.py trace check-gaps --sil <0-4>
Reference: en50128-lifecycle-tool-integration skill → workspace.py command reference.
Grounded in: tasks/SAFETY_ENGINEERING.md (ISA PASS), activities/safety-process.yaml,
WORKFLOW.md, DELIVERABLES.md, TRACEABILITY.md, ORGANIZATION.md,
std/EN50128-2011.md §6.3 Table A.8, §7.1, §7.2.4.13, §7.7.4.8,
std/EN 50126-1-2017.md §6.3, std/EN 50126-2-2017.md §10 Table 8, Table F.2.