Cool Routing - Itene · 2018-03-12 · Tabla 2. Listado de requerimientos técnicos. #4.SmartPhone....

PROGRAMA DE PROYECTOS DE I+D EN

COLABORACIÓN

Cool Routing

Plataforma de optimización de cálculo de rutas de reparto para vehículos eléctricos con carga refrigerada

E2.3. App del conductor

ITE

E2.3. App del Conductor

Página 2 de 27

Información del documento

Titulo App del conductor

Creador Caterina Tormo (ITE)

Description Describe el diseño y el desarrollo realizado para crear la vesrión al-fa de la App del conductor

Autores Caterina Tormo(ITE)

Participantes Caterina Tormo(ITE)

Entidad responsable ITE

Nivel de difusión Interno

Publico

Restringido

Fecha de entrega 30/03/17


Página 3 de 27

Revisión

Version Fecha Modificacdo por Comentarios

v0.0 14/02/17 Caterina Tormo (ITE) Crear la estructura del en-tregable

v0.1 28/02/17 Caterina Tormo (ITE) Completar los apartados 3 y 4.

v0.3 15/03/17 Caterina Tormo (ITE) Completar apartado 4 y 5.

v0.4 31/03/17 Caterina Tormo (ITE) Generar versión final.

v0.5 11/05/17 Caterina Tormo (ITE) Documentar los casos de test de las pruebas integra-das.

vF 15/05/17 Caterina Tormo (ITE) Generar versión final


Página 4 de 27

Tabla de contenidos

Tabla de contenidos ...........................................................................................................................................4

Índice de Figuras ................................................................................................................................................5

Índice de Tablas .................................................................................................................................................6

1 Términos y abreviaciones ...........................................................................................................................7

2 Sumario .......................................................................................................................................................8

3 Introducción .................................................................................................................................................9

4 SmartPhone App ...................................................................................................................................... 10

4.1 Analisis de los casos de uso ............................................................................................................. 10

4.2 Arquitectura ....................................................................................................................................... 11

4.3 Analisis de los requerimientos técnicos ............................................................................................ 12

4.4 Diseño de la interfaz de usuario ....................................................................................................... 12

4.5 Tests funcionales .............................................................................................................................. 14

5 Conclusiones ............................................................................................................................................ 27


Página 5 de 27

Índice de Figuras

No se encuentran elementos de tabla de ilustraciones.


Página 6 de 27

Índice de Tablas

Tabla 7: Listado de requerimientos técnicos. #4.SmartPhone. ....................................................................... 12


Página 7 de 27

1 Términos y abreviaciones

Acrónimo Definición

BLE Bluetooth Low Energy


Página 8 de 27

2 Sumario

El entregable explica el desarrollo tecnólogico que se ha seguido para tener una aplicación móvil ple-namente funcional.

El entregable se divide en las siguientes secciones:

• Analisis de los casos de uso.

• Arquitectura seleccionada.

• Analisis de los requerimientos técnicos.

• Diseño de la interfaz de usuario.

• Tests funcionales.


Página 9 de 27

3 Introducción

El objetivo general de Cool Routing es conseguir una mejora en el transporte de mercancía refrigerada empleando el vehículo eléctrico, a través del desarrollo y validación de las tecnologías necesarias para la implementación de una plataforma de cálculo óptimo de rutas de reparto.

El proyecto propone 9 paquetes de trabajo a lo largo de 2 anualidades. El paquete de trabajo 2 será el encargado de definir la sensorización del vehículo. Este PT también engloba las comunicaciones con la plataforma de recogida de datos (PT3).

Figura 1. Plan de trabajo CoolRouting.

El objetivo del presente entregable es describir el diseño y desarrollo realizado para la App del conduc-tor, el componente 4 de la arquitectura de CoolRouting.


Página 10 de 27

4 SmartPhone App

El componente SmartPhone es una interfaz de usuario, pensada para el AI.2, usuario – conductor. En treminos generales, se trata de una aplicación móvil que ofrece la posibilidad de visualizar la ruta que se le asignado al vehículo en el que se encuentra el conductor, además cuenta con el envío de la posi-ción GPS y datos del vehículo en cada entrega. Las interfaces que interactúan con este componente son:

