Understanding ARINC 661 and its benefits in a certified environment
StoryOctober 06, 2010
Yannick Lefebvre
Presagis
The ARINC 661 avionics display standard has been in existence and evolving for close to a decade ? with its most recent iteration published earlier this year. Yannick examines the ARINC 661 architecture, its Cockpit Display System (CDS) and User Application (UA) components, the standard?s widget library ? and how they all relate to DO-178B certification.
The task of creating aircraft cockpit displays has grown increasingly difficult over the past decade due to certifications rules (DO-178B) being applied more widely on military programs – along with the constant drive to deliver on shorter deadlines. To make things even more complicated, many players in the industry use their own development methodologies with little to no guidelines on content other than the instructions of their developers and human factors engineers.
This lack of a standards-based approach led to the proliferation of monolithic applications, either developed internally or through the use of commercial tools. These applications always need to be recertified as a whole, no matter which type of change is made. Exchanging data between commercial tools is also usually difficult, making it a challenge for aircraft manufacturers to think about switching providers for a system during the life cycle of an aircraft – or to reuse display elements between projects that are built using different software architectures.
In the late ’90s, a committee of representatives from the industry was formed to address these concerns and put together a standard and flexible architecture for the creation of aircraft avionics which became ARINC Specification 661: Cockpit Display System Interfaces to User Systems. Today, ARINC 661 is used on programs such as the Airbus A380 and A400M, the Boeing 787 and the AgustaWestland Merlin Helicopter Upgrade. This standard has been used in the military realm since its inception, with its most recent iteration published earlier this year.
After learning about the ARINC 661 standard and its architecture, we’ll look at the Cockpit Display System (CDS), User Application (UA), and widgets of ARINC 661, along with the benefits they bring to the table – especially for projects that need to be certified.
ARINC 661 architecture overview
While cockpit display software has traditionally been written as self-contained executables that present information and render graphics based on internal data, rules, and logic, ARINC 661 introduces a clear separation between the code drawing the graphics and the code managing the logic and the position and state of all visual elements. These two components are the CDS and the UA.
Furthermore, ARINC 661 defines the CDS as a runtime interpreter capable of displaying one or more elements from a finite library of building blocks called widgets based on information contained in external layout files. Finally, ARINC 661 defines a standard communication protocol for the CDS and UA to exchange messages. Figure 1 shows the relation between the CDS and UA, along with their typical execution environments and the communications between these two applications. It also shows that more than one UA can communicate with a CDS. In that situation, each UA can be developed separately and is responsible for updating and reacting to events of a specific section of the display.
Figure 1: The major components in an ARINC 661 architecture: Cockpit Display System (CDS) and User Application (UA)
|
|
A direct benefit of this architecture is that updates to the display composition are done by creating new layout files instead of modifying code within a unified application. In a certified environment, this means that UA and CDS code does not need to be recompiled or recertified for visual layout changes such as repositioning or changing the visual attributes of display elements. The same benefit applies to changes to the logic flow of the application, which will only result in changes to a specific user application, leaving the CDS code base and other user applications unaffected.
Beyond isolation benefits, this approach also simplifies the distribution of application development between different teams within an organization or across subcontractors.
A closer look: CDS and UA
Looking closer at a typical ARINC 661 application execution flow, the CDS loads and displays widgets based on one or more layout files called Definition Files (DFs). Each DF contains one or more layers, which are hierarchical listings of all widgets that need to be loaded along with their initial parameters such as position, size, and visibility. They are natively stored in a binary format that is loaded into the CDS application at runtime. The standard also defines an XML interchange format to facilitate DF inspection, revision control, and sharing.
Going down a level, the physical display attached to the CDS is divided into one or more subsections, simply called windows, which can each render one or more layers. These windows cannot have any overlaps and will stack the designated layers to create the final result that will be shown to the pilot or operator on-screen. Figure 2 illustrates this hierarchy.
Figure 2: CDS visual hierarchy
|
|
At runtime, the CDS handles pilot inputs and determines if these interactions can be handled locally (for example, the CheckButton needs to be highlighted when the cursor is placed over the widget) and/or if they should be transmitted to a UA (for example, that the CheckButton is pressed). In the latter case, an event is sent to the appropriate UA to determine a response based on the current system state and the event type. The UA(s) will also typically be sending a steady stream of messages to the CDS to update the position of all screen elements that are presenting information to the pilot.
When it comes to certification, this detailed display architecture greatly simplifies the creation of high- and low-level requirements. The use of a standard XML interchange format for Definition Files also gives flexibility for content developers to use CDS systems from multiple vendors as they see fit since work can be loaded in any ARINC 661 compliant CDS. It is also possible to reuse large parts of a Definition File and a system’s User Application(s) on a new project by only changing the visual appearance of widgets within the CDS library.
Standard widget library
Instead of being bound to a specific tool’s application-building components, or creating a custom component architecture internally for a project, the ARINC 661 Specification introduced 42 widgets that could be used to create displays. This number went up to 50 with the first update to the standard, to 57 with supplement 2, to 65 in revision 3 and to 68 with its most recent incarnation published earlier this year.
Widgets vary in complexity from basic graphical elements such as the GpLine and GpRectangle widgets to complex objects such as the MapHorz widget, which displays maps from various data sources. There are also some widgets that do not have any visual representation that are used to group other elements together as well as apply transformations on them. An example in this last category is the MutuallyExclusiveContainer widget that groups multiple elements under a single parent but only displays one of its immediate children at a time.
While ARINC 661 describes how widgets should function and what their parameters are, it does not define their visual appearance. This gives full liberty to the display manufacturers to implement their own look and feel for a given project. There is also a provision in the standard to allow developers to create custom widgets with tailored functionality and parameters that still follow general widget creation patterns.
Having a standard set of widgets to develop a display makes it easy for a developer to become familiar with the ARINC 661 standard and to understand quickly how to develop new displays. Also, similar to the overall ARINC 661 architecture tying directly into high-level requirements, having a standard set of widgets with well-documented functionality helps accelerate the documentation of low-level detailed functional requirements for a certified project.
The future of ARINC 661
While the implementation of this architecture might seem a bit daunting – considering the need to put in place a compliant CDS runtime software architecture, a functional widget library that adheres to the specification, and tools to facilitate the creation of Definition Files and their output to standard binary files – it should be noted that COTS tools are available to provide these capabilities out of the box. In some cases, these tools are even qualified development tools that can generate qualifiable code under DO-178B. After seeing a few large commercial aircrafts lead the way, many programs, both commercial and military, are considering or have already adopted ARINC 661 for their upcoming projects, ensuring the success of this standard.
Yannick Lefebvre is a senior application developer at Presagis. With a background in computer sciences and 13 years of experience in modeling and simulation, Yannick has provided counsel on hundreds of simulation and embedded display programs globally and is considered an expert in the industry. He can be reached at [email protected].
Presagis 514-341-3874 www.presagis.com
