28
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.2. Prototipo del Módulo de Adquisición ITENE

Cool Routing - itene.com€¦ · pone de dos vehículos eléctricos, una Renault Kangoo Z.E. y una Nissan e-NV200, ... sobre un esquema teórico de los interiores de los dos vehículos,

  • Upload
    dothuan

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

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.2. Prototipo del Módulo de Adquisición

ITENE

E2.2. Prototipo del Módulo de Adquisición

Página 2 de 28

Información del documento

Titulo Prototipo del Módulo de Adquisición

Creador ITENE (Coordinador)

ITE

Description Describe la arquitectura usada para el módulo de adquisición y los componentes utilizados.

Autores Miguel Ángel Alférez Moreno (ITENE)

Rubén Ponce Tortajada (ITENE)

Entidad responsable ITENE

Nivel de difusión Interno

Publico

Restringido

Fecha de entrega

E2.2. Prototipo del Módulo de Adquisición

Página 3 de 28

Revisión

Version Fecha Modificado por Comentarios

v0.0 11/10/2016 Miguel Ángel Alférez Moreno Versión inicial plantilla

v0.1 22/11/2016 Rubén Ponce Tortajada Ampliación de información

v0.2 02/12/2016 José Ángel Rodríguez Álvaro

Miguel Ángel Alférez Moreno

Revisión y comentarios

v0.3 15/12/2016 Caterina Tormo Domènech Revisión y comentarios

v0.4 05/05/2017 Miguel Ángel Alférez Moreno Ampliación de información

v0.5 11/05/2017 Caterina Tormo Domènech Revisión y comentarios. Adaptación de los casos de test a las plantillas del pro-yecto.

E2.2. Prototipo del Módulo de Adquisición

Página 4 de 28

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

3.1 Analisis de los casos de uso ............................................................................................................. 10

4 Proceso de selección del vehículo a monitorizar ..................................................................................... 12

5 Componentes Hardware .......................................................................................................................... 19

5.1 Sensorización de la Temperatura ..................................................................................................... 19

5.2 Microcontrolador ............................................................................................................................... 19

5.3 Interfaz con el vehículo ..................................................................................................................... 19

6 Diseño Hardware ...................................................................................................................................... 20

7 Tests. Pruebas de Campo........................................................................................................................ 21

7.1 Interpretación de los datos ................................................................................................................ 27

8 Diseño Firmware ...................................................................................................................................... 28

E2.2. Prototipo del Módulo de Adquisición

Página 5 de 28

Índice de Figuras

Figura 1. Plan de trabajo Cool Routing ..............................................................................................................9

Figura 2. Diagrama de E/S del MA .................................................................................................................. 10

Figura 3. Fotografía de una Nissan e-NV200 .................................................................................................. 12

Figura 4. Fotografía de una Renault Kangoo Z.E. .......................................................................................... 13

Figura 5. Planos de la unidad de carga logística del socio-usuario ................................................................ 14

Figura 6. Modelos de arcones refrigerados ..................................................................................................... 14

Figura 7. Detalle de la connexion de alimentación del arcón .......................................................................... 15

Figura 8. Fotografías del arcón seleccionado ................................................................................................. 15

Figura 9. Posible distribución de la carga en el interior de una Renault Kangoo Z.E. .................................... 16

Figura 10. Posible distribución de la carga en el interior de una Nissan e-NV200 ......................................... 16

Figura 11. Fotografías de la problemática comentada con anterioridad ......................................................... 17

Figura 12. Fotografías de la distribución de la carga en la Nissan e-NV200 .................................................. 17

Figura 13. Modelo 3D de la Nissan e-NV200 mostrando como se distribuiría la carga ................................. 18

Figura 14. Diagrama de los componentes del Hardware ................................................................................ 20

Figura 15. Grafica de las lecturas del SOC ..................................................................................................... 26

Figura 16. Evolución del SOC en base al tiempo............................................................................................ 26

Figura 17. Diagrama de flujo del Firmware ..................................................................................................... 28

E2.2. Prototipo del Módulo de Adquisición

Página 6 de 28

Índice de Tablas

Tabla 1. Interfaces vs Casos de Uso .............................................................................................................. 10

