Common Avionics Architecture System (CAAS)

idstch.com/military/air/avionics-architecture-from-common-avionics-architecture-system-caas-to-open-systems-
architecture-approach

Related Articles

Navigating the API Usage Landscape: Challenges and AI-Based Solutions

Guardians of the Cloud: Protecting Against Cyber Attacks on Cloud Services

The Sky’s the Limit: The Evolution, Challenges, Emerging Technologies, and
Architecture of In-Flight Entertainment Systems
Avionics are the electronic systems used on aircraft. Aircraft avionics is the most crucial
component of aircraft systems and helps in providing various operational and virtual
information in-flight and on the ground. The avionics system receives data from the air traffic
management system and feeds this information to the pilot to select an approach path to the
destination.

Aerospace avionics include navigation, communication, and surveillance systems along with
other electrical systems and in-flight entertainment system. Air navigation is the
determination of position and direction on or above the surface of the Earth. Avionics can
use satellite navigation systems (such as GPS and WAAS), INS( inertial navigation system),
ground-based radio navigation systems (such as VOR or LORAN), or any combination
thereof.

Software architecture defines the components that software will have, including the
functionality that each component will achieve, and the relationships between components,
specifically data flows and control flows. Because software architecture is a major
determinant of software quality, it follows that software architecture is critical to the quality of
any software-intensive system.

Your architectural decisions can have a significant impact on your project life cycle, not only
for implementation but also for verification, particularly considering data coupling and control
coupling. Decisions you make in your software architecture will impact the verification effort
needed for DO-178C compliance.

1/10
Integrated modular avionics
The integrated modular avionics concept proposes an integrated architecture with application
software portable across an assembly of common hardware modules. It has been used in
fourth generation jet fighters and the latest generation of airliners.

Integrated modular avionics (IMA) are real-time computer network airborne systems. This
network consists of a number of computing modules capable of supporting numerous
applications of differing criticality levels.

In opposition to traditional federated architectures, the IMA concept proposes an integrated

architecture with application software portable across an assembly of common hardware
modules. An IMA architecture imposes multiple requirements on the underlying operating
system.

IMA modularity simplifies the development process of avionics software:

As the structure of the modules network is unified, it is mandatory to use a common API to
access the hardware and network resources, thus simplifying the hardware and software
integration.
IMA concept also allows the Application developers to focus on the Application layer,
reducing the risk of faults in the lower-level software layers.

As modules often share an extensive part of their hardware and lower-level software
architecture, maintenance of the modules is easier than with previous specific architectures.

Applications can be reconfigured on spare modules if the primary module that supports them
is detected faulty during operations, increasing the overall availability of the avionics
functions.
Communication between the modules can use an internal high speed Computer bus, or can
share an external network, such as ARINC 429 or ARINC 664 (part 7).

However, much complexity is added to the systems, which thus require novel design and
verification approaches since applications with different criticality levels share hardware and
software resources such as CPU and network schedules, memory, inputs and outputs.
Partitioning is generally used in order to help segregate mixed criticality applications and
thus ease the verification process.

ARINC 650 and ARINC 651 provide general purpose hardware and software standards used
in an IMA architecture. However, parts of the API involved in an IMA network has been
standardized, such as: ARINC 653 for the software avionics partitioning constraints to the
underlying Real-time operating system (RTOS), and the associated API

2/10
The Common Avionics Architecture System (CAAS) Avionics Management System,
developed by Rockwell Collins, integrates multiple communications, navigation and mission
subsystems through its flexible Flight2™ open systems architecture design.

CAAS derives from the Air Force’s KC-135 GATM (Global Air Traffic Management) program
launched in 1997. This technology also leverages the commercial Boeing 767, corporate
Challenger 300 and the Navy’s P-3 CNS/ATM (communication, navigation, surveillance/air
traffic management) programs, among others.

CAAS makes 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

The CAAS System Architecture

CAAS comprises four subsystems: 6-by-8-inch, portrait-oriented, color, multifunction displays

