Exploratory Project Component Specified Verification Function

Exploratory Project Component Specified Verification Function

Reflecting upon a past aerospace project last night concerning implementation concerns that I had had while doing DO178B level A reviews a new feature to add to my exploratory project came to mind.

The aerospace code that came to mind was code that was involved with the receive and use of messages from particular ARINC 653 ports.  My problem with the code had to do with the haphazard way the received data was checked.  A message would have verification of its validity performed in various places in the code along with checks as to whether the values of various fields were such as to indicate that the message should be used.  The validation done would be inconsistent from the treatment of one port versus another.  And fields would be checked for usefulness before the validity of the message had been completely determined.  Also, various checks would be done in different paths of the code and in different called routines making it difficult to determine if all the necessary checks had been done / would get done. 

At the time I thought how such code should be redone to have a particular set of validation functions.  One to perform the necessary checks of any port message and another for each receive port to be called following the first that would check the values of the various fields as to whether the message was usable.

It occurred to me that my proposed routines to check the received values would have been similar to the Content Filtered messages of my Exploratory Project; except that they would be run after the message was received rather than prior to sending it.

Then I thought of how supplying a special verification routine to the message delivery system of the exploratory project would cause the checks to always be performed first.  That is, a particular consumer could reverse the existing Content Filtered message exchange mechanism to specify its own filter as a callback at the time it registers for the topic.

The framework already allows each topic to have a verify function specified for it to determine if a received topic is valid prior to allowing the instantiation of a Reader for it.  By also allowing a consumer component to specify its own filter/verify function would ensure that the topic message had values in the ranges that were acceptable for use by the consumer prior to its attempting to use them.  In fact, for point-to-point topics, the message communication framework could even avoid delivering the topic instance if the contained fields that would cause it to be ignored.  (But then would be executing the function in the thread of the framework rather than in the thread of the user component.)

In any case, when the topic verify was requested by a component to obtain the pointer to the message data, the framework could first execute the common verification of the topic as it does now and then run the particular filter/verify function of the component.  If the topic data didn’t pass both validations, invalid would be returned and the data pointer would be null preventing the component from using the data.

Also the message would always be validated prior to be used with the validations being done and their order easily identified for certification.

To be consistent, the framework most likely should not execute the verify/filter function to determine whether to deliver it to the component when the instance of the topic is published.  That is, it would be difficult to do this for publish/subscribe topics.  And the function would be executed in the thread of the framework sometimes and in the thread of the consumer component in others.  And, of course, for a remotely published topic it would have to be received by the local app before the local framework could execute the filter/verify function. 

Such a verify/filter function would be a combination framework attribute of the topic and the consumer and would initially be supplied at the time the consumer registers for the topic.  An additional feature could be the ability to allow a component to change the registered filter/verify callback to be executed as conditions change as the application runs or to supply a null callback to discard filtering.

Service-Oriented Architecture Attributes Progress Report 3

Service-Oriented Architecture Attributes Progress Report 3

This progress report has been significantly delayed – mainly because I have been interested in something else – but also since checking out some of the restructured attributes and added topic delivery methods was more challenging then expected.  Particularly when the topic had to be delivered to a component of a remote application.

One change was to treat Content Filtered topics similarly to Request/Response topics.  This made both methods of message exchange examples of the previous N-to-One delivery category. 

I hadn’t thought of Content Filtered as really N-to-One, thinking that multiple consumers could answer requests.  But I found this a problem when I went to implement the second instance of the topic since I didn’t have a mechanism to send the request to multiple consumers.  So I cloned the Content Filtered topic as a second such topic so the remote consumer component could treat a different topic. 

If I am to have multiple consumers to send responses to the multiple requesting components for a particular filter condition, then I need to have a different way of treating this.  And would might be the consequences if more than one component detected that the filter conditions were satisfied so that the requesting component got multiple responses. 

This message exchange would be M-to-N.  That is, a variety of both One-of-N and N-to-One where instead of the delivery identifier of One-of-N selecting which of the N consumers was to receive the message, the request message would be sent to each consumer.  That consumer would then need to decide if it could respond to one or more of the filter conditions and save those in its filter table.  Then when the conditions were satisfied, send its response to each of the requestors that ask for a response under those conditions.  It would be sending a One-to-One Point-to-Point response multiple times.

This would be a whole different ballgame from what I have had.  So, for now at least, Content Filtered is an example of N-to-One in that there is one consumer of the request.  And, instead of sending an immediate, synchronous response to the particular requestor, it sends the delayed asynchronous response to all the components that requested a response when the particular filter conditions were satisfied.

This was implemented and checked out with both locally delivered messages within a particular application and remotely delivered to components of another application for message exchange of No Exchange (broadcast to be delivered to any subscriber), Delivery Identifier (One-of-N), Request/Response and Content Filtered (both examples of N requestors to One consumer/responder).