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 |
Document content
The specification of OPIs is divided into the following domains:
|
Operational Data Domains |
Content |
|
|
Physical Vehicle |
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 |
Validation and ticket sales transactions and other information related to ticketing |
|
|
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. |
||
|
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.
-
/<cmd1_name> (one topic for each command)
-
/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.
-
/cmd (if any)
-
/<OPI_version>
** 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).
The following is an example of a topic structure under <root>/operation/<provider_GUID> for the OPI “Validator”:
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.
-
/<DataGroup1_topic_name>
(Examples: /accel_raw or
/feee = <pgn hex string>)
-
/<OPI_version>
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. |
|
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:
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)
<DG2Nname> (DataGroup2 name)
… |
(List of commands accepted)
|
|
OPI version |
||
|
<OPI_version> |
(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 |
|
|
<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
VehicleSpecs
CanDataAvailable
SignalsAvailable
|
|
|
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). |
||
|
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. |
||
|
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>
TimeStamp in microseconds Raw Hex String of the PGN
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. |
|
|
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
|
|
|
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
|
|
|
OPI version |
||
|
v1.0 |
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
VehicleAccelerations
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
EngineStatus
ParkingBrakeStatus
ChargingStatus
DrivingMode
PowerMode
|
|
|
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
PassengersAreaAmbientConditions
LuggageCompartmentStatus
StopRequestStatus
PassengersSeatbeltsStatus
|
|
|
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::
hvessHighestCellTemp (Object in DG) hvessLowestCellTemp (Object in DG)
hvessHighestCellVolt (Object in DG) hvessLowestCellVolt (Object in DG)
hvessHighestCellSoc (Object in DG) hvessLowestCellSoc (Object in DG)
Trigger: at startup, on discrete change and on threshold change for continuous values |
|
|
OPI version |
||
|
v1.0 |
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
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
|
|
|
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
TicketVendingOpParameters
DriverCashSettlement
|
|
|
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
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.
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 |
|
|
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
|
|
|
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
EstimatedVehicleJourneys
ObservedVehicleJourneys
|
|
|
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 |
||||
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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)
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
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 IDs Vehicle Specifications CAN Data available Signals available
Accelerations Odometer Other: angular_rate_gyro, can_motion_data, alti_baro, compass, location_beacon
Tell Tale Status Diagnostic Messages Vehicle Modes
High Voltage Energy storage System (HVESS) Other: Fuel, Fuel Cell (H2), Aux batteries and alternators, Global energy metrics
Powerplant Drivetrain Running_gear Steering Brakes Active_safety
|
|
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 |
|
|
|
Occupancy |
Passenger counting and vehicle occupancy %occupancy, passenger density, occupancy status (e.g. vehicle full) |
|
|
Note: In the OPIs column, items in bold are specified in the document. The remaining OPIs are planned for future releases.
On this page
- INTRODUCTION
- ODEx Documents
- Document content
- COMMON
- OPI Topic Structure & DataGroups
- Command Requests
- Command Responses
- Cardinality Notation Used for the JSON fields
- Data Types Used for the JSON fields
- Naming notation
- Common messages publication Triggers
- Versioning Rules in ODEx OPIs
- OPIs SPECIFICATION DESCRIPTION FORMAT
- OPI <OPI Name>
- VEHICLE TELEMETRY OPIs
- OPI Vehicle Static Information
- OPI CAN Raw PGN
- OPI Raw Vehicle Signals (digital)
- OPI Gnss
- Vehicle Motion Sensors
- Vehicle status
- OPI Passengers Area Information
- Vehicle Energy Sources Information
- TICKETING OPIs
- OPI Validator
- OPI Ticket Vending
- VEHICLE SERVICE MONITORING OPIs
- OPI Network Location
- OPI Employee Log
- OPI Journey Monitoring
- OPI Vehicle Assignment
- OPI Driver Messages
- OCCUPANCY OPIs
- OPI APC Sensor
- OPI Occupancy
