RSLFAC_Interop_DRAFT.pdf

PRF-PT-00910

28 October 2026

Version 0.1

CUI

CUI

Performance Specification

Royal Saudi Land Forces Aviation Corps

Interoperability

X_______________________

SYSTEMS ENGINEER

X_______________________

CHIEF ENGINEER

U.S. Army Capability Program Executive Simulation, Training, Test & Threat (CPE

ST3)

11221 Science Drive Orlando, FL 32826-3224 DRAFT

Version 0.1

CUI

II

CUI

Revision History

Date Version Revision Description 10/28/2026 0.1 Initial Draft

DRAFT

Version 0.1

CUI

III

Table of Contents

Section Title Page

1. SCOPE

Purpose System Description

2. APPLICABLE DOCUMENTS

Government Documents Non-Government Documents

3. REQUIREMENTS

General Requirements

3.1.1 Open Standards

3.1.2 Modular Open System Approach (MOSA)

3.1.3 Maximum Reuse and Minimum Intrusive Modification

3.1.4 Extensibility

3.1.5 Dynamic Federation Membership and Fault Tolerance

3.1.6 End-to-End Collective Training Capability

3.1.7 Future Common Baseline

Interface Control and Architecture

3.2.1 Interface Control Document

3.2.2 Data Dictionary

3.2.3 Interface Boundaries

3.2.4 Protocol Translation

3.2.5 Data-Centric Interface Architecture

3.2.6 Authoritative Ownership

3.2.7 Version and Configuration Control

Network and Data Exchange Performance

3.3.1 Data Exchange Protocol

3.3.2 Latency

3.3.3 Jitter

3.3.4 Update Rates

3.3.5 Data Integrity

3.3.6 Unique Entity Identification

3.3.7 Stale Data Handling

3.3.8 Message Validation

Time and Coordinate System Synchronization

3.4.1 Common Time Source

3.4.2 Time Differential

3.4.3 Common Simulation Time Base

3.4.4 Coordinate Reference System

3.4.5 Event Ordering

IV

3.4.6 Session State Synchronization

3.4.6.1 Environmental Correlation

Centralized Instructor Operator Station (IOS) Functionality

3.5.1 Master Control

3.5.2 Collective Session Control

3.5.3 Collective Reposition

3.5.4 Scenario Event Injection

3.5.5 Scenario Management

3.5.6 Connection Status Monitoring

3.5.7 Command Authority and Precedence

3.5.8 Partial-Federation Operations

Collective After-Action Review (AAR) Functionality

3.6.1 Synchronized Recording

3.6.2 Recording Continuity

3.6.3 Collective Playback

3.6.4 Common Timeline

3.6.5 Playback Fidelity

3.6.6 Performance

3.6.7 Concurrent AAR Operations

Disconnect, Recovery, and Degraded-Mode Behavior

3.7.1 Participant Disconnect

3.7.2 Degraded Mode

3.7.3 Rejoin Behavior

3.7.4 Data Logging of Faults Events

Cybersecurity and Audit

3.8.1 Access Control

3.8.2 Role-Based Access

3.8.3 Audit Logging

3.8.4 Log Protection

3.8.5 Secure Configuration

3.8.6 Update Security

3.8.7 Network and Data Exchange Protection

3.8.8 Network Isolation and Boundary Control

Physical and Environmental Integration

3.9.1 Network Hardware

3.9.2 Dust and Sand Ingress

4. VERIFICATION

Methods of Verification Verification Approach Incremental Verification During Development

4.3.1 Early Interface Verification

V

4.3.2 Incremental Integration Demonstration

4.3.3 Agile / DevSecOps Verification

4.3.4 Progressive Risk Reduction

Formal Verification Milestones

4.4.1 Contractor Verification Testing (CVT)

4.4.2 Government Acceptance Testing (GAT)

4.4.3 Physical Configuration Audit (PCA)

4.4.4 On-Site Acceptance Testing (OSAT)

5. APPENDIX SECTION

Performance Specification for Royal Saudi Land Forces Aviation Corps

Interoperability

1. SCOPE

