Design of OBDH Subsystem for Remote Sensing Satellite based on Onboard Route Architecture

. This paper describes the On-Board Data Handling Subsystem of remote sensing satellite, which plays nowadays a relevant role to support satellite assembling, integration and testing activities in the implementing complex system-level requirements. Firstly, the architecture and functionalities of On-Board Data Handling Subsystem are described. Secondly, layered On-Board Data Handling Subsystem flight software architecture based on onboard route as well as software maintenance and tolerance designs are depicted. In particular, we present the redundancies and fault processing means for ensuring the correctness of On-Board Data Handling Subsystem.


Introduction
In this paper, we present the architectural approach of the On-Board Data Handling Subsystem (OBDH S/S) running on the China-Brazil Earth Resource Satellite onboard computer. OBDH S/S is one of the subsystems, which belongs to the service platform of remote sensing satellite. Satellite OBDH S/S can be regarded as a system-level entity, which plays a relevant role in implementing some complex requirements, and is the main interface for the ground operators. OBDH S/S integrates the TT&C video frequency functions into a system based on microprocessor equipment to perform the telecommand(TC), telemetry(TM), program control, auto-control onboard, housekeeping functions for the satellite and generate on-board time reference, etc. The OBDH S/S life cycle and reliability requirements are to be defined at the very beginning of any satellite project [1].
Satellites are becoming increasingly softwaredependent, together with other complex systems [2]. The OBDH flight software (OBDH F/S) provides all the necessary functions for nominal and emergency operations of the satellite and enables the ground operators to control and supervise the various the state of all sub-systems for the whole satellite mission. This paper is organized as follows. Section 2 describes its layered architecture. Section 3 outlines the OBDH S/S functionality. Section 4 presents the flight software components based architecture as well as some software maintenance and tolerance designs. Section 5 focuses on the redundancies and fault processing means to fulfill the need of having a robust, reusable, modular OBDH S/S. Finally, section 6 concludes the paper.

Architecture descriptions
The deployment architecture diagram of OBDH S/S running on the on-board computer is shown in Fig.1

Command decode unit-CDU
The CDU of OBDH S/S is also an internal hot redundant unit, which has the ability of receiving a serial message from the TCU and generating the corresponding direct ON/OFF command to the users.

Central terminal unit-CTU
The CTU is the core unit of OBDH S/S, which shall be cold redundancy in one box and shall perform the following functions.
The CTU is the central terminal unit of satellite, which plays the relevant role to process and distribute the routed commands & data and on-board commands. Routed commands and data are received from the ground station and on-board commands are generated by onboard computer based on some parameter measurements and a control algorithm. The types of the routed commands and data include real-time/time-tagged ON/OFF commands, real-time/time-tagged Memory Load Commands (MLC), OBDH housekeeping data, Attitude and Orbit Control Sub-system (AOCS) control data and payload control data, etc. In addition, the CTU performs the functions of executing program-control commands, command group and time-tagged commands, and deleting time-tagged commands (groups).

Remote terminal unit-RTU
The OBDH S/S owns several RTUs, which are identical and are distributed among the different positions in the satellite to provide the direct TM/TC interfaces to the satellite subsystems. Each RTU is identified by the SDB remote terminal address. The microprocessor-based RTU provides the ability of TM acquisition, command distribution and some data processing. The operation of the RTU is controlled by the CTU via the SDB communication.
The RTU provides four kinds of channels for the acquisition of telemetry data: analog channels (AN), digital bi-level channels (BL), serial digital channels (DS) and thermal channels (TH). An analog channel is sampled by the RTU and then converted into an 8 bit binary word. A digital bi-level channel is two-level digital information delivered on a single line. A serial digital word is transferred from user to the RTU with the control of a sampling signal and an acquisition clock signal. A thermal channel is the same as the analog channel.
There are two kinds of interface channels to distribute and execute of commands and data to users: ON/OFF command channels and Memory Load Command (MLC) channels. The RTU also provide the function of self-testing, which includes the tests of CPU, RAM, PROM, AN, DS, ON/OFF command channel and MLC channel.

Ultra-stable oscillator-USO
Ultra-Stable Oscillator is an internal cold redundant unit outputting high-stability 40 kHz and 5MHz clock; 40KHz clock to CTU, which is utilized to generate the on-board time reference and 5MHz clock to GPS.

