Sistema de Telemetría Embebido por PPP

Transcripción

1 Sistema de Telemetría Embebido por PPP Martín I. del Barco, Juan S. Martina Diego R. Dujovne y Ricardo Taborda Universidad Nacional de Córdoba mdelbarco@efn.uncor.edu, sebasuo@yahoo.com Laboratorios LIADE y DSP, Dpto. Electrónica, F.C.E.F.y N., Universidad Nacional Córdoba liade@efn.uncor.edu y labdsp@efn.uncor.edu Resumen La integración de la Internet-enabling technology en los dispositivos electrónicos tanto nuevos como existentes sumados a los avances en la telefonía celular como canal de comunicaciones inalámbrico, impulsan a su uso en Telemetría. Teniendo en cuenta esto, el presente trabajo se basó en la utilización de un microcontrolador de 8 bits para la implementación de un sistema embebido de comunicación sobre Internet. Este permite acceder a la red mediante módulos de telefonía celular de tecnología GPRS con un bajo costo y capacidad de procesamiento suficiente para aplicaciones con poco volumen de datos. Palabras Clave Telemetría, Comunicación de datos inalámbrica, Internet, Sistemas embebidos. I. INTRODUCCIÓN El deseo de conectar todo dispositivo a Internet enfoca el desafío de la reducción de precio de la interfaz con la red de redes como un importante factor de diseño. La meta primaria es encontrar la performance necesaria al mínimo costo. Otras dos características claves en aplicaciones embebidas son la necesidad de minimizar la memoria y el consumo de energía. En muchas aplicaciones embebidas la memoria es una parte sustancial en el costo del sistema, por lo tanto es importante optimizarla en tales casos. Grandes memorias significan mayor energía y la optimización de la energía es crítica en este tipo de aplicaciones. Mas allá del énfasis en el bajo consumo de energía para el uso de baterías, se puede mencionar también la necesidad de encapsulados más baratos (plástico vs. cerámicos). Para aplicaciones de bajo costo que manejan pequeñas cantidades de datos, una opción es la utilización de un microcontrolador de 8 bits. Así los beneficios a obtener son amplios. Se visualiza la posibilidad de agregar o modificar características o parámetros a un producto a distancia, realizar manejo de dispositivo y diagnóstico remoto, integrar una interfaz de navegador interactiva e intuitiva a un dispositivo electrónico, monitorear el estado de sensores conectados al sistema desde su casa u oficina con cualquier PC conectada a Internet, entre otras aplicaciones. Esta última funcionalidad es la que da origen a este trabajo, como bien su nombre lo destaca: Sistema de Telemetría o sea de medición a distancia. De esta manera se pueden citar una gran cantidad de campos utilización, entre los que podemos mencionar: Seguridad Seguimiento de Mercancías Domótica Electrodomésticos Monitoreo de Variables Meteorológicas, etc. Sin embargo, para la mayoría de los dispositivos electrónicos, implementar la tecnología para lograr esta conectividad basada en estándares abiertos de Internet no es una tarea fácil. Por ejemplo, la mayoría de los electrodomésticos están basados en microcontroladores de 8-bits (muy económicos), en los cuales generalmente el microprocesador anfitrión no incluye un puerto hacia la red, recursos de hardware para apoyar TCP/IP (Transmisión Control Protocol/ Internet Protocol) u otros protocolos de Internet, sin afectar su función principal. Llevar a cabo una pila o stack completo de comunicación de Internet requiere una considerable cantidad de memoria y recursos de procesamiento en un sistema basado en un microcontrolador. En la mayoría de los casos, agregar esos recursos al sistema supera el costo y viabilidad de la razón principal por el que fue creado. Por lo tanto, diferentes técnicas para los dispositivos Web-enabled se han concebido recientemente: aplicaciones de funcionalidad limitada de TCP/IP en sistemas de recursos limitados, pilas de single-chip, a servidores de dispositivo objeto. Cada método tiene sus propias ventajas y desventajas. Por otra parte, el uso de la red celular como enlace inalámbrico trae aparejado varias ventajas, entre las que podemos citar: El aprovechamiento de capacidad instalada. Una mayor confiabilidad en la transmisión de datos mediante estos sistemas celulares con respecto a otros sistemas custom. Cobertura amplia y enlace de radiofrecuencia standard.