Purpose This Performance Specification establishes the technical and performance requirements for the interoperability solution that will network the new CH-47F Block I Flight Training Device (FTD) with the Royal Saudi Land Forces Aviation Corps (RSLFAC) legacy training systems. The purpose of this solution is to create a cohesive Collective Training Environment (CTE) that enables effective multi-ship mission training. This document defines the requirements for the architecture, interfaces, data exchange, synchronization, centralized control, recording, playback, and verification necessary to achieve this capability.

System Description The Collective Training Environment (CTE) is a system-of-systems that enables real-time, synchronized, and interactive training between distinct flight simulators. The CTE shall federate the following training devices:

a. CH-47F Block I Flight Training Device (FTD): The new device being procured, located at Al Qassim.

b. UH-60L Operational Flight Trainer (OFT): The legacy CAE-built device located at Al Qassim.

c. AH-64Ev2 Longbow Crew Trainer (LCT): The legacy Boeing-built, containerized, mobile trailer-based device located at Al Qassim.

The interoperability solution shall consist of all hardware and software required to connect these devices into a single, shared virtual environment. This includes, at a minimum, gateways, network switches, cabling, middleware, protocol translation services, centralized control services, and data logging services.

The interoperability solution shall provide an end-to-end collective training capability, including a shared virtual environment, synchronized exercise control, and collective After-Action Review (AAR).

The architecture shall be resilient such that the CH-47F FTD and UH-60L OFT can continue collective training without the presence of the AH-64Ev2 LCT when that device is unavailable or disconnected.

No requirement exists under this specification to federate the Al Qassim CTE with devices located at KKMC.

The interoperability architecture shall, however, establish an open and modular common external interface baseline to support future interoperability options for the UH- 60M FTD, including potential local federation at KKMC with compatible devices, including a non-containerized AH-64Ev2 LCT, if later directed, or future relocation of the UH-60M FTD to Al Qassim.

2. APPLICABLE DOCUMENTS

The following documents form a part of this specification to the extent specified herein.

In the event of a conflict between documents referenced herein and the contents of this specification, the contents of this specification take precedence. Nothing in this specification, however, supersedes applicable laws and regulations, unless a specific exemption has been obtained.

Government Documents SOW-2025-026 Statement of Work for CH-47F and UH-60M

Flight Training Devices PRF-PT-00908 RSLFAC CH-47 Block I Performance

Specification

Non-Government Documents IEEE 1516 Standard for Modeling and Simulation

(M&S) High Level Architecture (HLA) IEEE 1278.1 Standard for Distributed Interactive

Simulation (DIS)

3. REQUIREMENTS

General Requirements

3.1.1 Open Standards

The CTE architecture shall be based on a widely accepted, non-proprietary interoperability standard. The Contractor shall propose either a Distributed Interactive Simulation (DIS) or High-Level Architecture (HLA) solution.

3.1.2 Modular Open System Approach (MOSA)

The interoperability solution shall be designed using MOSA principles. The architecture shall utilize gateways, adapters, and/or message translation layers as required to decouple the new CH-47F FTD from the proprietary interfaces of the legacy simulators.

This approach shall permit future simulators to be integrated into the CTE without redesigning the core interoperability architecture.

3.1.3 Maximum Reuse and Minimum Intrusive Modification

The interoperability solution shall maximize reuse of existing training-device capabilities, interfaces, and support infrastructure to the greatest extent practicable. The Contractor shall minimize intrusive modification to legacy or fielded systems and shall only propose adaptation, replacement, retrofit, or additional interfacing where necessary to achieve the required collective training capability.

3.1.4 Extensibility

The architecture shall be scalable to support the future integration of additional training devices (e.g., the UH-60M FTD) and a minimum of 50 additional constructive (computer-generated) entities without degradation of performance.

3.1.5 Dynamic Federation Membership and Fault Tolerance

The CTE shall support dynamic federation membership. Any participating simulator shall be capable of joining or leaving an ongoing training session without causing interruption or restart of the other participating simulators.

The interoperability solution shall be fault tolerant such that disconnection, shutdown, or removal of any single participant shall not prevent continued collective training among the remaining connected participants.

The interoperability solution shall detect loss of connectivity to any participating simulator and annunciate that condition to the master IOS within 5 seconds.

3.1.6 End-to-End Collective Training Capability

