ARINC 661 Based Graphics Engine for Aircraft Head up Display

advertisement
International Journal of Engineering Trends and Technology (IJETT) – Volume 33 Number 5- March 2016
ARINC 661 Based Graphics Engine for
Aircraft Head up Display
Ashwin P Chandran#1, Vandan Revanur#2, Apoorva K Shah#3, Kavya TR Nayaka#4, Gurusewak
Singh*5, Lakshmi KP $6
#
Bachelors in Engineering,Electronics and Communication,BMS College of Engineering, Visvesvaraiah
Technological University, Karnataka, India
*Scientist. ‘D’, Avionics and Weapon systems, Aeronautical Development Agency, Karnataka, India
$
Associate Professor,Electronics and Communication, BMS College of Engineering, Visvesvaraiah
Technological University, Karnataka, India
Abstract—ARINC 661 Specification defines an overall
display system architecture suitable for aircraft cockpit
displays to facilitate the creation of interactive displays.
The specification include the Cockpit Display System
(CDS), a rendering engine dedicated to presenting
graphical information, which is separated from its
associated logic. The logic part of the display system is
handled by the User Application (UA). Head
UpDisplay(HUD) is the main cockpit display of a fighter
aircraft which provides flight and targeting information in
the pilot’s forward field of view.HUD uses vector graphics
for rendering the display page for which traditional raster
graphics processors are not suitable. A vector graphics
engine, was developed for the HUD to directly interpret
ARINC 661 definition files and run time protocol. This
vector graphics engine is capable of rendering widgets,
and having runtime communication with the user
application as defined by the ARINC 661 standard. This
enable the use of commercial software tools to address
various parts of display creation process and automatic
generation of DO178B certified definition files conforming
to the ARINC 661 standard, thereby significantly reducing
the cost and time foravionics display system acquisition
and upgrades.
Keywords—Head Up Display (HUD), CDS, ARINC
661, Widgets, Vector Graphics Engine, Display List,
FPGA
I. INTRODUCTION
HUD is the primary flight display for combat
aircrafts and has been proven to be a major
improvement in Man Machine Interface. It allows
the pilot to simultaneously view and assimilate flight
data and visual target information, while maintaining
head up position. HUD basically projects a
collimated display in the pilot’s forward line of sight
so that he can view both the display information and
outside world scene at the same time. The HUD
systemgenerally includes a cathode ray tube (CRT)
as display unit.CRT display is collimated, by a set of
beam combiners that focus the image at infinity. The
pilot’s gaze angle of display symbology does not
change with head movement, hence overlaid
symbology remains conformal, or stabilized with the
outside world scene. The pilot is thus able to observe
both distant outside world objects and display data at
the same time without having to change the direction
ISSN: 2231-5381
of gaze or refocus of the eyes [1]. The pilot is thus
free to concentrate on the outside world during
manoeuvres and does not need to look down at the
cockpit instruments. CRT beam is deflected by the
deflection system to draw the vector graphics on the
screen using X and Y deflection and Z blanking. The
vector graphics provides better positioning accuracy
and precision control for HUD symbology.
Traditionallydisplay processing for deflecting the
CRT coil to generate appropriate symbology is
carried out by a display computer. The data for
generating various symbols would be received from
various subsystems in theaircraft. There is no
predefined process or methodology for symbology
generation due to the lack of standardized Human
Machine Interface, which results in tedious display
software development cycle. The look, feel, and
display logic partitioning is not very well defined,
which results in certification process(DO-178B) to
be followed for every minor look & feel
modification.
ARINC661 specification defines an overall
architecture of interactive displays with sub
components – Cockpit Display System (CDS) and
User Application (UA) [2]. CDS is a rendering
engine dedicated to presenting graphical information,
which is separated from its associated logic. UA
handles the logic part for display. ARINC661
defines an interface protocol intended to facilitate
communication between the CDS and UA.
ARINC661 relies on a basic set of graphical user
interface objects called widgets. The list of widgets
is referred to as the ARINC661 Human Machine
Interface (HMI) widget Library. The use of this
standard introduces clear separation between the
code drawing the graphics and the one managing the
logic, position and state of all visual elements
thereby resolving many of the present issues. We
have implementedVector Graphics Engine based
CDS for the HUD, which is capable of interpreting
ARINC661 Definition Files and runtime commands.
http://www.ijettjournal.org
Page 236
International Journal of Engineering Trends and Technology (IJETT) – Volume 33 Number 5- March 2016
II. CDS FOR HUD OVERVIEW
The development of Vector Graphics Engine
based CDS for HUD is carried out using high
performance FPGA with integrated on chip
embedded processor.The Virtex 4 FX12 FPGA
which is available on ML403 evaluation Platform
from M/s Xilinx Inc. has been used for
implementation. The Virtex 4 FX12 has
PowerPC405 core which acts as system controller
and runs the application program. The Vector
graphics engine basedCDS, enablesARINC 661
Definition File(DF) to be loaded and rendered on
HUD CRT.A Definition File is used by the User
Application (UA), to specify the characteristics of all
the instances of the widgets to be drawn on the HUD.
Each definition file consists of the hierarchical
listing of all widgets to be loaded, along with their
initial properties, such as visibility, colour, position,
orientation etc.
The CDS, at its core is divided into two sections
i.e. processing section and graphics rendering
section. The processing section is implemented in
software running on PowerPC405 and graphics
rendering section consists of Vector Graphics
Engine IP core on FPGA Fabric as shown in Fig. 1.
Processing section performs following tasks:
DF Configuration control
DF parsing
DF update based on runtime data received
through the Ethernet communication interface.
Display list creationusing graphic primitives of
Vector Graphics Engine.
Fig. 1 CDS Architecture
Fig. 2shows the basic hardware architecture
implementation around PLB (Processor Local Bus).
The CDS hardware is created using Xilinx Platform
Studio. The Vector Graphics Engine IP is created
with PLB Slave Interface and memory mapped to
PowerPC PLB. Xilinx SDK is used for application
code development.
Graphics Rendering Section generates output X & Y
deflection signals along with Z blanking signal,
based on Display List created by the processing
section. The section has following primitives
implemented on FPGA fabric.
LoadMatrix
MoveCursor
DrawLine
DrawPolyLine
DrawCircle
LoadMask
Fig. 1 Block Diagram of the Hardware Architecture
III. GENERATION OF DISPLAY LIST
At Start-up, application runs DF configuration
control routine, which verifies the version of DF
available with UA and CDS. CDS stores a copy of
DF in Linear Flash memory. If version mismatch
occurs, the CDS loads its DF file over Ethernet from
the UA. After DF verification, application initialises
CDS and copies DF to runtime memory i.e. SDRAM
and makes index entries for runtime modifiable
ISSN: 2231-5381
http://www.ijettjournal.org
Page 237
International Journal of Engineering Trends and Technology (IJETT) – Volume 33 Number 5- March 2016
parameter of DF. It then proceeds to parse the DF
and generate the Display List. Display List is a set of
commands, parameters and vector pattern data that
has to be executed by the Vector Graphics Engine IP
core.
processor computes the matrix coefficients of
composite matrix and packs them into the Load
Matrix command of the display list and writes to
Dual port memory of Vector Graphics engine.
Fig. 6 Display List Commands for ARINC 661 Widgets [4]
Fig. 3 Processing Section Flow
Fig. 4 shows a typical instruction format of
display list commands [3]. The display list command
consists of instruction Header and data. The width of
display list is 32-bit in Big-endian Byte order as
PowerPC 405 and DF also is Big-endian Byte order.
(0-7)
(8-15)
(16-23)
(24-31)
Opcode
Length
Reserved
Reserved
Fig. 4 Display List Instruction Header
The Opcode details the primitive of the Vector
Graphics Engine and length details the number of
data operand required by opcode. The Fig. 5 shows
the example of DrawLine primitive (Opcode
0000_0001) of Display List.
0000_0001
0000_0100
xxxx_xxxx
xxxx_xxxx
Start_coordinate(x1)
Start_coordinate(y1)
End_coordinate(x2)
End_coordinate(y2)
Fig. 5 DrawLine Primitive of DisplayList
As DF is hierarchical list of widgets to be drawn,
the processor will read widget by widget and pack
the data as per display list format and writes to Dual
port memory of Vector Graphics Engine. All
container widgets of ARINC661 such as basic
container, rotation container, translational container,
have a specific rotation and translation value which
affect all the widgets that are within the container
(i.e. the container is their parent widget). The
ISSN: 2231-5381
ARINC 661 contains a large widget library
which defines the two dimensional graphics
primitives to be displayed by the Graphics Engine.
The library consists of a large variety of elements,
including lines, arcs, and circles. It also allows user
defined shapes to be created. All elements defined
by the standard can be represented using a small set
of display functions like draw line or circle, load
matrix, load mask etc. These commands are similar
to the display list commands of OpenGL. Using
these display commands, we can build a display list,
which when executed can accurately render a GUI as
defined by the Definition File.
Fig. 6 illustrates how different widgets can be
mapped to various Display List commands. When a
widget is encountered during parsing a Definition
File, the corresponding calculations are performed
and a set of commands pertaining to the widget are
added to the list. These commands are the vector
drawing primitives that can be used to render
virtually any widget in the file. Labels for example
are a collection of lines followed by a shift in the xaxis according to the width of the character. Hence
they can be rendered using draw line and move
cursor commands.
IV. RENDERING VECTOR GRAPHICS PRIMITIVES
Vector Graphics Engine is created as an IP core
with PLB slave interface using FPGA logic elements
available. The Vector Graphics engine has a Dual
port RAM which is interfaced to the PLB bus on one
port and other port is read by the Vector Graphics
http://www.ijettjournal.org
Page 238
International Journal of Engineering Trends and Technology (IJETT) – Volume 33 Number 5- March 2016
Engine. The processor writes the display list to Dual
port RAM, which is read by the Vector Graphics
engine and corresponding X, Y & Z deflection
signals are generated at required writing speeds for
HUD. The algorithms used and implemented in
VHDL for computationare detailed hereafter.
A. Line Algorithm
For given 2 points representing start and end
coordinates of the line, the pixel points of the
Lines are calculated by following equationsderived
from Bresenham line algorithm [5]:
Start Coordinates=(x1,y1)
End Coordinates=(x2,y2)
Slope of the line=dx/dy
Where
dy = y2 - y1
dx = x2 - x1
The pixel points are calculated by first checking
whether the slope is positive or negative. Here all
four quadrants have to be considered for
thecalculation. Hence right and down variables are
used to keep track of the start and end coordinates.
For dx > 0,
right = 1
Otherwise
right = 0,
dx = (-dx)
For dy> 0,
down= 1,
dy = (-dy)
Otherwise
down = 0
right => positive side of x-axis
down => negative side of y-axis
err= dx + dy
e2 = 2 * err
For (e2 >dy),
For (e2 < dx),
y=y–1
At the end of every iteration, x is incremented until x
is less than y.
The odd numbered sector points are calculated as
follows: (Circle algorithm in reverse)
For d > 0,
d = d + 2 * (x - y) + 1
y = y +1
For d < 0,
d = d + 2 * (x + 1)
At the end of every iteration, x is decremented
until x is greater than 0.
All other sector points are obtained by mirroring
the above obtained points. The calculation of the
points for the segments is performed 8 times and in
order due to the vector drawing nature of CRT HUD.
C. Cohen Masking Algorithm
The Cohen Sutherland masking algorithm is an
iterative algorithm to mask lines present in a
predefined rectangular masking boundary [6]. This
algorithm was chosen over other existing similar
algorithms due to its simplicity and speed of
execution. In the algorithm, the whole two
dimensional area of the screen is divided into nine
regions. Each region is allocated a specific 4-bit
value known as an Outcode. In the algorithm,
Outcodes are computed for the start and end vertices
of the line to be masked. Fig. 7 shows the Outcodes
for each of the 9 regions with a sample line
intersecting the clip boundary. The Outcodes are
computed using the following equation:
Code = Code | Region Outcode
err = err+dy
(right = 1) => x = x + 1
(right = 0) => x = x - 1
err = err+dx
(down = 1) => y = y + 1
(down = 0) => y = y - 1
B. Circle Algorithm
A circle is an 8 fold symmetric figure. For a
given Centre (x1, y1) and radius, r, the circle points
are calculated by the following algorithmderived
from Bresenham circle algorithm [5]. Firstthe origin
(0, 0) is chosen as centre. The points on the circle
are calculated in order with respect to the origin,
following which it is shifted to the given centre.
Centre =(x1, y1)
Radius = r
Initially, x = 0
y =r
Decision parameter,
d = (1 - r)
The even numbered sector points are calculated as
follows:
For d < 0,
d = d + 2 * (x +1)
For d > 0,
d = d + 2 * (x - y) + 1
ISSN: 2231-5381
Fig. 7 Region Outcodes [6]
There are three possible cases after Outcode
calculation. They are:
Trivial Accept
Trivial Reject
Intersection Calculation
If both points are inside the masking boundary,
then it is a trivial accept, if both are out of the
masking boundary it is a trivial reject. However, if
only one of them is inside the masking boundary
then, point of intersection with the masking region is
to be calculated.
http://www.ijettjournal.org
Page 239
International Journal of Engineering Trends and Technology (IJETT) – Volume 33 Number 5- March 2016
The point of intersection is calculated using the
following equations:
y = y0 + slope * (x – x0)
x = x0 + (1 / slope) * (y – y0)
Here, slope = (y1-y0)/(x1-x0)
the HUD driver electronics, which contains a Digital
to Analog convertor (DAC). The DAC converts the
input Digital signals into analog signals. The analog
signals are conditioned as per HUD CRT
requirements.
The intersection values of x and y coordinates
are updated as x0 and y0 and the algorithm is
recursively executed till a trivial accept case is
encountered.
VI. RESULTS& CONCLUSION
In this paper, we havedescribed the
implementation ofARINC661 based CDS on a
commercial off the shelf available evaluation
platform i.e. ML403 from M/s Xilinx Inc. [7]. The
implementation coversa subset of widgets required
for CDS of the HUD. Accordingly DF is generated
using SCADE display suite using the subset of
widgets. The runtime data for modifiable parameters
of the DF is created with the help of C language.
The Fig. 9 shows the sample rendering of DF. The
Vector Graphics engine is implemented using FPGA
as a soft IP core and can be modified, used and
updated for any FPGA family. This helps in
preventing
hardware
obsolescence.
The
implementation also proves to be a very effective,
light and a fast method for rendering vector graphics
for the HUD.
V. VECTOR GRAPHICS ENGINE PIPELINE
The workload of the graphics engine pipeline is
divided between the geometry engine and the
drawing engine. The pipeline starts at the geometry
engine and then proceeds to the drawing engine.
Fig. 8 Graphics Engine Pipeline
A. Geometry Engine
The geometry engine performs the mathematical
operations required [3]. The geometry engine reads
the display list commands and updates the matrix
coefficient entries. Then the following vertices are
transformed (translation, rotation and scaling) using
the updated matrix and then passed through the
Cohen Sutherland masking algorithm. The resulting
coordinates after being clipped are known as
normalized device coordinates.
The resulting coordinates are then subjected to a
viewport transformation which maps them to the
display device coordinates, because the origin and
scaling varies with different display devices. The
process flow here is sequential as each calculation or
transformation requires inputs from its previous
stage. As the HUD has a 12-bit display resolution,
the size of the viewport chosen is 4096*4096.
Fig. 9 Sample Definition file Rendered on CDS
ACKNOWLEDGMENT
This project was initiated and funded by the
Aeronautical Development Agency (ADA), Ministry
of Defence, Govt. of India and supported by BMS
College of Engineering, Bangalore, India.
REFERENCES
[1]
[2]
[3]
[4]
B. Drawing Engine
The drawing engine deals with visualising the
defined symbology using the viewport coordinates
received from the geometry engine. The drawing
engine incorporates line and circle drawing
algorithms mentioned in the previous section. The
drawing engine proceeds by calculating all the
intermediate coordinates required for drawing of the
primitives. These coordinate values inclusive of the
start and end points are passed as a digital signal to
ISSN: 2231-5381
[5]
[6]
[7]
R. Collinson, Introduction to avionics systems. Dordrecht:
Springer, 2011.
Cockpit display system interfaces to user systems, ARINC
Specification 661-3, p. 402, 2007.
MB86291 Graphics Controller Specifications. Fujitsu,
2001
J. Yoon, N. Baek and H. Lee, "ARINC661 Graphics
Rendering Based on OpenVG and Its Use Cases with
Wireless Communications", Wireless PersCommun, 2015.
J. Bresenham, "Algorithm for computer control of a digital
plotter", IBM Syst. J., vol. 4, no. 1, pp. 25-30, 1965.
J. Foley, Computer graphics. Reading, Mass.: AddisonWesley, 1990.
A. S, "FPGA Based Multi Resolution Graphics Controller",
IJETT, vol. 14, no. 6, pp. 261-266, 2014.
http://www.ijettjournal.org
Page 240
Download