Podría sorprendernos saber que hoy en día un sistema PLC, HMI y SCADA puede costar más que un DCS para el mismo proceso y aplicación en particular.
Tradicionalmente, los DCSs fueron extensos, costosos y muy complejos sistemas orientados para una solución integral para procesos industriales continuos o discretos (batch). Este concepto sigue siendo cierto hoy en día, y para aplicaciones más pequeñas los ingenieros optan por lo general en utilizar PLC/HMI/SCADA con el fin de mantener sus costos bajos.
Pero, Que ha cambiado? La integración de PLCs independientes, la necesidad de interfaces de operación y funcionalidades de supervisión, toma un gran tiempo y esfuerzo. El punto está en que los esfuerzos se centran en hacer que tecnología separada trabaje junta, sin mejorar las operaciones, reducir los costos o mejorar la calidad o rentabilidad de una planta.
Sin embargo, un sistema PLC/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
- Administración de Alarmas
- Manejo de Lotes, producción
- Redundancia en todos los niveles
- Históricos
- Optimización de Activos
- Administración de dispositivos con bus de campo (HART, FF, ProfiBus, etc.)
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 PLC/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 PLC/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.
Demostrando las Ventajas
Podemos mostrar algunos ejemplo de como el flujo de trabajo con DCS nos permitirá ahorrar y reducir drásticamente el tiempo de implementación y mantenimiento de nuestras aplicaciones, comparado con sistemas que involucran PLC/HMI/SCADA.
Se hace mucho más fácil explicar esto siguiendo la secuencia de tareas en desarrollo de un proyecto:
Paso 1: Diseño del Sistema
Los ingenieros o técnicos que utilizan PLC/SCADA deben planificar la integración del sistema con el HMI, sistema de alarmas, comunicación con el controlador y los mismos controladores para cada NUEVO proyecto. 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. Los ingenieros también deben aprender múltiples programas de software, que podría tomar semanas de tiempo en adaptarse bien.
Enfoque DCS: Conforme se implementa 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 UNICO software de configuración para actualizar una UNICA base de datos usada para todos los componentes del sistema. A medida que el ingeniero de control diseña la lógica de control, 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.
Paso 2: Programación
La lógica de control, el sistema de comunicación y HMI en sistemas PLC/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%.
Paso 3: 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.
Paso 4: Solución de Problemas
Un sistema PLC/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.
Paso 5: capacidad de cambiar para cumplir requerimientos del proceso
PLC/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.
Paso 6: Documentación del sistema
La documentación de un sistema PLC/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.
Conclusión:
Si estas usando, o planeando usar, PLCs y HMI/SCADA para controlar tu proceso continuo o discreto, tu aplicación podría ser candidata para usar una solución basada en DCS para ayudarte a reducir costos y mejorar la forma de controlar. El desarrollador puede concentrarse en agregar funcionalidad que proveerán mayores beneficios, reduciendo el periodo de retorno de nuestra inversión. La brecha entre los enfoques de DCS y PLC/SCADA es amplia, aunque podemos observar similitudes a nivel de hardware, siendo la UNICA base de datos el corazón de los beneficios de un DCS.

 

Demostrando las Ventajas

Podemos mostrar algunos ejemplos de como el flujo de trabajo con DCS nos permitirá ahorrar y reducir drásticamente el tiempo de implementación y mantenimiento de nuestras aplicaciones, comparado con sistemas que involucran PLC/HMI/SCADA.

Se hace mucho más fácil explicar esto siguiendo la secuencia de tareas en el desarrollo de un proyecto:

 

Paso 1: Diseño del Sistema

Los ingenieros o técnicos que utilizan PLC/SCADA deben planificar la integración del sistema con el HMI, sistema de alarmas, comunicación con el controlador y los demás controladores para cada NUEVO proyecto. 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. Los ingenieros también deben aprender múltiples programas de software, que podría tomar semanas de tiempo en adaptarse bien.

 

Enfoque DCS: Conforme se implementa 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 UNICO software de configuración para actualizar una UNICA base de datos usada para todos los componentes del sistema. A medida que el ingeniero de control diseña la lógica de control, 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.

 

Paso 2: Programación

La lógica de control, el sistema de comunicación y HMI en sistemas PLC/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%.

 

Paso 3: 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.

 

Paso 4: Solución de Problemas

Un sistema PLC/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.

 

Paso 5: capacidad de cambiar para cumplir requerimientos del proceso

PLC/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.

 

Paso 6: Documentación del sistema

La documentación de un sistema PLC/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.

 

Conclusión:

Si estas usando, o planeando usar, PLCs y HMI/SCADA para controlar tu proceso continuo o discreto, tu aplicación podría ser candidata para usar una solución basada en DCS para ayudarte a reducir costos y mejorar la forma de controlar. El desarrollador puede concentrarse en agregar funcionalidad que proveerán mayores beneficios, reduciendo el periodo de retorno de nuestra inversión. La brecha entre los enfoques de DCS y PLC/SCADA es amplia, aunque podemos observar similitudes a nivel de hardware, siendo la UNICA base de datos el corazón de los beneficios de un DCS.

 

 

 

ALMACENAMIENTO DE DATOS

 

La estación maestra (MTU) es uno de los componentes más importantes en un sistema de control Scada, en tal sentido se debe tener claro las funciones que cumple este equipo dentro del sistema y cuáles son los criterios de selección del mismo.

 

