See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/354007841

Avionics Display for Two-Seated Aircraft Using OpenGL

Chapter · January 2022

DOI: 10.1007/978-981-16-2674-6_20

CITATION READS

1 167

4 authors, including:

Dr Anand Govindaraj Manju Nanda

CSIR National Aerospace Laboratories National Aerospace Laboratories
17 PUBLICATIONS 7 CITATIONS 48 PUBLICATIONS 66 CITATIONS

SEE PROFILE SEE PROFILE

Jayanthi Jagannathan
National Aerospace Laboratories
33 PUBLICATIONS 47 CITATIONS

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

MPPT ALGORITHM BASED CONVENTIONAL POWER CONSUMPTION REDUCTION WITH A THERMOELECTRIC GENERATOR View project

Integrated Formal Model Based Framework View project

All content following this page was uploaded by Dr Anand Govindaraj on 30 August 2022.

The user has requested enhancement of the downloaded file.

Model-Based Code Generation
for Avionics Display Graphics

Lovin K. Jose, Manju Nanda, S. Poonam Patil, and G. Anand

Abstract Avionics display HMI developers often deal with the problem of devel-
oping display graphics for deploying it on to a simulator and then re-coding the
same display graphics for the final environment. This type of re-development makes
it difficult to make any future changes in display design and functionality. This
paper describes a model-based approach for target-independent avionics display
graphics development and its implementation on two different embedded platforms.
This paper describes a model-based approach for designing avionics display using
the SCADE Display tool for the development of Graphical User Interface (GUI),
SCADE Suite tool for the development of input processing logic to drive Primary
Flight Display (PFD).

Keywords OpenGL SC · SCADE suite · Simulator display · PFD · Human

Machine Interface (HMI)

1 Introduction

The displays used in aircraft play the key role in HMI, which enhances the pilot’s
interaction with the aircraft’s control system. The application software for displays
is initially developed for an aircraft simulator and if it satisfies the requirements, it
will be installed on the target embedded platform. This is the procedure followed in
developing software for airborne systems. Since the transition of code from the simu-
lator to the actual embedded target requires codes to be re-written, the conventional
method of manual coding is a time-consuming task. Here comes the significance of
the model-based approach.

L. K. Jose (B) · M. Nanda · S. Poonam Patil · G. Anand

Aerospace Software & Systems Division, CSIR-NAL, Bangalore, India
M. Nanda
e-mail: manjun@nal.res.in
G. Anand
e-mail: g.anand777@nal.res.in

© The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2022 247
S. Chandramohan et al. (eds.), Artificial Intelligence and Evolutionary Computations
in Engineering Systems, Advances in Intelligent Systems and Computing 1361,
https://doi.org/10.1007/978-981-16-2674-6_19
248 L. K. Jose et al.

Safety–Critical Application Development Environment (SCADE) Display [1, 2],

a model-based design tool used in the design and development of avionics display
GUI. SCADE Display IDE generates OpenGL SC (Safety Critical) [3] Application
Program Interface (API) based code for GUI and SCADE Suite [4] generates code
that processes the logic for controlling the GUI in C and ADA languages. This
tool generates DO 178B/C certifiable code. DO 178B/C is the set of guidelines for
software considerations in airborne systems and equipment certification. SCADE is
also capable of generating documents that play an important role in the certification
phase. This tool generates a target-independent code which makes the same code
usable on the simulator and the actual embedded target.
A. Conventional Methodology

Before the model-based approach for designing was introduced, the software for
display applications was manually coded. This was a time-consuming task as each
line of code has to be manually written. Another overhead of the conventional method
is that the program has different behavior on the target. If the code has to be ported
from a simulator to the target embedded system, the codes should be rewritten. This
makes the conventional method challenging and time-consuming.
B. Proposed Methodology

Model-based design and development can be used to overcome the drawbacks of

the conventional methods [4]. SCADE is a tool used in the model-based design and
development of a safety–critical system. SCADE has IDEs called Display and Suite.
The Display tool enables the user to generate OpenGL SC-based C or ADA code.
SCADE Suite is also a model-based designing tool that is used to generate code
that handles the logic required to draw graphics. The tool takes off the overheads of
rewriting the code when code has to be transferred from a simulator to the actual
target. This reduces the development time required for the project. The model-based
approach also has an in-built simulator that can be used to verify the behavior of the
models that have been developed. One of the other problems faced by the conventional
method is that the behavior of the software changes when integrated on an actual
target. The model-based approach provides a solution for this as it generates target-
independent code. The code generated for a simulator can be used on the target
embedded system.
C. Comparison

