Data-Based Paradigm for Rapid Development of Advanced Avionics Displays

The above process can be repeated for all elements within the HMI. The logical conditions can include logic that executes based on user-input events. The actions resulting from logic can include calls to external functions, allowing the developer to specify the behavior of the system based on its inputs. When the specification is complete, it can be reviewed and tested. At this point, the model represents the low-level requirements of the HMI, and it is ready to be moved to the next stages of the process including testing and deployment in an open-architecture HMI system.

Data Format

The data format is the key to an open-architecture HMI solution. Because of the high level of dynamics, the HMI database format must represent more that just geometry; it must have logical and behavioral representations, as created during the model-based development phase. In addition to fully representing the HMI definition, the data format must also allow for efficient run-time processing of the HMI to meet the goals of an efficient open-architecture solution. A data format that merely echoes the model will require too much extensive run-time optimization to be effectively deployed in a limited embedded system.

The solution must allow for the equivalent of a compilation step while retaining the data-driven nature demanded by open architecture and certification. To realize the goals of our system, we designed a database format, called the HMI Specification Language (HSL). HSL is an efficient, compact, HMI representation format that captures geometry, logic, and user interactivity in a data-driven format. A graphical view of HSL is shown in Figure 3.

Run-Time Integration

We implemented the run-time system, or HSL Rendering Library (HRL), to handle the task of rendering the HMI geometry and logic, maintaining the value of data inputs, and managing user interaction.