[Sis-ams] AMS deliberations

[Scott Burleigh]

[Posting for Roger]

Hello Scott,

Happy New Year!

November does seem a long time ago, so I'm afraid I am having a little 
difficulty remembering what the specific issue was that I brought up 
that was not addressed by your initial AMS concept.  My main 
recollection is how well the concept fitted with the MOIMS Mission 
Operations [MO]service concept.

I will try and summarise our messaging requirements.
The application level MO services would be overlaid on a Common service 
layer.
The MO Common layer provides support for a [hopefully small] set of 
interaction patterns.
These in turn would be implemented through [potentially multiple] 
undelying communications technologies/protocols.
Obviously, it would unify the CCSDS world if there is a good match 
between these and the messaging services provided by SIS.
I attach I diagram I put together during the November meeting after your 
presentation ...



We are in the process of, but have not completed, definition of the MO 
Common Services.
My preliminary view is that we only need a small set of fundamental 
interaction patterns:

-  Publish Subscribe
-  Request/Response
-  Mail?
-  File Transfer

The following shows a summary view of our common service pattern for MO 
services:




It is the red services between service consumer and provider that we see 
as being the principle subject for AMS, although the Replay service 
should have a high degree of commonality with Observe.

Publish/Subscribe would support the MO Common "observe" service, in 
which the service Consumer would register interest in a subset of 
available objects and the Provider would respond with asynchronous 
status update messages.  The published objects are either pre-defined 
[in the configuration data] and known in advance to both consumer and 
provider, or dynamically created by the provider, in which case the 
consumer can only subscribe to a specific object if its ID has been 
obtained in advance [e.g. in a response to a Control message], otherwise 
subscription is to a scoped sub-set.

Request/Response would be used for transactional message exchanges, and 
could be used to support the MO Common "control" and "manage" services. 
 Two cases have been identified:  1) a control message from service 
Consumer to the Provider, with optional response(s) from the Provider; 
 2) a request message from service Consumer, with an associated response 
message containing the requested data.

By "Mail" I mean an e-mail like service, involving delivery of messages 
to a mailbox, that the recipient can retrieve messages from at some 
later point in time.  Useful for unsolicited messages from Provider to 
Consumer.
I'm not sure whether or not an e-Mail type interaction is necessary, or 
even whether it is significantly different to Request/Response.  I 
suppose we were starting from the position that the Request/Response 
interface is based on an open end-to-end connection/session between 
consumer and provider, while Mail implied some form of connectionless 
store-and-forward.   However, this distinction may not be necessary if 
requests and responses do not require an open connection, in order to 
handle discontinuous contact.

File/Transfer would allow for bulk data transfer between service 
consumer and provider, in either direction.  In a SIS context, we 
assumed this would be provided by CFDP, not EMS.

All services would need to exist within a partitioned context.  In this 
sense the world is partitioned in two dimensions:

"Domain":
This is used to decompose the world into a scoping hierarchy, to ensure 
uniqueness of identifiers, etc.:
i.e. Mission.Spacecraft.Subsystem.Component.Object
The same service may be instantiated for multiple domains.  Its a good 
idea to make sure you're conneting to the right spacecraft ...

"Session" or Timeframe or, I believe the term you used was "Continuum":
This is used to separate data that would otherwise be potentially 
identically keyed - live operational data, multiple simulated or test 
data series, and maybe historical replay data series.  

The timeframe can be different for each session:  the live session is 
presumably synchronised with the present;  simulated sessions can be in 
the past, present or future; replay sessions can be past or future. 
 Timeframe for simulated and replay is externally controllable - it may 
be paused and stepped; or evolve at a real-time rate, faster or slower 
than real-time, or at a random rate [e.g. as fast as possible].  Not 
sure if this has any impact at all, other than the potential for 
"continua" to be dynamically created ...
Not all services would be available for replay sessions - you can 
observe history, but not change it.

Other issues to be considered:
-  User [Consumer] Authentication:  access rights may be limited to 
certain services for certain domains and certain classes of session
-  Security
-  Quality of Service

Not sure if that's got close enough to the issue to identify the issue 
raised in November.
Sorry its a bit of a ramble ...

Roger Thompson
SciSys Ltd.
Methuen Park
Chippenham,  SN14 0GB, UK

Tel. +44 1249 466452
Mob. +44 7884 351319



	*Scott Burleigh <Scott.Burleigh at jpl.nasa.gov>*
Sent by: sis-ams-bounces at mailman.ccsds.org

26/01/2005 18:10

	       
        To:        sis-ams at mailman.ccsds.org
        cc:        
        Subject:        [Sis-ams] AMS deliberations




Hi.  The holiday hiatus behind us, it's probably time for the AMS BOF to 
start making some progress toward its goals: we're supposed to report to 
Bob on our deliberations by the end of February.

The first step is to identify a set of Requirements for asynchronous 
message exchange among spacecraft and between spacecraft and ground data 
systems.  One way to begin would be to look at the (informal) 
requirements that the design of the NASA Constellation Command, Control, 
Communications, and Information (C3I) architecture's "framework" element 
was responding to.  Another way, though, would be to look at the MOIMS 
requirements for asynchronous messaging.

Roger, I remember there was at least one technical point that you 
brought up in Toulouse, that the initial AMS concept paper didn't 
address; naturally I failed to write it down, but I'm hoping you can 
recall what it was.  Would you have a few minutes to summarize the MOIMS 
messaging requirements for this mailing list and point out areas where 
AMS as currently proposed would fall short?

Also, are there MTS requirements that we need to keep in mind when 
considering the AMS concept?  Stuart and Ashton, would you want to 
summarize for this discussion?

A couple of things I know of that have come up since November:

1.                 Abhijit confirms a point I thought of, which comes 
out of the C3I framework design: while the AMS concept as currently 
written enables QOS to be specified on a node-by-node basis (in node 
specifications at registration time), we really need QOS to be specified 
at finer granularity.  I think this means adding optional overriding 
"port specifications" (or maybe a better term would be "delivery point 
specifications") to subscriptions, so that QOS is controlled at 
subscription -- message type, subject -- granularity.

2.                 Another C3I requirement comes out of vehicle docking: 
we need to be able to merge distinct AMS continua when the physical 
platforms on which they are sited come into such close proximity that 
there is no longer any purpose served by keeping the continua separate. 
 (And, conversely, we need to be able to carve a single continuum into 
two continua when physical platforms become separated by distances that 
impose inconvenient latencies on meta-AMS traffic.)  I've got a 
mechanism for this in mind, but the details are probably a topic to work 
out in the AMS Working Group when and if it gets approved; for now I 
think it's sufficient just to identify the requirement.

Any other thoughts?

Scott

_______________________________________________
Sis-ams mailing list
Sis-ams at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-ams



-------------- next part --------------
Skipped content of type multipart/related