In the conventional method, designing is a labor-intensive process. The requirements

have to be finalized. After having requirements, the designing phase starts. Once
designed, the code is downloaded to the target and then verifies its behavior. The
model-based approach in contrast to the conventional method is model-intensive.
Each model can be tested individually with simulation and can be refined at the
designing stage. This makes the model-based approach for design and development
efficient. In manual coding, the code has to be designed and then downloaded to the
Model-Based Code Generation for Avionics Display Graphics 249

Fig. 1 Comparison of the waterfall model for the conventional approach (on left) and V-model
SDLC for Model-based approach (on right)

target to check for the behavior of the code on the target. In manual coding, for future
modifications, the entire code has to be first understood and then modifications have
to be done. This is a tedious process as the developers have to go through the SDLC
again to accomplish their goals. In model-based design, the model can be easily
understood and can be easily modified. The model can be so refined that the chances
of failure are comparatively lower than that of manually written code. Figure 1 shows
the difference between the water flow model used in the conventional method and
the V-model flow used in model-based development.

2 Avionics Display Software development and Integration

Approach

The SCADE Display is the IDE used for developing the GUI. This helps in gener-
ating GUI with limited knowledge in OpenGL SC. There are primitives in the tool
that is capable of generating code. The IDE has a ‘drag and drops’ environment
where the user can drag and drop primitives that have been defined by the tool. The
primitives have plugins called a plug, where the user can assign variables to control
the symbology. Each symbology has a plug called visible. Here the user can define a
variable to control the visibility of that particular symbol. The data type of visibility
plug is Boolean. That is the variable can either have a value ‘TRUE’ or ‘FALSE’.
If the value of this variable is ‘TRUE’, then the symbology will be displayed. If the
value of the variable is ‘FALSE’, the symbology will not be displayed. Similarly,
each primitive has its associated plugs. In SCADE Display the user has to declare
and initialize these plugs as per requirements.
In SCADE Suite the variables declared in SCADE Display are used to control
the GUI. The initial step includes importing the SCADE Display project to SCADE
Suite. Creating an operator that is a block containing logical operations. The operator
is used to create a counterpart variable of SCADE Display in SCADE Suite. These
250 L. K. Jose et al.

variables are used to implement the logic required to control the GUI. As mentioned
above, the value for variables is assigned in the SCADE Suite. The tool also has
an option to integrate MATLAB code and Simulink model. The code generated by
Simulink embedded code generator is not certifiable code, but when imported in
Suite, the KCG code generator of SCADE Suite can generate certifiable code [5, 6].
Once the logic part is implemented, Suite has an option called co-simulation,
where Display IDE and Suite IDE works simultaneously based on inputs given to
the Suite model. This helps in the verification of the model by the user.
If the behavior of a model is as intended, the next step is to generate the auto-code.
SCADE Display generates OpenGL SC-based code and Suite generates code that
contains the logic to control the GUI generated by Display code.
The code generated by SCADE can then be ported on to any target as the codes
are target-independent. This means that the code generated for a simulator can be
used for the embedded target. The flow of design and development of application
software can be understood from Fig. 2.
To develop Primary Flight Display symbology an initial study of different
aircraft’s display was done, SAE-ARP standards [7] for display design of civilian
aircraft and human factor considerations [8] was considered as reference. DO-178B
[9] and DO-178C [10, 11] were also referred for software guidelines for airborne
systems. Symbology definition document along with software requirement document
was considered to design Primary Flight Display along with its basic functionality

Fig. 2 The flow of code generation and compilation

Model-Based Code Generation for Avionics Display Graphics 251