The interoperability solution shall provide a complete end-to-end collective training capability rather than a simple point-to-point technical connection. The solution shall support the interoperability-related functions necessary for mission planning support, scenario initialization, shared mission execution, synchronized scenario control, common event distribution, instructor and exercise-control actions, observation, data capture, replay, debrief, and collective After-Action Review (AAR) for the required delivered capability.

3.1.7 Future Common Baseline

The interoperability solution shall establish a common external interface baseline that preserves future interoperability options for the UH-60M FTD.

The external interfaces for simulation data exchange, visual systems, and instructor station integration shall be defined such that the UH-60M FTD can be integrated in the future either:

a. at KKMC with compatible local devices, including a non-containerized AH-64Ev2 LCT, if later directed; or

b. at Al Qassim following relocation, for federation with the established Collective Training Environment (CTE).

The baseline shall be designed so that enabling either future option requires no redesign of the core interoperability architecture and only minimal, known hardware, software, and configuration changes.

Any deviation from this common baseline shall be identified by the Contractor and explicitly justified in the design documentation.

Interface Control and Architecture

3.2.1 Interface Control Document

The Contractor shall develop, maintain, and deliver an interoperability appendix to the Interface Control Document (ICD). The ICD shall define all external interfaces, interface boundaries, message protocols, protocol translations, data models, timing requirements, error handling rules, degraded-mode behavior, and configuration dependencies associated with the interoperability solution.

3.2.2 Data Dictionary

The Contractor shall develop and document a complete data dictionary for all exchanged data. The data dictionary shall define every field, including units, valid ranges, precision, update rates, coordinate frames, timing parameters, ownership rules, message formats, and error-handling rules. This data dictionary shall be delivered as part of the ICD.

3.2.3 Interface Boundaries

The interoperability solution shall identify and control all interface boundaries between the CH-47F FTD, UH-60L OFT, mobile, containerized AH-64Ev2 LCT, gateways/translation services, centralized IOS services, and collective AAR/logging services.

3.2.4 Protocol Translation

Where a legacy simulator uses a proprietary or non-native interface, the interoperability solution shall provide all necessary protocol translation services to exchange required data with the common CTE architecture without loss of required functionality.

3.2.5 Data-Centric Interface Architecture

The interoperability solution shall employ a data-centric interface approach with well-defined interface definitions, data-exchange models, service or interface boundaries, and gateway or translation functions as required to connect participating systems into the required collective training architecture.

3.2.6 Authoritative Ownership

Each entity represented in the CTE shall have a single authoritative source for state generation at any given time. The interoperability solution shall prevent conflicting simultaneous ownership of the same entity or state variable.

Ownership rules, transfer rules, and precedence rules shall be defined in the ICD.

3.2.7 Version and Configuration Control

The interoperability solution shall identify the software versions, message set versions, protocol versions, and configuration dependencies required for successful federation.

These baselines shall be controlled as part of the approved system configuration documentation.

Network and Data Exchange Performance

3.3.1 Data Exchange Protocol

The CTE shall use a common data exchange protocol, such as DIS Protocol Data Units (PDUs) or an HLA Federation Object Model (FOM), for all real-time state data exchanged between the federated simulators.

3.3.2 Latency

The end-to-end latency for the transmission of critical state data, such as entity position, orientation, and velocity, between any two simulators in the CTE shall not exceed 150 milliseconds for 95 percent of all packets during representative training conditions.

3.3.3 Jitter

The packet-to-packet arrival time variation (jitter) for critical state data shall not exceed 20 milliseconds during representative training conditions.

3.3.4 Update Rates

The CH-47F FTD shall broadcast critical state data at a minimum rate of 30 Hz. The interoperability solution shall be capable of receiving, processing, translating, and distributing incoming data from the legacy simulators at their native update rates.

3.3.5 Data Integrity

The interoperability solution shall maintain a packet loss rate of less than 0.1 percent for all critical real-time data transmitted over the CTE network during a representative training scenario.

3.3.6 Unique Entity Identification

Each aircraft, constructive entity, threat, event source, and other network-visible object in the CTE shall be assigned a unique identifier that remains persistent throughout the active exercise.

3.3.7 Stale Data Handling

The interoperability solution shall detect stale or invalid critical state data and shall process it in accordance with ICD-defined timeout, extrapolation, and discard rules.

