Implantación de Nuevas Tecnologías de los Sistemas Inteligentes

Trabajo Final de Máster en
Electrónica, Tratamiento Digital de la Señal y
Comunicaciones
Implantación de Nuevas Tecnologías de los
Sistemas Inteligentes de Transporte en un
Vehículo Eléctrico
Autor: José María León Coca
Tutor: Federico José Barrero García
Departamento de Ingeniería Electrónica
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2013
i
Trabajo Final de Máster en
Electrónica, Tratamiento Digital de la Señal y Comunicaciones
Implantación de Nuevas Tecnologías de los Sistemas
Inteligentes de Transporte en un Vehículo Eléctrico
Autor:
José María León Coca
Tutor:
Federico José Barrero García
Profesor titular
Departamento de Ingeniería Electrónica
Escuela Técnica Superior de Ingeniería
Universidad de Sevilla
Sevilla, 2013
Trabajo Final de Máster: Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de
Transporte en un Vehículo Eléctrico
Autor: José María León Coca
Tutor:
Federico José Barrero García
El tribunal nombrado para juzgar el Trabajo Final de Máster arriba indicado, compuesto por los
siguientes miembros:
Presidente:
Vocales:
Secretario:
Acuerdan otorgarle la calificación de:
Sevilla, 2013
El Secretario del Tribunal
A mi prima María,
A mi tía Mili,
Y a mi Padre, nuevamente, Ella
estaría orgullosa.
v
Agradecimientos
A lo largo de este año han ocurrido muchísimas cosas, grandes retos que superar y muy poco
tiempo para ello. Aún así, siempre es bueno pensar que todo esto no cae en saco roto y que servirán
para formarme como persona y profesional. Es por ello que debo agradecerle a toda la gente que
hizo posible que siguiera hacia delante, dándome consejo y ofreciéndome su mano para volverme a
levantar: Juanma, Juanjo, Pepe, Diego, Jose… A mi familia, siempre apoyándome y facilitándome el
camino. A todos mis compañeros del grupo de investigación, hacéis que parezcamos una familia y
en especial a mi tutor Federico, guía en mi carrera investigativa, siempre dispuesto a poner sobre la
mesa su experiencia y mostrarme las opciones existentes.
Para terminar, lo más importante, mi Angelita, siempre seguiré creyendo en nuevo un 5 de Junio.
“Al final, todo va a acabar bien... Y si no acaba bien
es que aún no es el Final.”
-Película El Exótico Hotel Marigold-
Resumen
Este trabajo final de máster expone la implantación en un vehículo eléctrico de las nuevas
tecnologías de la información aplicadas a entornos vehiculares. Estas tecnologías permiten un
nuevo concepto de conducción: la conducción cooperativa. Este nuevo paradigma tiene la
capacidad potencial de evitar los accidentes y por tanto aumentar la seguridad en las carreteras.
Además de otros beneficios que permitirían una mejora y optimización de las infraestructuras de
transporte. Para poder habilitar esta tecnología es necesario disponer de una tecnología de
comunicación inalámbrica que permita una comunicación vehículo-a-vehículo y vehículo-ainfraestructura. Esta tecnología ha sido tema de estudio durante la última década, llegando a estar
al fin terminada y estandarizada bajo el nombre de WAVE (IEEE 802.11p/IEEE 1609). Por tanto este
proyecto supone un trabajo de investigación para conseguir desarrollar una plataforma
demostradora de estas nuevas tecnologías vehiculares.
Abstract
This final master job describes the implementation of new information technologies related with
vehicular environment in an electric vehicle. These technologies provide a new driving concept: The
cooperative driving. This new paradigm has been designed to have the potential capability to
avoide and prevent traffic accidents enhancing the road safety. In addition to offers other benefits
that allowan improvement and optimization on transportation infrastructures. In order to enable
this technology is necessary to have a wireless communication technology that supports vehicle-tovehicle and vehicle-to-infrastructure communications. This technology has been the subject of study
in the last decade, becoming finally finmished and standardized under the name WAVE (IEEE
802.11p/IEEE 1609). So this project is a research work for developing a new vehicular technologies
demonstrator platform.
viii
Índice
Agradecimientos
vi
Resumen
vii
Abstract
viii
Índice
ix
Siglas y Acrónimos
xi
1
Introducción
13
2
Marco tecnológico
2.1
Comunicaciones Inalambricas para ITS
2.1.1
Bluetooth
2.1.2
IEEE 802.11
2.1.3
WAVE
2.1.4
Tecnologías Adaptadas por ISO CALM
2.2
Comunicación Interna del Vehículo
2.2.1
Protocolo CAN
2.2.2
OBD II
2.3
Estudio Controlador CAN Stand Alone
2.3.1
Microcontrolador 8051
2.3.2
Controlador SJA1000
2.3.3
Registros Controlador CAN
2.3.4
Modo PeliCan.
2.3.5
Registros comunes
2.4
Proyectos ITS
2.4.1
Proyectos ITS Americanos
2.4.2
Proyectos ITS Europeos
15
17
19
22
24
28
31
31
42
44
44
46
48
60
83
89
89
91
3
Arquitectura y Elementos del Sistema
3.1
OBU
3.1.1
Arquitectura Base
3.1.2
Arquitectura del Demostrador
3.1.3
Mobile Router
3.1.4
Vehicle Host
3.1.5
Vehicle Gateway
3.1.6
Human Media Interface
3.2
RSU
3.2.1
Arquitectura Base
3.2.2
Arquitectura del Demostrador
97
98
98
98
99
103
105
107
109
109
110
4
Trabajo Realizado
4.1
Red Externa del Vehículo
4.1.1
Elección Sistema Operativo para Mobile Router
4.1.2
Primeros Pasos con Open-WRT
4.1.3
Modo GCDC
4.2
Integración SmartPhone
4.2.1
Creación Aplicación Servidora
4.2.2
Creación Aplicación Cliente
4.3
Red Interna del Vehículo
4.3.1
Creación de los Sensores/Actuadores
4.3.2
Soporte STK500 en Versiones Actuales de AVR-Studio
4.3.3
Test CAN
111
112
112
114
120
121
121
122
123
123
124
125
ix
4.4
5
PC de Abordo
Conclusiones y Trabajo Futuro
127
129
Referencias
131
Índice de Figuras
133
Índice de Tablas
135
Siglas y Acrónimos
CEN
CENELEC
CEPT
EN
ES
ESO
ETSI
FCC
GPS
ITS
ITS-G5
MAC
NSO
OFDM
PHY
STA
TC
UMTS
WAVE
WiFi
WiMAX
WG
WLAN
European Committee for Standardization
European Committee for Electrotechnical Standardization
European Conference of Postal and Telecommunications Administrations
European Norm
ETSI Standard
European Standardization Organization
European Telecommunications Standards Institute
Federal Communications Commission
Global Positioning System
Intelligent Transport System
ITS-G5 Set of protocols and parameters in the ETSI Standard ES 202 663
Medium Access Control
National Standards Organization
Orthogonal Frequency-Division Multiplexing
Physical
Station
Technical Committee
Universal Mobile Telecommunications System
Wireless Access in Vehicular Environments
Brandname of the Wi-Fi Alliance, normally used with IEEE 802.11
Worldwide Interoperability for Microwave Access, used with IEEE 802.16
Work Group
Wireless Local Area Network
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
1 INTRODUCCIÓN
E
ste documento es el trabajo final de máster, TFM en adelante, en Electrónica,
Tratamiento de Señal y Comunicaciones que es impartido de forma conjunta por el
Departamento de Ingeniería Electrónica y el Departamento de Teoría de la Señal de
la Escuela Técnica Superior de Ingeniería (ETSI) de la Universidad de Sevilla. En el mismo
se desarrolla un proyecto de investigación y desarrollo en el cual se encuentra trabajando
el propio autor, éste se engloba dentro del ámbito de los Sistemas Inteligentes de
Transporte (ITS) que pueden definirse brevemente como aquellos sistemas que tratan de
optimizar los productos y recursos de las infraestructuras de transporte mediante el uso de
las tecnologías de la información. El proyecto trata concretamente d e la implantación y el
desarrollo de las nuevas tecnologías de comunicaciones existentes en la industria en un
vehículo eléctrico, en pos de conseguir un prototipo que sirva como demostrador de
dichas tecnologías. Se trata de un proyecto ambicioso, con varias partes y tecnologías
diferentes a desarrollar. Su horizonte temporal, se extiende más allá de lo que se recoge en
este trabajo final de máster, en el que se explicarán los mimbres, las bases, que permitirán
crear la infraestructura de comunicaciones necesaria para realizar un sistema demostrador
de la tecnología ISO-CALM (Communication Access for Land Mobiles). Ésta tecnología
hace referencia al recién licenciado estándar de comunicaciones para entornos vehiculares,
que será explicado más adelante en el siguiente capítulo.
El proyecto se realiza en el seno del grupo de investigación ACE-TI (Aplicaciones
Cibernéticas de la Electrónica a las Tecnologías de la Información) creado en 2006 por
profesores de la ETSI, Este grupo de investigación, compuesto por profesores y estudiantes
adscritos a los departamentos de Ingeniería Electrónica e Ingeniería de Sistemas y
Automática, está compuesto por 23 investigadores agrupados en dos líneas de
investigación. Entre los miembros de este grupo, cabe destacar la presencia de 5 doctores.
Actualmente el director del grupo de investigación es el tutor de éste proyecto. Las líneas
de investigación del grupo ACE-ti se centran en los sistemas empotrados y sus
aplicaciones a áreas tan diversas como el procesamiento de video, el control de máquinas
eléctricas o las redes de sensores, y la optimización de los sistemas de producción,
principalmente plantas termosolares, invernadores o demanda.
Figura 1: Logotipo Grupo de Investigación ACE-TI
13
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
La mejor presentación posible para dar a conocer el trabajo que se realiza, es definir qué le
rodea. Éste sigue la influencia y directrices de algunos proyectos europeos más
importantes, como el CVIS, COOPERS, SAFESPOT y la iniciativa GCDC. Además se
seguirán y estudiarán los estándares IEEE 802.11p, IEEE 1609, ISO-CALM, CAN,
Bluetooth, WiFi. También se seguirá la estela de proyectos realizados por el grupo de
investigación como son VisioWay y AudioZity.
El punto de partida del proyecto se inició con un vehículo eléctrico “vacío”, el modelo
cross-ryder, disponible en el grupo de investigación, sobre éste se decidieron instalar una
serie de elementos que mejoraran de forma notable sus prestaciones. Al comenzar el
estudio de las últimas propuestas tecnológicas más actuales en la industria de la
automoción, para decidir qué instalar en el vehículo, comenzaba a expandirse más y más
el concepto de conducción cooperativa: dicho de forma breve, comunicaciones de todos los
vehículos entre ellos y con la infraestructura permitiendo el trasiego de información
relevante, tanto para la conducción y como para la mejora de la seguridad en la carretera.
Fue entonces cuando se decidió a seguir un modelo de desarrollo y una arquitectura
similares a la propuesta por el proyecto CVIS, tal y como puede verse en la Figura 2:
Figura 2: Arquitectura Vehículo Eléctrico
Todas estas entidades han de ser desarrolladas y hacerlas funcionar como una sóla para
conseguir el objetivo del proyecto. En éste TFM se recoge el trabajo hasta la fecha en la que
aún se encuentran en vías de desarrollo algunas de las entidades, comenzando a
interactuar entre ellas, por ello que anteriormente se describiera como las bases del
proyecto.
El TFM se organizará de la siguiente manera, primero un marco teórico el cual ayude a
situar tecnológicamente el proyecto y sean explicadas algunas de las tecnologías utilizadas
en el mismo. En el tercer capítulo, se describe más en profundidad los elementos
utilizados, tanto hardware como software, que serán empleados en la realización del
proyecto. El siguiente capítulo, se explicará el desarrollo realizado en cada una de las
partes del proyecto. El último capítulo expresará las conclusiones y el trabajo futuro a
realizar.
14
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2 MARCO TECNOLÓGICO
D
esde finales del siglo XX y principios del XXI, la tendencia de la población mundial
ha ido encaminada a establecerse en zonas urbanas. En la actualidad un 50% de la
población, reside en ciudades. Según estudios de Naciones Unidas [1], se estima
que ésta población, aumente hasta el 70%, 5,5 mil millones, en 2050.
El incremento en la población urbana ha traído consigo el aumento de la movilidad, como
puede verse en la Figura 3 [2]. En la mayoría de los casos, no existe la infraestructura
necesaria para satisfacer la demanda requerida por el número de vehículos, lo que acarrea
graves problemas de congestión tráfico y un importante aumento de la siniestralidad y la
contaminación.
Figura 3: Transporte de Personas por Regiones del Mundo
El impacto directo de estos problemas en el aspecto económico ha sido materia de estudio.
Según datos recopilados por la Fundación Instituto Tecnológico para la Seguridad del
Automóvil (FITSA), el coste acumulado de los accidentes de tráfico en España desde 1991
a 2002 ascendió a 108.000-150.000 millones. Actualmente supone más de 16.000 millones de
euros, alrededor de un 2% del PIB. Además se sabe que la congestión del tráfico tiene un
coste económico igualmente profundo, que puede alcanzar entre el 1 y el 3% del PIB tanto
en países desarrollados como en vías de desarrollo [3].
En materia sanitaria, la contaminación por culpa del tráfico supone un 25% del total de
emisiones de CO2 en Europa. El volumen del tráfico de vehículos a motor, es la principal
15
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
causa de la degeneración del aire que respiramos. La contaminación atmosférica afecta a
nuestra salud de una manera intensa pero lenta, no siempre apreciable en cortos lapsos de
tiempo. Diversas investigaciones han puesto de relieve su relación con la aparición y
agravamiento de enfermedades respiratorias, así como de otras dolencias asociadas, como
las vasculares y los cánceres. También es muy clara su relación con el incremento de las
alergias que tanto merman la calidad de vida de muchas personas.
El problema es de una enorme magnitud: según el Ministerio de Medio Ambiente 16.000
personas mueren prematuramente cada año en el Estado español a causa de la
contaminación atmosférica, según la UE, se producen 370.000 muertes al año por esta
causa en la zona europea, ocho veces más que los muertos en accidentes de tráfico [4].
Es evidente que la expansión tradicional de las infraestructuras urbanas ha sido ineficaz,
lo que ha obligado a realizar una gestión más eficiente de los recursos mediante la
implantación de Sistemas de Trafico Inteligentes. Los ITS se pueden definir como un
conjunto de aplicaciones avanzadas dentro de la tecnología informática, electrónica y de
comunicaciones que, desde un punto de vista social, económico y medioambiental, están
destinadas a mejorar la movilidad, seguridad y productividad del transporte, optimizando
la utilización de las infraestructuras existentes, aumentando la eficiencia del consumo de
energía y mejorando la capacidad del sistema de transportes para la disminución de las
emisiones.
Los ITS se emplean para diversas tareas, entre las que se incluyen:

Mejora de la vigilancia, videovigilancia y autovigilancia

Sistemas de seguridad avanzada intravehiculares, intervehiculares y entre vehículo
e infraestructura

Mejora de las condiciones de seguridad en el transporte por carretera

Mejora de la captura de datos y servicios de monitorización

Mejora de la difusión de información

Coordinación entre sistemas ITS

Mejora de la vialidad urbana y Gestión de determinadas mercancías y de los
terminales modales

Administración electrónica y E-movilidad
Actualmente, las ciudades, se encuentran en un periodo de comprensión y materialización
del potencial de los sistemas ITS. La implantación de estos sistemas se debe desarrollar de
una manera flexible y a largo plazo. Un aspecto clave en el desarrollo de dichos sistemas es
el económico. La inversión que requieren es grande y los países buscan la financiación
mediante capital privado o la aplicación directas de impuestos. La situación actual de crisis
que se vive en el mundo, ha traído consigo políticas de austeridad, por lo que la inversión
en campos de investigación y desarrollo se ha visto gravemente afectada. Esto supone un
frenazo en la evolución de los ITS. Aun así, la Unión Europea continua ofreciendo planes
de acción [5] en materia de ITS que afecta al ámbito del transporte por carretera y a las
interfaces con otros medios de transporte. El objetivo consiste en coordinar los recursos e
instrumentos disponibles existentes mediante el desarrollo de las siguientes acciones:

Un sistema europeo de información en tiempo real sobre tráfico y
desplazamientos. Se trata de dar fluidez al tráfico por carretera y de poner a
disposición de todos los ciudadanos europeos una información común.

Continuidad de los servicios ITS de gestión del tráfico y mercancías en los
corredores de transporte europeos y en las aglomeraciones urbanas mediante un
marco común.

Fomento de buenas prácticas en materia de protección y seguridad viaria, en
particular, promoviendo el despliegue de sistemas de asistencia a la conducción
más avanzados y sistemas ITS de seguridad y protección.
16
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Integración de los vehículos en las infraestructuras de transportes, por ejemplo,
mediante una plataforma de servicios y aplicaciones ITS.

Protección de la seguridad de los datos de carácter personal.

Cooperación y coordinación eficaz de todos los sectores interesados a escala
europea, en concreto por medio de la creación de un marco jurídico.
Así mismo los Estados miembros deberán proporcionar acceso a aplicaciones y servicios
ITS interoperables en la Comunidad Europea que incluyan:

Datos sobre el transporte por carretera.

Datos sobre el tráfico.

Sistemas de protección y seguridad en los vehículos y en la infraestructura viaria.

