• No in-orbit software update capability, but configurability through the use of an On-Board DataBase
• Use of Distributed Architecture (with single master) instead of original Star Architecture
• Subsystem microcontrollers will operate autonomously in case of failure of the On Board Computer(OBC) or I2C serial bus

The CDHS consists of many building blocks. Functionally, it is divided as indicated in the second figure on the right. The OBC controls the whole satellite, but each subsystem has one or more microcontrollers for local control. Most internal communication takes place via I2C on the System Bus. The tree shows three different types of microcontrollers. Keywords for CDHS functions have been listed under the blocks to show how they are allocated to the items.

So how does one implemented this in subsystems? The diagram below provides an explanation:

Both the CDHS as well as the Electrical Power Subsystem(EPS) are spread throught the satellite, physically. Every subsystem has a local microcontroller (PIC) and a local EPS part, under control of the CDHS, which can be switches and regulators, depending on the subsystem. The OBC provides central control on its own PCB, which is interfaced to the other systems vua the COMBO PCB. The COMBO PCB is combination of the interface from our custom System Bus to the COTS FM430 Flight module that was bought from Pumpkin Inc. and it houses the Receiver side of the AWSS payload. Note that only the I2C bus wires have been drawn in, in fact there are many more lines for electrical power and a few dedicated data lines fro some subsystems. However, this should give an overview of the way the CDHS is implemented.

Under control of the CDHS, the general operation of the satellite takes place as follows:

• Every subsystem that receives electrical power activates its own default mode. This default mode is a useful mode for the satellite, i.e. the subsystem will perform minimal functions.
• The default modes of all subsystem will result in OBM Deployment mode. When deployment has been tried often enough or when deployment was successful, the default mode will become OBM mode. Measurements will be performed autonomously, and the OBM downlink signal will be generated in the VCOs on the Measurement Boards and sent to the RAP for downlink.
• As soon as the subsystem’s PIC establishes communication with the OBC, the operation of that PIC and subsystem comes under OBC control. From then on it will perform nominal functions as defined in the OBC Modes.
• The OBC decides on satellite operational modes autonomously. The default mode that the OBC will go to is the OBC Science mode and under certain conditions it could revert to Basic Mode for diagnostic purposes. By ground command the default mode can be set to either OBC Science, OBC Transponder or OBC Basic Mode.
• The OBC listens for ground commands on both uplink receivers. Ground commands will overrule on-board autonomy, command actions to be performed, or parameters to be changed.
• After enough science data is gathered, a ground command can be sent to switch to OBC Transponder mode. Another option is to toggle between OBC Science Mode and OBC Transponder Mode by means of ground commands before all science objectives have been met.