On-Board Computing

(OBC)

The On-Board Computing team concerns itself with the software of the CubeSat, the internal communication between the OBC and other subsystems and the OBC hardware itself. The OBC is the central system that ties other subsystems together and is crucial to the success of the mission of the CubeSat. The OBC will run FreeRTOS, which is a real time operating system used to schedule all of the tasks. It is designed for embedded systems and has a small memory footprint, hence it is ideal for a CubeSat. This is the core of the system and will dictate the behaviour of everything.

As a member of the OBC Subteam, you will be working either on the software or on the OBC hardware, or possibly even on both. If you are working on the software, you will write the system code and program tasks such as retrieving sensor data or the code performing the algorithms requested by other subsystems such as ADCS. You will also have to test these task codes and debug any problems you come across. Some of the tasks will need to be tested on the actual hardware, which you will be setting up yourself. You will be responsible for finding appropriate libraries that can get the job done. You will also help develop and implement different protocols, such as what happens during deployment, after a reboot, when power is critically low and during a software update.

Another software responsibility is to cover all aspects of Fault Detection, Isolation, and Recovery, such as implementing a system wide and also task specific watchdogs, input validation, power cycling and bit-flip correction. The OBC team uses git with GitHub as a version control system. We work with pull requests and code reviews to ensure that all code is up to standard. The OBC will communicate with all other components through SPI connections. The code for the OBC will be written in C for FreeRTOS and C++ for other parts. PlatformIO will be used to handle dependency management and code compilation.

Engineering hardware for space use has a set of defining challenges. While in space, any electronic components are subject to radiation. This includes α, β, γ and heavy ion nuclei. The most important effects, and most noticeable, are the ones suffered by CMOS devices. Outcomes of radiation can be classified as displacement damage (exposure for longer periods of time causing changes in the semiconductor structure) or the more important single effect events. The latter can either cause soft errors (latching up a transistors, flipping a memory bit) or hard errors which consist of the permanent degradation of a MOSFET. When it comes to MCUs, soft errors can usually be handled by good software & hardware practices (redundancy or watchdogs), while hard errors can be fatal and the type of MCU should be carefully chosen in regards to reliability.

When choosing a hardware solution for the OBC there is a trade-off between reliability and cost. There are plenty of Cubesat OBC system that can be bought directly and have a certain degree of space qualification. This main issue with these solutions is the rather steep cost. Furthermore, another solution is to use commercial MCUs, which are usually used in either consumer products or the automotive industry. While the latter option may be more cheaper (by a few powers of 10), it does posses some issues in regards to how long it can realistically last.

Within Aster, a custom OBC system will be designed based around an automotive grade MCU which has been previously used in a space mission without issue. This design decision is mainly

 

about striking the previously mentioned balance between cost and reliability. Tasks in regards to this part of the OBC design are as follows:

 

 

 

 

Tasks & Responsibilities

SOFTWARE:

(a)   Coding system code and tasks in C/C++.

(b)   Finding appropriate libraries, contribute to the standardization of libraries within the OBC Subteam.

(c)   Design Fault Detection, Isolation, and Recovery functionality.

(d)   Test your code both Software-in-the-Loop and Hardware-in-the-Loop, debug your code if any encountered.

HARDWARE:

a)     Researching the MCU data-sheet.

b)     Developing a minimal setup circuit for the MCU.

c)     Interfacing with any external memory that may require to be added.

d)     Developing a full schematic of the OBC system.

e)     PCB design.

f)      PCB prototyping & assembly.

g)     Testing and evaluation.

Roles

Electrical Engineers, Computer Scientists

OBC Hardware Engineer Requirements

Knowledge and skills required prior to joining
  1. Ability to plan designs.
  2. Knowledge of PCB design.
  3. Knowledge of the existence of at least these different types of protocols: I2C, SPI, UART, CAN.
  4. Knowledge of the advantages/disadvantages of the protocols in a).
  5. Knowledge about ADCs/DACs and an understanding of the characteristic parameters such as: resolution and dynamic range. Knowledge about ADCs is more important.
  6. Knowledge about propagation time and what effects does it have on PCB traces (you need traces of equal length, that’s why the squiggly lines on mother boards for example. )
  7. Knowledge of what clock frequency & instructions per second are.
  8. Knowledge of how you can usually choose the clock frequency when designing a board with an MCU (generally you choose the frequency of the crystal that you connect to the MCU).

OBC Software Engineer Requirements

Knowledge and skills required prior to joining
  1. Basic programming skills and knowledge (2IP90).
  2. Working with GIT, GitHub.
Knowledge and skills you will learn after joining
  1. Working with platformIO.
  2. Working with FreeRTOS.
  3. Linux basics.
  4. Operating a command line.
  5. Programming in C.
  6. Compiling, building and uploading code to a micro controller.
  7. Understanding of task schedulers.
  8. Making and using SPI schedulers.
  9. Knowledge of embedded systems and basics of connecting components.
  10. Knowing how to test and debug code.
  11. Space standards for software.
  12. Radiation protection.
  13. Development cycle in a big team.