Trabajo Final de Máster en - bibing.us.esbibing.us.es/proyectos/abreproy/70452/fichero/TFM_JMLC.pdf · 2.3.1 Microcontrolador 8051 44 ... 4.3.2 Soporte STK500 en Versiones Actuales

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

Departamento de Ingeniería Electrónica

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2013

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

v

A mi prima María,

A mi tía Mili,

Y a mi Padre, nuevamente, Ella

estaría orgullosa.

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

viii

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

ix

Índice

Agradecimientos vi

Resumen vii

Abstract viii

Índice ix

Siglas y Acrónimos xi

1 Introducción 13

2 Marco tecnológico 15 2.1 Comunicaciones Inalambricas para ITS 17

2.1.1 Bluetooth 19 2.1.2 IEEE 802.11 22 2.1.3 WAVE 24 2.1.4 Tecnologías Adaptadas por ISO CALM 28

2.2 Comunicación Interna del Vehículo 31 2.2.1 Protocolo CAN 31 2.2.2 OBD II 42

2.3 Estudio Controlador CAN Stand Alone 44 2.3.1 Microcontrolador 8051 44 2.3.2 Controlador SJA1000 46 2.3.3 Registros Controlador CAN 48 2.3.4 Modo PeliCan. 60 2.3.5 Registros comunes 83

2.4 Proyectos ITS 89 2.4.1 Proyectos ITS Americanos 89 2.4.2 Proyectos ITS Europeos 91

3 Arquitectura y Elementos del Sistema 97 3.1 OBU 98

3.1.1 Arquitectura Base 98 3.1.2 Arquitectura del Demostrador 98 3.1.3 Mobile Router 99 3.1.4 Vehicle Host 103 3.1.5 Vehicle Gateway 105 3.1.6 Human Media Interface 107

3.2 RSU 109 3.2.1 Arquitectura Base 109 3.2.2 Arquitectura del Demostrador 110

4 Trabajo Realizado 111 4.1 Red Externa del Vehículo 112

4.1.1 Elección Sistema Operativo para Mobile Router 112 4.1.2 Primeros Pasos con Open-WRT 114 4.1.3 Modo GCDC 120

4.2 Integración SmartPhone 121 4.2.1 Creación Aplicación Servidora 121 4.2.2 Creación Aplicación Cliente 122

4.3 Red Interna del Vehículo 123 4.3.1 Creación de los Sensores/Actuadores 123 4.3.2 Soporte STK500 en Versiones Actuales de AVR-Studio 124 4.3.3 Test CAN 125

4.4 PC de Abordo 127

5 Conclusiones y Trabajo Futuro 129

Referencias 131

Índice de Figuras 133

Índice de Tablas 135

Siglas y Acrónimos

CEN European Committee for Standardization

CENELEC European Committee for Electrotechnical Standardization

CEPT European Conference of Postal and Telecommunications Administrations

EN European Norm

ES ETSI Standard

ESO European Standardization Organization

ETSI European Telecommunications Standards Institute

FCC Federal Communications Commission

GPS Global Positioning System

ITS Intelligent Transport System

ITS-G5 ITS-G5 Set of protocols and parameters in the ETSI Standard ES 202 663

MAC Medium Access Control

NSO National Standards Organization

OFDM Orthogonal Frequency-Division Multiplexing

PHY Physical

STA Station

TC Technical Committee

UMTS Universal Mobile Telecommunications System

WAVE Wireless Access in Vehicular Environments

WiFi Brandname of the Wi-Fi Alliance, normally used with IEEE 802.11

WiMAX Worldwide Interoperability for Microwave Access, used with IEEE 802.16

WG Work Group

WLAN Wireless Local Area Network

13 Implantación de Nuevas Tecnologías de los Sistemas Inteligentes de Transporte en un Vehículo Eléctrico

1 INTRODUCCIÓN

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.

E

Figura 1: Logotipo Grupo de Investigación ACE-TI


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:

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.

Figura 2: Arquitectura Vehículo Eléctrico


2 MARCO TECNOLÓGICO

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.

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

D

Figura 3: Transporte de Personas por Regiones del Mundo


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.


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

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ículo-infraestructura (V2I) y vehículo-vehículo (V2V) y vehículo-persona (V2P). Cuando se

Figura 4: Número de Secciones de Control Puestas en Producción por año


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.

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.

Figura 5: Entorno Urbano Inteligente