La unidad maestra MTU envía información a cada RTU utilizando un medio común de comunicación y un protocolo común. Ambos, la estación maestra y el RTU, básicamente tienen los mismos equipos de comunicación. La diferencia radica en que la estación maestra MTU es la única que puede iniciar la conversación. Esta comunicación es iniciada por un programa dentro del MTU que puede ser disparado por una instrucción manual dada por el operador o por el mismo programa del MTU. El 99% de los mensajes son iniciados automáticamente por el MTU como parte de sus rutinas de control.

 

Muchos MTU usan protocolos propietarios dependiendo del proveedor del equipo. Este protocolo deberá ser compatible con todas las estaciones a conectar en la red. A este tipo de tecnología se le conoce como una arquitectura cerrada, la cual se caracteriza por tener que utilizar sólo los equipos de un proveedor.

 


Fig. 1

 

Ejemplo de un módulo de comunicación para una estación maestra:

 

Cuando se trabaja con equipos de tecnología abierta, se considera que puede trabajar con distintos proveedores al momento del diseño del sistema. Esto básicamente porque se comparte un estándar entre los proveedores.

 

 

CONFIGURANDO UNA PANTALLA DE UN PROCESO

 

Para visualizar una información adecuada del estado de las estaciones remotas, es necesario que todos los elementos de campo necesarios se encuentren conectados a las RTU. De esa manera el MTU podrá obtener este tipo de información.

 


Fig. 2

 

 

A continuación se muestra un ejemplo que consiste de un proceso simple para el control de una línea de alimentación de combustibles.

 


Fig. 3

 

El RTU 1 monitorea el estado de la bomba, el cual puede estar prendido o apagado. También se puede controlar el encendido y apagado de la bomba. Del mismo modo se puede abrir y cerrar la válvula e identificar el estado de la válvula. Adicionalmente se tiene el dato de la totalización del flujo a través de la tubería y de la alarma por presión bajo en la línea.

 

En el RTU 2 se tiene sólo un bloque de control de la válvula. Se controla la apertura y cierre de la válvula y se monitorea el estado de la misma. Al igual que el caso del RTU1 se monitorea el estado de la presión mínima en la línea del proceso.

 

El RTU3 tiene la misma función que el RTU1 sólo que no se tiene una bomba a controlar.

 

Se tiene un sistema simple para el monitoreo del sistema Scada. Se busca evitar las fugas en la línea de alimentación del proceso. La detección puede ser realizada por la diferencia entre el totalizador a la entrada y el totalizador a la salida. Además se tiene un monitoreo continuo de la pérdida de presión en la línea en caso de una fuga de combustible. Cuando alguna de estas condiciones se presenta, en la tabla de datos de la estación maestra se activaría una señal de alarma que tome acción directa sobre el proceso. En esta caso se enviaría una señal para cerrar las válvulas del proceso en forma secuencial. Si es que no se recibe una confirmación que las válvulas se han cerrado, el MTU vuelve a enviar la señal de cierre. Si el problema persiste, se dará una señal de alarma al operador para que tome acción directa sobre el proceso.

 

El MTU en caso de falla y pierda comunicación con los RTU´s deberá recuperar la comunicación en forma automática. Si la comunicación no se llega a establecer se puede activar una rutina que mande detener el proceso. Esto es que los RTU?s manden cerrar sus válvulas y cortar el flujo.

 

La visualización del estado del proceso se hace desde una estación de supervisión que consiste de una PC con un software de supervisión que permita ver el estado de los equipos en forma gráfica.

 


Fig. 4

 

A continuación se muestra los códigos que son enviados al RTU1 para el control del proceso.

 

 

 

El lazo de comunicación es sólo entre dos estaciones. Cualquiera de las dos estaciones puede iniciar la comunicación o se puede configurar para que sea una de ellas quien controle a la otra.

 

La figura 8 muestra un simple sistema Scada que consiste de una unidad maestra MTU y una unidad remota RTU. El MTU y el RTU deben ser equipados con equipos de comunicación para establecer la comunicación uno con otro.

Que es SCADA?

 

SCADA son las siglas de Supervisión Control y Adquisición de Datos. También algunos autores lo definen como la tecnología que habilita la colección de datos de locaciones remotas, así como el envío de información a estas locaciones.

Página 1 de 2

Warning: mysqli_close(): Couldn't fetch mysqli in /home/freelancer01/instrumentacionycontrol.net/libraries/joomla/database/driver/mysqli.php on line 209

Warning: mysqli_close(): Couldn't fetch mysqli in /home/freelancer01/instrumentacionycontrol.net/libraries/joomla/database/driver/mysqli.php on line 209

Warning: mysqli_close(): Couldn't fetch mysqli in /home/freelancer01/instrumentacionycontrol.net/libraries/joomla/database/driver/mysqli.php on line 209

Warning: mysqli_close(): Couldn't fetch mysqli in /home/freelancer01/instrumentacionycontrol.net/libraries/joomla/database/driver/mysqli.php on line 209

Warning: mysqli_close(): Couldn't fetch mysqli in /home/freelancer01/instrumentacionycontrol.net/libraries/joomla/database/driver/mysqli.php on line 209

Warning: mysqli_close(): Couldn't fetch mysqli in /home/freelancer01/instrumentacionycontrol.net/libraries/joomla/database/driver/mysqli.php on line 209