universidad politécnica de madrid escuela técnica superior...

Universidad Politécnica de Madrid

Escuela Técnica Superior de Ingenieríade Sistemas Informáticos

Máster Universitario en Software de SistemasDistribuidos y Empotrados

Proyecto Fin de MásterSISTEMA DE CONTROL EMBEBIDO EN UN AUTOMÓVIL

Autor: Andrés Manuel Gamboa Meléndez

Director: Javier García Martín

Madrid, 2 de mayo de 2018

SISTEMA DE CONTROL EMBEBIDO EN UN AUTOMÓVIL

Autor: Andrés Manuel Gamboa MeléndezDirector: Javier García Martín

Escuela Técnica Superior de Ingeniería de Sistemas InformáticosUniversidad Politécnica de Madrid

2 de mayo de 2018

Resumen

Hoy en día los vehículos son utilizados en todo el mundo. Estos contienen una grancantidad de sistemas mecánicos y electrónicos complejos que funcionan juntos para unmismo propósito.

Los sistemas integrados en vehículos deben ser seguros y fiables, ya que por sunaturaleza pueden poner en riesgo vidas humanas. Por ello es necesario un control preciso yseguro de cada uno de los subsistemas integrados en el vehículo tanto de forma individual,como del conjunto.

En este proyecto se ha desarrollado un sistema de comunicaciones para este tipode sistemas, utilizando el protocolo CAN BUS. También se han implementado variossubsistemas que se comunican a través del sistema de comunicaciones para cubrir partede la funcionalidad de un vehículo. Las funcionalidades implementadas son las siguientes:gestión de la iluminación, sistema de limpiaparabrisas, control del motor y la dirección,obtención de datos de navegación y un interfaz para la comunicación con sistemas externos.

Palabras clave: Arduino, Tiempo real, Alta integridad

Abstract

Today, vehicles are used all around the world. These contains a great variety ofcomplex mechanical and electronic systems working together for a unique purpose.

The systems embedded in a vehicle must be safe and secure, because people livesdepend on them. For this reason, these systems must be control in a safe and secure way,individually and as a whole.

In this project it has been designed and developed a communication system for thistype of systems using CAN BUS protocol. This communication system is used by multiplesubsystems to implement part of the functionality of a vehicle. The functionalitiesimplemented are: motor power and direction control, light and wiper control, navigationdata collection and external communication interface.

Key words: Arduino, Real time, High integrity

Índice general

1 Introducción 11.1 Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Importancia del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Objetivo del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Métodos y herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5.1 Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5.2 Recursos y herramientas . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Documento de especificación de requisitos 92.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Ámbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Organización del documento . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Descripción general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Perspectiva del producto . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3 Requisitos pospuestos . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Requisitos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Arquitectura del sistema 133.1 Red de nodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Tipos de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Planificador de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Diseño de nodos funcionales 194.1 Nodo de navegación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1.1 Recursos Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.2 Recursos Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.3 Diseño hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.4 Diseño software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Nodo de confort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.1 Recursos Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.2 Recursos Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.3 Diseño hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Sistema de control embebido en un automóvil iii

ÍNDICE GENERAL

4.2.4 Diseño software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Nodo moto-propulsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42


5 Diseño de interfaz y sistema externo 535.1 Nodo interfaz inalámbrico . . . . . . . . . . . . . . . . . . . . . . . . . . . 53


5.2 Aplicación software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2.2 Recursos Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6 Resultados y Conclusiones 676.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2.1 Valoración del hardware utilizado . . . . . . . . . . . . . . . . . . . 696.2.2 Valoración de las comunicaciones . . . . . . . . . . . . . . . . . . . 706.2.3 Valoración de la programación . . . . . . . . . . . . . . . . . . . . . 706.2.4 Valoración de la metodología . . . . . . . . . . . . . . . . . . . . . . 71

6.3 Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Bibliografía 73

iv Master Thesis

Índice de figuras

3.1 Red de nodos del sistema.[9] . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Diagrama del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Ejecutivo cíclico.[10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Micro-controlador Arduino Nano . . . . . . . . . . . . . . . . . . . . . . . 204.2 Ultimate GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3 Placa GY-91 con sensores de fuerza. . . . . . . . . . . . . . . . . . . . . . 214.4 Controlador CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.5 Nodo de navegación: Diseño hardware (Fritzing) . . . . . . . . . . . . . . 234.6 Nodo de navegación: Diagrama de clases . . . . . . . . . . . . . . . . . . . 254.7 Servomotor SG-90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.8 Sensor YL-83 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.9 Led blanco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.10 Led rojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.11 Fotorresistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.12 Nodo de confort: Diseño hardware (Fritzing) . . . . . . . . . . . . . . . . . 334.13 Nodo de confort: Diagrama de clases . . . . . . . . . . . . . . . . . . . . . 364.14 Motor brushless y ESC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.15 Servomotor SG-90 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.16 Controlador CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.17 Nodo moto-propulsor: Diseño hardware (Fritzing) . . . . . . . . . . . . . . 444.18 Batería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.19 Nodo moto-propulsor: Diagrama de clases . . . . . . . . . . . . . . . . . . 47

5.1 Micro-controlador Wemos D1 Mini (ESP8266) . . . . . . . . . . . . . . . . 545.2 Nodo Interfaz Wi-Fi: Diseño hardware (Fritzing) . . . . . . . . . . . . . . 555.3 Nodo interfaz Wi-Fi: Diagrama de clases . . . . . . . . . . . . . . . . . . . 565.4 Aplicación: Diagrama de clases . . . . . . . . . . . . . . . . . . . . . . . . 645.5 Aplicación: Pestaña de motor . . . . . . . . . . . . . . . . . . . . . . . . . 655.6 Aplicación: Pestaña de navegación . . . . . . . . . . . . . . . . . . . . . . 665.7 Aplicación: Pestaña de confort . . . . . . . . . . . . . . . . . . . . . . . . 66

6.1 Sistema desarrollado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Sistema de control embebido en un automóvil v

Índice de tablas

3.1 Identificador de mensaje CAN. . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Nodo de navegación: Periodo de tareas. . . . . . . . . . . . . . . . . . . . . 284.2 Nodo de navegación: Identificadores de mensajes1. . . . . . . . . . . . . . . 304.3 Nodo de confort: Periodo de tareas. . . . . . . . . . . . . . . . . . . . . . . 404.4 Nodo de confort: Identificadores de mensajes2. . . . . . . . . . . . . . . . . 414.5 Nodo moto-propulsor: Periodo de tareas. . . . . . . . . . . . . . . . . . . . 494.6 Nodo moto-propulsor: Identificadores de mensajes3. . . . . . . . . . . . . . 50

5.1 Nodo interfaz inalámbrica: Periodo de tareas. . . . . . . . . . . . . . . . . 585.2 Mensaje UDP: Información de motor y dirección. . . . . . . . . . . . . . . 595.3 Mensaje UDP: Información de ubicación. . . . . . . . . . . . . . . . . . . . 605.4 Mensaje UDP: Información de inercia. . . . . . . . . . . . . . . . . . . . . 605.5 Mensaje UDP: Información de iluminación. . . . . . . . . . . . . . . . . . . 615.6 Mensaje UDP: Información de lluvia y limpiaparabrisas. . . . . . . . . . . 61

6.1 Dedicación de tiempos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2 Coste de materiales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Sistema de control embebido en un automóvil vii

1Introducción

1.1 Definición del problema

Un vehículo se compone tanto de partes mecánicas como de sistemas electrónicos. Laparte electrónica se compone de varios subsistemas, cada uno de los cuales se encarga deuna parte de las funcionalidades.

En este proyecto se afronta el problema de diseñar, desarrollar y valorar el sistemaelectrónico de un automóvil. Estos sistemas suponen un riesgo para las personas y porello deben respetar requisitos técnicos de seguridad y eficiencia.

Además, los sistemas embebidos en vehículos tienen limitaciones físicas, de tamaño yde ubicación dentro del vehículo, que hacen necesario la distribución del sistema en variospuntos del automóvil.

Estos sistemas embebidos y distribuidos, por su naturaleza de sistema crítico, debencumplir requisitos adicionales:

• Seguridad en el software.

• Restricciones de tiempos de ejecución.

• Distribuidos por el vehículo, comunicaciones seguras y con garantías.

Sistema de control embebido en un automóvil 1

CAPÍTULO 1. INTRODUCCIÓN

1.2 Importancia del problema

Cada vez hay una mayor demanda de equipos electrónicos en todo tipo de sistemas, desdeel sector agrícola, como puede ser un sistema para monitorizar viñedos[1]; hasta el sectoraeroespacial, donde los sistemas deben ser tan precisos que un pequeño error o retrasopuede ser catastrófico.

Al igual que aumenta la demanda, aumenta la complejidad de los sistemas y requierenun mayor nivel de seguridad y eficiencia. Por ejemplo, en el sector automovilístico sedemanda un mayor número de sistemas para la comodidad de los viajeros, así comouna mayor eficiencia en la gestión de los combustibles. Para conseguir esto, se han idosustituyendo los sistemas mecánicos por otros electrónicos, ya que estos últimos son másprecisos, más versátiles y más pequeños que sus comparables mecánicos.

Los nuevos sistemas y la demanda de los clientes genera una competitividad en elmercado abrumadora para los fabricantes. A día de hoy, el 30% del coste de producciónde un vehículo se invierte en la electrónica del mismo. Y el 90% de las innovaciones serealizan sobre los sistemas electrónicos de los vehículos [2].

Los sistemas mecánicos son lentos y toscos, se desgastan con el roce de las piezas ypierden fiabilidad. Los sistemas electrónicos son más rápidos, ligeros y pequeños, y ademásno tiene piezas móviles que se desgasten. Por esto son más fiables y seguros que las piezasmecánicas.

En un vehículo comercial pueden localizarse entre 40 y 100 micro-controladores paralas diferentes funcionalidades. Por ejemplo, la gestión del motor es realizada por unsubsistema, mientras que la transmisión es controlada por otro y la interfaz hombre-máquina por un tercero.

Con la gran cantidad de micro-controladores integrados en el vehículo, es necesariauna arquitectura software fiable de cada programa, así como de las comunicaciones entrelos micro-controladores.

Del mismo modo que se sustituyen sistemas mecánicos por sistemas electrónicos, seinvestigan y desarrollan nuevas funcionalidades que no es posible realizar sin la electrónica.Por ejemplo, el sistema Global Positioning System (GPS) de un vehículo, o la conectividadcon el teléfono móvil.

1.3 Contexto

Los vehículos son utilizados en todo el mundo. Sólo en España, en el año 2017, se hanmatriculado casi 1,3 millones de vehículos entre coches, furgonetas, camiones y motos [3].

Los vehículos llevan evolucionando desde antes de la existencia de los sistemaseléctricos, cuando la potencia motriz de los mismos necesitaban caballos para moverse.Con la evolución del vehículo, y la cada vez mayor complejidad del mismo, se han ido

2 Master Thesis


integrando sistemas eléctricos y electrónicos para controlar el vehículo de forma másprecisa.

Los sistemas electrónicos de un vehículo aparecieron para controlar el sistema deencendido, evitando la erosión y el desgaste del sistema mecánico original. Desde esemomento se han ido sustituyendo sistemas que antes eran mecánicos por unos nuevoselectrónicos. La electrónica permitió esto gracias a que estos sistemas ocupan menosespacio que los mecánicos. Otras de las ventajas que la electrónica aporta a estos sistemasson: precisión, rapidez, adaptabilidad, fiabilidad y auto-diagnóstico [4].

Los sistemas de un vehículo se pueden clasificar en 4 categorías, algunos de los cualesson los siguientes:

1. Seguridad

• Anti-bloqueo de ruedas

• Anti-patinaje

• Control dinámico de la trayectoria

• Dirección asistida

• Iluminación de xenón

• Iluminación dinámica

• Indicador de mantenimiento

• Vigilancia de la presión de los neumáticos

• Airbags y pretensores

2. Confort

• Regulación adaptativa de la velocidad

• Climatización automática

• Memorización del puesto de conducción

• Control de acceso sin llave

• Cierre centralizado

• Automatismo de limpieza e iluminación

• Ayuda de aparcamiento

3. Comunicación

• Audio

• Vídeo

• Ordenador de a bordo

• Mandos vocales

• Telefonía móvil



• Navegación

• Pantalla centralizada

• Visualización en el parabrisas

4. Grupo moto-propulsor

• Gestión motor gasolina con regulación de inyección, encendido, riqueza y depolución

• Regulación electrónica diésel con regulación del caudal y del comienzo deinyección

• Gestión motor diésel con rampa común

• Gestión electrónica de la caja de velocidades (automática, manual robotizada,por correa)

• Gestión electrónica de la refrigeración motor

• Gestión electrónica de la sobre-alimentación

• Motorización híbrida

• Regulación de potencia del motor eléctrico

En un mismo vehículo se pueden encontrar la mayoría de los sistemas listados. El únicocaso excluyente se encuentra en el grupo moto-propulsor, en el que los sistemas instaladosdependen del tipo de motor que tenga el vehículo. Todos los sistemas deben ser fiables yseguros ya que de ellos dependen la vida de sus usuario.

1.4 Objetivo del trabajo

El objetivo de este proyecto es el de desarrollar una maqueta o prototipo de unsistema electrónico para un vehículo. Por limitaciones en los recursos disponibles, tantode personal, de tiempo como de presupuesto, se desarrollará un subconjunto de lasfuncionalidades del sistema electrónico de un coche.

Las funcionalidades incluidas en este proyecto serán las siguientes:

• Regulación de la potencia del motor.

• Control de la dirección.

• Sistema de iluminación exterior.

• Sistema de limpiaparabrisas.

• Sistema de navegación.

• Valorar diferentes aspectos del desarrollo:

4 Master Thesis


– Hardware utilizado

– Sistemas de comunicaciones

– Desarrollo software

– Metodología seguida

1.5 Métodos y herramientas

1.5.1 Metodología

Se ha seguido un modelo de desarrollo basado en prototipos. Esto ha permitido irdefiniendo los requisitos del sistema y desarrollar un sistema completo, que aún siendo unprototipo, satisface los requisitos propuestos como fase final de este proyecto.

Al inicio de cada fase se ha establecido una serie de objetivos a diseñar e implementar.Para que al final de cada fase se tuviese una idea más precisa del producto final deseado.

En cada nueva fase de desarrollo y con la idea obtenida de la fase anterior, se planteannuevos requisitos, se modifican los antiguos y se establecen otros nuevos objetivos para lafase actual. De esta forma, después de varias fases se ha obtenido un sistema que cumplelos objetivos iniciales del proyecto.

1.5.2 Recursos y herramientas

Uno de los objetivos en este proyecto es el de implementar un prototipo del sistema, porlo que se han utilizado recursos que ya se poseían, y se ha tenido que invertir la cantidadmínima de dinero posible.

A su vez, tampoco se ha invertido dinero en las herramientas utilizadas para eldesarrollo. Al contrario, se han utilizado herramientas que permiten el uso libre paraproyectos personales y para el ámbito estudiantil.

1.5.2.1 Recursos hardware

A continuación se muestra la lista de dispositivos utilizados para el desarrollo de losprototipos del proyecto. Estos se describirán más adelante, en la fase de desarrollo.

Micro-Controladores

1) Arduino Nano: Es un micro-controlador económico, con recursos limitados y bajoconsumo, para utilizar en proyectos sencillos y de prototipado. En este proyecto seutiliza como elemento principal de los nodos del sistema.



