This action might not be possible to undo. Are you sure you want to continue?
1. System Definition:
The Command and Data Handling subsystem (C&DH) is responsible for running the spacecraft in an ordered and ‘intelligent’ manner according to its flight program. It is the brain of the satellite platform. The C&DH is responsible for the overall management of the spacecraft's activities. The system has two main functions: reception and execution of commands from the ground station, and gathering payload and housekeeping data (HK data), to be transmitted to the ground station. Moreover, the C&DH subsystem provides the main bus for the data exchange between all other subsystems. The system manages three data streams, each critical to the spacecraft, and each with distinctive characteristics. Those are: • • • mission/scientific data from the payload housekeeping (HK) data from spacecraft subsystems commands from ground station
The C&DH has to be capable to store those data streams for two main reasons. The first is that payload and HK data can only be transmitted when there is a communication link with a ground station, which occurs once every several orbits, depending on spacecraft's orbit. Furthermore some commands from ground have to be processed at later times, making it necessary to store those commands, and execute them according to their time tags.
2. Functional Requirements:
The system receives commands from the communications subsystem, performs validation and decoding of the commands, and distributes the commands to the appropriate spacecraft subsystems and components. The C&DH also receives housekeeping data and science data from the other spacecraft subsystems and components, and packages the data for storage or transmission to the ground via the communication subsystem. The system must also provide analog-to-digital conversion capabilities for any subsystem components generating analog
and between the satellite and the ground station. In a distributed architecture.g. Power (EPS). temperature sensor). and Communication (COMM) subsystems has its own PIC controller dedicated to performing the respective subsystem's tasks. before being stored or sent to spacecraft bus. the C&DH system is also responsible for the execution of attitude determination and control algorithms. Figure 1 illustrates the command and data paths within the satellite. C&DH Functional Requirements Provide an operating system that controls the spacecraft Assure and control the data exchange among spacecraft subsystems Process Received Tele-Commands Acquire Payload & Housekeeping Data Provide storage for data and commands ProvideA/D conversion capabilities . each of the Attitude (ADCS). In a centralized architecture. state-of-health monitoring. however.signals (e. and managing high-level fault protection and safing routines. as well as power system management algorithms.1: C&DH System Operations Other functions of the C&DH include maintaining the spacecraft clock. Command Payload Spacecraft Subsystems Science Data Command HK Data C&DH Command Science HK Data Communication Subsystem SCIENCE & HOUSEKEEPIN G DATA COMMANDS Ground Station Fig.
… etc) Table. payload. encoding. Telemetry Stream Generation.1: C&DH Functional Requirements 3.1 Hardware The hardware is composed of three main constituents: OnBoard Computer (OBC) ◦ Controls the spacecraft operations in normal mode. Power Distribution) Execute COMM routines – (Validation. It handles the exchange of data between the payload. Mod/Demodulation. Attitude Control) Execute EPS routines – (Power Management. and memory storage of commands. like a phone number. Design Analysis: The development of the C&DH subsystem requires both hardware and software solutions to successfully perform all the above mentioned functional requirements. and HK data. 1 for a full list of OBC functions. Maintain spacecraft clock State-of-health monitoring Manage fault protection and safing routines Centralized Architecture: Execute ADCS routines – (Sensor Data Acquisition. memory and communication. The bus assures the data flow between the different spacecraft subsystems and components. Every component connected to the bus has its own address. It is responsible for the decoding. Data Up/Downlink. This two-wire bus has a data wire. En/Decapsulation. and can send/receive data or commands by following a predefined protocol. Attitude Determination. subsystems. . The I 2C bus by Philips is the most commonly used onboard Cubesats. Refer to table. and a clock wire to synchronize transfers. The OBC is also responsible for managing fault protection and safing routines. System Bus ◦ Subsystems communicate with each other via the system bus. 3.
the OBC can reset and use the original boot loader stored on PROM to assure successful operation of the spacecraft. Space-tested. When in power save mode. Flash Memory is more prone to radiation than PROM. the boot procedure is passed through again. and commands received from ground/control station. External Memory ◦ Flash Memory provides space for payload data. If space radiation corrupts the updated version of the flight software on the Flash memory. and COMM. No code will be executed at this time. as well as flight software updates from the ground station. The board also holds the connectors for the payload and other subsystem boards. Several recommendations from veteran Cubesat builders are available. It brings the devices ‘to life’ and utilizes their features. As soon as the Electrical Power System (EPS) switches from power save into normal mode again. When all devices are initialized. Flash offers a great advantage over RAM in that it does not loose stored data even when powered off. The program code has to accommodate the various mission modes of the spacecraft. However. the satellite is said to be in nominal mode. or a designated kernel to handle satellite operations must be made. The PCB and components have to comply with the size. like VxWorks. When choosing components for the PCB. including boot mode. During boot. nominal mode and power save mode. the C&DH is turned off. namely ADCS. in which the C&DH interacts with the payload. An RTOS. thus it is recommended to also use PROM to store the original boot loader and flight software. HK data. which is unachievable using PROM. particularly temperature and radiation. the micro-control-unit (MCU) of the OBC initializes the other devices and goes into a predefined state.2 Software The flight software is the core element of the C&DH subsystem. and documented in several online resources. Flash memory is also used for storing flight software and boot loader. Commercially available Off The Shelf (COTS) components are easily acquired through numerous vendors. and all the spacecraft subsystems. EPS. enables the programmer to write . mass and power constraints of the Cubesat. The choice between a real-time operating system (RTOS). 3. All the above components will be mounted on a single PCB. the rough space environment must also be taken in consideration.
the programmer will have to write more lines of code since all low level routines have to be written as well). the code is usually furnished much better to the hardware on the lowest level. The other way is to write designated kernels dedicated to the chosen hardware configuration. but rather concentrates on the functions to be carried out. while in distributed architecture. in centralized architecture. latchups) Error Detection & Correction Executive Task Device Drivers Run-time Kernel Sensor Data Processing Attitude Determination Attitude Control Battery Charge Control Power Management & Distribution OBC Watchdog Table 2: Software Functions Fault Protection Operating System ADCS Power 1 Scholz. which does not take into account the final hardware selection.1 The software does not only include the operational system of the C&DH. and the hardware resources can be fully utilized. the OBC will manage and execute the different subsystem routines.g. Aachen University of Applied Sciences . but it is a part of all other subsystem as well. Also the code size will remain relatively small compared to an RTOS (however.code on a highly abstractive level. As mentioned above. those routines are executed via the PIC controller on the respective subsystem board. In this case. Design and Development of a CDHS for a Pico Satellite. System C&DH Software Function Command Verification Command Distribution Data Collection Data Formatting Data Encoding Data & Command Storage Flight Plan Scheduling Flight Plan Execution Redundancy Management Anomaly Response (e. Artur. Table 2 below lists the standard functions required of the different spacecraft modules.
the C&DH system will be required to perform command verification to ensure that it is a legitimate command. The output will describe the system physically. Building on the example stated above. 4. until ready for transmission. Compass I. “Besides the obvious need of an MCU. with specific requirements. the design process will result in a solution architecture. schedule the command for execution according to its time tag. and prepare the data package to be channeled to the intended subsystem. thereby ensuring that each function has an acknowledged owner. and in terms of software on the lowest assembly levels. Although AUC Cubesat might be composed of the same set of subsystems that another satellite has.1 Requirement Allocation The first design step is the subsystem requirement allocation. Additionally. the specific requirements of the particular functional blocks might differ significantly according to the spacecraft mission objectives. The C&DH also requires a storage unit to store command. This also ensures that all necessary tasks and components are listed and that no unnecessary tasks or components are requested.” * This section is highly influenced by the design process of the German CubeSat. The team performs functional analysis to breakdown high-level functions into lower-level function blocks. including both hardware and software. This is done by finding the answer to the question “How can this requirement be achieved?”. Generally. Figure 2 illustrates the entire subsystem life cycle. In other words.2 Functional Analysis The next step is to translate the requirements defined in the previous step into functions. “C&DH needs to dispatch commands from the ground station to the different spacecraft subsystems” 4. The subsequent development activities then cover the production of the system. The overall system is divided into smaller functional blocks. and to map low-level functions to physical or executive components. For example.4. the C&DH requires a system through which the different subsystems can communicate with each other. The Design and Development Process* Starting with requirement allocation and functional analysis. . the requirements can be established by answering the question “What must the subsystem achieve?”. interfaces and relationships between external and internal components. functional analysis provide proposed solutions to the questions asked in the requirement allocation step.
Subsystem Requirements Allocation Functional Analysis Functions Allocated to Hardware Functions Allocated to Software Hardware Definition Software Definition Circuit Design Flow Charts of Modules PCB Layout & Fabrication Programming of Modules PCB Assembly & Testing Debugging System Assembly. Integration & Testing Operation Disposal Fig.2: C&DH Design & Development Life Cycle .
taking into account cost. serving as stepping stones to the subsequent stages. The software architecture and interface between the different software modules are designed. By nature. and a specific memory chip is selected.” 4. or even after launch. “To perform the previously stated example requirement (see section 4. the C&DH has to first verify that the uplinked command is legitimate.1). store the command in the designated memory location. the software structure needs to be defined. software is more susceptible to malfunctions. Scheduling and Distribution are also created. both hardware and software must be used to implement a given function. hardware components are selected using trade studies. … etc. Based on our example. and a memory device to store the command until it is time for dispatching. However. due to radiation. as the designer can make changes. Building on our example. schedule the command in the flight plan. “A specific MCU must be selected. . On the software side. than hardware. The required hardware components are: an MCU to perform all the data management and manipulation. Hardware. on the other hand. It is the decision of the design team how to allocate functions to maximize flexibility.3 Function Allocation Once the system functions are well defined.4.g.4 Hardware and Software Definition Following function allocation. a trade analysis between RAM and Flash Memory as a candidate to store commands is performed. software tends to be a more flexible solution. heritage. Flowcharts for the Command Verification. is very expensive to amend once manufactured. the C&DH will need to utilize both hardware and software solutions. availability. a bus system to connect the different subsystems together.” Figure 3 below depicts the process from Requirement Allocation to HW & SW Definition. in space. Storage. and updates even at late stages of the project. reliability. Top-level flowcharts are also developed at this stage. while minimizing malfunction threats. Many times. Equivalently. they are partitioned and allocated to either hardware components or software solutions. I 2C bus). amendments. package and prepare the command to be channeled through the system bus (according to system bus protocol). the bus system also needs to be chosen (e. and finally initiate and complete the command transfer process.
3: C&DH Design Process Example 4. 4. The first step is to determine how the different devices or components will work together. covering both internal interface and external interface signals (signals .5 Hardware Design & Development After functions are properly allocated. This is one of the major tasks of the C&DH team. Then the signal flow is determined.1 Circuit Design The circuit design is the most time-consuming part of the hardware design process. the hardware design and development process starts. and the hardware has been defined.5. Figure 4 breaks down those tasks in details.Fig.
3 PCB Fabrication Once the PCB design is completed. physical connection. 4. The process is then followed by routing. structured programming and top/down design. 4. The PCB is then inspected and tested for any points of failure. content and compatibility must be taken into consideration. Circuit Design PCB Layout PCB Fabrication Fig. Both are mutually important and only the .2 PCB Layout The circuitry created in the previous step needs to be translated into physical tracks. including mechanical constraints like board size and mounting methods. Issues like data structure. the components can be soldered in place. which is the process of laying down tracks to connect components on the PCB. the layouts can then be sent to the fabrication or production. Once the board is fabricated. The part placement process should try to minimize radiation threats and extreme temperature variations.5. 4: Hardware Design & Development Process 4. or points of attachments. Part placement is also one of the most critical layout activities. The result of the circuit design process should be a set of schematics showing the logical interconnections between components within the C&DH subsystem. The process also takes into account any constraints that might be affecting the design.6 Software Design and Development There are two design approaches that are well established among software engineers. along with the main bus and other subsystem connections. for example by placing high heat emitting components next to low heat emitting components.5.between C&DH and other subsystems). and the design is verified.
simultaneous use of both strategies can form an efficient synergy. residing between the application layer and the low-level drivers. The top/down design approach. a highly modular design is desirable. It is responsible for translating the functions of the application layer into device-specific functions. Obviously. Interfaces between modules need to be clearly defined to allow different parts of the software to communicate efficiently with each other. the C&DH is required to interface with all the hardware and software solutions onboard on the satellite. It also facilitates later changes and modifications that might be required to be uplinked to the satellite from the ground station. these driver routines are hardware specific. As mentioned before. the I2C bus by Philips is selected for the system bus. the I 2C serial bus connects all the spacecraft subsystems with each other. on the other hand. which is highly appreciated by other developers wanting to familiarize themselves with the existing code. Application Layer Device Interface Layer Low Level Drivers Layer Fig. A master (in this case the MCU of the OBC) is the device . Structured programming brings more transparency into the code. acts as logical representation of the hardware. As shown. then elaborates the subsequent levels into finer details during the design activity. on the other hand. The physical domain of the spacecraft subsystems is shown in figure 6. The low-level drivers layer. focuses on the bigger picture first. 5. allows higher-level computer programs to interact with hardware devices onboard. The device interface layer. Since the Cubesat project is divided among several developer groups. 5: Software Top-Down Design The application layer covers the high level main application code. Software Architecture Recall. and can only be written after the specific hardware has been selected.
Header include the length of data packages. Fig. The addressed device is considered a slave.g. the satellite is powered-up. marking the beginning of its mission in space. This process is repeated every time the OBC is restarted. the C&DH runs the boat loader.that initiates a data transfer on the bus and generates the clock signals to permit transfers. 6: Cubesat Physical Domain 5. Data or Command. At this moment. locates and initializes all the different spacecraft subsystems and peripheral devices. CRC Checksum). and the specific module contacted in the slave.1.1 Software Elements 5. Stop Communication. and finally loads and starts the spacecraft's OS or designated kernels. The complete protocol should include: Start Communication. Acknowledge Bit. Header. . This is one of the most critical moments in the mission's lifetime. Error Check (e. which configures the OBC. R/W.1 Boot Loader A few moments after orbit insertion. An I2C protocol needs to be designed on top of the I2C bus. Address.
and that the current boot-up had failed. which lets the OBC continuously boot from a broken operating program. thus making the Boot sequence more reliable. and the operating system gives the proper instructions. If the watchdog timer times out. giving programs direct access to hardware resources. Drivers are very useful since they . or not. The new boot sequence should then be carried out from a different boot sequence version. and their program code will be compatible with any device. 5. These create the interface between the OBC hardware. 5. A watchdog timer should also be implemented during the start-up process. With hardware abstraction.1 Hardware Abstraction Layer A Hardware Abstraction Layer (HAL) is a low-level software that supplies a simple interface to access hardware features.1. the power unit should turn off the OBC and restart it. if not. If the OBC finishes the boot-up sequence.1. or as a result of a latch-up. the original version is loaded from PROM. the OBC should check if there is software updates in Flash memory.2. In this case. it means that there is a problem in the boot sequence. and the C&DH software.1. This prevents the the boot loader to enter a “boot loop”.2 Device Drivers The C&DH should provide the driver software that is used for accessing hardware components. A device driver is a piece of code that allows the operating system or user application to set up. the boot sequence is executed using the Flash version. When booting from Flash. This means that programmers do not need to know how the individual devices work. If there is. it resets the timer. access and utilize a specific hardware or peripheral device. the programer can write a code that tells the operating system what a given device should do. indicating that the boot sequence was successful. If an error occurs during the boot sequence. a check needs to be done to make sure data is not corrupted.as the spacecraft comes out of power save mode. On every start.2 Hardware Support 5. This will allow application software developers on the Cubesat to write device-independent applications by providing standard OS calls to hardware.2. the OBC should be designed to automatically reboot using a redundant software version.
www. the total ionizing dose effects are negligible and can be ignored. This enables programmers to seamlessly reuse code even when the hardware platform changes. Single Event Phenomena (SEP). there is another major source of concern. Radiation particles from solar or galactic origins bombard the spacecraft. This isolates the driver's implementation from the hardware platform variations. A driver implementation typically interacts with the hardware peripheral it is controlling through sequences of register reads and register writes. Fig. a single particle can penetrate the surface of the 2 Acal Technology.2 5. 7: C&DH Supporting Software Layers As shown above. However. namely. protocols and timings.allow an application to access the features of the OBC without any low-level knowledge. Figure 7 below shows the progression of the different software layers in the C&DH system. Because of the short orbital lifetime of cubesats. In this phenomenon. such as registers. the software driver's interaction with the hardware platform is done through the Hardware Abstraction Layer.com . posing threats to the onboard electronics.acaltechnology.3 Error Detection/Error Correction The harsh radiation environment of space takes its own toll on the spacecraft. The implementation of the HAL translates the read and write requests into the bus transactions relevant to the hardware platform.1.
such as erroneous calculations. in the order of probability of occurrence are: • Single Event Upsets: This is a logic reversal process. and employing checksum algorithms. and can only be minimized by the proper shielding and hardening techniques. Swenson. or vice versa. This can result in numerous side effects. and subsequently cycles power to the entire satellite. each board within the spacecraft monitors its current-flow. If not promptly performed. the software architecture is expected to be highly modular. which in turn cycles the power to the board/device. Power-cycling the device (turning off the device. This is very uncommon. permanent damage to the device can result from the excessive heat. • • 5. and operation setting changes. The C&DH design must be able to detect high current-flow through each board and cycle power accordingly. erratic software execution. then back on) is the only feasible remedy for clearing a latch-up condition. thus it generates an enormous amount of internal heat. Several approaches can be utilized to detect and correct these types of error. targeting electronic components.C. or avoid it).. M. employing hamming codes. command and data corruption. The OBC determines the board that needs to be reset and provides a reset signal to the EPS. J. Since the OBC is equally susceptible to latch-ups.1. which means that each module is responsible for performing a specific function on board of the 3 Jensen.spacecraft. the EPS must employ a watchdog timer to monitor the OBC's power. This current-flow can be several orders of magnitude larger than the device’s typical operating range. using majorityvoting logic. 3 Single Event Burnout: This causes a permanent failure to the device. the current monitor signals the OBC via the I2C bus. Single Event Latch-up: A latch-up event results in an abnormally high current-flow through a device. flipping a single bit from 1 to 0. The three major effects of SEP. Command and Data Handling Subsystem Design for the Ionospheric Observation Nanosatellite Formation (ION-F) . Possible solutions include including redundant memory devices. If the current-flow into a board rises above a predetermined reference level. where the radiation particle strikes the hardware component.3 System Architecture Modules As mentioned before. causing malfunctions. Using current monitors. (No software algorithms or subsystem commands can fix it.
Similarly. All spacecraft application modules interface with each other through the FLT_MNGR. Figure 8 presents the spacecraft software architecture. and the different threads forming each module.spacecraft. let's call it the ADCS Module. which is a time scheduler that specifies the execution of tasks or commands onboard of the satellite. the attitude determination and control algorithms are grouped in one module. FLT_MNGR plays a central role in data distribution. 8: Spacecraft Software Architecture For instance. This simplifies the communication paths between the different modules. the main functions of the C&DH are based on a flight plan. the C&DH hosts a Flight Manager (FLT_MNGR) program that controls all the tasks of the spacecraft. To facilitate the interface between the different software modules. For example. the power management and distribution routines are grouped in another module. Commands . and makes the module integration process much more robust. EPS Module. depicting the different modules onboard the satellite. Fig.
most of the problems occur where the software meet the hardware. Integration & Verification According to several Cubesat team developers. FLP module then schedules the tasks for execution. Fig. They are then forwarded to the FLT_MNGR. The integration and verification of the C&DH has four main levels: • • • • Software Level Subsystem Level System Integration Level System Level (Application Level) (C&DH Level) (Subsystem Interface Level) (Spacecraft System Level) . and decapsulation of data packets. Note that drivers for all the different devices will need to be integrated in the architecture to assure proper interaction with all system devices. and saves them in the designated location on flash memory. Figure 9 shows an exploded view of the driver architecture onboard of the spacecraft. 9: Application. demodulation. Driver & Hardware Level Exploded View 6.are usually transmitted to the satellite via the ground station. which in turn channels the commands to the Flight Plan (FLP) module. Once received. the COMM module performs command validation.
4 Vaartjes. Amini. respectively. inefficient executions. and detailed system architecture is also critical to the success of the C&DH team. 4 Note that every time software is changed. Following a unified coding format can save the team tremendous time and effort throughout the project lifetime. 10: C&DH Integration & Verification Flow There is a tendency among programmers to use their own programming style. R. and a hectic interface and integration process. This practice translates into undesirable redundancies. design decisions. and not to stick to a specified project format. Hamann. One small decision can have a domino effect on the whole system.. Fig. Integration and Verification of a Command and Data Handling Subsystem for Nano-Satellite Projects with Critical Time Constraints: Delfi-C3. Structured meetings will be scheduled to allow all project team members to interface with each other. Keeping up to date documentation of the design process. . as well as between other subsystem teams will eliminate critical problems on subsystem level. J. and discuss any pending design decisions or recommendations. B. Close interaction among team members. and system integration level. no individual decisions can be taken on this project. Remember. R. flowcharts.The levels and their location in the flow are illustrated in figure 10. the integration and verification loop has to return to the beginning of the test flow.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.