AUTOMATIZACIÓN DE PRUEBAS DE PÉRDIDA

DE COMUNICACIÓN CAN/LIN, RESETEO Y

DESACTIVACIÓN/ACTIVACIÓN EN SISTEMAS
AUTOMOTRICES EMBEBIDOS

TESIS
PARA OBTENER EL GRADO DE

MAESTRO EN
SISTEMAS INTELIGENTES MULTIMEDIA

PRESENTA

I.M.T HUMBERTO ISAAC FLORES BERMEJO

ASESOR: NOÉ VILLA VILLASEÑOR
<noe.villa@ciateq.mx>

ZAPOPAN, JALISCO, JULIO 2018.

I
II
III
IV
 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.

V
VI
 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.

VII
VIII
 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.

IX
X
 Í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
XI
 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

XII
 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

XIII
XIV
 Í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
XV
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

XVI
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

XVII
XVIII
 Í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

XIX
XX
 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).

XXI
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).
XXII
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).

XXIII
XXIV
 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).

XXV
XXVI
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

1
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.

2
 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.

3
 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.

4
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.

5
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

6
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.

7
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.

8
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.

9
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.

10
Figura 5 - Topología malla

2.2.1.5. Hibrida

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

11
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

12
 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).

13
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.

14
 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

15
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).

16
 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

17
 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

18
 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).

19
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

20
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

21
 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.

22
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

23
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 𝑇𝑔
𝑅𝑏 = [ − ] 𝑅 𝑆 𝑏
𝐾 𝑇𝑓

24
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.

25
 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.

26
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.

27
  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) .

28
 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.

29
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.
30
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
31
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

32
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).

33
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.

34
  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.

Característica Requisitos Duros Requisitos Suaves

Respuesta de tiempo Altamente requerido Deseable
Rendimiento de carga Predecible Degradable
máxima
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
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).

35
 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
36
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

37
 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

38
 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.

39
 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 Aplicaciones Protocolo

transferencia
A 10 Kbits/s Actuadores y sensores. LIN
B 125 Kbits/s Mecanismos de manejo de error ECUs de CAN baja
manejo de funciones de confort. velocidad /
FlexRay
C 10 Mbit/s Aplicaciones de tiempo real ECU para el CAN alta
manejo de funciones de manejo y motor. velocidad
D >10 Mbit/s ECU para el manejo de funciones MOST
multimedia.
Tabla 2 - Clasificación del bus de CAN

40
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

41
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

42
 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.
Algunos ejemplos son:
 Aire Acondicionado (AC)

43
  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.

Algunos ejemplos son:

 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.

44
 CAN Alta
CAN Baja Velocidad LIN TTP MOST Bus Flexray
Velocidad
Sistemas de
Protocolo de
Red de Área Red de interconexión Transporte
Definición Red de Área Controlada activación por Nombre Propio
Controlada local Orientados a los
tiempo
Medios

Convencional y
Tipo de BUS Convencional Convencional Convencional Óptico Convencional y Óptico
Óptico

Multimedia y
Domino Transmisión Confort Confort Redes de Seguridad Todos los Dominios
Infotainment

Control del Redes en entornos

Aplicaciones simples
motor, Aplicaciones sencillas relacionados con la Transmisión de audio
Aplicaciones Confort y Comodidad relacionadas con
transmisión y de bajo costo seguridad como y video
seguridad
redes ABS / ESP frenos
Topología Bus Bus Bus Estrella Anillo Estrella

Velocidad de
10 kbit/s - 1Mbit/s Max. 125 kbit/s Max. 20 kbit/s 10 Mbit/s Max. 22.5 Mbit/s 10 - 20 Mbit/s
Transferencia

Número
22 (Teóricamente
Máximo de 10 24 16 - 64
hasta 2,048)
Nodos

Mecanismo Activada por Activada por Activada por Activada por

Activada por Eventos Activada por Tiempo
de Control Eventos Tiempo Tiempo/Eventos Tiempo/Eventos

Número de
Par Cruzado Par Cruzado Cable Simple Par Cruzado Fibra óptica Par Cruzado
Líneas

Especificación del
Protocolo de
Paquete de protocolo del sistema
Estándar ISO 1198 ISO 11 519-2 activación por Especificación MOST
especificaciones LIN de comunicaciones
tiempo TTP / C
FlexRay
Clasificación
Clase C Clase B Clase A - - -
SAE
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

