Embed Size (px)
Citation preview
UNIVERSIDAD DE BUENOS AIRES
FACULTAD DE INGENIERÍA
CARRERA DE ESPECIALIZACIÓN EN SISTEMAS
EMBEBIDOS
MEMORIA DEL TRABAJO FINAL
Sistema de telemetría por red celularGSM utilizando CIAA
Autor:Ing. Gustavo Llanes
Director:Esp. Ing. Pablo Ridolfi (UTN-FRBA, FIUBA)
Jurados:Ing. Juan Manuel Cruz (UTN-FRBA, FIUBA)
Dr. Ing. Pablo Gómez (FIUBA)Esp. Ing. Eric Pernia (UNQ, FIUBA)
Este trabajo fue realizado en las Ciudad Autónoma de Buenos Aires, entre Abrilde 2016 y Agosto de 2017.
III
Resumen
En esta memoria se describe el diseño de un sistema de telemetría por redcelular desarrollado para la empresa Koner Seguridad. El sistema permite
monitorear el estado de las entradas de una EDU-CIAA y observarlas través deuna plataforma web. El objetivo del proyecto es cubrir la demanda de clientesque necesitan monitorear diversos sensores y visualizar su estado en la misma
plataforma web que utilizan para controlar su flota de vehículos.
Se utilizaron los conocimientos adquiridos durante la carrera, se hizo uso detécnicas de programación, de gestión de proyecto e ingeniería de software.Durante el desarrollo se utilizaron repositorios, se realizaron test unitarios,
funcionales y pruebas de caja negra para garantizar el buen funcionamiento delsistema.
V
Agradecimientos
A Pablo Ridolfi, director del trabajo, a los jurados y a los profesores de la carrerade Especialización en Sistemas Embebidos que me acompañaron durante estaformación profesional.
VII
Índice general
Resumen III
1. Introducción General 11.1. Telemetría . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introducción Específica 32.1. Funcionamiento general del sistema . . . . . . . . . . . . . . . . . . 32.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Diseño e Implementación 73.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Selección de componentes . . . . . . . . . . . . . . . . . . . . 73.1.2. Decisiones de diseño . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1. Arquitectura de firmware . . . . . . . . . . . . . . . . . . . . 103.2.2. Protocolos de comunicación . . . . . . . . . . . . . . . . . . . 11
Comandos AT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Protocolo UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 12Especificación NMEA . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Diseño en detalle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Ensayos y Resultados 194.1. Test Unitarios en cada tarea . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1. Ensayo 1 - Prueba de tarea Digital In . . . . . . . . . . . . . . 194.1.2. Ensayo 2 - Prueba de tarea LEDs . . . . . . . . . . . . . . . . 194.1.3. Ensayo 3 - Prueba de tarea Adc . . . . . . . . . . . . . . . . . 204.1.4. Ensayo 4 - Prueba de Funciones . . . . . . . . . . . . . . . . 214.1.5. Ensayo 5 - Prueba de tarea GPS . . . . . . . . . . . . . . . . . 214.1.6. Ensayo 6 - Prueba de tarea GSM . . . . . . . . . . . . . . . . 21
4.2. Test funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2.1. Ensayo 1 - Prueba de envio de paquete y ACK . . . . . . . . 224.2.2. Ensayo 2 - Prueba de posición . . . . . . . . . . . . . . . . . . 234.2.3. Ensayo 3 - Prueba de eventos . . . . . . . . . . . . . . . . . . 234.2.4. Ensayo 4 - Prueba led GSM . . . . . . . . . . . . . . . . . . . 234.2.5. Ensayo 5 - Prueba led GPS . . . . . . . . . . . . . . . . . . . . 244.2.6. Ensayo 6 - Prueba de reenvió de posición . . . . . . . . . . . 24
4.3. Pruebas de campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.1. Ensayo 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.2. Ensayo 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3.3. Ensayo 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
VIII
4.3.4. Ensayo 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.3.5. Ensayo 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Conclusiones 275.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . . . 275.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
IX
Índice de figuras
2.1. Diagrama de funcionamiento del sistema . . . . . . . . . . . . . . . 32.2. Diagrama de actividad . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3. Diagrama de Gannt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Plataforma EDU-CIAA-NXP . . . . . . . . . . . . . . . . . . . . . . . 73.2. Diagrama en bloques de la EDU-CIAA . . . . . . . . . . . . . . . . . 83.3. Imagen del módulo de desarrollo SIM9081. . . . . . . . . . . . . . . 93.4. Circuito esquemático de las conexiones entre la EDU-CIAA y el
módulo SIM908 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.5. Ciclo de vida modelo en V . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Imagen de la UART-USB al ejecutar el ensayo 1 . . . . . . . . . . . . 194.2. Imagen de la UART USB al ejecutar el ensayo 3. . . . . . . . . . . . 204.3. Verificación del armado del paquete RUS07. . . . . . . . . . . . . . . 214.4. Verificación del armado del paquete RGP. . . . . . . . . . . . . . . . 214.5. Imagen de la UART USB al ejecutar el ensayo 5. . . . . . . . . . . . 224.6. Imagen de la UART USB al ejecutar el ensayo 6. . . . . . . . . . . . 224.7. Imagen de UART USB al ejecutar el ensayo 1. . . . . . . . . . . . . . 234.8. Imagen de la UART USB al ejecutar el ensayo 2. . . . . . . . . . . . 234.9. Imagen de ubicación,fecha y hora reportada en el software de mo-
nitoreo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.10. Imagen de UART USB en el ensayo 6. . . . . . . . . . . . . . . . . . 25
XI
Índice de Tablas
3.1. Tabla de comandos AT . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2. Tabla de mensajes GPGGA en formato NMEA . . . . . . . . . . . . 133.3. Tabla de mensajes GPRMC en formato NMEA . . . . . . . . . . . . 14
1
Capítulo 1
Introducción General
En este capítulo se da una introducción básica y los motivos por los cuales serealizó el proyecto, también se detallan los objetivos y alcance del mismo.
1.1. Telemetría
Se conoce como telemetría al sistema que permite la monitorización, medicióny/o seguimiento de magnitudes físicas o químicas a través de datos que sontransferidos a una central de control. La palabra telemetría es de origen griego“tele"que significa “distancia” y “metría” que expresa “medida”.
El sistema de telemetría se realiza normalmente mediante comunicación inalám-brica pero también se puede realizar a través de otros medios como: teléfono,redes de ordenadores, enlace de fibra óptica, entre otros. La telemetría es usadaen áreas muy diversas que van desde el automovilismo, aviación, astronomía,pasando por la agricultura, industria de petróleo, medicina y hasta la biología.
La telemetría tiene como objetivo permitir la medición de magnitudes físicas oquímicas, conocer los estados de los procesos y sistema, así como controlar demanera remota el funcionamiento, corregir los errores y enviar la informaciónrecabada hacia un sistema de información para su uso y provecho.
El sistema de telemetría funciona por medio de un transductor como dispositivode entrada, un medio de transmisor en forma de líneas de cable u ondas de radio,procesamiento de señales, dispositivo de grabación o visualización de datos. Eltransductor tiene como principal función convertir la magnitud física o químicacomo la temperatura, presión, vibraciones, voltaje, en una señal eléctrica, que estransmitida a distancia a efecto de ser registrada y medida.
1.2. Motivación
La motivación principal por la cual se eligió este proyecto es aplicar los cono-cimientos y herramientas aprendidos durante la carrera de Especialización deSistemas Embebidos y además proporcionar a la empresa en la cual trabajo unnuevo producto.
Actualmente muchos de los clientes que utilizan equipos AVL (Automatic Vehi-cle Location, Localización Automática de Vehículos) para monitorear su flota devehículos, tienen la necesidad de monitorear magnitudes físicas en lugares fijos
2 Capítulo 1. Introducción General
y visualizar esa información en forma de gráficos o alarmas en la misma aplica-ción web que utilizan para el control de su flota. Esta solución permitiría cubriresta demanda a un costo relativamente bajo comparado a un sistema PLC u otrasalternativas ofrecidas en el mercado.
1.3. Objetivos y alcance
El objetivo de este proyecto es diseñar un prototipo funcional que pueda ser uti-lizado como base para luego desarrollar un producto propietario en una segundaetapa.
El proyecto inicial solo incluye el diseño del software necesario para que unaEDU-CIAA pueda transmitir datos de sensores conectados a ella, a través de unmodulo de comunicación celular GPS/GPRS hacia una plataforma de monitoreodeterminada.
El presente proyecto no incluye el diseño del hardware del módulo GPS/GPRS.Se utilizará una placa de desarrollo.
Tampoco incluye la programación necesaria para visualizar de los parámetrostransmitidos en la plataforma de monitoreo, solo incluye la entrega de un do-cumento en el cual se le indique a los desarrolladores del software, como es elformato en el cual ingresan los datos.
3
Capítulo 2
Introducción Específica
En este capítulo se presenta una introducción básica del funcionamiento del sis-tema, también se detallan los requerimientos y la planificación del proyecto.
2.1. Funcionamiento general del sistema
El proyecto consiste en un sistema de telemetría que permite ver datos de sen-sores en forma remota a través de una plataforma web. La figura 2.1 ilustra eldiagrama básico del funcionamiento del sistema.
Como se observa en la figura 2.1, el hardware utilizado es una EDU-CIAA lacual recibe datos de sensores analógicos y digitales e información de un móduloGPS, y los envía a través de una de sus salidas serie UART al módulo GSM. Estemódulo es el encargado de enviar la información a internet a través de la redGPRS utilizando el protocolo UDP.
Finalmente los datos son procesados por una aplicación y el usuario puede acce-der a ellos a través de una PC u otro dispositivo conectado a internet.
Entradas:-Sensores Analogicos-Entradas digitales-Datos del módulo GPS
Red GPRSInternet
Módulo GSM
Serial Uart
Plataforma de monitoreo web
FIGURA 2.1: Diagrama de funcionamiento del sistema
4 Capítulo 2. Introducción Específica
2.2. Requerimientos
A continuación se listan los requerimientos del proyecto.
1. Grupo de requerimientos asociados con el módulo GPS.
a) Consultar al módulo la posición, la fecha y la hora, cada 1 segundo.
2. Grupo de requerimientos asociados entradas digitales.
a) Monitorear el estado de las entradas digitales cada 500 ms.
b) Si se detecta un cambio en alguna de las entradas generar un eventoespecial.
3. Grupo de requerimientos asociados entradas analogicas.
a) Monitorear el estado de las entradas analogicas cada 500 ms.
b) Si se detecta un cambio del 10 % en alguna de las entradas generar unevento especial.
4. Grupo de requerimientos asociados a la red MODBUS
a) Monitorear cada 1 segundo el estado de al menos un sensor conectadoa la Red Modbus.
b) El sensor debe utilizar el protocolo Modbus ASCII.
5. Grupo de requerimientos asociados al módulo GPRS
a) Se debe enviar a la plataforma de monitoreo una trama con el estado delos sensores, junto con la posición y la fecha actual, según las siguientescondiciones:
1) Siempre cada 1 minuto.
2) Cada vez que produce un evento especial (como los indicados enlos puntos 2.2 y 3.2).
b) El envío de datos será realizado vía UDP a una IP y puerto específico.
c) Se deberá recibir un ACK, con la confirmación del que la trama fuerecibida por la plataforma de monitoreo.
d) En caso que la trama no sea recibida, se volverá a reintentar el envíocada 15 segundos.
e) Realizar una cola para el envío de las tramas.
2.3. Planificación
A modo ilustrativo se incluye el diagrama de actividad y el diagrama de Ganttdel proyecto, en las figuras 2.2 y 2.3 respectivamente, los cuales fueron realizadosdurante la planificación del proyecto realizada en la materia Gestión de Proyectosen Ingeniería.
El “Activity-on-node” (AON) es una diagrama temporal del proyecto, los cuadrosrepresentan hitos y tareas, letra “t” indica la duración y flechas señalan el flujo
2.3. Planificación 5
secuencial de un cuadro al otro. El tiempo “t” está expresado en días. Se considera8 hs por día de trabajo y se estimaron en total unas 608 hs de trabajo.
FIGURA 2.2: Diagrama de actividad
6 Capítulo 2. Introducción Específica
FIGURA 2.3: Diagrama de Gannt.
7
Capítulo 3
Diseño e Implementación
En este capítulo se detalla cuál fue el hardware elegido, las decisiones de diseñotomadas y cómo se diseñó el firmware del proyecto.
3.1. Hardware
3.1.1. Selección de componentes
Sistema embebido
La utilización de la plataforma CIAA se definió como uno de los requerimientosdel proyecto. Se optó por la utilización de la EDU-CIAA, ya que mantiene lasprestaciones necesarias para el desarrollo del mismo pero con un costo reducido.
FIGURA 3.1: Plataforma EDU-CIAA-NXP
La EDU-CIAA está basada en la CIAA-NXP, su microcontrolador es el LPC4337(dual core ARM Cortex-M4F y Cortex-M0). En la figura 3.2 se puede observar eldiagrama en bloques.
La EDU-CIAA cuenta con los siguientes módulos:
2 puertos micro-USB (uno para aplicaciones y debugging, otro para alimen-tación).
4 salidas digitales implementadas con leds RGB.
4 entradas digitales con pulsadores.
1 puerto de comunicaciones RS 485 con bornera.
2 conectores de expansión:
• P1:
8 Capítulo 3. Diseño e Implementación
FIGURA 3.2: Diagrama en bloques de la EDU-CIAA
◦ 3 entradas analógicas
◦ 1 salida analógica
◦ 1 puerto I2C
◦ 1 puerto asincrónico full duplex (para RS-232)
◦ 1 puerto CAN
◦ 1 conexión para un teclado de 3x4
• P2:
◦ 1 puerto Ethernet,
◦ 1 puerto SPI,
◦ 1 puerto para Display LCD con 4 bits de datos, Enable y RS.
◦ 9 pines genéricos de I/O.
Para el proyecto se utilizaron las teclas y los LEDs de la EDU-CIAA para simularentradas y salidas digitales, y se utilizó el conector de expansión derecho (P1) pa-ra conectar el módulo GSM y las entradas analógicas, y el conector de expansiónizquierdo (P2) para conectar el módulo GPS.
Modulo GSM/GPRS
Para el módulo de comunicación se utilizó el SIM908, ya que se consiguió en elmercado local una placa de desarrollo de bajo costo, se ilustra en la figura 3.3.Además este modulo y su familia es ampliamente utilizado en equipos AVL. Laalimentación y niveles lógicos de 3.3V, son compatible con la EDU-CIAA.
Características técnicas:
Cuatribanda: 850/ 900/ 1800/ 1900 MHz
GPRS multi-slot class 10
GPRS mobile station class B
3.1. Hardware 9
Cumple con GSM phase 2/2+
• Classe 4 (2 W @ 850/900 MHz)
• Classe 1 (1 W @ 1800/1900 MHz)
Control a través de comandos AT (GSM 07.07 ,07.05 y comandos AT mejo-rados por SIMCom)
Aplicación de herramientas SIM
Alimentación:
• GPRS: 3,2 4.8V
• GPS: 3.0 4.5V
Bajo consumo eléctrico
Dimensiones: 30x30x3,2 milímetros
Peso: 5,2 g
Temperatura de funcionamiento: de menos 40 a 85 grados
FIGURA 3.3: Imagen del módulo de desarrollo SIM9081.
3.1.2. Decisiones de diseño
En la EDU-CIAA ninguno de los pines necesarios para conectar la UART1 estánruteados al microcontrolador, por este motivo no disponemos de una entradaUART necesaria para conectar la salida GPS del módulo SIM908, debido a estose planteó la posibilidad de obtener los datos consultando el estado del móduloGPS a través de la UART0, es decir la salida conectada al módulo GSM.
Mediante comandos AT se puede obtener los datos de la posición en formatoNMEA del módulo GPS. La desventaja de esto es que los comando AT se puedenenviar de a uno a la vez, por lo cual la tarea que se encarga de establecer la cone-xión con el servidor y enviar los paquetes pendientes, tendría que consultar cada1 segundo el estado del módulo GPS. Se trabajó en esto pero no se pudo obteneruna tarea estable y que funcione correctamente.
1http://simcom.ee/modules/gsm-gprs-gps/sim908/
10 Capítulo 3. Diseño e Implementación
Finalmente se tomó la decisión, de conectar el módulo GPS la UART 2, la cualestaba asignada al red modbus. Se realizó una tarea que envía los comandos ATnecesarios para encender y configurar el módulo GPS y una tarea que escucha laUART2 y detecta los paquetes GPGGA y GPRMC.
La ventaja de esta solución es que se podría utilizar dos módulos independientesen una segunda etapa y no estar atados a utilizar un módulo dual.
Al tomar esta decisión, no se cumplirán con los requerimientos 4.a y 4.b asocia-dos a la red MODBUS. Se debe pensar en una segunda etapa del proyecto comoimplementar una solución para que se pueda cumplir con estos requerimientos.
En la figura 3.4 se ilustra el circuito esquemático.
FIGURA 3.4: Circuito esquemático de las conexiones entre la EDU-CIAA y el módulo SIM908
3.2. Firmware
3.2.1. Arquitectura de firmware
Para el desarrollo del firmware se utilizó el modelo de ciclo de vida en V, el cualse puede observar en la figura 3.5. Se eligió este modelo ya que permite una re-alimentación temprana, los procedimientos de prueba se fueron escribiendo enlas etapas de diseño y aplicados a medida que se iba implementando el softwa-re. Esto me permitió la realización de los diferentes ensayos y correcciones sinnecesidad de esperar a tener el prototipo final.
Para el desarrollo se utilizó el Firmware de la EDU-CIAA el cual implementa lossiguientes estándares:
El estándar OSEK-OS como RTOS (Sistema Operativo de Tiempo Real).
El estándar POSIX, que describe un conjunto de interfaces de aplicaciónadaptables a una gran variedad de implementaciones de sistemas operati-vos. El POSIX de la CIAA es un POSIX Like.
3.2. Firmware 11
FIGURA 3.5: Ciclo de vida modelo en V
Se creó un repositorio público 2 en GitHub para el control de versiones del pro-yecto.
3.2.2. Protocolos de comunicación
Comandos AT
Para controlar el funcionamiento del módulo SIM908 se utilizan comandos AT. Elfabricante dispone de un Manual de comandos AT3 que incluye una guía con todoslos comandos AT necesarios para controlar el módulo.
TABLA 3.1: Comandos AT
Comando Descripción
AT+CGATT Estado de la conexión a la red GPRSAT+CSTT=”APN”,”usuario”,”contraseña” Configura APN,usuario y contraseñaAT+CIPSTART=”TCP”,”dir.IP”,”puerto” Configura tipo de conexión, dirección IP y puertoAT+CIPSEND Preparamos el envío de datosAT+CIPSHUT Cierra el contexto PDP del GPRSAT+CIICR Activamos el perfil de datos inalámbricoAT+CIFSR Obtiene dirección de IPAT+CGPSPWR=1 Activar el GPSAT+CGPSIPR Configura velocidad del puerto serie del GPSAT+CGPSOUT Obtener los datos del GPS en formato NMEAAT+CGPSRST Resetea y reinicia GPS
En la tabla 3.1 se ilustra un resumen de los comandos AT utilizados en el sistema.
2https://github.com/Gustavohll/TesisEmbebidos3http://simcom.ee/documents/SIM900/SIM900_AT%20Command%20Manual_V1.11.pdf
12 Capítulo 3. Diseño e Implementación
Protocolo UDP
User Datagram Protocol (UDP) es un protocolo del nivel de transporte basado enel intercambio de datagramas. Permite el envío de dichos datagramas a través dela red sin que se haya establecido previamente una conexión, ya que el propiodatagrama incorpora suficiente información de direccionamiento en su cabecera.Tampoco tiene confirmación ni control de flujo, por lo que los paquetes puedenadelantarse unos a otros; y tampoco se sabe si ha llegado correctamente, ya queno hay confirmación de entrega o recepción.
Su uso principal es para protocolos como DHCP, BOOTP, DNS y demás protoco-los en los que el intercambio de paquetes de la conexión/desconexión son mayo-res, o no son rentables con respecto a la información transmitida, así como parala transmisión de audio y vídeo en tiempo real, donde no es posible realizar re-transmisiones por los estrictos requisitos de retardo que se tiene en estos casos.
Las principales características técnicas del protocolo UDP son:
Es un protocolo mínimo de nivel de transporte orientado a mensajes (data-gramas) documentado en el RFC 768 de la IETF.
Proporciona una sencilla interfaz entre la capa de red y la capa de aplica-ción.
No otorga garantías para la entrega de sus mensajes.
Se utiliza, por ejemplo, cuando se necesita transmitir voz o vídeo y resultamás importante transmitir con velocidad que garantizar el hecho de quelleguen absolutamente todos los bytes.
Uno de los requisitos del proyecto es utilizar protocolo UDP, esto se debe a que laaplicación web está preparada para recibir información en este protocolo y utilizael protocolo TCP. La mayoría de los equipos AVL utilizan este protocolo, ya queenvían paquetes pequeños cada 1 minuto o más tiempo entre envíos.
Para asegurarse que el mensaje llegó a destino se implementa el envío del ACKdesde el servidor hacia el dispositivo. También la aplicación está preparada paraverificar la integridad de los datos con un Checksum, pero este requerimiento noestá incluido en esta primer etapa de diseño.
Especificación NMEA
La NMEA (National Marine Electronics Association) ha desarrollado una especifica-ción que define la interfaz entre equipos electrónicos marinos. La norma permiteque la electrónica marina envíe información a las computadoras ya otros equiposmarinos.
La comunicación del receptor GPS se define dentro de esta especificación. La ma-yoría de los programas informáticos que proporcionan información de posiciónen tiempo real esperan que los datos estén en formato NMEA. Estos datos in-cluyen la solución completa PVT (posición, velocidad, tiempo) calculada por elreceptor GPS.
La idea de NMEA es enviar una línea de datos llamada oración que es totalmenteindependiente de otras oraciones. Todas las oraciones estándar tienen un prefijo
3.2. Firmware 13
de dos letras que define el dispositivo que usa ese tipo de oración. Para los re-ceptores de gps el prefijo es GP y es seguido por una secuencia de tres letras quedefine el contenido de la oración.
Cada oración comienza con ’$’ y termina con una secuencia de retorno de carroy avance de línea y no puede tener más de 80 caracteres de texto visible (más losterminadores de línea). Los datos están contenidos en esta única línea con ele-mentos de datos separados por comas. Los datos en sí son sólo texto ascii y pue-den extenderse sobre varias oraciones en ciertas instancias especializadas, peronormalmente están contenidos en una oración de longitud variable.
Los datos pueden variar en la cantidad de precisión contenida en el mensaje, porejemplo, el tiempo puede ser indicado en partes decimales de un segundo o laubicación puede mostrarse con 3 o incluso 4 dígitos después del punto decimal.Los programas que leen los datos sólo deben utilizar las comas para determinarlos límites del campo y no dependen de las posiciones de las columnas.
Hay una disposición para una suma de comprobación al final de cada frase quepuede o no puede ser verificada por la unidad que lee los datos. El campo check-sum consta de un ’*’ y dos dígitos hexadecimales que representan un OR exclusi-vo de 8 bits de todos los caracteres entre, pero sin incluir, ’$’ y ’*’.
TABLA 3.2: Mensaje GPGGA en formato NMEA
Name Example Description
Message ID $GPGGA GGA protocol headerUTC Time 2153.000 hhmmss.sssLatitude 3342.6618 ddmm.mmmmmmN/S Indicator N N=north or S=southLongitude 11751.3858 dddmm.mmmmmmE/W Indicator W E=east or W=westPosition Fix Indicator 1Satellites Used 10 Range 0 to 12HDOP 1.2 Horizontal Dilution of PrecisionMSL Altitude 27.0 metersUnits M metersGeoid Separation -34.2 Geoid-to-ellipsoid separation(meters)
Ellipsoid altitude = MSL Altitude+ Geoid Separation
Units M metersAge of Diff. Corr. Null fields when DGPS is not usedDiff. Ref. Station ID 0000Checksum *5E<CR><LF> End of message termination
En las tablas 3.2 y 3.3 se ilustran los mensajes utilizados en el sistema, para obte-ner los datos del módulo GPS.
Del mensaje GPGGA obtenemos los datos de la hora, minutos, segundos, longitudy latitud. Del mensaje GPGRC obtenemos el dato de la fecha y del estado de laposición.
14 Capítulo 3. Diseño e Implementación
TABLA 3.3: Mensaje GPRMC en formato NMEA
Name Example Description
Message ID $GPRMC RMC protocol headerUTC Time 161229.5 hhmmss.sssStatus A A=data valid or V=data not validLatitude 3723.248 ddmm.mmmmmmN/S Indicator N N=north or S=southLongitude 12158.34 dddmm.mmmmmmE/W Indicator W E=east or W=westSpeed Over Ground 0.13 knotsCourse Over Ground 309.62 degrees,TRUEDate 120598 ddmmyyMagnetic Variation E=east or W=westEast/West Indicator E E=eastMode A A=Autonomous,D=DGPS,E=DR,
N = Output Data Not Valid,R = Coarse Position
Checksum *10<CR><LF> End of message termination
3.3. Diseño en detalle
Se crearon las siguientes tareas en el sistema operativo OSEK:
Tarea Digital In: Verifica el estado de las entradas digitales cada 500 ms. Ge-nera un evento y lo guarda en la cola cada vez que detecta un cambio deestado en alguna de las entradas. Al finalizar activa la Tarea Analog In.
Tarea Analog In: Verifica el estado de las entradas analógicas cada 500 ms, seejecuta luego de la tarea Digital In. Genera un evento y lo guarda en la colacada vez que detecta un cambio de estado.
Tarea GPS: Se ejecuta solo una vez a los 15 segundos y envía los comandosAT necesarios para encender el módulo GPS. Al finalizar activa la TareaGSM.
Tarea GSM: Envía los comandos AT necesarios para establecer la conexióncon el servidor. Si hay información en la cola, arma los paquetes y los en-vía al servidor. Espera el ack del servidor que corresponde a cada paqueteenviado. Luego queda en espera hasta que haya algún evento por enviar.
Tarea comunicación: Se ejecuta cada 1 minuto, generar evento y lo guarda enla cola de envíos.
Tarea Leds: Según el estado de los módulos GPS y GSM controla el estado delos leds rojo y verde. Se ejecuta cada 500 ms.
Tarea Serial GSM: Escucha la UART GSM, busca patrones de respuesta delmódulo gsm. Cuando detecta una respuesta genera un Evento.
3.3. Diseño en detalle 15
Tarea serial gps: Escucha la UART GPS, busca patrones de comandos envia-dos por el módulo gps. Cuando detecta un comando actualiza las variablesfecha, hora, latitud, longitud, etc.
Como se mencionó anteriormente, un módulo GSM se administra por medio decomandos AT, lo cual implica enviar un comando y esperar la recepción de unarespuesta. El esquema obedece a un simple modelo del tipo cliente-servidor, enel cual el módulo externo o dispositivo se comporta como servidor de comandos,procesando las solicitudes y enviando en consecuencia el resultado obtenido alcliente conectado.
En este caso, el cliente es aquel que envía el comando y espera indefectiblementeuna respuesta como resultado. De forma tal, que una próxima solicitud deberáesperar la respuesta del comando previo, ya que los módulos GSM tradicionalesno permiten recibir un comando mientras se encuentre en procesamiento, por lotanto, desde el punto de vista del cliente, la respuesta implica que el módulo estánuevamente listo para recibir comandos. Si así no fuera, puede que el comandose descarte o bien el procesamiento en curso se aborte.
Otra de las problemáticas surge con las respuestas no solicitadas o URC (Unso-licited Result Code), las cuales las envía el módulo externo ante la ocurrencia deun evento determinado, sin necesidad de comandos previos.
La solución propuesta fue realizar dos tareas para controlar el módulo GSM, laprimera se encargará de recibir respuestas del módulo y despachar eventos encaso que sea una respuesta, un comando o un error, y la segunda será la encar-gada de enviar los comandos AT hacia el módulo GSM cuando la aplicación lorequiera.
Por lo tanto la Tarea Serial GSM procesará las respuestas provenientes del móduloGSM, y enviará un evento de respuesta recibida cuando reciba una respuesta quecoincida con alguna respuesta esperada o enviará un evento de error cuando larespuesta no coincida o sea un comando erróneo. Se puede ver en el Algoritmo3.1 parte del código que implementa esta solución.
1 i f ( r e s p u e s t a _ r e c i b i d a ==1)2 {3 e s t a d o _ s e r i a l =ESPERA ;4 i f ( respuesta_ok ==1)5 {6 /∗ Envio evento respuesta c o r r e c t a a l a t a r e a GSM ∗/7 SetEvent ( GsmTask , EVENTOK) ;8 }9 e l s e
10 {11 i f ( respuesta_ok ==2)12 {13 /∗ Envio evento respuesta c o r r e c t a a l a t a r e a GPS ∗/14 SetEvent ( GpsTask , EVENTOKGPS) ;15 } e l s e16 {17 /∗ evento respuesta no esperada ∗/18 SetEvent ( GsmTask , EVENTERROR) ;19 }20 }
ALGORITMO 3.1: Código de la Tarea Serial GSM.
16 Capítulo 3. Diseño e Implementación
Las tareas que envían comandos hacia el módulo GSM, una vez que envían elcomando, quedarán en estado de espera hasta que reciban un evento de respuestarecibida, un evento de error o se cumpla con el tiempo de espera (Time Out). Sepuede ver en el código 3.2 cómo se implementa esta solución.
1 case RED:2 {3
4 ciaaPOSIX wri te ( fd uart gsm , CGATT, ciaaPOSIX s t r l e n (CGATT) ) ;5 /∗ Activo time out de 2 segundos ∗/6 SetRelAlarm ( SetEventTimeOut , 2000 , 0 ) ;7 /∗ La t a r e a queda en estado Wait Event ∗/8 WaitEvent (EVENTOK | EVENTERROR | EVENTTIMEOUT) ;9 GetEvent ( GsmTask , &Events ) ;
10 ClearEvent ( Events ) ;11 /∗ S i l l e g a respuesta c o r r e c t a , paso a l s i g u i e n t e estado ∗/12 i f ( Events & EVENTOK)13 {14 CancelAlarm ( SetEventTimeOut ) ;15 estado_gsm = SET ;16 statusgsm =1;17 }18 /∗ S i l l e g a respuesta i n c o r r e c t a c o r r e c t a , espero 2 segundos y vuelvo a
enviar comando AT ∗/19 i f ( Events & EVENTERROR)20 {21 CancelAlarm ( SetEventTimeOut ) ;22 SetRelAlarm ( SetEventTimeOut , 1000 , 0 ) ;23 WaitEvent (EVENTTIMEOUT) ;24 GetEvent ( GsmTask , &Events ) ;25 ClearEvent ( Events ) ;26 statusgsm =0;27 }28 break ;29 }
ALGORITMO 3.2: Código de la Tarea Serial GSM.
Para poder recibir información del módulo GPS, se configuraron los pines GPIO1y GPIO2 de la EDU-CIAA como TX y RX de la UART 0. Para configurar esto semodificaron los siguientes archivos en el firmware de la CIAA:
ciaaDriverUart.c
ciaaDriverDio.h
En el primer archivo se comentaron las funciones que configuran el puerto RS485y se configuró el puerto 6 pin 4 y 5 como UART0, observar Algoritmo 3.3.
En el segundo archivo se comentaron las funciones que definen los pines P6_4 yP6_5 como GPIOs.
1 /∗ UART0 ( RS485/Prof ibus ) ∗/2 Chip_UART_Init (LPC_USART0) ;3 Chip_UART_SetBaud (LPC_USART0 , 115200) ;4
5 Chip_UART_SetupFIFOS (LPC_USART0 , UART_FCR_FIFO_EN | UART_FCR_TRG_LEV0);
6
7 Chip_UART_TXEnable (LPC_USART0) ;8
9 /∗ Configuro UART0 por pines GPIO1 y GPIO2 ( funcion 2) ∗/10 /∗ P6_4 : UART0_TXD ∗/
3.3. Diseño en detalle 17
11 Chip_SCU_PinMux ( 6 , 4 , MD_PDN, FUNC2) ;12 /∗ P6_5 : UART0_RXD ∗/13 Chip_SCU_PinMux ( 6 , 5 , MD_PLN|MD_EZI|MD_ZI, FUNC2) ;14
15 /∗ Se comentan l a s s i g u i e n t e s l i n e a s del codigo ∗/16
17 // Chip_SCU_PinMux ( 9 , 5 , MD_PDN, FUNC7) ;18 // Chip_SCU_PinMux ( 9 , 6 , MD_PLN|MD_EZI|MD_ZI, FUNC7) ;19 // Chip_UART_SetRS485Flags (LPC_USART0 , UART_RS485CTRL_DCTRL_EN |
UART_RS485CTRL_OINV_1) ;20 // Chip_SCU_PinMux ( 6 , 2 , MD_PDN, FUNC2) ;
ALGORITMO 3.3: Configuración UART GPS
19
Capítulo 4
Ensayos y Resultados
En este capítulo se explica cómo se hicieron los ensayos y qué resultados se obtu-vieron.
4.1. Test Unitarios en cada tarea
El plan de pruebas se fue ejecutando a medida que se iban implementando ca-da una de las tareas o funciones. Se probó cada tarea del firmware tratando decubrir la mayor cantidad de código posible. Se realizaron ensayos imprimiendodatos por consola o por la UART USB de la EDU-CIAA con el fin de verificar ydocumentar el funcionamiento.
4.1.1. Ensayo 1 - Prueba de tarea Digital In
Para probar el funcionamiento de la tarea Digital In, se agregó una función en latarea que imprime por la UART USB el estado de las entradas digitales. Se verificóel correcto funcionamiento presionando las teclas de la 1 a la 4 y se observó elcambio de estado de las entradas como se ilustra en la figura 4.1.
FIGURA 4.1: Imagen de la UART-USB al ejecutar el ensayo 1
4.1.2. Ensayo 2 - Prueba de tarea LEDs
Para probar el funcionamiento de la tarea Leds, se verificó visualmente que losleds rojo y verde titilan cuando arranca el sistema y que quedan fijos cuando se
20 Capítulo 4. Ensayos y Resultados
cambia el valor de las variables statusgsm y statusgps. Para esto se agregó un testen la tarea que pone a 1 estas variables luego de 20 ciclos de activación de estatarea. Se hace correr el programa y se verifica el funcionamiento.
1 /∗ TEST_2 : T i t i l o ambos leds 10 veces y luego l o s dejo f i j o s ∗/2
3 # i f d e f Test_LedsTask4 i f ( Periodic_Task_Counter == 20)5 {6 statusgsm =1;7 s ta tusgps =1;8 }9 # endi f
ALGORITMO 4.1: Código del Test en tarea Leds.
4.1.3. Ensayo 3 - Prueba de tarea Adc
Para probar el funcionamiento de la tarea Adc, se agregó una función en la tareaque imprime por la UART USB el valor de las variables AD. Se conectaron las en-tradas ADC1 y ADC3 a VCC y luego a GND, y se verificó el valor de las variablesobservando la salida de la UART USB como se ilustra en la figura 4.2.
FIGURA 4.2: Imagen de la UART USB al ejecutar el ensayo 3.
4.1. Test Unitarios en cada tarea 21
4.1.4. Ensayo 4 - Prueba de Funciones
En la función que arma los paquetes RUS07 y RGP, se agrega un test que insertauna cadena con los comandos de entrada esperados por la función y se imprimepor consola la salida.
1 # i f d e f Test_GSM2 i n t 8 _ t respuesta_gps [ ] = "GPGGA, 0 1 5 0 2 1 2 . 0 0 0 , 0 3 4 4 3 . 0 1 1 8 1 0 , 0 S
, 0 0 5 8 1 8 . 5 9 5 6 8 1 , 0W, 0 1 , 0 5 , 0 3 . 4 4 , 0 0 . 9 8 3 , 0M, 0 1 4 . 4 5 6 , 0M, ,∗5 B" ;3
4 i n t 8 _ t respuesta_gps2 [ ] = "$GPRMC, 1 3 5 0 3 2 . 0 0 0 ,A, 3 4 4 3 . 0 0 5 6 0 6 , S, 0 5 8 1 8 . 5 7 2 0 3 3 ,W, 0 . 0 0 0 , 0 . 0 , 0 1 0 5 1 7 , , ,A∗64 " ;
5 # endi f
ALGORITMO 4.2: Código del Test de funciones.
Se verifica que el formato de salida corresponda al esperado con el servidor. Pa-ra esto utiliza la herramienta web https://regex101.com/, para verificar que elpaquete coincida con el formato esperado por la función PHP. Se ilustran los re-sultados en las figuras 4.3 y 4.4.
FIGURA 4.3: Verificación del armado del paquete RUS07.
FIGURA 4.4: Verificación del armado del paquete RGP.
4.1.5. Ensayo 5 - Prueba de tarea GPS
Se verifica que la tarea GPS envíe los comandos adecuados para encender el mó-dulo GPS. En este ensayo se visualiza por la UART USB los comandos de confi-guración enviados por la tarea GPS al módulo SIM908. Se ilustran los resultadosen la figura 4.5.
4.1.6. Ensayo 6 - Prueba de tarea GSM
Se verifica que la tarea GSM envíe los comandos adecuados para realizar la co-nexión al servidor. En este ensayo se visualiza por la UART USB los comandosde configuración enviados por la tarea GSM al módulo SIM908. Se ilustran losresultados en la figura 4.6.
22 Capítulo 4. Ensayos y Resultados
FIGURA 4.5: Imagen de la UART USB al ejecutar el ensayo 5.
FIGURA 4.6: Imagen de la UART USB al ejecutar el ensayo 6.
4.2. Test funcionales
La idea de estos test es probar que todas las funciones y tareas funcionen en con-junto con el sistema operativo.
4.2.1. Ensayo 1 - Prueba de envio de paquete y ACK
Para este ensayo se imprime por UART USB la comunicación entre la EDU-CIAAy el módulo SIM. Se hace correr el programa y se verifica que el paquete es en-viado y llega el ack correspondiente. Se ilustra el resultado en la figura 4.7.
4.2. Test funcionales 23
FIGURA 4.7: Imagen de UART USB al ejecutar el ensayo 1.
4.2.2. Ensayo 2 - Prueba de posición
Se verifica que el sistema envía una posición correcta, para realizar este ensayo seimprime por UART USB la comunicación entre la EDU-CIAA y el módulo SIM,se verifica que se genere un paquete con fecha y posición, luego se chequea en elsoftware de monitoreo que esa posición se muestre correctamente, se ilustran losresultados en las figuras 4.8 y 4.9.
FIGURA 4.8: Imagen de la UART USB al ejecutar el ensayo 2.
4.2.3. Ensayo 3 - Prueba de eventos
Se verifica que se envíe un paquete al servidor, cuando se cumplen las siguientescondiciones:
Cada vez que cambie una entrada digital.
Cada vez que cambie una entrada analógica.
Cada 1 minuto.
Se verificó realizando un reporte histórico en el software de monitoreo, que cadacondición genero una posición con un número de evento diferente.
4.2.4. Ensayo 4 - Prueba led GSM
Se verificó que el led verde titila cuando la señal de ip no es válida, y queda fijocuando la señal es correcta.
Se chequeo visualizando la salida de la UART USB que imprime el comandoAT+CGATT=?, si este comando es 0 significa que el módulo no tiene señal GPRS
24 Capítulo 4. Ensayos y Resultados
FIGURA 4.9: Imagen de ubicación,fecha y hora reportada en elsoftware de monitoreo.
y se verifica que el led titila, si el valor es 1 el módulo tiene señal GPRS y el ledqueda fijo.
4.2.5. Ensayo 5 - Prueba led GPS
Se verificó que el led rojo titile cuando la señal de GPS no es válida, y queda fijocuando la señal es correcta. Se chequeo visualizando la salida de la UART USBque imprime los paquetes a medida que se envían, se observa el valor de latitudy longitud en el paquete generado.
Mientras estos valores son 0 el led rojo titila, cuando toman un valor distinto de0 se verifica que el led queda fijo.
4.2.6. Ensayo 6 - Prueba de reenvió de posición
En este test se verificó que se reenvía el paquete a los 15 segundos, en caso queno llegue el ACK correspondiente desde el servidor. Se ilustra el resultado en lafigura 4.10.
4.3. Pruebas de campo 25
FIGURA 4.10: Imagen de UART USB en el ensayo 6.
4.3. Pruebas de campo
Se realizaron pruebas de caja negra sobre el sistema, con el objetivo asegurar yvalidar que el producto es operativo.
4.3.1. Ensayo 1
Se forzó pérdida de señal GSM desconectando la antena y se chequeó que el ledverde comienza a titilar. Luego de 15 minutos se volvió a conectar la antena, severificó que el led verde quede fijo y se verificó que el sistema volvió a reportarlos eventos pendientes al sistema de monitoreo.
4.3.2. Ensayo 2
Se forzó pérdida de señal GPS desconectando la antena y se chequeó que el ledrojo comienza a titilar. Se verificó en el sistema de monitoreo que sigan llegan-do reportes ya que no se debería perder la posición ni la hora. Luego de unosminutos se volvió a conectar la antena y se verificó que el led rojo quede fijo.
4.3.3. Ensayo 3
Se probó el sistema durante 3 horas o más. Se verificó que llegan posiciones alsoftware de monitoreo cada 1 minuto y que el sistema sigue funcionando sinningún error.
26 Capítulo 4. Ensayos y Resultados
4.3.4. Ensayo 4
Se probaron las de entradas digitales presionado todas las teclas y se verificandoque llegan los eventos correspondientes al software de monitoreo.
4.3.5. Ensayo 5
Se probaron las entradas analógicas, modificando su valor y se verificando quellegan los eventos correspondientes al software de monitoreo.
27
Capítulo 5
Conclusiones
En esta sección se detallan cuáles son los principales aportes del trabajo realizadoy cómo se podría continuar.
5.1. Conclusiones generales
Los resultados del proyecto fueron satisfactorios y se cumplió el objetivo, ya queeste primer prototipo funcional servirá como base para futuros desarrollos. Tam-bién me permitió aprender y poner en práctica muchos de los conocimientos ad-quiridos durante la carrera y tener una experiencia en desarrollo de sistemas em-bebidos.
Para la realización del proyecto se aplicaron los conocimientos aprendidos du-rante la carrera de especialización en sistemas embebidos, principalmente de lassiguientes asignaturas:
Fundamentos de sistemas embebidos: En la misma se aprendió la arquitec-tura del microcontrolador utilizado en la EDU-CIAA, utilización de diagra-mas y máquinas de estados.
Ingeniería de software en sistemas embebidos: se aplicaron los conocimien-tos adquiridos para implementar un software más ordenado, respetandolas etapas de diseño y análisis del mismo, se utilizó un repositorio GIT paraguardar el proyecto.
Gestión de Proyectos en Ingeniería: Se logró gestionar el proyecto, pasandopor las distintas etapas y dejando una buena documentación de los distintospasos realizados.
Sistemas Operativos de Tiempo Real: Se utilizó todo lo practicado en la asig-natura, ya que el programa principal utiliza un sistemas operativos de tiem-po real.
5.2. Próximos pasos
El proyecto se debe probar en campo y en caso de tener buena aceptación en laempresa y se buscará mejorar o aplicar en una segunda etapa. A continuación sedetallan las mejoras a realizar en una próxima etapa:
28 Capítulo 5. Conclusiones
Diseño de una placa de expansión que incluya el módulo GSM/GPRS, yque saque por borneras todas las entradas y salidas de la EDU-CIAA.
Reemplazar el módulo GSM por uno con conectividad 3G.
Agregar el requerimiento faltante, para obtener datos de sensores que utili-cen protocolo Modbus.
Agregar control de salidas digitales a través de comandos enviados por elsoftware de monitoreo.
Incluir un Checksum en el envió de paquetes para que la aplicación puedaverificar la integridad de los datos recibidos.
29
Bibliografía
[1] Computadora Industrial Abierta Argentina CIAA.URL=http://www.proyecto-ciaa.com.ar/devwiki/doku.php?id=start
[2] Ing. Eric Pernia. EDU-CIAA-NXP Pin Out.URL=http://www.proyecto-ciaa.com.ar/devwiki/lib/exe/fetch.php?media=desarrollo:edu-ciaa:edu-ciaa-nxp_pinout_a4_v4r0_es.pdf
[3] Leandro Francucci.Administración de módulos GSM en sistemas reactivos.Diciembre 12, 2012. URL=http://embedded-exploited.blogspot.com.ar/2012/12/administracion-de-modulos-gsm-en.html
[4] Ing. Mariano Cerdeiro.Introducción a OSEK-OS - El Sistema Operativo delCIAA-Firmware. URL=http://www.proyecto-ciaa.com.ar/devwiki/lib/exe/fetch.php?media=desarrollo:firmware:rtos:introduccion_a_osek-os.pdf
[5] Ing. Gustavo Alessandrini, Ing. Alejandro Permingeat, Ing. PaolaPezoimburu. Introducción - Ciclos de vida. Apuntes de clase Ingeniería deSoftware. CESE.URL:https://sites.google.com/site/ingdesoftenembebidos/.