• Interfaz 3. Se trata de la comunicación entre el Smartphone y la Plataforma de Recogida de datos por GPRS. Los datos a intercambiar entre ambos componentes son, por un lado desde el smartphone a la plataforma de recogida de datos:

o Última actualización

o Posición GPS (latitud, longuitud y el error que genera el GPS)

o Datos propios del vehiculo a través del MA:

▪ Temperatura exterior

▪ % batería (SOC)

▪ Temperatura interior

▪ Temperatura del arcón

o Datos propios de la ruta

▪ Estado de los pedidos

▪ Identificador de la ruta y su estado

▪ Identificador del vehículo y su estado

• Interfaz 4. Comunicación entre el Smartphone y el Módulo de adquisición. La comunicación entre ambos componentes se establererá mediante Bluetooth Low Energy. Se ha seleccionado dicha tecnología por las necesidades de la propia comunicación, ya que para comunicar dispo-sitivos a corto alcance, sin cables, la tecnología Bluetooth es la mejor opción. La tecnología inalámbrica Bluetooth ofrece un coste bajo. Además todos los dispositivos Smartphone cuentan con la posibilidad de comunicarse a través de ella.

4.1 Analisis de los casos de uso

En base a los casos de uso definidos en E1.2. se ha realizado un análisis de los específicos del com-ponente 4.

Cuando los gestores (AI1) decidan realizar una planificación de ruta para su reparto de mercancía a través de CoolRouting, ésta se llevará a cabo a través de una interfaz amigable dónde introducir la in-formación para poder obtener las pautas necesarias para ejecutarlo.

INTERFACES

CÁLCULO DE RUTA

SERVICIOS EN RUTA SEGURIDAD

CUCR0100 Cálculo de

Ruta

CUSR0200 Servicios en Ruta

CUS0300 Seguridad

CUCR0101 UCSR0201 UCSR0202 UCS0301

I.1 PTCR PTCC X

X


Página 11 de 27

I.2 PTCR PTRD X X X

I.3 PTRD Smartpho-

ne X X X

I.4 Smartphon

e MA

X X

AI.1 Usuario Gestor

PTCR X

X

AI.2 Usuario

Conductor Smartphon

e X X X

Tabla 1. Interfaces vs Casos de Uso

En resumen, el componente SmartPhone App interviene en:

• Servicios en ruta. Tiene como objetivo principal dar soporte en tiempo real al ejecutor de las rutas, el conductor. El sistema ofrecerá la posibilidad de recálculo de ruta en dos casos, el primero cuando cuando el sistema detecte que no tiene suficiente SOC para llegar a su destino y el segundo a petición del propio conductor, por la existencia de alguna incidencia durante la ejecución de la ruta. Con lo que los casos de uso involucrados son CUSR0201 y CUSR0202. Optimización de la ruta.

• Seguridad. La identificación y autenticación se realizará mediante la introducción de la ma-tricula del vehículo.

4.2 Arquitectura

La arquitectura propuesta para el SmartPhone es un modelo piramidal. Por lo tanto, está estructurado como un formulario de aplicación de múltiples capas por elementos que están trabajando juntos en el mismo módulo. El módulo gestiona los datos desde la interfaz I.3 y I.4, trata toda la información y la re-presenta al usuario.

Figura 2. Arquitectura SmartPhone App

• Capa de datos

La capa de datos es el componente que proporciona los servicios disponibles que sostienen la estruc-tura de información. Se divide en dos partes:

o Componentes de acceso a datos. Estos componentes centralizan la funcionalidad de acceso a datos común para facilitar la configuración y el mantenimiento de la aplicación. Además hay algunas "utilidades" para ayudar en la manipulación de da-tos a "Data Access Components" que son definidos por "Data Utilities".

o Data Utilities. Funciones y métodos específicos para la manipulación de datos, transformación de datos y acceso a datos dentro de la capa.

• Capa de Presentación

La capa de presentación es entiende como la parte gráfica y se agrupa como los componentes de in-terfaz de usuario. Las pantallas de la aplicación son las encargadas de mostrar información al usuario y han sido diseñadas de acuerdo al análisis de casos de uso hecho en el apartado anterior y en base al E1.2.


