UNIVERSIDAD DE SANTIAGO DE CHILE

FACULTA DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA

DISEÑO E IMPLEMENTACIÓN DEL SISTEMA SCADA PARA

EQUIPOS MÓVILES ANDROID CON SOFTWARE LIBRE.

TOMÁS MARCELO CASTILLO CASTILLO

Profesor Guía:

Ing. M.Sc. Manuel Valenzuela Ponce

Trabajo de Titulación presentado en

conformidad a los requisitos para
obtener el Título de Ingeniero de
Ejecución en Electricidad

Santiago – Chile

2012
© Tomás Marcelo Castillo Castillo.

Se autoriza la reproducción parcial o total de esta obra, con fines académicos,

por cualquier forma, medio o procedimiento, siempre y cuando se incluya la cita
bibliográfica del documento.

ii
iii
 Dedicatoria.

En primer lugar por el apoyo de mi Madre, por su esfuerzo

entregado en mí.
Por mis Tíos, por los consejos fructuosos que me han entregado.
Doy gracias a mis profesores que inculcaron en mí su conocimiento y
perspectiva de la vida.
Y por todas las personas que me acompañan en el caminar de esta
vida.

iv
 Agradecimientos

Doy gracias a mi profesor guía Manuel Valenzuela Ponce por sus

consejos, como también a los profesores Carlos Lanyon Olivares y
José Bascur Parada en la elaboración de esta Memoria.
Gracias por la Universidad que me ha acogido en este transcurso de
aprendizaje.

v
Tabla de Contenido.
Portada……………………………………………………………………………….i

Derecho de Autor………………………………………………………………….. ii

Hoja de Calificaciones…………………………………………………………….. iii

Dedicatoria………………………………………………………………………….. iv

Agradecimientos…………………………………………………………………… v

Tabla de Contenido………………………………………………………………... vi

Índice de Ilustraciones…………………………………………………………….. xvi

Resumen…………………………………………………………………………… xxi

Capítulo I. Introducción.
Introducción……………………………………………………......................... 1

Capítulo II. Marco teórico.

2.1 Introducción a SCADA…………………………………………………...... 5

2.1.1 Lazo abierto y cerrado………………………………………………...7

2.1.2 Definición general de SCADA………………………………………. 8

2.1.3 Unidades Maestras (Master Terminal Units)………………………. 10

2.1.3.1 Características de las unidades maestras………………….. 10

2.1.3.2 Hardware y Software………………………………………….. 12

2.1.3.2.1 Hardware en sistemas de supervisión: PLC y PC…. 13

2.1.3.2.2 Uso del PC como centro neural del MTU…………… 14

2.1.3.3 Adquisición de Datos………………………………………….. 16

vi
 2.1.3.3.1 Interrogación, informes por excepción, y

transmisiones iniciadas por RTU…..….……..…….. 16

2.1.3.3.2 Manejo de fallas de comunicaciones…………..….. 18

2.1.3.3.3 Los protocolos de comunicación…………………….. 19

2.1.3.3.4 Las redes de comunicación………………………….. 20

2.1.3.3.5 Procesadores de Comunicaciones Front End……… 21

2.1.3.3.6 Radio……………………………………………………. 22

2.1.3.3.7 Los circuitos telefónicos……………………………… 23

2.1.3.4 Gráfico de tendencias………………………………………… 23

2.3.4.1 Características…………………………………………… 24

2.1.3.4.2 Particularidades del almacenaje de datos………….. 24

2.1.3.5 Procesamiento de alarmas…………………………………… 25

2.1.3.5.1 Características………………………………………… 25

2.1.3.5.2 Chequeos………………………………………………. 26

2.1.3.6 Comunicaciones……………………………………………….. 26

2.1.4 Terminales Remotas (Remote Terminal Units)……………………. 27

2.1.4.1 Fundamentos………………………………………………… 27

2.1.4.2 Funcionalidad del hardware de un RTU…………………….. 29

2.1.4.3 Funcionalidad del Software………………………………….. 29

2.1.4.4 Operación Básica……………………………………………… 30

2.1.4.5 RTU pequeñas contra RTU grandes………………………… 30

2.1.4.6 Algunos tipos de RTU…………………………………………. 31

2.1.4.7 Estándares……………………………………………………... 31

vii
 2.1.4.8 PLC’s contra RTU’s……………………………………………. 32

2.2 Introducción a Linux……………………………………………………….. 33

2.2.1 ¿Qué es el software libre?............................................................. 33

2.2.2 Libre no significa gratis………………………………………………. 35

2.2.3 Historia…………………………………………………………………. 36

2.2.4 Las distribuciones de Linux…………………………………………. 38

2.2.5 ¿Qué es Una Distribución De LINUX?........................................... 39

2.2.5.1 Mandriva Linux…………………………………………………. 40

2.2.5.2 Ubuntu Linux…………………………………………………… 40

2.2.5.3 SuSe Linux……………………………………………………. 41

2.2.5.4 Debian gnu/LINUX…………………………………………….. 42

2.2.5.5 SLackWare LINUX…………………………………………….. 43

2.2.6 Aspectos técnicos…………………………………………………...... 43

2.2.6.1 Arquitecturas…………………………………………………….43

2.2.6.2 Jerarquía de directorios……………………………………….. 44

2.2.6.3 Kernel panic…………………………………………………….. 45

2.2.6.4 Lenguajes de programación………………………………….. 46

2.2.6.5 Portabilidad……………………………………………………... 46

2.2.6.6 Arquitectura de máquina virtual………………………………. 47

2.2.6.7 Formatos binarios soportados………………………………... 47

2.3 Introducción a Android………………………………………………………... 48

2.3.1 ¿Qué hace Android especial?............................................................ 48

2.3.2 Los orígenes……………………………………………………………… 50

viii
 2.3.3 Arquitectura de Android…………………………………………………. 51

2.3.3.1 EL núcleo de Linux……………………………………………………. 51

2.3.3.2 Runtime de Android……………………………………………………. 52

2.3.3.3 Librerías nativas……………………………………………………….. 52

2.3.3.4 Entorno de Aplicación………………………………………………… 53

2.3.3.5 Aplicaciones……………………………………………………………. 54

Capítulo III. Diseño del Sistema SCADA para equipos móviles

Android con Software Libre.
3.1 Introducción……………………………………………………………… 55

3.2 Arquitectura del Hardware……………………………………………... 56

3.3 Sensores………………………………………………………………….57

3.3.1 Tipos de Sensores…………………………………………………….. 57

3.3.1.1 Sensores Discretos………………………………………… 58

3.3.1.1.1 Sensor Switch Magnético………………………... 59

3.3.1.1.2 El Sensor de Movimiento………………………… 59

3.3.1.1.2.1 Funcionamiento de los detectores

de movimiento…………………..……. 60

3.3.1.1.2.2 Sensor de movimiento de

infrarrojos pasivo……….…………….. 60

3.3.1.1.2.3 Cobertura de un Sensor de

Movimiento……………………………. 61

3.3.1.1.2.4 Sensor de movimientos de

microondas……………………………. 61

3.3.1.1.2.5 Sensor dual de rayos infrarrojos

y de microondas………………...……. 62

ix
 3.3.1.1.2.6 Sensor de movimiento de
ultrasonidos…………………………… 62

3.4 Preactuador (relé, contactores, etc)…………………………………...62

3.4.1 Actuador…………………………………………………………… 63

3.4.1.1 Actuadores electrónicos………………………………………. 63

3.4.1.2 Actuadores hidráulicos………………………………………... 64

3.4.1.2.1 Cilindro hidráulico……………………………………. 64

3.4.1.2.2 Cilindro de presión dinámica……………………….. 64

3.4.1.2.3 Cilindro de Efecto simple……………………………. 64

3.4.1.2.4 Cilindro de Efecto doble…………………………….. 65

3.4.1.3 Actuadores eléctricos…………………………………………. 65

3.4.2 Tipos de Preactuadores…………………………………………. 66

3.4.2.1 Electroválvulas………………………………………………… 66

3.4.2.2 Arrancadores estáticos……………………………………….. 66

3.4.2.3 Equipos de control de motores eléctricos…………………... 66

3.4.2.4 Relés y contactores…………………………………………… 66

3.4.2.4.1 Relé……………………………………………………. 66

3.4.2.4.1.2 Estructura y funcionamiento………… 67

3.4.2.4.1.3 Tipos de relés………………………… 68

3.4.2.4.1.4 Ventajas del uso de relés……………. 70

3.5 Hardware RTU (Arduino)……………………………………………… 70

3.5.1 La conexión del Arduino con los sensores y preactuador…… 71

3.5.2 Conexión del Arduino con el módulo GPRS…………………... 72

3.5.2.1 Descripción del ArduinoShield GM862……………………… 72

x
 3.5.2.2 Descripción del Módulo GM862……………………………… 73

3.6 Hardware del MTU (PC)……………………………………………….. 74

3.7 Arquitectura del Software……………………………………………….77

3.7.1 Arquitectura de los RTU…………………………………………. 78

3.7.2 Funciones del RTU de sensores y preactuador………………. 80

3.7.2.1 Función Selector………………………………………………. 80

3.7.2.2 Función de preactuador; EncenderApagarLed……………. 80

3.7.2.3 Función SensorMovimiento..……………………………….... 82

3.7.2.4 Función SensorMagnetico..………………………………….. 82

3.7.3 Arquitectura de Software de la RTU GPRS…………………… 82

3.7.4 Arquitectura del Software MTU (Servidor)…………………….. 83

3.7.5 Arquitectura de la Aplicación RTU y HMI sobre Android…….. 84

3.7.5.1 Apariencia de la Interfaz visual…..………………………….. 84

3.7.4.2 La Lógica de la Aplicación……………………………………. 87

Capítulo IV. Implementación del Sistema SCADA para equipos

móviles con Android.
4.1 Introducción……………………………………………………………… 88

4.2 Programación de la RTU………………………………………………. 89

4.2.1 Software para la RTU……………………………………………. 89

4.2.2 Comunicación Serial entre el RTU (Módulo Arduino)

y MTU (Servidor)………………………………..……………….. 89

4.2.3 Implementación del Software para RTU……………………….. 91

xi
 4.2.3.1 Implementación del Programa en la RTU
de los Sensores y Preactuador(relé)…..………………… 91

4.2.3.1.1 Función Selector……………………………………. 92

4.2.3.1.2 Función EncenderApagarLed……………………...94

4.2.3.1.3 Función SensorMovimiento……………………….. 95

4.2.3.1.4 Función SensorMagnetico………………………… 98

4.2.3.1.5 Función Setup………………………………………. 99

4.2.3.1.6 Función loop………………………………………… 100

4.2.3.2 Implementación del programa de la RTU

con el modem GPRS…………………………………………….. 101

4.2.3.2.1 La función Selector…………………………………. 101

4.2.3.2.2 La función de EnvioSMS…………………………... 102

4.2.3.2.3 Función Setup………………………………………. 103

4.2.3.2.4 Función Loop……………………………………….. 104

4.3 Programación de las MTU……………………………………………... 105

4.3.1 Software para la MTU……………………………………………..105

4.3.2 Comunicación Serial entre la MTU (Servidor)

y la RTU (Módulo Arduino)………………………………………. 106

4.3.3 Comunicación Serial entre la MTU (Servidor)

y la RTU (Módulo GPRS)………………………………………... 108

4.3.4 Comunicación por Socket entre la MTU y la RTU

con la interfaz HMI…….…………………….…………………… 109

4.3.5 Implementación del Software para la MTU……………………..109

4.3.5.1 Programa del Servidor MTU………………………………. 110

4.3.5.2 Programa de Socket……………………………………….. 111

xii
 4.3.5.2.1 Evento que controla el preactuador……………….113

4.3.5.2.2 Evento que controla el Sensor de Movimiento….. 113

4.3.5.2.3 Evento que controla el Switch Magnético……….. 114

4.3.5.3 Programa de la comunicación entre la MTU

y la RTU de sensores y preactuador a través
de puerto serial USB……………………………………….. 115

4.3.5.3.1 Sensor de Movimiento…………………………….. 117

4.3.5.3.2 Sensor Switch Magnético…………………………..117

4.3.5.4 Base de Datos en la MTU…………………………………. 118

4.3.5.4.1 Eventos que son almacenados

en la Base de Datos…………………………………. 120

4.3.6 Implementación de la interfaz HMI en la MTU………………… 125

4.3.6.1 Aviso de Alertas…………………………………………..... 126

4.3.6.1.1 Alerta de Sensor de Movimiento………………….. 126

4.3.6.1.2 Alerta del Switch Magnético……………………..... 127

4.3.6.2 Eventos al presionar botones……………………………... 127

4.3.6.2.1 Activar o Desactivar Relé………………………… 127

4.3.6.2.2 Activar o Desactivar Sensor de Movimiento…….. 128

4.3.6.2.3 Activar o Desactivar el Switch

Magnético…………………………………………… 129

4.4 Implementación en la RTU e interfaz HMI en el

S.O.Android……………………………………………………………… 130

4.4.1 Implementación de la Interfaz HMI en Android……………….. 131

4.4.2 Implementación de la Lógica en la RTU con S.O. Android….. 132

4.4.2.1 La conexión con la MTU con S.O. Linux Ubuntu……….. 133

xiii
 4.4.2.1.1 Función onConnect..……………………………..... 137

4.4.2.1.2 Función onDisconnect..……………………………. 138

4.4.2.1.3 Función on...………………………………………… 139

4.4.2.2 El control del preactuador…………………………………. 144

4.4.2.3 Control del Sensor de Movimiento……………………….. 146

4.4.2.4 Sensor Switch Magnético………………………………..... 149

4.4.3 Base de Datos…………………………………………………………... 153

4.4.4 Botón SMS………………………………………………………………. 161

Capitulo V. Pruebas y Operación del Sistema SCADA para

equipos móviles Android con software Libre.
5.1 Introducción……………………………………………………………… 163

5.2 Comunicación del puerto Serial con los Sensores y

Preactuador del RTU………………………...…………………………. 163

5.2.1 Sensor de Movimiento…………………………………………… 164

5.2.2 Sensor Switch Magnético………………………………………... 165

5.2.3 Funcionamiento de los sensores al mismo tiempo…………… 166

5.2.4 Preactuador……………………………………………………….. 167

5.3 Pruebas entre la interfaz HMI de la MTU y la RTU…………………. 167

5.3.1 Comunicación entre la interfaz HMI de la MTU

con la RTU de los sensores y preactuador..……………………. 167

5.4 Comunicación entre la RTU con interfaz HMI (Android)

con las RTU de los sensores y preactuador
a través de la MTU……………………………………………………… 170

5.4.1 Comunicación entre la RTU con interfaz HMI (Android)

y la MTU (Servidor Linux Ubuntu)…………………...…………… 170

xiv
 5.4.2 Comunicación de la RTU con interfaz HMI y la RTU de los
sensores y preactuador……………………………………………. 172

5.5 Prueba general del sistema SCADA con el acceso por medio
de la RTU con interfaz HMI (Android)……………………………...……… 174

Capítulo VI. Conclusiones.

Conclusiones…………………………………………………………………..... 177

Referencias Bibliográficas................................................................... 180

xv
Índice de Ilustraciones.

Capítulo II.
Figura 2 – 1 Arquitectura de Android………………………............................51

Capítulo III.
Figura 3 – 1 Arquitectura del Hardware………………………………………. 56

Figura 3 – 2 Sensores de Posición: de Bola, de Ruleta y Ajustable………. 58

Figura 3 – 3 Sensor Switch Magnético………………………………………... 59

Figura 3 – 4 Cobertura del Sensor de Movimiento……..……………………. 61

Figura 3 – 5 Estructura de un Relé………………….………………………… 67

Figura 3 – 6 Arduino Uno…………………….……………………………….... 70

Figura 3 – 7 Arduino GM862 Shield con módulo GM862…………………… 74

Figure 3 – 8 Arquitectura de Software del Sensor de Movimiento………… 78

Figure 3 – 9 Arquitectura de Software del Sensor de Switch

Magnético……………………………......................................... 79

Figura 3 – 10 Arquitectura de Software del Preactuador………….…………. 80

Figura 3 – 11 Arquitectura de Software de la Función Selector….…………. 81

Figura 3 – 12 Arquitectura de Software Módulo GPRS………………………. 83

Figura 3 – 13 Arquitectura de Software MTU………………………………….. 85

Figura 3 – 14 Arquitectura de la aplicación Android………………………….. 86

Capítulo IV.
Figura 4 – 1 Serial Arduino……………….……………………………………. 91

Figura 4 – 2 Esquema del circuito RTU Arduino de los sensores

y preactuador……………………………………………………… 96

Figura 4 – 3 Función Selector en el módulo GPRS…………………………. 102

xvi
Figura 4 – 4 Función EnvioSMS en el módulo GPRS………………………. 103

Figura 4 – 5 Función Setup del módulo GPRS………………………………. 104

Figura 4 – 6 Función Loop en módulo GPRS………………………………... 104

Figura 4 – 7 Programa de comunicación del puerto Serial

entre la MTU y la RTU…………………………………………… 107

Figura 4 – 8 Programa de comunicación del puerto Serial

entre la MTU y la RTU del módulo GPRS…………………….. 108

Figura 4 – 9 Crear programa Servidor para la MTU con Node.js….………. 110

Figura 4 – 10 Configuración del Servidor MTU (Servidor web)…...…………. 111

Figura 4 – 11 Programa de eventos por socket……………………………..… 112

Figura 4 – 12 Parte del programa de la MTU, de la recepción

de señales del RTU de los sensores
y preactuador (relé)……………….……………………………… 116

Figura 4 – 13 Funciones de Base de Datos……………………………………. 120

Figura 4 – 14 Eventos del preactuador emitidos por la RTU a la MTU……... 121

Figura 4 – 15 Evento del sensor de movimiento emitido

por la RTU a la MTU……………………………………………... 122

Figura 4 – 16 Evento del sensor switch magnético emitido

por la RTU a la MTU……………………………………………... 123

Figura 4 – 17 Creación de nueva fila en la tabla Monitor y envío

de los datos a la RTU con interfaz HMI……………….............. 124

Figura 4 – 18 Formato de la página web…………………..…………………… 125

Figura 4 – 19 Evento de alarma de sensores RTU…………………………… 126

xvii
Figura 4 – 20 Eventos al presionar botones en la HMI…….………………... 128

Figura 4 – 21 Body de la página web, interfaz HMI…….…………………….. 129

Figura 4 – 22 Diseño de la aplicación HMI en Android……..………………… 131

Figura 4 – 23 Variables para la conexión entre la MTU

y la RTU con interfaz HMI………………………………………. 133

Figura 4 – 24 Variables que enlazan la parte lógica con

la interfaz HMI y los intentos…………………………..………… 134

Figura 4 – 25 Función onClick a través del botón Conectar...……………….. 135

Figura 4 – 26 Sub-funciones de la función Connect

de la librería SocketIO…………………………………………… 136

Figura 4 – 27 Programa Conectado.java……….……………………………… 137

Figura 4 – 28 Programa Desconectado.java…………………..………………. 138

Figura 4 – 29 Eventos a la espera, a través del Socket…………..………..… 139

Figura 4 – 30 Programa SensorMovimiento.java…….……………………….. 140

Figura 4 – 31 Programa SensorMagnetico.java…………..…………………… 141

Figura 4 – 32 Evento del preactuador que cambia

el estado de la imagen…………………………………………… 142

Figura 4 – 33 Evento del sensor movimiento que cambia

el estado de la imagen…………………………………………… 143

Figura 4 – 34 Evento del sensor switch magnético que

cambia el estado dela imagen…………………………………... 144

xviii
Figura 4 – 35 Programa para botón Encender, para la RTU
asociado al relé…………………………………………………… 145

Figura 4 – 36 Programa para botón Apagar, para la RTU

asociado al relé…………………………………………………… 146

Figura 4 – 37 Programa para botón Activar, para la RTU

asociado al sensor de Movimiento…….……………………….. 147

Figura 4 – 38 Programa para botón Desactivar, para la RTU

asociado al sensor de Movimiento………………….………….. 148

Figura 4 – 39 Programa para botón Activar, para la RTU

asociado al Sensor Switch Magnético……………….………… 150

Figura 4 – 40 Programa para botón Desactivar, para la RTU

asociado al Sensor Switch Magnético……...…………..……… 151

Figura 4 – 41 Directorios de la Aplicación en Android………………………... 152

Figura 4 – 42 Rescate de la base de datos proveniente de la MTU………… 154

Figura 4 – 43 Interfaz visual de la Base de Datos…………………………….. 159

Capítulo V.

Figura 5 – 1 Luces predeterminadas del RTU de los sensores

y preactuador……………………………………………………… 164

Figura 5 – 2 Consola Serial Arduino IDE………………………………..……. 164

Figura 5 – 3 Mensaje del Sensor de Movimiento…………………….……… 165

Figura 5 – 4 Separación de módulos Sensor Switch Magnético…………… 165

Figura 5 – 5 Mensaje del Sensor Switch Magnético……..………………….. 166

xix
Figura 5 – 6 Mensaje de los Sensores……………..…………………………. 166

Figura 5 – 7 Permiso de puerto USB……………..…………………………… 168

Figura 5 – 8 Servidor Node.js…………….……………………………………. 168

Figura 5 – 9 Interfaz HMI de la MTU…………………………….……………. 169

Figura 5 – 10 Mensaje de alarma Magnética Activada………………....……. 169

Figura 5 – 11 Conexión por IP a la MTU………………………………….……. 171

Figura 5 – 12 Mensaje de conexión de la interfaz HMI Android de la MTU.. 171

Figura 5 – 13 Mensaje de desconexión de la interfaz HMI Android

de la MTU…………………………………………………………. 172

Figura 5 – 14 Mensaje de Activación de Luz por parte del relé……………... 172

Figura 5 – 15 Aviso de alarma de movimiento Activa,

en interfaz HMI de Android………………………………...……. 173

Figura 5 – 16 Aviso de alarma de switch magnético Activa,

en interfaz HMI de Android……………..……………………….. 173

Figura 5 – 17 Activar o Desactivar alarmas en interfaz HMI Android……….. 174

Figura 5 – 18 Conexión de la Arquitectura de Hardware……….……………. 174

xx
 TÍTULO: Diseño e implementación del sistema SCADA para equipos
móviles Android con software libre.

CLASIFICACIÓN TEMÁTICA: SCADA: Supervisión de sistemas de

control; Sistemas operativos; Computadores – Programación; Software
libre.

AUTOR: Castillo Castillo, Tomás Marcelo

CARRERA: Ingeniería de Ejecución en Electricidad
PROFESOR GUÍA: Valenzuela Ponce, Manuel Alexis
AÑO: 2012

CÓDIGO UBICACIÓN BIBLIOTECA: 2012 / E / 089

RESUMEN
En este trabajo se concibe, diseña, implementa y se prueba un sistema
SCADA para sistema operativo Android, desarrollado por el propio autor de
esta memoria de título.
El proyecto se logra a través de concebir, diseñar e implementar un
Hardware específico para el monitoreo y control de un sistema de vigilancia
remota. Luego mediante Software libre, se desarrollan los programas
necesarios para levantar el sistema SCADA. Tanto el Hardware y Software
es desarrollado por el autor.
Se comienza con un marco teórico respecto a SCADA, Linux y finalizando
con el sistema operativo Android.
Se continúa con la creación del diseño para el sistema SCADA, por medio
de arquitectura de Hardware y Software, listando los componentes
necesarios para tal objetivo.
Se crean los programas necesarios para cada componente del sistema
SCADA. Programas para la RTU y para la MTU, especialmente se
implementa el programa (aplicación) en el sistema operativo Android como
una extensión móvil del sistema SCADA.

xxi
Capítulo I. Introducción.

Cada vez más las empresas necesitan de sistemas de monitoreo a larga

distancia o simplemente en lugares de difícil acceso. Para este fin se crean los
sistemas SCADA, un sistema que supervisa el correcto funcionamiento de la
planta.

Con la llegada de los dispositivos móviles Android, la tarea se retira de la sala

de monitoreo y se accede a la supervisión en cualquier lugar de la industria,
incluso más, en cualquier sitio donde se pueda acceder a la red local de la planta
hasta en la comodidad del hogar.

Los sistemas SCADA originalmente se diseñaron para cubrir las necesidades de

un sistema de control centralizado, sobre procesos o complejos industriales
distribuidos sobre áreas geográficas muy extensas. Tal es así que en la definición
clásica de un sistema SCADA se hace referencia a esta característica. Hoy en
día, con el desarrollo de las redes digitales, la definición se tiene que modificar
para incluir esta nueva forma de conectividad [1].

Los sistemas de interfaz entre usuario y planta basados en paneles de control

repletos de indicadores luminosos, instrumentos de medida y pulsadores, están
siendo sustituidos por sistemas digitales que implementan el panel sobre la
pantalla de un ordenador.

El control directo lo realizan los controladores autónomos digitales y/o autómatas

programables y están conectados a un ordenador que realiza las funciones de
diálogo con el operador, tratamiento de la información y control de la producción,
utilizando el SCADA [2].

El monitoreo de la central de supervisión se traslada a los dispositivos móviles,

conocidos como Tablet con S.O. Android u otros.

1
En los últimos años los teléfonos móviles han experimentado una gran evolución,
desde los primeros terminales, grandes y pesados, pensados sólo para hablar
por teléfono en cualquier parte, a los últimos modelos, con los que el término
“medio de comunicación” se queda bastante pequeño.

Es así como nace Android. Android es un sistema operativo y una plataforma

software, basado en Linux para teléfonos móviles. Además, también usan este
sistema operativo (aunque no es muy habitual), tablets, netbooks, reproductores
de música e incluso PC’s. Android permite programar en un entorno de trabajo
(framework) de Java, aplicaciones sobre una máquina virtual Dalvik (una
variación de la máquina de Java con compilación en tiempo de ejecución).
Además, lo que le diferencia de otros sistemas operativos, es que cualquier
persona que sepa programar puede crear nuevas aplicaciones, widgets, o
incluso, modificar el propio sistema operativo, dado que Android es de código
libre, por lo que si se conoce programar en lenguaje Java, va a ser muy fácil
comenzar a programar en esta plataforma [3].

La implementación del SCADA en los dispositivos con S.O. Android abre las
puertas para que el usuario se pueda trasladar por cualquier lugar del recinto de
trabajo, posibilitando el control, no solo en la central maestra, y manteniendo en
todo momento la supervisión de la planta industrial.

En este trabajo se plantea la problemática de la supervisión de un proceso

industrial para el monitoreo y control del sistema por vigilancia remota. Con la
ayuda de una Tablet con sistema operativo Android, se implementa un programa
para el monitoreo y control del sistema por vigilancia remota de un dispositivo
(relé) por medio de la Tablet.

Con lo expuesto se realiza un sistema SCADA con Software libre y Hardware

armado en nuestro país.

2
Por lo tanto, se concibe, diseña e implementa el Hardware y el Software para el
sistema SCADA. Al reunir las partes de Hardware necesario para el proyecto.
Como también la creación del programa para el microcontrolador programable
(Arduino). El software para la central de control (MTU) con S.O. Linux Ubuntu.
Finalmente, el desarrollo del software para equipos con S.O. Android.

El sistema SCADA consiste de tres partes, una en donde existe la interfaz entre
los sensores y un dispositivo para su control y comunicación, otra en la que se
procesa la información recibida por los sensores (MTU), implementada en un
PC servidor y finalmente los dispositivos acceso a la información que se
encuentra en la central de proceso, por medio de Smartphone, Tablet con S.O.
Android con conexión a la red WiFi o a través de Internet.

El trabajo comienza en el Capítulo II con una descripción de SCADA, su

ideología, sus partes y definiciones. Se señala lo que es la MTU (Master
Terminal Unit) y la RTU (Remote Terminal Units). Se continúa con el sistema
operativo que alberga a la MTU, se escoge el S.O. Linux Ubuntu, en donde se
utiliza una nueva forma de crear un servidor web con código JavaScript en el
servidor. Finalizando con una introducción al sistema operativo Android, que tiene
semejanza con Linux, y su entorno de desarrollo para la plataforma Android.

En el Capítulo III se presenta el diseño a implementar en el proyecto SCADA. Al

presentar diagramas en bloques en forma lógica que dan vida al programa para
la MTU, como también para las RTU’s y la aplicación para el S.O. Android. Se
presenta la arquitectura de Software para cada RTU y para la MTU. También se
hace la descripción de la arquitectura de Hardware del sistema SCADA. Se
muestra el Hardware utilizado en el proyecto, dando sus características
técnicas.

3
Se continua con el Capítulo IV, aquí se implementa la arquitectura de Software
en los dispositivos, tanto en la RTU como en la MTU. En sí, se crean los
programas necesarios para el desarrollo del sistema SCADA. Se conciben las
funciones necesarias para cada módulo RTU (Arduino), como también las
funciones para la MTU (Servidor Linux Ubuntu) y las funciones para la RTU con
interfaz HMI (Human Machine Interface) con sistema operativo Android.

En el Capítulo V se nuestra los resultados de las pruebas de la implementación

del desarrollo del sistema SCADA.

Se finaliza con las conclusiones del trabajo.

4
CAPÍTULO II. Marco Teórico.

2.1 Introducción a SCADA

SCADA es un acrónimo por “Supervisory Control And Data Acquisition” (Control

Supervisor y Adquisición de Datos). Los sistemas SCADA utilizan la computadora
y tecnologías de comunicación para automatizar el monitoreo y control de
procesos industriales, para un sistema de control centralizado. Estos sistemas
son partes integrales de la mayoría de los ambientes industriales complejos o
muy geográficamente dispersos, ya que pueden recoger la información de una
gran cantidad de fuentes muy rápidamente, y la presentan a un operador en una
forma amigable. Los sistemas SCADA mejoran la eficacia del proceso de
monitoreo y control proporcionando la información oportuna para poder tomar
decisiones operacionales apropiadas.

Los primeros SCADA eran simplemente sistemas de telemetría, que

proporcionaban reportes periódicos de las condiciones de campo vigilando las
señales que representaban medidas y/o condiciones de estado en ubicaciones
de campo remotas. Estos sistemas ofrecían capacidades muy simples de
monitoreo y control, sin proveer funciones de aplicación alguna. La visión del
operador en el proceso estaba basada en los contadores y las lámparas detrás
de tableros llenos de indicadores. Mientras la tecnología se desarrollaba, las
computadoras asumieron el papel de manejar la recolección de datos,
disponiendo comandos de control, y una nueva función, presentación de la
información sobre una pantalla de video. Las computadoras agregaron la
capacidad de programar el sistema para realizar funciones de control más
complejas.

