Avtale om digitale tjenester - ADT 3.x

AssignmentAttemptRequest Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/operational/assignment/attempt/request
Schema	assignment-attempt-request.json
Producer	PTO
Consumer	Ruter Assignment
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

AssignmentAttemptRequest Usage

Follows the request/response/state pattern. When a request is made to the request topic, a response will be available at the response topic once Ruter has finished processing. In addition, if the request results in a change of state, the status topic will be updated to reflect the current state as seen by Ruter.

An AssignmentAttemptRequest can be made for:

Action	Description
SignOn	Creating an Assignment for a vehicle. Signing a vehicle on to a set of planned journeys/stops
SignOff	Signing a vehicle off from an assigned assignment
Update	Altering an existing assigned assignment

• The message is composed of three operations (signOn, signOff, update). Only one operation will be processed per message received by Ruter. This gives that each message should only contain one operation. If the message contains more than one operation, the order of precedence is the following:
  1. signOn
  2. signOff
  3. update
• Attempt request will get an attempt response under the response topic
• Any request leading to a change of existing assignment state is reflected under the status topic
  • This topic will also be updated when Ruter has initiated changes to existing assignments
• Please provide all fields marked as reqired in the schema specifications.

Definitions

• A block contains a set of journeys.
• A vehicleTask is a set of one or more blocks that can be served by one vehicle during one operating day. In the example below, the vehicle task with vehicleTaskId=59001 consists of the 2 Blocks with <PrivateCode>59001</PrivateCode>.

Example of NeTEx definition of a vehicle task with 2 blocks

<VehicleScheduleFrame version="20220908125021" id="RUT:VehicleScheduleFrame:1">
  <blocks>
    <Block version="20220908125021" id="RUT:Block:168197-59001mut-202209081312000">
      <PrivateCode>59001</PrivateCode>
      <StartTime>11:12:00</StartTime>
      <EndTime>14:41:00</EndTime>
      <dayTypes>
        <DayTypeRef ref="RUT:DayType:2022-09-08"/>
      </dayTypes>
      <StartPointRef ref="RUT:ScheduledStopPoint:Fg" version="20220908125021"/>
      <EndPointRef ref="RUT:ScheduledStopPoint:Fg" version="20220908125021"/>
      <journeys>
        <DeadRunRef ref="RUT:DeadRun:006723-008020-131200"/>
        <VehicleJourneyRef ref="RUT:ServiceJourney:003565-004003-131500"/>
        ...
      </journeys>
    </Block>
    <Block version="20220908125021" id="RUT:Block:168197-59001muwt-202209080359000">
      <PrivateCode>59001</PrivateCode>
      <StartTime>01:59:00</StartTime>
      <EndTime>06:16:00</EndTime>
      <dayTypes>
        <DayTypeRef ref="RUT:DayType:2022-09-08"/>
      </dayTypes>
      <StartPointRef ref="RUT:ScheduledStopPoint:Fg" version="20220908125021"/>
      <EndPointRef ref="RUT:ScheduledStopPoint:Fg" version="20220908125021"/>
      <journeys>
      <DeadRunRef ref="RUT:DeadRun:006713-008006-035900"/>
      <VehicleJourneyRef ref="RUT:ServiceJourney:002521-002932-041700"/>
      ...
      </journeys>
    </Block>
  </blocks>
</VehicleScheduleFrame>

Example of NeTEx definition to find values for assignment-attempt-request.signOn

• DatedServiceJourneyId: RUT:DatedServiceJourney:a
  • path: PublicationDelivery/dataObjects/CompositeFrame/frames/TimetableFrame/vehicleJourneys/DatedServiceJourney/@id
• VehicleJourneyId: 505
  • path: PublicationDelivery/dataObjects/CompositeFrame/frames/TimetableFrame/vehicleJourneys/ServiceJourney/PrivateCode
