Allocating drivers and vehicles in ODS

[hodb]

In reviewing the ODS spec, it appears that there is an absence of guidance regarding the allocation of blocks to operational vehicles, as well as the assignment of duties to drivers with their matching operated dates

As this crucial information is expected to be sourced from the dispatching software, can you provide clarification or additional details on how the ODS spec addresses the extraction of data related to block allocation, driver duties, and associated dates from the dispatching software for communication to the AVL provider?

Thanks

[skyqrose]

Matching operators to their duties on each day is something that I would use, and if it's not in ODS, I'd have to represent the data in a non-standard adjacent data feed. I'm currently using a CSV with 3 columns for this purpose: date, run_id, operator.

But it's also kind of separate from the schedules ODS does represent. For example, assigning operators to runs is done well after the rest of the schedule is finalized.

I think I remember this coming up in discussions a while ago and I think it was just cut for scope. It'd be easy to add as a backwards-compatible extension once the rest of the format is finalized.

[hodb]

Thanks for your answer @skyqrose. The concept I aim for is pretty much the same - having a new file driver_assignment.txt that includes the assignment per driver -
run_id,driver_id,operational_date

And a vehicle_assignment.txt file that includes assignment per vehicle
block_id,vehicle_id,operational_date

[safrazier17]

I think I remember this coming up in discussions a while ago and I think it was just cut for scope. It'd be easy to add as a backwards-compatible extension once the rest of the format is finalized.

Yes, this was discussed and cut for scope and also because there seemed to be less consensus on the topic of representing driver/staff-identifying information, at least at that time. I remain in favor of bringing this information into ODS, however.

For example, assigning operators to runs is done well after the rest of the schedule is finalized.

Can we be clear about what the intended use case is here? I want to make sure I understand who is producing these assignments and who the consumer will be. If the run assignments are done via the same producer after the schedule is finalized but before it would be sent to the schedule consumer, that wouldn't seem like it would impact our decision to include those assignments in the ODS-represented schedule. But I want to be sure that's an accurate read of what you both have said.

[skyqrose]

At MBTA, the use case is to export data from HASTUS and distribute it to multiple internal apps using a standard format, instead of the status quo of each app getting a custom export in a custom format. (This data would probably also make it outside of MBTA to Swiftly, but that's not my side of the house so I'm not sure.)

So far, exporting the trip schedules and exporting the operators' schedules have been completely separate processes, and exporting operators' schedules for each season typically happens a couple weeks after the trips.
If we didn't have this proposal, we would keep doing the separate operator export alongside ODS.
If we did, then I think we would publish an internal ODS feed without operator schedules as soon as the trips are scheduled, and then re-publish an updated ODS feed with operator schedules once those become available.

Does that answer the question?

[skyqrose]

