simulación de scada con comunicación gsm

Transmisión y redes de datos Scada con comunicación GSM

Autor: Domingo Díez Barrero Página 1 de 10 Universidad de Huelva, Escuela Politécnica Superior

Simulación de Scada con comunicación GSM

Introducción. En todos los procesos industriales de fabricación se pueden originar en ocasiones

imprevisibles situaciones de alarma debido a un fallo en cualquiera de los sistemas con los que cuenta el proceso.

Estos fallos pueden provocar situaciones peligrosas para los trabajadores del proceso, una parada en la producción o un mal funcionamiento del sistema dependiendo de la gravedad del mismo. En cualquier caso puede repercutir en unos costes, que se pueden incrementar si no se soluciona el problema en el menor tiempo posible.

En consecuencia es de vital importancia la pronta actuación en este tipo de situaciones. La única forma de luchar contra estas situaciones es la información. Cuanto antes se

conozca el problema y su naturaleza, es decir se obtenga información, antes se solucionará, reduciendo los citados costes.

Ahora se nos plantea el problema de obtener información instantánea de la alarma ocurrida.

Para solucionar este problema necesitamos monitorizar de forma constante el proceso industrial en todas sus etapas y cada uno de sus sistemas, o al menos los más importantes.

La información de la planta se obtiene a través de las variables analógicas y digitales que nos proporciona el sistema de sensores. Esta información expresada en soporte eléctrico, debe ser comunicada de manera comprensible al sistema automático que controla los actuadores o al personal de la planta para que actúe en consecuencia.

La mejor manera de comunicar el estado de los sensores y del proceso en sí al personal es de manera gráfica utilizando algún dispositivo HMI, Human Machina Interfaz, o mediante el uso de un ordenador, PC. Esta segunda opción es indudablemente más económica.

En consecuencia para obtener la máxima información sobre el proceso industrial de la manera más eficiente, necesitamos un Scada, un medio que nos ofrezca una interfaz gráfica con el proceso industrial a través del sistema de sensores o través del sistema automático que esté implantado.

Con la implantación de este elemento tenemos solucionada una parte del problema, pero sigue estando sin cubrir la necesidad de comunicar de manera inmediata, o en el menor tiempo posible, los errores del sistema de producción. Es necesario combinar este elemento indispensable con algo que sirva para establecer una vía de comunicación directa cuando se produzca la alarma en la planta. La vía de comunicación que se necesita establecer deberá de ser instantánea, debido a los requerimientos anteriormente expuestos, barata, de cara a reducir costes, y de fácil acceso.

Gracias al desarrollo de la tecnología, nuestra sociedad se ha convertido en la sociedad de la información, pudiendo establecer comunicación con cualquier persona en cualquier momento gracias al teléfono móvil. El teléfono móvil, herramienta indispensable de trabajo, es un elemento de comunicación instantáneo, barato y de fácil acceso. Y dentro de la telefonía GSM la comunicación a través de mensajes SMS es la mejor manera de comunicar un volumen de información pequeño pudiendo almacenarse en memoria para tener constancia de él.

Resumiendo necesitamos un sistema que sirva de interfaz entre el proceso industrial y los operarios, Scada, y además que se comunique de manera instantánea a través del teléfono móvil, telefonía GSM, dando información sobre el evento, alarma o aviso, acaecido.

Para resolver este problema concreto surge este proyecto.



Objetivo. El objetivo de este proyecto es la elaboración de un Scada para monitorizar un proceso

industrial simulado, con la posibilidad de comunicar eventos, alarmas o avisos, a través de mensajes cortos SMS usando un modem GSM.

Proceso industrial. El proceso industrial a simular sería el de la fabricación de un producto químico líquido a

partir de la mezcla bajo unas determinadas condiciones de temperatura de un fluido y un sólido. El fluido sería almacenado en un tanque previo que se llenaría a través de una

