Attachment A - TSS Software Specification - DRAFT.pdf

Tower Simulation System

(TSS)

Software Specification

DRAFT

Attachment J-1

Version 18

February 12, 2025

TSS Software Specification - DRAFT i

Contents

1 SCOPE

1.1 Document Purpose

1.2 Background

1.3 System Overview

1.4 Document Overview

2 APPLICABLE DOCUMENTS

2.1 Availability of Documents

2.2 Referenced Documents

3 REQUIREMENTS

3.1 System Software Requirements

3.1.1 TSS Positions

3.1.2 TSS Software Functional Requirements

3.1.3 Sound System

3.1.4 Visual System

3.1.5 Airport Visual Databases (VDB) and Models

3.1.6 Moving Models

3.1.7 Voice Recognition and Synthesis

3.1.8 Voice Communication System

3.1.9 Aircraft Characteristics

3.1.10 Physical Characteristics

3.1.11 Vehicle Characteristics

3.1.12 Record and Playback Function

3.1.13 Scenario Control

3.1.14 Weather Control

3.1.15 Airfield Lighting

3.1.16 Supervisor

3.1.17 RPO

3.1.18 Clearance Delivery/Flight Data

3.1.19 STARS

3.1.20 ASDE-X, AMASS, and SAI

3.1.21 Flight Strips

ii

3.1.22 Scenario Events

3.1.23 Macro/quick keys

3.1.24 Scenario Management

3.1.25 System Maintenance Functions

3.1.26 Intranet/Internet/Remote Capability

3.2 Equipment Requirements

3.2.1 COTS

3.2.2 TSS Equipment

Appendix 1: Acronyms Appendix 2: Definitions

1 SCOPE

1.1 Document Purpose

This specification establishes the functional, performance, design, and test requirements for the Tower Simulation System (TSS) Software.

1.2 Background

The FAA uses the TSS to train FAA air traffic controllers to safely and expeditiously move aircraft from, to, and through their designated airspace in the FAA national airspace system (NAS) and accomplish air traffic technical training as specified in FAA Order JO 3120.4, Air Traffic Technical Training. The TSS provides both developmental and certified tower controllers with training tools to improve their situational awareness, decision-making, effective communication, and workload management in a non-operational environment.

1.3 System Overview

The TSS consists of the hardware, software, firmware, databases, and documentation required to support the simulation of an air traffic control tower (ATCT) operational environment. The TSS is a hardware scalable, software extensible, and system configurable ATCT simulator providing an interactive, highly realistic environment for controller training. It supports scenario training for individuals or up to four students simultaneously. The TSS provides voice recognition and realistic synthetic voice response to allow a student to interact with the TSS. The voice recognition system interprets the student’s commands and translates them into actual aircraft movement depicted on the computer screen. For certain complex traffic scenarios, remote pilot operators (RPOs) can override the voice response capability and respond directly to the student.

RPOs view the simulated airport and surrounding airspace so they may enter accurate and timely aircraft commands. The TSS has tools for the development of realistic training scenarios. A recorded playback feature allows instructors to review and evaluate performance with the student after the training session has been completed.

The TSS does not interact with any operational systems and does not pose a threat of interrupting air traffic control (ATC) service. The TSS creates an environment that operates away from, and independently of live air traffic operations. It realistically replicates operations that enable training in an absolute safe environment. In addition to initial training, the TSS provides the ability to perform refresher training to heighten awareness of controllers from repeated exposure to seldom seen operations and airport conditions.

The TSS is also used in non-training applications. The TSS can be used to replicate various safety incidents at an airport to evaluate potential impacts and improve preparedness. It aids in site surveys for proposed new construction on or near the airfield. It also assists in the planning of new runways or changes in local arrival or departure procedures in an accurate and safe simulated environment.

The TSS is operated by local facility air traffic personnel or a TSS Field Service Representative (FSR). The TSS is a self-contained simulator that the developmental controller and instructor can turn on, select the desired training scenario, and conduct training.

1.4 Document Overview

Section 2 of this document lists the specifications, standards, and orders referred to in this document. Section 3 provides the TSS Software functional, performance, and design requirements. Section 4 identifies the test requirements for the TSS Software. In addition, there are two appendices and six SIR attachments that provide information and requirements referenced in this TSS Software Specification:

1. Appendix 1 – Acronyms

2. Appendix 2 – Definitions

3. Attachment J-2 – TSS System Locations and Airport Visual Databases List* [This attachment is a comprehensive list of 170+ TSS system locations throughout the NAS and associated airport visual databases]

4. Attachment J-3 – Representative TSS Hardware Components

5. Attachment J-4 – Representative TSS Remote Pilot Operator Hardware Components

6. Attachment J-5 – Representative TSS Scenario Development Laptop Components

7. Attachment J-6 – TSS Models – Aircraft & Vehicle Fleet List* [This attachment is a comprehensive list of aircraft and other vehicles active in the NAS that will evolve over time]

8. Attachment J-7 – TSS Models – Ground Objects* [This attachment is a comprehensive list of ground objects present at airports in the NAS that will evolve over time]

