Use Case 12 is dedicated to information related to the protection in real time of workers who carry out conservation actions on the roads. This service include the information provided by Connected Cones

Receipt and publication of data related to the real-time positioning of:

• Maintenance workers

• Construction and maintenance vehicles found on the tracks

This information can be sent to the DGT 3.0 platform either by IoT devices or by Apps that can be used to position these elements on the road.

The platform has two different functionalities for the publication (sending) and for the subscription (reception) of information. The first is through a REST API and the second through a real-time MQTT service.

Both the publication and subscription functionality require different access certificates that must be requested and supplied by DGT 3.0. If these certificates have not already been requested, they should be requested from soporte@cmobility30.es.

Everything related to MQTT is temporarily disabled.

Below are the URLs with which each functionality is accessed:

The two functionalities are described below.

Publication

This use case has a REST API for the publication (sending) of the data by the companies that request it. Details of this can be found in the following sections:

• General details for making a request:

General · (cmobility30.es)

• The details of the master tables and data that can compose the event:

Master Tables

• The structure of the event can be seen here:

Event

Subscription

This use case also has a subscription service (reception) to the data for the companies that request it through the MQTT protocol. Below you can find the details of this:

MQTT (MQ Telemetry Transport) is a messaging protocol used as a simple and lightweight method to transfer data to / from low-power devices.

The protocol supports a single messaging pattern, the Publish-Subscribe pattern: each message is published on a topic that must be subscribed to in order to receive the information.

Subscription to the service of this use case must be through the topic:

usecase12/events

In the topic, the events are published in JSON format. Here you can see an example:

​​​​​​​​{
"actionId": "CLI_235",
"beaconId": "cff92179-dc0a-47da-bd9e-5e9c5b14d251",
"beaconTypeId": 1,
"timestamp": "2021-06-02T13:34:56.747Z",
"lon": -4.304818,
"lat": 41.312456,
"speed": 85,
"eventTypeId": 1,
"provinceId": 40,
"road": "A-601",
"pk": 64.73,
"direction": "UP"
}​​​​​​​​

• actionId (text): unique identifier of the event

• beaconId (text): unique identifier of the beacon (for example, the MAC)

• beaconTypeId (integer number): beacon type identifier. 1 = Start, 2 = End, 3 = Intermediate, 4 = Unique

• timestamp (UTC time): date and time in UTC format of when the event was generated. It must be a maximum of 30 seconds old with respect to UTC time. The date must end with the character 'Z' that marks that it is in UTC

• lon (decimal number): longitude in WGS 84 coordinate system where the event was generated

• lat (decimal number): latitude in WGS 84 coordinate system where the event was generated

• vehicleTypeId (integer number): vehicle type identifier. 0 = None, 1 = Car, 2 = Motorbike

• deviceTypeId (integer number): identifier of the type of device from which the information is sent. 1 = Baliza, 2 = Chaleco, 3 = Cono

• deviceUseTypeId (integer number): identifier of the type of use of the device that sends the information. 1 = Worker, 2 = Vehicle, 3 = Infrastructure

• speed (integer number): speed measured in kilometers per hour at which the element is at the moment it sends the event

• provinceId (integer number): identifier of the province where the event is generated according to the INE

• road (integer number): official name of the road where the event is generated

• pk (integer number): kilometer point where the event is generated

• direction (String): direction of the road where the event is generated. UP = Upward direction, DOWN = Downward direction, UNKNOWN = Unknown

See more information and a connection example here.

Errors

As stated above, all HTTP responses other than 200 – OK, can be considered invalid. The format of the error response is like the following example:

{
    "status": 401,
    "code": 1,
    "message": "User not found or valid"
}

These errors will have three main categories:

Authentication Error

• HTTP Status: 401 - Unauthorized

  Code	Message
  1	User not found or valid

Client Error

• HTTP Status: 400 - Bad Request

  Code	Message
  0	Authenticate
  2	Entity ID not found
  3	Missing required property
  4	The entity received cannot be proccessed
  5	Incorrect token received
  6	Expired token received
  7	There is an error with the token provided. Please request a new one
  8	No token received
  9	Required request body is missing
  10	Event is marked as expired by timestamp
  11	Missing request header
  12	Permission denied. Role assigned to user missing
  13	There is an error in one or more elements of the list
  14	Cone use type must be Infraestructure
  15	Cone vehicle type must be None
  16	Cone beacon type must be Unique

In the case of getting an error 3 - Missing required property, the response obtained will have a value in the message that will indicate the missing fields to send:

{
    "status": 400,
    "code": 3,
    "message": "[deviceTypeId: must not be null, deviceUseTypeId: must not be null, informationQualityId: must not be null]"
}

Server Error

• HTTP Status: 500 - Internal Server Error

  Code	Message
  17	Internal error