Diagnóstico de Fallas en Tarjetas de Comunicación para Multiplexado de Redes Automotrices-Edición Única

(1)

Monterrey, Nuevo León a 5 de Diciembre del 2007.

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY P R E S E N T E ,

Por medio de la presente hago constar que soy autor y titular de la obra denominada "DIAGNOSTICO DE FALLAS EN TARJETAS DE COMUNICACIÓN PARA MULTEPLEXADO DE REDES AUTOMOTRICES.", en los sucesivo LA OBRA, en virtud de lo cual autorizo a el Instituto Tecnológico y de Estudios Superiores de Monterrey (EL INSTITUTO) para que efectúe la divulgación, publicación, comunicación pública, distribución, distribución pública, distribución electrónica y reproducción, así como la digitalización de la misma, con fines académicos o propios al objeto de EL INSTITUTO.

El Instituto se compromete a respetar en todo momento mi autoría y a otorgarme el crédito correspondiente en todas las actividades mencionadas anteriormente de la obra.

De la misma manera, manifiesto que el contenido académico, literario, la edición y en general cualquier parte de LA OBRA son de mi entera responsabilidad, por lo que deslindo a EL INSTITUTO por cualquier violación a los derechos de autor y/o propiedad intelectual y/o cualquier responsabilidad relacionada con la OBRA que cometa el suscrito frente a terceros.

(2)

Diagnóstico de Fallas en Tarjetas de Comunicación para

Multiplexado de Redes Automotrices-Edición Única

Title Diagnóstico de Fallas en Tarjetas de Comunicación para Multiplexado de Redes Automotrices-Edición Única

Authors Jorge Javier Treviño Contreras

Affiliation ITESM-Campus Monterrey

Issue Date 2007-12-01

Item type Tesis

Rights Open Access

Downloaded 19-Jan-2017 10:11:03

(3)

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

SUPERIORES DE MONTERREY

CAMPUS MONTERREY

PROGRAMA DE GRADUADOS EN MECATRÓNICA Y

TECNOLOGÍAS DE INFORMACIÓN

DIAGNOSTICO DE FALLAS EN TARJETAS DE COMUNICACIÓN PARA MULTIPLEXADO DE REDES AUTOMOTRICES.

TESIS

PRESENTADA COMO REQUISITO PARCIAL PARA OBTENER EL GRADO ACADEMICO DE:

MAESTRO EN CIENCIAS CON ESPECIALIDAD EN AUTOMATIZACIÓN

POR:

JORGE JAVIER TREVIÑO CONTRERAS

(4)

INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY

DIVISIÓN DE MECATRÓNICA Y TECNOLOGÍAS INFORMACIÓN

PROGRAMA DE GRA DUADOS EN MECATRÓNICA Y TECNOLOGÍAS DE INFORMACIÓN

Los miembros del comité de tesis recomendamos que la presente tesis del Ing. Jorge Javier Treviño Contreras sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias con especialidad en Automatización.

Comité de tesis:

______________________________

Ricardo Ramírez, Ph D. Asesor

______________________________

Artemio Aguilar, M.S.

Sinodal

______________________________

Federico Guedea, Ph D. Sinodal

_________________________________________

Dr. Graciano Dieck Assad

(5)

DIAGNOSTICO DE FALLAS EN TARJETAS DE COMUNICACIÓN PARA MULTIPLEXADO DE REDES AUTOMOTRICES.

POR:

JORGE JAVIER TREVIÑO CONTRERAS

TESIS

Presentada al Programa de Graduados en Mecatrónica y

Tecnologías de Información

Este trabajo es requisito parcial para obtener el grado de Maestro

en Ciencias con especialidad en Automatización.

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS

SUPERIORES DE MONTERREY

(6)

Resumen.

La tecnología de redes de comunicación ha cubierto varias áreas de aplicaciones como son las militares, informática, económicas e industriales. Actualmente también son usadas en nuestros hogares, áreas de trabajo, restaurantes y hasta en nuestro transporte diario. Es por esto que es importante que los dispositivos dentro de estas redes funcionen de manera adecuada, para que su funcionamiento no afecte al desempeño de la red de comunicación o peor aún, que suceda algo no esperado y peligroso en el sistema de control.

Para el diagnostico del funcionamiento de un dispositivo dentro de una red de comunicación es necesario utilizar herramientas de monitoreo. Una de estas herramientas son las tarjetas de comunicación, que por medio de una aplicación y un servidor, pueden ejecutar distintas pruebas o secuencias de monitoreo que nos ayudaran a obtener resultados comparativos sobre alguna situación especifica. El funcionamiento adecuado de estas herramientas es muy importante.

Al desarrollar una aplicación que nos sirva como herramienta de diagnostico para las tarjetas de comunicación, podremos asegurar que al monitorear las redes automotrices por medio de la tarjeta, estamos obteniendo lecturas seguras y correctas para un diagnóstico de dispositivos o bien para la aplicación de algún método de control dentro de la red de comunicación. La metodología para esta aplicación se desarrollará en este documento.

(7)

Dedicatoria.

A mis padres, Sonia y Francisco, que han estado a mi lado todo el camino apoyándome, impulsándome y guiándome, dándome la mejor herencia que un hijo puede pedir, una educación de calidad y una formación humana para la vida. Mostrándome la mejor manera de crecer y formar mi propio destino.

A mis hermanos, Amparo y Daniel, que me han apoyado en momentos difíciles y me han aconsejado de manera desinteresada para no cometer errores y salir adelante. Que me han mantenido feliz, exigiéndome paciencia, comprensión y alegría en nuestra relación.

(8)

Agradecimientos.

A mis padres, Sonia y Francisco, hermanos, novia y familiares que me apoyaron durante el desarrollo de mis estudios. Gracias por darme fuerza y aliento para concluir con éxito esta meta planeada. Por todas las muestras de amor que siempre tienen conmigo y por el gran ejemplo que han sido para mí.

Al Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Monterrey, que a través de sus instalaciones y facilidades, han sido una gran herramienta para mis estudios y para mi formación profesional.

A IDTEC Automatización, S.A. de C.V., que con el apoyo económico y personal de Alfredo Báez, Francisco Salazar y Gerardo Vallejo, pude concluir satisfactoriamente mis estudios. Les agradezco las enseñanzas y la experiencia que obtuve al trabajar a lado de ustedes antes y durante mis estudios de posgrado.

(9)

Listado de figuras.

No. Figura Descripción de figura Página

1.1 Esquema de sistema de pruebas. 12

2.1 Modelo ISO para red CAN. 18

2.2 Transmisión de mensajes. 19

2.3 Arbitraje de mensajes en el bus. 22

2.4 Formato de estructura de datos (DATA FRAME). 24

3.1 Configuración de conexiones. 38

3.2 Diagrama: Pruebas de configuración. 44

3.3 Diagrama: Pruebas de comunicación. 46

3.4 Diagrama: Pruebas de velocidad de transmisión. 48

3.5 Diagrama: Pruebas de carga de red. 50

3.6 Pantalla de bienvenida. 51

3.7 Pantalla de introducción. 52

3.8 Pantalla de instrucciones de conexión. 53

3.9 Pantalla de pruebas. 54

3.10 Diagrama: Aplicación de pruebas. 56

4.1 Diagrama eléctrico de nodo CAN 59

5.1 Resultado de caso 0. 66

5.2 Resultado de caso 1. 67

5.3 Resultado de caso 2 69

(10)

Listado de tablas.

No. Tabla Descripción de tabla Página

3.1 Descripción de tabla de pruebas. 40

3.2 Descripción de tabla de pruebas. 41

3.3 Pruebas de configuración. 42

3.4 Pruebas de comunicación. 45

3.5 Pruebas de cambio de velocidad. 47

3.6 Pruebas de carga de red. 49

4.1 Descripción de tabla de respuestas. 61

4.2 Respuesta a pruebas de comunicación. 62

