|
|
Este caso de uso responde a la necesidad de cumplimentar lo regulado en la Instrucción 18/ V- 132 de la DGT y en el [RD 159/2021, de 16 de marzo, por el que se regulan los servicios de auxilio en las vías públicas](https://www.boe.es/boe/dias/2021/03/17/pdfs/BOE-A-2021-4194.pdf), en el que se obliga a los nuevos dispositivos de la señal V-16, a enviar un mensaje a la plaraforma DGT3.0. Se detalla por tanto, la comunicación entre la nube del fabricante de estos dispositivos y la plataforma DGT3.0
|
|
|
|
|
|
Así mismo, las empresas que esten interesadas en consumir esta información podrán hacerlo con la siguiente [documentación](https://gitlab.cs.cmobility30.es/dgt3.0_esp/caso-de-uso-4).
|
|
|
|
|
|
|
|
|
Todas las peticiones que se realicen a la API deben ser enviadas a la
|
|
|
siguiente URL (URL base):
|
|
|
|
|
|
> https://pre.cmobility30.es/v16/
|
|
|
|
|
|
## Publicación
|
|
|
|
|
|
Para **publicar** información se dispone una API REST:
|
|
|
|
|
|
### Identificación en el servicio
|
|
|
|
|
|
Para llevar a cabo las operaciones del API es necesario obtener un token de sesión que caducará de forma aleatoria a lo largo de la misma. La operación de identifiación está descrita en la [siguiente documentación](publicacion/identificacion)
|
|
|
|
|
|
- Los detalles de las tablas maestras y datos que pueden componer el evento:
|
|
|
|
|
|
> [Tablas Maestras](publicacion/Tablas-Maestras)
|
|
|
|
|
|
- Información relativa al evento que se debe enviar:
|
|
|
|
|
|
> [Evento](publicacion/Evento)
|
|
|
|
|
|
# FAQs
|
|
|
|
|
|
## Protocolo A
|
|
|
|
|
|
**Confirmación de que el microservicio que recibirá los datagramas UDP de las balizas cuando se utilice la conexión de backup implementará un mecanismo de “acuse de recibo” tal y como se describe en el BOE.**
|
|
|
|
|
|
El BOE indica que “El protocolo incluirá un paquete UDP de respuesta (acuse de recibo) por parte del
|
|
|
operador de telefonía, que el fabricante podrá utilizar e efectos de control de llegada del
|
|
|
paquete, ya que el protocolo UDP no dispone de esta característica.” Esto salió en algunas reuniones con los Operadores. Desde la plataforma lo que haremos será publicar los mensajes a través de la bandeja de salida.
|
|
|
|
|
|
**Aclarar el significado de los tres tipos de trama (campo “Tipo trama”) del protocolo A y resolver incoherencia entre el BOE y la Wiki para tipo de trama 0 (¿“Inicio de incidencia” o “Reporte de batería”?).**
|
|
|
|
|
|
0 indica que se ha encendido el dispositivo y comienza a tenerse en cuenta la incidencia. 1 indica que el dispositivo continúa encendido. 3 indica que se ha apagado el dispositivo, y desde ese momento no se considerará un riesgo.
|
|
|
|
|
|
## Protocolo B
|
|
|
|
|
|
**Aclarar mapeo entre Tipo de trama del protocolo A, y el campo device_event_type_value” del mensaje del protocolo B.**
|
|
|
|
|
|
Protocolo A | Protoloco B | Significado
|
|
|
--|--|--
|
|
|
0|1| Inicio
|
|
|
1|2| Continúa incidencia
|
|
|
2|3| Fin
|
|
|
|
|
|
**Aclarar qué timestamp debe colocarse en el parámetro “detection_time” (¿el del primer mensaje enviado por la baliza o el momento de la recepción de ese mensaje en la plataforma?).**
|
|
|
|
|
|
Es el instante en el que ocurre el evento que se reporta. En la activación, el inicio, durante la incidencia cada uno de los instantes en los que se toma la posición del GPS, en la desactivación el momento en que se apaga el dispositivo.
|
|
|
|
|
|
**Existencia de limitaciones temporales en la generación de tokens para la autenticación.**
|
|
|
Actualmente es de 1 día.
|
|
|
|
|
|
**Aclarar cómo debe construirse el parámetro “actionId”.**
|
|
|
|
|
|
Debe ser un identificador único para toda la vida de la incidencia que se reporta desde el dispositivo y para esa idcompany. El mecanismo se deja libre a los desarrolladores.
|
|
|
|
|
|
**Aclarar qué valores puede adquirir el parámetro “device_event_type” (si solo es uno, sería el mismo caso que el parámetro “speed”).**
|
|
|
|
|
|
En este caso es 1 – Vehículo detenido. Hemos querido mantener este atributo por compatibilidad en un futuro.
|
|
|
|
|
|
**Aclarar si la plataforma del fabricante debe implementar una política de reenvíos de mensajes en caso de que la plataforma DGT3.0 deje de prestar servicio temporalmente.**
|
|
|
|
|
|
No se ha contemplado una política de reenvíos al tenerse en la propia plataforma uun política de retención de los mensajes en función de su riesgo. |
|
|
El evento es la parte principal de esta API de ingesta de datos. En este elemento es donde se va a enviar a la plataforma la información del evento generado por cada uno de los dispositivos en tiempo real.
|
|
|
|
|
|
- Method: POST
|
|
|
|
|
|
- URL: {baseUrl}/v1/**postincidence**
|
|
|
|
|
|
- Body:
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"actionid": "1",
|
|
|
"detection_time": "2020-02-24T07:17:27Z",
|
|
|
"lon": -3.5 ,
|
|
|
"lat": 40.5,
|
|
|
"device_event_type": 1,
|
|
|
"device_event_type_value": 1,
|
|
|
"information_quality": 1
|
|
|
}
|
|
|
```
|
|
|
|
|
|
Atributo| Significado
|
|
|
|--|--|
|
|
|
idcompany | Common Name del certificado de cliente
|
|
|
actionid | Identificador único del evento anonimizando al dispositivo de origen,desde la activación a la desactivación
|
|
|
token | Token generado para plataforma cliente durante la autenticación
|
|
|
detection_time| Timestamp del instante en el que ocurre el evento, en formato ISO 8601 YYYY-MM-DDTHH:MM:SSZ
|
|
|
lon | Longitud geográfica del evento en coordenadas WGS84
|
|
|
Lat | Latitud geográfica del evento en coordenada WGS84
|
|
|
device_event_type | Tipo de evento con la plataforma 1 – Vehículo detenido
|
|
|
device_event_type_value | Valor del tipo de evento. 1 – activación; 2 – activado; 3 - desactivación
|
|
|
information_quality| Precisión GPS estimada en metros
|
|
|
|
|
|
|
|
|
## Obtención del id de empresa
|
|
|
|
|
|
- Method: GET
|
|
|
|
|
|
- URL: {baseUrl}/v1/**idcompany**
|
|
|
|
|
|
- Body:
|
|
|
|
|
|
```json
|
|
|
{
|
|
|
"info_code": 0,
|
|
|
"info_desc": "",
|
|
|
"data": [
|
|
|
{
|
|
|
"idEmpresa": 38
|
|
|
}
|
|
|
]
|
|
|
}
|
|
|
``` |
|
|
\ No newline at end of file |