Depending on how the issues with non-unique run_ids go (see #12), it's possible that the drivers file would need to have a 4th column for the service_id. If runs are unique among all the services effective on a date (but not unique among all services), it wouldn't be necessary, but could still make looking up the run easier.

MBTA hasn't run into this specific uniqueness problem yet with our current use cases, but I expect we would if this file was standardized and we used it in more places.

I'm not sure if our block_ids are unique, but I guess the same problem could happen in principle to the vehicles file.

[hodb]

Can we be clear about what the intended use case is here? I want to make sure I understand who is producing these assignments and who the consumer will be. If the run assignments are done via the same producer after the schedule is finalized but before it would be sent to the schedule consumer, that wouldn't seem like it would impact our decision to include those assignments in the ODS-represented schedule. But I want to be sure that's an accurate read of what you both have said.

Adding on top of @skyqrose's answer. The dispatching software and the AVL vendor might be different. This creates a scenario where we are unable to communicate through the same format and are required to examine each vendor's unique specification which includes different data elements. From the customer's end, if they're using two different systems in place, they are required to manually do the allocations in both the dispatching and the AVL software, which can be inefficient. If we don't include the actual assignments in the ODS format, we would be able to convey information about the runs/blocks but not the dispatching portion. Extending ODS for including assignments, creates a clear path for clear communication between two different software providers

[safrazier17]

Question re: proposed driver_assignment.txt file

Would it be reasonable to say this same use applies to personnel more broadly (that is to say, not just to drivers/vehicle operators)? Does the job performed need to be identified in the new field? Or will it (always) be self-evident from the operator id what job they are performing?

Trying to get at whether we need to make our language more job-agnostic and how we can either support other roles or at least bake in some extensibility for that support in future

[safrazier17]

As proposed, would we be imposing a limitation that a driver's run assignment would always be for the full run. Is that desirable? Would it make sense to include the piece information in the file as well?

[safrazier17]

Some questions on proposed vehicle_assignment.txt:

• are there different types of assignment we need to account for?
• how do we account for the same vehicle being assigned to multiple blocks on a given date? or the same block assigned to multiple vehicles?
• is there a case where a block might be assigned no vehicle within the schedule, and instead only assigned on the day of operations?
• do we need a master list of vehicles that vehicle_id can pull from? [we also have add Vehicles.txt  #30, which currently doesn't have a vehicle_id field but should.]

one more q for driver_assignment.txt

• would it make sense for this assignment to be made between an operator and a bid instead to individual runs? with the bid representing a package of runs/pieces during a specific window of time?

[skyqrose]

I think that this file could apply to other jobs, if they have run ids, which seems very possible.

You can't determine job based on operator id, since some employees might do different jobs on different days. But you can determine the job based on run id. And if you want a run_id to job_id mapping, then that'd be better to do in runs.txt than in driver_assignment.txt. So I don't think it should go here, but we should consider it there.

Edit: On second thought maybe run_id isn't enough, because an employee could do multiple jobs within the same run, e.g. operator in the morning, then shifter in evening, so it'd have to go in runs.txt.

---

Yes, this would limit assignments to a full run. I think by the definition of a run, that's okay. If you plan to assign multiple operators to different pieces of the same run, then those are really two separate runs.

If you don't plan to assign multiple operators, but end up having to because you're filling absences or if an operator has a half-day conflict or something, then that's not necessarily going to align to piece boundaries, and it'd require a way to specify assignments per trip, which is way more detail than ODS should have and is a step away from schedule data towards realtime data so is out of scope anyway.

---

(no comment on vehicles)

I don't think we should associate operators to bids instead of runs+dates. If we did, we'd need a separate way to map bids to runs to runs+dates, and every lookup would have to go through that level of indirection. It'd also make it impossible to reassign people on individual days, for example if vacation dates are chosen after bidding. The important operational detail we want to capture is which employees are working, and the bidding process is just an administrative detail to get there that doesn't matter if we have the end result.

[hodb]

Would it be reasonable to say this same use applies to personnel more broadly (that is to say, not just to drivers/vehicle operators)? Does the job performed need to be identified in the new field? Or will it (always) be self-evident from the operator id what job they are performing?

Trying to get at whether we need to make our language more job-agnostic and how we can either support other roles or at least bake in some extensibility for that support in future

It could be extended, but what is the use case for associating another personnel that is not performing a run?

As proposed, would we be imposing a limitation that a driver's run assignment would always be for the full run. Is that desirable? Would it make sense to include the piece information in the file as well?

It is fair to say that a duty/run can be "cut" and split between different drivers. In that case, we would need to have some unique identifier on how many pieces the duty is split between drivers and on what date (which we have already). Since a duty might repeat itself every day but on a different date. For instance - 1/3, 2/3, 3/3).

Some questions on proposed vehicle_assignment.txt:

• are there different types of assignments we need to account for?
• how do we account for the same vehicle being assigned to multiple blocks on a given date? or the same block assigned to multiple vehicles?
• is there a case where a block might be assigned no vehicle within the schedule, and instead only assigned on the day of operations?
• do we need a master list of vehicles that vehicle_id can pull from? [we also have add Vehicles.txt  #30, which currently doesn't have a vehicle_id field but should.]

one more q for driver_assignment.txt

• would it make sense for this assignment to be made between an operator and a bid instead to individual runs? with the bid representing a package of runs/pieces during a specific window of time?

• I don't think we should have additional assignments for vehicles, but it depends also on the receiving end (the AVL) to elaborate on whether there is another use case from their side.
• We can add a unique identifier to the number of pieces a block is worked on by different vehicles (same as proposed for the duties).
• I assume no vehicle assigned is possible, due to maintenance and such. In that case, we would need a real-time aspect to inform the AVL of the change in allocation (this goes a bit further)
• I proposed the vehicles.txt as an option for the AVL provider to be in sync with the information the dispatching software has. The advantage of using this file is to have a complete sync between the list of vehicles the dispatching software holds and the AVL provider. How often is a vehicle being added or removed from the fleet? on the same note, perhaps a drivers.txt file would also be valuable

[safrazier17]

Separating out the different discussion threads here:

• Driver vs job-agnostic personnel assignments

• Rows in this file could be applicable to any personnel that has a run assignment. This will often, but not always, be an operator.
• @skyqrose has provided examples of multi-personnel trips/runs in Multiple employees on the same trip #54
• Proposal in that issue is to designate job performed within runs.txt rather than in driver_assignment.txt
• Further discussion on this can go to Multiple employees on the same trip #54

• During scheduling, will a driver always be assigned to a full run?

• Difference of opinion here:
  • @skyqrose says yes, scheduled runs should be assigned to 0 to 1 personnel
  • @hodb says it is possible that a run would be cut in such a way that we need to allow for 0, 1 or many personnel assignments
  • ultimately I believe this is a question of how we approach the normative power of a data standard. We can (1) normatively state that a single run is assigned to at most one person and that agencies using ODS will have to adhere to that, even if it means changing a run nomenclature they have used in the past, or (2) seek to be able to represent a wider array of use cases that exist in practice, even if they do not adhere to the typical definition of a run
• [Sky brings up the case of having to make post-scheduling adjustments that result in more than one operator on a run. I agree that this case is out of scope for ODS and doesn't need further consideration]
• This question should perhaps go out to the full working group

• During scheduling, will a vehicle always be assigned to a full block?

• Much the same applies here; we seem to have the same options as to whether we allow or disallow the blocks to have multiple vehicle assignments or vice versa
• Hod proposes similar approach as for above

• Assignment types for vehicles

• Sort of fishing but also a genuine question: might a schedule assign a revenue vehicle to something other than revenue service (be it, idk, standby, relief, or what have you)? Could that or should that be able to be represented as a block?
• Hod says he doesn't think this is necessary; I'm inclined to agree at this stage unless we receive other feedback

• Block with zero vehicles assigned

• The important point here is whether we end up in a situation where we have a complete list of blocks in the scheduling system, but only a subset of those blocks is captured in ODS, leaving the consumer app with an incomplete list or description of blocks
• Is there a case where this would happen? How would agencies handle this if they were scheduling during an operator shortage, for example? Is it possible that a defined block would not be assigned a vehicle until, perhaps, day-of (and thus not in ODS)?

• Personnel link to bids instead of to jobs?

• Sky argues against this as it would obfuscate the information that the consumer actually cares about: the specific work being performed by the operator
• this seems like a convincing argument to me, unless we receive other feedback

[skyqrose]

Going back to comment on vehicles:

• On MBTA Green Line, vehicles are assigned day of. I just wouldn't use vehicle_assignment.txt, or would leave Green Line blocks out of the file. Consumers should be able to handle blocks without scheduled vehicles (and also runs without assigned employees, which also concretely happens in our data).
• Having an inventory of all vehicles would be useful. Caveat: For trains that are made of multiple cars, what I really want is an inventory of cars, which doesn't directly correspond to a vehicle in the realtime data which is a full train. (This doesn't apply to bus.)

[safrazier17]

Ok, that makes sense. As it stands in GTFS and ODS, blocks are defined in trips.block_id and/or deadheads.block_id, so even if a block doesn't have a assignment in vehicle_assignments.txt, we still can have a full definition of what that block's contents are. I'll mark Block with zero vehicles assigned above as resolved

[timon-k]

For the train use case, wouldn't we then also need multiple vehicles assigned per block (analogously to the multiple employees per run)?

It also could include a new (optional) field order_in_driving_direction so that the order of cars becomes clear if the provinding system knows it.

We can also ignore this for now, but I think the specification needs to make some statement on
assignments of multiple vehicles to a single block, because technically, users will be able to do that in the proposed format. We should clarify expectations here (explicitly allow or disallow).

[skyqrose]

As mentioned in another issue, driver_assignments.txt is likely to end up containing more than drivers. staff_assignments.txt would be more generic.

[skyqrose]

If we want to allow multiple operators on the same run / multiple vehicles on the same block, maybe it's as simple as not enforcing any uniqueness guarantees on these files?

The order_in_driving_direction couldn't apply in this file, because a operator/vehicle is likely to be in a different order on different trips (like if a train turns around and the first car becomes the last). But maybe it could work in runs.txt?

[timon-k]

@safrazier17 @skyqrose This issue is currently marked as "Included" in ODS 2.0 here, but I don't see a final proposal of how to add the new files.

Also, the discussion about driver allocations was split off from this issue above, but there it states that the driver assignments should be in the new run_events.txt file - I cannot spot any reference to drivers or staff there. So it seems to me, that we still need to discuss both driver and vehicle assignments as part of this issue?