Data recording and processing unit-DRP
Data recording and processing unit is an internal cold redundant unit, which receives satellite TM or housekeeping data from CTU through SDB bus and playbacks the data from TM downlink channel (on-orbit inquire mode)and Data Travelling Subsystem channel(DTS playback mode). DRP has the ability of saving the important data of OBDH, AOCS, and etc.
In On-orbit inquire mode, the ground controller can downlink eight frames of specially selected TM data packets each time, according to the packet APID, or the packet saved time scale uploaded.
In DTS playback mode, the ground controller can upload the time-tagged command to playback all the TM data from DTS.

Functional requirements
In order to support the platform and payload operations, the OBDH S/S shall provide the following functions.
For the TC routing, execution and report generation, the OBDH S/S should be able to receive, demodulate and decode the telecommand messages from ground and distribute telecommands to all the satellite subsystems (see Fig.2). Usually, it shall handle three types of commands, the direct ON/OFF commands, routed commands and uplink data injection. In addition, the capability of performing program-control commands, on-board commands, command groups and time-tagged commands should be provided. for later down-link (see Fig.3). The CTU generates the OBDH S/S important data, and stores or restores the important data between the OBDH S/S(CTU, RTU, DRP) and AOCS. The CTU also provides the ability of dumping all the time-tagged command queues (On/Off, MLC and SDB) by using one single telecommand from the ground station.

Fig. 3. Satellite telemetry data gathering, encoding and downlink
Generally, all the satellite data, which come from RTUs, AOCS, GPS receiver, thermal controller etc, are gathered and formatted into Advanced Orbiting System (AOS) frame [3][4][5]. Fig.4 describes how the OBDH handles the TM data based on the AOS. In addition, the capability of changing telemetry scheduling period should be provided. In addition, OBDH S/S also provides the capability of housekeeping processing including system configuration, status data and event report collection, fault diagnosis, isolation and processing. Especially, OBDH S/S provides the capability of auto-control onboard, user-dedicated processing and data formatting. The serial data bus communication management is carried out by the OBDH S/S. Housekeeping functions of the CTU include system configuration, self-diagnosis and fault handling, telemetry scheduling mode switching, acquiring channel reconfiguration, and execution of the uplink control data, as well as the collection of the status data and historic event reports. Moreover, the CTU provides the functions of auto-control onboard, and userdedicated data generation, processing and distribution. The CTU is specifically designed to prevent the memory and components from SEU and SEL, and to provide the capability of memory write-protection.

Flights software
The OBDH F/S plays a relevant role in the implementation of the following functionality: management of the satellite AOCS, thermal control, spacecraft health management (also referred to as Failure Detection, Isolation, and Recovery (FDIR)), onboard autonomy, and spacecraft mode management. The OBDH F/S is composed of the CTU software, the RTU software, DRP software and TCU software. The CTU software is defined as management software, the RTU software is defined as execution software, DRP software is defined as data processing software and TCU software is defined as uplink data processing software.
The software of the CTU is the most important part in the OBDH, which is based on real-time operating system (RTOS). There are two hierarchical layers: one is nucleus which provides routines to serve all interfaces, and the other is application processes that implement the CTU tasks necessary. The CTU software is loaded in the PROM and run in the RAM.
The RTU software provides the functions of communication with the CTU through the SDB, telemetry acquisition (digital, analog and serial), command generation (on/off and serial) and internal OBDH processing.
The software architecture of the RTU, DRP & TCU are sequential, which are loaded and executed in the PROM.

Software Framework
The development of the on board software should follow the software engineering standards and consider carefully the various aspects, for example, development methodology, quality assurance, configuration management and analysis/design methodology and tools. Furthermore, the capability should be provided by the flight software to support the unit testing of the OBDH S/S. During the process of development of data management sub-system on traditional spacecrafts, the management of protocol data form and data transaction take plenty time, because of the meticulous analysis of all kinds of transport protocols. A new design of spacecraft OBDH software framework based on onboard route is introduced in this article (see Fig.5). Using this framework, data link layer protocols, such as AosLink, TcLink and 1553Blink, are handled by network layer route, which works as a component. When application layer software needs to send/receive data, the sending/receiving interfaces of the network layer are utilized, and the background running route will choose the destination and service type needed for the data automatically, according to the route table. The data flow between ground, OBDH and other on board sub-systems is thus formed. This framework separates functions of the application layer from commutation on the bottom layer totally, which makes the application layer software design a lot more convenient [6][7][8].

