SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE...

SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN

Proyecto Final de Carrera

TITULACIÓN: Ingeniero Técnico Industrial en Electrónica Industrial

AUTOR: Pedro Ceferino López Martín.

DIRECTOR: Ángel Cid Pastor.

FECHA: Junio / 2015.

Índice General 1 Introducción ....................................................................................................... 6

2 Objetivos .......................................................................................................... 19

3 Descripción del Sistema de Test Automático AUTOTESTER_GEN2 ....... 21

3.1 Esquema General del Sistema .................................................................... 21

3.2 Diferentes Elementos del Sistema ............................................................. 21

3.2.1 Fuente de Alimentación (Power Supply) ............................................... 22

3.2.2 Cámara Climática (Climatic Chamber) .................................................. 22

3.2.3 Carga Electrónica (Electronic Load) ...................................................... 23

3.2.4 Sistema de PLC ...................................................................................... 23

3.2.5 Tarjetas y Sistemas de Relés del Equipo (Relay Boards) ...................... 24

3.2.6 Conectores del Equipo (Connectors)...................................................... 25

3.2.7 Arnés de Cableado (Wiring Harness) ..................................................... 25

3.2.8 BCM (Body Control Module) ................................................................ 25

3.2.9 PC con Software CANoe de VECTOR e Interfaz CAN Case ............... 26

3.3 Configuración del Sistema ......................................................................... 33

4 Fases de Desarrollo del Proyecto ................................................................... 34

4.1 Validación Inicial del Hardware ................................................................ 35

4.1.1 Comprobaciones ..................................................................................... 35

4.2 Programación del Sistema de PLC ............................................................ 35

4.2.1 Creación y Asignación de las Tramas de CAN del Sistema de PLC ..... 35

4.2.2 Programación del PLC en su Software Específico................................. 36

4.3 Modificaciones en el Hardware ................................................................. 38

4.3.1 Corregir Pines sin continuidad ............................................................... 38

4.3.2 Sustitución de una Tarjeta de Relés ....................................................... 38

4.3.3 Soldar Conector a Tarjeta de Comunicaciones ...................................... 38

4.3.4 Cableado del Módulo de Comunicaciones CAN ................................... 38

4.3.5 Recableado de Varias Señales de las Tarjetas Multiplexoras ................ 38

4.3.6 Sistema de Control de Polaridad de la Carga Electrónica ...................... 38

4.3.7 Sustitución de un Módulo de señales PLC Erróneo ............................... 38

4.3.8 Módulo CAN del PLC Defectuoso ........................................................ 38

4.3.9 Retrabajo en Módulos de PLC (Sustitución Resistencias SMD) ........... 38

4.3.10 Divisores de Tensión Añadidos en Módulo del PLC ........................... 38

4.3.11 Sustitución Potenciómetros Módulos de Entradas Analógicas ............ 38

4.3.12 Relé Desconexión Terminal Común de Módulos del PLC .................. 38

2

4.4 Validación Completa del Hardware ........................................................... 39

4.5 Panel de Control de CANoe ....................................................................... 39

4.6 Adaptación a un Proyecto Específico ........................................................ 40

4.6.1 Creación del Arnés de Cableado para el Nuevo Proyecto ..................... 40

4.6.2 Creación de los Archivos Necesarios para el Nuevo Proyecto .............. 41

5 Planificación del Tiempo ................................................................................ 42

6 Conclusiones .................................................................................................... 44

Referencias ................................................................................................................ 48

3

Índice de Figuras

Figura 1. “Setup” Validación Funcional Manual ....................................................... 8 Figura 2. Posible secuencia de Validación Funcional de una BCM ........................ 9 Figura 3. “Setup” Validación Funcional Semiautomática ....................................... 11 Figura 4. “Setup” Validación Funcional Automática .............................................. 14 Figura 5. Adaptación a un Nuevo Proyecto del Equipo ......................................... 16 Figura 6. Objetivo Principal del Presente Proyecto ............................................... 19 Figura 7. Objetivos Concretos del Presente Proyecto ............................................ 20 Figura 8. Diagrama de Bloques del Equipo ........................................................... 21 Figura 9. Interacción PLC-Instalación ................................................................... 24 Figura 10. Estructura Básica de un PLC .................................................................. 24 Figura 11. Desarrollo de un Ciclo de Transmisión de Datos ................................... 29 Figura 12. Modelo de Interconexión de Sistemas Abiertos OSI ............................. 30 Figura 13. Formato Trama de Datos CAN ............................................................... 31 Figura 14. Configuración del Bus CAN para Evitar Fuentes Parásitas ................... 33 Figura 15. Fases de Desarrollo del Proyecto............................................................ 34 Figura 16. Estados de Funcionamiento del PLC ...................................................... 36 Figura 17. Diagrama de Flujo Modo RUN .............................................................. 37 Figura 18. Planificación Temporal en Lear ............................................................. 42

4

Índice de Tablas

Tabla 1. Velocidades de Transmisión……………………………………………….31

5

Introducción

1 Introducción

Este proyecto de final de carrera se ha desarrollado en la empresa LEAR Corporation Holding Spain SLU. Concretamente en el departamento de Hardware de la planta de Valls que está localizada en la calle Fusters (pg ind Valls), 54 de Valls (Tarragona).

LEAR es una compañía con productos de clase mundial diseñados, desarrollados y

fabricados por un equipo diverso de empleados. Proveedora líder de sistemas de gestión de energía eléctrica (Lear Electrical Power Management Systems) y asientos de automóviles (Lear Seating).

Lear Electrical Power Management Systems: LEAR es líder para los fabricantes

de automóviles de todo el mundo. Brinda a sus clientes las mejores ideas, la innovación en la industria y la tecnología más avanzada entregada por el mejor equipo de la industria.

Lear Automotive Seating: LEAR es líder mundial en Automotive Seating. Es uno

de los únicos fabricantes del mundo que ofrecen una solución completa en módulos de asientos con todo integrado, tiene un historial probado en la entrega de sistemas de asientos de calidad para la industria del automóvil a precios competitivos. Lear, trabaja con todos los fabricantes de todo el mundo, suministrando asientos completos para los programas que van desde el coche de mayor volumen y las plataformas de camiones hasta aplicaciones específicas para coches de gama alta y de vehículos de alto rendimiento.

LEAR atiende a sus clientes con las capacidades globales al mismo tiempo que

mantiene el compromiso individual. Con sede en Troy, Michigan, Lear mantiene 221 ubicaciones en 36 países de todo el mundo y emplea a aproximadamente 115,000 empleados. Lear se cotiza bajo el símbolo [LEA] en la Bolsa de Valores de Nueva York. Es uno de los cuatro proveedores con capacidad de proveer sistemas completos, tanto en sistemas de distribución eléctrica de alta potencia, como en sistemas tradicionales y en todas las partes del mundo. Combina su conocimiento total de los sistemas con una huella de bajo coste para llevar a sus clientes los mejores productos en su clase a un precio excepcional.

Sus principales clientes son: NISSAN, RENAULT VI, VOLVO, FORD, JAGUAR,

DAF, SEAT, SAAB, RENAULT, MITSUBISHI, ROVER, BMW, PSA, GM-OPEL, MERCEDES-BENZ Y CHRYSLER.

Posee certificaciones de calidad: TS 16949, ISO 9001, QS 9000, ISO 14001. Lear además se preocupa mucho de buscar reclutar, contratar y retener a los mejores

empleados de todos los orígenes en todo el mundo. Sabe que la diversidad es un buen negocio, asegurándose de tener el mejor talento disponible para mantener así su ventaja competitiva. Lear reconoce que la integridad y el respeto proporcionan una piedra angular de todo lo que se hace.

Dentro de las competencias de LEAR antes mencionadas este proyecto pertenece a la

sección Lear Electrical Power Management Systems y se ha desarrollado en el laboratorio de Hardware. Una de las tareas que se realizan en el laboratorio de Hardware es la validación funcional de piezas, a las que nos referiremos como DUT (Device Under Test), dispositivos que en nuestro caso serán BCM (Body Control Modules).

6

Introducción

Body Control Module es un término genérico para una unidad electrónica de control responsable de la supervisión y el control de varios dispositivos de un vehículo. Normalmente en un coche la BCM controla las ventanas eléctricas, espejos eléctricos, aire acondicionado, sistema inmovilizador, cierre centralizado, etc. La BCM se comunica con otros ordenadores de a bordo a través del bus de comunicaciones del vehículo.

Una validación funcional es un procedimiento en el que se comprueba que una BCM

funciona correctamente, pare ello se analizan una a una todas y cada una de las funcionalidades de dicha BCM.

En un principio estas validaciones se realizaban de manera completamente manual (y

se siguen realizando en muchos casos). De la evolución y para el perfeccionamiento y optimización de este proceso surge este proyecto. A continuación se explica la evolución y las diferentes etapas de esta que nos llevan hasta nuestro proyecto en sí, el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN.

1.1 Validación Funcional Manual

Una validación funcional manual es un procedimiento en el que se analizan, una a una,

todas y cada una de las funcionalidades de una BCM de manera manual con el fin de asegurarnos o comprobar que la pieza funciona correctamente.

Para ello se usa un panel llamado Panel de Cargas. Este panel simula la parte del

vehículo que es controlada por la pieza a testear y está formado por una serie de cargas, una serie de sistemas de interruptores, pulsadores, etc., que son equivalentes a las cargas que tendríamos en el vehículo y también a sus sistemas de activación, pudiendo así manipular todas las “Inputs”, las “Outputs” tanto individualmente cómo en forma de test y de combinaciones más complejas y por lo tanto pudiendo comprobar de esta manera el correcto funcionamiento de todas las funcionalidades de nuestra pieza.

La BCM se conecta al Panel de Cargas a través de un cableado (Wiring Harness)

equivalente al que se usaría en el vehículo y también a un PC con el software CANoe de VECTOR con el que se comunica por medio de protocolo de comunicaciones CAN.

De esta manera se puede controlar el sistema tanto desde el Panel de Cargas, mediante

la manipulación de interruptores, pulsadores, puentes etc., como desde el PC, mediante la manipulación del software de control específico para cada proyecto programado en CANoe y su interfaz gráfica. Así como visualizar el funcionamiento o estado de cada señal también tanto desde el Panel de Cargas, por medio de la visualización del estado de bombillas, leds, conmutación de relés, activación de motores, etc., como desde el PC, a través de CANoe, que nos permite ver el estado de algunas señales tanto a nivel visual como a nivel de variables que representan las diferentes señales. Con lo que es posible conocer su estado en cada momento, pudiendo comprobar así que el funcionamiento de la BCM es el correcto.

En la Figura 1 se puede ver el esquema de la configuración de un “setup” usado para

realizar validaciones funcionales de piezas. En la figura se pueden diferenciar el Panel de Cargas, el Cableado (con sus distintos conectores C1, C2,…,Cx), la BCM, el cableado del

7

Introducción

bus CAN, la CAN Case, que es un dispositivo de “hardware” que sirve para interconectar el bus de comunicaciones CAN con el PC, además, este dispositivo es el que contiene el tipo de licencia que usará el programa CANoe de VECTOR al iniciarse, y por último el PC (por supuesto para alimentar el sistema es necesaria una fuente de alimentación o una batería, no mostradas en la figura).

Figura 1. “Setup” Validación Funcional Manual

Como se puede observar en la figura, se trata de una validación completamente

manual en la que a través de la manipulación del Panel de Cargas y el control del panel de CANoe desde el PC se realizan toda una serie de pasos para comprobar todas las funcionalidades de la pieza (BCM).

En la Figura 2 se puede ver un posible diagrama de bloques de los pasos a seguir para realizar una validación funcional. Aunque no necesariamente tienen que suceder en ese orden.