4.3 Respuesta a pruebas de cambio de velocidad. 63

(11)

6

Índice.

Resumen... 1

Dedicatoria... 2

Agradecimientos. ... 3

Listado de figuras... 4

Listado de tablas. ... 5

Índice... 6

Capítulo 1 Introducción. ... 8

Antecedentes y motivación. ... 8

Definición del problema. ... 9

Hipótesis. ... 10

Objetivo... 10

Herramientas y conocimientos previos... 10

Alcances y limitaciones. ... 11

Trabajos previos... 12

Capítulo 2 Protocolo de comunicación CAN. ... 16

Introducción. ... 16

Especificaciones CAN y sus antecedentes... 17

Propiedades y conceptos básicos para redes CAN. ... 20

Transmisión de mensaje... 24

Validación de mensaje. ... 24

Manejo de errores y fallas... 25

Velocidad de transmisión de bits. ... 27

Características del medio y su actividad... 30

Capítulo 3 Diagnóstico de fallas... 32

Metodología de procedimientos de pruebas. ... 32

Definición de DUT. ... 36

Librerías de funciones utilizadas en protocolo CAN... 36

Procedimiento para evaluación de librería CAN. ... 39

Tabla de pruebas. ... 41

Pruebas de diagnóstico... 42

Secuencia de pruebas de diagnóstico... 51

Capítulo 4 Dispositivo espía... 57

Diseño de dispositivo CAN (nodo)... 57

Diagramas eléctricos... 58

(12)

7 Capítulo 5

Resultados y casos evaluados. ... 65

Caso 0... 65

Caso 1... 67

Caso 2... 68

Caso 3... 70

Tabla de resultados y solución de problemas. ... 71

Ejemplo de reporte final... 72

Capítulo 6 Conclusiones y trabajos futuros... 73

Conclusiones... 73

Trabajos futuros. ... 74

(13)

Capítulo 1. Introducción.

Capítulo 1

Introducción.

Antecedentes y motivación.

Las redes de comunicación industrial han experimentado un gran crecimiento a través de los años, debido a la complejidad de los sistemas de automatización en distintas áreas (control industrial, industria automotriz, industria aeronáutica y aeroespacial, industria marina, domótica, etc.) [1].

Hoy en día la cantidad de dispositivos electrónicos en un automóvil es muy grande (sensores, actuadores, interruptores, indicadores, etc.) a comparación con los vehículos de los años 90’s, esto hace que el cableado y la detección de fallas en dispositivos sean mas complejas de realizar [2]. El multiplexado de redes de dispositivos simplifica el cableado y

permite el análisis más sencillo de todos los procesos dentro del vehículo; procesos que van desde el desempeño del motor, los frenos, la dirección y la transmisión, hasta el control automático de funciones de monitoreo, confort e iluminación. El objetivo principal del multiplexado de redes es el de simplificar la comunicación entre sistemas aumentando la calidad, el desempeño, el confort y la seguridad en el vehículo.

Para monitorear los sistemas y controladores, ó diagnosticar fallas en este tipo de redes, es necesario tener una conexión dentro de la red hacia una PC, en la cual podamos utilizar o desarrollar software. Esta conexión se logra mediante tarjetas o módulos, sirviendo de enlace entre la computadora y las distintas redes dentro de un automóvil.

Un ejemplo de tarjetas o módulos de comunicación son los equipos EXXOTEST®

que es una marca de ANNECY Electronique. Los equipos EXXOTEST® son materiales

educativos eficientes y sofisticados para escuelas o centros de entrenamiento, en donde se

(14)

preparan profesionistas y técnicos con los conocimientos necesarios para laborar en el área automotriz.

Dentro de la gama de estos equipos, tenemos distintas tarjetas de comunicación, que varían en su forma de conexión con la PC y/o las distintas redes que pueden manejar cada tarjeta al mismo tiempo, dependiendo si la función es de monitoreo, accionamiento o diagnóstico.

Definición del problema.

Es muy necesario e importante determinar el buen funcionamiento de los dispositivos de comunicación, asegurando un funcionamiento óptimo y sin fallas, para poder tener buen manejo de información confiable entre el usuario y la red a monitorear, actuar y/o diagnosticar.

Actualmente no se cuenta en el mercado con algún módulo de pruebas que nos pueda determinar de manera automática alguna falla importante dentro de alguna de las tarjetas de comunicación o que nos arroje algún reporte de pruebas realizadas.

Una referencia sobre pruebas específicas, que determinen un buen funcionamiento o alguna falla dentro de un dispositivo dentro de una red, puede ser la que se realiza a los dispositivos dentro de la red de Sistemas de Tránsito Orientados en Media (MOST) [5].

Estas pruebas (Core Compliance Test Specification V2.00) ayudan a estandarizar la comunicación entre los dispositivos, y a la vez diagnostican fallas de programación o de funcionamiento.

.

Basándose en estas pruebas pudiéramos entender y generar diferentes procedimientos que determinen el funcionamiento adecuado de algún dispositivo dentro la red a analizar (por ejemplo: CAN). Para ellos se requiere entender completamente el protocolo de comunicación de la tarjeta, los requerimientos del medio de transmisión y las tramas de información correcta enviada a la red.

(15)

Hipótesis.

Es posible diseñar y desarrollar una herramienta útil y necesaria que determine el funcionamiento correcto de una tarjeta de comunicación para redes multiplexadas, pudiendo garantizar, hasta cierto nivel, que la información que pasa a través de la tarjeta es correcta y verdadera. Logrando con esto, poder monitorear los sistemas y dispositivos dentro de las redes y/o diagnosticar fallas. Garantizando que la tarjeta de comunicación es una herramienta confiable para su uso.

Objetivo.

Diseñar un procedimiento para el desarrollo de pruebas que determinen el buen funcionamiento de una tarjeta de comunicación funcionando en una red CAN. Aplicando estas pruebas a distintas tarjetas de comunicación existentes en el laboratorio de Autotrónica.

La aplicación debe de identificar el tipo de tarjeta conectada, aplicar prueba de configuración dentro de la red CAN que cada tarjeta contiene, pruebas de comunicación, pruebas anchos de banda de transmisión y asegurando la conexión correcta al medio de transmisión. Todas las pruebas deben de realizarse de la manera más automática posible.

Herramientas y conocimientos previos.

Para el desarrollo de un dispositivo de diagnóstico de fallas como el propuesto, es necesario utilizar herramientas de programación y de diseño. A continuación, se enlista cada una de las herramientas y conocimientos necesarios.

• Conocimientos sobre especificación CAN 2.0 A ó B. • Conocimientos de programación C.

• Conocimiento de programación de microcontroladores. • Manejo de herramientas de programación.

• Programación básica en LabWindows de NI y MPLAB de Microchip.

(16)

Alcances y limitaciones.

El alcance de esta tesis es el de diseñar y desarrollar algunas pruebas y el equipo necesarios para diagnosticar fallas y problemas en las tarjetas de comunicación disponibles dentro del laboratorio de Autotrónica. Las tarjetas disponibles son:

- USB – MUX 4C2L

- USB – MUX DIAG

La única tarjeta en la que se va a trabajar es USB – MUX 4C2L. Dentro de estas tarjetas tenemos distintas redes multiplexadas:

- CAN HS: Controller Area Network de alta velocidad. - CAN LS: Controller Area Network de baja velocidad.

- CAN LSFT: Controller Area Network de baja velocidad tolerante a fallas. - CAN SW: Controller Area Network single wire.

- LIN: Local Interconnect Network

- ISO9141: On – board Diagnostic Protocol

La única red en la que se va a trabajar en este documento es CAN HS, por cuestiones de profundizar y ejemplificar los métodos de diagnóstico determinados.

Se generarán pruebas para las instrucciones incluidas en las librerías del DLL-MUX-CAN basadas en el documento de MOST Core Compilance Testing que contiene las pruebas realizadas a la librería de funciones de los dispositivos MOST.