* Denotes that attachment is not being provided at this time but will be provided with the final Tower Simulation System Software Specification.

For clarification purposes the intent of the following words used in this specification is provided below:

• “Must” means an action is mandatory.

• “Should” means an action is recommended.

• “May” means an action is permitted.

• “Will” is used only to indicate futurity and is not a requirement.

• Singular words include the plural and plural words include the singular.

2 APPLICABLE DOCUMENTS

The documents listed in Section 2.2 form a part of this specification and are applicable to the extent specified herein. Unless otherwise specified in Section 2, the version in effect on the date of issuance of the Screening Information Request (SIR) for the relevant TSS software procurement is applicable. Referenced documents are applicable to the extent specified herein.

If applicability is not further specified in the text of this TSS Software specification, then the entire document is applicable. In the event of conflict between documents referenced herein and the contents of this specification, the contents of this specification must prevail.

2.1 Availability of Documents

Copies of FAA specifications, standards, and publications may be obtained from the FAA Acquisition Management System (AMS) website or from the FAA TSS Software Contracting Officer (CO) if the document is not available on the FAA AMS website. Requests must clearly identify the desired material by name and number (when applicable) and state the intended use of the material. Requested copies will be provided in electronic format.

2.2 Referenced Documents

1. FAA Order 3120.4, Air Traffic Technical Training

2. FAA Order JO 7110.65, Air Traffic Control

3 REQUIREMENTS

This section specifies the functional, performance, design, and test requirements of the TSS software.

3.1 System Software Requirements

The TSS system software must physically and functionally represent a typical FAA ATCT. The TSS software must simulate air and ground traffic at ATCTs with the visual representation displayed on various screens to align with what would typically be seen by an air traffic controller.

The TSS system software must have the following capabilities and functions:

• Display out-the-window (OTW) views and ATCT simulation scenario information with real-time display accuracy.

• Simulate aircraft and ground vehicles that recognize controller commands issued in FAA Order JO 7110.65 phraseology and respond appropriately with a realistic synthetic voice through speakers, headsets, or both speakers and headsets.

• Display a dynamic weather environment and seasonal environmental changes.

• Accurately depict aircraft, vehicles, and aircraft characteristics to include unique airborne profiles.

• Connect to the internal FAA intranet to download TSS software changes, obtain TSS user information, and support remote participation.

• Provide voice recognition for enhanced interaction.

• Integrate virtual databases (VDBs) and customizable virtual spaces (playing areas) tailored for each airport.

• Simulate radar informational data and the ATC Voice Communication System (VCS).

• Function as required with the TSS hardware components specified in Section 3.2 of this document. The software must be scalable, with the capability to function effectively on all simulator systems based on the available hardware.

• Support the ability for trainees to engage in self-training by practicing various simulations.

The TSS system software must be hardware scalable, software extensible, and system configurable to provide any combination of the FAA ATCT positions specified below. The definitions for scalable, extensible, and configurable are defined as follows:

• Scalable – the ability of a system, network, or process to handle a varying amount of work or number of tasks in a satisfactory manner or its ability to be enlarged or decreased to accommodate changes.

• Extensible – the ability of a system to have new software functionality extended or added through modification of existing software functionality.

• Configurable – the ability of a system to adapt/reuse independent system components by changing their interconnections but not their internals. It is the capability to move software/hardware functionality within the system without having to modify/change existing system components.

3.1.1 TSS Positions

“Positions” refer to the specific roles or functions assigned to users, defining their responsibilities, tasks, and authority within the simulated environment. Each position is designed to mimic real-world job functions, allowing participants to engage with the scenario as if they were in actual operations roles, facilitating targeted learning and interaction based identified duties and decision-making parameters.

Positions in the simulation may be individually assigned to either a user or the system, with options for the system to manage multiple positions simultaneously or for a user to undertake multiple positions within each scenario. The automation of various positions must support the ability to run simulations individually, enabling self-training for trainees.

The interface must incorporate a functionality that enables seamless toggling between users and the system to play any role/position.

The TSS must be configurable to simulate operations for the following positions:

1. Local Control

2. Ground Control

3. Flight Data/Clearance Delivery

4. Coordinator

5. Supervisor

6. Remote Pilot Operator

3.1.1.1 Local Control

The Local Control position is responsible for all active runways and all aircraft operating under instrument flight rules (IFR) or visual flight rules (VFR) within the control zone. The TSS software must have multiple Local Control positions, each with different control areas, as some FAA ATCTs require more than one Local Control position.

3.1.1.2 Ground Control

The Ground Control position is responsible for all aircraft and vehicles operating on the maneuvering area, excluding active runways. The controller at the Ground Control position must obtain approval from the Local Controller before directing an aircraft or vehicle to cross an active runway. The TSS software must allow as many as two students to train at the Ground Control position in a scenario, each with different control areas, as some FAA ATCTs require more than one Ground Control position.

3.1.1.3 Flight Data/Clearance Delivery

The Flight Data position is a communication function that receives and relays weather information, flight plan information, notices to airmen (NOTAMs), and other flight data information to pilots and other agencies.