3.3.8 Message Validation

The interoperability solution shall validate incoming interface messages for format, completeness, and required field ranges in accordance with the ICD and shall log interface errors for diagnostic purposes.

Time and Coordinate System Synchronization

3.4.1 Common Time Source

All simulators and interoperability services in the CTE shall be synchronized to a common time source. The Contractor shall define and implement the time synchronization method as part of the interoperability design.

3.4.2 Time Differential

The time differential between any two connected participants or interoperability services shall not exceed 20 milliseconds during normal operation.

3.4.3 Common Simulation Time Base

The interoperability solution shall maintain a common simulation time base across all participating simulators and interoperability services for exercise control, event distribution, and AAR synchronization.

3.4.4 Coordinate Reference System

The interoperability solution shall use a common geodetic reference system and consistent coordinate transformation rules for all exchanged entity state data.

Coordinate conventions, altitude references, heading references, and units shall be defined in the ICD.

3.4.5 Event Ordering

The interoperability solution shall preserve deterministic event ordering for collective session control commands and distributed scenario events.

3.4.6 Session State Synchronization

Initialize, run, freeze, reposition, reset, and terminate commands distributed through the CTE shall be applied consistently across all connected participants.

3.4.6.1 Environmental Correlation

Time of day, illumination state, weather state, and instructor-injected scenario events distributed through the interoperability solution shall be applied consistently across all connected participants to the extent supported by their native capabilities and the approved ICD mappings.

Centralized Instructor Operator Station (IOS) Functionality

3.5.1 Master Control

The CTE shall support operation from a centralized, master IOS. From this station, an instructor shall be able to perform collective control functions across all connected participants.

3.5.2 Collective Session Control

The master IOS shall be capable of commanding, at a minimum, the following collective session states across all connected participants:

a. Initialize

b. Run

c. Freeze

d. Reposition

e. Reset

f. Terminate

3.5.3 Collective Reposition

The master IOS shall be capable of repositioning all connected participating aircraft to a new location in a synchronized manner.

3.5.4 Scenario Event Injection

The master IOS shall be capable of injecting scenario events, including threats, entities, and mission events, that are distributed to all connected participants in accordance with the approved scenario design and interface mappings.

3.5.5 Scenario Management

The master IOS shall be capable of loading, managing, and monitoring a unified mission scenario that includes entities and events for all participating simulators. The interoperability solution shall provide the capability to configure and initialize the required collective training event, including selection of participating devices, allocation of exercise-control functions, loading of approved scenario data, and setup of associated logging and AAR services.

3.5.6 Connection Status Monitoring

The master IOS shall continuously monitor the connection status of each simulator and shall clearly display whether each participant is online, offline, degraded, or disconnected.

3.5.7 Command Authority and Precedence

When a simulator is participating in a collective training session, the master IOS shall have authoritative control over collective session states. Precedence rules between local IOS functions and master IOS functions shall be defined in the ICD.

3.5.8 Partial-Federation Operations

All collective control functions shall apply only to currently connected participants. Loss or absence of one participant shall not prevent continued control of the remaining connected participants.

Collective After-Action Review (AAR) Functionality

3.6.1 Synchronized Recording

The interoperability solution shall include a collective data logging capability that records critical state data, instructor actions, session control events, and participant connection-status events from all participating simulators into a common, time-synchronized record.

To the maximum extent practicable, the collective data logging capability shall capture and correlate other training-relevant data available through the interoperability solution or approved legacy-system interfaces, including distributed events, entity/event logs, and other data necessary to support collective mission replay and debrief.

3.6.2 Recording Continuity

The collective AAR system shall continue recording across initialization, run, freeze, reposition, reset, participant join, participant leave, disconnection, reconnection, and termination events.

3.6.3 Collective Playback

The AAR system shall be capable of replaying the entire collective mission from the common recorded data set. Playback shall provide a unified view of the exercise, allowing instructor review of all participating aircraft and relevant entities from multiple perspectives, using the recorded and correlated training-relevant data available from the participating systems and interoperability services.

3.6.4 Common Timeline

The AAR system shall correlate all recorded data to a common timeline to support accurate collective debriefing.

3.6.5 Playback Fidelity

