ADR-0100 - Phoenix as a Multi-Mission Sequencing IDE
Status
Accepted
Context
The Aerie project team was tasked by its primary sponsor, the NASA AMMOS program, to deliver enhanced multi-mission spacecraft sequencing capabilities to missions (this task has been colloquially called SEQ 2.0).
One of the highest-priority functions to deliver as part of SEQ 2.0 as determined by user research is "sequence integrated development". This is defined as
The user-facing function that enables sequence users to author, edit, statically verify, simulate, and compile command sequences through UI actions.
A number of requirements have been defined for this function. Some notable requirements are:
- Support for a variety of sequencing languages for FCPL, VML, cFS, and FPrime flight softwares
- Real-time validation against mission command dictionaries
- Interfaces to mission-defined compilation, static checking, and simulation services
- Review and edit the output of an automated sequence generation process
- Author and review reusable sequences or one-time bespoke sequences
A decision on the best path forward for the high-level architecture and technology stack for this function must be determined as the project moves into implementation.
Alternatives Considered
There have been a number of past and current efforts to develop sequence integrated development functionality. A number of alternative solutions were considered:
- Inherit an existing tool (e.g. Phoenix) and adapt it to be multi-mission
- Develop a new sequence development tool from scratch
- Develop a tool based on an existing IDE framework, similar to MPS Editor and MSLICE
Existing Tools
Many tools at JPL and NASA have provided sequence development capabilities. Below is a brief assessment of each tool:
| Tools | Description | Assessment for SEQ 2.0 adoption |
|---|---|---|
| Phoenix Editor | A web-based sequence editing tool already incorporated into Aerie originally developed to support a time-sensitive delivery for Europa Clipper (see ADR-0006). | - Originally designed for multi-mission use cases - Already relatively feature-rich and supports real-time sequence validation against command dictionary - Is heavily Clipper-focused, but expect that it can be expanded to support other missions - Can be run in the cloud - Can be expanded to support requirements listed in the summary above |
| MSLICE | A proprietary tool developing using the Eclipse framework for the Mars Science Laboratory (MSL) project and the Curiosity rover | - In-use by MSL, but is a complete planning and sequencing tool. Extracting just the sequence authoring function would be a signifcant effort - The Mars 2020 (M2020) project (i.e. Perserverence) decided not to adopt this because of significant maintenance and update costs and because it is not a web application, which would prevent tight integration with other M2020 tools |
| Sequencer | A proprietary sequence authoring tool developed by M2020 for M2020 that primarily uses an open-source library called Code Mirror on the backend. | - Very powerful and feature complete, but not designed for multi-mission and is intricately connected to other elements of the M2020 sequencing system. - Extracting just the sequence authoring functions would be more work than simply adopting the Phoenix editor - Starting from this tool was one of the paths considered when the effort to overhaul the Phoenix editor for Clipper was begun and the Aerie team made the decision to start from scratch in part because it uses an older version of Code Mirror (r5 vs r6) |
| ASIST | A real-time command and control system that provides an environment for the development, integration, testing, and on-orbit operation of spacecraft, their subsystems and instruments, as well as external control and support equipment | - In use at NASA Goddard but en-route to deprecation. |
| MPS Editor | A multi-mission Eclipse (IDE) framework provided by AMMOS in the past, used by many missions, and is now deprecated | - MPS Editor has been deprecated by AMMOS for the following reasons: - MPS Editor was challenging to maintain and keep up with newer versions of Eclipse (similar issue to MSLICE) - MPS Editor began to get unstable on recent Red Hat versions and the fixes/testing to stabilize it were non-trivial - MPS Editor is so old it had become extremely expensive to maintain. The build system was really challenging. An upgrade to a newer platform would liekly require a complete rewrite. Testing was also very expensive as the majority of testing was manual |
Of all the existing tools, our assessment is that the Phoenix editor is the best-suited for adoption.
New Custom In-House Tool
The path of developing a new, custom tool entirely from the ground up is worth considering if:
- Adopting and expanding an existing tool to meet requirements will take more effort than developing a new tool from scratch
- Adopting and expanding an existing tool to meet requirements will take similar or less effort to developing a new tool from scratch, but the adopted product is ultimately more difficult to maintain or less user-friendly than a new tool would be
At the time of this writing, our assessment is that the Phoenix sequence editor can be adopted, made multi-mission, and expanded with less effort than developing a new tool. The Phoenix editor is sufficiently user-friendly (it has received very positive feedbacl from Clipper thus far) and maintenance efforts are expected to be on par with any new tool that is developed from scratch. We have found no architectural issues with the Phoenix editor that would prevent us from adding the most critical features:
- Expansion to support sequencing for the Psyche mission (Psyche requires sequences to be imported/exported in legacy sequence formats like SATF and SASF), VML, cFS, and Fprime missions
- Interfaces to simulation service, compilation service, and static checking services
- Enhanced real-time static validation against command, parameter, and telemetry dictionaries.
Therefore, the team's assessment is to pursue adoption of the Phoenix editor over developing a new tool. However, we reserve this option as a fall-back if an insurmountable obstacle is encountered with the Phoenix editor, or if our assessment of any of the above criteria changes.
Customize Existing IDE
This approach has been tried with varying levels of success in the past and present. MSLICE and MPS Editor were both IDE frameworks. See the table below for an assessment of this option against adoption of the Phoenix editor.
| Phoenix Editor | Customize Existing IDE | |
|---|---|---|
| Usability | - Offers much more control over the user experience, because it is designed from scratch - User experience design can be directly catered towards sequence authoring | - User experience is constrained the experience provided by the chosen IDE - User experience will be adopted from software development/programming |
| Effort to Develop | - A Minimum Viable Product (MVP) is already in-use by Europa Clipper | - Would have to be developed from scratch, but likely much of the existing code could be ported into VSCode extensions |
| Editing Features | - Currently supports many required features for sequence authoring - No significant hurdles currently foreseen in adding other required authoring features | - Many desired editing features are provided out of the box: - Find/Replace - GitHub interface - Syntax Highlighting (although grammar would need to be defined) - Linting - Other general IDE features can align well in concept with required SEQ 2.0 features: - Running/Debugging → simulation - Compilation - However, while these features align in concept with required SEQ 2.0 features, actually implementing them may not be straightforward |
| Tech Stack | - Significant overlap in tech stack with existing Aerie functions. This overlap allows easy adoption of features such as Authentication and Authorization and file storage - A potential high risk is the reliance on the Code Mirror open-source library, which is currently maintained by a single developer. This risk is mitigated by the adoption of the library by large companies such as Microsoft. If the developer is not responsive or pauses developing the library, the Aerie team could take over maintenance and development or an effort could be expended to port the backend to Monaco | - No significant overlap with existing Aerie tech stack, meaning several features may have be to re-implemented, or new interfaces designed to existing features written |
| Maintainability | - Under our control when we want to update things- Parts of the app could still feel dated, but we can update at our own pace - All the work will be on the Aerie team to maintain modern feel - Aerie team is already familiar with CodeMirror | - Keeping pace with industry IDE version is very challenging - updating MSLICE from 3.6 to 4.0 took over a work year. MPS editor faced similar challenging keeping up with Eclipse versions - Keeping up with industry version is all that's needed to maintain modern feel (performance, user-friendliness of UI) - Team will need to learn new extension language rather than using CodeMirror or Monaco |
| Extensibility | - Initial assessment is that extending Phoenix editor to support VML, cFS, and Fprime is doable | - Can be extended to support other languages, but level of effort is unclear |
Decision
The Aerie team's assessment is that continuing to develop the Phoenix editor and extending it to meet additional requirements will require the least level of effort compared to all the other options and will result in the best end product for customers.
Consequences
- The greatest risk that we foresee with adopting the Phoenix editor is that support for the Code Mirror open-source library is lost, but this risk can be mitigated by:
- taking ownership of Code Mirror into Aerie or
- porting the tool to Monaco.
- Since Clipper already relies upon Phoenix, and enhancements will have to be made to support new requirements, there is a high probabilty Clipper will have to deal with breaking changes in new Phoenix releases. The Aerie team will work to limit changes and provide a high-level of support to existing customers when breaking changes are required