ATV Data Link Simulator: A Development based on a CCSDS Layers Framework

Transcription

1 SpaceOps 2010 Conference<br><b><i>Delivering on the Dream</b></i><br><i>Hosted by NASA Mars April 2010, Huntsville, Alabama AIAA ATV Data Link Simulator: A Development based on a CCSDS Layers Framework Javier Peña 1 and Nick Priborsky 2 LSE Space Engineering and Operations AG, Münchner Str 20, Wessling, 82234, Germany Fabio Sintoni 3 KIBB GbR, David-Gilly-Str 1, Berlin, 14469, Germany and Jean-Christophe Ronnet 4 ESA, 18 Ave Edouard Belin, Toulouse, 31401, France I. Introduction Following the first ATV mission ( Jules Verne ), ESA identified the need to procure a data flow simulator that is capable of supporting the test of the complete TM and TC chain including the RF links. The main objectives of the simulator are to Help troubleshooting activities in case of anomalies Verify correct configuration and operation of Ground Segment Equipment Test the configuration and operation of Ground Segment Equipment prior to tests with the spacecraft such as System Validation Tests As the physical layer of the ATV mission uses the SQPN (Staggered Quadrature Pseudo-random Noise) modulation format, it is not possible to use existing ESA simulators since they do not support SQPN modulation. In order to reduce costs, it was proposed to use an existing spare TM/TC baseband unit to simulate the RF part of the ATV spacecraft. The TM/TC Baseband Unit is normally used to receive TM and transmit TC. In this case however, it is used to transmit TM and receive TC thereby mimicking the behavior of the ATV spacecraft. Unfortunately, the baseband unit is not capable of supporting all required functions of the coding layer in such a setup. Therefore a solution had to be found that is capable of adding the missing functions to the system. LSE Space Engineering and Operations AG was able to propose a cost efficient solution based on a development framework that had already been developed for another project. The name of the framework is CCSDS Layer Framework and was part of the development of GSAT. GSAT is a generic satellite simulator that fully implements the relevant CCSDS protocols. It is used by LSE Space as a generic spacecraft simulator to test ground segment equipment and to train staff. The CCSDS Layer Framework is a Java library that encapsulates the following CCSDS Recommendations: CCSDS B-1 TM Synchronisation and Channel Coding CCSDS B-1 TM Space Data Link Protocol CCSDS B-1 Space Packet CCSDS B-1 TC Synchronisation and Channel Coding 1 Senior Software/Ground Systems Engineer, Javier.pena[at]lsespace.com 2 Ground Systems Engineering Manager, Nick.priborsky[at]lsespace.com 3 ATV Ground Segment Engineer, sintoni[at]kibb-space.com 4 Head of the ATV Ground Segment Section, Jean-Christophe.Ronnet[at]esa.int 1 Copyright 2010 by the, Inc. All rights reserved.

2 CCSDS B-1 TC Space Data Link Protocol CCSDS B-1 Communications Operation Procedure-1 It allows a software developer to efficiently implement the CCSDS layers of a given spacecraft mission and perform mission specific adaptations. This paper presents the design and implementation of the CCSDS Layers Framework and the advantages of using such a framework on the basis of the development of the ATV Data Link Simulator. II. Architecture of the CCSDS Layers Framework The architecture of the CCSDS Layers Framework is best described with the help of an example. This example will use the CCSDS TM Coding Layer. A. Example of CCSDS TM Coding Layer The CCSDS recommendations not only define the protocols that are going to be used but also which services shall be provided by each layer. Following figure gives an outline of the functionalities that the Space Telemetry Coding Layer provides: Figure 1: CCSDS Coding Layer 2

3 As can be seen in Figure 1, only the attachment of the Attached Sync Marker is a mandatory function that must be performed by the Coding Layer. It is up to the mission designers to define which other functions need to be used due to mission constraints. The fact that some services are mandatory and some are optional needs to be reflected by the framework in order to enable the developer to easily configure the mandatory and optional parts of the layer. Additionally, the CCSDS Recommendation defines two service primitives for the coding layer: 1) ChannelAccess.request (frame): The upper layer (master channel layer) requests the codification of a frame to the Coding Layer. 2) ChannelAccess.indication: Primitive used by the coding layer to send the coded frame to the lower layer (physical layer). B. Modeling of the TM Coding Layer The layers defined by the CCSDS Recommendations are modeled as Java Interfaces thereby only defining their behavior but not specifying a concrete implementation. The sending side of the TM Coding Layer is named ISpaceTmCodingLayer. The relevant interfaces of the sending TM Coding Layer side are outlined in the UML Class Diagram Figure 2 below. Figure 2: ISpaceTmCodingLayer UML Diagram The Coding Layer interface defines the method codeframe(tmframe) that is used to forward transfer frames from the Transfer Layer to the Coding Layer. This method represents the ChannelAcces.request primitive as defined by the CCSDS Recommendation. The Coding Layer interface provides a Set & Get method to associate a physical layer with the coding layer. This association will be used by the Coding layer to call the ChannelAccess.indication primitive to forward the output of the coding layer to the Physical Layer. An advantage of using interfaces becomes apparent here. The coding layer does not need to know anything about the specific implementation of the physical layer. The actual implementation of the physical layer could be a network connection to a TM/TC baseband unit, a physical connection to RF equipment or it could connect directly to a Mission Control System or Control Center using the relevant network protocols. 3

