[Sis-ams] revised AMS concept paper

[Scott Burleigh]

Stuart Fowell wrote:

>Hi Scott,
>
>Sorry I've been quiet recently, project pressures unfortunately.
>During a sick day yesterday (yes this is sad I know) I finally found
>time to read the concept paper.
>  
>
No problem at all, Stuart, and I hope you're feeling better.

>I think you've done a very good job and I only have a couple of minor
>comments (from the perspective of SOIS and MTS):
>
>1. From the on-board perspective, determining Worst Case Delivery Times
>would be necessary. Clearly this must be dependant upon the underlying
>communications protocols, buses etc, but AMS/MTS should not preclude
>this from being calculated.
>  
>
I think this sort of calculation will be easier when the underlying 
transport system is something fairly deterministic, like message queues, 
but in general I don't think anything about the AMS/MTS design precludes it.

>2. I'm not sure if just 3 levels of priority is sufficient for on-board
>software. Perhaps this is more relevant to users of AMS/MTS in queuing
>events for dispatching.
>  
>
I'm not opposed; let's explore this in some more depth within the 
Working Group when it gets chartered.

>3. These levels of priority should be respected at each stage in the
>delivery mechanism, e.g. where-ever any resource contention or buffering
>occurs. Should be high priority before low priority, FIFO within a
>priority level based on received time (as opposed to original send time
>- which would necessitate access to a global time).
>  
>
Sure, a reasonable blanket statement to add to the spec.

>4. Page 3, message notifications. Please clarify if "delivery success"
>means receiving user has read message or that it is queued ready for
>user to receive.
>  
>
The latter, really: it's up to the application to issue some sort of 
application-level notice of the former.  Section 4.3.6 discusses this.

>5. For acceptance in the on-board software community we would need to
>work up an example deployment on a minimal system to demonstrate roughly
>the resources required (CPU, tasks, memory etc) and fault handling.
>  
>
Yep, we're working on that now.  I have fond hopes of having a prototype 
running by September.  Hey, stranger things have happened.

Scott