SIRI Update Results of the Meeting in Paris 03-22 and 03-23-2012

1. SIRI UpdateResults of the Meeting in Paris 03-22 and 03-23-2012 CEN TC278/WG3 SG7 Winfried Bruns VDV Participants: Nick Knowles, Werner Kohl, Christophe Blendinger, Christophe Duquesne, Gustav Thiesing, Daniel Rubli, Gerald Dury, Ulf Bjersing, Etinee Michel, David Lellouche, Andrej Tibaut, Mike Frumin (phone), Jeff Maki (phone)

2. Presentations • French Input: Results see attached document • Inputs from MTA / Mike Frumin 22.3. 3 p.m. • Inputs from Ulf Bjersing (Sweden) • SIRI-changes (Germany, Werner Kohl, Winfried Bruns,…) • SIRI-enhancements (Werner Kohl)

3. Decisions 24 November 2011 Changes have to be strictly backwards compatible with the existing version. Even turning an optional element into a mandatory one is not allowed (Except it can be guaranteed, that no one ever used it other than mandatory) Changes in the document should be restricted to the requested changes. A general revision (graphs or structure) is not planned. A lite version of SIRI will be developed. The Input from Michael Frumin is welcome. It will have to be decided if a communication layer is sufficient or if additional simple data elements (ex for dates) have to be provided. SIRI Lite should become a annex to SIRI part 2 instead of merging it into the existing parts 1-3.

4. Inputs from MTA / Mike Frumin • StopDistanceGroup • CallDistanceAlongTrip: the distance of the particular stop along the geographic route of the trip the vehicle is serving (i.e. from the beginning of the route) • DistanceFromCall: the distance from the vehicle to the stop along the geographic route of the trip the vehicle is serving • StopsFromCall: the number of stops between the vehicle and the particular stop. When the immediate next stop is the stop in question, the value is 0. • PresentableDistance: the human-readable string that UI’s can use to display the distance to users (e.g. in MTA’s application, changes from “X stops away” to “Y miles away” when the bus is more than 3 stops out, and changes to “approaching” when the bus is less than 150m away). This exists to allow various user interfaces to be consistent without copying logic between them. https://docs.google.com/document/d/1X-9Wpwks2EH80IQaxHjxWXC2zlITJxRId1bbymCdABs/edit • Decision: This seems to be a local solution • Inclusion of MaximumNumberOfCalls into VehicleMonitoringRequestPolicyGroup https://docs.google.com/document/d/1PZmBECPXxKEeprZOLrJ_cMH0xRii9LDJQx7J54zTboo/edit Decision: Accepted • SIRI for Simple Web Serviceshttps://docs.google.com/document/d/1fPUQ1vS6RUjci7EJY_Aaf-W_Ul38lY43INf8VETeE88/edit Decision: All paragraphs are accepted. Thank you for the work. Examples are welcome. In 3.7 there might be the need for some sentences on a key to identify the customer.

5. Inputs from Ulf Bjersing (Sweden), Mail 09/03/2012 • Update/correct/restructure SIRI WSDL-file.Solved by other changrequest • Clarify meaning of <VehicleMonitoringDelivery> <VehicleActivity><ProgressBetweenStops><Percentage>Annotation in document • The EndTime of the following structures must be redefined or better annotated so that it is clear when the time rangeends: • StructuClosedTimesRangeStructure • ClosedTimestampRangeStructure • HalfOpenTimesRangeStructure • HalfOpenTimestampRangere Decision: Only Backward compatible solution is possible. Add attribute to time structures? State that end value is exclusive? Alternatively have additional structure? Changing semantics will be the preferred solution, but has to be analyzed up to the next meeting. • Better support for describing real time track changes at stations in Stop Monitoring Delivery. Decision: Transfer StopPlace Model from IFOPT to SIRI? Alternative proposal from Nick for the next meeting? • Add Protected Connection element in Stop Monitoring Delivery Decision: Will be merged with Werner proposal • Other: Some minor typos were found in xsd.

6. Not in Document; in XSD accepted Accepted : SuggestedWaitDecisionDuration Accepted: prediction with and without wait time makes sense. Add new time element ProvisionalAimedDepartureTime

7. Not in Document; in XSD Accepted Accepted: ProvisionalPredictedDepartureTime Accepted: DeliveryVariant

8. SIRI-changes (Germany, Rubli) • CheckStatusResponse.DataReady is missing Decision:additional flag for CheckStatusResponse’ • ErrorCondition.ErrorNumber is missing Decision: accepted • CheckStatusResponse.ServiceStartedTime has to be mandatory • DataReadyNotification.ProducerRef should be mandatory • DataSupplyRequest.ConsumerRef should be mandatory Decision: Making elemtents mandatory would be not compatible with last version. The elements are important only when using subscription. That should be put as a hint in the document.

9. New inputs from the German mirror group 2011 • ViaPriorityNew element in theViaStructuretoindicate/ decidewhichinformationshallbeshowed, ifplace on a displayisrestrictedDecision: Accepted • New Elements PlannedStoppingPositionofthefetcherattheconnectionarea in MonitoredFeederArrival, MonitoredStopVisit,VehicleActivity and DistributorInfoGroupAccepted, See swedish comment • Velocity, optional element, format„Definition hastobeagreed on locally: actualspeedoraverage“ in VehicleMonitoringServiceVehicleActivityDecision: Accepted • Element WaitUntilDecision: AcceptedaddelementWaitingInfo in EstimatedTimetableandStopMonitoring • Additional optional Elements QualityofPrognosis in DepartureandArrivalAccepted; Proposalfrom Werner Kohl

10. German input (Werner Kohl) • Real time data platform demands for additional information: • Add element for recipient address/reference to each SIRI message. • Recipients address in the message, not only in the hostname (accepted) • Additional errorcodes in SIRI error condtions (Table3) (accepted, aslo input from France) • RecordedArrivalTime Add to estimated timetable service • RecordedDepartureTime Add to estimated timetable service • Production Timetable Service: Include information on vehicle journeys (feeder-fetcher) that have a connection protection process in place. • Estimated Timetable Service: Include information on actual and current connection status (Waiting, Broken connection) Decision: Proposal will be formulated and sent by Werner Kohl

11. Action Points Send WI Proposal to CEN (Pälen): WB check with CEN if SIRI part 4+5 are really adopted, change xsd in any case, may be document 4 m+5 later; Change request document from France. It is of 2011 and has not yet been dicussed The current version of the document is attached to the mail. Editors might change the things decide directly in the document with change track function and send it back to Nick.Knowles@trapezegroup.co.uk cc bruns@vdv.de New version of the document and the schema will be disseminated beginning of May Next meeting: Neuhausen, Trapeze, Switzerland June 18 2007 9:30