AUTOMATIZACIÓN DE PRUEBAS DE PÉRDIDA DE … · tesis maestro en sistemas inteligentes multimedia...

TESIS

MAESTRO EN

SISTEMAS INTELIGENTES MULTIMEDIA

PRESENTA

I.M.T HUMBERTO ISAAC FLORES BERMEJO

ASESOR: NOÉ VILLA VILLASEÑOR

<[email protected]>

ZAPOPAN, JALISCO, JULIO 2018.

AUTOMATIZACIÓN DE PRUEBAS DE PÉRDIDA

DE COMUNICACIÓN CAN/LIN, RESETEO Y

DESACTIVACIÓN/ACTIVACIÓN EN SISTEMAS

AUTOMOTRICES EMBEBIDOS

PARA OBTENER EL GRADO DE

V

AGRADECIMIENTOS

Cada nuevo reto suele ser un trayecto con subidas y bajadas, la maestría no ha sida

para nada la excepción, muchas experiencias y vivencias llegaron con ella. A lo largo

de esta etapa he aprendido y crecido como profesionista y lo más importante como

persona.

En primer lugar me gustaría agradecer a mi familia, quien a pesar de muchas cosas

no son tan sencillas siempre han estado ahí para apoyarme en todo reto que me

propongo.

También quiero agradecer a todas aquellas personas las cuales han pasado por

alguna etapa de mi vida y dejaron algún aprendizaje o una enseñanza, algunos ya

no se encuentran en el mismo camino, solo pasando por un pequeño instante pero

siempre se agradecerá haber aprendido algo de ustedes. A aquellos pocos que aún

siguen aquí se les agradece mucho más.

Agradecimiento especial para Robert Bosch México el cual me permito y proporciono

todas herramientas y apoyo necesario para realizar esta investigación.

Por ultimo me gustaría agradecer al personal de CIATEQ y sus docentes. A mi asesor

Noé Villa y a mis compañeros de clase con los cuales conocí nuevos puntos de vista

y compartí esta dichosa experiencia.

VII

RESUMEN

Este documento aborda la problemática de la implementación de un marco de

pruebas automatizadas. El trabajo se concentra en el monitoreo y detección de fallas

que pueden ocurrir durante la comunicación entre las unidades electrónicas de

control (ECU). Las unidades ECU son ampliamente utilizadas en la industria automotriz.

El Desarrollo de la investigación se lleva a cabo en la planta Guadalajara de Robert

Bosch de México.

Las pruebas planteadas se enfocan en cubrir características no funcionales de los

sistemas embebidos dentro de un vehículo, por ello la investigación se enfoca en

descubrir las características y principios de los protocolos de comunicación utilizados

dentro de la industria automotriz CAN (Controller Area Network) y LIN (Local

Interconnect Network). Dicha investigación se limita a considerar las características

de estos dos protocolos. Ha sido posible descubrir los principios generales de la gran

mayoría de protocolos. Debido a esto la implementación del marco de pruebas

generado no se limita a estos protocolos y permite la extensión para múltiples

protocolos.

El desarrollo de la presente investigación ha permitido generar ahorros en tiempo de

ejecución. Igualmente se han descubierto nuevos defectos el software y

metodologías de pruebas.

Palabras clave: Tecnología de vehículos de motor; Tecnología de la instrumentación;

Tecnología de la automatización; Automóviles; Otras especialidades tecnológicas.

IX

ABSTRACT

This document addresses the problem of the implementation of a testing framework

for automation. The work focuses on the monitoring and detection of faults that may

occur during communication between the electronic control units (ECU). ECUs are

widely used in the automotive industry. The development of the research is carried out

in the Guadalajara plant of Robert Bosch of Mexico.

The tests proposed focus on covering non-functional characteristics of embedded

systems within a vehicle, the research focuses on discovering the characteristics and

principles of main communication protocols used within the automotive industry, CAN

(Controller Area Network) and LIN (Local Interconnect Network). This research is limited

to considering the characteristics of these two protocols. It has been possible to

discover the general principles of the majority of protocols. Thus, the implementation

of the test framework is not limited to these protocols, allowing the extension for

multiple protocols.

The development of this research has allowed to generate savings in execution time.

As a result, new defects have been discovered in software and new test

methodologies have been implemented.

Keywords: Motor vehicle technology; Automation technology; Instrumentation

technology; Automation technology; Automobiles; Other technological specialties.

XI

ÍNDICE DE CONTENIDO

AGRADECIMIENTOS.................................................................................................................................. V

RESUMEN ............................................................................................................................................... VII

ABSTRACT ................................................................................................................................................ IX

ÍNDICE DE CONTENIDO ........................................................................................................................... XI

ÍNDICE DE FIGURAS ................................................................................................................................ XV

ÍNDICE DE TABLAS ................................................................................................................................. XIX

GLOSARIO .............................................................................................................................................. XXI

NOMENCLATURA ................................................................................................................................. XXV

1. INTRODUCCIÓN ................................................................................................................................ 1

1.1. ANTECEDENTES ........................................................................................................................ 1

1.2. DEFINICIÓN DEL PROBLEMA .................................................................................................... 2

1.3. JUSTIFICACIÓN.......................................................................................................................... 3

1.4. OBJETIVOS ................................................................................................................................ 3

1.4.1. Objetivo general ............................................................................................................... 4

1.4.2. Objetivos específicos ........................................................................................................ 4

1.5. HIPÓTESIS ................................................................................................................................. 4

2. MARCO TEÓRICO .............................................................................................................................. 5

2.1. SISTEMAS EMBEBIDOS EN EL AMBIENTE AUTOMOTRIZ .......................................................... 5

2.2. REDES DE COMUNICACIÓN ...................................................................................................... 7

2.2.1. Topología de las redes de comunicación ......................................................................... 7

2.2.2. Organización de una red de comunicación .................................................................... 12

2.2.3. Direccionamiento ........................................................................................................... 14

2.2.4. Acceso a bus de datos .................................................................................................... 17

2.2.5. Modelo de interconexión de sistemas abiertos (OSI) ................................................... 26

2.3. REDES DE COMUNICACIÓN AUTOMOTRICES ......................................................................... 29

2.3.1. Composición de las redes automotrices ........................................................................ 30

2.3.2. Sistemas de buses en automóviles................................................................................. 31

2.3.3. Mecanismos de control .................................................................................................. 36

2.3.4. Clasificación de los sistemas de bus ............................................................................... 39

2.3.5. Compuerta de enlace (Gateway).................................................................................... 41

XII

2.4. APLICACIONES EN VEHÍCULOS ............................................................................................... 43

2.4.1. Sistemas de transmisión y chasis ................................................................................... 43

2.4.2. Sistemas de confort y comodidad .................................................................................. 43

2.4.3. Sistemas multimedia ...................................................................................................... 44

2.4.4. Ejemplo de redes vehiculares ......................................................................................... 44

2.5. SISTEMAS DE BUSES ............................................................................................................... 45

2.5.1. CAN ................................................................................................................................. 45

2.5.2. LIN ................................................................................................................................... 82

3. PROCEDIMIENTO DE INVESTIGACIÓN .......................................................................................... 113

3.1. DEFINICIÓN DE REQUISITOS DEL SISTEMA ........................................................................... 113

3.1.1. Perspectiva del sistema ................................................................................................ 114

3.1.2. Funcionalidad del producto .......................................................................................... 114

3.1.3. Restricciones ................................................................................................................. 114

3.1.4. Suposiciones y dependencias ....................................................................................... 114

3.1.5. Características de los usuarios ..................................................................................... 115

3.1.6. Entorno de utilización del sistema .............................................................................. 115

3.1.7. Requisitos funcionales .................................................................................................. 116

3.1.8. Requisitos no funcionales ............................................................................................. 117

3.2. DISEÑO E IMPLEMENTACIÓN ............................................................................................... 118

3.2.1. Clases, funciones y parámetros .................................................................................... 118

3.2.2. Diagramas eléctricos .................................................................................................... 127

3.2.3. Interfaz gráfica .............................................................................................................. 132

3.3. IMPLEMENTACIÓN DE LA AUTOMATIZACIÓN ...................................................................... 135

3.3.1. Visión general ............................................................................................................... 135

3.3.2. Procedimiento de pruebas anterior ............................................................................. 136

3.3.3. Cambio en el procedimiento de pruebas ..................................................................... 136

3.3.4. Medición ....................................................................................................................... 137

4. RESULTADOS................................................................................................................................. 139

4.1. REDUCCIÓN DE TIEMPOS ..................................................................................................... 139

4.2. VENTAJAS OBTENIDAS .......................................................................................................... 143

4.3. NUEVAS PRUEBAS EJECUTADAS ........................................................................................... 144

XIII

4.4. RETORNO DE INVERSIÓN (ROI) ............................................................................................ 145

4.5. DEFECTOS ENCONTRADOS ................................................................................................... 146

5. CONCLUSIONES ............................................................................................................................ 149

6. RECOMENDACIONES .................................................................................................................... 151

7. REFERENCIAS BIBLIOGRÁFICAS .................................................................................................... 153

8. ANEXO A ....................................................................................................................................... 159

XV

ÍNDICE DE FIGURAS

Figura 1 - Clasificación de los sistemas embebidos ............................................................. 6

Figura 2 - Topología bus ........................................................................................................... 8

Figura 3 - Topología estrella ..................................................................................................... 9

Figura 4 - Topología anillo ...................................................................................................... 10

Figura 5 - Topología malla ..................................................................................................... 11

Figura 6 - Topología híbrida ................................................................................................... 12

Figura 7 - Emisor, receptor y mensaje .................................................................................. 14

Figura 8 - Direccionamiento orientado al suscriptor .......................................................... 15

Figura 9 - Direccionamiento orientado al mensaje ........................................................... 16

Figura 10 - Clasificación de sistemas de múltiple acceso ................................................ 17

Figura 11 - Acceso múltiple por división de tiempo (TDMA) ............................................. 25

Figura 12 - Acceso múltiple por división de frecuencia .................................................... 18

Figura 13 - Comunicación maestro - esclavo ..................................................................... 20

Figura 14 - Colisión durante la transmisión de datos ......................................................... 21

Figura 15 - Respuesta ante una colisión ............................................................................. 23

Figura 16 - Prevención de colisiones .................................................................................... 24

Figura 17 - Modelo OSI ........................................................................................................... 27

Figura 18 - Red automotriz ..................................................................................................... 29

Figura 19 - Número de ECU en un vehículo (7) .................................................................. 30

Figura 20 - La interferencia electromagnética ................................................................... 33

Figura 21 - Control ET .............................................................................................................. 37

Figura 22 - Eventos de control ............................................................................................... 37

Figura 23 - Control TT ............................................................................................................... 38

Figura 24 - Buses automotrices .............................................................................................. 41

Figura 25 - Puerta de enlace ................................................................................................. 42

Figura 26 - Estructura del nodo de CAN .............................................................................. 51

Figura 27 - Direccionamiento y filtrado de mensajes ........................................................ 54

Figura 28 - Arbitrariedad de CAN ......................................................................................... 55

Figura 29 - Formato CAN 2.0A ............................................................................................... 59

Figura 30 - Campo de arbitraje ............................................................................................ 59

Figura 31 - Campo de control ............................................................................................... 60

Figura 32 - Formato CAN 2.0B................................................................................................ 64

Figura 33 - Estructura de un mensaje remoto ..................................................................... 65

Figura 34 - Formato de un mensaje de error ....................................................................... 66

Figura 35 - Formato de un mensaje de sobrecarga .......................................................... 67

Figura 36 - Espacio entre mensajes para nodos no pasivos ............................................. 68

Figura 37 - Espacio entre mensajes para nodo en error ................................................... 68

Figura 38 - Formato del espacio entre mensajes ............................................................... 68

XVI

Figura 39 - Peor caso del mecanismo de relleno de bits .................................................. 71

Figura 40 - Secuencia de tipos de errores ........................................................................... 76

Figura 41 - Nodo de CAN ...................................................................................................... 77

Figura 42 - Determinación de estados ................................................................................ 78

Figura 43 - Niveles de voltaje de CAN de baja velocidad ............................................... 80

Figura 44 - Niveles de voltaje para CAN de alta velocidad ............................................ 80

Figura 45 - Sistema de transmisión de datos CAN ............................................................. 82

Figura 46 - Ejemplo de buses de LIN..................................................................................... 83

Figura 47 - LIN Contra otros buses automotrices ................................................................ 84

Figura 48 - Estructura nodo de LIN ........................................................................................ 85

Figura 49 - Configuración de la red de LIN ......................................................................... 86

Figura 50 - Estructura de un menaje de LIN ........................................................................ 87

Figura 51 - Composición de los mensajes de LIN ............................................................... 87

Figura 52- Recepción de una señal ..................................................................................... 90

Figura 53 - Transmisión de una señal .................................................................................... 90

Figura 54 - Estructura de un mensaje ................................................................................... 91

Figura 55 - Estructura de los campo de datos ................................................................... 92

Figura 56 - Campo de corte ................................................................................................. 92

Figura 57 - Campo de sincronización .................................................................................. 93

Figura 58 - Campo de identificador protegido .................................................................. 94

Figura 59 - Campo de datos ................................................................................................. 94

Figura 60 - Transferencia de tres mensajes incondicionales ............................................ 96

Figura 61 - Resolución de colisiones en LIN ......................................................................... 98

Figura 62 - Mensaje esporádico ........................................................................................... 99

Figura 63 - Definición de tiempo ........................................................................................ 101

Figura 64 - Máquina de estados de la tarea maestra .................................................... 102

Figura 65 - Máquina de estados de procesamientos de mensajes de la tarea esclava

................................................................................................................................................. 103

Figura 66 - Maquina de estados de procesamientos de mensajes de la tarea esclava

................................................................................................................................................. 105

Figura 67 - Señal de activación de un nodo esclavo ..................................................... 106

Figura 68 - Secuencia de señales de activación ............................................................. 106

Figura 69 - Bloques de señales de activación .................................................................. 107

Figura 70 - Diferencia entre fuentes de voltaje ................................................................ 110

Figura 71 - Niveles en el bus de LIN .................................................................................... 110

Figura 72 -Banco de pruebas .............................................................................................. 116

Figura 73 - Clase Loss_CAN.................................................................................................. 118

Figura 74 - Clase Loss_LIN ..................................................................................................... 119

Figura 75 - Clase Short2Ground_CAN ................................................................................ 120

Figura 76 - Clase Short2Ground_LIN ................................................................................... 121

Figura 77 - Clase Short2Battery_CAN ................................................................................. 122

XVII

Figura 78 - Clase Short2Battery_LIN..................................................................................... 123

Figura 79 - Clase Power_Reset ............................................................................................ 123

Figura 80 - Clase WakeUp .................................................................................................... 124

Figura 81 - Clase Sleep ......................................................................................................... 124

Figura 82 - Interacción entre cases .................................................................................... 125

Figura 83 - Clase común para protocolos ......................................................................... 126

Figura 84 - Diagrama eléctrico CAN DW ........................................................................... 128

Figura 85 - Diagrama eléctrico CAN SW............................................................................ 129

Figura 86 - Diagrama eléctrico común para protocolos ................................................ 130

Figura 87 - Diagrama eléctrico LIN ..................................................................................... 131

Figura 88 - Diagrama activación y desactivación .......................................................... 132

Figura 89 - Panel de control ................................................................................................. 135

Figura 90 - Implementación de funciones ........................................................................ 137

Figura 91 - Reducción de tiempo en pruebas continúas de pérdida de

comunicación ....................................................................................................................... 140

Figura 92 - Reducción de tiempo en pruebas continúas de activación y

desactivación ........................................................................................................................ 141

Figura 93 - Reducción de tiempo en pruebas continúas de reseteo ........................... 142

XIX

ÍNDICE DE TABLAS

Tabla 1 - Requisitos de los sistemas en tiempo real ............................................................ 35

Tabla 2 - Clasificación del bus de CAN ............................................................................... 40

Tabla 3 - Descripción general de buses .............................................................................. 45

Tabla 4 - Principales acontecimientos en los primeros 20 años de CAN ........................ 48

Tabla 5 - Código de longitud de datos ............................................................................... 60

Tabla 6 - Mapa de memoria de mensaje de datos .......................................................... 61

Tabla 7- Comando para ir a modo inactivo ..................................................................... 107

Tabla 8 - Interpretación de errores ..................................................................................... 109

Tabla 9 - Personal involucrado ............................................................................................ 114

Tabla 10 - Reglas de diseño ................................................................................................. 134

Tabla 11 - Reducción de tiempo en pruebas de pérdida de comunicación............. 139

Tabla 12 - Reducción de tiempo en pruebas continúas de pérdida de comunicación

................................................................................................................................................. 140

Tabla 13 - Reducción de tiempo en pruebas activación y desactivación ................. 140

Tabla 14- Reducción de tiempo en pruebas continúas de activación y desactivación

................................................................................................................................................. 141

Tabla 15 - Reducción de tiempo en pruebas de reseteo .............................................. 141

Tabla 16 - Reducción de tiempo en pruebas continúas de reseteo ............................ 142

Tabla 17 - Costos del equipo VT System ............................................................................ 145

Tabla 18 - Costo por hora ingeniería de trabajo .............................................................. 146

XXI

GLOSARIO

VT System – Módulos de interfaz de entradas y salidas para pruebas de ECU.

CAN – Red de área de controlador (Controller Area Network).

LIN – Red de interconexión local (Local Interconnect Network).

ISO – Organización Internacional de Normalización (International Organization for

Standardization).

SAE – Sociedad de Ingenieros Automotrices (Society of Automotive Engineers).

RTOS – Sistemas en tiempo real (Real-Time Operative System).

ECU – Unidad de control electrónico (Electronic Control Unit)

TX – Transmisión (Transmission).

RX – Recepción (Receiver).

IP – Protocolo de Internet (Internet Protocol).

ID – Identificador de mensaje (Identifier)

TDMA – Acceso múltiple por división de tiempo (Time Division Multiple Access).

RF – Radio frecuencia (Radio Frequency).

FDMA – Acceso múltiple por división de frecuencia (Frequency Division Multiple

Access).

CDMA – Acceso múltiple por división de código (Code Division Multiple Access).

CSMA – Acceso Múltiple con Escucha de Señal Portadora (Carrier-Sense Multiple

Access).

CSMA-CD – CSMA con detección de colisión (Carrier Sense Multiple Access with

Collision Detection).

IEEE – Instituto de Ingeniería Eléctrica y Electrónica (Institute of Electrical and

Electronics Engineers).

CSMA / CCA – CSMA con copia de prevención de colisiones (Carrier Sense Multiple

Access with Collision Avoidance).

OSI – Modelo de interconexión de sistemas abiertos (Open System Interconnection).

PDU – Unidades de protocolo de datos (Protocol Data Units).

ESP – Programa de estabilidad electrónica (Stability Control Program).

EMC – Compatibilidad electromagnética (Electromagnetic Compatibility).

XXII

EMI – Interferencia electromagnética (ElectroMagnetic Interference).

UTP – Cableado de par trenzado sin blindaje (Unshielded twisted pair).

STP – Cableado de par trenzado con blindaje (Shielded Twisted Pair).

ABS – Sistema de frenos antibloqueo (Antiblockiersystem, Antilock Brake System).

EDC – Sistema de control electrónico de diesel (Electronic Diesel Control).

ABC – Sistemas de control activo del chasis (Active Body Control).

ACC – Sistemas de control de crucero adaptativo (Adaptive Cruise Control)

MSM – Módulos de memoria para asientos (Memory Seat Module).

CCSM – Módulos climatización de asientos (Climatique Control Seat Module).

CSM – Módulo de sistema central (Center Stack Module).

IPC – Panel de control de instrumentos (Instrumental Control Panel).

HUD – Pantalla frontal (Head-Up Display).

CiA – CAN en Automatización (CAN in Automation).

I2C – Circuito Inter-integrado (Inter-Integrated Circuit).

ET – Activación por eventos (Event Triggered).

TT – Activación por tiempo (Time Triggered),

TTCAN – CAN activado por tiempo (Time-Triggrered CAN).

MOST – Sistema de transporte orientado a medios (Media Oriented Systems

Transport).

OSEK – Sistemas abiertos y sus interfaces para electrónicos en vehículos de motor

(Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen, Open

systems and their interfaces for electronics in motor vehicles).

LLC – Control de Enlace Lógico (Logical Link Control).

MAC – Control de Acceso al Medio (Media Access Control).

RTR – Retransmisión remota (Remote Retransmition).

EOF – Fin del mensaje (End Of Frame).

SOF – Inicio del mensaje (Start Of Frame).

CRC – Comprobación de redundancia cíclica (Cyclic Redundancy Check).

FIFO – Primeras entradas primeras salidas (First Inputs First Outputs).

DLC – Código de longitud (Data Length Code).

ACK – Reconocimiento (Acknowledge).

NRZ – No regreso a cero (Non-Return Zero).

XXIII

TEC – Contador de errores de transmisión (Transmission Error Counter).

REC – Contador de errores de recepción (Reception Error Counter).

CAN_H – Canal alto de CAN (CAN High).

CAN_L – Canal bajo de CAN (CAN Low).

SCI – Interface de comunicación serial (Serial Communications Interface).

UART – Receptor-transmisor asincrónico universal (Receptor-transmisor asincrónico

universal).

LSB – Bit menos significativo (Less Significative Bit).

MSB – Bit mas significativo (More Significative Bit).

PID – Identificador protegido (Protected Identifier).

Jlitter – Fluctuación (Variaciones en el tiempo de una señal con respecto a su posición

original).

ERS – Especificación de Requisitos Software (SRS, Software Requirement Specification).

CAPL – Lenguaje de programación nativa de CANoe (Communication Access

Programming Language).

CANoe - Herramienta de software para el desarrollo, prueba y análisis de redes

completas y ECU individuales.

VT System – Módulos de interfaz de entradas y salidas para pruebas de ECU.

CAN DW – CAN doble cable (CAN Double-Wire).

CAN SW – CAN un cable (CAN Single-Wire).

HMI – Interfaz Hombre-Máquina (Human Machine Interface).

XXV

NOMENCLATURA

Rb – Tasa de transferencia por usuario.

Rbs – Tasa de transmisión de bits del sistema.

Tg – Tiempo libre de transmisión.

Tf – Duración de tiempo de transmisión (ventana).

K- Número de slots por cada ventana o número de canales.

B – Ancho de banda de cada canal.

Bg – Tiempo libre de transmisión entre los dos canales.

VBAT – Tensión de alimentación.

VSUP – Voltaje de suministro interno.

A – Ángulo (min).

H – Tamaño del carácter (cm).

D – Distancia entre el operador y el HMI (cm).

1

1. INTRODUCCIÓN

Este primer capítulo se encarga de presentar los elementos por los cuales se decidió

a llevar a cabo esta esta investigación. En primera instancia se presentarán los

antecedentes y definición del problema, con lo que justificamos y definiremos el

objetivo general y objetivos específicos de la investigación y finalmente generamos la

hipótesis dicha investigación.

1.1. ANTECEDENTES

Hoy en día la industria automotriz en es una de las industrias con mayor auge,

dinamismo y crecimiento en México y en el mundo (1). Hoy la industria automotriz

mexicana vuelve a ser centro de atención en la escena global, debido a que vive un

proceso de transición de un perfil orientado principalmente a la manufactura, a uno

en el que la innovación y el diseño juegan un papel preponderante (2).

La demanda automotriz así como el los avances tecnológicos obligan a los

fabricantes de vehículos a incorporar cada vez más mejoras dentro del confort,

seguridad y cuidado al medio ambiente. Los nuevos productos se basan en el

desarrollo de sistemas embebidos, los cuales deben de cumplir con estrictas

normativas que garanticen la seguridad de los usuarios.

Para asegurar la calidad del producto y con ello la satisfacción del cliente, las pruebas

juegan un papel importante al conseguir este objetivo Las pruebas de sistema dentro

de cualquier metodología de desarrollo de software son una etapa que debe

comenzar actividades tempranamente. Dentro del desarrollo de software la

ejecución de pruebas suele efectuarse como uno de los últimos pasos de este nivel

de pruebas. La liberación final del software al cliente depende de la terminación de

la ejecución de pruebas. Por ello es de vital importancia la detección de fallas en esta

etapa previa a la entrega al cliente de esta manera evitar cualquier descontento. Un

software libre de errores no es posible de garantizar, el seguimiento de metodologías

así como técnicas de prueba pueden incrementar la confianza del cliente. Uno de

los principales factores que afecta la profundidad de las pruebas es el tiempo y

2

presupuesto. La combinación de pruebas funcionales y no funcionales así como su

ejecución manual o automática.

1.2. DEFINICIÓN DEL PROBLEMA

En la actualidad la empresa Robert BOSCH México se encuentra dentro un proceso

de crecimiento inicial. Debido a que han pasado pocos años desde la estabilización

del centro de desarrollo tecnológico en la ciudad de Guadalajara. Para el comienzo

del centro de desarrollo se optó por seguir las metodologías, infraestructura y procesos