5
Los primeros sistemas automatizados SCADA fueron altamente modificados con
programas de aplicación específicos para atender a requisitos de algún proyecto
particular. Como ingenieros de varias industrias asistieron al diseño de estos
sistemas, su percepción de SCADA adquirió las características de su propia
industria. Proveedores de sistemas de software SCADA, deseando reutilizar su
trabajo previo sobre los nuevos proyectos, perpetuaron esta imagen de industria
específicos por su propia visión de los ambientes de control con los cuales tenían
experiencia. Solamente cuando nuevos proyectos requirieron funciones y
aplicaciones adicionales, hizo que los desarrolladores de sistemas SCADA
tuvieran la oportunidad de desarrollar experiencia en otras industrias.

Hoy, los proveedores de SCADA están diseñando sistemas que son pensados
para resolver las necesidades de muchas industrias, con módulos de software
industriales específicos disponibles para proporcionar las capacidades
requeridas comúnmente. No es inusual encontrar software SCADA
comercialmente disponible adaptado para procesamiento de papel y celulosa,
industrias de aceite y gas, hidroeléctricas, gerenciamiento y provisión de agua,
control de fluidos, etc. Puesto que los proveedores de SCADA aún tienen
tendencia en favor de algunas industrias sobre otras, los compradores de estos
sistemas a menudo dependen del proveedor para una comprensiva solución a su
requisito, y generalmente procurar seleccionar un vendedor que pueda ofrecer
una completa solución con un producto estándar que esté apuntado hacia las
necesidades específicas del usuario final. Si selecciona a un vendedor con
experiencia limitada en la industria del comprador, el comprador debe estar
preparado para asistir al esfuerzo de ingeniería necesario para desarrollar el
conocimiento adicional de la industria requerido por el vendedor para poner con
éxito el sistema en ejecución.

6
Para alcanzar un nivel aceptable de tolerancia de fallas con estos sistemas, es
común tener computadoras SCADA redundantes operando en paralelo en el
centro primario del control y un sistema de reserva del mismo situado en un área
geográficamente distante. Esta arquitectura proporciona la transferencia
automática de la responsabilidad del control de cualquier ordenador que pueda
llegar a ser inasequible por cualquier razón, a una computadora de reserva en
línea, sin interrupción significativa de las operaciones [1].

2.1.1 Lazo abierto y cerrado.

Existen dos tipos de sistemas, principalmente: los de lazo abierto o no

realimentados y los de lazo cerrado o realimentados. Los sistemas de lazo
cerrado funcionan de tal manera que hacen que la salida vuelva al principio para
que se analice la diferencia con un valor de referencia y en una segunda opción
la salida se vaya ajustando, así hasta que el error sea cero. Cualquier sistema
que tenga como objeto controlar una cantidad, como por ejemplo: temperatura,
velocidad, presión, caudal, fuerza, posición, etc., son normalmente de lazo
cerrado. Los sistemas de lazo abierto no se comparan a la variable controlada
con una entrada de referencia. Cada ajuste de entrada determina una posición
de funcionamiento fijo en los elementos de control (por ejemplo con
temporizadores).

Es así que, la realimentación es un mecanismo o proceso cuya señal se mueve

dentro de un sistema y vuelve al principio de éste como en un bucle, que se llama
"bucle de realimentación". En un sistema de control (que tiene entradas y
salidas), parte de la señal de salida vuelve de nuevo al sistema como parte de su
entrada; a esto se le llama "realimentación" o retroalimentación.

7
La realimentación comprende todas aquellas soluciones de aplicación que hacen
referencia a la captura de información de un proceso o planta, no necesariamente
industrial, para que, con esta información, sea posible realizar una serie de
análisis o estudios con los que se pueden obtener valiosos indicadores que
permitan una retroalimentación sobre un operador o sobre el propio proceso,
tales como:

• Indicadores sin retroalimentación inherente (no afectan al proceso, sólo

al operador):
• Estado actual del proceso. Valores instantáneos;
• Desviación o deriva del proceso. Evolución histórica y acumulada;
• Indicadores con retroalimentación inherente (afectan al proceso,
después al operador):
• Generación de alarmas;
• HMI, Human Machine Interface (Interfaz Hombre Máquina);
• Toma de decisiones:
• Mediante operatoria humana;
• Automática (mediante la utilización de sistemas basados en el
conocimiento o sistemas expertos) [4].

2.1.2 Definición general de SCADA.

SCADA es un sistema industrial de mediciones y control que consiste en una

computadora principal o “master” (generalmente llamada Estación Maestra,
“Master Terminal Unit” o MTU); una o más unidades control obteniendo datos de
campo (generalmente llamadas estaciones remotas, “Remote Terminal Units,” o
RTU); y una colección de software estándar y/o a la medida usado para
monitorear y controlar remotamente dispositivos de campo. Los sistemas SCADA
contemporáneos exhiben predominantemente características de control a lazo

8
abierto y utilizan comunicaciones generalmente locales (dentro de la planta) o
remotas (fuera de la planta), aunque algunos elementos de control a lazo cerrado
y/o de comunicaciones de corta distancia pueden también estar presentes.

Sistemas similares a un sistema SCADA son vistos rutinariamente en fábricas,

plantas de tratamiento, etc. Éstos son llamados a menudo como Sistemas de
Control Distribuidos (DCS – “Distributed Control Systems”). Tienen funciones
similares a los sistemas SCADA, pero las unidades de colección o de control de
datos de campo se establecen generalmente dentro de un área confinada.

Las comunicaciones pueden ser por vía de una red de área local (LAN), y son
normalmente confiables y de alta velocidad. Un sistema DCS emplea
generalmente cantidades significativas de control a lazo cerrado.

Un sistema SCADA por otra parte, generalmente cubre áreas geográficas más
grandes, y normalmente depende de una variedad de sistemas de comunicación
menos confiables que una LAN. El control a lazo cerrado en esta situación será
menos deseable. Un sistema SCADA se utiliza para vigilar y controlar la planta
industrial o el equipamiento. El control puede ser automático, o iniciado por
comandos de operador. La adquisición de datos es lograda en primer lugar por
las RTU que exploran las entradas de información de campo conectadas con
ellos (pueden también ser usados PLC (“Programmable Logic Controllers”).

Esto se hace generalmente a intervalos muy cortos. La MTU entonces explora

las RTU generalmente con una frecuencia menor. Los datos se procesan para
detectar condiciones de alarma, y si una alarma estuviera presente, sería
catalogada y visualizada en listas especiales de alarmas. Los datos pueden ser
de tres tipos principales:

• Datos analógicos (por ejemplo números reales) que quizás sean

presentados en gráficos.

9
 • Datos digitales (on/off) que pueden tener alarmas asociadas a un
estado o al otro.
• Datos de pulsos (por ejemplo conteo de revoluciones de un medidor)
que serán normalmente contabilizados o acumulados.

La interfaz primaria al operador es una pantalla que muestra una representación

de la planta o del equipamiento en forma gráfica. Los datos vivos (dispositivos)
se muestran como dibujos o esquemas en primer plano (foreground) sobre un
fondo estático (background). Mientras los datos cambian en campo, el foreground
es actualizado (una válvula se puede mostrar como abierta o cerrada, etc.). Los
datos analógicos se pueden mostrar como números, o gráficamente (esquema
de un tanque con su nivel de líquido almacenado). El sistema puede tener
muchas de tales pantallas, y el operador puede seleccionar los más relevantes
en cualquier momento [5].

2.1.3 Unidades Maestras (Master Terminal Units).

La parte más visible de un sistema SCADA es la estación central o MTU. Éste es

el "centro neurálgico" del sistema, y es el componente del cual el personal de
operaciones se valdrá para ver la mayoría de la planta. Una MTU a veces se
llama HMI –“Human Machine Interface”, interfaz ser humano máquina [5].

2.1.3.1 Características de las unidades maestras.

Características de las unidades maestras.

Todas las MTU de SCADA deben presentar una serie de características, algunas
de estas son las siguientes:

• Adquisición de datos: Recolección de datos de las unidades terminales

remotas (RTU)

10
• Gráficos de tendencia: Salvar los datos en una base de datos, y
ponerlos a disposición de los operadores en forma de gráficos.
• Procesamiento de Alarmas: Analizar los datos recogidos de las RTU
para ver si han ocurrido condiciones anormales, y alertar a personal de
operaciones sobre las mismas.
• Control: Control a Lazo Cerrado, e iniciados por operador.
• Visualizaciones: Gráficos del equipamiento actualizado para reflejar
datos del campo.
• Informes: La mayoría de los sistemas SCADA tienen un ordenador
dedicado a la producción de reportes conectado en red (LAN o similar)
con el principal.
• Mantenimiento del Sistema Mirror: Se debe mantener un sistema
idéntico con la capacidad segura de asumir el control inmediatamente
sí la principal falla.
• Interfaces con otros sistemas: Transferencia de datos hacia y desde
otros sistemas corporativos para, por ejemplo, el procesamiento de
órdenes de trabajo, de compra, la actualización de bases de datos, etc.
• Seguridad: Control de acceso a los distintos componentes del sistema.
• Administración de la red: Monitoreo de la red de comunicaciones.
• Administración de la Base de datos: Agregar nuevas estaciones,
puntos, gráficos, puntos de cambio de alarmas, y en general,
reconfigurar el sistema.
• Aplicaciones especiales: Casi todos los sistemas SCADA tendrán
cierto software de aplicación especial, asociado generalmente al
monitoreo y al control de la planta específica en la cual se está
utilizando. Recordemos que las necesidades de las diferentes
industrias pueden ser muy variadas.

11
 • Sistemas expertos, sistemas de modelado: Los más avanzados
pueden incluir sistemas expertos incorporados, o capacidad de
modelado de datos [5].

2.1.3.2 Hardware y Software.

Las MTU de sistemas SCADA se pueden implementar en la mayoría de las

plataformas existentes. Los primeros sistemas existentes tendieron a ser
propietarios y muy especializados, y donde fueron utilizados sistemas operativos
de fines generales, tendieron a ser modificados ampliamente. Esto debido a que
los requisitos de SCADA superaban los límites de la tecnología disponible en el
momento y por razones de desempeño ya que tendieron a proporcionar sistemas
gráficos por encargo, a usar bases de datos en tiempo real (con gran parte de la
base de datos en memoria), y a menudo el hardware debió ser modificado para
estos requisitos particulares. La serie Digital Equipment Corporation PDP11 y el
sistema operativo RSX11M eran quizás la plataforma más común en los SCADA
del siglo pasado. Posteriormente, Unix comenzó a ser el sistema operativo de
más frecuente elección. Mientras la potencia de la PC aumentaba, los sistemas
Intel llegaron a ser muy comunes, aunque las plataformas DEC Alfa, y otras
estaciones de trabajo de fines elevados estén aún en uso. En épocas recientes
Windows NT ha alcanzado alta aceptación dentro de la comunidad SCADA,
aunque los sistemas muy grandes siguen siendo en la mayor parte de los casos
estaciones de trabajo Unix (QNX o Solaris), las cuales son más veloces en sus
respuestas. Actualmente la industria se está desarrollando claramente hacia
estándares abiertos: ODBC, INTEL PC, sistemas estándares de gráficos, e
ínterconectividad a sistemas de computación corrientes. En años recientes ha
aparecido en el mercado un importante número de sistemas SCADA sobre
plataformas INTEL PC, ya que éstas están aumentando rápidamente su
capacidad y desempeño. Ejemplos de ellos son Citect, FIX de Intellution,
KEPware y Wonderware [5].

12
2.1.3.2.1 Hardware en sistemas de supervisión: PLC y PC.

El hecho es que las tareas automatizadas de control, visualización y computación

pueden ser efectuadas por los PLC (conectados en red mediante los módulos
adecuados) mejor que con sistemas exclusivos de control basados en PC. Lo
que finalmente es práctico, no obstante, depende de un gran número de factores
y la mayoría deben ser considerados individualmente para cada proyecto de
automatización. Así, por ejemplo, los actuales conocimientos y preferencias del
usuario pueden jugar un mayor papel que la pura potencia del ordenador. Los
factores cruciales, no obstante, son los atributos de capacidad en tiempo real y
las propiedades de seguridad que hasta ahora han sido fuertemente asociadas
con el PLC, aunque el PC también puede disponer de la característica de
capacidad en tiempo real. Un sistema de control es inconcebible sin capacidad
en tiempo real. Es común en sistemas de control por ordenador tener que elegir,
según las características del sistema a supervisar, entre el PLC o el PC. Se debe
elegir aquel hardware que mejor se adapte a las necesidades del sistema a
supervisar. Los controladores lógicos programables, en la mayoría de los casos,
están diseñados específicamente para ser empleados en ambientes industriales
exigentes y han sido continuamente desarrollados de forma que sus sistemas
operativos en tiempo real representan su mayor virtud. Ellos son y seguirán
siendo, no obstante, la primera elección para todo control de tareas críticas o
extremas por su rendimiento y simpleza, en los que un PC podría estar
simplemente "sobrecargado" debido al trabajo que le pueden suponer otras
tareas de ámbito común, como la gestión y visualización de datos, accesos a
periféricos, bases de datos, etc. Si, además del control de tareas, se necesita un
procesamiento de datos, trabajo en red o visualización (una aplicación SCADA),
un sistema basado en PC debe ser tomado en consideración. En cuanto a
sistemas operativos, Windows NT, por ejemplo, no es estrictamente un sistema
operativo en tiempo real como el de un PLC, pero puede actuar de forma

13
suficientemente rápida para aplicaciones "suaves" en tiempo real, gracias a su
arquitectura de micro-kernel.

2.1.3.2.2 Uso del PC como centro neural del MTU.

En casa y en la oficina, el ordenador personal continúa con su progreso. El PC

se ha establecido en un gran número de campos. Los componentes hardware y
software están siendo cada vez más potentes y más rentables. Es lógico, por
tanto, que la industria quiera tomar provecho de este hecho, para reducir costos
y/o incrementar la productividad. Ciertas tareas industriales están actualmente en
manos de los ordenadores desde hace tiempo: desde emplear la tecnología
Windows cuando se manejan pedidos y/o se ajustan parámetros de maquinaria
hasta preparar o visualizar datos prácticamente de cualquier tipo. No hay que
sorprenderse entonces, que los especialistas en automatización y los usuarios
estén pensando ahora en qué forma se pueden transferir al PC otras tareas, para
poder llegar a un mayor ahorro. Más recientemente un gran número de
simuladores de PLC (controladores lógicos programables) por software ha
aparecido en el mercado, que están ayudando a transferir el control de tareas al
disco duro y presentan una automatización más efectiva en costos en una simple
pieza de hardware (el PC). Los computadores personales o PC tienen múltiples
matices en cuanto a temas, arquitectura y forma de utilizarse, entre ellos
tenemos: (1) Supervisión de Procesos, en el que se utilizan fundamentalmente
los recursos del procesador para mostrar dinámicamente el funcionamiento de
un proceso, (2) El control, en el que el procesador, a través de interfaces de
entradas y salidas específicas permite manipular directamente el proceso y (3) El
sistema SCADA, Control Supervisado y Adquisición de datos, en el que se
realizan las dos funciones anteriores para sistemas relativamente complejos en
los que generalmente está involucrada las comunicaciones. Cada una de estas
tres categorías puede aplicarse en cualquier actividad sea industrial o
manufacturera, tanto en el laboratorio como en la planta. Para el control se

14
utilizan diversos tipos de computadores por lo que hay interfaces para las
diversas arquitecturas internas, de las que el Bus PCI es el más utilizado en la
actualidad. En la industria es el bus COMPACT PCI el equivalente más
adecuado.

Las computadoras industriales están preparadas para trabajar en los ambientes

duros de la industria.

Se ha discutido mucho el uso de los computadores haciendo la función de control,

felizmente la tecnología ha avanzado en este sentido y la tendencia es hacia
sistemas operativos más robustos, mientras tanto existen alternativas como la de
LabVIEW Real time de Nacional Instruments, en el que la interfaz de entradas y
salidas en el micro-computador alberga un sistema operativo de tiempo real en
el que se ejecuta el programa de control, de esta forma se tienen disponibles las
ventajas de Windows y el control no se pierde aunque el sistema operativo
(Windows) colapse.

Los sistemas SCADA están constituidos por el Hardware, que generalmente es

una red de controladores y estaciones remotas de adquisición de datos. El
corazón de un sistema SCADA está en el "Software SCADA", que es el
encargado de supervisar y controlar el Proceso a través del Hardware de control,
generalmente el software SCADA trabaja conjuntamente con un PLC o una red
de PLC. Este software permite supervisar el proceso desde un microcomputador,
así como realizar las acciones de control a través del PLC, controlador o sistema
de control. En el mercado existen varios programas que realizan esta función.

Tan importante como el 'Hardware' es el 'Software' especializado para el control

y la supervisión de procesos. Los niveles de 'software' podrían ser escalonados
en:

(1) 'Software' de manejo a nivel de registros para las interfaces, (2) programas de
usuario en lenguajes de alto nivel, utilizando rutinas suministradas por los
fabricantes de 'hardware', (3) Sistemas de desarrollo y generadores de código

15
fuente dedicados a la adquisición y procesamiento de data así como el control y
supervisión de procesos tal como LabVIEW antes mencionado, (4) 'Paquetes' de
control y supervisión de procesos, que permiten administrar el 'hardware' de
control de procesos basados en controladores lógicos programables (PLC),
supervisar los procesos y administrar redes de microcomputadores y de
controladores lógicos programables. La mayoría de Software de alta performance
para la Automatización Industrial se ejecuta bajo Microsoft Windows NT, 98 y
2000. Deben proveer una interfaz gráfica para su proceso, ya sea como Interfaz
Humano Máquina (HMI: “Human Machine Interface”), o como un sistema de
Supervisión, Control y Adquisición de Datos (SCADA) [5].

2.1.3.3 Adquisición de Datos.

La función de adquisición de datos de un sistema SCADA es obviamente una

función preponderante. Hay un número de características asociadas a la
adquisición de datos [5].

2.1.3.3.1 Interrogación, informes por excepción, y

transmisiones iniciadas por RTU.

Los primeros sistemas SCADA tenían RTU que no se enviaban directamente la

información al sistema central, debía utilizar el sistema central un escaneo
(“polling”) para tener acceso a sus datos. La unidad maestra controla todas las
comunicaciones, y una RTU nunca se comunicaba a menos que fuera
escaneada. La unidad maestra realizaba un polling a cada RTU alternadamente,
pidiendo que le envíen sus datos. La RTU haría lo necesario para recuperar los
últimos datos de sus instrumentos (además de la conversión de señales
analógicas a digitales) y después enviaba la petición a la unidad maestra. Al ser
controladas las comunicaciones por la unidad maestra, éste registraba los datos
con la hora de recepción, muchas veces muy distinta a la hora en que fueron

16
generados. Algunas variaciones en esto se han introducido para mejorar la
eficacia de comunicaciones. La unidad maestra podía solicitar solamente algunos
de los datos de una RTU en cada escaneo principal, y extraería los datos menos
importantes en una segundo escaneo disparado con una frecuencia más baja.
Con las RTU más inteligentes, se podían explorar independientemente sus
entradas de información, sobre una base continua, e incluso agrupar por hora los
datos. La unidad maestra entonces escaneaba a la RTU si tiene cualquier cosa
para informar. Si nada hubiera cambiado desde la vez última, la RTU enviaba sin
novedad, y la unidad maestra se movería a la RTU siguiente. Para asegurarse
de que un cierto acontecimiento no fue revisado, ocasionalmente la unidad
maestra haría una escaneo completo como una revisión completa del sistema.

Está claro lo que implica cuando una entrada de información digital ha cambiado,
pero el uso del informe por excepción con valores analógicos significa que un
cierto cambio del umbral está definido (típicamente 1-2%), y sobre éste se ha
producido algún cambio. El informe por excepción puede reducir dramáticamente
el tráfico de comunicaciones, siempre y cuando los datos estén cambiando en
forma relativamente lenta. Cuando se están midiendo parámetros altamente
volátiles puede aumentar drásticamente el tráfico. En este caso una solución es
poner estos parámetros volátiles en una encuesta rutinaria, sacrificando una
cierta exactitud en la hora de registro en pos de la reducción del tráfico. El
acercamiento más sofisticado es permitir que la RTU reporte por excepción sin
la encuesta previa por parte de la unidad maestra. Esto significa que el sistema
de comunicaciones no se está utilizando para las repetidos escaneos con sin
novedad, siendo la respuesta más frecuente. Esto permite que un sistema típico
controle muchos más RTU con la mismo ancho de banda para las
comunicaciones. Como los asuntos asociados con parámetros altamente
volátiles todavía existen, una revisión del sistema en background sigue siendo
necesario, de otro modo una RTU podría salir de servicio y el sistema nunca se
daría por enterado.
17
Para utilizar esta técnica, el protocolo de comunicación debe tener la capacidad
de proporcionar las direcciones de destino del mensaje, y de la fuente del mismo.
Este sistema también implica que dos RTU pueden transmitir simultáneamente,
interfiriendo uno con otro. Un sistema SCADA normalmente repetirá la
transmisión si no recibe el estado del dispositivo dentro de cierto tiempo. Si
interfieren dos RTU transmitiendo simultáneamente, y, luego si ambos poseen el
mismo tiempo de reenvío, interferirán otra vez. Por esta razón, el acercamiento
típico es repetir el envío después de un período aleatoriamente seleccionado. El
uso de timeouts al azar puede no ser suficiente cuando por ejemplo ha habido
un apagón extenso. Incluso con recomprobaciones al azar, puede haber tanto
tráfico que la RTU todavía no podrá conseguir realizar la transmisión. Por esta
razón una mejora que es deseable es que después de 5 intentos, el período de
recomprobación se fije por ejemplo 1 minuto [5].

2.1.3.3.2 Manejo de fallas de comunicaciones.

Un sistema SCADA debe ser muy confiable. Los sistemas de comunicación para
los sistemas SCADA se han desarrollado para manejar comunicaciones
deficientes de una manera predecible. Esto es especialmente importante donde
está implicado el control (podría ser desastroso si las fallas de comunicaciones
causaran que el sistema SCADA haga funcionar inadvertidamente el sector
incorrecto de la planta). Los sistemas SCADA hacen uso típicamente de las
técnicas tradicionales de la paridad, de la comprobacion de sumas polinómicas,
códigos de Hamming y demás. Sin embargo no confían simplemente en estas
técnicas. La operatoria normal para un sistema SCADA es esperar siempre que
cada transmisión sea reconocida. El sistema de escaneo que emplea tiene
seguridad incorporada, en la que cada estación externa está controlada y debe
periódicamente responder. Si no responde, entonces un número predeterminado
de recomprobaciones será efectuado.

18
Las fallas eventualmente repetidas harán que la RTU en cuestión sea marcado
como "fuera de servicio" (en un sistema de escaneo una falla de comunicación
bloquea la red por un período de tiempo relativamente largo, y una vez que se
haya detectado una falla, no hay motivo para volver a revisar). La exactitud de la
transmisión de un SCADA se ha mirado tradicionalmente como tan importante
que la aplicación SCADA toma directamente la responsabilidad sobre ella. Esto
se produce en contraste con protocolos de comunicación más generales donde
la responsabilidad de transmitir datos confiablemente se deja a los mismos
protocolos. A medida que se utilicen protocolos de comunicación más
sofisticados, y los proveedores de SCADA comiencen a tomar confianza con
ellos, entonces la responsabilidad de manejar errores será transferida al
protocolo [5].

2.1.3.3.3 Los protocolos de comunicación.

Se han desarrollado técnicas para la transmisión confiable sobre medios

deficientes, y es así que muchas compañías alcanzaron una ventaja competitiva
respecto de sus competidoras, simplemente debido al mérito técnico de sus
protocolos. Estos protocolos por lo tanto tendieron a ser propietarios, y
celosamente guardados. Esto no representaba un problema al instalar el sistema,
aunque sí cuando eran requeridas extensiones. Lo obvio y casi absolutamente
necesario era acudir de nuevo al proveedor original. No era generalmente factible
considerar el uso de un protocolo distinto, pues eran generalmente mutuamente
excluyentes. Los progresos recientes han considerado la aparición de un número
apreciable de protocolos "abiertos". IEC870/5, DNP3, MMS son algunos de éstos.
Los mejores de estos protocolos son los multicapa completamente
"encapsulados", y los sistemas SCADA que utilizan éstos pueden confiar en ellos
para garantizar la salida de un mensaje y el arribo a destino. Un número de
compañías ofrece los códigos fuente de estos protocolos, y otras ofrecen
conjuntos de datos de prueba para comprobar la implementación del mismo. Por

19
medio de estos progresos está llegando a ser factible, por lo menos a este nivel,
considerar la interoperabilidad del equipamiento de diversos fabricantes [5].

2.1.3.3.4 Las redes de comunicación.

SCADA tiende a utilizar la mayoría de las redes de comunicación disponibles.

Los sistemas SCADA basados en transmisión radial son probablemente los más
comunes. Éstos evolucionaron con el tiempo, y lo más básico es el uso de FSK
(“frequency shift keying” -codificación por conmutación de frecuencia) sobre
canales de radio analógicos. Esto significa que aquellos 0 y 1 son representados
por dos diversas frecuencias (1800 y 2100 hertzios son comunes). Estas
frecuencias se pueden sintetizar y enviar sobre una radio de audio normal.
Velocidades de hasta 1200 baudios son posibles. Una consideración especial
necesita ser dada al retardo de RTS (“request to send” - petición de enviar) que
normalmente se presenta. Esto se produce porque una radio se tomará algún
tiempo después de ser encendida (“on”) para que la señal alcance niveles
aceptables, y por lo tanto el sistema SCADA debe poder configurar estos
retardos. La mayoría de las otras consideraciones con respecto a radio y SCADA
se relacionan con el diseño básico de la red de radio [5].

Servicios basados en satélites de comunicaciones.

Hay muchos de éstos, pero la mayoría son muy costosos. Hay situaciones donde
no hay alternativas. No obstante, existe un servicio basado en satélites que es
económico: los sistemas VSAT: “Very Small Aperture”. Terminal. Con VSAT,
usted alquila un segmento del espacio (64k o más), y los datos se envían de un
sitio remoto a un “hub” vía satélite. Hay dos tipos de “hub”. El primero es un
sistema proporcionado típicamente por un proveedor de servicios de VSAT. La
ventaja es un costo fijo para los datos aunque su implementación puede costar
muy cara. La otra consideración para éstos es la necesidad de un “backlink” del

20
“hub” al centro de SCADA. Esto puede ser de un costo considerable. El otro tipo
de sistema utiliza un “hub” pequeño (los clásicos de LAN estructuradas) que se
puede instalar con la unidad maestra. Este es más barato, pero la administración
del “hub” es responsabilidad exclusiva del propietario de SCADA. La interfaz a
cualquier tipo de sistema de VSAT implica el uso de protocolos utilizados por el
sistema de VSAT - quizás TCP/IP.

Modbus

Es un protocolo de comunicaciones desarrollado para el mundo del PLC, y fue

definido para el uso de las conexiones por cable. Aunque los proyectos procuran
con frecuencia utilizar Modbus sobre radio, éste está trayendo problemas,
fundamentalmente con los temporizadores. En cualquier caso, Modbus es
incompleto como un protocolo para SCADA, y existen alternativas mejores tales
como DNP 3.0. Modbus tiene su campo de aplicación en comunicaciones con
PLC sobre una conexión por cable.

Sistemas Landline (Líneas Terrestres)

Éstos son comúnmente usados, pero una gran cantidad de sistemas SCADA
implican el uso de la radio para sustituir landlines ante una falla. Las termitas
(postes de madera) y el relámpago son problemas comunes para los landlines
[5].

2.1.3.3.5 Procesadores de Comunicaciones Front End.

El "centro" de SCADA consiste típicamente en una colección de computadoras

conectadas vía LAN (o LAN redundante). Cada máquina realiza una tarea
especializada. La responsabilidad de la colección de datos básicamente puede
residir en una de ellas (con un sistema mirror), las visualizaciones pueden ser

21
manejadas por una segunda computadora, etc. Una función asignada
típicamente a una computadora separada es la interfaz a la red de
comunicaciones. Ésta manejará toda la interconexión especializada a los canales
de comunicaciones, y en muchos casos realizará la conversión del protocolo de
modo que el sistema principal pueda contar con datos entrantes en un formato
estándar [5].

2.1.3.3.6 Radio.

La telemetría de radio es probablemente la tecnología base de SCADA. La

velocidad de transmisión de datos sobre radio estaba en su momento limitada al
rango 300 baudios a 1200 baudios, pero las radios de datos modernas soportan
hasta 9600 baudios (e incluso hasta 64kbps). Una red de radio que funciona en
la banda de 900 Mhz es autorizada normalmente para utilizar 12,5 o 25 kHz de
ancho de banda. En 25 kHz, las velocidades de 9600 baudios pueden ser
alcanzadas, pero en 12,5 kHz solamente 4800 baudios.

Una red de radio típica consiste en una conversación a través del repetidor
situado en algún punto elevado, y un número de RTU que comparten la red.
Todos las RTU "hablan" sobre una frecuencia (F1) y escuchan en una segunda
frecuencia (F2). El repetidor escucha en F1, y retransmite esto en F2, de modo
que una RTU que transmite un mensaje en F1, lo tiene retransmitido en F2, tal
que el resto de las RTU pueda oírlo. Los mensajes de la unidad maestra viajan
sobre un enlace de comunicación dedicado hacia el repetidor y son difundidos
desde el repetidor en F2 a todos las RTU. Si el protocolo de comunicaciones
usado entre la unidad maestra y el repetidor es diferente al usado en la red de
radio, entonces debe haber un "Gateway" en el sitio del repetidor. Este hecho
permitiría utilizar los protocolos apropiados para cada uno de los medios. Se ha
utilizado con éxito DNP3 sobre la red de radio y después encapsulado el DNP3
en el TCP/IP para permitir que una red de fines generales lleve los datos a la

22
unidad maestra. El número de RTU que puede compartir un repetidor depende
de un número de factores. En primer lugar el tipo de equipo de radio puede
afectar esto, teniendo en cuenta el retardo en alcanzar una señal estable. La
aplicación también es un factor importante, ya que de ella depende el tiempo de
respuesta requerido. Las características del protocolo (la interrogación, informe
por excepción, las transmisiones iniciadas por la RTU) también pueden ser
significativas. La velocidad tiene obviamente un impacto también [5].

2.1.3.3.7 Los circuitos telefónicos.

Tienen algunas implicaciones importantes para un sistema SCADA. En primer

lugar la administración de módems en campo puede ser molesta. En segundo
lugar la RTU debe poder salvar datos mientras el módem está desconectado,
para después transmitirlos cuando se establece la conexión. Preferiblemente la
RTU debe poder iniciar la llamada cuando ocurre una alarma, o sus buffers de
datos corren el riesgo de desbordar. La unidad maestra debe poder manejar la
recepción de este cúmulo de datos, y al mismo tiempo "rellenar" su base de
datos, generar los gráficos, etcétera. Algunos informes producidos por la unidad
maestra pueden necesitar ser corregidos cuando llegan los datos [5].

2.1.3.4 Gráfico de tendencias.

El recurso de los gráficos de tendencias es una función base incluida en cada

sistema SCADA. La computadora se puede utilizar para resumir y exhibir los
datos que está procesando. Las tendencias (gráficos) de valores analógicos
sobre el tiempo son muy comunes. Recoger los datos y resumirlos en informes
para los operadores y gerencia son características normales de un sistema
SCADA [5].

23
2.3.4.1 Características.

Los gráficos incluye elementos tales como diagramas X-Y, la capacidad de re-
escalar la tendencia mientras es mostrada, la capacidad de visualizar
coordenadas para seleccionar una característica en la tendencia y visualizar los
valores asociados a ella, histogramas, múltiples valores independientes en una
tendencia, y gráficos de información de estado. El sistema de tendencias trabaja
normalmente creando un archivo para cada tendencia con "casilleros" para los
valores de datos que se renovarán en una frecuencia especificada (máximo ratio
de “trending”). A medida que se adquieren los datos de campo, se ubican en los
archivos de tendencia, quedando disponibles para su posterior análisis. Hay
normalmente un límite superior a la cantidad de datos que puedan ser guardados
(ejemplo un año de datos) [5].

2.1.3.4.2 Particularidades del almacenaje de datos.

El uso de archivos de tendencia con casilleros para los datos, renovados en los
intervalos especificados, puede causar dificultades cuando se usa la
característica de Reporte por Excepción. Los problemas pueden ser aún mayores
cuando se incluyen en el sistema "dial-up" RTU por las posibles desconexiones.
El sistema SCADA debe tener la capacidad de llenar los archivos de tendencia
en estas circunstancias. Un set SCADA no está preparado para hacer esto
automáticamente, y se debe tener sumo cuidado al configurar y especificar las
características de graficar las tendencias para lograrlo. Algunos sistemas no
permiten que todas las variables sean afectadas a la tendencia de datos. Cuando
se desee ver una tendencia para un valor actualmente no configurado para un
gráfico de tendencia, debe entonces ser afectado a la tendencia de datos, y luego
habrá que esperar hasta que se hayan salvado suficientes datos para que el
gráfico sea consistente y aporte los datos de tendencia. Esto no es útil si estamos
procurando encontrar fallas [5].

24
2.1.3.5 Procesamiento de alarmas.

La característica del procesamiento de alarmas se ha asociado siempre a las

funciones de las áreas de control de la planta. La computadora procesa todos los
datos como vienen del campo, y considera si la variable ha entrado en alarma.
Para los valores digitales, uno de los estados (0 o 1) se puede señalar como
estado de alarma. Para valores analógicos es normal que se definan límites de
alarmas tal que si el valor cae fuera de estos límites, considerarlo como en
alarma. Las alarmas se clasifican normalmente en varios niveles de prioridad,
con la prioridad más alta siendo a menudo reservada para las alarmas de
seguridad. Esto permite que el operador seleccione una lista de las alarmas más
importantes. Cuando un punto entra en alarma, debe ser validada por el
operador. Un código es asociado a veces por el operador en ese momento para
explicar la razón de la alarma. Esto ayuda en el análisis posterior de los datos.
Es común tener cierto anuncio audible de la alarma, alguna señal sonora en la
sala de operaciones. Un problema común para los sistemas SCADA es la
"inundación" de alarmas. Cuando ocurre un trastorno importante del proceso, a
menudo un evento de alarma causa otro y así sucesivamente. A menudo en el
entusiasmo inicial, los límites de alarma se especifican firmemente, y aún en
valores que no son realmente importantes. La inundación de alarmas resultante
puede abrumar al personal de operaciones, y ocultar la causa inicial del problema
[5].

2.1.3.5.1 Características.

Los recursos de alarmas incluyen la capacidad de identificar al personal de

operaciones por su “login”, y exhibir solamente las alarmas relevantes a su área
de responsabilidad, y de suprimir alarmas, por ejemplo, cuando la planta está

25
bajo mantenimiento. Algunos sistemas sofisticados pueden resolver la
inundación de alarmas identificando secuencias de causas y efectos [5].

2.1.3.5.2 Chequeos.

Cuando los sistemas SCADA no escanean regularmente todos los sitios, sino
que por el contrario confían en la transmisión iniciada por la RTU, si se detectara
una condición de error o un cambio significativo en un valor, existe la posibilidad
de que la RTU o las comunicaciones puedan fallar, y el evento pase
desapercibido. Para solucionar esto, se dispara un "revisión completa del
sistema" en “background”, en el cual cada RTU es escaneada con una frecuencia
determinada por el tiempo que se considere prudente en que una alarma no sea
detectada [5].

2.1.3.6 Comunicaciones.

La característica distintiva de los sistemas SCADA es su capacidad de

comunicación. Como ya se ha dicho, comparado a los DCS (“Distributed Control
Systems” - sistemas de control distribuido) considerados a menudo dentro de una
planta o de una fábrica, un sistema SCADA cubre generalmente áreas
geográficas más grandes, y utiliza muchos medios de comunicaciones diversos
(y a menudo relativamente no fiables). Un aspecto importante de la tecnología de
SCADA es la capacidad de garantizar confiablemente la salida de datos al usar
estos medios. Los sistemas SCADA utilizaron inicialmente enlaces de
comunicación lentos. Cálculos cuidadosos debieron ser hechos para evaluar los
volúmenes de datos probables esperados, y asegurar que la red de
comunicaciones fuera capaz de resolver las demandas [5].

26
2.1.4 Terminales Remotas (Remote Terminal Units).

2.1.4.1 Fundamentos.

Las unidades terminales remotas consisten en una pequeña y robusta

computadora que almacenaba datos y los transmite a la terminal maestra para
que esta controle los instrumentos. Es una unidad stand-alone (independiente)
de adquisición y control de datos. Su función es controlar el equipamiento de
proceso en el sitio remoto, adquirir datos del mismo, y transferirlos al sistema
central SCADA. La gama de Unidades Terminales Remotas ofrece una solución
universal para el control de instalaciones técnicas de todo tipo. Hay dos tipos
básicos de RTU- "single boards" (de un solo módulo), compactos, que contienen
todas las entradas de datos en una sola tarjeta, y "modulares" que tienen un
módulo CPU separado, y pueden tener otros módulos agregados, normalmente
conectados en una placa común (similar a una PC con una placa madre donde
se montan procesador y periféricos). Una RTU “single board” tiene normalmente
I/O fijas, por ejemplo, 16 entradas de información digitales, 8 salidas digitales, 8
entradas de información analógicas, y 4 salidas analógicas. No es normalmente
posible ampliar su capacidad. Un RTU modular se diseña para ser ampliado
agregando módulos adicionales. Los módulos típicos pueden ser un módulo de
8 entradas análogas, un módulo de 8 salidas digitales. En la actualidad gracias a
la modularidad funcional y material, las unidades remotas pueden ser utilizadas
tanto para satisfacer necesidades de transmisión de alarmas como para la
supervisión completa de una compleja instalación de telegestión, en forma
autónoma o acoplada a módulos de expansión. El mercado propone varios
modelos para responder de la manera más óptima posible a los diferentes casos
de aplicación, desde un punto de vista técnico y económico. La mayoría de
terminales incluyen un software embarcado que integra potentes recursos de
comunicación y supervisión, sin necesidad de programación específica claro que
se tiene que tomar en cuenta que este software es especifico de cada compañía
27
y no son compatibles entre sí. Para minimizar el problema de compatibilidad las
compañías están realizando sus programas bajo estándares para poder vender
sus productos con mayor facilidad.

La mayor parte de las RTU tienen como características principales:

• Comunicaciones a través de la red telefónica fija y móvil, radio enlaces,

líneas dedicadas, bus de campo.
• Adquisición y mando (señales digitales y analógicas, conteos).
• Capacidad: entre 280 y 700 variables (según las aplicaciones).
• Procesamientos y automatismos paramétricos.
• Almacenamiento de datos a largo plazo (alarmas, medidas, conteos,
informes).
• Alerta hacia estaciones maestras, buscapersonas y teléfonos móviles.
• Módulos especializados (automatización y gestión de las estaciones de
elevación).
• Enlaces entre instalaciones (entre remota y remota, entre remotas y
módulos).

• Compatibilidad con otros productos (autómatas programables,

analizadores, controladores, medidores, ordenadores de supervisión.)

La interacción humano-máquina (HMI) para configurar y operar el equipo puede

realizarse localmente o a distancia, mediante un microordenador (programas y
otros productos compatibles), en un lenguaje natural e intuitivo [5].

28
2.1.4.2 Funcionalidad del hardware de un RTU.

El hardware de un RTU tiene los siguientes componentes principales:

• CPU y memoria volátil (RAM).

• Memoria no volátil para grabar programas y datos.
• Capacidad de comunicaciones a través de puertos seriales o a veces
con módem incorporado.
• Fuente de alimentación segura (con salvaguardia de batería).
• “Watchdog timer” (que asegure reiniciar el RTU si algo falla).
• Protección eléctrica contra fluctuaciones en la tensión.
• Interfaces de entrada-salida a DI/DO/AI/AO.

• Reloj de tiempo real.

2.1.4.3 Funcionalidad del Software.

Todos las RTU requieren la siguiente funcionalidad. En muchas RTU éstas se

pueden mezclar y no necesariamente ser identificables como módulos
separados.

• Sistema operativo en tiempo real.

• “Driver” para el sistema de comunicaciones, es decir la conexión con la
MTU.
• “Drivers” de dispositivo para el sistema de entrada-salida a los
dispositivos de campo.
• Aplicación SCADA para exploración de entradas de información,
procesamiento y el grabado de datos, respondiendo a las peticiones de
la unidad maestra sobre la red de comunicaciones.
• Algún método para permitir que las aplicaciones de usuario sean
configuradas en la RTU. Ésta puede ser una simple configuración de

29
 parámetros, habilitando o deshabilitando entradas-salidas específicas
que invalidan o puede representar un ambiente de programación
completo para el usuario.
• Diagnóstico.

• Algunas RTU pueden tener un sistema de archivos con soporte para

descarga de archivo, tanto programas de usuario como archivos de
configuración [5].

2.1.4.4 Operación Básica.

El RTU operará la exploración de sus entradas de información, normalmente con

una frecuencia bastante alta. Puede realizar algún procesamiento, por ejemplo
cambios de estado, “time stamping” de cambios, y almacenaje de datos que
aguardan el “polling” de la unidad maestra. Algunas RTU tienen la capacidad de
iniciar la transmisión de datos a la unidad maestra, aunque es más común la
situación donde la unidad maestra encuesta a las RTU preguntando por cambios.
La RTU puede realizar un cierto procesamiento de alarmas. Cuando es
interrogado la RTU deber responder a la petición, la que puede ser tan simple
como dar todos tus datos, o una compleja función de control para ser ejecutada
[5].

2.1.4.5 RTU pequeñas contra RTU grandes.

Las RTU son dispositivos especiales fabricados a menudo por pequeños

proveedores en pequeños lotes de algunos cientos, normalmente para los
mercados domésticos. Por lo tanto no todas las RTU soportan toda la
funcionalidad descrita. Una RTU más grande puede ser capaz de procesar
centenares de entradas de información, y aún controlar el funcionamiento de "sub
RTU" más pequeñas. Éstas son obviamente más costosas. La potencia de
procesamiento de una RTU se extiende desde pequeños procesadores de 8 bits

30
con memoria mínima hasta sofisticados RTU más grandes capaces de recolectar
datos en el orden del milisegundo [5].

2.1.4.6 Algunos tipos de RTU.

• Sistemas “stand-alone” minúsculos que emplean las mismas baterías

por un año entero o más. Estos sistemas registran los datos en la
EPROM o FLASH ROM y descargan sus datos cuando son accedidos
físicamente por un operador. A menudo estos sistemas usan
procesadores de chip simple con memoria mínima y pueden no ser
capaces de manejar un protocolo de comunicaciones sofisticado.

• Sistemas “stand-alone” pequeños que pueden accionar

periódicamente a los sensores (o radios) para medir y/o reportar.
Generalmente las baterías son mantenidas por energía solar con
capacidad para mantener la operación por lo menos 4 meses durante
la oscuridad completa. Estos sistemas tienen generalmente bastante
capacidad para un esquema mucho más complejo de comunicaciones.

• Sistemas medios. Ordenadores industriales single board dedicados,

incluyendo IBM-PC o compatibles en configuraciones industriales tales
como VME, MultiBus, STD megabus, PC104, etc.
• Sistemas grandes. Completo control de planta con todas las alarmas
visuales y sonoras. Estos están generalmente en DCS en plantas, y se
comunican a menudo sobre LAN de alta velocidad. La sincronización
puede ser muy crítica [5].

2.1.4.7 Estándares.

Como fuera indicado, las RTU son dispositivos especiales. Ha habido una
carencia de estándares, especialmente en el área de comunicaciones, y las RTU
provenientes de un fabricante no se pueden mezclar generalmente con una RTU
31
de otro. Una industria ha crecido desarrollando conversores y emuladores de
protocolos. Algunos estándares han comenzado recientemente a emerger para
las RTU, como DNPs e IEC870 para comunicaciones IEC1131-3 para programar
las RTU [5].

2.1.4.8 PLC’s contra RTU’s.

Un PLC (“Programmable Logic Controller”) es una computadora industrial

pequeña que substituyó originalmente la lógica de los relays. Tenía entradas de
información y salidas similares a las de una RTU. Contenía un programa que
ejecutaba un bucle, explorando las entradas de información y tomando las
acciones basadas en estas entradas de información. El PLC no tenía
originalmente ninguna capacidad de comunicaciones, sino que comenzaron a ser
utilizadas en situaciones donde las comunicaciones eran una característica
deseable. Los módulos de comunicaciones fueron desarrollados así para los
PLC, utilizando Ethernet (para el uso en DCS) y el protocolo de comunicaciones
Modbus para el uso sobre conexiones dedicadas (cables). Con el correr del
tiempo los PLC soportaron protocolos de comunicación más sofisticados. Las
RTU se han utilizado siempre en situaciones donde son más difíciles las
comunicaciones, y la potencia de las RTU residía en su capacidad de manejar
comunicaciones difíciles. Las RTU tenían originalmente una programación
deficiente en comparación con los PLC. Con el tiempo, la programación de la
RTU ha ido aumentando. En la actualidad no existe gran rivalidad entre los PLC
y las RTU ya que se han convertido en el complemento, pues la RTU se ha
convertido en la conexión entre el PLC y el control central. De esta forma la RTU
informa del desempeño del equipo y en caso de que este no sea satisfactorio la
MTU realiza los cambios necesarios en el PLC por medio de la RTU [5].

32
2.2 Introducción a Linux.

En este apartado se explica qué es el software libre, Linux, cuál es su historia,

qué son sus distribuciones y finalmente, cuáles son las consideraciones que hay
que tener en cuenta antes de poner en marcha el plan de migrar al sistema
operativo de software libre más grande del mundo.

Linux es un núcleo libre de sistema operativo basado en Unix. Es uno de los

principales ejemplos de software libre. Linux está licenciado bajo la GPL v2 y está
desarrollado por colaboradores de todo el mundo. El desarrollo del día a día tiene
lugar en la Linux Kernel Mailing List Archive [6].

El núcleo Linux fue concebido por el entonces estudiante de ciencias de la

computación, Linus Torvalds, en 1991. Linux consiguió rápidamente
desarrolladores y usuarios que adoptaron códigos de otros proyectos de software
libre para su uso en nuevas distribuciones (versiones del S.O. Linux). El núcleo
Linux ha recibido contribuciones de miles de programadores de todo el mundo.
Normalmente Linux se utiliza junto a un empaquetado de software, llamado
distribución Linux y servidores [6].

2.2.1 ¿Qué es el software libre?

El software libre es, principalmente, una modalidad de desarrollo y distribución

de programas de computadoras. Aunque, si hacemos un análisis un poco más
minucioso del concepto, nos encontramos con que se trata de algo mucho más
amplio, mucho más trascendental.

El software libre es un suceso social, que está cambiando la forma en que el

mundo informático se mueve.

33
El software libre es aquel que se puede utilizar y distribuir libremente. También
puede ser modificado y vuelto a distribuir (para estas últimas dos opciones,
requiere código abierto).

Y para que el programa sea considerado software libre, deben garantizarse esas
cuatro libertades. Si la licencia de uso y distribución de un programa no garantiza
una de esas cuatro libertades, entonces estamos frente a un programa que no es
libre.

Cuando hablamos de libertad, lo hacemos en el sentido más completo de la

palabra. La libertad de usarlo para que lo queramos es la libertad de no tener que
pedir permiso a nadie para ejecutar cualquier acción con el programa. Esto
incluye utilizarlo para realizar tareas que quizás no estaban contempladas
cuando se desarrolló el programa. La libertad de distribuirlo libremente es la
libertad de realizar cuantas copias queramos del programa. Es la libertad de tener
una única licencia de uso para diez, cien o mil instalaciones del programa. Es la
libertad que permite copiar el programa a los amigos si ellos lo piden la libertad
de modificar el programa encierra en sí misma otra libertad, que es la de disponer
del código fuente del programa.

Para aquellos que no lo saben, el código fuente es el texto, escrito por un

programador, mediante el cual fue desarrollado el programa. Entonces, el
software libre permite ver cómo está hecho el programa y autoriza su
modificación. Podemos modificarlo para adecuarlo a nuestras necesidades, para
agregarle o sacarle características funcionales, etc.

Finalmente, si modificamos un programa, tenemos libertad de distribuir la versión

modificada, siempre y cuando lo hagamos por medio de la misma licencia, que
garantiza las cuatro libertades antes mencionadas [6].

34
2.2.2 Libre no significa gratis.

Muchas veces, las personas confunden la palabra libre con gratis. Y entonces
piensan cosas erróneas como que Linux es gratis. El software libre, no
necesariamente es gratis. Y para entender esto, vamos a ver un ejemplo. Yo
tengo una conexión de banda ancha, y descargué en mi computadora la última
versión de Ubuntu Linux. Entonces, cuando termino de descargarlo, viene un
amigo a mi casa y me pide que le haga una copia de esta versión de Linux. En
primer lugar, hay que aclarar que hacer una copia de un programa de software
libre es totalmente legal ya que, recordemos, la segunda libertad del software
libre tiene que ver con la libre distribución de un programa. De hecho, en la
Licencia Pública General (que es la licencia oficial del software libre) se anima de
manera entusiasta a programadores y usuarios a que distribuyan sus programas
de software libre. De todos modos, continuando con el ejemplo, yo tengo varias
opciones garantizadas por la libertad de distribuir el programa. Una de ellas es
decirle “sí, te lo copio ya mismo” y tomar cuatro CDs de mí escritorio, y grabárselo
de manera totalmente gratuita. Otra opción es decirle “sí, pero me tienes que
pagar por los CDs”, lo cual es totalmente válido y legal también. Y otra opción, es
decirle “sí, te lo copio, pero me tienes que pagar por los CDs y también por el
servicio de haber tenido la computadora toda la semana encendida para bajar
esa distribución”. Esta última opción, es totalmente válida y legal: todos tenemos
derecho a pedir una remuneración por el trabajo que realizamos.

Ahora bien, como se trata de software libre, mi amigo tiene varias opciones. Una
de ellas es pagarme para obtener la última versión de Ubuntu Linux. Pero,
también puede decirme: “Lo que me pides me parece muy caro, se lo voy a pedir
a mi primo que me lo dará gratis.”

Con este ejemplo se pretende que es el software libre, si bien generalmente es

gratis porque casi todo el mundo se lo descarga de Internet (recordemos: en un
acto totalmente legal), en ciertas ocasiones no lo es.
35
Es por eso que hay versiones de Linux que tienen un costo muy diferente. Porque
las empresas que las compilan (esto es convertir el código fuente en un programa
funcional), ofrecen servicios alrededor de esa compilación que consideran que
valen lo que nos están pidiendo por su versión de Linux [6].

2.2.3 Historia.

En abril de 1991 Linus Torvalds de 21 años, empezó a trabajar en unas simples

ideas para un núcleo de un sistema operativo. Comenzó con un intento por
obtener un núcleo de sistema operativo, gratuito, similar a Unix que funcionara
con microprocesadores Intel 80386. Luego, el 25 de agosto de 1991, Torvalds
escribió en el grupo de noticias comp.os.minix:

"Estoy haciendo un sistema operativo (gratuito, sólo un hobby, no será nada

grande ni profesional como GNU) para clones AT 386(486). Llevo en ello
desde abril y está empezando a estar listo. Me gustaría saber su opinión
sobre las cosas que les gustan o disgustan en minix, ya que mi SO tiene
algún parecido con él.[...] Actualmente he portado bash(1.08) y gcc(1.40), y
parece que las cosas funcionan. Esto implica que tendré algo práctico dentro
de unos meses..."

