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.