The Clearance Delivery position is responsible for obtaining and relaying IFR or VFR clearances when the controller receives a request from departing aircraft. The Clearance Delivery position is also a communication function that requires the controller at this position to communicate directly with the pilot and the appropriate FAA NAS sector. The TSS software must be capable of either combining the Flight Data and Clearance Delivery positions or keeping these positions separate during a scenario.

3.1.1.4 Coordinator

The Coordinator position is responsible for managing traffic flows. This position typically coordinates traffic between the positions, advises the tower positions of tower cab actions, and performs functions simulating coordination with other ATC and non-ATC facilities.

3.1.1.5 Supervisor

The Supervisor position must simulate the ATC functions and responsibilities of a pilot and the pilot’s interactions with air traffic controllers and provide all scenario and system management controls. The Supervisor position must have the ability to turn systems on or off while a scenario is running to simulate real world issues that might occur. The Supervisor must have the capability to override commands issued by the trainee.

3.1.1.6 Remote Pilot Operator

The RPO position must simulate the ATC functions and responsibilities of a pilot and the pilot’s interactions with air traffic controllers. The TSS software must allow as many as five RPOs to participate in a scenario. The RPO must have the capability to override commands issued by the trainee.

3.1.2 TSS Software Functional Requirements

The TSS software must enable the creation of a virtual playing area for each airport that replicates the environment and operational parameters experienced in the airport’s ATCT. The TSS software must simulate air and ground traffic at ATCTs with the visual representation displayed on various screens to align with what would typically be seen by an air traffic controller. The TSS software must simulate the ATCT functions of the following systems:

1. Airport Surface Detection Systems

2. Standard Terminal Automation Replacement System

3. Airport Surveillance Radar Systems

4. Runway Status Lights

5. Weather and Information Display Systems

6. Communication Systems

7. Navigation Aids and Landing Systems

8. Instrument Approach Procedures Systems

9. Runway Visual Range Systems

10. Wide Area and Local Area Augmentation Systems

3.1.2.1 Airport Surface Detection Systems

Airport surface detection systems are runway-safety tools that enable air traffic controllers to detect potential runway conflicts by providing detailed coverage of movement on runways and taxiways. The surface detection systems are able to track vehicles and aircraft on airport surfaces and obtain identification information from aircraft transponders by collecting data from a variety of sources. Airport surface detection systems include the following systems:

1. Airport Surface Detection Equipment (ASDE)

2. ASDE Model X (ASDE-X)

3. Airport Movement Area Safety System (AMASS)

4. Surface Awareness Initiative (SAI) system – a system that uses Automatic Dependent

Surveillance – Broadcast (ADS-B) data to display surface traffic to controllers at airports that do not have a surface surveillance tool.

3.1.2.2 Standard Terminal Automation Replacement System

The Standard Terminal Automation Replacement System (STARS) is a digital automation system capable of tracking all aircraft within the defined airspace, using information from available FAA and U.S. Department of Defense (DoD) surveillance systems, and displaying this information on monitors. STARS receives, processes, and displays target reports, weather information, and other non-target messages from both terminal and en route digital sensors. This system also automatically tracks primary and secondary surveillance targets and provides aircraft position information. STARS also detects unsafe proximities between tracked aircraft and provides a warning if tracked aircraft are detected at an unsafe altitude.

Additional features provided by STARS include the Converging Runway Display Alert (CRDA) and Controller Automation Spacing Aid (CASA). These features display “ghost” targets as an aid to controllers attempting to tightly space aircraft in the terminal environment.

3.1.2.3 Airport Surveillance Radar Systems

The TSS software must simulate terminal short-range radar (ASR-9 and ASR-11), en route long-range radar, and ADS-B. Airport surveillance radar (ASR) systems are radar systems used at airports to detect and display aircraft in the terminal area. The ASR-9 and ASR-11 systems are also referred to as “precision approach radars” and are integrated primary and secondary radar systems that provide aircraft information within a 60 nautical mile radius of the radar location.

The primary radar provides aircraft location and direction and data on rainfall density. The secondary radar systems provide barometric altitude, identification code, and emergency conditions data for all area aircraft. The ASR-11 also provides six-level National Weather Service (NWS) calibrated weather capability that provides enhanced situational awareness for both controllers and pilots. The ASR data is displayed on STARS display consoles in control towers.

3.1.2.4 Runway Status Lights

The Runway Status Lights (RWSL) system consists of runway entrance lights, takeoff hold lights, and other necessary airfield lighting equipment that are dynamically controlled based on real-time surveillance of aircraft and vehicle positions on the simulated airfield. The RWSL system provides visual warnings through the activation of lights to indicate unsafe conditions, such as the risk of entering, crossing, or commencing takeoff on an active runway. These lights illuminate red to signal potential hazards or unsafe conditions and are extinguished when the conditions are deemed safe. The RWSL system integrates airport lighting equipment with approach and surface surveillance systems to provide a visual signal to pilots and vehicle operators indicating that it is unsafe to enter, cross or begin takeoff on a runway. Red airfield lights (runway entrance lights and takeoff hold lights) illuminate and extinguish as vehicles and aircraft traverse the airfield.

