Skip to content

norechang/opencode-en50128

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

198 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

EN 50128 Railway Software Development Platform

AI-powered development platform for EN 50128:2011 compliant railway software

Status: Demonstration Complete — Development Frozen Version: 3.2.0


Project Status Notice

This platform has achieved its demonstration goal and is no longer under active development.

The primary objective of this platform was to demonstrate the possibility and flexibility of adopting agentic AI systems in safety-critical engineering infrastructure — specifically, whether a multi-agent AI system could credibly execute the full EN 50128:2011 V-Model software development lifecycle for a SIL 3 railway application.

Through the TDC (Train Door Control System) example project, this goal has been achieved. The TDC project progressed through all six active development phases (Planning through Integration), produced the full set of EN 50128 Annex C deliverables, enforced SIL 3 gate criteria, exercised the two-track V&V model with independent VMGR authority, raised and closed formal NCRs and change requests, and reached Phase 7 (Validation) authorization — all driven by AI agents operating within the EN 50128 role and independence constraints.

This demonstration platform is now frozen. The repository is preserved as a reference. No further development is planned.


Overview

This platform provides a complete EN 50128-compliant software development environment using OpenCode. It implements the full V-Model lifecycle with SIL-dependent phase gate enforcement, 14 specialized AI agents, and 21 domain-specific skill libraries.

Primary use: Develop safety-critical railway software in C (SIL 0-4) with full EN 50128:2011 compliance — from planning through deployment.

This is a development platform, not a project template. All railway software projects are developed in the examples/ directory, each with independent lifecycle tracking.


IMPORTANT: OpenCode Required

This platform must be used within the OpenCode TUI environment.

  • Install OpenCode: See https://opencode.ai
  • Why required: The platform uses OpenCode's agent system, specialized skills, and @agent routing
  • Do NOT use: Generic LLM interfaces — they cannot invoke agents or access EN 50128 skills

Quick Start

1. Install Tools

# System tools (requires sudo)
./install_tools.sh

# Python tools (creates venv/)
./install_python.sh

# Verify
./install_tools.sh --check

See SETUP.md for complete setup instructions.

2. Start a Project

# In OpenCode — initialize lifecycle
@cod plan --sil 3 --project my_railway_component

# Generate system-level input documents (choose from 5 typical railway systems)
@cod generate-system

# Execute phases via Project Manager
@pm execute-phase 1    # Planning: SQAP, SCMP, SVP, SVaP
@cod gate-check phase-1

@pm execute-phase 2    # Requirements: SRS
@cod gate-check phase-2

@pm execute-phase 3    # Architecture & Design: SAS, SDS, Interface Specs, Integration Test Specs
@cod gate-check phase-3

@pm execute-phase 4    # Component Design: Component Design Spec, Component Test Spec
@cod gate-check phase-4

@pm execute-phase 5    # Implementation + Unit Testing: Source Code, Component Test Report
@cod gate-check phase-5

@pm execute-phase 6    # Integration: SW + HW/SW Integration Test Reports
@cod gate-check phase-6

@pm execute-phase 7    # Overall Testing / Validation: Overall Software Test Report
@cod gate-check phase-7

# Phase 8: Assessment — facilitated by PM, conducted by independent ASR
@cod gate-check phase-8

@pm execute-phase 9    # Deployment: Release and Deployment Plan, Deployment Records
@cod gate-check phase-9

Two entry points only: @cod (lifecycle authority) and @pm (phase execution). All other agents are orchestrated internally.

3. Check Status

@cod status            # Lifecycle state, phase progress, deliverables
@pm status             # Project coordination status

Platform Architecture

Information Architecture

The platform is structured in three tiers:

┌──────────────────────────────────────────────────────────────┐
│  TIER 1 — Fundamental Documents (authoritative, ISA-reviewed) │
│  AGENTS.md · LIFECYCLE.md · WORKFLOW.md · ORGANIZATION.md    │
│  DELIVERABLES.md · TRACEABILITY.md · TOOLS.md                │
│  tasks/BASELINE_MANAGEMENT.md · tasks/QUALITY_PROCESS.md     │
│  tasks/SAFETY_ENGINEERING.md · tasks/VnV-PROCESS.md          │
├──────────────────────────────────────────────────────────────┤
│  TIER 2 — Machine-Readable YAML (activities/)                 │
│  phase-N-*.yaml · workflow.yaml · deliverables.yaml          │
│  roles.yaml · organization.yaml · lifecycle.yaml             │
│  traceability.yaml · vnv-process.yaml · tool-management.yaml │
├──────────────────────────────────────────────────────────────┤
│  TIER 3 — Agent & Skill Shells (.opencode/)                   │
│  Thin behavioral files that reference Tiers 1 & 2.           │
│  No duplication of standard content.                         │
└──────────────────────────────────────────────────────────────┘

Agents and skills are thin shells — they describe how to act, not what the rules are. All rules live in the fundamental documents and YAML files.

Fundamental Documents

These files are the single source of truth for all platform rules. They are ISA-reviewed and must not be modified without formal change control.

Document Purpose
AGENTS.md Role definitions, independence matrix, agent-to-skill mapping
LIFECYCLE.md V-Model phases (0–10), entry/exit criteria, deliverable mapping
WORKFLOW.md Authority structure (Diagrams 1–4), two-track model, CCB re-entry flow
ORGANIZATION.md SIL-tiered org charts, role combination rules
DELIVERABLES.md Complete Annex C Table C.1 deliverable catalogue
TRACEABILITY.md Traceability rules T1–T15, gate enforcement
TOOLS.md Tool catalogue, SIL requirements, T1/T2/T3 confidence levels
tasks/BASELINE_MANAGEMENT.md Baseline management lifecycle diagrams, role responsibilities, EN 50128 terminology corrections
tasks/QUALITY_PROCESS.md QUA workflow, deliverable touchpoints (all 46 Annex C items), two-track gate positions, Table A.9 SIL-tiered obligations
tasks/SAFETY_ENGINEERING.md SAF role phase activities, cross-cutting artifacts, hazard-to-validation traceability chain, Table A.8 technique matrix
tasks/VnV-PROCESS.md V&V process lifecycle mapping (Phases 1–10), deliverable review chain (all 46 Annex C items), role interaction models, VMGR platform extension

Machine-Readable YAML (activities/)

The activities/ directory provides machine-readable representations of the lifecycle. These are the primary data source for agents — agents read these files directly rather than relying on prose descriptions.

File Content
phase-0-initialization.yaml Lifecycle initialization activities
phase-1-planning.yaml through phase-10-maintenance.yaml Per-phase Track A activities, deliverables, Track B criteria, gate check criteria
workflow.yaml CCB re-entry flow, change classification rules
deliverables.yaml Complete deliverable catalogue (mirrors DELIVERABLES.md)
lifecycle.yaml Phase FSM, transitions, SIL-dependent enforcement rules
roles.yaml Role definitions with independence requirements by SIL
organization.yaml Role combination rules, org structure
traceability.yaml Traceability rules T1–T15 in structured form
baseline-management.yaml Baseline lifecycle, 8 gate baselines, 7-step creation procedure, CR re-entry path
quality-process.yaml QUA process: per-phase activities, all 46 Annex C touchpoints, two-track gate positions, Table A.9
safety-process.yaml SAF process: phase activity map, cross-cutting artifacts, Table A.8 (5 entries), EN 50126 companion techniques
vnv-process.yaml V&V process: VER/VAL/VMGR lifecycle mapping (Phases 1–10), role interactions by SIL, Phase 7 special flow
tool-management.yaml Tool management: T1/T2/T3 classification (§3.1.42–§3.1.44), qualification workflow, §6.7 obligations

