Universidad de Costa Rica: Facultad de Ingeniería

UNIVERSIDAD DE COSTA RICA
FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA QUÍMICA
Desarrollo de las habilidades necesarias para migrar un sistema de control automático

desde la plataforma de Provox hacia DeltaV en la empresa Emerson.
Informe de práctica dirigida de graduación sometida a la consideración de la Escuela de

Ingeniería Química como requisito final para optar por el grado de Licenciatura en Ingeniería
Química
Daniel Eduardo Mata Barrantes
Ciudad Universitaria Rodrigo Facio

San Pedro, 2013
ii
Desarrollo las habilidades necesarias para migrar un sistema de control automático desde
la plataforma de Provox hacia DeltaV en la empresa Emerson.
Informe de práctica dirigida de graduación sometida a la consideración de la Escuela de

Ingeniería Química como requisito final para optar por el grado de Licenciatura en Ingeniería
Química
Sustentante:
Daniel Eduardo Mata Barrantes
'n Berrera
Presidente del Tribunal.
---~
Ing. Ad o Ulate Brenes, M. Se.

rector del Proyecto
Maut'f í\. (?rd.ºhil=____

Ing. Maureen Córdoba Pérez
Miembro Lector
~~------
Ing. Adriana Román Cabezas
Miembro Lector
Dr. Benito A. Stradi Granados

Catedrático. Profesor Invitado
iii
A mis papás, mi hermana y mi novia,
que gracias a su apoyo se hizo posible
la culminación de este proyecto
iv
Reconocimientos
Luego de finalizada mi practica dirigida y de haber redactado mi trabajo final de graduación, es

mi deseo agradecerle a todas las personas que me ayudaron durante este largo camino.
Primero, quiero darle las gracias al profesor e ingeniero Adolfo Ulate Brenes por haberme
guiado con paciencia y dedicación durante todo el planteamiento y realización de mi proyecto.
Este apoyo al final de este camino sólo vino a reforzar toda la ayuda brindada a lo largo de estos
5 años cuando siempre estuvo disponible para cualquier consulta que uno tuviera.
También fueron de gran ayuda los aportes realizados por la Ingeniera Mauren Córdoba a la hora
de la redacción de esta práctica. Su ayuda aportó mucho a poder luchar contra ciertas
deficiencias a la hora de lograr redactar el informe y poder expresar en palabras lo que estaba
pensando.
Por último agradecerle a la empresa Emerson Costa Rica, que me dieron la oportunidad de
realizar esta práctica dirigida en la empresa. A la ingeniera Adriana Román, que fue la persona
que me ayudó a entrar a la empresa y luego más que mi jefa, fue una guía a lo largo de este
proyecto. A mis compañeros de trabajo, en especial al ingeniero Esteban Echeverría el cual como
líder del proyecto, siempre estuvo dispuesto a aclarar cualquier duda de la mejor manera.
v
INDICE
INDICE DE FIGURAS................................................................................................................ viii
INDICE DE CUADROS................................................................................................................ ix
Resumen.......................................................................................................................................... x
INTRODUCCIÓN .......................................................................................................................... 1
Justificación ................................................................................................................................ 1
CAPITULO 1: Marco Teórico ........................................................................................................ 3
Emerson ...................................................................................................................................... 3
Provox ......................................................................................................................................... 4
Lógicas de control en Provox ................................................................................................. 5
Principales instrucciones para la programación de FSTs ..................................................... 5
Deltav .......................................................................................................................................... 9
Migraciones .............................................................................................................................. 11
CAPITULO 2: Métodos de Trabajo ............................................................................................. 13
CAPITULO 3: Software de la Empresa Emerson ........................................................................ 20
DeltaV Overview ....................................................................................................................... 21
Operate ................................................................................................................................. 21
Configuration Suite ............................................................................................................... 24
DeltaV Explorer .................................................................................................................... 24
Control Studio ....................................................................................................................... 24
Sequencial Function Charts ...................................................................................................... 25
Phase Logic Modules ................................................................................................................ 27
CAPITULO 5: Revisión de fases migradas hacia DeltaV ............................................................ 36
CAPITULO 6: Migración de una fase hacia DeltaV .................................................................... 38

vi
vii
CAPITULO 7: CONCLUSIONES Y RECOMENDACIONES................................................... 51
CONCLUCIONES..................................................................................................................... 51
RECOMENDACIONES ............................................................................................................ 52
BIBLIOGRAFÍA .......................................................................................................................... 53
A.1 GLOSARIO ......................................................................................................................... 54
A.2 HOJA PARA LA REVISION DE LOS ESTADOS ............................................................... 55
A.3 CERTIFICADO DE APROBACION DEL CURSO 7009 ................................................... 56

INDICE DE FIGURAS
Figura 2.1 Paso del aprendizaje escalonado propuesto para la práctica ....................................... 13
Figura 3.1 Ejemplo DeltaV Operate Run ...................................................................................... 22
Figura 3.2 Ejemplo de DeltaV Operate Configure ....................................................................... 23
Figura 3.3 Ejemplo de un diagramas de función secuencial ......................................................... 26
Figura 3.4 Ejemplo de edición de las propiedades de una acción ................................................ 27
Figura 3.5 Ejemplo de un módulos de lógica de fase ................................................................... 28
Figura 4.1 Ejemplo de la figura utilizada para las acciones ......................................................... 29
Figura 4.2 Ejemplo de la figura utilizada para las transiciones .................................................... 30
Figura 4.3 Ejemplo de la figura utilizada para las esperas ........................................................... 30
Figura 4.4 Ejemplo de un documento en Visio sobre una fase en DeltaV ................................... 34
Figura 4.4 (cont.) Ejemplo de un documento en Visio sobre una fase en DeltaV ........................ 35
Figura 6.1 Vista general de las fases y units en Provox................................................................ 40
Figura 6.2 Fase LIST_TAMB programada en Provox ................................................................. 41
Figura 6.2 (cont.) Fase LIST_TAMB programada en Provox ...................................................... 42
Figura 6.3 Diagrama de función secuencial .................................................................................. 44
Figura 6.3 (cont.) Diagrama de función secuencial ...................................................................... 45
Figura 6.4 Diagrama de flujo de la fase LIST_TAMB ................................................................. 47
viii
INDICE DE CUADROS
Cuadro2.1 Ejemplo de distribución de trabajo ............................................................................. 17
Cuadro 5.1 Ejemplo de asignación de registros UV en Provox .................................................... 37
Cuadro 5.2 Asignación de registros I/FXXXXXX en Provox ...................................................... 37
ix
Resumen
El presente trabajo se concentra en el resultado de una práctica profesional en donde se

adquirieron los conocimientos necesarios para poder realizar una migración de una fase desde el
sistema de Provox hacia el sistema Deltav. Esto se logró por medio de adquisición de
conocimiento tanto en la obtención de cursos como con el trabajo cotidiano realizado en la
empresa.
El inicio del estudio se vio complicado debido a que la disponibilidad de bibliografía acerca del
tema es escasa, por lo que fue necesario apoyarse, en gran medida, en los manuales e
información disponible que tiene la empresa para sus empleados, además del consejo y la
supervisión de personal altamente capacitado en estos aspectos.
Entre los principales logros del trabajo se tiene que la curva de aprendizaje trazada para lograr
llegar a tener las habilidades necesarias para migrar una fase fue correctamente diseñada y
llevada a cabo ya que al final de la práctica, esto se podía hacer con relativa facilidad. Además
se adquirieron habilidades y conocimientos de suma importancia a la hora de desempeñarse en
cualquier empresa o lugar de trabajo que van más allá de las habilidades técnicas como lo son la
comunicación constante y el trabajo en equipo que sin esta parte fundamental no hubiera sido
posible llevar a cabo el actual proyecto.
x
INTRODUCCIÓN
Justificación
El objetivo principal del control automático, implementado en una planta, es el de ajustar una
variable manipulada con el objetivo de mantener la variable controlada en el punto de consigna a
pesar de los disturbios que pueda presentar. Además el control automático ayuda a prevenir
accidentes en los trabajadores, proteger el ambiente, y prevenir daños a los equipos de trabajo;
también ayuda a mantener el producto con la calidad especificada y evitar el desperdicio de
materia prima. (Smith & Corripio, 2006) Todas estas ventajas que presenta el control
automatizado de los procesos lo hacen ser una herramienta muy poderosa a la hora de
estandarizar los procesos y de proveer un valor agregado al producto que se está fabricando. En
general se puede resumir en garantizar la calidad del producto y aumentar las condiciones de
seguridad a la hora de fabricarlo.
Existe un número importante de empresas actualmente en el mercado que ofrecen los servicios
de automatización industrial, entre las que destacan los sistemas de las empresas Siemens,
Honeywell, General Electric y Rockwel, entre otros. Así como hay una gran cantidad de
empresas hay un igual número de sistemas que operan de manera diferente entre sí. Esto se
puede ver desde una óptica en la que ya muchas empresas tienen implementados sistemas de
control y usan un sistema en específico. Esta diversidad de sistemas representa un reto para las
otras empresas para poder lograr ser contratadas para mejorar el sistema ya existente porque es
diferente de la compañía original. Esta situación explicada anteriormente se denomina una
migración de un sistema de control automático a otro. Esto significa que se pasará de un sistema
a otro, que haga lo mismo pero que sea más moderno, con más funciones y mayor capacidad de
control. Para esto se mantiene la misma filosofía de control programada con anterioridad pero se
traducen los códigos a lenguaje DeltaV el cual se implementará en la planta para ver si presenta
algún problema en su funcionamiento.
La práctica se enfocó en brindar el apoyo a una migración de un sistema en Provox a un sistema

en DeltaV. Para llegar a lograr esto se siguieron una serie de etapas de aprendizaje las cuales se
fueron cumpliendo hasta lograr llegar al punto en que se podía realizar una migración del código
1
2
de Provox hacia el de DeltaV. Estas etapas de aprendizaje se representaron por los objetivos
propuestos.
CAPITULO 1: Marco Teórico
Emerson
Emerson fue fundada en 1890 en St. Louis, Missouri por los hermanos Meston provenientes de
Escocia. Ellos tenían la idea de fundar una compañía dedicada a la producción de motores de
corriente alterna para así poder fabricar ventiladores eléctricos. El capital inicial para montar la
empresa lo brindo un ex oficial del ejército de la unión llamado John Wesley Emerson por el
cual se nombró a la compañía The Emerson Electric Manufacturing Company. (Emerson
Electric Co, 2013)
Ya para el año de 1892 la compañía era un símbolo de éxito y de calidad. Cinco años después
introdujeron el ventilador de techo el cual fue ampliamente aceptado y significo más de la mitad
de las ventas de la compañía por varios años. Para la gran depresión de Estados Unidos la
compañía bajo sus ventas en aproximadamente dos tercios lo cual casi la lleva a la quiebra. Los
siguientes años la compañía se dedicó a intentar salir del bache en el que se encontraban
intentando diversificar sus líneas de ventiladores y motores. (Emerson Electric Co, 2013)
Con el estallido de la segunda guerra mundial el gobierno le brindó una gran cantidad de
concesiones a Emerson para trabajar con metales y construir carcasas de latón para aviones. Con
el final de la guerra en 1945 la empresa vuelve a producir con fines comerciales para el público
en general. (Emerson Electric Co, 2013)
Para el año de 1954 W.R. “Buck” Persons es elegido presidente de la empresa. Con una gran
visión y pensamiento a futuro reestructura la organización y diversificación de la empresa.
Durante su gestión se adquieren 36 distintas compañías empezando a crear a Emerson como un
conglomerado de distintas empresas con una muy amplia diversidad. Él se enfocó en políticas
corporativas que ayudaran a reducir los costos, a aumentar la calidad de los productos y a tener
una muy buena planificación. Bajo su mandato, la compañía pasó de tener 2 plantas y 4 000
empleados a poseer 82 plantas con 31 000 empleados. (Emerson Electric Co, 2013)
Desde 1973 con el cambio de mando de la empresa se define una nueva estrategia corporativa
enfocada en el desarrollo, la fabricación y comercialización de productos de alta tecnología,
3
4
adquisición de otras empresas y un crecimiento internacional. Durante 20 años se adquirieron la

