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 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 MonitoredVehicleJourneyVehicleJourneyRef field

  • Else if the prior field was not provided the MonitoredVehicleJourneyFramedVehicleJourneyRef → 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 MonitoredVehicleJourneyBlockRef 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 OperationalBlockBlockNumber 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 -> TicketMachineJourneyCode defined in your TransXChange for each VehicleJourney.

  • The “Ticket machine service code” column must match the Operational -> TicketMachineTicketMachineServiceCode 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.