Event Relative Planning #467
Replies: 11 comments 90 replies
-
Event Relative PlanningUse cases@bashbash:
E.g. rover ops: the "decisional downlink activity" "anchors the plan" Our Scheduler allows placing activities relative to other activities and resource behaviors, but this information is lost when When the "anchor" shifts for some external reason - users would like associated activities to shift along with it. @JoelCourtney: should shifting be the responsibility of the scheduler? @JoelCourtney: shifting could be more complex than just "move over by time delta" - in which case the scheduler would need to be involved @Mythicaeda: Do we want this to be automatic? Scheduler run shouldn't be automatically triggered @lklyne: Parent-child relationships between anchor/anchored activities. Any parallels with decomposition? @JoelCourtney: Does the scheduler produce anchors? @bashbash: "Epochs" are parameters in flight software. An Epoch is a name associated with an absolute time value.
Activity A occurs 5 mins after Activity B @JoelCourtney: Can an activity be an event? (Yes) @Mythicaeda: Events may have durations (@JoelCourtney concurs) Onboard epochs assumed static (known without simulating) Inputs to simulation:
@bashbash If we start by limiting scope to relative to start time only - if the duration is known, you can use start time + offset @JoelCourtney two subproblems:
@bashbash: biggest difference between events and activities is visual treatment @camargo An activity directive is an event, but an event is not necessarily an activity_directive @Mythicaeda: plan merge with events? @bashbash: should be like activities Command expansion use case (lower priority than the other use cases): Epoch relative sequences are written using Command expansion doesn't need to know what the epoch is in this case - but, if we want to generate Command expansion logic should be given the information that this activity's start time is relative to an event. Epoch-relative sequences are useful for re-using sequences. Expanded sequences, on the other hand, are not meant to be re-used. @adrienmaillard : we can encode all the relationships in the scheduler with the current design Next steps:@mattdailis and @Mythicaeda : start a data model design |
Beta Was this translation helpful? Give feedback.
-
Notes from discussion with @mattdailis: Goal: Delta = (start + offset) and when anchored to an end time offset = duration + delta Events as Activities: Activity_directive could have a Events as Events: Example Situation: A start time depends on B start time. Recursive query to get absolute start time of A Potential Returns for the Absolute Start Time Query: Preventing a Cycle: In the interest of homogeneously representing “unanchored” and “anchored” activities - both will have start_offsets of type interval - “unanchored” activities’ start_offset will be implicitly relative to the plan start. For plan start time changing, if the activity is unanchored, we change the delta = negative delta between old and new start time. (Meaning the activity stays at the same absolute time.) |
Beta Was this translation helpful? Give feedback.
-
Had a discussion with @JoelCourtney. Key points from it are:
|
Beta Was this translation helpful? Give feedback.
-
I don't expect this to go over well, but can I petition to reconsider referring to these as "events"? We already have a distinct concept of event in the simulation realm; most people are already familiar with the concept of "discrete event simulation", and these do not appear to be those kinds of events. I've heard this concept referred to as an "opportunity" by other domain experts; I vaguely remember the term from Cassini, and the SOA software is literally called Science Opportunity Analyzer. It sounds like Clipper probably does call them "events". That's fine, but since different missions may call them different things, we're going to be putting somebody out a little bit no matter what we do. On the basis of multi-mission software and unambiguous communication, I think it's at least something worth discussing. For full disclosure, CCSDS 529.0-G-1 does include a concept of "planning event" -- see Section 4.10 in particular, which seems to be a very worthwhile read. But it seems to be much more general, as a kind of "condition" on which an activity occurs, and which may just so happen to have some temporal variance under uncertainty. Moreover,
I'm definitely going "out of scope" with the following, but if we do think our concept of event-relative planning is an instance of the concept described by this document, then it might illuminate our discussions to understand what this vision might look like in our setting. (@patkenneally knows this as my "understand more than we solve" tactic.) (Also, I've been instructed before that the existence of a CCSDS-defined term does not require us to follow the same nomenclature. It's informative only.) |
Beta Was this translation helpful? Give feedback.
-
Matt and I brainstormed a little recently, and I think I'm much more sympathetic to the idea that these "events" are related to input activities. However, I think that they're actually a manifestation of plan structure rather than plan content. The below is my attempted synthesis of what we've all been discussing here; I'm not claiming everything is original, I just want to pose a way of thinking about this problem that may suggest a solution. (EDIT: I just wrote 1.5k words. I am so, so sorry. 😅) Plans are trees, not listsA plan as we currently know it represented as a list of activities, each with a concrete start time. I think it's important to keep in mind that this is a representation of the domain concept of a plan, and not the canonical source of what it means to be a plan. At a domain level, a "plan" is our literal plan of attack for achieving some goal. (That's why the scheduler and the whole planning process is important, of course -- we want to come up with a plan of attack, and then refine it to better meet our goal.) Our representation manifests as a restriction: the kinds of plans we can achieve with our system are merely those where we know precisely what to do and precisely when to do it. In this discussion thread, we're talking about kinds of plans that we cannot handle -- at least, not conveniently. Users want to be able to plan relative to some other feature, which itself may vary; and if it varies, we want the activities to consistently occur at the right time. We could require users to manually reposition activities and keep track of which activities are "morally" relative, but I think it's very fair to say that this is a workflow that Aerie should support better. After working through these thoughts with Matt, this seems to me to be a very clear signal that our vocabulary for describing plans is not expressive enough. In this thread, we're all aware that the Instead of talking about "event-relative planning", let's just talk about "relative planning" as a whole. We've known already that we want to be able to plan activities relative to other activities; it seems reasonable to bring that deficiency into scope as well. What does it mean to plan "relative"? The concept of "anchors" came up before, and I like it: an anchor models a time point against which other entities may be positioned relative, and which may itself be determined relative to some other anchor. Every activity is planned against an anchor, and in turn defines two more anchors: its start and end anchors. Now, let's consider the totality of anchors and relationships between them in a plan. Surely it's a tree, right? An activity cannot be anchored to two anchor points at once, so every anchor has one parent; and we want everything to ultimately be relative to the plan, so there cannot be cycles. If we identify an activity with the start and end anchors it generates, then the activities themselves are organized in a tree. Thus, we really ought to think of "relative planning" in terms of moving from our list representation to a tree-like representation. But when we're talking about events, some of the anchors do not originate from an activity in the strict sense. Where do these come from, and how do we specify them? One school of thought says that, since planning events could also be considered to have a durative extent, and hence also start and end anchors, we should literally model them with activities. I am not unsympathetic to this idea, but it leads to the question of "where is the activity defined?", and I refuse to implicate the model in owning such a definition, sorry :) But I think there are still options along this line that don't implicate the model. In my mind, events are meaningfully different from activities, for one very specific reason (and maybe others). We know that negative offsets are problematic for the As an example, here's an example plan (cooked up by Matt) with relative scheduling, and a tree formulation of the plan with my own random syntax. I've visualized events with the notation
And this leads to my proposed earthshattering revelation: Events aren't activities; they're plansOr plans are events; I'm not really too hung up on "is-a" analysis here. What I mean is: we already have a notion of "thing with duration against which activities are scheduled", and it's literally a plan! We already have this capability! Right now! An activity is not, actually, scheduled against an absolute time. It is scheduled against an offset from the plan start. The plan itself already acts much as a "root event" for relative planning. (This means we ought to think about "plan end" as a viable anchor. Why not, right??) All that we're missing is the ability to nest one plan under another. If we model events as plans, and give plans the ability to nest, we can open up a whole world of possibilities.
Incidentally, I remember from my time at Cassini that part of the job of coming up with a planned sequence was meeting with all of the science teams, sorting through their planned sequences, and working with them to integrate them into a sequence that was actually achievable. If two science teams proposed activities that conflicted, the sequencing team had to get one or the other to give up their request (e.g. by giving them priority next time) or to reduce the scope to something that could work with everyting else going on. This strikes me as a great example of a workflow that plan nesting would support very well. The individual teams propose their own plans within the opportunities given by the mission, and then there's a collaborative back-and-forth until the master plan meets goals and flight rules. |
Beta Was this translation helpful? Give feedback.
-
Something that occurred to me when Jonathon mentioned "moving our representation from a list to a tree" -- Would it be useful to have a UI panel that shows this anchor-tree breakdown? Maybe using a directory-like visualization? |
Beta Was this translation helpful? Give feedback.
-
Adding few responses here: Our definition of events is very similar to "planning events" from the CCSDS blue book. CCSDS suggests more features which don't know how valuable. CCSDS defines data model of events almost identical to activities both having types and instances. We do not follow CCSDS too closely as it suggests specific implementation and design which we already diverged in many ways, or suggests a design that is very custom or specific. In short, we validate the need for event relative planning based on CCSDS, but I don't see much else to extract from there. Happy to share the doc if anyone is interested. Instead of thinking event as a plan, treating "plan start" and "plan end" as events is another option that we discussed. Activity directives and events represented as a tree seems like a natural conclusion based on multiple discussions here and offline. |
Beta Was this translation helpful? Give feedback.
-
Trade Study (work in progress)Below, we would like to enumerate our various design directions and evaluate them against the same criteria. I will edit this top level comment based on any discussion below. Criteria:
The Activity Groups feature could be implemented on top of all of the below. The Events as Plans would be a bit different Numbering is for reference only, and not meant to impose an order. 1. Annotation Processor generate Event as an activityNotes:
Pros:
Cons:
2. Add an Event activity on mission model load (close to interface)Notes:
Pros:
Cons:
3. Define Event as an activity by clients of the mission modelNotes:
Pros:
Cons:
4. Events as PlansNotes:
Pros:
Cons:
5. Events as a new primitiveNotes:
Pros:
Cons:
|
Beta Was this translation helpful? Give feedback.
-
Based on discussion with @bashbash and @mattdailis, this is the current proposed path forward: Step 1) Introducing activity-directive-to-activity-directive and activity-directive-to-plan anchors.
Step 1b (Can be delayed)) Allow anchors to be created in CoexistanceGoals (and ReoccuranceGoals)
Step 2a) The user can chose certain activity types to be drawn as "events" (or, to go with a closer variation to @Twisol's proposal, the user can customize how certain activity types are drawn.)
Step 2b) Introducing a new activity type named "Event" (or "Marker" or whichever name we decide on)
Step 2c) As a UI convenience feature, the database will maintain a table correlating Mission Model IDs with possible
Step 3) Introduce excluding specified activities (potentially activity types) from simulation
|
Beta Was this translation helpful? Give feedback.
-
I was on vacation for this, but I wanted to see if I understand it. I'm filling in some blanks for myself, so please let me know what I got right/wrong. There are questions, too. Short/curt/rude answers are very welcome in this case--I don't want to burden the team.
|
Beta Was this translation helpful? Give feedback.
-
Oops, I meant monotonic, not non-monotonic. I'm going to edit my comment above to fix. |
Beta Was this translation helpful? Give feedback.
-
This discussion is a placeholder, to be filled in at the working group on Monday.
Here are the preliminary designs for this new feature: Event Relative Planning - v2.pdf
Related issues:
#429 #449 #450 #451
Beta Was this translation helpful? Give feedback.
All reactions