Use case 1
Signal V 16
This use case responds to the need to comply with what is regulated in Instruction 18 / V-132 of the DGT and in [RD 159/2021, of March 16, which regulates aid services on public roads ] (https://www.boe.es/boe/dias/2021/03/17/pdfs/BOE-A-2021-4194.pdf), in which the new V-16 signal devices , to send a message to the DGT3.0 platform. Therefore, the communication between the cloud of the manufacturer of these devices and the DGT3.0 platform is detailed.
All requests made to the API must be sent to the following URL (base URL):
To publish information, a REST API is available:
Identificación en el servicio
To carry out the API operations, it is necessary to obtain a session token that will expire randomly throughout the session. The identification operation is described in the documentation
- The details of the master tables and data that can compose the event:
- Information regarding the event to be sent:
Where can I get the company id for the connection?
Confirmation that the microservice that will receive the UDP datagrams from the beacons when the backup connection is used will implement an “acknowledgement” mechanism as described in the BOE.
The BOE indicates that "The protocol will include a response UDP packet (acknowledgment of receipt) by the telephone operator, which the manufacturer may use for the purpose of controlling the arrival of the packet, since the UDP protocol does not have this feature.” This came out in some meetings with the Operators. From the platform, what we will do is publish the messages.
Clarify the meaning of the three frame types (“Frame Type” field) of protocol A and resolve inconsistencies between the BOE and the Wiki for frame type 0 (“Incident Start” or “Battery Report”?) .
0 indicates that the device has been turned on and the incidence begins to be taken into account. 1 indicates that the device is still on. 3 indicates that the device has been turned off, and from that moment it will not be considered a risk.
Clarify the mapping between the frame type of protocol A, and the device_event_type_value” field of the message of protocol B.
Clarify which timestamp should be placed in the "detection_time" parameter (the one of the first message sent by the beacon or the time of receipt of that message on the platform?).
It is the moment in which the reported event occurs. In the activation, the beginning, during the incidence each of the instants in which the GPS position is taken, in the deactivation the moment in which the device is turned off.
** Existence of temporary limitations in the generation of tokens for authentication.** It is currently 1 day.
Clarify how the “actionId” parameter should be constructed.
It must be a unique identifier for the life of the incident that is reported from the device and for that idcompany. The mechanism is left free to developers.
Clarify what values the “device_event_type” parameter can acquire (if it is only one, it would be the same case as the “speed” parameter).
In this case it is 1 – Vehicle stopped. We wanted to keep this attribute for future compatibility.
Clarify if the platform manufacturer should implement a message forwarding policy in case the DGT3.0 platform temporarily stops providing service.
A forwarding policy has not been contemplated as the platform itself has a message retention policy based on risk.