1. Changing the pluribus final A Ingmar Brouns Peter van Keeken Niels Reyngoud Lennart Kats Jeroen Zuijderwijk Team B

2. The original spec A Is very informal at points We do not want to respecify their complete specification (undefined functions, etc.) But we do want to make some changes Therefore we will also be informal at times

3. Challenge Cope with unexpected events – Change route on-the-fly Accidents Broken down buses Traffic jams Cope with expected events – Carnival – Queens day Keep as close to the original spec as possible

4. Problems Bus already in detoured part of route – Do not change all of this bus route – Only update bus route for coming buses and for the part which is still to come

5. The Operator Unit State: – Scheduled changes sched = [(Time, Route)] Output: – Route When current time equals the Time of one of times in sched, output the corresponding entry to the R&S and remove it from sched Changing the route back to “normal” requires another element in sched

6. R&SAS changes The ETAs type will be redefined as: – (LineID, [(Node, Time)]) The type of Route is now: – (LineID, [Node]) So we remove the initial absolute times from the Routes

7. R&SAS changes etas initialization: – Original spec: “Set of sequences ETAs as Routes (initial timetable)” – We will not be using an initial timetable, but use a ETAs with ‘zero’ times from a route: zerosEtas :: Route  ETAs This function either returns the existing ETAs sequence in the state of the R&SAS, or creates a new sequence with ‘zero’ times

8. R&SAS changes When calculating, – Original spec: “Using the Bus ID and current time, get the Line number nr and Route the bus is following” “For each Node in the current Route after p, calculate a Time by the remaining distance from p to that Node following the current Route, using the average traveling speed” – To calculate we do not use the Route from the Routes in the ‘given’, but use the Route from the ETAs of the bus – We thus define a function: etasToRoute :: ETAs  Route – This function returns the sequence of the nodes in the ETAs

9. R&SAS changes Extra input (from Operator unit): – Route Extra state information: – routes :: [Route] (used to be in the ‘given’) On input event (route r: (lineID, nodes)): – Determine the old route “oldroute” for lineID from routes. – disabledNodes = snd oldroute – snd r – routes := routes \ oldroute) U r – Update active etas of buses – Update no longer visited bus stands

10. The updated R&SAS Update active etas of buses (1) For each bus with etas e where e.LineID == lineID: – Wait until the bus is on an edge in the new r, then e = zerosEtas(r) zerosEtas takes the Nodes, and puts zeros next to them This only updates the old estimate etas, and does not send a message to the dispatcher

11. The updated R&SAS changing etas (2) new route old route zerosEtas is not called until the bus is at the new route

12. The updated R&SAS Update bus stands For each bus (busID) with etas e where e.LineID == lineID (busses currently on the route) – Wait until the bus is on an edge in the new r, then: – Send an output event (busID, lineID, arrivaltimes) to the dispatcher arrivaltimes is a sequence of (standid, arrivaltime). arrivaltime = “NEVER” for all nodes in disabledNodes which are bus stands. (according to team A: “For each Route also a relation Node to Stand ID.” )

13. The updated bus stands Schedule is removed from the bus stand, it’s not necessary to store it here. – Danger of duplication of information – Danger of inconsistency – Permanent changes of routes by the RS&AS is now possible