Se desarrollará un dispositivo CAN que ayudará a la realización de las pruebas en caso de ser necesario. Basándose en instrucciones y procedimientos de diseño de dispositivos CAN.

El sistema final esperado se muestra en la figura 1.1. Este sistema se compone de una PC que contendrá el software necesario para que el usuario pueda realizar y monitorear las pruebas de diagnóstico en la tarjeta de comunicación por medio de una conexión USB. La tarjeta de comunicación estará conectada en su otro extremo a una red CAN

(17)

[image:17.612.124.504.145.288.2]

local, compuesta por la tarjeta de comunicación y un dispositivo CAN que nos servirá de asistente en algunas de las pruebas a realizar.

Figura. 1.1. Esquema de Sistema de pruebas.

Trabajos previos.

Algunos de los trabajos mas comunes que se realizan en el área de pruebas en tarjetas y dispositivos electrónicos son los de calidad, funcionamiento, mantenimiento o reparación. También se realizan pruebas físicas destructivas, de temperatura o eléctricas.

De acuerdo al documento de “Un banco de pruebas e investigación en redes para servicios de nueva generación sobre Redes de próxima generación” [3], la complejidad de

las redes de comunicación de datos actuales necesitan bases de pruebas completas, reales y sofisticadas para verificar y validar la función habilidad de dichas redes. Las bases de pruebas de redes están restringidas a laboratorios y ambientes aislados de escenarios de la vida real.

Adicionalmente, la mayoría de los bancos de pruebas para redes de comunicación actuales, carecen de escalabilidad y flexibilidad necesaria para representar adecuadamente un ambiente real. Antes de adentrarnos en establecer una red de comunicación, existe la necesidad de tener un ambiente de pruebas escalable y suficientemente flexible para trabajar con problemas como: diseño de redes, interoperabilidad entre marcas, resistentes, ínterconectividades de capas multiprotocolos,

(18)

estándares específicos de operación de alguna determinada marca y viabilidad en el diseño de redes para satisfacer los requisitos.

Uno de los trabajos previos analizados es el desarrollo y construcción de sistemas de pruebas basadas en redes [4]. En donde se explica que en estos días, la tecnología de

información se ha convertido en la principal motivación para el desarrollo de la economía, el área militar y aun la vida humana. En cuanto al campo de pruebas, con la gradualmente cercana combinación de pruebas automáticas y la tecnología del Internet, un sistema de pruebas por medio de redes logrará tener un mayor desarrollo y un mayor campo de aplicaciones.

Un sistema de pruebas por medio de redes hace uso de la tecnología de comunicación de redes para lograr compartir información y al mismo tiempo usar la tecnología de auto pruebas para realizar las tareas dentro de cada prueba propuesta. Este tipo de sistemas posee dos características básicas: la red de información entre computadoras y el sistema de pruebas. También se tiene una estructura general que comprende distintos elementos: los resultados de pruebas basadas en la red, los resultados de pruebas a larga distancia basadas en la red, el servicio de la prueba, el almacenamiento de datos y diagnostico de fallas y la red de comunicación.

A continuación se describen cada uno de estos elementos:

• Los resultados de pruebas basadas en la red. Su función principal es el de indicar

la forma en que se establecerán los resultados de las pruebas.

• Los resultados de pruebas a larga distancia basadas en la red. Su función es el de

establecer el destino u origen de la prueba a larga distancia a realizar, determinando el objeto bajo pruebas y estableciendo los resultados de las pruebas.

• El servicio de la prueba. Su función es el de liberar o establecer un agente de

pruebas.

(19)

• El almacenamiento de datos y diagnóstico de fallas. Su función es el de permitir

el acceso a los datos de las pruebas al igual que enviar los datos al sistema en donde se realiza el diagnóstico. El diagnóstico esta basado en funciones o en el trabajo conjunto de expertos.

• La red de comunicación. Aquí se establece el medio y el protocolo que se sigue en

la aplicación, en el establecimiento de pruebas y en la transmisión de datos; de tal manera que sea posible el diagnóstico de resultados.

El objetivo de crear un sistema de pruebas por medio de redes, es el de lograr un control local y de larga distancia de las pruebas en los dispositivos de la red, al mismo tiempo lograr compartir resultados o datos de las pruebas por medio de la red.

Un programa de pruebas se define como: un sistema de programación y de colección de recursos interrelacionados que logran un uso eficiente de la información dentro del sistema de dispositivos, para la realización de distintas pruebas y funciones de monitoreo. Este programa de pruebas puede ser dividido en dos sistemas, sistema de programa y sistema de aplicación. El sistema de programa se refiere a la configuración de un programa para extender la eficiencia de algún dispositivo. El programa de aplicación se refiere al programa usado por los usuarios en orden de resolver algún problema específico en cuanto a la toma de datos, pruebas o control de algún dispositivo.

Los sistemas de pruebas por medio de redes se convirtieron en la nueva dirección del desarrollo de tecnología en pruebas y funciones de monitoreo. Su estructura sistemática, integración de tecnología y métodos de diseño son una nueva dirección para la investigación.

Como nuestra aplicación se basa en determinar el buen funcionamiento de la comunicación entre el dispositivo y la red, analizaremos el método de diagnóstico de fallas aplicado en dispositivos MOST como un acercamiento previo al trabajo de diagnóstico de fallas en dispositivos dentro de redes automotrices.

(20)

Este sistema MOST (Media Oriented Systems Transport) ha sido desarrollado para sistemas de comunicación que necesitan de anchos de banda amplios, por ejemplo: Radio, teléfono, sistemas de audio, CD y control de voz. Esta arquitectura está basada en una topología de red tipo anillo. Para asegurar la buena operación de la red de comunicación bajo cualquier condición, cualquier dispositivo conectado en el anillo debe de cumplir las especificaciones requeridas. El dispositivo de algún fabricante debe de cumplir con los requisitos del sistema en cualquier circunstancia.

Para verificar cualquier comportamiento del dispositivo, este debe pasar diferentes tipos de pruebas que evalúan cualquier función o dato, sin importar el tipo de control o administración del sistema en donde se incluirá.

El objetivo básico de estas pruebas, como ya se mencionó, es el de evaluar el comportamiento del dispositivo mediante sus funciones dentro de las especificaciones MOST diagnosticando el funcionamiento actual del dispositivo bajo prueba (DUT, por sus siglas en inglés).

Esta compilación de pruebas de función interna para dispositivos MOST está basada en la especificación MOST 2V4.[5]

(21)

Capítulo 2. Protocolo de comunicación CAN.

Capítulo 2

Protocolo de comunicación CAN.

Introducción.

CAN ( Controller Area Network ) es un protocolo de comunicación serial el cual maneja eficientemente un control distribuido en tiempo real de muy alto nivel de seguridad. Esto es, que la información dentro de una red CAN es segura, distribuida y rápida. El rango de aplicaciones que normalmente maneja este tipo de red van desde redes de alta velocidad, como en los automóviles, hasta cableado de bajo costo de redes multiplexadas, en sistemas de automatización inteligentes en el hogar o en el mismo automóvil.

El uso de comunicaciones seriales en más y más aplicaciones de control, ha requerido de la estandarización en las asignaciones de identificadores para mensajes dentro de algunas de esas aplicaciones. Estas aplicaciones pueden realizarse utilizando CAN de una manera más cómoda, ya sea con un rango de identificadores estándar o extendido. El objetivo principal de tener estos dos esquemas de identificación es el de permitir al operador o programador tener un rango más amplio y holgado de asignación de identificadores, teniendo esquemas de asignación variables más sencillos.

Este capítulo tiene como objetivo adentrarnos en las especificaciones del protocolo de comunicación CAN, de tal manera que queden totalmente clarificadas para el lector, dándole la capacidad de utilizar el protocolo de manera adecuada en la aplicación a desarrollar. Conocerá los antecedentes de las redes de comunicación en general, la forma en que dividen las diferentes capas que comprenden la estructura del protocolo de comunicación. También ejemplificaremos algunos de los arreglos o topologías de redes de comunicación a utilizar.

