Menú
EN 50128 software validation and system testing for railway C applications
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
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-validation |
| description | EN 50128 software validation and system testing for railway C applications |
| license | Proprietary |
| compatibility | opencode |
| metadata | {"standard":"EN 50128:2011","domain":"railway-software","language":"C","section":"7.7","sil_applicability":"0-4"} |
This skill provides authoritative guidance for the Software Validator (VAL) role per EN 50128:2011 §7.7, §5.3.7, §5.1.2.8, §6.3.4.2, Table B.7.
VAL authors two categories of document:
In all other phases VAL reviews deliverables as 2nd Check only — no VAL report produced. See the 2nd-Check Table (§4 below) for the complete per-phase list.
| SIL | Independence | Reporting |
|---|---|---|
| SIL 0-1 | Not required | May report to PM |
| SIL 2 | HR | Recommended separation from development |
| SIL 3-4 | Mandatory | SHALL NOT report to PM (§5.1.2.10f); reports to Safety Authority or Customer |
VAL's release decision (agree/disagree per §5.1.2.8) is FINAL and cannot be overridden by PM, COD, or VMGR.
VAL produces formal documents in Phase 1 and Phase 7 only.
| Phase | Item | Label | Abbrev | Condition |
|---|---|---|---|---|
| 1 | 5 | Software Validation Plan | SVaP | All SIL levels (M by §6.3.4.2) |
| 7 | 25 | Software Validation Report | VALRPT | All SIL levels |
| 7 | 26 | Tools Validation Report | TOOLSVALRPT | If tool qualification required |
| 7 | 27 | Release Note | RELEASENOTE | Mandatory per §7.7.4.12 |
Note on item 27: Authorship unspecified in Annex C footnote 'a'. Assign in SQAP. Distinct from "Release Notes" (plural, item 38, Phase 9). Confirm against printed standard.
| Phase | Items VAL 2nd-Checks | Note |
|---|---|---|
| 1 | 1, 2, 3, 4, 5 | Items 1–5; all planning deliverables |
| 2 | 6, 7, 8 | SRS, OTSS, REQVER |
| 3 | 9, 10, 11, 12, 13, 14 | Architecture, design, interfaces, integration test specs, ARCHDESIGNVER |
| 4 | 15, 16 | Component design spec, component test spec; item 17 (VER report) not 2nd-checked |
| 5 | 18, 20 | Source code, unit test report; item 19 (VER report) not 2nd-checked |
| 6 | 21, 22 | Integration test spec, integration test report; item 23 (VER report) not 2nd-checked |
| 7 | — | VAL produces reports (items 25–26); does not 2nd-check in Phase 7 |
| 8 | — | Phase 8 is ASR-driven; VAL has no touchpoint |
| 9 | 36, 37, 38, 39 | Deployment plan, manual, release notes, records |
| 10 | 41, 42, 43 | Maintenance records, change records, maintenance plan |
Rule: VAL does NOT 2nd-check VER reports (items 2, 8, 14, 17, 19, 23, 40, 44, †) except via the Phase 7 Track B Step B2 flow where VMGR coordinates both VER and VAL reviews together.
1. Read .workspace; resolve canonical path via CM query-location --doc svap
2. Draft SVaP (item 5) per §6.3.4.2–6.3.4.5:
- Scope, SIL level, validation environment description
- Validation methods selected per SIL tier (Table A.7)
- Acceptance criteria for all requirements
- Planned operational scenarios (normal, degraded, emergency, recovery)
- Performance test plan (MANDATORY SIL 3-4)
- Tools and independence declaration
3. Submit SVaP to QUA for format-gate (Track A)
4. Submit QUA-passed SVaP to VER for 1st-check
5. After VER 1st-check PASS: submit to VMGR (SIL 3-4) or COD (SIL 0-2) for acceptance
1. Receive tasking from COD (SIL 0-2) or VMGR (SIL 3-4) after VER item 23 is approved
2. Read LIFECYCLE_STATE.md; confirm Phase 7 Track B Step B2 authorisation
3. Execute validation activities per SVaP:
a. Functional/black-box testing — verify all SRS requirements (M SIL 3-4)
b. Performance testing — timing, throughput, WCET, resource usage (M SIL 3-4)
c. Operational scenario testing — normal, degraded, emergency, recovery
d. Acceptance testing — customer acceptance criteria
e. End-to-end traceability check — SRS → unit tests → integration → system tests
4. Invoke CM query-location --doc valrpt for canonical path
5. Author Software Validation Report (item 25) per §7.7.4.6–7.7.4.11
6. Author Tools Validation Report (item 26) if tool qualification evidence required
7. Author Release Note (item 27) per §7.7.4.12
8. Submit items 25–26 to QUA for format-gate (1-Pass Rule)
9. After QUA PASS: submit to VER for item † (Validation Verification Report)
10. After VER item † PASS + QUA format check: submit package to VMGR for FINAL V&V decision
11. Issue release decision: AGREE or DISAGREE (§5.1.2.8) — this decision is FINAL
1. Receive deliverable from COD/VMGR after VER has issued its report
2. Review deliverable against SRS, design, and SIL requirements for technical correctness
3. Confirm all VER-identified defects are resolved before 2nd-checking
4. Record 2nd-check outcome: PASS or FAIL with defect list
5. Return outcome to VMGR (SIL 3-4) or COD (SIL 0-2)
Track A (TST) Track B
───────────────── ─────────────────────────────────────────
TST authors item 24 Step B1: VER reviews item 24
(Overall SW Test Report) → VER authors item 23 (SW Integration VER Report)
↓ QUA format-gate → VMGR review
Step B2: VMGR assigns VAL
VAL executes validation (items 25–26–27)
↓ QUA format-gate (1-Pass Rule)
↓ VER authors item † (SW Validation VER Report)
↓ QUA format-gate on item †
VMGR reviews items 23 + 25(+26) + † together
VMGR issues FINAL V&V DECISION to COD
VAL issues release decision (AGREE/DISAGREE)
Key rules:
Per EN 50128 §5.1.2.8, VAL gives agreement/disagreement for software release.
Release criteria (SIL 3-4):
AGREE → Forward to VMGR for FINAL V&V decision; software may proceed to deployment.
DISAGREE → Block release; return defect list; PM/COD cannot override.
second_check: null)| No. | Technique | SIL 0 | SIL 1-2 | SIL 3-4 |
|---|---|---|---|---|
| 1 | Performance Testing (Table A.18) | - | HR | M |
| 2 | Functional and Black-box Testing (Table A.14) | HR | HR | M |
| 3 | Modelling (Table A.17) | - | R | R |
| 4 | Regression Testing (D.46) | HR | HR | M |
| 5 | User Interface Testing | HR | HR | HR |
| 6 | Boundary Value Analysis (D.7) | R | HR | M |
| 7 | Equivalence Classes (D.20) | R | HR | HR |
Legend: M = Mandatory, HR = Highly Recommended, R = Recommended, - = No recommendation
Use the Markdown templates in [PROJECT_ROOT] deliverables/ when authoring VAL deliverables.
The [PROJECT_ROOT] deliverables/ YAML files are machine-readable requirement specs (SIL criteria,
evidence requirements, verification criteria) — they complement but do not replace
the Markdown templates.
| Annex C Item | Markdown Template | Requirements Spec (YAML) |
|---|---|---|
| 5 — Software Validation Plan | [PROJECT_ROOT] deliverables/planning/Software-Validation-Plan-template.md | [PROJECT_ROOT] deliverables/planning/Software-Validation-Plan.yaml |
| 25 — Software Validation Report | [PROJECT_ROOT] deliverables/validation/Software-Validation-Report-template.md | [PROJECT_ROOT] deliverables/validation/Software-Validation-Report.yaml |
| 26 — Tools Validation Report | [PROJECT_ROOT] deliverables/validation/Tools-Validation-Report-template.md | [PROJECT_ROOT] deliverables/validation/Tools-Validation-Report.yaml |
| 27 — Release Note | (assign in SQAP; no platform template — §7.7.4.12) | [PROJECT_ROOT] deliverables/deployment/Release-Notes.yaml |
# Submit SVaP to workflow after authoring
python3 tools/workspace.py wf submit <DOC-SVaP-ID> \
--path <path-to-svap> \
--author-role VAL \
--author-name '<VAL Name>' \
--sil <level>
# Submit Validation Report to QUA
python3 tools/workspace.py wf submit <DOC-VALRPT-ID> \
--path <path-to-validation-report> \
--author-role VAL \
--author-name '<VAL Name>' \
--sil <level>
# Record VAL approval/disagreement
python3 tools/workspace.py wf review <DOC-VALRPT-ID> \
--role VAL \
--name '<VAL Name>' \
--approve \
--comment "Validation complete. AGREE for release."
# Check traceability completeness before release — normative T-rule gate check
# Checks all T-rules applicable up to and including the validation phase,
# reports per-rule PASS/FAIL with normative clause citations, exits 0/1.
python3 tools/workspace.py trace gate-check \
--phase validation \
--sil <level>
# Mark a traceability link as VAL-verified in the named matrix CSV
python3 tools/workspace.py trace verify-link \
--matrix doc25_to_doc6 \
--source <SOURCE_ID> \
--target <TARGET_ID> \
--role VAL \
--name '<VAL Name>'
# Generate requirements coverage report (SRS → validation tests)
python3 tools/workspace.py trace report \
--from requirements --to tests --format markdown \
--output evidence/validation/requirements_coverage.md
Matrix naming convention (established by traceability_manager.py):
evidence/traceability/doc<from>_to_doc<to>.csv
Key validation-phase matrices:
| Rule | Matrix | Description |
|---|---|---|
| T13 | doc25_to_doc6.csv | Validation Report → SRS requirements |
| T3 | doc6_to_doc9.csv | SRS → Architecture (cumulative) |
| T5a | doc10_to_doc9.csv | Design Spec → Architecture (cumulative) |
Note: trace validate --sil <level> performs per-item gap detection within a
single matrix and does NOT check T1–T15 normative rules. Use trace gate-check
for phase gate compliance checks.