Página 12 de 27

4.3 Analisis de los requerimientos técnicos

En cuanto a los requerimientos técnicos de la App, se trata e una aplicación móvil que podrá instalarse en dispositivos Android (5.0 o superior). La funcionalidad de la I.4. será soportada por los dispositivos que cuente con BLE.

Los objetivos de este componente son:

• Mostrar y enviar a la plataforma de recogida de datos la información proveniente del vehículo.

• Asegurar la integridad de los datos recogidos.

• Mostrar y obtener datos provenientes de la plataforma de recogida de datos. (Rutas, servicios en ruta…)

4.3.1 Listado de requerimientos técnicos

ReqID Requerimiento

RTC401 Software: Sistema operativo Android 5.0 o superior

RTC402 Conectividad: BLE

RTC403 Conectividad: Mín Red 3G (HSDPA)

Tabla 2. Listado de requerimientos técnicos. #4.SmartPhone.

4.4 Diseño de la interfaz de usuario

El diseño de la interfaz de usuario conductor esta basada en crear un medio eficaz y amigable de co-municación entre el conductor, la PTRD y el propio vehículo. Siguiendo un conjunto de principios de di-seño que identifican los objetos y las acciones para luego crear las plantillas que constituyen la base del propio interfaz de usuario. En base a todo lo descrito en apartados anteriores, se optó por una na-vehación de menú lateral.

La aplicación permitirá al usuario interactuar con la plataforma e informando si sucede alguna anomalía durante el reparto de las mercancías. Además, ofrecerá de manera rápida información útil al conductor como el teléfono del cliente, el enrutado a través del mapa…

En primer lugar el usuario deberá descargarse la aplicación. Una vez instalada, deberá de introducir la matricula del vehículo en el que se encuentra, en el que va a realizar el reparto de las mercancías.


Página 13 de 27

Figura 3.Pantalla de bienvenida CoolRouting

A continuación, el usuario pulsará continuar, aparecerá la pantalla principal de la aplicación, así como la ruta que el vehículo tiene asignada por el gestor de la plataforma.

Figura 4.Menu principal

Desde el menú el usuario podrá navegar y consultar la información que necesite. Por un lado la referente al vehículo y por otro el de la ruta asignada.

La información del vehiculo se distribuirá de la siguiente manera:


Página 14 de 27

Figura 5. Información de vehículo

La información útil para el usuario se ha basado en los requerimientos de usuarios definidos en el E1.2., con lo que se muestra por un lado la información del CANBUS y por otro la ubicación actal del mismo. Además, mediante petición el usuario podrá refrescar los parámetros del vehículo y visualizarlos por pantalla.

Por otro lado, la información referente a la ruta asignada se mostrará de la siguiente manera:

Figura 6.Pantalla inicio de ruta

El conductor notificará a la PTRD el inicio de la ruta. Con la finalidad de no relantizar en caso de que haya cualquier problema con la comunicación con el vehículo, la aplicación permitirá el inicio de la ruta aunque no haya comunicación con el MA.

4.5 Tests funcionales

Los tests individuales de la aplicación se han realizado en dos líneas diferenciadas, por una parte con la pla-taforma de recogida de datos y por otra con el modulo de adquisición. Acontinuacuión, se documentan los tests realizados.


Página 15 de 27

Test ID T01. Visualización de datos del MA.

Caso de Uso involucrado CUSR0201 Descarga de la ruta

Fecha 06/04/2017

Descripción del escenario

Se van a simular escenarios de test, se crea en el gestor unos pedidos y una ruta. La ruta se asigna al vehículo 1111-A.

El Módulo de adquisión es un prototipo inicial NO conectado a vehículo, con lo que los datos del VE son simulados para probar la comunicación entre MA y App.

Paso Acción Entrada Resulado GAP

01 Usuario introduce la matricula del vehículo. (1111-A)

Matricula del vehículo Se muestra la ruta asignada. -

02 Usuario intenta in-ciar ruta sin conec-tar con el MA

Actualiza el estado de la ruta. Inicio de la ruta.

Advertencia al usuario.

03 El usuario se co-necta al MA

Petición de conexión. La App se conecta al MA.