8

Introducción

Figura 2. Posible secuencia de Validación Funcional de una BCM

Tal y como indica el diagrama de ejemplo de la Figura 2 primero se comprueban que

todos los fusibles de la BCM están colocados y en buen estado. En un principio se comprueba que físicamente están conectados los que corresponden y después se comprobará su correcto funcionamiento al activar la señal correspondiente a cada fusible (ya sean “inputs” u “outputs”), si al activar una salida que dispone de fusible, esta no funciona, lo primero a comprobar será que dicho fusible se encuentre conectado y en buen estado.

A continuación se comprueban una a una todas las entradas (“inputs”) de la BCM.

Empezando por las entradas digitales y acabando por las entradas analógicas. Para ello se activan los interruptores o pulsadores del Panel de Cargas (panel físico) manualmente y se comprueba desde el panel de control de CANoe (interfaz software) correspondiente a nuestro proyecto que la correspondiente entrada se está activando correctamente. Además de poder visualizar el correcto funcionamiento de las entradas en el panel de CANoe, es decir en la interfaz gráfica de nuestro software de control, también veremos la activación física de las salidas que estén asociadas a las entradas que estemos activando, generalmente serán bombillas que se encenderán. Estas bombillas, no tienen por qué corresponder siempre a luces del vehículo, ya que en muchas ocasiones simularán otras cargas, que a pesar de no ser luces, sí tendrán un valor equivalente. En el caso de las entradas analógicas además de activar el pulsador o interruptor correspondiente podemos seleccionar varios valores de resistencia en la entrada por medio de potenciómetros, para comprobar el correcto funcionamiento con los diferentes valores de uso.

El siguiente paso es la comprobación de todas las salidas (“outputs”) de la BCM que

están conectadas al Panel de Cargas. Para ello se activan una a una todas las salidas una a una desde nuestro panel de CANoe (software) comprobando que se activa la salida correspondiente, también comprobando todo el rango de funcionamiento en el caso de las salidas PWM, seleccionando diferentes valores. Evidentemente también podemos activar las salidas correspondientes activando la entradas que tengan asociada la activación de dichas salidas.

Otro paso sería comprobar las comunicaciones, comprobar que las comunicaciones

funcionan correctamente. Dependiendo del proyecto puede constar de comunicaciones CAN, LIN, FLEXRAY, ETHERNET, etc. solo alguna de ellas o una combinación de ellas. Básicamente se trata de comprobar que existe comunicación haciendo varias pruebas.

Por último habría que realizar una serie de test especiales. En este grupo entraría

cualquier test que se realice para validar funcionalidades de la BCM que no se puedan comprobar de una manera directa y sencilla, sino que requieren de una secuencia específica unas o condiciones previas para llevarlos a cabo, o test que comprueben una serie características simultáneamente. En general cualquier test que sea específico o requiera de un procedimiento específico para llegar a validar la funcionalidad completa de una BCM.

FUSES INPUTS OUTPUTS COMMUNICATIONS SPECIAL TESTS

9

Introducción

Estos test pueden variar dependiendo de cada proyecto. Pueden ser test de consumos en ciertas condiciones o en ciertos modos de funcionamiento, test de partes específicas del vehículo con funcionamiento complejo, etc.

Además de la realización de una validación funcional completa en la que se comprueba

la funcionalidad completa de la pieza a validar, esta validación puede requerir ser realizada en diferentes condiciones, como pueden ser a diferentes temperaturas o con diferentes tensiones de alimentación, para asegurar el correcto funcionamiento de la pieza en las diferentes condiciones en las que se podría encontrar la pieza en situaciones reales, como pueden ser situaciones climatológicas extremas o estado de la batería con exceso o defecto de carga. En dicho caso sería necesario realizar la validación completa varias veces en las diferentes condiciones. Un caso habitual sería una validación completa a tres tensiones y tres temperaturas. En este caso, básicamente se trataría de realizar 9 validaciones completas:

- A temperatura mínima con tensión mínima de funcionamiento. - A temperatura mínima con tensión normal de funcionamiento. - A temperatura mínima con tensión máxima de funcionamiento. - A temperatura ambiente con tensión mínima de funcionamiento. - A temperatura ambiente con tensión normal de funcionamiento. - A temperatura ambiente con tensión máxima de funcionamiento. - A temperatura máxima con tensión mínima de funcionamiento. - A temperatura máxima con tensión normal de funcionamiento. - A temperatura máxima con tensión máxima de funcionamiento.

Hay que destacar que para cada proyecto es necesario un Panel de Cargas específico con unas cargas fijas, ya que evidentemente este panel está adaptado para ese proyecto en concreto y simula la parte del vehículo que iría conectada a una serie de BCM de un proyecto específico y por lo tanto se conectan por medio de su cableado específico de proyecto. A pesar de ser un sistema automático pretende ser también genérico y adaptable a otros proyectos de LEAR, como se explicará más adelante.

En el caso del proyecto adaptado, estamos hablando de un proyecto de complejidad

alta cuyo número de señales a tratar es bastante elevado. El tiempo de validación por unidad, en un proyecto de esta complejidad, es de entre dos a tres horas aproximadamente, teniendo en cuenta que no se produzca ningún problema a la hora de realizar la validación y por supuesto realizándolo únicamente a una tensión y una temperatura. En el caso de necesitar realizar una validación funcional completa a tres tensiones y tres temperaturas de una BCM, el tiempo necesario para llevarla a cabo en el caso más optimista de 2 horas por unidad sería de 18 horas, sin contar el tiempo necesario de la cámara climática para llegar a la temperatura requerida.

Es evidente que es un gran inconveniente la cantidad de tiempo necesario para realizar estas validaciones y que cualquier reducción, por pequeña que fuera, en el tiempo necesario para llevar a cabo este proceso supondría un gran ahorro de tiempo ya que ese tiempo se multiplicaría por cada unidad a validar. Con la consecuente repercusión en los costes para la empresa.

10

Introducción

Con el fin de solucionar este problema y reducir el tiempo necesario para llevar a cabo una validación funcional completa, un equipo de LEAR creó un sistema de validación funcional semiautomático.

1.2 Validación Funcional Semiautomática

Con la finalidad de reducir el tiempo necesario para realizar una validación funcional completa, el equipo de LEAR creó el sistema de validación funcional semiautomático.

Este equipo en fue creado para un proyecto específico, y trata de automatizar al

máximo el proceso de validación. De manera que apretando un solo botón, se inicie una secuencia que comprobará la mayor parte de las funcionalidades de una BCM de manera automática.

Esto se consigue por medio de añadir un PLC (Controlador Lógico Programable) a

nuestro sistema de validación manual, más concretamente al Panel de Cargas. Más adelante se explicará que es un PLC en mayor profundidad, pero básicamente, una vez programado, se encargará de activar y desactivar todas las entradas de la BCM a validar, así como sensar el estado de algunas salidas, gracias a sus distintos módulos y a su capacidad de comunicarse por protocolo de comunicaciones CAN. De esta manera el PLC será controlado desde el PC por medio del panel específico para el proyecto en cuestión programado en el software de CANoe de VECTOR.

En la Figura 3 se puede ver el esquema de la configuración del “setup” de un sistema

de validación funcional semiautomático. Como se puede observar es prácticamente el mismo equipo que el usado para la realización de validaciones manuales pero con el sistema de PLC añadido.

Figura 3. “Setup” Validación Funcional Semiautomática

11

Introducción

Como se puede ver en la figura, gracias a este equipo se consigue automatizar aproximadamente un 85% el proceso de validación, teniendo que realizar el 15% restante de manera manual. A pesar de no ser completamente automático este equipo consigue una gran reducción en el tiempo de validación por unidad, pasando de las dos a tres horas necesarias para realizar una validación manual a unos 15 minutos por pieza aproximadamente.

Además, de la parte automatizada, al acabar la validación, se obtienen un informe en

un archivo “.xml” con los datos de todas las señales, donde quedará reflejado si todo ha funcionado correctamente, o que señales han fallado en el caso de que así haya sido. Por supuesto, si queremos obtener un informe completo se tendrán que añadir los resultados del 15% del proceso realizado manualmente.

A pesar de aportar una mejora realmente grande, este equipo sigue manteniendo ciertas

limitaciones. Estas limitaciones son las siguientes:

-Las cargas del panel no son reales. Las cargas del panel, que simulan las que encontraríamos en el vehículo, no son reales. Es decir, no son exactamente las mismas cargas que llevaría el vehículo, son cargas equivalentes, que están dentro de los rangos correctos de funcionamiento de cada señal. En los casos necesarios, hay varias cargas seleccionables, pero no son exactas.

Uno de los motivos a los que se debe esto es que, a pesar de ser un panel específico

para un proyecto en concreto, dentro de este proyecto existen una gran cantidad de variantes (diferentes modelos, diferentes años, etc.), en las que existen diferencias, ya sea porque se añaden funciones, porque algunas funciones no se usen, porque se hayan modificado características de alguna señal, etc. y a pesar de esto se usa el mismo Panel de Cargas para todas las variantes. Además las cargas no son modificables, lo que limita mucho las capacidades de test del equipo.

-El Panel de Cargas no es genérico. Cada Panel de Cargas está adaptado y es

específico para un proyecto. Entre otros motivos, debido a la limitación comentada en el punto anterior. Los paneles no pueden ser adaptados a diferentes proyectos, ya que para ello habría que cambiar toda la estructura, cantidad y ordenación de señales y modificar los valores de carga de cada señal. Lo que significa tener que crear un nuevo panel.

-El proceso de validación no es completamente automático. Esto supone varios

inconvenientes. Uno de ellos es que el tiempo necesario para realizar una validación completa es mayor, al necesitar realizar una parte del proceso de manera manual. Con el consecuente riesgo de que se cometan errores humanos. Además el informe que se genera de manera automática con los resultados de la validación no está completo, ya que evidentemente, solo constan los datos de la parte del proceso realizada automáticamente. -Configuración previa del Panel de Cargas necesaria. Antes de lanzar un test hay que configurar el Panel de Cargas para que el sistema de PLC pueda realizar los test de forma correcta. Esto es debido a que el panel que se usa es el mismo que el utilizado para realizar la validación de forma manual, por lo que es necesario colocar los interruptores y potenciómetros en la posición en la que el sistema de PLC pueda llevar a cabo el control del sistema.

12

Introducción

Con el propósito de eliminar todas estas limitaciones y obtener el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN óptimo nace el equipo de validación funcional automática en el que está basado este proyecto.

1.3 Validación Funcional Automática

La idea principal es crear un sistema completo desde cero, capaz de realizar validaciones de manera totalmente automática y que además sea adaptable a diferentes proyectos. Es decir como el propio nombre del proyecto indica, crear un SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN, que además, sea genérico.

Para conseguirlo la principal característica del equipo es el uso de una Carga

Electrónica. Una Carga Electrónica es un equipo electrónico capaz de simular cargas eléctricas,

que el usuario puede configurar o programar. Nos permite así someter cualquier sistema de alimentación a diferentes condiciones de carga. Generalmente se pueden usar fijando la corriente que atraviesa la carga, la resistencia de la carga, el voltaje hasta el que se quiere llegar (consumirá la corriente necesaria para llegar hasta dicho voltaje) o la potencia (la Carga Electrónica regulará la corriente para mantener la potencia constante).

Esta Carga Electrónica será la que simule todas las cargas que sean necesarias en

cada proyecto y será controlada en todo momento desde el PC por medio del software programado en el panel de CANoe (VECTOR). En este caso la comunicación entre el PC y la Carga Electrónica se realizará a través de la interfaz RS232.

Para poder dirigir todas las señales necesarias de la BCM a validar hacia la Carga

