Software Design and development of Small Satellites

Traditionally, all space missions have two main segments, one is the Space Segment which is composed of the satellites themselves. The second one is the Ground Segment, which consists of all the elements used to design, manage and conclude space missions, such as testing facilities, and infrastructure to operate and control the spacecraft.

The software system is responsible for performing all of the operations of the satellite including control of onboard hardware devices, scheduling of operations, maintenance of data, and communications with a ground station on Earth.

Any space mission requires software that can operate reliably for long periods without the need for maintenance. Once the satellite is in-orbit, any error that occurs is not usually correctable. In the period 2000-2012, at least 2% of CubeSats failed due to software. Moreover, the use of COTS components makes it necessary that the software is able to tolerate faults since fault prevention is not an option.

The software requirements of the satellite are determined by both the electronics hardware present and the
determining mission specification. Most space satellites have a specific mission performed by their main payload
components.

Satellite Functions and tasks

Space satellites typically perform a standard set of tasks. First, satellites perform power management operations, including control of solar panel operation, management of power distribution, and control of battery charging. Many satellites also perform attitude control in order to allow them to maintain specific orientations with respect to the Earth’s surface. Attitude control may be performed passively using magnets and gravity gradient stabilization, or may be actively performed by a control mechanism such as gas thrusters, magnetic torque coils, or momentum wheels.
Communications and data handling operations are performed by most satellites. These operations include transmission of telemetry data to Earth, receipt of commands, management of data, and execution of any necessary computations.
Finally, satellites perform what can be termed payload operations. These operations are specific to the payload of a satellite and may include imaging tasks, communications relay tasks, or tasks to perform scientific experiments

These electronic components are grouped into five main areas: the flight computer, components specific to the scientific payload of the satellite, components specific to satellite attitude determination and control, components specific to communications with a ground station on Earth, and components that provide fundamental electrical support.

To properly orient themselves in space, satellites often perform active attitude control. In order to do this, sensors providing feedback on spacecraft orientation along with an actuator mechanism to perform control are required. Communication between the Earth and a satellite is commonly accomplished through the use of a radio along with some form of modulation of digital data.

Onboard Power is provided by a power system consisting of lithium-ion batteries, solar panels, a power control board, and a  peak power tracking (PPT) board.

 

Modes of Operation

On the topmost level, the design of the flight software is based on modes of operation. 4 modes of operation were designed and transitions to each other defined. At any given point of time, the software exists in one of the modes, which dictates how the internal tasks are run and how it should respond to various external triggers.

 

Interaction with space satellites, especially small satellite, is limited as to two main problems. First, communications windows are very short and infrequent as a result of the typical low earth orbits of small satellites. In general, communications between a satellite in low earth orbit and a single ground station on Earth is limited to two 15 min windows every 24 h. The majority of satellite operations must occur while there is no contact with the satellite. This requires a satellite to either perform activity autonomously or based upon a predetermined schedule.
Second, data bandwidth between small satellites and ground stations is often very limited.

Communications links are slow as a result of limitations of power, financial budget, and physical space. A slow communications link, coupled with a short communications window, means that very little data can be transferred between a satellite and a ground station. It is expected that within a single communications session fewer than 100 kilobytes of data can be transferred between ION and a ground station. The limitations on contact time and data transfer amount force satellites to operate largely autonomously and perform a large amount of processing and decision-making onboard.

Ground System

Satellites are constantly moving, following an orbit trajectory. This trajectory can be modeled using orbital parameters. These parameters are formatted in the well-known Two-Line Element (TLE) File. TLE file contains all the parameters to calculate the position and velocity of a satellite at any given time. With this TLE and a list of timestamps, it is possible to generate a sequence of position and velocity using an orbit propagator. It is basically a software implementation of one of the Simplified Perturbations Models, which are a set of Keplerian calculations that predict the position and velocity of the satellite relative to the Earth-Centered Inertial (ECI) coordinate frame.

In order to communicate with the Ground Segment, radio frequency transceivers are used. Satellites have a configured downlink frequency for sending data to the Ground Segment and an uplink frequency for receiving commands.  These communications can only be achieved when the satellite is flying over the GS. Due to the satellite motion, the spacecraft remains visible from a GS during a lapse of time, called GS pass. During this contact, the satellite changes its position with respect to the GS one. Therefore, the GS has to be capable to point its antennas towards the satellite. The interval of the orbit in which the satellite will be visible is known as the coverage interval. When a satellite travels above the coverage interval, the GS pass is feasible.

