1. Document Roadmap

1.1. Overview This section summarises the set of standard documents, types, and the related testing proposed in support of fulfilling all of the requirements for defining a fully standard, compliant, and interoperable SM&C Mission Operations Services Concept. The following diagram presents the proposed top level documentation tree: Spacecraft Monitor and Control

Specifications Technology Language SM&C Mappings Mappings Concept

Service Specific Service Encoding Specifications (optional)

Reference Language Model API

Message MAL Abstraction Encoding Layer (MAL)

Green Book Application Magenta Book Profile

Blue Book

Spacecraft Monitor and Control

SM&C Specifications Technology Concept Mappings

Service Service Specific Specifications Encoding

Reference Model Generic Encoding Message Abstraction Layer Application Profile

Green Book Language Magenta Book API Blue Book Figure 1-11: Top Level Document Set

In the following sections each of the document types are expanded.

1.2. SM&C Service Concept

1.2.1. Overview The SM&C Mission Operations Services Concept document provides a complete overview for the entire collection of functions and services that are to be defined. This includes ground services to support mission operations and the respective flight side elements. It also provides an overview of the specific services and how they relate to the missions operations functions that will use them.

1.2.2. Book colour Green – Informational

1.2.3. Current status and issue Issued as “Mission Operations Services Concept CCSDS 520.0-G-2”, August 2006.

1.2.4. SLE equivalent Cross Support Concept—Part 1: Space Link Extension Services, CCSDS 910.3-G-2 – A report introducing the concepts of cross support and the SLE services;

1.2.5. Book contents The Service Concept book contains:  Outlines the basic concept  Outlines the context of SM&C  Outlines the proposed SM&C sevices  Presents the SM&C documentation structure, and shows how this document fits into that framework. TBW

1.2.6. Book source Existing document.

1.2.7. Required changes Update to reflect current SM&C service concept and also to include the correct document roadmap derived from this document. 1.2.8. Prototyping requirements None.

1.3. SM&C Reference Model

1.3.1. Overview The Reference Model provides a common basis for coordinating the development of CCSDS Recommended Standards for Spacecraft Monitor and Control service specifications and serves as a reference to maintain the consistency of these Recommended Standards.

1.3.2. Book colour Magenta – Recommended Practice

1.3.3. Current status and issue Does not exist.

1.3.4. SLE equivalent Cross Support Reference Model—Part 1: Space Link Extension Services, CCSDS 910.4-B-1 – A Recommended Standard that defines the framework and terminology for the specification of SLE services. This is currently identified as a Blue Book, but it’s contents are really Magenta Book material.

1.3.5. Book contents The Recommended Practice contains:  The context of SM&C, presents the SM&C documentation structure, and shows how this document fits into that framework.  It defines the SM&C system environment, data handled by an SM&C system, and introduces SM&C services.  It defines an architectural model for the SM&C system. This architectural model comprises two views: o A functional view which defines the system concepts, including functions and data, from which the services are derived. o A service view which defines the services and how they are composed, along with data and control flow views for example deployments. o A management view, which defines the management interactions between the entities involved in the provision of services. o

1.3.6. Book source Generic Reference Model material to be taken from the existing MAL book. 1.3.7. Required changes Model material shall be updated and expanded to contain equivalent to that contained in the SLE Reference Model.

Specifically it shall contain concepts, relationships of books, system level considerations such as how to string service elements together, how the various layered books will work together, as well as a more complete SLE-like RM.

1.3.8. Prototyping requirements Because these are abstract definitions there are no testing requirements for these this books . They It must be validated for completeness and consistency, but this can be done by inspection, possibly augmented with some automated translation and machine checking [if an appropriate technology is available]. 2. SM&C Specifications

2.1. SM&C Message Abstraction Layer

2.1.1. Overview The Message Abstraction layer (MAL) provides the basic toolkit of operations and messages of whichthat all SM&C services use to build their service specifications. It provides a standard abstract service to the higher MO services so that they can concentrate on the service specifics and remain transport and encoding agnostic. The MAL formal specification defines the specific services required of the underlying message transfer service in terms of abstract service interfaces with requests, indications, and responses.

2.1.2. Book colour Blue – Recommended Standard

2.1.3. Current status and issue Currently a proposed Red Book CCSDS 521.0-R-1.1 dated June 2008