http://www.cvisproject.org/

http://www.safespot-eu.org/pages/page.php

http://www.coopers-ip.eu/


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


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.

Los pasos que llevan a cabo los dispositivos para su interconexión son:

Activación de modo pasivo.

Figura 6: Esquema Bluetooth


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)

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

Figura 7: Pila de Protocolos Bluetooth


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


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.

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

Figura 8: Comparación 802.11a y 802.11p ¡Error! No se encuentra el origen de la referencia.


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.

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:

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

2.1.3.2 IEEE 1609.4

Es una extensión al estándar IEEE 802.11p con el objetivo de lograr una operación del

Figura 9: Pila de Protocolos WAVE


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.


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,


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:

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

Figura 10: Ejemplo de un Sistema WAVE y sus Componentes


de transporte siguien siendo un poco diferentes, dejando sin servicio a algunos canales:

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.

Figura 11: Distribución Frecuencial reservada a ITS


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

Figura 12: Arquitectura de ISO CALM


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.

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.

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


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:

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

Figura 13: Arquitectura de la Red Interna del Vehículo


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:

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

Figura 14: Esquema de comunicaciones internas de SEAT Altea basado en Bus CAN


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 100-500Ω.

Estandar 11898 (alta velocidad):

Figura 15: Niveles de los Buses en Baja Velocidad

Figura 16: Colocación del bus en Baja Velocidad

Figura 17: Niveles de los buses en Alta Velocidad


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.

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)

Baja (125Kbps)

Motor (ECU), Cambio automático

Figura 18: Configuración del bus en Alta Velocidad


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.


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.


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.

Figura 19: Arbitraje del Bus CAN


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:

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.

Figura 20: Formato de la trama de datos


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 21: Formatos de Tramas Normal y Extendida

Figura 22: Formato de Trama Remota


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.

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

Figura 23: Formato de la Trama de Error


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:

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 24: Relleno de Bits

Figura 25: Formato de la Trama de Sobrecarga


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


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


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


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.

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 26: (a) PinOut 8051 (b) Bloques Básicos 8051

Figura 27: Arquitectura Interna 8051


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.

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:

Figura 28: Diagrama Funcional Entidad CAN


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

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

Figura 29: Esquema de Bloques SJA1000


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


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 :


Tabla 6: Direccionamiento BasicCAN

Dirección CAN

Segmento Modo de Operación Modo Reset

Lectura Escritura Lectura Escritura

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

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

10 transmit

buffer

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








20 receive

buffer





21 identifier (2to 0), RTR


identifier (2to 0), RTR y DLC



y DLC DLC DLC

22 data byte 1 data byte 1 data byte 1 data byte 1








30 (FFH) - (FFH) -

31 clock divider

clock divider clock divider clock divider clock divider

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


no overrun interrupt signal.

CR.3 EIE Error Interrupt Enable 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.

CR.2 TIE Transmit Interrupt Enable

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.

CR.1 RIE Receive Interrupt Enable

1 enabled; when a message has been received without errors.

0 disabled; the microcontroller receives no transmit interrupt signal

CR.0 RR Reset Request; 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.


El desglose del registro en bits y su significado se muestra en la Tabla 8:

Tabla 8: Registro de comando


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

CMR.3 CDO Clear Data Overrun 1 clear; data overrun status bit is cleared

0 no action

CMR.2 RRB Release Receive Buffer 1 released; the receive buffer, representing the message memory

space in the RXFIFO is released

0 no action

CMR.1 AT Abort Transmission 1 present; if not already in progress, a pending transmission request is

cancelled

0 absent; no action

CMR.0 TR Transmission Request 1 present; a message will be transmitted

0 absent; no action

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


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


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

SR6 ES Error Status 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

SR5 TS Transmit Status 1 transmit; the Can controller is transmitting a message

0 idle; no transmit message is in progress

SR4 RS Receive Status 1 receive; the Can controller is receiving a message

0 idle; no receive message is in progress

SR3 TCS Transmission Complete

1 complete; the last requested transmission has been successfully

completed

0 incomplete; the previously requested


transmission is not yet completed

SR2 TBS Transmit 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

SR1 DOS Data Overrun Status 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

SR0 RBS Receive Buffer Status 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.


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


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

IR3 DOI Data Overrum interrupt

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)


IR2 EI Error Interrupt 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)


IR1 TI Transmit Interrupt 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)