on the SCADE Display tool. The basic functionality of the developed display was
animated and simulated using the SCADE Display tool’s inbuilt simulator. Further,
display input data processing logic was developed using a model-based approach
using the SCADE Suite tool. The verification of the auto code generation using the
SCADE tool was verified using LDRA and SCADE Suite simulator. The auto code
generated was integrated with the manual code consisting of functions for applica-
tion initialization and runtime error indication. Finally, the code was compiled to run
the display on the windows platform using visual studio and also on Linux based
platform using the make file procedure. Execution of the PFD was carried out both
on desktop pc and ARM-7 architecture-based targets (Raspberry Pi-2). The PC runs
on an Intel-based processor, whereas Raspberry Pi-2 is an ARM-7 architecture-based
target. This experiment was done as proof of concept to show that, the tool generates
target-independent code and can be used on different targets. This also helped in
observing the time required to draw the OpenGL SC-based graphics on different
targets with different clock frequencies.
D. Software Module Description

SCADE environment provides the following file structure to generate the display
application software. Display application Software of primary flight display is
divided into three modules.
1. SCADE Display Module
2. SCADE Suite Module
3. Entry point and data acquisition Module.
Display Module contains *.c and *.h files generated by SCADE Display. Suite
Module contains *.c and *.h files generated by SCADE Suite. The manual code
integrates the auto-code generated by the SCADE Display and Suite, initializes the
entry points of the application. Figure 3 shows the contents of each module.
E. Input and Output Data

The simulator generates real-time values for parameters that are inputs from different
sensors or sub-systems in actual aircraft. The Suite code accepts input from the
simulator, this input is processed to generate output data to drive display symbology.
The generated output of Suite is further mapped to SCADE display input for the
functionality of the display symbols like transition, rotation, text/value, etc. The
display code accepts the input from the Suite code and displays the GUI as per the
inputs. This flow is represented in Fig. 4.
F. Communication and Entry Point of Application

Manual code integrating SCADE auto-generated code has the main entry point for
the display application. The initialization of the OpenGL application is implemented
in main.c file and initialization of UDP protocol are implemented in the network.c
file.
252 L. K. Jose et al.

Fig. 3 Modules of application software

Fig. 4 Execution flow of code

The network.c has the following functions declared and has a functionality to
establish a connection between the simulator computer and display computer, it also
has a function to receive real-time data from the simulator computer and store it in
an array. network.c has the following functions defined.
1. Initialize function: This function is responsible for the initialization of the UDP
protocol between the Simulator computer and Display Computer.
2. Receive function: This function is responsible for receiving the data at the
receiver computer.

3 Implementation and Execution

Model-based display development using the SCADE tool provides a platform to

develop target-independent OpenGL SC-based auto-generated code. This code can
be ported to any embedded target without a change in code or library. The Primary
Flight Display application built was executed on SARAS aircraft cockpit simulator
and ARM Cortex A-7 based Raspberry Pi. Visual Studio with GCC compiler was used
to compile and built the application for the SARAS simulator whereas a ‘makefile’-
based procedure was used to cross-compile the same application for Raspberry Pi.
SARAS simulator provides dynamic PFD data based on user input. This data is
Model-Based Code Generation for Avionics Display Graphics 253

Fig. 5 Integration of auto-code on different target

Fig. 6 Code running on SARAS Simulator And Raspberry Pi

further used as input for a display to drive the symbology. Figure 5 shows the flow
of code integration on SARAS Simulator and Raspberry Pi.

4 Result

The code was successfully executed on Raspberry Pi an ARM-based target working

on Raspbian OS and on SARAS simulator which has an Intel-based processor
working on the Windows platform. The auto-code generated was not altered in
this process, which proves the code is independent of target hardware and soft-
ware. Figure 6 shows auto-code integrated on the SARAS simulator (on the left) and
Raspberry Pi (on the right).

5 Conclusion and Future Works

The code was generated using a model-based designer tool SCADE and was inte-
grated on different targets. The code generated is target-independent and can inte-
grate on a different embedded target. The code generated need not be modified for
254 L. K. Jose et al.

different targets. This helps in reducing the development time required for a project,
from developing a prototype to simulating it from a test rig and later integration on
a final embedded target. The code can be integrated on any OS or RTOS depending
upon the functionality. The code generated is initially verified using simulation in the
SCADE Suite and later can be tested using Model tester tools or LDRA. However,
SCADE generates DO-178C certifiable code and needs not to be tested manually.

Acknowledgements This paper was published as part of a technology demonstration project