2.1.4. SLE equivalent Any existing SLE Transfer Services, such as CLTU or RAF. First part of Cross Support Transfer Services Specification Framework, CCSDS 921.1-R-0 draft 0.15.

2.1.5. Book contents The Recommended Standard defines, in an abstract manner, the MAL in terms of:  The abstract definition of the MAL service provided interface(s);  The abstract definition of the services required from the underlying layers;  the Common Object Model operations;  the behaviours of each operation template;  the state models of the operation templates;  the messages structures and interactions necessary to constitute describe the operation templates;  the parameters associated with each messagee;.  the data types that build the messages.

It does not specify:  individual upper layer application services, implementations or products;  the implementation of entities or interfaces within real systems;  the methods or technologies required to acquire data;  the methods or technologies required to provide a suitable environment for communications; or  the management activities required to schedule the service. 2.1.6. Book source Existing MAL book, the Common Object Model from the Common Services book plus new material to define behaviour, state machines, abstract interfaces and concrete messages and data types.

2.1.7. Required changes Removal of material destined for the Reference Model. Specification of message headers, data types, and extensible message PDUs in an abstract but unambiguous formal notation (proposal of ASN.1XML Schema). Formal specification of operation templates (Interaction Patterns) using an unambiguous formal notation (proposal of ASN.1 or UML). Requires sequence, activity and state machine information.

2.1.8. Prototyping requirements There shall be at least two independently implemented instances of these specifications. They shall be tested, over a single underlying message transport and technology binding, and verified for interpretability, interoperability, and correct operation in a representative operational environment.

Each and every option and feature defined in the formal specification shall be independently tested and verified. Any failure to interoperate correctly shall be analyzed and the formal specifications shall be modified such that they can be unambiguously interpreted. If any options or features of these specifications cannot or are not successfully tested they shall be removed from the final formal specifications.

These tests shall be completely described and documented. The details of the test bed used to drive the testing and the details of the underlying technology binding shall be fully documented. The details of all of the tests of all of the features and options shall be fully documented.

See section 5.1 for more information. 2.2. SM&C Mission Operations Services

2.2.1. Overview

The following diagram presents the proposed documentation tree for the SM&C Mission Operations Services. These are the formalized, implementable specifications for each of the mission operations services that are defined to use the underlying MAL and Common services, data types, message types, and interaction patterns. While the MAL and Common specifications defines the baseline set of data types, message structures and set of possible interaction patterns, these Mission Operations Services specify the content and meaning of the messages they use to communications their requests and responses, and the specific set of interaction patterns used to provide each service.

These documents contain the following set of formal, interoperable, specifications:

SM&C Services

Common Services: Blue Book

Core M&C Service: Blue Book

Time Service: Blue Book

Software Management Service: Blue Book

Automation Service: Blue Book

Scheduling Service: Blue Book

Planning Request Service: Blue Book

Data Product Management Service: Blue Book

Location Service: Blue Book

Flight Dynamics Service: Blue Book

Remote Buffer Management Service: Blue Book

Figure 2-22: Mission Operations Service Specification Document Roadmap Each of these service specifications are to be defined in a complete, formal, unambiguous fashion, such that they can be directly implemented and tested. These are all expected to be defined using the services, protocols, messages, data types, and interaction patterns defined in a formal MAL specification.

In addition to referencing the other baseline Blue Books, each Mission Operations Service formal specification shall define the services offered at its own Service Access Point (SAP) and its behaviour in terms of requests, indications, and responses at this abstract interface. Each service shall also define the formal message contents and meanings, using the relevant MAL Blue Book message structure and data type specifications. A, and each mission operations service shall define its own behaviour in terms of internal operations and in terms of the set of interactions and message patterns that it exchanges with its peer service entity. These shall all be defined in reference to the relevant MAL Blue Book.

If any of these service specifications require new data types, message structures, or interaction patterns outside those supported by the MAL these shall be formally documented by updating the MAL Blue Book specification.

2.2.3. Current status and issue Common Service a proposed Red Book CCSDS 521.1-R-1.1 dated June 2008 Core Service a proposed Red Book CCSDS 522.0-R-2 dated June 2008

2.2.4. SLE equivalent

CFDP defines application layer services for data management that may also provide a useful analogy for these services.

Common service has no direct equivalent but similar to Procedures in Cross Support Transfer Services Specification Framework, CCSDS 921.1-R-0 draft 0.15

