Open Source RTOS Implementation for On-Board

Computer (OBC) in STUDSAT-2

Bheema Rajulu Sankar Dasiga Naveen R. Iyer
Project STUDSAT Project STUDSAT Project STUDSAT
Nitte Meenakshi Institute of Tech. Nitte Meenakshi Institute of Tech. M. S. Ramaiah Institute of Tech.
Bangalore - 560064, India Bangalore - 560064, India Bangalore - 560054, India
bheemarajulu90@gmail.com dasiga@hotmail.com iyernaveenr@gmail.com

Abstract— STUDSAT-1 is the first pico-satellite developed in 5 I NITIALIZATION OF OBC & D EVICE S TARTUP . 8
India by the undergraduate students from seven engineer- 6 S OFTWARE T ESTING & S IMULATION . . . . . . . . . . . 8
ing colleges across South India. After the successful launch
of STUDSAT-1 on 12th July, 2010, the team is develop- 7 C ONCLUSION & S COPE FOR F UTURE . . . . . . . . . . . 11
ing STUDSAT-2 which is India’s first twin satellite mission. ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
STUDSAT-2 is undertaken by the undergraduate students from
seven engineering colleges from the State of Karnataka, India. R EFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
STUDSAT-2 consists of two Nano Satellites each having the B IOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
dimension of 30 x 30 x 20 cm cube and weighing less than 10 kg.
Each satellite has two payloads, one is the CMOS Camera with
a resolution of 80 m and other is the ISL facility. The satellites
are in along-the-track constellation architecture with the Master 1. I NTRODUCTION
Satellite sending position data of the first image location on orbit Real-time systems are omnipresent in almost every applica-
and velocity of master satellite from GPS module to the Slave tion. Some of the examples include industrial plant con-
satellite via ISL for improving temporal resolution. On-board
computer is the brain of a satellite whose operating system is trol, missile guidance, computer on-board an aircraft, path
designed to operate in resource constrained environments and is planning task of a robot, etc. Nowadays all systems are
often tailored to the specific needs of its host system, while a real designed for real-time response to stimuli. A real-time system
time operating system ensures that interrupts and other time is subject to operational deadlines to respond to events.
critical tasks are processed when required. In order to maximize
the accessibility the operating system must be inexpensive, and A Real-time operating system (RTOS) is an operating system
readily available, which demands an open-source OS. Imple- which is used to write good embedded software for com-
mentation of a Real-Time Operating System (RTOS) provides plex systems in order to ensure the application meets its
several priority levels for tasks execution. FreeRTOS fulfills the processing deadlines. Typically, deeply embedded real-time
requirements by having real-time capabilities, full availability
of the source code, functional development environment, cross- applications include a mix of both hard and soft real-time
platform support and community support. After an extensive requirements. Soft real-time requirements are those that state
literature survey, the ARM microcontroller with low power a time deadline, which when breached, does not render the
and high performance capability, STM32 ARM Cortex-M4 with system useless whereas hard real-time requirements are those
168 MHz CPU having 210 DMIPS is chosen as the main con- that state a time deadline, which when breached, results in
troller that supports FreeRTOS that can run on ARM Cortex- absolute system failure.
M cores. The On-Board Computer controls and coordinates
the tasks of all other subsystems of the satellite. The different In this paper we elucidate the technical justification for using
tasks executed by these subsystems have multi-threading and FreeRTOS in STUDSAT-2. We present the implementation
preemptive multitasking characteristics. A real-time operating
system, FreeRTOS, uses advanced task scheduling techniques of FreeRTOS on STM32Cortex M4 controller to increase the
and a preemptive kernel, which allows multi-threading of pro- functional integration and overall performance of the small
cesses to occur. This paper presents the technical justication for satellite. Utilization of FreeRTOS simplifies software devel-
using FreeRTOS in STUDSAT-2. It presents implementation of opment, enables code modularity, and results in maintainable
FreeRTOS on STM32Cortex M4 controller which will increase and expandable high-performance that will reduce the effort
the functional integration and performance of small satellite required to develop software for STUDSAT-2A/2B Mission.
that simplifies software development, enables code modularity,
and results in maintainable and expandable high-performance The rest of the paper is organized as follows: Section 2
that will reduce the effort required to develop software for reviews the general OBC system design and its objectives,
STUDSAT-2A/2B Mission.
requirements and functions. Section 3 explains the OBCs
Index Terms- STUDSAT-2, Satellite, RTOS, Inter-Satellite Link hardware selection which includes the OBC Bus and Mem-
(ISL), Twin Satellite Mission, OnBoard Computer (OBC). ory. Section 4 discusses the OBCs software which includes
the significance of a RTOS for STUDSAT-2 and the imple-
mentation of FreeRTOS for the OBC. Section 5 describes the
initialization of the OBC system with the help of flow charts
TABLE OF C ONTENTS which are self - explanatory. Section 6 is the concluding note
which also discusses the scope for future.
1 I NTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 O N -B OARD C OMPUTER . . . . . . . . . . . . . . . . . . . . . . . . . 2 Real-time software architecture and its implementation on
3 H ARDWARE S ELECTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 a small satellite platform were explored and also, its pros
and cons were discussed in [1]. Utilization of Atmel
4 S OFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 AT91SAM7SE-256 controller as the OBC for Nano/Pico
satellite applications was studied [2]. Implementation of
978-1-4799-1622-1/14/$31.00 2014
c IEEE. FreeRTOS on S3C44B0 processor was studied [3]. The con-
1
 Figure 1. Overall OBC System.

