An Exploratory Project to Mimic A661 and Create a Publish-Subscribe Framework
Becoming retired with time on my hands I decided to pursue a PC version of experimental aerospace software designs that I had been involved with off and on in the preceding years that had been discarded by the time of my retirement. The results of this exploratory development will be discussed from time to time.
General Background
There are various papers concerning Service-Oriented Architecture (SOA). I do not claim to be knowledgeable about them with most of my inter-application communication background being before I even heard of the term. Therefore, what I will discuss of the exploratory project’s architecture may be making false associations with SOA and publish/subscribe. I only refer the reader to the “Data-Oriented Architecture” paper of Rajive Joshi and to “Building an effective real time publish-subscribe framework for a distributed embedded design” by Rajive Joshi of Real-Time Innovations, Inc as published in three parts in Embedded and in EE Times in August of 2006.
This particular project was implemented in two phases; one that created the publish-subscribe framework and a much shorter second phase that began an implementation to mimic the aerospace ARINC-661 (A661) standard using a display application that interfaces to Windows and to a publish-subscribe framework application to interpret the Windows events and command modifications of what is displayed.
The publish-subscribe framework was developed with AdaCore GNAT Pro GPS with use of the Win32Ada source library. To mimic A661, I used Microsoft for C Sharp (C#) “Microsoft Visual C# 2010 Express”.
As a keep-busy project to avoid mental stagnation the code is unverified and is also subject to any restrictions of AdaCore and Microsoft. It also requires more work – perhaps I will get around to it. Such as to make it somewhat more robust so an application can connect to the publish-subscribe network at any time, drop off and later reconnect, etc.
General Publish-Subscribe Design
Dr. Joshi’s publish-subscribe message topics of “Building an effective real time publish-subscribe framework for a distributed embedded design” are received by each of the consumers that subscribe to receive the topic. This also occurs in my “Message Controller” framework. However, I have implemented modifications for different types of topics. That is,
- A general one where every consumer receives the topic although not necessarily every instance since the consumer can be blocked preventing it from reading the instance before a new instance of the topic is published. There is only one producer of the topic and there can be many consumers. This type of topic has been designated as data flow, such as by Dr. Rajive Joshi.
- A modification of the above where an event is also sent to the consumers to notify them that a new instance of the topic is available. The event causes the registered notify method of the consumer for the particular topic to be executed.
- A N-to-One topic that is point-to-point synchronous to prevent an instance of the topic from being lost. In this case the normal delivery method is reversed with multiple producers of the topic and only one consumer. The consumer also produces a response that is only received by the producer of the original request and only if the original request producer registered to receive it. The consumer’s topic notify method is executed for each request that is queued by the message controller.
- A One-of-N topic that is also point-to-point synchronous in so far that the instance of the topic is delivered. In this case the topic contains a delivery identifier so that multiple consumers can register for the topic but only for those instances with particular delivery identifiers. A particular use for this type of topic is the delivery of the A661 events where particular consumers register to treat events from particular “widgets” using their widget identifier as the delivery identifier. A particular instance of the topic will only be delivered to the component that registered for the delivery identifier contained in the topic.
The applications are organized as a number of components that interface to each other via the message controller framework. The components are loosely coupled in that they can only communicate with each other via the message topics. When a component becomes installed to the framework it registers itself with the framework as to how it is to be executed to accomplish its objectives. The options are whether
- A component is to be event driven where it is only run if an instance of an event driven topic has been published. When run it can then consume the latest instance of data flow topics for which it has registered. An event driven component will be run after a producer has published an instance of an event driven, N-to-One, or One-of-N topic.
- A component is to be periodic where it is to be run at a particular interval. Such a component cannot be notified of new instances of a topic and can only produce topics that do not require a response and be a consumer of the latest instance of a message topic.
- A component is to be pseudo periodic where it will run in its own loop and issue a delay to allow lower priority components to run. As with periodic components, a pseudo periodic component can only produce topics that do not require a response and read the latest instance of message topics for which it has registered to consume.
However, a component can be written such as to separate itself into two sub-components where one registers as event driven and the other as one of the of periodic styles. Then the event driven sub-component can, for instance, register to publish a N-to-One topic and consume the response but the periodic sub-component can be the one that actually publishes the topic using the key obtained by the event driven sub-component. The event driven sub-component will receive the response and can save it for the periodic sub-component to examine (in a thread-safe way) the next time it runs. In such a case the component, if it is to be moved to another application, it must be moved in its entirety and not just one of the sub-components. Therefore, they should be packaged as sub packages of the same Ada package or sub units of the same C# class such that an application won’t build if only some of the sub-components are moved.
After the component has registered itself it also registers for the topics it needs to read/consume and those that it will produce to complete its install. The message controller framework confirms the validity of the topic registration within the particular application. That is, any component after the first to register as the consumer of a N-to-One request, any component after the first to register to publish a data flow, event driven, One-of-N topic, etc are rejected. This is an area that could use more work when multiple applications exist.
The components are such that they can be moved from one application to another in the distributed network. That is, after they become installed and have registered the topics that they need to consume or that they will publish, the framework determines whether another component of the particular application can satisfy the component’s requests. If not, a register request topic is broadcast to allow other applications to respond to indicate if they have an installed component that can satisfy the need. If so, the requesting application records the application to which to forward the message topic and sends an acknowledgment to the responding application. The responding application then records that it will need to forward the N-to-One request or receive a message to route to one or more of its components to consume the topic. Thus the framework of each application can lookup either the local component(s) to which to forward an instance of a topic or the remote application(s). In the case of one to many topics, a combination of local components and remote applications can be forwarded the topic instance. And a component can be moved from one application to another and still receive and send its messages. Upon receiving a message, the framework examines its header to determine the topic and then forwards it as if it had been locally published.
The message controller framework allows components to be small with a limited purpose. This reduces their complexity and limits their interfaces.
The content and format of each message is declared in a topic package/class. To allow a topic to be distributed between multiple applications each topic has a standard header that is private to the message controller framework. This header really isn’t needed if all the components that register for the topic install themselves within a single application. However, it is always a hidden part of a topic to allow some of the components to be moved to another application later. (Note: For ease of identification, a standard naming convention has been used so that all coding units that are part of the message controller begin with “mC.”, all coding units that declare message topics begin with “mT.”, and all coding units that are part of a component begin with “Com”. This means that code with a like purpose will sort together in a directory/folder.)
The contents of an instance of a message topic are stored in a reusable buffer. This buffer cannot be directly accessed. Instead, the successful instantiation of a new topic reader or writer returns a pointer to the buffer. The reader’s pointer is to the consumer component’s buffer. A reader can then examine the message without the need to move it to component’s local storage unless to be saved for later reference (that is, after the component has ceased its current execution). A writer must, of course, move the data to the buffer via the pointer before it can publish the topic. After the message controller has determined that all local components have had a chance to read an instance of the topic (or a new instance of a data flow topic will replace it), the buffer is released to allow its reuse.
General Considerations to Imitate A661
ARINC-661 is an aerospace specification for the communication protocol between aerospace “user” applications and a display processor that manages the displays and communicates the click, enter, etc events to the application that “owns” a particular display “layer”. The particular user application interprets the event message that it receives and commands any modifications of what is to be displayed. The particular “widgets” (buttons, labels, edit boxes, list boxes, etc) that the display processor is to render are described in an XML file as described by the A661 specification. As such, the application of the display processor is a general application that only obtains what is to be displayed from the XML that is loaded into it and it only passes along operator initiated events to the owning user application.
Therefore, my display application works in a similar way. It obtains a description (quite abbreviated since I was only investigating what would be needed) from a text file to specify the Windows forms and controls to be displayed. To simplify the application, it communicates with only one user application. Bypassing most of the A661 protocol used to initiate the connection, the display application shows the initial form described in the text file as soon as a connection is made. After that, modifications of the display only happen due to “commands” from the user application in response to events sent to it by the display application.
Consequently, what is displayed is controlled by the user application and the descriptor file. A different descriptor file and a different user application means a different set of displayed Windows forms and controls (corresponding to A661 widgets) without change of the display application. Also, with the use of the message controller, different components of multiple applications can respond to the Windows events of particular widgets and be in charge of a group of widgets to distribute the responsibility for the display among multiple components.
