ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS DEPARTAMENTO DE ELECTRICIDAD
“SISTEMA DE ADQUISICIÓN, SUPERVISIÓN Y CONTROL DE
PEQUEÑAS PLANTA DE PROCESOS BASADO EN
TECNOLOGÍA LIBRES”
Realizado Por:
CESAR JESÚS BRITO BOLÍVAR C.I. 19.675.148
Trabajo de Grado Presentado Ante la Universidad de Oriente Como Requisito Parcial para Obtener el Título de:
INGENIERO ELECTRICISTA.
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS DEPARTAMENTO DE ELECTRICIDAD
“SISTEMA DE ADQUISICIÓN, SUPERVISIÓN Y CONTROL DE
PEQUEÑAS PLANTA DE PROCESOS BASADO EN
TECNOLOGÍA LIBRES”
ASESOR:
_____________________
Barcelona, Febrero 2013 Ing. Danilo Navarro
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS DEPARTAMENTO DE ELECTRICIDAD
“SISTEMA DE ADQUISICIÓN, SUPERVISIÓN Y CONTROL DE
PEQUEÑAS PLANTA DE PROCESOS BASADO EN
TECNOLOGÍA LIBRES””
TRABAJO DE GRADO APROBADO POR EL DEPARTAMENTO DE ELECTRICIDAD DE LA UNIVERSIDAD DE ORIENTE.
El Jurado hace constar que asignó a esta Tesis la calificación de:
_______________________ _______________________
Barcelona, Febrero 2013 Ing. Verena Mercado
Jurado Principal
Ing. Luis Parraguez Jurado Principal
iv
RESOLUCIÓN
De acuerdo al artículo 41 del Reglamento de Trabajos de Grado de la Universidad de Oriente:
“Los trabajos de grado son exclusiva propiedad de la Universidad de Oriente y solo podrán ser utilizados a otros fines con el consentimiento del Consejo de Núcleo respectivo, quien lo participará al Consejo Universitario”
v
vi
vii
RESUMEN
El sistema desarrollado en este trabajo de investigación es una alternativa metodológica para el diseño e implementación de un sistema de adquisición supervisión y control de bajo costo, utilizando herramientas de software y hardware libres. Esta se basara en dos partes, el primero es el desarrollo de un hardware de adquisición, centrado en un microcontrolador con conexión USB, que se encarga de recibir la señales emanadas de los sensores luego de ser tratadas por unos circuitos de acondicionamiento, intervenir en el proceso a través de los actuadores, y a su vez enviar esos datos a través del puerto USB a un ordenador, donde se encontrara un software multiplataforma llamado HmiUdo (segunda parte) el cual es una interfaz hombre-máquina (HMI) que se encargara de muestrear los datos del proceso de forma gráfica para luego almacenarlas en una base de datos. Para la verificación y validación de la metodología se utilizó 3 micrcontroladores uno de 28 pin que es el 18f2550, uno de 40 pin 18f4550 y el atmega 328 junto a otros componentes electrónicos.
viii
ÍNDICE
RESOLUCIÓN ... IV DEDICATORIA ... V AGRADECIMIENTOS ... VI RESUMEN ... VII ÍNDICE ... VIIILISTA DE FIGURAS ... XIII
LISTA DE TABLAS ... XV
CAPITULO1: INTRODUCCIÓN ... 16
1.1 PLANTEAMIENTODELPROBLEMA... 16
1.2. JUSTIFICACIÓNYALCANCE. ... 18 1.3. OBJETIVOS. ... 18 1.3.1. Objetivo General. ... 18 1.3.2. Objetivos Específicos ... 18 1.4. MARCOMETODOLÓGICO ... 19 1.4.1. Tipo de Investigación. ... 19 1.4.2. Nivel de Investigación ... 19 1.4.3. Técnicas de Investigación ... 20
1.5ETAPASDELPROYECTO ... 20
1.5.1. Etapa 1. Revisión Bibliográfica. ... 20
1.5.2. Etapa 2. Descripción de las Premisas y Criterios para el Diseño. 21 1.5.3. Etapa 3. Establecimiento de una Estructura Base para la utilización de los Microcontroladores de Gama media-alta como tarjetas de adquisición de datos. ... 21
1.5.4. Etapa 4. Desarrollo del Programa para la Interfaz Hombre-Maquina utilizando Software Libre. ... 21
ix
1.5.5. Etapa 5. Validación del Funcionamiento del Sistema Diseñado. . 22
1.5.6. Etapa 6. Redacción y Presentación de Trabajo de Grado. ... 22
1.6.ORGANIZACIÓNDELTEXTO ... 22
CAPITULO 2: MARCO TEÓRICO ... 24
2.1. FUNDAMENTOTEÓRICOS. ... 24
2.1.1. Interfaz Hombre Maquina (HMI) ... 24
2.1.2. Adquisición de Datos. ... 26
2.1.3. Tarjetas de Adquisición de Datos. ... 27
2.1.4. Microcontroladores. ... 27
2.1.3. Hardware Libre. ... 30
2.1.4. Arduino ... 30
2.1.5. Pingüino. ... 31
2.1.6. Interfaz Serie ... 32
2.1.7. Bus Serie Universal (USB) ... 33
2.1.8. Simulador de Circuitos ISIS Proteus. ... 41
2.1.9. MPLAB IDE ... 42
2.1.10. MPLAB C18 ... 43
2.1.11. Software Libre (Free Software) y Software de Código Abierto (Open Source Software) ... 43
2.1.12. Python ... 48
2.1.13. wxPython ... 49
2.1.14. PyUSB ... 50
2.1.15. PySerial ... 50
2.1.17. Sqlite3 ... 52
CAPITULO 3. PREMISAS DE DISEÑO DEL SISTEMA ... 54
3.1SISTEMASHMI/SCADAS ... 54
3.2FUNCIONESDELSOFTWAREDEDESARROLLODESISTEMAS HMI/SCADA. ... 55
x
3.4.ESTÁNDARANSI/ISA5.12009 ... 57
3.4.1. Identificación y Símbolos de Instrumentación. ... 57
3.5 ESTÁNDARISA-5.5-1985. ... 66
3.5.1. Símbolos Gráficos para Visualización de Procesos. ... 66
3.5.2. Color. ... 66
3.6.OPCIONESDECONECTIVIDADUSB. ... 68
3.6.1. Transceivers USB. ... 68
3.6.2. Conversores USB a Interfaz Serial o Paralela. ... 69
3.6.3. Controladores de Periféricos. ... 71
3.7.DISEÑOESTRUCTURALDELSISTEMA ... 73
CAPITULO 4 HARDWARE DE ADQUISICIÓN ... 77
4.1.HARDWAREDEADQUISICIÓNDEDATOSUTILIZANDOARDUINOY PINGÜINO. ... 77
4.1.1. Estructura Firmware Archivo principal Arduino (Arduino Tarjeta Adq.pde). ... 78
4.1.2. Estructura Firmware Archivo Principal Pingüino (Pingüino TarjetaAdq.pde) ... 80
4.2.HARDWAREDEADQUISICIÓNUTILIZANDO MICROCONTROLADDORPICY COMPILADORC18DEMPLABIDE. ... 82
4.2.1 Estructura Firmware Main.c (Programa principal) ... 84
4.2.2 Ejemplo de Aplicación de Estructura ... 88
4.2.3. Circuito Electrónico de la Tarjeta de Adquisición de Datos basado en Microcontrolador pic 18f2550 y 18f4550. ... 99
CAPITULO 5. DISEÑO SOFTWARE HMIUDO ... 101
5.1SOFTWAREHMI_UDO. ... 101
5.2ESTRUCTURADELSOFTWAREHMI_UDO. ... 101
5.2.1 HMI_UDO.py ... 102
5.2.2 Proceso_Virtual.py ... 105
xi 5.2.4. Graficar_Proceso.py ... 122 5.2.5. Mando_Proceso.py ... 127 5.2.6. Base_Datos.py. ... 130 5.2.7. Serial_Conect.py ... 133 5.2.8. USB_Pic_Conect.py ... 136 5.2.9. CrearBaseDatos.py ... 138
CAPITULO 6. .VALIDACIÓN DEL SISTEMA HMI_UDO ... 139
6.1.VERIFICACIÓN CON PLANTA P1. ... 144
6.2.VERIFICACIÓN CON PLANTA ARMFIELD FM-51. ... 155
6.2.1- Sensor Flujo ... 156
6.2.2-Sensor de presión 6CF6G ... 157
6.2.3. El Sensor LM35. ... 158
6.2.4. Adaptación del Sistema HMI_UDO a la Planta Armifield Fm51. 159 CONCLUSIÓN ... 164
RECOMENDACIÓN Y TRABAJOS A FUTURO. ... 166
BIBLIOGRAFÍA ... 167
APENDICE ... 168
APÉNDICE.1 GUÍAREFERENCIALLENGUAJE ARDUINO. ... 169
APÉNDICE2.GUÍAREFERENCIALLENGUAJE ARDUINO. ... 171
APÉNDICE3.GUÍAREFERENCIALLENGUAJE PYTHON. ... 172
APÉNDICE4.GUÍAREFERENCIAL WXPYTHON ... 176
APÉNDICE5.GUÍAREFERENCIAL C18COMPILER ... 180
APÉNDICE6.SCRIPTPRINCIPALHMI_UDO.PY ... 190
APÉNDICE7.SCRIPTPARACREARBASEDEDATOS ... 191
APÉNDICE8.SCRIPTBASE_DATOS.PY (18F2550) ... 192
APÉNDICE9.SCRIPTPROCESO_VIRTUAL.PY (18F2550) ... 193
APÉNDICE10.SCRIPTOBJ_COMANDO.PY (18F2550) ... 194
xii
APÉNDICE12.SCRIPTMANDO_PROCESO.PY (18F2550) ... 201
APÉNDICE13.SCRIPTPROCESO_VIRTUAL.PY (18F4550) ... 202
APÉNDICE14.SCRIPTOBJ_COMANDO.PY (18F4550) ... 203
APÉNDICE15.SCRIPTBASE_DATOS.PY (18F4550) ... 209
APÉNDICE16.SCRIPTGRAFICAR_PROCESO.PY (18F4550) ... 210
APÉNDICE17.SCRIPTMANDO_PROCESO.PY (18F4550) ... 212
APÉNDICE18.SCRIPTBASE_DATOS.PY (FM51) ... 213
APÉNDICE19.SCRIPTSERIAL_CONECT.PY (FM51) ... 213
APÉNDICE20.SCRIPTPROCESO_VIRTUAL.PY (FM51) ... 213
APÉNDICE21.SCRIPTOBJ_COMANDO.PY (FM51) ... 213
APÉNDICE22.SCRIPTGRAFICAR_PROCESO.PY (FM51) ... 213
APÉNDICE23.SCRIPTGRAFICAR_PROCESO.PY (FM51) ... 213
APÉNDICE24.SCRIPTMANDO_PROCESO.PY (FM51) ... 213
ANEXOS ... 214
ANEXOA.LISTA DE MATERIALES PARA LA CONSTRUCCIÓN DE TARJETA ADQ18F2550 ... 216
ANEXOB.LISTA DE MATERIALES PARA LA CONSTRUCCIÓN DE TARJETA ADQ18F4550 ... 217
ANEXO C.CIRCUITO ELECTRÓNICO DE LA TARJETA ADQ PIC 18F4550. ... 218
xiii
LISTA DE FIGURAS
Figura 2.0.1 Esquema de una HMI.Fuente:(Rodriguez, p, (2007)) ... 25
Figura 2.0.2 Estructura General de un microcontrolador. ... 28
Figura 2.0.3 Conector USB tipo A (izquierda) y tipo B (derecha). ... 38
Figura 2.0.4 Conector USB Mini tipo A (izquierda) y tipo B (derecha) ... 38
Figura 3.0.1 Diagrama lógico y tabla de verdad del Transceiver USB ... 68
Figura 3.0.2 Diagrama de bloques del FT232 ... 70
Figura 3.0.3 Esquema estructural del Sistema ... 74
Figura 3.0.4 Esquema estructural del sistema (Interfaces) ... 75
Figura 3.0.5 Esquema estructural del sistema (Interfaces detallada) ... 76
Figura 4.0.1 Diagrama de Flujo del Firmware Arduino. ... 79
Figura 4.0.2 Diagrama Flujo Firmware Pingüino ... 81
Figura 4.0.3 Estructura del directorio Firmware Framework Usb ... 83
Figura 4.0.4 Tarjeta de Adquisicion con pic 18f4550 ... 99
Figura 4.0.5 Tarjeta de Adquisición con pic 18f2550 ... 100
Figura 5.0.1 Estructura de Software HMI_UDO ... 102
Figura 5.0.2 HMI_UDO ventana principal ... 103
Figura 5.0.3 Proceso Virtual ... 108
Figura 5.0.4 Animación Texto ... 109
Figura 5.0.5 Animación Corte Rectagular ... 110
Figura 5.0.6 Tuberia Horizontal... 111
Figura 5.0.7 Tuberia Vertical ... 112
Figura 5.0.8 Escala Verical Izquierda ... 112
Figura 5.0.9 Escala Verical Derecha ... 113
Figura 5.0.10 Escala Horizontal Inferior ... 114
Figura 5.0.11 Escala Horizontal Superior ... 114
Figura 5.0.12 Imagen importada por el Comando... 115
xiv
Figura 5.0.14 Datos Recibido Arduino Organizado en un Array ... 136
Figura 5.0.15 Datos Recibidos Por Puerto USB PIC 18f ... 138
Figura 6.0.1 Pasos para utilizar Paquete HMI_UDO ... 141
Figura 6.0.2 Pasos para Utilizar Paquete HMI_UDO (Continuación) ... 142
Figura 6.0.3 Pasos para Utilizar Paquete HMI_UDO (Continuación) ... 143
Figura 6.0.4 Planta P1 ... 144
Figura 6.0.5 Archivo base dato hmi.db sin datos ... 146
Figura 6.0.6 Archivo BasesDatosPlantaP1_4550.db sin datos ... 146
Figura 6.0.7 HMI DE LA PLANTA P1 (MODELO 1) ... 147
Figura 6.0.8 HMI Planta P1 (Modelo 2) ... 147
Figura 6.0.9 Graficas Entradas Analógica Planta P1 (18f2550) ... 148
Figura 6.0.10 Graficas Entradas Analógica Planta P1 (18f4550) ... 148
Figura 6.0.11 Interfaz para Control de Salida (Modelo 1). ... 149
Figura 6.0.12 Interfaz para Control de Salida (Modelo 2) ... 149
Figura 6.0.13 Base de Datos Planta P1 18f2550 (Sqlite Administrador) ... 150
Figura 6.0.14 Base de Datos Planta P1 18f2550 (Archivo Texto) ... 151
Figura 6.0.15 Base de Datos Planta P1 18f4550 (Sqlite Administrador) .... 152
Figura 6.0.16 Base de Datos Planta P1 18f4550 (Archivo Texto) ... 153
Figura 6.0.17 Vista Diagonal Planta FM51 ... 156
Figura 6.0.18 Especificaciones Técnicas del Sensor de Presión ... 157
Figura 6.0.19 HMI DE LA PLANTA FM51. ... 160
Figura 6.0.20 Graficas Entradas Analógica Planta FM51 ... 160
Figura 6.0.21 Interfaz para Control de Salidas... 161
Figura 6.0.22 Base de Datos Planta FM51 (Sqlite Administrador) ... 162
xv
LISTA DE TABLAS
Tabla 2.0.1 Modelos de Arduino ... 31
Tabla 2.0.2 Velocidades de transferencias USB ... 34
Tabla 2.0.3 Pines del bus USB ... 37
Tabla 2.0.4 Clases de dispositivos USB ... 41
Tabla 2.0.5 Términos SQL ... 53
Tabla 2.0.6 Tipos de datos ... 53
Tabla 3.0.1 Características de algunos Sistemas SCADAS ... 56
Tabla 3.0.2 Ejemplo de designación de la identificación de un instrumento usando el estándar ANSI/ISA ... 63
Tabla 3.0.3 Significado e identificación de letras, para la designación de instrumentos funciones o variables mediante tags. ... 64
Tabla 3.0.4 Significado e identificación de letras, para la designación de instrumentos funciones o variables mediante tags. Continuación... 65
Tabla 3.0.5 Significado de Colores Sugerido, para el diseño de despliegues ... 67
Tabla 4.0.1 características del sistema ... 89
Tabla 6.0.1 Característica de la Planta P1 ... 145
Tabla 6.0.2 Características de Prueba Placa ADQ 18F2550 ... 145
Tabla 6.3 Características de Prueba Placa ADQ 18F4450 ... 145
Tabla 6.0.4 Característica de la Planta FM51 ... 159
CAPITULO1: INTRODUCCIÓN
En este trabajo de investigación se describe el diseño y desarrollo de un sistema de adquisición, supervisión y control, el cual está enfocado en ser una alternativa económica y libre a la hora de probar sensores, actuadores, monitorear plantas pilotos e incluso aplicarles control. El sistema se basa en la comunicación entre un hardware de adquisición (Tarjeta de adquisición de datos) y un ordenador a través del protocolo USB. Donde el circuito electrónico del hardware esta compuesto principalmente de un microcontrolador, el cual se le cargara un programa (firmware), para que este pueda habilitar las entradas y salidas digitales, conversión Analógicas-Digital y salidas PWM, a su vez él envió y recepción de datos por el protocolo ya mencionado, del lado del ordenador se encontrara un driver genérico del dispositivo USB proporcionado por microchip y un software que permite la interacción entre el operador y el sistema a monitorear y/o controlar, todo esto basándose en los criterios del software y hardware libre.
1.1 PLANTEAMIENTO DEL PROBLEMA.
En la actualidad los equipos utilizados para medir variables físicas que intervienen en los sistemas, presentan dificultades para apreciar su medición, ya que en ocasiones se encuentran alojados en lugares de difícil acceso, además las señales emanadas por los sensores, generalmente son voltajes y corrientes, que deben ser acondicionadas según los requerimientos de las tarjetas de adquisición de datos (TAD) a utilizar, las cuales convierten las señales analógicas en digitales, para ser aprovechada por herramientas computacionales o software encargadas de aplicar control y de proporcionar una representación grafica de estas variables, brindando la posibilidad de
modificar o tomar acciones sobre el sistema a través de los actuadores, la combinación de estos dispositivos y herramientas computacionales forman lo que se conoce como sistema de adquisición, supervisión y control facilitando la interacción entre el operador y la planta.
Existen empresas que comercializan dispositivos electrónicos de adquisición de datos (TAD) y software (HMI) los cuales generalmente su licencia son muy costosos y con código fuente cerrado, quizás sean rentables económicamente su implementación a nivel industrial, pero cabe destacar que al ser de código fuente cerrado limita ajustar el software a diversos cambios o exigencias funcionales, en el caso de plantas pilotos, utilizadas en laboratorios universitarios seria muy costoso económicamente, y a nivel de estudio no permiten su modificación para la investigación en diversos escenarios.
En tal sentido, surge la problemática de diseñar un Sistema de adquisición, supervisión y control que este desarrollado con software y hardware libres, un ejemplo es el arduino, que son dispositivos electrónicos basados en microcontroladores, que pueden ser utilizados como tarjetas de adquisición de datos, logrando así una alternativa, rápida y económica, manteniendo un funcionamiento robusto con respecto a la necesidad de centralizar la información de las variables y la capacidad de ser adaptable a varios sistemas, sin necesidad de adquirir nuevas licencias.
En base a este planteamiento se formula las siguiente interrogante, ¿Cómo aprovechar las características de los microcontroladores, para ser utilizados como dispositivos electrónicos de adquisición de datos?, tomando en consideración la compatibilidad de comunicación con los algoritmos del software de supervisión y control que se va a diseñar.
1.2. JUSTIFICACIÓN Y ALCANCE.
El alcance del trabajo abarca el desarrollo de una alternativa procedimental y metodológica, para diseñar un sistema de adquisición supervisión y control con software y hardware libre, permitiendo al operador o al estudiante la posibilidad de mejorar y optimizar el código, tanto del software como del hardware (firmware), Esta idea surge de la inquietud a la cantidad limitada de tarjetas de adquisición de datos en el laboratorio de control del departamento de electricidad de la Universidad de Oriente, núcleo de Anzoátegui, limitando la realización y desarrollo de prácticas que permiten reafirmar los conocimientos teóricos en el área de la instrumentación y control. Dichas tarjetas además de ser insuficientes, cuentan con un software y hardware específico de código fuente cerrado y cabe destacar el costo elevado que tienen estos productos privativos.
1.3. OBJETIVOS.
1.3.1. Objetivo General.
Diseñar un sistema de adquisición, supervisión y control de variables de pequeñas plantas de proceso basándose en tecnologías libres.
1.3.2. Objetivos Específicos
1. Describir las premisas y criterios para el diseño, realizando un estudio de las variables típicas de adquisición y los sistemas comerciales existentes.
2. Establecer una estructura base para la utilización de los microcontroladores de gama media-alta como tarjetas de adquisición de datos.
3. Desarrollar el programa para la Interfaz Hombre-Máquina utilizando software libre.
4. Validar el funcionamiento del sistema diseñado.
1.4. MARCO METODOLÓGICO
1.4.1. Tipo de Investigación.
El tipo de investigación es el esquema general o marco estratégico que le da unidad, coherencia, secuencia y sentido práctico a todas las actividades que se emprenden para buscar respuesta al problema y los objetivos que fueron planteados. De este modo, la investigación, según el grado de abstracción, es de tipo aplicada (Zorrilla, 1993), ya que el objetivo que se persigue es diseñar un sistema de adquisición, supervisión y control para ser aplicada en pequeñas plantas de proceso.
1.4.2. Nivel de Investigación
Según Sabino C. (1994) una investigación descriptiva es donde se propone conocer grupos homogéneos de fenómenos, utilizando criterios sistemáticos que permitan poner en manifiesto su estructura. En esta investigación se pretender describir las características y funciones que
ocurren en los sistemas de adquisición, supervisión y control que presenta la problemática de estudio así como también los equipos, y tecnologías para abordar la solución, partiendo de las especificaciones de diseño.
1.4.3. Técnicas de Investigación
1.4.3.1. Observación Directa.
La observación directa se utilizará como una técnica para describir los sistemas de adquisición y supervisión, identificando las variables que intervienen.
1.4.3.1. Recolección de Datos.
Esta técnica se utilizará para el reconocimiento de la información que se encuentra en las hojas datos de cada componente, manuales de programación y bibliografías que intervendrá en el sistema a diseñar.
1.5 ETAPAS DEL PROYECTO
1.5.1. Etapa 1. Revisión Bibliográfica.
Se recolecto toda la información documental concerniente al tópico general de estudio, para su compresión y descripción durante todo el proceso de desarrollo de este trabajo de investigación.
1.5.2. Etapa 2. Descripción de las Premisas y Criterios para el Diseño.
Durante esta etapa se procede al estudio de unas series de software comerciales HMI/SCADA, para obtener información de las variables típicas de adquisición de procesos que manejan, las funciones y los protocolos de comunicación que ofrecen, con la finalidad de establecer especificaciones para el sistema a diseñar.
1.5.3. Etapa 3. Establecimiento de una Estructura Base para la utilización de los Microcontroladores de Gama media-alta como tarjetas de adquisición de datos.
En esta tapa se estudiaran las hojas de datos de los microcontroladores de la familia 18fX550, para proceder a la configuración y programación del firmware base, utilizando el software mplab junto con la librería c18 de microchip.
1.5.4. Etapa 4. Desarrollo del Programa para la Interfaz Hombre-Máquina utilizando Software Libre.
Luego de cumplirse las etapas anteriores, se partirá a la programación del software HMI utilizando el lenguaje de programación Python, wxPython para el entrono gráfico, pySerial para la comunicación serie, pyUSbB para la comunicación por el puerto USB y sqlite3 para la base de datos.
1.5.5. Etapa 5. Validación del Funcionamiento del Sistema Diseñado.
Luego de diseñar el sistema se procede a verificar su funcionamiento para ello se utilizara una planta de proceso a escala, la cual permitirá dar a conocer el uso de las funciones y la robustez de cada scripts codificado y la posibilidad de sus respectivas modificaciones.
1.5.6. Etapa 6. Redacción y Presentación de Trabajo de Grado.
Esta etapa consiste en la preparación de manera ordenada, la interpretación de la información adquirida en el transcurso de la investigación durante el periodo ya mencionado siguiendo los reglamentos establecidos por la universidad de oriente, posteriormente se efectuara la presentación antes la autoridades competentes.
1.6. ORGANIZACIÓN DEL TEXTO
El contenido del presente trabajo de grado está estructurado en seis capítulos, conclusiones, recomendaciones, y apéndices, dispuesto de tal forma que el lector pueda comprender los planteamientos que se exponen y el proceso de desarrollo del mismo, todo esto de manera gradual, vinculado al cumplimiento de los objetivos planteados.
El capítulo dos presenta el marco teórico que da formalidad bibliográfica al trabajo de grado. Aquí el lector podrá ubicar los antecedentes de la investigación y las bases teóricas que la fundamenta,
Finalizando con las conclusiones, recomendaciones del trabajo de grado. Así como también una sección de apéndice, donde se colocan los extensos de los códigos diseñados.
CAPITULO 2: MARCO TEÓRICO
En función del objetivo uno, en este capítulo se presente el marco teórico que da formalidad bibliográfica al trabajo de grado. Aquí el lector podrá ubicar los antecedentes de la investigación que sirvieron como consulta, y que presentan los aspectos relevantes en relación al problema tratado. Luego se muestra las bases teóricas que fundamenta la investigación.
2.1. FUNDAMENTO TEÓRICOS.
2.1.1. Interfaz Hombre Maquina (HMI)
Es el entorno visual que brinda el sistema para que el operador se adapte al proceso desarrollado por la planta .Permite la interacción del ser humano con los medios tecnológicos implementados. Las señales del proceso son conducidas al HMI por medio de dispositivos como tarjetas de entrada/salida en la computadora, PLC, RTU o DRIVER. Todos estos dispositivos deben de tener un protocolo de comunicación que entienda el HMI. En la figura 1.1 se muestra una representación gráfica de los elemento que comúnmente está presente en estos sistemas (Rodríguez, P, 2007, 110).
Figura 2.0.1 Esquema de una HMI.Fuente:(Rodriguez, p, (2007))
2.1.1.1. Tipos de HMI:
2.1.1.1.1. Terminal de Operador.
Consiste en un dispositivo, generalmente construido para ser instalado en ambientes agresivos, donde pueden ser solamente de despliegues numéricos, o alfanuméricos o gráficos. Pueden ser además con pantalla sensible al tacto (touchscreen).
2.1.1.1.2. PC + Software
Esto constituye otra alternativa basada en un PC, en donde se carga un software apropiado para la aplicación. Como PC se puede utilizar cualquiera según lo exija el proyecto, en donde existen los llamados Industriales (para ambientes agresivos), los de panel (Panel PC) que se
instalan en gabinetes dando una apariencia de terminal de operador, y en general se verán muchas formas de hacer un PC, pasando por el tradicional PC de escritorio.
Estos software permiten entre otras cosas las siguientes funciones: Interfaces gráficas que permitan ver el proceso e interactuar con él, registro en tiempo real e histórico de datos y manejo de alarmas. Si bien es cierto sólo con la primera función enunciada es la propiamente HMI, casi todos los proveedores incluyen las otras dos ya sea en el mismo paquete o bien como opcionales. También es normal que dispongan de muchas más herramientas.
Por otro lado, este software puede comunicarse directamente con los dispositivos externos (proceso) o bien hacerlo a través de un software especializado en la comunicación, la cual es la tendencia actual.
2.1.2. Adquisición de Datos.
Este proceso consiste en digitalizar las variables física que se obtiene de un determinado sistema. A la adquisición del valor de un solo punto de datos se le llama muestreo de la señal. Este tiene las siguientes etapas:
1. Los sensores o transductores convierten un fenómeno o magnitud física en una magnitud o señal eléctrica.
2. Un conjunto de circuitos electrónicos para el acondicionamiento de la señal.
3. Un dispositivo electrónico que convierta la señal analógica en digital (tarjeta de adquisición de datos).
4. Una interfaz que va a transformar la información digital presentada por el bloque anterior, en información útil al usuario.
2.1.3. Tarjetas de Adquisición de Datos.
Es un dispositivo electrónico que se encarga de obtener o generar información de manera automatizada desde recursos de medidas analógicas y digitales como sensores y dispositivos bajo prueba. Utiliza una combinación de hardware y software basados en PC para brindar un sistema de medida flexible y definido por el usuario, la interfaz de comunicación entre el dispositivo y la PC generalmente es serie o USB.
Es por lo anterior que estos dispositivos son instrumentos, ideales para una gran variedad de aplicaciones, desde registros de datos simples hasta sistemas integrados, ya que han sido diseñados con el propósito general de medir señales de voltaje. (Ríos, F. (2006)).
Para este proyecto se utilizaran el Arduino UNO y el Pingüino BD4550 que ambos son dispositivos electrónicos de hardware libre, que pueden ser utilizados como tarjetas de adquisición de datos.
2.1.4. Microcontroladores.
Un microcontrolador es un circuito integrado que incorpora procesador, memoria ROM y RAM, puertos de entrada/salida y otros dispositivos de propósito especial como conversores A/D, contadores,
temporizadores y puertos de comunicación. En otras palabras, un microcontrolador es un computador en miniatura.
Estos elementos se convierten en una solución completa para el diseño de sistemas empotrados. Los podemos encontrar en todos los aparatos, instrumentos o maquinaria, desde juguetes, electrodomésticos hasta unidades de disco, impresoras o coches. Hay fabricantes que ofrecen una amplia variedad de microcontroladores, siendo el diseñador del dispositivo el que hace la elección, en la figura 2.2 se muestra la estructura general de un microcontrolador.
Figura 2.0.2 Estructura General de un microcontrolador.
Las empresas fabricantes de microcontroladores habitualmente desarrollan una serie de microcontroladores basados en un microprocesador o CPU (en alguna literatura se menciona como núcleo), a cada uno de ellos se le acondicionan diferentes cantidades de memoria RAM, memoria ROM, con más o menos puertos de entradas y salidas simple o con puertos de
comunicación especializado. Al conjunto de microcontroladores que poseen un mismo núcleo se le conoce como familia.
De las especificaciones del microcontrolador, el más preponderante es el que tiene que ver con la cantidad de bits que puede transmitir en un momento dado. Y de acuerdo al tamaño del bus se tiene la siguiente clasificación de las familias de microcontroladores:
Gama Baja: Las CPU más pequeñas son de 8 bits y cubren un amplio abanico de aplicaciones de propósito general, de bajo costo, compactas, pero a la vez potentes. Dedicados fundamentalmente a tareas de control (electrodomésticos, cabinas telefónicas, smart-cards, algunos periféricos de ordenadores, etc.). También se usan mucho como periféricos de otros micros más grandes.
Gama Media: Las CPU de 16 bits, están destinadas a aumentar la potencia de cálculo, principalmente, y a aumentar las capacidades de memoria de programa y memoria de datos, pudiendo expandir el bus externamente. Usados en tareas de control con cierto grado de procesamiento (control de automóvil, teléfonos móviles, PDAs,...).
Gama Alta: Las CPU de 32 y 64 bits, están destinadas a cubrir campos como multimedia, alta capacidad de proceso, así como un mayor direccionamiento. Normalmente pueden expandir los buses externamente. Usados en aplicaciones como celulares inteligentes, videoconsolas, tablet-pc, etc.
2.1.3. Hardware Libre.
El Hardware libre se puede definir como una materialización particular del conocimiento libre en el área del hardware. En otras palabras, se podrá considerar que un hardware es libre, cuando el conocimiento asociado al mismo es libre.
En este sentido, tomando en referencia las libertades que han sido asociadas a una de las formas de entender al software libre, una manera más explícita de definir al hardware libre sería establecer que el mismo es aquel cuyo código d fuente, especificaciones de proceso de fabricación y diseño conceptual están disponible de forma tal que ofrezcan: libertad de uso, estudio, modificación, distribución y redistribución de las mejoras.
En base a esta definición, desde la fundación Cenditel se está concretando una plataforma de Desarrollo de hardware donde se puedan desarrollar prototipos funcionales para construir, estudiar, y mejorar diseños de hardware libre que aseguren la soberanía tecnológica y estén acores con la sociedad democrática, participativa y protagónica de la nación.
2.1.4. Arduino
Arduino es una plataforma de hardware libre, basado en una sencilla placa con un microcontrolador Atmel AVR y un entorno de desarrollo, diseñada para facilitar el uso de la electrónica en proyectos multidisciplinares, ya que posee puertos de entrada/salida digitales, analógicas y PWM, el número de entrada/salida va a depender del modelo.
Los microcontroladores más usados son el Atmega168, Atmega328, Atmega1280, ATmega8 por su sencillez y bajo coste que permiten el desarrollo de múltiples diseños. Por otro lado el software consiste en un entorno de desarrollo que implementa el lenguaje de programación Processing/Wiring y el cargador de arranque (boot loader) que corre en la placa. Arduino se puede utilizar para desarrollar objetos interactivos autónomos o puede ser conectado a software del ordenador (por ejemplo: Macromedia Flash, Processing, Max/MSP, Pure Data). Las placas se pueden montar a mano o adquirirse. El entorno de desarrollo integrado libre se puede descargar gratuitamente.
Tabla 2.0.1 Modelos de Arduino
Arduino Microcontrolador Digital I/O
Entradas Analogicas PWM
Flash
SRAM EEPROM Clock Speed Interfaz USB Memory UNO ATmega328 14 6 6 32KB 2KB 1KB 16 MHz ATmega8U 2 Decimila ATmega168 14 6 6 16KB 1KB 512 bytes 16
MHz FTDI Duemilanov e ATmega168/328P 14 6 6 16KB/32K B 1KB/2K B 512bytes/1K B 16 MHz FTDI Mega ATmega1280 54 16 14 128KB 8KB 4KB 16 MHz FTDI Mega2560 ATmega2560 54 16 15 256KB 8KB 4KB 16 MHz ATmega8U 2 Nano ATmega168/328 14 8 6 128KB 8KB 4KB 16 MHz FTDI 2.1.5. Pingüino.
Pingüino es un proyecto open-hardware similar a Arduino, su diferencia radica en que está basado en un Microcontrolador PIC de Microchip, al igual que el arduino también es capaz de actuar como un Controlador Lógico de Procesos Embebido , pues puede recibir y procesar datos del exterior a través de sensores o transductores conectados a sus entradas (de luz, temperatura, sonido, otros), para procesarlos lógicamente, y en función de ello, generar cambios
sobre su entorno a través de actuadores o transductores conectados a sus salidas (lámparas, motores, pistones, otros) con total autonomía de un computador personal, aunque puede permanecer conectado a éste, aún luego de ser programado, para enviar y recibir datos desde y hacia el mismo. La programación se realiza utilizando el puerto USB mediante un bootloader y el IDE de pingüino.
Arduino y Pingüino Comparten el mismo lenguaje de programación así que no es tan difícil de migrar a una o la otra, esto ya dependerá del gusto o necesidades del usuario. En la tabla 1.2 se puede observar las características del dispositivo. (hackinglab Pingüino, (2011))
El hardware de Pingüino está basado en el microcontrolador PIC 18F2550 o PIC 18F4550, que tiene un módulo nativo USB y una UART para comunicación serial.
2.1.6. Interfaz Serie
En este tipo de comunicación la información viaja por una línea de bit en bit. Esta transmisión puede ser sincrónica o asincrónica, es decir, si se utiliza una señal de reloj o no durante la transmisión de la información. La gran ventaja de la comunicación serie es su simplicidad y economía al estar implementada por un par de líneas. Aunque la comunicación serie es básicamente enviar datos digitales sobre una línea de bit en bit, existen varias maneras de hacerlo y el proceso de compresión entre el transmisor y el receptor puede variar. Esto da lugar a diversas normas y métodos de comunicación serie que son conocidos como protocolos. (Hoffman, P. 2006).
2.1.7. Bus Serie Universal (USB)
El Universal Serial Bus (USB) es un estándar diseñado para conectar dispositivos, a través de un bus serie. Fue originalmente pensado para conectar dispositivos a computadoras, eliminando la necesidad de conectar tarjetas PCI (o similares), como así también conectar y desconectar los dispositivos sin tener que reiniciar la PC (hot-swap). Sin embargo, hoy en día también se utiliza en consolas de juegos e incluso en algunos equipos de audio y video.
El diseño del protocolo USB está a cargo del USB Implementers Forum (USBIF), una organización compuesta por varias empresas del ramo de la computación y la electrónica, entre las que se encuentran Apple Computer, Hewlett-Packard, Microsoft e Intel.
Existen tres versiones del protocolo (1.0, 1.1 y 2.0). A diferencia de las anteriores, la última versión (2.0) soporta tasas de transferencia de altas velocidades, comparables (o incluso superiores) a la de un disco duro o almacenamiento magnético, lo cual ha permitido ampliar el uso del USB a aplicaciones de video y almacenamiento (discos duros externos). Una de las razones a la cual se atribuye su gran popularidad es que todas las versiones del protocolo son compatibles hacia atrás. Es decir, que cualquier dispositivo 2.0 puede ser conectado a un dispositivo 1.0, aunque funcionará la velocidad del más lento.
Existen tres tipos de velocidades en la comunicación. Ellas son:
Tabla 2.0.2 Velocidades de transferencias USB
TIPO VELOCIDAD
Baja velocidad (low speed) 183 Kbytes/s (1.5Mbit/s) Velocidad completa (full speed) 1.4 Mbytes/s (12Mbit/s) Alta velocidad (high speed) 57 Mbytes/s (480 Mbit/s)
2.1.7.1. Topología
USB tiene un diseño asimétrico ya que consiste de un host controlador conectado a múltiples dispositivos conectados en daisy-chain. USB conecta varios dispositivos a un_host controlador a través de una cadena de hubs. Los hubs (al igual que en redes) son dispositivos que permiten, a partir de un único punto de conexión, poder conectar varios dispositivos, es decir, disponer de varios puntos de conexión. De esta forma se crea una especie de estructura de árbol. El estándar admite hasta 5 niveles de ramificación por host controlador con un límite absoluto de 127 dispositivos conectados al mismo bus (incluyendo los hubs). Siempre existe un hub principal (conocido como el hub raíz) que está conectado directo al host controlador.
Un mismo dispositivo USB puede cumplir varias funciones. Por ejemplo, un mouse puede ser también lector de tarjetas, y de esa forma sería como dos dispositivos conectados al bus USB. Por lo tanto es muy común hablar de funciones en lugar de dispositivos.
2.1.7.2. Funcionamiento.
Los dispositivos tienen asociados unos canales lógicos unidireccionales (llamados pipes) que conectan al host controlador con una entidad lógica en el dispositivo llamada endpoint. Los datos son enviados en paquetes; típicamente estos paquetes son de 64, 128 o más bytes. Estos endpoints (y sus respectivos pipes) son numerados del 0 al 15 en cada dirección, por lo cual un dispositivo puede tener hasta 32 endpoints (16 de entrada y 16 de salida). La dirección se considera siempre desde el punto de vista del host controlador, así un endpoint de salida será un canal que transmite datos desde el host controlador al dispositivo, solo puede tener una única dirección, asimismo endpoint 0 (en ambas direcciones) está reservado para el control del bus.
Cuando un dispositivo es conectado al bus USB, el host controlador le asigna una dirección única de 7 bit (llamado proceso de enumeración) que es utilizada luego en la comunicación para identificar el dispositivo o en particular, la función. Luego el host controlador consulta continuamente a los dispositivos para ver si tiene algo para mandar, de manera que ningún dispositivo puede enviar datos sin la solicitud previa explícita del host controlador.
Para acceder a un endpoint se utiliza una configuración jerárquica de la siguiente manera: un dispositivo/función conectado al bus tiene un único descriptor de dispositivo, quien a su vez tiene uno o varios descriptores de configuración. Estos últimos guardan generalmente el estado del dispositivo (ej: activo, suspendida, ahorro de energía, etc). Cada descriptor de configuración tiene uno o más descriptores de interfaz, y éstos a su vez tienen una configuración por defecto (aunque puede tener otras). Y éstos últimos finalmente son los que contienen los endpoint, que a su vez pueden
ser reutilizados entre varias interfaces y distintas configuraciones. La comunicación USB es bastante compleja y extremadamente más
complicada que una simple comunicación serie.
2.1.7.3. Tipos de Transferencia
Los canales también se dividen en cuatro categorías según el tipo de transmisión:
Transferencias de Control: usada para comandos y respuestas cortos y simples. Es el tipo de transferencia usada por el pipe 0
Transferencias isócronas: proveen un ancho de banda asegurado pero con posibles pérdidas de datos. Usado típicamente para audio y video en tiempo real
Transferencias interruptivas: para dispositivos que necesitan una respuesta rápida (poca latencia), por ejemplo, mouse y otros dispositivos de interacción humana
Transferencias Masivas: para transferencias grandes y esporádicas utilizando todo el ancho de banda disponible, pero sin garantías de velocidad o latencia. Por ejemplo, transferencias de archivos.
En realidad las transferencias interruptivas no son tales ya que los dispositivos no pueden enviar datos sin recibir autorización del host controlador, por lo tanto simplemente le dan más prioridad al sondeo del host controlador.
2.1.7.4. Señalización y Conectores
Las señales USB son transmitidas en un par trenzado (cuyos hilos son denominados D+ y D-) utilizando señalización diferencial half-duplex minimizando el ruido electromagnético en tramos largos. El diseño eléctrico permite un largo máximo de 5 metros (sin precisar un repetidor intermedio).
Existen dos tipos de conectores estándar y mini. Los estándar son los que típicamente encontramos en un computador y vienen en dos tipos: A y B. El tipo A es el que es chato y se encuentra del lado del host controlador, mientras que el tipo B es el cuadrado y se encuentra del lado del dispositivo. Todos los cables son machos, mientras que los enchufes (ya sea en la computadora o los dispositivos) son hembra. No existen intercambiadores de género puesto que las conexiones cíclicas no están permitidas en un bus USB. Los conectores mini siguen la misma política que los estándar pero son utilizados para dispositivos pequeños como Palm y celulares. Los pines de un cable USB son los siguientes:
Tabla 2.0.3 Pines del bus USB
Pin Color Función
1 Rojo BUS(4.4 - 5.25 V)
2 Blanco D-
3 Verde D+
4 Tierra
5 En corto con pin 4 en conector Mini-A, utilizado para USB On-The-Go
A continuación se muestra un diagrama de los conectores (las medidas están en mm) y los números de los pines se corresponden con la tabla anterior.
Figura 2.0.3 Conector USB tipo A (izquierda) y tipo B (derecha).
2.1.7.5. Potencia
El bus USB suministra 5V de continua regulados por cada uno de sus puertos, entre los pines 1 y 4. Por lo tanto, dispositivos de bajo consumo de potencia (que de otra forma vendría con una fuente de alimentación) puede obtener de allí la corriente necesaria para el funcionamiento. El límite de corriente suministrada es de 500mA por cada puerto. Además, el estándar exige no más de 5.25V en ningún caso, ni menos de 4.375V en el peor caso. Típicamente el voltaje se mantiene en los 5V.
Algunos hubs se alimentan directamente del bus USB, en cuyo caso la corriente total de todos los dispositivos conectados a él no puede superar los
500mA. Sin embargo, la especificación permite solo un nivel de hub alimentados por el bus, de forma que no es posible conectado un hub sin alimentación a otro hub sin alimentación. Los hubs con alimentación propia no tienen esta restricción y generalmente son necesarios para conectar dispositivos de alto consumo como impresoras o discos duros.
Cuando un dispositivo es conectado le reporta al host controlador cuando potencia va a consumir. De esta manera el host controlador lleva un registro de los requisitos de cada puerto y generalmente cuando un dispositivo se excede generalmente se apaga, cortándole el suministro de corriente, de forma de no afectar al resto de los dispositivos. El estándar exige que los dispositivos se conecten en un modo de bajo consumo (100 mA máximo) y luego le comuniquen al host controlador cuanta corriente precisan, para luego cambiar a un modo de alto consumo (si el host se lo permite).
Los dispositivos que superen los límites de consumo deben utilizar su propia fuente de poder.
Los dispositivos que no cumplan con los requisitos de potencia y consuman más corriente de la negociada con el host puede dejar de funcionar sin previo aviso 0, en algunos casos, dejar todo el bus inoperativo.
2.1.7.6. Clases de Dispositivos
Los dispositivos que se conectan puede tener sus propios drivers personalizados. Sin embargo, existe lo que se llaman clases de dispositivos que son pequeños estándar para distintos tipos de dispositivos y especifican como deben compartirse los dispositivos en términos de los descriptores de interfaz y de dispositivo, endpoints, etc. Esto permite que todos los dispositivos sean fácilmente intercambiables y/o sustituibles puesto que hablan el "mismo idioma". Por su parte, los sistemas operativos solo tienen que implementar drivers genéricos para todas las clases conocidas de dispositivos lo cual alivia el alto costo de desarrollar y mantener un driver particular para cada producto y modelo.
En conclusión, las clases de dispositivos son una estandarización de funcionalidades a un nivel superior al del bus BUS y que utiliza a éste último como medio de comunicación e intercambio de datos.
Tanto los descriptores de dispositivos como los descriptores de interfaz tiene un byte que identifica la clase. En el primer caso, todo el dispositivo/función pertenece a la misma clase, mientras que en el segundo un mismo dispositivo puede tener diferentes clases, cada una asociada a su descriptor de interfaz.
Dado que el identificador de la clase es un byte, existe un máximo de 253 clases diferentes (0x00 y 0xFF están reservados). Los códigos de las clases son asignados por el USB Implementers Forum, y a continuación se presenta una lista de los más comunes.
Tabla 2.0.4 Clases de dispositivos USB
Código
Clase
0x00 Reservado. Usado en el descriptor de dispositivo para indicar que la clase está identificada en él (o los) descriptores de interfaz. 0x01 Dispositivo de audio. Por ejemplo; tarjetas de sonidos
0x03 Dispositivo de interfaz humana (HID). Por ejemplo: mouses, teclados, joystick.
0x07 Impresoras 0x08
Dispositivo de almacenamiento masivo. Por ejemplo: discos duros, lectores de memoria, cámaras digitales, reproductores MP3.
0x09 Hubs
0x0A Dispositivo de comunicación (CDC por sus siglas en inglés). Por ejemplo: módems, tarjetas de red.
0x0E Dispositivo de video. Por ejemplo: webcams
0xE0 Controladores inalámbricos. Por ejemplo: adaptadores Bluetooth. 0xFF Reservado. Usado para indicar que el dispositivo tiene un driver
personalizado propio que no pertenece a ninguna clase.
2.1.8. Simulador de Circuitos ISIS Proteus.
El paquete electrónico Proteus es una compilación de programas de diseño y simulación electrónica, desarrollado por Labcenter Electronics. Consta de los dos programas principales, ARES e ISIS, y los módulos VSM y Electra (Labcenter, 2011). Proteus está pensado para construir, simular, y realizar la placa de circuito impreso de circuitos electrónicos analógicos,
digitales y mixtos. Con una librería que supera los 6000 modelos de componentes, abacá todo el proceso de diseño de cualquier proyecto electrónico.
Específicamente, el programa ISIS (Inteligent Schemantic Input
Sistem, siglas en ingles), permite diseñar el plano eléctrico del circuito que
se desea realizar con componentes muy variados, desde simples resistencias, hasta alguno que otro microprocesador o microcontrolador, incluyendo fuentes de alimentación, generador de señales y muchos otros componentes con prestaciones diferentes. Los diseños realizados es ISIS pueden ser simulados en tiempo de ejecución, mediante el módulo VSM (Virtual System Modelling), asociado directamente con ISIS.
Lo que diferencia enormemente a Proteus de otros paquetes de CAD electrónico que existen en el mercado, es la poderosa capacidad de simular varios tipos de microcontroladores y microprocesadores: PIC, Atmel, Motorola, Zilog, etc., ya que trata al microcontrolador como un componente más del circuito (Tojeiro, 2009).
2.1.9. MPLAB IDE
Ensamblador, enlazador, gestión de proyectos, depurador y simulador. La interfaz gráfica del usuario MPLAB IDE sirve como un único entorno para escribir, compilar y depurar código para aplicaciones embebidas. Permite manejar la mayoría de los detalles del compilador, ensamblador y enlazador, quedando la tarea de escribir y depurar la aplicación como foco principal del programador (usuario).
2.1.10. MPLAB C18
El compilador MPLAB C18 es un compilador que optimiza el estándar ANSI C en los microcontroladores PIC18. El compilador modifica el estándar ANSI X3.159 -1989 sólo en los puntos en los que se puedan crear conflictos con el soporte del microcontrolador.
El MPLAB C18 tiene las siguientes características:
Compatibilidad ANSI ‟89.
Integración con el MLAB IDE para una mayor facilidad de realización y debugg de proyectos.
Admite ensamblador empotrado.
Gran variedad de librerías.
2.1.11. Software Libre (Free Software) y Software de Código Abierto (Open Source Software)
En la actualidad existen dos movimientos importantes que promueven el desarrollo de Software de libre distribución, estos son:
La Fundación de Software Libre (Free Software Foundation).
2.1.11.1 Fundación de Software Libre (Free Software Foundation).
2.1.11.1.1. Descripción General.
La Fundación de Software libre, desarrolló la Licencia Pública General (GPL: General Public Licence) GNU/GPL, la misma que promueve la libre distribución de Software, incluyendo su código fuente. El objetivo principal es permitir a la comunidad de programadores realizar cambios al código fuente. De acuerdo a la licencia GNU/GPL ninguna aplicación que declare el uso de esta licencia puede ser distribuida sin su código fuente. Compartir entre los programadores el código fuente permite responder a defectos y problemas en las aplicaciones de manera más rápida y efectiva. Por ejemplo, un problema detectado en una distribución de Linux puede solucionarse en días; en cambio, aplicaciones comerciales pueden tardar meses en solucionar un determinado error [10].
2.1.11.1.2. Características Definidas por la Fundación de Software Libre.
Las siguientes características son definidas por la Fundación de Software libre, y determinan si un programa o aplicación cumple con las características de un software libre (Free Software).
La Fundación de Software Libre (Free Software Foundation), define lo siguiente:
“El software libre es una cuestión de libertad, no de precio”, esto permite que los usuarios finales tengan la capacidad de ejecutar, estudiar, copiar, cambiar, distribuir y mejorar un determinado Software bajo el concepto de 4 libertades definidas a continuación [10]:
Libertad 0: Libertad de ejecutar el software, para cualquier aplicación final.
Libertad 1: Libertad de entender y estudiar el funcionamiento del programa, y modificarlo para adaptarlo de acuerdo a las necesidades del usuario.
Libertad 2: Libertad para distribuir copias del software, con el objetivo de beneficiar a la comunidad.
Libertad 3: Libertad de mejorar el programa y publicar la versión modificada y mejorada, con el objetivo de beneficiar a toda la comunidad, para esto el acceso al código fuente del programa es necesario.
En conclusión, un programa es considerado como software libre (Free Software) si los usuarios poseen las libertades mencionadas anteriormente. Además, el propósito del software libre radica en el principio de ejecución y uso del usuario, y no del programador original, por lo que es necesario y obligatorio el acceso al código fuente y la libre distribución de los manuales del software desarrollado. Finalmente, software libre no significa que no sea comercial. El usuario puede haber obtenido una copia de software libre, mediante un pago, o puede haber obtenido una copia sin costo. Sin embargo, sin tener en cuenta como se obtuvo una copia, el usuario tiene la libertad de copiar, modificar y redistribuir el software.
2.1.11.2 Iniciativa de Código Abierto (Open Source Initiative)
2.1.11.2.1. Descripción General.
La Iniciativa de Código Abierto difiere un poco del movimiento de Software Libre, aunque comparten el objetivo principal de distribuir libremente el software. El movimiento de Código Abierto no se preocupa mucho si cierta persona obtiene ganancias de un determinado sistema, el movimiento está más preocupado de la distribución libre del mismo y su código fuente, lo que no implica que sea gratis. (Se debe garantizar que sin importar que el sistema tenga un costo inicial, su posterior distribución libre debe ser asegurada) [10].
2.1.11.2.2. Características Definidas por la Iniciativa de Código Abierto.
La Iniciativa de Código Abierto (OSI Open Source Initiative) se encarga de mantener la definición de código abierto en beneficio de la comunidad y transmitir los beneficios del código abierto [11].
Código Abierto (Open Source) no solo significa acceso al código fuente de un determinado programa. Para que un software o aplicación sea catalogada de código abierto debe cumplir con las siguientes características [11]:
Redistribución libre: Permite a los usuarios vender o distribuir el software libremente.
Código fuente: El Software debe incluir el código fuente, o que pueda ser obtenido libremente. El código fuente debe ser distribuido en forma adecuada, en la cual el programador pueda realizar cambios.
Trabajos derivados: Las modificaciones y los trabajos derivados, pueden ser distribuidos.
Integridad del código fuente del autor: Existe la posibilidad de que la licencia establezca que las modificaciones en el código fuente solo puedan ser distribuidas en forma de parches. Caso contrario, la licencia debe especificar el permiso de distribución del software con su código fuente modificado.
Sin Discriminación a personas o grupos: Todas las personas pueden acceder al Software de Código Abierto.
Sin Discriminación en contra de los campos de aplicación: No se puede restringir el uso en un determinado campo de aplicación. Por ejemplo, en el uso en un negocio particular.
Distribución de la licencia: Todas los usuarios a quienes se redistribuyó el programa, tienen los derechos especificados sobre el mismo.
La licencia no debe ser específica a un determinado producto: Los derechos establecidos de un determinado programa no deben depender en el hecho que el mismo este formando parte de una distribución particular de software.
La licencia no debe restringir otro software: La licencia no puede obligar a otro software que se distribuya de manera conjunta con el Software de Código Abierto, a que sea necesariamente de código abierto.
La licencia debe ser tecnológicamente neutral: No se requiere ninguna aceptación de la licencia.
2.1.12. Python
Python es un lenguaje de programación interpretado y orientado a objetos creado por Guido Van Rossum en 1991. Python es un lenguaje de programación poderoso, pero a su vez muy fácil de aprender y entender, posee las siguientes características:
La implementación de Python se desarrolla bajo la licencia de código abierto, lo que hace que Python pueda ser libremente usado y
distribuido, inclusive para propósito comercial. La Licencia de Python es administrada por la Fundación de Software de Python (Python Software Foundation).
Python es un lenguaje de programación modular. El usuario puede generar módulos reutilizables por otros programas.
Es un lenguaje de programación multiparadigma (varios estilos): o Programación orientada a objetos.
o Programación estructurada. o Programación funcional.
Puede usar un intérprete (Modo interactivo, como Matlab)
Python soporta herencia múltiple y polimorfismo.
Python puede ser ejecutado en Windows, Linux/Unix, Mac OS X, inclusive existe versiones de Python que corren sobre máquinas virtuales .NET y Java.
Python posee un extenso número de librerías estándar y módulos especiales desarrollados para diversas tareas.
Python se enfoca en desarrollar códigos entendibles, coherentes, y de calidad. El código de Python es desarrollado para ser entendible, y como consecuencia, reusable y fácil de mantener, de manera más profunda comparado con otros lenguajes de programación.
2.1.13. wxPython
wxPython es un conjunto de herramientas que permite el desarrollo de programas para la generación de interfaces gráficas de usuario reales (GUIs) muy poderosa, pero a su vez muy simple de usar. wxPython permite al usuario crear y manipular elementos comunes de las interfaces tal como botones y menús, pero también permite crear y manipular elementos menos comunes, como tablas, árboles y editores de texto. Tal como Python, wxPython es un proyecto de código abierto y multiplataforma. (N. Rappin R. Dunn, 2006).
2.1.14. PyUSB
PyUSB tiene como objetivo proporcionar fácil USB acceso al Python lenguaje. El proyecto está dividido en dos versiones principales: la 0.x estable y las versiones en desarrollo 1.0. Todos los esfuerzos se concentran ahora en el nuevo (0.x incompatible) API 1.0. PyUSB 1,0 realza la biblioteca de varias maneras:
Apoyo a libusb 0,1 , 1,0 libusb y OpenUSB .
API fácil de comunicarse con los dispositivos.
Apoyo a backends biblioteca personalizada.
Transferencia isócrono soporte tipo.
100% escrito en Python por ctypes .
Funciona en cualquier versión de Python.
2.1.15. PySerial
PySerial es un módulo de Pyton que administra el acceso al puerto serial. Presenta las siguientes características:
Estado de desarrollo: Módulo Estable.
Licencia: aprobada por la Iniciativa de Código Abierto (OSI Open Source Initiative) y por la Fundación Python Software.
Lenguaje: Inglés.
Lenguaje de Programación: Python.
Permite acceder a las propiedades del puerto serial a través de Python.
Soporta diferentes tamaños de bits de datos, bits de parada, paridad y control de flujo.
El usuario puede emplear o no un tiempo de espera (timeout), para la recepción de datos.
2.1.16. Matplolib
Matplotlib es una librería que permite realizar gráficas en dos dimensiones mediante Python. Sin embargo, los comandos de Matplotlib fueron desarrollados emulando los comandos de generación de gráficas de Matlab; pero, los desarrolladores le agregaron la idea de programación orientada a objetos. Para un mejor uso de los datos a graficar, Matplotlib, hace uso de la librería Numpy, la misma que constituye el paquete fundamental utilizado para realizar cálculos científicos en Python [20].
El código de Matplotlib se divide básicamente en las siguientes interfaces:
Interfaz pylab: Conjunto de funciones provistas por matplotlib. pylab el cual permite al usuario crear gráficas con comandos similares a Matlab.
Interfaz de aplicación de Matplotlib: Es un conjunto de clases las cuales permiten crear y manejar las figuras, gráficas, texto, líneas, etc.
2.1.17. Sqlite3
SQLite es una biblioteca de C que proporciona una base de datos ligera basada en disco que no requiere un proceso de servidor independiente y permite el acceso a la base de datos utilizando una variante no estándar del lenguaje de consulta SQL. Algunas aplicaciones pueden utilizar SQLite para el almacenamiento de datos interno. También es posible que un prototipo de una aplicación utilizando SQLite y después portar el código a una base de datos más grande como PostgreSQL o Oracle.
El módulo del sqlite3 fue escrito por Gerhard Häring. Proporciona una interfaz de SQL compatible con la especificación de DB-API 2.0 descrito por PEP 249
Tabla 2.0.5 Términos SQL
Termino Definición
SQL
El Lenguaje de Consulta Estructurado (del
inglés Structured Query Language) es un lenguaje utilizado para crear, actualizar, eliminar, y consultar información de
una base de datos.
Consulta Búsqueda de información determinada en la base de datos.
Cursos Objeto utilizado para navegar por los registros resultantes de una consulta SQL.
Resultados Conjunto de registros que entrega la consulta SQL. Registro Unidad de información dentro de una tabla. También
llamado fila.
Transaccion Operación con el sistema de manejo de la base de datos.
Tabla 2.0.6 Tipos de datos
SQLite Python
NULL None
INTEGER int or long, depending on size
REAL float
CAPITULO 3. PREMISAS DE DISEÑO DEL SISTEMA
En este capítulo se dará a conocer las características y funciones que tendrá el sistema de adquisición, supervisión y control desarrollado, a través del estudio de sistemas comerciales HMI/SCADA, estándares para el diseño de la interfaz hombre maquina (HMI), opciones de conectividad USB entre PC y hardware de adquisición.3.1 SISTEMAS HMI/SCADAS
Las primeras herramientas para la creación de sistemas Scada fueron desarrolladas para aplicaciones específicas, dependiendo de las características del proceso a supervisar y controlar; por esta razón los sistemas Scada eran adaptados a las necesidades de un proceso específico, como resultado, los proveedores de software de desarrollo de sistemas Scada adaptaron su trabajo previo en aplicaciones específicas, para que el software pueda ser utilizado en otro tipo de industria. Con el tiempo, varios fabricantes desarrollaron paquetes de software capaces de comunicarse con los sistemas y dispositivos de control de una determinada planta, y le dieron al sistema en general escalabilidad y flexibilidad. Sin embargo, ciertos procesos requerían de aplicaciones adicionales, las cuales fueron desarrolladas como módulos específicos [4]. En la actualidad, el objetivo de los proveedores de software para sistemas HMI/Scada es desarrollar una arquitectura abierta que permita su utilización en diversos procesos industriales, con la adición de módulos específicos para determinadas industrias.
3.2 FUNCIONES DEL SOFTWARE DE DESARROLLO DE
SISTEMAS HMI/SCADA.
Supervisar el proceso: El sistema HMI/Scada genera aplicaciones que permiten modificar el estado de una determinada variable de manera remota, a partir del análisis del proceso en un determinado instante de tiempo.
Generar Reportes y Alarmas: El Sistema HMI/Scada permite configurar el sistema para determinar si ha ocurrido un evento no deseado dentro del sistema para después generar la alarma y el reporte respectivo. Estas alarmas se determinan a partir de límites establecidos por el supervisor del sistema.
Generar Algoritmos de Control: Actualmente el software para desarrollo de HMIs permite generar algoritmos de control. Es decir, permite modificar o ajustar el valor de una determinada variable (variable manipulada) del proceso a partir de los valores de ciertas señales de entrada, con el objetivo de mantener una variable (variable controlada) del proceso dentro de valores preestablecidos.
Configura el sistema de Comunicación: Mediante el software de desarrollo de sistemas HMI/Scada, se configura los canales de comunicación con los diversos dispositivos de campo.
Desarrollar despliegues: El software de desarrollo de sistemas Scada tiene módulos que permiten generar los despliegues que describen gráficamente el proceso.
Configurar los sistemas de Gestión de Base de datos: El software de desarrollo de sistemas HMI/Scada permite configurar la base de datos del proceso y las funciones específicas a realizar con los datos almacenados mediante este módulo se estructura el sistema de control y supervisión del proceso, ya que define el grupo de variables involucradas en el sistema.
Tabla 3.0.1 Características de algunos Sistemas SCADAS
Nombre Ignition Stantor Proview Argos LabVIEW NI Tipo LICENCIA GPL LICENCIA LIBRE LICENCIA
Compañia Inductive
Automation Stantor
Mandator and
SSAB Oxelosund CINTAL
National Instruments
Sitio inductive
automation.com stantor.free.fr proview.se cintal.com.ve ni.com
Pais USA Francia Suiza Venezuela EE.UU Estado ACTIVO ACTIVO ACTIVO ACTIVO ACTIVO
Año 2010 2010 2010 2009 2012
Lenguaje Java C, C++ C, C++ y algo de
Java C++ / Fltk C
S.O. Linux, Windows, Mac Linux Fedora, Ubuntu and Mandriva Linux Linux Windows (Linux, Mandriva, RedHat, SUSE), Mac OS Multilenguaje Si Si Si No Si Web HMI Si Si Si Si Si Scripts Si Si Si Si Si Archivado Si Si Si Si Si Tendencia a avance Si Si Si Si Si Control Si Si Si Si y Alarmas Si
Protocolos OPC UA Modbus, TCP/IP Proibus, OPC Modbus, TCP/IP CanBus, DeviceNet, Ethernet, Fieldbus, Modbus, Profibus, Usb/Serial. Dispositivos OPC UA K8000/K8055/K8061/ Arduino, X10 CM11A ABB, Siemens,
Inor, entre otros. PLCs
ADQ, Arduino,
3.3 DESARROLLO DE APLICACIONES HMI.
Las aplicaciones HMI son un conjunto de despliegues que le permiten al operador determinar el comportamiento en tiempo real del proceso. El software de desarrollo de sistemas HMI/Scada presentan módulos que permiten generar despliegues, estos son generados y caracterizados de acuerdo al proceso que representan, sin embargo existen organizaciones que desarrollan estándares con el objetivo de normalizar el desarrollo de interfaces Hombre-Máquina dentro de sistemas de control distribuido. El objetivo de estas organizaciones es que los desarrolladores de despliegues sigan ciertas reglas a la hora de representar a las variables de manera gráfica o mediante identificaciones (Tags), además intentan normalizar el uso de colores y los significados de los mismos.
Como resultado, se tiene una normalización en la presentación del proceso desde el punto de vista estructural, pero no así desde el punto de vista funcional, que depende de las características del proceso.
3.4. ESTÁNDAR ANSI /ISA 5.1 2009
3.4.1. Identificación y Símbolos de Instrumentación.
3.4.1. 1. Propósito.
El propósito de este estándar es establecer medios uniformes a la hora de identificar instrumentos y sistemas de instrumentación. Generar un sistema de designación de símbolos y códigos de los instrumentos y sistemas de instrumentación [8].