Electrónica se necesitan unas Tarjetas Multiplexoras (la Carga Electrónica solo puede simular una carga al mismo tiempo, por lo que se simularán las diferentes cargas de manera secuencial). Estas Tarjetas Multiplexoras permitirán ir conectando y desconectando una a una cada señal de la BCM a la Carga Electrónica en el momento indicado. Dichas tarjetas están compuestas por relés, hay de dos tipos distintos, han sido creadas desde cero para este proyecto y se explicarán en profundidad en los siguientes apartados.

Se mantiene el PLC como en el sistema de validación funcional semiautomático, pero

en este caso, añadiendo nuevos módulos, como los necesarios para controlar las Tarjetas Multiplexoras, entre otros necesarios para que la automatización del sistema sea completa.

Todo el sistema será controlado desde el PC por medio de un nuevo panel de control

programado en el software de CANoe de VECTOR (código e interfaz gráfica). Además, este panel de control de CANoe pretende ser lo más genérico posible, estando adecuado al hardware, es decir, siendo capaz de controlar toda la cantidad de señales disponibles en el hardware, a pesar de que evidentemente, no todas sean usadas para todos los proyectos. Este software programado en CANoe de VECTOR también será capaz de controlar automáticamente una Fuente de Alimentación, permitiendo variar la tensión, o cualquiera de los parámetros que nos ofrezca la Fuente de Alimentación usada, en cualquier momento.

13

Introducción

Así como una Cámara Climática, pudiendo así controlar también la temperatura de los test realizados en todo momento. El control se realizará a través de la interfaz RS232, de la misma manera que con la Carga Electrónica.

De esta manera nuestro SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS

HARDWARE DE AUTOMOCIÓN (AUTOTESTER_GEN2) tendrá la capacidad de realizar validaciones completas automáticas a cualquier tensión deseada, a cualquier temperatura (o perfil de temperatura), así como la capacidad de elegir la carga exacta deseada para todas y cada una de las señales de cualquier proyecto, lo que permitirá realizar las validaciones con valores de cargas máximos, mínimos, nominales o con cualquier valor puntual deseado.

Y todo esto permitiéndonos programar una secuencia de test completamente

automática, de la que al acabar se obtenga un informe con todos los resultados detallados. En la Figura 4 se puede ver el esquema de la configuración del “setup” del SISTEMA

DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN) en el que se basa el presente proyecto.

Figura 4. “Setup” Validación Funcional Automática

Gran parte del hardware se encontrará dentro de un panel físico, que será el que

disponga de todos los conectores necesarios para poder conectar cualquier BCM de cualquier proyecto que se desee adaptar a este sistema.

La cantidad de conectores (representados en la Figura 4 como C1, C2 y Cx) dependerá

de la capacidad de cantidad de señales a tratar por nuestro sistema, o dicho de otra manera, el equipo constará de tantos conectores como sean necesarios para tratar la totalidad de

14

Introducción

señales que el hardware sea capaz de controlar, a pesar de que no siempre se usarán todas, ya que según el proyecto del que se trate será necesario tratar un número mayor o menor de señales.

Como se puede ver en la figura, gracias a este equipo se conseguirá automatizar

completamente el proceso de validación, de manera que con solo apretar un botón, el equipo realizará toda la serie de test necesarios para completar una validación funcional de manera totalmente autónoma y automática.

Igual que en el sistema anterior, se obtendrá un informe en un archivo “.xml” con los

datos de todas las señales, donde quedará reflejado si todo ha funcionado correctamente, o que señales han fallado en el caso de que así haya sido.

Gracias a este sistema se consigue una increíble reducción en el tiempo de validación por unidad, pasando de los 15 minutos por pieza aproximadamente necesarios para realizar una validación con el equipo e validación semiautomático a unos 3 minutos por pieza aproximadamente (siempre hablando del mismo proyecto).

Por otro lado y como ya se ha comentado, este equipo, permite ser adaptado a

diferentes proyectos. Esto es gracias a la capacidad de la Carga Electrónica para simular todas las cargas que sean necesarias, gracias a la estructura del sistema y a estar este dimensionado para poder cubrir los proyectos más complejos de la empresa, así como a un software de control también genérico.

A la hora de adaptar un nuevo proyecto a nuestro SISTEMA DE TEST

AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN se tratará de un proceso relativamente sencillo en el que lo únicos pasos a seguir serán los siguientes:

-Generar un nuevo cableado para el nuevo proyecto. Se necesitará un cableado con

el que conectar las piezas a validar al nuevo equipo de test automático. Por lo tanto este cableado se definirá decidiendo a que parte del equipo se dirigirá cada una de las señales de la BCM del proyecto a adaptar. Dependiendo de qué tipo de señal sea y como sea necesario tratarla, cada señal será direccionada a su correspondiente lugar en el equipo de test, ya sea al módulo de PLC necesario, a la Tarjeta Multiplexora correspondiente, etc. De esta manera quedará definido a que pin y conector del panel del equipo se dirigirá cada señal y por lo tanto quedará definido así el nuevo cableado.

Para generar este cableado estudiarán las características y necesidades del proyecto a

adaptar así como se tendrán en cuenta las capacidades y características del equipo de test, para encontrar la mejor manera de evaluar cada señal que nos ofrezca el equipo. Pudiendo obtener de esta manera el proceso de validación mejor optimizado para cada proyecto. Esto es importante, ya que una vez se haya producido el cableado, será fijo, y supondrán esfuerzo, tiempo y coste innecesario tenerlo que readaptar.

-Generar los archivos necesarios para el nuevo proyecto. Se tendrán que crear los

archivos que contendrán toda la información necesaria para que el equipo de test automático lleve a cabo las validaciones de las BCM del nuevo proyecto a adaptar. Básicamente se trata de dos tipos de archivos con extensión “.csv” de los que el software obtendrá todos los datos.

15

Introducción

En uno de ellos, al que nos referiremos como Signals.csv, se encontrará toda la información necesaria para el tratamiento de las señales, nombres, conectores, relación entre señales de la BCM y punto del equipo al que van dirigidas (definida por el cableado creado para el proyecto), tramas de comunicación CAN para todas las señales, tanto de la BCM como del PLC, etc.

En el otro archivo, al que nos referiremos como Test_seq.csv, se encontrará toda la

información referente a los test a realizar. Es decir, es el archivo donde estarán definidas todas las secuencias de los diferentes test a realizar para que el equipo pueda completar una validación funcional. Dentro de este archivo estarán definidas todas las activaciones y desactivaciones de señales, tiempo de activación, etc. y varios parámetros de configuración de los elementos del equipo como pueden ser los parámetros de configuración de la Carga Electrónica o los parámetros de configuración de la Fuente de Alimentación para cada paso de test.

En la Figura 5 se puede ver el esquema de la configuración del “setup” del SISTEMA

DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN en el que se muestran los elementos que cambian a la hora de adaptar un nuevo proyecto.

Figura 5. Adaptación a un Nuevo Proyecto del Equipo

Todo este proceso de adaptación del equipo de test automático a un proyecto específico

se tratará en profundidad en la fase de desarrollo del presente proyecto. Gracias a este SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS

HARDWARE DE AUTOMOCIÓN se consiguen eliminar todas las limitaciones de las

16

Introducción

anteriores generaciones de sistemas de test, obteniendo un sistema capaz de realizar validaciones de una forma mucho más rápida y eficaz que además aporta nuevas ventajas.

Las ventajas del nuevo sistema son las siguientes:

-Capacidad de simular perfiles de carga reales. Gracias a la nueva configuración

del sistema y a la capacidad de la Carga Electrónica para simular cualquier carga eléctrica o cualquier perfil de carga eléctrica, el nuevo sistema permite simular a la perfección cualquier carga que podamos encontrar en un vehículo.

De esta manera se puede programar un perfil completo que simule cada carga real,

obteniendo así un resultado mucho más preciso al poder simular un comportamiento mucho más fiel al que se obtendría en un vehículo real. Añadiendo además la posibilidad de modificar la carga en cualquier momento, pudiendo hacer pruebas con distintas cargas para la misma señal, hacer test de corrientes máximas, mínimas, etc.

Gracias a esto este sistema no solo tiene la capacidad de validar el correcto

funcionamiento de una pieza, sino que además se convierte en una herramienta con capacidad de analizar los límites de funcionamiento de manera precisa y depurar posibles errores. Con lo que obtenemos un equipo con mayores prestaciones.

-Posibilidad de utilizar el equipo para diferentes proyectos. Esta nueva

configuración del sistema permite que el equipo pueda ser adaptado y utilizado para diferentes proyectos.

Esto supone una gran ventaja. En primer lugar porque permite reaprovechar el equipo.

Con los equipos anteriores, una vez ya no se necesitaba validar más piezas, el equipo quedaba en desuso, prácticamente inservible, ocupando espacio en algún almacén o en algún laboratorio por si en algún momento se necesitara validar alguna o varias piezas sueltas, por algún problema puntual. Con el consiguiente desaprovechamiento del equipo y el espacio necesario para almacenarlo. El nuevo equipo no solo permite poder reutilizarlo adaptándolo a un segundo proyecto una vez ya no sea usado para el primero, sino que también permite dar soporte a dos o más proyectos al mismo tiempo simplemente teniéndolo adaptado para dichos proyectos. Con lo que prácticamente con realizar el cambio del cableado se puede pasar de validar piezas de un proyecto a validar piezas de otro. Siempre que, lógicamente, no se requiera el uso del equipo a dedicación completa para un mismo proyecto por cuestiones de carga de trabajo. Esto permite, por ejemplo, tener un equipo preparado para dar soporte a varios proyectos diferentes en momentos puntuales en los que se produzca un pico en la carga de trabajo. Ahorrando así la necesidad de disponer de la gran cantidad de equipos que serían necesarios para dar soporte a eso proyectos.

Por lo tanto, esta capacidad del nuevo equipo para ser reutilizado en diferentes

proyectos hace que sean necesarios muchos menos equipos de validación. Lo que permite a su vez un gran ahorro de espacio, tanto del necesario para los paneles en uso, como del necesario para los paneles almacenados ya en desuso. Además permite retrasar la obsolescencia de los equipos, ya que un equipo que antes se desechaba, ahora con el nuevo equipo, se aprovechará para otro proyecto. Y a pesar de que los proyectos cada vez tienden a ser más grandes, al estar dimensionado para los proyectos más grandes de la actualidad, la

17

Introducción

vida útil del equipo se alarga enormemente, al poder ser utilizado por los proyectos “pequeños” de un futuro.

Por supuesto todas estas cualidades mencionadas se traducen directamente en un gran

ahorro de los costes. -Validación completamente automática. Otra de las ventajas del nuevo sistema es

que es capaz de realizar validaciones completas de manera totalmente automática. Lo que no solo es una ventaja por el hecho de la gran reducción en el tiempo de validación, además al ser completamente automático y proporcionar un fichero con un informe completo con los resultados al terminar, permite que la persona que ponga en marcha los test, pueda dedicarse a otras tareas mientras el equipo de test está en funcionamiento.

-Gran reducción en costes de desarrollo. Es evidente que muchas de las ventajas

mencionadas se traducen directamente en un gran ahorro de costes. Pero hay que destacar que este sistema también aporta una gran reducción de costes de desarrollo.

A la hora de desarrollar uno de los equipos de validación con panel de cargas fijo para

un proyecto nuevo, es necesario desarrollar el nuevo panel, revisarlo, comprobar que sea correcto y si es necesario depurarlo, desarrollar el cableado para el proyecto del que se trate (que solo será uno), revisarlo, comprobar que sea correcto y si es necesario depurarlo y desarrollar el software de control de CANoe depurarlo junto al panel y cableado ya correctos.