electroválvula de manera independiente al proceso cada vez que éste se vaciara. Cuando la cuba de mezclado está lista se abre la electroválvula de salida del tanque de

almacenamiento hasta llenar ésta. Se enciende el sistema de calentamiento de esta cuba y se espera la venida del otro componente que lo hará a través de una cinta transportadora, que se activa cada vez que se llena la cuba y hay una temperatura adecuada.

Una vez en contacto los dos componentes se mezclan en la cuba a una temperatura de aproximadamente de 100 ºC durante un determinado tiempo y después se vacía la cuba del compuesto, para volverse a llenar a continuación.

Todo el proceso está automatizado por un PLC que comunica las variables del sistema, tanto digitales: apertura y cierre de las electroválvulas; como las analógicas: temperatura de la cuba, y niveles del tanque de almacenamiento y de la cuba; y el error de las electroválvulas al Scada.

Scada. El Scada a realizar tendría la función de monitorizar las variables que le fueran ofrecidas

por el autómata a través de una tarjeta de adquisición de datos, sin tener la posibilidad de actuar sobre el sistema, pero debe tener la opción se simular errores en el sistema para probar la comunicación GSM mediante el uso de comandos AT con un modem GSM, que será el encargado de enviar los mensajes informativos SMS al móvil configurado.

Se propusieron varias plataformas de programación visuales, considerando la posibilidad

de utilizar LabView, pero al final se desarrolló el software con C++ Builder, por utilizar la potencia y flexibilidad del lenguaje C++, C orientado a objetos.

Comunicación GSM. La comunicación a través de mensajes cortos SMS se lleva a cabo a través de un

modem GSM, modelo WMOD2 de la compañía Wavecom, que se comunica con el PC a través del puerto serie RS-232, mediante comandos AT.

Dicho modem fue prestado durante las pruebas técnicas de comunicación por DIPROSISA, S.L.

Características del equipo módem GSM-GPRS diseñado para aplicaciones de datos, fax, SMS y voz. Totalmente compatible con los estándar ETSI GSM. Especificaciones Fase 2+.Fácil acceso a la tarjeta SIM (3v / 5v)

Alimentación de salida: 2w - Clase 4, GSM 900, 1w - Clase 5, GSM 1800. Voltaje de entrada: 5V-32V para GSM 900 Corriente de entrada: (GSM 900 @ 12V) <10 mA en reposo y 200 mA en transmisión,

(GSM 1800 @ 12V) <4,8 mA en reposo y 100mA en transmisión. Rango de temperatura:-20°C - +55°C operativo, y -25°C - +70°C almacén



Dimensiones: 98 x 54 x 25 mm Peso aprox.: 130 gr. Características Básicas: teléfono (TCH / FS) y llamadas de emergencia, modos FR /

EFR / HR, DTMF (tonos multifrecuencia), algoritmo de encriptación A5/1 y A5/2, SMS: MT / MO / CB / modo PDU

Servicios suplementarios: desvío de llamadas, restricción de llamadas, identificación de llamada entrante, multiparty, aviso de carga (AoC), SIM Lock, SIM Toolkit, agenda telefónica, número de marcación fija, llamada en espera y retención de llamada, cancelación de eco, y USSD.

Características de datos: transmisión asíncrona, modos transparente y no transparente, velocidad de transferencia, hasta 14.400 bps, 2.400 y 4.800 bps en Half Rate.

Rango de velocidades en puerto local: desde 300 bps a 19.200 bps con autobauding. Fax grupo 3 (clase 1 y 2). Soporte compresión V.42, V.42 bis. Soporte GPRS. Soporte WAP. Interfaces: V.24 y audio a través del conector sub-D 15. Alimentación a través de un conector micro FIT de 4 pines. Conector de la antena SMA

hembra. Soporte para la tarjeta SIM. Control remoto por medio de comandos AT (GSM 07.07 y 07.05).

Especificaciones GPRS: GPRS clase 2. Esquema de codificación: C51 a C54. Cumple con SMG 31 bis.



