M&C and MAL/SPP Prototyping test bed
July 2012
2
Content
M&C and MAL/SPP Prototyping test bed ......................................................... 1
1.
Overview ................................................................................................... 5
1.1. Testing a new MAL technology mapping ............................................ 5
1.2. Testing a new Service Specification ................................................... 6
2.
Software components ............................................................................... 7
2.1. MAL implementation and stub generator ............................................ 7
2.2. Service implementation ...................................................................... 8
2.2.1. M&C prototype ............................................................................. 8
2.2.2. MAL/SPP prototype ...................................................................... 8
2.3. Transport adapter implementation ...................................................... 9
2.3.1. M&C prototype ............................................................................. 9
2.3.2. MAL/SPP prototype ...................................................................... 9
2.4. SPP Messaging layer ......................................................................... 9
2.5. Tests and FitNesse ........................................................................... 10
2.5.1. Tests definition ........................................................................... 10
2.5.2. Test classes ............................................................................... 10
2.5.3. Test report .................................................................................. 11
2.6. Common test bed utilities.................................................................. 11
2.7. SPP test bed utilities ......................................................................... 11
3.
Java libraries........................................................................................... 12
3.1. Both prototypes................................................................................. 12
3.2. MAL/SPP prototype .......................................................................... 12
3.3. M&C prototype .................................................................................. 13
4.
Tools ....................................................................................................... 14
4.1. Maven ............................................................................................... 14
4.2. Git ..................................................................................................... 14
4.3. FitNesse............................................................................................ 14
5.
MAL/SPP Prototyping effort .................................................................... 15
5.1. Transport adapter implementation .................................................... 15
5.2. Tests implementation ........................................................................ 15
6.
M&C Prototyping effort ........................................................................... 17
6.1. Service providers implementation ..................................................... 17
3
6.2. Tests implementation ........................................................................ 17
4
1. Overview
The reference test bed has been developed as part of the MAL Blue Book and
Java API prototyping activities. Much of the test bed can be reused when
testing other aspects as shown by the following figure:
Test Code
Service Specific API
Service Stub/Skeletons
MAL Standard APIs
MAL Implementation
Transport Adapter
Message transport
Must be changed to test
a new language mapping
Implementation #1
Test Application
Test Application
Service Specific API
Service Specific API
Service Stub/Skeletons
Service Stub/Skeletons
MAL API
MAL API
MAL Implementation
MAL Implementation
Standard Transport API
Standard Transport API
Transport Adapter
Implementation
Transport Adapter
Implementation
Must be changed to test
a new service specification
Sec API
Sec API
Sec
Impl
Implementation #2
Sec
Impl
Must be changed to test
a new technology mapping
Message transport
Messaging Middleware
Reference Test Bed
The initial instance of the test bed has developed two complete, independent,
implementations of the formal MAL and representative test service
specifications.
The following sections detail what must be replaced for each type of book and
how that must be tested
1.1. Testing a new MAL technology mapping
To test a new MAL technology mapping, the messaging transport would be
replaced by the new technology. The MAL standard Transport API would not
change (as it is part of the MAL specification and the relevant Language
mapping) therefore there would need to be two independent implementations
of the Transport Adapter for that new technology. From the Standard
Transport API point upwards everything remains the same on both sides, i.e.
the implementations of the ‘test service’.
It is expected that the MAL test service shall be partially if not completely
automated therefore a complete set of MAL tests shall be executed to verify
the transport interoperability.
5
1.2. Testing a new Service Specification
If a new Service is to be tested then new test applications that use that
service, and the language specific service API for that service, would need to
be developed and tested, using a tested and validated reference version of
the underlying MAL. The application testing executed would be suitable for
that specific service, but would need to demonstrate all aspects of the new
service. Two independent implementations of the peer service entities would
need to be developed and validated.
6
2. Software components
The parts of the test bed are built as a set of Maven
(http://maven.apache.org/) components and hosted in a shared component
repository (no code only binaries shared). This permits not only automated
build and dependency management of the two application stacks but also the
use of automated test tools.
The test bed consists of the following components:
a) MAL implementation and stub generator
b) Service implementation
c) Transport adapter implementation
d) Messaging layer
e) Tests and FitNesse
f) Common test bed utilities
g) SPP test bed utilities
2.1. MAL implementation and stub generator
Two MAL implementations have been developed, one by ESA and one by
CNES.
Only one MAL implementation is enough to test a MAL technology mapping.
However two independent implementations of M&C service providers and
MAL/SPP transport adapter will be necessary to validate interoperability.
As currently only the Java MAL API is complete and fully available, both M&C
service and MAL/SPP transport adapter implementations and test code shall
be compliant with the Java MAL API and reuse an existing Java MAL
implementation and stub generator. The stub generator shall be used to
generate the specific service API (e.g. M&C API or test API). Then the
corresponding implementation can be developed.
The Maven artifacts are:
Library
Artifact identifier
Status
CNES MAL API
org.ccsds.moims.mo
Reused
cnes-mal-api
CNES MAL
implementation
CNES stub
generator
fr.cnes.mal