Core service similar in level of specification to SLE Forward CLTU Service Specification, CCSDS 912.1-B-1

2.2.5. Book contents The Recommended Standards defines the SM&C MO services in terms of:  The abstract service interface;  the operations necessary to provide the service;  the message structures and contents exchanged;  the parameter data associated with each operation;  the required behaviour of each operation;  message interchange patterns during operation of the service;  the use of the service.

They do not specify:  individual implementations or products;  the implementation of entities or interfaces within real systems;  the methods or technologies required for communications.

2.2.6. Book source Existing material.

2.2.7. Required changes Addition of ASN.1 formal notation normative Annex for PDUs. Much more rigorous definition of operations using state UML diagrams where appropriate.

Specifically for the Common Service: Removal of Common Object Model to new MAL Blue Book.

2.2.8. Prototyping requirements There shall be at least two independently implemented instances of each of these specifications. They shall be tested, over a single underlying MAL and technology binding, and verified for interpretability, interoperability, and correct operation in a representative operational environment.

These Blue Books shall be prescriptive enough to be directly implemented when defined in reference to the MAL and a technology mapping Blue Book.

Each Mission Operations Service Blue Book shall formally define its own service SAP, behaviour, message contents, usage of interaction patterns, and usage of the MAL and other services in clear and unambiguous terms.

All aspects of the service shall be demonstrated and tested. Each and every option and feature defined in the formal specification shall be independently tested and verified. Any failure to interoperate correctly shall be analyzed and the formal specifications shall be modified such that they can be unambiguously interpreted. If any options or features of these specifications cannot be or are not successfully tested they shall be removed from the final formal specifications.

These tests shall be completely described and documented. The details of the test bed used to drive the testing and the details of the underlying technology binding shall be fully documented.

See section 5.2.3 for more information. 3. Technology Mappings The lowest layer in the SM&C stack is the one that provides the actual message transfer and encoding service for the Message Abstraction Layer (MAL).

The MAL formal specification defines the specific services required of the underlying message transfer service in terms of abstract service interfaces with requests, indications, and responses. A technology mapping translates these abstract required services into the capabilities provided in its concrete message transfer service. The following diagram presents the proposed documentation tree for the SM&C Technology Mappings:

SM&C Technology Mappings

Java JMS MAL Encoding: Magenta Book 1

CCSDS Space Packet Encoding: Blue Books 2

CCSDS AMS MAL Encoding: Blue Book 3

XML MAL Encoding: Blue Book 4

Other Technology Mappings: Magenta/Blue Book ..

SM&C Technology Mappings

Java JMS Mapping: Magenta Book

CCSDS Space Packet Encoding: Blue Books

CCSDS AMS Mapping: Magenta Book

XML Encoding: Blue Book

Other Technology Mappings: Magenta/Blue Book

Figure 3-33: Technology Mappings Document Roadmap

The technology mappings must translate the concrete MAL service and message model into a specific protocol tied to specific protocol data units (PDU). The Each Technology Mapping Recommendation casts the MAL formal data types and messages into specific bit representations appropriate to that protocol, there are two primary standardisation streams for this, the Magenta book for Recommended Practices where existing standards are applied, and the Blue book for Recommended Standards where a new standard is created.. It should be noted that themappings to transports that do not provide an interoperable protocol such as Java JMS mapping cannot be considered a Blue book as it only defines a mapping to an API (Java JMS) and does not provide entity to entity interoperability. These shall, however, be supported via a Magenta book.

There are two types of encoding propsedproposed, the primary one is a mapping from the abstract formalt MAL notation to the specific technology, basically a mapping at the MAL level. There is one Blue book per encoding that applies to all defined services.

The secondary case, the exception case, is where for optimisation reasons the data structures at the service level are mapped directly to the encoding. The rule here however is that the existing relevant MAL encoding is also used so that the layering is not violated.

3.1. Generic Technology MappingMAL Encodings

3.1.1. Overview A generic MAL encoding technology mapping defines a standard transform from the data types, message structure combination rules, and interaction patterns of the MAL into the relevant wire level protocol and PDUs of that technology.

Because theany MO service specificationss are defined in terms of the MAL using a formalt notation the generic MAL mapping can be used, without modification, to transform the abstract notation of the MO service specifications into the relevant wire level messages.

3.1.3. Current status and issue None.

