OBC and memory module

Satellite systems are generally engaged in the collection and transfer of information or commands among all of their subsystems. The OBC is at the heart of this data transfer and acts as the onboard communications link between all other subsystems. It is an embedded computer dedicated to command and data handling (C&DH) of the satellite. The major OBC specifications need to be determined and optimised to ensure secure and efficient data flow since different transfer rates are used between subsystems (Hidayat, 2010).

Onboard parameters such as temperature and power consumption in different sections of the satellite are constantly measured and stored in the OBC’s memory module and constitute telemetry data to be downloaded to the ground station during an overpass. From the ground station, newer versions of the FSW can be uploaded via the uplink channel and new orbital parameters can be defined and implemented. This is also accomplished by the OBC which decodes these telecommands and executes them by in turn commanding the other subsystems to achieve the desired action (Polaschegg, 2005).

The OBC also makes use of the data from ADCS sensors to determine the attitude of the orbiting satellite and controls the ADCS actuators to control the satellite’s attitude. This is done by loading a pre-defined control algorithm into the microcontroller and executing manoeuvres whenever necessary (Hales et al., 2001).

As illustrated in Figure 2.3, the OBC is composed of both hardware and software components. Such a global visualisation is very useful to associate all the OBC elements with their respective functions and build the OBC architecture based on these elements (Noergaard, 2005). These two components are presented in more details:

a. Hardware component

Also called the physical layer, the hardware component contains all the physical electronic components that are located on a PCB. It is the lowest level in the OBC model and consists essentially of a microcontroller with various peripheral interfaces and supporting hardware with a memory module to store programs and data.

15

Figure 2.3: OBC subsystem model (Adapted from Castoulis, 2005)

Castoulis (2005) defines a microcontroller as a central processing unit (CPU), memory and some Input/Output (I/O) devices all contained within a single integrated circuit (IC) and interconnected by an internal bus system. The processor is central to the microcontroller unit and represents the most important part of the system. It manipulates data in a way specified by a sequence of instructions defined in the software layer and intended to suit a given application or program. Selecting the ideal microcontroller is crucial since it constitutes the backbone of the OBC design.

In general, microcontrollers are classified according to their instruction set, memory and internal bus width. Singh (2004) states that the nature of the arithmetic logic unit (ALU) determines if the microcontroller is classified as 8-bit, 16-bit or 32-bit depending on logical and arithmetic operations which will then, respectively, be performed on a byte (8- bit), a word (16-bit) or a double word (32-bit).

The internal memory (also referred to as on-chip memory) of the microcontroller is divided into two types which are defined by Botma (2011) as follows:

16

 Flash memory: It is a variation of electrically erasable programmable read-only memory (EEPROM) which is accessible in blocks of data. It is the non-volatile portion of the memory, meaning that it retains its value even when power is removed in the system. It has the advantage of presenting fast access time and has a high tolerance to radiation effects.

 Static Random Access Memory (SRAM): It is the volatile portion of the memory, meaning it loses data when power is removed. The read and write operations on SRAM are very fast; it is thus used to store program data which are temporarily allocated and constantly changing during the run of the program.

On-chip memory is usually insufficient and in most cases, microcontrollers provide support for external memory devices in order to expand the memory capacity of the system. In an OBC subsystem, the selected microcontroller should allow for external memory expansion since housekeeping and payload data are usually of sizes bigger than the space available on-chip. The external memory module can also be used to store program applications that would run on the microcontroller and that may require additional memory space (Sakoda, Horning & Moseley, 2005). Various components are available that can be used as memory expansion modules such as secure digital/multimedia cards (SD/MMC) and memory ICs.

The I/O devices (or peripherals) are integrated in the microcontroller and are used by the processor to communicate with other external devices (Catsoulis, 2005). In the case of the CubeSat, these peripherals create an interface between the OBC and the other subsystems. The CubeSat architecture requires a standard serial data bus protocol to be used for fast data rate transfers between subsystems. This data transfer is initialised and monitored by the OBCs’ microcontroller. Common serial interfaces found in microcontrollers include universal asynchronous receive-transmit (UART), inter- integrated circuit (I2_{C) (also known as two wire interface (TWI)) and serial peripheral} interface (SPI).

Additional supporting hardware components to the microcontroller are necessary to ensure the OBC runs efficiently. According to the work published by Clausen et al. (2001), it is recommended for the OBC subsystem to include an overcurrent protection

17

circuitry, a battery backed-up real time clock (RTC) and one or more on-board temperature sensors. The overcurrent protection is needed to monitor the current drawn by the subsystem and disconnect the supply in case of an overcurrent condition. The RTC keeps track of the time and helps to synchronise onboard operations. The RTC also keeps onboard data synchronised with the ground operations. Time is typically encoded in a timing format known as the Unix Time Counter (UTC8_{) system and} interrupts are used to synchronise events between subsystems. The RTC’s power is backed up with a battery so time is not lost when the OBC’s power is removed for any reason. The on-board temperature sensors are necessary to monitor the variations in temperature at different points of the CubeSat which are exposed to the harsh space environment.

b. Software component

The software component commands the processor and controls its operability and functionality. There are three layers of software that are represented by a common shade in Figure 2.3, each interacting only with the layer(s) directly above or below it.

When the microcontroller powers up, it is necessary that the processor’s internal registers be configured to an initial state in order to operate correctly. The piece of software responsible for this process is known as the firmware and is the lower software component layer that communicates directly with the hardware component layer and the operating system. The operating system is the system software component that manages the use of and access to the memory and other peripherals within the microcontroller. It acts as a host for applications and is responsible for the management and coordination of activities and sharing of other resources in the OBC subsystem, making it easier for the user to write and run applications (Catsoulis, 2005).

Applications within the OBC are organised in tasks to which a priority level and a deadline are assigned. These tasks are co-ordinated by a real time operating system (RTOS) which according to Whilmshurst (2007) accomplishes three major functions when implemented in a system:

 It decides which task should run and for how long;

18

 It provides communication and synchronisation between tasks and

 It controls the use of resources shared between tasks, for example memory and hardware peripherals.

The implementation of several applications (or multi-tasking applications) based on a RTOS constitutes the CubeSat’s flight software (FSW). Hidayat (2010) defines the FSW as “the central intelligent system of the modern satellite that can run on a single chip”. Enright (2002) further summarises the major flight software functions as follows:

 It schedules satellite activities autonomously when the satellite is away from the ground station radiation coverage, such as scheduling the payload imager to take a picture of a certain location at a particular time;

 It responds to ground user telecommands during the ground station overpass. The FSW should be able to interact with the ground user by accepting all the valid commands and execute commands based on their parameters;

 It performs data logging by taking measurements of the housekeeping parameters (telemetry) and stores them into the memory device until they can be sent to the ground station. Data logging also includes the logging of events that took place during flight ;

 It performs data management, including data structure and protocol.

When the use of a specific RTOS is required, the selected microcontroller needs to be supported by it. An adequate integrated development environment (IDE) to write and compile applications or tasks is also needed in order to program the microcontroller or load the RTOS.