Basic Design
Event bus
Previously for the event driven inter object communications in the Java MFD training I’d used a derived version of ARINC429. This worked well although it was clumsy in use.
Basic structure was to have a Message, within which there were multiple MessageDataItems.
The standard way of receiving a message is to implement the interface and then decode each specific message type, and then iterate through the contained messages. This allows for great flexibility and the ability to have complex messages which are flexible and ggeneric. The identified problem is that this is too generic and could possibly be better served by extended the message class and containing that as is implemented in Emesary implementation of C# WPF Application Messaging
The old way
public long Receive(Message message)
{
if (message.getSystemIdent().Equals(SystemIdent.FlightModule))
{
foreach (MessageDataItem mr in message.getMDIList())
{
switch (mr.getItemType())
{
case MessageDataItem.Aircraft_Altitude:
ac_altitude = mr.getDValue();
break;
.
.
.
.
case MessageDataItem.Aircraft_Latitude_Degrees:
ac_lat = mr.getDValue();
break;
}
}
}
return 0L;
}
and to send a message
Message m = new Message(SystemIdent.GlobalPositioningSystem);
m.addMessageItem(new MessageDataItem(MessageDataItem.Aircraft_Altitude,ac_altitude)); m.addMessageItem(new MessageDataItem(MessageDataItem.Aircraft_Latitude_Degrees, ac_lat)); m.addMessageItem(new MessageDataItem(MessageDataItem.Aircraft_Longitude_Degrees, ac_lon)); m.addMessageItem(new MessageDataItem(MessageDataItem.Aircraft_Heading, ac_heading)); m.addMessageItem(new MessageDataItem(MessageDataItem.Aircraft_TAS, ac_true_airspeed)); ExecSystem._Transmitter.NotifyAll(m);
Using Emesary
When beginning to redevelop / refactor the existing code it became obvious that the above structure could and probably should be replaced for internal comms within the same application. To bridge the message bus across to a different application it’ll be a case of packing and / or unpacking, but within the same application space we can transmit and receive using objects – which is quicker and easier.
Databinding and datapool
What is going to be neat if I can get it to work is to allow databinding directly from the XAML to elements in datapool. Then the Simulator Host communications module can modify the bound items directly – and the rest will be taken care of automatically. Having only seriously used databinding with the EF before it may be hard to get this to work, but what I’d like to have is:
<IOS:DigitalReadout Datapool="{Binding RAXLAT}" Label="Latitude" />;
Also probably will consider binding the Label to a language system so that we can translate it.
Pages
Pages are built from XAML. Design objective here is to completely avoid the need for any code behind and to partition the pages out so that they can be built using either Visual Studio, Expression Blend, or any other XAML editor.
All of the IOS elements such as Buttons, Readouts, Plots, Maps will be implemented in one or more Custom control libraries.
IOS Processes and components
The IOS must be split into components, to provide the required parts. A monolothic approach has been proven not to work or to be maintainable.
- Pages
- Simulator host communications
- Hardcopy / Printing
- GSD (Arinc424)
- Malfunctions
- Failed Radio stations (VOR/DME, LMK, etc.)
- Ownship monitoring (approach plot,
- Maintenance facilities
To achieve this a basic IOSProcess class is defined. The requirement is to allow this to be linked into an assembly, or to be a standalone process (as requirements dictate). To achieve this flexibility we will be relying on Emesary to provide the communications between all processes.
Class diagram of IOS Process
Details of inter-process communications within the Instructor Station
As you can from the above diagram Emesary is a core component of the ExecNode (name subject to change). What is happening is that each IOS must implement the required interfaces and by doing so, and becoming part of the Emesary Transmitter located in the Exec each process is isolated from the other.
In the first instance the Exec implementation of the Transmitter / Recipient will be a simple forwarder. When working in a multi-process environment this will become an asynchronous operation. This is slightly contrary to the Emesary design and will require careful consideration to ensure that the Emesary implementation does not become a bottleneck. In the first instance message routing and filtering together with a consistent approach will be used to get this right.
A simple example is the datapool interface. Traditionally datapool has been a block of shared memory and it may remain like this, however the interface to an individual symbol needs to be isolated from this as the access to datapool could be implemented by IPC using Emesary.
The future.
As the project progresses I will keep this page updated.