herramienta de ayuda semi automatizada de validación de...

Herramienta de ayuda semi automatizada de validación de códigos de error de un módulo electrónico en

vehículo.

TITULACI ÓN: Ingeniería Técnica Industrial en Electrónica Industrial

AUTOR: Marc Morillo Adán.

PONENTE: Nicolau Cañellas Alberich.

FECHA: Junio del 2012.

Departament d’Enginyeria Electronica Electrica i Automatica

Índice general PFC: Herramienta de ayuda semi automatizada de validación de códigos de error de un modulo electrónico en vehiculo.

1. ÍNDICE GENERAL

PFC: Herramienta de ayuda semi automatizada de validación de códigos de error de un modulo electrónico en vehiculo.

3

1- Índice general……………………………………………….……………………...3

2- Memoria descriptiva…………………………………………………….6

2.1- Introducción………………………………………………………………….7

2.1.1- Antecedentes …………………………………………………….….9

2.1.2- Objetivo del proyecto…………………………………………….…12

2.1.3- Solución adoptada…………………………………………………12

2.2- Sistema de Entrada y Arranque Pasivo…………………………………...15

2.2.1- Componentes del Sistema Pasivo………………………………….15

2.3- Bus CAN……………………………………………………………………..16

2.3.1 Introducción………………………………………………………...16

2.3.2 Funcionamiento general de un sistema CAN bus……….………...17

2.3.3 Topología y componentes del sistema CAN………………………..18

2.3.2.1 Bus CAN………………………………………………......18

2.3.2.2 Componente de un modulo de control electrónico………19

2.3.4 El bus CAN según el modelo OSI………………………………….19

2.3.4.1 La capa física……………………………………………..20

2.3.4.2 La capa de enlace………………………………………...22

2.3.5 Proceso de transmisión de datos en CAN………………………….23

2.3.6 Proceso de arbitraje del bus………………………………………..23

2.3.7 Tipos de tramas……………………………………………………..24

2.3.8 Formato de tramas………………………………………………….25

2.3.8.1Trama de datos…………………………………………….25

2.3.8.2Trama remotas…………………………………………….26

2.3.8.3 Trama de error……………………………………………26

2.3.8.4 Espacio entre tramas……………………………………..26

2.3.8.5 Trama de sobrecargas…………………………………….26

2.3.9 Detección y corrección de errores………………………………….27

2.3.9.1 Mecanismos de detección de Error en el bus………….....27

2.3.9.2 Mecanismos de aislamiento de módulos defectuosos...….28

2.4- Comunicaciones…………………………………………………………..…29

2.4.1- Explicación general……………………………………………..…29

2.4.2- Comunicaciones Usuario/ PC / ECU…………………………..….30

2.4.3- Comunicaciones Breakout box/ ECU………………………...…..31


4

2.5- Diagnósticos en vehiculo………………………………………………...….33

2.5.1- ISO 14229 Servicios de diagnósticos………………………...……33

2.5.2- Control de flujo………………………………………………….…33

2.5.3- Respuestas positiva………………………………………………..35

2.5.4- Respuestas Negativas……………………………………………..35

2.5.5- Servicios de diagnostico……………………………………….…..36

2.5.5.1-Servicio $10 (Control de Sesión de Diagnóstico)…..……36

2.5.5.2-Servicio $11 (Reiniciación de la ECU)………………..…38

2.5.5.3-Servicio $27 (Security Access)………………………...…39

2.5.5.4-Servicio $3E (Tester Present)………………………….…40

2.5.5.5-Servicio $22 (Lectura de datos por identificador)……….41

2.5.5.6-Servicio $2E (Escritura de datos por identificador)….….42

2.5.5.6-Servicio $19 (Lectura de información de DTCs...)………42

2.5.5.7-Servicio $14 (Elimina información de diagnostico)….….44

2.5.5.8-Servicio $31 (Control de Rutinas)………………………..45

2.6- Data trouble Codes (DTCs)…………………………………………...……46

2.6.1- Que se conoce como DTC………………………………………….46

2.6.2- Asignación de DTCs…………………………………………...…..46

2.6.3- Cuando registrar un DTC……………………………………..…..46

2.6.4- Condiciones para registrar un DTC………………………….……47

2.6.5- Reporta DTC bajo petición o de forma continua…………………47

2.6.6- Registro y borrado de DTC………………………………………..48

2.6.7- Rangos de DTCs a ser implementados……………………….……48

2.6.8- Estructura de un DTC…………………………………………..…49

2.6.9- Tipo de fallo…………………………………………………..…....49

2.6.9.1- Códigos de error del sistema…………………………..…50

2.6.10- Bits de Estado………………………………………………….….53

2.6.10.1- Contador de detección de errores……………………....54

3- Fundamentos del código desarrollado…………………………….…...57 3.1-Fundamentos y detalles de la secuencia para provocar los DTCs……..…58

3.1.1- Actuador de funciones remoto……………………………..…...…58

3.1.2- Receptor de radio frecuencia………………………………………60

3.1.3- Antennas………………………………………………………...…61

3.1.4- Unlock switch………………………………………………..….…69

3.1.5- Lock switch ……………………………………………………..…74


5

3.1.6- Latch Clutch switch ………………………………………………76

3.1.7- Latch relay …………………………………………………..……77

3.1.8- Door Handles ……………………………………………….……78

3.1.9- Medium speed CAN bus …………………………………….……79

3.2- Diagrama de flujo de la interfaz visual con el usuario……………..…..….80

4- ECU Diagnostics Tool ……………………………………………….…83 4.1 Entorno y funcionalidad……………………………………………...…84

4.1.1- Barra de estado……………………………………………………85

4.1.2- Barra de comandos…………………………………………….….85

4.1.3- Script control………………………………………………….…..86

4.1.4- Logging control……………………………………………….…..86

4.1.5- Tester Present y estado de Tx/Rx…………………………………86

4.1.6- Pantalla de visualización Tx/Rx de tramas………………………86

5- Presupuesto…………………………………………………………..…88 5.1 Resumen del presupuesto…………………………………………….…89

6- Conclusión………………………………………………….……………90 6.1 Conclusión del proyecto…………………………………………………91

7- Anexos………………………………………………………………...…92

7.1- Archivos adjuntos del proyecto……………………………………………93

7.2- Código fuente de la herramienta de validación de DTCs de la ECU……94

7.3- Código fuente de la macro Visual Basic, Informe del test………………144


6

2. MEMORIA DESCRIPTIVA


7

2 Memoria descriptiva.

2.1 Introducción

Actualmente la electrónica se ha instaurado en nuestras vidas de forma que todos aquellos elementos eléctricos y mecánicos que rodeaban nuestro entorno, han evolucionado incorporando elementos electrónicos que permiten beneficiar de grandes ventajas tanto a usuarios como a fabricantes.

Del mismo modo, los automóviles han pasado de ser un elemento básicamente mecánico, a ser un elemento mecánico controlado y equipado con elementos electrónicos que permiten, desde gestionar la respuesta del motor hasta la sintonización de canales de televisión durante la circulación.

En la actualidad existen módulos electrónicos de todo tipo que controlan elementos del motor, de la suspensión, de la apertura y cierre de las puertas, del techo solar, de las ventanas, las cámaras de aparcamiento, el sistema radio navegación y entretenimiento, los asientos eléctricos, etc.

Esta gran mejoría a nivel de confort y control, no fue tan bien aceptada por mecánicos y carroceros, ya que ha dificultado sus tareas del día a día y muchos han tenido que recurrir a la adquisición de nuevas herramientas para el diagnostico de problemas.

Para que el uso de estas herramientas de diagnostico sea posible, los módulos electrónicos instalados en el vehiculo, deben poder ser capaces de monitorizar y registrar, los errores que ocurran en los componentes de su sistema y poder reportarlos cuando la herramienta de diagnostico lo solicite. Estos registros de error son conocidos en el mundo de la automoción como “DTC’s” o “Data Trouble Codes”.

Los errores reciben un código único y exclusivo para cada componente de manera que un DTC registrado no dé lugar a la confusión entre otros componentes y módulos. Los DTCs se registran en la memoria EEPROM de la ECU en confirmarse, previo un proceso interno de detección de error, la existencia de una anomalía en alguna de sus entradas y/o salidas. El DTC también provee información que le permite identificar no solo el componente sino el motivo del fallo.

Las herramientas de diagnostico utilizadas en taller se basan en un ordenador que mediante la interfaz adecuada, permite conectarse al bus CAN del vehiculo a través del conector J1962 que equipan los vehículos actualmente como Estándar (véase figura 1). El computador es capaz de comunicarse con los módulos electrónicos que penden del bus CAN y solicitar a cada uno de ellos un informe acerca de su estado. Dada la petición, los módulos responden al PC informándole de los DTCs que han sido registrados. Debido a que todos los módulos están conectados al mismo bus de comunicaciones y la información es vista por todas las ECUs, la petición del Tester (computador), consiste en el envío de una trama de datos compuesta por un comando especifico de diagnostico para la solicitud del registro de DTCs almacenados y un identificador que permite a la ECU reconocer quien solicita la información. El proceso de respuesta por parte del modulo electrónico también sigue los mismos criterios, es decir, en este caso, la ECU responderá con una trama donde conste la información solicitada por el Tester y un identificador, propio de la ECU que el Tester deberá reconocer.


8

Figura 1. Ejemplo esquema de comunicación Tester / ECU.

Los DTCs son de gran utilidad ya sea desde el punto de vista de ingeniería como desde el punto de vista de los talleres de reparación. Para la ingeniería, los DTC’s aportan pistas que ayudan a esclarecer posibles fallos que estén ocurriendo en el sistema o causando comportamientos inesperados ayudando a encontrar la causa raíz. Desde el punto de vista de un taller de reparación, informan al operario a cerca de que componente debe reparar permitiendo grandes beneficios debido al ahorro de tiempo de investigación y evitando el hecho de substituir sistemas completos debido a un simple fallo en un componente que pueda ser reemplazado con un bajo coste.

Previo a que un vehiculo este disponible de venta al publico, debe antes pasar por una etapa de progreso que comprende varias fases para asegurar que el vehiculo llegara al mercado final sin defectos.

Centrándonos en los módulos electrónicos o mas bien conocidos como ECUs (Electronic Control Units), se deberá tener siempre en cuenta que el desarrollo del producto debe realizarse en base a las especificaciones solicitadas por el cliente (en este caso la compañía automovilística que desea incorporar dicho producto en su vehiculo) y cumpliendo con las normativas y Estándares que exige la industria de la automoción.

Cada ECU, se someterá a diversos tipos de tests para verificar su comportamiento y respuesta en base a los requerimientos.

Bus CAN

J1962 ECU 1 ECU 4

ECU 2 ECU 3 ECU 5

Interfaz hardware de CAN

TESTER


9

Mientras los Ingenieros de Diseño, Chasis y Motor, entre otros, crean la parte visible del automóvil, los Ingenieros de módulos electrónicos desarrollan por su parte las ECU que se integraran en el vehiculo y se procede al testeo en laboratorios con cargas no reales y entornos simulados.

La siguiente etapa consiste en la integración de todos los módulos electrónicos en Labcars1 y coches Prototipo2. De este modo, finalizan las simulaciones individuales en laboratorios para dar paso al entorno real donde se interactúa directamente a través del bus CAN con los demás módulos que penden de él trabajando así con cargas no simuladas.

Figura 2. Fases del vehiculo desde el punto de vista de los módulos electrónicos.

2.1.1 Antecedentes del proyecto

La marca de automóviles Kotse Limited incorpora desde hace años en sus coches el sistema de entrada y arranque pasivo, y decide durante una etapa de cambios, renovar y escoger otro fabricante de módulos de control electrónicos para que continúe y se encargue del desarrollo y la integración de dicho sistema para las futuras plataformas de la firma de la marca.

El cambio de fabricante requiere una transición lo menos brusca posible para que la adaptación de las características de un sistema al otro, no altere el correcto funcionamiento de los demás módulos electrónicos que incorporan los vehículos y que utilizan el mismo bus de comunicaciones, en este caso el CAN de 125 Kbit/s.

______________________

1) Estructura metálica la cual pretende simular el habitáculo de una vehiculo y que permite posicionar los módulos electrónicos en el lugar asignado.

2) Vehiculo real de apariencia similar al diseño, construido básicamente con partes y módulos que siguen en fase de desarrollo y que se utilizan a modo experimental para pruebas. Se les conoce también como coches de ingeniería, y se permite modificar, re-trabajar y alterar sus partes o componentes sin seguir las normativas estipuladas. Pasan por distintas fases hasta llegar al vehiculo final.

Desarrollo en Laboratorio

Labcar

Prototipo Fase I

Prototipo Fase III

Prototipo Fase II

Prototipo Fase…

Vehiculo Final:

Inicio producción


10

El cambio de fabricante requiere una transición lo menos brusca posible para que la adaptación de las características de un sistema al otro, no altere el correcto funcionamiento de los demás módulos electrónicos que incorporan los vehículos y que utilizan el mismo bus de comunicaciones, en este caso el CAN de 125 Kbit/s.

Inevitablemente, la incorporación de nuevas funcionalidades y mejoras, la propia naturaleza de los componentes del antiguo sistema frente al nuevo y, la continua adaptación a los Estándares de la industria de la automoción, en cuanto a diagnósticos se refiere, hacen que el comportamiento a nivel de detalle del sistema recién llegado varíe considerablemente respecto al anterior.

Las mencionadas variaciones que distinguen a un sistema del otro también se reflejan en los protocolos de validación3 ya existentes en los archivos de la compañía Kotse Limited como legado del anterior fabricante de módulos de control electrónicos. Los protocolos de validación de sistemas, se utilizan en este caso, durante las diferentes etapas de desarrollo de los vehículos y previo a la fase de producción en serie de los automóviles.

La empresa Kotse Limited requiere de un ingeniero de validación permanente en sus instalaciones de ingeniería y desarrollo de vehículos prototipo, que se encargue de asegurar de forma empírica que el sistema electrónico se comporta en el vehiculo según lo esperado y conforme a los resultados de los test que marcan los protocolos de funcionalidad y DTCs.

El ingeniero se percata de carencias y errores en los antiguos protocolos de validación de DTCs heredados del anterior proveedor y listados a continuación:

• No se cubren la totalidad de los requerimientos exigidos por cliente.

• No se sigue una estructura adecuada.

• Existen erratas graves mezclando conceptos y resultados que dan lugar a la confusión y fallos.

• No se indican los pasos a seguir ni el procedimiento necesario para la validación.

• No están adaptados al nuevo sistema de control electrónico.

El hecho de no disponer de un protocolo de validación adecuado, que cumpla los puntos listados anteriormente, implica la imposibilidad de testear el funcionamiento completo del sistema electrónico y afecta consecuentemente a la evolución y desarrollo del vehiculo. Esta situación puede generar la consideración por parte de Kotse Limited de posponer la fabricación en serie del vehiculo, en caso de que dichos tests no se comprueben y se superen estando el vehiculo en su ultima etapa de desarrollo.

_________________________

3) Protocolos de validación: Un protocolo de validación es un documento donde se definen casos de test conforme a la especificación y requerimientos que ha definido el cliente, solicitante del modulo electrónico. Se utilizan como guía para comprobar y verificar si el modulo se comporta según lo esperado en función de unas condiciones u otras de test. Se dice que un protocolo de validación se considera infinito y que nunca se llegan a cubrir todas las opciones posibles a testear, debido a la gran cantidad de componentes y de factores que se deben tener en cuenta lo cual conlleva la generación de una cantidad infinita de combinaciones disponibles.


11

La validación de DTCs en vehiculo requiere de amplios conocimientos del sistema electrónico a testear y de los medios necesarios para comunicar, ejecutar y comprobar las reacciones y respuestas del conjunto ECU/ Vehiculo.

Las herramientas imprescindibles para la validación de diagnósticos en vehiculo son:

• PC con el software pertinente para el análisis de diagnósticos subministrado en Kotse Limited. (ECU Diagnostics Tool).

• Interfaz Hardware de CAN para la comunicación PC/Bus CAN. (CANcaseXL de Vector).

• Cable OBDII a DB9 para la adaptación entre el conector universal On-Board Diagnostics a la interfaz Hardware de CAN.

• Breakout Box4

Por otro lado, se requiere la intervención del ingeniero de validación para ejecutar acciones físicas tales como: alterar las conexiones de la breakout box, pulsar los interruptores de cierre o apertura del vehiculo, apertura de las puertas mediante los tiradores de las mismas, cambiar componentes del sistema, pulsar el interruptor de arranque de motor en el vehiculo, pulsar los diferentes botones de las llaves control remoto, etc. Además el ingeniero debe cumplir con las siguientes aptitudes:

• Disponer de una visión global de la diferentes funcionalidades del vehiculo.

• Tener un buen conocimiento del funcionamiento del sistema a validar.

• Estar familiarizado con herramientas de diagnostico y detección de errores en vehiculo.

• Conocimiento de los servicios y rutinas de diagnostico necesarias y específicas del modulo para el envío de tramas por CAN a través de la herramienta de diagnóstico.

• Reconocer correctamente la interpretación de las tramas enviadas y recibidas por el bus y mostradas en la pantalla de visualización del ECU Diagnostics Tool.

Las características que requiere el ingeniero de validación y los inconvenientes causados por la falta de un buen protocolo de test se acentúan aun más por las siguientes razones:

• La carga de trabajo del ingeniero de test impuesta por el ritmo frenético del mundo de la automoción debido al desarrollo continuado de nuevos vehículos implica que el validador no pueda atender como debiera el proceso de validación.

____________________

4) La breakout box (BoB) es un dispositivo de test intercalado entre el cableado del vehiculo y la ECU. Incorpora puentes eléctricos para cada una de las I/O del modulo y permiten al usuario realizar mediciones, provocar cortocircuitos, forzar cargas abiertas etc. Sin necesidad de perturbar los cables o la placa PCB.


12

• Los cambios laborales, que se producen a nivel interno de la empresa o debido a decisiones personales que conllevan un cambio laboral, fomentan la perdida del conocimiento

Los motivos numerados anteriormente conllevan a que puedan existir DTCs que no hayan sido debidamente testeados, la existencia de errores debido a la confusión y la falta de conocimientos, limitación de las personas capaces de validar los códigos de error en vehiculo y el gran numero de horas invertidas para ello. Como dato, la media oscila actualmente entre 24 y 40 horas de trabajo lo que implica cerca de una semana de trabajo para la validación de DTCs. El proceso de validación se repite alrededor de 12 o mas veces anualmente en función de las plataformas previstas a construir y los cambios de software que se realicen en el modulo.

El coste que esto supone a nivel empresarial es de aproximadamente:

40h x 50 € = 2000 € / Validación de DTCs. (1)

2000 € x 12 = 24000 € / Anuales. (2)

2.1.2 Objetivo del proyecto

El objetivo de este proyecto es implementar un herramienta que permita testear los “Data trouble Codes” del sistema de entrada y arranque pasivo en un vehiculo prototipo de forma rápida y sencilla por cualquier usuario y en base a los requerimientos exigidos por cliente y los Estándares de automoción. Además, la herramienta deberá poder generar un informe con los resultados obtenidos durante las pruebas.

La herramienta deberá comunicarse con el modulo mediante el bus de comunicación CAN y a través del conector OBD-II del vehiculo.

2.1.3 Solución adoptada

Haciendo uso de las herramientas existentes para la comunicación entre PC/ Vehiculo/ ECU y la validación de DTCs, se decide que la mejor forma de cumplir con las expectativas del objetivo del proyecto y solventar además la problemática explicada en el punto 2.1.1 será (véase figura 3):

• Protocolo de validación de DTCs: Se confeccionara un protocolo de validación de DTCs de acuerdo a los requerimientos del nuevo sistema y en base a las normativas impuestas por los Estándares de Automoción referente a cómo debe responder un modulo de control electrónico, ante peticiones de diagnostico por parte del Tester (véase capitulo…). El formato típico de protocolos de validación consiste en un archivo de Microsoft Excel donde exponen fila a fila las condiciones previas del test, el procedimiento para la ejecución de fallos, la respuesta esperada y el resultado real obtenido. Además, se añadirá una pagina


13

principal donde se mostraran los datos mas relevantes del sistema a validar y que permitirán llevar una trazabilidad para el análisis y comparación de los resultados de los test, en función de la plataforma de vehiculo que se pretende validar y la versión de software y hardware de la ECU del sistema de entrada y arranque pasivo. Estos parámetros informaran de: identificador del vehiculo, tipo de sistema de entrada y arranque pasivo, versión de hardware y software de los diferentes componentes que forman el sistema de entrada y arranque pasivo, la frecuencia del receptor (véase 2.2) y parámetros de configuración y estado de los componentes. Un botón situado en la primera hoja del protocolo y vinculado a una Macro de Visual Basic, permitirá recoger los resultados obtenidos durante los tests y emplazarlos en la adecuada casilla de resultados. El protocolo de validación corresponde al archivo “DTC Validation Protocol.xls”.

• DTC_Checker.c: El ECU Diagnostics Tool es una solución informática la cual posibilita al usuario el envío y recepción de tramas de diagnostico entre un PC (Tester) y una ECU (se requiere interfaz hardware de CAN para dicha comunicación). La herramienta permite trabajar de modo manual o mediante Scripts. El Script consiste en un archivo en código de programación C que correrá bajo el entorno del ECU Diagnostics Tool y permitirá envíos consecutivos y periódicos de tramas de diagnósticos las cuales serian tediosas y duraderas de ser ejecutadas manualmente. De este modo se conseguirá un gran ahorro en el tiempo de validación. Por otro lado, para evitar que la validación este limitada a la persona con conocimientos sobre DTCs, el Script permitirá la creación de un asistente que mediante menús mostrados por pantalla guiaran al técnico durante la validación permitiendo navegar por los menús para seleccionar que DTCs se desea testear. A su vez, durante el guiado, el script esta programado para enviar servicios de diagnostico cuando sea necesario, controlar los tiempos de envío y almacenar los mensajes de comunicación entre la ECU y el Tester en un archivo de texto (Log file). El Script corresponde al archivo “DTC Checker.c”.

• Log file: Consiste en un archivo formato texto que será habilitado al inicio de la validación por parte del DTC_Checker.c y donde se almacenara el trafico de datos de CAN enviados entre el Tester y la ECU.

• Macro de Visual Basic: La Macro será programada para realizar la lectura de la información almacenada en el Log file y la cargarla en la celda correspondiente del protocolo de validación haciendo a su vez una comparativa entre la respuesta esperada y la respuesta recibida.

• Usuario: La función del usuario consistirá en seguir las instrucciones mostradas por pantalla por el DTC_Cheker realizando acciones sobre elementos del vehiculo tales como pulsar interruptores, abriendo y cerrando puertas, pulsando el botón start/stop de arranque etc. Además de provocar cortocircuitos a tierra, a batería o circuitos abiertos cuando se requiera trabajar sobre la breakout box.


14

Figura 3. Esquema general de los módulos que integran la solución adoptada.

DTC_CHECKER.c

- Entorno visual menú de usuario.

- Guía por pantalla durante la validación.

- Envío de tramas de diagnostico ECU

- Lectura DTCs ECU.

- Log file.

ECU DIAGNOSTICS TOOL

Breakout Box Usuario

Log File

Macro VB

Protocolo en Microsoft Excel; RESULTADOS

VALIDACION DTCs

Vehiculo

Bus CAN

MODULO DE CONTROL ELECTRONICO

Entras / Salidas

Salidas / Entradas


15

2.2 Sistema de Entrada y Arranque Pasivo

El Sistema de Entrada y Arranque Pasivo se divide en dos partes:

• El sistema de entrada pasiva permite al usuario la apertura3 o cierre4 de cualquier puerta del vehiculo, incluido el maletero, sin necesidad pulsar el correspondiente botón de la llave. Para ello, en el momento de la acción, la llave5, ha de situarse a una distancia máxima de dos metros de la puerta que se pretende abrir o cerrar y haber sido reconocida y aceptada por la ECU. Además de esta peculiar característica, la llave sigue manteniendo la función de control remoto y ejecuta la misma función cuando cualquiera de sus botones sea pulsado.

• El sistema de arranque pasivo, permite al usuario el arranque del vehiculo sin necesidad de insertar la llave en ninguna ranura, simplemente deberá encontrarse en el interior del automóvil y ser reconocida como un dispositivo valido.

2.2.1 Componentes del Sistema de Entrada y Arranque Pasivo.

1- Actuador de Frecuencia Remota (AFR): Es la ECU principal del sistema y el único que interactúa con las demás ECU del vehiculo vía bus de comunicaciones CAN de media velocidad (125kbits/sec.). Los demás componentes del sistema de Entrada y arranque pasivo se encuentran conectados al AFR que se encarga de recibir, gestionar y transmitir las señales oportunas.

Existen dos variantes del modulo AFR, una de 2 conectores que únicamente permite la función de arranque pasivo y otra de 3 conectores que permite la entrada y el arranque pasivos.

2- Receptor de radio frecuencia (RRF): Se encuentra conectado al modulo principal (AFR) mediante un bus de una única vía de comunicación (K-line, ISO9141). Se encarga de captar la señal RF (radio frecuencia) transmitida por la llave, ante una petición de cierre, apertura o arranque del vehiculo. Existen 2 variantes, uno de 315 MHz y otro de 434 MHz que cubren los mercados a nivel mundial ya que existen discrepancias en las normativas que estipulan las frecuencias para tal uso entre unos y otros.

______________________

3 La apertura de las puertas se dará de forma inmediata en accionar el tirador de la puerta. En el caso del maletero se efectuara en pulsar un interruptor.

4 Para el cierre o bloqueo de las puertas será suficiente con pulsar cualquiera de los interruptores que se encuentra integrados en los tiradores.

