name	en50128-lifecycle-phase-checklists
description	Per-phase gate checklists (Phase 1–9) with SIL-annotated criteria for all COD gate-check operations
license	Proprietary
compatibility	opencode
metadata	{"standard":"EN 50128:2011","domain":"railway-software","role":"lifecycle-coordinator"}

Phase Gate Checklists

Load trigger: Load at the start of any @cod gate-check <phase> or @cod start-phase <phase>. Apply only the section for the target phase; the others are reference.

Deliverables for each phase: see DELIVERABLES.md (Annex C Table C.1) and activities/phase-N-*.yaml §gate_check §criteria. These checklists cover quality, technique, and SIL-specific criteria not captured in the deliverables matrix.

Phase 1 — Planning

Quality criteria:

All planning documents internally consistent and cross-referencing
Quality gates defined for all subsequent phases (SQAP covers full lifecycle)
V&V strategy established: VER and VAL roles identified with independence level per SIL
Configuration management operational (repo initialized, naming convention agreed)

Team organization:

All roles assigned with named individuals or team designations
SIL-required independence satisfied (SIL 3–4: VAL independent of PM; ASR independent of supplier)
Reporting structure documented in SQAP (source: ORGANIZATION.md for SIL-tiered charts)
Tool qualification plan in place if tool failure could affect SIL classification

SIL-specific:

SIL 0–1: Basic SQAP and SCMP sufficient; SVP/SVaP optional
SIL 2: MISRA C compliance plan required; static analysis tooling nominated
SIL 3–4: SVP authored by VER (not PM); SVaP authored by VMGR (not PM); formal tool qualification plan required

Phase 2 — Requirements

Requirements quality:

All requirements unambiguous (no undefined terms; single clear interpretation)
All requirements testable (acceptance criterion defined for each)
Unique IDs assigned to all requirements
SHALL/SHOULD/MAY keywords used correctly (RFC 2119 or project standard)
SIL levels assigned to all requirements
C language constraints reflected (data types, timing, memory)

Traceability:

RTM complete: system requirements → software requirements (bidirectional, rule T2)
No orphan software requirements (or justified)

Safety:

Hazard analysis initiated or updated (FMEA/FTA as appropriate for SIL)
Safety requirements identified and linked to hazards
Hazard log established

EN 50128 Table A.2 techniques:

Structured Methodology (R SIL 0–1; HR SIL 2–4)
Modelling (R all; HR SIL 3–4)
Formal Methods (R SIL 1–2; HR SIL 3–4)

SIL-specific:

SIL 0–1: Informal methods acceptable; traceability recommended
SIL 2: Structured methodology and traceability highly recommended
SIL 3–4: Traceability MANDATORY; formal/semi-formal methods highly recommended

Phase 3 — Architecture & Design

Architecture quality:

Modular design (MANDATORY SIL 2+)
Module interfaces fully specified and unambiguous
No dynamic memory allocation (MANDATORY SIL 2+)
No recursion (HR SIL 3–4)
Bounded execution time for all modules

Design quality (C-specific):

Cyclomatic complexity limits defined: SIL 3–4 ≤ 10; SIL 2 ≤ 15; SIL 0–1 ≤ 20
Fixed-width integer types specified (uint8_t, uint32_t, etc.)
Error handling strategy defined for all identified failure modes
Defensive programming patterns specified

Traceability:

RTM updated: requirements → architecture → design modules (bidirectional, rules T3–T4)
No orphan design elements (or justified)

Safety design:

Safety-critical functions identified and isolated
Fault detection / diagnosis mechanisms defined (R SIL 1–2; HR SIL 3–4)
FMEA/FTA updated to reflect architecture decisions

EN 50128 Table A.3 techniques:

Structured Methodology (HR SIL 1–2; M SIL 3–4)
Modular Approach (HR SIL 0–1; M SIL 2+)
Design and Coding Standards defined (HR SIL 0–2; M SIL 3–4)
Defensive Programming (HR SIL 1–4)

SIL-specific:

SIL 0–1: Basic modular design; informal methods
SIL 2: Static allocation MANDATORY; modular approach MANDATORY
SIL 3–4: All above + structured methodology MANDATORY; complexity limits enforced; no recursion HR

Phase 4 — Component Design

Design quality:

Component design traceable to SDS (rule T5)
Test strategies defined per component (test cases traceable to component requirements)
Complexity limits respected per SIL

SIL-specific:

SIL 0–1: Component designs recommended; VER review optional
SIL 2: Component designs highly recommended; VER review highly recommended
SIL 3–4: Component designs, test specifications, and VER report MANDATORY

Phase 5 — Implementation & Testing

Code quality (C-specific):

