Helicopter HMIs: Managing risk with automatic code generation, standards, and simulation

Story

September 25, 2008

Robert Kopersiewich

Presagis

COTS suppliers are providing developers with the automated software tools needed for effective design of helicopter HMIs ? before the design is deployed in the cockpit.

Helicopter Human Machine Interfaces (HMIs) have changed dramatically since the first turbine helicopters, the Ka-225 and a modified Navy HTK-1, were introduced more than 50 years ago. What was initially comprised of mechanical fuel gauges and altimeters has been replaced with an integrated flight data system of computers and multifunction displays that provides the pilot with key navigational, weather, and other crucial flight information (Figure 1). Today, helicopter avionics continue to evolve at a rapid pace, increasing the complexity of their development.

Figure 1

(Click graphic to zoom by 2.3x)

Integrating next-generation displays and new information sources into pilot-friendly HMIs is not the only challenge faced by avionics developers today. Developers must also manage the project and consider development costs. When the turbine helicopter was introduced, only 5 percent of its cost was for avionics. Today, avionics account for approximately 60 percent of the aircraft costs.

Now that HMI development is more complex and costly, there is a greater risk of coding errors, project overruns, and design flaws. But with a little advanced planning and the right tools, helicopter developers can stay ahead of the curve and provide customers with the most user-friendly, sophisticated HMI possible without incurring huge development costs and risks. Advances in COTS software are providing avionics developers the opportunity to take advantage of software tools that automate processes, support industry standards, and provide a platform for effectively testing the design before it is deployed in the cockpit.

Reduce risks with automatic code generation

To save time and reduce the risk of project overruns, designers should pay close attention to how they approach low-level requirements, which indicate how to write the software at the coding level without any further instruction necessary. Examples of low-level testing include the coding of objects and logic. While these features can be manually developed, hand coding requires manual bug fixing and optimization, which can consume a lot of time at the project's outset. By using software with automatic code generation, low-level requirements are captured in the software's model and low-level testing is virtually eliminated. While high-level testing is still required, it is generally reduced because the code has been automatically generated and required little or no low-level testing. As the displays are created using a modeling tool, requirements are captured in early prototypes and reviews are completed early on. This can further reduce the need for high-level testing.

As the HMI moves from prototyping into production, developers must take extra care to reduce coding errors. Hand coding by nature can be unpredictable and might generate unexpected results and bugs with each iteration. Automatic code generation helps to avoid the revision of millions of lines of code when changes are made to a display - even late in the project or during the testing phase - by providing a repeatable process with a predictable outcome. For example, creating a simple blue box with a specific size using hand coding could be done in hundreds or even thousands of different ways. This increases the risk of error with the number of variations in code used across the project. To mitigate this risk, the automatic code generator will always generate the same code for the blue box in exactly the same manner, no matter how many times it is repeated.

Choosing to use tools with automatic code generation at the beginning of the project is crucial and will ultimately enhance productivity during the development process. With mandatory, safety-critical standards like DO-178B taking center stage in avionics certification, the ability to track and document HMI development is critical. The FAA requires that developers provide lengthy documentation tracking software development as part of the certification application process. This documentation can be manually created, but a code generator that is qualifiable to DO-178B comes with many certification documents and test cases to show that the HMI has already undergone significant testing to the levels required by the FAA. When a customer leverages automatic code generators qualifiable to DO-178B, they can take credit for much of the testing and documentation that has already been accomplished and reduce the time and cost of certification.

Cut costs with standardization

New avionics systems, display functions, and widgets combined with the management of hardware obsolescence during the lifetime of a helicopter can cause project overhead to skyrocket. To manage these costs, developers can opt to follow ARINC 661. ARINC 661 allows developers to access a standard set of widgets, which are objects such as symbols, pictures, panels, and buttons. These are the basic building blocks of a Definition File (DF) that will be displayed in an HMI. The DF contains pages or "layers," made up of different widgets that will be displayed on the Cockpit Display System (CDS). Using standardized widgets reduces the amount of time required to ramp-up on projects because it makes it very easy for a developer to understand how to develop new displays. Without a standard in place, developers have to rework the coding whenever a different combination of vendors is chosen to meet a variety of file format requirements. This standard set of preapproved building blocks gives a developer the flexibility to use systems from multiple vendors: The files follow a standard format and don't require data replication or additional coding. Finally, it is also possible to reuse large parts of a DF on a new project by modifying the visual appearance of widgets, eliminating the need to start from scratch every time.