5 Cada una de las llaves fabricadas contiene un código único que es registrado en la ECU principal durante el proceso de fabricación del vehiculo de modo que solo será identificada como valida en dicho modulo.


16

3- Llave electrónica (PK): Conocido también como CID (Dispositivo Identificador de Cliente) permite al usuario la apertura, cierre o arranque del vehiculo. La llave es propiamente un transductor que posibilita captar las señales LF que transmiten las antenas del vehiculo y transmitir señales RF para comunicarse con el RRF. También dispone de dos variantes (315 y 434 MHz) que deberán contrastar con las del RRF.

4- Antenas de baja frecuencia (LF): Estas se encuentran distribuidas en cada una de las manetas, en el maletero y en el interior del vehiculo y son alimentadas por el AFR. Son activadas cuando se recibe la petición de cerrar, abrir o arrancar el vehiculo y su función es transmitir una señal LF que será captada por la llave si se encuentra en un radio cercano.

5- Lock/unlock switch: Los interruptores de cierre se encuentran integrados en cada una de las manetas de las puertas y conectados al AFR. Su accionamiento provoca la activación de la antena LF asociada para posteriormente bloquear o desbloquear las puertas. Existen tipo interruptor y tipo sensor capacitivo.

6- Clutch switch: El clutch switch es activado en el momento que uno de los tiradores de las puertas es accionado solo durante la acción de apertura y da paso a la actuación del “E-Latch motor”.

7- E-Latch Motor: Cada una de las puertas contiene un motor que permite mover el pestillo de forma rápida consiguiendo que el usuario no detecte ningún tipo de resistencia en abrir la puerta de forma enérgica.

Figura 4. Diagrama del sistema.


17

2.3 CAN bus

2.3.1 Introducción

Los módulos electrónicos del vehiculo se encuentran comunicados entre si vía CAN. El “Controller Área Network”, o bus CAN, es un protocolo de comunicación serie que permite el intercambio de datos en tiempo real entre las unidades de control electrónicas existentes en un vehiculo.

Fue desarrollado por la firma alemana Bosch en 1982 con la finalidad de reducir el cableado y consecuentemente los costes en la fabricación de automóviles. Para ello se basa en una arquitectura multimaster la cual permite compartir información entre las unidades de control conectadas a la red. Un claro ejemplo seria que cuando una ECU dispone de una información, como por ejemplo, la temperatura del motor, esta puede ser utilizada por el resto de unidades de mando sin ser necesaria la conexión directa de cada modulo al sensor que mide los grados del motor, únicamente bastaría con monitorizar en el bus la información publicada por el modulo de control permitiendo así ahorrar costes en cableado e incluso sensores.

Su bajo coste de implementación, la capacidad de trabajar en tiempo real, su sencillez, su fiabilidad, su robustez incluso en entornos no amigables eléctricamente hablando (vibraciones, altas temperaturas, interferencias…) y su velocidad (hasta 1Mbit/s) lo han convertido en un protocolo abierto de alta seguridad usado en la industria de la automoción y otros sectores como en trenes, barcos, sistemas de control distribuido o automatización industrial.

2.3.2 Funcionamiento general de un sistema CAN bus

Las Unidades Electrónicas de Control que se conectan al sistema CAN Bus son las que necesitan compartir información, pertenezcan o no a un mismo sistema. Gracias a la arquitectura multi-maestro, se permite ejercer de master de comunicaciones a todos los nodos y ser capaces de transmitir datos y/o solicitar el bus simultáneamente.

El sistema CAN bus está orientado hacía el mensaje y no al destinatario de modo que la información en la línea es trasmitida en forma de mensajes estructurados en la que una parte del mismo es un identificador que indica la clase de dato que contiene.

Todas las unidades de control reciben el mensaje, lo filtran y solo lo emplean las que necesitan dicho dato. Naturalmente, la totalidad de unidades de control abonadas al sistema son capaces tanto de introducir como de recoger mensajes de la línea. Cuando el bus está libre cualquier unidad conectada puede empezar a trasmitir un nuevo mensaje.

En el caso de que una o varias unidades pretendan introducir un mensaje al mismo tiempo, lo hará la que tenga una mayor prioridad. Esta prioridad viene indicada por el identificador.

El sistema CAN Bus dispone de mecanismos para detectar errores en la trasmisión de mensajes, de forma que todos los receptores realizan un chequeo del mensaje analizando una parte del mismo, llamado campo CRC. Otros mecanismos de control se


18

aplican en las unidades emisoras que monitorizan el nivel del bus, la presencia de campos de formato fijo en el mensaje (verificación de la trama), análisis estadísticos por parte de las unidades de mando de sus propios fallos… Estas medidas hacen que las probabilidades de error en la emisión y recepción de mensajes sean muy bajas, por lo que es un sistema extraordinariamente seguro.

2.3.3 Topología y componentes del sistema CAN

Figura 5. Ejemplo de la topología del bus CAN con varios nodos en un vehiculo.

2.3.3.1 Bus CAN

Físicamente, consiste en un par de cables trenzados (CAN High & CAN Low), a los que se unen las unidades electrónicas de control (nodos) y por donde circula la información. Esta información se trasmite por diferencia de tensión entre los dos cables, de forma que un valor alto de tensión representa un 1 y un valor bajo de tensión representa un 0. La combinación adecuada de unos y ceros (bits), conforman el mensaje a trasmitir. Además, dos resistencias de terminación deben conectarse a ambos extremos de las líneas de transmisión y su valor varia en función de la longitud y la velocidad a la que se pretenda transmitir.


19

2.3.3.2 Componentes de un Modulo de Control Electrónico

Para que cada nodo se capaz publicar el estado de los sensores o conocer las acciones que realiza otra unidad electrónica de control existente en el bus, será necesario adaptar las diferentes señales para que se produzca la comunicación de todos los componentes que forman la red. Para ello se deberán conocer los componentes integrados en cada ECU que facilitan dicho proceso:

Transmisor / Receptor: El transmisor-receptor es el elemento que tiene la misión de recibir y de trasmitir los datos, además de acondicionar y preparar la información para que pueda ser utilizada por los controladores. Esta preparación consiste en situar los niveles de tensión de forma adecuada, amplificando la señal cuando la información se vuelca en la línea y reduciéndola cuando es recogida de la misma y suministrada al controlador.

Controlador: Es el elemento encargado de la comunicación entre el microprocesador de la unidad de control y el trasmisor-receptor. Trabaja acondicionando la información que entra y sale entre ambos componentes. El controlador está situado en la unidad de control, por lo que existen tantos como unidades estén conectados al sistema. Este elemento trabaja con niveles de tensión muy bajos y es el que determina la velocidad de trasmisión de los mensajes, que será más o menos elevada según el compromiso del sistema. Por norma general, la línea de CAN del motor, frenos, o elementos de seguridad es de 500 Kbit/s, y en el sistema de confort de 125 Kbit/s.

Figura 6. Componentes en la Unidad Electrónica de Control.

Microcontrolador: Como cerebro de la unidad electrónica de control, este recibe directamente el estado de los sensores y actuadores conectados a sus pines y el estado de sensores y actuadores ajenos controlados por otros nodos recibiendo dicha información en forma de trama a través del bus CAN.


20

Del mismo modo en función de la información recibida, o simplemente debido a una tarea programada, el microcontrolador dirige sus salidas e inicia el envío de tramas a ser publicadas en el bus y que serán leídas por aquellas unidades que se encuentren subscritas a la unidad electrónica.

2.3.4 El bus CAN según el modelo OSI.

La especificación del protocolo CAN de Bosch 2.0 fue estandarizado según la norma ISO 11898 y abarca la capa física, la capa de enlace y la de aplicación del modelo OSI (Open System Interconnection). El modelo es una normativa formada por siete capas que define las diferentes fases por las que deben pasar los datos para viajar de un dispositivo a otro sobre una red de comunicaciones.

Figura 7. Modelo OSI aplicado a CAN.

2.3.4.1 La capa física

Define los aspectos del medio físico para la transmisión de datos entre nodos de una red CAN, los más importantes son niveles de señal, representación, sincronización y tiempos en los que los bits se transfieren al bus. La especificación del protocolo CAN no define una capa física, sin embargo, los estándares ISO 11898 establecen las características que deben cumplir las aplicaciones para la transferencia en alta y baja velocidad.

La capa física se divide en:

• PLS (“Physical Signalling”): Codificación de bit, tiempo de bit y sincronización.

• PMA (“Physical Medium Attachment”): Características Receptor/Transmisor.

• MDI (“Medium Dependent Interface”): Conector de bus.


21

Como características mas relevantes se encuentra que el bus debe constar de un par de cables trenzados para la anulación de campos magnéticos, (CAN_H y CAN_L) los cuales constituyen la transmisión de línea por donde circulara la información.

Los nodos conectados al bus interpretan dos niveles lógicos:

Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2’0 V con CAN_H = 3’5V y CAN_L = 1’5V (nominales). Equivale al “0 lógico.

Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 0V con CAN_H = CAN_L = 2.5V (nominales). Equivale al “1 lógico

.

Figura 8. Representación de los niveles lógicos del bus CAN.

La comunicación en el bus fluye en ambos sentidos así que será necesario dotar de

resistores de terminación a sus extremos para evitar el fenómeno de la reflexión el cual provocaría errores de comunicación. Normalmente dichas resistencias oscilan los 120 ohmios aunque se deberá tener en cuenta la velocidad de transmisión, la longitud de la red, impedancias de la línea, etc.

Figura 9. Imagen de una señal incorrecta en un bus sin resistencias de terminación.


22

Figura 10. Imagen de una señal en un bus con resistencias de terminación.

El transceptor de CAN, el cual forma parte de la capa física, permite además de

adaptar las señales entre el bus y el controlador, la detección de errores en el bus tales como roturas de cable, cortocircuitos, cortos a tierra, etc.

Como ventajas se puede destacar que el bus CAN funciona independientemente de:

• Cualquiera de los dos alambres en el bus esta cortado.

• Cualquier alambre se pone en cortocircuito a la alimentación.

• Cualquier alambre se pone en cortocircuito a tierra.

2.3.4.2 La capa de enlace

Define las tareas independientes del método de acceso al medio, además debido a que una red CAN brinda soporte para procesamiento en tiempo real a todos los sistemas que la integran, el intercambio de mensajes que demanda dicho procesamiento requiere de un sistema de transmisión a frecuencias altas y retrasos mínimos. En redes multi-maestro, la técnica de acceso al medio es muy importante ya que todo nodo activo tiene los derechos para controlar la red y acaparar los recursos. Por lo tanto la capa de enlace de datos define el método de acceso al medio así como los tipos de tramas para el envío de mensajes.

La capa de enlace se divide en:

• LLC (“Logical Link Control”): Filtración de los mensajes, notificaciones de sobrecarga y administración de la recuperación.

• MAC (“Medium Access Control”): Es el núcleo del protocolo CAN y gestiona el tramado y desentramado de los mensajes, el arbitraje a la hora de acceder al bus y el reconocimiento de los mensajes, así como el chequeo de posibles errores y su señalización, el aislamiento de fallos en unidades de control y la identificación del estado libre del bus para iniciar una transmisión o recepción de un nuevo mensaje.


23

Cuando un nodo necesita enviar información a través de una red CAN, puede ocurrir que varios nodos intenten transmitir simultáneamente. CAN resuelve lo anterior al asignar prioridades mediante el identificador de cada mensaje, donde dicha asignación se realiza durante el diseño del sistema en forma de números binarios y no puede modificarse dinámicamente. El identificador con el menor número binario es el que tiene mayor prioridad.