mayor parte de las divisiones relacionadas al control automático como Rosemount y Fisher
Controls, entre otras. Para el año 2000 la compañía ya tenía 43 años consecutivos de tener un
crecimiento en sus ganancias. (Emerson Electric Co, 2013)
En el año 2000 se elige como presidente David Farr quien todavía se encuentra desempeñando
sus funciones. Bajo su mando se cambió el nombre de la empresa por uno más corto: Emerson y
se le agrega el lema “Consider it solved”. En el 2007 abre operaciones en el país como un centro
de ingeniería. (Emerson Electric Co, 2013)
Para el 2012 Emerson tuvo ingresos por 24.4 billones de dólares y empleó a 135 000 personas
alrededor del mundo, haciendo negocios en más de 150 países y consiguiendo sólo en el 2012, 1
600 patentes. (Emerson Electric Co, 2013)
Provox
Para hablar sobre Provox se debe de ahondar en la historia de la compañía Fisher Controls
International LLC, la cual fue fundada en 1880 y desde entonces siempre ha estado involucrada
con el control de procesos. Es así como se ha dedicado a construir bombas, válvulas y sistemas
de control automático a lo largo de su historia. En 1969 la compañía es adquirida por Monsanto
y se cambia su nombre a Fisher Controls Company la cual se vende en el año 1992 a Emerson
por $ 1.4 billones. Emerson tomó esta compañía y la unió con una propia llamada Rosemount
dando como resultado el nacimiento de Fisher-Rosemount. En el año 2001 se le vuelve a
cambiar el nombre a Emerson Process Managment, el cual hasta el día de hoy es una de las
divisiones de la empresa. Esta compañía es de las más viejas en el mundo en diseñar, fabricar y
suplir válvulas y reguladores además de diseñar e implementar sistemas finales de control.
(Patterson & Smid, 2005)
La compañía se dedicó a las válvulas y distintos tipos de reguladores hasta que en los primeros
años de los 70 Monsanto desarrollo un sistema de instrumentación analógica la cual será
progenitora del sistema de control distribuido Provox, el cual tiene capacidad para controlar
procesos altamente complicados. La línea de productos Fisher-Rosemount dominaron el
mercado global del control de procesos en los primeros años de los 90s, ofreciendo la mayor
5
cantidad de productos relacionados a la automatización industrial. Ofrecían una gran variedad de

válvulas de control, reguladores, transmisores, analizadores, entre otros. Entre las empresas que
fueron automatizadas se encuentran la de productos químicos, plásticos, vidrio, refinerías,
producción de gas, papel, alimentos, farmacéuticas y minerías, mostrando de esta forma la
versatilidad del sistema. Para 1996 la compañía presenta la arquitectura de planta digital
PlantWeb, la cual integra todos los sistemas de control de sus divisiones, sus maneras de
comunicarse y distintos software con las nuevas tecnologías para asegurar un mejor manejo de
las plantas ofreciendo a sus clientes sistemas de soluciones totales para sus problemas. En el año
1997 Fisher-Rosemount presenta su primera versión del sistema DeltaV, el cual desplazo
completamente a Provox el cual se fue quedando poco a poco atrás hasta el punto en que ya no
se vendieran más estos sistemas. (Patterson & Smid, 2005)
Lógicas de control en Provox
A la hora de realizar la configuración de las estrategias de control, por lo general un algoritmo

estándar como un PID no va a servir para lograr el objetivo. Para poder lograr esto, en Provox lo
que se utilizan son las lógicas de control, LCP (Logic Control Point), los cuales se pueden definir
como el “ambiente de ejecución” en el cual se tiene una TFS: tabla de función secuencial (FST:
Function Sequence Table). El FST, es un algoritmo que se programa con una combinación de
funciones y de varias instrucciones. A continuación repasaremos las instrucciones más utilizadas
a la hora de configurar una FST. (CREEC, 2013)
Principales instrucciones para la programación de FSTs
Un registro electrónico en Provox es un dispositivo lógico secuencial que puede llegar a

almacenar 32 bits de información. Para ordenar estos registros se utilizan 3 tipos de los mismos
los cuales son los Enteros (Integers: I), los booleanos (boolean: B) y los puntos flotantes
(Floating point: F). Los enteros tienen la restricción a como su nombre lo indica que sólo se les
pueden escribir números enteros sin puntos decimales. Los registros booleanos pueden tener
como valor un 1 o un 0, que representan un verdadero o falso. Y por último los puntos flotantes
son los que admiten los decimales. (CREEC, 2013)
6
Una vez que ya se habló sobre las formas en las que se almacenan los datos en el sistema se
puede continuar con la forma en la que se programa en Provox. Existen 4 comandos principales
y más generales los cuales se utilizan para cargar, guardar, leer y escribir valores. Estos 4
comandos son los siguientes: (CREEC, 2013)
 LDSV: sus siglas significan Load Signal Value. Es el comando utilizado para cargar
valores. Y al escribir el comando se utilizan paréntesis redondos para indicar el registro
que se debe de cargar. Por ejemplo: LDSV(I22). Esta expresión anterior lo que indica es
que se cargará el valor del registro entero 22.
 STSV: sus siglas significan Store Signal Value. Es el comando utilizado para guardar
valores en algún registro. Al igual que el comando anterior se pone dentro de los
paréntesis el registro al que se guarda el valor.
 DARD: Sus siglas son data Access read, con este comando lo que se hace es leer el valor
de algún lazo o de la apertura de una válvula, entre otros. Por ejemplo: DARD (F ,
%IVP:I22). En el ejemplo anterior lo que podemos ver es que la acción indica que se lea
el valor flotante de %IVP:I22, que para este caso es la salida que se obtiene en un lazo de
control.
 DAWT: data acces write. Con este comando se puede escribir a registros, a lazos, se
pueden asignar puntos de consigna, entre otros. Tiene el mismo formato que el anterior
ejemplo, en donde primero se define qué tipo de registro se está escribiendo y luego a
donde se escribe.
Luego de estos 4 comandos están también una serie de instrucciones que se escriben en la
programación de las LCPs. A continuación se hará una explicación breve sobre los que más se
utilizaran en el desarrollo de la práctica: (Control Desktop. Fisher-Rosemount Systems, 2000)
 ACQUIRE: con este comando se adquieren recursos compartidos, lo más común en

adquirir con esto son equipos, los cuales una vez que se utilizan, son liberados.
 CALCULATE: Son operaciones matemáticas específicas que se realizan cada cierta
cantidad de intervalos. Se pueden definir 4 cálculos diferentes por cada unit. Esta
instrucción a la hora de escribirla en el programa tiene 4 campos que van entre paréntesis
separados por comas.
7
Ejemplo: CALCULATE (C1, UV[11], 1+UV[10], 1). En el ejemplo anterior, el primer

valor (C1) indica que se esta realizando el cálculo C1, que puede llegar hasta C4, luego la
operación matemática es UV[10] + 1, y el valor resultante se guarda en UV[11] y esto se
realiza cada 1 segundo.
 SCALCULATE: se utiliza para que la rutina que se comenzó con CALCULATE

finalice. Entonces se escribe esta instrucción seguida de paréntesis con cual cálculo (C1
a C4) finalizar.
 CONST: es de los que más se utilizan en el presente proyecto. Lo que realiza es asignar
el valor de una constante a un DBE (Data base element) el cual puede ser un set point, un
integrador, un timer entre otros.
Ejemplo: CONST(UV[10], 0), lo que quiere decir la expresión anterior es que se le

asigna un valor de 0 al registro UV[10]. Esto quiere decir que en el código, la próxima
vez que se lea el valor de UV[10] será un 0, para el caso del ejemplo.
 DBI: sus siglas son en el idioma inglés Database interchange. Lo que realiza es
básicamente lo mismo que CONST, con el detalle de que no es un valor constante el que
asigna, sino que toma el valor de un DBE y lo pega en otro.
Ejemplo: DBI (UV[31], GIREG[15]:VAR), esto anterior indica que se toma el registro
entero regular general (GIREG) 15, de la lista VAR, y se le asigna a UV[31]. Las listas
de VAR son listas que se levantan con las variables definidas para cada fase, en donde se
le asigna a cada variable un número. Entonces si el valor de GIREG[15]:VAR fuera 20,
la próxima vez que se utilice UV[31] tendrá este mismo valor.
 EXPRESSION: funciona igual que CALCULATE, sólo que no tiene ni el primer ni el

último campo en su fórmula, ya que se ejecuta una sola vez y guarda su valor para el
futuro.
 GOTO: esta expresión lo que hace es ramificar la rutina incondicionalmente a otra
etiqueta.
8
 IF: Evalúa alguna expresión definida por el usuario, si esta se cumple la rutina se
ramifica hacia otra etiqueta, si es falso se continua con la instrucción que sigue
inmediatamente.
 LABEL: Es la forma en la que se organizan las instrucciones, es así como un label es
como un “subtitulo” de un grupo de instrucciones. Esto sirve para que otras instrucciones
como ONGOTO, GOTO o IF se referencia a los LABELS.
 NEXT: se utiliza para continuar a la siguiente fase deseada en la unit en que se está
trabajando.
 ONGOTO: Evalúa una variable que es ingresada, y ramifica a distintos sitios de la rutina
dependiendo del valor ingresado.
Ejemplo: ONGOTO(UV[29], TASK1, TASK2, TASK3, LABEL 99). La expresión

anterior se interpreta de la siguiente manera: Si el valor de UV[29] es 1, entonces se
ramifica hacia task1, si el valor es 2 salta hacia TASK2, si es 3 hacia TASK3 y si es 4
hacia LABEL99.
 TIMER: inicia un cronometro de la unidad, que mide el tiempo transcurrido en

segundos. Al igual que los calculate sólo se pueden tener 4 TIMER por unit. Con la
instrucción CONST se puede poner en cero o en algún otro valor inicial.
 STIMER: suspende el timer que se indique y guarda su último valor para posterior uso.
 WAIT: tiene 2 campos, el primero el que indica la cantidad de tiempo que se debe de
realizar una espera en la rutina y otro en el que se pone si puede ser cancelado por el
operador (CWEN) o si no puede ser cancelado (NOCWEN).
 WAITUNTIL: consiste en una espera a que se cumplan ciertas condiciones o
expresiones ingresadas por el usuario. Además contiene un campo en donde se indica la
cantidad de tiempo que existe entre la evaluación de cada una de las condiciones antes
escritas y por ultimo si es cancelable o no por el operador.
 YESNO: es una pregunta hacia el operador en el que debe de escoger entre las opciones
si y no. Luego esto se guarda en un booleano y se puede utilizar después.
9
Deltav
DeltaV es el sistema de control distribuido (DCS) con el cual trabaja en este momento Emerson
para todas sus aplicaciones de automatización industrial. Un sistema de control distribuido es un
sistema basado en microprocesadores los cuales tienen distribuidas la carga de la
implementación de la estrategia de control, con lo que se aumenta la fidelidad de estos sistemas
(Smith & Corripio, 2006). Dentro de sus diferentes capacidades, los sistemas DCS tienen
diferencias. DeltaV presenta una serie de ventajas comparativas debido a que brinda un muy
buen manejo de la planta ya que puede presentar una velocidad mayor de comunicación, en la
que se integran muchos dispositivos inteligentes que pueden tanto enviar como recibir
información al sistema integrado. Este sistema no presenta ninguna dificultad a la hora de diseño
que pueda surgir a partir del tamaño de la planta o de la aplicación de control que se requiera
implementar, además soporta procesos que sean tanto continuos como batch. Este sistema
además presenta la particularidad de que ya viene programado para ser redundante lo cual lo
hace mucho más seguro y tiene menos probabilidad de presentar algún fallo. (Getting Started
With Your DeltaV Digital Automation System, 2010)
A la hora de interactuar con DeltaV se tienen varios tipos de usuarios que pueden registrarse,
entonces es así como se pueden crear filtros para cada tipo de operario o si es un supervisor o
una persona autorizada a realizar cambios en las estrategias de control. Con estos filtros se va a
tener distintas potestades dentro del sistema, es así como ciertos usuarios tienen capacidades para
detener alarmas, realizar cambios en el sistema, comenzar o parar procesos, escribir puntos de
consigna, o cambiar de modo algún lazo, todas estas opciones son completamente
personalizables y se pueden configurar para cada usuario que va a ingresar al sistema. (DeltaV
Digital Automation System, 2009)
En cuanto a las funciones de ingeniería que presenta el sistema, al ser tan amplias tiene varios
programas con los cuales se realizan distintas funciones. Entre estos programas tenemos los
siguientes: (DeltaV Digital Automation System, 2009)
 DeltaV Explorer: es la herramienta principal de configuración, representa todo el sistema