45
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,

46
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.
Especificación de CAN extendido 2.0.
1991
Lanzamiento del primer vehículo - Mercedes class S, 5 unidades comunicadas
1992 Creación de CiA (Can en Automatización).
Creación de grupo OSEK (Sistemas abiertos y sus interfaces para electrónicos en
1993
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).

47
2003 CAN es utilizado por todas las compañías automotrices.
La producción anual de vehículos es de 65-67 millones con 10-15 nodos de CAN en
2008
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.

48
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).

49
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).

50
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).

51
 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).

52
 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

53
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).
54
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.
55
 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).

56
 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).
57
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:

58
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

59
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.
DLC3 DLC2 DLC1 DCL0 Bytes
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

60
 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).

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
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

61
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).

62
 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

63
 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).

64
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).

65
 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).

66
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

67
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

68
 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

69
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:

70
 𝑔 + 8s − 1
𝑔 + 8𝑠 + 13 +
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).

71
 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).

72
 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.
73
 • 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).

74
 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).

75
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).

76
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).

77
 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

78
 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).

79
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

80
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
• 250 kBits / s hasta 250 m
• 125 kBits / s hasta 500 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).

81
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

82
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

83
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.

84
  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

85
 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

86
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

87
 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).

88
 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).

89
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).

90
 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).

91
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).

92
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)

93
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

94
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).

95
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).

96
 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.

97
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).

98
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.

99
 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
100
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).

101
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).

102
 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).

103
 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).

104
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

105
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).
106
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).

Dato 1 Dato 2 Dato 3 Dato 4 Dato 5 Dato 6 Dato 7 Dato 8

0 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

Tabla 7- Comando para ir a modo inactivo

107
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).

108
 response_error Interpretación
Falso el nodo esclavo está funcionando correctamente
Verdadero el nodo esclavo tiene problemas intermitentes

el nodo esclavo, el bus o el nodo maestro tiene serios

Sin Respuesta
problemas

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.

109
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.

110
 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.

111
112
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.

113
 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 Humberto.Flores@mx.bosch.com
contacto
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

114
 • 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.

115
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]
El sistema debe de generar una pérdida de comunicación por tiempo finito de un
nodo dentro de una red de LIN mediante un circuito abierto.
[VT_ERS_003]
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 corto a tierra.
[VT_ERS_004]
El sistema debe de generar una pérdida de comunicación por tiempo finito de un
nodo dentro de una red de LIN mediante un corto a tierra.
[VT_ERS_005]
116
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 corto a batería.
[VT_ERS_006]
El sistema debe de generar una pérdida de comunicación por tiempo finito de un
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]
117
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. 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()

Figura 73 - Clase Loss_CAN

Definición de funciones:

closeCircuit_CAN_H ()
//Descripción función
//Parámetros de entrada
//Parámetros de salida
closeCircuit_CAN_L ()
//Descripción función
//Parámetros de entrada
//Parámetros de salida
lossOfCom_CAN_DW (dword)
//Descripción función
//Parámetros de entrada
//Descripción del parámetro
//Rango de entrada
: Cierra circuito en línea CAN_H (Solo CAN DW)
: NA
: NA
: Cierra circuito en línea CAN_L CAN SW/CAN DW
: NA
: NA
: Pérdida de comunicación CAN DW
: dword i_lossOfCom_time_ms
: Tiempo en ms de la pérdida de comunicación
: 1-4294967295

118
//Parámetros de salida : NA
lossOfCom_CAN_SW (dword)
//Descripción función : Pérdida de comunicación CAN SW
//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
//Parámetros de salida : NA
openCircuit_CAN_H ()
//Descripción función : Abre circuito en línea CAN_H (Solo CAN DW)
//Parámetros de entrada : NA
//Parámetros de salida : NA
openCircuit_CAN_L ()
//Descripción función : Abre circuito en línea CAN_L CAN SW/CAN DW
//Parámetros de entrada : NA
//Parámetros de salida : NA