Información entre vehículos e infraestructuras viarias.
Un ejemplo del desarrollo en España es el “Plan Nacional de consolidación de los ITS de
carretera en España”, cuya evolución puede verse en la Figura 4 [6].
Figura 4: Número de Secciones de Control Puestas en Producción por año
Para lograr este propósito, los vehículos deben integrar la tecnología necesaria. En este
campo la industria automovilística ha realizado una gran inversión para conseguir fabricar
vehículos inteligentes, que aumenten la seguridad y comodidad de conductores y
pasajeros. En 2011 la empresa automovilística Ford, duplicó su inversión en el desarrollo
de sistemas que permitan reducir la colisión entre vehículos. Estos sistemas se basan en la
utilización de sensores y algoritmos de control para la evaluación de las situaciones y la
actuación autónoma.
La tecnología inalámbrica por la que se ha apostado para la realización de los sistemas ITS
ha sido 802.11p, más conocida como WAVE, comentada posteriormente en esta
documentación.
2.1 Comunicaciones Inalambricas para ITS
Las tecnologías de comunicación inalámbricas están llamadas a desempeñar un papel
importante en el ámbito de los sistemas inteligentes de transporte [7], [8], [9]. Actualmente,
los entornos urbanos poseen una infraestructura dotada de gran multitud de equipos
como cámaras de vigilancia y detección, reguladores de tráfico, paneles, equipos de
estimación de parámetros de tráfico, todos ellos conectados a una red Ethernet urbana,
capaz de recibir toda la información de estos sistemas incluyendo datos en tiempo real,
imágenes y video [10], [11]. Como elementos móviles de estos entornos urbanos se
encuentran los vehículos y los ciudadanos, lo que da lugar a las comunicaciones vehículoinfraestructura (V2I) y vehículo-vehículo (V2V) y vehículo-persona (V2P). Cuando se
17
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
quiere hacer referencia al conjunto de ellas, sin distinguir entre los protagonistas de la
comunicación, se utiliza el acrónimo V2X. En la Figura 5, se ilustran las interacciones entre
los elementos que forman los entornos urbanos inteligentes.
Figura 5: Entorno Urbano Inteligente
Existen varias iniciativas europeas centradas en el desarrollo de aplicaciones y la capa
middleware para infraestructuras cooperativas en entornos urbanos. Dentro del Sexto
Programa marco (FP6) destacan CVIS (Cooperative Vehicle Infrastructure Systems,
http://www.cvisproject.org/), SAFESPOT (Cooperative systems for Road Safety,
http://www.safespot-eu.org/pages/page.php) y COOPERS (COOPerative systEms for
Intelligent Road Safety, http://www.coopers-ip.eu/). Sirviendo como referencia y prueba
del concepto de conducción cooperativa para los test diseñados por cuerpos de
estandarización europeos, en pos de conseguir una arquitectura única europea para
entornos vehiculares. No obstante, estas iniciativas no profundizan en el despliegue de
estas redes y en las dificultades y limitaciones referentes a entornos urbanos.
Las redes móviles Ad Hoc (MANETs) son redes inalámbricas descentralizadas con nodos
móviles en las que cada uno actúa como pasarela de otro, permitiendo el trasiego de
mensajes sin el establecimiento de una red inalámbrica local, realizando el rol de punto de
acceso y cliente a la vez [12]. Es por ello que las redes Ad Hoc encajan perfectamente en las
limitaciones que presentan las redes en entornos urbanos. Cuando los nodos se
corresponden con vehículos (coches, camiones, autobuses…etc.) y su movimiento se
restringe a las carreteras y pasos hábiles, se denominan VANET o Vehicular Ad-Hoc
Network. Desde el punto de vista funcional, las redes Ad Hoc se consideran sistemas
colaborativos en las que los elementos de la red colaboran para alcanzar un objetivo
común. Este modelo de comunicaciones parece adaptarse perfectamente al un entorno
vehicular, pero también se ha querido tener en cuenta la adición del concepto clásico de
red celular en la que los nodos de comunicaciones instalados en las infraestructuras
públicas y carreteras actúan como puntos de acceso. Estos puntos de acceso sirven como
sumidero o fuente de datos.
Dependiendo del tipo de aplicación, las dos arquitecturas de comunicaciones comentadas
en el párrafo anterior podrían ser utilizadas en un entorno vehicular inteligente. Todo ello
dependerá de la naturaleza de la propia aplicación, siendo determinantes los tiempos de
latencia para implementar una u otra. Por ejemplo, todas las aplicaciones relativas a la
seguridad en carretera, requieren unos tiempos de latencia muy bajos y un establecimiento
de la comunicación prácticamente inexistente. Es por ello que para este tipo de
comunicaciones se utilizará una comunicación ad-hoc descentralizada. Por otro lado, si la
aplicación a implementar es del tipo de acceso a contenidos de Internet, la latencia no es un
factor crítico y el establecimiento de una sesión sí que es necesario. Por tanto, las
comunicaciones centralizadas o celulares serían idóneas para este tipo de aplicaciones.
Como resultado, para conseguir los objetivos ha sido necesario establecer una arquitectura
mixta para las comunicaciones que ha quedado patente en los estándares desarrollados
para este tipo de entornos.
18
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Para poder conseguir habilitar este tipo de comunicaciones ha sido necesario el desarrollo
de una nueva tecnología de comunicaciones que permita sobrepasar las dificultades que
presenta este estilo de entornos. Dificultades tales como permitir comunicaciones
inalámbricas continuadas a altas velocidades (250 km/h), que presenten una latencia
menor a los 100ms y una frecuencia de retransmisión de paquetes de 10 Hz. Esta
tecnología es WAVE (Wireless Access in Vehicular Environmet). Pero además de éstas
otras tecnologías son utilizadas en un entorno ITS como se observa en la Figura 5. Éstas
han sido especialmente adaptadas por los cuerpos de estandarización para poder ser
utilizadas de forma transparente en las plataformas ITS europeas y son:

CALM Sistemas Móviles 2G.

CALM Sistemas Móviles 3G.

CALM Sistemas Infrarrojos.

CALM M5 es el sistema WAVE europeo.

CALM MM.

CALM Mobile wireless broadband usando IEEE 802.16 (WiMAX).

CALM Usando tecnologías de difusión.

CALM mediante redes Satellite.
A continuación serán explicadas las tecnologías inalámbricas las cuales manejaran en el
projecto, para una mayor comprensión de las acciones realizadas.
2.1.1
Bluetooth
Bluetooth es una tecnología de red de área personal inalámbrica (WPAN). Son redes de
corto alcance, bajo coste y bajo consumo. Estas características han sido favorables para que
la tecnología se haya extendido de forma rápida en el ámbito de la interconexión de
dispositivos móviles o periféricos. Opera en la banda ISM (Industrial Scientific Medical) de
2.4 GHz. Existen varias normativas y perfiles de uso que cambian sus características de
transmisión. Cada revisión de la norma aporta nuevas características a éste estándar de
comunicación que muchos veían acabado:

Bluetooth v1.0 y v1.0b: Las versiones 1.0 y 1.0b han tenido muchos problemas, y los
fabricantes tenían dificultades para hacer sus productos interoperables. Todo
radicaba en la dependencia hardware que exigía esta versión del protocolo.

Bluetooth v1.1 (2002): Esta versión fue finalmente ratificada como un estándar
IEEE 802.15.1-20022. Se consiguió subsanando los errores en las especificaciones
anteriores, añadiendo soporte para canales no cifrados e indicador de señal
recibida (RSSI).

Bluetooth v1.2 (2005): Esta versión es compatible con USB 1.1 y mejora en ser capaz
de establecer una conexión más rápidamente, mejora las interferencias al añadir
saltos de señal, un aumento en la velocidad de transmisión y por tanto una mejora
en la calidad de la voz. Se definió el Host Controller Interface (HCI) el apoyo a tres
hilos UART. Fue nuevamente ratificado como estándar IEEE 802.15.1-20054.

Bluetooth v2.0 + EDR (2004): Es la versión que puede considerarse como estándar
al ser compatible con la versión anterior 1.2. El termino EDR (Enhanced Data Rate)
"mayor velocidad de transmisión de datos" aumentando la tasa de transferencia de
datos práctica es de 2,1 Mbit / s.

Bluetooth v2.1 + EDR (2007): Nuevamente es totalmente compatible con 1.2, y fue
adoptada por el Bluetooth SIG ( Bluetooth Special Interest Group) el 26 de julio de
2007.5. Su principal mejora es el Secure Simple Pairing (SSP) mejorando la
experiencia de emparejamiento de dispositivos Bluetooth y reduce el consumo de
19
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
energía al mejorar en la búsqueda de dispositivos.

Bluetooth v3.0 + HS (2009): Esta versión soporta velocidades de transferencia de
datos teórica de hasta 24 Mbit / entre sí, aunque no a través del enlace Bluetooth
propiamente dicho. La conexión Bluetooth nativa se utiliza para la negociación y el
establecimiento mientras que el tráfico de datos de alta velocidad se realiza
mediante un enlace 802.11.

Bluetooth v4.0 (2010): Esta versión incluye varios modos de funcionamiento:
Bluetooth clásico, Bluetooth de alta la velocidad y protocolos Bluetooth de bajo
consumo. Bluetooth de alta velocidad se basa en Wi-Fi, y Bluetooth clásico consta
de protocolos Bluetooth legado. Bluetooth baja energía (BLE) es un subconjunto de
Bluetooth v4.0 con una pila de protocolo nueva para realizar enlaces sencillos.
La clasificación de los dispositivos dependerá de la potencia de los mismos, Tabla 1.
Tabla 1: Clases de Transmisión Buetooth
Clase Potencia (pérdida de señal) Alcance
I
100 mW (20 dBm)
100 metros
II
2,5 mW (4 dBm)
15-20 metros
III
1 mW (0 dBm)
10 metros
La comunicación, Bluetooth se basa en un modelo maestro/esclavo. La red formada por un
dispositivo y los que se encuentran a su alrededor se denominada piconet. En cada red
piconet un dispositivo actúa de maestro y permite conectarse a un máximo de 7
dispositivos esclavos activos o de 255 en modo de espera, Figura 6. El estándar permite
que coexistan hasta un máximo de 10 redes piconet en un mismo área de cobertura. Otra
posibilidad que ofrece Bluetooth es el conexionado de 2 piconets para formar una red más
extensa, denominada scatternet.
Figura 6: Esquema Bluetooth
Los pasos que llevan a cabo los dispositivos para su interconexión son:

Activación de modo pasivo.
20
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Búsqueda de puntos de acceso.

Sincronización con los puntos de acceso.

Descubrimiento del servicio del punto de acceso.

Creación de un canal con el punto de acceso.

Emparejamiento mediante el PIN (seguridad).

Utilización de la red.
La implementación del protocolo Bluetooth irá en función del uso y de los recursos que
disponga el dispositivo. La pila de protocolos (Figura 7), diferirá en el orden donde se
implementa cada capa:

Hosted (anfitrión)

Embedded (empotrado)

Fully embedded (completamente empotrado)
Figura 7: Pila de Protocolos
Bluetooth
El estándar Bluetooth define un cierto número de perfiles de aplicación (denominados
perfiles Bluetooth) para definir qué tipos de servicios ofrece un dispositivo Bluetooth. Por
lo tanto, cada dispositivo puede admitir múltiples perfiles. Con esto se consigue la
interoperatibilidad entre varias unidades Bluetooth que cumplan los mismos perfiles.
Cada dispositivo Bluetooth tiene al menos un perfil, es decir, una aplicación para la cual se
puede utilizar el dispositivo. Cuando dos dispositivos deben comunicarse entre ellos,
deben tener un perfil compartido. Si por ejemplo quiere transferir un archivo desde un
ordenador preparado para Bluetooth a otro, ambos ordenadores deben admitir el perfil de
21
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
transferencia de archivos. Todos los dispositivos Bluetooth deben soportar el perfil de
acceso genérico (Generic Access Profile) como mínimo. Este perfil en particular define el
descubrimiento o hallazgo de dispositivos, procedimientos de conexión y procedimientos
para varios niveles de seguridad. También se describen algunos requerimientos de interfaz
al usuario. Otro perfil universal, aunque no es requerido, es el perfil de acceso a
descubrimiento de servicios (Service Discovery Access Profile), el cual define los
protocolos y parámetros asociados requeridos para acceder a los perfiles.
2.1.2
IEEE 802.11
El estándar nace en 1997. Se trata de un conjunto de normas cuyo propósito fue sustituir al
protocolo Ethernet para las zonas donde no interesase usar cableado. Desde su creación
esta norma ha ido evolucionando y ha sido mejorada como puede verse en la Tabla 2. La
primera versión, se basaba en la misma modulación utilizada en IR, con unas velocidades
máximas de 2Mbps. Debido a la alta frecuencia, era necesario que los dispositivos tuvieran
una visión directa para su enlace. El estándar implementa la capa física y la capa de enlace
sobre un canal inalámbrico, según el modelo de capas OSI.
Tabla 2: Familia de Protocolos IEEE 802.11
Protocolo
Publicación Frecuencia
Capacidad Alcance
Legacy
1997
2,4 GHz
2 Mbps
100 m
802.11a
1999
5 GHz
54 Mbps
120 m
802.11b
1999
2,4 GHz
11 Mbps
140 m
802.11g
2003
2,4 GHz
54 Mbps
140 m
802.11n
2008
2,4 GHz
300 Mbps
250 m
802.11y
2008
3,7 GHz
54 Mbps
5000m
802.11p
2009
5,9GHz
27 Mbps
Las modulaciones utilizadas por las distintas versiones del estándar pueden verse en la
Tabla 3.
Estándar Modulación
802.11
FHSS, DSSS, IR, PPM
802.11b
DSSS
802.11g
DSSS, OFDM
802.11a
OFDM
802.11n
OFDM-MIMO
802.11p
OFDM
22
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2.1.2.1
IEEE 802.11a
Se trata de la tercera revisión del estándar, tras 802.11 y 802.11b. Opera en la banda de
5GHz y permite una velocidad de enlace de 54Mbps. 802.11a utiliza OFDM (Orthogonal
Frequency Division Multiplexing). OFMD es una técnica de transmisión multiportadora
que se basa en dividir el espectro disponible en varios subcanales. El flujo de datos se
divide en varios flujos de datos más lentos que se transmiten simultaneamente en estos
subcanales. OFDM tolera mejor problemas como la atenuación selectiva en frecuencia,
propagación multitrayecto e interferencias, con técnicas como la del barajado de chunk.
Tras realizar varios estudios, puede encontrarse en la literatura, varios proyectos que
utilizan o parten de 802.11a, para conseguir desarrollar el estándar 802.11p. Los cambios a
realizar para conseguir esto se limitan a modificaciones en el tiempo de guarda y en la
anchura de canal.
Figura 8: Comparación 802.11a y 802.11p ¡Error! No se encuentra el origen de la
referencia.
2.1.2.2
IEEE 802.11g
Este estándar surgió como una extensión del 802.11b con el que se pretendía mejorar la
capacidad de transmisión del enlace usando el mismo rango de frecuencias, es decir, la
banda de 2,4 Ghz. Para ello, lo que se hizo fue introducir un segundo modo de acceso
basado en OFDM usado ya en las redes 802.11a que permitió aumentar la capacidad del
enlace hasta los 54 Mbps. De esta forma, al disponer de las dos técnicas de modulación, las
usadas en 802.11b y la usada en 802.11a, este estándar podía dar servicio a dispositivos que
cumpliesen la normativa 802.11b y a la vez a los nuevos dispositivos compatibles con el
estándar 802.11g. Por tanto, la principal ventaja de las redes 802.11g es el aumento
considerable de la capacidad de transmisión, hasta 54 MBPS. No obstante, al compartir la
misma banda que 802.11b presenta las mismas desventajas.
2.1.2.3
IEEE 802.11p
Esta es la normativa central de todas las tecnologías inalámbricas estudiadas fue
específicamente concebida para la comunicación entre vehículos, siendo esta tecnología
inalámbrica la que soporta las nuevas aplicaciones y servicios de los ITS. Esta tecnología
23
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
trabaja en la banda de los 5.9 GHz, con un espaciado de canal variable 5 MHz, 10 MHz y
20 MHz. Esta tecnología soporta tanto comunicaciones ad-hoc como WLAN permitiendo
distintos roles a la hora de realizar la comunicación.
En este apartado se han realizado algunos comentarios, pero será más adelante cuando se
analice WAVE cuando se darán más datos sobre ésta.
2.1.3
WAVE
WAVE son las siglas de Wireless Access in Vehicular Environments, es decir acceso
inalámbrico en entornos vehiculares. Es un estándar prácticamente recién estandarizado
en su versión completa, está formado por el conjunto formado por los estándares IEEE
1609 y, como se comentó anteriormente, el estándar IEEE 802.11p.
Figura 9: Pila de Protocolos WAVE
Como puede observarse esta pila de protocolos tiene dos partes bien diferenciadas, una
que permite el tráfico de paquetes IP y la otra que realiza un protocolo especial de
mensajes llamado WAVE Small Message Protocol (WSMP). Los distintos estándares no se
encargan sólo de una capa si de una o varias funciones específicas. Comenzamos a
describir cada uno de estos estándares:
2.1.3.1
IEEE 802.11p
es un anexo que pertenece al grupo de protocolos wifi, y cumple las funciones de capa
física y buena parte de las funciones de capa mac. Está especialmente diseñado para
comunicaciones inter-vehiculares y presenta las siguientes particularidades:
2.1.3.2
o
Define un modo de operación especifico para comunicaciones vehiculares
o
El transmisor emplea OFDM en la banda ISM libre de 5.9 Ghz
o
Define canales de 10 y 20 MHz de ancho de banda
o
Define especificaciones de frecuencia más ajustadas para el transmisor
o
Agrega requerimientos de rechazo de canales adyacentes para al receptor
o
Permite comunicaciones con y sin un WBSS (WAVE Basic Service Set)
o
Define un rango extendido de temperaturas en las cuales debe ser capaz de
operar
IEEE 1609.4
Es una extensión al estándar IEEE 802.11p con el objetivo de lograr una operación del
24
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
sistema en múltiples canales. Posibilita mecanismos efectivos para controlar operaciones
de capas superiores (IEEE 1609.3) a través de múltiples canales sin la necesidad de conocer
datos de capa física. En particular se definen 2 tipos de canales,

De control (CCH – Control Channel) se usa para transmitir mensajes de tipo WSM
(WAVE Short Message), mensajes característicos del estándar de alta prioridad,
principalmente orientados a aplicaciones de seguridad. También en este canal es
posible anunciar servicios WAVE.

De servicios (SCH – Service Channel). Es un tipo de canal es donde se hacen
efectivos esos servicios una vez solicitados en el CCH, soportando el manejo tanto
de mensajes WSMP (WAVE Short Message Protocol) como de mensajes IP. Existen
varios canales de servicio.
En general, el canal CCH es monitoreado a intervalos regulares para poder atender sin
demoras mensajes de alta prioridad. Se realiza un ranurado en el tiempo en intervalos de
50 ms y se asigna a cada canal un intervalo de manera alternativa. La existencia de varios
canales de servicios distintos en el espectro permite atender varios servicios
simultáneamente una vez que han sido apropiadamente coordinados en el canal de
control. Las funcionalidades provistas por IEEE 1609.4 son las siguientes:

Channel routing: controla el ruteo de paquetes provenientes de la capa LLC a su
canal designado, ya sea de control o de servicios, sin necesidad de realizar
operaciones de coordinación de canal por parte de la capa mac.

User priority: IEEE 1609.4 soporta una variedad de aplicaciones seguras y no
seguras con hasta 8 niveles de prioridad predefinidos. Estos son utilizados por
algoritmos de contención a la hora de ganar el acceso al medio, siendo los de
mayor prioridad los mensajes relacionados a la seguridad. Existe un buffer para
cada uno de estos 8 niveles donde los paquetes son encolados. A su vez, estos
buffers tienen 3 parámetros característicos:
o
AIFS (Arbitration Inter-Frame Space) – Tiempo mínimo entre que el canal
esta libre y se puede comenzar a transmitir
o
CW (Contention Window) – Ventana para implementar un backoff
aleatorio
o
TXOP (Transmit Oportunity) limit – Tiempo máximo durante el cual se
puede transmitir luego de haber obtenido un TXOP. Si el límite es 0 solo se
podrá trasmitir un MSDU.
Mediante el uso de estos parámetros, los paquetes provenientes de los diferentes
buffers participan primero en un mecanismo de contención interno para luego
realizar otro externo y así ganar el acceso al medio.

Channel coordination: coordina los intervalos activos de cada canal acorde a las
operaciones de sincronización de la capa mac para que los paquetes se transmitan
en el canal adecuado. Es necesario para soportar intercambio de datos entre
dispositivos que no son capaces de monitorear el canal de control a la vez que
intercambian datos en canales de servicios. Cuando un dispositivo se une a una
WBSS (WAVE BSS) es imprescindible la sincronización y la coordinación de canal
para asegurar que todos los dispositivos están monitoreando el CCH
adecuadamente, donde se transmiten los mensajes de mayor prioridad
relacionados a seguridad vehicular.

MSDU data transfer: servicios de capa mac para la transferencia de datos ya sean
de control o de servicio, mediante IPv6 o WSMP. Pueden enviarse tramas WSMP
directamente entre dos nodos sin conexión previa en el canal de control mientras
que para comunicaciones en un canal de servicio primero el proveedor del servicio
debe anunciarlo en el canal de control, generando una WBSS.
25
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2.1.3.3
IEEE 1609.3
Este protocolo se encarga de la capa de red por encima de la capa MAC. Se distinguen dos
áreas definidas como el plano de datos y el plano de administración.

El plano de datos contiene los protocolos y hardware usados en la transmisión de
datos, y se encarga generalmente del tráfico generado o destinado a aplicaciones,
aunque soporta también tráfico entre planos de administración de diferentes
maquinas o tráfico entre el plano de administración y el de datos.

El plano de administración en cambio lleva a cabo tareas de configuración y
mantenimiento del sistema. Sus funciones emplean servicios del plano de datos
para intercambiar tráfico de administración entre dispositivos. Se definen
entidades específicas de administración para ciertas capas como son PLME
(Physical Layer Management Entity) y MLME (Mac Layer Management Entity),
además de WME que es una colección más general de los servicios de
administración.
Se ve entonces que el estándar IEEE 1609.3 consiste en las capas intermedias del plano de
datos y la totalidad del plano de administración y se hace cargo de los siguientes servicios:


Servicios de datos:
o
LLC (Logical Link Control)
o
IPv6
o
UDP y TCP
o
WSMP (WAVE Short Message Protocol)
Servicios de administración:
o
Mecanismos de registro para las aplicaciones
o
Administración de WBSS (WAVE Basic Service Set)
o
Monitoreo del uso del canal
o
Configuración IPv6
o
Monitorización del RCPI (Received Channel Power Indicator)
o
Mantenimiento del MIB (Management Information Base)
Los dos protocolos posibles de comunicación a nivel de red son WSMP o IPv6. WSMP
(WAVE Short Message Protocol) está diseñado específicamente para operaciones del
entorno vehicular, siendo muy eficientes en la utilización del canal. Los mensajes WSM
pueden ser transmitidos en cualquier canal y permite a las aplicaciones controlar
directamente parámetros de capa física como ser el canal utilizado y la potencia de
transmisión, a diferencia de IPv6 que controla estos parámetros a través de los diferentes
perfiles que define el protocolo. Las aplicaciones pueden elegir el intercambio de datos en
el contexto de un WBSS o no. Si se establece un WBSS, es posible utilizar tanto WSM como
IPv6 sobre algún canal de servicio (aunque el anuncio y coordinación de una WBSS se
realiza en el canal de control). El dispositivo que anuncia un WBSS y por ende los
respectivos servicios asociados (pueden existir más de un servicio asociado a un mismo
WBSS) se denomina “proveedor”. Cualquier dispositivo que se una a ese WBSS para
utilizar sus servicios se denomina “usuario” (pueden haber varios usuarios utilizando
distintas combinaciones de servicios dentro del mismo WBSS). Al operar sin un WBSS, la
aplicación prepara mensajes WSM con una primitiva tipo request y los manda a la
dirección MAC de broadcast en el CCH.
2.1.3.4
IEEE 1609.2
Ya sea debido al carácter crítico que pueden tener los mensajes relacionados a la seguridad
vehicular, o simplemente para mantener la confidencialidad de la información difundida,
26
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
es necesario contar con mecanismos que aseguren el intercambio seguro y confiable de
mensajes entre las diferentes entidades. Sumando además que las pruebas realizadas en
los proyectos ITS anteriores era una de las mayores carencias del sistema. Es por ello que
define los servicios usados para proteger los mensajes de ataques tales como acceso a la
información por personas no autorizadas, alteración de los mensajes, o repetición de los
mismos, entre otros. Se definen funciones de seguridad tanto para la capa de red como
para la capa de aplicación. Aparte de los servicios típicos de seguridad como son la
confidencialidad, autenticidad e integridad, el sistema WAVE impone que se provean
mecanismo para mantener el anonimato del usuario final, ya que información propia
puede llegar a ser difundida, y también porque se puede llegar a tener en memoria
información de otros usuarios. Para cumplir con estos requisitos, el estándar utiliza
ampliamente los mecanismos conocidos de criptografía como ser: algoritmos simétricos,
algoritmos asimétricos, funciones hash, y certificados y autorizaciones digitales. La
utilización de cada uno de ellos depende de los requerimientos y restricciones de cada
situación en particular, ya que, por ejemplo, existe un compromiso entre velocidad de
codificación-decodificación y nivel de seguridad, que determina que un algoritmo sea
mejor que otro según la situación.
2.1.3.5
Capas superiores
Sobre esta pila, se han comenzado a estandarizar nuevos protocolos de la “suite” de 1609
que realizan aplicaciones específicas como por ejemplo el IEEE 1609.11 que realiza todo lo
necesario para establecer mecanismos de pago electrónico sobre WAVE.
2.1.3.6
Situación de WAVE
Para comprender mejor el concepto de WAVE y poder marcar su área de aplicación hay
que definir dos conceptos previamente:

OBU (On Board Unit) hace referencia a la entidad embarcada, a la plataforma
capaz de dar soporte a los servicios ITS sobre WAVE en movilidad.

RSU (Roadside Unit) hace referencia a la entidad fija situada en la infraestructura
que provee de acceso a red e información a la entidad embarcada mediante
WAVE.
Por tanto WAVE puede identificarse como aquella tecnología inalámbrica que permite
comunicaciones V2V y V2I de vehículos en movimiento. En la queda retratado el ámbito
de aplicación de los sistemas WAVE:
Figura 10: Ejemplo de un Sistema WAVE y sus Componentes
Otro aspecto interesante a tratar al hablar de WAVE es la banda asociada dentro del
espectro de comunicaciones. Tanto en Europa como en Estados Unidos se están acercando
las posturas lo máximo posible para conseguir realizar dispositivos lo más parejos posibles
para poder ser utilizados en ambas regiones, aún así las bandas dedicadas a los sistemas
27
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
de transporte siguien siendo un poco diferentes, dejando sin servicio a algunos canales:
Figura 11: Distribución Frecuencial reservada a ITS
Comentar que en Europa WAVE se ha estandarizado bajo el nombre ISO CALM-M5 (hace
referencia a la banda de los 5GHz) o bajo el nombre ITS-G5. Existe cierto problema con la
tecnología DSRC CEN, utilizada sobre todo para el pago electrónico en carreteras de peaje.
Ésta funciona en la banda de los 5.8GHz y existen problemas de interferencias entre ellas.
Para esta tecnología se han definido una serie de aplicaciones de seguridad en la carretera
específicas, ya que es la única capaz de cumplir los requisitos de:

latencia menor a 100 ms

frecuencia de 10 Hz

A alta velocidad

En situaciones de corto alcance, próximas
Todas estas han sido recogidas en un catálogo de uso para la seguridad vial, puede ser
consultado en el ANEXO 1.
2.1.4
Tecnologías Adaptadas por ISO CALM
La arquitectura CALM (Communication Access for Land Mobiles) resultante del proyecto
europeo CVIS (explicado más adelante) proporciona la comunicación I2I, V2I y V2V.
CALM está basado en IPv6 y proporciona un conjunto de protocolos y parámetros
estandarizados para las comunicaciones inalámbricas de medio y largo alcance de alta
velocidad. Además, constituye una capa de alto nivel que define reglas que rigen sobre
protocolos y tecnologías inalámbricas ad-hoc ya existentes y/o desarrolladas.
Los métodos de transmisión usados por CALM que quedarán recogidos a continuación
son:

WiMax

Sistemas celulares

Comunicación Infrarroja

DSRC CEN

CALM M5.
28
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 12: Arquitectura de ISO CALM
Esta arquitectura es capaz de determinar en todo momento qué tecnología inalámbrica
está disponible en una cierta localización y decidir cuál utilizar para una comunicación
óptima. Por otra parte siempre garantiza varios canales de comunicación de forma
simultánea, de esta forma los vehículos y la infraestructura pueden mantener una
comunicación de forma continua, incluso si por algún motivo algún canal individual no se
encuentra disponible. Este hecho es muy importante para aplicaciones relacionadas con la
seguridad. Aun no existe una solución satisfactoria para algunos aspectos relevantes de las
comunicaciones vehiculares como puede ser el acceso inalámbrico simultáneo por parte de
un alto número de vehículos, ubicación y redistribución de frecuencias, identificación de
Gateway e infraestructuras disponibles o mecanismos de priorización en la transmisión de
datos. A continuación se analizan con más detenimiento algunas de las tecnologías más
destacables recogidas por CALM.
2.1.4.1
CALM WiMax
Se trata de una tecnología bastante parecida a la WiFi, solo que WiMax puede cubrir zonas
de hasta 50 Km. Se velocidad de transmisión de datos oscila entre 1 y 75 Mbps y opera
entre las bandas de 2.5 a 5.8 GHz con y sin licencia de operación. A pesar de que aun esta
en desarrollo se espera que pueda dar servicio a redes vehiculares a velocidades entre 20
km/h y 200km/h con el objetivo de satisfacer comunicaciones I2V, V2I, I2I y hasta V2V.
2.1.4.2
CALM 2G
Bajo la ISO 21212 incluye las redes móviles GSM de segunda genaracion (2G) o de segunda
generación extendida (2.5G). Emplean la tecnología de servicio general de paquetes vía
radio o GPRS (Global Packet Radio Service) para la comunicación V2I y viceversa. Cabe
destacar su rango de alcance alrededor de los 10 km, su velocidad para la transmisión de
datos, entre 80 y 384 kbps, y su banda de operación, entre 0.8 a 1.9 GHz.
2.1.4.3
CALM 3G
Bajo la ISO 21213 que es similar a la anterior con la diferencia de que se trata de redes
UMTS, es decir, de tercera generación (3G) o de tercera generación extendida (3.5G).
29
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Ambas redes emplean la tecnología para el acceso de paquetes de alta velocidad HSPA
(High Speed Packet Access) para los mismos escenarios de la tecnología 2G. Cabe destacar
el aumento de ancho de banda que pasa a ser de hasta 7.2 Mbps con alcances que oscilan
entre los 10-35 km operando en el rango de 0.8, 1.9, 2.1 GHz.

2.1.4.4
Es importante hacer mención dentro de las redes móviles a la tecnología LTE
(Long Term Evolution) que postula como la cuarta generación (4G) y que
actualmente se estudiando su integración al estándar CALM.
CALM-IR
Bajo la ISO 21214 es utilizado principalmente para las comunicaciones entre los mismos
vehículos o entre el vehículo y la infraestructura. Esta tecnología es utilizada con
frecuencia en los sistemas de peaje automático en los países asiáticos tales como Japón.
Entre sus características destacamos su ancho de banda entre 1Mbps hasta 128 Mbps, su
tiempo de enlace entre 1 a 10 ms y su funcionamiento para distancias de 10 m, 100 m o 1
km.
2.1.4.5
CALM DSRC
El DSRC (Dedicated Short Range Communication) CEN es una tecnología que pretende
ser un complemento a las redes de móviles al proveer velocidades de transferencia muy
altas en circunstancias en las que es importante minimizar la latencia del enlace de
comunicaciones en zonas relativamente pequeñas. Una de las condiciones más
importantes para lograr estos propósitos es minimizar la latencia.
DSRC tiene dos usos principales:

Seguridad vial: sistema de alertas de emergencia para vehículos, prevención de
colisiones en intersecciones, alertas de aproximación de vehículos de emergencias,
inspecciones de seguridad de vehículos, señalización de prioridad de vehículos,
etc.

Transacciones comerciales e información de viaje: pago automático de servicios
como autovías parkings, etc. Información en ruta sobre tráfico, restaurantes, etc.
2.1.4.6
CALM M5
Se encuentra en la ISO 21215, está orientado a satisfacer las comunicaciones entre
vehículos, es decir, contribuirá a la formación de redes vehiculares o VANETs. CALM M5
es muy cercano a las tecnologías de la iniciativa WAVE, es decir, IEEE 802.11p y la familia
de estándares IEEE 1609.X. Dicha iniciativa ofrece velocidades promedio de 6 a 27 Mbps,
rango de alcance de un 1km y latencias bajas de 200µs y opera en los 5.9GHz.
30
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2.2 Comunicación Interna del Vehículo
La red interna de comunicaciones que se quiere montar en el vehículo está basada en el
protocolo de comunicaciones CAN, para su realización se seguirá la siguiente arquitectura:
Figura 13: Arquitectura de la Red Interna del
Vehículo
El bus CAN (Controller Area Network), el cual es un bus serie creado para la transmisión
de mensajes en entornos distribuidos. Se ha elegido este protocolo porque está presente en
la industria automovilística desde 1992, por lo que está sobradamente justificado su uso en
este proyecto. El otro protocolo que se usará en el proyecto es OBD (On Board Diagnostic).
Este sistema de diagnosis permite localizar los errores producidos en el vehículo,
ahorrando tiempo en la localización y reparación de averías. En caso de fallo, este
protocolo es el encargado de almacenar toda la información referida a dicho fallo, así como
avisar al conductor del mal funcionamiento. Como medio físico, utiliza el bus CAN y se
comunica con el exterior mediante un conector estandarizado. Desde 2008 todos los
vehículos llevan incorporado un sistema OBD.
2.2.1
Protocolo CAN
La especificación CAN (versión 2.0) de Bosch fue sometida a la estandarización
internacional a comienzos de los 90. Concretamente en Noviembre de 1993, después de
diversos conflictos políticos, se publicó el estándar ISO 11898, que definía además una capa
física para velocidades de hasta 1 Mbps. Paralelamente, un formato de CAN tolerante a
fallos se incluyó en la ISO 11519-2. En 1995, el estándar se amplió con la descripción del
identificador CAN de 29 bits. Desafortunadamente, todas las especificaciones y
estandarizaciones publicadas acerca de CAN contenían errores o estaban incompletas.
Para evitar incompatibilidades, Bosch se cercioró, y sigue haciéndolo, de que todos los
microcontroladores CAN cumplen con el modelo de referencia que ellos definieron.
Las especificaciones CAN han sido revisadas y estandarizadas con el tiempo en diferentes
secciones:

La norma ISO 11898-1 describe la capa de transmisión de datos CAN, la ISO 118982 la capa física CAN no tolerante a fallos.

La ISO 11898-3 la capa física CAN tolerante a fallos.

Los estándares de ISO 11992 (referente a la interfaz para camiones y remolques).

ISO 11783 (referente a la maquinaria agrícola y forestal) definen los perfiles del uso
31
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
de CAN basados en el US-protocol J1939.
A modo de ejemplo, en la siguiente figura se puede ver una arquitectura típica del bus de
comunicaciones internas de un vehículo:
Figura 14: Esquema de comunicaciones internas de SEAT Altea
basado en Bus CAN
A continuación se explicará el protocolo CAN capa a capa según la pila OSI.
2.2.1.1
Capa Física
La capa física de CAN, es responsable de la transferencia de bits entre los distintos nodos
que componen la red. Define aspectos como niveles de señal, codificación, sincronización y
tiempos en que los bits se transfieren al bus. En la especificación original de CAN, la capa
física no fue definida, permitiendo diferentes opciones para la elección del medio y niveles
eléctricos de transmisión. Las características de las señales eléctricas en el bus, fueron
establecidas más tarde por el ISO 11898 para las aplicaciones de alta velocidad (hasta
1Mbps) destinadas para controlar el motor e interconectar las unidades de control
electrónico (ECU) y, por el estándar ISO 11519 para las aplicaciones de baja velocidad
(hasta 125 Kbps) tolerante a fallos dedicada a la comunicación de los dispositivos
electrónicos internos como son control de puertas, techo corredizo, luces y asientos.

Estándar 11519 (baja velocidad): Los nodos conectados en este bus interpretan dos
niveles lógicos denominados dominante y recesivo:
o
Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2V,
con CAN_H = 3.5V y CAN_L = 1.5V (nominales).
o
Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 5V, con
CAN_H = 0V y CAN_L = 5V (nominales).
32
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 15: Niveles de los Buses en Baja Velocidad
A diferencia del bus de alta velocidad, el bus de baja velocidad requiere dos resistencias en
cada transceptor: RTH para la señal CAN_H y RTL para la señal CAN_L. Esta
configuración permite al transceptor de bus de baja velocidad (fault-tolerant) detectar
fallas en la red. La suma de todas las resistencias en paralelo, debe estar en el rango de 100500Ω.
Figura 16: Colocación del bus en Baja Velocidad

Estandar 11898 (alta velocidad):
Figura 17: Niveles de los buses en Alta Velocidad
33
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Los nodos conectados en este bus interpretan los siguientes niveles lógicos:
o
Dominante: la tensión diferencial (CAN_H - CAN_L) es del orden de 2V,
con CAN_H = 3.5V y CAN_L = 1.5V (nominales).
o
Recesivo: la tensión diferencial (CAN_H - CAN_L) es del orden de 0V, con
CAN_H = CAN_L = 2.5V (nominales).
El par de cables trenzados (CAN_H y CAN_L) constituyen una transmisión de línea. Si
dicha transmisión de línea no está configurada con los valores correctos, cada trama
transferida causa una reflexión que puede originar fallos de comunicación. Como la
comunicación en el bus CAN fluye en ambos sentidos, ambos extremos de red deben de
estar cerrados mediante una resistencia de 120Ω. Ambas resistencias deberían poder
disipar 0.25W de potencia.
Figura 18: Configuración del bus en Alta Velocidad
A continuación se muestran los buses y las velocidades dependiendo de su naturaleza,
todo dependerá de la prioridad de los nodos que estén incluidos:
Tabla 3: Velocidades CAN Según Bus
Bus
Velocidad
máxima
Nodos
Tracción
Alta (1Mbps)
Motor (ECU), ABS, Dirección, Cambio,
Airbag
Confort
Baja (125Kbps)
Cierre centralizado, Alarma, Climatizador
Infotenimiento
Baja (125Kbps)
Radio, Pantalla
Cuadro de
instrumentos
Baja (125Kbps)
Cuadro de instrumentos
Diagnosis
Media (500Kbps)
Motor (ECU), Cambio automático
Baja (125Kbps)
34
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Formato de codificación y sincronización de datos
La codificación de bits se realiza por el método NRZ (Non-Return-to Zero) que se
caracteriza por que el nivel de señal puede permanecer constante durante largos periodos
de tiempo y habrá que tomar medidas para asegurarse de que el intervalo máximo
permitido entre dos señales no es superado. Esto es importante para la sincronización (Bit
Timing). Este tipo de codificación requiere poco ancho de banda para transmitir, pero en
cambio, no puede garantizar la sincronización de la trama transmitida. Para resolver esta
falta de sincronismo se emplea la técnica del “bit stuffing”: cada 5 bits consecutivos con el
mismo estado lógico en una trama (excepto del delimitador de final de trama y el espacio
entre tramas), se inserta un bit de diferente polaridad, no perdiéndose así la
sincronización. Por otro lado este bit extra debe ser eliminado por el receptor de la trama,
que sólo lo utilizará para sincronizar la transmisión. No hay flanco de subida ni de bajada
para cada bit, durante el tiempo de bit hay bits dominantes (“0”) y recesivos (“1”) y
disminuye la frecuencia de señal respecto a otras codificaciones.
2.2.1.2
Capa de Enlace de Datos
Esta capa es la responsable de controlar el flujo de información entre los nodos de la red.
Es decir, se encarga de la transmisión de los bits en “frames” o tramas de información, se
ocupa de que los mensajes lleguen al destino sin errores, controla las secuencias de
transmisión, los acuses de recibo y si en determinado caso no se recibe un mensaje
correctamente se encarga de retransmitirlo. Se puede dividir esta capa en dos subcapas
que se ocupan de diferentes tareas:

Subcapa LLC (Control de Enlace Lógico)
La subcapa LLC describe la parte alta de la capa de enlace de datos y define las tareas
independientes del método de acceso al medio, asimismo proporciona dos tipos de
servicios de transmisión sin conexión al usuario de la capa LLC (LLC user):
o
Servicio de transmisión de datos sin reconocimiento: proporciona, al
usuario LLC, los medios para intercambiar unidades de datos de servicio
de enlace (LSDU, Link Service Data Units) sin establecer una conexión de
enlace de datos. La transmisión de datos puede ser punto a punto,
multidifusión o difusión.
o
Servicio de petición de datos remota sin reconocimiento: proporciona, al
usuario LLC, los medios para solicitar que un nodo remoto transmita sus
LDSUs sin establecer una conexión de enlace de datos.
De acuerdo con los tipos de servicios, se definen dos formatos de tramas, de datos LLC y
remota LLC. Ambos formatos definen identificadores de 11 bits (estándar) y de 29 bits
(extendida).
Las funciones de la subcapa LLC son las siguientes:
o
Filtrar mensajes (frame acceptance filtering): el identificador de una trama
no indica la dirección destino pero define el contenido del mensaje, y
mediante esta función todo receptor activo en la red determina si el
mensaje es relevante o no para sus propósitos.
o
Notificar sobrecarga (overload notification): si las condiciones internas de
un receptor requieren un retraso en la transmisión de la siguiente trama de
datos o remota, la subcapa LLC transmite una trama de sobrecarga.
Solamente se pueden generar dos tramas de sobrecarga como máximo.
o
Proceso de recuperación (recovery management): la subcapa LLC
proporciona la capacidad de retransmisión automática de tramas cuando
una trama pierde el arbitraje o presenta errores durante su transmisión,
dicho servicio se confirma al usuario hasta que la transmisión se completa
con éxito.
35
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Subcapa MAC (Control de Acceso al Medio):
Esta subcapa representa el núcleo del protocolo CAN. Por un lado presenta los mensajes
recibidos a la subcapa LLC y acepta los mensajes para ser transmitidos a dicha subcapa y
por otro lado es responsable del mecanismo de arbitraje de acceso al medio.
Unas de las características que distingue a CAN con respecto a otras normas, es su técnica
de acceso al medio denominada como CSMA/CD+CR o "Carrier Sense, Multiple
Access/Collision Detection + Collision Resolution" (Acceso Múltiple con detección de
portadora, detección de colisión más Resolución de colisión). Cada nodo debe vigilar el
bus en un periodo sin actividad antes de enviar un mensaje (Carrier Sense) y además, una
vez que ocurre el periodo sin actividad cada nodo tiene la misma oportunidad de enviar
un mensaje (Multiple Access). En caso de que dos nodos comiencen a transmitir al unísono
se detectará la colisión.
El método de acceso al medio utilizado en bus CAN añade una característica adicional: la
resolución de colisión. En la técnica CSMA/CD utilizada en redes Ethernet ante colisión de
varias tramas, todas se pierden. CAN resuelve la colisión con la supervivencia de una de
las tramas que chocan en el bus. Además la trama superviviente es aquella a la que se ha
identificado como de mayor prioridad. La resolución de colisión se basa en una topología
eléctrica que aplica una función lógica determinista a cada bit, que se resuelve con la
prioridad del nivel definido como bit de tipo dominante. Definiendo el bit dominante
como equivalente al valor lógico '0' y bit recesivo al nivel lógico '1' se trata de una función
AND de todos los bits transmitidos simultáneamente. Cada transmisor escucha
continuamente el valor presente en el bus, y se retira cuando ese valor no coincide con el
que dicho transmisor ha forzado. Mientras hay coincidencia la transmisión continua,
finalmente el mensaje con identificador de máxima prioridad sobrevive. Los demás nodos
reintentarán la transmisión lo antes posible.
Se ha de tener en cuenta que la especificación CAN de Bosh no establece cómo se ha de
traducir cada nivel de bit (dominante o recesivo) a variable física. Cuando se utiliza par
trenzado según ISO 11898 el nivel dominante es una tensión diferencial positiva en el bus,
el nivel recesivo es ausencia de tensión, o cierto valor negativo, (los transceptores no
generan corriente sobre las resistencias de carga del bus). Esta técnica aporta la
combinación de dos factores muy deseados en aplicaciones industriales distribuidas: la
posibilidad de fijar con determinismo la latencia en la transmisión de mensajes entre nodos
y el funcionamiento en modo multimaestro sin necesidad de gestión del arbitraje, es decir
control de acceso al medio, desde las capas de software de protocolo. La prioridad queda
así determinada por el contenido del mensaje, en CAN es un campo determinado, el
identificador de mensaje, el que determina la prioridad.
En un bus único, un identificador de mensaje ha de ser asignado a un solo nodo concreto,
es decir, se ha de evitar que dos nodos puedan iniciar la transmisión simultánea de
mensajes con el mismo identificador y datos diferentes. El protocolo CAN establece que
cada mensaje es único en el sistema, de manera que por ejemplo, si en un automóvil existe
la variable “presión de aceite”, esta variable ha de ser transmitida por un nodo concreto,
con un identificador concreto, con una longitud fija concreta y coherente con la
codificación de la información en el campo de datos.
En la siguiente figura se ve un ejemplo de arbitraje en un bus CAN.
36
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 19: Arbitraje del Bus CAN