MISRA C:2012 compliance (MANDATORY SIL 2+): mandatory rules satisfied; deviations justified in deviation log
No dynamic memory allocation; no recursion (HR SIL 3–4)
Fixed-width integer types used throughout
All pointer dereferences validated; all return values checked
All external inputs validated (defensive programming)
Cyclomatic complexity measured and within SIL limit for every function

Static analysis (MANDATORY SIL 3–4; HR SIL 2):

Static analysis tool run (e.g., PC-lint Plus, Cppcheck, Clang Static Analyzer)
All violations resolved or entered in deviation log with justification
No dead code; no unreachable code

Unit testing:

All units tested; all unit tests passing
Coverage measured and meets SIL threshold:
- SIL 0–1: Statement HR; Branch HR
- SIL 2: Statement HR; Branch M
- SIL 3–4: Statement M; Branch M; Condition M (or data flow HR)
Boundary value tests included; error handling paths tested
Fault injection testing (HR SIL 3–4)

Code review (MANDATORY all SIL levels):

QUA code review conducted; MISRA C and defensive programming verified
All review findings resolved

Traceability:

RTM updated: design → source files → unit tests (bidirectional, rules T6–T8)
No untested source files (or justified)

EN 50128 Table A.4 techniques:

Structured Programming (HR SIL 1–2; M SIL 3–4)
Design and Coding Standards (HR SIL 0–2; M SIL 3–4)
Analysable Programs (HR SIL 0–2; M SIL 3–4)

Phase 6 — Integration

Integration execution:

Integration strategy (bottom-up / top-down / incremental) executed as planned
All components integrated without conflict; build system produces executable

Integration testing:

All integration tests executed and passing
Interface testing complete (HR all SIL levels): data flow across interfaces; error handling at interfaces; boundary conditions
Performance testing: timing requirements verified; WCET measured (HR SIL 3–4)
Regression testing performed after each integration step

Traceability:

RTM updated: components → integration tests (rules T9–T10); interface coverage complete

EN 50128 Table A.6 techniques:

Functional/Black-box Testing (HR all SIL levels)
Performance Testing (R SIL 1–2; HR SIL 3–4)

SIL-specific:

SIL 0–1: Basic integration testing
SIL 2: Interface testing HR; performance testing R
SIL 3–4: Interface testing HR; performance testing HR; WCET analysis HR

Phase 7 — Validation

Validation testing:

Overall Software Test Specification executed in full
All system tests passing; testing performed in target environment or representative simulator
Operational scenarios tested; performance testing complete (HR SIL 1–2; M SIL 3–4)
Functional/black-box testing complete (HR SIL 0–2; M SIL 3–4)

Requirements validation:

RTM complete end-to-end: requirements → design → code → tests → results (rule T11)
100% requirements coverage (every requirement has at least one passing test)

Independence (SIL 3–4):

Validation performed by independent Validator (VAL)
VAL does NOT report to PM (§5.1.2.10f)
VAL independence documented

Customer acceptance:

Acceptance criteria met; customer sign-off obtained; deviations documented

EN 50128 Table A.7 techniques:

Performance Testing (HR SIL 1–2; M SIL 3–4)
Functional/Black-box Testing (HR SIL 0–2; M SIL 3–4)

SIL-specific:

SIL 0–1: Basic system testing; customer acceptance
SIL 2: Functional and performance testing HR
SIL 3–4: Independent validation MANDATORY; performance and functional testing MANDATORY

Phase 8 — Assessment

Independence (MANDATORY SIL 1–4 per §6.4.1.1; exempt SIL 0 per §6.4.1.2):

Assessor independent from supplier (or Safety Authority discretion)
Assessor independence documented; no reporting to COD or PM

Assessment activities:

Process compliance audit performed (all EN 50128 lifecycle requirements)
All lifecycle documents reviewed; all evidence reviewed
Safety case evaluated; traceability verified end-to-end (rule T15)

Findings:

All findings documented in Assessment Report; all addressed or accepted with justification
No open critical findings; residual risks accepted and documented

Safety Authority:

Safety Authority notified and approval obtained if required by applicable regulation

Phase 9 — Deployment

Release package:

Release package complete (executable, libraries, configuration, documentation)
Package verified against CM baseline; signed/authenticated (SIL 3–4)

Deployment:

Deployment procedure followed; deployment records complete (what/when/where/who)
Post-deployment verification performed (smoke tests, operational checks)

Maintenance:

Maintenance plan established; change control process active
Defect tracking system operational; maintenance team assigned and trained

Configuration management:

Final release baselined and tagged in repository
All artifacts archived; traceability complete from requirements to deployed code (rule T15)