2 Costo medio en relación con otras tecnologías y muy bajo teniendo en cuenta el alcance obtenido. Soporte tecnológico Versatilidad Tamaño Autonomía. Dentro de la utilización de los recursos de telefonía celular se optó por el uso del sistema GPRS (General Packet Radio Service). Este está dirigido a aplicaciones donde la transmisión de datos es poco frecuente y en pequeñas cantidades (Seurre et. al.,2003). Dicho sistema presenta ciertas ventajas para el usuario tales como: Always connected (Siempre conectado) Tarifación por volumen de datos transferidos en lugar de por tiempo. Costo nulo de establecimiento de conexión frente a GSM. Mayor velocidad de Transmisión (gracias a la asignación dinámica de canales, como a la utilización de un sistema de codificación que permite mayores velocidades) Además le permite a la prestadora del servicio un manejo más eficiente de la red, ya que los usuarios solo ocupan sus recursos durante la transmisión o recepción de datos. A. Implementación II. DESARROLLO Hardware: El stack de comunicaciones se embebió en un microcontrolador de 8 bits de la familia HC08 de Motorola. Dicho dispositivo, el MC68HC908AZ60, fue elegido debido a que sus características de memoria (60K Flash y 2k de RAM), de velocidad (8Mhz de frecuencia máxima de bus) y costo lo hacían óptimo para el desarrollo del stack. Se comenzó por realizar una placa de evaluación en conjunto con una de interfaz. Esta última permite recolectar datos de variables físicas reales, tales como temperatura y posición, visualizar el estado del dispositivo y realizar la conexión con el módem. Como la Fig.1 indica, el sistema de telemetría dispone de: Sensores: Recolectan datos de temperatura y posición. Interfaz Sensores Microcontrolador: utilizada para adecuar las señales de los sensores a las entradas del ADC del microcontrolador. Microcontrolador: Es el encargado de adecuar los datos enviados por los sensores al formato de Internet (PPP/IP/UDP) Interfaz de visualización: permite visualizar el estado del dispositivo (en línea, realizando negociación para la conexión, etc.) Interfaz Microcontrolador-Módem: acondiciona las señales provenientes del microcontrolador a niveles RS- 232 que son los manejados por módems standard. Software: La función principal del software es la de un stack de comunicación de Internet (Stevens, W.R., 1994) que permite a un microcontrolador de pocos recursos y de bajo costo conectarse a la red de redes con una funcionalidad limitada de TCP/IP. Con funcionalidad limitada nos referimos a que solo se implementaron funciones de los protocolos que son útiles a la presente aplicación. Estas funciones serán detalladas más adelante. Este limitado stack nos permite transmitir información o datos de dispositivos conectados en los puertos del microcontrolador tales como: sensores con salida analógica sensores con salida digital memorias seriales. etc. Procesar las señales provenientes de estos, y luego enviarlas a través Internet. Sistema del AZ60 (1)Establece un enlace PPP I P/ICPM RESPUESTAS Y DEMANDAS DE PING (2) Mensages PPP/ INT ERNET ISP OTROS HOST SOBRE INTERNET Modem Externo d e telefo n ía fija o de telefon ía m óvil INT E RFA C E SENSORES - IN T ER FAC E - MODEM SENSORES TEMP: 27 C Displays INT E RFA C E - HOMBRE Fig.1 Fig.2 En la Fig.2 se muestra la idea expuesta anteriormente. El sistema se conecta a un proveedor de servicios de Internet por medio de un módem telefónico externo utilizando una red pública de telefonía (fija o móvil). Un host también conectado a Internet podrá tanto requerir como recibir los datos del sistema de telemetría para su posterior procesamiento, así como

