The deployment of mega-constellations and smallsats in LEO is driving the democratization of space and changing how the data flows between the edge and the cloud.

In a 3-part series, we will cover how space computing is following in the footsteps of Industrial IoT by enabling autonomous decision making at the edge of the compute network:

  • Gen 1: The Recent Past
    • Human In The Loop (HITL) – Capture, Store, Forward…then Wait for Action
  • Gen 2: The Evolving Present
    • Human On The Loop (HOTL) – Capture, Store, Analyze, and Act – Space-IoTTM
  • Gen 3: The Future Intelligent Autonomous AI enabled Space-IoTTM
    • Human Out of The Loop (HOOTL) – Capture, Store, Analyze, Act re-Architect systems – AI enabled Space-IoTTM

Gen 2: The Evolving Present – Human On the Loop (HOTL) Generation

As we highlighted in the first post, space computing has followed Industrial systems in many ways and is continuing to evolve in similar fashion. In this post, we will discuss how Gen 2 systems had to evolve from Gen 1 due to two factors:

  • Quantity of data “captured and stored” growing due to more sensors being added to the mission.
  • Inability to guarantee the connection link to transmit the collected data to the ground station, as well as the need to reduce the data flow

This resulted in the system architecture changing into more change detection action and reporting along with more deterministic autonomy.

Example 1: Fixed Tasking Autonomy: Mars Rovers – These rovers are excellent examples of required remote tasking due to the incredible delay in transmission of commands between Earth and Mars, which is anywhere between four to 24 minutes each way. A lot can happen within those lengthy delays in communication, which is why remote tasking is paramount even for trivial items we take for granted such as image capturing or moving the rovers small distances. The Entry, Descent and Landing (EDL) of the Mars 2020 mission, also known as the “Seven Minutes of Terror” was the most stressful time of mission planning and execution, as during those seven minutes there is absolutely nothing that can be done to adjust or mitigate issues if things weren’t perfectly planned before tasking the activity.

Example 2: Fixed Tasking Autonomy: Kepler satellite – Yet another example of fixed tasking autonomy to enable the mission. While the Earth-Trailing Heliocentric Orbit of Kepler is not nearly as far away as the Mars missions, there are many reasons for remote fixed tasking autonomy. The sensitivity of the mission required this sort of fixed tasking to minimize impacts on the data collection and then periodically, pausing that data collection of the focal plane array staring at that Goldilocks zone to point the antennas at Earth to downlink the data for post processing. While not quite as stressful or exotic as the Mars missions, still a paramount case of remote tasking autonomy to achieve the mission goals.

Example 3: Fixed Tasking Autonomy: Mars Helicopter, Ingenuity – The first ever helicopter to fly on another world was yet another prime example of fixed tasking autonomy due to the reasons outlined above on the Mars rovers. Adding in further complexity of performing self-checks of “servo wiggle” as adjustments need to be performed due to variances in the Martian atmosphere density due to seasonal changes to ensure the rotors are spinning at the proper RPMs to ensure it can safely take off, fly, and then land again. Over the last six months, through the various phases of mission steps starting out on the very first mission to hover at ten feet all the way to mission nine going up to 33 feet and traversing over 2,000 feet, the Ingenuity mission has been highly successful due to the remote tasking further enabled by the countless hours of planning and simulations.

Gen 2 system share the same basic attributes we discussed for Gen 1 systems:

  • Avoid system level failure in the field
  • Do not assume a communication link is available between the Space-IoT Node and the base station
  • Use EDAC to assure system reliability

As such, the goals of Space Missions Computation for Gen 2 — Capture, Store, Forward, Act – Space-IoTTM — Collect data from all sensors, store onboard until over a ground station and then downlink to the ground for further post-processing. Whilst waiting to get an absolute response from the ground station, in parallel, analyze and act whether to execute a “deterministic autonomous maneuver” or “change detection monitoring enabled self-tasking/collection”, before actionable information has been received from the ground station. This is exactly what we saw in Industrial IoT.

And the Computing required to achieve these missions — On-Board Processing — OBP was leveraged to capture the data for further later analysis along with actionable information gathered from onboard change detection and collection in concert with both open loop and closed loop management of the satellite Avionics/Command & Data Handling (C&DH)/Data Management Subsystem (DMS) and Payload Subsystems.

In the third and final post in this series, we will discuss how Gen 3 systems will further reduce the data flow from the systems to the ground station, and enable fully autonomous systems and the corresponding revolution that it brings.

Get our free Whitepaper on why MRAM has a clear advantage in Space applications

Download Whitepaper