The EPPER application was developed for the French catering firm Servair to manage their personnel assignment for the restaurant and bar services in the TGV Atlantique. This TGV service runs from Paris to Rennes, Nantes and Bordeaux and continues to other stations along the different lines, see the route network below.
At the time of development (1996), there were around 220 train services per day on that network, and the catering was handled by 350 agents with different qualifications. Each planning period covers a four week (28 day) time span.
Each TGV unit has a bar station, where passengers can buy food and drink from a catering agent.
There normally is also a trolley service, and on some trains a restaurant service serving meals in first class. On some routes, two TGV units are coupled together, doubling the number of required catering personnel. Agents can have multiple qualifications, but will be typically assigned to work corresponding to their highest qualification.
All agents are based in Paris, where they clock in and out at Gare Montparnasse. This dramatically simplifies the problem, as we do not have to assign activities to crew depots, as it is customary with airline or train crew rostering problems. At the same time, it creates operational problems in order to cover all services from and to Paris from that crew station.
The application is based on the published train schedule, which also defines which services must be delivered. In a first step, trips starting and ending in Paris are generated from the timetable. Most of these trips cover a simple return trip, although there are some more complex trips (Paris-Nantes-Lyon-Nantes-Paris). If the outbound trip starts late in the day, then there is no possibility to return to Paris on the same day, the agent has to stay overnight at the destination. He can then work on an early morning train back to Paris, which could not be covered by an agent starting from Paris on that day anyway. In principle the number of possible pairings is very large, but this is much reduced by work regulations, which state that a strict first-in/first-out rule should be applied for return trips. By defining good pairings we can reduce the waiting time at the destinations, thus improving overall productivity.
Once all the required services are covered by trips, the second step of the application consists in assigning the trips to agents over the 28 day horizon. The usual rules apply:
- Each agent should have a certain number of days off, including some weekends in each planning period.
- There is a lower and upper bound on the number of days worked consecutively.
- Minimum rest periods between trips must be respected.
- The total number of hours worked in any consecutive period must be legal.
- The work in progress from the last planning period must fit with the new work plan.
- People may also be pre-assigned to other duties like training sessions, and can be assigned to the operational reserve, covering unforeseen events like illness or accidents of other agents.
The main objective of the scheduling is to create a balanced work plan for all employees, while covering all trips with the minimal number of agents. Each agent should have similar total hours of work, required overnight stays, short and long trips, etc. Extreme rosters with too much or too little workload must be avoided, the tool should appear “fair” to the agents.
The image below shows part of the user interface. It shows the train list connecting Paris with Nantes. It is important to note that relatively few trains run on every day, often the weekend timetable is quite different from the Mon-Fri services. And even the services on the week days are differentiated, there are for example extra trains on a Friday. More exceptions are caused by public holidays and special events, when extra trains are run to handle the passenger volume. In that case it can be quite difficult to balance the trips to and from a destination, and some agents are dead-heading (are not required to cover a service) on one leg of the trip.
To learn more
This post is based on a presentation of A. Dubos (Cap Gemini) and A. Du Jeu (Servair) at the 1996 CHIP Users’ Club meeting. The screen dump of the application is from the EPPER prototype application developed at COSYTEC.