carried out by CSIR-NAL. We thank our H.O.D Mrs. J. Jayanthi for providing insight and expertise
that greatly assisted the project
We thank our colleague Santosh Kumar P and Reshma Rajkumar for the comments that greatly
improved the manuscript.

References

1. S. Kumar, M. Nanda, P.R. Rao, L.K. Jose, Model-based approach for design and development
of avionics display application, in ICETE (2019)
2. H. Fuhrmann, R. Von Hanxleden, Enhancing Graphical Model-Based System Design—An
Avionics Case Study
3. B. Stockwell, OpenGL SC: safety-critical profile specification, version 1.0.1, Khronos Group
(2009)
4. Esterel Technologies, Methodology Handbook—Efficient Development of Safe Avionics Soft-
ware with DO-178C Objectives Using Scade Suite, 1st edn. Esterel Technologies, 2015
5. G. Walde, R. Lunkner, Bridging the Tool Gap for Model-Based Design from Flight Control
Function Design in Simulink to Software Design in SCADE
6. Esterel Technologies, Gateway Guidelines for Simulink (Esterel Technologies, 2015), SC-
SKG-EPG-R16 - DOC/rev/55682-01
7. SAE ARP4102–7 Appendix A Electronic Display Symbology for EAD/PFD The Engineering
Society For Advancing Mobility Land Sea Air and Space
8. DOT/FAA/AM-01/17, Human Factors Design Guidelines for Multifunction Displays (2011)
9. Software Considerations in Airborne Systems and Equipment Certification, RTCA document
DO-178B (1992)
10. RTCA DO-178C - Software Considerations in Airborne Systems and Equipment Certification,
RTCA, Inc. Std. (2011)
11. Model-Based Development and Verification Supplement to DO-178C and DO-278A. RTCA
document DO-331 (2011)
Avionics Display for Two-Seated Aircraft
Using OpenGL

G. Anand, Manju Nanda, K. Nayana, and J. Jayanthi

Abstract The avionics display is the most critical part of an aircraft. The display
provides the Human–Machine Interface (HMI) or Human–Computer Interface (HCI)
for the pilot. The display, a safety–critical system in aircraft which gives essen-
tial information about the aircraft. The hardware and software of the safety–critical
avionics system are established depending on RTCA guidelines such as DO 178B.
In this paper, we propose a method to create an HMI for a safety–critical system
using graphical libraries. The aim is to develop a display for the two-seater aircraft.
The avionics display comes under criticality level A which requires perfect software
development following the standards for safety criticality. The application software
development is based on Software Development Life Cycle (SDLC). The GUIs
are created using the OpenGL library available. The software developed was tested
in real-time using a 7-inch Thin Film Transistor (TFT) display using BCM2837
microprocessor.

Keywords Safety–critical system · Human–machine interface (HMI, RTCA

DO178B) · Open graphics library (OpenGL, Software Development Life Cycle
(SDLC))

G. Anand (B) · M. Nanda

Aerospace Software & Information Systems Division, CSIR- National Aerospace Laboratories,
Bangalore, India
e-mail: g.anand777@nal.res.in
M. Nanda
e-mail: manjun@nal.res.in
K. Nayana
Department of Electronics, Cochin University of Science and Technology, Kochi, India
J. Jayanthi
Aerospace Software & System Division, CSIR-NAL, Bangalore, India
e-mail: jayanthi@nal.res.in

© The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2022 255
S. Chandramohan et al. (eds.), Artificial Intelligence and Evolutionary Computations
in Engineering Systems, Advances in Intelligent Systems and Computing 1361,
https://doi.org/10.1007/978-981-16-2674-6_20
256 G. Anand et al.

1 Introduction

