• Author / Uploaded
• israel elguera arevalo

Citation preview

SISTEMA DE CONTROL DISTRIBUIDO (DCS)

HISTORIA Los DCS fueron introducidos en 1975 - Tanto Honeywell y la firma de ingeniería eléctrica japonesa Yokogawa introdujo sus propios DCSs producción independiente más o menos al mismo tiempo, con los sistemas de Centum TDC 2000, respectivamente. Basada en Bristol EE.UU. también presentó su controlador universal de 3000 UCS en 1975 - En 1978, Metso introdujo su propio sistema de DCS se llama Damatic. En 1980, Bailey introdujo el sistema RED 90. También en 1980, Fischer y PorterCompany introdujo DCI-4000. La DCS fue en gran parte producido debido a la mayor disponibilidad de las microcomputadoras y la proliferación de microprocesadores en el mundo del control de procesos. Computers ya habían sido aplicados a la automatización de procesos desde hace algún tiempo, en forma tanto de control digital directo y control del punto de ajuste. A principios del decenio de 1970 Taylor InstrumentCompany, ha desarrollado el sistema de 1010, Foxboro sistema FOX1 y Bailey controla los sistemas de 1055. Todos estos eran aplicaciones DDC aplicadas en minicomputadoras y conectado a la Entrada propietaria/hardware de salida. Así como el control continuo por lotes sofisticado se llevó a cabo de esta manera. Un enfoque más conservador se estableció el control del punto, donde los equipos de procesos supervisados grupos de controladores de procesos analógicos. Una estación de trabajo basada en CRT proporciona visibilidad sobre el proceso mediante el texto y los gráficos de carácter crudo. La disponibilidad de una interfaz gráfica de usuario completamente funcional era una forma de distancia. Fundamental para el modelo DCS fue la inclusión de bloques de funciones de control. Los bloques de función evolucionaron a partir de los primeros conceptos DDC, más primitivos de "TableDriven" software. Una de las primeras realizaciones de software orientado a objetos, bloques de función eran "bloques" independientes de código que las tareas de control de hardware emulado componentes analógicos y realizado que eran esenciales para el control de procesos, tales como la ejecución de los algoritmos PID. Los bloques de función siguen sufriendo como el método predominante de control para los proveedores de DCS, y se apoyan en tecnologías clave como la FoundationFieldbus hoy. Sistemas Midac, de Sydney, Australia, desarrollaron un sistema de control digital directo distribuida orientada opuso en 1982 - El sistema central corrió 11 microprocesadores comparten las tareas y la memoria común y conectada a una red de comunicación serie de controladores distribuidos cada ejecución de dos Z80s. El sistema fue instalado en la Universidad de Melbourne. La comunicación digital entre los controladores distribuidos, estaciones de trabajo y otros elementos de computación fue una de las principales ventajas de los DCS. La atención se centró debidamente en las redes, que proporcionan las líneas de suma importancia de la comunicación que, para aplicaciones de proceso, tuvieron que incorporar funciones específicas, tales como el

determinismo y la redundancia. Como resultado, muchos proveedores adoptaron el estándar de red IEEE 802.4. Esta decisión sentó las bases para la ola de migraciones de tecnología de la información necesaria cuando se mudó a la automatización de procesos y IEEE 802.3 IEEE 802.4 más que prevaleció como la LAN de control.

LA ERA DE NETWORK CENTRIC DE 1980 En la década de 1980, los usuarios comenzaron a mirar a DCS como algo más que lo básico de control de procesos. Un ejemplo muy temprano de un Control Digital Directo DCS fue completado por el Midac empresas australianas en 1981-82 usando R-Tec australiano hardware diseñado. El sistema instalado en la Universidad de Melbourne utiliza una red de comunicaciones en serie, conectando los edificios del campus de nuevo a la sala de control "frontend". Cada unidad remota corrió 2 microprocesadores Z80, mientras que el extremo delantero corrió 11 en una configuración de procesamiento paralelo con memoria común paginado de compartir tareas y podía ejecutar hasta 20.000 concurrentes objetos controles. Se creía que si la apertura podría ser alcanzado y mayores cantidades de datos podría ser compartida en toda la empresa que las cosas aún mayores podrían ser alcanzados. Los primeros intentos de aumentar la transparencia de DCS dieron lugar a la adopción del sistema operativo predominante del día: UNIX. UNIX y su compañero de tecnología de redes TCP-IP han sido desarrollados por el Departamento de Defensa para la apertura de EE.UU., que fue precisamente el tema de las industrias de procesos buscaban resolver. Como proveedores de resultado también comenzaron a adoptar redes basadas en Ethernet con sus propias capas de protocolos propietarios. El estándar TCP/IP completo no se llevó a cabo, pero el uso de Ethernet hace posible la aplicación de los primeros casos de la gestión de objetos y la tecnología mundial de acceso a datos. La década de 1980 también fue testigo de los primeros autómatas integrados en la infraestructura DCS. Historiadores de toda la planta también surgieron para aprovechar el mayor alcance de los sistemas de automatización. El primer proveedor de DCS para adoptar tecnologías de red Ethernet de UNIX y fue Foxboro, que introdujo el sistema I/A Series en 1987.

