System Decomposition Report — Generated 2026-03-27 — UHT Journal / universalhex.org
This report was generated autonomously by the UHT Journal systems engineering loop. An AI agent decomposed the system into subsystems and components, classified each using the Universal Hex Taxonomy (a 32-bit ontological classification system), generated traced requirements in AIRGen, and built architecture diagrams — all without human intervention.
Every component and subsystem is assigned an 8-character hex code representing its ontological profile across 32 binary traits organised in four layers: Physical (bits 1–8), Functional (9–16), Abstract (17–24), and Social (25–32). These codes enable cross-domain comparison — components from unrelated systems that share a hex code or high Jaccard similarity are ontological twins, meaning they occupy the same structural niche despite belonging to different domains.
Duplicate hex codes are informative, not errors. When two components share the same code, it means UHT classifies them as the same kind of thing — they have identical trait profiles. This reveals architectural patterns: for example, a fire control computer and a sensor fusion engine may share the same hex because both are powered, synthetic, signal-processing, state-transforming, system-essential components. The duplication signals that requirements, interfaces, and verification approaches from one may transfer to the other.
Requirements follow the EARS pattern (Easy Approach to Requirements Syntax) and are traced through a derivation chain: Stakeholder Needs (STK) → System Requirements (SYS) → Subsystem Requirements (SUB) / Interface Requirements (IFC) → Verification Plan (VER). The traceability matrices at the end of this report show every link in that chain.
| Standard | Title |
|---|---|
| IEC 61508 | Functional safety of electrical/electronic/programmable electronic safety-related systems |
| IEC 62061 | — |
| Acronym | Expansion |
|---|---|
| ARC | Architecture Decisions |
| CAA | Civil Aviation Authority |
| CCCS | Completeness, Consistency, Correctness, Stability |
| EARS | Easy Approach to Requirements Syntax |
| IFC | Interface Requirements |
| LRU | Replaceable Unit |
| MSAW | Minimum Safe Altitude Warning |
| MTCD | Term Conflict Detection |
| NATS | Air Navigation Service Provider |
| PSR | Primary Surveillance Radar |
| SSR | Secondary Surveillance Radar |
| STCA | Term Conflict Alert |
| STK | Stakeholder Requirements |
| SUB | Subsystem Requirements |
| SYS | System Requirements |
| UHT | Universal Hex Taxonomy |
| VER | Verification Plan |
flowchart TB n0["system<br>Air Traffic Control System"] n1["actor<br>Air Traffic Controller"] n2["actor<br>Adjacent ATC Centre"] n3["actor<br>Surveillance Sensors (Radar/ADS-B/MLAT)"] n4["actor<br>Airline Operations Centre"] n5["actor<br>Meteorological Service"] n6["actor<br>Aeronautical Information Service"] n1 -->|Control instructions, clearances| n0 n0 -->|Track display, alerts, flight data| n1 n3 -->|Radar plots, ADS-B reports, MLAT tracks| n0 n2 -->|Coordination requests, handoff data| n0 n0 -->|Handoff acceptance, coordination messages| n2 n4 -->|Flight plans, slot allocations| n0 n5 -->|METAR, TAF, SIGMET, wind data| n0 n6 -->|NOTAM, airspace data, procedures| n0
Air Traffic Control System — Context
flowchart TB n0["system<br>Air Traffic Control System"] n1["subsystem<br>Surveillance Data Processing"] n2["subsystem<br>Flight Data Processing"] n3["subsystem<br>Controller Working Position"] n4["subsystem<br>Safety Net System"] n5["subsystem<br>Voice Communication System"] n6["subsystem<br>Recording and Replay System"] n7["subsystem<br>System Monitoring and Control"] n8["subsystem<br>Data Distribution Network"] n9["subsystem<br>Aeronautical Information Management"] n10["subsystem<br>Surveillance Data Processing"] n11["subsystem<br>Flight Data Processing"] n12["subsystem<br>Controller Working Position"] n13["subsystem<br>Safety Net System"] n14["subsystem<br>Voice Communication System"] n15["subsystem<br>Surveillance Data Processing"] n16["subsystem<br>Surveillance Data Processing"] n17["subsystem<br>Flight Data Processing"] n18["subsystem<br>Controller Working Position"] n19["subsystem<br>Safety Net System"] n20["subsystem<br>Voice Communication System"] n21["subsystem<br>Aeronautical Information Management"] n22["subsystem<br>Data Distribution Network"] n23["subsystem<br>System Monitoring and Control"] n24["subsystem<br>Recording and Replay System"] n16 -->|Correlated tracks| n17 n16 -->|Live track data| n19 n17 -->|Flight plan data| n18 n19 -->|Conflict alerts| n18 n20 -->|Voice channels| n18 n22 -->|Raw sensor data| n16
Air Traffic Control System — Decomposition
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| STK-REQ-001 | The Air Traffic Control System SHALL enable controllers to maintain safe separation between all aircraft within controlled airspace in accordance with ICAO Doc 4444 separation minima. Rationale: The primary purpose of ATC is separation assurance. ICAO Doc 4444 defines the applicable separation minima (5 NM en-route, 3 NM terminal). Controllers need a system that presents accurate traffic information and provides tools to ensure these minima are never breached. Failure to maintain separation is the most severe safety outcome in ATC operations. | Demonstration | stakeholder, session-323 |
| STK-REQ-002 | The Air Traffic Control System SHALL provide continuous 24/7 operational availability with no single point of failure that could cause loss of air traffic service. Rationale: Air Navigation Service Providers (ANSPs) are mandated by ICAO Annex 11 to provide continuous ATC service in designated airspace. Any service interruption requires emergency procedures, airspace closure, or traffic flow restrictions that create cascading delays and safety risk. The system must be architected for zero unplanned downtime. | Analysis | stakeholder, session-323 |
| STK-REQ-003 | The Air Traffic Control System SHALL achieve a safety integrity level commensurate with EUROCONTROL ESARR 4 severity classification, targeting a maximum tolerable probability of 1.55x10^-8 per flight hour for ATM system failures that could lead to an accident. Rationale: European regulators require ATM systems to meet ESARR 4 safety targets. The 1.55x10^-8 figure is the EUROCONTROL Target Level of Safety for the most severe failure condition (accident with no effective recovery). This drives the entire system architecture toward redundancy, diversity, and rigorous verification. National CAA certification requires evidence of compliance. | Analysis | stakeholder, session-323 |
| STK-REQ-004 | The Air Traffic Control System SHALL present surveillance and flight data in a manner that minimises controller cognitive workload while supporting a sector capacity of at least 40 aircraft simultaneously. Rationale: Controller workload is a primary constraint on sector capacity and a contributor to operational errors. European ATM performance targets require sector throughput of 40+ aircraft. The system must support this through clear displays, appropriate automation, and efficient interaction design. Excessive clutter, latent alerts, or poor HMI design directly increases error probability. | Demonstration | stakeholder, session-323 |
| STK-REQ-005 | The Air Traffic Control System SHALL support automated coordination and seamless handoff of flights with adjacent ATC centres using OLDI (On-Line Data Interchange) messaging in accordance with EUROCONTROL specification. Rationale: Airlines and passengers expect seamless en-route transitions. Manual telephone coordination between centres is slow, error-prone, and limits sector capacity. OLDI automation enables predictive coordination (ABI, ACT, MAC messages), reducing controller workload during handoffs and preventing coordination errors that have historically contributed to mid-air collision risk at sector boundaries. | Test | stakeholder, session-323 |
| STK-REQ-006 | The Air Traffic Control System SHALL support a maximum sector capacity of at least 60 movements per hour per sector, with controller workload tools (conflict probe, sequencing) available to sustain flow rates up to that ceiling. Rationale: Air Navigation Service Provider (NATS): ANSP throughput targets are agreed with the CAA and airport operators; failure to support 60 movements/hr per sector limits FIR capacity and forces flow restrictions impacting airlines. | Demonstration | stakeholder, stk-ansp, session-384, idempotency:stk-ansp-capacity-384 |
| STK-REQ-007 | The Air Traffic Control System SHALL maintain all audit logs and recordings in a tamper-evident format accessible to the Civil Aviation Authority (CAA) within 2 hours of a formal incident investigation request. Rationale: UK CAA (Civil Aviation Authority): regulator has statutory rights to access ATC recordings under Air Navigation Order 2016; non-compliance risks operational licence suspension. 2h access SLA is the CAA's stated investigation enablement requirement. | Demonstration | stakeholder, stk-caa, session-384, idempotency:stk-caa-audit-access-384 |
| STK-REQ-008 | The Air Traffic Control System SHALL provide a maintenance interface that allows trained technicians to replace any line-replaceable unit (LRU) without interrupting ATC operations, with restoration of the replaced LRU to full operational status within 30 minutes. Rationale: Maintenance engineering team: LRU replacement downtime drives service credit penalties with the ANSP; 30-minute MTTR is the contractual target for field maintenance. Non-interrupting LRU swap is required because the ATCS runs 24/7 with no maintenance windows. | Demonstration | stakeholder, stk-maintenance, session-384, idempotency:stk-maintenance-lru-384 |
| STK-REQ-009 | The Air Traffic Control System SHALL provide full ASTERIX Cat 062 track output to all registered third-party systems (flow management, adjacent ATC centres) with latency not exceeding 500ms from the track update generation time. Rationale: Adjacent ATC centre operators and EUROCONTROL CFMU: ASTERIX Cat 062 is the mandated track data exchange format (EUROCONTROL ASTERIX specification); 500ms latency is required for CFMU to compute accurate flow control predictions. | Test | stakeholder, stk-adjacent-atc, session-384, idempotency:stk-adjacent-asterix-384 |
| STK-REQ-010 | The Air Traffic Control System SHALL provide an isolated controller training mode that replicates the live operational interface with recorded or synthetic traffic, preventing any training-mode inputs from entering the live operational system, so that controllers may maintain proficiency and assess system changes without flight safety risk. Rationale: ICAO Doc 9426 ATC Planning Manual and EUROCONTROL guidelines require ATCS training mode to be physically or logically isolated from live operations. Proficiency validation in a live system poses unacceptable risk; an incorrectly entered instruction during a training exercise could be transmitted to aircraft. Inspection of isolation architecture (separate processing, no live data write-back) plus a demonstration test confirms segregation. | Inspection | mode-coverage, training-mode, validation-gap, session-543, idempotency:stk-training-mode-session-543 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SYS-012 | The Air Traffic Control System SHALL provide real-time ASTERIX Category 062 System Track output to all registered third-party consumers (adjacent ATC centres, CFMU, flow management systems) with a maximum end-to-end latency of 500ms from track update generation to network delivery, with zero message loss for registered consumers over any 24-hour period. Rationale: Derived from STK-REQ-009: adjacent ATC centres and CFMU flow management require ASTERIX Cat 062 data within the 500ms CFMU SLA to generate accurate flow control predictions. Message loss would create track data gaps in downstream systems that rely on the track feed for automated coordination, creating coordination hazards at sector boundaries. | Test | idempotency:sys-req-asterix-cat062-latency |
| SYS-REQ-001 | The Air Traffic Control System SHALL maintain a multi-sensor fused track position accuracy of less than 250 metres RMS for en-route surveillance and less than 50 metres RMS for terminal area surveillance. Rationale: Separation minima of 5 NM en-route and 3 NM terminal require track accuracy significantly better than the separation standard to allow controllers to detect converging tracks with adequate warning. 250m en-route corresponds to approximately 2.7% of 5 NM separation, providing sufficient margin for controller assessment. Terminal 50m accuracy is driven by parallel runway approach monitoring where aircraft may be separated by only 1000ft laterally. | Test | system, surveillance, session-323 |
| SYS-REQ-002 | The Air Traffic Control System SHALL update the surveillance track picture at a rate of at least once per 4 seconds for en-route and once per 1 second for terminal approach operations. Rationale: Track update rate determines controller ability to detect developing conflicts. 4-second en-route rate matches the rotation period of long-range SSR and provides adequate track refresh for traffic at Mach 0.80-0.85. Terminal 1-second rate is required for approach monitoring where aircraft closure rates on final approach are high and controller reaction time is limited. | Test | system, surveillance, session-323 |
| SYS-REQ-003 | The Air Traffic Control System SHALL achieve operational availability of at least 99.9997% measured over any 12-month period, corresponding to no more than 1.6 minutes of unplanned downtime per year. Rationale: ANSP continuity obligation requires effectively zero unplanned outage. 99.9997% (five-and-a-half nines) corresponds to 1.6 min/year, which allows for one brief automatic failover event. This drives dual-redundant hot-standby architecture with sub-5-second switchover. Each additional nine of availability roughly doubles the system cost, and 99.9997% represents the engineering optimum for ATC where the cost of an outage (airspace closure, diversion costs, safety risk) vastly exceeds redundancy investment. | Analysis | system, availability, session-323 |
| SYS-REQ-004 | The Air Traffic Control System SHALL detect and alert controllers to predicted losses of separation at least 120 seconds before the predicted closest point of approach, with a missed detection probability not exceeding 10^-5 per conflict encounter. Rationale: 120 seconds provides adequate time for controller assessment, pilot communication, and execution of a resolution manoeuvre. At closing speeds of 1000 kt (head-on en-route), 120 seconds corresponds to approximately 33 NM from the conflict point. The 10^-5 missed detection rate is derived from ESARR 4 safety target apportionment: the safety net is the last barrier before a mid-air collision, and its reliability must ensure the overall accident rate stays below 1.55x10^-8. | Test | system, safety-net, session-323 |
| SYS-REQ-005 | The Air Traffic Control System SHALL simultaneously process and display at least 2500 correlated surveillance tracks and 5000 active flight plans without degradation of display refresh rate or processing latency. Rationale: Sector capacity of 40 aircraft per sector, across a centre with up to 25 sectors plus overflights and adjacent traffic, requires a system-wide capacity of 2500+ tracks. Flight plan count is higher because plans are filed hours before activation. The system must maintain full performance at peak loading — capacity-related performance degradation would force sector capacity restrictions during periods of highest demand. | Test | system, capacity, session-323 |
| SYS-REQ-006 | The Air Traffic Control System SHALL implement network isolation between the operational ATC network and all external networks (internet, airline networks, meteorological feeds), with all external data feeds ingested through unidirectional data diodes or validated application-layer gateways. Rationale: ATC systems are designated Critical National Infrastructure in all ICAO Contracting States. Network isolation is a mandatory cyber security control per ICAO Doc 10110 (Cyber Security Manual for Civil Aviation) and EUROCONTROL's EATM-CERT guidance. Unidirectional data diodes for external feeds eliminate the attack surface from airline networks and internet-connected met services without disrupting data ingestion — a hardware-enforced boundary cannot be compromised by software vulnerabilities. | Analysis | system, cybersecurity, session-379 |
| SYS-REQ-007 | The Air Traffic Control System SHALL be supplied by at least two independent power sources (mains grid plus diesel generator), with automatic switchover to backup within 500 ms on mains failure and a minimum 72-hour backup power endurance at full operational load. Rationale: Power failure is identified as a Common Mode Failure that could disable all ATC services simultaneously. ICAO Annex 10 and EUROCONTROL ESARR 2 require continuous power supply for ATC facilities. 72-hour endurance is derived from the maximum credible grid outage scenario (major storm or regional grid fault) that must not force airspace closure. 500ms switchover prevents UPS battery exhaustion during mains interruption. | Test | system, power, session-379 |
| SYS-REQ-008 | The Air Traffic Control System SHALL provide a controller-initiated conflict probe tool that scans all active flight plans against current airspace structure and generates a preliminary conflict notification at least 20 minutes before predicted intersection. Rationale: Medium-Term Conflict Detection (MTCD) is required by EUROCONTROL ATM Master Plan Phase 2 to support high-density operations; 20-minute horizon gives controllers adequate time to negotiate reroutings before separation minima are threatened. | Test | system, safety, session-384, idempotency:sys-mtcd-conflict-probe-384 |
| SYS-REQ-009 | The Air Traffic Control System SHALL continue to provide surveillance display, flight data display, and voice communications at degraded but safe minimum service levels following any single subsystem failure, with recovery to full service within 15 minutes. Rationale: Minimum service level following single subsystem failure is the safety case baseline for system availability architecture; 15-minute recovery is the NATS Target Level of Safety (TLS) for ATC system failure modes, derived from separation assurance temporal buffers. | Test | system, availability, degraded, session-384, idempotency:sys-degraded-service-384 |
| SYS-REQ-010 | The Air Traffic Control System SHALL interface to the EUROCONTROL CFMU Network Manager via the OLDI B2B web service interface, exchanging flight plan activation, modification, and flight data for all flights within the FIR at update rates consistent with the CFMU SLA. Rationale: CFMU interface is a mandatory EUROCONTROL Network Manager requirement for all IFR flights; failure to maintain the B2B interface results in CFMU flow restrictions affecting all aircraft transiting the FIR. | Test | system, interface, session-384, idempotency:sys-cfmu-interface-384 |
| SYS-REQ-011 | The Air Traffic Control System SHALL record all surveillance tracks, controller-pilot voice communications, controller inputs, and flight data events in tamper-evident format, retained for a minimum of 30 days and retrievable within 2 hours of a regulatory request. Rationale: UK CAA CAP 670 and ICAO Annex 11 Section 6.4 mandate ATC recording for incident investigation; 30-day retention and 2h retrieval are the CAA's specified investigation enablement requirements. Tamper-evidence is required for legal admissibility. | Test | system, recording, regulatory, session-384, idempotency:sys-recording-mandate-384 |
| SYS-REQ-013 | The Air Traffic Control System SHALL provide a maintenance interface that permits replacement of any Line-Replaceable Unit (LRU) without interrupting active ATC service, with full subsystem functionality restored within 30 minutes of LRU insertion. Rationale: STK-REQ-008 requires LRU replacement without service interruption and 30-minute restoration. SYS-REQ-009 covers degraded mode continuity but does not address the maintenance procedure protocol or restoration time bound. The 30-minute target is derived from ICAO Doc 7030 ATC service continuity expectations. | Test | idempotency:sys-maintenance-lru-swap-session-539 |
| SYS-REQ-014 | The Air Traffic Control System SHALL implement a training mode subsystem that is logically isolated from the operational data path, sharing no write-back channel to live tracking, flight plan, or voice systems, and that replays recorded traffic or injects synthetic traffic at the Controller Working Position. Rationale: Derived from REQ-SEAIRTRAFFICCONTROL-082 (training mode isolation). The isolation boundary must be at the system architecture level to prevent accidental live system writes. The training subsystem replay capability is necessary for regulatory proficiency requirements under CAA ATC licensing standards. | Inspection | mode-coverage, training-mode, session-543, idempotency:sys-training-mode-session-543 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SUB-REQ-001 | The Aeronautical Information Management subsystem SHALL maintain a complete aeronautical database incorporating all AIRAC-cycle data (airways, waypoints, sector boundaries, prohibited areas, SIDs/STARs, and instrument approach procedures), with database updates applied within 2 hours of each AIRAC publication date and validated against EUROCONTROL AIXM 5.1 schema before activation. Rationale: Derived from STK-REQ-001: controllers depend on accurate aeronautical data for sector boundary awareness and procedural instruction. AIRAC cycle compliance (every 28 days) is mandated by ICAO Annex 15 to ensure all ANSPs operate from consistent data. Schema validation prevents corrupted data activations that could cause flight plan processing errors in FDP. | Inspection | |
| SUB-REQ-001 | The Surveillance Data Processing subsystem SHALL ingest surveillance data from a minimum of 4 independent sensor sources simultaneously (Primary Surveillance Radar, Secondary Surveillance Radar, ADS-B, and MLAT), maintaining correlated track output when at least 2 sensor sources are operational. Rationale: Single-sensor dependency creates a single point of failure that violates STK-REQ-002. Four sources provide N+2 redundancy at the sensor input layer. The 2-source minimum reflects the engineering judgement that multi-lateration requires at least 4 receivers but ADS-B plus PSR provide sufficient independent coverage for safe operations during degraded mode. This threshold drives the sensor fusion algorithm design. | Test | subsystem, surveillance, session-379 |
| SUB-REQ-002 | The Aeronautical Information Management subsystem SHALL respond to navigation data queries from the Flight Data Processing subsystem within 50 ms at 95th percentile under maximum operational load (5000 simultaneous active flight plans), using an in-memory database cache refreshed on each AIRAC cycle transition. Rationale: FDP requires rapid procedural waypoint lookups for trajectory prediction and clearance validation. A 50ms latency budget is derived from the FDP flight plan correlation time budget of 30 seconds (SUB-REQ-005) — database lookup must not be the bottleneck in the correlation chain. In-memory cache eliminates disk I/O latency on hot query paths. | Test | |
| SUB-REQ-002 | The Surveillance Data Processing subsystem SHALL produce a fused track update with position accuracy better than 250 m RMS (en-route) and 50 m RMS (terminal) within 500 ms of receiving the latest sensor input from any source. Rationale: Derived from SYS-REQ-001 and SYS-REQ-002: 4-second en-route track update rate with 500ms processing latency leaves 3.5 seconds for data propagation and display. Terminal operations require 1-second update rate; 500ms processing budget is therefore tight but achievable with dedicated FPGA-based sensor fusion. Exceeding 500ms degrades conflict prediction accuracy by increasing projected track uncertainty ellipses. | Test | subsystem, surveillance, session-379 |
| SUB-REQ-003 | When a NOTAM is received from the national ANSP feed, the Aeronautical Information Management subsystem SHALL distribute the NOTAM to all active Controller Working Positions within 60 seconds of receipt, categorised by affected sector and effective time window. Rationale: Controllers must be aware of temporary restrictions (NOTAM) affecting their sector before the effective time. 60-second distribution ensures controllers receive actionable information with adequate lead time to adjust sector operations. Categorisation by affected sector prevents information overload — controllers only see NOTAMs relevant to their current sector assignment. | Test | |
| SUB-REQ-003 | The Safety Net System SHALL evaluate all active track pairs for predicted minimum separation within a 5-minute lookahead window and SHALL generate a Short Term Conflict Alert (STCA) when predicted separation falls below 3 NM horizontal and 1000 ft vertical for en-route, or 2.5 NM horizontal and 500 ft vertical for terminal operations. Rationale: Derived from SYS-REQ-004: 120-second controller action time requires prediction at 5 minutes to allow alert, assessment, and instruction cycles. STCA thresholds are set at 150% of ICAO separation minima to provide a buffer margin while avoiding nuisance alerts that degrade controller trust. Terminal thresholds reflect tighter published separation standards at controlled airfields. These are EUROCONTROL-standardised values used across European ANSPs. | Test | subsystem, safety-net, session-379 |
| SUB-REQ-004 | The Data Distribution Network subsystem SHALL provide end-to-end message delivery latency not exceeding 10 ms at 99th percentile for safety-critical traffic (track updates, STCA and MSAW alerts) and not exceeding 100 ms for operational traffic (flight plan changes, configuration messages), using differentiated QoS queue priorities across a dual-redundant switched Ethernet fabric. Rationale: Derived from IFC-REQ-001 (200ms SDP-to-SNS budget): the DDN must consume no more than 10ms of this budget. Safety-critical QoS priority prevents track data being queued behind large flight plan batch updates — an uncontrolled burst of OLDI messages in a QoS-flat network could delay STCA alert delivery beyond the controller action time budget. | Test | |
| SUB-REQ-004 | The Safety Net System SHALL achieve a STCA missed detection probability not exceeding 10^-6 per conflict encounter and a false alert rate not exceeding 3 alerts per sector per hour at 80% sector capacity loading. Rationale: The 10^-6 missed detection target is derived from SYS-REQ-004 (10^-5 system-level) with a 10x safety factor to account for controller response failure probability. The 3 false alerts per sector per hour threshold is set at the boundary where controller trust in the safety net begins to erode — empirical EUROCONTROL studies show controllers begin to inhibit alerts above this rate, eliminating the safety net's effectiveness. | Analysis | subsystem, safety-net, session-379 |
| SUB-REQ-005 | When a single network switch or inter-switch link fails, the Data Distribution Network subsystem SHALL complete automatic re-routing of all traffic flows within 50 ms, maintaining full capacity on all subsystem connections without operator intervention. Rationale: Derived from SYS-REQ-003 (99.9997% availability): the DDN is a potential single point of failure that could simultaneously disable all subsystem communications. 50ms re-routing ensures that a link failure does not interrupt track delivery cycles (4-second SDP cycle, 1-second terminal cycle). Dual-ring topology enables pre-computed protection switching without route recalculation. | Test | |
| SUB-REQ-005 | The Flight Data Processing subsystem SHALL maintain a flight plan record for every active, proposed, and filed flight within the controlled airspace and SHALL correlate each active flight plan with its corresponding surveillance track within 30 seconds of the aircraft entering the system's coverage area. Rationale: Flight plan-to-track correlation is the mechanism that links procedural and surveillance control. Uncorrelated tracks appear as 'unknown' aircraft to controllers, requiring manual identification that consumes workload and time. 30-second correlation is derived from an average transponder-activation-to-correlation time observed in operational ATCS systems and must be met to comply with STK-REQ-001 separation assurance at system entry points. | Test | subsystem, fdp, session-379 |
| SUB-REQ-006 | The System Monitoring and Control subsystem SHALL detect any subsystem health parameter breach (CPU utilisation >90%, memory utilisation >85%, network packet loss >0.01%, or disk write failure) within 5 seconds and SHALL deliver an alert to the System Controller position within a further 2 seconds, classified by subsystem and severity. Rationale: Early detection of resource exhaustion prevents cascading failures that could cause unplanned service loss. 5-second detection is the maximum permissible before a degrading subsystem begins to affect track processing latency — CPU saturation in SDP will begin dropping track fusion cycles if not detected and corrected within one processing generation. System Controller must receive the alert in time to initiate planned degradation procedures. | Test | |
| SUB-REQ-006 | The Controller Working Position subsystem SHALL present all track labels, alerts, and flight data at a minimum display refresh rate of 25 Hz and SHALL render track symbol position updates within 100 ms of receiving new track data from the processing layer. Rationale: 25 Hz display refresh eliminates visible flicker and ensures alert animations (STCA, MSAW) are immediately apparent without cognitive delay. The 100 ms end-to-end latency from track data receipt to display symbol update is derived from human factors research showing controller reaction time degrades when system latency exceeds 150 ms — 100 ms leaves 50 ms margin for controller interface responsiveness. This is an HMI safety-critical parameter that affects the controller's ability to assess developing conflicts. | Test | subsystem, cwp, session-379 |
| SUB-REQ-007 | The System Monitoring and Control subsystem SHALL provide a secure configuration management interface supporting controlled software updates with mandatory pre-activation health check validation, automatic rollback to the previous stable configuration within 60 seconds if post-activation health checks fail, and an audit log of all configuration changes retained for 12 months. Rationale: ATC system software updates are high-risk change events — a defective update deployed to a live system could simultaneously degrade multiple subsystems. Mandatory health check validation and automatic rollback reduce the exposure window for a failed update to <60 seconds. Audit log retention is required by EUROCONTROL ESARR 1 for safety case traceability and incident investigation. | Inspection | |
| SUB-REQ-007 | The Voice Communication System subsystem SHALL provide simultaneous independent voice channels for each active control sector, with channel switching latency not exceeding 150 ms and audio clarity meeting ICAO Annex 10 voice quality standards (speech intelligibility score greater than 0.75 using PESQ methodology). Rationale: Each sector requires a dedicated radio channel to prevent cross-sector interference; a controller transmitting on the wrong frequency is a well-documented error category in aviation safety reports. 150 ms switching latency matches the lower bound of detectable audio gaps — shorter gaps are imperceptible and longer gaps create the impression of dropped transmissions. PESQ 0.75 is the ICAOrequirement for ATC voice quality in Annex 10 Appendix S. | Test | subsystem, vcs, session-379 |
| SUB-REQ-008 | The Recording and Replay System SHALL continuously record all surveillance sensor inputs, processed track data, voice communications on all radio and telephone channels, and controller input events, timestamped to UTC with accuracy better than 1 ms, and SHALL retain all recordings for a minimum of 60 days on immediately accessible storage and 6 months on archival storage. Rationale: ICAO Annex 11 Section 6.4 and EUROCONTROL ESARR 5 mandate continuous recording for ATC incident investigation. 60-day immediate accessibility supports ANSP internal safety investigations; 6-month archival meets the maximum statutory retention period for judicial investigations in most ICAO Contracting States. Sub-millisecond timestamping enables reconstruction of event sequences during incident analysis. | Inspection | |
| SUB-REQ-008 | When the primary processing node fails, the Surveillance Data Processing subsystem SHALL complete automatic failover to a hot-standby processing node within 3 seconds, maintaining track continuity with position error not exceeding 500 m during the failover interval. Rationale: Derived from SYS-REQ-003 (99.9997% availability): a 3-second failover is the engineering optimum balancing switchover state synchronisation overhead against the risk of controllers losing track picture visibility. 3 seconds represents 0.75 track update cycles at 4-second update rate — track coasting algorithms can maintain position estimates within 500 m for this duration using last known velocity vectors. Longer failover would require controllers to initiate hold instructions for all sector traffic. | Test | subsystem, surveillance, degraded-mode, session-379 |
| SUB-REQ-009 | The Recording and Replay System SHALL support simultaneous replay of all recorded data streams at selectable playback rates from 0.25x to 8x real time, synchronised to a common timeline cursor, with the ability to extract and export defined time windows to EUROCONTROL standard replay format for external safety investigation tools. Rationale: Post-incident reconstruction requires the ability to replay the exact system state seen by controllers at the time of an event. Variable playback speeds support both detailed frame-by-frame analysis and rapid scanning of longer time periods. EUROCONTROL standard replay format (ASTERIX-based) ensures recordings are accessible to national CAA investigators using standard tooling, not only the ANSP's own replay application. | Test | |
| SUB-REQ-010 | The Surveillance Data Processing subsystem SHALL assign a unique track identity (TN) to each correlated surveillance return and maintain track identity continuity across all surveillance sensor coverage gaps not exceeding 60 seconds. Rationale: ICAO Doc 4444 requires unambiguous track identity for separation assurance; identity loss forces controllers to reconfirm aircraft identity manually, increasing workload and loss-of-separation risk. 60s gap tolerance is derived from ATC handoff procedures. | Test | subsystem, surveillance, session-384, idempotency:sub-sdp-track-identity-384 |
| SUB-REQ-011 | The Surveillance Data Processing subsystem SHALL process ADS-B Mode S, Secondary Surveillance Radar (SSR), Primary Surveillance Radar (PSR), and MLAT inputs and produce a fused track using a weighted Kalman filter biased towards the highest-accuracy source available. Rationale: Multi-sensor fusion is mandated by EUROCONTROL MOPS for en-route ATC; preferring ADS-B in coverage areas reduces radar-only latency from 5s to <1s. Kalman-weighted fusion prevents degraded track quality when low-accuracy sensors are online. | Test | subsystem, surveillance, session-384, idempotency:sub-sdp-sensor-fusion-384 |
| SUB-REQ-012 | When a predicted loss of separation is detected within a 120-second look-ahead window, the Safety Net System SHALL generate a Short-Term Conflict Alert (STCA) with audio and visual indication at the Controller Working Position within 3 seconds. Rationale: EUROCONTROL STCA specification requires 2-minute look-ahead minimum; 3-second alert delivery ensures the controller has actionable warning before the 120s window closes. Audio plus visual alert is required by ICAO human factors guidance (Doc 9426). | Test | subsystem, safety-net, session-384, idempotency:sub-sns-stca-alert-384 |
| SUB-REQ-013 | When a track is predicted to violate terrain or obstacle clearance criteria, the Safety Net System SHALL generate a Minimum Safe Altitude Warning (MSAW) alert within 8 seconds, using the current aeronautical information database. Rationale: MSAW is mandated by ICAO Annex 11 for all en-route and approach ATC facilities. 8s delivery is derived from typical terrain-closure rates for GA aircraft in mountainous terrain and controller reaction time requirements. | Test | subsystem, safety-net, session-384, idempotency:sub-sns-msaw-384 |
| SUB-REQ-014 | The Safety Net System SHALL maintain a STCA nuisance alert rate not exceeding 2% of all STCA alerts generated during normal operations. Rationale: Controller studies (EUROCONTROL HUM.ET1.ST05.1000-REP-01) show nuisance rates above 5% cause controllers to disable safety nets; 2% is the NATS operational ceiling. Nuisance rate is measured as false positives divided by total alerts over a 6-month evaluation period. | Analysis | subsystem, safety-net, session-384, idempotency:sub-sns-nuisance-rate-384 |
| SUB-REQ-015 | The Flight Data Processing subsystem SHALL distribute updated flight plan data to all Controller Working Positions within 5 seconds of receiving a clearance input or OLDI coordination message. Rationale: Flight plan currency is critical for correct strip labelling; stale data drives incorrect controller clearances. 5s is derived from ICAO Doc 4444 coordination timescales for sector handoffs. | Test | subsystem, flight-data, session-384, idempotency:sub-fdp-distribution-latency-384 |
| SUB-REQ-016 | The Controller Working Position subsystem SHALL allow a controller to input a direct routing, level assignment, or speed constraint for any displayed track within 3 keystrokes or mouse clicks and confirm the clearance back to the controller within 2 seconds. Rationale: EUROCONTROL HMI guidance and cognitive load studies establish that clearance input time greater than 10s under moderate traffic correlates with clearance errors; 3-keystroke limit and 2s feedback are consistent with NATS CWP usability standards. | Demonstration | subsystem, cwp, session-384, idempotency:sub-cwp-clearance-input-384 |
| SUB-REQ-017 | The Voice Communication System subsystem SHALL provide at least one dedicated guard frequency receiver (121.5 MHz) at each working position, operational independently of the primary voice switching system. Rationale: ICAO Annex 10 Volume II mandates continuous guard frequency monitoring at all ATC facilities; independence from primary VCS ensures guard monitoring survives VCS failures. This is a regulatory non-negotiable. | Inspection | subsystem, voice-comms, session-384, idempotency:sub-vcs-guard-freq-384 |
| SUB-REQ-018 | The Aeronautical Information Management subsystem SHALL update all airspace boundary, procedure, and waypoint data in the live operational database within 2 hours of an AIRAC cycle activation. Rationale: ICAO mandates AIRAC 28-day cycle adherence; delayed activation risks controllers issuing clearances based on superseded procedures. 2h window accommodates automated import validation without manual intervention. | Test | subsystem, aim, session-384, idempotency:sub-aim-airac-update-384 |
| SUB-REQ-019 | The Aeronautical Information Management subsystem SHALL provide a terrain and obstacle database covering the entire FIR at a resolution of at least 100m horizontal and 10m vertical, updated at least annually. Rationale: MSAW accuracy is directly bounded by terrain database resolution; 100m/10m resolution is the EUROCONTROL MSAW specification minimum. Annual update cycle reflects SRTM and national survey update schedules. | Inspection | subsystem, aim, session-384, idempotency:sub-aim-terrain-db-384 |
| SUB-REQ-020 | The Data Distribution Network subsystem SHALL enforce Quality-of-Service (QoS) priority queuing that ensures safety-critical traffic (STCA alerts, MSAW alerts, track updates) is delivered before management and administrative traffic during any congestion condition. Rationale: Network congestion from administrative traffic must not delay safety-critical alerts; EUROCONTROL DDN specification requires absolute priority for alert traffic. QoS enforcement is the implementation mechanism for the safety-critical latency requirement. | Test | subsystem, ddn, session-384, idempotency:sub-ddn-qos-priority-384 |
| SUB-REQ-021 | The System Monitoring and Control subsystem SHALL provide real-time dashboard visibility of CPU utilisation, memory utilisation, network throughput, and application process health for all subsystem nodes, refreshed at 10-second intervals. Rationale: Proactive monitoring is required to pre-empt subsystem failures before they affect the operational picture; 10s refresh is derived from expected growth rates of resource utilisation faults (burst vs gradual failure modes). | Demonstration | subsystem, smc, session-384, idempotency:sub-smc-dashboard-384 |
| SUB-REQ-022 | The Recording and Replay System SHALL maintain continuous recordings of all surveillance tracks, flight plan events, voice communications, and controller inputs for a minimum of 30 days, with cryptographic integrity protection. Rationale: ICAO Annex 11 Section 6.4 requires ATC recording retention for at least 30 days. Cryptographic integrity protection is required by UK CAA CAP 670 to ensure recordings are admissible in incident investigations. | Test | subsystem, recording, session-384, idempotency:sub-rrs-retention-384 |
| SUB-REQ-023 | The Surveillance Data Processing subsystem SHALL continue to produce fused track updates for at least 60% of active tracks at the nominal update rate when 2 of 4 surveillance sensor inputs are unavailable. Rationale: Degraded-mode requirement: dual sensor failure is a credible scenario (simultaneous PSR+SSR outage). 60% track retention ensures adequate separation assurance for high-priority flights; derived from minimum sector coverage requirements in NATS operations manuals. | Test | subsystem, surveillance, degraded, session-384, idempotency:sub-sdp-degraded-mode-384 |
| SUB-REQ-024 | The Controller Working Position subsystem SHALL support a configurable sector ownership display that shows all sectors within the FIR, current owner, and any pending transfers, updated within 5 seconds of any sector ownership change. Rationale: Sector ownership situational awareness is required to prevent clearance authority errors during sector splits and combines; 5s latency is the maximum acceptable delay for sector boundary changes per NATS operational procedures. | Test | subsystem, cwp, session-384, idempotency:sub-cwp-sector-display-384 |
| SUB-REQ-025 | The Controller Pilot Data Link Communications subsystem SHALL deliver uplinked clearances from ATC to suitably equipped aircraft within 10 seconds of controller transmission, and surface a delivery confirmation at the Controller Working Position within 60 seconds. Rationale: ICAO Doc 9694 CPDLC manual specifies 10s uplink latency as the maximum for operational acceptability; 60s response confirmation is the FANS-1/A protocol maximum for ATC Clearance category messages in oceanic operations. | Test | subsystem, cpdlc, session-384, idempotency:sub-cpdlc-uplink-latency-384 |
| SUB-REQ-026 | The Approach Sequencing and Metering subsystem SHALL compute an optimised landing sequence and associated speed/level advisories for all aircraft within 250nm of the destination airport, updating the sequence within 30 seconds of any new flight activation or estimated time revision. Rationale: AMAN planning horizon of 250nm provides 40-50 minute advisory lead time needed for trans-oceanic arrival sequencing; 30s update on plan change ensures the sequence reflects current traffic without creating controller confusion from excessive replanning. | Test | subsystem, aman, session-384, idempotency:sub-aman-sequence-compute-384 |
| SUB-REQ-027 | The Controller Pilot Data Link Communications subsystem SHALL authenticate all CPDLC uplink and downlink messages using ATN B1 or FANS-1/A+ digital signature mechanisms, rejecting any message that fails authentication within 2 seconds of receipt. Rationale: CPDLC messages carry legally binding ATC clearances. Message spoofing or replay attacks on datalink are a documented threat vector (ICAO EUR Doc 015); authentication is mandated by EUROCAE ED-110B for ATN B1 implementations and failure to reject forged messages could result in aircraft receiving unauthorized clearances. | Test | subsystem, cpdlc, session-385 |
| SUB-REQ-028 | The Controller Pilot Data Link Communications subsystem SHALL authenticate all CPDLC uplink and downlink messages using ATN B1 or FANS-1/A+ digital signature mechanisms, rejecting any message failing authentication within 2 seconds of receipt. Rationale: CPDLC messages carry legally binding ATC clearances. Message spoofing or replay attacks on datalink are documented in ICAO EUR Doc 015; authentication is mandated by EUROCAE ED-110B for ATN B1 implementations. Failure to reject forged messages could result in aircraft receiving unauthorized clearances. | Test | subsystem, cpdlc, session-385 |
| SUB-REQ-029 | When the primary VHF ACARS datalink path is unavailable, the Controller Pilot Data Link Communications subsystem SHALL automatically reroute pending CPDLC messages via the secondary SATCOM channel within 30 seconds, maintaining datalink connectivity for all active flights. Rationale: VHF ACARS coverage is limited to approximately FL240 and below within continental coverage areas. Oceanic and high-altitude operations require SATCOM backup. The 30-second switchover bound is derived from ICAO DOC 9694 CPDLC message timeout thresholds, which require retransmission within 60 seconds; failover must complete before the first retry expires. | Test | subsystem, cpdlc, session-385 |
| SUB-REQ-030 | When the primary VHF ACARS datalink path is unavailable, the Controller Pilot Data Link Communications subsystem SHALL automatically reroute pending CPDLC messages via the secondary SATCOM channel within 30 seconds, maintaining datalink connectivity for all active flights. Rationale: VHF ACARS coverage is limited at high altitudes and oceanic airspace. The 30-second switchover bound is derived from ICAO DOC 9694 CPDLC message timeout thresholds: retransmission is required within 60 seconds, so failover must complete before the first retry expires to avoid message loss. | Test | subsystem, cpdlc, session-385 |
| SUB-REQ-031 | The Controller Pilot Data Link Communications subsystem SHALL log all CPDLC message exchanges, including sender identity, timestamp, message content, delivery status, and acknowledgement time, retaining records for a minimum of 30 days in tamper-evident storage. Rationale: ICAO Annex 11 and EU Regulation 2017/373 require ATC service providers to retain all controller-pilot communications for incident investigation. Tamper-evident storage is required to preserve chain of evidence. 30 days aligns with the minimum statutory retention period for ATS communications. | Inspection | subsystem, cpdlc, session-385 |
| SUB-REQ-032 | The Approach Sequencing and Metering subsystem SHALL recompute the inbound landing sequence and all associated scheduled times of arrival within 15 seconds of any flight plan amendment, ATC intervention, or meteorological update that affects sequence order. Rationale: Sequence optimisation becomes stale within minutes of plan changes in busy terminal airspace. The 15-second recomputation bound is derived from controller operational practice: a sector controller takes approximately 20-30 seconds to implement a revised sequence instruction, requiring the system to provide updated guidance before the controller acts on stale data. | Test | subsystem, aman, sequencing, session-385 |
| SUB-REQ-033 | The Approach Sequencing and Metering subsystem SHALL generate separate and simultaneously valid landing sequences for up to 4 active runway configurations, allowing controllers to switch the active configuration without sequence discontinuity. Rationale: Large airports routinely operate parallel runways and change configurations for crosswind, noise abatement, or capacity reasons. Simultaneous 4-configuration support reflects the upper bound of real-world airport runway configurations; configuration switching during peak traffic without sequence discontinuity is essential to avoid missed approach scenarios from abrupt sequencing changes. | Test | subsystem, aman, session-385 |
| SUB-REQ-034 | The Approach Sequencing and Metering subsystem SHALL maintain an inbound sequence planning horizon of at least 40 minutes, providing preliminary scheduled times of arrival to en-route controllers for aircraft entering the terminal area manoeuvre horizon. Rationale: A 40-minute horizon allows en-route controllers to begin speed adjustments while aircraft are still 300+ NM from the terminal area, absorbing delay-at-cruise before the more fuel-expensive and operationally disruptive delay-in-holding pattern. EUROCONTROL AMAN operational guidance specifies minimum 30-minute horizon; 40 minutes is consistent with SESAR ER-AMAN implementations at Heathrow and Frankfurt. | Test | subsystem, aman, session-385 |
| SUB-REQ-035 | The Flight Data Processing subsystem SHALL process incoming and outgoing OLDI ABI, ACT, REV, and LAM message types for all adjacent ANSP boundary crossings, completing boundary coordination and acknowledgement within 30 seconds of receiving an ABI message. Rationale: OLDI (On-Line Data Interchange) is the mandatory ICAO-specified protocol for coordination of flights crossing FIR boundaries. The 30-second coordination window is derived from ICAO Doc 4444 sector boundary notification requirements, which specify minimum notification times of typically 2-5 minutes before boundary crossing. Late coordination triggers voice fallback, increasing controller workload and introducing coordination errors. | Test | subsystem, fdp, oldi, session-385 |
| SUB-REQ-036 | The Flight Data Processing subsystem SHALL provide trajectory prediction for all active and proposed flight plans over a look-ahead window of at least 20 minutes, with position prediction accuracy of better than 2 NM RMS at the 20-minute horizon for non-manoeuvring aircraft. Rationale: Trajectory prediction feeds conflict detection (safety net) and AMAN. The 20-minute horizon covers the 15-minute conflict probe window plus margin. The 2 NM RMS accuracy at 20 minutes is derived from published SESAR trajectory prediction performance studies: prediction errors beyond 5 NM at 20 minutes degrade conflict detection to below operational acceptance thresholds for separation standards of 5 NM. | Test | subsystem, fdp, trajectory, session-385 |
| SUB-REQ-037 | The Controller Working Position subsystem SHALL provide an electronic flight strip bay displaying all flights in the controller's sector, sorted by estimated time at the next significant point, with automated highlighting of flights within 5 minutes of sector boundary transfer. Rationale: Electronic flight strips replace paper strips at modern ATC facilities. Automatic boundary highlighting is a safety-critical feature: missed sector transfer is one of the top 5 causes of near-miss incidents in en-route ATC per EUROCONTROL ESARR 2 data. The 5-minute highlight threshold gives controllers adequate time to initiate transfer procedures. | Test | subsystem, cwp, efs, session-385 |
| SUB-REQ-038 | The Voice Communication System subsystem SHALL support conferencing of up to 6 radio frequencies and telephone lines simultaneously on a single controller position, with automatic squelch and mixing latency not exceeding 40 ms end-to-end from microphone input to loudspeaker output. Rationale: Multi-frequency conferencing is essential for cross-sector and cross-facility coordination during transition events. 40 ms total delay is the ITU-T G.114 recommendation for conversational voice quality; exceeding this introduces noticeable echo and degrades controller comprehension, which is safety-critical during high-workload coordination tasks. | Test | subsystem, vcs, conferencing, session-385 |
| SUB-REQ-039 | The facility power supply system SHALL provide two independent AC power feeds to all ATC subsystems: mains grid feed and a dedicated diesel generator capable of sustaining 100% of ATC operational load, with automatic transfer switch completing switchover within 500 ms of mains failure detection without loss of any running subsystem state. Rationale: SYS-REQ-007 mandates two independent power sources and ≤500ms switchover — this SUB requirement decomposes the facility power infrastructure obligation, specifying the ATS timing and load coverage needed to achieve the system-level availability claim. Without a SUB-level power supply requirement, SYS-REQ-007 has no implementation target and the S-002 power grid failure scenario trace chain is incomplete. | Test | subsystem, power-supply, session-536, idempotency:sub-power-supply-ats-536 |
| SUB-REQ-040 | The facility power supply system SHALL sustain all ATC subsystems at full operational load on diesel generator power alone for a minimum of 72 hours from a full fuel tank, with a low-fuel alarm at 8 hours remaining and a critical alarm at 2 hours remaining presented on the SMC workstation. Rationale: SYS-REQ-007 specifies 72-hour backup endurance. This SUB requirement adds operational monitoring obligations — staged fuel alarms at 8-hour and 2-hour thresholds — necessary for safe fuel management during extended mains outages. Without these thresholds, operators cannot coordinate refuelling before generator failure; the 8-hour trigger allows one standard maintenance cycle for refuelling. | Test | subsystem, power-supply, session-536, idempotency:sub-power-supply-endurance-536 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| IFC-REQ-001 | The interface between Surveillance Data Processing and Safety Net System SHALL deliver a complete fused track update for all active tracks to the Safety Net System within 200 ms of the track fusion cycle completing, using a publish-subscribe message bus with guaranteed delivery semantics. Rationale: The Safety Net System's 5-minute lookahead computation depends on receiving current track positions; a 200ms delivery budget is allocated from the 500ms end-to-end SDP processing budget (SUB-REQ-002), leaving 300ms for SDP internal processing. Publish-subscribe with guaranteed delivery prevents track data loss that would create undetected track gaps in safety net coverage. | Test | interface, session-379 |
| IFC-REQ-002 | The interface between Surveillance Data Processing and Flight Data Processing SHALL use a standardised ASTERIX Category 062 track message format for correlated track output, with message rate matching the SDP fusion cycle rate and including all mandatory data items for SSRCODE, MODE_C_ALT, and TRACK_STATUS. Rationale: ASTERIX Cat 062 is the EUROCONTROL standard for processed track data exchange between ATCS subsystems. Standardisation ensures interoperability with third-party subsystem replacements during system life extension programmes — ATC systems have 15-25 year operational lives and subsystem vendors change. Mandatory SSRCODE and MODE_C_ALT items are required for flight plan correlation in FDP. | Test | interface, session-379 |
| IFC-REQ-003 | The OLDI messaging interface between Flight Data Processing and Adjacent ATC Centres SHALL implement the full EUROCONTROL OLDI message set (ABI, ACT, MAC, REJ, LAM, CDN, ACP, TOC, AOC) and SHALL complete message round-trip transactions within 5 seconds for boundary coordination actions. Rationale: Derived from STK-REQ-005: OLDI automation eliminates manual telephone coordination. Full message set compliance is required to handle all coordination scenarios including boundary crossings with non-standard flight profiles. 5-second round-trip is the threshold above which controller workflow is disrupted — beyond this time, controllers revert to telephone backup which negates the automation benefit. | Test | interface, session-379 |
| IFC-REQ-010 | The interface between the Safety Net System and the Controller Working Position SHALL deliver STCA and MSAW alerts to the display within 500 ms of the Safety Net System detecting the alert condition, using a dedicated high-priority alert channel on the Data Distribution Network that cannot be blocked or delayed by non-safety-critical traffic. Rationale: Derived from SYS-REQ-004 (120-second conflict resolution time): the alert delivery chain must complete rapidly to preserve controller response time. 500ms alert delivery budget is derived from a 4-second track update cycle — one full scan cycle plus 500ms provides adequate time for the SNS to compute, raise, and deliver the alert before the next cycle. Dedicated alert channel prevents head-of-line blocking by flight plan updates. | Test | |
| IFC-REQ-011 | The interface between the Aeronautical Information Management subsystem and Surveillance Data Processing SHALL deliver terrain and airspace boundary data updates to the safety net geofencing database within 30 seconds of an AIRAC activation event. Rationale: MSAW and airspace infringement alerts derive from AIM data; any lag between AIRAC activation and safety net database update creates a window where alerts may be suppressed or falsely generated. 30s is derived from EUROCONTROL MSAW system design guidance. | Test | interface, aim, sdp, session-384, idempotency:ifc-aim-sdp-terrain-384 |
| IFC-REQ-012 | The interface between the Flight Data Processing subsystem and Controller Working Position SHALL transmit electronic flight strip data as an XML-encoded message conforming to ICAO/EUROCONTROL IFPS format, with end-to-end delivery latency not exceeding 2 seconds. Rationale: Flight strip display currency is required for controller situational awareness during handoffs; 2s end-to-end latency is the operational maximum to avoid strip display showing a superseded clearance during active ATC interaction. | Test | interface, fdp, cwp, session-384, idempotency:ifc-fdp-cwp-strips-384 |
| IFC-REQ-013 | The interface between the Voice Communication System and Controller Working Position SHALL allow a controller to select, monitor, transmit on, and record any licensed ATC frequency within 1 second of a frequency selection action. Rationale: Frequency selection latency directly impacts controller response times; 1s is the maximum tolerable delay for ATC communications per EUROCONTROL VCS human factors standards (HRS/HSP-005-GUI-01). | Test | interface, vcs, cwp, session-384, idempotency:ifc-vcs-cwp-frequency-384 |
| IFC-REQ-014 | The interface between the System Monitoring and Control subsystem and all other subsystems SHALL use SNMP v3 with AES-256 encryption for health telemetry, and deliver heartbeat messages at 5-second intervals. Rationale: SNMP v3 with AES-256 is required to prevent spoofed health telemetry that could mask a genuine subsystem failure; 5s heartbeat ensures SMC detects a subsystem silence within one monitoring cycle before the 10s dashboard refresh. | Inspection | interface, smc, monitoring, session-384, idempotency:ifc-smc-subsystems-snmp-384 |
| IFC-REQ-015 | The interface between the Recording and Replay System and the Data Distribution Network SHALL capture a bitstream copy of all safety-critical multicast groups in real time with no dropped packets during normal operation, and no more than 0.001% packet loss during single link failure conditions. Rationale: Incomplete recordings invalidate incident investigation and may result in regulatory non-compliance; 0.001% packet loss threshold under failure is derived from ICAO Annex 11 recording completeness requirements and the DDN redundancy design. | Test | interface, rrs, ddn, session-384, idempotency:ifc-rrs-ddn-capture-384 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| ARC-REQ-001 | The ATCS SHALL implement a dual-hot-standby processing architecture for Surveillance Data Processing and Flight Data Processing, with state synchronisation over a dedicated 10 Gbps synchronisation fabric, such that either node can assume full primary processing responsibility within 3 seconds without operator intervention. Rationale: Hot-standby architecture with a dedicated sync fabric is preferred over active-active load sharing because active-active introduces complexity in resolving conflicting track updates from two independent fused pictures. The 3-second failover with synchronised state allows track continuity — no controller is aware of the switchover. Alternative considered: cold standby. Rejected: cold standby requires full re-correlation of flight plans and tracks, taking 30-60 seconds and requiring ATC supervisor notification and traffic hold instructions. | Analysis | implements-SYS-REQ-003, implements-SYS-REQ-009, arc-validated-session-533 |
| ARC-REQ-002 | The ATCS SHALL implement the Safety Net System as a safety-instrumented function independent of the operational processing path, with its own dedicated processing nodes, independent power supply, and separate communication path from the surveillance sensor network, achieving SIL 3 per IEC 62061. Rationale: Safety net independence from operational processing is a fundamental EUROCONTROL ESARR 4 architectural principle. If the Safety Net shared compute resources with operational processing (SDP, FDP), a software fault causing operational processing overload could simultaneously degrade or disable the safety net — removing the last barrier before a mid-air collision. SIL 3 target is derived from ESARR 4 severity apportionment: safety net failure contributes to Severity Class 1 (accident) and must achieve a probability less than 10^-7/flight hour. | Analysis | implements-SYS-REQ-004, sil-3-architecture, arc-validated-session-533 |
| ARC-REQ-011 | The Data Distribution Network SHALL use VLAN segmentation to isolate safety-critical traffic (track data, STCA/MSAW alerts) from operational traffic (flight plan updates, OLDI messages, system management). Safety-critical VLANs SHALL be physically implemented on a dedicated network segment with no Layer-2 bridging to the operational VLAN. Dual-ring topology with rapid spanning tree protocol SHALL be used for sub-50ms link failure recovery. Rationale: VLAN isolation prevents a broadcast storm or traffic burst on the operational network from consuming bandwidth on the safety-critical segment. Physical isolation (separate switch fabric, not just VLAN tags) provides defence in depth against misconfiguration errors — a mislabeled packet cannot enter the safety-critical VLAN even if VLAN tagging is incorrectly configured. This was the primary driver for dedicated DDN hardware rather than a shared enterprise network. | Analysis | implements-SYS-REQ-006, arc-validated-session-533 |
| ARC-REQ-012 | The Aeronautical Information Management subsystem SHALL implement a dual-database architecture with a live active database and a staging database. AIRAC cycle updates SHALL be loaded and validated in staging while the live database remains in production service. Switchover to the updated database SHALL occur at the AIRAC effective time (0001 UTC) with the ability to revert to the previous cycle database within 2 hours if validation or operational issues are detected post-activation. Rationale: AIRAC updates are high-risk change events — an incorrect database activation could introduce wrong sector boundaries or invalid procedures into live operations. Staging allows full pre-activation validation without impacting live operations. The 2-hour reversion window allows operations management to identify procedural discrepancies before the next major traffic peak. A single-database design with in-place update would require service interruption for AIRAC loading — unacceptable for a 24/7 system. | Analysis | implements-SYS-REQ-001, implements-SYS-REQ-009, arc-validated-session-533 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| VER-011 | The system-level track position accuracy (SYS-REQ-001) SHALL be verified by a full-system integration test using live radar sensor feeds and ADS-B reference transponders at known surveyed positions. Test procedure: (1) place 10 reference transponders at surveyed locations across the FIR; (2) run live radar and ADS-B ingestion for 1 hour; (3) compare fused track positions against surveyed references. Pass criterion: RMS position error ≤250m for en-route tracks and ≤50m for terminal tracks across all 10 reference positions. Rationale: SYS-REQ-001 is a system-level performance requirement spanning SDP, DDN, and CWP — component-level tests verify individual contributions but cannot confirm end-to-end fused accuracy through the full processing chain. A reference transponder test at surveyed positions provides ground truth that simulation cannot replicate, per EUROCONTROL ESARR 4 integration verification requirements. | Test | idempotency:ver-sys-001-track-accuracy |
| VER-012 | The surveillance track picture update rate (SYS-REQ-002) SHALL be verified by injecting simulated radar and ADS-B data at maximum track density (2500 tracks) and measuring the display refresh interval at the CWP operator workstation. Pass criterion: en-route track symbols updated ≤4 seconds between refreshes; terminal area track symbols updated ≤1 second between refreshes; sustained over a 30-minute load period with no degradation. Rationale: SYS-REQ-002 sets an end-to-end latency budget from sensor to display — verifying sub-systems in isolation does not confirm that the full pipeline (sensor ingestion → SDP fusion → FDP correlation → CWP render) meets the composite deadline. The 4s/1s thresholds are derived from ICAO Doc 4444 track update requirements for radar display systems; deviation would cause track history symbols to mislead controllers about aircraft position. | Test | idempotency:ver-sys-002-update-rate |
| VER-013 | The Short-Term Conflict Alert advance warning time and missed detection probability (SYS-REQ-004) SHALL be verified by replaying 1000 recorded near-miss scenarios through the full system, each with a known CPA time and separation minimum. Pass criterion: (1) system issues STCA alert ≥120 seconds before CPA in ≥99.999% of scenarios; (2) missed detection count ≤10 out of 1000 scenarios (10^-2 observed, extrapolated to 10^-5 per flight hour by FTA cross-check). Must include 100 scenarios with weather radar interference, Mode C garbling, and ADS-B spoofing. Rationale: STCA is the last automated safety barrier before a mid-air collision — IEC 61508 SIL 3 requires missed detection probability ≤10^-5. Statistical test coverage of 1000 scenarios with adversarial inputs (garbling, spoofing) is required because analytical methods alone cannot account for multi-sensor fusion failure modes. EUROCONTROL ESARR 4 requires test-based validation for SIL 3 functions. | Test | idempotency:ver-sys-004-stca-alert |
| VER-014 | The system track and flight plan processing capacity (SYS-REQ-005) SHALL be verified by a load test injecting 2500 simultaneous correlated surveillance tracks and 5000 active flight plan records into the SDP/FDP systems, sustained for 60 minutes. Pass criterion: (1) CWP display refresh rate does not drop below 1 Hz during sustained load; (2) FDP flight plan query response time remains ≤500ms at 95th percentile; (3) SDP track processing latency remains ≤2 seconds end-to-end; (4) no track dropouts or flight plan data corruption observed. Rationale: Capacity under concurrent load is an emergent property that cannot be confirmed by testing SDP and FDP in isolation — resource contention on the Data Distribution Network and shared processing nodes only manifests under full-system load. The 2500/5000 limits represent the declared FIR maximum; exceeding them would require flow restrictions on all traffic. | Test | idempotency:ver-sys-005-capacity |
| VER-015 | The network isolation between operational ATC network and external networks (SYS-REQ-006) SHALL be verified by a penetration test conducted by an accredited independent security assessor. Test procedure: (1) attempt to inject data directly into the ATC operational network from each external feed point (AFTN, meteorological, airline ACARS) without passing through the data diode or application gateway; (2) attempt to establish bidirectional communication through each unidirectional data diode; (3) attempt VLAN hop from external-facing switch to safety-critical VLAN. Pass criterion: all 3 test categories produce zero successful injections or bidirectional paths. Rationale: Network isolation against external threats cannot be verified by inspection of configuration alone — misconfigurations, firmware vulnerabilities, and VLAN hop techniques require active testing. EUROCONTROL ESARR 5 requires independent security assessment for ATM systems connected to external networks. The data diode hardware provides a physical one-way enforcement mechanism whose correctness must be validated by attempted bypass. | Test | idempotency:ver-sys-006-network-isolation |
| VER-016 | The dual power supply switchover time and backup endurance (SYS-REQ-007) SHALL be verified by: (1) with all ATCS subsystems at full operational load, disconnect mains power feed and measure time to full transfer to diesel generator; (2) sustain operation on generator power alone for 72 hours with continuous system monitoring. Pass criterion: (1) switchover achieved in ≤500ms with no loss of ATC operational capability; (2) all subsystems remain fully operational throughout 72-hour generator run; (3) fuel consumption and battery buffer behaviour consistent with type-test specifications. Rationale: Power continuity is a life-safety requirement — if the 500ms switchover target is not met, SDP and CWP displays may blank during handover, presenting controllers with an unannounced loss of traffic picture. The 72-hour endurance requirement addresses extended grid outage scenarios (weather events, national grid fault). These cannot be verified by analysis alone because generator load characteristics and battery buffer decay are system-specific. | Test | idempotency:ver-sys-007-power-supply |
| VER-017 | The medium-term conflict probe advance warning time (SYS-REQ-008) SHALL be verified by injecting 200 test flight plan pairs with known geometric intersection points at 15, 20, 25, and 30 minutes ahead, with varied aircraft performance and route configurations. Pass criterion: for all 50 cases with intersection ≥20 minutes ahead, the conflict probe tool notifies the controller within 30 seconds of flight plan entry; no false notification generated for any of the 150 cases with intersection <20 minutes or no intersection. Rationale: The 20-minute advance warning is the controller planning horizon for conflict resolution at cruise altitudes — insufficient advance notice forces last-minute vector solutions that increase controller workload and may be infeasible in congested airspace. False positives (notification of non-conflicts) degrade controller trust and lead to alert suppression. Geometric injection testing at boundary values is required to confirm algorithm correctness at the 20-minute threshold. | Test | idempotency:ver-sys-008-conflict-probe |
| VER-018 | The degraded mode continuity and recovery time (SYS-REQ-009) SHALL be verified by failing each of the 11 ATCS subsystems in turn (one at a time, simulated by process termination or hardware removal) and measuring: (1) time to automatic switchover to backup/degraded mode; (2) minimum capability retained (surveillance display present, voice communications active); (3) time from failure injection to restoration of full service. Pass criterion: for each subsystem failure, degraded mode achieved in ≤30 seconds with surveillance and voice communications active; full service restored in ≤15 minutes by automated recovery or technician action. Rationale: SYS-REQ-009 is the primary availability/resilience requirement — it must be tested by actual failure injection, not by analysis of redundancy architecture. Each subsystem has different failover mechanisms (hot standby SDP/FDP, passive VCS backup, RRS fallback) and recovery paths that must be validated individually. The 15-minute recovery target is derived from ANSP service level agreements with CAA and requires empirical confirmation. | Test | idempotency:ver-sys-009-degraded-mode |
| VER-019 | The OLDI B2B interface to EUROCONTROL CFMU Network Manager (SYS-REQ-010) SHALL be verified by end-to-end interoperability testing against the CFMU acceptance test environment. Test procedure: (1) initiate flight plan activation, modification, and cancellation messages for 50 test flights; (2) confirm round-trip message exchange timing; (3) inject 10 non-nominal scenarios (boundary crossing, flight plan amendment during active coordination). Pass criterion: all message types exchanged successfully per EUROCONTROL OLDI specification; message latency ≤2 seconds for all transaction types; no message loss or duplication in nominal or non-nominal scenarios. Rationale: OLDI B2B interoperability requires testing against the actual CFMU acceptance environment — the protocol has version-specific behaviours and error handling that cannot be validated against a local stub. Coordination failures at sector boundaries are a historical cause of mid-air collision precursor events; the interface must be tested against real CFMU message flows. | Test | idempotency:ver-sys-010-oldi-b2b |
| VER-020 | The recording completeness, tamper-evidence, and regulatory access time (SYS-REQ-011) SHALL be verified by: (1) injecting 4 hours of synthetic track, voice, and controller input data and confirming all records are stored to the RRS; (2) attempting to modify a stored record and confirming the tamper-detection mechanism raises an integrity alert; (3) issuing a regulatory retrieval request and measuring time to delivery of a complete data package. Pass criterion: 100% of injected events captured in RRS; tamper attempt raises alert within 5 seconds and the modified record is flagged as invalid; data delivery to regulatory authority within 2 hours of request. Rationale: SYS-REQ-011 has regulatory compliance implications — failure to provide tamper-evident recordings risks UK CAA enforcement action under the Air Navigation Order 2016. Tamper-evidence cannot be verified by inspection of the cryptographic scheme alone; active tampering attempts are required to confirm the implementation correctly rejects modifications. The 2-hour retrieval SLA must be tested end-to-end including data format conversion and secure transfer mechanisms. | Test | idempotency:ver-sys-011-recording |
| VER-021 | The ASTERIX Category 062 output latency and message loss (SYS-012) SHALL be verified by: (1) registering 5 test consumer endpoints; (2) injecting 10,000 track updates at maximum track density; (3) measuring end-to-end delivery time from track update generation timestamp to receipt at each consumer. Pass criterion: 99th percentile delivery latency ≤500ms; zero message loss across all 10,000 updates at all 5 consumers sustained over 60 minutes. Rationale: ASTERIX Cat 062 latency must be tested at full track density because the DDN and track output gateway share network resources with operational processing — contention only appears under load. The CFMU 500ms SLA has contractual and operational consequences if breached; test coverage must replicate real consumer endpoint behaviour. | Test | idempotency:ver-sys-012-asterix-latency |
| VER-REQ-001 | The Surveillance Data Processing subsystem track position accuracy (SUB-REQ-002) SHALL be verified by injecting 1000 simulated aircraft tracks at known positions via a radar replay facility and measuring RMS position error of the fused output against ground truth, at both en-route (>1000m AGL) and terminal (<1000m AGL, within 30 NM) conditions. Rationale: Accuracy verification by simulation replay is the only practicable method — live flight measurement requires extensive air traffic coordination, airspace closure, and reference aircraft instrumentation. Radar replay facilities with known-position injection are the standard ANSP acceptance test method, validated in EUROCONTROL's ASTERIX test framework. 1000 tracks provides statistical significance at the required 250m and 50m RMS thresholds. | Test | verification, session-379 |
| VER-REQ-002 | The Safety Net System missed detection probability (SUB-REQ-004) SHALL be verified by analytical reliability modelling using a fault tree analysis (FTA) referencing IEC 61508 methodology, with all significant failure modes and common cause failures identified, and the resulting FTA reviewed and endorsed by an independent safety assessor. Rationale: The 10^-6 missed detection target cannot be verified by statistical testing — achieving sufficient test volume would require hundreds of millions of conflict scenarios. FTA per IEC 61508 is the accepted certification methodology for safety-critical detection systems at this integrity level. Independent safety assessor review is required by EUROCONTROL ESARR 4 and national CAA requirements for safety-critical ATM system changes. | Analysis | verification, session-379 |
| VER-REQ-003 | The system operational availability (SYS-REQ-003) SHALL be verified by 12 months of operational monitoring with automated availability logging, capturing all unplanned service interruptions with timestamps and root cause classification, achieving a demonstrated availability of at least 99.9997% before final certification. Rationale: Availability targets at the 99.9997% level can only be demonstrated by extended operational service — simulation cannot replicate the full range of environmental, hardware aging, and operational failure modes that occur in live service. 12 months provides sufficient observational period to distinguish random failures from systematic weaknesses. Automated logging prevents subjective outage classification and ensures auditability for CAA certification review. | Demonstration | verification, session-379 |
| VER-REQ-013 | The Data Distribution Network end-to-end safety-critical message latency (SUB-REQ for DDN) SHALL be verified by injecting synthetic track update messages from a simulated SDP output and measuring arrival time at the Safety Net System interface under three loading conditions: idle, 50% operational load, and 110% overload, confirming 10ms at 99th percentile under all conditions. Rationale: Network latency must be verified under realistic load conditions — idle-state measurements do not reveal queuing delays under burst traffic. 110% overload scenario tests QoS behaviour when total offered load exceeds capacity, confirming that safety-critical traffic maintains priority and low latency while operational traffic is degraded. Measurement is only possible via synthetic injection — live traffic cannot be instrumented without affecting operational messages. | Test | |
| VER-REQ-014 | The Controller Working Position display refresh rate and track symbol update latency (SUB-REQ-006) SHALL be verified by driving the CWP display system with pre-recorded track data and measuring display refresh rate with a high-speed camera (minimum 240fps) and symbol position update latency using frame-difference analysis, under a 40-aircraft sector load with simultaneous STCA alert rendering. Rationale: Display performance requirements cannot be verified by software instrumentation alone — the GPU rendering pipeline, video hardware, and monitor refresh rate all contribute to perceived latency. High-speed camera measurement captures the full end-to-end latency including display hardware. The 40-aircraft concurrent load test ensures performance degradation under realistic operational conditions is characterised before deployment. | Test | |
| VER-REQ-015 | The Safety Net System STCA nuisance alert rate (sub-requirement) SHALL be verified by a 6-month operational monitoring trial using live traffic, counting nuisance alerts as any STCA alert dismissed by the controller within 10 seconds without corrective action. Rationale: Nuisance alert rate cannot be accurately assessed in lab simulation because traffic density and complexity drive false positive rates; 6-month operational trial is the EUROCONTROL acceptance standard for STCA deployments. | Test | verification, safety-net, session-384, idempotency:ver-sns-nuisance-trial-384 |
| VER-REQ-016 | The Voice Communication System guard frequency monitoring independence (sub-requirement) SHALL be verified by inspection of circuit diagrams and a live test that disables the primary voice switching fabric and confirms guard frequency receive capability is preserved. Rationale: Guard frequency independence is a regulatory requirement; inspection plus live failure test is the CAA-mandated verification approach for safety-critical independence claims. Simulation is not accepted for this requirement class. | Inspection | verification, voice-comms, session-384, idempotency:ver-vcs-guard-independence-384 |
| VER-REQ-017 | The Surveillance Data Processing degraded-mode track continuity (sub-requirement) SHALL be verified by a controlled test injecting dual sensor failure while 200 synthetic tracks are active and confirming that at least 120 tracks (60%) continue to update at nominal rate within 30 seconds. Rationale: Degraded-mode performance cannot be verified by analysis alone; a live controlled failure injection test is required to validate sensor switching and fusion algorithm behaviour under realistic conditions. | Test | verification, surveillance, degraded, session-384, idempotency:ver-sdp-degraded-mode-384 |
| VER-REQ-018 | The Recording and Replay System data retention and integrity (sub-requirement) SHALL be verified by storing a test recording stream for 30 days and confirming that playback retrieval succeeds for 100% of stored records and cryptographic hash verification passes for all records. Rationale: Recording completeness and integrity are legal requirements; verification must confirm both storage longevity (30 days) and cryptographic integrity of the stored data, which cannot be validated by shorter-duration testing. | Test | verification, recording, session-384, idempotency:ver-rrs-retention-integrity-384 |
| VER-REQ-019 | The CPDLC message authentication mechanism (SUB-REQ-028) SHALL be verified by injecting syntactically valid but cryptographically invalid CPDLC messages into the datalink subsystem and confirming rejection in all cases within 2 seconds, with zero false-positive rejections of valid messages during a 1000-message regression suite. Rationale: Cryptographic authentication can fail by accepting bad messages or rejecting good ones. Both failure modes must be tested. The 1000-message suite provides statistical confidence that false-positive rate is below 1 in 1000, acceptable for an operational system where false rejections degrade datalink availability. | Test | verification, cpdlc, session-385 |
| VER-REQ-020 | The Approach Sequencing and Metering 40-minute planning horizon (SUB-REQ-034) SHALL be verified by injecting a test scenario with 40 inbound flights at the 40-minute boundary and confirming that all flights appear in the sequence display with valid STAs within 15 seconds of scenario activation, with STA accuracy within plus or minus 30 seconds of calculated optimal times. Rationale: The 40-minute horizon is a functional boundary condition. The plus or minus 30 second STA accuracy threshold is derived from AMAN operational requirements: controllers issue speed instructions in 10-knot increments which produce approximately 30-60 second time adjustments, so AMAN predictions must be accurate to within one instruction step. | Test | verification, aman, session-385 |
| VER-REQ-021 | The Flight Data Processing trajectory prediction accuracy (SUB-REQ-036) SHALL be verified by replaying a 4-hour recorded traffic sample against the prediction engine and measuring position error at T+5, T+10, T+15, and T+20 minutes for at least 500 track samples. Pass criterion: 90th percentile position error shall be less than 2 NM at T+20 for non-manoeuvring flight segments. Rationale: FDP trajectory prediction accuracy is measured by replaying recorded traffic and computing position error statistics — this is a test procedure with quantified acceptance criteria (90th percentile ≤NM at T+5 through T+20 minutes), not an analysis. Analysis would imply algorithmic derivation from specifications; here we are instrumenting the running system against known reference data. | Test | verification, fdp, trajectory, session-385 |
| VER-REQ-023 | The Safety Net System conflict prediction function (SUB-REQ-003) SHALL be verified by injecting 500 synthetic conflict scenarios spanning the full parameter space and confirming prediction of loss of separation within the 120-second look-ahead window for all scenarios where CPA is less than 5 NM horizontal or 1000 ft vertical, with zero missed alerts in safety-critical configurations. Rationale: The 120-second look-ahead is the primary parameter of the conflict detection algorithm and must be verified across the full operational envelope. 500 scenarios spanning closing speed and geometry provides coverage of failure modes identified in EUROCONTROL STCA Specification Version 2.1. | Test | |
| VER-REQ-024 | The Minimum Safe Altitude Warning function (SUB-REQ-013) SHALL be verified by replaying 100 CFIT-precursor track profiles against the MSAW module with terrain database loaded and confirming alert generation at least 30 seconds before projected terrain impact in all cases, plus replaying 200 benign descent scenarios and confirming zero false terrain warnings. Rationale: MSAW is SIL-3. Verification must use representative CFIT-precursor profiles to validate true positive detection. False warning rate testing is equally critical: controller habituation to false MSAW alerts is a systemic safety risk documented in ICAO CFIT prevention circular AN-WP/8779. | Test | |
| VER-REQ-025 | The Surveillance Data Processing multi-sensor ingestion capability (SUB-REQ-001) SHALL be verified by a system integration test connecting live or simulated feeds from all four required sensor types (PSR, SSR Mode S, ADS-B, MLAT) simultaneously, confirming that all sensors contribute tracks to the fused picture within 10 seconds of sensor connection and that removal of any single sensor does not cause track loss for aircraft covered by at least two remaining sensors. Rationale: Multi-sensor fusion correctness cannot be verified by testing each sensor in isolation — fusion algorithm behaviour under concurrent inputs, including conflict resolution when sensors disagree, must be tested with simultaneous feeds. This requirement tests the sensor integration boundary condition that EUROCONTROL guidance identifies as a common integration failure point. | Test | |
| VER-REQ-026 | The Surveillance Data Processing track identity assignment (SUB-REQ-010) SHALL be verified by injecting a 200-aircraft scenario where 20 aircraft perform Mode S interrogation responses, confirming that each aircraft receives a unique track identity within two scan cycles, and injecting a scenario where the same aircraft departs and returns to coverage within 5 minutes, confirming track continuity is re-established with the same identity within one scan cycle. Rationale: Track identity assignment failures cause STCA and MSAW to operate on incorrect track histories, creating safety risks. The re-acquisition scenario tests the most common identity continuity failure mode — controllers routinely rely on track history to predict aircraft behaviour, so identity instability directly degrades situational awareness. | Test | |
| VER-REQ-027 | The Flight Data Processing flight plan lifecycle management (SUB-REQ-005) SHALL be verified by executing a 4-hour traffic sample with 150 flight plans, confirming correct state transitions (filed, activated, transferred, completed) for 100% of flight plans and verifying that the subsystem holds flight plan state for flights that disconnect from surveillance for up to 10 minutes without deletion. Rationale: Flight plan lifecycle errors are a leading cause of trajectory confusion incidents. The 10-minute persistence test directly verifies the degraded-mode requirement for temporary surveillance loss — controllers operate in airspace where radar blind spots exist and must not lose flight plan context during brief gaps in coverage. | Test | |
| VER-REQ-028 | The CPDLC message delivery latency and confirmation (SUB-REQ-025) SHALL be verified by injecting 1000 CPDLC uplink messages and measuring time-to-confirmation from transmission to receipt of WILCO, UNABLE, or ROGER response, confirming that 99% of messages receive a delivery confirmation within 60 seconds, and that the subsystem generates an unacknowledged message alert to the controller for any message not confirmed within 90 seconds. Rationale: CPDLC delivery assurance is an operational safety requirement: unconfirmed clearances may not have been received by the aircraft. The 60-second 99th percentile threshold aligns with EUROCONTROL CPDLC performance monitoring guidance for en-route operations. The 90-second alert threshold gives controllers actionable notification within the time window before re-transmit or voice backup is required. | Test | |
| VER-REQ-029 | The Aeronautical Information Management NOTAM propagation (SUB-REQ-003) SHALL be verified by injecting 50 NOTAMs of different types (airspace restriction, navaid unserviceable, obstacle new) via the ANSP feed simulator and measuring time between NOTAM injection and availability in the AIM query interface, confirming propagation within 60 seconds for all types, with cryptographic signature validation confirmed for all 50 NOTAMs. Rationale: NOTAM propagation delay is operationally critical: a controller displaying an outdated airspace picture may issue clearances into newly restricted airspace. 60-second propagation is derived from ICAO AIM transition standards. Cryptographic validation testing ensures the dual-database integrity mechanism (ARC-REQ-012) actually detects modification — testing both valid and corrupted NOTAMs is required. | Test | |
| VER-REQ-030 | The Data Distribution Network single-switch failure survivability (SUB-REQ-005) SHALL be verified by a controlled test removing each switch in the network fabric one at a time while active traffic (simulated 200 track updates per second) is flowing, measuring network reconvergence time and confirming that no safety-critical message stream experiences more than 50ms interruption and that operational traffic recovers within 200ms. Rationale: Switch removal testing must be conducted with live traffic load because network reconvergence time is traffic-dependent. The 50ms safety-critical interruption limit is derived from the SNS update cycle — a 100ms STCA processing window requires network delivery within 50ms to allow processing within cycle. Testing each switch individually identifies any single switch whose removal causes disproportionate impact. | Test | |
| VER-REQ-031 | The System Monitoring and Control health deviation detection (SUB-REQ-006) SHALL be verified by injecting simulated subsystem health parameter anomalies for each monitored subsystem in turn — CPU utilisation spike, message queue depth increase, network packet loss threshold breach — and confirming that the SMC subsystem generates an alert within 10 seconds of the injected anomaly crossing the detection threshold, with zero false alerts during a 24-hour clean-state monitoring run. Rationale: SMC detection latency directly affects operator response time to developing failures. The 10-second detection threshold is derived from operational resilience requirements: a subsystem degradation that goes undetected for more than 10 seconds may progress to service disruption before the operator can respond. Testing each subsystem individually validates that monitoring coverage is complete, not just that the alerting mechanism works. | Test | |
| VER-REQ-032 | The Voice Communication System simultaneous independent channel capability (SUB-REQ-007) SHALL be verified by configuring and simultaneously activating all required VHF/UHF channels and the guard frequency monitor, confirming by protocol analyser that each transmit/receive path is electrically and logically independent, and conducting a live reception test confirming that simultaneous transmissions on all channels are correctly discriminated with no cross-talk at the headset output below -60 dBc. Rationale: Channel independence is a certification requirement under CAA Air Traffic Services Communication Standards. Cross-talk verification at -60 dBc ensures that simultaneous multi-frequency operation does not degrade intelligibility on any channel — the threshold is the minimum intelligibility standard under ICAO Annex 10 for air-ground communications. | Test | |
| VER-REQ-033 | The Recording and Replay System simultaneous replay capability (SUB-REQ-009) SHALL be verified by initiating playback of three concurrent replay sessions from different time windows on the same recording, confirming that all three sessions maintain real-time playback rate without frame drops over a 30-minute test period, and that interleaving read operations from three sessions does not affect ongoing live recording write performance (verified by confirming no gaps in the live recording during the test). Rationale: Simultaneous replay is required during incidents when multiple investigators need independent access to recorded data. The key performance risk is I/O contention between concurrent read sessions and ongoing live recording. Testing confirms that the storage subsystem handles concurrent access without degrading the primary safety function of live continuous recording. | Test | |
| VER-REQ-034 | The SDP failover timing (SUB-REQ-008) SHALL be verified by: (1) disconnecting the primary processing node power while running live radar simulation at 350 tracks; (2) measuring time from node failure detection to full track processing resumption on the hot-standby node using a NTP-synchronised precision timer. Pass criterion: failover completes within 3 seconds and track continuity is maintained with position error not exceeding 500 m during the failover interval. Rationale: Automatic failover timing is safety-critical as SDP outage of >3 s creates a surveillance gap detectable by SNS. Physical disconnect test is the only method that accurately simulates hardware failure — software-simulated failover does not exercise OS process recovery paths and RAID state synchronisation timing. | Test | |
| VER-REQ-035 | The SNS STCA alert timing (SUB-REQ-012) SHALL be verified by: (1) injecting 100 simulated separation-violating track pairs with predicted conflicts at 30s, 60s, and 120s look-ahead windows; (2) measuring time from first predicted-conflict detection to STCA audio and visual alert appearing at the CWP. Pass criterion: alert generated within 3 seconds of detection for all 100 scenarios, with audio and visual simultaneous. Rationale: STCA alert latency is a SIL-4 safety requirement — a 3-second delay prevents timely controller intervention for close-proximity conflicts. Physical end-to-end timing must be measured from SNS processing to CWP display; analysis cannot account for IPC queuing latency and display rendering time. | Test | |
| VER-REQ-036 | The AIM AIRAC cycle update timing (SUB-REQ-018) SHALL be verified by: (1) injecting a complete AIRAC cycle data package at a controlled time T0; (2) querying the live operational database for an airspace boundary, procedure, and waypoint update at T0+2h. Pass criterion: all three data types are updated and queryable from the operational database within 2 hours of AIRAC activation. Rationale: AIRAC data currency is an ICAO AIP regulatory obligation — controllers relying on stale airspace boundaries risk procedural non-compliance. A 2-hour update window is tested at system level because AIM data pipelines involve ETL transforms, validation, and publication that must be exercised end-to-end. | Test | |
| VER-REQ-037 | The DDN QoS priority queuing (SUB-REQ-020) SHALL be verified by: (1) generating synthetic congestion load at 95% link utilisation; (2) simultaneously injecting STCA alert packets and best-effort management traffic; (3) measuring delivery latency for each traffic class. Pass criterion: safety-critical traffic (STCA, MSAW, track updates) arrives within the required latency budget (<50 ms end-to-end) while management traffic is queued, for all 20 congestion test runs. Rationale: QoS priority enforcement cannot be verified by Analysis because switch firmware and buffer management behaviour under high load is vendor-implementation-dependent and may not match the datasheet specification. Empirical congestion testing at near-capacity load is the only reliable method. | Test | |
| VER-REQ-038 | The CPDLC ACARS failover (SUB-REQ-029) SHALL be verified by: (1) establishing active CPDLC sessions on 5 aircraft over VHF ACARS; (2) cutting primary ACARS link; (3) measuring time for automatic rerouting via SATCOM and confirming session continuity. Pass criterion: all 5 sessions rerouted via SATCOM within 30 seconds; no message loss for messages injected after the failover event. Rationale: CPDLC failover time is a safety requirement — if rerouting takes >30 s, inflight clearances may be delayed beyond the controller intervention window. Physical link severance test is required because software simulation of ACARS link failure does not exercise real SATCOM routing table convergence timing. | Test | |
| VER-REQ-039 | The AMAN sequence recomputation latency (SUB-REQ-032) SHALL be verified by: (1) loading a 20-aircraft inbound scenario; (2) injecting flight plan amendments, ATC interventions, and meteorological updates at 30-second intervals; (3) measuring recomputation latency for each event type. Pass criterion: updated sequence with revised STAs generated within 15 seconds for all event types across 50 test runs. Rationale: AMAN recomputation latency determines whether revised STAs are usable for en-route controller instructions — a 15-second bound is the Eurocontrol A-CDM contractual SLA. Testing under live event injection is required because algorithm convergence time varies with traffic density and amendment type in ways that resist analytical bounding. | Test | |
| VER-REQ-041 | The SDP multi-sensor fusion (SUB-REQ-011) SHALL be verified by: (1) simultaneously injecting simulated ADS-B, SSR, PSR, and MLAT returns for 200 identical track scenarios; (2) checking that each fused track is correctly weighted towards the highest-accuracy source (ADS-B > MLAT > SSR > PSR) and that the output matches the known ground-truth trajectory within 50 m RMS. Pass criterion: sensor weighting is correct for all 200 scenarios and fusion accuracy meets the 50 m RMS threshold. Rationale: Multi-sensor fusion correctness underpins all downstream SNS STCA calculations. Testing must inject all four sensor types simultaneously to verify the Kalman filter bias — testing sensors individually does not demonstrate correct relative weighting during concurrent reception. | Test | |
| VER-REQ-043 | The FDP clearance distribution latency (SUB-REQ-015) SHALL be verified by: (1) entering 50 sequential clearance inputs at a test CWP and measuring time from CWP confirmation to receipt of the updated flight plan at all other CWPs in the sector; (2) replaying 50 OLDI coordination messages and measuring distribution latency to all CWPs. Pass criterion: all clearance/OLDI updates delivered to all CWPs within 5 seconds. Rationale: Clearance distribution latency directly affects conflict resolution — a controller at another sector position acting on a stale flight plan may issue conflicting clearances. End-to-end latency cannot be confirmed by analysis because DDN QoS behaviour under concurrent clearance load is non-linear. | Test | |
| VER-REQ-044 | The CWP clearance input efficiency (SUB-REQ-016) SHALL be verified by: (1) having 3 qualified ATC controllers attempt 50 direct routing, level, and speed inputs on a representative track dataset; (2) counting keystrokes/clicks per input and measuring time from first input action to on-screen confirmation. Pass criterion: all inputs completable within 3 keystrokes or clicks and confirmation appears within 2 seconds for ≥95% of attempts. Rationale: CWP input efficiency directly affects controller cognitive load during high-traffic periods. Human-in-the-loop testing with qualified controllers is required because input efficiency depends on UI interaction flow and cognitive steps, not just technical performance metrics. | Test | |
| VER-REQ-045 | The VCS guard frequency independence (SUB-REQ-017) SHALL be verified by: (1) powering down the primary voice switching system while the guard receiver is active; (2) transmitting a test tone on 121.5 MHz and confirming audio is received at the CWP loudspeaker. Pass criterion: guard frequency audio received at CWP within 2 seconds of transmission while primary VCS is offline, for all 5 working positions tested. Rationale: Guard frequency independence is a regulatory requirement (ICAO Doc 4444 emergency communications). The test requires physical VCS shutdown because software simulation cannot verify hardware independence of the guard receiver circuit from the main switching fabric. | Test | |
| VER-REQ-047 | The AIM terrain and obstacle database coverage (SUB-REQ-019) SHALL be verified by: (1) sampling 100 randomised geographic points across the FIR and querying the AIM terrain database for each; (2) checking resolution and comparing against an authoritative DTED Level 2 reference. Pass criterion: all 100 points are present in the AIM database with horizontal resolution ≤100 m and vertical resolution ≤10 m, and values agree with the reference within measurement uncertainty. Rationale: AIM terrain database accuracy drives MSAW alert validity — insufficient resolution or stale data causes missed CFIT warnings. Statistical sampling across 100 points at random FIR coordinates provides 95% confidence at 5% error rate for coverage and accuracy compliance. | Test | |
| VER-REQ-049 | The SMC real-time health dashboard (SUB-REQ-021) SHALL be verified by: (1) inducing CPU spike, memory leak, and network saturation conditions on three separate subsystem nodes in sequence; (2) observing the SMC dashboard for reflection of each condition. Pass criterion: each health parameter breach is visible on the SMC dashboard within 10 seconds of condition onset for all three node types. Rationale: SMC refresh accuracy depends on telemetry polling cycles, SNMP trap propagation, and UI rendering pipeline — each of which introduces latency that cannot be analytically bounded without empirical measurement. 10-second visibility is operationally required so shift supervisors can act before subsystem failure. | Test | |
| VER-REQ-050 | The RRS 30-day retention with integrity protection (SUB-REQ-022) SHALL be verified by: (1) running the RRS for a 30-day test window at full data rate; (2) at the end of the period, verifying all required data streams are present without gaps; (3) attempting to modify one stored record and confirming the cryptographic integrity check detects the tampering. Pass criterion: no data gaps >1 second in any stream over 30 days; tamper detection triggers within 5 seconds of modification. Rationale: 30-day retention is a mandatory ICAO ATCO occurrence investigation requirement. Storage continuity and cryptographic integrity cannot be verified by Analysis because storage system capacity and filesystem fragmentation behaviour are operational variables. Physical tamper-detection test demonstrates the security mechanism is active, not just configured. | Test | |
| VER-REQ-051 | The CWP sector ownership display currency (SUB-REQ-024) SHALL be verified by: (1) executing 20 sector boundary transfers in rapid succession (1 per 15 seconds); (2) verifying the sector ownership display at three remote CWPs reflects each transfer. Pass criterion: all 20 sector ownership changes are visible at all three remote CWPs within 5 seconds of the change event. Rationale: Sector ownership currency is safety-critical for handoff coordination — a stale ownership display could lead a controller to issue a clearance for an aircraft in another controller's sector. End-to-end propagation test is required because FDP distribution latency and CWP display rendering latency are both contributors and cannot be reliably bounded without measurement. | Test | |
| VER-REQ-052 | The AMAN landing sequence computation (SUB-REQ-026) SHALL be verified by: (1) loading a high-density traffic scenario (25 inbound aircraft within 250nm); (2) requesting initial AMAN sequence and confirming the sequence with advisories is generated within 30 seconds. Pass criterion: initial sequence generated within 30 seconds, sequence update delivered within 30 seconds of injecting a new flight plan revision. Rationale: AMAN sequence computation latency directly affects whether speed/level advisories reach en-route controllers with sufficient lead time for efficient sequencing. The 30-second threshold is a Eurocontrol A-CDM operational requirement and must be demonstrated under representative traffic density. | Test | |
| VER-REQ-053 | The CPDLC message authentication (SUB-REQ-027) SHALL be verified by: (1) injecting 100 CPDLC messages with valid ATN B1/FANS-1/A+ signatures; (2) injecting 100 messages with invalid or missing signatures; (3) measuring rejection latency for the invalid set. Pass criterion: all 100 valid messages are accepted, all 100 invalid messages are rejected within 2 seconds of receipt with a DATALINK STATUS alert at the CWP. Rationale: CPDLC authentication prevents spoofed clearances from being presented to controllers. Both acceptance and rejection paths must be tested; analysis of cryptographic library compliance does not demonstrate correct integration into the CPDLC message pipeline. | Test | |
| VER-REQ-055 | The CPDLC message logging and tamper-evidence (SUB-REQ-031) SHALL be verified by: (1) executing 200 CPDLC message exchanges; (2) reviewing log records for completeness (sender, timestamp, content, delivery status, ack time); (3) attempting to modify a stored log record and confirming the system detects the modification. Pass criterion: all 200 exchanges are logged with all required fields; tamper detection is triggered within 5 seconds. Rationale: CPDLC logs are mandatory for accident investigation (ICAO Annex 11). Tamper-evidence is a legal obligation — regulatory authorities require logs to be court-admissible. Physical tamper test demonstrates the integrity mechanism is active in the deployed configuration, not just present in the specification. | Test | |
| VER-REQ-057 | The AMAN multi-runway configuration (SUB-REQ-033) SHALL be verified by: (1) configuring all 4 runway configurations simultaneously in the AMAN system; (2) switching the active configuration mid-sequence; (3) confirming no sequence discontinuity in any other configuration. Pass criterion: all 4 sequences remain valid and displayed without interruption during and after the configuration switch. Rationale: Multi-runway sequence validity is operationally critical for airports with parallel runways requiring simultaneous independent approaches. Testing requires physical configuration switching in a running AMAN instance because sequence state management under concurrent runway configurations cannot be verified by inspection of the design. | Test | |
| VER-REQ-058 | The AMAN planning horizon (SUB-REQ-034) SHALL be verified by: (1) populating the AMAN with 30 aircraft at ranges from 0 to 50 minutes ETA; (2) verifying preliminary STAs are presented on the en-route display for aircraft at the 40-minute horizon. Pass criterion: valid preliminary STAs are generated and visible on the en-route display for all aircraft within the 40-minute planning horizon. Rationale: The 40-minute planning horizon is the minimum needed for en-route controllers to issue pre-sequence speed advisories before the aircraft enters the descent profile. Verification must use a populated traffic scenario because AMAN look-ahead cutoff depends on computational resource allocation that varies with traffic count. | Test | |
| VER-REQ-059 | The FDP OLDI coordination processing (SUB-REQ-035) SHALL be verified by: (1) injecting 100 ABI, ACT, REV, and LAM messages from 4 simulated adjacent ANSPs; (2) measuring time from ABI receipt to boundary coordination acknowledgement. Pass criterion: all message types are correctly processed and acknowledgements generated within 30 seconds for all 100 injected messages. Rationale: OLDI coordination is a bilateral agreement between ANSPs — correct ABI/ACT/REV/LAM processing is required for legal transfer of responsibility at FIR boundaries. 30-second processing is the EUROCONTROL OLDI SLA. End-to-end testing with simulated adjacent ANSP systems is the only method that validates the full coordination loop. | Test | |
| VER-REQ-060 | The FDP trajectory prediction accuracy (SUB-REQ-036) SHALL be verified by: (1) running 500 historical traffic scenarios with known ground-truth trajectories; (2) comparing FDP 20-minute trajectory predictions against ground-truth using RMS error. Pass criterion: RMS position error at the 20-minute horizon is <2 NM for non-manoeuvring aircraft across all 500 scenarios. Rationale: FDP trajectory accuracy directly affects STCA look-ahead reliability — prediction errors >2 NM at 20 min cause either false STCA alerts or missed conflicts. Accuracy must be validated against historical ground-truth rather than modelled data because atmospheric variability and aircraft performance model errors are real-world variables. | Test | |
| VER-REQ-061 | The CWP electronic flight strip bay (SUB-REQ-037) SHALL be verified by: (1) populating a sector with 25 active flights, each at different phases of flight; (2) observing the CWP electronic flight strip bay for sort order and boundary transfer highlighting. Pass criterion: all flights sorted by ETA to next significant point, and all flights within 5 minutes of sector boundary transfer are highlighted, with highlighting applied within 5 seconds of crossing the time threshold. Rationale: Electronic flight strip sort order and transfer highlighting are the primary pilot awareness tools replacing paper strips — incorrect display directly impairs controller situational awareness. Human-in-the-loop verification with real traffic scenarios is required because display logic interacts with FDP data in ways that cannot be fully confirmed by unit testing. | Test | |
| VER-REQ-062 | The VCS conferencing latency (SUB-REQ-038) SHALL be verified by: (1) establishing a 6-way conference on a single controller position mixing 4 radio frequencies and 2 telephone lines; (2) measuring end-to-end audio latency from microphone input to loudspeaker output using a calibrated audio delay measurement system. Pass criterion: end-to-end latency ≤40 ms for all 6 simultaneous channels across 20 test runs. Rationale: VCS conference latency >40 ms causes noticeable echo and double-talk degradation in controller-pilot voice communications, a known factor in ATCO communication errors (EUROCONTROL Human Factors report HUM.ET1.ST13.3000-REP-01). Latency must be measured physically because digital mixing pipeline delays depend on hardware buffer configuration. | Test | |
| VER-REQ-063 | The SDP→SNS track data interface (IFC-REQ-001) SHALL be verified by: (1) injecting 500 track updates from a simulated SDP at 1-second intervals; (2) measuring receipt timestamp at the SNS input queue and confirming data format against the ASTERIX Cat-062 specification. Pass criterion: all 500 updates received at SNS within the IFC latency budget (≤200 ms end-to-end) and zero format violations. Rationale: The SDP→SNS interface carries the track data on which STCA conflict predictions are based. Interface timing and format errors at this boundary could cause SNS to operate on stale or malformed tracks, producing missed alerts. End-to-end timing measurement validates that the full IPC path meets the latency budget. | Test | |
| VER-REQ-064 | The SDP→FDP track data interface (IFC-REQ-002) SHALL be verified by: (1) running 200 aircraft scenarios with known track positions; (2) confirming FDP receives standardised ASTERIX Cat-062 position updates for all 200 aircraft; (3) checking correlation between SDP track identities and FDP flight plan identifiers. Pass criterion: 100% track delivery with correct correlation for all 200 aircraft; zero format errors. Rationale: The SDP→FDP interface links surveillance identities to flight plans, enabling clearance-track correlation. Correlation errors here lead to clearances being applied to the wrong flight plan. Standardised format compliance (ASTERIX Cat-062) must be verified by injection test because schema validation tools only check structure, not data semantics. | Test | |
| VER-REQ-065 | The FDP OLDI interface to Adjacent ATC Centres (IFC-REQ-003) SHALL be verified by: (1) simulating 4 adjacent ANSP boundary crossings with 50 flights per crossing; (2) injecting ABI, ACT, REV, LAM message sequences; (3) confirming correct message framing, sequence numbering, and acknowledgement within the OLDI SLA. Pass criterion: all message types correctly framed to EUROCONTROL OLDI spec; acknowledgements returned within 30 seconds. Rationale: OLDI interface correctness is legally required for FIR boundary coordination — incorrect framing or sequence numbering causes adjacent ANSP systems to reject coordination, leaving aircraft without legal transfer of responsibility. Physical protocol testing against a simulated adjacent ANSP is required because OLDI conformance cannot be confirmed by internal FDP unit tests. | Test | |
| VER-REQ-066 | The SNS→CWP STCA alert delivery interface (IFC-REQ-010) SHALL be verified by: (1) generating 100 STCA events at the SNS; (2) measuring time from STCA generation to audio and visual alert at the CWP HMI. Pass criterion: all 100 alerts delivered with both audio and visual components at all CWP positions within 3 seconds of SNS detection. Rationale: SNS→CWP STCA delivery latency is the final link in the safety net alert chain. Delays at this interface reduce the controller's response window to below the safety margin. Verifying interface latency separately from end-to-end latency allows locating whether bottlenecks are in the IPC path or in the CWP rendering pipeline. | Test | |
| VER-REQ-067 | The AIM→SDP navigation data interface (IFC-REQ-011) SHALL be verified by: (1) updating a waypoint and airspace boundary in the AIM; (2) measuring time for the updated data to be received and applied by SDP for track correlation. Pass criterion: navigation database updates are propagated from AIM to SDP within 60 seconds of publication and applied to track correlation within 5 minutes of the AIRAC cycle activation. Rationale: AIM→SDP navigation data currency drives MSAW terrain correlation accuracy. If SDP uses outdated terrain or obstacle data received from AIM, MSAW alerts may be missed or falsely generated. Timing verification must be end-to-end to confirm the publication-to-application propagation cycle meets AIRAC obligations. | Test | |
| VER-REQ-068 | The FDP→CWP flight data interface (IFC-REQ-012) SHALL be verified by: (1) executing 100 flight plan amendments at FDP; (2) measuring time for each amendment to appear at the CWP flight strip bay and sector data displays. Pass criterion: all 100 amendments visible at all subscribed CWPs within 5 seconds; zero data loss or format errors. Rationale: FDP→CWP flight data delivery is on the critical path for controller situational awareness. A 5-second delivery latency matches the FDP distribution requirement (SUB-REQ-015) and must be confirmed at the interface level to identify whether delays originate in the FDP or the DDN/CWP rendering pipeline. | Test | |
| VER-REQ-069 | The VCS→CWP voice integration interface (IFC-REQ-013) SHALL be verified by: (1) selecting a radio frequency at a CWP position and transmitting on that frequency; (2) confirming audio is routed to the correct CWP loudspeaker and that the CWP displays the selected frequency active status. Pass criterion: frequency selection reflected on CWP within 500 ms; audio routing confirmed at CWP within 1 second of transmission; no cross-talk between controller positions. Rationale: VCS→CWP frequency selection interface is safety-critical — an incorrect routing (transmitting on wrong frequency or receiving on wrong loudspeaker) could cause a controller to miss a pilot call or transmit on an incorrect frequency. Physical radio test with calibrated audio monitoring is required to verify routing correctness. | Test | |
| VER-REQ-070 | The SMC→subsystems health monitoring interface (IFC-REQ-014) SHALL be verified by: (1) inducing health parameter breaches in SDP, SNS, FDP, and VCS simultaneously; (2) confirming the SMC monitoring interface receives and displays the health deviations from all four subsystems within the 10-second dashboard refresh cycle. Pass criterion: all 4 subsystem health deviations visible on SMC dashboard within 10 seconds and categorised with correct subsystem identity. Rationale: SMC health monitoring interface coverage is required across all subsystems — a single unmonitored subsystem failure could degrade ATC services without operator awareness. Simultaneous breach injection across 4 subsystems verifies that the monitoring interface scales correctly and that subsystem health data is not dropped under concurrent load. | Test | |
| VER-REQ-071 | The RRS→DDN recording capture interface (IFC-REQ-015) SHALL be verified by: (1) running the full system at peak traffic load (350 tracks, 50 active flights, full voice recording); (2) confirming the RRS captures all data streams from the DDN interface without packet loss. Pass criterion: zero packet loss on all RRS capture streams at peak load over a 4-hour sustained test period. Rationale: RRS recording completeness is a mandatory regulatory requirement (ICAO Annex 11). The RRS→DDN interface must support the full system data rate without packet loss — interface saturation could cause recording gaps that invalidate incident investigation records. Peak-load testing over 4 hours is necessary to detect buffer overflow conditions not apparent in short-duration tests. | Test | |
| VER-REQ-072 | The SNS-to-CWP alert delivery latency (IFC-REQ-010) SHALL be verified by: (1) configuring an instrumented CWP display with sub-millisecond timestamping; (2) injecting 1,000 synthetic STCA and MSAW alert triggers; (3) measuring interval from SNS alert generation to display render at CWP. Pass criterion: 100% of alerts delivered within 500ms; no alert blocked by simultaneous injection of 2,000 flight plan updates/minute on the operational VLAN. Rationale: IFC-REQ-010 specifies a 500ms alert delivery SLA on a dedicated priority channel — head-of-line blocking by operational traffic is the key risk. Test must replicate worst-case DDN congestion to confirm safety VLAN isolation holds under load. Inspection of VLAN config alone is insufficient; active measurement under traffic stress is required per EUROCONTROL ESARR 4. | Test | idempotency:ver-ifc-010-sns-cwp-alert-534 |
| VER-REQ-073 | The dual-hot-standby failover capability (ARC-REQ-001) SHALL be verified by: (1) running both SDP and FDP nodes in primary/standby configuration with live traffic; (2) inducing an unplanned primary node failure by severing the network connection; (3) measuring time from failure detection to standby node assuming full primary processing responsibility. Pass criterion: standby assumes full primary role within 3 seconds; no track discontinuity visible at CWP (no displayed track gaps >1 scan cycle, i.e. >4 seconds); operator receives no 'correlation lost' or 'track dropped' alerts during switchover. Rationale: ARC-REQ-001 specifies a 3-second failover with no track continuity loss — Analysis alone cannot verify this because the synchronisation fabric latency and state transfer completeness are implementation-dependent. A live failover test under traffic load is required to confirm that state synchronisation is sufficient to eliminate track correlation loss at switchover. This is the ATC equivalent of a fire drill — it must be tested, not inferred. | Test | idempotency:ver-arc-001-hot-standby-failover-534 |
| VER-REQ-074 | The Safety Net System architectural independence from operational processing (ARC-REQ-002) SHALL be verified by analysis: an independent functional safety assessor SHALL review SDP/FDP/SNS process isolation, memory space separation, power supply independence, and network path isolation. The assessor SHALL produce a SIL 3 claim substantiation report per IEC 62061 Section 7 confirming that the SNS failure rate is ≤10^-7 per flight hour. Acceptance criterion: third-party SIL 3 certificate issued with no outstanding Category 1 safety issues. Rationale: ARC-REQ-002 specifies SIL 3 for the Safety Net System — this cannot be demonstrated by functional test alone. IEC 62061 requires a systematic safety assessment including FMEA, fault tree analysis, and independence verification. An independent third-party assessment is the accepted verification method for SIL 3 claims; EUROCONTROL ESARR 4 mandates external safety oversight for safety instrumented functions in ATC. | Analysis | idempotency:ver-arc-002-sns-sil3-analysis-534 |
| VER-REQ-075 | The DDN VLAN segmentation and physical isolation (ARC-REQ-011) SHALL be verified by: (1) a network topology inspection confirming separate switch fabric for safety-critical and operational VLANs with no Layer-2 bridge ports; (2) a traffic injection test flooding the operational VLAN at 90% capacity for 30 minutes while measuring safety-critical VLAN throughput; (3) a link failure test removing one ring segment and confirming RSTP convergence. Pass criterion: inspection confirms physical separation; safety-critical VLAN throughput not degraded by >1% during operational flood; RSTP convergence within 50ms on ring failure. Rationale: DDN VLAN segmentation verification includes an active traffic injection test (flooding the operational VLAN at 90% capacity and confirming zero cross-VLAN bleed on the safety-critical VLAN). The network topology review is a supporting step, but the binding evidence comes from the active injection test. Requirements with quantified pass criteria confirmed by instrumented test execution must be classified as Test, not Inspection. | Test | idempotency:ver-arc-011-vlan-segmentation-534 |
| VER-REQ-076 | The AIM subsystem dual-database AIRAC switchover and reversion (ARC-REQ-012) SHALL be verified by demonstration: (1) load a complete AIRAC cycle package into the staging database; (2) validate the staging database against the production database to confirm all sector boundaries and procedures load correctly; (3) trigger a scheduled switchover at 0001 UTC and confirm the live database transitions to the new cycle without service interruption; (4) within the 2-hour reversion window, revert to the previous cycle and confirm all sector boundaries restore to their previous values. Pass criterion: switchover completes in under 30 seconds; no ATC service interruption detected at CWP; reversion completes in under 60 seconds. Rationale: ARC-REQ-012 specifies a live AIRAC switchover procedure with a 2-hour reversion window — this must be demonstrated end-to-end including the ATC operational impact (no service interruption) because database activation faults in production have caused loss of sector boundary visibility. Timed switchover and reversion are operational procedures that must be validated before they are executed in a live ATC environment. | Demonstration | idempotency:ver-arc-012-aim-airac-switch-534 |
| VER-REQ-077 | The Recording and Replay System multi-stream replay capability (SUB-REQ-009) SHALL be verified by: (1) recording 2 hours of synthetic track, voice, OLDI, and controller input data; (2) replaying at 0.25x, 1x, 4x, and 8x playback rates with all streams simultaneously active; (3) verifying temporal synchronisation between tracks, voice clips, and controller inputs at each playback rate; (4) exporting a 30-minute time window to EUROCONTROL standard format and loading into an external investigation tool. Pass criterion: all stream combinations synchronised to within 100ms across all playback rates; export loads correctly in EUROCONTROL-standard investigation tooling without data loss. Rationale: SUB-REQ-009 specifies variable-rate synchronised multi-stream replay — synchronisation drift between voice and track data at high playback speeds can mislead safety investigators. The EUROCONTROL export format must be tested with an actual external tool because format compatibility cannot be confirmed by inspection of the export specification alone. Post-incident replay quality directly affects the accuracy of safety investigation findings. | Test | idempotency:ver-sub-009-rrs-replay-534 |
| VER-REQ-078 | The Aeronautical Information Management navigation data query latency (REQ-SEAIRTRAFFICCONTROL-002) SHALL be verified by: (1) configuring a test client to issue 1000 sequential queries for waypoint, airspace boundary, and procedure data; (2) measuring round-trip response time from query submission to data receipt using a NTP-synchronised precision timer; (3) issuing queries under peak load (50 concurrent SDP/FDP clients). Pass criterion: 99th-percentile response time not exceeding 100ms under peak concurrent load; zero query timeouts or dropped responses. Rationale: REQ-SEAIRTRAFFICCONTROL-002 specifies sub-100ms query response to support real-time trajectory processing in FDP and SDP. If AIM queries exceed this bound, FDP trajectory prediction and SDP track-to-waypoint correlation will lag behind aircraft position, potentially causing late conflict detection. A load test with 50 concurrent clients is required because AIM query latency degrades under simultaneous SDP/FDP access patterns during sector boundary transitions. | Test | idempotency:ver-aim-nav-query-latency-535 |
| VER-REQ-079 | The System Monitoring and Control secure configuration management interface (REQ-SEAIRTRAFFICCONTROL-007) SHALL be verified by: (1) attempting configuration changes without administrator credentials and confirming rejection with logged denial; (2) making 20 configuration parameter changes under authenticated session and confirming each change is written to the immutable audit log within 5 seconds; (3) reviewing the audit log for completeness (operator ID, timestamp, parameter changed, old value, new value). Pass criterion: all unauthenticated attempts rejected with error code and audit entry; all authenticated changes logged within 5 seconds with full provenance; audit log entries are non-modifiable (attempt to edit fails). Rationale: REQ-SEAIRTRAFFICCONTROL-007 specifies authenticated access with immutable audit logging for SMC configuration — this is a safety-critical control because unauthorised configuration changes could disable subsystem health monitoring or alter safety thresholds. Inspection alone cannot verify that the audit trail is genuinely immutable; injection testing of both authorised and unauthorised access paths is required to confirm the enforcement mechanism. | Test | idempotency:ver-smc-config-mgmt-535 |
| VER-REQ-080 | The Controller Working Position display refresh rate and track symbol update latency (native SUB-REQ-006) SHALL be verified by: (1) driving the CWP display subsystem with a synthetic radar feed providing 350 simultaneous tracks at full sector capacity; (2) measuring the interval between consecutive screen refreshes of the same track label using a high-speed frame capture device (minimum 120fps); (3) measuring latency from radar data receipt to corresponding symbol movement on CWP display. Pass criterion: track symbol refresh rate not less than 4Hz for all visible tracks; display update latency not exceeding 250ms at 99th percentile under full sector load. Rationale: Native SUB-REQ-006 specifies a 4Hz minimum refresh rate for all CWP display elements — controllers require smooth track symbol movement to accurately assess aircraft trajectories and separation trends. Below 4Hz, discrete track jumps impair separation assurance, particularly for high-speed traffic converging at close proximity. Frame capture verification is required because software timer measurements miss missed frames caused by rendering pipeline backpressure. | Test | idempotency:ver-cwp-display-refresh-535 |
| VER-REQ-081 | The AIM subsystem aeronautical database completeness and AIRAC update timing (REQ-SEAIRTRAFFICCONTROL-001) SHALL be verified by: (1) injecting a complete AIRAC cycle package into the AIM at a controlled reference time T0 and confirming via AIM audit log that the new dataset is active within 120 minutes of T0; (2) extracting a random sample of 200 database items (airways, waypoints, sector boundaries, prohibited areas, SIDs/STARs, and instrument approach procedures) and comparing against the EUROCONTROL AIXM 5.1 reference dataset to verify zero schema validation errors; (3) confirming the prior-cycle dataset is retained and revertable until the new cycle is operationally accepted. Pass criterion: dataset active ≤T0+120min; 0/200 schema violations; prior-cycle revert succeeds within 15 minutes. Rationale: REQ-SEAIRTRAFFICCONTROL-001 makes two verifiable claims: AIRAC data covers all required element types (verifiable only by systematic schema comparison against EUROCONTROL AIXM 5.1) and updates are applied within 2 hours (verifiable only by controlled timing injection). The revert test confirms AIM dual-database safe fallback before new cycle acceptance, required by EUROCONTROL ESARR 4. | Test | verification, aim, airac, session-537, idempotency:ver-aim-database-completeness-537, idempotency:ver-aim-database-completeness-537 |
| VER-REQ-082 | The facility power supply ATS switchover performance (REQ-SEAIRTRAFFICCONTROL-074) SHALL be verified by: (1) with all ATC subsystems at full operational load, trigger simulated mains failure by opening the main breaker; (2) measure time from mains voltage loss detection to restoration of power from diesel generator on all distribution busbars; (3) confirm no running subsystem process terminates during transfer. Pass criterion: ATS switchover complete in ≤500ms; no CWP display freeze, no voice drop, no track processing gap detectable in recorded data. Rationale: The 500ms switchover threshold is the system-level requirement driven by EUROCONTROL ESARR 4 short-duration interruption limits. Only a physical mains-failure test exercises the actual ATS relay timing, UPS bridge behaviour, and subsystem resilience simultaneously — software simulation cannot replicate this. | Test | verification, power-supply, session-536, idempotency:ver-power-supply-switchover-536 |
| VER-REQ-083 | The diesel generator 72-hour endurance and fuel alarm system (REQ-SEAIRTRAFFICCONTROL-075) SHALL be verified by: (1) conducting a type-test fuel consumption measurement at full ATC operational load to verify the tank capacity covers ≥72 hours; (2) simulating fuel level sensor readings at 8-hour-remaining and 2-hour-remaining thresholds and confirming alarm display on SMC workstation within 30 seconds. Pass criterion: calculated endurance ≥72 hours at certified fuel consumption rate; both fuel alarms presented on SMC within 30 seconds of threshold trigger. Rationale: Physical tank endurance testing at operational load establishes the actual fuel consumption rate, which cannot be derived analytically with sufficient precision for a 72-hour safety claim. Alarm functional testing is required separately because sensor threshold logic is independently programmable and may be misconfigured without this test. | Test | verification, power-supply, session-536, idempotency:ver-power-supply-endurance-536 |
| VER-REQ-084 | The DDN VLAN segmentation isolation (ARC-REQ-011) SHALL be verified by: (1) configuring a test host on the safety-critical VLAN and attempting to inject non-safety-critical traffic to safety-critical multicast groups; (2) injecting 1000 ASTERIX Cat 062 track packets while saturating the operational VLAN at 90% capacity, confirming zero packet loss on the safety-critical VLAN; (3) auditing switch port VLAN membership to confirm no unapproved cross-VLAN ports. Pass criterion: inter-VLAN injection fails at Layer 2 within 100ms; zero track packet loss under saturation; zero unapproved cross-VLAN ports. Rationale: ARC-REQ-011 makes two verifiable claims: VLAN isolation prevents cross-traffic and safety-critical traffic is protected from head-of-line blocking. Injection attempt is the only method to confirm runtime isolation; saturation test confirms protection under load. Inspection of switch config alone is insufficient. | Test | verification, arc, ddn, vlan, session-538, idempotency:ver-arc-011-ddn-vlan-session-538 |
| VER-REQ-085 | The AIM dual-database architecture (ARC-REQ-012) SHALL be verified by: (1) loading a corrupted AIRAC package into the AIM staging database and confirming the active live database remains unchanged and operationally available; (2) confirming via AIM audit log that the schema validation failure triggers an alert within 60 seconds without affecting the live database; (3) performing a successful rollback by loading the prior valid AIRAC cycle into staging and activating it with live database availability maintained throughout. Pass criterion: live database unaffected during staging failure; alert raised in ≤60 seconds; rollback completes in ≤15 minutes. Rationale: ARC-REQ-012 exists to prevent AIRAC update failures from causing AIM operational outages. The staging-failure isolation test is the only method to confirm the dual-database boundary holds under fault conditions — analysis of the architecture cannot confirm runtime isolation. | Test | verification, arc, aim, dual-database, session-538, idempotency:ver-arc-012-aim-dual-db-session-538 |
| VER-REQ-086 | The SNS-to-CWP alert delivery interface (IFC-REQ-010) SHALL be verified by: (1) triggering 50 STCA alerts and 50 MSAW alerts in a certified ATCS test environment with the SNS generating alerts at T0 and a timestamped packet capture on the dedicated alert channel confirming CWP receipt; (2) simultaneously saturating the Data Distribution Network with non-safety traffic at 95% link utilisation and confirming alert delivery latency remains within 500ms; (3) disconnecting the dedicated alert channel and confirming the CWP displays an alert channel failure indication within 10 seconds. Pass criterion: 100/100 alerts delivered ≤500ms under nominal and saturated conditions; channel failure detected ≤10s. Rationale: IFC-REQ-010 specifies a 500ms delivery budget on a dedicated high-priority channel that cannot be blocked by non-safety-critical traffic. Test is the only appropriate method: Analysis cannot predict actual network behaviour under saturation, and Inspection of channel configuration cannot confirm runtime priority enforcement. The channel-failure detection test confirms the alerting path is itself monitored. | Test | verification, ifc, sns, cwp, stca, msaw, session-538, idempotency:ver-ifc-010-sns-cwp-alert-session-538 |
| VER-REQ-087 | The Recording and Replay System simultaneous multi-stream replay (SUB-REQ-009) SHALL be verified by: (1) configuring a replay session with all recorded data streams active (radar tracks, voice communications, ADS-B, Mode S, OLDI messages, controller inputs) using a 30-minute golden recording, and confirming all streams remain time-synchronised to the common timeline cursor within ±100ms at playback rates of 0.25x, 1x, 4x, and 8x; (2) extracting a 10-minute window from the golden recording, exporting to EUROCONTROL replay format, and importing into a EUROCONTROL-supplied reference tool confirming successful playback without format errors; (3) running concurrent replay of two independent timeline windows and confirming no cross-contamination between sessions. Pass criterion: all streams within ±100ms at all playback speeds; zero EUROCONTROL format import errors; no cross-session contamination. Rationale: SUB-REQ-009 makes three verifiable claims: multi-stream time synchronisation at variable playback rates, EUROCONTROL standard format export compatibility, and independent concurrent replay session isolation. Only Test with a known golden recording can verify synchronisation accuracy and format compliance. Analysis cannot validate 8x playback timing without runtime measurement. | Test | verification, sub, rrs, replay, session-538, idempotency:ver-sub-009-rrs-replay-session-538 |
| VER-REQ-088 | The maintenance LRU hot-swap capability (SYS-REQ-013) SHALL be verified by: (1) placing the ATCS in full operational load with 2000 active tracks and 10 active controller workstations; (2) removing and reinserting each LRU type (processing blade, display processor, network switch, voice gateway) in turn while confirming via monitoring logs that no active ATC service is lost (STCA, display, voice remain operational throughout); (3) measuring time from LRU insertion to full subsystem functionality confirmed by automated health check output. Pass criterion: zero service interruption events logged; full functionality restored within 30 minutes for every LRU type. Rationale: SYS-REQ-013 makes two verifiable claims: no service interruption during swap and 30-minute restoration bound. Both require live-traffic-load testing — bench testing without concurrent ATC operations cannot validate that swap procedures are transparent to the operational traffic path. The pass criterion mirrors the STK-REQ-008 time bound exactly. | Test | idempotency:ver-sys-013-lru-swap-session-539 |
| VER-REQ-089 | The ASTERIX Category 062 System Track output latency and delivery reliability (SYS-012) SHALL be verified by: (1) configuring the ATCS with 2500 active tracks at steady-state load; (2) injecting 10,000 track update events while simultaneously recording the ASTERIX Cat 062 output stream at all registered consumer interfaces; (3) timestamping each track update at source and at each consumer interface using a GPS-disciplined synchronised time reference; (4) computing end-to-end latency for each delivered message. Pass criteria: 99th percentile end-to-end latency ≤500 ms; zero message loss for any registered consumer over a 24-hour sustained load test; output rate ≥1 Hz per registered consumer during nominal load. Rationale: SYS-012 makes two verifiable claims requiring instrumented measurement: (a) ≤500 ms end-to-end latency from track update to network delivery, and (b) zero message loss over 24 hours for registered consumers. | Test | |
| VER-REQ-090 | The CPDLC ACARS-to-SATCOM rerouting function (SUB-REQ-030) SHALL be verified by: (1) establishing active CPDLC sessions on 10 simulated aircraft via primary VHF ACARS; (2) withdrawing the ACARS uplink to simulate datalink failure; (3) measuring time from ACARS loss to successful CPDLC delivery via SATCOM for all 10 aircraft. Pass criteria: rerouting completes within 30 seconds for all sessions; no pending CPDLC messages lost; session continuity maintained without controller intervention. Rationale: SUB-REQ-030 requires ACARS→SATCOM failover within 30 seconds for active CPDLC sessions. Test verification is mandatory because the 30-second timing constraint is operationally critical — exceeding it could lose ATC separation assurance for aircraft on oceanic tracks — and must be demonstrated under live datalink gateway handshake conditions, not simulation. | Test | idempotency:VER-SUB030-CPDLC-SATCOM-FAILOVER-v1 |
| VER-REQ-091 | The training mode isolation (REQ-SEAIRTRAFFICCONTROL-083) SHALL be verified by: (1) inspecting the system architecture documentation to confirm no shared write-back bus between training and operational processing domains; (2) enabling training mode while live operations are active and confirming via packet capture on the operational network that no training-mode commands are transmitted; (3) verifying that synthetic traffic replayed in training mode does not appear on any live surveillance display or flight plan processor. Pass criterion: zero training-originated messages visible on the operational network during a 1-hour concurrent test run. Rationale: Training mode isolation cannot be fully verified by functional test alone — architecture inspection confirms the design intent, while network capture provides empirical evidence of separation. The 1-hour concurrent run mimics a realistic proficiency check duration. | Inspection | mode-coverage, training-mode, session-543, idempotency:ver-training-mode-session-543 |
flowchart TB n0["system<br>Air Traffic Control System"] n1["subsystem<br>Surveillance Data Processing"] n2["subsystem<br>Flight Data Processing"] n3["subsystem<br>Safety Net System"] n4["subsystem<br>Controller Working Position"] n5["system<br>Air Traffic Control System"] n6["subsystem<br>Surveillance Data Processing"] n7["subsystem<br>Flight Data Processing"] n8["subsystem<br>Safety Net System"] n9["subsystem<br>Controller Working Position"] n10["subsystem<br>Voice Communication System"] n11["subsystem<br>Data Distribution Network"] n12["subsystem<br>Aeronautical Information Management"] n13["subsystem<br>Approach Sequencing and Metering"] n14["subsystem<br>System Monitoring and Control"] n15["subsystem<br>Recording and Replay System"] n16["subsystem<br>Controller Pilot Data Link Communications"] n6 -->|Correlated tracks ASTERIX| n11 n11 -->|Track data| n7 n6 -->|Raw surveillance| n8 n7 -->|Flight plan data| n9 n8 -->|STCA/MSAW alerts| n9 n10 -->|Voice channels| n9 n12 -->|Sector boundaries| n7 n7 -->|Flight schedule| n13 n14 -.->|Health monitoring| n6 n11 -->|All data streams| n15 n16 -->|ACARS messages| n9
ATC System Decomposition
| Entity | Hex Code | Description |
|---|---|---|
| Aeronautical Information Management | 40B53B59 | Subsystem of an Air Traffic Control system maintaining the aeronautical database that underpins all route computation, airspace display, and safety net terrain models. Ingests AIXM data from national AIS providers, manages AIRAC cycle updates (28-day publication cycle), stores airspace boundaries, published procedures (SIDs/STARs), navigation aids, obstacle data, and terrain elevation models. Validates data integrity before activation. A corrupt airspace boundary or missing obstacle can directly cause a safety net false negative — data quality is safety-critical. |
| Aeronautical Information Management System | 40B57B58 | Subsystem of the Air Traffic Control System maintaining the authoritative aeronautical database used by all operational subsystems. Stores and distributes AIRAC-cycle navigation data including airways, waypoints, prohibited areas, sector boundaries, SIDs/STARs, and instrument approach procedures. Updates are ingested from national ANSP NOTAM feeds and applied on AIRAC publication dates (every 28 days). Provides query API to Flight Data Processing for procedure lookups and real-time NOTAM delivery to Controller Working Positions. |
| Air Traffic Control System | 51F57BD9 | An en-route and terminal area air traffic control system managing controlled airspace for civil aviation. Integrates primary and secondary surveillance radar, ADS-B, multilateration, and flight data processing to maintain safe separation of aircraft. Operates in a 24/7 high-availability environment with ESARR/EUROCAE safety targets (SIL 4 for separation assurance). Handles 2000+ simultaneous tracks, provides conflict detection and resolution advisories, manages sector capacity, and interfaces with adjacent ATC centres, airline operations, meteorological services, and aeronautical information systems. Regulatory framework: ICAO Annex 11, EUROCONTROL standards, national CAA oversight. |
| Alert Management Module | 41F77918 | Software module within the Safety Net System responsible for filtering, prioritising, and delivering conflict alerts to Controller Working Positions. Receives raw STCA and MSAW triggers from the Conflict Detection Processor, applies alert suppression logic to prevent duplicate or cascading false alerts, assigns urgency levels, and routes formatted alerts to the correct CWP sector display. Must suppress nuisance alerts below 3/sector/hour threshold while maintaining 10^-6 missed detection probability. |
| Approach Sequencing and Metering | 40B73B18 | Arrival Manager (AMAN) subsystem computing optimised landing sequences and speed profiles for arriving aircraft in the terminal manoeuvring area (TMA). Processes flight plan ETAs, runway throughput constraints, and wake turbulence separation to generate ordered sequence lists at typically 45-60nm from runway threshold. Interfaces with FDP and CWP. |
| ATC Data Distribution Network | 40A57018 | The internal communication backbone of the Air Traffic Control System that carries all inter-subsystem data traffic. Provides publish-subscribe messaging with differentiated Quality of Service for safety-critical messages (STCA alerts, track updates) versus operational messages (flight plan changes, configuration commands). Uses dual-redundant ring topology with automatic failover. Must achieve <10ms end-to-end latency for safety-critical messages and support 500 Mbps aggregate throughput across all subsystem connections. |
| ATC System Monitoring and Control Subsystem | 51B57318 | Central health monitoring and remote management subsystem of the Air Traffic Control System. Continuously monitors CPU load, memory utilisation, network latency, and availability of all subsystems. Provides alert escalation to the System Controller position for subsystem failures. Manages configuration versioning and controlled deployment of software updates with roll-back capability. Provides the interface for maintenance technicians to perform diagnostics without interrupting live operations. All monitoring is non-intrusive to safety-critical data paths. |
| Conflict Detection Processor | 51F73218 | Dedicated processing module within the Safety Net System that computes predicted minimum separation between all active track pairs using 5-minute lookahead trajectory projection. Receives fused track data at 4Hz from SDP, runs pairwise closest-point-of-approach algorithms using aircraft kinematic models, generates STCA alerts when predicted separation falls below 3 NM horizontal / 1000 ft vertical en-route. Runs on SIL 3 certified hardware, independent of operational processing. Must complete evaluation cycle for 2500 tracks within 500ms. |
| Controller Pilot Data Link Communications | 50E57B58 | CPDLC subsystem providing text-based data link communication between ATC and aircraft transponder-equipped aircraft above FL285. Transmits clearances, requests, and advisories over VHF digital link VDL Mode 2 or SATCOM. Reduces voice frequency congestion in high-density oceanic and upper airspace. Interfaces with ICAO FANS-1/A and ATN B1 protocols. |
| Controller Working Position | 50ED5218 | Subsystem of an Air Traffic Control system providing the human-machine interface for air traffic controllers. Comprises situation display (plan view, vertical view, timeline), electronic flight strip system, input devices (trackball, keyboard, touch), and alert presentation. Displays fused track data, flight labels, safety net alerts, weather overlay, and airspace boundaries. Supports sector configuration (split/merge), assumed/transferred flight ownership, and direct controller-pilot datalink (CPDLC). Must render full situation display at 60fps with <100ms input-to-display latency. |
| Data Distribution Network | 40A57018 | Subsystem of an Air Traffic Control system providing the communication backbone between all processing subsystems, controller positions, and external interfaces. Implements dual-redundant switched Ethernet with deterministic latency (IEEE 802.1Qbv time-sensitive networking). Carries surveillance tracks, flight data, voice streams, and system management traffic on segregated VLANs. Must achieve <1ms inter-subsystem latency, 99.9999% availability through path redundancy, and support 10Gbps aggregate throughput. Includes hardware security modules for data-in-transit encryption. |
| Flight Data Processing | 40B57B58 | Subsystem of an Air Traffic Control system managing the lifecycle of flight plans from filing through activation, correlation with surveillance tracks, and closure. Receives ICAO FPL messages via AFTN/AMHS, performs route validation against airspace structure and published procedures, computes 4D trajectory predictions, and distributes flight data to controller positions. Supports flight plan amendments, re-routing, and ATFM slot management. Interfaces with adjacent centres for coordination and handoff. Manages system flight plan store for 5000+ active plans. |
| Minimum Safe Altitude Warning Module | 50F77818 | Terrain and obstacle proximity warning module within the Safety Net System. Computes predicted aircraft-to-terrain clearance using 3D terrain elevation model and aircraft trajectory projection. Generates MSAW alert when predicted clearance falls below safe separation margins. Must independently verify altitude data from Mode C transponder against terrain database for each active track. Operates as SIL 3 function co-located with STCA on dedicated SNS processing hardware. |
| Multi-Sensor Fusion Engine | 51F73319 | Core processing component of the Surveillance Data Processing subsystem. Ingests raw sensor reports from PSR, SSR, ADS-B, and MLAT simultaneously using a Kalman-filter-based track fusion algorithm. Correlates returns from multiple sensors to the same aircraft, resolves conflicts between sensor sources using confidence weighting, and maintains a single consistent track picture. Must achieve <250m RMS accuracy en-route and <50m terminal at 4Hz output rate processing up to 2500 simultaneous tracks. |
| Recording and Replay System | 50853B59 | Subsystem of an Air Traffic Control system providing continuous recording of all surveillance data, voice communications, system events, and controller actions for post-incident investigation, legal compliance, and training. Records at full fidelity with cryptographic timestamping. Supports time-synchronised replay across all data streams with variable-speed playback. Must retain 30 days online, 5 years archived. Complies with EUROCONTROL recording standards and ICAO Annex 10 voice recording requirements. Recording integrity is legally mandated — any gap is a reportable incident. |
| Safety Net System | 51F77B59 | Subsystem of an Air Traffic Control system providing automated conflict detection and resolution advisories. Implements STCA (Short-Term Conflict Alert) predicting loss of separation 2 minutes ahead, MSAW (Minimum Safe Altitude Warning) checking terrain clearance, APW (Area Proximity Warning) detecting unauthorized airspace penetration, and CLAM (Cleared Level Adherence Monitor). Safety-critical SIL 4 function: false negative rate <10^-5 per flight hour, false positive rate <1 per controller hour. Must operate on predicted trajectories accounting for aircraft performance models and wind. |
| Surveillance Data Processing | 50F73319 | Subsystem of an Air Traffic Control system responsible for ingesting, correlating, and fusing surveillance data from primary surveillance radar (PSR), secondary surveillance radar (SSR/Mode-S), ADS-B receivers, and multilateration (MLAT) sensors. Produces a unified multi-sensor track picture at 4-second update rate for en-route and 1-second for terminal. Handles track initiation, smoothing, coast prediction, and duplicate elimination across overlapping sensor coverage. Must process 2000+ simultaneous tracks with <500ms processing latency. Critical safety function: track integrity directly determines separation assurance. |
| System Monitoring and Control | 51B77B18 | Subsystem of an Air Traffic Control system supervising the health, configuration, and failover of all other subsystems. Monitors hardware status, software process health, data quality metrics, and capacity thresholds. Manages automatic failover between redundant processing chains (hot standby). Provides system administrator interface for configuration changes, software updates, and maintenance scheduling. Implements SNMP and custom monitoring protocols. Must detect subsystem failure within 2 seconds and complete automatic switchover within 5 seconds. |
| Track Quality Monitor | 51F77308 | Monitoring component within Surveillance Data Processing that continuously assesses the quality and reliability of each tracked aircraft. Monitors sensor coverage gaps, transponder coasting (last known position extrapolation), track-to-track ambiguity, and velocity consistency. Flags tracks with degraded quality to the Controller Working Position via track quality indicators and generates NOTAM-equivalent alerts when coverage zones experience sensor loss. Operates at 4Hz track update rate for all active tracks. |
| Track-Plan Correlator | 40B53308 | Component of the Flight Data Processing subsystem that links each active surveillance track to its corresponding filed flight plan. Uses SSR squawk code, Mode C altitude, and trajectory correlation to associate tracks with flight plans. Maintains correlation state throughout the flight lifecycle, resolving correlation conflicts when multiple aircraft have similar transponder codes. Must achieve correlation within 30 seconds of airspace entry and maintain correlation through transponder changes and temporary coverage loss. |
| Voice Communication System | 54F57358 | Subsystem of an Air Traffic Control system providing air-ground radio and ground-ground telephony for controller operations. Manages VHF/UHF frequency allocation across sectors, supports frequency coupling for extended coverage, provides instant-access telephony between controller positions and adjacent centres. Implements ED-137 VoIP protocol for digital voice distribution. Must achieve voice latency <150ms, availability 99.999%, and support simultaneous transmission detection. Includes cockpit voice recording interface. |
| Component | Belongs To |
|---|---|
| Surveillance Data Processing | Air Traffic Control System |
| Flight Data Processing | Air Traffic Control System |
| Controller Working Position | Air Traffic Control System |
| Safety Net System | Air Traffic Control System |
| Voice Communication System | Air Traffic Control System |
| Recording and Replay System | Air Traffic Control System |
| System Monitoring and Control | Air Traffic Control System |
| Data Distribution Network | Air Traffic Control System |
| Aeronautical Information Management | Air Traffic Control System |
| Controller Pilot Data Link Communications | Air Traffic Control System |
| Approach Sequencing and Metering | Air Traffic Control System |
| Source | Target | Type | Description |
|---|---|---|---|
| SYS-REQ-003 | REQ-SEAIRTRAFFICCONTROL-012 | derives | SYS-REQ-003 availability derives ARC-REQ-012 AIM dual-database decision |
| SYS-REQ-006 | REQ-SEAIRTRAFFICCONTROL-011 | derives | SYS-REQ-006 network isolation derives ARC-REQ-011 VLAN segmentation decision |
| SYS-REQ-003 | REQ-SEAIRTRAFFICCONTROL-012 | derives | AIM dual-database architecture supports 99.9997% availability target by enabling safe AIRAC updates |
| SYS-REQ-006 | REQ-SEAIRTRAFFICCONTROL-011 | derives | DDN VLAN segmentation implements SYS-REQ-006 network isolation mandate |
| SYS-REQ-003 | REQ-SEAIRTRAFFICCONTROL-012 | derives | SYS-REQ-003 availability requirement drives the AIM dual-database architecture for non-disruptive AIRAC updates |
| SYS-REQ-006 | REQ-SEAIRTRAFFICCONTROL-011 | derives | SYS-REQ-006 network isolation requirement drives the DDN VLAN segmentation architecture decision |
| SYS-REQ-004 | ARC-REQ-002 | derives | SYS-REQ-004 safety net requirement drives the independent architecture and SIL 3 classification of the SNS |
| SYS-REQ-003 | ARC-REQ-001 | derives | SYS-REQ-003 availability requirement drives the dual-hot-standby processing architecture decision |
| REQ-SEAIRTRAFFICCONTROL-004 | REQ-SEAIRTRAFFICCONTROL-013 | derives | DDN latency requirement drives verification by injection test |
| SUB-REQ-006 | REQ-SEAIRTRAFFICCONTROL-014 | derives | CWP display performance drives camera-based verification method |
| SUB-REQ-014 | VER-REQ-015 | derives | SNS nuisance alert requirement drives 6-month operational trial verification |
| SUB-REQ-023 | VER-REQ-017 | derives | SDP degraded mode requirement drives failure injection test |
| SUB-REQ-022 | VER-REQ-018 | derives | Recording retention requirement drives 30-day integrity verification |
| SYS-REQ-007 | REQ-SEAIRTRAFFICCONTROL-075 | derives | SYS-REQ-007 backup endurance requirement derives to diesel generator endurance and fuel alarm SUB requirement |
| SYS-REQ-007 | REQ-SEAIRTRAFFICCONTROL-074 | derives | SYS-REQ-007 dual power source requirement derives to facility ATS switchover SUB requirement |
| SYS-REQ-011 | REQ-SEAIRTRAFFICCONTROL-008 | derives | System recording req derives RRS continuous recording |
| SYS-REQ-009 | SUB-REQ-008 | derives | Degraded-mode system req derives SDP processing failover |
| SYS-REQ-003 | SUB-REQ-005 | derives | System availability derives DDN switch survivability |
| SYS-REQ-004 | SUB-REQ-004 | derives | STCA system req drives SNS integrity requirement |
| SYS-REQ-004 | SUB-REQ-003 | derives | STCA system req derives SNS 120s look-ahead requirement |
| SYS-REQ-001 | SUB-REQ-002 | derives | System track accuracy derives SDP fused track accuracy |
| SYS-REQ-004 | SUB-REQ-036 | derives | FDP trajectory prediction accuracy derives from system conflict detection requirement |
| SYS-REQ-010 | SUB-REQ-035 | derives | FDP OLDI message processing derives from system OLDI interface requirement |
| SYS-REQ-008 | SUB-REQ-034 | derives | AMAN 40-minute horizon derives from system trajectory planning and conflict probe requirement |
| SYS-REQ-009 | SUB-REQ-030 | derives | CPDLC network failover derives from system degraded-mode continuity requirement |
| SYS-REQ-006 | SUB-REQ-028 | derives | CPDLC message authentication derives from system cybersecurity isolation requirement |
| SYS-REQ-011 | SUB-REQ-022 | derives | System recording mandate drives RRS 30-day retention with integrity |
| SYS-REQ-008 | SUB-REQ-025 | derives | System conflict probe requirement drives AMAN sequencing requirement |
| SYS-REQ-009 | SUB-REQ-023 | derives | System degraded service requirement drives SDP degraded-mode track continuity |
| SYS-REQ-004 | SUB-REQ-013 | derives | System conflict alert requirement drives MSAW terrain alert requirement |
| SYS-REQ-004 | SUB-REQ-012 | derives | System STCA requirement derives Safety Net STCA delivery requirement |
| SYS-REQ-001 | SUB-REQ-011 | derives | System track accuracy derives SDP multi-sensor fusion requirement |
| SYS-REQ-001 | REQ-SEAIRTRAFFICCONTROL-001 | derives | Track accuracy requires current aeronautical procedure database |
| SYS-REQ-003 | REQ-SEAIRTRAFFICCONTROL-005 | derives | System availability drives DDN failover recovery time |
| SYS-REQ-003 | REQ-SEAIRTRAFFICCONTROL-004 | derives | System availability drives DDN latency requirement |
| SYS-REQ-001 | SUB-REQ-005 | derives | Track accuracy drives FDP correlation timeliness requirement |
| SYS-REQ-002 | SUB-REQ-001 | derives | Track update rate requires multi-sensor sensor fusion capability |
| SYS-REQ-003 | SUB-REQ-008 | derives | System availability target derives SDP failover timing requirement |
| SYS-REQ-004 | SUB-REQ-004 | derives | System missed detection probability drives STCA reliability allocation |
| SYS-REQ-004 | SUB-REQ-003 | derives | System conflict alert requirement derives STCA geometry thresholds |
| SYS-REQ-001 | SUB-REQ-002 | derives | Track accuracy system req derives SDP accuracy subsystem req |
| SYS-REQ-003 | SUB-REQ-008 | derives | System availability target derives SDP failover timing requirement |
| SYS-REQ-004 | SUB-REQ-004 | derives | System missed detection probability drives STCA reliability allocation |
| SYS-REQ-004 | SUB-REQ-003 | derives | System conflict alert requirement derives STCA geometry thresholds |
| SYS-REQ-001 | SUB-REQ-002 | derives | Track accuracy system req derives SDP accuracy subsystem req |
| SYS-REQ-011 | IFC-REQ-015 | derives | RRS-to-DDN recording interface derives from 30-day recording retention requirement |
| SYS-REQ-003 | IFC-REQ-014 | derives | SMC-to-subsystem SNMP v3 monitoring interface derives from 99.9997% availability requirement |
| SYS-REQ-009 | IFC-REQ-013 | derives | VCS-to-CWP voice selection interface derives from degraded-mode continuity requirement |
| SYS-REQ-005 | IFC-REQ-012 | derives | FDP-to-CWP flight strip interface derives from 5000 active flight plan capacity requirement |
| SYS-REQ-001 | IFC-REQ-011 | derives | AIM-to-SDP sector boundary data feed derives from track accuracy requirement |
| SYS-REQ-004 | REQ-SEAIRTRAFFICCONTROL-010 | derives | SNS-CWP 500ms alert budget derived from SYS-REQ-004 120-second conflict resolution window |
| SYS-REQ-004 | REQ-SEAIRTRAFFICCONTROL-010 | derives | Conflict detection drives SNS-to-CWP interface latency requirement |
| SYS-REQ-005 | IFC-REQ-003 | derives | System processing capacity drives OLDI interface coordination bandwidth |
| SYS-REQ-002 | IFC-REQ-002 | derives | Track update rate drives ASTERIX interface message rate requirement |
| SYS-REQ-005 | IFC-REQ-001 | derives | System track count capacity drives SDP-to-SNS interface bandwidth |
| REQ-SEAIRTRAFFICCONTROL-082 | REQ-SEAIRTRAFFICCONTROL-083 | derives | STK training mode → SYS architecture-level training mode isolation |
| STK-REQ-008 | SYS-REQ-013 | derives | STK-008 maintenance LRU requirement derives SYS-013 maintenance interface and restoration time bound |
| STK-REQ-009 | SYS-012 | derives | STK-REQ-009 ASTERIX Cat 062 ≤500ms latency requirement derives the system-level ASTERIX output specification SYS-012 |
| STK-REQ-008 | SYS-REQ-009 | derives | STK-REQ-008 LRU replacement MTTR constraint derives the 15-minute service restoration requirement in SYS-REQ-009 |
| STK-REQ-007 | SYS-REQ-011 | derives | Audit log requirement drives recording requirement |
| STK-REQ-006 | SYS-REQ-005 | derives | Sector capacity drives 400-aircraft processing requirement |
| STK-REQ-005 | SYS-REQ-010 | derives | Coordination drives CFMU NMOC interface requirement |
| STK-REQ-004 | SYS-REQ-002 | derives | Display clarity drives surveillance update rate |
| STK-REQ-003 | SYS-REQ-006 | derives | SIL requirement drives network isolation |
| STK-REQ-002 | SYS-REQ-003 | derives | 24/7 availability drives 99.9997% availability requirement |
| STK-REQ-001 | SYS-REQ-004 | derives | Safety separation drives STCA detection requirement |
| STK-REQ-001 | SYS-REQ-001 | derives | Safety separation drives track accuracy requirement |
| STK-REQ-007 | SYS-REQ-011 | derives | CAA audit access requirement drives system recording mandate |
| STK-REQ-003 | SYS-REQ-003 | derives | Safety integrity level need drives system availability requirement |
| STK-REQ-001 | SYS-REQ-004 | derives | Controller separation need drives system STCA requirement |
| STK-REQ-005 | SYS-REQ-010 | derives | Automated coordination need drives CFMU B2B interface requirement |
| STK-REQ-002 | SYS-REQ-009 | derives | 24/7 availability need derives degraded service requirement |
| STK-REQ-006 | SYS-REQ-008 | derives | ANSP capacity need derives system conflict probe requirement |
| STK-REQ-002 | SYS-REQ-003 | derives | Continuous availability drives 99.9997% system availability target |
| STK-REQ-001 | SYS-REQ-004 | derives | Separation assurance drives automated conflict detection |
| STK-REQ-001 | SYS-REQ-001 | derives | Separation assurance drives track accuracy requirement |
| STK-REQ-002 | SYS-REQ-007 | derives | 24/7 availability need drives redundant power supply requirement |
| STK-REQ-003 | SYS-REQ-006 | derives | Safety integrity target drives network isolation requirement |
| STK-REQ-004 | SYS-REQ-005 | derives | Controller workload and sector capacity need drives system processing capacity |
| STK-REQ-003 | SYS-REQ-004 | derives | ESARR 4 safety target drives conflict alert missed detection probability |
| STK-REQ-001 | SYS-REQ-004 | derives | Separation assurance need drives conflict alert timing and reliability |
| STK-REQ-002 | SYS-REQ-003 | derives | 24/7 continuity need drives 99.9997% availability target |
| STK-REQ-001 | SYS-REQ-002 | derives | Separation assurance need drives track update rate requirement |
| STK-REQ-001 | SYS-REQ-001 | derives | Separation assurance need drives track position accuracy requirement |
| Requirement | Verified By | Type | Description |
|---|---|---|---|
| REQ-SEAIRTRAFFICCONTROL-084 | REQ-SEAIRTRAFFICCONTROL-083 | verifies | VER training mode isolation test → SYS training mode req |
| VER-REQ-089 | SYS-012 | verifies | VER-REQ-089 end-to-end ASTERIX Cat 062 latency and zero-loss test verifies SYS-012 latency bound and delivery reliability |
| VER-REQ-088 | SYS-REQ-013 | verifies | VER-088 maintenance LRU hot-swap test verifies SYS-013 restoration time and no-interruption requirements |
| REQ-SEAIRTRAFFICCONTROL-059 | REQ-SEAIRTRAFFICCONTROL-010 | verifies | VER-REQ-066 tests the SNS→CWP STCA alert delivery interface (IFC-REQ-010) |
| REQ-SEAIRTRAFFICCONTROL-064 | IFC-REQ-015 | verifies | Verification test for IFC-REQ-015 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-063 | IFC-REQ-014 | verifies | Verification test for IFC-REQ-014 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-062 | IFC-REQ-013 | verifies | Verification test for IFC-REQ-013 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-061 | IFC-REQ-012 | verifies | Verification test for IFC-REQ-012 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-060 | IFC-REQ-011 | verifies | Verification test for IFC-REQ-011 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-058 | IFC-REQ-003 | verifies | Verification test for IFC-REQ-003 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-057 | IFC-REQ-002 | verifies | Verification test for IFC-REQ-002 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-056 | IFC-REQ-001 | verifies | Verification test for IFC-REQ-001 interface requirement |
| REQ-SEAIRTRAFFICCONTROL-080 | REQ-SEAIRTRAFFICCONTROL-010 | verifies | STCA/MSAW latency and saturation test verifies SNS-CWP alert channel performance |
| REQ-SEAIRTRAFFICCONTROL-069 | REQ-SEAIRTRAFFICCONTROL-012 | verifies | Verification test for architecture decision |
| REQ-SEAIRTRAFFICCONTROL-068 | REQ-SEAIRTRAFFICCONTROL-011 | verifies | Verification test for architecture decision |
| REQ-SEAIRTRAFFICCONTROL-067 | ARC-REQ-002 | verifies | Verification test for architecture decision ARC-REQ-002 |
| REQ-SEAIRTRAFFICCONTROL-066 | ARC-REQ-001 | verifies | Verification test for architecture decision ARC-REQ-001 |
| REQ-SEAIRTRAFFICCONTROL-079 | REQ-SEAIRTRAFFICCONTROL-012 | verifies | Staging corruption and rollback test verifies AIM dual-database isolation architecture |
| REQ-SEAIRTRAFFICCONTROL-078 | REQ-SEAIRTRAFFICCONTROL-011 | verifies | VLAN injection and saturation test verifies DDN isolation architecture |
| REQ-SEAIRTRAFFICCONTROL-069 | REQ-SEAIRTRAFFICCONTROL-012 | verifies | AIM dual-database AIRAC switchover and reversion test verifies the ARC-REQ-012 architecture decision |
| REQ-SEAIRTRAFFICCONTROL-068 | REQ-SEAIRTRAFFICCONTROL-011 | verifies | DDN VLAN segmentation and isolation test verifies the ARC-REQ-011 network architecture decision |
| REQ-SEAIRTRAFFICCONTROL-067 | ARC-REQ-002 | verifies | SNS independence test verifies the ARC-REQ-002 architectural independence design decision |
| REQ-SEAIRTRAFFICCONTROL-066 | ARC-REQ-001 | verifies | Dual-hot-standby failover test directly verifies the ARC-REQ-001 architecture decision |
| REQ-SEAIRTRAFFICCONTROL-046 | SUB-REQ-027 | verifies | Verification test for SUB-REQ-027 |
| REQ-SEAIRTRAFFICCONTROL-027 | SUB-REQ-008 | verifies | VER-REQ-034 tests SDP failover timing (SUB-REQ-008 SDP) |
| REQ-SEAIRTRAFFICCONTROL-025 | SUB-REQ-007 | verifies | VER-REQ-032 tests VCS simultaneous independent channel capability (SUB-REQ-007 VCS) |
| REQ-SEAIRTRAFFICCONTROL-024 | REQ-SEAIRTRAFFICCONTROL-006 | verifies | VER-REQ-031 tests SMC health deviation detection (SUB-REQ-006 SMC) |
| REQ-SEAIRTRAFFICCONTROL-020 | SUB-REQ-005 | verifies | VER-REQ-027 tests FDP flight plan lifecycle management (SUB-REQ-005 FDP) |
| VER-REQ-002 | SUB-REQ-004 | verifies | VER-REQ-002 tests SNS STCA missed detection probability (SUB-REQ-004 SNS) |
| VER-REQ-001 | REQ-SEAIRTRAFFICCONTROL-002 | verifies | VER-REQ-001 tests AIM navigation data query latency (SUB-REQ-002 AIM) |
| REQ-SEAIRTRAFFICCONTROL-018 | SUB-REQ-001 | verifies | VER-REQ-025 tests SDP multi-sensor ingestion (SUB-REQ-001 SDP) |
| REQ-SEAIRTRAFFICCONTROL-016 | SUB-REQ-003 | verifies | VER-REQ-023 tests SNS conflict prediction function (SUB-REQ-003 SNS) |
| REQ-SEAIRTRAFFICCONTROL-022 | REQ-SEAIRTRAFFICCONTROL-003 | verifies | VER-REQ-029 tests AIM NOTAM propagation (SUB-REQ-003 AIM) |
| VER-REQ-090 | SUB-REQ-030 | verifies | VER-REQ-090 tests CPDLC ACARS-to-SATCOM failover (SUB-REQ-030) |
| REQ-SEAIRTRAFFICCONTROL-077 | REQ-SEAIRTRAFFICCONTROL-075 | verifies | VER-REQ-083 tests diesel generator 72-hour endurance (SUB-REQ-040) |
| REQ-SEAIRTRAFFICCONTROL-076 | REQ-SEAIRTRAFFICCONTROL-074 | verifies | VER-REQ-082 tests power supply ATS switchover (SUB-REQ-039) |
| REQ-SEAIRTRAFFICCONTROL-055 | SUB-REQ-038 | verifies | VER-REQ-062 tests VCS conferencing latency (SUB-REQ-038) |
| REQ-SEAIRTRAFFICCONTROL-054 | SUB-REQ-037 | verifies | VER-REQ-061 tests CWP electronic flight strip (SUB-REQ-037) |
| VER-REQ-021 | SUB-REQ-036 | verifies | VER-REQ-021 tests FDP trajectory prediction accuracy (SUB-REQ-036) |
| REQ-SEAIRTRAFFICCONTROL-052 | SUB-REQ-035 | verifies | VER-REQ-059 tests FDP OLDI coordination processing (SUB-REQ-035) |
| VER-REQ-020 | SUB-REQ-034 | verifies | VER-REQ-020 tests AMAN 40-minute planning horizon (SUB-REQ-034) |
| REQ-SEAIRTRAFFICCONTROL-050 | SUB-REQ-033 | verifies | VER-REQ-057 tests AMAN multi-runway configuration (SUB-REQ-033) |
| REQ-SEAIRTRAFFICCONTROL-032 | SUB-REQ-032 | verifies | VER-REQ-039 tests AMAN sequence recomputation latency (SUB-REQ-032) |
| REQ-SEAIRTRAFFICCONTROL-048 | SUB-REQ-031 | verifies | VER-REQ-055 tests CPDLC message logging (SUB-REQ-031) |
| REQ-SEAIRTRAFFICCONTROL-031 | SUB-REQ-029 | verifies | VER-REQ-038 tests CPDLC ACARS failover (SUB-REQ-029) |
| VER-REQ-019 | SUB-REQ-028 | verifies | VER-REQ-019 tests CPDLC authentication mechanism (SUB-REQ-028) |
| REQ-SEAIRTRAFFICCONTROL-046 | SUB-REQ-027 | verifies | VER-REQ-053 tests CPDLC message authentication (SUB-REQ-027) |
| REQ-SEAIRTRAFFICCONTROL-045 | SUB-REQ-026 | verifies | VER-REQ-052 tests AMAN landing sequence computation (SUB-REQ-026) |
| REQ-SEAIRTRAFFICCONTROL-021 | SUB-REQ-025 | verifies | VER-REQ-028 tests CPDLC message delivery latency (SUB-REQ-025) |
| REQ-SEAIRTRAFFICCONTROL-044 | SUB-REQ-024 | verifies | VER-REQ-051 tests CWP sector ownership display (SUB-REQ-024) |
| REQ-SEAIRTRAFFICCONTROL-043 | SUB-REQ-022 | verifies | VER-REQ-050 tests RRS 30-day retention with integrity protection (SUB-REQ-022) |
| REQ-SEAIRTRAFFICCONTROL-042 | SUB-REQ-021 | verifies | VER-REQ-049 tests SMC real-time health dashboard (SUB-REQ-021) |
| REQ-SEAIRTRAFFICCONTROL-030 | SUB-REQ-020 | verifies | VER-REQ-037 tests DDN QoS priority queuing (SUB-REQ-020) |
| REQ-SEAIRTRAFFICCONTROL-040 | SUB-REQ-019 | verifies | VER-REQ-047 tests AIM terrain/obstacle database coverage (SUB-REQ-019) |
| REQ-SEAIRTRAFFICCONTROL-029 | SUB-REQ-018 | verifies | VER-REQ-036 tests AIM AIRAC cycle update timing (SUB-REQ-018) |
| REQ-SEAIRTRAFFICCONTROL-038 | SUB-REQ-017 | verifies | VER-REQ-045 tests VCS guard frequency independence (SUB-REQ-017) |
| REQ-SEAIRTRAFFICCONTROL-037 | SUB-REQ-016 | verifies | VER-REQ-044 tests CWP clearance input efficiency (SUB-REQ-016) |
| REQ-SEAIRTRAFFICCONTROL-036 | SUB-REQ-015 | verifies | VER-REQ-043 tests FDP clearance distribution latency (SUB-REQ-015) |
| REQ-SEAIRTRAFFICCONTROL-017 | SUB-REQ-013 | verifies | VER-REQ-024 tests SNS MSAW function (SUB-REQ-013) |
| REQ-SEAIRTRAFFICCONTROL-028 | SUB-REQ-012 | verifies | VER-REQ-035 tests SNS STCA alert timing (SUB-REQ-012) |
| REQ-SEAIRTRAFFICCONTROL-034 | SUB-REQ-011 | verifies | VER-REQ-041 tests SDP multi-sensor fusion (SUB-REQ-011) |
| REQ-SEAIRTRAFFICCONTROL-019 | SUB-REQ-010 | verifies | VER-REQ-026 tests SDP track identity assignment (SUB-REQ-010) |
| REQ-SEAIRTRAFFICCONTROL-026 | REQ-SEAIRTRAFFICCONTROL-009 | verifies | VER-REQ-033 tests RRS simultaneous replay (SUB-REQ-009) |
| REQ-SEAIRTRAFFICCONTROL-081 | REQ-SEAIRTRAFFICCONTROL-009 | verifies | Multi-stream synchronisation and EUROCONTROL export test verifies RRS simultaneous replay requirement |
| VER-REQ-081 | REQ-SEAIRTRAFFICCONTROL-001 | verifies | AIRAC injection test and AIXM schema check verifies AIM database completeness requirement |
| REQ-SEAIRTRAFFICCONTROL-023 | REQ-SEAIRTRAFFICCONTROL-005 | verifies | DDN switch removal test verifies the 50ms automatic re-routing failover requirement |
| REQ-SEAIRTRAFFICCONTROL-013 | REQ-SEAIRTRAFFICCONTROL-004 | verifies | DDN latency injection test verifies the 10ms 99th-percentile latency requirement |
| REQ-SEAIRTRAFFICCONTROL-077 | REQ-SEAIRTRAFFICCONTROL-075 | verifies | Diesel generator endurance and fuel alarm test verifies power supply endurance SUB requirement |
| REQ-SEAIRTRAFFICCONTROL-076 | REQ-SEAIRTRAFFICCONTROL-074 | verifies | Power supply ATS switchover test verifies facility power infrastructure SUB requirement |
| REQ-SEAIRTRAFFICCONTROL-031 | SUB-REQ-030 | verifies | CPDLC ACARS failover test also verifies SATCOM rerouting behaviour in SUB-REQ-030 |
| REQ-SEAIRTRAFFICCONTROL-073 | SUB-REQ-006 | verifies | CWP frame-capture display refresh test verifies 4Hz minimum track symbol update requirement |
| REQ-SEAIRTRAFFICCONTROL-072 | REQ-SEAIRTRAFFICCONTROL-007 | verifies | SMC config access and audit log test verifies configuration management security requirement |
| REQ-SEAIRTRAFFICCONTROL-071 | REQ-SEAIRTRAFFICCONTROL-002 | verifies | AIM nav data query latency test verifies AIM sub-100ms query response requirement |
| REQ-SEAIRTRAFFICCONTROL-024 | REQ-SEAIRTRAFFICCONTROL-006 | verifies | SMC health deviation test additionally verifies SMC breach detection requirement |
| REQ-SEAIRTRAFFICCONTROL-070 | REQ-SEAIRTRAFFICCONTROL-009 | verifies | Multi-stream replay test at variable playback rates verifies RRS replay capability |
| REQ-SEAIRTRAFFICCONTROL-069 | SUB-REQ-001 | verifies | AIRAC switchover and reversion demonstration verifies AIM database continuity via ARC-REQ-012 architectural mechanism |
| VER-REQ-016 | SUB-REQ-017 | verifies | Inspection of circuit diagrams and live test verifies VCS guard frequency monitoring independence |
| REQ-SEAIRTRAFFICCONTROL-047 | SUB-REQ-030 | verifies | Verification test for CPDLC ACARS failover (SUB-REQ-030) |
| REQ-SEAIRTRAFFICCONTROL-046 | SUB-REQ-028 | verifies | Verification test for CPDLC authentication (SUB-REQ-028) |
| REQ-SEAIRTRAFFICCONTROL-028 | SUB-REQ-012 | verifies | Verification test for SUB-REQ-012 |
| REQ-SEAIRTRAFFICCONTROL-029 | SUB-REQ-018 | verifies | Verification test for SUB-REQ-018 |
| REQ-SEAIRTRAFFICCONTROL-027 | SUB-REQ-008 | verifies | Verification test for SUB-REQ-008 |
| REQ-SEAIRTRAFFICCONTROL-032 | SUB-REQ-032 | verifies | Verification test for SUB-REQ-032 |
| REQ-SEAIRTRAFFICCONTROL-031 | SUB-REQ-029 | verifies | Verification test for SUB-REQ-029 |
| REQ-SEAIRTRAFFICCONTROL-030 | SUB-REQ-020 | verifies | Verification test for SUB-REQ-020 |
| REQ-SEAIRTRAFFICCONTROL-048 | SUB-REQ-031 | verifies | Verification test for SUB-REQ-031 |
| REQ-SEAIRTRAFFICCONTROL-049 | SUB-REQ-032 | verifies | Verification test for SUB-REQ-032 |
| SUB-REQ-002 | VER-REQ-001 | verifies | SDP accuracy requirement verified by radar replay test |
| SUB-REQ-004 | VER-REQ-002 | verifies | Safety net reliability requirement verified by FTA analysis |
| SUB-REQ-028 | VER-REQ-019 | verifies | CPDLC authentication requirement verified by cryptographic injection test |
| SUB-REQ-034 | VER-REQ-020 | verifies | AMAN planning horizon verified by 40-flight scenario test |
| SUB-REQ-036 | VER-REQ-021 | verifies | FDP trajectory prediction verified by 4-hour replay analysis |
| REQ-SEAIRTRAFFICCONTROL-016 | SUB-REQ-003 | verifies | VER covers SNS 120s conflict prediction verification |
| REQ-SEAIRTRAFFICCONTROL-017 | SUB-REQ-013 | verifies | VER covers MSAW terrain warning verification |
| REQ-SEAIRTRAFFICCONTROL-018 | SUB-REQ-001 | verifies | VER covers SDP multi-sensor ingestion capability |
| REQ-SEAIRTRAFFICCONTROL-019 | SUB-REQ-010 | verifies | VER covers SDP track identity assignment |
| REQ-SEAIRTRAFFICCONTROL-020 | SUB-REQ-005 | verifies | VER covers FDP flight plan lifecycle management |
| REQ-SEAIRTRAFFICCONTROL-021 | SUB-REQ-025 | verifies | VER covers CPDLC message delivery latency |
| REQ-SEAIRTRAFFICCONTROL-022 | REQ-SEAIRTRAFFICCONTROL-003 | verifies | VER covers AIM NOTAM propagation verification |
| REQ-SEAIRTRAFFICCONTROL-023 | SUB-REQ-005 | verifies | VER covers DDN switch failure survivability test |
| REQ-SEAIRTRAFFICCONTROL-024 | SUB-REQ-006 | verifies | VER covers SMC health deviation detection latency |
| REQ-SEAIRTRAFFICCONTROL-025 | SUB-REQ-007 | verifies | VER covers VCS channel independence |
| VER-REQ-001 | SUB-REQ-002 | verifies | VER-001 verifies SDP track position accuracy |
| VER-REQ-002 | SUB-REQ-004 | verifies | VER-002 verifies SNS missed detection probability |
| VER-REQ-015 | SUB-REQ-014 | verifies | VER-015 verifies SNS STCA nuisance alert rate |
| VER-REQ-017 | SUB-REQ-023 | verifies | VER-017 verifies SDP degraded mode track continuity |
| REQ-SEAIRTRAFFICCONTROL-026 | REQ-SEAIRTRAFFICCONTROL-009 | verifies | VER covers RRS simultaneous replay capability |
| VER-REQ-018 | REQ-SEAIRTRAFFICCONTROL-008 | verifies | VER-018 verifies RRS data retention and integrity |
| REQ-SEAIRTRAFFICCONTROL-033 | SUB-REQ-008 | verifies | SDP failover test |
| REQ-SEAIRTRAFFICCONTROL-034 | SUB-REQ-011 | verifies | Verification test for SUB-REQ-011 |
| REQ-SEAIRTRAFFICCONTROL-035 | SUB-REQ-012 | verifies | Verification test for SUB-REQ-012 |
| REQ-SEAIRTRAFFICCONTROL-036 | SUB-REQ-015 | verifies | Verification test for SUB-REQ-015 |
| REQ-SEAIRTRAFFICCONTROL-037 | SUB-REQ-016 | verifies | Verification test for SUB-REQ-016 |
| REQ-SEAIRTRAFFICCONTROL-038 | SUB-REQ-017 | verifies | Verification test for SUB-REQ-017 |
| REQ-SEAIRTRAFFICCONTROL-039 | SUB-REQ-018 | verifies | Verification test for SUB-REQ-018 |
| REQ-SEAIRTRAFFICCONTROL-054 | SUB-REQ-037 | verifies | Verification test for SUB-REQ-037 |
| REQ-SEAIRTRAFFICCONTROL-055 | SUB-REQ-038 | verifies | Verification test for SUB-REQ-038 |
| REQ-SEAIRTRAFFICCONTROL-052 | SUB-REQ-035 | verifies | Verification test for SUB-REQ-035 |
| REQ-SEAIRTRAFFICCONTROL-053 | SUB-REQ-036 | verifies | Verification test for SUB-REQ-036 |
| REQ-SEAIRTRAFFICCONTROL-050 | SUB-REQ-033 | verifies | Verification test for SUB-REQ-033 |
| REQ-SEAIRTRAFFICCONTROL-051 | SUB-REQ-034 | verifies | Verification test for SUB-REQ-034 |
| REQ-SEAIRTRAFFICCONTROL-041 | SUB-REQ-020 | verifies | Verification test for SUB-REQ-020 |
| REQ-SEAIRTRAFFICCONTROL-040 | SUB-REQ-019 | verifies | Verification test for SUB-REQ-019 |
| REQ-SEAIRTRAFFICCONTROL-043 | SUB-REQ-022 | verifies | Verification test for SUB-REQ-022 |
| REQ-SEAIRTRAFFICCONTROL-042 | SUB-REQ-021 | verifies | Verification test for SUB-REQ-021 |
| REQ-SEAIRTRAFFICCONTROL-045 | SUB-REQ-026 | verifies | Verification test for SUB-REQ-026 |
| REQ-SEAIRTRAFFICCONTROL-044 | SUB-REQ-024 | verifies | Verification test for SUB-REQ-024 |
| REQ-SEAIRTRAFFICCONTROL-047 | SUB-REQ-029 | verifies | Verification test for SUB-REQ-029 |
| REQ-SEAIRTRAFFICCONTROL-065 | REQ-SEAIRTRAFFICCONTROL-010 | verifies | Load test of SNS→CWP alert delivery under DDN congestion verifies IFC-REQ-010 500ms latency requirement |
| REQ-SEAIRTRAFFICCONTROL-064 | IFC-REQ-015 | verifies | Verification test for IFC-REQ-015 |
| REQ-SEAIRTRAFFICCONTROL-060 | IFC-REQ-011 | verifies | Verification test for IFC-REQ-011 |
| REQ-SEAIRTRAFFICCONTROL-061 | IFC-REQ-012 | verifies | Verification test for IFC-REQ-012 |
| REQ-SEAIRTRAFFICCONTROL-062 | IFC-REQ-013 | verifies | Verification test for IFC-REQ-013 |
| REQ-SEAIRTRAFFICCONTROL-063 | IFC-REQ-014 | verifies | Verification test for IFC-REQ-014 |
| REQ-SEAIRTRAFFICCONTROL-057 | IFC-REQ-002 | verifies | Verification test for IFC-REQ-002 |
| REQ-SEAIRTRAFFICCONTROL-056 | IFC-REQ-001 | verifies | Verification test for IFC-REQ-001 |
| REQ-SEAIRTRAFFICCONTROL-059 | REQ-SEAIRTRAFFICCONTROL-010 | verifies | Verification test for REQ-SEAIRTRAFFICCONTROL-010 |
| REQ-SEAIRTRAFFICCONTROL-058 | IFC-REQ-003 | verifies | Verification test for IFC-REQ-003 |
| REQ-SEAIRTRAFFICCONTROL-068 | SYS-REQ-006 | verifies | VLAN inspection and flood test verifies network isolation architecture supporting SYS-REQ-006 |
| REQ-SEAIRTRAFFICCONTROL-067 | SYS-REQ-004 | verifies | SIL 3 assessment of SNS architectural independence verifies safety net architecture supporting SYS-REQ-004 |
| REQ-SEAIRTRAFFICCONTROL-066 | SYS-REQ-003 | verifies | Live dual-hot-standby failover test verifies availability through architectural mechanism specified in ARC-REQ-001 |
| VER-021 | SYS-012 | verifies | Load test of ASTERIX Cat 062 latency at full track density verifies SYS-012 output latency requirement |
| VER-020 | SYS-REQ-011 | verifies | Recording completeness, tamper-attempt, and regulatory retrieval test verifies audit capability |
| VER-019 | SYS-REQ-010 | verifies | CFMU acceptance environment interoperability test verifies OLDI B2B interface compliance |
| VER-018 | SYS-REQ-009 | verifies | Per-subsystem failure injection test verifies degraded mode continuity and 15-minute recovery time |
| VER-017 | SYS-REQ-008 | verifies | Geometric injection test at boundary values verifies conflict probe 20-minute advance warning |
| VER-016 | SYS-REQ-007 | verifies | Live mains failure switchover test and 72-hour generator endurance run verifies power supply requirements |
| VER-015 | SYS-REQ-006 | verifies | Independent penetration test verifies network isolation between ATC operational network and external feeds |
| VER-014 | SYS-REQ-005 | verifies | Full-load capacity test at 2500 tracks and 5000 flight plans verifies system throughput requirement |
| VER-013 | SYS-REQ-004 | verifies | 1000-scenario replay test verifies STCA 120s advance warning and missed detection probability |
| VER-012 | SYS-REQ-002 | verifies | Full-system update rate load test verifies end-to-end track refresh latency |
| VER-011 | SYS-REQ-001 | verifies | System-level ADS-B reference transponder test verifies end-to-end fused track accuracy |
| VER-REQ-003 | SYS-REQ-003 | verifies | VER-003 verifies system availability |
| SYS-REQ-003 | VER-REQ-003 | verifies | System availability requirement verified by 12-month operational monitoring |
| Ref | Document | Requirement |
|---|---|---|
| IFC-REQ-010 | interface-requirements | The interface between the Safety Net System and the Controller Working Position SHALL deliver STCA and MSAW alerts to th... |
| STK-REQ-010 | stakeholder-requirements | The Air Traffic Control System SHALL provide an isolated controller training mode that replicates the live operational i... |
| SUB-REQ-009 | subsystem-requirements | The Recording and Replay System SHALL support simultaneous replay of all recorded data streams at selectable playback ra... |
| SUB-REQ-039 | subsystem-requirements | The facility power supply system SHALL provide two independent AC power feeds to all ATC subsystems: mains grid feed and... |
| SUB-REQ-040 | subsystem-requirements | The facility power supply system SHALL sustain all ATC subsystems at full operational load on diesel generator power alo... |
| SYS-REQ-014 | system-requirements | The Air Traffic Control System SHALL implement a training mode subsystem that is logically isolated from the operational... |
| VER-REQ-013 | verification-plan | The Data Distribution Network end-to-end safety-critical message latency (SUB-REQ for DDN) SHALL be verified by injectin... |
| VER-REQ-014 | verification-plan | The Controller Working Position display refresh rate and track symbol update latency (SUB-REQ-006) SHALL be verified by ... |
| VER-REQ-023 | verification-plan | The Safety Net System conflict prediction function (SUB-REQ-003) SHALL be verified by injecting 500 synthetic conflict s... |
| VER-REQ-024 | verification-plan | The Minimum Safe Altitude Warning function (SUB-REQ-013) SHALL be verified by replaying 100 CFIT-precursor track profile... |
| VER-REQ-025 | verification-plan | The Surveillance Data Processing multi-sensor ingestion capability (SUB-REQ-001) SHALL be verified by a system integrati... |
| VER-REQ-026 | verification-plan | The Surveillance Data Processing track identity assignment (SUB-REQ-010) SHALL be verified by injecting a 200-aircraft s... |
| VER-REQ-027 | verification-plan | The Flight Data Processing flight plan lifecycle management (SUB-REQ-005) SHALL be verified by executing a 4-hour traffi... |
| VER-REQ-028 | verification-plan | The CPDLC message delivery latency and confirmation (SUB-REQ-025) SHALL be verified by injecting 1000 CPDLC uplink messa... |
| VER-REQ-029 | verification-plan | The Aeronautical Information Management NOTAM propagation (SUB-REQ-003) SHALL be verified by injecting 50 NOTAMs of diff... |
| VER-REQ-030 | verification-plan | The Data Distribution Network single-switch failure survivability (SUB-REQ-005) SHALL be verified by a controlled test r... |
| VER-REQ-031 | verification-plan | The System Monitoring and Control health deviation detection (SUB-REQ-006) SHALL be verified by injecting simulated subs... |
| VER-REQ-032 | verification-plan | The Voice Communication System simultaneous independent channel capability (SUB-REQ-007) SHALL be verified by configurin... |
| VER-REQ-033 | verification-plan | The Recording and Replay System simultaneous replay capability (SUB-REQ-009) SHALL be verified by initiating playback of... |
| VER-REQ-034 | verification-plan | The SDP failover timing (SUB-REQ-008) SHALL be verified by: (1) disconnecting the primary processing node power while ru... |
| VER-REQ-035 | verification-plan | The SNS STCA alert timing (SUB-REQ-012) SHALL be verified by: (1) injecting 100 simulated separation-violating track pai... |
| VER-REQ-036 | verification-plan | The AIM AIRAC cycle update timing (SUB-REQ-018) SHALL be verified by: (1) injecting a complete AIRAC cycle data package ... |
| VER-REQ-037 | verification-plan | The DDN QoS priority queuing (SUB-REQ-020) SHALL be verified by: (1) generating synthetic congestion load at 95% link ut... |
| VER-REQ-038 | verification-plan | The CPDLC ACARS failover (SUB-REQ-029) SHALL be verified by: (1) establishing active CPDLC sessions on 5 aircraft over V... |
| VER-REQ-039 | verification-plan | The AMAN sequence recomputation latency (SUB-REQ-032) SHALL be verified by: (1) loading a 20-aircraft inbound scenario; ... |
| VER-REQ-041 | verification-plan | The SDP multi-sensor fusion (SUB-REQ-011) SHALL be verified by: (1) simultaneously injecting simulated ADS-B, SSR, PSR, ... |
| VER-REQ-043 | verification-plan | The FDP clearance distribution latency (SUB-REQ-015) SHALL be verified by: (1) entering 50 sequential clearance inputs a... |
| VER-REQ-044 | verification-plan | The CWP clearance input efficiency (SUB-REQ-016) SHALL be verified by: (1) having 3 qualified ATC controllers attempt 50... |
| VER-REQ-045 | verification-plan | The VCS guard frequency independence (SUB-REQ-017) SHALL be verified by: (1) powering down the primary voice switching s... |
| VER-REQ-047 | verification-plan | The AIM terrain and obstacle database coverage (SUB-REQ-019) SHALL be verified by: (1) sampling 100 randomised geographi... |
| VER-REQ-049 | verification-plan | The SMC real-time health dashboard (SUB-REQ-021) SHALL be verified by: (1) inducing CPU spike, memory leak, and network ... |
| VER-REQ-050 | verification-plan | The RRS 30-day retention with integrity protection (SUB-REQ-022) SHALL be verified by: (1) running the RRS for a 30-day ... |
| VER-REQ-051 | verification-plan | The CWP sector ownership display currency (SUB-REQ-024) SHALL be verified by: (1) executing 20 sector boundary transfers... |
| VER-REQ-052 | verification-plan | The AMAN landing sequence computation (SUB-REQ-026) SHALL be verified by: (1) loading a high-density traffic scenario (2... |
| VER-REQ-053 | verification-plan | The CPDLC message authentication (SUB-REQ-027) SHALL be verified by: (1) injecting 100 CPDLC messages with valid ATN B1/... |
| VER-REQ-055 | verification-plan | The CPDLC message logging and tamper-evidence (SUB-REQ-031) SHALL be verified by: (1) executing 200 CPDLC message exchan... |
| VER-REQ-057 | verification-plan | The AMAN multi-runway configuration (SUB-REQ-033) SHALL be verified by: (1) configuring all 4 runway configurations simu... |
| VER-REQ-058 | verification-plan | The AMAN planning horizon (SUB-REQ-034) SHALL be verified by: (1) populating the AMAN with 30 aircraft at ranges from 0 ... |
| VER-REQ-059 | verification-plan | The FDP OLDI coordination processing (SUB-REQ-035) SHALL be verified by: (1) injecting 100 ABI, ACT, REV, and LAM messag... |
| VER-REQ-060 | verification-plan | The FDP trajectory prediction accuracy (SUB-REQ-036) SHALL be verified by: (1) running 500 historical traffic scenarios ... |
| VER-REQ-061 | verification-plan | The CWP electronic flight strip bay (SUB-REQ-037) SHALL be verified by: (1) populating a sector with 25 active flights, ... |
| VER-REQ-062 | verification-plan | The VCS conferencing latency (SUB-REQ-038) SHALL be verified by: (1) establishing a 6-way conference on a single control... |
| VER-REQ-063 | verification-plan | The SDP→SNS track data interface (IFC-REQ-001) SHALL be verified by: (1) injecting 500 track updates from a simulated SD... |
| VER-REQ-064 | verification-plan | The SDP→FDP track data interface (IFC-REQ-002) SHALL be verified by: (1) running 200 aircraft scenarios with known track... |
| VER-REQ-065 | verification-plan | The FDP OLDI interface to Adjacent ATC Centres (IFC-REQ-003) SHALL be verified by: (1) simulating 4 adjacent ANSP bounda... |
| VER-REQ-066 | verification-plan | The SNS→CWP STCA alert delivery interface (IFC-REQ-010) SHALL be verified by: (1) generating 100 STCA events at the SNS;... |
| VER-REQ-067 | verification-plan | The AIM→SDP navigation data interface (IFC-REQ-011) SHALL be verified by: (1) updating a waypoint and airspace boundary ... |
| VER-REQ-068 | verification-plan | The FDP→CWP flight data interface (IFC-REQ-012) SHALL be verified by: (1) executing 100 flight plan amendments at FDP; (... |
| VER-REQ-069 | verification-plan | The VCS→CWP voice integration interface (IFC-REQ-013) SHALL be verified by: (1) selecting a radio frequency at a CWP pos... |
| VER-REQ-070 | verification-plan | The SMC→subsystems health monitoring interface (IFC-REQ-014) SHALL be verified by: (1) inducing health parameter breache... |
| VER-REQ-071 | verification-plan | The RRS→DDN recording capture interface (IFC-REQ-015) SHALL be verified by: (1) running the full system at peak traffic ... |
| VER-REQ-072 | verification-plan | The SNS-to-CWP alert delivery latency (IFC-REQ-010) SHALL be verified by: (1) configuring an instrumented CWP display wi... |
| VER-REQ-073 | verification-plan | The dual-hot-standby failover capability (ARC-REQ-001) SHALL be verified by: (1) running both SDP and FDP nodes in prima... |
| VER-REQ-074 | verification-plan | The Safety Net System architectural independence from operational processing (ARC-REQ-002) SHALL be verified by analysis... |
| VER-REQ-075 | verification-plan | The DDN VLAN segmentation and physical isolation (ARC-REQ-011) SHALL be verified by: (1) a network topology inspection c... |
| VER-REQ-076 | verification-plan | The AIM subsystem dual-database AIRAC switchover and reversion (ARC-REQ-012) SHALL be verified by demonstration: (1) loa... |
| VER-REQ-077 | verification-plan | The Recording and Replay System multi-stream replay capability (SUB-REQ-009) SHALL be verified by: (1) recording 2 hours... |
| VER-REQ-078 | verification-plan | The Aeronautical Information Management navigation data query latency (REQ-SEAIRTRAFFICCONTROL-002) SHALL be verified by... |
| VER-REQ-079 | verification-plan | The System Monitoring and Control secure configuration management interface (REQ-SEAIRTRAFFICCONTROL-007) SHALL be verif... |
| VER-REQ-080 | verification-plan | The Controller Working Position display refresh rate and track symbol update latency (native SUB-REQ-006) SHALL be verif... |
| VER-REQ-082 | verification-plan | The facility power supply ATS switchover performance (REQ-SEAIRTRAFFICCONTROL-074) SHALL be verified by: (1) with all AT... |
| VER-REQ-083 | verification-plan | The diesel generator 72-hour endurance and fuel alarm system (REQ-SEAIRTRAFFICCONTROL-075) SHALL be verified by: (1) con... |
| VER-REQ-084 | verification-plan | The DDN VLAN segmentation isolation (ARC-REQ-011) SHALL be verified by: (1) configuring a test host on the safety-critic... |
| VER-REQ-085 | verification-plan | The AIM dual-database architecture (ARC-REQ-012) SHALL be verified by: (1) loading a corrupted AIRAC package into the AI... |
| VER-REQ-086 | verification-plan | The SNS-to-CWP alert delivery interface (IFC-REQ-010) SHALL be verified by: (1) triggering 50 STCA alerts and 50 MSAW al... |
| VER-REQ-087 | verification-plan | The Recording and Replay System simultaneous multi-stream replay (SUB-REQ-009) SHALL be verified by: (1) configuring a r... |
| VER-REQ-091 | verification-plan | The training mode isolation (REQ-SEAIRTRAFFICCONTROL-083) SHALL be verified by: (1) inspecting the system architecture d... |