IR0 RI Receive Interrupt 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)



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

7 6 5 4 3 2 1 0

10 Descriptor

Identifier byte 1

ID 10

ID9

ID8

ID7 ID6 ID5 ID4 ID3

11 Identifier byte 1

ID2

ID1

ID0

RTR

DLC.3

DLC.2

DLC.1

DLC.0

12 Data TX Data1

transmit data byte 1

13 TX Data2

Transmit data byte 2

14 TX Data3


15 TX Data4


16 TX Data5


17 TX Data6


18 TX Data7


19 TX Data8



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.


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.

Figura 30: Buffer de Recepción Modo BasicCAN


2.3.3.9 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


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 information

ESF

(Extended

Frame Format)

TX frame informatio

n SSF (Standard

Frame Format)

TX frame informatio

n ESF (Extended

Frame Format)

Acceptance code 0

Acceptance code 0

17 RX Identifier 1

RX Identifier 1

TX Identifier 1

TX Identifier 1

Acceptance code 1

Acceptance code 1

18 RX Identifier 2

RX Identifier 2

TX Identifier 2

TX Identifier 2

Acceptance code 2

Acceptance code 2

19 RX data 1 RX Identifier 3

TX data 1 TX Identifier 3

Acceptance code 3

Acceptance code 3

20 RX data 2 RX Identifier 4

TX data 2 TX Identifier 4

Acceptance mask 0

Acceptance mask 0

21 RX data 3 RX data 1 TX data 3 TX data 1 Acceptance mask 1

Acceptance mask 1


Acceptance mask 2


Acceptance mask 3

24 RX data 6 RX data 4 TX data 6 TX data 4 reserved (0x00)

-


-


-

27 (FIFO RAM)

RX data 7 - TX data 7 reserved (0x00)

-


28 (FIFO RAM)

RX data 8 - TX data 8 reserved (0x00)

-

29 RX message counter - RX message counter

-

30 RX buffer start address RX buffer start

address

RX buffer start

address

31 clock divider clock divider clock divider

clock divider

32 Internal RAM address 0 (FIFO)

- Internal RAM

address 0

Internal RAM

address 0


- Internal RAM

address 1

Internal RAM

address 1

↓


- 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


- Internal RAM

address 78

Internal RAM

address 78


- Internal RAM

address 79

Internal RAM

address 79

112 0x00 - 0x00 -

↓

127 0x00 - 0x00 -


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


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

MOD.3 AFM Acceptance Filter Mode

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)

MOD.2 STM Self Test Mode 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

MOD.1 LOM Listen Only Mode 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


current value

0 normal

MOD.0 RM Reset Mode 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.


El desglose del registro en bits y su significado se muestra en la Tabla 16.

Tabla 16: Registro de comando





CMR.4 SRR Self Reception Request 1 present; a message shall be transmitted and received

simultaneously

0 - (absent)

CMR.3 CDO Clear Data Overrun 1 clear; data overrun status bit is cleared

0 no action

CMR.2 RRB Release Receive Buffer 1 released; the receive buffer, representing the message memory

space in the RXFIFO is released

0 no action

CMR.1 AT Abort Transmission 1 present; if not already in progress, a pending transmission request is

cancelled

0 absent; no action

CMR.0 TR Transmission Request 1 present; a message will be transmitted

0 absent; no action

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


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


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

SR6 ES Error Status 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

SR5 TS Transmit Status 1 transmit; the Can controller is transmitting a message

0 idle; no transmit message is in progress

SR4 RS Receive Status 1 receive; the Can controller is receiving a message

0 idle; no receive message is in progress

SR3 TCS Transmission Complete

1 complete; the last requested transmission has been successfully completed

0 incomplete; the previously requested transmission is not yet completed

SR2 TBS Transmit Buffer 1 released; the CPU may write a message into


Status the transmit buffer

0 locked; the CPU cannot access the transmit buffer; a message is waiting for transmission

or is already in process

SR1 DOS Data Overrun Status

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

SR0 RBS Receive Buffer Status

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.


Tabla 18: Registro de Interrupciones


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

IR6 ALI Arbitration Lost Interrupt

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

IR5 EPI Error Passive Interrupt

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

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

0 reset

IR4 WUI Wake-Up Interrupt

1 set; this bit is set when the sleep mode is left


IR3 DOI Data Overrum interrupt

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)