Software. El proyecto está formado por dos formularios con sus respectivos archivos de código,

.res, .cpp y .h, que más adelante se describirán con detalle, un hilo de subproceso para tener abierta continuamente la escucha en el puerto serie, y una clase de comunicaciones para trabajar con el puerto serie.

Comenzaremos por describir la clase de control del puerto serie por ser la más compleja y de mayor importancia:

Clase TWinSerCom La declaración de la clase está definida en el archivo portcom.h con dos zonas una

protegida, protected, que sólo será compartida por las clases tipo friend de ésta, y que está formada por la declaración de todas las variables y estructuras usadas para comunicarse con la API WIN32 de Windows; y una segunda parte pública, public, accesible por todo el código.

Las variables declaradas son: Int iNumCom -> almacena el nº de puerto que se abre. Bool lOpen -> indica si está abierto el puerto. Handle hCom -> manipulador, puntero, de flujo de datos en windows, sea para ficheros,

para puertos, …etc. DCB sComCfg -> estructura para configurar el puerto serie sus campos son:

DCBlength Tamaño de la estructura DCB BaudRate Velocidad en bps fBinary:1 Activación del modo binario fParity:1 Activación del chequeo de errores de paridad fOutxCtsFlow:1 Activación del control de flujo por CTS fOutxDsrFlow:1 Activación del control de flujo por DSR fDtrControl:2 Define el modo de empleo de la línea DTR. (Control de flujo por

hardware DTR-DSR) fDsrSensitivity:1 Activación de la eliminación de datos mientras DSR activada fTXContinueOnXoff:1 Referente a control de flujo por software fOutX:1 Activa el control de flujo por software durante transmisión fInX:1 Activa el control de flujo por software durante recepción fErrorChar:1 Activa la sustitución de carácter mal recibidos por el dato ErrorChar fNull:1 Activa la eliminación de los Bytes recibidos nulos fRtsControl:2 Define el modo de empleo de la línea RTS. (Control de flujo por

hardware RTS-CTS) fAbortOnError:1 Impide la lectura o escritura hasta que se llame a función

ClearCommError( ) XonLim Límite inferior del Buffer del receptor XoffLim Límite superior del Buffer del receptor ByteSize Determina el número de bits de datos: 4,5,6,7,8 Parity Paridad: NOPARITY, EVENPARITY (par), ODDPARITY (impar) StopBits Bits de Stop: ONESTOPBIT, ONESTOPBITS, TWOSTOPBITS XonChar Carácter de XON XoffChar Carácter de XOFF ErrorChar Sustituye carácter mal recibidos si se ha activado el servicio EofChar Carácter de final de transmisión



EvtChar Carácter para forzar el lanzamiento de un evento Comstat sComSta -> estructura del estado del puerto, sus campos son:

fCtsHold Si True el puerto está esperando que el DCE active CTS fDsrHold Si True el puerto está esperando que el DCE active DSR fRlsdHold Si True el puerto está esperando que el DCE active CD fXoffHold Si True el puerto ha recibido Xoff fXoffSent Si True el puerto ha enviado Xoff fEof Si True el puerto ha recibido un carácter Eof fTxim Si True hay un carácter en buffer de transmisión DWord cbInQue Nº de caracteres en buffer de receptor DWord cdOutQue Nº de caracteres en buffer de transmisión

Dword dwErr -> variable de tipo doble palabra con el error del puerto. Dword dwTamBufIn -> variable con el tamaño del buffer de entrada. Dword dwTamBufOut -> variable con el tamaño del buffer de salida. Dword dwEvtMask -> variable con los eventos producidos en el puerto serie. Commtimeouts sTimOut -> estructura con configuración de tiempos en la comunicación:

ReadIntervalTimeout Tiempo máximo de espera entre bytes recibidos ReadTotalTimeoutMultiplier Factor de escala para calcular el TIMEOUT de las operaciones de