(22)

Desarrollaremos los conceptos básicos del protocolo CAN dando algunos ejemplos de aplicaciones en las redes CAN. Ejemplos como la comunicación CAN entre nodos de un automóvil, analizando la información que esta dentro de la red, su origen y su destino, su contenido y su efecto en el funcionamiento final de los sistemas en el coche. El análisis de las especificaciones de la red CAN publicadas por BOSCH [6] nos

ayudara a entender mejor las pruebas que realizaremos en los capítulos subsecuentes.

Especificaciones CAN y sus antecedentes.

La intención del desarrollo de las especificaciones CAN es el de lograr una compatibilidad entre los dos tipos de implementación CAN existentes. Sin embargo, la compatibilidad se logra en distintos aspectos, aspectos de medio o de interpretación de datos.

Para lograr una transparencia en el diseño y una flexibilidad en la implementación, la red CAN se ha sido subdividido en diferentes capas.

• Capa de objetos • Capa de transferencia • Capa física

Las capas de objeto y de transferencia comprenden las funciones y servicios de la capa de enlace de datos descritos en el modelo ISO/OSI [7].

Como menciona Tanenbaum [7] la tarea principal de la capa de enlace de datos,

en el modelo ISO, es el de tomar una transmisión de datos y transformarla en una línea libre de errores indetectables para la capa de red. Esto se logra haciendo que el transmisor de los datos divida en paquetes de datos el mensaje a transmitir, transmitiendo estos datos en secuencia y procesando el dato de confirmación enviado por el receptor.

(23)

Los objetivos principales de la capa de objetos dentro de la red CAN son: el encontrar cual de los mensajes debe ser transmitido, decidir cual mensaje recibido por la capa de transferencia debe ser utilizado y el de proveer una interfase a la capa de aplicación relacionada con el equipo. Existe mucha libertad al definir los objetos que se manejaran dentro de la aplicación.

El enfoque de la capa de transferencia es principalmente el protocolo de transferencia. Dentro de la capa de transferencia se decide si el medio de transferencia esta libre para empezar una nueva transmisión o si hay una recepción actualmente activa.

También algunos de los detalles en los tiempos de transmisión se manejan dentro de esta capa. Dentro de esta capa no existe la libertad de modificación dado a que es parte esencial del protocolo de comunicación.

Capa de objeto

• Localización de mensajes.

• Elección de mensajes para recepción. • Interfase con capa de transferencia.

Capa de transferencia • Arbitraje. • Protocolo.

• Tiempos de transmisión. • Velocidades de transmisión.

Capa física

[image:23.612.178.427.379.701.2]

• Definición del medio.

Figura. 2.1. Modelo ISO para red CAN.

(24)

El enfoque de la capa física es el de transmitir la información entre los diferentes nodos dentro de las propiedades eléctricas del medio. Aunque dentro de una red la capa física debe de ser igual para todos los nodos, existe una libertad de escoger el medio a utilizar en la red implementada.

Para comprender mejor el funcionamiento de estas capas pondremos un ejemplo. Digamos que tenemos que transmitir un mensaje desde un punto A hasta un punto B, este mensaje contiene la información necesaria para que B realice una tarea ó para que A pida información a B para poder realizar una acción.

[image:24.612.119.494.491.652.2]

Tanto en A como en B ó C (ver Figura 2.2) existen las tres capas del protocolo. En el caso de la capa de objetos, en A, actúa en la definición del contenido de mensaje y la información que este contiene, ya sea una petición o una transmisión. En B la capa de objetos actúa como un árbitro al determinar si se recibe la información necesaria o se envía la información pedida. En el punto C, solamente actúa árbitro de recepción. En cualquiera de los tres puntos (A, B ó C) la capa de objeto puede tener cualquiera de las tres acciones, aparte de la acción de lectura ó escritura de información, dependiendo de cómo se requiera que se maneje la información de la red.

Figura. 2.2. Transmisión de mensajes.

(25)

Para el caso de la capa de transferencia, se debe de especificar una velocidad de transmisión específica para los tres puntos, con el fin de evitar errores por pérdida de información o mala identificación de mensaje. También es importante que esta capa determine la disponibilidad del medio para ser utilizado por cualquiera de los tres puntos. Permitiendo un arbitraje definido por prioridades, más adelante explicaremos como sucede esto dentro de la red.

La capa física define el medio por el cual se transmitirán los datos, ya sea por radio frecuencia (RF), algún medio alámbrico o algún medio moderno como puede ser alguna fibra de vidrio o plástica. En el ejemplo el medio son las flechas que conectan a los tres puntos.

Propiedades y conceptos básicos para redes CAN.

La red CAN cuenta con propiedades importantes, que describen las ventajas que se tienen al implementar este tipo de red. Estas propiedades se relacionan más con la capa de objeto que con las capas de transmisión y física.

• Prioridad de mensajes.

• Garantía de tiempos de estado latente. • Configuración flexible.

• Recepción múltiple y sincronización de tiempos. • Consistencia de datos en el sistema.

• Multi - maestro.

• Señalización y detección de errores. • Retransmisión de mensajes con errores.

• Determinación de fallas parciales o completas de los nodos del sistema, desconexión y reactivación de nodos.

(26)

A continuación detallaremos sobre ellas.

La prioridad de mensajes se logra por medio de la asignación de

IDENTIFICADORES a los mensajes que entrarán al medio. Esta información es enviada al medio en forma de MENSAJES, de formato fijo y de diferente pero limitada longitud.

Garantiza tiempos de estado latente mediante la configuración de la velocidad de flujo de información o BIT RATE, que puede ser distinta entre diferentes sistemas, pero sin embargo, en un sistema dado, esta velocidad tiene que ser uniforme y fija.

En una red CAN es posible agregar NODOS sin la necesidad de cambiar la configuración de la red o de los nodos existentes, siempre y cuando se respete la velocidad de información. Así se logra una configuración flexible, ya que la información viaja a través de la red sin importar el destino. Por ejemplo: al enviar un mensaje con la información del estado actual de algún dispositivo, digamos, la velocidad del motor, el tablero del automóvil puede desplegar esta información en su velocímetro, mientras que el volumen del estero del auto es regulado por cuestiones de seguridad. Es posible que la función del estéreo dependiente de la velocidad del motor sea deshabilitada o que el estéreo sea retirado del auto sin tener que afectar la transmisión de los datos de la velocidad actual del motor, ó sin afectar a la información desplegada en el tablero. La cantidad máxima de nodos trabajando sin problemas dentro de una red depende solamente de los retrasos generados en la red o por la carga eléctrica del sistema.

La propiedad de multi-maestro depende del arbitraje de transmisión ya que cualquier nodo puede enviar o modificar un mensaje cuando el medio este disponible para transmitir. El mensaje es enviado de acuerdo a las reglas de arbitraje del protocolo usando los identificadores de los mensajes ya sean mensajes de datos o mensajes de petición remota. La regla de arbitraje utiliza los niveles eléctricos del mensaje, nivel “dominante” (0) y nivel “recesivo” (1).

(27)

En la figura 2.3 se representa el arbitraje entre 3 nodos que desean enviar los datos a la red.

Identifier

S O F

R T R 1

0 9 8 7 6 5 4 3 2 1 0

Control Field

Data Field

Listening only

Node1

Node2

Node3

[image:27.612.115.543.178.359.2]

Bus-level

Figura. 2.3. Arbitraje de mensajes en el bus.

La consistencia de los datos asegura que un mensaje puede ser recibido por todos o ninguno de los nodos dentro de la red CAN. Esto se logra por medio de la recepción múltiple, sincronización de tiempos y el manejo de errores. La recepción multiple y sincronización de tiempo consiste en que mediante el FILTRADO DE MENSAJES se logre que uno o mas nodos de la red puedan leer ciertos mensajes.