Tramas
El protocolo CAN está basado en mensajes, no en direcciones. El nodo emisor transmite el
mensaje a todos los nodos de la red sin especificar un destino y todos ellos escuchan el
mensaje para luego filtrarlo según le interese o no. Existen distintos tipos de tramas
predefinidas por CAN para la gestión de la transferencia de mensajes:
o
Trama de datos: se utiliza normalmente para poner información en el bus y
la pueden recibir algunos o todos los nodos.
o
Trama de información remota: puede ser utilizada por un nodo para
solicitar la transmisión de una trama de datos con la información asociada
a un identificador dado. El nodo que disponga de la información definida
por el identificador la transmitirá en una trama de datos.
o
Trama de error: se generan cuando algún nodo detecta algún error
definido.
o
Trama de sobrecarga: se generan cuando algún nodo necesita más tiempo
para procesar los mensajes recibidos.
o
Espaciado entre tramas: las tramas de datos (y de interrogación remota) se
separan entre sí por una secuencia predefinida que se denomina espaciado
inter-trama.
37
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
o
Bus en reposo: En los intervalos de inactividad se mantiene constantemente
el nivel recesivo del bus.
En un bus CAN los nodos transmiten la información espontáneamente con tramas de
datos, bien sea por un proceso cíclico o activado ante eventos en el nodo. La trama de
interrogación remota sólo se suele utilizar para detección de presencia de nodos o para
puesta al día de información en un nodo recién incorporado a la red. Los mensajes pueden
entrar en colisión en el bus, el de identificador de mayor prioridad sobrevivirá y los demás
son retransmitidos lo antes posible.
Análisis de las tramas:

Trama de Datos: Es la utilizada por un nodo normalmente para poner información
en el bus. Puede incluir entre 0 y 8 bytes de información útil. Los mensajes de datos
consisten en celdas que envían datos y añaden información definida por las
especificaciones CAN:
Figura 20: Formato de la trama de datos
o
Inicio de trama (SOF): el inicio de trama es una celda de un sólo bit siempre
dominante que indica el inicio del mensaje, sirve para la sincronización con
otros nodos.
o
Celda de Arbitraje (Arbitration Field): es la celda que concede prioridad a
unos mensajes o a otros:
o
En formato estándar tendrá 11 bits seguidos del bit RTR (Remote
Transmisión Request) que en este caso será dominante.
o
En formato extendido serán 11 bits de identificador base y 18 de extendido.
El bit SRR substituye al RTR y será recesivo. La trama en formato estándar
prevalece sobre la extendida.
38
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 21: Formatos de Tramas Normal y Extendida
o
Celda de control (Control Field): el campo de control está formado por dos
bits reservados para uso futuro y cuatro bits adicionales que indican el
número de bytes de datos. En realidad el primero de estos bits (IDE) se
utiliza para indicar si la trama es de CAN Estándar (IDE dominante) o
Extendido (IDE recesivo). el segundo bit (RB0) es siempre recesivo. Los
cuatro bits de código de longitud (DLC) indican en binario el número de
bytes de datos en el mensaje (0 a 8).
o
Celda de Datos (Data Field): es el campo de datos de 0 a 8 bytes.
o
CRC (Código de redundancia cíclica): tras comprobar este código se podrá
comprobar si se han producido errores.
o
Celda de reconocimiento (ACK): es un campo de 2 bits que indica si el
mensaje ha sido recibido correctamente. El nodo transmisor pone este bit
como recesivo y cualquier nodo que reciba el mensaje lo pone como
dominante para indicar que el mensaje ha sido recibido.
o
Fin de trama (EOF): consiste en 7 bits recesivos sucesivos e indica el final de
la trama.
o

Espaciado entre tramas (IFS): consta de un mínimo de 3 bits recesivos.
Trama Remota: Los nodos tienen habilidad para requerir información a otros
nodos. Un nodo pide una información a los otros y el nodo que tiene dicha
información envía una comunicación con la respuesta que puede ser recibida
además por otros nodos si están interesados.
Figura 22: Formato de Trama Remota
39
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
En este tipo de mensajes se envía una trama con el identificador del nodo requerido, a
diferencia con los mensajes de datos, el bit RTR toma valor recesivo y no hay campo de
datos. En caso de que se envíe un mensaje de datos y de petición remota con el mismo
identificador, el de datos ganará el acceso al bus puesto que el RTR lleva valor dominante.

Trama de Error: Las tramas de error son generadas por cualquier nodo que detecta
un error. Se basan en el valor de dos campos:
o
Indicador de error ("Error Flag"): es distinto según el estado de error del
nodo que detecta el error.
o
Delimitador de error (“Error Delimeter”): consta de 8 bits recesivos
consecutivos y permite a los nodos reiniciar la comunicación limpiamente
tras el error.
Figura 23: Formato de la Trama de Error
Si un nodo en estado de error "Activo" detecta un error en el bus interrumpe la
comunicación del mensaje en proceso generando un "Indicador de error activo" que
consiste en una secuencia de 6 bits dominantes sucesivos. Esta secuencia rompe la regla de
relleno de bits y provocará la generación de tramas de error en otros nodos. Por tanto el
indicador de error puede extenderse entre 6 y 12 bits dominantes sucesivos. Finalmente se
recibe el campo de delimitación de error formado por los 8 bits recesivos. Entonces la
comunicación se reinicia y el nodo que había sido interrumpido reintenta la transmisión
del mensaje.
Si un nodo en estado de error "Pasivo" detecta un error, el nodo transmite un "Indicador de
error pasivo" seguido, de nuevo, por el campo delimitador de error. El indicador de error
de tipo pasivo consiste en 6 bits recesivos seguidos y, por tanto, la trama de error para un
nodo pasivo es una secuencia de 14 bits recesivos. De aquí se deduce que la transmisión de
40
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
una trama de error de tipo pasivo no afectará a ningún nodo en la red, excepto cuando el
error es detectado por el propio nodo que está transmitiendo. En ese caso los demás nodos
detectarán una violación de las reglas de relleno y transmitirán a su vez tramas de error.
Tras señalar un error por medio de la trama de error apropiada cada nodo transmite bits
recesivos hasta que recibe un bit también recesivo, luego transmite 7 bits recesivos
consecutivos antes de finalizar el tratamiento de error.
La regla de relleno de bits, consiste en que cada cinco bits de igual valor se introduce uno
de valor inverso tal y como se ve en la figura siguiente:
Figura 24: Relleno de Bits

Trama de Sobrecarga: Una trama de sobrecarga tiene el mismo formato que una
trama de error activo. Sin embargo, la trama de sobrecarga sólo puede generarse
durante el espacio entre tramas. De esta forma se diferencia de una trama de error,
que sólo puede ser transmitida durante la transmisión de un mensaje.
Figura 25: Formato de la Trama de Sobrecarga
41
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
La trama de sobrecarga consta de dos campos, el Indicador de Sobrecarga, y el
delimitador.

El indicador de sobrecarga consta de 6 bits dominantes que pueden ser seguidos
por los generados por otros nodos, dando lugar a un máximo de 12 bits
dominantes.

El delimitador es de 8 bits recesivos.
Una trama de sobrecarga puede ser generada por cualquier nodo que debido a sus
condiciones internas no está en condiciones de iniciar la recepción de un nuevo mensaje.
De esta forma retrasa el inicio de transmisión de un nuevo mensaje. Un nodo puede
generar como máximo 2 tramas de sobrecarga consecutivas para retrasar un mensaje.
Otra razón para iniciar la transmisión de una trama de sobrecarga es la detección por
cualquier nodo de un bit dominante en los 3 bits de "intermission".

Espacio entre Tramas: El espacio entre tramas separa una trama (de cualquier tipo)
de la siguiente trama de datos o interrogación remota. El espacio entre tramas ha
de constar de, al menos, 3 bits recesivos. Esta secuencia de bits se denomina
"intermission". Una vez transcurrida esta secuencia un nodo en estado de error
activo puede iniciar una nueva transmisión o el bus permanecerá en reposo
(manteniendo constante el nivel recesivo del bus). Para un nodo en estado error
pasivo la situación es diferente, deberá esperar una secuencia adicional de 8 bits
recesivos antes de poder iniciar una transmisión. De esta forma se asegura una
ventaja en inicio de transmisión a los nodos en estado activo frente a los nodos en
estado pasivo.
2.2.2
OBD II
Durante los años 70 y principios de los 80 algunos fabricantes empezaron a usar
componentes electrónicos de control y diagnóstico de errores en sus automóviles. Al
principio fue solo para conocer y controlar las emisiones del vehículo y adaptarlas a los
estándares exigidos, pero con el paso del tiempo estos sistemas fueron volviéndose cada
vez más sofisticados. Para reducir la contaminación del aire, la "California Air Resources
Board" (CARB) determinó en 1988 que todos los automóviles a gasolina contaran con OBD
(On Board Diagnostics), para que controlara los límites máximos de emisiones. Medidas
más estrictas en los límites de emisiones en 1996 llevó a la creación del estándar OBD II
(On Board Diagnostic Second Generation). Este sistema permite diagnosticar los errores
que se producen en el vehículo sin necesidad de desmontar partes para descubrir la
procedencia de dicho error. A diferencia de otros sistemas desarrollados antes de 1996,
OBD II se caracteriza por ser un sistema estandarizado, que permite, de manera fácil, ver
que errores se han producido en un vehículo cualquiera utilizando una única codificación
y claro está, un conector estandarizado.
En Europa se introdujo el OBD ajustándose al OBD-II americano. Desde 1996 el OBD II es
un requisito legal para automóviles nuevos en Estados Unidos. En base a esta regla
americana se impuso en los noventa la inclusión de sistemas de diagnóstico también para
los automóviles destinados al mercado europeo. Según la Directiva 98/69EG, los
automóviles a gasolina del año 2000 en adelante, los diésel de 2003 en adelante, y los
42
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
camiones de 2005 en adelante tienen que estar provistos de un OBD. La interfaz estándar
del OBD-II no solamente es utilizada por el fabricante para sus funciones avanzadas de
diagnóstico sino también por aquellos que van más allá de lo que la ley exige.
La siguiente etapa planeada es el OBD-III, en el que los propios automóviles se comunican
con las autoridades si se produce un empeoramiento de las emisiones de gases nocivos
mientras está en marcha. Si esto sucede, se pedirá a través de una tarjeta indicativa, que se
corrijan los defectos.
Actualmente se emplean los estándares que se emplean son:

OBD-II en Estados Unidos.

EOBD en Europa.

JOBD en Japón.
2.2.2.1
Funciones OBD II
Todos los vehículos actuales, disponen de una o varias ECU (Engine Control Unit), que se
encargan de gestionar ciertos parámetros del motor del vehículo para asegurar su correcto
funcionamiento. Las relaciones entre estos parámetros deben mantenerse acotadas,
dependiendo de las condiciones externas varían ciertos rangos, en caso contrario es que se
está produciendo algún mal funcionamiento en nuestro vehículo.
Los parámetros principales que dictan como debe estar funcionando nuestro motor, y si
verifican si todo funcionando correctamente son:

Velocidad

Carga

Temperatura del motor

Consumo de combustible

Temperatura ambiente

Caudal de aire

Emisiones
Para conocerlos, los automóviles actuales, incorporan una gran cantidad de sensores, que
permiten a la ECU conocer cuáles son las condiciones externas, y decidir cómo actuar
sobre el motor. En caso de que alguno de los parámetros se salga de los rangos marcados,
el sistema OBD II, es el encargado de almacenar esta información, y avisar al conductor de
que algo sufre un mal funcionamiento, señalizando con un indicador luminoso que es
recomendable ir al taller a revisar que error se ha producido.
Una vez el vehículo llega al taller, el equipo de mecánicos, puede acceder a la información
almacenada por el OBD II, ver que error era el que se había producido, y arreglarlo en caso
de necesidad sin tener que hacer múltiples pruebas para descubrir la procedencia del
error.
Algunas de las funciones específicas de control que puede desempeñar OBD II según el
tipo de motor son las siguientes:

Control en los motores de gasolina
o
Vigilancia del rendimiento del catalizador.
o
Diagnóstico de envejecimiento de sondas lambda.
o
Prueba de tensión de sondas lambda.
o
Sistema de aire secundario (si el vehículo lo incorpora).
o
Sistema de recuperación de vapores de combustible (cánister).
43
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

o
Prueba de diagnóstico de fugas.
o
Sistema de alimentación de combustible.
o
Fallos de la combustión.
o
Control del sistema de gestión electrónica.
o
Sensores y actuadores del sistema electrónico que intervienen en la gestión
del motor o están relacionados con las emisiones de escape
Control en los motores diésel
o
Fallos de la combustión.
o
Regulación del comienzo de la inyección.
o
Regulación de la presión de sobrealimentación.
o
Recirculación de gases de escape.
o
Funcionamiento del sistema de comunicación entre unidades de mando,
por ejemplo el Can-Bus.
o
Control del sistema de gestión electrónica.
o
Sensores y actuadores del sistema electrónico que intervienen en la gestión
del motor o están relacionados con las emisiones de escape.
o
Control de la contaminación
Uno de los aspectos más importantes que permite controlar OBD II es la contaminación
que produce el vehículo. El estado actual de la técnica no permite, o sería muy caro,
realizar la medida directa de los gases CO (monóxido de carbono), HC (hidrocarburos) y
NOx (óxidos nítricos), por lo que este control lo realiza la ECU de manera indirecta,
detectando los niveles de contaminación a partir del análisis del funcionamiento de los
componentes adecuados y del correcto desarrollo de las diversas funciones del equipo de
inyección que intervengan en la combustión. En los vehículos con OBD II se incorpora una
segunda sonda lambda que se instala detrás del catalizador para verificar el
funcionamiento del mismo y de la sonda lambda anterior al catalizador. En el caso de que
ésta presente envejecimiento o esté defectuosa, no es posible la corrección de la mezcla con
precisión, lo que deriva en un aumento de la contaminación y afecta al rendimiento del
motor. Para verificar el estado de funcionamiento del sistema de regulación lambda, el
OBD II analiza el estado de envejecimiento de la sonda, la tensión que generan y el estado
de funcionamiento de los elementos calefactores. El envejecimiento de la sonda se
determina en función de la velocidad de reacción de la misma, que es mayor cuanto más
deteriorada se encuentre.
2.3 Estudio Controlador CAN Stand Alone
Tras la elección de los dispositivos que se verá más adelante fue necesario aprender el
funcionamiento de un controlador CAN que funcionase por si solo, para ello se realizó un
estudio del microcontrolador 8051 de Intel núcleo que se usa para construir un controlador
CAN SJA1000, referencia de Bocsh en todos sus diseños.
2.3.1
Microcontrolador 8051
El microcontrolador 8051 fue desarrollado por Intel en 1980, su familia fue conocida como
los MCS 051, principalmente pensado para dispositivos empotrados, este controlador ha
sido muy utilizado en varios diseños y en particular en el desarrollo de las entidades de
bus CAN. La popularidad de este microcontrolador es tal que su núcleo reside en más de
100 microcontroladores de más de 20 fabricantes independientes como Atmel, Dallas
Semiconductor, Philips, Winbond, entre otros. Llegando a imponerse como un estándar de
facto y a acuñar el término “compatible con 8051”. Históricamente, la primera tirada nació
con unas características muy modestas en comparación con los nuevos microcontroladores
44
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
existentes de la época, pero la razón principal de su éxito fue una configuración
hábilmente elegida que satisfacía las necesidades de un gran número de usuarios y
además permitía al mismo tiempo constantes expansiones.
Figura 26: (a) PinOut 8051 (b) Bloques Básicos 8051
Destacar de la Figura 26 (b) que el 8051 posee una arquitectura Harvard, con áreas de
memoria separadas para datos e instrucciones. Su juego de instrucciones es CISC
(Complex Intrusction Set Computer). Posee un bus de datos interno de 8-bit de anchura y
un bus de direcciones interno de 16-bit. Cuenta con los siguientes registros
implementados: SFR(Special Function Register), PSW (Processor Status Word), A
(Accumulator), B register, SP (Stack Pointer) y registros para la entrada/salida serie,
temporizadores, puertos y manejo de interrupciones. Éstos pueden observarse, al igual
que una vista más detallada de la arquitectura interna en la Figura 27.
Figura 27: Arquitectura Interna 8051
45
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Prestando ahora atención en la Figura 26 (a) el microcontrolador dispone de 40 pines de los
cuales serán utilizados los siguientes al configurar la entidad para trabajar con CAN (Tabla
4):
Tabla 4: Pines correspondientes a las señales usadas por la entidad CAN
PIN
USO
Reset
Realiza el reset del dispositivo
RXD
Línea de comunicación serie para recepción, síncrona o asíncrona
TXD
Línea de comunicación serie para transmisión, síncrona o asíncrona
WR
Habilitación de la señal de escritura
RD
Habilitación de la señal de lectura
X1 y
X2
Pines dónde se conectará el reloj del sistema
P0.X
Puerto de entrada/salida configurado para acceder a los registros
ALE
Señal que sirve para demultiplexar direcciones y datos en el puerto de salida
configurado
A continuación se muestra en la Figura 28 el diagrama funcional de la entidad CAN, el
cual sin tener un manual de referencia que muestre cómo funciona aporta poca luz al
trabajo con este tipo de controlador. Es por ello que dado que el más usado es el
controlador CAN SJA1000 será el utilizado para analizar y entender el funcionamiento de
la entidad.
Figura 28: Diagrama Funcional Entidad CAN
2.3.2
Controlador SJA1000
La major manera de presentar a este componente es observar su diagrama de bloques y
posteriormente analizar sus entradas y salidas:
46
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 29: Esquema de Bloques SJA1000
Tabla 5: Señales del controlador SJA1000
SIMBOLO
PIN
DESCRIPCIÓN
AD7-AD0
2,1, 28-23
Bus multiplexado de datos y direcciones
ALE/AS
3
Address Lach Enable (modo Intel), AS (modo motorola)
4
Chip Select, un valor bajo permite el acceso al SJA1000
5
Señal de lectura (modo Intel), Señal de Encendido (motorla)
6
Señal de escritura
CLKOUT
7
Reloj de salida tras configurarlo con el CDR
VSS1
8
Tierra
XTAL1
9
Entrada del oscilador externo
XTAL2
10
Salida del amplificador del oscilador, al aire si es externo
MODE
11
Valor alto (intel), un valor bajo (Motorola)
VDD3
12
Fuente de 5V para la salida del driver
/E
47
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
TX0
13
Salida de la salida del driver 0 CAN al bus físico
TX1
14
Salida de la salida del driver 1 CAN al bus físico
VSS3
15
Tierra para la salida del driver
16
Interrupción de salida
17
Entrada de reset hardware
VDD2
18
5V para la entrada del comparador
RX0,RX1
19,20
Entrada del bus CAN físico a los comparadores del SJA1000
VSS2
21
Tierra para el comparador de entrada
VDD1
22
5V para los circuitos lógicos
A continuación se explican los registros del controlador CAN SJA1000, pero su
funcionamiento y análisis puede extenderse a cualquier controlador CAN verificado por
Bosch.
2.3.3
Registros Controlador CAN
Este apartado es uno de los más extensos de la documentación, pero fue necesario su
realización para comprender el funcionamiento y manejar los registros de la entidad que
en definitiva permitirán testar y utilizar las entidades CAN.
Como se sabe, el controlador CAN presenta dos modos de funcionamiento, BasicCAN el
cual trabaja con tramas estándar y el modo PeliCAN que trabaja tanto con tramas
estándar como extendidas además de emplear muchos más registros y tener un número
mayor de funcionalidades.
Por tanto, el mapeo de los registros será diferente en función del modo seleccionado
(BasicCAN ó PeliCAN), aunque existen una serie de registros comunes. Dicho mapeo
también puede ser diferente en función de que la entidad se encuentre en modo reset o en
funcionamiento, incluso los significados pueden diferenciarse para los casos de escritura y
lectura.
Las principales características del CAN podrían describirse como:

Transmisión y recepción tanto de tramas estándar como extendidas (según el
modo).

Dar formato de trama a los mensajes.

Disponer de una FIFO de recepción

Filtro de aceptación con simple/dual filtrado con código de aceptación y máscara
de aceptación.

Registros para tramas estándar y extendidas

Contadores de error para accesos a escritura y lectura.

Alarma del límite de errores (“error warning limit”) programable

Registro de código del ultimo error (“Last error code register”)

Iterrupción de errores para cada error en el Bus Can
48
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Mediador de interrupciones de pérdidas (“Arbitration lost interrupt”) con
información detallada de la posición del bit.

Transmisión “Single-shot” (sin retransmisiones en casos de error o “arbitration
lost”)

Listen only mode (monitoring of the CAN-bus, noacknowledge, no error flags)

Apoyo de conexiones en caliente (“Hot plugging supported”, software para la
detección del “bit rate” sin perturbaciones).

Capacidad de deshabilitar el reloj de salida “CLKOUT” de forma hardware.
Para disponer de estas funcionalidades se pasarán a describir a continuación el
funcionamiento de cada uno de los modos de funcionamiento y sus registros asociados.
2.3.3.1
Modo BasicCAN
Los registros y su direccionamiento en el modo BasicCan consisten en la parte de control y
los buffers para los mensajes. La parte de control se suele programar durante la
inicialización con la idea de configurar los parámetros de la configuración (Por ejemplo,
uno de los parámetros que debe ser programado durante la inicialización es el reloj
CLKOUT que es programado en general por el microcontrolador).
En base a estos parámetros de configuración, la comunicación es controlada de forma
autónoma durante la comunicación. Un aspecto importante es que tras la inicialización, los
registros de código de aceptación, máscara de aceptación, bus timing 0, bus timing 1 y
control de salida, no deben ser modificados. Por lo que estos registros solo pueden ser
accesibles si el modo reset está activado.
Los mensajes que quieran ser enviados deben ser escritos al buffer de transmisión. Tras
una recepción correcta de dicho mensaje, el microcontrolador debe leer el mensaje recibido
del buffer de recepción y liberar a este para futuros usos.
El cambio de las señales de estado, control y comando entre el microcontrolador y el
controlador CAN, se realiza en el segmento de control. Las direcciones y contenidos de los
registros correspondientes se muestran un poco más adelante.
Para el acceso a los registros deben considerarse dos modos de funcionamiento.

Modo reset (“Reset mode”)

Modo de Operación (“Operating mode”)
El modo reset se alcanza tras la activación hardware de la señal reset o modificando el
registro de control, mientras que el modo de operación se consigue poniendo a nivel bajo
el bit de reset en el registro de control (el menos significativo).
El mapeo de memoria de los diferentes registros, diferenciando entre los distintos
segmentos y modo de funcionamiento pueden observarse en la Tabla :
49
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
50
Tabla 6: Direccionamiento BasicCAN
Dirección
CAN
Segmento
Modo de Operación
Modo Reset
Lectura
Escritura
Lectura
Escritura
control
control
control
control
1
(FFH)
command
(FFH)=0xFF
command
2
status
-
status
-
3
interupt
-
interupt
-
4
(FFH)
-
acceptance
code
acceptance
code
5
(FFH)
-
acceptance
mask
acceptance
0
control
mask
6
(FFH)
-
bus timing 0
bus timing 0
7
(FFH)
-
bus timing 1
bus timing 1
8
(FFH)
-
output control
output control
9
test
test
(FFH)
-
identifier (10
to 3)
identifier (10
to 3)
(FFH)
-
11
identifier
(2to 0), RTR
y DLC
identifier (2to
0), RTR y
DLC
(FFH)
-
12
data byte 1
data byte 1
(FFH)
-
13
data byte 2
data byte 2
(FFH)
-
14
data byte 3
data byte 3
(FFH)
-
15
data byte 4
data byte 4
(FFH)
-
16
data byte 5
data byte 5
(FFH)
-
17
data byte 6
data byte 6
(FFH)
-
18
data byte 7
data byte 7
(FFH)
-
19
data byte 8
data byte 8
(FFH)
-
identifier (10
to 3)
identifier (10
to 3)
identifier (10 to
3)
identifier (10
to 3)
identifier
(2to 0), RTR
identifier (2to
0), RTR y
identifier (2to
0), RTR y DLC
identifier (2to
0), RTR y
10
transmit
buffer
20
receive
buffer
21
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
51
y DLC
DLC
22
data byte 1
data byte 1
data byte 1
data byte 1
23
data byte 2
data byte 2
data byte 2
data byte 2
24
data byte 3
data byte 3
data byte 3
data byte 3
25
data byte 4
data byte 4
data byte 4
data byte 4
26
data byte 5
data byte 5
data byte 5
data byte 5
27
data byte 6
data byte 6
data byte 6
data byte 6
28
data byte 7
data byte 7
data byte 7
data byte 7
29
data byte 8
data byte 8
data byte 8
data byte 8
30
(FFH)
-
(FFH)
-
clock divider
clock divider
clock divider
clock divider
31
clock
divider
DLC
El direccionamiento de los registros se repite para direcciones CAN superiores ya que el
bit más significativo del bus de direcciones será ignorado. A continuación se pasará a
describir los diferentes registros de forma más exhaustiva por ser los registros
“principales” y más utilizados en la acción del controlador.
2.3.3.2
Registro de control “Control Register” (CR)
El contenido del registro de control es utilizado para cambiar el comportamiento del
controlador del bus CAN. Los bits se pueden establecer o restablecer por el
microprocesador o microcontrolador adjunto, que utiliza el registro de control como una
memoria de lectura / escritura. El mapeo a nivel de bits del registro de control o “Control
Register” CR se muestra a continuación en la ¡Error! No se encuentra el origen de la
referencia.Tabla 7.
Tabla 7: Registro de control BasicCan
Bit
Símbolo
Nombre
Valor
Función
CR.7
-
-
-
reserved; Any write access to the control
register has to set this bit to logic 0 (reset
value is logic 0).
CR.6
-
-
-
reserved;
CR.5
-
-
-
reserved; Reading this bit will always reflect
a logic 1.
CR.4
OIE
Overrun Interrupt
Enable
1
enabled; if the data overrun bit is set,
the microcontroller receives an
overrun interrupt signal (Ver “Status
Register”).
0
disabled; the microcontroller receives
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
no overrun interrupt signal.
CR.3
CR.2
CR.1
CR.0
EIE
TIE
RIE
RR
Error Interrupt Enable
Transmit Interrupt
Enable
Receive Interrupt
Enable
Reset Request;
1
enabled; if the error or bus status change,
the microcontroller receives an error interrupt
signal (Ver “Status Register”).
0
disabled; the microcontroller receives
no error interrupt signal.
1
enabled; when a message has been
successfully transmitted or the
transmit buffer is accessible again.
0
disabled; the CAN controller receives
no transmit interrupt signal.
1
enabled; when a message has been
received without errors.
0
disabled; the microcontroller receives
no transmit interrupt signal
1
present; detection of a reset request
results in aborting the current
transmission/reception of a message
and entering the reset mode
0
absent; on the ‘1-to-0’ transition of the
reset request bit. the microcontroller
returns to the operating mode
Durante un reset hardware o cuando el bit de estado se coloca a un 1 lógico (bus-off), el bit
de petición de reset se establece en 1 lógico (manteniéndose). Si se accede por software a
este bit, Un cambio en el valor se hace visible y toma efecto con el siguiente flanco positivo
del reloj interno que opera con 1/2 de la frecuencia del oscilador externo.
Durante un reset externo, el microcontrolador no puede establecer el valor de “reset
request” a 0, por lo que tras realizar la petición correspondiente de que se desactive el
reset, el microcontrolador debe asegurarse que no se está forzando el reset de forma
externa. Por último, cabe decir que después de establecer el bit correspondiente del
registro de control a cero, el microcontrolador debe esperar:

Una ocurrencia de la señal “bus-free” (11-bits recesivos) si el reset precedido ha sido
generado por un reset hardware o por un reset iniciado por la CPU.

128 ocurrencias de la señal “bus-free” si el precedido reset ha sido causado por el
controlador CAN en estado de “bus off” antes de reentrar en el modo “bus on”.
En el manejo del controlador CAN se dan numerosas ocasiones en las que se modifica el
valor del registro de control, sobre todo, para imponer la condición de reset.
2.3.3.3
Registro de comando “Command Register” (CMR)
El registro de comando aparece para el microcontrolador como un registro de solo
escritura (si se accede con un acceso de lectura se devuelve 0xFF). Escribir un bit en dicho
registro, inicia una acción en la capa de transferencia del controlador CAN. Entre dos
comandos diferentes es necesario al menos un ciclo del reloj interno.
52
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
El desglose del registro en bits y su significado se muestra en la Tabla 8:
Tabla 8: Registro de comando
Bit
Símbolo
Nombre
Valor
Función
CMR.7
-
-
-
reserved
CMR.6
-
-
-
reserved
CMR.5
-
-
-
reserved
CMR.4
GTS
Go to Sleep
1
sleep; the CAN controller enters sleep
mode if no CAN interrupt is pending
and there is no bus activity
0
wake up; CAN controller operates
normal
1
clear; data overrun status bit is
cleared
0
no action
1
released; the receive buffer,
representing the message memory
space in the RXFIFO is released
0
no action
1
present; if not already in progress, a
pending transmission request is
cancelled
0
absent; no action
1
present; a message will be
transmitted
0
absent; no action
CMR.3
CMR.2
CMR.1
CMR.0
CDO
RRB
AT
TR
Clear Data Overrun
Release Receive Buffer
Abort Transmission
Transmission Request
El controlador CAN entra en modo “sleep” si al bit de “sleep” se le asigna un valor 1 y no
existe actividad en el bus ni existen interrupciones pendientes. Ajustar el bit de Go to Sleep
(GTS), con al menos una de las circunstancias anteriormente mencionadas resulta en una
interrupción de “despertar” denominada “wake up”. Tras entrar en modo “sleep”, la señal
CLKOUT continúa al menos durante 15 tiempos de bit, para permitir el sincronismo del
microcontrolador entrar en su propio “stand by” antes de desconectar el reloj.
El controlador CAN despertará si algunas de las condiciones antes mencionadas no se
cumple tras el GTS. En el despertar comienza la interrupción “wake-up”, tras ello, será
necesario detectar once bits recesivos consecutivos (secuencia “bus free”) para ser capaz de
recibir los mensajes. Debe tenerse en cuenta que no es posible establecer GTS en el modo
reset y tras salir de él, es necesario esperar de nuevo la condición “bus free” para poder
habilitarlo.
El bit de “Clear Data Overrun”, se utiliza para borrar la condición de saturación de datos
indicado por el bit de estado correspondiente. Mientras este bit este activo, no se
53
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
producirán más interrupciones por saturación. Además es posible realizar esta acción en el
mismo instante que la liberación del bus de recepción.
El bit de “Release Receive Buffer”, permite liberar el contenido del buffer de recepción
después de leer su contenido. Esto resultará en la disponibilidad de inmediata del
siguiente mensaje en el buffer de recepción. Este evento, forzará otra interrupción de
recepción si está habilitada.
El bit de abortar transmisión, es usado cuando la CPU requiere la suspensión de la petición
de transmisión (“transmission request”) previa (por ejemplo para transmitir otro mensaje
más urgente). Las transmisiones en curso no se detienen. Para comprobar si una
transmisión se ha enviado o se ha abortado es necesario comprobar el bit “transmission
complete status bit”, lo que se hace tras la activación del “transmit buffer status bit” o de
una interrupción por transmisión.
El bit de “transmission request” se asigna a un uno lógico para solicitar una transmisión. Si
este bit se coloca a un uno lógico, la petición de transmisión no puede cancelarse
imponiendo un valor lógico de cero, sino que dicha cancelación debe hacerse mediante el
empleo de un “abort transmission”.
2.3.3.4
Registro de estado “Status Register” (SR).
El registro de estado refleja la información sobre el estado del controlador CAN. Este
registro se trata como de solo lectura desde el punto de vista del microcontrolador, y el
significado de los bits correspondientes al registro se muestra en la Tabla 9:
Tabla 9: Registro de estado
Bit
Símbolo
Nombre
Valor
Función
SR7
BS
Bus Status
1
bus-off; the Can controller is not
involved in bus activities
0
bus-on; the Can controller is involved
in bus activities
1
error; at least one of the error counters
has reached or exceeded the CPU
warning limit
0
ok; both error counters are below the
warning limit
1
transmit; the Can controller is
transmitting a message
0
idle; no transmit message is in
progress
1
receive; the Can controller is receiving
a message
0
idle; no receive message is in progress
1
complete; the last requested
transmission has been successfully
completed
0
incomplete; the previously requested
SR6
SR5
SR4
SR3
ES
TS
RS
TCS
Error Status
Transmit Status
Receive Status
Transmission
Complete
54
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
transmission is not yet completed
SR2
SR1
SR0
TBS
DOS
RBS
Transmit Buffer Status
Data Overrun Status
Receive Buffer Status
1
released; the CPU may write a
message into the transmit buffer
0
locked; the CPU cannot access the
transmit buffer; a message is waiting
for transmission or is already in
process
1
overrun; a message was lost because
there was not enough space for that
message in the RXFIFO
0
absent; no data overrun has occurred
since the last clear data overrun
command was given
1
full; one or more messages are
available in the RXFIFO
0
empty; no message is available
Cuando el contador de errores excede el límite de 255 errores, el bit del bus status se
establece a 1 (Bus-off). El controlador CAN colocara el bit “reset request” a 1, y comenzará
una interrupción de error si dicha interrupción está activada. El controlador se quedará en
este modo hasta que la CPU limpie el bit de reset. Una vez hecho esto, espera un tiempo
mínimo definido por el protocolo (128 ocurrencias de la “bus-free”), tras lo cual, el bit de
estado del bus se restablece (bus-on), el bit de error de estado se establece a 0 (ok), el
contador de errores se reinicializa y se genera una interrupción de error si está disponible.
Los errores detectados durante la transmisión o recepción de datos afectaran al contador
de errores de acuerdo al protocolo especificado para CAN 2.0B. El “Status Error Bit” se
coloca a 1 cuando al menos uno de los contadores de error ha excedido el límite de
advertencias (“Warning limit”), establecido por defecto a 96. Dado el caso, se genera una
interrupción de error si está habilitada.
Por otro lado, si tanto los bits lógicos del “transmit status” como del “receive status” se
encuentran a 0, significa que el Bus Can está inactivo.
El “transmission complete status bit” se establece a 0 (“incomplete”), siempre y cuando el
“transmission request bit” se establezca a uno. El “transmission complete status bit” se
mantiene a 0 hasta que el mensaje se ha transmitido satisfactoriamente.
Por otro lado, si la CPU trata de escribir en el buffer de transmisión, cuando el “transmit
buffer status bit se encuentra a 0 (“locked”), el byte escrito, no será aceptado y se perderá
sin ninguna indicación.
Cuando un mensaje que se va a recibir pasa el filtro de aceptación, el controlador CAN
necesita espacio en la FIFO de recepción para almacenar el descriptor del mensaje. Del
mismo modo, debe haber suficiente espacio para cada byte de datos que debe ser
recibidos. Si no existe suficiente espacio para almacenar el mensaje, este se elimina y se
indica la condición de desbordamiento o saturación de datos se indica a la CPU, solo si el
mensaje recibido no tiene errores, al menos, hasta el penúltimo bit antes del fin de trama.
Después de leer el mensaje almacenado en la FIFO y liberar el espacio de memoria, con el
comando de liberar el buffer de recepción, este bit se libera. Si existe otro mensaje
disponible en la FIFO, el bit se activa nuevamente.
55
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2.3.3.5
Registro de interrupciones “Interrupt Register” (IR).
El registro de interrupción permite la identificación de una fuente de interrupción. Cuando
se establecen uno o más bits de este registro, el pin INT se activa (a nivel bajo). Después de
que este registro sea leído por el microcontrolador, todos los bits se restablecen. El registro
de interrupción aparece para el microcontrolador como una memoria de solo lectura. El
significado de los bits correspondientes al registro se muestra en la Tabla 10:
Tabla 10: Registro de Interrupciones
Bit
Símbolo Nombre
Valor Función
IR7
-
-
-
reserverd
IR6
-
-
-
reserverd
IR5
-
-
-
reserverd
IR4
WUI
Wake-Up Interrupt
1
set; this bit is set when the sleep mode
is left
0
reset; this bit is cleared by any read
access of the microcontroller
Overrum 1
set; this bit is set on a ‘0-to-1’ transition
of the data overrun status bit, when
the data overrun interrupt enable is set
to logic 1 (enabled)
0
reset; this bit is cleared by any read
access of the microcontroller
1
set; this bit is set on a change of either
the error status or bus status bits if the
error interrupt enable is set to logic 1
(enabled)
0
reset; this bit is cleared by any read
access of the microcontroller
1
set; this bit is set whenever the
transmit buffer status changes from
logic 0 to logic 1 (released) and
transmit interrupt enable is set to logic
1 (enabled)
0
reset; this bit is cleared by any read
access of the microcontroller
1
set; this bit is set while the receive
FIFO is not empty and the receive
interrupt enable bit is set to logic 1
(enabled)
0
reset; this bit is cleared by any read
access of the microcontroller
IR3
IR2
IR1
IR0
DOI
EI
TI
RI
Data
interrupt
Error Interrupt
Transmit Interrupt
Receive Interrupt
56
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
57
Debe tenerse en cuenta que una interrupción “Wake-Up” también se genera si la CPU
trata de establecer “go to sleep” mientras el controlador CAN está envuelto en actividades
con el bus o bien, si existe una interrupción pendiente.
El bit “Data Overrum interrupt” (si está habilitado) y el de “Data Overrun Status”, se
establecen en el mismo momento.
El bit “receive interrupt” (Si está habilitado) y el “received buffer status” se establecen en el
mismo momento. Debe tenerse en cuenta, que el bit “receive interrupt” se libera tras un
acceso de lectura, incluso si existe otro mensaje disponible en la FIFO. En el momento en
que se realiza el “release receive buffer command”, y existe otro mensaje valido en el
buffer de recepción, el bit “receive interrupt”, se activa nuevamente.
2.3.3.6
Buffer de Transmisión “Transmission Buffer”
En la Tabla 11, se muestra la disposición del buffer de transmisión. La función del buffer es
almacenar los mensajes que el microcontrolador desea transmitir a través del controlador
CAN. Puede subdividirse en un campo de descripción (descriptor) y un campo de datos
(data). El buffer de transmisión, solo puede ser manipulado por el microcontrolador en el
modo de operación (“operating mode”), en el modo reset, siempre refleja el valor
hexadecimal 0xFF.
Tabla 11: Buffer de Transmisión
CAN
ADDRES
S
FIELD
10
Descripto
r
11
12
Data
NAME
BITS
7
6
5
4
3
2
1
0
Identifie
r byte 1
ID
10
ID
9
ID
8
ID7
ID6
ID5
ID4
ID3
Identifie
r byte 1
ID
2
ID
1
ID
0
RT
R
DLC.
3
DLC.
2
DLC.
1
DLC.
0
TX
Data1
transmit data byte 1
13
TX
Data2
Transmit data byte 2
14
TX
Data3
Transmit data byte 3
15
TX
Data4
Transmit data byte 4
16
TX
Data5
Transmit data byte 5
17
TX
Data6
Transmit data byte 6
18
TX
Data7
Transmit data byte 7
19
TX
Data8
Transmit data byte 8
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
El identificador consiste en 11 bits (ID10-ID0). ID10 es el bit más significativo siendo el
primero en ser transmitido por el bus en el proceso de arbitraje (arbitration process). El
identificador actúa como nombre del mensaje y es usado en el receptor para el filtrado de
aceptación y para determinar la prioridad del bus durante el proceso de arbitraje. Cuanto
más bajo sea el identificador más alto es su nivel de prioridad (debido al número de bits
dominantes durante el proceso de arbitraje).
La solicitud de transmisión remota o “Remote Transfer Request” (RTR), es un bit que
índica en caso de estar activo, una trama remota será transmitida a través del bus. Esto
significa que si RTR tiene un valor 1, no se incluyen datos en la trama enviada. No
obstante, es necesario especificar longitud de los datos de forma correcta, que se
corresponderá con el de la trama de datos con el mismo código identificador. Si el RTR no
está asignado (vale 0), la trama envía los datos con un tamaño especificado en el “Data
Length Code”.
El código de longitud de datos “Data Length Code” (DLC), indica el número de bytes del
campo de datos que serán transmitidos en el mensaje. En el comienzo de la transmisión de
una trama remota, el DLC no se considera si el RTR está a un valor lógico 1. Aun así el
campo de DLC debe ser introducido correctamente para prevenir errores en el bus (Si dos
controladores de CAN empiezan una transmisión con el mismo identificador
simultáneamente).
Por razones de compatibilidad, ningún código de longitud de datos mayor que 8 debe ser
utilizado. Si se selecciona un valor superior a 8, se transmiten los 8 bytes en la trama de
datos con el código de longitud de datos indicado en DLC.
En cuanto al campo de datos, el byte más significativo y el primero en ser transmitido es el
“transmit data byte 1”.
2.3.3.7
Buffer de Recepción “Receive Buffer”
La distribución del buffer de recepción es extremadamente similar a la del buffer de
transmisión descrito en la Tabla 11. El registro de recepción es la parte accesible de la FIFO
de recepción (RXFIFO), todos los campos (Identificador, RTR, DLC) tienen el mismo
significado y siguen la misma ditribución que en el buffer de transmisión salvo porque se
encuentran localizados entre las direcciones CAN 20 al 29.
En la ¡Error! No se encuentra el origen de la referencia., se ilustra el buffer de recepción
como la parte accesible de la RXFIFO, además, puede observarse como la FIFO es capaz de
almacenar en total un total de 64 bytes de mensaje en total, por lo que el número máximo
de mensajes que puede almacenar dependerá de la longitud individual de dichos
mensajes. Si no existiera sitio suficiente en la FIFO para almacenar un mensaje, el
controlador CAN generara una interrupción de saturación, tal como se explicó
previamente en el registro de interrupciones.
58
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
59
Figura 30: Buffer de Recepción Modo BasicCAN
2.3.3.8
Filtro de Aceptación “Acceptance Filter”.
Con la ayuda del filtro de aceptación, el controlador CAN, es capaz de dejar pasa los
mensajes recibidos en la RXFIFO, tan solo cuando el identificador del mensaje se incluye
entre aquellos que se han predefinido en los registros del filtro. Estos registros son el
registro del código de aceptación y el registro de máscara de aceptación
El registro de código de aceptación “Aceptance Code Register” (ACR), se encuentra en la
dirección Can 4 y se accede a él tanto en operaciones de lectura como de escritura, si el bit
de reset está activado. Este registro de ocho bits, cuya composición se observa en la Tabla
12.
Tabla 12: Registro de código de aceptación
BIT7
BIT6
BIT5
BIT4
BIT3
BIT2
BIT1
BIT0
AC.7
AC.6
AC.5
AC.4
AC.3
AC.2
AC.1
AC.0
Por su parte, el registro de mascara de aceptación, “Aceptance Mask Register” (AMR)
igualmente, puede accederse como registro de lectura o de escritura si el bit reset está
activado y su composición se observa en la Tabla 13.
Tabla 13: Registro de máscara de aceptación
BIT7
BIT6
BIT5
BIT4
BIT3
BIT2
BIT1
BIT0
AM.7
AM.6
AM.5
AM.4
AM.3
AM.2
AM.1
AM.0
Para que el mensaje recibido, pase el filtro de aceptación, los 8 bits más significativos
(ID10-ID3) del identificador de mensaje, deben coincidir con los bits del ACR (AC7-AC0)
en aquellas posiciones que se indique en el AMR, indicando en la relevancia con un valor
lógico 1 en los bits correspondientes.
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2.3.3.9
60
Otros Registros.
Los registros comunes a los modos BasicCAN y PeliCAN, serán explicados en una sección
posterior, tras presentar los registros de PeliCAN.
2.3.4
Modo PeliCan.
Al igual que se hizo previamente en el apartado Basic CAN, puede comenzarse realizando
una descripción la distribución de los diferentes registros que intervienen en este modo.
Cabe destacar nuevamente, la necesidad de distinguir entre el modo reset y el modo
operación, además de las acciones de lectura y escritura. La distribución puede observarse
en la Tabla 14.
Tabla 14: Distribución de direcciones en Pelican
CAN
ADDRES
S
OPERATING MODE
RESET MODE
READ
WRITE
READ
WRITE
0
mode
mode
mode
mode
1
0x00
command
0x00
command
2
status
-
status
-
3
interrupt
-
interrupt
-
4
interrupt enable
interrupt enable
interrupt
enable
interrupt
enable
5
reserved (0x00)
-
reserved
(0x00)
-
6
bus timing 0
-
bus timing
0
bus timing
0
7
bus timing 1
-
bus timing
1
bus timing
1
8
output control
-
output
control
output
control
9
test
test
test
test
10
reserved (0x00)
-
reserved
(0x00)
-
11
arbitration lost capture
-
arbitration
lost
capture
-
12
error code capture
-
error code
capture
-
13
error warning limit
-
error
warning
limit
error
warning
limit
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
61
14
RX error counter
-
RX error
counter
RX error
counter
15
TX error counter
-
TX error
counter
TX error
counter
16
RX frame
informatio
n SSF
(Standard
Frame
Format)
RX frame
inf
or
ma
tio
n
ES
F
(Ex
ten
de
d
Fra
me
For
ma
t)
TX frame
informatio
n SSF
(Standard
Frame
Format)
TX frame
informatio
n ESF
(Extended
Frame
Format)
Acceptanc
e code 0
Acceptanc
e code 0
17
RX
Identifier 1
RX
Identifier 1
TX
Identifier 1
TX
Identifier 1
Acceptanc
e code 1
Acceptanc
e code 1
18
RX
Identifier 2
RX
Identifier 2
TX
Identifier 2
TX
Identifier 2
Acceptanc
e code 2
Acceptanc
e code 2
19
RX data 1
RX
Identifier 3
TX data 1
TX
Identifier 3
Acceptanc
e code 3
Acceptanc
e code 3
20
RX data 2
RX
Identifier 4
TX data 2
TX
Identifier 4
Acceptanc
e mask 0
Acceptanc
e mask 0
21
RX data 3
RX data 1
TX data 3
TX data 1
Acceptanc
e mask 1
Acceptanc
e mask 1
22
RX data 4
RX data 2
TX data 4
TX data 2
Acceptanc
e mask 2
Acceptanc
e mask 2
23
RX data 5
RX data 3
TX data 5
TX data 3
Acceptanc
e mask 3
Acceptanc
e mask 3
24
RX data 6
RX data 4
TX data 6
TX data 4
reserved
(0x00)
-
25
RX data 7
RX data 5
TX data 7
TX data 5
reserved
(0x00)
-
26
RX data 8
RX data 6
TX data 8
TX data 6
reserved
(0x00)
-
27
(FIFO
RAM)
RX data 7
-
TX data 7
reserved
(0x00)
-
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
28
(FIFO
RAM)
RX data 8
29
RX message counter
30
RX buffer start address
31
clock divider
32
33
-
TX data 8
62
reserved
(0x00)
-
RX
message
counter
-
RX buffer
start
address
RX buffer
start
address
clock divider
clock
divider
clock
divider
Internal RAM address 0
(FIFO)
-
Internal
RAM
address 0
Internal
RAM
address 0
Internal RAM address 1
(FIFO)
-
Internal
RAM
address 1
Internal
RAM
address 1
95
Internal RAM address
63 (FIFO)
-
Internal
RAM
address 63
Internal
RAM
address 63
96
Internal RAM address
64 (TX Buffer)
-
Internal
RAM
address 64
Internal
RAM
address 64
108
Internal RAM address
76 (TX Buffer)
-
Internal
RAM
address 76
Internal
RAM
address 76
109
Internal RAM address
77 (free)
-
Internal
RAM
address 77
Internal
RAM
address 77
110
Internal RAM address
78 (free)
-
Internal
RAM
address 78
Internal
RAM
address 78
111
Internal RAM address
79 (free)
-
Internal
RAM
address 79
Internal
RAM
address 79
112
0x00
-
0x00
-
0x00
-
0x00
-
-
↓
↓
↓
127
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Del mismo modo que ocurría en BasicCAN, el direccionamiento de registros se repite para
direcciones más altas de CAN (Ya que no se tiene en cuenta el bit más significativo del byte
de direcciones, así que tras 127, la dirección CAN 128 es equivalente a 0 y así
sucesivamente).
A continuación, se procederá del mismo modo que en el modo basicCan, se pasará a
describir los diferentes registros de forma más exhaustiva por ser los registros
“principales” y más utilizados en la acción del controlador.
2.3.4.1
Registro de modo “Mode Register” (MOD)
El registro de modo se utiliza para variar el comportamiento del controlador CAN. Los bits
deben ser establecidos o eliminados por la CPU, que usa el registro de modo como una
memoria de lectura/escritura (Los bits reservados se leerán como 0 lógicos). El significado
de los bits del registro se muestra en Tabla 15.
Tabla 15: Registro de modo
Bit
Símbolo
Nombre
Valor
Función
MOD.7
-
-
-
-
MOD.6
-
-
-
-
MOD.5
-
-
-
-
MOD.4
SM
Sleep Mode
1
sleep; the CAN controller enters
sleep mode if no CAN interrupt is
pending and if there is no bus
activity
0
wake-up; the CAN controller wakes
up if sleeping
1
single; the single acceptance filter
option is enabled (one filter with the
length of 32 bit is active)
0
dual; the dual acceptance filter option
is enabled (two filters, each with the
length of 16 bit are active)
1
self test; in this mode a full node test
is possible without any other active
node on the bus using the self
reception request command; the
CAN controller will perform a
successful transmission, even if there
is no acknowledge received
0
normal; an acknowledge is required
for successful transmission
1
listen only; in this mode the CAN
controller would give no
acknowledge to the CAN-bus, even if
a message is received successfully;
the error counters are stopped at the
MOD.3
MOD.2
MOD.1
AFM
STM
LOM
Acceptance Filter
Mode
Self Test Mode
Listen Only Mode
63
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
current value
MOD.0
RM
Reset Mode
0
normal
1
reset; detection of a set reset mode bit
results in aborting the current
transmission/reception of a message
and entering the reset mode
0
normal; on the ‘1-to-0’ transition of
the reset mode bit, the CAN
controller returns to the operating
mode
El controlador CAN entra en modo “sleep” si al bit de “mode sleep” se le asigna un valor 1
y no existe actividad en el bus ni existen interrupciones pendientes. Ajustar el bit SM, con
al menos una de las circunstancias anteriormente mencionadas resulta en una interrupción
de “despertar” denominada “wake up”. Tras entrar en modo “sleep”, la señal CLKOUT
continúa al menos durante 15 tiempos de bit, para permitir el sincronismo del
microcontrolador entrar en su propio “stand by” antes de desconectar el reloj.
El controlador CAN despertará si algunas de las condiciones antes mencionadas no se
cumple tras el GTS. En el despertar comienza la interrupción “wake-up”, tras ello, será
necesario detectar once bits recesivos consecutivos (secuencia “bus free”) para ser capaz de
recibir los mensajes. Debe tenerse en cuenta que no es posible establecer GTS en el modo
reset y tras salir de él, es necesario esperar de nuevo la condición “bus free” para poder
habilitarlo.
A su vez, debe tenerse en cuenta que el proceso de escritura solo podrá hacerse en los bits
MOD.3 a MOD.1 si se ha establecido el modo reset. Si se activa el modo LOM, se fuerza al
controlador CAN ser pasivo a los errores. Tampoco es posible transmitir mensajes, el resto
de funciones, funcionarán como en el modo normal.
Durante un reset hardware o cuando el bit de estado se coloca a un 1 lógico (bus-off), el bit
de petición de reset se establece en 1 lógico (manteniéndose). Si se accede por software a
este bit, Un cambio en el valor se hace visible y toma efecto con el siguiente flanco positivo
del reloj interno que opera con 1/2 de la frecuencia del oscilador externo.
Durante un reset externo, el microcontrolador no puede establecer el valor de “reset
request” a 0, por lo que tras realizar la petición correspondiente de que se desactive el
reset, el microcontrolador debe asegurarse que no se está forzando el reset de forma
externa.
Por último, cabe decir que después de establecer el bit correspondiente del registro de
control a cero, el microcontrolador debe esperar:

Una ocurrencia de la señal “bus-free” (11-bits recesivos) si el reset precedido ha
sido generado por un reset hardware o por un reset iniciado por la CPU.