As there exists a relative movement between the Satellite and the GS, the radio waves suffer from the so-called Doppler effect. The Doppler effect is the change in the instantaneous frequency due to the relative velocity between two nodes. Due to the Doppler effect, the frequencies at which we have to receive or transmit to the satellite vary depending on the relative velocity it has at each point of time. As the velocity is known thanks to the Orbit Propagator, and the frequency of the satellite is also known, the Doppler shift can be calculated and thus the frequency can be compensated accordingly.

Due to the popularization of constellations based on low-cost satellite platforms (CubeSats), the Ground Segment facilities need to expand for the sake of handling all those satellite missions. The automation in the management of the Ground Segment is becoming more and more important in order to make the operators’ job easier.

The Ground Segment includes different support equipment essential to achieve the mission. The common and more important facilities of this segment are the GS and the OpCen. The GSs are the installations used to communicate with the satellite, uploading telecommands and downloading data. Therefore, it includes all the antennas, and radio interfaces to achieve this goal. They contain the hardware and software that makes possible the communication with the satellite. The OpCen is where the missions are managed.

All the personnel manning the different stations in an operation center are called the operators, and their competencies range from monitoring the output of the satellite or preparing the commands to upload, to maintaining the GSs infrastructure to communicate with the satellite.

The OpCen is connected to GSs using a specific network known as the GS Network, enabling operators to manage the GS and the spacecraft remotely.

 

Operations management

When operating the satellite, there are three main roles that need to be covered by the operators. The GS manager, the responsible of the Uplink and the responsible of the Downlink.
 GS Manager: The GS Manager is responsible for scheduling passes, executing health tests to guarantee the correct functioning and performance of the GS before, during and after performing operations like a satellite pass.
 Uplink Manager: The Uplink Manager is the operator in charge of planning the commands flow for one pass and sending them to the satellite at each scheduled time.
 Downlink Manager: Is the operator in charge of receiving and analyzing the telemmetry of the satellite. Additionally, she/he must inform to the Uplink Manager on what to do next.

Those three roles work together in a coordinated manner, but each of them focused on its own specific tasks.

Requirements

Ground Station Requirements refer to all the functionalities (software logic) that the GS has to perform, how the managed data should be stored and how the interface to the GS should be managed. It also includes some design requirements in order to make the software reusable.
Operation Center Requirements denote the requirements related to how the final user communicates with the software user interface, how the OpCen software should work and how it should communicate with the GSs.
System Communication Requirements define the data that needs to be shared between the two subsystems and how it has to be shared, including security and communication protocols.

Non-Functional Requirements

In addition to directly implementing the satellite mission, the software system needed to provide some level of reliability, redundancy, and features for recovery in the case of any errors. Examples include support for
new software updates from the ground, recovery mechanisms in the case of device failure, assessment of general system health, and logging of system activity.

Non-Functional Requirements are requirement that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. These are the nonfunctional requirements needed to ensure the quality of the final product.
NF-REQ 1: Data exchanges should be done through a secure connection.
NF-REQ 2: The GS software should be scalable and modular.
NF-REQ 3: The GS software has to be reliable and should be able to recover from errors,
such as internet or electricity outage.
NF-REQ 4: There has to be data integrity between the GSs and OpCen.
NF-REQ 5: The OpCen’s software has to be usable, as it is the one managed by real
users.
NF-REQ 6: The OpCen software GUIs have to keep the same look and feel and brand
image.

Satellite Hardware

Traditionally many satellites have separated their functionality into multiple physically independent hardware subsystems. Each hardware system would be responsible for performing a single function such as attitude determination and control or operation of a payload device such as camera. The hardware design of a small satellite does not allow for this. Instead, a single central computer is required to perform all satellite operations.

Nearly all space satellites have at least one flight computer devoted to performing tasks related to communications and data handling. Many satellites have additional computers devoted to the operation of specific subsystems or tasks such as attitude control or scientific payloads. Nearly all of the electronics components directly interface to the flight computer. Operation details of these devices require specific timings and control of signal lines