2) WeMos D1 mini: Es un micro-controlador similar al Arduino Nano, queademás ofrece una interfaz Wi-Fi. Este se utiliza para establecer comunicacionesinalámbricas con sistemas externos. Se ha utilizado en el nodo de interfacesinalámbricas.

Sensores

1) Ultimate GPS: Es un módulo GPS utilizado para la obtención de los datos deubicación geográfica. Se utiliza en el nodo de navegación.

2) Sensor inercial (GY-91): Este módulo se utiliza para determinar las fuerzasinerciales que sufre el vehículo. Se utiliza en el nodo de navegación.

3) Sensor de lluvia (YL-83): Este sensor mide la cantidad de agua sobre susuperficie, se utiliza para evaluar la intensidad de la lluvia. Se utiliza en el nodode confort.

4) Fotorresistencia: Este sensor se utiliza para medir la intensidad de la luz ambiente.Se utiliza en el nodo de confort.

Actuadores

1) Servo-motor (SG-90): El servo-motor se utiliza para modificar la dirección delvehículo. Se utiliza en los nodos de confort y moto-propulsión.

2) LED blanco/rojo: Los LED de color blanco y rojo representan las luces exteriores,delanteras y traseras, del vehículo. Se utiliza en el nodo de confort.

3) Motor brushless: El motor brushless es el motor central del vehículo para elmovimiento del mismo. Se utiliza en el nodo de moto-propulsión.

4) Controlador electrónico de velocidad (ESC): Este módulo es necesario paracontrolar la velocidad del vehículo. Se utiliza en el nodo de moto-propulsión.

Comunicaciones

1) Modulo bus CAN (MCP2515): Este módulo gestiona las comunicacionesentre los nodos utilizando el protocolo Controller Area Network (CAN). Este seutiliza en todos los nodos del sistema ya que proporciona un medio para realizarcomunicaciones con restricciones de tiempo real.

1.5.2.2 Herramientas software

A continuación se describen las herramientas software utilizadas para el desarrollo de losprototipos del proyecto.

6 Master Thesis


Diseño hardware

1) Fritzing: Es un programa software para el diseño de sistemas sobre placas deprototipado. En este proyecto se utiliza para diseñar los diagramas de circuitospara los prototipos de cada nodo.

Desarrollo software

1) Arduino IDE: Es un entorno de desarrollo de software libre desarrollado paratrabajar con el hardware de Arduino. Incluye un compilador y las configuracionespara todos los subsistemas Arduino existentes. Además incorpora las libreríassoftware que puedan necesitar los desarrollos en cualquier plataforma de Arduino[5]. Esta herramienta se utiliza para la implementación del software instalado encada nodo.

2) Notepad++: Es un editor de texto con ayudas para la edición de código fuenteen varios lenguajes de programación [6]. Se utiliza como herramienta auxiliar alArduino IDE.

3) Netbeans: Netbeans es un entorno de desarrollo integrado dedicado principalmenteal desarrollo de aplicaciones Java. Este Integrated Development Environment (IDE)tiene funcionalidades propias que facilitan el desarrollo de aplicaciones gráficas. Seutiliza para el desarrollo de la aplicación de ordenador.


2Documento de especificación de requisitos

En este capítulo, como el propio título indica, se especifican los requisitos que debesatisfacer el proyecto que se va a desarrollar en este trabajo.

Al tratarse de un desarrollo basado en prototipos, se han ido tomando decisiones tantode diseño como de funcionalidad durante el transcurso del proyecto. Debido a esto, se hahecho una especificación de requisitos poco detallada.

2.1 Introducción

2.1.1 Ámbito

Este documento contiene la especificación de requisitos software del sistema definido,diseñado e implementado como trabajo final para el “Máster Universitario en Software deSistemas Distribuidos y Empotrados"[7]. Este sistema monitoriza y controla una serie defuncionalidades de un vehículo a través de sensores y actuadores instalados en el mismo.

2.1.2 Organización del documento

En la sección 2.1 se realiza la introducción de este documento y se define el objetivoprincipal del proyecto. También se describe la organización del documento.

Las siguientes secciones definen los requisitos que debe cumplir y las restricciones quedebe respetar el sistema. La sección 2.2 describe la funcionalidad, las restricciones y las


CAPÍTULO 2. DOCUMENTO DE ESPECIFICACIÓN DE REQUISITOS

características. Mientras que la sección 2.3 define los requisitos específicos del sistema.

2.2 Descripción general

2.2.1 Perspectiva del producto

Este sistema tiene como objetivo ser una plataforma hardware y software de bajo nivelpara un vehículo. Con esta plataforma se permitirá desarrollar sistemas de más alto niveldedicados al sector automovilístico para la gestión de la información y el control de lossistemas que componen la electrónica de un vehículo.

2.2.1.1 Interfaces del sistema

En esta sección se definen las interfaces que debe proporcionar el sistema para interactuarcon sistemas externos y/o usuarios.

Interfaces de usuario

Este sistema no tiene interfaz de usuario.

Interfaces hardware

Las interfaces hardware del sistema son aquellas que requieren un medio físico para elintercambio de información entre subsistemas o entre el sistema y el usuario.

El sistema debe proporcionar conectividad Wi-Fi, de modo que un sistema externopueda establecer una conexión inalámbrica y recibir información del estado del mismo.

Interfaces software

Las interfaces software del sistema son los fragmentos software que permiten al sistemainteractuar con otros sistemas. Esto puede ser tanto por el uso de librerías de terceros enel sistema, o por proporcionar métodos para que un sistema externo pueda interactuarcon el sistema desarrollado.

En este proyecto no hay límites para el uso de software de terceros. La única restricciónaplicable es que éstas librerías permitan el uso o edición libre del código.

Se debe desarrollar una interfaz para el intercambio de datos por medio de una redinalámbrica Wi-Fi.

10 Master Thesis


2.2.1.2 Requisitos de despliegue

Para el despliegue del sistema debe considerarse la naturaleza del mismo. Éste debe irinstalado en un vehículo móvil, por lo que debe estar alimentado por una batería.

La conexión inalámbrica entre el sistema y sistemas externos se debe realizar por mediode una red Wi-Fi, esta comunicación no debe perjudicar el rendimiento del sistema.

2.2.1.3 Funciones del producto

El objetivo principal del sistema es el de capturar información relativa al estado delvehículo, analizar los datos obtenidos y proporcionar los medios para el acceso a losmismos desde un sistema de alto nivel.

Adicionalmente, el sistema debe poder recibir ordenes de un sistema externo paracontrolar el sistema electrónico del vehículo. Esto incluye el movimiento del mismo.

2.2.2 Restricciones

El sistema debe obtener información del entorno de forma periódica. Las ordenes recibidasdesde un sistema externo deben ejecutarse de forma inmediata, a menos que esto supongaun peligro para el sistema.

El lenguaje de programación utilizado debe ser Ada o C/C++. En el caso de utilizarC/C++ se deben seguir las recomendaciones definidas por el estándar MISRA C [8].

No existen restricciones de memoria definidas más que las establecidas por el hardwareutilizado.

2.2.3 Requisitos pospuestos

En esta fase del proyecto se desarrollará un subconjunto de las funcionalidades de unvehículo, se pospone para fases futuras el desarrollo del resto de funcionalidades. Comola implementación de un nodo que permita al usuario controlar directamente el vehículo.

También se pospone la integración de reacciones automáticas ante circunstancias quepuedan resultar peligrosas. Así como la integración de un sistema de control autónomopara el vehículo. Queda pendiente realizar un estudio de las ventajas de integrar estossistemas o desarrollar sistemas externos que utilicen las interfaces proporcionadas.



2.3 Requisitos específicos

El sistema desarrollado debe proporcionar a sistemas externos información relativa alestado interno y medios para controlar ciertos elementos.

La información de estado del sistema se divide por categorías y debe incluir lossiguientes datos:

1. Información del sistema de navegación.

• Datos de ubicación GPS.

• Datos de sensores de inercia.

2. Información del sistema de confort.

• Estado del sistema de iluminación.

• Estado del sistema de limpiaparabrisas.

3. Información del sistema moto-propulsor.

• Estado del motor del vehículo.

• Estado de la dirección.

Para el control del sistema, este debe poder recibir comandos para cambiar su estado.Estos comandos pueden afectar a los siguientes elementos del sistema:

1. Estado del sistema de confort.

• Estado del sistema de iluminación.

• Estado del sistema de limpiaparabrisas.

2. Estado del sistema moto-propulsor.

• Estado del motor del vehículo.

• Estado de la dirección.

Tanto la información como los comandos se transmiten hacia y desde un sistemaexterno. El desarrollo de cualquier sistema externo no se contempla como un requisito eneste proyecto, pero sí se debe desarrollar la interfaz para las comunicaciones externas.

12 Master Thesis

3Arquitectura del sistema

En este capitulo se define el sistema desarrollado de forma superficial. Se describe laarquitectura utilizada a nivel de sistema distribuido y los requisitos que deben satisfacerlos elementos para poder interactuar en la red.

Para satisfacer todos los requisitos definidos en el capítulo anterior y crear un sistemaescalable, eficiente y seguro, se ha decidido diseñar un sistema distribuido en varios nodos.Estos estarán conectados a una red por la que intercambiarán información.

Cada uno de los nodos ejecutará parte de la funcionalidad del sistema y comunicará lainformación relevante a través de la red. De esta forma, todos los nodos conocerán todala información y reaccionarán según las condiciones del sistema.

3.1 Red de nodos

El protocolo de comunicaciones utilizado es el CAN. Éste basa el intercambio de datos enmensajes broadcast, es decir, todo lo que transmite un nodo es recibido por el resto denodos conectados al bus. Y es el nodo receptor el que decide si almacenar y procesar elmensaje o simplemente lo descarta.


CAPÍTULO 3. ARQUITECTURA DEL SISTEMA

Figura 3.1: Red de nodos del sistema.[9]

Este protocolo de comunicaciones proporciona las siguientes características [9]:

• Prioridad de mensajes

• Garantía de tiempos de latencia

• Flexibilidad en la configuración

• Recepción por multidifusión (multicast) con sincronización de tiempos

• Sistema robusto en cuanto a consistencia de datos

• Sistema multi-maestro

• Detección y señalización de errores

• Retransmisión automática de tramas erróneas

• Distinción entre errores temporales y fallas permanentes de los nodos de la red, ydesconexión autónoma de nodos defectuosos

Este tipo de bus permite desarrollar un sistema distribuido donde se garantice laentrega de mensajes y cumplir plazos de tiempos máximos, pudiendo satisfacer lascaracterísticas de tiempo real en el sistema. Además de asignar prioridades a ciertosmensajes transmitidos por la red o a algunos nodos más críticos frente a otros.

La red del sistema se ha dividido en los siguientes nodos para cumplir con los requisitosdel proyecto.

14 Master Thesis


Figura 3.2: Diagrama del sistema.

Nodo de navegaciónEl nodo de navegación es el encargado de obtener la información relacionada con elestado del vehículo y los sistemas de navegación. Entre los que se pueden encontrarel sistema anti-bloqueo de las ruedas (ABS), los airbags y cinturones de navegacióno el estado de la presión de los neumáticos.

En este proyecto se consideran, para este nodo, el sistema de localización del vehículoy los sensores de fuerzas inerciales instalados en el coche. Esto incluye el sistemaGPS, acelerómetros, giroscopios y brújula.