4 The remaining setter and getter methods are used to configure the functions of the TM coding layer. A function worth mentioning is frame encoding. Here again, interfaces provide additional decoupling of concerns. To achieve this, an interface named IEncoder is defined in the framework. This interface must be implemented by all encoders thereby ensuring that the actual encoding implementation remains transparent to the TM coding layer. In case a mission would like to use a custom encoding algorithm, it is as simple as implementing the IEncoder interface and the coding layer would then be able to use the new algorithm without having to change any internal code of the layer. C. Default implementation and Hook Methods Every layer has a set of common functionalities that are mission independent (for example attachment of the Attached Sync Marker). The default implementation of the layer extracts the common functionalities and implements these so that they can be reused by the mission specific implementation. Additionally, some functionality related to low level development can be added here thereby making it available to the specific implementation (i.e. Property listeners to make easier the GUI development, or multithreading). This way the actual implementation of the layers for a specific mission will not have to rewrite any common code. Moreover, the default implementation needs to be extendable. This can be achieved by the use of so called Hook Methods. These are empty methods placed strategically in the default implementation code. This way the classes that derive from the default implementation only need to rewrite these extension points. Thus the code defining the basic common functionality of the layer is not affected. Figure 3: codeframehook Method Diagram Figure 3 shows how the hook method concept is applied to the codeframe Method of the TM coding Layer. The codeframe(etmframe) method implements a multithreading strategy to decide whether an additional thread is required to code the Frame or not. Then it will call the hook method codeframehook(etmframe) which will do the actual coding of the TM frame. In case the default implementation needs to be adapted only the 4

5 codeframehook(etmframe) method would have to be rewritten in the subclass. The codeframe(etmframe) method with the multithreading support will remain untouched and will be inherited by the mission specific implementation of the Coding Layer. The two approaches (default implementation and hook methods) are used in order to maximize the reusability of the code within the Framework with all the advantages that it brings. As explained, the default implementations are used as the base for the implementations of all the layers that either come with the framework or are derived from the framework. This, however, does not exclude the possibility of creating an implementation outside of the framework by implementing the layer interface directly. In addition, the default layers can be used out-of-the-box as they contain the common functionality of the layer. D. Intercepting filter pattern Thanks to previous experience in space-related software development, it was realized that there are still some cases that are not properly handled by the design. For example, it may be required to dump the output of the coding layer to the local file system or to a central logging facility. This information can be used for troubleshooting activities or to fulfill logging requirements. It would be possible to add this functionality by using hook methods. But this would result in having to use a series of conditional checks. Unfortunately, this would make the code less readable and maintainable as the flow of the layer and the processing of the data would be compiled into the layer itself. The key to solve this common problem in a flexible and unobtrusive manner is to have a simple mechanism for adding and removing processing components. This software design pattern is known as the Intercepting Filter Pattern. This pattern is frequently used in the CCSDS Layers Framework. The use of this pattern forces: Reusability of common processing components. Centralization of common logic. Components can be easily added or removed without affecting existing components, so that they can be used in a variety of combinations. Interceptor Client Filter Filter 1 Chain.. Filter N intercept dointerception Some processing dointerception Some processing Figure 4. Intercepting Filter Sequence Diagram 5

