Calliope integration and testing is on hold until Spring break, possibly until Summer.  This is driven by two factors: my new job has me short on time, and InterOrbital's deadlines have removed a strong time pressure.  It's a good situation-- it's always better to have more time.

One aspect of my new job is presenting mission scenarios and case studies from Mission Operations.  I posted a key trade in my science blog, looking at explosive bolts versus springs from a risk point of view.  In retrospect, this column-- being about crunchy engineering topics-- may have been a better venue.

A key trade (or key tradeoff) is where you compare how two mission aspects interact.  The one most people know from daily life is a cost/benefit analysis, looking at where increasing cost (for, say, a nicer pair of shoes) balances against the benefits received (nicer shoes last longer).  There are usually three areas in a key trade.  At the very cheap end, there's usually little benefit.  At the very expensive end, there's usually very little added benefit.  But that middle area, that's where the tradeoffs get subtle.

Other key trades can include balancing innovation (adoption of new technology, say) versus the risk (chance of bugs or mistakes in use), aka innovation/risk.  Or you can balance cost/risk, risk/reward, performance/cost, performance/training, or just about any two things that a mission involves. 

Today, we'll look at a software cost-benefit scenario.  While that may sound a bit dry, it's an example of the sort of high-level decisions a mission operations lead may have to make, in the face of the usual imperfect information and unknown future.

Plus, it's a good primer for the alphabet soup of acronyms that we'll need to learn before we can tackle command and control for our own picosatellite.  Let us know enter the world of satellite mission operations.
 NASA image
Layout of a sample mission operations, image courtesy of NASA

Scenario:  A Mission named RENN is in its extended mission period and has to decide on whether to stay with a Commercial Off-the-Shelf (COTS) database or use an open source in-house database for a mission upgrade.

The (fictitious) RENN mission is currently in its extended mission life.  It has fulfilled its primary mission goals, and is expected to have from 2 to 5 years of useful life left.  It is in fact required to operate for at least 2 more years.  Because it is near the end of its mission, its budget is very small and cost savings are considered very important.

The RENN mission currently uses a proprietary Mission Operations Center (MOC) software package called PENUMBRA, provided by a corporation called Cyberdyne Systems.  PENUMBRA is a 'black box'-- whenever work needs to be done on it, you have to call in Cyberdyne.  However, it was available and tested and ready to deploy and has a good track record.  The license cost per year for PENUMBRA is approximately $200,000.

An outside vendor offers to develop an in-house alternative to PENUMBRA that they call SOTI.  SOTI uses an open-source protocol and has strong support from other missions, but has not been used or tested by RENN.  SOTI also addresses security concerns that have arisen during the mission but have not been fixed in PENUMBRA by Cyberdyne.  SOTI can also be supported by in-house RENN developers after deployment.

The argument for migrating to SOTI is that initial deployment adds a cost-- approximately $80K/yr for 2 years as an overlapping cost, then $40K/year in maintenance.  But once deployed, PENUMBRA and its license cost can be ditched, and it also addresses the security concerns.

RENN decides to commit $80K of the $160K dev cost towards SOTI, meaning they only need 1 more year of development (at $80K), then SOTI will be in place and able to run the satellite.  So we are looking at $80K in 'sunk costs' (money spent that can't be recovered), the intent of spending a further $80K to finish this, then for years 2 through the end of mission, only $40K/yr for using this database.

However, RENN then suffers cost cutbacks.  Further, Cyberdyne has offered a security patch and will cut the licensing fee on PENUMBRA to just $100K/year.

Question:  Staying with PENUMBRA maintains costs at $100K/yr.  Switching to SOTI requires they pay the remaining $80K to finish development while simultaneously paying for one last year of PENUMBRA ($100K), after which their costs drop to $40K/year as well as having a more secure standard they can support in-house (but which required RENN to switch vendors).  Should RENN continue paying $100K for 2-4 years for PENUMBRA, which works, or switch to SOTI?

Discuss key trades of Cost/benefit, Risk of new versus lack of support of old, switching vendors, and use of proprietary versus open source, as well as possible advantages of switching RENN as a testbed for testing SOTI for possible future mission use.

There is no right answer.  While this case is based on an actual mission, it is the discussion and nuance which is just as important as the final decision.

Until next time,
Building the Project Calliope home satellite to convert the ionosphere to music