Keywords

1 Introduction

A satellite is a combination of different subsystems, each working to perform specific tasks. On-Board Computer (OBC) is the brain of the satellite which is responsible for monitoring temperature, pressure, direction, all telemetry and telecommand signals, and memory management [1]. The main function of the OBC is to communicate with different subsystems and also to the ground station. OBC subsystems carry out the processing of science data (such as payload data), and housekeeping data and send it to the ground station when requested through tele commands. The next section of this paper provides the design of the onboard computing subsystem. The different modes of operation and interfacing of different sensors are discussed in Sects. 3 and 4 of this document, respectively. Section 5 shows us the data handling done by the OBC. Sections 6 and 7 depict the common problems encountered during the development of the OBC, and some of the proposed solutions for the same, respectively.

2 Design of OBC

OBC can be designed using an FPGA-based model, which helps all subsystems to run parallelly in a hierarchical relationship. The design using the FPGA can be done in the form of a finite state machine working in major and minor cycles. The goal is to design a system that uses the same power provided by the satellite but fits in a smaller fixed space and also interface with the control signals of the satellite that are already present [2].

2.1 Hardware Architecture

The OBC subsystem hardware is realized either using a System On-Chip (SOC) FPGA or using a microprocessor/microcontroller. The efficient hardware design is to use both FPGA and a microprocessor running in parallel as shown in Fig. 1. The FPGA is used to interface different sensors using different protocols into the OBC. The microprocessor is used for processing housekeeping data. The microprocessor initializes and transfers the control to the processor present in the FPGA.

Fig. 1
A flowchart of the on board computer subsystem starts with analog sensors, R x, digital sun sensors, G P S, I M U, and magnetometer, and payload leads to S O C F P G A, and it leads to S R A M, E E P R O M and T x.

Depicts the overview of OBC subsystem

Full size image

  • SOC FPGA. Main processing unit responsible for data handling and interfacing different sensors

  • Microprocessor. For housekeeping inside the OBC

  • Rx, Tx. Receiver and Transmitter

  • Analog Sensors. Includes Course analog sun sensors, thermistors, solar panels and battery sensors

  • Analog Interface. Interfacing all analog sensors to the OBC board

  • Digital Sun Sensors, GPS. For location and altitude adjustment.

  • UART Interface. Interfacing digital sensors and GPS to the OBC board

  • IMU and Magnetometer. For monitoring the orientation and angular velocity of the satellite

  • Payload. Payload sensors like camera and IR imaging devices.

  • SRAM. For storing temporary data during data processing

  • EEPROM. Storing parametric data of the system

Microprocessor Selection. The microprocessor for the OBC needs to be selected keeping different aspects such as power consumption, operating temperature, operating voltage, packaging I/O, and serial bus compatibility into consideration. Following steps are followed to select the best-suited microprocessor for our mission-

  • The first step is to shortlist different core design manufacturers such as Atmel, ARM, Texas Instruments, etc.

  • Based on the above-mentioned parameters microprocessors are selected and compared with different manufacturers.

  • The last step is to compare each shortlisted microprocessor individually and select the best suited for our requirements [3].

Different microprocessors used in different missions

  • Atmel 32-bit microcontroller AVR32- AT32UC3A0512 is used as the main processing unit in the Cube Sat developed by the Cape Peninsula University of Technology, South Africa [3].

  • Norwegian University of Science and Technology (NTNU) Test Satellite uses ATSAMV71Q21 microcontroller in the UHF radio range and AT32UC3C0512C microcontroller in the VHF radio range [4].

  • The PISAT Nano satellite launched by the Crucible of Research and Innovation Laboratory of PESIT, India, used an Atmel 32-bit microcontroller AVR32-AT32UC3A0512 with a clock speed of 12 MHz [5].

2.2 Software Architecture

Attributes of a good software. The OBC software requirements specification is the most crucial part of the OBC software. Following are the characteristics to adhere to while designing the software [4]–

  • Minimal complexity

  • Ease of maintenance

  • Loose coupling/high cohesion

  • Extensibility, Reusability and portability.

Onboard autonomy. The onboard autonomy in any satellite can be distinguished in three different ways as shown below-

  • The commanding level can be set such that only low-level commands are executed in the initial phase of the mission. The commanding level is increased after testing the satellite in the orbit. The high-level commands are converted into sequential low-level commands on the satellite for execution.

  • The intelligent payload data processing is considered as the second autonomy wherein a particular data is selected, stored, and processed by the data processing algorithm.

  • The highest autonomy is the artificial intelligence of the satellite to carry out its instructions and self-decision-making without relying on the ground station or any other system [2].

Mission control system. The mission control system looks after the satellite from the point of launch till the end of the mission. The mission control system is a part of the ground station which monitors all aspects of the machine by sending telemetry and telecommand data from the ground station to the satellite. The most common mission control system (MCS) software is the satellite control and operation system 2000 (SCOS 2000). The SCOS has been used by the European space agency in several space missions like Cryosat, Galileo FOC, and MetOp-A [6].

3 Modes of Operation

3.1 Modes of Operation Based on Battery Capacity