Gracias a la reusabilidad del nuevo equipo para nuevos proyectos se utilizaría el mismo

equipo, eliminándose así el desarrollo de un nuevo panel y un nuevo software. Siendo solo necesaria la creación de un nuevo cableado y los archivos de adaptación al nuevo proyecto como se ha explicado anteriormente.

18

Descripción del Sistema de Test Automático AUTOTESTER_GEN2

2 Objetivos

Lo que se pretende conseguir con el presente proyecto ha quedado implícito en lo

descrito en el punto anterior. No obstante se define explícitamente en el siguiente párrafo. El objetivo principal de este proyecto es conseguir una herramienta capaz de realizar

validaciones de hardware con el máximo nivel de automatización y con la máxima capacidad de ser adaptado para diferentes proyectos de LEAR de la manera más sencilla posible, sin por ello perder fiabilidad en los resultados (ver Figura 6). Obteniendo así un equipo o SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN como indica el propio nombre del proyecto. En concreto el hardware a validar por el equipo serán piezas BCM.

Como objetivo secundario se pretende adaptar este equipo de test a uno de los

proyectos de mayor complejidad de la empresa. Aunque, prácticamente, este es un objetivo implícito en el anterior, ya que, a pesar de ser un equipo adaptable a diferentes proyectos, requiere de la aplicación en uno de ellos para poder ser desarrollado y poder asegurar el correcto funcionamiento del equipo. Además de existir una necesidad urgente en la empresa de tener disponible esta herramienta para el proyecto en concreto, por motivos de cantidad de trabajo.

Figura 6. Objetivo Principal del Presente Proyecto

Por supuesto, para llegar a conseguir el objetivo principal y poder disponer de un

equipo de validación completamente funcional es necesario realizar una serie de pasos que podríamos definir como una serie de objetivos más concretos. Estos objetivos concretos son los siguientes:

-Programación del PLC. Se tiene que conseguir programar toda la serie de módulos

de PLC para que sea capaz de controlar todas las señales y funcionalidades del sistema. Una vez el sistema de PLC se encuentre programado, no se tendrá que volver a modificar, ni siquiera a la hora de adaptar un nuevo proyecto al equipo, ya que esta programación tendrá

19


en cuenta la capacidad total del sistema de PLC dejando este completamente funcional. Será el software de control desde el PC el que tenga en cuenta qué hay conectado en cada punto del PLC y cómo tratarlo.

-Hardware del Equipo de Test. Se tiene que conseguir crear la parte hardware del

equipo. Asegurando que funcione correctamente y sea capaz de llevar a cabo todas las acciones necesarias para realizar las validaciones. Para eso hay que comprobar que todas las partes del equipo están bien interconectadas, que no tengan fallos, que sean adecuadas para realizar la función que se espera de ellas, que no existan incompatibilidades, que trabajen bien en conjunto, etc. En definitiva, conseguir un hardware completamente funcional para el propósito del proyecto, que una vez creado y validado será fijo y no habrá que volver a modificar en ningún momento.

-Creación de los paneles de control de CANoe. Se tiene que conseguir crear todo el

software de control del equipo. Este se creará desde el programa CANoe de VECTOR donde se creará tanto el código como la combinación de paneles que forman la interfaz gráfica, desde dónde se controlará todo el sistema, se tratarán los diferentes archivos que proveen de la información específica de cada proyecto al sistema y se comprobarán los resultados.

-Adaptación a un proyecto específico. Por último se tiene que conseguir adaptar el

sistema a un proyecto específico, consiguiendo poder validar completamente todas las funcionalidades y test necesarios de dicho proyecto y pudiendo asegurar la fiabilidad del equipo al hacerlo.

En la Figura 7 se pueden ver los objetivos específicos mencionados.

Figura 7. Objetivos Concretos del Presente Proyecto

PLC PROGRAMMING

FUNCTIONAL HARDWARE

CANoe CONTROL

PANEL

SPECIFIC PROJECT

ADAPTATION

20


3 Descripción del Sistema de Test Automático AUTOTESTER_GEN2

En este apartado se detallan todas las partes de las que consta el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN llamado AUTOTESTER_GEN2 en el que se basa el presente proyecto.

3.1 Esquema General del Sistema En la Figura 8 se puede ver un diagrama de bloques en el que se representan todas las

partes de las que consta el sistema.

Figura 8. Diagrama de Bloques del Equipo

3.2 Diferentes Elementos del Sistema

A continuación se detallan los elementos de los que está compuesto el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN.

21


3.2.1 Fuente de Alimentación (Power Supply) Una fuente de alimentación es un dispositivo que convierte la corriente alterna (CA)

en una o varias corrientes continuas (CC) que serán las que alimenten los distintos circuitos del aparato electrónico al que se conecte, en nuestro caso a todo el sistema de test automático.

En este caso será la encargada de simular la batería que encontraríamos en el vehículo,

por lo tanto, alimentará todos los elementos que en el vehículo serían alimentados por la batería. Esto significa alimentar la BCM y todas las cargas que controle dicha BCM (que como ya se ha explicado serán simuladas por la Carga Electrónica) y en este caso, ya que no se trata de un vehículo real con todo el sistema real implementado, alimentará también, todos los elementos del sistema de simulación del vehículo.

En definitiva, la fuente de alimentación alimentará todo el SISTEMA DE TEST

AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN, a excepción de los elementos que dispongan de alimentación propia, como son el sistema de PLC, la Carga Electrónica (aunque evidentemente sí alimentará a la carga simulada por esta), la Cámara Climática y por supuesto el PC.

3.2.2 Cámara Climática (Climatic Chamber) Se define como Cámara Climática a un equipo de laboratorio capaz de reproducir en

su interior cualquier tipo de clima existente en cualquier lugar de la Tierra o del espacio accesible. Así, dentro de los climas naturales, podemos hablar de clima tropical, ártico, marciano, etc., aunque de igual modo se pueden recrear climas artificiales extremos que pueden presentarse en entornos no naturales.

En las cámaras climáticas inteligentes, las variables climatológicas se reproducen con

la máxima precisión y con capacidad suficiente para el almacenamiento y transmisión de datos, establecimiento de programas múltiples normalizados y autodiagnóstico.

Aplicaciones comunes:

- Simulación ambiental. - Envejecimiento acelerado. - Control de calidad. - Investigación de materiales y sistemas. - Estabilidad de productos. - Acondicionamiento en húmedo.

22


Características comunes:

- Diversas dimensiones y configuraciones. - Ejecución compacta o de construcción modular, en función del tamaño y aplicación. - Control preciso de temperatura y humedad relativa. - Posibilidad de simulación de ciclos climáticos. - Registro gráfico y almacenamiento de datos. En el caso del presente proyecto se utilizará una Cámara Climática para simular los

diferentes climas de las variadas situaciones ambientales en las que se pueden encontrar las piezas a validar (BCM) durante su vida útil dentro del vehículo. Asegurando así el correcto funcionamiento de todos los componentes y sistemas de la pieza.

3.2.3 Carga Electrónica (Electronic Load) Una Carga Electrónica es un equipo electrónico capaz de simular cargas eléctricas,

que el usuario puede configurar o programar. Nos permite así someter cualquier sistema de alimentación a diferentes condiciones de carga. Generalmente se pueden usar fijando la corriente que atraviesa la carga, la resistencia de la carga, el voltaje hasta el que se quiere llegar (consumirá la corriente necesaria para llegar hasta dicho voltaje) o la potencia que será consumida (la Carga Electrónica regulará la corriente para mantener la potencia constante).

Por lo tanto la Carga Electrónica será el dispositivo que simule todas las cargas que

sean necesarias en cada proyecto para representar un sistema equivalente al vehículo en el que se colocarán las piezas. Será controlada en todo momento desde el PC por medio del software programado en el panel de CANoe (VECTOR). La comunicación entre el PC y la Carga Electrónica se realizará a través de la interfaz RS232.

3.2.4 Sistema de PLC Un controlador lógico programable, más conocido por sus siglas en

inglés PLC (Programmable Logic Controller), es una computadora utilizada en la ingeniería automática o automatización industrial, para automatizar procesos electromecánicos, tales como el control de la maquinaria de la fábrica en líneas de montaje o atracciones mecánicas.

Los PLC son utilizados en muchas industrias y máquinas. A diferencia de las computadoras de propósito general, el PLC está diseñado para múltiples señales de entrada y de salida, rangos de temperatura ampliados, inmunidad al ruido eléctrico y resistencia a la vibración y al impacto. Los programas para el control de funcionamiento de la máquina se suelen almacenar en baterías copia de seguridad o en memorias no volátiles. Un PLC es un

23

http://es.wikipedia.org/wiki/Computadora

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_autom%C3%A1tica

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_autom%C3%A1tica

http://es.wikipedia.org/wiki/Automatizaci%C3%B3n_industrial

http://es.wikipedia.org/wiki/Electromec%C3%A1nica

http://es.wikipedia.org/wiki/Producci%C3%B3n_en_cadena


ejemplo de un sistema de tiempo real, donde los resultados de salida deben ser producidos en respuesta a las condiciones de entrada dentro de un tiempo limitado.

El PLC reacciona en base a la información recibida por los captadores (sensores) y el

programa lógico interno, actuando sobre los accionadores de la instalación. Como se puede ver en el esquema de la Figura 9.

Figura 9. Interacción PLC-Instalación

En la Figura 10 se puede ver la estructura básica de un PLC.

Figura 10. Estructura Básica de un PLC

3.2.5 Tarjetas y Sistemas de Relés del Equipo (Relay Boards) Las tarjetas o placas que se describen en este punto, son una serie de tarjetas que se

han diseñado y creado en LEAR específicamente para el presente proyecto. Se trata de tarjetas que están formadas por una serie de relés, que serán controlados

desde los distintos módulos del PLC, para activar y desactivar una serie de señales.

SEÑALESDE

SENSORES

SEÑALESA

ACTUADORES

ALIMENTACIÓN

MEMORIA

PROCESADOR

CPU

PERIFÉRICOS

24

http://es.wikipedia.org/wiki/Tiempo_real


3.2.6 Conectores del Equipo (Connectors) El equipo físico de validación automática dispone de todos los conectores necesarios

en su panel posterior. Para conectar tanto la BCM del proyecto a validar como todos los elementos que puedan ser necesarios para realizar dicha validación Como pueden ser módulos externos que controle la BCM, otros dispositivos de medida, etc.

3.2.7 Arnés de Cableado (Wiring Harness) El arnés de cableado es básicamente, el conjunto de cables con sus diferentes

conectores que comunicarán todas las señales de la BCM a validar, con el equipo de validación automática.

Será un cableado equivalente al que encontraríamos en el vehículo, en el que todos los

conectores de la parte de la BCM lógicamente serán exactamente los mismos, pero los conectores del extremo opuesto serán los conectores que encajen en los respectivos conectores del equipo de validación automática.

Este cableado tendrá que ser creado de cero para cada proyecto que se pretenda adaptar

al equipo de validación automática. Seleccionando cuidadosamente a que conector (y en consecuencia a que parte del sistema) se conectará cada una de las señales de la BCM. Teniendo en cuenta la funcionalidad y características de cada señal, el procedimiento del test que requiera para validarla y las características del equipo de test.

Como ya se ha mencionado cada proyecto diferente que se pretenda adaptar al equipo

de validación automática requerirá de la creación de un nuevo cableado propio, este proceso se detallará en el apartado de la fase de desarrollo del presente proyecto llamada “Adaptación del Equipo a un Proyecto Específico”. Donde se explica la creación del cableado para el primer proyecto al que ha sido adaptado el equipo.