La señalización y detección de errores es necesaria para asegurar que la información en el medio es correcta y útil. Existen fuertes medidas de detección de errores y señalización de fallas para apoyar al diseño de cualquier nodo. Para la detección de errores existen: monitoreo, chequeo de redundancia cíclica (CRC), apiñamiento de bits y chequeo de formato de mensaje. Las propiedades más importantes de estos mecanismos son que todos los mensajes globales con error son detectados, al igual que los mensajes locales en cada transmisor.

(28)

Al identificarse un mensaje con error, es marcado por una bandera por cualquiera de los nodos en la red. En este caso el mensaje se retransmite al momento en que el medio esta disponible para transmisión. La cantidad de errores determinará si el nodo transmisor se mantiene activado en la red o se manda a apagar. Para volver a trabajar con el nodo desactivado es necesario realizar una reactivación del nodo.

Ahora veremos algunos de los conceptos básicos en el manejo del protocolo de comunicación CAN. Estos conceptos aclararán algunas de las funciones especiales del protocolo y así mismo nos ayudarán a respaldar y desarrollar algunas de las pruebas de diagnóstico a realizar en la tarjeta de comunicación.

Los conceptos más importantes, de los cuales se desprenden otras definiciones, son:

• Mensajes.

• Transmisión de mensaje. • Validación de mensajes. • Manejo de errores y fallas. • Velocidad de transmisión de bits.

• Características del medio y su actividad.

A continuación detallaremos en cada uno de estos conceptos y en sus definiciones.

El mensaje.

El mensaje se denomina como la información enviada en el medio con formato definido de longitud limitada diferente. Cuando el medio esta libre cualquier unidad conectada puede empezar a transmitir un nuevo mensaje.

Este mensaje lleva la información a todos los nodos o dispositivos dentro de la red, para que sea usada de manera independiente entre nodos. Este uso de información independiente, permite que los mensajes puedan fluir por el medio de manera rápida y controlada. Un ejemplo de mensaje en una red CAN, es el que lleva la información de

(29)

velocidad y revoluciones del motor a los demás dispositivos en la red, generando acciones automáticas. Como puede ser un estado de alarma en el sistema de iluminación por una variación muy brusca en la velocidad del coche.

Transmisión de mensaje.

En cuanto al manejo de la información dentro los sistemas CAN, un nodo CAN no hace uso de la información con referencia a una configuración del sistema o estaciones. Esto tiene diferentes consecuencias importantes. Existe una flexibilidad del

sistema en donde un nodo puede ser agregado a la red CAN sin afectar ni cambiar la configuración de la aplicación o los componentes de cualquier otro nodo.

[image:29.612.178.436.506.661.2]

La transmisión de mensajes se realiza y se controla por cuatro tipos diferentes de estructuras: la estructura de datos (DATA FRAME), que lleva la información del transmisor al receptor; la estructura de datos remotos (REMOTE FRAME), que es el que se envía a través del medio como petición de una estructura de datos, utilizando el mismo IDENTIFICADOR; la estructura de error (ERROR FRAME), enviada por cualquier unidad conectada al medio para indicar un error en el mensaje; y la estructura de sobrecarga (OVERLOAD FRAME) que sirve para generar un retraso extra en el mensaje previo y el subsiguiente.

Figura. 2.4. Formato de estructura de datos (DATA FRAME).

(30)

Las características específicas de cada estructura se pueden consultar en las especificaciones CAN [4], según sea necesario.

Validación de mensaje.

El punto en el que el mensaje es válido para el transmisor y el receptor, es distinto.

Para el transmisor el mensaje es valido si no existe ningún error al momento de transmitir el fin de la estructura o END OF FRAME. Si el mensaje es dañado, la retransmisión se reinicia automáticamente y de acuerdo a la prioridad, para lograr esto el medio debe de estar en espera de nuevos mensajes.

Para el receptor el mensaje es valido si no existe ningún error hasta el último bit recibido del END OF FRAME.

La consistencia de los datos dentro de la red CAN garantiza que un mensaje puede ser aceptado ya sea por todos o por ninguno de los nodos en el sistema. Esta consistencia se define por el manejo de los mensajes o por el manejo de errores de transmisión.

Manejo de errores y fallas.

Existen 5 tipos de error diferentes, que no son mutuamente exclusivos:

• Error de bit: Al momento en que una unidad envía un bit al medio de transmisión también monitorea al mismo medio. Es por esto que un error de este tipo debe de detectarse en ese preciso momento, cuando el bit enviado es diferente al bit monitoreado entonces ser marca el error. A excepción del caso en el que se envíe un bit recesivo durante la transmisión del campo de arbitraje o el campo de

(31)

confirmación, entonces no se marca ningún error aunque se monitoree un bit dominante. También se exceptúa este tipo de error cuando un transmisor envía una bandera de error pasivo (seis bits recesivos de manera consecutiva) y detecta un bit dominante en el medio.

• Error de relleno (STUFF ERROR): Este se detecta al momento en el que el sexto bit consecutivo sea igual a los anteriores y no respete la regla de la codificación de relleno, en donde se indica que se permite la transmisión de 5 bits consecutivos de mismo nivel seguidos de un sexto de nivel complementario. Ver CODIFICACION en [4]

• Error en CRC: La secuencia CRC de un dato transmitido resulta de un cálculo hecho por el transmisor. El receptor hace el mismo cálculo. Si existe una diferencia en los resultados de la secuencia, entonces se marca este tipo de error.

• Error de forma: Este error se marca cuando algún campo de bits, supuestamente de forma fija y determinada, tiene uno o más bits ilegales en el.

• Error de confirmación: Este error se detecta cuando un transmisor no monitorea un bit dominante en el medio durante un bloque de confirmación.

Cuando un mensaje se detecta alterado o erróneo, cualquier nodo puede marcar con una bandera de error al mensaje, a esto se le llama señalización de errores. Estos mensajes son inmediatamente abortados y retransmitidos automáticamente. El tiempo de recuperación, desde la detección del error hasta el inicio del envío del nuevo mensaje, es máximo de 29 tiempos de bit en caso de ya no haber errores en el mensaje.

En el manejo de fallas los nodos CAN pueden detectar desde pequeños disturbios hasta fallas permanentes, tomando la decisión de mantener encendido el nodo o apagarlo.

(32)

Cada unidad puede estar en cualquiera de los siguientes estados:

• Error activo: tiene influencia en el medio y puede enviar banderas de error activo.

• Error pasivo: tiene influencia en el medio, pero al momento de encontrar un error solo puede enviar banderas de error pasivo y debe suspender su transmisión.

• Desconectado del medio de transmisión (bus off): no tiene influencia en el medio y no manda ninguna bandera de error.

Estos estados dependen de dos conteos: conteo de errores en transmisión y conteo

de errores en recepción que cambian según un conjunto de reglas establecidas en la especificación CAN [4]

Velocidad de transmisión de bits.

La velocidad de transmisión de bits se define como el número de bits por segundo transmitidos en la ausencia de resincronización por un transmisor ideal.

NOMINAL BIT TIME = 1 / NOMINAL BIT RATE

La velocidad de transmisión de bits de una red CAN puede ser diferente en diferentes sistemas. Sin embargo, en un sistema específico, la velocidad debe de ser uniforme y fija. Por ejemplo, en una red CAN de 1Mbit/s, todos los nodos deben de transmitir y recibir a 1Mbit/s. Si algún nodo esta configurado a diferente velocidad, este nodo no podrá funcionar con esta red. Esta velocidad es definida por el usuario o programador del sistema mediante el uso de variables dentro de las librerias o modulos de configuración de la red. Con la configuración de estas variables se establece el tiempo nominal de bit.

(33)

El tiempo nominal de bit puede ser dividido en cuatro segmentos de tiempo, estos segmentos son:

• Segmento de sincronización (SYNC_SEG): este segmento es utilizado para

sincronizar a los diferentes nodos en el medio.

• Segmento de tiempo de propagación (PROP_SEG): este segmento se utiliza para compensar el retraso físico dentro de la red. Que es dos veces la suma del tiempo de propagación de la señal por el medio, el retraso del comparador de entrada y el retraso del dispositivo de salida.

• Segmentos de almacén de fase (PHASE_SEG1 y PHASE_SEG2): estos segmentos se usan para compensar los errores de fase. Estos segmentos pueden ser alargados o acortados dependiendo de la resincronización.

Estos segmentos son programados para definir la velocidad de transmisión de cada nodo, teniendo en cuenta que la velocidad dentro de la red CAN debe ser homogénea.

Para entender mejor la forma correcta en la que se puede programar la velocidad de transmisión, desarrollaremos dos ejemplos, para 125 Kbit/s y 1Mbit/s.

Para la programación de la velocidad de transmisión, el caudal se expresa como:

(34)

Capítulo 2. Protocolo de comunicación CAN. BRP wTSEG wTSEG Fo Caudal * ) 2 1 1 ( + +

= Eq. 1

Donde BRP es igual al segmento de sincronización. El punto de muestreo está dado por: 100 ) 2 1 1 ( ) 1 1 ( % . x wTSEG wTSEG wTSEG M P + + +

= Eq.2

Para un caudal de 125 Kbit/s con un punto de muestreo del 81%, los valores asignados serán: MHz Fo wTSEG wTSEG BRP 8 ; 3 2 ; 12 1 ; 4 = = = = Sustituyendo: s Kbit MHz

Caudal 125000 125 /

4 * ) 3 12 1 ( 8 = = + + = % 81 100 ) 3 12 1 ( ) 12 1 ( .% . = + + + = x M P

(35)

Sustituyendo:

s Mbit MHz

Caudal 1000000 1 /

1 * ) 2 5 1 ( 8 = = + + = % 75 100 ) 2 5 1 ( ) 5 1 ( .% . = + + + = x M P

Para el caso de programar en un dispositivo o nodo CAN, los parámetros están basados en las especificaciones del CI utilizado para el diseño y de las especificaciones de BOSCH para redes CAN. En este caso solo tenemos que tomar en cuenta lo siguiente:

• El valor asignado en BRP para la tarjeta MUX debe ser dividido en 2 para obtener el valor a asignar en el BRP del nodo.

• wTSEG1=PROPSEG+PHSEG1

• wTSEG2=PHSEG2

• El punto de muestreo del nodo respeta la ecuación de la tarjeta MUX, solamente tomando en cuenta las anotaciones anteriores, esto es:

100 ) 2 1 1 ( ) 1 1 ( % . x PHSEG PHSEG PROPSEG PHSEG PROPSEG M P + + + + +

= Eq. 3

El valor de SJW representa la flexibilidad que va a tener el dispositivo en modificar los valores de wTSEG1 y wTSEG2 para evitar errores de sincronización, esto es realizar una re-sincronización. Para el valor de wSJW en la tarjeta MUX y SJW en el dispositivo CAN, solamente tenemos que respetar un valor de 1-4.

(36)

Características del medio y su actividad.

En cuanto a las características del medio, no existe un número limitado de nodos dentro de una red. Prácticamente el numero total de nodos se ve limitado por tiempos de retrasos y/o cargas eléctricas en la línea del medio. Como el medio de transmisión consiste en un solo canal de información, la forma en que el medio es implementado no es única. Los datos dentro del medio son representados por dos valores lógicos: “dominantes” o “recesivos”, en donde el valor dominante (nivel bajo o 0) predomina sobre el valor recesivo (nivel alto o 1).

Para reducir el consumo de energía del sistema, cualquier nodo CAN puede ponerse en modo de espera o sleep mode dejando cualquier actividad interna y desconectándose del medio de transmisión. Para abandonar este modo de espera solo es necesario que el medio de transmisión tenga actividad o que por condiciones internas del sistema la unidad se reinicie. Al reiniciarse, la actividad interna se reestablece, aunque la capa de transferencia estará esperando para que el oscilador del sistema se estabilice y esperara a sincronizarse con la actividad del medio (esperando once bits recesivos), antes de que la unidad encienda su comunicación completa con el medio. Para poder reiniciar a otros nodos del sistema, que se encuentren en modo de espera, se debe de emplear un mensaje de reinicio especial con el IDENTIFICADOR mas bajo posible (rrr rrrd rrrr ; r = recesivo, d = dominante)

Ahora con estos conceptos claros podemos entender mejor la forma en que funciona el protocolo CAN. Durante el desarrollo del documento entraremos poco más en detalle a la forma en que el mensaje es transmitido; en como se validan estos mensajes; la definición de errores y determinación de las fallas dentro de la transmisión, y algunos de los requisitos en la temporización de las transmisiones.

(37)

Capítulo 3. Diagnóstico de fallas.

Capítulo 3

Diagnóstico de fallas.

Dentro de este capítulo se establecerá una metodología de procedimientos de pruebas, en donde se definirán las categorías de problemas, las definiciones de cada problema y la prueba propuesta para cada uno de ellos, cubriendo desde el hardware hasta el protocolo de comunicación.

Dentro de la metodología se entrará en detalle a las funciones utilizadas para cada propuesta de prueba, ejemplificando cada función y proponiendo ejemplos de programación para un uso futuro.

También se definirá el dispositivo bajo pruebas, se establecerá la aplicación de pruebas para dicho dispositivo y se desarrollarán algunas de las pruebas propuestas para diferentes funciones dentro de la librería CAN a utilizar.

Metodología de procedimientos de pruebas.

Al definir una metodología de procedimiento de pruebas es necesario establecer los problemas a atacar, creando categorías de problemas con la finalidad de agrupar y relacionar las acciones necesarias para el diagnóstico de fallas que buscamos.

También es necesario establecer la relación entre las necesidades del protocolo de comunicación con respecto a errores, y los alcances y limitaciones de la librería de software de la tarjeta de comunicación y el dispositivo CAN. Una vez establecidas estas relaciones, se podrán proponer distintos procedimientos de pruebas.

(38)

Basados en el protocolo de comunicación CAN y las librerías de los módulos CAN de las tarjetas de comunicación y dispositivos podemos establecer dos categorías de problemas principales:

• Problemas de inicialización y/o configuración de hardware. • Problemas de comunicación y/o de operación.

Los problemas de inicialización y/o configuración de hardware se presentan al momento de llamar a las funciones necesarias para inicializar o configurar el equipo de acuerdo a las necesidades de la aplicación. Los errores que pueden detectarse en cada función pueden ser de dos tipos: de parámetro o de secuencia, y se representan mediante un código de retorno. Un error de parámetro nos indica que algunos de los parámetros dentro de una función fueron mal declarados. Un error de secuencia nos indica que la función de fue mandada a llamar se realizó fuera del orden de llamada establecido por la librería de software de la tarjeta.

Los problemas de inicialización y/o configuración pueden dividirse en:

• Problemas de identificación de dispositivo. Estos pueden ser causados por mala conexión de hardware o por equipo dañado.

• Problemas de inicialización. Este tipo de problemas son causados por error de carga de librerías de comunicación o por fallas internas de la tarjeta.

• Problemas de configuración. Se pueden presentar al momento de llamar a las funciones de configuración, indicando errores de estado

• Problemas de activación/desactivación de la tarjeta de comunicación.

Los problemas de comunicación y/o de operación se presentan comúnmente en la comunicación establecida entre la aplicación y los dispositivos dentro de la red por medio de la tarjeta de comunicación. En estos casos es muy importante tener en cuenta el protocolo de comunicación CAN para diagnosticar una falla de manera correcta. Los

(39)

errores que se presentan pueden ser causados por problema de hardware o por problemas de programación.

Los problemas de comunicación y/o de operación pueden dividirse como:

• Problemas de transmisión y recepción de datos. Estos pueden ser causados por problemas del medio de transmisión o por desconexión de la red.

• Monitoreo de errores basados en protocolo. Estos errores son basados en el protocolo mediante la característica de detección de errores en el mensaje. Los diferentes errores que se pueden presentar son: de bit, de formato, de stuffing o algún otro.

• Problemas en la detección de modos de operación “Sleep” y reactivación de bus de comunicación.

• Problemas en el accionamiento y lectura de I/O. • Problemas de gestión del reloj interno de la tarjeta.

La relación entre el protocolo y las funciones dentro de las librerías de software fue establecida por el desarrollador de la tarjeta de comunicación, basando las funciones de las librerías con las especificaciones del protocolo, cubriendo propiedades y conceptos básicos del mismo.

Basado en esto, es posible proponer procedimientos de pruebas que diagnostiquen que las funciones realicen todas las propiedades y conceptos establecidos en el protocolo.

Para los problemas de inicialización y/o configuración se recomienda agrupar todos los llamados de funciones de inicialización y configuración dentro de una sola prueba, respetando el orden de llamado establecido por el desarrollador. Así, es posible determinar en secuencia si alguna función que se ejecuta está causando un error. En caso de no ser así, poder determinar que la tarjeta puede ser utilizada para realizar las siguientes pruebas. La propuesta de esta prueba se desarrolla más adelante.

(40)

Para los problemas de comunicación y/o operación, no es suficiente proponer solo una prueba, si no que es necesario proponer varias pruebas que cubran los alcances y las limitaciones de las librerías con respecto al protocolo. Algunas de las propuestas son:

• Para los problemas de transmisión y recepción de datos se propone una interacción entre la aplicación y un dispositivo CAN por medio de la tarjeta, enviando y recibiendo una secuencia de datos controlada. Esta propuesta se desarrolla mas adelante en el documento.

• En el monitoreo de errores basados en protocolo se pueden hacer varias propuestas. Una de las propuestas es llevar a cabo una interacción entre la tarjeta un generador de errores aleatorios para monitorear el medio, obteniendo resultados estadísticos de error basados en modelos. Otra propuesta es el de generación de errores controlados con la finalidad de monitorear los contadores de errores para determinar que todos los errores son detectados adecuadamente.

• En la detección de modos de operación “sleep” y reactivación de bus de comunicación se propone el monitorear la tarjeta de tal forma que automáticamente caiga en modo “sleep”, tomando el tiempo en que tarda en caer en dicho modo para después reactivarla y hacer esto en repetidas ocasiones para calcular un valor estadístico de ese tiempo y al mismo tiempo evaluar el funcionamiento correcto de la función de reactivación de bus.

• Para la activación y lectura de entradas y salidas se propone realizar secuencias interactivas entre la tarjeta y un dispositivo programado. Demostrando que las entradas y salidas funcionan de acuerdo a la configuración establecida en la prueba propuesta.

(41)

• Y por ultimo para la gestión de timers, se propone que se evalúe su funcionamiento ya sea en una prueba específica o durante el desarrollo de otra prueba, monitoreando la lectura del timer y el restablecimiento del mismo.

Algunas de estas propuestas de pruebas no se desarrollarán en este documento, pero se proponen mas adelante como trabajos futuros. También es necesario decir que estas propuestas no son únicas y pueden ser mejoradas mas adelante. Las propuestas de pruebas que se desarrollan más adelante están estructuradas a manera de formato y se recomienda que se tome ese formato para el desarrollo de propuestas futuras.

Definición de DUT.

Definimos al dispositivo bajo pruebas (DUT) como el hardware a evaluar, haciendo pruebas a sus funciones, entradas, salidas, comunicación y manejo de errores dentro de la red CAN.

Las funciones del DUT que evaluaremos serán las comprendidas dentro de la librería CAN para aplicaciones de las tarjetas de comunicación. Dentro de esta librería existen funciones que usaremos para realizar pruebas de la comunicación y el manejo de errores.

Librerías de funciones utilizadas en protocolo CAN.

Para explicar mejor el funcionamiento de la tarjeta de comunicación dentro de una red CAN y una aplicación específica, podemos poner como ejemplo el sistema de diagnóstico utilizado en los talleres de servicio de algunas agencias automotrices. Para realizar estos diagnósticos de servicio es necesario contar con una estación de pruebas, que contienen las secuencias de pruebas y datos enviados a la red de comunicación dentro del automóvil. Estas pruebas y datos llegan por medio de una tarjeta de comunicación a la

(42)

red formada por varios dispositivos, generando eventos y retroalimentando datos, para que con esto pueda establecerse un diagnóstico bajo respuestas esperadas del sistema. Digamos que se realiza una prueba al sistema de frenado, enviando los datos necesarios para acelerar el motor a la velocidad necesaria. Después de alcanzar esta velocidad, por medio de la tarjeta se inicia una secuencia de frenado ligero y después agresivo. La función principal de la tarjeta es solamente el de comunicar los datos y retroalimentar las variables al controlador establecido dentro de la aplicación.

Dentro del manual de la librería CAN de la compañía EXXOTEST se menciona que una aplicación es capaz de dialogar a través de la tarjeta de comunicación con distintas redes mediante las diferentes funciones incluidas en la librería de aplicación.

Las funciones se describen dentro del manual de la librería CAN para la tarjeta de comunicación [8]. Dentro de estas funciones se encuentran las de comunicación, como son

la función de envío de datos y la función de recepción de eventos; y también funciones de configuración, como las de configuración de la tarjeta o configuración del bus de comunicación. Las funciones de configuración tienen un formato específico y un orden de llamado, pero las funciones de comunicación pueden ser programadas de tal forma que se adapten a la aplicación que se busque desarrollar.

La librería permite que una aplicación acceda hasta un máximo de 8 tarjetas simultáneamente así como a todas las redes de cada tarjeta. Se permite que varias aplicaciones accedan a varias tarjetas diferentes, pero no permiten que varias aplicaciones compartan una misma tarjeta. Basándonos en esto, estableceremos distintas configuraciones de conexión para realizar nuestras pruebas o desarrollar nuevas pruebas.

Una configuración de conexión que nos permitirá realizar pruebas de configuración de tarjeta, de comunicación y de estadística de errores, es la configuración que se muestra a continuación (Figura 3.1) en donde contamos con una conexión directa

(43)

[image:43.612.96.516.161.315.2]

entre PC y DUT por medio del puerto USB disponible en ambos dispositivos, y una conexión de red entre DUT y el dispositivo CAN.

Figura. 3.1. Configuración de conexiones.

En nuestro banco de pruebas, existen tres componentes: la aplicación, el medio de comunicación para pruebas y la retroalimentación de resultados. El banco de pruebas trabaja principalmente en la evaluación del medio de comunicación, en este caso la tarjeta de comunicación. Mediante el uso de una aplicación programada en la PC se realizan pruebas de configuración de comunicación y pruebas de comunicación de datos. Estas pruebas envían datos por medio de la tarjeta a una red CAN establecida entre la tarjeta y un dispositivo CAN. El dispositivo CAN es un retroalimentador de datos que se comporta de acuerdo a los datos enviados al medio. Dependiendo de la respuesta obtenida en el medio monitoreado por la tarjeta se determina un diagnóstico del funcionamiento de la tarjeta.

Conociendo ahora la aplicación general de la tarjeta y entendiendo la importancia de contar con una herramienta altamente confiable, en cuanto a los datos que proporciona a la aplicación en la cual se usa, comprendemos el por que es importante generar un diagnóstico fiel y preciso de las funciones de la tarjeta.

(44)

Procedimiento para evaluación de librería CAN.

Las pruebas realizadas para el diagnóstico de fallas en la tarjeta de comunicación están basadas en las funciones dentro de la librería de aplicación. Algunas de las pruebas utilizan más de una función al mismo tiempo y la duración de cada prueba es distinta.

El orden en que se realizan estas pruebas al diagnosticar la tarjeta, es determinado por una lista de pruebas especificada en la aplicación. También, algunas de estas pruebas dependen de la interacción de un dispositivo o nodo conectado en el canal CAN a

evaluar.

Cada prueba es descrita por un formato de prueba y un diagrama de flujo, que explica completamente el comportamiento y resultados esperados de cada prueba. A continuación se presenta la descripción de cada campo de la tabla:

(45)

No mbre de la prue ba

Clave y nombre asignado a la prueba

Re fe re nc ia a DLL- MUX- CAN

Función a evaluar dentro de la prueba, no se comentan las funciones

generales ni las de configuración

Va lo r de inte ré s

Variable de interés dentro de la función a evaluar.

Co ndic io ne s inic ia le s

Condiciones de estado de la tarjeta de comunicación en el instante

posterior al inicio de la prueba.

De sc ripc ió n de prue ba

Descripción general de la prueba. Los pasos de cada prueba se establecen

de manera resumida.

Arre g lo de e xpe rime nto

Se especifica la interacción de la aplicación con el nodo espía a través de

la tarjeta de comunicación, en caso de no contar con el nodo espía se

indica un error de pruebas y se marca como prueba fallida.

No ta

Cualquier observación necesaria para la comprensión de la prueba

Re sulta do s

Se presentan los posibles resultados de la prueba describiendo las causas

necesarias para la obtención de cada resultado.

[image:45.612.85.531.92.557.2]

Tabla. 3.1. Descripción de tabla de pruebas

(46)

[image:46.612.84.527.179.399.2]

Tabla de pruebas.

A continuación se enlistan las pruebas realizables en la aplicación del diagnostico, estableciéndose títulos y claves de pruebas.

Cla ve de prue b a No mbre de prue ba

Versión. # de prueba

01.001 Pruebas de configuración de tarjeta.

01.002 Prueba de comunicación.

01.003 Prueba de cambios de velocidad.

[image:46.612.78.533.181.402.2]

01.004 Pruebas de medición de carga de bus.

Tabla. 3.2. Descripción de tabla de pruebas

(47)

Pruebas de diagnóstico.

• Pruebas de configuración.

01.001 – Pruebas de configuración de tarjeta.

- MuxInit( ).

- MuxOpen ( ).

- CanConfigOper ( ).

- CanConfigParam ( ).

- CanConfigBus ( ).

- CanConfigStat ( ).

- CanActivate ( ).

La variable de interés en todas las funciones de referencia a la librería es la

de STATUS_OK. Esto nos indica que cada función esta funcional y puede ser

configurada adecuadamente.

Tarjeta des-activada e identificada.

La prueba manda llamar cada una de las funciones de referencia en

secuencia, de acuerdo a las especificaciones de documento de referencia

de la librería. Se espera que cada función se ejecute y devuelva STATUS_OK

para seguir con la siguiente función. En caso de no ser así la prueba se

aborta y se marca el error.

El arreglo mínimo para realizar esta prueba es el de la conexión por medio

de USB de la tarjeta con la PC de la aplicación. .

No ta

Este procedimiento es considerado como necesario para poder continuar el

resto de pruebas.

Re sulta do s

STATUS_OK en todas las funciones, determinan prueba aprobada.

Algún otro estado diferente al mencionado, en una o mas funciones,

[image:47.612.83.528.142.709.2]

determina prueba NO aprobada.

Tabla. 3.3. Pruebas de configuración.

(48)

TEST: OpenCard()

Inicializar la tarjeta

OK? NO

SI

OK? NO

SI

Prueba de Configuración

OK? NO

SI TEST: SetBusOper()

OK? NO

SI TEST: SetBusParm()

(49)

TEST: SetStatics()

OK? NO

SI

OK? NO

SI TEST: CloseCard()

End TEST TEST: SetBusBaud

Rate()

OK? NO

SI

TEST: CloseCard()

Siguiente prueba

[image:49.612.115.474.123.664.2]

ω

Figura. 3.2. Diagrama: Pruebas de configuración.

(50)

• Pruebas de comunicación.

01.002 – Prueba de comunicación.

- CanSendMsg ( ).

- CanGetEvent ( ).

Para CanSendMsg(), esperamos un STATUS_OK.

Para CanGetEvent(), esperamos:

- EVENT_CAN_MSGTX

- EVENT_CAN_MSGRX

- EVENT_CAN_BUSLOAD

- y STATUS_OK

La tarjeta esta activa y completamente configurada, el bus esta libre.

Se empieza enviando el identificador 0x000 por medio del bus hasta el nodo

espía, el nodo nos responderá haciendo eco en un identificador + 1 y con

un conjunto de datos que contaran desde 0x00 hasta 0xFF, incrementando

el identificador enviado por la tarjeta cada vez que se complete la cuenta

del nodo espía, llegando hasta el identificador 0x7EF.

La configuración de conexiones debe de ser completa PC-MUX-Nodo espía.

No ta

Al momento de aprobar esta prueba se puede continuar con el resto de

pruebas, en caso de no ser así, se debe de abortar y terminar la secuencia

de pruebas.

Re sulta do s

STATUS_OK en ambas funciones al final de los conteos de identificadores y los

datos, demuestra una prueba aprobada. En caso de no ser así sería una

[image:50.612.80.528.115.641.2]

prueba NO aprobada.

Tabla. 3.4. Pruebas de comunicación.

(51)

Set BaudRate a 125Kbits/s

ω

Init Frame Ident = 001

Send Frame

IdentTX = IdentRX+1

END TEST: Test FAILED END TEST: Test PASSED

Siguiente prueba IdentRX =

IdentTX+1 ?

IdentTX <= h7EF ? NO

SI

NO

BRP = 4 PSEG1 = 12 PSEG2 = 3 SJW = 4 SPL = 1

Data[1] = 01 (test id) Data[2] = 01 (test data) Data[3] = 00 Data[ ] = 00 Data[8] = 00

Prueba de Comunicación

[image:51.612.107.485.114.668.2]

Read Frame

(52)

• Pruebas de cambio de velocidad.

1.003 – Prueba de cambio de velocidad. 0

ariables de configuración de bus, BRP, TSEG1, TSEG2 y SJW. V

Cambio de valor en variables de configuración de bus, BRP, TSEG1, TSEG2 y

SJW, para hacer cambio de velocidad de 125Kbits/s a 250Kbits/s.

Funciones de configuración, CanSendMsg() y CanGetEvent() aprobadas.

En esta prueba se realiza la misma secuencia que la prueba de

cidad de comunicación, agregando al final del conteo un cambio de velo

transmisión de bus y realizando de nuevo el conteo de identificadores y

datos. Al final del segundo conteo se regresa a la configuración de la

primera velocidad y se da por terminada la prueba.

La configuración de conexiones debe de ser completa PC-MUX-Nodo espía.

No ta

Esta prueba solo depende de la aprobación de las pruebas de

e esta configuración y la prueba de comunicación. De la aprobación d

prueba no dependerán otras.

Re sulta do s

STATUS_OK en las funciones configuración, CanSendMsg() y CanGetEvent(),

demuestran que la prueba fue aprobada. En caso de no ser así se aborta la

prueba y se determina una prueba NO aprobada

[image:52.612.84.527.118.652.2]

Tabla. 3.5. Prueba de cambio de velocidad.

(53)

Set BaudRate a 125Kbits/s

Prueba de velocidad de trans.

λ

Send Frame

IdentTX = IdentRX+1

END TEST: Test FAILED

END TEST: Test PASSED

Siguiente prueba IdentRX =

IdentTX+1 ?

IdentTX <= h7EF ? NO SI SI NO Read Frame Set BaudRate a 250Kbits/s

Data[2} = 2 ? NO

SI

[image:53.612.115.487.113.667.2]

λ ω