lectura ReadTotalTimeoutConstant Constante para calcular TIMEOUT en operaciones de lectura WriteTotalTimeoutMultiplier Factor de escala para calcular el TIMEOUT en operaciones de

escritura WriteTotalTimeoutConstant Constante para calcular TIMEOUT en operaciones de escritura

En la parte pública se declaran las funciones de uso en la comunicación serie: TWinSerCom(int sport) -> función constructora de la clase que inicializa los parámetros

configurables del puerto. Bool Open (DWORD vel=CBR_9600, Byte tam_byte=8, Byte paridad=NOPARITY, Byte

bits_stop=ONESTOPBIT) -> función de apertura del puerto con parámetros de entrada predefinidos.

Bool Open (int iPor, DWORD vel=CBR_9600, Byte tam_byte=8, Byte paridad=NOPARITY, Byte bits_stop=ONESTOPBIT) -> función sobrecargada de apertura de un puerto especificado.

Bool Close (void) -> función para cerrar el puerto abierto. Bool IsOpen (void) -> función para chequear apertura. Bool IsDCE (void) -> función para comprobar DCE conectado. Bool RxByte (BYTE &bDta) -> recoge un byte del buffer de repción. Bool TxByte (BYTE bDat) -> manda una biyte al buffer de transmisión. DWORD LeerError (void) -> función para leer el error del puerto serie. Bool SetEventos (DWORD dwDat) -> función para fijar la máscara de eventos. Handle LeeIde (void) -> función para leer el manipulador del puerto serie. DWORD BytesRecibidos (void) -> Devuelve la cantidad de bytes recibidos. Una vez declarada la cabecera de la clase de comunicaciones definiendo todas las

funciones pertenecientes, todas las variables y todas las estructuras en el archivo portcom.cpp se escribe el código de cada una de ellas. Dicho código se encuentra en el anexo I.

Esta clase se encarga de toda la comunicación usando como interfaz con el hardware la API WIN 32.



Otra clase importante es la que hace de subproceso la clase CSerRx.

Clase CSerRx Esta clase hereda de la parte pública de la clase TThread, y está formada por una

función de __fastcall Execute( ), que contendrá el código que se ejecutará de forma continuada mientras esté activo el subproceso , una función constructora sin código que hereda del constructor de TThread, y una función sin definir en esta versión del software MostrarRx(void).

La función Execute ( ) está suficientemente explicada en el Anexo II.

Clase TForm2 Es la clase que define el código del primer formulario de presentación.

Esta clase hereda de la parte pública de la clase TForm y en su parte __published define los siguientes objetos:

TImage *Image1 -> Puntero al objeto Image1 de tipo TImage, que es el fondo de duna que aparece.

TBitBtn *BitBtn1 ->Puntero al objeto BitBtn1 de tipo TBitBtn, que es el botón de continuar.

TLabel *Label1 -> Puntero al objeto Label1 de tipo TLabel, es el texto: Scada con comunicación GSM

TLabel *Label2 -> Puntero al objeto Label2 de tipo TLabel, es el texto: Asignatura: Transmisión y redes de datos.

TLabel *Label3 -> Puntero al objeto Label3 de tipo TLabel, es el texto: Alumno: Domingo Díez Barrero.

TLabel *Label4 -> Puntero al objeto Label4 de tipo TLabel, es el texto: Versión 0.2. Void __fastcall BitBtnClick (TObject *Sender) -> función para ejecutarse cuando se pulse

el botón de continuar.



En la parte pública se define el constructor de la clase __fastcall TForm2 (TComponent * Owner) que hereda del constructor de la clase TForm.

En el proyecto se crean de manera conjunta este formulario como el principal pero este se hace visible al crear mientras que el principal permaneced en un segundo plano, cuando se pulsa el botón se cambia el atributo de visibilidad, y este formulario se hace invisible apareciendo el formulario principal, que mientras había permanecido en el fondo.

