DISEÑO DE PLATAFORMAS DE VALIDACIÓNHIL PARA VEHÍCULOS HÍBRIDOS

Bruno Elvis Costas Rodés

Trabajo de Fin de GradoEscuela de Ingeniería de Telecomunicación

Grado en Ingeniería de Tecnologías de Telecomunicación

TutoresPerfecto Mariño EspiñeiraFrancisco Poza González

2018

Escola de

Enxeñaría de

Telecomunicación

Grao en Enxeñaría de

Tecnoloxías de

Telecomunicación

Mención:

Sistemas electrónicos

DISEÑO DE PLATAFORMAS DE VALIDACIÓN

HIL PARA VEHÍCULOS HÍBRIDOS

Autor: Bruno Elvis Costas Rodés

Tutores: Perfecto Mariño y Francisco Poza

Curso: 2017-2018

Índice

I. Introducción 3

II. Objetivos 3

III. Resultados 4

IV. Conclusiones 9

V. Bibliografía 10

Anexo 1: Estado del arte 11

Anexo 2: Librerías utilizadas 20

2. A. Librería de variables 20

2. B. Librería de métodos de validación de señales 21

2. C. Librería de métodos de activación de señales 22

Anexo 3: Test individuales y resultados 23

3. A. Test de arranque 24

3. B. Test de bocina 25

3. C. Test de activación del limpiaparabrisas 27

3. D. Test del filtro de aire ICE (Internal Combustion Engine) 32

3. E. Test de activación de la luz de día 33

3. F. Test de activación de las luces cortas 35

3. G. Test de activación de los intermitentes 39

Anexo 4: Hardware 44

4. A. Podium 44

4. B. Power 66 45

4. C. VT System 46

4. D. Placa de cargas 47

Anexo 5: Valoración económica 48

I. Introducción

En esta memoria se recogen el desarrollo y los resultados del Trabajo de Fin de Grado “Diseño de

plataformas de validación HIL para vehículos híbridos” del grado de Ingeniería de Tecnologías de

Telecomunicación de la Universidad de Vigo, en el curso académico 2017/2018.

Vectia es una empresa que, entre otras cosas se dedica al diseño de autobuses híbridos. Estos vehículos

poseen un circuito eléctrico interno, que se controla desde un Podium. Éste es el panel de control de

control de un autobúes, desde el que se controlan todas las funcionalidades del mismo. Está explicado en

profundidad en el Anexo 4. Manda las señales de control a las tres ECUs (Unidades de control de motor).

Estas son las que generan las señales actuadoras para las diferentes funcionalidades del vehículo.

Para comprobar que no hay errores antes de poner el sistema a funcionar en un vehículo, el sistema debe

ser sometido a un proceso de validación, que se realiza mediante el diseño de una plataforma HIL

(Hardware-in-the-Loop) [11, 12]. Las ECUs se conectan a un sistema VT por el cual se monitorizan las

señales, y además, las señales relacionadas con un componente resistivo se conectan a una placa de cargas

que simula el efecto que puede tener un actuador mediante una resistencia. Mediante la activación de

señales desde el Podium, o el control de algunos sensores, gracias a este circuito se pueden comprobar las

respuestas de los actuadores sin llegar a montarlos en el autobús, lo que simplifica mucho la verificación de

las funcionalidades del mismo.

II. Objetivos

El objetivo principal del proyecto es la validación mediante un sistema HIL las señales que generan las ECUs,

intentando encontrar sus puntos de fallo y detectar los problemas que se puedan producir mediante este

sistema. Para ello, se realizaron las siguientes tareas:

- Estudio inicial y período de aprendizaje de las herramientas a utilizar: Para realizar este proyecto

hubo un extenso trabajo de documentación inicial, ya que las herramientas a utilizar, CANoe,

vTestStudio y la programación en lenguaje CAPL eran cosas con las que no se había trabajado con

anterioridad. Además también se realizó un estudio del sistema proporcionado, y de las señales con

las que había que trabajar.

- Comprobación del cableado existente y adición de nuevo cableado: Tarea que consistió en

repasar todas las conexiones del sistema, para detectar puntos de fallo, además de añadir nuevo

cableado que no se había realizado todavía.

- Diseño del sistema en CANoe: A nivel de software, lo primero fue diseñar el sistema en CANoe,

generando las redes de nodos y asignándoles los valores oportunos.

- Diseño de los test de validación mediante vTestStudio: Finalmente se realizó el diseño de los test

con la herramienta vTestStudio, y se sometieron a validación mediante CANoe.

III. Resultados

Lo primero que se va a comentar es el funcionamiento de la plataforma de validación que se ha

implementado. La Figura 1 representa un esquema sencillo del sistema.

Figura 1: Circuito de validación HIL.

El sistema funciona de la siguiente manera, por partes.

El Podium emite una señal actuadora, y esto puede deberse a dos posibilidades. La primera que

accionemos manualmente uno de los pulsadores o botones incorporados en el propio Podium, como

pueden ser la bocina o los intermitentes. La segunda es que emita señales de estado, en función de las

variables internas del Podium. Este lleva un software interno que gestiona sus señales, y comprueba que

todo sea correcto. Por ejemplo, internamente, actuará la señal de refrigeración del motor si detecta que la

temperatura del motor es demasiado elevada. Cada señal tiene sus propias condiciones para ser activada, y

ninguna se ejecutará si no se cumplen todas ellas, aunque sea una señal que se active manualmente.

El Podium se comunica con las ECUs mediante un bus CAN. El vehículo posee tres ECUs, cuyo nombre se

puso en función de su situación en el vehículo: Delantera, central y trasera. Estas realizan dos funciones

principales. Transforman las señales que reciben del Podium en señales independientes e individuales

dirigidas a los actuadores. Las señales que emiten pueden ser de dos tipos, orientadas a actuadores

(binarias) o de control (en CAN). La otra función que realiza es la comunicación inversa. Envían al Podium

señales de control, que pueden provenir de sensores, o señales que publica el CANoe, también de control,

en mensajes CAN.

El VT System es el que procesa las señales. Establece comunicación por Ethernet con el CANoe. A través de

ella se deciden, desde el CANoe, que señales se quieren simular y evaluar. Además, mediante él, se pueden

simular varias variables que no están presentes físicamente. Está conectado a la placa de cargas, que simula

las resistencias de los diferentes actuadores del vehículo. Mediante activación de relés (que se controlan

desde los test ejecutados en CANoe), se seleccionan las cargas que se quieren utilizar en cada simulación.

La señal recibida de la placa de cargas también se lee en él, que envía el resultado al CANoe.

La placa de cargas es una simulación resistiva de algunas funcionalidades del autobús. Hay algunos

actuadores que en un vehículo que presentan una resistencia, como pueden ser las luces o un

limpiaparabrisas. Si no se detecta esa resistencia (mediante una medición de la intensidad), la ECU bloquea

esa señal y no se activa. Para simular esas resistencias se conectan las señales a la placa de cargas, que es

una sucesión de canales, cada uno con distinta resistencia, conectados cada uno a un diodo LED para saber

cual está activado. Para explicar el funcionamiento de la lectura de una señal que pasa por la placa de

cargas se sigue el esquema de la Figura 2.

Figura 2: Esquema de la placa de cargas.

Recibimos una señal de actuación, como puede ser por ejemplo, la pulsación de una bocina. Entonces,

cuando se active el relé de esta carga mediante él, la señal circula por el circuito, la resistencia consume y el

LED se enciende, entonces, la señal medida pasa a ser ‘1’ (en binario), que es lo que lee él. En realidad, este

circuito equivaldría a una puerta AND con la señal de actuación y la de activación de relé como entradas, y

la tensión que cae en la resistencia como salida. Esta señal medida es la que se envía desde el al CANoe

para ser leída.

Toda la información completa del hardware está descrita en el Anexo 4. Se puede ver el equipo completo

en la Figura 3.

Figura 3: Equipo completo.

Para la comunicación entre el CANoe y las ECUs se utiliza un Hardware denominado CAN/LIN Interface

VN1630 (Figura 4) que utilizamos para adaptar la señal que llega del CANoe y, mediante un cable en Y,

dividirla en las dos redes CAN (chasis y carrocería), que tenemos en el sistema.

Figura 4: CAN/LIN Interface VN1630.

Una vez explicado el funcionamiento del sistema se pasará a desarrollar el funcionamiento de los test. Los

test están descritos individual y específicamente en el Anexo 3.

Lo primero fue desarrollar un test de arranque. Este inicializa el Podium y lo deja en un estado estable para

poder realizar los test. Este test consiste en activar las señales K30 y K15 que son las alimentaciones tanto

del Podium como de las ECUs, activa la seta de emergencia y el freno de mano, y pone a cero las señales de

demanda de contacto y el sensor de fuego. Además, manda por CAN las señales de cierre de puertas y la

temperatura a la que debe estabilizarse el motor mediante el refrigerante. Este test tarda