cept of hierarchical scheduling using FreeRTOS was studied STUDSAT OBC subsystem
[4]. The implementation of Stream Control Transmission
Protocol (SCTP) in RTEMS, an open source RTOS, for data • To perform the house keeping functions which includes
communication over satellite networks was proposed in [5]. logging the telemetry data in the memory periodically
Design of a system for handling high speed image data from • To detect and correct faults
satellite and advanced image compression techniques was
explained in [6]. A novel algorithm for GPS data acquisition, • To implement the higher layers of the communication
data processing and implementation for robot navigation was protocol
proposed in [7]. • To interface with the electrical and ground support equip-
ment, the launcher, the ground segment, with the other two
spacecraft in the constellation for telemetry possibly received
2. O N -B OARD C OMPUTER over the Inter-Spacecraft Links
The On Board Computer (OBC) for STUDSAT-2 is ARM Requirements
based Cortex- M4 microcontroller with DSP and FPU in-
structions combined to 168 MHz performance. The perfor- OBC requirements are derived from mission requirements
mance and the features of the chosen processor are based and are defined at system level requirements. OBC System
on functional, operational and interface requirements & pro- requirements can be subdivided into three different groups:
tocols. The overall system architecture and requirements • Functional Requirements: Tasks, subsystem control, task
of the subsystems is accomplished by the open-source real- scheduling, data processing, communication subsystem and
time operating system (RTOS) which support various types of component level, data storage, etc.
peripheral interfaces, telemetry storage and data processing.
• Operational Requirements: Operations modes (states),
The block diagram shown in Figure 1 illustrates the various power modes, autonomy, failure detection isolation and re-
peripherals used for the project and the general system de- covery (FDIR), etc.)
sign. The various peripherals for the C&DH system consist of • Interface Requirements and protocols: Compatibility with
a set of memories, a microcontroller supervisor IC and tem- hardware and software interfaces, standards and protocols.
perature sensors at various locations of the satellite. A Read-
/Write Non-Volatile Radiation Resistant Memory is used for Functions of OBC
storing the telemetry data. And for storing the images from
the CMOS image sensor a fast and lard read/write memory The tasks that are performed by the OBC can be listed as
is used. The controller will be supervised by a watchdog follows:
timer to catch runaway programs by resetting the controller. • Stabilize the satellite in the orbit
The I/O Board provides serial peripheral interface (SPI), I2C,
USART, ADC etc. to communicate with sub-modules of • Establish a communication link with ground station
other sub-systems.
• Monitor the health of the satellite
Objectives • To capture images of the earth
The Command and Data Handling (C&DH) System is the • To send the image to the ground station
brain of the satellite. Its functions are:
• To communicate with the other satellite through Inter-
• To develop a working hardware prototype of the Satellite Link

2
 3. H ARDWARE S ELECTION Electronic Power Board (I2C)—This board handles the volt-
ARM CORTEX-M4F-based STM32F407VGT6 is used as age regulation for the different subsystems.
main processor for device monitoring, status maintenance Payload CMOS camera (DCMI)— Provided 10 bit parallel
and interfacing with other peripherals. The Cortex-M4 pro- data bus with SDA and SCL data bus for storing image and
cessor has a wide variety of highly efficient signal processing
features applicable to digital signal control markets and fea- reading image data from payload memory.
tures necessary for the OBC. More information of STM32F4 Inter-satellite Board (USART)— This board is designed to
Discovery board can be inferred from the data sheet.
mount the ISL S-Band transceivers on and connects to the
computer via a USART data link.
Figure 2 shows an example of a figure spanning a single
column.
Memory
General Requirements—The general requirements of both the
program and data memories are as follows:
• Low power consumption.
• Non-volatile, so that data is not lost in the event of a power
failure.
• Serial bus interface to minimize space of bus on PCB and
failure rate.
• The maximum number of write cycles expected is assumed
to about 11,000.
This is based on the satellite passing the NASTRAC ground
station six times a day, for the mission lifetime of five
years, with each pass initiating a write cycle. Obviously, the
memory should be able to write/erase more times than this.
Figure 2. STM32F4DISCOVERY.
Program Memory Requirements— The microcontroller has
its own non-volatile program memory. However, on most
devices this is small limiting the size of the program, and
The project utilizes STM32F4 Discovery board as its on- thus range of tasks, the microcontroller can run. In order
board computer. A snapshot of the board is as shown in the to increase the flexibility of the mission, external program
above figure. memory will be used. There is no upper limit to the required
program memory size. During the mission, it is expected to
The OBC hardware has been designed with all possible have the ability to upload new programs to the spacecraft.
interfaces and control circuitry with STM32F4 Discovery Thus it is essential to use fast writing, non-volatile secure
board. memory for the external program memory. Three types
memories: EEPROM, Flash, and SRAM chosen because this
OBC Bus computer will operate in atmosphere where radiation some-
One Wire Interface Board—This board allows the onboard times leads to bit-flips in temporary memory (Flash), which
computer to act as the 1-wire bus master to control the devices results in unpredictable software errors. A programmable
connected to the bus. This board also contains a mounted safety timer, called a watchdog timer, resets the processor if
thermal sensor for monitoring the temperature of the box bit-flip occurs, and the processor reloads the boot-software
containing the onboard computer as well as several additional from EEPROM (24LC02 (EEPROM)) to Flash. It is essential
circuit boards. that the boot-software always works correctly, and therefore
must be stored in a memory, where bit-flips do not occur
Magnetic Coil Control Board—This board provides the on- [8]. The Flash memory is used to store the main operating
board computer with a GPIO connection to control the mag- software and other subroutines, and a copy of this software
netic coils for attitude adjustments. will also be stored in EEPROM (permanent memory). The
512K SRAM temporary memory will be used to run the
Reaction Wheels Control Board (PWM)—This board provides software and subroutines and also as a place to store the
access for the data bus to the heaters and reaction wheels. measured values from the payload sensors.

