Módulo Telemático Avanzado para Aplicaciones en Automoción (V2VCU)

TITULACIÓN: E.A.E.I.

AUTOR: Rubén Sánchez Fajardo DIRECTOR: Javier Maixé Altés

TUTOR EN LA EMPRESA: Antoni Ferré Fabregas

FECHA: Junio del 2008.

iii

ÍNDICE

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

1.1. SISTEMAS TELEMÁTICOS EN AUTOMOCIÓN ..................................................... 1 1.2. APLICACIONES DE C2C/C2I..................................................................... 4 1.3. ESTADO DEL ARTE (STATE OF THE ART)...................................................11

1.3.1. CVIS Project (Cooperative Vehicle Infrastructure System) ...............11 1.3.2. Consorcio CAR2CAR...................................................................14 1.3.3. Implementación real V2VCU: GENERAL MOTORS ...........................18

1.4. TECNOLOGIA DE LOS SISTEMAS TELEMÁTICOS EN AUTOMOCIÓN ............................23

2. ESTRUCTURA DEL PROYECTO.............................................................. 26

2.1. OBJETIVOS DEL PROYECTO ......................................................................26 2.2. FASES DEL PROYECTO............................................................................27

2.2.1. Análisis del proyecto ..................................................................27 2.2.2. Desarrollo HW: Diseño de la placa electrónica................................28 2.2.3. Desarrollo SW: Diseño del software de la placa electrónica (C) /

Desarrollo del software de la aplicación de demostración (JAVA)....................29 2.2.4. Documentación .........................................................................30

2.3. DESARROLLO EN V ...............................................................................31 2.4. DIAGRAMA DE BLOQUES .........................................................................35

2.4.1. Diagrama de bloques software ....................................................35 2.4.2. Diagrama Hardware...................................................................36

3. ENTORNO DE TRABAJO ....................................................................... 38

3.1. HERRAMIENTAS HARDWARE. ....................................................................38 3.2. HERRAMIENTAS SOFTWARE......................................................................48

4. DESARROLLO HARDWARE................................................................... 55

4.1. DIAGRAMA DE BLOQUES DEL HARDWARE ......................................................55 4.2. SELECCIÓN DE MÓDULOS (GPS/GSM, 802.11A, VFIR) ..................................58 4.3. DISEÑO DEL BLOQUE DE ALIMENTACIÓN.......................................................69 4.4. DISEÑO DEL BLOQUE DE PROCESO .............................................................72 4.5. DISEÑO DE LOS BLOQUES DE COMUNICACIÓN ................................................74 4.6. REVISIÓN DE ESQUEMAS Y PUESTA EN MARCHA DE LA PLACA DE EVALUACIÓN.............78

iv

5. DESARROLLO SOFTWARE.................................................................... 82

5.1. DIAGRAMA DE BLOQUES DEL SOFTWARE ......................................................82 5.2. DISEÑO DE LA INTERFACE SCI .................................................................83 5.3. DISEÑO DE LA INTERFACE SPI..................................................................89 5.4. DISEÑO DE LA INTERFACE ETHERNET (TCP/IP, UDP) ......................................91

6. DESARROLLO DE LAS APLICACIONES.................................................. 96

6.1. INTRODUCCIÓN...................................................................................96 6.2. APLICACIONES....................................................................................98

6.2.1. Aplicación “llamada de emergencia” .............................................98 6.2.2. Aplicación “posicionamiento y sensado del entorno” .....................100 6.2.3. Aplicación “diagnóstico por infrarrojos” .......................................102

7. TESTS 106

7.1. INTRODUCCIÓN.................................................................................106 7.2. SYSTEM TEST ...................................................................................107 7.3. INTEGRATION TEST.............................................................................107 7.4. UNIT TEST.......................................................................................108 7.5. ARCHITECTURE TEST ...........................................................................110

8. CONCLUSIONES................................................................................ 111

8.1. EVALUACIÓN DE OBJETIVOS CUMPLIDOS /PENDIENTES.....................................111 8.2. CONCLUSIONES TÉCNICAS ....................................................................112 8.3. PRÓXIMOS PASOS ..............................................................................113 8.4. CONCLUSIONES SOBRE LAS COMUNICACIONES C2C/C2I .................................114 8.5. OPINIÓN PERSONAL Y VALORACIÓN DEL PROYECTO.........................................115

REFERENCIAS BIBLIOGRÁFICAS.............................................................. 116

AGRADECIMIENTOS ................................................................................ 117

ANEXOS…………………………………………………………………………………………..118

v

1

1. Introducción

1.1 Sistemas telemáticos en automoción. 1.2 Aplicaciones C2C/C2I 1.3 Estado del arte (STATE OF THE ART)

1.1. Sistemas telemáticos en automoción Actualmente, la automoción es una de las especialidades de la ingeniería que más se ha

beneficiado de la revolución producida a finales del siglo XX en materia de desarrollo de circuitos electrónicos. Desde su nacimiento en el siglo XIX, la automoción ha sufrido una evolución constante en cuanto a muchos de los procesos de fabricación y de los sistemas de los propios vehículos basados en las mejoras de diseño, nuevos materiales, simulaciones informáticas etc. Pero la evolución más acusada y que se puede ver en el último tramo de la historia de la automoción se debe sobretodo en la integración continua de nuevos sistemas electrónicos a los vehículos que han ido ganando en prestaciones, confort y seguridad y que hace que esta ciencia se situe hoy en dia a la cabeza de la industria en cuanto a recursos dedicados a la investigación y desarrollolo, este hecho ha dado como resultado que en la actualidad sea una industria tan especializada, competitiva y avanzada fuente de aplicaciones y técnicas a traspasar a las demás.

La automoción es en la actalidad un simbolo del desarrollo tecnológico y económico de un

país. Los parques móviles en los países desarrollados han crecido exponencialmente y se han extendido en gran medida en los países del tercer mundo.

Muy especialmente ha crecido el sector de los vehículos de turismo, gracias a los avances de los procesos de producción de la industria de la automoción que han permitido el acceso a un vehículo tecnológicamente avanzado al muchos ciudadanos de clase media, convirtiéndose el coche en un producto de consumo masivo, este consumismo permite dedicar mas recursos a a investigación lo que acaba beneficiando nuevamente a los procesos de fabricación y a los consumidores ya que el producto mejora.

Como ocurre con todos los productos tecnológicos, especialmente los ‘de consumo’

susceptibles de llevar electrónica, el avance que se ha producido en los vehículos en general y en los de turismo especialmente, en los últimos años ha supuesto un gran paso dentro de la totalidad de su evolución. En las ultimas 3 décadas, los automóviles han pasado de llevar una electrónica casi anecdótica y mas relacionada con la ingenieria electrica que de la microelectrónica actual para elementos como la bobina de encendido, los equipos de radio y algunos elementos electromecánicos para el funcionamiento del motor a poseer una compleja arquitectura electrónica de microcontroladores miniaturizados con aplicación a muchos y distintos sistemas.

2

Obviando elementos como la radio y centrados en el vehículo como medio de transporte, cuando aun se fabricaban vehículos con carburación, se incluyeron los primeros elementos de gestión electrónica del motor, que básicamente controlaban el sistema de encendido retrasando o avanzando la ignición de la mezcla de aire combustible según parámetros como la velocidad o la temperatura del motor, sin necesidad de usar elementos mecánicos susceptibles de desgaste. Posteriormente, con el paso del tiempo, la electrónica fue introduciéndose paulatinamente en los diseños de los motores que iban apareciendo hasta el punto de que en la actualidad los fabricantes de automóviles y vehículos pesados no fabrican vehículos con motor de carburación para su venta masiva.

Obviamente la introducción de la electrónica en la automoción siguió adelante, asi pues en

un vehículo actual de rango medio podemos encontrar más de 50 microprocesadores repartidos en funciones relativas a seguridad, gestión del motor, confort, entretenimiento...

Como se ha dicho la electrónica no solo ha modernizado a los vehículos, sino que la

industria también se ha beneficiado en gran medida de los avances de la tecnología del silicio en lo referente a la parte de producción. Como ejemplo, el hecho de que cada día la robótica industrial resulte mas asequible y eficiente en cuanto a coste inicial y mantenimiento, a la vez que se incrementa la precisión en la ejecución de sus aplicaciones, propicia que el producto final sea igualmente mas barato y de mejor calidad, lo que dentro de la industria del los vehículos y muy especialmente en la del automóvil, ha conllevado un incremento a gran escala de las ventas de vehículos durante el último tercio del siglo XX que sigue hoy en día un ritmo de ventas si bien menos pronunciado, en unos rangos absolutos realmente impensables en el pasado.

En este contexto de especialización de la industria vehicular, de gran demanda de unidades

del producto final y de generalización de su uso en las poblaciones de todo el mundo, surgen nuevos retos a los fabricantes. El cliente de a pie no cesa nunca en su demanda de nuevas soluciones a los problemas del día a día en lo referente a su vehículo: mas comodidad, mas estética, mas prestaciones y sobretodo en los últimos años, mas seguridad. Las cifras de fallecidos y heridos por accidente de tráfico han crecido en los últimos años y eso va contra la idea de felicidad que persiguen las personas y en consecuencia de sus pretensiones, por tanto la empresa que fabrique el vehículo mas seguro tendrá ganado a gran parte del publico y por eso hoy en día, se dedican grandes recursos al incremento de la seguridad durante la fase de desarrollo de los vehículos.

Durante los últimos diez años, se han ido implantando de manera sucesiva sistemas

accesorios de seguridad tales como cinturones de seguridad en todas las plazas, limitadores de la tensión del cinturón de seguridad, tensores pirotécnicos del cinturón de seguridad, reposacabezas en todas las plazas, reposacabezas activos, airbags de múltiples tipos etc. como elementos de seguridad pasiva, y otros como el sistema antibloqueo de frenos, el control de tracción, el programa electrónico de estabilidad, la ayuda a la frenada de emergencia, el reparto de frenada en curva etc. como elementos que refuerzan el comportamiento del chasis suponiendo una gran ayuda al control del coche en situaciones de todo tipo y que se conocen como elementos de seguridad activa.

3

Llega un momento en que la tecnología actual, no puede paliar los efectos de una colisión sin encarecer de manera desorbitada los costes de los vehículos, con lo cual hay que encontrar nuevas soluciones a los problemas que plantea la seguridad.

En plena era de la comunicación la solución según los departamentos de investigación de

muchas empresas de fabricantes de vehículos así como de entidades independientes, parece venir por abrir el concepto de seguridad a un punto de vista mas global, en el cual un vehículo como ente individual sea una pieza de un sistema mayor que mantiene un equilibrio a una escala por encima de la del vehículo y que garantiza la integridad de todos estos entes mediante un flujo continuo de información, que tiene por objetivo evitar las situaciones de peligro, o en caso de que se produzcan asegurar que todos los usuarios de la vía están informados de ello y pueden actuar de manera que se minimicen las consecuencias negativas en caso de que dicha situación de peligro desemboque en un accidente de tráfico. Esta tecnología intenta evitar o superponerse al error humano y a la vez paliar algunos de los límites de los usuarios permitiendo que estos reciban información que no pueden percibir por sus propias capacidades innatas.

La comunicación entre los vehículos se llevara a cabo mediante sistemas electrónicos

avanzados con multiples transceptores. Dichos sistemas de comunicación se agrupan dentro de la tecnología C2C (Car to Car) o V2V (Vehicle to Vehicle), con estos acrónimos se definen todo un abanico de sistemas y tecnologías que persiguen la interacción entre vehículos, y entre vehículos e infrastructuras (estas aplicaciones se identifican con el acronimo especifico de V2I e I2V), mediante la transmisión de distintos datos con el objetivo de incrementar la seguridad en la vía evitando las situaciones de peligro o dandolas a conocer como se ha dicho previamente.

El presente proyecto, se basa en la implementación de uno de estos sistemas

experimentales basado en las tecnologías de trasnmsión de datos actuales y en el estudio de la situación del entorno industrial en cuanto a desarrollos relacionados tanto a escala de definición de protocolos de telecomunicaciones aplicables a la tecnología C2C como de sistemas electrónicos con finalidades similares al prototipo implementado.

El proyecto ha sido desarrollado en el Centro Tecnológico Europeo de la empresa Lear

Corporation dentro del programa de “Premis Lear a la innovació tecnológica”. Como se verá mas adelante el proyecto consta de distintas etapas partiendo del diseño

conceptual propuesto por la empresa en la cual se ha llevado a cabo el proyecto hasta la puesta en marcha del módulo una vez fabricado.

4

1.2. Aplicaciones de C2C/C2I

A continuación se comentan algunas de las aplicaciones basadas en C2C orientadas a

seguridad, implementadas con mayor o menor detalle en los distintos proyectos europeos que se comentarán posteriomente. El abanico de posibles aplicaciones a construir sobre la base del C2C abarca muchas otras que a día de hoy se están desarrollando o que se definirán en el futuro según evolucionen las necesidades de la automoción.

Transmisión de Información Relacionada con la Seguridad

El objetivo de esta aplicación es posibilitar la transmisión de información crítica en zonas

donde no existan infraestructuras de telecomunicaciones establecidas capaces de enviarla a los usuarios. A nivel Europeo existen gran cantidad de zonas en las que no hay cobertura de telecomunicaciones, tales como parking, túneles, pistas forestales etc.

Con la tecnología C2C se crean redes Ad-Hoc entre vehículos que se encuentran en un

area determinada, que permiten transmitir información de vehículo a vehículo consiguiendo así la transmisión de información dentro de los limites de la zona sin cobertura. Con esto, los vehículos del interior tendrán posibilidad de enviar/recibir información a la infraestructura, los datos se iran transmitiendo desde el vehículo emisor a través de los demás vehículos hasta que las tramas lleguen a un vehículo fuera de ese area sin cobertura y se envien a la infraestructura.

En caso de que un vehículo se separe de los demás más allá de su rango de

emisión/recepción de mensajes, puede mantener en memoria los mensajes y enviarlos posteriormente a otro vehículo cuando la distancia entre ambos sea adecuada para que el sistema de transmisión realice el envio de manera satisfactoria.

Esta aplicación esta especialmente orientada a información crítica, ya que se usa parte del

ancho de banda de los sistemas de los vehículos que actuan como repetidores para tareas que no tienen porque ofrecer un beneficio directo a los usuarios de los mismos. Un ejemplo de esta información podría ser la transmisión de una ECALL, entre vehículos hasta que uno sea capaz de realizar con éxito el envío del mensaje a un nodo de infraestructura que lo acabará llevando a un nodo de infraestructura con capacidad para enviarlo vía red GSM. Modelo de Mapeado Dinánimo Local

Los sistemas inteligentes avanzados que se implantarán en los próximos años en los

vehículos, y de los cuales son precedentes los sistemas de seguridad activa y pasiva actuales,

5

tales como el SRS, el control de tracción y estabilidad etc., se basan en el conocimiento del entorno del vehículo.

El disponer de esos datos permite a la parte inteligente del vehículo tomar las decisiones adecuadas a transmitir a las partes funcionales del vehículo a fin de lograr una conducción más segura y placentera. El conocimiento de este entorno, se plasman en un modelo dinámico local actualizado en

tiempo real del entorno en el cual se encuentra el vehículo (Local Dynamic MAP). Este modelo dinámico, adapta los valores recibidos a través de sus entradas, que son

constituidas por: Señales recibidas a través de los sensores integrados del vehículo Información intercambiada con el resto de vehículos de la vía, con información sobre esta

y sobre el comportamiento de los mismos vehículos Información de diversa índole sobre el estado actual del vehículo para realimentación del

modelo.

IMAGEN 1: Representación de la aplicación de Modelaje de Mapeado Dinánimo Local

6

Por otra parte, del modelo de obtienen unas salida con datos calculados en tiempo real que

permiten a los módulos de proceso que la reciben trabajar con algoritmos avanzados para la asistencia al conductor, la toma de medidas cautelares de seguridad etc.

En una fase avanzada de desarrollo el objetivo de este proyecto y en concreto del modelo

dinámico mencionado seria el disponer de un mapeado detallado de el entorno del vehículo. Dicha información abarcaria datos obtenidos por el propio vehículo a través de sus sensores, de los demás vehículos de la vía a través de transmisión C2C así como de infraestructuras. De esta manera, vehículos relativamente sencillos y baratos dispondrían de información compleja y difícil de calcular/obtener cedida por otros vehículos mas avanzados o por las infraestructuras que al ser recursos compartidos pueden disponer de tecnología mas avanzada.

El modelo dinámico local es una elemento básico del que se espera dispongan los

vehículos del futuro de manera general, como parte fundamental del procesado de la informaciones accesibles por el vehículo y sobre el cual se fundamentarán las aplicaciones cooperativas de comunicación enfocadas a la seguridad del tráfico. Permitiendo homogeneizar informaciones de distinta naturaleza para hacerlas accesibles a las aplicaciones de mas alto nivel sin que estas deban ser especificas al hardware del que se obtienen.

Aviso de Peligro Local (ej. Aplicación Warning triangle del GST)

La aplicación de Aviso de Peligro Local consiste en dotar a un vehículo de la capacidad de señalizar al resto de vehículos del entorno la existencia de un determinado peligro que por distintas causas puede no ser apreciable por dichos vehículos.

Algunos peligros susceptibles de ser señalizados son: • Vehículo detenido por avería, en este caso el vehículo averiado será quien señalizará

su posición a los demás vehículos (ej. Aplicación Warning triangle del GST). • Vehículos accidentados, en este caso cualquiera de los vehículos implicados en el

accidente deberá señalizar su posición indicando que su detención se debe a un accidente. Este tipo de sucesos es especialmente peligroso por las probabilidades de derrame de líquidos, trozos de vehículo en el asfalto así como riesgo de herir a los ocupantes de los vehículos accidentados al salir de estos. A la hora de mostrar la información de los mensajes relativos a situaciones de riesgos se priorizará su exposición en los vehículos según el riesgo real que supongan.

• Vehículo incendiado, también constituye una situación especialmente peligrosa,

sobretodo en ciertas zonas con ambientes potencialmente inflamables, tales como industrias gasolineras etc.

7

Otro tipo de obstáculos en la vía. Además de los propios vehículos, se pueden encontrar en la vía gran cantidad de objetos que pueden resultar peligrosos para los usuarios de la misma. Los coches dotados de sistemas de radar, dispositivo usado ya actualmente en algunas aplicaciones de control de crucero adaptativo podrán rastrear un determinado tramo de la vía que se encuentra delante del vehículo. En caso de detección de un obstáculo, esta información será transmitida a la red del vehículo para que se tomen una serie de medidas de acuerdo a la posición y dimensiones del objeto. Estas medidad comprenden avisos al conductor, regulación de las suspensiones etc., Por otra parte el sistema C2C del vehículo transmitirá datos sobre el obstáculo a los demás vehículos a fin de que estos puedan igualmente adaptar sus sistemas a la potencial situación de peligro y los usuarios modificar su conducción.

• Algunos posibles objetos que pueden ser reconocidos y transmitidos según este

sistema, son animales en la vía, peatones, piedras, trozos de vehículos etc. • Malas condiciones climatológicas. Cuando un vehículo detecte alguna situación

crítica con respecto al tiempo, tal como un banco de niebla, rachas de viento fuerte, una zona helada del pavimento etc.

• Otros problemas de agarre en el firme. Los sistemas de control de tracción (CTS) y de

control de estabilidad (ESP) pueden proporcionar información sobre el agarre del vehículo en tiempo real, este puede verse reducido ante la presencia de hielo, grava, arena, agua, lubricantes etc. Asi como debido a problemas físicos de la vía tale s como agujeros o curvas con peralte invertido.

Ante la detección de cualquiera de estas situaciones, el vehículo detector transmite el

mensaje a los vehículos de su entorno, que a su vez lo retransmiten a otros vehículo mas lejanos. Igualmente en caso de acceso a un nodo de infraestructura los vehículos enviarán el mensaje a los mismos. Esta estrategia de disfusión permite incrementar rápidamente el número de vehículos informados y también una acción efectiva de los servicios adecuados tanto móviles (servicios de limpieza, grúas, cuerpos de seguridad, servicios médicos etc.) como fijos (alerta a hospitales, parques de bomberos etc.).

IMAGEN 2: Ejemplo de vehículo 'avisado' de peligro por coche detenido

8

Aviso al Conductor Dentro del Margen de Seguridad Esta aplicación pretende anunciar al conductor del vehículo, de que forma puede/debe

conducir para mantener un nivel de seguridad aceptable. El vehículo capta a través de sensores propios y de la infraestuctura vía mensajes I2V, cual

es el estado real y actual de la via, en terminos de regularidad del asfalto, adherencia, tráfico, señales, climatología etc. A partir de esa información, el sistema puede establecer cuales son las limitaciones que deberian llevarse a cabo para que la conducción se mantenga dentro de un margen de seguridad, indicando al conductor como debe de llevarla a cabo.

El parametro más importante es la velocidad del vehículo, pero pueden tomar en cuenta

muchas mas a fin de definir un modelo de calculo más complejo y preciso. Las condiciones para mantenerse dentro del margen de seguridad se definen según: El estado actual del conductor y su capacidad para realizar maniobras de emergencia