3.1.2.5 Weather & Information Display Systems

The Weather and Information Display is a network of individual workstations designed to provide air traffic controllers with static and dynamic weather-related and operational data critical for air traffic control. It interfaces with the following weather systems and sensors:

1. Automated Surface Observing Systems (ASOS) and Automated Weather Observing Systems (AWOS)

2. Digital Altimeter Setting Indicator (DASI)

3. Flight Data Input/Output (FDIO)

4. Low Level Windshear Alert System (LLWAS)

5. Terminal Doppler Weather Radar (TDWR)

6. Weather and Radar Processor (WARP)

7. Notice to Air Mission (NOTAM)

8. Runway Visual Range (RVR)

9. NAS Infrastructure Division Systems (NIDS)

10. Automated Terminal Information Service (ATIS)

11. Meteorological Aerodrome Report (METAR)

3.1.2.6 Communication Systems

Voice communications are a fundamental part of providing ATC services. Both air-to-ground and ground-to-ground voice communications are essential for the terminal domain of aircraft flights to provide safety, orderly and efficient flow of air traffic. The TSS software must simulate the following types of voice communications:

1. ATC VCS

2. Ultra-high frequency (UHF)/very high frequency (VHF) frequency modulation (FM) radios – modulation and transmission over UHF and VHF bands, crucial for direct communication with aircraft.

3. Intercom – internal communications between controllers, other operational staff, and other intra-facility positions.

4. Landline communications – fixed communication lines between interfacility positions.

3.1.2.7 Navigation Aids and Landing Systems

The TSS software simulation must show how these systems enhance positioning and whether they are available or degraded. For example, one scenario may show how much more precisely an aircraft can navigate towards and along the approach path when these systems are active compared to when they are not active.

Weather conditions must be linked to navigation and landing system performance. The TSS system software must ensure the visual representation of weather conditions viewed from an ATCT is accurately reflected in the performance readings of navigation and landing systems.

The system software must display navigation aids performance realistically by mirroring how these navigation aids would respond under similar real-world meteorological conditions and providing air traffic controllers with authentic scenarios for decision-making during aircraft approaches and landings.

3.1.2.8 Instrument Approach Procedures Systems

The TSS software must simulate the instrument approach procedures provided by the following systems:

1. Instrument Landing System (ILS)

2. VHF Omnidirectional Range (VOR)

3. Area Navigation (RNAV)

4. Non-Directional Beacon (NDB)

5. Tactical Air Navigation (TACAN)

The TSS software must incorporate accurate altitude data to ensure comprehensive training scenarios. These approaches should accurately replicate real-world procedures, allowing trainees to practice and master different types of instrument landings.

3.1.2.9 Runway Visual Range (RVR) Systems

Runway visual range (RVR) is the distance over which a pilot of an aircraft on the centerline of the runway can see the runway surface markings delineating the runway or identifying its centerline. RVR is used as one of the main criteria for minima on instrument approaches as in most cases a pilot must obtain visual reference of the runway in order to land the aircraft. The TSS simulation software must have dynamic RVR measurements and the ability to simulate changing visibility conditions on the runway, influenced by fog, rain, snow, and other meteorological factors. Instrumented RVR systems are used by the ATC to provide this information to pilots.

3.1.2.10 Wide Area and Local Area Augmentation Systems

The Wide Area Augmentation System (WAAS) and the Local Area Augmentation System (LAAS) are ground based navigation aids that augment aircraft information provided via the Global Positioning System (GPS) network of satellites. The WAAS and LAAS are all-weather aircraft landing systems that use real-time differential corrections of the GPS signal for precision approaches and landings at airports.

The TSS simulation software should show how these systems enhance positioning and whether they are available or degraded. For example, one scenario may show how much more precisely an aircraft can navigate towards and along the approach path when these systems are active compared to when they are not.

The TSS simulation software must display information panels and other tools that show navigation aid statuses, such as the operational status of ILS components, RVR values, and augmentation system availability.

Weather conditions must be linked to navigation and landing system performance. The TSS simulation software must ensure the visual representation of weather conditions viewed from an ATCT is accurately reflected in the performance readings of navigation and landing systems.

The TSS software must display navigation aids’ performance realistically, mirroring how these aids would respond under similar real-world meteorological conditions, to provide air traffic controllers with authentic scenarios for decision-making during aircraft approaches and landings.

3.1.3 Sound System

The TSS software must have 5.1 surround sound to realistically simulate relational and positional audio within the airport environment. It must accurately reproduce the sounds of aircraft, vehicles, and other airport-related activities, with appropriate sounds tailored to specific actions and aircraft types. The sound system must support dynamic audio adjustments based on environmental changes, such as weather conditions, time of day, and proximity to different sound sources. Robust audio settings must be available to fine-tune volume levels and balance between different sound elements to suit the user’s preferences.

3.1.4 Visual System

The TSS software must have sufficient resolution, brightness, contrast, and sharpness to allow the trainee, with support from other informational aids (i.e., radar displays), or modeling techniques, to detect, recognize and identify aircraft at distances sufficient to meet the training objectives. The visual scene must have no discernible flashing, flickering, popping or indications of visual error.

