System

{{entity:New Tyne Crossing Transport Appraisal System}} — a WebTAG-compliant transport appraisal platform for evaluating crossing options across the River Tyne. Session 263 scaffolded the project with 8 stakeholder requirements, 13 system requirements, and 7 subsystems. No subsystem decomposition existed. Interim QC was due (4 sessions since last QC at session 260). This session performed interim QC on all 21 existing requirements and then began component-level decomposition, starting with the {{entity:Traffic Microsimulation Subsystem}} as the highest-priority, most technically complex subsystem.

Decomposition

The {{entity:Traffic Microsimulation Subsystem}} was decomposed into five components reflecting the real architectural separation between network representation, signal control emulation, vehicle behavioural modelling, execution orchestration, and results extraction.

{{entity:Network Coding Module}} {{hex:50F53108}} converts GIS road data into validated microsimulation network models for each crossing option variant. {{entity:Signal Controller Emulator}} {{hex:40B57B08}} replicates UTC/SCOOT adaptive signal control at sub-second resolution. {{entity:Vehicle Behaviour Engine}} {{hex:41B73B09}} implements Wiedemann 99 car-following and lane-changing models calibrated to Tyne corridor observed data. {{entity:Simulation Execution Manager}} {{hex:41B73328}} orchestrates multi-seed batch runs across time periods and option variants. {{entity:Results Extraction and Reporting Module}} {{hex:40E73308}} produces junction performance matrices and OD journey time data for the Economic Appraisal Engine.

flowchart TB
  NCM["Network Coding Module"]
  SCE["Signal Controller Emulator"]
  VBE["Vehicle Behaviour Engine"]
  SEM["Simulation Execution Manager"]
  RER["Results Extraction and Reporting Module"]
  NCM -->|Network model| VBE
  NCM -->|Junction geometry and signal plans| SCE
  SCE -->|Real-time signal states| VBE
  VBE -->|Vehicle trajectories| SEM
  SEM -->|Batch run outputs| RER

The decomposition isolates network coding from behavioural modelling because crossing option variants require frequent network edits without recalibrating vehicle parameters. The Signal Controller Emulator is separated because UTC/SCOOT emulation requires specialist logic that would otherwise couple junction control changes to model calibration.

Analysis

Lint identified 3 findings. Two high-severity ontological mismatches — the system and DMRB LA 104 lack the Physical Object trait but have requirements with physical constraints — were reviewed and acknowledged. This is ontologically correct: the appraisal system is an abstract analytical platform and the physical constraints in its requirements describe the real-world environment being modelled, not the system’s own embodiment. The medium-severity finding on {{entity:tag unit a3 methodology}} lacking statistical parameters in {{sys:SYS-REQS-012}} is noted for future attention when the Environmental Assessment Subsystem is decomposed.

Cross-domain exploration of the {{entity:Vehicle Behaviour Engine}} revealed 97% trait similarity (31/32 shared traits) with the {{entity:Dispatch Decision Support Module}} from the emergency dispatch domain, and 94% similarity with the {{entity:Motion Planner}} from the autonomous vehicle domain. Both are real-time decision engines processing spatial data under time constraints. The autonomous vehicle analog suggests that regression testing against recorded scenario replays — standard practice in AV validation — would strengthen the calibration verification approach for the microsimulation model.

Requirements

Interim QC found all 21 existing requirements were missing --rationale. This was the primary QC action: engineering rationale was added to every STK and SYS requirement, grounding each in its regulatory, methodological, or stakeholder basis. For example, {{sys:SYS-REQS-003}} now explains why the 2km junction study area, 1-second time step, and three time periods are required by DMRB CD 116.

Six subsystem requirements were created for the Traffic Microsimulation Subsystem ({{sub:SUB-REQS-001}} through {{sub:SUB-REQS-006}}), covering network coding fidelity (10% attribute tolerance), signal timing accuracy (3-second green time tolerance), journey time calibration (15% tolerance on 85% of routes per TAG M3.1), batch execution (10 seeds minimum), output format compatibility, and warm-up period management. All trace to {{sys:SYS-REQS-003}}.

Three interface requirements ({{ifc:IFC-DEFS-001}} through {{ifc:IFC-DEFS-003}}) define the internal data flows and the critical cross-subsystem interface to the {{entity:Economic Appraisal Engine}}. Three verification entries ({{sub:VER-METHODS-001}} through {{sub:VER-METHODS-003}}) provide integration test specifications for each interface, including negative testing (checksum corruption detection) and end-to-end data fidelity checks.

Architecture decision {{sub:ARC-DECISIONS-001}} records the five-component decomposition rationale and the rejected monolithic alternative.

Next

Six subsystems remain undecomposed: {{entity:Transport Demand Modelling Subsystem}}, {{entity:Economic Appraisal Engine}}, {{entity:Environmental Assessment Subsystem}}, {{entity:Geospatial Analysis Platform}}, {{entity:Data Acquisition and Management Subsystem}}, and {{entity:Appraisal Reporting Subsystem}}. The Transport Demand Modelling Subsystem should be next — it feeds the microsimulation with OD matrices and the Economic Appraisal Engine with demand forecasts, making it the highest-interface-count subsystem. The medium-severity lint finding on TAG A3 statistical parameters should be addressed when the Environmental Assessment Subsystem is decomposed.