Clase TForm1 Esta clase es la que define el formulario principal.

El Scada está sustentado sobre varias funciones que coordinadas ejecutan la

simulación, entre ellas hay una función sistema (void) que se encarga de provocar gráficamente en el sistema los efectos de la apertura y del cierre de las electroválvulas, llenado y vaciado de los tanques, indicando también cuando se han llegado a los niveles de llenado. Otra función automata (void), se encarga de controlar y regular los tiempos del proceso de mezcla.

Todos los eventos de control y de llenado están regidos por temporizadores que

determinan la velocidad de llenado y vaciado de los tanques, así de la velocidad de la cinta transportadora.

El interfaz gráfico consta de una serie de objetos, shape, que modifican sus

características: tamaño, color y posición, para simular el nivel de fluido de un deposito, el calentamiento de un depósito o el movimiento de un objeto sobre un cinta, todo ello sobre un fondo, el objeto Image1, extraído del software SuperVisor de Omron para hacer software de monitoreo con autómatas.



Para facilitar el nombramiento de las electroválvulas se declararon las siguientes

constantes, para ser sustituidas por su número asociado en tiempo de compilación: Const int val_in_1=1 -> la palabra val_in_1 valdrá 1. Const int val_out_1=2 . Const int val_in_2=2. Const int val_out_2=3. Está clase TForm1 hereda de la parte pública de la clase TForm, y tiene definidas

además en la parte __published todos los objetos de los que está compuesto el formulario, incluido el MainMenu Menú con el que se accede a activar y desactivar el proceso, a parte también se declaran las siguientes funciones:

Void __fastcall Salir1Click (TObject *Sender) -> Función ejecutada al pulsar el botón de salir del menú principal, se encarga de cerrar el puerto de comunicaciones y suspender el hilo de recepción.

Void __fastcall FormCreate (TObject *Sender) -> Función que se ejecuta al crear al formulario, inicializa algunas variables de la interfaz gráfica.

Void __fastcall Activar1Click (TObject *Sender) -> Función que se ejecuta al pulsar el botón de activar, pone en marcha la simulación del sistema.

Void __fastcall Timer1Timer (TObject *Sender) -> Función que se ejecuta al proporcionar el temporizador1 un evento.

Void __fastcall Desactivar1Click (TObject *Sender) -> Función que se ejecuta al pulsar el botón de desactivar simulación del Menú.

Void __fastcall Timer2Timer (TObject *Sender) -> Función que al igual como la anterior se ejecuta cuando un temporizador, el temporizador2, proporciona un evento.

Void __fastcall BitBtn1Click (TObject *Sender) -> Función que se ejecuta al pulsar el botón de simulación de error al lado de la primera electroválvula.

Void __fastcall Timer3Timer (TObject *Sender) -> Función que se ejecuta cuando el temporizador3 da un evento.

En la parte pública se declaran todas las variables usadas por el sistema, así como las funciones automata (void), y sistema (void), anteriormente mencionadas, estas son:

Bool lleno_tan1, vacio_tan1, lleno_tan2, vacío_tan2 -> toman el valor de True según los niveles máximos y mínimos de los tanques.

Bool quemador_on -> indica la activación del quemador. Bool pido_paquete -> indica el pedido del segundo ingrediente sólido. Bool fin -> indica el final del proceso. Bool espero_calor -> indica la espera a que el segundo tanque tenga la temperatura

adecuada. Bool paquete_ok -> indica la caída del paquete dentro de la cuba. Bool error -> indica simulación de error en la electroválvula. Int temperatura -> variable analógica con el valor de la temperatura. Int tempo_quemador -> tiempo que debe estar encendido el quemador a partir de que el

paquete haya caido. Bool llenar_tanque1 -> orden de llenado de tanque 1. Bool vaciar_tanque1 -> orden de vaciado del tanque 1. Bool llenar_tanque2 -> orden de llenado de tanque 2. Bool vaciar_tanque2-> orden de vaciado de tanque 2. Void automata (void) -> función que simula el comportamiento del autómata que controla