3.2.8 BCM (Body Control Module) Como ya se ha definido en el apartado de introducción del presente proyecto, BCM o

Body Control Module, es un término genérico para denominar a una unidad electrónica de control, responsable de la supervisión y el control de varios dispositivos de un vehículo.

Normalmente en un coche la BCM controla las ventanas eléctricas, espejos

eléctricos, aire acondicionado, sistema inmovilizador, cierre centralizado, luces, limpiaparabrisas, alarma, cerraduras de las puertas etc.

La BCM se comunica con otros ordenadores de a bordo a través del bus de

comunicaciones del vehículo. Dependiendo del proyecto las BCM pueden tener diferentes tamaños, formas,

conectores, etc.

25


3.2.9 PC con Software CANoe de VECTOR e Interfaz CAN Case Una parte importante del sistema de validación automático es el ordenador o PC junto

con el software CANoe de VECTOR donde se creará el programa que controlará todo el sistema, comunicándose con todos sus componentes, tanto con el DUT conectado al equipo, como con el sistema de PLC, la Carga Electrónica, la Fuente de Alimentación, la Cámara Climática o realmente cualquier elemento que fuera necesario.

En este caso la Carga Electrónica, la Fuente de Alimentación, la Cámara Climática

serán controladas y se comunicarán a través de bus de comunicaciones RS-232 pero todo el programa de control será implementado y ejecutado desde el software CANoe de VECTOR.

La comunicación entre el PC que ejecutará el software de control del equipo

(implementado en CANoe) y la BCM se realizará a través del protocolo de comunicaciones CAN, de la misma manera que se realizará la comunicación con el sistema de PLC.

El software de control del equipo (implementado en CANoe) dispondrá de una interfaz

gráfica desde la que se podrá controlar todo el sistema, ya sea apretando un botón que ponga en marcha una validación completa totalmente automática o permitiendo realizar cualquier test por separado o cualquier control específico sobre cualquier parte o señal del sistema.

3.2.9.1 PC Como ya se ha descrito será necesario el uso del PC ya que será el centro de control

del sistema de validaciones. Desde este se controlará todo a través de la interfaz gráfica creada en el propio software de CANoe de VECTOR, como también se obtendrán todos los informes de resultados de los diferentes test y validaciones.

3.2.9.2 Software CANoe de VECTOR

CANoe es una herramienta de desarrollo y testeo de software de de Vector Informatik GmbH. El software es utilizado principalmente por los fabricantes de automóviles y los proveedores de unidades de control electrónico (ECU) para el desarrollo, análisis, simulación, testeo, diagnóstico y puesta en marcha de redes de ECU y ECU individuales. Su uso generalizado y el gran número de diferentes sistemas de bus de vehículo soportados, hace que sea especialmente adecuado para el desarrollo ECU en vehículos convencionales, así como para vehículos híbridos y vehículos eléctricos.

CANoe soporta CAN, LIN, FlexRay, MOST, sistemas de bus Ethernet y así como protocolos basados en CAN como J1939, CANopen, ARINC 825, ISOBUS y muchos otros.

El software de control creado en CANoe será el centro de control del sistema de

validaciones. Desde este se controlará todo a través de la interfaz gráfica. Este software será el que lea los archivos específicos de cada proyecto donde se relacionen todas las señales de

26


cada BCM con su punto de conexión en el equipo de validación y los archivos que especifican la secuencia de test a seguir para llevar a cabo todo el proceso de validación. Y en consecuencia controle el sistema según se haya especificado y muestre toda la información necesaria por pantalla generando un informe con los resultados de la validación o los test específicos que se hayan llevado a cabo.

3.2.9.3 Interfaz Física de CAN (CANcase) Las herramientas de software utilizadas para desarrollar, simular, probar y mantener

los sistemas, es decir, el software de CANoe de VECTOR, requieren interfaces hardware potentes y flexibles.

VECTOR ofrece interfaces para CAN, LIN, J1708, Ethernet/IP, FlexRay y MOST

así como drivers para usar con sus herramientas software de VECTOR.

3.2.9.4 CAN-Bus de Datos y Protocolo de comunicaciones CAN El CAN-Bus de datos, ha sido diseñado para mantener estructurados los sistemas

eléctricos y electrónicos que requieren un intercambio de información intenso entre las unidades de control, evitando que ocupen demasiado espacio.

CAN corresponde a las siglas de Controller Area Network (red de área de

controlador) y significa, que las unidades de control están interconectadas e intercambian datos entre sí.

El CAN-Bus de datos representa un modo de transmitir los datos entre las unidades

de control. Comunica las diferentes unidades de control en un sistema global interconectado.

Con el CAN-Bus de datos en lugar de transmitir cada información a través de un cable propio, toda la información se transmite a través de dos cables. En ambos cables bidireccionales del CAN-Bus se transmiten los mismos datos. Independientemente de la cantidad de unidades de control abonadas y de la cantidad de información transmitida. Por ese motivo es conveniente transmitir los datos con un CAN-Bus cuando se intercambia una gran cantidad de información entre las unidades de control.

El CAN-Bus de datos ofrece las siguientes ventajas:

- Si el protocolo de datos ha de ser ampliado con información suplementaria

únicamente se necesitarán modificaciones en el software. - Un bajo porcentaje de errores, mediante una verificación continua de la información

transmitida, de parte de las unidades de control, y mediante protecciones adicionales en los protocolos de datos.

- Menos sensores y cables de señales gracias al uso múltiple de una misma señal de sensores.

- Es posible una transmisión de datos muy rápida entre las unidades de control.

27


- Más espacio disponible, mediante unidades de control más pequeñas y conectores más compactos para las unidades de control.

- El CAN-Bus de datos está normalizado a nivel mundial. Por ese motivo, también las unidades de control de diferentes fabricantes pueden intercambiar datos.

3.2.9.4.1 Principio de Funcionamiento La transmisión de datos a través del CAN-Bus funciona de un modo parecido al de

una conferencia telefónica. Un abonado (unidad de control) modula sus datos, introduciéndolos en la red, mientras que los demás coescuchan estos datos. Para ciertos abonados resultan interesantes estos datos, por lo que los utilizan. A otros abonados pueden no interesarles esos datos específicos.

3.2.9.4.2 Componentes del CAN-Bus de Datos El CAN-Bus de datos consta de un controlador, un transceptor, dos elementos

finales del bus y dos cables para la transmisión de datos. Con excepción de los cables del bus todos los componentes están alojados en las unidades de control.

El controlador CAN recibe del microprocesador, en la unidad de control, los datos

que han de ser transmitidos. Los acondiciona y los pasa al transceptor CAN. Asimismo recibe los datos procedentes del transceptor CAN, los acondiciona y los pasa a la unidad de control.

El transceptor CAN es un transmisor y un receptor. Transforma los datos del

controlador CAN en señales eléctricas y transmite éstas sobre los cables del CAN-Bus. Asimismo recibe los datos y los transforma para el controlador CAN.

El elemento final del bus de datos es una resistencia. Evita que los datos transmitidos

sean devueltos en forma de eco de los extremos de los cables y que se falsifiquen datos. Los cables del bus de datos funcionan de forma bidireccional y sirven para la

transmisión de los datos. Se denominan con las designaciones “CAN-High” (señales de nivel lógico alto) y “CAN-Low” ” (señales de nivel lógico bajo).

28


3.2.9.4.3 Desarrollo de un Ciclo de Transmisión de Datos

Figura 11. Desarrollo de un Ciclo de Transmisión de Datos

Al trabajar con el CAN-Bus no se define el destinatario de los datos. Se transmiten a

bordo del bus y generalmente los reciben y analizan todos los abonados. La unidad de control provee los datos al controlador CAN, para su transmisión. El

transceptor CAN recibe los datos del controlador CAN, los transforma en señales eléctricas y los transmite.

Todas las demás unidades de control que están interconectadas a través del CAN-Bus

se transforman en receptores. Las unidades de control revisan si necesitan los datos recibidos para la ejecución de sus funciones o si no los necesitan. Si se trata de datos importantes, la unidad de control en cuestión los adopta y procesa, si no son importantes, los desprecia.

En la Figura 11 se puede ver el diagrama del desarrollo de un ciclo de transmisión de datos, donde la unidad de control 2 actúa como transmisora y el resto de unidades de control actúan como receptoras. Se puede ver también como solo las unidades de control uno y cuatro adoptan los datos.

3.2.9.4.4 Protocolo de Comunicación CAN En general, el protocolo de comunicación CAN se basa en el modelo de referencia de

Interconexión de Sistemas Abiertos (OSI) de acuerdo con la norma ISO-7498 estándar internacional (véase la Figura 12). El modelo define 7 capas de funciones de comunicación, dos de los cuales, las capas 1 y 2, se utilizan en CAN.

29


Figura 12. Modelo de Interconexión de Sistemas Abiertos OSI

- Capa 1, la capa física (Physical Layer) de este modelo, define las características de

transmisión físicas. - Capa 2, la capa de enlace de datos (Data Link Layer) de este modelo, define el

protocolo de acceso al bus. Este protocolo también incluye la seguridad de los datos y el manejo de los protocolos de transmisión y telegramas.

CAN utiliza las capas uno y dos. Las capas de la tres a la siete no están definidas para

CAN, la capa de aplicación, capa OSI 7, define las funciones de interfaz para las áreas de aplicación específicas.

- OSI, Capa 1 (Medio de Transmisión): ISO 11898 define la capa física. El bus CAN es una interfaz diferencial de 2 hilos que

funciona sobre un par trenzado apantallado (STP, Shielded Twisted Pair), par trenzado sin apantallar (UTP, Unshielded Twisted Pair) o cable plano. La codificación de bits utilizada es: NRZ (Non Return to Zero) codificación con “bit-stuffing” para la comunicación de datos en un bus diferencial de dos hilos. El uso de codificación NRZ asegura mensajes compactos con un número mínimo de transiciones y de alta resistencia a perturbaciones externas.

Se define una serie de velocidades de transmisión (ver Tabla 1), siendo 1 Mbps (bits

por segundo) la velocidad máxima y 10 Kbps la mínima. La longitud del cable depende de la velocidad de datos utilizada. La longitud máxima de la línea es de 5 km, y la mínima de 25 metros a 1 Mbps. Se utilizan resistencias de terminación en cada extremo del cable como ya se ha comentado en el apartado anterior. El tiempo de transmisión del peor caso de una trama de 8 bytes con un identificador de 11 bits es de 134 tiempos de bit (que es 134 microsegundos a la máxima velocidad de transmisión de 1Mbits/seg).

30


Tabla 1. Velocidades de Transmisión

- OSI, Capa 2 (Enlace de Datos): El protocolo de acceso al bus CAN es implementado por la capa 2 de OSI. Este

protocolo también incluye seguridad de datos y el manejo de los protocolos de transmisión y mensajes. La capa de enlace de datos es la capa 2 del modelo de referencia ISO / OSI, y se construye con dos sub-capas una encima de otra: la subcapa “Logical Link Control” (LLC) y la subcapa “Medium Access Control” (MAC).

La subcapa “Medium Access Control” (MAC) especifica los procedimientos que

determinan cuando a un dispositivo se le permite transmitir datos. Se transmite información de los transmisores a los receptores en tramas de datos. La subcapa MAC representa el “kernel” del protocolo CAN. Presenta los mensajes recibidos de la subcapa LLC y acepta los mensajes a transmitir a la subcapa LLC.

La subcapa LLC se ocupa del filtrado de mensajes, notificación de sobrecarga y

administración de recuperación.

Los mensajes transmitidos y recibidos son llamados tramas de datos. La trama de datos se compone de siete secciones como se puede ver en la Figura 13.

Figura 13. Formato Trama de Datos CAN