Después de esto, muchas personas ayudaron con el código. En septiembre de

1991 se lanzó la versión 0.01 de Linux. Tenía 10.239 líneas de código. En octubre
de ese año (1991), se lanzó la versión 0.02 de Linux; luego, en diciembre se lanzó
la versión 0.11 (1991). Esta versión fue la primera en ser self-hosted (auto
albergada). Es decir, Linux 0.11 podía ser compilado por una computadora que
ejecutase Linux 0.11, mientras que las versiones anteriores de Linux se
compilaban usando otros sistemas operativos. Cuando lanzó la siguiente versión,
Torvalds adoptó la GPL como su propio boceto de licencia, la cual no permitía su
redistribución con otra licencia que no sea GPL.

36
Se inició un grupo de noticias llamado alt.os.linux y el 19 de enero de 1992 se
publicó en ese grupo el primer post. El 31 de marzo, alt.os.linux se convirtió en
comp.os.linux. XFree86, una implementación del X WindowSystem, fue portada
a Linux, la versión del núcleo 0.95 fue la primera en ser capaz de ejecutarla. Este
gran salto de versiones (de 0.1x a 0.9x) fue por la sensación de que una versión
1.0 acabada no parecía estar lejos. Sin embargo, estas previsiones resultaron
ser un poco optimistas: desde 1993 a principios de 1994, se desarrollaron 15
versiones diferentes de 0.99 (llegando a la versión 0.99r15).

El 14 de marzo de 1994, se lanzó Linux 1.0.0, que constaba de 176.250 líneas

de código. En marzo de 1995 se lanzó Linux 1.2.0, que ya estaba compuesto de
310.950 líneas de código.

 Mayo de 1996: Torvalds decidió adoptar al pingüino Tux como mascota

para Linux.

 9 de junio de 1996: Se lanzó la versión 2 de Linux, con una recepción

positiva.

 25 de enero de 1999: Se lanzó Linux 2.2.0 con 1.800.847 líneas de código.

 18 de diciembre de 1999: se publicaron parches de IBM Mainframe para

2.2.13, permitiendo de esta forma que Linux fuera usado en ordenadores
corporativos.

 4 de enero de 2001: se lanzó Linux 2.4.0 con 3.377.902 líneas de código.

 17 de diciembre de 2003: se lanzó Linux 2.6.0 con 5.929.913 líneas de

código.

 24 de diciembre de 2008: se lanzó Linux 2.6.28 con 10.195.402 líneas de

código.5

37
  20 de octubre de 2010: se lanzó Linux 2.6.36 con 13.499.457 líneas de
código.6

 30 de mayo de 2011: Linus Torvalds anunció que la versión del núcleo

dará el salto a la 3.0 en la siguiente publicación.

 21 de julio de 2011: Torvalds publicó en su perfil en la red social Google+

que el núcleo versión 3.0 estaba listo con la frase "3.0 Pushed Out".8

 22 de julio de 2011: Fue lanzada la versión 3.0 del núcleo en

http://www.kernel.org

 12 de mayo y 13 de mayo de 2012 fueron lanzadas las versiones 3.3.6 y

3.4-rc7 del núcleo en http://www.kernel.org respectivamente.

Su código fuente está disponible para descarga en el sitio web oficial:

http://www.kernel.org [7].

2.2.4 Las distribuciones de Linux.

Los aportes al sistema operativo comenzaron a ser cada día más numerosas. Un
programador desarrollaba una aplicación basada en GNU/Linux y entonces lo
enviaba a los servidores de la Fundación Software Libre para que otros usuarios
pudieran tener libre acceso a él. Así las aplicaciones se empezaron a contar por
decenas, y luego por centenas. Por eso, el sistema operativo GNU/Linux
completo que en un inicio cabía en sólo algunos disquetes, con el tiempo se fue
convirtiendo en una pila de megabytes. Recordemos que seguimos en la primera
mitad de la década de los noventa, y los usuarios particulares comenzaban a
aparecer en Internet. Las conexiones por aquel entonces eran en su mayoría
basadas en dispositivos MODEM, de bajísima velocidad. Acceder a descargar el
sistema operativo GNU/Linux completo era un lujo que sólo se podían dar
aquellos que tenían acceso a un servidor universitario o gubernamental.

38
Para solucionar este problema, quienes tenían acceso a bajar el sistema
operativo completo decidieron brindar un servicio a quienes no podían bajarlo por
limitaciones de conexión. El servicio era muy simple: grabar los paquetes del
sistema operativo en disquetes (que eran 20 ó 30) y enviarlos por correo a cambio
de una suma de dinero por el medio físico utilizado y por el tiempo perdido en la
grabación. Así nació el concepto de distribución de Linux [6].

2.2.5 ¿Qué es Una Distribución De LINUX?

Una distribución de Linux es esencialmente el sistema operativo básico, más una

selección de paquetes de aplicaciones que lo acompañan. Cada distribuidor tiene
la libertad de seleccionar con qué aplicaciones estará acompañado el sistema
operativo. Y así es como aquel negocio simple de vender disquetes con Linux a
quienes no podían descargarlo dejó de ser un simple servicio para convertirse en
un negocio millonario. Las personas que querían acceder a Linux eran cada vez
más, y las conexiones seguían siendo lentas.

Aquellos pioneros que comenzaron vendiendo el servicio de una distribución de

Linux pasaron de lo artesanal a lo corporativo.

A mediados de los noventa las distribuciones de Linux se podían contar con los
dedos de la mano. Se cree que las primeras distribuciones de Linux fueron SuSE
y Slackware, aunque nadie está muy seguro de ello. Hoy, las distribuciones de
Linux son miles.

Prácticamente cualquiera puede hacerse su propia versión de Linux. Y hay de

todos los tipos: distribuciones para servidores, para estaciones de trabajo, para
el hogar, la oficina, para aplicaciones multimedia, etc.

Al haber tanta diversidad en la oferta, se hace complicado elegir una. De todas

formas, para comenzar a dar nuestros primeros pasos en GNU/Linux, las
opciones no son tantas, ya que no son tantas las distribuciones fáciles de instalar,

39
usar y configurar. Veamos cuáles son las distribuciones ideales para empezar
con Linux [6].

2.2.5.1 Mandriva Linux.

Mandriva Linux es la unión de dos distribuciones de Linux: Mandrake y Conectiva.

Ambas distribuciones, si bien estaban desarrolladas por diferentes empresas, se
orientaban al usuario del hogar y de la oficina, priorizando aspectos visual, la
usabilidad y la facilidad para llevar a cabo las tareas cotidianas. La compañía
Mandrake compró a Conectiva y entonces tomó lo mejor de esta última para su
propia distribución: así nació Mandriva.

Mandriva Linux es una distribución que tiene dos características importantes: fácil
instalación y fácil uso. La primera de ellas es gracias a que el sistema de
instalación tiene un desarrollo de muchos años. Es posible instalar Mandriva en
un equipo con tan sólo hacer algunos clic, incluso teniendo ya otro sistema
operativo instalado (como Microsoft Windows). Cada nueva versión incluye
innumerable cantidad de nuevos controladores de hardware, por lo que podemos
asegurar que funciona perfectamente con la gran mayoría de las placas y
periféricos de las computadoras actuales como scanners, webcams, impresoras,
placas de video 3D, etc.

La distribución Mandriva completa consta de varios miles de paquetes de

aplicaciones, que se distribuyen en un DVD o en varios CDs. Es posible bajarla
de Internet desde su sitio oficial en www.mandriva.com [6].

2.2.5.2 Ubuntu Linux.

Ubuntu es una distribución que durante los últimos años ganó popularidad y
prestigio. La popularidad la ganó gracias a una campaña de distribución gratuita
de CDs en todo el mundo.

40
Cualquiera que quiera tener esta distribución, solo tiene que acceder al sitio oficial
del proyecto (www.ubuntulinux.org) y pedir que le envíen un CD. Lo recibirán de
manera totalmente gratuita en la puerta de su casa.

Ubuntu se caracteriza por ser una distribución simple en todo sentido. En lugar
de incluir miles de aplicaciones como otras distribuciones, se limita a incluir las
mejores. Entonces, cuando el usuario ingresa al menú Aplicaciones encuentra un
navegador, un cliente de correo, un procesador de textos, etc., y no tantas
alternativas como quizás en Mandriva o SuSE. El entorno de usuario también es
muy simple, ya que presenta un escritorio limpio, conciso, y con los iconos justos.
Nada de más, ni de menos.

Otra de las características de Ubuntu es que está basada en una distribución

llamada Debian, que es la distribución oficial de la Fundación Software Libre.
Debian es popular porque goza del mejor sistema de administración de paquetes
del mundo de Linux, por lo cual Ubuntu también se beneficia con él. Instalar un
nuevo programa en Ubuntu es muy simple (si tenemos banda ancha), mientras
que en otras distribuciones como SuSE y Mandriva quizás resulte un poco más
complicado [6].

2.2.5.3 SuSE Linux.

Por ser una de las primeras distribuciones, SuSELinux es la distribución más

veterana de las que estamos mencionando como ideales para el hogar y la
oficina. Las características de SuSE son similares a las de Mandriva: se trata de
una distribución fácil de instalar, con muchos paquetes de aplicaciones incluidos,
y fácil de configurar. SuSE presenta un soporte de hardware quizás más completo
que Ubuntu y Mandriva.

Una de las características principales de SuSE es YaST (Yet Another Setup

Tool), la aplicación de configuración. Desde allí se puede realizar todo tipo de
tareas administrativas, como configurar un nuevo dispositivo de hardware o un
41
servidor proxy, actualizar el sistema, cambiar el fondo del escritorio y mucho más.
El sitio oficial se encuentra en www.novell.com/linux.

Como mencionamos anteriormente, existen muchísimas distribuciones más.

Veamos algunas otras que, aunque no sean las más adecuadas para comenzar
nuestro camino junto a GNU/Linux, son muy importantes para tenerlas en cuenta
[6].

2.2.5.4 Debian gnu/LINUX.

Debian (www.debian.org) es considerada la distribución oficial de la Fundación

