Avtale om digitale tjenester - ADT 2.x

Ruters digitale plattform

This specification contains interfaces to be used between PTOs (operators) and Ruter. The API describes a set of MQTT topics which are used to distribute data onboard public transport vehicles/vessels as well as between the vehicle/vessel and Ruter’s Back Office or vv.

General information

Upgrades to the API

The API follows the upgrade cycles of ADT. Major releases are done more or less once a year and usually include breaking changes.

Minor/build releases are performed as continual deliveries and are non-breaking. New versions of this document will be published when new topics and/or fields are added.

Consumer Client Requirements

Clients consuming information posted on the topics must be tolerant to:

  • That optional properties can be null or left out.
  • That arrays can contain any number of elements including zero.
  • That returned data can be extended with new properties without notice.

Quality of Service, Retained Flag and Persistence

Generally, QoS level 1 is applied for most topics and the retain flag is true for most topics. See the respective topic for precise info.

Subscribers should start with Clean Session set to True to assure that they get the latest information at reconnection (the retained info) and avoid first having to process a long queue of outdated old information that in reality hinders new relevant information to reach the subscriber.

Translation of topic names

Global topic names are generally written on the format of {recipient}/{sender}/{vehicleid}/{topic} to make it easy to identify the source and destination of the messages. Local topic names have omitted the {recipient}/{sender}/{vehicleid} part in order to have onboard equipment pre-configured with vehicle independent settings.

All topic names must thus be rewritten local/global in the MQTT bridge according to a provided configuration file.

Data format

All data must be JSON and UTF-8 encoded.

More info

For more information, please go to: Ruter’s ADT agreement.

Comments or suggestions

Please open an issue here: ADT-DOC Issues

Servers

  • mqtt.transhub.iomqttmqtt.transhub.io

    Ruters central MQTT broker

    port
    required
    string

    The mqtt broker is available through TCP (:8883) and Websockets (:9883)

    Default value:"8883"
      Allowed values:
    • "8883"
    • "9883"
    Security:

Operations

  • PUB di/assignment_attempt/block

    AssignmentAttempt Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/di/assignment_attempt/block
    Schema assignment-attempt.json

    Describes an attempt to sign on or off a block from MADT, another GUI or from the PTO backoffice. The result of this request will be confirmed by the PTA backoffice and the results presented either on the topic ruter/{PTO}/{vehicleID}/oi/current_ block/state or the topic ruter/{PTO}/{vehicleID}/di/assignment_attempt_rejection/block.

    Specifications

    AttemptType AssignmentCode Required Description
    SIGNON PLANNED
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • blockRef
    • fromDateTime
    • The vehicle is assigned on to the block matching the provided blockRef and fromDateTime
    • If the vehicle is already assigned on another block, the preexisting assignment gets unassigned
    • The current block will contain only stops departing after the supplied fromDateTime
    SIGNON EXTRA
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • blockRef
    • fromDateTime
    • The vehicle is assigned on to the block matching the provided blockRef and fromDateTime
    • If the vehicle is already assigned on another block, the preexisting assignment gets unassigned
    • The current block will contain only stops departing after the supplied fromDateTime
    • The current block will contain only the first journey matching fromDateTime in the planned block
    SIGNON REPLACEMENT
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • blockRef
    • fromDateTime
    • The vehicle is assigned on to the block matching the provided blockRef and fromDateTime
    • If the vehicle is already assigned on another block, the preexisting assigment gets unassigned
    • Any vehicle, not marked as EXTRA, assigned to the the provided blockRef will be unassigned
    • The current block will contain only stops departing after the supplied fromDateTime
    SIGNOFF FINISHED
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • The vehicle is unassigned from any existing assignment.
    • Note that the unassignmentis effective immediately.
    • The field fromDateTimeis optional and thus not honored
    SIGNOFF BREAKDOWN
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • The vehicle is unassigned from any existing assignment.
    • Note that the unassignmentis effective immediately.
    • The field fromDateTimeis optional and thus not honored
    SIGNOFF CANCELLED
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • The vehicle is unassigned from any existing assignment.
    • Note that the unassignmentis effective immediately.
    • The field fromDateTimeis optional and thus not honored
    SIGNOFF SHORTENING
    • apiVersion
    • assignmentType
    • assignmentCode
    • vehicleRef
    • The vehicle is unassigned from any existing assignment.
    • Note that the unassignmentis effective immediately.
    • The field fromDateTimeis optional and thus not honored

    Accepts the following message:

    Assignment Attempt Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/driver-interaction/assignment-attempt.json

    Describes an attempt to sign on or off a block from MADT, another GUI or from the PTO backoffice. The result of this request will be confirmed by the PTA backoffice and the results presented either on the topic ruter/{PTO}/{vehicleID}/oi/current_ block/state or the topic ruter/{PTO}/{vehicleID}/di/assignment_attempt_rejection/block.

    Examples

  • PUB di/override_attempt/destination_display

    Destination Display Override Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/di/override_attempt/destination_display
    Schema destination-display-override.json

    Accepts the following message:

    Destination Display Override Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/driver-interaction/destination-display-override.json

    Describes a request from MADT or other GUI to manually override the information shown on the destination display. It is up to the presenting system to decide how and for how long the override will apply. A rule could be until next journey begins or a new override_attempt/destination_display is received. The topic could be blanked (provided with a zero-byte payload) to indicate that any overriding information is no longer valid and that the destination display can return to normal

    Examples

  • PUB oi/vehicle/unique_identifier

    Unique Identifier message:

    Field Value
    Central Topic -
    Schema unique-identifier.json

    Accepts the following message:

    UniqueIdentifier Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/operational-information/unique-identifier.json

    A primary and permanent unique identifier used to represent the physical vehicle. For road vehicles: Indicates the globally unique 17 characters long alphanumeric Vehicle Identification Number (VIN) permanently attached to the vehicle. For other modes: Indicates a globally unique number of some sort permanently attached to the vehicle or if this is not possible; to the on-board system. Could be a MAC-address or other GUID.

    Examples

  • PUB pe/activecab

    Active Cab message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/activecab
    Schema active-cab.json

    Accepts the following message:

    ActiveCab Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/proprietary-extensions/active-cab.json

    Used to keep track of what direction the train is driving

    Examples

  • PUB pe/doorlock

    Door Lock message:

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/doorlock
    Schema door-lock.json

    This message is used to track if the vehicle doors are locked or unlocked.

    Frequency: on change

    Accepts the following message:

    DoorLock Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/proprietary-extensions/door-lock.json

    Door lock event

      Examples values:
    • {"eventTimestamp":"2020-10-31T08:38:02.749Z","locked":false}

    Examples

  • PUB pe/doors_individually

    Door Lock message:

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/doors_individually
    Schema doors-individually.json

    This topic is used to track the individual status of doors. One use case is to improve the data quality of APC counts. See also topic sensors/door for status of anyDoorOpen/allDoorsClosed.

    Accepts the following message:

    Doors Individually Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/proprietary-extensions/doors-individually.json

    This object is used to represent a door individually.

    Examples

  • PUB pe/dpi_ack

    DPI Acknowledge message:

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/dpi_ack
    Schema dpi-acknowledge.json
    Status ⚠️ Deprecated!

    The DPI Ack topic is used to inform the Ruter BO about the content presented on the PTO’s own systems for Dynamic Passenger Information in the vehicle. Usually, this is destination displays. The rest of DPI is presented by Ruter’s own DPI system, and does not need this kind of acknowledgement message.

    ⚠️ Deprecation notice! ⚠️

    Please be advised this topic is marked for deletion in later major versions of ADT.

    Accepts the following message:

    DPIAcknowledge Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/proprietary-extensions/dpi-acknowledge.json

    The DPI Ack topic.

    Examples

  • PUB pe/dpi/ack

    DPI Ack Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/adt/v2/pe/dpi/ack
    Schema dpi-acknowledge.json
    Producer PTO, Ruter DPI
    Consumer Ruter DPI

    The DPI Ack topic is used to inform the Ruter BO about the correct transfer and interpretation of messages to the vehicle.

    Ruter shall receive an acknowledgment message for the following topics:

    Topic Responsible for producing ack
    External display messages PTO
    Audio messages PTO
    Journey messages DPI application
    NextStop messages DPI application

    Notice! Due to late introduction of this topic, no messages are to be expected by PTOs on this version of ADT api.

    The ack message should be produced as soon as the message is received and validated. This is a confirmation that the system on board the vehicle have received the data and is capable of acting on it.

    No confirmation message should be returned if the system is unable to playback the content. (e.g. invalid message format)

    Accepts the following message:

    DpiAcknowledge
    object
    uid: https://schemas.ruter.no/adt/ota/api/v3.0/pe/dpi/ack/dpi-acknowledge.json

    The DPI Ack topic.

    Examples

  • PUB pe/dpi_diagnostics

    DPI Diagnostics message:

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/dpi_diagnostics
    Schema dpi-diagnostics.json

    Report to PTA BO about a screen.

    The DPI application itself produces diagnostic messages. The payload is defined as an object with no pre-defined structure to provide flexibility.

    Accepts the following message:

    DPI Diagnostics Message
    object
    uid: http://example.com/root.json

    Examples

  • PUB pe/sales/diagnostics

    RuterSalg diagnostics

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/sales/diagnostics
    Schema salediagnostics.json

    Diagnostics message generated by RuterSalg. More details about fields can be found at https://ruter.atlassian.net/wiki/spaces/TAAS/pages/948928517/OTA+MQTT-Meldinger+benyttet+av+Ruter+Salg.

    This topic is intended for applications interested in health status for the RuterSalg application on each bus. The health status is intended both as a real time surveillance of health status for each individual bus as well as for aggregating data per operator to see larger, more general issues. The topic can also, when enriched by other data, determine whether or not RuterSalg was used and working on a specific departure.

    Accepts the following message:

    RuterSalg Diagnostics MQTT Message
    object
    uid: http://schema.ruter.no/salediagnostics.json

    Examples

  • PUB pe/sales/saleresult

    Saleresult Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/sales/saleresult
    Schema saleresult.json

    Sale result message generated by RuterSalg. More details about fields can be found at https://ruterwiki.ruter.no/display/PNS/MQTT+Topics+consumed+and+produced+by+RuterSalg.

    This topic is intended as a live view of sales, and must not be used as the complete truth. This is done elsewhere. This topic is intended for health surveillance, for anyone interesting in whether or not tickets are being sold, and also how many and what kind of tickets.

    Some operators have suggested that they might be interested in using this topic to display sales results on screens separate from the RuterSalg application, intended as information to the travelers purchasing tickets. This topic is well suited for this use case.

    Accepts the following message:

    Saleresult MQTT Message
    object
    uid: http://schema.ruter.no/saleresult.json

    Result of sale made with the RuterSalg application

    Examples

  • PUB pe/sales/validationresult

    Validationresult Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/pe/sales/validationresult
    Schema validationresult.json

    Validation result message generated by RuterSalg. This topic is intended as a live view of validation. This topic is intended for health surveillance, for anyone interesting in whether or not validations are being performed, as well as validation results.

    Accepts the following message:

    Validationresult MQTT Message
    object
    uid: http://schema.ruter.no/validationresult.json

    Result of validation made with the RuterSalg application

    Examples

  • PUB pe/cardreader_diagnostics/vix/{deviceRef}

    Card Reader Diagnostics MQTT Message

    Field Value
    Central Topic ruter/{PTO}/{vehicleID}/pe/cardreader_diagnostics/vix/{deviceRef}
    Schema cardreader_diagnostics.json

    Diagnostics message sent from any Vix-validator running Ruter-firmware in the vehicle. Can be used by both PTA and PTO to monitor the operational status of these units.

    deviceRef
    required
    string
    uid: deviceRef

    An unique ID of the unit.

    Accepts the following message:

    Card Reader Diagnostics
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/proprietary-extensions/doors-individually.json

    Diagnostics message sent from any Vix-validator running Ruter-firmware in the vehicle. Can be used by both PTA and PTO to monitor the operational status of these units.

    Examples

  • PUB sensors/gnss/location

    Location MQTT Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/sensors/gnss/location
    Schema location.json

    Describes the GNSS navigation receiver feedback in metric format. The periodicity of updates to be expected should be described as number of seconds in configValue01 for this topic under topic:

    ruter/{PTO}/{vehicleID}/mi/provider_clients//provided_topics
    

    The GNSS type should be described in configValue11. Information about the used GNSS System. MixedGNSSTypes is used for receivers using multiple satellite constellations. Possible values:

    • GPS
    • Glonass
    • Galileo
    • Beidou
    • IRNSS
    • Other
    • DeadReckoning
    • MixedGNSSTypes

    The GNSS coordinate system should be described in configValue12, at least if other than “WGS84”. Possible values:

    • GPS
    • Glonass
    • Galileo
    • Beidou
    • IRNSS
    • Other
    • DeadReckoning
    • MixedGNSSTypes

    “MixedGNSSTypes” is used for receivers using multiple satellite constellations.

    Frequency is recommended at 1 message per second.

    Accepts the following message:

    Location Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/location.json

    Location sensor data

    Examples

  • PUB sensors/odometer

    Odometer Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/sensors/odometer
    Schema odometer.json

    Describes an odometer value in meters based on total vehicle distance or similar. Absolute value of less importance but should be increasing at least within the scope of a journey. Optionally the current speed according to the odometer could be included.

    Frequency is recommended at 1 message per second.

    Accepts the following message:

    Odometer Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/odometer.json

    Odometer data

      Examples values:
    • {"distance":23434556,"atDateTime":"2017-11-30T23:45:52.006Z","traceId":"2d826a9a-2474-11ed-861d-0242ac120002","messageNumber":12345}

    Examples

  • PUB sensors/apc_sensors/{sensorId}

    APC Sensors Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/sensors/apc_sensors/{sensorID}
    Schema apc-sensors.json
    sensorId
    required
    string
    uid: sensorId

    The sensor / telemetry Id.

    Accepts the following message:

    Apc Sensors Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/apc-sensors.json

    Raw-data from door-sensor for later evaluation.

    Examples

  • PUB sensors/door

    Door Sensor MQTT Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/sensors/door
    Schema door.json

    Frequency: on change

    Accepts the following message:

    Door Sensors Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/door.json

    Describes if any door is open (or to be more precise – if the door lock is released). Also see topic pe/doors_individually for status on individual doors.

      Examples values:
    • {"doorOpen":true,"atDateTime":"2021-11-30T23:45:52.006Z","traceId":"2d826a9a-2474-11ed-861d-0242ac120002"}

    Examples

  • PUB sensors/stop_button

    Stop Button Message

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/sensors/stop_button
    Schema stop-button.json

    This message should be produced whenever the stop signal is turned on or off.

    Frequency: on change

    Accepts the following message:

    Stop Button Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/stop-button.json

    Describes if passengers have requested that the bus should stop (stop button pressed).

      Examples values:
    • {"stopPressed":true,"atDateTime":"2021-11-30T23:45:52.006Z","messageNumber":1}

    Examples

  • PUB sensors/clock

    Clock Message

    Field Value
    Central Topic -
    Schema clock.json

    Accepts the following message:

    Clock Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/clock.json

    Examples

  • PUB sensors/telemetry/{sensorId}

    Telemetry data

    Field Value
    Central Topic ruter/{operatorId}/{vehicleId}/sensors/telemetry/{sensorID}
    Schema telemetry.json

    Several different kinds of sensor/telemetry data are available varying by vehicle type For traditional busses, FMS is the standard that defines what data about the vehicle is published on the FMS bus and further on by ITxPT FMStoIP service.In addition, vessels, trams and different bus types have proprietary data not captured by FMS.

    According to the data centric approach from ITxPT, several of these data types (door, location, stop button etc) have been assigned separate topics as being described in this document. However, data types required by Ruter that haven’t yet been described in the MQTT structure from ITxPT, will still be handled by the general Telemetry topic that was introduced by Ruter in 2019.

    All such data are defined by unique, 32 bit, identifiers. Data caught from the FMS bus retain their PGN numbers as the last 16 bits of the ID. Data not coming from the FMS bus follow a separate addressing scheme, with addresses allocated by Ruter on request. Please note that PTOs are free to decide if they want to use FMS or a non-FMS data source to provide the data.

    To utilize FMS data in Ruter’s architecture, Operators can either set up an FMS2IP service or use any other means to subscribe to the FMS bus data. Note that there must be one separate MQTT message per FMS PGN.

    The identifiers are constructed this way:

    Bytes Description
    1 Source identifier (0x00 FMS, 0x01 Non-FMS)
    2-4 Source-specific id, e.g. FMS PGNs

    Available Non-FMS standard data identifiers

    Optional unless stated explicitly in the main ADT document.

    ID Subid Name Value Recommended refresh interval Remarks
    0001FF25 10003 Wall Charger connected onChange
    0001FF25 10004 Fast Charger connected onChange
    0001FF25 10005 Charging Active onChange
    01000002 Temperature inside average float 1/min
    01000005 SOC float 1/min
    01000006 Transmission mode combustion/electric onChange Intended for hybrid vehicles
    01000007 Windscreen wiper active True/false onChange Taken to represent a measurement of the ground truth binary rainfall state, given that it is a better predictor of the binary rainfall state than radar- or gauge-based measurements
    01000008 Accelerometry 1/min * Bandwidth >= 100 hz
    * Resolution <= 0.01 g
    xmin Min x value last minute g
    xmax Max x value last minute g
    xavg Average x value last minute g
    ymin Min y value last minute g
    ymax Max y value last minute g
    yavg Average y value last minute g
    zmin Min z value last minute g
    zmax Max z value last minute g
    zavg Average z value last minute g
    01000009 Outdoor temperature float 1/min * Unit Celcius
    * Resolution <= 1 C
    * Measured at front of vehicle as near as possible to the ground
    0100000A Accumulated energy consumption float 1/min * Energy consumed
    * Including HVAC
    * Unit: kWh
    sensorId
    required
    string
    uid: sensorId

    The sensor / telemetry Id.

    Accepts the following message:

    Telemetry data
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/sensor/telemetry.json

    Examples

  • SUB di/assignment_attempt_rejection/block

    AssignmentAttemptRejection Message

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/di/assignment_attempt_rejection/block
    Schema assignment-attempt-rejection.json

    Describes a negative result from the back-office of an attempt to sign on or off a block from MADT or another GUI

    Accepts the following message:

    Assignment Attempt Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/driver-interaction/assignment-attempt-rejection.json

    Describes a negative result from the back-office of an attempt to sign on or off a block from MADT or another GUI

    Examples

  • SUB di/available_destination_displays

    AvailableDestinationDisplays Message

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/di/available_destination_displays
    Schema available-destination-displays.json

    Provides a list of available destination displays for a vehicle. The list should be used for external displays, in case the vehicle has lost connection to the backoffice.

    Accepts the following message:

    Assignment Attempt Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/driver-interaction/available-destination-displays.json

    Examples

  • SUB di/operational_message_to_driver

    OperationalMessageToDriver Message

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/di/operational_message_to_driver
    Schema operational-message-to-driver.json

    Provides an operational message directed to the driver onboard this vehicle. Direction: From back-office to driver.

    Accepts the following message:

    OperationalMessageToDriver Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/driver-interaction/operational-message-to-driver.json

    Operational message to driver

    Examples

  • SUB ei/audio_message

    Audio message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/ei/audio_message
    Schema audio.json

    Topic used exclusively to transmit audio messages to be played by the speaker system. The audio messages may contain an array of sound bites, that are to be played in the sequence they have been received.

    Accepts the following message:

    Audio MQTT Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/extended-information/audio-message.json

    This topic provides an audio message intended for passengers onboard the vehicle that should be played on speaker(s) defined in the speaker property of the payload.

    Examples

  • SUB ei/deviation_information

    Deviation message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/ei/deviation_information
    Schema deviation.json

    This topic provides an adapted selection of deviation and incident information that is relevant for passengers onboard this vehicle in scope of what the vehicle is currently doing and where it is on the current vehicle journey. The information is provided in the form of a list of situation messages. This topic should be blanked (provided with empty content) if there are no relevant situation messages. As an added precaution an expiry timestamp is included to assure that outdated information is not presented.

    Accepts the following message:

    Deviation Information Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/extended-information/deviation-information.json

    Deviation information

    Examples

  • SUB ei/due_information

    Due message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/ei/due_information
    Schema due-information.json

    This topic provides an adapted text indicating that the vehicle is about to arrive at a stop according to what the coordinating application has concluded.

    This could optionally be based on information provided in real-time from a back-office AVMS. However, if contact is lost with the back-office for more than a configured duration the information should be based on local information.

    ⚠️ Deprecation notice! ⚠️

    Please be advised this topic is marked for deletion in later major versions of ADT.

    Accepts the following message:

    Due Information Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/extended-information/due-information.json

    Due information

    Examples

  • SUB ei/transfer_information

    Due message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/ei/transfer_information
    Schema transfer-information.json

    This topic provides an adapted selection of real time information describing connecting lines at the current or the coming stop that passengers onboard this vehicle could transfer to. The information is provided in the form of a list of possible transfer options at the next stop.

    This topic should be blanked (provided with empty content) when there is no relevant information to display.

    As an added precaution an expiry timestamp is included to assure that outdated information is not presented.

    ⚠️ Deprecation notice! ⚠️

    Please be advised this topic is marked for deletion in later major versions of ADT.

    Accepts the following message:

    Transfer Information Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/extended-information/transfer-information.json

    Transfer information

    Examples

  • SUB oi/current_destination_display/text

    Current destination display message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/oi/current_destination_display/text
    Schema current-destination-display.json

    Message to be shown on the external destination display. Usually line number (lineDesignation) and name, with support for alternative message.

    Accepts the following message:

    Current Destination Display Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/operational-information/current-destination-display.json
      Examples values:
    • {"name":"Tonsenhagen","lineDesignation":"60"}

    Examples

  • SUB oi/current_block/state

    Current block message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/oi/current_block/state
    Schema current-block.json

    Normally this topic indicates which block this vehicle is currently signed on to according to the backoffice or that it only assigned but not yet signed on or that it is not even assigned. This is usually a result of what was proposed by the driver on-board (see ruter/{PTO}/{vehicleID}/di/assignment_attempt/block) and then confirmed as valid by the back-office. It could also be based on an overriding decision enforced by the operation control centre.

    Note that if a ruter/{PTO}/{vehicleID}/di/assignment_attempt/block is not answered by the back-office within a configured duration it is assumed that contact is lost with the control centre and then the proposed block will be accepted and exposed on this topic.

    Accepts the following message:

    Current Block Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/operational-information/current-block.json

    Current block

    Examples

  • SUB oi/current_vehicle_journey/expected_call

    Expected Call message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/oi/current_vehicle_journey/expected_call
    Schema expected-call.json

    The topic should provide a consistent set of current information describing the vehicle’s current, previous and next stop(s) including estimated times, observed times and additional information helping the driver to adhere to the operation control centre’s current plan for this vehicle. The topic is focused on the stop that the vehicle is standing at or will arrive to next in the case that the vehicle is between stops. The topic should be blanked (provided as a retained message with a zero-byte payload) if the vehicle has left the last stop and if it is not known what the next vehicle journey will be.

    ⚠️ Deprecation notice! ⚠️

    Please be advised this topic is marked for deletion in later major versions of ADT.

    Accepts the following message:

    Expected Call Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/operational-information/expected-call.json

    The expected call object.

    Examples

  • SUB oi/current_vehicle_journey/details

    Vehicle Journey Details message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/oi/current_vehicle_journey/details
    Schema vehicle-journey-details.json

    This topic provides the details of the current (monitored) vehicle journey. If there is no ongoing vehicle journey, this topic will provide the details of the coming vehicle journey. The information should reflect the latest production plan including any applied control actions as known in the back-office. Note however that this does not include neither estimated nor observed times at the different stops. This information is instead provided on the topic:

    ruter/{PTO}/{vehicleID}/oi/current_vehicle_journey/expected_call 
    

    The topic should be blanked (provided as a retained message with a zero-byte payload) if the vehicle has left the last stop and the next vehicle journey is not known

    Accepts the following message:

    UniqueIdentifier Message
    object
    uid: https://schemas.ruter.no/adt/ota/api/v2.1/operational-information/vehicle-journey-details.json

    Vehicle journey details

    Examples

  • SUB pe/tsp

    Traffic Preemption MQTT Message

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/tsp
    Schema tsp.json

    The message to be sent to VHF to ensure that the bus is prioritized at the traffic lights. This message is generated by Ruter when approaching an intersection or, when a stop is just before an intersection, after the doors have closed.

    Accepts the following message:

    Traffic Preemption MQTT Message
    object
    uid: http://schema.ruter.no/tsp.json

    Notification that vehicle should transmit a traffic preemption message

    Examples

  • SUB pe/dpi/journey

    Journey message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/journey
    Schema dpi-journey.json

    Message containing the stops included in the journey, connections to other lines, positions ++.

    Accepts the following message:

    Journey Message
    object
    uid: http://schema.ruter.no/journey.json

    List of stops for current journey in block

    Examples

  • SUB pe/dpi/nextstop

    Next Stop message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/nextstop
    Schema dpi-nextstop.json

    Next stop on the buss route after leaving a stop.

    Accepts the following message:

    Next Stop MQTT Message
    object
    uid: http://schema.ruter.no/nextstop.json

    Notification that vehicle has a new next stop

    Examples

  • SUB pe/dpi/eta

    ETA message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/eta
    Schema dpi-eta.json

    Estimated arrival at the remaining stops.

    Accepts the following message:

    ETA MQTT Message
    object
    uid: http://schema.ruter.no/eta.json

    Estimated time of arrival for future stops on a journey

    Examples

  • SUB pe/dpi/externaldisplay

    External Display message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/externaldisplay
    Schema dpi-externaldisplay.json

    Message to be shown on the external destination display. Usually line number (publicCode) and routeName, with support for alternative message.

    Accepts the following message:

    External Display MQTT Message
    object
    uid: http://schema.ruter.no/externaldisplay.json

    Notification that the external displays should show new destination information

    Examples

  • SUB pe/dpi/pa

    Passenger Announcement message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/pa
    Schema dpi-pa.json

    Message to be shown on internal displays. May contain references to videos, html, images, text etc.

    Accepts the following message:

    Passenger Announcement message
    object
    uid: https://schema.ruter.no/pamessage.json

    Examples

  • SUB pe/dpi/arriving

    Arriving message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/arriving
    Schema dpi-arriving.json

    Notice to passengers that the bus is approaching a stop.

    Accepts the following message:

    Arriving Message
    object
    uid: http://schema.ruter.no/arriving.json

    For display of arriving information to passengers

    Examples

  • SUB pe/dpi/connections

    Connections message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/connections
    Schema dpi-connections.json

    List of connections for the remaining stops on a journey with expected departures.

    Accepts the following message:

    The Connections Schema
    object
    uid: http://schema.ruter.no/connections.json

    This schema defines the connection message sent as an MQTT message to buses

    Examples

  • SUB pe/dpi/key_stops

    Key Stops message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi/key_stops
    Schema dpi-key_stops.json

    List of X number of most trafficked stops in the rest of the journey. Based on predicted number of passengers leaving on each stop

    Accepts the following message:

    Key Stops message
    object
    uid: https://schemas.ruter.no/dpi-key_stops.json

    This schema defines the Key Stops message sent as an MQTT message to vehicles

    Examples

  • SUB pe/dpi_command

    DPI Command message:

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/dpi_command
    Schema dpi-command.json

    This channels is reserved for command and control messages originated by Ruter. Typical use cases include:

    • Diagnostics / debugging
      • Trigger transfer of debug information
      • Trigger screenshot of DPI screen
      • Trigger clearing of cache and refresh of webpage
    • Content
      • Trigger display of campaign

    The payload is defined as an object with no structure to provide flexibility.

    Accepts the following message:

    DPI Command Message
    object
    uid: http://schema.ruter.no/c2.json

    Message sent to bus to control DPI functions

    Examples

  • SUB pe/vehicle/api

    Vehicle API

    Field Value
    Central Topic {operatorId}/ruter/{vehicleId}/pe/vehicle/api
    Schema api.json

    Message used by Ruter to distribute information about the vehicle and it's supported APIs as provided by the PTO.

    Accepts the following message:

    Api
    object
    uid: https://schemas.ruter.no/adt/ota/api/v3.0/pe/vehicle/api/api.json

    Vehicle API topic

    Examples