3.1.4. SLE equivalent None applicable.The SLE transfer service API (CCSDS 914.0-M-0.1.1) that describes how to map the SLE abstractions to and API, or the CCSDS 913.1-R-1 that describes how to map the SLE abstractions to TCP/IP should offer useful guidance.

3.1.5. Book contents The Recommended Standard defines a mapping from the abstract notation of the MAL to an unambiguous wire level protocol, more specifically:  how the specific technology shall be used;  how any transmission errors or issues shall be communicated to higher layers;  all link level issues shall be defined;  the physical representation of the abstract MAL messages necessary to constitute the operation templates;  the mapping of the message structure rules for that technology;  the physical representation of the abstract MAL data types

It does not specify:  individual application services, implementations or products;  the implementation of entities or interfaces within real systems;  the methods or technologies required to acquire data;  the management activities required to schedule a service;  the representation of any service specific PDUs (this is derived from the encoding rules defined in this document)

3.1.6. Book source To be written.

3.1.7. Required changes Not applicable.

3.1.8. Prototyping requirements The technology mappings MAL Encodings must be complete, unambiguous, and implementable Blue Books and therefore there is a requirement for two independent implementations of each technology mappingone. If a bridge specification is defined between two or more technology mappings bridge is developed it must be tested and verified for interoperability with two independent, but previously tested and fully verified, instances of the MAL &, Common protocols and mappings., and test bed.

NOTE: There is a benefit to developing and validating a reference test bed that can be reused for testing of future instances of the SM&C services. This reference test bed must contain fully tested, validated, and verified instances of each of the MAL, Common and Mission Operations Services service layers, along with the required test jgigs and test scripts for each layer. However, for the technology mappings there will still need to be two independent implementations of that mapping layer validated within the test bed.

There needs to be defined a test ‘service’ that fully demonstrates all aspects of the MAL that is defined in the technology mapping. This test service can be an aspect of the reference test bed.More details are given in section 5.2.1.

3.2. Service Specific Technology MappingEncoding

3.2.1. Overview For cases where a service should be explicitly mapped into a technology for efficiency or other reasons then it is supported in the SM&C concept for that to be defined in a service specific encoding technology mapping Blue Book. A service specific encoding defines the exact representation for each service PDU in that technology rather than using the standard transform defined in the relevant MAL encoding; this allows optimisations to be made based on context specific knowledge.

In this case, when using this specific service and technology combination it is expected that the service specific technology mapping shall be used.

However it may be the case that a generic stand alone MAL technology mapping is also possible in which case it must be clear which is being used for a specific deployment either via agreement or through some technology of that mapping.

It should be noted that a service specific encoding does not break the SM&C layering concept as the service specific encoding must still use the existing relevant MAL encoding. However it may be the case that use of just the standalone MAL technology mapping is also possible in which case it must be clear which is being used for a specific deployment either via agreement or through some aspect (header field for example) of that mapping.

3.2.3. Current status and issue None.

3.2.4. SLE equivalent None. Is there any equivalent in CCSDS or elsewhere? This reads like it is defining a mapping from Application Layer 7 down to a Link Layer 2, skipping every other layer in between. How is this supposed to work with the MAL?

3.2.5. Book contents The Recommended Standard defines a mapping from the abstract notation of a specific MO service specification to an unambiguous wire level protocol, more specifically:  how the specific technology shall be used;  how any transmission errors or issues shall be communicated to higher layers;  all link level issues shall be defined;  the MAL encoding that is to be used;  the physical representation of the abstract messages necessary to constitute the operations;  the mapping of the message structure rules for that technology;  the physical representation of the abstract MAL data types if different from the underlying MAL encoding

It does not specify:  individual application services, implementations or products;  the implementation of entities or interfaces within real systems;  the methods or technologies required to acquire data;  the management activities required to schedule a service;

It may shall be based on a generic MAL Encoding Technology Mapping and in that case may only contain the physical representation of the abstract service messages.

3.2.8. Prototyping requirements The technology mappings must be complete, unambiguous, and implementable Blue Books and therefore there is a requirement for two independent implementations of each technology mapping.

More details are given in section 5.2.2. There needs to be defined a test suite that fully demonstrates all aspects of the service that is defined in the technology mapping, and that all aspects of the used MAL encoding are correct..

3.3. Application Profile Technology Mapping