Magnetometer Interface Board (USART)— This board pro- Data Memory Requirements (AT45DB161D)—For the initial
vides the serial conversion of magnetic field in xyz coordi- payload, 500 Kbytes is needed to store one photo taken by
nates to allow the onboard computer to take readings over the the camera. The transmitter transmits at 9.6Kbits/s, and in the
data bus from the magnetometer. STUDSAT-2 low orbit, the maximum time it will be able to
transmit data to the ground station will be around ten minutes.
GPS Interface Board (USART)— This board converts the This means the maximum data that can be transmitted in one
LVTTL signal from the GPS unit to an RS-232 signal for pass is 720 Kbytes. However, in practice, it will typically be
connection to the onboard computer. about half of this. As one photo takes 500 Kbytes that means
that in one pass over the ground station, either one photo of
Communication (SPI/USART)—The communication system around 500 Kbytes or 500 Kbytes of telemetry data can be
with transmitter and receiver for the radio frequency commu- transmitted, but not at the same time. Thus, some orbits will
nication link and provides an SPI data link to the onboard store only a photo, while other orbits will store only telemetry
computer. data, at the discretion of the ground station operator [8].

3
 Figure 3. Peripheral Interfacing.

4. S OFTWARE thereby saving time in rewriting huge chunks of code again

Figure 3 shows the STM32 M4 interfaced with various phe- and again.Greater modularity and less module interdependen-
ripherals like Camera, Magnetometer, Gyros, ISL Module cies facilitates code reuse across projects [10].
2.4GHz, Power System and Beacon Module for checking the • Etcetera
overall software functionality (using FreeRTOS as operating
system). Above are just few of the points which justify the use of
RTOS for the project. A thorough study of the capabilities
Requirement of Real-Time Operating System of a RTOS led to more such advantages of using a RTOS for
the project.
When STUDSAT-1 was developed the idea of utilizing a real-
time operating system did not strike us. However, after its In order to implement all the functions required by the OBC
launch we did come to realize how utilization of a RTOS a real-time operating system is used. A real time operating
could have significantly reduced the complexity of the code system (RTOS) is basically a task-scheduling program that
and saved a lot of time. responds to events such as interrupts in real time, i.e. a few
milliseconds at most. A good RTOS will hide the complexity
Exploring the prospects of using a RTOS for Project of the underlying hardware from the tasks running, making
STUDSAT-2 led to the following advantages: tasks easier to develop.
• Code Complexity: Utilization of RTOS leads to a signif-
icant reduction of the complexity of the code. By allowing An RTOS provides the following services to the tasks run-
the project to be decomposed into independent threads or ning:
processes, and using OS services such as message queues, • Decides which task to run next.
mutexes, semaphores, event flags, etc. to communicate and
synchronize, the project becomes more manageable. • Ensures that a task does not take up resources for too long,
• Time critical nature of the system: As discussed in the delaying other tasks.
introduction section of this paper, the need to meet hard real- • Handles hardware interrupts for tasks, and calls the appro-
time deadlines is another major issue where RTOS could help. priate task that is waiting for the interrupt.
With a priority-based pre-emptive RTOS, the scheduler can • Passes messages between tasks so they can communicate
help ensure deadlines are met. with each other.
• Testing: Testing of individual functions becomes easier
when these functions are split into a number of tasks so An important feature of the RTOS is multitasking. This
that each task can be separately tested and verified. Task allows several tasks to run as though they are running in
interfaces can be exercised without the need to add instru- parallel. Obviously this is impossible on most processors,
mentation that may have changed the behaviour of the module and what actually happens is the tasks are allowed to run for
under test [10]. short periods before switching to the next task. All important
• Code reuse: Tasks facilitate code resue within a project registers and data are saved between each task switch so
4
that the task may resume in exactly the same state it was The section below discribes why we chose FreeRTOS over
before the switch next time it is called. More details on other RTOSes.
how multitasking and other such features can be implemented
using FreeRTOS is discussed in the sections below. Why FreeRTOS?
Functionally, most small RTOSes do basically the same thing.
Comparison & Feasibility Studies So differentiation comes from non-functional attributes like
One of the major requirements of Project STUDSAT-2 was an quality control, IP infringement protection, design choices (at
open-source RTOS (mainly for economic feasibility). Also, which point do you trade off size, speed, portability, etc.),
when an open-source RTOS could do the job and share the ecosystem, user base, if there are options for commercial
same capabilities as that of a non-open-source RTOS, then support should any legal team ever need it, etc.
there is no need to incur additional costs. Following are
the major aspects of a RTOS we looked at for carrying out A good comparison of various open-source RTOS for STM32
comparison studies: and Cortex-M3 MCUs (which is applicable for Cortex-M4
MCUs like STM32F407VGT6 also) can be found in [9].
• Features: Basic features of a RTOS include tasks, task
scheduling, queues, semaphores, memory management, etc. Features—FreeRTOS has all the necessary features a RTOS
Although there are several more features, the said features generally has and is therefore suitable for the project. All of
constitute a minimum requirement. the features are also easy to implement.
• Size: Memory constraint is a big issue while considering
using a RTOS. The microcontroller chosen for the project Size—This depends on the compiler, architecture and RTOS
(STM32F4VGT6) required a small RTOS. kernel configuration. FreeRTOS is a relatively small applica-
tion. The minimum core of FreeRTOS is only three source
• Performance: One of the major requirements include that (.c) files and a handful of header files, totalling just under
the RTOS take minimal time to boot. Memory allocation 9000 lines of code, including comments and blank lines.
mechanism gives a clearer picture of the performance of the FreeRTOS running on an AVR has a footprint (the amount of
RTOS in the chosen hardware. ROM used) of approximately 4.4 kilobytes. RTLinux ( RTOS
• Documentation & Support: Any RTOS has to have good microkernel that runs the entire Linux operating system ), on
documentation and technical support so that critical issues the other hand, is relatively scalable. The Linux kernel can
can be easily and professionally addressed. be stripped of functionality which is not needed. But even
given that, the footprint is generally measured in megabytes
• Cost & Licensing Model: What kind of license does the (or in some rare cases hundreds of kilobytes). Similarly,
RTOS offer? Is it open-source? The definition of open- QNX is another RTOS which seemed viable but is a ”heavier”
source may not be uniform across all vendors of RTOS. It is RTOS compared to FreeRTOS. A typical application takes
important to check what features are available as open source, 5 to 10 kilobytes of ROM space. STM32F407VGT6 has
that is, how much of the RTOS is truly open-source. These upto 1 Mbyte of flash memory and upto 192+4 Kbyte of
are few of the questions that need to be answered. SRAM including 64 Kbyte of CCM (core coupled memory)
data RAM which makes it suitable for any FreeRTOS-based
Since there are several RTOSes in the market which are application. More details on the amount of RAM and ROM
open source it may not be possible to test each and every utilization of FreeRTOS can be found in [11].
available open-source RTOS on the hardware due to time
constraints. However, a comparison study is really important Performance— Time taken for booting is one of the major
for the project. issues that is to be taken into consideration while judging
the performance of any RTOS. A detailed description of the
Comparison studies require brainstorming sessions. The first each of the processes that are executed while booting and
step for comparison studies would be to lookup for the list its timing in FreeRTOS can be found in [11]. Again, the
of available open-source RTOSes. And then look up for performance depends on how efficiently the code is written
comparison studies already performed and made available and the hardware on which the RTOS is used. Although
online. Based on the online reviews of several open-source few of the small open-source RTOSes (like ChibiOS/RT)
RTOSes a select few can be rounded off. Then theoretical may closely compete with FreeRTOS in performance, other
studies over each of these RTOSes could lead to rounding off aspects like documentation & support, features, etc. make
to an even smaller number of RTOSes which makes it viable FreeRTOS a more attractive choice.
to test each of these on the hardware.
Documentation & Support—FreeRTOS is a truly cross plat-
Nevertheless, it is upto the user to test and verify each of the form defacto standard. It supports 34 architectures (that
open source RTOSes available for a specific application. is, architectures, not devices) and 18 tool chains till date.
Even the time investment required can be lower than with
Keeping the above points in mind, we finalised on FreeRTOS. commercial solutions. Availability of documentation for
FreeRTOS is a good choice if the user is looking for a small several microcontroller architectures, swift technical support
OS (for microcontroller-based applications). Having tested and massive user base makes FreeRTOS a good choice and
quite a few like ChibiOS/RT (which lacked good documenta- reins it supreme when compared to ChibiOS/RT. Also, since
tion), uCOS-II (which lacked a robust multitasking feature FreeRTOS has a massive user base, the solutions to most of
(set by assigning same priority to several tasks in FreeR- the common technical problems are available readily online.
TOS)), etc., we were convinced that FreeRTOS provides us
with all that is required for our project. Cost & Licensing—License details of FreeRTOS can be found
in [12]. FreeRTOS is ’moderated open source’, which means
RTOSes keep getting updated with the latest features and that, when FreeRTOS is downloaded, the code is truly free
thereby, there may or may not be a best choice for the and open source to the user. However, contributions back
application. to FreeRTOS are made publicly available while simultane-