El método de acceso al medio utilizado es el de Acceso Múltiple por Detección de Portadora, con Detección de Colisiones y Arbitraje por Prioridad de Mensaje (CSMA/CD+CR (Carrier Sense, Multiple Access/Collision Detection and Collision Resolution). De acuerdo con este método, los nodos en la red que necesitan transmitir información deben esperar a que el bus esté libre (detección de portadora). Cuando se cumple esta condición, dichos nodos transmiten un bit de inicio (acceso múltiple). Cada nodo lee el bus bit a bit durante la transmisión de la trama y comparan el valor transmitido con el valor recibido; mientras los valores sean idénticos, el nodo continúa con la transmisión; si se detecta una diferencia en los valores de los bits, se lleva a cabo el mecanismo de arbitraje.

2.3.5 Proceso de trasmisión de datos en CAN

Suministro de datos: Una unidad de mando recibe información de los sensores que tiene asociados (rpm. Del motor, velocidad, temperatura del motor, puerta abierta, etc.) Su microprocesador pasa la información al controlador donde es gestionada y acondicionada para a su vez ser pasada al trasmisor-receptor donde se transforma en señales eléctricas.

Trasmisión de datos: El controlador de dicha unidad transfiere los datos y su identificador junto con la petición de inicio de trasmisión, asumiendo la responsabilidad de que el mensaje sea correctamente trasmitido a todas las unidades de mando asociadas. Para trasmitir el mensaje ha tenido que encontrar el bus libre, y en caso de colisión con otra unidad de mando intentando trasmitir simultáneamente, tener una prioridad mayor. A partir del momento en que esto ocurre, el resto de unidades de mando se convierten en receptoras.

Recepción del mensaje: Cuando la totalidad de las unidades de mando reciben el mensaje, verifican el identificador para determinar si el mensaje va a ser utilizado por ellas. Las unidades de mando que necesiten los datos del mensaje lo procesan, si no lo necesitan, el mensaje es ignorado.

2.3.6 Proceso de arbitraje del bus

Un nodo al comenzar la transmisión de un mensaje, monitoriza constantemente el estado del bus. Si durante la transmisión del campo de arbitraje, detecta en el bus un bit dominante cuando el bit transmitido por ese nodo ha sido recesivo, detiene su transmisión y continua recibiendo la trama monitorizada en el bus. De esta forma no hay pérdida de información y no se destruye por colisión, ninguna trama de datos o remota.


24

Figura 11 Arbitraje en el bus CAN.

En un bus único, un identificador de mensaje ha de ser asignado a un solo nodo concreto, es decir, se ha de evitar que dos nodos puedan iniciar la transmisión simultánea de mensajes con el mismo identificador y datos diferentes. La filosofía del protocolo CAN dice que cada mensaje es único en el sistema. Por ejemplo, si en un automóvil existe la variable "presión de aceite", esta variable ha de ser transmitida por un nodo concreto, con un identificador concreto, con longitud fija y coherente con la codificación de la información en el campo de datos.

2.3.7 Tipos de tramas

El mensaje es una sucesión de “0” y “1” representados por diferentes niveles de tensión en los cables del CAN Bus. La sucesión de “0” y “1” conforman el mensaje que se transmite en el bus. Esta compuesto por una serie de campos de diferente tamaño (número de bits) que permiten llevar a cabo el proceso de comunicación entre las unidades de mando según el protocolo definido por Bosch para el bus CAN, que facilitan desde identificar a la unidad de mando, como indicar el principio y el final del mensaje, mostrar los datos, permitir distintos controles, etc. Existen diversos tipos de tramas:

Trama de datos: Información útil que se transmite en "broadcast" a todos los demás nodos. Puede incluir entre 0 y 8 Bytes de información.

Trama de interrogación remota o trama remota: Es utilizada por un nodo para solicitar datos con la información asociada a un identificador dado. El nodo que disponga de la información definida por el identificador transmitirá una trama de datos.

Tramas de error: Usadas para señalar al resto de nodos la detección de un error, invalidando el mensaje erróneo.

Trama de sobrecarga: Indica que un nodo esta en sobrecarga y fuerza a los demás alargar el tiempo entre transmisión de tramas.

Espaciado entre tramas: Las tramas se separan entre si por una secuencia predefinida.

Bus en reposo: Cuando no se envían tramas, el bus mantiene constantemente el nivel recesivo.


25

2.3.8 Formato de las tramas

2.3.8.1 Trama de datos

La trama de datos se divide en los campos mostrados en la figura inferior.

Figura 12 Formato de una trama de datos (11 bit).

Campo de inicio del mensaje: El mensaje se inicia con un bit dominante, cuyo flanco descendente es utilizado por las unidades de mando para sincronizarse entre sí.

Campo de arbitrio: Los 11 bit de este campo se emplean como identificador que permite reconocer a las unidades de mando la prioridad del mensaje. Cuanto más bajo sea el valor del identificador más alta es la prioridad, y por lo tanto determina el orden en que van a ser introducidos los mensajes en la línea.

El bit RTR indica si el mensaje contiene datos (RTR=0) o si se trata de una trama remota sin datos (RTR=1). Una trama de datos siempre tiene una prioridad más alta que una trama remota. La trama remota se emplea para solicitar datos a otras unidades de mando o bien porque se necesitan o para realizar un chequeo.

Campo de control: Este campo informa sobre las características del campo de datos. El bit IDE indica cuando es un “0” que se trata de una trama estándar y cuando es un “1” que es una trama extendida. Los cuatro bit que componen el campo DLC indican el número de bytes contenido en el campo de datos.

La diferencia entre una trama estándar y una trama extendida es que la primera tiene 11 bits y la segunda 29 bits. Ambas tramas pueden coexistir eventualmente, y la razón de su presencia es la existencia de dos versiones de CAN.

Campo de datos: En este campo aparece la información del mensaje con los datos que la unidad de mando correspondiente introduce en la línea Can-Bus. Puede contener entre 0 y 8 bytes (de 0 a 64 bit).


26

Campo de aseguramiento (CRC): Este campo tiene una longitud de 16 bit y es utilizado para la detección de errores por los 15 primeros, mientras el último siempre es un bit recesivo (1) que delimita el campo CRC.

Campo de confirmación (ACK): El campo ACK esta compuesto por dos bit que son siempre trasmitidos como recesivos (1). Todas las unidades de mando que reciben el mismo CRC modifican el primer bit del campo ACK por uno dominante (0), de forma que la unidad de mando que está todavía trasmitiendo reconoce que al menos alguna unidad de mando ha recibido un mensaje escrito correctamente. De no ser así, la unidad de mando trasmisora interpreta que su mensaje presenta un error.

Campo de final de mensaje (EOF): Este campo indica el final del mensaje con una cadena de 7 bits recesivos. Puede ocurrir que en determinados mensajes se produzcan largas cadenas de ceros o unos, y que esto provoque una pérdida de sincronización entre unidades de mando. El protocolo CAN resuelve esta situación insertando un bit de diferente polaridad cada cinco bits iguales: cada cinco “0” se inserta un “1” y viceversa. La unidad de mando que utiliza el mensaje, descarta un bit posterior a cinco bits iguales. Estos bits reciben el nombre de bit stuffing.

2.3.8.2 Trama remota

El formato es el mismo que la trama de datos pero con el bit RTR recesivo. No incluye datos. El identificador es el del mensaje que se solicita, el campo longitud corresponde a la longitud de ese mensaje

2.3.8.3 Trama de error

Las tramas de error son generadas por cualquier nodo que detecte un error. Consiste en dos campos: Indicador de error ("Error Flag") y Delimitador de error. El delimitador de error consta de 8 bits recesivos consecutivos y permite a los nodos reiniciar la comunicación limpiamente tras el error. El Indicador de error es distinto según el error

2.3.8.4 Espacio entre tramas

El espacio entre tramas separa una trama de la siguiente trama. El espacio entre tramas ha de constar de, al menos, 3 bits recesivos. Una vez transcurrida esta secuencia un nodo puede iniciar una nueva transmisión o el bus permanecerá en reposo. Para un nodo en estado error pasivo la situación es diferente, deberá espera una secuencia adicional de 8 bits recesivos antes de poder iniciar una transmisión. De esta forma se asegura una ventaja en inicio de transmisión a los nodos en estado activo frente a los nodos en estado pasivo.

2.3.8.5 Trama de sobrecarga

Una trama de sobrecarga tiene el mismo formato que una trama de error activo. Sin embargo, la trama de sobrecarga solo puede generarse durante el espacio entre tramas. De esta forma se diferencia de una trama de error, que solo puede ser transmitida durante la transmisión de un mensaje. La trama de sobrecarga consta de dos campos, el Indicador de Sobrecarga, y el delimitador. El indicador de sobrecarga consta de 6 bits dominantes, el delimitador es de 8 bits recesivos. Una trama de sobrecarga puede ser generada por


27

cualquier nodo que debido a sus condiciones internas no esta en condiciones de iniciar la recepción de un nuevo mensaje. Retrasa el inicio de transmisión de un nuevo mensaje.

2.3.9 Detección y Corrección de Errores

Los sistemas de seguridad que incorpora el Can-Bus permiten que las probabilidades de fallo en el proceso de comunicación sean muy bajas, pero sigue siendo posible que cables, contactos y las propias unidades de mando presenten alguna disfunción.

Para el análisis de una avería, se debe tener presente que nodo averiado abonado al CAN bus en ningún caso impide que el sistema trabaje con normalidad. Lógicamente no será posible llevar a cabo las funciones que implican el uso de información que proporciona la unidad averiada, pero sí todas las demás.

Por ejemplo, si quedase fuera de servicio la unidad de mando de una puerta, no funcionaría el cierre eléctrico ni se podrían accionar el del resto de las puertas.

En el supuesto que la avería se presentara en los cables del bus, sería posible accionar eléctricamente la cerradura de dicha puerta, pero no las demás. Recuérdese que esto solo ocurriría si los dos cables se cortan o se cortocircuitan a masa.

También es posible localizar fallos en el CAN bus consultando el sistema de auto diagnosis del vehículo, donde se podrá averiguar desde el estado de funcionamiento del sistema hasta las unidades de mando asociadas al mismo, pero necesariamente se ha de disponer del equipo de chequeo apropiado.

Otra alternativa es emplear el programa informático CANAlyzer (Vector Informatik GmbH) con el ordenador con la conexión adecuada. Este programa permite visualizar el tráfico de datos en el CAN bus, indicar el contenido de los mensajes y realizar la estadística de mensajes, rendimiento y fallos. Además también es posible su diagnostico mediante un osciloscopio digital con la suficiente resolución para visualizar las tramas del bus.

2.3.9.1 Mecanismos de detección de Error en el bus

En el momento en que un dispositivo detecta un error en una trama, este dispositivo

transmite una secuencia especial de bits, el error flag. Cuando el dispositivo que ha transmitido la trama errónea detecta el error flag, transmite la misma trama de nuevo.

Los dispositivos de CAN detectan los errores descritos a continuación:

Error de Bit (Bit Error): Durante la trasmisión de una trama, el nodo que transmite, simultáneamente monitoriza el bus. Cualquier bit que reciba con polaridad inversa a la que ha transmitido se considera un error de bit, excepto cuando se recibe durante el campo de arbitraje o en el bit de reconocimiento. Además, no se considera error de bit, la detección de bit dominante por un nodo en estado de error pasivo que transmite una trama


28

de error pasivo.

Error de relleno (Stuff Error): Se considera error de relleno la detección de 6 bits consecutivos del mismo signo, en cualquier campo que siga la técnica de relleno de bits, donde por cada 5 bits iguales se añade uno diferente.

Error de CRC. Cuando el cálculo de CRC realizado por un receptor no coincide con el recibido en la trama. El campo CRC (Cyclic Redundant Code) contiene 15 bits y una distancia de Hamming de 6, lo que asegura la detección de 5 bits erróneos por mensaje. Estas medidas sirven para detectar errores de transmisión debido a posibles incidencias en el medio físico como por ejemplo el ruido

Error de forma (Form Error): Cuando un campo de formato fijo se recibe alterado en algún bit.

Error de reconocimiento (Acknowledgment Error): Cuando ningún nodo cambia a dominante el bit de reconocimiento Si un nodo advierte alguno de los fallos anteriores, inicia la transmisión de una trama de error. El protocolo CAN especifica diversos fallos en la línea física de comunicación, como por ejemplo línea desconectada, problemas con la terminación de los cables o líneas cortocircuitadas, aunque, no especifica como reaccionar en caso de que se produzca algún error de estos.

2.3.9.2 Mecanismo de aislamiento de Módulos Defectuosos.

Para evitar que un nodo en problemas condicione el funcionamiento del resto de la red, se han incorporado a la especificación de CAN, medidas de aislamiento de nodos defectuosos que son gestionadas por los controladores. Un nodo puede encontrarse en uno de los tres estados siguientes en relación con la gestión de errores:

Active Error: Es el estado normal de un nodo. Participa en la comunicación y en caso de detección de error envía una trama de error activa.

Passive Error: Un nodo en estado de error pasivo participa en la comunicación, sin embargo ha de esperar una secuencia adicional de bits recesivos antes de intentar transmitir y sólo puede señalar errores con una trama de error pasivo.

Bus off: En este estado deshabilitará su transceptor y no participará en la comunicación. La evolución entre estos estados se basa en dos contadores incluidos en el controlador de comunicaciones: Contador de errores de transmisión (TEC) y Contador de errores de recepción (REC).


29

2.4 Comunicaciones

2.4.1 Explicación general

Tal y como se ha explicado al inicio de la memoria uno de los objetivos del proyecto, es la necesidad de poder enviar y recibir tramas de diagnostico entre el Tester y el modulo de control electrónico, de acuerdo a las necesidades que se requieran para la validación de los Data Trouble Codes especificadas en el protocolo de test.

Además, como parte de los objetivos, será necesario provocar de forma intencionada DTCs en la ECU lo que implica el uso de una breakout box que permita perturbar y manipular las E/S del modulo electrónico.

Para los mencionados propósitos, se deben distinguir dos grupos (véase figura 13):

• Comunicaciones entre Usuario/ PC/ ECU

• Comunicaciones entre Breakout box / ECU

Figura 13 Montaje para la validación de DTCs.

1- Bus CAN 2- Conector J1962 3- Interfaz CAN 4- PC/Software 5- ECU 6- Breakout Box


30

2.4.2 Comunicaciones Usuario/ PC / ECU

Para que el envío y recepción de tramas sea factible entre el usuario y la ECU, se requiere la intervención de varios componentes para poder adaptar tanto las señales que circulan por el bus como los diferentes tipos de conectores que existen entre los elementos que componen la interfaz de comunicación.

Observando la figura 13 se puede distinguir como la ECU se encuentra conectada al bus de comunicaciones CAN junto con otros módulos siendo su única vía de contacto con el exterior el conector J1962.

Figura 14. Imagen conector J1962F Figura 15: Pin out conector J1962F

La popularidad de este conector se debe al hecho de que a partir de 1996 en USA, y 2001/2004 (gasolina y diesel respectivamente para vehículos en Europa), se decidió la implantación de un sistema estandarizado para la industria del automóvil que permitiese comprobar los errores de diagnostico de los módulos electrónicos sin tener que desmontar el vehiculo. Se conoce como OBD-II (On-Board Diagnostics second generation) y su especificación consta de una interfaz de hardware estandarizada, el conector J1962 de 16 pines que conectado al modulo “master” de comunicaciones permitirá el acceso al bus CAN. Por norma general, el conector J1962 se encuentra en una zona de fácil acceso que permita la conexión de herramientas de diagnostico para la comprobación del estado del automóvil.

Por otro extremo tenemos el PC el cual requiere de una herramienta de software que le permita crear un entorno que sea legible y entendible para el usuario y posibilite el envío y recepción de las tramas. Esta herramienta (ECU Diagnostics Tool) actúa como interfaz visual entre el usuario y el bus. El PC se considera como otro nodo más del bus CAN cuando éste se encuentra conectado al bus y es participe de la comunicación. Se le conoce como Tester.

Para que la información pueda ser transmitida y recibida al Tester desde la ECU y viceversa, se requiere una interfaz que permita por un extremo adaptar las señales que viajan por el bus de acuerdo a los requerimientos de ambos dispositivos y por otro lado, los cables y conectores adecuados que permitan enlazarlos.

La interfaz, CANcaseXL, consta de un transceptor que permite adaptar las señales y dos controladores que permite procesar mensajes de CAN con identificadores de 11 y 29 bits (En nuestro caso particular será únicamente necesario de 11).

Description PinMS CAN_H 3Chassis GND 4PWR GND 5MS CAN_L 11Battery 16

Pinout J1962F


31

Dicha interfaz debe ser configurada con en el PC mediante la correspondiente aplicación de Vector (la firma de la marca) indicándole la velocidad de transmisión necesaria (125 Kbit/s) y el canal por el que viajara la comunicación entre otros detalles.

Figura 16: Imagen de la interfaz CAN modelo CANcaseXL Figura 17: Pin out conector DB9

Por in extremo conecta al PC mediante un conector USB mientras que por el otro extremo será necesario un cable DB9 / J1962 que cierre el lazo con el conector de diagnósticos del vehiculo:

Figura 19: Cable de adaptación Interfaz Hardware CAN DB9 / Conector J1962.

Description PinCAN_L 2GND 3Shield GND 5CAN_H 7

DB9 (M)


32

2.4.3 Comunicación Breakout box/ ECU

Lamentablemente, el único modo de poder provocar intencionadamente errores y fallos en el vehiculo de un modo relativamente sencillo será mediante el uso de una Breakout box. La breakout box (BoB) es un dispositivo eléctrico de test que se conecta entre el cableado proveniente del vehiculo y la ECU (véase figura 13). Incorpora puentes eléctricos para cada una de las E/S del modulo y permiten al usuario tomar medidas mediante un osciloscopio o multímetro, provocar cortocircuitos, forzar cargas abiertas etc. sin necesidad de trabajar directamente sobre la placa PCB. Su mayor inconveniente implica tener que desmontar los paneles del vehiculo hasta llegar a la ECU para intercalarla en el sistema. La ventaja es, que una vez conectada, no se deberá llegar hasta cada uno de los componentes que formen el sistema, en este caso de entrada y arranque pasivo ya que podrán ser manipulados directamente desde los pines de la breakout box.

Figura 20. Imagen de una breakout box.

Salida conector a ECU

Entrada conector del

Vehiculo


33

2.5 Diagnósticos en vehiculo

2.5.1 ISO 14229 Servicios de diagnósticos

Los servicios de diagnóstico es el instrumento que permite una comunicación entre el Tester y la ECU, ya sea para obtener información de diagnóstico y/o para alterar el comportamiento de la ECU con fines de diagnóstico según la definición de la ISO, sin embargo, la posibilidad de lanzar rutinas o escribir información en el módulo permite cambiar el comportamiento del módulo no necesariamente por razones de diagnóstico.

La ISO 14229 define un total de 25 servicios de diagnósticos, los cuales quedan representados por 1 byte, utilizándose notación hexadecimal.

Servicio (hex.)

Servicio (Nombre) Servicio (hex.)

Servicio (Nombre)

10 Session Control 2E Write Data by Identifier

11 ECU reset 3D Write Memory by Address

27 Security Access 14 Clear Diagnostic Information

28 Communication Control 19 Read DTC Information

83 Access Timing Parameter 2F Input Output Control by Identifier

84 Secured Data Transmission 31 Routine Control

85 Control DTC Setting 34 Request Download

86 Response on Event 35 Request Upload

87 Link Control 36 Transfer Data

22 Read Data by Identifier 37 Request Transfer Exit

23 Read Memory by Address 3E Test Present

24 Read Scaling Data by Identifier

2C Dynamically Define Data Identifier

2A Read Data by Periodic Identifier

2.5.2 Control de flujo

Las tramas están compuestas por 8 bytes, de los cuales el primero representa tipo de trama

El estándar internacional define cuatro tipos diferentes de tramas en el protocolo de comunicación de red que se representan con un byte. A continuación se explican cada una de ellas, y se indica entre paréntesis el valor hexadecimal que las representa:

- Single Frame (0x00). Se trata de una trama sencilla.

- First Frame (0x01). Representa la primera de la tramas de un conjunto que se enviara consecutivamente.


34

- Consecutive Frame (0x02). Es una trama dentro de un conjunto pero que no representa la primera de ellas.

- Flow Control (0x03). Es una trama de control que indica que se cede el control al elemento de la comunicación que ha de enviar el conjunto de tramas.

Bytes del control de información del protocolo de red (N_PCI)

Byte #1 Byte #2 Byte #3

N_PDU nombre Bits 7-4 Bits 3-0

N_PCItype=0 SF_DL N/A N/A

N_PCItype=1 FF_DL N/A

N_PCItype=2 SN N/A N/A

N_PCItype=3 FS BS STmin

N_PCI = Control de información del Protocolo de Red

N_PDU = Unidad de Datos del Protocolo de Red

SF_DL = Longitud de datos de una trama simple

FF_DL = Primera trama de una secuencia de tramas

SN = Orden de la trama dentro de una secuencia de tramas

FS = Estado del flujo

BS = Tamaño del bloque

STmin = Tiempo de separación mínima entre dos tramas consecutivas.

Transmisión de una trama simple:

Figura 21: Ejemplo transmisión de una trama simple

Positive response

02 3E 00 00 00 00 00 00

02 7E 00 00 00 00 00 00

Single frame:

TESTER ECU


35

Transmisión múltiple de tramas:

Cuando la transmisión de un mensaje es mayor de 7 bytes se procede a una segmentación del mensaje, y al envío del mismo a través de varias tramas de CAN transmitidas a través del control de flujo.

Figura 22: Ejemplo transmisión de una trama múltiple.

2.5.3 Respuesta positiva

Las tramas de respuesta positiva desde una ECU se identifican fácilmente a través del byte #3, ya que estará formado por la suma de 0x40 al identificador del servicio.

2.5.4 Respuesta Negativa

Cuando la ECU no es capaz de llevar a cabo la petición de diagnostico solicitada por el Tester debe responder con uno de los códigos que identifique el motivo de ello. Estos códigos son:

- 0x11 que indica que el servicio no es soportado por la ECU.

- 0x12 indica que una determinada subfuncion asociada a un servicio no es soportada por la ECU.

- 0x13, indica que el tamaño del mensaje especificado no es correcto o que el formato es inválido.

First frame:

03 22 F1 88 00 00 00 00

10 1B 62 F1 88 38 58 32

Single frame:

ECU

First frame:

30 00 00 00 00 00 00 00

Flow control:

Consecutive frame:

21 33 2D 31 34 43 30 32

22 36 2D 41 44 00 00 00

TESTER

Consecutive frame:

23 00 00 00 00 00 00 00

STmin BS

(Block Size)


36

- 0x22, indica que las condiciones necesarias para cumplir la petición no se están cumpliendo.

- 0x78, es una respuesta de respuesta pendiente, indica que la petición de servicio por el Tester se recibió correctamente pero que la ECU no ha podido completar las acciones asociadas y por lo tanto no está en situación de recibir nuevos mensajes desde el Tester.

Una vez que la ECU complete la ejecución de la petición, esta debe responder con una respuesta positiva o con una respuesta negativa según proceda.

El código de respuesta pendiente puede ser repetido por la ECU hasta que la petición de respuesta de servicio se haya completado y la respuesta final se haya enviado.

2.5.5 Servicios de diagnostico

2.5.5.1 Servicio $10 (Control de Sesión de Diagnóstico)

El hecho de disponer de diferentes sesiones de diagnostico hace posible habilitar un determinado conjunto de servicios y/o funcionalidades en el modulo. Ello implica la necesidad de un servicio de control de diagnostico que permita activar cada uno de los diferentes niveles de sesión en la ECU.

Figura 23. Diagrama de las sesiones de diagnostico en el AFR.

1. Default Diagnostic Session, que es la sesión por defecto. Todo modulo entra en esta sesión al ser iniciado.

2. Programming Diagnostic Session. Es la sesión en la cual se habilita la programación del modulo.

3. Extended Session, es la sesión en la que se definen todos los servicios especiales.


37

La petición de servicio se compone de dos bytes, el primero de ellos se destina al servicio y el segundo para la sesión que se requiere.

Petición de servicio la petición de servicio de control de sesión de diagnostico.

Byte Descripción Ejemplo

1 Identificador de la petición de servicio de control de sesión de diagnostico.

10

2 Tipo de sesión de diagnostico (Default, programming, extended, …) 01

Respuesta negativa a la petición de servicio la petición de servicio de control de sesión de diagnostico.


1 Identificador de la respuesta positiva a la petición de servicio de control de sesión de diagnostico.

50

2 Tipo de sesión de diagnostico de la petición 01

3 Parámetro de la sesión de diagnostico. Registro 1. LSB del máximo tiempo en el cual el modulo tiene que responder a cualquier petición de servicio en ms. ($0032 o 25 ms. para default sesión, $0016 o 26 ms. para programming sesión, …)

00

4 Parámetro de la sesión de diagnostico. Registro 2. LSB del máximo tiempo en el cual el modulo tiene que responder a cualquier petición de servicio en ms. ($0032 o 25 ms. para default sesión, $0016 o 26 ms. para programming sesión, …)

32

5 Parámetro de la sesión de diagnostico. Registro 3. MSB del: - máximo tiempo en el cual el modulo tiene que permanecer en una sesión de diagnostico si el módulo no recibe nueva petición de servicio diagnostico (No se incluyen las petición de servicio de control de sesión de diagnostico). - máximo tiempo en el cual el modulo tiene que responder a cualquier petición de servicio después de haber enviado un mensaje de respuesta pendiente. Ej.: Default sesión $01F4*$0A = 5000ms

01

6 Parámetro de la sesión de diagnostico. Registro 4. LSB del: - máximo tiempo en el cual el modulo tiene que permanecer en una sesión de diagnostico si el módulo no recibe nueva petición de servicio diagnostico (No se incluyen las petición de servicio de control de sesión de diagnostico). - máximo tiempo en el cual el modulo tiene que responder a cualquier petición de servicio después de haber enviado un mensaje de respuesta pendiente.

F4


38

Respuesta negativa a la petición de servicio la petición de servicio de control de sesión de diagnostico.


1 Identificador de la respuesta negativa a la petición de servicio de control de sesión de diagnostico.

7F

2 Tipo de sesión de diagnostico de la petición 10

3 Código de la respuesta negativa. Indica por qué el servicio de diagnostico ha fallado, no ha podido completarse o si necesita más tiempo para completarse en el caso de código de respuesta pendiente.

xx

2.5.5.2 Servicio $11 (Reiniciación de la ECU)

Este servicio permite al Tester reiniciar el módulo. La petición de servicio se compone de dos bytes, el primero de ellos se destina al servicio y el segundo para indicar qué tipo de reinicio se requiere, siendo el más comúnmente utilizado el HardReset, que es la simulación de la secuencia llevada a cabo con un módulo es alimentado de nuevo tras haber perdido alimentación de batería.

La respuesta positiva se envía antes de que el módulo se reinicie.

Petición de servicio de reiniciación.


1 Identificador de la petición de servicio de reiniciación. 11

2 Tipo de reiniciación ($01 = HardReset) 01

Respuesta positiva a la petición de servicio de reiniciación.


1 Identificador de la respuesta positiva a la petición de servicio de reiniciación.

51

2 Tipo de reiniciación ($01 = HardReset) 01

Respuesta negativa a la petición de servicio de reiniciación.


1 Identificador de la respuesta negativa a la petición de servicio de control de sesión de diagnostico.

7F

2 Identificador de la petición de servicio de reiniciación. 11


xx


39

2.5.5.3 Servicio $27 (Security Access)

La ECU puede ser accedida con diferentes niveles de seguridad, lo que permite proteger datos y limitar el uso de determinados servicios por razones de protección, medioambientales o de seguridad. Solo un nivel de seguridad puede estar activo al mismo tiempo

El concepto de seguridad utiliza una relación de semilla y clave:

1. El Tester solicita la semilla.

2. El módulo envía la semilla

3. Tester y módulo generan una clave utilizando la semilla.

4. El Tester envía la clave al módulo.

5. El módulo responde positivamente si la clave es válida y se desbloquea.

Si un módulo soporta más de un nivel de seguridad de acceso deberá de disponer de diferentes identificadores de tipo de solicitud de semilla, y además existirá una relación única entre la petición de semilla y el envío de la clave. De manera que la petición de semilla con identificador $01 tendrá una relación fija entre la petición de semilla $01 y el envío de la clave $02, así como identificador $03 tendrá una relación fija entre la petición de semilla $03 y el envío de la clave $04.

Petición de servicio de Security Access (petición de semilla):


1 Identificador de petición de servicio de acceso seguro. 27

2 Tipo de petición de acceso seguro (petición de semilla). 01

Respuesta positiva a la petición de semilla:


1 Identificador de la respuesta positiva a la petición de servicio de acceso seguro.

67

2 Tipo de petición de acceso seguro (petición de semilla). 01

3 Semilla Byte 1 22

4 Semilla Byte 2 56

5 Semilla Byte 3 89


40

Petición de servicio de Security Access (envío de clave):



2 Tipo de petición de acceso seguro (envío de clave). 02

3 Clave Byte 1 29

4 Clave Byte 2 01

5 Clave Byte 3 8C

Respuesta positiva petición de servicio de Security Access (envío de clave):


1 Identificador de la respuesta positiva a la petición de servicio de acceso seguro.

67

2 Tipo de petición de acceso seguro (envío de clave). 02

Respuesta negativa a un mensaje de petición de servicio de acceso seguro (Security Access)


1 Identificador de la respuesta negativa a una petición de servicio. 7F



xx

2.5.5.4 Servicio $3E (Tester Present)

Este servicio está destinado a indicar al módulo que el Tester está aún conectado al vehículo y que la comunicación abierta debe permanecer activa.

Petición de servicio de Tester Present.


1 Identificador de la petición de servicio de Tester Present. 3E

2 Tipo de Tester Present. 00

Respuesta positiva a un mensaje de Tester Present:


1 Identificador de respuesta positiva la petición de servicio de Tester Present.

7E

2 Tipo de Tester Present. 00


41

2.5.5.5 Servicio $22 (Lectura de datos por identificador)

Es un servicio que permite al Tester hacer una petición para conocer ciertos los valores de datos del módulo a través de identificadores creados para tal efecto. La ISO 14229 define el tamaño de dichos identificadores como 2 bytes. El formato y definición de los identificadores son determinados por los fabricantes de vehículos o el proveedor del módulo.

Petición de servicio de lectura de datos por identificador:


1 Identificador de la petición de servicio de lectura de datos por identificador.

22

2 Identificador de datos (MSB) ($F0E8 devuelve RRF Software versión) F0

3 Identificador de datos (LSB) ($F0E8 devuelve RRF Software versión) E8

Respuesta positiva a un mensaje de petición de servicio de lectura de datos por identificador :


1 Identificador de respuesta positiva a la petición de servicio de lectura de datos por identificador.

62

2 Identificador de datos (MSB) F0

3 Identificador de datos (LSB) E8

4 Registro del dato pedido Byte 1 31

5 Registro del dato pedido Byte 2 2E

6 Registro del dato pedido Byte 3 38

Respuesta negativa a un mensaje de petición de servicio de lectura de datos por identificador :




22


xx


42

2.5.5.6 Servicio $2E (Escritura de datos por identificador)

Es un servicio que permite al Tester hacer una petición para conocer ciertos valores de datos del módulo a través de identificadores creados para tal efecto. La ISO 14229 define el tamaño de dichos identificadores como 2 bytes. El formato y definición de los identificadores son determinados por los fabricantes de vehículos o el proveedor del módulo.

Petición de servicio de escritura de datos por identificador :



2E

2 Identificador de datos (MSB) ($FD11 activa o desactiva secure CAN) FD

3 Identificador de datos (LSB) ($FD11 activa o desactiva secure CAN) 11

4 Registro del dato Byte 1 ($00 = desactivar) 00

Respuesta positiva a un mensaje de petición de servicio de escritura de datos por identificador :


1 Identificador de respuesta positiva a la petición de servicio de escritura de datos por identificador.

6E

2 Identificador de datos (MSB) FD

3 Identificador de datos (LSB) 11

Respuesta negativa a un mensaje de petición de servicio de escritura de datos por identificador :



2 Identificador de la petición de servicio de escritura de datos por identificador.

2E


xx

2.5.5.6 Servicio $19 (Lectura de información de DTCs)

Es un servicio que permite al Tester hacer una petición de lectura de los DTC del módulo. Este servicio utiliza subfunciones para determinar qué tipo de información de diagnostico se pide. Los más comúnmente utilizados son:

- $01 que devuelve el número de DTCs cuyo estado verifica la máscara de estado utilizada en la petición.


43

- $02 que devuelve la lista de DTCs cuyo estado verifica la máscara de estado utilizada en la petición.

Además existen subfunciones que permiten obtener información adicional de un DTC determinado como son:



Otro servicio interesante es el servicio $0A que devuelve la lista de todos los DTCs soportados por el módulo.

La subfunción más útil de cara al proyecto, y también por ser la más utilizada desde un punto de vista práctico es la subfunción $02, pero antes de entrar en detalles de la misma es interesante conocer como funciona la máscara de estado. Esta máscara contiene ocho bits de estado, y se considera que el estado del DTC verifica la máscara de estado de la petición si uno de los bits de estado del DTC es 1 y el mismo bit de la máscara de estado de la petición también tiene valor 1.

Subfunción $02

Petición de lectura de información de DTCs reportada por máscara de estado:


1 Identificador de la petición de servicio de lectura de información de DTCs.

19

2 Identificador de subfunción. 02

3 Máscara de estado FF

Respuesta positiva a un mensaje de petición de lectura de información de DTCs reportada por máscara de estado:


1 Identificador de respuesta positiva a la petición de servicio de lectura de información de DTCs.

59


3 Máscara de estado FF

4 Registro del dato Byte 1 ($00 = desactivar) 00

5 Registro de DTC y estado 1. Byte 1 (High Byte) C1

6 Registro de DTC y estado 1. Byte 1 (Middle Byte) 59

7 Registro de DTC y estado 1. Byte 1 (Low Byte) 87

8 Registro de DTC y estado 1. Byte 1 (Byte de estado del DTC) 2F

.. Registro de DTC y estado n. Byte 1 (High Byte) xx

.. Registro de DTC y estado n. Byte 1 (Middle Byte) xx


44

.. Registro de DTC y estado n. Byte 1 (Low Byte) xx

.. Registro de DTC y estado n. Byte 1 (Byte de estado del DTC) xx

Respuesta negativa a un mensaje de petición de lectura de información de DTCs reportada por máscara de estado:



2 Identificador de la petición de servicio de lectura de información de DTCs.

19


xx

2.5.5.7 Servicio $14 (Elimina información de diagnostico)

La petición de eliminación de información de diagnostico elimina toda información relacionada con los DTCs, estado, snapshot contadores, flags, etc. Además el servicio permite hacer un borrado selectivo a través del parámetro grupo de DTCs, ver tabla de Mensaje de petición de eliminación de información de diagnostico.

Mensaje de petición de eliminación de información de diagnostico:


1 Identificador de la petición de servicio de eliminación de información de diagnóstico.

14

2 Identificador de grupo de DTCs. Byte 1 (High Byte) FF

3 Identificador de grupo de DTCs. Byte 2 (Middle Byte) FF

4 Identificador de grupo de DTCs. Byte 3 (Low Byte) FF

Respuesta positiva a un mensaje de petición de eliminación de información de diagnóstico:


1 Identificador de la respuesta positiva a la petición de servicio de eliminación de información de diagnóstico.

54

Respuesta negativa a un mensaje de petición de eliminación de información de diagnóstico:



2 Identificador de la petición de servicio de eliminación de información de diagnóstico.

14


45


xx

2.5.5.8 Servicio $31 (Control de Rutinas)

La petición de control de rutinas permite ejecutar rutinas de diagnostico desde el Tester, lo que habilita al mismo para acceder a test internos, programas y/o funciones dentro del módulo.

El identificador de la rutina se define con dos bytes y se definen tres subfunciones que son:

- $01, para lanzar una rutina.

- $02, para detener la ejecución de una rutina.

- $03, para hacer una petición de datos de una rutina.

Mensaje de petición de control de rutinas:


1 Identificador de la petición de servicio de control de rutinas. 31


3 Identificador de rutina (MSB). 02

4 Identificador de rutina (LSB). 02

Respuesta positiva a un mensaje de petición de control de rutinas:


1 Identificador de respuesta positiva a la petición de servicio de control de rutinas.

71


3 Identificador de rutina (MSB). 02

3 Identificador de rutina (LSB). 02

Respuesta negativa a un mensaje de petición de control de rutinas:



2 Identificador de la petición de servicio de control de rutinas. 31


xx


46

2.6 Data Trouble Codes (DTC)

2.6.1 Que se conoce como DTC.

La compleja tarea de diagnosticar la causa principal de un síntoma de error reportado por un usuario en un vehiculo actual, comportaría una ardua tarea por parte de los técnicos de taller hasta concretar el fallo en el supuesto caso de ser encontrado.

Para facilitar la tarea, cada unidad electrónica de control comprueba periódicamente su funcionamiento interno así como el estado de los dispositivos conectados a sus E/S e incluso el bus de comunicaciones CAN.

Cabe mencionar, que esta comprobación, no es periódica para cada uno de los elementos sino que en algunos casos, son evaluadas en función de una acción realizada eventualmente, como por ejemplo durante el momento de ignición del automóvil o incluso mediante una petición de un servicio de diagnostico solicitado por una herramienta de diagnostico de taller.

Durante la comprobación, la ECU evalúa las muestras recibidas y en función del criterio de evaluación (exclusivo para cada tipo de fallo), se registrara un error en sobrepasar los valores límites establecidos en el proceso de filtración.

Dicho error se almacena en la memoria FLASH del modulo asignándole un código de error especifico según marca el Standard de automoción ISO15031-6 (Diagnostics Trouble Code Definition). El código de error es exclusivo para cada tipo de componente permitiendo identificar individualmente cada fallo existente en el vehiculo. Este código de error se conoce como DTC (Data Trouble Code).

2.6.2 Asignación de DTCs

Únicamente los componentes del sistema que puedan ser reemplazados en un taller, tienen asociados un DTC específico que les diferencia de los demás. En algunos componentes, se identifica también con un DTC único cada una de partes que lo componen siempre y cuando su activación permita diagnosticar el error, facilitar la trazabilidad o desvelar la causa principal de un problema.

Si un DTC no corresponde a una falla que, en caso de ser registrada, no conlleva a una accion de reparacion, indica un error de diseno y no debera tener un dtc asociado.

Ademas, una ECU se considera defectuosa si un codigo de error permanece registrado permanentemente y las pruebas realizadas en los componentes no desvelan ningun fallo.

2.6.3 Cuando registrar un DTC

Un DTC únicamente debe ser registrado si el fallo ha provocado un síntoma observable por el usuario durante un periodo de tiempo suficiente para que este se de cuenta del error. El tiempo considerado para registrar el error, varía en función del síntoma. Por ejemplo, el código de error de “lock switch” de la maneta requiere, mantener el botón pulsado durante 45 segundos antes de registrar el error mientras que el fallo asociado a la frecuencia del receptor de radio se establecerá de inmediato.


47

Además un DTC no se aplicará para cualquier condición que pudiera ser causado por un fallo o por una acción del cliente que la ECU no pueda determinar cuál de ellos ha sido la causa. Por ejemplo, en un vehiculo con sistema de entrada y arranque pasivo, podría darse la situación que el arranque pasivo se inhiba debido a un fallo en el RRF o en la llave electrónica. Este síntoma puede ser provocado también si el vehiculo se ha intentado arrancar sin estar la llave electrónica presente. Este último caso no debe generar un DTC debido a que ha sido un fallo de usuario y no de sistema.

2.6.4 Condiciones para registrar un DTC:

Los códigos de error se registran cuando se dan una o más de las siguientes razones:

a. Un fallo ha sido detectado en los circuitos externos conectados a la ECU.

b. Un fallo ha sido detectado internamente en la ECU.

c. Un fallo ha sido detectado indirectamente en un componente o sistema del vehículo mediante la supervisión del sistema, componente o comportamiento del vehiculo.

d. No se ha detectado un fallo directo en la ECU pero el modulo electrónico se ha visto obligado a adoptar una estrategia de protección que ha reducido su funcionalidad debido al contenido de los datos de la información recibida por otro ECU. Durante esta circunstancia, la ECU no responderá según se espera y generará síntomas observables por los clientes.

e. Fallos internos que no se encuentran en el circuito principal

f. Fallos internos que se encuentran en el circuito principal

g. Fallos debidos a errores de configuración y compatibilidad de software / hardware. Fallos ocasionados por el contenido de la señal y valores de los datos recibidos por otros módulos electrónicos.

h. Defectos causados por el entorno operativo de la ECU o acciones de los clientes.

2.6.5 Reportar DTCs bajo petición o de forma continua

Un DTC puede ser reportado mediante el uso del servicio de diagnostico 19 (ReadDTCInformation) o mediante la rutina “On-Demand Self Test” del servicio 31.

Cuando el DTC se reporta mediante el servicio 19, la respuesta se compone de 3 bytes mas un byte indicando el status del error. El DTC se setea como resultado de monitorizar el fallo continuamente o en momentos determinados independientemente de una petición de diagnostico. Se conocen como DTC’s Continuos.

Cuando un DTC se reporta mediante la rutina “On-demand self test” del servicio 31 la respuesta consiste básicamente en 3 bytes sin informar del estado del fallo ya que dicho servicio únicamente comprueba el estado de los componentes bajo una petición de usuario y consecuentemente se registra el DTC en ese momento en caso de fallo.

Aunque la finalidad de ambos servicios sea la misma, se debe tener en cuenta que no todos los DTC’s soportan ambos servicios y del mismo modo un DTC que haya sido


48

reportado como resultado de la ejecución de la rutina “On Demand Self Test “ no implica que sea reportado por el servicio 19.

2.6.6 Registro y borrado de DTCs

La ECU transmite la información del DTC de la memoria volátil (RAM) a la no

volátil (EEPROM o FLASH) cada vez que se produce un cambio en el estado del código de error y previamente a que el modulo pase de un estado activo a un estado de reposo o de bajo consumo. Previo a esta operación se produce una etapa de análisis de fallo donde se evalúa si el error ha sido confirmado o se ha producido un error esporádico y consecuentemente no deba ser reportado como DTC. La información almacenada previamente en EEPROM debe estar disponible a pesar de que la batería del vehiculo sea desconectada o exista un reset en el sistema.

Un DTC que ha sido reportado como fallo y consecuentemente registrado en memoria como tal, puede ser borrado mediante el envío de un servicio de diagnostico que requiere ser enviado por parte de un Tester, es decir, un equipo de diagnostico u ordenador conectado al bus CAN del automóvil con capacidad de comunicarse con el modulo y permitir el envío y recepción de tramas. La ISO 14229-1 define al servicio de diagnostico 14 como “Clear Diagnostic Information”.

Se debe recordar que una vez que un DTC ha sido registrado en memoria, permanecerá presente y variar el byte de estado según las condiciones del sistema y los factores relacionados con el ciclo de operación del automóvil. Por otro lado un fallo existente físicamente en el sistema, seguirá afectando el comportamiento del sistema aunque haya sido eliminado el registro en memoria que alertaba de dicho error. 2.6.7- Rangos de DTCs implementados.

Los dtcs son implementados según la tabla inferior definida por la ISO 15031-6: DTC

Name Item Valid display value range, see reference [7]

Definition

1.1 P0000YY to P0FFFYY P2000YY to P2FFFYY P3400YY to P3FFFYY

DTCs defined in reference [7] and the GMRDB. Byte YY is the DTCFailureTypeByte specified by reference [7] The faults that shall be identified by DTCs are specified in sections ¡Error! No se encuentra el origen de la referencia.

Powertrain (P) DTCs

1.2 P1000YY to P1FFFYY P3000YY to P3399YY

DTCs defined in the GMRDB. Byte YY is the DTCFailureTypeByte specified by reference [7] The faults that shall be identified by DTCs are specified in sections ¡Error! No se encuentra el origen de la referencia. and ¡Error! No se encuentra el origen de la referencia.

2.1 B0000YY to B0FFFYY B3000YY to B3FFFYY C0000YY to C0FFFYY C3000YY to C3FFFYY U0000YY to U0FFFYY U3000YY to U3FFFYY

DTCs defined in reference [7] and the GMRDB. Byte YY is the DTCFailureTypeByte specified by reference [7] The faults that shall be identified by DTCs are specified in sections ¡Error! No se encuentra el origen de la referencia. and ¡Error! No se encuentra el origen de la referencia.

Body (B), Chassis (C), Network and Miscellaneous (U) DTCs

2.2 B1000YY to B2FFFYY C1000YY to C2FFFYY U1000YY to U2FFFYY

DTCs defined in the GMRDB. Byte YY is the DTCFailureTypeByte specified by reference [7] The faults that shall be identified by DTCs are specified in sections ¡Error! No se encuentra el origen de la referencia. and ¡Error! No se encuentra el origen de la referencia.

Los dos bytes mas significativos de un DTC (la base del DTC) se basa en la ISO

15031 la cual divide el codigo de error entre las areas funcionales y la ISO/SAE


49

(especifico al fabricante del vehiculo). Los DTCs correspondientes a la ISO/SAE son definidos en los estandares y (Global Master Reference Database) y adecuados a cada fabricante. 2.6.8 Estructura de un DTC

La estructura básica en formato hexadecimal (utilizado por el modulo electrónico) consta de 3 bytes + 1 byte (reportado opcionalmente ante una petición de diagnostico):

Byte 1 Byte 2 Byte 3 Byte 4

Base del DTC Base del DTC Tipo de fallo Estado del fallo

Figura 24. Estructura de un DTC.

La base del DTC define un nombre identificativo o código asocia un código especifico a cada componente del vehiculo

Los dos byte que forman la base del DTC asocian un identificador a cada uno de los componentes que forman el sistema y que puedan ser reconocidos como causantes de un error.

El tipo de fallo permite identificar en un byte cual es la causa de error en dicho componente, es decir, si se ha producido por un cortocircuito a masa, por un circuito abierto, por un cortocircuito a batería, por un error durante el chequeo de la memoria, etc.

El estado de fallo determina en un byte el estado actual del error informando si sigue activo y permanente o si es un error obsoleto o intermitente.

A pesar de que la base del DTC sea la misma, se debe distinguir el DTC segun el byte de fallo ya que no existe asociacion entre ambos, es decir, se consideran codigos de fallos distintos.

2.6.9 Tipos de fallo

Existen diferentes componentes eléctricos conectados a las E/S de la ECU como interruptores, elementos analógicos, PWM, pull-up y/o pull-down, comunicaciones serie CAN y LIN entre otras, la alimentación del circuito y otros tales como cables, conectores, sensores, y actuadores, etc. La ISO15031-1 en base a la ISO14229 define en función del tipo de circuito eléctrico y el síntoma de fallo detectado, un identificador común que establece el tipo de error.

Los tipos de fallo más comunes a nivel externo serian:

a. Cortocircuito a masa.

b. Cortocircuito a batería.

c. Cortocircuito entre cables de conexión entre antenas.

d. Circuito abierto.

e. Error en el nivel de la tensión de alimentación.

f. Cortocircuito en la línea del bus CAN o LIN.


50

Las siguientes comprobaciones permitirán detectar un error provocado a nivel interno y desvelar la causa de un fallo:

a. Comprobación de la memoria del modulo mediante el calculo del checksum.

b. Comprobación del tiempo de operación del procesador utilizando un watchdog timer.

c. Comprobación de periodos de ejecución de tareas estableciendo time-out.

d. Comprobación de la temperatura, las sobrecarga, los cortocircuitos y circuitos abiertos en relés internos.

e. Comprobación de fallos eléctricos en los circuitos internos del sensor.

A pesar de que algunos comparten identificador del tipo de fallo, aun perteneciendo a diferente grupo de circuito eléctrico, no permite crear confusión debido a que la base del DTC sigue siendo única para cada tipo de componente sin importar el tipo de error.

A continuación se muestra la tabla de DTC’s con sus sintomas y tipos de fallo asociados para nuestro sistema:

2.6.9.1 Códigos de error del sistema

El sistema de entrada y arranque pasivo tiene la capacidad de poder registrar los siguientes tipos de fallo asociados a un código de error y a un componente del sistema:

Componente Descripción del componente

Código de

error

Tipo de Fallo

Descripción del error

AFR & PK 90A9 00 Less than 2 PK programmed.

AFR software C300 00 NM state

NMExpulsion is reached.

RF configuration E100 00 Missed or wrong LF

calibration file.

Vehicle configuration E101 00 Invalid car

configuration received.

AFR MCU 49 Internal failure

AFR Module F000

95 Wrong module

installed.

ECU

AFR VIN F002 81 Invalid VIN

Number.


51

92EA 96 RRF HW failure - configuration miss

match.

00 K-line bus short or

driver failure

31 No communication

with RFR

Receiver RRF

E01F

95 RRF of wrong frequency is

detected.

11 Short to GND. 11 Wires shorted. 12 Short to Bat.

Antenna 4 Exterior trunk.

90C6

13 Open circuit. 11 Short to GND. 11 Wires shorted. 12 Short to Bat.

Antennas

Antenna 3 Interior trunk.

90C7


Antenna 2 Interior center.

90C8

13 Open circuit. 11 Short to GND. 11 Wires shorted. 12 Short to Bat. 13 Open circuit.

Antenna 1 Interior front.

90C9

12 Short to Bat. 11 Short to GND. 11 Wires shorted. 12 Short to Bat.

Antenna 6 Left rear door handle.

90CA


Antenna 8 Right rear door handle.

90CB


Antenna 10 Front triangulation/load space (Depending on the

model).

9335

13 Open circuit. 11 Short to GND. 11 Wires shorted.

Antennas

Antenna 5 Left front door handle.

9336

12 Short to Bat.


52


Antenna 7 Right front door handle.

9337


Antenna 9 Load space/interior boot

(Depending on the model). 933D

13 Open circuit. 15 Stock open.

LF unlock switch 90C1 23 Stock on. 15 Stock open.

LR unlock switch 90C2 23 Stock on. 15 Stock open.

RF unlock switch 90C3 23 Stock on. 15 Stock open.

RR unlock switch 90C4 23 Stock on.

Trunk unlock switch 90C5 23 Stock on.

Unlock Switch

Tailgate glass release switch

9334 23 Stock on.

LF lock switch 90D1 23 Stock on. LR lock switch 90D2 23 Stock on. RF lock switch 90D3 23 Stock on. RR lock switch 90D4 23 Stock on.

Lock Switch

Boot/Trunk primary switch 5017 23 Stock on. LF latch clutch switch 90CC 23 Stock on. LR latch clutch switch 90CD 23 Stock on. RF latch clutch switch 90CE 23 Stock on.

Latch Clutch

RR latch clutch switch 90CF 23 Stock on.

11 Short to GND on E-

latch. LF E-latch relay

12 Short to Bat on E-

latch.


latch. LR E-latch relay


latch.


latch. RF E-latch relay


latch.

E-Latch

RR E-latch relay

92D6


latch.


53


latch.

LF DH proximity sensor LR DH proximity sensor RF DH proximity sensor

Door Handle

RR DH proximity sensor

90D5 16 Handle supply more

than 3V below VBAT.

CAN bus MS CAN bus C010 88 NM State

NMBussOffWait is reached.

Tabla 1: DTCs y síntomas de los componentes.

2.6.10- Bits de Estado

Los “Status Bits” forman parte de la estructura del DTC y aportan infamación acerca del estado del error. Desvelan si se ha producido un error, si el fallo se ha producido en el actual ciclo de ignición (arranque del vehiculo) o si ha sido establecido por primera vez después de haber ejecutado la rutina de limpiar DTC’s.

A criterio del equipo de software se puede utilizar el Status Bits para definir cuando un DTC es permanente, intermitente u obsoleto.

El Status Bits únicamente se reporta cuando se comprueban DTC’s ejecutando el servicio de diagnostico $19.

Bit Nombre en ISO 14221 Descripción

0 testFailed Not used, always 0

1 testFailedThisOperatingCycle The bit is set when the DTC detection counter 1) reaches 127 and cleared at the beginning of DTC monitoring cycle 2)