LA ERA CENTRADA EN LA APLICACIÓN DE LA DÉCADA DE 1990 El impulso hacia la apertura en la década de 1980 cobró impulso a través de la década de 1990 con el aumento de la adopción de comerciales de los componentes estándar y estándares de TI. Probablemente, la mayor transición emprendido durante este tiempo fue el movimiento del sistema operativo UNIX al entorno Windows. Si bien el ámbito del sistema operativo en tiempo real para aplicaciones de control sigue estando dominado por las variantes en tiempo real comerciales de UNIX o sistemas operativos propietarios, todo por encima de un control en tiempo real se ha hecho la transición a Windows.

La introducción de Microsoft en las capas de escritorio y servidores como resultado el desarrollo de tecnologías como OLE para control de procesos, que ahora es un estándar de facto de la conectividad de la industria. La tecnología de Internet también comenzó a dejar su huella en la automatización y el mundo DCS, con la mayor parte HMI DCS soporte a la conectividad a Internet. La década de 1990 también fueron conocidos por el "bus de campo Wars", donde las organizaciones rivales compitieron para definir lo que se convertiría en el estándar de bus de campo IEC para la comunicación digital con la instrumentación de campo en lugar de las comunicaciones analógicas 4-20 miliamperios. Las primeras instalaciones de bus de campo se produjo en la década de 1990. Hacia el final de la década, la tecnología comenzó a desarrollar un impulso significativo, con el mercado consolidó alrededor Ethernet I/P, FoundationFieldbus y Profibus PA para aplicaciones de automatización de procesos. Algunos proveedores construyen nuevos sistemas desde cero para maximizar la funcionalidad con el bus de campo, tales como Rockwell sistema PlantPAx, Honeywell con Experion y sistemas SCADA Plantscape, ABB con el sistema 800xA, Emerson Process Management con el sistema de control DeltaV de Emerson Process Management, Siemens con la APS -T3000 o Simatic PCS 7 y Azbil Corporación con el sistema Harmonas-DEO. De bus de campo técnicas se han utilizado para integrar máquina, unidades, calidad y condición aplicaciones de monitoreo a uno DCS con sistema de ADN Metso. El impacto de COTS, sin embargo, fue más pronunciado en la capa de hardware. Durante años, el principal negocio de los proveedores de DCS había sido el suministro de grandes cantidades de hardware, en especial de E/S y controladores. La proliferación inicial de DCS requiere la instalación de enormes cantidades de este hardware, la mayoría de ellos fabricado de abajo hacia arriba por los proveedores de DCS. Componentes informáticos estándar de fabricantes como Intel y Motorola, sin embargo, hicieron un costo prohibitivo para los proveedores de DCS para seguir haciendo sus propios componentes, estaciones de trabajo y equipos de redes. A medida que los proveedores realizan la transición a los componentes COTS, también descubrieron que el mercado de hardware se estaba reduciendo rápidamente. COTS no sólo dio lugar a menores costes de fabricación de la empresa, sino que también disminuye de manera constante los precios para los usuarios finales, que también se estaban volviendo cada vez más vocal sobre lo que percibían como los costes indebidamente altos hardware. Algunos proveedores que antes eran más fuerte en el negocio de PLC, tales como Rockwell Automation y Siemens, fueron capaces de aprovechar su experiencia en hardware de control de fabricación para entrar en el mercado DCS con las ofertas de coste efectivo, mientras que la estabilidad/escalabilidad/fiabilidad y funcionalidad de estos emergente sistemas todavía están mejorando. Los proveedores tradicionales DCS introducen nuevo sistema DCS generación basado en la última Comunicación y del IEC, que resulta en una tendencia de combinar los conceptos/funcionalidades de PLC y DCS tradicionales en un uno para toda la solución denominada "Sistema de automatización de procesos". Las diferencias entre los distintos sistemas se mantienen en las áreas tales como: la integridad de base de datos, la funcionalidad de preingeniería, la madurez del sistema, transparencia en la comunicación y la fiabilidad. Si bien se espera que el ratio de eficiencia es relativamente el mismo, la realidad del sector de la