OpenCode Tabs

Tab Mode Purpose
RailDev Primary Default mode — railway software development with full EN 50128 context
Build Primary Compilation and testing focused
Plan Primary Planning and architecture focused

Use the RailDev tab for all EN 50128 development work.

Agent System

14 specialized AI agents implement EN 50128-defined roles:

Core Development Agents

Agent EN 50128 Role Independence (SIL 3-4)
@req Requirements Engineer (§7.2, Table B.2) No
@des Designer (§7.3, Table B.2) No
@imp Implementer (§7.4, Table B.3) No
@tst Tester (§7.5, Table B.4) No
@int Integrator (§7.6, Table B.6) No
@ver Verifier (§6.2, Table B.5) MANDATORY
@val Validator (§7.7, Table B.7) MANDATORY
@saf Safety Engineer (§7.1, §6.3) No

Management and Support Agents

Agent EN 50128 Role Independence (SIL 3-4)
@cod Lifecycle Coordinator (§5.3, platform extension) No
@pm Project Manager (§5, Table B.9) No
@cm Configuration Manager (§6.6, Table B.10) No
@qua Quality Assurance (§6.5) No
@vmgr V&V Manager (§5.1.2.10e, platform extension) MANDATORY

User entry points: @cod and @pm only. All other agents are orchestrated internally by COD and PM.

Authority Structure (SIL 3-4)

        Safety Authority / Customer
                |
        ┌───────┴───────────┐
        |                   |
    COD (Lifecycle)     VMGR (Independent V&V)
        |                   |
    PM (Team)           VER (Verification)
        |
    REQ, DES, IMP, INT, TST, QUA, CM, SAF
  • COD has overall lifecycle authority; enforces phase gates
  • VMGR is independent; V&V approval cannot be overridden by COD or PM
  • PM coordinates Track A (development) only; reports to COD for lifecycle decisions
  • VER/VAL operate on Track B; PM never directs them

SIL Levels

SIL Risk Level Hazard Impact Key Requirements
4 Very High Catastrophic - multiple fatalities Formal methods, independent V&V, 100% coverage
3 High Critical - single fatality Static analysis (M), independent V&V, 100% coverage
2 Medium Marginal - serious injuries Branch coverage (M), MISRA C, static analysis (HR)
1 Low Negligible - minor injuries Statement coverage (HR)
0 None Non-safety related Basic testing

Agent Rewrite Status

All subagent files have been rewritten following a thin shell philosophy: agent and skill files reference authoritative sources (fundamental documents + activities/ YAMLs) rather than duplicating them. This eliminates content drift and reduces context load.

Completed — All 13 Subagents

Agent Before After Reduction
COD (cod.md + 5 skill files) ~13,600 lines ~1,100 lines 92%
PM (pm.md + skill + phase YAMLs) ~5,100 lines ~670 lines 87%
CM (cm.md + skill) ~2,400 lines ~180 lines 93%
QUA (qua.md + skill + review-criteria/) ~3,100 lines ~310 lines 90%
SAF (saf.md + skill + templates + workflows) ~4,200 lines ~590 lines 86%
REQ (req.md + skill) rewritten thin shell
DES (des.md + skill) rewritten thin shell
IMP (imp.md + skill) rewritten thin shell
TST (tst.md + skill) rewritten thin shell
INT (int.md + skill) rewritten thin shell
VER (ver.md + skill) rewritten thin shell
VAL (val.md + skill) rewritten thin shell
VMGR (vmgr.md + skill) rewritten thin shell

doc-reviewer is a standalone ISA audit agent (58 lines) — already minimal by design.

raildev is the primary-mode orchestrator agent; it is not a subagent and the thin-shell rewrite pattern does not apply.

COD skill files rewritten: en50128-lifecycle-coordination, en50128-lifecycle-capabilities, en50128-lifecycle-phase-checklists, en50128-lifecycle-examples. Ten obsolete workflow/template files deleted.