aproximadamente un minuto en desarrollarse, ya que es el tiempo que tarda el Podium en iniciarse. El test

completo está descrito en el apartado A del Anexo 3.

Una vez establecido eso se realizan el resto de los test. En ellos, hay dos tipos de señales, las señales

digitales, que se utilizan para la comunicación con el VT System, y por otro lado las señales CAN que se

utilizan para establecer la comunicación con las ECUs. Los test básicamente consisten en mediante la

activación de señales, ya sean de un tipo u otro, observar como varían las señales de los actuadores,

también de cualquiera de los tipos. Debido a esto, se desarrolló una librería de métodos que consistían en

la validación de este sistema, que reciben unas señales que ellos activan y leen la respuesta de las señales a

validar. Además, hay que tener en cuenta que las señales que funcionan con la placa de cargas requieren

una activación de relé previa, que se indica también desde los test mediante una función de activación de

carga, definida en otra librería. Ambas librerías están descritas también en el Anexo 2.

Además, todas las variables (entradas y salidas del VT System) fueron definidas en función de un archivo

Excel suministrado por la empresa Vectia que definía su cableado. Esta librería tuvo que ser modificada

varias veces por los problemas que hubo con el cableado que explicaré más adelante. Esta librería estará

explicada más en profundidad en el Anexo 2.

Para cada uno de los test hay que describir un fichero .vtt. Como cada test tiene varios casos de uso, este

archivo sirve principalmente para describir el orden de ejecución de los casos de uso al lanzar un test.

Además, también se pueden indicar unas funciones para antes de iniciar el test y preparar el equipo para

éste, o para que se ejecuten al finalizarlo. La Figura 5 sería un ejemplo de archivo vtt para las luces,

viéndose expandido el test de los intermitentes.

Figura 5: Archivo vtt para los intermitentes.

Cada uno de los test es compilado y cargado desde el CANoe. Una vez puesta en marcha la simulación, se

ejecuta el test de arranque y luego se inicia la validación de los test individuales. Cada test puede tener

varias secciones, y cada una de estos varios casos de test. Por ejemplo, el test de las luces está dividido en

varias secciones (una para las luces cortas, otra para los intermitentes, otra para la luz de día), y estas, a su

vez en varios casos de test (por ejemplo, para las luces cortas se establecen 4 casos de test, uno para las

luces apagadas, uno para la luz corta derecha, otro para la izquierda, y uno para ambas luces encendidas

simultáneamente).

CANoe genera un informe al finalizar un test, en el que indica si el test ha sido ejecutado con éxito o no, y

en caso negativo, sus puntos de fallo. Este informe se abre desde un programa que se llama CANoe test

report viewer, que da un formato a los resultados, teniendo en cuenta las especificaciones del mismo que

se puedan imponer en CAPL desde los archivos de los test. La Figura 6 sería un ejemplo de un informe de

test.

Figura 6: Informe de test del limpiaparabrisas.

Por otra parte, además de la validación software hubo que hacer una validación y ampliación de las

conexiones del hardware. Aunque a priori se presuponía que éste estaba bien realizado y completo, resulto

ser lo contrario. A medida que se iba avanzando en el proyecto, acabó viéndose que las conexiones entre

las ECUs y el VT System y entre el VT System y la placa de cargas estaban mal realizadas. Junto con el

equipo se nos proporcionaron varios documentos de Excel en los que se indicaban las entradas y salidas de

cada uno de los componentes Hardware, para utilizar directamente esta información en los test. Pero había

conexiones que no coincidían y otras que faltaban, así que la solución fue revisar el cableado cable a cable

(Figura 7). Primero se revisó con un polímetro que todas las conexiones entre las ECUs y el VT System

fueran correctas, y se cambiaron las conexiones oportunas. Una vez finalizado se comenzó la revisión del

cableado entre el VT System y la placa de cargas. En este caso, además de haber conexiones mal hechas,

faltaba todo el cableado que medía las señales en la placa de cargas y enviaba los resultados al VT System.

Es decir, el VT System enviaba señales a la placa de cargas, pero los resultados de estas nunca volvían de

vuelta.

Figura 7: Cableado del sistema.

IV. Conclusiones

El trabajo realizado en este proyecto fue orientado a afinar tanto el hardware como el software que fue

proporcionado por la empresa Vectia. Aunque el objetivo inicial era, a partir de un equipo que se

presuponía funcionando correctamente, realizar el mayor número de test posibles de las diferentes

funcionalidades del autobús, los problemas con el cableado que fueron comentados en el apartado

anterior, añadidos a los diferentes fallos que surgieron también con los dos ordenadores de la universidad

que se utilizaron para el desarrollo del proyecto (con el primero problemas con la compatibilidad entre el

software y el sistema operativo, y después con el segundo, numerosos reinicios y pantallas azules que

dificultaban enormemente la posibilidad de trabajo), obligaron a cambiar el rumbo del proyecto y a dejar el

hardware listo y funcionando al completo para que ya no de ningún tipo de problemas al trabajar con él. A

partir de ahora podrán hacerse numerosas validaciones nuevas, además de poder ampliar la plataforma de

validación HIL simulando nodos en otro ordenador a mayores, siendo este desarrollado con la herramienta

Simulink, lo que dará mayor veracidad a la simulación.

Como conclusión sobre los test obtenemos que la mayoría de las señales digitales simuladas funcionan

correctamente, salvo alguna excepción, pero que, sin embargo, el Podium no es capaz de detectar las

señales CAN enviadas desde el CANoe. Este sería uno de los problemas principales a solucionar en el futuro.

V. Bibliografía

[1] – National Instruments <<ni.com>> [En línea]. Disponible en: http://www.ni.com/ [Último acceso:

04/07/2018]

[2] – Jmag International <<jmag-international.com>> [En línea]. Disponible en: http://www.jmag-

international.com/ [Último acceso: 04/07/2018]

[3] – Bus CAN <<es.wikipedia.org>> [En línea]. Disponible en: https://es.wikipedia.org/wiki/Bus_CAN

[Último acceso: 04/07/2018]

[4] – JSOL <<jsol.co.jp>> [En línea]. Disponible en: https://www.jsol.co.jp/english/ [Último acceso:

04/07/2018]

[5] – Introducción a los sistemas de comunicación del vehículo <<es.scribd.com>> [En línea]. Disponible en:

https://es.scribd.com/doc/49635800/CAN-BUS-Introduccion-a-los-sistemas-de-comunicacion-del-

vehiculo [Último acceso: 04/07/2018]

[6] – Sobre CAN y aplicaciones de testeo <<mukom.mondragon.edu>> [En línea]. Disponible en:

https://mukom.mondragon.edu/ict/sobre-can-aplicaciones-de-control-y-testeo/ [Último acceso:

04/07/2018]

[7] Vector <<vector.com>> [En línea]. Disponible en: https://www.vector.com/ [Último acceso:

04/07/2018]

[8] Manual de CANoe <<vector.com>> [En línea]. Disponible en:

https://vector.com/portal/medien/cmc/manuals/CANoe75_Manual_En.pdf [Último acceso: 04/07/2018]

[9] CAPL Documentation <<vector.com>> [En línea]. Disponible en: https://kb.vector.com/entry/48/

[Último acceso: 04/07/2018]

[10] Introduction to CAPL <<can-newsletter.org>> [En línea]. Disponible en: https://can-

newsletter.org/assets/files/media/raw/778c5e06c68f2486a54599e245d18ff7.pdf [Último acceso:

04/07/2018]

[11] Mariño Andrés, Rodrigo (2017). Proyecto de Fin de Máster – Instrumentación de metodología

Hardware-in-the-Loop para aplicaciones de automoción basadas en herramientas de diseño electrónico y

simulación. Universidad de Vigo.

[12] R. T. Ogan, <<Hardware-in-the-Loop Simulation>> de Modeling and Simulation in the Systems

Engineering Life Cycle, Springer, 2015, páginas 167-173.

Anexo 1: Estado del arte. Sistemas de validación HIL.

La simulación Hardware-in-the-Loop (HIL) es una técnica usada para el desarrollo y comprobación de

sistemas embebidos en tiempo real complejos. La simulación HIL constituye una plataforma efectiva

porque incluye toda la complejidad de la planta que controla el sistema embebido. Esto lo realiza mediante

modelos matemáticos de todos los sistemas dinámicos relacionados con la planta bajo control, formando lo

que se denomina como "simulación de la planta". El sistema embebido que se está comprobando

interactúa con esta simulación de la planta.

Al probar sistemas de control embebido, las consideraciones de seguridad, disponibilidad o costo pueden

hacer poco práctico el realizar todas las pruebas necesarias usando el sistema completo. La simulación HIL

puede simular las partes del sistema que representan esos retos, lo cual permite probar ampliamente el

dispositivo de control embebido en un entorno virtual antes de proceder con las pruebas del mundo real