en general. Su apariencia se asemeja mucho a la del programa Explorer de Windows.
10
Acá se puede revisar que elementos están asignados a cada controlador, cuales
dispositivos están creados, sus nombre y su configuración.
 Control Studio: En este programa es que se programa y se modifica la lógica que da la
estrategia de control. Esto se realiza de forma gráfica, con algo similar a un diagrama de
flujo con cajas, que dentro tienen su configuración particular.
Además de los programas anteriormente mencionados en cuanto a funciones que hacen que el
sistema sea altamente efectivo a la hora de aplicarlo en una planta se tiene que: (DeltaV Digital
Automation System, 2009)
 Fácil configuración de I/O: siempre que un controlador o un dispositivo se conecta a la

red es auto-sensado por el sistema y se agrega al DeltaV Explorer para su configuración.
Esto reduce mucho el tiempo a la hora de comisionar.
 Fácil configuración de las lógicas: a la hora de configurar las lógicas se tiene que se
puede usar Drag-and-Drop en la interface del Control Studio para utilizar bloques
preconfigurados que son usados con frecuencia. Estos bloques son fácilmente
configurable y adaptados a cada aplicación específica. Además, el sistema queda
configurado automáticamente para recolectar los datos de todo lo que sucede, de todos
los cambios, y quien los realiza, a lo largo del tiempo y los va guardando en un servidor
específico para esto.
 Adaptable: el sistema es completamente adaptable y configurable a la aplicación que se
desea. A la hora de programar tiene la facilidad de que muchas cuentas pueden accesar al
mismo tiempo la información en el sistema e irlo programando al mismo tiempo. No
necesita estar en línea para ser configurado, se pueden realizar unas acciones llamadas
bulk-edits para configurar más rápidamente grandes cantidades de módulos, entre otras
funciones.
Por último se tiene un programa que se llama DeltaV Operate el cual es básicamente donde se ve
el producto final que se presenta al cliente en la planta. Consiste en la pantalla en donde se ve el
proceso y el operador puede interactuar para controlarlo o modificarlo. En este programa se
observan fácilmente las alarmas que se activan que son accesibles con las credenciales con las
que se registró la persona que está interactuando con el programa, además presenta de una forma
11
muy fácil datos importantes del proceso como flujos, SP, o valores de presión, temperatura y
demás que son críticos para el sistema. (Installing your DeltaV Digital Automation System,
2010)
Migraciones
Una migración se le llama al cambio de un sistema a otro. En el caso particular de esta práctica
sería el cambio de un sistema de Provox a un sistema de DeltaV. Pero estos no son los únicos
que existen, se puede pasar desde cualquier proveedor de servicios de control automático hacia
DeltaV, que es el sistema que utiliza Emerson.
Para el caso de estudio, que es la migración de un sistema desde Provox hacia DeltaV, se tienen
tres tipos principales: (CREEC, 2013)
 RYP/Replace: que a como lo indica su nombre es tomar el sistema entero y migrar todo
el hardware y todo el software de la empresa. Es la opción menos utilizada ya que
realizar todo el cambio en una sola etapa resulta muy costoso.
 I/O replacemente from Provox: se cambian las entradas y salidas del sistema, que es
básicamente un cambio en el controlador y sus entradas. En este caso se puede realizar
con una tecnología que se llaman Charms, con pequeñas tarjetas de entradas y salidas del
sistema que se montan en la rejilla (rack) a la par del controlador para tener la cantidad
exacta de AI/AO/DI/DO que se necesiten, en lugar de utilizar tarjetas de una cantidad
determinada de cada una de estas entradas.
 Flex Connect: se utiliza dejando el sistema sin tocar el cableado y lo que se hace es tomar
todas las entradas y salidas y acoplarlas a un dispositivo que se llama FlexConnect, el
cual traduce las señales desde el lenguaje de Provox hacia el de DeltaV, o viceversa.
Además de estos tipos de migraciones se tienen varios servicios que ofrece Emerson a la hora
de efectuar las migraciones. Se puede plantear una migración sólo del sistema gráfico de
Provox, con lo que se pasa de pantallas en 2D sin color, a pantallas con animaciones en
tercera dimensión y con los colores que se prefiera. Para esto lo que se utiliza es una versión
del programa DeltaV, programada exclusivamente para correr en un sistema Provox.
Además de esto se puede realizar una decodificación e implementación de lógicas de LCP y
12
FST’s. Esta última opción es la que se estuvo desarrollando en el proyecto en el cual se

realizó la presente práctica profesional. (CREEC, 2013)
CAPITULO 2: Métodos de Trabajo
En la práctica dirigida que se realizó en Emerson Engineering Center de Costa Rica, se planteó
obtener un aprendizaje escalonado a partir de experiencias en contacto con los compañeros de
trabajo además de las capacitaciones que se llevaron a cabo. Todo lo anterior con el fin de
interiorizar el conocimiento necesario para realizar migraciones de fases y unidades desde el
sistema de Provox hacia el sistema de DeltaV.
La forma en la que se planteó realizar este aprendizaje se refleja en los objetivos propuestos, los
cuales fueron aportando un poco más de conocimiento cada uno, hasta llegar a que sea posible
realizar una migración de una fase pequeña de no más de 200 líneas de código. Estos objetivos se
ven representados en la Figura 2.1 que se muestra a continuación.
Paso 1 Paso 2
Curso 7009 Asignación a un proyecto
(Introducción a la empresa) en el área de migraciones
Paso 4 Paso 3
Realización de diagramas Aprendizaje sobre los
de flujo en el programa lenguajes de programación
Visio
Paso 5 Paso 6
Revisión de fases migradas Migración de una fase de
por comparación Provox a DeltaV
Figura 2.1 Paso del aprendizaje escalonado propuesto para la práctica
13
14
Se inició con una inducción a la empresa, representado en el paso 1, en la que se conoció más a
fondo su funcionamiento y se adquirió el conocimiento para poder utilizar correctamente los
software DeltaV Explorer, Control Studio, Operate Configure y Operate Run, los cuales son las
herramientas más utilizadas por Emerson para sus tareas de ingeniería. Para cumplir con esto se
asistió a un curso de 40 horas en el que se dio una introducción sobre el uso de los mismos, al
terminar de llevar este curso se realizó un examen y el que se aprueba con una nota específica.
Con esto se recibió un certificado de cumplimiento de los objetivos de este curso.
Una vez que se obtuvo el conocimiento sobre estos programas, como funcionan y que se hizo
posible utilizarlos de una manera más fluida que no presentara muchas complicaciones a uno
como usuario, se continuó con el paso 2 en el que se asignó un equipo encargado de realizar un
proyecto dentro de la organización de Emerson. Este proyecto consistió en una migración de la
planta de un tercero el cual contrata a Emerson para que les brindara sus servicios. Esta fue una
empresa que tiene una planta localizada en Argentina que se dedica a la producción de
agroquímicos que por políticas de ambas empresas para fines de este proyecto se reservará el
nombre, de ahora en adelante se les llamará Empresa Contratista. El equipo de trabajo fue
liderado por un ingeniero de migraciones el cual supervisó el trabajo realizado.
Luego de aprender a utilizar los programas, se llevó a cabo el paso 3 que fue lograr una
familiarización con los lenguajes de programación que se utilizan tanto en Provox y en DeltaV.
La metodología a seguir para esta etapa del proyecto fue la de observar lógicas en ambos
sistemas que ya estuvieran completamente revisadas y aprobadas que fueron asignadas por el
líder del proyecto.
Una vez que se tuvo una idea de cómo es la estructura principal de ambos sistemas se continuó al
siguiente paso 4 en donde se realizaron unos diagramas de flujo en los que se trasladó lo que está
en la lógica de Provox. Esto se llevó a cabo a petición de la empresa contratista ya que ellos no
poseen el conocimiento necesario para poder interpretar lo que está en las lógicas de
programación en el programa Control Studio y necesitaban algún punto de referencia para
cambios posteriores o revisiones del sistema. Por lo anterior se efectuó un diagrama de flujo en
el que se fue mostrando paso a paso todas las acciones, esperas o transiciones que tiene cada
fase. Con la realización del diagrama de flujo de varias fases, se continuó mejorando el
15
conocimiento además del lenguaje utilizado para programar las especificaciones técnicas del
contratista. Esta interiorización sobre los lenguajes se pudo realizar ya que para poder dibujar
los diagramas de flujo, la base de donde se obtiene la información es el código en el lenguaje de
DeltaV, por lo que se pueden ir observando cómo son los estándares bajo los cuales se rige la
empresa contratista.
Cuando ya se tuvo el conocimiento suficiente en cuanto al lenguaje de programación en DeltaV,

se continuó con el siguiente objetivo del proyecto representado con el paso 5 en donde se revisó
el código de programación obtenido por la migración de una fase. En esta parte lo que se buscó
fue ir aprendiendo poco a poco como pasar de un código a otro, además de la forma en la que se
debían escribir los comandos y cuáles eran las principales expectativas del contratista. Para esta
revisión se tomaron en cuenta dos ejes principales los cuales se fueron revisando al mismo
tiempo, que no existieran problemas de forma o de fondo en cada una de las fases. Los
problemas de forma fueron principalmente errores en la escritura de algún comando, o algún
número de acción o paso que no fueran consistentes. Los problemas de fondo consistieron en
que no se falle sobre las especificaciones técnicas del contratista que se deben de seguir para
realizar la migración. Como un punto de aceptación se tuvo que si una fase cumplía en un 95%
estas características se aprobaba que se continuara a la siguiente etapa, que era una simulación
dinámica en la que se terminan de depurar los errores por otra persona. Se toma un 95% de
cumplimiento con los lineamientos por si existe algún error humano de pasar por alto alguna
indicación o una línea de código que aunque es muy difícil que suceda, se puede llegar a dar.
Por último, la culminación del proceso de aprendizaje estuvo dada por el sexto y último paso en
donde se realizó una migración de una fase simple, no mayor a 100 líneas de código, desde
Provox hacia DeltaV. En esta etapa se tuvieron que aplicar todos los conocimientos adquiridos
con anterioridad, para así programar una fase a partir del código que se tiene en Provox. Esta
fase fue revisada luego por una persona la cual constató que se hiciera de manera correcta y
luego una segunda persona la revisó por medio de una simulación dinámica en donde se probó
que la fase cumpliera con su propósito.
Durante la realización de la práctica para la distribución del trabajo y de las tareas, se utilizó una
hoja de Excel compartida en un servidor a la cual todos los involucrados con el proyecto podían
16
acceder desde sus ordenadores. Para este fin se le asignó a cada una de las personas involucradas
un código, como por ejemplo DMA para mi persona. Un ejemplo sobre este cuadro se puede
observar a continuación en el Cuadro 2.1. Con este formato de organización del trabajo lo que se
pretendía es que sólo una persona esté trabajando en una fase y que no se pierda el trabajo
realizado, es así como si en el cuadro salía EN PROCESO quiere decir que esa etapa no se ha
terminado y se estaba trabajando en ella, si sale SI quiere decir que ya el trabajo en esta fase
estaba concluido.
En el Cuadro 2.se tiene un ejemplo, sobre lo expuesto anteriormente, en donde se tienen dos
unidades, TFILT y WFILT. Estas unidades están compuestas de varias fases las cuales se pueden
observar en el Cuadro. Se puede ver como existen 6 columnas luego que indican que ingeniero
configuró cada fase, si esta ya fue corregida, quien fue la persona que la revisó, el estado de la
revisión, además de que persona realizó el diagrama en Visio y el estado del mismo, todo esto
respectivamente al orden mostrado en el Cuadro 2.1. De lo anterior se puede explicar por
ejemplo como la fase FILTRADO de WFILT fue configurada por el ingeniero JB, que ya fue
corregida y que está siendo revisada por el ingeniero DV, el cual todavía no finaliza su trabajo. O
también como la fase INICIAL de TFILT fue configurada por JB, que ya fue corregida, además
de que PI la revisó y DMA le realizó el diagrama en Visio. Este Cuadro 2.1 estaba además
pensado para que se llenara de izquierda a derecha sin saltarse ningún paso y una vez que
estuviera completo, la fase configurada estaba lista para entregarse.
En la realización de esta práctica se tuvieron varios puntos que se deben de destacar que
facilitaron el trabajo pero también surgieron ciertos inconvenientes y problemas que es bueno
mencionarlos para que en un futuro en ocasiones similares no se vuelvan a dar. A continuación
se muestran en forma de lista las principales dificultades y facilidades que se tuvo a la hora de
realizar el proyecto.
17
Cuadro 2.1 Ejemplo de distribución de trabajo