automatización a menudo operando estratégicamente caso por caso. El actual paso siguiente evolución se denomina sistemas de automatización de procesos colaborativos. Para agravar el problema, los proveedores también se dan cuenta de que el mercado de hardware se está saturando. El ciclo de vida de los componentes de hardware como de E/S y el cableado es también típicamente en el rango de 15 a 20 años, para hacer un mercado de sustitución desafiante. Muchos de los sistemas más antiguos que se han instalado en los años 1970 y 1980 se encuentran todavía en uso hoy en día, y hay una gran base instalada de sistemas en el mercado que se acerca al fin de su vida útil. Economías industriales desarrolladas en América del Norte, Europa y Japón ya tenían miles de DCS instalados, y con pocas o ninguna las nuevas plantas en construcción, el mercado de un nuevo hardware fue pasando rápidamente a la más pequeña, aunque las regiones de más rápido crecimiento, como China, América Latina , y Europa del Este. Debido a la disminución de negocio del hardware, los proveedores comenzaron a hacer la difícil transición de un modelo de negocio basado en hardware a otra basada en software y servicios de valor añadido. Es una transición que todavía se está realizando en la actualidad. La cartera de aplicaciones que ofrecen los proveedores ampliado considerablemente en los años 90 para incluir áreas como la gestión de la producción, el control basado en modelo, la optimización en tiempo real, gestión de activos de la planta, las herramientas de gestión del rendimiento en tiempo real, gestión de alarmas, y muchos otros. Para obtener el valor real de estas aplicaciones, sin embargo, a menudo se requiere un contenido de servicio considerable, que los proveedores también ofrecen.

DIFERENCIAS Y VENTAJAS ENTRE EL SCADA Y EL DCS Una de las más grandes diferencias aunque no se pueda creer es el costo el SCADA resulta ser mucho mas caro que el DCS por el costo de operación y mantenimiento. Tradicionalmente, los DCS fueron extensos, costosos y muy complejos sistemas orientados para una solución integral para procesos industriales continuos o discretos. Este concepto sigue siendo cierto hoy en dia, y para aplicaciones más pequeñas los ingenieros optan por lo general en utilizar SCADA con el fin de mantener sus costos bajos. Sin embargo la integración de PLCs independientes, la necesidad de interfaces de operación y funcionamiento de supervisión, toma un tiempo y esfuerzo. El punto esta en que los esfuerzos se centran en hacer que tecnologías separadas trabajen juntas, sin mejorar las operaciones, reducir los costos y mejorar la calidad o rentabilidad de la planta.

Un sistema SCADA puede tener toda o parte de la siguiente lista de base de datos independientes o relacionadas de forma manual: -

Cada controlador y sus I/O asociadas

-

Administracion de Alarmas

-

Manejo de Lotes, Produccion

-

Redundancia en todos los niveles

-

Historicos

-

Optimizacion de Activos

-

Administracion de dispositivos con bus de campo

Cada una de estas bases de datos debe ser manualmente sincronizada para que todo el sistema funcione correctamente. Esto es simple después del desarrollo inicial del sistema. Sin embargo, puede convertirse en una complicación innecesaria cuando se realizan cambios y/o mejoras en el sistema durante el tiempo, y mientras más grandes los cambios dan como resultado la programación más horas para realizar el mantenimiento de las bases de datos Haciendo los cambios Cada vez que realización un cambio en una base de datos, las demás usualmente requieren ser actualizadas para reflejar los cambios a la perfección. Por ejemplo, cuando se agregan señales I/O y alguna lógica de control se agrega se puede necesitar cambiar o agregar elementos al SCADA/HMI, al historiador y la base de datos de alarmas. Esto requiere que el ingeniero de planta realice los cambios en cada una de las bases de datos, y no solo en una – y hacerlo bien!!. En otro escenario, un cambio puede ser hecho en la configuración de una alarma dentro de un lazo de control. En el mundo de los PLC no hay una conexión automática entre el PLC mismo y el SCADA/HMI. Esto se puede tornar un serio problema durante la puesta en marcha de una nueva aplicación, donde los límites de alarmas son constantemente ajustadas en el controlador para manejar el proceso, mientras se trata de realizar la administración de las alarmas y mantener actualizadas las aplicaciones HMI con los cambios realizados a la vez que el operador las utiliza. Hoy en día los DCSs, los cuales también son llamados algunas veces “sistemas de control de procesos”, son desarrollados para permitir una rápida implementación en el sistema entero integrando todas las bases de datos en una sola. Se diseña una sola base de datos, configurada y operada desde la misma aplicación. Esto puede tornarse en una reducción seria de costos cuando se usan tecnología DCS si la comparamos con SCADA (o HMI), al menos en el costo de las horas de ingeniería necesarias. El hardware de los DCSs siempre ha sido considerado costo, esto en realidad ya no es el caso de hoy

