In The AIDA System, A 3rd Generation IMA Platform, DIANA Project White Paper page 10, I found
“AIDA remote services design shall allow multi-supplier integration compliance with DO-297 recommendations such as ARINC 661 Cockpit Display System standard service architecture.
Modern avionic architectures request a decoupled and fault tolerant communication model in a system that is considered reliable and static. As a consequence, the AIDA architecture includes an asynchronous communication model (command / event based) that allows a location transparency of remote service implementation and the object-oriented support adapted for the AIDA needs.
Another characteristic found in avionics systems, and not usually found in other applications domains, is the extensive presence of health monitors. The AIDA proposed communication model takes advantage of that, not associating by default a status to a command.
One important peculiarity of the proposed architecture with respect to existing approaches, such as ARINC 661, is that AIDA does not impose the use of commands to update data. AIDA proposes the use of a publish / subscribe data centric mechanism with content filtered topic supported by standard ARINC 653 ports and channels for data communication support. The use of content filter mechanism will largely reduce AIDA inter partition communication required bandwidth (see the two figures below).
From an implementation point of view inter-partition data communication is supported by middleware level data-centric services (publisher and subscriber services) accessing partition memory and distributing data over predefined ARINC 653 standard channels.
In summary, the above vision does not affect the approach of keeping the high level architecture compliant with ARINC 653: inter-partition communication remains port-based even if a mechanism that enhances location-transparency and reduces system integrators effort is used. Intra-partition communication remains based on ARINC 653 API services supported by the capabilities of compliant RTOS.”
The figure shows the usual Producer and Consumer. However, it has that the producer is only to send Temp information when the temperature is greater than 300 with the consumer having requested that condition.
This is something that was available in a previous avionics communications controller that I designed in regards to the requestor being able to specify the frequency with which the topic was to be sent by the producer. A consumer could request a particular topic be sent to it at a rate of its own choosing while other consumers could request the topic at other rates.
Allowing the consumer to subscribe to a topic in a way that allows it to specify the conditions under which it wants to receive the topic is something I can add to my exploratory message controller framework as well and seems like an excellent feature to provide.
I already have this to a degree with the One-of-N topic delivery style where a consumer can subscribe to the topic to only receive it if its delivery id matches certain values or range of values. In its case, the producer publishes the topic no matter what the delivery id and the framework checks if any consumer subscribed for its delivery id. If not, the instance of the topic is tossed and goes undelivered. If so, it is delivered to the particular consumer component that subscribed for it.
The kind of subscription of AIDA would be more complicated since the condition or set of conditions could vary and not just be based on particular integer values. And it would be sent to the producer since it would have to decide when to publish since one consumer could have one set of conditions and another consumer might subscribe to receive the topic under a different set of conditions. Or perhaps it would need to be One-to-One with only one publisher and one subscribing client. In any case, the framework couldn’t keep track of the conditions for delivery since the possibilities would vary from topic to topic.
This would be something like N-to-One where I have N possible requestors and one consumer of the request that produces a response that is only delivered to the particular requestor. However, for N-to-One the requestor sends a request and then synchronously gets its response. With the AIDA feature the requestor sends its request for the topic with the conditions that are to be met to send the response. Then the requestor gets its response when the conditions are met. (Once or periodically while the conditions are met? This could be another condition that is supplied such as a Frequency field in the request of 0 for only the first time the condition is met and a positive value to indicate a frequency to be sent while the conditions are met.) The various sets of conditions would be a contract between the producer of the response and the various requestors.
This feature is surely what I should choose to do next.
On page 14
“A more complex task is the protection of data leaving their partition walls. For this purpose the MILS Message Routing (MMR) component is designed. The MMR contains a privilege table defining which applications may communicate with each other and which information an application may gather from another. In ARINC 653 the messaging component may be seen as the complement to this MILS facility. The A653 messaging relies on a configuration which is defined before start-up and describes all possible communication paths within a system. This way, it is impossible that a partition sends or receives a message without authorisation. The picture changes with applications that force users to authenticate. Now, the actor, the sender or receiver of a message, is not necessarily a neutral application, but an actor with a role in the systems interaction. The respective role may have authorisation to access certain information or may not. In such a situation, the existence of a static routing description addressing partitions, ports and messages is no longer sufficient. A real access control is needed which identifies users and grants privileges to them.
The general access control performed by the MMR can already contain detailed information like client/server-configurations, message types and access levels. But it is not intended to enter protocol specifics of single applications. The MMR itself, being an OS component or a central system service, would become too complex if it integrated details of all possible types of applications and their communication protocols.”
The mentioned a privilege table reminds me of the loadable table I was going to have to identify the various allowed applications in a particular proposed avionics system and info on how they could interconnect. I have a somewhat similar loadable table in the exploratory project that defines what communication methods (MS Pipes and/or WinSock) that an application supports and the WinSock IP address to use. This could easily be expanded to specify which pairs of applications are allowed/authorized to communicate with each other. Then an attempt to connect without authorization could be refused.
“To extend the capabilities of the information flow control, made available by the MMR, MILS provides the concept of guardian applications. These guards are applications of their own, running in separate partitions, but dedicated to the protection of an application or a set of applications. Each application or set of applications may have a guard to validate the exit and entry of messages in the given context sender/receiver, contents, purpose etc. This way, security related tasks are removed from the applications and concentrated in specialised protection software.”
I currently have some validation built in. That is, that a received message was expected, has the correct header data and CRC, etc. Perhaps a “guardian” package into which to place some of this code would better emphasize its purpose and allow, at a future date, additional validation of received messages and add validation prior to the transmit of a message.
No comments:
Post a Comment