Nodo de confortEn el nodo de confort se agrupan todos los sistemas que se pueden considerar extraso lujos del vehículo. En este proyecto se considera integrar, como sistemas de confort,la gestión de iluminación automática y la limpieza de los parabrisas del vehículo.

Nodo moto-propulsorLos sistemas clasificados en el grupo moto-propulsor son los encargados de regularla motorización del vehículo. En este proyecto se agrupa además la gestión de ladirección del coche.

Nodo de interfazEl nodo interfaz es el nodo de comunicaciones entre el sistema desarrollado ycualquier sistema externo. La tarea principal de este nodo es la de transmitir todala información de estado al exterior. De este modo, un sistema externo conectadopuede obtener la información para su representación o para realizar un diagnósticosobre estado del sistema.



3.2 Tipos de mensajes

Existen dos tipos de trama de datos para los mensajes que se transmiten por el bus CAN,las tramas de formato base y las tramas de formato extendido. La diferencia entre los dostipos se encuentra en la longitud del identificador del mensaje, mientras que el formatobase contiene un identificador de 11 bits, el formato extendido permite un identificadorampliado de 29 bits. En este proyecto se utilizan las tramas con el formato base delprotocolo.

El resto de campos son equivalentes en ambos formatos, los más significativos a nivelde aplicación son el código de longitud del mensaje y el campo de datos. La longitudpuede ser un máximo de 8 bytes y el tamaño de los datos no pueden superar el indicadopor la longitud.

Para establecer un protocolo de comunicación de alto nivel se asigna un identificadora cada tipo de mensaje, de forma que cada mensaje se pueda identificar inequívocamentea partir del mismo.

Los 11 bits del identificador se dividen en tres campos para ampliar la utilidad delmismo.

Bit 10 9 8 7 6 5 4 3 2 1 0Campo Prio. Nodo Contenido

Tabla 3.1: Identificador de mensaje CAN.

Prioridad (2 bits)Indica el grado de emergencia que requiere el mensaje. Se utilizan los 2 bits mássignificativos.

0) ALERTA: Nivel máximo de prioridad, requiere la transmisión inmediata delmensaje.

1) COMANDO: Los comandos tienen prioridad media alta.

2) DATOS: Los mensajes de datos tienen prioridad media baja.

3) ESTADO: Los mensajes de estado tienen la prioridad mínima.

Nodo (3 bits)Identifica el nodo que genera los mensajes (campo prioridad 0, 2 o 3) o recibey procesa los comandos (campo prioridad 1). Utiliza los 3 bits intermedios,permitiendo hasta 8 nodos en la red. En este proyecto se han reservado 5identificadores, estos son los siguientes:

0) Nodo diagnóstico1

1) Nodo de interfaz inalámbrica

1Se reserva el nodo 0 para el desarrollo de un nodo capaz de valorar y determinar el estado del sistema.

16 Master Thesis


2) Nodo de navegación

3) Nodo moto-propulsor

4) Nodo de confort

Contenido (6 bits)Código interno, que junto al identificador de nodo, identifica inequívocamente laestructura de datos que contiene el mensaje. Con los 6 bits menos significativos sepueden tener hasta 64 estructuras de mensajes diferentes.

Utilizando esta gestión de los identificadores y teniendo en cuenta que los mensajescon identificador CAN menor se enviarán antes por el bus, se obtiene que la prioridadde un mensaje frente a otro se calcula comparando primero la prioridad de los mensajes,siendo ALERTA el más prioritario y ESTADO el de menor prioridad.

Si el identificador de prioridad es igual en dos mensajes, el mensaje que se enviaráprimero se calcula por el identificador de nodo. En este proyecto, por ejemplo, los mensajesdel nodo interfaz son más prioritarios frente a los del nodo de navegación, y a su vez estosson más prioritarios que los del nodo de confort.

3.3 Planificador de tareas

En un sistema informático, el planificador es el proceso software encargado de asignartiempo de cómputo a todos los procesos software que se ejecutan dentro del sistema.

Para la gestión de las tareas de cada nodo se debe utilizar un planificador que permitala ejecución de las tareas en tiempo real.

El planificador utilizado para los nodos de este proyecto es el “ejecutivo cíclico” [10].En un sistema con este tipo de planificador, se genera un plan de ejecución fijo. Este planse divide, a su vez, en ciclos secundarios durante los que se ejecutan determinadas tareasde forma que se asegure el cumplimiento de periodos y plazos de cada tarea.

Figura 3.3: Ejecutivo cíclico.[10]



Se ha elegido un planificador totalmente secuencial para tener mayor control sobre elorden de ejecución de las instrucciones. Otros planificadores, como Round-Robin, repartenel tiempo de Central Processing Unit (CPU) por igual entre todas las tareas, esto puedecausar problemas cuando se requiere satisfacer tiempos máximos de ejecución.

Se estudió el uso del sistema operativo FreeRTOS [11] por ofrecer las característicasnecesarias para cualquier sistema de tiempo real. Se decidió no utilizar este sistemaoperativo debido a las grandes limitaciones de memoria del hardware utilizado.

Se ha elegido el planificador de tipo “ejecutivo cíclico” por su implementación sencillay porque no requiere muchos recursos del sistema.

18 Master Thesis

4Diseño de nodos funcionales

En este capítulo se describen los diferentes nodos funcionales que forman el sistema. Seconsideran los nodos funcionales aquellos que capturan información a través de sensoresy/o realizan acciones mediante actuadores.

4.1 Nodo de navegación

El nodo de navegación es el encargado de obtener la información relacionada con el estadodel vehículo y los sistemas de navegación. Entre los que se pueden encontrar el sistemaanti-bloqueo de las ruedas (ABS), los airbags y cinturones de navegación o el estado dela presión de los neumáticos.

En este proyecto se consideran, para este nodo, el sistema de localización del vehículoy los sensores inerciales instalados en el coche. Esto incluye el sistema GPS, acelerómetros,giroscopio y brújula.

4.1.1 Recursos Hardware

Para el procesamiento del nodo de navegación se utiliza un Arduino Nano [12]. Este esuna placa de circuito impreso basada en el micro-controlador “ATmega328” de Microchipcon arquitectura AVR de 8 bits [12]. Combina 32KB de memoria flash con 2KB de StaticRandom Access Memory (SRAM) y dispone de un reloj de 16MHz. Con esta combinación,la placa consume 19mA.

La placa permite acceder a 22 pines de propósito general de entrada/salida para


CAPÍTULO 4. DISEÑO DE NODOS FUNCIONALES

los programas que los necesiten. De estos pines 8 pueden utilizarse como pines deentrada/salida analógicos, y 6 se pueden usar como salida de tipo Modulación por Anchode Pulso [13] (PWM).

Figura 4.1: Micro-controlador Arduino Nano

Para obtener la información GPS del sistema se utiliza el sensor “Ultimate GPS” deAdafruit [14] (figura 4.2). Este sensor provee los datos de latitud y longitud geográficasademás de la altitud, la hora y la fecha entre otros datos, por medio de una interfaz serie.

El módulo GPS integrado en la placa es el MTK3339 capaz de seguir 22 satélites en66 canales. Con un consumo de 20mA durante la navegación. Para alimentar el móduloes necesario un voltaje de entrada entre 3.3V y 5V.

Este GPS se puede configurar para que funcione de forma independiente y ofrececaracterísticas como ir registrando la localización durante un máximo de 16 horas sinalmacenamiento externo, o mantener la hora y fecha gracias a un reloj interno y una pilade botón.

Figura 4.2: Ultimate GPS

Se utiliza un sensor inercial para capturar los movimientos que realiza el vehículo.El chip utilizado es el “MPU9250” de Invensense [15], que incluye un acelerómetro, un

20 Master Thesis


giroscopio y una brújula. Este chip viene empaquetado en la placa “Gy-91” que proporcionainterfaces Inter-Integrated Circuit (I2C) y Serial Peripheral Interface (SPI) para obtenerlos datos fácilmente. Adicionalmente incluye el sensor BMP280 [16] para medir la presiónbarométrica, que no se ha utilizado en el proyecto.

Figura 4.3: Placa GY-91 con sensores de fuerza.

Las comunicaciones internas del sistema se realizan a través de un controlador CAN.Este se encargará de respetar el protocolo, transmitir los mensajes enviados e indicaral nodo si se han recibido mensajes. El módulo utilizado en este proyecto se componeprincipalmente por dos chips: el MCP2515 de Microchip [17] y el TJA1050 de NXP [18].El MCP2515 es el controlador de protocolo CAN, este es el que gestiona la transferenciade los datos respetando el protocolo CAN. Mientras que el chip TJA1050 es la interfazentre el controlador CAN y el medio físico del bus.



Figura 4.4: Controlador CAN

4.1.2 Recursos Software

El proveedor del sensor GPS proporciona una librería software con la que conectar conel sensor, configurar el mismo y recibir los datos a través de un puerto serie. La libreríautilizada es la librería “Adafruit_GPS” y se puede localizar en el repositorio de github:https://github.com/adafruit/Adafruit_GPS.

El fabricante de la placa utilizada como sensor de aceleraciones no provee una libreríapara arduino. Sin embargo se utiliza una librería de Sparkfun basada en el mismo sensor.Esta librería proporciona los métodos necesarios para obtener los datos del sensor a travésdel bus I2C de forma sencilla. Esta librería se puede descargar del repositorio de github:https://github.com/sparkfun/SparkFun_MPU-9250-DMP_Arduino_Library.

Para las comunicaciones internas por medio del bus CAN se utiliza la librería del“CAN-BUS Shield” de “Seeed Studio”. Esta librería no se ha implementado para elmódulo utilizado en este proyecto, pero es compatible ya que la placa utilizada estábasada en el mismo hardware que el controlador CAN de “Seeed Studio”. Esta libreríase puede descargar del repositorio de github: https://github.com/Seeed-Studio/CAN_BUS_Shield.

Para la gestión de las tareas software que debe ejecutar el micro-controlador se utilizala librería “Protothreads” [19]. Esta librería proporciona métodos para generar y controlarun sistema secuencial como si se ejecutasen varios hilos de forma concurrentes. La gestiónde estos hilos debe ser implementada por el programador para dar el comportamiento dehilos a las funciones del sistema. Esta se puede obtener de la pagina web del desarrolladorAdam Dunkels: http://dunkels.com/adam/pt/download.html.

22 Master Thesis

https://github.com/adafruit/Adafruit_GPS

https://github.com/sparkfun/SparkFun_MPU-9250-DMP_Arduino_Library

https://github.com/Seeed-Studio/CAN_BUS_Shield


http://dunkels.com/adam/pt/download.html


4.1.3 Diseño hardware

En este apartado se describe el circuito hardware diseñado para el nodo de navegación.Esto incluye el circuito electrónico de alimentación y las conexiones entre el micro-controlador y los recursos asociados. El diseño se puede observar en la figura 4.5.

Figura 4.5: Nodo de navegación: Diseño hardware (Fritzing)

4.1.3.1 Circuito de alimentación

El circuito de alimentación está formado por las líneas de voltaje (rojo) y de tierra (negro).El circuito se alimenta a través del micro-controlador. Éste es alimentado por medio delpuerto Universal Serial Bus (USB) integrado en la placa y distribuye la energía al restode componentes.

4.1.3.2 Sistema GPS

El sistema GPS se comunica con el micro-controlador a través de un bus serie. La línea detransmisión (Tx) (verde) del sensor se conecta al pin ’D3’ del micro-controlador, mientrasque la línea de recepción (Rx) (blanco) se conecta al pin ’D2’.

4.1.3.3 Sensor de inercias

Los sensores de inercia se comunica con el micro-controlador a través de un bus I2C.Las líneas de sincronización (SCL) (verde) y de datos (SDA) (amarillo) se conectandirectamente con el micro-controlador en los pines ’A5’ y ’A4’ respectivamente.



4.1.3.4 Controlador CAN

El sistema de comunicación requiere de 5 cables conectados al micro-controlador. Acontinuación se describen tomando como referencia la figura 4.17.

Interrupción (INT) (azul) Indica al micro-controlador cuando existen mensajes en lacola de recepción del controlador CAN.

Reloj (SCK) (gris) Señal de sincronización entre el micro-controlador y el controladorCAN.

Salida (MISO) (verde) Señal de transmisión de datos con origen el controlador CANy destino el micro-controlador (máster).

Entrada (MOSI) (amarillo) Señal de transmisión de datos con origen el micro-controlador (máster) y el controlador CAN.

Selección (CS) (naranaja) Señal de selección, indica al controlador CAN que debeparticipar en la comunicación actual.

4.1.4 Diseño software

En esta sección se describe la arquitectura utilizada para el software del nodo denavegación. Esta arquitectura se representa en el diagrama de clases más adelante.

La clase principal Main es el punto de entrada al programa. Al arrancar el sistemase ejecuta la función “setup” donde se configura e inicializa el nodo. Posteriormente seejecuta la función “loop” en bucle infinito hasta que se apague el nodo. Es en este bucledonde se ejecutan las tareas del nodo.

Se han creado clases abstractas para separar los elementos básicos del programa, estese divide en Tareas y Recursos. Las Tareas son los fragmentos de código que se repartenla CPU para ejecutar la funcionalidad del nodo. Los Recursos son los drivers de acceso alos recursos físicos del sistema, en este caso son el sensor GPS, los sensores inerciales y elcontrolador CAN.

En la figura 4.6 se puede observar el diagrama de clases utilizado para laimplementación del programa instalado en el nodo de navegación. Esta imagen muestralas tareas implementadas y la relación entre cada una de las tareas y los recursos con losque utiliza cada una.