3 configurar parámetros de la aplicación que realiza el microcontrolador. El stack fue desarrollado siguiendo los lineamientos de la programación estructurada (Deitel, H.M, P.J., Deitel, 1998). El código se dividió en diferentes módulos (Trenado, R, 2001 y Loewen, M., 1999), donde cada uno de ellos se encarga de las distintas capas del modelo de referencia de Internet. Los protocolos utilizados en cada una de estas capas, como se observan en la Fig.3, se listan a continuación: enviarse datagramas de cada protocolo de la capa de red sobre el enlace. El enlace permanecerá configurado para las comunicaciones hasta que paquetes explícitos LCP o de NCP cierren el enlace, o hasta que algún evento externo ocurra (un cronómetro de inactividad expira o la intervención del administrador de red). En el proceso de configurar, mantener y terminar el enlace de punto a punto, se pasa por varias fases distintas que se especifican en la Fig.4. Capas del modelo TCP/IP Protocolos a utilizar UP OPENED DEAD ESTABLISH AUTHENTICATION SUCCESS/ NOT APLICACION Aplicación corriendo sobre el microcontrolador Software FAIL FAIL TRANSPORTE UDP DOWN TERMINATE CLOSING NETWORK RED ENLACE DE DATOS FISICA ICMP IP PPP SERIAL Firmware Hardware Fig.4 A continuación, en la Fig.5 se presenta en forma breve la máquina de estados implementada para realizar la negociación de los parámetros de configuración del enlace PPP. Fig.3 Capa física: se realiza mediante comunicación serie asíncrona, a través de puerto SCI del microcontrolador utilizando el protocolo RS-232. (Campbell, J., 1994). Capa de enlace de datos: Este es el núcleo del desarrollo, ya que la finalidad principal es implementar el Protocolo Punto a Punto, ampliamente usado en conexiones Dial-up. El protocolo Punto-a-Punto (PPP) provee un método estándar para transportar datagramas de diferentes protocolos sobre un enlace punto-a-punto. PPP consiste en tres componentes principales: 1. Un método para encapsular datagramas de diferentes protocolos. 2. Un protocolo de control de enlace (LCP) para establecer, configurar, y testear la conexión de datos. 3. Una familia de protocolos de control de redes (NCPs) para establecer y configurar diferentes protocolos de capas de red. PPP fue diseñado para enlaces simples que transporten paquetes entre pares. Este enlace proporciona operación bi-direccional full-dúplex, y los paquetes se envían en orden (Simpson, W., 1994). Para establecer la comunicación sobre un enlace punto a punto, cada extremo del enlace debe enviar primero los paquetes de LCP para configurar y probar el enlace de datos. Después de que el enlace se ha establecido, un par debe autenticarse dependiendo de lo que se haya negociado en la etapa anterior. Entonces, el PPP debe enviar los paquetes de NCP para escoger y configurar uno o más protocolos de la capa de red. Una vez que cada uno de los protocolos de la capa de red escogidos se ha configurado, pueden REQ INCLUYE PROTOCOLO DE AUTENTICACIÓN NAK todas las opciones, menos la opción 3 ISP VUELVE A REQUERIR REQ DEL ISP CO N OPCION ACK DE LCP El ISP requiere paquetes de configuración Nego ciacio nes LCP desd e el ISP NAK, pide por PAP ACK PAP, pedir REQ con CHAR MAP 0xFF ENVIAR USERID Y CONTRASEÑA REQ DEL ISP CON OPCION ACK DE PAP, Y IPCP REQUIRE DIRECCION DE IP RECONOCIMIENTO DE DIRECCION DE IP (IPCP) NAK DEL ISP A LA OPCION DE CHAR MAP REQ NO INCLUYE PROTOCOLO DE AUTENTICACIÓN NAK todas las opciones de REQ NAK DE LOG-IN Rechazar todos los protocolos que no sean LCP, PAP, IPC, o IP Fig.5 Capa de red: En esta capa se implementaron algunas funcionalidades de IP (Postel, J., 1981 a), como así también de ICMP (Postel, J., 1981 b). Capa de transporte: Se utilizó el protocolo de datagrama de usuario (UDP) (Postel, J., 1980) el cual presenta una serie de ventajas frente a TCP: No necesita que se mantenga la conexión. No tiene el costo adicional del acuse de recibo de los paquetes por parte del destinatario (o la

4 retransmisión automática cuando los paquetes no llegan adecuadamente) Está diseñado para mensajes cortos de control y de aplicaciones. En una base de paquete a paquete necesita menos ancho de banda de red que TCP. Como así también desventajas: La aplicación debe encargarse en su código de detectar los errores de transmisión y retransmisión (si así lo requiere). Los paquetes grandes deben ser divididos. La razón para elegir UDP es que la aplicación a realizar envía mensajes de estado periódicos de poca importancia o que se repiten regularmente (como por ejemplo una estación meteorológica que envía datos cada, por ejemplo, 1 seg.), de manera que si se pierde una actualización, la próxima seguirá en muy poco tiempo. En este tipo de aplicación, cada elemento de datos transmitido sería razonablemente pequeño, no un archivo de imágenes tomado de un servidor web (Wall, K, 2001). Capa de aplicación: las tareas implementadas en este módulo fueron realizadas para demostrar las diferentes formas de comunicación que el dispositivo puede utilizar. Estas se dividen en: Tareas periódicas: envían datos de los sensores cada determinado lapso de tiempo, Asíncronas: comandadas por el ADC (envío de mensajes de alerta cuando una variable sobrepasa cierto valor de referencia) o por el puerto SCI (requerimiento de información desde el host remoto). B. Pruebas realizadas sobre el dispositivo: El dispositivo fue probado con tres tipos de servidores distintos para probar el comportamiento del stack implementado frente a diferentes plataformas. En primera instancia, se utilizó para la prueba y depuración del software y del hardware un servidor linux en una PC Pentium 233 MMX conectada a una central telefónica PANASONIC 308 EASA-PHONE que simulaba el circuito de conmutación de la red telefónica pública. Tal como muestra la Fig.6, se observa un esquema con la disposición de los elementos antes mencionados. Una vez depurado el stack se procedió a conectar el sistema a Internet a través de un ISP gratuito, mediante la red de telefonía pública fija. De esta manera se comprobó que el dispositivo era capaz de realizar la negociación con cualquier Proveedor de Servicios de Internet. En última instancia, se estableció el enlace PPP a Internet a través de la red celular de CTIMóvil. Para esto se hizo uso de un módem celular GM48 de Sony- Ericsson utilizando el sistema GPRS. La Fig.7 presenta un esquema con los elementos utilizados para la prueba. Fig.7 Para poder realizar la negociación usando los módems GPRS, se tuvieron que implementar algunos cambios en el código. Unos relacionados con los comandos de inicialización del módem. Y otros vinculados a la negociación PPP: debió modificarse ligeramente la máquina de estados de la negociación PPP debido a que el servidor GPRS no inicia la transacción de los paquetes de configuración (ni los de control de enlace LCP- ni los de control de red -IPCP). Por consiguiente se debió agregar las correspondientes rutinas de inicialización. Los programas utilizados para la recolección de los datos en el host remoto fueron desarrollados en LabView7.0. En la Fig.8 se muestra la interfaz de uno de ellos que permite observar el comportamiento de las variables trasmitidas. Fig.6 Para la lectura de los datos enviados se utilizaron en este caso programas desarrollados en C para Linux, utilizando las herramientas de programación en sockets (Wall, K, 2000). Fig.8 Además en los tres casos para probar que efectivamente el dispositivo estaba en línea, se realizaron requerimientos de ping con el mismo desde diferentes host en la red a la cual se encontraba