el proceso.



Void sistema (void) -> función que simula el comportamiento de sistema de producción ante las acciones de los actuadores.

Void paquete (void) -> función que controla la cinta y la caída del sólido a la cuba de mezclado.

Void quemador (void) -> función que regula el tiempo que está encendido el quemador. Void apagar_quemador (void) -> función para cambiar de color todas las barras del

quemador, ponerlas a gris, y colocar a False la variable quemador_on. Void encender_quemador (void) -> función para cambiar de color todas las barras del

quemador , ponerlas a rojo, y colocar a True la variable quemador_on. TWinSerCom *pCom -> puntero a nuestra clase de comunicaciones. Int puerto -> contiene el número de puerto serie que se va a abrir. Dword velocidad -> velocidad en baudios del puerto. Byte bits_dato -> bits de datos. Byte bits_parada -> bits de parada. Byte acBuf[1024] -> buffer del programa con los datos recibidos. AnsiString telefono ->cadena con el teléfono móvil al que se va a enviar los mensajes. Void abrir_puerto (void) -> función para abrir el puerto de comunicaciones especificado. Void cerrar_puerto (vodi) -> función para cerrar el puerto de comunicaciones

previamente abierto. Void enviar_cad (AnsiString cTmp) -> enviamos una cadena por el puerto serie. __fastcall TForm1 (TComponent* Owner) -> constructor de la clase principal. A continuación pasamos a describir brevemente el funcionamiento del programa. Cuando se ejecuta la aplicación se llama en primer lugar al constructor de la clase

TForm1, que inicializa los parámetros del puerto serie de la siguiente forma: Puerto 1 Velocidad CBR_9600 Bits datos 8 Paridad NOPARITY Bits parada ONESTOPBIT

El teléfono inicialmente se inicializa a “655037161” Y se crean la clase de comunicaciones TWinSerCom, y la clase del subproceso

CSerRx, llamando a sus respectivos constructores. Después al crear el formulario principal se inicializan todas las variables referentes al

interfaz gráfico, abriendo al final de esta función el puerto, que dará el mensaje de apertura de puerto si tiene éxito.

Después se nos mostrará la ventana de información, el segundo formulario, que desaparecerá al pulsar en Continuar.

En la ventana del formulario principal aparece el interfaz con unos cuantos elementos representativos del proceso industrial a simular.

Acceder al menú principal aparecen además de la opción de salir que cerraría el puerto, suspendería el subproceso y concluiría la aplicación, la opción de activar la simulación. Al pulsar esta opción, se habilita la opción de desactivar, y comienza la simulación.

La simulación del proceso se lleva a cabo según lo descrito en apartados anteriores, pudiendo provocar el fallo de la electroválvula al pulsar en el botón de Error, en ese momento se envía un mensaje determinado al número de teléfono inicializado y aparece un aviso en pantalla.



Conclusión Este software precariamente desarrollado sienta las bases para realizar una

comunicación bidireccional a través de la tecnología GSM y en particular a través de mensajes SMS tan usados para la comunicación la sociedad actual.

Esta versión aunque no cumple con todas las expectativas del proyecto si se muestra como un principio de proyecto innovador y con aplicaciones demostradas.

Para futuras versiones sería necesario mejorar la configuración de la clase del puerto serie para mejorar la comunicación con el modem, que aún es deficitaria, al igual que mejorar y terminar de desarrollar el subproceso, permitir el acceso a la configuración del mensaje de error, así del teléfono o teléfonos a los que sería enviado. De cara a establecer la comunicación bidireccional, se debería de desarrollar un protocolo de comunicaciones entre el PC y el usuario en el mensaje SMS así como un password de acceso a los recursos del sistema.

Muchas de las propuestas de mejora la futuras versiones no se han podido desarrollar por falta de tiempo.

simulación de scada con comunicación gsm

Documents