2 pendingDTC Not used, always 0

3 confirmedDTC Set at the same tome as testFailedThisOperatingCycle; cleared when DTC aging counter reaches its maximum 127.

4 testNotCompletedSinceLastClear Set when the service 14 is executed or when the routine 0408 – Clear EEPROM – is executed; cleared when the DTC detection counter reaches either 127 or -128. 4)

5 testFailedSinceLastClear Set at the same time as bit 1; cleared together with bit 4.

6 testNotCompletedThisOperatingCycle

Set at the beginning of the DTC monitoring cycle; 5) cleared together with bit 4.

7 warningIndicatorRequested Not used, always 0


54

2.6.10.1 Contador de detección de errores

La naturaleza del sistema y su funcionamiento definen qué elementos asociados a un DTC deben ser diagnosticados de forma continua y cuales deben serlo de forma esporádica ante una petición externa o en caso de cumplirse una serie de condiciones. Ya sea de forma cíclica, como los DTC’s soportados por el servicio de diagnostico $19 o de forma eventual, soportados por la rutina de petición de auto diagnostico (“31 01 02 02”), se dispone de un contador de fallos de DTC’s que ayuda a distinguir un fallo real de un falso DTC.

A nivel de la aplicación del software, la capa de diagnósticos tiene asociada una capa de control de drivers la cual evalúa continuamente el estado de sus E/S. Para evitar que un DTC sea registrado como error durante el primer análisis, se deben realizar varios muestreos y definir una etapa de filtrado que permita distinguir entre un error y un fallo esporádico que pueda ser causado de forma inesperada en el sistema, debido a la perturbación o interferencia momentánea de una señal, la cual no refleja ningún síntoma para el usuario del vehiculo y consecuentemente no estaría identificando un fallo en el sistema. Este filtro se le conoce como “DTC fault detection counter” o contador de detección de fallos de DTC.

Los contadores de fallos ejercen la función de filtro durante el proceso de detección de errores evaluando las veces que se ha producido un fallo y determinando si ha ocurrido durante el tiempo necesario como para ser registrado como DTC.

El “DTC Detection Fault Counter” se define como un contador de 1 byte con signo y es asignado individualmente a cada DTC. Su rango oscila entre -128 hasta +127. El contador incrementa cada ocasión que el test de comprobación falla y decrementa cuando supera el test. El DTC asociado se registra cuando el contador alcanza 127. El contador se reinicia a cada ciclo de operación, el cual se considera cada ocasión que el estado del vehiculo trasmitido por el bus CAN pasa de “KeyOut” (vehiculo cerrado) a “Accessory” (vehiculo abierto).

Los valores de incremento y decremento del contador son individuales para cada DTC y son definidos por el ingeniero de desarrollo del sistema de forma que se consigue adecuar la cantidad de intervalos necesarios antes de que un DTC sea considerado como activo o no.

________________________

4) Refiérase al punto 2.5.11 para más detalle.

5) Se entiende como ciclo de monitorización, o ciclo de operación. Ocurre cuando el AFR detecta un cambio en la señal publicada en el bus CAN que monitoriza si el vehiculo esta cerrado o no.


55

Filtro de Proceso Proceso de escalado. Rango de salida: -128 to +127

ETAPA 1 ETAPA 2 ETAPA 3

La figura 26 muestra un caso general de la estrategia a seguir para la implementación de un “DTC Fault Detection Counter” donde se asigna como ejemplo un valor de 32 unidades al contador incremental de fallo y un valor de 16 unidades al contador decremental.

En la etapa 1, se monitoriza la respuesta del componente a evaluar ante el test de fallo y se transmite en forma de valores lógicos el resultado de cada muestreo.

Los valores son adaptados por el Filtro de Proceso el cual envía los datos a la etapa 2 indicando incrementar en caso de fallo o decrementar en el caso de que el muestreo haya pasado exitosamente.

La etapa 2 no es más que un contador donde se almacena el valor que se actualiza dinámicamente en cada recepción de información por parte del Filtro de Proceso y corresponde al sumatorio de los contadores incrementales menos el sumatorio de los contadores decrementales.

El resultado de dicha operación se transmite al Filtro de Escalado el cual compara el valor limite (+127) con el valor recibido, permitiendo determinar si el test en general ha sido considerado como superado o no.

En caso de no superar el test general, la etapa 3, analiza la información y procede registrando el DTC asociado al componente y al test realizado. Señal

Figura 25: Estrategia del contador de detección de fallos.

Proceso de detección de fallo

Registro Contador de fallos de DTC

DTC reportado


56

Figura 26: Ejemplo de funcionamiento de una estrategia del contador de detección de fallos.

DTC status bit 4, Test-NotComplete-SinceLastClear

Señal

Test

Contador de deteccion de fallos de DTC

Decremento (-16)

Incremento (+32)

Detección de fallo

Fallo no detectado

-128

+127

Cero

DTC Test Failed


57

3. FUNDAMENTOS DEL CÓDIGO DESARROLLADO


58

3.1 Fundamentos y detalles de la secuencia a seguir para provocar los DTCs

El asistente de software basado en el fichero DTC_Checker.c, guía al usuario durante la validación a su vez que ejecuta rutinas y servicios de diagnostico comunicándose con el modulo electrónico.

La intervención del usuario es fundamental para poder realizar acciones como la apertura de las puertas, pulsar el botón de arranque del vehiculo, presionar durante un tiempo los interruptores de apertura o cierre de las manetas, generar cortocircuitos a masa o batería, eliminar una carga, etc.

El software esta programado de tal manera que imita la secuencia de pasos que haría el propio validador. Para ello es necesario conocer en detalle la tabla 1 del apartado 2.6.9.1, las especificaciones del sistema y el conocimiento del funcionamiento del modulo cuando se encuentra integrado en el vehiculo. A continuación se detallan los códigos de error contenidos en el DTC_checker.c y las secuencias necesarias para provocarlos. Cabe mencionar que del mismo modo, el Protocolo de validación confeccionado para el proyecto también se basa en la misma secuencia.

3.1.1 Actuador de funciones remoto:

Código de error (HEX): 90A9 Síntoma: 00 Descripción del código de error: “Less than 2 keys programmed”. Síntomas para el usuario: La/s llave/s no programada/s es inoperativa. Llave no programada Información del error: El modulo principal registra únicamente una o ninguna llave electrónica en su memoria interna. Por defecto los vehículos se sirven con dos llaves. La/s llave/s no programada/s es inoperativa. Llave no programada Síntomas en el sistema: Una o ambas llaves no operativas. Implica la anulación total de cualquier funcionalidad del sistema por parte de dicha llave. Condiciones necesarias: No disponible para esta versión. Secuencia cualquiera para su reproducción: No disponible.

Código de error (HEX): C300 Síntoma: 00 Descripción del código de error: “NM state, NMExpulsion state reached”. Información del error: La ECU no recibe el identificador transmitido por la BCM durante mas de 7 segundos después un reset o después de despertar al bus, con lo cual el modulo no participa en el envío/recepción de tramas en el bus hasta que se corrige el problema por parte de la BCM. Síntomas en el sistema: No disponible.


59

Código de error (HEX): E100 Síntoma: 00 Descripción del código de error: “Missed or wrong calibration file”. Información del error: El Código de error se registra si el archivo de calibración del modulo electrónico es incorrecto o no existe. Dicho archivo se carga en la memoria del modulo durante su paso por la planta de ensamblaje del vehiculo y contiene los parámetros que utiliza la aplicación y que permiten distinguir un modelo de otro. Síntomas en el sistema: Provoca la reducción del perímetro de detección de la llave lo cual conlleva fallos para la ejecución de las funciones pasivas de entrada/cierre o arranque. Secuencia cualquiera para su reproducción:

1. Reemplazar el archivo de calibración del modulo (Usuario) 2. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3. Respuesta positiva + DTC+síntoma+estado: “59 02 7A E1 00 00 2A”. (ECU) 4. Reponer el modulo original de nuevo. (Usuario) 5. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): E101 Síntoma: 00 Descripción del código de error: “Invalid car configuration received”. Información del error: Indica que los parámetros de configuración transmitidos vía CAN por el modulo electrónico principal de control del vehiculo no se corresponde con los parámetros esperados por el modulo de entrada y arranque pasivo. Alerta sobre Síntomas en el sistema: Provoca la reducción del perímetro de detección de la llave lo cual conlleva fallos para la ejecución de las funciones pasivas de entrada/cierre o arranque. Secuencia cualquiera para su reproducción:

1. Reemplazar modulo electrónico de 3 conectores por otro de 2 (Usuario) 2. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3. Respuesta positiva + DTC+síntoma+estado: “59 02 7A E1 01 00 2A”. (ECU) 4. Reponer el modulo original de nuevo. (Usuario) 5. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): F000 Síntoma: 95 Descripción del código de error: “Wrong module installed”. Información del error: Indica error de instalación. El modulo de arranque pasivo ha sido instalado en un vehiculo preparado para entrada y arranque pasivos. Los parámetros de configuración de vehiculo transmitidos por la BCM indican que el tiene características distintas a las del modulo. Síntomas en el sistema: Funciones pasivas de entrada y cierre anuladas. Secuencia cualquiera para su reproducción:

1. Reemplazar modulo electrónico de 3 conectores por otro de 2 (Usuario) 2. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3. Respuesta positiva + DTC+síntoma+estado: “59 02 7A F0 00 95 2A”. (ECU) 4. Reponer el modulo original de nuevo. (Usuario) 5. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6. Obtener respuesta positiva: “54”. (ECU)


60

Código de error (HEX): F002

Síntoma: 81 Descripción del código de error: “Invalid Id number“. Información del error: El numero de serie del vehiculo no coincide con el numero de serie almacenado en el modulo electrónico. Síntomas en el sistema: No implica causas para el usuario. Secuencia cualquiera para su reproducción:

1. Reemplazar modulo electrónico por otro. (Usuario) 2. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3. Respuesta positiva + DTC+síntoma+estado: “59 02 7A F0 00 81 2A”. (ECU) 4. Reponer el modulo original de nuevo. (Usuario) 5. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6. Obtener respuesta positiva: “54”. (ECU)

3.1.2 Receptor de radio frecuencia:

Código de error (HEX): E01F Síntoma: 00 Descripción del código de error: “K-line bus short or driver failure “. Información del error: Fallo en la línea de comunicación existente entre la ECU y el receptor. Síntomas en el sistema: Funciones de radio frecuencia y/o pasivas anuladas. Condiciones necesarias: Si no existe respuesta del Receptor ante una petición de la ECU antes de un tiempo determinado el error queda registrado. Secuencia cualquiera para su reproducción:

1. Cortocircuitar “K-Line” a GND en BoB. 2. Forzar la comunicación ECU-Receptor: pulsar interruptor Start/stop. (ECU) 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A E0 1F 00 2A”.

(ECU) 5. Eliminar el cortocircuito de la BoB. 6. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 7. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): E01F Síntoma: 31 Descripción del código de error: “No communication with RFR “. Información del error: El receptor no responde a los mensajes enviados por la ECU. Síntomas en el sistema: Funciones de radio frecuencia y/o pasivas anuladas. Condiciones necesarias: A diferencia de otros, únicamente se registra cuando el Receptor no responde a la rutina de chequeo $0202. Secuencia cualquiera para su reproducción:

1. Forzar circuito abierto en pin “K-Line” de la BoB. 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 E0 1F 31”. (ECU)


61

7. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 8. Respuesta positiva+ DTC+síntoma+estado: “59 02 7A E0 1F 31 2A”.

(ECU) 9. Eliminar el circuito abierto en BoB. 10. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 11. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): E01F Síntoma: 95 Descripción del código de error: “RFR of wrong frequency is detected “. Información del error: Indica que el receptor instalado en el vehiculo no se corresponde con la información transmitida por CAN en la que se publica la frecuencia esperada del receptor en el sistema. Síntomas en el sistema: Funciones de radio frecuencia y/o pasivas anuladas. Condiciones necesarias: Las características del Receptor se chequean por la ECU después de un reset o en desconectar/conectar dicho componente. El código de error se registra si la frecuencia del receptor no se ajusta a la indicada en los parámetros de configuración del vehiculo que transmite la BCM en el bus. Secuencia para su reproducción:

1. Desconectar el Receptor original a través de la BoB. 2. Conectar Receptor distinta frecuencia del original. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva+ DTC+síntoma+estado: “59 02 7A E0 1F 31 2A”.

(ECU) 5. Eliminar el circuito abierto en BoB. 6. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 7. Obtener respuesta positiva: “54”. (ECU)

3.1.3 Antenas:

Código de error (HEX): 90C6/ 90C7/ 90C8/ 90C9/ 90CA/ 90CB/ 9335/ 9336/ 9337/ 933D Síntoma: 11 Descripción del código de error: “Short to GND “. Información del error: Alerta que uno o ambos polos de conexión de la antena han sido cortocircuitados a masa o entre si. Síntomas en el sistema:

a) 90C6: Apertura pasiva del maletero anulada. b) 90C7: Llave electrónica no detectada en el interior del maletero. c) 90C8/ 90C9/ 9335/ 933D: Problemas de detección de la llave en el interior de la

