Using A661 in a Windows PC Environment – part 1

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.