Octave: A Portable, Distributed, Opened Platform for Interoperable Monitoring Services

Transcription

1 SpaceOps 2006 Conference AIAA Octave: A Portable, Distributed, Opened Platform for Interoperable Monitoring Services C. Pipo * CS Communications & System, ZAC de la Grande Plaine Rue de Brindejonc des Moulinais, Toulouse, France PA. Cros CS Communications & System, ZAC de la Grande Plaine Rue de Brindejonc des Moulinais, Toulouse, France Octave is a ground application for processing and monitoring telemetry. Many applications are developed on the basis of these requirements. Since the very beginning however, Octave has been driven by an ambitious goal: genericity. As a result, it is designed to be used in a variety of contexts such as test bench platforms, space control centers etc. The key for Octave is standardization. The condition for communicating easily with consumers is the use of standardized interfaces. The CCSDS description of telemetry has made it possible to develop a dynamic, non-specific processing monitoring task. Recent distributions have embedded the monitoring task into a distributed portable Java platform which is powerful and offers authentication, security, storage facilities and many other services. Built upon CORBA, this open platform can interoperate with any applications. For more interoperability between spatial agencies, Octave is a ready candidate to implement SM&C (Spacecraft Monitoring & Control) standards. Nomenclature SM&C = Spacecraft Monitoring and Control CCSDS = Consultative Committee for Space Data Systems DEDSL = Data Entity Dictionary Specification Language by CCSDS IDL = Interface Definition Language by OMG OMG = Object Management Group TM = Telemetry TMFlow = Telemetry Flow XTCE = XML Telemetric & Command Exchange by OMG I. Introduction In the context of spatial telemetry exploitation, many specific programs are developed because very few standards exist. Based on CCSDS DEDSL-XML standard for telemetry description, the Octave platform offers services to handle telemetry. Evolutions of Octave are always driven by genericity so that it could be used in many different contexts where telemetry is present. II. Octave monitoring function * Software engineer, christophe.pipo@c-s.fr, and AIAA Member Grade for first author. Software engineer, Pierre-alban.cros.pipo@c-s.fr, and AIAA Member Grade for second author. 1 Copyright 2006 by the, Inc. All rights reserved.

2 The main goal of Octave is to decode telemetry. This chapter describes how this function has been defined and implemented. A. Specifics to generics study The table below shows that starting from existing spacecraft control centers implementations, Octave extracted abstract concepts and proposed scalable implementations to fulfill the most number of real life contexts. Real life Abstract concept Octave Implementation Raw telemetry station Stream from a location URL First stream operations (add headers, control checksums etc.) Data acquisition Configurable stream router Stream multiplex, demultiplex etc. Stream transformations Combination of high customizable stream routers Extracting parameters from stream Stream parsing Generated parser Exploiting parameters values Distribution Dispatcher of events to observers Archiving Stream observer that pushes into a location Special acquisition observer Replay stored telemetry Creates a stream from the storing Configured router to read from location the storage location As a result, telemetry treatment consists in the following stages: Acquisition Preprocessing Decoding Distribution Archiving Figure 1 Workflow of telemetry treatment A. Main components for telemetry treatment The global concept of TMFlow gathers some stages described previously. It is the glue around telemetry treatment that allows final user to understand and to perform friendly piloting operations like start, stop, hold, step, resume Under the hood of TMFlow : Acquisition chain is the component in charge of preprocessing tasks. It consists in a particular router for main acquisition and several routers (see Packetizer 1) to perform possible transformations ; OctaveDecom is the name of the syntactic and semantic parser that produces physical telemetry for distribution. StorageAgent is a separate task to store telemetry in an external data bank. 2