128 ocurrencias de la señal “bus-free” si el precedido reset ha sido causado por el
controlador CAN en estado de “bus off” antes de reentrar en el modo “bus on”.
2.3.4.2
Registro de comando “Command Register” (CMR)
El registro de comando aparece para el microcontrolador como un registro de solo
escritura (si se accede con un acceso de lectura se devuelve 0xFF). Escribir un bit en dicho
registro, inicia una acción en la capa de transferencia del controlador CAN. Entre dos
comandos diferentes es necesario al menos un ciclo del reloj interno.
64
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
El desglose del registro en bits y su significado se muestra en la Tabla 16.
Tabla 16: Registro de comando
Bit
Símbolo
Nombre
Valor
Función
CMR.7
-
-
-
reserved
CMR.6
-
-
-
reserved
CMR.5
-
-
-
reserved
CMR.4
SRR
Self Reception Request
1
present; a message shall be
transmitted and received
simultaneously
0
- (absent)
1
clear; data overrun status bit is
cleared
0
no action
1
released; the receive buffer,
representing the message memory
space in the RXFIFO is released
0
no action
1
present; if not already in progress, a
pending transmission request is
cancelled
0
absent; no action
1
present; a message will be
transmitted
0
absent; no action
CMR.3
CMR.2
CMR.1
CMR.0
CDO
RRB
AT
TR
Clear Data Overrun
Release Receive Buffer
Abort Transmission
Transmission Request
Nuevamente, muchos bits realizan la función equivalente a lo planteado en el modo
basicCAN.
Activando el bit “Self Reception Request”, un mensaje se transmite y recibe
simultaneamente si el filtro de aceptación permite pasar el correspondiente identificador.
Una interrupción de transmisión y recepción indicará la correcta auto recepción (ver
también “Self Test Mode” en el registro de modo).
Activar simultáneamente los bits CMR.0 y CMR.1 resulta en enviar el mensaje de
transmisión una única vez. No se realizarán retransmisiones en el caso de errores o
pérdidas por arbitraje (llamado “single shot transmission”). Establecer los bits CMR.4 y
CMR.1 simultáneamente, resulta en enviar el mensaje transmitido una única vez
utilizando “self reception”. Si se activan simultaneamente, CMR.0, CMR.1 y CMR.4, el
resultado será el mismo que para el caso de CMR.0 y CMR.1 simultaneos.
El bit de “Clear Data Overrun”, se utiliza para borrar la condición de saturación de datos
indicado por el bit de estado correspondiente. Mientras este bit este activo, no se
65
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
producirán más interrupciones por saturación. Además es posible realizar esta acción en el
mismo instante que la liberación del bus de recepción.
El bit de “Release Receive Buffer”, permite liberar el contenido del buffer de recepción
después de leer su contenido. Esto resultará en la disponibilidad de inmediata del
siguiente mensaje en el buffer de recepción. Este evento, forzará otra interrupción de
recepción si está habilitada.
El bit de abortar transmisión, es usado cuando la CPU requiere la suspensión de la petición
de transmisión (“transmission request”) previa (por ejemplo para transmitir otro mensaje
más urgente). Las transmisiones en curso no se detienen. Para comprobar si una
transmisión se ha enviado o se ha abortado es necesario comprobar el bit “transmission
complete status bit”, lo que se hace tras la activación del “transmit buffer status bit” o de
una interrupción por transmisión.
El bit de “transmission request” se asigna a un uno lógico para solicitar una transmisión. Si
este bit se coloca a un uno lógico, la petición de transmisión no puede cancelarse
imponiendo un valor lógico de cero, sino que dicha cancelación debe hacerse mediante el
empleo de un “abort transmission”.
2.3.4.3
Registro de estado “Status Register” (SR)
El registro de estado refleja la información sobre el estado del controlador CAN. Este
registro se trata como de solo lectura desde el punto de vista del microcontrolador, y el
significado de los bits correspondientes al registro se muestra en la Tabla 17.
Tabla 17: Registro de estado
Bit
Símbolo
Nombre
Valor
Función
SR7
BS
Bus Status
1
bus-off; the Can controller is not involved in
bus activities
0
bus-on; the Can controller is involved in bus
activities
1
error; at least one of the error counters has
reached or exceeded the CPU warning limit
0
ok; both error counters are below the warning
limit
1
transmit; the Can controller is transmitting a
message
0
idle; no transmit message is in progress
1
receive; the Can controller is receiving a
message
0
idle; no receive message is in progress
1
complete; the last requested transmission has
been successfully completed
0
incomplete; the previously requested
transmission is not yet completed
1
released; the CPU may write a message into
SR6
SR5
SR4
SR3
SR2
ES
TS
RS
TCS
TBS
Error Status
Transmit Status
Receive Status
Transmission
Complete
Transmit Buffer
66
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Status
SR1
SR0
DOS
RBS
Data Overrun
Status
Receive Buffer
Status
the transmit buffer
0
locked; the CPU cannot access the transmit
buffer; a message is waiting for transmission
or is already in process
1
overrun; a message was lost because there was
not enough space for that message in the
RXFIFO
0
absent; no data overrun has occurred since the
last clear data overrun command was given
1
full; one or more messages are available in the
RXFIFO
0
empty; no message is available
Cuando el contador de errores excede el límite de 255 errores, el bit del bus status se
establece a 1 (Bus-off). El controlador CAN colocara el bit “reset request” a 1, y comenzará
una interrupción de error si dicha interrupción está activada. El controlador se quedará en
este modo hasta que la CPU limpie el bit de reset. Una vez hecho esto, espera un tiempo
mínimo definido por el protocolo (128 ocurrencias de la “bus-free”), tras lo cual, el bit de
estado del bus se restablece (bus-on), el bit de error de estado se establece a 0 (ok), el
contador de errores se reinicializa y se genera una interrupción de error si está disponible.
Los errores detectados durante la transmisión o recepción de datos afectaran al contador
de errores de acuerdo al protocolo especificado para CAN 2.0B. El “Status Error Bit” se
coloca a 1 cuando al menos uno de los contadores de error ha excedido el límite de
advertencias (“Warning limit”) que viene dado por el registro de límite de advertencias de
error, “Error Warning Limit Register” (EWLR) establecido por defecto a 96. Dado el caso,
se genera una interrupción de error si está habilitada.
Por otro lado, si tanto los bits lógicos del “transmit status” como del “receive status” se
encuentran a 0, significa que el Bus Can está inactivo.
El “transmission complete status bit” se establece a 0 (“incomplete”), siempre y cuando el
“transmission request bit” se establezca a uno. El “transmission complete status bit” se
mantiene a 0 hasta que el mensaje se ha transmitido satisfactoriamente.
Por otro lado, si la CPU trata de escribir en el buffer de transmisión, cuando el “transmit
buffer status bit se encuentra a 0 (“locked”), el byte escrito, no será aceptado y se perderá
sin ninguna indicación.
Cuando un mensaje que se va a recibir pasa el filtro de aceptación, el controlador CAN
necesita espacio en la FIFO de recepción para almacenar el descriptor del mensaje. Del
mismo modo, debe haber suficiente espacio para cada byte de datos que debe ser
recibidos. Si no existe suficiente espacio para almacenar el mensaje, este se elimina y se
indica la condición de desbordamiento o saturación de datos se indica a la CPU, solo si el
mensaje recibido no tiene errores, al menos, hasta el penúltimo bit antes del fin de trama.
Después de leer el mensaje almacenado en la FIFO y liberar el espacio de memoria, con el
comando de liberar el buffer de recepción, este bit se libera. Si existe otro mensaje
disponible en la FIFO, el bit se activa nuevamente.
2.3.4.4
Registro de interrupciones “Interrupt Register” (IR).
El registro de interrupción permite la identificación de una fuente de interrupción. Cuando
se establecen uno o más bits de este registro, se indican las interrupciones a la CPU. El
contenido de los bits, se muestra en la Tabla 18.
67
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Tabla 18: Registro de Interrupciones
Bit
Símbolo
Nombre
Valor
Función
IR7
BEI
Bus Error
Interrupt
1
set; this bit is set when the CAN controller
detects an error on the CAN-bus and the BEIE bit
is set within the interrupt enable register
0
reset
1
set; this bit is set when the CAN controller lost
the arbitration and becomes a receiver and the
ALIE bit is set within the interrupt enable register
0
reset
1
set; this bit is set whenever the CAN controller
has reached the error passive status (at least one
error counter exceeds the protocol-defined level
of
IR6
IR5
ALI
EPI
Arbitration
Lost Interrupt
Error Passive
Interrupt
127) or if the CAN controller is in the error
passive status and enters the error active status
again and the EPIE bit is set within the interrupt
enable register
IR4
IR3
IR2
IR1
IR0
WUI
DOI
EI
TI
RI
Wake-Up
Interrupt
Data Overrum
interrupt
Error
Interrupt
Transmit
Interrupt
Receive
0
reset
1
set; this bit is set when the sleep mode is left
0
reset; this bit is cleared by any read access of the
microcontroller
1
set; this bit is set on a ‘0-to-1’ transition of the
data overrun status bit, when the data overrun
interrupt enable is set to logic 1 (enabled)
0
reset; this bit is cleared by any read access of the
microcontroller
1
set; this bit is set on a change of either the error
status or bus status bits if the error interrupt
enable is set to logic 1 (enabled)
0
reset; this bit is cleared by any read access of the
microcontroller
1
set; this bit is set whenever the transmit buffer
status changes from logic 0 to logic 1 (released)
and transmit interrupt enable is set to logic 1
(enabled)
0
reset; this bit is cleared by any read access of the
microcontroller
1
set; this bit is set while the receive FIFO is not
empty and the receive interrupt enable bit is set
68
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Interrupt
to logic 1 (enabled)
0
reset; this bit is cleared by any read access of the
microcontroller
Debe tenerse en cuenta que una interrupción “Wake-Up” también se genera si la CPU
trata de establecer “go to sleep” mientras el controlador CAN está envuelto en actividades
con el bus o bien, si existe una interrupción pendiente.
El comportamiento del bit RI, es equivalente al de el “receive buffer status” con la
excepción de que RI depende de que el correspondiente bit habilitador de interrupciones
esté activado. Así que el bit de interrupción no se libera hasta que se realiza un acceso a
lectura sobre el bit de interrupciones. Realizar el comando, “release receive buffer” liberara
RI temporalmente. Si existe otro mensaje disponible en la FIFO RI se activa nuevamente,
contrariamente RI quedaría libre (a 0).
2.3.4.5
Registro de habilitación de interrupciones “Interrupt Enable Register” (IER)
Este registro activa o desactiva las diferentes fuentes de interrupción que están indicadas
por la CPU. El significado de sus bits se muestra en la Tabla 19.
Tabla 19: Registro de habilitación de Interrupciones
Bit
Símbolo
Nombre
Valor
Función
IER7
BEI
Bus Error Interrupt
Enable
1
enabled; if an bus error has been
detected, the CAN controller requests
the respective interrupt
0
disabled
1
enabled; if the CAN controller has lost
arbitration, the respective interrupt is
requested
0
disabled
1
enabled; if the error status of the CAN
controller changes from error active to
error passive or vice versa, the
respective interrupt is requested
0
disabled
1
enabled; if the sleeping CAN
controller wakes up, the respective
interrupt is requested
0
disabled
1
enabled; if the data overrun status bit
is set (see status register; Table 14), the
CAN controller requests the respective
interrupt
0
disabled
IER6
IER5
IER4
IER3
ALIE
EPIE
WUIE
DOIE
Arbitration Lost
Interrupt Enable
Error Passive Interrupt
Enable
Wake-Up Interrupt
Enable
Data Overrum
interrupt Enable
69
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
IER2
IER1
IER0
2.3.4.6
EIE
TIE
RIE
Error Interrupt Enable
Transmit Interrupt
Enable
Receive Interrupt
Enable
1
enabled; if the error or bus status
change (see status register; Table 14),
the CAN controller requests the
respective interrupt
0
disabled
1
enabled; when a message has been
successfully transmitted or the
transmit buffer is accessible again (e.g.
after an abort transmission command),
the CAN controller requests the
respective interrupt
0
disabled
1
enabled; when the receive buffer
status is ‘full’ the CAN controller
requests the respective interrupt
0
disabled
Registro de captura de pérdidas por arbitraje “Arbitration Lost Capture Register” (ALC)
Este registro contiene la información sobre la posición de las perdidas por arbitraje y
aparece al microporcesador como un registro de solo lectura. Su estructura de bits es la
mostrada en la Tabla 20.
Tabla 20: Registro de captura de pérdidas por arbitraje
Bit
Símbolo
Nombre
ACL7
-
reserved
ACL6
-
reserved
ACL5
-
reserved
ACL4 BITNO4
Bit number 4
ACL3 BITNO3
Bit number 3
ACL2 BITNO2
Bit number 2
ACL1 BITNO1
Bit number 1
ACL0 BITNO0
Bit number 0
Valor
Función
Ver Tabla 21.
En una perdida por arbitraje, se fuerza la correspondiente interrupción, si está habilitada.
Al mismo tiempo, la posición de bit actual de la cadena de bits se captura en el registro. El
contenido del registro se fija hasta que se realiza la lectura de su contenido nuevamente. En
ese momento, el mecanismo de captura queda activado de nuevo.
70
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
La correspondiente bandera de interrupción localizada en el registro de interrupción se
libra durante el acceso de lectura a dicho registro. Una nueva interrupción de pérdida por
arbitraje no es posible hasta que el registro de captura de pérdidas por arbitraje está listo.
A continuación se muestra un ejemplo de dichas pérdidas:
Figura 31: Ejemplo de Pérdidas de Arbitraje
La función del registro de captura del “Arbitration Lost Capture Register” se muestra en la
Tabla 21.
Tabla 21: Función del registro de captura del “Arbitration Lost Capture Register”
BITS
VALOR
DECIMAL
FUNCIÓN
ALC.4 ALC.3 ALC.2 ALC.1 ALC.0
0
0
0
0
0
00
arbitration lost in bit 1 of
identifier
0
0
0
0
1
01
arbitration lost in bit 2 of
identifier
0
0
0
1
0
02
arbitration lost in bit 3 of
identifier
0
0
0
1
1
03
arbitration lost in bit 4 of
identifier
0
0
1
0
0
04
arbitration lost in bit 5 of
identifier
0
0
1
0
1
05
arbitration lost in bit 6 of
identifier
71
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
0
0
1
1
0
06
arbitration lost in bit 7 of
identifier
0
0
1
1
1
07
arbitration lost in bit 8 of
identifier
0
1
0
0
0
08
arbitration lost in bit 9 of
identifier
0
1
0
0
1
09
arbitration lost in bit 10 of
identifier
0
1
0
1
0
10
arbitration lost in bit 11 of
identifier
0
1
0
1
1
11
arbitration lost in bit SRTR
0
1
1
0
0
12
arbitration lost in bit IDE
0
1
1
0
1
13
arbitration lost in bit 12 of
identifier
0
1
1
1
0
14
arbitration lost in bit 13 of
identifier
0
1
1
1
1
15
arbitration lost in bit 14 of
identifier
1
0
0
0
0
16
arbitration lost in bit 15 of
identifier
1
0
0
0
1
17
arbitration lost in bit 16 of
identifier
1
0
0
1
0
18
arbitration lost in bit 17 of
identifier
1
0
0
1
1
19
arbitration lost in bit 18 of
identifier
1
0
1
0
0
20
arbitration lost in bit 19 of
identifier
1
0
1
0
1
21
arbitration lost in bit 20 of
identifier
1
0
1
1
0
22
arbitration lost in bit 21 of
identifier
1
0
1
1
1
23
arbitration lost in bit 22 of
identifier
1
1
0
0
0
24
arbitration lost in bit 23 of
identifier
1
1
0
0
1
25
arbitration lost in bit 24 of
72
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
identifier
1
1
0
1
0
26
arbitration lost in bit 25 of
identifier
1
1
0
1
1
27
arbitration lost in bit 26 of
identifier
1
1
1
0
0
28
arbitration lost in bit 27 of
identifier
1
1
1
0
1
29
arbitration lost in bit 28 of
identifier
1
1
1
1
0
30
arbitration lost in bit 29 of
identifier
1
1
1
1
1
31
arbitration lost in bit RTR
2.3.4.7
Registro de captura del código de error “Error Code Capture Register” (ECC)
Este registro contiene la información sobre el tipo y la localización de los errores en el bus.
Su estructura de bits es la mostrada en la Tabla 22.
Tabla 22: Registro de captura de pérdidas por arbitraje
Bit
Símbolo
Nombre
ECC.7
ERRC1
Error Code 1
ECC.6
ERRC0
Error Code 0
ECC.5
DIR
Direction
ECC.4
SEG4
Segment 4
ECC.3
SEG3
Segment 3
ECC.2
SEG2
Segment 2
ECC.1
SEG1
Segment 1
ECC.0
SEG0
Segment 0
Valor
Función
Ver Tabla 23.
1
RX; error occurred
during reception
0
TX; error occurred
during transmission
Ver Tabla 24.
73
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
La interpretación de los bits ECC.7 y ECC.6 ver la Tabla 23.
Tabla 23: Interpretación de los bits ECC.7 y ECC.6
BIT ECC.7
BIT ECC.6
Función
0
0
bit error
0
1
form error
1
0
stuff error
1
1
other type of error
A su vez, la interpretación de los bits ECC.4 a ECC.0 se muestra en la Tabla 24.
Tabla 24: Diferentes bits que se muestran en el ECC para identificar los distintos tipos de
error
BITS
FUNCIÓN
ECC.4 ECC.3 ECC.2 ECC.1 ECC.0
0
0
0
1
1
start of frame
0
0
0
1
0
ID.28 to ID.21
0
0
1
1
0
ID.20 to ID.18
0
0
1
0
0
bit SRTR
0
0
1
0
1
bit IDE
0
0
1
1
1
ID.17 to ID.13
0
1
1
1
1
ID.12 to ID.5
0
1
1
1
0
ID.4 to ID.0
0
1
1
0
0
bit RTR
0
1
1
0
1
reserved bit 1
0
1
0
0
1
reserved bit 0
0
1
0
1
1
data length code
0
1
0
1
0
data field
0
1
0
0
0
CRC sequence
1
1
0
0
0
CRC delimiter
1
1
0
0
1
acknowledge slot
1
1
0
1
1
acknowledge delimiter
74
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
1
1
0
1
0
end of frame
1
0
0
1
0
intermission
1
0
0
0
1
active error flag
1
0
1
1
0
passive error flag
1
0
0
1
1
tolerate dominant bits
1
0
1
1
1
error delimiter
1
1
1
0
0
overload flag
Si ocurre un error de bus, la interrupción de error correspondiente siempre se fuerza (si
está habilitada). Al mismo tiempo, la posición actual de la cadena de bits se captura en el
registro de código de captura de error. El contenido de dicho registro se mantiene fijo hasta
que su contenido sea leído de nuevo.
La correspondiente bandera de interrupción que se encuentra en el registro de
interrupciones se libera cuando se realice un acceso de lectura en dicho registro. Una
nueva interrupción de errores no es posible hasta que el registro de captura de códigos de
error se lea una vez.
2.3.4.8
Registro límite de advertencias de error “Error Warning Limit Register” (EWLR)
Este registro de 8 bits índica el número límite de advertencias de error. Tras un reset
hardware se establece a 96. En modo reset es accesible tanto para lectura como para
escritura. En modo operación solo es accesible para operaciones lectura.
Como el valor de este registro solo puede ser escrito durante un reset, un “error status
change” y un “warning interrupt”, solo puede ser forzada por este registro cuando se
vuelva a salir del modo reset.
2.3.4.9
Registro contador de errores en recepción “RX Error Counter Register” (RXERR)
Este registro de 8 bits índica el del número de errores producidos en la recepción. Tras un
reset se situa a un valor lógico de 0. En el modo operación aparece como un registro de
solo lectura y solo puede escribirse en modo reset.
Si ocurre un “bus-error” el RXERR se inicializa a 0, pero no tendrá relevancia escribir en el
RXERR. Obsérvese que como RXERR, solo puede ser establecido en el modo reset, un
“error status change”, un “error warning” o un “error passive interrupt forced” solo se
producirá para un nuevo valor del RXERR hasta que se salga del modo reset.
2.3.4.10 Registro contador de errores en Transmisión “TX Error Counter Register” (RXERR)
Este registro de 8 bits índica el del número de errores producidos en la transmisión. Tras
un reset se sitúa a un valor lógico de 0. En el modo operación aparece como un registro de
solo lectura y solo puede escribirse en modo reset.
Si ocurre un “bus-error” el TXERR se inicializa a 127 (para esperar el tiempo
mínimodefinido por el protocolo, esto es 128 ocurrencias de “bus-free.
Si se da la condición de “bus-off”, un acceso de escritura en el rango 0-254, libera la
bandera de “bus-off”, y el controlador esperará la ocurrencia de 11 bits recesivos (“busfree”), tras que el modo reset sea cancelado.
Escribir un valor de 255 en el TXERR permite inicializar un evento de “bus-off”. Debe
notarse que un cambio forzado por la CPU en el registro RXERR solo puede realizarse en
75
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
modo reset, por lo que si se ha entrado previamente en modo reset, Un “bus error”, “bus
status chang”, “error warning” o “error passive interrupt”, que ocurriese por un nuevo
valor en el registro TXERR, será ignorado hasta que no se abandone el modo reset.
Tras salir del modo reset,el Nuevo contador del TX se interpreta y se realiza un evento de
“bus-off”, como si hubiese ocurrido un evento de “error-bus”. Esto significa que se entra
de nuevo en modo reset, el contador de TX se inicializa a 127, el contador de RX se libera y
se restablecen todos los bits concernientes a los registros de estado e interrupción. Cuando
se abandone el modo reset, se realizara la secuencia de recuperación definida por el
protocolo (esperar 128 ocurrencias de la señal “bus-free”). Si se entra de nuevo en modo
reset antes de que el bus termine su secuencia de recuperación, el estado de “bus off” se
mantendría y el contador de TXERR quedaría congelado (Sería necesario acceder en modo
reset a TXERR y escribir un valor entere 0-254 para salir).
2.3.4.11 Buffer de transmisión “Transmit Buffer”
La distribución global del buffer de transmisión puede observarse en laFigura 32. Como se
ha comentado en el modo PeliCan, debe distinguirse entre el uso de tramas estándar y el
uso de tramas extendidas, por tanto, existirán dos formatos, el formato de trama estándar
SFF y el formato de trama extendida o EFF. El buffer de transmisión permite transmitir
mensajes con más de ocho bytes en el campo de datos.
Figura 32: Distribución General del Buffer de Transmisión
La distribución del buffer de transmisión se subdivide en un campo de descripción
(descriptor), y un campo de datos. El primer byte del campo de descripción es el “frame
informatión byte”, que describe el formato de trama (SFF o EFF), si es una trama de datos o
remota, y la longitud de los datos. A continuación se dispone de dos bytes para el
identificador en tramas estándar y cuatro para las tramas extendidas. El campo de datos
puede contener más de ocho bytes de datos. El buffer de transmisión tiene una longitud de
13 bytes y se encuentra localizado en las direcciones CAN del 16 al 28.
El campo de descripción para el caso de tramas estándar se expone en detalle en la Tabla
25.
76
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
77
Tabla 25: Campo de descripción para SFF
Dirección
CAN
BIT 7
BIT 6
BIT 5
BIT 4
BIT 3
BIT 2
BIT 1
BIT 0
16
FF
RTR
X
X
DLC.3
DLC.2 DLC.1 DLC.0
17
ID.28
ID.27
ID.26
ID.25
ID.24
ID.23
ID.22
ID.21
18
ID.20
ID.19
ID.18
X
X
X
X
X
Dónde FF se refiere al bit “Frame Format”, RTR a “Remote Transfer Request”, DLC a
“Data Length Code”, ID a “Identifier” y X puede ser cualquier valor arbitrario, aunque se
recomienda que sea compatible con los valores del buffer de recepción para las pruebas de
“Self-Reception”.
En el caso de tratarse de tramas extendidas, la descripción de los datos es similar y puede
apreciarse en la Tabla 26.
Tabla 26: Campo de descripción para EFF
Dirección
CAN
BIT 7
BIT 6
BIT 5
BIT 4
BIT 3
BIT 2
BIT 1
BIT 0
16
FF
RTR
X
X
DLC.3
DLC.2 DLC.1 DLC.0
17
ID.28
ID.27
ID.26
ID.25
ID.24
ID.23
ID.22
ID.21
18
ID.20
ID.19
ID.18
ID.17
ID.16
ID.15
ID.14
ID.13
19
ID.12
ID.11
ID.10
ID.9
ID.8
ID.7
ID.6
ID.5
20
ID.4
ID.3
ID.2
ID.1
ID.0
X
X
X
Teniendo los bits significados idénticos al caso anterior.
Por su parte, el significado conjunto de los bits FF y RTR puede resumirse en la Tabla 27.
Tabla 27: Interpretación de los bits FF y RTR
BIT
VALUE
FUNCTION
FF
1
EFF; extended frame format
will be transmitted by the
CAN controller
0
SFF; standard frame format
will be transmitted by the
CAN controller
1
remote; remote frame will
be transmitted by the CAN
controller
0
data; data frame will be
transmitted by the CAN
RTR
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
78
controller
Las consideraciones realizadas sobre los identificadores y el campo de longitud de datos,
son análogas a las del modo Basic CAN (Con la diferencia de que se trabaja con
identificadores más largos para tramas extendidas).
En cuanto al campo de datos, simplemente decir que como pasaba en el modo BasicCan, se
enviarán tantos datos como se indique en el DLC y que el primer bit trasnmitido
corresponde al bit más significativo.
2.3.4.12 Buffer de recepción “Receive Buffer”
La distribución global del buffer de recepción es similar al del buffer de transmisión,
descrita en la sección previa. El buffer de recepción puede interpretarse como la parte
visible de la FIFO de recepción (RXFIFO) y se encuentra accesible en las direcciones CAN
de la 16 a la 28. Cada mensaje se divide en el campo de descripción y el campo de datos.
La ¡Error! No se encuentra el origen de la referencia., ilustra el funcionamiento de la
RXFIFO para el caso del modo PeliCan.
El contenido de los registros (muy similares a los del buffer de transmisión), para las
tramas estándar se muestra en la Tabla 28.
Tabla 28: Campo de descripción para SFF en RX Buffer
Dirección
CAN
BIT 7
BIT 6
BIT 5
BIT 4
BIT 3
BIT 2
BIT 1
BIT 0
16
FF
RTR
0
0
DLC.3
DLC.2 DLC.1 DLC.0
17
ID.28
ID.27
ID.26
ID.25
ID.24
ID.23
ID.22
ID.21
18
ID.20
ID.19
ID.18
0
0
0
0
0
Mientras que en el caso del uso de tramas extendidas, resulta en lo que se puede apreciar
en la Tabla 29.
Tabla 29: Campo de descripción para EFF para el RX Buffer
Dirección
CAN
BIT 7
BIT 6
BIT 5
BIT 4
BIT 3
BIT 2
BIT 1
BIT 0
16
FF
RTR
0
0
DLC.3
DLC.2 DLC.1 DLC.0
17
ID.28
ID.27
ID.26
ID.25
ID.24
ID.23
ID.22
ID.21
18
ID.20
ID.19
ID.18
ID.17
ID.16
ID.15
ID.14
ID.13
19
ID.12
ID.11
ID.10
ID.9
ID.8
ID.7
ID.6
ID.5
20
ID.4
ID.3
ID.2
ID.1
ID.0
RTR
0
0
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Donde el significado de los bits es el mismo que para el caso del buffer de transmisión.
Figura 33: Buffer de Recepción para el modo PeliCAN
Hay que remarcar que el campo de longitud de datos en la información de la trama,
representa el tamaño real de los datos enviados, que puede ser mayor de 8 bytes (depende
del transmisor). En cualquier caso, el tamaño máximo del buffer de recepción es 8 bytes,
esto debe tenerse en cuenta a la hora de leer un mensaje recibido en el buffer, como se
aprecia en la Figura 33, el tamaño de la RXFIFO es de 64 Bytes, si la FIFO se desborda, el
controlador CAN comenzará una interrupción de saturación (si está habilitada).
2.3.4.13 Filtro de aceptación “Acceptance filter”
La función es análoga a la del caso BasicCan. Su función es permitir el paso o no de los
mensajes recibidos en la FIFO en función del identificador de dichos mensajes.
Del mismo modo que ocurría anteriormente, el filtro de aceptación estará a su vez
compuesto de un código de aceptación y de una máscara de aceptación. La diferencia con
el modo BasicCAN, son por un lado, que ahora los identificadores de los mensajes son más
largos, y por otro que el filtro de aceptación dispone de dos modos de funcionamiento, el
modo “single filter mode” (bit AFM a 1) y el “dual Filter mode” (bit AFM a 0).
En la configuración “single filter mode” se utiliza una longitud del filtro de 4 bytes. En este
modo, para tramas estándar, el identificador completo, incluyendo el bit RTR y los
primeros bytes de datos, se utilizan para el filtrado (Aunque es posible que no existan
datos en los bytes de datos si RTR vale 1). Para que pueda realizarse la recepción del
mensaje, es necesario que se apliquen los registros de ACRn y AMRn de la forma indicada
en la Figura 34, puede observarse como los 4 bits menos significativos de AMR1 y ACR1,
no son utilizados.
79
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 34: Filtro de Aceptación PeliCAN. Modo Simple y Tramas Estándar
En el caso del empleo de tramas extendidas, se realiza el filtrado comparando todos los
bits (excepto AMR 3.1 y AMR 3.0), tal como se muestra en la Figura 35.
Figura 35: Filtro de Aceptación PeliCAN. Modo Simple y Trama Extendida
En el caso del funcionamiento dual, se definen dos filtros más cortos, el mensaje recibido se
compara con ambos filtros, y se decide si el mensaje debe pasar al buffer de recepción, caso
que se dará si el mensaje supera alguno de los filtros. Nuevamente se distinguen dos
comportamientos en función del formato de trama.
Para el caso de tramas estándar, el funcionamiento se muestra en la Figura 36. El primer
filtro compara el identificador completo, incluido el RTR y el primer byte de datos,
80
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
mientras que el segundo solo compara el identificador y el RTR.
Para el caso de las tramas extendidas, ambos filtros funcionan de manera idéntica, tal
como se muestra en la Figura 37. Ambos filtros comparan por tanto tan solo los dos bytes
más significativos del identificador. Nuevamente, basta con cumplir las condiciones de al
menos uno de los filtros para que el mensaje pase el filtro de aceptación.
Figura 36: Filtro de Aceptación PeliCAN. Modo Dual y Tramas Estándar
81
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 37: Filtro de Aceptación PeliCAN. Modo Dual y Tramas Extendidas
82
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
83
2.3.4.14 Registro contador de mensajes en el receptor “RX Message Counter” (RMC).
Este registro, indica el número de mensajes disponibles en la RXFIFO, su valor se
incrementa con cada evento de recepción y disminuye con cada acción de liberar el buffer
de recepción. Tras cualquier condición en la que se dé un reset, el valor del registro es
reinicializado.
2.3.4.15 Registro dirección de comienzo del buffer de recepción “RX Buffer Start Address
Register” (RBSA)
Este registro refleja la actual dirección interna válida de la RAM, donde el primer byte del
mensaje recibido, el cual es almacenado en el buffer de recepción, se encuentra
almacenado. Gracias a esta información es posible interpretar el contenido interno de la
RAM. El área interna de la RAM comienza en la dirección 32, y puede ser accedida por la
CPU tanto en modo lectura como escritura (escritura solo en reset).
2.3.5
Registros comunes
A continuación se describirán los registros comunes que aparecen en el mapa de
direcciones tanto del modo BasicCAN como de PeliCAN.En general estos registros
permiten configurar algunos aspectos del controlador CAN.
2.3.5.1
Registro de tiempo de bus 0 “Bus Timming Register 0” (BTR0)
El contenido de este registro define el valor del “Baud Rate Prescaler” (BRP), y el
“Synchronization Jump Width” (SJW). Este registro está accesible en modo lectura y
escritura en modo reset. La interpretación de los bits es la mostrada en la Tabla 30.
Tabla 30: Bus Timming Register 0
BIT.7
BIT.6
BIT.5
BIT.4
BIT.3
BIT.2
BIT.1
BIT.0
SJW.1
SJW.0
BRP.5
BRP.4
BRP.3
BRP.2
BRP.1
BRP.0
En cuanto al BRP, determina el periodo de reloj del sistema CAN
tiempo de bit y se calcula como:
Donde
, el cual determina el
es el periodo del oscilador externo.
Por otro lado, para compensar la desviación de fase entre los osciladores, el controlador del
bus debe re-sincronizar sus flancos de reloj. El valor de SJW, determina el número de ciclos
de reloj de un periodo de bits que puede ser acortado o alargado en una re-sincronización.
2.3.5.2
Registro de tiempo de bus 1 “Bus Timming Register 1” (BTR1)
Este registro es el encargado de definir la longitud el periodo de bit, la localización del
punto de muestreo y el número de muestras tomadas en cada punto. El registro está
accesible para lectura o escritura en el modo reset. En PeliCan, en el modo operación, el
registro es accesible pero solo para lectura. La interpretación de los bits del registro es la
mostrada en la Tabla 31.
Tabla 31: Bus Timming Register 1
BIT.7
BIT.6
BIT.5
BIT.4
BIT.3
BIT.2
BIT.1
BIT.0
SAM
TSEG2.2
TSEG2.1
TSEG2.0
TSEG1.3
TSEG1.2
TSEG1.1
TSEG1.0
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Si el bit SAM vale 1, el muestreo es realizado tres veces en el bus (recomendado para buses
de baja/media velocidad), si vale 0, el bit es muestreado una única vez.
Por su parte, TSEG2 y TSEG1, determinan el número de ciclos de reloj en un periodo de bit
y la localización del punto de muestreo tal como se indica en la ¡Error! No se encuentra el
origen de la referencia.. Los valores empleados son:
Figura 38: Estructura General de un periodo de bit
2.3.5.3
Registro de control de salida “Output Control Register” (OCR)
Este registro permite la puesta a punto de diferentes configuraciones del controlador de
salida bajo el control del software. Puede accederse en modo de lectura y escritura si el
modo reset está activo, además de ser accesible en modo operación si se está utilizando
PeliCAN.
El contenido de sus bits es el mostrado en la Tabla 32:
Tabla 32: Registro de control de salida
BIT.7
BIT.6
BIT.5
BIT.4
BIT.3
OCTP1
OCTN1
OCPOL1
OCTP0
OCTN0
BIT.2
BIT.1
BIT.0
OCPOL0 OCMODE1 OCMODE0
La lógica empleada en el “transceiver” es la mostrada en la Figura 39.
84
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 39: Logica Empleada en el Transceptor
Si el microcontrolador se encuentra en “sleep mode”, un valor rescesivo se coloca en los
pines TX0 y TX1. Si el controlador se encuentra en modo reset, dichas salidas quedan
flotantes.
La etapa de salida de transmisión es capaz de operar en diferentes modos. La ¡Error! No
se encuentra el origen de la referencia. muestra el control de salida de registro de
configuración.
Tabla 33: Interpretación de los bits OCMODE
OCMODE1
OCMODE0
Descripción
0
0
bi-phase output mode
0
1
test output mode
1
0
normal output mode
1
1
clock output mode
En “Normal Mode”, la secuencia de bits (TXD) se envía a través de TX0 y TX1. Los niveles
de tensión en el “driver” de salida en los pines TX1 y TX0 dependen de las características
de dicho “driver” programadas por OCTPx y OCTNx (“float”,”pull-up”, “pull-down”,
“push-pull”) y la polaridad de la salida programada por OCPOLx.
Para el “clock output mode”, el pin TX0 funciona del mismo modo que en “normal mode”.
No obstante, la cadena de datos de TX! se reemplaza por el reloj del transmisor (TXCLK).
El flanco de subida del reloj del transmisor marca el comienzo de un periodo de bit. Tal
como se ve en la Figura 40, el ancho de pulso es
.
85
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
86
Figura 40: Ejemplo del Clock Output Mode
En contraste con el “normal output mode”, en el “bi-phase output mode” la representación
de los bits es variable en el tiempo y alternante. Si el controlador de bus tiene aislamiento
galvánico con la línea de transmisión mediante un transformador, la cadena de bits no
podrá contener componentes en DC. Esto se consigue de la forma siguiente. Durante los
bits recesivos a la salida todas las salidas están desactivadas (flotantes). Los bits
dominantes se envían con alternación de los niveles en TX0 y TX1, es decir, el primer bit
dominante se envía en TX0, el segundo es enviado en TX1, y el tercero se envía en TX0 de
nuevo, y así sucesivamente. Una posible configuración de modo de salida bi-fase es
mostrado en la Figura 41.
Figura 41: Ejemplo de Bi-phase Output Mode
Por su parte, en “test output mode”, el nivel conectado a RX se refleja en TXn en el
siguiente flanco positivo del reloj del sistema fosc/2 correspondiente con la polaridad
programada en el “Output Control Register”.
En la Tabla 34, se muestra una relación entre los bits de salida del registro de control de
salida y la salida de los pines TX0 y TX1.
Tabla 34: Configuración de los pines de salida
DRIVE
TXD
OCTPX
OCTNX
OCPOLX
TPX
TNX
TXX
Float
X
0
0
X
off
off
float
Pulldown
0
0
1
0
off
on
LOW
1
0
1
0
off
off
float
0
0
1
1
off
off
float
1
0
1
1
off
on
LOW
0
1
0
0
off
off
float
Pull-up
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Pushpull
87
1
1
0
0
on
off
HIGH
0
1
0
1
on
off
HIGH
1
1
0
1
off
off
float
0
1
1
0
off
on
LOW
1
1
1
0
on
off
HIGH
0
1
1
1
on
off
HIGH
1
1
1
1
off
on
LOW
X significa que el valor es irrelevante, TPX es el “on-chip output transistor X” conectado a
VDD, TNX es el “on-chip output transistor X”, conectado a VSS y TXX es el nivel de salida
serie del pin TX0 o TX1. Es necesario que el nivel de salida en la línea del bus CAN sea
dominante cuando TXD=0 y recesivo si TXD=1.
2.3.5.4
Registro de división del reloj. “Clock Divider Register” (CDR)
Aunque el último de los registros presentados, este registro es sumamente importante y
utilizado ya que su bit más significativo indica el modo de CAN empleado. En general,
El registro controla la frecuencial del reloj de salida CLKOUT para el microcontrolador y
permite desactivar el bit correspondiente a dicho reloj. Además controla una interrupción
dedicada de recepción, un comparador bypass y el ya mencionado selector entre
BasicCAN y PeliCAN. El estado del registro tras un reset divide por defecto la frecuencia
del reloj entre 12 para Motorla y entre 2 para Intel.
La interpretación de los bits de este registro se muestra en la Tabla 35.
Tabla 35: Clock Divider Register
BIT.7
BIT.6
BIT.5
BIT.4
BIT.3
BIT.2
BIT.1
BIT.0
CAN
mode
CBP
RXINTEN
(0)
clock off
CD.2
CD.1
CD.0
Los bits CD.2 a CD.0 son accesibles sin restricciones en modo reset y en modo operación.
Estos bits son usados para definir la frecuencia de reloj en el pin externo CLKOUT y se
interpretan de la forma mostrada en la Tabla 36.
Tabla 36: Posible elección de frecuencia de CLKOUT
CD.2
CD.1
CD.0
CLKOUT
FREQUENCY
0
0
0
Fosc/2
0
0
1
Fosc/4
0
1
0
Fosc/6
0
1
1
Fosc/8
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
1
0
0
Fosc/10
1
0
1
Fosc/12
1
1
0
Fosc/14
1
1
1
Fosc
Por su parte, el bit clock off si está activo, permite deshabilitar el pin externo CLKOUT.
Solo es posible un acceso de escritura en modo reset. Si este bit está activo, CLKOUT se
encuentra a nivel bajo durante “sleep mode”, de otra forma está a nivel alto.
Por su parte, el bit RXINTEN, permite emplear la salida TX1 como una interrupción de
recepción dedicada de salida. Cuando un mensaje ha llegado y pasado el filtro de
aceptación, se recibirá un pulso de interrupción con la longitud de un tiempo de bit en el
pin TX1 (durante el último bit de la trama). La etapa de salida del transmisor debe operar
en “normal output mode”. La polaridad de la salida es programada con el “output contro
register”. Solo es posible un acceso de escritura en el modo reset.
A su vez, el bit CBP, permite omitir el comparador CAN de entrada y solo es posible en
modo reset. Esto es útil si el controlador CAN está conectado a un circuito transceptor
externo. El retraso interno del controlador CAN se reduce, lo que permite alargar el
máximo posible la longitud del bus. Si CBP está activo, solo RX0 está activo, y RX1 debe
conectarse a un nivel definido.
Por último, el bit de “CAN mode”, permite elegir el modo de operación del controlador
CAN. Este bit solo es accesible para escritura en modo reset. Si se le impone un valor
lógico 0, el bit opera en modo BasicCAN, mientras que en caso de asignarle un 1 lógico, el
controlador operara en modo PeliCAN.
88
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
2.4 Proyectos ITS
Analizaremos el proceso de evolución de la tecnología inalámbrica através de los más
importantes proyectos relacionados con los ITS tanto en Estados Unidos como en Europa.
2.4.1
Proyectos ITS Americanos
Cuando se habla de tecnologías inalámbricas para entornos vehiculares en la literatura
americana se asocia con el uso de las tecnologías DSRC (Dedicated Short Range
Communications). Históricamente el gobierno de los Estados Unidos de America ha
apoyado el desarrollo de los ITS através del Departamento de Transporte (USDOT) y las
distintas asociaciones públicas creadas para la investigación y el desarrollo de éstos. A
continuación se citan algunos de los proyectos e iniciativas que más han influido en la
creación del estándar WAVE y los sistemas de conducción cooperativos. Resaltar que la
conotacion negativa que tienen las comunicaciones móviles celulares en este país, han
contribuido a que las administraciones se vuelquen con el desarrollo de una nueva
tecnología de comunicaciones específica.
2.4.1.1
PATH (Desde 1986)
La iniciativa PATH (California Partners for Advanced Transportation Technology) [14]
nació en 1986 en el seno del Instituto de Estudios para el Trasporte de la Universidad de
California, Berkeley, y el departamento de transporte de California (Caltrans). Su principal
objetivo es desarrollar estrategias ITS innovadoras que permitan mejorar la seguridad,
flexibilidad, movilidad y despliegue de los sistemas de transporte en Califormia, los
Estados Unidos y el mundo [15]. Esta iniciativa ha jugado un papel importante en la
creación de la Sociedad Americana para el Transporte Inteligente (ITSA-Intelligent
Transportation Society of America). Fue el primer centro de investigación ITS en EEUU y
ha llegado a convertirse en uno de los más importantes del mundo. Sus líneas de
investigación pueden agruparse en tres:

Investigaciones en las Operaciones del Tráfico.

Investigaciones en la Seguridad del Transporte.

Investigaciones de Aplicaciones Modelo.
Hace no demasiado tiempo, en 2011, otro de los más grandes centros de investigación
sobre tecnologías aplicadas al transporte como el California Center for Innovative
Transportation (CCIT) se fusionó a la iniciativa PATH aunando esfuerzos.
2.4.1.2
IntelliDrive (2004 – 2009)
El proyecto IntelliDrive, formalmente conocido como Vehicle Infrastructure Integration
(VII) es un proyecto de colaboración entre el USDOT, asociaciones y universidades (ITS
America, PATH, Virginia Tech, etc), y la industria. Sus objetivos están relacionados con las
comunicaciones vehiculares y pueden definirse bajo dos principios [16]:

La investigación en comunicaciones entre vehículos (V2V) como una tecnología
que permita aplicaciones que eviten colisiones y accidentes.

La investigación del vehículo con la infraestructura fija (V2I).
Uno de los mayores hitos dentro de este proyecto fue la definición de las aplicaciones para
el primer día, que son las aplicaciones más importantes que han de ser implentadas
cuando se instauren de forma oficial las comunicaciones V2X. Es también importante
destacar que estos test servirán como prueba de concepto (POC-Proof of Concept) para
validar los nuevos estándares de DSRC en desarrollo IEEE 802.11p, IEEE 1609 y SAE J2735:
La pila de protocolos WAVE para su uso de prueba. Resumiendo los logros de este
proyecto, finalmente fueron demostradas las virtudes del nuevo núcleo para las
comunicaciones DSRC, tanto en las funciones de V2V y como V2I [9]. Sin embargo, fueron
89
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
dadas una serie de recomendaciones a tener en cuenta para un trabajo futuro:

Hay que conseguir mejorar el rango de las comunicaciones inalámbricas para la
mayoría de las situaciones,

Es necesario un estudio mucho más profundo y exhaustivo de los efectos del
multicamino de la señal.

Respecto a temas de seguridad, fue necesario la creación de dos protocolos IP (VDTLS y V-HIP) para poder mantenerla, recomendando a los cuerpos de
estandarización su extensión y desarrollo.
En general, las pruebas y las contribuciones del proyecto fueron satisfactorias y
contribuyeron a la construcción de una arquitectura Nacional de ITS (National ITS
Architecture).
2.4.1.3
SafeTrip21 (2008 – 2011)
Tras el programa VII en 2008 se llevó a cabo una nueva iniciativa a manos de l USDOT y la
Research and Innovative Technology Administration (RITA) conocida como “The Safe and
Efficient Travel through Innovation and Partnerships for the 21st Century” (SafeTrip21). El
objetivo de esta iniciativa era testear, evaluar e integrar las aplicaciones ITS, centrandose
los beneficios inmediatos que podrían producir como mejoras en la seguridad, reducción
de la congestión de las ciudades y el avance en el desarrollo del sistema nacional de
transporte [10]. La necesidad de generar beneficios de forma rápida, fue necesaria debido a
que para hacer funcionar de forma óptima el sistema, todos los vehículos han de poseer
una entidad embarcada que les permita utilizar este estilo de comunicaciones. Por tanto la
inversión ha de ser enorme. Así que estos test trataron de mostrar las ventajas dando un
empujon al desarrollo de ésta tecnología. Para ello el USDOT realizó cuatro concesiones
para el testeo específico de aplicaciones ITS [11]:

The California Connected Traveler Test Bed.

The I-95 Corridor Coalition Test Bed.

Dos concesiones fueron dadas a empresas independientes (iCone Product LLC y
TrafInfo Communications, Inc.) para probar el equipamiento y mejorar los testbeds
realizados.
La evaluación de los resultados finales del proyecto SafeTrip21 fueron realizados por una
compañía independiente (SAIC-Science Applications International Corporation) [17].
Finalmente, esta iniciativa ha sido considerada como la primera inversión federal en un
test de campo de ITS que estaba centrada en el mercado, tratando de dar a conocer las
bondades de ésta tecnología como un producto comercial que puede ser usado y vendido
en un mercado global.
2.4.1.4
Safety Pilot (2011 – 2014)
El proyecto Safety Pilot es un gran proyecto para testear la tecnología DSRC, está liderado
por el Instituto de Investigación del Transporte de la Universidad de Michigan (UMTRI),
en colaboración con la iniciativa CAMP (Crash Avoidance Metrics Partnership) y el
USDOT, estándo recogido dentro del programa Nacional de ITS del gobierno. Su misión es
demostrar los verdaderos beneficios de las comunicaciones V2V con conductores reales, en
un entorno real. El despliegue del proyecto incluye más de 73 millas lineales equipadas
con entidades de carretera en la ciudad de Ann Arbor. Este proyecto da a los conductores
voluntarios todo el equipamiento necesario para dotar a su vehículo con una plataforma
de comunicaciones V2X. En total más de 2800 vehículos fueron preparados para el estudio,
que estará recogiendo datos durante un año [19]. Recientemente, han añadido a la
iniciativa seis motocicletas y una bicicleta, para aportar mayores datos al estudio en la
infraestructura desplegada [13].
90
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 42: Plano del Modelo de Despliegue de Safety Pilot [21]
Este proyecto finalizará a finales de 2013 y ha sido considerado un hito relevante en el
programa de conducción cooperativa, ya que con los resultados obtenidos la National
Highway Traffic Safety Administration (NHTSA) determinará la forma de proceder con
actividades relacionadas con las comunicaciones V2V [22]. Por tanto los resultados
obtenidos del mismo marcarán el futuro de éste estilo de comunicaciones.
2.4.2
Proyectos ITS Europeos
La evolución en la investigación realizada en el ámbito de los ITS gracias a los proyectos
relacionados ha sido llevada a cabo por la Comisión Europea (EC). Para comenzar, un
buen punto de partida puede ser considerado la creación del grupo de trabajo eSafety [23].
Creado como una iniciativa conjunta entre el sector público y la industria en 2002, la cual
buscaba caminos que consiguieran acelerar el desarrollo y la implantación de las nuevas
tecnologías a la infraestructura de transporte europea. Su función principal es la de
coordinar y aconsejar, siendo intermediario entre los cuerpos de estandarización para
establecer un plan de acción de ITS a seguir. Este grupo de trabajo está compuesto por
representantes de la EC, de la industria de la automoción (ACEA-Asociación de
Fabricantes de Automoviles Europeos), el Consejo Europeo para la Automoción I+D
(EUCAR), empresas de telecomunicaciones y servicios industriales, operadores de las
infraestructuras y otros interesados como ERTICO, asociaciones públicas y de usuarios
[24]. El plan establecido como guía para los ITS comienza a definirse fundando iniciativas
y proyectos, los más importantes son aquellos incluidos en el Sexto y Septimpo Programa
Marco para la Investigación y el Desarrollo Tecnológico (FP6 y FP7). Este plan para los ITS
tiene sus bases establecidas en la Directiva 2010/40/EU [25] para tratar de solucionar los
problemas de transporte en todos los estados miembros. Por otro lado, a modo de
resumen, se destacan también los cuerpos de estandarización europeos que promueven y
establecen los estándares relacionados con los ITS. Estos cuerpos son:

CEN (European Committee for Standardization).
91
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

CENELEC (European Committee for Electrotechnical Standardization).

ETSI (European Telecommunications Standards Institute).
A continuación se recogen los proyectos que más relevancia han tenido en la
estandarización de las comunicaciones vehiculares, citados anteriormente en la
introducción. Son aquellos incluidos en el FP6: CVIS, SAFESPOT y COOPERS. Estos tres
proyectos fueron desarrollados de forma paralela entre 2006 y 2010 y analizan el concepto
de conducción cooperativa desde tres puntos de vista distintos [27].
Figura 43: Distintas Visiones de los Proyectos
CVIS, COOPERS y SAFESPOT

CVIS trabaja en el nucleo de la arquitectura de red que permita las comunicaciones
vehiculares V2V y V2I, para ello desarrolla prototipos y test que garanticen su
funcionamiento.

SAFESPOT analiza y define las tareas críticas en los principales escenarios de
seguridad vial.

COOPERS está centrado en el punto de vista del operador de servicios ITS, dando
a conocer las necesidades de la infraestructura para poder soportar
verdaderamente las aplicaciones vehiculares.
2.4.2.1
CVIS
El proyecto CVIS (Cooperative Vehicle and Ingrastructure Systems) tiene como objetivo
crear el nucleo de la red para entornos vehiculares, para ello desarolla una arquitectura
complete que dará soporte a las aplicaciones ITS. Entre los objetivos del proyecto CVIS
también se encuentra el crear un marco abierto de trabajo que haga más fácil la creación de
aplicaciones cooperativas que sirvan para la vida real y den verdadero servicio a los
conductores, la industria y los operadores [28]. Este proyeto es pionero en el uso del
estándar ISO-CALM (Communications Access for Land Mobiles) el cual aún se encontraba
bajo desarrollo al inicio de este proyecto que además se estableció como prueba del
concepto de lo establecido por el estándar. Este proyecto tuvo una financiación inicial de
aproximadamente 41 millones de euros, estuvo coordinado por ERTICO – ITS Europe y
contaba con más de 60 colaboradores. Para conseguir los objetivos del proyecto, fue
dividido en tres proyectos núcleo que dieron como resultado las siguientes tecnologías:

COMM (Components for Communications and networking): con el objetivo de
resolver todos los requerimientos de disponibilidad, conectividad, flexibilidad y
transparencia que fueron propuestos en el estándar de prueba de ISO-CALM. Se
92
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
definió una arquitectura del sistema basada en tres grandes entidades, donde
varias tecnologías de comunicaciones inalámbricas han sido tenidas en cuenta
(CALM, IR, CALM-M5, CALM MM, CALM 2G/3G, CEN DSRC)
Figura 44: Arquitectura CVIS [29]

FOAM (Framework for Open Application Management): Se define una plataforma
abierta que permite dar soporte a todoas las fases de una aplicación ITS a lo largo
de su tiempo de vida.

POMA (Positioning Map & Local Referencing): Todas las aplicaciones ITS
necesitan tener una muy buena precisión y con muy poco margen de error a la
hora de obtener la posición del vehículo. Para conseguirlo y mejorarlo, en este
sistema se han realizado combinaciones de varios modulos de posicionamiento
que son capaces de tener en cuenta la robustez de la señal y el error cometido.
Además se han desarrollado técnicas novedosas para conseguir situar el vehículo
en un mapa, creando además APIs de programación que permiten actualizar los
mapas.
2.4.2.2
SAFESPOT
Bajo el nombre en ingles “The Cooperative Vehicles and Road Infrastructure for Road
Safety” (SAFESPOT) este proyecto trata de diseñar los sistemas que permitan hacer uso de
las comunicaciones V2V y V2I [30]. Con la ayuda de estos sistemas puede mejorarse la
seguridad en las carreteras, para ello se ha creado el “Asistente del Margen de Seguridad”
que permite detectar situaciones potencialmente peligrosas avisando a los conductores con
muchísima información extra. El proyecto SAFESPOT se ha realizado con el trabajo de un
consorcio de 51 colaboradores liderado por el centro de investigación de FIAT en Italia. El
proyecto contaba con una financiación de 38 millones de euros [31]. Las principales metas
de SAFESPOT están recogidas en estos estamentos:

Testear y trabajar con el protocolo IEEE 802.11p, establecido como tecnología
candidata para las comunicaciones vehiculares.

Desarrollar y mejorar un sistema real de posicionamiento y cartografía.

Seguir los pasos de los principales grupos de estandarización como el grupo de
trabajo de ISO-CALM y el C2C-C (Car 2 Car – Consortium).
En la siguiente figura quedan recogidos todos los subproyectos y las empresas
93
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
colaboradoras que los dirigieron:
Figura 45: Subproyectos SAFESPOT [32]
Como resultado de estos subproyectos se estableció la arquitectura común europea para
ITS en sistemas cooperativos. El punto clave fue la implementación de una red ad hoc de
alta velocidad y un conjunto completo de mensajes, todo ello, sobre el estándar IEEE
802.11p. También se realizó en este proyecto un análisis de las buenas perspectivas de
futuro y de los nuevos modelos de negocio que generarían este estilo de sistemas.
2.4.2.3
COOPERS
Co-operative Systems for Intelligent Road Safety (COOPERS) se centra en el desarrollo un
modelo de gestión del tráfico cooperativa entre vehículos e infraestructuras. Está
compuesto por 36 socios, coordinado por Austria Tech y con un presupuesto de 27
millones de euros [33]. Tiene como objetivo la mejora de la seguridad vial, la optimización
de los recursos de la infraestructura del transporte ayudando así al medio ambiente,
mediante una información directa y en tiempo real del tráfico. Las áreas de trabajo dentro
del proyecto son las siguientes:

Adquisición de datos de la carretera.

Configuración de la unidad de carretera y de la unidad de abordo.

Centro de control del tráfico (TCC – Traffic Control Center) y aplicaciones del
mismo.

Servicios de información y metodologías de pruebas.

Simulación y demostración.
Este proyecto, como se comentó anteriormente, está centrado en una visión de
mantenimiento, gestión de la red vehicluar, es por ello que presta muchísima atención a las
comunicaciones I2V (Infraestructura a Vehículo). Por ello establece varias tecnologías de
comunicaciones con el vehículo como DAB, DVB-H, GPRS, WIMAX, CALM-IR.
Finalmente se obtienen directrices sobre cómo crear los servidores de los operadores de
servicios ITS y la forma en que accedan los dispositivos embarcados a dichos servicios.
2.4.2.4
GCDC
GCDC (Grand Cooperative Driving Challenge) tiene como objetivo acelerar el desarrollo e
implementación de las tecnologías de la conducción cooperativa para contribuir
94
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
significativamente a aliviar los problemas de tráfico a nivel mundial. Es un proyecto cuya
finalidad está enfocada a la participación y competición entre equipos internacionales para
conseguir el sistema más eficiente de cooperación vehículo-infraestructura en escenarios
predeterminados de tráfico. Un reto internacional en el campo de la conducción
cooperativa.
En 2008 se anunció el Grand Cooperative Driving Challenge y el resultado tras varias
modificaciones del plan inicial fue que comenzaría en 2009 y los resultados finales se
verían en 2011. En resumen, el programa sería el siguiente:

2009: Taller (mayo) durante el evento “Cooperative Systems on the Road" para
intercambiar ideas sobre las normas, protocolos y tecnología.

2010: Demostración de la tecnología cooperativa durante el evento de exhibición de
marzo con la participación de CVIS, SAFESPOT y Coopers.

2011: El desafío de los sistemas cooperativos de carretera en el que participarán
equipos de todo el mundo.
Después de 2011, los organizadores pretenden hacer que el reto se convierta en un evento
anual internacional en el que situaciones de tráfico nuevas y más desafiantes sean tenidas
en cuenta y así estimular el desarrollo de la tecnología de la cooperativa a largo plazo. El
primer evento que se organizó en mayo de 2011 fue una oportunidad para que los equipos
participantes mostraran sus desarrollos y evaluaran su situación con respecto a los otros
equipos en competencia.
Figura 46: Escenario GCDC
El plan consiste en promulgar un escenario predefinido y crear una prueba de onda de
choque de amortiguación con vehículos CACC proporcionados por los equipos
participantes. Los equipos se benefician de la exposición internacional a los medios y de la
oportunidad de poner a prueba su tecnología para compararse con los demás
competidores.
La conducción cooperativa permite un uso más eficiente de la infraestructura existente que
reduce los gastos y el uso del suelo para nuevas carreteras. Se basa en la comunicación
inteligente entre vehículos y entre vehículos y su entorno. Un uso más eficiente de la
carretera se consigue permitiendo que los vehículos circulen a una distancia más corta
entre ellos (reducción de consumo) al mismo tiempo que se garantiza un flujo homogéneo
del tráfico (rendimiento).
Los tiempos de reacción del ser humano son demasiado grandes como para conducir tan
cerca de otro coche y hoy en día los sistemas avanzados de control de crucero presentan
95
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
problemas. Los sistemas actuales ACC (Adaptive Cruise Control) sólo reaccionan con el
vehículo que está justo enfrente, no son capaces de predecir el comportamiento del flujo de
tráfico completo. Sin embargo, los sistemas cooperativos son capaces de proporcionar
información sobre qué sucede alrededor del vehículo, así como predecir qué va a suceder
en un futuro cercano. Esto permitirá a los vehículos equipados con dicho sistema
amortiguar y posiblemente prevenir ondas de choque de una serie de vehículos.
En resumen, aunque las tecnologías permitidas están disponibles en la actualidad, un
amplio despliegue de aplicaciones en tiempo real para la conducción cooperativa, como
platooning, sigue planteando retos significativos con respecto a la fiabilidad, seguridad,
escalabilidad y eficacia a un bajo grado de penetración. Por otra parte, la implementación
plantea un desafío adicional con respecto a los beneficios para el usuario y el plan de
negocio. GCDC pretende contribuir al desarrollo a gran escala y al despliegue de
aplicaciones en tiempo real mediante la creación de un impulso significativo, dando lugar
a un entendimiento común y a un enfoque unificado para estas aplicaciones.
96
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
3 ARQUITECTURA Y ELEMENTOS DEL
SISTEMA
L
a implantación de las tecnologías de comunicación y control que se desean realizar
en el proyecto exigen la construcción de un sistema demostrador que sigue la
arquitectura definida en el proyecto CVIS, Figura 8. El sistema que se propone se
trata de una versión simplificada de éste, compuesto por un vehículo y una entidad
externa de comunicación. Estos sistemas pueden denominarse como:

OBU (On Board Unit): Entidad embarcada en el vehículo eléctrico.

RSU (Road Side Unit): Entidad de carretera situada, por ejemplo, en una cámara de
monitorización.
Figura 47: Arquitectura CVIS
97
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
3.1 OBU
3.1.1
Arquitectura Base
La arquitectura a seguir es la propuesta en el proyecto CVIS, expuesta en la Figura X, en la
cual se distinguen tres entidades:
Figura 48: OBU Elementos Embarcados en Vehículo

Mobile Router: Entidad encargada de las comunicaciones del vehículo, tanto en el
exterior como en el interior.

Vehicle Host: Entidad encargada del control de todos los elementos del coche,
podría definirse como el ordenador de abordo tal y como se conoce en la
actualidad.

Vehicle Gateway: Entidad encargada de ser la pasarela entre el ordenador de a
bordo y los sensores y elementos de control del vehículo. Se encarga de recopilar
los datos de los sensores y pasarlos al ordenador de a bordo para que sean
procesados y transmite las órdenes de control a aquellos elementos que actúen
sobre el vehículo.
3.1.2
Arquitectura del Demostrador
La arquitectura definida para el prototipo se ciñe de forma fiel a las recomendaciones del
proyecto CVIS. Añadiendo además, una nueva entidad, la HMI (Human Media Interface),
con la cual se podrá controlar y monitorizar algunos dispositivos del vehículo permitiendo
en un futuro ser la pasarela de comunicaciones hacia una red móvil 3G/LTE.
98
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 49: Arquitectura del Demostrador
A continuación se describen cada una de las entidades destacando los dispositivos
hardware que las implementan junto con sus características más importantes. Añadir que
la elección de cada uno de los dispositivos ha sido objeto de un estudio previo que
garantizó la viabilidad del proyecto.
3.1.3
Mobile Router
Este sistema permitirá al vehículo comunicarse con el exterior: entidades de carretera,
dispositivos móviles, estaciones fijas, etc. Es por ello que debe ser capaz de ofrecer varias
de las tecnologías de comunicación sin cables ya implantadas como son WiFi (802.11g) y
Bluetooth. Y las nuevas formas de comunicación inalámbrica en el ámbito ITS, como se
comentó anteriormente, ya estandarizadas pero aún sin estar implantadas, WAVE
(802.11p/1609) o su versión europea CALM-M5. El dispositivo elegido para la
implementación de esta entidad es una placa router capaz de albergar en su interior un
sistema operativo Linux. Hablamos por tanto de un Embedded Linux System. La placa en
cuestión es la AlixBoard 3D2, un dispositivo que cuenta con varios puertos de expansión
que la dotan para tener una gran capacidad en la implementación de distintas tecnologías
de comunicación.
99
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 50: AlixBoard 3D2 (Superior/Inferior)
A continuación se destacan las características más importantes del dispositivo extraídas
del catálogo del fabricante:
Tabla 37: Caracteristicas AlixBoard 3D2
CPU: 500 MHz AMD Geode LX800
DRAM: 256 MB DDR DRAM
Almacenamiento: Slot CompactFlash
Alimentación: DC jack o POE pasivo, min. 7V to max. 20V
Tres LEDs
Expansion: 2 miniPCI slots, LPC bus
Conectividad: 1 Ethernet (Via VT6105M 10/100)
I/O: DB9 puerto serie, dos USB
Dimensiones: 100 x 160 mm
Firmware: tinyBIOS
Sobre este dispositivo hay que resaltar las siguientes características que determinaron su
adquisición para el prototipo:
100
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Procesador AMD Geode LX800: Este procesador es el mismo que el utilizado en
anteriores proyectos del grupo de investigación, de sobra conocido por su eficacia
y funcionalidad. De hecho, se poseen varias placas con el formato PC104 basadas
en éste y por tanto permiten, si fuese necesario, portar las aplicaciones realizadas al
tratarse de la misma arquitectura.

Dos puertos mini-PCI: En la actualidad la mayoría de tarjetas de comunicación
industrial poseen este formato. Permitiendo, en el caso de las tarjetas inalámbricas,
la posibilidad de utilizar una antena externa que garantice la potencia de
transmisión y pueda situarse en el exterior del vehículo.

Dos puertos USB: Permitirán el conexionado a la placa de dongles Bluetooth o
WIFI genéricos y la posibilidad de utilizar dispositivos de almacenamiento masivo
USB que doten a la placa de espacio suficiente para las futuras aplicaciones.

Conexión Ethernet: Mediante esta interfaz se realizará la comunicación con el
Vehicle Host estableciéndose así un canal de comunicación fiable, seguro y de alta
velocidad de transmisión de datos.
Además de haber sido la plataforma utilizada en la iniciativa GCDC, lo que avala en cierta
manera su potencial para cumplir su objetivo. A continuación se muestran los dispositivos
que dan conectividad inalámbrica (WAVE, WiFi y Bluetooth) a la tarjeta.
3.1.3.1
Tarjetas Mini-PCI
Para dotar a la placa AlixBoard de comunicaciones inalámbricas tanto WAVE como WiFi,
la mejor interfaz posible, que además permite desarrollar sobre ella, es la mini-PCI. Las
tarjetas elegidas son las MikroTik R52H que poseen el chipset de comunicaciones AR5414
uno de los requisitos para el desarrollo del protocolo de comunicaciones 802.11p. Estas
tarjetas son de uso industrial y permiten implementar sin modificación alguna los
protocolos de comunicaciones 802.11a/b/g permitiendo un uso en un rango ampliado de
frecuencias, además de una potencia de salida ajustable y suficiente.
Figura 51: MikroTik R52H
Las características más relevantes son mostradas a continuación, resaltar el rango de
frecuencias que permite ya que incluye la franja frecuencial para el uso de WAVE
sufirendo esta banda una atenuación menor que en otras tarjetas estudiadas:
101
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Tabla 38: Características MikroTik R52H
Chipset
AR5414
Rango de Frecuencias 2.192-2.539MHz / 4920-6100Mhz
3.1.3.2
Estándares
IEEE802.11a/IEEE802.11b/IEEE802.11g
Potencia Máxima
25dBm
Formato
miniPCI
Dimensiones
6.0cm x 4.5 cm
Conectores
2x UFL
Temperaturas de Op.
-20C to +70C
Alimentación
3.3V +/- 10% DC; 800mA max.
Dongle Bluetooth
El modelo concreto es el CBT2NANO de Conceptronic. Se trata de un dispositivo USBBluetooth de clase 2 el cual es soportado por las distintas distribuciones Linux. Este
dispositivo, además de pequeño, permite su programación utilizando las librerías BlueZ.
Figura 52: Dongle
Bluetooth Conceptronic
102
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Tabla 39: Caracteristicas Dongle Bluetooth
Estándar
V2.1+EDR (Backward compatible with V1.1/V1.2/V2.0)
Perfiles Soportados
Serial Port, Dial Up Networking, Fax, Headset, Printer, PIM Item
Transfer, PIM Synchronization, File Transfer, LAN Access, Generic
Object Exchange, Object Push, HCRP, HID, A2DP, AVRCP
Rango de Frecuencias
2.402~2.480 GHz / 79 Channel FHSS
Tasa de Transfererencia
3 Mbps (Max)
Clase
Class 2 (10mtr distance)
Sensibilidad Recepción
-80dBm at 0.1% BER
Dimensiones (L x Anch x Alto)
19.3 x 14.2 x 4.5 mm
3.1.4
Vehicle Host
Es la entidad encargada de recopilar la información recibida y mostrar al usuario los
mensajes o información que sea necesario. Permite controlar y actuar sobre los dispositivos
del vehículo. Para desarrollar este sistema se ha elegido un PC industrial: el iKarPC de la
marca taiwanesa iEiMobile. Este PC es una solución que incluye una pantalla táctil
empotrada en el mismo permitiendo la actuación del usuario con el dispositivo y
viceversa.
Figura 53: iKarPC
103
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Tabla 40: Características iKarPC
Modelo
Pantalla
Sistema
Comunicaciones
Multimedia
Indicatores LED y
Botones
Interfaces de E/S
Alimentación
Entorno
iKarPC
LCD
8" TFT-LCD (Sunlight readable)
Brillo (cd/m²)
600 cd/m2 High Brightness
Resolución Max
800 x 480 pixels WVGA
Ángulo de Visión
60/60/50/50 Deg.
Pantalla Táctil
5-Wire Resistive Type Touch
CPU
Intel® Atom™ Z510 1.1 GHz
Chipset
Iintel® US15WP
Sistema Operativo
Microsoft® Windows® XP Embedded
Memoria RAM
1 GB DDR2 533 MHz On-board
Almacenamiento
4 GB CompactFlash® SD Card Slot
Wireless LAN
Wi-Fi® 802.11 b/g
Bluetooth
Bluetooth® V2.0+ EDR (Class 1)
Modem
WCDMA/HSUPA
GPS
GPS w/ Internal Antenna
Audio
1 x Line-in 1 x Line-out 1 x 3 W Speaker
Cámara
0.3 Megapixel CMOS Camera
Indicadores
Wi-Fi®/Bluetooth®/HDD/3.75G/DVB-T/Power Status LED
Teclas de función
F1~F6 Function Key, Direction key, Power Button
USB
2 x USB 2.0
Serie
1xDB-9-OBD-II
1x DB-9 RS-232/422/485 (Software selectable w/ 5V DC)
LAN
1 x 10/100/1000 Mbps GbE RJ-45
Desde el encendedor del
mechero
Cigarette Lighter Power Cable DC 9~30V
Desde el arranque del
vehículo
Manual power mode and ignition detection supported ACC power
on/off mode with software configurable delay time
Fuente de Alimentación
12V - 3A - 36W
Temperatura de Op.
-20˚C to +60˚C
Temperatura
Amacenamiento
Humedad
del
-30˚C to +70˚C
5%~95% non-condensing
104
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Física
Aguanta Caídas
1M
Protección Ambiental
IP54 compliant front panel (Water, dust and splash resistant)
Certificación
CE/FCC/e-MARK
Dimensiones (Largo
Ancho x Alto) (mm)
Peso
x
261 x 162 x 44
1730 g
De estas características hay que destacar que es un PC industrial especialmente diseñado
para ser un ordenador de a bordo para vehículos. Sus características le permiten funcionar
sin problema en el habitáculo del vehículo:

Una protección IP54

Un rango de temperaturas amplio
Posee las interfaces de comunicación requeridas para comunicarse con las principales
entidades del vehículo.

Ethernet: Comunicación con el VEHICLE HOST.

DB-9 OBD-II: Comunicación con la ECU, bus interno del vehículo.
Gran capacidad de procesamiento de datos y funcionamiento, gracias a su procesador y
memoria RAM, superior a la mayoría de dispositivos para este fin. Tiene un GPS
integrado, necesario en la mayoría de tecnologías y aplicaciones de control, ruta y ayuda.
Para su programación y desarrollo, el fabricante ofrece unas APIs de las interfaces
realizadas en Visual Studio usando Visual C++ y las clases propias de Microsoft (MFC).
Por otra parte también cabe destacar que el dispositivo permite, si el proyecto lo requiriera,
capacidades de comunicación 3G y un puerto de 9 pines configurable a distintos
protocolos de comunicación. Gracias a estas características el dispositivo además de
ajustarse perfectamente al proyecto, otorga la flexibilidad necesaria en este tipo de
proyectos de investigación.
3.1.5
Vehicle Gateway
Está basado en el microcontrolador de Texas Instruments TMS320F28335, que es el
componente principal del kit de entrenamiento MSK28335 fabricado por Technosoft. La
placa de interface entre el kit de entrenamiento MSK28335 y los elementos de la etapa de
potencia fue desarrollada dentro del grupo de investigación y consta de 10 entradas de
conversión analógica digital, 12 salidas PWM y varias entradas y salidas de propósito
general que se usan para controlar elementos de potencia secundarios. La principal ventaja
de utilizar el TMS320F28335 está en su alta capacidad de cálculo, lo que permite realizar
operaciones de control complejo tales como el control predictivo en tiempo real.
105
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 54: MSK28335 con Adaptación de Señales
Tabla 41: Caracteristicas MSK28335
Procesador
TMS320F28335
Comunicaciones
RS232, CAN, I2C
Entrada Analógica 4 sensores corriente efecto Hall
4 adaptadores señal 0-20 mA
2 sen. alta tensión optoacoplado
Salida
12 PWM optoacoplado
4 salidas optoacoplado
3 salidas relay
Entradas digitales
6 entradas de fallo, 2 grupos de 3
Encoder digital
Esta plataforma realizará la función de ECU del sistema y será desarrollada en la parte de
potencia del grupo de investigación, donde se espera conseguir un motor de propulsión
multifásico capaz de seguir funcionando aún cuando una de sus fases cae. Por tanto será
necesario el establecimiento de un protocolo de comunicaciones bien definido para lograr
106
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
los objetivos. Éste protocolo se realizará usando como capa física el estándar de
comunicaciones para vehículos CAN.
3.1.5.1
Sensores y Actuadores CAN
Para la realización de los sensores y actuadores CAN que implementen los elementos que
permitirán el control del vehículo además de aportar información relativa a su
comportamiento, se empleará el microcontrolador de ATMEL AT90CAN128 y el
transceiver para comunicaciones CAN MCP2551 de MicroChip.
Tabla 42: Características AT90CAN128
Arquitectura
8-bit RISC Microcontroler
Empaquetado
TQFP MF 64
Memoria
128K Bytes Flash
4 K Bytes EEPROM
4 K Bytes RAM
Comunicaciones
SPI, I2C, CAN, 2xUART
Caracteristicas Generales 8 canales ADC (10b), Comparador Analógico
8 Interrupciones, 4 Timers, 7 Canales PWM
Tabla 43: Características MCP2551
Velocidad Máxima
1 Mb/s
Empaquetado
PDIP/SOIC
Capa Física
ISO-11898
Caracteristicas Generales Para sistemas de 12-24V
Temperatura de Funcionamiento estendida -40 a 1250C
3.1.6
Human Media Interface
Debido al gran auge de los smartphone y tabletas, la inclusión de este estilo de dispositivos
en el interior del vehículo como parte activa de la monitorización y control del mismo es
una solución más que óptima que ofrece muchísimas posibilidades de desarrollo. El
dispositivo elegido para el desarrollo de esta entidad es una Galaxy Tab 7” de Samsung
con el sistema operativo Android. La conexión con la misma se realizará de forma
inalámbrica, ya sea creando un punto de acceso WiFi o una comunicación Bluetooth desde
el MOBILE ROUTER.
107
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 55: Samsung Galaxy Tab 7”
Tabla 44: Características Samsung Galaxy Tab 7”
Procesador
Dual Core 1,2 GHz
Dispositivos de Entrada Pantalla táctil
Dimensiones
193,7 x 122,4 x 9,9 mm
Peso
345 g
Pantalla
TFT 600 x 1.024 pixels (170 ppi) 7"
Bluetooth
Sí (3.0)
USB
Sí (2.0)
WiFi
WiFi 802.11 a/b/g/n
AGPS
Sí / Navigation
Memoria de usuario
16 GB
Memoria externa
Micro SD hasta 32 GB
Memoria RAM
1 GB
108
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Esta tableta venía configurada con la versión 2.2 del sistema operativo Android (Froyo),
pudiendo ser actualizada a sistemas más actuales para aprovechar las nuevas
características de programación que ofrece google a sus desarrolladores.
3.2 RSU
3.2.1
Arquitectura Base
Figura 56: Arquitectura interna RSU

Roadside Gateway: Pasarela de comunicación de los vehículos que transiten por la
carretera.

Access Router: Plataforma de comunicaciones que permite a los sistemas (sensores
y actuadores) que incorpora la RSU su comunicación y control.

Roadside Host: Equipo encargado de las comunicaciones internas y externas y el
control de la RSU.

Border Router: Pasarela de comunicaciones con el “exterior” o el centro de datos
correspondiente.
109
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
3.2.2
Arquitectura del Demostrador
Figura 57: Arquitectura
RSU del Demostrador
3.2.2.1
Router
Se realizará utilizando una placa router igual que en el punto 3.1.3, una AlixBoard 3D2. El
primer objetivo de este proyecto será realizar una entidad par a la embarcada en el
vehículo para el testeo de las comunicaciones y se establecerá el diseño de la misma
definiendo interfaces de entrada y salida con el fin de que sea integrada con dispositivos
ya implantados en el medio urbano: VisioWay, paradas de autobús, semáforos, etc.
3.2.2.2
Control Unit
En general será la parte de control que gobierna la entidad, por ejemplo, VisioWay. La
comunicación con la entidad router por algún tipo de interfaz cableada.
110
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
4 TRABAJO REALIZADO
S
iguiendo la arquitectura del proyecto presentada en el apartado anterior, el trabajo
que se ha realizado hasta la fecha constituye las bases de la comunicación. En primer
lugar, viendo el sistema desde el punto de vista del desarrollo de las entidades OBU y
RSU, es inmediato darse cuenta que ambas entidades tienen sus elementos centrales
comunes y por tanto si centramos el desarrollo en la creación de una entidad. La creación
de la otra será simple particularización del sistema. Por tanto el trabajo realizado se centra
en la creación de la entidad embarcada en el vehículo, dada su mayor complejidad debido
al material disponible.
Figura 58: Resumen OBU
111
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Es por tanto que también pueden definirse cuatro áreas de trabajo, como se muestran en la
Figura 19, para el proyecto. Es por tanto más fácil describir el trabajo realizado explicando
el trabajo desde estos cuatro frentes:

Integración Smartphone basado en Android mediante el establecimiento de una
comunicación WiFi o Bluetooth.

Red Externa, define el área de trabajo que comunica el vehículo con el exterior:
RSU y HMI.

PC Abordo, representa la interfaz de usuario mostrando los datos al usuario
mediante una interfaz intuitiva.

Red Interna, comprende toda la electrónica del interior del vehículo: sensores, ECU
y el bus de comunicaciones.
A continuación se explica el desarrollo realizado en cada una de estas áreas de trabajo.
4.1 Red Externa del Vehículo
La red externa del vehículo tiene como hardware central la placa AlixBoard 3D2 definida
como la entidad Mobile Router dentro de la arquitectura. Su elección para este proyecto
radica en su compatiblilidad con el hardware heredado del proyecto AudioCity.
Compatibles por arquitectura x86, siendo además idéntico su procesador AMD Geode
LX800. Esto permite portar directamente las aplicaciones, drivers y herramientas
utilizadas. Permitiendo, la creación de más entidades para cuando llegue la hora de testear
el sistema completo.
4.1.1
Elección Sistema Operativo para Mobile Router
El motivo por el cual se eligen sistemas empotrados donde se pueda instalar una
distribución compacta de Linux es debido a que el núcleo de GNU/Linux es en sí mismo
un potente enrutador, y que sobre este sistema operativo se lleva trabajando más de 10
años ofreciendo soluciones para estos dispositivos empotrados desde la experiencia y
trabajos previos de sus comunidades de desarrollo y del mundo del código abierto. Las
ventajas del código abierto sobre un sistema empotrado son enormes, y alcanzan su
máxima expresión cuando se trata con un proyecto de investigación en el que se pretende
desarrollar un sistema específico. La disponibilidad del código y la infinidad de
herramientas para su desarrollo y adaptación nos ofrecen un marco incomparable para la
preparación del software “a la carta”, conocidas las necesidades.
A continuación se presentan varios sistemas operativos capaces de funcionar en un
sistema Linux empotrado y se detallan en mayor o menor medida sus ventajas e
inconvenientes a la hora de instalarlo en nuestro sistema.
4.1.1.1
iMedia
La distribución iMedia es una solución versátil y con gran capacidad de adaptación a
escenarios específicos. Es ampliamente empleada en el mundo de los empotrados y
dispone de una distribución específica casi para cada ocasión, y más concretamente, para
los empotrados ALIX y las aplicaciones de enrutado inalámbrico. La instalación de la
distribución es realmente sencilla usando una imagen iso, lo que facilita enormemente el
mantenimiento del equipamiento y permite la selección de los servicios para los que se
desea la instalación dejando en manos del administrador sólo algunas cuestiones de
configuración de red. El arranque sobre una placa ALIX 3d2 está en torno al minuto con
muy pocos servicios activos. El sistema presenta dos problemas fundamentales que la
dejan inicialmente fuera de la discusión del SO a elegir:

No dispone de un sistema de gestión de paquetes. Este problema dificulta mucho
la instalación, administración y mantenimiento del sistema a largo plazo.
112
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

Presenta dificultades para cargar con éxito los módulos de madwifi, siendo
únicamente capaz de arrancar las interfaces Mini-PCI Atheros en su modo 802.11b.
Por estas cuestiones esta distribución ha sido desechada para su uso.
4.1.1.2
DD-WRT
Esta distribución para empotrados de Linux es muy prometedora. Muy empleada incluso
en sistemas comerciales, tiene una carga sorprendentemente rápida (en torno a los 10s), un
gestor de paquetes ya asentado en el mundo del software libre (ipkg), requiere de muy
poca capacidad de almacenamiento para funcionar (hasta 16MB), un sistema de ficheros
comprimido con rápido acceso para el punto de montaje raíz (squashfs) y dispone de un
interfaz de configuración gráfico visual, intuitivo y aparentemente bastante depurado de
errores. Todo esto lo hace muy configurable y seleccionable para un esquema de
funcionamiento tipo RoD. Sin embargo, dispone de 2 versiones, de las cuales la versión
completamente libre para la que no es necesario el pago de ninguna licencia de uso no
tiene una buena integración de los módulos madwifi para interfaces inalámbricas con
chipset Atheros. Dado que el sentido de este proyecto es la construcción de un enrutador
inalámbrico, este sistema operativo quedaría por tanto también descartado.
4.1.1.3
Open-WRT
La distribución Open-WRT para sistemas empotrados es, aparentemente, una de las
mejores adaptadas para el escenario que deseamos crear. Derivada de la distribución
anterior junto con otras tantas como Free-WRT o Gargoyle, se trata de una distribución con
una enorme comunidad de usuarios y desarrolladores. El motivo de su éxito reside en que
fue la distribución que las redes ciudadanas comenzaron a usar sobre los ya tradicionales
enrutadores Linksys de Cisco. Este empuje, junto con las ventajas que ya citamos en el DDWRT, sin su inconveniente de ser de pago, y ser capaz de hacer funcionar con éxito el
driver madwifi. Además de haber encontrado proyectos como el GCDC que utilizan este
sistema operativo como base para sus desarrollos, dándo incluso librerías e instrucciones
para su generación y utilización. Sitúan a este SO a la cabeza de las posibilidades.
4.1.1.4
Voyage
La distribución Voyage, que ya cuenta con bastantes años de desarrollo, tiene además una
ventaja agregada muy importante, y es su fortaleza en los entornos más inhóspitos y
aislados de las regiones rurales de países en desarrollo como Perú, Colombia o Ecuador.
Éste constituye un no desdeñable "know how" que unido a las evidentes pruebas de
estabilidad que ha dado la distribución (en algunos casos con varios años de
funcionamiento ininterrumpido en regiones de selva). Se trata de una distribución muy
completa, basada en debian lenny (igual que la distribución usada en AudioZity), cuya
comunidad de desarrolladores garantiza la continuidad del proyecto, tiene un buen gestor
de paquetes (apt-get) y es posible sobre ella montar casi cualquier servicio que pudiera
montarse sobre un PC de sobremesa. Tiene una versión específica para ALIX, un buen
sistema de construcción de la distribución "a la carta", para diseñar el sistema sin que nada
sobre y nada falte, y su funcionamiento es muy estable. Puede presentar una tara
importante ya que su tiempo de arranque sobre una ALIX 3d2 considerablemente elevado
(1 min. Aprox.).
4.1.1.5
FLI4L
Se trata de una distribución de GNU/Linux pensada para empotrados y dispositivos x86
de bajos recursos con el objetivo de construir enrutadores RDSI, DSL, WLAN y Ethernet.
Tiene todo lo que es necesario y es capaz de funcionar en sistemas con tan solo 16MB de
RAM. Su mayor problema se presenta en la traducción lingüística, y es que se trata de una
distribución alemana y aparentemente no integra otras traducciones del interfaz. Por
contra tiene algunas ventajas muy importantes, y es que tiene un interfaz web muy
avanzado y atractivo. Asimismo, integra algunas funciones avanzadas como soporte para
113
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Wake-On-LAN o modificaciones del protocolo de arranque. La gestión de paquetes hace
que se descarte este sistema operativo.
4.1.1.6
M0N0WALL
M0n0wall es un proyecto que se enfoca hacia la creación de un firewall software,
empaquetado para sistemas empotrados que provee de todas las herramientas
importantes de un firewall comercial (incluyendo facilidad de uso) basándose para ello en
software libre (FreeBSD). Una ventaja especial que tiene m0m0wall es que la configuración
completa del sistema es almacenada en un único fichero de texto XML, manteniendo un
elevado grado de transparencia con el usuario. Se trata probablemente del primer sistema
UNIX que realiza su configuración de arranque mediante PHP en lugar de usar los
habituales shell scripts, y el primero también en almacenar toda la configuración en un
fichero XML. Este sistema, difiere de los instalados en las otras máquinas que en un futuro
rodearán al proyecto, es por ello que se descarta.
4.1.1.7
ZEROSHELL
La distribución Zeroshell de GNU/Linux está pensada para aprovechar sistemas
descartados para el uso de escritorio o viejos servidores (e incluso PCs de escritorio en uso)
como enrutadores avanzados sin necesidad alguna de instalación, empleando su arranque
desde CD. Sus requisitos son superiores a la mayoría del resto de distribuciones para
empotrados, requiriendo al menos un procesador de 233MHz y 96MB de RAM. Su
principal ventaja es su probado funcionamiento con el driver Madwifi para tarjetas
inalámbricas con chipset Atheros, para la “auditoría” de redes inalámbricas domesticas.
No obstante sus requerimientos de sistema, superiores al resto, descartan inicialmente su
uso.
4.1.1.8
Decisión Sistema Operativo
Finalmente se eligió entre Voyage y Open-WRT, eligiendo la última ya que se conocía en
mayor medida la configuración del sistema. Su comunidad es activa y participativa,
ayudando y dando soporte a aquellos posibles problemas de difícil solución. Además el
contacto establecido con algunos grupos integrantes de la iniciativa GCDC, indicaban que
la plataforma que ellos utilizaban estaba basada en un sistema con Open-WRT, siendo
comprobado posteriormente al encontrar documentación al respecto en los repositorios de
su sitio web.
Figura 59: Logotipo Open-WRT
4.1.2
Primeros Pasos con Open-WRT
Los pasos seguidos para configurar OpenWRT en el dispositivo AlixBoard han sido la
instalación una imagen genérica en una CF compatible, configuración e instalación de los
paquetes necesarios para su correcto funcionamiento en un esquema de dos entidades en
la que una actua como estación y otra como punto de acceso.
4.1.2.1
Instalación Open-WRT en CF
Para poder instalar OpenWRT en una CF compatible es necesario en primer lugar
114
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
formatear la propia CF a ext2. Puede usarse cualquier herramienta como gparted, o fdisk.
Tras esto descargar la distribución de OpenWRT desde su página oficial (openwrt.org)
adecuada para la arquitectura del dispositivo, en este caso x86.
http://downloads.openwrt.org/backfire/10.03.1-rc4/x86/openwrtx86-generic-rootfs-ext2.img.gz
Se ha instalado la versión oficial más estable hasta la fecha OpenWRT-Backfire 10.03.1-rc4.
Este tipo de imagen es genérica para dispositivos x86 con algunos paquetes instalados y
algunas herramientas, puede que, como ha pasado en este proyecto, sea necesario instalar
elementos que faltan en la versión genérica. Puede compilarse una imagen personalizada
con las herramientas y paquetes que se requieran descargando las fuentes del Builtroot
OpenWRT:
http://downloads.openwrt.org/backfire/10.03.1-rc4/x86/kerneldebug.tar.bz2
Luego simplemente es necesario utilizar el comando “dd” para copiar bit a bit los datos de
la imagen en la CF con formato ext2:
dd if=./openwrt-x86-generic-rootfs-ext2.iso of=/dev/sdb
4.1.2.2
Configuración Open-WRT
El esquema de conexionado actual sería conectando el PC a la placa mediante el cable nullmodem y un cable de red y alimentando la tarjeta mediante un cable DC jack y una fuente
de alimentación a 14V sin limitación en intensidad, ya que al instalar las tarjetas
inalámbricas ésta se dispara pudiendo producir cortes de alimentación si llegase al límite.
Figura 60: Esquema de Conexionado para el Trabajo con AlixBoard3D2
115
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Es necesario tener un terminal con el puerto serie abierto para monitorizar lo que pasa al
alimentar la tarjeta, ya que si hubiera algún tipo de fallo no sería posible detectarlo de otra
manera. Una vez que el sistema ha sido arrancado de forma correcta y no ha arrojado
ningún error, ya es posible trabajar con él. Para terminar de configurarlo es necesario
descargar e instalar nuevos paquetes que posibiliten las comunicaciones inalámbricas y
editar los archivos de configuración de los mismos.
4.1.2.3
Instalación de Paquetes
El primer paso que se realiza es la habilitación de la entrada inalámbrica Ethernet para
poder transferir los datos a la tarjeta, ya que de forma inicial la encontraremos
deshabilitada o desconfigurada. Se tienen dos opciones; la primera opción: conectar la
tarjeta a un router que posea un servidor DHCP y nos otorgue una dirección válida en la
red o crear un servidor DHCP en el PC, si la conectamos como en el esquema de la ¡Error!
No se encuentra el origen de la referencia., que nos provea de lo mismo. La segunda
opción sería, configurar una IP válida dentro de la red o conforme al PC al que se
encuentre conectado:
ifconfig eth0 192.168.0.3 netmask 255.255.255.0 up
Ahora desde un terminal en el PC es posible conectarse a la placa mediante SSH y
transferir los paquetes necesarios por SCP o introducir directamente la dirección IP si se
tuviera habilitado la compartición de internet o el acceso por un router. La conexión por
SSH se realiza de la siguiente manera:
ssh [email protected]
La transferencia por SCP:
scp ./Ruta_paquete_PC/PAQUETE.ipk
[email protected]:Ruta_paquete_Alix/PAQUETE.ipk
La instalación de un paquete en la placa:
opkg install PAQUETE.ipk
Los paquetes que son necesarios para configurar la red inalámbrica son los siguientes:
Tabla 45: Paquetes Open-WRT Previos a Instalar
wireless-tools_29-4_x86.ipk
kmod-madwifi_2.6.32.25+r3314-4_x86.ipk
kmod-cfg80211_2.6.32.25+2010-10-19-1_x86.ipk
Se descargan e instalan los paquetes anteriores que se pueden encontrar en la siguiente
dirección:
http://downloads.openwrt.org/backfire/10.03.1-rc4/x86/packages/
116
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Ahora es necesario conectar las tarjetas inalámbricas mini-PCI elegidas para el desarrollo
del protocolo WAVE y reiniciar el sistema. Estas tarjetas soportan los protocolos 802.11abg
y posee un chipset Atheros AR5414, el cual según los proyectos europeos consultados es el
más versátil y configurable para su modificación hacia WAVE. Para poder configurar las
interfaces de red, el firewall, etc. es necesario editar algunos archivos, los cuales se listarán
más adelante junto con su configuración, con el editor de textos instalado por defecto en la
placa VI/VIM.
4.1.2.4
Configuración Punto de Acceso
Aquí se recogen a modo de ejemplo, la configuración de una de las placas como punto de
acceso.

NETWORK
El primer archivo a configurar será “network” situado en la ruta:
/etc/config/network
Este archivo permite configurar cada interfaz y agruparla según su rol, permitiendo
“puentearlas” para facilitar su configuración. El archivo utilizado queda:
################################################################
###
# archivo /etc/config/network
#
# Autor: Jose M. León Coca
#
################################################################
###
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
config 'interface' 'lan'
option 'proto' 'static'
option 'ifname' 'eth0'
option 'ipaddr' '192.168.0.3'
option 'netmask' '255.255.255.0'
option 'gateway' '192.168.0.1'
option 'defaultroute' '0'
option 'peerdns' '0'
config 'interface' 'wifi'
option 'proto' 'static'
option 'ifname' 'ath0'
option 'ipaddr' '192.168.1.1'
option 'netmask' '255.255.255.0'
config 'interface' 'wan'
option 'ifname' ' '
option 'proto' 'none'
117
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

WIRELESS
El archivo “wireless” permite configurar las interfaces inalámbricas, situado en:
/etc/config/wireless
En este archivo se puede configurar el canal, el nombre de la red, el tipo de encriptación
(para este proyecto se ha dejado la red abierta, sin seguridad)…
################################################################
###
# archivo /etc/config/wireless
#
# Autor: Jose M. León Coca
#
################################################################
###
config wifi-device wifi0
option type
atheros
option channel 160
config wifi-iface
option device
wifi0
option network wifi
option mode
ap
option ssid
ppwifi
option encryption
none
4.1.2.5
Configuración Estación-Cliente
Aquí se recogen a modo de ejemplo, la configuración de una de las placas como
estación/cliente del punto de acceso anterior.

NETWORK
Como en el apartado anterior, el primer archivo a configurar será “network” situado en:
/etc/config/network
################################################################
###
# archivo /etc/config/network
#
# Autor: Jose M. León Coca
#
################################################################
###
118
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
config 'interface' 'lan'
option proto dhcp
option 'ifname' 'eth0'
config 'interface' 'wifi'
option 'proto' 'dhcp'
option ifname
ath0

WIRELESS
El archivo “wireless” de igual manera que en la otra placa, situado en:
/etc/config/wireless
################################################################
###
# archivo /etc/config/wireless
#
# Autor: Jose M. León Coca
#
################################################################
###
config wifi-device wifi0
option type
atheros
option channel 160
config wifi-iface
option device
wifi0
option network wifi
option mode
sta
option ssid
ppwifi
option encryption
none
Realizado este primer esquema de comunicaciones básico puede procederse al siguiente
paso con las placas, modificar los drivers necesarios para que implementen el protocolo de
comunicaciones 802.11p y realizar según el estándar ISO-CALM un protocolo de
comunicaciones que permita la implementación de aplicaciones de seguridad para
entornos vehiculares.
119
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Fue todo un acierto dar con una implementación similar a lo que se quiere desarrollar, con
documentación y código fuente existente entre los repositorios de la iniciativa del GCDC.
Por tanto, viendo gran parte del trabajo resuelto merecía la pena estudiar todos los
archivos de la iniciativa GCDC, concretamente el proyecto SPLIT (Strategic Platform for
ITS).
Actualmente, ya se ha conseguido generar un firmware GCDC con las herramientas y
librerías necesarias para comenzar a trabajar en el desarrollo de una aplicación que utilice
el protocolo de comunicaciones CALM-FAST.
4.1.3
Modo GCDC
Una vez conseguido e instalado el firmware diseñado por el GCDC, tenemos acceso a una
serie de herramientas como son el demonio CALMd que implementa el protocolo CALMFAST que provee un socket “en crudo” para comunicarse con otra entidad pareja.
Éstos son los comandos que hay que teclear para configurar la plataforma inicialmente:
iw reg set NL
ifconfig wlan0 down
iwconfig wlan0 mode ad-hoc
ifconfig wlan0 up
iw dev wlan0 ibss leave
iw dev wlan0 ibss join ITS 5890 fixed-freq 00:00:00:00:00:00
beacon 0

Dado que la iniciativa GDCD se realizaba en los países bajos, en primer lugar
se establece como dominio regulador los Países Bajos (NL). Esto es debido a
que la base de datos correspondiente a los países bajos ya ha sido modificada
para transladar en frecuencia la banda en la que se permite por defecto
transmitir a la tarjeta.

A continuación, se configura la interfaz en modo ad-hoc, para lo que hay que
deshabilitarla.

Finalmente se selecciona la frecuencia de ITS y una dirección fija IBSS. El
intervalo de baliza se ajusta a cero, indicando que no hay balizas WLAN en
absoluto.
Se han realizado pocas pruebas todavía para asegurar que la plataforma funciona como
debiera pero por ahora todas las realizadas arrojan resultados satisfactorios y dos
entidades correctamente configuradas son capaces de comunicarse entre sí, de verse
mandando beacons.
120
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
4.2 Integración SmartPhone
Esta parte del proyecto tendrá como objetivo, en esta primera versión, mostrar al usuario
los datos que permitan la monitorización del sistema: datos recolectados del vehículo,
mensajes importantes CALM-FAST, etc. Los elementos funcionales de la arquitectura del
proyecto que se tienen en cuenta para este documento son el Mobile Router y el HMI,
entre los que se establecerá un enlace Bluetooth para la comunicación entre ambos.
Figura 61: Comunicación HMI y Vehicle Host
Los dispositivos que permitirán la comunicación por Bluetooth en cada una de las
entidades son un dongle Bluetooth Clase 2, conectado al puerto USB de la placa AlixBoard
3D2. Y el propio dispositivo Bluetooth integrado de la Galaxy Tab, dispositivo con
múltiples posibilidades de conexión. Lo que permite que en las siguientes versiones de la
aplicación, se pueda sopesar la posibilidad de elegir otra forma de comunicación como por
ejemplo WiFi. En el siguiente apartado se presentan más en profundidad estos dos
dispositivos y se muestran las características más destacadas de cada uno. Cabe destacar
que la comunicación presentará un esquema cliente (HMI) / servidor (Mobile Router),
dadas las características de cada uno, en la HMI será necesario crear el cliente en un
entorno basado en Android y en el Mobile Router un servidor en un entorno Linux.
4.2.1
Creación Aplicación Servidora
Para realizar la aplicación servidora se hará en un entorno Linux, por comodidad de
desarrollo y utilizando el IDE Eclipse para desarrolladores en C/C++. Se realizará el
desarrollo utilizando la librería BlueZ que nos permitirá establecer una comunicación
Bluetooth emulando un puerto serie implementando el modo de comunicación RFCOMM:
121
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 62: Pila de
comunicaciones
Bluetooth
Su programación será similar a la de programar un servidor basado en socket TCP, ya que
esta librería permite realizar de ésta manera la asociación de la comunicación abierta con la
otra entidad bluetooth. La única peculiaridad reside en el modo que tiene la tecnología
bluetooth de establecer las comunicaciones entre dispositivos, en general siguen el
siguiente esquema, el cual conociendo información se puede simplificar:

Activación de modo pasivo.

Búsqueda de puntos de acceso.

Sincronización con los puntos de acceso.

Descubrimiento del servicio del punto de acceso.

Creación de un canal con el punto de acceso.

Emparejamiento mediante el PIN (seguridad).

Utilización de la red.
Por tanto el esquema de programación utilizado será el siguiente:

Configuración inicial del dispositivo.

Búsqueda del punto de acceso.

Conexión RFCOMM.

Inicio de la aplicación, envío de los datos de información del sistema.
Gracias al proyecto AudioZity, esta aplicación prácticamente está resuelta. Siendo
simplemente necesaria su modificación para conseguir crear un servidor bluetooth.
4.2.2
Creación Aplicación Cliente
Para realizar esta aplicación sera necesario instalar las herramientas de desarrollo de
Android (ADT-Android Developers Tools) directamente desde su sitio web o añadir la
funcionalidad a Eclipse instalando el plug-in correspondiente. Dependiendo de la versión
del firmware instalado en la tableta, las APIs de programación de google cambian, es un
punto a tener en cuenta ya que puede ocasionar que la aplicación sea incompatible. Cada
vez que aparece una nueva versión, las bases se mantienen, pero cambia la interfaz. Dentro
del sistio web para desarrolladores pueden encontrarse multitud de tutoriales y manuales,
incluidos los primeros pasos iniciarse en la programación de Android. La programación
122
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
que se realiza se hace mediante una interfaz gráfica, en la que se pinta el marco de la
aplicación, botonera, etc. Y luego se configura la funcionalidad de cada uno de esos
botones. El problema de la programación en Android, es que no se configura mediante un
lenguaje conocido, sino que ha de programarse aprendiendo sus APIs y funciones. En la
siguiente figura puede verse el núcleo de Android:
Figura 63: Capas y Núcleo Android
Es por tanto necesario utilizar una API distinta dependiendo de las características a utilizar
por la aplicación. Además éstas han de ser “autorizadas”, he incluidas en un fichero
llamado manifiesto, que el usuario final ha de aceptar.
Actualemente, esta aplicación aún se encuentra en desarrollo, presentando algunos
problemas al establecer el canal RFCOMM con la entidad servidora, imposibilitando el
envío de información.
4.3 Red Interna del Vehículo
Esta parte del proyecto trata sobre la creación de la red de comunicaciones interna del
vehículo, basándonos en los estándares utilizados en la industria del automóvil, es por ello
que se desea crear una infraestructura basada en un bus de comunicaciones CAN. Para el
desarrollo de este proyecto se ha decidido comenzar con la fabricación de dos
sensores/actuadores genéricos basados en los microcontroladores AT90CAN128.
Posteriormente, el futuro de esta red interna implementará tres buses de comunicaciones,
tal y como suele hacerse en la industria, generará mensajes bajo protocolo de
comunicaciones OBD-II para dar información al PC de Abordo e implementará una
jerarquía de mensajes que permita dar prioridad a los mensajes dirigidos a la ECU o a los
elementos de control. Actualmente este proyecto se encuentra en la primera fase de
desarrollo, es decir se están desarrollando los programas que permitan crear los primeros
elementos sensores y actuadores del sistema.
4.3.1
Creación de los Sensores/Actuadores
Lo primero en comentar es que para poder trabajar con los microcontroladores es disponer
del kit de desarrollo, necesario para poder programarlos, como mínimo, e incluso poder
realizar el “debugging” para depurar el programa realizado. El kit de desarrollo heredado
disponible en el grupo de investigación es el STK500, más la placa de expansion STK501
para dispositivos SMD. Combinados con la adquisición del dispositivo ATADAPCAN01,
un elemento que permite conectar directamente uno de los puertos de comunicaciones del
STK a un transceiver CAN. Además de estos elementos, para poder disponer de más de
123
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
un dispositivo de desarrollo se decidió adquirir los diseños de desarrollo de Olimex: AVRH128-CAN.
Figura 64: (a) Combinación STK500+STK501 (b) AVR-H128-CAN
Para comenzar el desarrollo es necesario instalar las herramientas software que facilita el
fabricante, el AVR-Studio. En general son herramientas fáciles de instalar y de utilizar,
basadas en el entorno de desarrollo Eclipse con una interfaz muy parecida de uso. El
problema es que ATMEL trata de descatalogar la STK500 por modelos superiores y por
ello hace que las versiones más actuales de AVR carezcan del soporte para la STK500
impidiendo su visualización por defecto.
4.3.2
Soporte STK500 en Versiones Actuales de AVR-Studio
El dispositivo STK500 es perfectamente compatible con el nuevo software AVR-Studio, por
ejemplo su versión número 6. Este entorno de desarrollo niega el soporte a la STK500
restringiendo el número de micros que puede programar, para solucionar esto, hay que
añadir en la carpeta:
C:\Program Files\Atmel\Atmel Studio 6.0\tools\STK500\xml\
El documento XML del micro en cuestión que se quiera programar, para ello y siguiendo
como patrón un XML de uno de los micros que ATMEL añade a la STK500. Simplemente
habrá que modificar el archivo y cambiarle el nombre de forma adecuada. En el caso de
desarrollo AT90CAN128.
124
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
<?xml version="1.0" encoding="UTF-8"?>
<avr-tools-part-file
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../schema/avr_tools_part_file.
xsd">
<devices>
<device name="AT90CAN128">
<tools>
<tool name="STK500"
type="com.atmel.avrdbg.tool.stk500"/>
</tools>
</device>
</devices>
</avr-tools-part-file>
Guardándolo como “AT90CAN128_stk500.xml”, de ésta manera el sistema reconocerá el
dispositivo y podremos programar el microcontrolador situado en la STK501.
NOTA: Conectar el programador ICSP de la STK500 al puerto de la STK501
4.3.3
Test CAN
Bajo el pseudónimo de ACETICAN, se han realizado una serie de diseños de PCB para el
testeo y el desarrollo de los microcontroladores con dispositivo CAN de ATMEL en el
grupo de investigación ACE-TI. El diseño que se ha realizado hasta la fecha para el
proyecto es la placa Test CAN que proporciona una configuración de tres transceiver
MCP2551 que permiten la entrada a un bus CAN según el siguiente esquema:
Figura 65: Esquemático Test CAN
125
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Para realizar el PCB se ha utilizado el software de diseño profesional Altium, siendo el
resultado el siguiente fotolito PCB:
Figura 66: Fotolito Test CAN
El tamaño de la placa ha sido el suficiente para poder enrollar tramos de un metro de cable
entre cada transceiver de manera que su curvatura no fuera demasiado pronunciada.
Actualemente, los sensores siguen estando en desarrollo, se ha decidido utilizar las
126
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
librerías CANary de forma desacertada, ya que carece del soporte suficiente y no permite
un control total sobre la interfaz CAN y su forma de envío de mensajes. Aún así se han
podido realizar las primeras retransmisiones CAN para testear que el sistema funciona de
forma correcta y que, por ejemplo, no era necesario la adaptación de impedancias de forma
individual por cada nodo.
4.4 PC de Abordo
Para poder trabajar con el ordenador de abordo, el fabricante iEiMobile facilita junto con el
dispositivo un CD con las APIs de programación del mismo. Estas APIs proveen de varias
funcionalidades, aunque con una documentación muy escueta y muchas veces incorrecta.
Figura 67: Demostración APIs iKarPC
Las APIs de programación se basan en las MFC (Microsoft Foundation Classes), siendo
necesario para trabajar con éstas realizarlo en un entorno Windows con el IDE Visual
Studio de Microsoft. Otro de los problemas encontrados con las APIs es que los archivos
de soluciones se encuentran portados directamente y muchas de las veces las carpetas y
nombres de referencia aparecen en chino. La interfaz de programación de Visual Studio es
también una programación gráfica de escritorio, con el inconveniente de tener en cuenta
los tipos de datos heredados de cada una de las distintas versiones de Microsofr. La API
programada y testeada hasta la fecha, ha sido la referente al sistema GPS integrado en el
iKarPC:
127
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
Figura 68: Programación GPS iKarPC
128
Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico
5 CONCLUSIONES Y TRABAJO FUTURO
L
as conclusiones que pueden extraerse de este trabajo, son nada mas y nada menos,
que el proyecto se encuentra vivo y en desarrollo. Como se comentaba al principio,
cada una de las partes sólo se encuentra en sus inicios, pero va tomando forma y
permitiendo crear sobre ellas todo lo necesario. Creo que cabe destacar que las tecnologías
asociadas en cada parte del trabajo que se realiza son útiles y actuales en el mundo
profesional, industrial e incluso académico: Android, Visual Studio, CAN, WAVE, ISOCALM, WiFi, Bluetooth…
Aún queda mucho trabajo por hacer, finalizar los proyectos puestos en marcha para poder
establecer las bases del sistema y crear una aplicación global que integre todas las áreas de
trabajo. Para ello será necesario establecer unos formatos de tramas de comunicaciones
comunes entre las partes, que permitan el flujo de la información de una a otra entidad.
Otro de los retos importantes será la creación de sensores mucho más específicos para el
vehículo, que permitan frenar, seguir las líneas de la carretera. Y lo que es más complicado
crear los algoritmos que permitan manejar de forma correcta y automática esa
información.
Para finalizar, comentar que para este autor es todo un lujo que un proyecto que sólo
imaginaba cuando estudiaba las comunicaciones vehiculares, tome forma y llegue a
realizarse, agradecer nuevamente a Federico la libertad que me dio para realizarlo.
129
REFERENCIAS
[1].
Handwerk, Brian. “Half of Humanity Will Live in Cities by Year’s End.” National Geographic News. 13
de marzo de 2008. Disponible en: http://news.nationalgeographic.com/ news/2008/03/080313-cities.html
[2].
Mobility 2030: Meeting the challenges to sustainability.” The Sustainable Mobility Project. World
Business Council for Sustainable Development. Diciembre de 2004.
[3].
Carisma, Brian y Sarah Lowder. “Economic Costs of Traffic Congestion: A Literature Review for
Multiple Locations.” 2008.Disponible en: http://greenconsumerism.net/wp-content/uploads/2008/08/thecost-of-trafficcongestion.pdf
[4].
Informe Sociedad Española de Neumología y Cirugía Torácica (SEPAR) 2009
[5].
COM(2008) 886 final. Disponible en: http://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52008DC0886:ES:NOT
[6].
Los Sistemas Inteligentes de Transporte. Su aplicación a los modos terrestre, marítimo y aéreo. 2009.
http://www.fomento.gob.es/NR/rdonlyres/7595AD41-7687-4850-A568-D0EC56379CF9/72310/SIT_opt.pdf
[7].
K. Selvarajah, A. Tully, P.T. Blythe, “ZigBee for Intelligent Transport System applications”, IET Road
Transport Information and Control - RTIC 2008 and ITS United Kingdom Members' Conference, 2008, pp. 1-7.
[8].
S. L. Toral, M. R. Martínez-Torres, F. Barrero, M. R. Arahal, “Current Paradigms in Intelligent
Transportation Systems”, IET Intelligent Transport Systems, Vol. 4, Iss. 3, 2010, pp. 201-211.
[9].
M.R. Martínez-Torres, C. Díaz, S. L. Toral, F. Barrero, “Identification of New Added Value Services on
Intelligent Transportation Systems”, Behaviour and Information Technology, en prensa, DOI:
10.1080/0144929X.2010.529942.
[10]. S. L. Toral, M. Vargas, F. Barrero, “Embedded Multimedia Processors for Road-Traffic Parameter
Estimation”, Computer, Vol. 42, no. 12, 2009, pp. 61-68.
[11].
2004.
D. Cook, S. Das, Smart Environments: Technology, Protocols and Applications, Wiley-Interscience
[12]. E.M. Royer y C. Toh. A Review of Current Routing Protocols for Ad Hoc Mobile Wireless Networks.
IEEE Personal Communications. Vol. 6, 46-55. 1999.
[13].
Bluetooth en Wikipedia: http://es.wikipedia.org/wiki/Bluetooth
[14]. PATH Website, “Official web site of the PATH project” Website, August 2013, also available as
http://www.path.berkeley.edu/Default.htm
[15]. Web resource, "PATH 2009 Annual Report", August 2013, also available as
http://www.path.berkeley.edu/Data-Files/Annual_Reports/PATH-2009-Annual-Report.pdf.
[16]. Ram Kandarpa, Mujib Chenzaie, Justin Anderson, Jim Marousek, Tim Weil, Frank Perry, Ian Schworer,
Joe Beal, Chris Anderson (2009). "Final Report: Vehicle Infrastructure Integration Proof of Concept Results and
Findings - Infrastructure". May 2009. Research and Innovative Technology Administration (RITA) - U.S.
Department of Transportation.
[17]. Sheryl Miller, Jennifer Rephlo, Christopher Armstrong, Keith Jasper, Gary Golembiewski (2011),
"National Evaluation Of The Safetrip-21 Initiative: Combined Final Report", March 2011, Science Applications
International Corporation (SAIC).
[18]. Jessica Hector-Hsu, Gary T. Ritter, Suzanne Sloan, Laura Waldon, Philip Thornton, Katherine Blythe
(2011), "SafeTrip-21 — Federal ITS Field Tests to Transform the Traveler Experience", June 2011, John A. Volpe
National Transportation Systems Center, ITS Joint Program Office.
[19].
Safety Pilot Project Website available at http://safetypilot.umtri.umich.edu/
[20]. ITS Newsleter August 2013 available at
http://www.its.dot.gov/newsletter/PDF/Newsletter_august_V19.pdf
[21].
Picture available at http://www.umtri.umich.edu/content/SafetyPilot_map.JPG
[22]. Mike Schagrin. "Safety Pilot Final Fact Sheet". ITS Joint Program Office, Research and Innovative
Technology Administration. Available at http://www.its.dot.gov/factsheets/pdf/SafetyPilot_final.pdf
[23]. eSafety sitio web disponible en:
http://ec.europa.eu/information_society/activities/esafety/index_en.htm
[24]. Information Society Technologies (2002). "Research on Integrated Safety Systems for Improving Road
Safety in Europe - The Information Society Technologies (IST) programme 1998-2002". Septiembre 2002.
Luxembourg: Office for Official Publications of the European Communities.
[25]. Council, European Parliament (2010). "Directive 2010/40/EU of the European Parliament and of the
Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of
road transport and for interfaces with other modes of transport Text with EEA relevance". Agosto 2010.
Official Journal of the European Un-ion.
[26].
iMobilitysupport sitio web disponible en: http://www.imobilitysupport.eu
[27]. Lina Konstantinopoulou, Zwijnenberg Han, Susanne Fuchs, Doris Bankosegger. "White paper:
Deployment Challenges for Cooperative Systems". Disponible en:
http://www.cvisproject.org/download/Deliverables/White%20paper_Cooperative%20Systems%20Deployme
nt.pdf
[28].
CVIS sitio web disponible en: http://www.cvisproject.org/
[29].
Imagen disponible en: http://www.cvisproject.org/en/cvis_subprojects/technology/comm.htm
[30].
SAFESPOT sitio web disponible en: http://www.safespot-eu.org/
[31]. Documento disponible en:
http://ec.europa.eu/information_society/activities/esafety/doc/esafety_2006/spectrum_28feb2006/6_safes
pot_applications.pdf
[32].
Imagen disponible en: http://www.safespot-eu.org/images/sub_projects.jpg
[33].
COOPERS sitio web disponible en: http://www.coopers-ip.eu/
ÍNDICE DE FIGURAS
Figura 1: Logotipo Grupo de Investigación ACE-TI
13
Figura 2: Arquitectura Vehículo Eléctrico
14
Figura 3: Transporte de Personas por Regiones del Mundo
15
Figura 4: Número de Secciones de Control Puestas en Producción por año
17
Figura 5: Entorno Urbano Inteligente
18
Figura 6: Esquema Bluetooth
20
Figura 7: Pila de Protocolos Bluetooth
21
Figura 8: Comparación 802.11a y 802.11p ¡Error! No se encuentra el origen de la referencia.
23
Figura 9: Pila de Protocolos WAVE
24
Figura 10: Ejemplo de un Sistema WAVE y sus Componentes
27
Figura 11: Distribución Frecuencial reservada a ITS
28
Figura 12: Arquitectura de ISO CALM
29
Figura 13: Arquitectura de la Red Interna del Vehículo
31
Figura 14: Esquema de comunicaciones internas de SEAT Altea basado en Bus CAN
32
Figura 15: Niveles de los Buses en Baja Velocidad
33
Figura 16: Colocación del bus en Baja Velocidad
33
Figura 17: Niveles de los buses en Alta Velocidad
33
Figura 18: Configuración del bus en Alta Velocidad
34
Figura 19: Arbitraje del Bus CAN
37
Figura 20: Formato de la trama de datos
38
Figura 21: Formatos de Tramas Normal y Extendida
39
Figura 22: Formato de Trama Remota
39
Figura 23: Formato de la Trama de Error
40
Figura 24: Relleno de Bits
41
Figura 25: Formato de la Trama de Sobrecarga
41
Figura 26: (a) PinOut 8051 (b) Bloques Básicos 8051
45
Figura 27: Arquitectura Interna 8051
45
Figura 28: Diagrama Funcional Entidad CAN
46
Figura 29: Esquema de Bloques SJA1000
47
Figura 30: Buffer de Recepción Modo BasicCAN
59
Figura 31: Ejemplo de Pérdidas de Arbitraje
71
Figura 32: Distribución General del Buffer de Transmisión
76
Figura 33: Buffer de Recepción para el modo PeliCAN
79
Figura 34: Filtro de Aceptación PeliCAN. Modo Simple y Tramas Estándar
80
Figura 35: Filtro de Aceptación PeliCAN. Modo Simple y Trama Extendida
80
Figura 36: Filtro de Aceptación PeliCAN. Modo Dual y Tramas Estándar
81
Figura 37: Filtro de Aceptación PeliCAN. Modo Dual y Tramas Extendidas
82
Figura 38: Estructura General de un periodo de bit
84
Figura 39: Logica Empleada en el Transceptor
85
Figura 40: Ejemplo del Clock Output Mode
86
Figura 41: Ejemplo de Bi-phase Output Mode
86
Figura 42: Plano del Modelo de Despliegue de Safety Pilot [21]
91
Figura 43: Distintas Visiones de los Proyectos CVIS, COOPERS y SAFESPOT
92
Figura 44: Arquitectura CVIS [29]
93
Figura 45: Subproyectos SAFESPOT [32]
94
Figura 46: Escenario GCDC
95
Figura 47: Arquitectura CVIS
97
Figura 48: OBU Elementos Embarcados en Vehículo
98
Figura 49: Arquitectura del Demostrador
99
Figura 50: AlixBoard 3D2 (Superior/Inferior)
100
Figura 51: MikroTik R52H
101
Figura 52: Dongle Bluetooth Conceptronic
102
Figura 53: iKarPC
103
Figura 54: MSK28335 con Adaptación de Señales
106
Figura 55: Samsung Galaxy Tab 7”
108
Figura 56: Arquitectura interna RSU
109
Figura 57: Arquitectura RSU del Demostrador
110
Figura 58: Resumen OBU
111
Figura 59: Logotipo Open-WRT
114
Figura 60: Esquema de Conexionado para el Trabajo con AlixBoard3D2
115
Figura 61: Comunicación HMI y Vehicle Host
121
Figura 62: Pila de comunicaciones Bluetooth
122
Figura 63: Capas y Núcleo Android
123
Figura 64: (a) Combinación STK500+STK501 (b) AVR-H128-CAN
124
Figura 65: Esquemático Test CAN
125
Figura 66: Fotolito Test CAN
126
Figura 67: Demostración APIs iKarPC
127
Figura 68: Programación GPS iKarPC
128
ÍNDICE DE TABLAS
Tabla 1: Clases de Transmisión Buetooth
20
Tabla 2: Familia de Protocolos IEEE 802.11
22
Tabla 3: Velocidades CAN Según Bus
34
Tabla 4: Pines correspondientes a las señales usadas por la entidad CAN
46
Tabla 5: Señales del controlador SJA1000
47
Tabla 6: Direccionamiento BasicCAN
50
Tabla 7: Registro de control BasicCan
51
Tabla 8: Registro de comando
53
Tabla 9: Registro de estado
54
Tabla 10: Registro de Interrupciones
56
Tabla 11: Buffer de Transmisión
57
Tabla 12: Registro de código de aceptación
59
Tabla 13: Registro de máscara de aceptación
59
Tabla 14: Distribución de direcciones en Pelican
60
Tabla 15: Registro de modo
63
Tabla 16: Registro de comando
65
Tabla 17: Registro de estado
66
Tabla 18: Registro de Interrupciones
68
Tabla 19: Registro de habilitación de Interrupciones
69
Tabla 20: Registro de captura de pérdidas por arbitraje
70
Tabla 21: Función del registro de captura del “Arbitration Lost Capture Register”
71
Tabla 22: Registro de captura de pérdidas por arbitraje
73
Tabla 23: Interpretación de los bits ECC.7 y ECC.6
74
Tabla 24: Diferentes bits que se muestran en el ECC para identificar los distintos tipos de error 74
Tabla 25: Campo de descripción para SFF
77
Tabla 26: Campo de descripción para EFF
77
Tabla 27: Interpretación de los bits FF y RTR
77
Tabla 28: Campo de descripción para SFF en RX Buffer
78
Tabla 29: Campo de descripción para EFF para el RX Buffer
78
Tabla 30: Bus Timming Register 0
83
Tabla 31: Bus Timming Register 1
83
Tabla 32: Registro de control de salida
84
Tabla 33: Interpretación de los bits OCMODE
85
Tabla 34: Configuración de los pines de salida
86
Tabla 35: Clock Divider Register
87
Tabla 36: Posible elección de frecuencia de CLKOUT
87
Tabla 37: Caracteristicas AlixBoard 3D2
100
Tabla 38: Características MikroTik R52H
102
Tabla 39: Caracteristicas Dongle Bluetooth
103
Tabla 40: Características iKarPC
104
Tabla 41: Caracteristicas MSK28335
106
Tabla 42: Características AT90CAN128
107
Tabla 43: Características MCP2551
107
Tabla 44: Características Samsung Galaxy Tab 7”
108
Tabla 45: Paquetes Open-WRT Previos a Instalar
116