PM skill rewritten: en50128-project-management/SKILL.md; phase data consolidated into phase-coordination.yaml. Five obsolete files deleted.

CM rewrite: FCA/PCA terminology removed; grounded in tasks/BASELINE_MANAGEMENT.md and activities/baseline-management.yaml.

QUA rewrite: 9 per-deliverable YAML checkers and 4 workflow files deleted; replaced by generic-format-checker.yaml + sections/ directory; grounded in tasks/QUALITY_PROCESS.md and activities/quality-process.yaml.

SAF rewrite: Safety Case removed (not in EN 50128); CCF corrected to HR (not Mandatory); Table A.8 fixed to 5 entries; §6.3.4.16 release authority corrected to Validator; 4 workflow files and Safety-Case-template deleted; grounded in tasks/SAFETY_ENGINEERING.md and activities/safety-process.yaml.

Template audit (all 21 skills): All 45 document templates audited and remediated for EN 50128 compliance — correct Annex C Table C.1 approval chains, accurate §/Table references, standardised [UpperCamelCase] placeholders, and DOC-[ABBREV]-[YYYY]-[NNN] Document ID format. The en50128-documentation orphan skill was consolidated into owning skills (en50128-quality, en50128-configuration, en50128-verification, en50128-validation). Three new skills added: en50128-deployment, en50128-maintenance, en50128-application.

Thin-shell rewrite principles:

  1. Agent file (*.md) is a boot script only (~70–100 lines): identity, skill load instruction, capabilities list, hard rules, reference table
  2. Primary skill (SKILL.md) is an authoritative-sources table + unique behavioral patterns only (~250–330 lines)
  3. All rules and data live in fundamental documents or activities/ YAMLs — never duplicated in agent/skill files
  4. Phase-specific coordination notes live in a single process YAML per skill (e.g. phase-coordination.yaml, quality-process.yaml, safety-process.yaml)

Directory Structure

