a data model framework for the characterization of a ...

A DATA MODEL FRAMEWORK FOR THE CHARACTERIZATION OF A SATELLITE DATA HANDLING SOFTWARE Gianluigi Camatto (1), Massimo Tipaldi (1,2), Wolfgang Bothmer (1), Massimo Ferraguto(1), Bernhard Bruenjes (1) (1)

OHB System AG, Universitätsallee 27-29, 28359 Bremen (Germany), {gianluigi.camatto, massimo.tipaldi, wolfgang.bothmer, ext.massimo.ferraguto, bernhard.bruenjes} @ohb-system.de

(2)

1.

University of Sannio, Dept. of Engineering, P.zza Roma, 82100 Benevento (Italy), [email protected]

ABSTRACT

This paper describes an approach for the modelling of the characterization and configuration data yielded when developing a Satellite Data Handling Software (DHSW). The model can then be used as an input for the preparation of the logical and physical representation of the Satellite Reference Database (SRDB) contents and related SW suite, an essential product that allows transferring the information between the different system stakeholders, but also to produce part of the DHSW documentation and artefacts. Special attention is given to the shaping of the general Parameter concept, which is shared by a number of different entities within a Space System. 2.

INTRODUCTION

One of the biggest tasks in the satellite manufacturing process is the creation and maintenance of the so-called Satellite Reference Database, an electronic repository for the information produced by the spacecraft manufacturer as essential for configuration control, information archiving & exchange and spacecraft development activities. SRDB contents can span from hardware and physical interface identification (up to harness pin naming and function/characteristics) to telemetry and telecommand packet formats, to configuration and missionisation data and similar. The SRDB data implements the Space System Model (SSM) data model and the identification of the SRDB scope is ultimately left to the customer. An orthogonal definition has to be used for each element resulting from the functional decomposition of the space system, which according to ECSS‐E‐ST‐70‐31C [1] should identify system, subsystem, set, equipment or software product, assembly, part (hardware) or module (software). Each subsystem should bring its own tile to the bigger SRDB picture, including its interfaces with the other subsystems. The DHSW contributes to this information set to the extent needed to support: 

its development (e.g. source code generation for definitions and configuration files) and test/operation



the preparation and maintenance –including the consistency- of the relevant documentation.

Science data, flight dynamic data and instruments data are normally not part of the SRDB-data. The modelling pattern proposed in this paper provides a way to express the DHSW data-representation needs to the SRDB team. The pattern is not intended to impose any constraints on the logical data model designed for the more general SRDB (see Fig. 1), other than the one that the resulting model is able to represent the data and the relationships relevant to the DHSW characterization. It is also not concerned with the formats used for data population and import into the SRDB database. As shown in the next sections and defined in ECSS‐E‐ST‐70‐31C [1], at each level of the space system hierarchy, each element is associated to Activities, Reporting Data and Events. The peculiarity of the approach hereafter proposed is to promote the concept of “Parameter”, confined in the Reporting Data classification of the ECSS, to a meta-level so that the same concept can be used in the three contexts with the same reference. At data instantiation level, this means that an object from class Parameter can be used to build up Activities (e.g. telecommands), Reporting Data (telemetries) or Events indifferently. Purpose is an easier data identification and possibly a reduction in redundant information (i.e. data model normalization). A second aim of the proposed approach is the identifiers binding, i.e. the association of specific system elements with their naming used within the DHSW. This with the intent of decoupling SW development and data representation in other subsystems -e.g. Central Checkout Systems (CCS)- while keeping the link in the SRDB available at any time. The outlined approach draws on a real satellite SW project carried out at OHB System AG, that is to say the Satellite Control Software (SCSW) running on the Meteosat Third Generation Satellite (MTG) On-Board Computer, whose main purpose is to control the spacecraft along with its various subsystems (AOCS, Payloads, Electrical Power, Telemetry Tracking & Command, etc.) in a way that guarantees a high degree of flexibility and autonomy. In this paper, the model of the

SCSW characterisation and configuration data submitted for inclusion in the SRDB logical representation is presented. Finally, the usage of such data model for export of interest to the DHSW is also outlined.

Figure 1 - Deployment of System Elements E-R onto the SRDB Logical Model 3.

DHSW DATA MODELS AND SPACECRAFT ADVANCED AUTONOMY/FDIR

