Long-term designs ideas for daily ops cycles

[JoelCourtney]

Right now, Aerie’s planning and scheduling workflow is heavily inspired by Clipper’s needs, which has a long ops cycle and long activity plans. This means that Clipper’s planners are usually going to use scheduling goals to produce many activities in recurring patterns, rather than creating goals that only produce a single activity. Unfortunately this would be pretty unwieldy for missions like M20, which makes heavy use of singleton ungrounded activities in the planning cycle. Here are some design ideas that could make that easier, as inspired by COCPIT and COPILOT. They’re presented roughly in the order they would need to be implemented, so the selling points are at the end.

(This is not about onboard planners, as that is a fundamentally different kind of scheduler that we don’t have yet.)

(already planned!) Scheduling procedure parameterization

We’ll need to separate scheduling procedures into two concepts, “implementations” and “invocations”, and let the user specify arguments for the procedure similar (or even exactly the same) to activity parameters. This would allow goals to take ungrounded activity instances as parameters, if/when #1294 is merged.

(click to expand the most hare-brained idea I’ve ever had)

Our activity parameter system has been mostly sufficient so far, but it might be a bit restrictive for scheduling parameters. For example, in the eDSL Coexistence goal we can specify an activity parameter to be a profile, and its value at the activity start time will become the grounded parameter. This would be a very powerful capability if we could do something similar for activity and procedure parameters. Technically, we could pull this off by reusing the eDSL, and I think that would absolutely work, but I think I have a better way.

The timeline library is written in Kotlin. Kotlin has the ability to transpile to javascript, not just compile to the JVM. With fairly minimal refactoring to use only the Kotlin standard library, we could ship the timeline library for both languages, and allow activity/procedure parameters to be timeline expressions that use the exact same API as the procedure internals. Relatedly, we could also completely replace the eDSLs this way, with a unified library for both JVM and JS. But as cool as that would be, I’m not sure its realistic.

Scheduling analysis rework

Instead of scheduling analysis just reporting whether a goal is satisfied, we could instead record the activity conflicts generated. This would essentially be how we represent ungrounded activities. To do this, we would need a couple things:

• eDSL goals must never simulate before producing the final set of conflicts (I don’t know if this is the case already)
• Procedures that produce conflicts instead of grounded activities do not have the ability to simulate. They should have control over whether simulation is used to solve those conflicts, but can’t do it themselves.
• Procedures that produce grounded activities would either not be run during scheduling analysis, or would be run up until the first simulation request.

Provide a single-activity goal archetype (“SingletonGoal”)

This one is pretty self-explanatory. Juan has already talked about this in the past. Having a pre-made procedure implementation that produces an activity relative to another, and is configurable by parameters, would go a long way for short-ops-cycle missions. Whether it could be configured to consider resource conditions is another discussion; see my “hare-brained idea” above. It would produce conflicts instead of grounded activities, so that it would be run with scheduling analysis.

Let goals that produce conflicts remove their own activities

Right now, no type of goal or procedure can remove or edit activities that are already grounded. I think it isn’t too controversial to allow procedures that produce grounded activities to edit the plan in other ways; they already have the training wheels off, I think they should be able to do whatever they feel they need to, whether it is a good idea or not. That’s not the fun part though.

It could be very useful for procedures that produce conflicts to optionally remove activities that they themselves have already placed. As in, when the procedure has already been run but the plan was later changed, the procedure should be able to delete its old results and place them again. I think this would need to be configurable, as some procedures wouldn’t want that.

It would be tricky if these procedures always removed and replaced their activities on every scheduling run, because they could self-interact. For example, if the procedure makes a conflict because of a resource condition, but the grounded activity resolves the resource condition, then every other scheduling run would result in the activity being removed and not replaced. I think instead a sounder way would be to only remove the old activity if the procedure is still unsatisfied even when the activity is there.

This would be very useful for singleton goals. If they detect that they are unsatisfied but are only supposed to produce one activity, they should replace the old activity instead of making a second.

Render scheduling analysis results as ungrounded activities

I don’t know what this would look like exactly, as I am not a UI designer, but it would be very helpful to see roughly where to expect activities to be placed, rendered alongside the grounded activities. This would help the users keep a rough image of what the plan looks like, even if most of the activities don’t actually exist yet. Obviously the results of scheduling analysis are approximate, and could be different if simulation is used in the middle of the scheduling run.

UI Shortcut for creating singleton goals

The last step to make this really seamless would be to let planners create singleton goals graphically in the UI, just like they create grounded activities. This would go a long way to make it feel you’re creating an ungrounded activity, rather than using the complex scheduling system to represent one. Users should have some way to edit the procedure parameters by interacting with the rendered conflict from scheduling analysis.

(Optional, but very cool) Parallel execution with simulation / resource streaming

The timeline library is compatible with streaming instead of reified lists. It uses lists for simplicity for now, but with a moderate rework it could be turned into a system for composing stream processors, instead of operations that transform lists. (It would probably be a lot more efficient too.)

I’ve heard several times that it would’ve made more sense to integrate constraints with the mission model and simulation, rather than being a separate step. Well, if we get resource streaming in simulation, we can automatically run constraints and scheduling analysis in parallel with simulation, processing the results as they are streamed out of Merlin. This would keep the rendered activity conflicts almost instantly in sync with simulation.

[JoelCourtney]

As an alternative to the hare-brained idea for allowing resource conditions in procedure parameters, we could maybe use scheduling conditions to achieve a less-flexible but still helpful version.

• Allow scheduling conditions to be applied to specific scheduling procedures instead of all procedures / goals.
• Implement the UI procedure editor for procedural scheduling like we have for eDSL goals (already planned, post-MVP)
• When creating a singleton goal, give a shortcut to create a procedural condition, pre-populated with a template that will apply the condition to the singleton goal you are creating.

On one hand it doesn't quite have the full power of allowing JS timeline expressions in parameters, but on the other hand it isn't mad.