Tabla 2. Evolución del SOC durante una ruta de 25 min. ............................................................................... 24

E2.2. Prototipo del Módulo de Adquisición

Página 7 de 28

1 Términos y abreviaciones

Acrónimo Definición

App Aplicación móvil

BLE Bluetooth Low Energy

CAN Controller Area Network

CPU Central Processing Unit

E/S Entradas y Salidas

ECU Engine Control Unit

MA Módulo de Adquisición

OBD On Board Diagnostic

PCB Printed Circuit Board

PSoC Programmable System on Chip

RAM Random Access Memory

ROM Read Only Memory

RTD Resistance Temperature Detector

uC Microcontrolador

E2.2. Prototipo del Módulo de Adquisición

Página 8 de 28

2 Sumario

El entregable explica el desarrollo tecnólogico que se ha seguido para tener un módulo de adquisición de datos plenamente funcional. Se explicará en detalle los componentes Hardware que se han usado, asi como la arquitectura por la que se ha optado.

El entregable se divide en las siguientes secciones:

• Proceso de selección del vehiculo a monitorizar: Análisis de diversos factores (capacidad de carga de cada vehiculo, acuerdos de colaboración, etc) que influyen en la elección del vehiculo que se utilizará finalmente, así como el equipo de refrigeración escogido.

• Componentes Hardware: Análisis de cada componente hardware, y se explica el porqué se ha elegido cada uno de ellos.

• Pruebas de Campo: Pruebas realizadas en el vehiculo para confirmar el correcto funcionamien-to del Hardware.

• Diseño Hardware: Los esquemáticos del MA.

• Diseño Firmware: Descripción del software utilizado para la programación del módulo.

Con estas secciones se obtendrá una visión global del módulo de adquisición y sus componentes.

E2.2. Prototipo del Módulo de Adquisición

Página 9 de 28

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 la sensorización y extracción de datos del CAN Bus del vehículo. Estos datos serán com-partidos con el resto de paquetes de trabajo del proyecto para su uso en el cálculo de rutas y consu-mos.

Figura 1. Plan de trabajo Cool Routing

El presente entregable muestra los resultados del Paquete de trabajo 2. Sensorización del vehículo, la tarea se centra en desarrollar un módulo de adquisición capaz de recoger los datos de estado de carga de la batería y temperatura exterior provenientes del CAN Bus del vehículo, y además digitalizar los da-tos de los dos sensores de temperatura, uno en el arcón refrigerador y otro en el habitáculo donde este se encuentra. Una vez obtenidos estos datos se enviarán mediante comunicación Bluetooth al Smartp-hone con el cual se haya enlazado.

E2.2. Prototipo del Módulo de Adquisición

Página 10 de 28

Figura 2. Diagrama de E/S del MA

3.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

I.2 PTCR PTRD X X X

I.3 PTRD Smartphone X X X

I.4 Smartphone MA X X

AI.1

Usuario

Gestor

PTCR X X

AI.2

Usuario

Conductor

Smartphone X X X

Tabla 1. Interfaces vs Casos de Uso

En resumen, el componente MA interviene únicamente en Servicios en ruta. El cual tiene como objeti-vo principal dar soporte en tiempo real al ejecutor de las rutas, el conductor. El sistema ofrecerá la po-sibilidad 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

E2.2. Prototipo del Módulo de Adquisición

Página 11 de 28

durante la ejecución de la ruta. Con lo que los casos de uso involucrados son CUSR0201 y CUSR0202. Op-timización de la ruta.

E2.2. Prototipo del Módulo de Adquisición

Página 12 de 28

4 Proceso de selección del vehículo a monitorizar

El objetivo de esta sección es describir los factores que se han debido de tener en cuenta para final-mente escoger entre un vehiculo u otro.

Dado el acuerdo de colaboración con Renault en este proyecto y que uno de los integrantes del pro-yecto cuenta en su flota con vehículos eléctricos del grupo Renault, se va a centrar en estos la selec-ción del vehículo a monitorizar. Este vehículo además será el que deba emplearse cuando se realicen las pruebas de campo. El encargado de realizar estas pruebas será el socio SD Logistica, el cual dis-pone de dos vehículos eléctricos, una Renault Kangoo Z.E. y una Nissan e-NV200, ambos pertenecien-tes al grupo industrial Renault.