satisfactoriamente (de acuerdo al nivel de sueño del conductor, horas al volante y parámetros estables tales como problemas de movilidad, edad, experiencia etc.

Las condiciones dinámicas del vehículo, teniendo en cuenta el estado de la vía. Estas

además dependen de parametros como la edad del vehículo, tiempo desde la última revisión, estado y presión de los neumaticos etc

Las situaciones de peligro que pueden aparecer en un determinado tramo de vía, esto

depende del número de carriles, accesos a la vía, numero de curvas, visibilidad etc.

La aplicación intenta minimizar los efectos de la valoración subjetiva que hace el conductor de la situación que le rodea basada en su propia percepción, ofreciendo al conductor información objetiva sobre la situación en la que se encuentra. Además fácilita la adaptación de la manera de conducir a la situación actual, indicando al conductor el comportamiento adecuado que debe mantener.

Posicionamiento Local Preciso Entre Vehículos El Posicionamiento Local Preciso Entre Vehículos es una aplicación, complementaria a

otras del mas alto nivel basadas en el posicionamiento del vehículo y especialmente del posicionamiento relativo entre vehículos del mismo entorno.

El objetivo a cumplir es satisfacer unas cotas de exactitud en el posicionamiento que

permitan la correcta ejecución de las mencionadas aplicaciones partiendo de los datos de

9

posicionamiento recibidos a través de un sistema satelital de posicionamiento. El GPS/Galileo no ofrece la precisión necesaria para la mayoría de estas aplicaciones Safety de posicionamiento, y por tanto se deben implementar mecanismos alternativos tales que en colaboración con este sistema permitan un posicionamiento preciso del vehículo.

La necesidad se basa más en un correcto posicionamiento del vehículo dentro de un area

pequeña (entorno inmediado) que en su posicionamiento global, por lo que las técnicas se basan en un sistema cooperativo formado por los vehículos próximos entre si.

Algunas técnicas usadas para lograr este objetivo son

• Posicionamiento relativo del vehículo basado en redes ad-hoc • Localización del vehículo según sensores de velocidad (ABS) • Posicionamiento basado en puntos de referencia, vallas, balizas, marcas en la

calzada • Algoritmos de aumento de la precisión

Apertura de Paso a Vehículos Prioritarios (ej. Aplicación Blue Corridor del GST).

Dentro del proyecto europeo llamado GST se definió una aplicación cuyo propósito es

fácilitar la circulación a vehículos prioritarios. En cualquier situación y sin depender de las normativas sobre limitación en el uso de

sirenas, los vehículos prioritarios pueden solicitar el paso mediante el envío de mensajes C2C. Adicionalmente dichos vehículos pueden definir la ruta que planean realizar a fin de que

los demás usuarios de la vía la eviten o adapten su comportamiento a la situación, por ejemplo evitando iniciar un estacionamiento o la parada en doble fila si la vía en la que se encuentran ha sido marcada como parte de la ruta de un vehículo prioritario.

Por otra parte también se propone la señalización virtual de zonas de trabajo, de manera

que pese a que no exista una barrera física el vehículo reciba la información de que una determinada zona de la vía no debe ser usada e informe de ello al usuario. Pantalla de Información del Estado de la Vía

El objetivo de esta aplicación es posibilitar la llegada de cierta información relevante ofrecida por la infraestructura al los usuarios de la vía como por ejemplo señales de tráfico, en condiciones adversas tales como la falta de visibilidad por obstáculos eventuales (estructuras en obras, vehículos de gran tamaño etc.)

La infraestructura realizaría una emisión indicando la señal de tráfico indicando su

posición, vía y carriles a los que afecta y en su caso información adicional.

10

En el vehículo el sistema de comunicaciones lo transmitiría al usuario mediante dispositivos HMI tales como proyectores HUD (heads up display) o la pantalla del equipo multimedia.

Las informaciones a transmitir pueden ser tanto estáticas (señales, puntos peligrosos, puntos

de interés) como dinámicas (peligros por obras, peligro por formación de hielo o presencia de niebla, vehículos especiales circulando o trabajando en la vía etc.)Este sería un ejemplo de aplicación similar a la aplicación Virtual Cones del proyecto GST, en esta última el objetivo es señalizar virtualmente una zona por la que no se debe circular mediante señalización en los sistemas de abordo del vehículo, como medida añadida y no alternativa a los sistemas de señalización tradicionales.

IMAGEN 3: Ejemplo de ‘Pantalla de Información del Estado de la Vía’ en vehículo de pruebas

11

1.3. Estado del arte (STATE OF THE ART) En la actualidad, la totalidad de los fabricantes han dado muestras de interés en el uso de

las tecnologías de comunicación vehiculares, bien mediante el desarrollo de sus propios prototipos o bien estableciendo enlaces con empresas que dispongan de estos. La tecnología de V2V es algo innovador y resulta difícil generar prototipos funcionales para ciertas empresas cuyas prioridades inmediatas son otras. Es por ello que la mayoría de los avances en este campo vienen dados por las asociaciones fabricantes de automóviles o electrónica.

Por otro lado, la mayor parte del peso de la evolución de la tecnología obviando el

protagonismo del factor comercial, lo llevan los organismos gubernamentales, así pues, la comunidad económica europea, en un intento de minimizar la siniestralidad, subvenciona muchos y diversos proyectos de investigación que tienen por objetivo la implementación de alguna medida de seguridad tanto directa como indirectamente. Así, en el ámbito de su programa ESafety, la Comisión Europea ha apoyado financieramente la investigación en sistemas, entre ellos los telemáticos, que permitan reducir a la mitad el número de muertes en las carreteras para el año 2010 con la visión de tener una situación de "Cero muertes" en 2020.

Por supuesto, los fabricantes de automóviles europeos apoyan firmemente este objetivo y

están convencidos de que esto sólo puede lograrse a través de una combinación de medios, incluida una eficaz cooperación entre los vehículos y entre ellos y una infraestructura de carreteras inteligente.

En esta sección se presentan las iniciativas europeas más destacadas tanto a nivel de

investigación como de desarrollo, y tanto a nivel público como privado.

1.3.1. CVIS Project (Cooperative Vehicle Infrastructure System)

A partir del eSafety forum creado en 2002, se crearon varios grupos de trabajo orientados a cubrir distintos aspectos de la seguridad vial, una de ellos es el Working Group on Communications. El objetivo de este grupo de trabajo consiste fomentar las actividades de desarrollo de sistemas tecnológicos dirigidos a incrementar la seguridad de los usuarios mediante el intercambio continuo de información.

En este marco nace el proyecto CVIS, este está dirigido por ERTICO, la asociación

público-privada plurisectorial europea sobre desarrollo y despliegue de sistemas y servicios de

12

transporte inteligente, y ha sido subvencionado a través de la sección de Tecnologías de la Sociedad de la Información del VI Programa Marco (VI PM). En él participan 63 socios de toda Europa, entre los que se encuentran fabricantes de vehículos (BMW, Renault, etc.), empresas de telecomunicaciones (Vodafone, Telecom Italia, etc.), institutos de investigación y universidades (Cork Institute of Technology, Centre de la Recherche Scientifique) y otros (RACC). Se trata de un proyecto de 4 años, con fecha de inicio 1 de Febrero de 2006, con un presupuesto de 41 millones de euros, de los cuales 22 millones están subvencionados por la Unión Europea, y la participación de 12 países europeos con pruebas piloto en seis de ellos (Francia, Alemania, Italia, Los países Bajos, Suecia y Reino Unido).

. El CVIS pretende desarrollar un sistema router móvil, capaz de trabajar sobre varios

medios de comunicación tales como las tecnologías de telefonía celular, la redes de área local para nodos móviles, las microondas de corto alcance (DSRC) o los transceptores de luz infrarroja, que permita mantener una conexión continua de los vehículos entre si y de estos con los sistemas fijos y servicios presentes en la vía.

El proyecto tomará como base y validará los estándares ISO “CALM” para la

comunicación móvil continua y proporcionará a su vez una base para los estándares de desarrollo a nivel Europeo y global.

Brevemente, los objetivos del CVIS son: • Crear una solución tecnológica estándar que permita una comunicación transparente

entre vehículos de distintos fabricantes e infraestructuras de diversa índole, basada en el uso de varios medios de transmisión inalámbrica y avanzados sistemas de localización.

• Definir e implementar una serie de servicios cooperativos capaces de ser ejecutados

en un entorno abierto y dinámico tanto por vehículos como por infraestructuras • Definir y validar una arquitectura abierta y un concepto de sistema sobre el cual

ejecutar aplicaciones para sistemas cooperativos y desarrollar componentes comunes a integrar en distintas aplicaciones. Con esto se persigue el fin de permitir modelos de cooperación entre esas aplicaciones y servicios por parte de los usurarios de la vía, operadores telemáticos, infraestructura y otros grupos con intereses en materia de seguridad

• Solucionar temas como el acceso a la red, el reconocimiento de los usuarios, la

privacidad y seguridad en las comunicaciones, la normalización de los sistemas y la interoperabilidad entre estos, la fiabilidad de la tecnología propuesta y la evaluación de riesgos en general. Por otra parte un objetivo importante es la búsqueda de compromiso entre capacidades de los sistemas y precio unitario para asegurar una rápida generalización de su uso.

13

En cuanto a su organización el CVIS se divide en varios sub proyectos con objetivos

especializados, estos son el grupo de Core Technologies, Cooperative Applications, Test Sites y Deployment Enablers.

Los resultados a conseguir globalmente por el CVIS son:

• Un Terminal capaz de mantener una conexión continua a Internet basada en los distintos medios de comunicación y que permita total interoperabilidad en las comunicaciones entre distintos fabricantes de vehículos y sistemas de control de tráfico.

• Una arquitectura abierta para conectar sistemas de abordo con sistemas de control de

tráfico y sistemas telemáticos de las infraestructuras que puedan ser fácilmente actualizados y redimensionados a fin de permitir la implementación de aplicaciones basadas en distintas tecnologías, especialmente tecnologías actualmente bajo desarrollo.

• Técnicas de mejora para posicionamiento preciso de los vehículos y creación de mapas

locales dinámicos (explicado en el capitulo Aplicaciones C2C/C2I), mediante uso de sistemas de posicionamiento por satélite (GPS/Galileo), algoritmos de triangulación y métodos avanzados de posicionamiento basados en comunicación local entre vehículos.

• Extender el uso de protocolos para monitorización de vehículos, vía e infraestructuras,

que permitan a los vehículos compartir y verificar sus datos con otros vehículos e infraestructuras del entorno.

• Centrado en el diseño de aplicaciones y núcleos base para el desarrollo de software, el

CVIS pretende crear:

o Sistemas cooperativos para control de redes urbanas, control cooperativo basado en los destinos de los vehículos, control cooperativo de adaptación de aceleración/desaceleración y control dinámico adaptativo de las vías.

o Asistencia avanzada al conductor, sistemas avanzado de avisos al conductor

o Monitorización de vehículos de transporte de materias peligrosas, y control de

reservas de parking, zonas de carga y descarga etc. así como control de acceso a zonas restringidas.

o Difundir un “toolkit” en forma de modelos, guías y recomendaciones enfocadas

a distintos ámbitos como la interoperabilidad y el concepto de abierto para los sistemas descritos, la seguridad, el diseño con tolerancia a errores, utilidad, costes, beneficios etc. Así como modelos enfocados al fomento de

14

oportunidades de negocio, centradas en la valoración de riesgos, viabilidad, cooperación etc.

1.3.2. Consorcio CAR2CAR Se trata de una asociación no lucrativa creada por varios fabricantes de vehículos

europeos, abierta a proveedores de electrónica, investigadores e incluso a usuarios particulares que quieran integrarse en la misma.

Según se muestra en su página web oficial sus principales objetivos son: Establecer un estándar abierto para la comunicación C2C (entre vehículos) y C2I (entre

vehículos e infraestructura) para garantizar en el ámbito Europeo una comunicación continua en toda su superficie y con suficientes prestaciones que permita interoperatibilidad entre los distintos elementos de la vía, incluyendo vehículos e infraestructuras fijas.

Promover el uso de un rango de frecuencias exclusivo a nivel Europeo para la

implementación de comunicaciones Car2Car y Car2Infrastructure (tambien conocido como Car2Road).

Promover la extensión del estándar de comunicaciones a nivel mundial a fin de lograr una

comunicación global sin fronteras Para lograr estos objetivos el consorcio Car2Car propone diversas medidas: • Crear un estándar industrial abierto para la implementación de sistemas de

comunicación íntervehicular y vehículo-infraestructura basado en una tecnología de difusión publica

• Tener control sobre las diferentes actividades que puedan afectar al desarrollo de las

comunicaciones en automoción • Promover el uso de una banda de frecuencias de uso gratuito para aplicaciones C2C

• Promover el uso de la tecnología C2C mediante la redacción y distribución de

especificaciones, creación de prototipos y demostradores de las tecnologías de comunicaciones propuestas

15

• Desarrollar estrategias de mercado realistas que permitan acelerar la implantación en el mercado de empresas productoras de este tipo de dispositivos de comunicación con el objetivo de generalizar su uso masivo en la red de vehículos fácilitando su diseño y fabricación.

Los fabricantes de vehículos agrupados en el consorcio Car2Car son: • AUDI • BMW • DAIMLER CHRYSLER • FIAT • RENAULT • VOLKSWAGEN Así mismo se hallan en el consorcio distintos fabricantes de electrónica que pueden aportar

gran parte del know how necesario para la consecución de los objetivos del consorcio. El consorcio queda abierto al resto de fabricantes europeos que quieran tomar parte en el

proceso de estandarización de la tecnología C2C así como a otras empresas con posibles intereses en el conocimiento, desarrollo e implantación de las tecnologías propuestas para los sistemas de transporte Europeos.

IMAGEN 4: Fabricantes de vehículos miembros del C2C Communication consortium

16

日本語

IMAGEN 5: Algunos fabricantes de tecnología electrónica miembros asociados del C2C Communication Consortium

La tecnología y aplicaciones propuestas por el Car2Car Consortium para su implantación en vehículos con funcionalidades de comunicación avanzadas, aportan mejoras en tres áreas:

• Asistencia avanzada a la conducción. Incrementando la seguridad en carretera

reduciendo así el numero de accidentes así como reduciendo la severidad de las consecuencias en caso de no poder evitar el accidente.

• Comunicaciones descentralizadas basadas en la flota de vehículos de la vía lo que

implica un aumento en la fluidez y eficiencia del tráfico

• Posibilidad de ofrecer servicios de comunicaciones y servicios varios, adicionales a los orientados a la seguridad, a los vehículos de la vía abarcando aplicaciones de confort, entretenimiento y trabajo, tanto orientados al conductor como a los pasajeros del vehículo.

17

IMAGEN 6: Esquema de servicios potenciales de las tecnologías C2C en comparación con tecnología de comunicación celular

18

1.3.3. Implementación real V2VCU: GENERAL MOTORS

El grupo de la industria de la automocion General Motors (GM integrado por marcas como

Opel, Cadillac, GME, Vauxhall, Saab etc) es pionero en el desarrollo de sistemas de comunicación inalámbrica experimentales para sus prototipos de vehículos.

GM dispone de prototipos de vehículos de calle equipados con sistemas de comunicación

C2C y C2I totalmente funcionales , los modelos Cadillac y Opel han sido mostrados en varios eventos relacionados con la exposición de novedades del mundo del motor, exhibiendo las distintas funcionalidades implementadas actualmente en sus vehículos.

IMAGEN 7: Sistema C2C experimental en vehículo GM

Los sistemas montados utilizan derivaciones de hardware existente para redes WIFI, y algoritmos software que mejoran la recepción con nodos en movimiento.

Los fabricantes de vehículos invierten en el desarrollo de software efectivo y en soluciones

que actuen sobre los demás sistemas del vehículo formando parte del arquitectura del mismo a fin de diseñar tecnologia propia que los diferencie de sus competidores.

En el momento de madurez de la tecnologia C2C los sitemas se encargarán a un proveedor

de sistemas electroncos por lo que un alto grado de integración de los circuitos en terminos de componentes por unidad de volumen es algo secundario, de ahi que los sistemas desarrollados por los fabricantes de vehículos, como el de la imagen superior, no compartan en absoluto las dimensiones ni prestaciones del prototipo V2CU.

En especial, los sistemas de GM destacan por alto grado de integración en el vehículo e

interacción con distintos elementos electrónicos avanzados del vehículo, tales como el sistema de ABS, CTS (Sistema de Control de Tracción) o ESP (Programa Electrónico de Estabilidad). El funcionamiento en común con estos sistemas les permiten en caso de necesidad la

19

asistencia automática al conductor, mejorando la respuesta del vehículo en aquellos casos en los que los tiempos de reacción del conductor son excesivamente largos y en los que la tardanza en ejecutar una determinada acción puede poner en peligro la integridad del vehículo y sus ocupantes. En estos casos la maniobra se puede ejecutar en menos tiempo que en el caso de que el vehículo se limitara a activar señales sonoras o luminosas en el cuadro de instrumentos.

El sistema C2C desarrollado por General Motors, actúa comunicandose sobre bus

multiplexado de altas prestaciones con la centralita del sistema de frenado ABS llegando a frenar automaticamente y de manera progresiva si una vez detectado y adevertido el peligro no se aprecia respuesta suficiente por parte del conductor. Como ocurre con otros sistemas automáticos, este prioriza siempre las acciones del conductor, para ello, se monitoriza contínuamente el estado de aquellos dispositivos de control sobre los cuales este puede actuar. En caso de conflicto directo entre la solicitud de control del sistema automático y las acciones del conductor, se dan por válidas estas últimas, de forma que la responsabilidad recae sobre el conductor. Por ejemplo ante un vehículo detenido, si el conductor frena con fuerza insuficiente el sistema enviará al sistema electrohidráulico ABS una solicitud de frenada mayor a la solicitada por el conductor. En el caso de que el conductor pise el acelerador, por ejemplo para evitar ser alcanzado por detrás, el vehículo dejará de frenar y acelerará.

IMAGEN 8: Representación gráfica de un sistema C2C de aviso de peligro integrado en el sistema multimedia del vehículo

Además el sistema indica de manera cautelar los posibles peligros en la pantalla del sistema multimedia del vehículo y emite avisos sonoros como representa la imagen adjunta, adicionalmente algunos avisos se transmiten mediante vibración del asiento del conductor y el volante.

20

Algunas de las aplicaciones implementadas en los prototipos de GM son:

Asistente de cambio de carril

Este sistema advierte a los demás vehículos de la intención de cambiar de carril, ante lo cual el vehículo que circula por el otro carril manda un aviso de presencia cuyo contenido depende de varios parámetros como las posiciones relativas de los vehículos, la velocidad absoluta y relativa y las acciones sobre el vehículo que se estén llevando a cabo en ese momento.

IMAGEN 9: Asistente de cambio de carril indicando presencia de vehículo en angulo muerto

Aviso vehículos prioritarios

La aplicación de señalización de vehículos prioritarios descrita de manera genérica en el capítulo de Aplicaciones C2C permite al conductor saber que se aproxima un vehículo prioritario incluso antes de que pueda oír la sirena o ver las señales luminosas. Una aplicación adicional al margen de GM consiste en que los vehículos prioritarios puedan por ejemplo trazar la ruta que van a tomar con el fin de que los vehículos normales no circulen por las vías que componen dicha con esto se permite un incremento en la eficacia del servicio prestado por dichos vehículos.

21

IMAGEN 10: Representación de la aplicación de Aviso de vehículos prioritarios

Señalización de vehículos detenidos

Los vehículos que se detienen o circulan a baja velocidad emiten automáticamente un

mensaje de aviso indicando su posición exacta en datos GPS. Consiguiendo que el resto de usuarios puedan adaptar su conducción a la situación de peligro anteponiéndose a esta incluso antes de que sean capaces de ver a simple vista al coche detenido. De igual manera los servicios implementados en la parte de la infraestructura pueden activarse al detectar esta situación.

Avanzado sistema de control en intersecciones

El sistema prioriza el paso de vehículos a través de una intersección a nivel de manera que se eviten eventuales colisiones. Las colisiones frontolaterales son las más peligrosas para el vehículo que recibe el

impacto por el lateral y tienen un alto factor de fallecidos/heridos por accidente. Esto se debe a la poca protección que ofrecen los vehículos por dicha zona y a la vez a limitaciones biológicas del ser humano a recibir desaceleraciones laterales. Por ello el sistema supone una contribución importante al incemento de la seguridad. Este es uno de los sistemas con posibilidad de actuación automática sobre los sistemas

del vehículo, básicamente sobre el sistema de frenado, pudiendo llegar a detener el vehículo ante una acción insuficiente del usuario. Cuando los vehiculos se acercan a una intersección el sistema entra en acción priorizando a cada vehículo en su paso por la misma y dando al usuario del vehículo instrucciones para superarla de manera segura. A través de instrucciones audibles y de la pantalla del sistema multimedia del vehículo, el

conductor es informado de que su trayectoria interseca con la de otros vehículos, de la posición de estos y sus direcciones. A la vez el sistema indica si el vehículo en el cual se encuentra instalado tiene prioridad o debe ceder el paso a los demás. Por otra parte el sistema se antepone a la llegada a la interesección y recomienda una velocidad adecuada para entrar en la mis.

22

IMAGEN 11: Recreación de la aplicación de control avanzado de intersecciones de GM mostrando las instrucciones que percibiría el conductor de cada vehículo

23

1.4. Tecnologia de los sistemas telemáticos en automoción

En este apartado presentamos una breve aproximación a la arquitectura propuesta así como a la tecnología básica que se utilizará para los sitemas telemáticos en automoción. Con toda seguridad estará basada en las propuestas del Car2Car Consortium, pues éste comprende al núcleo duro de la industria..

Para la implementación de la comunicación vehicular cabe mencionar que en el sistema de radiocomunicaciones soportado propuesto por el consorcio tiene muchos puntos en común con el estándar del que deriva, el IEEE 802.11 conocido popularmente como Wireless LAN o WIFI, se ha elegido este estándar por tratarse de una tecnología “off the shelf” es decir de acceso publico, no especifica para esta aplicación en especial.

En una situación real en campo según el CAR2CAR cuando dos o mas vehículos entren en

un espacio común en el que exista visibilidad de los demás por parte de sus sistemas de comunicaciones wireless, estos se conectarán automáticamente estableciendo así una red “ad-hoc”. Esto es una red creada dinámicamente, que puede crecer y decrecer a medida que los nodos abandonen la red por alejamiento o nuevos nodos se unan a esta al acercarse a los demás nodos de la red existente

Dado que el rango de un enlace vehículo - vehículo dentro de una red se limita a algunos

cientos de metros en condiciones ambientales adecuadas, el envío de información entre dos vehículos o un nodo de infrastructura y un vehículo, se hace posible ya que cada vehículo y nodo actua como router, permitiendo reenviar el mensaje recibido al siguente o siguientes vehículos. Para esta tarea se deben implementar eficaces algoritmos de disfusión. Estos algoritmos se basan en la posición relativa de los vehículos entre si, y es capaz de adaptar el patrón de distribución ante los cambios súbitos de entrada y salida de nodos en la red asi como de cambios posicion de los mismos.

IMAGEN 12: Muestra de red Ad-hoc, cada vehículo actua como Router reenviando la información a los demás nodos

próximos de la red

24

Con respecto a los avances reales en el desarrollo de una tecnología apropiada a las casos de transmisión comentados, los progresos en el campo de las Wireless LAN por parte del comité IEEE 802 han permitido el desarrollo de nuevos servicios y aplicaciones C2X implementados sobre los protocolos de red local existentes.

Sin embargo esta tecnología no se desarrollo teniendo en cuenta la posibilidad de

contemplar nodos móviles a altas velocidades (>20Km/h), pese a ello el protocolo IEEE 802.11b dio resultados prometedores en este tipo de aplicaciones. Por ello, basado en este estándar, el Consorcio C2C en cooperación con fabricantes americanos de vehículos ha venido desarrollando un nuevo estándar, el IEEE 802.11p, enfocado a satisfacer los requerimientos de las aplicaciones de comunicación WLAN con nodos móviles de alta velocidad.

IMAGEN 13: Esquema de pila de protocolos para aplicaciones C2C

El estándar recomienda el uso de un ancho de banda localizado en la banda de los 5.8 GHz.

En Europa las transmisiones inalámbricas no están regularizadas a nivel continental, sino

que cada país dispone de regulaciones nacionales con respecto a distintas bandas de transmisión.

Según los estudios realizados para la implantación del estándar a nivel europeo la banda

menos congestionada compatible a la vez con el estándar estadounidense es la que abarca desde los 5.885 Ghz hasta los 5.905 Ghz, que permite dos canales de 10 Mhz de ancho de banda. El uso de canales exclusivos para la implementación de una red inalámbrica en aplicaciones críticas, que requieran de alta velocidad de transmisión y fiabilidad es imperativo, especialmente si estas tienen requerimientos de transmisión de información en tiempo real.

25

Pese a los exigentes requisitos que tiene cualquier aplicacion automotive, esta debe tener un precio de producción ajustado a fin de que esta sea implantada a nivel mundial en vehículos de todas las gamas, sin lo cual las aplicaciones y servicios perderían gran parte de su potencial. Por ello se basó la transmisión sobre vehículos en los protocolos WLAN existentes. Pese a sus ventajas, los protocolos WLAN actuales, como se ha dicho no estaban diseñados con este propósito y sus capas mas bajas, carecen de las prestaciones necesarias para soportar la creación de redes Ad-hoc, flexibles y cambiantes a alta velocidad. De igual manera las capas superiores del protocolo no soportan los modos de distribución de mensajes adecuados a las dichas redes.

Como se ha comentado anteriormente, en la práctica, los vehículos transmitirían en un

radio de acción de algunos cientos de metros y la transmisión de información proveniente de nodos lejanos debería de hacerse mediante múltiples retransmisiones en las que cada vehículo haría las veces de repetidor. En este contexto la red evoluciona alejándose del concepto de red local, por ello se estudia que por encima de las capas de transmisión física WLAN, y para determinadas aplicaciones se use el protocolo de transporte IPv6.

La ventajas que aporta este protocolo tales como el gran numero de nodos identificables con direcciones IP únicas o el control de errores a alto nivel lo hacen muy interesantes para las aplicaciones C2C y C2I pero a la vez se debe tener en cuenta que las aplicaciones vehiculares tienen requerimientos específicos y probablemente el protocolo deberá ser adaptado para su uso en las mismas.

IMAGEN 14: Diagrama de tecnologias wireless C2C y C2I basada en transporte IPv6

26

2. Estructura del Proyecto

2.1 Objetivos del proyecto 2.2 Fases del proyecto 2.3 Desarrollo en V 2.4 Diagrama de bloques

2.1. Objetivos del proyecto

El proyecto expuesto se ha realizado dentro del programa de Premios Lear a la innovación tecnológica, que beca a dos estudiantes de ingeniería de la Universidad Rovira y Virgili y dos de la Universidad Politécnica de Cataluña, a fin de que realicen sendos proyectos de final de carrera en el departamento de investigación del Centro Tecnológico Europeo de Lear optando a ganar un premio económico.

Al rellenar la solicitud de de adscripción al programa de Premios Lear, el alumno especifica en un formulario fácilitado por la empresa aquellas áreas de conocimiento aplicado que mas interesantes le resultan. Por su parte la empresa, en caso de una valoración positiva de las aptitudes del alumno oferta un proyecto que resulte interesante en relación a sus necesidades vigentes y a la vez los intereses del alumno.

En el caso de este proyecto los temas marcados como de interés abarcaban la electrónica

digital, los módulos body controller, buses de comunicaciones a bordo (CAN, LIN, etc.) las telecomunicaciones en los vehículos etc. El proyecto realizado fue el propuesto por la empresa prácticamente sin modificaciones con respecto a la idea inicial que se presentó.

El proyecto consiste en el diseño, validación y testeo, tanto a nivel de hardware como de

software de un módulo electrónico avanzado de comunicaciones para vehículos con distintos transceptores de comunicaciones, dotado de receptor GPS para aplicaciones de posicionamiento e interface ethernet de cara a poder conectar el módulo con un módulo de mayores prestaciones bajo desarrollo en ese momento en el departamento de electrónica avanzada de LEAR conocido como CCM (Central Console Module). El disponer de dicha interface permitiría igualmente la conexión a un PC para probar el módulo. Como se puede ver en el Anexo1 en la propuesta de LEAR, aparecen igualmente algunas aplicaciones que se podía implementar sobre el módulo realizado, tales como la E-Call, o las aplicaciones de posicionamiento por GPS que se han realizado en el proyecto.

El objetivo final del módulo era la de prototipo demostrador, es decir un módulo cuya finalidad era la de mostrar la capacidad de la empresa para realizar este tipo de módulos y a la vez adquirir una serie de conocimientos (know-how) sobre esta tecnología que serían de utilidad en futuros proyecto similares.

27

IMAGEN 15: Esquema básico de componentes del módulo

La empresa definió al presentar el proyecto el tipo de transceptores de comunicaciones de

los que debía disponer el módulo electrónico, como se puede ver en el diagrama de bloques. Estos abarcan la transmisión por infla rojos, y por ondas de radio. Pese a que en el diagrama aparece un módulo transceptor DSRC, ya se especificaba que dicho protocolo de transmisiones C2C y C2I aún estaba bajo desarrollo por parte de las entidades competentes y que por estar basado en los actuales protocolos 802.11 se utilizaría un transceptor que soportara alguno de los estándares de WIFI existentes. La frecuencia de radio a la que transmitirá el DSRC según se anunció en su momento será de 5.9 Ghz por lo que en el proyecto se especificaba que el transceiver a utilizar debía ser de WIFI 802.11a ya que este trabaja en esta frecuencia.

El módulo electrónico debía de tener una CPU propia a fin de ejecutar los comandos

externos que le llegaran a través de la interface ethernet, para dotar al módulo de una alta potencia de calculo y a la vez aprovechar los recursos disponibles del departamento se definía en el documento que el procesador a utilizar por el módulo V2VCU sería el mismo que el del módulo CCM, finalmente como se explica en el apartado Diseño Hardware, en el subapartado de Elección de Componentes se eligió otro procesador menos prestacional, que cumplía igualmente con los requisitos impuestos.

2.2. Fases del proyecto

2.2.1. Análisis del proyecto

En esta fase del proyecto, se estudió el funcionamiento de la comunicación ínter vehicular en varios proyectos como los mencionados en el apartado Estado del Arte, centrándose en las tecnologías usadas, aplicaciones y servicios bajo estudio por parte de los distintos grupos de investigación.

28

Se estudiaron igualmente las distintas tecnologías a usar en la placa, a fin de poder definir el grado de integración necesario que debian tener los componentes que se iban a montar en la placa, se inicio igualmente la selección preliminar de componentes.

Se planificó de acuerdo a la información disponible cual debía ser el timing del proyecto a fin de poder completarlo en el periodo de 600h del que constaba el mismo, especificando el objetivo de las distintas fases de las que consta. Ver capítulo de conclusiones para más información sobre el timing.

2.2.2. Desarrollo HW: Diseño de la placa electrónica

En la fase de desarrollo del hardware se llevaron a cabo básicamente dos subtareas de gran importancia, por una parte la elección de componentes principales descrita en un capítulo posterior de la memoria, centrada sobretodo en:

-Selección del micro -Selección del módulo WIFI -Selección del módulo GSM -Selección del módulo GPS -Selección de antenas para los módulos de comunicación WIFI y GSM -Selección de antena para módulo receptor de GPS -Selección de controlador IR -Selección de transceptor IR

Por otra parte dentro de esta fase se llevó a cabo el diseño del hardware de la placa

electrónica. La tarea de diseño se llevó a cabo tomando como referencia algunos diseños de prototipos anteriores del CTE, application notes de los datasheets de los distintos componentes etc. procurando hacer un diseño modular, sencillo y fiable, que permitiera ampliar la placa en un futuro. Esta fue una de las fases mas interesantes como se expone en el capitulo de Conclusiones por el reto que presentaba a nivel personal. Para realizar el diseño de los esquemas electrónicos se usó la herramienta P-CAD schematic, descrita mas adelante.

El trabajo resultante de esta fase consiste, por una parte en los esquemas, que suponen un

producto de alto valor por la posibilidad de ser usados en un futuro para otros proyectos y por constituir un estudio de las partes de la implementación que no se habían probado en proyectos anteriores, y por otra el módulo electrónico V2VCU. El V2VCU fue fabricado a partir de los esquemas electrónicos realizados usando un PCB (circuito impreso) de 6 capas cuyo diseño y fabricación se subcontrató, asi mismo el montaje en la placa de la mayor parte de los distintos componentes se llevó a cabo por terceros.

Debería haberse realizado en esta fase del timing, según la previsión que se hizo en un

principio, el testeo del hardware de la placa, consistente básicamente en comprobar que la alimentación de todos los módulos es correcta, que existe comunicación entre ellos y que todos funcionan correctamente. Dicho testeo permitiría dejar el prototipo preparado para los programas de aplicación que se deberían de grabar al final de la siguiente fase. Como se explicará mas adelante la puesta en marcha y testeo de la placa tuvo que retrasarse por

29

demoras en el proyecto y en el proceso de fabricación de la misma. Debido a estos retrasos, las aplicaciones software desarrolladas se tuvieron que probar sobre un setup formado por las distintas placas de evaluación correspondientes al micro y a los módulos de comunicaciones.

2.2.3. Desarrollo SW: Diseño del software de la placa electrónica (C) / Desarrollo del software de la aplicación de demostración (JAVA)

El módulo V2VCU es un módulo ‘inteligente’ en el sentido de que tiene una unidad de proceso que se encarga a través de un software y drivers de bajo de nivel de interactuar con los distintos componentes hardware de la placa a fin de proporcionar al módulo externo que se conecta al V2VCU el servicio solicitado. El módulo maestro envía tramas de datos sencillas a través de la interface ethernet y obtiene datos por el mismo medio. La CPU del V2VCU se encarga de procesar dichas tramas, de realizar las peticiones oportunas a los distintos módulos de comunicación y GPS a través de sus buses SCI y SPI y finalmente de procesar la información obtenida para reenviarla hacia el exterior. Este es el propósito básico del software ‘embedeed’ que se tuvo que programar durante esta fase para dotar de funcionalidad al módulo V2VCU, y que constituye la parte mas compleja y con mayor asignación de tiempo de la misma.

El software del microcontrolador se programó en lenguaje C standard, lenguaje sobre el que se tenía una buena base y de cuyas herramientas de compilación para el micro seleccionado para el módulo se disponía en el departamento. La aplicación se desarrolló sobre el IDE CodeWarrior.

Por otra parte, se debía diseñar una aplicación para testear el módulo, pese a que en un

principio se definió que el módulo sería un periférico del módulo CCM comentado anteriormente y que por tanto se podría manejar desde este, ya se previó la necesidad de implementar una aplicación basada en un PC que ofreciera al proyecto V2VCU independencia total de la evolución del desarrollo del CCM.

La aplicación sobre PC se diseñó en JAVA, en este caso no existía imposición alguna

sobre el lenguaje a utilizar, se escogió JAVA por tener una buena base adquirida durante el cursado de la carrera de ingeniería técnica informática así como por la sencillez que ofrece este lenguaje a la hora de realizar aplicaciones basadas en red (creación de sockets, buffers de datos, etc.). La aplicación de demostador implementa algunas aplicaciones de alto nivel a fin de mostrar las posibilidades de la tecnología incluida sobre el V2VCU. La aplicación usada para la programación de esta aplicación fue NetBeans, herramienta gratuita proporcionada por Sun Microsystems.

La implementación del programa de demostración al final del proyecto quedó bastante

avanzada, a falta completar la fase de validación de algunas partes del software que accedían a funcionalidades del micro que no se llegaron a implementar tales como la transmisión VFIR.

30

2.2.4. Documentación

El objetivo de la fase final del proyecto ha sido la de realizar una selección y ordenación de todos los documentos recopilados a lo largo de la realización del proyecto y que servirán como fuente de información y punto de partida para futuros proyectos referentes al diseño de módulos C2C y por otra parte la realización de la presente memoria que debería también servir como guía para futuros proyectos similares que se lleven a cabo en la empresa. Además de Datasheets, catálogos, application notes etc. se dejan como documentación del proyecto, algunos documentos resultado del trabajo realizado, como son listas de precios de componentes, timings, datos de contacto con los proveedores de los distintos módulos electrónicos de comunicaciones integrados, notas de uso de los módulos etc.

Según el planning propuesto por la empresa la fase de documentación tenía una asignación

de 120h de la duración total del proyecto, que ha sido de 600h, en la práctica el desarrollo del módulo, debido a su complejidad y a los problemas indirectos que surgieron se extendió en el tiempo relegándose las tareas de documentación a un plano secundario. Las tareas de documentación durante el transcurso del proyecto se limitan a la creación de presentaciones internas y de la presentación final mostrada al jurado en el concurso de los premios LEAR asi como a la recopilación de documentos necesarios para el desarrollo del mismo. Por tanto como se explica mas adelante en el capitulo de conclusiones algunas subtareas relativas a la documentación que constituyen parte de los objetivos del proyecto se tuvieron que dejar pendientes.

De igual manera debido a las causas descritas, la presente memoria, objetivo principal de

la fase de documentación de proyecto se ha realizado a posteriori partiendo de la información guardada durante la ejecución del mismo.

31

2.3. Desarrollo en V A fin de conseguir desarrollar exitosamente un producto, en las empresas modernas se

siguen distintos modelos de desarrollo. Los modelos de desarrollo marcan los pasos que deben de darse para llegar a concebir un producto, su orden y los requisitos que tiene cada uno de estos pasos con respecto al anterior.

La fabricación de un producto parte de una necesidad, esta necesidad es recogida por el

cliente en forma de unas especificaciones que se transmiten a la empresa que diseña y fabrica el producto y a partir de las cuales se iniciará el desarrollo del mismo. El seguimiento de un buen modelo de desarrollo implicará que todos los requisitos aportados por el cliente encuentren su respuesta en el producto final y se vean satisfechos de manera correcta.

Este ha sido el modelo seguido durante el desarrollo del presente proyecto. A continuación se describe brevemente el modelo antecesor del modelo en V.

Modelo en cascada

En la industria del software ha tenido mucho peso a lo largo de los últimos años el modelo de desarrollo en cascada, este es el enfoque metodológico que ordena las etapas del ciclo de vida del proyecto de software, de tal forma que el inicio de cada etapa la etapa anterior debe haber finalizado.

IMAGEN 16: Diagráma del modelo de desarollo en cascada

En el sistema en cascada se parte de unas especificaciones de cliente, se analizan y

posteriormente se diseña el programa a alto nivel. Entonces se procede a programarlo y finalmente en los últimos estados del proceso se testea el software resultando de todo ello la implementación final, la ultima etapa se llama de mantenimiento y se encarga por una parte de

32

mejorar el producto por encima de las especificaciones originales y por otra paliar deficiencias del proceso que han desembocado en un producto con alguna carencia en cuanto a calidad.

Algunas de las ventajas más importantes del modelo de desarrollo en cascada son: Es muy sencillo seguirlo cuando se tiene un profundo conocimiento de la tecnología en la

que se trabaja y un producto estable. Debido a su sencillez es adecuado a equipos sin experiencia. Es relativamente fácil planear el trabajo con anterioridad Por otra parte tiene una serie de carencias: Es poco flexible Se deben conocer de antemano todos los requisitos del producto, lo que no siempre ocurre El cliente no tiene una idea de cómo será el producto hasta que se llega a un estado

avanzado del ciclo de vida del proyecto Un error pequeño en las primeras fases puede suponer graves problemas en etapas mas

avanzadas. A fin de paliar las contras del modelo en cascada muchas empresas toman un modelo

reinventado del mismo, el modelo en V. El proceso en V tiene como objetivo prioritario la calidad del producto, y esta se consigue

mediante el mantenimiento de la calidad a lo largo de todo el ciclo de vida del producto. Con el fin de mantener dicha calidad la tarea de desarrollo se divide en varias subetapas de

mas alto a mas bajo nivel, tal y como ocurre con el modelo en cascada, pero por el contrario, la etapa de testeo no sigue una secuencialidad con respecto a la de codificación globalizando las validación del producto como un todo, sino que cada una de las etapas de desarrollo desde el análisis de requerimientos a la implementación lleva asociado un testeo en la rama ascendente de la V.

IMAGEN 17: Diagrama de actividades paralelas llevadas a cabo en un proyecto en V

33

El desarrollo llevado a cabo por un equipo de ingeniería de software siguiendo el modelo en V teóricamente se divide en cuatro actividades paralelas: Project Management, software development, configuration management y quality assurance que a la vez disponen de un proceso, es decir de una secuencia de pasos que deben de llevar a cabo para lograr el éxito del proyecto, de unos métodos, esto es, como deben llevar a cabo las acciones necesarias para realizar esos pasos y por ultimo de unos requisitos de tooling, que especifiquen que recursos necesitan para llevar a cabo sus respectivas tareas.

En cualquier caso para cada una de las cuatro posibilidades, desde el punto de vista del

producto, el modelo sigue la siguiente estructura:

IMAGEN 18: Diagrama de entidades del modelo en V

La ventaja de este modelo frente al de cascada es que como se ve cada etapa de desarrollo

desde las de mas alto nivel hasta las de mas bajo tienen su correspondiente testeo, esta jerarquización permite obtener softwares de mayor calidad donde es controlan mejor los requisitos y su impacto en las diferentes ‘capas’ de la V.

El resultado es que un error a bajo nivel en un módulo del software se puede detectar al

hacer los tests de unidad (UT), uno a nivel high level design en el integration test (IT) y así sucesivamente, con ello un error originado en un nivel bajo de diseño no tiene porque llegar a afectar a todo el software puesto que si se sigue correctamente el modelo se detectará a tiempo.

El modelo en V, se sigue en LEAR para desarrollar los distintos proyectos que se llevan a

cabo en la empresa, pese a que el modelo constituye un estándar en la ingeniería del software también es aplicable al hardware por lo cual se adapta generalmente a la mayor parte de actividades para el desarrollo de módulos electrónicos que tienen lugar en la misma.

34

En la práctica, el cumplir con modelos teóricos no siempre es posible debido a que ello

necesita de recursos que en muchas ocasiones están destinados al desarrollo productivo, es decir a las tareas que san como resultado avances apreciables del producto. En el desarrollo de software dichos recursos se asignan principalmente a la etapa de programación, por lo tanto la secuencialidad de la V en cada una de sus ramas y el paralelismo entre las etapas de desarrollo y las de testeo se rompe en ocasiones. Este incumplimiento del proceso se debe por ejemplo a la necesidad de retroceder en la ‘V’ para rediseñar una parte del high level design una vez ya se ha completado la de codificación lo que alterará consecuentemente otras secciones del software.

En cualquier caso este ha sido el modelo que se ha intentado seguir para el diseño y

validación del proyecto V2VCU, partiendo de unos requerimientos sobre el módulo que conforman la parte superior izquierda de la V y dando como resultado una placa electrónica funcional y un software que pese a no implementar todos los requisitos, como se explica en puntos posteriores, tiene una calidad satisfactoria visible en la etapa de validación y testeo gracias que se intentó en todo momento llevar a cabo un paralelismo entre los tests y las implementaciones a bajo nivel antes de ascender a las siguientes celdas de la V.

35

2.4. Diagrama de bloques

2.4.1. Diagrama de bloques software A continuación se muestra en forma de diagramas de bloques la estructura básica del

prototipo, tanto a nivel de software como de hardware. En el modelo de software, se simbolizan con flechas las relaciones entre entidades. En el de hardware, las líneas simbolizan canales físicos entre los distintos componentes del circuito tales como buses de datos o pistas de alimentación.

Como introducción al diseño del software, como se comentará mas adelante se ha optado

por atender las peticiones de acceso a las funcionalidades de los distintos módulos hardware desde rutinas de servicio a la interrupción (RSI). De esta manera no hay tiempos de CPU asignados a distintas tareas siguiendo un esquema estático ni polling de los buffers de estado de los puertos del micro con los que este se comunica con los periféricos, si no que se dedican los recursos en función del régimen de peticiones que esté teniendo lugar en cada momento.

Al iniciarse el programa se realizan una serie de inicializaciones de valores correspondientes a registros del microcontrolador, tales como los de dirección de los puertos y sus valores iniciales.

A continuación se inicializan valores de red del micro, tales como la dirección IP, la

dirección hardware o MAC o la mascara de red y gateway, con lo cual definimos el acceso al micro desde la red y a que direcciones puede acceder el mismo.

Para realizar la comunicación con los módulos integrados periféricos, GSM, WIFI y VFIR,

se usaron rutinas de servicio a la interrupción independientes que implementan los protocolos adecuados para los distintos módulos (comandos AT, transmisión de datos RAW, configuración de los módulos, etc.). Cuando se reciben datos y cuando el hardware del micro a acabado de enviar los últimos datos introducidos en la anterior ejecución de la RSI esta se vuelve a ejecutar.

Por esto se especifican en el fichero usado para llenar el vector de interrupciones que se realice la llamada a las funciones ISR implementadas, asociando una posición del vector a un puntero que direccionará al micro a dicha función.

Posteriormente se crean tres sockets, que tienen asociados las rutinas de servicio

correspondientes a cada uno de los módulos de hardware, de tal forma que para acceder a las funcionalidades del módulo GPS/GSM/GPS el módulo maestro externo tiene que enviar al módulo V2VCU un mensaje de red por un puerto, para las del módulo WIFI a un puerto distinto y a un tercero para la transmisión vía VFIR. Esto se explicará mas adelante en el punto de desarrollo software.

Por ultimo en el diagrama de bloques del programa podemos ver que dentro del bucle

principal, se establece el código de atención a los mensajes ethernet, esto se hace mediante evaluación cíclica de una macro de la librería Open TCP, librería que implementa el código de

36

comunicaciones en red desde bajo nivel. En caso de llegada de mensaje, según el protocolo de red que sea ejecuta una función u otra de la misma librería. Si el paquete recibido es UDP y se ha enviado a uno de los puertos para los cuales creamos los sockets la función de Open TCP que atiende a los mensajes UDP llamará a la función que se especificó durante la inicialización de los sockets, representada como SERVICE ROUTINE P2X00 en el siguiente diagrama. INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 19: Diagrama de bloques SOFTWARE

FIN DE INFORMACIÓN CONFIDENCIAL

2.4.2. Diagrama Hardware

En lo referente al hardware, como se verá mas adelante el diseño consta de varios módulos

de comunicaciones premontados, controladores, transceptores, leds etc. La placa tiene instalado un microcontrolador que es la única unidad de proceso de la placa

y se encarga de controlar los demás periféricos según los comandos que le llegan externamente a través del puerto ethernet. El controlador de ethernet esta integrado en el micro. Como se ha dicho al inicio del capitulo el micro esta aprovechado en lo referente a puertos de comunicación disponibles colgando los módulo periféricos de los buses SCI y SPI del mismo.

Las comunicaciones GSM y la recepción de información GPS las lleva a cabo un único

módulo electrónico que se comunica con el microcontrolador vía SCI y que se alimenta a partir del regulador avanzado conmutado dual del que dispone la placa, la tensión de alimentación usada en este caso es la de 3.8 voltios, la otra tensión disponible es de 3.3V. Este módulo electrónico con un alto factor de densidad de componentes en su interior viene encapsulado en una carcasa metálica puesta a masa interna y externamente a fin de evitar las interferencias electromagnéticas y presenta en la misma dos conectores para las antenas de GPS y GSM lo cual fácilita aún mas su integración en proyectos como el V2VCU donde la simplicidad y la fiabilidad del diseño son críticos.

37

El otro bus SCI del microcontrolador se usa para controlar el módulo de transmisión WIFI,

este módulo es un sandwich de dos placas electrónicas, una de procesado y una que implementa el ‘front end’ de radio como se describe en el apartado de selección de componentes. El módulo WIFI, cuenta también con conectores de antena integrados y tiene la posibilidad de conectarse a dos antenas ganando así capacidad de recepción.

Como se ve en el diagrama de bloques adjunto, se alimenta a partir de la salida de 3.3V del convertidor de voltaje dual, compartida con el microcontrolador.

Por ultimo, la placa dispone también de capacidad de comunicación a alta velocidad por

infrarrojos, para lo cual se usa un controlador de VFIR, que según el fabricante transmite hasta 16Mbits por segundo, el controlador tiene un encapsulado pequeño de bajo consumo y que se alimenta a 1.8 voltios, para lo cual se instaló en la placa un segundo regulador de voltaje (lineal). Este último regulador es un integrado mucho mas sencillo que el dual cuelga de la salida de 3.3V de este.

El transceptor IR montado es el único encontrado en el mercado que permitía extraer el

máximo rendimiento del controlador según el fabricante y por eso se optó por usar el mismo siguiendo una ‘application note’ del mismo. Además visto que el transceptor cuenta con un pin al cátodo del led, se conecto un led de alto alcance en paralelo al del transceptor, con lo cual la distancia máxima de transmisión crece sustancialmente.

INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 20: Diagrama de bloques HARDWARE

FIN DE INFORMACIÓN CONFIDENCIAL

38

3. Entorno de Trabajo

3.1 Herramientas hardware 3.2 Herramientas software

3.1. Herramientas hardware. Para la realización del proyecto se han usado diversas herramientas hardware y software.

Básicamente a nivel de hardware, la “estación de trabajo” para las diversas etapas del proyecto, desde la de análisis a la de desarrollo del proyecto se ha basado en un único PC con conexión a Internet.

No obstante durante la fase de programación de algunas de las funciones del

microcontrolador debido a una limitación en el número de licencias disponibles para el compilador del microcontrolador se ha usado otro PC distinto alternando su uso con el principal.

Para la programación del microcontrolador durante la fase de desarrollo del software se ha

usado una placa de evaluación de Motorola de la que se disponía en el departamento. Como periféricos de comunicaciones se han usado dos placas de evaluación

proporcionadas por los respectivos fabricantes de la tecnología a evaluar, en este caso GSM/GPS y comunicaciones WIFI-Bridge ethernet/WIFI/RS-232.

A continuación se detalla el hardware usado durante las distintas fases del proyecto

• Análisis del proyecto:

Ordenador VLS-20-1520

• Desarrollo de la aplicación:

Ordenador VLS-20-1591 Ordenador VLS-20-1520 Placa evaluación EVB9S12NE64 con microcontrolador MC9S12NE64 Placa de evaluación EV Silex550 con módulo de comunicaciones Silex 550 Placa de evaluación Telit EVK2 Motherboard con placa Telit EVK2 GM862 Interface y

módulo telemático GSM/GPS/GPRS GM862 GPS

39

ORDENADOR VLS-20-1520:

Características:

Ordenador de sobremesa Intel® Pentium® 4 CPU 1GHz 512 MB RAM Windows XP Professional Service Pack 2

Descripción Se trata de un del PC, sobre el que se han ejecutado la totalidad de los programas descritos

en el punto herramientas de software, los tiempos de carga de los programas han sido largos pero la potencia total del PC era suficiente para el desarrollo del proyecto, por tanto se puede considerar que cumple los requisitos mínimos para la realización del proyecto.

Este ordenador disponía de conexión a Internet a través de la red de la empresa lo que fue necesario durante todo el proyecto, especialmente en la fase de desarrollo del hardware ya que se recopiló gran cantidad de información sobre componentes, datasheets, hojas de aplicaciones etc. En cualquier caso la conexión es necesaria para el correcto seguimiento del proyecto por parte del tutor, comunicación con los proveedores para solicitud de información sobre el producto, cotizaciones, dudas técnicas etc.

Otro aspecto importante de esta máquina es que tenía dos puertos de serie RS-232, el disponer de al menos uno es requisito indispensable para realizar el envío de datos a la placa de evaluación del microcontrolador (EVB9S12NE64) que solo tiene esta entrada para programar al micro a través del bootloader incorporado en la misma. De igual manera se uso el puerto para comunicarse con la placa de evaluación del módulo GSM/GPS (Telit EVK2) que como se describe mas adelante dispone también de esta interface para su control.

Durante el desarrollo el disponer de 2 puertos serie en el PC fue muy beneficioso puesto

que reduce enormemente el tiempo de puesta en marcha del sistema para el desarrollo de los distintos módulos de software, GPS/GSM, WIFI y fácilita el debugging del protocolo de transmisión entre el microcontrolador y los módulos de comunicaciones. Es decir, el poder tener conectados al PC a la vez el microcontrolador mediante su placa de evaluación y el módulo GSM/GPRS mediante la suya, permite trabajar de forma mas productiva. Esta configuración permite por ejemplo ver mediante las herramientas descritas, lo que esta enviando cada una de las placas de evaluación (micro y módulo periférico) en cada momento e ir paso a paso transmitiendo los datos que se reciben por un puerto serie al otro, con esto se puede simular secuencial mente y paso a paso el dialogo que tendría lugar directamente entre micro y periférico.

Una vez depurado el código con el PC se pueden conectar las placas directamente, al final de la fase de desarrollo o los módulos directamente en la placa V2VCU definitiva.

40

ORDENADOR VLS-20-1591:

Características:

Ordenador de sobremesa Intel® Pentium® 4 CPU 2.80GHz 1GB RAM Windows XP Professional Service Pack 2

Descripción Básicamente, se uso para programar algunas rutinas del microcontrolador cuando no se

disponía de licencia para el compilador en el otro PC. Su potencia es muy superior, lo que hacia que el tiempo de compilación se redujese

drásticamente. La fase de programación que se llevó a cabo en esta máquina fue la referente a la integración de la librería de comunicaciones TCP/IP por lo que se realizaron muchas pruebas de acceso a la aplicación JAVA, que se encontraba bajo desarrollo así como a la herramienta PortPeeker, debido al alto consumo de CPU del programa editor de Java, NetBeans el disponer de un PC rápido es muy recomendable ya que en esta fase se debe relanzar el programa continuamente.

PLACA DE EVALUACION EVB9S12NE64 PARA EL MICROCONTROLADOR MC9S12NE64

Esta es la placa de evaluación que se uso en el proyecto y que lleva instalado el microcontrolador usado en el mismo, el Freescale MC9S12NE64. En el departamento se disponía de dos placas para este microcontrolador, siendo esta la que mas posibilidades ofrecía especialmente para debugging y expansión del micro.

La placa, fabricada for Xion manufacturing dispone de de un regulador de tensión MIC4690 SuperSwitcher, con una frecuencia de conmutación de 500kHz, que permite alimentar la placa conectándola a un transformador AC/DC de pared aceptando un rango de tensiones de entrada entre 4 y 34 voltios.

41

IMAGEN 21: EVB9S12NE64 PARA Microcontrolador MC9S12NE64

Dispone de puerto ethernet, para la implementación de aplicaciones que exploten las capacidades del controlador integrado en el micro, el conector ethernet RJ-45 esta aislado galvánicamente del micro y es muy similar al usado en el prototipo V2VCU.

De los dos puertos serie RS-232 conectados mediante chips adaptadores de niveles a los

SCI (serie 5V) que ofrece el micro, el SCI0 se usa para la programación de la placa a través de la aplicación preinstalada Monitor. Mediante el programador integrado en el IDE Code Warrior, se puede grabar el software en el microcontrolador desde el PC.

Para la comunicación de la aplicación del micro con el PC u otro módulo electrónico hay

que usar el puerto SCI1 ya que el otro esta dedicado en exclusiva al programa pregrabado MONITOR, el bootloader del microcontrolador y no se quería prescindir de este por la practicidad que ofrece el poder grabar directamente desde el PC.

Otras posibilidades que ofrece la placa son los conectores de expansión del micro, estos

son conectores standard de pich 2,54 mm, uno de los cuales se presenta como puerto de expansión para LCD.

Durante la fase de debbuging fueron muy útiles los 4 pulsadores y 4 leds de uso general

(los leds de status de la red también se pueden usar a discreción), cabe mencionar que dispone de un potenciómetro para testeo de aplicaciones con entrada de datos analógicos pese a que no fue el caso.

42

Dispone de memoria EEPROM externa al microcontrolador, switches de configuración de los puertos serie del microcontrolador y un transceiver de infrarrojos, unido a uno de los puertos serie del micro y que se configura con los mencionados switches.

Así mismo, como se muestra en la siguiente imagen la placa tiene una zona de prototipaje, una pequeña protoboard y una zona de topos para prototipaje con soldadura. PLACA DE EVALUACIÓN TELIT EVK2

IMAGEN 22: Placa de evaluación TELIT EVK2

La placa de evaluación Telit EVK2, es una plataforma común para la mayoría de los módulos de este tipo que fabrica y distribuye la marca, se puede utilizar para el testeo de toda la gama de producto GSM/GPRS, UMTS/HSDPA y CDMA, esto permite a la Telit proporcionarlas a un precio mas competitivo y a la vez a los clientes conocer un producto que sirve para varias aplicaciones distintas según el módulo que se quiera probar.

La placa de evaluación es realidad un kit de dos PCBs, el PCB común a todos los

productos y otro PCB de interface (hijo) especifico para el módulo o familia de módulos que se va a testear. Este ultimo es mas pequeño y permite el aprovechamiento del hardware del módulo base para distintos módulos sin encarecer excesivamente el coste por módulo a testear, ya que el módulo hijo no tiene componentes caros, solamente conectores y algunos componentes pasivos.

43

La placa madre contiene el hardware relativo a las interfaces con el exterior, como el jack de alimentación, el porta tarjetas SIM externo, las entradas y salidas de audio para los módulos GSM/GPRS, los puertos RS-232 y el USB 1.1, un botón para RESET y un interruptor de alimentación así como los integrados para acondicionamiento de las señales de audio, conversión de niveles serie 3.3V a RS-232 etc.

IMAGEN 23: Esquema de bloques e interfaces de la placa de evaluación EVK2

Telit ofrece los esquemas de la placa de evaluación a fin de que los proyectistas que usen sus módulos puedan tener un diseño de referencia para sus prototipos. Las placa madre ofrece varios parámetros de configuración a través de jumper para definir el uso de la placa que mas se acerque al del prototipo definitivo, por ejemplo se puede configurar si las salidas serie del módulo de comunicaciones se deben conectar al convertidor de serie a USB integrado o a los convertidores de nivel serie - RS-232 según se vaya a usar un puerto u otro o si se usa o no la etapa de audio.

El módulo hijo se conecta a la placa madre a través de dos conectores (ristras de pines)

standard de pich 2.54 mm, situados en la parte del módulo hijo opuesta al módulo de comunicaciones y en la parte superior de la placa madre. A finde evitar conexiones erróneas, la placa madre lleva unos separadores roscados que solo permiten encajar las dos placas en un sentido.

En el caso del módulo probado la placa hija tenía un pequeño puerto de expansión para aprovechar todas las posibilidades que ofrecía el módulo de comunicaciones y que no eran comunes a todos los módulos, según la documentación de Telit, las características especificas de cada módulo de comunicaciones que requieran implementación hardware se encuentran en la placa hija especifica para dicho módulo. De la misma manera la placa hija tiene un conector especifico, para el módulo de comunicaciones en el caso de que este sea conectable a través de conector como en el caso del módulo Telit usado durante el proyecto o bien lleva el módulo

44

directamente soldado en el caso de ser una placa para testeo de módulo SMD, ya que su instalación posterior por parte del cliente requeriría de medios difícilmente accesibles como una estación de soldadura por infrarrojos.

IMAGEN 24: Layout de la placa de evaluación

IMAGEN 25: PCB de interface con módulo de comunicaciones montado

PLACA DE EVALUACIÓN SILEX SX-550-6900

La placa de evaluación SILEX SX-550-6900 esta incluida en un kit de desarrollo

proporcionado por la empresa SILEX, que se compone además de un cable RS232, antena WIFI y conector adaptador para esta, con el kit se puede iniciar el desarrollo con este módulo

45

de manera immediata ya que la placa permite la conexión a un un PC vía puerto RS232, con lo cual se puede empezar a probar el módulo desde que se recibe el kit.

La placa constituye un circuito base sobre el cual, a traves de un conector estandar de 40

pines, se instala el módulo SX-550 y que le proporciona un hardware adicional que fácilita su uso durante la etapa de prueba del mismo o de desarrollo de aplicaciones que lo usen como componente integrado.

Además de dotar al módulo WIFI, de interfaz RS-232 mediante chips de adaptación de

niveles, la placa cuenta con las siguientes componentes potencialmente utiles de cara al desarrollo:

• 2 conectores de 10 pines para acceder a los puertos serie del módulo SX-550 sin pasar

por los adecuadores de nivel RS-232 • Un conector de 20 pines para acceso a pines GPIO, SPI, Alimentación • Un conector RJ45 Ethernet, que permite la conexión a red cableada • LEDs de status de alimentación y red y leds para monitoreo de GPIO • Switch de testing, que muestra los datos del módulo por consola serie y permite el

reseteo a valores por defecto del mismo. • Un pin de expansion de 18 pines GPIO para uso como pines de control de flujo

hardware • Un array de 3 pines para ruteo de la señal de SPI chip select.

Por ultimo en relación a su implementación, la placa alimenta al módulo a traves del

conector principal de instalación, el sistema esta basado en un regulador disipativo. Respecto al su uso, cabe mencionar el objetivo dedicado a cada uno de los puertos del

módulo SX-550 y que se conserva en el uso del mismo vía la placa de evaluación: El puerto serie 0 se usa para configurar a través de consola el módulo mientras el puerto 1 se dedica a la transmisión de datos.

Por ejemplo con el PC se puede configurar el módulo para que funcione como bridge ethernet - serie, lo cual se debe hacer vía el puerto serie 0 de la placa que a la vez corresponde al mismo puerto del módulo, al conectarse otro nodo de la red al servidor del módulo SX-550 y enviar paquetes de datos al mismo, este los reemitira a través del puerto 1 de la placa al PC.

En el apartado de elección de componentes se explican con mayor profundidad las

caracteristicas del módulo WIFI.

46

ROUTER SWITCH 4200G 3COM

El ordenador en el cual se trabajó la mayor parte del proyecto, no disponía tarjeta de red con funcionalidad MDI/X, es decir debia usar necesariamente cable de par trenzado sin cruzado para ir a otro nodo de la red como la placa de evaluación del microcontrolador, debido a que esta última tampoco disponía de esta funcionalidad y solo se disponía de cables de par tranzado no cruzado, de los que se usan en el departamento para conectar ordenadores a la red de la empresa, se usó este router que estaba disponible y sin usar en el departamento.

El disponer de este aparato permite, conectar la placa del microcontrolador, la placa de

evaluación del módulo WIFI y el PC en una mini-red local sin tener que conectar y desconectar continuamente. Por precaución de no enviar paquetes de datos del módulo WIFI y la placa electrónica a la red de la empresa, el router no se conectó nunca a la misma.

Su uso en el proyecto ha sido totalmente prescindible pero como otros elementos ha

ayudado a una mayor eficiencia en el trabajo y mejor aprovechamiento del tiempo. Se podria haber utilizado igualmente un switch de tres puertos, ya que debido al poco tráfico que habia

47

en la red creada ninguno de los módulos se veria perjudicado en cuando a la carga de CPU adicional que supone el recibir paquetes de datos ajenos.

IMAGEN 26: ROUTER 4200G 3COM

48

3.2. Herramientas software

Las herramientas software consisten en los principales programas que se utilizaron en el proyecto para llevarlo a cabo, executandose sobre las máquinas descritas en el capítulo de Herramientas hardware. El software controla el hardware y a su vez sirve para programar las aplicaciones que se diseñaron para el proyecto.

A continuación se enumera el software acompañado de diversas capturas. Para cada una de

las aplicaciones software utilizadas se muestra una captura del la pantalla principal de trabajo asi como una descripción de la funcionalidad básica de las mismas. Se describe también su aplicación especifica en el proyecto, haciendo especial incapié en cuales de las funcionalidades y opciones ofrecidas por el software han sido mas importantes durante la realización del mismo.

Con este punto se pretende dar una introducción al entorno de trabajo desde el punto de

vista del desarrollador que debe usar, tomando como soporte el PC, una serie de sub entornos dedicados a las distintas tareas que constituyen la realización del proyecto: Comunicaciones, diseño de hardware, de software embedded en C, Java etc

NET BEANS 5.5

IMAGEN 27: CAPTURA DEL PROGRAMA NETBEANS

49

Descripción NetBeans, es un entorno integrado de desarrollo (IDE) para editar código Java que se

puede obtener de manera gratuita de la página de Sun Microsystems. Aunque para el proyecto se ha usado una pequeña parte de su potencial, tras examinar los

menús del programa se puede ver que es un editor bastante completo. Permite la creación de proyectos definidos específicamente desde el inicio con la

aportación del programa de una plantilla adecuada a cada tipo, los diferentes proyectos que se pueden crear desde el “Wizard” del programa corresponden a los distintos tipos de aplicaciones Java que existen, tales como Applet, aplicación de consola, aplicación gráfica, beans etc.

El programa permite migrar fácilmente proyectos desde otros editores como el Java Studio.

De entre las muchas opciones interesantes que ofrece con diferencia a otros editores de

cara al desarrollo de aplicaciones online destaca el editor de flujo de páginas, soporte para JavaScript avanzado o edición avanzada CSS.

En especial, para el proyecto, ha sido muy útil su editor de paneles de aplicación ya que

con este programa el código de la parte gráfica de la aplicación diseñada es autogenerado a partir del diseño creado en este editor a base de añadir elementos gráficos como botones, etiquetas, marcos, subpaneles etc. Esto permite abstraerse de la programación en lo referente a la interface de la aplicación que se está creando y a la vez ahorrar una gran cantidad de tiempo de desarrollo. Pese a que se producen pequeñas diferencias entre lo que muestra el editor y la interface gráfica del programa generado estas son mínimas, por lo que se puede tener en todo momento una visión clara del resultado que se va a obtener.

HYPER TERMINAL

Descripción

Hyperterminal es un programa que viene incluido como accesorio del sistema operativo

Windows desde hace varias generaciones. Es un sencillo programa de consola de terminal para puerto serie, es decir un programa que

muestra por pantalla los caracteres que se reciben por el puerto serie del PC y envía por el mismo los caracteres que el usuario escribe en la consola.

Es una reminiscencia del software que incorporaban los antiguos terminales de datos que

se conectaban por vía puerto serie a una CPU central que se encargaba de realizar los cálculos complejos y que se usaban únicamente como interface con el usuario gracias al uso de teclado y pantalla. En el proyecto se ha usado para debuggar la comunicación entre los distintos

50

módulos con puerto serie (microcontrolador, tarjeta WIFI y módulo GSM/GPS) así como para prácticar el uso de los comandos de control y configuración de los módulos de comunicaciones.

Permite configurar los parámetros inherentes a un puerto de serie asíncrono, tales como la velocidad de transmisión, bit de paridad, bit parada, longitud de la palabra (carácter) así como el puerto del PC que se desea usar.

Además permite la configuración de otras opciones del programa tales como la

representación de los caracteres especiales, la transmisión de carácter de retorno de carro y de nueva línea al pulsar enter, el hecho de los caracteres escritos localmente etc.

Es un programa muy sencillo de usar debido a su limitado numero de opciones y a su

potencia en proporción, por ejemplo en lo relativo al uso de ficheros las únicas que permite son guardar la configuración actual o recuperar una al iniciar conexión de manera que no tenga que reconfigurarse el uso del puerto serie cada vez y por otra parte capturar en un fichero de texto los caracteres que van apareciendo en la consola.

IMAGEN 28: Captura del programa HYPERTERMINAL

51

ADVANCED SERIAL PORT TERMINAL v4.2 (Shareware)

IMAGEN 29: Captura del programa ADVANCED SERIAL PORT TERMINAL

Descripción El advanced Serial Port terminal, es otro terminal para puerto de serie. En concepto es muy parecido a Hyper Terminal pero con muchas más funcionalidades que

le dan una potencia bastante superior. Es decir, la función principal del programa es mostrar los caracteres que le llegan por el puerto serie y enviar por el mismo los carácteres que el usuario le introduce mediante el teclado.

La versión usada es una versión de demostración operativa durante 14 días, después de los

cuales se debe comprar la licencia del programa. Durante el proyecto se usaron dos versiones del programa ya que no se disponía de licencias y la empresa que lo edita permite una licencia de demostración con cada versión pese a ser instaladas en la misma máquina.

Respecto a las opciones más interesantes del programa cabe destacar la posibilidad de ir

viendo los caracteres en formato hexadecimal, como ocurre en la mayoría de programas editores de hexadecimal, en el Advanced Serial Port terminal se muestra el texto en forma de caracteres ascii en la parte derecha de la pantalla, y los valores en hexadecimal a la izquierda. Esta característica permite tener un total control sobre los caracteres especiales ya que no se enviaran a menos que se especifique ello mediante la introducción del valor de dicho carácter en el área de texto del programa, es decir se puede enviar un string sin caracteres especiales al final o bien se puede enviar poniendo solo retorno de carro, solo nueva línea o ambos. Esto ha sido muy interesante a la hora de trabajar con los módulos de comunicaciones ya que uno de

52

ellos (el módulo GSM/GPS) utiliza el carácter de nueva línea (\n) para definir el final de string (en la práctica comando AT) mientras que el otro módulo usa el otro carácter especial, el retorno de carro, para tal fin.

También resulta interesante para el proyecto el tener la posibilidad de tener múltiples

configuraciones abiertas en una misma instancia del programa (estas no son operativas simultáneamente por las limitaciones del puerto de serie y el protocolo de comunicaciones que implementa). Cada configuración tiene una pestaña en el panel del programa y permite ver logeada la comunicación que se ha mantenido bajo esa configuración, para cambiar de configuración se debe cerrar la actual mediante el menú contextual de la pestaña correspondiente y abrir la configuración que interese mediante el mismo menú de su pestaña asociada.

P-CAD 2004

IMAGEN 30: Captura de pantalla del programa P-CAD

Descripción:

El nombre P-Cad identifica a un paquete de programas orientados al diseño integral de circuitos electrónicos y que ofrece soluciones aplicables desde la fase de diseño de esquemas tanto digitales como analógicos a la de diseño del PCB así como otras tareas no enfocadas directamente a la fabricación física del circuito sino a su testeo y simulación.

53

En la el proyecto se ha utilizado la herramienta P-Cad schematic, que como su nombre

indica es un editor de esquemas electrónicos tipo Orcad schematic. En este editor vemos como objetos geométricos los distintos componentes que se usarán

en el proyecto, pudiendo crear y editar nuevos objetos con el P-Cad Symbol editor, una herramienta incorporada al P-Cad schematic. con este programa definimos parámetros del componente tales como el numero de pines, la longitud de estos, su ubicación, pich de separación entre pines y su forma geométrica, pudiendo hacer el componente parecido a como seria la pieza en realidad en cuanto a forma y disposición de los pines según su numeración y orden o bien desde un punto de vista mas practico agrupando pines según su finalidad o topología, con esto se fácilita el conectarlos en el esquema y permite que resultado sea visualmente mas sencillo.

El programa permite las funciones típicas de este tipo de editores, tales como edición de plantillas, zoom, realzado de mallas, etiquetas para los pines o conexiones, cajas de texto, uso de distintos colores, en todos los componentes, así como configuraciones gráficas, permitiendo cambiar el color del fondo del entorno de edición, distintos modos de rejilla etc.

PORT PEEKER

IMAGEN 31: Captura de pantalla del programa PORTPEEKER

Descripción:

PortPeeker, es una herramienta freeware de Binary Visions, desarrollada para su ejecución

en Se puede ejecutar en Windows 95, 98, 98SE, ME, NT, 2000, XP and 2003. Este programa

54

es simple en su utilización, básicamente permite ver el tráfico que hay en una red en un puerto concreto. Soporta los protocolos TCP, UDP e ICMP. El programa consiste en un solo archivo .exe por lo que no requiere instalación alguna.

Para el proyecto su utilización fue muy importante, por una parte durante el diseño del

software del microcontrolador y por otra durante la programación de la aplicación de demostración JAVA. De la misma forma que para el debugging del puerto de serie se usó el Advanced Serial Port Terminal el PortPeeker, permitió ver los mensajes que enviaban las distintas placas del proyecto a fin de eliminar los errores del protocolo.

Dado que la placa de evaluación del micro estaba controlada totalmente desde ethernet PortPeeker se uso junto con HyperTerminal para el debugging de los mensajes, con HyperTerminal se enviaban solicitudes al puerto de escucha de la placa y esta, una vez obtenidos los datos del hardware adecuado (placa GSM o WIFI) los enviaba al puerto de destino del ordenador donde escuchaba PortPeeker.

Por otra parte cuando se recibió el módulo Silex WIFI y se empezó a configurar mediante

consola la transmisión a través del bridge serie ethernet/WIFI, se usó PortPeeker para ver como el modo bridge una vez configurado en modo escucha de datos convertía los datos serie enviados por HyperTerminal a través de la consola a paquetes TCP/IP.

Una de las mayores ventajas de PortPeeker frente a otras aplicaciones es que permite ver los datos recibidos como valores hexadecimales, aspecto crítico en el proyecto ya que la forma de en que el microcontrolador evalúa los mensajes enviados desde el PC, es reconociendo caracteres de final de línea o retorno de carro con lo cual los caracteres no alfanuméricos deben de poder evaluarse correctamente.

55

4. Desarrollo Hardware

4.1 Diagrama de Bloques del hardware 4.2 Selección de módulos (GPS/GSM, 802.11a, VFIR, regulador) 4.3 Diseño del bloque de alimentación 4.4 Diseño del bloque de procesado 4.5 Diseño de los bloques de comunicación 4.6 Revisión de esquemas y puesta en marcha de la placa de evaluación

4.1. Diagrama de Bloques del hardware Partiendo de la idea definida en el enunciado del proyecto y tras la elección de los

componentes que resultaban mas apropiados por sus prestaciones para la creación del prototipo del módulo V2VCU, se procedió a hacer un primer diseño externo del prototipo, solo a efectos de ir dando forma al proyecto en lo relativo a su parte hardware. En este se mostró la disposición que podrían tomar los componentes principales de la placa y también sin detalles profundos los buses de datos principales del sistema y la interacción existente entre los mismos. Como objetivo secundario se buscaba tener un diagrama simple que poder usar en una presentación del producto que se estaba diseñando, por tanto el diagrama debía sintetizar la idea de manera concisa y sin detalles complejos de manera que fuese asequible a personas no familiarizadas con el proyecto en concreto.

Dicho diseño creado en Power Point, sirvió también para mostrar a los demás integrantes

del departamento y al director del mismo, que concepto se iba seguir para el diseño de la placa, y someter así estas primeras ideas a examen.

En el diagrama básico inicial, se mostraba una configuración del módulo separado en dos

PCBs conectadas mediante cable plano a través de cual pasaban todas las señales de control del micro a los módulos incluyendo buses de datos ya que una de las PCBs iba a contener el hardware de procesado, el microcontrolador, y los dispositivos periféricos de este, como el clock, conectores de expansión, conectores ethernet, leds genéricos y el integrado de conversión de tensión

En el segundo PCB, la placa de “periféricos de comunicaciones” iba a contener los

diferentes módulos electrónicos de comunicaciones y su electrónica auxiliar, de nuevo clocks, componentes pasivos (resistencias, diodos, condensadores…), así como un integrado de conversión de tensiones especifico para la placa.

En la parte superior se situó el módulos GSM, ya que según mostraban los datasheets, los conectores de GPS y GSM estaban en la parte superior y de esta manera sería mas fácil la conexión de las antenas externas, además situándolo con esta orientación y posición, debido a que el módulo GSM es bastante mas pequeño que el módulo WIFI, se permitía colocar un porta tarjeta SIM externo sin tener que ampliar la anchura del PCB, esto haría mas ergonómica

56

la acción de cambio de tarjeta SIM, y evitaría tener que tocar el módulo electrónico para realizar las demostraciones.

Para mostrar la posibilidad de conectividad del módulo GSM/GPS a una cámara de móvil

para realizar funciones de envío de imágenes, se incluyo el diagrama de la cámara dentro del principal del V2VC, esta cámara se conectaría en caso de ser instalada mediante un cable plano a un conector situado junto al borde del PCB, de esta manera se podría meter en una caja el módulo electrónico, y doblando el cable que comunicaba las dos placas hacer un sandwitch, que permitiera que dicho conector quedara en un borde de la caja fácilitando la conexión de la cámara.

Al lado del conector anterior, se puede ver en azul un conector de expansión de audio, que

finalmente tampoco está en el diseño final y que ofrecería canales analógicos de audio para poder usar el módulo por voz, como si fuese un teléfono móvil común y permitiendo al mismo tiempo la interacción con la unidad de audio principal del coche en caso de que se requiriese la implementación de un sistema manos libres para la interacción usuario-V2VCU vía voz.

El módulo WIFI se situó en la parte inferior del diagrama, los conectores de antena no se

muestran ya que en el momento del diseño se barajaba el uso de dos posibles módulos WIFI, ambos de dimensiones parecidas de distintas empresas y con layouts totalmente diferentes.

Finalmente en el centro de la placa se sitúa el integrado de IR, mostrando su vía de

comunicación principal por un lado hacia el micro, a través del bus SPI que pasa por el cable plano principal entre las dos placas y por otro hacia el transceiver que se sitúa en un extremo del PCB de nuevo contemplando la posibilidad de meter el sistema en una caja y a la vez se satisfacen los requerimientos de “visión” de esta pieza que debe tener acceso al exterior de la placa sin que otros componentes obstaculicen la llegada/salida de datos a este componente.

IMAGEN 32: Diagrama de bloques vista general. Planteamiento inicial

S12X uC

WI-FI MODULE

UART1

UART2

SPI

sim card

IR

GSM/GPRS & GPS

MODULE

Tranship photo cameraZIF camera connectorAudio expansion connector

GPS Antenna connector GSM Antenna connector

IR

Ethernet connector

STATUS

Power connector

Status LED array

MC9S12NE64V

RE

CLK_OSC

PWR

ETH CO

57

En una revisión de la placa tras una la reunión con diferentes miembros del departamento se decidió que la implementación definitiva del módulo V2VCU constaría de una sola placa, a fin de incrementar la fiabilidad que podría verse comprometida por el uso de elementos conectables, como jumpers y a la vez prescindibles como los cables planos de unión entre placas. A la vez se reducía el numero de componentes al tener la posibilidad de usar un integrado dual para la adecuación de la entrada de alimentación para las dos partes del V2VCU procesado y comunicación., implementación de los buses de comunicaciones sobre PCB, etc.

El diseño presentado

IMAGEN 33: Diagrama de bloques vista general. Planteamiento inicial

Este es el esquema se siguió a la hora de diseñar el layout definitivo que se entregó al

fabricante.

S12 uC

WI-FI MODULE

UART1

UART2

SPI

sim card

IR

GSM/GPRS & GPS

MODULE

Tranship photo cameraZIF camera connectorAudio expansion connector

GPS Antenna connector GSM Antenna connector

IR

Ethernet connecto

STATUS

Power connecto

Status LED

MC9S12NE64V

CLK_OSC

RE

PWR

ETH CON

58

4.2. Selección de módulos (GPS/GSM, 802.11a, VFIR) Una tarea de estudio prévio al inicio del diseño de un módulo electrónico es la selección de

componentes que se van a usar en el proyecto, que toma como base las especificaciones del mismo en cuanto a funcionalidades requeridas, tamaño, peso, resistencia térmica, resistencia mecánica, precio, velocidades de transmisión o de procesado entre otras.

Para la realización en el departamento de investigación de un primer prototipo de un

módulo electrónico como el V2VCU , se da mas peso a características como la practicidad de uso durante el desarrollo, es decir fácilitar la puesta en marcha, la depuración del código, la habilitación/deshabilitación de distintas partes del código etc. Que a otras tales como la reducción de tamaño de los componentes y la placa, el nulo contenido en plomo de los componentes etc.

Muchas de las características del módulo requeridas en caso de llegar a fabricarse variarían de un cliente a otro, por tanto en el caso del V2VCU, solo se ha sido rígido en el cumplimiento de algunas características automotive genéricas, como es el caso de la resistencia térmica a un valor de cómo mínimo 85 grados. Por supuesto se deben satisfacer los requisitos aportados en cuanto a funcionalidad del módulo, es decir, medios de conectividad, velocidad de transmisión si la hubiera, numero de procesadores y a un nivel de abstracción mas alto aplicaciones finales mínimas que debe ser capaz de implementar.

GSM

Para el módulo V2VCU, uno de los requisitos principales e imperativos era que tuviera

conectividad GSM a fin de poder implementar comunicación de largo alcance en caso, necesaria para llevar a cabo la ejecución de funciones telemáticas como la llamada de emergencia en caso de accidente.

El primero de los módulos que se buscaron en la fase de elección de componente fue el

módulo GSM. Como requisito técnico exclusivo del módulo, aparte de los mencionados como relativos a todos los componentes automotive se tuvieron en cuenta algunos tales como el tamaño el tamaño del módulo, la capacidad de comunicarse en distintas bandas de frecuencia, la posibilidad de envío/recepción de voz y datos, la disposición de conexiones para el uso de componentes externos como un porta tarjetas SIM no integrado etc.

Respecto al tamaño, desde un primer momento se mantuvo la idea de usar una solución

integrada, es decir un único módulo que incorporara una etapa de radio y una de procesado de manera que todo el protocolo de negociación con la red GSM, envío de tramas etc. Tuviera lugar de manera totalmente transparente para el microcontrolador principal del módulo V2VCU. Por ello todos los transceptores estudiados tenían un tamaño adecuado a nuestro proyecto, siendo la longitud del mas grande de unos 60 mm.

59

De entre las marcas que disponían de modelos embedded, es decir todo-integrado, solo tres tenían productos interesantes en cuanto a precio, comercialización actual, fácilidad para conseguir muestras etc. Sony m2m, Siemens y Telit. Las características de los módulos estudiados pueden verse en la tabla siguiente:

Fabricante Modelo

Foto Datasheet

Sony-Ericsson GA64

-Quad Band GSM

-GSM/GPRS Class 10

-2x UART Connectivity

-Integrated TCP/IP stack

-Power supply: 5.0VDC ± 10%

Sony-Ericsson GM41

-Dual Band EGSM

-GSM/GPRS Class 8

-Extended temperature range

-Power supply: 5.0VDC ± 10%

Siemens AC75

Power supply:

-3.3-4.5V

-Serial interface (ITU-T V.24 protocol)

-Dual-Band GSM 900/1800 MHz

Siemens AC45

No disponible en la web, solicitado y obtenido por mail.

Telit GM862-GPS Modem

Product description:

http://www.telit.co.it/data/uploads_EN/products//80272st10019a_GM862_Prod_Descr_r4.pdf

60

Telit GE863-GPS Embedded

Product description:

http://www.telit.co.it/data/uploads_EN/products//80278ST10016a_GE863_Prod_Descr_r6.pdf

Software manual:

http://www.telit.co.it/data/uploads_EN/products//GE863-GPS_Software_User_Guide_r1.pdf

Hadware manual:

http://www.telit.co.it/data/uploads_EN/products//1vv0300714_GE863-GPS_Hardware_User_Guide_r4(1).pdf

Al inicio del proyecto según informaciones de Sony-Ericsson Francia, la división de Sony

de módulos embedded fue adquirida por Wavecom. A partir de este hecho los módulos estudiados de Sony-Ericsson no iban a seguir fabricandose.

Se estudiaron entonces algunos modelos Wavecom a partir de los datos suministrados por un distribuidor de Wavecom que presento los módulos GSM que ofrecía esta marca y se vió que no satisfacían las necesidades del proyecto en cuanto a prestaciones de lo módulo. El problema que presentaba Wavecom era que la gama casi al completo de GSM se componía de módulos stand-alone, capaces de ser programados y de funcionar en solitario gracias a su gran capacidad de procesado, ya que su aplicación mas frecuente era su uso en productos que no formaban parte de una arquitectura electrónica compleja, tales como máquinas expendedoras, letrinas portátiles, etc. Estas capacidades consecuentemente incrementaban el precio del producto y lo hacian inapropiado para su uso en el V2VCU.

Con los módulos de Siemens ocurrió lo mismo, el distribuidor de Siemens informó sobre

cambios en la gama. Iban a aparecer próximamente en sustitución de los dos modelos estudiados otros nuevos diseños. Pese a que en el prototipado de módulos en el departamento de investigación la continuidad de los componentes en el mercado no resulta tan critica como en los departamentos de ingeniería de producto se debe evitar el usar componentes cercanos al fin de su vida comercial a fin de garantizar una posible extensión en el desarrollo y su posible producción en serie en el futuro.

El distribuidor de Siemens informó de la próxima aparición de módulos prestacionalmente muy interesantes. Estos integraban en el mismo encapsulado una parte de procesado, combinado con una electrónica para transmisión GSM y a la vez un módulo GPS, lo cual permitía ahorrar en buses de comunicación del microcontrolador principal, a la vez que simplificaba el diseño y aumentaba en consecuencia la fiabilidad al tener que usar menos componentes en el proyecto.

El problema con estos módulos consistía en el desconocimiento por parte del distribuidor de la fecha de lanzamiento de los mismos, ni siquiera como muestras para desarrollo. En

61

consecuencia no resultaba interesante para un proyecto con un timing tan estricto y tan corto como el V2VCU.

MÓDULO ELEGIDO La tercera alternativa, los módulos Telit resultaron muy interesantes una vez vistas sus

características. Por una parte los módulos llevaban varios años en el mercado lo cual da una idea de que han tenido una fase de testeo suficiente, en la pagina web se dispone de una gran información relativa a cada modelo incluyendo hojas de características, application notes, manuales de integración de hardware y de software etc. Además la empresa había trabajado con el distribuidor de Telit en España, ARROW con lo cual se fácilitaban los tramites para conseguir datos, muestras, etc.

A nivel técnico los módulos Telit GM862-GPS y GE863-GPS eran muy adecuados a los

requerimientos del proyecto, teniendo rangos de funcionamiento de temperatura automotive, precio ajustado, tamaño contenido, un gran nivel de integración y posibilidades de expanion externa. Lo mas detacable era que estas versiones de los módulos GM862 y GE863 tenían integrado un GPS con lo cual se conseguían todas las ventajas proporcionadas por los módulos de los otros fabricantes sin tener que pagar un precio mayor por una potencia de calculo innecesaria ni aceptar un tamaño mayor del módulo que haria menos compacto el V2VCU.

Ambos módulos comparten toda la funcionalidad, siendo su única diferencia a nivel de

integración un hardware distinto, que hace que el GE863, sea un módulo algo mas ligero, no incorpore SIM holder interno ni conectores integrados en el módulo y su instalación en la placa madre sea vía soldadura de BGA (Ball Grid Array) en lugar de a traves de un conector PCB-PCB (Molex ref.53748-0504) como en el GM862.

Otra caracteristica de los módulos Telit es que su firmware permite la trasmisión de

imagenes desde una camara TRANSCHIP TC5747, vía GPRS de manera trasnparente al usuario, ya que solo se debe enviar al módulo electrónico una serie de comandos AT que solicitan al módulo GPRS la captura y envio de una foto a un terminal remoto.

En la documentación de los módulos se explica el uso de este periferico, tanto a nivel de software como de hardware. En el ‘SW user manual’, se describe la secuencia de comandos AT necesaria para configurar el módulo para su uso con las camaras soportadas asi como ejecutar la captura y envio de las imagenes y en el ‘HW user manual’ se describen los pines del módulo que hay que conectar a la camara, datos mecanicos de la camara y el conector, circuitos de alimentación para la camara entre otros detalles.

62

IMAGEN 34: Detalle de datos mecánicos de la cámara TRANSCHIP TC5747 para su integración

Esta tiene interfaz I2C, la mayoría de pines son GPIO del módulo, que no se podrán usar

para otro fin si se dedican a la camara, en cualquier caso el integrador solo debe preocuparse de conectar correctamente el pinout de acurdo con lo descrito en el documento, esto hizo que se planteara la posibilidad de implementar una plicación de seguridad relativa al envio de imagenes en caso de accidente, finalmente se diseñó el PCB con pads de soldadura para los componentes inherentes a la instalación de la camara, pero no llegaron a instarse ni a comprarse las camaras.

WIFI

Como se ha dicho, el protocolo de comunicaciones C2C que se estandarizará en el futuro

se encuentra aún bajo desarrollo, no obstante se sabe que este emitirá en la banda de los 5.9 Ghz como se ha comentado previamente. Esta es la banda de frecuencias libre que mejor se adapta a los requerimientos de esta tecnologia y por permitir compatibilidad entre los estandares Europeos y Americanos.

Dado que el estandar aún no está definido, en las especificaciones del prototipo V2VCU se especificó que se debia montar un transceiver 802.11a, debido a que dicho protocolo trabaja en la misma banda de frecuencias en este caso centradas en 5.8 Ghz aproximadamente.

Durante la fase de búsqueda y selección de módulos se vio que existe una oferta bastante

amplia de módulos embeeded orientados a ser integrados en prototipos mayores. La mayoría de estos módulos tienen interfaces que los hacen inapropiados para el prototipo bajo

63

desarrollo, la mas frecuente es la interfaz miniPCI muy usada en dispositivos portatiles industriales. El porcentage de módulos con interfaz serie encontrados ha sido realmente bajo.

Por otra parte el protocolo 802.11a es el protocolo de transmisión Wi-FI, menos popular en

el mercado, debido principalmente a los costes que supone su fabricación, impuestos por el hecho de trabajar a una frecuencia el doble de alta que el resto. Por ello la práctica totalidad de los módulo embeeded con interfaz serie trabajaban sobre los protocolos 802.11b/g.

Finalmente a lo largo de la etapa de búsqueda de componentes, solo se encontraron dos

módulos 802.11a interesantes, estos son:

DIGI ConnectCore Wi-9C

Este módulo electrónico embeeded, sustituye a un anterior modelo de la marca que solo tenía capacidades wireless y es pin-to-pin compatible con el mismo, esta pensado para su integración en prototipos que como el V2VCU necesitan transmisión WIFI y donde la integración total no es critica, su interfaz fisica principal con el exterior es un conector SO-DIMM.

Este módulo ofrece conectividad por Ethernet 10/100 Mbit por cable y 802.11a/b/g wireless

LAN y cuenta con unas prestaciones muy altas dentro del mercado de módulos embedded, cabe destacar que su CPU es un microcontrolador tipo ARM9, NetSilicon® NS9360 a una frecuencia de 177Mhz. Cuenta con 256Mb de memoria RAM y 256 de Flash.

Ademas de la interface serie, se puede conectar al prototipo base por I2C, y por USB.

IMAGEN 35: DIGI ConnectCore Wi-9C

SILEX SX-550 El otro módulo disponible lo fabrica SILEX technologies, y sigue un concepto muy

diferente al DIGI, el módulo SILEX SX-550, es mucho mas compacto en lo que a superficie se refiere.

64

Ofrece interfaces serie y SPI, dedicandose este ultimo solamente a la configuración, que se puede hacer tambien a través de uno de sus puertos de serie, de los cuales tiene dos, uno dedicado a configuración del módulo y otro a la transmisión de datos entre el micro externo y el módulo, estos puertos pueden trabajar a frecuencias de hasta 921 Kbps en caso de implementar control de flujo por hardware.

La interfaz física con el exterior es un conector standard de 40 pines con un pich de

1.27mm. A traves de su conector, puede conectarse a red cableada, dispone de pines GPIO

disponibles, asi como dos puertos serie a 3.3V para su conexión en prototipos. Admás del conector principal tiene dos conectores de antena, uno de los cuales se usa para

conectarlo a la antena principal y otro para a una antena secundaria opcional. El módulo SILEX-550 es un kit de dos PCBs, una de las cuales constituye de por si un

módulo funcional con capacidades de conexión a ethernet cableada, y que se conecta directamente al PCB del prototipo bajo diseño y otra auxiliar que implementa los sistemas de comunicación vía radio del módulo, que es la que lleva los conectores de antena.

En oposiciñon al módulo DIGI, el SILEX, no permite gravar codigo propio en el módulo

por lo que está orientado en exclusiva a su uso como periferico, caso del V2VCU.

IMAGEN 36: Vista inferior de la placa de proceso del módulo SILEX SX-550

65

IMAGEN 37: Esquema de las dimensiones de la placa para su integración en prototipos

MÓDULO ELEGIDO

El módulo seleccionado para el V2VCU, fue el módulo SILEX SX-550.

Es un módulo de menor tamaño y mas fácil de integrar debido a su interfaz física estandar. Es un módulo mucho mas barato y adecuado desde el punto de vista de diseño de un

módulo electrónico por parte de una empresa de fabricación de módulos automotive, como es Lear, donde el precio de cada componente usado es crucial para ganar la asignación de los proyectos ofertados por los clientes.

Su sencillez es otro punto a valorar sobre el módulo DIGI, ya que permite dominar la placa

en menos tiempo.

A parte de las razones mencionadas, que son las principales, hay otros aspectos que hcieron adecuada su elección para el proyecto, como son, las fácilidades que dió la empresa fabricante para conseguir el kit de evaluación de manera gratuita, el soporte técnico y la información que proporcionaron durante el transcurso del proyecto.

Las caracteristicas básicas del módulo de cara a su integración son las siguientes: • Interface serie UART (RS-232) x 2 puertos; hasta 921Kbps • Interface Ethernet 10Base-T and 100Base-T (autoconfigurable) • Interface Wireless 802.11a/b/g; 54, 48, 36, 24, 18, 11, 9, 6, 5.5, 2, y 1

Mbps; 2.4GHz banda ISM

66

• Alimentación 3.3VDC (a través de conector estandard OEM de 40 pines) • Consumo (I) 628mA max transmitiendo; 294mA en espera • Protocolos soportados ARP, TCP, Telnet, ICMP, SNMP, DHCP, BOOTP, Auto IP,

HTTP, SMTP, TFTP, SLP, DNS, Dynamic DNS • Securidad Wireless WPA and WPA2 (modos personal y enterprise), PAP, MS-

CHAPv2, 802.1x EAP with TLS/TTLS/ LEAP/PEAP/FAST, WEP

ANTENAS

IMAGEN 38: Detalle de las antenas, de arriba a abajo: WIFI, GPS y GSM

Tras la lectura de los datasheets de los distintos módulos se vió que la elección de las antenas es crítica para lograr el máxmo rango de alcance y una calidad de transmisión aceptable.

67

El módulo WIFI requería antenas especificas para transmisión a 5.9Ghz bastante difíciles de encontrar en el mercado por la poca difusión a nivel de aplicaciones domésticas del protocolo WIFI 802.11a, que es el que como se ha dicho previamente se ha utilizado en el proyecto en sustitución del protocolo 802.11p para nodos moviles, aún bajo desarrollo.

Tras buscar antenas compatibles a través de internet y debido a la dificultad para encontrar

descripciones detalladas de las mismas en las webs de los distribuidores, se decidió solicitarlas a Silex si una vez comprovada la capacidad de la antena suministrada esta era suficiente para el proyecto. Las pruebas a este respecto no se llegaron a realizar por lo que usó el módulo Silex sobre ethernet cableado, dicho módulo transmite simultáneamente por WIFI y ethernet si no se desactiva expresamente alguna de las dos redes. La antena suministrada por Silex es una antena de 5dB onmidireccional con un conector SMT ultraminiature.

Para el GPS, dado que el módulo Telit GM862-GPS no cuenta con amplificación interna

se utilizó una antena activa MMCX, la antena disponía de conector SMA y se usó con un adaptador SMA a MMCX, formato presente en el módulo Telit. La antena corresponde al modelo SHARK GPS 01.

Para GSM se utilizó una antena quadribanda/ 3G de 300mm con conector MMCX

angulado.

CONTROLADOR VFIR

Los sistemas de transmisión IR de ultima generación se basan en el soporte del estandar

IrDA, según este estandar se definen varios rango de velocidad de transmisión de los sistemas. Las velocidades definidas y sus identificadores (acrónimos) son: SIR (115.2 Kbps), MIR (1.152 Mbps), FIR (4 Mbps) and VFIR (16 Mbps).

Para la transmisión por IR en el V2VCU, se busco un controlador capaz de transmitir a

muy alta velocidad según la definición del IrDA. La mayoría de los integrados disponibles trabajan a velocidades de trasnmisión bajas, desfasadas en proporción a la que se consigue por medios cableados de bajo coste. La principal aplicación de estos controladores a lo largo de los ultimos años ha sido la de comunicar perifericos ofimaticos portatiles tales como PDAs con PCs e Impersoras, Calculadoras cientificas con PCs, etc., que frecuentemente no necesitaban elevadas velocidades de transmisión porque transmitian cantidades de datos limitadas. Hoy en dia los flujos de datos que es capaz de manejar este tipo de dispositivos ha crecido exponencialmente, pero debido a la aparición de tecnologias mas fáciles de usar, tales como el WIFI o el BLUETOOTH la evolución de los transceptores de IR, se ha estancado.

68

Esto da como resultado que sea complicado encontrar controladores que soporten el estandar FIR.

SIGMATEL STIR 4230 Tras analizar multitud de controladores la mayoría de los cuales no ofrecian unas

presataciones que satisfacieran los requisitos del proyecto en cuanto a velocidad de transmisión, se encontró un diseño reciente de la empresa SIGMATEL, fabricante de integrados para aparatos multimedia, de entretenimiento e impresoras multifunción. El integrado es el SIGMATEL STIR 4230. Se trata de un controlador de pequeño formato (16-PAD QFN) capaz de transmitir según los estándares VFIR, FIR, MIR y SIR con tasas de transferencia (VFIR) que alcanzan los 16 Mbits/sec y que es compatible con IrDA.

Este es junto con el transceptor TFDU8108 el componente básico del sistema de transmisión IR del prototipo V2VCU.

En comparación con otros métodos de transmisión, el STIR4230 proporciona un

rendimiento teórico máximo muy alto, como se puede ver en la siguiente comparativa ofrecida por el fabricante:

IMAGEN 39: Comparativa de velocidades de transmisión para distintas tecnologias wireless

69

REGULADOR / CONVERTIDOR DE TENSIÓN

Los requisitos de tensión del prototipo heredados de los de cada uno de los módulos

integrados son 3.3, 3.8 y 1.8V, del canal de 3.3 se alimentan el micro, y el módulo WIFI, el de 3.8V se usa para el módulo GSM, por ultimo el controlador de VFIR funciona a tensión de 1.8.

Los requisitos para el regulador, en principio se limitan a que el integrado seleccionado sea

automotive y pueda cubrir los requerimientos de corriente máxima que describen los datasheets de los componentes.

El nombre del integrado utilizado es LT3506. Este es un convertidor de tensión dual, es

decir con dos salidas cuyas tensiones pueden ser distintas. Debido al echo de haber usado este conversor de tensión para otro proyecto del departamento se disponía de una hoja de cálculo de valores de los componentes pasivos asociados. El ajuste de estos permite conseguir unas tensiones de salida específicas.

Para alimentar al controlador VFIR, se usó un regulador lineal automotive de Infineon, que

cumple con los requisitos de corriente de dicho módulo y ademas viene ajustado internamente para ofrecer una salida de 1.8V. Como se trata de un regulador de voltage y no de un convertidor conmutado se decidió colgarlo del convertidor principal, en la salida de 3.8V, que se previó menos cargada que la de 3.3V, ya que de esta ultima se alimentan el micro y el módulo WIFI. Mediante esta medida se consigue que el regulador deba disipar una energía mucho menor a la necesaria en el caso de colgarlo de la entrada de batería directamente no obstante debido al bajo consumo del controlador STIR el regulador lo hubiera soportado sin poner en peligro su fiabilidad.

4.3. Diseño del bloque de alimentación Como se ha dicho previamente, el circuito utiliza como regulador principal un convertidor

de tensión de alta frecuencia para regular la alimentación a los valores necesarios para los componentes montados en el prototipo.

70

El convertidor se puede regular para distintas tensiones de salida, para lo cual, necesita de una serie de componentes pasivos, que definen su comportamiento en el circuito, definiendo básicamente la tensión de salida, en este caso resistencia

El integrado es dual, es decir tiene dos convertidores en el mismo encapsulado, el diseño

de ambas partes es similar, cambiando solamente los componentes pasivos que condicionan las tensiones de salida y el equilibrio del lazo de control interno de la misma.

En el diseño, se deben seguir los pasos especificados en el datasheet para obtener los valores de los componentes pasivos que conseguirán en la salida una tensión estable del valor deseado. La inductancia a la salida y condensador asociado actúan específicamente sobre el rizado que se produce a la salida inmediata del chip por la naturaleza del conmutador, el divisor de tensión compuesto por las resistencias R1 y R2 condicionan la tensión de salida que dará el convertidor ya que condicionan el factor tensión de salida/ tensión de feedback que sensa el convertidor.

Como se puede ver en esquema adjunto, los dos convertidores contenidos en el integrado

están unidos por dos pines, estos corresponden a la salida PG del convertidor de 3.3V (convertidor 1, a la derecha en el esquema) y la entrada RUN/SS del de 3.8V (convertidor 2), a la izquierda en el esquema). Esta conexión junto con el condensador unido a dichos pines y a masa, explota la funcionalidad de arranque secuencial de los convertidores y la de soft start del convertidor 2, esto es, se consigue que el convertidor 2 no active su salida hasta que el convertidor 1 esté funcionando y tenga la tensión de su salida estabilizada, una vez suceda esto se activará la tensión de salida del convertidor 2, esta por estar activada a través del pin RUN/SS irá subiendo paulatinamente (soft start) hasta el valor de salida configurado. Conectando los convertidores de esta manera el micro dispone de algún tiempo para arrancar

