This section contains all the SIRI vehicle activity currently being sent from the SIRI supplier. 


 

This table makes it easy to identify what data is being sent from the supplier, and any issues that data may have.

 

For example; 


  1. If the vehicle activity was not able to be matched to a line - the references from the SIRI supplier do not match the “Network” → “Lines” section of Passenger Cloud, which is populated via TransXChange datasets. This can be resolved by:

    1. Updating your TransXChange to match what is being sent by the SIRI supplier

      1. The “Published line name” or “Line reference” columns must match the “Line name” field in TransXChange.

      2.  Changing operator codes requires careful consideration, see Managing operator code migrations.

    2. Updating the operator and line references at your SIRI supplier to match your TransXChange

  2. If the vehicle activity was outside of the operator bounding box - either the coordinates sent from the SIRI supplier are wrong, or the operator bounding box is too small.

    1. If the operator bounding box is too small, please contact help@passengerteam.com to have the it expanded.

 

Vehicle destinations


When viewing a vehicle in a Passenger app or Website, the destination of the vehicle can be displayed if the SIRI-VM feed and TransXChange data match correctly.

Passenger supports 3 options for vehicle destinations:

  1. (default) None - no destination name is displayed.

  2. Ultimate destination - destination name based upon the name of the final stop.

  3. Dynamic destinations - destination name based upon the journey and call data in the SIRI-VM feed.

We recommend that you review the data within Passenger Cloud, and then contact our Customer Success team to enable your desired option.

You can view the relevant details on the vehicle activity page for an individual vehicle activity.


Ultimate destinations


The SIRI-VM feed can provide a stop ID and/or destination name of the final stop in the journey, if both fields exist then the destination name will be used, otherwise, we look up a stop from your dataset based upon the stop ID


Dynamic destinations


The SIRI-VM feed can provide monitored call data - which describes a visit at a stop, by visit number, stop ID and destination display. This allows for the destination name to change along a journey, which is particularly useful for circular routes.

If the destination display is provided within the SIRI-VM feed then this will be used.

Otherwise, we fall back to destination data from your dataset. This requires that the vehicle matches a journey within your dataset. You can view the matched journey via the vehicle activity page, which lists details of the journey and visits.


The monitored call data from the SIRI-VM feed (the visit number + stop ID) is used to match to a specific visit. The following lists the order of the destination fields that will be used within your dataset, if defined:

  1. TransXChange DynamicDestinationDisplay

  2. TransXChange JourneyPattern -> DestinationDisplay

  3. Stop locality name

  4. Stop common name


Vehicle journey matching

 

You can view the fields used to match to journeys in the “Vehicle activity” table in Passenger Cloud.

Using these fields, you can compare the data sent from your SIRI-VM feed to your TransXChange to ensure journeys are matched correctly.

 

Fields

 

There is currently not a widely adopted industry standard for matching vehicle activity from SIRI-VM to vehicle journeys in TransXChange, so the fields (and how they are used) can vary depending upon the supplier, and both sets of data.

The “Journey reference” column is from the following SIRI-VM fields:

  • The MonitoredVehicleJourney → VehicleJourneyRef field

  • Else if the prior field was not provided the MonitoredVehicleJourney →FramedVehicleJourneyRef → DatedVehicleJourneyRef is used.

 

The “Ticket machine service code” column is specific to Ticketer SIRI-VM feeds, this comes from the TicketMachineServiceCode field.

The “Block ref” column from SIRI-VM is visible for all suppliers except Ticketer, this comes from the MonitoredVehicleJourney → BlockRef field.

 

Strategies

 

Each strategy is attempted in the following order, if exactly 1 journey is found then this journey is used, if none or more than one are found then we’ll move on to the next strategy.

Vehicles that are not operating according to a scheduled journey should not be matched, as the journey code entered into the ETM (and thus sent via the SIRI-VM feed), should not match your TransXChange.

 
Strategy 1 - Journey ref only

 

This strategy attempts to match the “Journey reference” field from SIRI-VM to the VehicleJourneyCode defined in your TransXChange for each VehicleJourney.

 
Strategy 2 - SIRI-VM PTI profile recommended strategy

 

This strategy follows the recommended strategy within the UK PTI SIRI-VM profile.

  • The OperatorRef from SIRI-VM must match either the NationalOperatorCode or OperatorCode fields within your TransXChange.

    • Note that we always require 1 to 1 strict matches of operator codes for journey matching.

  • The LineRef from SIRI-VM must match the LineName from your TransXChange.

  • The “Journey reference” column must match the VehicleJourneyCode defined in your TransXChange for each VehicleJourney.

  • The BlockRef field must match the Operational → Block → BlockNumber field defined in your TransXChange for each VehicleJourney.

 
Strategy 3 - Ticketer specific

 

This strategy is implemented for support with Ticketer feeds.

  • The OperatorRef from SIRI-VM must match either the NationalOperatorCode or OperatorCode fields within your TransXChange.

    • Note that we always require 1 to 1 strict matches of operator codes for journey matching.

  • The PublishedLineName (or LineRef if not provided) from SIRI-VM must match the LineName from your TransXChange.

  • The “Journey reference” column must match the Operational -> TicketMachine → JourneyCode defined in your TransXChange for each VehicleJourney.

  • The “Ticket machine service code” column must match the Operational -> TicketMachine → TicketMachineServiceCode defined in your TransXChange for each VehicleJourney.

    • If your TransXChange does not provide a TicketMachineServiceCode, we will attempt matching without it, which may result in us matching multiple journeys, and thus not selecting any. To resolve this please provide the field in your TransXChange.

  • The scheduled journey must be active according to it’s operating profile.

 

Ticketer have 3 distinct configuration options for DatedVehicleJourneyRef:

  

A. External Service Code and Started At - a combination of the service code and the actual date and time that the journey was started on the ETM. ServiceCode_JourneyStartDate_StartHours_StartMinutes (e.g. 603_20130416_08_06)

 

B. Inferred Journey Code – This is the Journey Code as entered by the driver in ‘hhmm’ (or similarly, scheduled start time as specified by the scheduled rota). If the driver did not enter a Journey Code, and there is no Journey Code in the trip rota definition, then the Journey Scheduled Start Time is used. This time as provided by the driver (or rota), unless it is not supplied, in which case it will the actual trip start time from the ETM’s clock.

 

C. Scheduled Trip Start (HHmm)

Ticketer recommends using option B for best results, if you are not currently using this configuration option you should contact Ticketer to get this updated.