Instalación de un sistema de automatización para el control de la
Anuncio
UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica INSTALACIÓN DE UN SISTEMA DE AUTOMATIZACIÓN PARA EL CONTROL DE LA PLANTA DE ÁCIDO FOSFÓRICO DE LA EMPRESA TRIPOLIVEN, UTILIZANDO EQUIPOS PROPIETARIOS INVENSYSFOXBORO A2 Por HILDEBRAND ALAN VERA ROJAS Sartenejas, Octubre de 2005 UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica INSTALACIÓN DE UN SISTEMA DE AUTOMATIZACIÓN PARA EL CONTROL DE LA PLANTA DE ÁCIDO FOSFÓRICO DE LA EMPRESA TRIPOLIVEN, UTILIZANDO EQUIPOS PROPIETARIOS INVENSYSFOXBORO A2 Informe de pasantía presentado por Hildebrand Alan Vera Rojas Realizado con la asesoría de Tutor Académico: Prof. Ernesto Granado Tutor Industrial: Ing. Jhon Ramírez. PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, Octubre de 2005 UNIVERSIDAD SIMÓN BOLÍVAR Decanato de Estudios Profesionales Coordinación de Ingeniería Electrónica INSTALACIÓN DE UN SISTEMA DE AUTOMATIZACIÓN PARA EL CONTROL DE LA PLANTA DE ÁCIDO FOSFÓRICO DE LA EMPRESA TRIPOLIVEN, UTILIZANDO EQUIPOS PROPIETARIOS INVENSYSFOXBORO A2 Informe de pasantía presentado por HILDEBRAND ALAN VERA ROJAS Realizado con la asesoría de Tutor Académico: Prof. Ernesto Granado Tutor Industrial: Ing. Jhon Ramírez. RESUMEN Basado en la tecnología ArchestrA (A2) y en los dispositivos de control y automatización industrial de la compañía trasnacional, Invensys, se llevaron a cabo las fases iniciales de implementación de un sistema de gestión DCS para la planta de ácido fosfórico, conocida como P205 y propiedad de la empresa TRIPOLIVEN. Para abordar la problemática de la migración y transferencia del DCS de esta planta, se realizó un estudio con base en la narrativa, los lazos y la propuesta de red de control industrial siguiendo los estándares de TRIPOLIVEN y considerando sus necesidades. El procedimiento de implementación se llevó a cabo en varias etapas, por lo que fue necesario generar un plan de acción que se ajustara al cronograma pautado por TRIPOLIVEN para el arranque de la planta. En función de ello, previa entrega de la información revisada por dicha empresa durante el levantamiento, se realizó un análisis inicial para la estimación de los costos de operación del proyecto. El siguiente paso consistió en la realización de un cronograma que comprendía elementos importantes en el proceso de transferencia y migración de la planta, como son: procedimientos de ingeniería, documentación, prueba de equipos, configuración de estaciones de supervisión y control de la planta y la puesta a punto del sistema para la realización de las Pruebas de Aceptación de Fabrica (FAT) y las Pruebas de Aceptación de Sitio (SAT) que se realizarán luego de la entrega de este libro. PALABRAS CLAVES: ArchestrA, Automatización Industrial, Control Industrial, Narrativa de Control. PROYECTO DE GRADO Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero Electrónico Sartenejas, Octubre de 2005 DEDICATORIA A mis padres, Luis Antonio Vera Crespo e Isabel Rojas de Vera, quienes siempre me han apoyado en todo momento, con su cariño, sus consejos y recomendaciones, para alcanzar todas las metas que me he propuesto en la vida, en los momentos felices y en los desagradables. Espero nunca fallarles, porque como padres han sido los mejores del mundo, nunca dejaré de hablar bien de ustedes, mis primeros mentores, a quienes salvé la vida en una oportunidad siendo yo apenas un bebé ¿Lo recuerdan verdad? Aquel viaje desde Pto. Píritu a Caracas es una historia familiar muy especial para mí. Tu madre, que me enseñaste tantas cosas, nunca he dejado de admirar tu capacidad artística, lo que lograbas hacer con tus manos y que hoy día no puedes hacer más, que me enseñaste desde pequeño a no depender de ti cuando no estuvieras presente en el que hacer de la vida diaria por cualquier circunstancia, gracias a tus previsiones aprendí lo básico del arte culinario y demás quehaceres del hogar, y lo más importante del mundo, sentir respeto por el género femenino, hoy día debo ayudar a cuidarte. A ti padre, que con el ejemplo, paciencia y consejos me has preparado para la vida, has ayudado inconmensurablemente a la formación de mi carácter y mis sentimientos de varón, el respeto a las personas, sin distingo de clase social, color o religión, siempre te he admirado como el hombre responsable que eres, hoy te admiro más, pues, has tenido que asumir el rol de mi madre en muchas de las cosas que hacía, seguro que te has ganado el cielo por atenderla en todo momento. Para Ludwig Antonio Vera Rojas y Erwin Vladimir Vera Rojas, quienes me han brindado su apoyo constante, sobre todo en estos últimos siete años y medio en circunstancias tan difíciles para mis padres y para mí. Ustedes, que siempre han sido fuente de inspiración, ejemplo y alegría desde que tengo memoria, mis mejores amigos, mis confidentes, mis hermanos. Ustedes junto a mis padres tienen un lugar especial en mi corazón, un lugar que jamás nadie podrá poseer. Hoy día espero tener lo que seguramente dirías en estos casos, Ludwig, “buen viento y buena mar en la vida”, en verdad espero que Poseidón esté siempre a mi favor. Los barcos y el sol han proporcionado más brillo a tus pensamientos. A ti Erwin, te debo muchas de las cosas que aprendí en mi preparación para el trabajo, el trato con la gente a nivel laboral y muchas cosas relacionadas, además, siempre le has dado un toque especial de cordura a la familia; a final de cuentas, ser el más gordito tiene sus ventajas. Para el “individuo”, Luis Raúl Vera Flores y sus hermanas, Niurka y Ninoska. Nunca imaginé tener sobrinos tan particularmente especiales, ya espero compartir más tiempo con ustedes. Para Antonio Salazar, excelente profesor y excelente persona, quien a pesar de las vicisitudes afrontadas en mi primera experiencia con el estatus de tesista me supo brindar su apoyo para salir adelante en tan grave, desestimulante y frustrante situación. Fuiste parte del sistema de ignición para volver a arrancar la máquina, por así decir. A mi tutor académico, Ernesto Granado, quien estuvo bombardeado durante 20 semanas con la información de mi desempeño en Invensys a través de mi “Bitácora”. Gracias por su apoyo y consideración durante todo este tiempo, sobre todo en la etapa final de mi pasantía cuando los objetivos finales lucían distantes. Fue muy provechoso para mí el haber mantenido comunicación constante con ud. vía correo-e. A uno de mis mejores amigos y compañeros de estudios, Rubén Chacón, quién con su experiencia como instructor del idioma inglés ha estado “al pie del cañón” mientras trataba de traducir secciones de documentos que no lograba comprender muy bien y que empleé como aportes en mis investigación documental; ni hablar del gran trabajo de logística que lograste hacer para que cierto personaje no muriera de inanición, mientras todavía andaba trabajando como loco frente a una computadora en ELE-207, cuando era tesista, te aseguro que Hman lo agradece mucho, así como también el nuevo Hman, el pasante e indetenible guerrero. A mi buen amigo, Alexander Sánchez, excelente persona. Espero que celebremos junto a otros compañeros y amigos en el mejor pozo que he visto en el cerro El Ávila. Esto bien vale un salto desde la cascada, si no varios. Por cierto, Hman te agradece tu contribución con la logística y con el apoyo moral en tiempos difíciles. Al mejor compañero de sufrimientos en el miniproyecto y tutor industrial de esta, mi pasantía larga, el Ing. Jesús Carrero. Gracias por brindarme la oportunidad de salir adelante, después de todo, tu y yo sabemos que trabajar en equipo es algo fundamental, por algo éramos como extraterrestres tanto en la carrera como en CITE. A mis buenos amigos de CITE: Dom Oráa, el más chamo de todos, Maximiliano Rodríguez, el tartamudo intelectual, Luis Ferrer, heredero de mi mando en CITE, Daniel Ponticelli, amigo computista y uno de los más preciados para mí, bajo esa denominación, entre todos los de mi cohorte. A todos los compañeros de Invensys, en especial a Ender Rivas, Jhon Ramírez, Bernardo Ovalles e Irma Aguilar. Son el mejor equipo humano que he visto interactuar en una organización como lo es Invensys. A Franco Comerlati, gerente de proyectos, quien a pesar de los tropiezos siempre procuró que todo sucediera de la mejor manera posible en beneficio de quienes estábamos involucrados en la ejecución de este proyecto. Espero no haberme olvidado de ninguno y si así fue, pues, mis disculpas, el descanso no ha sido uno de mis mejores aliados últimamente, igual les guardo mi aprecio. ¡ALLES FERTIG! ¡AUF WIEDER SEHEN UNIVERSITÄT SIMÓN BOLÍVAR! ÍNDICE GENERAL ÍNDICE DE TABLAS..................................................................................................................iv ÍNDICE DE FIGURAS ................................................................................................................ v LISTA DE SÍMBOLOS Y ABREVIATURAS ...............................................................................vi INTRODUCCIÓN........................................................................................................................1 CAPÍTULO I................................................................................................................................6 MARCO TEÓRICO .....................................................................................................................6 PROCESO INDUSTRIAL DEL ÁCIDO FOSFÓRICO. ...........................................................6 1 Producción del ácido fosfórico: ......................................................................................7 1.1 Proceso húmedo. ......................................................................................................7 1.2 Proceso térmico........................................................................................................9 CAPÍTULO II ............................................................................................................................11 TECNOLOGÍAS PARA EL CONTROL DE PROCESOS INDUSTRIALES. .............................11 2.1 SISTEMA DE CONTROL SUPERVISORIO Y ADQUISICIÓN DE DATOS (SCADA). .......................11 2.2 SISTEMAS DCS..................................................................................................................13 2.3 BUSES DE CAMPO (FIELDBUSES)..................................................................................15 2.3.1 Fieldbus FOUNDATION (FF). ...............................................................................15 2.3.1.1 Bus H1. .............................................................................................................16 2.3.1.2 Bus HSE ó H2. ..................................................................................................19 2.3.2 PROFIBUS. .............................................................................................................19 2.3.2.1 PROFIBUS-FMS. .............................................................................................20 2.3.2.2 PROFIBUS-DP.................................................................................................20 2.3.2.3 PROFIBUS-PA. ................................................................................................21 2.3.3 DeviceNet.................................................................................................................22 2.3.4 AS-i. .........................................................................................................................23 2.3.5 MODBUS.................................................................................................................23 2.3.6 HART. ......................................................................................................................25 2.4 TECNOLOGÍAS DE TRANSMISIÓN EN BUSES DE CAMPO. .....................................26 2.4.1 RS485.......................................................................................................................26 2.4.2 RS485-IS. .................................................................................................................27 2.4.3 Fibra óptica. ............................................................................................................28 ii 2.4.4 Modelo FISCO.........................................................................................................28 2.5 VÍAS DE COMUNICACIÓN HARDWARE-SCADA Y HARDWARE-DCS. ......................................28 2.5.1 DDE. ........................................................................................................................29 2.5.2 NetDDE. ..................................................................................................................30 2.5.3 OPC Foundation. ....................................................................................................31 2.5.3.1 COM. ................................................................................................................31 2.5.3.2 OLE...................................................................................................................32 2.5.3.3 Automatización OLE. .......................................................................................32 2.5.3.4 DCOM. .............................................................................................................32 2.5.3.5 ActiveX..............................................................................................................32 2.5.4 ArchestrA (A2). ........................................................................................................33 CAPÍTULO III ...........................................................................................................................35 PLANTEAMIENTO Y ESTUDIO DEL PROBLEMA. ...............................................................35 3.1 ANTECEDENTES.................................................................................................................35 3.2 CONDICIONES DE LA PLANTA P2O5.....................................................................................36 3.3 PROBLEMÁTICA PLANTEADA. .............................................................................................37 3.4 DEFINICIÓN DEL PROYECTO. .............................................................................................37 3.5 ALCANCE DEL PROYECTO...................................................................................................38 CAPÍTULO IV ...........................................................................................................................39 DESARROLLO E IMPLEMENTACIÓN. ..................................................................................39 4.1 PLANIFICACIÓN DEL CRONOGRAMA DE ACTIVIDADES. .........................................................39 4.2 FASE DE DOCUMENTACIÓN Y PROGRAMACIÓN DEL ENTRENAMIENTO. ..................................40 4.2.1 Documentación........................................................................................................40 4.2.2 Entrenamiento. ........................................................................................................42 4.3 FASE DE ANÁLISIS DE LA PLANTA P2O5...............................................................................44 4.3.1 Análisis topológico de la red de TRIPOLIVEN........................................................44 4.3.2 Reunión en la planta de TRIPOLIVEN....................................................................48 4.4 CONFIGURACIÓN INICIAL DE PROYECTO EN FOXBORO A2....................................................50 4.5 ANÁLISIS Y APORTE DEFINITIVO DE UNA PROPUESTA DE CONFIGURACIÓN DE RED EN TRIPOLIVEN.........................................................................................................................51 4.6 EJECUCIÓN DEL PROYECTO. ..............................................................................................52 iii 4.6.1 Procura de tarjetas de red duales y sistema operativo compatible. .......................52 4.6.1.1 Proceso administrativo de tarjetas de red duales. ...........................................52 4.6.1.2 Proceso administrativo para la adquisición de sistema operativo compatible con Suite Voyager..........................................................................................................53 4.6.2 Programación de los bloques de control.................................................................54 4.6.2.1 Programación analógica..................................................................................54 4.6.2.2 Programación digital. ......................................................................................55 4.6.3 Configuración de las pantallas de operación. ........................................................56 4.6.4 Configuración de la galaxia en Wonderware A2.....................................................56 CAPÍTULO V.............................................................................................................................61 DISCUSIÓN DE RESULTADOS...............................................................................................61 5.1 PROGRAMACIÓN ANALÓGICA. ............................................................................................61 5.2 PROGRAMACIÓN DIGITAL...................................................................................................63 5.3 DOCUMENTACIÓN DEL PROYECTO Y MANEJO DE COSTOS. ...................................................64 CONCLUSIONES......................................................................................................................65 RECOMENDACIONES .............................................................................................................67 REFERENCIAS BIBLIOGRÁFICAS .........................................................................................69 ANEXOS ....................................................................................................................................72 ANEXO A – TABLA COMPARATIVA DE BUSES DE CAMPO..............................................................73 ANEXO B – ESQUEMA DE RED DE FIBRA ÓPTICA EN TRIPOLIVEN ............................................74 ANEXO C – ESQUEMA DE RED PROPUESTA POR TRIPOLIVEN..................................................75 ANEXO D – HERRAMIENTA DE CONFIGURACIÓN DE TAGS SEGÚN MODELO DE PLANTA, PLANT MODEL....................................................................................................................................76 ANEXO E – HERRAMIENTA DE ASIGNACIÓN DE TAGS A LOS DISPOSITIVOS DE ENTRADA/SALIDA, IO ALLOCATION............................................................................................................................77 ANEXO F – PROGRAMACIÓN EN LINTOOLS. DETALLE DE BLOQUE PID. .....................................78 ANEXO G – HERRAMIENTA DE CONFIGURACIÓN POR PUNTO DE CONEXIÓN, ITOOLS. ..................79 ANEXO H - PROGRAMACIÓN EN LINTOOLS. DETALLE DE BLOQUE ANALÓGICO DE ENTRADA. ......80 ANEXO I – EJEMPLO DE PANTALLA DE OPERACIÓN (SECCIÓN DE MOLIENDA)..............................81 iv ÍNDICE DE TABLAS Tabla 2.2.1 – Comparación de los sistemas SCADA versus sistemas DCS. .............................15 Tabla 2.3.1 – Tipos de cable Fieldbus y longitudes máximas del bus. .....................................18 Tabla 2.3.2 – Valores límite de capacitancia e inductancia para Ex-i. ....................................18 Tabla 3.1.1 – Propiedades de los derivados de la planta P2O5. ...............................................36 Tabla 4.1.1 – Cronograma y fases del proyecto. ......................................................................39 Tabla 4.2.1 – Herramientas contenidas en Foxboro A2. ...........................................................41 Tabla 4.2.3 – Componentes de hardware en Foxboro A2. ........................................................42 v ÍNDICE DE FIGURAS Figura 1.1 – Estructura molecular del H3PO4. ..........................................................................6 Figura 1.2 – Proceso húmedo de una planta de ácido fosfórico. ...............................................8 Figura 1.3 – Proceso húmedo de una planta de ácido fosfórico (continuación)........................9 Figura 1.4 – Proceso térmico de una planta de ácido fosfórico...............................................10 Figura 2.1.1 – Arquitectura genérica del software SCADA. ....................................................12 Figura 2.1.2 – Configuración de un SCADA típico. .................................................................13 Figura 2.2.1 – Arquitectura básica de un DCS.........................................................................14 Figura 2.3.1 – Estructura y descripción de las capas de comunicación de FF........................16 Figura 2.3.2 – Esquema de combinación de las tecnologías H1 y HSE. ..................................19 Figura 2.3.3 – Variantes de PROFIBUS...................................................................................20 Figura 2.3.4 – Pila de comunicación MODBUS.......................................................................24 Figura 2.3.5 – Ejemplo de arquitectura MODBUS. .................................................................25 Figura 2.3.6 – Método de modulación FSK de HART. .............................................................26 Figura 2.3.7 – Superposición en comunicación HART. ............................................................26 Figura 2.5.1 – Esquema representativo de la tecnología ArchestrA. .......................................33 Figura 3.1.1 – Diagrama de los procesos de producción en TRIPOLIVEN.............................35 Figura 4.2.1 – Rango de los DCS de Invensys. .........................................................................40 Figura 4.3.1 – Combinación de propósitos de redes dispares..................................................45 Figura 4.3.2 – Esquema planteado por Invensys en torno al Web Server. ...............................45 Figura 4.3.3 – Esquema sugerido al cliente..............................................................................46 Figura 4.3.4 – Análisis de grafo de la red (fibra óptica) propuesta por TRIPOLIVEN. ..........48 Figura 4.4.1 – Proyecto generado en Foxboro A2. ...................................................................50 Figura 4.6.1 – Organización de las áreas de TRIPOLIVEN. ...................................................57 Figura 4.6.2 – Estructura del DCS de TRIPOLIVEN. ..............................................................59 Figura 4.6.3 – Estructura de plantillas y sus componentes (objetos). ......................................60 Figura 5.1.1 – Diagrama de programación analógica elaborada en LinTools. ......................61 Figura 5.1.2 – Vista de la librería de los bloques de programación para el T940. .................62 Figura 5.1.2 – Detalle de la base de datos de P2O5 que se descargará en el T940..................63 vi LISTA DE SÍMBOLOS Y ABREVIATURAS AS-i Actuator Sensor Interface – Interfaz sensor actuador. A2 ArchestrA – Tecnología de automatización de Invensys. Ca3 ( PO4 )2 Fórmula molecular de la roca fosfática (fosforita). HF Fórmula molecular del Ácido fluorhídrico. H 3 PO4 Fórmula molecular del ácido fosfórico. H 2 SO4 Fórmula molecular del ácido sulfúrico. H 2O Fórmula molecular del agua. SO2 Fórmula molecular del Dióxido de azufre. P2O5 Fórmula molecular del pentóxido de sodio. O2 Fórmula molecular del oxígeno. P2O5 Fórmula molecular del Pentóxido de sodio. Denominación de la planta de ácido fosfórico (TRIPOLIVEN, C.A.). CaSO4 • 2 H 2O Fórmula molecular del sulfato cálcico dihidratado. CaSO4 • 12 H 2O Fórmula molecular del sulfato cálcico hemihidratado. CaSO4 Fórmula molecular del sulfato cálcico. SiF4 Fórmula molecular del tetrafluoruro de silicio. °C Grados centígrado(s). I O Input/Output – Entrada/Salida. ISO OSI International Standardization Organization/Open System Interconnection – Organización Internacional de Estandarización/Interconexión de Sistemas Abiertos. L E Lectura / Escritura. TCP IP Transmisión Control Protocol/Internet Protocol – Protocolo de control de transmisiones/Protocolo de Internet. vii H2S Fórmula molecular del sulfuro de hidrógeno. A Amper. ABB Inc. Asean Brown Boveri Incorporated – Corporación energética fabricante de sistemas de automatización en Europa. Active X Tecnología de la compañía Microsoft derivada de OLE y aplicada a Internet. API Application Programming Interface – Interfaz de programación de aplicaciones. B.D. Base de datos. Bps Bits por segundo. BVS Bergbau Versuchsstrecke im DMT - Sección de pruebas de la industria de explotación minera de la DMT. Ca, Co Capacitancias. COM Component Object Model – Modelo de componentes de objeto. CP Control processor – Procesador de control. CSMA Carrier Sense Multiple Acces – Acceso múltiple por detección de portadora. DAS Data Access Specification – Especificación para acceso a datos. DCOM Distributed Component Object Model – Modelo de componentes de objeto distribuido. DCS Distribuited Control System - Diagrama de proceso e identificación. DDE Dynamic Data Exchange – Intercambio dinámico de datos. DDT Distributed Data Transfer – Transferencia de datos distribuidos. DLL Dynamic Linking Library – Biblioteca de enlace dinámico. DMT Deutsche Montan Technologie, GmbH – Tecnología Alemana de Montaña, Sociedad de Responsabilidad Limitada. DOS Disk Operating System – Sistema operativo en disco. viii DP Decentralized Peripheral – Periféricos descentralizados. Ex-i IIB ó IIC Instrumentación intrínseca para áreas potencialmente explosivas del grupo IIB o IIC. FAT Factory Acceptance Test – Pruebas de aceptación de fábrica. FDS Functional Design Specification – Especificación del diseño funcional. FF Fieldbus FOUNDATION – Fundación Fieldbus. FIP Flux Information Processus Factory Instrumentation Protocol – Protocolo de instrumentación en fábrica. FISCO Fieldbus Intrinsically Safe Concept – Concepto intrínsecamente seguro de bus de campo. FMS Fieldbus Message Specification – Especificaciones de mensajes de bus de campo. FSK Frequency Shift Keying – Modulación por desplazamiento de frecuencia. g Gramo. ha Hectárea(s). Hacker(s) Pirata(s) informático(s). HART Highway Addressable Remote Transducer – Transductor remoto direccionable por línea de transmisión. HDLC High Level Data Link Control – Control de transmisión de datos del alto nivel. HMI Human Machine Interface – Interfaz humano-máquina. HSE High Speed Ethernet – Ethernet de alta velocidad. INSQL Industrial SQL – SQL Industrial. Km Kilómetro(s). Kps Kilo bits por segundo. ix Lo, La Inductancias. m Metro. mA Mili amper. MB Protocolo MODBUS. MB+ MODBUS PLUS – Protocolo de red de alta velocidad con pase de testigo. Mbps Mega bits por segundo. mH Mili Henrio. ml Mililitro. MMI Man Machine Interface – Interfaz hombre-máquina. mV Mili voltio. NetDDE Network DDE – DDE de red. nF Nano Faradio. NT New Technology – Nueva tecnología (Microsoft). ODBC Open DataBase Connectivity – Conectividad abierta a base de datos. OLE Object Linking and Embedding – Enlace e incrustación de objetos. OPC OLE for Process Control – OLE para control de procesos. P&ID Process and Identification Diagram - Diagrama de proceso e identificación. PA Process Automation – Automatización de procesos. PC Personal Computer – Computadora personal. PFAT Previous Factory Acceptance Test – Pruebas previas para aceptación en fábrica. PI PROFIBUS International – Organización que agrupa a los desarrolladores del estándar de bus de campo, PROFIBUS. PLC Programmable logic controller – Controlador lógico programable. x Pot Potentiometer input – Entrada de potenciómetro PROFIBUS Process Field Bus – Bus de proceso de campo. PTB Physikalisch-Technische Bundesanstalt – Laboratorio Federal de Estándares de Alemania. PYRO Optical Pyrometer – Pirómetro óptico. RTD PT100 resistance thermometer – Termómetro de resistencia PT100 RTU Real Time Unit – Unidad de procesamiento en tiempo real. SAT Site Acceptance Tes - Pruebas de aceptación en campo. SCADA Supervisory Control and Data Acquisition - Sistema de Control Supervisorio y Adquisición de Datos. SIP Interoperable Systems Project – Proyecto de interoperabilidad de sistemas. SQL Structured Query Language – Lenguaje de consulta estructurado. T.R. Tiempo real. TAG(s) Etiqueta(s). TC Termocupla. V Voltio. VME Versa Module Eurocard bus. VMS Virtual Memory System – Sistema operativo de memoria virtual. µF Micro Faradio. INTRODUCCIÓN El trabajo que se presenta a continuación tiene como objeto llevar a cabo un proyecto de migración e implantación de un sistema de control, DCS, en la planta de ácido fosfórico, denominada P2O5, perteneciente a la compañía TRIPOLIVEN C.A., quien de ahora en adelante será denominado, indistintamente, por su nombre de persona jurídica o como cliente. Dicha empresa está enclavada en el sector de empresas mixtas de la región de Morón, Edo. Carabobo y forma parte del complejo petroquímico de dicha zona. La solución planteada para este reto se inicia con el estudio de las distintas herramientas que posee Invensys en la manipulación de los equipos electrónicos y electromecánicos que forman parte de un sistema de control distribuido de bajo costo (DCS). El proyecto se llevará a cabo empleando el sistema propietario identificado como Foxboro A2, de la mencionada trasnacional, el cual será utilizado durante el proceso de automatización de la planta de ácido fosfórico perteneciente al cliente. Con la disponibilidad de la información suministrada sobre la base de las necesidades del cliente, se procederá a la generación del plan de acción del proyecto, sus diversas fases de ingeniería, que comprenden tanto el empleo de los equipos así como también la programación y puesta a punto del sistema de control automatizado de la planta (PFAT) a la vez que se realiza una estimación inicial de los costos involucrados durante la realización del proyecto. Luego de la planificación inicial, se procederá a la preparación de los equipos para la implementación in situ del sistema (FAT) con lo cual se verificará el funcionamiento de los distintos equipos involucrados. Al culminar esta etapa de pruebas se realizará la documentación de las mismas y se preparará la información para llevar acabo las pruebas en campo (SAT) para su verificación ante el cliente y su posterior aceptación. Resumen biográfico de Invensys. Con más de cien años de experiencia, Invensys, ha venido ofreciendo productos y servicios en función de los requerimientos de las necesidades del cliente y del empuje tecnológico. La historia de esta compañía comenzó con Siebe plc, compañía formada por Augustus Siebe inventor de la campana de buceo o escafandra no autónoma, en 1819. A partir de ese momento la compañía de Augustus Siebe fue adquiriendo, no solo experiencia, sino también fue 2 desarrollando otras capacidades en el área de automatización y servicios relacionados. Paralelo al crecimiento de la compañía, la compañía de Siebe fue adquiriendo otras empresas muy competitivas en el mercado, tales como: • 1990 - Foxboro Company: automatización industrial, monitoreo de plantas, manejo de información y sistemas de control automatizado. • 1994 - Triconex: sistemas de parada de plantas de emergencia de triple redundancia. • 1997 - APV plc: pioneros en las placas para intercambio de calor y el proveedor más importante de componentes de ingeniería para uso diario en los procesos de la industria de alimentos, bebidas, farmacéutica, químicos, marítimo y otros. • 1997 - Eurotherm: originalmente fabricantes de controladores de temperatura y hoy día proveedor de soluciones para control a nivel mundial, manejo de datos y procesos automatizados. • 1997 - Wonderware: líder proveedor, en la actualidad, de software para automatización industrial y pioneros en la utilización del Windows como plataforma para operar software de automatización HMI en diversas industrias, plantas y procesos. • 1997 - SimSci: enfocada en la simulación a nivel de planta para la optimización de los procesos en refinerías e industrias petroquímicas. • 1999 - Esscor: enfocada en proveer simuladores para el entrenamiento para operadores de planta. • 1999 – BTR (Alemania) y Siebe (Inglaterra) se unen para formar Invensys. En la actualidad, Invensys, procura estar a la vanguardia tecnológica mundial en el competido mercado de la automatización, procesos y control industrial, en tanto sigue desarrollando nuevas ideas y planteando nuevas soluciones por sí misma y a través de sus filiales alrededor del mundo. Justificación e importancia: Invensys, CA es la sucursal venezolana de la trasnacional del mismo nombre cuya base de operación se encuentra en Reino Unido. En la actualidad la labor de Invensys consiste en brindar soluciones en el área de control y procesos automatizados a nivel global que permitan el incremento de la productividad, reducción de desperdicios, reducción de costos de la cadena de suministros, incremento de la rentabilidad y perfeccionamiento cuantificable del 3 rendimiento general de las compañías, entre las que se encuentran: Shell, BP, Bayer, Kraft, Eli Lily, Shering-Plough y Bombardier. La plataforma tecnológica con la que cuenta Invensys en la prestación de sus servicios a nivel global comprende: − Empleo de una arquitectura tecnológica integrada: o Sistemas de control en tiempo real basado en interfaz humano-máquina. o Integración entre sistemas nuevos y heredados independientes del protocolo. o Sistemas de manejo de información. − Aplicaciones de alto rendimiento, sistemas y servicios. − Empleo de la Arquitectura de programación en automatización industrial e información, ArchestrA (A2), que extiende el uso de los sistemas heredados en conjunción con los nuevos desarrollos. − Centro de desarrollo propio. Actualmente, como parte de su red de proyectos y servicios, se encuentra en fase inicial el proceso de implantación del sistema de automatización de una planta de ácido fosfórico que forma parte del conjunto petroquímico de Morón, con lo cual se desea optimizar el control de las diversas etapas que componen dicha planta en la actualidad. Sin embargo, dada la existencia de otros sistemas ya empleados en la planta, se debe procurar la correcta comunicación entre los protocolos existentes y aquellos que se van a emplear en la solución a implementar, es decir, todos los datos que recaben los equipos a través de los sensores y demás elementos colectores de información deberán ser transformados para la debida interpretación por el sistema de gestión y manipulación de los actuadores y demás elementos de control ya empleados en la planta. Con el plan de servicios de ingeniería que se llevará a cabo y que fue descrito anteriormente, se procurará, de la mejor manera posible, la ejecución del proyecto. En tal sentido se realizarán todas las adaptaciones que el cliente desea y con ello garantizar los objetivos que promueve Invensys entre toda su red de clientes a nivel mundial. 4 Objetivo general: Implementación de un sistema automatizado para el control de la planta de ácido fosfórico (P205), de la empresa TRIPOLIVEN, empleando tecnología propiedad de Invensys, programación del sistema y calibración de los equipos, comunicación entre la plataforma seleccionada por el cliente y el sistema de gestión existente en la planta que monitorean los procesos de producción. Objetivos Específicos: − Documentación y adquisición de conocimientos sobre la programación y uso de las herramientas de Foxboro A2. − Adaptación y familiarización con los equipos seleccionados por el cliente para la automatización de la planta de ácido fosfórico. − Pruebas iniciales entre los equipos involucrados y el sistema de automatización de Invensys. − Familiarización con los modelos procedimentales de Invensys y elaboración del plan de acción para la implementación del sistema en planta según los requerimientos de un cliente. − Evaluación general de los posibles problemas a encontrar y aporte de soluciones más idóneas según el caso y la experiencia acumulada en la compañía. − Adquisición de experticia en la evaluación y estimación de costos relativos a la implementación de un sistema de automatización considerando los requerimientos de un cliente. − Apreciación de las pruebas en fábrica, detección y corrección de las fallas acaecidas en el proceso de implementación. − Evaluación completa de los resultados y del rendimiento de la planta ante Invensys. − Generación de la documentación en función del trabajo realizado y de todos los elementos involucrados durante la ejecución de la implementación. − Adquisición de experticia con base en la evaluación practicada por la empresa y por el cliente. 5 En el presente informe se describirá con detalle cada una de las fases que están involucradas en el desarrollo del proyecto. En tal sentido se explica brevemente el contenido de cada uno de los capítulos que lo conforman: CAPÍTULOS I y II: Marco Teórico. Se da explicación de todos los conceptos necesarios que están involucrados con el desarrollo del proyecto en su totalidad. CAPÍTULO III: Planteamiento y Estudio del Problema. Se desglosa la información del proyecto propuesto por la empresa, antecedentes, condiciones existentes y la delimitación del mismo. CAPÍTULO IV: Desarrollo e implementación. Contiene la descripción detallada de las fases del proyecto, la planificación de las actividades, documentación y entrenamiento, análisis de la planta de ácido fosfórico, configuración y ejecución de las tareas asociadas a la migración del sistema DCS. CAPÍTULO V: Discusión de resultados. Esta sección describe los objetivos alcanzados en la ejecución del proyecto y los detalles sobre la programación tanto analógica como digital así como el análisis y comparación de costos entre sistemas DCS. CONCLUSIONES: Se analizan y discuten los resultados obtenidos durante la ejecución del proyecto. RECOMENDACIONES: Se presentan y argumentan una serie de ideas basadas en la experiencia y aprendizaje adquirido a través del desarrollo del proyecto. Así mismo, se dan algunas sugerencias para un mejor desenvolvimiento de las actividades de la compañía, Invensys. 6 CAPÍTULO I MARCO TEÓRICO En los siguientes dos capítulos se expondrá al lector toda la información que permitirá, en primer lugar, reconocer las características de una planta industrial de ácido fosfórico como la que se tratará en el presente trabajo, y en segundo lugar, se mostrarán un conjunto de tecnologías estandarizadas que están asociadas al control de cualquier proceso o planta industrial. PROCESO INDUSTRIAL DEL ÁCIDO FOSFÓRICO. El ácido fosfórico o H3PO4, es un compuesto químico cuyo aspecto físico se caracteriza por ser líquido, semitransparente y ligeramente amarillento. Comúnmente se produce en disolución y resulta ser útil en el laboratorio por su resistencia a la oxidación, reducción y evaporación. La estructura molecular del ácido fosfórico se puede apreciar en Figura 1.1 [1]. Figura 1.1 – Estructura molecular del H3PO4. Las aplicaciones de este compuesto son variadas por lo que se le encuentra como ingrediente de bebidas no alcohólicas (refrescos de Cola), en pegamento para prótesis dentales, se emplea como catalizador en metales inoxidables, fosfatos que se usan como ablandadores de agua, fertilizantes, detergentes, suplemento para alimento animal (rumiantes, cerdos y aves) en sistemas intensivos de producción de carne, leche y huevos, entre otros [1]. El ácido fosfórico se produce a través de dos métodos industriales: el proceso húmedo y el proceso térmico. En ambos casos se pueden obtener concentraciones suficientes para las aplicaciones ya mencionadas, sin embargo, el proceso térmico es con el que se pueden lograr mayores concentraciones de ácido; a pesar de esa ventaja, si se comparan los costos de producción, el proceso húmedo es mucho más económico que el térmico [1]. 7 1 Producción del ácido fosfórico: 1.1 Proceso húmedo. El proceso de producción de H3PO4 se inicia al hacer reaccionar ácido sulfúrico (H2SO4) con roca fosfática proveniente de la naturaleza. La roca se muele hasta que es pulverizada y el reactivo pasa a alimentar a un reactor junto con el flujo del reactivo H2SO4, esto sucede de manera continua. La reacción combina el calcio proveniente de la roca fosfática con sulfato, formando así el compuesto CaSO4 o yeso que luego es separado de la solución por filtración. En esta etapa del proceso, dependiendo del tipo de hidratación, se obtiene como producto yeso con dos moléculas de agua (CaSO4 • 2H2O → Dihidratación) o yeso con media molécula de agua (CaSO4 • ½H2O → Hemihidratación). Las ventajas del proceso de hemihidratación se evidencian en una mayor concentración de ácido fosfórico respecto a su contraparte, el proceso de dihidratación [1]. La ecuación química que define el proceso dihidratado es: Ca3 ( PO4 )2 + 3H 2 SO4 + 6 H 2O → 2 H 3 PO4 + 3[CaSO4 • 2 H 2O ] ↓ (1) Para obtener la mayor concentración de ácido fosfórico posible y disminuir los costos por evaporación, normalmente, el 93% de H2SO4 es empleado en la reacción. Debido a la criticidad de la relación proporcional entre los reactivos, roca fosfática y ácido dentro del reactor, es extremadamente necesario contar con un sistema automático de control muy preciso que regule el flujo de entrada de los mismos [1]. Durante la reacción, cristales de yeso son precipitados y separados del ácido por filtración. Los cristales deben ser lavados a fondo para producir al menos un 99% de recuperación del ácido fosfórico filtrado. Luego del lavado, la mezcla de yeso es bombeada a un pozo de yeso para su almacenamiento, típicamente a cielo abierto. El agua es trasegada con sifón y reciclada a través de un estanque de enfriamiento al proceso de ácido fosfórico. Un aproximado de 0,3ha se requiere por cada Mg diario de P2O5 procesado [1]. El calor generado en el reactor es considerable. En antiguas plantas el calor se removía soplando aire sobre la “superficie de la mezcla”. Las plantas modernas llevan una parte de la mezcla a un enfriador-separador flash al vacío y lo reciclan de vuelta al reactor [1]. El proceso húmedo de ácido fosfórico, normalmente, contiene de 26% a 30% de P2O5. En la mayoría de los casos, el ácido debe estar fuertemente concentrado para reunir las 8 especificaciones de la producción de los fertilizantes. Dependiendo del tipo de fertilizante a ser producido, el ácido fosfórico tiene una concentración típica de 40% a 55% de P2O5 cuando se usan 2 ó 3 evaporadores de vacío [1]. En las Figuras 1.2 y 1.3 se presentará un esquema de las etapas (diagrama de flujo) de producción de H3PO4 según el proceso húmedo [1]. Figura 1.2 – Proceso húmedo de una planta de ácido fosfórico. 9 Figura 1.3 – Proceso húmedo de una planta de ácido fosfórico (continuación). 1.2 Proceso térmico. La materia prima para la producción de ácido fosfórico por medio del proceso térmico consta de los siguientes componentes: el fósforo elemental (amarillo), el aire y el agua. Este proceso de obtención de H3PO4 se realiza en tres grandes pasos: combustión, hidratación y humidificación (desempañamiento) [1]. En la combustión, el fósforo elemental es quemado (oxidado) en un ambiente aireado dentro de una caldera a temperaturas de 1650°C a 2760°C para formar pentóxido de sodio (Reacción 2). Este compuesto es hidratado con H3PO4 o agua para producir líquido de ácido fosfórico fuerte (Reacción 3). En la humidificación, paso final, se remueve “la humedad en el ácido fosfórico del vapor en la combustión gaseosa” antes de ser liberado a la atmósfera. Esto es hecho, usualmente, con “humidificadores de gota de alta presión”. En la Figura 1.4 [1] se presenta un esquema típico del proceso térmico utilizado en la producción de ácido fosfórico. P4 + 5O2 → 2 P2O5 (2) 2 P2O5 + 6 H 2O → 4 H 3 PO4 (3) 10 Figura 1.4 – Proceso térmico de una planta de ácido fosfórico. La concentración de H3PO4 producto del proceso térmico tiene un rango, normalmente, de 75% a 85%. Estas altas concentraciones son requeridas para productos químicos de “alto grado” y la manufactura de otros productos no fertilizantes. Las plantas más eficientes recuperan cerca del 99,9% del fósforo elemental quemado como ácido fosfórico [1]. Debido a la complejidad de una planta de este estilo y de lo peligroso que resulta manipular compuestos como el ácido sulfúrico o el ácido fosfórico, resulta imprescindible conocer con detalle los distintos métodos de control industrial. En tal sentido, y para conocer las distintas herramientas que se tienen a mano, se deberá tener una mínima comprensión de las tecnologías involucradas en el control de una planta industrial. Ellas serán explicadas en el Capítulo II de este libro. 11 CAPÍTULO II TECNOLOGÍAS PARA EL CONTROL DE PROCESOS INDUSTRIALES. En este capítulo se expondrán una serie de tecnologías comúnmente utilizadas en el control de procesos industriales, los conceptos aquí expuestos constituirán la base que permitirá identificar, clasificar, establecer y desarrollar, todos y cada uno de los pasos que son necesarios para completar el proceso de migración de la planta P2O5 de TRIPOLIVEN. 2.1 Sistema de Control Supervisorio y Adquisición de Datos (SCADA). El acrónimo de SCADA, es empleado para definir una filosofía de control que data de los años sesenta que combina la utilización de equipos (hardware), de programas (software) y una intervención constante del operador (usuario) [2]. Un sistema de este tipo está basado en el uso de un conjunto de computadores (Esclavos) que se encargan de la recolección de toda la información que se deriva de un grupo de sensores o transmisores en tiempo real y que luego será llevada a un computador central (Maestro), desde el cual los operadores realizan tareas de supervisión y control, igualmente, en tiempo real. Las conexiones entre los distintos elementos involucrados se realizan a través de redes que permiten la comunicación de largas, medianas y cortas distancias por lo que suelen utilizarse medios de transmisión como: líneas telefónicas, conexiones directas, redes LAN / WAN o radio enlaces [3]. El procedimiento para la ejecución de las funciones inherentes a un sistema SCADA se inician con la recolección de información por los computadores, a través de la red de transmisores interconectados a los mismos, los cuales al detectar un problema en algún lugar, como por ejemplo: el desperfecto en un sector de la línea de producción de una planta industrial o anomalías de una radio base en una red celular, transfieren la información relacionada con la falla al computador central que deberá alertar al operador sobre la criticidad de ésta, al mismo tiempo se presenta de manera lógica y ordenada la información, se realizan tareas de análisis y se entregan las propuestas o estrategias de control preprogramadas para tales fines. En cualquier caso se deja en manos del operador la ejecución del control desde la consola, o por el contrario, las tareas de control son ejecutadas automáticamente por el sistema 12 en el computador central desde donde se enviarán las señales a los actuadores a través de la red. Todo esto depende del nivel otorgado al SCADA para la ejecución de las labores de control así como del grado de sofisticación y configuración del computador maestro. Los sistemas SCADA abarcan una gran gama de aplicaciones en muchas áreas y distintos tipos de ambientes, tales como: telecomunicaciones, agua y desechos, energía nuclear o eléctrica, refinación de petróleo y gas, transporte público, industria de alimentos, seguridad, entre otros. Los sistemas SCADA operan en los sistemas operativos: DOS, VMS y UNIX. En los últimos años los desarrolladores de estos sistemas han migrado a sistemas como Windows NT y algunos a Linux. En la Figura 2.1.1 se presenta un esquema genérico de la arquitectura de un software SCADA [4] y a continuación, en la Figura 2.1.2 se muestra una arquitectura típica de estos sistemas [5]. Figura 2.1.1 – Arquitectura genérica del software SCADA. 13 Figura 2.1.2 – Configuración de un SCADA típico. 2.2 Sistemas DCS. Es el acrónimo que identifica a un Sistema de Control Distribuido que data de los años setenta y que, a diferencia de la filosofía de los sistemas SCADA, se caracterizan por realizar las tareas de control automatizadas desde múltiples computadoras y/o consolas con poca intervención de los operadores. Un DCS consta de los siguientes elementos: instrumentos de campo (transductores o transmisores), buses de comunicación (MODBUS, PROFIBUS, HART), multiplexores y demultiplexores y una interfaz humano-máquina (HMI). Un sistema DCS, comúnmente, tiene la facilidad de interconectarse con otros sistemas de su tipo o a sistemas secundarios como los SCADA. Esto quiere decir que la tecnología de las redes de comunicación, en los SCADA y en los DCS, suelen ser del mismo tipo por lo que en ambos casos los buses de comunicación pueden ser de la misma clase [6]. 14 Las operaciones de control en un sistema DCS siguen un patrón prácticamente idéntico comparado con el SCADA, la diferencia radica en que las estrategias de control son automatizadas y se dividen entre varias unidades de procesamiento (CP) ubicadas en cada una de las secciones de la planta. Esta característica es la que define con claridad la arquitectura de un DCS ya que las tareas de control son divididas entre muchos microcomputadores, los cuales ejecutan todas las labores mientras que los operadores se dedican a supervisar el estatus de las alarmas. En caso de que ocurra una falla, dependiendo de la criticidad de la misma y en última instancia, el operador o un nivel superior de usuario puede tomar acciones directas tal y como se haría en un SCADA típico en el que el operador ejecuta el control. En algunos casos se deja a voluntad del operador el arranque manual de motores o de válvulas, todo depende de las necesidades o requerimientos que los ingenieros de planta consideren conveniente. En la Figura 2.2.1 se presenta un ejemplo genérico de una arquitectura de un DCS. Figura 2.2.1 – Arquitectura básica de un DCS. En la Tabla 2.2.1 se presenta una tabla comparativa de las características de un sistema SCADA y uno DCS: 15 Tabla 2.2.1 – Comparación de los sistemas SCADA versus sistemas DCS. ATRIBUTO ARQUITECTURA TIPO DE CONTROL ÁREA DE ACCIÓN ELEMENTOS DE ADQUISICIÓN DE DATOS Y CONTROL MEDIOS DE COMUNICACIÓN BASE DE DATOS SCADA Centralizada Supervisorio Geográficamente distribuida DCS Distribuida Regulatorio Planta RTU, PLC CP, PLC Radio enlaces (satelital o terrestre), líneas telefónicas, conexión directa, LAN, WAN Centralizada LAN, conexión directa Distribuida 2.3 BUSES DE CAMPO (Fieldbuses). Los buses de campo engloban a todas aquellas arquitecturas o tecnologías de transporte de datos que a través de un medio físico (cable de cobre, fibra óptica, radiofrecuencia, etc.) permiten enlazar las comunicaciones entre los dispositivos que ejecutan control (PLC, CP, etc.) con aquellos que realizan trabajo (sensores, actuadores, motores, válvulas, alarmas, interruptores, contactores, etc.) sobre una red industrial de dispositivos distribuidos en campo [7]. Existe un amplio espectro de buses de campo. Entre ellos se puede mencionar los siguientes: 2.3.1 Fieldbus FOUNDATION (FF). Nace de la unión entre el grupo ISP y la WorldFIP en 1994 como una organización sin fines de lucro cuyo objetivo es el desarrollo y mantenimiento de un bus de campo estándar a nivel internacional. Este estándar de bus, el cual lleva el mismo nombre de la organización que lo creó, es un modelo abierto y está orientado, básicamente, a la interconexión de dispositivos en las industrias de proceso continuo y/o control distribuido. En la actualidad existen dos versiones del estándar identificados como nivel H1 y nivel HSE. Las características más importantes que definen a este bus de campo son: • Seguridad intrínseca para su utilización en ambientes peligrosos o explosivos. • Dispositivos alimentados por bus. • Topología de árbol o lineal. 16 • Capacidad de comunicación de múltiples maestros. • Comportamiento dinámico determinista (predecible). • Transferencia de datos distribuido (DDT). • Modelo estandardizado de bloques para las interfaces uniformes de dispositivos (interoperabilidad e intercambiabilidad). • Flexibilidad de opciones para las extensiones basadas en las descripciones del dispositivo. Las especificaciones del estándar están basadas en el modelo de capas de comunicación ISO/OSI – 7 y de acuerdo a las especificaciones IEC, las capas comprendidas entre los niveles 3 y 6, incluidas, no se utilizan. FF está constituido por tres grandes elementos funcionales como son: la capa física, la pila o capa de comunicación (Stack) y la capa de aplicaciones de usuario (véase la Figura 2.3.1) [8]. Figura 2.3.1 – Estructura y descripción de las capas de comunicación de FF. Las versiones que existen de la tecnología FF se clasifican en dos grupos: 2.3.1.1 Bus H1. Las especificaciones del bus están contenidas en IEC 61158-2 y cumple con las siguientes características [8]: 17 • Para la transferencia de datos se emplea el código Manchester. La tasa de transferencia máxima es de 31,25Kbps. • Para una comunicación apropiada se requiere que los dispositivos de campo tengan suficiente voltaje. Cada dispositivo debe de tener al menos 9V. Para cumplir con este requerimiento existen herramientas de software que calculan la corriente resultante y los voltajes entre terminales basándose en la topología de la red y que determinan tanto la resistencia de la línea de transmisión como las fuentes de alimentación. • El bus H1 permite que los dispositivos de campo sean alimentados por el propio bus. La fuente de alimentación es conectada a la línea de transmisión del bus de la misma manera (configuración paralela) que el dispositivo de campo. Los dispositivos de campo energizados por fuentes de alimentación distintas al del bus, deben ser conectados a sus propias fuentes. • Debe asegurarse que el consumo de potencia de los dispositivos actuales sea mucho menor que la potencia suministrada por las fuentes de alimentación. • Las topologías de red típicamente utilizadas son: topología lineal o, cuando son equipadas con cajas de unión, estrella, de árbol o la combinación de varias topologías. Los dispositivos se conectan mejor usando conectores tipo T vía ramales o derivaciones cortas (short spurs) para habilitar la conexión/desconexión de dispositivos sin interrumpir la comunicación. • La máxima longitud de una derivación es de 120m y depende del número de derivaciones usadas así como también del número de dispositivos por derivación. • Sin repetidores, la máxima longitud en un segmento H1 puede ser tan larga como 1900m. Y hasta con 4 repetidores puede alcanzarse un máximo de 5 x 1900m = 9500m. El ramal desde un dispositivo de campo al bus se incluye en el cálculo total de longitud. • El número de usuarios por buses está limitado a 32 en áreas intrínsecamente seguras. En áreas potencialmente explosivas este número se reduce a solo unos pocos dispositivos debido a las limitaciones de la fuente de alimentación. 18 • Varios tipos de cable son empleados en FF (ver Tabla 2.3.1). El Tipo A es recomendado como el cable de bus de campo preferido y solamente este tipo de cable está especificado para alcanzar el límite de longitud de 1900m. • Necesariamente, se requieren de dos terminadores por segmento de bus, uno de ellos cerca o al final de la línea de transmisión. • No es obligatorio que los cables sean apantallados o blindados, sin embargo, son recomendados para prevenir posibles interferencias y para un mejor desempeño del sistema. • El responsable de la planta debe asegurarse que los requerimientos de seguridad intrínseca sean cumplidos durante la planificación y la instalación de la red de comunicación. Por ello, la capacitancia e inductancia tanto del segmento como del dispositivo debe ser calculado para cumplir con los límites permisibles (ver Tabla 2.3.2). Tabla 2.3.1 – Tipos de cable Fieldbus y longitudes máximas del bus. TIPO A TIPO B TIPO C TIPO D Descripción Par trenzado blindado Par trenzado sencillo o multi- Par multitrenzado con trenzado sin cubierta blindaje. blindada Multi-núcleo, sin pares trenzados y sin blindaje Sección Transversal 0.8 mm2 (AWG 18) 0.32 mm2 (AWG 22) 0.13 mm2 (AWG 26) 1.25 mm2 (AWG 16) Longitud Máxima (Incluyendo los ramales) 1900 m 1200 m 400 m 200 m Tabla 2.3.2 – Valores límite de capacitancia e inductancia para Ex-i. Grupo Co (Ca) Lo (La) IIC 165 nF 0,35 mH IIB 1,14 µ F 1,04 mH 19 2.3.1.2 Bus HSE ó H2. Fue desarrollado en Francia a finales de los años 80 y normalizado por EN 50170 [9]. Está basado en la tecnología estándar Ethernet orientado al control industrial. Los componentes necesarios son ampliamente utilizados y disponibles a bajo costo. HSE opera hasta 100Mbps y se puede emplear tanto líneas de transmisión de cobre como de fibra óptica [8]. Ethernet opera con un método de acceso al cableado aleatorio, CSMA. Este método solo puede ser aplicable a un número limitado de aplicaciones de automatización debido a que se requiere de capacidades de tiempo real. Las altas tasas de transmisión habilitan el bus para responder lo suficientemente rápido cuando la carga en el bus baja y los dispositivos son pocos. Los requerimientos de ingeniería ameritan de tiempo real para cualquier caso [8]. En la Figura 2.3.2 se presenta un esquema de la forma en que se visualizaría la conexión entre las dos tecnologías de Foundation Fieldbus [8]: Figura 2.3.2 – Esquema de combinación de las tecnologías H1 y HSE. 2.3.2 PROFIBUS. Es el acrónimo para el estándar abierto de bus de campo desarrollado a partir del año 1987 por las empresas alemanas: Bosch, Klöckner Möller y Siemens con el auspicio del gobierno alemán y el apoyo de varias instituciones del país [10]. En el año de 1989 la adoptó la norma alemana DIN 19245, parte I y II. La parte III, Profibus-DP, se definió en el año de 1993. Se confirmó como norma europea en el año de 1996 bajo el código EN 50170 sin modificaciones 20 [11]. También forma parte del conjunto de buses normalizados internacionalmente bajo el código IEC 61158 e IEC 61784 [12]. El estándar de PROFIBUS tiene las siguientes variantes según su aplicación [11]: • PROFIBUS-FMS. • PROFIBUS-DP. • PROFIBUS-PA. Estas variantes se pueden visualizar, incluyendo sus características más relevantes, a través del esquema de la Figura 2.3.3 [11]: Figura 2.3.3 – Variantes de PROFIBUS. 2.3.2.1 PROFIBUS-FMS. Esta variante provee al usuario una amplia selección de funciones, las cuales, sin embargo, la hacen más compleja de implementar comparada con otras variantes. La potencialidad del servicio FMS puede ser utilizada para resolver tareas de comunicación extensas y complejas. Esta variante de PROFIBUS soporta comunicaciones entre sistemas automatizados (PLC y estaciones automatizadas) así como también intercambio de datos con instrumentos de campo. Por tanto, FMS puede ser usado en un amplio rango de aplicaciones, operando a velocidades típicas de transmisión de buses de campo [11]. 2.3.2.2 PROFIBUS-DP. La variante DP es la solución de alta velocidad de PROFIBUS. Ha sido diseñada y optimizada, especialmente, para la comunicación entre sistemas automatizados y dispositivos 21 de campo descentralizados. Por tanto, PROFIBUS-DP requiere menos de 2ms para la transmisión de 1KB en la entrada y salida de datos. De esta manera cualquiera de las tareas de comunicación en tiempo crítico puede ser resuelta [11]. Intercambio cíclico de datos: PROFIBUS-DP se comunica vía tráfico de datos cíclico exclusivamente. Cada dispositivo de campo intercambia datos de entrada y salida con el dispositivo automatizado, el maestro clase-1, dentro de un ciclo de tiempo determinado [11]. Operación y monitoreo con un maestro clase-2: en ingeniería de procesos así como también en edificios y procesos automatizados, las tareas de operación y monitoreo requieren un dispositivo de visualización adicionalmente al dispositivo automatizado. Este maestro clase-2 es responsable de arranque, parametrización, y monitoreo de funciones de los dispositivos de campo actualizados. Ellos requieren que los datos de los dispositivos sean leídos y escritos durante su operación independientemente de los ciclos de control [11]. Servicio acíclico para arranque, parametrización y monitoreo: como las especificaciones originales no previeron ningún servicio especial para estas tareas, las extensiones apropiadas de las funciones fueron definidas en 1997. Estas extensiones pueden ser implementadas, opcionalmente, y son compatibles con el protocolo DP existente y las versiones anteriores. La variante DP extendida es referida como PROFIBUS-DPV1. Además de los servicios cíclicos de comunicación DP, éste también ofrece servicios acíclicos para mensajes de alarma, diagnósticos, parametrización y control de dispositivos de campo [11]. 2.3.2.3 PROFIBUS-PA. La tercera variante PROFIBUS, PROFIBUS-PA, reúne los requisitos especiales de la industria de procesos automatizados. La comunicación PA está basada en los servicios proveídos por DPV1 y es implementado como un sistema parcialmente contenido en un sistema de comunicación DP de alto nivel. A pesar de que las aplicaciones automatizadas en ingeniería de fabricación requieren ciclos de tiempo cortos, de unos pocos milisegundos, otros factores son de importancia en procesos automatizados, tales como [11]: • Técnicas intrínsecamente seguras de transmisión. • Los dispositivos de campo son alimentados remotamente a través del cable del bus. 22 • Transmisión de datos confiable. • Interoperabilidad (estandarización de las funciones de los dispositivos). Protocolo de acceso al bus estandarizado: el aspecto de “seguridad intrínseca” y “alimentación remota por bus” fueron descuidados al principio cuando PROFIBUS fue estandardizado. Solo cuando el estándar internacional IEC 1158-2 fue publicado en octubre de 1994 se convirtió en una técnica conveniente e internacionalmente especificada para esta área de aplicación e implementada en el estándar europeo EN 61158-2. La especificación PROFIBUS-PA, publicada en marzo de 1995, incluye esta técnica de transmisión para instalaciones intrínsecamente seguras y dispositivos de campo alimentados remotamente en los cables del bus [11]. 2.3.3 DeviceNet. Este bus fue desarrollado por Allen-Bradley [9] y fue dado a conocer en 1994, luego pasó a ser una especificación abierta soportada por la organización ODVA. DeviceNet es un bus que está basado en el estándar CAN. La capa física y capa de enlace se basan en ISO 11898 y en la especificación Bosch 2.0. En la actualidad es una de las más sofisticadas aplicaciones industriales sobre bus CAN [13]. Sus características más resaltantes son: • Se pueden conectar hasta 64 nodos. • Las velocidades de conexión están comprendidas entre 125 y 500 Kbps. • Las distancias máximas permitidas oscilan entre los 100 y 500 m. • El modelo de los servicios de comunicación y el comportamiento externo de los nodos está orientada a objetos. • Las definiciones de los mensajes y conexiones para funcionalidades tipo maestroesclavo, interrogación cíclica, “strobing” o interrogación pulsante de dispositivos, mensajes espontáneos de cambio de estado, comunicación punto a punto, modelo productor-consumidor, carga y descarga de bloques de datos, archivos, etc. 23 2.3.4 AS-i. Bus desarrollado inicialmente por Siemens. Es especialmente conveniente para los niveles más bajos de automatización de plantas donde hayan dispositivos de campo simples (frecuentemente binarios), como los interruptores o sensores, que necesitan interactuar en una red de automatización local e independiente controlada por PLC o PC. Actualmente, las especificaciones están contenidas en el estándar IEC TG 17B [9]. Básicamente es un sistema de conexión electromecánica de bajo costo diseñado para operar sobre cable bifilar sin apantallamiento. Las características más resaltantes de este estándar son [14]: • La red puede adaptar cualquier tipo de topología (bus lineal, árbol, estrella o anillo). • Se pueden interconectar hasta un máximo de 31 dispositivos esclavos. • Puede transportar datos hasta una distancia máxima de segmento de 100m. • Para mayores distancias se pueden interconectar hasta 3 segmentos empleando repetidores. • Existen puentes que permiten la interconexión hacia redes PROFIBUS. • Este sistema representa el reemplazo digital de arquitecturas de cable tradicional, como el cable paralelo. • Se evita el peligro de la inversión de polaridad en la conexión por su diseño de contactores. • Emplea codificación Manchester para lograr inmunidad al ruido. • Un circuito integrado ha sido desarrollado para integrarlo en módulos de usuario y dispositivos de campo. 2.3.5 MODBUS. El protocolo de MODBUS es una estructura de la mensajería desarrollada por la compañía Modicon en 1979 para su aplicación en PLCs [9]. Se utiliza para establecer comunicaciones maestro-esclavo/cliente-servidor entre dispositivos inteligentes. Es un estándar de facto, totalmente abierto y además, es el protocolo de red más utilizado por las fábricas e industrias alrededor del mundo. Ha sido implementado por centenares de proveedores en diversos y muy variados dispositivos con el objeto de transferir señales de entrada/salida tanto discretas como analógicas, así como también, para registrar datos entre los dispositivos de control. Sus ventajas y características se resumen en los siguientes puntos [15]: 24 • MODBUS es utilizado en múltiples aplicaciones maestro-esclavo para programar y monitorear dispositivos. • Para la comunicación entre dispositivos inteligentes, sensores e instrumentos. • Para monitorear dispositivos de campo a través de PCs y HMIs. • Es el protocolo ideal para aplicaciones RTU donde son necesarias las comunicaciones inalámbricas. • Por esta razón es utilizado para innumerables aplicaciones en subestaciones de petróleo y gas. Véase la Figura 2.3.4 [15] para apreciar las capas de comunicación en un enlace MODBUS con varias tecnologías de red. Las versiones disponibles del protocolo MODBUS se agrupan en: 9 MODBUS serial (EIA/TIA-232-E, EIA-422, EIA/TIA-485-A; fibra óptica, radio, etc.): versión del protocolo para aplicaciones tanto para cableado como para aplicaciones inalámbricas (MODBUS-RTU). 9 MODBUS PLUS (par trenzado y fibra óptica): versión del protocolo utilizado en redes de alta velocidad empleando la técnica del paso de testigo. 9 MODBUS Ethernet: versión del protocolo que opera sobre TCP/IP. En la Figura 2.3.5 [15] se podrá observar una arquitectura típica de MODBUS. Figura 2.3.4 – Pila de comunicación MODBUS. 25 Figura 2.3.5 – Ejemplo de arquitectura MODBUS. 2.3.6 HART. HART es uno de los protocolos más utilizados en el ámbito de los procesos industriales. Fue creado a finales de 1980 y se caracteriza por la aplicación del estándar Bell 202 para la superposición de señales digitales (información digital) en el rango de señales analógicas de medición de 4-20mA (información analógica); esta peculiaridad lo convirtió en un protocolo de facto. Las características de este protocolo son [16]: • Alimentación de los dispositivos vía línea de transmisión. • Permite conectar hasta un máximo de 15 dispositivos sobre un mismo bus (multidrop). • El protocolo emplea modulación FSK a 1200 baudios. Se obtienen hasta 2 ó más respuestas por segundo. • Comunicación entre dispositivos inteligentes en campo (transductor HART) y los sistemas de control (CP, PLC, etc.). • Envío y recepción de mensajes digitales de variables, parámetros, configuración de dispositivos, calibración y diagnóstico al mismo tiempo. • No se afecta la señal analógica de medición debido a que la modulación FSK es continua en fase. 26 Tanto en la Figura 2.3.6 [17] como en la Figura 2.3.7 [17] se presentan dos esquemas representativos de comunicación utilizando protocolo HART. Figura 2.3.6 – Método de modulación FSK de HART. Figura 2.3.7 – Superposición en comunicación HART. 2.4 TECNOLOGÍAS DE TRANSMISIÓN EN BUSES DE CAMPO. Esta área del control industrial comprende a aquellas tecnologías que permiten la interconexión entre los distintos dispositivos que se encuentran en una planta (transductores, actuadores, etc) y los equipos de control asociados. 2.4.1 RS485. Es una tecnología de transmisión simple y rentable; primordialmente, es utilizada para aplicaciones que requieren tasas de transmisión altas. El cable utilizado es par trenzado de cobre blindado, de los cuales solo un par se emplea para las comunicaciones. Las ventajas y características de esta tecnología son [18]: • Ningún conocimiento técnico es necesario para la instalación del cable. 27 • La estructura del bus permite añadir o retirar estaciones individuales, o poner en servicio el sistema entero paso a paso, sin afectar a las demás. • Expansiones sucesivas (dentro de los límites especificados) no tienen ningún efecto sobre las estaciones que ya estén en operación. • Varias tasas de transmisión pueden seleccionarse, entre 9600Kbits/s y 12Mbits/s. • Se requiere de una velocidad uniforme para todos los dispositivos conectados al bus cuando se pone en servicio el sistema. • Hasta 32 estaciones (maestras o esclavas) pueden conectarse en un solo segmento. • Para conectar más de 32 estaciones se amerita el uso de repetidores. • La longitud máxima permisible depende de la velocidad de transmisión. • En el mercado están disponibles diferentes tipos de cables (identificados de la letra A a la D) para diferentes aplicaciones que permiten conectar dispositivos entre sí o con elementos de red (acopladores, enlaces y repetidores). • En el caso particular de PROFIBUS, PI (PROFIBUS Internacional) recomienda el uso de cable tipo A. 2.4.2 RS485-IS. Esta tecnología de transmisión se deriva del estándar RS-485, ya mencionado, con la característica principal de que fue desarrollado para cubrir las necesidades en aplicaciones intrínsecamente seguras. Esta característica es propia de PROFIBUS-PA, por lo que existe una guía de su configuración según dicho estándar [18], donde se detallan los siguientes aspectos: • Los niveles de voltaje que deben ser asumidos por todas las estaciones para asegurar el seguro funcionamiento durante la interconexión. • Un circuito eléctrico permite una corriente máxima a un determinado nivel de voltaje. • Cuando se conectan fuentes activas, la suma de las corrientes de todas las estaciones no debe exceder el máximo de corriente permitido. • Todas las estaciones representan fuentes activas. • Hasta un máximo de 32 estaciones pueden ser conectadas al circuito del bus de seguridad intrínseca. 28 2.4.3 Fibra óptica. Esta tecnología de transmisión es utilizada para aplicaciones de bus de campo en lugares en los que existen restricciones debido a la tecnología de transmisión por cable de cobre, bien sea en ambientes con mucha interferencia electromagnética o cuando se deben cubrir largas distancias [18]. 2.4.4 Modelo FISCO. Este modelo de transmisión de bus de campo fue desarrollado a mediados de los años 90 por el trabajo conjunto de cuatro partes: PTB (Alemania), el Instituto Nacional de las Ciencias Naturales y de la Ingeniería (Alemania), la industria química, la Organización Internacional PROFIBUS y el fabricante de tecnología de automatización ABB Inc. como promotor [19]. Desde 2001 la Foundation Fieldbus también ha tomado parte en el desarrollo y soporte del Modelo FISCO. El modelo permite la instalación de redes PROFIBUS o FOUNDATION Fieldbus-H1 en ambientes potencialmente peligrosos o explosivos [18]. Las ventajas que se derivan del uso del modelo FISCO en áreas peligrosas comprende: • Reemplazo en caliente dentro de áreas peligrosas. • No se necesita la certificación de nuevos componentes, siempre y cuando exista la certificación previa de organismos acreditados como son: PTB y BVS (Alemania) o UL y FM (Estados Unidos de América). • Expansión simple de la utilidad de las aplicaciones en un solo segmento de red. • Máxima expansión de la cantidad de dispositivos conectados. • No se necesita realizar recálculos para el intercambio de dispositivos. • Bajo costo. En el Anexo A se muestra una tabla comparativa de los buses de campo tratados en este libro. 2.5 Vías de comunicación hardware-SCADA y hardware-DCS. Con esta denominación se pretende dar a conocer las interfaces más utilizadas a nivel de usuario o de programadores de sistemas, por medio de las cuales se establecen las comunicaciones entre los dispositivos físicos que ejercen el control (PLC o CP) y los sistemas que permiten la visualización de los procesos industriales. 29 2.5.1 DDE. DDE es el predecesor de OLE, Intercambio Dinámico de Datos, es un método para la movilizar datos dinámicamente entre aplicaciones cuyo API se basa en Win32. El protocolo DDE envía mensajes entre múltiples aplicaciones que comparten recursos (datos y memoria) para intercambiar información y comandos. En la actualidad ha sido desplazado por OLE, COM y Automatización OLE [20]. Las características más importantes de DDE son [21]: • Permite que una aplicación establezca una sesión con otra, envía comandos al servidor de aplicaciones y recibir las respuestas. • El proceso es asíncrono ya que el servidor debe estar disponible para procesar la petición del cliente. • Es directo al implementarlo, todo lo que puede hacer es transmitir datos. El puede controlar otra aplicación solo porque el recipiente puede interpretar la información como un comando. • Es incapaz de crear un objeto por sí mismo. La esencia de DDE es que el cliente se puede unir a un servidor que ya está activo. • Los programas que usan DDE pueden prescindir uno del otro o pueden apoyarse entre sí, pero no necesitan ningún soporte extra de DLL alguno. • El rol del servidor y del cliente es intercambiable para las aplicaciones que emplean DDE. • El cliente es quien inicia las transacciones. Las transacciones pueden consistir en pedir datos (request), pedir actualizaciones (advise, notify) entregar comandos (execute) y enviar datos no solicitados (poke). • Usar DDE para comunicar los componentes dentro de una misma aplicación es posible pero no trae beneficio alguno. • En una comunicación DDE es de vital importancia mantener el orden de los mensajes. • Tiene blindaje binario, es decir, ni el cliente ni el servidor pueden saber si la otra aplicación es de 16-bits ó de 32-bits. El servidor no puede conocer si el cliente está en el mismo computador o no. 30 Una comunicación DDE se establece enviando tres elementos desde el cliente al servidor de aplicaciones. Estos elementos son: el servicio, el tópico y el ítem. El conjunto del servicio y el tópico conforman el canal. El cliente, normalmente, dice a qué canal conectarse (servicio/tópico) y envía un mensaje por difusión (broadcast) a todos los posibles servidores, aquél que responda se conecta y se establece la comunicación entre la aplicación cliente y la aplicación servidor. En ocasiones, puede suceder que el cliente no especifique servicio/tópico, sino uno de ellos o ninguno, este tipo de conexión se le denomina “wildconnect”; en una conexión de este tipo el servidor decidirá si la acepta, para cuáles tópicos la acepta y qué límites le impone. Por cada canal se pueden tener muchas conversaciones y, generalmente, se establecen con el fin de enviar un solo tipo de dato o comando por cada canal para evitar confusiones [21]. Los primeros esfuerzos realizados por las compañías para emplear a DDE como elemento de enlace de las comunicaciones de sus aplicaciones no fueron muy fructíferas, esto debido a que DDE consume mucho ancho de banda en la red, más aun si existen muchos elementos (transmisores, transductores, etc.) a lo largo de la línea de producción o en el control de procesos propiamente dicho. 2.5.2 NetDDE. Es una mejora realizada a DDE por compañías aliadas de Microsoft conjuntamente con dicha empresa. Básicamente, consiste en emplear la API de NetBios para empaquetar las transacciones DDE y enviarlas sobre TCP/IP. Este método permite conexiones más rápidas que aquellas establecidas entre dos programas de una misma máquina, esto se debe a que el cliente y el servidor pueden procesar la información en paralelo. Cuando una comunicación es establecida entre el cliente y el servidor las transacciones son llevadas a cabo como si se estuviera en una misma máquina [21]. A diferencia de DDE puro, NetDDE permite una comunicación punto a punto sin afectar el rendimiento por ancho de banda, esto debido al empaquetamiento de los datos y a la naturaleza asíncrona de TCP/IP. Adicionalmente, el hecho de que se emplee el protocolo Internet, permite emplear la misma capa física utilizada en redes como Ethernet [21]. 31 2.5.3 OPC Foundation. Es un consorcio industrial que trabaja en cooperación con Microsoft y cuya función es desarrollar y mantener el estándar OPC, modelo de conectividad abierta con dispositivos y sistemas en el área de automatización industrial [22]. La especificación OPC, denominada en la actualidad especificación DAS, está basada en las siguientes tecnologías de Microsoft: OLE (ahora ActiveX), COM y DCOM. En tal sentido, OPC consiste en un conjunto de estándares de interfaces, propiedades y métodos que son empleados en el control de procesos y automatización industrial. Las tecnologías ActiveX/COM definen la manera en que los componentes individuales de software pueden interactuar y compartir datos. Respaldado por la tecnología NT de Microsoft, OPC provee una interfaz común para la comunicación con diversos dispositivos para el control de procesos sin importar que tipo de software de control o dispositivo esté involucrado en el proceso. Este estándar fue liberado, inicialmente, en agosto de 1996 y hasta hoy día se prosigue su desarrollo y soporte [22]. El éxito del estándar OPC se basa en la característica Plug-and-Play definida por Microsoft y otras compañías, por tal motivo, esta tecnología procura la definición de una interfaz común que permite, fácilmente, su aplicación y reutilización. El estándar OPC requiere que los suplidores de hardware provean la recolección y distribución de los datos. Esto se debe a que son quienes mejor conocen de la eficiencia y la mejor forma de sacarles el máximo provecho a sus equipos. En tal sentido, el hardware se convierte en un Servidor OPC el cual provee los datos a los Clientes OPC de manera consistente. Los componentes sobre los que se basa el estándar OPC o actual DAS son los siguientes: 2.5.3.1 COM. Provee el estándar de interfaces y de comunicaciones entre componentes. A través de COM, una aplicación puede utilizar las características de cualquier otra aplicación de objeto o sistema operativo, o permitir la actualización de componentes de software sin afectar la operación de toda la aplicación. COM puede ser utilizado por desarrolladores e integradores 32 de sistemas para crear soluciones particulares. Como estándar binario, COM, es genérico y es el corazón de la tecnología DCOM, ActiveX y OLE [22]. 2.5.3.2 OLE. OLE se utiliza para posibilitar la integración entre aplicaciones, permitiendo un alto grado de compatibilidad aún entre distintos tipos de información. Está basada en COM y permite utilizar objetos plug-and-play reutilizables que son interoperables entre varias aplicaciones. Además permite el desarrollo de software basado en componentes y reutilizable, en el cual los componentes pueden estar escritos en cualquier lenguaje y provistos por cualquier fabricante de software [12]. 2.5.3.3 Automatización OLE. La automatización OLE y las tecnologías subyacentes de COM fueron diseñadas por Microsoft para permitir que los componentes (escritos en C y C++) sean utilizados por un programa personalizado (escrito Visual Basic o en Delphi). Este modelo representa un éxito ya que satisface las necesidades de la industria de control de procesos al permitir a los desarrolladores de hardware escribir componentes de software en C y C++ para manejar el acceso a los datos de un dispositivo. A través de OPC, desarrolladores de aplicaciones pueden escribir código en cualquier lenguaje de programación para solicitar y utilizar los datos provenientes de la planta [22]. 2.5.3.4 DCOM. Extiende la utilidad de COM a las redes (objetos remotos). Es un protocolo altamente optimizado en donde los componentes remotos parecieran ser locales. DCOM fue liberado inicialmente en agosto de 1996 para Windows NT 4.0. Microsoft Java y VB Script soportan el desarrollo de DCOM y ActiveX. Otras compañías desarrollan versiones de DCOM y ActiveX para plataformas que no son de Microsoft [22]. 2.5.3.5 ActiveX. Es el término que denomina a un amplio rango de tecnologías comúnmente conocidas como Controles OLE, los cuales se basan en COM. Está basado en objetos en lugar de estar orientado a objetos. ActiveX es una plataforma integrada y abierta que permite, a los desarrolladores de software y a los desarrolladores Web, la creación de aplicaciones portátiles 33 y de contenido interactivo para el World Wide Web. Es abierta, multiplataforma y está soportada en Mac, Windows y sistemas Unix [22]. 2.5.4 ArchestrA (A2). Esta tecnología de DCS, desarrollada por Wonderware y Foxboro Company (ambas filiales de Invensys), está basada en plataforma Windows y tiene como finalidad la disminución de los costos de adquisición, mantenimiento y actualización de software así como la replicación de las aplicaciones de automatización [23]. La visión de ArchestrA consiste en proveer una arquitectura unificada y robusta como base del trabajo colaborativo en los sistemas de producción para asistir a las corporaciones industriales y/o plantas de cualquier clase y tipo. La característica de plataforma de desarrollo abierto otorga tanto a Invensys como a las compañías de terceros acumular y ampliar la base de conocimientos y de aplicaciones de esta tecnología, además de que permite extender la vida útil de una gran diversidad de equipos y sistemas pre-existentes (ver Figura 2.5.1) [23]. Figura 2.5.1 – Esquema representativo de la tecnología ArchestrA. 34 Al igual que otras organizaciones mencionadas, como OPC Foundation, ArchestrA se persigue el objetivo de tratar de establecer un estándar que, en el caso particular de esta tecnología, tiene como finalidad abarcar el mercado de los DCS de rango mediano. En el caso de TRIPOLIVEN, objeto de esta pasantía, era necesario tener este cúmulo de conocimientos previos para atacar el problema planteado, ya que debido a la complejidad de la planta y el estatus de rémora de los equipos (hardware), el sistema operativo (software) y el DCS (software), todos en estado de obsolescencia y falta de soporte, obligaron a la compañía, TRIPOLIVEN, a realizar un cambio y a la actualización de sus sistemas. Con este propósito Invensys Venezuela convenció a esta empresa para que realizasen una migración del sistema actual a una solución que brindara los beneficios que están enmarcados dentro en las características de ArchestrA. Este cambio implicaba conocer del equipo de control y servidor OPC de la compañía Eurotherm, socio de Invensys, así como también de la tecnología a utilizar en forma definitiva, Wonderware A2 y Foxboro A2. Con todo el conocimiento a mano, respecto de las distintas tecnologías de control industrial y de la problemática del proyecto, se establecieron las pautas que dieran la solución más adecuada y expedita, amén de un buen servicio, al cliente en cuestión. Para ello, se cumplieron con una serie de etapas que se desglosarán en los siguientes capítulos. 35 CAPÍTULO III PLANTEAMIENTO Y ESTUDIO DEL PROBLEMA. A continuación se presentan los detalles relacionados con el desarrollo del proyecto. Los pormenores del mismo son planteados desde el punto de vista de sus antecedentes, las condiciones actuales y la delimitación o alcance del trabajo a realizar. 3.1 Antecedentes. TRIPOLIVEN, C. A., es una empresa mixta constituida por participación accionaria distribuida en partes iguales entre Petroquímica de Venezuela, S. A., Valquímica, C. A. y FMC Foret en 33,33% cada una. Fue constituida en 1972 e inició operaciones el 1° de Junio de 1977 con el objetivo de ejercer el comercio en todas las formas y desarrollar la producción de tripolifosfato de sodio, ácido fosfórico y de todos los componentes químicos relacionados. La compañía está enclavada en la región Carabobeña de Morón por lo que forma parte del complejo petroquímico de dicha zona [24]. Los principales procesos de producción de TRIPOLIVEN están divididos, fundamentalmente, en tres (3) etapas. Cada una de estas etapas se interrelacionan entre sí, directa o indirectamente, para una maximización en la generación de los productos de esta compañía. Obsérvese un diagrama demostrativo de los procesos de TRIPOLIVEN [24]. Figura 3.1.1 – Diagrama de los procesos de producción en TRIPOLIVEN. 36 La planta de ácido fosfórico (P2O5) opera conjuntamente con otras instalaciones de TRIPOLIVEN. La principal función de dicha planta es la de generar ácido fosfórico cuya concentración del fosfato P2O5 comprenda los valores nominales de 28%, 52% y 54% [24]. Los principales productos que se derivan de esta planta comprenden los siguientes rubros: • Fabricación de polifosfatos de uso industrial. • Fabricación de fosfatos para fertilizantes. • Fosfato para uso en alimentos de animales. • Formulación de revestimientos protectores de metales férreos. • Limpieza y decapado de los metales. • Modificador de opacidad en la fabricación de vidrio. Las propiedades, según la concentración de P2O5, se pueden apreciar en la siguiente tabla [24]: Tabla 3.1.1 – Propiedades de los derivados de la planta P2O5. TIPO P2O5 (%) H3PO4 (%) Fósforo – P (%) Flúor – F (%) Relación P/F Sulfato – SO4 (%) Sólidos suspendidos – Totales (%) Densidad – g/ml Ácido Fosfórico 28% - P2O5 Ácido Fosfórico 52% - P2O5 Ácido Fosfórico 54% - P2O5 Típicos Especificaciones Típicos Especificaciones Típicos Especificaciones 28,0 38,6 12,2 0,12 100 0,85 0,2 27,5 mín. 38,0 mín. 12,0 mín. 0,20 máx. 60 mín. 1,0 máx. 0,5 máx. 53,0 73,2 23,1 0,18 130 2,5 0,7 52,0 mín. 71,8 mín. 22,7 mín. 0,22 máx. 100 mín. 3,0 máx. 2,0 máx. 54,5 75,2 23,8 0,12 200 0,65 0,4 54,0 mín. 74,5 mín. 23,6 mín. 0,17 máx. 138 mín. 0,8 máx. 2,0 máx. 1,28 1,27 máx. 1,59 1,57 mín. 1,61 1,60 mín. 3.2 Condiciones de la planta P2O5. En la actualidad el conjunto de plantas de TRIPOLIVEN están en un proceso de actualización y migración de sus sistemas de control, entre ellas, la planta P2O5 es la que dará inicio a este proceso de modernización. El sistema de automatización y supervisión que venía utilizando el cliente data de los inicios de los años noventa, por lo que lleva más de una década en uso. Este DCS es desarrollado por la compañía ICONICS, se le conoce como GENESIS y al igual que la 37 tecnología A2, opera sobre plataforma Windows. Este DCS ha venido funcionando con Windows for Workgroups en las estaciones de operación, en tal sentido, el cliente desea actualizar toda su plataforma sin perder conectividad con los dispostivos (transmisores o transductores, actuadores, etc.) además de aprovechar todas las bondades que ArchestrA puede brindarle. 3.3 Problemática planteada. El propósito de Invensys Latin America Corporation en la actualización de la planta P2O5 de la compañía TRIPOLIVEN supone un reto para la corporación a nivel nacional ya que se empleará una combinación de hardware y software no experimentada por el personal de Invensys en otros desarrollos dentro del país. Ante esta situación se hace necesario el entrenamiento en la tecnología A2, desde la concepción de Wonderware, así como también la disponibilidad y dedicación de un ingeniero para esta tarea. Para cumplir con todos los requisitos del proyecto se deberá verificar que tanto el hardware como el software armonicen, es decir, se cumplan con los requerimientos tanto del sistema como del cliente. Así mismo, se necesitará una evaluación de la topología de la red propuesta para ofrecer las alternativas más adecuadas y que permitan la escalabilidad de la misma sin que ello afecte el desarrollo a realizarse en la actualidad. Finalmente se deberá realizar toda la configuración del sistema y generación de la documentación que incluyen varias fases: • Dimensionamiento del consumo de potencia y del desempeño de los equipos de control. • Asignaciones de TAG y de I/O obtenidos del levantamiento en sitio. • Adaptación y configuración de las estrategias de control. • Adaptación, desarrollo y animación de las pantallas de operación. Al mismo tiempo, dependiendo de las condiciones, se deberá proveer de una solución o repuesta confiable a las contingencias que pudieran surgir en el camino, debido a la escasa experiencia con la tecnología que se deberá implementar. 3.4 Definición del proyecto. La instalación de un sistema de automatización para el control de la fábrica de ácido fosfórico de la empresa TRIPOLIVEN, planta P2O5, consiste en realizar la migración del 38 sistema GENESIS al nuevo DCS basado en la tecnología A2 de Invensys. Los criterios de implementación involucran una serie de elementos que se deben considerar entre los que se encuentran factores humanos, técnicos y administrativos. En tal sentido, será necesario analizar toda la información disponible y entregada por TRIPOLIVEN como resultado del levantamiento de información: P&ID, diagramas de lazo, narrativa de control y lista de TAGs. 3.5 Alcance del proyecto. Para cumplir con las pautas establecidas en la relación cliente – proveedor (TRIPOLIVEN – Invensys), será necesario adquirir todos los conocimientos que sean pertinentes para tales fines los cuales se desglosan de la siguiente manera: • Documentación sobre los equipos de control y recolección de información sobre la configuración tanto de hardware como de software de los computadores a emplearse en la implementación. • Documentación e inducción sobre la plataforma de software Foxboro A2 empleada en la configuración y programación de las estrategias de control a ser transferidas al hardware (T940, módulos 2500). • Entrenamiento sobre la plataforma ArchestrA de Wonderware, IAS e Intouch. • Análisis de la propuesta de red del DCS de la planta P2O5 y reconocimiento de cada uno de sus elementos que la integran. • Inducción sobre el estilo y contenido de la documentación que se deberá entregar al cliente. • Distribución y asignación de TAG considerando las necesidades del cliente. • Configuración de las estrategias de control que se descargarán en el CP (firmware). • Distribución y configuración del ambiente general del DCS en función de los requerimientos del cliente (software). • Configuración y adaptación del HMI que será empleado por los operadores de la planta. • El proyecto solo abarca la planta de P2O5, por tanto, es responsabilidad del cliente la configuración y adecuación del resto de las plantas de su propiedad. 39 CAPÍTULO IV DESARROLLO E IMPLEMENTACIÓN. A continuación se expondrán todas y cada uno de las fases del proyecto que se ejecutaron, en función una planificación de actividades, y que permitieron llevar a cabo la migración de un sistema de control en estado de obsolescencia en la planta P2O5 de TRIPOLIVEN. 4.1 Planificación del cronograma de actividades. La planificación original del proyecto en la planta P2O5 comprendía varios aspectos los cuales se pueden apreciar en la Tabla 4.1.1: Tabla 4.1.1 – Cronograma y fases del proyecto. Fase 1. Adaptación e investigación documental 2. Programación y previsión de actividades. 3. Inicio de programación y desarrollo. 4. Pruebas iniciales para el FAT. 5. Pruebas en presencia del cliente. 6. Evaluación preliminar del sistema. 7. Preparación para instalación en planta. 8. Inicio de trabajo de campo y documentación del SAT. 9. Pruebas en fábrica. Descripción Documentación básica. Curso de adiestramiento en el sistema: FOXBORO A2 y familiarización con los equipos disponibles. Generación del plan de acción del proyecto. Estimación de costos. Recopilación de material del cliente y desarrollo de la Ingeniería asociada al proyecto. Preparación del FAT, detección y corrección de fallas. Inicio y culminación de la documentación del FAT. Pruebas con el cliente de la ingeniería desarrollada (FAT). Corrección de fallas detectadas. Pruebas de ingeniería. Aceptación del FAT. Corrección de fallas. Traslado de equipos. Implementación in situ (Trabajo de Campo). Configuración de equipos. Inicio de la documentación del SAT. Culminación del SAT. Pruebas de la ingeniería desarrollada en sitio y en presencia del cliente. Tiempo Estimado (semanas) 3 1 4 3 1 2 1 2 2 El cronograma establecido durante la reunión con el Ingeniero gerente del proyecto para TRIPOLIVEN (Invensys), según los lineamientos de la corporación, tenían previsto el inicio de las pruebas FAT en el transcurso del mes de julio y el inicio de las pruebas SAT durante el 40 mes de agosto. En el cronograma de actividades se contempla la elaboración de los archivos correspondientes al FDS que incluyen toda la documentación de la ingeniería desarrollada o configuración PRE-FAT para que el cliente la examine. 4.2 Fase de documentación y programación del entrenamiento. 4.2.1 Documentación. En esta primera etapa se recibieron los archivos de la propuesta del personal de ventas de Invensys al cliente, TRIPOLIVEN. Dichos documentos comprendían elementos importantes como son: propuesta de la topología de la red de control, componentes de software por computador, configuración topológica de la unidad de control o CP incluyendo los módulos de comunicación, plataforma computacional (sin ser específica), sistema operativo de las estaciones que se emplearán en la implementación y software del DCS proveído por Wonderware. Con toda la información suministrada se hizo un cotejo inicial del material vendido a TRIPOLIVEN.. En esta ronda de reconocimiento de los diferentes componentes se destaca el hecho de que la solución que se proveyó al cliente procura minimizar los costos de adquisición y mantenimiento de todo el DCS en la planta P2O5 y, consecuentemente, en el resto de las plantas asociadas al proceso productivo de TRIPOLIVEN. Básicamente, la alternativa propuesta por Invensys se concentra en el rango medio entre los DCS de alto y de bajo rango de la corporación; esto puede apreciarse en la Figura 4.2.1: Figura 4.2.1 – Rango de los DCS de Invensys. 41 La interpretación de la Figura 4.2.1 se explica en el sentido de las características que el DCS de tecnología A2 ofrece, esto es: una inversión equivalente a un poderoso sistema distribuido al precio de un PLC de rango medio, disminución de costos en cableado e interconexión (punto a punto), adquisición de licencias ajustadas a las necesidades del cliente, la promesa de un tiempo de ingeniería mínimo en comparación con sistemas mayor rango para su configuración, expansibilidad del sistema hasta un máximo de 15.000 puntos de I/O sin necesidad de un cambio estructural de las herramientas preexistentes, arquitectura abierta de Wonderware (conexión con equipos de terceros), entre otras ventajas. El equipamiento de un sistema Foxboro A2, consiste en los siguientes elementos: Software: • Intouch. • AlarmSuitePlus. • Plant Solutions. Estos tres grandes componentes (Intouch, AlarmSuitPlus y Plant Solutions) se subdividen en otros con funciones más específicas. Dichos elementos pueden apreciarse en la Tabla 4.2.1. Hardware: este componente en Foxboro A2 está constituido, básicamente, por productos suministrados por una filial de Invensys, Eurotherm. Estos equipos pueden identificarse en la Tabla 4.2.3. Tabla 4.2.1 – Herramientas contenidas en Foxboro A2. Ambiente de desarrollo (Servidor) LinTools iTools Project Developer Window Maker Window Viewer I/O License for Wonderware drivers I/O License for Lin instruments Ambiente de ejecución (Servidor) LinTools (solo configuración) iTools (solo configuración) X X Window Viewer X X 42 Tabla 4.2.3 – Componentes de hardware en Foxboro A2. Capa de monitoreo (Supervisión de procesos) Capa de planta (Control de procesos) Capa de control Capa de entrada/salida Típicamente estaciones de operación (Rama gerencial de la empresa). Servidores y estaciones de operación. • • • • T940 → Procesador-supervisor T800 → Supervisor visual. T640 → Micro DCS. Módulos 2500. o Entrada análoga universal (TC, RTD, mA, mV, V, Pot, PYRO) de 2 canales. o Entrada análoga de alto nivel de 3 canales. o Entrada análoga universal (TC, mA, mV, PYRO) de 4 canales. o Salida analógica de 2 canales (mA, V). o Entrada digital de 4 canales. o Entrada de CA de 6 canales. o Entrada digital de 8 canales. o Salida lógica de 4 canales. o Entrada de relay (3NA, 1NC / 2A-240V) de cuatro canales. 4.2.2 Entrenamiento. Para la fase de entrenamiento en la tecnología Foxoboro A2 se partió de la única experiencia previa, implementación en los pozos petroleros 3X y 6X de La Ceiba, Edo. Zulia, así como de un proyecto en desarrollo para la compañía INDELMA (Planta de Glucosa Alfonzo Rivas) para lo cual se inició la configuración mientras se esperaba la llegada de la información proveniente del levantamiento en la planta P2O5 de TRIPOLIVEN. Las fases del entrenamiento comprendían los siguientes aspectos: • Identificación, instalación y configuración básica de los distintos componentes del software para el DCS (Foxboro A2). • Documentación sobre el hardware de control de Eurotherm: T940, T640, T800, Módulos 2500. Esto incluye el tipo de bus de campo utilizado entre los distintos equipos. 43 • Filosofía de la tecnología Foxboro A2 y el modo de interacción con las herramientas básicas que contiene el paquete. Esto comprende los siguientes aspectos de ejecución y configuración: o Configuración del Servidor OPC. o Configuración de la red. o Configuración básica de los elementos de la red. o Modelo de planta y asignación de I/O. o Configuración de I/O. o Configuración de las estrategias de control. o Configuración de las alarmas. o Configuración y funcionamiento del HMI. Todos y cada uno de los aspectos mencionados fueron cubiertos con una inducción preliminar y se reforzaron a la par del proyecto de actualización de la planta de glucosa de la compañía INDELMA, para lo cual se procesó la información proveniente del levantamiento de dicha planta. A inicios del mes de mayo de 2005 se realizó una visita guiada, en compañía de los ingenieros de Invensys, a la Planta de Glucosa de INDELMA en la que se realizó un reconocimiento e inspección general de toda el área. Se recibió la documentación referente al proceso de la planta los cuales fueron: lista de TAG de las diferentes variables y señales del proceso, esquematización de las estrategias de control, rangos de operación de los instrumentos y niveles de alarma. Para realiza la configuración inicial del sistema se procedió con el traslado de un T940 y una PC a las oficinas de Invensys a Caracas, ambos dispositivos involucrados en el proceso de implementación del DCS, con el fin de trabajar sobre el hardware del cliente durante el PRE-FAT. Siguiendo los pasos de la documentación y teniendo a disposición las herramientas del cliente se realizaron las pruebas de comunicación con el CP (T940F) vía Hyperterminal, red ELIN (Ethernet) y con el módulo ALIN PCM20H (adaptador Arcnet) ↔ MAU20H (unidad de acceso a medios). Paralelamente, se hizo la configuración básica de la red de control de la planta siguiendo todos y cada uno de los pasos descritos en la sección 3.2 hasta la fase inicial 44 del punto correspondiente a las estrategias de control, en la que se recibió una inducción respecto a la interfaz y modo de operación de la herramienta correspondiente (LintTools). Igualmente, se recibió una inducción sobre el modo de trabajo de las pantallas de operación y la relación de la herramienta gráfica (Intouch) con la capa de software que le sirve de los datos (Servidor OPC) provenientes de los módulos I/O (módulos 2500). Con base a los datos recopilados de la planta de glucosa, se procedió a la realización de los documentos tomando como base los formatos y filosofía de trabajo existente en Invensys. Esta información que incluye: detalles particulares de Foxboro A2 y esquemas de conexión, entradas/salidas, consumo de potencia, arquitectura y configuración del sistema, diagramas de lazos, configuración de control, distribución de señales de entrada/salida (nestloading), estimación de carga. 4.3 Fase de análisis de la Planta P2O5. En esta etapa se presentan un conjunto de actividades que permitieron conocer y evaluar, con mayor profundidad, los distintos aspectos relacionados con la red industrial de TRIPOLIVEN, su arquitectura y otros elementos relacionados con la configuración de dicha red. 4.3.1 Análisis topológico de la red de TRIPOLIVEN. Luego de haber tomado partido en las fases iniciales del PRE-FAT de INDELMA y finalizada las responsabilidades en dicho proyecto (entrenamiento completado), se procedió a realizar la revisión del modelo de planta de P2O5 en función de los esquemas de red planteados a TRIPOLIVEN. En este sentido se examinó el esquema alternativo que elaboró el cliente (ver Anexo B) en el cual se detectó la mezcla de la red de control a través el servidor INSQL, que mantendrá el histórico de todas las plantas, con una parte de la red administrativa y/o de supervisión de los procesos de producción. El segmento de red en cuestión se muestra a en la Figura 4.3.1: 45 Figura 4.3.1 – Combinación de propósitos de redes dispares. En la topología propuesta inicialmente por Invensys se planteaba la conexión de la red de “Visualización y Análisis” a través del servidor Web (Suite Voyager) de manera directa, por medio de un switch, ya que las estaciones de trabajo de los usuarios de la mencionada red solo tendrán acceso a la información de las plantas a través de ese servidor sin ninguna posibilidad de poder interferir en las actividades normales del DCS aguas abajo (ver Figura 4.3.2). Figura 4.3.2 – Esquema planteado por Invensys en torno al Web Server. Debido a las inconsistencias en este aspecto, se debía argumentar al cliente sobre las posibilidades de ocurrencia de fallas en el servidor INSQL, para ello se acudió a un esquema de red más sencillo de entender para el personal de TRIPOLIVEN, considerando además un aspecto adicional, la inclusión de tarjetas de red adicionales para la redundancia en toda la red de control (ver Figura 4.3.3). 46 Figura 4.3.3 – Esquema sugerido al cliente. Inicialmente, el vendedor del sistema DCS de Invensys le había planteado al cliente, vía correo-e, la factibilidad de poder emplear tarjetas de red duales. Esta posición estaba fundamentada en la experiencia vivida por una compañía francesa, SIAAP, dedicada a la limpieza de las aguas servidas, la cual empleó tarjetas de red Intel® PRO/1000 MT Dual Port Server Adapter (PWLA8492MT) en sus servidores con el objeto lograr redundancia física dentro del ambiente Wonderware A2. En contraposición a esta idea se planteó una alternativa diferente, antes de que se sostuviera una reunión formal en TRIPOLIVEN. La solución consistía en el empleo de tarjetas de redes simples, adicionales a las existentes según la configuración del hardware adquirido (estaciones y servidores), y el manejo de números de red distintos para la redundancia a través de routers o switches capa 3. La alternativa se basó en los siguientes hechos: • Cuando una estación de trabajo es equipada con dos tarjetas de red, y estas son conectadas a una misma red (mismo número de red), el servidor responsable de dar respuesta a las requisiciones de este equipo se verá saturado con las mismas. En este sentido, el servidor dará prioridad a una sola tarjeta de red mientras que la otra realizará solicitudes de manera intermitente y sin detenerse, hasta que alguna de las tarjetas de red sea desconectada. 47 • Para evitar la saturación del servidor por las constantes requisiciones de una segunda NIC conectada a la red, es imperativo el empleo de routers o de switches capa 3, esta es la mejor opción a tomar para poder distribuir el tráfico, balancear cargas y evitar consecuencias de disminución de ancho de banda disponible del servidor o una merma en la capacidad de dar respuesta. • La adquisición del equipamiento (routers y/o switches capa 3) de pocos puertos tienen un costo, en promedio, menor al de las tarjetas de red duales. A pesar de lo razonable del planteamiento, la solución fue descartada como opción viable debido a los siguientes aspectos: • No existe la disponibilidad del equipamiento necesario, en Invensys, para la realización de estas pruebas. • No existe un espacio libre destinado a la realización de pruebas (laboratorio). • Invensys no deseaba arriesgarse a experimentar debido al intenso ritmo de trabajo y por las complicaciones que pudieran surgir atendiendo las peticiones del cliente. • La posibilidad de retrasarse, innecesariamente, en el cronograma entregado a TRIPOLIVEN. Para la toma de una decisión final sobre esta posibilidad se consideró la experiencia de Wonderware de Venezuela con base en los resultados que han obtenido, además, ésta no es una opción que haya sido probada con anterioridad, ni por la empresa ni por los clientes de ella. Bajo esta condición la solución planteada no tiene cabida ya que el cliente final, TRIPOLIVEN, requiere de una solución efectiva, además, Invensys no estaba preparada para asumir esa responsabilidad. Aunque se considera que un servidor, cualquiera que sea su rango, puede estar en capacidad de manejar múltiples requisiciones de datos en modo recurrente así como la ejecución de múltiples tareas, también es cierto que dicho servidor pude verse rebasado en términos de sus capacidades de cómputo o peor aún, verse sometido a ataques de cualquier índole (virus o hackers). En tal sentido, en el caso de TRIPOLIVEN, resulta más confiable la segmentación de la red con el fin de independizar las requisiciones dirigidas al servidor Web (red de visualización y análisis) de aquellas que dependen directamente del servidor INSQL (red de control). Esta decisión añade un valor agregado que consiste en la no intromisión de 48 ningún otro equipo a la red de control de una manera directa a través de un computador puente. Esto permitiría canalizar los datos a través de un servidor intermediario entre la red de control de las plantas y los usuarios de las estaciones de visualización y supervisión. 4.3.2 Reunión en la planta de TRIPOLIVEN. Previa visita a la planta, se realizó un análisis detallado del conexionado de fibra óptica para presentárselo al cliente como información adicional y así complementar la información de las capacidades de redundancia física de la red. En la Figura 4.3.4 se presenta un diagrama de grafo de la distribución de de red según el esquema entregado (ver Anexo C) y que fuera facilitado al cliente para su evaluación y contraste con la información que este poseía, esto con el fin de que se tomen las correcciones respecto al aislamiento innecesario de las redes de control. Figura 4.3.4 – Análisis de grafo de la red (fibra óptica) propuesta por TRIPOLIVEN. Adicionalmente, se realizó un cuestionario en función de las necesidades del diseñador gráfico de Invensys. Esto con la finalidad de aprovechar la experiencia de esta persona y conocer así conocer el tipo y clasificación de la información que suele manejarse en el área de HMI como lo son: 49 • Formato, tipos y localización de las mediciones en pantalla. • Estilo y localización de botones de navegación. • Tipos de pantallas superpuestas (arranque de bombas y motores, control de válvulas, mediciones, tendencias, etc.). Durante la reunión llevada a cabo en sitio se produjeron los siguientes eventos: • Entrega del análisis de la topología de la red en función del esquema realizado por TRIPOLIVEN y presentación de posibles inconvenientes respecto a la configuración de los computadores y de la red en sí misma tal y como estaba planteada por ellos. • Visita a los sectores claves en la migración de la planta de ácido fosfórico así como adquisición de la información con base en las pantallas entregadas a Invensys en formato electrónico. • Entrega de pantallas desarrolladas en Caracas en función de las existentes y que fueran entregadas como guía por TRIPOLIVEN. • Establecimiento de prioridades en concordancia con los deseos del cliente y considerando los problemas identificados y previstos a futuro durante el proceso de implementación. • TRIPOLIVEN informó de la necesidad de separar los Gabinetes (Planta P2O5) de la siguiente manera: un gabinete para CP, comunicación, I/O analógicos y un gabinete para I/O digitales. • Compromiso por parte de la contratista IEE para la entrega de la documentación referente al levantamiento de I/O y TAGs vía correo-e. • Reenvío de esquemas de red para ser examinados en Invensys con el fin de definir una topología definitiva con prontitud y la arquitectura del sistema por completo. • Se a informó a TRIPOLIVEN que las tarjetas de red para redundancia en las computadoras del sistema de control no se habían pedido debido a que se tenían dudas sobre el correcto funcionamiento de las tarjetas duales en esta aplicación. Invensys se comprometió a realizar pruebas para asegurar el correcto funcionamiento de la aplicación. 50 • Elaboración de borrador de minuta de reunión en presencia de todos los involucrados durante la visita: TRIPOLIVEN, la subcontratista IEE e Invensys. 4.4 Configuración inicial de proyecto en Foxboro A2. Luego de la recepción de la documentación se procedió a la generación del proyecto según los pasos ya descritos en la sección 4.2.2, los mismos que se siguieron durante la fase de entrenamiento con el proyecto de INDELMA. En la fase final del proceso, y para la configuración de I/O, se realizó una revisión exhaustiva de todos los TAGs provenientes del levantamiento como paso previo a la generación de los TAGs dentro del Plant Model del Foxboro A2. Luego de esto se procedió a la carga de la base de datos y, finalmente, la asignación de los TAGs por tipo de señal atendiendo a la petición de TRIPOLIVEN de dividir las señales entre analógicas y digitales por separado. En la Figura 4.4.1 se puede apreciar el proyecto generado en Foxboro A2. Figura 4.4.1 – Proyecto generado en Foxboro A2. 51 Finalizada la asignación tanto en el Plant Model (ver Anexo D) como en I/O Allocation (ver Anexo E) se inspeccionó y depuró aquellos TAGs que no se ajustaban a los estándares del sistema, para lo cual se devolvió la documentación electrónica con los cambios realizados (ordenamiento vertical creciente y ajuste de nombres). Luego de la configuración y asignación de señales I/O en el sistema (Foxboro A2) se procedió a la realización de la documentación y generación del documento, Nestloading, que define la asignación de los TAG por chasis y módulos 2500; para ello se contó con la existencia de un modelo de documento el cual fue modificado y ajustado a los requerimientos del proyecto de TRIPOLIVEN. 4.5 Análisis y aporte definitivo de una propuesta de configuración de red en TRIPOLIVEN. Con base a la información recabada tanto en la reunión establecida con el cliente como con la obtenida vía electrónica, se procedió a evaluar y puntualizar lo que resultaba más conveniente en esta fase del proceso de implementación: • Independencia y redundancia física de la red, es decir, dos Backbones de fibra óptica en lugar de uno solo; ambos cableados por rutas físicas diferentes. • Redundancia de tarjetas de red en las conexiones a los equipos de control (NICs duales) como lo deseaba el cliente. • Asilamiento e independencia de la red de control y del servidor INSQL respecto de los equipos preexistentes a través del servidor Web para evitar futuras e innecesarias sobrecargas de requisiciones de dichos computadores clientes. • Envío de correo-e tomando en cuenta los dibujos anteriores y petición de la esquematización adecuada de la red propuesta por TRIPOLIVEN en la que se considere tanto los computadores como la distribución de los equipos de comunicación (Switchs). Para complementar esta propuesta se realizó la búsqueda de los detalles de la información de la compra de los equipos de computación (DELL) para cotejar el tipo de tarjeta proveniente en dicha compra por equipo así como también de los respectivos sistemas operativos para contabilizar el número adecuado de NICs duales necesarias en el proyecto. Así mismo, se programó una reunión para la valoración definitiva de la red propuesta por TRIPOLIVEN con 52 base en las potencialidades del IAS (Wonderware), la cual dio como resultado la consideración de los siguientes aspectos: • Servidor Web: No puede utilizarse como repositorio de la galaxia y la versión de sistema operativo que vino con el equipo en el que residiría es incompatible. • Estaciones de operación: redundancia de objetos en P2O5, TPF y Servicios. La planta de Urea se quedará sin redundancia, excepto si se adquiere otra máquina o al mover el servidor INSQL a la localidad de dicha planta. • Realización de FAT: traer al menos tres (3) estaciones de trabajo y la totalidad de los servidores (3) para su configuración en Caracas. • Software necesario para el FAT: IAS, Suite Voyager, INSQL y el relativo a las estaciones. 4.6 Ejecución del proyecto. En esta etapa del proyecto se cumplieron cuatro objetivos fundamentales, los cuales fueron el pilar fundamental para llevar a cabo la totalidad del cronograma. Estos objetivos comprendían los siguientes puntos: 4.6.1 Procura de tarjetas de red duales y sistema operativo compatible. Debido a problemas presentados durante el proceso de venta y procura inicial, fue necesario llevar a cabo ciertos procedimientos administrativos con el fin de satisfacer las necesidades del cliente, TRIPOLIVEN, y así brindar soluciones que permitieran optimizar tiempo y recursos financieros tanto a Invensys como a TRIPOLIVEN. Estos procedimientos fueron: 4.6.1.1 Proceso administrativo de tarjetas de red duales. Se solicitaron a tres compañías distribuidoras de productos de Intel en los Estados Unidos una cotización de un total de nueve (9) tarjetas de red duales (PWLA8492MT). Como se explicó, estas tarjetas son necesarias para llevar a cabo el proyecto y satisfacer las necesidades de redundancia física en la red de control del cliente. La selección de tres proveedores foráneos permitía tener diferentes opciones al momento de la escogencia de alguno de ellos. A pesar de varios intentos solo un proveedor respondió a la solicitud y se hizo del conocimiento al gerente del proyecto de esta situación. Se hizo entrega a los gerentes en Invensys de la opción de compra y se procesó la transacción a través de bancos extranjeros (E.E.U.U.). 53 Lamentablemente, la respuesta por parte de las compañías extranjeras, en general, fue muy negativa, llegando al punto de devolverse el dinero por concepto de transferencia bancaria en territorio de norteamericano; este dinero estaba destinado a la adquisición de las tarjetas de red. En vista de esta situación se buscaron otras opciones en territorio nacional por lo cual se tuvieron que realizar nuevas solicitudes de las tarjetas de red. En el transcurso del tiempo se obtuvo una respuesta favorable de cotización en el país, sin embargo, el costo duplicaba el monto original a cambio oficial. En tal sentido se intentó de nuevo con el proveedor por excelencia de Invensys Venezuela, DELL (E.E.U.U.), obteniéndose una respuesta y precios favorables para la compañía con lo cual se logró un ahorro, que en comparación con la oferta nacional, representaba la mitad del monto solicitado. Entre las dos ofertas válidas, la nacional y la internacional, se optó por adquirir el material fuera del país, por lo cual se realizaron los procesos administrativos necesarios dentro de Invensys. Durante el procedimiento se logró un mejor flujo de información sobre los procesos administrativos de la compañía partiendo de las solicitudes de cotización y finalizando con el proceso de adquisición de material. 4.6.1.2 Proceso administrativo para la adquisición de sistema operativo compatible con Suite Voyager. Debido a que en las reuniones sostenidas con Wonderware Venezuela surgió la disyuntiva de la incompatibilidad del sistema de operación de uno de los servidores con el paquete Suite Voyager, de Wonderware, el cual está incluido en la oferta original y con el objetivo de dar una solución definitiva con los problemas heredados en la oferta de Invensys al cliente final, TRIPOLIVEN, se procedió a buscar el apoyo de la representación de la casa matriz fabricante del sistema de operación, Microsoft, en Venezuela, así como también la solicitud de información a la compañía a la que se le compró la plataforma de computación, DELL (E.E.U.U.). Todo esto con la finalidad de abarcar dos opciones distintas para poder solventar este obstáculo de manera efectiva y eficiente sin acarrear costos elevados a Invensys. Como resultado de las gestiones, lamentablemente para Invensys, DELL no podía hacer un cambio del sistema de operación sin antes devolver el equipo completo a Norteamérica, en tal sentido, se optó por seguir el consejo del fabricante del sistema de operación, Microsoft, quien 54 notificó la necesidad de adquirir una licencia especial (OLP) de la última versión del sistema servidor de dicha empresa para poder utilizar un sistema más antiguo (downgrade). Igualmente, se procuró tener varias opciones de ofertas a nivel nacional, dado el hecho de que no se podía importar desde otro país por políticas del fabricante. Se solicitaron cotizaciones a dos proveedores de Microsoft en Venezuela con lo cual se procedió, nuevamente, a realizar las gestiones administrativas internas para la adquisición del sistema de operación que se necesitaba (Windows 2003 Server Standard Edition). Este procedimiento, exceptuando el caso de las tarjetas de red, se realizó sin conocimiento alguno por parte del cliente final, TRIPOLIVEN, quién no fue informado de los errores internos que se cometieron en cuanto a este aspecto con el fin de no despertar molestias adicionales en el proceso de implementación y transferencia del sistema en la planta P2O5. Además, con esto se pretendía que el cambio de las tecnologías del control de la planta fuera lo más transparente posible, a efectos de la imagen de Invensys como proveedor de soluciones de automatización en el país. 4.6.2 Programación de los bloques de control. Para poder realizar la programación del control, es necesario el empleo de Foxboro A2, el cual contiene la herramienta denominada LinTools (ver Anexos E y F), de Eurotherm fabricante del CP, así como también el resto del entorno de programación que asocia la base de datos de los TAGs y de I/O del nuevo DCS de la planta. Esta herramienta contiene varias opciones de programación, entre los cuales se destaca la programación secuencial, de bloques funcionales y recetas (Batch). En el caso de P2O5, y teniendo a mano la narrativa de control, diagrama de lazos y el diagrama del proceso con todas las conexiones e identificaciones existentes (P&ID), se procedió a la realización de la programación de los dos tipos de señales, es decir, tanto analógicas como digitales. 4.6.2.1 Programación analógica. Para la realización de la programación de los dispositivos analógicos se procedió a emplear los diagramas de lazo y la narrativa de control analógica, para abarcar toda la información posible relacionada con todos y cada uno de los TAGs asociados a los dispositivos electromecánicos, transductores y señalización interna del DCS. 55 En esta etapa se realizó la traducción del control continuo (bloque funcional) de todos y cada uno de los lazos de control existentes. También, fue necesario realizar el cruce de información de los diagramas de lazo, P&ID y narrativa de control de la planta de ácido fosfórico. Este procedimiento se llevó al menos dos (2) meses de trabajo para poder realizar las adaptaciones necesarias así como también la depuración de las señales obtenidas del levantamiento. Adicionalmente, se mantuvo conversaciones en sitio, con el cliente, para finiquitar detalles tales como: dudas sobre la existencia real de algunos TAGs, rangos de ingeniería faltantes, solicitud de aclaratoria respecto a algunos lazos de control. Para complementar la programación de los bloques fue necesario emplear otra herramienta diseñada específicamente para los dispositivos de I/O, iTools (ver Anexo G). A través de este instrumento se le asignó rango de ingeniería y rango eléctrico a cada uno de los contactos analógicos de los módulos 2500 (I/O). Paralelamente, se generaba la documentación que se podía exportar de Foxboro A2, según los lineamientos de Invensys, y que son necesarios para la conformación del libro de construcción del cliente. 4.6.2.2 Programación digital. Al igual que la programación para el control analógico se empleó la herramienta LinTools. La diferencia consistió, básicamente, en el estudio de todos y cada uno de los lazos de control digital y la generación de las funciones lógicas asociadas a cada lazo. Del mismo modo, fue necesario el cruce de información de la base de datos (lista de TAGs), la narrativa de control respectiva y el P&ID para así poder detectar, verificar y corregir cualquier diferencia existente y con ello depurar la información de dicha base de datos. Al igual que en el caso de la programación analógica, se necesitó intercambiar información entre el cliente e Invensys con el fin de tomar las correcciones a que hubiere lugar; esto se hizo luego de que se expusiera la situación del control analógico. La programación digital difiere de la analógica, fundamentalmente, por el tipo de bloques de control que existen en la herramienta y porque sus funciones más básicas son típicamente booleanos cuyos resultados son, también, booleanos. Existe además, bloques de programación digital que permite manipular información analógica para tomar decisiones en función de los rangos de una señal de ese tipo. 56 Al finalizar la programación digital, se procedió a la revisión de todos los TAGs para estandarizar el formato de los nombres de los mismos. En cuanto a esta situación se procedió a establecer ciertas reglas de nombres para imponer un criterio único de nombres de TAGs. En este aspecto el cliente no demostró desacuerdo alguno. Este procedimiento permite una búsqueda mucho más expedita y sencilla de cualquier nombre asignado, por ejemplo, a una variable del proceso en la planta, analógica o digital. Es de hacer notar que cualquier pequeño cambio significaba la reasignación de TAGs en los módulos 2500, esto si era necesario para no perder el orden ascendente vertical en la lista, en caso contrario todo continuaba inalterable. Igualmente era necesario realizar cambios tanto en el Plant Model (B.D.) así también con el iTools (I/O) cuando se realizaba algún cambio. 4.6.3 Configuración de las pantallas de operación. Esta responsabilidad fue delegada al personal de diseñadores y dibujantes de Invensys, los cuales se encargaron de elaborar las pantallas en su totalidad, desde los esquemas o dibujos hasta las animaciones y pantallas superpuestas (overlay) correspondientes a cada uno de los elementos de la planta P2O5 (ver Anexo I). Debe destacarse el hecho de que la elaboración de las pantallas se fundamentó en las capturas que de estas se hicieron en la planta. La mayor parte de los elementos de dibujo se hicieron en Invensys y se agregaron a una plantilla o matriz de dibujos que los diseñadores crearon para Intouch (HMI). La elaboración de todas las pantallas y la depuración de todas las señales que en ellas aparecía se llevó más de cuatro (4) meses debido a os retrasos originados por la elaboración de muchos proyectos al mismo tiempo, además, el cliente demoró en hacer entrega de sus pantallas ya revisadas y depuradas. Básicamente, las pantallas se convirtieron en una copia fiel de las entregadas por el personal de TRIPOLIVEN, lo mismo que la interfaz de navegación. 4.6.4 Configuración de la galaxia en Wonderware A2. El primer paso para configurar la galaxia consistió en darle un nombre a la misma. El nombre que se escogió corresponde al nombre de la empresa, es decir, TRIPOLIVEN. Luego de esto se realizó la planificación de las áreas de las plantas las cuales llevan el nombre de las cuatro plantas: P2O5, TPF, Servicios y URFOS (ver la Figura 4.6.1). Para ello fue necesario hacer un cotejo de todas las señales, pero que a diferencia de otros procedimientos, ameritaba 57 la asignación y/o asociación de todos y cada uno de los TAGs con un área y un conjunto de dispositivos específicos. Figura 4.6.1 – Organización de las áreas de TRIPOLIVEN. Completado el procedimiento de creación de las áreas principales ($Area) o plantas y sus respectivas sub-áreas, se siguió con la generación e identificación de las plataformas ($WinPlatForm) y motores ($AppEngine) para cada una de las tres (3) computadoras de operación que se utilizarán en P2O5. Como último paso, se agregó un cliente OPC para cada computadora con el fin de que el servidor OPC de Eurotherm se comunique con dicho componente de software, tal y como se explicó en el marco teórico. Esto permitirá la comunicación de los componentes físicos (señales de campo y actuadores electromecánicos ↔ I/O) con el componente de software correspondiente (TAGs ↔ objetos de Wonderware ArchestrA). Vale destacar que en Wonderware ArchestrA la programación se lleva a cabo desde el punto de vista de objetos, es decir, cada dispositivo o señal se trata como un objeto y de haber sub-componentes, igualmente, son tratados como objetos. Culminados las primeras etapas de configuración de la galaxia, se contabilizó el grupo de TAGs asociados a componentes tales como tanques, bombas, tolvas, filtros, etc. Esto con la finalidad de generar los modelos, o grupos de objetos típicos, para cada uno de equipos existentes en la planta de ácido fosfórico. El procedimiento que se llevó a cabo en el proyecto para darle estructura al software DCS no es una práctica estándar en Invensys, en tal sentido fue necesario cumplir con los siguientes pasos: 58 • Se hizo un bosquejo de los lazos de control existentes, teniendo como base la información aportada por los diagramas de lazos, P&ID y la narrativa de control. En este proceso se encontraron lazos que no aparecían inicialmente en los diagramas originales, de hecho, algunos de estos diagramas nunca fueron entregados por el cliente, así que se decidió su inclusión según lo reportado por el P&ID así como también lo expresado en la narrativa de control. Los lazos fueron entregados en borrador al técnico diseñador para su inclusión en una nueva narrativa de control. Dicha documento será elaborado en Invensys como parte del protocolo. • Se elaboró una tabla en la que se localizaron la totalidad de los TAGs de manera que cumpliera con tres aspectos importantes: en primer lugar la existencia de la señal, en segundo lugar una asociación lógica de las señales al equipo o dispositivo respectivo y por último una asociación de un conjunto de equipos a un área que guarda relación directa con el proceso químico de la planta, tal y como se reflejaba en la narrativa de control de TRIPOLIVEN. • Generación de plantillas o típicos en concordancia con las señales existentes en los equipos. El patrón que se siguió consistió en la asignación del máximo de señales posibles por cada plantilla con lo cual se abarcaba la totalidad de señales posibles, independientemente que ese fuera el caso de un único equipo o dispositivo en campo. • Debido a que las únicas señales que mantienen un patrón definido corresponden a las de temperatura, todas operan en ºC, ésta será la única señal que podrá aprovechar las características de propagación del ambiente de desarrollo IAS, de otro modo habría una sobrecarga de señales, la mayoría no utilizables por la totalidad de los equipos que guardan similitud entre sí debido a las unidades de ingeniería. En tal sentido, la configuración de las señales será local y específica para cada una de ellas por equipo, excepto la temperatura. • Para efectos de la comunicación entre el hardware de control y el software del DCS, conexión que se hará vía OPC, se realizará un mapeo de todos los TAGs entre la base de datos que residen el CP y los objetos de Wonderware ArchestrA. 59 En las Figura 4.6.2 y 4.6.3 puede apreciarse el resultado de la configuración obtenida luego de cumplir con los pasos descritos anteriormente. Figura 4.6.2 – Estructura del DCS de TRIPOLIVEN. 60 Figura 4.6.3 – Estructura de plantillas y sus componentes (objetos). CAPÍTULO V DISCUSIÓN DE RESULTADOS En este capitulo se presentan los resultados obtenidos previos a la realización del FAT así como también ejemplos representativos de las herramientas de configuración y programación tanto en Foxboro A2 como en Wonderware A2. 5.1 Programación Analógica. En la Figura 5.1.1 se presenta un esquema que representa una programación en bloques funcionales típica. Como se expuso anteriormente, esta programación fue elaborada tomando en cuenta la información otorgada por el cliente. Figura 5.1.1 – Diagrama de programación analógica elaborada en LinTools. Como se puede apreciar, existen bloques típicos de entrada y salida, en la figura anterior se puede apreciar tanto las entradas analógicas, identificadas como A25_AI, los bloques PID y las salidas analógicas, identificadas como D25_AO, el resto de los bloques son de uso general y dependiendo del caso en que sea necesario utilizarlos, bien sea en programación analógica o digital (ver Figura 5.1.2). 62 Figura 5.1.2 – Vista de la librería de los bloques de programación para el T940. Para mayor detalle de la programación de bloques ver Anexos G y H, allí se podrán apreciar ejemplos de la vista del contenido de algunos bloques. Toda la programación, dependiendo del nivel de organización que se desee, puede ser distribuida en compendios. Dichos compendios representan una nueva hoja, tal como un libro, pero que solo están asociadas a la base de datos en la programación respectiva. En el caso del 63 proyecto, estos fueron organizados según los diagramas de lazos entregados por el cliente, ello con el fin de tratar de mantener cierta similitud con la manera en que este organizó la información. En el caso particular de la programación analógica, tanto las entradas como las salidas, así como los bloques PID, debieron configurarse de manera que tomaran la información de la base de datos con las respectivas unidades de ingeniería utilizadas por el cliente. Esto debió hacerse en cada uno de los bloques para guardar correspondencia con la realidad. Igualmente, en la herramienta iTools (ver Anexo F) se configuraron estos parámetros, tal y como se describió. En la Figura 5.1.2 se puede apreciar la base de datos de la programación que se descargará en el T940. En ella se puede apreciar las bases de datos generadas en la programación (no se debe confundir con la base de datos de los TAGs). Figura 5.1.2 – Detalle de la base de datos de P2O5 que se descargará en el T940. 5.2 Programación digital. En este caso, se procedió exactamente igual que en el caso de la programación analógica, con la única diferencia de que la misma fue desarrollada en función de la narrativa de control y en total ausencia de cualquier diagrama de lazo. Debe destacarse el hecho de que, además del cotejo de señales, se debió utilizar una tabla en la que quedaba asociada la interacción de señales con un evento específico, por ejemplo, al 64 programar el encendido de un motor se debió considerar las señales que afectaban el arranque (causa) para luego tomar una decisión a la salida (efecto) al aplicar la lógica correspondiente. En general, todas las señales se trataron como señales digitales y las decisiones fueron soluciones algebraicas de estas variables, salvo en los casos en que una señal analógica era tomada en cuenta. Para este caso particular se debió colocar un bloque intermediario a través del cual se obtuvo el nivel lógico que se necesitaba (traducción) para luego tomar esa nueva señal e inyectarla a la lógica. El estilo de programación de bloques digitales es muy similar al analógico, la diferencia estriba, obviamente, en el tipo de señales y bloques utilizados en la programación. 5.3 Documentación del proyecto y manejo de costos. A lo largo del desarrollo del proyecto se realizó la documentación o generación de archivos a partir de Foxboro A2. Básicamente se aprovecharon los reportes que éste producía y que luego eran enviados electrónicamente al ingeniero gerente del proyecto. Debido a que la información aquí tratada es de uso exclusivo de Invensys y del cliente no se puede reflejar en este informe mayor detalle respecto a la documentación, sin embargo, los esquemas presentados pueden servir de guía en cuanto al tipo de datos que se manejaron dentro de la empresa durante el tiempo de ejecución del proyecto. Respecto a los costos, igualmente, no se puede brindar mayor detalle, sin embargo, se puede decir que un sistema DCS ArchestrA para un máximo de mil (1000) señales tiene un costo aproximado de 80.000,00 US$. En este monto se incluye toda la labor de ingeniería y servicios asociados a un proyecto de estas dimensiones; si se le compara con un DCS de mayor rango, como el caso de I/A (también de Invensys), su costo es mucho más económico, pues el precio de un sistema como I/A puede rebasar los 150.000,00 US$ lo que representaría un incremento de 47% adicional respecto al monto de ArchestrA. Es en este aspecto, el económico, donde Invensys busca captar la atención de los clientes potenciales de sistemas DCS de rango medio sobre A2. CONCLUSIONES En este proyecto de pasantía se logró elaborar una configuración completa de todo un sistema de control para dar solución a la migración del sistema DCS de la planta P2O5 de la compañía TRIPOLIVEN C.A. En el ínterin, se siguió el protocolo formal para la elaboración de proyectos en Invensys bajo la observación del gerente de dicho proyecto. Para alcanzar el objetivo se debió investigar en la documentación de la compañía respecto al sistema ofrecido al cliente así como también el análisis tanto de software como de hardware asociado. En esta etapa se pudo lograr el entendimiento de cierto patrón que obedece a los lineamientos de la casa matriz respecto a la tecnología ArchestrA, el cual se basa, fundamentalmente, en el bajo costo y la robustez de los equipos de control empleados. Esta característica costo – beneficio se refuerza con el tipo de bus (estandarizado) utilizado en este proyecto; en este aspecto se hace una clara referencia a PROFIBUS DP. Otro de los aspectos fundamentales que se pudo obtener con base en la experiencia adquirida fue el establecimiento de claras diferencias entre Wonderware A2 y Foxboro A2. En el primer caso el sistema se configura a través de la programación de objetos a nivel de DCS o de software propiamente dicho, mientras que en el segundo caso se enlaza el equipo, CP T940 y módulos 2500, al software de control utilizando programación focalizada en el hardware. Aunque en ambos casos se comparte cierta similitud de los paquetes de software, está clara la orientación de cada uno de ellos. En la configuración de la programación del hardware (Foxboro A2) se hicieron pruebas que relacionaron tanto la base de datos descargadas al equipo, T940, con el sistema HMI del cliente, Intouch, de manera exitosa. Respecto a la configuración de la galaxia (Wonderware A2), quedó pendiente realizar las pruebas debido al gran retraso que se generó en la importación, nacionalización y transporte tanto de los computadores como de los dispositivos de control; en todo caso se confió en el entrenamiento y prácticas simuladas realizadas con los instructores de Wonderware en sus oficinas. Se presentaron serios inconvenientes con un material prometido al cliente así como también la configuración inadecuada de un sistema de servidor en el cual se instalaría un paquete de software, Suite Voyager, que permite la visualización de los procesos de las 66 plantas, sin posibilidad de interacción o afectación directa de las mismas. En el primer caso se logró, luego de muchos intentos, la procura de unas tarjetas de red duales que permiten utilizar un mismo número IP para ambos puertos; esta característica permite tener redundancia física. En el caso del sistema de servidor, se hicieron todas las gestiones necesarias para la procura de la licencia del fabricante del sistema operativo, Microsoft, que permitía hacer la instalación de un sistema de operación más antiguo (Windows 2003 Server Std. Edition → Windows 2000 Server). En ambos casos las labores fueron netamente administrativas, sin embargo, fue un problema con el que se tuvo que lidiar con el fin de mantener la confianza del cliente durante todo el proceso de migración. Contrariamente a los esfuerzos realizados para ajustar cronograma del trabajo de pasantía con los hechos que se sucedían en la realidad, donde se incluían las pruebas FAT y SAT, lamentablemente, no se pudo alcanzar los resultados deseados para la ejecución del proyecto. Entre los objetivos finales que se deseaban alcanzar estaba la puesta en marcha del sistema en planta, su entrega al cliente y el entrenamiento asociado al DCS de P2O5. A pesar de lo negativo que representa la no concreción de las metas trazadas, queda la satisfacción de haber participado y haber formado equipo con ingenieros de gran talla en el área de automatización de procesos. Igualmente, representa un gran orgullo haber hecho una configuración de una planta sin la intervención directa de terceros, de hecho, el gerente del proyecto delegó toda la responsabilidad en la persona en quien más confiaba y a quien le dio todas las libertades posibles para solucionar los problemas cuando se presentaron, de igual manera, el valor de la confianza depositada fue retribuida asumiendo la responsabilidad de cumplir con las tareas encomendadas. No en balde, la experiencia previa y personal respecto a configuraciones, instalaciones y puesta en marcha de redes de computadoras así como los años invertidos en la manipulación de sistemas operativos, tanto de red como de estaciones de trabajo, esto sin olvidar la formación que la Universidad Simón Bolívar brinda a sus estudiantes en el aspecto académico así como el roce social obtenido con la permanencia en agrupaciones estudiantiles, añadieron el valor agregado que era necesario para el desarrollo de y configuración de un DCS único y primigenio, por no haber sido realizado antes por ingeniero alguno de Invensys en ninguna parte del territorio venezolano. RECOMENDACIONES Se hace necesaria la adquisición de equipos de computación adecuados al nivel de exigencias de la tecnología ArchestrA para configuraciones futuras, bajo la filosofía de Wonderware-IAS. Esto en vista de las grandes diferencias de requerimientos de hardware que existe entre el estilo de implementación de Wonderware A2 y la de FOXBORO A2. En caso contrario, proveer a los ingenieros de proyectos y servicios de los recursos suficientes para manejar máquinas virtuales en sus equipos portátiles, con la finalidad de hacer prácticas y configuraciones locales durante el desarrollo de los proyectos de A2. Debido a lo novedoso de la tecnología ArchestrA dentro de Invensys y su poco tiempo en el mercado, en comparación, por ejemplo, con el sistema I/A de la misma compañía, es necesario que exista una verdadera y mejor interacción entre el personal de ventas y los ingenieros en las áreas de proyectos y de servicios. Esto con el fin de evitar mayores complicaciones al momento de realizar nuevas implementaciones o el reemplazo de un sistema como en el caso de TRIPOLIVEN. La idea es abrir un espacio de consultas y de planteamientos lo suficientemente claros, desde el inicio de las conversaciones con los clientes potenciales, para evitar tropiezos en el camino y con ello procurar minimizar los imprevistos y evitar pérdidas de recursos, especialmente el tiempo. Esto evitaría traumas durante el proceso de implementación y/o migración de los sistemas, particularmente Foxboro A2, lo cual redundaría en la mejoría de los tiempos de entrega de estos proyectos. Se considera necesario adiestrar debidamente a los ingenieros de proyectos y de servicios según la propuesta del ArchestrA de Wonderware, esto significaría una organización minuciosa del calendario y la agenda dentro de Invensys, así como del apoyo de la gerencia. Una distribución del tiempo, más allá de las constantes o sorpresivas exigencias del cliente, es imprescindible para poder atender el aspecto del entrenamiento del personal en procura de brindar una mejor calidad de servicio. Es imprescindible adquirir una licencia comercial para integradores de sistemas (licencia de desarrollo), sin llave de hardware, más el contrato de soporte de parte de Wonderware de Venezuela. Igualmente, es conveniente la adquisición o actualización de módulos y CP de Eurotherm. Esto con el fin de que Invensys pueda llevar acabo proyectos futuros sin ninguna 68 complicación y en ausencia del material del cliente (hardware y software). Esto eliminaría la fuerte dependencia que existe respecto a los recursos que son propiedad del cliente o del propio personal de Wonderware Venezuela. Sería conveniente destinar un espacio físico, únicamente, a la realización de pruebas FAT para no entorpecer las actividades del resto de los miembros del equipo de ingenieros pertenecientes a los departamentos de Proyectos y de Servicios. Esta situación incomoda el desenvolvimiento de las actividades debido a las limitaciones de espacio y a las distracciones que se originan de una y otra parte, como ha sucedido con el proyecto de TRIPOLIVEN. Dicho espacio podría servir, al igual que el salón de clases, de laboratorio temporal para los ingenieros de Invensys para construir, utilizar y probar configuraciones de sistemas bajo distintos esquemas. Obviamente, se necesitaría una persona dedicada al control y supervisión de estos recursos con el fin de mantener y ordenar tanto el área como los equipos. REFERENCIAS BIBLIOGRÁFICAS [1] [EPA] Enviromental Protection Agency (Estados Unidos de América). “Phosphoric Acid”. [En línea] disponible en: <http://www.epa.gov/ttnchie1/ap42/ch08/final/c08s09.pdf >. Consultado el 11 de agosto de 2005. [2] [WEBOPEDIA] Diccionario en línea. <http://www.webopedia.com/TERM/S/SCADA.html>. Consultado el 1° de junio de 2005. [3] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 25 de agosto de 2005. [En línea] disponible en: <http://en.wikipedia.org/wiki/SCADA> Consultado el 7 de septiembre de 2005. [4] [CERN] European Organization for Nuclear Research. 1 de junio de 2005. [En línea] disponible en: <http://ref.cern.ch/CERN/CNL/2000/003/scada> Consultado el 1 de junio de 2005. [5] [EPA] Enviromental Protection Agency (Estados Unidos de América). “Supervisory Control and Data Acquisition (SCADA)”. [En línea] disponible en: <http://www.epa.gov/safewater/watersecurity/guide/scada.html>. Consultado el 9 de junio de 2005. [6] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 21 de agosto de 2005. [En línea] disponible en: <http://en.wikipedia.org/wiki/Distributed_Control_System> Consultado el 7 de septiembre de 2005. [7] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 25 de agosto de 2005. [En línea] disponible en: <http://en.wikipedia.org/wiki/Fieldbus> Consultado el 26 de septiembre de 2005. [8] [SAMSON] Samson AG. [En línea] disponible en: <www.samson.de/pdf_en/l454en.pdf> Consultado el 20 de septiembre de 2005. [9] Kaschel H. y Pinto E. Análisis del Estado del Arte de los Buses de Campo Aplicados al Control de Procesos Industriales. [En línea] disponible en <http://cabierta.uchile.cl/revista/19/articulos/pdf/edu2.pdf> Consultado el 3 de septiembre de 2005. [10] Autómatas Industriales. [En línea] disponible en: <http://www.automatas.org> 70 Consultado el 22 de julio de 2005. [11] [SAMSON] Samson AG. [En línea] disponible en: <www.samson.de/pdf_en/l453en.pdf > Consultado el 20 de septiembre de 2005. [12] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 10 de septiembre de 2005. [En línea] disponible en: <http://es.wikipedia.org/wiki/Profibus> Consultado el 26 de septiembre de 2005. [13] [ODVA] Asociación internacional ODVA. [En línea] disponible en: <http://www.odva.org/> Consultado el 5 de octubre de 2005. [14] [AS-i] AS Interface [En línea] disponible en : <http://www.as-interface.net/System/Applications> Consultado el 27 de septiembre de 2005. [15] [MODBUS] Modicon Bus. [En línea] disponible en: < http://modbus.org/specs.php> Consultado el 27 de septiembre de 2005. [16] [HART Communication Foundation] Fundación de Comunicación HART. [En línea] disponible en: <http://www.hartcomm.org/index.html> Consultado el 27 de septiembre de 2005. [17] Helson R. An Overview of the HART – Protocol. [En línea] disponible en <www.ife.tugraz.at/datashts/HART/harttech.pdf> Consultado el 27 de septiembre de 2005. [18] [PROFIBUS] Process Field Bus International. [En línea] disponible en: <http://www.profibus.com> Consultado el 1° de junio de 2005. [19] [ABB] Asean Brown Boveri Inc. 9 de septiembre de 2002. [En línea] disponible en: <http://www.abb.com/> Consultado el 27 de septiembre de 2005. [20] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 16 de agosto de 2005. [En línea] disponible en: <http://en.wikipedia.org/wiki/Dynamic_data_exchange> Consultado el 3 de octubre de 2005. [21] RHA (Minisistems) Ltd. [En línea] disponible en: <http://www.angelfire.com/biz/rhaminisys/ddeinfo.html> Consultado el 3 de octubre de 2005. [22] [OPC] OPC Foundation. [En línea] disponible en: 71 <http://www.opcfoundation.org/Default.aspx/01_about/01_whatis.asp?MID=AboutO PC> Consultado el 4 de octubre de 2005. [23] [INVENSYS] Invensys. [En línea] disponible en: <http://www.invensys.com> Consultado el 24 de abril 2005. [24] [TRIPOLIVEN] Tripolifasfatos de Venezuela. 31 de enero de 2005. [En línea] disponible en: <http://www.tripoliven.com/> Consultada el 25 de mayo de 2005. [25] [PaControl.com] Process Automation Control. 1° de octubre de 2005. [En línea] disponible en: <http://www.pacontrol.com/Fieldbus.html> Consultado el 9 de junio de 2005. [26] [UNCU] Universidad Nacional de Cuyo. [En línea] disponible en: <fing.uncu.edu.ar/catedras/archivos/electronica/tema12r.pdf>. Consultado el 28 de septiembre de 2005. [27] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 23 de mayo de 2005. <http://en.wikipedia.org/wiki/RTU>. [En línea] disponible en: Consultado el 7 de septiembre de 2005. [28] [WIKIPEDIA] Enciclopedia comunitaria de libre acceso. 8 de septiembre de 2005. [En línea] disponible en: <http://en.wikipedia.org/wiki/Phosphoric_acid> Consultado el 7 de septiembre de 2005. ANEXOS Anexo A – Tabla comparativa de los buses de campo. Anexo B – Esquema de red de fibra óptica en TRIPOLIVEN. Anexo C – Esquema de red propuesta por TRIPOLIVEN. Anexo D – Herramienta de configuración de TAGs según modelo de planta, Plant Model. Anexo E – Herramienta de asignación de TAGs a los dispositivos de entrada/salida, IO Allocation. Anexo F – Programación en LinTools. Detalle de bloque PID. Anexo G – Herramienta de configuración por punto de conexión, iTools. Anexo H –Programación en LinTools. Detalle de bloque analógico de entrada. Anexo I – Ejemplo de pantalla de operación (sección de molienda). 73 Anexo A – Tabla comparativa de buses de campo. 74 Anexo B – Esquema de red de fibra óptica en TRIPOLIVEN 75 Anexo C – Esquema de red propuesta por TRIPOLIVEN. 76 Anexo D – Herramienta de configuración de TAGs según modelo de planta, Plant Model. 77 Anexo E – Herramienta de asignación de TAGs a los dispositivos de entrada/salida, IO Allocation. 78 Anexo F – Programación en LinTools. Detalle de bloque PID. 79 Anexo G – Herramienta de configuración por punto de conexión, iTools. 80 Anexo H - Programación en LinTools. Detalle de bloque analógico de entrada. 81 Anexo I – Ejemplo de pantalla de operación (sección de molienda).
