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 pre-
ingenierí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