del sistema completo. Con esta habilidad, se puede mantener la fiabilidad y los requerimientos de tiempo

de salida al mercado de una manera rentable, aunque los sistemas que está probando se vuelven más

complejos.

La mayor parte de la información sobre National Instruments de este Anexo está sacada de [1].

Componentes de un sistema HIL

Un sistema de pruebas HIL consiste de tres componentes principales: un procesador en tiempo real,

interfaces de entrada y salida y una interfaz de operador.

El procesador en tiempo real es el núcleo del sistema de pruebas HIL. Proporciona ejecución determinística

de la mayoría de los componentes del sistema de pruebas HIL como comunicación de E/S de hardware,

generación de estímulos y ejecución de modelos. Un sistema en tiempo real es generalmente necesario

para proporcionar una simulación precisa de las partes del sistema que no están presentes físicamente

como parte de la prueba.

Las interfaces de E/S son señales analógicas, digitales y de bus que interactúan con la unidad bajo prueba.

Pueden utilizarse para producir señales de estímulos, adquirir datos para registro y análisis y proporcionar

las interacciones de sensor/actuador entre la unidad de control electrónico (ECU) probada y el entorno

virtual simulado por el modelo.

La interfaz del operador se comunica con el procesador en tiempo real para proporcionar comandos de

pruebas y visualización. A menudo, este componente también permite la administración de la

configuración, automatización de la prueba, análisis y tareas de informes.

Figura 8: Componentes de un sistema HIL.

Inserción de fallas de hardware

Muchos sistemas de pruebas HIL usan inserción de fallas de hardware para crear fallas de señales entre el

ECU y el resto del sistema para probar, caracterizar o validar el comportamiento del dispositivo bajo estas

condiciones. Para lograr esto, se pueden insertar unidades de inserción de fallas (Fault Insertion Units, FIU)

entre las interfaces de E/S y la ECU para permitir al sistema de pruebas HIL conectar las señales de la

interfaz entre una operación normal y condiciones de fallas como un corto a tierra o circuito abierto.

Figura 9: Inserción de fallas en un sistema HIL.

Sistemas de Múltiples ECU

Algunos sistemas de control embebido, como un automóvil, un avión o un parque eólico, usan múltiples ECUs que a menudo están conectados en red para funcionar sin dificultad. Aunque cada una de estas ECU debe ser probado con anticipación de forma independiente, a menudo se utiliza una integración del sistema de pruebas HIL como un simulador completo de vehículo o simulador aéreo, para lograr pruebas virtuales más completas. Al probar un sistema de control de múltiples ECU (y aún algunos sistemas de control de una sola ECU), surgen dos necesidades: potencia de procesamiento adicional y cableado simple.

Figura 10: Sistema HIL de múltiples ECUs.

Potencia de Procesamiento Adicional - Procesamiento Distribuido

Aún con la potencia de procesamiento multinúcleo más reciente, algunos sistemas requieren más potencia

de procesamiento de la que hay disponible en un solo chasis. Para solucionar este problema, existen

técnicas de procesamiento distribuido para cumplir con los requerimientos de rendimiento de estos

sistemas. En sistemas de gran cantidad de canales, la necesidad es más que simplemente potencia de

procesamiento adicional, también son necesarias entradas y salidas adicionales. Por el contrario, los

sistemas que utilizan grandes modelos de procesadores, a menudo usan chasis adicionales para potencia

de procesamiento extra, lo que permite a esos procesadores permanecer dedicados a una sola tarea para

una mayor eficiencia. Dependiendo de cómo están distribuidas las tareas del simulador, puede ser

necesario proporcionar señales de disparo y temporización compartidas entre el chasis, así como reflejar

datos determinísticos para permitirles operar sin dificultad. Esto puede apreciarse en el esquema de la

Figura 11.

Figura 11: Procesamiento distribuido en un sistema HIL.

Cableado Simple

Implementar y mantener el cableado para sistemas de gran cantidad de canales puede representar problemas costosos y lentos. Estos sistemas pueden requerir que de cientos a miles de señales sean conectadas entre el ECU y el sistema de pruebas HIL, abarcando muchos metros que contribuyen a los requerimientos de espacio.

Afortunadamente, las tecnologías de E/S distribuida determinística pueden ayudar a disminuir estas complejidades de cableado y proporcionar conectividad modular a las ECUs, lo cual permite modificaciones eficientes de configuración del sistema. En lugar de enrutar todas las conexiones de regreso a un solo rack que contiene uno o más chasis de procesamiento en tiempo real con interfaces de E/S, se puede usar E/S distribuida determinística para proporcionar interfaces de E/S modular ubicadas cerca de cada ECU, sin sacrificar el determinismo de alta velocidad necesario para una simulación precisa de las partes virtuales del sistema.

Este enfoque reduce enormemente el costo y la complejidad del cableado del sistema de pruebas HIL, haciendo posible que las conexiones entre la ECU y las interfaces de E/S se puedan hacer localmente (abarcando menos de un metro), mientras que un solo cable de bus es usado para abarcar la distancia adicional al chasis de procesamiento en tiempo real. Además, con la naturaleza modular de este enfoque, los sistemas de pruebas HIL se pueden escalar, progresivamente, de un sistema de pruebas de múltiples ECU en el cual todas menos una de las ECUs están simulados a un sistema de pruebas HIL de integración completa de sistemas donde ninguna de las ECUs está simulada. Esto puede observarse en la Figura 12.

Figura 12: Cableado en un sistema HIL.

Sistema HIL de National Instruments

La creciente adopción de motores eléctricos en la industria automotriz y en aplicaciones de energía verde

ha creado nuevos desafíos para los desarrolladores de sistemas de control integrados y los ingenieros de

pruebas. La simulación del motor eléctrico debe tener alta fidelidad, los sistemas de simulación deben

poder ejecutar modelos de simulación del orden de 1 μs para simular adecuadamente el comportamiento

del motor eléctrico. Esta combinación de fidelidad de simulación y velocidad de ejecución ha sido

previamente imposible, muchos ingenieros de prueba tuvieron que recurrir al dinamómetro más costoso o

a las pruebas de campo para validar su software integrado.

Utilizando la última tecnología para simulación de motor eléctrico de alta fidelidad en tiempo real, se

pueden probar muchos tipos de condiciones transitorias y de falla que son difíciles o poco prácticas de

realizar con sistemas reales. Estas pruebas pueden ser destructivas para el hardware físico. Sin embargo,

con esta simulación de alta precisión del sistema físico, se puede ejercitar el controlador en casos extremos

para garantizar la seguridad y protección en tiempo real.

La plataforma HIL de National Instruments proporciona la simulación en tiempo real de la más alta fidelidad

disponible en una plataforma abierta y extensible para la ejecución de pruebas. Con la plataforma NI, se

pueden encontrar problemas y optimizar el rendimiento en una etapa anterior del proceso de desarrollo, lo

que reduce la cantidad de pruebas de campo para validar el software incorporado y, como resultado,

mejora la eficiencia del desarrollo.

National Instruments ha combinado las herramientas de hardware y software para proporcionar una

plataforma líder en la industria de electrónica de potencia y prueba de motor eléctrico en tiempo real. El kit

de herramientas de simulación de motores eléctricos de NI contiene modelos de máquinas eléctricas e

inversores para que los ingenieros de control establezcan rápidamente sistemas de prueba que se vinculen

al mayor ecosistema de herramientas de NI para la prueba en tiempo real.

Kit de herramientas de simulación de motor eléctrico de NI (NI Electric Motor Simulation Toolkit)

El kit de herramientas de simulación de motores eléctricos de NI (Figura 13) proporciona los elementos de

modelado para desarrollar simulaciones de escritorio y HIL de sistemas de motor eléctrico. El juego de

herramientas agrega una plantilla de proyecto de LabVIEW para simulación de motor eléctrico, control y

simulación de HIL. El kit de herramientas también incluye complementos VeriStand para varios tipos de

motores. Puede ejecutar los modelos en una computadora host para la simulación de solo software, en los

objetivos NI Real-Time para la simulación HIL tradicional, o en los objetivos NI FPGA para la simulación HIL

de alta velocidad.

El kit de herramientas contiene modelos de tipos de motor Switched Reluctance (SR) y Permanent

Synchronous Machine (PMSM) en una aproximación lineal simple o en una representación de alta fidelidad

que se integra con los modelos JMAG-RT de JSOL [4]. La interfaz con los modelos JMAG-RT basados en

análisis de elementos finitos (FEA) proporciona la capacidad de simular con precisión un comportamiento

altamente no lineal, como el par de engranaje y la saturación magnética.

Figura 13: Una combinación de hardware y software para un ECU de motor eléctrico prueba HIL.

Los siguientes son los tipos de motor admitidos:

Máquina síncrona con imán permanente (PMSM)

Modelo de parámetro constante

JMAG-RT modelo basado en FEA

Switched Reluctance Motors (SRM)