The separation of physical systems is therefore simulated through a software design that provides segmentation of associated functionality

Flight Software

The FSW is, at a fundamental level, the instructions for the spacecraft to perform all operations necessary for the mission. These include all the science objectives as regular tasks (commands) to keep the spacecraft functioning and ensure the storage and communication of data (telemetry).

The functionality of the flight software is broken down into tasks. Each task handles a particular functionality of the software and thus allows modularity of design. They also provide an intuitive way to design the software from specifications. For example, the specification that the satellite must beacon at regular intervals is simply translated to a Beaconing task. For the sake of modularity, the tasks are kept as independent as possible.

The software system must solve two problems for each operation the satellite performs. First, a mechanism is needed to regularly perform the required operation based upon a schedule or command received from the ground. Second, a mechanism to handle the exact details of performing the operation is needed.

For example, the satellite functional requirement to “Take and record a picture at undefined times and at an undefined frequency” can be considered to consist of two main problems. The first problem requires the creation of a mechanism to interpret a request from the ground to take a picture, begin the process of taking a picture, and appropriately store the resulting image. The second problem requires the creation of a mechanism for the hardware
details of making the camera take a picture. This includes: powering on the camera, configuring camera settings, starting a memory transfer operation, and powering off the camera.

Each group of associated satellite functionality could be performed by a software subsystem. Each subsystem would consist of two parts, corresponding to the two problems which needed to be solved for each satellite operation. The first part would be a generic mechanism, known as an application, which would use a hardware device or group of
devices based upon either a schedule or system state. The second part is known as a device driver that interfaces to the hardware. Each subsystem would be responsible for handling its own data and managing its own schedule of operations performed, thereby completely hiding the details of the operation of the subsystem.

Each independent software subsystem needs to be given processing time to run on the central computer as well as any other resources it requires. A mechanism was needed to allocate these resources to each subsystem. Ideally, the
mechanism would hide the details of resource allocation and provide a simple way to use the entire satellite from the ground. This mechanism should allow for some limited interaction between subsystems, allowing individual subsystems to affect other portions of satellite operations.

Because each independent subsystem was determined to be responsible for the management of its own data,  a data storage mechanism would be necessary. Data used and generated by subsystems may be of large size and undefined format; therefore, this mechanism must be generic. Furthermore, the mechanism should be easy to use, should hide the details of its operation, and should allow for data to persist across system reboots.

In order to permanently store and access general data onboard satellite, a file system is required to use with the flash memory chip onboard the computer. The file system would need to provide the ability to create, read, write, and delete files.

Operating System

There are many factors in the selection of a development environment and/or operating system used for a space mission. A major factor is the amount of memory and computational resources. There are always financial and schedule concerns. Another factor is what past software an organization may have used and their experiences with that software. Also, the maturity of the software as well as its availability on the target are additional factors to be considered in the final selection.

The use of an operating system (OS) has become increasingly popular in nano-satellites. All but the simplest of flight software benefits greatly from the use of an OS because it lets the software be broken down into intuitive tasks and handles the scheduling of these tasks as needed

Three popular OS are SALVO, FreeRTOS, and Linux. FreeRTOS is a light, open-source real-time operating system.  FreeRTOS is developed for embedded applications and thus it has good support for various micro-controllers and an active community.

 

Therefore, satellite operations must be previously scheduled to occur when there is no contact between the satellite and Earth. Command of the satellite begins at the ground station where a user uses custom software on a Linux
computer to generate a schedule of work for each software subsystem onboard the satellite. These schedules of work consist of multiple pieces of data known as work units and are stored in a standard format known as a config file. Each work unit specifies an operation to perform, the date and time it should be performed, and any associated options with the operation. In addition to storing a collection of work units, each config file also specifies some global details of operation for a subsystem. Once a collection of config files has been created on the ground, the next time communication is established with satellite these files are transmitted to the satellite using a custom communications protocol implemented as another piece of Linux software.

After the config files have been uploaded to the satellite, each running subsystem onboard the satellite is commanded to read and interpret its uploaded config file using a special command built into the communications protocol known as Rehash().
The satellite communications window soon ends and over the course of the next 24 h each subsystem does its best to perform the work requested. In most cases all work scheduled will be executed. For reasons of system schedulability or safety, however, some work may be dropped, though it is the responsibility of the user to create work schedules to make sure that the expectations placed upon the time and power margins of the satellite are realistic and that no damage will occur as a result of execution of the scheduled operations.

