Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Instruments.
Visin General
National Instruments tiene varios productos que pueden usarse en varias aplicaciones en la Industria Automotriz. Al usar los Productos de National Instruments puede disear y probar
componentes electrnicos automotrices. Este documento habla sobre ECU's y los diferentes protocolos que comnmente se usan en la Industria Automotriz. Tambin describe las diferentes
opciones que ofrece National Instruments para disear y probar ECU.br>
Contenido
1.
Introduccin
2.
3.
4.
5.
Diseo y Pruebas
1. Introduccin
En la industria automotriz una unidad de control electrnico (ECU) es un dispositivo electrnico embebido, bsicamente una PC digital, que lee seales provenientes de sensores ubicados en
varias partes y en diferentes componentes del automvil y dependiendo de esta informacin controla varias unidades importantes por ejemplo el motor y operaciones automatizadas en el auto
y tambin verifica el rendimiento de algunos componentes clave usados en el automvil.
Un ECU est hecho bsicamente de hardware y software (firmware). El hardware est hecho de varios componentes electrnicos en un PCB. El componente ms importante es un chip
microcontrolador junto con un EPROM o un chip de memoria Flash. El software (firmware) es un juego de cdigos de menor nivel que se ejecuta en el microcontrolador.
El ECU se caracteriza por:
varias lneas de E/S analgica y digital (alta y baja potencia)
1. El Freno: Esta entrada le proporciona el estado del pedal del freno, por ejemplo flexin o adhesin. Esta informacin se adquiere en un formato digital o analgico.
2. El 4 W.D: Esta entrada proporciona el estado en formato digital si el vehculo est en modo de manejo en 4 ruedas.
3. El encendido: Esta entrada registra si la llave de encendido est en su lugar y si el motor est andando o no.
4. Velocidad del Vehculo: Esta entrada proporciona la informacin sobre la velocidad del vehculo.
5. Velocidad de las llantas: En una aplicacin tpica esto representa un juego de 4 seales de entrada que transmiten la informacin referente a la velocidad de cada llanta. Esta informacin se
usa para obtener toda la informacin necesaria para los algoritmos de control.
PCM Mdulo de control del tren de potencia.
PCM es un ECU que monitorea y controla velocidad, A/C y Transmisin Automtica. Las entradas que son alimentadas al PCM son de:
sensor de posicin del acelerador,
sensor de velocidad de flecha de transmisin,
sensor de velocidad del vehculo
sensor de velocidad del motor (CKP)
interruptor de freno
interruptores de control de velocidad
encendido
interruptor on/off de overdrive
sensor del gobernador de presin.
Usando estas entradas realiza control de transmisin, control de vlvula a travs de salidas PWM, control del embrague convertidor de torsin y del rel de proteccin de transmisin y
proporciona informacin al controlador a travs de la lmpara del tablero de overdrive.
VCM Mdulo de control del vehculo
VCM es un ECU que cuida los sistemas como:
sistemas de Direccin Elctrica Asistida (EPS)
sistemas de control de velocidad inteligente (ACC)
sistemas de control de bolsa de aire (ACS).
sistemas de Control Electrnico de Estabilidad (ESC).
El VCM generalmente es instalado a la mitad del automvil entre el pasajero y el compartimiento del motor. Estn conectados a varios tipos de sensores para controlar varios sistemas en el
automvil. Toman entradas de sensores de impacto (acelermetros de micro mquina) y sensores que detectan el peso del ocupante, posicin de asientos, cinturn de seguridad y posicin de
asiento para determinar la fuerza con la cual las bolsas de aire frontales deben desplegar. As mismo, toman entradas de los sensores de ngulo de direccin, sensores de velocidad de las
llantas, sensores del rango de viraje, sensores de aceleracin lateral para proporcionar una salida al ESC para seguridad de manejo.
BCM Mdulo de control de la unidad.
BCM es un ECU que cuida la unidad de control del asiento, control del limpiador, ventanas y toldos en automviles convertibles (ej. Benz SL Roadster).
Regresar al Inicio
Veamos algunos de los tipos de sensores y actuadores que generalmente son conectados a un mdulo de control de motores y el tipo de E/S que requieren.
Sensor Manifold de Temperatura del Aire (MAT)
El sensor es un termistor. Es montado normalmente en el ducto de aire alojado en el manifold. La resistencia elctrica del termistor disminuye como respuesta al aumento de temperatura y esto
se puede medir usando canal analgico con algn acondicionamiento de seal. (excitacin, amplificacin, etc.)
Protocolo ODBII- Este es un estndar de los ms populares que se introdujo a mediados de los aos 90's y cuida el control del motor completo y monitoreo del chasis y los accesorios. Es
usado por casi todos los
fabricantes
CAN ISO 11898 - Otro protocolo muy popular usado por la mayora de los fabricantes para diagnsticos internos. Los detalles del pin se muestran a continuacin.
Pin 2 - J1850 Bus+
Pin 4 - Tierra del Chasis
Pin 5 - Seal a Tierra
Pin 6 - CAN Alto (J-2284)
Pin 7 - ISO 9141-2 Lnea K
Pin 10 - J1850 Bus
Pin 14 - CAN Bajo (J-2284)
Pin 15 - ISO 9141-2 Lnea L
Pin 16 - Batera
Keyword 2000 y J1850 - Estos protocolos son usados bsicamente por GM, Chrysler para diagnsticos internos. J1850 es un protocolo muy viejo y est obsoleto.
Carrocera y Tren de Potencia
Las redes de Carrocera y Tren de Potencia pueden consistir en protocolos CAN, LIN o J1850. CAN es un protocolo verstil y es usado principalmente en varias categoras de redes porttiles.
CAN de alta velocidad es usado comnmente para aplicaciones de Tren de potencia como temporizacin del motor para asegurar que el automvil funciona de manera eficiente.
LIN -- La Red Local de Interconexin (LIN) es una red basada en UART que fue desarrollada estrictamente para aplicaciones de carrocera. Por ejemplo, una red LIN conecta todos los
dispositivos elctricos en la puerta de un automvil. LIN y CAN deben coexistir. Es usado principalmente por Chrysler, BMW y Volkswagen.
Multimedia y Controlador por cable
MOST -- Es una red de fibra ptica que ha sido optimizada para uso en el automvil. Est diseado para usarse con dispositivos simples como micrfonos y bocinas junto con dispositivos ms
complejos como dispositivos de seguridad como aquellos usados para ubicar automviles robados. La tecnologa MOST ha sido desarrollada y promovida por una Cooperacin, la cual incluye
BMW, Daimler-Chrysler y Audi.
IDB 1394 -- Es la ltima adicin a la familia IDB de las redes porttiles, diseado para aplicaciones de multimedia de alta velocidad que requieren mover rpidamente grandes cantidades de
informacin en un vehculo. Anteriormente conocido como IDB-M, el IDB-1394 est integrado en la tecnologa IEEE 1394 que ha ganado amplia aceptacin en la comunidad de electrnicos de
consumo.
La especificacin IDB-1394 define las capas de grado fsico del automvil (ej. cables, conectores), modos de potencia y los protocolos del ms alto nivel necesarios para asegurar la inter
operatividad de todos los dispositivos IDB-1394.
Controlador por cable hasta el momento los protocolos no han sido desarrollados completamente. Tambin hay algunos desacuerdos sobre cul protocolo se volver el estndar industrial.
Mientras Flexray ofrece alta velocidad, es costoso y lejos de la estandarizacin.
FlexRay -- Es un sistema de comunicacin escalable, flexible y de alta velocidad, el cual cumple con las crecientes demandas tcnicas en la industria automotriz. Con su razn de datos de
hasta 10 MBits/s, es ideal para aplicaciones de cable por X.
Regresar al Inicio
5. Diseo y Pruebas
La manera tradicional para desarrollar sistemas embebidos automotrices ha sido construir tarjetas de hardware que representan todo o parte de cada ECU y parte de sus componentes,
generalmente llamados modelos de plantas y usadas para pruebas de laboratorio. Desafortunadamente, el enfoque de laboratorio tiene varias limitaciones.
En este diagrama la progresin del tiempo general en las etapas de desarrollo se muestra de izquierda a derecha. Sin embargo, este es siempre un proceso repetitivo y el desarrollo actual no
proceder linealmente a travs de estos pasos. A cambio, usted podr emplear el tiempo en cada paso y hasta tener que regresar de vez en cuando. La meta es hacer este ciclo lo ms
eficiente posible al minimizar la cantidad de reproducciones entre los pasos, as como el tiempo empleado en cada paso.
El eje y de este diagrama se le puede conocer como el nivel al cual los componentes del sistema son considerados. Los requerimientos del sistema se deben considerar al comienzo del
desarrollo. Conforme el sistema es dividido en sub sistemas y componentes, el proceso se vuelve de bajo nivel hasta el punto de cargar el cdigo en los procesadores individuales.
Despus, los componentes son integrados y probados juntos hasta ese tiempo en el que el sistema completo puede entrar a las pruebas de produccin finales. Por lo tanto, la parte superior del
diagrama representa la vista del sistema de alto nivel y la parte inferior del diagrama representa una vista de muy bajo nivel.
Analicemos estos pasos uno por uno.
Definicin del Sistema.
En este paso los ingenieros de diseo inicialmente documentan las necesidades y requerimientos del proyecto usando aplicaciones de hojas de clculo o procesamiento de palabras. La
documentacin tambin se encarga de las diferentes especificaciones del motor y las diferentes normas que necesita para cumplirlas. Tambin marca los lmites de los parmetros involucrados
en controlar el motor.
Una vez que las especificaciones son documentadas, el proceso actual de diseo comienza, en el que primero se construyen un modelo de software del ECU y el motor.
Y una vez que los modelos son construidos, el tercer paso involucra simulacin de software en el ciclo. En este paso los dos modelos de software; modelo del ECU y modelo del Motor; son
conectados juntos en un ciclo cerrado y despus simulados para analizar las caractersticas dinmicas del sistema completo. Durante la simulacin el modelo del ECU monitorea la salida
desde el modelo del Motor y ajusta las entradas al modelo del Motor para mejorar el rendimiento de varias funciones del motor como inyeccin del combustible, encendido, etc.
MATRIXx tiene habilidades similares a Matlab/Simulink. Es una herramienta ideal para clientes que estn planeando construir sus modelos desde cero y estn buscando herramientas que
puedan lograr una aplicacin compleja de diseo de control y simularla a alta velocidad.
MATRIXx est hecho bsicamente de cuatro productos:1) XMath
2) SystemBuild
3) AUTOCODE
4) DocumentIt
Usando software XMath y SystemBuild, los clientes pueden modelar sus ECUs y Motores y despus usando esos modelos pueden realizar simulacin de software en el ciclo.
El software XMath es un entorno de software bsico de anlisis y visualizacin que controla SystemBuild y todo el entorno MATRIXx relacionado. Tambin ayuda a manejar datos y realizar
anlisis numrico para SystemBuild.
SystemBuild es un entorno de programacin grfica que se puede usar para modelar y simular el Motor y el sistema del Motor. Tiene una opcin de ms 80 tipos de bloques que se pueden
usar para construir modelos complejos del Motor y del ECU.
Para documentar el modelo MATRIXx tiene un producto llamado DocumentIt el cual puede crear documentos automticamente en varios formatos desde los modelos construidos en
SystemBuild.
3ra Opcin --- LabVIEW + Simulink
Si ya tiene un modelo de motor listo e integrado en Simulink y no desea re construir el modelo. Entonces hay dos opciones disponibles:
1) Al usar el Mdulo de Simulacin podemos traducir el modelo Simulink (.mdl file) existente en cdigo del diagrama de bloques de LabVIEW, lo cual se puede lograr fcilmente en un proceso
de tres pasos.
2) El Simulation Interface Toolkit (SIT) es un complemento de LabVIEW que proporciona herramientas para crear interfaz de LabVIEW para comunicarse exitosamente con un modelo
Simulink existente.
a) Comunicar directamente entre LabVIEW y el modelo Simulink. El Servidor SIT necesita iniciarse desde MATLAB para lograr esta comunicacin. El modelo Simulink tambin se puede
ejecutar en la PC principal u otra PC diferente.
b.) Ejecutar el modelo en un sistema en tiempo real al convertir el modelo Simulink a un DLL. Una vez que el DLL est construido, no son necesarios el servidor SIT ni el modelo.
Rpida Generacin de Prototipos de Control
Tambin se conoce como simulacin de modelo en el ciclo (EIL). No se debe confundir con el trmino rpida generacin de prototipos(RP) la cual se refiere a una clase de tecnologas que
pueden construir modelos fsicos automticamente desde datos de Diseo Asistido por Computadora (CAD). Para RCP, el modelo de software ECU que ha sido diseado es descargado a un
objetivo prototipo de hardware en tiempo real. El Objetivo puede ser cualquier hardware en tiempo real (idealmente un sistema PXI o un sistema cRIO). Por lo tanto, el modelo de software de
ECU proporciona interfaz de E/S la cual est conectada a sensores y actuadores sujetos al motor.
El software que se puede requerir es LabVIEW, LV RT y LV FPGA (si se usa cRIO o 7831R en PXI). Si el mdulo es construido en MATRIXx entonces un dll se puede crear a partir de l y se
puede importar a LabVIEW donde la interfaz de E/S se puede proporcionar y el cdigo se puede descargar a uno de los objetivos de hardware en tiempo real mencionados arriba. Si es un
modelo Simulink entonces despus de ser importado o traducido a LabVIEW la interfaz de E/S se puede proporcionar al mismo y despus el objetivo al Hardware RT como PXI o cRIO.
Como se mencion en la seccin de Entrada/salida, el hardware apropiado se puede usar en el PXI o cRIO dependiendo de los parmetros controlados y los sensores usados.
Objetivos
En este paso el modelo ECU principal es modificado para conectarse con la E/S disponible en el ECU actual y despus es convertido en un cdigo C usando un generador de cdigo C. En
algunos casos tambin son convertidos en un cdigo ada. Y despus este cdigo es descargado como el algoritmo de control al microcontrolador de 32 bits dentro del ECU.
Actualmente LabVIEW no tiene la habilidad o las herramientas para convertir el diagrama de bloques en un cdigo C. Por lo tanto quien est usando el paquete de diseo de control para
construir el modelo del ECU tiene que codificar manualmente el modelo en C. Aunque es tedioso hacer esto en lugar de usar un auto generador de cdigo C, muchos clientes prefieren hacerlo
ya que en la mayora de los casos el generador de cdigo C crea muchos errores en el cdigo generado, lo cual es difcil de depurar.
De cualquier manera si el cliente est usando MATRIXx para construir el modelo, entonces nosotros tenemos un producto llamado AUTOCODE el cual puede generar un cdigo C o un cdigo
ada desde el modelo SystemBuild que fue construido para el ECU.
Simulacin de Hardware en el Ciclo (HIL).
Una vez que el cdigo que contiene el algoritmo de control es descargado al ECU podemos probar el rendimiento del ECU bajo condiciones extremas, lo cual no se puede alcanzar en la
realidad al realizar simulacin HIL. En este paso el ECU actual es probado al simular un motor usando el modelo del Motor que creamos anteriormente.
Al contrario de lo que hicimos en RCP, aqu en HIL el modelo del software del Motor es descargado a un hardware en tiempo real y las interfaces de E/S apropiadas son proporcionadas. Estas
E/S son conectadas al ECU actual. Despus las diferentes condiciones del motor pueden ser simuladas y el ECU puede ser probado bajo sus lmites, lo cual no sera posible si fuera probado
usando un Motor actual.
.
Otra vez, como el RCP el hardware para el HIL se elije de acuerdo a las seales y los sensores que se van a simular, este se puede escoger en la lista proporcionada en la seccin de
Entrada/Salida.
MATLAB y Simulink son marcas registradas de The MathWorks, Inc. Otros productos y compaas nombradas son marca registrada y nombres comerciales de sus respectivas compaas.