CONFIGURADA PROBADA FASE VISIO VISIO
UNIT FASE CORREGIDA
POR POR PROBADA POR REALIZADO
INICIAL JB SI PI SI DMA SI
LLENAR AV SI PI SI DMA SI
TURBIDEZ DV SI PI SI DMA SI
FILTRAR JB EN PROCESO
TFILT FILTRAR2 JB SI PI SI DMA SI
LAVADO DV SI PI SI DMA SI
DRAIN JB SI PI EN PROCESO
LAVADO2 JB SI PI SI DMA SI
HAS JB SI PI SI DMA SI
INICIAL PI SI JB SI DMA SI
LLENADO JB SI DV EN PROCESO
TURBIDEZ DV SI JB SI DMA SI
FILTRADO JB SI DV EN PROCESO
DRENAJE PI SI JB SI DMA SI
WFILT SECADO JB SI JB SI DMA SI
LISTO DMA SI JB SI DMA SI
DESCARGA JB SI JB SI DMA SI
LAVADO
HAS JB SI JB SI DMA SI
18
DIFICULTADES
 Una de las principales dificultades a la hora de avanzar con el proyecto consistía en que
al inicio al sólo estar capacitado para ciertas tareas no se podían realizar otras que eran
más urgentes como la configuración de fases. Por esto había momentos en los que la
carga de trabajo disminuía considerablemente mientras se estaba esperando por la
configuración y revisión de una fase por parte del equipo de trabajo para poder realizar el
diagrama de flujo.
 Se tuvieron problemas con la comunicación con Argentina, ya que se necesitaba que
aprobaran o dieran respuesta a preguntas realizadas o que enviaran información necesaria
para continuar trabajando y al no hacerlo a tiempo se tenía tiempo ocioso.
 Al ser la tecnología de Emerson algo muy específico la bibliografía disponible afuera de
la empresa es muy escaza. La mayor cantidad de información encontrada es sobre
manuales, libros y entrevistas a lo interno de Emerson.
FACILIDADES
 La disposición de las personas allegadas al proyecto hacia mi persona siempre fue la

mejor. Siempre estuvieron dispuestos a realizar explicaciones sobre los temas que no se
entendían o sobre lo que no se tuviera conocimiento. Con esta disposición se hizo
posible entender de una manera más rápida los conceptos relacionados a esta práctica
profesional.
 La empresa Emerson brindó todos los recursos necesarios para poder desempeñarme de
la mejor manera. Se proporcionó una computadora, con dos monitores necesarios para
realizar el trabajo, además de un lugar adecuado y todos los software que se necesitaron
incluyendo el Visio de Microsoft Office.
 Las personas que estuvieron en el equipo de trabajo estaban muy capacitadas y conocían
ampliamente el tema por lo que esto facilitó de gran manera el trabajo realizado.
Por último, esta práctica se realizó en una compañía que maneja términos muy técnicos y que
pueden resultar difícil de entender se procederá a explicar la principal terminología que se debe
de manejar para lograr un buen entendimiento de la presente práctica. Además en el Anexo A.1
19
se muestran en forma de un glosario. Lo primero que se debe de tener en cuenta es que DeltaV
es un sistema de control distribuido desarrollado por la empresa Emerson, utilizando una
arquitectura de planta digital (PlantWeb). Con este tipo de arquitectura se realiza una conexión
muy rápida y eficiente de los dispositivos del sistema, además de que se tiene un manejo de
planta muy confiable debido a esta misma robustez del sistema. Luego se tiene el significado de
Provox, que es un sistema de control distribuido desarrollado por Fisher-Rosemount el cual fue
el precursor del DeltaV.
Luego de entender los dos conceptos anteriores, hay ocasiones en las que se desea cambiar o
mejorar el control de una planta por medio de un cambio en su sistema de control automático, a
esto se le llama una migración. Por ejemplo cambiar de sistema desde Provox a DeltaV se le
llama una migración, como lo es el caso de esta práctica dirigida. Luego se tienen conceptos los
cuales ayudan a entender la manera en que se maneja la información tanto en el sistema DeltaV
como en el sistema Provox. Para esto lo principal sería poder distinguir entre lo que representa
una unidad (unit) y lo que representa una fase. Las fases son pequeñas agrupaciones de tanques,
bombas, válvulas, entre otras cosas, que son capaces de realizar alguna acción en conjunto. Para
utilizar una terminología de ingeniería química, se podrían ver como operaciones unitarias dentro
de la planta. Es así como por ejemplo se puede llegar a tener una fase que se llame lavado, en la
que se tengan todos los equipos necesarios para realizar la acción de lavado en un tanque
específico. Por último, el término de unidad es como se le llama a una agrupación de fases en las
que realizadas de una manera conjunta representan un proceso. Por ejemplo, se puede tener una
unidad que se llame filtrado en la que se agrupen las fases de inicio, lavado, filtrado y drenado.
En el ejemplo anterior cada fase realiza una acción individual que al juntarse y realizarse en
cierto orden, logran llevar a cabo la filtración de algún producto.
CAPITULO 3: Software de la Empresa Emerson
La empresa Emerson cuenta con un curso introductorio a sus sistemas y a lo que se realiza en el
área de ingeniería el cual tiene el nombre de DeltaV 700: DeltaV Operate Implementation I. Este
entrenamiento en su revisión 10 del 3 de marzo del 2009 se cursó en la primer semana de la
práctica dirigida en el mes de junio del 2012, para luego realizar un examen sobre lo aprendido el
cual se debía de pasar con una nota superior a 80 para que se tomara como aprobado. Este curso
es el primer acercamiento a lo que son los software y lo que se realiza en la empresa. Al ser algo
tan extenso, son realmente sólo conocimientos muy básicos de las aptitudes que se desean
desarrollar luego en los trabajadores, por lo que los meses siguientes consistieron también en un
aprendizaje continuo en el que se mejoraron las técnicas estudiadas en este entrenamiento. El
curso cuenta de 17 secciones en ingles que vienen a describir las funciones principales del
software DeltaV las cuales se indican a continuación:
1. Vista general de DeltaV (DeltaV Overview)

2. El proceso simulado (The simulated process)
3. Modulos de control en DeltaV (DeltaV Control Modules)
4. Configurando alarmas en DeltaV (Configuring DeltaV Alarms)
5. Control de motores en DeltaV (DeltaV Motor Control)
6. Control Regulatorio en DeltaV (DeltaV Regulatory Control)
7. Diagramas de función secuencial (Sequential Function Charts)
8. Control en cascada (Cascade Control)
9. Alarmas condicionales (Conditional Alarms)
10. Módulos de lógicas de fase (Phase Logic Modules)
11. Seguridad en DeltaV (DeltaV Security)
12. Complemento para Excel (Excel Add-in)
13. Interfase serial de DeltaV (DeltaV Serial Interface)
14. Interfase de la tarjeta RTD (RTD Card Interface)
15. Interfase de la tarjeta de termocupla (Thermocouple Card Interface)
16. Interfase de la tarjeta multifuncional (Multifunction Card Interface)
17. Soporte (Support)
20
21
Para efectos de lo que se realizó en la práctica, los que están resaltados en negrita son los que nos
aportarán la información más importante para sentar las bases teóricas sobre una migración de un
sistema en Batch como el que se realizó. A continuación se dividirá la discusión en cada una de
las secciones importantes mencionadas anteriormente.
DeltaV Overview
En esta sección se explica básicamente la arquitectura del sistema DeltaV, cuantos lazos de
control, controladores y estaciones de trabajo soporta entre otras generalidades importantes.
También habla sobre cómo es que se cuentan las licencias y como se otorgan a los clientes, pero
en esto no se entrará en detalle ya que es irrelevante para el desarrollo de la práctica dirigida. Lo
importante de esta sección es su introducción al software y los programas de DeltaV. Estos
programas se dividen en 2, los que están pensados para estaciones de usuarios (operarios) o los
que están desarrollados para la configuración de los procesos. Entre los programas que se tienen
para las estaciones de usuarios los más importantes son el Operate y el Configuration Suite. Por
otro lado los que se utilizan para la configuración son el DeltaV Explorer y el Control Studio. A
continuación se explicará cada uno de estos programas y sus funciones y para que se utilizan.
Operate
El programa tiene dos modos en los que se puede abrir que son corriendo (run) y en
configuración (configure). El primero es el modo en que los operarios lo utilizan en planta en
donde pueden observar y controlar el proceso. Es una pantalla que consiste en 3 áreas
principales que se observan en la Figura 3.1. Estas áreas son la barra de botones, el área de
trabajo y el banner de alarmas. El área de la barra de botones se puede ver arriba. Estos botones
sirven para navegar entre los gráficos, abrir alguno existente, o ir a otras funciones del programa.
El área de trabajo es donde se ve el dibujo que representa el proceso que se está controlando. En
esta área se puede ver información además de manipular válvulas, bombas, motores, o ingresar
datos cuando sea posible. Por último se tiene la barra de alarmas, que es la que está abajo, en
donde se tiene campo para 5 o 6 alarmas que se ponen en los cuadros que terminan con una i al
final. La cantidad de alarmas mostradas depende de la resolución de la pantalla que se está
utilizando. Acá se pueden observar las alarmas, silenciarlas, reconocerlas y además se puede
obtener toda la información disponible sobre la falla al darle click en la i.
22
Figura 3.1 Ejemplo DeltaV Operate Run

23
El segundo modo en el que se puede abrir este programa es en el cual se realizan los trabajos de
crear, configurar y editar los diferentes gráficos. En este modo no se tiene el área de los botones
ni la de alarmas como se tiene en el modo run. Lo que si se tiene es una visualización de todas
las pantallas con su nombre al lado izquierdo como se observa en la Figura 3.2. Además tiene
una barra de botones especiales para la configuración.
Figura 3.2 Ejemplo de DeltaV Operate Configure