During the next communications window any data files that were created as a result of satellite operations are downloaded. These files may include samples from various instruments, system logs, or even photographs. Interpretation and processing of the resulting data are performed on the ground and any operations that are to be taken as a result of returned data are encoded as work units for upload.

System Design

Two software components known as applications and device drivers completely fulfill the first tier of the software functional requirements. Typically, each device driver is responsible for directly interacting with a single hardware device and completely abstracts away the details of device operation. Nearly all of the hardware devices onboard ION can be considered sensors or actuators so all device drivers follow a very similar design providing a simple way to perform an output action or perform an input sample.

The software system was next required to provide a mechanism to use each device or group of devices at the appropriate time based upon input from the ground. This was accomplished with a set of software components referred to as applications. Typically, an application interacts with one or two device drivers in order to operate hardware devices as needed. Applications perform all management of data associated with device operation,
including interpreting and maintaining schedules of work from the ground and recording results of operations into files on the file system.

One example subsystem is the communications subsystem which consists of a communications application along with a device driver for the Terminal Node Controller, Radio, and Antenna. This subsystem, consisting of an application component and multiple device driver components fulfills the final of the first tier requirements. This requirement necessitated a mechanism to return recorded data to Earth and to accept schedules of commands from
Earth.

The system software is responsible for bringing the software system up to a known state upon satellite power up, starting and stopping applications as necessary, providing a limited communications mechanism for applications to affect the operations of the entire satellite, and cleanly shutting down the system upon satellite power down.

The design phase deals with transforming the gathered requirements into a feature that can be implemented later. It defines the system architecture, the interface in which the software can be accessed and the detailed behaviours of some logic units. The design phase includes the general architectural System Design (SD1), the GS with its database design, and the OpCen with its database design.
SD1 – System Architecture Design: Consists of defining the general architecture of the software, treating the OpCen and the GSs as black boxes and defining the interfaces between them.
SD2 – GS Design: Designing the software architecture of the GS. Specifically, the interfaces with the hardware, the interface with the OpCen, the logic layer and the access to the database.
SD3 – GS Database design: Designing the database structure and choosing one database type.
SD4 – OpCen Design: Defining the design of the OpCen software architecture, including the user interface basics, backend functions, database accesses and connection with the GS interface.

SD5 – OpCen Database: Designing the OpCen Database with compatibility with the one in the GSs.

In the implementation phase, the product is built according to the specified design. It includes the GS and the OpCen implementation.

Testing

In the testing phase, a project plan is developed in order to find whether the product meets the requirements and if it behaves as it should in all scenarios. During the testing phase the GS and the OpCen are tested according to the project plans.

TT1 – GS Testing: To conduct the unit tests and integration tests. For each unit test, the specific implementation task needs to be complete in order to get a valid report. For the integration test, both of the tasks involved need to be completed.

TT2 – OpCen Testing: To conduct the unit tests and integration tests.
TT3 – System Level Testing: Testing the system as a whole.

Deployment

The deployment phase puts the product into production. It can be divided in two tasks, the GS software deployment and the OpCen deployment.
DP1 – GS Deployment:  In order to deploy the code to the GSs, the git repository has to be accessed and a laptop with remote access to the GS’s computer is required.
DP2 – OpCen Deployment: In order to deploy the software, there needs to be access to the OpCen’s server and a laptop with the git repository.
DP3 – System Connection: To connect the two deployed softwares (DP1, DP2) in order to have a full system deployment.

Verification

Finally there is a verification phase. Its main purpose is to verify that all the tests that passed in the testing phase, still pass in its production build. It also checks which requirements are met at that iteration. There, the deployed project is verified and the documentation finished.
PV1 – Project Verification: To check that the final project meets the requirements
and verification criteria established during the inception phase.

 

References and Resources also include:

file:///C:/Users/DELL/Downloads/Askari2017-SoftwareDevelopmentforGalassiaCubeSatDesignImplementationandIn-OrbitValidation.pdf

http://cubesat.ece.illinois.edu/Files/thesis_dabrowski_050405.pdf

 

 

Cite This Article