de otras localidades en diferentes partes del mundo. Esto trajo como consecuencia

diferentes efectos muchos a favor como la adquisición de conocimientos y lecciones

aprendidas a través de la experiencia de los demás centros de desarrollo pero no se

fue exento de algunas problemáticas.

La principal problemática que se pretende resolver a través de esta investigación fue

la generada a la adquisición de equipamiento que es utilizado por otras localidades

en diversos proyectos de desarrollo de sistemas embebidos para el ramo automotriz,

dicho equipamiento al ser un equipo especializado tiene un costo elevado pero

puede ser utilizado para tener beneficios tangibles; como confiabilidad, precisión,

reducción de tiempos y esfuerzos por mencionar algunos. Actualmente estos

beneficios no están siendo aprovechados y el equipamiento no está siendo utilizado.

Otra característica de la situación actual en la que se encuentra las operaciones es

la poca o casi nula automatización con la que se están ejecutando las pruebas en

desarrollos llevados a cabo dentro del centro de desarrollo de Guadalajara. La gran

mayoría de pruebas se ejecutan de manera manual lo cual requiere la operación

constante así como la presencia del personal de pruebas. La combinación de estas

dos problemáticas afecta al equipo de pruebas de sistemas de la localidad y a su vez

presenta una oportunidad para la implantación de mejora que pueda traer grandes

beneficios.

3

1.3. JUSTIFICACIÓN

Ya se ha hecho mención sobre la importancia de las pruebas dentro del desarrollo de

sistemas y el valor agregado a la calidad del producto y satisfacción del cliente. La

compañía cuenta con el equipo VT System el cual es una solución comercial para la

creación de ambientes de pruebas. Este equipo no está siendo utilizado por lo cual es

necesario la implementación y automatización de pruebas, así poder generar un

ahorro de tiempo y esfuerzos. Esta implementación pretende genere una reducción

de costos y recuperación del costo de inversión en equipo.

Para poder generar estos beneficios se plantea utilizar el equipo de pruebas VT

System. El personal de pruebas está realizando ejecuciones manuales donde la

interacción no es indispensable o puede ser reemplazada. De ello se deriva la idea

de realizar automatización de pruebas de pérdida de comunicación y reseteo en las

líneas de comunicación CAN y LIN. Dichas pruebas en la actualidad se están

realizando manualmente donde el personal de pruebas tiene que conectar y

desconectar los cables de transmisión de datos y la fuente de alimentación.

En otras palabras el proyecto plantea aportar una solución de ayuda en:

Enfocar actividades humanas a tareas que agreguen valor.

Minimizar el error humano durante la fase de pruebas.

Aumentar ganancias al reducir tiempos.

Estandarización.

Seguimiento de Normativa.

Mejorar la calidad del producto.

Utilización de equipamiento no utilizado.

Retorno de inversión en gastos del equipamiento.

1.4. OBJETIVOS

Automatizar pruebas de pérdida de comunicación y reseteo en sistema embebidos

automotrices mediante el equipo VT System.

4

1.4.1. Objetivo general

Automatizar pruebas de sistema mediante el equipo VT System.

1.4.2. Objetivos específicos

Los objetivos específicos definidos a partir del objetivo general son:

Automatizar pruebas de pérdida de comunicación CAN (Controller Area

Network).

Automatizar pruebas de pérdida de comunicación LIN (Local Interconnect

Network).

Automatizar pruebas de Reseteo de Alimentación.

Automatizar pruebas de modo dormir y despertar.

Utilizar los módulos de VT System VT2820 VT2004A.

1.5. HIPÓTESIS

La presente investigación pretende demostrar:

Si se logra una automatización de pruebas por consiguiente el tiempo de

ejecución manual se limitará al tiempo de ajuste del equipo recuperando el

costo de inversión de equipo.

5

2. MARCO TEÓRICO

2.1. SISTEMAS EMBEBIDOS EN EL AMBIENTE AUTOMOTRIZ

Se le conoce como un Sistema embebido a circuito electrónico computarizado el

cual es diseñado para cumplir con una tarea específica (3). Un sistema

computacional de uso general como una computadora personal puede cumplir con

diferentes tareas por ejemplo editar y crear documentos, navegar en internet,

visualizar imágenes y videos por mencionar algunas. Un sistema embebido de lo

contrario como se encarga de realizar una tarea específica o un conjunto de

funciones dedicadas.

Un sistema embebido está dedicado a realizar tareas específicas. Estos pueden ser

diseñados para optimizar dichas tareas. Reduciendo su tamaño y costo de

producción para incrementar la confianza y el desempeño del mismo (4).

Entre las diversas áreas de aplicación de un sistema embebido se encuentra:

1. Sistemas electrónicos automotrices.

2. Sistemas electrónicos aeronáuticos.

3. Telecomunicaciones.

4. Sistemas electrónicos médicos.

5. Aplicaciones militares.

6. Robots.

7. Electrodomésticos.

Algunos ejemplos enfocados al área automotriz son los sistemas de frenado anti

bloqueo o los sistemas de bolsas de aire. La complejidad de los sistemas embebidos

automotrices se está aumentando cada vez más. Por lo cual están sujetos a una gran

cantidad de normas que aseguren su funcionalidad y cuiden la integridad de los

usuarios. El estándar ISO 26262 (5) es uno de los estándares dedicados

específicamente a la seguridad de los sistemas automotrices.

6

Figura 1 - Clasificación de los sistemas embebidos

Los sistemas de software automotrices son clasificados como sistemas en tiempo real

(RTOS Real-time operative system). Estos sistemas operativos son destinados a ejecutar

aplicaciones en tiempo real. Esto implica que son sistemas se rigen bajo requisitos de

tiempo muy estrictos.

Un sistema operativo de tiempo real debe responder a eventos externos dentro de

lapsos de tiempo muy pequeños. Este tiempo de respuesta en el cual un sistema

responde a una interrupción generada por un evento es conocido como latencia de

interrupción. Al mismo tiempo un sistema operativo en tiempo real debe de ser capaz

de manejar todas estas interrupciones y priorizarlas para asegurar el correcto

procesamiento de eventos generados.

Las tareas procesadas por estos sistemas operativos deben ser tareas finitas con un

límite de tiempo llamado deadline. Para conseguir esto un sistema de programación

de tareas es llevado a cabo (6).

Si un sistema operativo en tiempo real debe de cumplir con requisitos de tiempo

continuamente es llamado Sistema duro en tiempo real, si el sistema no debe de

cumplir con estos requisitos de tiempo es considerado como sistemas ligeros o suaves

7

en tiempo real. Es por ello que los sistemas embebidos en tiempo real dentro de una

red automotriz son considerados como sistemas duros, como los ejemplos

mencionados un bolsa de aire instalada dentro de un vehículo debe responder y

activarse en un lapso determinado de tiempo después de que un impacto ha sido

detectado.

2.2. REDES DE COMUNICACIÓN

Se entiende por una red de comunicación a sistema en el cual un grupo de elementos

intercambian información a través de un medio de transporte (7). Un nodo puede ser

visualizado como un elemento dentro de la red de comunicación. El medio de

transporte es la vía por la cual la comunicación toma lugar, suele ser referido como

bus o bus de datos.

2.2.1. Topología de las redes de comunicación

Existe diversas tipos de redes de comunicación, estas se pueden clasificar debido a su

topología. La topología de una red de comunicación se entiende por la estructura

con la cual los nodos son contados. Por lo menos dos nodos deben de estar

conectados entre sí para que una red exista. La topología de una red determinara

algunas de las características de la comunicación (8).

La gran mayoría de redes de comunicación se basan en las siguientes topologías (9).

2.2.1.1. Bus

Fiable en redes pequeñas.

Bajo costo.

Cualquier nodo puede transmitir en cualquier momento.

Si un nodo falla afecta al resto de la red.

8

Figura 2 - Topología bus

2.2.1.2. Estrella

Utiliza un nodo central donde el resto de nodos están conectados.

Toda la comunicación se realiza a través del nodo central.

El nodo central se encarga tomar todas las decisiones y prioridades.

La red únicamente falla si el nodo central falla.

Fácil detección de fallas en la red.

Fácil mantenimiento.

Buen rendimiento y confiable.

9

Figura 3 - Topología estrella

2.2.1.3. Anillo

Lo nodos están unidos únicamente con los nodos vecinos.

Comunicación unidireccional a través de los nodos vecinos.

La red puede abarcar largas distancias.

Fácilmente extendibles.

Si un nodo falla toda la red falla.

La transmisión suele ser más lenta que en otro tipo de topología.

10

Figura 4 - Topología anillo

2.2.1.4. Malla

Todos los nodos tienen una conexión con cada otro nodo de la red.

Conexiones redundantes entre los nodos de la red.

En caso de alguna falla en un nodo la red sigue operando.

Facilita el aislamiento de fallas.

Privacidad entre información transmitida.

En caso de alguna falla es más difícil de diagnosticar.

Costoso debido a la cantidad de cableado.

11

Figura 5 - Topología malla

2.2.1.5. Hibrida

Las topologías híbridas son la combinación de diferentes topologías.

12

Figura 6 - Topología híbrida

2.2.2. Organización de una red de comunicación

En una red de comunicación automotriz o de cualquier tipo debe de existir una

organización y protocolos para que esta logre funcionar correctamente. Se ha hecho

mención a los tres elementos básicos que la conforman:

1. Nodo

2. Medio de Transporte

3. Datos

13

2.2.2.1. Nodo (ECU)

En un lenguaje automotriz un nodo es referido como una unidad de control

electrónico (Electronic control unit, ECU) (10). Una unidad de control electrónico se

caracteriza por ser un sistema embebido el cual debe recibir toda la información

proveniente del medio ambiente a través señales eléctricas transmitidas por sensores.

La ECU procesa todos estos datos utilizando un programa de software y responde

mediante la generación de señales de control para diversos tipos de actuadores.

2.2.2.2. Medio de transporte

El medio de transporte en un vehículo automotriz no es más que el cableado y los

araneses con los que las ECUs se conectan entre sí además de los sensores,

actuadores.

2.2.2.3. Datos/Bus de Datos

Los datos, bus de datos es la información que será enviada entre las ECUs que

conforman la red dentro de un vehículo. Estos datos o paquetes de datos son

enviados a través de un mensaje. Se dice que un ECU es emisor o transmisor cuando

es el encargado de enviar información y receptor cuando éste lee la información

proveniente de otro. Dada esta característica un mensaje se considerará TX cuando

es transmitido y RX cuando es un mensaje recibido (11).

14

Figura 7 - Emisor, receptor y mensaje

2.2.3. Direccionamiento

Para hacer posible la transmisión de paquetes de información a través de mensajes

dentro un red de comunicación y evaluar el contenido de los datos útiles, el mensaje

transmitido debe ser acompañado de información de transferencia. La información

puede ser transmitida explícitamente dentro del contenido del mensaje o

implícitamente por valores predefinidos. Esta información es necesaria para garantizar

que el contenido del mensaje fue enviado y recibido correctamente (7).

Algunas maneras de realizar el direccionamiento son las siguientes:

Orientado al Suscriptor.

Orientado al Mensaje.

Orientado a la Transmisión.

15

2.2.3.1. Direccionamiento orientado al suscriptor

Los paquetes de datos se intercambian en base a las direcciones de los nodos (ECU).

Los mensaje enviados por el nodo transmisor contiene los datos a transmitir y también

la dirección del nodo de destino. Todos los nodos receptores comparan la dirección

de recepción enviada por el transmisor con su propia dirección, y solo el receptor con

la dirección correcta evalúa el mensaje, el resto de nodos ignoran la información

enviada (7). Un ejemplo de red de comunicación automotriz el cual utiliza este tipo

de suscripción es la comunicación por medio de Ethernet, el cual mediante una

dirección IP (Protocolo de Internet) proporciona a los nodos un único número de

identificación jerárquico (12).

Figura 8 - Direccionamiento orientado al suscriptor

2.2.3.2. Direccionamiento orientado al mensaje

Este tipo de direccionamiento se basa en el contenido del mensaje, se identifica por

un identificador de mensaje (ID) que ha sido predefinido para este tipo de mensaje.

En este método, el transmisor no necesita saber nada sobre el destino del mensaje, ya

16

que cada receptor lee el mensaje y decide si este es procesado o no. El mensaje

puede ser recibido y evaluado por varios nodos (7). Los ejemplos más claros de este

tipo de direccionamiento son los mensajes de CAN (Controller Área Network) los

cuales son enviados a un bus y escuchados por múltiples nodos.

Figura 9 - Direccionamiento orientado al mensaje

2.2.3.3. Direccionamiento orientado a la transmisión

Las características de transmisión también se pueden usar para identificar un mensaje.

Si un mensaje siempre se transmite dentro de una ventana de tiempo definida, esta

se puede utilizar como base para definir el destino. Como medida de seguridad, este

direccionamiento a menudo se combina con un mensaje o un direccionamiento

orientado al suscriptor (7).

17

2.2.4. Acceso a bus de datos

Para poder hacer la transmisión de datos a través de un nodo transmisor es necesario

primero acceder a la red para ello existen diferentes métodos:

Métodos predecibles en los que el acceso al bus está determinado por el

tiempo. En este método solo un nodo puede transmitir a la vez y el derecho de

acceso al bus se determina antes del acceso al bus. En este método se evitaran

las colisiones de acceso debido al uso simultáneo (7).

Métodos aleatorios mediante los cuales cualquier nodo puede transmitir datos

si el bus parece estar libre. En el método, los nodos pueden intentar usar el bus

simultáneamente tan pronto como parezca estar libre. Existe el riesgo de

colisiones de transmisión utilizando este método. Esto se puede resolver

repitiendo transmisiones después de que se haya detectado una colisión (7).

Figura 10 - Clasificación de sistemas de múltiple acceso

18

2.2.4.1. Acceso múltiple por división de frecuencia (FDMA)

En este sistema los canales de trasmisión son definidos de acuerdo con la asignación

de frecuencia. Esto quiere decir que todos los nodos se encuentran activo y cada uno

ocupa un segmento del espectro de radio frecuencia (RF). Todos los nodos reciben la

información pero filtran únicamente la frecuencia que les es asignada. En este sistema

el ancho de banda por nodo es simplemente relacionada con la velocidad de los

datos. Así el ancho de banda del sistema es calculado dela siguiente manera (13).

𝐵𝑠 = 𝐾 ∗ (𝐵 + 𝐵𝑔)

K, es el número de canales.

B, es el ancho de banda de cada canal.

Bg, es tiempo libre de transmisión entre los dos canales.

Figura 11 - Acceso múltiple por división de frecuencia

19

2.2.4.2. Acceso múltiple por división de código (CDMA)

El sistema de acceso múltiple por división de código, similar a la división por frecuencia

divide el espectro en canales ortogonales y así evitar la interferencia entre ellos aun

que los canales no son completamente ortogonales debido a imperfecciones en la

sincronización de tiempo y el filtrado, lo cual puede generar algunas interferencias.

Los sistemas CDMA a diferencia de los sistemas FDMA utilizan un código para definir

sus canales (13).

2.2.4.3. Maestro - Esclavo

Los protocolos maestro-esclavo se usan en situaciones donde un nodo principal

controla uno o más nodos (incluso una red completa). La comunicación entre el

maestro y sus esclavos se rige por una técnica llamada Sondeo (Polling). Este sondeo

es llevado de la siguiente manera: El maestro envía datos en forma de un mensaje a

cualquiera de los esclavos. El mensaje contiene una dirección que está destinado

únicamente para un esclavo, así el esclavo puede procesar la información. Para

recibir datos de los esclavos, el maestro 'sondea' a cada esclavo enviándoles un

mensaje y preguntándole si tiene algún dato para enviar, el esclavo responde

enviando datos o enviando un rechazo mensaje para indicar que no tiene nada que

enviar. Sin embargo, algunos protocolos de maestro-esclavo permiten que un esclavo

contacte a un maestro para transmitir (14).

20

Figura 12 - Comunicación maestro - esclavo

2.2.4.4. Multi-maestro

Si en una red todos los nodos pueden transmitir sin necesidad de ser controlado por

otro nodo siempre y en cuando el bus se encuentre libre se conoce como un sistema

multi-maestro, donde la priorización y la detección de colisiones juegan un papel

importante (7) en el caso que múltiples nodos intenten acceder bus simultáneamente.

Por otro lado este sistema asegura la comunicación directa entre todos los nodos del

sistema por lo tanto la máxima velocidad y confianza posible. En una red multi-

maestro todos los nodos tienen los mismos derechos de transmisión (15).

2.2.4.4.1. Acceso múltiple con escucha de señal portadora

(CSMA)

Una solución creada para evitar la colisión entre paquetes de información enviados

es permitir que el nodo detecte (escuche) el canal o bus en el cual se encuentra

21

transmitiendo. Cuando un nodo tiene un paquete para transmitir, primero escucha el

canal. Si el canal se detecta inactivo, el paquete se transmite. Si, por otro lado, el

canal está ocupado, la transmisión del paquete se retrasa por un momento. De esta

forma, la posibilidad de colisión de paquetes se reduce en gran medida. Este

esquema se llama Acceso Múltiple con Escucha de Señal Portadora (CSMA). En un

esquema de CSMA, las colisiones de paquetes aún pueden ocurrir (16).

2.2.4.4.2. Sistemas anticolisiones

Como se ha mencionado el acceso a un bus de datos puede llegar a generar

colisiones, es decir que más de un nodo intenten transmitir información

simultáneamente. Esta es una acción recurrente en sistemas de acceso aleatorio.

Para solucionar esta problemática, el acceso a un bus de datos está acompañado

de un sistema anticolisiones que ayude a evitar dichos conflictos.

Figura 13 - Colisión durante la transmisión de datos

22

2.2.4.4.3. Acceso múltiple con escucha de señal portadora

con detección de colisiones CSMA/CD

Debido a que los sistemas CSMA son propensos a accesos simultáneamente de los

nodos, si se produce una colisión de paquetes, la transmisión puede ser abortada

antes de que se complete. De esta forma, la duración del tiempo de colisión puede

acortarse y la utilización del canal puede mejorarse aún más (16). Así cuando una

red se encuentra en reposo y múltiples nodos tratan de acceder un mensaje de

contención es detectado. En ese momento la transmisión es pausada y los nodos se

retiran de la red, después de un determinado tiempo los nodos intentar acceder de

nuevo (17). Este esquema se llama CSMA con detección de colisión (CSMA-CD). A

pesar de que este sistema ayuda a mejorar el rendimiento del canal la cancelación

de envíos decremento la capacidad de la red, donde incluso cuando la transferencia

de datos se encuentra en su punto más alto la red puede quedar totalmente

bloqueada, por tanto este sistema no se vuelve conveniente de utilizar en sistemas de

tiempo real.

23

Figura 14 - Respuesta ante una colisión

2.2.4.4.4. Acceso múltiple con Escucha de Señal Portadora

con prevención de colisiones CSMA/CA

Para resolver la problemática mencionada en los sistemas CSMA/CD el principio de

“prevención de colisiones” es implementado. Este sistema de contención los

conflictos de acceso a la red son evitados asignando un nivel de prioridad a cada

mensaje enviado.

En este tipo de contención, el mensaje con la más alta prioridad ganaran el acceso

al bus. La latencia de un mensaje dependerá de la prioridad asignada a cada

mensaje (17).

Acceso Múltiple con Escucha de Señal Portadora con prevención de colisiones

(CSMA / CA) ha sido adoptado por los estándares IEEE 802.11 (18). Para mitigar los

24

problemas de equidad que surgen con CSMA / CA, se ha desarrollado una versión

modificada del CSMA con copia de prevención de colisiones (CSMA / CCA) (19).

Figura 15 - Prevención de colisiones

2.2.4.1. Acceso múltiple por división de tiempo (TDMA)

Este sistema es del tipo predecible donde a un nodo se le asigna un tiempo fijo en

donde se le es permitido transmitir. Este sistema define series de repeticiones en

intervalos fijos llamados ventanas, esta ventana de tiempo es dividida en espacios

(Slots) donde a cada nodo se le es permitido transmitir únicamente durante su espacio

de tiempo, así hasta que una nueva repetición llega. Por lo tanto debe existir una

programación de las trasmisiones y los derechos de transmisión. Normalmente no hay

un suscriptor de comunicación principal que controle el procedimiento de

comunicación por tanto es la comunicación es llevada síncronamente entre todos los

nodos de la red (20).

𝑅𝑏 = [1

𝐾−

𝑇𝑔

𝑇𝑓] 𝑅𝑆

𝑏

25

Rb, es la tasa de transferencia por usuario.

Rbs, es la tasa de transmisión de bits del sistema.

Tg, es tiempo libre de transmisión.

Tf, es la duración de tiempo de transmisión (ventana).

K, es el número de slots por cada ventana.

Figura 16 - Acceso múltiple por división de tiempo (TDMA)

2.2.4.1.1. Latencia

Como se ha hecho mención de la latencia de un mensaje cuando se tiene un sistema

de contención de colisiones. Latencia es definida como la diferencian de tiempo en

el que se hace una requisición de transmisión y el tiempo real de transmisión (17). En

un sistema de tiempo real solo los mensajes de alta importancia deben de garantizar

su latencia debido a la prioridad de estos para preservar la funcionalidad del sistema.

26

2.2.5. Modelo de interconexión de sistemas abiertos (OSI)

El modelo OSI se encuentra definido en el estándar ISO/IEC 7498-1 (21), este adopta

un enfoque de capas para el diseño de sistemas de información distribuidos. Cada

capa proporciona un conjunto de servicios. Estos servicios están definidos por

capacidad de hacer alguna forma de comunicación sobre el sistema. Cada servicio

se implementa mediante uno o más procesos, cada uno de los cuales se denomina

una entidad. Las entidades pueden comunicarse con entidades pares en la misma

capa mediante el intercambio de mensajes llamados unidades de protocolo de

datos (PDU) (22).

2.2.5.1. Capas del modelo OSI

Modelo de interconexión de sistemas abiertos (OSI) consiste de siete capas. Estas siete

capas pueden se agrupadas de acuerdo con su principal funcionalidad, donde se

encuentra la capa física, capas de comunicación y finalmente la capa de

aplicación.

27

Figura 17 - Modelo OSI

2.2.5.1.1. Capa física

La capa física maneja los datos como bits sin formato. Esto significa que la PDU para

la capa física es un bit. El objetivo de la capa física es proporcionar una transmisión

transparente de bits desde la capa de enlace de datos del emisor a la capa de

enlace de datos del receptor (23).

Los estados binarios en el PDU se pueden representar de maneras diferentes. La

interfaz de serial de una PC utiliza + 12 V y -12 V, los protocolos automotrices como

CAN (Controller Área Network) o LIN (Local Interconnect Network) utilizan voltajes de

0 V y 5 V y medios como la fibra óptica utilizan representaciones visuales como claro

u obscuro. Los voltajes como los de la PC no son adecuados para un bus, ya que

pueden ocurrir cortocircuitos si varios suscriptores desean transmitir estados binarios

simultáneamente (7).

Por lo tanto las principales funciones de la capa física son:

Conexión física.

28

Transmisión de PDUs.

Secuenciación entre la información física y la información enviada a la capa

de enlace.

2.2.5.1.2. Capas de comunicación

Las capas de comunicación se encargan de preparar la información a transmitir por

la capa de aplicación a ser enviada a través de la capa física y viceversa, prepara

la información entregada por la capa física para que pueda ser utilizada en la capa

de aplicación (7). Las capas que se encargan de la comunicación son:

1. Capa de enlace.

2. Capa de red.

3. Capa de transporte.

4. Capa de sesión.

5. Capa de presentación.

Juntas estas capas cumplen en con las siguientes Funciones:

Controlar el acceso al bus

Direccionamiento de mensajes

Detección y manejo de colisiones

Sincronización del nodo y red

Detección de errores

2.2.5.1.3. Capa de aplicación

La capa de aplicación es responsable de definir los servicios presentados en el usuario

final (24) .

29

2.3. REDES DE COMUNICACIÓN AUTOMOTRICES

La industria automotriz ha aumentado su complejidad debido al incremento del uso

de la tecnología y de sistemas electrónicos. Un sistema general que controle todas las

funcionalidades de un vehículo es básicamente imposible. Uno de los grandes

avances se ha logrado principalmente por medio de la interacción entre varios

sistemas individuales.

Figura 18 - Red automotriz

Así mismo la demanda de seguridad, comodidad, economía y requisitos legales más

estrictos sobre la compatibilidad ambiental de los vehículos solo se puede lograr con

la ayuda de componentes electrónicos adicionales. Por ello el número de sistemas

electrónicos en los vehículos está aumentando continuamente.

30

Figura 19 - Número de ECU en un vehículo (7)

2.3.1. Composición de las redes automotrices

En muchas disciplinas de ingeniería, los sistemas grandes se construyen integrando un

conjunto de subsistemas bien especificados y probados. Es importante que las

propiedades que se han establecido a nivel de subsistema se mantengan durante la