5
ously kept separate from the ’official’ code. This allows the Table 1. Task Interface
FreeRTOS project to strictly control the quality of the code,
ensuring a robust product. It also provides assurance to end Task Task Name Timing
users that their open source choice has no unintentional or Task Manager Continuous
unknown IP contamination. The business model allows users Camera tCamera Periodic Update
the freedom to access, use, evaluate, distribute, etc. the code, GPS tGPS Periodic Update
completely free of charge. However, they have the security of Attitude tAttDetr Periodic
knowing there is a third party infrastructure there should they Determination
ever need commercial licensing or support contracts. Inter-Satellite tISL Periodic
Communication
QNX RTOS is not open-source and therefore can be used only STUDSAT tBeacon Periodic
for a limited time period. The project duration is long and Beacon
therefore limited time period softwares are not feasible for Power tPower Periodic
the project. Micrium’s uCOS is another example of a RTOS Mode Manager tModeMgr Periodic
which competes closely with FreeRTOS. Although uCOS is Mission Timeline tMTM Aperiodic
known for its high reliability (even more than FreeRTOS as Manager
it has been used in several space research projects), it is not Uplink tUplink Aperiodic
open-source. Communication
Downlink tDownlink Aperiodic
Another speciality of FreeRTOS includes code quality, which Communication
can be quantified in a number of ways. Independent analysis
of the code has proven its robustness and quality. FreeRTOS
is professional grade and robust, yet still free. Users can have
the confidence in knowing that SafeRTOS, which originated task and execution time. Each task will have a message
from FreeRTOS, has been independently certified by TUV queue assigned to it and will block on the message queue,
SUD for use in safety critical systems. with a timeout equal to its period. If the task is aperiodic, it
will have an infinite timeout. Using this mechanism, there
These are all the points where FreeRTOS scores extremely are two ways to activate a sleeping task: send a message
highly. The design choice is subjective of course, and differ- to its message queue, which will be processed immediately
ent solutions are best suited to different applications, so there (as long as another, higher priority task isnt already active)
is no ”best” and no ”right or wrong” for that category. or wait for the timeout period to expire (assuming the task
is periodic). The task manager is the FreeRTOS real-time
FreeRTOS has become the de facto standard for microcon- operating system (RTOS). The task manager is responsible
trollers, and comes top in class in the EE times embedded for context switching between active tasks, based on their
market surveys for most used and most considered for next priority.
project, shows independently that the model works extremely • Camera (tCamera) : This task is responsible for capturing
well. image and serve buffer to compress on board image using
JPEG2000 algorithm. Following threads run in the Camera
Implementation of FreeRTOS Task (tCamera):
FreeRTOS software download consists of demo, source and
license files. Demo file consists of example projects for Cam_GetStatus();
Cam_set_mode();
a variety of boards. For OBC either one of these sample Cam_TakePicture();
projects can be modified or a project can be created from Cam_Jpeg_Compress();
the scratch using a project management software. Instead Cam_Transmit_Image_to_Buffer();
of modifying an existing demo (which makes use of IAR Cam_Rec_Image_from_Buffer();
Embedded Workbench software) we chose to create a project Cam_LowPower();
from the scratch as it allows us to use any software we Cam_PowerOK();
choose to integrate with FreeRTOS. We chose uVision Keil Cam_telemetry.();
for the OBC. Creating a project from the scratch allows us Cam_PictureData();
to organize/group all the files and also allows us to add or
delete files as per our requirement. On the other hand a • Intersatellite Link (tISL): This task is responsible for com-
pre-configured demo includes even those files which are not munication with the other satellite through Inter-Satellite
required for the OBC. Link (2.4Ghz) and establish communication between two
satellites. The communication would be master salve con-
Firstly, we listed out the tasks required by the OBC. Table 1 figuration. OBC will determine when the data needs to be
illustrates the list of tasks devised for the system [16]. There gathered for the telemetry buffer and when to communicate
are three types of tasks based on the timing in this software with the slave satellite. Following Threads run in Intersatel-
architecture [16]. lite Link (tISL):
• Periodic Task: This task must take action on a regular
basis. ISL_GetStatus();
ISL_Get_TelemBuffer();
• Periodic Update Task: This task will collect data and place ISL_Get_IMIBuffer();
it in a global memory area for use by other tasks on regular ISL_Get_ImageData();
basis. ISL_Send_Cross Send();
• Aperiodic Task: This task will run as a result of some ISL_GetResponse();
external command respond, such as from the ground. ISL_Get_Cross_GPS();
ISL_End_Link();
The tasks are assigned a priority based on criticality of the
6
Figure 4. Flowchart illustrating initialization of OBC and device startup.