24
Configuration Suite
Esta herramienta está diseñada para las personas con alta capacidad de toma de decisiones en la
empresa. Esto debido a que en este programa se configura la jerarquía de los usuarios y los
permisos que se le brinda a cada uno entre otras funciones. Esto es de suma importancia ya que
ciertos usuarios tendrán acceso sólo a un área en específica de la planta, lo que se traduce en que
a la hora de utilizar el DeltaV Operate Run sólo tendrán acceso limitado a cierta cantidad de
pantallas por usuario. Además de esto los usuarios se configuran en esta herramienta para que en
el banner de alarmas solo se vean las alarmas que son relevantes para esa persona. Esto permite
no distraer a los operarios con información no necesaria para que realicen sus labores de la mejor
manera.
DeltaV Explorer
Este programa se utiliza para ver y para editar toda la configuración del sistema. Se puede
accesar a otros programas de edición desde su pantalla principal y se pueden realizar una
cantidad muy grande de funciones del software DeltaV. En este programa se ve en cual
controlador estarán asignados los diferentes módulos de control, cuales son las unidades que lo
componen, sus distintas fases, además de todos los parámetros y su descripción. También en
este programa se realiza el conteo de las señales que entran y salen para cuestiones de licencias.
Es desde esa pantalla donde se cargan y descargan los datos y toda la información necesaria para
el funcionamiento de la planta, se puede decir que el Explorer es una conexión entre lo que se
realiza en la computadora y lo que se manda a la planta a los controladores y actuadores físicos.
Control Studio
Este programa es donde se pueden abrir las fases de cada unidad y ver su módulo de lógica de
fase (PLM) el cual, como se verá más adelante, consiste como lo dice su nombre en secuencias
que se utilizan para la programación de sistemas por tandas. En estos PLM se puede entrar en la
parte de ejecutar (run), que es donde viene la secuencia que se utiliza cuando la fase se encuentra
corriendo. Cuando se entra a esta secuencia lo que se observa es un diagrama de función
secuencial (SFC). Estos diagramas constan de transiciones y pasos, los cuales a su vez se
componen de acciones que son las que van realizando todos los cambios en el sistema. Es con
25
esta herramienta que se lleva a cabo toda la creación, configuración y programación de las fases
que, para fines de esta práctica, fue lo que se estuvo migrando del sistema Provox hacia DeltaV.
Sequencial Function Charts
Los diagramas de función secuencial se utilizan para realizar el control sobre un proceso que
tiene una secuencia de tiempo o de acciones. Está compuesto de tres partes principales como lo
son los pasos que son los que ejecutan las acciones, las transiciones que determinan cuando se
puede proceder al siguiente paso por medio de expresiones que deben ser evaluadas como
verdaderas y por último una terminación que es un símbolo especial de que la secuencia terminó.
En la Figura 3.3 se muestra un ejemplo de un SFC con la cual lo que se busca es ejemplificar la
forma que tienen estas secuencias, como pueden ser los saltos, las esperas, los pasos y como se
terminan.
Las acciones de cada paso pueden ser de tres tipos: Asignaciones, booleanos o no booleanos.
Las asignaciones como lo dice su nombre asignan el resultado de una expresión a un destinatario.
Los booleanos están referenciados a módulos con parámetros de este tipo y por último los no
booleanos se referencian a un bloque de función. Además estas acciones tienen un calificador
que va a ser el que determine el tipo de señal que mandan. Existen muchos de estos calificadores
por lo que sólo se explicarán los 4 que se utilizan luego en la migración que se realizó.
 D (Delayed): estas acciones se activan al cumplir con 2 condiciones, que el paso en el

que se encuentran este activo y que además el tiempo que se programó como retraso se
haya cumplido. Este tiempo puede ser un número o también puede consistir en una
expresión.
 P (pulse): Este es el tipo más utilizado que se utiliza como lo dice su nombre. Un pulso
en el que se manda una señal como un pulso no como algo continuo.
 S (set): también se dice que es un paso guardado ya que se activará cuando se active el
paso en el que se encuentra y parará de ejecutarse hasta que se reinicie más adelante.
 R (reset): Se utiliza para parar acciones que están guardadas.
La edición de las propiedades de las acciones además de un ejemplo de donde se escriben las
expresiones para realizar el control del proceso se muestra en la Figura 3.4.
26
Figura 3.3 Ejemplo de un diagramas de función secuencial

27
Figura 3.4 Ejemplo de edición de las propiedades de una acción
Estos diagramas de función secuencial pueden llegar a tener 2 tipos de caminos para continuar
con la lógica: los caminos divergentes y los caminos paralelos. Los primeros se indican con una
línea sencilla y los segundos se indican con líneas dobles.
Phase Logic Modules
Los módulos de lógica de fase son los que indican cuales son los estados en los que puede caer la
fase que se está programando además de la lógica que se asocia a cada uno de estos estados. En
la Figura 3.5 se observa un ejemplo de cómo se ve un módulo de este tipo. En esta figura se ve
como se tienen los estados de corriendo (running), parando (stopping), esperando (holding) o
abortando (aborting) que son las principales comandos que se pueden programar, los demás que
se observan son solo pasos intermedios que no requieren ser programados para que el programa
funcione correctamente, ya que su lógica de programación es estándar. Las SFC que se
explicaron anteriormente se encuentran programadas dentro de los 4 estados que se mencionaron
anteriormente. Para el caso específico de la migración realizada en esta práctica profesional, la
28
SFC para esperando, abortando y parando se configuro en una solo que se llamó HAS (hold-
abort-stop).
Figura 3.5 Ejemplo de un módulos de lógica de fase

CAPITULO 4: Diagramas de flujo de sobre el código en DeltaV
La parte de realizar los diagramas de flujo en el software Visio, no es algo muy común en
Emerson, esto se hace exclusivamente para proyectos en los que se utilizan los diagramas de
función secuencial (SFC) y que los clientes así lo especifiquen. Por lo general esto se da en
procesos por tandas (Batch). Debido a esto no existen estándares predefinidos por Emerson para
la realización de los diagramas Visio. Para obtener estas especificaciones lo que se siguió fue
una curva de aprendizaje en la cual se realizaron varias opciones y se enviaron a la empresa
contratista y ésta fue indicando como prefería que se fueran haciendo. Entre los aspectos que se
definieron fue el tamaño de las hojas las cuales serán del tamaño estándar A3. Además de la
forma, se realizaron consultas sobre el fondo en cuanto a cuál era la mejor manera para traducir
las acciones que se tenían programadas en DeltaV. Una vez que se realizaron y corrigieron los
gráficos y se afinaron estos detalles, se llego a un conjunto de especificaciones que fueron las
que se siguieron para la realización de los diagramas de flujo. Para explicar cuáles son estas
especificaciones primero se explicará una fase sencilla de no muchas líneas de código, en la que
se incluyan la mayor parte de los comandos utilizados. Para este propósito se tomará la unidad
TFILT238-UN, que tiene 6 fases: Inicial, llenar, filtrar, lavado, turbidez y HAS. La fase que se
utilizará para este fin será llenar.
En general se puede decir que los diagramas de flujo se confeccionaron a partir de 3 figuras
principalmente. La figura más utilizada será la de cajas rectangulares que especifican que se
lleva a cabo un paso según la lógica en DeltaV, como se puede observar a continuación en la
Figura 4.1.
Figura 4.1 Ejemplo de la figura utilizada para las acciones
Luego están los rombos que quieren decir que se llegó a una transición en la que se puede tomar
más de un camino dependiendo de una condición o una evaluación de alguna variable. Un
ejemplo de esto se presenta en la Figura 4.2
29
30
Figura 4.2 Ejemplo de la figura utilizada para las transiciones
Por último se tienen los trapecios que indican pausas en la lógica de control. Estos trapecios
pueden indicar una pausa ya sea por un tiempo definido de tiempo o hasta que una condición se
cumpla. La figura utilizada para esto se puede apreciar en la imagen de la Figura 4.3.
Figura 4.3 Ejemplo de la figura utilizada para las esperas
Además de esto para que queden claras las acciones que vienen programadas en cada paso en el
programa DeltaV se puso un cuadro a la derecha el cual lleva todas estas indicaciones. La fase
llenar que es la que utilizará para explicar estos conceptos consiste en 18 pasos y 23 transiciones.
Como en la Figura 4.4 se ve como al inicio de esta fase siempre se comenzará por una acción que
se llamará inicio de secuencia. Esta acción en el código de DeltaV no lleva nada programado por
eso es que no se pone nada en las indicaciones al lado derecho. Después de esto viene un paso
en el que en la lógica es mucho más compleja de lo que se ve acá, que es el de adquirir los
equipos compartidos. En el programa DeltaV se detalla cuales equipos se adquieren al inicio de
cada fase pero se llegó a la conclusión de que no era fundamental ponerlo ya que ocuparía
mucho espacio y no aportaría mucho a lo que se busca con estos diagramas. Luego viene otro
paso que se repite en casi todas las lógicas que es el de activar los HM y los SM. Estos son
equipos o situaciones que se deben de controlar ya que son vitales para el buen funcionamiento
de un proceso. Los SM lo que hacen es monitorear los equipos específicos que se sabe que
deben estar en correcto funcionamiento. Los HM lo que monitorean son situaciones en
especifico que no se deben dar. Tanto los SM y los HM son condiciones que de darse van a
31
parar el proceso. Después viene una acción muy importante en cada fase que es la de cambiar los
modos a cascada. Para esto la indicación que se pondrá en el programa Visio será de la forma,
REQ_MODE: (Nombre del equipo) := (modo)
en donde los valores entre paréntesis se llenarán según sea el caso. Además de esto la forma en
la que se indicará un cambio en un punto de consigna será a como se muestra a continuación,
REQ_SP: (Nombre del equipo) := (modo)
Siguiendo con el diagrama de flujo se observa como aparece la primera transición, que esta se
representan poniendo la condición en el cuadro de la derecha y las posibles respuestas sobre los
caminos que puede tomar. Entonces para este caso en particular,
P_FIRST_PASS = TRUE ?
si el valor de la variable P_FIRST_PASS es igual a true tomará el camino a su izquierda si esto

es falso tomará el camino hacia abajo. Entonces hasta acá se tienen un par de cosas importantes
para recalcar sobre la forma en la que se representaron las indicaciones de DeltaV en el programa
Visio y es que para escribir un valor se pone “:=” y para realizar una comparación se utiliza solo
“=”, que serán las dos indicaciones más importantes a la hora de elaborar los diagramas, ya que
son las formas de comparar variables o de escribirle un valor a alguna otra.
Luego de esto también se tienen más indicaciones como por ejemplo cuando se paran o se
habilitan los temporizadores, esto se indica en el diagrama en Visio con palabras, por ejemplo
para indicar que se va a parar el temporizador 1 se escribirá: “PARO TIMER 1”. En la lógica de
DeltaV se utilizan unos pasos vacios para que 2 transiciones seguidas no choquen ya que esto no
es permitido, a esto se le llama un DUMMY y al final el cliente decidió que quedaba a criterio de
la persona que realizaba el diagrama ponerlo o no ponerlo que a final de cuentas viene siendo
una cuestión más de espacio que de otra cosa. Es debido a lo anterior que en las fases más
sencillas en el Visio si aparecen los Dummy y que en los más complejos no. Luego de esto se va
a llegar a un trapecio el cual indicará una pausa. Las pausas son más complejas que las acciones
32
anteriores ya que pueden ser simplemente un tiempo predefinido o expresiones grandes que hasta
que se cumplan la lógica no continuara operando. Por ejemplo,
(TIMER 1 > P_TIME_SAVE + UP004 OR PV:FLTR_HILVL = TRUE)
indica que la lógica no continuara hasta que se cumpla alguna de las dos condiciones descritas
con anterioridad. Para estas condiciones se pueden utilizar los comandos como AND y OR
principalmente, aunque también en alguna ocasión se utiliza IF. Por último se tiene el manejo
que se le quiso dar a los mensaje que se muestran al operador, estos se dividieron en dos tipos:
los mensajes que solo son informativos o los que requieren algún tipo de interacción para obtener
alguna información. Los primeros se tratan igual que los temporizadores, simplemente se
describe con palabras la acción, como por ejemplo “MENSAJE 3”, quiere decir que se mostrará
en pantalla el mensaje número 3 de la lista de mensajes de esa fase. Los segundos son una
función del programa que se llama OAR, en el que se escribe un mensaje y se requiere una
respuesta por parte del operador, como por ejemplo:
OAR := LA FASE ESTA EN ESPERA, DESEA INICIAR?
Los comandos que se han explicado sobre su forma de escribirlos en Visio son los más utilizados
y fuera de casos poco comunes serán los únicos que aparezcan. Entre estos casos a parte están los
cálculos que se realizan simultáneamente a la lógica de control los cuales se habilitan al igual
que los temporizadores pero además en un cuadro aparte en una esquina del diagrama de Visio se
coloca todo el procedimiento de cálculo que se lleva a cabo. Además de esto, existen parámetros
que tienen más de una variable como lo son el PV (valor presente), CV (valor actual), REQ_SP
(valor de consigna requerido) entre otros. Si es fundamental para el entendimiento de la lógica el
poner cuál de estas variables es la que se está utilizando se realizará poniendo la abreviación
luego los dos puntos y después de esto el nombre del parámetro utilizado. Por ejemplo,
PV:FADSF
quiere decir que en esta parte de la lógica se estaría utilizando el valor presente de FADSF.
33
Esto que se explicó anteriormente se trata de lo que es una fase. Las unidades (units) se
componen de varias fases que se van ejecutando en cierto orden. Además de todas las fases
normales de operación, se tiene una especial que es la fase a la que se llega cuando el sistema
falla de alguna manera. Ya sea que entró a paro, o esta abortando o esperando. En esta fase por
lo general lo que se hace ese llevar los equipos a un modo seguro predeterminado. Por último,
en el archivo de Visio de cada unidad se pone una pestaña especial en donde van todas las
variables utilizadas en la fase con su descripción junto con una tabla con los mensajes OAR.
34
TASK
Page-1
INICIO
SECUENCIA
ACTION
ADQUIRIR EQUIPOS
ENABLE HM 1, 3, 5
ACTION
ENABLE SM 26, 27, 28, 39, 40, 41, 42, 44
REQ_MODE: FLTR_DRAIN : CAS

