The ARINC 661 Standards for Avionics Cockpit Display development have been in use by the industry for over 23 years, with the first release dating back to 2001. From its initial usage with the Airbus A380 it has grown to be used across most new commercial aircraft and many military projects globally. It has been proven in the real world and allowed developers and integrators to develop complex and interactive systems using a non-proprietary method.
However, even with the success of ARINC 661 internationally there has been confusion when people start to implement a system or perform integration with existing environments. There are implementation details that are outside the scope of the standard or need to be agreed when working with different suppliers to allow successful integration. With the introduction of the new ARINC 661 Part 2 standard the level of confusion for casual or new users has increased across the industry. To understand what the purpose of and usage of ARINC 661 it helps to understand the reasons why ARINC 661 was introduced, and the history of the cockpit displays.
Avionics display background:
Glass Cockpits started to appear in service with military aircraft in late 1960s and early 1970s which replaced the “steam powered” dials and gauges. These digital displays were often just a digital replication of existing instruments, but this then moved to more electronic flight instruments and systems which allowed the removal of many other existing gauges and the need for additional people in the cockpit (flight deck engineers) The evolution of commercial flight deck introduced multiple large display systems with the need to interact with these systems by use of keyboards, pointing devices such as trackpads and even touchscreens which added another layer of complexity for development of systems.
The need for standards:
The complexity and number of the systems that pilots must interact with has grown greatly over the years. Originally sub-systems that needed to present data to pilot and be interacted with were tightly coupled via proprietary interfaces or definitions. Any change to a display layout or information presented required the display computer to have code modified and additional data added to the display interface message protocols.
This lack of a standards-based approach led to the proliferation of monolithic applications, either developed internally or via suppliers. These applications always need to be recertified as a whole, no matter which type of change was made. Exchanging data between suppliers was 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.
The challenge of sharing a screen would often make this set of proprietary message structures complex and unique to the aircraft. Any supplier or subsystem that interfaced to the display would need clearly defined interfaces. For the simple example shown this would mean defining all parameters that are required to be updated on the display by each subsystem. This leads to a detailed set of specification documents with information relating to the display such as structures, sequencing byte order etc . An alternative approach to proprietary messaging was to allow systems to take over parts of the display and issue graphics commands directly. This introduced additional overheads for development and could mean the graphics looked inconsistent without everybody using the same graphics components. This would then require additional checks, control software, requirements and guidelines to be undertaken as part of development which added to the cost and possible error.
Introducing the ARINC 661 Standards
The ARINC 661 Standard original need and intention can be summarized as: Reduce cost of updates and new features, Support managing hardware obsolescence, introduce interactivity to cockpit in a standardized Human Machine Interface (HMI).
– To achieve this the original architecture defined three major parts.
– Cockpit Display System that renders graphics and allows user interaction.
– A Binary file that defines what graphics are shown and the layout of screen.
User Application that sends and receives data from the CDS controlling information being displayed on screen and what user interaction.
In addition to the architecture separation of graphics from systems the standard defines a set of widgets (push button, check button, touch area, graphic primitives etc.) The widgets are not described how they look & feel (colours, font type, shape, modes etc) but what events they generate and what data they can receive from external systems. ARINC 661 describes how widgets should function and what their parameters are, not defining their visual appearance. This gives full freedom to the display manufacturers to implement their own look and feel for a given project. There is a provision in the standard to allow developers to create custom widgets with tailored functionality and parameters that still follow general widget creation patterns.
In the first release of the standard, there were 42 widgets that could be used to create displays. This number went up to 50 with the first update to the standard, 57 with supplement 2, increasing to 65 in supplement 3 and continued to grow with each update. As of Supplement 9 there are now 120 Widgets including 3D Maps, Touch and Gesture Management along with the more traditional Push Buttons and Text Labels.
The graphics system does not have any knowledge of the meaning of the data that is sent but only what needs to change on the display. For example, instead of sending a proprietary message that defined “Airspeed” the User Application sends a generic ARINC 661 Message which controls the widget on the screen that is responsible for showing the Airspeed data. The benefit this brings is that if more information or items need to be added there is no need to change the message structures or update code on the Display System.
The standard clearly defines the message protocol how to control the widgets on the screen but does not define how the messages are transmitted from the systems that want to control graphics. Many new users assume that the standard mandates a transmission medium, but this is not the case as this would reduce the flexibility of developers to build systems using different technology and architectures. What the standard is clear on is that whatever transmission mechanism is used must be reliable and all messages received in correct order. This means that developers when integrating need to use transmission methods to ensure that this requirement is met. For an ARINC 653 system using APEX channels between partitions this requirement is met without additional management, however if a developer wishes to use UDP Messages they would need to implement methods that ensure messages are not lost and are in correct sequence.
Originally the ARINC 661 standard focused on the communication protocol and the layout of the graphics on screen with a predefined appearance. In 2015 a requirement to have a standard way to define the physical look and feel of graphics was brought to the ARINC standards committee by avionics vendors and airframers. This was wanted to manage specifications, define new widgets and to be able to re-use from one aircraft to another. The request for having this as a standard was approved and work on a new ARINC 661 Standard began. The existing ARINC 661 Specification was relabeled as Part 1 and the new complementary standard labeled Part 2. Both standards sit under the generic ARINC 661 Cockpit Display Standard and are separate documents with parallel development and evolution life cycle. The first formal release of new Part 2 standard appeared in 2020 and coincided with the Part 1 supplement 8 release.
There has been a level of confusion due to the shared name. Both the Part 1 and Part 2 standards have continued to develop and evolve with the committee releasing both specifications in parallel.
The need for Part 2 Standard was driven by a need for clearly defining the appearance of the widget appearance without textual descriptions. Often textual documents can be ambiguous with the assumptions on what is meant. The simple request and description of asking for a picture of a “football” to be shown would be recognized differently by a person in Europe and in North America. New input control devices and the want to define user centric natural interaction means that more complex modeling of logic also meant that textual was no longer suitable. As a result, of these needs the Part 2 standard defined a formal language to define the Look and Behaviour of UI Objects.
Part 2 Standard Language for modelling Avionics HMI
The semantics of the modelling language defines 3 key areas.
– Interfaces
– Representation
– Behaviour
The User Interface (UI) markup language syntax is expressed as an XML notation model. This model is designed to be executed in a standard way so that all users of the model see the same behavior and appearance. One of the major benefits of using Part 2 to define graphics is that a single definition model can be used through the lifecycle without need to re-express in multiple documents, tools or code. A model that starts as a prototype can be evolved to become a formal specification and transcoded to a DO178C Design model. This allows fast iterations and try out new user experience. Currently unlike Part 1 which has Binary and XML syntax the Part 2 standard does not define how this model would be deployed to an embedded platform.
The future of ARINC 661
ARINC 661 is still being developed and extended with both Part 1 and Part 2. The standards committee has very active membership and involvement from industry supporting and is not showing any slowdown to the updates and improvements. With Part 1 generally supporting backwards compatibility of data files the evolution and improvements in standard are designed to ensure that integration with newer versions does not impact all systems on aircraft.
With recent inclusion of 3D widgets in Part 1 and the formalisation of scripting language in Part 2 the ARINC 661 standard is keeping pace with the technical and usage needs of the industry. Currently the ARINC 661 Committee are on target to provide new functionality in Part 1 and Part 2 in 2026. Key areas of the standard under development at present is management of screens and flight decks, along with formally providing mappings of Part 2 definitions for Part 1 widgets.
While the implementation of ARINC 661 architecture in systems did originally look complicated the benefits of easier upgrades and an open standards-based approach are driving more projects to adopt it. With its inclusion in the FACE standard as part of safety critical profile for graphics the number of aircraft with an ARINC 661 system on board is growing rapidly especially in non-commercial aircraft. ARINC 661 looks like it has a healthy future with at present no other standard providing the depth and flexibility for HMI development in the aerospace domain.
By Matt Jackson
Technical Product Manager HMI and Embedded Systems
PACE Aerospace & IT
Member of ARINC 661 Committee