antes de que lo haga el módulo GSM y el controlador VFIR, evitando así que estos últimos puedan llevar a cabo alguna acción indeterminada debido a que previamente al startup del micro el estado de sus salidas no esta determinado. INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 40: Esquema electrónico del bloque de alimentación del módulo V2VCU

FIN DE INFORMACIÓN CONFIDENCIAL La mayoría de los valores componentes pasivos son fácilmente deducibles a partir de la

información de los data sheets, no obstante como se ha dicho se contaba con una hoja de calculo Excel para el calculo automático de dichos valores a partir de la tensión e intensidad

71

de salida deseadas, y que permite ver la acción directa de los cambios sobre la intensidad máxima de salida, los máximos valores de tensión admisibles, y la tensión de salida.

Por otra parte, el fabricante del conversor ofrece una aplicación de simulación para sus

integrados, con la cual se testeo la salida de los conversores y se hicieron varias pruebas para analizar la complicación de que el segundo regulador lo accionara el micro según lo mandara el software, finalmente se optó por una opción mas sencilla y en consecuencia menos arriesgada, el encendido secuencial que se ha comentado.

A continuación se muestra la aplicación de simulación del fabricante con el diseño bajo desarrollo y la hoja de cálculo descrita:

IMAGEN 41: Captura de la hoja EXCEL para calculo de valores de componentes externos del regulador

INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 42: Captura del simulador de LINEAR mostrando el convertidor usado

FIN DE INFORMACIÓN CONFIDENCIAL

72

4.4. Diseño del bloque de proceso

MICROCONTROLADOR El microcontrolador usado en el V2VCU, ha sido el MOTOROLLA MC9S12NE64. En

otros proyectos del departamento se habían usado microcontroladores de la misma familia y en consecuencia se disponían de esquemas de los cuales se podrían aprovechar ciertas partes relacionadas con la alimentación, la configuración del micro, elección del cristal etc.

Así mismo se disponía de mucha información sobre este chip, tales como datasheets del mismo y de las distintas placas de evaluación. El disponer de dichas placas fue también un echo muy importante en la elección, ya que en el caso de diseñar un prototipo el diseño del software y del hardware pueden evolucionar en paralelo, de manera que una vez se disponga de la placa solo se deban hacer pequeñas adaptaciones en el código.

En un principio se evaluó la posibilidad de usar un micro mucho mas avanzado, como un

power PC MPC5567 ya que se disponía de una licencia para un compilador compatible con este micro y su uso permitiría una potencia de calculo mucho mayor producto en gran parte por soportar frecuencia de reloj de orden muy superior al micro finalmente elegido. El usar este micro hubiera ofrecido muchas posibilidades de conectividad ya que esta familia de integrados ofrece un gran numero de pines GPIO y suele disponer de gran cantidad de periféricos integrados, algunos de ellos son una Unidad Aritmético-Lógica de 64-bit que permite ejecutar en un solo ciclo una operación con dos números de 64 bits en coma flotante, controladores para transmisión serie sincronía y asíncrona (SPI y SCI respectivamente), controlador ethernet, mas de veinte timers de uso general, reloj de tiempo real etc. asi como de muchas posibilidades de configuración de las que un micro mas pequeño no suele disponer. Las posibilidades a nivel de rendimiento son incomparables a las del micro que se usó