EN50128/
├── README.md                          # This file
├── AGENTS.md                          # Role definitions, independence matrix  ← fundamental doc
├── LIFECYCLE.md                       # EN 50128 V-Model (10 phases)           ← fundamental doc
├── WORKFLOW.md                        # Authority structure, two-track model    ← fundamental doc
├── ORGANIZATION.md                    # SIL-tiered org charts, role rules       ← fundamental doc
├── DELIVERABLES.md                    # Annex C Table C.1 deliverables          ← fundamental doc
├── TRACEABILITY.md                    # Traceability rules T1–T15               ← fundamental doc
├── TOOLS.md                           # Tool catalog (T1/T2/T3 confidence)      ← fundamental doc
│   ├── tasks/
│   │   ├── BASELINE_MANAGEMENT.md         # Baseline management diagrams, role boundaries ← fundamental doc
│   │   ├── QUALITY_PROCESS.md             # QUA workflow, deliverable touchpoints, SIL obligations ← fundamental doc
│   │   ├── SAFETY_ENGINEERING.md          # SAF phase activities, artifacts, Table A.8 matrix ← fundamental doc
│   │   └── VnV-PROCESS.md                 # V&V process lifecycle mapping, role interactions ← fundamental doc
├── SETUP.md                           # Installation guide
├── CONTRIBUTING.md                    # Contribution guidelines
├── CHANGELOG.md                       # Version history
│
├── activities/                        # Machine-readable lifecycle data (primary agent data source)
│   ├── phase-0-initialization.yaml   # Lifecycle initialization
│   ├── phase-1-planning.yaml         # Phase 1: Track A activities, deliverables, gate criteria
│   ├── phase-2-requirements.yaml     # Phase 2: Requirements
│   ├── phase-3-architecture-design.yaml
│   ├── phase-4-component-design.yaml
│   ├── phase-5-implementation-testing.yaml
│   ├── phase-6-integration.yaml
│   ├── phase-7-validation.yaml
│   ├── phase-8-assessment.yaml
│   ├── phase-9-deployment.yaml
│   ├── phase-10-maintenance.yaml
│   ├── workflow.yaml                  # CCB re-entry flow, change classification
│   ├── deliverables.yaml             # Complete deliverable catalogue
│   ├── lifecycle.yaml                # Phase FSM, SIL enforcement rules
│   ├── roles.yaml                    # Role definitions and independence rules
│   ├── organization.yaml             # Role combination rules
│   ├── traceability.yaml             # Traceability rules T1–T15
│   ├── baseline-management.yaml      # Baseline lifecycle, 8 gate baselines, CR re-entry
│   ├── quality-process.yaml          # QUA process, all 46 Annex C touchpoints, Table A.9
│   ├── safety-process.yaml           # SAF process, Table A.8 (5 entries), phase map
│   ├── vnv-process.yaml              # V&V process, VER/VAL/VMGR lifecycle mapping
│   └── tool-management.yaml          # Tool management, T1/T2/T3 classification, §6.7
│
├── .opencode/
│   ├── agents/                        # 14 agent definition files (thin boot scripts)
│   │   ├── raildev.md                # Primary RailDev mode
│   │   ├── cod.md                    # Lifecycle Coordinator  ✓ rewritten
│   │   ├── pm.md                     # Project Manager        ✓ rewritten
│   │   ├── cm.md                     # Config Manager         ✓ rewritten
│   │   ├── qua.md                    # Quality Assurance      ✓ rewritten
│   │   ├── saf.md                    # Safety Engineer        ✓ rewritten
│   │   ├── req.md, des.md, imp.md   # Requirements, Design, Implementation
│   │   ├── tst.md, int.md           # Testing, Integration
│   │   ├── ver.md, val.md           # Verification, Validation
│   │   ├── vmgr.md                   # V&V Manager
│   │   └── doc-reviewer.md           # ISA / doc review
│   └── skills/                        # 18 domain-specific skills
│       ├── en50128-lifecycle-coordination/   ✓ rewritten
│       ├── en50128-lifecycle-capabilities/   ✓ rewritten
│       ├── en50128-lifecycle-phase-checklists/ ✓ rewritten
│       ├── en50128-lifecycle-examples/       ✓ rewritten
│       ├── en50128-lifecycle-tool-integration/
│       ├── en50128-project-management/       ✓ rewritten
│       │   ├── SKILL.md
│       │   └── phase-coordination.yaml       # PM coordination notes for all 10 phases
│       ├── en50128-configuration/            ✓ rewritten
│       ├── en50128-quality/                  ✓ rewritten
│       │   ├── SKILL.md
│       │   ├── review-criteria/              # generic-format-checker.yaml + sections/
│       │   └── templates/
│       ├── en50128-safety/                   ✓ rewritten
│       │   ├── SKILL.md
│       │   ├── templates/                    # Hazard-Log, FMEA, FTA templates
│       │   └── workflows/                    # safety-analysis-procedures.md
│       ├── en50128-requirements/
│       ├── en50128-design/
│       ├── en50128-implementation/
│       ├── en50128-testing/
│       ├── en50128-integration/
│       ├── en50128-verification/
│       ├── en50128-validation/
│       ├── en50128-deployment/
│       ├── en50128-maintenance/
│       ├── en50128-application/
│       ├── en50128-vmgr/
│       └── en50128-tools/
│
├── std/                               # EN 50128 Standards (LLM-friendly Markdown)
│   ├── EN50128-2011.md               # Main standard (2.2 MB)
│   ├── EN 50126-1-2017.md            # RAMS Part 1
│   ├── EN 50126-2-2017.md            # RAMS Part 2
│   └── EN50128-TABLES-EXTRACTED.md   # Technique tables A.2-A.23
│
├── docs/
│   ├── USER-GUIDE.md                 # Complete platform user guide (START HERE)
│   └── plans/                        # Phase 1 plan templates
│
├── assets/
│   └── sample_system/                # System-level document templates + catalogue
│       ├── README.md                 # Usage guide
│       ├── TYPICAL-SYSTEMS.md        # Catalogue of 5 typical railway systems
│       ├── System-Requirements-Specification-TEMPLATE.md
│       ├── System-Architecture-Description-TEMPLATE.md
│       ├── System-Safety-Plan-TEMPLATE.md
│       └── System-Safety-Requirements-Specification-TEMPLATE.md
│
├── tools/                             # Python + shell analysis tools
│   ├── mcdc/mcdc_analyzer.py         # MC/DC analysis
│   ├── workspace.py                  # Workspace management
│   ├── workflow_manager.py           # Phase gate enforcement
│   ├── enhelp.py                     # Platform help
│   └── scripts/                      # Validation scripts
│
└── examples/                          # YOUR PROJECTS GO HERE
    └── TDC/                           # Active SIL 3 Train Door Control project
        ├── LIFECYCLE_STATE.md
        └── docs/                      # EN 50128 deliverables (Phases 0–6 complete; Phase 7 authorized)

