Caso práctico basado en FPGAs y Sistemas de - IEEE-RITA
Anuncio
IEEE-RITA Vol. 2, Núm. 2, Nov. 2007 79 Caso práctico basado en FPGAs y Sistemas de Telefonía Móvil para la Docencia en la Titulación de Ingeniería Telemática Juan Suardíaz Muro, Member, IEEE, y Basil M. Al-Hadithi Tittle—Practical case based on FPGAs and Mobile Communication Systems for Teaching in a Telematics Engineering Career. Abstract— When teaching using FPGAs (Field Programmable Gate Arrays), it is recommended to focus, if it were possible, the great amount of practical case studies and examples to the specific domain of the career that includes the taught subject. This paper describes the development of a mobile communication based control system that covers the main knowledge required in a telematics engineering discipline. It uses the main theoretical concepts discussed in weekly lectures. Index Terms— Mobile Communication Networks, Electronic Control, FPGAs, Architectures Systems, GSM Reconfigurable Dependiendo del tipo de aplicación, es posible hacer una distinción entre módulos y terminales. Mientras que los denominados ‘módulos’ permiten integrarse completamente en una determinada solución, los ‘terminales’ constituyen unidades independientes que es posible añadir al sistema mediante unos conectores e interfaces estandarizados, permitiendo así la creación de redes inalámbricas tipo ‘plug and play’ de una manera muy sencilla. Los terminales GSM están subdivididos en cinco clases basándose en la máxima potencia con la que pueden transmitir sobre el canal radio, que varía desde un máximo de 20W a un mínimo de 0.8W. La siguiente tabla (Tabla I) resume las características de estas cinco clases: TABLA I CLASIFICACIÓN DE LOS TERMINALES MÓVILES I. INTRODUCCIÓN L os terminales inalámbricos constituyen uno de los segmentos más innovadores en el mercado de las comunicaciones móviles. Fue la empresa Siemens la que en el año 1995 abrió el camino a las comunicaciones inalámbricas máquina a máquina sacando al mercado el M1, el primer módulo para comunicaciones industriales basado en el estándar de telefonía móvil GSM [1]. Desde entonces el mercado ha presentado una evolución constante y hoy en día es posible encontrar aplicaciones tan dispares como el seguimiento de estaciones meteorológicas a distancia, o la gestión de informes de averías de los dispositivos de control de ascensores o máquinas de lavado. La semilla que hace unos años plantó Siemens en el ámbito industrial ha germinado rápidamente y actualmente son muy diversas las propuestas de sistemas electrónicos basados en tecnología inalámbrica. Mayer [2] o Tan [3] proponen sistemas SCADA basados en GSM y en un ámbito más industrial, la empresa Telemetrix Inc [4], ofrece el sistema T3000, un sistema integrado de adquisición de datos basado en una infraestructura de comunicaciones digitales inalámbrica como el GSM, TDMA o CDMA. Juan Suardíaz Muro es profesor titular del Dpto de Tecnología Electrónica de la Universidad Politécnica de Cartagena. Campus Muralla del Mar. 30202 Cartagena, Murcia (tfno: 968 32 53 80; fax: 958 32 53 45; e-mail: juan.suardiaz@upct.es). Basil M. Al-Hadithi es profesor asociado en el Dpto de Electrónica y Sistemas de la Universidad Alfonso X el Sabio. Villanueva de la Cañada. Madrid (e-mail: bmal@uax.es). DOI (Digital Object Identifier) Pendiente Clase 1 2 3 4 5 Potencia Máxima (W) 20 8 5 2 0.8 Tipo Vehicular Portátil Palmario Palmario Palmario Dejando a un lado esta clasificación se pueden dividir los tipos de terminales en función del uso para el cual han sido diseñados. Según esto se podría diferenciar entre: - teléfonos móviles - Módems Ambos dispositivos comparten características. La función principal de un teléfono móvil es la transmisión de voz, aunque también existe la posibilidad de utilizarlos como transmisor/receptor de datos. Ofrece un interfaz amigable al usuario, tal como micrófono, altavoz, pantalla y teclado. Tales características hacen del teléfono móvil un instrumento ideal de uso personal. Los módems vienen a ser equipos terminales de aplicación industrial, en los que están potenciadas las funciones de comunicación y control, para la transmisión y recepción de datos. No obstante también permiten la transmisión de voz, para su uso como teléfono, aunque esta característica no viene a ser importante. No suelen disponer de teclado ni pantalla. A cambio, su control se realiza gracias a que poseen una interfaz de comunicaciones destinada a la conexión con otros equipos terminales (suele ser una comunicación serie), cualidad que los hace idóneos para la conexión con multitud de dispositivos electrónicos. ISSN 1932-8540 © IEEE 80 IEEE-RITA Vol. 2, Núm. 2, Nov. 2007 Fig. 1. Evolución de las redes móviles En resumen, el desarrollo de sistemas de control industrial basado en las comunicaciones inalámbricas parece consolidarse como un mercado muy prometedor; tal y como lo confirma la misma SIEMENS en un informe publicado en 2002 [1], en el que, tal y como resume la Fig. 2, las expectativas de mercado para este tipo de productos son muy esperanzadoras. Dentro del ámbito de este tipo de aplicaciones, el segmento de los servicios de mensajería basado en mensajes cortos (SMS) constituye un segmento que ha evolucionado de forma exponencial en los últimos años y que a nuestro entender puede ofrecer posibilidades muy interesantes en lo que a dispositivos de control se refiere. 9000 8000 7000 6000 5000 4000 3000 Automóviles Industria Consumo 2000 1000 0 Añ 1 o0 Añ 2 o0 Añ 3 o0 Añ 4 o0 Añ 5 o0 Añ 6 o0 Añ 7 o0 Añ 8 o0 9 0 Añ o Una gran multitud de modelos de teléfonos GSM y módems GSM/GPRS se encuentran disponibles actualmente, ofrecidos por fabricantes importantes como Motorola, Nokia, Siemens y Sony Ericsson. Los dispositivos GSM se ofrecen en una amplia variedad de precios y funcionalidades, incluso en modelos para el segmento superior, los cuales poseen pantallas a color y cámaras digitales incorporadas. Además, debido a que GSM es una norma abierta, cualquier proveedor puede fabricar equipos GSM. Esto pone a disposición de los operadores y clientes GSM una amplia selección de equipos y proveedores. Tanto las redes como los servicios móviles han sufrido una fuerte evolución a lo largo de los últimos años. En sus orígenes, la principal función de estas redes y servicios era la comunicación por voz. Los esfuerzos en el campo de las comunicaciones móviles han ido dirigidos hacia la mejora de los servicios de transmisión de datos. Básicamente consiste en el aumento de las velocidades de transmisión. Hoy en día ya se puede observar una clara tendencia (Fig. 1) hacia los servicios multimedia, en la que se comparten diversos modos de comunicación (datos, imagen y sonido). Fig. 2. Perspectivas de mercado para los sistemas de control inalámbricos En base a lo anteriormente expuesto, se ha considerado que el desarrollo de un caso práctico basado en este tipo de tecnología supondría un interesante banco de pruebas para alumnos correspondientes a la titulación de ingeniería técnica de Telecomunicaciones, especialidad telemática. Dicho caso de estudio se presenta dentro de la asignatura “Diseño de Sistemas Electrónicos”, en la cual se imparten conocimientos del lenguaje de descripción de hardware VHDL [5]. A fin de ofrecer una visión del diseño interrelacionada con los conceptos adquiridos en otras asignaturas de control y de sistemas de comunicaciones, se presenta un caso práctico que permite aportar una solución al problema del control a distancia, creando un sistema autónomo y compacto con funciones de telemando, telemetría y televigilancia. Los elementos esenciales de este sistema son una FPGA[6], donde se ha programado la lógica reconfigurable encargada de las funciones de control e interfaz de comunicaciones y un módem GSM a través del cual el controlador está permanentemente conectado a la red, evitando la necesidad de cables de transmisión de datos y permitiendo así una telemetría y actuación a larga distancia. A lo largo del presente texto se describen las distintas tareas que harán diferentes alumnos a lo largo de las sesiones prácticas. En primer lugar se detalla en la sección II, lo que serán los diferentes elementos que constituyen el subsistema deseado, con un enfoque modular, lo que permitirá la división del trabajo en paquetes que podrán ser desarrollados por diferentes equipos. Los principales datos para la implementación del sistema propuesto se aportan a lo largo del la sección III. A continuación se aplicará el sistema desarrollado a su evaluación sobre un problema específico. En este caso se ha optado por el sistema de control de temperatura detallado en la sección IV. Por último en la sección V se detallan los resultados y conclusiones derivados del diseño. II. DESCRIPCIÓN DEL SISTEMA PROPUESTO Para conseguir la operación a distancia son necesarios los siguientes elementos - Red de comunicaciones operativa ISSN 1932-8540 © IEEE SUARDÍAZ MURO Y AL-HADITHI: CASO PRÁCTICO BASADO EN FPGAs - Dispositivo de comunicaciones para el acceso a dicha red - Interfaz para la comunicación entre el dispositivo de comunicaciones y el controlador del proceso. Para la red de comunicaciones se seleccionó una del tipo de las ya existentes en el mercado. Debido al gran auge que presentan en la actualidad las comunicaciones móviles se ha optado por la red GSM, debido fundamentalmente a que ésta dispone de muchos servicios, entre los cuales se encuentran el realizar llamadas de voz, la transmisión de texto a través del Servicio de Mensajes Cortos (SMS, Short Message Service) y la identificación de llamada, entre otros. Una vez escogida la red a utilizar, el siguiente paso es seleccionar el tipo de dispositivo con el cual se accederá a la red, es decir, el terminal móvil. Para poder hacer uso de las funciones a distancia únicamente es necesario tener acceso al Servicio de Mensajes Cortos (SMS), lo cual es una característica común a todos los teléfonos y operadoras móviles GSM de Europa. Actualmente existen en el mercado dos tipos de elementos transmisor/receptor: - teléfono móvil GSM - módem GSM Obviamente la opción del módem es preferible frente a las de teléfono móvil, principalmente por los siguientes motivos: - El teléfono móvil es un aparato destinado al usuario, mientras que el módem presenta ciertas funciones que lo hacen más apto para aplicaciones industriales. - El control del teléfono móvil se realiza mediante teclado, mientras el módem es controlable a través de cable o infrarrojos, lo cual lo hace más compatible con los sistemas electrónicos e informáticos. Tras un estudio comparativo de estos modelos se ha optado concretamente por el Módem Siemens MC35T [7], ya que cumple los requisitos mínimos a la vez de tener un precio moderado. Además incluye otras características no exigidas pero que pueden ser favorables, como por ejemplo: - sistema autobaudio para la comunicación serie. - antena magnética externa independiente, con 3 metros de cable. - entradas y salidas analógicas para micrófono y altavoz. - alta compacidad. Conocido el dispositivo y su sistema de comunicación y control, se diseñó una interfaz de comunicaciones para poder conectar a distancia con el controlador. Dadas las funciones a distancia que debe desempeñar el sistema completo, la interfaz de comunicaciones debía ser bidireccional. Esto es: - Permite solicitar datos al controlador y que éste lea en su memoria y los transmita. - Permite enviar datos al controlador y que éste los almacene en su memoria interna. - Y en caso de que se activen las alarmas, el controlador, de forma automática, ha de poder transmitir los datos, según haya sido programado. El planteamiento general de la plataforma propuesta puede verse en la Fig. 3. Se encuentra constituida por el proceso que se desea controlar (proceso bajo control), el sistema digital a desarrollar objeto de este caso práctico (FPGA), constituido a 81 su vez internamente por dos subsistemas, uno dedicado a implementar el interfaz de comunicaciones con el terminal móvil (módem GSM) que le permitirá conectarse a la red GSM y el subsistema encargado de implementar el controlador que actuará sobre el proceso anteriormente comentado. De esta forma será posible que el sistema pueda enviar alertas al móvil de un usuario, o bien recibir nuevos parámetros de control a través de este medio. Existen diferentes soluciones de implementación que quedan al libre albedrío de los alumnos. En este texto se presenta una opción posible en la que se ha utilizado un dispositivo FPGA en el que el sistema se ha desglosado en el siguiente conjunto de módulos: un módulo (UART) que será encargado de establecer una comunicación serie entre la FPGA y el MC35T mediante comandos AT. Dos submódulos, denominados ‘Codificador de Comandos’ y ‘Decodificador de Comandos’ serán los encargados de la interpretación y generación de órdenes transmitidas y recibidas a través del MC35T. Finalmente, habrá un núcleo dedicado a la implementación del controlador que se comunicará con el exterior y que realizará el control del sistema seleccionado, un sistema de control de temperatura en este caso. Fig. 3. Estructura general de la plataforma propuesta III. IMPLEMENTACIÓN HARDWARE DEL SISTEMA Una vez seleccionado el tipo de terminal móvil y conocido su sistema de control, la próxima tarea es el diseño del hardware necesario para la implementación del módulo controlador de proceso y la interfaz de comunicaciones para conectar con dicho módem. Se trata de implementar el sistema al completo, que dicho sistema sea autónomo y a ser posible, adoptar una solución compacta basada en un único chip. Por tanto se descarta la idea de la conexión del módem a un ordenador. A cambio, se ha optado por el uso de un dispositivo lógico programable (PLD, Programmable Logic Device). Debido a la complejidad que este problema plantea, automáticamente quedan descartados los PLDs sencillos (como PAL, GAL, etc... ) siendo lo más conveniente la implementación sobre una FPGA, ya que es el único con la escala de integración suficiente como para programar todas las funciones a realizar, además de ser el más flexible ya que puede ser reconfigurada y verificada en muy poco tiempo. ISSN 1932-8540 © IEEE 82 IEEE-RITA Vol. 2, Núm. 2, Nov. 2007 Debido a la gran flexibilidad de las FPGAs no es necesario establecer muchos requisitos mínimos para poder llevar a cabo este diseño. Básicamente se podría decir que lo único imprescindible es que tenga la memoria suficiente como para almacenar la totalidad del hardware que se va a implementar. Sin embargo, en este momento no se dispone de información acerca del tamaño que ocupará el sistema porque éste aún no ha sido diseñado con detalle. Por tanto la opción más correcta sería desarrollarlo y una vez conseguido ese punto, conociendo ya el tamaño que supone, seleccionar la FPGA donde será volcado. No obstante se ha elegido una FPGA para poder empezar a implementar el diseño, confiando en que ésta será lo suficientemente grande. En caso de llegar a su límite de capacidad debería ser sustituida por otra mayor. Se ha optado por la familia Spartan II. Y más concretamente por la FPGA XC-2S200-PQ-208. El fabricante Xilinx [8] ofrece esta FPGA montada sobre una placa de pruebas, se trata de la placa Digilab 2 [9], que, además de incorporar las conexiones de alimentación, programación y oscilador, dispone de, entre otras, una conexión con adaptación de señal RS232 db9, y múltiples conectores unidos directamente a los pines de entrada/salida de la FPGA. Éstas son características que, sin duda, serán útiles, a la hora de conectar la FPGA con los dispositivos externos (como por ejemplo con el módem GSM). Parece, en un principio, que la conexión entre ambos dispositivos se puede realizar directamente a través de un cable serie estándar con conectores db9. Sin embargo se presenta el problema de que ambos dispositivos han sido diseñados para trabajar como DCEs, es decir como receptores. Debido a ello ambos poseen un conector db9 hembra. Por este motivo no pueden ser conectados directamente a través de un cable serie estándar, ya que éste consta de un conector macho en un extremo y un conector hembra en el otro. Una comunicación serie asíncrona bidireccional se puede simplificar a tres líneas de conexión: GND, TXD y RXD. Dichas líneas se corresponden con los pines 5, 3 y 2 respectivamente del conector db9. Por lo tanto, en esta fase del diseño es necesario realizar un cable serie con conectores db9 En conclusión, la Fig. 4 muestra cómo queda la conexión de los elementos seleccionados. Fig. 4. Aspecto final de la plataforma hardware Sobre la FPGA seleccionada se ha implementado la arquitectura de control esquematizada de forma general en la Fig. 5. Para ello se ha hecho uso de herramientas informáticas de diseño, simulación y síntesis destinadas a la configuración de dispositivos lógicos programables y como método de programación hardware, el lenguaje VHDL (Very High Speed Integrated Circuit Hardware Description Language) [10]. •Núcleo hardware del subsistema ‘interfaz de comunicaciones’. Este subsistema es el encargado de establecer la comunicación entre el módem GSM externo y el sistema de control disponible. Existen dos formas de manejo de datos en los sistemas digitales: - datos en serie. - datos en paralelo. Normalmente resulta más sencillo el procesamiento de datos en paralelo, si bien suele ser más apropiado los datos en serie para las funciones de transmisión y recepción entre dispositivos situados a una cierta distancia. Concretamente, la comunicación con el módem GSM se realiza a través del protocolo RS-232, que es un sistema de comunicación serie. El manejo de datos dentro de la FPGA se va ha realizar en modo paralelo. Fig. 5. Estructura general de la arquitectura hardware diseñada. macho en ambos extremos, teniendo en cuenta que se está estableciendo una conexión entre dos DCEs y por tanto es necesario cruzar los terminales TX y RX. La Fig. 6 detalla los diferentes submódulos que constituyen este elemento. ISSN 1932-8540 © IEEE SUARDÍAZ MURO Y AL-HADITHI: CASO PRÁCTICO BASADO EN FPGAs Fig. 6. Estructura hardware detallada en los submódulos VHDL constituyentes • Submódulo ‘UART’ En primer lugar, es necesario el diseño de un convertidor serie-paralelo/paralelo- serie, para poder establecer la comunicación con el módem. Esta es la finalidad del módulo ‘UART’ (Universal Asíncronous Receiver Transmiter). Este módulo, transmite por la línea de transmisión serie (Tx) los datos en paralelo recibidos en su puerto Din y a la inversa, recibe datos por la línea de recepción serie (Rx) y los agrupa en paralelo enviándolos por el puerto de salida Dout. Este módulo engloba los submódulos divisor, divisor2, emisor y receptor. La UART es un elemento de comunicación bidireccional. Por tanto serán necesarios un módulo encargado de recibir (receptor) y otro encargado de enviar (emisor). Para la comunicación serie asíncrona es preciso definir unos determinados parámetros, entre ellos la velocidad de transmisión ( baudios, bps ). Esta velocidad, aún escogiendo la más alta posible, según los estándares de transmisión (115200 bps) es mucho menor que la velocidad del sistema ( 50 MHz ). Por tanto se ha de definir un circuito de adaptación de velocidad. Esta es la misión de los módulos divisor y divisor2. Ambos módulos generan pulsos de reloj que marcarán la base de tiempos para la comunicación. • Submódulo ‘Codificador de Comandos’ La comunicación con el módem GSM se realiza por medio de comandos AT. Los comandos AT son el sistema utilizado para comunicar con módems y otros dispositivos de comunicaciones. La mayoría de las aplicaciones de comunicaciones tienen una interfaz amigable que oculta estos comandos, no obstante siguen siendo necesarios para establecer la comunicación. La estandarización de este lenguaje ha sido llevada a cabo por el Comité Técnico (TC, Technical Committee) del llamado 83 Special Mobile Group (SMG) perteneciente al Instituto Europeo de Estandarizacion de las Telecomunicaciones (ETSI, European Telecommunications Standards Institute). Esta estandarización se recoge en la Global System Mobile (GSM) Technical Specification (GTS), más concretamente en el documento Digital cellular telecommunications system (Phase 2+);AT command set for GSM Mobile Equipment (ME) (GSM 07.07). Este Estándar Europeo de Telecomunicaciones (ETS, European Telecomunications Standard) especifica un perfil de comandos AT y recomienda su uso para controlar las funciones de los Equipos Móviles (ME) y los servicios de la red GSM desde un Equipo Terminal (TE) a través de un Terminal Adaptor (TA). La interfase entre el TE y el TA se ha pensado para funcionar a través de un cable serie existente (la opción seleccionada en este trabajo), conexión infrarroja, o cualquier otro tipo de enlace de comportamiento similar. Para una correcta operación, muchos de los comandos definidos requieren 8 bits de datos, por lo tanto se recomienda que el enlace TE-TA se establezca en modo 8 bits. La interfaz entre el TA y el TE depende de la interfaz del ME. Todos los comandos están perfectamente definidos en cuanto a sintaxis y funcionalidad. Este sistema constituye un lenguaje estandarizado del cuál los módems hacen uso. No obstante la lista de comandos soportados varía en función del tipo de dispositivo o fabricante. Estos comandos consisten en cadenas de caracteres finalizadas por el carácter de RETURN. Para poder trabajar con estos comandos de forma sencilla se ha añadido el módulo ‘Codificador de Comandos’ y ‘Decodificador de Comandos’. El módulo ‘Codificador de Comandos’ se encarga de leer sucesivamente los caracteres recibidos, interpretar el comando formado por dichos caracteres y asignarle un código numérico. Para ello, recibe un comando en forma de cadena de caracteres y lo codifica asignándole un número de 8 bits, enviado dicho número a través del puerto svCom. Si no se ha podido codificar devuelve un “00000000”. Tras detectar el carácter de RETURN o bien, alcanzada la longitud máxima de los caracteres, una vez finalizada la codificación, devuelve un pulso a través del puerto recibido. La codificación de comandos se va a realizar por comparación. Para ello es necesario almacenar todos comandos decodificables. Se ha implementado, para tal fin, una memoria formada por una matriz de m filas y n columnas de elementos tipo carácter. Tanto m como n son valores configurables mediante las constantes char_matrix_size y char_vector_size en el código VHDL. Se ha utilizado el tipo carácter para poder inicializar dicha memoria de forma simple, mediante constantes tipo. A la constante char_matrix_size se le ha dado el valor del número de comandos que se quiere codificar (concretamente 10). A la constante char_vector_size se le ha asignado el valor de la longitud máxima que van a tener dichos comandos (concretamente 8). De esta forma se pueden almacenar 10 comandos de hasta 8 caracteres cada uno. ISSN 1932-8540 © IEEE 84 IEEE-RITA Vol. 2, Núm. 2, Nov. 2007 Esta memoria es del tipo sólo lectura, y únicamente se graba al inicializarse, asignando a cada fila de la matriz un comando (o cadena de caracteres ) determinado. Para la inicialización, hay que tener en cuenta que la asignación de valores a señales, en VHDL, requiere que tanto el valor como la variable sean del mismo tipo. Sin embargo, aunque todos los comandos son señales tipo string, no todos tienen la misma longitud. Para solucionar este problema se ha implementado una función que rellena los huecos hasta completar el tamaño de las cadenas de caracteres. A dicha función se le ha dado el nombre fill. Las tareas a realizar para efectuar la codificación son: - Carga de datos: almacenar datos recibidos para formar una cadena de caracteres. - Comparación: se compara la cadena recibida con las líneas de la matriz de memoria donde se almacenan los comandos. Para la primera tarea se ha declarado una señal tipo string (cvComando_aux) del tamaño de char_vector_size (8). Mediante un contador que se va incrementando conforme se detectan pulsos en la señal de carga (LD) se va apuntando a una posición concreta de la señal cvComando, para almacenar en ella el valor recibido tras su conversión a carácter previamente, mediante la función to_char. Este proceso continúa hasta que se alcanza la longitud máxima de caracteres recibidos o bien se detecta el carácter de RETURN. Finalizado el proceso de carga de datos se procede a la comparación. Se ha definido un contador que incrementa la señal i con cada ciclo de reloj. La señal i es utilizada para apuntar a la fila i de la matriz de comandos y leer dicha fila. Tras esta lectura se efectúa su comparación con la cadena de caracteres que se creó en la etapa anterior. Si se detecta coincidencia con alguna de las filas se pone en la salida svCom el valor de la señal i que se corresponde con el código asignado al comando recibido. • Submódulo ‘Decodificador de Comandos’ El módulo ‘Decodificador de Comandos’ recibe un código numérico, lo asocia con una cadena de caracteres y envía dichos caracteres secuencialmente. De esta forma con un único número se pueden hacer referencia a todos estos comandos y otras cadenas de caracteres que se van a utilizar. Está constituido por dos sumódulos denominados ‘cod2’ y ‘flujo’ Para la decodificación de comandos es necesario un bloque que almacene las cadenas de caracteres correspondientes a dichos comandos y que envíe estos caracteres de forma secuencial. El bloque cod2 es el encargado de realizar esta tarea. Contiene la memoria que almacena las cadenas de caracteres de los comandos que se van a utilizar. La presencia del componente flujo se justifica dada la necesidad de coordinación entre el cod2 y la UART externa. Es el encargado de manejar las señales de control (activación, lectura, envío, ... ) de ambos bloques. • Submódulo ‘Convertidor numeros=>caracteres’. La función del módulo ‘Convertidor numeros=>caracteres’ es, como su nombre indica, convertir números binarios en los caracteres correspondientes a sus dígitos en sistema decimal, teniendo en cuenta que serán transmitidos en código ASCII. Este módulo recibe un número de 8 bits por svDin y lo convierte en los caracteres ASCII correspondientes a sus dígitos en base 10, enviando dichos caracteres secuencialmente por svDout comenzando por el más significativo. Para poder representar un número de 8 bits en código decimal son necesarios tres dígitos: centenas (más significativo), decenas y unidades (menos significativo). Para llevar a cabo esta conversión se ha utilizado el módulo divisor (divcore.vhd). Este módulo está precompilado por Xilinx y se encuentra en la herramienta Core Generator. Realiza la función de dividir un dividendo entre un divisor para obtener un cociente y un resto. El tamaño de estas variables es configurable. Para este caso se han seleccionado señales de 8 bits. El proceso de conversión se va a realizar en dos etapas: 1. División entre 10 del número a convertir. Como resultado se obtiene un cociente y un resto. El valor de dicho resto corresponde con el dígito de las unidades. 2. Una segunda división entre 10 del valor obtenido como cociente en la operación anterior. El resultado de esta operación es otro cociente, que se corresponde con los dígitos de las centenas, y un resto que se corresponde con el digito de las decenas. Para llevar a cabo estas dos etapas se ha declarado una señal tipo array de 3 componentes tipo enteros donde se almacenarán los dígitos llamada digito. Además se ha implementado un contador de 0 a 22, que incrementa una señal (cuenta) en cada pulso de reloj. Mediante un bloque combinacional asociado se realizan las siguientes operaciones: Si cuenta=0 se coloca en el dividendo del componente divCore el valor del número a convertir. Si cuenta=10 el valor del resto se asigna a la señal digito(2). Y el valor del cociente se realimenta en al dividendo del bloque divCore. Si cuenta=22 el valor del cociente se le asigna a la señal digito(0) y el resto a la señal digito(1). El que haya que esperar 11 pulsos de reloj tras especificar el dividendo del divCore se debe a que este módulo necesita 11 pulsos de reloj para efectuar la operación. Una vez convertido el número binario en decimal, se analizan los dígitos obtenidos para eliminar los ceros a la izquierda con el fin de que sólo se transmitan aquellos dígitos que realmente sean necesarios. Posteriormente se procede a su conversión a código ASCII. La forma más sencilla de realizar esta operación se sumándole 48 al valor del dígito. Esto es posible porque en el código ASCII los dígitos (0-9) tienen códigos consecutivos, y el código del 0 es el número 48. un Tras obtener el código ASCII de los tres dígitos se ejecuta proceso secuencial para enviar dichos códigos ISSN 1932-8540 © IEEE SUARDÍAZ MURO Y AL-HADITHI: CASO PRÁCTICO BASADO EN FPGAs secuencialmente a través de la salida svDout, comenzando por el primer dígito distinto de 0 (desde el más significativo hasta el menos significativo). También hay que tener en cuenta que cada vez que se envía un carácter hay que esperar a que el encargado de transmitirlo (UART) termine de hacerlo, para poder enviar el siguiente. • Submódulo ‘Controlador de comunicaciones’. Este módulo es sin duda el más complejo y a la vez, el más importante de toda la estructura hardware que se ha desarrollado. Se podría decir que es la unidad más “inteligente” del sistema. Es capaz de realizar, entre otras, las siguientes funciones: - Configurar el módem GSM. - Dar la orden de realizar una llamada de teléfono. - Redactar un SMS y dar la orden de envío. - Leer e interpretar un SMS recibido. - Actuar según las ordenes interpretadas en un SMS leído. - Capturar y almacenar el número de teléfono de una llamada entrante. - Ejecutar un programa de instrucciones programado. - Detectar si la ejecución del programa se ha quedado bloqueada y reiniciar. Para poder llevar a cabo todas estas funciones, la estructura de este bloque, se ha basado en un sistema microprocesador. Consiste en un proceso secuencial en el que existen unas líneas de programa, cada una de las cuales contiene unas determinadas instrucciones. Dicho programa es el encargado de gestionar y procesar el tráfico de información entre el módem GSM y el controlador de temperatura. Dispone además de diversos puertos de entrada / salida con el fin de poder comunicar con el resto de bloques, tanto internos (‘UART’, ‘Codificador de comandos’, ‘Decodificador de comandos’ y ‘Convertidor numeros=>caracteres’ ) como externos (módulo de control). • Submódulo ‘Multiplexor’. Debido a que es posible enviar caracteres a la UART a través de varios módulos, se ha colocado un multiplexor con el fin de seleccionar en cada momento cuál es el módulo que va a transmitir, evitando de esta manera conflictos o colisiones de información. Debido a la complejidad del sistema desarrollado ha sido necesario limitar la frecuencia de funcionamiento del mismo, para evitar errores en el proceso. Para ello se ha introducido el módulo ‘frec_div’. El módulo ‘Pulso’ genera un pulso cuando detecta un flanco de subida en la señal de entrada. Dicho pulso es necesario para el control del módulo ‘Codificador de comandos’ (codificador). IV. CASO PRÁCTICO: SISTEMA DE CONTROL DE TEMPERATURA Como caso práctico de aplicación se ha escogido el control de temperatura, en el cual básicamente se pueden identificar: una variable de entrada – temperatura –, dos variables de salida – calentar y enfriar – y dos parámetros de control – consigna e histéresis –. El funcionamiento consiste en la 85 activación de la salida enfriar o calentar en función de que la temperatura sobrepase por encima, o por debajo respectivamente, la consigna, con un margen de error definido por la histéresis. A fin de controlar la temperatura, en primer lugar, es necesario conocer su valor en cada momento. La temperatura es una variable continua. Para poder ser interpretada y procesada por un sistema digital es necesaria su conversión previa a variable discreta. Esta es la función del convertidor AD externo. A fin de poder controlar y leer dicho convertidor se ha diseñado sobre la FPGA el módulo ‘Control ADC’ esquematizado en la Fig. 6. Una vez digitalizada la temperatura, es necesario procesarla para activar sistemas de control externos que la modifiquen según unos parámetros preestablecidos. Esta es la misión del módulo hardware ‘Control Proceso’. Para poder visualizar en todo momento la temperatura actual se ha diseñado el módulo ‘Visualizador’, el cual dispone de unas salidas para displays de 7 segmentos multiplexados. Además se ha dotado al controlador de una salida de alarma que se activa cuando, debido a alguna causa inesperada, se superan unos valores críticos. Éstos están definidos mediante los parámetros alarma superior y alarma inferior. Una vez muestreadas las entradas, es necesario analizarlas para actuar sobre las variables de control (o variables de salida) según unos parámetros de control. Esta es la misión del módulo ‘Control Proceso’ esquematizado en la Fig. 6 Un ejemplo del comportamiento de este dispositivo se puede ver en la Fig. 7, en la que es posible observar que cuando se superan los niveles dados por la consigna y el margen de histéresis, entra la acción de control correspondiente (calentar o enfriar) y que cuando se sobrepasan unos determinados niveles de alarma prefijados, se produce la activación correspondiente del indicador asociado. Hasta el momento, este sistema se asemeja bastante a cualquier otro controlador de temperatura, como pueda ser por ejemplo un sencillo termostato. La diferencia importante es que, gracias a la interfaz de comunicaciones que se ha diseñado, el controlador puede ser dirigido a través de teléfono móvil GSM, permitiendo modificar los parámetros de control y alarmas (telemando), solicitar información de la temperatura (telemetría), y recibir mensajes de alarma de forma automática cuando ésta se active (televigilancia). A continuación se detalla un ejemplo (Tabla II) de lo que podría ser un intercambio de comandos entre el dispositivo FPGA y el módem GSM que clarifica la comunicación mediante comandos AT. En la transmisión hacia el módem el encargado de la gestión es el submódulo ‘Codificador de Comandos’ antes comentado, mientras que en la recepción desde el módem el encargado de la gestión sería el ‘Decodificador de comandos’. ISSN 1932-8540 © IEEE 86 IEEE-RITA Vol. 2, Núm. 2, Nov. 2007 TABLA II EJEMPLO DE COMUNICACIÓN ENTRE FPGA Y MODEM GSM Linea 1: 2: 3: 4: 5: 6: 7: 8. 9: 10: 11: 12: 13: 14: Comandos enviados por la FPGA (COM1) ATV ATE AT+CLIP=1 AT+CMGF=1 AT+CNMI=2, 1, 0, 2, 1 AT+CPMS="MT", "MT", "MT" AT+CMGD=1 ATDT nnnnnnnnn AT+CMGS="nnnnnnnnn" Temperatura actual=24 grados AT+CMGS="nnnnnnnnn" ALARMA! Temperatura actual=43 grados AT+CMGR=1 AT+CMGD=1 (nnnnnnnnn : número de teléfono del usuario) Linea 1: 2: 3: 4: 5: 6: 7: 8. 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31. 32. 33: - - - Las 11 primeras líneas son las respuestas correspondientes a los comandos de configuración La línea 12 indica que la llamada realizada ha sido colgada Entre las líneas 13 y 15 se recibe una llamada procedente del teléfono móvil ( petición de un SMS informativo ) Las líneas 18-19 y 22-23 son las respuestas correspondientes al envío de los SMS informativo y de alarma respectivamente. La línea 25 indica que se ha recibido un SMS Las líneas 27 a 32 son la respuesta correspondiente a la orden a la lectura de un SMS Comandos enviados por el MÓDEM (COM2) ATV 0 ATE 0 0 0 0 V. RESULTADOS Una vez programado el código VHDL necesario para describir la arquitectura que se ha planteado, se ha sintetizado e implementado, mediante las correspondientes herramientas informáticas y finalmente se ha programado sobre la FPGA seleccionada. Los resultados obtenidos durante esta fase de implementación se detallan en la tabla III. +CPMS: 4, 45, 4, 45, 4, 45 0 0 7 2 TABLA III RESULTADOS DE LA IMPLEMENTACIÓN HARDWARE Recurso +CLIP: , "nnnnnnnnn", 161, , , , 0 > Slices Registros LUTs IOBs Puertas equivalentes +CMGS: 53 0 > +CMGS: 54 0 +CMTI: "MT", 1 +CMGR: "REC UNREAD", "+34nnnnnnnnn", , "03/12/03,12:53:49+00" #T36*H3*A45*# 0 0 (nnnnnnnnn : número de teléfono del usuario) Del texto procedente de la FPGA se puede interpretar lo siguiente: - Las primeras siete líneas corresponden a comandos utilizados en la configuración del módem GSM. - La 8ª línea muestra el comando utilizado para realizar la llamada de petición de confirmación de comienzo de ejecución. - En las líneas 9 y 10 se redacta y envía un SMS informativo. - En las líneas 11 y 12 se redacta y envía un SMS de alarma - La línea 13 manda la orden de lectura del SMS almacenado en el registro 1. - La línea 14 borra el registro 1. Del texto procedente del módem se puede destacar lo siguiente: Rutas Redes Conexiones Periodo mínimo Retardo máximo Frecuencia máxima Análisis de recursos Cantidad utilizada 1.719 1.315 2.739 27 29.354 Análisis de retardos % de los disponibles 73% 27% 58% 19% 1.893,413 1.315 1.271 44 ns 7,397ns 38,879MHz Como es posible observar en la tabla anterior, han sido utilizados 1.719 slices, lo que supone el 73% de la capacidad de la FPGA. Xilinx recomienda una ocupación de estos dispositivos inferior al 80. Teniendo en cuenta este dato, se puede decir que la elección de la FPGA ha sido correcta, si bien se están rozando los límites de capacidad del dispositivo. Por otro lado, de los 140 pines de entrada/salida disponibles, únicamente han sido utilizados 27. Esto corresponde con el 19% del total, lo cual indica que esta característica de la FPGA está siendo infrautilizada. Esto permitiría una gran ampliación, pudiendo dotar al sistema de un gran número señales de control y variables de entrada adicionales. Por último, tras el análisis de retrasos en las señales, se obtiene un periodo de funcionamiento mínimo de 26ns, lo cual permite una frecuencia de trabajo de 38MHz. Esta frecuencia es más que suficiente para desempeñar las funciones para las cuales el sistema ha sido diseñado. ISSN 1932-8540 © IEEE SUARDÍAZ MURO Y AL-HADITHI: CASO PRÁCTICO BASADO EN FPGAs 87 Fig. 7. Ejemplo de evolución de las salidas del controlador de temperatura desarrollado REFERENCIAS VI. CONCLUSIONES Se ha diseñado un caso práctico de aplicación capaz de realizar las siguientes funciones: • Control automático de un proceso en base a unos parámetros dados. • Operación remota: - Solicitar información del estado del proceso a controlar. - Modificar los parámetros de control. - Programación de alarmas. - Respuesta automática de mensajes de alarma, según lo programado. Desde un principio se ha querido realizar un dispositivo que pueda tener una determinada aplicación real, con el fin de que no quede en un mero trabajo teórico. Con esta intención, se ha decidido concretar en un proceso de control de temperatura. Éste no es más que un ejemplo de las múltiples aplicaciones posibles, que se ha escogido por ser un caso muy frecuente en tareas industriales (calderas, procesos químicos, cultivos en invernadero,...) y cotidiano a nivel de usuario (pensemos en cualquier sistema de climatización de una vivienda, local o automóvil). De la forma que ha sido planteado, resultará fácil realizar una posterior modificación del dispositivo para trabajar en circunstancias diferentes, variando la programación del sistema de control, modificando la sintaxis de los mensajes SMS, etc. La experiencia ha supuesto un reto para los alumnos, si bien el esfuerzo inicial ha sido grande en el arranque de la experiencia, el grado de satisfacción medido al finalizar la asignatura ha sido elevado. Un 70% de los alumnos han presentado un nivel de satisfacción elevado, el 20% indican un grado medio de satisfacción y un 10% presenta un grado bajo de satisfacción. [1] [2] Wireless Module White Paper. Siemens Inc. 2002. Kevin Mayer and Ken Taylor; “An Embedded Device Utilizing GPRS for Communications”; International Conference On Information Technology and Applications, Bathurst, Australia, 25-28 November 2002. [3] Lukas Tan and Ken Taylor; “Mobile SCADA with Thin Clients - A Web Demonstration”; International Conference On Information Technology and Applications, Bathurst, Australia, 25-28 November 2002. [4] Telemetrix Inc.: http://www.tlxt.net [5] David Van den Bout . “The practical Xilinx Designer Lab Book”. Ed. Prentice Hall, 1999.. [6] Peter J Ashenden. “The Designer’s Guide to VHDL”. Morgan Kaufmann, 1996 [7] Manual usuario MC35T. Xacom Inc: http://www.xacom.com [8] Xilinx Inc: http://www.xilinx.com [9] Digilent Inc: http://www.digilent.com [10] The IEEE Standard VHDL Language Reference Manual, ANSI/IEEEStd-1076-1993. Juan Suardíaz Muro obtiene el título de ingeniero industrial en 1997 y el de doctor ingeniero industrial en 2001. Actualmente trabaja como profesor titular de universidad en el departamento de Tecnología Electrónica de la Universidad Politécnica de Cartagena (Murcia, España), donde imparte clases de circuitos integrados analógicos lineales y diseño de sistemas electrónicos. Sus principales líneas de investigación se centran fundamentalmente en diseño de sistemas electrónicos mediante FPGAs, control electrónico y visión por computador. Basil M. Al-Hadithi obtiene el título de B. Sc. en ingeniería de control y sistemas en el año 1983 y el M. Sc. en ingeniería de control e instrumentación en el año 1988. Posteriormente, obtiene el título de Doctor ingeniero industrial en control de procesos e inteligencia artificial en el año 2002. Trabaja desde 1999 como profesor en la universidad Alfonso X (Madrid, España), donde imparte clases de teoría de sistemas, regulación automática y diseño de sistemas electrónicos. Su interés se centra principalmente en el área de control adaptativo, control borroso y control de estructura variable. Además actualmente se encuentra investigando en el área del diseño de sistemas electrónicos mediante FPGAs. ISSN 1932-8540 © IEEE 88 IEEE-RITA Vol. 2, Núm. 2, Nov. 2007 ISSN 1932-8540 © IEEE
