Common Avionics Architecture System (CAAS)

Related Articles

Aluminum Alloys: The Timeless Value in Aerospace Technology and Market Trends

7 days ago

Soaring Into the Future: Hydrogen Hybrids Revolutionizing Commercial Aviation

1 week ago

Enhancing Aviation Safety and Efficiency: A Deep Dive into Aircraft Maintenance, Repair, and Overhaul (MRO) Technology and Market Trends

1 week ago

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.

 

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

 

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.

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

 

Common Avionics Architecture System (CAAS)

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.

 

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.

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