As more and more vital functions are realized by electronic devices, the avionics
system has become indispensable in modern aircraft. Automation has been recog-
nized in the field of avionics which benefits operational efficiency and safety but it has
also increased operational complexity for pilots. Because of insufficient situational
awareness, many accidents and incidents had happened. Many of these problems were
caused because of the increased computerization of flight deck design. The pilots
must perceive information in time to make decisions and take control in unexpected
conditions. The displays are designed in such a way that it can provide a means to
perceive different information. Human information processing capability to perceive
aircraft changes remains a safety concern in the field of avionics. Good situational
awareness for the pilot can be made possible by the human-centered design of the
cockpit display. There is a need to consider the pilots’ visual characteristics while
designing a display. There comes the development of HMI. An HMI is a user inter-
face that connects a person to a machine, i.e., any screen that allows a user to interact
with a device is an HMI. HMIs communicate with input/output sensors to get and
display information for users to view. Pilots will always face situations where they
should make timely decisions. The safety of aircraft is not only dependent on the
pilot’s decision but also depends on the information perceived at the right time [1, 2].
Avionics system is a safety–critical real-time system whose failure can cause many
severe serious issues even loss of life. To ensure the development of a device in the
avionics domain with safety is a more challenging task. The safety criticality level of
avionics display which established depending on Radio Technical Commission for
Avionics (RTCA) guidelines such as DO-178 B. As the avionic system developed
from a federal structure to an integrated modular structure, many researchers and
research institutes have made lots of researches on the modeling of the avionic system.
The focus of this paper is on the modeling of an avionics display system in the cockpit
for aircraft for displaying the engine parameters. The aim is to develop an HMI for
a safety–critical embedded system using graphical libraries. Using OpenGL makes
the development of Display or HMI easier. OpenGL is an Application Programming
Interface (API) which is a software library that can create graphical visualization. The
display application is going to be developed using OpenGL. The cockpit display for
two-seater aircraft is an interface for the pilot to understand the aircraft parameters and
status information easily. The avionics display application consists of the main page
with some essential parameters and some buttons. The buttons can be programmed
to translate to other sub-pages which can show other parameters [3, 4].
Avionics Display for Two-Seated Aircraft Using OpenGL 257

2 Human–Machine Interface

In the aviation domain, much guidance documentation has developed that focuses
on the standards required for aircraft cockpit designs. Most of the documents focus
on the design of displays design to improve Human–Machine Interface (HMI) in the
aircraft and situation awareness for the safety of operations. Pilots must understand
engine parameters displayed such as oil temperature, oil pressure, throttle position &
engine RPM, etc. The automated cockpit design has become coordination between
human and the HMI systems [2].

2.1 Hand Coding Drawbacks

The HMI design can be done in manual and model-based. There has been an increased
use of model-based tools to create HMIs. But still in some projects hand-coding is
used that is difficult to maintain and is difficult to make corrections and upgrades [5].
A limiting feature of hand-coding is that it can be used with specific computing
architecture, operating system, or a specific graphic library. This is due to the lack
of information to create flexible code and because of the deadlines. This makes it
difficult to make changes or updating the codes and difficult to adopt a new archi-
tecture. It is impossible to re-use the program because each program has its own
specific graphical and functional requirements and is not organized in a modular
fashion that facilitates reuse. Some companies have been able to reuse their work
when the projects have the same requirements and same development environment.
But it is difficult when the applications are different or a part of the code is to be
reused. So it will be better to create a code newly rather than reusing it [5].

2.2 The Current State of HMI Tools

HMI design allows users to focus on the visual appearance and functional aspects of
their displays. while more advanced programmers can augment the tool as necessary
by creating new visual components as well as interfaces to external data sources and
hardware components. When any modification of the display is needed, by using the
HMI tools it is easy to create changes and update the display code. HMI defines the
visual appearance of a display and is also used to specify the behavior and data ranges
of all elements that are rendered on-screen. HMI tool helps to define the relationship
between the user interaction and multiple pages interactive systems [5].
258 G. Anand et al.

3 Standards for Software Development

3.1 RTCA DO-178B

Validation and certification of systems become more difficult since the system has to
withstand both software design errors and hardware component failures. Additional
methods were required to assure that avionics software applications achieved the
same level of assurance as hardware-based systems. This was the reason for the
development of DO-178 by the RTCA [6]. The DO-178B are guidelines that focus
on the impact of software failure on the safety–critical system, i.e., how critical is the
failure and how it affects the aircraft system. These software impacts are classified
into five categories, i.e., Catastrophic, Hazardous/Severe-Major, Major, Minor, and
No Effect [7]. (1) Catastrophic- it is a failure condition of Level A software that
may cause multiple fatalities like loss of the airplane, (2) Hazardous- it is a failure
condition of Level B software that has a large negative impact on the safety or
performance that reduces the ability of the crew to operate the aircraft, (3) Major- it
is a failure condition of Level C software that results in a significant reduction in safety
which increases the crew’s workload and may cause discomfort to the passengers,
(4) Minor- it is a failure condition of Level D software which will slightly reduce the
safety margin or increases the crew’s workload and causes an inconvenience for the
passengers, (5) No effect- this is a Level E software failure condition that does not
affect the safe operation of the aircraft [8].