IR2 EI Error Interrupt

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)


IR1 TI Transmit Interrupt

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)


IR0 RI Receive 1 set; this bit is set while the receive FIFO is not empty and the receive interrupt enable bit is set


Interrupt to logic 1 (enabled)


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


IER7 BEI Bus Error Interrupt Enable

1 enabled; if an bus error has been detected, the CAN controller requests

the respective interrupt

0 disabled

IER6 ALIE Arbitration Lost Interrupt Enable

1 enabled; if the CAN controller has lost arbitration, the respective interrupt is

requested

0 disabled

IER5 EPIE Error Passive Interrupt Enable

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

IER4 WUIE Wake-Up Interrupt Enable

1 enabled; if the sleeping CAN controller wakes up, the respective

interrupt is requested

0 disabled

IER3 DOIE Data Overrum interrupt Enable

1 enabled; if the data overrun status bit is set (see status register; Table 14), the CAN controller requests the respective

interrupt

0 disabled


IER2 EIE Error 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

IER1 TIE Transmit Interrupt Enable

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

IER0 RIE Receive Interrupt Enable

1 enabled; when the receive buffer status is ‘full’ the CAN controller requests the respective interrupt

0 disabled

2.3.4.6 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


ACL7 - reserved Ver Tabla 21.

ACL6 - reserved

ACL5 - reserved

ACL4 BITNO4 Bit number 4





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.


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:

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






Figura 31: Ejemplo de Pérdidas de Arbitraje







0 1 0 1 1 11 arbitration lost in bit SRTR

0 1 1 0 0 12 arbitration lost in bit IDE













1 1 0 0 1 25 arbitration lost in bit 24 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


ECC.7 ERRC1 Error Code 1 Ver Tabla 23.

ECC.6 ERRC0 Error Code 0

ECC.5 DIR Direction 1 RX; error occurred during reception

0 TX; error occurred during transmission

ECC.4 SEG4 Segment 4 Ver Tabla 24.

ECC.3 SEG3 Segment 3





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


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 (“bus-free”), 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


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.

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.

Figura 32: Distribución General del Buffer de Transmisión


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


16 FF RTR X X DLC.3 DLC.2 DLC.1 DLC.0




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

RTR 1 remote; remote frame will be transmitted by the CAN

controller

0 data; data frame will be transmitted by the CAN


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


16 FF RTR 0 0 DLC.3 DLC.2 DLC.1 DLC.0


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


16 FF RTR 0 0 DLC.3 DLC.2 DLC.1 DLC.0




20 ID.4 ID.3 ID.2 ID.1 ID.0 RTR 0 0


Donde el significado de los bits es el mismo que para el caso del buffer de transmisión.

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.

Figura 33: Buffer de Recepción para el modo PeliCAN


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.

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,

Figura 34: Filtro de Aceptación PeliCAN. Modo Simple y Tramas Estándar

Figura 35: Filtro de Aceptación PeliCAN. Modo Simple y Trama Extendida


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


Figura 37: Filtro de Aceptación PeliCAN. Modo Dual y Tramas Extendidas


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 , el cual determina el tiempo de bit y se calcula como:

Donde 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


SAM TSEG2.2 TSEG2.1 TSEG2.0 TSEG1.3 TSEG1.2 TSEG1.1 TSEG1.0


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:

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


OCTP1 OCTN1 OCPOL1 OCTP0 OCTN0 OCPOL0 OCMODE1 OCMODE0

La lógica empleada en el “transceiver” es la mostrada en la Figura 39.

Figura 38: Estructura General de un periodo de bit


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 .

Figura 39: Logica Empleada en el Transceptor


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.

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

Pull-down

0 0 1 0 off on LOW

1 0 1 0 off off float


1 0 1 1 off on LOW

Pull-up 0 1 0 0 off off float

Figura 40: Ejemplo del Clock Output Mode

Figura 41: Ejemplo de Bi-phase Output Mode


1 1 0 0 on off HIGH

0 1 0 1 on off HIGH


Push-pull

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


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


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.


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


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 (V-DTLS 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].


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

Figura 42: Plano del Modelo de Despliegue de Safety Pilot [21]


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

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

Figura 43: Distintas Visiones de los Proyectos CVIS, COOPERS y SAFESPOT


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)

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

Figura 44: Arquitectura CVIS [29]


colaboradoras que los dirigieron:

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