[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. class

Loss_LIN

- closeCircuit_LIN()
+ lossOfCom_LIN(dword)
- openCircuit_LIN()

Figura 74 - Clase Loss_LIN

Definición de funciones:

closeCircuit_LIN ()
//Descripción función : Cierra circuito en línea LIN
//Parámetros de entrada : NA
//Parámetros de salida : NA
lossOfCom_LIN (dword)
//Descripción función : Perdida de comunicación LIN
//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
//Parámetros de salida : NA
openCircuit_LIN ()
//Descripción función : Abre circuito en línea LIN
//Parámetros de entrada : NA
//Parámetros de salida : NA

119
[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. 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)

Figura 75 - Clase Short2Ground_CAN

Definición de funciones:
s2g_switchActive_CAN_H ()
//Descripción función : Activa el corto a tierra en línea CAN_H
// (Solo CAN DW)
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2g_switchActive_CAN_L ()
//Descripción función : Activa el corto a tierra en línea CAN_L
// CAN SW/CAN DW
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2g_switchInactive_CAN_H ()
//Descripción función : Inactiva el corto a tierra en línea CAN_H
// (Solo CAN DW)
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2g_switchInactive_CAN_L ()
//Descripción función : Inactiva el corto a tierra en línea CAN_L
// CAN SW/CAN DW
//Parámetros de entrada : NA
//Parámetros de salida : NA
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
//Rango de entrada : 1-4294967295
//Parámetros de salida : NA
short2Ground_CAN_L (dword)
//Descripción función : Corto a tierra en línea CAN_L (CAN DW/SW)
//Parámetros de entrada : dword i_s2g_time_ms
//Descripción del parámetro : Tiempo en ms del corto a tierra
//Rango de entrada : 1-4294967295

120
//Parámetros de salida : NA

[VT_ERS_04]
La clase Short2Ground_LIN permite realizar la un corto a tierra en una red de CAN de
dos líneas o una línea. class

Short2Ground_LIN

- s2g_switchActive_LIN()
- s2g_switchInactive_LIN()
+ short2Ground_LIN(dword)

Figura 76 - Clase Short2Ground_LIN

Definición de funciones:
s2g_switchActive_LIN ()
//Descripción función : Activa el corto a tierra en línea LIN
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2g_switchInactive_LIN ()
//Descripción función : Inactiva el corto a tierra en línea LIN
//Parámetros de entrada : NA
//Parámetros de salida : NA
short2Ground_CAN_LIN (dword)
//Descripción función : Corto a tierra en línea LIN
//Parámetros de entrada : dword i_s2g_time_ms
//Descripción del parámetro : Tiempo en ms del corto a tierra
//Rango de entrada : 1-4294967295
//Parámetros de salida : NA

[VT_ERS_005]
La clase Short2Battery_CAN permite realizar la un corto a tierra en una red de CAN de
dos líneas o una línea.

121
 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)

Figura 77 - Clase Short2Battery_CAN

Definición de funciones:
s2b_switchActive_CAN_H ()
//Descripción función : Activa el corto a batería en línea CAN_H
// (Solo CAN DW)
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2b_switchActive_CAN_L ()
//Descripción función : Activa el corto a batería en línea CAN_L
// CAN SW/CAN DW
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2b_switchInactive_CAN_H ()
//Descripción función : Inactiva el corto a batería en línea CAN_H
// (Solo CAN DW)
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2b_switchInactive_CAN_L ()
//Descripción función : Inactiva el corto a batería en línea CAN_L
// CAN SW/CAN DW
//Parámetros de entrada : NA
//Parámetros de salida : NA
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
//Rango de entrada : 1-4294967295
//Parámetros de salida : NA
short2Battery_CAN_L (dword)
//Descripción función : Corto a batería en línea CAN_L (CAN DW/SW)
//Parámetros de entrada : dword i_s2b_time_ms
//Descripción del parámetro : Tiempo en ms del corto a batería
//Rango de entrada : 1-4294967295
//Parámetros de salida : NA

[VT_ERS_006]
La clase Short2Battery_LIN permite realizar la un corto a tierra en una red de LIN.

122
 class

Short2Battery_LIN

- s2b_switchActive_LIN()
- s2b_switchInactive_LIN()
+ short2Battery_LIN(dword)

Figura 78 - Clase Short2Battery_LIN