cabina del vehiculo pudiendo darse el caso de usar un sistema adicional para el arranque del vehiculo.

d) 90CA: Apertura/cierre de la puerta trasera izquierda anulada. e) 90CB: Apertura/cierre de la puerta trasera derecha anulada. f) 9336: Apertura/cierre de la puerta delantera izquierda anulada. g) 9337: Apertura/cierre de la puerta delantera derecha anulada.


62

Secuencia para su reproducción: 90C6:

1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT4(+)”a “GND” o “ANT4(+)” a “ANT4(-)” o “ANT4(-) ”a “GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 C6 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)

90C7:


90C8:


90C9:



63

90CA: 1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT6(+)”a “GND” o “ANT6(+)” a “ANT6(-)” o “ANT6(-) ”a “GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 CA 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)

90CB:

1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT8(+)”a “GND” o “ANT8(+)” a “ANT8(-)” o “ANT8(-) ”a “GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 CB 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)

9335:

1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT10(+)”a “GND” o “ANT10(+)” a “ANT10(-)” o “ANT1 0(-)”a

“GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 35 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)

9336:

1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT5(+)”a “GND” o “ANT5(+)” a “ANT5(-)” o “ANT5(-) ”a “GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 36 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)


64

9337: 1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT7(+)”a “GND” o “ANT7(+)” a “ANT7(-)” o “ANT7(-) ”a “GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 37 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)

933D: 1. Cortocircuitar los siguiente pines en “BoB”: 2. “ANT9(+)”a “GND” o “ANT9(+)” a “ANT9(-)” o “ANT9(-) ”a “GND”. 3. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 4. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 5. Tiempo de espera por ejecución rutina: 12 segundos. 6. Lectura de resultado: “31 03 02 02”. (Tester) 7. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 3D 11”. (ECU) 8. Eliminar cortocircuito en BoB. 9. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 10. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): 90C6/ 90C7/ 90C8/ 90C9/ 90CA/ 90CB/ 9335/ 9336/ 9337/ 933D Síntoma: 12 Descripción del código de error: “Short to Batt. “. Información del error: Alerta que uno o ambos polos de conexión de la antena han sido cortocircuitados a batería. Síntomas en el sistema:




Condiciones necesarias: 90C6:

1. Conectar los pines “ANT4(-)” o “ANT4(-)” a “BATT SUPP” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 C6 12”. (ECU) 7. Eliminar cortocircuito en BoB.


65

8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

90C7:

1. Conectar los pines “ANT3(-)” o “ANT3(-)” a “BATT SUPP” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 C7 12”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

90C8:


90C9:


90CA:

1. Conectar los pines “ANT6(-)” o “ANT6(-)” a “BATT SUPP” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 CA 12”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)


66

90CB: 1. Conectar los pines “ANT8(-)” o “ANT8(-)” a “BATT SUPP” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 CB 12”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

9335:

1. Conectar los pines “ANT10(-)” o “ANT10(-)” a “BATT SUPP” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 35 12”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

9336:


9337:


933D:

1. Conectar los pines “ANT9(-)” o “ANT9(-)” a “BATT SUPP” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester)


67

6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 3D 12”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): 90C6/ 90C7/ 90C8/ 90C9/ 90CA/ 90CB/ 9335/ 9336/ 9337/ 933D Síntoma: 13 Descripción del código de error: “Open circuit“. Información del error: Alerta que uno o ambos polos de conexión de la antena se encuentran en circuito abierto. Síntomas en el sistema:





1. Forzar circuito abierto en los pines “ANT4(-)” o “ANT4(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 C6 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

90C7:


90C8:

1. Forzar circuito abierto en los pines “ANT2(-)” o “ANT2(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU)


68

4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 C8 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

90C9:


90CA:

1. Forzar circuito abierto en los pines “ANT6(-)” o “ANT6(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 CA 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

90CB:

1. Forzar circuito abierto en los pines “ANT8(-)” o “ANT8(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 90 CB 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

9335:

1. Forzar circuito abierto en los pines “ANT10(-)” o “ANT10(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 35 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)


69

9336: 1. Forzar circuito abierto en los pines “ANT5(-)” o “ANT5(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 36 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

9337:

1. Forzar circuito abierto en los pines “ANT7(-)” o “ANT7(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 37 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

933D:

1. Forzar circuito abierto en los pines “ANT9(-)” o “ANT9(-)” en “BoB” 2. Ejecutar rutina de auto diagnostico del sistema: “31 01 02 02”. (Tester) 3. Obtener respuesta positiva: “71 01 02 02 22”. (ECU) 4. Tiempo de espera por ejecución rutina: 12 segundos. 5. Lectura de resultado: “31 03 02 02”. (Tester) 6. Respuesta positiva+ DTC+síntoma: “71 03 02 02 93 3D 13”. (ECU) 7. Eliminar cortocircuito en BoB. 8. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 9. Obtener respuesta positiva: “54”. (ECU)

3.1.4 Unlock Switch: Código de error (HEX): 90C1/ 90C2/ 90C3/ 90C4 Síntoma: 15 Descripción del código de error: “Stuck open“. Información del error: Indica fallo por circuito abierto en el interruptor de apertura integrado en el tirador de la puerta. Síntomas en el sistema: Percepción del usuario de resistencia ante la acción de la apertura de la puerta en modo pasivo. En interruptores no capacitivos, necesidad de accionar 2 veces el tirador para que se produzca la apertura. El DTC se registra si el “Clutch Switch” se activa sin haberse activado previamente el “Unlock Switch” seis veces consecutivas.


70

Condiciones necesarias: a) 90C1: Interruptor delantero izquierdo de apertura. b) 90C2: Interruptor trasero izquierdo de apertura. c) 90C3: Interruptor delantero derecho de apertura. d) 90C4: Interruptor trasero derecho de apertura.

90C1: 1. Cerrar el vehiculo. 2. En “BoB”, forzar circuito abierto en pin “LF ULOCK”. 3. Apertura del vehiculo de forma pasiva a través del tirador delantero izquierdo (1). 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva : “59 02 7A”. (ECU) 6. Cerrar el vehiculo. 7. Apertura del vehiculo de forma pasiva a través del tirador delantero izquierdo (2). 8. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 9. Respuesta positiva : “59 02 7A”. (ECU) 10. Cerrar el vehiculo. 11. Apertura del vehiculo de forma pasiva a través del tirador delantero izquierdo (3). 12. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 13. Respuesta positiva : “59 02 7A”. (ECU) 14. Cerrar el vehiculo. 15. Apertura del vehiculo de forma pasiva a través del tirador delantero izquierdo (4). 16. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 17. Respuesta positiva : “59 02 7A”. (ECU) 18. Cerrar el vehiculo. 19. Apertura del vehiculo de forma pasiva a través del tirador delantero izquierdo (5). 20. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 21. Respuesta positiva : “59 02 7A”. (ECU) 22. Cerrar el vehiculo. 23. Apertura del vehiculo de forma pasiva a través del tirador delantero izquierdo (6). 24. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 25. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C1 15 2A”. (ECU) 26. Eliminar el circuito abierto en “BoB”. 27. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 28. Obtener respuesta positiva: “54”. (ECU)

90C2:

1. Cerrar el vehiculo. 2. En “BoB”, forzar circuito abierto en pin “LR ULOCK”. 3. Apertura del vehiculo de forma pasiva a través del tirador trasero izquierdo (1). 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva : “59 02 7A”. (ECU) 6. Cerrar el vehiculo. 7. Apertura del vehiculo de forma pasiva a través del tirador trasero izquierdo (2). 8. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 9. Respuesta positiva : “59 02 7A”. (ECU) 10. Cerrar el vehiculo. 11. Apertura del vehiculo de forma pasiva a través del tirador trasero izquierdo (3). 12. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 13. Respuesta positiva : “59 02 7A”. (ECU)


71

14. Cerrar el vehiculo. 15. Apertura del vehiculo de forma pasiva a través del tirador trasero izquierdo (4). 16. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 17. Respuesta positiva : “59 02 7A”. (ECU) 18. Cerrar el vehiculo. 19. Apertura del vehiculo de forma pasiva a través del tirador trasero izquierdo (5). 20. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 21. Respuesta positiva : “59 02 7A”. (ECU) 22. Cerrar el vehiculo. 23. Apertura del vehiculo de forma pasiva a través del tirador trasero izquierdo (6). 24. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 25. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C2 15 2A”. (ECU) 26. Eliminar el circuito abierto en “BoB”. 27. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 28. Obtener respuesta positiva: “54”. (ECU)

90C3:

1. Cerrar el vehiculo. 2. En “BoB”, forzar circuito abierto en pin “RF ULOCK”. 3. Apertura del vehiculo de forma pasiva a través del tirador delantero derecho (1). 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva : “59 02 7A”. (ECU) 6. Cerrar el vehiculo. 7. Apertura del vehiculo de forma pasiva a través del tirador delantero derecho (2). 8. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 9. Respuesta positiva : “59 02 7A”. (ECU) 10. Cerrar el vehiculo. 11. Apertura del vehiculo de forma pasiva a través del tirador delantero derecho (3). 12. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 13. Respuesta positiva : “59 02 7A”. (ECU) 14. Cerrar el vehiculo. 15. Apertura del vehiculo de forma pasiva a través del tirador delantero derecho (4). 16. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 17. Respuesta positiva : “59 02 7A”. (ECU) 18. Cerrar el vehiculo. 19. Apertura del vehiculo de forma pasiva a través del tirador delantero derecho (5). 20. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 21. Respuesta positiva : “59 02 7A”. (ECU) 22. Cerrar el vehiculo. 23. Apertura del vehiculo de forma pasiva a través del tirador delantero derecho (6). 24. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 25. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C3 15 2A”. (ECU) 26. Eliminar el circuito abierto en “BoB”. 27. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 28. Obtener respuesta positiva: “54”. (ECU)

90C4:

1. Cerrar el vehiculo. 2. En “BoB”, forzar circuito abierto en pin “RR ULOCK”. 3. Apertura del vehiculo de forma pasiva a través del tirador trasero derecho (1).


72

4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva : “59 02 7A”. (ECU) 6. Cerrar el vehiculo. 7. Apertura del vehiculo de forma pasiva a través del tirador trasero derecho (2). 8. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 9. Respuesta positiva : “59 02 7A”. (ECU) 10. Cerrar el vehiculo. 11. Apertura del vehiculo de forma pasiva a través del tirador trasero derecho (3). 12. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 13. Respuesta positiva : “59 02 7A”. (ECU) 14. Cerrar el vehiculo. 15. Apertura del vehiculo de forma pasiva a través del tirador trasero derecho (4). 16. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 17. Respuesta positiva : “59 02 7A”. (ECU) 18. Cerrar el vehiculo. 19. Apertura del vehiculo de forma pasiva a través del tirador trasero derecho (5). 20. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 21. Respuesta positiva : “59 02 7A”. (ECU) 22. Cerrar el vehiculo. 23. Apertura del vehiculo de forma pasiva a través del tirador trasero derecho (6). 24. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 25. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C4 15 2A”. (ECU) 26. Eliminar el circuito abierto en “BoB”. 27. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 28. Obtener respuesta positiva: “54”. (ECU)

Código de error (HEX): 90C1/ 90C2/ 90C3/ 90C4/ 90C5/ 9334 Síntoma: 23 Descripción del código de error: “Stuck on“. Información del error: Indica fallo por cortocircuito a masa en el interruptor de apertura integrado en el tirador de la puerta. Síntomas en el sistema: Percepción del usuario de resistencia ante la acción de la apertura de la puerta en modo pasivo. En interruptores no capacitivos, necesidad de accionar 2 veces el tirador para que se produzca la apertura.

a) 90C1: Interruptor delantero izquierdo de apertura. b) 90C2: Interruptor trasero izquierdo de apertura. c) 90C3: Interruptor delantero derecho de apertura. d) 90C4: Interruptor trasero derecho de apertura. e) 90C5: Interruptor de apertura del maletero. f) 9334: Interruptor de apertura de la parte superior del maletero.


1. Cerrar el vehiculo. 2. En “BoB”, cortocircuitar pin “LF ULOCK” a “GND”. 3. Mantener durante 45 segundos. 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C1 23 2A”.

(ECU)


73

6. Eliminar cortocircuito en “BoB”. 7. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 8. Obtener respuesta positiva: “54”. (ECU) 9. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 10. Respuesta positiva: “59 02 7A”. (ECU)

90C2:

1. Cerrar el vehiculo. 2. En “BoB”, cortocircuitar pin “LR ULOCK” a “GND”. 3. Mantener durante 45 segundos. 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C2 23 2A”.

(ECU) 6. Eliminar cortocircuito en “BoB”. 7. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 8. Obtener respuesta positiva: “54”. (ECU) 9. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 10. Respuesta positiva: “59 02 7A”. (ECU)

90C3:

1. Cerrar el vehiculo. 2. En “BoB”, cortocircuitar pin “RF ULOCK” a “GND”. 3. Mantener durante 45 segundos. 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C3 23 2A”.


90C4:

1. Cerrar el vehiculo. 2. En “BoB”, cortocircuitar pin “RR ULOCK” a “GND”. 3. Mantener durante 45 segundos. 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C4 23 2A”.


90C5:

1. Cerrar el vehiculo. 2. En “BoB”, cortocircuitar pin “BOOT REL” a “GND”. 3. Mantener durante 45 segundos. 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester)


74

5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 C5 23 2A”. (ECU)

6. Eliminar cortocircuito en “BoB”. 7. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 8. Obtener respuesta positiva: “54”. (ECU) 9. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 10. Respuesta positiva: “59 02 7A”. (ECU)

9334:

1. Cerrar el vehiculo. 2. En “BoB”, cortocircuitar pin “BT GL REL” a “GND”. 3. Mantener durante 45 segundos. 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 93 34 23 2A”.


3.1.5 Lock Switch: Código de error (HEX): 90D1/ 90D2/ 90D3/ 90D4/ 5017 Síntoma: 23 Descripción del código de error: “Stuck on “. Información del error: Indica fallo por cortocircuito a masa en el interruptor de cierre integrado en el tirador de la puerta. Síntomas en el sistema:

a) 90D1: Interruptor delantero izquierdo de cierre. b) 90D2: Interruptor trasero izquierdo de cierre. c) 90D3: Interruptor delantero derecho de cierre. d) 90D4: Interruptor trasero derecho de cierre. e) 5017: Interruptor de cierre del maletero.

Condiciones necesarias: 90D1:

1. En “BoB”, cortocircuitar pin “LF LOCK” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 D1 23 2A”.



75

90D21: 1. En “BoB”, cortocircuitar pin “LR LOCK” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 D2 23 2A”.


90D3:

1. En “BoB”, cortocircuitar pin “RF LOCK” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+sintoma+estado: “59 02 7A 90 D3 23 2A”.


90D4:

1. En “BoB”, cortocircuitar pin “LR LOCK” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 D4 23 2A”.


5017:

1. En “BoB”, cortocircuitar pin “BOOT LCK” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 50 17 23 2A”.



76

3.1.6 Latch Clutch Switch: Código de error (HEX): 90CC/ 90CD/ 90CE/ 90CF Síntoma: 23 Descripción del código de error: “Stuck on“. Información del error: Indica fallo por cortocircuito a masa en el interruptor que permite el embrague del pestillo de la puerta para su apertura. Síntomas en el sistema: El sistema de entrada pasivo no responde cuando se activa el tirador de la puerta, consecuentemente, el vehiculo debe ser abierto pulsando el correspondiente botón en la llave electrónica previo a la apertura de la puerta. Necesidad de accionar 2 veces el tirador para que se produzca la apertura.(la primera produce el Unlock y la segunda el Unlatch) en el caso de apertura pasiva. Condiciones necesarias:

a) 90CC: Interruptor delantero izquierdo del Latch Clutch. b) 90CD: Interruptor trasero izquierdo del Latch Clutch. c) 90CE: Interruptor delantero derecho del Latch Clutch. d) 90CF: Interruptor trasero derecho del Latch Clutch.

90CC:

1. En “BoB”, cortocircuitar pin “FL CLUTCH” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 CC 23 2A”.


90CD:

1. En “BoB”, cortocircuitar pin “RL CLUTCH” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 CD 23 2A”.


90CE:

1. En “BoB”, cortocircuitar pin “FR CLUTCH” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 CE 23 2A”.

(ECU) 5. Eliminar cortocircuito en “BoB”.


77

6. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 7. Obtener respuesta positiva: “54”. (ECU) 8. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 9. Respuesta positiva: “59 02 7A”. (ECU)

90CF:

1. En “BoB”, cortocircuitar pin “RR CLUTCH” a “GND”. 2. Mantener durante 45 segundos. 3. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 4. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 90 CF 23 2A”.


3.1.7- Latch Relay: Código de error (HEX): 92D6 Síntoma: 11 Descripción del código de error: “Short to GND on E-latch “. Información del error: Una o más salidas del relé que activa el motor que controla el embrague rápido para la apertura de la puerta se encuentran cortocircuitadas a masa. Síntomas en el sistema: Necesidad de accionar 2 veces el tirador para que se produzca la apertura (la primera produce el Unlock y la segunda el Unlatch). Condiciones necesarias: 92D6:

1. En “BoB”, cortocircuitar pin “FL6 MOTOR(+)” a “GND”. 2. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 92 D6 11 2A”. (ECU) 4. Eliminar cortocircuito en “BoB”. 5. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6. Obtener respuesta positiva: “54”. (ECU) 7. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 8. Respuesta positiva: “59 02 7A”. (ECU)

_________________________ 6 Será necesario substituir”FL MOTOR (+)” por “LR MOTOR (+)”, “RF MOTOR (+)” y “RR MOTOR (+)” sucesivamente para poder chequear el código de error en cada uno de los motores de las puertas. El DTC 92D6 no distingue entre motores.


78

Código de error (HEX): 92D6 Síntoma: 12 Descripción del código de error: “Short to Batt on E-latch“. Información del error: Una o más salidas del relé que activa el motor que controla el embrague rápido para la apertura de la puerta se encuentran cortocircuitadas a batería. Síntomas en el sistema: Necesidad de accionar 2 veces el tirador para que se produzca la apertura.(la primera produce el Unlock y la segunda el Unlatch). Condiciones necesarias: 92D6:

1.En “BoB”, cortocircuitar pin “FL7 MOTOR(-)” a “BATT SUPP”. 2.Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3.Respuesta positiva + DTC+síntoma+estado: “59 02 7A 92 D6 12 2A”. (ECU) 4.Eliminar cortocircuito en “BoB”. 5.Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6.Obtener respuesta positiva: “54”. (ECU) 7.Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 8.Respuesta positiva: “59 02 7A”. (ECU)

3.1.8 Door Handles

Código de error (HEX): 92D5 Síntoma: 16 Descripción del código de error: “Handle supply voltage more than 3V below VBat“. Información del error: Indica un voltaje insuficiente en el tirador de la puerta, consecuentemente, los interruptores integrados en el, no responden. Síntomas en el sistema: Sistema pasivo de entrada/ cierre no disponible. Condiciones necesarias: 92D5:

1. En “BoB”, reducir voltage en “DH SUPP” 3V respecto “VBATT” 2. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 3. Respuesta positiva + DTC+síntoma+estado: “59 02 7A 92 D5 16 2A”. (ECU) 4. Restaurar voltaje en “DH SUPP” en “BoB”. 5. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 6. Obtener respuesta positiva: “54”. (ECU)

______________________________ 7 Será necesario substituir”FL MOTOR (-)” por “LR MOTOR (-)”, “RF MOTOR (-)” y “RR MOTOR (-)” sucesivamente para poder chequear el código de error en cada uno de los motores de las puertas. El DTC 92D6 no distingue entre motores.


79

3.1.9 Medium Speed CAN bus: Código de error (HEX): C010 Síntoma: 88 Descripción del código de error: “NM State. NMBussOffwait is reached“. Información del error: Alerta sobre un problema de comunicación en el bus CAN. Síntomas en el sistema: Fallo general del sistema, funciones pasivas o remotas anuladas. C010 88 (HI)

1. Detener Tester Present y cortocircuitar “CAN HI” a “GND” 2. Restaurar el error. 3. Activar tester Present 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A C0 10 88 2A”.

(ECU) 6. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 7. Obtener respuesta positiva: “54”. (ECU)

C010 88 (LO)

1. Detener Tester Present y cortocircuitar “CAN LO” a “BATT” 2. Restaurar el error. 3. Activar tester Present 4. Ejecutar rutina de lectura de DTCs “19 02 20”. (Tester) 5. Respuesta positiva + DTC+síntoma+estado: “59 02 7A C0 10 88 2A”.

(ECU) 6. Eliminar DTCs: ejecutar rutina “14 FF FF FF”. (Tester) 7. Obtener respuesta positiva: “54”. (ECU)


80

3.2- Diagrama de flujo de la interfaz visual con el usuario

El código que permite al usuario navegar entre menus por pantalla, responde al siguiente diagrama de estados:

Figura 26: Menú principal e inicio programa.

Inicio

Fin

Seleccionar archivo Log file.

Almacenar los datos en un Log file?

Comprobar Información del sistema y parámetros de configuración mediante envío de tramas del servicio 22.

Activar Tester Present

Si

No

Opción 10

Opción 11

1-AFR Menu

2-RRF Menu

3-Antena Menu

4-Unlock Switch Menú

Opción 1

Opción 2

Opción 3

Opción 4

Opción 5

Opción 6

Opción 7

Opción 9

5- Lock Switch Menú

6- Latch Clutch Menú

7- ELatch Menú

8- Door handle Menú

9- CAN bus Menú

Stop Tester Present & Logging

Asignar dirección del modulo

MENU PRINCIPAL: Seleccionar componente a validar:

1-AFR; 2-RRF; 3-Antenas; 4-Unlock switch; 5-Lock switch; 6-Latch Clutch; 7-ELatch; 8-Door handles; 9-CANbus; 10-Return; 11-Exit


81

Figura 27: Ejemplo Menú de navegación de un componente.

Menú Componente

Menú Principal

Seleccionar DTC a validar:

1-Volver Menu Principal 2-Validar todos consecutivamente. 3- DTC 1 4- DTC 2 5- DTC xx…

Opción 1 Opción 3

Función DTC 1 ( );

Función DTC 2 ( );

Función DTC 3 ( );

...

Menú DTC 1

Repetir?

No Si

Opción 2


82

Figura 28: Ejemplo Menú de navegación de un DTC.

Menú DTC 1

Tipos de fallo del DTC 1 a validar:

Tipo 1, Tipo 2, Tipo3…Continuar?

No

No

Menú Componente

Función DTC 1 Tipo 1( );

Función DTC 1 Tipo 2( );

Función DTC 1 Tipo X( );

Repetir los tests? Si

Si


83

4. ECU DIAGNOSTICS TOOL


84

4 ECU Diagnostics Tool

4.1 Entorno y funcionalidad

ECU Diagnostics Tool es una aplicación de software que funciona bajo un entorno Windows y a través de una interfaz de CAN, permite comunicar un PC (Tester) con una ECU (Server) de un vehiculo. A su vez es el medio visual del usuario la permite visualizar el trafico de comunicación de envío y recepción entre ambos dispositivos.

Destaca como ventaja la capacidad de ejecutar archivos programados en lenguaje C la cual nos ha permitido desarrollar un código programado (DTC_Checker.c) que funciona bajo el entorno de la ECU Diagnostics Tool y que ha permitido desarrollar la herramienta para la validación de DTCs en nuestra ECU. A nivel visual para el usuario se ha creado un menú amigable capaz de guiar al validador a través de los distintos DTCs a testear y aportar información acerca de los pasos a seguir mientras que a un segundo nivel, se trabaja directamente con las comunicaciones y se procede al envío/recepción de tramas entre Tester/ECU.

El archivo DTC_Checker.c controla los campos del ECU Diangostics Tool que se explican a continuación durante su funcionamiento.

Figura 29: .Pantalla principal del ECU Diagnostics Tool

Pantalla de visualizacion de tramas enviadas y recibidas.

Barra de estado

Script control window Logging Control window Estado de TX/RX Tester Present

Area de comandos


85

4.1.1 Barra de Estado:

Permite adaptar la configuración del ECU Diagnostics Tool a la configuración establecida en la interfaz de comunicaciones CAN que habilita el canal de comunicación entre el PC (Tester) y el bus del vehiculo. Esta formado por tres campos y su modificación es posible mediante un doble clic en cada uno de ellos:

Communications Port: Permite seleccionar que puerto de comunicaciones se debe utilizar para el intercambio de datos entre el Tester y la interfaz de CAN asociada. En este caso será necesario seleccionar el canal 1 acorde con la configuración de la interfaz de CAN.

ECU Diagnostics Tool Status: Permite conectar/desconectar el Tester del bus de comunicaciones.

Protocol Comunications Parametres: Permite establecer la velocidad de comunicación del bus. Para el objetivo de este proyecto será necesaria la comunicación de Medium Speed CAN de 125 kbit/s.

4.1.2 Área de Comandos:

Permite configurar propiedades tales como el protolo de comunicación, el vehiculo donde se va a usar, el dispositivo o ECU, la dirección, el comando a ejecutar, los datos a transmitir y el tipo de comando. Para nuestro proposito los campos más relevantes son:

a) Protocol: Permite adecuar el tipo de protocolo de comunicación del sistema, configurado en nuestro caso para comunicación CAN 11 bit.

b) Address: Dirección en valor hexadecimal con la que el Tester pretende comunicarse con la ECU (0x731)

c) Command type / Security Interface: Este campo permite al usuario seleccionar que tipo de sesión de diagnostico requiere en ese momento pudiendo escoger entre Normal, FastInitPrefix, 5BaudInit y SecureAccesRqst. Las opciones relevantes para nuestro caso serán:

a. Normal: Permite el envío de tramas bajo sesión estándar ($10 01) y sesión extendida ($10 03).

b. SecureAccessRqst: Imprescindible cuando se requiere solicitar acceso en la sesión seguridad (Servicio 27). La concesión para poder trabajar en la sesión de Seguridad, es específica a cada ECU y requiere un intercambio de datos encriptados entre la ECU y el Tester para poder acceder a ella. Para que la transmisión de códigos encriptados sea posible se requiere cargar un archivo en el campo Security Interface.

d) Data / Send: Mensaje o trama a ser enviada por el Tester a la ECU. La herramienta reconoce la cantidad de bytes que son enviados suprimiendo la necesidad de tener que indicar la longitud de la trama al inicio del mensaje.


86

4.1.3 Script Control

El menú Script control permite seleccionar un script y ejecutarlo en pulsar el botón Execute. El script tomara el control de la ECU Diagnostics Tool durante el tiempo que dure su ejecución.

Para cargar un script se deberá accionar el botón de puntos suspensivos el cual abrirá una ventana de dialogo que permitirá navegar por el explorador de Windows hasta seleccionar el archivo conveniente. Cualquier acción disponible en el entorno manual puede ser controlada y dirigida mediante el uso de scripts. Además existen una gran cantidad de funciones que permiten ejecutar tareas repetitivas y tediosas así como tareas que necesiten controlar tiempos de ejecución y respuesta entre otras.

Para hacer uso de la herramienta de validación semi automática de DTCs se deberá seleccionar el archivo “DTC_Checker.c “. Este archivo en código de programación C, contiene los comandos de configuración para adecuar el entorno del ECU Diagnostics Tool de acuerdo a las necesidades del modulo electrónico Accionador de Funciones Remoto.

4.1.4 Logging Control

El Logging Control permite seleccionar un archivo donde registrar todas las tramas de comunicación que se dan entre el Tester y la ECU. En pulsar el botón de elipsis, se abrirá una ventana de entorno Windows permitiendo seleccionar el archivo donde almacenar la información. También es posible acceder al cuadro de dialogo de selección de archivo a través de Start logging to file, hallado en el File menú de la barra de tareas.

El archivo “DTC_Checker.c” activa automáticamente dicha función. El archivo generado, será utilizado posteriormente por la macro de Visual Basic para plasmar los resultados obtenidos durante los tests en un archivo de Excel.

4.1.5 Tester Present & Estado de TX/RX:

Cuando la función TP se encuentra habilitada en la barra de tareas de la pantalla principal, se produce el envío automático del mensaje “Tester Present”. Tal y como se ha comentado en el apartado de Servicios de diagnostico, el envío cíclico de TP informa a la ECU de que el “tester” sigue conectado al vehiculo y pretende mantener activa la comunicación entre ambos.

El periodo de envío de la señal para modo de envío automático es configurable en el menú “Tools � Tester Present”.


87

Los leds simulados TX y RX se habilitan cuando se produce una envío/recepción de tramas entre el Tester y la ECU.

4.1.6 Pantalla de visualización TX/RX de tramas

La pantalla de visualización de tramas es el medio que permite al usuario conocer comunicación existente entre el Tester y la ECU que se produce debido al envío de tramas de diagnostico a través de la ventana de comandos.


88

5. PRESUPUESTO


89

5.1 Resumen del presupuesto

El coste ocasionado para la compañía Kotse Limited ha sido de cero euros dado que los materiales utilizados eran activos de la empresa a los que se les ha sabido sacar un mayor partido. Sin embargo, la solución de este proyecto puede ser de utilidad para otros módulos electrónicos que se encuentren en la misma situación.

Gracias a que el software de diagnósticos (ECU Diagnostics Tool) se proporciona por la compañía Kotse Limited, el presupuesto para establecer la infraestructura necesaria para el desarrollo e implementación de una herramienta semi automática de validación de DTCs en un modulo de control electrónico de un vehiculo es de:

CANT. DESCRIPCION Precio U. Precio Total

1 CANCaseXL

(o similar interfaz de CAN) 172.00 €/u 172.00 €/u

1 Licencia de Hardware de CAN 2.833 €/u 2.833 €

1 Cable de conexión DB9/ J1962 25,30 €/u 25,30 €

1 Breakout box 368,56 €/u 368,56 €

Precio Total 3398, 86€

El precio total del presupuesto asciende a TRES MIL TRES CIENTOS NOVENTA Y OCHO EUROS CON OCHENTA Y SEIS CENTIMOS DE EURO.


90

6. CONCLUSIÓN


91

6.1 Conclusión

Previo a que la herramienta de ayuda semi automatizada para la validación de DTCs mediante tramas de diagnostico entre PC / ECU fuese implementada se experimentaba la siguiente problemática:

• Gran numero de horas invertidas para la validación de DTCs en vehiculo.

• Un coste empresarial anual de aproximado de 24.000 Euros.

• Falta de personal instruido para el testeo mediante tramas de diagnostico.

• Perdida del saber hacer debido a cambios laborales de los empleados con conocimientos.

• Necesidad de un protocolo de validación actualizado con la información paso a paso del proceso de validación.

La nueva herramienta de validación se compone de material ya existente en la compañía al cual se le ha sacado un mayor partido en implementar un software y un protocolo que han permitido resolver los problemas anteriores además de:

• Reducción del tiempo de validación de 40 horas, en el peor de los casos, a 6 horas actualmente lo que implica una reducción del 85% de las horas invertidas en la validación de DTCs.

• Posibilidad de mantener un control de las características y configuración del sistema validado así como de un registro de resultados del test gracias al binomio DTC_Checker.c & Protocolo de Validación.

El importante detalle es que la solución adoptada ha permitido obtener grandes beneficios tal y como se ha comentado en los puntos anteriores y con un coste para la compañía de 0 Euros.


92

7. ANEXOS


93

7.1 Archivos adjuntos del proyecto

El proyecto consta en formato digitalizado de 2 archivos que forman parte del mismo:

1. Archivo “DTC_Checker.c”: Código de programación en C (véase apartado 7.2) que permite la asistencia, guiado, envío de tramas y almacenar la información.

2. Archivo “DTC Validation Protocol.xls” de Microsoft Excel el cual contiene la Macro en Visual Basic (véase apartado 7.3) y permite cargar y comprobar los datos almacenados durante la validación por el DTC_Checker.


94

7.2 Código fuente del DTC_Checker.c

//************************************************* ************// //************************************************* ***********// //** //** Current File : RFA DTC CHECKER.c //** Modified Date : 10/06/2012 //** //** Author : Marc Morillo //** Original date : 19/11/2012 //** //** Description : General RFA Data Trouble Codes & Diagnostics checker script //** //************************************************* ****************// //************************************************* ****************// //------------------------------------------------- --------------- // INCLUDES //------------------------------------------------- -------------- #include <edg_defs.h> #include <ecudiagt.h> #include <edg_can.h> #include <edg_evnt.h> #include <stdio.h> #include <stdarg.h> #include <stdlib.h> #include <stddef.h> #include <string.h> //------------------------------------------------- --------------- // DEFINES & MACROS //------------------------------------------------- --------------- #define i_INICIO 0 //States index./Start, logging function request. #define i_RFA_M 1 //States index./RFA Main Menu #define i_RFR_M 2 //States index./RFR Main Menu #define i_ANTENNAS_M 3 //States index./ANTENNAS Main Menu #define i_UNLOCK_SW_M 4 //States index./UNLOCK SWITCH Main Menu #define i_LOCK_SW_M 5 //States index./LOCK SWITCH Main Menu #define i_LATCH_CLUTCH_M 6 //States index./LATCH CLUTCH Main Menu #define i_E_LATCH_M 7 //States index./E-LATCH Main Menu #define i_DOOR_HANDLE_M 8 //States index./DOOR HANDLE Main Menu #define i_CAN_BUS_M 9 //States index./CAN BUS Main Menu #define i_RETURN_INICIO 10 //States index./RETURN TO Main Menu #define i_EXIT_M 11 //States index./EXIT Main Menu #define i_BYE_BYE 12 //States index./PRE_EXIT Main Menu. #define i_MAIN_M 13 //States index./Dtc's Main Menu. #define MAX 24 //------------------------------------------------- ---------------- // FUNCTION PROTOTYPES //------------------------------------------------- ---------------- void f_inicio (); //Function called from the state i_INICIO, init commands before the tests starts. void f_rfa_m (); //Function called from the RFA Main Menu void f_rfr_m (); //Function called from the RFR Main Menu void f_antennas_m (); //Function called from the ANTENNAS Main Menu void f_unlock_sw_m (); // called from the UNLOCK SWITCH Main Menu void f_lock_sw_m (); / /called from the LOCK SWITCH Main Menu


95

void f_latch_clutch_m (); //called from the LATCH CLUTCH Main Menu void f_e_latch_m (); // called from the E-LATCH Main Menu void f_door_handle_m (); // called from the DOOR HANDLE Main Menu void f_can_bus_m (); // called from the CAN BUS Main Menu void f_return_inicio (); // called from the RETURN TO Main Menu void f_exit_m (); // called from the EXIT Main Menu void f_bye_bye (); //called from the PRE_EXIT Main Menu void f_main_m (); //called from the MAIN_M Main Menu void f_Clean_DTCs (); //It's a global function that runs the 14 FF FF FF routine to clean DTC's. void f_Read_DTCs (); //It's a global function that runs the 19 02 AF routine to read DTC's. void f_W_8006 (); //It's a global function that runs the 31 01 80 06 routine. void f_R_8006 (); //It's a global function that runs the 31 03 80 06 routine. void f_ODST ( const char * label); //Writtes,waits 10 seconds and reads the ODST Routine results. void f_Reset (); //Writtes 11 01 in order to reset the module. void f_90A9 (); //RFA DTC functions. void f_C300 (); //RFA DTC functions. void f_E100 (); //RFA DTC functions. void f_E101 (); //RFA DTC functions. void f_F000 (); //RFA DTC functions. void f_F002 (); //RFA DTC functions. void f_E01F (); //RFR DTC functions. void f_rfr_00 (); //RFR DTC functions. void f_rfr_31 (); //RFR DTC functions. void f_rfr_95 (); //RFR DTC functions. void f_90C6 (); //Antenna DTC functions. void f_90C7 (); //Antenna DTC functions. void f_90C8 (); //Antenna DTC functions. void f_90C9 (); //Antenna DTC functions. void f_90CA (); //Antenna DTC functions. void f_90CB (); //Antenna DTC functions. void f_9335 (); //Antenna DTC functions. void f_9336 (); //Antenna DTC functions. void f_9337 (); //Antenna DTC functions. void f_933D (); //Antenna DTC functions. void f_90C1 (); //Unlock switch DTC functions. void f_90C2 (); //Unlock switch DTC functions. void f_90C3 (); //Unlock switch DTC functions. void f_90C4 (); //Unlock switch DTC functions. void f_90C5 (); //Unlock switch DTC functions. void f_9334 (); //Unlock switch DTC functions. void f_90D1 (); //Lock switch DTC functions. void f_90D2 (); //Lock switch DTC functions. void f_90D3 (); //Lock switch DTC functions. void f_90D4 (); //Lock switch DTC functions. void f_5017 (); //Lock switch DTC functions. void f_90CC (); //Latch clutch switch DTC functions. void f_90CD (); //Latch clutch switch DTC functions. void f_90CE (); //Latch clutch switch DTC functions. void f_90CF (); //Latch clutch switch DTC functions. void f_92D6_11_FL (); //E-Latch function for DTC symptom 11 for Front Left Latch. void f_92D6_12_FL (); //E-Latch function for DTC symptom 12 for Front Left Latch.


96

void f_92D6_11_FR (); //E-Latch function for DTC symptom 11 for Front Right Latch. void f_92D6_12_FR (); //E-Latch function for DTC symptom 12 for Front Right Latch. void f_92D6_11_RL (); //E-Latch function for DTC symptom 11 for Left RearLatch. void f_92D6_12_RL (); //E-Latch function for DTC symptom 12 for Left Rear Latch. void f_92D6_11_RR (); //E-Latch function for DTC symptom 11 for Rear Right Latch. void f_92D6_12_RR (); //E-Latch function for DTC symptom 12 for Rear Right Latch. void f_elatch (); //E-Latch DTC functions. void f_92D5_16 (); //Door Handles function for DTC symptom 16. void f_C010_88_LO (); //MS CAN BUS DTC functions. void f_C010_88_HI (); //MS CAN BUS DTC functions. void f_exe_all_rfa (); //Execute All RFA DTC 's void f_exe_all_rfr (); //Execute All RFR DTC 's void f_exe_all_antennas (); //Execute All Antennas DTC 's void f_exe_all_unlocksw (); //Execute All Unlock Switch DTC 's void f_exe_all_locksw (); //Execute All Lock Switch DTC 's void f_exe_all_latch (); //Execute All latch clutch DTC 's void f_exe_all_elatch (); //Execute All elatch DTC 's void f_exe_all_canbus (); //Execute All CAN bus DTC 's int f_Repeat_Not_Exe_all(); //The function allows to repeat or go to main menu. void f_ulock_sw_15 (); //Unlock Switch symptom 15 functions void f_sw_23 (); //Lock-Unlock Switch symptom 23 functions. void f_Restore_failure (); //At the end of evry test reminds to remove the failure and send 14 ff ff ff void f_antenna_dtcs (); //void f_antenna_dtcs (char* pin1,char* pin2,char* ant_num,char* ant_dtc) void f_timer45 (); //45 seconds counter. Timer required for Lock-Unlock stock on DTCS void f_timer6 (); //Allows 6 seconds in order to wait till SKNF message is not displayed in the cluster void f_timer12 (); //Allows 12 seconds until 31 01 02 02 is requesting information to the system int f_Repeat_or_Not ( int ); //When the test is done, asks for repeat or return to the menu void f_check_system (); //Request to read system info by Service 0x22 //------------------------------------------------- ------------------ // GLOBAL VARIABLES //------------------------------------------------- ------------------ int button_log; / / Variable to control the logging function. int index_submenu; //State control variable on Sub Menus. char ind_f_arg = i_INICIO; // State control variable on Main Menu. char datos[30]; // String that contains de message to be dsiplayed on the Menus. int i_submenu_old= 1; //Variables to handle the repeat tests function. int i_submenu_new; //Variables to handle the repeat tests function. char switch_side[50]; //Lock Unlock Switches parametres and identifiers. char switch_hand[50]; //Lock Unlock Switches parametres and identifiers. char sw_box_p1[50]; //Lock Unlock Switches parametres and identifiers.


97

char sw_box_p2[50]; //Lock Unlock Switches parametres and identifiers. char attempts = 6; //Lock Unlock Switches parametres and identifiers. int x; //Lock Unlock Switches parametres and identifiers. char sw_box_short[50]; //Latch Motors parametres and identifiers. char symptom[3]; //Latch Motors parametres and identifiers. char pin1[10]; //Antenna parameters and identifiers. char pin2[10]; //Antenna parameters and identifiers. char ant_pos[32]; //Antenna parameters and identifiers. char ant_dtc[5]; //Antenna parameters and identifiers. BOOL f_append= FALSE; //Looging funtion constants char pathname[256]; //Looging funtion constants const char caption[256]= "Logging Menu" ; //Looging funtion constants const char default_ext[32]= "*.txt" ; //Looging funtion constants int filter_index=1; //Looging funtion constants const char sz_filters[256]= "Text files(*.txt)|*.txt" ; //Looging funtion constants //Diagnostic Sessions BYTE ExitExtendedSesion[2]={0x10,0x01}; //Extended Session BYTE ExtendedSesion[2]={0x10,0x03}; //Default Session //Reset ECU BYTE Reset[2]={0x11,0x01}; //Service 11 01. //Routine Control. Service 0x31. BYTE W_8006[4]={0x31,0x01,0x80,0x06}; //Check all antennas Routine.31 01 80 06 BYTE R_8006[4]={0x31,0x03,0x80,0x06}; // Read Antenna check routine results.31 03 80 06 BYTE W_ODST[4]={0x31,0x01,0x02,0x02}; //Write On Demand Self Test Routine. 31 01 02 02 BYTE R_ODST[4]={0x31,0x03,0x02,0x02}; //Read On Demand Self Test Routine. 31 03 02 02 //DTC Services. BYTE ClearRFAdtcs[4]={0x14,0xFF,0xFF,0xFF}; //Clear DTCS memory. 14 ff ff ff BYTE ReadRFAdtcs[3]={0x19,0x02,0xAF}; // Read DTCs. 19 02 20 //Read data by identifier. Service 0x22. BYTE R_A113[3] = {0x22, 0xA1,0x13}; //Return all switched status in a bit-wise format. BYTE R_E103[3] = {0x22, 0xE1,0x03}; //Invalid car configuration parameters. BYTE R_EE35[3] = {0x22, 0xEE,0x35}; //Customer passive entry configuration. BYTE R_EE36[3] = {0x22, 0xEE,0x36}; //Write entry configuration. BYTE R_EE39[3] = {0x22, 0xEE,0x39}; //Applicaton configuration. BYTE R_EE3E[3] = {0x22, 0xEE,0x3E}; //RF frequency. BYTE R_F0E8[3] = {0x22, 0xF0,0xE8}; //RFR Software version. BYTE R_F108[3] = {0x22, 0xF1,0x08}; //Signal configuration PN. BYTE R_F111[3] = {0x22, 0xF1,0x11}; //ECU core assembly number. BYTE R_F113[3] = {0x22, 0xF1,0x13}; //ECU delivery assembly number. BYTE R_F124[3] = {0x22, 0xF1,0x24}; //Calibration file PN. BYTE R_F129[3] = {0x22, 0xF1,0x29}; //RFR Hadware variant. BYTE R_F180[3] = {0x22, 0xF1,0x80}; //PBL PN. BYTE R_F188[3] = {0x22, 0xF1,0x88}; //Software PN. BYTE R_F190[3] = {0x22, 0xF1,0x90}; //VIN number. BYTE R_FD03[3] = {0x22, 0xFD,0x03}; //Software Version. BYTE R_FD16[3] = {0x22, 0xFD,0x16}; //PE/PEPS indiaction. BYTE R_FD35[3] = {0x22, 0xFD,0x35}; //Read Calibration file version.


98

//------------------------------------------------- ------------ // MAIN //------------------------------------------------- ------------ int main() { EDG_set_auto_tp(1); //Activar Tester Present do { switch (ind_f_arg){ case i_INICIO: //Estado INICIO --> ind_f_arg = 0 { f_inicio (); } break ; case i_MAIN_M: //Estado i_MAIN_M --> ind_f_arg = 13 { f_main_m(); } break ; case i_RFA_M: //Estado i_RFA_M --> ind_f_arg = 1 { f_rfa_m(); } break ; case i_RFR_M: //Estado i_RFR_M --> ind_f_arg = 2 { f_rfr_m(); } break ; case i_ANTENNAS_M: //Estado i_ANTENNAS_M --> ind_f_arg = 3 { f_antennas_m(); } break ; case i_UNLOCK_SW_M: //Estado i_UNLOCK_SW_M --> ind_f_arg = 4 { f_unlock_sw_m(); } break ; case i_LOCK_SW_M: //Estado i_LOCK_SW_M --> ind_f_arg = 5 { f_lock_sw_m(); } break ; case i_LATCH_CLUTCH_M: //Estado i_LATCH_CLUTCH_M --> ind_f_arg = 6 { f_latch_clutch_m(); } break ; case i_E_LATCH_M: //Estado i_E_LATCH_M --> ind_f_arg = 7 { f_e_latch_m(); } break ;


99

case i_DOOR_HANDLE_M: //Estado i_DOOR_HANDLE_M --> ind_f_arg = 8 { f_door_handle_m(); } break ; case i_CAN_BUS_M: //Estado i_CAN_BUS_M --> ind_f_arg = 9 { f_can_bus_m(); } break ; case i_RETURN_INICIO: //Estado i_RETURN_INICIO --> ind_f_arg = 10 { f_return_inicio(); } break ; case i_EXIT_M: //Estado i_EXIT_M --> ind_f_arg = 11 { f_exit_m(); } break ; default : { } break ; } } while (ind_f_arg!= i_BYE_BYE); //Estado i_BYE_BYE --> ind_f_arg = 12 return 0; } //------------------------------------------------- -------------------- // SUB MENU FUNCTIONS //------------------------------------------------- -------------------- void f_inicio() { EDG_select_device( "RFA" ); EDG_set_target_address(0x731); EDG_set_security_interface( "L32210MY_RFA_SECURE-03" ); do { EDG_info_box( "INFO" , "/[Yes],[No]/Save the tests in a logfile?" ); EDG_delay(1500); button_log = EDG_info_box(NULL, "/?/" ); EDG_info_box(NULL,NULL); } while (button_log == 0); //Button_variant, to choose between PS or PEPS. if (button_log == 1) { EDG_file_save_dialog(pathname,caption,default_ext, &filter_index,sz_filters); //Open logging dialog to start looging. EDG_open_logfile(pathname,f_append); EDG_enable_logging(1); //Once the directory has been selected this function will start the log. }


100

