Spacecraft are man-made machines that operate in space. An orbiting spacecraft is normally referred to as a satellite, although it is manmade as opposed to a natural satellite like our moon. A spacecraft is typically subdivided into two major parts, the payload and the bus. The bus provides the structural body and primary system of a space vehicle, usually providing locations for the payload (typically space experiments or instruments).
The spacecraft bus consists of several different subsystems, each with a unique purpose. A bus typically consists of the following subsystems: Structures and mechanics subsystem (S&MS), Command and data handling (C&DH) system, Telemetry, Tracking, and Command (TT&C), Communications system and antennas, Electrical power system (EPS), Propulsion System (PS), Thermal control systems (TCS), Attitude control system (ACS), and Guidance, navigation, and control (GNC) system.
Command and data handling, which consists of the computer “brain” that runs the spacecraft, and all the electronics that control how data is transported from component to component. All other subsystems “talk” to this subsystem by sending data back and forth through hundreds of feet of wiring carefully routed throughout the spacecraft bus. This system used to be considered part of another satellite subsystem until on-board computers became more common. Now, C&DH handles much of the processing work from the main telemetry system. C&DH uses reliable, redundant processors to prevent calculation errors.
The onboard data handling (OBDH) subsystem of a satellite is the subsystem that carries and stores data between the various electronics units and the ground segment, via the telemetry, tracking, and command (TT&C) subsystem.
On-Board Data Handling (OBDH) Hardware comprise of
On-Board Computer (OBC) for controlling satellite platform.
RF transmitter and receiver units for handles all communication to ground station.
Data Handling Unit (DHU) for stores data, manage payload, and manage downlink data.
On-Board Computer (OBC)
The On-Board Computer (OBC) of a satellite is a very important sub-system. It is responsible for control of the payload and other sub-systems like power generation, attitude control and communication. Due to the importance of this sub-system to the mission and rigours
of operating in the hazardous space environment, there are some particular design requirements for on-board computers. At the small satellite level, there are added constraints because of the required level of miniaturisation and energy-efficiency. All these make the design of
an OBC for pico satellites a challenge.
Like the rest of the components of a satellite, OBCs also have an operating lifetime in space. This lifetime is mainly dependent on the radiation level of the space environment. OBCs’ electronic components are key factors to estimate the mission duration. For short duration missions COTS components can be used, but for longer duration missions, radiation-hardened components need to be involved in order to make satellite lifetimes longer. Alongside high-quality electronic components, the reliable and robust design of an OBC is also very important in considering mission lifetime.
Functions of CD&H
Courtesy of NASA, some examples of what the system controls are:
- managing all forms of data on the spacecraft
- carrying out commands sent from Earth
- preparing data for transmission to Earth
- managing collection of solar power and charging the batteries
- collecting and processing information about all subsystems and payloads
- keeping and distributing the spacecraft internal clock time
- calculating the spacecraft’s position in orbit
- carrying out commanded maneuvers
- autonomously monitoring and responding to a wide range of on-board problems that might occur
On-board computer (OBC) functions
Payload Control: The OBC is required to control the operation of the payload for communication payload receiving messages from ground station, storing the messages until required and sending them to the destination ground station at the proper time. The OBC is also responsible for sending the ‘Satellite Health’ data to the main ground station.
Power management: To communicate with the power sub-system and maintain an optimal power consumption state. This includes switching off subsystems and components which are not required and switching between solar panel supply and battery according to the light situation. In case of certain emergencies like excessive current being drawn by a sub-system and the hardware safeguards of PWR failing, the OBC switches of the problematic component.
System Health Data Acquisition: Reading the different sensors to monitor satellite health and log the data for transmission to Earth. This data is also useful in the system control loop itself.
Command Handling: The satellite is required to respond to a basic set of commands from the ground station, the most important being the command to terminate radio transmission at the end of the mission life. For this purpose the satellite has to handle tele-commands.
On-Board Data Handling (OBDH) Hardware comprises of
On-Board Computer (OBC) for controlling satellite platform.
RF transmitter and receiver units for handles all communication to ground station.
Data Handling Unit (DHU) for stores data, manage payload and manage downlink data.
On-board computer (OBC) requirements
An OBC primarily consists of a microprocessor, memory banks and interfacing chip to connect the computer to other sub-systems. A range of standard and non-standard interface formats are in use (e.g. RS485, CAN, SpaceWire, SPI and I2C) and the OBC itself can be provided as an integrated unit in the satellite bus and avionics system, or as a modular device capable of working with various other pieces of multi-vendor equipment.
Mission duration
Like the rest of the components of a satellite, OBCs also have an operating lifetime in space. This lifetime is mainly dependent on the radiation level of the space environment. OBCs’ electronic components are key factors to estimate the mission duration. For short duration missions COTS components can be used, but for longer-duration missions, radiation-hardened components need to be involved in order to make satellite lifetimes longer. Alongside high-quality electronic components the reliable and robust design of an OBC is also very important in considering mission lifetime.
Processing capability
The computing unit must be able to handle the processing capacity needed to operate the payload and the sub-systems supporting it (e.g. attitude control, communication, power distribution, etc.).
Every mission plan requires an understanding of similar resources such as power, memory, weight, size etc. One of the most important resources in space missions is time. If the satellite is not geostationary the ground station will be waiting for the satellite to orbit the earth so it can transfer the precious data. Also, the gap for transferring data is usually very short (often a narrow window of 3-10 minutes) so the satellite data transfer system needs to be fast enough to operate in this window, as does the ground station. This requires fast processing and computing power.
In addition, the hardware should be able to support fast processors as these use clock signals generated by the hardware. For example, if a 4 GHz processor is using 2 GHz data bus to communicate, communication speed will be 2 GHz. This means that 4 GHz of processor speed will be excessive and will unnecessarily drain power.
Memory (Static and Dynamic)
Both the capacity and memory format should be chosen to meet your needs. An OBC typically includes both volatile and non-volatile memories with differing capacities.
Similar to computing power, satellites require memory for mission tasks. Dynamic memory size mostly depends on the software to be loaded on the satellite. Such software should be designed around the mission objectives, so the more complex and sophisticated the satellite, the more it requires effective dynamic memory.
Software size also affects static memory, but the main determining factor for static memory is data collected in each orbit. For example, if a satellite’s main task is recording high-resolution video footage, it should be storing the footage in static memory as dynamic memory could be erased in the case of a power interruption or a restart. This way task results can be saved and accessed in the short data transfer gap.
For safety reasons there also can be another static memory that holds a copy of the satellite software in case of malfunction in the main static memory. This also helps with updating satellite software as there will be a static main code stored in a different memory which can be booted in the case of an unseen bug or malfunction.
Sensor Requirements
Sensors can be divided into three branches: Mission-critical sensors, System health sensors, Navigation and positioning sensors
Mission-critical sensors, as the name suggests, depend on the mission objective and tasks, which can be widely varied as they are often for military or research purposes (e.g. EM detectors, spectrum analyzers, temperature sensors, vibration sensors, cameras etc.).
System health sensors collect information on the current status of satellite systems, monitoring critical indicators such as voltage, current, temperature etc. Some loopback tests included in the system are also stored with these sensor data as system health. These data provide very important information about the current satellite status which is used, for example, in the case of a malfunction.
Navigation and positioning sensors are primarily required in missions where there is a need to rotate or move the satellite to another orbit. Such sensing systems may include, for example, a gyroscope to provide the current direction of the satellite, and a GPS receiver to provide current position. Understanding exactly what sensors and sensing configurations are required in a mission or service is important for choosing the right satellite OBC.
Interoperability and interfacing capabilities – as a central controlling unit it is vital that the OBC can work effectively with the required interfaces (e.g. USB, I2C etc.) and has enough capacity and ports for the external sub-systems it will connect to.
Reliability of software – the OBC needs to have reliable software running on it in order to be able handle event sequencing, monitor health and performance of all systems, and handle any problems on orbit.
Power requirements
Power consumption is critical as the generated power in solar cells is very limited. Power consumption can be different for various satellite operations such as imaging, compressing, and transmitting processes. During operations, OBCs should ideally consume little power while still operating effectively.
Field-programmable gate arrays (FPGAs) used in OBCs are important components to consider when calculating power consumption. FPGA technologies differ widely in their power consumption characteristics. To be on the safe side it is important to know that both flash and anti-fuse FPGAs are true live-at power-up technologies that do not exhibit large inrush current spikes at power-up. Moreover, because Flash FPGA technologies are non-volatile they do not suffer from the high configuration current needed during each power cycle. The power consumption of other components can be considered to a lesser extent than that of the processor, but some attention should be paid to power consumption when selecting them.
Size and weight – the system you choose needs to fit into your current mass and volume budget to avoid more extensive redesigns. OBC dimensions and weight must be compatible with the satellite. For instance, nanosatellite platform weights are typically a maximum of 10 kg. An OBC that will sit on a stack (which can be a PC104 connection) is expected to have a maximum weight of between 100 – 200 g and should be compatible with this structure in terms of width, length, and height.
For microsatellites, an OBC used in a 100 kg satellite does not have a definite standard regarding the size, but it is expected to have its own case, be as lightweight as possible, and have its dimensions and connector placement to support the satellite harness.
Environmental Considerations
Launch phase issues:
- Vibration : occurs when rocket launches
- Structural vibration : motors and atmosphere
- Acoustic noise
Shock : occurs during launch when
- Fairing of rocket jettisoned
- Satellite separated
- Release of Deployable
De-pressurization
- Atmospheric pressure drops rapidly with altitude
- Spacecraft design needs sufficient venting
In orbit environmental issues.
Vacuum
Outgassing of materials
Cold-welding of materials (Bonding between metals)
Thermal issues as no effective convection
Radiation
The Sun and other more distant objects in space emit radiation
Particles can upset satellite memories and cause the performance of electrical components, like solar panels, and sensitive surfaces such as thermal and optical to get worse over time
Architecture
Firstly, considering the requirements from the system, there were two candidate designs. The first was a centralised approach, with a single OBC with enough computing power to perform all these tasks. The second approach consisted of using multiple simpler chips in specialised functions for each task. The constraints on size and power favour the first approach. It was also decided to use commercial components with high availability as much as possible.
Fault tolerance
COTS components are typically more sensitive to radiation compared with custom (radiation-hardened) components. Therefore it is important to guarantee the reliability of the system by adopting fault-tolerant design approaches. Low-cost COTS components allow satellite developers to exploit the radiation hardening technique through hardware redundancy; to make the components suitable for space use. Although it doesn’t promise 100% reliability, fault-tolerant design approaches can improve the overall reliability of the system to a great extent. Recovery of the program memory from radiation induced Singe Event Upsets (SEU’s) is also an important feature of the design.
A ’Watchdog’ may be the last line of defense against radiation. As radiation can affect electrons in both dynamic and static memory, it can cause infinite loops and cycles, or malfunctions in the system. These software malfunctions can be repaired with a soft restart provided by a watchdog.
A watchdog is a timer that counts to zero from a set time (for this reason it is also known as WatchDogTimer or WDT). It needs to be reset (known as “kicking WDT”) before it reaches zero, otherwise it creates an interrupt that causes a soft restart. In this way, if software becomes trapped in an infinite loop or malfunction, the WDT will not be reset in the normal manner, which will trigger a soft restart of the software.
The STM MICROSATPRO is tolerant to Single Event Effects (SEE) in logic and data storage with enhanced error detection and correction. SEE protection is provided through the use of a Fault Tolerant (FT-LEON3) processor core, Triple Modular Redundancy (TMR) in FPGA, Error Detection and Correction (EDAC) in memory units, watchdog on software, and Latch-up Current Limiter (LCL) in power units.
Interfaces.
There is also a variety of sensors on board – to gather electrical, temperature and attitude data. The system-wide bus is the most important data communication interface between the devices and the OBC. It is meant to provide a uniform, digital communication interface and protocol between different devices of different sub-systems and the OBC. These devices are mainly sensors for the PWR and ADCS. This approach simplifies the design of the data acquisition system.
This interface is required to be efficient, support many devices, use minimum wiring and provide some diagnostics about the interfaced devices to the OBC. The InterIntegrated Circuit (I2C) bus is a two-wire interface. It can support many devices using only two-wires (data and clock), unlike SPI, in which the number of lines increases with the number of devices supported due to device selection lines. This makes an efficient system-wide bus, since only two lines have to be routed. This interface works at the standard voltage present in the satellite (3.3 V) and is fast. Also, many sensors supporting this interface are available. There is a ‘command-acknowledgement’ protocol, which helps the OBC in diagnostics in case a device on the bus develops a fault.
The communication between COMM and OBC has to use a USART instead of I2C. This is because the COMM system might need to interrupt the processor but this would not be possible with I2C, since it is master-slave protocol wherein the slave devices, cannot interrupt the master. Support for this interface is an important feature of the design.
System Software
Due to the centralised approach, the system software needed to ensure that all the tasks get the required computational services from the OBC before the deadlines. Some of the tasks, like communication, have strict real-time requirements which the system software needs
to satisfy. The nature of the mission requires us to store messages and data on the satellite. Therefore, a considerable amount of persistent storage is required.
At the logical level, the main ‘layers’ of this stack are
1) The modules that form the lowest-level system software – the boot-up code, the real-time operating system (RTOS), and the exception handlers.
2) Device and interface drivers form a separate module independent of the RTOS.
3) The file-system for message and satellite health data.
4) The modules that execute the OBC functions by making use of the RTOS services and device drivers.
CAES developing space-bound user-selectable SoCs
The European Space Agency (ESA) has signed multiple contracts with mission-critical electronics company CAES to develop and deliver the GR765 system-on-chip (SoC), the first user-selectable CPU for space, which will enable users to choose between the LEON5 SPARC V8 or NOEL-V RISC-V RV64 processor cores.
According to the official announcement, the GR765 SoC will give designers additional flexibility and functionality while providing the higher processing and bandwidth needed for future space applications while enabling the user to reuse legacy LEON SPARC software or develop new software for the NOEL-V RISC-V architecture. Based on the radiation test on the demo chip, CAES reports the SEU [single-event upset] tolerance for the GR765 to be at least five times harder than the current radiation-hardened processors. CAES also says that the parts will allow the software to transparently continue execution in presence of correctable errors amd extend fault tolerance to peripherals and software libraries.
Michael Harverson, head of the Space Segment Section at ESA, said of the agreements: “The CAES GR765 responds to the ever-increasing demands of telecommunication payload data processing, but also benefits a broad range of other mission-critical applications such as on-board computing.”
References and Resources also include:
https://blog.satsearch.co/2021-01-21-spotlight-how-to-choose-a-satellite-on-board-computer-obc