Though it is not mandatory, industry leaders such as helicopter manufacturer AgustaWestland are benefiting from ARINC 661's guidelines. AgustaWestland selected the VAPS XT ARINC 661 module from Presagis because it allows the company to quickly develop concepts for the HMI and reduce risk by providing a future path for DO-178B certification.

Tools supporting ARINC 661 development can be used to develop the look and feel of a complete widget library without working on the actual hardware. These widgets can be created graphically, using the low-level building blocks that are provided with the tools, or through programming. Objects created through programming need to be coded from scratch using traditional software coding tools, but when they are created graphically using a modeling tool, there is no coding involved. Developers use modeling tools to select aspects such as lines, colors, and text from the user interface, and the tool automatically generates the code for the completed object. This supports quick changes to their appearance during an iterative development process without needing to modify or create a single line of code. To define behavior of objects, developers will then use state-charts, such as the one depicted in Figure 2, to select elements of the design to create triggers and actions inside the application logic. By using ARINC 661-supported software, the need to repeatedly hand code behaviors across multiple widgets is eliminated. Instead the state-chart logic can be applied to each instance of a customer object, saving time and eliminating the risk of human error.

Figure 2

(Click graphic to zoom by 2.5x)

Put the HMI to the test in a simulated environment

Before the HMI is deployed to the cockpit, it is crucial to test its functionality. No one wants to discover during pilot training that activating a combination of display functions in a specific sequence causes a critical system failure. No one wants to be forced back to the drawing board and have to repeat the entire development process either. Consequently, HMIs are evaluated on many criteria. For example, will the HMI allow pilots to act intuitively, helping them quickly make and execute the right decisions? In order to properly make this assessment, designers need to test the HMI in a simulated environment such as the one shown in Figure 3.

Figure 3

(Click graphic to zoom by 2.5x)

To ensure new HMIs will function as intended, they must be tested under a wide variety of conditions, such as brownouts, which occur when dust or sand in the air reduces in-flight visibility. By simulating a rich immersive environment, designers can test the HMI in a realistic 3D scenario that tests the ability of the HMI to process and present flight information. Creating a simulated environment for testing helps save money in the long run by allowing developers to see how the HMI functions before it is embedded into the cockpit. If anomalies such as alignment, usability, and performance issues are identified, an automatic code generator will become particularly handy, as it allows the developer to easily make changes and reiterate the process.

An advantage of using COTS tools for simulation and testing is that the software can be used across a multitude of platforms out-of-the-box. Avionics developers can take advantage of COTS tools to design HMIs and create the simulated environment for HMI testing. Using simulation at the very beginning stages of development to test prototype concepts and receive early feedback from end users, avionics developers can eliminate the risk of creating an HMI that pilots do not find intuitive. By leveraging a simulated environment, they can also put the final HMI through its paces and test its maximum threshold. With COTS simulation software, developers can test the HMI while the pilot flies different missions in a simulated virtual environment.

The end result: A sophisticated, pilot-friendly HMI

The helicopter cockpit has evolved from an electronic flight instrumentation system to an integrated flight data system. As a result, HMI development projects have increased in complexity, presenting unique challenges and risks, such as coding errors, project overruns, and design flaws. To mitigate these risks, avionics developers can tap into useful features - such as automatic code generation, support for industry standards, and simulation - incorporated by COTS suppliers that have broad access to the marketplace. This allows avionics developers to leverage tools that have already been proven across a wide number of systems, which means they can minimize the amount of time spent developing tools and focus on what they do best: developing effective, pilot-friendly HMIs.

Robert Kopersiewich is vice president, product and program management, at Presagis, where he oversees and directs the growth and trajectory of the Presagis product portfolio and business road map. With more than 15 years of experience identifying and addressing key market needs, Robert plays a key role in the future success of Presagis. In 2004, he was named director of product management at Engenuity Technologies. Prior to joining Engenuity, he worked for a number of leading companies in both the telecommunications and optical-disc industries. He can be contacted at [email protected].

Presagis
1-800-361-6424
www.presagis.com