24 Master Thesis


Figura 4.6: Nodo de navegación: Diagrama de clases

4.1.4.1 Tareas

El programa del nodo de navegación se divide en varias tareas. Cada una de las cuales seencargará de realizar una o varias acciones relacionadas entre sí. Para este nodo se hanvisto necesarias 5 tareas diferentes:



Tarea de GPSEsta tarea se encarga de la leer los mensajes enviados por el GPS y procesarlos paraobtener los datos válidos.

Tarea inercialEsta tarea se encarga de consultar la información de los sensores de fuerza, elacelerómetro, giroscopio y brújula.

Tarea de comunicaciones de entradaEsta es la tarea encargada de comprobar si hay mensajes en la cola del controladorCAN y procesarlos si es necesario.

Tarea de comunicaciones de salidaEsta tarea es la encargada de enviar toda la información del nodo por medio delcontrolador CAN.

Tarea de planificadorEsta tarea es la encargada de habilitar la ejecución de cada una de las demás tareas.

Estas tareas se dividen en dos partes. La primera es la configuración de los sensores ylos recursos utilizados por la tarea. La segunda parte es el bucle que realiza las accionescorrespondientes a dicha tarea.

A) Tarea de GPS

Configuración La configuración de esta tarea consiste en iniciar la comunicacióncon el sensor GPS a través de un puerto serie a una velocidad de 9600 baudios yenviar comandos al sensor.

Se le indica al GPS que envíe la mínima información específica recomendada (RMC)[20]. Esta información incluye la hora, la calidad de la recepción de la posición, laposición geográfica, la velocidad y la fecha. También se indica al sensor GPS quedebe enviar los datos con un periodo de 1 Hz.

También se configura una interrupción periodica que almacenará los datos recibidosen un buffer para procesarlos durante la ejecución de la tarea.

Para finalizar se inicializan todas las variables locales que almacenarán los datos.

Ejecución La tarea del GPS consiste en leer los datos enviados por el sensor,procesarlos y almacenar la información en memoria compartida, de este modo lasdemás tareas del programa podrán acceder a los datos.

B) Tarea inercial

Configuración La configuración de esta tarea consiste en iniciar las comunica-ciones con el sensor y configurar el mismo para tomar medidas en los ejes XYZ delacelerómetro, del giroscopio y de la brújula.

26 Master Thesis


El acelerómetro se configura con rango total de +/- 2G de las fuerzas inercialesmedidas, una frecuencia de muestreo de 10 Hz y un filtro de paso bajo de 5 Hz.

El giroscopio se configura con un rango máximo de 2000 grados por segundo. Y labrújula del nodo se configura con una frecuencia de muestreo de 10 Hz.

Para finalizar se inicializan las variables locales de los valores de cada eje de lossensores.

Ejecución La ejecución de esta tarea consiste en obtener los valores de cada unode los sensores en todos sus ejes y almacenarlos en la memoria compartida entre lastareas del programa.

C) Tarea de comunicaciones de entrada

Configuración La configuración de las comunicaciones de entrada consiste enasignar el pin CS del controlador CAN a un pin del micro-controlador. Se establece lavelocidad de comunicación con el controlador a un ratio de 500 Kbps. Y se configurael pin de interrupción de mensajes pendientes.

Ejecución La tarea de recepción de datos consiste en comprobar si hay mensajespendientes de leer en el controlador CAN y en caso afirmativo procesar los mensajesrecibidos.

D) Tarea de comunicaciones de salida

Configuración La configuración de esta tarea se incluye en la tarea decomunicaciones de entrada.

Ejecución La tarea de envío de datos consiste en comprobar si hay datos nuevosobtenidos de los sensores y, en caso afirmativo, enviar por el bus CAN el estado delos sensores actualizado.

E) Tarea de planificador

Configuración La configuración de la tarea de planificación prepara los semáforospara la gestión de todas las demás tareas que se ejecutan en el nodo, e inicia lostemporizadores para el control de las mismas.

Ejecución Esta tarea se encarga de calcular y habilitar las tareas que debenejecutarse en cada momento, habilitando para ello el semáforo de dicha tarea.



4.1.4.2 Planificador

El planificador implementado es un ejecutivo cíclico, clásico de sistemas de tiempo real.Este permite lanzar las tareas de forma periódica.

Cada tarea tiene un periodo de ejecución distinto, y es el planificador el que se encargade habilitar cada una al inicio de su periodo.

A continuación se listan las tareas y sus tiempos de ejecución:

Nombre de tarea Orden de ejecución Periodo de activación (ms)Tarea de planificador 1 0Tarea de comunicaciones de entrada 2 0Tarea de GPS 3 1000Tarea inercial 4 10Tarea de comunicaciones de salida 5 500

Tabla 4.1: Nodo de navegación: Periodo de tareas.

El periodo de activación ’0’ en la tabla anterior significa que se ejecutan en cadaiteración del programa. Para el resto de tareas, es la tarea planificador la que habilita suejecución cuando ha transcurrido el tiempo estipulado.

4.1.4.3 Mensajes CAN

Los mensajes enviados por el bus CAN por el nodo de navegación tienen el campo“Identificador de nodo” constante a ’2’. A continuación se listan los mensajes que envía ylos comandos que procesa este nodo.

AlertasEste nodo no envía mensajes de ALERTA.

ComandosEste nodo no procesa mensajes de COMANDO.

DatosLos mensajes de tipo DATO tienen una prioridad constante a ’2’. Los mensajes deeste tipo que son enviados por este nodo son los siguientes:

0) Datos del acelerómetro del sistema. Estos se nombran en el código como“DAT_ACCELEROMETER_” y el eje al que hace referencia el dato. Estosmensajes contienen el valor del acelerómetro en bruto en formato float de 4bytes.

28 Master Thesis


1) Datos del giroscopio del sistema. Estos se nombran en el código como“DAT_GYROSCOPE_” y el plano sobre el que se aplica la fuerza al que hacereferencia el dato. Estos mensajes contienen el valor del giroscopio en bruto enformato float de 4 bytes.

2) Datos de la brújula del sistema. Estos se nombran en el código como“DAT_COMPASS_” y el eje al que hace referencia el dato. Estos mensajescontienen el valor de la brújula en bruto en formato float de 4 bytes.

3) Hora del sistema. Este mensaje se nombra en el código como “DAT_TIME”y contiene 3 valores en formato entero de 2 bytes cada uno. Los valores seordenan de forma que los dos primeros bytes contienen la hora, los dos bytesintermedios forman los minutos y los dos últimos bytes indican los segundos.

4) Fecha del sistema. Este mensaje se nombra en el código como “DAT_DATE”y contiene 3 valores en formato entero de 2 bytes cada uno. Cada 2 bytes delmensaje indican el año, mes y día del sistema en este orden.

5) Longitud geográfica. Este mensaje se nombra en el código como “DAT_LONGITUDE”,ocupa 4 bytes y se transmite el valor obtenido del sensor sin procesar en formatofloat.

6) Latitud geográfica. Este mensaje se nombra en el código como “DAT_LATITUDE”,ocupa 4 bytes y se transmite el valor obtenido del sensor sin procesar en formatofloat.

7) Altitud geográfica. Este mensaje se nombra en el código como “DAT_ALTITUDE”,ocupa 4 bytes y se transmite el valor obtenido del sensor sin procesar en formatofloat.

8) Velocidad determinada por GPS. Este mensaje se nombra en el código como“DAT_SPEED”, ocupa 4 bytes y se transmite el valor obtenido del sensor sinprocesar en formato float.

9) Orientación determinada por GPS. Este mensaje se nombra en el código como“DAT_ANGLE”, ocupa 4 bytes y se transmite el valor obtenido del sensor sinprocesar en formato float.

EstadoEste nodo no envía mensajes de ESTADO.



Resumen de mensajes del nodo de navegación:

Mensaje ID Prioridad ID Nodo ID Contenido ID CANDAT_ACCELEROMETER_X 2 2 0 1152DAT_ACCELEROMETER_Y 2 2 1 1153DAT_ACCELEROMETER_Z 2 2 2 1154DAT_GYROSCOPE_YZ 2 2 3 1155DAT_GYROSCOPE_XZ 2 2 4 1156DAT_GYROSCOPE_XY 2 2 5 1157DAT_COMPASS_X 2 2 6 1158DAT_COMPASS_Y 2 2 7 1159DAT_COMPASS_Z 2 2 8 1160DAT_TIME 2 2 9 1161DAT_DATE 2 2 10 1162DAT_LONGITUDE 2 2 11 1163DAT_LATITUDE 2 2 12 1164DAT_ALTITUDE 2 2 13 1165DAT_SPEED 2 2 14 1166DAT_ANGLE 2 2 15 1167

Tabla 4.2: Nodo de navegación: Identificadores de mensajes1.

El campo “ID CAN” identifica el valor de los campos “ID Prioridad”, “ID Nodo” e “IDContenido” empaquetados en el campo del protocolo CAN utilizado para identificar losmensajes que se transmiten por el bus. Estos valores son los utilizados por el softwaredesarrollado para este proyecto.

4.2 Nodo de confort

El nodo de confort tiene la responsabilidad de gestionar los recursos considerados comolujos, es decir, aquellos sistemas que ayudan al conductor con acciones sencillas yhabituales pero no necesarias para el uso principal del vehículo. En este sistema se centraen el control de los sistemas de luces del vehículo y el control de los limpiaparabrisas.


Al igual que el nodo de navegación, se utilizan el micro-controlador Arduino Nano [12]para el procesamiento del software del nodo y el controlador “MCP2515” [17] para lascomunicaciones por el bus interno. Más información de estos elementos se puede consultaren la sección 4.1.1.

1Los números están representados en decimal

30 Master Thesis


Para simular el sistema de limpiaparabrisas se utiliza un servomotor SG-90 [21] (figura4.7). Para controlar este motor se debe utilizar una señal PWM, según la señal enviadael motor se pondrá en una posición u otra. Se utiliza este motor porque es pequeño(22.2x11.8x31mm) pesa menos de 10g y es capaz de girar casi 180 grados.

El sistema de limpiaparabrisas también incluye un sensor de lluvia para detectar lapresencia de agua en la superficie del parabrisas y poder actuar en función de la cantidadde agua detectada. Para esta función se utiliza el sensor de lluvia YL-83 (figura 4.8). Estees capaz de detectar gotas de agua: a mayor cantidad de gotas sobre el sensor, aumentala conductividad y el valor proporcionado por el sensor.

Figura 4.7: Servomotor SG-90 Figura 4.8: Sensor YL-83

Para el sistema de iluminación se utilizan 2 leds de color blanco y rojo (figuras 4.9y 4.10) para simular las luces del delantera y trasera, respectivamente, del vehículo. Elsistema de iluminación también incluye un sensor de luminosidad para reaccionar antecambios de la intensidad de luz en el ambiental, por ejemplo si se entra en un túnel.Este sensor es una fotorresistencia [22] (figura 4.11) que aumenta la resistencia eléctricaa mayor intensidad de luz detectada.



Figura 4.9: Led blanco Figura 4.10: Led rojo Figura 4.11: Fotorresistencia


El equipo de desarrollo de Arduino proporciona una librería para el control deservomotores, esta facilita notablemente el uso preciso de un servomotor. Esta libreríatiene el nombre de “Servo”, viene incluida con el IDE de Arduino y se utiliza para elcontrol del limpiaparabrisas del vehículo.

No se utiliza ninguna librería para los sensores de lluvia y luminosidad, sin embargose utilizan las características analógicas del micro-controlador para la lectura del valoranalógico y conversión posterior a valores digitales de cada sensor.

Del mismo modo, se utilizan las características analógicas para el control de las luces.De este modo se puede controlar la intensidad con la que se iluminan las luces del vehículo.


Para la gestión de las tareas software que debe ejecutar el micro-controlador se utilizala librería “Protothreads” [19]. Esta librería proporciona métodos para generar y controlarun sistema secuencial como si se ejecutasen varios hilos de forma concurrentes. La gestiónde estos hilos debe ser implementada por el programador para dar el comportamiento dehilos a las funciones del sistema. Esta se puede obtener de la pagina web del desarrolladorAdam Dunkels: http://dunkels.com/adam/pt/download.html.

32 Master Thesis






En este apartado se describe el circuito hardware diseñado para el nodo de navegación.Esto incluye el circuito electrónico de alimentación y las conexiones entre el micro-controlador y los recursos asociados. El diseño se puede observar en la figura 4.12.

Figura 4.12: Nodo de confort: Diseño hardware (Fritzing)


El circuito de alimentación está formado por las líneas de voltaje (rojo) y de tierra (negro).El circuito se alimenta a través del micro-controlador. Éste es alimentado por medio delpuerto USB integrado en la placa y distribuye la energía al resto de componentes.

4.2.3.2 Sistema de iluminación

El sistema de iluminación lo forman las luces Light Emmitter Diode (LED) y el sensorde luminosidad. El sensor requiere una conexión a los pines analógicos para el filtrado dela señal y la conversión a valores digitales. Las luces LED requieren conexión a puertoshabilitados PWM para ajustar la intensidad de la luz emitida.

Por estos motivos, el sensor de luminosidad se ha conectado al pin ’A1’, la luz trasera(led rojo) al pin ’D5’ y la luz delantera (led blanco) al pin ’D3’.



La electrónica de los componentes requiere la instalación de resistencias adicionales enlos circuitos de las luces LED y el sensor de luminosidad, estas resistencias son de 1kΩ y10kΩ, respectivamente.

