UC CubeSat Main MCU Software Requirements Specification 23 November 2012 Adam Goodwin
Table of Contents 1. Introduction... 3 2. Problem Statement and Scope... 3 3. Software Sequences... 4 3.1. Overall System... 4 3.2. Timing (Using Real-time Timer)... 5 3.3. Temperature Sensor Interaction... 5 3.4. Gyroscope Interaction... 6 3.5. Communications Board Interaction +... 7 3.6. Sensor Board Interaction +... 7 3.7. Power Board Interaction +... 7 3.8. Memory Interaction... 8 3.9. I 2 C Interface... 8 4. Main MCU Software Architecture... 9 5. Context Diagram... 10 6. Requirements List... 11 High Level Requirements... 11 Low Level Requirements... 13
1. Introduction The main microcontroller (MCU) of the UC CubeSat is an Atmel AT91SAM7S16. The purpose of the main MCU is to perform the overall control, coordination and management of the satellite s individual components. The main MCU is housed on the mainboard of the satellite, along with several other components. It is to communicate with all of the components of the satellite via a single I 2 C bus. This includes the components housed on the mainboard as well as the generally undetermined components which are to be attached to other boards. The communications board is also to utilise an AT91SAM7S16. The idea is that it will be capable of performing the same function as the main MCU, if required, as opposed to managing only the details of communication with the ground. 2. Problem Statement and Scope Currently there is no software written for the CubeSat. The goal of this project is for software to be written for the main MCU, allowing for the operation of the satellite. The complete satellite description, including its hardware and mission, has not been concretely defined. In particular, the use of the I 2 C bus means that almost any number of modules and devices can potentially be added to the satellite in the future. This means that the project is open-ended, and so a limit needs to be placed on the scope of these requirements in order to allow the project to at some stage be considered complete. The scope of the main MCU software will be limited to designing some form of operating system or scheduler for the satellite, as well as the software for performing the required interactions with the satellite s modular components. The scheduler should provide a framework such that the satellite s as-yet-undefined tasks can easily be added at a later time. In other words, the scheduler should provide a generalised mechanism for executing any given task that the satellite is to be capable of. In terms of performing the required interactions with each of the satellite s modules, the only strict requirement of the software is that it can do this for the components built onto the mainboard. (These components are the EEPROM memory, gyroscope and temperature sensor). The software should still be built such that it can easily be extended to handle new devices, as well as the other boards and components which are expected to be incorporated into the UC CubeSat in the future (for example the communications board), but complete software for the use of these modules will not be possible until these boards hardware has been finalised. Finally, the software will need to be designed such that it is fault tolerant, particularly with respect to the high energy radiation that can be expected once the satellite is deployed.
3. Software Sequences What follows are the key sequences, represented diagrammatically, that the main MCU s software will be able to perform. These provide a starting point for the software implementation. By writing software that allows the satellite to perform each of these sequences, the bulk of the necessary software will be completed. However, during development there are likely to be significant changes as new information arrives, and so these sequences most likely represent a bare minimum of functionality. These sequences involve not only the interactions with the components on the mainboard, but also include some of the expected interactions involving other boards. These sequences are marked as such with a superscript plus sign. The purpose of including them is to give an indication of where the extensibility points of the software will be, so that the software can be built to accommodate the future functionality. It is most likely that there will be only a small amount of interface code written for these particular interactions at least until a later date. Note that a block containing a circle in the top left corner represents a starting point for a particular sequence. Dotted arrows connected to a block represent the exit to, or entry from, a higher or lower level of software. Finally, dotted rectangles enclose blocks which depend on communication over the I 2 C bus. 3.1. Overall System Initialisation Scheduling and running of tasks. Shutdown/restart procedures if required Receive instructions from ground station* *The instructions from the ground station are likely to be heavily dependent on the CubeSat s mission. A general framework for carrying out ground station commands is therefore what is implied here.
3.2. Timing (Using Real-time Timer) Get elapsed time Obtain time from register Return control to parent This will be required for scheduling tasks as well as time-stamping sensor readings and other information 3.3. Temperature Sensor Interaction Temperature read Obtain reading from 16-bit register Save/transmit/use temperature reading One-shot mode enable/disable Select ADC resolution Set fault queue size (no. of readings to trigger an alert) Sensor configuration* Alert polarity (active high vs. active low) Return control to parent Alert type (comparator vs. interrupt) Shutdown enable/disable Temperature limit (set min/max) *Consult the TCN75A Temperature Sensor datasheet for further details
3.4. Gyroscope Interaction Read gyroscope Obtain X reading from 16-bit register Obtain Y reading from 16-bit register Obtain Z reading from 16-bit register Convert reading to angular speed in appropriate units Save/transmit/use angular velocity reading Data rate and bandwidth selection Set power mode (down/sleep/norm) Configure highpass filter Sensor configuration* Full scale selection (degrees per second) Return control to parent Select read mode (FIFO vs. bypass vs. stream etc) Configure interrupt on X/Y/Z threshold value Other configuration settings* *Consult the L3GD20 Gyroscope datasheet for further details
3.5. Communications Board Interaction + Receive from ground station Receive data Save/use received data Transmit to ground station Send data Return control to parent Configure communications module Set configuration options 3.6. Sensor Board Interaction + Obtain measurements Receive readings Save/transmit/use sensor readings Configure sensor module Set configuration options Return control to parent 3.7. Power Board Interaction + Power board configuration Device power enable/disable Set configuration options Enable/disable power to selected device Return control to parent Get operation status Receive information
3.8. Memory Interaction Read operation* Current address read Random read Sequential read Error checking and correcting Return control to parent along with any data read Byte write Page write Write operation* Prepare data for fault tolerance, e.g. add a checksum *Consult the AT24C128C EEPROM datasheet for details on the read and write operations 3.9. I 2 C Interface Read from a device Receive data Save/use data received Write to a device Send data Return control to parent
Task status Permission to run Angular velocity readings Configuration Status information Configure and enable/disable device power Sensor readings Configuration 4. Main MCU Software Architecture From the previous section it becomes clear that there will be several modules and interfaces in the software system for the CubeSat. Below is a diagram which summarises these software components. Task scheduler Transmit data, configure Receive data Tasks Temperature readings Configuration Temperature Sensor Module Communications Board Module Gyroscope Module Sensor Board Module Data read Data write EEPROM Module Power Board Module I 2 C Interface
5. Context Diagram In the below diagram, the main MCU and its software is shown within the context of the CubeSat system as a whole. Mainboard Temperature Sensor EEPROM Data retrieval Configuration, data requests Temperature readings Configuration, data requests Gyroscope Sensor data, logs, saved tasks Main CubeSat MCU X, Y and Z axis spin readings Configuration, requests for board status, power control Board status Instructions from ground, board status Requests for board status, data to send, antenna deployment Sensor readings, board status Configuration, requests for data Power Board Sensor Board Communications Board Instructions for CubeSat Data to ground Ground Station
6. Requirements List Below are the requirements for the UC CubeSat s main MCU software. Again, these represent a general and open-ended expectation for the system additional functionality should be implemented as the need for it becomes apparent during the course of the project. High Level Requirements R1. The UC CubeSat software shall be built to function in different mission modes, corresponding to the stages of the satellite s flight, as well has handle transitions between these modes. The major modes are described below: R1.1. Booting up: The CubeSat software shall perform a booting up procedure, readying the satellite for operation during flight. R1.1.1. This shall be taken care of by the task scheduler during its initialisation. R1.2. Detumble: Although the attitude control system of the UC CubeSat is passive, useful actions can still be performed during this time: R1.2.1. Using the onboard gyroscope the software shall log angular velocity information. This can be used to verify the success or failure of the passive control system. R1.3. Science collection: The UV sensor board (or other apparatus chosen for the CubeSat) provides the main purpose of the CubeSat s flight. There shall be software for use during this time that carries out the recording of data and performs any necessary processing. R1.3.1. Data shall be stored in the EEPROM on the mainboard. R1.3.2. Recording shall occur at a low enough frequency such that the available space in EEPROM is not consumed in a short space of time. R1.3.3. Recording shall also occur at a frequency low enough to prevent an unmanageable amount of data needing to be transmitted during a communication window. R1.4. Ground station contact: The CubeSat software shall handle communication with the ground in order to receive commands and pass on data. R1.4.1. As per the CubeSat specification, the CubeSat shall wait 30 minutes before deploying the antenna or enabling communication with the ground. R1.4.2. Possible contact times are likely to be infrequent and short. The software shall ensure timely ground station communication such that the window is not wasted. i) The contact should be initiated by the ground station, so that the CubeSat does not have to use power on wasted transmissions. It is upon receiving the initial message from the ground station that the CubeSat should ensure priority is given to communication, so as not to waste the communication window.
R1.4.3. To inform those at the ground station of any problems with the CubeSat, communication should begin with the transmission to the ground of the status of each aspect of the CubeSat. R1.4.4. The remainder of the communication window shall be used by the CubeSat to send experimental data to the ground station, as well as to receive commands from the ground station. i) Commands that the CubeSat receives shall be able to be scheduled and executed when desired by those on the ground. R1.5. Safehold: The software shall implement a safehold mode where all unnecessary devices are powered down and the CubeSat is readied to receive commands from the ground station. This shall occur if there is a significant problem with the satellite. R2. The CubeSat shall monitor the status of other boards and be able to resolve issues. R2.1. The CubeSat software shall make use of the MCU s watchdog timer in order to escape from being locked into a section of code. R2.2. To monitor the status of other boards the software shall request information over the I 2 C bus from the MCUs running those boards. R2.2.1. This should be possible on demand, but should also be performed periodically, so that recent status information can be passed to the ground in the event of communication being initiated. R2.2.2. The data returned shall be information on the ability of the board to perform its intended functions, or information on its current state. Some examples are below: i) The power board should return the currently powered devices. If the communications board has not received a transmission within the expected time, this should be returned as a possible fault with the transceiver. R2.3. The software shall be able to restart the MCU or another device if this can resolve an issue. Safehold mode should be entered if there is a serious problem such as low power availability. R3. The software shall be thoroughly tested to ensure it will perform as expected. R3.1. This shall include testing all aspects of newly added code after it is implemented and intended to be left as the permanent implementation. R3.2. The testing shall also include running through overall scenarios that the CubeSat is expected to encounter, thus ensuring the different software modules are working together as intended.
Low Level Requirements R4. A task scheduling program shall be implemented as the highest-level UC CubeSat software. R4.1. The task scheduling program shall initialise and configure the CubeSat s modules after the satellite is powered on. Initialisation shall include: R4.1.1. Checking the status of the modules in order to determine if there are faults, shutting down modules where required. R4.1.2. Configuring each of the working modules with their default settings. R4.1.3. Preparing the default tasks that are to be run during every flight. R4.1.4. Loading any tasks which have been stored in EEPROM. R4.2. The main duty of the task scheduler shall be to manage and run the tasks which the satellite is to perform. R4.2.1. A task, as seen by the scheduler, shall be some form of object containing the following information: i) An identifier. i iv) A counter representing the number of times that the task is to be run. Some value shall indicate that the task is to repeat indefinitely. The time(s) when the task should be run. A function to be executed in order to actually run the task. R4.2.2. Tasks shall either run once, to completion, before being removed from the pending tasks OR Run on a regular schedule for a certain number of times or until the task is forcibly removed. R4.2.3. Tasks implementation shall be loaded onto the MCU s flash memory before launch, as with any other software. In other words, the CubeSat will only be able to perform tasks programmed before launch. R4.2.4. Control from a ground station shall be made possible by including a mechanism for adding and removing tasks on command. i) Adding a task shall involve filling in the details of a task object so that the scheduler can handle it and run it when required. Removing a task will require the task s identifier to be specified.
R4.2.5. Newly added tasks shall be stored in EEPROM to ensure that they are not lost in the event that the MCU has to reset. R4.2.6. The task scheduler shall operate on a round-robin basis, by polling the set of waiting tasks and running tasks which are due. i) Every time a task is run its counter shall be decremented and the copy of the task stored in EEPROM updated with the new status of the task. i Every time a task is run, the next time it is to be run shall be calculated. Tasks shall be removed from the pending tasks, and EEPROM, by the scheduler once the task s counter reaches zero. R4.3. The scheduler shall have a shutdown routine. R4.3.1. If the watchdog timer underflows, an interrupt shall be generated and the current task removed from the pending tasks before the MCU is reset. The software is assuming that the current task was the cause of the watchdog underflow. R5. A software module for interacting with the temperature sensor shall be implemented. R5.1. The temperature module shall provide an initialisation function for setting the sensor up to a default ready-for-use state. R5.1.1. The initialisation function should be called during the top-level task scheduler initialisation. R5.1.2. The temperature sensor should be initialised for sensible use in the CubeSat. The initialisation code will be easy to change if needed, but examples of sensible initialisation settings to use as a starting point include: i) Enabling one-shot mode for power conservation. Selecting a low ADC resolution to save time and power. R5.2. The temperature module should also provide configuration functions for changing the sensor s settings during flight. R5.2.1. A useful configuration change might include disabling one-shot mode, and enabling an interrupt to occur on a temperature limit, if one-shot readings from the sensor indicate something unusual is occurring and that the situation should be more closely monitored. R5.3. The primary purpose of the temperature sensor shall be to provide temperature information to the MCU. R5.3.1. A function shall be implemented to obtain and return a temperature reading from the sensor.
R5.3.2. The function shall behave appropriately with respect to the sensor s configuration. For example, in one-shot mode the sensor must first be asked to obtain a new temperature reading from the ADC. R6. A software module for interacting with the gyroscope shall be implemented similarly to the temperature sensor module. R6.1. The gyroscope module shall provide an initialisation function for setting up the gyroscope to a default ready-to-use state. R6.1.1. The initialisation function should be called during task scheduler initialisation. R6.1.2. As with the temperature sensor the initialisation should sensibly configure the gyroscope for CubeSat use. This could include: i) Selecting a low data rate for power conservation. Choosing an appropriate full scale in degrees per second based on the anticipated stability of the CubeSat after launch. For example, selecting a full scale setting of 2000dps would likely give an unnecessarily low resolution, as it is unlikely that the CubeSat would approach anywhere close to over five rotations per second. R6.2. The gyroscope module should provide functions for reconfiguring the gyroscope. R6.3. The gyroscope module shall contain a function for obtaining and returning the angular velocities about the x-, y- and z-axes of the sensor. R7. Header files for the communications, sensor and power board software modules shall be written to provide a future interface to these boards. R7.1. These header files shall be lightweight and perhaps consist of a few function prototypes. The purpose of these empty modules is simply to serve as a reminder that the modules will exist and need to be accommodated fully at a later time. R8. A software module shall be implemented for interacting with the EEPROM memory. R8.1. The module shall provide a file system for use on the EEPROM. R8.1.1. The file system shall have a mechanism for maintaining data integrity. This could include for example: i) The use of checksums. The storage of redundant copies of data. R8.2. The module shall provide a function for reading data from EEPROM. R8.2.1. The read function should make appropriate use of the three read modes supported by the EEPROM.
R8.2.2. After reading a number of bytes, the function should ensure that the data being returned is correct by utilising the implemented method of data integrity protection. i) If the data contains an error but it is possible to correct it, the function should do so and return the corrected data. The EEPROM should be updated with the correction also. i If the data contains an error but it cannot be corrected, the space on the EEPROM should be freed and the read function should return an error. Statistics on both the number of corrected errors and uncorrected errors should be preserved. R8.3. The module shall provide a function for writing data to EEPROM. R8.3.1. The write function should make appropriate use of the two write modes supported by the EEPROM. R8.3.2. When writing data to EEPROM the memory module shall store it in accordance with the implemented file system. i) Data shall be formatted correctly for storage. Data integrity protection measures, such as a checksum, shall be calculated and stored along with the data appropriately. R8.3.3. Following writing, the module shall perform a read of the data to ensure it was written correctly. i) The write function shall return an error if the write was not successful. This could indicate permanently damaged memory or simply occur when there is no room to write more data. R8.4. The module shall provide a means to check all EEPROM for data integrity on demand. R8.4.1. As with read operations, correctable errors should be corrected and logged while uncorrectable errors should be logged and the space on the EEPROM freed. R9. The CubeSat software shall contain a module for interfacing with the I 2 C bus. R9.1. The I 2 C interface shall allow sending and receiving of data over the bus. R9.2. The interface shall be utilised by the other software modules which communicate with devices connected by I 2 C bus.