3.3.1. Overview An Application Profile provides a Recommended Practice for the use of a standard technology with the SM&C concept. Because it is a Recommended Practice it must not define any standard aspect but except for how the existing standard, or standards, should be used.

NOTE: Normally an Application Profile MB would defineof how to use a complete stack of protocols, i.e. one or more MOsServices, running over the Common and MAL layers, mapped onto some specific underlying technology mapping. It might even can also define how to bridge across two different technology mappings. But what is described in this section sounds more like what ought to appear in a technology mapping, such as was partly defined in Sec 3.1, except that was somehow conceived of as “Generic”. I suggest combining these and providing a proper Application profile if one is needed.

3.3.2. Book colour Magenta – Recommended Practice 3.3.3. Current status and issue None.

3.3.4. SLE equivalent SLE – Internet Protocol For Transfer Services, Red Book, CCSDS 913.1-R-1, October 2005

3.3.5. Book contents The Recommended Practice defines an application profile of standards that map from the abstract notation of the MAL to an unambiguous wire level protocolcan be used to solve a specific issue or deployment use, more specifically:  which existing standards shall be used at each layer being address;  how the specific technologies shall be used;  how any transmission errors or issues shall be communicated to higher layers;  all link level issues shall be defined;  the standard encoding that defines: o the physical representation of the abstract MAL messages necessary to constitute the operation templates; o the mapping of the message structure rules for that technology; o the physical representation of the abstract MAL data types

It does not specify:  individual application services, implementations or products;  the implementation of entities or interfaces within real systems;  the methods or technologies required to acquire data;  the management activities required to schedule a service;  the representation of any service specific PDUs (this is derived from the encoding rules defined in this the referenced standards document)

It differs from a Generic Technology Mapping in so much that it references other standards and details how they shall be used rather than define any mapping rules itself.

3.3.8. Prototyping requirements TBWDue to this being a Magenta Book there is no specific requirement for two independent implementations however there needs to be evidence provided that actual implementation experience of the profile has been obtained and that it does provide or solve the purpose for which it was specified.

4. APIs

4.1. Language API

4.1.1. Overview Language mappings or Application Programming Interfaces (API) are not normative specifications. They play a useful role in application portability, but play no role in interoperability. They provide a convenient interface specification that translates the abstract service access point (SAP) definitions of the MAL, Common, and Mission Operations Services into a language specific interface that can be used by programmers. The API must be faithful to the abstract services defined in the SAP and it must, by some means, provide access to the features of the services and all of their options.

The following diagram presents the proposed documentation tree for the SM&C Language Mappings:

SM&C Language Mappings

Java Language Mapping: Magenta Book

Python Language Mapping: Magenta Book

C++ Language Mapping: Magenta Book

C Language Mapping: Magenta Book

Other Language Mappings: Magenta Book

Figure 443-44: Language Mappings Document Roadmap

These are Magenta Books as they have no effect on interoperability. They provide a standard API for that binds the abstract model for to a specific programming language, they also define a standard transform that maps the abstract service specifications into that language.

4.1.2. Book colour Magenta – Recommended Practice 4.1.3. Current status and issue Draft Java API under development.

4.1.4. SLE equivalent SLE – Application Program Interface for Transfer Services – Core Spec, Draft Recommended Practice, CCSDS 914.0-M-0.1, October 2005 SLE – Application Program Interface for Return All Frames Service, Draft Recommended Practice, CCSDS 915.1-M-0.1, October 2005 SLE – Application Program Interface for Return Channel Frames Service, Draft Recommended Practice, CCSDS 915.2-M-0.1, October 2005 SLE – Application Program Interface for Return Operational Control Fields Service, Draft Recommended Practice, CCSDS 915.5-M-0.1, October 2005 SLE – Application Program Interface for The Forward CLTU Service, Draft Recommended Practice, CCSDS 916.1-M-0.1, October 2005 SLE – Application Program Interface for The Forward Space Packet Service, Draft Recommended Practice, CCSDS 916.3-M-0.1, October 2005

4.1.5. Book contents The Recommended Practice defines a mapping from the abstract notation of the MAL to an unambiguous language API, more specifically:  how the specific technology MAP abstract services are mapped to the selected languageshall be used;  how any transmission service errors or issues shall be communicated to higher layers;  the physical representation of the abstract MAL messages at the interface necessary to constitute the operation templates;  the mapping of the message structure rules for that technologylanguage;  the physical representation of the abstract MAL data types in that language.