4.2.3.3 Sistema de limpiaparabrisas

El sistema del limpiaparabrisas está formado por el sensor de lluvia y el motor que mueveel limpiaparabrisas. El sensor de lluvia requiere una conexión a los pines analógicos delmicro-controlador para la conversión a un valor digital. Mientras que para el motor esnecesario un pin habilitado PWM.

Por esto el sensor de lluvia se conecta al pin ’A0’ del micro-controlador y el servo-motorse conecta al pin ’D6’.


El sistema de comunicaciones CAN se describe en la sección 4.1.3.4. A continuación seidentifican los cables de la figura 4.12, en base a su color.

• Interrupción (INT) (azul)

• Reloj (SCK) (gris)

• Salida (MISO) (verde)

• Entrada (MOSI) (amarillo)

• Selección (CS) (naranaja)


El diagrama de clases del programa para el nodo de confort puede observarse en la figura4.13. Este programa consta principalmente de 3 tipos de elementos: Tareas, Sensoresy Actuadores. De manera especial se pueden encontrar otros 3 elementos fuera de lascategorías anteriores, las clases: Main, BrakeSensor y CANController.

La clase Main es el punto de entrada al programa. Al arrancar el sistema se ejecutala función “setup” donde se configura e inicializa el nodo. Posteriormente se ejecuta lafunción “loop” en bucle infinito hasta que se apague el nodo. Es en este bucle donde seejecutan las tareas del nodo.

Los elementos de tipo Actuador y de tipo Sensor son los drivers que representanlos elementos físicos del nodo. La diferencia entre estos dos tipos consiste en la clasede dispositivo que representan. Un Actuador representa un dispositivos que realiza unaacción sobre el mundo exterior, mientras que un Sensor toma mediciones de él. Dentro

34 Master Thesis


del tipo Actuador se encuentran los LED y el limpiaparabrisas, y en el grupo de Sensoresse incluyen el sensor de luz y el sensor de lluvia.

Las clases CANController y BrakeSensor representan recursos que no puedenclasificarse como ninguno de los anteriores. El CANController representa el acceso a lascomunicaciones por el bus interno del sistema. Por otro lado, el BrakeSensor representaun sensor instalado en otro nodo, en este caso se recibe la información por medio del busy no directamente de un sensor físico.

Las Tareas son fragmentos de código que se ejecutan de forma concurrente eindependiente. Cada uno de estos subprogramas hacen uso de los recursos para realizarsus acciones.



Figura

4.13:Nodo

deconfort:D

iagramade

clases

36 Master Thesis


4.2.4.1 Tareas

El programa del nodo de confort se separa en varias tareas. Cada una de ellas se encargadel control de un sensor o de uno de los actuadores que son responsabilidad de este nodo,también hay tareas para la gestión de las comunicaciones y el control de la planificación.Las tareas de este nodo son las siguientes:

Tarea de luminosidadEsta tarea se encarga de obtener la intensidad de iluminación ambiental y convertirel valor analógico a una escala compatible dentro del sistema.

Tarea de lluviaEsta tarea se encarga de obtener la intensidad de lluvia y convertir el valor analógicoa una escala compatible dentro del sistema.

Tarea de luces delanterasEsta tarea se encarga de controlar la intensidad de las luces frontales del vehículo.

Tarea de luces traserasEsta tarea se encarga de controlar la intensidad de las luces traseras del vehículo.

Tarea de limpiaparabrisasEsta tarea controla la velocidad del limpiaparabrisas.

Tarea de comunicaciones de entradaEsta es la tarea encargada de comprobar si hay mensajes en la cola del controladorCAN y procesarlos si es necesario.

Tarea de comunicaciones de salidaEsta tarea es la encargada de enviar toda la información del nodo por medio delcontrolador CAN.

Tarea de planificadorEsta tarea es la encargada de habilitar la ejecución de cada una de las demás tareas.

Estas tareas se dividen en dos partes. La primera es la configuración de lossensores/actuadores y de inicializar los recursos utilizados por la tarea. La segunda partees el bucle principal que realiza las acciones correspondientes de dicha tarea.

A) Tarea de luminosidad

Configuración La configuración de esta tarea consiste en establecer el pin dondese realiza la lectura del sensor como entrada al micro-controlador e iniciar los valoresde las variables de la tarea.



Ejecución Durante la ejecución de esta tarea se comprueba el valor del sensor y seconvierte a la escala interna del sensor en el sistema. Esta información se almacenaen memoria para que el resto de tareas pueda acceder y reaccionar ante los nuevosvalores medidos.

B) Tarea de lluvia

Configuración La configuración de esta tarea consiste en establecer el pin dondese realiza la lectura del sensor como entrada al micro-controlador e iniciar los valoresde las variables de la tarea.

Ejecución Durante la ejecución de esta tarea se comprueba el valor del sensor y seconvierte a la escala interna del sensor en el sistema. Esta información se almacenaen memoria para que el resto de tareas pueda acceder y reaccionar ante los nuevosvalores medidos.

C) Tarea de luces delanteras

Configuración La configuración inicial de esta tarea establece el pin donde seconecta el led que representa las luces delanteras como salida del micro-controladore inicia el modo de funcionamiento y la intensidad de las luces al valor por defecto.

Ejecución Las luces delanteras pueden funcionar en modo automático o en modomanual. En modo automático, esta tarea ajusta la intensidad de las luces segúnlas condiciones ambientales, esto es posible gracias a la tarea de luminosidad queproporciona los datos necesarios por medio de memoria compartida. En modomanual, ignora el valor capturado por los sensores y reacciona a comandos recibidospor medio del bus CAN que indican el nivel de intensidad al que se deben ajustarlas luces.

D) Tarea de luces traseras

Configuración Al igual que las luces delanteras, la configuración de esta tareaestablece el pin donde se conecta el led que representa las luces traseras, e inicia elmodo de funcionamiento y la intensidad de las luces al valor por defecto.

Ejecución Esta tarea es similar a la tarea para las luces delanteras. Puedeser configurada para funcionar tanto en modo automático como en modomanual, funcionando en ambos casos igual que la tarea anterior. Adicional eindependientemente del modo de funcionamiento, esta tarea reacciona a los cambiosde estado de los frenos del motor del vehículo, este estado se recibe por medio delbus CAN.

38 Master Thesis


E) Tarea de limpiaparabrisas

Configuración La configuración inicial de esta tarea establece e inicializa el pindel servomotor que controla el limpiaparabrisas e inicia el modo de funcionamientoy la velocidad del mismo al valor por defecto.

Ejecución De manera similar a los sistemas de iluminación, el limpiaparabrisaspuede funcionar en modo automático o en modo manual. En modo automático, ellimpiaparabrisas comprueba la información almacenada por la tarea del sensor delluvia y reacciona ajustando la velocidad del motor del limpiaparabrisas. En modomanual, al igual que los sistemas de iluminación, los ajustes de velocidad se recibenen forma de mensajes por medio del bus CAN.

F) Tarea de comunicaciones de entrada


Ejecución La tarea de recepción de datos consiste en comprobar si hay mensajespendientes de leer en el controlador CAN y en caso afirmativo procesar los mensajesrecibidos. El procesamiento de los mensajes dependerá del tipo de mensaje recibido.

G) Tarea de comunicaciones de salida



H) Tarea de planificador









Nombre de tarea Orden de ejecución Periodo de activación (ms)Tarea de planificador 1 0Tarea de comunicaciones de entrada 2 0Tarea de luminosidad 3 10Tarea de lluvia 4 10Tarea de luces delanteras 5 20Tarea de luces traseras 6 20Tarea de limpiaparabrisas 7 150Tarea de comunicaciones de salida 8 500

Tabla 4.3: Nodo de confort: Periodo de tareas.



Los mensajes enviados por medio del bus CAN por el nodo de confort tienen el campo“Identificador de nodo” constante a ’4’. A continuación se listan los mensajes que envía ylos mensajes de tipo “comando” que procesa este nodo.


ComandosLos mensajes de tipo COMANDO tienen una prioridad constante a ’1’. Los mensajesde este tipo que son procesados por este nodo son los siguientes:

0) Modo e intensidad de las luces. Configura el modo de funcionamiento de lasluces del vehículo y establece el nivel de intensidad de las mismas. El mensajese nombra en el código como “CMD_SETLIGHTS” y está formado por 2 bytes.El primer byte indica el modo de funcionamiento mientras que el segundo byteindica la intensidad de las luces.

40 Master Thesis


1) Modo y velocidad del limpiaparabrisas. Configura el modo de funcionamientodel limpiaparabrisas del vehículo y establece la velocidad del mismo. El mensajese nombra en el código como “CMD_SETWIPER” y está formado por 2 bytes.El primer byte indica el modo de funcionamiento mientras que el segundo byteindica la velocidad.


0) Luminosidad ambiental. Indica la intensidad de la luz ambiental detectada porel sistema. Este mensaje se nombra en el código como “DAT_LUMINOSITY”y está formado por 1 byte que indica la intensidad lumínica.

1) Lluvia ambiental. Indica la intensidad de la lluvia detectada por el sistema.Este mensaje se nombra en el código como “DAT_RAIN” y está formado por1 byte que indica la intensidad de la lluvia.

2) Modo e intensidad de las luces. Indica el modo de funcionamiento y el nivel deintensidad actuales de las luces del vehículo. El mensaje se nombra en el códigocomo “DAT_LIGHTS” y está formado por 2 bytes. El primer byte indica elmodo de funcionamiento mientras que el segundo byte indica la intensidad delas luces.

3) Modo y velocidad del limpiaparabrisas. Indica el modo de funcionamiento y lavelocidad actuales del sistema de limpiaparabrisas. El mensaje se nombra en elcódigo como “DAT_WIPER” y está formado por 2 bytes. El primer byte indicael modo de funcionamiento mientras que el segundo byte indica la velocidadde los limpiaparabrisas.


Resumen de mensajes del nodo de confort:

Mensaje ID Prioridad ID Nodo ID Contenido ID CANCMD_SETLIGHTS 1 4 0 768CMD_SETWIPER 1 4 1 769DAT_LUMINOSITY 2 4 0 1280DAT_RAIN 2 4 1 1281DAT_LIGHTS 2 4 2 1282DAT_WIPER 2 4 3 1283

Tabla 4.4: Nodo de confort: Identificadores de mensajes2.





4.3 Nodo moto-propulsor

El nodo moto-propulsor gestiona los elementos principales del vehículo. Estos incluyen elmotor del vehículo para el control del movimiento y el control de la dirección del vehículos.


Al igual que el nodo de navegación y el nodo confort, se utilizan el micro-controladorArduino Nano [12] para el procesamiento del software del nodo y el controlador“MCP2515” [17] para las comunicaciones por el bus interno. Más información de estoselementos se puede consultar en la sección 4.1.1.

Para el motor del vehículo se utiliza un motor eléctrico sin escobillas (brushless) [23]junto a un Electronic Speed Controller [24] (ESC) (figuras 4.14 y 4.15). Este tipo de motorse controla a través de ESC utilizando una señal de tipo PWM.

El motor brushless es un tipo de motor eléctrico caracterizado por no utilizar escobillaspara el cambio de polaridad en el rotor [23]. Se suele utilizar un controlador externo quecontrole la velocidad, este se conoce como ESC.

El ESC [24], como su propio nombre indica, es un componente electrónico utilizadopara controlar la velocidad del motor brushless. Este gestiona la corriente que llega almotor para controlar de forma precisa la velocidad y la fuerza de torsión que ejerza elmotor. Normalmente se controla mediante una señal PWM desde un microcontrolador yse alimenta desde una batería.

La dirección del vehículo es controlada por medio de un servomotor SG-90 [21], quese controla a través de una señal PWM. Este modelo de servomotor es el mismo que elutilizado en el sistema de limpiaparabrisas del nodo confort (sección 4.2.1).

42 Master Thesis


Figura 4.14: Motor brushless y ESC. Figura 4.15: Servomotor SG-90

Figura 4.16: Controlador CAN


Para el control tanto del motor como de la dirección se utiliza la librería “Servo” queproporciona el equipo de Arduino junto al entorno de desarrollo software (IDE). Estafacilita el control de las señales PWM necesarias para controlar los motores.


Para la gestión de las tareas software que debe ejecutar el micro-controlador se utilizala librería “Protothreads” [19]. Esta librería proporciona métodos para generar y controlar





un sistema secuencial como si se ejecutasen varios hilos de forma concurrentes. La gestiónde estos hilos debe ser implementada por el programador para dar el comportamiento dehilos a las funciones del sistema. Esta se puede obtener de la pagina web del desarrolladorAdam Dunkels: http://dunkels.com/adam/pt/download.html.


En este apartado se describe el circuito hardware diseñado para el nodo moto-propulsor.Esto incluye el circuito electrónico de alimentación y las conexiones entre el micro-controlador y los recursos asociados. El diseño se puede observar en la figura 4.17.

Figura 4.17: Nodo moto-propulsor: Diseño hardware (Fritzing)


El circuito de alimentación está formado por las líneas de voltaje (rojo) y de tierra (negro).El circuito está alimentado por una batería de polímero de litio con una capacidad de1800mAh y voltaje de 7’4V.

La batería (figura 4.18) se conecta directamente al circuito de alimentación y sedistribuye la energía al resto de componentes: el micro-controlador, el controlador CANy el servomotor de dirección.

44 Master Thesis



Figura 4.18: Batería

4.3.3.2 Motor

