r bulletin 103 — august 2000

100

Database Administration for SpacecraftOperations – The Integral Experience

J. Houser & M PecchioliMission Operations Department, ESA Directorate of Technical and Operational Support,ESOC, Darmstadt, Germany

IntroductionLong before the integration of a spacecraftbegins, the structure of the spacecraftdatabase is defined and documented. Becauseof the large amount of data involved, a properand clear definition of the database structure iscrucial to minimise the effort subsequentlyrequired to populate and maintain it.

The database is initially populated, used andvalidated by the teams responsible for thedesign and integration of the different satellitesubsystems. The flight control team at ESOCwould normally see it for the first time two tothree years before the launch. At this stage, thedatabase is typically in an incomplete andunstable state, and progressively maturesthroughout the integration and test phase.During the same period, the flight control teamat ESOC will need to augment and sometimesmodify it. These parallel activities introduce theneed to ensure coherence between thesedifferent versions of the database and tocoordinate their maintenance.

The size and complexity of spacecraftdatabases differs significantly depending uponthe particular mission, and has beensignificantly affected by the evolution inspacecraft design over the years. For example,the adoption of modem telemetry/telecommandstandards (e.g. the Packet Utilisation Standard)allows great data-handling flexibility on boardand therefore implies the need to introducemore sophisticated techniques on the groundto describe variable packets, for example. Theamount of data required to describe aspacecraft has also increased dramatically inrecent years. For the early spacecraft, onlyabout 500 telemetry parameters had to bedefined in the database, whereas those fortoday’s scientific satellites typically containmore than 15 000 parameters. This growth hasimposed severe requirements on the functionaland performance capabilities of databaseeditors and mission-control systems.

The database maintained by the satellitemanufacturer and delivered to ESOC isnormally referred to as the ‘Satellite Database,or SDB’. The database maintained at ESOC bythe flight control team is normally referred to as

ESA’s flight control teams have always used databases for spacecraftmonitoring and control. The mission control systems rely on adatabase to interface with the spacecraft, in order to know how toencode the telecommands sent and interpret the telemetry received.This approach allows the control system software and the datadescribing the controlled domain to be decoupled. Given the numberof changes typically implemented in a database prior to and even afterlaunch, no other approach would be feasible.

The population, validation and configuration control of the spacecraftdatabase therefore play an important role in mission pre-launchactivities. Experience shows that a reliable database is possibly themost fundamental prerequisite for the successful execution ofspacecraft operations.

The typical spacecraft database consists ofseveral dozen tables, each containing a portionof the data. The tables are interrelated in thatone table record can refer to items furtherdescribed in other tables. Unfortunately, thedatabase structure is influenced not only by thecharacteristics of the controlled domain (i.e. thespacecraft), but also by the design features ofthe control system itself. Given that differentcontrol systems are typically used by thesatellite manufacturer’s Assembly, Integrationand Test (AIT) team and the flight control teamat ESOC, several different database structuresare normally defined. To support the exchangeof data across the different formats, interfacesare formally agreed and data-conversionapplications (import/export) developed.

HOUSER 22/8/00 2:03 pm Page 2

database administration for spacecraft operations

101

the off-line ‘Operational Database, or ODB’. Forperformance reasons, the ODB is convertedinto an internal format when it is imported intothe Mission Control System (MCS), which isnormally referred to as the ‘Run-Time Data-base’.

HistoryThe 80-column card eraIn the late 1970s and early 1980s spacecraftdatabases were defined and managed on 80-column punched cards. These cards were amatrix of holes, 80 columns wide by 12columns deep. Each column was used torecord one character of information as a seriesof holes. The first two rows were used for theheader information, and the remaining 10 torepresent the characters.

There were many punched-card machines inESOC during this period. They were as loudand as large as today’s photocopying machines.The problem with punched cards was flexibility– there just wasn’t any! With punched cards itwas almost impossible for the operationspersonnel to have an overview of the datacontained within them.

As computer technology progressed, punchedcards were replaced by electronic storagemedia, but the organisation of the data itselfwas not modified. The data were accessedusing remote terminals connected to a centralmainframe computer and edited using verybasic text editors. Inputs about the databasecontent were still received from the satellitemanufacturer in paper form.