Figura 45: Subproyectos SAFESPOT [32]


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.

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

Figura 46: Escenario GCDC


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.


3 ARQUITECTURA Y ELEMENTOS DEL

SISTEMA

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.

L

Figura 47: Arquitectura CVIS


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:

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.

Figura 48: OBU Elementos Embarcados en Vehículo


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.

Figura 49: Arquitectura del Demostrador


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:

Figura 50: AlixBoard 3D2 (Superior/Inferior)


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.

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:

Figura 51: MikroTik R52H


Tabla 38: Características MikroTik R52H

Chipset AR5414

Rango de Frecuencias 2.192-2.539MHz / 4920-6100Mhz

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.

3.1.3.2 Dongle Bluetooth

El modelo concreto es el CBT2NANO de Conceptronic. Se trata de un dispositivo USB-Bluetooth 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


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


Tabla 40: Características iKarPC

Modelo iKarPC

Pantalla 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

Sistema 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

Comunicaciones Wireless LAN Wi-Fi® 802.11 b/g

Bluetooth Bluetooth® V2.0+ EDR (Class 1)

Modem WCDMA/HSUPA

GPS GPS w/ Internal Antenna

Multimedia Audio 1 x Line-in 1 x Line-out 1 x 3 W Speaker

Cámara 0.3 Megapixel CMOS Camera

Indicatores LED y

Botones

Indicadores Wi-Fi®/Bluetooth®/HDD/3.75G/DVB-T/Power Status LED

Teclas de función F1~F6 Function Key, Direction key, Power Button

Interfaces de E/S 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

Alimentación 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

Entorno Temperatura de Op. -20˚C to +60˚C

Temperatura del

Amacenamiento

-30˚C to +70˚C

Humedad 5%~95% non-condensing


Aguanta Caídas 1 M

Protección Ambiental IP54 compliant front panel (Water, dust and splash resistant)

Certificación CE/FCC/e-MARK

Física Dimensiones (Largo x

Ancho x Alto) (mm)

261 x 162 x 44

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


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

Figura 54: MSK28335 con Adaptación de Señales


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.


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

Figura 55: Samsung Galaxy Tab 7”


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

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.

Figura 56: Arquitectura interna RSU


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

Figura 57: Arquitectura RSU del Demostrador


4 TRABAJO REALIZADO

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.

S

Figura 58: Resumen OBU


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.


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 DD-WRT, 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


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.

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

Figura 59: Logotipo Open-WRT


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/openwrt-x86-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/kernel-debug.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 null-modem 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


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/


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 'ifname' 'eth0'


option 'netmask' '255.255.255.0'

option 'gateway' '192.168.0.1'

option 'defaultroute' '0'

option 'peerdns' '0'

config 'interface' 'wifi'


option 'ifname' 'ath0'


option 'netmask' '255.255.255.0'

config 'interface' 'wan'

option 'ifname' ' '

option 'proto' 'none'


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

#


#

################################################################

###

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

#


#

################################################################

###


config 'interface' 'loopback'

option 'ifname' 'lo'



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

#


#

################################################################

###

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.


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


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.

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:

Figura 61: Comunicación HMI y Vehicle Host


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

Figura 62: Pila de comunicaciones

Bluetooth


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:

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

Figura 63: Capas y Núcleo Android


un dispositivo de desarrollo se decidió adquirir los diseños de desarrollo de Olimex: 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.

Figura 64: (a) Combinación STK500+STK501 (b) AVR-H128-CAN


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


Para realizar el PCB se ha utilizado el software de diseño profesional Altium, siendo el resultado el siguiente fotolito PCB:

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

Figura 66: Fotolito Test CAN


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.

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:

Figura 67: Demostración APIs iKarPC


Figura 68: Programación GPS iKarPC


5 CONCLUSIONES Y TRABAJO FUTURO

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, ISO-CALM, 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.

L

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/the-cost-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://eur-lex.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]. D. Cook, S. Das, Smart Environments: Technology, Protocols and Applications, Wiley-Interscience 2004.

[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

http://es.wikipedia.org/wiki/Bluetooth

[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%20Deployment.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_safespot_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/

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

Documents

Trabajo Final de Máster en - bibing.us.esbibing.us.es/proyectos/abreproy/70452/fichero/TFM_JMLC.pdf · 2.3.1 Microcontrolador 8051 44 ... 4.3.2 Soporte STK500 en Versiones Actuales