General characteristics of a spacecraft data bus
The acquisition of data from sensors and the commanding of actuators was the original role of the spacecraft onboard bus. Typically, the bus comprised a central controller with a number of remote terminals attached. Each remote terminal implemented a certain number of interfaces to sensors and actuators, such as thermistors and on/off switches.
To read a given sensor, the bus controller issued a command to the remote terminal to which that sensor was attached, and the remote terminal then read the sensor and transmitted the result back to the bus controller. Similarly, to write to a device, e.g. to operate a switch or relay, the bus controller issued a command to the appropriate remote terminal, which then wrote to the device itself. The commands issued by the bus controller were generally very short, typically in the form of 16 bit opcodes, and responses from remote terminals, if any, were usually also short. Addressing and control information was needed in addition to the command and response data, but even with this, commands and their associated responses usually occupied not more than 32 bits.
The need to transfer packets of data across the spacecraft bus has arisen as more capable microcontrollers and microprocessors become available for use in remote terminals. Firstly, this enables larger and more complex commands to be sent to the remote terminals, where they can then be decoded and may result in the acquisition of data from several sensors, or the execution of a series of actuator commands. Secondly, it becomes possible to run software applications in the remote terminals. These applications are usually targeted towards simple automatic operations, such as the periodic acquisition and formatting of data from several sensors without waiting for a command from the bus controller, but use of microprocessor-based payload control units is on the rise, giving then birth to systems where the ‘slave’ is much more complex than the ‘master’. Another growing requirement is for the initial or updated programme loading of remote terminals, and occasional loading of configuration tables during operations.
Finally, the need for the distribution of time information is a consequence of the increasing autonomy and capabilities of the remote terminals, and the devolution of control functions to them. Such a devolved system can be considered as a set of independent, asynchronous processes. However, for operational purposes it is necessary that all of those processes can access a common, coherent time reference. One obvious need for this is in the time stamping of locally acquired data so that a complete event time-line can be reconstituted from the spacecraft telemetry. Another example is in the synchronisation of control actions, such as synchronisation of a spacecraft attitude control manoeuvre with the acquisition of an image.
Time distribution involves the transfer of time data with the appropriate precision, and the distribution of a time reference pulse or tick that indicates exactly when the time data is valid. While all onboard busses have the capability of transferring the time data, they vary considerably in their ability to transfer the reference pulse. If it is not possible to distribute the reference pulse with sufficient accuracy through the onboard bus, it becomes necessary to use an external means of transferring this pulse, e.g. by adding a dedicated time distribution bus, which increases the spacecraft harness.
Most of the current space borne controls are then based on Centralized Control systems where a single central control unit is responsible to control the application tasks and performing data management, resulting often in high performance (MIPs, communication throughput) requirements for the CPU. Another downside of the current systems is the physical concentration of I/O interfaces resulting in a great amount of wiring and connectors and considerable impact on reliability, tests and maintenance.
Heritage and availability reasons have brought to a situation where serial communication standards such as MIL-STD-1553B and RS-485 are established for space use despite they are meant for Distributed Control architecture in form of Master/Slave or Client/Server configuration.
Nevertheless the above standards are limited to the Media Layer definition, and, especially for MIL-STD-1553 case, were optimized for systems with requirements very different from modern spacecrafts , and lack a comprehensive and robust data layer standardization to be used as general purpose backbone for the year to come allowing the use of more modern design test and integration techniques.
When miniaturization and/or strict power budgets start playing a role then the limitations of currently used bus interfaces are even more striking. Typical (secondary) power consumption of a MIL-STD-1553 RT is around 1W, and this is often a sizing number for DCDC converters for small units.
Situation with other busses is not any better: for RS-485, the most common and robust bus capable physical layer, IC transceivers differ greatly in their supply current versus data rate, but power consumptions around 250mW are the norm. On top of that, unavailability of 3.3V transceiver means that LDOs need to be used to power all the remaining 3.3V electronics.
