Avtale om digitale tjenester - ADT (Metro) 4.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.

Overview

The diagram below shows an overview of the most important messages that manage the assignment and journey of a vehicle.

Overview of important messages

  1. The vehicle signs on. (In ADT4, this is a synchronous REST call.)
  2. Based on the location of the vehicle, Ruter calculates which journey in the assignment the vehicle is on, which stop it is going to next, etc.
  3. If the position matches a journey in the assignmment, Ruter sends a journey message to the vehicle,
  4. ...and Ruter changes external display

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://mqtt.transhub.io/mqttmqttTranshub

    Ruters central MQTT broker

    object
    string
    required

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

    Security:

Operations

  • SEND di/override_attempt/destination_display

    Destination Display Override Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/di/override_attempt/destination_display
    Schema destination-display-override.json
    Maintainer Assignment
    Producer PTO
    Consumer Assignment
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    To construct a message, refer to the Available Destination Displays Message list and ensure that all fields provided in the list are included in the message.

    If an entry contains publicCode, destination, and alternativeMessage, all three fields must be included exactly as specified in the list. The only additional fields you need to provide are a current eventTimestamp and a unique traceId.

    Operation IDsendDestinationDisplayOverride

    Available only on servers:

    object

    Accepts the following message:

    Message IDDestinationDisplayOverride
    object [DestinationDisplayOverride]uid: https://schemas.ruter.no/adt/ota/api/v4.x/di/override_attempt/destination_display/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

  • SEND pe/active_cab

    ActiveCab Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/active_cab
    Schema active-cab.json
    Maintainer DPI
    Producer PTO
    Consumer DPI, Progress
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.
    Operation IDsendActiveCab

    Available only on servers:

    object

    Accepts the following message:

    Message IDActiveCab
    object [ActiveCab]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/active-cab/active-cab.json

    Used to keep track of what direction the train is driving

    Examples

  • RECEIVE pe/audio

    Audio Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/audio
    Schema audio.json
    Maintainer DPI
    Producer DPI
    Consumer PTO
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    The topic used for transmitting these audio messages is dedicated exclusively to audio playback through the vehicle's speaker system. The audio messages may contain an array of sound clips that should be played sequentially as they were received.

    In some cases, multiple speaker groups may be targeted by the same audio message.

    Audio Message Playback

    • When a vehicle receives an MQTT message containing audio content, the PTO must play the audio, which can be in either OPUS or MP3 format.
    • If the message defines an expiration timestamp that has passed, the audio content must not be played.
    • If a message contains multiple audio files, these must be played in the order in which they appear in the message.
    • MQTT messages with audio content must be processed synchronously, ensuring that new messages are only played after the previous one has finished.
    Operation IDreceiveAudio

    Available only on servers:

    object

    Accepts the following message:

    Message IDAudio
    object [Audio]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/audio/audio.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

  • SEND pe/cardreader_diagnostics/vix/{deviceRef}

    VIX Card Reader Diagnostics MQTT Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/cardreader_diagnostics/vix/{deviceRef}
    Schema vix-cardreader_diagnostics.json
    Maintainer Betjent salg
    Producer VIX
    Consumer PTA
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    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.

    Operation IDsendVixCardreaderDiagnostics

    Available only on servers:

    object
    deviceRefstring
    required

    An unique ID of the unit.

    object

    Accepts the following message:

    Message IDVixCardreaderDiagnostics
    object [VixCardreaderDiagnostics]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cardreader-diagnostics/vix/vix-cardreader_diagnostics.json

    Examples

  • SEND pe/cbtc/trip_activated

    CBTC Trip Activated Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/cbtc/trip_activated
    Schema trip-activated.json
    Maintainer Assignment
    Producer Sporveien / CBTC
    Consumer Assignment
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Published when the CBTC system activates a new trip. Contains enough information to uniquely identify the trip, used by Ruter's offline solution and matched with data stored onboard about the route plan.

    When vehicles have been coupled, each vehicle must send this information.

    Operation IDsendCbtcTripActivated

    Available only on servers:

    object

    Accepts the following message:

    Message IDTripActivated
    object [TripActivated]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cbtc/trip_activated/trip-activated.json

    Published onboard when CBTC activates a new trip. Contains enough information to uniquely identify the trip, used by Ruter's offline solution and matched with data stored onboard about the route plan. When vehicles have been coupled, each vehicle must send this information.

    Examples

  • SEND pe/cbtc/next_stop

    CBTC Next Stop Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/cbtc/next_stop
    Schema next-stop.json
    Maintainer Assignment
    Producer Sporveien / CBTC
    Consumer Assignment
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    When the vehicle starts to move with a defined destination, CBTC makes information available about the next stop of the vehicle. This information is published onboard so that the Ruter offline solution can access it.

    When vehicles have been coupled, each vehicle must send this information.

    Operation IDsendCbtcNextStop

    Available only on servers:

    object

    Accepts the following message:

    Message IDCbtcNextStop
    object [NextStop]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cbtc/next_stop/next-stop.json

    Published when CBTC knows the next stop/quay of the vehicle, so that the Ruter offline solution can access it.

    Examples

  • SEND pe/cbtc/target_distance

    CBTC Distance To Next Quay (Target) Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/cbtc/target_distance
    Schema target-distance.json
    Maintainer Assignment
    Producer Sporveien / CBTC
    Consumer Assignment
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    When the vehicle has a known destination, CBTC publishes information about the remaining distance to the target every second.

    Operation IDsendCbtcTargetDistance

    Available only on servers:

    object

    Accepts the following message:

    Message IDTargetDistance
    object [TargetDistance]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cbtc/target_distance/target-distance.json

    Published every second when the vehicle has a known destination, with information about the remaining distance to the target.

    Examples

  • SEND pe/rejected

    Rejected Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/rejected
    Schema pe-rejected.json
    Maintainer DPI
    Producer PTO
    Consumer DPI
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    The pe/rejected topic is used by the external client to inform the DPI backoffice when an incoming message fails validation on the client side.

    A rejected message must reference the original rejected message via rejectedMessage and include a machine-readable reasonCode. The optional reasonDetails field may contain a human-readable explanation.

    reasonCode Description
    SCHEMA_VALIDATION_FAILED The message did not conform to the expected JSON Schema
    CONTENT_POLICY_VIOLATION The message was rejected due to prohibited content (e.g. words)
    Operation IDsendPeRejected

    Available only on servers:

    object

    Accepts the following message:

    Message IDPeRejected
    object [PeRejected]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/rejected/pe-rejected.json

    Published by the consumer when an incoming message fails validation.

    Examples

  • SEND pe/doors_individually

    DoorsIndividually Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/doors_individually
    Schema doors-individually.json
    Maintainer Passasjertelling
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    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.

    Operation IDsendDoorsIndividually

    Available only on servers:

    object

    Accepts the following message:

    Message IDDoorsIndividually
    object [DoorsIndividually]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/doors-individually/doors-individually.json

    This object is used to represent a door individually.

    Examples

  • SEND pe/dpi/ack

    Acknowledge Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/dpi/ack
    Schema dpi-acknowledge.json
    Maintainer DPI
    Producer PTO, DPI
    Consumer DPI
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

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

    PTA 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

    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)

    Operation IDsendDpiAcknowledge

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiAcknowledge
    object [DpiAcknowledge]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/ack/dpi-acknowledge.json

    The DPI Ack topic.

    Examples

  • RECEIVE pe/dpi/arriving

    Arriving Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/arriving
    Schema dpi-arriving.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Notice to passengers that the bus is approaching a stop.

    Operation IDreceiveDpiArriving

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiArriving
    object [DpiArriving]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/arriving/dpi-arriving.json

    For display of arriving information to passengers

    Examples

  • RECEIVE pe/dpi/command

    Command Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/command
    Schema dpi-command.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    This channel is highly unstable and should only be used by developers in TET.

    This channel makes it possible for developers to debug the running application by providing real-time commands to it.

    The results from each requested command is sent to pe/dpi/command_response.

    Operation IDreceiveDpiCommand

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiCommand
    object [DpiCommand]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/command/dpi-command.json

    Message sent to bus to control DPI functions

    Examples

  • SEND pe/dpi/command_response

    Command response message

    Responses generated from requests sent on /pe/dpi/command

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/dpi/command_response
    Schema dpi-command_response.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    This message is a response to another message sent on pe/dpi/command. It contains the result of the command.

    Operation IDsendDpiCommandResponse

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiCommandResponse
    object [DpiCommandResponse]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/command_response/dpi-command_response.json

    Message sent from vehicle as response to DPI commands

    Examples

  • SEND pe/dpi/connection_status

    Connection Status Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/dpi/connection_status
    Schema dpi-connection-status.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Connection messages sent when the DPI client connects and disconnects from the MQTT broker. It is used to monitor the connection status of the DPI client and detect screens where the browser may be in restart loop.

    Operation IDsendDpiConnectionStatus

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiConnectionStatus
    object [DpiConnectionStatus]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/connection_status/dpi-connection-status.json

    DPI Connection status topic

    Examples

  • RECEIVE pe/dpi/connections

    Connections Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/connections
    Schema dpi-connections.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

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

    Operation IDreceiveDpiConnections

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiConnections
    object [DpiConnections]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/connections/dpi-connections.json

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

    Examples

  • SEND pe/dpi/diagnostics

    Diagnostics Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/dpi/diagnostics
    Schema dpi-diagnostics.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    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.

    Operation IDsendDpiDiagnostics

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiDiagnostics
    object [DpiDiagnostics]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/diagnostics/dpi-diagnostics.json

    Examples

  • SEND pe/dpi/display_status

    DPI Display Status

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/dpi/display_status
    Schema dpi-display-status.json
    Maintainer DPI
    Producer DPI
    Consumer PTO, DPI
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    The DPI Display status topic is used to inform the Ruter BO about the current state (Tilstandsmelding) for DPI.

    This messages is produced every fifth minute and every time a message is received on pe/dpi/journey and used in SLA measurement.

    Operation IDsendDpiDisplayStatus

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiDisplayStatus
    object [DpiDisplayStatus]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/display_status/dpi-display-status.json

    DPI Display status topic

    Examples

  • SEND pe/dpi/emergency

    Emergency Message To Passengers

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/emergency
    Schema emergency.json
    Maintainer DPI
    Producer M4 / MADT
    Consumer DPI
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Sporveien is required to provide the public with an evacuation message in case an emergency occurs. This message overrides the display on Ruter's DPI screens onboard the vehicle.

    This message is among those that will be sent by the MADT when the driver has selected an "Emergency message". It will often be sent together with pe/audio (one of several pre-recorded audio messages stored onboard in a configuration file for the MADT). This message, and an audio message, must be sent repeatedly by the MADT every X seconds (where X is a configurable setting from the message definition file), until the driver disables the emergency message. Some of the emergency messages contain external signage which is to override whatever is currently set.

    The message is broadcast from the MADT. The consumer is Ruter's DPI application running in browser in displays onboard the vehicle. The message direction is "out", because the message should be forwarded from the vehicle to the backoffice systems, as the driver triggering an emergency is important information to keep track of.

    It is expected that the MADT will send one message to enable the emergency message. When the driver cancels the emergency message from the MADT, this same message (pe/dpi/emergency) must be sent with enabled set to Boolean false.

    Operation IDsendDpiEmergency

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiEmergency
    object [Emergency]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/emergency/emergency.json

    Emergency message to passengers. Sporveien is required to provide the public with an evacuation message in case an emergency occurs. This message overrides the display on Ruter's DPI screens onboard the vehicle. This message is among those that will be sent by the MADT when the driver has selected an "Emergency message". It will often be sent together with pe/audio (one of several pre-recorded audio messages stored onboard in a configuration file for the MADT). This message, and an audio message, must be sent repeatedly by the MADT until the driver disables the emergency message.

    Examples

  • RECEIVE pe/dpi/eta

    Eta Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/eta
    Schema dpi-eta.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Estimated arrival at the remaining stops.

    Operation IDreceiveDpiEta

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiEta
    object [DpiEta]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/eta/dpi-eta.json

    Estimated time of arrival for future stops on a journey

    Examples

  • RECEIVE pe/dpi/externaldisplay

    Externaldisplay Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/externaldisplay
    Schema dpi-externaldisplay.json
    Maintainer DPI
    Producer DPI
    Consumer PTO
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

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

    Operation IDreceiveDpiExternaldisplay

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiExternaldisplay
    object [DpiExternaldisplay]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/externaldisplay/dpi-externaldisplay.json

    Notification that the external displays should show new destination information

    Examples

  • RECEIVE pe/dpi/feature_toggle

    Feature Toggle Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/feature_toggle
    Schema dpi-feature-toggle.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Message with all active and inactive features.

    Operation IDreceiveDpiFeatureToggle

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiFeatureToggle
    object [DpiFeatureToggle]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/feature_toggle/dpi-feature-toggle.json

    Message sent to vehicle to feature toggle DPI functions

    Examples

  • RECEIVE pe/dpi/journey

    Journey Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/journey
    Schema dpi-journey.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

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

    Operation IDreceiveDpiJourney

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiJourney
    object [DpiJourney]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/journey/dpi-journey.json

    List of stops for current journey in block

    Examples

  • RECEIVE pe/dpi/key_stops

    Key Stops Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/key_stops
    Schema dpi-key_stops.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

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

    Operation IDreceiveDpiKeyStops

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiKeyStops
    object [DpiKeyStops]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/key_stops/dpi-key_stops.json

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

    Examples

  • SEND pe/dpi/logs

    Command Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/pe/dpi/logs
    Schema dpi-logs.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Logs from the DPI client are published to this topic. The payload includes the log level and message, and may include a stack trace when available.

    Operation IDsendDpiLogs

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiLogs
    object [DpiLogs]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/logs/dpi-logs.json

    Logs from the DPI client

    Examples

  • RECEIVE pe/dpi/nextstop

    Nextstop Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/nextstop
    Schema dpi-nextstop.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Next stop on the buss route after leaving a stop.

    Operation IDreceiveDpiNextstop

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiNextstop
    object [DpiNextstop]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/nextstop/dpi-nextstop.json

    Notification that vehicle has a new next stop

    Examples

  • RECEIVE pe/dpi/pa

    Pa Message

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/dpi/pa
    Schema dpi-pa.json
    Maintainer DPI
    Producer DPI
    Consumer DPI
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

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

    Operation IDreceiveDpiPa

    Available only on servers:

    object

    Accepts the following message:

    Message IDDpiPa
    object [DpiPa]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/pa/dpi-pa.json

    Examples

  • RECEIVE pe/vehicle/api

    Vehicle API

    Field Value
    Central Topic {operatorId}/{authorityId}/{vehicleId}/adt/v4/pe/vehicle/api
    Schema api.json
    Maintainer DPI
    Producer DPI
    Consumer DPI, Betjent salg
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

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

    Operation IDreceiveApi

    Available only on servers:

    object

    Accepts the following message:

    Message IDApi
    object [Api]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/vehicle/api/api.json

    Vehicle API topic

    Examples

  • SEND status/coupling

    Coupling Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/status/coupling
    Schema coupling.json
    Maintainer Sporveien / DRIV
    Producer Sporveien / DRIV
    Consumer Sporveien / DRIV
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    M4 cars can be coupled ("connected") with each other, and they can be decoupled ("disconnected"). Both vehicles being connected or disconnected must send information. Hence, each coupling/decoupling action will result in two such messages - one from each vehicle.

    The message topic from each vehicle contains the vehicle number of that vehicle. The carId and withCarId fields refer to the individual cars (parts) of the vehicle (MC1, M, or MC2).

    Motivation: Connecting and disconnecting carriages is key information required in backend systems, for example for DRIV.

    Operation IDsendCoupling

    Available only on servers:

    object

    Accepts the following message:

    Message IDCoupling
    object [Coupling]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/coupling/coupling.json

    Sent from both vehicles when M4 cars are coupled or decoupled. Vehicles can be coupled ("connected") with each other, and they can be decoupled ("disconnected"). Both vehicles being connected or disconnected must send information, so each coupling/decoupling action results in two such messages - one from each vehicle.

    Examples

  • SEND status/offline

    Signal From MADT (Driver) To Use Offline Passenger Information

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/status/offline
    Schema offline.json
    Maintainer Sporveien
    Producer Sporveien
    Consumer Sporveien
    Service Level ⛔ PTA internal API. No restrictions apply. May be removed or modified freely by the PTA

    Ruter delivers a solution for limited passenger information to be used onboard. This message triggers use of the offline solution. The message flow for audio and external signage will be:

    • Ruter publishes: pe/audio
    • Sporveien backoffice republishes this as pe/online/audio
    • Ruter's onboard component listens on pe/online/audio
      • When state is "online", Ruter's offline solution republishes the message on the M4 MQTT broker as pe/audio (the standard ADT audio message)
      • When state is "offline", Ruter's component will publish pe/audio without any signal from the landside

    This message is triggered from the MADT screen by the driver. When the driver exits "offline" mode in the MADT, the message should first be published with offline = false. When the vehicle is first powered on, it should immediately send a message with offline = false.

    Note that the message is "retained". The last message of this type published will remain on the broker. Any new subscribing client will receive it. The topic is specified as "bridged", even though it most likely will not be sent out of the vehicle, as the vehicle will not have a network connection when this occurs.

    Operation IDsendOffline

    Available only on servers:

    object

    Accepts the following message:

    Message IDOffline
    object [Offline]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/offline/offline.json

    Signal from MADT (driver) to use offline passenger information. Ruter delivers a solution for limited passenger information to be used onboard. This message triggers use of the offline solution. The message is retained - the last message of this type published will remain on the broker, and any new subscribing client will receive it.

    Examples

  • SEND status/doors/available

    Describe Which Doors Will Open At The Next Stop

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/status/doors/available
    Schema doors-available.json
    Maintainer Sporveien
    Producer Sporveien
    Consumer Sporveien
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    CBTC onboard, physically locking/blocking doors, and the vehicle itself will determine which doors can or cannot open when approaching a stop. This message broadcasts that information as a list of the doors that will open at the next stop, a list of doors that will not open, and a list of doors with errors.

    For example, at a stop which is long enough for the entire vehicle, all the doors on the right-hand side will open. At some stops that are too short for the entire vehicle, only the front-most doors will open.

    Motivation: This will likely be used by Ruter to display a visual indication in the DPI application showing passengers whether a door will open at the next stop or not.

    When several vehicles are connected ("coupled") each vehicle should send its own individual status/doors/available message. It is important that this message be published for the next stop/quay as soon as possible on leaving the current stop/quay.

    Operation IDsendDoorsAvailable

    Available only on servers:

    object

    Accepts the following message:

    Message IDDoorsAvailable
    object [DoorsAvailable]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/doors/available/doors-available.json

    Describes which doors will open at the next stop. CBTC onboard, physically locking/blocking doors, and the vehicle itself will determine which doors can or cannot open when approaching a stop. This message broadcasts that information as a list of the doors that will open at the next stop, a list of doors that will not open, and a list of doors with errors.

    Examples

  • SEND status/door_request_open

    Report Which Doors Were Requested To Open Using Button

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/status/door_request_open
    Schema door-request-open.json
    Maintainer Sporveien
    Producer Sporveien
    Consumer Sporveien
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    This message is sent with requestOpen equal to Boolean True when the button on the door is pressed, requesting that it be opened at the next stop.

    The message is sent with requestOpen equal to Boolean False for all doors that were previously requested opened (i.e., a message of this type with requestOpen = true was sent for this doorRef) when the door lock is enabled (sensors/door is sent with isOpen=false).

    Motivation: It should be possible for the passenger information application (DPI) on the screen above the door to listen to this message onboard, and display whether the door will open or not. This is in addition to the button lighting up, signaling that the door will open on reaching the platform/quay.

    This should be sent even if the door is on the list of doors that should be disabled (or is locked) at the next stop.

    Operation IDsendDoorRequestOpen

    Available only on servers:

    object

    Accepts the following message:

    Message IDDoorRequestOpen
    object [DoorRequestOpen]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/door_request_open/door-request-open.json

    Report which doors were requested to open using the door button. This topic is used to track whether the passengers have pressed the door_request button.

    Examples

  • SEND sensors/apc/{sensorId}

    Apc Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/apc/{sensorId}
    Schema apc.json
    Maintainer Passasjertelling
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.
    Operation IDsendApc

    Available only on servers:

    object
    sensorIdstring
    required

    Identification of the physical sensor, e.g. serial number

    object

    Accepts the following message:

    Message IDApc
    object [Apc]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/apc/apc.json

    Raw-data from door-sensor for later evaluation.

    Examples

  • SEND sensors/door

    Door Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/door
    Schema door.json
    Maintainer Passasjertelling
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Frequency: on change

    Operation IDsendDoor

    Available only on servers:

    object

    Accepts the following message:

    Message IDDoor
    object [Door]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/door/door.json

    Door status - indicates if passengers are able to open the doors (the door lock is released). When false, doors are locked and cannot be opened by passengers.

    Examples

  • SEND sensors/location

    Location Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/location
    Schema location.json
    Maintainer Progress
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Describes the GNSS navigation receiver feedback in metric format.

    The GNSS type is expected to be GPS. The GNSS coordinate system is expected be “WGS84”. Negative values is used south of the equator and west of Greenwich.

    Frequency is expected to be at 1 message per second.

    Operation IDsendLocation

    Available only on servers:

    object

    Accepts the following message:

    Message IDLocation
    object [Location]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/location/location.json

    Location sensor data

    Examples

  • SEND sensors/odometer

    Odometer Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/odometer
    Schema odometer.json
    Maintainer Progress
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Describes an odometer value in meters based on total vehicle distance or similar. Absolute value of less importance but should be increasing within the scope of a journey.

    Frequency is expected to be at 1 message per second.

    Operation IDsendOdometer

    Available only on servers:

    object

    Accepts the following message:

    Message IDOdometer
    object [Odometer]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/odometer/odometer.json

    Odometer data

    Examples

  • SEND sensors/temperature_indoor

    Temperature Indoor Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/temperature_indoor
    Schema temperature-indoor.json
    Maintainer Miljødata
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Describes the measured air temperature inside a vehicle. Each message corresponds to one physical sensor and includes contextual information that indicates its approximate location, based on defined temperature zones along the vehicle’s length and its vertical level if applicable.

    Message Specifications

    • Message frequency: 6 times per minute (every 10 seconds)
    • Unit: Degrees Celsius (°C)
    • Resolution: <= 1°C

    Location Semantics

    To support consistent interpretation across vehicle types, each temperature message includes:

    Field Type Description
    zone Int Position along the vehicle’s length. Divided into zones (starting from front = 1). Zone 0 is reserved exclusively for the driver's cabin.
    level Int Vertical level of the sensor. Only applicable for multi-level vehicles. If not provided, it will be interpreted as 1 (platform level).

    Note: All zones are approximate and not intended to represent exact physical locations. They serve to provide a general understanding of where a sensor is located within the vehicle.

    Temperature Zones

    Operation IDsendTemperatureIndoor

    Available only on servers:

    object

    Accepts the following message:

    Message IDTemperatureIndoor
    object [TemperatureIndoor]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/temperature-indoor/temperature-indoor.json

    Schema for indoor temperature sensor data. The value represents the measured air temperature in degrees Celsius (°C) at a specific location within the vehicle. Location is defined by the car, zone (front, middle, rear, driver cabin), and level (e.g. below platform, platform, or upper level).

    Examples

  • SEND sensors/temperature_outdoor

    Temperature Outdoor Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/temperature_outdoor
    Schema temperature-outdoor.json
    Maintainer Miljødata
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Measurement of the external temperature around the vehicle.

    Message Specifications

    • Message frequency: Once per minute (every 60 seconds)
    • Unit: Degrees Celsius (°C)
    • Resolution: <= 1°C
    Operation IDsendTemperatureOutdoor

    Available only on servers:

    object

    Accepts the following message:

    Message IDTemperatureOutdoor
    object [TemperatureOutdoor]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/temperature-outdoor/temperature-outdoor.json

    Schema for outdoor temperature sensor data

    Examples

  • SEND sensors/accelerometer

    Accelerometer Message

    Field Value
    Central Topic {authorityId}/{operatorId}/{vehicleId}/adt/v4/sensors/accelerometer
    Schema accelerometer.json
    Maintainer Miljødata
    Producer PTO
    Consumer PTA
    Service Level ✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

    Expects a message that provides aggregated acceleration measurements over a 10-second interval. Each payload must include the minimum, maximum, and average acceleration values along the X, Y, and Z axes.

    Message Specifications

    • Message Frequency: 6 messages per minute (every 10 seconds)
    • Unit: All acceleration values are reported in g (1 g ≈ 9.81 m/s²)
    • Sampling Bandwidth: ≥ 100 Hz
    • Resolution: ≤ 0.01 g

    Expected Orientation

    By default, the schema assumes the accelerometer is mounted so that:

    • X-axis points forward (toward the vehicle’s front)
    • Y-axis points left (toward the vehicle’s left side)
    • Z-axis points up (toward the vehicle’s roof)

    If no orientation override fields are present, consumers should interpret the numerical values according to these defaults.

    Orientation Overrides

    Producers may optionally set xOrientation, yOrientation or zOrientation, each of which must be one of the six values: F (forward), B (backward), L (left), R (right), U (up) or D (down). If none are provided, the system assumes xOrientation = "F", yOrientation = "L", and zOrientation = "U".

    For a valid override, exactly one axis must be aligned along the forward/backward direction (F or B), exactly one along the up/down direction (U or D), and exactly one along the left/right direction (L or R). In other words, among the three fields there must be one value from { F, B }, one from { U, D }, and one from { L, R }. Any other combination is considered invalid and must be corrected before publishing.

    Operation IDsendAccelerometer

    Available only on servers:

    object

    Accepts the following message:

    Message IDAccelerometer
    object [Accelerometer]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/accelerometer/accelerometer.json

    Schema for accelerometer sensor data. Accelerations are measured along the sensor's axes: X points forward, Y points left, and Z points upward. 'Forward' is defined relative to the vehicle's front (as configured or physically marked). All acceleration values are in units of g (where 1g ≈ 9.81 m/s²). Any divergence from the standard must be specified using the optional axis orientation overrides (fields xOrientation, yOrientation, and zOrientation).

    Examples

