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


Algorithmic requirements


e.g. communication with sensors
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.