El circuito de control para el motor se compone del micro-controlador, el ESC y el propiomotor brushless. El cable de la señal PWM del ESC se conecta al pin digital ’D5’ delmicro-controlador.

Los tres cables del motor brushless se conectan al controlador respetando el tipo deseñal de cada cable: tierra(negro), control (naranja) y alimentación (rojo).

4.3.3.3 Sistema de dirección

El sistema de dirección lo forma exclusivamente un servo-motor. Este motor es controladopor el micro-controlador a través de una señal PWM conectada al pin ’D3’ del mismo.



• Interrupción (INT) (azul)

• Reloj (SCK) (gris)

• Salida (MISO) (verde)

• Entrada (MOSI) (amarillo)

• Selección (CS) (naranaja)




El diagrama de clases del programa para el nodo de moto-propulsor está representadopor la figura 4.19. En este diagrama se puede observar la separación entre las Tareas delprograma y los drivers que representan los recursos conectados al nodo.

La clase Main es especial, esta es el punto de entrada al programa. Al arrancar elsistema se ejecuta la función “setup” donde se configura e inicializa el nodo. Posteriormentese ejecuta la función “loop” en bucle infinito hasta que se apague el nodo. Es en este bucledonde se ejecutan las tareas del nodo.

La clase CANController representa el bus interno del sistema, se encarga de lascomunicaciones de entrada y salida utilizando el controlador CAN. Las clases que heredande la clase Actuador son drivers para el control de los periféricos conectados al nodo.

Las Tareas son los subprogramas ejecutados por el nodo para realizar las acciones decontrol sobre la parte del sistema que gestiona este nodo.

46 Master Thesis


Figura 4.19: Nodo moto-propulsor: Diagrama de clases



4.3.4.1 Tareas

A) Tarea de motor

Configuración La tarea del motor requiere que se inicialice el pin hardwareconectado al ESC como salida y establecer el valor inicial conocido ya que estevalor será la referencia para el estado parado motor. Desde la inicalización hastaque se apague el motor, el valor establecido al inicio indicará el apagado del motory según aumente el valor de la señal, mayor será la velocidad aplicada por el motor.También se inicializan las variables internas.

Ejecución Esta tarea gestiona la velocidad del motor. Cuando se recibencomandos que signifiquen un cambio de velocidad, esta tarea es la encargada deaumentar o disminuir la potencia del motor para conseguir la velocidad deseada.Esta tarea tiene en cuenta los límites establecidos para no sobrecargar o estropearel motor.

B) Tarea de dirección

Configuración La tarea de dirección inicializa la configuración necesaria para elcontrol de la dirección del vehículo y establece el valor inicial de la misma para queel vehículo vaya recto.

Ejecución Esta tarea gestiona la dirección del vehículo. Esta se modificaúnicamente cuando se recibe un comando para cambiar la dirección a través delbus CAN, mientras tanto se encarga de mantener el ángulo de giro establecido porla última orden recibida.

C) Tarea de comunicaciones de entrada


Ejecución La tarea de recepción de datos consiste en comprobar si hay mensajespendientes de leer en el controlador CAN y en caso afirmativo procesar los mensajesrecibidos.

D) Tarea de comunicaciones de salida


48 Master Thesis



E) Tarea de planificador







Nombre de tarea Orden de ejecución Periodo de activación (ms)Tarea de planificador 1 0Tarea de comunicaciones de entrada 2 0Tarea de motor 3 250Tarea de dirección 4 250Tarea de comunicaciones de salida 5 500

Tabla 4.5: Nodo moto-propulsor: Periodo de tareas.



Los mensajes enviados por el bus CAN por el nodo moto-propulsor tienen el campo“Identificador de nodo” constante a ’3’. A continuación se listan los mensajes que envía ylos comandos que procesa este nodo.




ComandosLos mensajes de tipo COMANDO tienen una prioridad constante a ’1’. Los mensajesde este tipo que son procesados por este nodo son los siguientes:

0) Potencia del motor. Configura la potencia con la que se debe alimentar almotor. Este mensaje se nombra en el código como “CMD_SETMOTOR” ycontiene una variable de tipo entero con una precisión de 1 byte.

1) Dirección del vehículo. Configura la ángulo de la dirección que debe tener elvehículo. Este mensaje se nombra en el código como “CMD_SETDIRECTION”y contiene una variable de tipo entero con una precisión de 1 byte.


0) Potencia del motor. Indica la potencia actual del motor. Este mensaje senombra en el código como “DAT_MOTOR” y contiene una variable de tipoentero con una precisión de 1 byte.

1) Indicador de freno. Indica la el estado del freno del vehículo. Este mensajese nombra en el código como “DAT_BRAKE” y contiene una variable de tipoboolean en 1 byte. Cuando este mensaje contiene el valor ’0’ indica que el frenono está accionado, en otro caso los frenos están activos.

2) Dirección del vehículo. Indica el ángulo de dirección del vehículo. Este mensajese nombra en el código como “DAT_DIRECTION” y contiene una variable detipo entero con una precisión de 1 byte.


Resumen de mensajes del nodo moto-propulsor:

Mensaje ID Prioridad ID Nodo ID Contenido ID CANCMD_SETMOTOR 1 3 0 704CMD_SETDIRECTION 1 3 1 705DAT_MOTOR 2 3 0 1216DAT_BRAKE 2 3 1 1217DAT_DIRECTION 2 3 2 1218

Tabla 4.6: Nodo moto-propulsor: Identificadores de mensajes3.


50 Master Thesis

5Diseño de interfaz y sistema externo

En este capítulo se describe el nodo desarrollado como interfaz que permite al sistemaembebido interactuar con sistemas externos. Este nodo permite extraer información delsistema.

También se describe el desarrollo de una aplicación externa al sistema, y conectada almismo a través del nodo interfaz, capaz de recibir los datos y mostrarlos de forma gráfica.

5.1 Nodo interfaz inalámbrico

Este nodo envía la información de telemetría del sistema de forma inalámbrica a unprograma externo que no se conecta físicamente al bus CAN del sistema.


El hardware utilizado para el nodo de interfaz inalámbrica está formado por la placa“Wemos D1 Mini” (figura 5.1) [25] basada en el micro-controlador “ESP8266” de “Espressif”[26] y un controlador para las comunicaciones CAN.

Este micro-controlador está diseñado con una arquitectura de 32 bits, proporcionamodos de bajo consumo y comunicación Wi-Fi integrada. El micro-controlador es capazde funcionar a una velocidad máxima de 160MHz. Lo más destacado del micro-controladores la integración del módulo Wi-Fi dentro del mismo chip. Esto permite utilizar este tipo deconexiones de forma sencilla. Adicionalmente, los módulos de comunicaciones inalámbricasincluyen los protocolos estándar de seguridad.


CAPÍTULO 5. DISEÑO DE INTERFAZ Y SISTEMA EXTERNO

Figura 5.1: Micro-controlador Wemos D1 Mini (ESP8266)

Las comunicaciones por el bus CAN se realizan a través del controlador CAN“MCP2515” y del transceptor “TJA1050” (figura ??). La comunicación entre el micro-controlador y este módulo se realiza a través de una interfaz SPI. Más información sobreel controlador CAN se puede consultar en la sección 4.1.1.


Las conexiones Wi-Fi se gestionan gracias a la librería “ESP8266WiFi”. Ésta incluye losmétodos necesarios para gestionar las conexiones Wi-Fi necesarias para este proyecto,incluyendo el establecimiento o cierre de una conexión y el envío/recepción de datos.Esta librería se puede localizar en el siguiente repositorio de git: https://github.com/esp8266/Arduino.


La gestión de las tareas software se realiza a través de la librería “Protothreads”[19]. Esta proporciona métodos para generar y controlar un sistema secuencial comosi se ejecutasen varios hilos de forma concurrente. La gestión de los hilos debe sergestionada por el programador para dar el comportamiento de hilos a las funciones delsistema. Esta librería se puede obtener de la página web del desarrollador Adam Dunkels:http://dunkels.com/adam/pt/download.html.

54 Master Thesis

https://github.com/esp8266/Arduino

https://github.com/esp8266/Arduino






En este apartado se describe el circuito hardware diseñado para la interfaz Wi-Fi delsistema. Esto incluye el circuito electrónico de alimentación y las conexiones entre elmicro-controlador y los recursos asociados. El diseño se puede observar en la figura 5.2.

Figura 5.2: Nodo Interfaz Wi-Fi: Diseño hardware (Fritzing)


El circuito de alimentación está formado por las líneas de voltaje (rojo) y de tierra (negro).El circuito se alimenta a través del micro-controlador que es alimentado por medio delpuerto USB integrado en la placa, y distribuye la energía al resto de componentes.



• Interrupción (INT) (gris)

• Reloj (SCK) (morado)

• Salida (MISO) (azul)

• Entrada (MOSI) (verde)

• Selección (CS) (amarillo)




A continuación se describe la arquitectura software utilizada en el software del nodointerfaz Wi-Fi. Este diseño se puede observar en la figura 5.3 y muestra las clasesimplementadas en el programa.

La clase principal Main es el punto de entrada del programa. Al arrancar el sistemase ejecuta una única vez la función “setup”, en este punto se configura e inicializa el nodo.A continuación y de forma continua se ejecuta la función “loop”, en esta función es dondese ejecuta la funcionalidad del nodo.

Las tareas del programa son implementadas con clases de tipo Task, mientras losrecursos físicos y los recursos compartidos se implementan con clases independientes. Lasclases CANController y WIFIController representan y gestionan los recursos hardwarepara el control de las comunicaciones de ambos medios. Por otro lado, las clasesNavigationData, ConfortData y MotorData son necesarios para almacenar la informacióndel sistema global y el envío de esta entre tareas.

Figura 5.3: Nodo interfaz Wi-Fi: Diagrama de clases

56 Master Thesis


5.1.4.1 Tareas

El funcionamiento del nodo interfaz Wi-Fi se separa en varias tareas encargadas del controlde una parte del nodo completo. Las tareas de este nodo son las siguientes:

Tarea de comunicaiones Wi-FiEsta tarea se encarga de transmitir a un programa externo los datos de telemetríadel sistema mediante una conexión inalámbrica.

Tarea de comunicaciones CANEsta es la tarea encargada de comprobar si hay mensajes en la cola del controladorCAN y procesarlos si es necesario.

Tarea de planificadorEsta tarea es la encargada de habilitar la ejecución de cada una de las tareasanteriores.

Estas tareas se dividen en dos partes. La primera es la configuración de lossensores/actuadores y de inicializar los recursos utilizados por la tarea. La segunda partees el bucle principal que realiza las acciones correspondientes de dicha tarea.

5.1.4.1.1 Tarea de comunicaciones CAN

Configuración La configuración de las comunicaciones CAN consiste en asignar elpin CS del controlador CAN a un pin del micro-controlador. Se establece la velocidadde comunicación con el controlador a un ratio de 500 Kbps. Y se configura el pin deinterrupción de mensajes pendientes.

Ejecución Esta tarea gestiona la recepción de los mensajes recibidos por el bus CAN. Delos mensajes recibidos almacena los datos de estado del sistema en memoria compartida.De este modo el resto de tareas puede acceder a la información y reaccionar al estadoactual.

5.1.4.1.2 Tarea de comunicaciones Wi-Fi

Configuración La configuración de las comunicaciones Wi-Fi conlleva configurar elmódulo Wi-Fi del micro-controlador para utilizar una Internet Protocol (IP) fija, asícomo asignar el Service Set Identifier (SSID) y la contraseña para la establecer conexióncon un Access Point (AP) conocido. Una vez conectado se abre un puerto User DatagramProtocol (UDP) por el que enviar toda la información del sistema.



Ejecución Esta tarea obtiene la información del sistema alojada en la memoriacompartida del programa y la retransmite por medio de la red Wi-Fi.

5.1.4.1.3 Tarea de planificador

Configuración La configuración de la tarea de planificación prepara los semáforos parala gestión de todas las demás tareas que se ejecutan en el nodo, e inicia los temporizadorespara el control de las mismas.

Ejecución Esta tarea se encarga de calcular y habilitar las tareas que deben ejecutarseen cada momento, activando para ello el semáforo de dicha tarea.





Nombre de tarea Orden de ejecución Periodo de activación (ms)Tarea de planificador 1 0Tarea de comunicaciones CAN 2 0Tarea de comunicaciones Wi-Fi 3 500

Tabla 5.1: Nodo interfaz inalámbrica: Periodo de tareas.


5.1.4.3 Comunicaciones

Las comunicaciones de este nodo consisten en recibir mensajes por medio del bus CAN yenviar los datos recibidos por medio de la red Wi-Fi a todos los clientes conectados a estenodo.

Este nodo no envía mensajes por medio del bus CAN. Simplemente recibe y almacenala información del sistema.

58 Master Thesis


Las comunicaciones Wi-Fi se realizan a través de una conexión cliente-servidor conmensajes UDP. Este nodo actúa como servidor, acepta la conexión de los clientes ytransmite los datos a los mismos de forma periódica.

5.1.4.3.1 Mensajes Wi-Fi El contenido de los mensajes de la red Wi-Fi siguen unformato propio para organizar los datos incluidos en cada mensaje. A continuación sedefinen los mensajes que se transmiten por esta red.

Estos mensajes se dividen en dos partes. La primera identifica el mensaje y los datosque contiene. La segunda son los propios datos que se transmiten en el mensaje.

El campo identificador del mensaje tiene un tamaño de 2 bytes, permitiendo enviarun total de 65536 mensajes diferentes. Cada tipo de mensaje contiene una estructura dedatos específica para la información incluida.