integración del sistema. Tal enfoque constructivo para el diseño del sistema solo es

posible si la arquitectura es modular.

Se dice que una arquitectura es modular con respecto a una propiedad específica si

la integración del sistema no invalidará esta propiedad (25).

Si se analiza la composición de las redes automotrices el principio de modularidad

debe preservarse. Es posible darse cuenta de que cierta información debe de viajar

a través de distintas unidades de control (ECU). Por ejemplo la velocidad del vehículo

es información proveniente de sensores y evaluada por el programa de estabilidad

electrónica (ESP), pero a su vez necesita ser conocida por el sistema de control de

velocidad automático (Control de Crucero), por el tablero de control que muestra la

velocidad o por los sistemas de cálculo del rango de gasolina, etc.

31

Así en una red automotriz no solo las unidades de control electrónico (ECUs) deben

intercambiar información entre ellas que les permita realizar ajustes, de la misma

manera los sensores inteligentes también se consideran sistemas de control

electrónicos ya que preparan la información recolectada del exterior en un circuito

de evaluación y colocan la información en el bus de datos a través de una interfaz

de bus. Por ejemplo los sensores pre-choque.

La coordinación entre los diversos sistemas de control en un vehículo es necesaria

para poder realizar las funciones cruzadas, así mismo se debe de garantizar la

transferencia de una gran cantidad información a un bajo costo. Se han desarrollado

diversos sistemas seriales de bus de datos para este propósito. Donde una unidad de

control puede formar parte de más de un bus de comunicación y utilizar más de un

protocolo de comunicación (26).

El uso de sistemas de bus tiene las siguientes ventajas en comparación con una

solución que utiliza un cableado convencional (7):

Reducción de costos con menos peso y espacio de instalación debido a la

menor cantidad de cables en el mazo de cables

Mayor confiabilidad debido a un menor número de conexiones.

Simplificación del ensamblaje del vehículo durante la producción.

Uso múltiple de señales.

2.3.2. Sistemas de buses en automóviles

Los sistemas de bus en automóviles permiten la comunicación, lo que significa el

intercambio de datos entre las unidades de control electrónico (ECU), sensores

inteligentes y actuadores. Dependiendo de los requisitos respectivos, se utilizan

diferentes sistemas de bus. Los requisitos típicos consisten en la velocidad de datos

requerida, la longitud permitida del mensaje, el número de nodos conectables (ECU),

topologías requeridas, requisitos sobre la capacidad de transmisión determinista y en

32

mayor fiabilidad, disponibilidad o requisitos orientados a la seguridad. Otros requisitos

abordan aspectos de características físicas, como tolerancia a desviaciones de

voltaje, estabilidad de temperatura, impactos en el mazo de cables (compatibilidad

electromagnética (EMC), cable de cobre, plástico o fibra de vidrio, cableado de par

trenzado sin blindaje (UTP) o par trenzado blindado (STP)) y por último, pero no menos

importante, aspectos de costo (27).

2.3.2.1. Requisitos para los sistemas de bus

Como se ha mencionado una unidad de control electrónica (ECU) podrá pertenecer

a una o más de una red dentro del vehículo. Las principales características y requisitos

técnicos para ser tomados en cuenta al momento de seleccionar el bus de datos

donde una unidad de control será conectada deberán ser los siguientes.

2.3.2.1.1. Velocidad de transferencia de datos

Esta variable especifica el volumen de datos que se transmiten durante una unidad

de tiempo. La unidad de datos más pequeña es el bit, y la velocidad de transferencia

de datos generalmente se especifica en bits / segundos (7).

La velocidad de datos requerida depende de la aplicación. Por ejemplo se requiere

una velocidad de transferencia más lenta para sistemas de baja prioridad como la

calefacción que para transferir señales de video en la radio que requieren de una

alta velocidad para poder mostrar el contenido correctamente.

2.3.2.1.2. Inmunidad a interferencias

La interferencia electromagnética y la compatibilidad electromagnética (EMI / EMC)

se convirtieron por primera vez en una preocupación durante las décadas de 1940 y

1950, principalmente como ruido de motor que se llevaba a cabo sobre líneas

33

eléctricas y en equipos sensibles (28). La interferencia no está limitada a escenarios de

comunicación alámbrica. También se observa en redes inalámbricas (29).

Figura 20 - La interferencia electromagnética

En una red automotriz los datos deberían transferirse sin interferencia. Sin embargo,

esto no se puede garantizar en un vehículo de motor debido a los efectos

electromagnéticos. Los requisitos de inmunidad a la interferencia que se establecen

dependen de la relevancia para la seguridad de los sistemas electrónicos en cuestión.

Se necesitan menos requisitos de sistemas de comodidad y conveniencia que el

sistema de frenos antibloqueo (ABS), por ejemplo (7).

Para cumplir con estos requisitos, los mecanismos que detectan errores de transmisión

se incorporan en los protocolos de red. Se puede llevar a cabo una verificación simple

utilizando el bit de paridad, que se calcula en el transmisor y se transmite junto con los

datos útiles. Esto especifica si el primer byte transferido es par o no (7).

34

Otro método es la verificación de suma de verificación (checksum). Si se están

transmitiendo varios bytes de datos, el transmisor calcula un checksum a partir de los

bytes de datos individuales usando una fórmula predefinida y transmite este valor. El

receptor también calcula la suma de verificación de los bytes de datos que se han

recibido y los compara con el checksum. Si se detecta un error de transmisión de

datos, los datos recibidos no se utilizan y se solicita una repetir la transmisión (7).

2.3.2.1.3. Capacidad en tiempo real

Un sistema en tiempo real es un sistema en el que la corrección del comportamiento

del sistema depende no solo de los resultados lógicos de los cálculos, sino también del

instante físico en el que se producen estos resultados. Un sistema en tiempo real

cambia su estado en función del tiempo (25). La duración del intervalo de tiempo

depende de la aplicación. Por ejemplo el sistema de frenos antibloqueo (ABS) debe

reaccionar al bloqueo en unos pocos milisegundos, mientras el motor de la ventanilla

eléctrica debe reaccionar antes de 100 ms (7).

Los requisitos funcionales de los sistemas en tiempo real se refieren a las funciones que

debe realizar. Se agrupan en requisitos de (25):

Recopilación de datos – registro de sus variables de estado.

Requisitos de control digital directo – Cálculo de puntos de ajuste para

actuadores.

Requisitos de interacción hombre-máquina – Informar al usuario el estado del

objeto controlado.

Los requisitos de los sistemas en tiempo real también pueden ser agrupados

dependiendo de su clasificación (7):

Requisito sistemas en tiempo real suaves: el sistema generalmente se ajusta al

tiempo de respuesta especificado, y si estos tiempos se exceden

ocasionalmente, no produce ningún efecto grave.

35

Requisito sistemas en tiempo real duros: la especificación de tiempo debe

cumplirse estrictamente. Si se excedió podría ocasionar problemas en sistemas

críticos para la seguridad. Por ejemplo, si se excedieran los límites de tiempo en

el sistema ABS, las ruedas se bloquearían.

Tabla 1 - Requisitos de los sistemas en tiempo real

En una red automotriz las tolerancias de tiempo se deben cumplir estrictamente para

muchas funciones del sistema de gestión del motor. Los retrasos en la transmisión de

las señales de encendido y encendido pueden provocar vibraciones en el motor e

incluso fallas en el encendido. Estas reacciones deben evitarse, ya que representan

un peligro potencial. Por lo tanto, se deben cumplir estrictos requisitos en tiempo real

de estos sistemas (7).

Sin embargo, esto no necesariamente significa que la transmisión de datos a través

de un sistema de bus también debe estar sujeta a estos requisitos en tiempo real. La

adherencia a los requisitos suaves en tiempo real suele ser suficiente. Si se necesitan

señales de otras unidades de control para funciones, el sistema de bus debe transmitir

los datos a una velocidad de transferencia de datos más rápida y con un retardo de

tiempo menor para que el sistema general cumpla con lo especificado en los

requisitos en tiempo real (7).

Característica Requisitos Duros Requisitos Suaves

Respuesta de tiempo Altamente requerido Deseable

Rendimiento de carga

máxima

Predecible Degradable

Seguridad Crítica No crítica

Tamaño de los datos Pequeños/Mediano Largo

Redundancia Activa Recuperación

Integridad de los datos Termino corto Término largo

Detección de errores Autónomo Asignado

36

2.3.2.1.4. Número de nodos de red

La cantidad máxima de nodos que se integra varía según las diferentes áreas de

operación del vehículo. Varios buses idénticos se pueden usar si es necesario. En 2008

hubo una producción mundial anual de vehículos de aproximadamente de 65-67

millones de vehículos con 10-15 nodos en promedio por vehículo. Este número ha ido

en incremento, en un futuro se estima que en promedio un vehículo contendrá 30-45

nodos (17). La cantidad de nodos conectados a una red dependerá del

equipamiento y la gama del vehículo. Vehículos como el Mercedes clase S ha

incrementado su número de nodos de 5 hasta 55 en un lapso de 14 años.

2.3.3. Mecanismos de control

En la actualidad dos tipos de redes de comunicación son distinguidas. Las actividades

de comunicación en redes activadas por eventos son activadas por la ocurrencia de

algún evento en el ambiente o el sistema. Un nodo solicita la transmisión de un

mensaje si un una interrupción llegado desde un sensor, por ejemplo. Por otro lado si

las actividades son controladas por la progresión global del tiempo se habla de una

red de comunicación activada por el tiempo. Cada nodo envía mensajes en periodos

de tiempo predefinidos. Los dos enfoques de comunicación resultan en significantes

diferencias en sus propiedades no funcionales (30).

2.3.3.1. Comunicación activada por eventos

Los buses activados por eventos se han establecido como un estándar para los

sistemas de control de chasis actuales y la comunicación del tren de potencia en un

vehículo.

La principal ventaja de los sistemas activados por eventos (ET) es su capacidad para

reaccionar rápidamente ante eventos externos asíncronos que no se conocen de

antemano (31). Por lo tanto, muestran un mejor rendimiento en tiempo real en

comparación con los sistemas activados por tiempo. Además, los sistemas activados

37

por eventos poseen una mayor flexibilidad y permiten en muchos casos la adaptación

a la demanda real sin un rediseño del sistema completo (32).

Figura 21 - Control ET

En el muestreo activado por eventos, los eventos de control solo se pueden generar

cuando la red está inactiva (33).

Figura 22 - Eventos de control

38

2.3.3.2. Comunicación activada por tiempo

Las redes de comunicación activadas por el tiempo permiten desenredar la alta

complejidad de los sistemas de gran escala actuales, haciendo que el sistema sea

más controlable debido a un mayor determinismo (32).

En un sistema de comunicación activado por tiempo (TT), el control temporal reside

dentro del sistema de comunicación y no depende del software de aplicación en los

nodos. Los mensajes de estado se transportan desde el nodo emisor al nodo receptor

en puntos de tiempo predeterminados que se almacenan en tablas de planificación

de mensajes dentro de los controladores de comunicación (25).

Por lo tanto las actividades de verificación se vuelven prioridad para garantizar la

seguridad. Diversos trabajos muestran la necesidad de creación de escenarios en

etapas tempranas.

Figura 23 - Control TT

39

2.3.4. Clasificación de los sistemas de bus

Como se ha hecho mención a los diferentes requisitos que debe de cumplir un sistema

de bus la Sociedad de Ingenieros Automotrices (SAE) los ha clasificado en cuatro

clases dependiendo sus requisitos y características. A diferencia de la Organización

Internacional de Normalización (ISO) diferencia los sistemas de bus solo en dos tipos:

Comunicación a baja velocidad (velocidades de bits <125 kbit/s)

Comunicación de alta velocidad (velocidades de bits> 125 kbit/s)

2.3.4.1. Clase A

Sistemas de bus para aplicaciones simples con velocidades de datos bajas de hasta

10 kbit/s. Los mensajes transmitidos son principalmente cortos y se activan con una

baja velocidad de datos. El área de aplicación es relativamente sensible a los costos

y exige, por lo tanto, una tecnología de interconexión bastante barata.

2.3.4.2. Clase B

Sistemas de bus para aplicaciones con velocidades de datos de 10 kbit/s hasta 125

kbit/s.

2.3.4.3. Clase C

Sistemas de bus para aplicaciones, que requieren un comportamiento en tiempo real

con velocidades de datos de 125 kbit/s hasta 1 Mbit/s. En estas aplicaciones, se

requieren dominios a altas velocidades de datos con bajas latencias definidas de

transmisión de datos.

40

2.3.4.4. Clase D

Sistemas de bus para la transmisión de datos de flujos de datos largos con gran ancho

de banda. Estos requisitos prevalecen principalmente en el área de información y

entretenimiento, por ejemplo, para la transmisión de transmisiones de audio / video.

Clase Velocidad de

transferencia

Aplicaciones Protocolo

A 10 Kbits/s Actuadores y sensores. LIN

B 125 Kbits/s Mecanismos de manejo de error ECUs de

manejo de funciones de confort.

CAN baja

velocidad /

FlexRay

C 10 Mbit/s Aplicaciones de tiempo real ECU para el

manejo de funciones de manejo y motor.

CAN alta

velocidad

D >10 Mbit/s ECU para el manejo de funciones

multimedia.

MOST

Tabla 2 - Clasificación del bus de CAN

41

Figura 24 - Buses automotrices

2.3.5. Compuerta de enlace (Gateway)

Debido a que dentro de las redes de comunicación automotrices pueden tener

diferentes protocolos de comunicación los cuales necesitan transmitir información a

través de ellos es uso de Gateways o compuertas de enlace son necesarias para

garantizar que diferentes redes compartan la misma información.

Las compuertas de enlace son combinaciones de hardware y software de red que

conectan dos tipos distintos de redes. Específicamente, pueden conectar dos

sistemas que usan diferentes formatos, protocolos de comunicación o arquitectura. A

diferencia del hardware de conectividad analizado anteriormente en este capítulo,

las compuertas de enlace en realidad re empaquetan información para que otro

sistema pueda leerla. Para lograr esta tarea, las compuertas de enlace deben operar

42

en múltiples capas del modelo de OSI. Se comunican con una aplicación, establecen

y administran sesiones, traducen datos codificados e interpretan datos de

direccionamiento lógico y físico (34).

Una puerta de enlace se puede comparar con un intérprete que recibe información

de una red, los traduce y los pasa a otra. Una puerta de enlace es un nodo que lee

los datos que transmiten las redes y los convierte a otro formato. El uso de compuertas

de enlace permite, por lo tanto, intercambiar información entre diferentes redes (7).

Figura 25 - Puerta de enlace

43

2.4. APLICACIONES EN VEHÍCULOS

Los sistemas presentes en un vehículo se pueden dividir en cuatro grandes

agrupaciones visas desde un punto electrónico.

Transmisión

Chasis

Interior

Telemática

Los sistemas de transmisión y chasis, recaen principalmente en las aplicaciones en

tiempo real. En los sistemas de interior se encuentran los sistemas múltiplex y de

creación de redes. Las aplicaciones multimedia, de información y entretenimiento

corresponden a los sistemas telemáticos.

2.4.1. Sistemas de transmisión y chasis

Los sistemas de Transmisión y Chasis están asignados a buses clase C, con velocidad

de transferencia de datos de 500 kBaud (high-speed CAN). Estas redes son activadas

por eventos.

Algunos ejemplos son:

Sistema de control electrónico de diésel (EDC)

Sistemas de frenos antibloqueo (ABS)

Programa de estabilidad electrónica (ESP)

Sistemas de control activo del chasis (ABC)

Sistemas de control de crucero adaptativo (ACC)

2.4.2. Sistemas de confort y comodidad

Los sistemas de interior son sistemas para el confort y comodidad, generalmente clase

B con una velocidad de transferencia de datos de 125Kbits/s (CAN Baja velocidad) o

CAN single-wire a 33 Kbits/s.


Aire Acondicionado (AC)

44

Módulos de memoria para asientos (MSM)

Módulos de las puertas

Módulos climatización de asientos (CSM)

Módulos de Iluminación

Si la velocidad de transferencia caen a menos de 20 kBit / s, el LIN de bajo costo se

usa con mayor frecuencia. Las principales aplicaciones son la transferencia de

información del interruptor o la activación de actuadores.

2.4.3. Sistemas multimedia

Los sistemas telemáticos enfocan sus funciones en sistemas multimedia. Debe hacerse

una distinción entre los datos de control y los datos de audio / video en las redes

multimedia. Las tasas de transferencia de hasta 125 Kbit/s son suficientes para las

tareas de control, lo que significa que se puede usar el bus CAN de baja velocidad.

La transmisión directa de datos de audio o video requiere tasas de transferencia

extremadamente altas de más de 10 Mbit/s. El bus MOST o Ethernet se usan para este

propósito.


Radio (CSM)

Panel de instrumentos (IPC)

Pantalla frontal (HUD)

2.4.4. Ejemplo de redes vehiculares

Las topologías de las redes de comunicación pueden diferir considerablemente según

el equipo del vehículo. En algunos casos, diferentes fabricantes de automóviles utilizan

diferentes sistemas de bus para la comunicación.

45

Tabla 3 - Descripción general de buses

2.5. SISTEMAS DE BUSES

2.5.1. CAN

2.5.1.1. Introducción

En 1983 Robert Bosch GmbH comenzó a desarrollar un proyecto interno en Alemania

para conectar todos los componentes electrónicos en un vehículo automotriz. En

1986, introdujeron por primera vez en el Congreso de la Sociedad de Ingenieros

Automotrices (SAE) el concepto de Red de Área de Controlador (CAN) basada en

un sistema de bus (35). El protocolo CAN se basa en el principio de la técnica de

transmisión de difusión en la donde los datos a transmitir en una red se envían a todos

los nodos. Los nodos miran dentro del paquete de datos para ver si el mensaje fue

CAN Alta

VelocidadCAN Baja Velocidad LIN TTP MOST Bus Flexray

DefiniciónRed de Área

ControladaRed de Área Controlada

Red de interconexión

local

Protocolo de

activación por

tiempo

Sistemas de

Transporte

Orientados a los

Medios

Nombre Propio

Tipo de BUS Convencional Convencional ConvencionalConvencional y

ÓpticoÓptico Convencional y Óptico

Domino Transmisión Confort Confort Redes de SeguridadMultimedia y

InfotainmentTodos los Dominios

Aplicaciones

Control del

motor,

transmisión y

redes ABS / ESP

Confort y ComodidadAplicaciones sencillas

de bajo costo

Redes en entornos

relacionados con la

seguridad como

frenos

Transmisión de audio

y video

Aplicaciones simples

relacionadas con

seguridad

Topología Bus Bus Bus Estrella Anillo Estrella

Número

Máximo de

Nodos

10 24 16 - 6422 (Teóricamente

hasta 2,048)

Mecanismo

de Control

Activada por

EventosActivada por Eventos Activada por Tiempo

Activada por

Tiempo

Activada por

Tiempo/Eventos

Activada por

Tiempo/Eventos

Número de

LíneasPar Cruzado Par Cruzado Cable Simple Par Cruzado Fibra óptica Par Cruzado

Estándar ISO 1198 ISO 11 519-2Paquete de

especificaciones LIN

Protocolo de

activación por

tiempo TTP / C

Especificación MOST

Especificación del

protocolo del sistema

de comunicaciones

FlexRay

Clasificación

SAEClase C Clase B Clase A - - -

10 Mbit/s Max. 22.5 Mbit/s 10 - 20 Mbit/sVelocidad de

Transferencia10 kbit/s - 1Mbit/s Max. 125 kbit/s Max. 20 kbit/s

46

creado para ellos. Si no, simplemente se descarta el paquete. El nodo destinatario de

los datos los descarga y los procesa (36).

Algunas de estas características hacen la velocidad CAN hasta 1 Mb/s. Esto es muy

útil en sistemas de control mecatrónicos en tiempo real que pueden permitir una

latencia muy baja. Debido a la alta velocidad ofrecida por CAN, se puede lograr una

baja latencia y, por lo tanto, un control eficiente en el tiempo. Los mensajes CAN

tienen una longitud corta por lo tanto hay una demora mínima en la recepción de

mensajes. La combinación de alta velocidad y longitud de mensaje corto da como

resultado un retardo bajo, debido a lo cual CAN se implementa en sistemas de control

mecatrónicos que tienen una tolerancia muy baja para retrasos (37). CAN es

básicamente un mecanismo de protocolo desencadenado por evento (ETP). Esto

significa que la transmisión de datos se inicia sólo cuando se produce un evento

específico. Debido a esta propiedad, el ancho de banda disponible se aprovecha al

máximo debido a la carga mínima en el sistema de bus

El sistema de direccionamiento se basa en identificadores de mensajes en lugar de

en direcciones físicas para nodos. Cada mensaje CAN tiene un identificador único

que asigna una prioridad al mensaje respectivo basado en el valor binario del

identificador. A un valor binario inferior se le asigna una prioridad más alta y viceversa.

Cualquier nodo puede transmitir un mensaje. Todos los demás nodos se preparan para

recibir, los nodos que no tienen uso para el mensaje lo descartan (35).

2.5.1.2. Historia de CAN

A comienzos de 1980’s muchos sistemas electrónicos comenzaron a aparecer en la

industria automotriz. Las compañías manufactureras de vehículos se vieron

interesados en comunicar estos sistemas electrónicos entre sí, para resolver esta

problemática protocolos como I2C (Circuito Inter-integrado) fueron implementados,

pero este tipo de comunicación no proporcionaba soporte para comunicaciones

multi-maestro, así como la velocidad de transferencia y la seguridad de la información

transmitida eran inadecuadas utilizando este tipo de protocolos. Consecuentemente

debido la ausencia de un bus que fuera capaz de proveer una comunicación veloz

multi-maestro que pudiera operar correctamente en distancias y con un bajo costo,

47

en 1983 Robert Bosch GmbH tomo la decisión de desarrollar un protocolo de

comunicación orientado a sistemas distribuidos que operará en tiempo real, el

desarrollo de CAN había comenzado (17).

El enfoque principal de ese desarrollo fue un sistema de comunicación entre un

número de ECUs dentro de un vehículo Mercedes-Benz. El involucramiento de esta

manufacturera automotriz así como la manufacturera de semiconductores Inter y

algunas universidades ayudaría al desarrollo exitoso de CAN.

El estándar de CAN fue introducido en 1986 durante el congreso de la SAE en Detroit,

Michigan. Los primeros chips controladores de CAN fue el Intel 82526 y el Phillips

82C200, introducidos en 1987 (15).

1983 Comienza el desarrollo de CAN en Robert Bosch GmbH.

1985 Especificación de CAN V1.0.

1986 Comienza la estandarización ISO.

1987 Introducción del primer prototipo del circuito integrado de CAN.

1989 Comienzo de la primera aplicación industrial.

1991 Especificación de CAN extendido 2.0.

Lanzamiento del primer vehículo - Mercedes class S, 5 unidades comunicadas

1992 Creación de CiA (Can en Automatización).

1993 Creación de grupo OSEK (Sistemas abiertos y sus interfaces para electrónicos en

vehículos de motor).

1994 Primera estandarización ISO.

1995 Grupo de trabajo en los Estados Unidos con la SAE.

1996 CAN es aplicado en la mayoría de sistemas de control del motor.

1997 Todos los mayores productores de chips venden componentes de CAN.

1998 Nuevos set de estándares (Diagnósticos, conformidad, etc.).

1999 Fase de desarrollo de CAN activado por tiempo (TTCAN).

2000 Explosión de CAN en todos los equipamientos vehiculares.

2001 Introducción de CAN activado por tiempo en tiempo real (TTCAN).

48

2003 CAN es utilizado por todas las compañías automotrices.

2008 La producción anual de vehículos es de 65-67 millones con 10-15 nodos de CAN en

promedio.

Tabla 4 - Principales acontecimientos en los primeros 20 años de CAN

2.5.1.3. Aplicaciones

CAN es el estándar de facto en una gran variedad de sistemas embebidos de red. El

desarrollo temprano de CAN fue respaldado principalmente por la industria del

vehículo: CAN se encuentra en una variedad de automóviles, camiones, barcos,

naves espaciales y otros tipos de vehículos (38). Así el protocolo de CAN es

mayormente utilizado en el sector automotriz, alrededor de 80% de las aplicaciones

desarrolladas basadas en CAN pertenecen a este dominio (17). Las aplicaciones

emergentes de CAN las cuales están ganando terreno van desde la industria la

automatización y las industrias de manufactura. Para mencionar algunos, se puede

citar por ejemplo autos de pasajeros, camiones y autobuses, productos electrónicos

marinos, automatización de fábricas, control de maquinaria industrial y control no

industrial (39).

Alguno de los ejemplos de las aplicaciones dentro de un vehículo, son:

Sistema de gestión del motor.

Control de transmisión electrónica.

Sistemas de estabilización de vehículos.

Tablero de instrumentos.

Control del sistema de aire acondicionado.

Ajuste del asiento.

Unidad de ventana de poder.