(MFDs); control display units (CDUs); general-purpose processing units (GPPUs); and data
concentrator units (DCUs). Rockwell Collins provides most, but not all, of CAAS. The system
incorporates the LynuxWorks’ LynxOS-178 real-time operating system. Harris Corp. licenses
its digital map generator and database, which is hosted in the GPPU.

Each night vision-compatible MFD incorporates two independent PowerPC 500-MHz

processors; one is an expandable, commercial 3D graphics card with open graphics
language, and the other is a general-purpose processor.

Software-controlled, bezel-mounted, push-button keys border the liquid crystal displays

(LCDs), providing display format control and non-alphanumeric crew management. The top
and bottom keys control the display modes, while the keys along the side control the
“submodes,” or the information present on the display, according to Dan Toy, marketing
manager for Army programs at Collins. The pilot also can make adjustments by moving a
cursor that is governed by a “coolie hat” on the helicopter’s cyclic control.

The CAAS system architecture is depicted in Figure. 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.

3/10
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. The MFDs can provide split-screen imagery, for example, a forward
looking infrared (FLIR) image above or below a hover-guidance display.

• 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).

The GPPU comprises two modules: a processor switch module for the Ethernet LAN and a
video processing module. The latter module accepts digital video inputs and multiplexes the
signals to six independent digital video outputs. Both modules include a common processor,
graphics engine and digital video output.

4/10
CDUs – These are the primary data entry units for the system and contain a character-
oriented display and keyboard. They contain a general-purpose processor used for running
CAAS software.

The CDU, with a single general-purpose processor and 3U cPCI cards, includes a color
alphanumeric LCD and a keyboard for entering flight, navigation, mission and systems
information.

There are three CDUs on each aircraft except the MH-6 (which contains two). The two CDUs
on board the aircraft also operate as the primary and backup bus controllers for the dual-
redundant Mil-Std-1553 data buses.

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.

The DCU’s task is to take in analog inputs from the engines, transmissions, fuel system, etc.,
and output the data via a digital Mil-Std-1553 bus to the control display unit, where it is
distributed throughout the system on the Ethernet LAN. Also run on a 3U cPCI card, the
DCU has interfaces for ARINC 429 and RS-422, as well as 1553, for commercial standard
connectivity and integration.

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.
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 second acts as the backup bus
controller for the networks.

CAAS is 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. 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

5/10
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.

Flexibility

To explain CAAS’ flexibility, both Army and Rockwell Collins officials compare the system to
an office environment in which all computers are linked by an intranet, yet each computer
can be exchanged or upgraded without impacting the others. CAAS operating software is
partitioned, allowing multiple applications on the same processing resources, with no chance
of interference. Applications are comparable in all platforms, allowing “up to 90 percent reuse
of the software code,” says Flesner.

The source code for CAAS-a combination of ADA, C, C++ and Java-is nonproprietary. DoD
can use the code freely and share it with third parties that are working on U.S. military
programs. Flesner says Collins will deliver a tool kit that allows DoD to modify and further
develop the code.

A 100 base T Ethernet local area network (LAN) distributes data among all onboard
processors. This free flow of information gives CAAS extensive mission management
capability, including:

Flight management to take care of all tactical flight planning;

Performance management, automatically accounting for fuel load, weight and balance,
flight conditions, etc.;
Integrated navigation management of Doppler, GPS/inertial nav, VOR/ILS, ADF,
TACAN and radio altimeter;
Integrated communications and identification management;
Sensor management of terrain-following/terrain avoidance radar, forward looking
infrared (FLIR), weather radar, Stormscope and aircraft survivability equipment;
Avionics systems management, showing status and including built-in test equipment,
data recording, alerts and aircraft configuration; and
On the Army’s two armed, CAAS-equipped helicopters, the MH-60L DAP and ARH-
70A, weapons management of such systems as the Hellfire air-to-ground missile,
Stinger air-to-air missile, rockets and guns, and accommodation for a monocle head-up
display (monoHUD).

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.