3 Figure 2 Main components for monitoring function B. Stream preprocessing Some transformations are often necessary on incoming streams before decoding. Transformations are always specific to a telemetry format. For example, demultiplexing needs to know precisely where to split the stream. Therefore, Packetizer was created to act as a router and a transformer. Combination of such Packetizer is called an AcquisitionChain. 1. Packetizer A Packetizer is used to route, to transform and to distribute streams It has inputs and outputs. An input is in charge to read or to receive data from outside. An output is a listening socket for distribution which can accept several clients. Between inputs and outputs, there are internal routers. Routers route the data from input towards outputs. Some routers can perform some operations on data if needed (Multiplexer, Demultiplexer...). The user can build a Packetizer by assembling and defining inside components. The following figure illustrates a basic Packetizer that connects an input to a multi clients output. Readers, transformers and filters should be configured or defined using the Packetizer API. Such a Packetizer is used to distribute to many clients a stream. 3

4 Figure 3 A basic Packetizer For more complex preprocessing, a Packetizer can accept several interconnected routers. Each router should be in charge of a part of the treatment. In next figure, the Packetizer multiplexes two inputs and a second router inserts a header in the stream. Figure 4 An advanced Packetizer The Reactor Design Pattern manages Inputs/Outputs with java.nio JDK package. The result is that the Packetizer can support many clients. Moreover, each client has its own sending queue and the memory is safe as the queue is swapped on hard disk when too much big. 4

5 From an object conceptual point of view, the key classes are : Packetizer : The main class which stands for the idea of Packetizer Router : Abstract base class for a router. A Packetizer can contains several inter-connected routers. Predefined routers exist. For example, the basic, default router is DuplicateRouter which only rewrites inputs on outputs. ExternalInput : Class for external inputs. An external input belongs to a router. Reading input stream is delegated to a StreamReader. Predefined stream reader exists. For example, CCSDSPacketStreamReader splits the stream into CCSDS packets. InternalInput : Class for internal inputs, i.e inputs connected to an Output. With InternalInput, it is possible to inter-connect routers. An internal input belongs to a router Output : Class for outputs. An output belongs to a router. It is possible to filter data before sending it to the connected clients. This is done with a DataFilter. Some predefined filters exist, for example CCSDSPacketFilter which can filter CCSDS packet against APID. An output has two possible protocols to send data to clients. The first one is called RAW_PROTOCOL. It is a very simple protocol since it does nothing! The second one is the well-known TLV (Type, Length, Value) protocol. It is very useful when the input stream is split into packets by inputs. 5 Figure 5 UML class diagram of a Packetizer

6 The configuration of a Packetizer means a global lego-construction with the above elements. A Packetizer can save and restore its configuration in and from a XML file. Following an example of XML configuration : <?xml version="1.0" encoding="utf-8"?> <Packetizer-config name="mypacketizer"> <router class="packetizer.router.duplicaterouter" name="router1"> <external-input auto-restart-on-eof="false" auto-restart-on-error="false" name="router1.exin1" stream-reader-class="packetizer.reader.defaultstreamreader" url="file:/d:/octave/packetizer/tu/data/ccsds.bin"/> <output name="router1.out1" port="2000" protocol="raw_protocol"> <filter class="custompacketizer.filter.mydatafilter" name="mydatafilter"/> <remote-client send-buffer-capacity="-1"/> </output> </router> <code-extention name="test-custom" url="file:/d:/octave/packetizer/ custom.jar"/> </Packetizer-config> 2. Acquisition chain An AcquisitionChain is several interconnected Packetizers. It is very powerful to realize complex preprocessing and also to intermediate ports to external systems. A special Packetizer in the acquisition chain, called frontal Packetizer, is flagged as the main telemetry input that will be stored in databank. Figure 6 An acquisition chain All combinations of packetizers are possible C. Decoding engine Connected to an output of the AcquisitionChain, the decoding engine parses the stream to produce telemetry parameters with understanding values. At this stage, the telemetry description is essential. It gives a structural (syntactic) description of the incoming stream to retrieve serialized parameters. Octave uses the CCSDS DEDSL- XML format. Firstly, this format has the very big advantage to be standardized by the CCSDS ; secondly tools, like OASIS that provides friendly graphical interfaces to draw the syntactic tree of telemetry packets, helps the user to write such descriptions. However, classes which generate the engine being well identified, Octave is ready to handle other formats like XTCE for instance. 6