The 80-column card era has been the drivingfactor in the design of the database structurefor many control systems. The databasestructure of the SCOS-1 control system, still inuse today, can be mapped to 80 columns ofinformation per record.

Relational databasesRelational databases (e.g. ORACLE) wereintroduced in the late 1980s with thedevelopment of the SCOS-1 infrastructure andare still being widely used in ESA. The use ofrelational database technology has opened thedoor to a progressive increase of theautomation in the creation and maintenance ofthe spacecraft databases. ORACLE, inparticular, supports a powerful query language(SQL), which allows interrogation of thedatabase and the manipulation of all datameeting specified criteria (bulk data editing). Italso supports a development environment,which has been used extensively to producethe editor forms. The visibility of the databasecontent as well as the sophistication of the

syntactical and on-line consistency checkscould be progressively improved. Most of theoff-line databases that are managed currentlyat ESOC are still in ORACLE format.

Object-oriented databasesObject-oriented databases have only recentlybeen introduced at ESOC both for the off-lineand for the run-time database. The Rosetta off-line database system and the run-timedatabase of SCOS-2000 (latest ESOC infra-structure for spacecraft control systems) areboth based on object-oriented technology.

Database contentThe content of the satellite database cannormally be split into three main areas:telemetry, telecommand and flight dynamics.This last area is not addressed in this article,which focusses on the telemetry and tele-command databases of the Integral MissionControl System.

TelemetryAll of us are involved in one way or another inmonitoring data in our daily lives, for examplethe water temperature indicators in our cars.What about attaching your thermometer to theinside housing of a spacecraft’s service moduleand launching it into space? As opposed toseeing the data directly, as you can in your car,you encode the temperature value in the formof binary bits and place them in a data unit (e.g.a ‘packet’), which is eventually down-linkedfrom the spacecraft. In order to present youwith an engineering view of the on-boardstatus, your control system first needs toidentify which data unit is being received andthen to know how to extract and decode thetelemetry data delivered by it. In most cases,the location of telemetry data in thetransmission data units is fixed. This is thesimplest and traditionally most commonly usedapproach, but not necessarily the most efficientone. To optimise the usage of the down-linkbandwidth, it maybe required to transmitdifferent data depending on some conditionsrelated to the on-board status. The PacketTelemetry Standard allows this flexibility in thatdifferent packets can be generated dependingon the actual data to be down-linked. A furtherlevel of sophistication may be required undersome circumstances, whereby the content ofsome asynchronously generated packetsdepends on the prevailing on-board states.

Once the bits corresponding to a telemetryparameter sample have been extracted, thecontrol system needs to know how to decodethem (depending on the parameter type, e.g.integer, real, string, time) and how to calibratethem to derive a proper engineering view. One

HOUSER 22/8/00 2:03 pm Page 3

r bulletin 103 — august 2000

102

syntactical as well as range checks. Unlikeprevious standards, the Packet TelecommandStandard, and the Packet Utilisation Standard inparticular, allow great flexibility in the encodingof a command packet, including a variablenumber of parameters, or parameters that maybe given values with variable length.

The execution of spacecraft operations typicallyrequires the transmission of many telecommandsto achieve a specified goal. To ease thisprocess, telecommands are normally collectedin named lists (command sequences), whichcan also be associated with parameters(mapped to the parameters of the constitutingelements). Command sequences are alsoallowed to contain other sequences (nestedsequences), thereby enabling the hierarchicaldefinition of the commanding activities.

The telecommand databases contain all of thedata required to (de-)calibrate and checkcommand parameter values, to encode,validate and verify commands and to store thedefinitions of command sequences.

The Integral experienceThe Integral Mission Control System has beendeveloped based on the SCOS-2000infrastructure. As noted above, SCOS-2000allows full freedom in the design of the off-linedatabase system for a client mission. In thecase of Integral, however, the structure of theoff-line database was directly derived from theorganisation of data expected by the SCOS-2000 database importer. This approach offeredthe advantage of minimising the conversionstaking place when importing the database intothe run-time system, and thus afforded theusers access to all of the flexibility offered bySCOS-2000. Also, the organisation of theSCOS import data is fully ‘normalised’, in thatmany-to-many relationships between data areavoided by means of mapping tables. Theadoption of a normalised database structuresimplifies significantly the relationships betweendata items and thus the development of thedatabase editors and consistency checker.