Control del techo corredizo.

Ajustador de espejo.

Sistema de iluminación.

Control del sistema de navegación.

49

Debido a los procesos rápidos involucrados en el área de gestión del motor, la

información se requiere mucho más rápido comparada con el área de comodidad /

conveniencia donde los sistemas. Como resultado de estos requisitos diferentes, se

utilizan buses con diferentes velocidades de datos que ofrecen una relación costo-

beneficio óptima para el campo de aplicación en cuestión. Se hace una distinción

entre los buses CAN de alta velocidad y baja velocidad (7).

2.5.1.4. Principios operacionales de CAN

2.5.1.4.1. Propiedades de CAN

Las principales propiedades de la estructura del protocolo de CAN son (40):

Priorización de mensajes.

Garantiza los tiempos de latencia.

Configuración flexible.

Multi-distribución de recepción con tiempos de sincronización.

Consistencia de datos.

Comunicación multi-maestro.

Detección de errores.

Auto-retransmisión de mensajes corruptos.

Distinción entre errores temporales y fallas permanentes.

2.5.1.4.2. Estructura de un nodo de CAN

En el modelo de referencia ISO / OSI, la especificación CAN original, desarrollada por

Robert Bosch GmbH, cubre solo las capas de enlace Físico, de Transferencia y de

Datos. Más tarde, ISO proporcionó su propia especificación del protocolo CAN, con

detalles adicionales para la implementación de la capa física (41).

En términos generales, el objetivo de la capa física es definir la codificación de bits en

señales con características físicas definidas. La especificación del medio físico de

transmisión únicamente incluye los niveles de señal requerida (corriente / voltaje) (41).

50

La capa de enlace de datos consiste en las subcapas de Control de Enlace Lógico

LLC y de Control de Acceso al Medio. La subcapa LLC proporciona todos los servicios

para la transmisión de una secuencia de bits desde una fuente a un destino. En

particular, define (41):

Servicios para transferencia de datos y solicitud remota de datos.

Condiciones en las que se deben aceptar los mensajes recibidos, incluido el

filtrado de mensajes.

Mecanismos para la gestión de la recuperación y el flujo (notificación de

sobrecarga).

La subcapa MAC (Control de Acceso al medio) se considera como el núcleo del

protocolo CAN. La subcapa MAC es responsable del encuadre del mensaje, el

arbitraje del medio de comunicación, la gestión del acuse de recibo y la detección y

señalización de errores (41).

La capa de objetos está relacionada con el filtrado de mensajes, así como con el

estado y el manejo de mensajes (40).

51

Figura 26 - Estructura del nodo de CAN

2.5.1.4.3. Mensajes

La información del bus se envía en forma de mensajes de longitud diferente pero

limitada. Cuando el bus está libre, cualquier nodo conectado puede comenzar a

transmitir un nuevo mensaje (40).

52

2.5.1.4.4. Enrutamiento de información

En los sistemas CAN, un nodo no utiliza ninguna información sobre la configuración del

sistema (40).

2.5.1.4.5. Flexibilidad del sistema

Los nodos se pueden agregar a la red CAN sin requerir ningún cambio en el software

o hardware de ningún nodo o capa de aplicación (40).

2.5.1.4.6. Enrutamiento de mensajes

El contenido de un mensaje se describe mediante un Identificador. El Identificador no

indica el destino del mensaje, sino que describe el significado de los datos, de modo

que todos los nodos en la red puedan decidir mediante el filtrado de mensajes si los

datos serán o no accionados por ellos (40).

2.5.1.4.7. Multidifusión

Como consecuencia del concepto de filtrado de mensajes, cualquier número de

nodos puede recibi

2.5.1.4.8. Consistencia de los datos

Dentro de una red CAN se garantiza que un mensaje sea aceptado simultáneamente

por todos los nodos o por ningún nodo. Por lo tanto, la coherencia de los datos es una

propiedad del sistema lograda mediante los conceptos de multidifusión y mediante

el manejo de errores (40).

2.5.1.4.9. Velocidad de bits

La velocidad de CAN puede ser diferente en diferentes sistemas. Sin embargo, en un

sistema dado, la tasa de bits es uniforme y fija (40).

53

2.5.1.4.10. Prioridades

El identificador define una prioridad de mensaje estático durante el acceso al bus

(40).

2.5.1.4.11. Solicitud remota de datos

Al enviar un mensaje remoto, un nodo que requiera datos puede solicitar otro nodo

para enviar el marco de datos correspondiente. El mensaje de datos y el mensaje

remoto correspondiente tienen el mismo identificador (40).

2.5.1.4.12. Multi-maestro

Cuando el bus está libre, cualquier nodo puede comenzar a transmitir un mensaje. El

nodo con el mensaje de mayor prioridad que se transmitirá gana acceso al bus (40).

2.5.1.4.13. Direccionamiento basado en contenido

A diferencia de otras redes, CAN no direcciona los nodos de red individualmente, sino

a los mensajes que se han enviado. Cada mensaje tiene un identificador único. El

identificador clasifica el contenido del mensaje (por ejemplo, la velocidad del motor

o la posición de la ventana de encendido). Por lo tanto, una estación puede transmitir

un mensaje a todas las demás estaciones (método de multidifusión o de difusión).

Estas estaciones leen solo aquellos mensajes cuyos identificadores están

almacenados en su lista de aceptación (filtrado de mensajes). De esta manera, cada

estación decide por sí misma si necesita o no un mensaje enviado en el bus. Con 11

bits en el formato estándar, es posible distinguir entre 2,048 mensajes CAN diferentes;

en el formato extendido, este número asciende a más de 536 millones (7).

La ventaja de este método de direccionamiento es que los nodos de red no requieren

ninguna información sobre la configuración del sistema y, por lo tanto, son libres de

operar de forma totalmente independiente entre sí. Esto da como resultado un

sistema completo altamente flexible, que facilita la administración de las variantes de

los equipos. Si un nodo requiere nueva información que ya está en el bus, todo lo que

54

necesita hacer es llamarla desde el bus. Es posible integrar estaciones adicionales en

el sistema (siempre que sean receptores) sin tener que modificar las estaciones

existentes (7).

Figura 27 - Direccionamiento y filtrado de mensajes

2.5.1.4.14. Arbitraje

Cada nodo de una red CAN puede iniciar la transmisión de un mensaje tan pronto

como el bus esté libre (42). Si dos o más nodos comienzan a transmitir mensajes al

mismo tiempo, el conflicto de acceso al bus se resuelve mediante un arbitraje bit a bit

utilizando el identificador (40). Para evitar que los nodos destruyan los datos

transmitidos entre sí, el mensaje con la más alta prioridad de todos los mensajes que

se arbitran simultáneamente se determina en una fase de arbitraje. Al mensaje con el

valor más bajo de identificador de mensaje se le asigna la más alta prioridad (43).

Cada nodo monitorea el nivel de señal en el bus durante la fase de arbitraje. La fase

de arbitraje consiste en la transmisión del identificador de mensaje y del bit de

retransmisión remota (RTR). Si un nodo detecta un nivel de bus dominante, aborta el

proceso de transmisión de inmediato, un mensaje con mayor prioridad se transmite al

mismo tiempo y entra en el estado de recepción (43).

55

Figura 28 - Arbitrariedad de CAN

2.5.1.4.15. Secuencia de transmisión y recepción de datos

Secuencia de transmisión de datos en el bus CAN (44).

1) Inicialmente el bus está inactivo.

2) Todos los nodos transmitirán datos.

3) El nodo de prioridad más alta tendrá acceso al bus y transmitirá los

datos, otros nodos entrarán en el modo de recepción.

4) El nodo de transmisión esperará el acuse de recibo.

5) Si se recibe acuse de recibo, se envía el siguiente mensaje, de lo

contrario se espera y vuelve a enviar el mismo mensaje.

6) Se envía bit EOF (Fin del mensaje) y se ingresar al modo de recepción.

Secuencia de recepción de datos en el bus CAN (44).

1) Si el mensaje se recibe sin errores (por cálculos CRC) se envía el acuse

de recibo.

2) Si el mensaje está dañado, se espera al mensaje corregido.

3) Se inicia el proceso del controlador de CAN.

56

4) Se enviar el mensaje recibido al mecanismo de filtro de Aceptación

5) Si se acepta el mensaje, envíelo a la memoria FIFO del controlador de

lo contrario descarta el mensaje.

6) Alerte el procesador sobre el mensaje válido.

2.5.1.4.16. Integridad de los datos

Para lograr una integridad muy alta de la transferencia de datos, se implementan

potentes medidas de detección de errores, señalización y auto-verificación en cada

nodo CAN (40).

2.5.1.4.17. Detección de errores

Para detectar errores, se han tomado las siguientes medidas (40):

Monitoreo (cada transmisor compara los niveles de bit detectados en el bus

con los niveles de bit que se transmiten)

Comprobación de redundancia cíclica (CRC)

Verificación del mensaje

Rendimiento de detección de errores

2.5.1.4.18. Error de señalización y tiempo de recuperación

Los mensajes dañados son marcados por cualquier nodo que detecta un error. Tales

mensajes se cancelan y se retransmiten automáticamente. El tiempo de recuperación

desde la detección de un error hasta el inicio del siguiente mensaje es como máximo

de 29 bits, siempre que no haya más errores (40).

2.5.1.4.19. Confinamiento de fallas

Los nodos CAN son capaces de distinguir entre perturbaciones cortas y fallas

permanentes. Los nodos defectuosos son apagados (40).

57

2.5.1.4.20. Conexiones

El enlace de comunicación en serie CAN es un bus al que se pueden conectar varios

nodos. Este número no tiene límite teórico. Prácticamente, la cantidad total de nodos

estará limitada por los tiempos de demora y / o cargas eléctricas en la línea del bus

(40).

2.5.1.4.21. Canal único

El bus consiste en un único canal bidireccional que transporta bits. A partir de estos

datos, la información de re-sincronización se puede derivar (40).

2.5.1.4.22. Valores de bus

El bus puede tener uno de dos valores complementarios: dominante o recesivo.

Durante la transmisión simultánea de bits dominantes y recesivos, el valor de bus

resultante será dominante. El nivel dominante estaría representado por un "0" lógico y

el nivel recesivo por un "1" lógico (40).

2.5.1.4.23. Reconocimiento

Todos los receptores verifican la consistencia del mensaje que se recibe y confirmará

un mensaje consistente (40).

2.5.1.5. Mensajes de CAN

Existen cuatro tipos mensajes de CAN: Mensajes de datos, Mensajes remotos,

Mensajes de error y Mensaje de sobrecarga (45).

Los mensajes de datos son transmitidos cuando un nodo desea transmitir datos

normales dentro de la red (45).

Los mensajes remotos se pueden describir como una petición de información, un nodo

que transmite este mensaje se encuentra preguntando algún tipo de información

descrita en el identificador. El nodo con la información disponible deberá responder

enviando esta información dentro de la red (45).

58

Cualquier unidad que detecte un error en el bus transmitirá un mensaje de error (45).

Un mensaje de sobrecarga es utilizado para proveer un retardo extra entre los datos

o mensajes remotos enviados (45).

2.5.1.6. Mensaje de datos

Los mensajes de datos se utilizan para transmitir información entre un nodo fuente y

uno o más nodos receptores. Los mensajes de datos no usan direccionamiento

explícito para identificar los receptores de mensajes. En cambio, cada nodo receptor

indica los mensajes que se recibirán en función de su contenido de información, el

cual está codificado en el campo Identificador (41).

Hay dos versiones del protocolo de CAN: CAN 2.0A (CAN estándar) con

identificadores de 11 bits y CAN 2.0B (CAN extendido) con identificadores de 29 bits.

Para las comunicaciones en el vehículo, solo se utiliza CAN 2.0A ya que proporciona

un número suficiente de identificadores (46). El protocolo CAN utiliza el identificador

de mensaje como una prioridad para determinar qué mensaje, entre los

contendientes para el bus, se transmitirá a continuación (47).

Los mensajes estándar y extendidos se pueden transmitir en el mismo bus por

diferentes nodos o por el mismo nodo. La parte de arbitraje del protocolo funciona

independientemente de la versión de identificador, permitiendo que los mensajes de

identificador de 29 bits se transmiten en la misma red junto con otros con un

identificador de 11 bits (41).

2.5.1.6.1. Formato 2.0A

El estándar de CAN 2.0 A consiste de siete campos:

59

Figura 29 - Formato CAN 2.0A

2.5.1.6.1.1. Inicio del mensaje (SOF)

Este es un bit dominante (0), indica el comienzo de un mensaje (45) y sincroniza todo

participante de la red (48). Un nodo sólo puede iniciar la transmisión cuando el bus

está inactivo. Todos los nodos tienen que sincronizarse con el flanco causado por el

inicio del mensaje del nodo iniciador de la primera transmisión (40).

2.5.1.6.1.2. Campo de arbitraje

El campo de arbitraje contiene el identificador y un bit de solicitud de retransmisión

remota (RTR). Durante la transmisión de este campo, el transmisor comprobado para

cada bit, si todavía es elegible para transmitir o si envía otra estación con mayor

prioridad. El bit de solicitud de retransmisión remota se usa para distinguir mensajes de

datos o mensajes remotos (48).

Figura 30 - Campo de arbitraje

2.5.1.6.1.3. Campo de control

El Campo de control contiene codificado el número de bits de datos en el Campo de

datos (48). La longitud del Identificador es de 11 bits. Estos bits se transmiten en el orden

60

de ID10 a ID0. El bit menos significativo es ID0. Los 7 bits más significativos no deben ser

todos recesivos (40).

El campo de control consta de seis bits. Incluye el código de longitud de datos y dos

bits reservados para futuras expansiones. Los bits reservados deben enviarse como

dominantes. Los receptores aceptan bits dominantes y recesivos en todas las

combinaciones (40).

Figura 31 - Campo de control

El número de bytes en el campo de datos se indica con el código de Longitud de

datos. Este código de longitud de datos tiene 4 bits de ancho y se transmite dentro

del campo de control. Los bits DLC pueden codificar longitudes de datos de 0 a 8

bytes; otros valores no están permitidos (40).

Código de Longitud No.

Bytes DLC3 DLC2 DLC1 DCL0

d d d d 0

d d d r 1

d d r d 2

d d r r 3

d r d d 4

d r d r 5

d r r d 6

d r r r 7

r d d d 8

d = dominante (0)

r = recesivo (1)

Tabla 5 - Código de longitud de datos

61

2.5.1.6.1.4. Campo de datos

El campo de datos consiste en los datos que se transferirán dentro de un marco de

datos. El Campo de datos lleva entre 0 y 8 bits de datos, cada uno de los cuales

contiene 8 bits, el bit más significativo se transfiere primero (40). La longitud de datos

0 se puede usar para sincronizar procesos distribuidos (48).

Tabla 6 - Mapa de memoria de mensaje de datos

2.5.1.6.1.5. Suma de comprobación (CRC)

El campo de suma de comprobación sirve para detectar posibles errores de

transmisión o mal funcionamiento (48).

El campo CRC contiene una secuencia CRC seguida de un delimitador CRC.

1.1.1.1.1.1.1. Secuencia CRC

La secuencia comprobación se deriva de un código de redundancia cíclica que se

adapta mejor a las tramas con un conteo de bits inferior a 127 bits (40).

Para realizar el cálculo de CRC, el polinomio a dividir se define como el polinomio

cuyos coeficientes están dados por la secuencia de bits que consiste en Inicio del

mensaje, Campo de arbitraje, Campo de control, Campo de datos (si está presente)

y, para el 15 coeficientes más bajos, por 0. Este polinomio se divide (los coeficientes se

calculan en módulo-2) por el polinomio generado (40):

X15 + X14 + X10 + X8 + X7 + X4 + X3 + 1

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0

Byte 0 7 6 5 4 3 2 1 0

Byte 1 15 14 13 12 11 10 9 8

Byte 2 23 22 21 20 19 18 17 16

Byte 3 31 30 29 28 27 26 25 24

Byte 4 39 38 37 36 35 34 33 32

Byte 5 47 46 45 44 43 42 41 40

Byte 6 55 54 53 52 51 50 49 48

Byte 7 63 62 61 60 59 58 57 56

62

El residuo de esta división de polinomios es la secuencia de CRC transmitida por el bus.

Para implementar esta función, se puede usar un registro de desplazamiento de 15

bits CRC_RG (14: 0). Si NXTBIT denota el siguiente bit del flujo de bits, dado por la

secuencia de bits desechados desde el inicio del cuadro hasta el final del campo de

datos, la secuencia del CRC se calcula de la siguiente manera (40):

CRC_RG = 0 //Inicializa el registro de desplazamiento

REPEAT

CRCNXT = NXTBIT EXOR CRC_RG (14)

CRC_RG (14:1) = CRC_RG (13:0) //Desplazamiento a la izquierda...

CRC_RG (0) = 0 //...Primera posición

IF CRCNXT THEN

CRC_RG (14:0) = CRC_RG (14:0) EXOR (4599 hex)

ENDIF

UNTIL (CRC SEQUENCE starts or there is an ERROR condition)

Después de la transmisión y/o recepción del último bit del campo de datos, CRC_RG

(14: 0) contiene la secuencia de CRC (40).

1.1.1.1.1.1.2. Delimitador de CRC

La Secuencia CRC es seguida por el Delimitador CRC que consiste en un único bit

recesivo (1) (40).

2.5.1.6.1.6. Campo de reconocimiento (ACK)

El campo ACK tiene dos bits de longitud y contiene el campo ACK y el delimitador

ACK.

Este campo contiene una señal de confirmación de todos los suscriptores que han

recibido el mensaje correctamente. Un receptor que ha recibido un mensaje válido

informa esto correctamente al transmisor enviando un bit dominante en el ACK Slot

(es decir, envía ACK) (40).

63

1.1.1.1.1.1.3. Campo ACK

Todos los nodos que han recibido la secuencia CRC coincidente informan esto dentro

del campo ACK sobrescribiendo el bit recesivo del transmisor por un bit dominante

(40).

1.1.1.1.1.1.4. Delimitador de ACK

El delimitador ACK es el segundo bit del campo ACK y tiene que ser un bit recesivo.

Como consecuencia, el campo ACK está rodeada por dos bits recesivos (delimitador

CRC y delimitador ACK) (40).

2.5.1.6.1.7. Fin del mensaje

Cada mensaje de datos y mensaje remoto está delimitado por una secuencia de

indicador que consta de siete bits recesivos (40).

2.5.1.6.2. Formato 2.0B

El formato de CAN 2.0B provee un identificador de 29 bits, a diferencia del formato

2.0A el cual tiene un identificador de 1 bits. Los mensajes en versión 2.0B tienen un

formato extendido (45). Las diferencias son:

En la versión 2.0B el campo de arbitraje contiene dos campos de identificador.

El primero es de 11 bits de longitud el propósito de es la compatibilidad con el

versión 2.0A, el identificador en este primer campo es conocido como

identificador base. El segundo campo es el identificador extendido el cual es

de 18 bits de longitud, para dar como total 29 bits de longitud (45).

La distinción entre los dos formatos es realizada por in bit de identificación de

extensión (IDE) (45).

Un bit es incluido en el campo de arbitraje denominado sustituto de solicitud

remota (SRR). El bit SRR es siempre enviado con un bit recesivo para asegurar

durante la arbitrariedad de un mensaje de datos estándar y un mensaje de

64

datos extendido, el mensaje estándar siempre tendrá la prioridad si ambos

mensajes tienen en mismo identificador base (45).

El resto de campo es formato 20.B son idénticos al formato 2.0A (45).

Figura 32 - Formato CAN 2.0B

2.5.1.7. Mensaje remoto

Un nodo que actúa como receptor para ciertos datos puede estimular al nodo fuente

a transmitir los datos enviando un mensaje remoto (40).

Un mensaje remoto se compone de seis campos de bits diferentes (40):

Inicio de mensaje.

Campo de arbitraje.

Campo de control.

Campo de suma de comprobación CRC.

Campo Reconocimiento ACK.

El bit RTR de un mensaje remoto siempre es recesivo (40).

No hay un campo de datos en un mensaje remoto, independientemente del valor del

código de longitud de datos del mensaje de datos correspondiente, se le puede

asignar cualquier valor dentro del rango admisible de 0 a 8 (40).

La polaridad del bit RTR indica si un mensaje transmitido es un mensaje de datos

(dominante de bit RTR) o un mensaje remoto (bit recesivo de RTR) (40).

65

Figura 33 - Estructura de un mensaje remoto

2.5.1.8. Mensaje de error

Un mensaje de error consta de dos campos distintos. El primer campo viene dado por

la superposición de banderas de error aportados por diferentes nodos. El segundo

campo es el delimitador de errores (40).

Para terminar un cuadro de error correctamente, un nodo en error puede necesitar

que el bus esté inactivo en el bus durante al menos tres tiempos de bit (40).

2.5.1.8.1. Indicador de error

Existen dos formas de banderas de error (40):

1) El indicador de error-activo, consta de seis bits dominantes consecutivos.

2) El indicador de error-pasivo, consta de seis bits recesivos consecutivos a menos que

se sobrescribe con bits dominantes de otros nodos.

Si nodo detecta una condición de error lo señala mediante la transmisión de un

indicador de error activo. La bandera de error no aplica la ley de relleno de bits, se

aplica a todos los campos desde el Inicio del mensaje al Delimitador CRC. Como

consecuencia, todos los otros nodos detectan una condición de error y cada uno

comienza a transmitir un mensaje de error. De este modo la secuencia de bits resulta

de una superposición de diferentes banderas de error transmitidas por nodos

individuales. La longitud total de esta secuencia varía entre un mínimo de seis y un

máximo de doce bits (40).

Si un nodo en error-pasivo detecta una condición de error señala esto transmitiendo

un indicador de error-pasivo. El nodo en error-pasivo espera seis bits consecutivos de

igual polaridad, comenzando al inicio del indicador de error-pasivo. El indicador de

error-pasivo está completo cuando se han detectado estos seis bits iguales (40).

66

2.5.1.8.2. Delimitador de error

El Delimitador de error consta de ocho bits recesivos. Después de la transmisión de un

indicador de Error, cada nodo envía bits recesivos y supervisa el bus hasta detectar

un bit recesivo. Luego comienza a transmitir siete bits más recesivos (40).

Figura 34 - Formato de un mensaje de error

El mensaje de Sobrecarga contiene dos campos de bit, la bandera de sobrecarga y

el delimitador de sobrecarga. Existen dos tipos de condiciones de sobrecarga, que

conducen a la transmisión de una bandera de sobrecarga (40):

1) Cuando las condiciones internas de un receptor son tales que el receptor requiere

un retraso del siguiente mensaje de datos o mensaje remoto,

2) En la detección de un bit dominante durante la intermisión.

Un mensaje de sobrecarga resultante de la primera condición de sobrecarga sólo

puede comenzar en el primer bit de una intermisión esperada, mientras un mensaje

de sobrecarga resultante de la segunda condición de sobrecarga comienza un bit

después de detectar el bit dominante (40).

67

Figura 35 - Formato de un mensaje de sobrecarga

Como máximo, se pueden generar dos mensajes de sobrecarga para retrasar el

siguiente mensaje de datos o mensaje remoto (40).

2.5.1.8.3. Bandera de sobrecarga

La bandera de sobrecarga consta de seis bits dominantes. La forma general

corresponde al indicador de error-activo (40).

La forma de la bandera de sobrecarga destruye la forma fija del campo intermisión.

Como consecuencia, todos los otros nodos también detectan una condición de

sobrecarga y cada uno comienza a transmitir una bandera de sobrecarga. Si un bit

dominante es detectado durante el tercer bit de la intermisión localmente en algún

nodo, los otros no interpretarán correctamente el indicador de sobrecarga, pero

interpretarán el primero de estos seis bits dominantes como el inicio del mensaje (40).

2.5.1.8.4. Delimitador de sobrecarga

El delimitador de sobrecarga consta de ocho bits recesivos. El delimitador de

sobrecarga tiene la misma forma que el delimitador de errores. Después de la

transmisión de un indicador de sobrecarga, el nodo supervisa el bus hasta detectar

una transición de un bit dominante a un bit recesivo. En este momento, cada nodo

68

de bus ha terminado de enviar su bandera de sobrecarga y todos los nodos

comienzan la transmisión de siete bits recesivos más en coincidencia (40).

2.5.1.9. Espacio entre menajes

Los mensajes de datos y los mensajes remotos están separados de los mensajes

anteriores, por un campo llamado espacio entre mensajes. Por el contrario, los

mensajes de sobrecarga y los mensajes de error no van precedidas de un espacio

entre mensajes y múltiples mensajes de sobrecarga no están separadas por un

espacio entre mensajes. El espacio entre mensajes contiene los campos de bit

Intermisión y bus inactivo (40).

Figura 36 - Espacio entre mensajes para nodos no pasivos

Figura 37 - Espacio entre mensajes para nodo en error

Figura 38 - Formato del espacio entre mensajes

69