7
• Communication Tasks: Communication tasks can be clas- • Mission Timeline Manager (tMTM): This task is responsi-
sified as Uplink Task and Downlink Task. These tasks ble for managing the timeline for future events [16].
are responsible for establishing a communication link with
ground station for both uplink and downlink communication.
Uplink Communication (tUplink): This task is responsible 5. I NITIALIZATION OF OBC & D EVICE
for receiving commands from ground station and parsing the
data to execute suitable actions in the satellite. S TARTUP
Downlink Communication (tDownlink): This task is respon- The data ow shown in gure 4 describes the initialization of
sible for sending telemetry data and payload data that is re- OBC and device startup required to send telemetry data from
quested by ground station. The message should be formatted the sensors to communication module. All the communica-
in AX.25 protocol for decoding message in ground station. tion between tasks occur using message queues. The ight
The OBC Comm Downlink performs the task of forming software is implemented with FreeRTOS for operation of
packets of the information to be sent. command and data handling.
OBC_Comm_Downlink(): OBC_Uplink(): Satellite Modes of Operation
Com_GetStatus Com_RxNewSoftware
Com_PictureData Com_RxSyncData The ight software is implemented with three distinct space-
Com_LOGData Com_RxCommand craft modes ->Safe Mode ->Ideal Mode->Normal Mode.
Com_TxSyncData Com_RxDtmf_Command
Com_LowPower Com_RxSetDebugOut Apart from the normal operation of the satellite the following
Com_PowerOK Com_RxTransmit_Image operating modes are defined for the extended convenience &
Com_RxNewFlightPlan Com_RxNewAcsParam
Com_RxKeplerElements Com_COMStatus optimum functioning of the satellite and for power saving
Com_RxTimeSync functions.

Start-up Mode— This will be a one-time operational mode

• Beacon Task (tBeacon): The satellite will send beacon which will be active only after a few hours after the launch
signals to the ground station. The Beacon signal contains of the Satellite into the orbit.
information like the satellite ID. This information is in the
form of packets, which are formed according to the AX.25 Safe Mode (Low power) —In this mode only the essential
protocol. modules are powered ON and only the Housekeeping &
• Power (tPower): This task is responsible for handling all Maintenance functions are done in this mode.
power related tasks on the OBC. These tasks include software
overcurrent protection and power switch control with data Emergency Mode—The satellite is put under emergency mode
flow control command for Regulator Current and Voltage bus. during Extreme operating conditions caused due to either
Following threads run in Power (tPower): partial module failure or low power availability, In this mode
only the Power system and the Beacon is kept on and rest of
Power_GetStatus(); the modules are suspended until the errors are rectified or the
Power_SetBootMode(); Power_SystemReset (); normal operating conditions are restored.
Power_TurnOnSubsytem();
Power_TurnOffSubsytem (); Communication Priority Mode— In this mode the priority
Power_reset_theDog(); of operation is given to the Communication modules, all
Power_BasicBeaconOff(); other modules are put under minimal operative mode so that
Power_telemetry(); maximum power is provided to the Communication module
Power_ErrorShutDown(); for the duration in which the satellite happens to be in the
Power_PCUPowerOK(); Power_PCULowPower();
Cone of Window.