else if (button_log == 2) { EDG_info_box( "INFO" , "No logfile will be saved." ); //mensaje para saber que ha entrado aqui. EDG_delay(2500); EDG_info_box(NULL,NULL); } f_check_system (); //Gets some details about the system configuration. ind_f_arg = i_MAIN_M; //Returns to Main Menu } void f_main_m() { EDG_input_query_box( "MAIN MENU" , "Choose one of the options below entering the number:\n\n1.-RFA\n2.-RFR\n3.-An tennas\n4.-Unlock Switches (PEPS only)\n5.-Lock Switches (PEPS only)\ n6.-Latch Clutches (PEPS only)\n7.-E-Latches\n8.-Door handles (PEPS on ly)\n9.-CAN bus\n10.-Return\n11.-Exit\n" ,datos); EDG_display_string(datos); ind_f_arg = atoi (datos); } void f_rfa_m () { char d_rfa[30]; EDG_input_query_box( "1.RFA MENU" , "Choose one of the options below entering the number:\n\n1.-Return MAIN MENU\n2.-Exe cute all\n3.-DTC 90A9\n4.-DTC C300\n5.-DTC F000\n6.-DTC F002\n7.-DTC E100\n8.-DTC E101\n9.-DTC 902B: DTC Not supported.\n" ,d_rfa); EDG_display_string(d_rfa); index_submenu = atoi (d_rfa); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M; //Return to MAIN MENU } break ; case 2: { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_rfa(); } break ; case 3: { if (EDG_yesno_box( "RFA & PKey test to be executed:\n\n1- 90A9 00: Less than 2 Passive Keys programmed.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90A9 ();


101

index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 4: { if (EDG_yesno_box( "RFA Software test to be executed:\n\n1- C300 00: NM state NMExpulsion is reached.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_C300 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 5: { if (EDG_yesno_box( "RFA Module tests to be executed:\n\n1- F000 49: DTC Not supported.\n\n2- F 000 95: Wrong Module Installed.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_F000 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 6: { if (EDG_yesno_box( "RFA & VIN test to be executed:\n\n1- F002 81: Invalid VIN Number.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_F002 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 7: {


102

if (EDG_yesno_box( "RFA & RF configuration test to be executed:\n\n1- E100 00: LF calibration file missing or wrong.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_E100 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 8: { if (EDG_yesno_box( "RFA & vehicle configuration test to be executed:\n\n1- E101 00: I nvalid configuration parameters received.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_E101 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_rfr_m () { char d_rfr[30]; EDG_input_query_box( "2.RFR MENU" , "Choose one of the options below entering the number:\n\n1.-Return MAIN MENU\n2.-Exe cute all\n3.-DTC E01F\n4.-DTC 92EA: DTC not supported.\n" ,d_rfr); EDG_display_string(d_rfr); index_submenu = atoi (d_rfr); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M;

} break ; case 2: { EDG_info_box( "INFO" , "EXECUTE ALL" );


103

EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_rfr(); } break ; case 3: { if (EDG_yesno_box( "RFR tests to be executed:\n\n1- E01F 00: K-Line bus short to GND.\n 2- E01F 31: No comms with RFR.\n3- E01F 95: Wrong RFR frequency detected .\n\n\nContinue?" ) == (EDG_MB_YES)) { f_E01F (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_antennas_m () { char d_antennas[30]; // Para ser mostrada en ANTENNA MENU. EDG_input_query_box( "3.ANTENNA MENU", "Choose one of the options below entering the number:\n\n1.-Return MAIN MENU\n 2.-Execute all\n3.-DTC 90C6\n4.-DTC 90C7\n5.-DTC 90C8\n6.-DTC 90C9\n7. -DTC 90CA\n8.-DTC 90CB\n9.-DTC 9335\n10.-DTC 9336\n11.-DTC 9337\n12.- DTC 933D\n" ,d_antennas); EDG_display_string(d_antennas); index_submenu = atoi (d_antennas); do{ switch (index_submenu){ case 1: //Estado INICIO --> ind_f_arg = 0 { ind_f_arg = i_MAIN_M; } break ; case 2: //Estado INICIO --> ind_f_arg = 0 { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_antennas(); }


104

break ; case 3: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 4 tests to be executed:\n\n1- 90C6 11: Short to GND or wires shor ted.\n2- 90C6 12: Short to battery.\n3- 90C6 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90C6 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 4: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 3 tests to be executed:\n\n1- 90C7 11: Short to GND or wires shor ted.\n2- 90C7 12: Short to battery.\n3- 90C7 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90C7 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 5: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 2 tests to be executed:\n\n1- 90C8 11: Short to GND or wires shor ted.\n2- 90C8 12: Short to battery.\n3- 90C8 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90C8 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 6: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 1 tests to be executed:\n\n1- 90C9 11: Short to GND or wires shor ted.\n2- 90C9 12:


105

Short to battery.\n3- 90C9 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90C9 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 7: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 6 tests to be executed:\n\n1- 90CA 11: Short to GND or wires shor ted.\n2- 90CA 12: Short to battery.\n3- 90CA 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90CA (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 8: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 8 tests to be executed:\n\n1- 90CB 11: Short to GND or wires shor ted.\n2- 90CB 12: Short to battery.\n3- 90CB 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90CB (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 9: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 10 tests to be executed:\n\n1- 9335 11: Short to GND or wires shor ted.\n2- 9335 12: Short to battery.\n3- 9335 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_9335 (); index_submenu = f_Repeat_or_Not(index_submenu); }


106

else { index_submenu =1; } } break ; case 10: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 5 tests to be executed:\n\n1- 9336 11: Short to GND or wires shor ted.\n2- 9336 12: Short to battery.\n3- 9336 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_9336 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 11: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 7 tests to be executed:\n\n1- 9337 11: Short to GND or wires shor ted.\n2- 9337 12: Short to battery.\n3- 9337 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_9337 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 12: //Estado INICIO --> ind_f_arg = 0 { if (EDG_yesno_box( "Antenna 9 tests to be executed:\n\n1- 933D 11: Short to GND or wires shor ted.\n2- 933D 12: Short to battery.\n3- 933D 13: Open circuit.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_933D (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ;


107

default : { } break ; } } while (index_submenu!= 1); //Estado i_BYE_BYE --> ind_f_arg = 12 } void f_unlock_sw_m () { char d_unlock_sw[30]; // Para ser mostrada en ANTENNA MENU. EDG_input_query_box( "4.UNLOCK SW MENU", "Choose one of the options below entering the number:\n\n1.-Return MAIN MENU\n 2.-Execute all\n3.-DTC 90C1\n4.-DTC 90C2\n5.-DTC 90C3\n6.-DTC 90C4\n7. -DTC 90C5\n8.-DTC 9334\n" ,d_unlock_sw); EDG_display_string(d_unlock_sw); index_submenu = atoi (d_unlock_sw); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M; } break ; case 2: { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_unlocksw(); } break ; case 3: { if (EDG_yesno_box( "LF Unlock Switch tests to be executed:\n\n1- 90C1 15: Switch stuck open.\n 2- 90C1 23: Switch stuck On.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90C1 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 4: { if (EDG_yesno_box( "LR Unlock Switch tests to be executed:\n\n1- 90C2 15: Switch stuck open.\n 2- 90C2 23: Switch stuck On.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90C2 ();


108

index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 5: { if (EDG_yesno_box( "RF Unlock Switch tests to be executed:\n\n1- 90C3 15: Switch stuck open.\n 2- 90C3 23: Switch stuck On.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90C3 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 6: { if (EDG_yesno_box( "RR Unlock Switch tests to be executed:\n\n1- 90C4 15: Switch stuck open.\n 2- 90C4 23: Switch stuck On.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90C4 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 7: { if (EDG_yesno_box( "TRUNK Unlock Switch test to be executed:\n\n1- 90C5 23: Switch stuck On.\n\n \nContinue?" ) == (EDG_MB_YES)) { f_90C5 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 8: {


109

if (EDG_yesno_box( "Tailgate glass release unlock Switch test to be executed:\n\n1- 9334 23: S witch stuck On.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_9334 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_lock_sw_m () { char d_lock_sw[30]; EDG_input_query_box( "5.LOCK SW MENU" , "Choose one of the options below entering the number:\n\n1.-Return MAIN MENU\n 2.-Execute all\n3.-DTC 90D1\n4.-DTC 90D2\n5.-DTC 90D3\n6.-DTC 90D4\n7. -DTC 5017\n" ,d_lock_sw); EDG_display_string(d_lock_sw); index_submenu = atoi (d_lock_sw); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M; } break ; case 2: { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_locksw(); } break ; case 3: { if (EDG_yesno_box( "LF Lock Switch test to be executed:\n\n1- 90D1 23: Switch stuck On.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90D1 (); index_submenu = f_Repeat_or_Not(index_submenu); } else {


110

index_submenu =1; } } break ; case 4: { if (EDG_yesno_box( "LR Lock Switch test to be executed:\n\n1- 90D2 23: Switch stuck On.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90D2 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 5: { if (EDG_yesno_box( "RF Lock Switch test to be executed:\n\n1- 90D3 23: Switch stuck On.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90D3 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 6: { if (EDG_yesno_box( "RR Lock Switch test to be executed:\n\n1- 90D4 23: Switch stuck On.\n\n\nC ontinue?" ) == (EDG_MB_YES)) { f_90D4 (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 7: { if (EDG_yesno_box( "Boot/Trunk primary Lock Switch test to be executed:\n\n1- 5017 23: Switch s tuck On.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_5017 (); index_submenu = f_Repeat_or_Not(index_submenu);


111

} else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_latch_clutch_m () { char d_latch_clutch[30]; / / Para ser mostrada en ANTENNA MENU. EDG_input_query_box( "6.LATCH CLUTCH MENU" , "Choose one of the options below entering the number:\n\n1.-Return MAI N MENU\n2.-Execute all\n3.-DTC 90CC\n4.-DTC 90CD\n5.-DTC 90CE\n6.-DTC 90CF\n" ,d_latch_clutch); EDG_display_string(d_latch_clutch); index_submenu = atoi (d_latch_clutch); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M } break ; case 2: { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_latch (); } break ; case 3: { if (EDG_yesno_box( "FL Latch Clutch Switch test to be executed:\n\n1- 90CC 23: Switch stuck On .\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90CC (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 4: {


112

if (EDG_yesno_box( "RL Latch Clutch Switch test to be executed:\n\n1- 90CD 23: Switch stuck On .\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90CD (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 5: { if (EDG_yesno_box( "FR Latch Clutch Switch test to be executed:\n\n1- 90CE 23: Switch stuck On .\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90CE (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 6: { if (EDG_yesno_box( "RR Latch Clutch Switch test to be executed:\n\n1- 90CF 23: Switch stuck On .\n\n\nContinue?" ) == (EDG_MB_YES)) { f_90CF (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_e_latch_m () { char d_e_latch[30]; // Para ser mostrada en ANTENNA MENU. EDG_input_query_box( "7.E-LATCH MENU" , "Choose one of the options below entering the number:\n\n1.-Return MAIN MENU\n 2.-Execute all\n3.-


113

DTC 92D6 FL\n4.-DTC 92D6 FR\n5.-DTC 92D6 RL\n6.-DTC 92D6 RR\n" ,d_e_latch); EDG_display_string(d_e_latch); index_submenu = atoi (d_e_latch); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M; } break ; case 2: { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_elatch(); } break ; case 3: { if (EDG_yesno_box( "Front Left E-Latch Relay tests:\n\n\n1- 92D6 11: Short to ground.\n2- 92D6 1 2: Short to battery.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_92D6_11_FL (); f_92D6_12_FL (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 4: { if (EDG_yesno_box( "Front Right E-Latch Relay tests:\n\n\n1- 92D6 11: Short to ground.\n2- 92D6 12: Short to battery.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_92D6_11_FR (); f_92D6_12_FR (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 5: { if (EDG_yesno_box( "Rear Left E-Latch Relay tests:\n\n\n1- 92D6 11: Short to ground.\n2- 92D6 1 2: Short to battery.\n\n\nContinue?" ) == (EDG_MB_YES)) {


114

f_92D6_11_RL (); f_92D6_12_RL (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; case 6: { if (EDG_yesno_box( "Rear Right E-Latch Relay tests:\n\n\n1- 92D6 11: Short to ground.\n2- 92D6 1 2: Short to battery.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_92D6_11_RR (); f_92D6_12_RR (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_door_handle_m () { char d_door_handle[30]; EDG_input_query_box( "8.DOOR HANDLE MENU", "Choose one of the options below entering the number:\n\n1.-Return MAI N MENU\n2.-DTC 92D5 \n" ,d_door_handle); EDG_display_string(d_door_handle); index_submenu = atoi (d_door_handle); do{ switch (index_submenu){ case 1: { ind_f_arg = i_MAIN_M; } break ; case 2: { if (EDG_yesno_box( "Door Handle test:\n\n\n1- 92D5 16: Handle supply more than 3V b elow VBAT.\n\n\nContinue?" ) == (EDG_MB_YES)) { f_92D5_16 ();


115

index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); } void f_can_bus_m () { char d_bus[30]; EDG_input_query_box( "9.CAN BUS MENU" , "Choose one of the options below entering the number:\n\n1.Return to MAIN MENU \n2.-Execute all\n3.-DTC C010 88 LO\n4.-DTC C010 88 HI\n" ,d_bus); EDG_display_string(d_bus); index_submenu = atoi (d_bus); do{ switch (index_submenu){ case 1: //Estado INICIO --> ind_f_arg = 0 { ind_f_arg = i_MAIN_M; } break ; case 2: //Estado INICIO --> ind_f_arg = 0 { EDG_info_box( "INFO" , "EXECUTE ALL" ); EDG_delay(2000); EDG_info_box(NULL,NULL); f_exe_all_canbus(); } break ; case 3: { if (EDG_yesno_box( "MS CAN bus tests:\n\n\n1- C010 88: MS LOW Short to Battery.\n\ n\nContinue?" ) == (EDG_MB_YES)) { f_C010_88_LO (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ;


116

case 4: { if (EDG_yesno_box( "MS CAN bus tests:\n\n\n2- C010 88: MS HI short to ground.\n\n\ nContinue?" ) == (EDG_MB_YES)) { f_C010_88_HI (); index_submenu = f_Repeat_or_Not(index_submenu); } else { index_submenu =1; } } break ; default : { } break ; } } while (index_submenu!= 1); //Estado i_BYE_BYE --> ind_f_arg = 12 } void f_return_inicio () { EDG_info_box( "INFO" , "10.APPLICATION RESTART..." ); EDG_delay(2000); ind_f_arg = i_INICIO; } void f_exit_m () { EDG_set_auto_tp(0); //Tester Present stops. EDG_enable_logging(0); //Log stops. EDG_info_box( "INFO" , "CLOSING APPLICATION..." ); EDG_delay(2000); ind_f_arg = i_BYE_BYE; } //------------------------------------------------- --------------------- // RFA DTC FUNCTIONS: Symptom 00 / Symptom 49 / Sym ptom 81 / Symptom 95 //------------------------------------------------- --------------------- void f_90A9 () { EDG_info_box( "INFO" , "90A9_00 NOT SUPPORTED ON THIS VERSION" ); EDG_delay(4000); EDG_info_box(NULL,NULL); } void f_C300 () { EDG_set_auto_tp(0); // Tester Present if (EDG_yesno_box( "1.-Disconnect the RFA and plug an old version modu le & software\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@C300R");


117

f_Read_DTCs (); EDG_display_string( "@C300C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "RFA SOFTWARE DTC SYMPTOM 00 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); // Tester Present } void f_E100 () { EDG_set_auto_tp(0); // Tester Present if (EDG_yesno_box( "1.-Disconnect the RFA and plug one using a diferen t calibration file\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@E100R"); f_Read_DTCs (); EDG_display_string( "@E100C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "RF Configuration DTC SYMPTOM 00 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); // Tester Present } void f_E101 () { EDG_set_auto_tp(0); // Tester Present if (EDG_yesno_box( "1.-Disconnect the RFA and plug one using a diferen t calibration file\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@E101R"); f_Read_DTCs (); EDG_display_string( "@E101C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "Vehicle configuration DTC SYMPTOM 00 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); // Tester Present } void f_F002 ()


118

{ EDG_set_auto_tp(0); //Desactivar Tester Present if (EDG_yesno_box( "1.-Disconnect the RFA and plug a replacement.\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@F002R"); f_Read_DTCs (); EDG_display_string( "@F002C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "IRFA ID DTC SYMPTOM 81 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); // Tester Present } void f_F000 () { EDG_set_auto_tp(0); // Tester Present if (EDG_yesno_box( "1.-Disconnect the RFA version 3 connectors and replace it with a 2 connector ECU\n\n\n...Continue? " )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@F000R"); f_Read_DTCs (); EDG_display_string( "@F000R"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "RFA Module DTC SYMPTOM 95 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); //Activar Tester Present } //------------------------------------------------- -------------------- // RFR DTC FUNCTIONS: Symptom 00 / Symptom 31 / Sym ptom 96 //------------------------------------------------- -------------------- void f_E01F () { f_rfr_00 (); f_rfr_31 (); f_rfr_95 (); } void f_rfr_00 () { int button_continue2=0; if (EDG_yesno_box( "1.-Unlock the vehicle\n\n2.-Short K-LINE to GND on Breakoutbox\n\n3.-Place the key inside the car\n\n4 .-Press Start/Stop


119

button once\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { f_timer6 (); do{ EDG_info_box( "INFO" , "/[YES],[NO]/Press Start/Stop button again. Continue?" ); EDG_delay(2000); //Without this delay, the instruction is repeated too quickly and the user has no time to press the button. EDG_info_box(NULL,NULL); button_continue2 = EDG_info_box(NULL, "/?/" ); } while (button_continue2==0); EDG_display_string( "@E01F00R"); f_Read_DTCs (); EDG_display_string( "@E01F00C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "RFR DTC SYMPTOM 00 has been omited." ); EDG_delay(3000); EDG_info_box(NULL,NULL); } } void f_rfr_31 () { if (EDG_yesno_box( "1.-K-LINE Open circuit on Breakoutbox\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@E01F31odstW" ); EDG_send_binary(W_ODST, 4); f_timer12(); EDG_display_string( "@E01F31odstR" ); EDG_send_binary(R_ODST, 4); EDG_display_string( "@E01F31R"); f_Read_DTCs (); EDG_display_string( "@E01F31C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "RFR DTC SYMPTOM 31 has been omited." ); EDG_delay(3000); EDG_info_box(NULL,NULL); } } void f_rfr_95 () { if (EDG_yesno_box( "1.-K-LINE Open circuit on Breakoutbox\n\n2.-Select the wrong RFR frequency\n\n3.-Plug the posit ive lid to BATT SUPP\n\n4.-Plug the negative lid to GND\n\n5.-Plug the K-LINE lid to K-LINE ECU extrem\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { f_Reset (); EDG_display_string( "@E01F95R"); f_Read_DTCs ();


120

EDG_display_string( "@E01F95C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "RFR DTC SYMPTOM 95 has been omited." ); EDG_delay(3000); EDG_info_box(NULL,NULL); } } //------------------------------------------------- --------------------- // ANTENNA DTC FUNCTIONS: Symptom 11 / Symptom 12 / Symptom 13 //------------------------------------------------- --------------------- void f_90C6 () { char pin1[10]= "ANT4(+)" ; char pin2[10]= "ANT4(-)" ; char ant_pos[32]= "Exterior trunk" ; char ant_dtc[5]= "90C6" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_90C7 () { char pin1[10]= "ANT3(+)" ; char pin2[10]= "ANT3(-)" ; char ant_pos[32]= "Interior trunk" ; char ant_dtc[5]= "90C7" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_90C8 () { char pin1[10]= "ANT2(+)" ; char pin2[10]= "ANT2(-)" ; char ant_pos[32]= "Interior center" ; char ant_dtc[5]= "90C8" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_90C9 () { char pin1[10]= "ANT1(+)" ; char pin2[10]= "ANT1(-)" ; char ant_pos[32]= "Interior front" ; char ant_dtc[5]= "90C9" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_90CA () { char pin1[10]= "ANT6(+)" ; char pin2[10]= "ANT6(-)" ; char ant_pos[32]= "Left rear door handle" ; char ant_dtc[5]= "90CA" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc);


121

} void f_90CB () { char pin1[10]= "ANT8(+)" ; char pin2[10]= "ANT8(-)" ; char ant_pos[32]= "Right rear door handle" ; char ant_dtc[5]= "90CB" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_9335 () { char pin1[10]= "ANT10(+)" ; char pin2[10]= "ANT10(-)" ; char ant_pos[32]= "Front triangulation/Load Space" ; char ant_dtc[5]= "9335" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_9336 () { char pin1[10]= "ANT5(+)" ; char pin2[10]= "ANT5(-)" ; char ant_pos[32]= "Left front door handle" ; char ant_dtc[5]= "9336" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_9337 () { char pin1[10]= "ANT7(+)" ; char pin2[10]= "ANT7(-)" ; char ant_pos[32]= "Right front door handle" ; char ant_dtc[5]= "9337" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_933D () { char pin1[8]= "ANT9(+)" ; char pin2[8]= "ANT9(-)" ; char ant_pos[32]= "Load space/Interior boot" ; char ant_dtc[5]= "933D" ; f_antenna_dtcs (&pin1, &pin2, &ant_pos, &ant_dtc); } void f_antenna_dtcs ( char * pin1, char * pin2, char * ant_pos, char * ant_dtc) { char ant_sms[256]; sprintf (ant_sms, "Please,open circuit at %s and %s.\n\n%s antenna DT C %s 13 will be set.\n\n\n...Continue?" ,pin1,pin2,ant_pos,ant_dtc); if (EDG_yesno_box(ant_sms)==(EDG_MB_YES)) { sprintf (ant_sms, "@oc%s%s%s",pin1,pin2,ant_dtc); //Helps to recognise set the label to be used by the VB Macro.


122

EDG_display_string(ant_sms); f_ODST (ant_sms); f_Restore_failure (); } else //If test is skiped, continues with the next one. If it is the last test, returns to menu. { sprintf (ant_sms, "%s antenna DTC %s SYMPTOM 13 has been omited." ,ant_pos,ant_dtc); EDG_info_box( "INFO" ,ant_sms); EDG_delay(3000); EDG_info_box(NULL,NULL); } sprintf (ant_sms, "Please,short %s to GND.\n\n%s antenna DTC %s 11 wi ll be set.\n\n\n...Continue?" ,pin1,ant_pos,ant_dtc); if (EDG_yesno_box(ant_sms)==(EDG_MB_YES)) { sprintf (ant_sms, "@sg%s%s",pin1,ant_dtc); f_ODST (ant_sms); f_Restore_failure (); } else { sprintf (ant_sms, "%s antenna DTC %s SYMPTOM 11 has been omited." ,ant_pos,ant_dtc); EDG_info_box( "INFO" ,ant_sms); EDG_delay(3000); EDG_info_box(NULL,NULL); } sprintf (ant_sms, "Please,short %s to GND.\n\n%s antenna DTC %s 11 wi ll be set.\n\n\n...Continue?" ,pin2,ant_pos,ant_dtc); if (EDG_yesno_box(ant_sms)==(EDG_MB_YES)) { sprintf (ant_sms, "@sg%s%s",pin2,ant_dtc); f_ODST (ant_sms); f_Restore_failure (); } else { sprintf (ant_sms, "%s antenna DTC %s SYMPTOM 11 has been omited." ,ant_pos,ant_dtc); EDG_info_box( "INFO" ,ant_sms); EDG_delay(3000); EDG_info_box(NULL,NULL); } sprintf (ant_sms, "Please,short %s to %s.\n\n%s antenna DTC %s 11 wil l be set.\n\n\n...Continue?" ,pin1,pin2,ant_pos,ant_dtc); if (EDG_yesno_box(ant_sms)==(EDG_MB_YES)) { sprintf (ant_sms, "@sw%s%s",pin1,pin2,ant_dtc); f_ODST (ant_sms); f_Restore_failure (); } else { sprintf (ant_sms, "%s antenna DTC %s SYMPTOM 11 has been omited." ,ant_pos,ant_dtc); EDG_info_box( "INFO" ,ant_sms);


123

EDG_delay(3000); EDG_info_box(NULL,NULL); } sprintf (ant_sms, "Please,short %s to BATT SUPP.\n\n%s antenna DTC %s 12 will be set.\n\n\n...Continue?" ,pin1,ant_pos,ant_dtc); if (EDG_yesno_box(ant_sms)==(EDG_MB_YES)) { sprintf (ant_sms, "@sb%s%s",pin1,ant_dtc); f_ODST (ant_sms); f_Restore_failure (); } else { sprintf (ant_sms, "%s antenna DTC %s SYMPTOM 12 has been omited." ,ant_pos,ant_dtc); EDG_info_box( "INFO" ,ant_sms); EDG_delay(3000); EDG_info_box(NULL,NULL); } sprintf (ant_sms, "Please,short %s to BATT SUPP.\n\n%s antenna DTC %s 12 will be set.\n\n\n...Continue?" ,pin2,ant_pos,ant_dtc); if (EDG_yesno_box(ant_sms)==(EDG_MB_YES)) { sprintf (ant_sms, "@sb%s%s",pin2,ant_dtc); f_ODST (ant_sms); f_Restore_failure (); } else { sprintf (ant_sms, "%s antenna DTC %s SYMPTOM 12 has been omited." ,ant_pos,ant_dtc); EDG_info_box( "INFO" ,ant_sms); EDG_delay(3000); EDG_info_box(NULL,NULL); } } //------------------------------------------------- --------------------- // UNLOCK SWITCH DTC FUNCTIONS: Symptom 15 / Sympto m 23 //------------------------------------------------- --------------------- void f_90C1 () { char switch_side[50]= "left" ; char switch_hand[50]= "front" ; char sw_box_p1[50]= "FL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "ULOCK"; //Second description parameter on the Breakoutbox. f_ulock_sw_15 (&switch_side,&switch_hand,x,attempts ,&sw_box_p1); f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90C2 () { char switch_side[50]= "left" ; char switch_hand[50]= "rear" ; char sw_box_p1[50]= "RL" ; //First description parameter on the Breakoutbox.


124

char sw_box_p2[50]= "ULOCK"; //Second description parameter on the Breakoutbox. f_ulock_sw_15 (&switch_side,&switch_hand,x,attempts ,&sw_box_p1); f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90C3 () { char switch_side[50]= "right" ; char switch_hand[50]= "front" ; char sw_box_p1[50]= "FR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "ULOCK"; //Second description parameter on the Breakoutbox. f_ulock_sw_15 (&switch_side,&switch_hand,x,attempts ,&sw_box_p1); f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90C4 () { char switch_side[50]= "right" ; char switch_hand[50]= "rear" ; char sw_box_p1[50]= "RR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "ULOCK"; //Second description parameter on the Breakoutbox. f_ulock_sw_15 (&switch_side,&switch_hand,x,attempts ,&sw_box_p1); f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90C5 () { char sw_box_p1[50]= "BOOT"; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "REL" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_9334 () { char sw_box_p1[50]= "BT GLS" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "REL" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } //------------------------------------------------- --------------------------- // LOCK SWITCH DTC FUNCTIONS: Symptom 23 //------------------------------------------------- --------------------------- void f_90D1 () { char sw_box_p1[50]= "FL" ; //First description parameter on the Breakoutbox.


125

char sw_box_p2[50]= "LOCK" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90D2 () { char sw_box_p1[50]= "RL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "LOCK" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90D3 () { char sw_box_p1[50]= "FR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "LOCK" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90D4 () { char sw_box_p1[50]= "RR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "LOCK" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_5017 () { char sw_box_p1[50]= "BOOT"; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "LCK" ; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } //------------------------------------------------- --------------------- // LATCH CLUTCH SWITCH DTC FUNCTIONS: Symptom 23 //------------------------------------------------- --------------------- void f_90CC () { char sw_box_p1[50]= "FL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "CLUTCH"; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90CD () { char sw_box_p1[50]= "RL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "CLUTCH"; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2);


126

} void f_90CE () { char sw_box_p1[50]= "FR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "CLUTCH"; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } void f_90CF () { char sw_box_p1[50]= "RR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "CLUTCH"; //Second description parameter on the Breakoutbox. f_sw_23 (&sw_box_p1,&sw_box_p2); } //------------------------------------------------- --------------------- // E-LATCH DTC FUNCTIONS: Symptom 11 //------------------------------------------------- --------------------- void f_92D6_11_FL () { char sw_box_p1[50]= "FL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(+)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "GND"; char symptom[3]= "11" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_92D6_11_FR () { char sw_box_p1[50]= "FR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(+)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "GND"; char symptom[3]= "11" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_92D6_11_RL () { char sw_box_p1[50]= "RL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(+)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "GND"; char symptom[3]= "11" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_92D6_11_RR () { char sw_box_p1[50]= "RR" ; //First description parameter on the Breakoutbox.


127

char sw_box_p2[50]= "MTR(+)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "GND"; char symptom[3]= "11" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } //------------------------------------------------- --------------------- // E-LATCH DTC FUNCTIONS: Symptom 12 //------------------------------------------------- --------------------- void f_92D6_12_FL () { char sw_box_p1[50]= "FL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(-)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "BATT SUPP" ; char symptom[3]= "12" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_92D6_12_FR () { char sw_box_p1[50]= "FR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(-)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "BATT SUPP" ; char symptom[3]= "12" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_92D6_12_RL () { char sw_box_p1[50]= "RL" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(-)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "BATT SUPP" ; char symptom[3]= "12" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_92D6_12_RR () { char sw_box_p1[50]= "RR" ; //First description parameter on the Breakoutbox. char sw_box_p2[50]= "MTR(-)" ; //Second description parameter on the Breakoutbox. char sw_box_short[50]= "BATT SUPP" ; char symptom[3]= "12" ; f_elatch (&sw_box_p1,&sw_box_p2,&sw_box_short,&symp tom); } void f_elatch ( char * sw_box_p1, char * sw_box_p2, char * sw_box_short, char * symptom) { char sw_sms6[256]; char sw_sms7[256];


128

sprintf (sw_sms6, "Short %s %s pin to %s.\n\n...Continue?" ,sw_box_p1,sw_box_p2,sw_box_short); if (EDG_yesno_box(sw_sms6)==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { f_Read_DTCs (); f_Restore_failure (); } else { sprintf (sw_sms7, "%s %s E-LATCH DTC SYMPTOM %s has been omited." ,sw_box_p1,sw_box_p2,symptom); EDG_info_box( "INFO" ,sw_sms7); //If the test is skiped, continues with the next one. If it is the last test , returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } } //------------------------------------------------- --------------------- // DOOR HANDLE DTC FUNCTIONS: Symptom 16 //------------------------------------------------- --------------------- void f_92D5_16() { if (EDG_yesno_box( "1.-Reduce the Door Handle Power Supply voltage at least 3V in reference with ECU Power Supply\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@92D5R"); f_Read_DTCs (); EDG_display_string( "@92D5C"); f_Restore_failure (); } else { EDG_info_box( "INFO" , "DOOR HANDLE DTC SYMPTOM 16 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } } //------------------------------------------------- --------------------- // MS CAN BUS DTC FUNCTIONS: Symptom 88 //------------------------------------------------- --------------------- void f_C010_88_LO () { EDG_set_auto_tp(0); //Desactivar Tester Present if (EDG_yesno_box( "1.-Short CAN LOW to Battery\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@C01088LOR"); f_Read_DTCs (); EDG_display_string( "@C01088LOC"); f_Restore_failure (); } else {


129

EDG_info_box( "INFO" , "CAN BUS DTC SYMPTOM 88 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); //Activar Tester Present } void f_C010_88_HI () //Pendiente de implementar { EDG_set_auto_tp(0); //Desactivar Tester Present if (EDG_yesno_box( "1.-Short CAN HI to GND\n\n\n...Continue?" )==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { EDG_display_string( "@C01088HIR" ); f_Read_DTCs (); EDG_display_string( "@C01088HIR" ); f_Restore_failure (); } else { EDG_info_box( "INFO" , "CAN BUS DTC SYMPTOM 88 has been omited." ); //If the test is skiped, continues with the next on e. If it is the last test, returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } EDG_set_auto_tp(1); //Activar Tester Present } //------------------------------------------------- --------------------- // DIAGNOSTICS SERVICES & ROUTINES //------------------------------------------------- --------------------- void f_Read_DTCs () { EDG_info_box( "DTC's READ" , "Reading RFA DTC's in process" ); //Restore sytem EDG_delay(1500); EDG_info_box(NULL,NULL); EDG_send_binary(ReadRFAdtcs, 3); } void f_Clean_DTCs () { EDG_info_box( "DTC's CLEAN" , "Cleaning RFA DTC's in process" ); //Restore sytem EDG_delay(1500); EDG_info_box(NULL,NULL); EDG_send_binary(ClearRFAdtcs, 4); } void f_W_8006 () { EDG_info_box( "ROUTINE 8006" , "Antenna check in process" ); EDG_send_binary(W_8006, 4); EDG_delay(1000); EDG_info_box(NULL,NULL); } void f_R_8006 ()


130

{ EDG_info_box( "ROUTINE 8006" , "Antenna check in process" ); EDG_send_binary(R_8006, 4); EDG_delay(1000); EDG_info_box(NULL,NULL); } void f_ODST ( const char * label) { char label_aux [256]; EDG_send_binary(ExtendedSesion, 2); //Enter into Extended Sesion mode in order to use ODST Routine. strcpy (label_aux, label); strcat (label_aux, "W" ); EDG_display_string(label_aux); EDG_send_binary(W_ODST, 4); f_timer12(); strcpy (label_aux, label); strcat (label_aux, "R" ); EDG_display_string(label_aux); EDG_send_binary(R_ODST, 4); strcpy (label_aux, label); strcat (label_aux, "C" ); EDG_display_string(label_aux); EDG_send_binary(ExitExtendedSesion, 2); //Turn barck to the Normal Sesion. } void f_Reset () { EDG_send_binary(Reset, 2); EDG_info_box( "RFA Reset" , "RFA Module reset done" ); //Reset the module. EDG_delay(3000); EDG_info_box(NULL,NULL); } void f_check_system () { int i; int button_variant; int temp; char system_sms[320]; BYTE ret[25],F190_ret[23],F111_ret[23],F188_ret[23],F180 _ret[23],F108_ret[23],F124_ret[23],F0E8_ret[23],F129_ret[23]; EDG_send_binary(ExtendedSesion, 2); //Enter into Extended Sesion mode in order to use ODST Routine. EDG_delay(4000); // Required delay. Challenge between tester/ECU tak e up to 4 seconds. EDG_display_string( "@FD16"); EDG_send_binary(R_FD16, 3); //RFA MODULE PS or PEPS.--> Display information EDG_display_string( "@A113" ); EDG_send_binary(R_A113, 3); //Return all switched status ina bit-wise format.


131

EDG_display_string( "@E103" ); EDG_send_binary(R_E103, 3); //Invalid car configuration parameters. EDG_display_string( "@EE35"); EDG_send_binary(R_EE35, 3); //Customer passive entry configuration. EDG_display_string( "@EE36"); EDG_send_binary(R_EE36, 3); //Write passive entry configuration. EDG_display_string( "@EE39"); EDG_send_binary(R_EE39, 3); //Applicaton configuration. EDG_display_string( "@EE3E"); EDG_send_binary(R_EE3E, 3); //RF frequency. -->Display information. EDG_display_string( "@F113" ); EDG_send_binary(R_F113, 3); //ECU delivery assembly number. EDG_display_string( "@FD03"); EDG_send_binary(R_FD03, 3); //Software Version.--> Display information EDG_display_string( "@F190" ); EDG_send_binary(R_F190, 3); //Id Number.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F190_ret[i]=ret[i+3]; } EDG_display_string( "@F111" ); EDG_send_binary(R_F111, 3); //ECU core assembly number.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F111_ret[i]=ret[i+3]; } EDG_display_string( "@F188" ); EDG_send_binary(R_F188, 3); //SW PN.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F188_ret[i]=ret[i+3]; } EDG_display_string( "@F180" ); EDG_send_binary(R_F180, 3); //Primary Bootloader PN.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F180_ret[i]=ret[i+3]; } EDG_display_string( "@F108" ); EDG_send_binary(R_F108, 3); //Signal Configuration PN.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F108_ret[i]=ret[i+3]; } EDG_display_string( "@F124" ); EDG_send_binary(R_F124, 3); //Calibration file PN.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F124_ret[i]=ret[i+3];


132

} EDG_display_string( "@F0E8"); EDG_send_binary(R_F0E8, 3); //Primary Bootloader PN.--> Display information EDG_get_reply(ret,24, &temp); for (i=0;i<=(MAX-3);i++) { F0E8_ret[i]=ret[i+3]; } EDG_display_string( "@F129" ); EDG_send_binary(R_F129, 3); //Primary Bootloader PN.--> Display information EDG_get_reply(ret,23, &temp); for (i=0;i<=(MAX-3);i++) { F129_ret[i]=ret[i+3]; } EDG_send_binary(ExitExtendedSesion, 2); //Turn barck to the Normal Sesion. sprintf(system_sms, "1.VIN: %s\n\n2.System: %s\n3.RFA HW PN: %s\n\n4.RF A SW PN: %s\n5.PBL PN: %s\n6.SINGAL CONFIG PN: %s\n7. Calibration File PN: %s\n\n8.RFR Frequency: %s\n9.RFR SW version: %s\n" , F190_ret,F111_ret,F188_ret,F180_ret,F108_ret,F124_r et,F0E8_ret,F129_ret); EDG_info_box( "SYSTEM CONFIGURATION",system_sms); EDG_delay(10000); EDG_info_box(NULL,NULL); } //------------------------------------------------- --------------------- // TIMERS //------------------------------------------------- --------------------- void f_timer45 () { int seconds; char timercounter[256]; for (seconds=45;seconds>=1;seconds--) { EDG_delay(1000); sprintf (timercounter, "WAIT till the timer ends!\n\n\n...%d seconds left." ,seconds); EDG_info_box( "TIME COUNTER",timercounter); } } void f_timer6 () { int seconds; char timercounter[256]; for (seconds=6;seconds>=1;seconds--) { EDG_delay(1000); sprintf (timercounter, "WAIT till SKNF is not displayed on the cluster\n\n\n...%d seconds left." ,seconds); EDG_info_box( "TIME COUNTER",timercounter); } } void f_timer12 () { int seconds; char timercounter[256];


133

for (seconds=12;seconds>=1;seconds--) { EDG_delay(1000); sprintf (timercounter, "Executing On Demand Self Test Routine\n\n\n...%d seconds left." ,seconds); EDG_info_box( "TIME COUNTER",timercounter); } } //------------------------------------------------- --------------------- // GENERAL FUNCTIONS //------------------------------------------------- --------------------- int f_Repeat_or_Not ( int index_submenu) //Allows to repeat tests once finished. { int button_continue=0; do{ EDG_info_box( "INFO" , "/[YES],[NO]/Repeat the test?" ); EDG_delay(5000); //Without this delay, the instruction is repeated too quickly and the user has no time to press the button. EDG_info_box(NULL,NULL); button_continue = EDG_info_box(NULL, "/?/" ); } while (button_continue==0); if (button_continue == 2) { index_submenu= 1; } else { } return index_submenu; } void f_Restore_failure () { int accept_button = 0; do{ EDG_info_box( "INFO" , "/[Accept]/Please, remove the failure." ); EDG_delay(2000); //Delay required to in order to see the message. EDG_info_box(NULL,NULL); accept_button = EDG_info_box(NULL, "/?/" ); } while (accept_button==0); EDG_send_binary(ClearRFAdtcs, 4); } void f_ulock_sw_15 ( char * switch_side, char * switch_hand, int x, int attempts, char * sw_box_p1) { char sw_sms1[256]; char sw_sms2[256]; char sw_sms3[256]; char sw_sms4[256];


134

sprintf (sw_sms1, "1.-Lock the vehicle using the key fob.\n\n2.-OPEN CIRCUIT %s ULOCK on the Breakoutbox.\n\n\nContinue the test?" ,sw_box_p1); if (EDG_yesno_box(sw_sms1)==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { for (x=1;x<=(attempts);x++) { sprintf (sw_sms2, "1.-Pull %s %s door handle fully -->Door will be opened.\n2.-Close the door.\n3.-LOCK vehicle again.\n\nThis is attempt number %d/%d.\n\nContinue the test?" ,switch_hand,switch_side,x,attempts); EDG_yesno_box(sw_sms2); //Set the DTC manually using the Breakout box. sprintf (sw_sms3, "@%s%dULOCK15R",sw_box_p1,x); EDG_display_string(sw_sms3); f_Read_DTCs (); //Ensure that the DTC was not set before the 6th action. } sprintf (sw_sms3, "@%sULOCK15C",sw_box_p1); EDG_display_string(sw_sms3); f_Restore_failure (); sprintf (sw_sms3, "@%sULOCK15R",sw_box_p1); EDG_display_string(sw_sms3); f_Read_DTCs (); } else { sprintf (sw_sms4, "%s UNLOCK SWITCH DTC SYMPTOM 15 has been omited." ,sw_box_p1); EDG_info_box( "INFO" ,sw_sms4); //If the test is skiped, continues with the next one. If it is the last test , returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } } void f_sw_23 ( char * sw_box_p1, char * sw_box_p2) { char sw_sms4[256]; char sw_sms5[256]; sprintf (sw_sms4, "Short %s %s pin to GND.\n\n45 seconds timer is goi ng to start...READY?" ,sw_box_p1,sw_box_p2); if (EDG_yesno_box(sw_sms4)==(EDG_MB_YES)) //Set the DTC manually using the Breakout box. { f_timer45 (); sprintf (sw_sms4, "@%s%s23R",sw_box_p1,sw_box_p2); //pendiente EDG_display_string(sw_sms4); //pendiente f_Read_DTCs (); sprintf (sw_sms4, "@%s%s23C",sw_box_p1,sw_box_p2); //pendiente EDG_display_string(sw_sms4); //pendiente f_Restore_failure (); } else { sprintf (sw_sms5, "%s %s SWITCH DTC SYMPTOM 23 has been omited." ,sw_box_p1,sw_box_p2);


135

EDG_info_box( "INFO" ,sw_sms5); //If the test is skiped, continues with the next one. If it is the last test , returns to menu. EDG_delay(3000); EDG_info_box(NULL,NULL); } } //------------------------------------------------- --------------------- // CONTINUED TESTING - STATE FLOW CONTINUE TEST CON TROLLER //------------------------------------------------- --------------------- int f_Repeat_Not_Exe_all ( int i_submenu_new) //FUNCTION NAME: REPEAT CONTROL AFTER THE DTC EXECUTION { int button_continue=0; do{ EDG_info_box( "INFO" , "/[YES],[NO],[EXIT]/Repeat the test?" ); EDG_delay(5000); //Without this delay, the instruction is repeated too quickly and the user has no time to press the button. EDG_info_box(NULL,NULL); button_continue = EDG_info_box(NULL, "/?/" ); } while (button_continue==0); if (button_continue == 2) { i_submenu_new= (i_submenu_old)+1; } if (button_continue == 1) { i_submenu_new= (i_submenu_old); } if (button_continue == 3) { i_submenu_new= 0; } return i_submenu_new; } void f_exe_all_rfr() { do{ switch (i_submenu_old){ case 1: //Estado INICIO --> ind_f_arg = 0 { f_rfr_00(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: //Estado INICIO --> ind_f_arg = 0 { f_rfr_31(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ;


136

case 3: //Estado INICIO --> ind_f_arg = 0 { f_rfr_95(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); //i_submenu_old= 0; Must be another state for reset the variable if not f_rfr_95 will not hav e the repeat option. } break ; case 4: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. { i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 14 index_submenu =1; // Returns to RFR menu, if not control will be lost . i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward. } void f_exe_all_antennas() { do{ switch (i_submenu_old){ case 1: { f_90C6(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: { f_90C7(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 3: { f_90C8(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 4: { f_90C9(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new);


137

} break ; case 5: { f_90CA(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 6: { f_90CB(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 7: { f_9335(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 8: { f_9336(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 9: { f_9337(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 10: { f_933D(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 11: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. { i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 14


138

index_submenu =1; // Returns to Antennas menu, if not control will be lost. i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward. } void f_exe_all_locksw() { do{ switch (i_submenu_old){ case 1: { f_90D1(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: { f_90D2(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 3: { f_90D3(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 4: { f_90D4(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 5: { f_5017(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 6: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. { i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 14


139

index_submenu =1; // Returns to Lock Switch menu, if not control will be lost. i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward. } void f_exe_all_unlocksw() { do{ switch (i_submenu_old){ case 1: { f_90C1(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: { f_90C2(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 3: { f_90C3(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 4: { f_90C4(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 5: { f_90C5(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 6: { f_9334(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 7: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. {


140

i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 14 index_submenu =1; // Returns to Antennas menu, if not control will be lost. i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward. } void f_exe_all_latch() { do{ switch (i_submenu_old){ case 1: { f_90CC(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: { f_90CD(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 3: { f_90CE(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 4: { f_90CF(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 5: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. { i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 14


141

index_submenu =1; // Returns to Antennas menu, if not control will be lost. i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward. } void f_exe_all_elatch() { do{ switch (i_submenu_old){ case 1: { f_92D6_11_FL (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: { f_92D6_11_FR (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 3: { f_92D6_11_RL (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 4: { f_92D6_11_RR (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 5: { f_92D6_12_FL (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 6: { f_92D6_12_FR (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 7: {


142

f_92D6_12_RL (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 8: { f_92D6_12_RR (); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 9: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. { i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 14 index_submenu =1; // Returns to Antennas menu, if not control will be lost. i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward. } void f_exe_all_canbus() { do{ switch (i_submenu_old){ case 1: //Estado INICIO --> ind_f_arg = 0 { f_C010_88_LO(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 2: //Estado INICIO --> ind_f_arg = 0 { f_C010_88_HI(); i_submenu_old = f_Repeat_Not_Exe_all(i_submenu_new); } break ; case 3: //This state allows the previous one to be repeated, if not will not be possible after the first attempt. { i_submenu_old= 0; } break ; } } while (i_submenu_old!= 0); //Estado i_BYE_BYE --> ind_f_arg = 12


143

index_submenu =1; // Returns to CAN bus menu, if not control will be lost. i_submenu_old=1; //If the variable is not restored to "1", after the first run will be always "0" therefore,will exit th e dtcs routine stright forward.

}


144

7.3 Código fuente de la Macro de Visual Basic

Sub GetLogFile() Dim MsgBoxRespon As Integer Dim FileToOpen As Variant 'Selecting File FileToOpen = Application.GetOpenFilename("Log Files (*.txt), *.txt") If FileToOpen = False Then MsgBoxRespon = MsgBox("Retry to select file.", v bRetryCancel, ThisWorkbook.Name) Do While MsgBoxRespon = 4 And FileToOpen = False FileToOpen = Application.GetOpenFilename("Log Files (*.txt), *.txt") If FileToOpen = False Then MsgBoxRespon = MsgBox("Retry to select file.", vbRetryCancel, ThisWorkbook.Name) End If Loop If FileToOpen <> False Then Call Parse_file(FileToOpen, 1) End If Else Call Parse_file(FileToOpen, 1) End If End Sub ---------------------------------------- Sub Parse_file(FileToOpen As Variant, ControlVersio n As Integer) Close 1 Dim sLabel As String, sLabelId As String, sResponse As String, sResponseId, sInput(1 To 366, 1 To 2) As String, sI nputLength As Integer, endResponse As Boolean, labelIdPos As Inte ger, buffer As String sInputLength = 0 endResponse = False Open FileToOpen For Input As #1 Do While Not EOF(1) Input #1, buffer If sResponseId = "@" Then buffer = sResponse End If labelIdPos = InStr(buffer, "@") If labelIdPos <> 0 Then sLabelId = Mid$(sLabel, labelIdPos, 1) sLabel = Mid$(buffer, labelIdPos, Len(buffer)) sInputLength = sInputLength + 1 sInput(sInputLength, 1) = sLabel


145

Do While Not EOF(1) And endResponse = False Input #1, sResponse sResponseId = Mid$(sResponse, 1, 2) If InStr(sResponse, "@") <> 0 Then sInput(sInputLength, 2) = "" endResponse = True ElseIf sResponseId = "50" Then sInput(sInputLength, 2) = sResponse endResponse = True ElseIf sResponseId = "51" Then sInput(sInputLength, 2) = sResponse endResponse = True ElseIf sResponseId = "62" Then sInput(sInputLength, 2) = sResponse endResponse = True ElseIf sResponseId = "71" Then sInput(sInputLength, 2) = sResponse endResponse = True ElseIf sResponseId = "59" Then sInput(sInputLength, 2) = sResponse endResponse = True ElseIf sResponseId = "54" Then sInput(sInputLength, 2) = sResponse endResponse = True ElseIf sResponseId = "7F" Then sInput(sInputLength, 2) = sResponse endResponse = True End If Loop endResponse = False End If Loop Close 1 h = SearchAndWriteCell(sInput, sInputLength) MsgBox "Loaded Succesfully" End Sub ------------------------------------------------- Function SearchAndWriteCell(sInput, sInputLength) Dim sPIDType, sRow, sCol, sColTarget, sRowTarget As String, iRow As Integer Dim Done As Boolean Done = False iRow = 5 'Fila inicial de busqueda sCol = "E" 'Columna de busqueda sColTarget = "M" 'Columna donde se almancenara el resultado Sheets("DTC Protocol&Report").Select 'Activacion de la hoja sRow = sCol + Str(iRow) 'Celda de partida sRowTarget = sColTarget + Str(iRow) 'Celda objetivo sRow = Replace(sRow, " ", "") sRowTarget = Replace(sRowTarget, " ", "")


146

For j = 1 To 366 For i = 1 To sInputLength If Range(sRow).Value = sInput(i, 1) Then Range(sRowTarget).Value = sInput(i, 2) 'Convert to ASC End If Next i sRow = sCol + Str(iRow + j) 'Celda de partida sRowTarget = sColTarget + Str(iRow + j) 'Celda objetivo sRow = Replace(sRow, " ", "") sRowTarget = Replace(sRowTarget, " ", "") Next j iRow = 11 'Fila inicial de busqueda sCol = "A" 'Columna de busqueda sColTarget = "G" 'Columna donde se almancenara el resultado Sheets("System Information").Select 'Activacion de la hoja sRow = sCol + Str(iRow) 'Celda de partida sRowTarget = sColTarget + Str(iRow) 'Celda objetivo sRow = Replace(sRow, " ", "") sRowTarget = Replace(sRowTarget, " ", "") For j = 1 To 23 For i = 1 To sInputLength If Range(sRow).Value = sInput(i, 1) Then If j = 3 Or j = 17 Then Range(sRowTarget).Value = Mid$(sInput(i, 2), 10, Len(sInput(i, 2))) Else Range(sRowTarget).Value = ConvertToASC(Mi d$(sInput(i, 2), 10, Len(sInput(i, 2)))) 'Convert to ASC Mid$(buffer, labelIdPos,Len(buffer) ) End If End If Next i sRow = sCol + Str(iRow + j) 'Celda de partida sRowTarget = sColTarget + Str(iRow + j) 'Celda objetivo sRow = Replace(sRow, " ", "") sRowTarget = Replace(sRowTarget, " ", "") Next j iRow = 11 'Fila inicial de busqueda sCol = "I" 'Columna de busqueda sColTarget = "N" 'Columna donde se almancenara el resultado Sheets("System Information").Select 'Activacion de la hoja sRow = sCol + Str(iRow) 'Celda de partida sRowTarget = sColTarget + Str(iRow) 'Celda objetivo sRow = Replace(sRow, " ", "") sRowTarget = Replace(sRowTarget, " ", "") For j = 1 To 9 For i = 1 To sInputLength


147

If Range(sRow).Value = sInput(i, 1) Then Range(sRowTarget).Value = Mid$(sInput(i, 2) , 10, Len(sInput(i, 2))) 'Convert to ASC End If Next i sRow = sCol + Str(iRow + j) 'Celda de partida sRowTarget = sColTarget + Str(iRow + j) 'Celda objetivo sRow = Replace(sRow, " ", "") sRowTarget = Replace(sRowTarget, " ", "") Next j End Function ---------------------------------------------- Public Function ConvertToASC(sStringInHex As String ) As String Dim sAux As String Dim sResult As String Dim iAux As Long Dim Done As Boolean Dim Counter As Integer sStringInHex = Replace(sStringInHex, " ", "") Counter = Len(sStringInHex) / 2 Done = False Do While Done = False sChar = Mid$(sStringInHex, 2 * Counter - 1, 2) If Counter = 1 Then Done = True Else Counter = Counter - 1 End If Select Case sChar Case "20" sAux = "?" Case "21" sAux = "!" Case "22" sAux = """" Case "23" sAux = "#" Case "24" sAux = "$" Case "25" sAux = "%" Case "26" sAux = "&" Case "27" sAux = "'" Case "28" sAux = "(" Case "29" sAux = ")" Case "2A" sAux = "*" Case "2B"


148

sAux = "+" Case "2C" sAux = "," Case "2D" sAux = "-" Case "2E" sAux = "." Case "2F" sAux = "/" Case "30" sAux = "0" Case "31" sAux = "1" Case "32" sAux = "2" Case "33" sAux = "3" Case "34" sAux = "4" Case "35" sAux = "5" Case "36" sAux = "6" Case "37" sAux = "7" Case "38" sAux = "8" Case "39" sAux = "9" Case "3A" sAux = ":" Case "3B" sAux = ";" Case "3C" sAux = "<" Case "3D" sAux = "=" Case "3E" sAux = ">" Case "3F" sAux = "?" Case "40" sAux = "@" Case "41" sAux = "A" Case "42" sAux = "B" Case "43" sAux = "C" Case "44" sAux = "D" Case "45" sAux = "E" Case "46" sAux = "F" Case "47" sAux = "G" Case "48" sAux = "H" Case "49" sAux = "I"


149

Case "4A" sAux = "J" Case "4B" sAux = "K" Case "4C" sAux = "L" Case "4D" sAux = "M" Case "4E" sAux = "N" Case "4F" sAux = "O" Case "50" sAux = "P" Case "51" sAux = "Q" Case "52" sAux = "R" Case "53" sAux = "S" Case "54" sAux = "T" Case "55" sAux = "U" Case "56" sAux = "V" Case "57" sAux = "W" Case "58" sAux = "X" Case "59" sAux = "Y" Case "5A" sAux = "Z" Case "5B" sAux = "[" Case "5C" sAux = "\" Case "5D" sAux = "]" Case "5E" sAux = "^" Case "5F" sAux = "_" Case "60" sAux = "`" Case "61" sAux = "a" Case "62" sAux = "b" Case "63" sAux = "c" Case "64" sAux = "d" Case "65" sAux = "e" Case "66" sAux = "f" Case "67" sAux = "g" Case "68"


150

sAux = "h" Case "69" sAux = "i" Case "6A" sAux = "j" Case "6B" sAux = "k" Case "6C" sAux = "l" Case "6D" sAux = "m" Case "6E" sAux = "n" Case "6F" sAux = "o" Case "70" sAux = "p" Case "71" sAux = "q" Case "72" sAux = "r" Case "73" sAux = "s" Case "74" sAux = "t" Case "75" sAux = "u" Case "76" sAux = "v" Case "77" sAux = "w" Case "78" sAux = "x" Case "79" sAux = "y" Case "7A" sAux = "z" Case "7B" sAux = "{" Case "7C" sAux = "|" Case "7D" sAux = "}" Case "7E" sAux = "~" End Select sResult = sAux + sResult Loop ConvertToASC = sResult End Function

herramienta de ayuda semi automatizada de validación de...

Documents