en día. El hardware de un PLC hoy en día luce como un PLC, y el software puede correr en PC comunes, con la misma red, entonces porque el costo extra? Acaso es el software? Si bien es cierto que el software de los DCS hace que estos sean más caros, pero solo si se compran software con funcionales avanzadas disponibles (que en honor a la verdad frecuentemente no se utilizan o se necesitan). Si nuestra preocupación es un sistema pequeño o mediano, los precios de la adquisición de hardware y software son muy competentes con los de un sistema SCADA. Por lo tanto, la diferencia real está en los costos asociados de las horas de mantenimiento/ingeniería invertidas, lo cual es mejorado y simplificado con una única base de datos en el corazón de un DCS. Hasta este punto, uno puede pensar que la funcionalidad de un DCS esta relegada a los lazos de control, mientras que los PLC están orientadas a aplicaciones discretas y secuenciales, y que por eso no se puede realizar una comparación de igual a igual. Esto es OTRO MITO. Hoy por hoy un DCS es tan funcional y rentable como un PLC para realizar lógica de discreta y secuencial. Vamos a comparar el DCS con el SCADA con los siguientes procesos. Diseño del sistema: Para el SCADA se debe planificar la integración del sistema con el HMI, sistema de alarmas, con el controlador y los demás controladores para cada nuevo proceso. Cada variable de control o TAG debe ser manualmente asignados para cada parte, y además en la documentación de ingeniería de todo el proyecto. Este proceso manual consume mucho tiempo y sobre todo está expuesto a errores humanos. También se deben aprender múltiples programas de software, que podrían tomar semanas de tiempo en adaptarse bien. En cambio para el DCS: En la implementación la lógica diseñada, el sistema de alarmas, el HMI y los sistemas de comunicación son automáticamente configuradas. Generalmente solo se necesita un único software de configuración para actualizar una única base de datos usada para todos los componentes del sistema. A medida que el ingeniero de control diseña la lógica de contrl el resto del sistema también lo hace en paralelo. La forma sencilla de este proceso y su entorno permite a los ingenieros adaptarse y entender el entorno de desarrollo en pocos días. A consecuencia se produce un ahorro entre el 15 y 25% dependiendo de la magnitud del HMI y el alarmado que se está diseñando en el sistema. Programación: La lógica de control, el sistema de comunicación y HMI en sistemas SCADA son programadas independientemente. Los ingenieros de control son los responsable de la integración/enlace de las múltiples bases de datos que se crean en el sistema. Los ítems (tags) deben ser manualmente duplicados en cada elemento del sistema: escalamiento de los datos, niveles de alarma, y localización de tags (direccionamiento). Solamente está disponible un control básico. Extender las funcionalidades necesita crearlas en cada aplicación, por ejemplo feedforward, tracking, self-tuning, etc. Esto conlleva a tener aplicaciones no estándar, tediosas para operar y mantener. La redundancia es usada muy poco o muy simple en los PLCs. Una de las razones es de la dificultad en configurar y administrar la redundancia para la aplicación.