Figura 3. Fotografía de una Nissan e-NV200

E2.2. Prototipo del Módulo de Adquisición

Página 13 de 28

Figura 4. Fotografía de una Renault Kangoo Z.E.

El espíritu del proyecto es la optimización de las rutas de reparto por dos motivos, mantener la cadena del frío y optimizar la ruta de reparto en base a los criterios seleccionados. Las flotas de vehiculo indus-trial puramente eléctricas son muy novedosas, reducidas y la mayoría son de renting, por lo que el vehículo no puede ser modificado si no es mediante el pago de una sanción a la empresa que lo alqui-la. La solución pasa por colocar un sistema que mantenga el frío sin necesidad de modificar el vehícu-lo. Por este motivo se han buscado arcones refrigerados adaptados a los vehículos industriales. De los diferentes modelos que han sido sopesados, se ha escogido reducir el alcance del arcón a productos refrigerados en lugar de congelados, puesto que habría un alto riesgo de que se descargara totalmente la batería del vehículo y no poder acabar el recorrido, debido a su mayor consumo energético.

Se han estudiado dos tamaños de arcón, el primero de aproximadamente 300 litros de capacidad y el segundo de unos 150l. Tras la revisión del histórico de pedidos del socio que aporta el vehículo al pro-yecto se ha decidido emplear el arcón de menor volumen, debido a que el de mayor volumen reduce en exceso la capacidad de carga del producto no refrigerado. La unidad de carga logística del socio-usuario es una caja de plástico con asa de 390mm de altura, 400mm de ancho y 600mm de profundi-dad. A plena carga, sobre un esquema teórico de los interiores de los dos vehículos, supone que la Renault Kangoo Z.E. puede transportar 18 unidades y la Nissan e-NV200 puede transportar 21 unida-des.

E2.2. Prototipo del Módulo de Adquisición

Página 14 de 28

Figura 5. Planos de la unidad de carga logística del socio-usuario

Al tratar con un tipo de vehículo muy novedoso se abren nuevas cuestiones para adecuar la nevera al proyecto. La alimentación del arcón será provista directamente por la batería del vehículo. La proble-mática viene dada en que los vehículos eléctricos cuentan con baterías que alimentan el motor, pero las tensiones de alimentación no son las tradicionales de 12 o 24 voltios.

Tras las primeras pesquisas se confirmó que estos dos vehículos eléctricos cuentan con dos baterías, una que alimenta el motor, que según el modelo tiene una tensión nominal entre 350V y 240V, y ade-más una batería de servicio de 12V que alimenta el resto de elementos del vehículo, luces, aire acon-dicionado, etc.

Figura 6. Modelos de arcones refrigerados

Tras la valoración de diferentes modelos de arcones refrigerados presentes en el mercado, se ha se-leccionado el arcón marca Euroengel, modelo F0104NDN de 140l de capacidad, que tiene un menor consumo que el modelo de más de 300l. Además, el modelo de 300l ocupa más de un tercio del volu-men útil de transporte y, sin embargo, la cubicación interior únicamente permite la colocación de una unidad de carga logística. Por otro lado, dentro de los modelos de aproximadamente 150l, se han se-leccionado los modelos de carga lateral ya que permiten su apertura sin necesidad de anular el espacio

E2.2. Prototipo del Módulo de Adquisición

Página 15 de 28

de carga existente sobre ellos, o sin tener que retirar las unidades de carga colocadas encima cada vez que se quiera retirar producto de su interior.

El arcón seleccionado es adecuado para la aplicación del proyecto porque se puede alimentar a la ten-sión de la batería de servicio del coche eléctrico, además cuenta con un relé de protección que no permite que arranque el arcón en el caso que la batería de 12V esté baja. Este arcón permite una ali-mentación eléctrica mixta, de tal manera que se puede enchufar a la red eléctrica o se puede enchufar a la batería. Poder enchufarlo a la red eléctrica permite pre-acondicionar el arcón antes del reparto pa-ra que esté a la temperatura adecuada y realizar un reparto más eficiente.

