Designing, Developing and Deploying CubeSats

In 1999, a collaborative effort of Jordi Puig-Suari, a professor at California Polytechnic State University and Bob Twiggs of Stanford University, created the reference design for CubeSats. They maintained that the proposed platform can help reduce the cost of technical developments and scientific investigation. This reduction escalated the access to space, leading to diversification of its use, and researchers found it a great platform for quick deployment of their proposals.

What is CubeSat?

A CubeSat is a miniaturized spacecraft that orbits the earth. As the name suggests, CubeSat is shaped like a cube of about 10 cm in length, breadth and depth. This is called one unit or 1U. It is very lightweight, weighing not more than 1.33 kilograms. CubeSats can be stacked together to form a larger CubeSat of two, three or even six units. Once in space, this can be used in a variety of applications. Cubesats are economical and reduce launch cost to a consider able extent. Owing to the fact that it is lightweight, you don’t need much fuel to deploy them.

Figure 1. 1U Cubesat (small enough to hold it in your hand)

In the beginning, cubesats were exclusively used in low earth orbit for applications like remote sensing or communications. At present they are even being used in interplanetary missions.

Challenges?

Satellites may need to remain in space for months or even years. So, we need to optimize their power consumption. This can be achieved by designing small circuits and minimizing components like ICs and the printed circuit boards. These electrical components operate at optimal temperature ranges, but temperatures in space fluctuate rapidly within short periods of time from extreme hot to freezing cold, so this directly affects their lifespan.

Secondly, radiation from both the sun and outside the solar system has to be taken into consideration. The radiation particles may contain electrons and protons that penetrate through the satellite, interacting with the circuitry. This can cause bit flipping which is related to data transmission, build charge in materials, and change the properties of components. The impact may range from minor effects to complete shutdown of the whole system.

Overview of the Satellite's Operation in Space

For our explanation on the design of the CubeSat, we have considered a reference architecture published by the Air Force Research Lab at Kirtland Air Force Base in Albuquerque, NM, USA. Figure 2 shows a satellite revolving round the earth. This Cubesat travels around the Earth in elliptical orbits. It takes 90 minutes (5400 seconds) to complete one rotation. CubeSats are generally used in low Earth orbit for applications like remote sensing and communications. This guarantees ideal conditions for land observation or communications and provides better shielding from solar and cosmic radiation.

Figure 2. Satellite orbiting round the Earth

Cubesats are loaded into the dispensers and its power is turned off. Dispenser systems are used for multiple satellite launches, where a number of spacecraft need to be placed in orbit in a short timeframe. When cubesats are deployed into orbit, the transmitters are turned on and power and other tools get activated. The development team is responsible to complete the launch and early operations phase (LEOP) for commissioning all subsystems and payloads.

Payloads consist of the communication antennas, receivers, and transmitters. During the LEOP phase, it is checked whether the satellite survived the launch. Further, the satellite is identified among all other satellites that may have been deployed simultaneously. The Launch and Early Operations phase is one of the most critical phases of a mission and generally takes a period of seven weeks.

Additional checks certify that the solar panels supply sufficient power for operation. The LEOP phase continues with a platform commissioning and detumbling phase. The commissioning phase performs functional checking of the end-to-end system, proceeding from simple to complex operations. Detumbling is the process of stabilizing the angular rate of the satellite after orbital insertion. In this phase, all subsystems of the CubeSat are checked for their correct function in orbit. The satellite may have some rotations induced by the deployment mechanism.

The CubeSat has to be detumbled to a stable attitude. Once the satellite is stable, other actuators such as reaction wheels can take over for fine attitude control required for nominal operations. A reaction wheel is a type of flywheel used primarily by spacecraft for three-axis attitude control. They provide a high pointing accuracy. Attitude control helps in stabilizing the satellite. The LEOP finalizes with the commissioning of the payloads. Operators calibrate the instruments, and perform tests to check for the payload function, power consumption and transmission of data for safe operations.

There are limitations set in the quantity of information that can be sent through a radio channel. Multiple ground stations are set to maximize the data exchange between the satellite and its operators. This leads to the development of a network of ground stations.

During the satellite operation, it is pivotal to prepare a proposition for daily observations. First, simulations should be performed to foresee the exact time when the CubeSat appears over the horizon for every observation event. Further, to store the results of every incident, a template has to be made for the operation report. The report so generated can be used in the future for keeping track of the work performed, as well as analyzing the data in case of some operation failure. The status of the satellite is summarized in the housekeeping telemetry data. Housekeeping telemetry consists of the parameters and event messages. They are processed and converted into the engineering or functional parameter values needed to monitor the status of the spacecraft platform, payload, and to recover in case of anomalies.