Información de motor y dirección El identificador de este mensaje es el 1. Y losdatos enviados contienen la información de estado del motor, de los frenos y de la direccióndel vehículo.

Además de los bytes de identificación, este mensaje contiene 6 bytes. La estructura dedatos contiene 2 variables de tipo entero de 2 bytes que representan el estado del motory la dirección, y una variable de tipo boolean de 2 bytes para el estado del freno.

Word Byte 1 Byte 2 Byte 3 Byte 4Word 1 ID de mensaje Estado del motorWord 2 Estado de la dirección Frenos

Tabla 5.2: Mensaje UDP: Información de motor y dirección.

Información de ubicación El identificador de este mensaje es el 2. Los datos enviadosincluyen la información de ubicación geográfica del vehículo, es decir, los datos obtenidospor el sensor GPS que incluyen la latitud y la longitud geográficas, la altitud y la velocidadentre otros.

Además de los bytes de identificación, en este mensaje se envían 30 bytes. La estructurade datos se puede observar en la tabla 5.3, contiene los datos de fecha, hora, latitud,longitud, altitud y velocidad. Los datos de fecha y hora son representados por variablesde tipo entero de 2 bytes. El resto de los datos son representado con una variable de tipofloat de 4 bytes.



Word Byte 1 Byte 2 Byte 3 Byte 4Word 1 ID de mensaje AñoWord 2 Mes DíaWord 3 Hora MinutoWord 4 Segundo ReservadoWord 5 LatitudWord 6 LongitudWord 7 AltitudWord 8 Velocidad

Tabla 5.3: Mensaje UDP: Información de ubicación.

Información de inercia El identificador de este mensaje es el 3. Los datos incluidosen este mensaje hacen referencia a los sensores de inercia del vehículo, es decir, elacelerómetro, el giroscopio y la brújula.

Además de los bytes de identificación, este mensaje ocupa 38 bytes de memoria. Laestructura contiene los datos del acelerómetro, del giroscopio y de la brújula en los 3 ejes decada sensor. Este mensaje queda representado en la tabla 5.4. Cada dato es representadopor una variable de tipo float de 4 bytes.

Word Byte 1 Byte 2 Byte 3 Byte 4Word 1 ID de mensaje ReservadoWord 2 Acelerómetro, eje XWord 3 Acelerómetro, eje YWord 4 Acelerómetro, eje ZWord 5 Giroscopio, plano YZWord 6 Giroscopio, plano XZWord 7 Giroscopio, plano XYWord 8 Brújula, eje XWord 9 Brújula, eje YWord 10 Brújula, eje Z

Tabla 5.4: Mensaje UDP: Información de inercia.

Información de iluminación El identificador de este mensaje es el 4. Los datoscontenidos en este mensaje indican el estado de las luces del vehículo así como el modode funcionamiento del sistema de iluminación y el nivel de luminosidad detectada.

Además de los bytes de identificación, este mensaje ocupa 10 bytes y contiene losdatos del sensor de luz ambiental, el modo de funcionamiento del sistema de iluminación,el estado de las luces delanteras y el estado de las luces trasera. Cada dato se representacon una variable de tipo entero de 2 bytes.

60 Master Thesis


Word Byte 1 Byte 2 Byte 3 Byte 4Word 1 ID de mensaje Sensor de luz ambientalWord 2 Modo de funcionamiento Estado luz delanteraWord 3 Estado luz trasera Reservado

Tabla 5.5: Mensaje UDP: Información de iluminación.

Información de lluvia y limpiaparabrisas El identificador de este mensaje es el5. Los datos contenidos en este mensaje hacen referencia a todos los datos relativos alsistema de lluvias y limpiaparabrisas.

Además de los bytes de identificación, este mensaje ocupa 6 bytes y contiene los datosdel sensor de lluvia, el modo de funcionamiento y la velocidad actual del limpiaparabrisas.Cada dato se representa con una variable de tipo entero de 2 bytes.

Word Byte 1 Byte 2 Byte 3 Byte 4Word 1 ID de mensaje Sensor de lluviaWord 2 Modo de funcionamiento Velocidad de limpiaparabrisas

Tabla 5.6: Mensaje UDP: Información de lluvia y limpiaparabrisas.



5.2 Aplicación software

Se ha desarrollado un sistema externo, en forma de aplicación de ordenador, para mostrarel potencial del sistema desarrollado. Este desarrollo no se incluye en los requisitos delproyecto por no formar parte del sistema embebido y no ir instalado dentro del vehículo.

La aplicación desarrollada tiene como objetivo mostrar a un usuario, los datos delsistema embebido en el vehículo. Estos datos incluyen los valores capturados por lossensores integrados en el sistema y el estado de los actuadores del mismo.

Una aplicación de este tipo podría utilizarse para realizar inspecciones sobre losvehículos de forma más rápida. Acelerar el sistema de tráfico para la inspección técnicade los vehículos (ITV). Se podría usar en los concesionarios para mejorar el servicio derevisiones de los vehículos. Incluso que el propio vehículo sea el responsable de avisar alpropietario a través de una aplicación móvil.

5.2.1 Descripción

La aplicación muestra tres tipos de información enviada por el sistema embebido. Sedividen en datos de moto-propulsión, datos de navegación y datos de confort. La aplicaciónse divide en tres ventanas para cada tipo de información.

Ventana de moto-propulsiónInformación del estado del motor y la dirección del vehículo.

Ventana de navegaciónIncluye información de fecha y hora, además de las coordenadas GPS y lainformación de los sensores inerciales.

Ventana de confortMuestra la información de los sensores de luz y lluvia así como los sistemas deiluminación y el sistema de limpia-parabrisas.


La aplicación se ha desarrollado en el lenguaje de programación Java utilizando laplataforma gráfica JavaFX. Esta incluye todos los medios necesarios para implementaruna aplicación básica de escritorio.

Adicionalmente se importan varias librerías con elementos extra que se han vistonecesarios para esta aplicación. Las primera librería incluye diferentes tipos de medidores.Esta se utiliza para representar la información del motor así como la dirección. Estosrecursos se pueden descargar del siguiente repositorio: https://github.com/HanSolo/Medusa. También se han utilizado algunos elementos de la librería ControlsFX que sepuede localizar en http://fxexperience.com/controlsfx/.

62 Master Thesis

https://github.com/HanSolo/Medusa

https://github.com/HanSolo/Medusa

http://fxexperience.com/controlsfx/


5.2.2.1 Diseño software

La aplicación de escritorio diseñada tiene una ventana con tres pestañas que muestranlos datos del sistema embebido del vehículo. Cada pestaña muestra los datos de cada unode los nodos implementados en este proyecto. En esta sección se describe la arquitecturasoftware de la aplicación y la apariencia gráfica de cada pestaña.

Arquitectura

La aplicación se compone de 2 hilos de ejecución, el primero mantiene la interfaz gráfica,muestra al usuario los cambios en los datos y responde a sus acciones. El segundo hiloes responsable de las conexiones Wi-Fi de la aplicación, mantiene abierto un socket deconexión, lee los datos que se reciban por este y actualiza los valores de los datos delsistema.

En la figura 5.4 se puede observar el diagrama de clases de la aplicación. Lasclases Main y UDPServer representan los hilos de interfaz gráfica y conexiones Wi-Fi,respectivamente, mencionados anteriormente. Las clases de tipo WifiData parsean losmensajes recibidos y almacenan los datos del sistema remoto. Mientras que las clasesMotorTab, NavigationTab y ConfortTab gestionan los elementos gráficos de la aplicación.



Figura 5.4: Aplicación: Diagrama de clases

64 Master Thesis


Pestaña de motor

En esta pestaña de información se muestran los datos recibidos del nodo moto-propulsordel sistema remoto. Esto incluye el estado del motor, de los frenos y de la dirección delvehículo. En la figura 5.5 se pueden observar los indicadores de cada uno de los elementosmencionados.

Figura 5.5: Aplicación: Pestaña de motor

Pestaña de navegación

En esta pestaña se muestran los datos recibidos del nodo navegación del sistema remoto.Estos datos se dividen en cuatro paneles. El primer panel muestra la información obtenidapor el GPS: latitud, longitud, altitud, velocidad, fecha y hora. Los paneles restantesmuestran los valores de los sensores inerciales en sus tres ejes: acelerómetro, brújula ygiroscopio. En la figura 5.6 se pueden observar los indicadores de cada uno de los elementosmencionados.



Figura 5.6: Aplicación: Pestaña de navegación

Pestaña de confort

La pestaña de confort se divide en dos paneles. El primer panel muestra la informaciónrelacionada con el sistema de iluminación, mientras que el segundo panel muestra lainformación del sistema de lluvia y limpiaparabrisas. Ambos sistemas componen el nodode confort del sistema remoto.

El panel de iluminación muestra la intensidad de luminosidad, el modo defuncionamiento y el estado de las luces del vehículo. El panel de lluvia y limpia-parabrisasmuestra la intensidad de la lluvia, además del modo de funcionamiento y la velocidad dellimpia-parabrisas. Esta pestaña se muestra en la figura 5.7

Figura 5.7: Aplicación: Pestaña de confort

66 Master Thesis

6Resultados y Conclusiones

6.1 Resultados

Se ha diseñado e implementado un sistema de comunicaciones haciendo uso del protocoloCAN y hardware específico para este tipo de bus. Este sistema se ha basado en definiruna estructura para la identificación de mensajes con la cuál poder determinar el nivel deimportancia del mensaje, su procedencia (o destino) y el contenido del mismo.

Con este sistema de comunicaciones como núcleo, se han diseñado e implementado va-rios subsistemas. También se han definido los mensajes necesarios para las comunicacionesde cada subsistema y asignado un identificador único siguiendo la estructura definida.

Los subsistemas implementados han sido descritos en los capítulos 4 y 5. En la figura6.1 se pueden observar los subsistemas desarrollados (de izquierda a derecha): moto-propulsor, confort, navegación e interfaz inalámbrica. Todos ellos comunicados entre sípor medio del módulo CAN (abajo).

También se han definido los mensajes que se transmiten por medio de lascomunicaciones inalámbricas. Y se ha desarrollado una aplicación de ordenador que recibelos mensajes y muestra la información al usuario. Esta aplicación se puede ver en detalleen la sección 5.2.


CAPÍTULO 6. RESULTADOS Y CONCLUSIONES

Figura 6.1: Sistema desarrollado.

El coste de desarrollo del proyecto se puede observar en las siguientes tablas. Laprimera (tabla 6.1) resume el tiempo dedicado a las diferentes fases de desarrollo delproyecto, mientras que la segunda tabla (6.2) resume el coste de los materiales utilizadospara la implementación del prototipo.

Tarea Tiempo dedicadoDefinición de requisitos 20 horasEstudio de sistemas y plataformas 120 horasDiseño de arquitectura del sistema 35 horasDiseño de comunicaciones 45 horasDiseño de nodos 60 horasImplementación de comunicaciones 30 horasImplementación de nodos 80 horasDiseño de aplicación 30 horasImplementación de aplicación 20 horasMemoria 80 horasTotal 520 horas

Tabla 6.1: Dedicación de tiempos.

68 Master Thesis


Material CosteArduino Nano (x3) 3 e/u (9 e)Wemos D1 mini 4 eControlador CAN (x4) 2 e/u (8 e)Ultimate GPS 35 eGY-91 5 eSensor de lluvia YL-83 1 eFotorresistencia 0.25 eLeds 0.50 eServomotor SG-90 (x2) 1.5 e/u (3 e)Motor brushless y ESC 40 eBatería 8 eTotal materiales 113.75 eMano de obra 14 e/hCoste de trabajador 7280 eTotal 7393.75 e

Tabla 6.2: Coste de materiales.

6.2 Conclusiones

El proyecto se ha desarrollado, aunque con algunos imprevistos, de forma satisfactoria.A continuación se realiza una valoración de los aspectos del proyecto y las decisionestomadas durante el desarrollo.

6.2.1 Valoración del hardware utilizado

Las prestaciones del hardware utilizado han resultado escasas para el proyectodesarrollado. El mayor problema encontrado al utilizar un Arduino Nano ha sido el tamañode la memoria disponible para el programa.

El sistema Arduino es barato, accesible y fácil de utilizar. Sin embargo, los 32 KBde memoria que ofrece la plataforma utilizada ha resultado un problema al quererusar un sistema operativo de tiempo real con algunas características avanzadas de este.Concretamente, se ha querido utilizar FreeRTOS[11], pero no se han podido añadircaracterísticas como las colas de mensajes. Este sistema operativo ofrece muchas ventajaspara facilitar la gestión de las tareas.

En sistemas reales se utilizan diferentes tipos de micro-controladores[27]. Dependiendode la utilidad que se de al subsistema, requiere un tipo u otro de micro-controlador. Elhardware utilizado en este proyecto sería adecuado para los subsistemas menos críticosdel vehículo. Por ejemplo, estos pueden ser utilizados para ofrecer información al usuarioa través del velocímetro, el kilometraje, o para controlar el estado de algunos sistemas



como el cierre centralizado del vehículo.

Para subsistemas más críticos, como el control del vehículo, habría sido más adecuadoutilizar un micro-controlador de 16 bits con un mayor rendimiento.

