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)

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)

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.

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

VehicleMonitoringRequestPolicyGrouphttps://docs.google.com/document/d/1PZmBECPXxKEeprZOLrJ_cMH0xRii9LDJQx7J54zTboo/edit

Decision: Accepted SIRI for Simple Web Services

https://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.

Inputs from Ulf Bjersing (Sweden), Mail 09/03/20121. Update/correct/restructure SIRI WSDL-file.

Solved by other changrequest

2. Clarify meaning of <VehicleMonitoringDelivery> <VehicleActivity><ProgressBetweenStops><Percentage>Annotation in document

3. The EndTime of the following structures must be redefined or better annotated so that it is clear when the time range ends: 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.

4. 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?1. Add Protected Connection element in Stop Monitoring Delivery

Decision: Will be merged with Werner proposal

Other: Some minor typos were found in xsd.

Not in Document; in XSD

accepted

Accepted : SuggestedWaitDecisionDuration

Accepted: prediction with and without wait time makes sense. Add new time element ProvisionalAimedDepartureTime

Not in Document; in XSD

Accepted

Accepted: ProvisionalPredictedDepartureTime

Accepted: DeliveryVariant

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.

8

New inputs from the German mirror group 20111. ViaPriority

New element in the ViaStructure to indicate/ decide which information shall be showed, if place on a display is restrictedDecision: Accepted

2. New Elements PlannedStoppingPosition of the fetcher at the connection area in MonitoredFeederArrival, MonitoredStopVisit, VehicleActivity and DistributorInfoGroup Accepted, See swedish comment

1. Velocity, optional element, format „Definition has to be agreed on locally: actual speed or average“ in VehicleMonitoringService VehicleActivityDecision: Accepted

3. Element WaitUntilDecision: Accepted add element WaitingInfo in EstimatedTimetable and StopMonitoring

4. Additional optional Elements QualityofPrognosis in Departure and ArrivalAccepted; Proposal from Werner Kohl

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

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