ConOps

ConOps is your concept of operations, occasionally called OpsCon. Mission Operations exists to perform normal operations and resolve anomalies. Operations has four core functions: call them Commanding, Monitoring, Trending, and Science. The Mission Operations Center (MOC) handles commanding the spacecraft and assessing the status of the spacecraft via HK data, as well as trending. The capture and archiving of the science data is the responsibility of the Science Operations Center, or SOC. The MOC and SOC can be the same entity, it’s just that one deals with the satellite bus, the other with the instruments and data. From the hardware view, your satellite consists of a bus + payload. These deliver three streams of data, shown here with the uplink and downlink elements:

Uplink can be via one or two antenna ground networks. Housekeeping (HK) data goes to a Mission Operations Center (MOC), while science data goes to a Science Operations Center (SOC). HK telemetry is usually frequent and small; science telemetry is usually of larger size and therefore often less frequent.

The comm system may be one antenna or two (or more), relaying to the MOC and SOC appropriately and handling the uplink. Health and safety and science data may also use the same or different frequencies, depending on your ConOps.

There are many different architectures, ranging from one ground station, one frequency, one satellite to multiple ground stations, in-orbit satellite relays, multiple frequencies, one satellite.

For commanding, the SOC usually relays their requests to the MOC. For small missions like ours, the SOC and MOC may be the same entity—or even the same person.

In addition to communications, your ConOps should indicate who is telling you where your satellite is. Make sure someone is providing ranging and flight determination information and sending it to your MOC.

Good operations involves a team, each tracking a different aspect of the mission. Even if your team is one person, you are generally looking at only one aspect of the information flow—health of the satellite, quality of data, whether commands are being sent—at a time.

Some typical roles are the mission operations manager planner; scheduler; comm lead; bus monitor(s); and science monitor. Here’s one set of typical roles:

Mission Operations Manager (or MOM)

The person leading operations. They may just boss other people, or they may also handle a role below, but everyone needs to agree who is in charge.

Scheduler

You need someone in charge of making overall mission schedules and detailed activity schedules, of scheduling data link times, and of overall planning. The three short-term components they track are when the next data downlink will occur; what the next set of planned commands will occur; and when the next command uplink will occur.

Comms

Getting the data, processing it, and ensuring it goes to the right people is the next seat. Typically Comms will be making sure the telemetry is flowing, and also in charge of hitting the button to send any commands at the proper time.

Bus Monitor

This role analyzes the HK data and assesses the status of the satellite and its subsystems to ensure everything is working with designed tolerances. They assess whether the mission is alive or in trouble.

Science Monitor

This role checks that the quick look or actual data is valid and what is desired. They assess whether the mission is succeeding in its goals.

Navigation

If your satellite has active position control, either in attitude (facing) or orbit (maneuvers), someone in Ops should be in charge of tracking this.

SysAdmin

Maintaining your hardware and software is the final required role. They need not be in Ops all the time, but be sure someone is on top of your actual ground station hardware and software to ensure you are up and running when you need to be.

While any of these seats/roles can be filled by one or more people, it is important to realize the breadth of tasks required for operations. There is no one standard way to set up operations. Your team may just be you or a small group of friends, but understanding roles and responsibilities will lead to better operations.

High-Level ConOps Design

Your satellite might just be a free flier, tumbling through space with no active control. You might have a pulsed plasma drive and be changing orbits to head for the Moon. In all cases, you need to examine whether your satellite needs any commanding or operations needs due to its inherent limits. Some sample limits (constraints) that might need to be considered are:

• The instrument’s target visibility

• Solar angle (between solar panels and sun)

• Moon contamination in FOV

• Angle to bright Earth limb

• SAA passages

• Star tracker limits with respect to the sun, moon, and bright Earth

• Contact pass availability and telemetry requirements

• Time-critical and phase-critical observation windows

• Telemetry limits, contact passes, and downlink

Pulling this together into a schema, then, you can define your ConOps as:

• Spacecraft choice, payload design, operations and flight software, navigation and control

• Commanding needs: duration, frequency, complexity, automation

• Data return needs, monitoring and trending, science needs, automation

• Team, skills, ability to resolve anomalies and faults

The first part of your concept of operations involves assessing your mission needs, the resources you can bring to bear, and the items you’ll need to develop. All elements of this book feed into the ConOps—deciding what your mission goal, type, and target are define the satellite. The orbit defines its accessibility.

Next, you create assessments on how risky your mission is. Add to this the level of expertise of your people—how much experience each part of the team has in its area, and whether they have done this before.

Now assess resources—are you using established, mature software or new code? Is your development period long, or short? Is your hardware mature, or untested? Are you inheriting software or hardware from other missions, or creating from scratch?