finalmente, ya que el núcleo del modelo de power PC sopesado corría a una frecuencia recomendada de 132 Mhz mientras el chip de Freescale usado finalmente lo hace a 25Mhz, de igual manera la memoria de este micro es mucho mayor a la del micro usado finalmente, tanto en flash, 2Mb contra 64Kb como en RAM, 64Kb contra 8.

La decisión de no usar el Power PC, del que también se deponía de placa de evaluación se

debió a que era prioritaria su utilización en otro proyecto del departamento cuyo desarrollo de software iba a coincidir en el tiempo con el del V2VCU. Debido a que se disponía de una sola unidad del compilador y del hardware para debuggeo del software del power PC se iban a producir colisiones entre proyectos con toda seguridad.

Los requisitos del microcontrolador en cuanto a velocidad se cumplían con el

microcontrolador S12 de manera poco holgada, pero se estimó que serian suficientes si se efectuaba una programación eficiente orientada a satisfacer las interrupciones hardware de los distintos módulos. También se tuvo en cuenta que por ser un prototipo de un producto que no se iba a fabricar para su uso en vehículos reales sino para demostración se podrían limitar las exigencias a satisfacer en cuanto al uso simultaneo de los distintos módulos de comunicación de los que iba a disponer.

73

En cuanto a los requerimientos relativos a los puertos de entrada/salida que ofrecía el micro, un requerimiento básico era que dispusiera de puerto ethernet, ya que esta era la interface impuesta en la definición inicial del módulo, esta característica era satisfecha por el micro S12 que dispone de un controlador ethernet 10/100 Mbits/s que además necesita muy pocos componentes pasivos para ser utilizado. Sobre este aspecto se han utilizado los diseños de referencia de las dos placas de evaluación de las que se disponía y que usaban las posibilidades ethernet del micro.

En referencia a este punto un aspecto importante fue la búsqueda y selección del conector de ethernet RJ45, que es el componente pasivo mas importante del sistema de red del microcontrolador y que cuenta con una serie de bobinas internas que permiten al controlador estar aislado galvánicamente y protegido de picos de tensión.

Para la implementación de la placa V2VCU se usan los dos puertos SCI (puertos serie

asíncronos) del micro, que van conectados al módulo GSM y al módulo WIFI, a través de los pines RX/TX de cada puerto prescindiendo de los pines de control de flujo HW.

Igualmente se da uso al puerto SPI (síncrono) para la conexión al controlador VFIR de

Sigmatel, el uso del puerto SPI junto con la alta velocidad de transmisión ofrecida por el chip VFIR hizo que fuera selecciona para el proyecto.

IMAGEN 43: Aqruitectura interna del micro MC9S12NE64

74

Otras características interesantes del micro que no se usaron son:

• Conversor de 8 ADC de 10 bits, de 8 canales • Timer de 16 bits y 4 canales • Posibilidades de comunicación puerto I2C • 18 fuentes de wake up • Pines IRQs HW

4.5. Diseño de los bloques de comunicación

El apartado de diseño de los bloques de comunicación consta de varios subpuntos relacionados con las fases de diseño mencionadas anteriormente. Por una parte se debe garantizar la correcta alimentación de los tres módulos de

comunicaciones de los que dispone el prototipo V2VCU, el GSM/GPS, el de transmisión WIFI y el controlador de VFIR. Como se ha dicho en el apartado de diseño del bloque de alimentación se requerían tres niveles de tensión distintos que se han solucionado mediante el uso de un regulador y un conversor de tensión, como se verá mas delante en el punto de la puesta en marcha del prototipo, surgió algún problema de diseño debido a un dimensionado insuficiente del convertidor con respecto a la corriente máxima que este es capaz de ofrecer a los módulos.

Una vez resuelto el tema de la alimentación, se pasó a diseñar los canales de comunicación

entre el microcontrolador y los módulos de comunicaciones. En el caso de los módulos WIFI y GSM/GPS, la comunicación se realiza a través de los

puertos serie asíncronos del micro, es decir de los llamados SCI. Ambos módulos de comunicaciones pueden funcionar usando solo dos pines del micro cada uno, el pin de transmisión y de recepción de cada una de las UARTS incluidas. Pese a ello es imperativo en el módulo GSM/GPS que se usen las señales de control de flujo por hardware si se quiere usar la funcionalidad integrada de captura de imágenes a través de la cámara VGA, detallada en el punto de selección de hardware.

Por si se llagaba a instalar la cámara en el prototipo y debido a que el micro no tiene pines

dedicados a salida de control de flujo hardware directos del controlador del puerto serie, se usaron pines genéricos del micro para implementar dicho control por software.

A nivel de esquema para la comunicación con el módulo GSM/GPS además de los pines

del micro SCI0_RX y SCI0_TX (30,31) correspondientes a los canales de transmisión y

75

recepción del primer puerto de serie, se usaron los pines PA0~PA4 (60~63,77) para las señales RTS, CTS, DCD, DTR y DSR.

INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 44: Esquema del módulo de GPS en el V2VCU

FIN DE INFORMACIÓN CONFIDENCIAL Para el módulo WIFI, se prescindió del control por HW desde el principio ya que la placa

de evolución de Silex, usada durante el desarrollo se probó junto con la placa de evaluación del microcontrolador, y se conectaba a esta ultima y al PC mediante un cableado de dos vías que solo conectaba los pines de transmisión y recepción del módulo WIFI. Dado que mediante este tipo de conexión se obtuvieron resultados satisfactorios, a velocidades de transmisión altas se decidió el usarla también en el prototipo bajo diseño.

Por otra parte la implementación de control de flujo hardware se tomó como una medida que no debía suponer un incremento de velocidad importante en este caso ya que en este caso debería de implementarse por software en el micro.

INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 45: Esquema del módulo de WIFI en el V2VCU

FIN DE INFORMACIÓN CONFIDENCIAL

76

Por otra parte el controlador VFIR se comunica con el micro a través de puerto SPI, usando dos pines para transmisión y recepción, SPI_MISO, SPI_MOSI (34,35), un tercero para la transmisión de la señal del clock: SPI_CLK(36) por parte del micro y un ultimo SCI_SS (37) para la habilitación del controlador.

Una señal igualmente común a lo módulos WIFI y GSM/GPS es la de RESET, el micro

puede resetear a cada uno de estos módulos mediante la puesta a nivel bajo del pin PA5(78) en el caso del WIFI y la puesta a nivel alto del PA6(78) en el caso del GSM/GPRS. En el caso del WIFI la conexión entre el micro y el módulo de comunicaciones es directa de acuerdo a lo descrito en el datasheet de Silex.

Para la activación del reset del módulo GSM/GPS, en el datasheet se advierte que este pin

del módulo debe conectarse a un transistor de colector abierto para no interferir en el proceso interno de power on reset así como para la inhabilitación interna del módulo en caso de tensión insuficiente. Para satisfacer este requerimiento se usó un transistor con resistencias integradas DTC144E.

El reinicio del módulo VFIR según el fabricante se debe efectuar preferentemente a través

de comandos especiales transmitidos por SPI, por ello se decidió no usar la señal específica del controlador para reset del mismo.

Otro punto común del diseño relativo a los módulos fue la disposición de leds de status de

la transmisión de los mismos. Tanto el módulo GSM/GPS como el VFIR tienen pines dedicados a tal tarea, capaces de absorber suficiente corriente como para conectar un led directamente a los mismos. El cátodo del led se conecta al pin del módulo mientras que el ánodo va conectado al canal de 3.8 o 3.3 voltios para GSM y VFIR respectivamente a través de una resistencia limitadora adecuada.

En el módulo WIFI, con el objetivo de dar mayor flexibilidad al diseño y poder usar los

pines para otras tareas, se conectaron dos GPIO al microcontrolador directamente, la principal aplicación de estos es la transmisión del estatus al microcontrolador a fin de que este pueda aproveche los drivers de leds para mostrar el status en lugar de tener que sacar o dar toda la corriente que necesitaran sus leds de status del propio módulo.

Por último, los aspectos más interesantes de la fase de diseño del bloque de

comunicaciones se centran en los componentes periféricos del controlador VFIR. Este integrado debido a su elevada velocidad de transmisión usa un cristal de cuarzo dedicado, a una frecuencia de 24Mhz, la recomendada por el fabricante para obtener la máxima velocidad de transmisión, como fuente de oscilación junto con dos condensadores de 22pF.

77

INICIO DE INFORMACIÓN CONFIDENCIAL

IMAGEN 46: Esquema del módulo de VFIR en el V2VCU

FIN DE INFORMACIÓN CONFIDENCIAL

Los pines de transmisión y recepción del controlador se conectan directamente al transceptor TFDU8108, que funcionalmente hace las veces de driver del led integrado y de conversor a señal digital de los impulsos de luz IR recibidos. El mismo transceptor va conectado al cátodo del led de alta flujo HSDL-4220 a fin de lograr un incremento en la distancia máxima de transmisión, este led se alimenta de la pista de 3.3V a través de una resistencia limitadora de 270 ohmios con lo cual se consigue la tensión recomendada según el dataste. A fin de que el led pueda encenderse de manera rápida según los requerimientos del transceptor se disponen dos condensadores de 0.1 y 10 uF puestos a masa que darán al led la corriente necesaria durante picos de consumo.

Finalmente en cuanto al diseño relativo al uso del controlador VFIR, se ha montado un

DTE144E para conectar el pin de salida de interrupción del controlador VFIR al pin ~IRQ (55) del microcontrolador, consiguiendo interrumpir la ejecución del micro con una mínima corriente emitida por el controlador, según requisitos de diseño del datasheet del mismo.

78

4.6. Revisión de esquemas y puesta en marcha de la placa de evaluación Una vez realizado el esquema electrónico, se realizó una etapa de revisión del diseño. El

objetivo de esta es eliminar todos los errores de la placa. Consiste básicamente en repasar cada pin de cada uno de los componentes comparándolos con los de los diseños de referencia si los hay, recalcular los componentes pasivos que configuran los integrados, analizar notas referentes al montaje y a la ubicación de los componentes, comprobar que las etiquetas de los nodos no tienen errores y algunas otras tareas con la misma finalidad.

Paralelamente a este trabajo se realizaron reuniones de revisión con otros miembros del

departamento para que aprotasen portar distintos puntos de vista y experiencia de cara a detectar errores que se habieran pasado por alto. En una de ellas se aconsejó el uso de drivers para la iluminación de los leds en lugar de alimentarlos directamente de los pines del micro, se vió que había que poner una resistencia de pull up en el reset que se había olvidado, se añadieron dos diodos de protección en la etapa de regulación etc.

IMAGEN 47: V2VCU una vez montados los conectores de alimentación a falta de montar los drivers de los leds de estatus

Pese al análisis descrito al recibir la primera versión de los prototipos de un circuito de

nuevo diseño suelen descubrirse fallos de diseño que han pasado en el diseño a la fase de fabricación bien por no haberlos detectado bien por desconocer que lo eran. Es habitual por

79

tanto cuando se prueba una placa la primera vez que esta no funcione de manera absolutamente correcta y deban realizarse retrabajos sobre la misma.

El primer paso al recibir el circuito, a fin de garantizar la integridad del mismo es

alimentarlo con una fuente de alimentación y medir con un tester que las tensiones a la salida del regulador o el convertidor de tensión según el caso son las previstas. Un exceso de tensión fuera del rango recomendado por el fabricante deteriora los componentes a mayor velocidad, por tanto en caso de detectar un voltaje erróneo habría que analizar la causa sobre el circuito e intentar subsanarla.