mal-impl-base

mal-impl-security

mal-impl-broker
fr.cnes.genstub
Reused
Reused
genstub
7
2.2. Service implementation
2.2.1. M&C prototype
For M&C service prototyping, two independent implementations of this service
specified in document 522x1R2[draft3] shall be developed by DLR and ESA.
Then exhaustive tests of this specification shall be built using FitNesse
formalism (see 2.5) to cover all assertions of the CCSDS M&C specification
Those tests may be shared between ESA and DLR and shall conform to
FitNesse formalism (see 2.5).
The Maven artifacts are:
Library
Artifact identifier
Status
M&C service
providers
implemented by
DLR
Not yet defined
To be implemented by
DLR
M&C service
providers
implemented by
ESA
Not yet defined
To be implemented by
ESA
2.2.2. MAL/SPP prototype
For MAL/SPP prototyping no service implementation is required, except if
some more test services are needed. The MAL prototyping test services
should be enough. However there may be a need for additional test services.
The Maven artifacts are:
Library
Artifact identifier
Status
MAL prototype test org.ccsds.moims.mo
service stubs
cnes-malprototype-stubs
generated by
CNES
Reused
MAL/SPP
prototype test
service stubs
generated by
CNES
To be generated by
CNES
Not yet defined
(if needed)
8
2.3. Transport adapter implementation
2.3.1. M&C prototype
For M&C prototyping, an existing transport adapter developed for the MAL
Blue Book tests shall be reused.
The Maven artifacts are:
Library
Artifact identifier
Status
MAL/RMI transport org.ccsds.moims.mo
adapter provided
MOIMS_TRANSPORT_RMI
by ESA
Reused
String encoding
module provided
by ESA
Reused
org.ccsds.moims.mo
MOIMS_ENCODING_STRING
2.3.2. MAL/SPP prototype
For MAL/SPP prototyping, two independent implementations of this transport
specified in document 524x1R1 shall be developed by DLR and CNES. Then
exhaustive tests of this specification shall be built using FitNesse formalism
(see 2.5) to cover all assertions of this CCSDS MAL/SPP specification. Those
tests may be shared between DLR and CNES and shall conform to FitNesse
formalism (see 2.5).
As currently only the Java MAL API is complete and fully available, both
transport adapter implementations shall be compliant with the transport API
specified by the Java MAL API Magenta Book.
They shall also use a common SPP messaging layer providing the Space
Packet Protocol primitives. This SPP messaging layer is implemented by
CNES.
The Maven artifacts are:
Library
Artifact identifier
Status
MAL/SPP
transport adapter
provided by DLR
Not yet defined
To be implemented by
DLR
MAL/SPP
transport adapter
provided by CNES
Not yet defined
To be implemented by
CNES
2.4. SPP Messaging layer
A Space Packet Protocol (SPP) Socket API has been defined in order to
separate the MAL/SPP transport adapter layer from the mechanisms used to
9
actually send and receive Space Packets. A TCP SPPSocket layer has been
implemented.
The Maven artifact is:
Library
Artifact identifier
Status
SPP Socket
Not yet defined
To be implemented by
CNES
2.5. Tests and FitNesse
2.5.1. Tests definition
FitNesse (http://fitnesse.org/) provides a special Wiki language enabling to
define tests. Tests are a set of FitNesse pages. The test output is generated
as HTML web pages.
FitNesse enables to use the same formalism when specifying the tests and
running them. As a consequence tests are described only once using the Wiki
language provided by FitNesse.
The top level test application Java class provides a set of methods for
performing the various tests and these are invoked by the Wiki pages, the
output of which is formatted into an HTML report.
Here is a Fitnesse test scenario example coming from the MAL prototyping
tests:
|scenario| test pattern | interact | transitions | trans |
|ensure |pattern initiation | @interact | transitions | @trans |
This scenario is then instantiated once by the following script:
|script| pattern test|
|test pattern | Invoke| transitions | [ACK, RESPONSE] |
This script calls the method:
public boolean patternInitiationTransitions(String pattern,
String[] transitions) throws Exception
The parameters “Invoke” and {“ACK”, “RESPONSE”} are passed. Once the
method has returned, FitNesse checks that the result is TRUE.
2.5.2. Test classes
Some test classes have to be implemented according to the FitNesse Wiki
pages.
Moreover, for the MAL/SPP prototype, some classes from the MAL prototype
tests probably have to be extended in order to add specific MAL/SPP
assertions.
The Maven artifacts are:
Library
Artifact identifier
Status
10
MAL/SPP
prototype tests
Not yet defined
To be implemented by
DLR and CNES
Not yet defined
To be implemented by
DLR and ESA
(without FitNesse
scripts)
M&C prototype
tests
(without FitNesse
scripts)
2.5.3. Test report
The test report is mainly automatically generated, however some manual
editorial modifications are necessary to produce the required CCSDS Yellow
book. This editorial work will be done by ESA for M&C prototyping and by
CNES for MAL/SPP prototyping.
2.6. Common test bed utilities
The test bed utilities are the core of the test bed programming framework.
The Maven artifact is:
Library
Artifact identifier
Status
Test bed
framework
org.ccsds.moims.mo
Reused
MOIMS_TESTBED_UTIL
2.7. SPP test bed utilities
Some additional utilities are required by the MAL/SPP prototyping test,
especially a Space Packet interception API to be provided by the SPP layer
(messaging layer). This will be developed and provided by CNES.
The Maven artifact is:
Library
Artifact identifier
Status
SPP test bed
framework
org.ccsds.moims.mo
To be implemented by
CNES
MOIMS_TESTBED_MALSPP_
FRAMEWORK
11
3. Java libraries
The Java libraries are a set of Maven artifacts. The following sections give the
list of libraries:
a) for both prototypes;
b) specific to MAL/SPP prototype;
c) specific to M&C prototype.
3.1. Both prototypes
Library
Artifact identifier
Status
Test bed
framework
org.ccsds.moims.mo
Reused
CNES MAL API
org.ccsds.moims.mo
MOIMS_TESTBED_UTIL
Reused
cnes-mal-api
CNES MAL
implementation
CNES stub
generator
fr.cnes.mal