REQ_SP: FLTR_DRAIN : CERRADA
REQ_MODE: FDTK_OUT : CAS
REQ_SP: FDTK_OUT : ABRIR
REQ_MODE: FLTR_VENT : CAS
REQ_SP: FLTR_VENT : ABRIR
REQ_MODE: FILTER_DISCH : CAS
REQ_SP: FILTER_DISCH : CERRAR
REQ_MODE: FLT_SEAL_H20 : CAS
REQ_SP: FLT_SEAL_H20 : ABRIR
REQ_MODE: FLT_TO_EFT : CAS
ACTION
REQ_SP: FLT_TO_EFT : CERRAR
REQ_MODE: FDTK_FWDNEW : CAS
REQ_SP: FDTK_FWDNEW : ABRIR
REQ_MODE: FLTR_FWD : CAS
REQ_SP: FLTR_FWD : FFT
REQ_MODE: FLTR_HW : CAS
REQ_SP: FLTR_HW : CERRAR
REQ_MODE: FDTK_HW : CAS
REQ_SP: FDTK_HW : CERRAR
REQ_MODE: FLTR_AIR : CAS
REQ_SP: FLTR_AIR : CERRADA
S
TRANSITION P_FIRST_PASS = TRUE ?
P_FIRST_PASS := TRUE
REQ_SP: UP067 := UP061
ACTION INDICADOR DE TAREA := 1
PARO TIMER 1
TIMER 1 := 0
ACTION
REQ_SP: FLTR_STAT := LLENANDO
REQ_MODE: FDTK_P1_CTLR := ROUT

REQ_OUTP: FDTK_P1_CTRL := OP002
ACTION
REQ_OUTP: FDTK_P2_CTLR := OP002
S
TRANSITION PV:FDTK_PMP_SEL = TRUE
HABILITAR SM 4
ACTION
DESHABILITAR SM 5
REQ_SP: FDTK_P1 := MARCHAR
REQ_SP: FDTK_P2 := PARAR
HABILITAR SM 5
ACTION DESHABILITAR SM 4
Figura 4.4 Ejemplo de un documento en Visio sobre una fase en DeltaV

35
ACTION
REQ_SP: FLTR_STAT := LLENANDO

REQ_OUTP: FDTK_P1_CTRL := OP002
ACTION
REQ_OUTP: FDTK_P2_CTLR := OP002
S
TRANSITION PV:FDTK_PMP_SEL = TRUE
HABILITAR SM 4
ACTION
DESHABILITAR SM 5
HABILITAR SM 5
ACTION DESHABILITAR SM 4
ACTION DUMMY
(PV_D:FDTK_P1 = MARCHANDO OR
WAIT
PV_D:FDTK_P2 = MARCHANDO)
ACTION DUMMY
3 2
TRANSITION INDICADOR DE TAREA ?
1
INDICADOR DE TAREA := 1
INICIO TIMER 1
REQ_MODE: FLTR_SIG_SEL := AUT
ACTION
REQ_MODE: FLTR_FD_CTRL := ROUT
REQ_OUTP: FLTR_FD_CTLR := OP003
MENSAJE 102
WAIT (TIMER1 > UP003 OR PV:FLTR_HILVL = TRUE)

REQ_MODE: FLTR_FD_CTRL := ROUT
REQ_OUTP: FLTR_FD_CTLR := OP004
ACTION
P_TIME_SAVE := TIMER 1
MENSAJE 103
REQ_SP: FLTR_DISCH := ABRIR
WAIT (TIMER 1 > P_TIME_SAVE + UP004 OR PV:FLTR_HILVL = TRUE)
ACTION MENSAJE 0
INDICADOR DE TAREA := 2
ACTION REQ_SP: FLTR_VENT := CERRAR
REQ_MODE: FLTR_STAT := CAS
REQ_SP: FLTR_STAT := CIRCULAR
REQ_SP: BV012 := FALSE

ACTION TOT_RESET:TFILT_TOT11 := TRUE
BV013 := TRUE
TFILT_TURBIDEZ
Figura 4.4 (cont.) Ejemplo de un documento en Visio sobre una fase en DeltaV
CAPITULO 5: Revisión de fases migradas hacia DeltaV
La revisión de una fase ya migrada en el lenguaje de DeltaV se realiza por medio de una
comparación visual. Para esto se tendrá una lista de verificación la cual incluye los siguientes
puntos:
 Impresión de la fase escrita en Provox

 Con un marcador de un color definido tachar las partes que no se van a utilizar
 Ir con otro color de marcador revisando que todas las líneas que están en el código de
Provox se encuentren en DeltaV bien configuradas.
 Revisar según el documento que se encuentra en el anexo A.2 que los estados se hayan
migrado correctamente.
 Revisión final de la fase en DeltaV donde se ven aspectos sobre la forma más que el
fondo de la fase. Se revisa que la numeración de los pasos sea consecutiva y que dentro
de cada paso la numeración de las acciones también cumpla esto.
 Realizar una revisión de las variables y que a la hora de la migración se haya realizado
