Architectures of Onboard Data Systems
On-board Data Systems encompass a vast range of functional blocks that include Telecommand and Telemetry Modules, On-Board computers, Data Storage and Mass memories, Remote Terminal Units, Communication protocols and Busses. These elements are common to all projects and are subject to a demanding set of evolving requirements from Science, Exploration, Earth Observation and Telecom missions.
Figure 1 represents the reference architecture for Avionics as defined by the SAVOIR Advisory Group: this reference architecture is applicable to the following scenarios:
- ESA Science and Earth Observation missions (LEO, GEO,Lagrange points, Interplanetary space) ,
- Telecom missions and
- Commercial earth observation missions.
The parts coloured in green define the elements that are inside the domain of competence of the On-Board computer & Data Handling section:
- On-board Computer :
- Remote Terminal Units :
- Platform Solid State Mass Memories :
- TM/TC units :
- Busses & Communication protocols :
The On-board Computer (also referred to as Spacecraft Management Unit - SMU or Command & Data Handling Management unit - CDMU) is the central core of the Spacecraft Avionics. The Central Processing Unit (CPU) hosts the Execution Platform SW (composed of RTOS, BSP, SOIS layers, PUS, …) and the Application SW. Volatile and Non-volatile Memories, Safe Guard Memories, On Board Timer, Interface controllers and Reconfiguration modules are the other main blocks of a OBC. The figure above shows a functional architecture of the On-Board Data System where all the major functional blocks are indicated with their intercommunication links and their typical redundancy scheme.
Remote Terminal Unit
Remote Terminal Unit (also called Remote Interface Unit-RIU) is a unit that is usually present on medium-large size spacecraft. The RTU offloads the On Board Computer from analogue and discrete digital data acquisition and actuators control tasks.
Platform Solid State Mass Memory
For Earth Observation missions the mass memory for the P/L data may belong to the satellite platform and sometimes, , depending on the capacity required, might be included inside the OBC as a single module.
The telecommands, once validated, are multiplexed to the intended addresses. There are two categories of commands: the high priority and the normal commands. The high priority commands (HPC) are sent to the Command Pulse Distribution Unit (CPDU) for immediate execution. The CPDU is either internal to the TC decoder or external and its implemented in hardware, i.e. no software is involved in the execution of HPCs. The normal commands are sent off to the OBC CPU to be either processed or relayed on the system bus. The Telemetry encoder collects the Telemetry packets from different sources (processing, data storage, essential telemetry, payload), assembles the Telemetry transfer frames and sends them to the TM/TC transceiver to be downloaded to the ground.
The most common command and control bus used on a spacecraft platform is the MIL-STD-1553B covered by the ECSS-E-ST-50-13C. An alternative to the MIL-STD-1553B is the CAN that ESA and the European Space community is standardizing for space applications. UART serial channels are also used especially to control AOCS sensors. The Spacewire technology is now being increasingly used for data transfers < 160 Mbit/s and it can combine the command and control function with massive data transfer.
The space community is asking for a real improvement in the specification and use of communications protocols. Typically, previous developments have harmonised physical interfaces and low level data link protocols but above this level proprietary solutions have been utilised. This has without any doubt increased development and integration costs and limited the possibility of element reuse without expensive modification. In comparison, the commercial market on ground has systematically pursued the use of multilayer protocol stacks resulting in simple integration and multi vendor compatibility. This commercial trend is now being adopted for the flight avionics by the development and standardisation of protocols above the basic link layer.
Human Space Flight avionics architectures
For Human Space Flight avionics architectures different from the ones presented in the first two diagrams have been and are developed. For manned space mission and in particular for critical mission phases the key feature is the availability of the avionics system: a standard redundant architecture based on two branches in cold redundancy is not adequate because the recovery time in case of failure can be excessive. ESA and its industrial team, led by Daimler-Benz Aerospace (DASA), supplied the data management system (DMS-R) for the Service Module of the International Space Station's Russian Segment. The above image shows the DMS-R's Fault-Tolerant Computer (FTC).
A FTC is usually composed by three (3) or four(4) single computer units operating in hot redundancy with a voting mechanism that supervises the behaviour of the composing elements. DMS-R not only controls the module itself, but also performs overall control mission and failure management of the entire Russian Segment, and overall guidance and navigation for the whole station. Several computers also implementing less sophisticated redundancy scheme are present on the ISS as control unit for internal and external Payloads.
Evolution of the DMS-R will be based on more powerful processing core (Leon2) and will make use of more advanced internal bus : see image of SPAICE.
Last update: 1 May 2014