Home - dgt30-eng/Use-case-1 GitHub Wiki
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:
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.
| Protocol A | Protocol B | Meaning |
|---|---|---|
| 0 | 1 | Start |
| 1 | 2 | Incident continues |
| 23 | The end |
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.
- Apply to [email protected] and obtain the manufacturer's connection certificate to the platform.
- Request connectivity via APN from the Operator corresponding to the platform.
- Apply to [email protected] a date for testing.
On the agreed test date the process will be as follows::
Protocol A
- The Telephone Operator will
- Verify that there is connectivity from the beacon to be tested to the APN corresponding to the manufacturer.
- Will route messages from the beacon to the platform's network.
- The manufacturer shall switch on the beacon by sending the messages described in the documentation. Messages of the 3 specified states shall be generated.
- The platform shall check
- That they arrive at the message ingest service of the back-up service.
- That the frame format corresponds to what is specified in the documentation.
- That it is possible to send the received frame to the publishing service.
- That the generated messages are correctly received in the V16 protocol B receiving service.
- That the messages are correctly published.
- That the events are not older than 15 seconds.
- That the events do not have a future time.
Protocol B
- The Telephony Operator shall route the messages from the beacon to the manufacturer's network.
- The manufacturer shall switch on the beacon by sending the messages described in the documentation. Messages of the 3 specified states shall be generated.
- The platform shall check
- That the generated messages are correctly received in the V16 protocol B receiving service.
- That the messages are correctly published.
- That the events have a maximum age of 15 seconds.
- That the events do not have a future time.