Resources often involve compromises. Are you designing custom software or hardware to exactly fit your mission (requirements-driven), or are you using existing off-the-shelf solutions and making your mission work with their capabilities (software-driven/hardware-driven)?

Choose your physical locations. Do you have space for your MOC and SOC? Do you have support partners who are not located in the same building? Are you using an existing ground network, comm network, tracking network, or are you building your own? Draw a map of your physical facilities and how they are networked for trading data and email and communications. Include time zones, if you have more than one facility.

Next, tackle the timing. Work out how often will you need to command the spacecraft and how often will you need to downlink data. Evaluate if your solution can support this—if not, either redesign your solution or rescope your mission goals. If you are planning on automated operations, again, assess whether this exists and is mature, or still has to be developed (and whether you have the expertise).

To assess timing, list a typical set of daily (or whatever interval) items that need to be built in to the command loads (i.e., maneuvers, commands, data downlinks, types of events, calibration requests, etc.). Include an example of a typical duty cycle—the steps and intervals going from a request to an action carried out by the spacecraft.

Any implementation involves trade-offs, called “key trades.” Key trades can include comparing cost versus benefit (cost/benefit), complexity/risk, speed/flexibility, development cost/operations cost (aka money now/money later), longevity/costs, longevity/complexity, and others.

Trending

A primary job of the MOC is validation of whether the satellite is working as specified in the requirements. Validation is determining whether the satellite is functioning as designed. Connected to this, verification is determining whether the mission is succeeding in its goal (usually determined by the science or technical leads). Together, they form V&V (validation and verification).

Trending is simply keeping track of the satellite over a long period of time, particularly for items that may be changing. It has several functions.

1. Predicting spacecraft performance

2. Assessing health of the spacecraft subsystems by trending

3. Tracking the use of consumables such as propellant, coolant, etc.

4. Assessing actual spacecraft performance against design goals and requirements (V&V)

5. Maintaining spacecraft parameters that may need changing or adjusting

6. Making inputs to mission planning regarding future spacecraft activities such as calibrations

7. Sometimes, validating stored commands

8. Often, maintaining flight software

Telemetry analysis, with short- and long-term trending, can find errors in all subsystems. HK trending can deduce the performance levels of the battery charge/discharge cycles, the thermal changes in the spacecraft, and the functioning of the power system. Science trending can help with instrument calibration. Navigation trending finds attitude errors, pointing problems, and propellant.

With CubeSats, it’s easy enough to assess the trends just by eyeballing the data. Ideally, your HK data should be stored in a database so you can do a trending analysis at any time (“Hey, when did this battery charging problem first appear?”). This allows you to plot data over time as graphs. Formal trending tools and automated reports are standard in better operations centers.

Science Operations Center (SOC)

Science operations concerns itself with the instrument and payload data. It assumes the satellite bus is working and doesn’t really care about things like contact passes or the satellite is overheating. It just wants its data. The SOC goals and requests are fed to the MOC, and the SOC receives the MOC’s results. The SOC is the entity that validates the mission—the MOC can tell if you if everything is working as per specifications, but only the SOC can tell you whether the mission is meeting the purpose for which it was launched.

In terms of security, the SOC rarely has direct contact with the spacecraft, and does not send commands. Instead, they send their requested commands to the MOC, who are the only entity that can actually control the spacecraft. For a distributed project with many users, the “SOC” is the user base, and the “MOC” is the people operating the satellite. For larger missions, the SOC can act as a liaison or buffer between the MOC and data end-use customers. Because they are focused on the mission, the SOC often coordinates high-level strategic and tactical mission decisions as well.

The SOC team follows similar processes as the MOC and requires high fidelity on input (command requests in particular) to the MOC, but the SOC requires less fidelity than the MOC for real-time monitoring. A failure at the SOC won’t kill the satellite, just cause less optimal performance.

In order to produce science, tasks or observations must be proposed, coordinated and scheduled, and carried out. Then, quicklook and production data must be delivered to the users or scientists. In addition, the performance of the instruments over time must be monitored, trended, and adjusted. As drivers of the mission goals (while the MOC is focusing on the mission execution), the SOC often takes a lead in creating the schedule of what to do next.

The basic concept of scheduling is simple. You take a list of goals, experiments, or targets, and make a calendar. The three main factors to consider are calculated quantities (i.e., unchangeable facts of the situation), derived quantities (soft constraints, ratings of good and bad events, and politics), and capacity constraints (such as time and telemetry).

For mission scheduling, the general calculated quantities are based on the platform. For satellites, this includes sun angle, orbital position, Earth limb angle, roll angle, and others. For ground-based units, several analogs are day/night, latitude/longitude, and elevation angle. These have no particular weight to them, but are simply physical facts about the observing situation.