Figura 7. Detalle de la connexion de alimentación del arcón

Uno de los puntos fuertes de los vehículos eléctricos es la ecología, pero hay un elemento importante que no se valora a simple vista, y es que el vehículo ha de ser eficiente desde un punto de vista ener-gético. Con tal objetivo, los vehículos eléctricos recuperan parte de la energía que en otros vehículos se disipa al frenar, convirtiéndola de nuevo en energía eléctrica. La duda es, si parte de esa energía de recuperación es la que realimenta a la batería de 12V o esta batería se alimenta de un convertidor de potencia conectado a la batería del motor. Independientemente de este aspecto, el arcón ha sido se-leccionado, además, por contar con un relé de protección que detiene el funcionamiento del arcón en el supuesto de tener la batería de 12V con poca carga.

Figura 8. Fotografías del arcón seleccionado

Uno de los criterios que se va a emplear es el acuerdo con el socio-usuario del vehículo, el cúal consis-te en seleccionar el que sea más parecido a las condiciones de reparto real.

E2.2. Prototipo del Módulo de Adquisición

Página 16 de 28

Figura 9. Posible distribución de la carga en el interior de una Renault Kangoo Z.E.

Al incorporar el arcón de menor volumen, el de 140l, en el interior de la Kangoo, la carga útil pasa de 18 unidades de carga a 12, y muy posiblemente quedara en 9 unidades, ya que las tres unidades si-tuadas encima del arcón no tendrían una colocación funcional. El uso del arcón reduce su capacidad de carga entre un 33 y un 50%.

Figura 10. Posible distribución de la carga en el interior de una Nissan e-NV200

En el caso de la Nissan e-NV200, el volumen de carga pasa de 21 unidades a 16. Esto hace que la ca-pacidad de carga mengüe en un 24%.

Según la información aportada por la empresa, el reparto típico está formado por 4-5 unidades de car-ga. Esto supone que en el caso de la Kangoo pasa de una capacidad de 4 repartos por salida a 1-2 re-partos típicos por salida, y para la Nissan pasa de 4-5 repartos por salida a 3-4 repartos típicos.

Tras realizar pruebas de configuración de carga, para verificar que los diseños teóricos coincidían con la realidad, se descubrió que la puerta del arcón seleccionado tropezaba con el marco de la puerta en el caso de la Kangoo. Para salvar este inconveniente, es necesario elevar el arcón eliminando la posi-bilidad de colocar carga encima del arcón y reduciendo la capacidad de carga definitivamente a 9 uni-dades.

E2.2. Prototipo del Módulo de Adquisición

Página 17 de 28

Figura 11. Fotografías de la problemática comentada con anterioridad

Tras valorar las opciones y verificar la distribución de carga se ha tomado la decisión de monitorizar el vehículo Nissan debido a que es el que permite reproducir un entorno de distribución más próximo a la realidad.

Figura 12. Fotografías de la distribución de la carga en la Nissan e-NV200

E2.2. Prototipo del Módulo de Adquisición

Página 18 de 28

Figura 13. Modelo 3D de la Nissan e-NV200 mostrando como se distribuiría la carga

E2.2. Prototipo del Módulo de Adquisición

Página 19 de 28

5 Componentes Hardware

El objetivo de esta sección es analizar cada componente hardware que se necesita para el desarrollo y explicar porque se ha optado por los que finalmente se han utilizado.

5.1 Sensorización de la Temperatura

En esta subsección se tratará la sensorización de la temperatura del arcón refrigerador y del habitáculo donde éste se encuentra, ya que la temperatura exterior se obtiene a través del CAN Bus del vehículo por lo que se abordará en la subsección de Interfaz con el vehículo.

Para poder obtener la temperatura existen varias posibilidades en el mercado. Por una parte, los detec-tores de temperatura resistivos (Termistor, RTD), es decir, cambia su resistencia en función de la tem-peratura. Debido a ello, para poder obtener la temperatura e interpretarla, se debe de hacer un circuito de acondicionamiento cuyo voltaje de salida varía en función de la temperatura. Por otra parte, existen también unos circuitos integrados, los cuales proporcionan directamente un voltaje de salida proporcio-nal a la temperatura. Debido a la facilidad de estos últimos y que en términos de precisión y linealidad se comportan prácticamente igual, se ha optado por usar como sensor de temperatura uno de estos circuitos integrados.