7 One characteristic and originality of Octave is that the decoding engine is dynamically generated from the telemetry description. Flavor technology is used to create classes of the syntactic parser and JavaAssist technology API serves to compile Java code at runtime. The figure below shows the steps to generate an engine. Figure 7 Steps in generating a decoding engine At the moment a CORBA interface defines distribution service implemented by the engine. Various registering are possible : sampling, on value changes, punctual. Formal Language for Audio-Visual Object Representation is an object-oriented media representation language being developed at Columbia University Java programming assistant is a load-time reflective system for Java 7

8 D. Dispatcher In future version, the entire distribution of the parameters will be delegated to a dispatcher. Thus, the amount of work of the decoding engine will be not be dependant of the number of clients anymore. According to the SM&C works, a middleware to distribute messages will be used. III. Distributed Octave platform Since version 2, the monitoring function is embedded in a distributed user oriented platform. Architecture and clients applications are described in this chapter. A. Architecture The Octave platform is full Java CORBA. Java provides portability and the many libraries developed by the community helps innovations. The architecture is based upon three main CORBA servers : OctaveServer TMTCBank UserManagement The OctaveServer component homes all the descriptions about telemetry to create TMFlow. It is the heart of the platform since it makes running the decoding engines. It is possible and recommended to instantiate many times this component to distribute the CPU load. The TMTCBank offers services to store and to extract telemetry from a database. The UserManagement component offers authentication and user management services. Following, several deployments of Octave platform. Figure 8 A mono machine deployment 8

9 Figure 9 A multi machines deployment B. Services Any client applications used the offered services to connect and to interact with Octave. Services are describes in IDL language. Interoperability is possible : C++ clients have been developed in the STILO project. 3. User management services User Management services are interfaces to make possible authentication, profiles and environments downloads. The component also plays the role of a security checker each time a client invokes a service. 4. Monitoring services Monitoring services are in majority proposed by OctaveServer. These services enable the management of telemetry flows, of acquisition chains, of Packetizers etc. C. Client applications Two kinds of client could be distinguished according to their profile : administrator and operator. The administrator can create telemetry contexts, it means incorporate a telemetry description into an OctaveServer to create TMFlow latter. 5. Administrator application Octave proposes a ready application to administrate the whole platform. This application delegates all intelligence to the platform by using remote services defining in IDL interfaces. Following, some screenshots of the OctaveManager application. 9

10 Figure 10 The OctaveManager application The telemetry description can be managed and the flows can be piloted from this application. 10

11 Figure 11 The OctaveManager application The telemetry description can be edited remotely. At the left side, we see the syntactic tree of the telemetry. 11

12 6. Operator applications Operators usually want to visualize the telemetry. So they call services offered by TM flows to subscribe to parameters values. With more privileges defined by the administrator, operators may be authorized to create and to pilot TM flows. Figure 12 An OctaveClient application for visualization Sophisticated views are animated according to the values of parameters 12

13 Figure 13 An OctaveClient application for visualization On the left, we can see three flows. The number of OctaveServers deployed is hidden. The distributed platform is seen as a whole server. On the right side, curves are updated upon parameters values reception. 13

14 D. External systems External systems are future not yet developed clients. IDL Interfaces are the starting point to implement an Octave client in any language. Administrator and operator applications described above has been developed in the same manner. Actual users of Octave are : IV. Customers CRYOSAT PHARAO JASON 2 PICARD MeghaTropiques References 1 Consultative Committee for Space Data Systems, DATA ENTITY DICTIONARY SPECIFICATION LANGUAGE (DEDSL) XML/DTD SYNTAX (CCSD0013) CCSDS B-1, January