mal-impl-base

mal-impl-security

mal-impl-broker
fr.cnes.genstub
Reused
Reused
genstub
3.2. MAL/SPP prototype
Library
Artifact identifier
Status
MAL prototype test org.ccsds.moims.mo
service stubs
cnes-malprototype-stubs
generated by
CNES
Reused
MAL prototype
tests
Reused
org.ccsds.moims.mo
MOIMS_TESTBED_MAL
(without FitNesse
scripts)
SPP test bed
framework
org.ccsds.moims.mo
MOIMS_TESTBED_MALSPP_
To be implemented by
CNES
FRAMEWORK
12
MAL/SPP
transport adapter
provided by DLR
Not yet defined
To be implemented by
DLR
MAL/SPP
transport adapter
provided by CNES
Not yet defined
To be implemented by
CNES
MAL/SPP
prototype tests
Not yet defined
To be implemented by
DLR and CNES
Not yet defined
To be generated by
CNES
(without FitNesse
scripts)
MAL/SPP
prototype test
service stubs
generated by
CNES
(if needed)
3.3. M&C prototype
Library
Artifact identifier
Status
MAL/RMI transport org.ccsds.moims.mo
adapter provided
MOIMS_TRANSPORT_RMI
by ESA
Reused
String encoding
module provided
by ESA
org.ccsds.moims.mo
Reused
M&C service
providers
implemented by
DLR
Not yet defined
To be implemented by
DLR
M&C service
providers
implemented by
ESA
Not yet defined
To be implemented by
ESA
M&C prototype
tests
Not yet defined
To be implemented by
DLR and ESA
MOIMS_ENCODING_STRING
(without FitNesse
scripts)
13
4. Tools
The following tools are used:
a) Maven: http://maven.apache.org/
b) Git: http://git-scm.com/
c) FitNesse: http://fitnesse.org/
4.1. Maven
Java projects are built with Maven and delivered as artifacts through a
common repository hosted by SCISYS.
4.2. Git
A common Git repository is provided by SCISYS.
4.3. FitNesse
As already mentioned in section 2.5, FitNesse is used to specify and run the
tests.
14
5. MAL/SPP Prototyping effort
The MAL/SPP prototyping effort can be divided in two major steps:
a) the implementation of two independent MAL/SPP transport adapters;
b) the definition and the implementation of the prototyping tests.
5.1. Transport adapter implementation
Each participant (DLR and CNES) has to implement a MAL transport adapter
according to the MAL/SPP book.
Moreover this transport adapter has to be compliant with:
a) the Java MAL API, especially the transport API;
b) the Space Packet Protocol Socket API.
5.2. Tests implementation
Every assertion specified in the MAL/SPP book (using the CCSDS “terse”
style) has to be tested. For example:
4.2.3.1 The field ‘Type’ shall be assigned according to the MAL
header fields ‘InteractionType’ and ‘InteractionStage’ as defined by
the table...
The MAL prototyping tests scenarios will be reused as far as they can be.
Their scope should be enough to cover all the test cases required by the
MAL/SPP book. However there may be a need to add some more test cases.
Moreover, even if the MAL prototyping tests are reused, it is necessary to
extend them with the additional assertions defined in the MAL/SPP book. The
aim of the MAL/SPP prototyping test is to check the assertions defined in the
MAL/SPP book, not those defined in the MAL book. So reusing the MAL
prototyping tests is just a mean to minimise the amount of overlap in all the
prototyping tests and maximise the amount of reuse in order to keep the effort
down.
Most of the MAL/SPP assertions take place at the link level, in the messaging
layer. Checking those assertions require to intercept the Space Packets and
analyze their content: headers and body. So the transmitted Protocol Data
Unit (PDU) will have to be fully analyzed and compared to the expected binary
format as specified by the MAL/SPP book.
As a first step, the MAL/SPP prototyping tests have to check the protocol from
the inside (analyzing the PDUs) so they guarantee that the MAL/SPP book is
well defined. This step can be done with only one MAL/SPP transport adapter
implementation.
As a second step the MAL/SPP prototyping tests have to check that two
independent MAL/SPP transport adapters can communicate with each other
through the MAL prototyping tests. This step enables to demonstrate that
there is no ambiguity in the MAL/SPP book and that two independent
implementations can be interoperable.
15
The tests implementation effort is to be shared among participants (DLR and
CNES).
16
6. M&C Prototyping effort
The M&C prototyping effort can be divided in two major steps:
a) the implementation of two independent set of M&C service providers;
b) the definition and the implementation of the prototyping tests.
6.1. Service providers implementation
Each participant (DLR and ESA) has to implement a set of service providers
according to the M&C book.
Moreover these service providers have to be compliant with the Java MAL
API.
6.2. Tests implementation
Every assertion specified in the M&C book (using the CCSDS “terse” style)
has to be tested.
The tests implementation effort is to be shared among participants (DLR and
ESA).
17