Why Maestro?
2021-09-05
Maestro is an application being built at NASA JSC, providing painless procedure editing before and during spacewalks with shared situational awareness during execution. It solves a problem that no other tools address: handling detailed procedures that involve significant synchronization between multiple actors. Most procedures are purely serial: the same actor performs one step after another. Other tools involve multiple actors but still only model one step happening at a time. An entirely different set of tools manage high-level timelines, giving a big-picture view of what multiple resources are doing without diving into the details. For EVAs (Extravehicular Activities, also known as “spacewalks”, where astronauts in space suits work outside their vehicle) we write incredibly detailed procedures managing what multiple astronauts, robots, and ground teams are working on in parallel, with a far higher granularity than is possible with any timelining tool. Managing this complexity in Microsoft Word is, to say the least, difficult.
For over a decade I’ve been looking for a solution to the problem of efficiently building and maintaining these procedures. I’ve tried using spreadsheets and Google Docs instead of Word. I spent years working with TracLabs to make their PRIDE tool work for EVA (to no avail). I’ve considered ProX and asked for advice on Hacker News, but found nothing workable. I’ve been on this hunt all while doing my two jobs: EVA flight controller/instructor and software engineer/sysadmin. I’ve written many EVA procedures, suffering through the pain of Word, while also building software platforms that have greatly improved life at NASA. I’ve struggled to collaborate on Word documents with my coworkers who sit down the hall from me while easily collaborating on open source software with people half a world away who I don’t know. These two sides of my career have made clear the need for workflows that truly enable collaboration.
In 2019, I executed an EVA that had been in development for five years. In the final three months before the EVA we made more changes to the procedure than the prior five years combined due to misunderstandings between various disciplines and changes imposed by the ISS program. The difficulties involved with implementing these changes were substantial. As the EVA date approached I decided that post-EVA I would finally solve the procedure problem. I worked on Maestro as a side project for a while, and in April 2020 became lead of the new EVA Mission Systems Software team, who’s job is to modernize EVA operations. Maestro is one of the major projects.
Early development of Maestro brought about another important requirement: Flexibility. As stated previously, EVA procedures are very detailed and involve heavy synchronization between multiple actors. Requiring a procedure to have these two properties is essentially requiring it to be fragile:
- The more detail in a procedure, the higher likelihood that any one detail is wrong
- The more synchronization between multiple actors, the higher likelihood that actors will get out-of-sync during execution and some change will need to be made to the procedure real-time to re-sync.
To mitigate the inherent fragility of such procedures, those procedures must be flexible. During execution it must be possible to add, delete, and update the procedure on-the-fly. If an ordinary procedure editor must be easy-to-use, then an EVA procedure editor, where seconds matter and human life is on the line, must be exceptionally easy-to-use.
In summary, to answer the titular question of this post, “Why Maestro?”: Because EVA needs a way to create detailed procedures with extensive synchronization between multiple actors that can be edited so easily that the author won’t hesitate to make changes during execution in support of split-second decisions. Furthermore, Maestro must be able to quickly communicate these changes through the chain of command during execution, but also support review of changes in the months or years of planning prior to execution.