The size of the Integral database is significant inthat it currently contains about 150 000records, occupying more than 12 Mbyte ofmemory. As for many other missions currentlymanaged at ESOC, this has imposed the needto electronically import as many data aspossible from the database delivered by themanufacturer, thereby avoiding the risk – andeffort – implied by manually inputting all data.

The data flow involved in the process of creatingand maintaining the Integral off-line database isshown in Figure 1. This process is not a one-off

aspect that is of fundamental importance in themonitoring of spacecraft telemetry data is anassessment of the validity of the data received.Is the temperature shown in your car a validindication if the car is switched off? Validityconditions have to be specified in order toensure that the data being used are reliable.This may sound trivial, but in fact it is not as thevalidity conditions are normally based on othertelemetry parameters that also requirevalidation. A chain of conditions is established,which is typically organised in a hierarchicalmanner. Once the validity of the received datais established, the system is supposed to notifythe operator if the on-board status is notnominal. This is achieved by applying to eachreceived parameter a set of checks ensuringthat its value is within the allowed ranges (limitchecks) and also that no unexpected change inon-board status has taken place (statusconsistency checks). A different set of checkshas to be applied, for example, during differentmission phases. This implies that applicabilityconditions have to be specified for each check,each condition also being dependent ontelemetry data.

In many cases, the telemetry data received alsohave to be consolidated to ease the visibility ofthe on-board status. This is achieved byassociating with a ‘pseudo’ telemetry parameter(derived parameter) a routine that is evaluatedbased on some trigger criterion, for examplethe reception of a contributing telemetrypacket.

The telemetry databases contain all of the datarequired to identify, extract, decode, calibrate,validate, check, derive and display thetelemetry data.

TelecommandsTelecommands are encoded messagestransmitted to the spacecraft to trigger one ormore actions on-board. They can performmany different functions, the most obvious onebeing to switch a unit on or off, as you wouldwith your normal television remote-control unit.Of course, commanding a modern spacecraftimplies a much higher level of complexity andalso imposes severe safety requirements.

A telecommand is typically composed of severalelements, which may be given a fixed value, ora default value which can be changed at eachinstantiation level (parameters). Mirroring theprocessing of telemetry parameters, a value fora command parameter can be specified/viewedin engineering form and thus has to be properly(de-)calibrated and eventually encoded in aformat that depends on the parameter type.Parameter values can also be subject to

HOUSER 22/8/00 2:03 pm Page 4

database administration for spacecraft operations

103

Figure 1. Data flow withinthe Integral databasemaintenance process

exercise, because in the years prior to launchpopulation of the database basically takes placein parallel on the manufacturer’s side and atESOC. This is explained and described furtherin the following sections.

The Satellite Database (SDB)The SDB is populated and maintained by thespacecraft manufacturer based on inputs fromthose responsible for each subsystem. Itcontains all of the basic telemetry/telecommanddata required to interface with the spacecraft,as well as some basic Boolean expressions,which are used as telemetry validity criteria,check applicability criteria, and command pre-transmission validation checks. Each SDBversion is delivered to ESOC in the form of SQLscripts, from which a Microsoft Access databasewith the same structure is created at ESOC.This database is not manipulated further atESOC. It is only used as a reference and forimporting data into the Operational Database(ODB, see below). A browser developed in MS-Access is available to all users to visualise theSDB content.

In order to ensure its integrity and consistencyprior to importation into the ODB, the SDB isinterrogated by the database administrator atESOC. Any problems with that particularversion of the SDB are thereby isolated andaddressed during the importation process.

The Operational Database (ODB) editorsAs noted above, the telemetry/telecommanddata contained in the SDB are automaticallyimported into the ODB by means of a set ofMS-Access queries (basically SQL queries),which convert the SDB data and import theminto the appropriate fields of the ODB.Additional information not delivered by thespacecraft manufacturer as part of the SDB isrequired in the ODB. On the manufacturer’sside, only those items essential to safelyinterface with the spacecraft are introducedinto the database. The flight control teams atESOC also have to take into account how thedata are entered (commanding side) and how