DHSW configuration and characterisation data are injected into the DHSW by means of artefacts (i.e. configuration files structured according to specific file formats) generated by the so-called DHSW missionisation tools, which are usually part of the SRDBSW suite. Thus, DHSW objects (such as monitoring items or recovery action definitions, see [2]) are instantiated and comply with the underlying data models. In the near future, this approach will be further extended by the adoption of “generic” processing engines which can be configured and tuned during the integration phase by means of data set representing specific SSM elements and generated on-ground by such missionisation tools. In this way, we will be able to fulfil the need of having DHSW featured by high-rich autonomy and advanced Fault Detection Isolation and Recovery (FDIR) capabilities. Autonomy is an important feature of currently developed and future missions. In the next years, satellites will be able to receive, process and achieve high-level goals even in an uncertain or dynamically varying context. They will be endowed with an ergonomic interface so that ground operators can easily define and transmit such high level requests. In [3] and [4], the integration of planning systems and dynamic reprogramming capabilities into the flight software is addressed. The authors propose to organize the DHSW architecture along three hierarchical levels, that is to say the decisional level, the operational level and the functional level (see Fig. 2). These levels are

characterized by different reaction times, handle more or less abstract data representations and have different type knowledge of the system state (global or local). Ground high-level objectives can be further on-board detailed into a sequence of commands for the subsystems and can be autonomously adapted during their execution according to context changes, such as new objectives and altered onboard resource profile. FDIR functions are allocated to the three levels. A first set is paired to the satellite subsystems and is allocated to the bottom of the architecture, which is the functional level. This level serves as basis to operational level, where system-level FDIR functions are deployed. At the decisional level, FDIR monitors the plan execution and detects inconsistencies according to the reports coming from the operational level. In [5], the authors propose a stratified agent architecture where the on-board mission planning, the command schedule executor and the FDIR functions are seamlessly designed and integrated. A homogenous knowledge approach based on the Petri-net formalism (e.g. for plan representation, abstract and detailed spacecraft models, cause-effect relationships) is used. In particular the mission planning is carried out hierarchically and involves iterative refinements of the Petri net transitions until they represent primitive operations for the command schedule executor. As shown in Fig. 2, at each level, specific domain models are instantiated by data sets, thus the different SSM elements and DHSW functions are customized to the specific mission requirements. Explicit representation of spacecraft states and behavioural models in the DHSW will offer a unique opportunity to verify the correctness and the consistency of information that nowadays is usually implicitly embedded in algorithms. This will reduce notably the gap between concepts and assumptions that reside in the mind of system engineers and what is actually implemented in the DHSW. Moreover, it will also lead to easier portability from mission to mission, as only the models need to be updated with domain specific knowledge. 4.

THE ECSS‐E‐ST‐70‐31 MODEL

SPACE

SYSTEM

ECSS‐E‐ST‐70‐31C [1] introduces a hierarchical view of the satellite composition (called Space System Model (SSM)) and the definition of associated data at each node of the composition. In particular, at each level of the space system hierarchy, each element is associated to information categories, i.e. Activities, Reporting Data and Events (see Fig. 3). An Activity is a space system monitoring and control function implemented within the EGSE or mission control system (EMCS), e.g. a telecommand or a procedure. Reporting Data is the information that a system element provides, irrespective of how this information is used; a

typical Reporting Data example is a telemetry packet, or any subparts of it. Finally, an Event is an occurrence of a condition or group of conditions of operational significance; those raised within procedures are an example of events associated with a specific system element.

set of requirements in a tabular form where each table corresponds to an entity type and each row corresponds to a value type. In this way, the association between system elements and their own data is achieved. This standard uses the suffix type to highlight the facts that the model describes generic elements of the information categories and their characteristics, not the instances that will actually populate the database; in the following, that suffix will not be used as clear from the context. This paper extends the methodology by introducing UML diagrams to describe the SSM Entities of concern of the DHSW, and the relations among them. Classes describe entities and class attributes their values. Relations are represented as Association arrows, while the usage of UML allows expressing concepts such as Generalisation and Composition that make the description easier. Definition of the Entities is also provided in tabular form for readability’s sake.

Figure 2 - DHSW architecture in high-rich autonomy space systems The concepts of system elements and their characteristics introduced above enable a complete, high‐level description of the space system model independent of any specific space system configuration and, as such, can be reused at any level of integration, test and mission operations. For example, the name and description of an activity always remain the same, although it may be implemented as a simulated command during testing and a procedure during mission operations.