Modelo lineal

JMAG-RT modelo basado en FEA

Asociación con JSOL Corporation para HIL utilizando modelos JMAG-RT

National Instruments se ha asociado con JSOL Corporation para usar sus herramientas FEA, JMAG y JMAG-RT, para generar modelos de alta fidelidad que puede usar con el software de diseño de NI LabVIEW (Figura 14) y el software NI VeriStand para configurar aplicaciones de prueba en tiempo real. Con esta asociación, NI está abordando los requisitos clave para la prueba y simulación de motores eléctricos. Ahora se pueden ejecutar modelos de motores basados en FEA con temporización de microsegundos utilizando LabVIEW FPGA y el hardware NI RIO FPGA. Los modelos usan la tabla de búsqueda generada por FEA para parametrizar los modelos en tiempo real en función del estado actual del motor. Esta combinación de matemática lineal y tabla de búsqueda no lineal proporciona una simulación muy rápida y precisa.

Figura 14: Herramienta de NI en LabView.

Cálculos obtenidos con modelos en NI Electric Motor Simulation Toolkit

JMAG[2] es un completo paquete software para diseño de equipo electromecánico y su desarrollo (Figura

15). Una potente simulación y el análisis tecnológico proporcionan un nuevo estándar en el rendimiento y

la calidad del diseño de un producto.

Figura 15: Captura del software JMAG.

NI Veristand

NI VeriStand es un entorno de software para crear aplicaciones de prueba en tiempo real. Ayuda a realizar comunicaciones con un host en tiempo real, registro de datos, generación de estímulos y detección y respuesta de alarmas. NI VeriStand también permite pasar rápidamente de las pruebas solo de simulación a las pruebas HIL, lo que ayuda a reutilizar componentes de prueba, como perfiles de prueba, alarmas, procedimientos y rutinas de análisis. Puede reasignar parámetros de modelos a canales de hardware para facilitar la E/S del mundo real. Esta transición ahorra tiempo al realizar pruebas de regresión y ayuda a automatizar las pruebas utilizando el software de prueba ejecutiva, como NI TestStand.

NI VeriStand presenta un marco abierto que se puede utilizar para crear funcionalidades específicas de la aplicación a través de complementos en tiempo real. Esto proporciona la máxima flexibilidad en sistema de prueba. El Kit de herramientas de simulación de motores eléctricos de NI agrega funciones de modelado de motores al entorno de configuración para poder realizar simulaciones y pruebas de escritorio y en tiempo real en una plataforma tradicional de hardware en tiempo real y simulación de alta velocidad en una FPGA.

Sistema HIL de Vector

Vector utiliza para este tipo de simulaciones el denominado VT System, que será el utilizado en este

Trabajo de Fin de Grado. Simplifica enormemente la configuración de bancos de prueba y sistemas de

prueba HIL, ya que integra todos los componentes del circuito necesarios para conectar un canal de E/S en

un módulo [7]. Un esquema de la utilización de este sistema es el de la Figura 16.

Figura 16: Sistema HIL de Vector.

El VT System sustituye los actuadores y sensores que pueda tener el vehículo por simulaciones, y está

directamente conectado a CANoe mediante Ethernet. Desde el CANoe, se ejecutan los test diseñados desde

el software de Vector vTestStudio, preparado para controlar este tipo de Hardware, activando las entradas

y salidas necesarias para la correcta validación del sistema. El VT System al completo está explicado en el

Anexo 4.

Anexo 2: Librerías utilizadas.

Se han descrito 3 librerías principales para facilitar el desarrollo de los test. Son las siguientes.

A. Librería de variables.

Para un acceso rápido a todas las variables que se utilizan en el sistema se ha desarrollado esta librería. Por

un lado, se asignan los mensajes CAN de la base de datos a vectores tipo “char[]” para facilitar su uso. Este

sería un fragmento de la librería que realiza esta función.

char CAN_DCLink[25] = "BEGA1::DC_Link_Status";

char CAN_SwitchOffPW[30] = "BEGA1::Switch_off_K15_allowed";

char CAN_FrontAxleSpeed[28] = "EBC2_0000::FrontAxleSpeed";

char CAN_DoorPositionDelantera[28] = "DOOR1_R::Door_position";

char CAN_DoorPositionCentral[28] = "DOOR2_R::Door_position";

char CAN_DoorPositionTrasera[28] = "DOOR3_R::Door_position";

char CAN_DoorEmergencyDelantera[28] = "DOOR1_R::Emergency_door";

char CAN_DoorEmergencyCentral[28] = "DOOR2_R::Emergency_door";

char CAN_DoorEmergencyTrasera[28] = "DOOR3_R::Emergency_door";

char CAN_RampStatus[28] = "RAMP_R::Ramp_status";

Estos son algunos de los ejemplos de los múltiples mensajes CAN que se utilizan en el sistema.

Por otro lado, declara todas las variables que se van a utilizar para asignarlas posteriormente en los test.

Estas serán tanto digitales como de activación de relé. Este es un fragmento de las declaraciones de

variables:

sysvarInt * Power_KL30;

sysvarInt * Power_KL15;

sysvarInt * Digital_DemandaContacto;

sysvarInt * Digital_ActivationMS;

sysvarInt * Digital_SetaEmergencia;

sysvarInt * Digital_SensFuego;

Finalmente, estas variables son inicializadas, asignándosele un puerto de entrada o de salida del módulo

VT:

Power_KL30 = sysvar::VTS::M8_Out1::Active;

Power_KL15 = sysvar::VTS::M8_Out2::Active;

Digital_DemandaContacto = sysvar::VTS::M7_Ch1::DigitalOutput;

Digital_ActivationMS = sysvar::VTS::M7_Ch30::DigitalOutput;

Digital_SetaEmergencia = sysvar::VTS::M7_Ch23::DigitalOutput;

Digital_SensFuego = sysvar::VTS::M5_Ch17::DigitalOutput;

B. Librería de métodos de validación de señales.

Esta librería define métodos para la validación de algunas señales en función de los valores introducidos.

Estos consisten en variar una o varias señales, y comprobar como eso afecta a otras señales, ya sean éstas

mensajes CAN o digitales. Se han definido 12 métodos con diferentes combinaciones posibles. Además, a

algunos de estos métodos se les puede pasar un parámetro de tiempo en ms que determina un tiempo de

espera entre la variación de las señales y la validación de los datos recibidos. Este sería un ejemplo sencillo

de uno de estos métodos:

testfunction TestType9 (signal * CANSignal, int signalval, sysvarInt * Digitaloutpin, int DigitalVal, int

waittime, signal * CANresponseSignal, int signalresponseVal, sysvarInt * DigitalInPin, int

DigitalInPinVal,char ID[], char description[] ){

int result;

int DIresult;

testStep(ID, description);

setSignal(CANSignal, signalval);

NUSUR_DigitalOutput(Digitaloutpin, DigitalVal);

NUSUR_WaitForTime(waittime);

result = testWaitForSignalMatch(CANresponseSignal, signalresponseVal, timetochange);

DIresult = NUSUR_DigitalInputMatch(DigitalInPin, DigitalInPinVal, signalwaittime);

if(result != 1) testStepFail("Mensaje CAN no corresponde con lo esperado");

if(DIresult == -1) testStepFail("Pin fisico no es correcto");

if(result == 1 && DIresult == DigitalInPinVal) testStepPass();

}

Este test lo que hace es poner las dos variables recibidas (una señal can y una señal digital) a los valores

también recibidos en las variables signalVal y DigitalVal, espera un tiempo waittime y comprueba el valor

de una señal CAN diferente y un pin digital diferente al anterior. Si ambos coinciden con el valor esperado

se llama al método testStepPass(), y si no es así se llama a la función testStepFail(), pasando el error que ha

sucedido en el test.

De este mismo modo, todos los métodos de esta librería son del mismo estilo pero variando el número de

señales que se utilizan, así como los tipos de señal.

C. Librería de métodos de activación de señales.

En esta librería se definen los métodos para asignar y recoger los valores de diferentes señales (lo que

serían los métodos getters y setters de los pines del VT System), así como los métodos para activar y

desactivar las cargas de la placa de cargas. Este sería, por ejemplo, el método para activar la carga:

int NUSUR_ActivarCarga (sysvarInt * DigitalPin, sysvarInt * Relay)

{

int errors;

char msg1[100] = "\0", msg2[200] = "\0";

strncpy(msg1,"\0",200);

strncpy(msg2,"\0",200);

strncat(msg2, "Activación de la carga con el rele ", 200);

strncat(msg2, Relay.namespace, 200);

strncat(msg1, "El rele es ", 200);

strncat(msg1, Relay.namespace, 200);

strncat(msg2, " y el pin digital es ", 200);

strncat(msg2, DigitalPin.name, 200);

testStep(lvldetail, msg1, msg2);

errors = vtsSetOutputMode(DigitalPin.namespace, 0);

if(errors == 0) errors = sysSetVariableInt(Relay.namespace, Relay.name, 1);

if (errors == 0)

{

// Ningún error activando la carga

errors = sysGetVariableInt(DigitalPin.namespace, DigitalPin.name);

}

else

{

testStepFail(msg1, "Error activando la carga");

errors = 3;

}

return errors;

}