6/10
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.

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 applications reside in LynxOS-178 partitions, which are created at load time and cannot
access memory in the other partitions. Each partition receives a strict cycle of processor
time: unused time within a partition’s cycle is spare and remains unused. If a processor
overruns its time, a fault monitor detects the occurrence and can either cause the partition to
fail or allow it to restart where it left off on the next cycle.

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).

The applications can execute as a number of POSIX threads within a partition. All
communications between partitions takes place through calls to LynxOS-178 and the
Ethernet network. The goal is to have a “plug and play” architecture with respect to
applications and processors.

7/10
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.

Partition Model
The internal structure of partitions provides an environment in which the application
functionality lives.

The application shell provides a number of component types and component

implementations
for use by the applications. Some of these component types are extended or
completed by developers of the partition—that is, the component type is intended as an
abstraction that is instantiated for use. Some components are used as is; their
implementation
is provided as part of the shell.

Four of the components (i.e., exec_main, lru, health monitor, and cross-side primary control)
provide essential services to the application, which performs the appropriate avionics
functionality.

The CoRE Shell is a collection of infrastructure components that supports the application
Computer Software Configuration Item (CSCI). This shell is a set of common reusable
components developed by the contractor for use on multiple programs. It contains some

8/10
basic
infrastructure services needed by avionics systems.

Startup and Operation

For Army pilots, particularly in the 160th, preparedness and quickness to execute a mission
are paramount. Before taking off in a CAAS-equipped helicopter, the pilot and mission
planning team inputs data on PCMCIA cards, which are pertinent to the mission. When the
pilot enters the aircraft, instead of “fat fingering” a keyboard to input data, he simply inserts
the cards.

“Within a minute and a half at most, he will load all the radio presets, all the navigation
presets, all of the waypoints, all of his flight plan, all the weapons information, his “friendlies”
or other assets, such as a UAV [unmanned air vehicle], reconnaissance aircraft or ground
system-all he needs to get the mission done,” Billig explains. “And he can start his check list
while all of this is loading.” SOAR helicopters have aerial refueling capability, and
rendezvous with tanker aircraft also is preprogrammed.

The pilot can review the inputted data by scrolling through pages on his CDU, or he can view
an entire page on the MFD. He can customize the pages, using either the CDU keyboard or
cursor control. Because CAAS can provide many pages of data, Collins created six
configurable mission pages, broken down to present the most critical information for the
flight.

With critical data reviewed, the pilot enters the startup procedure and monitors progress on
the instrumentation display and, perhaps, the warning cautionary grid on another screen. He
can call up synoptic displays that show oil pressure and temperature and that include
representations of the engine, input modules of the engine to the gearboxes, the main
gearbox, transitional gearbox and tail rotor gearbox.

CAAS is performance-based, so it “knows the aircraft, the fuel on board and the weight,”
says Billig. “It evaluates the data and will tell the pilot what he can and cannot do in terms of
aircraft performance.” If, for example, the pilot has an insufficient fuel supply, CAAS software
will automatically issue an alert on the MFD. Multiple cautions are presented in a prioritized
list.

Taking a next step with CAAS, Collins is proposing the extended use of the terrain database
to produce synthetic vision imagery, a technology the company is making available for the
corporate aircraft market.

Collins engineers working on synthetic vision have come up with several options. For
instance, the lab has developed a synthetic vision system that presents both an egocentric
view (out the cockpit windscreen) and exocentric view (from behind and slightly to one side
of the aircraft), also called the “wingman’s view.” The lab also has come up with the option of

9/10
integrating the FLIR imagery in a window within synthetic vision. By correlating, or blending,
the terrain data with the real-time FLIR imagery, pilots can feel more assured of a safe flight
heading. ”

References and Resources also include:

https://www.aviationtoday.com/2006/10/01/caas-past-present-and-future/

https://resources.sei.cmu.edu/asset_files/technicalreport/2005_005_001_14615.pdf

10/10