En el proyecto el primer paso a seguir una vez se recibieron las placas fue soldar a mano

los conectores de alimentación, ya que estos se recibieron posteriormente al envio al montador de los componentes y por tanto no fueron montados por este, estos conectores son jacks macho de 2,1 mm en formato throughhole, los conectores de alimentación fueron soldados con una aportación de estaño suficiente como para cubrir bien las patas a fin de minimizar la resistencia de la corriente al circuito y el calor. Los módulos GSM/GPS tampoco estaban montados por le mismo motivo y se montarían posteriormente un poco mas adelante.

IMAGEN 48: Detalle de los conectores de alimentación del módulo V2VCU

Una vez soldados los conectores se alimentó una de las placas y se comprobó que las

tensiones de salida del convertidor eran las esperadas, en este caso 1.8V, 3.3V y 3.8 V, en este punto se midió tambien que el consumo no fuera excesivo en relación al valor que se habia calculado que podia consumir el circuito con los distintos componentes encendidos.

El test fué satisfactorio. En la misma etapa de análisis es importante observar el estado de los distintos

componentes en lo referente a su temperatura, en el caso de los micros esto es especialmente crítico pues el deterioro del mismo implicaria mucho trabajo por el formato de su encapsulado, que en el caso del V2VCU era un smd de 144 patillas, tras unos segundos alimentado el micro se calentaba relativamente bastante, cosa que se penso podia ser devida a una incorrecta configuración de los pines segun el micro viene de fabrica con respecto a la que se necesitaba en la placa. Ciertamente una vez programado el microcontrolador con los valores adecuados al diseño la temperatura se estabilizo a un nivel bastante bajo, no emitia calor excesivo.

Dando por echo que la integridad de la placa estaba asegurada se procedio al pogramar la placa por primera vez. Durante el desarrollo de la aplicación se programaba el microcontrolador usando una placa de evaluación, en esta el micro contiene un bootloader en

80

memoria que permite la programación del micro a traves de uno de sus dos puertos de serie que estan conectador a dos conectores de puerto serie DB9 mediante una pareja de integrados de adecuación de niveles a RS-232. En el caso de la placa V2VCU no se dispone de dichos integrados y conectores y hay que programar la placa mediante el conector JDM soldado en la placa para tal fin.

El programa software para programar la placa es el TRACE 32, un programma debugger

que con el soporte de un hardware generico emulador (Lauterbach) y un add-on de este especifico para cada familia de micros permite la programación del micro y su posterior depurado. Algunas de las funciones que permite son la ejecución del codigo paso a paso, insercion de multiples tipos de breakpoint incluyendo breakpoints avanzados condicionales en funcion del estado de variables etc y por supuesto permite ver el estado de variables internas incluso en tiempo de ejecución, la memoria del micro o los registros del microcontrolador.

IMAGEN 49: Emulador Lauterbach y captura de pantalla del programa TRACE32

Al conectar la placa al emulador el micro no respondía, no reseteaba y no podia grabar. Tras comprobar que el micro tenía tension en los pines adecuados y que en distintas placas

V2VCU pasaba lo mismo, analizando con un osciloscopio en los pines del circuito oscilador, es decir en los pines del cristal se vio que este no oscilaba.

81

El problema era debido a que la resistencia entre pines del cristal era demasiado baja, se habia definido por error con un valor erroneo, al cambiar la resistencia, se comprobo como la oscilación en pines del cristal era mucho mayor y adecuada para el microcontrolador del prototipo.

Una vez subsanada este defecto el tracer comunicaba con el micro pero no salia de reset,

se medio la tension en el pin de reset y se confirmo que este estaba asertado a nivel bajo continuamente lo que impedia el arranque del microcontrolador, este hecho era debido auna resistencia que no debia haber sido instalada. Esto habia detectado sobre el esquema durante la etapa en que la placa ya estaba en proceso de fabricación y montaje, comparando el diseño de la placa con uno de referencia de la placa de evaluación usada durante del desarollo del software del microcontrolador, la presencia de esa resistencia que en todo caso deberia haber sido por ejemplo un jumper unia el pin de reset a masa, con lo cual debido a la poca corriente que absorve el micro y a la resistencia de pull up permitia que se realizara continuamente un reset del micro.

INICIODE INFORMACIÓN CONFIDENCIAL

IMAGEN 50: Layout del PCB V2VCU fabricado

FIN DE INFORMACIÓN CONFIDENCIAL

82

5. Desarrollo Software

5.1. Diagrama de Bloques del software 5.2. Diseño de la interface SCI 5.3. Diseño de la interface SPI 5.4. Diseño de la interface Ethernet (TCP/IP, UDP) 5.5 Comunicación con GSM/GPS 5.6 Comunicación con 802.11a 5.7 Comunicación con VFIR

5.1. Diagrama de Bloques del software El módulo V2VCU, se caracteriza por presentar una arquitectura con múltiples periféricos

del microprocesador, tales como, el módulo GPS/GSM, el módulo IR, el módulo de comunicaciones WIFI, y salida al exterior vía el conector ethernet, a fin de conectarlo a un PC o a otro módulo embedded.

Para gestionar los puertos utilizados y poder acceder a cada uno de los diferentes periféricos, se ha programado software especifico para tal funcionalidad, en el caso del SPI y los SCI, que se usan para controlar los módulos VFIR (SPI), GSM/GPS (SCI) y 802.11 (SCI) el software se ha implementado desde cero siguiendo las especificaciones del data sheet del microcontrolador y por tanto abarcando todas las capas de aplicación incluyendo la de driver de bajo nivel.

En el caso del puerto ethernet, se ha implementado la capa de aplicación, así como la de acceso al driver. El driver esta implementado como parte de una librería llamada OpenTCP que permite configurar en muchos aspectos la transmisión así como elegir el protocolo de transporte etc. sin necesidad de conocer el uso de los registros hardware del microcontrolador.

Dado que el diseño consta de diversos periféricos “colgados” de un micro de potencia de calculo bastante limitada, y por el interés que tenía desde el punto de vista de realizar una programación avanzada y eficiente en el proyecto se optó por implementar un código donde los tiempos de ejecución de la rutina que implementa cada driver no fueran fijos, es decir, en lugar de realizar secuencial mente (polling) una lectura de los registros de estado de los distintos periféricos del sistema a finde ver si existen datos recibidos pendientes de ser tratados o buffers vacíos después del envío siguiendo un esquema temporal determinista se optó por programar rutinas de servicio a la interrupción para satisfacer el tratamiento de dichos eventos de modo que el bucle principal del programa solo se interrumpiera en este caso y se permitiera una uso de los distintos periféricos sin tener que limitar a priori el tiempo de proceso que se debe dedicar a cada uno de ellos evitándose así asignar potencia de calculo a un dispositivo que en muchos casos puede no tener nada que recibir o enviar.

83

5.2. Diseño de la interface SCI El funcionamiento de los módulos de GSM/GPS y WIFI a efectos de conectividad lógica

es muy similar, se basa en el envío de comandos AT, comandos AT extendidos e información RAW vía puerto SCI (serie) a velocidad constante y configurable.

Tras el estudio del datasheet y de algunos ejemplos de código escritos par

microcontroladores de la misma familia se inició la programación del driver encargado de la transmisión vía SCI.

Para poder recibir información vía puerto serie se realizaron una serie de pasos previos a la

implementación del código de la rutina de servicio a la interrupción del puerto a fin de configurar el microcontrolador de acuerdo al periférico que se le iba a conectar. Básicamente el SCI es un puerto serie asíncrono como el RS-232, en el caso del microcontrolador (SCI) los niveles son de 0-5V. Los parámetros a configurar son los mismos que se deberían de configurar en un PC para iniciar una comunicación vía serie, los pasos en concreto son:

-Configuración de velocidad, paridad, tamaño de palabra. -Habilitación de puertos y periféricos. -Habilitación de la interrupción.

Configuración de velocidad, paridad, tamaño de palabra. Como se ha dicho, para usar los dispositivos GSM/GPS y WIFI se usaron los puertos SCI0

y SCI1. Para la conexión del micro y los módulos de comunicaciones se definió un modo de comunicación serie a 115200 bps, palabra de 8 bits, 1bit de stop y sin paridad.

Estos parámetros se configuran dentro de una función llamada durante la fase de

inicialización del programa principal y como paso previo a la ejecución de cualquier transmisión sobre los puertos de serie. El registro en el que se configuran dichos parámetros es (SCIx_CTR1 siendo x 1 ó 2).

Posteriormente el código de inicialización de módulos configura el registro de control del

dispositivo (SCIx_CTR2), poniendo a activo el bit que define la habilitación/deshabilitación de los mecanismos de transmisión/recepción (bits SCIxCR2_TE y SCIxCR2_RE), así como para habilitación de la interrupción asociada al puerto para el caso de evento de recepción o de transmisión completa (bits SCIxCR2_RIE y SCIxCR2_TCIE). El proceso es común para el módulo WIFI y el GSM/GPS.

84

A continuación se expone la función de configuración del modo de comunicación, como se puede ver no se habilita la interrupción por transmisión completa, ya que al no haber rellenado el buffer de transmisión en este punto del código la interrupción saltaría directamente.

INICIO DE INFORMACIÓN CONFIDENCIAL

En este espacio en la versión integra del proyecto se muestra el código perteneciente a la

inicialización de los puertos SCI del micro

FIN DE INFORMACIÓN CONFIDENCIAL

Habilitación de puertos y periféricos.

Como se verá en el código mostrado mas adelante el control de los módulos GSM/GPS y

WIFI se basa en una máquina de estados, cuyas transiciones están condicionadas por los datos que devuelve el módulo de comunicación tras recibir un comando del micro. Al inicio del programa, como parte de la inicialización de los puertos se envía un string a cada módulo con el único objetivo de que estos devuelvan un string valido, esto hará que se ejecute la rutina de servicio a la interrupción (RSI o ISR) del puerto por el que se recibe dicho string (ver función Init_modules más adelante).

La mencionada máquina de estados esta implementada como dos máquinas de estado

independientes, una por cada puerto serie y módulo conectado, estas máquinas se ejecutan dentro de las respectivas RSIs de los puertos asociados. El proceso es común en ambas RSIs: ante la recepción por parte del micro de un string proveniente del módulo de comunicaciones conectado, según el estado actual en que se encuentre la máquina de estados y el contenido del string se realizarán unas determinadas acciones y en caso necesario se saltará al siguiente estado de la máquina.

La acción inicial a tomar al recibir un string por parte del módulo es analizarlo

descomponiéndolo en caso necesario para extraer la información contenida. Si esta es información compleja y de interés para usos posteriores se guarda en variables temporales,

85

este el caso que ocurre por ejemplo cuando el módulo GSM/GPS devuelve unas coordenadas GPS que el micro ha solicitado en el ultimo comando enviado.

De acuerdo al string recibido se procede a rellenar el buffer de salida del puerto serie asociado con un nuevo comando AT si se requiere de acciones adicionales por parte del módulo en cuestión. A continuación se habilitan los permisos de interrupción y se inicia el proceso de transferencia del mismo. En caso negativo, no se renuevan los permisos de interrupción y la máquina de estados queda detenida, hasta que el micro reciba una nueva petición externa, por ejemplo de un PC vía ethernet y reenvíe un nuevo comando al módulo de comunicaciones al cual este último contestará reanudando la ejecución de la máquina de estados e iniciando nuevamente el ciclo de análisis y toma de acciones mencionado.

INICIO DE INFORMACIÓN CONFIDENCIAL

En este espacio en la versión integra del proyecto se muestra el código perteneciente a la

inicialización de los puertos SCI del micro FIN DE INFORMACIÓN CONFIDENCIAL Código de la máquina de estados

A continuación se muestra un extracto del código de la máquina de estados del puerto

SCI1 correspondiente al control del módulo WIFI. Esta se implementa dentro de una estructura SWITCH CASE en la cual el índice identifica al estado actual dentro de la máquina.

Se puede ver como para cada estado se rellena el buffer de salida del puerto serie a fin de

enviar un nuevo comando al módulo WIFI.

86

Dado que la RSI se ejecuta cada vez que se recibe un byte completo por el puerto al inicio

de la función se examina si el byte constituye el final de un string devuelto por el módulo de comunicaciones según sea su valor, ya que el byte final de un string completo debe ser un carácter de escape. Dicho carácter de escape será bien de retorno bien de nueva línea (\r, \n), de esta manera en caso de no haber recibido un comando entero del módulo, se almacena el byte en el buffer de recepción y no se ejecuta la máquina de estados, saliendo mas rápidamente de la RSI y evitando consumo innecesario de tiempo de CPU.

En ocasiones, según el estado en el que se encuentre el módulo de comunicaciones

(configuración, bridge, ecable mode etc.) el módulo no devolverá un string completo y por tanto no llegará nunca el carácter de escape. En el código se tratan dichas excepciones capturando otras secuencias de escape, por ejemplo en el modo bridge, en el que el módulo WIFI envía al micro lo que le va llegando a través de ethernet/WIFI, si llega la secuencia “+++”. Esta secuencia en caso de ser detectada en la RSI hace que se proceda a ejecutar una iteración de la máquina de estados para saltar al siguiente estado, que permite configurar el módulo cuando llegue una nueva petición.

Del mismo modo, puede ocurrir que no importe el contenido del string devuelto por el

módulo como ocurre en el caso de las confirmaciones de comandos de configuración ejecutados que siempre devuelven respuesta positiva (“OK\n”), en ese caso el código no evalúa el contenido del buffer, como se puede ver en el case 69 del código adjunto.

Como parte final de la ejecución de un estado se rellena el buffer de salida con el comando

necesario y se procede a habilitar a través del registro SCI1CR2, la interrupción por envío completo, así como por recepción de byte y el inicio de la transmisión del buffer.

INICIO DE INFORMACIÓN CONFIDENCIAL En este espacio en la versión integra del proyecto se muestra el código perteneciente a la

máquina de estados que controla las comunicaciones sobre un puerto SCI

FIN DE INFORMACIÓN CONFIDENCIAL

Gráfico de la máquina de estados

A continuación se muestra un gráfico ilustrativo del funcionamiento de la máquina de estados usada para implementar el dialogo con el módulo GSM/GPS, correspondiente a un extracto del código real de la misma.

El software que implementa dicha máquina es muy similar en el caso del módulo WIFI, obviamente con las adaptaciones que exige el protocolo de cada módulo como las comentadas

87

en el punto anterior. Para más detalles sobre el código, se recomienda ver el anexo dedicado a este (Anexo 6).

Case 10

Set_buffer("AT+CPIN=5553\r");Habilitar_interrupciones();Set_next_state(13);

If(Byte received&&

End of String (‘\n’,’\r’))Then goto( current case)

Case 13

Habilitar_interrupciones();Set_next_state(17);

If(Byte received&&

End of String (‘\n’,’\r’))Then goto( current case)

Case 17

Set_buffer("AT+CREG?\r");Habilitar_interrupciones();Set_next_state(13);

If(Byte received&&

End of String (‘\n’,’\r’))Then goto( current case)

Case 18

Habilitar_interrupciones();Set_next_state(20);

If(Byte received&&

End of String (‘\n’,’\r’))Then goto( current case)

En este estado, se envía el comando AT de registro del PIN de la tarjeta SIM

Debido a que el módulo GSM/GPS tiene el ECO activo, nos devolverá lo mismo que nosotros hemos escrito en el CASE 10, con lo cual recibiremos un string acabado en ‘\r’ y entraremos en el CASE 13. En este, se establece como estado actual el CASE17 al que se entrará al recibir la respuesta del modulo GSM/GPS a la petición de registro del PIN

Dado que se conoce el PIN de la tarjeta utiilizada, este será el correcto y el módulo devolverá un string “OK\r”. La Máquina de Estados entrará en el CASE 17. Se rellenará el buffer de salida con el comando “AT+CREG?\r" que sirve para que el módulo inicie la negociación con la red, necesaria para lograr una conexión que permita la comunicación con otros terminales GSM

De nuevo el módulo devuelve el ECO, del comando introducido y la máquina de estados entra en el CASE 18. Como se ve, en la mayoría de los estados se habilitan las interrupciones a fin de que al recibir la respuesta del módulo se entre en el CASE correspondiente al estado especificado, en este caso se especifica el 20, luego este será el próximo al que entre la máquina al recibir la respuesta del módulo GSM.

Case 20

If(equal(SCI1_buf_in,"+CREG: 0,1",10,0)|| equal(SCI1_buf_in,"+CREG: 0,5",10,0)){ action1()}Else{ action2()}Habilitar_interrupciones();

If(Byte received&&

End of String (‘\n’,’\r’))Then goto( current case)

El módulo devuelve la respuesta y se entra en el CASE 20.Se evalúa la respuesta:

En caso de haber que la conexión se haya producido con éxito se ejecuta action1() donde se rellenará el buffer con un nuevo comando y se establecerá el nuevo estado actual.

En caso de intento de conexión fallido, se ejecutará action 2(), en este caso llevará a la Máquina de Estados a un estado ‘dummy’ donde esta permanecerá hasta que se haga un reset del V2VCU.

La solución adecuada, que no se llegó a implementar era realizar un reintento de conexión transcurrido un tiempo determinado.

Case 50

/*Estado de inactividad. Se abandonará si llega alguna petición GSM/GPS*/

If(Byte received&&

End of String (‘\n’,’\r’))Then goto( current case) Tras pasar por los estados de inicialización del módulo GSM se llega al estado se

inactividad (CASE 50) donde no se manda nada al mismo, aquí se enciende un led de status que indica que el registro ha sido correcto.

En la rutina de recepción de paquetes ethernet, en caso de recibir una petición de envio de SMS o recepción de datos GPS, se enviará un nuevo comando AT al módulo para que realice la acción necesaria y se seteara el próximo estado al que se debe entrar. Al recibir del GSM/GPS un ‘OK’ o datos GPS reactivará la Máquina de Estados. Que finalmente volverá al estado de inactividad.

IMAGEN 51: Esquema de la máquina de estados para el dialogo con el módulo GSM/GPS

88

Igualmente se muestra el diagrama de estados que representa la ejecución del código del microcontrolador. A la izquierda la linea principal del programa y a la derecha el arbol de estados que representa el código de la RSI del puerto SCI. Esta describe el comportamiento de la RSI del SCI0 y la del SCI1 pues son muy similares en su estructura.

COMPLETE TXEVENT

COMPLETE RXEVENT

SCIRSI

INITIALIZESCI’s

CHECKOUT BUFFER

EMPTY

INITIALIZEI/O’s

INITIALIZEETHERNET

PARAMETERS

START

FULLFIL SCI OUTBUFFER

&ENABLE COMPLETE TX INTERRUPTION

CHECK:END OFSTRING?

PUT A NEW BYTE IN OUT

BUFFER

DISABLECOMPLETE TXINTERRUPT &

CLEAR INT.FLAG

OUT BUFFER EMPTY

MAIN PROGRAM EXECUTIONFLOW DIAGRAM

ENDOFINT.

CLEAR TX INT.FLAG

PUTRECIVEDBYTE ON

IN BUFFER

IF SENDINGNEW

COMMANDIS NEEDED

CLEAR RX INT.FLAG

ITERATESTATE FLOW

MACHINE

INITIALIZESPI’s

*INT INTERRUPTION

FULL FILLOUT

BUFFER

SET NEW

STATE

NO

ENABLECOMPLETE

TXINT.

SCI INTERRUPT SERVICE ROUTINE (SIMILAR FOR SCI0 AND SCI1)

MAINLOOP

ETHERNETMANAGE-

MENT

YES

INITIALIZESOCKETS

IMAGEN 52: Diagrama de estados representando el código del microcontrolador. Hilo de ejecución principal y RSI de

puertos serie

89

5.3. Diseño de la interface SPI El módulo VFIR se comunica con el micro vía puerto SPI, el puerto SPI es un puerto

síncrono con configuración maestro-multiesclavo. El puerto SPI cuenta además de con un canal de transmisión y otro de recepción, uno que contiene la señal de clock, que indica cuando se debe proceder a la lectura/envío de los datos, además por permitir el uso de varios esclavos cada uno de ellos tiene además de los 3 pines correspondientes a los canales mencionados uno de Slave select, que en caso de hallarse a bajo nivel indica que ese es el esclavo seleccionado para la transmisión.

Desde el punto de vista del software debido a que el micro cuenta con un pin dedicado a

Slave Select, no se debe controlar su seteo sino que este queda activado dependiendo del valor configurado en el registro de control del SPI.

Debido a que como se comenta a lo largo del proyecto no se contó con el tiempo suficiente

como para realizar al completo el desarrollo completo del prototipo V2VCU, la implementación de algunas partes del software quedó pendiente para una futura versión, este es el caso de la transmisión SPI de alto nivel, es decir la implementación del protocolo de comunicación entre el microcontrolador y el controlador SPI.

No obstante, si se implementaron las rutinas de bajo nivel para configuración del puerto SPI y la rutinas de servicio a la interrupción del puerto SPI, que guardan los datos recibidos en un buffer y realizan la parte de reseteo de los registros de interrupción a fin de permitir una nueva transmisión o recepción, la implementación se probó con un módulo que se estaba usando en otro proyecto que realiza las funciones de conversor de datos sobre poweline a SPI, esto es envía por SPI los datos recibidos a través de su propia línea de alimentación.

El puerto se configuró para una frecuencia de transmisión de 125Kbs, esta se configura a

través del registro SPIBR del micro, el resto de parámetros del puerto SPI se configuran en los registros SPICR1 y SPICR2, como se ve en la siguiente rutina de inicialización:

INICIO DE INFORMACIÓN CONFIDENCIAL

En este espacio en la versión integra del proyecto se muestra el código perteneciente a la inicialización del puerto SPI del micro

90

FIN DE INFORMACIÓN CONFIDENCIAL

La RSI del SPI, es similar a la del puerto SCI, obviando todo el protocolo de alto nivel del que se ha hablado (máquina de estados, comandos enviados etc.). La RSI se limita a recepcionar un string que el módulo SPI y a setear una variable que indica que el buffer esta lleno, de manera que desde otra parte del programa se puede conocer el estado del buffer.

En el proyecto para probar la correcta implementación de la ruitna se leyeron las tramas que el módulo SPI que se ha mencionado envía como respuesta a un comando enviado tras llenar el buffer de salida en el programa principal. Dicho comando acaba en el carácter de escape ‘\n’ por lo que al llegar al ultimo byte en envío, se deshabilita la interrupción por transmisión de byte completa.

Por su parte el módulo envía una respuesta al microcontrolador que acaba igualmente en el

carácter de escape ‘\n’ deshabilitándose al recibir dicho carácter el flan de interrupción por recepción de byte.

A continuación se muestra la RSI del puerto SPI.

INICIO DE INFORMACIÓN CONFIDENCIAL

En este espacio en la versión integra del proyecto se muestra el código perteneciente a la rutina de servicio a la interrupción del puerto SPI implementada en el micro FIN DE INFORMACIÓN CONFIDENCIAL A continuación se muestra un diagrama de estados que representa el código anterior:

91

IMAGEN 53: Diagrama de estados representando el código de la RSI del puerto SPI del micro

5.4. Diseño de la interface Ethernet (TCP/IP, UDP) En el proyecto V2VCU, el puerto ethernet del MC9S12NE64 es la interfaz de

comunicación de control exterior de la placa. Es decir a través del puerto ethernet se recibirán los comandos de solicitud de comunicación inalámbrica o de solicitud de información GPS y a también se enviarán los paquetes de datos GPS en caso de haber sido solicitados. Asi mismo se enviará a través de este puerto la información recibida a través de los diferentes transceptores inalámbricos al módulo conectado al V2VCU (por ejemplo un PC ejecutando la aplicación de demostración).

El diseño del módulo encargado de la comunicación vía ethernet fue una de las partes mas

complejas de la fase de desarrollo de software. Ya que pese a utilizar una librería de comunicaciones que integra los drivers de bajo nivel que acceden a los periféricos del micro encargados de llevar a cabo la comunicación a nivel hardware (EPHY y EMAC) existen muchos parámetros de configuración para la librería, una vez se integró la librería debido a que se habían seteado dichos parámetros erróneamente se tuvieron que invertir muchas horas hasta la primera transmisión exitosa, por tanto es recomendable trabajar a partir de uno de los

92

ejemplos que acompañan la librería e ir modificando los parámetros de configuración de la misma paulatinamente comprobando a cada paso como evoluciona el comportamiento de la comunicación.

OPENTCP

OpenTCP es una robusta y completa librería desarrollada por Viola systems bajo una licencia de código libre (open source), ofrecida por Feescale para su integración en software diseñado para sus miconcontroladores con controlador ethernet.

La librería, es totalmente modular y permite escoger solo las partes interesantes para el proyecto. Abarca desde la capa de transporte, tanto sobre UDP como TCP incluyendo el driver de acceso al controlador del micro hasta algunos de los protocolos de nivel de aplicación mas usados, tales como ARP, IPv4, ICMP, UDP, TCP, HTTP, BOOTP, TFTP, POP3 y SMTP.

No obstante, debido a las limitaciones en memoria y capacidades del micro, OpenTCP

tiene ciertas reducciones respecto a los estándares RFC de TCP/IP. Es necesario que sea así para reducir la carga de código en memoria FLASH, ROM y RAM, que produce instalar OpenTCP sobre el micro. Aún así, OpenTCP mantiene una alta funcionalidad TCP/IP y plena interoperabilidad con la pila de protocolos [10]. Para hacerse una idea, las desventajas que muestra OpenTCP respecto al estándar TCP/IP son:

• No soporta tipos de paquetes IEEE 802.3 • No soporta opciones IP • No soporta manejo para paquetes fragmentados • El servicio ICMP sólo incluye respuestas de echo • Ignora todas las opciones TCP • Cada paquete TCP debe ser confirmado con un ACK antes que otro pueda ser

recibido La librería ofrece una gran fácilidad de uso gracias a su interface de sockets, que permiten

una integración rápida de la librería sin que el software deba trabajar con especificaciones de red de bajo nivel. Para el acceso a un puerto el programa principal, una vez inicializada la librería debe abrir un socket mediante la llamada adecuada especificando un puerto, así como proporcionar un buffer de entrada donde se irán almacenando los datos recibidos por dicho puerto.

Para el proyecto se dispuso de mucha información relativa a la librería, y de algunos

ejemplos disponibles a través de Freescale, que fácilitaron la su integración y la configuración de la misma para adaptarla a los requerimientos del programa desarrollado. En concreto se utilizaron las funcionalidades comentadas con respecto a los sockets, y como protocolo de transporte el UDP, ya que su uso permitía una menor carga de CPU y cumplía las necesidades

93

del proyecto debido a que la conexión ethernet entre el micro y el cliente sería cableada y de no mucha distancia, con lo cual el riesgo de ruidos en la línea y consecuentemente de paquetes corruptos era relativamente bajo.

La interfaz de red está implementada por el controlador Ethernet de la MC9S12NE64 y sus

drivers. En la siguiente imagen vemos cómo se sobre la pila de protocolos TCP/IP la arquitectura sobre la placa MC9S12NE64.

IMAGEN 54: Diagrama de bloque de la pila TCP/IP para la placa MC9S12NE64

Como se ve en la figura anterior, la placa no incluye por si misma una implementación de

las capas de transporte y aplicación. Estas capas son las capas que implementa la OpenTCP como se ha explicado previamente.

DISEÑO DE LA COMUNICACIÓN MAESTRO-V2CU

Como se ha dicho, la transmisión de las tramas de comandos de solicitud que envía al