The collective playback capability shall preserve the relative timing and sequencing of recorded participant actions and distributed events within the limits of the recorded data resolution.

3.6.6 Performance

The recording and playback functions of the collective AAR system shall not degrade real-time training performance below the required interoperability performance thresholds of this specification.

3.6.7 Concurrent AAR Operations

To the maximum extent practicable, the collective AAR capability shall support conduct of replay and debrief activities without preventing continued training operations by other non-participating or subsequently scheduled devices and interoperability services.

Disconnect, Recovery, and Degraded-Mode Behavior

3.7.1 Participant Disconnect

Upon loss of connectivity to a participating simulator, the interoperability solution shall identify that participant as disconnected, notify the master IOS, and continue operation of the remaining connected participants without requiring exercise restart.

3.7.2 Degraded Mode

Upon loss of selected non-critical data streams or partial interface degradation, the interoperability solution shall continue to support the maximum feasible collective training functionality and shall annunciate the degraded condition to the master IOS.

3.7.3 Rejoin Behavior

The interoperability solution shall support controlled rejoin of a disconnected participant to an active exercise in accordance with ICD-defined procedures for state synchronization and exercise control.

3.7.4 Data Logging of Faults Events

All participant disconnects, reconnects, degraded connections, interface faults, and recovery actions shall be logged with timestamps for troubleshooting and AAR use.

Cybersecurity and Audit

3.8.1 Access Control

The interoperability solution shall enforce authenticated access to administrative, maintenance, and instructor control functions.

3.8.2 Role-Based Access

The interoperability solution shall implement role-based access control for instructor, maintainer, and administrator functions.

3.8.3 Audit Logging

The interoperability solution shall generate audit logs for successful and failed login attempts, privileged actions, configuration changes, connection status changes, and interface faults, and cybersecurity-relevant events (including failed authentication attempts against interoperability services).

3.8.4 Log Protection

Audit logs shall be protected from unauthorized modification or deletion.

3.8.5 Secure Configuration

The interoperability solution shall be delivered in a secure configuration that minimizes exposed services, ports, and protocols to only those required for approved interoperability functions.

3.8.6 Update Security

The interoperability solution shall provide a secure method for updating interoperability software and associated protections without compromising the integrity of the operational training environment.

3.8.7 Network and Data Exchange Protection

The interoperability solution shall protect the confidentiality and integrity of real-time training data exchanged across the Collective Training Environment. The Contractor shall implement protections appropriate to the operational environment (for example, encryption of data in transit, integrity checking of critical messages, or operation of the federation within a protected network enclave) so that unauthorized interception, modification, or injection of training data is prevented or detectable.

3.8.8 Network Isolation and Boundary Control

The interoperability solution shall support isolation of the Collective Training Environment network from non-training networks and shall control external interfaces so that only authorized interoperability traffic is permitted. Gateways, boundary devices, and any external connections shall enforce the approved interface set and message types defined in the Interface Control Document. The architecture shall be capable of accommodating additional cybersecurity constraints identified by the customer without requiring redesign of the core interoperability solution.

Physical and Environmental Integration

3.9.1 Network Hardware

All Contractor-provided network switches, gateways, servers, and other interoperability hardware shall be rack-mountable or otherwise suitable for the intended installation environment.

3.9.2 Dust and Sand Ingress

All Contractor-provided hardware that is part of the interoperability solution shall be designed and verified for dust and sand ingress protection in accordance with the parent FTD specification.

4. VERIFICATION

Methods of Verification The following methods will be utilized to accomplish the verification of requirements:

a) Analysis

b) Demonstration

c) Examination/Inspection

d) Test

Verification Approach

Interoperability shall be verified progressively throughout the development lifecycle and shall not be deferred until Contractor Verification Testing (CVT). The Contractor shall implement an incremental verification approach consistent with Agile and DevSecOps practices to reduce technical, schedule, and integration risk.

The Contractor shall verify interoperability functions at the lowest practical level as soon as the relevant hardware, software, interfaces, or data models become available.

Verification shall begin during design and implementation and shall continue through subsystem integration, system integration, formal test events, and on-site acceptance.

The Contractor shall plan and conduct incremental interoperability demonstrations, integration events, and test activities throughout development to confirm progress in interface implementation, data exchange, synchronization, centralized control, and collective AAR capability.