From these, we create the derived quantities, which determine whether a given task or observation is feasible. This includes (for satellites) issues like allowable sun condition, occultation, thermal profile, in-SAA region, bright/dark Earth, ground-station contacts, and star tracker acquisition. Some of these are functions of the calculated quantities, and others are qualitative opinions based on the calculated quantities. Some derived quantities can be entirely political, and imposed from the outside (scientific priority, for example).

In particular, CubeSat capacity constraints include, first and foremost, time, generally defined as “you can only do one one thing at a time.” Telemetry is a large concern for satellites, and other user-defined resources vary from mission to mission. Tracking all of these is the principal task of scheduling; that is, to place targets such that no constraints are violated and all resources are used to maximum efficiency without overbooking. The goal is ultimately to maximize the scientific routine.

So tools to manipulate this output not just “a schedule,” but also an evaluation of its overall suitability (and stability) for the problem at hand. The interface must present all the quantities above to the user when hand-editing is required. Finally, the automatic scheduling routines (ranging from simple “good time bad time” limiting, to AI routines that make sequences) must interface with the editing options available to the user.

A good mission scheduling system can take user requests like turn this on tomorrow and dovetail it with other user requests (like take a space selfie of me!), fold them together so there are no conflicts, then actually generate the command sequences needed for delivery to the MOC. The MOC then checks that out, compares them against their own mission needs—especially contact pass times, which aren’t under anybody’s control—and builds the actual command strings that have to be transmitted to the satellite.

None of the SOC’s criteria for a decision are necessarily the MOC’s concern! The MOC must execute the SOC’s provided schedule, but it is not the MOC’s call as to whether it is a good, bad, safe, or risky schedule. The MOC should evaluate the SOC’s proposed commands for safety—to ensure they don’t overdrive the satellite or break something—but not for whether it’s worth doing. Pragmatically, especially for small missions, the two groups will talk to each other, but the formal difference between the two is worth keeping organizationally to ensure decisions made are well informed:

Science 'not good enough' ->
      new operations modes suggested ->
              SOC builds new command sequences & macros ->
                       SOC validates ->
                               MOC validates for limits only ->
                                       MOC uploads

Handling Anomalies

Anomalies are when something behaves different than expected. Most anomalies are considered a problem, which means the problem has to be either dealt with or ignored. Anomalies introduce risk. Recall that you cannot eliminate risk, only minimize, mitigate, or accept it. As the picosatellite industry matures, failures should, in theory, be reduced—but we’re also always aiming for higher achievements.

The process for ground testing of hardware and for resolving in-flight anomalies are the same. There are no perfect solutions, and decisions often have to be made on the basis of partial information. It’s just that on the ground, you have a lot more data and you can fix things by hand. The fundamental rule in anomaly resolution is that an anomaly, no matter how complex, has one and only one cause. The corollary is that multiple failures don’t occur unless they cascade from a single root cause. Most anomalies can be resolved without changing operating modes. If anomalies indicates danger to the spacecraft’s health, command it into a safe haven. If in doubt, abort the current operations and safe it.

Availability analysis looks at mean time between failures (MTBF) and mean time to restore (MTTR) where availability is A:

A = MTBF/(MTBF+MTTR)

(e.g., MTBF = 400 hrs and MTTR = 2 hrs → A = 0.995). In other words, over the course of 1 year such a system is unavailable 16.7 times for a total of 43.8 hrs! Fun fact—a survey of 13 spacecraft over 2 years indicates anomalies occur about every 7 months of spacecraft operations. Statistically, then, even the most robust spacecraft should expect at least one anomaly. For CubeSats, built fast and cheap, expect more.

The core of resolving anomalies is root cause analysis (RCA). You can get very deep into formal techniques. One is formal failure modes, effects, and criticality analysis (FMECA). In this process, before launch you define conditions and constraints for each component, define what constitutes failure, and assign probabilities and severities. From this you can predict many anomalies before they happen. In CubeSats, most people do not have the staff depth nor experience to do this in detail. So we go to diagnosing anomalies as they happen.

Now that you’ve saved…

1. Get all the data. All.

2. Establish accurate timing and sequence of telemetry events.

3. List possible causes.

4. Analyze data and find the cause (look for single points of failure, construct a failure tree).

5. Determine the corrective action.

6. Carry it out (take your time, verify each step, do no harm).

A sample failure tree for “magnetometer not recording” could be:

• Not getting voltage

• Component damaged

• Connection to CPU down

• Software not reading it

Multiple failure trees can help drill down to a single cause. You need to determine if additional analyses or spacecraft HK data are needed to define the root cause. Once you determine the root cause, then (and only then) are you ready to start looking at ways to solve the anomaly and restore normal operations. Normal operations—in fact, boring operations—is the goal of any well run Mission Control.