Software Libre. Es una distribución muy grande ya que incluye miles de paquetes
de aplicaciones. Obviamente, no es necesario instalarlos todos, sino sólo los que
precisemos. La instalación básica de Debian requiere menos de 100MB de
espacio en nuestro disco rígido, lo que la convierte en una de las ideales para
sistemas de bajos recursos. Luego, a medida que vayamos instalando las
diferentes aplicaciones que conforman el enorme repositorio, necesitaremos más
espacio de almacenamiento.

Y hablando de repositorio, el de Debian no sólo se destaca por la inmensa

cantidad de aplicaciones que tiene, sino por el sistema de actualización Apt, que
permite mantener la distribución actualizada con sólo algunos comandos. El
sistema Apt es uno de los mejores a la hora de instalar nuevas aplicaciones, por
su simpleza y practicidad.

Otra de las características de Debian es que se lanza una nueva versión cada
uno o dos años. Esto se debe al gran nivel de testeo y control que recae sobre el
sistema, por parte de los miles de colaboradores. De esta manera, se tiene un
sistema de gran confiabilidad, aunque pagando el precio de tener el software un
poco desactualizado. De todas maneras, aquellos que quieran instalar lo último
de lo último, pueden hacerlo: sólo tienen que acceder a los directorios Inestable
e Inseguro del servidor de aplicaciones de Debian.
42
Razones porque Debian se considera una de las mejores distribuciones: ocupa
poco lugar, tiene muy bajos requerimientos del sistema, incluye todos los
servidores de red conocidos en el mundo del software libre, y tiene una gran base
de usuarios, entonces, cuando se necesita ayuda, se puede recurrir a una
enorme cantidad de gente [6].

2.2.5.5 SLackWare LINUX.

Slackware (www.slackware.org) es una distribución muy particular por dos

razones: en primer lugar porque es una de las primeras distribuciones de Linux
que aparecieron. En segundo lugar, porque es considerada la distribución de
Linux más parecida al UNIX original.

Las ventajas de Slackware son similares a las de Debian: consume pocos

recursos, incluye mucho software, y es muy segura gracias a su alto grado de
estabilidad. De todas formas, Slackware pierde puntos frente a Debian a la hora
de hablar del sistema de instalación y actualización de paquetes.

Slackware fue la primera distribución de GNU/Linux de muchos usuarios y la

comunidad aun le tiene mucho cariño. Si bien su comunidad de desarrolladores
no es muy grande (a decir verdad casi todo el trabajo recae sobre una sola
persona), su comunidad de usuarios y fanáticos sí lo es [6].

2.2.6 Aspectos técnicos.

2.2.6.1 Arquitecturas.

Actualmente Linux es un núcleo monolítico híbrido. Los controladores de

dispositivos y las extensiones del núcleo normalmente se ejecutan en un espacio
privilegiado conocido como anillo 0 (ring 0), con acceso irrestricto al hardware,
aunque algunos se ejecutan en espacio de usuario. A diferencia de los núcleos

43
monolíticos tradicionales, los controladores de dispositivos y las extensiones al
núcleo se pueden cargar y descargar fácilmente como módulos, mientras el
sistema continúa funcionando sin interrupciones. También, a diferencia de los
núcleos monolíticos tradicionales, los controladores pueden ser prevolcados
(detenidos momentáneamente por actividades más importantes) bajo ciertas
condiciones. Esta habilidad fue agregada para gestionar correctamente
interrupciones de hardware, y para mejorar el soporte de multiprocesamiento
simétrico.

El hecho de que Linux no fuera desarrollado siguiendo el diseño de un

micronúcleo (diseño que, en aquella época, era considerado el más apropiado
para un núcleo por muchos teóricos informáticos) fue asunto de una famosa y
acalorada discusión entre Linus Torvalds y Andrew S. Tanenbaum [7].

2.2.6.2 Jerarquía de directorios.

En Linux existe un sistema de archivos que carga y contiene todos los directorios,
redes, programas, particiones, dispositivos, etc. que el sistema sabe reconocer,
o por lo menos, identificar. Este sistema de ficheros y directorios, tiene como base
al carácter (/); ese mismo carácter sirve también para demarcar los directorios,
como por ejemplo: "/home/usuario/imagen.jpg". El directorio especificado por una
ruta consistente sólo por este carácter contiene toda la jerarquía de los directorios
que constituyen todo el sistema. A este directorio suele llamárselo directorio raíz.
En Linux, a los discos no se les asigna una letra como en Windows (por ejemplo.
"C:"), sino que se les asigna un directorio de la jerarquía del directorio raíz (/),
como por ejemplo: "/media/floppy". Es práctica común en el sistema de ficheros
de Linux, utilizar varias sub-jerarquías de directorios, según las diferentes
funciones y estilos de utilización de los archivos. Estos directorios pueden
clasificarse en:

44
  Estáticos: Contiene archivos que no cambian sin la intervención del
administrador (root), sin embargo, pueden ser leídos por cualquier otro
usuario. (/bin, /sbin, /opt, /boot, /usr/bin...)

 Dinámicos: Contiene archivos que son cambiantes, y pueden leerse y

escribirse (algunos solo por su respectivo usuario y el root). Contienen
configuraciones, documentos, etc. Para estos directorios, es
recomendable una copia de seguridad con frecuencia, o mejor aún,
deberían ser montados en una partición aparte en el mismo disco, como
por ejemplo, montar el directorio /home en otra partición del mismo disco,
independiente de la partición principal del sistema; de esta forma, puede
repararse el sistema sin afectar o borrar los documentos de los usuarios.
(/var/mail, /var/spool, /var/run, /var/lock, /home...)

 Compartidos: Contiene archivos que se pueden encontrar en un ordenador

y utilizarse en otro, o incluso compartirse entre usuarios.

 Restringidos: Contiene ficheros que no se pueden compartir, solo son

modificables por el administrador. (/etc, /boot, /var/run, /var/lock...) [7]

2.2.6.3 Kernel panic.

En Linux, un panic es un error casi siempre insalvable del sistema detectado por
el núcleo en oposición a los errores similares detectados en el código del espacio
de usuario. Es posible para el código del núcleo indicar estas condiciones
mediante una llamada a la función de pánico situada en el archivo
headersys/system.h. Sin embargo, la mayoría de las alertas son el resultado de
excepciones en el código del núcleo que el procesador no puede manejar, como
referencias a direcciones de memorias inválidas.

Generalmente esto es indicador de la existencia de un bug en algún lugar de la

cadena de alerta. También pueden indicar un fallo en el hardware como un fallo

45
de la RAM o errores en las funciones aritméticas en el procesador, o por un error
en el software. En muchas ocasiones es posible reiniciar o apagar
adecuadamente el núcleo mediante una combinación de teclas como
ALT+SysRq+REISUB [7].

2.2.6.4 Lenguajes de programación.

Linux está escrito en el lenguaje de programación C, en la variante utilizada por

el compilador GCC (que ha introducido un número de extensiones y cambios al
C estándar), junto a unas pequeñas secciones de código escritas con el lenguaje
ensamblador. Por el uso de sus extensiones al lenguaje, GCC fue durante mucho
tiempo el único compilador capaz de construir correctamente Linux. Sin embargo,
Intel afirmó haber modificado su compilador C de forma que permitiera compilarlo
correctamente.

Asimismo se usan muchos otros lenguajes en alguna forma, básicamente en la

conexión con el proceso de construcción del núcleo (el método a través del cual
las imágenes arrancables son creadas desde el código fuente). Estos incluyen a
Perl, Python y varios lenguajes shell scripting. Algunos drivers también pueden
ser escritos en C++, Fortran, u otros lenguajes, pero esto no es aconsejable. El
sistema de construcción de Linux oficialmente solo soporta GCC como núcleo y
compilador de controlador [7].

2.2.6.5 Portabilidad.

Aun cuando Linus Torvalds no ideó originalmente Linux como un núcleo portable,
ha evolucionado en esa dirección. Linux es ahora de hecho, uno de los núcleos
más ampliamente portados, y funciona en sistemas muy diversos que van desde
iPAQ (una handheld) hasta un zSeries (un mainframe masivo). Está planeado

46
que Linux sea el sistema operativo principal de las nuevas supercomputadoras
de IBM, Blue Gene cuando su desarrollo se complete.

De todos modos, es importante notar que los esfuerzos de Torvalds también

estaban dirigidos a un tipo diferente de portabilidad. Según su punto de vista, la
portabilidad es la habilidad de compilar fácilmente en un sistema aplicaciones de
los orígenes más diversos; así, la popularidad original de Linux se debió en parte
al poco esfuerzo necesario para tener funcionando las aplicaciones favoritas de
todos, ya sean GPL o de Código abierto.

Las arquitecturas principales soportadas por Linux son DEC Alpha, ARM, AVR32,
Blackfin, ETRAX CRIS, FR-V, H8, IA64, M32R, m68k, MicroBlaze, MIPS,
MN10300, PA-RISC, PowerPC, System/390, SuperH, SPARC, x86, x86 64 y
Xtensa12 [7]

2.2.6.6 Arquitectura de máquina virtual.

El núcleo Linux puede correr sobre muchas arquitecturas de máquina virtual,

tanto como host del sistema operativo o como cliente. La máquina virtual
usualmente emula la familia de procesadores Intel x86, aunque en algunos casos
también son emulados procesadores de PowerPC o ARM [7].

2.2.6.7 Formatos binarios soportados.

Linux 1.0 admitía sólo el formato binario a.out. La siguiente serie estable (Linux
1.2) agregó la utilización del formato ELF, el cual simplifica la creación de
bibliotecas compartidas (usadas de forma extensa por los actuales ambientes de
escritorio como GNOME y KDE). ELF es el formato usado de forma
predeterminada por el GCC desde alrededor de la versión 2.6.0. El formato a.out
actualmente no es usado, convirtiendo a ELF en el formato binario utilizado por
Linux en la actualidad.

47
Linux tiene la capacidad de permitir al usuario añadir el manejo de otros formatos
binarios. También binfmt_misc permite correr el programa asociado a un archivo
de datos [6].

2.3 Introducción a Android.

La telefonía móvil está cambiando la sociedad actual de una forma tan

significativa como la ha hecho Internet. Esta revolución no ha hecho más que
empezar, los nuevos terminales ofrecen unas capacidades similares a un
ordenador personal, lo que permite que puedan ser utilizados para leer nuestro
correo o navegar por Internet. Pero a diferencia de un ordenador, un teléfono
móvil siempre está en el bolsillo del usuario. Esto permite un nuevo abanico de
aplicaciones mucho más cercanas al usuario. De hecho, muchos autores
coinciden en que el nuevo ordenador personal del siglo veintiuno será un terminal
móvil.

El lanzamiento de Android como nueva plataforma para el desarrollo de

aplicaciones móviles ha causado una gran expectación y está teniendo una
importante aceptación tanto por los usuarios como por la industria. En la
actualidad se está convirtiendo en una serie alternativa a otras plataformas como
Symbian, ¡Phone o Windows Mobile [8].

2.3.1 ¿Qué hace Android especial?

Como hemos comentado, existe muchas plataformas para móviles (¡Phone,

Symbian, Windows Phone, BlackBerry, Palm, Java MovileEdition, Linux
Mobile(LiMo),…); sin embargo Android presenta una serie de características que

48
lo hacen diferente. Es el primero que combina en una misma solución las
siguientes cualidades:

 Plataforma realmente abierta. Es una plataforma de desarrollo libre

basada en Linux y de código abierto. Una de sus grandes ventajas es que
se puede usar y customizar el sistema sin pagar royalties.

 Portabilidad asegurada. Las aplicaciones finales son desarrolladas en

Java lo que nos asegura que podrán ser ejecutadas en gran variedad de
dispositivos, tanto presentes como futuros. Esto se consigue gracias al
concepto de máquina virtual.

 Arquitectura basada en componentes inspirados en Internet. Por ejemplo,

el diseño de la interfaz de usuario se hace en xml, lo que permite que una
misma aplicación se ejecute en un móvil de pantalla reducida o en un
netbook.

 Filosofía de dispositivo siempre conectado a Internet.

 Gran cantidad de servicios incorporados: por ejemplo, localización basada

tanto en GPS como en torres de telefonía móvil. Incorpora potentes bases
de datos con SQL. Reconocimiento y síntesis de voz, navegador, mapas
…

 Alto nivel de seguridad. Los programas se encuentran aislados unos de

otros gracias al concepto de ejecución dentro de una caja que incorpora
la máquina virtual. Cada aplicación dispone de una serie de permisos que
limitan su rango de actualización (servicios de localización, acceso a
internet…)

 Optimización para baja potencia y poca memoria. Por ejemplo, Android

utiliza la Máquina Virtual Dalvik. Se trata de una implementación de
Google de la máquina virtual de Java optimizada para dispositivos móviles.
49
  Alta calidad de gráficos y sonido: gráficos vectoriales suavizados,
animaciones inspiradas en Flash, gráficos en 3 dimensiones basados en
OpenGl. Incorpora codecs estándar más comunes de audio y video
incluyendo H.264 (AVC), MP3, AAC,…

Android combina características muy interesantes.

En conclusión Android nos ofrece una forma sencilla y novedosa de implementar

potentes aplicaciones para móviles [8].

2.3.2 Los orígenes.

Google adquiere Android Inc. en el año 2005. Se trataba de una pequeña

compañía, que acababa de ser creada, orientada a la producción de aplicaciones
para terminales móviles. Este mismo año empiezan a trabajar en la creación una
máquina virtual Java optimizada para móviles (Dalvik VM).

En el año 2007 se crea el consorcio Handset Alliance con el objetivo de

desarrollar estándares abiertos para móviles. Está formado por Google, Intel,
Texas Instruments, Motorola, T-Movile, Samsung, Ericson, Toshiba, Vodafone,
NTT DoCoMo, Sprint Nextel y otros. Una pieza clave de los objetivos de esta
alianza es promover el diseño y difusión de la plataforma Android. Sus miembros
se han comprometido a publicar una parte importante de su propiedad intelectual
como código abierto bajo licencia Apache v2.0.

En noviembre del 2007 se lanza una primera versión del Android SDK. Al año
siguiente aparece el primer móvil con Andorid (T-Mobile G1). En octubre Google
libera el código fuente de Android principalmente bajo licencia de código abierto
Apache (licencia GPL v2 para el núcleo). Este mismo mes se abre AndroidMarket,
para la descarga de aplicaciones. En abril del 2009 Google lanza la versión 1.5
del SDK que incorpora nuevas características como el teclado en pantalla. A

50
finales del 2009 se lanza la versión 2.0, durante el 2010 las versiones 2.1, 2.2 y
2.3, y al termino del 2012 la versión 4.2.1 [8].

2.3.3 Arquitectura de Android.

El siguiente gráfico muestra la arquitectura de Android. Como se puede ver está

formada por cuatro capas. Una de las características más importantes es que
todas las capas están basadas en software libre.

Figura 2 – 1. Arquitectura de Android.

2.3.3.1 EL núcleo de Linux.

El Núcleo de Android está formado por el sistema operativo Linux versión 2.6.
Esta capa proporciona servicios como la seguridad, el manejo de la memoria, el
multiproceso, la pila de protocolos y el soporte de drivers para dispositivos.

51
Esta capa del modelo actúa como capa de abstracción entre el hardware y el
resto de la pila. Por lo tanto, es la única que es dependiente del hardware [8].

2.3.3.2 Runtime de Android.

Está basado en el concepto de máquina virtual utilizado en Java. Dado las

limitaciones de los dispositivos donde ha de correr Android (poca memoria y
procesador limitado) no fue posible utilizar una máquina virtual Java estándar.
Google tomó la decisión de crear una nueva, la máquina virtual Dalvik, que
respondiera mejor a estas limitaciones.

Algunas características de la máquina virtual Dalvik que facilitan esta

optimización de recursos son: que ejecuta ficheros Dalvik ejecutables (.dex)
formato optimizado para ahorrar memoria. Además, está basada en registros.
Cada aplicación corre en su propio proceso Linux algunas funciones como
threading y el manejo de la memoria a bajo nivel.

También se incluye en el Runtime de Android el “corelibraries” con la mayoría de

las librerías disponibles en el lenguaje Java [8].

2.3.3.3 Librerías nativas.

Incluye un conjunto de librerías en C/C++ usadas en varios componentes de

Android. Están compiladas en código nativo del procesador. Muchas de las
librerías utilizan proyecto de código abierto. Algunas de estas librerías son:

 System C library: una derivación de la librería BSD de C estándar (libc),

adaptada para dispositivos embebidos basados en Linux.

 Media Framework: librería basada en Packet Video’s Open Core; soporta

codecs de reproducción y grabación de multitud de formatos de audio
video e imágenes MPEG4, H.264, MP3, AAC, AMR, JPG y PNG.

52
  SurfaceManeger: manejar el acceso al subsistema de representación
gráfica en 2D y 3D.

 WebKit: soporta un moderno navegador web utilizado en el navegador

Android y en la vista webview. Se trata de la misma librería que utiliza
Google Chrome y Safari de Apple.

 SGL: motor de gráficos 2D.

 Librerías 3D: implementación basada en OpenGL ES 1.0 API. Las librerías

utilizan el acelerador de hardware 3D si está disponible, o el software
altamente optimizado de proyección 3D.

 FreeType: fuentes en bitmap y renderizado vectorial.

 SQLite: potente y ligero motor de bases de datos relacionales disponibles

para todas las aplicaciones.

 SSL: proporciona servicios de encriptación Secure Socket Layer [8].

2.3.3.4 Entorno de Aplicación.

Proporciona una plataforma de desarrollo libre para aplicaciones con gran

riqueza e innovaciones (sensores, localización, servicios, barra de notificaciones,
etcétera). También se conoce como Java SDK.

La arquitectura ha sido diseñada para simplificar la reutilización de componentes.

Las aplicaciones pueden publicar sus capacidades y otras pueden hacer uso de
ellas (sujetas a las restricciones de seguridad). Este mismo mecanismo permite
a los usuarios reemplazar componentes.

Una de las mayores fortalezas del entorno de aplicación de Android es que se

aprovecha el lenguaje de programación Java. El SDK de Android no acaba de

53
ofrecer todo lo disponible para su estándar del entorno de ejecución Java (JRE),
pero es compatible con una fracción muy significativa de la misma [8].

Los servicios más importantes que incluye son:

 View: extenso conjunto de vistas, (parte visual de los componentes).

 Resource Manager: proporciona acceso a recursos que no son en código.

 Activity Manager: maneja el ciclo de vida de las aplicaciones y proporciona

un sistema de navegación entre ellas.

 Notification Manager: permite a las aplicaciones mostrar alertas

personalizadas en la barra de estado.

 Content Providers: mecanismo sencillo para acceder a datos de otras

aplicaciones (como los contactos).

2.3.3.5 Aplicaciones.

Este nivel está formado por el conjunto de aplicaciones instaladas en una

máquina Android. Todas las aplicaciones han de correr en la máquina virtual
Dalvik para garantizar la seguridad del sistema [8].

54
Capítulo III. Diseño del Sistema SCADA para equipos móviles
Android con Software Libre.

3.1 Introducción.

Dado un proceso de monitorio y control a través de un sistema SCADA con

software Libre, se concibe la siguiente idea:

Se tiene un proceso de monitoreo y control, que puede ser en un recinto de

difícil acceso y alejado del personal técnico, que se desea supervisar. Lo
que se pone en este recinto es unos microcontroladores (RTU), PC, HMI y
un modem GPRS. Los datos obtenidos por estos hardwares son
transportados a través de un bus o varios buses al servidor (server), que es
supervisado, controlado, mediante un SCADA. Este envío de datos se
realiza a través de USB, Ethernet, Wireless y avisos de alerta por medio de
SMS.

El servidor (MTU), a su tiempo, manda los datos a una base con la finalidad
de almacenar la información. Esta base de datos está integrada dentro del
disco duro del propio servidor. También es posible que el servidor mande la
información a otro PC, PDA, Tablet, Smartphone, Internet y a celulares, es
decir, transmita la información a otros sistemas operativos, en los cuales los
clientes, accionistas, jefes, supervisores, etc. pueden acceder a la
información.

Con lo expuesto se concibe un SCADA con software libre, especialmente para

la plataforma Android.

55
3.2 Arquitectura del Hardware.

En la siguiente Figura 3 – 1 se muestra la arquitectura del Hardware a utilizar.

Figura 3 – 1. Arquitectura del Hardware.

En el diagrama presenta la estructura del Hardware que se utilizará en el

proyecto, se distinguen la MTU (PC servidor), que es el centro de control del
SCADA. Se ramifica una RTU (el microcontrolador Arduino) que son el enlace de
los sensores y el preactuador con el PC servidor, y también la RTU con módulo
GPRS. Y el medio de comunicación a los dispositivos HMI que es a través de
TCP/IP.

56
3.3 Sensores.

Son unos de los componentes de entrada de datos a un sistema de control. El

sensor detecta la variación física del elemento que controla, y lo transmite en
forma de magnitud eléctrica.

Básicamente el sensor dispone de un transductor y de un circuito o sistema

amplificador de la señal. La señal que entrega un sensor debe ser recogida por
el controlador, y en caso necesario, será amplificada y acondicionada para su
posterior uso [9].

3.3.1 Tipos de Sensores.

Determinados sensores, deben estar alimentados eléctricamente conforme a sus

características y se les denomina Sensores Activos.

Otros sensores no necesitan alimentación eléctrica y son llamados Sensores

Pasivos, el hecho de ser pasivo no significa que no sean atravesados por una
corriente eléctrica, por ejemplo una fotorresistencia está conectada a una
corriente eléctrica, pero mientras no exista una variación de la luminosidad la
corriente eléctrica no la atraviesa, es un Sensor Pasivo.

La calificación de los sensores se puede hacer en función de muchos criterios

diferentes:

 Por la forma mecánica de actuar.

 Por los componentes que integran.

 Dependiendo del sitio donde actúa.

 Por la naturaleza de la señal que entrega el sistema en que se acopla.

57
Si la clasificación empleada es la última de la lista que precede se distinguen dos
grupos principales:

 Los Sensores Discretos.

 Los Sensores de tipo Continuos [9].

3.3.1.1 Sensores Discretos.

Son aquellos que entregan una señal de valor concreto en función de la red a
que estén conectados.

Los más comunes son los que adoptan dos valores, Abierto-Cerrado, On-Off,
Activado-Desactivado, Uno-Cero.

Un ejemplo sería el interruptor o pulsador, también llamados de posición, ya que

indica que la pieza está situada en el lugar. Dispone de un contacto cerrado y
otro abierto, la parte con la que tropieza la pieza puede ser un tope, de forma de
bola, o de rueda, graduable o fija, Figura 3 – 2.

Figura 3 – 2. Sensores de Posición: de Bola, de Ruleta y Ajustable.

Los sensores discretos suelen ser más baratos y de gran fiabilidad, gracias a la
sencillez de su funcionamiento. Normalmente, la salida de esta clase de sensores
es un contacto libre de potencial que se cierra y se abre en función del sensor.

58
Algunas de la variantes son: Sensor de Humo, Sensor de Agua, Sensor de Gas,
Sensor por ruptura de Cristal, Sensor de Infrarrojo y una de las variantes de este
tipo el Sensor de SwitchManégtico y Sensor de Movimiento, los cuales se ocupan
en el proyecto [9].

3.3.1.1.1 Sensor Switch Magnético.

El principio de funcionamiento se basa en el efecto que produce un par de

láminas dentro de un campo magnético. Los contactos se colocan dentro de una
ampolleta de vidrio en la que se ha practicado el vacío.

Existen dos tipos en una de ellos los contactos permanecen abiertos cuando no
está próximo al campo magnético, si se aproxima un imán las láminas se unen
cerrando los contactos.

El segundo tipo es todo lo contrario, dentro del campo magnético los contactos
están normalmente abiertos y al separarlos del imán se unen, Figura 3 – 3 [9].

Figura 3 – 3. Sensor Switch Magnético.

3.3.1.1.2 El Sensor de Movimiento.

El Sensor de movimiento, tiene una gran importancia como detector de

presencia, en las instalaciones de seguridad. El avance de la tecnología, ha
disminuido enormemente el tamaño de los sensores, así como las falsas
detecciones debidas a los animales de compañía.

59
Los sensores de movimientos, son dispositivos capaces de emitir y recibir
señales, que le permiten detectar movimiento en la zona de vigilancia.

El sensor de movimiento en cuanto a su zona de instalación se clasifica entre

apto para exterior o para aplicación interior.

Para poder ser instalado un sensor en el exterior debe cumplir las condiciones
de estanqueidad establecidas por la normativa, así como contar con la potencia
de emisión necesaria, dado que la zona de vigilancia es mayor.

El Sensor de Movimiento, en cuanto al sistema de detección que utiliza se

clasifica como [9]:

 Sensor de movimiento de rayos infrarrojos pasivo.

 Sensor de movimiento de microondas.

 Sensor de movimiento dual de rayos infrarrojos y de microondas.

 Sensor de movimiento de ultrasonidos.

3.3.1.1.2.1 Funcionamiento de los detectores de movimiento.

Todo detector de movimiento consta de una unidad emisora y receptora,

conectada a otra unidad central. Ambas unidades generalmente están alejadas
entre sí [9].

3.3.1.1.2.2 Sensor de movimiento de infrarrojos pasivo.

Va equipado con uno dos sensores infrarrojos, que transmiten su señal de salida
a la unidad central. Las variaciones de temperatura uniformes de la zona a vigilar
no son consideradas.

Una rápida variación de la radiación infrarroja, producida por la entrada en escena

de un intruso, dispara la situación de alarma.

60
La unidad central responde ejecutando automáticamente la secuencia de
actuación, previamente programada [9].

3.3.1.1.2.3 Cobertura de un Sensor de Movimiento.

Una de las características del detector de movimiento es el alcance que éstos

poseen. Normalmente su rango es de un poco más de 10 mts de largo y 3 mts
de alto con un ángulo de cobertura entre 90° y 110° de ancho. Los detectores de
movimiento se instalan a una altura recomendable de 2 a 2.4 mts para que
cubran mejor los espacios abiertos [9].

Figura 3 – 4. Cobertura del Sensor de Movimiento.

3.3.1.1.2.4 Sensor de movimientos de microondas.

Van equipados con un emisor de microondas, y un detector doppler que puede

contar hasta con dos canales de recepción, para evitar falsas alarmas. La unidad
central memoriza el nivel de respuesta a la señal emitida recibida de la zona a
proteger, estableciendo un nivel de alarma. Si este nivel, es alcanzado por la
variación de la señal recibida, debida a la entrada de un intruso.

61
La unidad central pasa a situación de alarma, y ejecuta automáticamente la
secuencia de actuación previamente programada. Existen en el mercado,
equipos que incluso llegan a detectar intrusos que se mueven gateando, o
arrastrándose [9].

3.3.1.1.2.5 Sensor dual de rayos infrarrojos y de microondas.

Incorpora los dos sistemas de detección, y sólo se llega a la situación de alarma,

si los dos sistemas alcanzan este nivel. Con este sistema se evita una gran
cantidad de falsas alarmas [9].

3.3.1.1.2.6 Sensor de movimiento de ultrasonidos.

Va equipado con un emisor, y un receptor de ultrasonidos. La variación de la

frecuencia de la onda recibida respecto a la emitida, provoca el disparo de la
alarma en la unidad central, y la ejecución de las acciones previamente
programadas.

Algunos equipos incorporan un regulador de luminosidad que pilota

automáticamente mediante un regulador electrónico, los puntos de luz
previamente determinados.

Los sensores utilizados en el proyecto son: Sensor de Movimiento de infrarrojos

pasivo y Sensor Switch Magnético [9].

3.4 Preactuador (relé, contactores, etc).

Un sistema de control obtiene como salida una señal eléctrica, la cual ha de

activar un actuador. El preactuador es el elemento que hace de interfaz, tomando
como entrada la señal eléctrica y procediendo en el actuador [10].

62
3.4.1 Actuador.

Un actuador es un dispositivo capaz de transformar energía hidráulica, neumática

o eléctrica en la activación de un proceso con la finalidad de generar un efecto
sobre un proceso automatizado. Este recibe la orden de un regulador o
controlador y en función a ella genera la orden para activar un elemento final de
control como, por ejemplo, una válvula [11].

Existen varios tipos de actuadores como son:

 Electrónicos

 Hidráulicos

 Neumáticos

 Eléctricos

Los actuadores hidráulicos, neumáticos y eléctricos son usados para manejar

aparatos mecatrónicos. Por lo general, los actuadores hidráulicos se emplean
cuando lo que se necesita es potencia, y los neumáticos son simples
posicionamientos. Sin embargo, los hidráulicos requieren mucho equipo para
suministro de energía, así como de mantenimiento periódico. Por otro lado, las
aplicaciones de los modelos neumáticos también son limitadas desde el punto de
vista de precisión y mantenimiento [11].

3.4.1.1 Actuadores electrónicos.

Los actuadores electrónicos también son muy utilizados en los aparatos

mecatrónicos, como por ejemplo, en los robots. Los servomotores CA sin
escobillas se utilizaran en el futuro como actuadores de posicionamiento preciso
debido a la demanda de funcionamiento sin tantas horas de mantenimiento [11].

63
3.4.1.2 Actuadores hidráulicos.

Los actuadores hidráulicos, que son los de mayor antigüedad, pueden ser
clasificados de acuerdo con la forma de operación, funcionan en base a fluidos a
presión. Existen tres grandes grupos [11].

 cilindro hidráulico

 motor hidráulico

 motor hidráulico de oscilación

3.4.1.2.1 Cilindro hidráulico.

De acuerdo con su función podemos clasificar a los cilindros hidráulicos en 2

tipos: de Efecto simple y de acción doble. En el primer tipo se utiliza fuerza
hidráulica para empujar y una fuerza externa, diferente, para contraer. El segundo
tipo se emplea la fuerza hidráulica para efectuar ambas acciones. El control de
dirección se lleva a cabo mediante un solenoide. En el interior poseen un resorte
que cambia su constante elástica con el paso de la corriente. Es decir, si circula
corriente por el pistón eléctrico este puede ser extendido fácilmente [11].

3.4.1.2.2 Cilindro de presión dinámica.

Lleva la carga en la base del cilindro. Los costos de fabricación por lo general son
bajos ya que no hay partes que resbalen dentro del cilindro [11].

3.4.1.2.3 Cilindro de Efecto simple.

La barra esta solo en uno de los extremos del pistón, el cual se contrae mediante
resortes o por la misma gravedad. La carga puede colocarse solo en un extremo
del cilindro [11].

64
3.4.1.2.4 Cilindro de Efecto doble.

La carga puede colocarse en cualquiera de los lados del cilindro. Se genera un

impulso horizontal debido a la diferencia de presión entre los extremos del pistón
[11].