Insights on the Cubesat Architecture

Figure 3. Architecture Model of the CubeSat in VisualSim Architect

Figure 3 depicts the model of a CubeSat developed using a modeling and simulation software called VisualSim Architect from Mirabilis Design Inc. The designer can perform various experimentations, conduct a variety of tradeoffs for optimization and functional studies to meet the specified requirements before actual implementation in real time. The designer gets a clear picture of the performance and power optimization to determine the trade-offs, for instance the failure and functional analysis, security, and a variety of other attributes. It helps in exploration of the architecture and to rectify faults at a very early stage.

Working of the Subsystems

There are multiple subsystems such as telemetry, tracking and command (TTC), thermal, electrical power system (EPS), altitude control system (ACS), command and data handling (CDH), payload, and mission communication. Each subsystem is allocated a task to process.

The TTC and mission communication subsystem observes and controls the spacecraft’s functions and communication to and from the satellite. The thermal subsystem controls and monitors the temperature of all hardware within the satellite. The EPS subsystem manages peak, pulse and transient power demands and the battery charge/discharge cycles. It eliminates spacecraft instability and performance degradation.

ACS measures orbit position, absolute attitude, spacecraft rates and can also control the orientation of the satellite. CDH handles all the real-time operations of the satellite and provide data interfaces to all other systems. Payload acquires scientific data and monitors the health and progress of various subsystems. As the satellite revolves around the earth, it is expected to perform tasks at specific times that need to be completed within a time deadline.

Functioning of the Model

The controller configures all the systems before the start of a task. Associated with each task is a schedule time, processing time, and a deadline. The Modular Space Vehicle (MSV) scheduler is responsible for scheduling the tasks. The scheduler uses the Application Sensor Interface Module (ASIM) mapper to present the task to the corresponding hardware unit.

The ASIM gets triggered by the scheduler based on the orbit number and the sequence defined in the table. In this dynamic system simulation, there is a processing module that monitors and records the latency, power consumption and battery charging activities. The delay defined for each task is used as the time that a subsystem will take to complete a task. The subsystem mapper is responsible for allocating the processes to the respective subsystems. The ASIM Complete triggers the ASIM module of the completion of the task. The Plot and Display modules in the dynamic simulation view of Figure 3 show the statistics for power, latency, activity and battery charge.

The MSV scheduler has the following tasks defined:

Figure 4. Tasks scheduled to MSV scheduler

MSV Task in Figure 4 displays a table where four different events are scheduled to an MSV scheduler. Each event corresponds to a range of orbits where the same sequence of tasks is repeated. ID=1 event would be active from orbit number 0 till the 250th orbit. Each orbit has a list of tasks shown in the Task_ID_Arr column.

Figure 5. Task ID table

Figure 5 contains the description of the tasks listed in the MSV table and matches the Task ID values. For example, Task ID=1 corresponds to the Telemetry, Tracking and Control (TTC) and Task ID=2 corresponds to the Image Capture. The table also contains the time within each orbit that the task will be triggered, and by the time in the orbit that the task might be completed. The duration of the tasks will depend on multiple factors including the processing time that will be different during charging and discharging times, availability of battery power, and access to resources.

Figure 6 shows the list of subsystems that are executed for a task to complete.

Figure 6. List of subsystems associated with each task

Several observations were made post simulation model. The tasks were executed at subsystems sequentially. There is another option to perform a parallel execution of tasks. The statistics for both sequential and parallel observations are studied.

Conclusion

This article discusses the background and modeling of cubesat — the overview of satellite operation in space, architectural insights of the model and how the model functions. The criticality of modeling lies in the fact that all the tasks should complete within deadlines. The failure detection and analysis at an early stage is necessary to eliminate any fault before integration in the real-life systems. It saves the cost, effort and time of the designer. Architectural exploration also will give an overall view of how the system is going to work. Various trade-offs and performance analysis will allow designers to reach the specified requirements.

This article was written by Deepak Shankar, founder; Tom Jose, Application Specialist; and Anupurba Mukherjee, Product Market Engineer, Mirabilis Design Inc. (Sunnyvale, CA and Chennai, India). For more information, visit here .