3.2 Software Development Life Cycle

Software Development Life cycle (SDLC) is the phases involved in the development,
design, and maintenance of the software and this ensures the fulfillment of user
requirements [9, 10]. An SDLC deals with various phases from planning to testing
and deploying software [11]. An SDLC model has two models one is a descriptive
model that describes how a particular software system was developed and the other
model is the prescriptive model that describes basic information for understanding
and improving software development processes [12, 13]. Figure 1 below shows the
different stages of a waterfall model.
V model is an SDLC model in which each phase must be completed before the next
phase begins. The testing procedures are developed during each of the phases before
any coding is done and a system test plan will be created before the development
of the designed system begins. The test plan is designed based on the functionality
requirements described in the requirement analysis stage.
The V-model concept shows the main steps to be followed from the beginning to
its final delivery of a system. Figure 2 above shows the flow of different stages of a
V-model flow diagram.
Avionics Display for Two-Seated Aircraft Using OpenGL 259

Requirement

Design

Implementation

Verification

Maintenance

Fig. 1 Waterfall model stages [1]

System System
requirements testing

High level
SW
testing
requirements

SW arch & Low level

design testing

Created From
Received From
Feed into Code &
EOC

EOC-Executable Object Code

SAS-Statistical Analysis System,
SCI-Software Code Integration

Fig. 2 V-model flow diagram

This model has many advantages and disadvantages compared to other conven-
tional models. The advantages are (1) It is simple and easy to use, (2) This model
has a higher chance of success due to the early development of the test plan, (3) The
requirements are easily understood, and the disadvantages are (1) It is very rigid,
little flexibility, (2) software is developed during the implementation phase, (3) The
model doesn’t provide a clear path for problems [11, 14].
260 G. Anand et al.

4 Opengl Graphics Library

OpenGL (Open Graphics Library) is an Application Programming Interface (API)

which is a software library for accessing features in graphics, i.e., it is a software
interface to graphics hardware that can create graphical visualization. This software
interface consists of a set of functions that allow indicating the objects and opera-
tions for creating graphical images objects [15]. OpenGL functions are called in the
program which draws objects such as points, lines, and polygons. A safety–critical
application is an application whose failure can be fatal. OpenGL API makes the devel-
opment of HMI display easy. OpenGL helps the creation of graphical icons that can
graphically indicate the aircraft parameters. Because it aims for use in safety–critical
applications the development of the engine management display unit for displaying
the engine parameters made easy. In general, anyone developing safety–critical soft-
ware for avionics systems must follow RTCA DO-178 guidelines which ensure the
safety of airborne systems published by RTCA [16, 17].

4.1 OpenGL Fundamentals

OpenGL is concerned mainly with rendering into frames and there is no need for
support for other peripherals sometimes associated with graphics hardware, such as
mouse and keyboards. This draws primitives to selectable modes are points, line
segments, or triangles. Modes can be changed independently and the setting of one
does not affect the settings of others. Function calls can be written in a program
that can create graphical primitives. In the function call commands the parameters
are given, such as foreground colors, background colors, texture coordinates, text
colors, text style and size, position coordinates, etc. The commands in the programs
are always processed in the order in which they appeared, even though there may be
an indeterminate delay [16].

5 Overview of EMU Display System

The display system in the Cockpit provides the visible and audible portion of the
HMI for aircrew. In the cockpit, the aircrew can manage the modern Glass cockpit
and interface with the c aircraft onboard avionics through the display system [1]. The
software for a cockpit display system helps to acquire sensor data from various parts
of aircraft and synchronizes it. Using this data application software can generate the
display visualization of parameter details and many warnings for pilots to make the
decisions for the operation of aircraft [18].
Avionics Display for Two-Seated Aircraft Using OpenGL 261