31


- Start of Frame (SOF): El campo de comienzo de trama marca el comienzo del protocolo de enlace de los datos. En el cable CAN-High se transmite un bit con aprox. 5 voltios (en función del sistema) y en el cable CAN-Low se transmite un bit con aprox. 0 voltios.

- Arbitration Field: En el campo de estado se define la prioridad del protocolo. Si

por ejemplo hay dos unidades de control que intentan transmitir simultáneamente su protocolo de datos, se concede la preferencia al protocolo de prioridad superior.

- Control Field: En el campo de control se especifica la cantidad de información que

está contenida en el campo de datos. De esa forma, cada receptor puede revisar si ha recibido la información completa.

- Data Field: En el campo de datos se transmite la información para las demás

unidades de control. El campo de datos puede ser de 0 a 8 bytes. - Cyclic Redundancy Code Field (CRC): El campo de aseguramiento sirve para

detectar fallos en la transmisión. La secuencia de verificación de trama se deriva de un Código de Redundancia Cíclica (CRC).

- Ack Field: En el campo de confirmación los receptores señalizan al transmisor, que

han recibido correctamente el protocolo de enlace de datos. Si detectan cualquier fallo, informan de inmediato al transmisor. A raíz de ello, el transmisor repite su transmisión.

- End of Frame (EOF): Con el campo de fin de trama finaliza el protocolo de datos.

Es la última oportunidad posible para dar un aviso de error, que conduzca a una repetición. Hay dos formatos diferentes para una trama de datos, los dos formatos difieren en la

longitud del identificador de mensaje, también llamado “Arbitration Field” o campo de estado (ver Figura 13). Las tramas que tienen identificadores con un tamaño de 11 bits se llaman tramas estándar (Standard Frames). El otro formato tiene tramas que contienen un identificador de 29 bits, que son llamadas tramas extendidas (Extended Frames). La longitud Máxima de los datos de transmitidos en un mensaje es de 8 bytes, pero incluso si la longitud de datos es menor que 8 bits, la trama siempre tiene 8 bytes de datos.

3.2.9.4.5 Adjudicación del Bus de Datos CAN Si varias unidades de control pretenden transmitir simultáneamente su protocolo de

datos, es preciso decir cuál de ellos se transmite primero. Se transmitirá primero el protocolo con mayor prioridad. Esta prioridad vendrá indicada por el “arbitration field” o campo de estado, como se ha explicado en el punto anterior.

Si por ejemplo tres unidades de control empiezan simultáneamente con la transmisión

de su protocolo de datos. Se comparan los bits, de uno en uno, en el cable del bus. Si una unidad de control transmite un bit de validación inferior y detecta uno de validación superior, interrumpe la transmisión y se transforma en receptor.

32


Después de que la unidad de control con mayor prioridad ha transmitido su protocolo de datos hasta el final, las demás vuelven a hacer el intento de transmitir su propio protocolo de datos.

3.2.9.4.6 Fuentes Parásitas En el vehículo existirán fuentes parásitas, como serán los componentes en cuyo

funcionamiento se producen chispas o se abren o se cierran circuitos de corriente. Otras fuentes parásitas son por ejemplo los teléfonos móviles y radioemisoras, es decir, todo aquello que genera ondas electromagnéticas. Estas ondas electromagnéticas pueden influir en la transmisión de datos o incluso la pueden falsificar.

Para evitar influencias parásitas sobre la transmisión de datos se procede a retorcer

conjuntamente los dos hilos del bus de datos (ver Figura 14). De esta forma se evitan al mismo tiempo emisiones perturbadoras procedentes del propio cable del bus de datos. Las tensiones en ambos hilos o cables se encuentran respectivamente contrapuestas, lo que significa que si uno de los cables del bus tiene aplicada una tensión de aproximadamente 0 voltios, el otro tendrá una de aproximadamente 5 voltios y viceversa (ver Figura 14). Gracias a esto la suma de tensiones es constante en cualquier momento y se anulan mutuamente los efectos electromagnéticos de campo de ambos cables del bus.

El cable del bus está protegido contra penetración de emisiones parásitas y tiene un

comportamiento casi neutro hacia afuera.

Figura 14. Configuración del Bus CAN para Evitar Fuentes Parásitas

3.3 Configuración del Sistema

En este apartado se explica cómo están conectados todos estos elementos y cómo interactúan entre sí, para poder comprender las capacidades totales del equipo y cuál será su modo de trabajo. Dando así la información necesaria para comprender cuales son los pasos a seguir a la hora de adaptar cualquier proyecto al equipo.

33

4 Fases de Desarrollo del Proyecto

En este apartado de describen todas las fases que se han seguido para desarrollar el

proyecto desde el principio hasta conseguir el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN que da nombre al presente proyecto. Incluida la fase de adaptación del sistema a uno de los proyectos de LEAR. Concretamente a uno de los proyectos más grandes de la empresa.

En la Figura 15 se muestran las fases de desarrollo del proyecto.

Figura 15. Fases de Desarrollo del Proyecto


4.1 Validación Inicial del Hardware

4.1.1 Comprobaciones

Una vez se encuentra el prototipo del equipo en el laboratorio, el primer paso es realizar una validación inicial del hardware, en la que se compruebe que absolutamente todas las conexiones, entre todas las partes del equipo se encuentran correctamente, es decir, tal y como se ha especificado en los esquemáticos.

Se parte de un prototipo que básicamente es un panel en el que ya se encuentran la

mayoría de las partes montadas. Por lo tanto se comprobarán una a una todas las conexiones del equipo. Esto significa

realizar test de continuidad con un multímetro entre todos los extremos de todos los conectores, es decir pin a pin, para verificar así, que el equipo está cableado correctamente y además asegurar que no existan falsos contactos, señales cortadas o pines cortocircuitados.

4.2 Programación del Sistema de PLC Una vez comprobado que todas las conexiones, entre todas las partes del equipo se

encuentran correctamente, se tiene que programar toda la serie de módulos de PLC para que sea capaz de controlar todas las señales y funcionalidades del sistema y comunicarse y por CAN reportando la información necesaria.

Una vez el sistema de PLC se encuentre programado, no se tendrá que volver a

modificar, ni siquiera a la hora de adaptar un nuevo proyecto al equipo, ya que esta programación tendrá en cuenta la capacidad total del sistema de PLC dejando este completamente funcional. Será el software de control desde el PC, programado en CANoe, el que tenga en cuenta qué hay conectado en cada punto del PLC y cómo tratarlo.

Por lo tanto una vez programado el PLC, se podrá realizar una Validación Completa

del Hardware utilizando ya el PLC como parte del hardware del equipo, al poder controlar todos los módulos y visualizar medidas desde el mismo software en el que se programa el sistema de PLC. Pudiendo así comprobar y asegurar que cuando el software del equipo, creado en CANoe, sea el que controle el sistema, este responderá de manera correcta.

4.2.1 Creación y Asignación de las Tramas de CAN del Sistema de PLC El sistema de PLC será controlado desde CANoe a través de comunicación CAN. Al

mismo tiempo el sistema de PLC reportará información sobre ciertas señales también a través de comunicación CAN. Esta comunicación se producirá gracias al módulo CAN del PLC.

35


Por lo tanto el primer paso es definir todas las tramas de CAN necesarias para realizar la comunicación con el sistema de PLC.

Toda esta información se creará en un archivo de Excel.

Como ya se ha visto en el apartado del protocolo de CAN, una trama de datos CAN

dispone de 8 Bytes que forman el campo de datos, por lo tanto con 8 Bytes de datos podremos controlar 64 entradas o salidas de algún módulo de PLC, estos 64 Bytes tendrán el mismo identificador de trama (ID de11bits), los siguientes 64 bit tendrán otro identificador y con ellos se podrán controlar otras 64 entradas o salidas de algún módulo de PLC. Se pueden usar los 8 Bytes de cada trama o solo algunos.

Por lo tanto a cada entrada o salida de cualquier módulo de PLC se le asignará una

trama concreta de CAN con su correspondiente identificador (ID).

El archivo de Excel dispondrá en cada fila de toda la información referente a la trama de CAN seguida de toda la información referente a la entrada o salida correspondiente de cada módulo de PLC.

4.2.2 Programación del PLC en su Software Específico Para realizar la programación del sistema de PLC se usa el software específico. Esta

programación se realizará en lenguaje Ladder, también conocido como programación en diagrama de contactos.

4.2.2.1 Conceptos Básicos sobre el Sistema de PLC El sistema de PLC dispone de tres estados de funcionamiento que son PROGRAM,

MONITOR y RUN (Figura 16).

Figura 16. Estados de Funcionamiento del PLC

RUNMONITOR

PROGRAM

36


- PROGRAM. El PLC está en reposo, y puede recibir ó enviar el programa a un periférico (consola, PC, etc.) - MONITOR o RUN. En estos dos modos el PLC ejecuta el programa que tiene en memoria, permitiendo en el modo monitor el cambio de valores en los registros del mismo.

En la Figura 17 se puede ver un diagrama de flujo del modo de funcionamiento RUN,

que es el modo en el que el PLC funcionará normalmente.

Figura 17. Diagrama de Flujo Modo RUN

La memoria del PLC se encuentra dividida en varias áreas, cada una de ellas con un

contenido y características distintas: - ÁREA DE PROGRAMA. En esta área es donde se encuentra almacenado el

programa del PLC (que se puede programar en lenguaje Ladder o nemónico).

- ÁREA DE DATOS. Esta área es usada para almacenar valores o para obtener información sobre el estado del PLC. Está dividida según funciones en IR, SR, AR, HR, LR, DM, TR, T/C.

37


4.2.2.2 Descripción del Programa del Sistema de PLC

INFORMACIÓN CONFIDENCIAL

4.3 Modificaciones en el Hardware La siguiente fase de desarrollo consiste en reparar todos los errores o fallos que se han

ido detectando durante todo el proceso. Básicamente se trata de modificar todo lo necesario para que el equipo funcione como se espera. En esta fase se corrigen los errores detectados durante la fase de Validación Inicial del Hardware, así como otros detectados durante la fase de Programación del PLC.

Como es lógico, en la última fase del proyecto, la fase de Adaptación a un Proyecto

Específico, surgen nuevas modificaciones necesarias para adaptar el equipo a un proyecto. Estas modificaciones, a pesar de haber sido realizadas en paralelo con esta última fase, se detallan en este apartado por motivos de estructuración del proyecto.

4.3.1 Corregir Pines sin continuidad

4.3.2 Sustitución de una Tarjeta de Relés

4.3.3 Soldar Conector a Tarjeta de Comunicaciones

4.3.4 Cableado del Módulo de Comunicaciones CAN

4.3.5 Recableado de Varias Señales de las Tarjetas Multiplexoras

4.3.6 Sistema de Control de Polaridad de la Carga Electrónica

4.3.7 Sustitución de un Módulo de señales PLC Erróneo

4.3.8 Módulo CAN del PLC Defectuoso

4.3.9 Retrabajo en Módulos de PLC (Sustitución Resistencias SMD)

4.3.10 Divisores de Tensión Añadidos en Módulo del PLC

4.3.11 Sustitución Potenciómetros Módulos de Entradas Analógicas

4.3.12 Relé Desconexión Terminal Común de Módulos del PLC

38


4.4 Validación Completa del Hardware Una vez se encuentra el sistema de PLC programado completamente y ya han sido

realizadas todas las modificaciones de hardware necesarias, se puede decir que el equipo de validación AUTOTESTER_GEN2 se encuentra ya preparado para su uso. Pero antes de pasar a la siguiente fase, se realizará una validación completa del equipo, ahora teniendo en cuenta el sistema de PLC como parte del hardware. Por lo tanto esta validación completa del hardware se tratará de activar una a una todas y cada una de las entradas o salidas del equipo. Comprobando así que el software del PLC funciona correctamente, al mismo tiempo que se asegura que todas las partes del equipo están conectadas como deben e interactúan entre ellas como se espera.