It does not specify:  individual application services, implementations or products;  the implementation of entities or interfaces within real systems;  the methods or technologies required to acquire data;  the management activities required to schedule a service;  the representation of any service specific PDUs or operations (this is derived from the language transform defined in this document)

It should be noted that there is only one Recommended Practice defined for each language rather than one for language and service combination. This differs from the SLE API model. The SM&C Language Mapping shall define a generic transform that can be applied to all SM&C service specifications. For this to be possible the service specifications must completely adhere to the operation templates and rules specified in the MAL, they are not allowed to diverge from this without updating the MAL.

4.1.6. Book source Existing material. 4.1.7. Required changes Alignment with final book material.

4.1.8. Prototyping requirements The testing expected for a language mapping is one of completeness and correctness. All aspects of the MAL and by extension any MO sService must be supported in an API, this is the completeness test. No language specific aspects must be introduced that would have a requirement on the lower technology mappings, for example the addition of a new data type.

The language mappings shall be tested by implementing the API and application layers of the a reference test bed for one of the stacks. For example, once two completed implementations of one layer have been fully tested and verified it they can then serve as a testbed for other implementations. If the test bed was originally written in Java then replacing one of the two implementations with an implementation written in some other language under test, that adheres to that language underlying technology mapping, must be able to run the interoperability tests as normal.

Note that the APIs for these two different languages need not be identical in form or fit, but that the implementations must be identical in function. I.e. they must be fully interoperable with any other compliant implementation regardless of language used or the API exposed to programmers.

More details are given in section 5.2.4. 5. Prototyping With the exception of the Green book and the Reference Model each of the books of the Standards track require some degree of prototyping. This can be an expensive task and therefore it is planned to develop a reference test bed that minimises the amount of effort required to test new specifications. To reach this point there needs to be developed an initial verified reference implementation.

5.1. Initial MAL Prototype The initial development shall follow the CCSDS Blue book prototyping requirements to validate two independent implementations of the MAL specification. At the same time this initial prototyping activity shall be used to prove the initial Language API mapping, in this case Java. To do this there shall be specified a ‘Test Service’ that shall exercise all aspects of the MAL specification, this will be specified using the service specification rules and notation of the MAL BB so that the Service transformation of the Java Language API mapping can be validated.

Test Code Service Specific API Service Stub/Skeletons MAL Standard APIs MAL Implementation Transport Adapter Message transport

Implementation #1 Implementation #2

Test Application Test Application

Service Specific API Service Specific API

Service Stub/Skeletons Service Stub/Skeletons

MAL API MAL API S S e e c c

Sec Sec A MAL Implementation MAL Implementation A P Impl P Impl I I

Standard Transport API Standard Transport API

Transport Adapter Transport Adapter Implementation Implementation

Message transport Messaging Middleware

Figure 5-55: Initial MAL prototype

The following sections detail each element of the prototype stack, also defining which aspects must be independently implemented and which aspects may be shared for this initial development.

5.1.1. Test Application Implements the actual tests that exercise all aspects of the MAL. The specification of this and the ‘Test Service’ it uses are fully defined in the test plan. It has a backdoor link to the Security Implementation to control the behaviour of that component for the access control tests. Single shared implementation

5.1.2. Service API The Java representation of the abstract ‘Test Service’. This is derived from the ‘Test Service’ by using the transform specified in the Java API specification. Both parties produce their own.

5.1.3. Service Stub/Skeletons The layer of code that maps from the Service API to the MAL API in Java. This is derived by using the transform specified in the Java API specification. Both parties produce their own. 5.1.4. MAL API The standard MAL API in Java as specified in the Java MAL API specification. Is a set of Java interfaces that shall be independently implemented to verify that it is fully specified in the Java Book. Both parties produce their own.

5.1.5. MAL Implementation Both parties produce their own.

5.1.6. Security API The standard MAL Security API in Java as specified in the Java MAL API specification. Is a set of Java interfaces that shall be independently implemented to verify that it is fully specified in the Java Book. Both parties produce their own.

5.1.7. Security Implementation Provides the required access control and security component for the test. Specification of the functionality of the component shall be in the test plan. It can be considered an aspect of the Test Application. Single shared implementation

5.1.8. Standard Transport API The standard MAL Transport API in Java as specified in the Java MAL API specification. Is a set of Java interfaces that shall be independently implemented to verify that it is fully specified in the Java Book. Both parties produce their own.