3.1.4.1 Physical Field of View (PFOV)

The TSS system software must provide a 315° horizontal physical field of view.

3.1.4.2 Vertical Field of View (VFOV)

The TSS system software must have a 45° vertical field of view, providing comprehensive visibility for simulation purposes. Additionally, it should allow for tilt adjustments of +/- 90° to ensure complete coverage and accurate representation of all angles in the simulated environment.

3.1.4.3 Horizontal Field of View (HFOV)

The TSS system software must have a 180-360° horizontal field of view that can be rotated 360°, allowing users to have a complete situational awareness and an immersive experience within the simulated environment.

3.1.4.4 Image Quality

The TSS system software must have a minimum 60 Hz refresh rate and a minimum display resolution 3840x2160 (4K). The TSS system software must provide an anti-aliased image.

3.1.4.5 Geometry Channel Match

The TSS software must support multiple displays for the OTW view accommodate setups where a mullion or plastic piece separates the screens. The TSS software must ensure that objects moving between screens appear to move seamlessly behind the mullion, rather than jumping abruptly to the next screen. The TSS software must include a feature to verify geometry channel matching, ensuring precise alignment and consistency of visual elements across all display channels. The channel match must be verifiable by displaying the same cross hatch test pattern as used to verify geometry accuracy and observing that the horizontal lines join each other at the screen edges.

3.1.4.6 Performance Metrics

The visual system must provide a minimum of 250 visible moving aircraft and ground vehicle models distributed evenly across the full field of view (applies to TSS system configurations with 3-14 visual channels). The system must support at least 25 moving models in a single channel at 60 Hz. Moving models must display continuous smooth movement in each scenario, with no visual disruptions, including but not limited to screen flickering or degradation of graphics into blocky or misshapen forms.

3.1.4.7 Weather

The TSS system software must provide programmable, dynamic weather effects with appropriate visual representation. The TSS software must be capable of simulating a wide range of weather conditions, including clear skies, rain, snow, fog, thunderstorms, sand/dust storms, and high winds. Each condition must have adjustable severity levels to match real-world scenarios.

Weather conditions must be programmable to change dynamically over time during simulations to mimic weather progression and sudden meteorological changes. Weather effects must be realistic and have high quality graphics that accurately represent various weather phenomena as seen from the control tower. Visual weather effects must be consistent with the meteorological data used in the simulation. This includes the appearance of:

1. Clear skies

2. Cloud cover

3. Rain

4. Thunderstorms

5. Snow

6. Fog

7. Wind

8. Wind shear

9. Icing conditions

10. Turbulence

11. Hail

12. Low visibility conditions

13. Volcanic ash

14. Drizzle

15. Freezing rain

16. Mist

17. Squalls

18. Sand or dust storms

19. Smoke

The simulation must also include visual effects for lightning during thunderstorms, glare from the sun, and reflections on wet surfaces to enhance realism.

The TSS software must ensure the visual representation of weather conditions is synchronized with the radar data and navigational displays used by the controllers within the simulation. The software must allow the supervisor to manually adjust weather parameters to create specific weather training scenarios. Controls must be intuitive and allow for quick changes to simulate sudden weather phenomena. The software must provide immediate visual and data-driven feedback based on the changes in weather settings to verify the correct implementation of the supervisor’s input. Weather data must be displayed visually, and the information presented on system tools like wind indicators, temperature gauges, and radar screens must be consistent to ensure all representations of weather conditions match across all outputs.

The TSS software must include the impact of various weather conditions on aircraft behavior, such as takeoff and landing performance affected by wind speed and direction, and turbulence.

The software must handle the dynamic loading of weather data and visual effects without degrading simulation performance and response times.

The weather in the TSS software must comply with aviation training standards, ensuring that the simulated environments are suitable for air traffic controller training.

3.1.4.7.1 Cloud Formations

The TSS software must accurately depict stratiform and cumuliform cloud formations. Single clouds and cloud formations must have vertical profiles and the depth of the clouds. A cloud layer must have a horizontal profile and cover the whole sky. Cloud layers must present underneath views and be available in 1/8, 1/4, 3/8, 1/2, 5/8, 3/4, 7/8, and full 8/8 coverage. Cloud layer color must be related to the percentage coverage. If no ceiling is defined, the sky must appear blue.

Under the cloud ceiling, the operator must be able to construct a weather scenario composed of single clouds, cloud layers (e.g., minimum of two) and/or cloud formations, and complex cloud formations. The operator must be able to define the position and height of cloud formations and single clouds and must be able to define the height of cloud layers. All cloud types under the ceiling must move according to wind speed and direction provided by the operator and provide similar visual effects to what is experienced in the real world. Cloud dynamics should include changes in shape and form with the wind. The TSS software must support the following cloud models:

1. Cumulus

2. Cumulonimbus

3. Altocumulus

4. Towering cumulus

5. Towering cumulonimbus

6. Altostratus

7. Cirrocumulus