2.5.1.9.1. Intermisión (Pausa)

Consta de tres bits recesivos.

Durante la intermisión, ningún nodo puede iniciar la transmisión de un mensaje de

datos o mensaje remoto. La única acción permitida es la señalización de una

condición de sobrecarga (40).

2.5.1.9.2. Bus inactivo

El período de inactividad del bus puede ser de longitud arbitraria. El bus se reconoce

como libre, y cualquier nodo que tenga algo que transmitir puede acceder al bus. Un

mensaje, pendiente durante la transmisión de otro mensaje, se inicia en el primer bit

después de intermisión. La detección de un bit dominante en el bus se interpreta

como inicio del mensaje (40).

2.5.1.10. Suspensión de transmisión

Después de que un nodo en error-pasivo ha transmitido un mensaje, envía ocho bits

recesivos después de la intermisión, antes de comenzar a transmitir un mensaje

adicional o reconocer que el bus está inactivo. Si, mientras tanto, se inicia una

transmisión (causada por otro nodo), el nodo se convertirá en el receptor de este

mensaje (40).

2.5.1.11. Validación de mensajes

El punto en el tiempo en el cual un mensaje se considera válido es diferente para el

transmisor y los receptores del mensaje (40).

2.5.1.11.1. Transmisor

El mensaje es válido para el transmisor si no hay ningún error hasta el final del mensaje.

Si un mensaje está dañado, la retransmisión seguirá automáticamente y de acuerdo

70

con las reglas de priorización. Para poder competir por el acceso del bus con otros

mensajes, la retransmisión debe comenzar tan pronto como el bus esté inactivo (40).

2.5.1.11.2. Receptor

El mensaje es válido para el receptor si no hay ningún error en mensaje (40).

2.5.1.11.3. Codificación de secuencia de bits

Los segmentos del inicio del mensaje, campo de arbitraje, campo de control, campo

de datos y secuencia CRC están codificados por el método de relleno de bits.

Cuando un transmisor detecta cinco bits consecutivos de valor idéntico en el flujo de

bits a transmitir, inserta automáticamente un bit complementario en el flujo de bits

transmitido real (40).

Los campos de bits restantes del mensaje de datos o mensaje remoto (delimitador

CRC, campo ACK y fin del mensaje) son de forma fija y no rellenos (40).

El mensaje de error y el mensaje de sobrecarga también son de forma fija y no están

codificados por el método de relleno de bits. El flujo de bits en un mensaje se codifica

de acuerdo con el método no regreso a cero (NRZ) (49). Esto significa que durante el

tiempo de bit total el nivel de bit generado es dominante o recesivo.

2.5.1.11.4. Mecanismo de relleno de bits.

El mecanismo de relleno de bits evita que seis bits consecutivos tengan la misma

polaridad al insertar un bit de polaridad opuesta después del quinto bit. Además, el

objetivo principal del mecanismo de relleno de bits se utiliza para sincronizar el

transmisor y el receptor cuando los mismos valores deben transmitirse

consecutivamente (50). Los bits expuestos al mecanismo de relleno de bits son los bits

del SOF a los bits de secuencia. Los bits de relleno del mensaje recibido se eliminan en

el nodo de recepción antes de procesar el mensaje (51).

Según el peor de los casos, la cantidad de bits de un mensaje CAN se encuentra dada

por:

71

𝑔 + 8𝑠 + 13 +𝑔 + 8s − 1

4

Donde g es 34 para el formato estándar o 54 para el formato extendido, s es la

cantidad de bytes de datos de un mensaje CAN (52).

Figura 39 - Peor caso del mecanismo de relleno de bits

2.5.1.12. Manejo de errores

2.5.1.12.1. Detección de errores

Hay cinco tipos de error diferentes (mutuamente excluyentes).

2.5.1.12.1.1. Error de bit

Un nodo el cual envía un bit en el bus también supervisa el bus. El nodo debe detectar

e interpretar como un error de Bit, la situación donde el valor de bit monitoreado es

diferente del valor de bit que se envía. Una excepción a esto es el envío de un bit

recesivo durante el flujo de bits rellenado del campo de arbitraje o durante el campo

ACK; en este caso, no se produce un error de bit cuando se controla un bit dominante.

Un transmisor que envía un indicador de error-pasivo y detecta un bit dominante no

lo interpreta como un error de bit (40).

72

2.5.1.12.1.2. Error de rellenado

Un error de rellenado debe ser detectado e interpretado como tal en si se detectan

6 niveles consecutivos dominantes u 6 consecutivos recesivos, en un campo de

mensaje que debe ser codificado por el método de relleno de bits (40).

2.5.1.12.1.3. Error de CRC

La secuencia CRC consiste en el resultado del cálculo CRC por el transmisor.

Los receptores calculan el CRC de la misma manera que el transmisor. Se debe

reconocer un error CRC si el resultado calculado no es el mismo que el recibido en la

secuencia CRC (40).

2.5.1.12.1.4. Error de forma

Se debe detectar un error de forma cuando un campo de bit de forma fija contiene

uno o más bits ilegales (40).

2.5.1.12.1.5. Error de acuse de recibo

Un error de acuse de recibo debe ser detectado por un transmisor siempre que no

monitoree un bit dominante durante la el campo ACK (40).

2.5.1.13. Señalización de error

Un nodo que detecta una condición de error lo señala al transmitir un indicador de

Error. Un nodo en error activo transmitirá un indicador de error activo; un nodo en error-

pasivo transmitirá un indicador de error-pasivo. Cuando nodo detecte un error de Bit,

un error de rellenado, un error de forma o un error de reconocimiento, ese nodo

comenzará la transmisión de un indicador de error en el siguiente tiempo de bit.

Cuando se detecte un error de CRC, la transmisión de un indicador de error

comenzará en el bit que sigue al delimitador de ACK, a excepción cuando ya se haya

iniciado un indicador de Error para otra condición de error (40).

73

2.5.1.14. Confinamiento de fallas

2.5.1.14.1. Estado del nodo de CAN

Con respecto al confinamiento de fallas, un nodo puede estar en uno de tres estados:

error-activo, error-pasivo o desconectado del bus. Un nodo activo de error

normalmente puede participar en la comunicación de bus y envía un indicador de

error activo cuando se ha detectado un error (40).

Un nodo en error-pasivo no debe enviar un indicador de error activo. Participa en la

comunicación de bus, pero cuando se detecta un error, solo se envía un indicador

de error-pasivo. También después de una transmisión, un nodo en error-pasivo

esperará antes de iniciar una transmisión adicional. No se permite que un nodo en el

bus tenga alguna influencia en el bus (40).

2.5.1.14.2. Contador de error

Para facilitar el confinamiento de fallas, se implementan dos contadores en cada

nodo del bus:

• Contador de errores de transmisión (TEC)

• Contador de errores de recepción (REC)

Estos conteos se modifican de acuerdo con las siguientes 12 reglas:

1) Cuando un receptor detecta un error, el contador de errores de recepción se

incrementará en 1, excepto cuando el error detectado fue un error de bit

durante el envío de un indicador de error activo o una sobrecarga (40).

2) Cuando un receptor detecta un bit dominante como el primer bit después de

enviar un indicador de error activo, el contador de errores de recepción se

incrementará en 8 (40).

3) Cuando un transmisor envía un indicador de error, el contador de errores de

transmisión se incrementa en 8 (40).

Excepción 1:

El contador de errores de transmisión no cambia si:

• El transmisor es un nodo en error-pasivo.

74

• El transmisor detecta un error de acuse de recibo porque no

detecta un ACK dominante.

• El transmisor no detecta un bit dominante mientras envía su

indicador de error pasivo.

Excepción 2:

Contador de errores de recepción no cambia si:

• El transmisor envía un indicador de error porque se produjo un

error de relleno.

• Durante el arbitraje y el bit de relleno debería haber sido recesivo.

• Durante el arbitraje y el bit de relleno se ha enviado como

recesivo, pero se controla como dominante.

4) Un transmisor en error-activo detecta un error de bit mientras envía un indicador

de error activo o un indicador de sobrecarga, el contador de errores de

transmisión se incrementa en 8 (40).

5) Un receptor de error-activo detecta un error de bit mientras envía un indicador

de error activo o un indicador de Sobrecarga, el contador de errores de

recepción se incrementa en 8 (40).

6) Cualquier nodo tolera hasta 7 bits dominantes consecutivos después de enviar

un indicador de error-activo o un indicador de error-pasivo. Después de

detectar el octavo bit dominante consecutivo y después de cada secuencia

de ocho bits dominantes consecutivos, cada transmisor aumenta su contador

de errores de transmisión en 8 y cada receptor aumenta su contador de errores

de recepción en 8 (40).

7) Después de la transmisión exitosa de un mensaje (recibiendo ACK y sin error

hasta que finalice el mensaje), el contador de errores de transmisión se reduce

en 1, a menos que ya sea 0 (40).

8) Después de la recepción exitosa de un mensaje (recepción sin error hasta el

campo ACK), el contador de errores de recepción se reduce en 1, si estaba

entre 1 y 127. Si el contador de errores de recepción era 0, permanece en 0, y

si era mayor que 127, entonces se establecerá en un valor entre 119 y 127 (40).

75

9) Un nodo tiene error-pasivo cuando el contador de errores de transmisión es

igual o superior a 128, o cuando el contador de errores de recepción es igual

o superior a 128 (40).

10) Un nodo se desconecta del bus cuando el contador de errores de transmisión

es mayor o igual a 256 (40).

11) Un nodo en error-pasivo vuelve a activarse por error cuando tanto el contador

de errores de transmisión como el contador de errores de recepción son

menores o iguales a 127 (40).

12) Se permite que un nodo que está desconectado se active, estableciendo sus

contadores de errores a 0 después de que se hayan monitoreado 128

ocurrencias de 11 bits recesivos consecutivos en el bus (40).

Cuando un contador de errores es superior 96 indica un bus muy perturbado (40).

Si durante el arranque del sistema, sólo un nodo está en línea, y si este nodo transmite

algún mensaje, no recibirá acuse de recibo, detectará un error y repetirá el mensaje.

Puede convertirse en un nodo en error-pasivo pero no desconectarse del bus debido

a esta razón (40).

Se puede aplicar más de una regla durante una transferencia de mensaje dada (40).

76

Figura 40 - Secuencia de tipos de errores

2.5.1.15. Sistema de transmisión de datos

2.5.1.15.1.1. Nodo de CAN

Un nodo de CAN comprende un microcontrolador para el software de aplicación, el

controlador CAN y el transceptor CAN (controlador de bus). El controlador CAN es

responsable de los modos de transmisión y recepción. Genera el flujo de bits para la

comunicación de datos a partir de los datos binarios que se transmiten y lo envía al

transceptor en la línea TX. Genera el nivel de voltaje requerido para la transferencia

de datos diferenciales y transmite el flujo de bits procesado en serie en la línea de bus

(CAN_H y CAN_L) (7).

Los mensajes entrantes son procesados por el transceptor y enviados al controlador

CAN en la línea RX (7).

77

El microcontrolador, que ejecuta el programa de aplicación, controla el controlador

CAN, prepara los datos que se enviarán y evalúa los datos recibidos (7).

Figura 41 - Nodo de CAN

2.5.1.15.1.2. Estados lógicos y codificación del bus

CAN utiliza dos estados para comunicación, dominante y recesivo, con los cuales se

transmiten los bits de información. El estado dominante representa un 0 binario, el

recesivo es un 1 binario (7).

Cuando recibe mensajes, el transceptor de CAN convierte el nivel de señal a estados

lógicos. En el proceso, un amplificador diferencial resta el nivel CAN_L del nivel CAN_H

(7).

78

2.5.1.15.1.3. Línea de dos cables (CAN DW)

Para CAN, cualquier agente de transmisión en el que puedan transmitirse estados

dominantes y recesivos es digno de consideración. Por lo general, se usa un par de

cables, dependiendo de las condiciones ambientales, y los cables están acoplados

o desacoplados galvánicamente. Las dos líneas de bus se designan CAN_H y CAN_L.

La línea de dos hilos admite la transferencia simétrica de datos, por lo que los bits se

envían en ambas líneas de bus y se representan mediante diferentes tensiones. Esto

reduce la sensibilidad a la interferencia en fase debido al efecto de la interferencia

en ambas líneas puede filtrarse. La protección adicional de las líneas reduce sus

propias emisiones de radiación, especialmente a altas velocidades de transmisión (7).

Figura 42 - Determinación de estados

79

2.5.1.15.1.4. Línea de un solo cable (CAN SW)

La especificación de un solo cable SAE J2411 (53) es para aplicaciones de red CAN

con requisitos bajos en cuanto a velocidad de bits y longitud de bus. La comunicación

se realiza a través de una sola línea de bus con una velocidad de datos nominal de

33,3 kbit / s (83,3 kbit / s en modo de alta velocidad para el diagnóstico). Se permiten

hasta 32 nodos por red. El área de aplicación principal de esta capa física se

encuentra en las redes de electrónica de confort en los vehículos de motor (54).

Un cable individual sin blindaje se define como el medio de bus. Una estructura de

topología de bus lineal no es necesaria. El estándar incluye la capacidad de dormir

del nodo selectivo, que permite que la comunicación regular tenga lugar entre varios

nodos, mientras que otros quedan en estado inactivo. Sin embargo, debido a la

comunicación de un solo cable (sin tensión diferencial), la robustez es muy baja. Todos

los suscriptores del bus deben compartir una conexión común a tierra que asumiría la

función de la segunda línea. La versión de un solo cable del bus CAN es, por lo tanto,

solo una opción para un sistema de comunicaciones de dimensiones espaciales

limitadas (7).

La transferencia de datos en la línea de un solo cable es más propensa a la radiación

de interferencia porque no es posible filtrar los impulsos de perturbación como ocurre

con la línea de dos hilos. Por esta razón, se requiere un mayor aumento de nivel en la

línea de bus para mejorar la relación señal / ruido (7).

2.5.1.15.1.5. Nivel de voltaje

El transceptor de CAN convierte los estados lógicos 0 y 1 recibidos por el controlador

de CAN en niveles de voltaje los cuales alimentan a las líneas CAN_H y CAN_L dentro

del bus (7).

CAN de alta velocidad y baja velocidad utilizan diferentes niveles de voltaje para la

transmisión de estados dominantes y recesivos. Los niveles de voltaje de CAN de baja

velocidad van de 0 V a 3.6 V para CAN_L y de 1.4 V a 5 V para CAN_H (7).

80

Figura 43 - Niveles de voltaje de CAN de baja velocidad

Mientras tanto los niveles de voltaje de CAN de alta velocidad van de 1.5 V a 2.5 V

para CAN_L y de 2.5 V a 3.5 V para CAN_H (7).

Figura 44 - Niveles de voltaje para CAN de alta velocidad

81

En estado recesivo, la CAN de alta velocidad usa una tensión de 2.5 V en ambas

líneas. En el estado dominante, un voltaje de 3.5 V está presente en CAN_H y un voltaje

de 1.5 V está presente en CAN_L (7).

En la CAN de baja velocidad, hay una tensión de 0 V en CAN_H en estado recesivo y

5 V en CAN_L. En el estado dominante, los voltajes de 3.6 V y 1.4 V están presentes en

CAN_H y CAN_L respectivamente (7).

2.5.1.15.1.6. Terminación sin reflejos

Para amortiguar las reflexiones de las señales eléctricas en los extremos abiertos, las

líneas de bus terminan en cada extremo con una resistencia de 120 Ω (7).

Alternativamente, las resistencias de terminación se pueden integrar en las propias

unidades de control electrónico (7).

2.5.1.15.1.7. Límites de emisión

Para permitir la evaluación correcta de la transmisión de bits, la señal debe llegar a

cada nodo dentro del tiempo del bit sin interferencia. La velocidad de bits máxima

permitida depende de la longitud total del bus. La ISO 11898 (40) especifica la

velocidad de bits para una longitud de circuito definida. Las siguientes

recomendaciones existen para líneas más largas.

• 1 MBits / s por 40 m

• 500 kBits / s hasta 100 m



• 40 kBits / s hasta 1,000 m

Es posible conectar al menos 30 nodos de red al bus sin la necesidad de medidas

adicionales (17).

82

Figura 45 - Sistema de transmisión de datos CAN

2.5.2. LIN

2.5.2.1. Introducción

La red de interconexión local (LIN) es un protocolo de comunicación que se ha

establecido para vehículos automotrices. Este protocolo se basa en el formato de

datos SCI (UART) con una arquitectura esclavo-maestro. Un consorcio formado en

1998, compuesto por AUDI, BMW, DaimlerChrysler, Volvo, Volkswagen, VCT y Motorola

trabajó en el establecimiento de una especificación para este protocolo. El desarrollo

de LIN se basó en la necesidad de un protocolo de comunicación que fuera muy

rentable y no solo abordará el tema de la especificación para la comunicación, sino

también otros temas como transmisión de señales, programación e interconexión de

nodos (55). Actualmente la última especificación de LIN se encuentra contenida en

el Paquete de Especificación LIN, revisión 2.2A el cual había sido mantenido por el

consorcio de LIN. Actualmente, la última especificación LIN se transcribe en ISO

(Organización Internacional para la Estandarización) como parte del proceso para

83

ser aceptado como ISO 17987 Parte 1-7. El mantenimiento de la identificación del

proveedor LIN será manejado por la ISO.

LIN Fue diseñado especialmente para la comunicación de bajo costo entre sensores

inteligentes y actuadores en aplicaciones automotrices. Las aplicaciones pueden ser

aire acondicionado, asientos, espejos, sensores de lluvia, sensores de luz, cierre de

puertas, ventanas.

Figura 46 - Ejemplo de buses de LIN

84

Figura 47 - LIN Contra otros buses automotrices

LIN provee una solución económica cuando los requisitos de desempeño no son altos.

Así LIN puede ser utilizado donde el ancho de banda o velocidad de transferencia en

la red son bajos y la confianza y robustez encontrados en CAN no son requeridos. Otra

ventaja de LIN es que no existen conflictos de colisiones, el sistema opera con un solo

maestro y múltiples esclavos (17).

2.5.2.2. Principales características

LIN es un protocolo de comunicaciones en serie que soporta de manera eficiente el

control de nodos en aplicaciones automotrices distribuidas.

Las principales propiedades del bus LIN son (56):

Maestro único con concepto de esclavos múltiples.

Implementación de silicio de bajo costo basada en hardware común de

interfaz UART / SCI, un equivalente en software o como máquina de estado

puro.

85

Auto sincronización sin necesidad de un cristal de cuarzo o cerámica en los

nodos esclavos.

Sistema determinístico de trasmisión con tiempo de propagación de señal

computable por adelantado.

Implementación de un solo cable de bajo costo.

Velocidad de hasta 20 Kbit/s.

Comportamiento predecible.

Re-configurabilidad.

Capa de transporte y soporte de diagnóstico

2.5.2.3. Concepto de nodo

Un nodo en una red se conecta al cable físico del bus utilizando un transceptor de

mensajes. Los mensajes no son accedidos directamente por la aplicación; una capa

de interacción basada en señal se agrega en el medio. Como complemento, existe

una interfaz de capa de transporte entre la aplicación y el transceptor de mensajes

(56).

Figura 48 - Estructura nodo de LIN

86

2.5.2.4. Principio operacional de LIN

2.5.2.4.1. Maestro-esclavo

Una red de LIN consta de una tarea maestra y varias tareas esclavas. Un nodo maestro

contiene la tarea maestra, así como una tarea esclava. Todos los demás nodos

esclavos sólo contienen una tarea esclava. Un nodo puede participar en más de una

red. El término nodo se refiere a una única interfaz de un nodo si el nodo tiene múltiples

interfaces de bus (56). La tarea maestra decide cuándo y qué mensaje se transferirá

al bus. Las tareas esclavas proporcionan los datos transportados por cada mensaje

(56).

Figura 49 - Configuración de la red de LIN

2.5.2.4.2. Mensajes

Un mensaje consiste en un encabezado enviado por la tarea maestra y una respuesta

llevada a cabo por la tarea esclava (56).

El encabezado consiste en un campo de corte, un campo de sincronización y un

campo de identificación. El identificador define de manera única el propósito del

marco. La tarea esclava designada para proporcionar la respuesta asociada con el

87

identificador se encarga de transmitir la respuesta. La respuesta consiste en un campo

de datos y un cam us LIN se conocen como po de suma de comprobación (56).

Figura 50 - Estructura de un menaje de LIN

Las tareas esclavas interesadas en los datos asociados con el identificador de trama

reciben la respuesta, verifican la suma de comprobación y utilizan los datos

transportados (56).

Figura 51 - Composición de los mensajes de LIN

Esta configuración permite que los sistemas LIN sean flexibles permitiendo la

incorporación de nodos simplemente siendo agregados físicamente al sistema. Así

mismo toda la información transmitida es identificada con un número único y esta

puede ser recibida y utilizada por cualquier nodo que lo desee (56).

2.5.2.4.3. Transporte de datos

En un mensaje de LIN se pueden transportar dos tipos de datos

88

1. Señales: Son valores escalares o matrices de bytes que se empaquetan en el

campo de datos de un mensaje. Una señal siempre está presente en la misma

posición del campo de datos para todos los mensajes con el mismo

identificador (56).

2. Mensajes de diagnóstico: Se transportan en un mensaje con dos identificadores

reservados. La interpretación del campo de datos depende del campo de

datos en sí, así como del estado de los nodos de comunicación (56).

2.5.2.4.4. Tabla de programación

La tarea maestra (en el nodo maestro) transmite encabezados basados en una tabla

de programación. La tabla de programación específica los mensajes y el intervalo

entre el inicio de inicio transmisión de este y el inicio del siguiente mensaje. La

aplicación maestra puede usar diferentes tablas de programación y seleccionar entre

ellas (56).

2.5.2.5. Protocolo LIN

2.5.2.5.1. Tipos de señales

Una señal es un valor escalar o una matriz de bytes. Una señal escalar tiene entre uno

y dieciséis bits de longitud. Una señal escalar de un bit se llama señal booleana. Las

señales escalares en el tamaño de dos a dieciséis bits se tratan como enteros sin signo.

Una matriz de bytes es una matriz de entre uno y ocho bytes.

Cada señal tiene un único transmisor pero múltiples nodos pueden suscribirse a la

señal.

Todas las señales tienen valores iniciales. El valor inicial para una señal transmitida es

válido hasta que el nodo escriba un nuevo valor a esta señal (56).

89

2.5.2.5.2. Consistencia de las señales

Nunca debe ser posible que una aplicación reciba un valor de señal que se actualice

parcialmente. Esto también se aplica a las matrices de bytes. Sin embargo, no se

garantiza la coherencia entre las señales (56).

2.5.2.5.3. Empaquetamiento de señales

Una señal se transmite primero con el LSB y el MSB. No hay restricciones para

empaquetar señales escalares por encima de los límites de bytes. Se pueden

empaquetar varias señales en un mensaje siempre que no se superpongan entre sí.

La misma señal se puede empaquetar en múltiples mensajes siempre que el transmisor

de la señal sea el mismo. Si un nodo recibe una señal empaquetada en múltiples

mensajes, el último valor de señal recibido es válido. Manejar la misma señal

empaquetada en mensajes diferentes en diferentes está fuera del alcance de LIN

(56).

2.5.2.5.4. Recepción y transmisión de mensajes

El tiempo es diferente para un nodo maestro y un nodo esclavo. La razón es que el

nodo maestro controla la programación de mensajes y sabe cuándo deben ser

enviados. Un nodo esclavo obtiene esta información cuando el encabezado se

transmite en el bus (56).

Una señal se considera recibida y disponible para la aplicación de la siguiente

manera:

Nodo maestro: En la siguiente base de tiempo cuando el mensaje ha sido

enviada. El nodo maestro actualiza sus señales recibidas periódicamente en el

inicio de cada base de tiempo (56).

Nodo esclavo: Cuando se valida la suma de verificación para el mensaje

recibido. El nodo esclavo actualiza sus señales recibidas directamente después

de que el mensaje ha sido recibido (56).

90

Figura 52- Recepción de una señal

Una señal se considera transmitida cuando:

Nodo maestro: Antes de iniciar la transmisión de un mensaje (56).

Nodo esclavo: Cuando se recibe la ID para el mensaje (56).

Figura 53 - Transmisión de una señal

2.5.2.6. Transferencia de mensajes

Las entidades que se transfieren en el bus LIN se conocen como mensajes (56).

91

2.5.2.6.1. Estructura de los mensajes

Un mensaje está formado por una serie de campos, comienza con un campo de corte

seguido de cuatro hasta once campos de datos (56).

El tiempo que toma enviar un mensaje es la suma del tiempo para enviar cada byte

más el espacio de respuesta y los espacios entre bytes (56).

El encabezado comienza en el en el flanco de bajada del campo de corte y termina

después del último bit del campo de identificador protegido (PID). La respuesta

comienza al final del último bit del campo PID y finaliza en el último bit del campo de

suma de comprobación (56).