3.4.1.3 Actuadores eléctricos.

La estructura de un actuador eléctrico es simple en comparación con la de los

actuadores hidráulicos, ya que sólo requieren de energía eléctrica como fuente
de poder. Como se utilizan cables eléctricos para transmitir electricidad y las
señales, es altamente versátil y prácticamente no hay restricciones respecto a la
distancia entre la fuente de poder y el actuador.

Existe una gran cantidad de modelos y es fácil utilizarlos con motores eléctricos
estandarizados según la aplicación. En la mayoría de los casos es necesario
utilizar reductores, debido a que los motores son de operación continua.

Utilización de un pistón eléctrico para el accionamiento de una válvula pequeña.

La forma más sencilla para el accionamiento con un pistón, sería la instalación

de una palanca solidaria a una bisagra adherida a una superficie paralela al eje
del pistón de accionamiento y a las entradas roscadas.

Existen Alambres Musculares, los cuales permiten realizar movimientos

silenciosos sin motores. Es la tecnología más innovadora para robótica y
automática, como así también para la implementación de pequeños actuadores
[11].

65
3.4.2 Tipos de Preactuadores.

Los más usuales son:

3.4.2.1 Electroválvulas.

Son los preactuadores de los cilindros y actuadores de giro neumáticos e

hidráulicos.

3.4.2.2 Arrancadores estáticos.

Se emplean para conectar o desconectar motores eléctricos restringiendo las

corrientes de arranque [10].

3.4.2.3 Equipos de control de motores eléctricos.

Se emplean para controlar los diferentes tipos de motores, permitiendo

conectarlos o desconectarlos y regular su velocidad de giro. El más habitual es
el variador de frecuencia [10].

3.4.2.4 Relés y contactores.

Se emplean para conectar y desconectar actuadores eléctricos como resistencias

calefactoras o motores.

3.4.2.4.1 Relé.

El relé o relevador es un dispositivo electromecánico. Funciona como un

interruptor controlado por un circuito eléctrico en el que, por medio de una bobina
y un electroimán, se acciona un juego de uno o varios contactos que permiten
abrir o cerrar otros circuitos eléctricos independientes.

Fue inventado por Joseph Henry en 1835.

66
Dado que el relé es capaz de controlar un circuito de salida de mayor potencia
que el de entrada, puede considerarse, en un amplio sentido, como un
amplificador eléctrico. Como tal se emplearon en telegrafía, haciendo la función
de repetidores que generaban una nueva señal con corriente procedente de pilas
locales a partir de la señal débil recibida por la línea. Se les llamaba "re-
levadores" De ahí "relé".

En la Figura 3 – 5 se representa, de forma esquemática, la disposición de los

distintos elementos que forman un relé de un único contacto de trabajo o circuito.

Figura 3 – 5. Estructura de un Relé.

3.4.2.4.1.2 Estructura y funcionamiento.

El electroimán hace bascular la armadura al ser excitada, cerrando los contactos

dependiendo de si es N.A ó N.C (normalmente abierto o normalmente cerrado).
Si se le aplica un voltaje a la bobina se genera un campo magnético, que provoca
que los contactos hagan una conexión. Estos contactos pueden ser considerados
como el interruptor, que permite que la corriente fluya entre los dos puntos que
cerraron el circuito.

67
3.4.2.4.1.3 Tipos de relés.

Existen multitud de tipos distintos de relés, dependiendo del número de

contactos, de su intensidad admisible, del tipo de corriente de accionamiento, del
tiempo de activación y desactivación, etc. Cuando controlan grandes potencias
se les llama contactores en lugar de relés.

Relés electromecánicos

Relés de tipo armadura: pese a ser los más antiguos siguen siendo los más
utilizados en multitud de aplicaciones. Un electroimán provoca la basculación de
una armadura al ser excitado, cerrando o abriendo los contactos dependiendo de
si es NA (normalmente abierto) o NC (normalmente cerrado).

Relés de núcleo móvil: a diferencia del anterior modelo estos están formados por
un émbolo en lugar de una armadura. Debido a su mayor fuerza de atracción, se
utiliza un solenoide para cerrar sus contactos. Es muy utilizado cuando hay que
controlar altas corrientes.

Relé tipo reed o de lengüeta: están constituidos por una ampolla de vidrio, con
contactos en su interior, montados sobre delgadas láminas de metal. Estos
contactos conmutan por la excitación de una bobina, que se encuentra alrededor
de la mencionada ampolla.

Relés polarizados o biestables: se componen de una pequeña armadura,

solidaria a un imán permanente. El extremo inferior gira dentro de los polos de
un electroimán, mientras que el otro lleva una cabeza de contacto. Al excitar el
electroimán, se mueve la armadura y provoca el cierre de los contactos. Si se
polariza al revés, el giro será en sentido contrario, abriendo los contactos o
cerrando otro circuito.

68
Relé de estado sólido

Se llama relé de estado sólido a un circuito híbrido, normalmente compuesto por

un optoacoplador que aísla la entrada, un circuito de disparo, que detecta el paso
por cero de la corriente de línea y un triac o dispositivo similar que actúa de
interruptor de potencia. Su nombre se debe a la similitud que presenta con un
relé electromecánico; este dispositivo es usado generalmente para aplicaciones
donde se presenta un uso continuo de los contactos del relé que en comparación
con un relé convencional generaría un serio desgaste mecánico, además de
poder conmutar altos amperajes que en el caso del relé electromecánico
destruirían en poco tiempo los contactos. Estos relés permiten una velocidad de
conmutación muy superior a la de los relés electromecánicos.

Relé de corriente alterna

Cuando se excita la bobina de un relé con corriente alterna, el flujo magnético en

el circuito magnético, también es alterno, produciendo una fuerza pulsante, con
frecuencia doble, sobre los contactos. Es decir, los contactos de un relé
conectado a la red, en algunos lugares, como varios países de Europa y
latinoamérica oscilarán a 50 Hz y en otros, como en Estados Unidos lo harán a
60 Hz. Este hecho se aprovecha en algunos timbres y zumbadores, como un
activador a distancia. En un relé de corriente alterna se modifica la resonancia de
los contactos para que no oscilen.

Relé de láminas

Este tipo de relé se utilizaba para discriminar distintas frecuencias. Consiste en

un electroimán excitado con la corriente alterna de entrada que atrae varias
varillas sintonizadas para resonar a sendas frecuencias de interés. La varilla que
resuena acciona su contacto, las demás no. Los relés de láminas se utilizaron en
aeromodelismo y otros sistemas de telecontrol.

69
3.4.2.4.1.4 Ventajas del uso de relés.

La gran ventaja de los relés electromagnéticos es la completa separación

eléctrica entre la corriente de accionamiento, la que circula por la bobina del
electroimán, y los circuitos controlados por los contactos, lo que hace que se
puedan manejar altos voltajes o elevadas potencias con pequeñas tensiones de
control. También ofrecen la posibilidad de control de un dispositivo a distancia
mediante el uso de pequeñas señales de control. En un mini PLD (Dispositivo
Lógico Programable) en estos modernos sistemas los relés pueden actuar de
forma programada e independiente lo que supone grandes ventajas en su
aplicación aumentando su uso en aplicaciones sin necesidad de utilizar controles
como PLD's u otros medios para comandarlos. Se puede encender por ejemplo
una bombilla o motor y al encenderlo se apaga el otro motor o bombilla.

3.5 Hardware RTU (Arduino).

Los dispositivos RTU para controlar los sensores como el preactuador es un

microcontrolador de la familia de los Arduino, llamado Arduino Uno, su foto se
muestra en la Figura 3 – 6.

Figura 3 – 6. Arduino Uno.

70
Descripción:

El Arduino Uno utiliza el microcontrolador ATmega328. También el Arduino Uno

utiliza el ATmega16U2 para el manejo de USB. Esto permite ratios de
transferencia más rápidos y más memoria. No se necesitan drivers para Linux o
Mac.

El Arduino es una plataforma computacional física open-source basada en una

simple tarjeta de I/O y un entorno de desarrollo que implementa el lenguaje
Processing/Wiring. El Arduino Uno puede ser utilizado para desarrollar objetos
interactivos o puede ser conectado a software al computador (por ejemplo, Flash,
Processing, MaxMSP). El IDE open-source puede ser descargado gratuitamente
(actualmente para Mac OS X, Windows y Linux).

Sus Característica son:

 Microcontrolador ATmega328.

 Voltaje de entrada 7-12V.

 14 pines digitales de I/O (6 salidas PWM).

 6 entradas análogas.

 32k de memoria Flash.

 Reloj de 16MHz de velocidad.

3.5.1 La conexión del Arduino con los sensores y

preactuador.

Como el Arduino Uno posee 14 pines digitales de I/O, solo se requiere 7 pines
de I/O. Se ocupa 2 pines para el Sensor de Movimiento, 2 para el Switch
Magnético, 3 para el dispositivo On/Off.

71
El Arduino se comunica con el Servidor por medio del protocolo USB. Y por este
medio, obtiene la alimentación que suministra el puerto USB (5VCC).

Los sensores se conectan al Arduino a través de determinados pines

configurados como entrada y se visualiza su estado por medio de Led que indican
si se encuentran activados o desactivados.

El Sensor Switch Magnético es alimentado por el propio Arduino, con una tensión
de 5Vcc. Este switch actúa como un interruptor On/Off.

El sensor de movimiento actúa como un On/Off y se conecta al pin

correspondiente de entrada del Arduino con una tensión de 5Vcc que es
suministrado por el Arduino, sin embargo tiene que ser alimentado el sensor por
una fuente externa de 12 V continuo, para activar su mecanismo de detección de
movimiento.

Hay un pin especialmente asignado para poder controlar un mecanismo de

On/Off (relé), el cual activa cualquier dispositivo que ocupe 220 V alternos, por
medio de un relé que es el interruptor electromecánico. Tiene un indicador Led,
que permite observar si el dispositivo está activado o desactivado.

3.5.2 Conexión del Arduino con el módulo GPRS.

La RTU que envía los mensajes de texto cortos, es un módulo Arduino, llamado
Arduino GM862 Shield.

3.5.2.1 Descripción del ArduinoShield GM862.

El GM862 ArduinoShield permite a la tarjeta Arduino hacer llamadas telefónicas,
enviar mensajes de texto SMS, enviar datos vía GPRS, accionar pines I/O del
módulo y mucho más. Utiliza la biblioteca Arduino-GM862 para manejar el
módem sin necesidad de comenzar un proyecto de nuevo desde cero.

72
El GM862 Shield se conecta a la tarjeta Arduino sin necesidad de cables y deja
el layout de los pines intacto permitiendo conectar un segundo shield en la parte
superior.

Arduino utiliza los pines Digital 0, 1, 2, 3, 4 y RESET para comunicarse con la

tarjeta y prenderla o apargarla desde Arduino. Mientras se esté usando este
shield, éstos pines no se pueden utilizar para otro propósito.

El Shield viene con un conector Molex 52991-0508 (macho) para la conexión con
el modem GM862

3.5.2.2 Descripción del Módulo GM862.

Permite la comunicación M2M (Machine to Machine) con el módulo celular
GM862 PCS. Este pequeño módulo permite conectar un sistema embebido con
cualquier parte del mundo en donde se utilicen redes celulares. Este módulo es
compatible con las redes de 850/900/1800/1900MHz.

Solo necesitas una tarjeta SIM. La cual se puede obtener del teléfono celular. La
tarjeta SIM se inserta en el módulo y listo. Ya es posible hacer llamadas, transferir
datos, enviar mensajes de texto SMS.

