INTRODUCTION

The ODEx (Onboard Data Exchange) protocol is a set of specifications for the exchange of real time vehicle data, which can be categorized either as 1) Inventory and Status Data, 2) Information about the Software and Configuration or other Data of Equipment Items and Applications and their Updates, and 3) Operational Data, which includes data concerning the physical vehicle (obtained from the vehicle CAN buses and vehicle signals and sensors) and data related to the PT services run by the vehicle (Network Location, Driver Log on, passenger counting, ticketing data…).

An OPI is a set of inputs (called generically commands) and outputs (operational data grouped into DataGroups) of a Provider for a specific operational function - such as ticket validation, GNSS positioning, passenger counting, or any other logical grouping of inputs and outputs of a Provider that is useful for the purposes of operational information exchange. For more explanation and context see the document ODEx-1.

ODEx-4, this document, specifies ODEx Operational Interfaces.

ODEx Documents

Document

Contents

ODEx-1. Concepts and Functional Architecture

Core Concepts, functional specification and topic structure

ODEx-2. Network Requirements

Onboard IP Network requirements to support ODEx onboard communication

ODEx-3. Inventory and Updates Interfaces

Inventory, status and updates interfaces data definitions

ODEx-4. Operational Interfaces (This document)

Operational interfaces data definitions and topics

ODEx-5. Usage and Examples

Practical guidelines and implementation examples

Table 1.- ODEx Documents

Document content

The specification of OPIs is divided into the following domains:

Operational Data Domains

Content

Physical Vehicle

Vehicle Telemetry

Information related to the physical vehicle and its base (non ITS) equipment: vehicle static data (ID, vehicle specifications) CAN J1939 data, GNSS data, data from sensors (e.g. odometer, accelerometer, internal thermometers…) and data from signals (e.g. ignition, doors status).

Vehicle PT Operation

Ticketing

Validation and ticket sales transactions and other information related to ticketing

Vehicle Service Monitoring

Information related to the service run by the vehicle: network location, driver, vehicle journeys and calls observed, monitored and estimated, status with respect to planned and target services vehicle service assigmnet and driver messages.

Occupancy

Passenger counting, %occupancy, passenger density, occupancy status (e.g. vehicle full)

External information relevant to be published onboard

(Future)

Ambient Conditions

External ambient conditions: temperature, relative humidity, atmospheric pressure, meteorology conditions and predictions, air quality or others that can be published onboard and used by a passenger information system to inform passengers onboard or by other systems to log data with ambient conditions metadata.

Facilities monitoring

Incidents in public transport facilities (e.g. elevator not working) published onboard for passenger information.

Incidents and events

Incidents (e.g. cancelation of services, delays ) and events affecting other services which can be relevant for passenger information onboard

Table 2.- Operational Data Domains

Note: A summary list of OPIs can be found in #Anexo B. OPIs Catalog

COMMON

OPI Topic Structure & DataGroups

OPI Topic Structure

A Provider may have one or more OPIs. Each OPI of a Provider has its own topics under its Provider GUID and OPI name and version:

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>

The structure of topics under /<OPI_name>/<OPI_version> is divided into two branches:

  • /<OPI_name>/<OPI_version>
    • /data for operational data messages published by the OPI (DataGroups).
    • /cmd for command requests to the OPI and responses from the OPI.

Under these branches, each OPI may define additional nested structures depending on its specific needs, as follows:

  • /<OPI_name>
    • /<OPI_version>
      • /cmd (if any)
        • /<cmd1_name> (one topic for each command)
          • /<sender_GUID> (each sender sends the command to its own topic under the command topic)
          • /response (here the sender will receive a response to the command it has sent)
          • /<sender_GUID>
          • /response
        • /<cmd2_name>
          • /<sender_GUID>
          • /response
        • Etc.
      • /data
        • /<DataGroup1_topic_name**>_all (Example network_location_all. The suffix “_all” is added to the DG name when the OPI publishes all data in a single DataGroup)
        • /<DataGroup1_topic_name**> (one topic for each DataGroup, if there is more than one, without the “all” prefix)
        • /<DataGroup2_topic_name**>
        • Etc.

** Each DataGroup is published to a different topic with a name derived from the DataGroup name. E.g. for the OPI validator we have the DataGroup validator_transactions and the DataGroup validator_op_parameters. The topics to publish these DGs will be validator/<OPI_version>/data/transactions and validator/<OPI_version>/data/op_parameters respectively. See Section #2.1.2. DataGroups (DG).

Figure 1.- OPI Topic structure within the global ODEx structure
Figure 1.- OPI Topic structure within the global ODEx structure

The following is an example of a topic structure under <root>/operation/<provider_GUID> for the OPI “Validator”:

Descripción de la imagen

DataGroups (DG)

A DataGroup is a set of operational data published simultaneously in a single message.

DataGroups are primarily defined to ensure data consistency. For example, GNSS parameters such as latitude, longitude, dilution of precision, and satellite count are grouped together in one DataGroup because they are interrelated and must be published in the same message to provide consumers with consistent information.

In other cases, DataGroups are defined for convenience. For example, while the status of each bus door could be published separately in different topics, consumers will usually require the status of all doors and wheelchair ramps, and in most cases a single Provider supplies all this information. For these reasons, a DataGroup is defined to publish the status of all doors and ramps in a single message (DoorsStatus). Nevertheless, the fields in this DataGroup are optional, so if more than one Provider supplies this information, each will populate the DataGroup with the subset of data it is able to provide.

Each DataGroup is published to a different topic with a name derived from the DataGroup name or vicecersa. Therefore, it might not replicate the exact name of the topic. E.g. for the OPI validator we have the DataGroup ValidatorTransaction and the DataGroup ValidatorOpParameters. The topics to publish these DGs will be validator/<OPI_version>/data/transaction and validator/<OPI_version>/data/op_parameters respectively.

Data Streaming

For data which can be published very frequently (“streamed”), such as some CAN messages or acceleration data, the structure under each DataGroup topic consists of two topics:

Topics for DG with “streamed” data

Content

/stream_info

The standard JSON is published to this topic, including static or slow changing information which is common to all data published to /stream_data, which includes at least the time reference for the timestamp of the data samples published in /stream_data.

/stream_data

The DG “streamed” data is published to this topic using a non-standard, more compact, JSON structure, consisting only of a list of data samples, each one consisting of an array of data elements. Fon instance, in the case of Accelerations, each sample will include the timestamp and the X, Y and Z accelerations.

Table 3.- Topics under DataGroups pubished frequently (“streamed”)

  • /<OPI_name> (Examples: /accelerations, /raw_pgn)
    • /<OPI_version>
      • /cmd (if any)
      • /data
        • /<DataGroup1_topic_name> (Examples: /accel_raw or /feee = <pgn hex string>)
          • /stream_info (information which is common to all data streamed)
          • /stream_data (published in a compact JSON)
        • /<DataGroup1_topic_name> (Examples: /accel_vehicle or /f002 = <pgn hex string>)
          • </stream_info>
          • /stream_data (a compact JSON structure is used to publish frequent, streamed, data)
        • Etc.

Publication Rules

Data messages must be sent with QoS1 and with retain. Exceptions to this rule will be indicated for specific data, if any.

Command messages and responses must be sent with QoS2 and without retain; i.e. the command must be received only once by the Provider and the response must be received only once by the command sender. Exceptions to this rule will be indicated for specific commands, if any.

Common Message Format in /data and /cmd

ODEx uses the JSON format to publish messages.

ODEx data and command JSON Structure

<Common fields for every ODEx JSON data or command message>

<Specific ODEx DataGroup or Command fields>

Table 4.- ODEx data and command general JSON structure

Following the conventions defined in #ODEx-3, every OPI message (whether published under /data or /cmd) starts with common JSON fields (grey background colour) to ensure consistency, traceability, and automated responses, followed by OPI specific DataGroup or command fields:

Common Message Format Fields

+Structure

Description

timestamp

1:1

DateTime

Timestamp of the message (see DateTime in Data Types)

topicPath

1:1

String

Full MQTT topic path where this message is being published

messageId

(See description)

String

Message UUID. Mandatory in command topics but could also be needed in data topics.

<specific field>

<Specific ODEx DataGroup or Command fields>

<specific field>

Etc.

Table 5.- ODEX data and command detailed JSON structure (messageId is only mandatory in command topics)

JSON example:

{
    "timestamp": "2025-05-27T11:28:15Z", /* Mandatory */
    "topicPath": <exact MQTT topic path where the message is published>, /* Mandatory */
    "messageId": "message UUID" /* Mandatory in command topics but could also be needed in data topics */
    /* +Specific fields which vary depending on the DataGroup */
    }

Notice that there is no version field because all data and commands are published under an OPI version topic. This allows to work with more than one version if required.

Command Requests

As described in ODEx-1, each command is published by the sender to a topic ending with their sender_GUID, placed directly below the command name.

The command sender will:

  • Publish the command in

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>/cmd/<command_name>/<sender_GUID>

  • And receive the response of the Provider that implements such OPI on

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>/cmd/<same_command_name>/<sender_GUID>/response

  • It can listen to all responses of its commands related to that Provider OPI by being subscribed to

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>/cmd/+/<sender_GUID>/response

The Provider that expects to receive commands will:

  • Listen to all commands sent by others to a specific OPI

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>/cmd/+/+

  • Listen to all commands sent by others to all of his OPIs

<root>/operation/<provider_GUID>/+/+/cmd/+/+

  • Answer to the commands received by publishing in the /response topic under that same command it received

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>/cmd/<command_name>/<sender_GUID>/response

Command Responses

As specified in the section before, the Provider OPI which receives a command will publish a response to:

<root>/operation/<provider_GUID>/<OPI_name>/<OPI_version>/cmd/<command>/<sender_GUID>/response

All response payloads must include the following fields:

Common Response Fields

+Structure

Description

<Common fields for every JSON command message>**

commandResult

1:1

String (Enum)

Result of the request command. See the following possible enums: OK | NOK

rejectionCode

0:1

Integer

Rejection code only if result is "NOK". See next table of possible rejection codes.

rejectionDescription

0:1

String

Optional human-readable error message

details

0:1

String

Optional debug information or notes.

responseContent

-

anyType

In command responses where some fields are required to be returned, they will be in the responseContent field structure.

Table 6.- ODEx command response JSON structure

Common rejection code references are the following:

Code

Meaning

0

OK

1

FAILED

2

BUSY

3

PARAMETER_ERROR

4

NOT_SUPPORTED

5

FORMAT_ERROR

6

OPERATION_ALREADY_EXECUTED

7

TIMEOUT

8

CANCELLED

9

QUEUE_OVERFLOW

10

DENIED

11

NOT_CONFIGURED

12

COMMAND_EXPIRED

(Extensions)

Table 7.- Rejection code references and meaning

Cardinality Notation Used for the JSON fields

Cardinality

Meaning

0:1

Optional field, zero or one occurrence. If included, supply exactly one non-array value. If not included, remove both, the tag and the value.

1:1

Mandatory field, exactly one occurrence. It must appear once and carry a single non-array value.

The 1:1 cardinatility of a field inside a structure only applies if the structure is published, as the structure may have 0:1 cardinality.

0:*

Optional array, zero or more elements. The array itself may be absent; if present it may be empty [] or have any length.

1:*

Mandatory array, at least one element. The field must be present and the array must contain ≥ 1 items.

Table 8.- Cardinality notation used for the JSON fields

Note: The concept of mandatory and optional fields indicates whether a piece of data must always be included in the JSON or not. An optional JSON field (0:1) means that the field may or may not appear in the message structure. However, this does not necessarily mean that the information is optional for the project. For example, the field ramp_status is mandatory for buses equipped with a ramp (it must be present in those vehicles), but it will be absent from the JSON messages of vehicles that do not have a ramp

Data Types Used for the JSON fields

Notation

Description

String

UTF-8 text

String (Enum)

UTF-8 text restricted to a predefined set of literal values

Integer

Whole number (positive or negative).

Use a wider range (e.g., 64-bit) only when the field explicitly requires it.

Float

Numbers with a decimal point (positive or negative).

Boolean

true / false

DateTime

ISO-8601 UTC E.g. 2025-05-27T11:28:15Z

Object

JSON object (unordered key-value map)

anyType

Freely defined extension field (must be valid JSON)

Table 9.- Data types used for JSON fields

Naming notation

Concept

Naming notation

Examples

OPIs

OPIS are named using snake_case (lower case letters and underscore)

network_location

In tittles, OPIs are named using Title Case

OPI Network Location

DataGroups

DataGroups are named using UpperCamelCase

NetworkLocationAll

Commands

Commands are named using snake case (lower case letters and underscore)

lock_validation

Topics

Topics are named using snake_case (lower case letters and underscore)

/network_location

/lock_validation

Variables and enums

Variables and enumerations are named using lowerCamelCase

journeyPatternRef

Table 10.- Naming notation for OPIs, DataGroups, Commands, Topics and Variavles

Common messages publication Triggers

ODEx messages are published based on predefined conditions known as triggers. The most common triggers are the following:

Trigger type

Description

startup

Triggered immediately after the MQTT client used by the Provider is connected to the broker.
This occurs at power-on of the Equipment Item hosting the Provider, after a reset of the Equipment Item, or after a broker reset or reconnection.

periodic

Triggered periodically at fixed time intervals (e.g. GNSS data published every 1s). If no value is defined in ODEx, it should be defined in the project.

discrete change

Triggered when at least one discrete variable of a Datagroup (e.g. boolean, enumerated, string, identifier) changes value. The complete DataGroup must be published reflecting the new values.

threshold change