bien la correspondencia.
Antes de explicar cómo se realizó la revisión se expone a continuación el significado del último
punto de la lista anterior. A la hora de migrar las fases de un sistema a otro, existen unos
registros en Provox de la forma UV[#]. Estos registros cuando se migran a DeltaV son de la
forma UPXXXX . También están los registros normales en Provox que son los IXXXXXX o los
FXXXXXX que al igual que los UV se les asigna un valor en DeltaV. Para esto se lleva un
orden en un cuadro de Excel como el que se muestra en los Cuadros 5.1 y 5.2. En estos cuadros
se puede ver como existe una columna con el valor en Provox y en otra el valor que se le asigno
para DeltaV. Es importante recalcar que el número que tiene cada uno no es el mismo para
ambos registros en los dos programas, por lo que entonces se hace de suma importancia
confirmar que a la hora de realizar la migración se haya tenido cuidado con este detalle y que los
registros de estas variables no tengan ningún problema. La importancia de esto anterior se debe a
que al ser registros que en Provox tienen un número y luego en DeltaV tienen otro, a la hora de
realizar la migración de la fase se pueden cometer error muy fácilmente en esta etapa.
36
37
Cuadro 5.1 Ejemplo de asignación de registros UV en Provox

Registros PVX REGISTRO DELTA V
UV[1] UP043
UV[2] UP046
UV[3]
UV[4]
UV[5] UP041
UV[6] UP042
Cuadro 5.2 Asignación de registros I/FXXXXXX en Provox

Registro Unit Registro PVX
UP001 I020409
UP002 I020413
UP003 F020427
UP004 F020428
UP005 F020426
Por lo general los cambios que se deben de realizar a la hora de la revisión son mínimos y no
ocupan de mucho tiempo, por lo que la misma persona que la revisa se encarga de realizar esos
cambios. Cuando estos cambios si son más grandes y pueden llegar a tomar mucho tiempo, la
fase si se debe de rechazar y devolverla a la persona que la configuró para que la arregle. Por
último, se podría decir que la revisión final de la fase se realiza en planta, luego de que se haya
entregado la fase al cliente para que la prueben junto con el ingeniero a cargo del proyecto que
está realizando las pruebas. Acá lo que se hace es que el ingeniero en planta toma notas del
funcionamiento y junto con el cliente observan cómo se podría mejorar, y estos cambios si son
relevantes se envían de nuevo a la empresa Emerson, en Costa Rica para reconfigurar la fase.
Esto se continúa realizando hasta que el cliente esté satisfecho con el resultado y todas las fases
realicen su objetivo de la manera en que la empresa espera.
CAPITULO 6: Migración de una fase hacia DeltaV
Para la explicación de cómo realizar una migración de una fase desde Provox hacia DeltaV este
capítulo se desarrolla de la siguiente manera. Primero se exponen los principales conceptos que
se deben de saber sobre las fases en Provox, luego se presenta la lógica ya a como queda una vez
que se migró a DeltaV y por último se explica cómo pasamos de la lógica en Provox hacia la
lógica final en DeltaV. Esto con el fin de poder utilizar la lógica ya migrada como ejemplo.
Una migración de una fase como la que se realizó para este proyecto consiste básicamente en una
traducción de lo que se tiene en un programa y escribirlo en el lenguaje del sistema al que se
quiere migrar. Los lenguajes que se tienen en este caso es el lenguaje que utiliza Provox y el que
utiliza DeltaV. Entre ambos la mayor diferencia es que el primero se programa en líneas
consecutivas de texto, con gran similitud por ejemplo a como se programa en java. Por otro lado
el segundo se programa en diagramas de función secuencial que a como se ha explicado con
anterioridad constan de distintos pasos en los que se programan acciones. A la hora de comparar
los lenguajes en sí, la forma en la que se indican las acciones que se van a llevar a cabo y demás,
no difieren mucho entre sí. Esto es normal ya que ambos sistemas han sido desarrollados por la
misma compañía sin embargo presentan también muchas diferencias en aspectos de forma. Para
entender mejor estas diferencias primero se la forma en que se trabaja en Provox, ya que la forma
en que se trabaja en DeltaV ha sido explicada en este informe final sobre la práctica dirigida.
Para que sea más fácil entender la forma en la que se trabaja en Provox se utilizará de guía la
Figura 6.1. En esta figura se tiene una vista general de lo principal con lo que se trabajó a la hora
de migrar una fase desde este sistema hacia DeltaV. Las ventanas que se muestran en la figura
son las que dan la información necesaria sobre las operaciones que lleva a cabo la unidad además
de una fase ya abierta. Por ejemplo la ventana señalada con una flecha de color verde llamada
TFILT es la que mostrará las operaciones relacionadas a esta unidad. En las pestañas que se
tienen en la parte de arriba se muestran diferentes opciones para visualizar la información que se
tiene.
En la pestaña “Primary”, se tiene una descripción de la unidad, y se tienen los alias que serán
importantes a la hora de realizar la configuración. Luego está la pestaña de los pasos de esta
unidad, que en realidad vienen siendo las fases asociadas a esta unidad. En lo que resta de las
38
39
pestañas no se tiene información relevante que se deba considerar a la hora de migrar una fase.
Una vez que se tiene identificada la fase que se quiere migrar, se procede a abrirla. Para esto se
le da click al botón señalado con rojo, con este botón se abre la programación de la lógica que se
tendrá programada para esta fase. Esta ventana que se abre es la que se tiene marcada con color
amarillo.
40
Figura 6.1 Vista general de las fases y units en Provox

Una vez que ya se tiene una noción sobre cómo utilizar Provox, se procederá a realizar la
explicación de cómo migrar una Fase desde Provox hacia DeltaV. Para esto se utilizará una fase
de una complejidad baja pero que será muy rica en cuanto a su contenido ya que presentará la
mayoría de acciones que se utilizan a lo largo del proyecto como mensajes al operador, esperas,
bifurcaciones en el recorrido entre otras. Esta fase que se utilizará será la fase de LIST_TAMB
de la unidad WFILT. A continuación en la Figura 6.2 se presenta la fase programada en Provox.
0001: FAILEXP (((BREG[1]:'PC'= TRUE ) AND (IREG[6]:'PC'=SN)))

{
%%%%%%%%%%%%%%%%%%%%%%
1ST PASS LOGIC
%%%%%%%%%%%%%%%%%%%%%
}
0002: IF (UV[23]=UPHA, LABEL1)
0003: CONST (UV[25], 1) {SET TASK INDICATOR}
0004: DBI (UV[23], UPHA)
0005: CONST (SP:CAT_FIL_STAT, DESCARGA)
0006: CONST (MODE:FLTR_SIG_SEL, AUT)
{
%%%%%%%%%%%%%%%%%%%%%%%%
REQUEST PHASE GROUP MASK
%%%%%%%%%%%%%%%%%%%%%%%%
}
LABEL1:
0007: CONST (IREG[3]:PC, -7)
0008: GOSUB (PC SETUP)
0009: DBI (UV[29], UV[25])
0010: ONGOTO (UV29, TASK1, TASK2, LABEL99, LABEL99)
TASK1:
0011: CONST (MODE:DRUMLITE, COM)
0012: CONST (SP:DRUMLITE, INACTIVO)
Figura 6.2 Fase LIST_TAMB programada en Provox
41
42
0013: CONST (SP:COMP_LIGHT, NO)

0014: CONST (FPREG[3]:PC, 0.0) {Clear message flag}
0015: IF (PV:'DRUM_WEIGHT'<GFPREG[16]:'VAR', {Check for full drum}
LABEL60)
* CONST (BREG[25]:CT, FALSE) {Reset start button flag}
0016: YESNO (M8, 0, 0, BV16, FALSE, 0 S) {EL TAMBOR ESTA
LLENO, RESPONDER SI
CUANDO SEA
REEMPLAZADO}
0017: GOTO (TASK1)
LABEL60:
0018: CONST (FPREG[3]:PC, 103.0)
0019: WAITUNTIL ((PV:'DRUM_WEIGHT' < GFPREG[16]:'VAR')AND(PV:'1ZS364-10-2'=0), 1 S,
NOCWEN)
0020: CONST (SP:READY_LIGHT, SI)
TASK2:
0021: CONST (UV[25], 2)
0022: CONST (FPREG[3]:PC, 100.0)
0023: WAITUNTIL (PV:'FIELD_PB', 1 S, NOCWEN) {WAIT FOR FIELD OPERATOR
TO PUSH START}
0024: CONST (FPREG[3]:PC, 0.0) {Clear message flag}
0025: CONST (SP:READY_LIGHT, NO)
0027: CONST (SP:DRUMLITE, ENTAMBORANDO)
0028: WAIT (4 S, NOCWEN)
0029: CONST (SP:DRUM_VENT, ABIERTA)
0030: WAITUNTIL (PV:'DRUM_VENT' = 'ABIERTA', 0 S, NOCWEN) {Wait for drum vent to
open}
LABEL99:
0031: NEXT (DESCARGA)
Figura 6.2 (cont.) Fase LIST_TAMB programada en Provox

43
La fase LIST_TAMB configurada en DeltaV se presentará como la Figura 6.3 que es el

diagrama de función secuencial y las acciones que tiene programadas se irán explicando paso a
paso, además de que en la Figura 6.4 se presenta el diagrama de flujo en Visio para esta Fase.
Antes de comenzar a explicar cómo ir traduciendo el código, se presentarán algunas de las
indicaciones más importantes que se debían de tener en cuenta a la hora de realizar la migración
que fueron propuestas por el cliente tomando en cuenta en donde era que se presentaban los
fallos de las primeras ocasiones.
Estas indicaciones se enlistan a continuación:
 Trabajar con ORDEN, no sólo importa que las cosas funcionen, sino que también es muy
importante que se vean bien. Esto se aplica en el sentido de que no debe sobrar nada en
la programación, además de que en los SFC, se deben de tener líneas rectas y que en
general el documento se tenga ordenado.
 Los ACT, que son las acciones de cada paso no deben de tener más de una acción
configurada. Esto quiere decir que no se debe por ejemplo de cerrar dos válvulas en el
mismo ACT, con el fin de que esto facilite las cosas a la hora de revisar las fases o de
corregirlas por si presentan algún fallo. Las únicas acciones que se pueden poner más de
una en un mismo ACT son en las que se asignan valores a unas variables llamadas ups,
que lo único que hacen es almacenar valores.
 A la hora de configurar las válvulas se debe tener especial cuidado de si es una válvula
normalmente abierta o normalmente cerrada.
 Revisar que todo el código en Provox se encuentre programado en DeltaV.
Una vez que se tiene esto claro ya se puede continuar a migrar una fase de un sistema a otro.
Para esto lo último que queda explicar es cuando cambiar de ACT en la SFC. Esto se realiza una
vez que se llega a la cantidad máxima de memoria que tiene cada ACT o cuando se tiene una
bifurcación o una pausa en la lógica. Ahora para explicar el proceso de migración de una fase se
irá explicando cada línea del código de Provox y luego como se traduce esto hacia DeltaV.
44
Figura 6.3 Diagrama de función secuencial

45
Figura 6.3 (cont.) Diagrama de función secuencial

46
Antes de explicar línea por línea en Provox cabe aclarar que las primeras 3 cajas de acciones que
viene en la SFC mostrada en la Figura 6.3, que son Inicio de tarea, Adquisición de equipos y la
habilitación de HM y de SM no aparecen en Provox por lo que son algo exclusivo y que es
necesario para la programación en DeltaV. El primero de estos pasos no tiene ninguna acción
dentro, lo único que indica es que la fase está comenzando, luego el segundo paso es el mismo
para todas las fases del proyecto, en el que se adquieren los equipos necesarios para el
funcionamiento correcto de la fase. Luego está la habilitación de los HM y SM (Holding
monitor y Sentinel monitor) que se programa según la unidad con la que se está trabajando.
Luego de esto ya si se comienza con la lógica de Provox y se explicará a continuación que quiere
decir cada una de las líneas en este lenguaje y su traducción será asociada a lo que se tiene en el
diagrama Visio que se muestra en la Figura 6.4.
Línea 0001
0001: FAILEXP (((BREG[1]:'PC'= TRUE ) AND (IREG[6]:'PC'=SN)))

Esta línea no se pone en DeltaV por lo que no aparece nada relacionado a ella en la traducción de
DeltaV.
Línea 0002
0002: IF (UV[23]=UPHA, LABEL1)
Esta línea como lo dice en la lógica antes de ponerla se llama la lógica del primer paso (1st pass
logic). Los IF en Provox lo que hacen es realizar una evaluación de una condición y si esta se
cumple se brinca hacia la línea del código que se indica luego de la coma. Por ejemplo para este
caso, si la condición de que UV[23]=UPHA se cumple, se irá a la parte del código que se llama
LABEL1 y se brincará todo lo que está en medio. Estos casos en DeltaV no se programan como
acciones, sino como una transición que son las “cruces” que se ven entre cajas. Estas transiciones
lo que hacen es que dejan que la lógica continúe por el camino en donde están puestas sólo si se
cumple la condición que tiene programada. Entonces para programar un IF como este, se tienen
que poner dos transiciones en la que se programa en un lado una con la condición tal y como está
en Provox y en la otra completamente opuesta. Por lo que siguiendo con el ejemplo de lo que
está en la línea 0002 del código en Provox, las indicaciones serían UV[23]=UPHA y la otra
UV[23]!=UPHA. En donde en la primera se tiene la condición de que el UV[23] sea igual a un
valor, en para la segunda, más bien tenemos que el valor de UV[23] debe de ser distinto a UPHA
47
Figura 6.4 Diagrama de flujo de la fase LIST_TAMB

48
Líneas 0003, 0004, 0005 y 0006
0003: CONST (UV[25], 1) {SET TASK INDICATOR}

0004: DBI (UV[23], UPHA)
0005: CONST (SP:CAT_FIL_STAT, DESCARGA)
0006: CONST (MODE:FLTR_SIG_SEL, AUT)
Se explicaran todas estas líneas juntas ya que al no haber ninguna transición en medio de ellas o
alguna espera de tiempo, todas juntas conforman el paso S0040 de la lógica de DeltaV. Las
líneas 0003 y 0004 lo que hacen es asignarle al registro antes de la coma, el valor después de la
coma. Luego se tiene la acción 0005, la cual es una escritura de un punto de consigna. Para
esto, antes de escribirle el valor se debe de pasar el equipo a modo cascada, y luego escribirle el
punto de consigna “DESCARGA” a CAT_FIL_STAT. Por último la línea 006 lo que indica es
que se escribe al modo de este equipo y éste se cambia a AUTO, esto según la lista que ya se
explicó con anterioridad.
Líneas 0007, 0008, 0009 y 0010
0007: CONST (IREG[3]:PC, -7)

0008: GOSUB (PC SETUP)
0009: DBI (UV[29], UV[25])
0010: ONGOTO (UV29, TASK1, TASK2, LABEL99, LABEL99)
Las líneas 0007 y 008 no se migran a DeltaV debido a que el registro PC es un parámetro que
utiliza Provox que no hace falta poner en DeltaV, por lo que nunca se pone. Luego la línea 0009
tampoco se pone ya que como se puede ver se guarda el valor de un registro en otro registro, que
luego se utiliza abajo para realizar una comparación. Se llegó a la conclusión de que esto no era
necesario y sólo se realiza la comparación sin este paso ni esta variable intermedia para el caso
de DeltaV. Por último tenemos la línea 10 la cual se repite muchas veces en las distintas fases,
por lo que se le llamo el árbol del sistema. Esto debido a que la indicación ONGOTO lo que
hace es tomar UV[29] y si este valor es igual a 1 lo manda al TASK1, si es igual a 2 lo manda a
TASK2, y si es igual a 3 y 4 lo enviará a LABEL99, para este caso en particular. Para programa
esto en DeltaV lo que se utilizan son 3 transiciones en las que se pregunta si el valor es igual a 1,
2 o 3 y se envía el flujo hacia donde corresponda según sea el caso.
Líneas 0011, 0012, 0013 y 0014

49

0012: CONST (SP:DRUMLITE, INACTIVO)
0013: CONST (SP:COMP_LIGHT, NO)
0014: CONST (FPREG[3]:PC, 0.0)
De estas líneas, la única que se explicará será la 0014 ya que las demás no aportan nada nuevo a
la discusión. Esta línea lo que hace es escribir un mensaje, y en este caso en específico es más
bien borrar los mensajes que puedan estar guardados. Viéndolo estrictamente este paso lo que
hace es escribirle al registro FPREG[3]:PC el valor 0.0. Esto en el fondo lo que dice es que se le
está mostrando el mensaje 0.0, de una lista de mensajes definidos para cada unidad. Todas
tienen en común que el mensaje 0.0 es el que está en blanco.
Líneas 0015, *
0015: IF (PV:'DRUM_WEIGHT'<GFPREG[16]:'VAR', {Check for full drum}

LABEL60)
* CONST (BREG[25]:CT, FALSE) {Reset start button flag}
La línea 15 ya se explicó un caso con anterioridad. Pero la línea siguiente presenta un *, el cual
indica que la fase antes tenía esto configurado, pero debido a revisiones que se realizaron en la
empresa contratante por distintos motivos decidieron eliminarlo. Pero esta línea no se borra del
todo, sino que lo que se hace es ponerle un asterisco al inicio y con esto ya no se toma en cuenta
a la hora de que la lógica este corriendo.
Líneas 0016, 0017
0016: YESNO (M8, 0, 0, BV16, FALSE, 0 S) {EL TAMBOR ESTA

LLENO, RESPONDER SI
CUANDO SEA
REEMPLAZADO}
0017: GOTO (TASK1)
La línea 16 lo que realiza es mostrar el mensaje que se encuentra a la derecha y guarda el valor
que se mete en el registro BV16. Como este es un mensaje que requiere la interacción con el
usuario siguiendo lo que se había comentado con anterioridad, se utilizará lo que se llama un
OAR. Luego la línea 17 lo que indica es que el flujo por este camino se devuelve hacia el lugar
de la lógica en donde está TASK1.
50
Líneas 0019
0019: WAITUNTIL ((PV:'DRUM_WEIGHT' < GFPREG[16]:'VAR')AND(PV:'1ZS364-10-

2'=0), 1 S, NOCWEN)
La línea 0018 no se analiza pues ya se discutió antes y su interpretación no cambia a lo expuesto

con antelación. La línea 0019 lo que indica es que se realizará una pausa, hasta que se cumplan
las condiciones ahí descritas. Esta condición además será evaluada cada segundo y el NOCWEN
lo que indica es que esta espera no puede ser cancelada por el operador.
Líneas 0031
0031: NEXT (DESCARGA)
La línea 0031 es la última que llegará a aportar algo nuevo para discutir ya que todas las demás
son acciones que ya se describieron y que son repetidas. Esta línea (0031) es muy sencilla y lo
que hace es invocar la siguiente fase a la que va a llamar una vez que termine, para este caso será
la fase DESCARGA.
CAPITULO 7: CONCLUSIONES Y RECOMENDACIONES
CONCLUCIONES
 El curso 7009 que es la introducción a la empresa por parte de Emerson, intenta cubrir
una gran cantidad de materia y el tiempo que se le dedica es de apenas 40 horas, por lo
que para llegar a conocer realmente el funcionamiento de todos los software de la
empresa se requieren de meses de práctica y estar utilizándolos para lograr dominarlos de
una manera aceptable.
 La terminología técnica utilizada en el ámbito del control automático y más
específicamente la utilizada por Emerson puede llegar a ser muy compleja para personas
externas, por lo que con el trabajo cotidiano se logró el conocimiento necesario para
elaborar un glosario con toda la terminología a utilizar en el presente documento.
 Los lenguajes entre los códigos de Provox y DeltaV son muy similares, la diferencia más
grande entre ambos es la forma en la que organizan sus secuencias.
 La realización de los diagramas de flujo en el programa Visio fue el acercamiento más
adecuado para lograr un conocimiento profundo sobre la manera en que se programa el
código de las lógicas de control en el programa DeltaV.
 Como era de esperar, los primeros diagramas de flujo que se realizaron contenían muchos
errores de interpretación del código por lo que eran devueltos para su corrección, al final
de la curva de aprendizaje se logró tener una aprobación satisfactoria de todos los
diagramas en Visio realizados.
 El mayor cuidado que se debe de tener a la hora de migrar una fase de un sistema a otro
es realizarlo con un orden impecable, ya que si no se realiza de esta forma hay muchas
posibilidades de que se incurra en un error.
 Los pasos de la curva de aprendizaje trazados para poder llegar a lograr programar una
fase sencilla al final de la práctica dirigida fueron correctamente planeados y diseñados
ya que se logró cumplir este objetivo de una forma muy satisfactoria, realizando una
migración de una fase que fue aprobada tanto por los compañeros en Costa Rica como el
cliente en el exterior.
51
52
 Dentro de las lecciones aprendidas del proyecto se tuvo que no se debe de tener miedo a
preguntar cuando no se saben las cosas, ya que un cliente prefiere estar responder y
aclarar dudas a que se diga que todo quedó claro y cuando se entrega el producto el
resultado no es el deseado.
RECOMENDACIONES
 De ser posible realizar o programar un curso sobre fundamentos eléctricos necesarios

para sacar más provecho al curso 7009.
 Sistematizar de mejor manera los pasos que se siguen para la migración de una fase, para
que no existan diferencias entre la configuración de cada ingeniero.
 Definir con el cliente con anterioridad los lineamientos a seguir para la configuración de
los diagramas de flujo en el programa Visio, ya que varios fueron devueltos por cosas
muy simples como que el formato no les gustaba.
 Es muy recomendable siempre imprimir todos los códigos en el lenguaje de Provox que
se están migrando y realizar un esquema con todas las bifurcaciones, saltos y retrocesos
de la fase, así a la hora de programarla se tiene mayor claridad a la hora de realizar esta
tarea.
BIBLIOGRAFÍA
Arc Advisory Group. (2008). Emerson's Flexible Approach to control System Migration. USA:
Arc White Paper.
Centralised Logger (CLOG). User Manual. (1999). USA: Fisher-Rosemount Systems.
Defining a PROVOX system. (1999). USA: Fisher-Rosemount Systems.
DeltaV Digital Automation System. (2009). Austin: Emerson Process Management.
Getting Started With Your DeltaV Digital Automation System. (2010). Singapore: Emerson
Process Management.
Installing your DeltaV Digital Automation System. (2010). Singapore: Emerson Process
Management.
Installing your DeltaV SIS Process Safety System Hardware. (2010). Singapore: Emerson
Process Management.
Nethercutt, M., & Sutton, J. (01 de Julio de 2001). Control System Upgrade Centralizes Plant
Operations. Recuperado el 11 de Febrero de 2013, de Power Engineering:
http://www.power-eng.com
Patterson, M., & Smid, L. (2005). The Fisher Story: 125 years of process control experience.
Iowa: Fisher Controls International LLC.
Pederson, J. (2004). International Directory of Company Histories (Vol. 61). St. James Press.
PROVOX Process Management System Master Glossary. (1997). USA: Fisher-Rosemount

Systems.
Schnipke, E., & Nitriles, I. (May de 2008). Hot cutover boosts control system migration.
Chemical processing , 39-42.
The System Manager's Guide to ENVOX Server and Control Desktop. (2000). USA: Fisher-
Rosemount Systems.
The Technical Reference for ENVOX Server and Control Desktop. (2000). USA: Fisher-
Rosemount Systems.
53
ANEXOS
A.1 GLOSARIO
 Emerson: en el presente documento se utilizará está palabra con el fin de referirse a la

Empresa Mundial Emerson Electric, más específicamente a su división de Process
Systems and Solutions, sin hacer distinción entre Emerson Costa Rica o Emerson
Argentina.
 Contratista: Empresa de productos agroquímicos con una planta de producción en
Argentina, que contrata a Emerson para la migración de un sistema de Provox a un
sistema de DeltaV.
 DeltaV: DCS desarrollado por Emerson para el control de procesos. Utiliza una
arquitectura de planta digital PlantWeb.
 Provox: DCS desarrollado por Fisher-Rosemount para el control de procesos. Funciona
con una arquitectura de sistema de control distribuido.
 Migración: Una migración es el cambio de un sistema de control por otro.
 Unit: grupo de fases que se ejecutan en cierto orden para así lograr un objetivo en el
proceso. Por ejemplo una Unit que se llama TFILT239, tendrá varias fases para así poder
llegar a realizar el filtrado
 Fase: Para términos de ingeniería química podría llamarse como una de las operaciones
unitarias que componen una Unit. Con el ejemplo anterior, tenemos que las fases de
TFILT239 son: Inicial (que siempre se llama de esta manera a la primer fase de una unit),
llenar, filtrar, lavado y por último turbidez. Además hay una fase que se llama HAS, que
también siempre está presenta, que es la rutina de fallo de cada unit.
54
55
A.2 HOJA PARA LA REVISION DE LOS ESTADOS

56
A.3 CERTIFICADO DE APROBACION DEL CURSO 7009

Universidad de Costa Rica: Facultad de Ingeniería

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Universidad de Costa Rica: Facultad de Ingeniería

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE COSTA RICA

Desarrollo de las habilidades necesarias para migrar un sistema de control automático

Informe de práctica dirigida de graduación sometida a la consideración de la Escuela de

Daniel Eduardo Mata Barrantes

Ciudad Universitaria Rodrigo Facio

Informe de práctica dirigida de graduación sometida a la consideración de la Escuela de

Ing. Ad o Ulate Brenes, M. Se.

Maut'f í\. (?rd.ºhil=____

Dr. Benito A. Stradi Granados

Luego de finalizada mi practica dirigida y de haber redactado mi trabajo final de graduación, es

INDICE DE FIGURAS................................................................................................................ viii

CAPITULO 1: Marco Teórico ........................................................................................................ 3

Lógicas de control en Provox ................................................................................................. 5

Principales instrucciones para la programación de FSTs ..................................................... 5

CAPITULO 2: Métodos de Trabajo ............................................................................................. 13

CAPITULO 3: Software de la Empresa Emerson ........................................................................ 20

DeltaV Overview ....................................................................................................................... 21

Configuration Suite ............................................................................................................... 24

DeltaV Explorer .................................................................................................................... 24

Control Studio ....................................................................................................................... 24

Sequencial Function Charts ...................................................................................................... 25

Phase Logic Modules ................................................................................................................ 27

CAPITULO 5: Revisión de fases migradas hacia DeltaV ............................................................ 36

CAPITULO 6: Migración de una fase hacia DeltaV .................................................................... 38

CAPITULO 7: CONCLUSIONES Y RECOMENDACIONES................................................... 51

A.1 GLOSARIO ......................................................................................................................... 54

A.2 HOJA PARA LA REVISION DE LOS ESTADOS ............................................................... 55

A.3 CERTIFICADO DE APROBACION DEL CURSO 7009 ................................................... 56

Figura 3.1 Ejemplo DeltaV Operate Run ...................................................................................... 22

Figura 3.2 Ejemplo de DeltaV Operate Configure ....................................................................... 23

Figura 3.3 Ejemplo de un diagramas de función secuencial ......................................................... 26

Figura 3.4 Ejemplo de edición de las propiedades de una acción ................................................ 27

Figura 3.5 Ejemplo de un módulos de lógica de fase ................................................................... 28

Figura 4.1 Ejemplo de la figura utilizada para las acciones ......................................................... 29

Figura 4.2 Ejemplo de la figura utilizada para las transiciones .................................................... 30

Figura 4.3 Ejemplo de la figura utilizada para las esperas ........................................................... 30

Figura 6.1 Vista general de las fases y units en Provox................................................................ 40

Figura 6.2 Fase LIST_TAMB programada en Provox ................................................................. 41

Figura 6.2 (cont.) Fase LIST_TAMB programada en Provox ...................................................... 42

Figura 6.3 Diagrama de función secuencial .................................................................................. 44

Figura 6.3 (cont.) Diagrama de función secuencial ...................................................................... 45

Figura 6.4 Diagrama de flujo de la fase LIST_TAMB ................................................................. 47

Cuadro2.1 Ejemplo de distribución de trabajo ............................................................................. 17

Cuadro 5.1 Ejemplo de asignación de registros UV en Provox .................................................... 37

Cuadro 5.2 Asignación de registros I/FXXXXXX en Provox ...................................................... 37

El presente trabajo se concentra en el resultado de una práctica profesional en donde se

La práctica se enfocó en brindar el apoyo a una migración de un sistema en Provox a un sistema

adquisición de otras empresas y un crecimiento internacional. Durante 20 años se adquirieron la

cantidad de productos relacionados a la automatización industrial. Ofrecían una gran variedad de

Lógicas de control en Provox

A la hora de realizar la configuración de las estrategias de control, por lo general un algoritmo

Principales instrucciones para la programación de FSTs

Un registro electrónico en Provox es un dispositivo lógico secuencial que puede llegar a

 ACQUIRE: con este comando se adquieren recursos compartidos, lo más común en

Ejemplo: CALCULATE (C1, UV[11], 1+UV[10], 1). En el ejemplo anterior, el primer

 SCALCULATE: se utiliza para que la rutina que se comenzó con CALCULATE

Ejemplo: CONST(UV[10], 0), lo que quiere decir la expresión anterior es que se le

 EXPRESSION: funciona igual que CALCULATE, sólo que no tiene ni el primer ni el

Ejemplo: ONGOTO(UV[29], TASK1, TASK2, TASK3, LABEL 99). La expresión

 TIMER: inicia un cronometro de la unidad, que mide el tiempo transcurrido en

 DeltaV Explorer: es la herramienta principal de configuración, representa todo el sistema

 Fácil configuración de I/O: siempre que un controlador o un dispositivo se conecta a la