Para realizar esta validación se prueban una a una todas las señales que el equipo es

capaz de manipular. Es decir se controla el sistema de PLC de la misma manera que se haría en su funcionamiento normal, pero forzando todas sus acciones desde el propio programa del PLC en lugar de controlarlo desde el programa principal de CANoe de VECTOR.

De esta manera se comprueba que todos los módulos han sido correctamente

programados, ya que somos capaces de activar cualquiera de las salidas de cualquiera de los módulos de salidas del equipo en el momento deseado, así como de recibir información de los módulos de entradas en el momento de que se conecte algo en cualquiera de estos módulos de entradas.

4.5 Panel de Control de CANoe La siguiente fase de desarrollo consiste en la creación de la interfaz gráfica a través de

la cual se controlará completamente el equipo. Por lo tanto a través de esta interfaz gráfica se controlará todo el software de CANoe

de VECTOR que controlará el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN.

De la misma manera que el resto del equipo esta interfaz se ha desarrollado pensando

en ser genérica, es decir, con la idea de poder ser usada para los diferentes proyectos de LEAR a los que se necesite adaptar al equipo. Por lo tanto antes de ser creada se ha estudiado toda la cantidad posible de información que pudiera ser necesaria en cualquiera de los posibles diferentes proyectos a adaptar.

Básicamente, la idea es disponer de un panel principal que contenga toda la

información necesaria para controlar el equipo.

El panel principal consta de dos partes diferenciadas. Una zona llamada System que forma la parte izquierda del panel y una zona llamada Automatic Tests que forma la parte derecha del panel.

39


En la zona llamada System se encuentra toda la información de los diferentes elementos del sistema. Desde esta zona no solo se pueden visualizar los datos y el estado de cada uno de los elementos del sistema, también se pueden configurar diferentes parámetros de cada elemento de manera manual, así como acceder a unos paneles secundarios desde los que poder controlar el sistema de manera completamente manual, como si de un panel de cargas completamente normal se tratase.

En la zona llamada Automatic Tests se encuentran todos los elementos de control

para lanzar los diferentes test automáticos que se puedan requerir así como para la obtención de los archivos de resultados.

4.6 Adaptación a un Proyecto Específico Una de las fases más importantes en el desarrollo del presente proyecto es la fase de

adaptación a un proyecto específico. En primer lugar porque esta fase definirá el nivel de dificultad de futuras adaptaciones

de otros proyectos al equipo. En segundo lugar porque esta fase, aparte de seguir el plan de adaptación a un proyecto específico y permitir así realizar validaciones de dicho proyecto con el equipo, servirá también para detectar errores o debilidades del equipo que no se conocían (al ser este el primer prototipo), descubriendo posibilidades de mejora. Esto en algunas ocasiones creará la necesidad de realizar modificaciones inmediatas en el equipo, para poder realizar así una correcta adaptación del proyecto que se esté adaptando, pero gracias a esta primera adaptación a un proyecto específico se obtendrá una información muy valiosa para crear una versión final, lo más optimizada posible.

A continuación se describen las diferentes fases necesarias para llevar a cabo la adaptación del proyecto al equipo.

4.6.1 Creación del Arnés de Cableado para el Nuevo Proyecto El primer paso para adaptar un proyecto al equipo es generar un arnés de cableado que

permita conectar las diferentes BCM a validar con el equipo de test. Para ello es necesario generar un documento con todas las especificaciones del nuevo

cableado. Este, es un documento de Excel en el que se especifica a que pin específico del equipo irá conectada cada una de las señales de las posibles BCM del proyecto a adaptar,. De esta manera el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN será capaz de tratar cada señal como sea necesario en cada momento.

Por supuesto, antes de decidir dónde irá conectada cada una de las señales de la BCM,

es necesario saber cómo tendrán que ser tratadas dichas señales para que el equipo sea capaz de simular su funcionamiento normal y validar así que su funcionamiento es el correcto.

40


4.6.2 Creación de los Archivos Necesarios para el Nuevo Proyecto

El segundo paso para adaptar un proyecto al equipo es generar los archivos específicos para cada proyecto, que contendrán toda la información necesaria para que el equipo de test automático lleve a cabo las validaciones de las BCM del proyecto en cuestión. Es decir, generar los archivos de los que el software obtendrá todos los datos para poder tratar un proyecto en concreto.

Se trata de dos tipos de archivos. En uno de ellos, al que nos referiremos como Signals.csv, se encontrará toda la

información necesaria para el tratamiento de las señales, nombres, conectores, relación entre señales de la BCM y punto del equipo al que van dirigidas (definida por el cableado creado para el proyecto), tramas de comunicación CAN para todas las señales, tanto de la BCM como del PLC, etc.

En el otro archivo, al que nos referiremos como Test_seq.csv, se encontrará toda la

información referente a los test a realizar. Es decir, es el archivo donde estarán definidas todas las secuencias de los diferentes test a realizar para que el equipo pueda completar una validación funcional. Dentro de este archivo estarán definidas todas las activaciones y desactivaciones de señales, tiempo de activación, etc. y varios parámetros de configuración de los elementos del equipo como pueden ser los parámetros de configuración de la Carga Electrónica o los parámetros de configuración de la Fuente de Alimentación para cada paso de test. Cada proyecto necesita su propio archivo de Signals.csv y su propio archivo de Test_seq.csv. De hecho cada DUT o BCM en el que exista una cierta cantidad de cambios necesita sus propios archivos, o por lo menos ciertas modificaciones. Por ejemplo en el caso del proyecto adaptado, dentro del mismo proyecto existen una gran cantidad de variantes en las que cambian señales o la misma señal es usada de distinta forma o con una distinta carga. Por lo tanto se tendrá que crear un archivo de Signals.csv y un archivo Test_seq.csv para cada variante. El archivo Signals.csv será prácticamente igual para todas las variantes, ya que la relación de conexión de señales prácticamente no cambiará entre variantes, pues en parte, viene definida por el cableado creado, que es fijo para todas las variantes, pero en el archivo Test_seq.csv sí cambiarán muchos de los valores de configuración del equipo en los diferentes pasos de test.

Como se puede apreciar en sus nombres son archivos CSV. Los archivos CSV (del inglés comma separated values) son un tipo de documento en formato abierto sencillo para representar datos en forma de tabla, en las que las columnas se separan por comas (o punto y coma en donde la coma es el separador decimal) y las filas por saltos de línea. Los campos que contengan una coma, un salto de línea o una comilla doble deben ser encerrados entre comillas dobles.

41

Planificación del Tiempo

5 Planificación del Tiempo

A continuación en la Figura 18 se puede ver la planificación temporal que se ha

seguido para llevar a cabo el desarrollo del proyecto dentro de la empresa LEAR.

Figura 18. Planificación Temporal en Lear

Como se puede apreciar en el diagrama de la Figura 18 las primeras cuatro fases del desarrollo del proyecto fueron prácticamente secuenciales, hasta que no se completaba una fase no se empezaba la siguiente. Y relativamente cortas, prácticamente a mediados de Octubre la parte hardware del equipo ya estaba técnicamente terminada y validada.

Justo en ese punto se realizó una actualización de la documentación, en la que

prácticamente se realizaron los esquemáticos completamente, ya que se tuvieron que crear las librerías CAD de todos los módulos de PLC debido a que en la primera versión de esquemáticos se encontraba el mismo módulo repetido y cambiado de posición, lo cual no se correspondía con la realidad. Esto produjo muchos errores en el cableado interno del equipo y por lo tanto errores en la documentación previamente realizada. Estos errores se arrastraron durante un tiempo, por lo que también se tuvieron que actualizar todos los documentos de relación de señales.

La siguiente fase fue la creación del panel de control de CANoe. Fase que se realizó

prácticamente en paralelo con la fase adaptación del equipo al proyecto específico, ya que para poder desarrollar correctamente el software y la interfaz del panel de control de CANoe era necesario conocer y tener en cuenta todas las partes, sistemas y procesos de validación que pudieran existir en cualquier proyecto, y así tenerlos en cuenta sin dejarse nada. Además de poder disponer cuanto antes de un cableado que permitiese empezar a conectar piezas al sistema para poder realizar todas las pruebas necesarias para realizar la comprobación del correcto funcionamiento del software.

42

Planificación del Tiempo

Por lo tanto se definió la interfaz gráfica, decidiendo qué era necesario y qué no era necesario y se creó el arnés de cableado. Y una vez se disponía de un equipo completo en el que ya se podían conectar diferentes BCM y una interfaz relativamente funcional, se crearon los archivos relativos al proyecto (Signals.csv y Test_seq.csv de una de las variantes del proyecto) y se realizaron las primeras pruebas automáticas en las que salieron multitud de errores y muchos pasos de test y acciones del equipo no funcionaron.

Entonces comenzó una etapa de trabajo en equipo en la que se fueron realizando

continuas pruebas con el equipo por medio de las cuales se detectaron tanto errores o carencias en el software de CANoe, como también alguna modificación en el software del PLC, que básicamente fue añadir la posibilidad de realizar un “reset” desde el panel de CANoe enviando una trama de CAN específica por si fuera necesario en algún momento. También ciertos retoques en el hardware como algunos de los comentados en la fase de modificaciones en el hardware (añadir divisores de tensión, añadir relé de desconexión del común de un módulo, algunos redireccionamientos de señales por necesidades del proyecto, etc.) y otros más específicos de la adaptación de todas las señales de un proyecto específico.

A la hora de adaptar un nuevo proyecto al equipo de test siempre va a ser necesaria

una fase de adaptación, en la que se ajusten todas las señales o sistemas del nuevo proyecto a las capacidades o métodos de validación del equipo de test, pero en este caso, al tratarse del primer proyecto adaptado, esta fase, evidentemente fue más extensa, ya que además de servir para adaptar el primer proyecto, también fue al mismo tiempo la fase de depuración del equipo de test, tanto en hardware como en software. Detectando además en esta fase muchas posibles mejoras para incluir en la versión final.

Una vez terminado se realizó la primera validación completa correcta para la primera

de las variantes del proyecto adaptado, es decir, una vez se terminó el primer archivo de test secuenciales (Test_seq.csv) que funcionó correctamente en consonancia con el software, la interfaz gráfica y el hardware y toda su configuración con el DUT del proyecto, entonces se empezaron a realizar archivos de test secuenciales (Test_seq.csv) para las diferentes variantes del proyecto. El resto de variantes fueron adaptadas mucho más rápido ya que el sistema ya se encontraba terminado, depurado y sin errores y además se creó una herramienta (Variant test sequence generator) para generar los archivos de test secuenciales (Test_seq.csv) de manera semiautomática. Esta fase está reflejada en el diagrama de la Figura 18 por la segunda semana del mes de febrero, cuando consta como terminada la fase de panel de control de CANoe, pero aún sigue la fase de adaptación a un proyecto específico.

Por último las últimas dos semanas se generó toda la documentación final.

43

6 Conclusiones

Debido a que se trata de un proyecto que ha sido desarrollado en una empresa, las

conclusiones se van a dividir en dos puntos fundamentales bien diferenciados. Por un lado las conclusiones sobre qué resultados se han obtenido para la empresa, LEAR. Cómo influye y qué aporta este proyecto a la empresa. Y por otro lado las conclusiones sobre los resultados a nivel personal. Cómo ha influido y qué ha aportado al autor del proyecto el hecho de llevarlo a cabo dentro de una empresa multinacional como es LEAR.