they are presented to the end operators(monitoring side). This is crucial both during theexecution of critical mission phases (whenoperations have to be executed under timepressure), as well as during the routineoperations phase (when only a singlespacecraft operator is responsible for theexecution of all operations without any on-lineengineering support).

Typical examples of data stored in the ODB butnot imported from the SDB are the definitionsof monitoring displays and command sequences,which the flight control team directly defines tobe fully in line with the Flight Operations Plan.Another area where the ODB requiressignificant extension after SDB importation isthe definition of derived parameters. Typically,hundreds of additional derived parameters aredefined by the flight control team to refine thevalidity, monitoring check applicability and PTV*criteria, and also to present the on-board statusto the spacecraft operators in the mostconvenient manner. Finally, other extensions ofthe ODB are required to introduce the datarelating to all of the functions of the IntegralMission Control System that are not supportedby the control system used by the AIT** team(e.g. status consistency checks, load/dumpcomparison verification checks, report basedverification, variable packets definition).

Thus, although a large portion of the ODB datais directly imported from the SDB, databaseeditors are nonetheless required to support theflight control team at ESOC in the definition ofthe additional data. Severe requirements applyin that the Man/Machine lnterface has to beunambiguous, efficient, user-friendly andprotective against the introduction of invaliddata.

The Integral ODB (IODB) editors have beendeveloped based on Microsoft Access,allowing easy integration of the severalelements involved in a database editor, such asthe Man/Machine Interface forms and the codewritten in Visual Basic. It also supports easy

*PTV= Pre-Transmission Validation

**AIT= Assembly, Integration and Test

HOUSER 22/8/00 2:03 pm Page 5

r bulletin 103 — august 2000

104

mirrors the data organisation and therelationships between data items as expectedby the MCS database importer. This allowssimplification of the database export function,which is a pure conversion into ASCII format.

Figure 4 provides an overview of the differentelements related to the IODB editors andassociated tools (importer and consistencychecker). The IODB editors support adedicated on-line function, which enables theuser to understand exactly how a data field isgoing to be used in the Mission Control Systemand all of the constraints applying to it.

Last but not least, the content of a databaseneeds to be documented. Reports areproduced in order to support reviews and also

access to an intuitive query definitionenvironment (based on SQL), whichsignificantly eases the data manipulation andvisualisation. The IODB editors were designedwith the continuous involvement of the endusers, to ensure that the product would meetthe actual user needs, including thosesometimes not easily specified in the form ofrequirements. One of the main achievementslies in fact that the editor forms provide a verygood overview of the data being edited as wellas of any referenced data, as shown in Figures2 and 3.

The IODB editors are designed for multipleusers accessing a centralised set of tables fromtheir own PC in their office environment. Thedatabase tables are based on a structure that

Figure 2. The calibrationcurve editor

Figure 3. The derivedparameters editor

HOUSER 22/8/00 2:03 pm Page 6

database administration for spacecraft operations

105

Figure 4. Organisation of theIODB applications

to be used as a reference in the control rooms.The IODB editors support the generation ofreports containing not only the attributes of eachdata item, but also cross-reference lists (i.e.which item is referenced by which other item).

The database consistency checkerThe IODB editors are designed so as to avoidas much as possible the inputting of incorrectdata. This is achieved, for example, by meansof drop-down selection lists for all multiple-choice fields. Relational integrity is alsoautomatically preserved using the relationshipsbetween tables by means of cascade deleteand cascade update mechanisms. However,the execution of on-line checks is not adequateto ensure in all cases that no databaseinconsistencies are introduced. The databasetable organisation is complex, with manyinteractions between data. Executing allapplicable checks following any user inputwould introduce unnecessary complexity andpossibly in some cases even lead to a chickenand egg loop. Furthermore, a large portion ofthe data is imported from external sources,thereby imposing the need to check the overallconsistency of the data after each data importoperation.