• Attitude Determination (tAttDetr): This task is responsible Payload Priority Mode—In this mode maximum CPU usage
for updating Keplerian elements, performing mathematical and power is given to the payload requirements to ensure
calculations and provide actuation and determination. Data smooth and uninterrupted payload mission. The satellite will
acquisition of magnetometer XYZ position, gyro XYZ po- operate in this mode during the exclusive payload operation.
sition, sun vector, orbit propagation and error detection.
Following Threads run in Attitude Determination (tAttDetr): Debug Mode—This mode is mostly activated along with the
Emergency mode or Safe mode. This mode is activated dur-
ADCS_GetStatus ing the maintenance operation, where the Runtime software
ADCS_Telemetry errors can be debugged by up-command.
ADCS_UpdateKeplerElements
ADCS_navigation_guidance
ADCS_SunData
ADCS_SwitchADCSMode 6. S OFTWARE T ESTING & S IMULATION
ADCS_Lowpower The softwares used for OBC are as follows:
ADCS_PowerOk
ADCS_TimeSynchronized • RTOS: The OBC makes use of FreeRTOS. It is GPL
Licensed operating system that targets microcontroller. It
supports various degrees of multitasking, ranging from a
• Mode Manager (tModeMng): This task is responsible for preemptive scheduler & co-operative multitasking to co-
maintaining the mode state of the satellite. The mode man- routines.
ager will determine the state based the request and conditions
received from the OBC which are associated with different • Compiler and Debugger: The Vision IDE from Keil com-
subsystems like EPS, COMM, ADCS and thermal systems bines project management, make facilities, source code edit-
[16]. ing, program debugging, and complete simulation in one
8
powerful environment which makes it suitable for the project. Following is a code snippet which shows multitasking using
The ST-LINK/V2 tool can be easily used for JTAG and SWD FreeRTOS.
interface debugging and programming.
void tUplink (void *pvParameters)
{
Testing /* Variable declarations and other
initializations*/
A code was written and executed on STM32F4DISCOVERY const char *pcTaskName = \r\ntUlink
board to test few task management features of FreeRTOS. task running\r\n;
The total flash footprint came upto approximately 11 Kbyte uint8_t i=0;
which includes FreeRTOS code, application code and library /* .*/
code. Few code snippets are listed below that show different
task management features of FreeRTOS. for( ;; ){
/* Print out the name of this
The syntax for creating a task using FreeRTOS is shown task. */
below. Detailed explanation can be referred from text books USART_puts(USART1, pcTaskName);
/* tUplink code */
on FreeRTOS. }
}
portBASE_TYPE xTaskCreate( pdTASK_CODE void tDownlink (void *pvParameters)
pvTaskCode, {
const signed char * const pcName, /* Variable declarations and other
unsigned short usStackDepth, initializations*/
void *pvParameters, const char *pcTaskName = \r\ntDlink
unsigned portBASE_TYPE uxPriority, task running\r\n;
xTaskHandle *pxCreatedTask uint8_t i=0;
); /* .*/
for( ;; ){
Following is a code snippet which shows simple task creation /* Print out the name of this
using FreeRTOS. task. */
USART_puts(USART1, pcTaskName);
/* tDownlink code */
void emptyTask(void *pvParameters) }
{ }
char *pcTaskName = "Empty Task is
running\n"; //To display which int main( void )
task is running {
for(;;) //Infinite loop init_USART1(9600); // initialize
{ USART1 @ 9600 baud
USART_puts(USART1, pcTaskName); USART_puts(USART1, "USART
//For printing on a terminal Initialization complete !\r\n");
software through USART1
Delay(); //Task Creation
} xTaskCreate( tUplink, "tUplink",
} configMINIMAL_STACK_SIZE, NULL, 1,
int main( void ) &hUplink ); //Note that the
{ priority for both the tasks are
init_USART1(9600); // initialize set the same (whisi is 1)
USART1 @ 9600 baud xTaskCreate( tDownlink, "tDownlink",
USART_puts(USART1, "USART configMINIMAL_STACK_SIZE, NULL, 1,
Initialization complete !\r\n"); &hDownlink ); //This means that on
execution, both tasks will be
//Task Creation running alternately which makes it
xTaskCreate(emptyTask, ( signed char * look like its running
) "EmptyTask", 240, NULL, simultaneously
EmptyTaskPriority, NULL); //Similarly, any number of tasks can
be set the same priority for
//Execute the task multitasking
vTaskStartScheduler();// This should
never return. //Execute the task
// Will only get here if there was vTaskStartScheduler(); // This should
insufficient memory to create never return.
// the idle task.
return 0; // Will only get here if there was
} insufficient memory to create
// the idle task.
return 0;
The output looks like the following: }

USART Initialization complete !

Empty Task is running The output looks like the following:
Empty Task is running
Empty Task is running USART Initialization complete !
tUlink task running

9
tDlink task running // Will only get here if there was
tUlink task running insufficient memory to create
tDlink task running // the idle task.
tUlink task running return 0;
tDlink task running }

Following is a code snippet which shows dynamic pri- The output looks like the following:
ority scheduling using FreeRTOS. An initial priority for
the task is assigned by the uxPriority parameter of the USART Initialization complete !
xTaskCreate() API function. The priority can be changed sampleTask1 is running
by using the vTaskPrioritySet() API function. The maxi- About to raise the sampleTask2 priority...
mum number of priorities can be set by defining a compile sampleTask2 is running
About to lower the sampleTask2 priority...
time configuration constant in the configMAX PRIORITIES sampleTask1 is running
within FreeRTOSConfig.h header file. Higher the config- About to raise the sampleTask2 priority...
MAX PRIORITIES value the more RAM the kernel will sampleTask2 is running
consume. About to lower the sampleTask2 priority...

void sampleTask1(void *pvParameters)

{
const char *pcTaskName = "sampleTask1 Following is a code snippet which shows task periodicity
is running\n"; using FreeRTOS.
unsigned portBASE_TYPE uxPriority;
uxPriority = uxTaskPriorityGet(NULL); void emptyTask(void *pvParameters)
for(;;) { {
Delay(); char *pcTaskName = "Empty Task is
USART_puts(USART1, pcTaskName); running\n"; //To display which
USART_puts(USART1, "About to task is running
raise the sampleTask2 for(;;) {
priority...\n"); USART_puts(USART1, pcTaskName);
vTaskPrioritySet(xTask2Handle, //For printing on a terminal
(uxPriority+1)); software through USART1
} Delay();
} }
}
void sampleTask2(void *pvParameters)
{ void periodicTask (void *pvParameters)
const char *pcTaskName = "sampleTask2 {
is running\n"; const char *pcTaskName = "Periodic
unsigned portBASE_TYPE uxPriority; Task is running\n";
uxPriority = uxTaskPriorityGet(NULL); portTickType xLastWakeTime;
for(;;) { xLastWakeTime = xTaskGetTickCount();
Delay();
USART_puts(USART1, pcTaskName); //Lets say the mode of execution is as
USART_puts(USART1, "About to per the number of executions, that
lower the sampleTask2 is, after a said number of
priority...\n"); executions the periodic task will
vTaskPrioritySet(NULL, execute
(uxPriority-2)); x = (number_of_executions * y);
} //number_of_executions=3
} //The code can also be modified to
execute a periodic task after a
int main( void ) said time rather than the number
{ of executions
init_USART1(9600); // initialize
USART1 @ 9600 baud for(;;) {
USART_puts(USART1, "USART Delay();
Initialization complete !\r\n"); USART_puts(USART1, pcTaskName );
vTaskDelayUntil( &xLastWakeTime,
//Task Creation (x/portTICK_RATE_MS));
xTaskCreate(sampleTask1, ( Delay();
signed char * ) }
"sampleTask1", 240, NULL, }
sampleTask1Priority, NULL);
xTaskCreate(sampleTask2, ( int main( void )
signed char * ) {
"sampleTask2", 240, NULL, init_USART1(9600); // initialize
sampleTask2Priority, USART1 @ 9600 baud
&xTask2Handle); USART_puts(USART1, "USART
Initialization complete !\r\n");
//Execute the task
vTaskStartScheduler(); // This should //Task Creation
never return. xTaskCreate(emptyTask, ( signed char *
) "EmptyTask", 240, NULL, 1, NULL);

10
 xTaskCreate(periodicTask, ( 7. C ONCLUSION & S COPE FOR F UTURE
signed char * )
"PeriodicTask", 240, NULL, The overall system architecture and requirements of the sub-
2, NULL); //Note that the systems is accomplished by the open-source real-time oper-
periodic task has a higher ating system (FreeRTOS) which supports various types of
priority peripheral interfaces, telemetry storage and data processing.
FreeRTOS was chosen for the project after performing several
//Execute the task comparison and feasibility studies which have been discussed
vTaskStartScheduler(); // This should in the earlier sections.
never return.

// Will only get here if there was The only drawback of FreeRTOS is that tasks are designed
insufficient memory to create to enter in infinite loops. Satellite function tasks should
// the idle task. not be in infinite loop. The tasks should function in the
return 0; specified conditions without going into infinite loops. To
} overcome this issue implementation of special techniques to
avoid infinite loops is required. Currently, we are working
on implementation of certain techniques described in [17] to
The output looks like the following: avoid infinite loops. This would help to modify the existing
FreeRTOS code for STUDSAT-2.
USART Initialization complete !
Empty Task is running Results
Empty Task is running
Empty Task is running Figure 6 shows the image data received from the hardware
Periodic Task is running setup shown figure 5. Camera is interfaced with STM32
Empty Task is running and commanded to take picture using UHF communication
Empty Task is running module. The image stored is sent via 2.4 GHz ISL module.
Empty Task is running The hex values received for the ISL module is converted to
Periodic Task is running JPEG Image format to display in PC and this experiment
Empty Task is running carried out to prove the concept of transmitting image from
one satellite to other satellite via ISL. The results shows
the decoded beacon signal received from the overall satellite
It is worth mentioning that as a subset of the not running state, subsystems interface as seen in figure 5. The data is received
the aperiodic tasks are in the blocked state, that is, these tasks by NASTRAC (Nitte Amateur Satellite Tracking Center)
are waiting for an event to occur and the periodic update tasks using MiXW (a software TNC program).
are in the ready state, that is, they are in the not running state
but are ready to run.
ACKNOWLEDGMENTS
Software Test Logging
The authors sincerely thank Dr. M. Annadurai Chairmen,
Each module should have a minimum of two testing logs SRC for Small Satellite, ISRO and Shri Amereshwar Knened
on file after completion. Due to the nature of software Project, Director, Small Satellite Project and all the scientists
development and debugging (code, compile, test, repeat, across various centers of ISRO and ISRO Satellite Centre
etc) the testing logs will act as a debugging completed log (ISAC) for their motivation and having provided the authors
which shows that the software is completed and ready to be with all the technical and non-technical support. The authors
integrated into the system. extend their sincere gratitude to Dr. Jharna Majumdar, Prof.
CSE and Dean (R&D) of the Nitte Meenakshi Institute of
Full software system tests will only begin once initial ver- Technology, the Chief Project Coordinator of the Project
sions of modules are completed and the full system can be STUDSAT, for guiding the STUDSAT Team and playing a
assembled as a functional software package. The system test key role in initiating the Project STUDSAT-2. The authors
will attempt to check every possible system state and execu- render special thanks to Mr. Loganathan M., Director Space
tion path. This will ensure that the individual modules do not Program Nitte Meenakshi Institute of Technology, for his
cause functionality problems with each other or that there are support and guidance. The authors are grateful to Visves-
multiple modules attempting to use the same resource at the varaya Technological University (VTU), Belgaum for their
same time. Monetary support. The authors thank the Management of
Nitte Meenakshi Institute of Technology, the lead college of
Error Checking the STUDSAT project for their wholehearted support for the
Error checking in the hardware can help to eliminate addi- project. The authors thank Prof. N.R. Shetty, Visionary,
tional software. However, commercial-off-the-shelf (COTS) Advisor, Nitte Meenakshi Institute of Technology and Dr.
products that utilize hardware solutions are cost prohibitive H.C. Nagaraj, Principal, NMIT for providing excellent in-
for this project. A single processor board for both satellites is frastructure in the college for the execution of the project and
utilized because of the higher power requirements of a multi- the encouragement given to the team. The authors thank the
processor plan. Onboard error checking systems are adequate Principals and the managements of the 6 consortium colleges
for our need. Software redundant storage system has been for their support. The authors also thank Richard Barry,
designed and tested for the computers. The system consists the author of FreeRTOS, and Real Time Engineers Ltd. for
of a read, write, and validate module that implements a three- technical support.
copy data storage system to fix any errors that may occur
during storage. This system has been found to be error free
and functions properly on a Compact Flash memory device.

11
 Figure 5. Complete hardware test setup.

Figure 6. Image Received from the interface.

Figure 7. Beacon Received from UHF Beacon Board.

12
 R EFERENCES [17] Super Simple Tasker (SST) by Micro Samek and Robert
Word in Embedded System Design, 2006
[1] Caitlyn M. Cooke, Implementation of a Real-Time Op-
erating System on a small Satellite Platform, in Space
Grant Undergraduate Research Symposium, Colorado
Space Grant Consortium, Boulder, CO, 80309. B IOGRAPHY [
[2] Nishchay Mhatre, Mohit Karve, Gautam Akiwate,
Shravan Aras, Mr. Sanjeev Krishnan, Varad Desh- Bheema Rajulu working as Research
mukh, Rahul Bedarkar, A MODULAR, GENERIC, Scholar for Student Small Satellite
LOW-COST ON-BOARD COMPUTER SYSTEM FOR Project - Project STUDSAT-2, received
NANO/PICO SATELLITE APPLICATIONS, 62nd In- a B.E in Electical and Electronic En-
ternational Astronautical Congress 2011, vol.,no.,pp. gineering from Nitte Meenakshi Insti-
IAC-11,E2,3,5,x10570 2011. tute of Technology under Visweswaraya
[3] Shancao Niu; Jing Zhang; Bin Wang; Xiaodong Fu, Technological University, Belgaum, In-
”Analysis and Implementation of Migrating Real-Time dia in July 2011. He was the core team
Embedded Operating System FreeRTOS Kernel Based member of the Project-STUDSAT-1, In-
on S3C44B0 Processor,” Information Science and Engi- dia’s first Pico satellite, which was suc-
neering (ISISE), 2012 International Symposium on , vol., cessfully flown into the orbit on July 12th, 2010 by PSLV. Now
no., pp.430,433, 14-16 Dec. 2012. he is leading Project STUDSAT-2, India’s first Twin Satellite
Mission aiming to prove Inter-Satellite Communication. He
[4] Rafia Inam, Jukka Mki-Turja, Mikael Sjdin, Moris is the Co-author of several papers out of which one has won
Behnam, Hard Real-time Support for Hierarchical the ESSTA (Emerging Scenarios in Space Technology”) Best
Scheduling in FreeRTOS*,7th annual workshop on Op- paper Award.
erating Systems Platforms for Embedded Real-Time Ap-
plications (OSPERT 11), p 51-60, Porto, Portugal.
Sankar Dasiga has obtained his Bach-
[5] Rahman, M.S.; Atiquzzaman, M.; Ivancic, W.; Eddy, W.; elors Degree in ECE from Bangalore
Stewart, D., ”Implementation of SCTP in an open source University in 1984 and Masters Degree
Real-Time Operating System,” Military Communications in Electronics and Instrumentation from
Conference, 2008. MILCOM 2008. IEEE , vol., no., REC, Warangal in 1988. He has 22Years
pp.1,7, 16-19 Nov. 2008. experience in Embedded Systems and
[6] Sarma, T.C.; Srinivas, C.V., ”Design and Implementation Semiconductor Industry. His industry
of High Bit Rate Satellite Image Data Ingest and Process- experience includes working in Macmet,
ing System,” Signal Processing, Communications and Siemens, Philips, Wipro, CISCO, and
Networking, 2007. ICSCN ’07. International Conference NXP. He is currently working as a Pro-
on , vol., no., pp.149,152, 22-24 Feb. 2007. fessor in Department of ECE, Nitte Meenakshi Institute of
[7] Sethu Selvi, S.; Iyer, N.R.; Sandeep, G.S.P., ”A facile ap- Technology, Bangalore from 2010. He is a Deputy Project
proach to GPS navigation in unmanned ground vehicles,” Co-ordinator for Project STUDSAT-2.
Advances in Technology and Engineering (ICATE), 2013
International Conference on , vol., no., pp.1,6, 23-25 Jan. Naveen Rajaraman Iyer is a final year
2013. undergraduate student pursuing Bach-
[8] DTUsat On Board Computer (OBC) System - DTUsat, elor of Engineering in Instrumentation
http://etd.dtu.dk/thesis/200728/imm5238.pdf Technology, in M S Ramaiah Institute of
Technology, Bangalore, India. He is a
[9] Open source Real time Operating Systems robotics enthusiast who has worked on
for the STM32 and Cortex m3 MCu’s, a variety of projects, conducted work-
https://sites.google.com/site/stm32discovery/stm32- shops on robotics and has also repre-
resources-and-links/open-source-real-time-operating- sented his institute in one of the worlds
systems-for-the-stm32-and-cortex-m3-mpus most prestigious robotics competitions
[10] Why Use FreeRTOS, (IGVC 2012). Additionally, he has coauthored a paper,
http://www.freertos.org/FAQWhat.html#WhyUseRTOS titled A facile approach to GPS navigation in unmanned
[11] FreeRTOS FAQ - Memory Usage, ground vehicles which was published in an IEEE conference,
Boot Times & Context Switch Times, International Conference on Advances in Technology and
http://www.freertos.org/FAQMem.html Engineering (ICATE 2013). He is currently working on
research projects in Centre for Cryogenic Technology (CCT)
[12] FreeRTOS License Details, and Department of Electronic Systems Engineering (DESE),
http://www.freertos.org/a00114.html Indian Institute of Science (IISc), Bangalore, India.
[13] A NEW DESIGN APPROACH OF SOFTWARE AR-
CHITECTURE FOR AN AUTONOMOUS OBSERVA-
TION SATELLITE Jkrorne Gout, Sara Fleury, LAAS-
CNRS
[14] Command and Data Handling Subsystem Design for the
Ionospheric Observation Nanosatellite Formation (ION-
F) John D. Jensen, Utah State University Dr. Charles M.
Swenson (Advisor), Utah State University
[15] USU Software Document AOE
[16] Ion-F Software Architecture AOE
13