Messages

  • #1
    Message IDDestinationDisplayOverride
    object [DestinationDisplayOverride]uid: https://schemas.ruter.no/adt/ota/api/v4.x/di/override_attempt/destination_display/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

  • #2
    Message IDActiveCab
    object [ActiveCab]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/active-cab/active-cab.json

    Used to keep track of what direction the train is driving

  • #3
    Message IDAudio
    object [Audio]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/audio/audio.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.

  • #4
    Message IDVixCardreaderDiagnostics
    object [VixCardreaderDiagnostics]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cardreader-diagnostics/vix/vix-cardreader_diagnostics.json
  • #5
    Message IDTripActivated
    object [TripActivated]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cbtc/trip_activated/trip-activated.json

    Published onboard when CBTC activates a new trip. Contains enough information to uniquely identify the trip, used by Ruter's offline solution and matched with data stored onboard about the route plan. When vehicles have been coupled, each vehicle must send this information.

  • #6
    Message IDCbtcNextStop
    object [NextStop]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cbtc/next_stop/next-stop.json

    Published when CBTC knows the next stop/quay of the vehicle, so that the Ruter offline solution can access it.

  • #7
    Message IDTargetDistance
    object [TargetDistance]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/cbtc/target_distance/target-distance.json

    Published every second when the vehicle has a known destination, with information about the remaining distance to the target.

  • #8
    Message IDDoorsIndividually
    object [DoorsIndividually]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/doors-individually/doors-individually.json

    This object is used to represent a door individually.

  • #9
    Message IDDpiAcknowledge
    object [DpiAcknowledge]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/ack/dpi-acknowledge.json

    The DPI Ack topic.

  • #10
    Message IDDpiArriving
    object [DpiArriving]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/arriving/dpi-arriving.json

    For display of arriving information to passengers

  • #11
    Message IDDpiCommand
    object [DpiCommand]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/command/dpi-command.json

    Message sent to bus to control DPI functions

  • #12
    Message IDDpiCommandResponse
    object [DpiCommandResponse]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/command_response/dpi-command_response.json

    Message sent from vehicle as response to DPI commands

  • #13
    Message IDDpiConnectionStatus
    object [DpiConnectionStatus]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/connection_status/dpi-connection-status.json

    DPI Connection status topic

  • #14
    Message IDDpiConnections
    object [DpiConnections]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/connections/dpi-connections.json

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

  • #15
    Message IDDpiDiagnostics
    object [DpiDiagnostics]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/diagnostics/dpi-diagnostics.json
  • #16
    Message IDDpiDisplayStatus
    object [DpiDisplayStatus]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/display_status/dpi-display-status.json

    DPI Display status topic

  • #17
    Message IDDpiEmergency
    object [Emergency]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/emergency/emergency.json

    Emergency message to passengers. Sporveien is required to provide the public with an evacuation message in case an emergency occurs. This message overrides the display on Ruter's DPI screens onboard the vehicle. This message is among those that will be sent by the MADT when the driver has selected an "Emergency message". It will often be sent together with pe/audio (one of several pre-recorded audio messages stored onboard in a configuration file for the MADT). This message, and an audio message, must be sent repeatedly by the MADT until the driver disables the emergency message.

  • #18
    Message IDDpiEta
    object [DpiEta]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/eta/dpi-eta.json

    Estimated time of arrival for future stops on a journey

  • #19
    Message IDDpiExternaldisplay
    object [DpiExternaldisplay]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/externaldisplay/dpi-externaldisplay.json

    Notification that the external displays should show new destination information

  • #20
    Message IDDpiFeatureToggle
    object [DpiFeatureToggle]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/feature_toggle/dpi-feature-toggle.json

    Message sent to vehicle to feature toggle DPI functions

  • #21
    Message IDDpiJourney
    object [DpiJourney]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/journey/dpi-journey.json

    List of stops for current journey in block

  • #22
    Message IDDpiKeyStops
    object [DpiKeyStops]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/key_stops/dpi-key_stops.json

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

  • #23
    Message IDDpiLogs
    object [DpiLogs]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/logs/dpi-logs.json

    Logs from the DPI client

  • #24
    Message IDDpiNextstop
    object [DpiNextstop]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/nextstop/dpi-nextstop.json

    Notification that vehicle has a new next stop

  • #25
    Message IDDpiPa
    object [DpiPa]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/dpi/pa/dpi-pa.json
  • #26
    Message IDPeRejected
    object [PeRejected]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/rejected/pe-rejected.json

    Published by the consumer when an incoming message fails validation.

  • #27
    Message IDApi
    object [Api]uid: https://schemas.ruter.no/adt/ota/api/v4.x/pe/vehicle/api/api.json

    Vehicle API topic

  • #28
    Message IDCoupling
    object [Coupling]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/coupling/coupling.json

    Sent from both vehicles when M4 cars are coupled or decoupled. Vehicles can be coupled ("connected") with each other, and they can be decoupled ("disconnected"). Both vehicles being connected or disconnected must send information, so each coupling/decoupling action results in two such messages - one from each vehicle.

  • #29
    Message IDOffline
    object [Offline]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/offline/offline.json

    Signal from MADT (driver) to use offline passenger information. Ruter delivers a solution for limited passenger information to be used onboard. This message triggers use of the offline solution. The message is retained - the last message of this type published will remain on the broker, and any new subscribing client will receive it.

  • #30
    Message IDDoorsAvailable
    object [DoorsAvailable]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/doors/available/doors-available.json

    Describes which doors will open at the next stop. CBTC onboard, physically locking/blocking doors, and the vehicle itself will determine which doors can or cannot open when approaching a stop. This message broadcasts that information as a list of the doors that will open at the next stop, a list of doors that will not open, and a list of doors with errors.

  • #31
    Message IDDoorRequestOpen
    object [DoorRequestOpen]uid: https://schemas.ruter.no/adt/ota/api/v4.x/status/door_request_open/door-request-open.json

    Report which doors were requested to open using the door button. This topic is used to track whether the passengers have pressed the door_request button.

  • #32
    Message IDApc
    object [Apc]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/apc/apc.json

    Raw-data from door-sensor for later evaluation.

  • #33
    Message IDDoor
    object [Door]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/door/door.json

    Door status - indicates if passengers are able to open the doors (the door lock is released). When false, doors are locked and cannot be opened by passengers.

  • #34
    Message IDLocation
    object [Location]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/location/location.json

    Location sensor data

  • #35
    Message IDOdometer
    object [Odometer]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/odometer/odometer.json

    Odometer data

  • #36
    Message IDTemperatureIndoor
    object [TemperatureIndoor]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/temperature-indoor/temperature-indoor.json

    Schema for indoor temperature sensor data. The value represents the measured air temperature in degrees Celsius (°C) at a specific location within the vehicle. Location is defined by the car, zone (front, middle, rear, driver cabin), and level (e.g. below platform, platform, or upper level).

  • #37
    Message IDTemperatureOutdoor
    object [TemperatureOutdoor]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/temperature-outdoor/temperature-outdoor.json

    Schema for outdoor temperature sensor data

  • #38
    Message IDAccelerometer
    object [Accelerometer]uid: https://schemas.ruter.no/adt/ota/api/v4.x/sensors/accelerometer/accelerometer.json

    Schema for accelerometer sensor data. Accelerations are measured along the sensor's axes: X points forward, Y points left, and Z points upward. 'Forward' is defined relative to the vehicle's front (as configured or physically marked). All acceleration values are in units of g (where 1g ≈ 9.81 m/s²). Any divergence from the standard must be specified using the optional axis orientation overrides (fields xOrientation, yOrientation, and zOrientation).