5.2 Microcontrolador

El microcontrolador es un circuito integrado programable, en el cual se graba una serie de ordenes en su memoria para que las ejecute. Contiene en su interior una CPU, unidades de memoria (RAM y ROM), puertos de E/S y perífericos. Para esta aplicación se ha decido usar que contiene los tres tipos de bloques que se necesitan para esta aplicación:

• Un conversor analógico-digital para digitalizar los voltajes que los sensores de temperatura devuelven.

• Bloques de comunicación puerto serie para conectarse con la interfaz con el vehículo.

• Bloque de comunicación Bluetooth para enviar los datos a la aplicación Android.

5.3 Interfaz con el vehículo

Para este fin se utilizará un interpretador multi-protocolo. Se conectará a la consola central del vehículo a través del conector OBD-II, y a través del protocolo CAN pedirá una trama de datos que será enviada al microcontrolado mediante una comunicación puerto serie. Dentro de esa trama de datos se indentifi-cará el estado de carga de la batería y la temperatura ambiente. Una vez identificados, se actualizarán los valores para que sean leídos por la App

E2.2. Prototipo del Módulo de Adquisición

Página 20 de 28

6 Diseño Hardware

Figura 14. Diagrama de los componentes del Hardware

En el diseño final del hardware se ha optado por utilizar dos interpretes, debido a que la Nissan e-NV200 utiliza tres comunicaciones CAN simultáneamente, pero sólo dos de ellos pueden contener in-formación de interés para el proyecto. El microcontrolador por tanto deberá disponer de dos comunica-ciones puerto serie para poder recibir información de ambos. Tambien dispone de LED’s de notificación para que el usuario pueda saber si la App y el MA están conectados, enviando información o desco-nectado.

E2.2. Prototipo del Módulo de Adquisición

Página 21 de 28

7 Tests. Pruebas de Campo

En este apartado se analizarán y se mostrarán los resultados obtenidos en las pruebas de campo reali-zadas en la Nissan e-NV200 en dos días diferentes (Test01 y Test02). El último test, se realizó durante 5 días. (Test03)

Test ID 01

Caso de Uso involucrado CUSR0201 Descarga de la ruta

Fecha 16/11/2016

Descripción del escenario

Las pruebas se realizaron un día soleado, con una temperatura aproxi-mada de 20ºC. Las pruebas se realizaron en las instalaciones de FRIGICOLL.

El SOC del vehículo era aproximadamente de un 50-60%. Las pruebas se realizaron con el vehículo parado, la puerta del copiloto y el portón tra-sero abierto. El vehículo estuvo encendido durante todas las pruebas rea-lizadas para poder acceder al ECU (Unidad de Control de Motor) median-te una conexión OBD-II.

Paso Acción Entrada Resulado GAP

01 Lectura a petición

OBD-II

R: #CR7BB 8 10 C6 61 02 0F 64 0F 64 #CR#CR>

-

02 Lectura trama

completa OBD-II

R: #CR002 5 1A 00 00 07 7B #CR174 8 00 00 00 AA 05 00 00 00 #CR176 7 00 00 00 00 00 00 05 #CR180 8 00 00 00 00 00 00 25 00 #CR1D5 5 00 00 00 01 D7 #CR260 4 C8 C8 7D 00 <DATA ERROR#CR421 3 08 00 40 <DATA ERROR#CR358 8 00 0A 80 00 00 00 00 00 #CR280 8 03 00 00 00 00 00 00 00 #CR2DE 8 00 00 00 00 00 00 02 B2 #CR60D 8 D8 06 00 00 00 00 00 00 <DATA ERROR#CR1CF 8 FF 33 FF FE 08 00 28 2F <DATA ERROR#CR284 8 00 00 00 00 00 00 8F 15 #CR285 8 00 00 00 00 00 00 8F 16 #CR286 5 00 C0 00 00 00 #CR1CB 7 00 00 00 00 60 00 11 #CR1C6 8 7F FF FF FE 72 29 00 DD <DATA ERROR#CR215 6 FF F0 FF 00 FF FF <DATA ERROR#CR216 2 42 64 <DATA ERROR#CR300 1 00