Specifically to Fig.4, a Telemetry Packet Definition TmPacketDef is associated to its PUS Application Program Identifier APID, and is composed of a number of Telemetry Data Elements TmDataElement. This can be associated to a simple Telemetry Parameter TmParam, or to a more complex Compound Telemetry Parameter CompoundTmParam, which in turn can be again a TmDataElement. The PUS Telemetry class PUSTM is a specialisation of TmPacketDef. Dotted classes are used to demand their definition to a separate diagram.

Figure 4 - Example of UML diagram for the TMPacketDef entity Figure 3 - Information categories of a system element ([1]) 5.

THE NOTATION USED

Within the three information categories identified above for a system element, the ECSS‐E‐ST‐70‐31C [1] defines the concepts of entity types and value types, normally as a

6.

THE PARAMETER CONCEPT

The approach used in this work is to promote the Parameter entity from the domain of the Reporting Data to that more general of the information categories. This can be justified by three main observations:



a Parameter can be in general a component of both Activities (e.g. Telecommands) and Reporting Data (e.g. Telemetries);



a Parameter normally exists independently from the possible uses, for example because it represents a physical element;



a Parameter can be handled by a System Element although that element is not the source of it (e.g. values coming from another equipment).

Fig.5 depicts the proposed approach.

Figure 5 – Extension of system element information categories There is a first clear advantage in using this approach: a reduction on the redundancy on the data representation within the SRDB, which brings then all its side benefits like the improvement of data consistency, the reduction of database size, database normalization and the simplification of its maintenance.

Table 1 - Entity for the Parameter information category With reference to Fig. 4, Tab. 2 reports a possible specialisation of the Parameter entity when used inside a Telemetry packet. In this case the further definition of the transport types (i.e. the Parameter Type Code (PTC) and Parameter Format Code (PFC) used in the TM packet, if different from those of the Param class) and of an optional flag value to represent invalid data, are given.

The Parameter information category should implies entities featured by the general attributes of a datum per se, like its ID, type/size, description fields for the documentation or the SW generation and a link to the applicable interpretation functions. The identification of an optional parameter conditioning its validity is also inherent to the datum. Tab. 1 gives an example of entity for the Parameter information category, taken from the MTG SCSW project. Attributes are explained in the relevant column, the only remark concerns the Identification Block which is a record of data uniquely labelling each Entity instance where it is foreseen. The last column specifies whether the attribute is Mandatory for filling or Optional. The description of attributes specific to a given usage of the Parameter can then be demanded to a derived subclass/sub-entity, extending the set with what needed.

Table 2 - Tabular description for entity TmParam Similar considerations can be done for the PTC and PFC codes of the class TcParam (see Tab. 3). In addition, this class details the default value for the TC field to be presented to the operator when preparing the Telecommand.

Table 3 - Tabular description for entity TcParam As in the case of the third bullet above, a specific parameter can come from another system element (e.g. a different equipment). Its definition will be filled in the database by the originating process so it is not of direct concern of the DHSW data specification. Nevertheless, the DHSW needs very likely to acquire it through a physical interface, and extract it from its possible transmission harness, e.g. header, footer, segmentation data and so on. To do so the DHSW must be able to reference a data block in the packet, and to relate it to a parameter. Fig. 6 shows the UML diagram of the command entity within the Activity information category in the MTG SCSW project and in particular the entities used to represent data from the internal 1553-Milbus. As evident from the diagram, a parameter can be mapped onto a portion of the datawords of a Milbus command message or response message (as it is usually the case in DHSW) to avoid mirroring in memory of acquired data. The mapping can also span over the entire dataset, i.e. even outside the borders of a single Milbus dataword, thus inherently performing the data extraction at transport level. A similar modelisation has been used for the Satellite Platform Internal Control Bus (ICB). 7.

THE MODEL IS IN, DATA AS WELL, AND NOW ?

Once the data model prepared for the DHSW has been deployed in the more general logical representation of the SRDB, data can be populated incrementally. SRDB data releases will then be performed to the Customer and other System stakeholders, but specifically for the DHSW there is the need to obtain some reports in different forms, to support the software development. Two kinds of reports are currently foreseen for the DHSW: 

