Multiple employees on the same trip

[skyqrose]

On the MBTA Green Line, most trips require two operators, one for each car of the two-car train. It matters who's assigned to the lead car (driving the train) and who's in the 2nd car (just fares+doors). Each operator has their own run number.

Other agencies could run into this with operators+conductors, or any other situation where a trip requires multiple employees.

How would this be represented?

Some thoughts:

• Thankfully, there's no run_id column in trips.txt or deadheads.txt that would get in the way.
• It's probably okay if multiple runs in runs.txt have the same trip, but we should probably mention that explicitly in the docs, cuz it'd be easy to incorrectly assume.
• There needs to be some way to specify which employee has which job. A new field in runs.txt that describes the job/responsibility for the trip/event would satisfy that, and address Scott's comment here.

[timon-k]

Agree with the proposal, also with the idea to add the role/job of the employee in run.txt instead of in driver_assignment.txt (as discussed in https://github.com/cal-itp/operational-data-standard/issues/28). A certain run will be built for the specific role (also the pieces/events in this run).

Questions that I had:

• We may want to extend the enum values in event_type to account for task types like Fare Collection? Otherwise users would be limited to the imprecise Other.
• The runs.txt file does not yet exist, does it? I could not spot it under the hosted docs, nor in any GH branch.
• driver_assignment.txt should really not be called this way then. It should be personnell_assignment.txt or staff_assignment.txt or the like since it's no longer limited to drivers.

[skyqrose]

• What if event_type/job_type wasn't an enum, but was an arbitrary string? It would make it harder for a consumer to read a different agency's file, but to get meaning out of the field requires understanding how the agency works, so maybe the benefits to flexibility if every agency can describe their jobs how they want is worth it? Or there could be a middle ground of some officially recognized jobs, like "Operator" or "Fare Collection", but arbitrary custom names are also allowed?
• runs.txt is proposed in https://github.com/cal-itp/operational-data-standard/issues/51
• I agree, I'll go comment about the name on the other issue.

[jeffkessler-keolis]

I would highly recommend we make event_type a string, not only for custom names, but to support a number of cases with multiple employees where people can have varying roles.

One key thing that I want to clarify is that there is a need in the rail world to distinguish between the type of work ("activity" or "piece" type… in Hastus parlance, at least) being undertaken, and the type of the job itself.

Commuter Trains in North America typically operate with a Locomotive Engineer, a Conductor, and 0+ other employees typically dubbed Assistant Conductors, Collectors, Trainmen, Brakemen, etc.

Boston Example of Different Job Types

In Boston, each trip operates with an Engineer (performing Engineer work), a Conductor (performing Conductor work), and a "matched" Assistant Conductor (performing Assistant Conductor work). All three employees will have separate run numbers (e.g. Engineer = 201, Conductor = 401, AC = 601), but work identical trips on pieces of work aligning with their activity (e.g. trains 102-205-206-311-312-117).

Many rush hour trips will also have additional "unmatched" or "extra" Assistant Conductors who will work alongside the matched crew on certain trips, but not the matched crew's entire job (e.g. the above may be a straight job, but an unmatched AC may work 102-205-206 with the prior crew, go on a release/split, and then return to work 423-424-125).

(This is, of course, in addition to the concept that all four employees could be a "recrew" / en-route relief of another set of employees at the start/end of their assignments, or before/after a relief.)

Elsewhere in the Northeast

• Long Island Rail Road extends the above to have matched "Assistant Conductors" and unmatched [Ticket] "Collectors." Employees working Collector assignments not only don't work the entire assignment with their Conductor, they also generally don't work entire trips, supplementing crews on busier segments (think of an en-route relief, but the total number of crew members is ±1 after that point). There are also different CBA requirements for employees working Collector assignments.

• NJ Transit Rail Operations has Conductors, matched Assistant Conductors, and unmatched Ticket Collectors… but then they go a step further and sometimes have matched Assistant Conductors work a trip or two as an unmatched Ticket Collector while their Conductor/Engineer are on a break (these jobs denoted as AC jobs, with a note that "AC ALSO TC").

• SEPTA's through-running Regional Rail operation basically has the exact same concept, although most AC assignments aren't entirely matched, and some will join for only part of the journey.

Promotions

As if the above isn't crazy enough, there's then the concept of "promotions," generally the case when an Assistant Conductor who's qualified to work as a Conductor works part of their day as an AC and part of their day as a Conductor. This could be:

• Real-time / unplanned:
  • The employee working the matched Conductor job is out sick, so the promotable AC gets promoted to work their run for the day.
  • The employee working a Conductor piece of work has to leave early, so the promotable AC works the remainder of the assignment as the Conductor.
• Scheduled / planned[ish]:
  • The job is a Conductor assignment that has the employee work as an AC on trips for which they'd otherwise be deadheading / on a travel trip.
  • The job is an Assistant Conductor assignment that has them work as an AC for part of the day, then as a protect / work as directed crew member for the remainder of the day.

And just to wrap things up for good measure, down at Virginia Railway Express on our counterpart Keolis Commuter Rail operation in North America, we have crews who work "ACE" jobs, where they could literally be working as an Assistant Conductor, a Conductor, or an Engineer.

Implication

tl;dr We need a way to say, "this is a run," and then need to say within the run, "you're working the trip in capacity," but we do not need to assign multiple employees to the same run identifier.

…and rail is complex.

(This also relates to my "other" comment in https://github.com/cal-itp/operational-data-standard/issues/51#issuecomment-1861883775 about specifying an event_type alongside each piece within a run, which if a string could model the generic needs of the RR, @skyqrose's needs on the Green Line, etc.)

[skyqrose]

I've just opened https://github.com/cal-itp/operational-data-standard/issues/60 , which has job_type (optional) and event_type (required) fields, and should support everything discussed here.

Jeff, if that meets your needs, then we could close this issue.

[jeffkessler-keolis]

@skyqrose Okay to close per my comments in https://github.com/cal-itp/operational-data-standard/issues/60#issuecomment-1943001662

Thanks!