#CR002 5 1A 00 00 07 0C #CR50A 8 04 90 00 16 00 21 04 00 #CR174

E2.2. Prototipo del Módulo de Adquisición

Página 22 de 28

Test ID 01

Caso de Uso involucrado CUSR0201 Descarga de la ruta

8 00 00 00 AA 06 00 00 00 #CR176 7 00 00 00 00 00 00 06 #CR180 8 00 00 00 00 00 00 26 00 #CR1D5 5 00 00 00 02 D8 #CR2DE 8 00 00 00 00 00 00 02 B2 #CR1CF 8 FF 33 FF FE 08 00 29 30 <DATA ERROR#CR245 8 7F E8 02 18 00 00 7F E0 <DATA ERROR#CR292 8 80 C8 06 7F D0 00 13 00 <DATA ERROR#CR354 8 00 00 00 00 00 00 04 00 #CR1CB 7 00 00 00 00 60 01 94 #CR1C6 8 7F FF FF FE 72 29 01 DE <DATA ERROR

#CR002 5 1A 00 00 07 1D #CR174 8 00 00 00 AA 07 00 00 00 #CR176 7 00 00 00 00 00 00 07 #CR180 8 00 00 00 00 00 00 27 00 #CR1D5 5 00 00 00 03 D9 #CR260 4 C8 C8 7D 00 <DATA ERROR#CR50D 8 34 00 00 00 00 80 00 00 <DATA ERROR#CR510 8 19 00 00 00 00 00 00 73 #CR280 8 03 00 00 00 00 00 00 00 #CR2DE 8 00 00 00 00 00 00 02 B2 #CR351 8 00 00 00 00 00 02 42 02 #CR1CF 8 FF 33 FF FE 08 00 2A 31 <DATA ERROR#CR284 8 00 00 00 00 00 00 90 16 #CR285 8 00 00 00 00 00 00 90 17 #CR286 5 00 00 00 00 00 #CR355 8 00 00 00 00 00 00 40 00 #CR4F2 4 00 00 00 00 #CR551 8 00 00 00 80 00 00 40 00 #CR580 8 00 00 00 00 00 00 00 00 #CR5B3 8 64 BE 56 5E 30 8D F0 8A <DATA ERROR#CR1CB 7 00 00 00 00 60 02 9E #CR1C6 8 7F FF FF FE 72 29 02 DF <DATA ERROR#CR215 6 FF F0 FF 00 FF FF <DATA ERROR#CR216 2 42 64 <DATA ERROR#CR300 1 00

#CR002 5 1A 00 00 07 2E #CR174 8 00 00 00 AA 08 00 00 00 #CR176 7 00 00 00 00 00 00 08 #CR180 8 00 00 00 00 00 00 28 00 #CR1D5 5 00 00 00 00 D6 #CR5C5 8 44 00 14 D8 00 0C 00 00 <DATA ERROR#CR2DE 8 00 00 00 00 00 00 02 B2 #CRBUFFER FULL#CR#CR>

E2.2. Prototipo del Módulo de Adquisición

Página 23 de 28

Test ID 02

Caso de Uso involucrado CUSR0201 Descarga de la ruta

Fecha 10/03/2017

Descripción del escenario

Las pruebas se realizaron en las instalaciones de SD Logistica, el SOC del coche al inicio es de un 80-90% aproximadamente.

Se procede a capturar todos los datos que pasan por los cables hacien-do especial incapie en la línea de datos que contiene el valor del SOC, y se comprueba que este valor conforme el vehículo va circulando dismi-nuye, pero cuando el conductor frena aumenta, debido a la regenración que se produce.

Paso Acción Entrada Resulado GAP

01 Realizar el test 01

En evaluación/validación de

resultado, se muestra como ha

ido variando este valor durante

25 minutos de conducción. Para

mayor claridad se ha marcado en

color rojo las casillas de la tabla

donde se ve que el SOC del

vehículo esta disminuyendo y en