source code portions defining configuration values/constants, enumerated lists and default contents for some services at start-up.

Figure 6 - Example of UML diagram for the Command entity 

Tables containing information for the DHSW Interface Control Document (ICD) like parameter lists and attributes, Telemetry packets structure and send-list definitions for the 1553-Milbus and the ICB.

A key-point for the first type of extraction is of course to store in the SRDB the naming and the information that is needed in the source code, e.g. the DHSW identifiers (literals) used to represent an entity instance. For example, a Parameter with PID 87654321 may be referenced as DHS_ADSS_A_THERMISTOR in the software. This coupling is made available by special attributes of the involved entity. For example, the PID uniquely identifying a parameter is related to its DHSW identifier through the field Mnemonic of the IdentificationBlock (ref. Tab. 1, PidMnemonic row). This allows also an easy tracking of data throughout the SSM, from the originator to the user, and an easy extraction of lookup tables by simple queries. A problem faced when specifying the format of the source code blocks to be produced by the SRDB-SW suite is the identification of a formal way of doing it. While code skeletons and natural language could be used, some glue is needed to make the definition non ambiguous. To that purpose, the usage of the Extended Backus‐Naur form (EBNF) has been chosen. The EBNF is well suited to express the kind of language used when filling the skeletons. Essentially, an EBNF consists of terminal symbols, non-terminal symbols, and production rules

which are the restrictions governing how terminal symbols can be combined into a legal sequence. For example, to generate the following piece of source code (colours are used here just to highlight tokens, and are left to syntax highlighting tools), the filling rules reported in the Fig. 7 could be used. typedef enum { /** Reference for "No event" */ EventId_Null = 0, /** No definition exists for this ID in either "TM Packets" or "Event Packet Config" */ EventId_Dummy_1 = 1, /** An hazardous TC has been received */ EventId_HAZARDOUS_TC_ARMED = 5, /* ... */ /** Total number of events */ EventId_Max = 3 } EventId_t;

8.

CONCLUSION AND FUTURE WORK

This paper has proposed a possible data-model framework applicable when expressing the data representation needs of a DHSW within a Satellite Reference Database. The model grows on the recommendations from ECSS‐E‐ST‐70‐31C for Space System Models, and introduces a set of Entities and the relevant Relationships recurrent in DHSW development. In addition, the concept of Parameter is extracted from the Reporting Data information category and promoted to a general System Entity open to contribution from various Elements of the Space systems, but globally referable. Finally, a formalism for data exports and report production is proposed, aimed at specifying non ambiguously to the SRDB team the format of the reports to be produced from the DHSW data. Although the main issues seem to be addressed by the modelling proposed, some work is still to be completed on it. For sure, a data model refinement will be needed basing on the feedbacks from first usage and on some data normalisation criteria. Secondly, the introduction of some support entities, i.e. not really part of the satellite system but helping in the data definition, is under study. This should streamline the model and reduce the storage size requested by the overall data set identified by it, again looking at data normalisation principles. Thirdly, an improvement of the data filling rules is under study, to better isolate the set of data onto which EBNF production rules are to be applied. Currently a simplified SQL set of queries is used stated in advance of the production rules.

Template: typedef enum { } EventId_t;

Filling rules: ::= [ "," ] ::= [ "/** " " */" TAB> ::= ReportIDDef::Doc_description ::= ReportIDDef:: RidMnemonic ‘=’ ReportIDDef:: RID ::= “ “ ::= carriage return ::= horizontal tab Figure 7: Example of EBNF filling rules 9.

REFERENCES

1.

ECSS‐E‐ST‐70‐31C: Space Engineering – Ground systems and operations - Monitoring and control data definition, 31 July 2008

2.

ECSS-E-70-41A: Ground systems and operations telemetry and telecommand packet utilization, European Cooperation for Space Standardization Standard, 2003.

3.

S. Lemai & X. Olive C. M., “Decisional architecture for autonomous space system”, in Proceedings of ESA Workshop on adavanced space technologies for robotics and automation, 2006

4.

X. Olive, “FDI(R) for satellites: How to deal with high availability and robustness in the space domain?”, International Journal of Applied Mathematics and Computer Science, 2012.

5.

A. Indra, V. Agrawal & V. Sarma, “Stratified agent architecture for on-board mission planning and execution for an autonomous spacecraft”, in Proceedings of Tencon Conference, 2008