V2VCU el módulo externo, referido a partir de ahora como maestro y de información a mandar por parte del V2VCU a dicho módulo, se realiza sobre protocolo UDP. El protocolo UDP envía paquetes de datos sin control de errores, de perdida de trama, ni de orden de las mismas, por ello, no suele usarse en ambientes agresivos como los que afectan a las aplicaciones automotive. No obstante por la baja potencia de calculo requerida por este

94

protocolo y por el poco tráfico que se estimó para comunicar los dos módulos (maestro y V2VCU) el protocolo UDP cumplía con los requisitos mínimos de fiabilidad y sencillez de uso.

IMAGEN 55: Esquema de representación de los sistemas de transmisión usados entre V2VCU/módulo maestro y medio exterior

INICIO DE INFORMACIÓN CONFIDENCIAL

En este espacio en la versión integra del proyecto se muestra el formato de las tramas

enviadas por el módulo maestro al V2VCU para que este realice las acciones de comunicación o obtencio de datos GPS adecuadas.

FIN DE INFORMACIÓN CONFIDENCIAL

95

IMPLEMENTACIÓN

La implementación de las funciones de envio y recepción sobre ethernet, estan representadas de manera simplificada en el siguiente diagrama.

En cuanto a funcionamiento mismas constituyen la parte complementara del dialogo que se describirá a continuación en el capítulo sobre el desarrollo de la Aplicación de demostración en JAVA.

PROCESSUDP

ETHERNET MANAGING CODE

MAINLOOP

IF LINKED

YES,TCP/IP PACKET

PacketReceived?

PROCESSARP

YES, ARP PACKET

NO

PROCESSIP_ICMPNOT USED

IP

PORT 2000LISTENER

PORT 2100LISTENER

PORT 2300LISTENER

SEND LAST STORED GPS

DATA TO PORT 2300 OF THE

MASTER

CORRECTGPS REQUEST

CORRECTECALL REQUEST

EXTRACTPHONE

NUMBER AND MSG

STARTCOMMUNICATION

WITH GSMMODULE

PROCESSTCP IP NOT USED

SEND FIRST MSG BYTE

BY SPI

CORRECTVFIR SENDING

REQUEST

SEND CONFIRMATIO

N TO PORT 2500 OF THE

MASTER*INT INTERRUPTION

SEND SIMULATED MESAGE TO

PORT 2400 OF THE MASTER

IMAGEN 56: Diagrama de estados representando el código de manejo de los paquetes ethernet en el

microcontrolador.

96

6. Desarrollo de las Aplicaciones

6.1 Introducción 6.2 Aplicaciones

6.2.1 Aplicación “llamada de emergencia” 6.2.2 Aplicación “posicionamiento y sensado del entorno”

6.2.3 Aplicación “diagnóstico por infrarrojos”

6.1. Introducción El desarrollo de un módulo electrónico aplicable a la automoción no se concibe en la

actualidad como un ente aislado, ya que en la immensa mayoría de casos el módulo va a formar parte de una arquitectura electrónica compleja en la que varios módulos electrónicos interactuarán intercambiando información y desarrollando subtareas que dependen de la naturaleza del módulo.

Por esto como parte de la introduccion a las aplicaciones de demostracion/simulación del

entorno real, de describen algunos aspectos sobre la arquitectura electrónica en que se hayaría integrado el módulo en un vehículo actual y la elegida para el proyecto realizado

Sin profundizar en exceso en el tema de las arquitecturas electrónicas en automoción

actuales, hay que señalar una de las mayores evoluciones que ha tenido lugar en lo referente a esta parte del diseño del vehículo. Esta es la multiplexación de señales. La multiplexación consiste en el uso de unos soportes fisicos determinados (cableado) para la trasnsmision de datos por parte de distintos módulos de la arquitectura. La multiplexación en la automoción surge a partir de varias causas, que como resultado comportaban un incremento del precio de los vehículos, lo que redunda en una baja competitividad del producto final.

Cuando los módulos electrónicos fueron alcanzando mas presencia en los vehículos, el cableado empezó a crecer en peso y tamaño. Usando señales hardwired, es decir que usan en exclusiva un cable para trasmitir un valor concreto, debía exisitir un cable entre cada pareja de módulos que debian comunicarse entre si, con lo cual al incluir nuevos módulos el cableado crecía de manera exponencial.

Un cableado extenso redunda en un mayor peso del vehículo y por tanto en el consumo de

combustible, una arquitectura compleja de diagnosticar en caso de problemas, y a la vez mas cara ya que el cobre del que estan echos muchos cableados es un material cada vez mas cotizado, lo cual lo hace mas caro de mantener y de fabricar el vehículo.

La solución es usar un cableado común en el que varios módulos puedan verter datos y

recojer los introducidos por otros módulos en caso de que sean necesarios para su funcionamiento. Esta topologia de BUS se encuentra instalada en mayor o menor medida en la práctica totalidad de los coches fabricados hoy en día en europa, USA, gran parte de Asia...

97

En un bus, los distintos módulos envian datos de tipos muy diversos siempre codificados de forma digital, el acceso al medio depende del tipo de bus.

Hay una gran variadas de buses, algunos propiedad de los fabricantes de automóviles que

los suelen usar en exclusiva y otros desarrollados por empresas independientes. Algunos buses son VAN, CAN, Flexray, LIN...

Vista la idea de las posibilidades de comunicación existentes en el vehículo, en caso de

desarrollar comercilamente este módulo lo mas probable es que se conectara a alguno de estos buses a fin de obtener informaciones de distinta naturaleza, tales como comandos del usuario, de la centralita de SRS (seguiridad pasiva) etc.

En el caso del prototipo, el proyecto se planteo describiendo al V2VCU como parte de un

proyecto mayor que consistía principalmente en el desarrollo de un módulo electrónico para aplicaciones multimedia mucho mas complejo, el CCM (módulo de consola central). Este módulo podría solicitar acciones del V2VCU mediante una comunicación directa y dedicada entre lo dos. Siendo el CCM el módulo que en caso de producción en masa se integraría con la arquitectura del vehículo a traves de buses de comunicación compartidos.

IMAGEN 57: Ilustración del prototipo del módulo CCM fabricado en el CTE

Dada la limitación de puertos libres de la CCM se definió como interface entre este

módulo y el V2VCU una conexion ethernet, pese a que en un principio ethernet no se consideraba un bus adecuado para su inclusión en los sistemas automotive, hay algunas implementaciones sobre ethernet en vehículos comercializados actualmente. Por ejemplo, algunos BMWs tienen una interface ethernet para su conexión al Tester del taller, y un módulo electrónico que funciona como puerta de enlace que convierte los paquetes TCP/IP a los distintos buses del coche.

El uso de ethernet como canal de comunicaciones para el módulo V2VCU resultaba muy

interesante ya que aporta la posibilidad de crear aplicaciones sobre PC que simulen peticiones de otros módulos, en este caso el mencionado CCM. A la vez, permite funcionalidades tan

98

interesantes como que el módulo esté conectado a internet a través de un router, o a una LAN incrementando asi su posibilidad de conectividad y aportando la posibilidad de efectuar por ejemplo aplicaciones de diagnosis o control remoto.

6.2. Aplicaciones

El PC será la interface entre el usuario y el V2VCU. El PC servirá para simular tanto peticiones de acciones como la ECALL como comandos del módulo CCM tales como trasnmision de datos vía WIFI o infrarojos o la obtencion de datos GPS.

Una vez abstraidos de las capas inferiores de la pila de comunicaciones relativa al módulo y a la interacción con el PC, se definen las aplicaciones para testeo y demostracion del módulo V2VCU:

6.2.1. Aplicación “llamada de emergencia” La llamada de emergencia o ECALL (emergency call) es una de las aplicaciones mas

extendidas en la telemática que actualmente se incluye en ciertos vehículos. En la mayoría de casos solo se incluye esta aplicación en vehículos de alta gama o vehículos pesados. Esto se debe a a que el coste de la tecnología telemática con capacidad para realizar ECALLs en proporción a su funcionalidad y a la frecuencia con que se usa en la vida del vehículo es alto.

Se prevé que en un futuro cercano a no más de 20 años cada vehículo será un nodo de una

red global en constante movimiento como analógicamente ocurre con los PCs dentro de Internet. Algunas de las ultimas investigaciones en materia de seguridad para la automoción prevén que la implementación de nuevas mecanismos de evitación de accidentes en los vehículos que se desarrollarán en los próximos años pasará por sacar partido de las tecnologías de las comunicaciones para incrementar así la seguridad del vehículo. El objetivo en especial será el de evitar los accidentes ya que cada vez es mas difícil incrementar la seguridad mediante la mejora de las partes mecánicas del vehículo tal y como se ha venido haciendo hasta ahora.

Por otra parte, lo mas importante para los fabricantes de automóviles es el rendimiento

económico, por una parte el abaratamiento continuo del hardware hará que sea mas barato producir vehículos equipados con esta tecnología y por otra, debido al incremento de la clase media y su poder adquisitivo, se prevé que estas tecnologías irán ganando paulatinamente mas

99

adeptos. A la larga esto debe redundar en el hecho de que la ECALL se generalice como equipamiento básico de los vehículos de turismo.

El principio de funcionamiento de la ECALL consiste en, ya sea mediante interacción de

usuario a través del accionamiento de un pulsador o directamente de la electrónica del vehículo en caso de que esta detecte una situación de peligro (incendio, colisión, aire toxico…), el módulo telemático envíe uno o varios mensajes de ayuda a uno o varios destinatarios.

El objetivo principal de la tecnología ECALL es dar a conocer que el usuario ha sufrido

algún tipo de percance, a fin de que los servicios de emergencia puedan acudir en su ayuda, por tanto una aplicación ECALL típica debe realizar al menos una llamada o envío de mensaje a un canal fijo establecido para tal fin, adicionalmente es interesante el poder programar números adicionales para avisar a familiares o conocidos del usuario.

En una ECALL se debe reportar la máxima información relativa al estado actual del

vehículo y de sus usuarios de la que se disponga, en este sentido el dato más importante a transmitir la posición del vehículo en coordenadas GPS a fin de que sea posible su localización.

En el proyecto dentro de la aplicación desarrollada para realizar la demostración del

hardware diseñado, se ha implementado un panel para la funcionalidad de ECALLing, en el se muestran varios campos donde introducir teléfonos, todos los campos son editables en tiempo de ejecución del programa, pero el único que sale rellenado es el primero que sería el teléfono correspondiente al teléfono fijo de las autoridades, mientras los demás campos quedan vacíos para que el usuario introduzca los teléfonos adicionales. Para realizar distintas pruebas cada teléfono dispone de una casilla de habilitación, por tanto con cada ECALL se puede enviar el mensaje a uno o mas teléfonos.

El programa una vez pulsado el botón “ECALL” realizara el envío del mensaje secuencial

mente a cada uno de los teléfonos introducidos. El programa envía a los teléfonos mencionados la posición GPS, seguida de un string que

contiene un mensaje que describe el estado de los airbag del vehículo simulando la información que el módulo, en caso de encontrarse integrado en la arquitectura del vehículo, habría recibido del módulo SRS (supplemental restraint system) del vehículo. En el programa dicho string se puede modificar libremente a fin por ejemplo de ver el resultado visual del mensaje en la pantalla del teléfono móvil.

100

IMAGEN 58: Captura de la pantalla mostrando el panel de la funcionalidad ECALL

6.2.2. Aplicación “posicionamiento y sensado del entorno” Esta aplicación es la mas innovadora ya que no se usa actualmente en ningún vehículo

comercial, se basa en recrear a partir de los datos de posicionamiento del vehículo obtenidos del hardware GPS del V2VCU del mismo y de la información GPS obtenida del resto de vehículos cercanos el entorno en el que se haya el vehículo.

La transmisión de la información GPS la realizan todos los vehículos vía WIFI, ofreciendo

al resto de vehículos información sobre su posición de manera cíclica. Obviamente todos los vehículos deben seguir los mismos protocolos en las distintas capas de la pila de comunicaciones. Es decir protocolo 802.11b en el protocolo físico, ethernet, tcp/ip y finalmente aplicación.

Esta aplicación puede llegar a alcanzar una gran complicación si se intenta implementar de

una manera aplicable a la realidad, con nodos (vehículos ) entrando y saliendo de la red continuamente, intentado enviar información a la vez y debiendo calcular detalladamente la carga que soporta la red para cada posible situación de la misma.

En el proyecto la aplicación no llegó a completarse por falta de tiempo, pero se definieron

sus especificaciones que se exponen brevemente a continuación. En cuanto a saturación de vehículos se simplificó la aplicación de manera que en el

entorno solo hubiera 5 vehículos adicionales al vehículo principal el PC en el cual se está

101

ejecutando la aplicación. De esta manera se puede asignar una IP a cada uno de los vehículos sin necesidad de mandar mensajes de descubrimiento en la red para cada vehículo que llega a la red ni timeouts para liberar las IPs de los nodos que ya no participan en la misma.

El envío cíclico de mensajes de posición lo realiza automáticamente el SW interno del

módulo V2VCU a la dirección IP del PC, de esta manera desde el panel del PC se puede ver la información que debería de llegar al resto de vehículos del entorno. En la práctica debido a que se disponía de un numero muy limitado de módulos V2VCU operativos se planteo la posibilidad de usar uno o dos V2VCU reales y simular el resto de vehículos de la vía en la aplicación JAVA.

Por otra parte en el módulo V2VCU el software configura el módulo WIFI en un modo

bridge en el cual una vez realizados una serie de pasos cada byte que llega por un puerto TCP/IP configurado se transmite al puerto serie del módulo WIFI, a su vez este está conectado al microcontrolador. Este envía por ethernet, al PC dicha información una vez tratada. Al recibirla en el PC por un concreto esta se procesa nuevamente, extrayendo el identificador del vehículo.

Como tarea abierta relativa a esta aplicación quedó también parte de la representación

gráfica del entorno. De acuerdo a las decisiones de diseño tomadas debería mostrar el vehículo como en la imagen expuesta a continuación en una vista semejante a la mostrada en la pantalla de un radar, donde se puede apreciar centrado el vehículo implementado sobre el PC y los vehículos del entorno simulados.

IMAGEN 59: Captura simulada de la aplicación de sensado del entorno

102

6.2.3. Aplicación “diagnóstico por infrarrojos” Una de las aplicaciones del módulo V2VCU, era la trasnmision de datos a alta velocidad

vía rayos infrarojos, una tecnologia que ofrece grandes posibilidades que hacen muy interesante su utilización en medios automotive a la vez que presenta algunas limitaciones inherentes a este tipo de ondas electromagneticas.

Las posibles aplicaciones de un trasceptor emisor receptor de infrarojos de altas

prestaciones como el montado en la V2VCU son casi inacabables, destacando entre ellas aquellas que aprovechan mejor las ventajas de los infrarojos y se adaptan a sus requisitos de uso.

Por ejemplo es muy interesante su uso en lugares donde exista la necesidad de conectividad rapida, sin cables, y focalizada, lo cual ofrece un grado extra de seguridad en las trasnmisiones, la tecnologia infraroja al igual que las ondas de luz visible depende en cuanto a la apertura de su foco de accion de la lente del emisor, pudiendose usar lentes que concentren la señal y que aprovechen al maximo la potencia del emisor o bien de que abran el haz a fin de poder transmitir en situaciones donde sea dificil la alineacion del ente emisor y el receptor, como seria el caso de vehículos en movimiento al pasar bajo una baliza emisora de datos IR.

Otra caracteristica destacable de los rayos IR es su inmunidad al ruido eléctrico, lo que los

hace preferibles en zonas donde se produzcan este tipo de ondas, especialmente en entornos con instalaciones eléctricas de potencia, máquinaria, inversores... etc.

Como se ha dicho tambien existen una serie de limitaciones que se tuvieron en cuenta al

decidir las aplicaciones mas adecuadas para esta tecnologia y como análisis de las que podria tener en el mundo real en caso de que llegase a fabricarse un módulo de estas caracteristicas en serie para su uso en vehículos.

Las ondas IR tienen caracteristicas físicas muy semejantes a las de las ondas de la luz visible, al igual que esta, los rayos IR no tienen la capacidad de atravesar objetos opacos o de grosor considerable, asi mismo pueden desviarse o distorsionarse al atravesar cuerpos transparentes que aunque son permeables a este tipo de ondas pueden segun la geometría de su superficie variar su trayectoria.

Frente a otras soluciones tales como las ondas de radio presentan la desventaja de no ser omnidireccionales, como suele ocurrir con el resto de ondas electromagneticas cercanas del espectro de las electromagneticas, el echo de tener tan alta frecuencia (300Ghz-120Thz) las hace lineales, esto es causa a su vez de su bajo poder de penetración, dado que la frecuencia de la ona se relaciona directamente con su longitud de onda (1mm-2,5 um), que hace que estas sean interceptadas por las moléculas que componen los objetos y gran parte de su energía sea absorvida o reflejada.

La aplicación diseñada, simula un dialogo de diagnósticos muy simple entre un tester y el

propio vehículo, en el escenario real un tester u ordenador de taller equipado con un trasnceptor y software compatibles con las capacidades IR del V2VCU enviaria un comando de diagnosticos al cual el vehículo contestaria por ejemplo con una respuesta positiva en caso de estar en disposición de realizarse dichas tareas o negativa en caso contrario, a partir de ahi

103

se podria iniciar una secuencia de identificación o bien directamente empezar con el intercambio de datos pertinente dependiendo del protocolo de alto nivel que se definiese para garantizar la correcta transmisión de la información por vía IR, y el protocolo de diagnosis que en este caso obedeceria probablemente a un protocolo de automoción como los definidos los standares KWP2000 (ISO 14230) o “Diagnostics on CAN” (ISO 15765).

En la práctica, tanto el tester como el vehículo se encuentran emulados por un PC

conectado a un módulo V2VCU, siendo el PC la unidad de procesado que respresenta a una ECU del vehículo y al tester en el caso del segundo equipo.

IMAGEN 60: Setup para demostración de las capacidades VFIR del V2VCU

La implementación de la aplicación no se completó debido a no disponer de los módulos

V2VCU totalmente operativos como se ha dicho en puntos anteriores. Por tanto solo se probo de manera unitaria la aplicación, simulando el emisor mediante la escritura directa por parte del usuario de los comandos del emisor en la ventana de envio del PC sobre el cual se ejecutaba la aplicación y observando una respuesta de confirmación por parte del V2VCU.

104

En la pestaña VFIR de la aplicación, podemos ver dos cuadros de texto, se dispone de dos modos de operación.

El primero de ellos, no implementado es el modo de transmisión RAW, en este caso el modo diagnosis está desactivado y todo lo que se reciba vía IR a través del módulo V2VCU se mostrará en dicho cuadro de texto y lo que se escriba en la ventana de emisión se enviará por IR al receptor.

En caso de estar activado el modo diagnósitco la aplicación envia un determinado mensaje al V2VCU y este devuelve una respuesta automatica en caso de recibir un pasword correcto del PC sobre el cual se ejecuta el programa. En este caso la palabra clave es “DIAGNOSTICS” que es el string que se ha definido como inicio de una petición de diagnosticos por IR.

En caso de que en lugar de dicho string se reciba cualquier otro la aplicación del V2VCU no realiza ninguna accción, esto se definió como el comportamiento más seguro y energéticamente mas económico para un módulo de comunicaciones accesible desde el exterior del vehículo.

105

A continuación se muestra un diagrama de estados simplificado de la aplicación de demostración JAVA:

IMAGEN 61: Diagrama de estados de la aplicación de demostración para V2VCU

106

7. Tests

7.1 Introducción 7.2 System test 7.2 Unit test 7.3 Integration test 7.4 Architecture test

7.1. Introducción La fase final del proyecto consiste el testeo y validación de las funcionalidades

implementadas en el módulo fabricado. En un modelo comercial se dedican muchos recursos a la validación del producto ya que se debe garantizar su correcto funcionamiento en cualquier circunstancia para lo cual se necesitan gran cantidad de recursos y horas de testeo, en cambio en un prototipo como el fabricado, la fase de testeo es mucho menos critica y se le asignan muchos menos recursos. Esto supone en valor relativo un porcentaje menor del tiempo dedicado al proyecto. A continuación se describe a modo de introducción el proceso de testeo de un módulo electrónico complejo siguiendo el esquema del desarrollo en V anteriormente comentado, centrando sobretodo en la parte software del mismo por haber sido la que en el caso del V2VCU ha tenido mayor peso. Esta se ha ido realizando durante todo el proyecto frente al testeo de hardware que se ha limitado a la puesta en marcha de la placa sin llegar a someterla a casos de test exigentes.

Dentro del desarrollo en V que se sigue habitualmente en Lear como ejemplo de empresa

de peso dentro de la fabricación de módulos electrónicos automotive puede verse que al igual que hay distintas fases de desarrollo en la parte descendiente de la V.

Desde la concepción del sistema dentro de la arquitectura, la definición a alto nivel del software y hardware o la implementación a bajo nivel, a cada uno de estos pasos le corresponde su testeo correspondiente, equivalente en cuanto a nivel de profundidad dentro de la arquitectura en la que se encuentra incluido el módulo, en este caso en la parte ascendiente de la V.

De esta manera a las fases de definición de arquitectura le corresponde un testeo y validación del módulo como caja negra, como parte de la misma aquitectura, mientras que a los niveles de desarrollo inferiores les corresponden tests de mas bajo nivel tales como los integration tests (IT) y los unit tests (UT).

En el caso concreto del V2VCU, la fase de testeo de arquitectura este se realizaría

activando las funcionalidades de la caja tal cual lo haría el usuario final del demostrador, esto es desde la aplicación java de demostración descrita en puntos anteriores que se ejecuta en un PC.

En este caso por ser un demostrador independiente se ha definido la totalidad de la arquitectura dentro del proyecto, es decir como funciona la aplicación del demostrador y como funciona el V2VCU en si mismo, en el supuesto de que al final del proyecto, se hubiese cumplido el propósito inicial de conectar el módulo al CCM, este test debería abarcar también

107

a este módulo, y se actuaría sobre la CCM a fin de ver si la solicitud de los servicios que la CCM haría al V2VCU se resuelven correctamente y no sobre el módulo en si mismo.

El testeo de arquitectura en el caso de un producto comercial, lo lleva a cabo el fabricante de automóviles cliente, en un escenario en el que se dispone además del módulo fabricado por esta empresa de los demás módulos que funcionarán en el vehículo, es decir con la arquitectura completa o parcialmente completa según el test, que queda fuera del alcance del proveedor en la mayoría de casos, ya que no se dispone de la totalidad de los módulos. Este es el test situado en el extremo ascendente de la V y satisfechos los test de nivel inferior garantiza el funcionamiento correcto del módulo en el vehículo.

7.2. System test El test de sistema trata como un bloque tipo caja negra al módulo, actuando sobre sus

entradas y evaluando sus salidas, sin integrarlo en la arquitectura global. Es decir se simulan los valores que serán visibles a la entrada del módulo, tales como mensajes de datos transmitidos a través de los buses de comunicación o señales hardwired, para provocar de manera controlada todas las situaciones que resulten interesantes desde el punto de vista del testeo. Se pueden ampliar los casos de test que se consideran viables una vez instalado el módulo dentro de la arquitectura, tales como casos de fallo de otros módulos, inanición de mensajes, valores inválidos para las señales hardware y otros casos que ante un funcionamiento correcto de todos los módulos del vehículo no podrían reproducirse en el testeo de nivel de arquitectura.

De la misma manera en esta fase se realizan pruebas de testeo de las salidas, a fin de comprobar la robustez ante cortocircuitos a masa, a batería, cargas abiertas etc.

7.3. Integration test En cuanto los tests de nivel inferior, los integration tests evalúan el correcto

funcionamiento de los distintos submódulos que componen el módulo electrónico. Esto es aplicable tanto al software como el de hardware, en oposición a los tests de sistema

estos prescinden de las interferencias que pueda ocasionar el submódulo a testear en los demás submódulos. Un submódulo en un módulo electrónico, a nivel de software puede corresponder por ejemplo a una serie de funcionalidades agrupadas según su definición a alto nivel, tal como un submódulo de protección de salidas digitales, un submódulo de control de mensajes CAN, un submódulo de ahorro de energía etc.

Normalmente tanto los test de integración como los de unidad son llevados a cabo por el

propio equipo de desarrolladores del submódulo por el conocimiento que exige de la funcionalidad del mismo. El integration test se ejecuta en un ámbito de profundidad en el cual se ignora el funcionamiento interno del submódulo, es decir se prueba toda la funcionalidad de este dentro del módulo electrónico realizando peticiones externas al módulo electrónico a través de sus entradas, relativas a funcionalidades cuya ejecución es llevada a cabo total o

108

principalmente por el submódulo bajo testeo, analizándose las respuestas del submódulo a través del comportamiento global del módulo electrónico.

7.4. Unit test En el unit test, se comprueba el correcto funcionamiento a un nivel de implementación

mas bajo, esto es dentro del submódulo, a nivel de software, para ello, durante la fase de desarrollo se evalúa el correcto comportamiento de las funciones que componen el código forzando mediante el software y hardware emulador o debbuger los parámetros de las funciones y comparando los resultados obtenidos al finalizar las mismas con los esperados.

En el caso de submódulos que a su vez contengan software proporcionado por terceros,

como es el caso de la librería TCP/IP usada en el módulo V2VCU, el unit test se limita a comprobar que el paso de parámetros a las funciones del software integrado por parte del software propio se realiza correctamente, ya que no se dispone de conocimiento sobra los detalles internos del software, de manera que en caso de existir un fallo, en el software integrado este se debe detectar en el integration test, que es el test inmediatamente superior al unit test, y en caso de determinar que el error proviene del software integrado solicitarse un test del mismo al proveedor de este a fin de determinar la fuente exacta del error y subsanarlo

El seguimiento de la V garantiza la calidad en el diseño de módulos complejos ya que el

software se diseña de mas alto nivel a menor, sin perder nunca la visión global de lo que el módulo debe hacer y a su vez se testea el código implementado de menor a mayor nivel.

En el caso de un proyecto pequeño como es el V2VCU, todo el testeo al igual que ocurre con el desarrollo se realiza sin que exista una separación tan clara entre los niveles de implementación, los unit e integration test se van realizando conjuntamente a medida que se programa dándose los resultados del integration test como validos para garantizar el funcionamiento correcto de los submódulos.

En la V2VCU estos submódulos corresponden a cada uno de los servicios de los que dispone el módulo a nivel de hardware, es decir, comunicación IR, comunicación con el módulo WIFI, y con el módulo GPS/GSM y recepción ethernet ya que estos funcionan de manera mas o menos independiente, debido a que usan distintos recursos del microcontrolador y a que obedecen a las distintas solicitudes que el V2VCU puede recibir, como se ha comentado en el punto Descripción del software/ Diagrama de bloques.

Por otra parte una parte del testeo del sistema V2VCU se realiza de manera unitaria junto

con el de la arquitectura en el caso del demostrador ya que la aplicación de demostración nos permite a la vez mandar los comandos a nivel de sistema al V2VCU, lo que garantiza en caso de funcionamiento correcto que tanto el V2VCU como el programa funcionan como se espera en conjunto y por tanto también como sistemas independientes. Al testear de esta manera mas generalista que si se siguiese estrictamente el diseño en V se pierde eficacia en el testeo a cambio de dedicar menos recursos, lo cual es importante en el caso de un proyecto con un tiempo de ejecución corto como el V2VCU.

109

