Caso de Uso 1
Señal V 16
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, 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
Todas las peticiones que se realicen a la API deben ser enviadas a la siguiente URL (URL base):
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
- Los detalles de las tablas maestras y datos que pueden componer el evento:
- Información relativa al evento que se debe enviar:
FAQs
Protocolo A
¿Dónde puedo obtener el id de empresa para la conexión?
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.
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.
Guía para las pruebas de protocolos A y B
Fase administrativa
- Solicitar a soporte@cmobility30.es y obtener el certificado de conexión del fabricante a la plataforma.
- Solicitar conectividad vía APN del Operador correspondiente a la plataforma.
- Solicitar a soporte@cmobility30.es fecha para realizar las pruebas.
Fase de pruebas
En la fecha concertada para las pruebas el proceso será el siguiente:
Protocolo A
- El Operador de telefonía
- Verificará que existe conectividad desde la baliza a probar al APN correspondiente al fabricante.
- Enrutará los mensajes procedentes de la baliza hasta la red de la plataforma.
- El fabricante encenderá la baliza enviando los mensajes descritos en la documentación. Se deberán generar mensajes de los 3 estados especificados.
- La plataforma comprobará
- Que llegan al servicio de ingesta de mensajes del servicio de respaldo.
- Que el formato de la trama corresponde con lo especificado en la documentación.
- Que es posible enviar la trama recibida al servicio de publicación.
- Que los mensajes generados son recibidos correctamente en el servicio de recepción de V16 protocolo B.
- Que los mensajes sean publicados correctamente.
Protocolo B
- El Operador de telefonía enrutará los mensajes procedentes de la baliza hasta la red del fabricante.
- El fabricante encenderá la baliza enviando los mensajes descritos en la documentación. Se deberán generar mensajes de los 3 estados especificados.
- La plataforma comprobará
- Que los mensajes generados son recibidos correctamente en el servicio de recepción de V16 protocolo B.
- Que los mensajes sean publicados correctamente.