Understand Aircraft State and Control Response

Overview

User capability

Show the feedback needed to understand aircraft response

User

An AeroSim player

What the user can do

Show the feedback needed to understand aircraft response

Why the user benefits

The player receives one coherent, observable capability.

User need

The player needs AeroSim to show the feedback needed to understand aircraft response.

In scope

Show the feedback needed to understand aircraft response

• StatusProposed
• OwnerAeroSim Scope (proposed; not accepted)
• Parent EpicAEROSIM-EP-4
• Depends onAEROSIM-FT-3

Tasks

AEROSIM-TS-4Planning status: Done

Project authoritative aircraft state into flight instruments

Attitude, speed, altitude, heading, and control position remain visible and update from the authoritative flight state.

• ComponentWeb Application — flight-state projection and instrument presentation
• Depends onAEROSIM-TS-96
• RequirementsFR-0007, NFR-0001, NFR-0003, NFR-0006, NFR-0010

AEROSIM-TS-5Planning status: Done

Classify and present aircraft warnings and control feedback

Normal, warning, and invalid aircraft states are distinguishable through timely, prioritized control-response cues and warnings.

• ComponentWeb Application — aircraft-state classification and in-flight feedback
• Depends onAEROSIM-TS-4
• RequirementsFR-0008, NFR-0003, NFR-0005, NFR-0010

AEROSIM-TS-125Planning status: Done

Correct the delivered HUD and warning presentation to the approved design

Delivered instruments, contextual warnings, and controller recovery match the approved Minimal Edge HUD and warning screen.

• ComponentWeb Application — Release 1.0.0 user journey
• Depends onAEROSIM-TS-5
• RequirementsFR-0007, FR-0008, NFR-0001, NFR-0003, NFR-0005, NFR-0006, NFR-0010

AEROSIM-TS-174Planning status: To Be Released

Compact flight controls into the right-side HUD and match Camera to Menu

Read all five live control values beside existing flight instruments while retaining compact editable controls and consistent Menu/Camera actions.

• ComponentActive flight controls and Minimal Edge HUD
• Depends onAEROSIM-TS-125
• RequirementsFR-0007, FR-0008, NFR-0001

AEROSIM-TS-177Planning status: In Backlog

Complete HUD design conformance

The player reads complete, coherent flight instruments through an outlined surface-free HUD in Chase, Cockpit, Orbit and Fly-by without losing current controls or later approved layout improvements.

• ComponentActive-flight HUD instrument presentation
• Depends onAEROSIM-TS-96
• RequirementsFR-0007, FR-0008, NFR-0001

Acceptance outcomes

1. 01

   Critical aircraft state and control response remain visible and update from authoritative flight state.

2. 02

   The player can distinguish normal, warning, and invalid aircraft states during flight.

Functional requirements and measurable criteria

FR-0007

present essential aircraft state

The system shall present attitude, speed, altitude, heading, and control position.

Acceptance 01

Givena valid current Feature configuration and defined initial state

Whenthe relevant user action or simulation step occurs

Thenthe observable result must present attitude, speed, altitude, heading, and control position

EvidenceFuture reviewed automated and browser evidence must verify this outcome against the current requirement.

Acceptance 02

Givenan invalid or unsupported input at the same boundary

Whenthe system evaluates the input

Thenthe system must reject or recover visibly without publishing a misleading result

EvidenceFuture negative-path tests and browser evidence must verify explicit failure or recovery behaviour.

FR-0008

present response and warnings

The system shall present timely control-response cues and warnings.

Acceptance 01

Givena valid current Feature configuration and defined initial state

Whenthe relevant user action or simulation step occurs

Thenthe observable result must present timely control-response cues and warnings

EvidenceFuture reviewed automated and browser evidence must verify this outcome against the current requirement.

Acceptance 02

Givenan invalid or unsupported input at the same boundary

Whenthe system evaluates the input

Thenthe system must reject or recover visibly without publishing a misleading result

EvidenceFuture negative-path tests and browser evidence must verify explicit failure or recovery behaviour.

Non-functional requirements

• NFR-0001 — Performance

  Maintain responsive rendering and simulation.

• NFR-0003 — Responsiveness

  Present control and state feedback within a measurable budget.

• NFR-0005 — Resource governance

  Keep browser and deployed workload consumption within explicit budgets.

• NFR-0006 — Compatibility

  Support the declared browser and input compatibility matrix.

• NFR-0010 — Responsive flight interaction

  Supported input-to-state and state-to-render paths meet the declared latency budget across ordinary flight, bounded heavy scenes, pause, camera selection, outcomes, and recovery.

Risks

• Risk

  Prototype behaviour may not meet the current acceptance outcomes.

Original source and prototype evidence

• discord: Authoritative clean-slate Scope recommendation.
• discord: Clean-slate Scope discussion 1.
• discord: Clean-slate Scope discussion 2.
• discord: Clean-slate Scope discussion 3.
• discord: Agreed eight-Epic portfolio and Feature decomposition.
• discord: Agreed eight-Epic portfolio and Feature decomposition continuation.
• discord: RootAtSkic directed publication of the agreed Scope update.

Prototype and discovery boundary

Existing application behaviour is discovery evidence only; it establishes no current Scope approval, implementation approval, acceptance, or release state.