Triggered when both of the following conditions are met:

  • The value of at least one continuous (numeric) variable within the DataGroup has changed by more than an optional, predefined change threshold with respect to the last published value. (If no change threshold is defined in ODEx, it can be established in the project if needed); and
  • At least T = 100 ms have elapsed since the previous publication of the same DataGroup, ensuring that the publication rate of any DataGroup does not exceed 10 messages per second.

When this trigger occurs, the Provider shall publish the entire DataGroup, reflecting the updated values.

Variables whose values need to be sampled more frequently (for example, hvessCurrent, every 20 ms or raw PGNs) should be included in specific DataGroups that, although published at intervals of 100 ms or longer, contain in each publication all the required values of the variable, each timestamped and recorded at the desired sampling rate. For example, if a value is required every 20 ms, the DataGroup published every 100 ms will include 5 recorded samples.

request

When explicitly requested (i.e. Publication on demand)

other

E.g. Publication triggered by movement or distance

Table 11.- Types of ODEx messages publication triggers

Versioning Rules in ODEx OPIs

An OPI version should be changed in the following cases:

  • The meaning of an existing field is changed.
  • A previously defined field is removed.
  • The data type of a field is changed (e.g., Boolean → String).
  • A new field is added which is mandatory

It is possible to add new, project specific, fields to ODEx JSON structures without changing the OPI version, as long as the new field is not mandatory (et least for preexisting Providers and consumers).

Other considerations for project specific new fields:

  • The Providers and consumers installed in the project will know how to use new fields
  • All ODEx Consumers must tolerate unknown fields. If a new field is added to a JSON, pre-existing consumers which do not know the new field must ignore it.
  • This document should be updated for the project with the new fields

OPIs SPECIFICATION DESCRIPTION FORMAT

OPIs will be described in next sections using the following format for each OPI:

OPI <OPI Name>

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

<OPI_name>

<DG1Name> (DataGroup1 name)

  • General description of data in DataGroup1
  • Trigger: Conditions to publish DataGroup1 (According to Table 11.- Types of ODEx messages publication triggers, e.g. at startup, periodically every XX s, etc.)

<DG2Nname> (DataGroup2 name)

  • General description of data in DataGroup2
  • Trigger: Conditions to publish DataGroup2

(List of commands accepted)

  • command_1_name
  • command_2_name

OPI version

<OPI_version>

Table 12.- <OPI> OPI summary

(Case of OPIs which publish more than one DataGroup)

<DG1Name> DG

<root>/operation/<provider_guid>/<OPI_name>/<OPI_version>/data/<DG1_name>

Table 13.- Topic path for <DG1Name>DG

<DG1_name>

+Structure

Description

<Common fields for every JSON data message>**

<specific field>

Cardinality

Type

Description

<specific field>

Cardinality

Type

Description

Etc.

Table 14.- <DG1_name> DG message structure

**Common fields are not shown at each OPI description as they are always the same, as described in section #2.2

<DG2Name> DG

<root>/operation/<provider_guid>/<OPI_name>/<OPI_version>/data/<DG2_name

Table 15.- Topic path for <DG2Name> DG

<DG2_name>

+Structure

Description

<Common fields for every JSON data message>**

<specific field>

Cardinality

Type

Description

<specific field>

Cardinality

Type

Description

Etc.

Table 16.- <DG2_name> DG message structure

Etc. for the rest of DataGroups published.

In the case few commands are present in an OPI, the same format specified in the section before for /data will be used, first stating the topic path for such command, and then the corresponding Fields table for that command topic:

(example with an OPI that only has 2 commands)

<command_1_name> command

<root>/operation/<provider_guid>/<OPI_name>/<OPI_version>/cmd/<command1_name>

Table 17.- Topic path for <command_1_name> command

<command_1_name>

+Structure

Description

<Common fields for every JSON data message>**

<specific field>

Cardinality

Type

Description

<specific field>

Cardinality

Type

Description

Etc.

Table 18.- <command_1_name> command message structure

<command_2_name> command

<root>/operation/<provider_guid>/<OPI_name>/<OPI_version>/cmd/<command2_name>

Table 19.- Topic path for <command_2_name> command

<CMD2_name> Structure: (if any)

<command_2_name>

+Structure

Description

<Common fields for every JSON data message>**

<specific field>

Cardinality

Type

Description

<specific field>

Cardinality

Type

Description

Etc.

Table 20.- <command_2_name> command message structure

Etc. for the rest of Commands published.

If an OPI has many commands, instead of describing each command topic and structure separately, they are described in a single table with the following format:

Topic under …/<OPI_name>/<OPI_version>/cmd

Specific Fields**

+Structure

Description

<Common fields for every JSON data message>

/<command_1_name>

<command_1_field_1_name>

Cardinality

Type

Field description

/<command_2_name>

<command_2_field_1_name>

Cardinality

Type

Field description

<command_2_field_2_name>

Cardinality

Type

Field description

<command_2_field_3_name>

Cardinality

Type

Field description

/<command_3_name>

<command_3_field_1_name>

Cardinality

Type

Field description

Table 21.- <OPI> OPI commands and fields

** Fields additional to the common fields as described in Section #2.2 Common Message Format in /data and /cmd

Therefore, in this case, the JSON for <command_2_name> that is not made explicit in the document would be the following:

<command_2_name>

+Structure

Description

<Common fields for every JSON data message>

< command_2_field_1_name>

Cardinality

Type

Description

<command_2_field_2_name>

Cardinality

Type

Description

<command_2_field_3_name>

Cardinality

Type

Description

Table 22.- Derived <command_2_name> command fields message structure

VEHICLE TELEMETRY OPIs

OPI Vehicle Static Information

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

vehicle_static_info

VehicleId

  • VIN, PTO/PTA IDs, license plate, fleet/internal IDs, vehicle type.
  • Trigger: at startup and on discrete change

VehicleSpecs

  • One single JSON with: make and model, dimensions and weight, power plant, energy sources, passenger area, HVAC info.
  • Trigger: at startup and on discrete change

CanDataAvailable

  • List of PGNs discovered. It may be published in several parts, as PGNs are read from the CAN bus
  • Trigger: at startup and on discrete change

SignalsAvailable

  • Catalog of available signals.
  • Trigger: at startup and on discrete change
  • none

OPI version

v1.0

Table 23.- OPI Vehicle Static Information summary

VehicleId DG

<root>/operation/<provider_guid>/vehicle_static_info/<OPI_version>/data/vehicle_id

Table 24.- Topic path for VehicleId DG

VehicleId

+Structure

Description

<Common fields for every JSON data message>

vehicleRef

1:1

String

ID of the vehicle unit. VIN for bus.

licensePlate

1:1

String

Registration plate.

ptoVehicleId

1:1

String

Operator (PTO) vehicle ID.

ptaVehicleId

1:1

String

Authority (PTA) vehicle ID.

fleetNumber

1:1

String

Internal fleet number.

vehicleType

0:1

String (Enum)

bus | coach | tram | other (TBD more types as needed)

additionalInfo

0:1

String

Free text notes.

Table 25.- VehicleId DG message structure

VehicleSpecs DG

<root>/operation/<provider_guid>/vehicle_static_info/<OPI_version>/data/vehicle_specs

Table 26.- Topic path for VehicleSpecs DG

VehicleSpecs

+Structure

Description

<Common fields for every JSON data message>

makeModel

0:1

Object

Make & model object

manufacturer

1:1

String

Vehicle manufacturer brand (e.g., “Iveco Bus”, “Irizar”)

model

1:1

String

Model family/commercial name (e.g., “Crossway LE”, “i4”). Do not include length here

variant

0:1

string

Commercial variant label; may include length and use-case (e.g., “LE City 12 m”, “LE Line 12 m”)

homologationStep

0:1

String

Emission stage or propulsion label (e.g., “Euro VI Step E”, “Hybrid”, “CNG”, “BEV”)

axleConfig

0:1

String

Axle/drive layout (e.g., “4×2”, “6×2”)

dimensionsWeight

0:1

Object

Dimensions and Weight information

length

1:1

Integer

Vehicle length (mm)

width

0:1

Integer

Vehicle width (mm)

height

0:1

Integer

Vehicle height (mm)

wheelbase

0:1

Integer

Wheelbase (mm)

curbWeight

0:1

Integer

Vehicle weight with all standard equipment, but no passengers or cargo (kg)

grossCombinationWeight

0:1

Integer

Gross Combination Weight (kg).

powerPlant

0:1

Object

Power-plant related information

propulsionType

1:1

String (Enum)

Primary propulsion type: diesel | cng | hybrid | batteryElectric | fuelCell | other

engineModel

0:1

String

Manufacturer/model of the prime mover (ICE engine or electric family, include variant if known).
Examples: Cummins ISB6.7 280, Volvo D13K-500

maxPower

0:1

String

Rated power of the ICE (Internal Combustion Engine) or traction motor for BEV/hybrid. Example: “265 kW (360 hp) @ 2000 rpm”

maxTorque

0:1

String

Rated torque for ICE or e-motor where given (units: Nm). Example: “1600 Nm @1200 rpm”

emissionClass

0:1

String

Regulatory emission standard of the combustion engine.
Examples: Euro VI, Euro V...

driveLayout

0:1

String

Driven-wheel configuration. Typical format AxleCount x DrivenWheels (e.g., 4x2, 6x2, 6x4)

displacement

0:1

String