color verde los momentos en los

cuales se observa como el SOC

aumenta debido a la regenera-

ción por frenada.

Observaciones

Evaluación/validación de los resultados

El test ha sido realizado correctamente. Comienza el trayecto a las 11:15 y termina a las 11:40.

80.1% 79.1% 77.5% 75.5% 75.0% 73.4% 73.3% 73.2% 72.3%

72.2% 71.7% 71.6% 71.5% 71.4% 70.7% 70.6% 69.9% 69.8%

69.3% 69.4% 68.8% 68.9% 69.0% 68.9% 66.8% 66.7% 66.6%

65.2% 65.1% 65.2% 64.5% 64.4% 64.3% 64.2% 64.1% 63.1%

63. 0% 62.0% 62.1% 62.2% 62.3% 62.2% 61.6% 61.5% 61.4%

61.3% 59.8% 59.7% 59.4% 59.3% 59.4% 59.1% 59.0% 58.9%

E2.2. Prototipo del Módulo de Adquisición

Página 24 de 28

Test ID 01

Caso de Uso involucrado CUSR0201 Descarga de la ruta

58.3% 58.4% 58.5% 58.6% 58.5% 57.6% 57.7% 57.8% 57.9%

57.6% 57.5% 57.4% 57.3% 57.4% 57.5% 57.4% 57.3% 57.4%

57.1%

Tabla 2. Evolución del SOC durante una ruta de 25 min.

E2.2. Prototipo del Módulo de Adquisición

Página 25 de 28

Test ID 03

Caso de Uso involucrado CUSR0201 Descarga de la ruta

Fecha Del 10/03/2017 al 15/03/2017

Descripción del escenario Se dejó un Kit de evaluación con una memoria SD recogiendo datos ca-da 20 segundos durante 5 días. Se hacen un total de 22635 lecturas, tras cuales 4690 corresponden a actividad en el Bus de comunicaciones del vehículo.

Paso Acción Entrada Resulado GAP

01

Realizar el test

02 durante 5

días.

Tras analizar estos datos se locali-

za en cada lectura la cabecera que

se piensa que contiene el valor del

SOC y se muestra en evalua-

ción/validación de los resultados

una gráfica como varía con el tiem-

po.

Observaciones

Evaluación/validación de los resultados

E2.2. Prototipo del Módulo de Adquisición

Página 26 de 28

Test ID 03

Caso de Uso involucrado CUSR0201 Descarga de la ruta

El test ha sido realizado correctamente.

Figura 155. Grafica de las lecturas del SOC

Figura 166. Evolución del SOC en base al tiempo

E2.2. Prototipo del Módulo de Adquisición

Página 27 de 28

7.1 Interpretación de los datos

Los datos obtenidos son contrastados con unas tablas donde están registradas las cabeceras y los comandos para comunicarse con el bus CAN del vehículo.

Dado que es un vehículo eléctrico, los cuales están empezando a implantarse en el mercado, existe una cierta problemática ya que las tablas de comandos son distintas a las de un vehículo de combus-tión.

E2.2. Prototipo del Módulo de Adquisición

Página 28 de 28

8 Diseño Firmware

Figura 177. Diagrama de flujo del Firmware

Para evitar errores de comunicación debido al tiempo que puede tardar en devolver toda la trama de datos el interpretador, se ha optado por pedir constantemente la trama de datos, analizar la misma en busca de las cabeceras que contienen la información que se requiere en este proyecto y actualizar la información. De esta forma, cuando se pida la información desde la App, se entregará el último dato recogido.

* En este proyecto han colaborado por parte del ITE: Caterina Tormo Domènech, Christian Conca de la Asunción, Ignacio Javier Bení-tez Sánchez, Julio César Díaz Cabrera, Juan Carlos Rojas Mestre, Celeste Martínez Catalán, Ricardo Ridaura Belenguer, Esther Mo-cholí Munera, Alejandro Almela Frechina; Por parte de ITENE: Emilio González Viosca, Enrique De La Cruz Navarro, Miguel Angel Al-ferez Moreno, Jose Ángel Rodríguez Álvaro, Liseth Monticone, Sergio Güerri, Carla Cots Renau