Esta función activa un relé y devuelve a través de la variable errores un 0 si todo va bien o un 3 (“11” en

binario) si se han producido errores. La función para desactivar la carga funcionaría exactamente igual.

Anexo 3: Test individuales y resultados.

En este anexo se van a analizar por separado los resultados en cada uno de los test. Además también se

explicará la configuración utilizada en CANoe [8] para probar el sistema.

En CANoe se crean dos redes principales, una red chasis y una red carrocería. Estas redes tienen nodos que

están definidos en la base de datos, algunos son independientes de cada una de las redes, pero unos pocos

los comparten. Estas dos redes están conectadas a CAN 1 (chasis) y a CAN 3 (carrocería) para establecer la

conexión con las ECUs desde el ordenador. En la Figura 17 se muestran los nodos conectados a la red chasis

y en la Figura 18 se muestran los nodos conectados a la red carrocería.

Figura 17: Nodos de la red chasis.

Figura 18: Nodos de la red carrocería.

Estos nodos fueron siendo definidos individualmente para cada una de las dos redes. Una vez realizado

esto, se asigna a cada uno de ellos un nodo de la base de datos para dejarlo todo definitivamente

configurado. Por ejemplo, en la Figura 19, se puede observar la configuración del nodo de control de

puertas.

Figura 19: Ejemplo de configuración de nodo.

Finalmente, el último paso es configurar la conexión CAN de las dos redes, estableciendo estas a 250 kBaud

como se puede apreciar en la Figura 20.

Figura 20: Configuración del bus CAN de la red chasis.

Tras hablar de la configuración del CANoe, coviene explicar que en los siguientes test, se da por supuesta la

activación de la señal Master Switch (MS), que está siempre activa una vez arranca el Podium. Para la

información sobre CAN se han utilizado las referencias [3], [5] y [6].

A. Test de arranque

Como se explicó en el apartado III sobre resultados, lo primero de todo para hacer cualquiera de los test es

ejecutar un test de arranque que inicializa el Podium y lo deja en un estado estable a partir del cual

trabajar. Este no es un test propiamente dicho aunque se ejecute como tal, ya que en él no se valida

ninguna señal, y solo sirve para activar o desactivar algunas señales. Consta de dos casos, uno para el

arranque y otro para la parada, aunque este último no es necesario utilizarlo. Empezamos por el de

arranque [9, 10]:

export testcase MSArranque()

{

NUSUR_DigitalOutput(Power_KL30, 1);

NUSUR_DigitalOutput(Digital_SetaEmergencia, 1);

NUSUR_DigitalOutput(Digital_FrenoMano, 1);

NUSUR_DigitalOutput(Digital_DemandaContacto, 0);

NUSUR_DigitalOutput(Digital_SensFuego, 0);

NUSUR_WaitForTime(2000);

NUSUR_DigitalOutput(Power_KL15, 1);

NUSUR_WaitForTime(TimeTostart);

NUSUR_SetSignal("ET1::EngCoolantTemp", 20);

NUSUR_SetSignal("DOOR1_R::Emergency_door", 0);

NUSUR_SetSignal("DOOR2_R::Emergency_door", 0);

NUSUR_SetSignal("DOOR3_R::Emergency_door", 0);

}

En él se activan las alimentaciones tanto del Podium como de las ECUs (KL30 y KL15), se activan la señal de

la seta de emergencia y del freno de mano, y se ponen a cero las señales de demandar contacto y el sensor

de fuego. Tras esperar un tiempo TimeToStart de aproximadamente un minuto, que es el tiempo que le

lleva inicializarse al Podium, se establece una temperatura del refrigerante y se cierran las puertas del

vehículo. Una vez realizado este test el Podium se queda en un estado estable a partir del cual ejecutar el

resto de los test.

Además de este se ha descrito un test de paro del sistema, que realiza la función inversa al anterior. Ahora

el sistema demanda un contacto, y el freno de mano está desactivado. La seta de emergencia y el sensor de

fuego permanecen igual.

export testcase MSApagado()

{

NUSUR_DigitalOutput(Digital_SetaEmergencia, 1);

NUSUR_DigitalOutput(Digital_FrenoMano, 0);

NUSUR_DigitalOutput(Digital_SensFuego, 0);

NUSUR_DigitalOutput(Digital_DemandaContacto, 1);

NUSUR_WaitForTime(TimeTostart);

vtsSetInterconnectionMode(Power_Module,0);

}

B. Test de bocina.

El primer test realizado fue el de la bocina debido a su sencillez. Este consiste en comprobar si su señal

correspondiente se activa tras una pulsación manual de la bocina en el Podium. Esta sería la descripción del

test:

“En caso de que el master switch se encuentre activo y se detecte la activación de la bocina por

entrada digital interna de Podium, se publicará por salida digital (CN103.14 Power66 delantero) la

activación de la bocina.”

Tabla I: Tabla de verdad de activación de la bocina.

MS (DO) Activation order

(Podium) Activation order

(DO)

0 0 0

0 1 0

1 0 0

1 1 1

Como indicamos al principio, en los test el Master Switch se supone activo, el objetivo es desarrollar un test

por el cual se compruebe que la salida (DO) es igual al pulsador de la bocina en el Podium (Activation

order). Para ello se desarrolló el siguiente código:

export testcase TC12_2 ()

{

testCaseTitle("PV_1","TC_2");

testCaseDescription("Test de bocina");

NUSUR_ActivarCarga(DigitalBocina, RelayBocina);

TestType10("NO PULSAR BOCINA", 1000, DigitalBocina, 0, "ID:1-2 ", "Bocina no pulsada");

}

export testcase TC12_3 ()

{

testCaseTitle("PV_1","TC_3");

testCaseDescription("Test de bocina");

NUSUR_ActivarCarga(DigitalBocina, RelayBocina);

TestType10("PULSAR BOCINA", 10000, DigitalBocina, 1, "ID:1-2 ", "Bocina pulsada");

}

Se pueden observar claramente dos casos de uso. En el primero (TC12_2) se comprueba que si la bocina

está desactivada, la salida en DigitalBocina es ‘0’. Del mismo modo en TC12_3 se comprueba que cuando se

pulsa la bocina la señal de salida digital se pone a ‘1’. Además, en ambos casos, se pasa por el método de la

activación de una carga para la bocina, ya que su comportamiento resistivo es simulado a través de la placa

de cargas. Los resultados de este test pueden observarse a través del CANoe Test Report Viewer en las

Figuras 21 y 22:

Figura 21: TC12_2, bocina no pulsada.

Figura 22: TC12_3, bocina pulsada.

A partir de estos resultados se puede concretar que la bocina pasa el test y funciona correctamente.

C. Test de activación del limpiaparabrisas.

Este test es similar al anterior, solo que en este caso se controlan más variables. Ahora pasamos a tener dos

señales de activación de limpiaparabrisas para dos velocidades diferentes. Por un lado una señal si el

limpiaparabrisas está en la velocidad 1 o 2, y una a parte por si está en velocidad 3. Además, tendremos la

señal de agua del limpiaparabrisas.

Tabla II: Estado del limpiaparabrisas.

Water (Podium)

Speed1 o Speed2 (Podium)

Speed 3 (Podium)

Estado

0 0 0 Estado OFF

0 0 1 Estado E2

0 1 0 Estado E1

0 1 1 Estado E1

1 0 0 Estado E1 + W

1 0 1 Estado E1 + W

1 1 0 Estado E1 + W

1 1 1 Estado E1 + W

Tabla III: Máquina de estados del limpiaparabrisas.

Estado Slow (DO) Fast (DO) Water (DO)

Estado OFF 0 0 0

Estado E1 1 0 0

Estado E2 0 1 0

Estado E1 + W 1 0 1

Para desarrollar esto se han realizado 5 casos de uso. Uno por uno, son los siguientes:

export testcase TC1_1()

{

testCaseTitle(PV1Title, "TC_1");

NUSUR_DigitalOutput(Digital_ParoLimpias, 0);

NUSUR_ActivarCarga(Digital_LimpiasV1, Relay_LimpiasV1);

NUSUR_ActivarCarga(Digital_LimpiasV2, Relay_LimpiasV2);

NUSUR_ActivarCarga(Digital_LimpiasAgua, Relay_LimpiasAgua);

TestType10("Speed 1", 5000, Digital_LimpiasV1, 0, "ID:1_1", "Speed 1 desactivado");

TestType10("Speed 2", 5000, Digital_LimpiasV2, 0, "ID:1_1", "Speed 2 desactivado");

TestType10("Agua", 5000, Digital_LimpiasAgua, 0, "ID:1_1", "Agua desactivado");

}

