AVIONICS SYSTEM ARCHITECTURE

The CAAS embodies the following architectural precepts:

• an Open System Architecture (OSA) using published and controlled interface definitions, such that its
hardware and software components can be replaced or upgraded with alternate components

• variability isolation to accommodate changes in the system over its life cycle, such that the impact of
change is isolated to the smallest system component

• use of layers and partitions with widely accepted interfaces to isolate system components

• redundant software using master/slave protocol where every application is resident on every box and
some applications are active on multiple boxes to support quality attributes such as availability and
safety

• use of application templates across applications, common software, and CoRE to support reusability,
modifiability, repeatability, and affordability

• use of commercial standards including ARINC 661 (cockpit display system interface standards), POSIX,
CORBA, IEEE P1386/P1386.1 (common mezzanine card families draft standards), OpenGL (graphical
interfaces standards), and DO 178B (software considerations for airborne systems) to enhance
portability, maintainability, and modifiability

• LynxOS-178 based on the flight-ready POSIX operating system (with standard POSIX API and Ada 95
support) to encapsulate and manage any interaction with the computing platform and provide DO-178B,
Level A design assurance Other features being supported include a high-integrity, ethernet local area
network (LAN) with COTS general-purpose processors, video processors, and graphics engines.

The architecture is highly redundant, containing both communication line and processor redundancy,
with well-defined fault detection schemes and failover philosophy.

The CAAS System Architecture:

The scaleable CAAS uses one Power PC 750 processor in each CDU and two Power PC 750 processors in
each MFD. The open system architecture is meant to simplify connectivity and support including the
ability to swap LRUs between platforms in the field. The use of this common avionics hardware and
software across the aircraft will reduce the logistics demands on aviation units and simplify training. And
the commonality of software and hardware components is expected to provide the special operations
forces a lower total life-cycle cost and lower costs for technology insertion and supportability. The
software of interest resides in the CDUs and MFDs. The GPPUs contain the digital map software. The
Armament System Processor Panel (ASPP) contains embedded software.

The system architecture includes the following elements:

• MFDs – These are general-purpose graphical display and processing units including two processors:
one display and one mission. There are four MFDs (and an optional fifth) on all aircraft except the MH-6
(which contains two). These MFDs are the primary means for displaying information to the crew. The
crew’s interaction with the MFD is through the bezel switches.

• CDUs – These are the primary data entry units for the system and contain a characteroriented display
and keyboard. They contain a general-purpose processor used for running CAAS software. There are
three CDUs on each aircraft except the MH-6 (which contains two). One CDU functions as the bus
controller and one as the backup bus controller for the MIL-STD-1553B busses.

• data concentrator units (DCUs) – This is a general-purpose interface control unit used for connecting
the CAAS system to devices that don’t comply with the MIL-STD-1553B. Interface types include discrete,
analog, ARINC 429, RS-422, and serial multiplex. There are two DCUs on each aircraft except the MH-6
(which doesn’t have any).

• ASPP – This unit is responsible for low-level control of weapons and management of the hardware
interfaces to those weapons. There is one on each MH-60 IDAP and MH-6 aircraft.

• GPPUs – These units are used primarily for video processing and provide digital video to the MFDs.
They also contain the digital map software that generates the digital map video for display on MFDs. In
addition, the GPPU contains the digital switch that serves as the full-duplex switch fabric and control for
the avionics system LAN (ASL).

• ASLs – Two ARINC-664-based ethernet LANs are used in the system. They are the primary means of
communications among the software elements of the CAAS. The networks are arranged as a set of
ethernet segments connecting each node on the network to the full-duplex switch fabric. Each network
segment is restricted to one user node and the switch connection, to eliminate collisions on the
network. The switch receives message traffic sent by each user node and routes it to the segments that
contain the nodes that are to receive the message. The network topology is a star.
• MIL-STD-1553B serial data bus - Two dual redundant 1553B busses are used to handle
communications between the CAAS software and the 1553B-compliant devices mounted on the aircraft.
One CDU acts as the bus controller, while a second acts as the backup bus controller for the networks.

Software Architecture:

The primary structural mechanism used by CAAS software is layering. Mission-related functionality lies,
for the most part, in an application layer that is the top layer in a software stack. The applications make
use of system services through an API. All access to lower level system capabilities is routed through this
API. System services communicate to hardware through a device driver layer. Hardware characteristics
are abstracted for all devices by the device driver layer.

The API and System Services layers shown in the diagram above are provided by the LynxOS-178, which
sits on top of the device drives for things like the 1553 bus and ARINC 429 Input/Output.

The LynxOS-178 kernel:

The LynxOS-178 kernel is the operating system kernel for the CAAS and handles resource management
in the system. Each processor contains a number of memory partitions, which are scheduled in
accordance with ARINC 653 using a static, time-sliced, priority-based, interruptible, cyclic scheduler.

The scheduler performs all dispatching of partitions and threads within partitions based on the schedule
that is currently active. Three schedules are supported: cold start, warm start, and normal operation.
The schedules are supplied from the Virtual Machine Configuration Table (VCT).

Memory management is handled mostly by the memory management unit (MMU), which is capable of
detecting memory violations and generating an exception in response. The kernel services the
exception, suspends the offender, and activates the Health Monitor (HM). The VCT specifies limits for
memory allocation to each partition. These limits are enforced by the MMU and kernel, preventing a
partition from accessing memory not allocated to it. Blocks of memory are allocated to partitions at
initialization time, and no further changes in memory allocation occur.

Applications:

The primary component identified for applications is the partition. A partition is a term tracing to the
operating system kernel, which recognizes a partition as the primary unit of resource allocation and
management. A partition is a container for a collection of lower level components including both
mission-related software components and infrastructure components.
Thirteen partitions are distributed among the MFDs and CDUs:
1. CDU display manager
2. MFD display manager
3. CDU input/output (I/O) manager
4. flight director
5. flight manager
6. system manager
7. mission sensor manager
8. communications manager
9. weapons manager
10. EICAS manager
11. tactical situation awareness
12. CDU MP VM0 (HM for CDU)
13. MFD MP VM0 (HM for MFD)