El módulo GM862 es controlado por comandos AT. Esto significa que todo lo que
se necesita hacer es enviar caracteres como `ATD 022328107' para hacer una
llamada. Una vez que el módulo se conecta con otro módulo o modem, se
establece una conexión serial y los datos pueden transferirse simplemente
enviando y recibiendo strings en forma serial.

Key features:

 17mA average stand-by, 3.5mA in low-power mode

 250mA average operating current

 New Quad Band Frequency

73
  Data, Voice, SMS, and Fax

 Data speeds up to 57.6kbps

 Supply voltage : 3.4-4.2V

 CMOS Camera Capable

 MMCX Antenna Connector

 Extensive datasheets and forum support

 100% Software and pin compatible with the previous GM862 modules

Figura 3 – 7. Arduino GM862 Shield con módulo GM862.

Esté módulo GPRS, necesita una fuente externa de 9 VCC.

3.6 Hardware del MTU (PC).

El hardware de la MTU (PC) se compone de un procesador AMD Sempron 145

- 2,80 GHz de un núcleo, memoria RAM KINGSTON KVR1333D3S8N9/2G
1333MHZ 2GB.

La placa madre tiene las siguientes características:

Generales

CPU - Soporte para procesadores con Socket AM3 hasta 95W: Procesadores AMD
Phenom™ II X6 / X4 / X3 / X2 (excepto de 920/940) / Athlon II X4 / X3 / X2 / Sempron

74
 - Soporta Six-Core CPU
- Soporta función UCC (Unlock CPU Core – Desbloqueo núcleo CPU)
- Soporta tecnología Cool 'n' Quiet de AMD
- FSB 1000 MHz (2.0 GT/s)
- Soporta tecnología Untied Overclocking
- Soporta tecnología Hyper-Transport

*Para obtener más información, por favor consulte la "Lista de soporte de CPU".

Chipset - NVIDIA® GeForce 7025 / nForce 630ª

- Tecnología de memoria Dual Channel DDR3

- 2 x ranuras DDR3 DIMM
- Soporta memoria DDR3 1600/1333/1066/800 non-ECC, un-buffered

Memoria - Máxima capacidad de memoria del sistema: 8GB*

*Debido a la limitación del sistema operativo, el tamaño de la memoria actual puede ser
menos que 4GB para la reserva del uso del sistema bajo operativo Windows® 32-bit. Para
Windows® 64-bit con CPU de 64-bit no hay tal limitación.

- AMI Legal BIOS 4Mb

- Soporta "Plug y Play"
- ACPI 1.1 conforme Wake Up Events
BIOS
- Soporta jumperfree
- Soporta SMBIOS 2.3.1
- CPU, VCCM multi-ajuste de voltaje

Audio, Video y Conectividad

- Gráficos integrados NVIDIA® GeForce 7025

- DX9.0 VGA, Pixel Shader 3.0
Gráficos
- Tamaño máximo memoria 256MB
- Soporta D-Sub con maxima resolución hasta 1920x1440 @ 60Hz

Audio - 5.1 CH HD Audio (VIA VT1705 Audio Codec)

- Realtek PHY RTL8201EL

- Speed: Ethernet 10/100
LAN
- Soporta Wake-On-LAN
- Soporta PXE

75
Expansión / Conectividad

Ranuras de - 1 x ranura PCI Express x16

expansión - 1 x ranura PCI

- 4 x conectores SATA2 de 3,0 Gb/s, Soporta RAID (RAID 0, RAID 1, RAID 0+1,
RAID 5 y JBOD), NCQ de "Hot Plug"
- 1 x conector ATA100 IDE (Soporta 2 x dispositivos IDE)
- 1 x cabezal Puerto impresora
- 1 x cabezal de puertos COM
Conectores
- conector ventilador Procesador / caja
- conector alimentación 24 pin ATX
- conector alimentación 4 pin 12V
- Conector panel frontal audio
- 2 x cabezales USB 2.0 (soporta 4 puertos USB 2.0)

Panel Entrada/Salida
- 1 x Puerto ratón PS/2
- 1 x Puerto teclado PS/2
Panel trasero
- 1 x puerto VGA
Entrada/salida
- 4 x Puertos USB 2.0 listos-para-usar
- 1 x Puerto con LED LAN RJ-45 (LEDs de Activación/conexión y velocidad)
- Enchufe HD Audio: entrada de línea / Altavoz Delantero / Micrófono

Otras Características / Varios

- ASRock OC Tuner
- Ahorrador de energía inteligente
- Instant Boot
- ASRock Instant Flash
- ASRock OC DNA
Características
- ASRock APP Charger
especiales
- ASRock XFast USB
- Booster Híbrido:
- Control de Frecuencia del Procesador
- ASRock U-COP
- Boot Failure Guard (B.F.G.)

76
 - Drivers, Utilidades, Software Antivirus (Versión de prueba),
CD de Soporte Suite de Software ASRock (CyberLink DVD Suite - OEM y Prueba; Creative Sound
Blaster X-Fi MB - Prueba)

- Guía de instalación rápida, CD de Soporte, Placa entrada/salida

Accesorios
- 2 x cables de datos SATA

- Sensor temperatura Procesador

- Sensor temperatura Chasis
Monitorización del - Sensor de velocidad del ventilador del Procesador
hardware - Sensor de velocidad del ventilador de Chasis
- Silencioso ventilador de la CPU
- Monitorización del Voltaje: +12V, +5V, +3.3V, Vcore

Formato - Formato Micro ATX: 8.5-in x 7.0-in, 21.6 cm x 17.8 cm

- Compatible con Microsoft® Windows® 7 / 7 64-bit / Vista™ / Vista™ 64-bit / XP / XP

Sistema Operativo
64-bit

Certificaciones - FCC, CE, WHQL

3.7 Arquitectura del Software.

En los inicios de la informática, la programación se consideraba un arte y se

desarrollaba como tal, debido a la dificultad que entrañaba para la mayoría de las
personas, pero con el tiempo se han ido descubriendo y desarrollando formas y
guías generales, con base a las cuales se puedan resolver los problemas. A
estas, se les ha denominado Arquitectura de Software, porque, a semejanza de
los planos de un edificio o construcción, estas indican la estructura,
funcionamiento e interacción entre las partes del software. En el libro "An
introduction to Software Architecture", David Garlan y Mary Shaw definen que la
Arquitectura es un nivel de diseño que hace foco en aspectos "más allá de los
algoritmos y estructuras de datos de la computación; el diseño y especificación
de la estructura global del sistema es un nuevo tipo de problema". [12]

77
En este apartado se define el esquema que tiene el software para el
funcionamiento del proyecto.

3.7.1 Arquitectura de la RTU.

Las funciones de la Arquitectura de software dela RTU encargado de reunir a los

sensores y al preactuador se presentan en las figuras 3 – 8, 3 – 9, 3 – 10.

Señal de Selector

Adquirir datos de
Sensor de
Movimiento

Prende Led Verde No Sensor Activo

Si

Prende Led Rojo

Escribe Mensaje en
puerto Serial “2222”

Figura 3 – 8. Arquitectura de Software del Sensor de Movimiento.

78
 Señal de Selector

Adquirir datos de
Sensor de
Magnético

Prende Led Verde No Sensor Activo

Si

Prende Led Rojo

Escribe Mensaje en
puerto Serial “5555”

Figura 3 – 9. Arquitectura de Software del Sensor de Switch Magnético.

79
 Señal de
Preactuador

Preactuador
Preactuador Activo Si Señal Activa No
Desactivado

Figura 3 – 10. Arquitectura de Software del Preactuador.

3.7.2 Funciones del RTU de sensores y preactuador.

Para este fin se establecen funciones que representan a las arquitecturas

mostradas.

3.7.2.1 Función Selector.

La función Selector tiene como objetivo recibir la activación de los sensores como
también la desactivación, por parte de las órdenes que recibe del Servidor, las
variantes para activar o desactivar los sensores como también la salida
conectado al relé. El código es el siguiente: 0, para desactivar el dispositivo
conectado al relé; 1, para activar el dispositivo conectado al relé; 2, para activar
el sensor de movimiento; 3, para desactivar el sensor de movimiento; 4, para
activar el switch magnético; 5, para desactivar el switch magnético. Esta función
está permanentemente revisando la entrada del puerto serie, para realizar su
cometido. Como aparece en la Figura 4 – 11.

3.7.2.2 Función de preactuador; EncenderApagarLed.

La función EncenderApagarLed, tiene como objetivo realizar un On/Off al relé

conectado al Arduino. Recibe como parámetros los valores que entrega

80
 Entrada Serie

Mensaje de Servidor

Señal Preactuador
0
Desactivado

Señal Preactuador
1
Activado

Señal Sensor
2 Movimiento
Activado

Señal Sensor
3 Movimiento
Desactivado

Señal Sensor
4 Magnético
Activado

Señal Sensor
5 Magnético
Desactivado

Figura 3 – 11. Arquitectura de Software de la Función Selector.

81
Selector, para funcionar como interruptor electrónico, mostrando avisos visuales
a usuario, si está abierto o cerrado el interruptor.

3.7.2.3 Función SensorMovimiento.

La función de Movimiento tiene como objetivo recolectar la información que

reciba de un sensor de movimiento externo conectado a uno de los pines del
Arduino. El cual actúa como un interruptor On/Off electrónico. Recibe como
parámetros los valores que entrega la función Selector, para activar o desactivar
el sensor de movimiento físico. La función de SensorMovimiento, está
permanente esperando que se active la señal de alarma que emite el sensor de
movimiento. Al recibir la señal, la función emite una señal de aviso en forma visual
al usuario y, además, envía un aviso al Servidor en forma de un código (una
cadena de caracteres, que es transmitida por el puerto serial; 2222). El cual es
procesado por el Servidor para su accionar. Como muestra la Figura 3 – 8.

3.7.2.4 Función SensorMagnetico.

La función del sensor magnético tiene como objetivo censar si el switch

magnético está abierto o cerrado. Recibe los parámetros del Selector para
activar o desactivar el sensor. Si se abre el switch magnético, la función emite
una señal visual y envía un aviso al servidor por medio de un código (este código
es una cadena de caracteres, que es de la forma de un string emitido al puerto
serial; 5555). El Servidor la procesa para su accionar. Como muestra la Figura 3
– 9.

3.7.3 Arquitectura de software de la RTU GPRS.

La arquitectura software de la RTU GPRS a través del Arduino es la que se
muestra en la figura 3 – 12.

82
 Recibe opciones del
puerto Serial

Puerto Serial Puerto Serial

datos “1” datos “0”

Mensaje SMS, Mensaje SMS,

Alarma Switch Alarma de
Magnético Activo Movimiento Activo

Figura 3 – 12. Arquitectura de Software Módulo GPRS.

Se compone de la función EnvíoSMS.

EnvioSMS tiene como objetivo enviar un mensaje SMS de advertencia al celular

preestablecido, cuando se activa los sensores de Movimiento o Switch
Magnético. Los códigos empleados son: si recibe el carácter 0, a través de puerto
serie, envía un SMS al celular con la indicación “Alarma de Movimiento Activa”.
Si recibe el carácter 1, a través del puerto serial, se envía un SMS con el mensaje
“Alarma Switch Magnético Activo”.

3.7.4 Arquitectura del Software MTU (Servidor).

El ambiente de trabajo en donde se diseña el software SCADA es en Linux

Ubuntu 12.04. Se montan la aplicación de Node.js que actúa como servidor web.

En la MTU se distinguen de las siguientes etapas: La primera es crear el servidor

MTU, La segunda es activar los puertos de comunicación, La tercera es crear el
socket con las sub-etapas del puerto serial.

83
La primera consiste en crear el servidor, con el lenguaje Node.js, en donde se
definen la dirección IP que tiene el servidor y el puerto de escucha, con sus
configuraciones.

La Segunda es abrir el puertos seriales (USB) en donde se realizan las

comunicaciones entre los sensores, preactuador y módulo GPRS.

Y la tercera etapa es abrir una comunicación TCP/IP por medio de socket, para
la comunicación por internet o una red WiFi, entre la MTU y los terminales HMI.
Esta atapa maneja eventos por vía socket, y al depender de que evento reciba
por parte de la HMI es la respuesta que envía por el puerto serial de datos (entre
la MTU y RTU Arduino de los sensores y preactuador).

Las sub-etapas están a la espera de que ocurra un mensaje por parte de la RTU.
Al depender del mensaje se emite un nuevo evento hacia el socket o se escribe
un código al puerto serial, para activar o desactivar los sensores o el preactuador
o enviar un SMS a los celulares.

En la Figura 3 – 13 se muestra la arquitectura de software en el MTU.

3.7.5 Arquitectura de la Aplicación RTU y HMI sobre Android.

Se especifica el diseño que tiene la aplicación Android, separándose en dos

ramas principales una que es la parte lógica de la aplicación y la otra que es el
formato de la interfaz visual, como se ve en la Figura 3 – 14.

3.7.5.1 Apariencia de la Interfaz visual.

Es el HMI del usuario en S.O. Android, aquí se presentan los botones asociados
a funciones internas programadas en la lógica de la aplicación.

Se presentan mensajes emergentes provenientes de funciones internas

programadas que son activadas cuando se presenta un evento proveniente por

84
 Configuración de los
Crear Servidor Configuración del Puertos Seriales USB
Node.js Servidor Node.js para sensores y
GRPS

Crear el Socket de
Datos

Evento Mandar al puerto

EncenderLed Serie carácter “1”

Evento Mandar al puerto

ApagarLed Serie carácter “0”

Evento
Mandar al puerto
EncenderAlarma
Serie carácter “2”
Mov

Evento
Mandar al puerto
ApagarAlarma
Serie carácter “3”
Mov

Evento
Mandar al puerto
EncenderAlarma
Serie carácter “4”
Mag

Evento
Mandar al puerto
ApagarAlarma
Serie carácter “5”
Mag

Emite un evento
Escuchar Puerto Socket “SensorMov”
Emite “2222”
Serie Escribe en Serial
GPRS “0”

Emite un evento
Socket “SensorMag”
Emite “5555”
Escribe en Serial
GPRS “1”

Figura 3 – 13. Arquitectura de Software MTU.

85
 Aplicación Android

Lógica de la Apariencia de la
Aplicación Interfaz

Interfaz de Interfaz de Base de

Botón Encender Luz Interfaz de Eventos
Conexión Datos

Alarma de
Movimiento

Alarma de Switch
Magnético

Base de Datos

SMS

Figura 3 – 14. Arquitectura de la aplicación Android.

el socket de comunicación conectado a la MTU. Más precisamente, cuando un

sensor es activado (sensor de movimiento o sensor switch magnético).

86
La interfaz de Conexión consiste en un cuadro de texto en donde se introduce la
dirección IP del Servidor. Presenta dos botones que Conectan o Desconectan la
aplicación por socket al Servidor (MTU).

La interfaz de Base de Datos es la presentación del registro interno de la fecha y

hora en que se activan o desactivan los sensores y preactuador.

3.7.5.2 La Lógica de la Aplicación.

En esta parte se desarrolla la lógica de la aplicación en Android, no es percibida

por el usuario, solo a través de la interfaz de usuario que arroja las acciones de
las funciones lógicas, HMI.

Se presentan las siguientes funciones relacionadas con los botones.

EncendeLuz, esta función es la encargada de emitir un evento al servidor que

luego emite un comando al puerto serial para Activar o Desactivar el relé.

La función Alarma de Movimiento tiene como objetivo Activar o Desactivar la

Alarma de Movimiento, y a través de la interfaz visual mostrar un mensaje de la
activación o desactivación de la Alarma de Movimiento.

También la Alarma de Switch Magnético tiene como objetivo la activación o

desactivación de esta alarma, mostrando a través de la interfaz el mensaje
respectivo.

La función que permite ver los registros almacenados de la base de datos,

despliega la fecha y hora del acontecimiento de los sensores y preactuador.

Y la función para activar el envío de SMS a celulares preestablecidos.

87
Capítulo IV. Implementación del Sistema SCADA para
equipos móviles con Android.

4.1 Introducción.

En este Capítulo se presenta la implementación del Sistema SCADA para

equipos móviles con S.O. Android y con software Libre. Se presentan los pasos
que se deben realizar para implementar lo planificado en el Capítulo anterior, se
crea la arquitectura de software con los detalles para levantar el proyecto.

Se comienza con las comunicaciones seriales entre las RTU (módulos Arduinos)
y la MTU (Servidor sobre Linux Ubuntu). Se definen las bibliotecas que se
necesitan para el enlace serial entre la RTU y MTU.

Luego, se implementa las arquitecturas de software de las RTU, se señalan los

detalles de las funciones para llevar acabo el objetivo de la adquisición de datos,
por parte de los sensores, la comunicación con el preactuador (relé, contactor,
variador de frecuencia u otro dispositivo que cumpla con este fin) y modem
GPRS.

En la sección de la implementación del software para la MTU, se plantea, un

nuevo enfoque, para el diseño de la plataforma de un Servidor, se propone el uso
de lenguaje JavaScript en el Servidor con el uso del lenguaje Node.js, y el empleo
de Socket en ambiente TCP/IP, todo esto para establecer las comunicaciones
entre la MTU y los clientes móviles que tienen programados el HMI, que les
permite monitorear los sensores remotos e interactuar con el sistema SCADA.

Finalmente, se realiza la implementación de la Aplicación HMI para los equipos

móviles con S.O. Android. Aquí se utiliza el lenguaje Java, y para las
comunicaciones en TCP/IP se implementa socket especialmente diseñado para
la comunicación entre la MTU y el HMI sobre S.O. Android.

88
4.2 Programación de la RTU.

En las siguientes líneas se da el origen del software necesario para la

programación de la RTU.

Se especifica el medio de comunicación con la MTU y la forma de programar

dicho medio.

Se crean las funciones mencionadas en el Capítulo 3. Al detallar el

funcionamiento que tiene en la lógica del proyecto SCADA.

4.2.1 Software para la RTU.

El software necesario para la programación de la RTU (Arduinos) es Arduino IDE

en la versión 1.0.3, que se puede descargar desde www.arduino.cc . El lenguaje
de programación de Arduino IDE es Processing/Wiring. Y el S.O en que se trabaja
es Linux o Windows.

Con Arduino IDE se escriben los programas necesarios para las RTU y también
se posibilita cargar el software en la memoria flash de la RTU.

4.2.2 Comunicación Serial entre el RTU (Módulo Arduino) y MTU

(Servidor).

La comunicación entre la RTU con la MTU, es a través del puerto serial USB.

Para comunicar la RTU con la MTU (Servidor) se necesita introducir un programa,

en la memoria flash del Arduino, que se logra a través de la plataforma de
desarrollo Arduino IDE.

En el caso de la RTU se implementan la librería de software para la comunicación

serial USB, que en el caso de la programación en Arduino IDE, es la librería
Serial.

89
La librería Serial contiene las funciones: begin, print, println, read, avalaible, que
son las funciones que se utilizan en este proyecto.

Para habilitar el puerto, o sea dejarlo listo para la comunicación entre la RTU y la
MTU, se utiliza la función begin de la librería Serial, un ejemplo de cómo se usa
es: begin(Velocidad_del_puerto); (en donde la velocidad el puerto es: 300, 600,
1200, 2400, 4800, 9600, 14400, 19200, 28800, 38400, 57600 ó 115200 baudios).

Para la escritura en el puerto serial se utiliza las funciones: print o println, en

donde la última instrucción, además de escribir en el puerto serie, da un salto de
línea. Para escribir en el puerto serial, se realiza a través de una concatenación
de caracteres, al llamar a la función println de la librería Serial después del punto
del siguiente modo: Serial.println(“Aquí va el texto”);

En cambio, para la lectura del puerto serial, se utiliza la función read que es
llamada de la librería después del punto, del siguiente modo: Serial.read(); Sin
embargo, para saber si existen caracteres por leer en el puerto serie, se utiliza la
función available. Del siguiente modo Serial.available();

La siguiente Figura 4 - 1 muestra un ejemplo.

90
 Figura 4 - 1. Serial Arduino

4.2.3 Implementación del Software para RTU.

Se especifica la lógica de programación según lo planteado en el diseño del

Capítulo 3.7.1. Se crean las funciones que están en el RTU de los sensores y
preactuador (relé, contactores, etc). Detallando su funcionamiento y el propósito
que tienen en el diseño SCADA.

4.2.3.1 Implementación del programa en la RTU de los sensores

y preactuador (relé).

El objetivo del programa, es la adquisición de datos provenientes de los sensores;

en forma de señales digitales on/off. Como también controlar el preactuador; en
forma de interruptor electrónico.

91
Para estos objetivos se crean funciones que cumplen el requisito de controlar
cada sensor por separado y del control del preactuador (relé).

Las funciones que se crean son: Selector, EncenderApagarLed,

SensorMovimiento y SensorMagnetico. La función Selector maneja el control de
los sensores y preactuador. La función EncenderApagarLed controla el
preactuador. La función SensorMovimiento supervisa la activación del sensor
de movimiento. Y la función SensorMagnetico, de igual modo que la función
SensorMovimiento, realiza la acción de sondear la señal de alarma del sensor
switch magnético.

4.2.3.1.1 Función Selector.

La función Selector tiene como fin activar o desactivar los sensores por medio
de códigos emitidos por parte de la MTU, códigos establecidos en el Capítulo
3.7.2.1 que son enviados a la RTU por puerto serial USB. Recibe como
parámetros, de la MTU, en forma de caracteres las siguientes opciones 0, 1, 2,
3, 4 y 5.

Dependiendo del carácter que reciba la función Selector se activa o desactiva las
funciones del respectivo sensor o el control de la función de preactuador.

Para este objetivo, en la función Selector se crean las variables EntradaAlarma,

EntradaLuz, ActivarSensorMov y ActivarSensorMag. Todas de tipo Booleana.

Para detectar el carácter proveniente de la MTU por vía serial USB, se utiliza la
función read de la librería Serial, de Arduino, y la almacena en una nueva
variable EntradaAlarma.

Antes de almacenar el carácter transmitido por la MTU a través del puerto serial
USB, se necesita la función available de la librerial Serial de Arduino. Con esto
se consigue saber si hay algún carácter transmitido por el puerto serial y

92
rescatarlo desde el buffer de Arduino. Y así lograr la lectura del puerto USB por
medio de la función read de la librería Serial.

La función available está adentro de un condicional, if, si hay datos por leer, entra
al condicional y con la función read almacena los datos del Buffer en la variable
EntradaAlarma.

Los datos almacenados en la variable EntradaAlarma son discriminados por un

condicional múltiple, o sea, un Switch. Se crean nuevas variables de tipo
booleano, EntradaLuz, ActivarSensorMov y ActivarSensorMag. La variable
EntradaLuz se asocia a la función EncenderApagarLed (relé). La variable
ActivarSensorMov se enlaza a la función SensorMovimiento y ActivarSensorMag
se relaciona con la función SensorMagnetico.

Los casos del Switch son:

 Carácter 0, en este caso la variable Booleana EntradaLuz toma el valor de

false. Envía al puerto serial los caracteres “aaaa”.

 Carácter 1, en este caso la variable Booleana EntradaLuz toma el valor de

true. Envía al puerto serial los caracteres “bbbb”.

 Carácter 2, en este caso la variable Booleana ActivarSensorMov toma el

valor de true. Envía al puerto serial los caracteres “cccc”.

 Carácter 3, en este caso la variable Booleana ActivarSensorMov toma el

valor de false. Envía al puerto serial los caracteres “dddd”.

 Carácter 4, en este caso la variable Booleana ActivarSensorMag toma el

valor de true. Envía al puerto serial los caracteres “eeee”.

 Carácter 5, en este caso la variable Booleana ActivarSensorMag toma el

valor de false. Envía al puerto serial los caracteres “ffff”.

93
Los detalles de la función se pueden ver en el Apéndice A.

4.2.3.1.2 Función EncenderApagarLed.

La función EncederApagarLed tiene como objetivo ser un interruptor electrónico,

o sea, depende del estado que reciba de la variable EntradaLuz de la función
Selector. El relé (preactuador) se cierra o se abre. Si la variable EntradaLuz tiene
el estado booleano true el relé se cierra con lo que el dispositivo conectado a este
se activa, en el caso de una ampolleta conectada al relé, se enciende. En el caso
que la variable EntradaLuz sea false, se abre el interruptor del relé y se
desconecta el dispositivo. También el estado se observa por medio de Led’s, si
el led que se enciende es de color verde el relé está cerrado en otro caso si el
led que se activa es rojo, el relé está abierto.

Los detalles de la función se presentan a continuación. La función tiene dos

condicionales, if, uno se activa cuando la variable booleana EntradaLuz es true o
cuando es false. Dentro de las funciones if, se encuentran funciones que activan
o desactivan los pines digitales, o sea, suministran un LOW (0V) o un HIGH (5V).
Las variables que se crean para almacenar los pines en forma de un entero son:
la variable Luz para el pin 11, la variable LuzApagado para el pin 5 y la variable
Relé para el pin 12, en donde los pines 11, 5 y 12 son los pines físicos de Arduino.

En cada condicional se llama a la función digitalWrite de la librería I/O de Arduino.

La función digitalWrite activa el pin físico de Arduino en un estado Alto; suministra

una tensión de 5 VCC al pin escogido, con el argumento HIGH. O en un estado
bajo; suministra una tensión de 0 VCC al pin seleccionado, con un argumento
LOW.

La salida de los pines en el primer condicional es:

94
  Luz, toma un valor High

 LuzApagado, toma un valor Low

 Rele, toma un valor High

La salida de los pines en el segundo condicional es:

 Luz, toma un valor Low

 LuzApagado, toma un valor High

 Rele, toma un valor Low

La variable Luz asociado al pin 11 va conectado a un circuito serie con una

resistencia de 1kΩ y un Led verde.

La variable LuzApagado enlazado al pin 5 va conectado a un circuito serie con

una resistencia de un 1kΩ y un Led rojo.

La variable Rele hace accionar al Relé, que cierra a un circuito normalmente

abierto. Con lo que acciona a un dispositivo conectado al relé, en este caso una
ampolleta de 220 VAC.

Los detalles del circuito se muestran en la Figura 4 – 2.

Los detalles de la función se pueden ver en el Apéndice A.

4.2.3.1.3 Función SensorMovimiento.

La función SensorMovimiento tiene como objetivo recoger el estado del sensor

de movimiento, o sea, cuando se active el sensor de movimiento por el hecho de
percibir un movimiento en el rango de acción de dicho sensor. Este envía un
estado de 0 VCC, con lo que la función detecta este estado y escribe en el
puerto serial un código de alarma (como se establece en el Capítulo 3.7.2.3) que
se envía a la MTU.
95
Figura 4 – 2. Esquema del circuito RTU Arduino de los sensores y preactuador.

Está función utiliza la variable suministrada por la función Selector la variable

booleana ActivarSensorMov, se crea una nueva variable de entrada digital, o sea
al detectar 5 VCC, los convierte al valor entero 1 o si entra 0 VCC lo convierte al
valor entero 0, EntradaSensorMov esta asociado al pin 9 físico de Arduino,
también se crea una variable de salida digital SalidaSensorMov relacionado al
pin 10 del Arduino, como también una variable entera SensorMov y una variable
de tipo auxiliar cont1 de tipo entero.

96
Un primer condicional if, que agrupa a las demás funciones, esta condición se
activa si la variable entrega por medio de la función Selector, ActivarSensorMov
es true.

Adentro del condicional, mediante la función digitalRead de la librería I/O de

Arduino se lee el valor lógico (1 para 5 VCC o 0 para 0 VCC) de
EntradaSensorMov asociado al pin 9 conectado al sensor de movimiento y lo
guarda en la variable entera SensorMov.

Si SensorMov es igual al valor lógico 1, llama a la función digitalWrite de la librería

I/O de Arduino, esta función devuelve un 1 o 0 lógico TTL, con los argumentos
HIGH o LOW. Y el pin asociado a SalidaSensorMov toma la salida a 0 VCC.

Si SensorMov es igual al valor TTL 0, llama a la función digitalWrite que escribe

en la variable entera SalidaSensorMov asociado al pin 10 una señal de 5 VCC,
con el argumento HIGH.

En el siguiente condicional, si la variable entera SensorMov tiene el valor entero

0 y la variable entera cont1 es menor que 5, se escribe en el puerto serial USB,
con la función print de la biblioteca Serial de Arduino, imprime la cadena de
caracteres 2222 y la variable entera cont1 aumenta en 1, esto se debe a que solo
se necesita 5 avisos de advertencia al MTU dando cuenta que el sensor de
movimiento se activó.

Y el último condicional devuelve a la variable entera cont1 a cero cuando la

variable entera SensorMov tome el valor entero 1 y la variable entera cont1 sea
mayor que cinco.

El pin 10 de Arduino está asociado a la variable entera SalidaSensorMov y el pin

está conectado en serie con una resistencia de un 1kΩ y un Led rojo.

El pin 9 de Arduino está asociado a la variable entera EntradaSensorMov este

pin está conectado al sensor de movimiento físico.

97
Los detalles del circuito se muestran en la Figura 4 – 2.

Los detalles de la función se pueden ver en el Apéndice A.

4.2.3.1.4 Función SensorMagnetico.

De igual manera que la función SensorMovimiento, la función SensorMagnetico

está a la espera de la activación del sensor switch magnético.

El funcionamiento del sensor es como un interruptor permitiendo el paso de

tensión al pin respectivo del Arduino. El pin 6 del Arduino está asociado a la
variable entera EntradaSensorMag. Al alejar el módulo del switch magnético que
cuenta con un imán, se abre el circuito y no deja pasar la tensión para el pin 6 del
Arduino.

Al igual que la función de SensorMovimiento, el cuenta con un condicional que

reúne a las demás funciones, y las variables que se crean son: SensorMag de
variable entera, EntradaSensorMag de variable entera asociado al pin 6 del
Arduino, SalidaSensorMag de variable entera asociado al pin 7 y cont2 de
variable auxiliar entera.

Al depender del estado que tenga la variable booleana de la función Selector;

ActivarSensorMag depende si se activa o no el sensor switch magnético; si la
variable ActivarSensorMag tiene el valor true, la función recoge los datos del
sensor, si el valor es false; deja de funcionar la función SensorMagnetico.

De idéntica forma la variable entera SensorMag recoge el valor entregado por la

variable entera EntradaSensorMag asociado al pin 6. La conversión a un valor
numérico entero la realiza la función digitalRead, en lógica TTL.

El primer condicional que está adentro comprueba si la variable entera

SensorMag toma el valor cero y si la variable entera cont2 es menor que 5.
Cumplidas estas condiciones, por medio de la función digitalWrite de la librería

98
I/O de Arduino, pone en la variable entera SalidaSensorMag asociado al pin 7el
valor 1 TTL y escribe en el puerto serial USB una cadena de caracteres, 5555,
con la función print de la biblioteca Serial, y la variable entera cont2 aumenta en
uno.

El segundo condicional, cumpliéndose la condición de que la variable entera

SensorMag está en valor 1 y la variable entera cont2 es mayor que 5, retorna
cont2 a cero.

Y el último condicional, cuando SensorMag tomo el valor entero 1 desactiva el

pin 7 asociado a la variable entera SalidaSensorMag, por medio de la función
digitalWrite, con el argumento LOW (0 TTL).

El pin 6 del Arduino asociado a la variable entera EntradaSensorMag está

conectado al switch magnético y en serie con una resistencia de un 1kΩ y un Led
verde.

El pin 7 del Arduino asociado a la variable entera SalidaSensorMag está

conectado en serie con una resistencia de un 1kΩ y un Led rojo.

Los detalles del circuito se muestran en la Figura 4 – 2.

Los detalles de la función se pueden ver en el Apéndice A.

4.2.3.1.5 Función Setup.

La función Setup del ambiente de programación Arduino, es la encargada de

inicializar los componentes por una única vez, esta función está siempre presente
en cualquier programa en Arduino. Es en esta función en donde se define la
velocidad de comunicación que tiene el puerto serial USB, la forma de trabajar
los pines físicos de Arduino, o sea, si son de entrada o salida, y las variables que
se inician por única vez.

99
La velocidad de comunicación que tiene el puerto serial, lo da la función begin de
la biblioteca Serial, la velocidad se establece en 9600 bps.

La configuración de los pines I/O digitales se da por medio de la función pinMode

de la librería I/O de Arduino, y las variables enteras que se definen son:

 Luz asociado al pin 11 como OUTPUT

 LuzApagado asociado al pin 5 como OUTPUT

 Rele asociado al pin 12 como OUTPUT

 EntradaSensorMov asociado al pin 9 como INPUT

 SalidaSensorMov asociado al pin 10 como OUTPUT

 EntradaSensorMag asociado al pin 6 como INPUT

 SalidaSensorMag asociado al pin 7 como OUTPUT

Los sensores están activados al principio, se definen en la función setup las

variables booleana ActivarSensorMov, ActivarSensorMag como true y
EntradaLuz como false.

Los detalles de la función se pueden ver en el Apéndice A.

4.2.3.1.6 Función loop.

Esta función es la que realiza el ciclo permanente de ejecución de las funciones

en el programa de la RTU (Arduino).

Aquí están las funcion Selector; EncenderApagarLed; SensorMovimiento y

SensorMagnetico.

Los detalles de la función se pueden ver en el Apéndice A.

100
4.2.3.2 Implementación del programa de la RTU con el
modem GPRS.

Consiste en una función para el envío de SMS que se crea a partir de la librería
GM862 del módulo GPRS Telit esta función es EnvioSMS. Y una función para
activar el envío de mensajes SMS, Selector.

4.2.3.2.1 La función Selector.

La función Selector tiene como objetivo activar la función EnvioSMS.

La función Selector funciona de la siguiente manera:

Si se detecta por el puerto serial GPRS el carácter A la variable booleana SMS

toma el valor de true. En caso contrario si recibe el carácter D la variable booleana
toma el valor false. Cuando la variable SMS tiene el valor true el módulo está
dispuesto para enviar mensajes SMS a celulares preestablecido. Al tomar la
variable SMS el valor false, se desactiva el envío de mensajes SMS a los
celulares preestablecidos. Como muestra la Figura 4 – 3.

101
 Figura 4 – 3. Función Selector en el módulo GPRS.

4.2.3.2.2 La función de EnvioSMS.

La función tiene como objetivo el envío de un mensaje de alertas a través de

mensajes SMS a celulares preestablecidos. Así se alerta al personal de la
activación de las alarmas del sistema.

Si se recibe el carácter 0 por el puerto serial del módulo GPRS se envía un

mensaje SMS al celular previamente registrado, con la función sendSMS de la
librería GM862. Se envía el siguiente mensaje “Sensor de Movimiento, Activo”

De forma similar, si se recibe el carácter 1 por el puerto serial del módulo GPRS
se envía un mensaje SMS al celular previamente registrado, con la función
sendSMS de la librería GM862. Se envía el siguiente mensaje “Sensor Switch
Magnético, Activo”. Como muestra la Figura 4 – 4.

102
 Figura 4 – 4. Función EnvioSMS en el módulo GPRS.

4.2.3.2.3 Función Setup.

La función setup tiene como fin activar el módulo GPRS y registrarlo en la red
celular GPRS.

Se inicia con estableciendo la velocidad del puerto serial a 9600 baudios con la
función Serial.begin(9600). Se continúa con el encendido del modem GPRS con
la función switchOn de la librería GM862. Se inicializa los comandos AT
necesarios para dejar el modem dispuesto a la comunicación mediante la función
init de la librería GM862. Luego se registra la tarjeta SIM en la red celular de la
compañía a elección.

El envío de SMS de alertas se inicia como desactivado.

103
La función setup se muestra en la Figura 4 – 5.

Figura 4 – 5. Función Setup del módulo GPRS.

4.2.3.2.4 Función Loop

Las funciones que agrupa la función loop son Selector y EnvioSMS. El contenido
de la función loop repite en forma cíclica las funciones que contiene. Como
muestra la Figura 4 – 6.

Figura 4 – 6. Función Loop en módulo GPRS.

Los detalles del programa se encuentran en el Apéndice A.

104
4.3 Programación de la MTU.

En la presente sección se da a conocer las librerías necesarias para la

implementación del software necesario para la MTU.

Se especifican los medios de comunicación de la MTU con la RTU y la forma de

programar dicho medio.

Se crean las funciones necesarias para la obtención de los objetivos del Capítulo
3. Al detallar el funcionamiento que tiene en la lógica del proyecto SCADA.

4.3.1 Software para la MTU.

El ambiente de trabajo de la MTU es S.O Linux Ubuntu en la versión 12.10. Ahí

se crea el servidor MTU, con diversos lenguajes de programación. Se implementa
JavaScript en el lado del Servidor con las librerías de Node.js y sus extensiones.

El software es de libre adquisición y se descarga del terminal de Ubuntu, del

siguiente modo.

Se abre un terminal en Ubuntu y se introduce las siguientes líneas de comando.

Para la instalación de Node.js, es la compilación de programas especializados en

la creación del Servidor en la MTU:

 sudo apt-get install python-software-properties Instala Python en Ubuntu

 sudo apt-add-repository ppa:chris-lea/node.js Actualiza el instalador para

instalar Node.js

 sudo apt-get update Actualiza el instalador

 sudo apt-get install nodejs npm Instala Node.js y npm instalador de

extensiones de Node.js en Ubuntu

Luego se necesita instalar la extensión Express, Jade, Socket.IO y SerialPort2.

105
Express es una extensión para desarrollar el servidor en lenguaje JavaScritp en
la MTU, al hacer más fácil el desarrollo. Jade es un intérprete para la creación de
páginas web en una forma más corta. Socket.IO es la extensión para la
comunicación de Socket por vía TCP/IP y SerialPort2 es la librería para las
comunicaciones por puerto serial USB con la RTU (Arduino) de los sensores,
preactuador y la RTU con módulo GPRS.

Para ello se introduce los siguientes comandos en la terminal de Ubuntu.

 sudo npm install express

 sudo npm install jade

 sudo npm install socket.io

 sudo npm install serialport2

Con todo esto se puede empezar a crear el programa en la MTU para el servidor
con Node.js.

4.3.2 Comunicación Serial entre la MTU (Servidor) y el RTU de los

sensores y preactuador.

Para lograr el objetivo de la comunicación de la MTU con la RTU (Arduino) es por

medio de la extensión de Node.js a través de la librería SerialPort2.

Esta librería, SerialPort2, es un programa para el manejo de las comunicaciones

del puerto serial USB, que implementa el lenguaje Node.js

106
En la Figura 4 – 7 se presenta la comunicación del puerto serial entre la MTU y
la RTU de los sensores y preactuador.

Figura 4 – 7. Programa de comunicación del puerto Serial entre la MTU y la

RTU de los sensores y preactuador.

En la línea 26 se llama a la librería SerialPort2 y se almacena en la variable

SerialPort. Después en la línea 28 se crea la variable sp que hereda las funciones
que contiene la variable SerialPort. Luego, en la línea 30 se abre el puerto serial,
por medio de la función open que es heredada de la librería SerialPort, en este
caso como se trabaja en Linux Ubuntu la dirección del puerto serial es
/dev/ttyACM0 si se le agrega otro dispositivo USB, el nuevo dispositivo tiene la
dirección /dev/ttyACM1, etc. Sigue la velocidad de transmisión, 9600 baudios; los
bits de datos, 8; la paridad ninguna; el bit de parada, 1 y el control de flujo, false.

Para escuchar por el puerto serial se utiliza la función on que hereda de la

variable SerialPort, o sea, sp.on(“data”, funtion(data){Aquí_van_las_funciones}),
donde sp es la variable de SerialPort(). Y en la escritura por el puerto serial se
utiliza el comando write(“Aquí_se_escribe”) función que hereda de la variable
SerialPort.

107
4.3.3 Comunicación Serial entre la MTU (Servidor) y el RTU
(Módulo GPRS).

Para lograr la comunicación de la MTU con la RTU (Arduino con módulo GPRS)
es realizado por medio de la extensión de Node.js a través de la librería
SerialPort2.

Esta librería, SerialPort2, es un programa para el manejo de las comunicaciones

del puerto serial USB, que implementa el lenguaje Node.js. Se muestra en la
Figura 4 – 8.

Figura 4 – 8. Programa de comunicación del puerto Serial entre la MTU y la

RTU del módulo GPRS.

En la línea 56 se crea la variable gprs que hereda las funciones que contiene la
variable SerialPort. Luego, en la línea 57 se abre el puerto serial, por medio de la
función open que es heredada de la librería SerialPort, en este caso como se
trabaja en Linux Ubuntu la dirección del puerto serial es /dev/ttyACM1. Sigue con
establecer la velocidad de transmisión, 9600 baudios; los bits de datos, 8; la
paridad ninguna; el bit de parada, 1 y el control de flujo, false.

108
4.3.4 Comunicación por Socket entre la MTU y la RTU con la
interfaz HMI.

La comunicación se realiza a través del protocolo TCP/IP. Por este medio se

establece un enlace a través de socket, más precisamente, la extensión para las
comunicaciones por socket, socket.io ( www.socket.io ) para Node.js.

Esta librería contiene funciones para el manejo de eventos en formato JSON.

Para utilizar socket.io, se comienza al crear una variable que herede de la librería
socket.io, por medio de la función require que es proporcionada por Node.js y en
la dirección IP que proporciona Node.js en la MTU. Como en la siguiente línea.
En donde server es la dirección IP con su respectivo puerto que crea el servidor
Node.js en la MTU.

var io=require('socket.io').listen(server);

Luego para establecer la conexión entre la RTU y MTU por medio de TCP/IP. Se
utiliza las funciones sockets.on heredadas de la librería socket.io a través de la
variable io. Con los argumentos “connection” y la creación de una función
implícita con el argumento “socket”, que se utiliza para el restos de los eventos
que se programan. Como aparece en la siguiente línea:

io.sockets.on('connection', function(socket){

… funciones que se utilizan en la programación

});

4.3.5 Implementación del Software para la MTU.

La implementación del programa para la MTU, se procede según lo expuesto en

el Capítulo 3.7.4. Se programa en el lenguaje JavaScript en el servidor, por medio

109
de Node.js. Gracias a las librerías mencionadas anteriormente. Se establece las
comunicaciones con las RTU, vía puerto serial USB y por TCP/IP.

4.3.5.1 Programa del servidor MTU.

El Node.js se basa en el lenguaje JavaScript, sin embargo, se implementa en el

lado del PC Servidor de servicios web. Con la facilidad de crear un servidor web
en la propia MTU. Se logra administrar las conexiones que se realizan a través
de un servidor web.

Para lograr este objetivo se implementan librerías externas compatibles para

Node.js, que se detallan a en la Figura 4 – 9.

Figura 4 – 9. Crear programa Servidor para la MTU con Node.js

En la línea 1 se llama a la librería externa express con la función de Node.js

require y se almacena en la variable express, que hereda las funciones de la
librería express. Luego en la línea 2 se realiza el mismo proceso con la librería
http, se guarda en la variable http que hereda las funciones que implementa la
librería http. En la línea 3 se crea una nueva variable para configurar el servidor
web en la MTU. Y Finalmente, en la línea 4 se crea el servidor web con Node.js
y se almacena en la variable server

Luego se configuran los parámetros del Servidor, se comienza con la carpeta en

donde están los archivos para la interfaz HMI de los RTU. Que se detallan en la
Figura 4 – 10.

110
 Figura 4 – 10. Configuración del Servidor MTU (Servidor web).

En la línea 6 se llama a la función set de la librería express en donde se determina

el directorio views en donde se sitúan los archivos de la interfaz HMI.

En la línea 7 con la función configure de la librería express, le dice a Node.js que

los archivos que se ocupan están contenidos en el directorio creado
anteriormente.

En la línea 11 con comando get de la librería express le dice a Node.js que la

primera página que se carga al acceder por Internet o WiFi es la dirección web
del servidor, escrita en lenguaje Jade, index.jade.

Finalmente, en la línea 15 se escoge el puerto de comunicación TCP/IP en donde

escucha, con el comando listen(8080), de la librería http de Node.js. Con esto se
da como terminado la creación del servidor Web para la MTU con Node.js.

4.3.5.2 Programa de socket

Este es una parte del programa principal de la MTU, aquí se especifica las
comunicaciones que tienen con las RTU y visualizadas en el HMI. El
funcionamiento es por eventos, o sea, nombres claves que son transmitidos por
TCP/IP al realizar la conexión por socket. Los detalles a continuación se
presentan, Figura 4 – 11.

111
 Figura 4 – 11. Programa de eventos por socket.

Al recibir el evento a través de TCP/IP, conectado por socket, se ejecutan las

funciones establecidas, que controlar el envío de mensajes en forma de
caracteres a la RTU de los sensores y preacuador (relé) a través del puerto serial
USB.

112
4.3.5.2.1 Evento que controla el preactuador.

Este evento controla el relé conectado a la RTU (Arduino), para abrir o cerrar el
interruptor del relé.

De la Figura 4 – 11 desde la línea 59 a la 71, son los eventos que controlan el

preactuador (relé).

Con la función on, de la librería socket.io, que recoge el evento transmitido por
socket. Al llegar el evento EncenderLed la función socket.on se activa y ejecuta
los siguientes comandos. Llama a la función write de la librería SerialPort2, que
escribe el carácter 1 en el puerto serial de la RTU que controla los sensores y el
preactuador (relé). Imprime un mensaje en la consola de Node.js con el mensaje
“Se enciende Led” y por último vacía la variable que almacena el contenido del
buffer de entrada del puerto serial a la MTU, readData.

Del mismo modo a lo mencionado anteriormente, con la función on, el evento a

esperar es ApagarLed, en este caso llama se activa la función y se ejecuta: la
función write de la librería SerialPort2, escribe el carácter 0 en el puerto serial de
salida de la MTU, e imprime en la consola de Node.js el mensaje “Se apaga Led”
y vacía la variable que almacena el contenido del buffer de entrada del puerto
serial a la MTU, readData.

Los detalles se pueden ver en el Apéndice B.

4.3.5.2.2 Evento que controla el Sensor de Movimiento.

Este evento realiza la acción de activar o desactivar el sensor de movimiento al

trasmitir por el puerto serial el código respectivo; 2 para Activar y 3 para
Desactivar.

De la Figura 4 – 11 desde la línea 73 a la 83, son los eventos que controlan el

sensor de movimiento.

113
Con la función on, de la librería socket.io, que recoge el evento transmitido por
socket. Al llegar el evento EncenderAlarmaMov la función socket.on se activa y
ejecuta los siguientes comandos. Llama a la función write de la librería
SerialPort2, que escribe el carácter 2 en el puerto serial de la RTU que controla
los sensores y el preactuador (relé). Imprime un mensaje en la consola de Node.js
con el mensaje “Se envió encender alarma de movimiento” y por último vacía la
variable que almacena el contenido del buffer de entrada del puerto serial a la
MTU, readData.

Del mismo modo a lo mencionado anteriormente, con la función on, el evento a

esperar es ApagarAlarmaMov, en este caso llama se activa la función y se
ejecuta: la función write de la librería SerialPort2, escribe el carácter 3 en el puerto
serial de salida de la MTU, e imprime en la consola de Node.js el mensaje “Se
envió apagar alarma de movimiento” y vacía la variable que almacena el
contenido del buffer de entrada del puerto serial a la MTU, readData.

4.3.5.2.3 Evento que controla el Switch Magnético.

Este evento realiza la acción de activar o desactivar el sensor de switch

magnético al trasmitir por el puerto serial el código respectivo; 4 para Activar y 5
para Desactivar el sensor.

De la Figura 4 – 11 desde la línea 85 a la 95, son los eventos que controlan el

sensor de switch magnético.

Con la función on, de la librería socket.io, que recoge el evento transmitido por
socket. Al llegar el evento EncenderAlarmaMag la función socket.on se activa y
ejecuta los siguientes comandos. Llama a la función write de la librería
SerialPort2, que escribe el carácter 4 en el puerto serial de la RTU que controla
los sensores y el preactuador (relé). Imprime un mensaje en la consola de Node.js
con el mensaje “Se envió encender alarma magnética” y por último vacía la

114
variable que almacena el contenido del buffer de entrada del puerto serial a la
MTU, readData.

Del mismo modo a lo mencionado anteriormente, con la función on, el evento a

esperar es ApagarAlarmaMag, en este caso llama se activa la función y se
ejecuta: la función write de la librería SerialPort2, escribe el carácter 5 en el puerto
serial de salida de la MTU, e imprime en la consola de Node.js el mensaje “Se
envió apagar alarma magnética” y vacía la variable que almacena el contenido
del buffer de entrada del puerto serial a la MTU, readData.

Los mensajes en la consola de Node.js son para monitorear el funcionamiento

del programa.

Los detalles se pueden ver en el Apéndice B.

4.3.5.3 Programa de la comunicación entre la MTU y la RTU de

sensores y preactuador a través de puerto serial USB.

Este programa tiene como objetivo estar a la espera de señales que provienen
de la RTU (Arduino). Al depender de los valores que presenta se ejecuta una
acción predeterminada, se presenta en la Figura 4 – 12.

Este programa es el puente entre las comunicaciones la RTU de los sensores y

la RTU con la interfaz HMI. El funcionamiento es, si recibe un mensaje, en forma
de una secuencia de caracteres proveniente de la RTU (Arduino), este los
examina y si concuerda con el código establecido; si recibe el string 2222 activa
el aviso del sensor de movimiento y si recibe el string 5555 activa el aviso del
sensor switch magnético. Ejecuta la acción de emitir un evento a todos los RTU
con interfaz HMI conectados en ese momento.

Los detalles del programa se presentan a continuación.

115
Figura 4 – 12. Parte del programa de la MTU, de la recepción de señales del
RTU de los sensores y preactuador (relé).

En la línea 144, la MTU está a la espera de los mensajes que recibe dela RTU
de los sensores (Arduino) por puerto serial USB, la función se inicia con la función
on de la librería de SerialPort2, que llama al argumento “data”, con esto el puerto
serial está a la espera de recibir los datos que se guardan en el buffer del puerto
serial en la MTU. Después de esto, los datos son almacenados en una variable
local, readData, previamente son convertidos a una cadena String.

116
Al depender de que cadena contenga la variable readData, es comparada en los
condicionales, y si la cadena contiene, a lo menos un carácter del código; 2222
para sensor de movimiento o 5555 para sensor switch magnético. Ejecuta las
funciones que contienen.

4.3.5.3.1 Sensor de Movimiento.

Entre la línea 150 y 163 de la Figura 4 – 12 se presenta el programa para el

código de activación 2222. Entra a una condición, si la variable cont0 es idéntica
a 0 se emite un nuevo evento SensorMov, con el comando emit de la librería
socket.io, que se envía a todos los RTU con interfaz HMI conectados en ese
momento. También escribe el carácter 0 en el puerto serial del módulo GPRS.
En la línea 157, se imprime en la consola de Node.js un mensaje para verificar el
funcionamiento del programa con el mensaje “Se envía Alarma de movimiento”,
la variable booleana AlarmaSensorMovDB toma el valor true esta variable se
almacena en la base de datos creada y la variable cont0 aumenta en uno, reset
toma el estado de true, que sirve para almacenar la variable
AlarmaSensorMovDB en la base de datos y se vacía la variable readData, para
poder recibir nuevos datos del buffer transmitidos por el puerto serial USB a la
MTU.

4.3.5.3.2 Sensor Switch Magnético.

Entre la línea 165 y 177 de la Figura 4 – 12 se presenta el programa para el

código de activación 5555. Al cumplirse esto se emite un nuevo evento
SensorMag, con el comando emit de la librería socket.io, que se envía a todos
los RTU con interfaz HMI conectados en ese momento. También escribe el
carácter 1 en el puerto serial del módulo GPRS. En la línea 171, se imprime en
la consola de Node.js un mensaje para verificar el funcionamiento del programa
con el mensaje “Se envió Alarma magnética”, la variable booleana
AlarmaSensorMagDB toma el valor true esta variable se almacena en la base de

117
datos creada y la variable cont1 aumenta en uno, reset toma el estado de true,
que sirve para almacenar la variable AlarmaSensorMovDB en la base de datos y
se vacía la variable readData, para poder recibir nuevos datos del buffer
transmitidos por el puerto serial USB a la MTU.

4.3.5.4 Base de Datos en la MTU.

En este apartado se presenta la creación y manipulación de una base de datos

en la MTU. Registra los estados de los sensores y preactuador, al proporcionar
el estado del sensor, activo o desactivo, la hora y fecha en que se presenta el
evento.

El lenguaje que se ocupa en la base de datos es SQLite. El módulo para la

implementación en Node.js es sqlite3. El proceso para integrar la librería en
Node.js es abrir un terminal en Linux y escribir la siguiente línea:

 sudo npm install sqlite3

Hecho este proceso se puede ocupar la librería en el código fuente del servidor
Node.js en la MTU (Linux).

Adentro del código fuente del servidor (MTU con S.O. Linux) se introduce las
siguientes líneas:

La primera hace referencia al módulo SQLite de Node.js y lo almacena en la

variable sqlite3. La segunda es una variable que se ocupa más tarde.

Se crean las funciones crearbasedatos, crearTabla y insertarFila. La función

crearbasedatos es la encargada de crear la base de datos, nombrada
base_datos_monitor.sqlite. En la función crearTabla se crea la tabla que contiene

118
la base de datos. Y en la función insertarFila se inserta una fila nueva en la base
de datos, como la presenta la Figura 4 – 13.

La función crearTabla de la base de datos especifica el contenido y el tipo de dato

que almacena, en este caso se almacenan dos tipos de dato; uno dato booleano
y otro de tipo texto. Los booleanos almacenan los estados de los sensores y
preactuador, con un valor true para cuando esta activado y false cuando esta
desactivado. Los de tipo texto almacena la hora y fecha de los eventos de los
sensores y preactuador. A cada evento, activar o desactivar los sensores o
preactuador, se acompaña de un tipo booleano y de texto; almacena el estado
del suceso y la hora, fecha que se acciona. El registro de la hora y fecha es la
que posee la MTU (Servidor Linux Ubuntu). Como se presenta en la Figura 4 –
13.

La funcion insertarFila, inserta una nueva fila en la tabla de la base de datos. Se

insertan nuevas filas cuando se activa o desactiva un sensor o preactuador, y
registra el estado, la hora y fecha en que ocurre. Como muestra la Figura 4 – 13.

119
 Figura 4 – 13. Funciones de la Base de Datos.

4.3.5.4.1 Eventos que son almacenados en la Base de Datos.

La base de datos registra los eventos provenientes de los sensores y preactuador

cuando se activa o desactiva estos. Las variables asociadas a su correspondiente
sensor o preactuador se almacenan cuando la RTU (Arduino) envía un código al
puerto serial que luego es leído por la MTU (Servidor Linux Ubuntu) almacenando
120
en la correspondiente variable el estado del evento, hora y fecha del sensor o
preactuador.

El evento del preactuador sucede cuando se recibe la cadena de caracteres

“aaaa” para desactivar el preactuador (relé) o al recibir el string “bbbb” para
activar el relé, a través del puerto serial USB.

Si recibe el string “bbbb” la variable de la base de datos asociado al preactuador,

LedDB, toma el valor de true, la variable LedDBTime almacena la hora y fecha
del sistema MTU (S.O. Linux Ubuntu) en que ocurre el evento. Emite un evento
al socket EnciendeLedDB a las RTU con interfaz HMI conectadas. Reset toma el
valor true y se vacía la variable readData.

De manera similar, cuando se recibe el string “aaaa” del puerto serial USB, la
variable LedDB toma el valor false, se registra la fecha y hora del evento en la
variable LedDBTime, se emite un evento al socket; ApagaLedDB. La variable
reset toma el valor true y se vacía la variable readData. Como muestra la Figura
4 – 14.

Figura 4 – 14. Eventos del preactuador emitido por la RTU a la MTU.

121
El evento del sensor de movimiento sucede cuando se recibe la cadena de
caracteres “dddd” para desactivar el sensor de movimiento o al recibir el string
“cccc” para activar el sensor de movimiento, a través del puerto serial USB.

Si recibe el string “cccc” la variable de la base de datos asociado al sensor de

movimiento, SensorMovDB, toma el valor de true, la variable SensorMovDBTime
almacena la hora y fecha del sistema MTU (S.O. Linux Ubuntu) en que ocurre el
evento. Emite un evento al socket; EnciendeSensorMovDB a las RTU con interfaz
HMI conectadas. Reset toma el valor true y se vacía la variable readData.

De manera similar, cuando se recibe el string “dddd” del puerto serial USB, la
variable SensorMovDB toma el valor false, se registra la fecha y hora del evento
en la variable SensorMovDBTime, se emite un evento al socket
ApagaSensorMovDB. La variable reset toma el valor true y se vacía la variable
readData. Como muestra la Figura 4 – 15.

Figura 4 – 15. Eventos del sensor de movimiento emitido por la RTU a la MTU.

122
El evento del sensor switch magnético sucede cuando se recibe la cadena de
caracteres “ffff” para desactivar el sensor switch magnético o al recibir el string
“eeee” para activar el sensor switch magnético, a través del puerto serial USB.

Si recibe el string “eeee” la variable de la base de datos asociado al sensor switch

magnético, SensorMagDB, toma el valor de true, la variable SensorMagDBTime
almacena la hora y fecha del sistema MTU (S.O. Linux Ubuntu) en que ocurre el
evento. Emite un evento al socket; EnciendeSensorMagDB a las RTU con
interfaz HMI conectadas. Reset toma el valor true y se vacía la variable readData.

De manera similar, cuando se recibe el string “ffff” del puerto serial USB, la
variable SensorMagDB toma el valor false, se registra la fecha y hora del evento
en la variable SensorMagDBTime, se emite un evento al socket;
ApagaSensorMagDB, la variable reset toma el valor true y se vacía la variable
readData. Como muestra la Figura 4 – 16.

Figura 4 – 16. Eventos del sensor switch magnético emitido por la RTU a la MTU.

123
Finalmente se procede a insertar una nueva fila en la tabla Monitor de la Base de
Datos creada. Solo cuando la variable reset es true. Se llama a la función
insertarFila, luego se lee el contenido de la tabla mediante la función db.all de la
librería sqlite3 de Node.js solamente en el último registro y se envía los datos por
medio de un evento socket; DatoBD, en formato JSON a la RTU con interfaz HMI
(Android). Como muestra la Figura 4 – 17.

Figura 4 – 17. Creación de nueva fila en tabla Monitor y envío de los datos a RTU
con interfaz HMI.

Los detalles se pueden ver en el Apéndice B.

124
4.3.6 Implementación de la interfaz HMI en la MTU.

En este apartado se crea una página web para la interfaz HMI. Con lo que se
consigue el acceso de cualquier dispositivo que cuente con un navegador web
para supervisar el sistema SCADA.

La creación de la página web, se realiza por medio del intérprete Jade, una forma
más corta de escribir código HTML. Esta página web se carga al ingresar a la
dirección IP de la MTU, Servidor Node.js. En la primera parte se establece el
formato del documento web y los script que necesita. Como se muestra en la
Figura 4 – 18.

Figura 4 – 18. Formato de la página web.

El comienzo del código de la página web se especifica el tipo de formato que

tiene con doctype 5 le dice al servidor que se trata de un documento HTML5. En
la línea 2, html se especifica el lenguaje de la página web en este caso español.

Entre la línea 3 y 7 se especifica la cabecera con el título de la ventana, el

formato del texto, los script que necesita, el primer script especifica la librería el
socket.io y el siguiente añade la librería jquery, en la página. Luego se abre un
script que contiene lo necesario para trabajar en la página web.

En la línea 9, se establece la variable que almacena la función connect de la

librería socket.io en websocket.

125
Luego se presenta el script en donde se maneja las propiedades de la página
web por medio del lenguaje jquery, que maneja los eventos de los botones de la
página web y las alertas provenientes de la MTU.

Se compone de las siguientes partes, la sección para las alertas de los sensores
provenientes de la MTU. Los eventos de los botones, al ser presionados, con la
respectiva ejecución del programa.

4.3.6.1 Aviso de Alertas.

La función que cumple el programa en la página web en la interfaz del HMI de la

RTU. Es dar aviso de la activación de los sensores del RTU, a través del MTU
por medio de conexión por socket y trasportado a través de TCP/IP. Como
muestra la Figura 4 – 19.

Figura 4 – 19. Evento de alarma de sensores RTU.

4.3.6.1.1 Alerta de Sensor de Movimiento.

Su función es emitir una alerta al recibir el evento SensorMov a través del socket,
cuyo aviso lo implementa el comando alert de la librería JavaScript, con el
mensaje de “Alarma de movimiento Activada”.

126
4.3.6.1.2 Alerta del Switch Magnético.

Su función es emitir una alerta al recibir el evento SensorMag a través de socket,

cuyo aviso lo implementa el comando alert de la librería JavaScript, con el
mensaje de “Alarma magnética Activada”.

4.3.6.2 Eventos al presionar botones.

Son los eventos que se activan cuando se presionan los botones de la interfaz
HMI. Su función es seleccionar la opción que disponga el usuario en la interfaz
HMI. Para este cometido se tienen tres tipos de funciones, Activar o Desactivar
Relé; Activar o Desactivar Sensor de Movimiento; Activar o Desactivar Sensor
Switch Magnético. El programa aparece en la Figura 4 – 20.

4.3.6.2.1 Activar o Desactivar Relé.

En la línea 64 de la Figura 4 – 21, en el body de la página web se introduce el

código fuente para representar a los botones, líneas 67 a la 70, Encender y
Apagar el relé con el comando input de la librería HTML se crean los botones y
se los identifica con el parámetro id de la función input de la librería HTML al ser,
id= “enciende” y id= “apaga”, estos botones con el comando de click, de la librería
jquery, cuando son presionados se realizan las acciones siguientes: Entre las
líneas 27 y 37 de la Figura 20. Si el botón Encender si presiona o Apagar, el
socket de la librería socket.io emite un evento llamado EncenderLed o
ApagarLed, este evento es capturado por el servidor MTU y envía su
correspondiente código al puerto serial USB del RTU de los sensores y
preacuador, que luego se procesa por el RTU para cerrar o abrir el relé.

127
 Figura 4 – 20. Eventos al presionar botones en la HMI.

4.3.6.2.2 Activar o Desactivar Sensor de Movimiento.

En la línea 64 de la Figura 4 – 21, en el body de la página web se introduce el

programa para representar a los botones, líneas 73 y 76, Encender y Apagar
que activan o desactivan el sensor de movimiento, con el comando input de la
librería HTML se crean los botones y se los identifica con el parámetro id de la

128
función input de la librería HTML al ser, id= “enciendeMovimiento” y id=
“apagaMovimiento”, estos botones con el comando click de la librería jquery,
cuando se presiona realiza la acciones siguientes: Entre las líneas 39 y 49 de la
Figura 4 – 20. Si el botón Encender se presiona o Apagar, el socket de la librería
socket.io, emite un evento llamado EncenderAlarmaMov o ApagarAlarmaMov,
este evento es capturado por el servidor MTU y envía su correspondiente código
al puerto serial USB del RTU de los sensores y preacuador, que luego se procesa
por el RTU para activar o desactivar el sensor de movimiento.

Figura 4 – 21. Body de la página web, interfaz HMI.

4.3.6.2.3 Activar o Desactivar el Switch Magnético.

En la línea 64 de la Figura 4 – 21, en el body de la página web se introduce el

código fuente para representar a los botones, líneas 79 a la 82, de Encender y
Apagar que activan o desactivan el Switch Magnético, con el comando input se
crean los botones y se los identifica con id= “enciendeMagnetico” y id=

129
“apagaMagnetico”, estos botones con el comando click, de la librería jquery,
cuando se presiona realiza la acciones siguientes: Entre las líneas 51 y 61 de la
Figura 4 – 20, Si el botón Encender se presiona o Apagar, el socket emite un
evento llamado EncenderAlarmaMag o ApagarAlarmaMag, este evento es
capturado por el servidor MTU y envía su correspondiente código al puerto serial,
que luego se procesa por el RTU para activar o desactivar el switch magnético.

4.4 Implementación en la RTU e interfaz HMI en el S.O. Android.

En este apartado se ve la implementación de la RTU en el S.O. Android.

Este programa que se llama “Monitor” en el S.O. Android (aplicación) se compone

de dos partes principales que son: la interfaz visual HMI y la lógica de la
aplicación, el programa en sí.

En la interfaz HMI, es donde el usuario controla el dispositivo en el sistema

SCADA. Se muestran los componentes de conexión entre el RTU con S.O.
Android y la MTU con S.O. Linux Ubuntu. Se visualizan los comandos para activar
o desactivar las funciones de los sensores y preactuador (relé).

En la lógica de la aplicación, es la parte que se crea el programa para Android,

se enlaza los componentes de la interfaz HMI con los funciones de la aplicación.

El funcionamiento es el siguiente. Al visualizar la aplicación en Android, Figura 4

– 22, se presenta la interfaz HMI para la conexión entre la RTU Android y la MTU
Linux, se introduce la dirección IP asignada para para la MTU con Linux Ubuntu,
se presiona el botón conectar y luego de establecida la conexión con el servidor
MTU la luz del lado se enciende a verde, se accede a el a través de los botones
de los sensores y preactuador (relé) como también se logra recibir los mensajes
de alerta de parte de los sensores, todo este sistema es en tiempo real.

130
4.4.1 Implementación de la Interfaz HMI en Android.

Lo primero que se realiza es la creación de la interfaz de usuario. Esta interfaz

se sitúa en Monitor>res>layout>activity_main.xml (apéndice C). En el archivo se
tienen dos alternativas para la creación de la interfaz para la aplicación, una es
por medio de escribir su código fuente en el archivo activity_main.xml o a través
de la interfaz gráfica, sin embargo, al ocupar la interfaz gráfica, se escribe
automáticamente el código fuente en el archivo XML; Esta es la alternativa de
implementar el diseño.

El diseño de la aplicación se muestra en la Figura 4 – 22.

Figura 4 – 22. Diseño de la aplicación HMI en Android.

Se ocupa el comando <RelativeLayout> con el siguiente encabezado:

131
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity"

En donde las dos primeras líneas son obligatorias y la última línea hace referencia
al archivo principal que es la lógica de la aplicación.

Las demás líneas hacen referencia a los botones, texto y entrada de texto. Con
sus respectivas identificaciones (android:id="@+id/Tipo_Objeto), que se necesita
al realizar el enlace a la parte lógica de la aplicación.

Detalles se pueden ver en el Apéndice C.

4.4.2 Implementación de la Lógica en la RTU con S.O. Android.

La lógica de la aplicación se desarrolla en el archivo MainActivity.java ubicado en

Monitor>src>com.tomas.monitor. También están otros archivos necesarios para
el proyecto.

El archivo se compone del paquete com.tomas.monitor, las librerías que se

importan al archivo. La clase pública MainActivity que extiende de Activity y es
ahí en donde se implementan las funciones lógicas de la aplicación.

La función que crea la ventana y los procesos lógicos es onCreate, está se

compone super.onCreate que hereda de la clase base Activity. setContentView
que establece el contenido de la actividad de un recurso de la interfaz HMI de
diseño, en este caso al archivo activity_main.xml en donde se diseña la interfaz.

Consta de las siguientes partes: El enlace entre la MTU con S.O. Linux Ubuntu y
la RTU con interfaz HMI con S.O. Android, el manejo del preactuador (relé), el

132
control del sensor de movimiento, el control del Switch Magnético, el acceso a la
base de datos y el control de los mensajes SMS.

Detalles se muestra en el Apéndice C.

4.4.2.1 La conexión con la MTU con S.O. Linux Ubuntu.

Esta es la parte encargada de establecer la conexión con el MTU, a través de

TCP/IP por medio de una librería especial para el socket (socket.io) en Android.
Esta realiza las comunicaciones entre la RTU con la Interfaz HMI con S.O.
Android (Cliente) y la MTU con S.O. Linux Ubuntu (Servidor Node.js).

Primero se definen las variables a ocupar en la clase principal, MainActivity.java.

Las variables que se ocupan en la conexión con el servidor Conectar,
Desconectar; Direcciónde tipo String, una variable EditText con nombre ip, para
introducir texto a través de la interfaz HMI, y una variable SocketIO con nombre
cliente de la librería socket.io para Android. Como muestra la Figura 4 – 23.

Figura 4 – 23. Variables para la conexión entre la MTU y la RTU con interfaz
HMI.

133
Adentro de la función onCreate se enlaza los recursos de la interfaz de usuario,
mediante la función findViewById, para los botones Conectar, Desconectar y la
entrada de texto ip. Como muestra la Figura 4 – 24.

Figura 4 – 24. Variables que enlazan la parte lógica con la interfaz HMI y los
intentos.

Se llama al evento Conectar.setOnClickListener, el cual espera de la función

onClick y que el condicional se active cuando el botón Conectar se presiona,
luego de este proceso, todo lo que recoge de la entrada de texto, la dirección
web, es almacenado en la variable dirección. Se crea el cliente socket en la
dirección IP introducida y en el puerto asignado para ello, en este caso el puerto
8080. Como se muestra en la Figura 4 – 25.

134
 Figura 4 – 25. Función onClick a través del botón Conectar.

Luego la variable cliente que hereda de la librería SocketIO se conecta a través

de la función de la librería SocketIO, connect, en la que tiene sub-funciones que
sirven para ver el estado de la conexión, o sea, cuando se desconecta del
servidor (onDisconnect), cuando se conecta con el servidor (onConnect), cuando
ocurre un evento, o sea, cuando se transmite una función a través de TCP/IP por
medio de Socket, (on) y cuando sucede un error en la conexión por socket
(onError). Como se aprecia en la Figura 4 – 26.

135
Figura 4 – 26. Sub-funciones de la función Connect de la librería SocketIO.
136
4.4.2.1.1 Función onConnect.

La sub-función onConnect muestra un aviso en la consola de depuración y una

alerta en la interfaz HMI de Android, indica que la conexión fue realizada con
éxito, con el inicio del Intento startActivity(AlarmaConectado). Se crea
Conectado.java se ubica en el paquete com.tomas.monitor. Conectado.java
contiene el programa fuente del mensaje de alerta.

Conectado.java se compone de la librería AlertDialog que muestra el mensaje de

aviso en una ventana emergente. Como muestra la Figura 4 – 27.

Figura 4 – 27. Programa Conectado.java.

137
4.4.2.1.2 Función onDisconnect.

La función muestra un aviso de desconexión del servidor en un mensaje en

consola de depuración y un alerta en la interfaz HMI de Android a través de un
nuevo Intento startActivity(AlarmaDesconectado). Se crea Desconectado.java
que se ubica en el paquete com.tomas.monitor. Desconectado.java contiene el
programa fuente del mensaje de alerta.

Desconectado.java se compone de la librería AlertDialog para mostrar el mensaje

de aviso en una ventana emergente. Como muestra la Figura 4 – 28.

Figura 4 – 28. Programa Desconectado.java.

138
4.4.2.1.3 Función on

La función on es la encargada de escuchar los eventos provenientes del Socket,

por medio del argumento event. On está a la espera de los eventos “SensorMov”
y “SensorMag”. Como se muestra en la Figura 4 – 29.

Figura 4 – 29. Eventos a la espera a través del Socket.

El primer condicional, if, por medio del comando equalsIgnoreCase hace una
comparación con el evento SensorMov proveniente del argumento event de la
función On. Si es igual, llama a un Intento, el cual abre una ventana emergente
mostrando un mensaje de que el Sensor de movimiento se activó, en la interfaz
HMI de Android. Para este fin, se crea SensorMovimieno.java ubicado en el
paquete com.tomas.monitor. SensorMovimieno.java contine el programa fuente
del mensaje de alerta.

SensorMovimiento.java se compone de la librería AlertDialog para mostrar el

mensaje de aviso en una ventana emergente. Como aparece en la Figura 4 – 30.

139
 Figura 4 – 30. Programa SensorMovimiento.java.

Para el segundo condicional se evalúa el evento de la trasmisión del socket

SensorMag si al comparar por medio de la función equalsIgnoreCase con event,
se presenta un mensaje de aviso de que el Switch magnético se activó en una
ventana emergente. Para llevar a cabo esta tarea, se crea SensorMagnetico.java
ubicado en el paquete com.tomas.monitor. SensorMagnetico.java contiene el
programa fuente del mensaje de alerta.

140
SensorMagnetico.java se compone de la librería AlertDialog para mostrar el
mensaje de aviso en una ventana emergente. Se presenta en la Figura 4 – 31.

Figura 4 – 31. Programa SensorMagnetico.java.

También la función on recoge los eventos que accionan las luces indicadoras de
la interfaz HMI del preactuador y los sensores.

El código fuente se presenta en la Figura 4 – 32.

141
Para tal efecto se establecen imágenes de luces rojas, verdes y grises. Que
sirven como indicadoras de los estados de los sensores y preactuador.

Se comienza con el evento EncenderLuzDB. Al recibir por medio del socket el

evento EncenderLuzDB cambia el estado de la imagen de la luz indicadora de
rojo a verde. Por medio del comando setImageResource cambia la variable
GrisLed por una imagen, guardada en la carpeta Drawable, a verde. Como
también la variable RojoLed por la imagen gris.

En cambio cuando recibe el evento proveniente del socket ApagaLedDB la

variable imagen GrisLed cambia a la imagen gris y la variable imagen RojoLed
cambia la imagen a rojo.

Figura 4 – 32. Evento del preactuador que cambia el estado de la imagen.

142
De manera semejante los eventos EnciendeSensorMovBD y
ApagaSensorMovBD, cambia la variable imagen VerdeSensorMov de verde a
gris y viceversa. Mediante la función setImageResource como muestra la Figura
4 – 33.

Lo mismo sucede con el evento proveniente del socket EnciendeSensorMagBD

y ApagaSensorMagBD. Se Cambia la variable imagen VerdeSensorMag de
verde a gris y viceversa. Mediante la función setImageResource como muestra
la Figura 4 – 34.

Figura 4 – 33. Evento del sensor movimiento que cambia el estado de la imagen.

143
Figura 4 – 34. Evento del sensor switch magnético que cambia el estado de la
imagen.

4.4.2.2 El control del preactuador.

Se definen las variables para los botones al principio de la clase MainActivity.java;

Encender y Apagar de la librería Button como se muestra en la Figura 4 – 23.
Dentro de la función onCreate se presenta el enlace que tiene las variables con
la interfaz de la aplicación, gracias a la función findViewById, como se muestra
en la Figura 4 – 24.

Existen dos escenarios con las variables Encender y Apagar.

La primera Encender.setOnClickListener establece la acción que realiza al

presionar el botón Encender. Adentro de la función onClick se crea el objeto

144
JSON, le sigue un condicional, que está a la espera de que el usuario presione
el botón. La acción a realizar es emitir el evento EncenderLed al socket creado y
mostrar un mensaje en la interfaz HMI de usuario “Enciende Luz”, si hay falla se
presenta el mensaje “Fallo Encender Luz, conéctese al servidor”. Como se
presenta en la Figura 4 – 35.

La segunda Apagar.setOnClickListener realiza un procedimiento semejante al

primero, cambia al emitir el evento ApagarLed al socket conectado, cuando es
presionado el botón Apagar, como también da un mensaje emergente en la
interfaz de la aplicación “Apaga Luz”, si hay problemas en la condición se
despliega un mensaje “Fallo Apagar Luz, conéctese al servidor”. Como se
presenta en la Figura 4 – 36.

Figura 4 – 35. Programa para botón Encender, para la RTU asociado al relé.
145
 Figura 4 – 36. Programa para botón Apagar, para la RTU asociado al relé.

4.4.2.3 Control del Sensor de Movimiento.

Se definen las variables, al principio de la clase MainActivity.java; ActivarMov y

DesactivarMov de la librería Button, como se muestra en la Figura 4 – 23. Luego,
adentro de la onCreate se enlazan las variables con la interfaz de la aplicación,
por medio de findViewById, como se presenta en la Figura 4 – 24.

Existen dos escenarios con las variables ActivarMov y DesactivarMov.

La primera ActivarMov.setOnClickListener establece la acción que realiza al

presionar el botón ActivarMov. Adentro de la función onClick se crea el objeto

146
JSON, le sigue un condicional, que está a la espera de que el usuario presione
el botón. La acción a realizar es emitir el evento EncenderAlarmaMov al socket
creado y mostrar un mensaje en la interfaz de usuario “La alarma de Movimiento
se Activó”, si hay una falla, se presenta el mensaje “Fallo activar Alarma de
Movimiento, conéctese al Servidor”. Como se presenta en la Figura 4 – 37.

Figura 4 – 37. Programa para botón Activar, para la RTU asociado al sensor de
Movimiento.

147
La segunda DesactivarMov.setOnClickListener realiza un procedimiento
semejante al primero, cambia al emitir el evento ApagarAlarmaMov al socket
conectado, cuando es presionado el botón Desactivar, como también da un
mensaje emergente en la interfaz de la aplicación “La alarma de Movimiento se
ha Desactivado”, si hay problemas la condición despliega un mensaje “Fallo
Desactivar Alarma de Movimiento, conéctese al Servidor”. Como se presenta en
la Figura 4 – 38.

Figura 4 – 38. Programa para botón Desactivar, para la RTU asociado al sensor
de Movimiento.

148
4.4.2.4 Sensor Switch Magnético.

Se definen las variables, al principio de la clase MainActivity.java; ActivarMag y

DesactivarMag de la librería Button, como se muestra en la Figura 4 – 23. Luego,
adentro de la onCreate se enlazan las variables con la interfaz de la aplicación,
por medio de findViewById, como se presenta en la Figura 4 – 24.

Existen dos escenarios con las variables ActivarMag y DesactivarMag. La

primera ActivarMag.setOnClickListener establece la acción que realiza al
presionar el botón Activar. Adentro de la función onClick se crea el objeto JSON,
le sigue un condicional, que está a la espera de que el usuario presione el botón.
La acción a realizar es emitir un evento EncenderAlarmaMag al socket creado y
mostrar un mensaje en la interfaz HMI del usuario “El Switch Magnético se ha
Activado”, si hay una falla, se presenta el mensaje “Fallo Activar Switch
Magnético, conéctese al Servidor”. Como se muestra en la Figura 4 – 39.

La segunda DesactivarMag.setOnClickListener realiza un procedimiento

semejante al primero, cambia al emitir el evento ApagarAlarmaMag al socket
conectado, cuando es presionado el botón Desactivar, como también da un
mensaje emergente en la interfaz de la aplicación “El Switch Magnético se ha
Desactivado”, si presenta problemas la condición se despliega un mensaje “Fallo
Desactivar Switch Magnético, conéctese al Servidor”. Como muestra la Figura 4
– 40.

149
Figura 4 – 39. Programa para botón Activar, para la RTU asociado al Sensor
Switch Magnético.

150
Figura 4 – 40. Programa para botón Desactivar, para la RTU asociado al Sensor
Switch Magnético.

También se necesitan crear los siguientes archivos en XML:

 activity_conectado.xml,

 activity_desaconectado.xml,

151
  activity_sensormagnetico.xml,

 activity_sensormovimiento.xml,

Estos archivos deben estar vacios ya que son para la interfaz HMI en Android
que se ejecutan cuando sucede un intento y como por cada intento solo se
muestra un mensaje emergente, no es necesario configurar la pantalla de la
interfaz HMI.

Se ubican en la carpeta layout, como muestra la Figura 4 – 41.

Figura 4 – 41. Directorios de la Aplicación en Android.

152
También se coloca las siguientes cadenas de código en el archivo
AndroidManifest.xml

<activityandroid:name=".Conectado"></activity>
<activityandroid:name=".Desconectado"></activity>
<activityandroid:name=".SensorMovimiento"></activity>
<activityandroid:name=".SensorMagnetico"></activity>

<uses-permissionandroid:name="android.permission.INTERNET"/>

Los primeros 4 hacen referencia a los avisos emergentes, para cada Intento. El
último da permisos al programa, RTU de interfaz HMI con S.O. Android para
funcionar a través de la red local o Internet.

4.4.3 Base de Datos.

Para este cometido se diseña un botón que enlaza a otra actividad; esta
despliega la información de la fecha y hora en que ocurre los eventos de activar
o desactivar los sensores y preactuador, provenientes de la copia de la base de
datos de la MTU.

Comienza con la variable de BaseDatos que vincula la base de datos con el inicio
de una nueva actividad:

BaseDatos=(Button)findViewById(R.id.ftp);

Se prosigue con el almacenamiento de la base de datos proveniente de la MTU,

al realizar una copia en la RTU con interfaz HMI, del siguiente modo:

Dentro de la función on del socket, está a la espera de que se presente el evento

DatosDB que también contiene la información de la base de datos provenientes
de la MTU en formato JSONArray. Para obtener los datos se convierte el

153
contenido del evento DatosDB a un objeto JSON. Con un substring se rescata el
formato de un JSONObject. Luego se adquiere el contenido de cada variable de
la base de datos transmitida, de los sensores y preactuador, y se almacena en la
variable que caracteriza el contenido. Como muestra la Figura 4 – 42.

Figura 4 – 42. Rescate de la base de datos proveniente de la MTU.

Se crea una nueva clase Java con nombre CreaciónBDSQLite.java que es la

encargada de crear la base de datos SQLite en Android, como se muestra el
programa a continuación:

package com.tomas.monitor;

import android.content.Context;
import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;

public class CreacionBDSQLite extends SQLiteOpenHelper {

154
 //Nombre de la base de datos
public static final String NOMBREBD = "BDmonitor.sqlite";
//Versión de la base de datos
public static final int VERSION = 1;
//Nombre de la tabla (puede haber tantas como necesitemos)
public static final String NOMBRE_TABLA = "Base_Datos_Monitor";
//Campos de la base de datos
public static final String ID = "id";
public static final String RELE = "Rele";

public static final String RELETIME ="ReleTime";

public static final String SENSORMOV = "SensorMov";

public static final String SENSORMOVTIME ="SensorMovTime";

public static final String SENSORMAG = "SensorMag";

public static final String SENSORMAGTIME = "SensorMagTime";

public static final String ALARMASENSORMOV = "AlarmaSensorMov";

public static final String ALARMASENSORMOVTIME = "AlarmaSensorMovTime";

public static final String ALARMASENSORMAG = "AlarmaSensorMag";

public static final String ALARMASENSORMAGTIME = "AlarmaSensorMagTime";

//Constructor
public CreacionBDSQLite(Context context) {
//Aquí le pasamos el contexto, el nombre de la base de datos, el
cursor que no lo necesitamos y la version de la base de datos.
super(context, NOMBREBD, null, VERSION);
}

//Aquí crearemos la base de datos

@Override
public void onCreate(SQLiteDatabase db) {
//En la siguiente linea lo que estamos haciendo es crear la base
de datos

db.execSQL("create table " + NOMBRE_TABLA + "(" + ID + " integer

primary key autoincrement not null, "

+ RELE + " text, "

+ RELETIME + " text, "

+ SENSORMOV + " text, "

155
 + SENSORMOVTIME + " text, "

+ SENSORMAG + " text, "

+ SENSORMAGTIME + " text, "

+ ALARMASENSORMOV +" text, "

+ ALARMASENSORMOVTIME + " text, "

+ ALARMASENSORMAG +" text, "

+ ALARMASENSORMAGTIME +" text);");

//Aquí se actualizará la base de datos

@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int
newVersion) {

Primero se definen las variables de campo que determinan el contenido de la

base de datos.

Adentro de la función onCreate se crea la base de datos en formato SQLite, con

las respectivas columnas asociadas a los sensores y preactuador como también
emparejado con la fecha y hora de activación o desactivación.

Para crear la base de datos se necesita introducir el siguiente código fuente al

comienzo de la función onCreate en la clase MainActivity.java:

CreacionBDSQLite crearBD = new CreacionBDSQLite(this);

final SQLiteDatabase bd = crearBD.getWritableDatabase();

Con estas líneas de código fuente se crea y está a la espera, la variable bd, para
escribir en la base de datos.

156
El botón asociado a la base de datos, al hacer click en el botón Entrar se ejecuta
un proceso de iniciar una nueva actividad en una ventana nueva; lleva los datos
del último registro de la base de datos a la nueva ventana.

El proceso es el siguiente:

Cuando es presionado el botón Entrar, se busca la última fila de la base de datos

por medio de la siguiente línea de SQLite:

SELECT ROWID from Base_Datos_Monitor order by ROWID DESC limit 1

En dónde se llama a la Base de datos y se pide el índice de las filas numerada

en forma descendente y como máximo una fila.

Luego se almacena en un cursor que es una colección de filas, como variable c,

se obtiene la primera fila y se guarda su contenido en la variable lastId que es de
tipo long. Con esto se procede a obtener el contenido de la última fila.

Cursor c = bd.rawQuery(query, null);

if (c != null && c.moveToFirst()) {
lastId = c.getLong(0);}

Nuevamente se obtiene la fila con la con la línea de SQLite:

SELECT Rele, ReleTime, SensorMov, SensorMovTime, SensorMag,

SensorMagTime, AlarmaSensorMov, AlarmaSensorMovTime,
AlarmaSensorMag, AlarmaSensorMagTime FROM Base_Datos_Monitor
WHERE rowid="+lastId+"

En donde se rescatan todos los valores de la base de datos referente al

preactuador y sensores. Se almacenan en un nuevo cursor, contenido. Se busca
en cada columna del cursor, contenido y se almacena en la variable
correspondiente. Del siguiente modo:

for(contenido.moveToFirst();contenido.isAfterLast();contenido.moveToNe
xt()){

ReleToIntent = contenido.getString(0);

ReleTimeToIntent = contenido.getString(1);

157
 SensorMovToIntent = contenido.getString(2);

SensorMovTimeToIntent = contenido.getString(3);

SensorMagToIntent = contenido.getString(4);

SensorMagTimeToIntent = contenido.getString(5);

AlarmaSensorMovToIntent = contenido.getString(6);

AlarmaSensorMovTimeToIntent = contenido.getString(7);

AlarmaSensorMagToIntent = contenido.getString(8);

AlarmaSensorMagTimeToIntent = contenido.getString(9);}

El siguiente paso es traspasar la información de las variables de la base de datos

a la nueva actividad, se realiza el proceso por medio de la función putExtra de la
clase Bundle. Finalmente se inicia la nueva Actividad. Como muestra las
siguientes líneas:

BDToIntent.putExtra("Rele", ReleToIntent);
BDToIntent.putExtra("ReleTime", ReleTimeToIntent);
BDToIntent.putExtra("SensorMov", SensorMovToIntent);
BDToIntent.putExtra("SensorMovTime", SensorMovTimeToIntent);
BDToIntent.putExtra("SensorMag", SensorMagToIntent);
BDToIntent.putExtra("SensorMagTime", SensorMagTimeToIntent);
BDToIntent.putExtra("AlarmaSensorMov", AlarmaSensorMovToIntent);
BDToIntent.putExtra("AlarmaSensorMovTime", AlarmaSensorMovTimeToIntent);
BDToIntent.putExtra("AlarmaSensorMag", AlarmaSensorMagToIntent);
BDToIntent.putExtra("AlarmaSensorMagTime", AlarmaSensorMagTimeToIntent);

startActivity(BDToIntent);

Se crea una nueva interfaz visual para mostrar el traspaso de información de una
actividad a otra. La interfaz es la que se muestra en la Figura 4 – 43.

Para entrar a la nueva actividad se crea una nueva clase, MainDbActivity.java,

en esta clase tiene como función rescatar la información de la actividad principal
y mostrar los datos almacenados en el último registro de la base de datos
almacenada en Android.

Comienza con la obtención de los datos por medio de la función

getIntent().getExtras() que las almacena en la variable Bundle extras. De ahí
cada dato se obtiene y almacena en la variable respectiva asociado al

158
Figura 4 – 43. Interfaz visual de la Base de Datos

preactuador, sensor de la base de datos, por medio de la función

getString(“Variable de la base de datos”) se obtiene el valor respectivo.

Luego cada variable es comparada con un valor específico y si resulta idéntico el

texto de la respectiva variable se cambia por Activo o Desactivo como también
se imprime la fecha y hora del suceso. Como muestran las líneas siguientes:

Bundle extras = getIntent().getExtras();

if (extras != null)

{
Rele = extras.getString("Rele");
ReleTime = extras.getString("ReleTime");

159
 SensorMov = extras.getString("SensorMov");
SensorMovTime = extras.getString("SensorMovTime");
SensorMag = extras.getString("SensorMag");
SensorMagTime = extras.getString("SensorMagTime");
AlarmaSensorMov = extras.getString("AlarmaSensorMov");
AlarmaSensorMovTime = extras.getString("AlarmaSensorMovTime");
AlarmaSensorMag = extras.getString("AlarmaSensorMag");
AlarmaSensorMagTime = extras.getString("AlarmaSensorMagTime");

if(Rele.equalsIgnoreCase("1")){

Log.v(null,"Entro a cambiar texto");

ReleText.setText("Activo "+ ReleTime);

}
if(Rele.equalsIgnoreCase("0")){

ReleText.setText("Desactivo "+ ReleTime);

}

if(SensorMov.equalsIgnoreCase("1")){

Log.v(null,"Entro a cambiar texto");

SensorMovText.setText("Activo "+ SensorMovTime);

}
if(SensorMov.equalsIgnoreCase("0")){

SensorMovText.setText("Desactivo "+ SensorMovTime);

}

if(SensorMag.equalsIgnoreCase("1")){

Log.v(null,"Entro a cambiar texto");

SensorMagText.setText("Activo "+ SensorMagTime);

}
if(SensorMag.equalsIgnoreCase("0")){

SensorMagText.setText("Desactivo "+ SensorMagTime);

if(AlarmaSensorMov.equalsIgnoreCase("1")){

Log.v(null,"Entro a cambiar texto");

160
 AlarmaSensorMovText.setText("Activa "+
AlarmaSensorMovTime);

}
if(AlarmaSensorMov.equalsIgnoreCase("0")){

AlarmaSensorMovText.setText("Desactiva "+
AlarmaSensorMovTime);
}

if(AlarmaSensorMag.equalsIgnoreCase("1")){

Log.v(null,"Entro a cambiar texto");

AlarmaSensorMagText.setText("Activa "+
AlarmaSensorMagTime);

}
if(AlarmaSensorMag.equalsIgnoreCase("0")){

AlarmaSensorMagText.setText("Desactiva "+
AlarmaSensorMagTime);
}

Aceptar.setOnClickListener(new OnClickListener(){

@Override
public void onClick(View arg0){

//Si Aceptar es presionado

if(Aceptar.isClickable()){

finish(); //Finaliza la actividad

}
}
});

4.4.4 Botón SMS.

El botón SMS tiene como fin activar o desactivar el modem GPRS, módulo de la
RTU GPRS Arduino.
Se define un botón especial que muestra cuando está activo. ToggleBoton es la
nueva variable para el botón SMS:

private ToggleButton ToggleBoton;

Se vincula el botón con la nueva variable mediante:

161
ToggleBoton = (ToggleButton) findViewById(R.id.toggleButton1);

Luego se crea una función ToggleBoton.setOnClickListener en donde

realiza los estados del botón, activo o desactivo. En el estado activo envía un
evento al socket llamado SMSActivo en caso contrario emite el evento al socket
SMSDesactivo. Como muestra las líneas siguientes:

ToggleBoton.setOnClickListener(new OnClickListener(){

@Override
public void onClick(View arg0) {

//estado activo
if(ToggleBoton.isChecked()){

Log.v(TAG,"SMS Activo");

JSONArray SMSActivo= new JSONArray();

cliente.emit("SMSActivo", SMSActivo);

}
//estado desactivo
else{
Log.v(TAG, "SMS Desactivo");

JSONArray SMSDesactivo= new JSONArray();

cliente.emit("SMSDesactivo", SMSDesactivo);
}

}
});

162
Capítulo V. Pruebas y Operación del Sistema SCADA para
equipos móviles Android con software Libre.

5.1 Introducción.

En este apartado se entrega las pruebas y la operación efectuadas en el sistema

SCADA.

Se realiza la prueba para las RTU (Arduino) con el software de desarrollo de

Arduino IDE. Por medio de la consola del puerto serial que cuenta la plataforma
de desarrollo Arduino IDE, se abre para examinar la trasmisión y recepción de
datos. Los datos que se visualizan son cadenas de caracteres, tipo String. Se
logra visualizar los String que se transmiten a la MTU y como tambien introducir
String al puerto serial USB, con lo que se logra enviar los comandos para activar
o desactivar los sensores y preactuador (relé, contactores, etc).

Se procede con las comunicaciones serial entre la RTU y la MTU, a través de la

interfaz HMI por medio de la página web. Continuando con la comunicación por
medio de TCP/IP (Socket) entre los dispositivos RTU con interfaz HMI y la MTU.

Finalmente, se realiza una prueba global del sistema. Al acceder a través de la

HMI de la RTU (Android) a la MTU para comprobar el funcionamiento de los
sensores y preactuador (relé).

5.2 Comunicación del puerto Serial con los Sensores y

Preactuador del RTU.

El Arduino de la RTU se coloca en una caja plástica para su protección, se

visualiza las luces de los sensores y preactuador, los estados predeterminados
se presentan en verde y rojo.

163
Las luces verdes representan a los sensores, y significan que están activados
estos. Y la luz roja señala que el preactuador está apagado. Figura 5 – 1.

Figura 5 – 1. Luces predeterminadas del RTU de los sensores y preactuador.

Se supervisa las señales de alarma de los sensores, que son enviadas al puerto
serial. Por medio de la consola de Arduino IDE, Figura 5 – 2.

Figura 5 – 2. Consola Serial Arduino IDE.

5.2.1 Sensor de Movimiento.

Se procede a activar el sensor de movimiento, esto se realiza desplazando un

objeto en el campo de acción del sensor. Al desplazar el objeto, en el puerto
serial se imprime el código “2222”, que se observa en la consola, Figura 5 – 3.

164
 Figura 5 – 3. Mensaje del Sensor de Movimiento.

El sensor de movimiento envía el String al puerto serial, con el código

preestablecido. Por lo tanto, está funcionando perfectamente.

5.2.2 Sensor Switch Magnético.

Se procede a activar el sensor switch magnético, esto se realiza separando los

módulos del sensor, como se aprecia en la Figura 5 – 4.

Figura 5 – 4. Separación de módulos Sensor Switch Magnético.

Al realizar está acción en el puerto serial se escribe el código “5555”. Se aprecia

en la consola serial de Arduino IDE, Figura 5 – 5.

165
 Figura 5 – 5. Mensaje del Sensor Switch Magnético.

El sensor switch magnético envía el String al puerto serial, con el código

preestablecido. Por lo tanto, está funcionando perfectamente.

5.2.3 Funcionamiento de los sensores al mismo tiempo.

Para este efecto se realiza los mismos procedimientos para activar los sensores.

En la consola serial de Arduino se aprecia los códigos escritos uno a continuación

del otro, Figura 5 – 6.

Figura 5 – 6. Mensaje de los Sensores.

166
En el puerto serial se escribe los códigos preestablecidos de los sensores, que
se visualizan en la consola de Arduino IDE. Por lo tanto, está funcionando
perfectamente.

5.2.4 Preactuador.

Para realizar la prueba del preactuador, se conecta a una ampolleta de 220 VCA.
En uno de los extremos del cofre del RTU, se conecta la ampolleta.

Se probó la activación del preactuador conectado a una ampolleta, escribiendo

en el puerto serie el carácter “1”, por medio de la consola del Arduino IDE. Esto
provoca el encendido de la ampolleta y el cambio de estado de la luz indicadora
predeterminada de roja a verde. Para desactivar el preactuador se escribe el
carácter “0” en la consola del Arduino IDE, se realiza el cambio de estado del
indicador de preactuador de verde a roja y el apagado de la ampolleta. Por tanto,
su funcionamiento es el esperado.

5.3 Pruebas entre la interfaz HMI de la MTU y la RTU.

En este apartado se realizan las pruebas en la comunicación entre la MTU y la

RTU a través de la interfaz HMI de la MTU (página web).

5.3.1 Comunicación entre la interfaz HMI de la MTU con la RTU

de los sensores y preactuador.

La prueba consiste en ingresar a la página web de la MTU (Servidor Linux

Ubuntu) y verificar el funcionamiento de los sensores y el preactuador.

Para lograr el objetivo se realizó la conexión de las RTU’s por puerto serial USB
a la MTU (Servidor). Primero se conecta la RTU de los sensores y preactuador y
se abre una consola terminal en la MTU y se ingresa la línea de comandos para
activar el puerto serial USB referido a la RTU de los sensores y preactuador, se
ingresa:

167
  sudo chmod a+rw /dev/ttyACM0 en donde sudo es el comando para
modificar los parámetros del servido en forma de superusuario chmod
a+rw le da al puerto serial la habilitación de poder escribir y leer en el, y
/dev/ttyACM0 es la ruta que tiene el puerto USB, como muestra la Figura
5 – 7.

Figura 5 – 7. Permiso de puerto USB.

Luego se inicia el servidor Node.js en la MTU con S.O Linux Ubuntu, del siguiente
modo.

 Se abre un consola terminal y se escribe

ruta_a_carpeta_de_archivo_javascript/ node server.js, como muestra la
Figura 5 – 8.

Figura 5 – 8. Servidor Node.js

Después se abre una ventana de un navegador de internet y se accede a la MTU

a través de la dirección IP que tiene asignada la MTU, con su respectivo puerto,
por ejemplo la IP: 192.168.1.34 en el puerto 8080. En la Figura 5 – 9 se muestra
la interfaz HMI de la MTU.

168
 Figura 5 – 9. Interfaz HMI de la MTU.

Las pruebas que se realizan son:

 Se Activa el sensor de movimiento, al desplazar un objeto en su campo de

visión, el resultado que se muestra es una ventana emergente, con la
indicación de “Alarma de movimiento Activada”, esta ventana emergente
se repite unas 2 a 5 veces. Sin embargo, el funcionamiento es el
adecuado, el aviso llega en tiempo real desde la RTU de los sensores a la
interfaz HMI de la MTU.

 Del mismo modo se realiza con el sensor de switch magnético, para activar
el sensor se separan los módulos switch magnético. Los resultados que
se presentan en la interfaz HMI es un despliegue de una ventana
emergente con el siguiente texto “Alarma magnética activada” como
muestra la Figura 5 – 10.

Figura 5 – 10. Mensaje de alarma Magnética Activada.

169
  Se presiona el botón Desactivar del sensor de movimiento y se mueve un
objeto en el campo de visión del sensor se comprueba que no se presenta
la ventana emergente. Y cuando se presiona Activar el sensor de
movimiento el sensor vuelve a funcionar.

 También al presionar el botón Desactivar del sensor switch magnético y al

acercarse un objeto en el campo a acción del sensor, no se presenta la
ventana emergente. Y al presionar el botón Activar el sensor vuelve a
funcionar normalmente.

 La prueba para el funcionamiento del preactuador (relé), es presionar el

botón encender, lo que produce el cambio de color del led de rojo a verde
y se prende la ampolleta conectada al relé, y se desconecta la ampolleta
al presionar el botón Apagar, también el led cambia de verde a rojo.

5.4 Comunicación entre la RTU con interfaz HMI (Android) con

la RTU de los sensores y preactuador a través de la MTU.

La prueba consiste en comprobar la comunicación entre la RTU (Arduino) y la

RTU con interfaz HMI con S.O. Android.

El acceso a la MTU se realiza en forma inalámbrica a través de una red de área

local que se puede extender a Internet.

La RTU con interfaz HMI con S.O. Android (Tablet) se conecta a la MTU a través
de WiFi a la red local. Por lo tanto el dispositivo es portable con movilidad.

Las pruebas que consiste son la conexión que se realiza a través de socket entre
la Tablet con S.O. Android y la MTU. Se verifica el correcto funcionamiento de los
sensores y preactuador (relé).

170
5.4.1 Comunicación entre la RTU con interfaz HMI (Android) y la
MTU (Servidor Linux Ubuntu).

Como punto de partida se realiza la conexión con la MTU a través de socket. Se

ingresa la dirección IP asignada a la MTU (Servidor Linux Ubuntu). Como muestra
la Figura 5 – 11. Se presiona el botón Conectar y luego de algunos segundos se
establece la conexión al mostrar el cambio la luz de conexión de gris a verde y
un mensaje emergente en la aplicación de Android, como muestra la Figura 5 –
12. Con lo que se logró la conexión a través de socket entre la RTU con interfaz
HMI con S.O. Android y la MTU con S.O. Linux Ubuntu. Para desconectarse se
presiona el botón Desconectar mostrando un mensaje emergente, como aparece
en la Figura 5 – 13.

Figura 5 – 11. Conexión por IP a la MTU.

Figura 5 – 12. Mensaje de conexión de la interfaz HMI Android de la MTU.

171
Figura 5 – 13. Mensaje de desconexión de la interfaz HMI Android de la MTU.

5.4.2 Comunicación de la RTU con interfaz HMI y la RTU de los

sensores y preactuador.

Al establecerse la conexión con la MTU con S.O. Linux Ubuntu. Se procede a

presionar el botón de Encender en la RTU con interfaz HMI con S.O. Android. Al
realizar la acción la orden llega a la MTU presentándose el mensaje en consola
Enciende Led. Como también en el Tablet se presenta un mensaje emergente
como aparece en la Figura 5 – 14.

Figura 5 – 14. Mensaje de Activación de Luz por parte del relé.

El mensaje en consola da el aviso de la activación del relé, en la RTU de los

sensores y preactuador, la luz que indica que el relé ha sido activado se cambia
de rojo a verde.

En el caso de presionar el botón Apagar la Tablet envía la orden a la MTU y esta

la procesa y la dirige a la RTU de los sensores y preactuador, desactivándose el
relé. Se presenta un aviso en consola de la MTU que dice “Apaga Led”. También
se presenta un aviso en la interfaz HMI de Android.

172
La siguiente prueba es en el Sensor de movimiento. Si no se presiona ningún
botón del área de Alarma de Movimiento. La MTU tiene prefijado que el sensor
de movimiento este activo. Al desplazar un objeto adelante del sensor de
movimiento, en la interfaz HMI se despliega un mensaje como se muestra en la
Figura 5 – 15.

Figura 5 – 15. Aviso de alarma de movimiento Activa, en interfaz HMI de Android.

De igual manera en el sensor switch magnético, cuando se separan los módulos

envía un aviso a través de la MTU a la Interfaz HMI Android, como muestra la
Figura 5 – 16.

Figura 5 – 16. Aviso de alarma de switch magnético Activa, en interfaz HMI de

Android.

En la parte del HMI de la Alarma Movimiento y Alarma de Switch Magnético. Si

es presionado el botón “Desactivar” las alarmas se bloquean y no se presenta

173
ningún mensaje emergente en la interfaz HMI Android como muestra la Figura 5
–17. Para reanudar su acción se tiene que presionar el botón “Activar, como
muestra la Figura 5 – 17.

Figura 5 – 17. Activar o Desactivar alarmas en interfaz HMI Android.

5.5 Prueba general del sistema SCADA con el acceso por

medio de la RTU con interfaz HMI (Android).

Según la Arquitectura de Hardware la conexión con los dispositivos es la

mostrada en la Figura 5 – 18.

Figura 5 – 18. Conexión de la Arquitectura de Hardware.

174
Se comienza con la conexión de los componentes de Hardware:

1. Se conecta los sensores y el dispositivo que funciona con el relé, a la RTU

de los sensores y preactuador (Arduino).

2. La RTU de los sensores y preactuador (Arduino) se conecta a la MTU (PC)

a través de cable serial USB.

3. La RTU del modem GPRS se conecta a la MTU por via USB.

4. Se conecta la MTU a la red local por cable Ethernet.

Se continúa con la ejecución de los programas en la MTU (PC).

Se abre un terminal en Linux Ubuntu y se ingresa a la carpeta en donde se aloja

el archivo de JavaScript del servidor web (server.js). Se ejecuta el archivo
server.js con la siguiente línea de comando: node server.js.

En ese instante se ejecuta el servidor Node.js como aparece en la Figura 5 – 8.

Completándose el trabajo en la parte de la MTU.

Luego se procede con la Tablet con S.O. Android conectándose a la red local
WiFi. Al acceder a ella, se ejecuta la aplicación “Monitor” en Android. Adentro de
la aplicación se continua con la conexión vía socket a la MTU, como muestra la
Figura 5 – 11.

Al establecerse la conexión en la interfaz HMI se presenta el mensaje que

aparece en la Figura 5 – 12.

Se prueban los sensores. Al activar el sensor de movimiento se presenta una

ventana emergente en la interfaz HMI como muestra la Figura 5 – 15.

De igual manera se activa el sensor switch magnético y aparece en la interfaz

HMI una ventana emergente como muestra la Figura 5 – 16.

175
Si se presionan los botones Desactivar de los sensores en la interfaz HMI y se
realiza la prueba de activar los sensores en la RTU. Los mensajes emergentes
no se presentan, solamente cuando se presionan los botones Activar; enforma
visual se presenta la luz de color verde cuando están activos los sensores y
cambia al color gris cuando están desactivados, como aparece en la Figura 5 –
17.

En tanto con el preactuador (relé), al presionar el botón Encender se envía la

orden a través del socket hasta la MTU finalizando con la activación del relé y el
encendido del dispositivo conectado con el, y la luz de color verde se activa. En
forma semejante al presionar el botón Apagar se envía la orden a través del
socket a la MTU finalizando con la desactivación del relé y la desconexión del
dispositivo conectado con el relé, y se enciende la luz roja.

Por otra parte la Base de Datos, al cambiar el estado de los sensores y

preactuador; Activo o Desactivo. Es almacenado la fecha y hora de tal suceso y
es mostrado en la interfaz de la base de datos a través del botón Entrar. También
cuando es activada la alarma de los sensores se registra la fecha y hora del
acontecimiento. Como muestra la Figura 4 – 43.

En el caso de la activación de los mensajes SMS, al presionar el botón Activar

mensajes SMS. La RTU con interfaz HMI (Android), manda un evento al socket
para la activación o desactivación del modem GPRS para el envio de SMS a
celulares preestablecidos.

176
Capítulo V. Conclusiones.

El proyecto según la metodología que se implemento para su elaboración hizo

más estructurado el desarrollo de la memoria. Arrojando resultados con las
herramientas de Hardware disponibles en el mercado. Incurriendo en bajos
costos de adquisición del Hardware. En tanto las licencias libres del Software
ocupadas dan libertad de creación, dejando de lado los erméticos programa para
el funcionamiento de los sistemas SCADA y sus altos costos.

Un potencial del Hardware es su reutilización para adaptarlo a otro sistema

SCADA, gracias a la programación que se puede dar por medio del software libre
adecuado.

En tanto el software de la MTU, para el desarrollo del servidor web, se utiliza un

nuevo lenguaje heredado de JavaScript, llamado Node.js, que es una forma de
llevar el lenguaje de programación JavaScript al entorno del PC Servidor (MTU)
y no sólo como un complemento de páginas web. Las conexiones simultáneas
del PC servidor, MTU, por parte de la RTU con interfaz HMI y S.O. Android, como
también de PC’s, se logran y se mantienen estables a través de TCP/IP por medio
de Socket.

Los módulos ocupados son extensiones, especialmente desarrollas para Node.js.

El módulo que controla la comunicación serial, SerialPort2, es un ejemplo de ello.
Con órdenes sencillas se logra el enlace entre la RTU (Arduino) y la MTU (PC).
También por medio del módulo para socket, socket.io, se obtiene la comunicación
entre la MTU y las unidades terminales, RTU con interfaz HMI con S.O. Android
y demás PC, a través de la red LAN o por Internet por medio del protocolo TCP/IP.

En tanto para el S.O. Android, el lenguaje que se ocupa es Java, pero contando
con sus propias librerías. El programa de desarrollo que se ocupa, Eclipse, hace
más ameno el desarrollo de la aplicación. Por medio de la consola se logra

177
supervisar el rumbo que sigue el programa, detectando los errores que surgen
en la programación.

La ventaja que tiene Android es poder trabajar por separado el desarrollo de la

interfaz HMI y por otra parte la lógica de la aplicación (programa). Se logra así
trabajar con objetivos puntuales, para luego armar todo en el proceso de creación
de la aplicación Android.

En el desarrollo del programa en Android se adjuntó un módulo para la

comunicación por socket por vía TCP/IP, llamado Socket.IO-Client for Java. Sin
este módulo no es posible la comunicación por socket por medio del protocolo
socket.io de Node.js. Siendo una desventaja, porque Android tiene por herencia
de Java la librería para socket.

En el momento de establecerse la comunicación por socket, Android está a la

espera de los eventos que provengan de la MTU, ejecutándose las acciones
predefinidas en la programación de la aplicación en Android. Los mensajes
emergentes de las alertas de los respectivos sensores son emitidos en forma
instantánea desde la MTU a la RTU con interfaz HMI, como también el control
del preactuador (relé), que se realiza a través de la interfaz HMI de Android hacia
la RTU (Arduino).

Gracias al Software libre se puede fabricar un sistema SCADA más aún

personalizarlo a los requerimientos de la industria dejando de lado a los
constosos sistemas SCADA de compañías fabricantes de ellos.

El Hardware como se ha presentado es de bajo costo, pero de potencial muy alto

para tareas de monitoreo y control en forma remota.

La ventaja que presenta la plataforma Android es creciente, como queda

demostrado en esta memoria. Con una básica aplicación sobre S.O. Android se
puede monitorear los sensores de un recinto y controlar dispositivos. Con lo que

178
se puede extrapolar para realizar proyectos más robustos. Manteniéndose el
concepto de SCADA, permitiendo la portabilidad, movilidad del monitoreo y
control por vigilancia en forma remota.

179
 Referencias Bibliográficas
[1] Corrales Paucar, Luis, “Interfaces de comunicación industrial”, Escuela
Politécnica Nacional, http://bibdigital.epn.edu.ec/.

[2] Carlos de Castro Lozano, Cristóbal Romero Morales, “Introducción a

SCADA”.

[3] Manuel Báez, Álvaro Borrego, Jorge Cordero,Luis Cruz, Miguel González,
Francisco Hernández, David Palomero, José Rodríguez de Llera, Daniel
Sanz, Mariam Saucedo, Pilar Torralbo, Álvaro Zapata, “Introducción a
Android”, www.tecnologiaUCM.es.

[4] http://es.wikipedia.org/wiki/SCADA.

[5] Dagoberto Montero, David B.Barrantes, Jorge M. Quirós, “Introducción a

los sistemas de control supervisor y de adquisición de datos (SCADA)”,
Verano de 2004.

[6] RedUSERS.com, “Introducción a Linux”, Capítulo 1,

http://img.redusers.com/imagenes/libros/lpcufl22/capitulogratis.pdf

[7] http://es.wikipedia.org/wiki/N%C3%BAcleo_Linux

[8] Jesús Tomás Gironés, “El gran libro de Android”, Marcombo.

[9] http://www.ulsa.edu.ni/publicaciones/-III-Anio/Plan-Sabatino-I-
Trimestre/Mando-Electromecanico/05_-_Sensores.pdf

[10] http://es.wikipedia.org/wiki/Preactuador

[11] http://es.wikipedia.org/wiki/Actuador

[12] http://es.wikipedia.org/wiki/Arquitectura_de_software

180