La forma en los DCSs: cuando la lógica de control es desarrollada, los overlays o faceplates HMI, alarmas y sistema de comunicación es automáticamente configurada. Los faceplates automáticamente aparecen con los niveles de alarma y escalamiento de la lógica de control. Estos elementos que contienen datos críticos en el sistema son configurados solo una vez en el sistema. Eso es analógico a tener el calendario en nuestro escritorio y que el teléfono automáticamente se sincroniza a vez de tener que volver a escribir todas las citas en ambos dispositivos. La redundancia es configurada en el software rápida y fácilmente, casi con un simple clic en un botón. El ahora potencial es entre 15 a 45%. Comisionamiento y puerta en marcha: Testear un sistema PLC/HMI normalmente se lleva a cabo con trabajar en el planta después de que todo el cableado se haya completado y el jefe de operación pregunta “porque el sistema aun no está en marcha”. La simulación off-line no es posible, y si se quiere esto lleva un gran esfuerzo de programación para escribir código que simule la aplicación que se está controlando. Debido a los altos costos y una programación compleja, esto se hace raramente. El beneficio de un DCS: un sistema DCS viene con la capacidad para simular automáticamente el proceso basado en la lógica, HMI y alarmado que se va ser usado por el operador de planta. En algunos casos se utiliza un software especial para modelar la planta entera y tener una experiencia casi exacta a todo el proceso, incluyendo la posibilidad de recorridos virtuales para entrenamiento de operadores. Esto ahora tiempo significativo dado que la programación puede ser ya comprobada entes de que el cableado empiece. El ahorro potencial esta entre el 10 y 20% dependiendo de la complejidad de la puesta en marcha y comisionamiento. Solución de Problemas: Un sistema SCADA ofrece excelentes herramientas para solucionar problemas. Por ejemplo, si una entrada o salida es conectada al sistema, la lógica de control será programada utilizando dicho punto sin problemas. Sin embargo, cuando este punto es actualizado, el HMI ha actualizado este punto también? Las alarmas han sido reconfiguradas?. La programación de la lógica es raramente mostrada al operador puesto que todo es un software diferente y nunca intuitivo para que el operador entienda. La forma en un DCS: toda la información es automáticamente disponible para el operador respecto a la lógica que está ejecutando en los controladores. Esto reduce enormemente el tiempo que toma identificar problemas y poner el sistema en marcha nuevamente. El diagnostico de dispositivos de campo (HART o FieldBus) está disponible desde las consolas de operación. Esto ahorra entre 10 y 40%, claro variando específicamente por el tamaño del HMI y alarmado. Capacidad de cambiar para cumplir requerimientos del proceso: -

SCADA: el cambio en la lógica de control para cumplir con requerimientos de la aplicación es relativamente fácil. El problema viene cuando con estos requisitos adicionales o nuevas funcionalidad deben ser integradas con las estaciones de operación. Nuevamente si se

cambia una entrada en una nueva dirección o tag, el cambio debe ser realizado manualmente en todo el sistema. -

DCS: agregar o cambiar la lógica en el sistema es también fácil. En muchos casos incluso más fácil cuando se ha implementado la lógica basándose en plantillas o modelos. Cuando estos cambios se efectúan, los datos en la lógica de control son propagados automáticamente a todos los aspectos del sistema. Esto significa mucho menos errores y todo el sistema a cambio con apenas un solo cambio en la lógica. Ahorro potencial: entre 20 y 25%. Esto afecta directamente a la mejora continua de los programas.

Documentación del sistema: La documentación de un sistema SCADA se basa en realizarla para cada parte del sistema en general. A medida que cada elemento cambio, la documentación se debe actualizar por cada elemento y así tenerla al día. Una vez más, esto rara vez sucede, causando muchos problemas con los futuros cambios y resolución de problemas. En un DCS cuando la lógica de control es modificada, la documentación de todos los aspectos del sistema, se crean automáticamente. En puede ahorrar entre un 30 a 50% dependiendo de la naturaleza de donde el sistema está instalado. Esos ahorros directamente minimizaran el tiempo de inactividad. Esto tiempos de ahorro están basados en costos típicos asociados a un sistema usando 500 I/O más o menos, dos controladores, una Workstation y 25 lazos de control PID.

DCS en Perú La empresa ABB instaló en el Perú más de 20 aplicaciones de Sistemas de Control DCS en distintas unidades mineras, como es el caso de Southern Perú, Compañía Minera Antamina, Minera BarrickMisquichilca, XstrataTintaya, Volcan, Compañía de Minas Buenaventura, Compañía Minera Milpo, Sociedad Minera El Brocal, Minera Chinalco Perú, Compañía Minera Trafigura y otras más. Otras ocho aplicaciones han sido instaladas en empresas de los sectores hidrocarburosy eléctrico, particularmente, en centrales de generación de energía eléctrica.

Ranking de empresas que proveen los DCS en el Mundo y en Latino América