Oil pressure
sensor

Oil temperature
sensor
Aircraft TFT
Fuel pressure Engine Touch
sensor Parameters Micro- Display
processor
(μp)
Fuel
temperature

Other sensors

Model- GUI
Generate
Based developed
d .exe
Approac usingOpe
library
h nGL

Fig. 3 EMU general block diagram

The Engine Management Unit (EMU) display application software has main
responsibilities that are displaying the engine parameters variations, displaying warn-
ings and alerts about the engine, and page control. The signals from sensors of the
aircraft engine are first synchronized and filtered by the application software and
these values are displayed [18]. Figure 3 depicts the general block diagram of the
engine management unit.

5.1 Engine Management Unit

In an aircraft engine, there will be many vital parameters that are very important.
There are many cockpit displays designed that will display the engine parameters
details in the bottom or side of the display along with other details. So that an
application-specific software for Engine Management Unit (EMU) can be designed
and interfaced with a display for the details of the parameters. The EMU is the
management system that is developed for the aircraft. The EMU is to display the
engine parameters values such as temperature, the pressure of fuel and oil, gas
temperature, warning alerts about devices, bus status, etc. For this EMU display
unit, application software has to be developed. This application software is devel-
oped using OpenGL graphical library. The application software developed was built
in an embedded processor and a display interfaced with it to visualize the developed
application graphical icons for the EMU display unit. The display uses advanced TFT
technology, providing a display with 800 × 480 pixels (7-inch display). The EMU
262 G. Anand et al.

FUNCTIO
REQUIREMENTS STATUS OUTCOME
NS

Paramet
ers
Reset
Main Created
button
Page Successfully
Navigati
on
buttons

Fig. 4 EMU main display page

display contains indications of all engine parameters including external fuel pres-
sure sensor information, the engine status, and error conditions cleartext. Continuous
monitoring and health checking of serial buses and are indicated in the display.
The EMU display has the main display page in Fig. 4 which gives the general
information and updated parameter values. To navigate buttons are provided on the
main page which helps to move to the other three pages which contain an elaborated
view of every single parameter information. The pages such as the Engine data
information (INFO) display page, System Information Status (SYST) display page,
and System Configuration (CONF) display page gives detailed engine information.
The application software can be built into the processor and visualized in the display
interfaced in real time. The lines, arcs, polygons & buttons are created using OpenGL
graphical toolkit. The text such as Oil, EGT/CHT, THROTTLE, FUEL, ECU/MAT
is the static headings under which the values will change depending on the inputs.
The color of the values will change depending on the range of values. The values
under heading OIL will show oil temperature & oil pressure. EGT is the exhaust gas
temperature & CHT is the coolant temperature. Throttle position will be indicated,
under heading FUEL, fuel temperature &fuel pressure will be displayed ECU voltage
and Manifold temperature will be displayed under ECU/MAN heading. Figure 5
shows the flow chart of the main page which gives an idea of how the display is
working.
Avionics Display for Two-Seated Aircraft Using OpenGL 263

Main Display Page

Engine parameters

Navigation
buttons

Buttons= Buttons= Buttons

= = ==
INFO SYST CONF

INFO Page SYST Page CONF Page

RET button

Fig. 5 Flow chart of the main page

The main page of the engine management unit will show some essential parameter
details and some buttons at the bottom. The three buttons are the navigation button,
by pressing it new subpages will appear. On each page, there will be the RET (Return)
button at the bottom which helps to go back to the previous page.

6 Result and Discussion

The functionality test for the application software developed was done in real time.
Each page with the requirements, its current status, and the visualized outcomes are
tabulated in Table 1.
264 G. Anand et al.

Table 1 Implemented result

Sub-pages via navigation buttons
INFO page Buttons such as; Created
• Power successfully
• EGT
• OIL
• Fuel/Man
• Electr/Amb
• Op Hours

SYST page Buttons such as; Created

• Warnings successfully
• ECU Faults
• ECU Status
• ECU Config
• Data Rec
• CAN BusMon

CONF page Buttons such as; Created

• units successfully
• RPM
• MAN
• FuelpCorr
• Save

7 Conclution