8. Cirrostratus

9. Cirrus

10. Nimbostratus

11. Stratocumulus

12. Stratus

All cloud types must be composed of opaque, semi-transparent, and transparent areas. Objects behind opaque areas of cloud must be occulted. Objects behind transparent areas must be displayed. Objects behind semitransparent areas must be partially occulted. Clouds must interact with the environment effects such as sunlight, creating realistic lighting scenarios including shading and shadowing effects under clouds.

The cloud layers must exhibit appropriate effects such as steady light rain, heavy showers, snow, cloud-to-ground lightning, cloud-to-cloud lightning, and in-cloud lightning.

A rain shaft must be seen as a semi-transparent texture under an associated cloud. Lightning must be provided as a visual cue for thunderstorms. Lightning bolts must be randomly triggered during thunderstorms; bolts must go from cloud to ground; a ‘flash’ effect must be provided whereby the scene is momentarily brightened to simulate the illumination of the surrounding environment.

3.1.4.7.2 Cloud Ceilings

The TSS software must accurately display cloud layers with a definable cloud base above ground level. The cloud base can be defined during scenario preparation or by the Supervisor during an exercise. The software must be capable of displaying at least three layers simultaneously.

Operators must be able to define the thickness of each cloud layer in addition to the cloud base, enhancing the realism and variability of weather scenarios. The software must allow for real-time adjustments to cloud base and thickness during the simulation to reflect changing weather conditions. Each of the three cloud layers must be capable of displaying different types of clouds simultaneously, allowing complex cloud compositions such as a combination of stratus on lower levels and cirrocumulus or altocumulus at higher altitudes. Cloud layers must interact dynamically with other simulated weather systems, such as precipitation and wind patterns, ensuring that changes in one system appropriately influence others. The software must include the ability to pre-build several weather scenarios that specifically focus on challenging cloud ceiling conditions. Operators must have the ability to develop and save custom weather/cloud ceiling scenarios that involve specific cloud ceiling configurations for repeated use.

3.1.4.7.3 Visibility

The TSS software must provide predefined ranges of visibility representing atmospheric conditions such as fog, smoke, haze, rain, mist, drizzle, sleet, snow, ash, dust, and sandstorms.

The software must also have the capability for the operator to add a visibility value. Visibility levels must be adjustable by the Supervisor during an exercise or predefined during scenario creation. Changes in visibility must be capable of a gradual transition based on an operator-defined time or an immediate change. The software must simulate localized weather phenomenon (e.g., a storm cell or fog bank) which must obscure visibility in specific directions or sections of the visual scene. The localized weather phenomenon visibility characteristics must move through the area in a predefined path and be dynamically adjustable during scenarios. In addition, it must be possible to select any operator-defined visibility level with a selected weather condition to enhance the realism and variability of training scenarios. Visibility distances must in statute miles and be selectable in accordance with the following table from FAA Order JO

7900.5 Surface Weather Observing.

3.1.4.7.3.1 Visibility Characteristics

The TSS software must provide the following visibility characteristics.

1. Animated falling rain, dust, snow, drizzle, sleet, ash, and hail must be displayed as ‘global’ weather states.

2. During rain, drizzle, sleet, hail, ash, and snow, the sun intensity and visibility must decrease as the precipitation intensity increases.

3. Raindrops and snow must be visibly represented when a storm surrounds the tower.

4. The intensity of sunlight fog and sun intensity must be modulated based on cloud coverage.

5. The homogeneous visibility range must directly affect the ability to see and identify objects in the scene accurately, including aircraft, ground vehicle, and runway markings.

6. Surrounding modeled details such as urban areas and tree lines must be located at representative ranges for the purpose of fog tower visibility distance markers cues.

7. The software must adjust the color saturation and light levels to reflect the impact of various visibility conditions, such as yellowish hue during a sandstorm or the grey tone during heavy rain.

8. The influence of wind on visibility conditions, such as blowing dust or snow, must be simulated, with the direction and speed of wind affecting the dispersion or accumulation of visual impediments.

9. Visibility effects must be integrated with the simulation’s day/night cycle, affecting how visibility changes from day to night under various weather conditions.

10. Visibility effects for aircraft landing on a water runway, including realistic water spray effects as the aircraft makes contract with the surface.

11. Tower visibility indicators, varying by location and time of day, to ensure that night and day conditions are accurately represented.

3.1.4.8 Time of Day/Month/Year/Season

The TSS software must utilize an ephemeris model to accurately simulate the full diurnal cycle of the local environment by tracking the precise positions of the sun and moon based on the date and time. The sun must illuminate the surfaces in the scene with realistic, directional light. The moon must add up to 20% of ambient lighting at Nighttime during a full moon and decrease with lesser phases. On clear nights, stars should be somewhat visible and must be represented based on the current time and geographical location. A yellow disk must be displayed representing the sun and an emissive lunar-textured disk must be displayed representing the moon. Sun and moon models must be accurately modeled according to the airfield latitude, longitude, date, and time of day. The sun and moon must both be occulted appropriately by clouds, atmospheric conditions, and physical structures like buildings. A horizon glow must be displayed during sunset and sunrise in the direction determined by the ephemeris model. The system must display moonrise and moonset effects, altering ambient light levels and shadowing accordingly. Operators must have the ability to adjust the simulation clock to speed up or slow down the progression of time, allowing for quick transitions between different times of day to observe varying effects and to train in different scenarios quickly.