For Integral, developing an off-line consistencychecker tool has solved these problems. Thisapplication accesses the same database tablesthat are manipulated via the editors. It runs apredefined set of sophisticated queries aboutthe current database content and returns areport that can be filtered based on tables,fields and type of checks. This approach hasproved to be very powerful in providing userswith a ‘snapshot’ of the current databasestatus in terms of data consistency.

Database validation and configurationcontrolBy the time a spacecraft is launched, itsOperational Database must be completely errorfree and fully tested. There is no system in theworld that can ensure this, and only anintensive test campaign can provide therequired confidence. Several methods are usedat ESOC to accomplish this task.

Spacecraft telemetry playbackThe first satellite data typically made availableto ESOC for testing are in the form of recordedtelemetry data units. These data are useful notonly to start testing the telemetry processing inthe control system, but also to start exercisingthe telemetry database.

SimulationsPrior to launch, intensive testing activities usinga spacecraft simulator take place. These are

geared to the validation of the Mission ControlSystem, the Flight Operations Plan as well asthe Operational Database. The advantage ofusing the simulator for the validation of thedatabase is that the various test scenarios(including failure scenarios) can be relativelyeasily recreated. However, the validationachieved using the simulator cannot beconsidered conclusive. In fact, the simulator’sbehaviour is also driven in many cases byconfiguration tables that are populated usingthe same input as for the OperationalDatabase.

System Validation TestsThe System Validation Tests (SVTs) areconducted by interfacing with the realspacecraft whilst it is still on the ground. Theactual ground-segment equipment is used andrealistic operational scenarios are exercised.One of the SVT objectives is to confirm thecorrectness of the telemetry and telecommanddatabase. In fact, SVTs ensure an end-to-endvalidation of all items in the OperationalDatabase, which are actually used during thetests.

Historical data reprocessingThe execution of the above tests will lead to theidentification of any problems with theOperational Database and their subsequentcorrection, but final confirmation of thedatabase’s correctness is still required. On thetelemetry side, this can be achieved by simplyreprocessing the data that have caused theproblem. In SCOS-2000 this is in many casessimply achieved by opening the monitoringdisplays in retrieval mode, which implies

HOUSER 22/8/00 2:03 pm Page 7

r bulletin 103 — august 2000

106

ConclusionsThis article has described the main problemsencountered in administering the OperationalDatabase for spacecraft operations and thesolutions adopted for the Integral mission. Theproblems and the solutions adopted in eachcase for Integral are summarised in theaccompanying table (Table 1). r

complete reprocessing of the raw telemetrypackets based on the currently activedatabase.

Database configuration controlAfter the execution of SVTs, it is crucial toensure that new errors are not introduced intopreviously validated data. A rigid databasechange- and version-control procedure istypically adopted, whereby each change has tobe traceable and, even more importantly, itmust always be possible to roll back to an olderdatabase version if new problems are indeedidentified. For this purpose, the Integral ODBeditors support the automatic logging of alluser edit operations, and all database versionsexported to the Mission Control System areautomatically archived under a dedicateddirectory.

Table 1

Need/Problem Solution for Integral

Manage large amount of data Automatically import TM/TC spacecraft characteristics from the manufacturer’sSatellite Database (SDB). Allow the users toaccess the powerful and intuitive querylanguage supported by MS-Access

Maximise the work efficiency in the Support high-level ‘replicate’ functions at thedefinition of the Operational Database (ODB) level of data items (e.g. commands).specific data Minimise the set of checks performed on-line

during editing activities

The first version of the SDB is imported Support a ‘delta’ SDB import option when it is not yet in a final state preserving all data added or modified at ODB

level

Ensure overall consistency of the imported Support an off-line consistency checkerand edited data request performing all required checks upon user.

Establish relationships across database tables with cascade delete and update mechanisms

Allow parallel maintenance of the Support the remote access of a centralised setOperational Database from the users’ office of tables directly from the users’ PCsenvironment

Provide the users with adequate visibility of Design editor forms in collaboration with thethe database content users. Implement navigation techniques

across related data items

Keep change and version control of the Automatically log all user edit actions.operational database Automatically archive all exported databases

HOUSER 22/8/00 2:03 pm Page 8