5 conectado. Es de destacar que se observó aquí un RTT (Round Trip Time) de entre 2 a 3 segundos al usar los módems GPRS entre los mensajes enviados y su recepción en el host destino (Meyer, M, 1999). La velocidad de transferencia de datos no superó los bps debido a las limitaciones en la velocidad de procesamiento del microcontrolador. III. CONCLUSIONES En este trabajo hemos implementado una solución al problema planteado en principio de comunicar un microcontrolador de 8-bits a través de Internet. Para ello se analizaron códigos fuentes desarrollados con anterioridad para otros microcontroladores de 8-bits. Estos fueron adaptados y corregidos al AZ60A. La elección de este microcontrolador de 8-bits de Motorola nos introdujo en la programación de lenguaje C embebido, el cual permite programar más rápidamente, dándonos la capacidad de trabajar en programación estructurada. Además posibilita especificar cada detalle en términos de hardware, y al mismo tiempo da la habilidad de ocultar los detalles de la arquitectura. Esta última característica facilita un mayor nivel de abstracción y poder pensar en términos del problema. La implementación de este stack mostró las ventajas de encarar las comunicaciones en un modelo de capas. Como cada una se ocupa de distintas funciones en el proceso de comunicación, esto permite abstraer los aspectos relativos a su implementación por separado, siendo independientes una de otras. Si bien en un principio el stack fue probado y depurado sobre módems de telefonía fija, muy pocos detalles tuvieron que ser cambiados para utilizarlo sobre módems de tecnología GPRS. Quedando una vez más en evidencia las ventajas de trabajar con un modelo de capas. El uso de protocolos de Internet en telemetría nos da la posibilidad de acceder al dispositivo desde cualquier rincón del planeta, procesando los datos que envía en una computadora conectada a la red, en forma independiente del sistema operativo. Así cualquier dispositivo capaz de generar datos, tal es el caso de instrumentos usados en telemetría o tele alarma, puede conectarse a Internet mediante este sistema. Realizando un análisis de costos debemos destacar que la implementación resulta considerablemente más económica que el uso de una PC para la transmisión de volúmenes pequeños de datos. El costo de hardware para establecer la comunicación con el módem no supera los $ 250. De más esta aclarar los beneficios que resultan de la reducción en el tamaño del dispositivo empleado y de la posibilidad de independizarse de la red de distribución eléctrica. Cabe acotar que este trabajo podría mejorarse agregando las funcionalidades de TCP que permitiría tener un mejor control del enlace, resolución de nombres, etc. En lo que respecta al hardware, una aplicación específica emplearía uno más compacto y económico. No todos los puertos estarían en uso, y se podría usar un microprocesador con menores recursos: el código para implementar el stack de comunicaciones no supera los 6 KBytes de memoria Flash y la cantidad de RAM utilizada no es mayor a 300 Bytes. REFERENCIAS Campbell, J., C Programmer s guide to serial communications, 2 da edición, Sams (1994). Deitel, H.M, P.J., Deitel, Como programar C++, Prentice Hall (1999). Loewen, M., Using PIC Micro MCUs to connect to internet via PPP, AN724, MICROCHIP TECHNOLOGY INC. (1999) Meyer, M, TCP Performance over GPRS, In Proc. of IEEE WCNC, (1999). Postel, J., User Datagram Protocol, RFC 768 (Aug- 1980). Postel, J., Internet Protocol, RFC 791 (Sep-1981 a) Postel, J., Internet Control Message Protocol, RFC 792 (Sep-1981 b) Seurre, E., P. Savelli y J.P. Pietri, GPRS for Movile Internet, Artech House (2003) Simpson, W., The Point-to-Point Protocol(PPP), RFC 1661 (July 1994) Stevens, W.R., TCP/IP Illustrated, Vol. 1, Addison Wesley (1994). Trenado, R., Conecting an M68HC08 Family Microcontroler to an Internet Service Provider (ISP) using the point-to-point Protocol (PPP), AN2120, MOTOROLA INC (2001) Wall, K., Programación en Linux al descubierto, 2 da edición, Prentice Hall (2001). Wall, K., Programación en Linux con ejemplos, Prentice Hall (2000). AGRADECIMIENTOS Los autores expresan su agradecimiento por el apoyo financiero recibido a través de un subsidio 2004 de la Secretaría de Ciencia y Tecnología de la Universidad Nacional de Córdoba a para la realización del proyecto Sistema de telemetría a través de cobertura celular en el cual se enmarca este trabajo.