Figura 54 - Estructura de un mensaje

En todos campos de bytes, excepto el campo de interrupción, El bit más significativo

(LSB) de los datos se envía primero y el bit menos significativo (MSB) se envía al último.

El bit de inicio se codifica como un bit con valor cero (dominante) y el bit de parada

se codifica como un bit con valor uno (recesivo) (56).

92

Figura 55 - Estructura de los campo de datos

2.5.2.6.1.1. Campo de corte

El campo de corte o también conocido como campo de corte se usa para señalar el

comienzo de un nuevo mensaje. Un campo de corte siempre es generado por la tarea

maestra (en el nodo maestro) y debe tener al menos 13 bits de valor dominante,

seguido de un delimitador de corte. El delimitador de salto debe ser al menos un bit

con longitud de un tiempo nominal (56).

Un nodo esclavo usará un umbral de detección de ruptura de 11 tiempos de bit

esclavo local dominante. No es necesario que un nodo esclavo verifique que el

delimitador de corte tenga al menos un bit de longitud del tiempo (56).

Figura 56 - Campo de corte

2.5.2.6.1.2. Campo de sincronización

El campo de sincronización es un campo de bytes con el valor de datos 0x55 (0101

0101b) (56).

93

Figura 57 - Campo de sincronización

Una tarea esclava siempre podrá detectar la secuencia del campo sincronización,

incluso si espera un campo de bytes. Cuando se produce una secuencia de campo

de sincronización, la transferencia en curso se interrumpirá y comenzará el

procesamiento del nuevo mensaje (56).

2.5.2.6.1.3. Campo identificador protegido

Un campo de identificador protegido consta de dos sub-campos; el identificador del

mensaje y la paridad. Los bits 0 a 5 son el identificador del mensaje y los bits 6 y 7 son

la paridad (56).

1.1.1.1.1.1.5. Identificador del mensaje

Seis bits están reservados para el identificador del mensaje, se pueden usar valores en

el rango de 0 a 63. Los identificadores de cuadros se dividen en tres categorías (56):

Los valores de 0 a 59 (0x3B) se utilizan para tramas portadoras de señal.

60 (0x3C) y 61 (0x3D) se utilizan para transportar datos de diagnóstico y

configuración.

62 (0x3E) y 63 (0x3F) están reservados para futuras mejoras de protocolo.

1.1.1.1.1.1.6. Paridad

La paridad se calcula con los bits de identificador del mensaje:

P0 = ID0 + ID1 + ID3 + ID4

P1 = ⌐ (ID1 + ID3 + ID4 + ID5)

94

Figura 58 - Campo de identificador protegido

1.1.1.1.1.1.7. Campo de datos

Un mensaje contiene entre uno y ocho bytes de datos. El editor y todos los suscriptores

deberán acordar el número de datos contenidos en un mensaje con un identificador

de mensaje específico. Un byte de datos se transmite como parte de un campo de

bytes (56).

Para entidades de datos de más de un byte, la parte menos significativa (LSB) está

contenida en el byte enviado primero y la parte menos significativa MSB en el byte

enviado en último lugar. Los campos de datos están etiquetados como datos 1, datos

2,... hasta datos máximos 8 (56).

Figura 59 - Campo de datos

1.1.1.1.1.1.8. Suma de comprobación

El último campo de un mensaje es la suma de comprobación. La suma de

comprobación contiene la suma de ocho bits invertida con todos los bytes de datos

o todos los bytes de datos y el identificador protegido. El cálculo de suma de

95

comprobación sobre los bytes de datos solo se denomina suma de comprobación

clásica (56).

La suma de ocho bits con acarreo equivale a sumar todos los valores y restar 255 cada

vez que la suma es mayor o igual a 256 (56).

El cálculo de suma de comprobación sobre los bytes de datos y el byte identificador

protegido se denomina suma de verificación mejorada (56).

El uso de la suma de comprobación clásica o mejorada es gestionado por el nodo

maestro y se determina por identificador de cuadro; clásico en la comunicación con

los nodos esclavos LIN 1.x y mejorado en la comunicación con los nodos esclavos LIN

2.x (56).

Los identificadores de trama 60 (0x3C) a 61 (0x3D) siempre usarán la suma de

comprobación clásica (56).

2.5.2.7. Tipos de mensajes

El tipo de mensaje se refiere a las condiciones previas que serán válidas para transmitir

el mensaje. Algunos de los tipos de mensajes sólo se usan para fines específicos. Un

nodo no tiene que admitir todos los tipos de mensajes (56).

Todos los bits no utilizados / definidos en un mensaje serán recesivos (unos).

2.5.2.7.1. Mensaje incondicional

Los mensajes incondicionales llevan señales y sus identificadores de mensaje están en

el rango 0 (cero) a 59 (0x3B) (56).

El encabezado de un mensaje incondicional siempre se transmite cuando el espacio

asignado al mensaje incondicional es procesado (por la tarea maestra). El suscriptor

del mensaje incondicional (la tarea esclava) siempre debe proporcionar la respuesta

al encabezado. Todos los suscriptores del mensaje incondicional recibirán el mensaje

y la pondrán a disposición de la aplicación (56).

Una transferencia siempre es iniciada por el maestro. Esta puede tener un único editor

y uno o varios suscriptores (56).

96

Figura 60 - Transferencia de tres mensajes incondicionales

2.5.2.7.2. Mensaje desencadenado por evento

El objetivo de un mensaje activado por un evento es aumentar la capacidad de

respuesta de un nodo de LIN sin asignar demasiado ancho de banda del bus a nodos

esclavos con eventos raramente ocurrentes (56).

Todos los suscriptores del mensaje activados por evento recibirán el mensaje y usarán

sus datos como si se hubiera recibido un mensaje incondicional asociado (56).

El encabezado de un mensaje activado por evento se transmite en el espacio de

tiempo cuando se procesa el mensaje activado por evento. El suscriptor de un

mensaje incondicional asociado sólo transmitirá la respuesta si se actualiza al menos

una de las señales transmitidas en su mensaje incondicional. Si la respuesta se

transmite con éxito, la señal ya no se considera actualizada (56).

Si ninguno de los nodos esclavos responde al encabezado, el encabezado se

ignorará. Si más de un nodo esclavo responde al encabezado en el mismo espacio y

tiempo, se producirá una colisión (56).

97

2.5.2.7.2.1. Resolución de colisión

El nodo maestro debe resolver la colisión en una tabla de programación de resolución

de colisiones. Cada mensaje activado por evento tiene una tabla de planificación de

resolución de colisiones asociada. El controlador en el nodo maestro realiza

automáticamente el cambio a la planificación de resolución de colisiones. La tabla

de resolución de colisión se activará al comienzo del siguiente mensaje después de la

colisión (56).

Todos mensajes incondicionales asociadas se enumerarán en esta tabla de

planificación de resolución de colisiones (56).

Después de que la tabla de planificación de colisión se haya procesado una vez, el

controlador en el nodo maestro deberá volver a la tabla de programación previa (56).

Continuará con la entrada subsecuente a la entrada de la tabla donde ocurrió la

colisión.

Si uno de los nodos esclavos colisionantes se retira sin corromper la transferencia, el

nodo maestro no detectará esto. Un nodo esclavo que ha retirado su respuesta debe,

por lo tanto, volver a intentar transmitir su respuesta hasta que tenga éxito, de lo

contrario la respuesta se perderá (56).

En caso de que la aplicación del nodo maestro cambie la tabla de planificación

antes de que se resuelva la colisión, la resolución de colisión se pierde. Los nodos

esclavos colisionantes aún tendrán sus respuestas pendientes para la transmisión (56).

Por ejemplo, una tabla de planificación contiene solo un mensaje activado por

evento (ID = 0x10). El mensaje activada por evento está asociada con dos menajes

incondicionales desde el esclavo 1 (ID = 0x11) y el esclavo 2 (ID = 0x12). La tabla de

planificación de resolución de colisión contiene los dos marcos incondicionales. La

figura siguiente muestra la resolución a esa colisión.

98

Figura 61 - Resolución de colisiones en LIN

2.5.2.7.3. Mensajes esporádicos

El propósito de los mensajes esporádicos es combinar algunos comportamientos

dinámicos en la tabla de planificación centrada en el tiempo determinista y en

tiempo real sin perder el determinismo en el resto de la tabla de planificación (56).

Un mensaje esporádico es un grupo de mensajes incondicionales que comparten el

mismo espacio de mensajes. Cuando el mensaje esporádico se vence para la

transmisión, los mensajes incondicionales se verifican si tienen alguna señal

actualizada. Si no se actualizan las señales, no se transmitirá ningún mensaje y el

tiempo transmisión estará vacío. Si se ha actualizado una o más señales se transmitirá

el mensaje correspondiente. Si se ha actualizado más de una señal (contenida en

diferentes mensajes), se transmitirá el mensaje con la prioridad más alta. Los mensajes

candidatos no transmitidos no se perderán. Serán candidatos para ser transmitidos

cada vez que venza el mensaje esporádico, siempre que no se hayan transmitido (56).

99

Si el mensaje incondicional se transmitió con éxito, este ya no estará pendiente de

transmisión hasta que una señal se actualice nuevamente. Solo la tarea maestra sabe

cuándo un mensaje incondicional está pendiente para la transmisión (56).

Figura 62 - Mensaje esporádico

2.5.2.7.4. Mensajes de diagnóstico

Los mensajes de diagnóstico siempre llevan la capa de transporte y siempre

contienen ocho bytes de datos. El identificador de mensaje es 60 (0x3C), llamado

mensaje de solicitud principal, o 61 (0x3D), llamado mensajes de respuesta esclavo.

La interpretación de los datos se da en la configuración de nodo y especificación de

identificación y especificación de diagnóstico (56).

Antes de transmitir una requisición de mensaje, la tarea maestra consulta su módulo

de diagnóstico si este se transmitirá o si el bus está en silencio. Un encabezado de

marco de respuesta esclavo se enviará incondicionalmente.

Las tareas esclavas se suscriben a la respuesta de acuerdo con sus módulos de

diagnóstico.

100

2.5.2.7.5. Mensajes reservados

Los mensaje reservados no se deben usar en un nodo de LIN 2.x. Su identificador de

mensaje es 62 (0x3E) y 63 (0x3F).

2.5.2.8. Tablas de planificación

Una propiedad clave del protocolo LIN es el uso de tablas de planificación. Las tablas

de planificación permiten asegurar que el bus nunca se sobrecargue. También son el

componente clave para garantizar la periodicidad de las señales (56).

El comportamiento determinista es posible por el hecho de que todas las

transferencias en un nodo de LIN son iniciadas por la tarea maestra. Es responsabilidad

del nodo maestro asegurarse de que todos los mensajes relevantes en un modo de

operación tengan suficiente tiempo para ser transferidos (56).

2.5.2.8.1. Definición de tiempo

La unidad de tiempo mínima que se utiliza en un nodo LIN es el tiempo base (Tbase). El

tiempo base se implementa en el nodo maestro y se usa para controlar el tiempo de

la tabla de planificación. Por lo general, un tiempo base es de 5 o 10 ms (56).

El punto de inicio del tiempo base se define como la tick del tiempo base. Un espacio

de mensaje siempre comienza en in tick de tiempo base (56).

La fluctuación (jlittler), especifica las diferencias entre la demora máxima y mínima

desde el tick hasta el punto de inicio del envío del encabezado (56).

El espacio entre mensajes, es el tiempo desde el final del mensaje hasta el inicio del

siguiente mensaje. El espacio entre mensajes debe ser no negativo (56).

2.5.2.8.2. Sistemas de espacios de mensajes

Tespacio es el tiempo que controla la tabla de planeación. Es el tiempo desde el inicio

de una transmisión hasta el vencimiento de la siguiente entrada de la tabla de

planeación. Se define como un múltiplo entero del tiempo base. El múltiplo entero es

normalmente diferente para cada espacio de mensaje (56).

Tespacio = Tbase * n

101

Un espacio de mensaje debe tener una duración lo suficientemente larga como para

permitir la fluctuación introducida por la tarea (56).

Tespacio > fluctuación + Tmaximo

Figura 63 - Definición de tiempo

2.5.2.9. Modelo de comportamiento

El modelo de comportamiento se basa en el concepto de tarea maestra tarea /

esclavo. La tarea maestra es responsable de generar los encabezados correctos, es

decir, decidir qué mensaje debe enviarse y mantener el tiempo correcto entre los

mensaje, todo de acuerdo con la tabla de planeación (56).

102

Figura 64 - Máquina de estados de la tarea maestra

La tarea esclava es responsable de transmitir la respuesta del mensaje cuando es un

editor y de recibir la respuesta del mensaje cuando es un suscriptor. La tarea esclava

se modela con dos máquinas de estado (56):

Detectar del campo de sincronización

Procesador de mensajes

2.5.2.9.1. Detectar del campo de sincronización

Se requiere que una tarea esclava se sincronice al comienzo del campo identificador

protegido de un mensaje. Debe permanecer sincronizado dentro de la tolerancia de

velocidad de bits requerida en todo el resto del mensaje. Para este propósito, cada

mensaje comienza un campo de corte seguido por un campo de sincronización. Esta

secuencia es única en toda la comunicación LIN y proporciona suficiente información

para que cualquier tarea esclava detecte el comienzo de un nuevo mensaje y se

sincronice al comienzo del campo identificador (56).

103

2.5.2.9.2. Procesador de mensaje

El procesamiento de mensajes consta de dos estados: inactivo y activo. Active

contiene cinco sub-estados. Tan pronto como se recibe una secuencia de campo de

interrupción / sincronización (desde cualquier estado o sub-estado), el estado Activo

se ingresa en el sub-estado PID. Esto implica que el procesamiento de un mensajes se

cancelará mediante la detección de una nueva secuencia de campo de

interrupción / sincronización (56).

Figura 65 - Máquina de estados de procesamientos de mensajes de la tarea esclava

Una discrepancia entre la lectura y los datos enviados se detectará a más tardar

después de la finalización del campo de bytes que contiene la falta de coincidencia.

Cuando se detecta una falta de correspondencia, la transmisión se abortará (56).

104

2.5.2.10. Gestión de la red de LIN

La gestión de red en un nodo LIN se refiere a la suspensión y activación del bus de LIN.

2.5.2.10.1. Estados de comunicación en el nodo esclavo

2.5.2.10.1.1. Inicializando

Este estado se ingresa instantáneamente después de la primera conexión a la fuente

de poder, tras un reinicio o después de la activación proveniente del modo inactivo.

El nodo esclavo hará la inicialización necesaria y luego ingresará al estado

operacional. La inicialización aquí se refiere a la inicialización relacionada con LIN

(56).

2.5.2.10.1.2. Operacional

El comportamiento del protocolo LIN (transmisión y recepción de mensajes)

especificado anteriormente aplica al estado operacional (56).

2.5.2.10.1.3. Modo inactivo

El nivel en el bus se establece en recesivo. Solo la señal de activación puede

transmitirse en la red (56).

105

Figura 66 - Maquina de estados de procesamientos de mensajes de la tarea esclava

2.5.2.10.2. Activación de la red de LIN

Cualquier nodo en una red LIN inactiva puede solicitar la activación de la red, al

transmitir una señal de activación. La señal de activación forzar el bus al estado

dominante durante 250 μs a 5 ms, y es válido con el retorno de la señal del bus al

estado recesivo. El nodo maestro puede emitir un campo de corte, emitiendo un

encabezado ordinario ya que el campo de corte actuará como una señal de

activación (en este caso, el maestro debe saber que este mensaje no puede ser

procesado por los nodos esclavos ya que es posible que aún no estén activos y listos

para escuchar los mensajes) (56).

Cada nodo esclavo (conectado a la alimentación) debería detectar la señal de

activación (un pulso dominante de más de 150 μs seguido de un flanco ascendente

de la señal del bus) y estar preparado para escuchar los comandos del bus dentro de

los 100 ms, medidos desde el borde final el pulso dominante. Un umbral de detección

de 150 μs combinado con una generación de pulsos de 250 μs proporciona un

margen de detección que es suficiente para los nodos esclavos no calibrados. Si el

106

nodo que transmitió la señal de activación es un nodo esclavo, estará listo para recibir

o transmitir mensajes inmediatamente. El nodo maestro también se debe activar y,

cuando los nodos esclavos estén listos, comience a transmitir encabezados para

descubrir la causa (usando señales) de la activación (56).

Figura 67 - Señal de activación de un nodo esclavo

El nodo maestro detectará la señal de activación (un impulso dominante de más de

150 μs) y estará listo para iniciar la comunicación dentro de un tiempo determinado

por el diseñador de la red o la aplicación específica (56).

Si el nodo maestro no transmite un campo de corte (es decir, comienza a transmitir un

mensaje) o si el nodo que emite la señal de activación no recibe una señal de

activación (desde otro nodo) dentro de 150 ms a 250 ms desde la señal de activación,

el nodo que emite la señal de activación transmitirá una nueva señal de activación

(56).

Figura 68 - Secuencia de señales de activación

En caso de que el nodo esclavo transmita una señal de activación en el mismo

momento en que el nodo maestro transmite un campo de corte, el esclavo recibirá y

reconocerá este campo de corte (56).

107

Después de tres solicitudes (fallidas), el nodo deberá esperar un mínimo de 1.5

segundos antes de emitir una cuarta señal de activación. El motivo de esta mayor

duración es permitir que la red se comunique en caso de que el nodo esclavo activo

tenga problemas, si el nodo esclavo tiene problemas para leer el bus, probablemente

retransmitirá la señal de despertador infinitamente (56).

No hay restricción de cuántas veces un esclavo puede transmitir la señal de despertar.

Sin embargo, se recomienda que un nodo esclavo transmita no más de tres bloques

de señales de activación para cada condición de activación (56).

Figura 69 - Bloques de señales de activación

2.5.2.10.3. Ir al modo Inactivo

El maestro establece la red en modo inactivo transmitiendo un comando de ir a

estado inactivo. La solicitud no necesariamente enviará a los nodos esclavos a un

modo de bajo consumo. La aplicación de nodo esclavo aún puede estar activa

después de que se haya recibido el comando ir a estado inactivo. Este

comportamiento es específico de la aplicación (56).

El comando ir a estado inactivo es un mensaje de solicitud maestro con el primer

campo de datos establecido en 0 y el resto establecido en 0xFF. Los nodos esclavos

ignorarán los campos de datos 2 a 8 e interpretarán solo el primer campo de datos

(56).

Tabla 7- Comando para ir a modo inactivo

Dato 1 Dato 2 Dato 3 Dato 4 Dato 5 Dato 6 Dato 7 Dato 8

0 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

108

La forma normal de configurar el bus para que entre en el estado inactivo es que el

nodo maestro transmita el comando ir a estado inactivo (56).

En caso de inactividad del bus, un nodo esclavo debe poder recibir / transmitir

mensajes durante 4 s (56).

El nodo esclavo debe ingresar automáticamente al modo inactivo entre 4s y 10s de

inactividad del bus. (56).

La inactividad del bus se define como la ausencia de transiciones entre los valores de

bits dominantes recesivos. La actividad del bus es inversa (56).

2.5.2.11. Gestión del estatus de la red

El propósito de la gestión de estatus es detectar errores durante la operación,

proporcionar medios para reemplazar fácilmente las unidades en falla y proporcionar

a los nodos entrada en un modo de funcionamiento limitado (56).

2.5.2.11.1. Concepto

La gestión del estado en una red central se realiza en el nodo maestro. El nodo

maestro supervisa los informes de estado de cada nodo y filtra / integra los informes

para concluir si uno o más nodos se encuentran en falla (56).

2.5.2.11.2. Notificación a la red

El nodo maestro supervisará el estado en la red para verificar el comportamiento de

una señal específica publicada por todos los nodos esclavos (56).

Cada nodo esclavo publicará una señal escalar de un bit al nodo maestro en uno de

sus mensajes incondicionales transmitidos, llamada response_error. En caso de que el

mensaje incondicional esté asociada a un mensaje desencadenado por evento, el

mensaje también debe programarse como incondicional (56).

La señal response_error se establecerá siempre que un mensaje (excepto las

respuestas de mensajes activados por evento) que se transmite o recibe por el nodo

esclavo contenga un error en la respuesta del mensaje (56).

109

Tabla 8 - Interpretación de errores

La señal response_error se borrará cuando el mensaje incondicional que contiene la

señal response_error se transmita con éxito (56).

Es responsabilidad de la aplicación del nodo principal integrar y filtrar los informes de

estado individuales, así como hacer una síntesis de los informes de diferentes nodos

esclavos (56).

Un nodo esclavo puede proporcionar más información de estado, si se desea, pero el

único bit response_error siempre estará presente (56).

2.5.2.12. Capa física de LIN

La capa física de LIN consiste de un simple cable (más la conexión a tierra),

conectado al poso positivo de una batería a través de una resistencia de potencia y

un diodo. La comunicación en la red de LIN se activa mediante al nivel domínate

(tierra 0v) (17).

2.5.2.12.1. Niveles en la red de LIN

Los valores voltaje correspondiente a los niveles de bits en el bus de LIN son (17):

1. Dominante: ‘0’, Tierra

2. Recesivo: ‘1’, Terminal positiva le la batería.

response_error Interpretación

Falso el nodo esclavo está funcionando correctamente

Verdadero el nodo esclavo tiene problemas intermitentes

Sin Respuesta el nodo esclavo, el bus o el nodo maestro tiene serios

problemas

110

Figura 70 - Diferencia entre fuentes de voltaje

VBAT denota la tensión de alimentación en el conector de los ECUs. Los componentes

electrónicos dentro de la unidad pueden ver que un VSUP de suministro interno es

diferente del VBAT. Esto puede ser el resultado de elementos de filtro de protección y

cambios dinámicos de voltaje en el bus (56).

Figura 71 - Niveles en el bus de LIN

2.5.2.12.2. Número máximo de nodos en la red de LIN

Teóricamente la máxima cantidad de nodos que pueden ser conectados a la red de

LIN son 64. Por razones prácticas el número total de nodos está limitado a parámetros

físicos, como el tiempo de propagación en la línea, aproximadamente 5-7 ns/m (17).

Debido a esto los valores recomendables son (17):

El máximo número de nodos en una red no debe exceder 16 nodos.

111

La longitud del cable conectado a la red no debe exceder los 40m.

La resistencia del terminador debe ser de 1kΩ para el nodo maestro y 20-47 kΩ

para los nodos esclavos.

La capacitancia del nodo maestro debe ser mayor a la de los nodos esclavos.

113

3. PROCEDIMIENTO DE INVESTIGACIÓN

Mediante la investigación realizada se ha logrado recolectar la información necesaria

para la plena implementación del proyecto Automatización de Pruebas de Pérdida

de Comunicación CAN/LIN y Reseteo mediante VT System en sistemas embebidos. A

continuación en los siguientes apartados se presenta la completa implementación del

sistema, sus requerimientos y consideraciones particulares, así mismo los hallazgos

detectados durante estas etapas. Finalmente se explicará el procedimiento mediante

el cual se está llevando la automatización de las pruebas.

3.1. DEFINICIÓN DE REQUISITOS DEL SISTEMA

Esta sección es una Especificación de Requisitos Software (ERS) para el sistema

Automatización de Pruebas de Pérdida de Comunicación CAN/LIN y Reseteo

mediante VT System en sistemas embebidos. Esta especificación se ha estructurado

basándose en las directrices dadas por el estándar IEEE Práctica Recomendada para

Especificaciones de Requisitos Software ANSI/IEEE 830, 1998 (57).

Las presentes secciones tiene como propósito definir las especificaciones funcionales,

no funcionales para el desarrollo del sistema de Automatización de Pruebas de

Pérdida de Comunicación CAN/LIN y Reseteo mediante VT System en sistemas

embebidos, el cual permitirá gestionar la ejecución de casos de prueba basados en

los principios de acceso a los buses de comunicación como a las condiciones de

activación y desactivación de nodos de las redes de comunicación.

Esta especificación de requisitos está dirigida al personal a cargo del diseño,

implementación y pruebas del sistema.

114

Nombre Humberto Isaac Flores Bermejo

Rol Analista, diseñador, programador y probador

Categoría Profesional Ingeniero de Pruebas de Sistema

Responsabilidad Análisis de información, diseño y programación

y pruebas

Información de

contacto

[email protected]

Tabla 9 - Personal involucrado

3.1.1. Perspectiva del sistema

El sistema Automatización de Pruebas de Pérdida de Comunicación CAN/LIN y

Reseteo mediante VT System en sistemas embebidos, operará en un marco de

ejecución de pruebas el cual se basa en la creación de librerías, funciones estándar

y una interfaz gráfica para el control manual y automático del equipo.

3.1.2. Funcionalidad del producto

La funcionalidad del sistema de Automatización de Pruebas de Pérdida de

Comunicación CAN/LIN y Reseteo mediante VT System en sistemas embebidos está

enfocado al cumplimiento de los objetivos generales y específicos, pero no limitado

a estos.

3.1.3. Restricciones