04 La App muestra los datos actualizdos del VE

Petición de actualiza-ción de datos

Actualización de los datos.

Observaciones

Evaluación/validación de los resultados

El test ha sido realizado correctamente.

Paso01:

Paso02:


Página 16 de 27

Test ID T01. Visualización de datos del MA.


Paso03 y Paso04:


Página 17 de 27

Test ID T02. Ruta no válida.


Fecha 07/04/2017





01 Usuario introduce la matricula del vehículo. (1111-A)


02 El usuario inicia trayecto con un SOC = 16.9%.

Inicio de trayecto Ruta no válida. La batería final es menor que 10%.

Observaciones



Paso01:

Paso02:


Página 18 de 27

Test ID T02. Ruta no válida.



Página 19 de 27

Test ID T03. Ruta realizada con éxito.


Fecha 07/04/2017




En este escenario se va a realizar una ruta completa con 4 pedidos, 1 en-tregado correctamente y los otros dos con error en la entrega.


01

Usuario introduce la matricula del vehículo. (1111-A). El gestor planificó la ruta con SOC= 100%


02 El usuario inicia trayecto con un SOC = 88.1%.

Actualiza el estado de la ruta. Inicio de la ruta.

Ok. Cambia el estado de la ruta.

03 Entrega pedido 1. Actualiza el estado del pedido

Ok. Se recalcula la estimación en base al SOC real en el momento de la entrega.

04 Entrega pedido 2. Error en la entrega

Actualiza el estado del pedido


05

Entrega pedido 3. Error en la entrega. Cliente no disponi-ble



06

Entrega pedido 4. Error en la entrega. Problema en la ru-ta



07 Fin de trayecto Actualiza el estado de la ruta. Fin de ruta.


Observaciones



Paso01 y Paso02:


Página 20 de 27




Página 21 de 27



Paso03, Paso04, Paso05 y Paso06:

Paso07:


Página 22 de 27




Página 23 de 27

Test ID T04. Ruta realizada con éxito. Sin comunicación con MA.


Fecha 07/04/2017



En este test se va a simular que la comunicación por BLE esta dañada.

En este escenario se va a realizar una ruta completa con 3 pedidos, 2 en-tregado correctamente y el último con error en entrega. El usuario se pondrá en contacto con el cliente, a través del telefeno facilitado.


01

Usuario introduce la matricula del vehículo. (1111-A). El gestor planificó la ruta con SOC= 100%


02

El usuario no pue-de conectar con el MA. Con lo que in-troduce los datos del display del vehiculo de mane-ra manual.

Introducir datos del ECU y mandarlos a la PTRD.

Ok. Los campos se actualizan co-rrectamente.

03 Inicio de ruta sin comunicación con MA.

Incio de ruta. Advertencia ante la falta de comu-nicación. Inicio de ruta ok. La ruta cambia de estado.

04 Entrega pedido 1. Entrega ok. El conductor introduce a mano los datos reales del SOC.


05

Entrega pedido 2.Error en la entre-ga. Cliente no dis-ponible. Conductor llama al cliente.

Error en la entrega. Cliente no disponible.

Ok. Se recalcula la estimación en base al SOC real en el momento de la entrega. Cambio el estado de l pedido.

06

Entrega pedido 3. Error en la entrega. Cliente no disponi-ble



07 Fin de trayecto Actualiza el estado de la ruta. Fin de ruta.


Observaciones



Paso01 y Paso02:


Página 24 de 27



Paso03:

Paso04:


Página 25 de 27



Paso05:

Paso06 y Paso07:


Página 26 de 27




Página 27 de 27

5 Conclusiones

En base a la arquitectura global del sistema el usuario conductor solo cuenta con una vía de comunicación para interactuar con CoolRouting, a través del Smartphone. Gracias al diseño realizado puede consultar la ruta asignada tanto dentro como fuera del vehículo.

El punto de partida para el diseño de la aplicación han sido tanto los requerimientos técnicos como las ne-cesidades del usuario listadas en el E1.2.

Date post:	04-Jul-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Cool Routing - Itene · 2018-03-12 · Tabla 2. Listado de requerimientos técnicos. #4.SmartPhone....

Documents