Para el testeo tanto de la aplicación del demostrador a nivel de sistema como del V2VCU, además, se realizan tests independientes que evalúan el correcto protocolo de comunicaciones que estos deben seguir para la transmisión de las solicitudes enviadas por parte de la aplicación del demostrador y los datos retornados por el módulo electrónico. Dicho protocolo abarca los mensajes de solicitud de las distintas acciones ejecutables por el V2VCU así como el formato de las respuestas del mismo, para mostrar la información recibida a través de los distintos canales a los que puede acceder el módulo, ver capítulo de Diseño de software/ Diseño de la interface Ethernet (TCP/IP, UDP)/ Formato.

Sea cual sea el nivel de test, como se ha dicho la exigencia de estos es inferior a la exigible

en un producto comercial, aun así se debe garantizar su correcto funcionamiento en una serie de casos concretos mínimos que son los que se reproducirán mas frecuentemente durante el uso del demostrador, para ello se deben realizar unos protocolos de test que permitan evaluar si el módulo tiene el comportamiento esperado ante las peticiones del usuario.

Estos tests deben incidir especialmente en aquellos aspectos que mas susceptibles sean de fallar según el diseñador del software y el hardware y de la misma manera deben ofrecer especial cobertura en aquellos aspectos que hayan sido modificados en el software para subsanar un error detectado anteriormente durante el testeo siguiendo el siguiente diagrama de flujo.

IMAGEN 62: Diagrama de flujo del proceso de testeo de la aplicación

(detección y corrección de errores)

Testeo de funcionalidad resultado

¿Satisfactorio?

Siguiente Caso Test Si

No

Evaluación del fallo

Fallo real Si Correción del

fallo

No

Corrección/ Ampliación del caso de test

Evaluación: ¿Error complejo/ Critico?

No

Si

Estado inicial

110

Como se ha dicho a lo largo de los puntos anteriores no se llegó a poner en marcha el

módulo final, por lo que los tests se realizaron sobre la placa de evaluación y son solo aplicables al software, en caso de contar con el módulo final los tests de software serian totalmente validos, debiendo probarse en profundidad el hardware, y limitando el testeo adicional de software a los niveles de arquitectura y sistema, descendiendo en la V solo en caso de hallar errores cuya causa no pudiera ser determinada en estos niveles.

De manera esquemática los integration test que se llevaron a cabo para evaluar el correcto

funcionamiento de las distintas partes del módulo V2VCU y de la arquitectura de la que constaba el demostrador fueron los siguientes.

INTEGRATION TEST

PROBAR LA COMUNICACIÓN CON EL WIFI INICIALIZACIÓN FUNCIONAMIENTO

PROBAR LA COMUNICACIÓN CON GSM/GPS INICIALIZACIÓN FUNCIONAMIENTO

PROBAR LA COMUNICACIÓN CON ETHERNET INICIALIZACIÓN FUNCIONAMIENTO

Los resultados de acuerdo con la parte del software implementada fueron satisfactorios,

permitiendo el uso del demostrador para su fin, no obstante en el caso del WIFI por las limitaciones del software implementado a fecha del final del proyecto los tests no son significativos y deberían en posteriores fases de desarrollo ampliarse una vez implementada el resto de funcionalidad.

7.5. Architecture test

Los tests de arquitectura, se hicieron mediante la ejecución repetida de los distintos comandos que ofrece la aplicación de demostración para las distintas funcionalidades del V2VCU, de esta forma se aseguró que la ejecución de las demostraciones usando el V2VCU estaría cubierta por los tests ya que estas iban a ser versiones reducidas de los mismos.

De esta manera la ejecución satisfactoria de cada una de las partes de la aplicación de demostración, tales como la obtención periódica de datos GPS, el envío de la ECALL y el resto de aplicaciones comentadas, implica el correcto funcionamiento de toda la arquitectura

111

8. Conclusiones

8.1 Evaluación de objetivos cumplidos /pendientes 8.2.Conclusiones técnicas 8.3.Próximos pasos 8.4.Conclusiones sobre las comunicaciones C2C/C2I 8.5.Opinión personal y valoración del proyecto

8.1. Evaluación de objetivos cumplidos /pendientes Como se ha dicho, el proyecto V2VCU, no se pudo completar en el transcurso de las 600h

de proyecto asignadas al mismo por diversas razones, a continuación se exponen cuales de los objetivos fijados se cumplieron y cuales no, mostrando los timings definidos originalmente y el timing real al final del proyecto así como una estimación del tiempo total requerido para la ejecución total del proyecto incluyendo los objetivos que no se lograron debido a la duración del mismo.

Por otra parte se analizan las causas de los retrasos, lessons learned derivados de haberlos sufrido que derivan en posibles medidas para evitarlos en futuros proyectos.

Planning inicial El planning inicial propuesto al inicio del proyecto presenta la siguiente asignación de

horas: 1-Análisis del proyecto (40h) 2-Development GPS / GSM / 5,8GHz / IR interface board development (250h) 3- Application development (190h) 4- Documentation (120h)

Objetivos logrados y porcentaje

Horas estimadas

Horas invertidas Porcentaje del objetivo logrado

Análisis del proyecto

40 50 100

Development GPS/IR/GPS

250 250 75% (-80h)

Application develompent

190 250 80 (-50h)

Documentation 120 50 55(-60h)

112

Se estimo que el proyecto hubiera necesitado unas 300 horas adicionales de trabajo para su correcta finalización.

8.2. Conclusiones técnicas El proyecto realizado sobre el diseño de una unidad de comunicaciones C2C para su uso

como demostrador de aplicaciones telemáticas vehiculares ha cumplido con la mayoría de los objetivos marcados en su inicio.

A continuación se detallan los objetivos alcanzados. - Se ha realizado el diseño hardware del módulo V2VCU para Lear Corporation,

obteniendo como resultado los esquemas electrónicos necesarios para su fabricación por un tercero y su posterior puesta en marcha

- Se ha realizado la detección y corrección de algunos fallos de diseño hardware,

comentados a lo largo de la memoria consiguiendo que el microcontrolador del módulo ejecute el programa diseñado.

- Se ha diseñado un software operativo, para la CPU del V2VCU, que permite su uso

limitado como módulo de comunicaciones multimedia, incluyendo GSM y WIFI. Así como funcionalidad para dotar al módulo maestro conectado a la V2VCU de capacidad de localización GPS.

- Se ha implementado una aplicación de demostración de la V2VCU que permite tanto su

testeo durante el desarrollo del software instalado en la misma como la demostración de sus capacidades y que servirá además como base para el diseño de futuras aplicaciones mas complejas y a la vez más intuitivas que permitan un mejor aprovechamiento de las posibilidades del módulo electrónico diseñado.

- Se han testado las distintas sub aplicaciones sobre las placas de evaluación de los

distintos módulos con resultados satisfactorios de acuerdo a las especificaciones definidas. -Se ha documentado de manera detallada el proyecto a fin de que se pueda seguir su

desarrollo en Lear Corporation, enfocando la evolución del V2VCU hacia la fabricación de otro módulo hardware que solucione los errores de diseño de la versión 1.00 diseñada y fabricada a lo largo de este proyecto y el incremento de funcionalidad del software desarrollado a fin de dar cobertura a la totalidad del hardware instalado en la V2VCU y su potencia.

113

8.3. Próximos pasos El presente proyecto deja ciertos frentes abiertos para la consecución de los objetivos

iniciales del proyecto de tener un prototipo de comunicaciones funcional que pueden dar lugar a algunos próximos proyectos en torno al módulo fabricado no obstante resulta mas interesante hablar de los próximos pasos relacionados con el proyecto a largo plazo, por lo que algunos de los próximos pasos comentados suponen un nivel de dedicación de recursos económicos y técnicos que van más allá de los asignados al proyecto presentado:

Terminar el desarrollo del software para la actual V2VCU incluyendo el control total del

las funcionalidades GSM, GPS, WIFI y VFIR Fabricación de un nuevo prototipo actualizado de la V2VCU con nuevos componentes

más funcionales y compactos, que solucione los errores de diseño hardware descritos anteriormente. Una posibilidad en este caso seria dotar al módulo de transceptores de comunicación más usados en las redes de comunicación intravehiculares, tales como CAN o Flex Ray. Para la implementación de un nuevo prototipo debería recurrirse a una CPU más rápido y con mayor memoria RAM y de FLASH como los descritos en el punto de diseño de hardware.

Respecto a integración: Implementar y testear la correcta comunicación del V2VCU con el

CCM de nueva generación que se está diseñando actualmente en el Centro Tecnológico Europeo de Lear.

Incorporación de la V2VCU a proyectos mayores multiECU, donde se pueda demostrar de

manera consistente las posibilidades que ofrece el V2VCU a nivel de arquitectura real, tal y como lo haría en un vehículo y en el cual varios módulos electrónicos realicen peticiones de comunicación al V2VCU utilizando los distintos de medios de transmisión de los que este ultimo dispone.

Respecto a diseño software: Revisión de las funcionalidades de la V2VCU, aplicaciones

soportadas y protocolos utilizados, haciendo hincapié en el uso de protocolo de transporte TCP/IP para la comunicación V2VCU y el módulo maestro a fin de incrementar la seguridad en las transmisiones. Estudiar igualmente el uso de protocolos de aplicación como FTP o TFTP o incluso el HTTPS cifrados para la transmisión WIFI en aplicaciones criticas como el envío en modo repetidor de mensajes de ECALL.

La posibilidad de llevar a cabo estas mejoras depende directamente de la potencia de calculo del módulo V2VCU, puesto que el cifrado consume gran cantidad de tiempo de CPU.

Evolución de las aplicaciones actuales del demostrador, orientándolas a una simulación

mas realista usando dos PCs con dos V2VCU simulando dos vehículos o nodos de vehículo e infraestructura. Un ejemplo de esta evolución consiste en realizar una aplicación basada en el Virtual Radar, basada en tecnología GPRS, pudiendo usarse esta tecnología junto a la transmisión WIFI a fin de duplicar la información usada por esta aplicación, critica en cuanto a seguridad, que ha sido inicialmente implementada para el uso del WIFI solamente.

114

Como posible próximo paso, en este caso ambicioso y en un futuro algo mas lejano, donde se cuente con un transceiver de comunicación DSRC (C2C WIFI), implementar una V2VCU como parte de un prototipo de ECU comercial de la empresa, a fin de demostrar a los fabricantes de automóviles las capacidades de la misma para desarrollar y fabricar módulos avanzados con tecnología C2C integrada para los vehículos de próxima generación.

8.4. Conclusiones sobre las comunicaciones C2C/C2I En lo que respecta la arquitectura de la V2VCU, el hecho de tener un microcontrolador de

potencia tan limitada para un dispositivo de aplicaciones tan bastas ha supuesto un trabajo extra de optimización de la programación para las aplicaciones GPS-GSM así como las WIFI y que todo el tratamiento de las comunicaciones entre el micro y los componentes de comunicaciones se realiza dentro de rutinas de servicio a la interrupción y su ejecución debe ser lo mas rápida posible. Por lo comentad,o se toma como lección aprendida que este tipo de módulos requiere de una potencia de cálculo mayor, lo que se traduce en un microcontrolador mas avanzado y potente como los valoradas al inicio del proyecto y descartados por lo motivos expuestos, de manera que en una futura versión mas funcional y con mas posibilidades de representar un modelo de módulo comercial, se deberá de reanalizar en profundidad este aspecto.

Por ultimo valorando lo aprendido en relación a las tecnologías C2C y C2I, se puede

afirmar sin riesgo a equivocarse que dichas tecnologías proporcionarán un gran incremento en la funcionalidad y especialmente en seguridad a los coches del futuro. El diseño y fabricación de este tipo de dispositivos puede llegar a ser muy rentable en el futuro dado que utilizan tecnologías muy especiales y no cualquier compañía cuenta con el know-how necesario como para ser validadas como proveedor de los fabricantes de vehículos por lo que aquellas que inviertan en investigación en la actualidad serán más susceptibles de ganar mercado en el futuro.

El precio por unidad de módulo V2VCU es relativamente asequible y no debería resultar

un problema para su próxima implantación en vehículos de alta gama, no obstante la necesidad de la generalización de esta tecnología a lo largo de toda el parque de vehículos para lograr su finalidad hará que su implantación venga supeditada a las acciones legislativas de las administraciones. En la actualidad estas son las máximas impulsoras del desarrollo de protocolos WIFI adaptados a los nodos en movimiento y de sus proyectos relacionados, lo cual indica que en los próximos años se empezarán a ver implementaciones de este tipo en vehículos de calle.

Dado que la posibilidad de que la empresa acabe fabricando en un futuro módulos

similares es la razón impulsora del proyecto en si, la visión empresarial ha estado presente en todo momento durante el proyecto, requiriendo un estudio del estado del arte, patentes, competencia y del futuro mercado de las aplicaciones telemáticas así como los aspectos inherentes a los costes de fabricación, precio por componente, complejidad de la placa pcb,

115

montaje de componentes etc. Los conocimientos adquiridos en relación a este aspecto hacen prever que se seguirá investigando de manera continua sobre este tipo de tecnologías, y que en caso de que la empresa se interese por el desarrollo de módulos comerciales, partirá con algunos conocimientos valiosos sobre esta tecnología.

8.5. Opinión personal y valoración del proyecto Globalmente, sobre el proyecto se puede decir que ha sido muy interesante, no solo a nivel

técnico sino a nivel de formación general, pues ha supuesto un reto en muchos sentidos y el aprendizaje de algunos aspectos tanto técnicos como relativos al trabajo en la industria. Estos últimos solo pueden ser adquiridos mediante la experiencia día a día en este entorno de trabajo.

Por otra parte la valoración personal del trabajo realizado también es buena, puesto que se

ha conseguido diseñar y programar un módulo relativamente funcional, objetivo considerable para una primera fase de desarrollo de un producto y para un perfil de ingeniero con prácticamente ninguna experiencia en el diseño de circuitos y sus tareas relacionadas. Precisamente esta ha sido una de las partes que se valora como mas interesante.

Este ha sido un proyecto que desde un principio se concibió como abierto a la continuación por parte de otros proyectistas en el futuro debido a la envergadura del mismo, mientras que al inicio de este se partió de cero ello ha obligado a realizar muchas tareas diferentes que abarcan desde el diseño esquemático, a la programación en JAVA y C, pasando por el estudio de protocolos wireless de telecomunicaciones y de módulos electrónicos específicos. Esta variedad ha hecho que su realización resulte muy amena.

A un nivel menos técnico, se han realizado toda una serie de tareas de recopilación de

información sobre distintos componentes Hardware, métodos de programación de las distintas rutinas del micro etc. También se ha participado en varias reunciones con distribuidores de distintas marcas de componentes de interés para el proyecto, conversaciones con las empresas fabricantes etc.

Por lo tanto se puede afirmar que el realizar un proyecto de final de carrera en Lear

Corporation enmarcado bajo la relación URV-LEAR es una gran oportunidad para aquellos estudiantes que deseen adquirir una cierta experiencia en el mercado laboral, en una empresa puntera del desarrollo de módulos electrónicos automotive.

116

Referencias bibliográficas

[1] Freescale www.freescale.com

[2] Telit www.telit.com

[3] Silex www.silexamerica.com

[4] SIgmatel www.sigmatel.com

[5] Cooperative Vehicle-Infrastructure System.

www.cvisproject.com

[6] IEEE communication Society.

www.comsoc.org

[7] ISO CALM www.calm.hu

[8] Car to Car Consortium. www.car-to-car.org

[9] SCADPLus (Actividades de la UE)

http://europa.eu/scadplus/leg/es/lvb/l31103a.htm

[10] Esafetysupport www.esafetysupport.org/

[11] Wirelesscar www.wirelesscar.com

[12]SourceForge.net:Freescale openTCP

sourceforge.net/projects/freescaleotcp

[13] embeddedrelated http://www.embeddedrelated.com

[14] Sigmobile www.sigmobile.org

[15] University of Meryland (computer science deptment)

www.cs.umd.edu

[16] Armstrong consulting http://www.leearmstrong.com/Dsrc/DSRCHomeset.htm

[17] Gstproject http://www.gstproject.org

[18] Esafetysupport http://www.esafetysupport.org

117

Agradecimientos

Ya que el presente proyecto de final de carrera supone la culminación de mis estudios de

ingenieria en automática me gustaría agradecer su apoyo a las personas que han estado a mi lado en los dos últimos años de realización y documentación del proyecto sino cuanto menos en los cuatro que hace que empecé la carrera.

Las más importantes y a las cuales les dedico el proyecto son mis padres, soporte incondicional en todas las facetas de mi vida incluida la académica y en segundo lugar mis pocos pero buenos amigos, a ellos gracias por animarme a acabar el proyecto cuando no abundaban los animos.

Dentro del entorno del proyecto, mi agradecimiento al Dr Antoni Ferré Fabregas, tutor del

proyecto en la empresa que me ha ido guiando a lo largo del proyecto iluminandome cuando las ideas para avanzando estban algo difusas, compaginando la tutoría con su trabajo habitual, que nunca es poco y que me ha ofrecido algunos consejos más allá del proyecto que me han servido posteriormente en el terreno profesional.

118

ANEXOS

Anexo 1

Descripción: Propuesta de proyecto de Lear Nombre de archivo: ANEXO 1 V2V_V2I_Communication_Unit.doc

Anexo 2

Descripción: Protocolo de comunicaciones inicial V2VCU-CCM Nombre de archivo: ANEXO 2 PROCOCOLO DE COMUNICACIÓN CCM.doc

Anexo 3

Descripción: Información sobre uso básico del módulo Silex SX-550 Nombre de archivo: ANEXO 3 FAQ Silex 550.doc

Anexo 4 Información confidencial

Descripción: Esquema del V2VCU Nombre de archivo: ANEXO 4 V2VCU schematic (ARCHIVO CONFIDENCIAL).pdf

Anexo 5 Información confidencial

Descripción: BOM de los componentes disponibles en planta de Lear Valls Nombre de archivo: ANEXO 5 02_12 Main Learparts BOM.doc

Anexo 6 Información confidencial

Descripción: Código fuente del software del microcontrolador Nombre de archivo: ANEXO 6 CÓDIGO FUENTE MICROCONTROLADOR.doc

Anexo 7 Información confidencial

Descripción: Código fuente del programa de demostración Nombre de archivo: ANEXO 6 CÓDIGO FUENTE MICROCONTROLADOR.doc

3ª Lear Innovation Award

This document is property of Lear. It cannot be reproduced, delivered or disclosed to third parties without prior consent from Lear

“Vehicle-to-Vehicle (V2V) / Vehicle-to-Infrastructure (V2I) Communication Electronic Unit” Author: Rubén Sánchez Fajardo The aim of the project is the design, implementation and test of an electronic control unit with RF interfaces supporting future Vehicle-to-vehicle (V2V) / Vehicle-to-Infrastructure (V2I) Communications, namely V2VCU. This includes:

- GSM supporting functions like E-call (automatic emergency call) - DSRC supporting directly Vehicle-to-vehicle and Vehicle-to-Infrastructure functionality. Possible

demonstration applications are SafeSpeed / Dynamic Traffic Information / Remote Monitoring. Since DSRC standard is not yet available, 802.11a (5.8GHz) transceivers will be used. - GPS receiver needed in both GSM and DSRC standards for appropriate positioning. - IR (infra-red communication for traffic control)

In order to communicate with the CCM module, the V2VCU will include a microcontroller with Ethernet interface. In order to reduce the implementation effort, microcontroller used will be the same used in CCM and will incorporate the same low-level software layers. A simple application will be also programmed / adapted from available EASIS demonstrators in a PC for demonstrative purposes. The final result will be part of the LEAR’s OMEEGA test bench, which is being developed at the European Technological Center, Valls.

Block diagram of the system

Phases 1- Project analysis (40h)

• Project description • Searching of documentation • Project task planning

Deliverable: Time plan of the project with the respective detailed tasks 2- GPS / GSM / 5,8GHz / IR interface board development (250h)

• Components selection (including antennas) • Schematics design • PCB design (outsourced) • Test

Deliverable: V2VCU electronic board

IRTransceiver

3ª Lear Innovation Award

This document is property of Lear. It cannot be reproduced, delivered or disclosed to third parties without prior consent from Lear

3- Application development (190h)

• V2VCU board o Development of GSM / DSRC / GPS control software using low-level software developed

for CCM • PC board

o Development of remote application Deliverable: software & hardware integration at functional level

4- Documentation (120h)

• Complete specification of the product developed. • Documentation of all validations done with respective results. • Lessons learned about the technologies applied with orientations for future uses. • Summary presentation.

Deliverable: a) Referred documents; b) Internal presentation; c) Presentation of the project at the University

PROCOCOLO DE COMUNICACIÓN ENTRE PROGRAMAS DEL CCM RELATIVA A LA FUNCIONALIDAD DE “RADAR DE ENTORNO” Introducción Dentro del CCM corren concurrentemente varios programas con funcionalidades independientes y no independientes, en ciertos casos estos programas deben disponer de mecanismos de comunicación que permitan el intercambio de datos para su correcto funcionamiento. Este documento detalla el protocolo de aplicación usado entre el programa driver del módulo telemático y el programa de interface grafica del CCM. Previo La interface física entre el modulo telematico y el modulo de consola (CCM) es ethernet. El protocolo de mensajes entre el modulo y la CCM esta definido provisionalmente en otro documento independiente y no afecta directamente al programa de interface grafica. Los programas driver del módulo telemático y el de interface grafica, se ejecutan en el CCM en el unico procesador de este, por tanto solo se debe resolver un procolo a nivel interno, en este caso a nivel aplicación, que se ejecutara sobre la interface socket, a fin de facilitar la independencia entre los dos programas, usando como base de transporte TCP/IP. Puesto que el programa interface va a ejecutarse siempre en el CCM mientras que el modulo telematico es una aplicación periferica del mismo, al inicializar el CCM, el programa de interface gráfica abre el socket y ejecuta los pasos necesarios para quedar a la espera de conexiones. El programa driver, se ejecuta mas tarde e intenta conectarse al de interface grafica. Una vez establecido el enlace el programa driver inicia el envio de datos al programa interface grafica a fin de que este pueda disponer de ellos y mostrar en la pantalla del CCM la información de manera adecuada. Funcionalidad a implementar El programa driver corriendo sobre el CCM recibe via ethernet datos correspondientes a información GPS de los vehículos simulados de su entorno, enviados al CCM por el modulo telematico que los recibe a través de enlaces externos con dichos vehiculos, estos datos son tales como latitud, longitud, velocidad, angulo etc. Aprovechando las capacidades multimedia del CCM, se pretende mostrar en pantalla una subventana donde aparezcan el vehículo que monta el CCM y los vehículos que cercanos de su entorno, a fin de dar al usuario una vision rapida de su situación en el entorno de manera rapida y visual, tal como ocurre con los radares algunos aviones. Por tanto, el programa driver, tras recibir los datos GPS de un vehículo del entorno y procesarlos, los pasa al programa interface que los mostrara en la pantalla del CCM.

Como se ha dicho tras recibir los datos del modulo telematico y previamente a pasarlos al modulo de interface grafica, el programa driver realizara el tratamiento oportuno de los datos a fin de no añadir al programa interface nuevas tareas no relativas a la presentación de gráficos y garantizar la maxima independencia entre funciones de cada aplicación. Respecto al aspecto en la pantalla del CCM como se ha dicho, la información se muestra en una subventana, cuyo tamaño es independiente del procolo de datos que se describe, siendo funcion del programa de interface grafica el “dibujado” de la ventana a partir de los datos proporcionados por el programa driver. En una posición centrada en el eje de X de la subventana, en posición longitudinal con respecto al eje de las Y se pintara el coche que representa al sistema. Alrededor de este se representaran los otros coches… (a determinar con Alberto Pelarda para ver como hacemos lo de las distancias, si el coche esta centrado en el eje de las Y o adelantado etc) Interface entre programa driver y programa de interface grafica Como se ha comentado el mecanismo de comunicación entre ambos procesos es la API de sockets UDP. El puerto en que se abrira el socket será el 2500 Dado que ambos procesos se ejecutan sobre la misma maquina la comunicación se hace a través de loopback, usando la IP 127.0.0.1 o el identificativo localhost si se dispone de dicha funcionalidad en el SO. Establecimiento de la comunicación Al recibir del modulo telemático un nuevo dato GPS, el programa driver lo procesa, a continuación abre la conexión TCP/IP a traves del socket, una vez establecida envia los datos procesados en forma de string al programa de interface grafica, tras esto cierra la conexión. Este proceso se repetira cada vez que el programa driver reciba un nuevo dato GPS. Temporización de los datos La llegada de datos al programa driver será no periodica dependiendo de la carga de vehículos en el entorno del sistema, el paso de información al programa de interface grafica sera por tanto no periodica. Definición de los datos a alto nivel Dado el requisito de no mostrar los datos de manera que no se sature de información al usuario, se tendran en cuenta solo cinco variables de la información GPS que ofrece el modulo telematico, estas son latitud, longitud, altura, angulo y velocidad. La altura nos permitirá discriminar a los vehículos que esten situados a otra altura por ejemplo en pasos a distinto nivel.

La longitud y la latitud, comparadas con las del sistema permitiran saber a que distancia del vehículo que simboliza el sistema hay que pintar los distintos vehículos del entorno. Igualmente el angulo se simboliza en la pantalla pintando a los vehículos con distinta inclinación siempre relativa a la del vehículo que simboliza el sistema, cuya representación permanecera inalterable sea cual sea su angulo real. Definición del protocolo (a revisar con A. Pelarda) El programa driver, pasa al programa de interface grafica las coordenadas de los vehículos del entorno como una coordenada entre (0,0) y (200,200) quedando el vehículo que representa al sistema en la coordenada (100,100); La altura se pasara como un valor entre -10 y 10. El angulo se pasara como un valor entre 0 y 360 con respecto al eje Y de la subventana o al vehículo que representa al sistema. La velocidad se pasara como un valor entre 0 y 500 y sera el valor real en km/h de los vehículos a fin de disponer de ese dato exacto el programa de interface grafica. Formato del string de datos El string que se transmitira empieza con el identificador CCMRADAR El separador que se usara entre el identificador y los datos entre los datos mismos es guión bajo (‘_’) Ejemplo de string de datos pasado: CCMRADAR_X20,120_Y50,50_H0_A3_S126

Consideraciones para la correcta comunicación con el modulo Silex 550 (WIFI board) A realizar manualmente a continuación de la inicialización o el primer encendido en el puerto2 de la evaluation board Habilitar filtro AT en puerto serie:

Set port s1 filter AT A continuación reinicializar

Configurar velocidad del puerto serie: Set port s1 speed 9600 (u otra de las disponibles)

A realizar manualmente a continuación de la inicialización o el primer encendido en el puerto1 de la evaluation board Dehabilitar eco en el puerto serie

ate

A realizar dentro del programa del microcontrolador Configurar IP y/o mascara de red del modulo

Set IP ad 192.150.150.150 Set IP su 255.255.0.0

Configurar IP destino del modo Ecable Set port s1 ecaddr 192.150.150.152

Configurar puerto destino del modo Ecable Set port s1 ecport 192.150.150.152

Habilitar modo Ecable (solo necesario si se va a transmitir inminentemente) Set port s1 ecable en

Errores frecuentes y soluciones síntoma Causa Solución La placa no responde: Falta de alimentación Conectar alimentación Bloqueada en estado conectado Reinicializar (boton

EB/inicializacion en consola) Puerto erroneo Verificar la conexión al puerto

serie adecuado Filtros AT no activados Activar filtro AT Cable de red desconectado Conectar cable de red a la placa

y al otro nodo Errores de protocolo Eco de los datos recibidos en el Deshabilitar eco

micro-wifiboard puerto de la placa