International Defense Security & Technology Your trusted Source for News, Research and Analysis
Small satellites have revolutionized the space industry, providing an affordable and accessible way for organizations to conduct space missions. Small satellites, also known as CubeSats, have emerged as powerful tools for scientific research, Earth observation, telecommunications, and more. These compact spacecraft, often weighing just a few kilograms, are revolutionizing space exploration with their affordability, flexibility, and rapid development cycles.
However, behind their miniature size lies a sophisticated network of software systems that enable them to perform their missions with precision and efficiency. The software that controls small satellites must be robust, reliable, and capable of executing complex commands in the harsh environment of space. In this article, we delve into the intricacies of software design and development for small satellites, exploring the unique challenges and innovative solutions that characterize this fascinating field.
The Role of Software in Small Satellites:
At the heart of every small satellite is a sophisticated software system that controls its operation, manages its subsystems, and executes its mission objectives. From attitude control and propulsion to data acquisition and communication, software plays a crucial role in every aspect of a satellite’s lifecycle. The software must be robust, reliable, and efficient, capable of operating autonomously in the harsh environment of space while responding to commands from ground control stations on Earth. Moreover, the software must be flexible and adaptable, allowing for updates and modifications as the mission requirements evolve.
The Challenges of Small Satellite Software Design and Development
Designing and developing software for small satellites presents unique challenges. Small satellites have limited power and computational resources, which means that the software must be efficient and lightweight. Moreover, the software must be able to withstand the extreme temperatures, radiation, and vacuum of space, while also being able to operate autonomously for extended periods.
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.
Another challenge is that the software must be designed to handle the specific needs of the mission. Small satellites are used for a wide range of applications, from Earth observation to communications and scientific research. The software must be customized to meet the requirements of each mission and be able to execute the necessary commands.
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.
Software Design and Development for Small Satellites
The software design and development process for small satellites typically follows a standard software engineering lifecycle. The process begins with requirements gathering, followed by design, coding, testing, and deployment. However, designing and developing software for small satellites requires a deep understanding of the unique challenges and requirements of space missions.
During the requirements-gathering phase, the software engineer must work closely with the mission team to understand the objectives and goals of the mission. The software engineer must also consider the hardware and environmental constraints of the small satellite to ensure that the software is optimized for the available resources.
The design phase involves developing a software architecture that meets the requirements of the mission. The architecture must be modular and scalable, allowing for the addition of new functionalities as the mission progresses. The software engineer must also consider fault tolerance and error handling to ensure that the software can recover from unexpected errors.
Once the software architecture is designed, the software engineer begins coding the software. The code must be optimized for the limited resources of the small satellite and be able to execute complex commands autonomously. The software engineer must also consider the impact of radiation on the code and implement measures to protect against data corruption and system failures.
The testing phase is critical for ensuring that the software performs as expected in the space environment. The software engineer must conduct both functional and environmental testing to ensure that the software can withstand the harsh conditions of space. The software must also be tested for its ability to handle unexpected errors and failures.
Finally, the deployment phase involves installing the software on the small satellite and conducting final testing to ensure that everything is working as expected. The software engineer must also ensure that the software is able to communicate with ground control and receive commands.
For in-depth understanding on Software Development for Small Satellite Constellations please visit: Software Development and operation management for Small Satellite Constellations: Best Practices and Strategies
Requirements
In the context of satellite missions, there are typically three subsystems involved: the Ground Station (GS), the Operation Center (OpCen), and the satellite itself. Each of these subsystems plays a crucial role in ensuring the success of the mission.
The Ground Station (GS) serves as the interface between the satellite and the terrestrial infrastructure. Its primary role is to communicate with the satellite, receiving telemetry data and sending commands for operation. Additionally, the Ground Station is responsible for tracking the satellite’s position and managing its orbit, ensuring optimal communication coverage.
The Operation Center (OpCen) acts as the central command hub for the entire satellite mission. It coordinates activities between the Ground Station, satellite operators, and other stakeholders. The OpCen oversees mission planning, scheduling, and execution, ensuring that all activities are conducted according to plan and mission objectives are achieved.
Finally, the satellite itself is the centerpiece of the mission, responsible for collecting and transmitting data, executing commands, and performing various mission-specific tasks. It relies on the Ground Station for communication and receives instructions from the Operation Center for mission execution.
Together, these subsystems form a cohesive framework for satellite missions, with each playing a distinct role in ensuring efficient communication, operation, and overall mission success.
The Ground Station Requirements refer to the functionalities and software logic that the GS must perform. This includes tasks such as receiving and decoding signals from the satellite, processing and analyzing the data, and sending commands back to the satellite. The managed data must also be stored in a manner that allows for easy retrieval and analysis. In addition, the interface between the GS and other subsystems must be managed in a way that allows for efficient communication and operation. The software used in the GS must also be designed in a way that allows for reusability, in order to facilitate future satellite missions.
The Operation Center Requirements refer to the software requirements related to the end user interface. This includes how the software user interface should work, how the user communicates with the OpCen, and how the OpCen software should communicate with the GSs. The OpCen software must be designed in a way that allows for efficient communication and operation between the end user and the GS, as well as providing easy access to the data collected by the satellite.
Finally, the System Communication Requirements refer to the data that needs to be shared between the GS and the OpCen, and how it should be shared. This includes communication protocols, security measures, and the transmission of data between the two subsystems. It is important that this communication is efficient, secure, and reliable, as it is essential to the success of the satellite mission.
In conclusion, the successful operation of a small satellite mission requires efficient communication and operation between the Ground Station, the Operation Center, and the satellite itself. This requires careful attention to the software design and development of each subsystem, as well as ensuring that the communication protocols and security measures are in place to facilitate the transmission of data between the subsystems.
Non-Functional Requirements
Non-Functional Requirements (NF-REQs) are essential for the development of software systems that go beyond mere functionality. While Functional Requirements describe what the system does, Non-Functional Requirements describe how it does it. These requirements specify the characteristics that the system must exhibit, such as reliability, maintainability, scalability, and security, among others.
In the context of small satellite mission software systems, Non-Functional Requirements play a critical role in ensuring that the system is secure, reliable, and efficient. For example, NF-REQ 1 specifies that data exchanges between the Ground Station and the Operation Center should be done through a secure connection, ensuring that the data is protected from unauthorized access or interception. NF-REQ 2 states that the Ground Station software should be scalable and modular, allowing it to adapt to changing mission requirements and handle increased data volumes as the mission progresses.
NF-REQ 3 highlights the need for reliability and fault tolerance in the Ground Station software, ensuring that the system can recover from errors such as power or internet outages. NF-REQ 4 specifies that data integrity between the Ground Station and the Operation Center is essential, ensuring that the data is accurate and consistent across the system.
NF-REQ 5 shifts the focus to the Operation Center software, emphasizing the need for usability. The Operation Center is the interface that real users interact with, and it should be intuitive and easy to use, enabling users to access the data they need without unnecessary complexity. Finally, NF-REQ 6 highlights the importance of branding and consistency in the Operation Center software, ensuring that it maintains a consistent look and feel that aligns with the overall mission brand image.
In summary, Non-Functional Requirements play a crucial role in the development of small satellite mission software systems, ensuring that the system is secure, reliable, scalable, and usable. By prioritizing these requirements, developers can ensure that the software system delivers on the mission objectives, providing reliable data and insights to support scientific research and exploration.
Satellite Hardware
Satellite hardware refers to the physical components that make up a satellite and enable it to perform its functions in space. These components include the flight computer, power supply system, communication system, attitude control system, propulsion system, payload devices, and structural elements.
The flight computer is the central processing unit of the satellite that controls all operations and subsystems. It is responsible for executing the onboard software and managing all data collected and transmitted by the satellite. The power supply system provides electrical power to all subsystems and components of the satellite. It typically consists of solar panels and batteries.
The communication system enables the satellite to transmit and receive data to and from the ground station and other satellites. This system typically includes antennas, transmitters, receivers, and modulators. The attitude control system is responsible for maintaining the correct orientation and stability of the satellite in space. It typically consists of reaction wheels, thrusters, and sensors.
The propulsion system provides the necessary thrust to move the satellite to its desired orbit and to perform orbital maneuvers. Payload devices are instruments or equipment on the satellite that perform scientific experiments, take measurements, or capture images. The structural elements provide support and protection to the satellite components.
The hardware design of a small satellite is often more challenging than that of a larger satellite because of the limited space and weight restrictions. Therefore, it requires a more compact, efficient, and reliable design. The hardware components are typically integrated into a single module to reduce weight and improve reliability.
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. The separation of physical systems is therefore simulated through a software design that provides segmentation of associated functionality
Additionally, the hardware components must be radiation-hardened to withstand the harsh space environment and prevent damage from cosmic rays and solar flares.
In conclusion, the hardware components of a satellite are critical to its success in space. They enable the satellite to perform its functions, collect and transmit data, and maintain its stability and orientation in space. The design of these components must be compact, efficient, and reliable to meet the weight and space restrictions of a small satellite and withstand the harsh space environment.
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 is 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
An operating system (OS) is a software component that manages computer hardware resources and provides services for computer programs to execute. It acts as an interface between the computer hardware and the user applications, providing a platform for running programs. An OS performs several functions, including managing memory, providing input/output services, managing files and directories, providing security, and managing processes and tasks.
In the context of satellite operations, an OS is used to manage the software subsystems onboard the satellite and to handle the scheduling of tasks as needed. This allows the software to be broken down into intuitive tasks, which can be executed independently and efficiently.
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. Three popular OS for nano-satellites are SALVO, FreeRTOS, and Linux.
In satellite operations, a user on the ground station generates a schedule of work for each software subsystem onboard the satellite using custom software on a Linux computer. 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. Once a collection of config files has been created on the ground, they are transmitted to the satellite using a custom communications protocol implemented as another piece of Linux software. The subsystems onboard the satellite are commanded to read and interpret their uploaded config files 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 to the ground station. 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
System design is the process of transforming the requirements of a system into a concrete plan or model for its implementation. This includes defining the system architecture, interfaces, and behaviors of the different components of the system. The goal of the system design phase is to create a detailed plan that can be used for the actual implementation of the system.
The system design phase involves defining the architecture of the software, including the applications and device drivers, as well as the interactions between them.
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 also includes defining the interfaces with the ground station, such as the protocol for uploading and downloading config files, and the communication between the subsystems onboard the satellite.
The system design phase is followed by the implementation phase, where the system is built according to the plan created during the design phase. This includes the development of the ground station software, as well as the implementation of the different software components onboard the satellite, including the applications and device drivers.
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 are 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. Communication 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.
The limited communications windows and data bandwidth also require the satellite to operate autonomously for long periods of time. This means that the software must be able to handle and process large amounts of data onboard the satellite and make decisions based on that data without the need for constant communication with the ground station.
Overall, the modes of operation provide a framework for the software to operate efficiently and effectively in a challenging environment with limited communication and processing resources.
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.
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.
A Ground System (GS) is a set of facilities and equipment used to communicate with satellites in orbit. It includes ground stations, antennas, and radio interfaces, as well as software and hardware that allow the communication to happen. The GS is essential to upload telecommands to the satellite and download data from it. The OpCen is where the missions are managed.
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 OpCen, on the other hand, is the mission management center where operators work to monitor the satellite output, prepare commands, and maintain the GS infrastructure. The OpCen is connected to the GS using a specific network known as the GS Network. With the advent of low-cost satellite platforms, such as CubeSats, the automation in the management of the Ground Segment is becoming more important to make the operators’ job easier. The GS network enables operators to manage the GS and the spacecraft remotely.
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.
Operations management
Operations management is the process of planning, organizing, and executing all activities related to the operation of a satellite. It involves managing resources such as personnel, equipment, and time to achieve mission objectives efficiently and effectively. Operations management includes tasks such as scheduling satellite passes, executing health checks on the satellite, planning and sending commands to the satellite, and receiving and analyzing telemetry data.
In addition to the roles mentioned above, there may be other roles in operations management, such as a mission director who oversees the entire operation and makes high-level decisions, or a data analyst who analyzes the telemetry data received from the satellite and provides feedback to the operations team.
The goal of operations management is to ensure the satellite is operating as intended and meeting its mission objectives. This requires a high level of coordination and communication between the different roles and stakeholders involved in the operation, including the ground segment team, the satellite manufacturer, and the mission customer.
To achieve effective operations management, it is necessary to have a well-defined and documented operations plan, which includes procedures for all phases of the mission, from launch to decommissioning. It is also important to have a robust system for tracking and reporting on mission performance and identifying and mitigating any issues or risks that may arise during the operation.
Testing
During the testing phase, the project team develops a plan to test the product to ensure that it meets the specified requirements and behaves as expected in all scenarios. This phase typically involves testing the system at various levels, including unit testing, integration testing, and system-level testing.
For the GS, the testing phase involves conducting unit tests and integration tests. Unit tests are designed to test individual components of the software, while integration tests are designed to test how different components work together. 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.
Similarly, for the OpCen, the testing phase involves conducting unit tests and integration tests. Once the individual components have been tested, the entire system is tested at a system level to ensure that all the components work together as expected.
Overall, the goal of testing is to ensure that the product is fully functional, reliable, and meets all the specified requirements. Testing is a critical part of the software development lifecycle and helps to identify and fix issues before the product is released to the end-users.
Deployment
Deployment is the phase in the software development life cycle (SDLC) where the product is made available for use in a production environment. It involves the installation of the software, configuration of the system, and making it operational.
The deployment phase includes two main tasks, which are the GS software deployment and the OpCen deployment.
For the GS deployment, the code is deployed to the GSs by accessing the git repository and using a laptop with remote access to the GS’s computer. This process involves transferring the software files to the GS and installing the required dependencies and libraries. The GSs are then set up to run the software in the production environment.
Similarly, for the OpCen deployment, access to the OpCen’s server is required, and the software is deployed using a laptop with the git repository. This involves configuring the system and installing the software and any necessary dependencies.
Once both the GS software and the OpCen software are deployed, the final step is to connect the two deployed software components to have a full system deployment. This involves verifying that the communication between the two software components is working correctly and that the system is operational.
Verification
Verification is the process of evaluating a product or system to determine whether it meets the specified requirements and expectations. In software development, verification typically involves testing the software to ensure that it performs as intended and meets all functional and non-functional requirements.
The verification phase usually comes after the testing phase, and its main goal is to ensure that all tests that passed in the testing phase still pass in the production build of the software. This is done to ensure that the software works correctly and meets the requirements set forth by the customer or stakeholders.
In addition to testing, the verification phase may also involve reviewing the software documentation to ensure that it accurately reflects the software implementation. The verification process may also involve checking that all required documentation has been completed and that the software has been properly deployed and configured.
The PV1 task is typically performed during the verification phase, and its purpose is to check that the final project meets all of the requirements and verification criteria that were established during the inception phase. This involves reviewing the project documentation, testing the software, and verifying that it has been properly deployed and configured.
Conclusion
Designing and developing software for small satellites is a complex and challenging task. The software must be efficient, reliable, and capable of executing complex commands in the harsh environment of space. However, with the right design and development process, software engineers can create software that meets the unique challenges and requirements of space missions.
From code to orbit, software plays a critical role in the success of small satellite missions. As the demand for small satellite missions continues to grow, the importance of software design and development for small satellites will only continue to increase. By following best practices and utilizing the latest technologies, software engineers can help organizations achieve their space mission objectives and explore the final frontier.
References and Resources also include:
http://cubesat.ece.illinois.edu/Files/thesis_dabrowski_050405.pdf