5.1.9. Transport Adapter Implementation Maps from the standard transport API to the relevant interface for the chosen transport. This mapping is either fully specified in a relevant CCSDS specification or fully documented in the test plan. Single shared implementation

5.1.10. Message Transport Standard component

5.2. Reference test bed The reference test bed should will be developed as part of the first set of Blue Book and technology mapping language API prototyping activities. Basically, with careful consideration during the design and development of the two independent prototypes for the initial Technology Blblue Bbook much of the prototype can be reused when testing other aspects of the SM&C service concept:

Test Code Service Specific API Service Stub/Skeletons MAL Standard APIs MAL Implementation Transport Adapter Must be changed to test Message transport a new language mapping

Test Application Test Application

Must be changed to test Service Specific API Service Specific API a new service specification

Service Stub/Skeletons Service Stub/Skeletons

MAL API MAL API S S e e c c

Sec Sec A MAL Implementation MAL Implementation A Impl P P Impl I I

Transport Adapter Transport Adapter Must be changed to test Implementation Implementation a new technology mapping

Message transport Messaging Middleware Application Layer SM&C Layers Must be changed to test Transport Layer a new language mapping

Application Application Must be changed to test a new service specification Service API Service API

MAL API MAL API

Must be changed to test MAL Implementation MAL Implementation a new technology mapping

Message transport Messaging Middleware Figure 554-66: Reference Test Bed

The initial instance of the test bed (see section 5.1) will develop two complete, independent, implementations of the formal MAL and a representative test service specifications. These will be tested using an agreed test bed that drives the SAP represented by the “MAL API” layer. This initial instance will also select some agreed underlying technology mapping (referred to as the Message Transport in this diagram). This Message Transport will be verified using a test bed at the layer labelled “Standard Transport API” in this figure. These two MAL implementations will be verified using the single underlying Message Transport. Each stack is implemented in a specific language, they do not have to be the same language, and it could be argued that they should not be. The Applications implement a ‘Test service’ that fully tests all aspects of the SM&C specification.

The following sections detail what must be replaced for each type of book and how that must be tested The same sort of testing will be done of each new Mission Operations Service as they are implemented and tested using the MAL API. Similarly, each Mission Operations Service will have its own test bed operating at the appropriate Service API.

5.2.1. Testing a new technology mappingMAL Encoding Technology mapping To test a new MAL Encoding technology mapping, the messaging middleware 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), the standard API for that would obviously change also, and then therefore there would need to be two independent implementations of the MAL Transport Adapter for that new technology. The MAL API does not change as that is defined by the language mapping and provides a standard API to the MAL for that language. From this the Standard Transport API point upwards everything remains the same on both sides, i.e. the implementations of the ‘test service’.

It should be noted that there may be a generic aspect of a MAL implementation that is tied to the programming language rather than the protocol and that this could be reused for different technology mappings. It may also be the case that the language mapping defines a standard API for these technology adaptors in which case this should be used to further reduce the amount of code that changes and therefore the effort to produce the new prototypes. Since it is possible that a new technology mapping would require a new MAL implementation there is a need It is expected that the MAL test service test shall be partially if not completely automated therefore for a complete set of MAL tests to be run from the MAL SAP downshall be executed to verify the transport interoperability.

5.2.2. Testing a new Service Specific Technology mapping For Service Specific technology mappings, where a service has been specifically represented in a specific technology, then the full validation of that service must also be performed. Because a service specific technology mapping must be based on a specific MAL Encoding it is not necessary to perform any MAL level testing as that shall already have been done during the testing of that MAL Encoding. The most obvious instance would be if a CCSDS Space Packet technology mapping were to be defined such that these Space Packets, which presumably would be message structures passed across some Transport Mapping service interface, were also used as the exposed message structures at the MAL service interface.

5.2.3. Testing a new Service Specification If a new Mission Operations Service is to be tested then new test applications or test bed 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 services. 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.

5.2.4. Testing a new language mapping If a new Language mapping is to be tested then one of the implementation stacks would be replaced by a completely new implementation using that language, and indicated by “Implementation #2”. Each layer of this new implementation must be tested against an existing implementation that has already been thoroughly tested and verified. It must be able to interoperate with no issues using each of the Test beds at each layer and with a representative suite of mission operations services and user applications.