• LineId: RUT:Line:1337
  • path: `PublicationDelivery/dataObjects/CompositeFrame/frames/ServiceFrame/lines/Line/@id
• DepartureDateTime: 2024-01-01T03:28:00+02:00
  • Use the date for when the journey is to be serviced and add the earliest DepartureTime found here:
  • PublicationDelivery/dataObjects/CompositeFrame/frames/TimetableFrame/vehicleJourneys/ServiceJourney/passingTimes/TimetabledPassingTime/DepartureTime

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PublicationDelivery>
  <dataObjects>
    <CompositeFrame>
      <frames>
        <ServiceFrame>
          <routes>
            <Route id="RUT:Route:007">
              <LineRef ref="RUT:Line:1337"/>
            </Route>
          </routes>
          <lines>
            <Line id="RUT:Line:1337">
            </Line>
          </lines>
          <journeyPatterns>
            <JourneyPattern id="RUT:JourneyPattern:123456">
              <RouteRef ref="RUT:Route:007"/>
            </JourneyPattern>
          </journeyPatterns>
        </ServiceFrame>
        <TimetableFrame>
          <vehicleJourneys>
            <ServiceJourney id="RUT:ServiceJourney:1">
              <JourneyPatternRef ref="RUT:JourneyPattern:123456"/>
              <PrivateCode>505</PrivateCode>
              <passingTimes>
                <TimetabledPassingTime>
                  <StopPointInJourneyPatternRef/>
                  <DepartureTime>03:28:00</DepartureTime>
                </TimetabledPassingTime>
                <TimetabledPassingTime>
                  <StopPointInJourneyPatternRef/>
                  <DepartureTime>03:31:00</DepartureTime>
                </TimetabledPassingTime>
                <TimetabledPassingTime>
                  <StopPointInJourneyPatternRef/>
                  <DepartureTime>03:33:00</DepartureTime>
                </TimetabledPassingTime>
              </passingTimes>
            </ServiceJourney>
            <DatedServiceJourney id="RUT:DatedServiceJourney:a">
              <ServiceJourneyRef ref="RUT:ServiceJourney:1"/>
              <OperatingDayRef ref="RUT:OperatingDay:2024-01-01"/>
            </DatedServiceJourney>
          </vehicleJourneys>
        </TimetableFrame>
      </frames>
    </CompositeFrame>
  </dataObjects>
</PublicationDelivery>

Example of NeTEx definitions to find

Sign On

• Any pre-existing assigned assignments will be signed off AssignmentState.assigned=true
• If the attempt request succeeds, the vehicle will be assigned the new plan AssignmentState.assigned=true
• If the attempt request fails, the state of the vehicle is AssignmentState.assigned=false
  • The reason for failing will be available under the response topic
• Contents of a signOn-attempt can now be based on vehicleTask, or a provided list of either DatedServiceJourneys or Journeys. If a list of DatedServiceJourneys or Journeys is provided, the provided vehicleTask is not included in the attempt
• Options for sign on:
  • Deprecated VehicleTask:
    • Please use a list of either DatedServiceJourneys or Journeys
    • Require the fields vehicleTaskId and serviceWindow.
      • vehicleTaskId: Can be found in the common file in the NeTEx export under this path VehicleScheduleFrame.blocks[].Block.PrivateCode
      • serviceWindow: Defines a time range for which journeys the vehicle should be signed on. The vehicle will be signed on to all the journeys in the vehicle task between provided times. Signed on journeys may be part of 1 or more Blocks. Times provided may belong to the same calendar date, or 2 consecutive dates. Attempts not containing valid date times for firstDepartureDateTime and lastArrivalDateTimes will be rejected, resulting in AssignmentState.assigned=false
  • A list of DatedServiceJourneys:
    • datedServiceJourneyId: Can be found in the respective Journey file in the NeTEx export (See above example xml)
    • serviceWindow: Optional: Defines a time range for which calls in the journey the vehicle should be signed on. If not provided, the entire journey is included
  • A list of Journeys. See above example on how to locate the fields in the NeTEx export:
    • vehicleJourneyId: Required if calls are not provided. Also known as 'turnummer'/trip number/privateCode of the journey.
    • lineId: Required if calls are not provided. Id for the line, e.g.: 'RUT:Line:32'. RUT:Line:0 can be used for DeadRuns
    • departureDateTime: Planned departure date time for the first call in the journey. This field is used to pinpoint the exact dated journey to be serviced
    • serviceWindow: Optional: Defines a time range for which calls in the journey the vehicle should be signed on. If not provided, the entire journey is included
    • calls: Optional: Used to create DeadRuns. Please provide a list of two or more calls.
      • quayId: Id of the quay (NSR:Quay:xxx) to be serviced or the depot (RUT/NBU)
      • arrivalDateTime: Required for all calls except the first call to be serviced
      • departureDateTime: Required for all calls except the last call to be serviced

Sign On - PLANNED

The vehicle will be signed on to service the pre-existing plans

Sign On - EXTRA

Used if additional vehicles are demanded to serve the pre-existing plans

Sign On - REPLACEMENT

Used if another vehicle can not service parts of its assignment. The operator should sign off the other vehicle using either SHORTENING or BREAKDOWN.

Note: Ruter will not sign off the other vehicle automatically.

Sign Off

Sign Off - FINISHED

The vehicle has serviced all journeys in the assignment

Sign Off - BREAKDOWN

The vehicle has broken down, or in some way not capable of servicing the rest of the assignment

Sign Off - CANCELLED

Remaining not serviced stops/journeys in the assignment will not be serviced (by the assigned vehicle).

Sign Off - SHORTENING

Same as CANCELLED

Additional Sign Off codes used by RUTER

• EXPIRED Given a successful signOn, if the vehicle is not signed off before two hours after the last planned arrival. The vehicle will be automatically signed off with the code EXPIRED.

Update

Update - SHORTENING

Operational change of a pre-existing assigned assignment for a vehicle.

Failed attempts will not affect the assignment state for a vehicle.

• serviceWindow is honoured as SignOn - PLANNED

Example case for SHORTENING

Given an assignment (vehicle plan) with two journeys:

Journey 1
Quay 1 dep 2023-04-27T10:00Z
Quay 2 arr 2023-04-27T10:01Z, dep 2023-04-27T10:01Z
Quay 3 arr 2023-04-27T10:02Z

Journey 2
Quay 3 dep 2023-04-27T10:03Z
Quay 2 arr 2023-04-27T10:04Z, dep 2023-04-27T10:04Z
Quay 1 arr 2023-04-27T10:05Z

When SHORTENING

{
    "eventTimestamp": "2023-04-27T12:40:12.631914Z",
    "traceId": "083b71c4-e417-11ed-b5ea-0242ac120004",
    "update":
    {
        "code": "SHORTENING",
        "serviceWindow":
        {
            "firstDepartureDateTime": "2023-04-27T10:02Z",
            "lastArrivalDateTime": "2023-04-27T10:03Z"
        }
    }
}

Then; both visits at Quay 3 will be removed from the assignment. The resulting assignment will be:

Journey 1
Quay 1 dep 2023-04-27T10:00Z
Quay 2 arr 2023-04-27T10:01Z, dep 2023-04-27T10:01Z

Journey 2
Quay 2 arr 2023-04-27T10:04Z, dep 2023-04-27T10:04Z
Quay 1 arr 2023-04-27T10:05Z

Effectively, the vehicle should turn around at Journey 1 Quay 2 and continue servicing Journey 2 from Quay 2

AssignmentOmitRequest Message

Field	Value
Central Topic	ruter/{operatorId}/back_office/adt/v3/operational/assignment/omit/request
Schema	assignment-omit-request.json
Producer	PTO
Consumer	Ruter Assignment
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

AssignmentOmitRequest Usage

Follows the request/response pattern. When a request is made to this topic, a response will be available at the response topic once Ruter has finished processing.

• All omit request will get an omit response under the response topic
• Please provide all fields marked as required in the schema specifications.
• Note that there are no vehicles involved in this exchange.

Omit - NO_INTENTION

Introducing the flag omit allows the operator to send omit=false to cancel an omit.

Inform Ruter that the PTO has no intention of servicing the journeys and stops defined by the provided service window.

• Contents of a omit can now be based on vehicleTask, or a provided list of DatedServiceJourneys.
  • If a list of DatedServiceJourneys is provided, the provided vehicleTask is not included in the omit
  • VehicleTask:
    • Require the fields vehicleTaskId and serviceWindow.
      • vehicleTaskId: Can be found in the common file in the NeTEx export under this path VehicleScheduleFrame.blocks[].Block.PrivateCode
      • serviceWindow: Defines a time range for which journeys the vehicle should be omitted.
  • A list of DatedServiceJourneys:
    • datedServiceJourneyId: Can be found in the respective Journey file in the NeTEx export (See above example xml)
    • serviceWindow: Optional: Defines a time range for which calls in the journey the vehicle should be signed on. If not provided, the entire journey is included
    • calls: Optional: Defines a list of calls by NSR:Quay:Id. This list can be used if only one call should be omitted, or the calls do not fall within one service windw

ActiveCab Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/pe/active_cab
Schema	active-cab.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

DoorLock Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/pe/door_lock
Schema	door-lock.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

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

Frequency: on change

DoorsIndividually Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/pe/doors_individually
Schema	doors-individually.json
Producer	PTO
Consumer	Ruter BO
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.

Apc Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/apc/{sensorId}
Schema	apc.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Door Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/door
Schema	door.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Frequency: on change

Location Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/location
Schema	location.json
Producer	PTO
Consumer	Ruter BO
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.

Odometer Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/odometer
Schema	odometer.json
Producer	PTO
Consumer	Ruter BO
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.

StopButton Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/stop_button
Schema	stop-button.json
Producer	PTO
Consumer	Ruter DPI
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

This message should be produced whenever the stop signal is turned on or off. Depending on whether the regular stop button is pressed or the blue accessebility button is pressed, a different signal should be produced.

Whenever the vehicle has serviced a stop, the signal is to be reset.

Frequency: on change

Telemetry Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/{telemetryId}
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

For telemetry not listed in the Available ADT Telemetry section below, refer to the FMS (Fleet Management System) standard documentation. However, before using the FMS standard directly:

• Check if the data point already exists in the MQTT API or ADT telemetry listed below.
• If not listed, contact Ruter to discuss potential implementation before defaulting to the FMS standard.

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

See topics with specific id for more information.

Telemetry ID	Telemetry Type
0001FF25	Charger (deprecated)
01000002	Temperature indoor
01000005	State of charge
01000006	Transmission mode
01000007	Windscreen wiper active
01000008	Accelerometry
01000009	Temperature outdoor
0100000A	Accumulated energy consumption

Charger Message (deprecated)

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/0001FF25
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

This has been deprecated and will be removed in the next major version. See´sensors/charging´ for information about new topic.

Describes the charging status and details of an electric vehicle.

Data specification

• Message frequency: On change

Payload details

• Name: Charger
• ID: 0001FF25

Sub ID	Name	Value Type	Description
10003	Wall charger connected	boolean	Indicates if connected to a wall charger
10004	Fast charger connected	boolean	Indicates if connected to a fast charger
10005	Charging active	boolean	Indicates if the vehicle is actively charging

Temperature Indoor Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/01000002
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the interior temperature of the vehicle.

Data specification

• Message frequency: 6 times per minute (6/min)
• Unit: Degrees Celsius (°C)
• Resolution: <= 1°C

Payload details

• Name: Temperature indoor
• ID: 01000002

Sub ID	Value Type	Description
tempavg	float	Average interior temperature
tempfront	float	Front interior temperature
tempmiddle	float	Middle interior temperature
temprear	float	Rear interior temperature

State of Charge Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/01000005
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the current charge level of the vehicle's battery.

Data specification

• Message frequency: Once per minute (1/min)
• Unit: Percentage (%)
• Resolution: <= 1%
• Range: 0% - 100%

Payload details

• Name: State of charge
• ID: 01000005

If vehicle has more than one battery use the sub id to identify them:

Sub ID	Name	Value Type	Description
N/A	State of charge	float	Only one battery in the given vehicle
1	State of charge	float	Battery 1
2	State of charge	float	Battery 2
(n)	State of charge	float	Battery (n)

Transmission Mode Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/01000006
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Intended for hybrid vehicles. Describes the current transmission mode of the vehicle.

Data specification

• Message frequency: On change
• Value: COMBUSTION or ELECTRIC

Payload details

• Name: Transmission mode
• ID: 01000006

Sub ID	Name	Value Type	Description
N/A	Transmission mode	string	Current transmisison mode, should be either COMBUSTION or ELECTRIC

Windscreen Wiper Active Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/01000007
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the activity of the windscreen wipers.

Data specification

• Message frequency: On change

Payload details

• Name: Windscreen wiper active
• Id: 01000007

Sub ID	Name	Value Type	Description
N/A	Windscreen wiper active	boolean

Accelerometry Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/01000008
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the vehicle's acceleration in three dimensions.

Data Specifications

• Message frequency: 6 times per minute (6/min)
• Bandwidth: ≥ 100 Hz
• Unit: g (gravity)
• Resolution: ≤ 0.01 g

Payload details

• Name: Accelerometry
• ID: 01000008

Sub Id	Value Type	Description
xmin	float	Minimum X-axis acceleration
xmax	float	Maximum X-axis acceleration
xavg	float	Average X-axis acceleration
ymin	float	Minimum Y-axis acceleration
ymax	float	Maximum Y-axis acceleration
yavg	float	Average Y-axis acceleration
zmin	float	Minimum Z-axis acceleration
zmax	float	Maximum Z-axis acceleration
zavg	float	Average Z-axis acceleration

Temperature Outdoor Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/01000009
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Measures the external temperature around the vehicle.

Data specification

• Message frequency: Once per minute (1/min)
• Unit: Degrees Celsius (°C)
• Resolution: <= 1°C

Payload details

• Name: Temperature outdoor
• ID: 01000009

Sub ID	Name	Value Type	Description
N/A	Temperature outdoor	float	External temperature measurement

Accumulated Energy Consumption Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/telemetry/0100000A
Schema	telemetry.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes total energy consumption by the vehicle.

Data specification

Energy consumed including HVAC

• Message frequency: Once per minute (1/min)
• Unit: kWh

Payload details

• Name: Accumulated energy consumption
• ID: 0100000A

Value Type	Description
float	Accumulated energy consumption

Charging Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/charging
Schema	charging.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the charging status and details of an electric vehicle. The message includes information about whether the vehicle is connected to a charging point, if it's actively charging, and the current charging effect in kilowatts (kW).

Data specification

Message frequency:

• Messages should be sent on change, i.e., when there's a change in connection status, charging status, or a change in charging effect more or equal to 10kW.

Properties:

• isConnected:

  • Boolean value indicating if the vehicle is connected to a charging point

• isCharging:

  • Boolean value indicating if the vehicle is actively charging

• chargingEffect:

  • Unit: Kilowatts (kW)
  • Resolution: Minimum one decimal (<=0.1kW)
  • Range: >=0.0kW

Temperature Water Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/temperature/water
Schema	temperature-water.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the water temperature in Celsius, measured 1 meter below the water surface. The value should be a float with a resolution of 1°C or better.

Data specification

• Message frequency: 1 message per minute (1/min)
• Unit: Celsius
• Resolution: <= 1°C
• Measurement depth: 1 meter below the water surface

Wind Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/sensors/wind
Schema	wind.json
Producer	PTO
Consumer	Ruter BO
Service Level	✅ External API. Restrictions apply. Only backward compatible changes may happen within the major version.

Describes the wind speed and direction measured on the vehicle. The wind speed should be reported in meters per second ( m/s) as a float with a resolution of 0.1 m/s or better. The wind direction should be reported in degrees from true north (0-359°) as an integer.

Data specification

Message frequency:

• 1 message per minute (1/min)

Properties:

• speed

  • Unit: meters per second (m/s)
  • Resolution: <= 0.1 m/s

• direction:

  • Unit: degrees from true north
  • Range: 0-359°
  • Resolution: 1°

Destination Display Override Message

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

Acknowledge Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/pe/dpi/ack
Schema	dpi-acknowledge.json
Producer	PTO, Ruter DPI
Consumer	Ruter 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 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

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)

Diagnostics Message

Field	Value
Central Topic	ruter/{operatorId}/{vehicleId}/adt/v3/pe/dpi/diagnostics
Schema	dpi-diagnostics.json
Producer	Ruter DPI
Consumer	Ruter DPI
Service Level	⛔ Ruter internal API. No restrictions apply. Api may be removed or modified freely by Ruter within major version.

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.