El hardware utilizado en un sistema crítico debe funcionar en circunstancias extremas.Por ejemplo, en un vehículo deben soportar muchas vibraciones y golpes. Al tratarse deldesarrollo de un prototipo, ninguno de estos inconvenientes han resultado decisivo parael proyecto y no se han buscado micro-controladores o sensores con estas características.Para un producto que se vaya a lanzar al mercado sí sería necesario investigar y utilizarhardware que satisfaga estos tipos de requisitos.

6.2.2 Valoración de las comunicaciones

Al contrario que el hardware utilizado para los micro-controladores y los sensores, elprotocolo CAN se valora como el punto más fuerte del proyecto. Este sistema decomunicaciones evita problemas que en otros mecanismos son frecuentes.

Los protocolos de red TCP/IP, UDP/IP o Wi-Fi se descartaron por la alta tasa decolisiones y las alta probabilidad de que la perdida de mensajes provoque errores en elsistema. En el proyecto se ha utilizado Wi-Fi pero solo para las comunicaciones externasy evitando que estas afecten al bus interno y al rendimiento del sistema.

El protocolo CAN se definió pensando en sistemas distribuidos de alta integridad.Y se utiliza de forma generalizada en el sector automovilístico. Con ayuda de lalibrería utilizada (ver sección 4.1.2), la documentación facilitada por los desarrolladorese información facilitada por compañeros de clase [28], ha sido relativamente fácil utilizareste tipo de comunicaciones en el sistema.

Al tener solo tres nodos en la red, enviando pocos mensajes cada uno, no se ha podidoapreciar ningún problema de rendimiento.

Existen otros protocolos pensados para sistemas distribuidos de tiempo real, como“Real-Time Ethernet”[29][30] o “Local Interconnect Network”[31]. Pero se decidió utilizarCAN sobre estos protocolos por tener fuentes de información más accesibles.

6.2.3 Valoración de la programación

Como lenguaje de programación se valoraron Java, C/C++ y Ada. Java, aunque es unlenguaje de programación muy utilizado, no está preparado para sistemas de tiempo real.

Java sí se ha utilizado para el desarrollo de la aplicación, donde no se han aplicadorequisitos de tiempo real.

Para el software de los micro-controladores se ha utilizado C/C++ ya que el entornode Arduino viene preparado para desarrollar en este lenguaje.

70 Master Thesis


Para el desarrollo se ha decidido separar las diferentes funcionalidades en varias tareasy utilizar un planificador de tipo cíclico para gestionar el orden de ejecución de las mismas.

Los nodos se han diseñado de tal manera que no existen tareas esporádicas ni acíclicasy con un número de tareas reducido por nodo. Por esto, el planificador elegido ha sidosuficiente para los nodos desarrollados y ha facilitado el diseño del sistema.

En el sistema real de un vehículo con motor de explosión, este tipo de planificadorsería adecuado para utilizarse en nodos que requieran un nivel de seguridad menor, porejemplo en el control de la iluminación del vehículo. Sin embargo, la gestión de un motorde explosión es muy compleja y debe ser precisa, un subsistema encargado de esta tareadebe tener en cuenta tareas cíclicas así como eventos esporádicos, y cada acción que seejecute debe realizarse siguiendo un orden de prioridades. Sería más adecuado utilizar unplanificador que tenga esto en cuenta, como por ejemplo un planificador con prioridadesdinámicas [32] donde se da preferencia a las tareas con un plazo de finalización máscercano.

6.2.4 Valoración de la metodología

Aunque no se ha seguido una metodología estricta durante el desarrollo de este proyecto,el mismo desarrollo ha seguido la línea del modelo de prototipos.

Se decidió utilizar este modelo de desarrollo por no tener claros los objetivos finalesni los requisitos del proyecto.

Aplicando este modelo de desarrollo se han ido desarrollando varias aproximacionesutilizando diferentes tecnologías. Teniendo en cuenta los diferentes resultados, se han idotomando decisiones para reducir, redefinir o ampliar los requisitos que se querían obtenery descartar o probar diferentes tecnologías.

Como ejemplo, en la primera iteración del desarrollo se quiso utilizar el sistemaoperativo FreeRTOS[11] pero no se pudo integrar por falta de recursos en los micro-controladores. En la siguiente iteración se sustituyó por el ejecutivo cíclico utilizado.

Creo que esta metodología sería adecuada en departamentos de investigación ydesarrollo donde el objetivo sea el de investigar nuevas tecnologías o un nuevo producto.En entornos donde se conozcan los objetivos y los requisitos, una metodología incrementalo en espiral serían más adecuadas.

A nivel personal volvería a aplicar esta metodología si no tuviera claros los recursosmínimos del proyecto o hubiese tiempo de explorar varias posibles implementaciones.



6.3 Trabajos futuros

El desarrollo llevado a cabo durante este proyecto ha dado como resultado un prototipoen fase estable. Para obtener un producto final sería necesario seguir ampliando lafuncionalidad del mismo y mejorar los sistemas existentes. Algunas mejoras que podríanaplicarse son:

• Ampliar la funcionalidad del sistema añadiendo nodos dedicados. Por ejemplo, elanálisis del entorno y detección de obstáculos.

• Añadir una interfaz de usuario para el control del vehículo.

• Mejorar el sistema de comunicaciones ampliando el número de nodos que permiteel sistema actual.

• El desarrollo de un control autónomo del vehículo haciendo uso de la informacióncapturada por los nodos conectados a la red.

72 Master Thesis

Bibliografía

[1] Quantislabs Ltd. Smart Vineyard. http://smartvineyard.com/home/. Visitado:07/04/2018.

[2] Roberto Ambrosio Lázaro y Abraham Sánchez Gaspariano. La importancia de laelectrónica en el desarrollo del automóvil. http://saberesyciencias.com.mx/2017/06/04/la-importancia-de-la-electronica-en-el-desarrollo-del-automovil/. Visitado: 06/03/2018.

[3] Datos Macro. España - Matriculaciones de vehículos nuevos. https : / / www .datosmacro . com / negocios / matriculaciones - vehiculos / espana. Visitado:06/03/2018.

[4] Soluciones Guemacar. La evolución de los sistemas electrónicos de los automóviles.http://www.solucionesguemacar.es/blog/entry/la-evolucion-de-los-sistemas-electronicos-de-los-automoviles. Visitado: 06/03/2018.

[5] Arduino. Arduino software. https : / / www . arduino . cc / en / main / software.Visitado: 06/03/2018.

[6] Don Ho. Notepad++. https://notepad-plus-plus.org. Visitado: 06/03/2018.[7] Universidad Politécnica de Madrid. Máster Universitario en Software de Sistemas

Distribuidos y Empotrados. http://msde.etsisi.upm.es/. Visitado: 06/03/2018.[8] Motor Industry Software Reliability Association. MISRA C, MISRA C++. www.

prqa.com/coding-standards/misra/. Visitado: 06/03/2018.[9] Raúl Milla Pérez. Arcan, Intercomunicación de Arduinos mediante CanBus. www.

arcan.es/?p=70. Visitado: 06/03/2018.[10] Juan Antonio de la Puente. Sistemas de tiempo real basados en ejecutivos cíclicos.

http://isa.uniovi.es/docencia/TiempoReal/Recursos/Transparencias/Ciclicos.pdf. Visitado: 06/03/2018.

[11] FreeRTOS. The FreeRTOS Kernel. http : / / www . freertos . org. Visitado:06/03/2018.

[12] Arduino. Arduino Nano. https://store.arduino.cc/arduino-nano. Visitado:06/03/2018.

[13] Wikipedia. Pulse-width modulation. https://en.wikipedia.org/wiki/Pulse-width_modulation. Visitado: 06/03/2018.

[14] Adafruit. Adafruit Ultimate GPS Breakout. https : / / learn . adafruit . com /adafruit-ultimate-gps/. Visitado: 06/03/2018.


http://smartvineyard.com/home/

http://saberesyciencias.com.mx/2017/06/04/la-importancia-de-la-electronica-en-el-desarrollo-del-automovil/



https://www.datosmacro.com/negocios/matriculaciones-vehiculos/espana

https://www.datosmacro.com/negocios/matriculaciones-vehiculos/espana

http://www.solucionesguemacar.es/blog/entry/la-evolucion-de-los-sistemas-electronicos-de-los-automoviles

http://www.solucionesguemacar.es/blog/entry/la-evolucion-de-los-sistemas-electronicos-de-los-automoviles

https://www.arduino.cc/en/main/software

https://notepad-plus-plus.org

http://msde.etsisi.upm.es/

www.prqa.com/coding-standards/misra/

www.prqa.com/coding-standards/misra/

www.arcan.es/?p=70

www.arcan.es/?p=70

http://isa.uniovi.es/docencia/TiempoReal/Recursos/Transparencias/Ciclicos.pdf

http://isa.uniovi.es/docencia/TiempoReal/Recursos/Transparencias/Ciclicos.pdf

http://www.freertos.org

https://store.arduino.cc/arduino-nano

https://en.wikipedia.org/wiki/Pulse-width_modulation

https://en.wikipedia.org/wiki/Pulse-width_modulation

https://learn.adafruit.com/adafruit-ultimate-gps/

https://learn.adafruit.com/adafruit-ultimate-gps/

BIBLIOGRAFÍA

[15] Invensense. MPU-9250 Nine-Axis (Gyro + Accelerometer + Compass) MEMSMotionTrackingTMDevices. https://www.invensense.com/products/motion-tracking/9-axis/mpu-9250/. Visitado: 06/03/2018.

[16] Bosch Sensortec. BMP280 Digital Pressure Sensor. https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf. Visitado: 06/03/2018.

[17] Microchip Technology Inc.MCP2515 Stand-Alone CAN Controller With SPITMInterface.http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf. Visitado:06/03/2018.

[18] Phillips Semiconductors. TJA1050 High speed CAN transceiver. https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf. Visitado: 06/03/2018.

[19] Adam Dunkels. Protothreads, a powerfull library. http://harteware.blogspot.com . es / 2010 / 11 / protothread - and - arduino - first - easy . html. Visitado:06/03/2018.

[20] Glenn Baddeley. GPS - NMEA sentence information. http://aprs.gids.nl/nmea/. Visitado: 06/03/2018.

[21] Akizuki Denshu Tsusho. SG90 Micro Servo. http : / / akizukidenshi . com /download/ds/towerpro/SG90.pdf. Visitado: 06/03/2018.

[22] Wikipedia. Photoresistor. https://en.wikipedia.org/wiki/Photoresistor.Visitado: 06/03/2018.

[23] Wikipedia. Brushless DC electric motor.

[24] Wikipedia. Electronic speed control.

[25] WEMOS. Wemos Electronics, D1 mini. https://wiki.wemos.cc/products:d1:d1_mini. Visitado: 06/03/2018.

[26] Espressif. ESP8266 Overview. http://espressif.com/en/products/hardware/esp8266ex/overview. Visitado: 06/03/2018.

[27] Tarun Agarwal. Different types of microcontrollers are used in automobile applica-tions. https://www.elprocus.com/different-microcontrollers-used-in-automobiles/. Visitado: 09/04/2018.

[28] Adrian Martinez Requena. Introduccion a CAN bus: Descripcion, ejemplos yaplicaciones de tiempo real. Tesis de máster. 2017.

[29] Inc. Contemporary Control Systems. Introduction to Real-Time Ethernet I. https://www.ccontrols.com/pdf/Extv5n3.pdf. Visitado: 06/03/2018.

[30] Inc. Contemporary Control Systems. Introduction to Real-Time Ethernet II. https://www.ccontrols.com/pdf/Extv5n4.pdf. Visitado: 06/03/2018.

[31] Microcontroller Division Applications. LIN (Local Interconnect Network) Solutions.http : / / www . st . com / content / ccc / resource / technical / document /application_note/10/30/18/b5/90/bc/4c/73/CD00004273.pdf/files/CD00004273.pdf/jcr:content/translations/en.CD00004273.pdf. Visitado:06/03/2018.

74 Master Thesis

https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf

https://cdn-shop.adafruit.com/datasheets/BST-BMP280-DS001-11.pdf

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf

https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf

http://harteware.blogspot.com.es/2010/11/protothread-and-arduino-first-easy.html

http://harteware.blogspot.com.es/2010/11/protothread-and-arduino-first-easy.html

http://aprs.gids.nl/nmea/

http://aprs.gids.nl/nmea/

http://akizukidenshi.com/download/ds/towerpro/SG90.pdf

http://akizukidenshi.com/download/ds/towerpro/SG90.pdf

https://en.wikipedia.org/wiki/Photoresistor

https://wiki.wemos.cc/products:d1:d1_mini

https://wiki.wemos.cc/products:d1:d1_mini

http://espressif.com/en/products/hardware/esp8266ex/overview

http://espressif.com/en/products/hardware/esp8266ex/overview

https://www.elprocus.com/different-microcontrollers-used-in-automobiles/

https://www.elprocus.com/different-microcontrollers-used-in-automobiles/

https://www.ccontrols.com/pdf/Extv5n3.pdf




http://www.st.com/content/ccc/resource/technical/document/application_note/10/30/18/b5/90/bc/4c/73/CD00004273.pdf/files/CD00004273.pdf/jcr:content/translations/en.CD00004273.pdf



BIBLIOGRAFÍA

[32] Francisco Pastor. Planificación en Tiempo Real. https://www.uv.es/gomis/Apuntes_SITR/Planificacion.pdf. Visitado: 10/04/2018.


https://www.uv.es/gomis/Apuntes_SITR/Planificacion.pdf

https://www.uv.es/gomis/Apuntes_SITR/Planificacion.pdf

universidad politécnica de madrid escuela técnica superior...

Documents