Software Maintenance
The software maintenance in orbit is to fix and update CTU software through the uplink TC block to correct, replace some wrong software module, or to find a new application in order to satisfy new user requirements. Memory dump, program load, and process creation/activation/inactivation functions should be provided by the flight software maintenance in orbit.

Important Data Store/Restore
The important data should be able to store and to restore between the OBDH S/S and other subsystems. OBDH important data presents the OBDH operational state, interval of uniform correction; flag of sending safety switch-off command group, thermal auto-control, temperature range, payload initialize data, main/redundant table, antenna bias data, etc. Its purpose is that the previous working state makes a comeback when CTU resetting or switching.
OBDH important data shall be stored respectively in AOCC, RTU, and DRP while it updates. The OBDH important data and on-board time should be firstly restored from AOCC or RTUs, DRP to perform setup, CTU should also require AOCC to transmit AOCS important data to store when CTU power-on, resetting or switching.

Software Auto-control
There are several cases which could be able to cause CTU resetting by software (namely soft-reset), for example, Non-masked interrupt (watch-dog), RAM write-protect, RAM Hamming code checkout error, Process overtime and etc.
Under the permission of ground station, the CTU may be auto-switched by software normally, when the soft-reset occurs some times, or the CTU fails to communicate with all RTs.
The CTU unconditional auto-switch caused by software may occur at the instance of the failing of Memory self-test when CTU powered on, the wrong testing of TM bit rate, and the stop of On-board time.

Data Estimation
Some important TM parameters, for example, which participate in the controlling of satellite-launcher separation signal, should be judged at least three times continuously. If the testing results are identical, OBDH can make sure some event occurred. Considering the security of satellite, all data acquired by the RTU channels for satellite-launcher separation signal should be judged.

Self-Testing and Self-Diagnosis
OBDH software should provide the capability of selftesting and diagnosis for some critical interface such as TM video interface, and clock interface etc depending on the hardware. Error Detection and Correction Circuit (EDAC) should be adopted to correct the single-bit error and to detect the double-bit error for the memory. The memory should be refreshed periodically by using "read" operation to reduce the probability of piling up the single-bit error and to prevent from double-bit error, which has been proved to be an effective measure to prevent Signal Event Upsets (SEU).

Redundancy and fault processing
The following redundancies shall be provided by the OBDH subsystem. The TCU and CDU are dual redundant devices of "hot backup". The CTU, DRP and USO are designed to be dual redundant with "cold backup" spare unit. The serial data bus SDB is dual redundant and the second bus is in "hot backup" status. The routed TC redundancy shall be provided using two interconnected RTUs. The RTU is not required to be redundant for TMs. TM channels redundancy is implemented by routing TM to two RTUs. The OBDH S/S provides several fault tolerance techniques for failure protection, isolation and recovery. The criterion to determine the position when fault occurred is that, TM value used for testing, comparing or judging must be made a decision during a specified time limit. If the diagnosis result is "true" for three times continuously, the fault is determined to be happen.
In order to judge the fault occurrence, the OBDH S/S provides the capability of self-testing and self-diagnosis including CPU, RAM, PROM, analogue channel, serial digital channel, ON/OFF command channel, Memory Load command channel, TM/TC interfaces and on-board time, etc. Also, it provides the capability of collecting and recording the working status and event reports of the satellite.
Incorrect-write access protection memory, watch dog timer and the code selection filled in spare area of the memory are designed to prevent the program from deadloop and going astray. The OBDH S/S provides the capability of detection of error telecommand frame and important data, detection of application running overtime, and auto-selecting of telemetry data acquired by main and backup channels onboard, which gives the first priority to ground station to fill in the TM frame.

Conclusions
This paper has described the design of OBDH Subsystem for the China-Brazil Earth Resource Satellite based on onboard route. As described, the OBDH is composed by different units in order to provide data handling service to all the equipment of the satellite. The main units and functionalities of OBDH have been presented. An innovative flight software framework based on onboard route has been reported. In particular, attention has been paid to software maintenance and software tolerance. Finally, this paper has stressed the redundancy design and fault processing means provided by OBDH for ensuring the correctness.