Definición de funciones:
s2b_switchActive_LIN ()
//Descripción función : Activa el corto a batería en línea LIN
//Parámetros de entrada : NA
//Parámetros de salida : NA
s2b_switchInactive_LIN ()
//Descripción función : Inactiva el corto a batería en línea LIN
//Parámetros de entrada : NA
//Parámetros de salida : NA
short2Battery_LIN (dword)
//Descripción función : Corto a batería en línea LIN
//Parámetros de entrada : dword i_s2b_time_ms
//Descripción del parámetro : Tiempo en ms del corto a batería
//Rango de entrada : 1-4294967295
//Parámetros de salida : NA

[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. class

Pow er_Reset

+ power_reset(dword)

Figura 79 - Clase Power_Reset

Definición de funciones:
power_reset (dword)
//Descripción función
//Parámetros de entrada
//Descripción del parámetro
//Rango de entrada
: Reseteo de voltaje de alimentación
: dword i_pr_time_ms
: Tiempo en ms del reseteo de alimentación
: 1-4294967295

123
//Parámetros de salida : NA

[VT_ERS_009] [VT_ERS_010]
La clase WakeUp permite realizar la activación de comunicación en una red, una vez
y en cuando la red se encuentre desactivada.
class

WakeUp

+ wakeup(dword)

Figura 80 - Clase WakeUp

Definición de funciones:
wakeup (dword)
//Descripción función
//Parámetros de entrada
//Descripción del parámetro
//
//Rango de entrada
//Parámetros de salida
: Activación de comunicación de la red
: dword i_wakeup_time_ms
: Tiempo en ms de espera para la activación
de la red
: 1-4294967295
: NA

[VT_ERS_011] [VT_ERS_012]
La clase Sleep permite realizar la desactivación de comunicación en una red, una vez
y en cuando la red se encuentre activada.

class

Sleep

+ sleep(dword)

Figura 81 - Clase Sleep

Definición de funciones:
sleep (dword)
//Descripción función
//Parámetros de entrada
//Descripción del parámetro
//
//Rango de entrada
//Parámetros de salida
: Desactivación de comunicación de la red
: dword i_sleep_time_ms
: Tiempo en ms de espera para la desactivación
de la red
: 1-4294967295
: NA

124
[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.
class

Pow er_Reset Sleep WakeUp

+ power_reset(dword) + sleep(word) + wakeup(word)

TurnOn_VT

- i_interconnectionMode: int
- i_voltageRef_sup1: int
- i_voltageRef_supInt: int

+ interface_VT(int, int, int): int

- tunrOn_VT()

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)
4 - Dos fuentes de alimentación independientes para OUT1 y OUT2: fuente
de alimentación interna y fuente de alimentación 2 (modo supint_sup2)
5 - Dos fuentes de alimentación independientes para OUT1 y OUT2: fuente
de alimentación 1 y fuente de alimentación interna (modo sup1_supint)
6 - Dos fuentes de alimentación independientes para OUT1 y OUT2: fuente
de alimentación 1 y fuente de alimentación 2 (modo sup1_sup2)
7 - Dos fuentes de alimentación independientes para OUT1 y OUT2: fuente
de alimentación 2 y fuente de alimentación interna (modo sup2_supint)
8 - Dos fuentes de alimentación independientes para OUT1 y OUT2: fuente
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)

125
int i_voltageRef_sup1
//Descripción del parámetro
//Rango de entrada
int i_voltageRef_supInt
//Descripción del parámetro
//Rango de entrada
: 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
: 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.
//Parámetros de entrada : NA
//Parámetros de salida : NA

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. class

Loss_Common

- closeCircuit()
+ lossOfCom(): dword
- openCircuit()

Figura 83 - Clase común para protocolos

126
Definición de funciones:

closeCircuit ()
//Descripción función : Cierra circuito
//Parámetros de entrada : NA
//Parámetros de salida : NA
lossOfCom (dword)
//Descripción función : Perdida de comunicación
//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
//Parámetros de salida : NA
openCircuit ()
//Descripción función : Abre circuito
//Parámetros de entrada : NA
//Parámetros de salida : NA

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.

127
CAN DW:

Figura 84 - Diagrama eléctrico CAN DW

128
CAN SW:

Figura 85 - Diagrama eléctrico CAN SW

129
Diagrama común:

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

130
LIN:

Figura 87 - Diagrama eléctrico LIN

131
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.

132
 La siguiente tabla muestra las principales reglas a seguir durante el diseño de la
interface HMI.

Área Nombre Descripción

Percepción Tamaño del Es el tamaño de los carácter utilizados adecuado

Visual carácter 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.

133
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.

134
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

135
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.

136
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

137
 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.

138
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 Ejecución manual Preparación Ejecución

manual automatización automatizada
01:23 01:31 01:23 00:00
Tabla 11 - Reducción de tiempo en pruebas de pérdida de comunicación

139
 Pérdida de Comunicación Manual Pérdida de Comunicación Automatizada
Repetición
Preparación Ejecución Preparación Ejecución
manual manual automatizació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

Perdida de Comunicación
16:48
14:24
12:00
09:36
07:12
04:48
02:24
00:00
0 2 4 6 8 10 12

Preparación manual Ejecución manual

Preparación automatización Ejecución automatizada

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 Ejecución manual Preparación Ejecución

manual automatización automatizada
01:23 02:43 01:23 00:00
Tabla 13 - Reducción de tiempo en pruebas activación y desactivación

140
 Activación/Desactivación Manual Activación/Desactivación
Repetición Automatizada
Preparación Ejecución Preparación Ejecución
manual manual automatizació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

Activación/Desactivación
01:40
01:26
01:12
00:57
00:43
00:28
00:14
00:00
0 2 4 6 8 10 12

Preparación manual Ejecución manual

Preparación automatización Ejecución automatizada

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 Ejecución manual Preparación Ejecución

manual automatización automatizada
01:23 01:04 01:23 00:00
Tabla 15 - Reducción de tiempo en pruebas de reseteo

141
 Reseteo de alimentación manual Reseteo de alimentación
Repetición automatizada
Preparación Ejecución Preparación Ejecución
manual manual automatizació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

Reseteo de alimentación
12:00
10:48
09:36
08:24
07:12
06:00
04:48
03:36
02:24
01:12
00:00
0 2 4 6 8 10 12

Preparación manual Ejecución manual

Preparación automatización Ejecución automatizada

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.

142
 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜
= 𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜 𝑝𝑟𝑢𝑒𝑏𝑎 𝑑𝑒 𝑟𝑒𝑠𝑒𝑡𝑒𝑜
+ 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 𝑝𝑟𝑢𝑒𝑏𝑎 𝑑𝑒 𝑎𝑐𝑡𝑖𝑣𝑎𝑐𝑖ó𝑛
+ 𝑇𝑖𝑒𝑚𝑝𝑜 𝑑𝑒 𝑎ℎ𝑜𝑟𝑟𝑜 𝑝𝑟𝑢𝑒𝑏𝑎 𝑑𝑒 𝑝é𝑟𝑑𝑖𝑑𝑎 𝑑𝑒 𝑐𝑜𝑚𝑢𝑛𝑖𝑐𝑎𝑐𝑖ó𝑛
= 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

143
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.

144
 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 $2,655.00

alimentación de las ECU.

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

145
 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
𝑅𝑂𝐼 = = = 9.11ℎ𝑟
ℎ𝑜𝑟𝑎 𝑖𝑛𝑔𝑒𝑛𝑖𝑒𝑟𝑖𝑎 $ 570/ℎ
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 𝑚𝑖𝑛

𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 = = ≈ 130
𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜 4.23 𝑚𝑖𝑛
Basados en este cálculo serían necesarias 130 ejecuciones de alguna funcionalidad.
𝑅𝑂𝐼 9.11 ℎ𝑟𝑠
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑟𝑜𝑛𝑑𝑎𝑠 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎 = = ≈ 1.5
𝑇𝑖𝑒𝑚𝑝𝑜 𝑎ℎ𝑜𝑟𝑟𝑜 𝑟𝑜𝑛𝑑𝑎 𝑑𝑒 𝑝𝑟𝑢𝑒𝑏𝑎𝑠 6 ℎ𝑟𝑠

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.

146
 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.

147
148
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).

149
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.

150
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.

151
152
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.

153
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.
154
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.

155
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.
156
59. Palmer, Stephen R. y Felsing, John M. Practical Guide to Feature-Driven Development. s.l. :
Prentice Hall, 2002. 978-0130676153.

157