6 Figure 4 gives an overview of the flow of the Intercepting Filter Pattern. The use of the Intercepting Filter Pattern ensures that the Space Telemetry Coding Layer not only follows the CCSDS recommendation but is flexible enough to cope with mission specific requirements without interfering with the rest of the framework. Figure 5. DefaultSpaceTmCodingLayer UML Diagram The UML Diagram in Figure 5 shows how the interceptor pattern was added to the ISpaceTmCodingLayer interface. The methods setbeforetmframecodinginterceptorchain and setaftertmframecodinginterceptorchain enable the developer to unobtrusively add processing components that may be required by mission specific constraints. III. Development of ADLS with the CCSDS Layers Framework It was decided to break the work to be performed down into two main areas of expertise: Capability and configuration of TM/TC Baseband Unit Development of ATV TM/TC chain customization A. Capability and configuration of TM/TC Baseband Unit As already stated in the introduction, TM/TC baseband units are normally used to receive TM and transmit TC. But due to cost constraints, it was proposed to use a spare TM/TC baseband unit as the RF component of the ATV Data Link Simulator. An analysis of the capabilities of the TM/TC baseband unit revealed that it was not capable of supporting all required functions of the coding layer. 6

7 TM TC Transfer Layer CLCW Transfer Layer TM Transfer Frame TC Transfer Frame Reed Solomon encoding Attachment of Attached Sync Marker Convolutional encoding Codeblocks CADU Channel Symbols Coding Layer BCH Decoding CLTU CLTU sync and extraction Bit stream Convolutional decoding Channel Symbols Physical Layer Physical Layer Figure 6: Coding Layer Functional Block Diagram As detailed in Figure 6, the red boxes identify tasks that are not supported by the TM/TC Baseband Unit but will have to be implemented in software instead. These tasks are: Reed Solomon Encoding Attachment of Attached Sync Marker Detection and extraction of CLTU from the bit stream BCH Decoding of CLTU All of these tasks are supported out-of-the-box by the CCSDS Layers Framework. Therefore, it was possible to quickly assemble an ADLS prototype for testing the TM/TC baseband unit configuration and the interface to the ADLS. Moreover, the CCSDS Layers Framework provided most of the code needed for the development of an MCS simulator. With these tools it was possible to carry out a test to prove that the proposed solution was viable. This was a very important step as it enabled the verification of the proposed set-up. Thereby the overall project risk was greatly minimized. 7

8 TCP/IP Intermediate Frequency TCP/IP MCS Simulator Main TM/TC Baseband Unit Spare TM/TC Baseband Unit Simulator Notebook Redu Ground Station Figure 7: TM/TC Baseband Equipment Test Diagram Figure 7 gives an overview of the preliminary test set-up that enabled the stakeholders to gain confidence in the proposed solution. The TM/TC Baseband Unit experts were no longer needed for the ADLS development and the resources could be freed for other projects. B. ATV TM/TC Chain Customization The next step was to implement the customization of the TM and TC Chain for ATV. Following specializations had to be performed Verification of ATV TC packets Generation of ATV Telecommand Acknowledgment TM packets Update of the time field of archived TM packets to simulate real-time TM Specific TM frame data field for the ATV TM Archiving of TM and TC stream The rest of the TM /TC Chain functionalities were already provided by the CCSDS Layers Framework such as FARM part of COP-1 protocol (AD Mode support) Check of TC Frame, check of TC Segment and the extraction of the TC packet TM flow control The integration of the customizations for ATV, thanks to the CCSDS Layer Framework design explained in the previous sections, was performed seamlessly. For example, the TM hexadecimal file archive was efficiently implemented by the use of the Interceptor pattern in the TM Coding layer. The Telecommand Verification task was added by implementing the ISpaceTcSpacePacketVerificationService interface. None of these customizations required any change to the Framework. Therefore, the ADLS reuses a large part of the CCSDS Layers Framework that has already been tested and used by other projects. This has facilitated the testing and the debugging of the ATV TM/TC Chain customizations, as it was easier to isolate bugs. 8

9 IV. Conclusion Using the CCSDS Layers Framework provides benefits in following domains: A. Technical Domain Robust Software: Thanks to the high level of reusability that the framework provides both in code and testing. Maintainable, scalable and extendable: The decoupling of concerns through the use of interfaces and the adoption of software design patterns such as the Intercepting Filter Pattern makes it easier to cope with future requirements and to integrate them with the existing framework. Debugging/Troubleshooting: As the amount of code that is prone to change is concentrated in certain points it is easier to focus the debugging and troubleshooting on known areas. Increase Productivity: The framework promotes loose coupling between modules and layers of the development thereby encouraging and promoting parallel development. Agile Development: As the framework provides default implementations it enables the use of agile development techniques and facilitates rapid prototyping. B. Management Domain Human Resources: New team members can become productive quickly as they only need to know the part of the framework that they are working on. Risk Management: Allows the developers to concentrate on the critical parts of the development at a very early stage, thereby decreasing the project risks. 9