System-Level Documents (EN 50126/50129 Inputs)

Per EN 50128 Section 7.2.2, four system-level documents are MANDATORY inputs before software requirements specification can begin:

  1. System Requirements Specification — Overall system functional and non-functional requirements
  2. System Architecture Description — Hardware/software partitioning, system structure
  3. System Safety Plan — Safety management strategy, lifecycle activities, V&V plan
  4. System Safety Requirements Specification — Hazards (FMEA/FTA), safety functions, safety requirements

These are produced by System Engineering (EN 50126/50129) and consumed by Software Engineering (EN 50128).

Automated generation: After @cod plan, run @cod generate-system to automatically generate all four documents by selecting from the 5 typical railway systems in assets/sample_system/TYPICAL-SYSTEMS.md. Generated documents are placed in docs/system/.

Manual path: Templates are in assets/sample_system/. Copy, adapt, and place them in docs/system/ before running @pm execute-phase 2.


Key Documentation

Document Purpose
docs/USER-GUIDE.md Complete user guide with worked examples — start here
AGENTS.md All 14 agent definitions, commands, and EN 50128 technique tables
LIFECYCLE.md Full V-Model lifecycle, phase gate criteria, deliverable mapping
WORKFLOW.md Authority structure, two-track model, CCB re-entry flow
ORGANIZATION.md SIL-tiered org charts, role combination rules
DELIVERABLES.md Annex C Table C.1 complete deliverable matrix
TRACEABILITY.md Traceability rules T1–T15
TOOLS.md Tool catalog with SIL requirements, confidence levels (T1/T2/T3)
tasks/BASELINE_MANAGEMENT.md Baseline management diagrams, role boundaries, EN 50128 terminology
tasks/QUALITY_PROCESS.md QUA workflow, deliverable touchpoints, Table A.9 SIL obligations
tasks/SAFETY_ENGINEERING.md SAF phase activities, artifacts, hazard traceability chain, Table A.8
tasks/VnV-PROCESS.md V&V process lifecycle mapping, role interactions, VMGR platform extension
SETUP.md Installation and environment setup
CONTRIBUTING.md Contribution guidelines
CHANGELOG.md Version history

Contributing

See CONTRIBUTING.md for guidelines on adding agents, creating skills, improving documentation, and reporting issues.


License

MIT License — see LICENSE file for details.


Disclaimer: This platform provides guidance and tooling for EN 50128 compliance. Actual certification requires independent safety assessment by qualified assessors and approval by relevant railway authorities.

About

EN 50128 Railway Software Development Framework - Role-based agents for OpenCode

Topics

Resources

License

Contributing

Stars

Watchers

Forks

Packages

 
 
 

Contributors