3.1.4.9 Special Views

The local control position must control the normal view and all special views on the host OTW display, default to the center channel, and be configurable to display on the different nodes. The ground control position must have an independent visual channel with special views capability.

The Supervisor position must have the same special views capability as the local control position (shared control of the OTW view). The following special views must be included.

1. Binocular

2. Binocular Auto-Track

3. Bird’s Eye

4. Camera

5. Pilot

6. Target

7. Free Movement “Fly Mode”

3.1.4.9.1 Binocular

The local and ground positions must be provided with a control system that allows a binocular feature to be selected, panned, pitched, and zoomed. The system must provide a clear indication of the area of the scene in which the binocular inset will appear when activated. The binocular feature should be easily activated by the user at any point within the physical field of view in the simulation. Transitioning to and from binocular view must be seamless, with no disruption to the simulation’s performance. On reaching the limits of the physical field of view, the scene within the binocular inset must scroll and pitch allowing any position within the 360-degree visual database to be viewed. The binocular view must be displayed as an inset to ensure it does not take over an entire channel. The binocular system must simulate the performance of a 7X50 zoom binocular, providing high-resolution imagery capable of significantly magnifying distant objects while maintaining clarity and detail. The binocular feature must not impact the overall TSS system performance.

3.1.4.9.2 Binocular Auto-Track

The binocular system must have an auto-track feature. The auto-track feature enables the operator to select a vehicle or an aircraft and have the binocular inset automatically follow the selected object to any point within or past the physical field of view. While tracking and on reaching the physical limits of the field of view, the scene within the binocular inset must scroll and pitch allowing any position within the 360 degree visual database to be viewed.

3.1.4.9.3 Bird's Eye

The TSS must provide a situational awareness or “Bird’s Eye” feature. View activation of the Bird’s Eye view should be easily toggleable for all users to ensure the users can switch between the standard control tower view and the Bird’s Eye view without disruption. It must be possible to activate and manipulate the Bird’s Eye viewpoint from close to ground level to 30,000 feet above ground level. The adjustments must be smooth and easily controlled via user input. It must also be possible using the scene controller to move the center of the display through the X and Y horizontal axis to allow flexibility in selecting the most beneficial viewpoint. The Bird’s Eye view must be displayed on a complete visual channel (not picture-in-picture). The transition to Bird’s Eye view should be seamless and maintain the TSS software performance standards.

3.1.4.9.4 Camera

The TSS software must provide at least six user-configured alternate eye points. One of the six camera points must be a default view within each simulated airport. The eye points provide additional perspectives and can be used to enhance situational awareness and training depth.

Each eye point must be defined by latitude, longitude, height, pitch, and default viewing direction. Each eye point must be selectable during the running of a scenario. Switching between eye points must be seamless and without significant delays to maintain simulation flow and realism. The visual transition between primary and alternate eye points must be smooth and maintain the continuity of the simulation. The TSS software must ensure that changing viewpoints does not degrade the simulation’s performance. This includes maintaining frame rates and visual fidelity across all alternate eye points.

3.1.4.9.5 Pilot

Pilot view must be selectable from the Supervisor position. This mode presents the scene as viewed from the cockpit of an aircraft or vehicle and must be seen in a full channel view. It must be possible to zoom in and out when using this view and there should be the ability to pan and tilt to see more of the horizon and vertical angles. The correct field of view from the pilot’s perspective must be displayed. The TSS software must ensure that changing viewpoints does not degrade the simulation’s performance. This includes maintaining frame rates and visual fidelity across all alternate eye points.

3.1.4.9.6 Target

Target view must be selectable from the Supervisor position and must be seen in a full channel view. The Target view locks on to the selected target, shown in the middle of the display. It must be possible to rotate the eye point around the target at a fixed radius. It must also be possible for the user to zoom in and out when using this view. The software must ensure that changing viewpoints does not degrade the simulation’s performance. This includes maintaining frame rates and visual fidelity across all alternate eye points.

3.1.4.9.7 Free Movement “Fly Mode”

Free Movement view must be selectable from the Supervisor position. The Free Movement view allows the Supervisor to move around the scene in all three dimensions. This view mode provides a virtual eyepoint that enables the viewpoint to be placed anywhere in the 3D scene. The TSS software must ensure that changing viewpoints does not degrade the simulation’s performance.

This includes maintaining frame rates and visual fidelity across all alternate eye points.

3.1.4.10 Special Visual Features

The TSS software must provide realistic depictions of local hazards to flying that evoke a controller’s response or non-response to specific occurrences. Local hazards must include the following:

1. Bird activity

2. Skydivers

3. Steam or smoke from industrial facilities or natural phenomenon

3.1.5 Airport Visual Databases (VDB) and Models