Este es el primer caso. En él se puede comprobar que si no se activa ninguna señal, las salidas permanecen

también desactivadas, estando el sistema en Estado Off. Además, en este caso, y en todos los que vienen a

continuación, a la función TestType10() se le pasa una variable 5000 que indica el tiempo en milisegundos

que hay que esperar para validar una señal. Esto se hace para dar tiempo al usuario que realiza el test a

cambiar manualmente entre las diferentes funcionalidades del limpiaparabrisas en el Podium. Tras ejecutar

este test se genera el informe de test. Los resultados son los de la Figura 23.

Figura 23: TC1_1, limpiaparabrisas desactivado.

El siguiente paso a probar es la activación de las velocidades 1 o 2, por lo cual el limpiaparabrisas debería

pasar al Estado 1. Para ello se desarrolla el siguiente caso:

export testcase TC1_2()

{

testCaseTitle(PV1Title, "TC_2");

NUSUR_DigitalOutput(Digital_ParoLimpias, 0);

NUSUR_ActivarCarga(Digital_LimpiasV1, Relay_LimpiasV1);

TestType10("Speed 1", 5000, Digital_LimpiasV1, 1, "ID:1_2", "Speed 1 activado");

TestType10("Speed 2", 5000, Digital_LimpiasV2, 0, "ID:1_2", "Speed 2 desactivado");

TestType10("Agua", 5000, Digital_LimpiasAgua, 0, "ID:1_2", "Agua desactivado");

}

Aquí se puede comprobar que si se activa una de las dos primeras velocidades en el Podium, la señal de la

primera velocidad se activa, por tanto el test sería superado. Esto se puede comprobar en la Figura 24.

Figura 24: TC1_2, Limpiaparabrisas en velocidad 1.

Continuando con el siguiente estado de uso, se comprueba que si se activa la máxima velocidad

manualmente del limpiaparabrisas en el Podium, ésta se activa en la salida.

export testcase TC1_3()

{

testCaseTitle(PV1Title, "TC_3");

NUSUR_DigitalOutput(Digital_ParoLimpias, 0);

NUSUR_ActivarCarga(Digital_LimpiasV2, Relay_LimpiasV2);

TestType10("Speed 1", 5000, Digital_LimpiasV1, 0, "ID:1_3", "Speed 1 desactivado");

TestType10("Speed 2", 5000, Digital_LimpiasV2, 1, "ID:1_3", "Speed 2 activado");

TestType10("Agua", 5000, Digital_LimpiasAgua, 0, "ID:1_3", "Agua desactivado");

}

En este test se puede comprobar como si se activa la velocidad máxima, la velocidad máxima, que en el test

se denomina Speed 2 también se activa. Se genera el informe de test de la Figura 25.

Figura 25: TC1_3, Limpia parabrisas en velocidad 3.

En el siguiente caso comprobamos que el limpiaparabrisas sigue a la misma velocidad que en el estado

anterior pero además se ha activado su bomba de agua. Esto se hace de la siguiente forma:

export testcase TC1_4()

{

testCaseTitle(PV1Title, "TC_4");

NUSUR_DigitalOutput(Digital_ParoLimpias, 0);

NUSUR_ActivarCarga(Digital_LimpiasV2, Relay_LimpiasV2);

NUSUR_ActivarCarga(Digital_LimpiasAgua, Relay_LimpiasAgua);

TestType10("Speed 1", 5000, Digital_LimpiasV1, 0, "ID:1_4", "Speed 1 desactivado");

TestType10("Speed 2", 5000, Digital_LimpiasV2, 1, "ID:1_4", "Speed 2 activado");

TestType10("Agua", 5000, Digital_LimpiasAgua, 1, "ID:1_4", "Agua activado");

}

Del mismo modo que en los casos anteriores, se comprueba que el test funciona correctamente y se genera

el informe de test de la Figura 26.

Figura 26: TC1_4, Limpiaparabrisas a máxima velocidad y agua activado.

Finalmente, en el último caso se comprueba que el parabrisas funciona a velocidad 1 o 2 y además se activa

la bomba de agua.

export testcase TC1_5()

{

testCaseTitle(PV1Title, "TC_5");

NUSUR_DigitalOutput(Digital_ParoLimpias, 0);

NUSUR_ActivarCarga(Digital_LimpiasV1, Relay_LimpiasV1);

NUSUR_ActivarCarga(Digital_LimpiasAgua, Relay_LimpiasAgua);

TestType10("Speed 1", 5000, Digital_LimpiasV1, 1, "ID:1_5", "Speed 1 activado");

TestType10("Speed 2", 5000, Digital_LimpiasV2, 0, "ID:1_5", "Speed 2 desactivado");

TestType10("Agua", 5000, Digital_LimpiasAgua, 1, "ID:1_5", "Agua activado");

NUSUR_WaitForTime(5000);

NUSUR_DesactivarCarga(Digital_LimpiasV1, Relay_LimpiasV1);

NUSUR_DesactivarCarga(Digital_LimpiasV2, Relay_LimpiasV2);

NUSUR_DesactivarCarga(Digital_LimpiasAgua, Relay_LimpiasAgua);

NUSUR_DigitalOutput(Digital_ParoLimpias, 1);

NUSUR_WaitForTime(3000);

NUSUR_R_CheckPin(Digital_LimpiasV1, Relay_LimpiasV1, 0, "limpiaparabrisas V1");

}

Este es el más extenso de todos, ya que, además de las comprobaciones iniciales del test, finalmente se

desactivan todas las cargas que pudieron quedar activas de los casos anteriores, y se activa la señal de paro

del limpiaparabrisas, comprobando que esta también funciona. Se genera el test report de la Figura 27.

Figura 27: TC1_5, limpiaparabrisas a velocidad 1 o 2 y agua activada.

Como se validan todos los casos se puede determinar que el limpiaparabrisas funciona correctamente.

D. Test del filtro de aire ICE (Internal Combustion Engine)

Este test consiste en comprobar la detección de la variación del mensaje CAN

“DLCD1_0000::EngAirFilterRestrictionLampData” cuando se varia la señal “Depresión Filtro de Aire”. Las

especificaciones exactas son las siguientes:

“En caso de que el Master Switch se encuentre activo y se reciba por entrada digital la colmatación

del filtro de aire del ICE (CN104.09 Power66 trasero) , se publica por CAN (CAN: CAN3; MSG:

DLCD1 - 0x18FD05E6; SGNL: Engine Air Filter Restriction Lamp = 01b) el estado del mismo.”

Tabla IV: Tabla de verdad del filtro de aire ICE

MS (DO)

Depresión filtro aire ICE (DI)

Depresión filtro aire ICE (CAN3)

0 0 00b

0 1 00b

1 0 00b

1 1 01b

Para ello, se establecen dos casos, uno para la depresión del filtro de aire a ‘0’, y otro con la señal activada,

para ver cómo reacciona el mensaje CAN. El código es el siguiente.

export testcase TC1_1()

{

testCaseTitle(PV1Title, "TC_1");

TestType2(Digital_DepresionFiltroAire, 0, DLCD1_0000::EngAirFilterRestrictionLampData, 0, 10000,

"ID:1_1", "Filtro de aire");

}

export testcase TC1_2()

{

testCaseTitle(PV1Title, "TC_2");

TestType2(Digital_DepresionFiltroAire, 1, DLCD1_0000::EngAirFilterRestrictionLampData, 1, 10000,

"ID:1_2", "Filtro de aire");

}

En ambos casos se comprueba el estado del mensaje de salida en función del parámetro que se le asigna a

Digital_DepresionFiltroAire. Los resultados del informe son los de la Figura 28.

Figura 28: Resultado del test del filtro de aire ICE.

Se puede observar que en este caso el test no ha sido superado con éxito, y en ambos casos de uso por el

mismo motivo, la no coincidencia de la señal CAN recibida. Sin embargo, simultáneamente, CANoe permite

seguir en tiempo real las tramas y los mensajes CAN que se envían a través de él, y ahí se puede comprobar

que cuando activamos la señal Digital_DepresionFiltroAire a ‘1’ en respuesta el mensaje CAN

DLCD1_0000::EngAirFilterRestrictionLampData también se activa a ‘1’. Esto se puede observar con claridad

en las Figuras 29 y 30.

Figura 29: Estado del mensaje CAN correspondiente cuando se activa a ‘1’ Digital_DepresionFiltroAire.

Figura 30: Estado del mensaje CAN correspondiente cuando se desactiva Digital_DepresionFiltroAire.

Por tanto, a partir de esto podemos concluir que el filtro de aire ICE funciona correctamente, pero que, sin

embargo, el vTestStudio no es capaz de leer los mensajes CAN en tiempo real.

E. Test de activación de la luz de día.

Este test consiste en comprobar si se activa la luz de día en función del mensaje CAN DC Link Status, siendo

