General Avionics Software Specification Paper by: C. Douglass Locke, David R. Vogel, Lee Lucas, John B. Goodenough Presented by: Jeremy Erickson August 27, 2010

System Structure - Overview Main focus of paper

Head-Up Display The Head-Up Display (HUD) is imposed on the pilot's view out the cockpit. “Reticles” are crosshairs for potential targets Image source: Wikipedia

Multi-Purpose Display (MPD) Shows anything else needed Normally a map of tactical situation, but has other modes as well.

Keyset This is just the set of keys the aircrew uses to interact with the computer for things like target selection.

Hands-On Throttle and Stick These are actual hardware controls used to maneuver the plane, which could function even if the mission computer fails.

Stores Stores are “items fastened to racks underneath the aircraft” In practice, stores we care about are weapons such as bombs. We have to keep track of how many are left.

Display Processor This processor does low-level stuff to interact with various display hardware. It's not the focus of this paper, so we don't really know what its tasks look like.

Inertial Navigation System Sensor system that provides information about position and velocity Also provides reference data for attitude and heading May have RT tasks, but they're not talked about in this paper.

Air Data Computer (ADC) Barometric altimeter and dynamic and static pressure data Again, outside the scope of this paper

Stores Management System (SMS) This computer does all the low-level interaction with the weapons and senses the status. Once again out of scope of the paper

Mission Control Computer (MCC) Main focus of paper that does “navigation, sensor control, weapons targeting and release, controls and displays management, and fault isolation test.” More on this later...

Radar The main radar component is used to track targets the plane may attack.

Radar Altimeter (RALT) The radar altimeter indicates height above the ground

Radar Warning Receiver (RWR) This component warns when we are scanned by an enemy radar

Communication All systems communicate over a single serial bus. Communication with the MCC is done entirely using polling, not interrupts. Interrupts may exist within the MCC, however.

Timing All tasks are executed periodically. Aperiodic work can happen, but is executed by a periodic task (we would call this a server or a container). Some tasks may not always run. The plane will have different modes of operation based on what it is doing (e.g. takeoff vs. combat), but the paper only considers one mode. Where do timing requirements come from?

Three Types of Timing Requirements Hardware requirements e.g. communication with sensors Algorithmic requirements e.g. numerical stability for weapon delivery computations Human factors e.g. making display updates appear “instantaneous”

Specific Tasks Next the paper gets into a “deep dive” with specific tasks in the MCC. We don't have time to discuss all the details, but we'll discuss the basic categories of tasks.

Navigation These tasks update aircraft position and motion information based on sensors or aircrew input, and provide steering cues to the aircrew. This category has two periodic tasks which always run.

Radar Control Radar can can operate in ground map, ground search, or single-target track modes, and radar control behaves appropriately. Different tasks are operative in each mode, and the paper ignores ground map mode since it's not used during attack. A periodic task for each of tracking and searching, and a user-triggered task for initiating tracking.

Targeting Targeting must be done in several stages: A target must be designated and then confirmed. Later, the target must be tracked and in some cases “sweetened” (improved). Several tasks take care of these functions. Only tracking is periodic; the others are triggered by the user or by previous task completion.

Weapon Control Weapon control involves several stages. The aircrew selects which weapon(s) to fire, how many, and at what intervals. These are implemented with user-trigggered tasks. Weapon trajectory is computed with a periodic task but can be reinitiated with an aperiodic task (not sure on trigger). The weapons are released by a set of scheduled tasks that could be periodic with varying periods

Controls and Displays Both the HUD and the MPD displays need to be updated. The relevant tasks are typically periodic. Various components must accept user input. These are generally user-trigged tasks.

RWR Control The Radar Warning Receiver must be programmed with specific frequencies it is supposed to care about. I'm not clear why the task to accept input would be periodic – I'm suspecting a typo in the page 29 table. I believe both tasks are user-triggered, with the RWR programming done once the input has been processed by the input task.

RWR Threat Response The MCC must poll the RWR to determine if there are any relevant threats. This is done with a periodic task. When there is a threat, a one-shot job does the actual response, which is just updating the display.

Built-In-Test (BIT) The Built-In-Test is the functionality of testing the hardware components. One task periodically performs standard tests. When a failure happens, a warning must be produced. The “Initiated BIT” test is when the operator requests a specific, non-standard test.

Utilization Exceeds 1 The total utilization of the system exceeds 1, so the system is not schedulable! However, there are two reasons this isn't actually a problem: It isn't actually possible for all the tasks to run at once. Priorities are given which specify what work can be shed if the utilization ever does exceed 1.