Agency: additional events

[lionel-panhaleux]

At the end of a trip or a maintenance, a vehicle may be unavailable.
The service_start transition signals the vehicle is available again, it can be used by programs operating 24/7.

Note this is missing a matching state machine diagram.

See #274

[marie-x]

Definitely addresses a need. Trying to be sure that this is the best way to address that need. Don't yet have a counter-proposal. Will consider with @whereissean and @toddapetersen.

[marie-x]

I have a counter-proposal. I think we should instead just add a transition from trip to unavailable via service_end.

[marie-x]

I wrote:

I have a counter-proposal. I think we should instead just add a transition from trip to unavailable via service_end.

Actually I have what I think is a full enumeration of the possibilities for resolving this, none of which I'm in love with:

1. leave as-is (decompose trip -> trip_end -> unavailable into trip -> trip_end -> available -> service_end -> unavailable with, say 1ms delay)
2. allow trip -> service_end -> unavailable
3. create new event trip -> trip_end_unavailable -> unavailable
4. use not just event_type but event_type_reason to determine the state change caused by trip_end
5. change state machine such that trip_end puts you into unavailable such that you need an additional service_start
6. variant on 1), decompose to multiple events with zero MS delay. pro: minimal change, zero time spent in available; con: requires some additional ordering method beyond timestamp (non-trivial)

I'm interested in how folks would rank these solutions, or are there others I've missed? @whereissean @hunterowens @lionel-panhaleux

[lionel-panhaleux]

If I had to grade these alternatives, I'd say:

• 2 is best because it is simpler. From an analytics point of view, a specific event reason would be nice (ie. technical_check, availability_check, or something similar).
• 3 is good enough, but slightly more complicated because it adds a new event
• 4 looks too tricky: a single events with two possible status seems bug-prone to me.
• Definitely not 1. The 1ms delay is problematic in some edge cases. Plus the vehicles will still be seen as available for 1ms (in analytics and compliance), although they were not.

[marie-x]

@lionel-panhaleux I just remembered there's a fifth option, added for your grading. Though in some ways is suffers the same inherent pathology as option one.

My problem with option two (trip -> service_end -> unavailable) is that it makes identifying the end of the trip harder, when generating Trips. OTOH we're already in a place where not all trips have trip_end; some effectively end with a trip_leave.

[rf-]

There's also another option, which is to preserve the semantics of option 1 (modeling a single real-world event as a sequence of trip_end followed by service_end) but with identical timestamps, so that the intermediate state is zero seconds long. This is more semantically accurate but means there would need to be some way to correctly identify the ordering of the events, which could happen a few different ways:

1. Allow some kind of compound event record that includes multiple sub-events
2. Add a sequence identifier that's separate from the timestamp and disambiguates the order of simultaneous events
3. Define heuristics in the spec that everyone can use consistently to identify the correct sequence based on event type, etc., when there are multiple simultaneous events

I'm not sure how appealing any of these options are in agency, or if there are other alternatives, but it would be nice to avoid the need for pseudo-events like trip_end_unavailable while still preserving each individual event's metadata.

[marie-x]

@rf- added to list. The three sub-options have new implications that we'd have to wade through. Each seems to add more complexity than it removes, seems to me.

[rf-]

Yeah, I'm not sure I find any of them super compelling, but that's also kind of how I feel about all the other options too. The core idea—having a relatively small set of events, allowing them to stack up on the same timestamp (consistent with the normal rules about state transitions), and then leaving the vehicle in the state indicated by the last event—seems like it has some nice properties, but I'm not sure anyone has come up with the right way to deal with the sequencing problem yet.

[CLAassistant]

All committers have signed the CLA.

[Retzoh]

I can follow up on this

[HenriJ]

2020-01-09 WG meeting:

• Add a new event trip_end_unavailable <- E&A, BlueSystems, Dirk
• Maybe a new "reason-like" field ?

Morgan: should be a minor version because it's adding something ?

[Retzoh]

Until #422 is solved, there is no versioning on the Agency API.
So for now, I feel any of the following changes would be breaking:

• add a trip_end_unavailable event_type -> agencies with old implementations would miss trip ends.
• add a reason to trip_end deciding the status -> agencies would still get trip ends but the device would be in the wrong status.
• add a state -> one of the two changes above is still needed since states are not explicitely sent in agency events.

[Retzoh]

@sarob as explained in #274 , this PR should be moved to the 0.5.0 milestone.

[marie-x]

Propose we close this in favor of the Provider/Agency reconciliation project

[schnuerle]

Ok closing this per the recommendation above in favor of the now completed reconciliation work.