As proposed by Arnesan and Kiaer, the modes of operation can be divided into three sections–

Critical Mode. The OBC switches to the critical mode when the battery capacity is less than 25% of the maximum battery capacity.

Avoidance Mode. The OBC switches to the critical mode when the battery capacity is between 25 and 50% of the maximum battery capacity.

Normal Mode. The OBC switches to the critical mode when the battery capacity is between 50 and 100% of the maximum battery capacity [4].

3.2 Modes of Operation Based on Contingency

The contingency operation as seen in the Flying Laptop satellite developed from Institute of Space Systems, Universität Stuttgart, can be classified as follows–

Level I Contingency (Idle Mode). The satellite enters the idle mode due to insufficient battery charge as mentioned above.

Level II Contingency (Safe Mode). The satellite enters into the safe mode due to the failure of any primary sensors such as altitude determination sensors. This mode triggers the altitude control system into the detumbling mode [2].

4 Interfacing of Different Sensors to OBC

Interfacing different sensors into the OBC is the major aspect in the development of an On-Board Computing subsystem of a nanosatellite. For interfacing different sensors we use different protocols based on the sensor datasheet. The different protocols include SPI, I2C, and UART.

Inter-integrated circuit (I2C) bus is generally used for communicating with different sensors and for data read operation. Serial-peripheral interface (SPI) bus is usually used where the data is of a larger magnitude that needs to be transferred. SPI can also be used in the interface between the OBC and the Power subsystem [7]. Universal Asynchronous Receiver Transmitter (UART) protocol is used for digital sun sensor and GPS interface.

5 Data Handling

The majority of the data coming into the OBC subsystem comprises science data which includes data coming from payloads and other sensors onboard. OBC also receives housekeeping data continuously from communication devices.

5.1 Payload Data Processing

The main purpose of a satellite is to gather data, process it, and send it back to the ground station. The data gathering is generally carried out by the payloads present onboard. This data coming from the payload needs to be reduced so that there is an efficient transfer from the satellite to the ground station. The processing of the data can be done in any of the following methods–

  • The redundancies in the data are removed by compressing the data by various methods.

  • The data can be analyzed on the satellite before sending it to the ground station. This process takes up a long implementation time and also affects computational performance.

  • The data can be screened such that only a particular part of the data is extracted and sent to the ground station [2].

6 Common Obstacles Encountered While Designing OBC 

6.1 Reliability 

Reliability is always an important requirement on a space mission because if a failure occurs in space it cannot be repaired and usually results at the end of the mission, although increasing the reliability of the system is directly proportional to the increase in the cost.

6.2 Space Radiation 

When the satellite is in space, radiation produced by particles emitted from either the sun (solar radiation) or from outside of the solar system, Galactic Cosmic Rays (GCRs) can cause degradation of the satellite, ultimately leading to the failure of the electronic and electrical systems in either the space vehicle or the satellite. Single event upsets (SEU) are the errors caused by radiations in microelectronic components. Single Event latch-ups (SEL) indicate the failure of a semiconductor device in responding to any input signals [4].

6.3 EEPROM Errors

Errors observed in the microcontroller EEPROM in the OBC affect the log register of the commands processed by the OBC, whose origin is suspected to be related to single event upsets (SEU), which can cause an increase in the OBC resets. These errors and OBC resets bring about change in the satellite time and result in the loss of the last received commands [8].

7 Fault Tolerance Methods

7.1 Watchdog Timer

A hardware timer is set on-board which resets itself at a particular predefined interval of times is known as the Watchdog timer. This timer is used for fault isolation and to safeguard the OBC from failures such as interface bus failures.

Watchdog can be used in a hierarchical order for better implementation. Software Watchdog threads are used OBC software [7].

7.2 Radiation Associated with Fault Tolerance for FPGA

The SEU and SEL are caused due to radiation effects. The SRAM-based FPGAs such as ZYNC 7000 are very sensitive to radiations. The upsets associated with PL fabric can be removed by resetting the memory configurations of the upsets followed by a whole system resets. The operation of FPGA in a radiation environment can be carried out with techniques such as mitigation and scrubbing [7].

7.3 Radiation Associated with Fault Tolerance for Flash Memory

Flash memories are generally susceptible to radiation; therefore, an additional boot image is stored in n EEPROM. This allows updating the software on flash while there is a fallback in the EEPROM. Memory scrubbing can be included in the flash memory with the help of error-correcting codes such as Hamming codes [7].

7.4 Multilevel Reset Mechanism

A multilevel reset scheme is used to remove SEU and SEL problems. The resets can be done in different ways such as autonomous reset of just the OBC’s system on module. The reset can also be done to the entire spacecraft by sending a signal to the power subsystem. The reset is also done by sending a command from the ground station using a telecommand [9].

8 Conclusion

The overview of the On-Board Computing subsystem of a Cube Sat is discussed in this paper which includes the design of the hardware using a SOC FPGA and microprocessor. The working of satellites in different modes and data handling capability is key in the functional aspect of the OBC subsystem. Some of the obstacles encountered in designing OBC are discussed with the possible solutions for the same.