In this paper, we have generated a graphical library to create an HMI for a safety–
critical system using OpenGL. The display of an aircraft is a safety–critical part
which is a medium for the pilot to interact with the aircraft. The display application
software designed for two seated aircraft is for displaying the engine parameters.
The EMU display for two-seater aircraft was developed which will show the engine
parameters, essential information, and warnings regarding the engine. We used the
OpenGL library that helps to create all the graphical visual representations required
for the application development. The application software was developed and for
checking the functionality a system-based testing was done.

Acknowledgements We the authors like to thank our Director, Mr. Jithendra J Jadhav CSIR-
National Aerospace Laboratories for his diligence to convey and carry the work successfully.
 Avionics Display for Two-Seated Aircraft Using OpenGL 265

References

1. Z. Zhao, J. Zhang, Y. Sun, Z. Liu,Modeling of avionic display system for civil aircraft based
on AADL, in 2018 Chinese Control And Decision Conference (CCDC) (IEEE, 2018), pp
4121–4126
2. W.C. Li, A. Horn, Z. Sun, J. Zhang, G. Braithwaite, Augmented visualization cues on primary
flight display facilitating pilot’s monitoring performance. Int. J. Hum.-Comput. Stud. 102377
(2019)
3. Rotax 912iS Engine Management Unit(EMU 912iS evo), Michael Stock (2018)
4. EMU 912iS evo Engine Management Unit, user manual, Version: 1.7
5. Y. Lefebvre, A flexible solution to deploy avionics displays to multiple embedded plat-
forms,in 2008 IEEE/AIAA 27th Digital Avionics Systems Conference (IEEE, 2008), pp. 5-A
6. C. Taylor, J. Alves-Foss, B. Rinker,Merging safety and assurance: the process of dual
certification for software, in Proceedings of the Software Technology Conference (2002)
7. G. Zoughbi, L. Briand, Y. Labiche, Modeling safety and airworthiness (RTCA DO-178B)
information: conceptual model and UML profile. Softw. Syst. Model. 10(3), 337–367 (2011)
8. W.K. Youn, S.B. Hong, K.R. Oh, O.S. Ahn, Software certification of safety-critical avionic
systems: DO-178C and its impacts. IEEE Aerosp. Electron. Syst. Mag. 30(4), 4–13 (2015)
9. S. Barjtya, A. Sharma, U. Rani, A detailed study of software development life cycle (SDLC)
models. Int. J. Eng. Comput. Sci. 6(7), 22097–22100 (2017)
10. T.J. Lehman, A. Sharma,Software development as a service: agile experiences, in 2011 Annual
SRII Global Conference (IEEE, 2011), pp. 749–758
11. P.K. Ragunath, S. Velmourougan, P. Davachelvan, S. Kayalvizhi, R. Ravimohan, Evolving a
new model (SDLC Model-2010) for software development life cycle (SDLC). Int. J. Comput.
Sci. Netw. Secur. 10(1), 112–119 (2010)
12. C. Larman, V.R. Basili, Iterative and incremental developments: a brief history. Computer
36(6), 47–56 (2003)
13. V. Massey, K.J. Satao,Evolving a new software development life cycle model (SDLC)
incorporated with release management. Int. J. Eng. Adv. Technol. (IJEAT) 1(4) (2012)
14. L. Marcil, MBD & code generation: a cost-effective way to speed up HMI certification, in 2011
IEEE/AIAA 30th Digital Avionics Systems Conference (IEEE, 2011), pp. 8B1–1
15. D. Shreiner, G. Sellers, J. Kessenich, B. Licea-Kane, OpenGL Programming Guide: The Official
guide to learning OpenGL, Version 4.3. (Addison-Wesley, 2013)
16. OpenGL SC Version 2.0.0 (Full Specification) (Aidan Fabius, Steve Viggers, 2016) (19 April
2016)
17. P.S. Santosh, M.K. Nanda, P.R. Rao, L.K. Jose, Model based approach for design and
development of avionics display application, in International Conference on E-Business and
Telecommunications (Springer, Cham, 2019), pp. 444–451
18. S. Sharma, N. Vasi, J. Ghidella,Designing control logic for cockpit display systems using
model-based design, in AIAA Modeling and Simulation Technologies (MST) Conference (2013),
p. 4589

View publication stats