[Sis-ams] AMS interoperability testing

[Scott Burleigh]

Hi, AMS aficionados.  I've been aiming at having at least some 
preliminary results of interoperability testing to talk about at the 
October CCSDS meetings in Berlin, so I'd like to take a few minutes now 
to explore the plausibility of that goal.  Here's my current 
understanding of the state of everybody's implementations:

1.   I believe the Marshall Space Flight Center class-6 implementation 
of AMS in JAva is now just about complete, is close to conformance with 
the latest (July 24) edition of the spec, and has got at least a 
UDP-based transport service adapter.

2.   APL's class-4 implementation runs in an on-board VxWorks Real-Time 
Process environment with transport service based on POSIX message 
queues, no network stack.  My guess is that there hasn't been enough 
funding to keep the software updated to track the spec changes, though.

3.   The ESA implementation runs in an on-board RTEMS environment with 
transport service based on POSIX message queues and on SOIS packet 
service over Spacewire.  I believe it is a complete and up-to-date 
class-4 implementation.

4.   The Goddard Space Flight Center implementation has run into a 
variety of schedule challenges.  I believe it's designed for class-4 
operation in a network environment, rather than on-board, but it may not 
be ready for interoperability testing before October.

5.   As of yesterday the JPL implementation has been updated to the 
latest edition of the spec and still seems to work okay.  It is class-6 
and is aimed at operation in both network and on-board (VxWorks and 
RTEMS) environments, but currently its only on-board-specific transport 
service is VxWorks (rather than POSIX) message queues.

So I think our opportunities for interoperability testing line up about 
like this:

-   We could interoperate the MSFC and JPL implementations via UDP/IP in 
a network environment, at Marshall or at JPL or both, perhaps as early 
as September.  This testing could theoretically include RAMS test cases.

-   The APL and ESA implementations seem architecturally similar and 
both use POSIX message queues for transport.  However, interoperation in 
the near term (an ESA node in an APL environment or vice versa) seems 
unlikely as it would require that one or the other be ported to a 
different real-time operating system.

-   Operation of a JPL-based application node in either the APL or ESA 
on-board environment also ought to be possible, but again not in the 
near term: an additional JPL transport service adapter based on POSIX 
message queues would have to be developed.

-   Interoperation of the GSFC, MSFC, and JPL implementations in a 
network environment should be possible later this year.

-   Integration of an APL or ESA continuum with off-board remote 
continua ought to be possible eventually, but it will depend on the 
availability of RAMS in the on-board environment.  Integration of a JPL 
RAMS gateway (which is, after all, just an application node that knows 
how to communicate over the RAMS network) might be a way to accomplish 
this; that would entail a non-trivial effort, though, and it certainly 
won't happen before October.

Have I got any of this seriously wrong?  Are there opportunities I'm 
overlooking?

If this assessment is close to being right, then our best shot for 
near-term interoperability testing seems to be between the Marshall and 
JPL implementations.  The next issue would be development of a test 
plan.  Does anybody feel they've got time to put such a plan together 
in, say, four or five weeks?  I am pretty sure I don't.

Scott