Como conclusión principal se puede decir que se han conseguido los objetivos

marcados inicialmente. Se ha conseguido el SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE DE AUTOMOCIÓN que se pretendía y da nombre al presente proyecto. Se ha conseguido además, que el equipo sea capaz de realizar las validaciones de manera completamente automática y se ha conseguido que el equipo sea adaptable a todos los proyectos de la empresa, ya que se ha dimensionado para ser capaz de dar soporte a los proyectos más grandes de la empresa en la actualidad.

Además se ha conseguido adaptar y poner en funcionamiento el equipo con uno de los

proyectos de mayor complejidad de la empresa tal y como se pretendía. Con lo que actualmente el equipo ya está dando soporte para validación de piezas de este proyecto.

Por supuesto, tal y como se explica en el apartado de objetivos del presente proyecto, para llegar a conseguir el objetivo principal, ha sido necesario cumplir la serie de objetivos concretos y la planificación que se marcó desde un principio. Y así ha sido, actualmente se dispone de:

- El sistema de PLC del equipo programado de manera fija para cualquier

proyecto que se necesite adaptar. Lo que permite que el sistema de PLC sea capaz de controlar todas las señales y funcionalidades del sistema para cualquier proyecto, de manera que no será necesario tener que volver a programarlo a la hora de adaptar un nuevo proyecto al equipo.

- Todo el hardware del equipo de test completamente funcional y con cobertura

de todas las posibles necesidades al adaptar cualquier proyecto. - Panel de control de CANoe con software que controla todo automáticamente

según lo establecido y con una interfaz gráfica lo más simple posible, pero al mismo tiempo con capacidad de permitir un control manual del sistema en caso que sea necesario.

- Un proyecto específico adaptado al equipo y funcionando. Con todos los archivos

necesarios creados para conseguir poder validar completamente todas las funcionalidades y realizar los test necesarios de dicho proyecto y pudiendo asegurar la fiabilidad del equipo al hacerlo, ya que se ha contrastado con gran cantidad de piezas y variantes.

Por lo tanto la conclusión es que con el nuevo SISTEMA DE TEST AUTOMÁTICO

PARA MÓDULOS HARDWARE DE AUTOMOCIÓN se consiguen eliminar todas las

Conclusiones

limitaciones de las anteriores generaciones de sistemas de test, al mismo tiempo que se aportan las siguientes ventajas:

-Capacidad de simular perfiles de carga reales. Gracias a la nueva configuración

del sistema y a la capacidad de la Carga Electrónica para simular cualquier carga eléctrica o cualquier perfil de carga eléctrica, el nuevo sistema permite simular a la perfección cualquier carga que podamos encontrar en un vehículo.

De esta manera se puede programar un perfil completo que simule cada carga real,

obteniendo así un resultado mucho más preciso al poder simular un comportamiento mucho más fiel al que se obtendría en un vehículo real. Añadiendo además la posibilidad de modificar la carga en cualquier momento, pudiendo hacer pruebas con distintas cargas para la misma señal, hacer test de corrientes máximas, mínimas, etc.

Gracias a esto este sistema no solo tiene la capacidad de validar el correcto

funcionamiento de una pieza, sino que además se convierte en una herramienta con capacidad de analizar los límites de funcionamiento de manera precisa y depurar posibles errores.

-Posibilidad de utilizar el equipo para diferentes proyectos. Esta nueva

configuración del sistema permite que el equipo pueda ser adaptado y utilizado para diferentes proyectos.

Esto supone una gran ventaja. En primer lugar porque permite reaprovechar el equipo.

Con los equipos anteriores, una vez ya no se necesitaba validar más piezas, el equipo quedaba en desuso, prácticamente inservible, ocupando espacio en algún almacén o en algún laboratorio por si en algún momento se necesitara validar alguna o varias piezas sueltas, por algún problema puntual. Con el consiguiente desaprovechamiento del equipo y el espacio necesario para almacenarlo. El nuevo equipo no solo permite poder reutilizarlo adaptándolo a un segundo proyecto una vez ya no sea usado para el primero, sino que también permite dar soporte a dos o más proyectos al mismo tiempo simplemente teniéndolo adaptado para dichos proyectos. Con lo que prácticamente con realizar el cambio del cableado se puede pasar de validar piezas de un proyecto a validar piezas de otro. Siempre que, lógicamente, no se requiera el uso del equipo a dedicación completa para un mismo proyecto por cuestiones de carga de trabajo. Esto permite, por ejemplo, tener un equipo preparado para dar soporte a varios proyectos diferentes en momentos puntuales en los que se produzca un pico en la carga de trabajo. Ahorrando así la necesidad de disponer de la gran cantidad de equipos que serían necesarios para dar soporte a eso proyectos.

Por lo tanto, esta capacidad del nuevo equipo para ser reutilizado en diferentes

proyectos hace que sean necesarios muchos menos equipos de validación. Lo que permite a su vez un gran ahorro de espacio, tanto del necesario para los paneles en uso, como del necesario para los paneles almacenados ya en desuso. Además permite retrasar la obsolescencia de los equipos, ya que un equipo que antes se desechaba, ahora con el nuevo equipo, se aprovechará para otro proyecto. Y a pesar de que los proyectos cada vez tienden a ser más grandes, al estar dimensionado para los proyectos más grandes de la actualidad, la vida útil del equipo se alarga enormemente, al poder ser utilizado por los proyectos “pequeños” de un futuro.

45

Conclusiones

Por supuesto todas estas cualidades mencionadas se traducen directamente en un gran ahorro de los costes.

-Validación completamente automática. Otra de las ventajas del nuevo sistema es

que es capaz de realizar validaciones completas de manera totalmente automática. Lo que no solo es una ventaja por el hecho de la gran reducción en el tiempo de validación, además al ser completamente automático y proporcionar un fichero con un informe completo con los resultados al terminar, permite que la persona que ponga en marcha los test, pueda dedicarse a otras tareas mientras el equipo de test está en funcionamiento.

-Gran reducción en costes de desarrollo. Es evidente que muchas de las ventajas

mencionadas se traducen directamente en un gran ahorro de costes. Pero hay que destacar que este sistema también aporta una gran reducción de costes de desarrollo.

A la hora de desarrollar uno de los equipos de validación con paneles de cargas para

un proyecto nuevo, es necesario desarrollar el nuevo panel, revisarlo, comprobar que sea correcto y si es necesario depurarlo, desarrollar el cableado para el proyecto del que se trate (que solo será uno), revisarlo, comprobar que sea correcto y si es necesario depurarlo y desarrollar el software de control de CANoe y depurarlo junto al panel y cableado ya correctos.

Gracias a la reusabilidad del nuevo equipo para nuevos proyectos se utilizaría el mismo

equipo, eliminándose así el desarrollo de un nuevo panel y un nuevo software. Siendo solo necesaria la creación de un nuevo cableado y los archivos de adaptación al nuevo proyecto como se ha explicado anteriormente.

Todas estas ventajas ya se habían comentado anteriormente pero ahora se puede

afirmar que se han conseguido y que la empresa puede disponer de ellas. Es evidente que todas las ventajas comentadas que aporta el equipo desarrollado durante este proyecto permite a LEAR disponer de una herramienta muy flexible que va ahorrar mucho tiempo y dinero a la empresa, además de proporcionarle una capacidad de respuesta mayor ante cantidades de trabajo elevadas lo que también puede traducirse en un mejor servicio para sus clientes.

Por otro lado, como conclusiones a nivel personal considero que poder desarrollar el proyecto de final de carrera en LEAR ha sido una experiencia muy positiva en muchos aspectos.

En primer lugar por tener la oportunidad de disfrutar de una toma de contacto real con

una empresa tan importante en el mundo de la electrónica y concretamente en la rama de la automoción, que personalmente considero muy interesante. Esto principalmente me ha aportado una gran cantidad de información y me ha permitido tener una visión mucho más amplia del funcionamiento de una empresa de esta envergadura, tanto a nivel general como más específico ya dentro de un puesto de trabajo en el laboratorio de Hardware. Gracias a poder conocer sus instalaciones, sus secciones, su organización, su política de empresa, interactuar con empleados de distintos rangos y secciones e incluso al tener la necesidad de solucionar problemas con los que me encontraba y tener que contactar con diferentes proveedores. Así como el trabajo día a día en el laboratorio, el descubrimiento y aprendizaje

46

Conclusiones

de utilización de muchas herramientas y dispositivos que no conocía. En definitiva, considero que ha sido un gran “baño de conocimientos” tanto a nivel de visión del mundo laboral dentro de la ingeniería como de conocimientos adquiridos a nivel más técnico.

Porque por supuesto una de las conclusiones realmente importantes que puedo sacar

de los resultados a nivel personal es la gran cantidad de conocimientos adquiridos. Ya que he tenido la oportunidad (y la necesidad) de conocer a fondo un proyecto de

complejidad alta, teniendo que conocer su funcionamiento completo, la totalidad de sus señales, que hace como funciona y para qué sirve cada componente de las BCM, para así comprender y contribuir a encontrar la mejor manera de que el equipo de test automático sea capaz de comprobar el funcionamiento de las piezas.

También he conocido el protocolo de comunicaciones CAN y su uso en automoción,

así como todos los detalles de su funcionamiento, es decir el protocolo en sí. Por supuesto, he conocido y he aprendido a usar el software CANoe de VECTOR.

Con control de todo el sistema, su código de programación CAPL y pudiendo profundizar en sus grandes capacidades para crear interfaces gráficas. Con la suerte de poder investigar y conocer grandes sistemas y programas ya en funcionamiento para otros proyectos, lo que permite acelerar mucho el aprendizaje.

También he conocido los nuevos sistemas de PLC, que nunca había tocado. Conocía

los PLC de SIEMENS SIMATIC S7 de la universidad. Considero que ha sido una suerte tener la oportunidad de conocer y poder trabajar con otro sistema o marca, ya que a pesar de sus similitudes, cada marca tiene sus peculiaridades y poder ampliar conocimientos siempre es algo positivo.

Además de conocer multitud de herramientas y equipo de trabajo con la oportunidad

de usarlo, como por ejemplo la estación de soldadura con todos sus componentes y su forma de usarlos, diferentes cargas electrónicas, diferentes fuentes de alimentación programables, diferentes osciloscopios, cámaras climáticas, cámaras anecoicas para realizar test de EMC, pinzas amperimétricas, etc.

En resumen, he tenido la posibilidad de adquirir una cantidad de conocimientos en

poco tiempo, que de no ser por realizar el proyecto dentro de una empresa, habría sido imposible adquirir. Sin olvidar, el tener que trabajar en equipo, aprendiendo a obligarse a llevar una planificación muy estructurada ya que he podido ver claramente como un error o pequeño descuido del presente, puede convertirse en un gran error, mucho mayor en un futuro y que cueste mucho solucionar o en el peor de los casos solo sea imposible, convirtiéndose en tiempo, esfuerzo y dinero perdido.

47

Referencias

Páginas Web: http://vector.com/ [Manuales CANoe]

http://omron.es/ [Manuales Módulos PLC] http://www.programmablepower.com/brands/sorensen.htm [Manuales Fuente de Alimentación e interfaz rs-232] http://www.hoecherl-hackl.com/ [Manuales Carga Electrónica] http://www.cts-umweltsimulation.de/english/products/temperature_eng.html [Manuales Cámara Climática]

http://vector.com/

http://omron.es/

http://www.programmablepower.com/brands/sorensen.htm

http://www.hoecherl-hackl.com/

http://www.cts-umweltsimulation.de/english/products/temperature_eng.html

SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE...

Documents

Transcript of SISTEMA DE TEST AUTOMÁTICO PARA MÓDULOS HARDWARE...