Engine displacement (ICE only) (E.g.: “8.7 litres”

energySources

0:1

Object

Energy sources information

energySourceType

1:1

String

One source: dsl | lpg | cng | prop | elec | h2 |

Hybrid: dslElec | lpgElec | cngElec | propElec |

Bi-fuel: dslLpg | dslCng |

fuelCapacity

0:1

Integer

Diesel fuel tank capacity (L)

cngTank

0:*

Integer

Mandatory in CNG vehicles

cngTankCapacity

1:1

Integer

CNG tank capacity as mass (kg)

cngTankLocation

1:1

String

Location of CNG Tank

h2Tank

0:*

Object

Mandatory in H2 vehicles

h2TankCapacity

1:1

Integer

H2 tank capacity as mass (kg)

h2TankLocation

1:1

String

Location of H2 Tank

hvess

0:*

Object

Mandatory in electric vehicles

batteryCapacity

1:1

Integer

Battery nominal capacity (units: kWh)

batteryChemistry

1:1

String

Battery chemistry if disclosed (e.g., LFP, NMC)

batteryLocation

1:1

String

Location of battery and access method

passengerArea

0:1

Object

Passenger area section

seatedCapacity

1:1

Integer

Number of passenger seats for the reference layout of the chosen variant (count)

standingCapacity

1:1

Integer

Standing places (count).

wheelchairPositions

1:1

Integer

Wheelchair (PMR) spaces (count).

hasRamp

1:1

Integer

Number of doors equipped with wheelchair ramp

doorCount

1:1

Integer

Number of service doors (count).

doorDescription

0:1

String

Free-text door description field If the sheet provides per-door widths/heights (e.g., “Front & middle doors 1,200 mm” for LE City; “Front 800 mm, middle 1,200 mm” for LE Line)

hvac

0:1

Object

HVAC information.

acPresent

0:1

Boolean

Air conditioning present (true/false).

heatingType

0:1

String (Enum)

Passenger-area heating technology. Recommended enum: dieselHeater | heatPump | electricResistance | other

Otherwise map from the OEM wording (e.g., “Four heaters for the passenger compartment”

Table 27.- VehicleSpecs DG message structure

CanDataAvailable DG

<root>/operation/<provider_guid>/vehicle_static_info/<OPI_version>/data/can_data_available

Table 28.- Topic path for CanDataAvailable DG

CanDataAvailable

+Structure

Description

<Common fields for every JSON data message>

pgnsDiscovered

0:*

Object

List of PGNs discovered

rawPgnHexString

1:*

String

Hex string with uppercase characters, without spaces, representing the 29bits CAN Identifier+1 byte Data Length Code+8 bytes of Data. Example “18FEEE17085A4B1027FFFFFFFF

(For most PGNs (8 data bytes PGNs) a single string will be published but for larger PGNs more strings are needed: the first BAM string plus one or more sequence strings)

pgnPeriod

1:1

Integer

PGN occurrence period on the CAN bus, in ms

Table 29.- CanDataAvailable DG message structure

SignalsAvailable DG

<root>/operation/<provider_guid>/vehicle_static_info/<OPI_version>/data/signals_available

Table 30.- Topic path for SignalsAvailable DG

SignalsAvailable

+Structure

Description

<Common fields for every JSON data message>

signalList

0:*

Object

List of available signal descriptors. Each item has the following fields.

signalName

1:1

String

Signal name according to the catalog of signals (See OPI Raw Vehicle Signals).

signalInformation

0:1

String

Required if signal is not in the catalog (Other).

Table 31.- SignalsAvailable DG message structure

OPI CAN Raw PGN

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

raw_pgn

Each PGN data is published to a different DataGroup named as the hex string PGN (e.g. feee)

<Hex PGN>

  • Requested J1939 PGNs, indicating for each PGN:

TimeStamp in microseconds

Raw Hex String of the PGN

  • Trigger: For PGNs published in the CAN bus with a period greater than 100ms the corresponding RawPGNMessage will be published in ODEx each time a new PGN is read from the CAN bus (even if it has the same value as the last published). For other, more frequent, PGNs, the corresponding RawPGNMessage will be published in ODEx periodically every 100ms including all PGNs read in the period form the CAN bus, timestamped.

Note: Requested RawPGNMessages will be published in ODEx until a stop_pgn command is received and after a timeout of 60s. If required, it should be requested again before the timeout.

  • request_pgn
  • stop_pgn

OPI version

v1.0

Table 32.- OPI CAN Raw PGN summary

RawPGNMessage DG stream_info

<root>/operation/<provider_guid>/raw_pgn/<OPI_version>/data/<PGN hex string>/stream_info

Table 33.- Topic path for RawPGNMessage DG stream_info

RawPGNMessage Stream Info

+Structure

Description

<Common fields for every JSON data message>

pgn

1:1

String

Hex string with uppercase characters, without spaces, representing the 2 bytes PGN, e.g. FEEE if the complete data were 18FEEE17085A4B1027FFFFFFFF

pgnSource

0:1

String

Hex string with uppercase characters, without spaces, representing Source byte, e.g. 17

pgnStreamTimeRef

1:1

DateTime

Reference time for the Timestamps of the data. It is the date of the start of the vehicle session.

Adding the timestamp of a data element in the stream to this time will result in the absolute DateTime for this data element

Table 34.- RawPGNMessage DG stream_info message structure

RawPGNMessage stream_data

<root>/operation/<provider_guid>/raw_pgn/<OPI_version>/data/<PGN hex string>/stream_data/

Table 35.- Topic path for a RawPGNMessage DG data Stream

RawPGNMessage Stream Data

+Structure

Description

Samples

1:*

Array

[0]

1:1

Integer

Timestamp in microseconds relative to pgnStreamTimeRef

[1]

1:1

String

Hex string with uppercase characters, without spaces, representing the 8 bytes PGN data, e.g. 5A4B1027FFFFFFFF

For most PGNs (8 data bytes PGNs) a single string will be published but for larger PGNs more strings are needed, the first BAM string plus one or more sequence strings.

[2…N]

0:*

String

Additional data represented as Hex string with uppercase characters, without spaces.

Only used in multi-packet PGNs.

Table 36.- RawPGNMessage DG stream_data message structure

request_pgn command

<root>/operation/<provider_guid>/raw_pgn/<OPI_version>/cmd/request_pgn/<sender_GUID>

Table 37.- Topic path for request_pgn command

request_pgn

+Structure

Description

<Common fields for every JSON cmd message>

pgn

1:1

String

Parameter Group Number (hex. Example FEEE)

Table 38.- request_pgn command message structure

stop_pgn command

<root>/operation/<provider_guid>/raw_pgn/<OPI_version>/cmd/stop_pgn/<sender_GUID>

Table 39.- Topic path for stop_pgn command

stop_pgn

+Structure

Description

<Common fields for every JSON data message>

pgn

1:1

Integer

Parameter Group Number (hex. Example FEEE).

Table 40.- stop_pgn command message structure

OPI Raw Vehicle Signals (digital)

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

raw_vehicle_signals

VehicleSignalName

  • Status of each of the vehicle digital signals acquired by the Provider
  • Trigger: at startup and on discrete change
  • none

OPI version

v1.0

Table 41.- OPI Raw Vehicle Signals (digital) summary

VehicleSignalName DG

Each signal is published in a topic with its Leaf Topic Name from the Vehicle Signals Catalog:

<root>/operation/<provider_guid>/raw_vehicle_signals /<OPI_version>/data/<vehicle_signal_leaf_topic_name>

Table 42.- Topic path for each Vehicle Signal

Then, the field to publish will be the Field Name from the Vehicle Signals Catalog:

VehicleSignalName (for a specific Field Name)

+Structure

Description

<Common fields for every JSON data message>

<vehicleSignalFieldName>

1:1

String

high | low | unavailable | unknown

Table 43.- VehicleSignalName DG message structure

Note: The VehicleSignalName DataGroup fields entirely depend on the Field Name from the Vehicle Signals Catalog. While the name of the topic depends on the equivalent Leaf Topic Name

Vehicle Signals Catalog

Field Name

Leaf Topic Name

Field Name

Leaf Topic Name

manualSwitchStatus

manual_switch_status

ramp3Status

ramp_3_status

mainSwitchStatus

main_switch_status

door4Status

door_4_status

ignitionSwitchStatus

ignition_switch_status

door5Status

door_5_status

fullPowerAvailableStatus

full_power_available_status

door6Status

door_6_status

lowBatteryStatus

low_battery_status

stopRequestStatus

stop_request_status

doorsStatus

doors_status

rampRequestStatus

ramp_request_status

rampsStatus

ramps_status

motorRunningStatus

motor_running_status

door1Status

door_1_status

presenceHVStatus

presence_hv_status

ramp1Status

ramp_1_status

reverseStatus

reverse_status

door2 Status

door_2_status

silentAlarmRequestStatus

silent_alarm_request_status

ramp2Status

ramp_2_status

luggageCompartmentDoorStatus

luggage_compartment_door_status

door3Status

door_3_status

(other)

Table 44.- Vehicle Signals (digital) Catalog: with its Field Name and Leaf Topic Name

Example 1 for ignitionSwitchStatus vehicle signal, published in:

<root>/operation/<provider_guid>/raw_vehicle_signals /<OPI_version>/data/ignition_switch_status

Table 45.- Topic path for ignitionSwitchStatus

VehicleSignalName (ignitionSwitchStatus)

+Structure

Description

<Common fields for every JSON data message>

ignitionSwitchStatus

1:1

String

Table 46.- ignitionSwitchStatus message structure

Example 2 for ramp1Status vehicle signal, published in:

<root>/operation/<provider_guid>/raw_vehicle_signals /<OPI_version>/data/ignition_switch_status

Table 47.- Topic path for ramp1Status

VehicleSignalName (ramp1Status)

+Structure

Description

<Common fields for every JSON data message>

ramp1Status

1:1

String

Table 48.- ramp1Status message structure

OPI Gnss

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

gnss

GnssLocationAll

  • GNSS metrics in a single message: Raw data, coordinates, altitude, speed, heading, date_time and information about the quality of these data.
  • Trigger: periodically, once per second.
  • none

OPI version

v1.0

Table 49.- OPI Gnss summary

GnssLocationAll DG

<root>/operation/<provider_guid>/gnss/<OPI_version>/data/gnss_location_all

Table 50.- Topic path for GnssLocationAll DG

GnssLocation

+Structure

Description

<Common fields for every JSON data message>

gnssRawData

0:1

String

Raw data as defined in the relevant GNSS, for example GPS NMEA 0183 or 2000 frames. At most one occurrence of each frame type shall be provided.

rawDataType

0:1

String

Type of data specification used for raw data

latitude

1:1

Object

Latitude value

degree

1:1

Float

Coordinate in decimal degrees (DDDDD), WGS-84 [-90.00000, +90.00000]

Positive = Northern Hemisphere, negative = Southern Hemisphere.

heading

0:1

String (Enum)

Geographical direction (N or S)

longitude

0:1

Object

Longitude value

degree

1:1

Float

Coordinate in decimal degrees (DDDDD), WGS-84 [-180.00000, +180.000000]

Positive = Eastern Hemisphere, negative = Western Hemisphere.

heading

0:1

String (Enum)

Geographical direction (W or E)

altitude

1:1

Float

Altitude value (m)

time

1:1

String

UTC time value with following format hh:mm:ss

date

0:1

String

Date value with following format yyyy-mm-dd

speedOverGround

0:1

Float

GNSS based speed over ground (m/s)

signalQuality

0:1

String (Enum)

Signal quality value. Quality reference from GNSS coordinates based on system specification. See the following possible enums: aGPS | dGPS | estimated | gps | notValid | unknown

fix

0:1

String (Enum)

Status of GNSS fix. See the following possible enums: noFix | 2D | 3D | DR | 3D+DR

numberOfSatellites

0:1

Integer

Number of satellites which are used for the GNSS

horizontalDilutionOfPrecision

0:1

Float

Value of precision in horizontal dilution

verticalDilutionOfPrecision

0:1

Float

Value of precision in vertical dilution

trackDegreeTrue

0:1

Float

Value of the Track based at the real north pole

trackDegreeMagnetic

0:1

Float

Value of the Track based at the magnetic north pole

gnssType

1:1

String (Enum)

Information about the used GNSS System. Type of satellites receiver. MixedGNSSTypes is used for receivers using multiple satellite constellations. See the following possible enums: gps | glonass | galileo | beidou | irnss | deadReckoning | mixedGnssTypes | other

gnssCoordinateSystem

0:1

String (Enum)

Information about the coordinate system. data reference used by satellites coordinates. the default coordinate system is wgs84 (widely used), in case of empty field. see the following possible enums: ch1903 | etsr89 | itrs/itrf nad83 | wgs84 | pz90

deadReckoning

1:1

Boolean

DR assistance active (Y/N).

doubleFrequency

0:1

Boolean

Dual-frequency receiver (Y/N).

gnssDistance

0:1

Float

Distance travelled computed from GNSS (metres).

simulationMode

0:1

Boolean

true when GNSS is in simulation mode.

horizontalAccuracy

0:1

Float

1-σ horizontal accuracy (metres)

verticalAccuracy

0:1

Float

1-σ vertical accuracy (metres)

speedAccuracy

0:1

Float

1-σ speed accuracy (m s-¹).

headingAccuracy

0:1

Float

1-σ heading accuracy (degrees).

gnssFixOk

0:1

Boolean

true if solution meets DOP & accuracy masks.

Table 51.- GnssLocation DG message structure

Vehicle Motion Sensors

OPI Accelerations

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

accelerations

RawAccelerations

  • X, Y, Z accelerations read from an accelerometer three axis sensor
  • Trigger: at startup and then periodically with a period of 30ms

VehicleAccelerations

  • Vehicle Longitudinal, Lateral and Vertical accelerations (vehicle axis aligned accelerations)
  • Longitudinal acceleration of the stopped vehicle (equivalent to the slope)
  • calibrate_accel (align the accelerator axis with the vehicle axis and remove offsets)

OPI version

v1.0

Table 52.- OPI Accelerations summary

RawAccelerations DG stream_info

<root>/operation/<provider_guid>/accelerations/<OPI_version>/data/raw_accelerations/stream_info

Table 53.- Topic path for Raw Accelerations data stream Information

RawAccelerations Stream Info

+Structure

Description

<Common fields for every JSON data message>

accellSamplingPeriod

1:1

Integer

Current sampling period (ms).

acelStreamTimeRef

1:1

DateTime

Reference time for the Timestamps of the data. It is the date of the start of the vehicle session.

Adding the timestamp of a data element in the stream to this time will result in the absolute DateTime for this data element

Table 54.- RawAccelerations DG stream_info message structure

RawAccelerations DG stream_data

<root>/operation/<provider_guid>/accelerations/<OPI_version>/data/raw_accelerations/stream_data

Table 55.- Topic path for Raw Accelerations DG Stream

Raw Accelerations Stream Data

+Structure

Description

Samples

1:*

Array

[0]

1:1

Integer

Timestamp in microseconds relative to acelStreamTimeRef

[1]

1:1

Integer

Raw X acceleration from the sensor axes (mG). (1 mG = 0.0098 m/s²)

[2]

0:1

Integer

Raw Y acceleration from the sensor axes (mG). (1 mG = 0.0098 m/s²)

[3]

0:1

Integer

Raw Z acceleration from the sensor axes (mG). (1 mG = 0.0098 m/s²)

Table 56.- RawAccelerations DG stream_data message structure

VehicleAccelerations DG

<root>/operation/<provider_guid>/accelerations/<OPI_version>/data/vehicle_accelerations/stream_info

Table 57.- Topic path for Vehicle Accelerations data stream Information

Vehicle Accelerations stream Info

+Structure

Description

<Common fields for every JSON data message>

accellSamplingPeriod

1:1

Integer

Current sampling period (ms).

accelSlope

0:1

Integer

Longitudinal acceleration measured last time the vehicle was stationary (mG).

acelStreamTimeRef

1:1

DateTime

Reference time for the Timestamps of the data. It is the date of the start of the vehicle session.

Adding the timestamp of a data element in the stream to this time will result in the absolute DateTime for this data element

<root>/operation/<provider_guid>/accelerations/<OPI_version>/data/vehicle_accelerations/stream_data

Table 58.- Topic path for Vehicle Accelerations DG Stream

Vehicle Accelerations stream

+Structure

Description

Samples

1:*

Array

[0]

1:1

Integer

Timestamp in microseconds relative to acelStreamTimeRef

[1]

1:1

Integer

Longitudinal, vehicle-aligned X acceleration (mG). (1 mG = 0.0098 m/s²)

[2]

0:1

Integer

Lateral, vehicle-aligned Y acceleration (mG). (1 mG = 0.0098 m/s²)

[3]

0:1

Integer

Vertical, vehicle-aligned Z acceleration (mG). (1 mG = 0.0098 m/s²)

calibrate_accel command

<root>/operation/<provider_guid>/accelerations/<OPI_version>/cmd/calibrate_acel/<sender_GUID>

Table 59.- Topic path for calibrate_accel command

calibrate_accel

+Structure

Description

<Common fields for every JSON command message>**

calibrateAccel

1:1

Boolean

true

Table 60.- calibrate_accel command message structure

OPI Odometer

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

odometer

OdometerAll

  • Distance, speed and pulses from the wheel odometer, reference time.
  • Trigger: At each new pulse while pulses are spaced more than 100ms, or periodically every 100ms when pulses are more frequent.
  • none

OPI version

v1.0

Table 61.- OPI Odometer summary

OdometerAll DG

<root>/operation/<provider_guid>/odometer/<OPI_version>/data/odometer_all

Table 62.- Topic path for OdometerAll DG

OdometerAll

+Structure

Description

<Common fields for every JSON data message>

odoSpeed

1:1

Integer

Vehicle speed computed from odometer (Hm/h).

odoDistance

1:1

Integer

Distance travelled since last vehicle start (last contact on) (meters).

odoPulses

1:1

Integer

Accumulated odometer pulse count since last vehicle start (last contact on).

odoAcceleration

0:1

Integer

Vehicle instantaneous acceleration (mG) (1mG=(9,8m/s2)/1000)

Table 63.- OdometerAll DG message structure

Vehicle status

OPI Tell Tale Status

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

tell_tale_status

ActiveTellTales

  • List of active tell tales with status information on distance and time while active.
  • Trigger: at startup, on discrete change and periodically every 10s while there are active tell tales.
  • none

OPI version

v1.0

Table 64.- OPI Tell Tale Status summary

ActiveTellTales DG

<root>/operation/<provider_guid>/tell_tale_status/<OPI_version>/data/active_tell_tales

Table 65.- Topic path for ActiveTellTales DG

ActiveTellTales

+Structure

Description

<Common fields for every JSON data message>

activeTellTales

1:*

Object

Tell Tales with Status= Info, Yellow or Red

tellTaleId

1:1

Integer

According to FMS (1~120)

tellTaleStatus

1:1

Integer

Info, Yellow or Red

ttsRedTime

0:1

Integer

Time in seconds with TTS Red

ttsRedDistance

0:1

Integer

Distance travelled in meters with TTS Red

ttsYellowTime

0:1

Integer

Time in seconds with TTS Yellow

ttsYellowDistance

0:1

Integer

Distance travelled in meters with TTS Yellow

Table 66.- ActiveTellTales DG message structure

OPI Diagnostic Messages

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

diagnostic_messages

DiagnosticMessagesAll

  • Publication of diagnostic messages according to j1939DM1.
  • Trigger: at startup, on discrete change and periodically every 10s while there are active diagnostic messages.
  • none

OPI version

v1.0

Table 67.- OPI Diagnostic Messages summary

DiagnosticMessagesAll DG

<root>/operation/<provider_guid>/diagnostic_messages/<OPI_version>/data/diagnostic_messages_all

Table 68.- Topic path for DiagnosticMessagesAll DG

DiagnosticMessagesAll

+Structure

Description

<Common fields for every JSON data message>

diagnosticMessages

1:*

Object

DM according to J1939 DM1

lampStatus

1:1

Integer

According to DM1. MIL(Malfunction Indicator), RSL(Red Stop), AWL(Amber Warning), PL(Protect Lamp)

dtc

1:*

Object

Diagnostic Trouble Codes

spn

1:1

Integer

J1939 parameter

failureModeId

1:1

Integer

Failure Mode Identifier

occurrenceCount

1:1

Integer

Occurrence Count

dtcTime

0:1

Integer

Time in seconds with DTC active

dtcDistance

0:1

Integer

Distance travelled in meters with DTC active

Table 69.- DiagnosticMessagesAll DG message structure

OPI Vehicle Modes

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

vehicle_modes

Contact

  • Ignition status information (Contact ON or OFF, No contact, Unavailable, Error).
  • Trigger: at startup and on discrete change.

EngineStatus

  • Engine status information (ON, OFF, No Engine, Unavailable, Error).
  • Trigger: at startup and on discrete change.

ParkingBrakeStatus

  • Parking brake status information.
  • Trigger: at startup and on discrete change.

ChargingStatus

  • Charging status information.
  • Trigger: At connection/disconnection from the charger and periodically every 10s while charging.

DrivingMode

  • Driving mode information (Driving, StandBy, Charging).
  • Trigger: at startup and on discrete change.

PowerMode

  • 24V auxiliaries power mode: ECO0, ECO1, ECO2 or SLEEP
  • Time to switch ITS power off
  • Trigger: at startup and on discrete change.
  • none

OPI version

v1.0

Table 70.- OPI Vehicle Modes summary

Contact DG

<root>/operation/<provider_guid>/vehicle_modes/<OPI_version>/data/contact

Table 71.- Topic path for Contact DG

Contact

+Structure

Description

<Common fields for every JSON data message>

ignitionStatus

1:1

String (Enum)

on | off | noContact | unavailable | error

Table 72.- Contact DG message structure

EngineStatus DG

<root>/operation/<provider_guid>/vehicle_modes/<OPI_version>/data/engine_status

Table 73.- Topic path for EngineStatus DG

EngineStatus

+Structure

Description

<Common fields for every JSON data message>

engineStatus

1:1

String (Enum)

on | off | noContact | unavailable | error

Table 74.- EngineStatus DG message structure

ParkingBrakeStatus DG

<root>/operation/<provider_guid>/vehicle_modes/<OPI_version>/data/parking_brake_status

Table 75.- Topic path for ParkingBrakeStatus DG

ParkingBrakeStatus

+Structure

Description

<Common fields for every JSON data message>

parkingBrakeStatus

1:1

String (Enum)

on | off | unavailable | error

Table 76.- ParkingBrakeStatus DG message structure

ChargingStatus DG

<root>/operation/<provider_guid>/vehicle_modes/<OPI_version>/data/charging_status

Table 77.- Topic path for ChargingStatus DG

ChargingStatus

+Structure

Description

<Common fields for every JSON data message>

chargingStatus

1:1

String

Overall vehicle charging session status. ON, OFF, Unavailable, Error

chargingStartTime

1:1

DateTime

Timestamp when a charging session started (chargingStatus from OFF to ON)

energyCharged

0:1

Integer

Cumulated Energy charged (Wh)

hvessSoc

0:1

Integer

0% means no charge remaining, 100% means the system is fully charged in terms of physical limits of the energy storage system (%)

chargingEndTime

0:1

DateTime

Timestamp when a charging session ended (chargingStatus from ON to OFF, error)

Table 78.- ChargingStatus DG message structure

DrivingMode DG

<root>/operation/<provider_guid>/vehicle_modes/<OPI_version>/data/driving_mode

Table 79.- Topic path for DrivingMode DG

DrivingMode

+Structure

Description

<Common fields for every JSON data message>

drivingMode

1:1

String

driving | standBy | charging

Table 80.- DrivingMode DG message structure

PowerMode DG

<root>/operation/<provider_guid>/vehicle_modes/<OPI_version>/data/power_mode

Table 81.- Topic path for PowerMode DG

PowerMode

+Structure

Description

<Common fields for every JSON data message>

powerMode

1:1

String

24V auxiliaries power mode: ECO0, ECO1, ECO2 or SLEEP

timeToPowerOff

0:1

Integer

Time in seconds left until 24V power is set to Off (Contact Off)

Table 82.- PowerMode DG message structure

OPI Passengers Area Information

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

passengers_area_info

DoorsStatus

  • Status of all and individual doors and ramp
  • Trigger: at startup and on discrete change.

PassengersAreaAmbientConditions

  • Temperature for each sensor (1:1)
  • Relative Humidity (%RH) for each sensor (0:1)
  • CO2 concentration for each sensor (0:1)
  • Air Quality Index for each sensor (0:1)
  • Trigger: periodically every 30s.

LuggageCompartmentStatus

  • Status of each luggage compartment (open or closed)
  • Trigger: at startup and on discrete change.

StopRequestStatus

  • Status of stop request sign
  • Status of each onboard stop request pushbutton
  • Stop request source (pushbutton1, pushbutton2, PRM pushbutton, app)
  • Trigger: on discrete change

PassengersSeatbeltsStatus

  • Status of each passenger seatbelt
  • Status of seatbelts for wheelchairs
  • Trigger: at startup and on discrete change.
  • none

OPI version

v1.0

Table 83.- OPI Passengers Area Information summary

DoorsStatus DG

<root>/operation/<provider_guid>/passengers_area_info/<OPI_version>/data/doors_status

Table 84.- Topic path for DoorsStatus DG

DoorsStatus

+Structure

Description

<Common fields for every JSON data message>

anyDoorStatus

1:1

String (Enum)

open = if any door is open

closed = if all doors are closed

unknown = if status is “unknown”

malfunction = in case of malfunction

anyRampStatus

1:1

String (Enum)

noRamp = no ramp available in this bus

open = if any ramp has been deployed

closed = if no ramp has been deployed

unknown = if status is “unknown”

malfunction = in case of malfunction of any ramp

eachDoorStatus

0:*

Object

List of all doors and their status

doorLocationId

1:1

Integer

Door ID associated with its position in the bus (e.g. 1 = front door)

doorInfo

1:1

String

Free description of the door e.g. “low floor, rear door with ramp)

doorStatus

1:1

String (Enum)

open = if any door is open

closed = if all doors are closed

unknown = if status is “unknown”

malfunction = in case of malfunction

doorCondition

0:1

String (enum)

normal | locked | emergencyRelease

rampLiftPosition

1:1

String (Enum)

noRamp = no ramp available in this door

open = if ramp has been deployed

closed = if ramp has not been deployed

unknown = if status is “unknown”

malfunction = in case of malfunction

ramp7DaysWithoutUseStatus

0:1

String (Enum)

usedWithin7Days | notUsed7Days | unknown | malfunction

rampErrorStatus

0:1

Boolean

true | false

rampIsDirtyStatus

0:1

Boolean

true | false

totalCyclesRamp

0:1

Integer

Cumulative number of ramp cycles for this door since installation or last maintenance reset (rampCounterSince)

totalCyclesDoor

0:1

Integer

Cumulative number of door cycles (open/close) since installation or last maintenance reset

doorCounterSince

0:1

DateTime

Timestamp when the door cycle counter was last reset

rampCounterSince

0:1

DateTime

Timestamp when the ramp cycle counter was last reset

Table 85.- DoorsStatus DG message structure

AmbientConditions DG

<root>/operation/<provider_guid>/passengers_area_info/<OPI_version>/data/ambient_conditions

Table 86.- Topic path for AmbientConditions DG

AmbientConditions

+Structure

Description

<Common fields for every JSON data message>

temperatureSensor

1:*

Object

Temperature sensors

temperatureSensorLocationId

1:1

Integer

ID associated with the position of the sensor within in the bus

temperatureSensorInfo

1:1

String

Free description of sensor features and , location

temperatureSensorValue

1:1

Integer

Value expressed in 0.1 °C units, unknown or malfunction

humiditySensor

0:*

Object

Humidity sensors

humiditySensorLocationId

1:1

Integer

ID associated with the position of the sensor within in the bus

humiditySensorInfo

1:1

String

Free description of sensor features and location

humiditySensorValue

1:1

Integer

Value expressed in % units, unknown or malfunction

co2Sensor

0:*

Object

CO2 sensors

co2SensorLocationId

1:1

Integer

ID associated with the position of the sensor within in the bus

co2SensorInfo

1:1

String

Free description of sensor features and location

co2SensorValue

1:1

Integer

Value expressed in ppm units, unknown or malfunction

euaqi

0:*

Object

European air quality index

euaqiSensorLocationId

0:1

Integer

ID associated with the position of the sensor within in the bus

euaqiSensorInfo

0:1

String

Free description of sensor features and location

euaqiSensorValue

0:1

Integer

EUAQI 1 to 5 air quality index value, unknown or malfunction

euaqiPassengersAreaValue

0:1

Integer

EUAQI 1 to 5 air quality index value in passengers Area

Table 87.- AmbientConditions DG message structure

LuggageCompartmentStatus DG

<root>/operation/<provider_guid>/passengers_area_info/<OPI_version>/data/luggage_compartment_status

Table 88.- Topic path for LuggageCompartmentStatus DG

LuggageCompartmentStatus

+Structure

Description

<Common fields for every JSON data message>

luggageCompartment1Status

1:1

Boolean

Status of any luggage compartment: true = ANY OPEN, false = ALL CLOSED

luggageCompartment1Status

0:1

Boolean

Status of any luggage compartment1: true = OPEN, false = CLOSED

luggageCompartment2Status

0:1

Boolean

Status of any luggage compartment2: true = OPEN, false = CLOSED

luggageCompartment3Status

0:1

Boolean

Status of any luggage compartment3: true = OPEN, false = CLOSED

luggageCompartment4Status

0:1

Boolean

Status of any luggage compartment4: true = OPEN, false = CLOSED

Table 89.- LuggageCompartmentStatus DG message structure

StopRequestStatus DG

<root>/operation/<provider_guid>/passengers_area_info/<OPI_version>/data/stop_request_status

Table 90.- Topic path for StopRequestStatus DG

StopRequestStatus

+Structure

Description

<Common fields for every JSON data message>

stopRequestStatus

1:1

Boolean

Status of the bus stop request signs.

true (if active/requested) | false (not requested)

They turn on whenever a stop request button is pushed by a passenger and turn off after the bus arrives at a stop.

stopRequestSource

0:1

String

Pushbutton, PMR_pushbutton or user_App

stopRequestButton1Status

0:1

Boolean

Status of stop request button 1 (front)

stopRequestButton2Status

0:1

Boolean

Status of stop request button 2 (middle)

stopRequestButton3Status

0:1

Boolean

Status of stop request button 3 (rear)

Table 91.- StopRequestStatusDG message structure

PassengersSeatbeltsStatus DG

<root>/operation/<provider_guid>/passengers_area_info/<OPI_version>/data/passengers_seatbelts_status

Table 92.- Topic path for PassengersSeatbeltsStatus DG

PassengersSeatbeltsStatus

+Structure

Description

<Common fields for every JSON data message>

passengersSeatbelts

1:N

Object

Status of passenger seatbelts

seatbeltLocationId

1:1

Integer

ID associated with the position of the sensor within in the bus

seatbeltInfo

1:1

String (Enum)

Seat or Wheelchair seatbelt. See the following possible enums: seat | wheelchair

seatbeltStatus

1:1

Integer

See the following possible enums: locked | unlocked | unknown | malfunction

Table 93.- PassengersSeatbeltsStatus DG message structure

Vehicle Energy Sources Information

OPI Hvess

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

hvess

ID, specifications, voltage, current, power, temperature, status and other data for the battery, and for each of its packs. The provided DataGroups are the following::

  • HvessMain
  • HvessStatus
  • HvessCellTemp

hvessHighestCellTemp (Object in DG)

hvessLowestCellTemp (Object in DG)

  • HvessCellVolt

hvessHighestCellVolt (Object in DG)

hvessLowestCellVolt (Object in DG)

  • HvessCellSoc

hvessHighestCellSoc (Object in DG)

hvessLowestCellSoc (Object in DG)

  • HvessConfiguration
  • HvessThermalManagement
  • HvessHistory
  • HvessPacks

Trigger: at startup, on discrete change and on threshold change for continuous values

  • none

OPI version

v1.0

Table 94.- OPI Hvess summary

HvessMain DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_main

Table 95.- Topic path for HvessMain DG

HvessMain

+Structure

Description

<Common fields for every JSON data message>

hvessId

1:1

String

hvessSpecs

1:1

String

hvessVoltage

1:1

Integer

The voltage level of the High Voltage Energy Storage 1 pack (or system)

hvessCurrent

1:1

Integer

The current in or out of the High Voltage Energy Storage 1 pack (or system)

hvessTemperature

1:1

Integer

The temperature of High Voltage Energy Storage System (or Pack 1 in systems with only one pack)

hvessAvgCellTemp

1:1

Integer

The average temperature level of all cells in the High Voltage Energy Storage System (or Pack 1 in systems with only one pack)

hvessAvailablePower

0:1

Integer

The rate at which the High Voltage Energy Storage System (or Pack 1 in systems with only one pack) can currently provide energy for propulsion or other uses

hvessDischargeCurrentCapacity

0:1

Integer

The amount of stored electrical charge in the High Voltage Energy Storage System (or Pack 1 in systems with only one pack) that is available for use by the hybrid system

hvessDdischargePowerCapacity

0:1

Integer

The amount of stored electrical energy in High Voltage Energy Storage System (or Pack 1 in systems with only one pack) that is available for use by the hybrid system

hvessChargePower

0:1

Integer

The rate at which the High Voltage Energy Storage System (or Pack 1 in systems with only one pack) can currently receive energy from a regenerative or recharging system

hvessFastUpdateStateOfCharge

0:1

Integer

Indicates the High Voltage Energy Storage System (or Pack 1 in systems with only one pack) state of charge

Table 96.- HvessMain DG message structure

HvessStatus DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_status

Table 97.- Topic path for HvessStatus DG

HvessStatus

+Structure

Description

<Common fields for every JSON data message>

cellBalanceStatus

1:1

Integer

Indicates whether or not the cells in the High Voltage Energy Storage System (or Pack 1 in systems with only one pack) are balanced:

balanced | unbalanced | unavailable | error

cellTemperatureDifferential

0:1

Integer

Difference between highest and lowest HVESS cell temperature

cellVoltageDifferential

1:1

Integer

Difference between highest and lowest HVESS cell voltage

internalChargerStatus

0:1

Integer

indicative of AC Charging status

Table 98.- HvessStatus DG message structure

HvessCellTemp DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_cell_temp

Table 99.- Topic path for HvessCellTemp DG

HvessCellTemp

+Structure

Description

<Common fields for every JSON data message>

hvessHighestCellTemp

1:1

Object

Highest temperature level reported by any cell in the High Voltage Energy Storage System

packNumber

0:1

Integer

Identifies the pack number containing the highest cell temperature

moduleNumber

0:1

Integer

Identifies the module containing the highest cell temperature

cellNumber

0:1

Integer

Identifies the cell with the highest temperature

temperature

1:1

Integer

The highest temperature level reported by any cell in the High Voltage Energy Storage System (ºC)

hvessLowestCellTemp

1:1

Object

The lowest temperature level reported by any cell in the High Voltage Energy Storage System

packNumber

0:1

Integer

Identifies the pack number containing the lowest cell temperature

moduleNumber

0:1

Integer

Identifies the module containing the lowest cell temperature

cellNumber

0:1

Integer

Identifies the cell with the lowest temperature

temperature

1:1

Integer

The lowest temperature level reported by any cell in the High Voltage Energy Storage System (ºC)

Table 100.- HvessCellTemp DG message structure

HvessCellVolt DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_cell_volt

Table 101.- Topic path for HvessCellVolt DG

HvessCellVolt

+Structure

Description

<Common fields for every JSON data message>

hvessHighestCellVolt

1:1

Object

The highest voltage level reported by any cell in the High Voltage Energy Storage System

packNumber

0:1

Integer

Identifies the pack number containing the highest cell voltage

moduleNumber

0:1

Integer

Identifies the module containing the highest cell voltage

cellNumber

0:1

Integer

Identifies the cell with the highest voltage

voltage

1:1

Integer

The highest temperature level reported by any cell in the High Voltage Energy Storage System (V)

hvessLowestCellVolt

1:1

Object

The lowest voltage level reported by any cell in the High Voltage Energy Storage System

packNumber

0:1

Integer

Identifies the pack number containing the lowest cell voltage

moduleNumber

0:1

Integer

Identifies the module containing the lowest cell voltage

cellNumber

0:1

Integer

Identifies the cell with the lowest voltage

voltage

1:1

Integer

The lowest temperature level reported by any cell in the High Voltage Energy Storage System (V)

Table 102.- HvessCellVolt DG message structure

HvessCellSoc DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_cell_soc

Table 103.- Topic path for HvessCellSoc DG

HvessCellSoc

+Structure

Description

<Common fields for every JSON data message>

hvessHighestCellSoc

1:1

Object

The highest state of charge (SoC) reported by any cell in the High Voltage Energy Storage System

packNumber

0:1

Integer

Identifies the pack containing the highest cell SoC

moduleNumber

0:1

Integer

Identifies the module containing the highest cell SoC

cellNumber

0:1

Integer

Identifies the cell with the highest SoC

stateOfCharge

1:1

Integer

Highest cell state of charge (%)

hvessLowestCellSoc

1:1

Object

The lowest state of charge (SoC) reported by any cell in the High Voltage Energy Storage System

packNumber

0:1

Integer

Identifies the pack containing the lowest cell SoC.

moduleNumber

0:1

Integer

Identifies the module containing the lowest cell SoC.

cellNumber

0:1

Integer

Identifies the cell with the lowest SoC.

stateOfCharge

1:1

Integer

Lowest cell state of charge (%).

Table 104.- HvessCellSoc DG message structure

HvessConfiguration DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_configuration

Table 105.- Topic path for HvessConfiguration DG

HvessConfiguration

+Structure

Description

<Common fields for every JSON data message>

maximumOperatingVoltage

0:1

Integer

Maximum recommended voltage level for High Voltage Energy Storage System. Operating above this value may compromise HVES life.

minimumOperatingVoltage

0:1

Integer

Minimum recommended voltage level for High Voltage Energy Storage System. Operating below this value may compromise HVES life.

maximumOperatingTemperature

0:1

Integer

Recommended maximum temperature for High Voltage Energy Storage System

minimumOperatingTemperature

0:1

Integer

Recommended minimum temperature for High Voltage Energy Storage System

nominalRatedCapacity

0:1

Integer

Manufacturer's nominal rated capacity of the High Voltage Energy Storage System

nominalVoltage

0:1

Integer

Manufacturer’s nominal operating voltage of the High Voltage Energy Storage System

maximumStateOfCharge

0:1

Integer

Recommended maximum state of charge for High Voltage Energy Storage System

minimumStateOfCharge

0:1

Integer

Recommended minimum state of charge for High Voltage Energy Storage System

cellMaximumVoltageLimit

0:1

Integer

Recommended maximum cell voltage for High Voltage Energy Storage System

cellMinimumVoltageLimit

0:1

Integer

Minimum cell voltage for High Voltage Energy Storage System

Table 106.- HvessConfiguration DG message structure

HvessThermalManagement DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_thermal_management

Table 107.- Topic path for HvessThermalManagement DG

HvessThermalManagement

+Structure

Description

<Common fields for every JSON data message>

heaterStatus

0:1

Integer

HVESS Thermal Management System Heater Status 

coolerStatus

0:1

Integer

HVESS Thermal Management System Cooler Status 

mode

0:1

Integer

HVESS Thermal Management System Mode (Cooler/Heater)

Table 108.- HvessThermalManagement DG message structure

HvessHistory DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_history

Table 109.- Topic path for HvessHistory DG

HvessHistory

+Structure

Description

<Common fields for every JSON data message>

contactorOpenUnderLoadCount

0:1

Integer

Number of times the contactors inside the High Voltage Energy Storage System have opened while current is flowing through them. The current level (that determines if an opening event will be counted) shall be defined by the HVES manufacturer, but in general should be a current level at which the contactor life may be reduced if repeated cycles occur.

totalLifetimeEnergyInput

0:1

Integer

The cumulative energy which has flowed into the High Voltage Energy Storage System over the lifetime of the battery system

hvessTotalEnergyThroughput

0:1

Integer

The total energy throughput which has flowed through High Voltage Energy Storage

hvessTotalLifetimeEnergyOutput

0:1

Integer

The cumulative energy which has flowed out of the High Voltage Energy Storage System over the lifetime of the battery system

hvessTotalAccumulatedCharge

0:1

Integer

The total accumulated amp hours which have flowed through High Voltage Energy Storage System

hvessStateOfHealth

1:1

Integer

Expected remaining “life” of the High Voltage Energy Storage System (%)

Table 110.- HvessHistory DG message structure

HvessPacks DG

<root>/operation/<provider_guid>/hvess/<OPI_version>/data/hvess_packs

Table 111.- Topic path for HvessPacks DG

HvessPacks

+Structure

Description

<Common fields for every JSON data message>

hvessPack

1:*

Object

High Voltage Energy Storage packs voltage, temperature and energy

packNumber

1:1

Integer

Identifies the pack number

packVoltage

1:1

Integer

The voltage level of the High Voltage Energy Storage pack referenced

packTemperature

1:1

Integer

The temperature of the High Voltage Energy Storage pack referenced

packEnergy

0:1

Integer

The amount of stored electrical energy of the High Voltage Energy Storage pack referenced

Table 112.- HvessPacks DG message structure

TICKETING OPIs

OPI Validator

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

validator

ValidatorTransaction

  • Validation transaction data (fare product, user profile, relevant network location…)
  • Trigger: after each transaction.

A different DataGroup published at a specific topic should be used to publish each different type of validation transaction, such as conventional card based transactions, ABT, EMV, QR or others

ValidatorOpParameters

  • Operating parameters for validation (relevant network location, tariff zone…)
  • Trigger: at startup and on discrete change
  • shutdown
  • reset
  • set_validation_mode
  • lock_validation
  • set_maintenance
  • set_demo
  • request_config
  • set_config

OPI version

v1.0

Table 113.- OPI Validator summary

ValidatorTransaction DG

<root>/operation/<provider_guid>/validator/<OPI_version>/data/transactions

Table 114.- Topic path for ValidatorTransaction DG

ValidatorTransaction

+Structure

Description

<Common fields for every JSON data message>

validationDate

1:1

DateTime

Timestamp of the validation date

fareMediumSerialNumber

1:1

String

Unique serial of the physical/virtual medium presented

accessEventCounter

1:1

Integer

Value of event counter in the medium.

fareProductCode

1:1

String

Code of the Fare Product consumed/checked

farePurchasingDate

1:1

DateTime

Timestamp when the product was sold/loaded

fareFirstValidationDate

1:1

DateTime

Timestamp of the first use/first validation of the product

fareOwner

1:1

String

Identifier of the fare contract owner

fareMediumType

1:1

String (Enum)

Medium type used: contactlessCard | nfcPhone | bankcard | paperBarcode | phoneBarcode

fareSystemType

1:1

String (Enum)

ptaSystem | ptoSystem | emv | abt | tesc

customerProfile

1:1

String

Passenger profile applied (adult, student, senior…)

driverRef

1:1

String

Driver identifier linked to the operating session

ptoRef

1:1

String

Public Transport Operator identifier reference.

validationLocation

1:1

Object

Context of where the validation took place

equipmentGuid

1:1

String

ODEx equipment item GUID where the validation took place.

vehicleRef

1:1

String

ID of the vehicle unit. VIN for bus.

stopPointRef

0:1

String

Stop Point reference attributed to the event

lineRef

1:1

String

Identifier of operational Line that vehicle follows

directionRef

0:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound | out = outbound | cw = clockwise | ccw = counterclockwise | other

servicePatternRef

0:1

String

Identifier of the Service Pattern

fareZoneId

0:1

String

Tariff/Fare Zone

blockRef

0:1

String

Reference (ID) of Block assigned

courseOfJourneyRef

0:1

String

Reference (ID) of Course of Journey assigned

serviceJourneyRef

0:1

String

Reference (ID) of Service Journey assigned

validationCount

1:1

Integer

Validator transaction counter

hotListsVersion

1:*

Object

List type and version of hot lists applied

type

1:1

String

Type of hot list applied (simple, ranged…)

version

1:1

String

Version of defined hot list.

validationResultCode

1:1

Integer

Project-specific validation result code. Consumers must interpret it using the project validation result code list.

E.g.: 1 = ok | 2 = cardRejected | 3 = cardBlocked | 4 = customerProfileChange…

Table 115.- ValidatorTransaction DG message structure

ValidatorOpParameters DG

<root>/operation/<provider_guid>/validator/<OPI_version>/data/op_parameters

Table 116.- Topic path for ValidatorOpParameters DG

ValidatorOpParameters

+Structure

Description

<Common fields for every JSON data message>

validatorOpStatus

Object

Current operational state of the validator application

opStatus

1:1

String (Enum)

Operating mode. See the following list of possible enums: ready | busy | locked | outOfOrder | maintenance | other

additionalInfo

0:1

String

Optional free-text

nlInfo

1:1

Object

Network-location context shared by the validator

servicePatternRef

0:1

String

Identifier of the Service Pattern

journeyPatternRef

0:1

String

Journey Pattern reference

vehicleJourneyRef

0:1

String

Reference to the specific service journey or dead run.

routeRef

0:1

String

Route identifier

lineRef

1:1

String

Identifier of operational Line that vehicle follows

directionRef

0:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound | out = outbound | cw = clockwise | ccw = counterclockwise | other

externalLineRef

0:1

String

External/agency line reference (if applicable).

lastStopPointRef

0:1

String

Reference of the last passed stop

nextStopPointRef

0:1

String

Reference of the next scheduled stop

driver

1:1

Object

Current driver and duty context

driverRef

1:1

String

Driver identifier reference

driverName

0:1

String

Driver Name

driverDuty

0:1

String

Duty identifier reference (work to be performed by a driver on a particular day type)

locationInVehicle

1:1

Object

Validator shared info about its location in the vehicle

equipmentGuid

1:1

String

ODEx equipment item GUID

valPosition

1:1

Integer

(1-8) 1= front door

validationMode

1:1

String

Indicates whether the validator is configured for validations on boarding (entry) or on alighting (exit): boarding | alighting | both | onlyConsult

pmr

1:1

Boolean

true if configured as PMR entry point; otherwise, false

fareZoneInfo

0:*

Object

List of accepted tarrif and fare zones. Each entry ties a Fare Authority/Organisation to a Tariff/Fare Zone.

fareAuthorityId

1:1

String

Identifier of the fare authority/organisation that defines the zone.

fareZoneId

1:1

String

Identifier of the Tariff/Fare Zone.

farezoneTypeId

1:1

String

Index at the fare zone type

hotListsVersion

1:*

Object

List type and version of hot lists applied

type

1:1

String

Type of hot list applied (simple, ranged…)

version

1:1

String

Version of defined hot list.

ptaRef

1:1

String

Identifier of the Public Transport Authority.

ptoRef

1:1

String

Identifier of the Public Transport Operator.

vehicleId

1:1

String

ID of the vehicle unit. VIN for bus.

samSerialNumber

1:1

String

SAM serial number installed

Table 117.- ValidatorOpParameters DG message structure

Validator OPI commands

MQTT topic under …/validator/<OPI_version>/cmd

Fields

+Structure

Description

<Common fields for every JSON command message>

/shutdown

reason

0:1

String

Switch off the validator app. Optional free-text reason

/reset

reason

0:1

String

Reset the validator app. With optional free-text reason.

/set_validation_mode

validationMode

1:1

String

Validation Mode (only entrance validation, consult…)

reason

0:1

String

Free-reason text

/lock_validation

durationSec

0:1

Integer

Lock duration time in seconds

reason

0:1

String

inspecction |driverOut …

/set_maintenance

active

1:1

Boolean

Enter/exit maintenance mode (true / false)

/set_demo

active

1:1

Boolean

Enter/exit demo mode (true / false) used for training

/request_config

-

-

-

Provider will return all config parameters in the details field structure (see Command Responses). Configuration parameters for the validator OPI and their data type must be specified (volumeLevel, screenBrightLevel, language…)

Structure of details field in response will be:

responseContent 0:* Object Config parameters

<configId1> - anyType1 Each parameter value

<configId2> - anyType2

/set_config

volumeLevel

0:1

anyType1

Integer

screenBrightLevel

0:1

anyType2

Integer

Table 118.- Validator OPI commands and fields

OPI Ticket Vending

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

ticket_vending

TicketVendingTransaction

  • Sale transaction data
  • Trigger: after each transaction

TicketVendingOpParameters

  • Operating parameters for tvm.
  • Trigger: at startup and on discrete change

DriverCashSettlement

  • Sale transaction data
  • Trigger: after end of shift or handover. Check employe_log OPI
  • shutdown
  • reset
  • lock_session
  • unlock_session
  • set_maintenance
  • set_demo
  • request_config
  • set_config

OPI version

v1.0

Table 119.- OPI Ticket Vending summary

TicketVendingTransaction DG

<root>/operation/<provider_guid>/ticket_vending/<OPI_version>/data/transactions

Table 120.- Topic path for TicketVendingTransaction DG

TicketVendingTransaction

+Structure

Description

<Common fields for every JSON data message>

saleDate

1:1

DateTime

Timestamp of the sale date.

ticketSerialNumber

1:1

String

Unique serial of the physical/virtual medium presented

fareProductCode

1:1

Integer

Code of the Fare Product consumed/checked

fareOwner

1:1

String

Identifier of the fare contract owner

customerProfile

1:1

String

Passenger profile applied (adult, student, senior…)

paymentType

1:1

String

cash | bankcard |

tariffAmount

1:1

Integer

Indicates the fare paid by the customer for the transaction (cents)

saleLocation

1:1

Object

Context of where the sale took place

equipmentGuid

1:1

String

ODEx equipment item GUID where the sale took place.

vehicleRef

1:1

String

ID of the vehicle unit. VIN for bus.

stopPointRef

0:1

String

Stop Point reference attributed to the event

lineRef

1:1

String

Identifier of operational Line that vehicle follows

directionRef

0:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound | out = outbound | cw = clockwise | ccw = counterclockwise | other

servicePatternRef

0:1

String

Identifier of the Service Pattern

fareZoneId

0:1

String

Tariff/Fare Zone resolved

blockRef

0:1

String

Reference (ID) of Block assigned

courseOfJourneyRef

0:1

String

Reference (ID) of Course of Journey assigned

serviceJourneyRef

0:1

String

Reference (ID) of Service Journey assigned

driverRef

1:1

String

Driver identifier linked to the operating session

ptoRef

1:1

String

Public Transport Operator identifier reference.

samSerialNumber

1:1

String

SAM serial number installed

saleCount

1:1

Integer

Operation counter.

saleResultCode

1:1

Integer

Project-specific sale result code. Consumers must interpret it using the project sale result code list.

Table 121.- TicketVendingTransaction DG message structure

TicketVendingOpParameters DG

<root>/operation/<provider_guid>/ticket_vending/<OPI_version>/data/op_parameters

Table 122.- Topic path for TicketVendingOpParameters DG

TicketVendingOpParameters

+Structure

Description

<Common fields for every JSON data message>

tvmOpMode

1:1

Object

Report of the operating mode and if manual or automatic

manualMode

1:1

Boolean

true if manual, false if automatic (farebox)

operatingMode

1:1

String (Enum)

ready | busy | locked | outOfOrder | maintenance | other

additionalInfo

0:1

String

Optional free-text

nlInfo

1:1

Object

Network location specific information shared.

servicePatternRef

0:1

String

Identifier of the Service Pattern

journeyPatternRef

0:1

String

Journey Pattern reference

vehicleJourneyRef

0:1

String

Reference to the specific service journey or dead run.

routeRef

0:1

String

Route identifier

lineRef

1:1

String

Identifier of operational Line that vehicle follows

directionRef

0:1

String

Relative direction the vehicle is running along the line (e.g. inbound, outbound, clockwise)

externalLineRef

0:1

String

External/agency line reference (if applicable).

lastStopPointRef

0:1

String

Reference of the last passed stop

nextStopPointRef

0:1

String

Reference of the next scheduled stop

driver

1:1

Object

Current driver

driverRef

1:1

String

Driver identifier reference

driverName

0:1

String

Driver Name

fareZoneInfo

0:*

Object

List of accepted tarrif and fare zones. Each entry ties a Fare Authority/Organisation to a Tariff/Fare Zone.

fareAuthorityId

1:1

String

Identifier of the fare authority/organisation that defines the zone.

fareZoneId

1:1

String

Identifier of the Tariff/Fare Zone.

farezoneTypeId

1:1

String

Index at the fare zone type

fareMatrixVersion

0:1

String

Version of Fare Matrix.

ptaRef

1:1

String

Identifier of the Public Transport Authority responsible for the services run by the vehicle

ptoRef

1:1

String

Identifier of the Public Transport Operator.

equipmentGuid

1:1

String

ODEx equipment item GUID.

vehicleRef

1:1

String

ID of the vehicle unit. VIN for bus.

Table 123.- TicketVendingOpParameters DG message structure

DriverCashSettlement DG

<root>/operation/<provider_guid>/ticket_vending/<OPI_version>/data/driver_cash_settlement

Table 124.- Topic path for DriverCashSettlement DG

DriverCashSettlement

+Structure

Description

<Common fields for every JSON data message>

sessionId

1:1

String

Sequential cash settlement identifier. New session id on new driver session.

sessionStartTime

1:1

DateTime

Start of session Timestamp.

sessionEndTime

1:1

DateTime

End of session Timestamp.

saleLocation

1:1

Object

Location context of the service during the settlement period.

vehicleRef

0:1

String

ID of the vehicle unit. VIN for bus.

equipmentGuid

0:1

String

ODEx equipment item GUID where the validation took place.

lineRef

1:*

String

Identifier of operational Line that vehicle followed

directionRef

0:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound | out = outbound | cw = clockwise | ccw = counterclockwise | other

servicePatternRef

0:1

String

Identifier of the Service Pattern

fareOwner

0:1

String

Identifier of the fare contract owner

blockRef

0:1

String

Reference (ID) of Block assigned

courseOfJourneyRef

0:1

String

Reference (ID) of Course of Journey assigned

serviceJourneyRef

0:1

String

Reference (ID) of Service Journey assigned

salesByLine

1:*

Object

lineRef

1:1

String

Identifier of operational Line that vehicle followed

salesByFareProduct

0:*

Object

Sales by Fare Product

fareOwner

0:1

String

Identifier of the fare contract owner

fareProductCode

1:1

Integer

Fare Product Reference

quantity

1:1

Integer

Count of sales for the corresponding Fare Product

unitPrice

1:1

Integer

Tariff amount per sale for the corresponding Fare Product. By default, in cents.

totalAmountByFareProduct

1:1

Integer

Total amount liquidated for the corresponding Fare Product

validationsByLine

1:*

Object

lineRef

1:*

String

Identifier of operational Line that vehicle follows

validationsByFareProduct

0:*

Object

Count of validations for the corresponding Fare Product

fareOwner

0:1

String

Identifier of the fare contract owner

fareProductCode

1:1

Integer

Fare Product Reference

validationCount

1:1

Integer

Count of validations for the corresponding Fare Product

settlementTotalAmount

1:1

Integer

Total amount liquidated in cents

Table 125.- DriverCashSettlement DG message structure

Ticket Vending OPI commands

MQTT topic under …/ticket_vending/<OPI_version>/cmd

Fields

+Structure

Description

<Common fields for every JSON command message>

/shutdown

reason

0:1

String

Switch off the ticket vending application and Optional free-text indicating the reason,

/reset

reason

0:1

String

Reset the ticket vending application and optional free-text indicating the reason.

/lock_session

reason

0:1

String

Disable ticket vending and optional free-text indicating the reason.

/unlock_session

-

0:1

String

Unlock session. Enable ticket vending

/set_maintenance

active

1:1

Boolean

Enter/exit maintenance mode (true / false)

/set_demo

active

1:1

Boolean

Enter/exit demo mode (true / false)

/request_config

-

-

-

Provider will return all config parameters in the details field structure (see Command Responses). Configuration parameters for the ticket_vending OPI and their data type must be specified (volumeLevel, screenBrightLevel, language, driverScreenContrast, passengerScreenContrast…)

Structure of details field in response will be:

responseContent 0:* Object Config parameters

<configId1> - anyType1 Each parameter value

<configId2> - anyType2

/set_config

volumeLevel

0:1

anyType1

Public configuration key, with its value to set.

screenBrightLevel

0:1

anyType2

Public configuration key, with its value to se.

Table 126.- Ticket Vending OPI commands and fields

VEHICLE SERVICE MONITORING OPIs

OPI Network Location

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

network_location

NetworkLocationAll

  • A vehicle can be at any of the following types of network locations (See #Anexo A. Understanding Network location):

On service

On a DeadRun (to start service, to Depot after finishing service, to change Line or making a manouver)

At Depot (at specific predefined areas within a depot: parking, washing, fueling, charging, workshop)

Depending on the type of network location (field runState), three different objects can be published in the JSON message.

  • Triggers:

at startup and on discrete change

While On Service:

X m before arrival to a stop

At arrival to a stop

At departure from a stop

While moving between stops, NL should be updated every 10m or 3s

At the start of a deviation

At the end of a deviation

When out of journeyPattern is detected

When return to journeyPattern is detected

  • none

OPI version

v1.0

Table 127.- OPI Network Location summary

NetworkLocationAll DG

<root>/operation/<provider_guid>/network_location/<OPI_version>/data/network_location_all

Table 128.- Topic path for NetworkLocationAll DG

NetworkLocationAll

+Structure

Description

<Common fields for every JSON data message>

runState

1:1

String (Enum)

Defines the type of network location the vehicle is in: nlOnService | nlOnDeadRun | nlAtDepot

nlOnService

0:1

Object

Mandatory only when runState = "nlOnService"

lineRef

1:1

String

Identifier of operational Line that vehicle follows

servicePatternRef

0:1

String

Identifier of the Service Pattern

directionRef

0:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound| out = outbound |cw = clockwise | ccw = counterclockwise | other

networkLocationStatus

1:1

String (Enum)

onRoute | onDeviation | outOfRoute | unknown

positionReferencedToStops

1:1

Object

Information about position referenced to Stop Points

stopRelativePosition

1:1

String

AfterPreviousStop | BetweenStops | BeforeNextStop | AtNextStop (if vehicle is AtNextStop => NextStop=CurrentStop)

previousStop

1:1

Object

Last stop the vehicle has passed through (whether it stopped or not)

stopPointRef

1:1

String

Identifier of StopPoint.

stopPointName

0:1

String

Name of StopPoint.

stopPointIndex

1:1

Integer

Order of the StopPoint in the ServicePattern (1= first stop of the Service Pattern)

isLastStop

1:1

Boolean

true (if the StopPoint is the last stop of the ServicePattern) | false otherwise

nextStop

1:1

Object

Information about next stop

stopPointRef

1:1

String

Identifier of StopPoint.

stopPointName

0:1

String

Name of StopPoint.

stopPointIndex

0:1

Integer

Order of the StopPoint in the ServicePattern (1 = first stop of the Service Pattern)

isLastStop

1:1

Boolean

true (if the StopPoint is the last stop of the ServicePattern) | false otherwise

linkDistance

1:1

Integer

The total distance in metres between the current stop and the next stop according to the planned pattern.

percentageTraveled

1:1

Integer

Percentage along links that vehicle has travelled.

serviceInfo

0:1

Object

blockRef

0:1

String

Reference (identifier) of the Block assigned

courseOfJourneyRef

0:1

String

Course of Journey assigned

serviceJourneyRef

0:1

String

Current Service Journey (In case it is at terminus, this will be the next Service Journey)

activationPoint

0:1

Object

A POINT where a control process is activated when a vehicle passes.

activationPointRef

0:1

String

Reference (identifier) to the activation Point.

activationPointType

0:1

String

E.g. Traffic signal priority request

area

0:1

areaRef

1:1

String

E.g. to identify an interchange station

areaName

0:1

String

E.g. name of interchange station

subAreaRef

0:1

String

E.g. part of the interchange station where the bus is

subAreaName

0:1

String

E.g. entrance ramp, park area, level 1 quay…

quayRef

0:1

String

In case the bus is in a quay

quayName

0:1

String

In case the bus is in a quay

nlOnDeadRun

0:1

Object

Present only when runState = "nlOnDeadRun"

deadRunPatternRef

1:1

String

Dead Run reference (identifier)

deadRunType

1:1

String (Enum)

depotToLine | lineToDepot | lineToLine | maneuver | unknown

targetLineRef

1:1

String

Line the vehicle is heading to

targetDepotRef

1:1

String

Depot the vehicle is heading to

positionReferencedToPoints

1:1

Object

DeadRunPattern points, at least initial and end points

previousPointRef

1:1

String

Reference of the previous point in the DeadRun Pattern

nextPointRef

1:1

String

Reference of the next point to be reached within the DeadRun Pattern

subAreaRef

0:1

String

Reference to a sub-area related to the DeadRun segment

segmentDistance

1:1

Integer

Planned distance in meters between previousPointRef and nextPointRef

segmentTraveled

1:1

Integer

Percentage of the segment already travelled by the vehicle (%)

additionalInfo

0:1

String

Optional free-text information about the dead run.

nlAtDepot

0:1

Object

Present only when runState = "nlAtDepot"

vehicleServiceStatus

1:1

String (Enum)

startingService | finishingService | noService

depotRef

1:1

String

Reference identifier of the depot where the vehicle is currently located

depotName

0:1

String

Human-readable name of the depot

area

0:1

Object

areaRef

1:1

String

areaName

0:1

String

subAreaRef

0:1

String

functionalType

0:1

String (Enum)

parking | workshop | washing | fueling | charging | other

parkingBayRef

0:1

String

Table 129.- NetworkLocationAll DG message structure

OPI Employee Log

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

employee_log

EmployeeLogAll

  • Informative data: driver session start or re-login if TVM was blocked, driver session end.
  • Trigger: publish when the login succeeds or the logout completes on the HMI.
  • none

OPI version

v1.0

Table 130.- OPI Employee Log summary

EmployeeLogAll DG

<root>/operation/<provider_guid>/employee_log/<OPI_version>/data/ employee_log_all

Table 131.- Topic path for EmployeeLogAll DG

EmployeeLogAll

+Structure

Description

<Common fields for every JSON data message>

logType

1:1

String (Enum)

Defines the type of event related to the employee log.

driverLogin | driverLogout | employeeLogin | employeeLogout | other

driverLogin

0:1

Object

Present only when logType = "driverLogin"

driverRef

1:1

String

Driver identifier reference.

driverName

0:1

String

Display name (if available).

authMethod

1:1

String (Enum)

Authentification method used such as pin (numeric passcode typed on HMI), rfid (driver card), barcode (QR/1D code), remote (backoffice). See the following possible enums: pin | rfid | barcode | remote

sessionId

0:1

String

Created at login. Identifier of the open session. If there was a previous lock and the employee just re-entered the pin, this session will already be active.

dutyRef

String

Duty identifier reference (work to be performed by a driver on a particular day type)

loginType

1:1

String (Enum)

See the following possible enums: startOfShift | unlock | handover | other (e.g. provider/app reset)

driverLogout

0:1

Object

Present only when logType = "driverLogin"

driverRef

1:1

String

Driver identifier reference.

sessionId

1:1

String

Session being closed.

source

1:1

String (Enum)

Origin of the logout action. See the following possible enums: local | remote

reason

0:1

String (Enum)

Reason of logout. See the following possible enums: endOfShift | handover | lock

printCashSettlement

0:1

Boolean

When it applies, set as “true” (e.g. reason = endOfShift or handover). Otherwise, “false”.

employeeLogin

0:1

Object

Present only when logType = "employeeLogin"

employeeRef

1:1

String

Employee identifier reference.

employeeName

0:1

String

Display name (if available)

authMethod

1:1

String (Enum)

Authentification method used such as pin (numeric passcode typed on HMI), rfid (driver card), barcode (QR/1D code), remote (backoffice). See the following possible enums: pin | rfid | barcode | remote

sessionId

0:1

String

Created at login. Identifier of the open session. If there was a previous lock and the employee just re-entered the pin, this session will already be active.

employeeLogout

0:1

Object

Present only when logType = "employeeLogin"

employeeRef

1:1

String

Employee identifier reference.

sessionId

1:1

String

Session being closed.

Table 132.- EmployeeLogAll DG message structure

OPI Journey Monitoring

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

journey_monitoring

The JourneyMonitoring DataGroup can contain one or many Vehicle Journeys, including Service Journeys and Dead Runs. The same DataGroup is published in all 3 topics with different vehicleJourneyReportType:

CurrentVehicleJourney

  • All vehicle journeys in this DataGroup will have VehicleJourneyReportType = Current except for the Next.
  • Trigger: at startup and on discrete change.

EstimatedVehicleJourneys

  • All vehicle journeys in this DataGroup will have VehicleJourneyReportType = Next or EstimatedAfterNext.
  • Trigger: at startup and on discrete change.

ObservedVehicleJourneys

  • All vehicle journeys in this DataGroup will have VehicleJourneyReportType = Observed
  • Trigger: at startup and on discrete change.
  • none

OPI version

v1.0

Table 133.- OPI Journey Monitoring summary

CurrentVehicleJourneyAll, EstimatedVehicleJourneysAll, ObservedVehicleJourneysAll DGs

<root>/operation/<provider_guid>/journey_monitoring/<OPI_version>/data/current_vehicle_journey_all

<root>/operation/<provider_guid>/journey_monitoring/<OPI_version>/data/estimated_vehicle_journeys_all

<root>/operation/<provider_guid>/journey_monitoring/<OPI_version>/data/observed_vehicle_journeys_all

Table 134.- Topic path for CurrentVehicleJourney, EstimatedVehicleJourneys and ObservedVehicleJourneys DGs

The CurrentVehicleJourneyAll, EstimatedVehicleJourneysAll and ObservedVehicleJourneysAll DGs use a common VehicleJourney message structure with different vehicleJourneyReportType value, as follows:

VehicleJourney

+Structure

Description

<Common fields for every JSON data message>

vehicleJourneys

2:*

Object

List of vehicle journeys

vehicleJourneyReportType

1:1

String (Enum)

current | next | estimatedAfterNext | observed

blockRef

1:1

String

Identifier of the Block

vehicleJourneyOrderInBlock

0:1

Integer

Order number of this journey within the assigned block.

vehicleJourneyPositionInBlock

1:1

String (Enum)

first | intermediate | last

vehicleJourneyType

1:1

String

serviceJourney | deadRun

vehicleJourneyDelay

0:1

Integer

Delay to a precision in seconds. Early times are shown as negative values.

vehicleJourneyProgressStatus

0:1

String (Enum)

onTime | early | late

occupancyStatus

0:1

String (Enum)

empty | low | noSeats | high | full (no passengers allowed)

vehicleEquipment

0:1

String

Information about relevant onboard equipment state during the journey (e.g. ramp…)

serviceJourney

1:1

Object

1:1 if vehicleJourneyType = serviceJourney, 0:0 Otherwise

serviceJourneyRef

1:1

String

Identifier of the Service Journey

courseOfJourneyRef

0:1

String

Identifier of the Course of Journey

serviceJourneyOrderInCourseOfJourney

0:1

Integer

Order of this Service Journey within its CourseOfJourney

serviceJourneyPositionInCourseOfJourney

0:1

Integer

first | intermediate | last

lineRef

1:1

String

Identifier of operational Line that vehicle follows

routeRef

0:1

String

Route identifier

servicePatternRef

1:1

String

Identifier of the Service Pattern

directionRef

1:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound | out = outbound | cw = clockwise | ccw = counterclockwise | other

serviceJourneyStartTime

1:1

DateTime

It will be Observed if vehicleJourneyReportType = current or observed

It will be Estimated if vehicleJourneyReportType = next or estimatedAfterNext

serviceJourneyTargetStartTime

0:1

DateTime

It will be Target valid when observed if vehicleJourneyReportType = current or observed

It will be current Target if vehicleJourneyReportType = next or estimatedAfterNext

serviceJourneyEndTime

0:1

Datetime

It will be Observed if vehicleJourneyReportType = observed

It will be Estimated if vehicleJourneyReportType = current, next or estimatedAfterNext

serviceJourneyTargetEndTime

0:1

DateTime

It will be Target valid when observed if vehicleJourneyReportType = observed

It will be current Target if vehicleJourneyReportType = current, next or estimatedAfterNext

serviceJourneyCharacteristics

1:1

Object

serviceJourneyBase

0:1

String (Enum)

Indicates if this journey is: base | variant

expressServiceJourney

0:1

Boolean

true | false

serviceJourneyControlActions

1:1

Boolean

true (if it is affected by any control action) | false (if none)

serviceJourneyTimetableControl

0:1

String (Enum)

timeBased | frequencyBased

onDemandServiceJourney

1:1

Boolean

true | false

serviceFeatureRef

0:1

String

Reference to a Service Feature classification (see SIRI: Airport line, School Service …)

vehicleFeatureRef

0:1

String

Reference to a Vehicle Feature (see SIRI: Accessible..)

controlActions

0:*

Object

Control actions affecting the Service Journey.

1:* if serviceJourneyControlActions = true, 0:* Otherwise

isExtraJourney

0:1

Boolean

true | false

cancelled

0:1

Boolean

If cancelled

partialCancellation

0:1

Boolean

If there will be estimated calls cancelled

changeOfTiming

0:1

Boolean

If calls will have times differing from the planned times

changeOfJourneyPattern

0:1

Boolean

If calls will happen at stops differing from the planned ones

plannedJourneyPatternRef

0:1

String

Planned Journey Pattern Reference

targetJourneyPatternRef

0:1

String

New Journey Pattern Ref affected by the control action

respacing

0:1

Boolean

If vehicle affected by a respacing control action

resorption

0:1

Boolean

If vehicle affected by a resorption control action

calls

2:*

Object

At least current and next calls

callReportType

1:1

String (Enum)

current (if vehicle is at stop) | next | estimatedAfterNext | observedPrevious | observedBeforePrevious

stopPointRef

1:1

String

Identifier of StopPoint

stopIndexInServiceJourney

0:1

String

StopPoint order in the ServicePattern (1 = first stop of the Service Pattern

stopPositionInServiceJourney

1:1

String (Enum)

first | intermediate | last

callArrivalTime

1:1

DateTime

It will be Observed if callReportType = current, observedPrevious or observedBeforePrevious
It will be Estimated if callReportType = next or estimatedAfterNext

callTargetArrivalTime

0:1

DateTime

It will be the Target valid when Observed if callReportType = current, observedPrevious or observedBeforePrevious

It will be the current Target if callReportType = next or estimatedAfterNext

callDatedArrivalTime

0:1

DateTime

callDepartureTime

1:1

DateTime

It will be Observed if callReportType = observedPrevious or observedBeforePrevious

It will be Estimated if callReportType = current, next or estimatedAfterNext

callTargetDepartureTime

0:1

DateTime

It will be the Target valid when Observed if callReportType = observedPrevious or observedBeforePrevious

It will be the current Target if CallReportType = current, next or estimatedAfterNext

callDatedDepartureTime

0:1

DateTime

callCharacteristics

1:1

Object

isTimingPoint

1:1

Boolean

true | false

onDemandCall

1:1

Boolean

true | false

boardingAlightingRestrictions

0:1

String

noRestrictions | onlyBoarding |

callControlActions

1:1

String (Enum)

extraCall | canceledCall | waitAtCall (departure lag)

noCall

1:1

Boolean

Only for Observed Calls, indicates whether the bus stopped at the stop or not

wheelChairPositionFree

0:1

Boolean

true | false

stopRequest

0:1

Boolean

true | false

activationPasses

0:*

Object

Steps by activation points: current, estimated and observed

activationPassReportType

1:1

String (Enum)

current (vehicle arrival at activation point) | estimated | observed

activationPointRef

1:1

String

Reference to activation point

activationPointType

1:1

String

Activation point type (e.g. )

activationInformation

0:1

String

activationPassTime

0:1

DateTime

activationCharacteristics

0:1

Object

isStartOfActivationLink

1:1

Boolean

true | false

isEndOfActivationLink

1:1

Boolean

true | false

activationIsActive

1:1

Boolean

true | false

deadRun

0:1

Object

1:1 if vehicleJourneyType = deadRun, 0:0 Otherwise

deadRunRef

0:1

String

deadRunPatternRef

0:1

String

deadRunStartTime

0:1

DateTime

It will be Observed if vehicleJourneyReportType = current or Observed

It will be Estimated if vehicleJourneyReportType = next or estimatedAfterNext

deadRunTargetStartTime

0:1

DateTime

It will be the Target valid when observed if vehicleJourneyReportType = current or observed

It will be current Target if vehicleJourneyReportType = next or estimatedAfterNext

deadRunEndTime

0:1

DateTime

It will be Observed if vehicleJourneyReportType = observed

It will be Estimated if vehicleJourneyReportType = current, next or estimatedAfterNext

deadRunTargetEndTime

1:1

DateTime

It will be Target valid when observed if vehicleJourneyReportType = observed

It will be current Target if vehicleJourneyReportType = current, next or estimatedAfterNext

deadRunTypeRef

1:1

String (Enum)

fromDepotToLine | fromLineToDepot | fromLineToLine | other

passingTimes

2:*

Object

At least current and next

passingTimeReportType

1:1

String (Enum)

current (vehicle is at point) | next | estimatedAfterNext | observedPrevious | observedBeforePrevious

pointRef

1:1

String

pointType

1:1

String

pointOrderInDeadRun

0:1

Integer

pointPositionInDeadRun

1:1

String (Enum)

first | intermediate | last

pointPassingTime

0:1

DateTime

pointTargetPassingTime

0:1

DateTime

Table 135.- Common VehicleJourney structure for CurrentVehicleJourney, EstimatedVehicleJourneys and ObservedVehicleJourneys DGs

OPI Vehicle Assignment

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

vehicle_assignment

VehicleAssignmentAll

  • Vehicle assignment and unassignment to a Block, Course of Journey or Service Journey
  • Trigger: at startup and on discrete change
  • none

OPI version

v1.0

Table 136.- OPI Vehicle Assignment summary

VehicleAssignmentAll DG

<root>/operation/<provider_guid>/vehicle_assignment/<OPI_version>/data/vehicle_assignment_all

Table 137.- Topic path for VehicleAssignmentAll DG

VehicleAssignmentAll

+Structure

Description

<Common fields for every JSON data message>

vehicleAssignmentType

1:1

String (Enum)

vehicleServiceLogOn | vehicleServiceLogOff

blockRef

0:1

String

Reference (ID) of Block assigned

courseOfJourneyRef

0:1

String

Reference (ID) of Course of Journey assigned

serviceJourneyRef

0:1

String

Reference (ID) of Service Journey assigned

LineRef

1:1

String

Identifier of operational Line that vehicle follows

servicePatternRef

0:1

String

Service Pattern reference. At least one of servicePatternRef, routeRef or directionRef must be published.

routeRef

0:1

String

Route identifier. At least one of servicePatternRef, routeRef or directionRef must be published.

directionRef

0:1

String (Enum)

Relative direction the vehicle is running along the line:

in = inbound | out = outbound | cw = clockwise | ccw = counterclockwise | other

At least one of servicePatternRef, routeRef or directionRef must be published.

vehicleAssignmentReason

0:1

String (Enum)

service = start or end of a planned service

reinforcement = start or end of an unplanned reinforcement

changeOfVehicle = start a service substituting a vehicle

vehicleBreakDown = end service due to vehicle breakdown

cancelation = end of service due to Block or Course of Journey cancellation

Table 138.- VehicleAssignmentAll DG message structure

OPI Driver Messages

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

driver_messages

DriverMessagesAll

  • Message generated by the driver
  • Trigger: each time a driver sends a message.
  • message_to_driver

OPI version

v1.0

Table 139.- OPI Driver Messages summary

DriverMessagesAll DG

<root>/operation/<provider_guid>/driver_messages/<OPI_version>/data/driver_messages_all

Table 140.- Topic path for DriverMessagesAll DG

DriverMessagesAll

+Structure

Description

<Common fields for every JSON data message>

driverRef

0:1

String

Driver identifier reference.

driverMessageRef

1:1

Integer

Message identifier

driverMessageText

1:1

String

Text of message

driverMessageType

0:1

String (Enum)

operational | safety | information | alert | incident | instruction

severity

1:1

String (Enum)

info | warning | critical | other

Table 141.- DriverMessagesAll DG message structure

message_to_driver command

<root>/operation/<provider_guid>/driver_messages/<OPI_version>/cmd/message_to_driver/<sender_GUID>

Table 142.- Topic path for message_to_driver command

message_to_driver

+Structure

Description

<Common fields for every JSON cmd message>

messageToDriverRef

1:1

Integer

Message identifier

messageToDriverText

1:1

String

Text of message

messageToDriverType

0:1

String (Enum)

operational | safety | information | alert | incident | instruction

severity

1:1

String (Enum)

info | warning | critical | other

Table 143.- message_to_driver command message structure

OCCUPANCY OPIs

OPI APC Sensor

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

apc_sensor

ApcSensorAll

  • Accumulated number of passengers boarding and alighting at one or more doors since startup
  • Trigger: after each door closing if the Provider has this information and periodically, every T=2s if the information changes (if there have been new boardings of alightings in the last T seconds)
  • enable_counting
  • reset_counters

OPI version

v1.0

Table 144.- OPI APC Sensor summary

ApcSensorAll DG

<root>/operation/<provider_guid>/apc_sensor/<OPI_version>/data/apc_sensor_all

Table 145.- Topic path for ApcSensorAll DG

ApcSensorAll

+Structure

Description

<Common fields for every JSON data message>

doorSensor

1:*

Object

Usually * will be 1 (each sensor at each door publishes data)

doorId

1:1

Integer

Identifer of the door associated (e.g., 1 = front, 2 = middle, 3 = rear). Must match the door indexing used in the vehicle

doorCountingQuality

0:1

String

Normal | Defect

typeOfElementCounted

1:*

Object

Repeated for each counted element reported

elementType

0:1

String (Enum)

Information about the type of counted element.

adult | bike | child | pram | wheelchair | unidentified | other

boardingCounts

1:1

Integer

Number of accumulated boardings detected for this elementType.

alightningCounts

1:1

Integer

Number of accumulated alightings detected for this elementType.

Table 146.- ApcSensorAll DG message structure

enable_counting command

<root>/operation/<provider_guid>/apc_sensor /<OPI_version>/cmd/enable_counting/<sender_GUID>

Table 147.- Topic path for enable_counting command

enable_counting

+Structure

Description

<Common fields for every JSON cmd message>

enableCounting

1:1

Boolean

true (enable) | false (disable counting)

Table 148.- enable_counting command message structure

reset_counters command

<root>/operation/<provider_guid>/apc_sensor /<OPI_version>/cmd reset_counters/<sender_GUID>

Table 149.- Topic path for reset_counters command

reset_counters

+Structure

Description

<Common fields for every JSON cmd message>

resetCounters

1:1

Boolean

true

Table 150.- reset_counters command message structure

OPI Occupancy

Description

OPI name

Operational Data Provided (DataGroups)

Inputs accepted

occupancy

OccupancyAll

  • Number of passengers onboard, %Occupancy, passengers per m2, occupancy level and accumulated boardings and alightings (all doors).
  • Trigger: after each door closing if the Provider has this information and periodically, every T=2s if the occupancy has changed in the last T seconds
  • reset_occupancy (Set occupancy to cero)

OPI version

v1.0

Table 151.- OPI Occupancy summary

As with any OPI, the Occupancy OPI can be implemented by more than one Provider, such as a dedicated application subscribed to the data needed to calculate Occupancy (APC sensors counts at each door (/apc_sensor_all for each door), Validation and Ticket vending transactions, Vehicle specs (capacity seated and stand still), an application based on image processing which will typically be able to provide the number of passengers onboard, or a driver interface where the driver can manually indicate an approximate level of occupancy (occupancyStatus).

Each Provider will publish just the information it provides. In order to know the source of the information the Consumer can look for the Provider GUID in the inventory and retrieve the Provider information.

OccupancyAll DG

<root>/operation/<provider_guid>/occupancy /<OPI_version>/data/occupancy_all

Table 152.- Topic path for OccupancyAll DG

OccupancyAll

+Structure

Description

<Common fields for every JSON data message>

numberOfPassengers

1:1

Integer

Number of passengers onboard

percentageOfOccupancy

0:1

Integer

Percentage of Occupancy onboard (%)

passengersPerSquareMeter

0:1

Integer

Number of passengers per square meter

occupancyStatus

0:1

Integer

0 = Empty

1 = Many seats available

2 = Few seats available

3 = Standing room only

4 = Crushed standing room only

5 = Full

6 = Not accepting passengers

totalBoardings

0:1

Integer

At vehicle level (all doors)

totalAlightings

0:1

Integer

At vehicle level (all doors)

occupancyPerTypeOfElement

0:*

Object

Repeated for each counted element reported

elementType

1:1

String (Enum)

Information about the type of counted element.

adult | bike | child | pram | wheelchair | unidentified | other

elementTypeCount

1:1

Integer

Number of elements onboard

Table 153.- OccupancyAll DG message structure

reset_occupancy command

<root>/operation/<provider_guid>/occupancy/<OPI_version>/cmd/reset_occupancy/<sender_GUID>

Table 154.- Topic path for reset_occupancy command

reset_occupancy

+Structure

Description

<Common fields for every JSON cmd message>

resetOccupancy

1:1

Boolean

true

Table 155.- reset_occupancy command message structure

    Anexo A – Understanding Network location

A vehicle can be at any of the following types of network locations:

  • On service
  • On a DeadRun (to start service, to Depot after finishing service, to change Line or making a manouver)
  • At Depot (at specific predefined areas within a depot: parking, washing, fueling, charging, workshop)
Figure 2.- Location of a bus relative to the Network. This information is published in three possible Network Location Data Groups: NL_DeadRun, NL_Depot and NL_Service depending on the bus Location
Figure 2.- Location of a bus relative to the Network. This information is published in three possible Network Location Data Groups: NL_DeadRun, NL_Depot and NL_Service depending on the bus Location

A VEHICLE On service may have the following location in relation to the stops:

  • Arriving a stop
  • At a stop (arrive to stop)
  • Leaving a stop
  • Between stops
  • On a deviation
  • Out of route
Figure 3.- Location of a bus in service relative to the bus Stops
Figure 3.- Location of a bus in service relative to the bus Stops

Additionally, a vehicle On service may be at an interchange station area, where the following locations are relevant:

  • Arriving at interchange station
  • Entering entrance ramp, at entrance ramp, exit entrance ramp
  • When entering or leaving predefined areas (At bay area, At rest area…)

    Anexo B – OPIs Catalog

Domains

Content

OPIs

Physical Vehicle

Vehicle Telemetry

Information related to the physical vehicle and its base (non ITS) equipment: vehicle static data (ID, vehicle specifications) CAN J1939 data, GNSS data, data from sensors (e.g. odometer, accelerometer, internal thermometers…) and data from signals (e.g. ignition, doors status).

  • Vehicle static information

Vehicle IDs

Vehicle Specifications

CAN Data available

Signals available

  • CAN Raw PGN
  • Raw Vehicle Signals
  • Gnss
  • Vehicle motion sensors data:

Accelerations

Odometer

Other: angular_rate_gyro, can_motion_data, alti_baro, compass, location_beacon

  • Vehicle status

Tell Tale Status

Diagnostic Messages

Vehicle Modes

  • Passengers area information
  • Vehicle energy sources information

High Voltage Energy storage System (HVESS)

Other: Fuel, Fuel Cell (H2), Aux batteries and alternators, Global energy metrics

  • Vehicle dynamics systems information

Powerplant

Drivetrain

Running_gear

Steering

Brakes

Active_safety

  • Vehicle auxiliary systems information
  • Vehicle ECUs information

Vehicle PT Operation

Ticketing

Validation and ticket sales transactions and other information related to ticketing

  • Validator
  • Ticket Vending
  • Host SAM module (HSM)
  • Validator Front End:

Vehicle Service Monitoring

Information related to the service run by the vehicle

  • Network Location
  • Employee Log
  • Journey Monitoring
  • Vehicle Assignment
  • Driver Messages
  • PreServiceCheck

Occupancy

Passenger counting and vehicle occupancy %occupancy, passenger density, occupancy status (e.g. vehicle full)

  • Apc sensor
  • Occupancy (metrics and status)

Note: In the OPIs column, items in bold are specified in the document. The remaining OPIs are planned for future releases.