Interoperability verification activities conducted prior to CVT shall be traceable to the requirements of this specification, the Interface Control Document (ICD), and the Requirements Traceability Verification Matrix (RTVM).

Incremental Verification During Development

4.3.1 Early Interface Verification

The Contractor shall verify interface definitions, message structures, field mappings, units, coordinate conventions, and protocol behaviors as soon as those elements are implemented. Early verification may be conducted by analysis, bench testing, software integration testing, or hardware-in-the-loop methods, as applicable.

4.3.2 Incremental Integration Demonstration

The Contractor shall conduct incremental integration demonstrations throughout development to show progressive maturity of the interoperability solution. These demonstrations shall include, as the design matures, verification of:

a. Basic connectivity between participating components

b. Data exchange correctness

c. Protocol translation behavior

d. Time synchronization

e. Centralized IOS control functions

f. Collective AAR data capture and playback

g. Disconnect, degraded mode, and recovery behavior

4.3.3 Agile / DevSecOps Verification

The Contractor shall integrate interoperability verification into the Agile and DevSecOps development process to the maximum extent practicable. Automated tests shall be used where feasible to continuously verify interface behavior, message compliance, data model integrity, and regression impacts as software is updated.

4.3.4 Progressive Risk Reduction

The Contractor shall use incremental interoperability verification to identify, document, and mitigate technical risks early, including risks associated with legacy interfaces, protocol translation, data ownership, timing, synchronization, and scenario control.

Formal Verification Milestones Verification of compliance with this specification shall be demonstrated and accepted at the following milestone events:

4.4.1 Contractor Verification Testing (CVT)

At CVT, the interoperability solution shall demonstrate that the integrated system is sufficiently mature for comprehensive Government acceptance testing. CVT shall confirm that the core functional, interface, synchronization, and performance requirements defined herein have been implemented and verified in the integrated configuration.

CVT shall not be the first demonstration of interoperability. Rather, it shall build upon the incremental verification activities conducted throughout development.

4.4.2 Government Acceptance Testing (GAT)

At GAT, the interoperability solution shall be formally verified using a USG-approved test environment that emulates the interfaces of the legacy UH-60L OFT and AH-64Ev2 LCT. GAT shall include formal verification of ICD compliance, messaging protocols, data models, protocol translation behavior, and data exchange correctness.

This specification does not require GAT verification of interoperability between Al Qassim and KKMC, nor does it require Day One interoperability verification for the UH- 60M FTD at KKMC.

4.4.3 Physical Configuration Audit (PCA)

At PCA, the as-built interoperability solution shall be verified by inspection and record to match the approved configuration baseline, including hardware, software versions, network configuration, interface definitions, and associated documentation.

4.4.4 On-Site Acceptance Testing (OSAT)

At OSAT, final end-to-end interoperability verification of the required delivered capability shall be conducted at Al Qassim using the CH-47F FTD and the designated operational legacy trainers located there, including the UH-60L OFT and the mobile, containerized

AH-64Ev2 LCT. OSAT shall verify mission-level interoperability in the operational environment.

This specification does not require OSAT verification of interoperability between Al Qassim and KKMC, nor does it require Day One interoperability verification for the UH- 60M FTD at KKMC.

If future local interoperability at KKMC with compatible devices, including a non-containerized AH-64Ev2 LCT, is later directed, associated verification requirements shall be defined under separate approved requirements and test procedures.

5. APPENDIX SECTION

Appendix A - Acronym List

Acronym Definition AAR After Action Review CTE Collective Training Environment CUI Controlled Unclassified Information CVT Contractor Verification Testing DIS Distributed Interactive Simulation FOM Federation Object Model FTD Flight Training Device GAT Government Acceptance Testing HLA High Level Architecture ICD Interface Control Document IOS Instructor Operator Station LCT Longbow Crew Trainer MOSA Modular Open Systems Approach NTP Network Time Protocol OFT Operational Flight Trainer OSAT On-Site Acceptance Testing PCA Physical Configuration Audit PDU Protocol Data Unit RSLFAC Royal Saudi Land Forces Aviation Corps RTVM Requirements Traceability Verification Matrix SOW Statement of Work