The TSS software must use a geo-specific/accurate visual representation for each airport. The visual scene must encompass a 360° panoramic field of view centered at the control tower. The visual image and models must automatically load by name as defined in the scenario. The geometry of each element of the TSS visual database (VDB), be it an airfield or aircraft, must reside in its own file for ease of maintenance. The TSS VDBs serve as a visual overlay that depicts the airport environment, including objects and various elements, enhancing the visual realism of the simulation. The TSS software must be able to integrate existing TSS VDBs and support the integration of new TSS VDBs. TSS VDBs should not be restricted to being created solely within the software, allowing for flexibility and compatibility with external image sources. The capability ensures that the simulation can adapt to various training needs and incorporate a wide range of airport environments and scenarios. TSS VDBs should load efficiently without causing significant delays in simulation start up or during real time scenario transitions. The TSS VDBs must work properly on all TSS configurations without any modifications. The Government reserves the right to add or modify TSS VDBs procured from separate FAA contracts.

3.1.5.1 Airport Visual Databases

The TSS software must use airport models that are photo realistic in the near ground and 3D realistic supplemented with scanned images and generic photo texture further away from the tower. Ground surfaces such as tarmac, grass, and aprons must make use of suitable generic textures. The TSS software must have the ability to set the screen height of the horizon on the OTW displays.

Airport details must be modeled to eliminate Z-buffer occultation problems and aliasing of edges and long narrow surfaces. When significant surfaces do not warrant modeling with varying terrain heights, they must be modeled flat, and variations in ground height climbs and drops must be smoothed out over large areas. Distance to horizon must be correct from every viewpoint height of all ATCTs. The TSS software should allow for the models to display ground surfaces, roofs, and trees represented in an appropriate texture for the ground cover currently set in the simulation scenario. For example, there will be alternative textures for snow cover and wet ground.

3.1.5.1.1 Major Features

The major features of an airport must include one or more of each of the following, and must include multiple instances of some features when applicable to the local installation:

1. Runways, helipads, vertical takeoff and landing (VTOL), and short takeoff and vertical landing (STOVL) pads accurately rendered with respect to length, width, markings, and signage.

2. Buildings accurately rendered with respect to perspective, orientation, and coloration.

3. Major construction hazards – major construction includes a stationary picture indicating surface repair or replacement of runways, taxiways, or ramps.

4. Terrain following.

3.1.5.1.2 Lighting Systems

The following features must be included in the lighting systems in the TSS software where appropriate to the local installation:

1. Directionality — lighting directionality as required for Visual Approach Slope Indicators (VASI), and for runway end markings being modeled as appropriate to the local installation.

2. Standard lighting for: runway center and runway edge lighting, taxiway lighting, stop bars, and approach lighting including but not limited to sequential flashing, Wig- Wags, hold bars, RWSL, airport beacon, and glide path indications to the local installation.

3.1.5.1.3 Controllable Objects

Controllable objects refer to objects in the database that are subject to control or manipulation.

The control may be manual, or it may be in reaction to effects in the simulation. These objects must exhibit dynamic behaviors and changes based on user inputs or predefined environmental triggers. Controllable objects must include Barrier Cables and windsocks. The hook-wire must be represented by a wire across the runway that can be raised or lowered. The windsock must react to the wind in the scenario (although not to gusts). The windsock effects must include raising and lowering of the model in relation to the wind speed. The windsock must rotate with a change of wind direction.

3.1.5.1.4 Surroundings and Local Features

Local features and airport surroundings must be included in the visual database to enhance its realism. Each airport’s surrounding and local features are distinct, but must include such things as the background skyline, major roadways, mountains, trees, fields, bodies of water, etc. Local features must be derived from photographic or other source data. Local features must dynamically adjust their appearance based on the time of day (light or dark) including shadows, and prevailing weather conditions to ensure realism and accuracy in their visual appearance.

3.1.5.1.5 TSS VDB Library

The TSS VDBs specified in Attachment J-2 will be provided (in the Unreal format) to be used with the TSS system software. The Government will provide applicable existing TSS VDBs as Government Furnished Information (GFI) for this contract. It is the responsibility of the simulation software vendor to assure the TSS VDBs are compatible or are converted to function with the TSS system software.

3.1.6 Moving Models

The TSS simulation software must have a comprehensive model library of aircraft and airport vehicles that will move within the simulated airport environment. The TSS Model library must have a wide range of accurately modeled airport vehicles and aircraft types, ensuring realistic interactions and movements within the simulated airport environment.

Aircraft and ground vehicle models must have the correct shape, dimensions, and shading reflecting dimension and shapes of their real-world counterparts. Shading techniques must be used to enhance three-dimensional factors and interaction with other objects. The models must be high-resolution textured with either photo-texture or, in the case of a camouflage livery, with appropriate generic textures. The TSS Models must represent the materials, colors, and markings specific to different types of aircraft and vehicles including liveries, company logos, and regulatory markings.

The TSS software must include a library of at least 300 distinct aircraft models, representing a broad range of commercial airlines, cargo aircraft, regional jets, military aircraft, and privately owned aircraft commonly seen at airports in the United States.