• El sistema deberá utilizar el lenguaje nativo de la herramienta.

• Detalles del proyecto están sujetos a confidencialidad.

• Todos los entregables generados pertenecen a Robert BOSCH México.

3.1.4. Suposiciones y dependencias

• Se asume que los requisitos aquí descritos son estables

115

• Los equipos en cuales se ejecutará el sistema deben cumplir los requisitos de los

programas externos a utilizar.

3.1.5. Características de los usuarios

• Los usuarios del sistema deberá ser personal capacitado con experiencia

en el manejo del equipo de pruebas.

• Los usuarios deberán conocer el lenguaje de programación CAPL1.

• Los usuarios deberán conocer las herramientas CANoe2, VT System3.

3.1.6. Entorno de utilización del sistema

El ambiente en que se realizará la aplicación consiste en un banco de pruebas con

múltiples ECUs, el cual estará interconectado con el equipo de pruebas VT System.

Este se conectara a un equipo de cómputo mediante una red de Internet. Él envió de

información y ejecución de guiones de pruebas se llevará a cabo a través de la

herramienta CANoe™.

1 CAPL – Lenguaje de programación nativa de CANoe (Communication Access Programming

Language). 2 CANoe - Herramienta de software para el desarrollo, prueba y análisis de redes completas y

ECU individuales. 3 VT System – Módulos de interfaz de entradas y salidas para pruebas de ECU.

116

Figura 72 -Banco de pruebas

3.1.7. Requisitos funcionales

[VT_ERS_001]

El sistema debe de generar una pérdida de comunicación por tiempo finito de un

nodo dentro de una red de CAN mediante un circuito abierto.

[VT_ERS_002]


nodo dentro de una red de LIN mediante un circuito abierto.

[VT_ERS_003]


nodo dentro de una red de CAN mediante un corto a tierra.

[VT_ERS_004]


nodo dentro de una red de LIN mediante un corto a tierra.

[VT_ERS_005]

117


nodo dentro de una red de CAN mediante un corto a batería.

[VT_ERS_006]


nodo dentro de una red de LIN mediante un corto a batería.

[VT_ERS_007]

El sistema debe de desconectar y conectar la fuente de alimentación de una red de

CAN.

[VT_ERS_008]

El sistema debe de desconectar y conectar la fuente de alimentación de una red de

LIN.

[VT_ERS_009]

El sistema debe ser capaz de activar la red de CAN.

[VT_ERS_010]

El sistema debe ser capaz de activar la red de LIN.

[VT_ERS_011]

El sistema debe ser capaz de desactivar la red de CAN.

[VT_ERS_012]

El sistema debe ser capaz de desactivar la red de LIN.

[VT_ERS_013]

Para todo requisito de CAN el sistema debe de ser capaz de funcionar para CAN SW

y CAN DW

3.1.8. Requisitos no funcionales

[VT_ERS_014]

Todos lo requerimiento funcional deben implementarse mediante funciones reusables.

[VT_ERS_015]

Todos lo requerimiento funcional deben implementarse mediante una interfaz gráfica.

[VT_ERS_016]

118

La interfaz gráfica debe de seguir los lineamientos de diseño para sistemas interactivos

– ISO 13407-1999 (58)

3.2. DISEÑO E IMPLEMENTACIÓN

3.2.1. Clases, funciones y parámetros

Con el fin de cumplir con los requisitos establecidos previamente siguiente sección

establece la manera en que el sistema es implementado.

[VT_ERS_001]

La clase Loss_CAN permite realizar la perdida de comunicación en una red de CAN

de dos líneas o una línea.

Figura 73 - Clase Loss_CAN

Definición de funciones:

closeCircuit_CAN_H ()

//Descripción función : Cierra circuito en línea CAN_H (Solo CAN DW)

//Parámetros de entrada : NA

//Parámetros de salida : NA

closeCircuit_CAN_L ()

//Descripción función : Cierra circuito en línea CAN_L CAN SW/CAN DW



lossOfCom_CAN_DW (dword)

//Descripción función : Pérdida de comunicación CAN DW

//Parámetros de entrada : dword i_lossOfCom_time_ms

//Descripción del parámetro : Tiempo en ms de la pérdida de comunicación

//Rango de entrada : 1-4294967295

class

Loss_CAN

+ closeCircuit_CAN_H()

- closeCircuit_CAN_L()

+ lossOfCom_CAN_DW(dword): dword

+ lossOfCom_CAN_SW(dword): dword

+ openCircuit_CAN_H()

- openCircuit_CAN_L()

119


lossOfCom_CAN_SW (dword)

//Descripción función : Pérdida de comunicación CAN SW





openCircuit_CAN_H ()

//Descripción función : Abre circuito en línea CAN_H (Solo CAN DW)



openCircuit_CAN_L ()

//Descripción función : Abre circuito en línea CAN_L CAN SW/CAN DW



[VT_ERS_002]

La clase Loss_LIN permite realizar la pérdida de comunicación en una red de LIN de

dos líneas o una línea.

Figura 74 - Clase Loss_LIN


closeCircuit_LIN ()

//Descripción función : Cierra circuito en línea LIN



lossOfCom_LIN (dword)

//Descripción función : Perdida de comunicación LIN





openCircuit_LIN ()

//Descripción función : Abre circuito en línea LIN



class

Loss_LIN

- closeCircuit_LIN()

+ lossOfCom_LIN(dword)

- openCircuit_LIN()

120

[VT_ERS_03]

La clase Short2Ground_CAN permite realizar la un corto a tierra en una red de CAN

de dos líneas o una línea.

Figura 75 - Clase Short2Ground_CAN


s2g_switchActive_CAN_H ()

//Descripción función : Activa el corto a tierra en línea CAN_H

// (Solo CAN DW)



s2g_switchActive_CAN_L ()

//Descripción función : Activa el corto a tierra en línea CAN_L

// CAN SW/CAN DW



s2g_switchInactive_CAN_H ()

//Descripción función : Inactiva el corto a tierra en línea CAN_H

// (Solo CAN DW)



s2g_switchInactive_CAN_L ()

//Descripción función : Inactiva el corto a tierra en línea CAN_L

// CAN SW/CAN DW



short2Ground_CAN_H (dword)

//Descripción función : Corto a tierra en línea CAN_H

//Parámetros de entrada : dword i_s2g_time_ms

//Descripción del parámetro : Tiempo en ms del corto a tierra



short2Ground_CAN_L (dword)

//Descripción función : Corto a tierra en línea CAN_L (CAN DW/SW)




class

Short2Ground_CAN

- s2g_switchActive_CAN_H()

- s2g_switchActive_CAN_L()

- s2g_switchInactive_CAN_H()

- s2g_switchInctive_CAN_L()

+ shor2Ground_CAN_H(dword)

+ short2Ground_CAN_L(dword)

121


[VT_ERS_04]

La clase Short2Ground_LIN permite realizar la un corto a tierra en una red de CAN de


Figura 76 - Clase Short2Ground_LIN


s2g_switchActive_LIN ()

//Descripción función : Activa el corto a tierra en línea LIN



s2g_switchInactive_LIN ()

//Descripción función : Inactiva el corto a tierra en línea LIN



short2Ground_CAN_LIN (dword)

//Descripción función : Corto a tierra en línea LIN





[VT_ERS_005]

La clase Short2Battery_CAN permite realizar la un corto a tierra en una red de CAN de


class

Short2Ground_LIN

- s2g_switchActive_LIN()

- s2g_switchInactive_LIN()

+ short2Ground_LIN(dword)

122

Figura 77 - Clase Short2Battery_CAN


s2b_switchActive_CAN_H ()

//Descripción función : Activa el corto a batería en línea CAN_H

// (Solo CAN DW)



s2b_switchActive_CAN_L ()

//Descripción función : Activa el corto a batería en línea CAN_L

// CAN SW/CAN DW



s2b_switchInactive_CAN_H ()

//Descripción función : Inactiva el corto a batería en línea CAN_H

// (Solo CAN DW)



s2b_switchInactive_CAN_L ()

//Descripción función : Inactiva el corto a batería en línea CAN_L

// CAN SW/CAN DW



short2Battery_CAN_H (dword)

//Descripción función : Corto a batería en línea CAN_H

//Parámetros de entrada : dword i_s2b_time_ms

//Descripción del parámetro : Tiempo en ms del corto a batería



short2Battery_CAN_L (dword)

//Descripción función : Corto a batería en línea CAN_L (CAN DW/SW)





[VT_ERS_006]

La clase Short2Battery_LIN permite realizar la un corto a tierra en una red de LIN.

class

Short2Battery_CAN

- s2b_switchActive_CAN_H()

- s2b_switchActive_CAN_L()

- s2b_switchInactive_CAN_H()

- s2b_switchInactive_CAN_L()

+ short2Battery_CAN_H(dword)

+ short2Battery_CAN_H(dword)

123

Figura 78 - Clase Short2Battery_LIN


s2b_switchActive_LIN ()

//Descripción función : Activa el corto a batería en línea LIN



s2b_switchInactive_LIN ()

//Descripción función : Inactiva el corto a batería en línea LIN



short2Battery_LIN (dword)

//Descripción función : Corto a batería en línea LIN





[VT_ERS_007] [VT_ERS_008]

La clase Power_Reset permite realizar corte a la alimentación de voltaje o reseteo a

una red de comunicación.

Figura 79 - Clase Power_Reset


power_reset (dword)

//Descripción función : Reseteo de voltaje de alimentación

//Parámetros de entrada : dword i_pr_time_ms

//Descripción del parámetro : Tiempo en ms del reseteo de alimentación


class

Short2Battery_LIN

- s2b_switchActive_LIN()

- s2b_switchInactive_LIN()

+ short2Battery_LIN(dword)

class

Power_Reset

+ power_reset(dword)

124



La clase WakeUp permite realizar la activación de comunicación en una red, una vez

y en cuando la red se encuentre desactivada.

Figura 80 - Clase WakeUp


wakeup (dword)

//Descripción función : Activación de comunicación de la red

//Parámetros de entrada : dword i_wakeup_time_ms

//Descripción del parámetro : Tiempo en ms de espera para la activación

// de la red




La clase Sleep permite realizar la desactivación de comunicación en una red, una vez

y en cuando la red se encuentre activada.

Figura 81 - Clase Sleep


sleep (dword)

//Descripción función : Desactivación de comunicación de la red

//Parámetros de entrada : dword i_sleep_time_ms

//Descripción del parámetro : Tiempo en ms de espera para la desactivación

// de la red



class

WakeUp

+ wakeup(dword)

class

Sleep

+ sleep(dword)

125

[VT_ERS_007] [VT_ERS_008] [VT_ERS_009] [VT_ERS_010] [VT_ERS_011] [VT_ERS_012]

La clase TurnOn_VT permite establecer la interface entre el ordenador y el equipo de

pruebas VT System. Necesaria para poder manipular las salidas de voltaje y crank de

una red automotriz.

Figura 82 - Interacción entre cases

int i_interconnectionMode

//Descripción del parámetro : Establece el modo para la interconexión de //

las fuentes de alimentación posibles y las //

dos salidas de potencia del módulo de

// potencia VT7001.

//Rango de entrada :

0 - Fuente de alimentación interna (modo supint)

1 - Fuente de alimentación 1 solamente (modo sup1)

2 - Fuente de alimentación 2 solamente (modo sup2)

3 - Dos fuentes de alimentación independientes para OUT1 y OUT2: fuente

de alimentación interna y fuente de alimentación 1 (modo supint_sup1)


de alimentación interna y fuente de alimentación 2 (modo supint_sup2)


de alimentación 1 y fuente de alimentación interna (modo sup1_supint)


de alimentación 1 y fuente de alimentación 2 (modo sup1_sup2)


de alimentación 2 y fuente de alimentación interna (modo sup2_supint)


de alimentación 2 y fuente de alimentación 1 (modo sup2_sup1)

9 - La fuente de alimentación 1 y la fuente de alimentación 2 están

conectadas en serie (sup_series)

10 - La fuente de alimentación 1 y la fuente de alimentación 2 están

conectadas en paralelo (sup_parallel)

class

Power_Reset

+ power_reset(dword)

Sleep

+ sleep(word)

WakeUp

+ wakeup(word)

TurnOn_VT

- i_interconnectionMode: int

- i_voltageRef_sup1: int

- i_voltageRef_supInt: int

+ interface_VT(int, int, int): int

- tunrOn_VT()

126

int i_voltageRef_sup1

//Descripción del parámetro : Establece el modo para la salida de voltaje

de referencia para controlar el voltaje de

salida de la fuente de alimentación 1.


0 - Salida de voltaje de referencia no activa

1 - Valor constante

2 - Forma de onda analógica

int i_voltageRef_supInt

//Descripción del parámetro : Establece el modo para la salida de voltaje

de referencia para controlar el voltaje de

salida de la fuente de alimentación interna.


0 - Salida de voltaje de referencia no activa

1 - Valor constante

2 - Forma de onda analógica

interface_VT (int, int, int)

//Descripción función : Establece el modo de conexión a utilizar

//Parámetros de entrada : int i_voltageRef_supInt

int i_voltageRef_sup1

int i_interconnectionMode

//Descripción del parámetro : Ver parámetros

//Rango de entrada : Ver parámetros

//Parámetros de salida :

0 - Llamada exitosa

1 - Error de llamada

2 - Comando no existe

3 - El modo especificado no es válido

turnOn_VT ()

//Descripción función : Activa módulo de potencia VT7001.



Adicionalmente se estableció una clase genérica mediante la cual permitir al sistema

tener la flexibilidad del uso de otro protocolo con principios de acceso al bus similares

a los protocolos CAN o LIN.

Figura 83 - Clase común para protocolos

class

Loss_Common

- closeCircuit()

+ lossOfCom(): dword

- openCircuit()

127


closeCircuit ()

//Descripción función : Cierra circuito



lossOfCom (dword)

//Descripción función : Perdida de comunicación





openCircuit ()

//Descripción función : Abre circuito



3.2.2. Diagramas eléctricos

La siguiente sección muestra los diagramas eléctricos de las interconexiones

implementadas entre el equipo VT System y el banco de pruebas.

128

CAN DW:

Figura 84 - Diagrama eléctrico CAN DW

129

CAN SW:

Figura 85 - Diagrama eléctrico CAN SW

130

Diagrama común:

Figura 86 - Diagrama eléctrico común para protocolos

131

LIN:

Figura 87 - Diagrama eléctrico LIN

132

Diagrama de activación y desactivación de bus:

Figura 88 - Diagrama activación y desactivación

3.2.3. Interfaz gráfica

La siguiente sección presenta las características básicas y el uso de la aplicación HMI

(Interfaz Hombre-Máquina) para el control de equipo de pruebas.

El diseño será implementado a través de un panel en una simulación de CANoe, que

permitirá ejecutar condiciones semejantes en un vehículo. El Panel será integrado a

una configuración de CANoe.

La validación del panel creado ejecuciones manuales se realizarán, los resultados

obtenidos serán comparados con los respectivos generados por el panel.

133

La siguiente tabla muestra las principales reglas a seguir durante el diseño de la

interface HMI.

Área Nombre Descripción

Percepción

Visual

Tamaño del

carácter

Es el tamaño de los carácter utilizados adecuado

según la fórmula:

𝐻 = 𝐴𝑥𝐷/3438

A es el ángulo (min).

H es el tamaño del carácter (cm).

D distancia entre el operador y el HMI (cm).

Color y Forma Es el texto no coloreado, en caso de serlo, se utiliza

algún método de codificación.

Memoria No se utilizan códigos de más de 5 caracteres.

Percepción Ambigüedad Existen ambigüedad, como textos no claros o

imágenes sin sentido

Consistencia Botones y Texto en la misma posición, alineados,

color, tipo, etc.

Claridad Se entienden todos los objetivos.

Gestalt Proximidad Es respetado el principio de Gestalt

Similitud Es respetado el principio de Gestalt

Continuidad Es respetado el principio de Gestalt

Cierra Es respetado el principio de Gestalt

Simetría Es respetado el principio de Gestalt

Figura/Fondo Es respetado el principio de Gestalt

Dirección Es respetado el principio de Gestalt

Estructura Visual Estructura Se está siguiendo una estructura adecuada para el

usuario.

134

Lenguaje Terminología Se utiliza algún término o vocabulario no

comprensible.

Fuente La fuente utilizada es adecuada para el usuario.

Textos Texto debe ser no centrado.

Visión y Color Color Se utilizan colores distintivos

Indicadores Evitar utilizar combinaciones que no sean visibles

para personas con daltonismo.

Combinaciones No utilizar solo color como indicador.

Memoria Textos No se deben utilizar indicaciones con textos largos.

Reconocimiento Iconos Se utilizan iconos estándar.

Tabla 10 - Reglas de diseño

La construcción del Panel fue realizada a través de la herramienta “Vector Panel

Designer”. El panel está dividido en 5 grupos:

• VT System: Se encarga de encender y apagar el equipo de pruebas, así

como seleccionar el modo de alimentación (Fuentes internas o externas).

• CAN: Se encarga de producir cortos a tierra, batería y abrir/cerrar circuito

en la comunicación CAN.

• LIN: Se encarga de producir cortos a tierra, batería y abrir/cerrar circuito

en la comunicación LIN.

• Battery Voltage: Se encarga de producir cortos a tierra, batería y abrir

circuito en las líneas de alimentación así como de regular el voltaje de

estas.

• Crank: Activa o desactiva la red de comunicación.

135

Figura 89 - Panel de control

3.3. IMPLEMENTACIÓN DE LA AUTOMATIZACIÓN

Una vez explicado el diseño e implementación del sistema, esta sección describe el

procedimiento mediante el cual la implementación de la automatización de pruebas

se ha conseguido.

3.3.1. Visión general

El diseño e implementación del proyecto no ha sido limitado a un proyecto o

producto en específico. Dentro de los diversos productos de Robert BOSCH México en

el área automotriz, este desarrollo ha sido aplicado dentro del grupo de Car

multimedia a un panel de instrumentos (IPC). Dicho proyecto es basado en un ciclo

de desarrollo basado en funcionalidades (59), es decir cada funcionalidad o

136

característica del proyecto es considerada una unidad de negocio, y esta debe ser

programada y probada de manera independiente. Cada unidad de negocio aparte

de ser probada funcionalmente es sometida a pruebas de no funcionales de:

Reseteo de alimentación

Pérdida de comunicación

Activación y desactivación (Sleep/Wake up)

Cambio de voltaje.

3.3.2. Procedimiento de pruebas anterior

En el procedimiento previamente usado, cada probador genera una especificación

de pruebas donde prueba todos los requerimientos de la funcionalidad, aunado a

esto el probador debe incluir las pruebas anteriormente mencionadas.

Posteriormente el probador genera guiones de pruebas para la ejecución automática

de los casos de prueba, a excepción de las pruebas no funcionales listadas, las cuales

el probador manualmente debe ejecutar. Todos los guiones de pruebas son realizados

en el lenguaje de programación CAPL y ejecutados utilizando CANoe.

La dependencia del probador durante cada ejecución era indispensable, debido a

la creación de guiones de pruebas semiautomáticos.

Estos guiones se mi automatizados consistían en guías que describían los pasos que el

probador debería realizar finalmente el guión pregunta al probador si tras realizar los

pasos el resultado obtenido era igual al esperado para finalmente crear un reporte

de todas las pruebas ejecutadas. Es así como los guiones tenían que ser

implementados de manera semi-automatizada y la dependencia del probador era

necesaria en todos los casos.

3.3.3. Cambio en el procedimiento de pruebas

El sistema de Automatización de Pruebas de Pérdida de Comunicación CAN/LIN y

Reseteo mediante VT System permite al probador incluir dentro de sus guiones de

pruebas las funciones establecidas para el uso del equipo de pruebas VT System.

137

Una vez que el probador se dispone a ejecutar las pruebas basta con que conecte

su equipo de cómputo al sistema VT System el cual se encuentra interconectado a un

banco de pruebas con el ECU a probar (para este caso el panel de instrumentación)

junto al resto de ECUs pertenecientes a su red vehicular, permitiendo así una ejecución

dentro de un ambiente cercano al real.

Si una prueba es detectada como fallida el probador utiliza el panel de control

implementado para validar la certeza de la falla y con esto crear un defecto nuevo

en el sistema.

Figura 90 - Implementación de funciones

3.3.4. Medición

Para la medición entre los cambios de procedimientos, se enfoca en tres principales

fases afectadas y los tiempos de operación invertidos por el probador en cada una

de ellas:

1. Implementación de guiones

2. Preparación del ambiente de pruebas

138

3. Ejecución de pruebas

La implementación de guiones consiste en tiempo en el cual el probador genera los

guiones de pruebas.

La preparación del ambiente de pruebas es el montaje, instalación y conexión del

banco de pruebas y el equipo de cómputo.

Por último la medición de la ejecución de pruebas se basará en el tiempo del

probador invertido para esta acción.

Este tipo de pruebas se ejecutan sobre dos escenarios, una ejecución única en una

funcionalidad y una ejecución continua (largo plazo).

Las mediciones fueron tomadas en una población de cuatro probadores con diez

muestras. Los valores obtenidos han sido promediados para un fácil análisis.

139

4. RESULTADOS

A partir de la implementación realizada la siguiente sección muestra los datos

obtenidos, resultados actuales y comparación entre el procedimiento manual de

pruebas y el cambio con la implementación del sistema de automatización

desarrollado.

A continuación se presentan las tiempo tomadas de las fases de pruebas afectadas

antes de implementar el proceso de automatización y las posteriores a este, también

se analizaran las ventajas cualitativas respecto a la diferencia entre la

implementación y el proceso manual, los retornos de inversión del costo del equipo

de pruebas VT System así como las nuevas pruebas ejecutadas posterior a dicha

implementación así, finalmente los defectos en el software detectados y el alcance

de los objetivos e hipótesis planteados.

4.1. REDUCCIÓN DE TIEMPOS

Una vez realizada la automatización en las pruebas de pérdida de comunicación,

desactivación y activación así como reseteo de alimentación los resultados siguientes

fueron obtenidos:

1. Los tiempos promedio en la preparación de pruebas se mantienen (ver tabla

2, 4 y 6).

2. El tiempo invertido por el probador durante la ejecución de pruebas se

eliminan (ver tabla 2, 4 y 6).

3. Ejecuciones de pruebas continuas solo requieren un esfuerzo mínimo del

probador durante la preparación (ver tabla 3, 5 y 7).

Pérdida de Comunicación Manual Pérdida de Comunicación Automatizada

Preparación

manual

Ejecución manual Preparación

automatización

Ejecución

automatizada

01:23 01:31 01:23 00:00

Tabla 11 - Reducción de tiempo en pruebas de pérdida de comunicación

140

Repetición

Pérdida de Comunicación Manual Pérdida de Comunicación Automatizada

Preparación

manual

Ejecución

manual

Preparación

automatización

Ejecución

automatizada

1 01:23 01:31 01:23 00:00

2 01:23 03:02 00:00 00:00

3 01:23 04:33 00:00 00:00

4 01:23 06:04 00:00 00:00

5 01:23 07:35 00:00 00:00

6 01:23 09:06 00:00 00:00

7 01:23 10:37 00:00 00:00

8 01:23 12:08 00:00 00:00

9 01:23 13:39 00:00 00:00

10 01:23 15:10 00:00 00:00

Tabla 12 - Reducción de tiempo en pruebas continúas de pérdida de comunicación

Figura 91 - Reducción de tiempo en pruebas continúas de pérdida de comunicación

Activación/Desactivación Manual Activación/Desactivación Automatizada

Preparación

manual


automatización

Ejecución

automatizada

01:23 02:43 01:23 00:00

Tabla 13 - Reducción de tiempo en pruebas activación y desactivación

00:00

02:24

04:48

07:12

09:36

12:00

14:24

16:48

0 2 4 6 8 10 12

Perdida de Comunicación

Preparación manual Ejecución manual

Preparación automatización Ejecución automatizada

141

Repetición

Activación/Desactivación Manual Activación/Desactivación

Automatizada

Preparación

manual

Ejecución

manual

Preparación

automatización

Ejecución

automatizada

1 01:23 00:02:43 01:23 00:00

2 01:23 00:05:26 00:00 00:00

3 01:23 00:08:09 00:00 00:00

4 01:23 00:10:52 00:00 00:00

5 01:23 00:13:35 00:00 00:00

6 01:23 00:16:18 00:00 00:00

7 01:23 00:19:01 00:00 00:00

8 01:23 00:21:44 00:00 00:00

9 01:23 00:24:27 00:00 00:00

10 01:23 00:27:10 00:00 00:00

Tabla 14- Reducción de tiempo en pruebas continúas de activación y desactivación

Figura 92 - Reducción de tiempo en pruebas continúas de activación y desactivación

Reseteo de alimentación manual Reseteo de alimentación automatizada

Preparación

manual


automatización

Ejecución

automatizada

01:23 01:04 01:23 00:00

Tabla 15 - Reducción de tiempo en pruebas de reseteo

00:00

00:14

00:28

