Using A661 in a
Windows PC Environment – part 1
Well, I'm back after these past months working
on something else.
Overview:
I will now do some posts on the use of the
ARINC 661 protocol for the graphical interface between a "worker"
application and a strictly display application. That is, an application that only interfaces to Windows to make
forms and controls visible or hidden as requested by the worker application,
forward control clicks and text entry to the worker application, etc where the
worker application supplies the "smarts" as to what to do with the
received messages and how what's displayed is to be presented.
The available controls and their original
arrangement and visibility is supplied by a Definition File that is read by the
display application (known as a CDS in the A-661 specification) so that the
same display application can be used with multiple worker/user
applications.
Thus, in this case, it is the interface
between the worker applications and the Windows GUI functions. Switch to Apple or Linux, for instance, and
only need the corresponding CDS. Or use
an embedded system. With the necessary
communication paths, the worker apps can be running on remote computers.
The ARINC 661 specification is a public
document. See en.wikipedia.org/wiki/ARINC_661 and http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4297342&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F4297296
As can be seen by these references, ARINC 661
has been development for the displays of aircraft cockpits. However, that doesn't prevent us from using
it for other types of systems.
A661 Overview:
As a version of my Exploratory Project, I have
created a CDS / Display Application to interface to Windows that obtains the
display layout from a definition file.
As previously, Microsoft Visual C# Express has
been used to implement the Display application although the ability to drag and
drop controls to a C# form to create the visual / graphical interface (GUI) has
not been used since that is supplied by the definition file.
A661 refers to layers and widgets. Windows of course has forms and
controls. My DF has an xml attribute to
relate both a primary form to a layer and sub-forms of the primary form. Controls and widgets are pretty much the
same and the terms will be used interchangeably. A layer is much like the primary form.
An A661 layer communicates with a particular
worker application. A different layer
can communicate with a different worker application. In A661, layers can be transparent so that one layer
communicating with its worker application can overlay another that is
communicating with another application while allowing the widgets of both
layers to be visible and "clickable". This transparent feature hasn't been implemented.
This application is a modification of my
previous one that at used my custom definition file (DF) and custom
inter-application protocol and to which I had added the ability to also use an
ARINC-661 like definition file and communicate via the A661 protocol. This latest revision removed the code for
the original custom DF and the use of the custom protocol so as to only treat
the A-661 protocol.
This latest version has also added the ability
to interpret A661 container and panel widgets.
The panel widget directly uses a Windows panel. Since a borderless panel seemed very
workable as an A661 container widget I used it.
Although a sample use of A661 map widgets is illustrated
in the DF I have yet to provide code to implement them. Such map widgets can be a reproduction of an
aircraft EFIS (see en.wikipedia.org/wiki/Electronic_flight_instrument_system) but can be as simple as line drawings such
as one illustrating stock market price changes during the day.
Worker Applications Overview:
The worker applications receive widget events
from the layer(s) that they are connected to with only one worker application
communicating with any particular layer (i.e., Windows main form).
In my design, the worker applications treat
received widget events similar to Windows control events received by the Visual
C# application. That is, an event
handler is specified for the widget and when the worker application receives
the A661 widget event message it is delivered to the event handler. See the diagram below for an overall view of
the Ada packages that make up the design.
The A661 messages are received by the
communications method used to connect between the worker application and the
display application. In this case the
method is Microsoft MS Pipes. In this
implementation, the MS_Pipe package is a generic package where an instantiation
(similar to an instance of a C# class) is created for each layer to be treated
by the worker application.
Each such layer has its own GUI package that
manages the layer. That is, manages the
received event messages and allows for the retention of information about the
widgets that should be currently displayed, active, etc. The diagram show two such Ada packages. In C# these packages would be variations of
a common class.
Common message formats, A661 constants, and
such are specified in the A661 package along with its Types and Topics
sub/child packages as well as a Receive method used to perform common
validations of received messages.
Widget is a package that retains information
about a particular Definition File configuration. That is, it contains, for instance, an Ada enumerated type to
supply a name to each A661 DF widget of interest to the worker application
along with functions to translate back and forth between the numeric widget
identifier and the widget name allowing the other routines of the application
to use names for the widgets of interest rather than their numeric identifier. Just like the Display application, it loads
the definition file and builds tables of those widgets of interest to the
application including one sorted by widget identifier for faster lookup.
Also illustrated are three kinds of A661
widget components. (The GUI packages
are A661 layer management components.)
The first kind is that of the Widget Action
components. These are the ones that are
similar to a C# event handler and are executed when the widget event of the
particular widget identifier is received.
To fully treat a widget event prior to starting the processing any other
widget event, the received messages are put into a FIFO queue specified for the
layer and treated one message event at a time.
The other two kinds of components are variations
of those that dynamically update the display without the necessity of a widget
event to which to respond. The
separation into two kinds of such components isn't really necessary. However, one is strictly dynamic producing
new output periodically while the other produces output due to worker
applications events, perhaps due to the results of some extended computation
that could have been initiated (at least in part) by a received message.
The messages to be transmitted are all routed
through the layer management component of the particular layer so it can keep
track of changes to be made to the display when need be and, for received widget
events, can treat any next message in its receive queue.
The GUI Installer is a launch package to
manage the installation of the various components and the use of framework
topics / message subjects by particular components with the framework to
facilitate their delivery.
Further description of the design and the two
applications will be provided in future posts.
