1. PLURIBUS Specification Properties Rudy, Peter N, Lennart, Laurence, Kang

2. 1. Stops functioning Bus unit stops functioning R&S stops functioning Stand stops functioning

3. 1. Stops functioning Team A: – bus unit stops functioning R&S will not update the bus position, and will not send message to bus stand – R&S stops functioning Bus stand displays the last known arrival times that are in the future – If there have been no updates from the R&S before, this equals the default time schedule – Stand stops functioning R&S keeps sending messages as normal

4. 1. Stops functioning Team B: – bus unit stops functioning: bus stands always displays the last estimates even if the bus unit cannot contact the server anymore If the bus has never sent any updates, there will be estimations in the R&S, and no time displayed at all for that bus – R&S stops functioning: For the bus stand the last known estimates will be used that satisfy this condition: – estimate + timeout > currentTime – Stand stops functioning: R&S keeps sending messages as normal

5. 1. Stops functioning Team C: – Bus unit stops functioning: Will be concluded when R&S can not send TriggerLocation back to the Bus unit. After a certain amount of resend TriggerLocation, retrying is stopped and alert is generated – R&S stops functioning: Will be concluded when BUS unit can not send messages to R&S. After a certain amount of resend message, retrying is stopped and alert is generated. – Bus stand stops functioning: Will be concluded when R&S can not send messages to bus stand. After a certain amount of resend message, retrying is stopped and alert is generated.

6. 2. Bus passes a single location several times Question: – What will be the estimated position when a bus passes a specific location that lies on a single route twice?

7. 2. Bus passes a single location several times Team A: – R&S does not use previous locations to determine the new position p of the bus on the route “most likely position” p can be ambiguous Estimates can be incorrect

8. 2. Bus passes a single location several times Team B: – Uses trigger locations to ensure that the bus unit sends critical locations when it passes them – Problem: posOnRoute does not get the last location or last estimate as input

9. 2. Bus passes a single location several times Team C: – Uses trigger locations to ensure that the bus unit sends critical locations when it passes them – Uses notion of direction – Problem: In determining the position on the route, it is not specified that trigger locations are used Use of direction is specified, but this is not enough to resolve ambiguity

10. 3. Time bounds How much data is sent between components? How do certain constants or functions influence this? And how do these affect latency and precision?

11. 3. Time bounds Team A – Every signal of GPS  Signal to R&S – Signal of bus /\ “estimate difference” > threshold  Signal to dispatcher, bus stand - Bus stands somehow have initial schedule

12. 3. Time bounds Team B – Every signal of GPS /\ (location = triggerLocation \/ time = triggerTime)  Signal to R&S – triggerTime is determined by the time the bus is expected to arrive at the next triggerLocation + triggerMarginTime – triggerLocations are determined and sent back by the R&S server The more trigger locations are given, the more data is sent – Signal of bus /\ “estimate difference” > estimateMarginTime  signal to dispatcher, bus stand – No initial schedule used, bus stands get first estimate once bus send the first update

13. 3. Time bounds Team C – Also use a trigger location together with a timeout. – Large output from the bus. Messages with be relative big. All the messages need to be confirmed. – There will be at least twice as many messages. What will happen if a system is down. – Will it keep sending new messages to the next system repeatedly?

14. 4. Flexibility of parameters Phone# changes Route or line changes

15. 4. Flexibility of parameters Phone number changes – For all x ‘elem’ {A, B, C}: Stored in dispatcher – Only need to change the information in the dispatcher

16. 4. Flexibility of parameters Route or line changes – Team A: Both in R&S Standard schedule in Bus stands – Changes to the route have more impact – Team B: Both in R&S – Team C: Line number in bus and R&S Standard schedule in Bus stands – Changes to the route have more impact

17. Conclusion There are a lot of good ideas specified – However, they have not been integrated correctly, if at all, in the specifications – It looks like people did not have enough time for this