00:43

00:57

01:12

01:26

01:40

0 2 4 6 8 10 12

Activación/Desactivación



142

Repetición

Reseteo de alimentación manual Reseteo de alimentación

automatizada

Preparación

manual

Ejecución

manual

Preparación

automatización

Ejecución

automatizada

1 01:23 01:04 01:23 00:00

2 01:23 02:08 00:00 00:00

3 01:23 03:12 00:00 00:00

4 01:23 04:16 00:00 00:00

5 01:23 05:20 00:00 00:00

6 01:23 06:24 00:00 00:00

7 01:23 07:28 00:00 00:00

8 01:23 08:32 00:00 00:00

9 01:23 09:36 00:00 00:00

10 01:23 10:40 00:00 00:00

Tabla 16 - Reducción de tiempo en pruebas continúas de reseteo

Figura 93 - Reducción de tiempo en pruebas continúas de reseteo

Las pruebas individuales descritas son ejecutadas en conjunto dentro la misma ronda

de pruebas, así el tiempo ahorrado total es la sumatoria del ahorro de cada una de

ellas. Mientras tanto las pruebas de larga duración son ejecutadas diariamente, para

este cálculo son dejadas fuera debido a que son pruebas implementadas a partir del

desarrollo de la automatización como se verá en las siguientes secciones.

00:00

01:12

02:24

03:36

04:48

06:00

07:12

08:24

09:36

10:48

12:00

0 2 4 6 8 10 12

Reseteo de alimentación



143

𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜

= 𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜 𝑝𝑟𝑢𝑒𝑏𝑎 𝑑𝑒 𝑟𝑒𝑠𝑒𝑡𝑒𝑜

+ 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 𝑝𝑟𝑢𝑒𝑏𝑎 𝑑𝑒 𝑎𝑐𝑡𝑖𝑣𝑎𝑐𝑖ó𝑛

+ 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 𝑝𝑟𝑢𝑒𝑏𝑎 𝑑𝑒 𝑝é𝑟𝑑𝑖𝑑𝑎 𝑑𝑒 𝑐𝑜𝑚𝑢𝑛𝑖𝑐𝑎𝑐𝑖ó𝑛

= 1: 04𝑚𝑖𝑛 + 1: 31 + 2.43 = 4: 14 𝑚𝑖𝑛

Actualmente el departamento de pruebas es responsable de probar 85

funcionalidades por lo tanto el ahorro por ejecución de pruebas es:

𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜 𝑟𝑜𝑛𝑑𝑎 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠

= 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 ∗ 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑓𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑𝑒𝑠 𝑝𝑟𝑜𝑏𝑎𝑑𝑎𝑠 = 4: 14 𝑥 ∗ 85

≈ 360 min ≈ 6 ℎ𝑟𝑠

El proyecto del panel de instrumentos contempla 1,434 funcionalidades disponibles

una completa implementación del sistema generaría un ahorro de:

𝑇𝑖𝑒𝑚𝑝𝑜 𝑚á𝑥𝑖𝑚𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 = 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 ∗ 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑓𝑢𝑛𝑐𝑖𝑜𝑛𝑎𝑙𝑖𝑑𝑎𝑑𝑒𝑠 𝑑𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑙𝑒𝑠

= 4: 14 𝑥 ∗ 1,434 ≈ 360 𝑚𝑖𝑛 ≈ 6,065 ℎ𝑟𝑠

4.2. VENTAJAS OBTENIDAS

Una vez realizada la investigación a fondo e implementado el sistema de

automatización fue posible generar un cambio en los procedimientos para realizar las

pruebas de pérdida de comunicación.

Debido a las anteriores limitaciones para realizar una prueba de pérdida de

comunicación se tenían dos escenarios:

1) Dentro de un banco de pruebas completamente simulado a través del

ordenador.

2) Dentro de un banco de pruebas con ECU pertenecientes a la red.

En el primer caso, las pruebas realizadas al ECU (IPC, panel de instrumentos) se basan

en la desconexión de la herramienta transmisora mediante la cual se simula el bus

completo de CAN o LIN, debido a la generación de esta desconexión se enfrentaban

dos problemas comunes; la simulación perdía su único ECU destinatario produciendo

144

paros en la ejecución, o la reactivación de la transmisión no se podía llevar a cabo

por errores en la herramienta resultado de la desconexión.

Cuando el entorno de la ejecución consistía en una red con ECU fiscos, la única

manera de producir esta pérdida de comunicación era la desconexión del arnés, el

cual incluye todas las entradas al ECU, alimentación redes de comunicación (CAN,

LIN, Ethernet) y sensores externos. Considerando este tipo de procedimientos una

prueba de pérdida de comunicación que afectará únicamente las líneas de

comunicación de CAN o LIN era imposible.

De este modo con la implementación se consiguió:

1) Generar pruebas basadas en los principios de acceso al bus.

2) Eliminar errores debido las herramientas de transmisión datos.

3) Ejecutar pruebas de pérdida de comunicación en un ambiente cercano al real

interfiriendo únicamente en las líneas de transmisión de datos.

4.3. NUEVAS PRUEBAS EJECUTADAS

Con las ventajas obtenidas a través de la correcta implementación fue capaz de

introducir nuevas pruebas. Debido a que en el procedimiento manual anterior era

imposible realizar pruebas de larga duración, la dificultad de mantener a un probador

durante periodos de tiempo mayores unos cuantos minutos limitaba la ejecución de

pruebas de larga duración (horas o días) y pruebas de estrés. El sistema permitió incluir

dentro del plan de pruebas:

1) Pruebas nocturnas (hasta 14 horas de ejecución).

a. Diversas funcionalidades controladas por el equipo VT System.

2) Pruebas de estrés (2 hasta 72 horas).

a. Pérdida continúa de comunicación de CAN durante operación

normal.

b. Pérdida continúa de comunicación de LIN durante operación normal.

c. Reseteo continúo de alimentación durante operación normal.

d. Activación y desactivación del bus durante operación normal.

145

e. Corto a tierra de líneas de CAN.

f. Corto a batería de las líneas de CAN.

g. Corto a tierra de líneas de LIN.

h. Corto a batería de las líneas de LIN.

Aunado a las pruebas mencionadas, durante la definición de los requisitos del sistema

se definió este como un sistema abierto que tuviera la capacidad de utilización dentro

de otros protocolos con principios similares. Es así como dentro del diseño se

implementó una sección con funciones comunes sin propósito específico.

Dentro del proyecto del panel de instrumentos (IPC) en el cual la automatización fue

realizada, existen tres protocolos de comunicación utilizados: CAN, LIN y Ethernet, de

este modo dichas funciones generales fueron empleadas en el protocolo de Ethernet,

con ello se logró incluir las siguientes nuevas pruebas:

1) Pérdida continúa de comunicación de Ethernet durante operación normal.

2) Corto a tierra de líneas de Ethernet.

3) Corto a batería de las líneas de Ethernet.

4.4. RETORNO DE INVERSIÓN (ROI)

En esta sección se analizará los costos de inversión del equipo VT System y su retorno

de inversión tras el análisis de reducción de tiempos.

Descripción Precio USD

VT System - Estuche de 6 ranuras. $425.00

VT8006 - Tarjeta posterior con 6 ranuras para el sistema VT. $585.00

VT7001A - Módulo de potencia de VT Sistema para controlar las líneas de

alimentación de las ECU.

$2,655.00

VT2820 - Módulo de relés de propósito general del sistema VT. $1,530.00

Total $5,195.00

Tabla 17 - Costos del equipo VT System

146

Descripción Precio USD

Hora ingeniería $570.00

Total $570.00

Tabla 18 - Costo por hora ingeniería de trabajo

Con los costos del equipo y el costo de hora ingeniería del probador podemos

determinar el tiempo de ejecución automatizada necesaria para recuperar la

inversión.

𝑅𝑂𝐼 =𝑐𝑜𝑠𝑡𝑜 𝑑𝑒 𝑖𝑛𝑣𝑒𝑟𝑠𝑖𝑜𝑛

ℎ𝑜𝑟𝑎 𝑖𝑛𝑔𝑒𝑛𝑖𝑒𝑟𝑖𝑎=

$ 5,195

$ 570/ℎ= 9.11ℎ𝑟

Considerando una prueba de larga duración el costo se cubriría inmediatamente.

Debido a que estas pruebas fueron introducidas a partir de la aplicación desarrollada

consideraremos únicamente las pruebas individuales para este cálculo.

𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 =𝑅𝑂𝐼

𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜=

546.6 𝑚𝑖𝑛

4.23 𝑚𝑖𝑛≈ 130

Basados en este cálculo serían necesarias 130 ejecuciones de alguna funcionalidad.

𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑜𝑛𝑑𝑎𝑠 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎 =𝑅𝑂𝐼

𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜 𝑟𝑜𝑛𝑑𝑎 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠=

9.11 ℎ𝑟𝑠

6 ℎ𝑟𝑠≈ 1.5

4.5. DEFECTOS ENCONTRADOS

A través de las pruebas ejecutadas estos algunos de los principales defectos

encontrados:

Gráficos se reinician con estrés de activación y desactivación.

IPC se reinicia durante una curva de voltaje.

Datos no son retenidos después de reseteos de alimentación.

Datos no son retenidos después de ciclos de activación y desactivación.

Unidades no son mostradas después de un reseteo de alimentación.

Congelamiento de la pantalla después de un reseteo de alimentación.

Alertas no son mostradas después de reseteo de alimentación.

Comunicación de LIN no es establecida después de reseteos de

alimentación.

147

Comunicación de LIN no es establecida después de ciclos de activación y

desactivación.

Códigos de error de pérdida de comunicación no son registrados.

Mecanismo de re-suscripción de Ethernet no son llevados a cabo.

Configuraciones de usuario no son retenidos después de ciclos de activación

y desactivación.

149

5. CONCLUSIONES

Mediante la investigación realizada fue posible alcanzar el objetivo principal

establecido, automatizar pruebas utilizando el equipo VT System, consiguiendo con

ella una exitosa puesta en marcha. Dicha automatización fue lograda utilizando los

módulos VT2820 y VT7001, implementando los cuatro tipos de pruebas establecidas

inicialmente dentro de los objetivos específicos:

Pérdida de comunicación CAN (Controller Area Network) utilizando el módulo

VT2820.

Pérdida de comunicación LIN (Local Interconnect Network) utilizando el

módulo VT2820.

Reseteo de alimentación utilizando el módulo VT7001.

Ciclos activación y desactivación utilizando el módulo VT7001.

Basado en los resultados expuestos en la sección de resultados la presente

investigación demostró al lograr una automatización de pruebas, que los tiempos de

ejecución manual se limitaron al tiempo de ajuste del equipo. También al lograr una

automatización de pruebas se consiguió el retorno de inversión del equipo VT System.

El éxito de la investigación fue conducido por el ambiente expuesto en la sección de

procedimiento de la investigación, el cual considera un amplio campo de utilización

dentro de múltiples redes de comunicación utilizadas en el ámbito automotriz. Basado

en los principios de acceso a bus y las topologías expuestas en el marco referencial

fue posible generar pruebas con los procedimientos adecuadas, es decir asegurarse

que la prueba realmente se enfoque en el objetivo de la misma sin producir algún

falso negativo o positivo. Así, mediante la implementación de la automatización se

logró eliminar errores de ejecución. Por ejemplo, las pruebas de pérdida de

comunicación permiten validar el acceso a los buses de datos y los sistemas

anticolisiones descritos, donde el retiro de un nodo no afecta a la red, eran realizadas

con malos procedimientos (resultado expuesto en la sección de ventajas obtenidas).

150

De igual manera ya se ha hecho mención de nuevas pruebas las cuales fueron

posibles de alcanzar, dichas pruebas basadas y descubiertas tras el análisis de las

especificaciones de los protocolos. Es así como las pruebas de cortos a tierra y batería

permiten validar la correcta implementación de los controladores de los protocolos

(CAN y LIN). Mecanismos como el relleno de bits es posible de validar introduciendo

ruido a través de las pruebas cortos a tierra y batería. Este tipo de pruebas también

permiten validar la desactivación de un nodo en caso de entrar en modo de error, y

de esta manera no afectar el funcionamiento de la red.

Podemos definir el término de esta investigación no solo con el cumplimiento de los

objetivos planteados los cuales lograron la validación de nuestra hipótesis, sino

también con una cobertura mayor a la prevista, alcanzada tras el análisis de la

especificación de los protocolos. Es importante mencionar el punto de la satisfacción

del cliente y el incremento en la calidad del producto, mediante este tipo de pruebas

no funcionales es posible detectar errores en el desempeño del software el cual se

traduce en una mayor robustez del sistema y confiabilidad del sistema, permitiendo la

generación de confianza al cliente. Con ello generando atracción de nuevos

proyectos y desarrollo de la empresa.

151

6. RECOMENDACIONES

Esta investigación puede ser utilizada como base para la automatización de más tipos

de pruebas no funcionales. Se recomienda utilizar las bases y los principios estudiados

para la extensión a diferentes protocolos como MOST, FlexRay, Ethernet por

mencionar algunos. Es conveniente continuar con la investigación desarrollada

incluyendo más módulos del equipo VT, actualmente esta investigación considero

únicamente dos módulos de seis posibles.

Así mismo como se mencionó en la sección de resultados y conclusiones este

proyecto ha sido aplicado a un solo ECU dentro de la red enorme dentro de un

vehículo por lo que la implementación de este sistema en el resto de sistemas

desarrollado por Robert BOSCH México traería grandes ventajas y resultados para la

empresa. También es altamente recomendable la utilización de esta investigación en

las etapas tempranas de desarrollo de un proyecto, incluyendo la mayor cantidad de

características del sistema para ser probadas.

Por último cabe resaltar que esta investigación ha llamado la atención dentro de la

compañía y el interés de la misma. Esta ha servido como una demostración del

alcance del equipo de pruebas de la localidad y con ellos la atracción de nuevos

proyectos.

153

7. REFERENCIAS BIBLIOGRÁFICAS

1. NU. CEPAL. División de Desarrollo Productivo y Empresarial. Informe sobre la industria. Santiago de

Chile : CEPAL, 2005. 9213226934.

2. Barrera Franco, Adriana y Pulido Morán, Alejandro. LA INDUSTRIA AUTOMOTRIZ MEXICANA:

SITUACIÓN ACTULA, RETOS Y OPORTUNIDADES. Ciudad de México : ProMéxico, 2016. 978-607-97294-

2-4.

3. Galeano, Gustavo. Programcación de sistemas embebidos en C, teoría y práctica aplicada a

cualquier microcontrolador. 1. Mexico : Alfaomega Grupo Editor, S.A. de C.V., 2009. pág. 544. 978-

958-682-770-6.

4. A. P. Godse, A. O. Mulani. Embedded Systems. Pune : Technical Publications Pune, 2009. 978-818-

431-713-8.

5. ISO 26262-1-2011(E) Road vehicles - Functional safety. 2011 : s.n.

6. Wang, K.C. Embedded and Real-Time Operating Systems. Switzerland : Springer, Cham, 2015. 978-

3-319-51516-8.

7. Robert Bosch GmbH. Bosch Automotive Electrics and Automotive Electronics. Wiesbaden : Springer

Vieweg, 2014. 978-3-658-01783-5.

8. Forouzan, Behrouz. Data communications and networking. New York : McGraw-Hill, 2007. 978-0-

07-296775-3.

9. Network Structure or Topology. Pandya, Kartik. 2, Gangtok : International Journal of Advance

Research in Computer Science and Management Studies, 2013, Vol. 1. 2321-7782.

10. M, Kaiser. Gasoline Engine Management. Bosch Professional Automotive Information.

Wiesbaden : Springer Vieweg, 2015. 978-3-658-03963-9.

11. W Valvano, Jonathan. Embedded Systems: Introduction to ARM Cortex-M Microcontrollers. Texas :

CreateSpace Independent Publishing Platform, 2012. 978-1463590154.

12. Kozierok, Charles M., y otros. Automotive Ethernet - The Definitive Guide. USA : Intrepid Control

Systems, 2014. 978-0990538806.

13. Buehrer, R. Michael. Code Division Multiple Access (CDMA). Virginia : Morgan & Claypool, 2006.

9781598290400.

14. Hekmat, Sharam. Communication Networks. [www.pragsoft.com/books/CommNetwrok.pdf] s.l. :

PragSoft Corporation, 2005.

154

15. Voss, Willfried. A comprehensible guide to controller area network. 2. Greebfield : Copperhill

Media Corporation, 2005. 978-0976511601.

16. Jenq, Yih-Chyun. Theoretical Analysis of Slotted ALOHA, CSMA, and CSMA-CD Protocols. New

York : Springer, 1986. 978-1-4612-9354-5.

17. Paret, Dominic. Multiplexed Network for embedded systems CAN, LIN, Flexray, safe-by-wire...

Paris : John Wily & Sons Ltd, 2007. 978-0-7680-1938-4.

18. St, IEEE. IEEE 802.11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)

Specifications. 2012.

19. Wang, X. & Giannakis, G.B. J. Wireless Com Network (2006) 2006: 039604. .

[https://doi.org/10.1155/WCN/2006/39604] s.l. : Springer International Publishing, 2006. 1687-1499.

20. H, Omar y W., Zhuang. Time Division Multiple Access For Vehicular Communications. Cham :

Springer, 2014. 978-3-319-09503-5.

21. ISO: Information Technology—Open Systems Interconnection—Basic Reference Model: The Basic

Model. Geneva, Standard ISO/IEC 7498-1(E). 1994.

22. Design of distributed applications based on the OSI model. McBrien, Peter. Berlin : Springer, 1997,

Vol. 1250. 978-3-540-63107-1.

23. Alani, M.M. OSI Model. In: Guide to OSI and TCP/IP Models. Cham : Springer, 2014. 978-3-319-

05151-2.

24. Tadimety, Phani Raj. The OSI Model—A Closer Look. In: OSPF: A Network Routing Protocol. .

Berkeley : Apress, 2015. 978-1-4842-1411-4.

25. Kopetz, Hermann. Real-Time Systems, Design Principles for Distributed Embedded Applications. 0-

792-39894-7 : Kluwer Academic Publishers, 2002. 0-792-39894-7.

26. Limam, Mourad. A New Approach for Gateway-based Automotive Network Architectures.

Dresden : expert-Verlag, 2010. 9-783-816930-297.

27. CAN System Engineering. Reichart G., Leen G., Courmont N., Knüppel R., Schmid C., Brockmann M.

London : Springer, 2013. 978-1-4471-5612-3.

28. Archambeault B., Ramahi O.M., Brench C. Introduction. In: EMI/EMC Computational Modeling

Handbook. Boston : Springer, 1998. 978-1-4757-5126-0.

29. Schubert M., Boche H. Introduction. In: Interference Calculus. Foundations in Signal Processing,

Communications and Networking,. Berlin : Springer, 2012. Vol. 7. 978-3-642-24620-3.

30. Obermaisser, Roman. Time-triggered communication. New York : CRC Press Taylor & Francis

Group, 2012. 97-4398-4662-9.

155

31. Evaluation and Comparison of the Real-Time Performance of CAN and TTCAN. A., Albert y W.,

Gerth. Munich : 9th international CAN in Automation Conference, 2003.

32. Comparison of event-triggered and time-triggered concepts. A., Albert. Nürnberg : Embedded

World Conf. 2004, 2004.

33. Scheduling of event-triggered controllers on a shared network. Cervin, Anton y Henningsson,

Toivo. Cancun : Decision and Control, 2008. CDC 2008. 47th IEEE Conference on, 2008. 0191-2216.

34. Dean, Tamara. Network+ guide to networks. Boston : Course Technology, Cengage Larning, 2013.

978-1-133-60819-6.

35. Electronic control units for automotive electrical power systems: Communication and networks. A

Shrinath, A Emadi. 11, s.l. : Proceedings of the Institution of Mechanical Engineers, Part D: Journal of

Automobile Engineering, Vol. 218.

36. Controller area network [automotive applications]. Navet, N. 4, s.l. : IEEE Potentials , 1998, Vol. 17.

0278-6648.

37. Instrument, National. NI Special CAN bus features. Presentation. 2007.

38. Johansson K.H., Törngren M., Nielsen L. Handbook of Networked and Embedded Control Systems.

s.l. : Birkhäuser Boston, 2005. 978-0-8176-3239-7.

39. H. F. Othman, Y. R. Aji, F. T. Fakhreddin, A. R. Al-Ali. Controller Area Networks: Evolution and

Applications. s.l. : Information and Communication Technologies, 2006. ICTTA '06. 2nd. 0-7803-9521-

2.

40. ISO. ISO-11898-1 Road vehicles — Controller area network (CAN) — Part 1: Data link layer and

physical signalling. 2015.

41. Natale M.D., Zeng H., Giusto P., Ghosal A. The CAN 2.0b Standard. In: Understanding and Using

the Controller Area Network Communication Protocol. New York : Springer, 2012. 978-1-4614-0313-5.

42. Park, Kiejin y Kang, Minkoo. Advanced Bit Stuffing Mechanism for Reducing CAN Message

Response Time, Automation. Korea : InTech, 2012. Kiejin Park and Minkoo Kang.

43. Etschberger, K. Controller Area Network (CAN): Basics, Protocols, Chips, and Applications.

Weingarten : IXXAT Automation GmbH, 2001. 978-3000073762.

44. Implementation of Controller Area Network (CAN) Bus (Building Automation). In: Unnikrishnan S.,

Surve S., Bhoir D. (eds) Advances in Computing, Communication and Control. Communications in

Computer and Information Science. Shweta S.A., Mukesh D.P., Jagdish B.N. s.l. : Springer, Berlin,

Heidelberg, 2011, Vol. 125. 978-3-642-18439-0.

156

45. Controller area network (CAN) for computer integrated manufacturing systems. Journal of

Intelligent Manufacturing. Çenesİz, N. & Esin, M. 4, Gebze-Kocaeli : Kluwer Academic Publishers,

2004, Vol. 15. 0956-5515.

46. Frontiers of Information Technology & Electronic Engineering: Frontiers of Information Technology

& Electronic Engineering. Wu, Y. & Chung, JG. 1, Jeonju : Zhejiang University Press, 14, Vol. 16. 2095-

9184.

47. Real-Time Systems: Robust priority assignment for messages on Controller Area Network (CAN).

Davis, Robert I y Burns, Alan. 2, York : Springer US, 2009, Vol. 41. 0922-6443.

48. Kraft, D. Controller Area Network (CAN), In: Gevatter HJ., Grünhaupt U. (eds) Handbuch der Mess-

und Automatisierungstechnik im Automobil. Berlin : Springer, Heidelberg, 2016. 978-3-540-21205-8.

49. Digital Signal Transmission Using a Multilevel NRZ Coding Technique. In: Shah K., Lakshmi Gorty

V.R., Phirke A. (eds) Technology Systems and Management. Communications in Computer and

Information Science. Kulkarni, V., y otros. Berlin : Springer, 2011, Vol. 145. 978-3-642-20208-7.

50. Using bit-stuffing distributions in CAN analysis, IEEE/IEE Real-Time Embedded Systems Workshop

(RTES’01). Nolte, T., y otros. 2011 : s.n.

51. CAN System Engineering: From Theory to Practical Applications. Wolfhard, L. s.l. : Springer, 1997.

978-0387949390.

52. Probabilistic worst-case response-time analysis for the controller area network, in Real-Time and

Embedded Technology and Applications Symposium. Nolte, T., Hansson, H. y & Norstrom, C. Toronto :

IEEE, 2003. 1545-3421.

53. International., SAE. J2411_200002 - Single Wire Can Network for Vehicle Applications. s.l. : SAE

International., 2000.

54. CiA. SAE J2411 single wire. can-cia.org. [En línea] CAN in Automation., 04 de Febrero de 2018.

[Citado el: 04 de Febrero de 2018.] https://www.can-cia.org/can-knowledge/can/sae-j2411-single-

wire/.

55. Local Interconnect Networking. In: Automotive Mechatronics: Operational and Practical Issues.

Intelligent Systems, Control and Automation: Science and Engineering. Fijalkowski, B. Dordrecht :

Springer, 2011. 978-94-007-0408-4.

56. Consortium, LIN. LIN Specification Package. [www.lin-subbus.org] 2010. Vol. Revision 2.2A.

57. 830-1998 - IEEE Recommended Practice for Software Requirements Specifications. s.l. : IEEE, 1998.

978-0-7381-0448-5.

58. ISO 13407:1999 Human-centred design processes for interactive systems. s.l. : International

Organization for Standardization, 1999.

157

59. Palmer, Stephen R. y Felsing, John M. Practical Guide to Feature-Driven Development. s.l. :

Prentice Hall, 2002. 978-0130676153.

AUTOMATIZACIÓN DE PRUEBAS DE PÉRDIDA DE … · tesis maestro en sistemas inteligentes multimedia...

Documents

Transcript of AUTOMATIZACIÓN DE PRUEBAS DE PÉRDIDA DE … · tesis maestro en sistemas inteligentes multimedia...