1 si también lo es el mensaje CAN. Además, la empresa Vectia informó de que podía haber un problema

con este test, ya que podía ser que solo funcionase con otro mensaje CAN, Traction Status, así que esta

funcionalidad fue probada con la activación de ambos mensajes. Las especificaciones iniciales exactas eran

las siguientes:

“En caso de que el master switch se encuentre activo y el sistema de tracción esté activo (CAN:

CAN3; MSG: VEGA1 - 0x18FF7847; SGNL: State of DC Link = 01b), se publicará por salida digital la

orden de encendido de la luz de día (CN101.13 Power66 delantero). “

Tabla V: Tabla de verdad de la luz de día.

MS (DO)

DC Link Status (CAN)

Activation order (DO)

0 0 0

0 1 0

1 0 0

1 1 1

Para realizar este test se establecen dos casos sencillos, en los que los mensajes CAN son puestos a ‘0’ o a

‘1’ respectivamente en cada caso, y en los que se comprueba que la salida se activa correctamente. El

código es el siguiente:

export testcase TC1_1()

{

testCaseTitle(PV1Title, "TC_1");

testCaseDescription("Test de luz de dia");

NUSUR_ActivarCarga(Digital_LuzDia, Relay_LuzDia);

TestType3(BEGA1::DC_Link_Status, 0,BEGA1::Traction_Status, 0, Digital_LuzDia, 0, "ID:1_1" , "Luz Día

desactivado");

}

export testcase TC1_2()

{

testCaseTitle(PV1Title, "TC_2");

testCaseDescription("Test de luz de dia");

TestType3(BEGA1::DC_Link_Status, 1,BEGA1::Traction_Status, 1, Digital_LuzDia, 1, "ID:1_2" , "Luz Día

activado");

}

Este test es sencillo, básicamente la función TestType3() establece al valor que se le pasa dos mensajes

CAN, en este caso BEGA1::DC_Link_Status y BEGA1::Traction_Status, y comprueba el valor que hay en la

señal digital Digital_LuzDia. Sin embargo, a pesar de que los mensajes se activan, falla la comunicación CAN

con las ECUs y la señal digital no se activa cuando es oportuno. Los resultados son los de las Figuras 31 y 32.

Figura 31: TC_1, Luz de día desactivada.

Figura 32: TC_1, Luz de día activada.

Se puede comprobar con este test que la luz de día nunca se activa, así que se determina que hay un

problema entre la funcionalidad del Podium y las ECUs. Además, para demostrar que el test es correcto y

que el problema no es que no se establezcan los valores oportunos a las señales CAN, podemos recurrir al

análisis en tiempo real de los mensajes CAN que se están transmitiendo (Figura 33), y ahí se puede

observar que los mensajes CAN se activan cuando es oportuno.

Figura 33: Análisis en tiempo real de los mensajes CAN durante el caso TC_2.

F. Test de activación de las luces cortas.

Este test consiste en la comprobación de la activación de las luces cortas derecha e izquierda mediante la

activación manual del Podium. Las especificaciones concretas son las siguientes:

“En caso de que el master switch se encuentre activo y se reciba por entrada digital interna de

Podium la orden de encendido de la luz corta derecha e izquierda, se publicará por salida digital

(CN103.10 Power66 delantero) (CN103.11 Power66 delantero) la orden de encendido de la luz

corta derecha e izquierda. “

Tabla VI: Tabla de verdad de las luces cortas

MS (DO)

Activation Order (Podium)

Activation order L. (DO)

Activation order R. (DO)

0 0 0 0

0 1 0 0

1 0 0 0

1 1 1 1

Para ello se elaboran 4 casos de uso sencillos. En el primero las luces están desactivadas, y se comprueba

que las salidas están a ‘0’. Tras ello, para los siguientes casos se activan las luces, comprobándose en el

segundo y en el tercer caso que funcionen las luces derecha e izquierda por separado respectivamente, y

en el último que funcionen ambas luces simultáneamente. El test sería el siguiente:

export testcase TC2_1() {

testCaseTitle(PV2Title, "TC_1");

testCaseDescription("Test de luz corta");

NUSUR_ActivarCarga(Digital_LuzCortaDrc, Relay_LuzCortaDrc);

NUSUR_ActivarCarga(Digital_LuzCortaizq, Relay_LuzCortaIzq);

TestType10("NO ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaDrc, 0, "ID:2_1 ", "Pin luz corta

derecha");

TestType10("NO ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaizq, 0, "ID:2_1 ", "Pin luz corta

izquierda");

}

export testcase TC2_2() {

testCaseTitle(PV2Title, "TC_2");

testCaseDescription("Test de luz corta");

NUSUR_ActivarCarga(Digital_LuzCortaDrc, Relay_LuzCortaDrc);

NUSUR_DesactivarCarga(Digital_LuzCortaizq, Relay_LuzCortaIzq);

TestType10("ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaDrc, 1, "ID:2_2 ", "Pin luz corta derecha");

TestType10("ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaizq, 0, "ID:2_2 ", "Pin luz corta izquierda");

}

export testcase TC2_3() {

testCaseTitle(PV2Title, "TC_3");

testCaseDescription("Test de luz corta");

NUSUR_DesactivarCarga(Digital_LuzCortaDrc, Relay_LuzCortaDrc);

NUSUR_ActivarCarga(Digital_LuzCortaizq, Relay_LuzCortaIzq);

TestType10("ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaDrc, 0, "ID:2_3 ", "Pin luz corta derecha");

TestType10("ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaizq, 1, "ID:2_3 ", "Pin luz corta izquierda");

}

export testcase TC2_4() {

testCaseTitle(PV2Title, "TC_4");

testCaseDescription("Test de luz corta");

NUSUR_ActivarCarga(Digital_LuzCortaDrc, Relay_LuzCortaDrc);

NUSUR_ActivarCarga(Digital_LuzCortaizq, Relay_LuzCortaIzq);

TestType10("ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaDrc, 1, "ID:2_4 ", "Pin luz corta derecha");

TestType10("ACTIVAR LUCES CORTAS", 5000, Digital_LuzCortaizq, 1, "ID:2_4 ", "Pin luz corta izquierda");

}

A continuación, los resultados de estos cuatro se muestran en las Figuras 34, 35, 36 y 37.

Figura 34: TC_1, test de luces cortas desactivadas.

Figura 35: TC_2, test de luz corta derecha activada e izquierda desactivada.

Figura 36: TC_3, test de luz corta izquierda activada y derecha desactivada.

Figura 37: TC_4, test de luces cortas activadas.

A partir de estos resultados se deduce que la luz izquierda funciona correctamente pero que la derecha no

es capaz de activarse. Analizando en profundidad el sistema es fácil encontrar el punto de fallo.

Observando la placa de cargas durante la realización del test, se comprueba que el LED correspondiente de

no llega a encenderse del todo, si no que solo hay una leve luz difícil de apreciar. Por esto, se concluye que

en este caso el problema está en el circuito interno de la placa de cargas pero que la luz corta derecha

funciona correctamente. Esto se puede observar en la siguiente imagen tomada durante la realización del

test (Figura 38):

Figura 38: Imagen tomada durante la realización de los test, del LED correspondiente a la luz corta derecha.

G. Test de activación de los intermitentes.

Este test se realiza del mismo modo tanto para los intermitentes derechos como para los izquierdos. Como

son exactamente iguales, se comentará el test realizado a los intermitentes derechos exclusivamente, pero

los casos son los mismos para los izquierdos. El vehículo posee dos intermitentes de cada lado, uno trasero

y uno delantero. Las especificaciones concretas son las siguientes:

“En caso de que el master switch se encuentre activo y se reciba por entrada digital interna de

Podium la orden de encendido de la luz intermitente derecho o el interruptor de luces de

emergencia, se publicará por salida digital la orden de encendido del intermitente derecho

(delantero y trasero) con período de 700ms y un ciclo de trabajo del 50%.”

Tabla VII: Tabla de verdad del intermitente derecho.

MS (DO)

Activation Order

(Podium)

Activation order Rear Right

(DO)

Activation order Front Right

(DO)

0 0 0 0

0 1 1 1

1 0 0 0

1 1 1 1

Para ello, se han diseñado cuatro casos de uso posibles: uno con los dos intermitentes conectados

simultáneamente, después dos comprobando el intermitente trasero y el intermitente delantero por

separado, y finalmente uno en el cual ambos funcionan correctamente a la par. El código desarrollado es el

siguiente:

export testcase TC9_1 ()

{

testCaseTitle(PV9Title, "TC_1");

NUSUR_ActivarCarga(Digital_IntermitenteDrchDl, Relay_IntermitenteDrchDl);

NUSUR_ActivarCarga(Digital_IntermitenteDrchTr, Relay_IntermitenteDrchTr);

TestType10("NO PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchDl, 0, "ID:9_1 ", "Pin

fisico intermitente derecho delantero");

TestType10("NO PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchTr, 0, "ID:9_1 ", "Pin

fisico intermitente derecho trasero");

}

export testcase TC9_2 ()

{

testCaseTitle(PV9Title, "TC_2");

NUSUR_DesactivarCarga(Digital_IntermitenteDrchDl, Relay_IntermitenteDrchDl);

NUSUR_ActivarCarga(Digital_IntermitenteDrchTr, Relay_IntermitenteDrchTr);

TestType10("PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchDl, 0, "ID:9_2 ", "Pin fisico

intermitente derecho delantero");

TestType10("PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchTr, 1, "ID:9_2 ", "Pin fisico

intermitente derecho trasero");

}

export testcase TC9_3 ()

{

testCaseTitle(PV9Title, "TC_3");

NUSUR_ActivarCarga(Digital_IntermitenteDrchDl, Relay_IntermitenteDrchDl);

NUSUR_DesactivarCarga(Digital_IntermitenteDrchTr, Relay_IntermitenteDrchTr);

TestType10("PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchDl, 1, "ID:9_3 ", "Pin fisico

intermitente derecho delantero");

TestType10("PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchTr, 0, "ID:9_3 ", "Pin fisico

intermitente derecho trasero");

}

export testcase TC9_4 ()

{

testCaseTitle(PV9Title, "TC_4")

NUSUR_ActivarCarga(Digital_IntermitenteDrchDl, Relay_IntermitenteDrchDl);

NUSUR_ActivarCarga(Digital_IntermitenteDrchTr, Relay_IntermitenteDrchTr);

TestType10("PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchDl, 1, "ID:9_4 ", "Pin fisico

intermitente derecho delantero");

TestType10("PULSAR INTERMITENTE DERECHO", 5000, Digital_IntermitenteDrchTr, 1, "ID:9_4 ", "Pin fisico

intermitente derecho trasero");

}

Como se puede observar fácilmente, tras activar las cargas correspondientes, se comprueba que estén

desactivados ambos intermitentes, luego que esté activado solo el trasero, luego que esté activado siempre

el delantero, y finalmente que estén activados ambos simultáneamente. Los resultados son los de las

Figuras 39, 40, 41 y 42:

Figura 39: TC_1, intermitentes derechos desactivados.

Figura 40: TC_2, intermitente derecho trasero activado y delantero desactivado.

Figura 41: TC_3, intermitente derecho delantero activado y trasero desactivado.

Figura 42: TC_4, los dos intermitentes derechos activados simultáneamente.

Figura 43: Resultado de todos los test de intermitentes, tanto derechos como izquierdos.

A raíz de la última imagen se puede apreciar que solo se superan la mitad de los casos. Esto se debe a que

la señal que proporcionan los intermitentes es una señal, como bien indica su nombre, intermitente.

Entonces, dependiendo de si en el momento de tomar la medida el intermitente está encendido o no, el

test da un resultado u otro. Repitiendo el test múltiples veces se puede observar que los resultados

difieren, y que aproximadamente se validan el 50% de los casos cada vez que se lanza el test. Teniendo en

cuenta que los test fallidos se deben a esto, podemos considerar con total seguridad que los intermitentes

funcionan correctamente.

Anexo 4: Hardware.

En este apartado se describirán los cuatro elementos principales de Hardware utilizados en el sistema.

A. Podium.

El Podium es un salpicadero ergonómico y modular que cumple los estándares europeo VDC 234 e ISO

16121-3 y que consiste de las siguientes partes:

- Una parte central principal formada por la columna de dirección ajustable, lo que permite una

mejor adaptación al conductor, un volante y los interruptores de mando.

- Instrumentación con capacidades MMI (Multi Media Interface) que mejoran la interacción con el

conductor (Multic 2).

- Interruptores de mando en la parte derecha e izquierda.

- Espacio disponible para un sistema público de transporte, espacio para un selector de marchas

(DNR), hasta cuatro pulsadores para la apertura de puertas y un interruptor giratorio para la

activación de las luces exteriores.

- Sistema de anclaje con el Chasis.

- Interruptores y pulsadores de control con el sistema de led integrado.

El Podium 200 (Figura 44) está equipado con un nuevo Multic en la parte central que cuenta con un display

cuya gestión grafica es gestionable, lo que permite la personalización de la misma por parte del usuario.

Figura 44: Podium.

El Podium 200 dispone de cinco buses CAN J1939 de comunicación. En cada bus CAN se puede realizar alguna de las siguientes acciones:

- Conexionado con un bus CAN J1939 externo a través del cual se gestionarán las comunicaciones con el mismo.

- Conexión con módulos esclavos de potencia a través de un bus CAN independiente. Esta conexión se realiza a través de comunicación CAN de 11 bits. Esto módulos sirven básicamente para la lectura de entradas y activación de salidas. Las entradas pueden ser de diferentes tipos: digitales, analógicas (medida de tensión y resistencia) y de frecuencia. En lo que respecta a las salidas estas pueden ser digitales, analógicas (valor de tensión variable) y PWM (valor de frecuencia y ciclo de trabajo).

También posee integrados de los que disponen las placas para la ejecución del software:

- Microcontrolador MPC 566K: para la gestión de la aplicación y cableado. Esto incluye las funciones desarrolladas, la lectura de las entradas y activación de salidas de las que dispone el Podium, de la gestión de los módulos esclavos y de las comunicaciones J1939 con otros buses de campo.

- FPGA Spartan 6: para la gestión de la parte grafica desarrollada en Embedded Wizard.

B. Power 66.

En el sistema se utilizan tres Power 66 (Figura 45), son las denominadas ECUs (Engine Control Unit). Con

ellas se establece la comunicación entre el Podium y los diferentes sensores y actuadores.

Figura 45: Power 66.

Las Power 66 son unidades de control electrónico incorporadas en el vehículo, dedicadas para su aplicación

en vehículos industriales. Pueden funcionar como una ECU independiente o pueden integrarse en la

arquitectura electrónica de un MultiBus o un ActiMux gracias a la transferencia por bus CAN.

Características principales:

- Tensión de alimentación de 24 V

- Opera entre -40ºC y +70ºC

- 23 entradas lógicas, analógicas y frecuenciales.

- 32 salidas lógicas

- 8 salidas de puente H

- 1 canal CAN a 250 kbaud, ISO 18898

- 3 salidas analógicas de 20 mA

- 1 fuente para sensores de 250 mA

Aplicaciones más comunes:

- Control del alumbrado interior y exterior. Iluminación LED.

- Control del limpiaparabrisas y su motor de agua

- Control climático

- Control del sensor de aceite

- Control de puertas en autobuses urbanos

- Control de niveles de tensión del vehículo.

C. VT System.

El VT System (Figura 46) es como se denomina a la unión de varios módulos VT. En este sistema se han

utilizado los siguientes:

- 1 x 19’’ subrack VT System 84 HP - 1 x VT8012 – Backplane - 2 x VT2004A – Simulador de salidas analógicas para simular sensores - 1 x VT7001A – Alimentación de las unidades de control - 2 x VT2820 – Relés - 2 x VT2848 – Salidas y entradas digitales - 1 x VT8920 – Alimentación del HIL

Además del módulo de alimentación, en la realización de estos test se utilizan dos módulos principales. Los

dos VT2820 son módulos de activación de relés. Mediante ellos se activan o desactivan las cargas que se

quieren utilizar en cada caso. Los otros más utilizados son los VT2848. Estos son las entradas y salidas

digitales del sistema, y son las señales que se utilizan en todos los test.

Figura 46: Sistema VT que se utiliza en este proyecto.

D. Placa de cargas.

La placa de cargas (Figura 47) sirve para simular el comportamiento resistivo de los actuadores de un

vehículo, para que los Power 66 no se bloqueen. Tiene en total 39 resistencias de 120, 160 y 480 ohms.

Estas resistencias tienen que soportar una corriente mínima para poder “engañar” a los Power 66 y que

“piensen” que tienen conectada la carga que se supone que tienen que controlar.

Figura 47: Placa de cargas.

A parte de las propias cargas también se han implementado unos Leds para visualizar las cargas activadas y

las no activadas. Estos Leds también cumplen una función de verificación ya que es posible demostrar con

ellos que las cargas están bien conectadas.

Anexo 5: Valoración económica.

Con el fin de detallar los costes de este proyecto, se elabora una tabla de costes del mismo. Como todo el

equipo se suministra por la empresa, el resultado final es el cómputo de las horas trabajadas.

Concepto Precio

Hardware (Pódium, VT System, Placa de Cargas, ECU, rack, cableado) Suministrado por la empresa

Software (CANoe, vTestStudio) Suministrado por la empresa

Ordenadores Suministrados por la Universidad

Horas de estudio y preparación: 60 300 €

Horas de desarrollo del proyecto: 250 1250 €

Se estima un precio por hora de 5 € por lo que el coste total sería de 1650 €.