[Sis-ams] AMS interoperability testing

[Edell, David J.]

Scott,

We should be receiving some funding in the near future to continue work
on our AMS implementation.  Dependent on when funds become available, I
should be able to help out with a basic testing plan, expanding on the
comments from Tim's draft outline a few months ago.  

A RAMS implementation would be the ideal method for future
interoperability testing for APL-AMS, although I don't know the
likelihood of completing a RAMS interface in that time frame.

Our implementation, other than the main() methods, is designed to be
largely OS-independent.  Theoretically, we should be able to port it to
another OS without too much difficulty, but I do not know enough about
RTEMS to be sure.  The details of the POSIX implementation are
definitely non-standard in its registration and configuration processes
though, so it's unlikely those components would be compatible
out-of-the-box.  

It might be plausible to do some basic node-to-node communication
testing in a special static configuration, or full communication with
APL-AMS and ESA's operating as separate cells in a single continuum.
This is of course also dependent on updating the APL-AMS implementation
to the latest standard version and other updates to implement options
(ie: multi-cell usage) not fully supported in APL-AMS.  


Stuart,
If you are interested, it could be a useful exercise to attempt some
level of interoperability testing (see above).  At the very least, it
would be productive to compare our implementations in more detail and
discuss the options for future testing.


- David



-----Original Message-----
From: sis-ams-bounces at mailman.ccsds.org
[mailto:sis-ams-bounces at mailman.ccsds.org] On Behalf Of Scott Burleigh
Sent: Friday, July 25, 2008 11:35 AM
To: sis-ams at mailman.ccsds.org
Subject: [Sis-ams] AMS interoperability testing

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


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