https://www.editores.com.ar/revistas/aa/12/yokogawa_desafio_no_convencionales
lunes, 12 de agosto de 2019
domingo, 25 de mayo de 2014
Advance automation in an oilfield ?
Digital Oilfields is collaboration with
production in focus (using the most extensive and technological use of the
collaboration term). Undoubtedly automation, instruments and control discipline
is a key player, from the base to the top of the automation pyramid inside an
oilfield initiative: From the instruments, control, HMI .. passing through the
special operation application up to the high level applications, reports and
key performance indicators.
Sometimes we tend to think about advance automation or advance operation applications, just when we talk about downstream in the oil & gas market. What happen with upstream? (From the production well, up to the inlet refinery flange). Is the upstream linked just with tele-supervision, single control loops and simple HMI interfaces?
Today,
thanks to the digital oil field requirements, new technologies and companies
thirsty of competitiveness, there is a lot of points in the oilfield with a
high degree of advance automation,
complexity or advance operation applications. Not only in the base or
first steps of the pyramid, sometime in the middle application or in higher
levels.
We will take a look to classic, specific and advance Automation applications and features in upstream that contribute to digital oilfields:
Some of the classic Automation application in upstream :
o Surface installations monitoring and control
o Process plants (treatment, injection, compression etc.) control
o Process plants Safety Systems
o Production wells (ESP, PCP, Mechanical, plunger lift, gas lift, Rotaflex etc.) monitoring and basic control.
o Remote measurement points monitoring
o Oilfield SCADA
o Pipelines monitoring and control (oil, gas and water)
o Electric power (generation and distribution) measurement, monitoring and control
PumpOff / Rof Pump Controller / Advance production well control :
o Real time well control and protection
o Surface and down hole dynamometric card
o Torque analysis
o Goodman analysis
Specific Automation application in upstream :
o Other wells advance control
o PCP (Progressive Cavity Pump)
o ESP (Electro Submergible Pump)
o Plunger Lift
o Gas Lift
o Injection well
o Other
o Pipe lines
o Leak detection and location (different techniques)
o Liquids administration
o Batch track
Advanced Automation application and advance features needed in upstream :
o Well test : There is a variety of well test technologies. Each apply in different oilfields and conditions. The advanced well test applications need to deal with four stages inside the digital oilfield initiative: To program the test, to execute the test, to control the test, to view and analyze the results. Other important issue is to integrate with other oilfield components : Telemetry wells, information production system, maintenance system etc.
o Oilfield balance : For a better understanding of the oilfield behavior, and with regard to optimize the production, you need to know how much oil, water and gas are you extracting, injecting, moving, storing, selling, buying, burning, treating, modifying and losing. The oilfield balance (in a partial o total way) finally joint the measurements from the well head, well test in battery, treatment plants, pipe lines, internal measurements and sales point, obtaining the overall efficiency and field factors. Some required features in a Oilfield balance : Flow balance, API corrected or energy balanced as appropriate. For digital oilfield contribution, the balance need to be flexible in information management. Linked with other corporative applications, integration with GIS, web deployment, multiple search filters etc. The measurement points, should be easily configured from the own balance interfaces. Recreate calculus (like AGA 3, AGA 10 e.g.), to corroborate the measurement, identify failures or supplement the computer instrument. Advance calculus like dew point or other chromatography relative calculus. Historical, current and predictive balances. Corrections by pressure, temperature, density. API compliance.
o Downtime management : In a small oilfield, or with a few production well control technologies and rotating machines, is easy manage the downtime. But in huge oilfields, and with several lift machines, injection pumps, air coolers and/or other rotating machines, became a real challenge. Image an oilfield with 4000 well, 12 or 14 different control lift technologies. How to keep the downtime metered and under control?.
o SNMP Telemetry : In an oilfield with 1000 wells or more, probably you will have 1200 control devices in a network or more. Count servers, workstation, printers and others devices too. To know the health of each site all the time will be a need . Some advance application, like the described before, will need the status of each site to know how to proceed.
o Sites administration and maintenance: Following with the same example, in an oilfield with 1000 wells or more, 12 or 14 different lift control technologies, you will add or modify the production wells (and control technologies) may be up to four to ten times a day. You will deploy this changes in the local HMI, the SCADA database, the relational databases, the historical databases and so on .. Up to 24 man hours for each new or modified well technologies will be used. Is a battalion of people, and you can make mistakes. There is some techniques to deploy it in a few steps, been do for a single maintenance operator.
o Alarm management: The amount of alarms generated are tremendous. Surely a study and an alarm management system based on the EEMUA 192 or ISA 18.2 is needed.
o High availability : The oilfield nonstop. The systems in the digital oilfield also not be stopped. Like in other systems, there is different techniques to guaranty the availability. The final selected solution depend of different conditions. Fault tolerance, hot or cold standby are some of the techniques more widely used in oilfields.
o High level report and KPIs : Almost at the top of the pyramid, the high level report and KPIs. Designed according with the business process, people and technologies, following the “life cycle” to obtain the better “dashboard” for the oilfield operation in the short, medium and long term.
o Special databases :An oilfield telemetry not only use huge real time databases. In such application are also used relational databases, time-indexed databases and multidimensional / data warehouse databases oriented to BI.
How automation is linked with a digital oilfield initiative: Regardless if it is a classic, advance or specially I&C solution for upstream, the important part is that the solution meet with the final objective decide through the Project Life Cycle, designed starting with the evaluation of the business process, people and technologies.
No one individual vendor has developed an unique solution for a digital oilfield, and our clients know it. The spectrum of need and possibilities are enormous. Some vendors are developed partial solutions or specialized isolated technologies. To have access to independent assessment at this point is a solution, developing concepts, engineering, design, integrating parts and development the final solution from an independent point of view. Even in disciplines or services not mentioned or nor identified yet ...
Sometimes we tend to think about advance automation or advance operation applications, just when we talk about downstream in the oil & gas market. What happen with upstream? (From the production well, up to the inlet refinery flange). Is the upstream linked just with tele-supervision, single control loops and simple HMI interfaces?
We will take a look to classic, specific and advance Automation applications and features in upstream that contribute to digital oilfields:
Some of the classic Automation application in upstream :
o Surface installations monitoring and control
o Process plants (treatment, injection, compression etc.) control
o Process plants Safety Systems
o Production wells (ESP, PCP, Mechanical, plunger lift, gas lift, Rotaflex etc.) monitoring and basic control.
o Remote measurement points monitoring
o Oilfield SCADA
o Pipelines monitoring and control (oil, gas and water)
o Electric power (generation and distribution) measurement, monitoring and control
PumpOff / Rof Pump Controller / Advance production well control :
o Real time well control and protection
o Surface and down hole dynamometric card
o Torque analysis
o Goodman analysis
Specific Automation application in upstream :
o Other wells advance control
o PCP (Progressive Cavity Pump)
o ESP (Electro Submergible Pump)
o Plunger Lift
o Gas Lift
o Injection well
o Other
o Pipe lines
o Leak detection and location (different techniques)
o Liquids administration
o Batch track
Advanced Automation application and advance features needed in upstream :
o Well test : There is a variety of well test technologies. Each apply in different oilfields and conditions. The advanced well test applications need to deal with four stages inside the digital oilfield initiative: To program the test, to execute the test, to control the test, to view and analyze the results. Other important issue is to integrate with other oilfield components : Telemetry wells, information production system, maintenance system etc.
o Oilfield balance : For a better understanding of the oilfield behavior, and with regard to optimize the production, you need to know how much oil, water and gas are you extracting, injecting, moving, storing, selling, buying, burning, treating, modifying and losing. The oilfield balance (in a partial o total way) finally joint the measurements from the well head, well test in battery, treatment plants, pipe lines, internal measurements and sales point, obtaining the overall efficiency and field factors. Some required features in a Oilfield balance : Flow balance, API corrected or energy balanced as appropriate. For digital oilfield contribution, the balance need to be flexible in information management. Linked with other corporative applications, integration with GIS, web deployment, multiple search filters etc. The measurement points, should be easily configured from the own balance interfaces. Recreate calculus (like AGA 3, AGA 10 e.g.), to corroborate the measurement, identify failures or supplement the computer instrument. Advance calculus like dew point or other chromatography relative calculus. Historical, current and predictive balances. Corrections by pressure, temperature, density. API compliance.
o Downtime management : In a small oilfield, or with a few production well control technologies and rotating machines, is easy manage the downtime. But in huge oilfields, and with several lift machines, injection pumps, air coolers and/or other rotating machines, became a real challenge. Image an oilfield with 4000 well, 12 or 14 different control lift technologies. How to keep the downtime metered and under control?.
o SNMP Telemetry : In an oilfield with 1000 wells or more, probably you will have 1200 control devices in a network or more. Count servers, workstation, printers and others devices too. To know the health of each site all the time will be a need . Some advance application, like the described before, will need the status of each site to know how to proceed.
o Sites administration and maintenance: Following with the same example, in an oilfield with 1000 wells or more, 12 or 14 different lift control technologies, you will add or modify the production wells (and control technologies) may be up to four to ten times a day. You will deploy this changes in the local HMI, the SCADA database, the relational databases, the historical databases and so on .. Up to 24 man hours for each new or modified well technologies will be used. Is a battalion of people, and you can make mistakes. There is some techniques to deploy it in a few steps, been do for a single maintenance operator.
o Alarm management: The amount of alarms generated are tremendous. Surely a study and an alarm management system based on the EEMUA 192 or ISA 18.2 is needed.
o High availability : The oilfield nonstop. The systems in the digital oilfield also not be stopped. Like in other systems, there is different techniques to guaranty the availability. The final selected solution depend of different conditions. Fault tolerance, hot or cold standby are some of the techniques more widely used in oilfields.
o High level report and KPIs : Almost at the top of the pyramid, the high level report and KPIs. Designed according with the business process, people and technologies, following the “life cycle” to obtain the better “dashboard” for the oilfield operation in the short, medium and long term.
o Special databases :An oilfield telemetry not only use huge real time databases. In such application are also used relational databases, time-indexed databases and multidimensional / data warehouse databases oriented to BI.
How automation is linked with a digital oilfield initiative: Regardless if it is a classic, advance or specially I&C solution for upstream, the important part is that the solution meet with the final objective decide through the Project Life Cycle, designed starting with the evaluation of the business process, people and technologies.
No one individual vendor has developed an unique solution for a digital oilfield, and our clients know it. The spectrum of need and possibilities are enormous. Some vendors are developed partial solutions or specialized isolated technologies. To have access to independent assessment at this point is a solution, developing concepts, engineering, design, integrating parts and development the final solution from an independent point of view. Even in disciplines or services not mentioned or nor identified yet ...
lunes, 17 de marzo de 2014
How automation meets the modern digital oilfields
We
have enough budget, the needs are identified and people fascinated with the
automation initiative as part of the digital oil field project or program. We
decided the level of automation, designed it and started to implement
instruments, PLCs, communications links and SCADA systems to obtain as much information
as possible from the field... This sounds familiar to you?
Many
of the best automation initiatives -inside a Digital Oil Field project- start
in this way. This approach is possible due to a lot of knowledge acquired in
the past in a fast way. Most of these projects finished successfully at the
end. It is natural, and it is not unique in the automation / digital
oil field spheres.
Today we learn to start a project from the
other side; from the business need, analyzing the business process, the people,
the technology and how to obtain the best workflows to optimize the results.
And from this point, start to decide the best designs. Also, we learn to follow
the project life cycle, like it has been done in other industries or projects.
This is especially applicable in huge oil fields in terms of extension, amount
of productive wells, amount of injection water, CO2 or chemical wells, amount
of people or complexity. Each one of these complexities, make your project
unique.
But what is hiding behind this life cycle,
referred to the automation applied to digital oil fields? 
Let´s analyze each point, not the meaning
or use, but taking a look at the particularities of this cycle in this kind of
complex projects:
"Business
process improvement expectation”: The cycle starts
here? Not necessarily. Sometimes the expectation is aligned with
long term plans, the best way to match with this point, is trying to
synchronize each life cycle turn, with the long term plans, your current
situation and the technologies obsolescence. Depending on other factors, 5 to
10 years I think is an appropriate range.
"Vision": Is company's vision aligned with a fully digital and automated oil
field? OK, let's move forward.
"Survey
and visualization": In first instance, we are evaluating
not only the current company technologies, people and workflows. We are taking
a look at the market too. Are your local distributors ready to provide a good
service in the following years? Do you have access to independent assessment
when needed?
"Situational
gap analysis": With these expectations,
visions, current situations in terms of technologies and people ’I want to
be there'.
"Diagnosis": Here we are preparing ourselves for the next step. Please sit back,
and take your time to identify the cause of the phenomenon happening in the
organization. This diagnosis will really help you to design an automation level
(as part of your digital field) that really matches with your organization
culture, the technologies available and the process being used (or being
identified to be modified). At this point, we need to ask us a
question; what consequences will automation bring?
"Conceptualization
and work plan" and "Engineering and development plan": this is the easiest part. Are you an automation specialist? OK,
let´s do your part. But .. I have 3 words starting with A to be taken into
account over the whole process. Align, Align and Align. Align your concept and
design with your vision. Align your concept and design with the people, the
process and the technologies. And don't forget, align your conceptual/design
developing people to do the best job. Here we need to ask some more questions:
Will automation reduce or eliminate the gaps? What is the automation level
needed to achieve the objectives? Can it be automated today?
"Change
management and implementation”: Ready to start up ... Wait, wait! We are not ready yet. When we
were thinking in an automated oil field, aligned with people, workflows,
current and new technologies, we were thinking in the gap that we are
covering. At the startup point, this gap should be managed in an
orderly and planned manner. Change management is the best solution. As in the
first stage of the initiative and over the whole project, keep in mind the
operators, maintenance, telecommunication, IT, RRHH people, and all your
stakeholders. Don't see the change management in automation as bureaucracy working
against you. Look at it as a tool that will protect you, and will help to
achieve the project objectives in a steadily way. Do the change management as a
project itself. A successful change management is as easy as a well-documented
description of the current situation before the change, the situation during
the change, the situation after the change, and keeping the stakeholders in the
loop.
"Knowledge
transfer”: You will be there because you will be
part or the whole project, or will you be there at the end or at the beginning
of the life cycle? The knowledge transfer from the design or implementation
team to the people (maintenance, IT, workflow key players etc.) is not just
training; it´s keeping these personnel in the strategic loop. Are you ready to
be part of a new improvement cycle?
"Measurement
and control”: Yes! Here we are. Automation from the
base of the pyramid. We are the right team to allocate the information needed
to complete this cycle. We can measure in "real time” and control the
cycle in small cycles tending to achieve the expectation.
Undoubtedly automation is a key player,
from the technologies side, to achieve digital oil field results in a fast way.
In a huge digital oil field initiative, it is not suitable to approach the
project from the classical control systems point of view. Instead of that,
using the life cycle and new approaches linked with business process,
technologies and people will be a right decision.
miércoles, 25 de agosto de 2010
Una mirada al ciclo de vida en la gestión de alarmas.-
En este caso, lo que presento es una mirada o interpretación de la EEMUA Publicación 191 (y de alguna forma de la ISA 18.2). Mas bien es una sugerencia sobre como implementar los servicios en gestión de alarmas a lo largo de su ciclo de vida. En el diagrama se puede ver los distintos estados de esta interpretación, que de alguna forma puede ser visto como "servicios" :
Filosofía de Alarmado
La “filosofía de alarmado” es el documento principal del sistema de alarmas, donde se precisará completamente la estrategia de alarmado. En este documento se definirá como configurar el sistema, medir continuamente la eficacia del sistema y auditar el sistema en un proceso que deberá repetirse a lo largo del ciclo de vida de la planta o proceso.
El objetivo de generar una filosofía de alarmas es un punto de partida para posteriormente -mediante la configuración adecuada- lograr una reducción de alarmas ruidosas, avalanchas de alarmas, alarmas en cascada, mensajes o indicaciones inadecuados en lugar de alarmas, gran cantidad de alarmas de alta prioridad o alarmas que se encuentran por largos períodos activas en el sistema sin motivo alguno, haciendo que el sistema en su conjunto garantice que se encuentra controlado en todo momento, dentro de los parámetros de seguridad.
La “filosofía de alarmado” contiene a grandes rasgos los siguientes puntos:
• Requerimientos generales.
• Definición de responsabilidades.
• Resumen de cuestionarios iniciales
• Definición de variables que deben generan alarma o alertas.
• Diagrama de variables alarmadas y alarmables.
• Definición de áreas de alarmas y asignación de cada variable a áreas.
• Definición de prioridad de cada alarma. Diagrama de distribución de las prioridades.
• Recomendaciones de configuración de límites de alarmas.
• Definición de respuestas ante la aparición de una alarma.
• Definición de respuestas ante la malfunción de un instrumento.
• Estándares de colorización para mostrar alarmas.
• Campos que se muestran en el alarmero.
• Filtros y forma de visualización en cada estación de trabajo.
• Análisis de variables dependientes para manejo de avalanchas descripción de “Gestión en Tiempo Real. Predictivo”.
• Descripción de indicadores claves para “control y gestión”.
• Documento de “auditoría”.
Una vez definida la "filosofía de alarmado" se puede proceder a la implementación de esta en el sistama, basado en la estrategia definida, tanto para el caso de sistemas nuevos, como para sistemas que se hayan implementado sin esta filosofía de alarmado y que de alguna forma la aplicación deba migrarse a esta nueva estrategia.
Informe Base
El “informe base” sirve como documento origen o punto de referencia para cualquier medición posterior que se realice. EEl “informe base” se puede realizar en dos instancias: Previamente a la implementación de cualquier cambio o mejora, como medio para demostrar la necesidad de un sistema de alarmado basado en una filosofía de alarmado gestado por medio de una estrategia. O posteriormente a la implementación de un sistema para medir desde el momento cero las mejoras que se producen en el sistema a lo largo de su ciclo de vida.
El “informe base” (ya sea previo o posterior a la implementación) se realiza en función de los indicadores descriptos en la “Filosofía de alarmado.” El "Informe Base" es fundamental para medir el GAP entre el antes y el después. En función de este GAP, desde la realidad a lo deseado, se puede realizar un adecuado "Manejo del Cambio".
Estudio de mejoras y capacitación
El “estudio de mejoras y capacitación” se encuentra íntimamente ligado a los indicadores que nos permiten medir la performance del sistema, es decir el “reporte base” en primera instancia y los indicadores del sistema de “control y gestión”. Estos indicadores nos permitirán conocer en cada momento que puntos mejorar en la forma en que se opera el sistema, en como se setean los niveles de alarma, la forma en que se reacciona ante un problema o incidente etc. El “estudio de mejoras”, mediante la adecuada lectura de los indicadores, permitirá realizar una “capacitación” focalizada. El “estudio de mejoras y capacitación” incluye también una serie de cuestionarios sugeridos.
Como parte del ciclo de vida del sistema de alarmas, se sugiere realizar el “estudio de mejoras y capacitación” en forma periódica mediante un plan. Dependiente la magnitud y complejidad del sistema, cantidad de operadores y demás variables de contorno, es recomendable realizar esta actividad cada 6 meses o 1 año. En principio el primer “estudio de mejoras y capacitación” se puede realizar inmediatamente posterior a haber realizado la implementación.
Auditoría
La fase de “auditoría” se encuentra íntimamente ligada a la “filosofía de alarmado” y a la implementación sobre el sistema. Durante la confección de la “filosofía de alarmado” se habrá confeccionado un documento de “auditoría”, que indicará cual es el procedimiento para chequear que el sistema no se haya degradado o apartado de lo especificado en la “filosofía de alarmado”. La “auditoría” no aplica sobre la forma en que las personas operan el sistema, sino sobre el sistema mismo.
El agregado de un equipo, la modificación de instrumentos o diferentes actividades pueden hacer que el sistema sufra modificaciones. La “auditoría” será la encargada de garantizar que el sistema siga cumpliendo con los requerimientos descriptos en la “filosofía de alarmado”, y prevendrá de cualquier degradación, indicando las acciones que se deben realizar para llevarlo a su estado original.
Dependiendo la magnitud y complejidad del sistema, dinámica de cambios e intervenciones que se realizan etc, es recomendable realizar esta “auditoría”cada 6 meses o un año, preferentemente previamente al “estudio de mejoras y capacitación”. La primer “auditoría” no es necesario que se realice posteriormente a la implementación, ya que el sistema se encuentra en su plena concordancia con la “filosofía de alarmado”. Es recomendable realizar la primer “auditoría” previo del segundo ciclo de “estudio de mejoras y capacitación”.
Control y gestión
El “control y gestión”, al igual que el “informe base”, se realiza partiendo de los indicadores descriptos en la “filosofía de alarmado”. Estos indicadores permitirán medir la performance de uso del sistema para realizar los ajustes necesarios sobre la operación y como punto de partida para los “estudios de mejora y capacitación”. Los indicadores obtenidos del “control y gestión” se podrán comparar como punto de partida con los indicadores obtenidos inicialmente en el “informe base”. El “control y gestión” también permitiría eventualmente realizar estadísticas o revisión de incidentes que son muy valoradas para la toma de decisiones a largo plazo.
Los sistemas de alarmas generalmente utilizan un “log” para el almacenado histórico de las alarmas y acciones realizadas. Este es uno de los puntos de partida para la generación de indicadores de gestión mediante un sistema. Sin embargo no todos los indicadores pueden ser generados a partir del log. Es por eso que se necesita de un sistema externo que permita gestionar esta información y generar los indicadores de gestión.
Por ejemplo, sin queremos contar la cantidad de alarmas presentes en un momento dado, analizando una sección de este log, es posible que estemos excluyendo algunas de las alarmas presentes en ese momento. Por otro lado, si se requiere mirar indicadores de semanas, meses o años el archivado de datos debe ser suficientemente grande para contener toda esta información. Para superar esto se debe realizar una mejora a este log, mediante el uso de una base de datos externa que además haga un tratamiento diferente de la información (base de datos del tipo datawarehouse). Esta base de datos se carga en forma continua con información proveniente de distintas fuentes, y previamente tratada mediante un mecanismo llamado ETL (Extraction, Treatment and Load). Esta base de datos es la fuente para los indicadores de gestión que son mostrados para la toma de decisiones.
Gestión en tiempo real - Predictivo
En búsqueda de cumplir con los objetivos de reducción de avalanchas de alarmas, alarmas en cascada, reducción de cantidad de alarmas totales aparecidas etc. es posible aplicar una serie de técnicas adicionales como complemente a una buena gestión de alarmas. Estas técnicas suelen ser “agrupado” (aunque esta primera no contribuye a la reducción de alarmas), “supresión” (por fuera de servicio, modo de operación, eventos etc), “detección inteligente” (reconocimiento de patrones etc), “equipos bajo test” entre otras técnicas.
Dependiendo la cantidad de instalaciones del sistema, magnitud de las mismas, complejidad etc. dependerá el tipo de lógicas a aplicar y el sistema que pueda o deba resolver la “gestión de alarmas” en tiempo real. Las lógicas a aplicar para cada sistema habrán sido convenientemente definidas en la “filosofía de alarmado”. Los sistemas que resolverán la problemática podrán ser desde sistemas dedicados a esta función (con lógicas booleanas, redes neuronales, fuzzy logic etc.) o bien implementaciones de lógicas de simple a mediana complejidad sobre el mismo sistema de control de la planta.
Filosofía de Alarmado
La “filosofía de alarmado” es el documento principal del sistema de alarmas, donde se precisará completamente la estrategia de alarmado. En este documento se definirá como configurar el sistema, medir continuamente la eficacia del sistema y auditar el sistema en un proceso que deberá repetirse a lo largo del ciclo de vida de la planta o proceso.
El objetivo de generar una filosofía de alarmas es un punto de partida para posteriormente -mediante la configuración adecuada- lograr una reducción de alarmas ruidosas, avalanchas de alarmas, alarmas en cascada, mensajes o indicaciones inadecuados en lugar de alarmas, gran cantidad de alarmas de alta prioridad o alarmas que se encuentran por largos períodos activas en el sistema sin motivo alguno, haciendo que el sistema en su conjunto garantice que se encuentra controlado en todo momento, dentro de los parámetros de seguridad.
La “filosofía de alarmado” contiene a grandes rasgos los siguientes puntos:
• Requerimientos generales.
• Definición de responsabilidades.
• Resumen de cuestionarios iniciales
• Definición de variables que deben generan alarma o alertas.
• Diagrama de variables alarmadas y alarmables.
• Definición de áreas de alarmas y asignación de cada variable a áreas.
• Definición de prioridad de cada alarma. Diagrama de distribución de las prioridades.
• Recomendaciones de configuración de límites de alarmas.
• Definición de respuestas ante la aparición de una alarma.
• Definición de respuestas ante la malfunción de un instrumento.
• Estándares de colorización para mostrar alarmas.
• Campos que se muestran en el alarmero.
• Filtros y forma de visualización en cada estación de trabajo.
• Análisis de variables dependientes para manejo de avalanchas descripción de “Gestión en Tiempo Real. Predictivo”.
• Descripción de indicadores claves para “control y gestión”.
• Documento de “auditoría”.
Una vez definida la "filosofía de alarmado" se puede proceder a la implementación de esta en el sistama, basado en la estrategia definida, tanto para el caso de sistemas nuevos, como para sistemas que se hayan implementado sin esta filosofía de alarmado y que de alguna forma la aplicación deba migrarse a esta nueva estrategia.
Informe Base
El “informe base” sirve como documento origen o punto de referencia para cualquier medición posterior que se realice. EEl “informe base” se puede realizar en dos instancias: Previamente a la implementación de cualquier cambio o mejora, como medio para demostrar la necesidad de un sistema de alarmado basado en una filosofía de alarmado gestado por medio de una estrategia. O posteriormente a la implementación de un sistema para medir desde el momento cero las mejoras que se producen en el sistema a lo largo de su ciclo de vida.
El “informe base” (ya sea previo o posterior a la implementación) se realiza en función de los indicadores descriptos en la “Filosofía de alarmado.” El "Informe Base" es fundamental para medir el GAP entre el antes y el después. En función de este GAP, desde la realidad a lo deseado, se puede realizar un adecuado "Manejo del Cambio".
Estudio de mejoras y capacitación
El “estudio de mejoras y capacitación” se encuentra íntimamente ligado a los indicadores que nos permiten medir la performance del sistema, es decir el “reporte base” en primera instancia y los indicadores del sistema de “control y gestión”. Estos indicadores nos permitirán conocer en cada momento que puntos mejorar en la forma en que se opera el sistema, en como se setean los niveles de alarma, la forma en que se reacciona ante un problema o incidente etc. El “estudio de mejoras”, mediante la adecuada lectura de los indicadores, permitirá realizar una “capacitación” focalizada. El “estudio de mejoras y capacitación” incluye también una serie de cuestionarios sugeridos.
Como parte del ciclo de vida del sistema de alarmas, se sugiere realizar el “estudio de mejoras y capacitación” en forma periódica mediante un plan. Dependiente la magnitud y complejidad del sistema, cantidad de operadores y demás variables de contorno, es recomendable realizar esta actividad cada 6 meses o 1 año. En principio el primer “estudio de mejoras y capacitación” se puede realizar inmediatamente posterior a haber realizado la implementación.
Auditoría
La fase de “auditoría” se encuentra íntimamente ligada a la “filosofía de alarmado” y a la implementación sobre el sistema. Durante la confección de la “filosofía de alarmado” se habrá confeccionado un documento de “auditoría”, que indicará cual es el procedimiento para chequear que el sistema no se haya degradado o apartado de lo especificado en la “filosofía de alarmado”. La “auditoría” no aplica sobre la forma en que las personas operan el sistema, sino sobre el sistema mismo.
El agregado de un equipo, la modificación de instrumentos o diferentes actividades pueden hacer que el sistema sufra modificaciones. La “auditoría” será la encargada de garantizar que el sistema siga cumpliendo con los requerimientos descriptos en la “filosofía de alarmado”, y prevendrá de cualquier degradación, indicando las acciones que se deben realizar para llevarlo a su estado original.
Dependiendo la magnitud y complejidad del sistema, dinámica de cambios e intervenciones que se realizan etc, es recomendable realizar esta “auditoría”cada 6 meses o un año, preferentemente previamente al “estudio de mejoras y capacitación”. La primer “auditoría” no es necesario que se realice posteriormente a la implementación, ya que el sistema se encuentra en su plena concordancia con la “filosofía de alarmado”. Es recomendable realizar la primer “auditoría” previo del segundo ciclo de “estudio de mejoras y capacitación”.
Control y gestión
El “control y gestión”, al igual que el “informe base”, se realiza partiendo de los indicadores descriptos en la “filosofía de alarmado”. Estos indicadores permitirán medir la performance de uso del sistema para realizar los ajustes necesarios sobre la operación y como punto de partida para los “estudios de mejora y capacitación”. Los indicadores obtenidos del “control y gestión” se podrán comparar como punto de partida con los indicadores obtenidos inicialmente en el “informe base”. El “control y gestión” también permitiría eventualmente realizar estadísticas o revisión de incidentes que son muy valoradas para la toma de decisiones a largo plazo.
Los sistemas de alarmas generalmente utilizan un “log” para el almacenado histórico de las alarmas y acciones realizadas. Este es uno de los puntos de partida para la generación de indicadores de gestión mediante un sistema. Sin embargo no todos los indicadores pueden ser generados a partir del log. Es por eso que se necesita de un sistema externo que permita gestionar esta información y generar los indicadores de gestión.
Por ejemplo, sin queremos contar la cantidad de alarmas presentes en un momento dado, analizando una sección de este log, es posible que estemos excluyendo algunas de las alarmas presentes en ese momento. Por otro lado, si se requiere mirar indicadores de semanas, meses o años el archivado de datos debe ser suficientemente grande para contener toda esta información. Para superar esto se debe realizar una mejora a este log, mediante el uso de una base de datos externa que además haga un tratamiento diferente de la información (base de datos del tipo datawarehouse). Esta base de datos se carga en forma continua con información proveniente de distintas fuentes, y previamente tratada mediante un mecanismo llamado ETL (Extraction, Treatment and Load). Esta base de datos es la fuente para los indicadores de gestión que son mostrados para la toma de decisiones.
Gestión en tiempo real - Predictivo
En búsqueda de cumplir con los objetivos de reducción de avalanchas de alarmas, alarmas en cascada, reducción de cantidad de alarmas totales aparecidas etc. es posible aplicar una serie de técnicas adicionales como complemente a una buena gestión de alarmas. Estas técnicas suelen ser “agrupado” (aunque esta primera no contribuye a la reducción de alarmas), “supresión” (por fuera de servicio, modo de operación, eventos etc), “detección inteligente” (reconocimiento de patrones etc), “equipos bajo test” entre otras técnicas.
Dependiendo la cantidad de instalaciones del sistema, magnitud de las mismas, complejidad etc. dependerá el tipo de lógicas a aplicar y el sistema que pueda o deba resolver la “gestión de alarmas” en tiempo real. Las lógicas a aplicar para cada sistema habrán sido convenientemente definidas en la “filosofía de alarmado”. Los sistemas que resolverán la problemática podrán ser desde sistemas dedicados a esta función (con lógicas booleanas, redes neuronales, fuzzy logic etc.) o bien implementaciones de lógicas de simple a mediana complejidad sobre el mismo sistema de control de la planta.
domingo, 22 de agosto de 2010
Gestión de Alarmas.-
Los sistemas de alarmas
Los sistemas de alarmas constituyen un elemento central de casi todas las interfases modernas de operación en plantas y procesos industriales, incluyendo refinerías de petróleo, plantas de generación de energía, plantas petroquímicas, instalaciones de superficie en yacimientos entre otras. Tradicionalmente estos sistemas se encontraban basados en sistemas cableados con lámparas de indicación y paneles de anunciación. Los sistemas modernos usan dispositivos de visualización por computadora para presentarle al operador gráficas o listas de texto de las alarmas, aunque en muchos casos los sistemas tradicionales no han dejado de utilizarse.
La alarma indica un problema que requiere atención del operador. Generalmente la alarma se inicia con una medición del proceso, que cuando se acerca a un valor no deseado o potencialmente peligroso es anunciado de diversas maneras.
Los sistemas de alarmas son hoy fundamentales para monitorear las condiciones de la planta o el proceso, y de atraer la atención del operador hacia cambios importantes que requieren de su evaluación, atención o toma de acción. El sistema de alarmas deberá ayudar al operador a mantener la planta dentro de un nivel de operación seguro, para corregir situaciones potencialmente peligrosas antes de que intervenga el sistema de paro de emergencia. Reduciendo la necesidad de acción por parte del sistema de paro de emergencia estaremos aumentando la seguridad de la planta. También pueden existir situaciones, aunque muy infrecuentes, donde la planta pueda comenzar a desviarse hacia estados hacia los cuales el paro de emergencia ya no será capaz de actuar en forma eficiente. También casos en que las acciones del operador, posteriormente a la aparición de una alarma, estén explícitamente diseñadas como medidas de protección seguras. El sistema de alarmas también ayudará a identificar condiciones no deseadas que puedan acarrear pérdidas de producción, o condiciones complejas difíciles de evaluar de otra manera. Las alarmas son una de las herramientas mas importantes de diagnóstico con las que el operador cuenta, y constituyen uno de los diversos recursos que utiliza frente a un contratiempo. Un buen sistema de alarmas tendrá también una función secundaria, pero no menos importante, mediante sus registros históricos de alarmas como ayuda a la optimización de la planta o proceso, para el análisis de incidentes y como medio también para la mejora continua del sistema de alarmas.
Actualmente los sistemas de control (DCS, sistemas híbridos SCADA-PLC etc.) disponen de una gran versatilidad para la configuración y gestión de alarmas, como resultado de esto las plantas con sistemas automatizados pueden operar cerca de límites que nunca antes se hubieran pensado, reduciendo los tiempos de paro, incrementando la productividad y sobre todo protegiendo las personas y el medio ambiente.
Cuando el sistema de alarmas no funciona adecuadamente
Defectos en los sistemas de alarmas, su implementación o su uso pueden generar multitud de pequeños efectos e incidentes que incrementan el riesgo de las personas, de la planta o proceso e incrementan el costo de operación. Si bien en accidentes graves que han habido en la industria es difícil establecer cuánto los sistemas de alarmas hubieran contribuido a evitarlos, la información de las alarmas ha sido generalmente esencial en otros casos para evitarlos, además de permitir un análisis posterior exhaustivo.
Los sistemas actuales, con mucha versatilidad, permiten la configuración de múltiples alarmas para cada medición, lo que resulta en una mayor cantidad de alarmas posibles que la cantidad de instrumentos que existen en la planta o proceso. El trabajo del sistema de control es mantener el proceso dentro de los rangos óptimos y seguros de funcionamiento. El trabajo del operador es mediar e intervenir para mantener el proceso dentro de esos rangos. Generalmente cuando el proceso sale fuera de sus rangos normales, prevalece el desorden. La habilidad que el conjunto sistema de control–operador tengan para responder eficientemente durante estos eventos pueden hacer la diferencia entre minimizar el tiempo de paro o un evento catastrófico.
El operador y el diseño del sistema en función de su rol
Las tendencias mas comunes son dar mayor responsabilidad y poner mayor presión sobre el operador.
Si a esto sumamos que el rol de un operador en plantas o procesos modernos abarca una variedad de actividades muy amplias tales como la operación de la planta, la optimización de la producción, la identificación de fallas, la coordinación del mantenimiento etc, la situación es aún más preocupante. El papel del operador durante una situación anormal puede ser muy complejo.
El sistema de alarmas es un sistema de apoyo a la operación, por lo que debe tener muchas características básicas, principalmente orientadas a la respuesta del operador y encontrarse diseñado de acuerdo a sus capacidades. Si una condición dada en el proceso no necesita que el operador tome una acción, entonces probablemente no debería haber una alarma asociada a esa condición. El sistema deberá intentar la atención del operador sobre las alarmas mas importantes, proveer mensajes claros y entendibles permitiendo poner foco en aquellas problemáticas mas importantes sobre las que tiene que realizar alguna acción. El sistema debe ser relevante al rol que en el momento tiene el operador, indicar claramente cuál es la respuesta esperada, presentar las alarmas a una velocidad que el usuario pueda manejar siendo además fácil de entender. El objetivo en este sentido es lograr un sistema de alarmas que evite que el operador piense que una alarma puede ser ignorada; todas las alarmas deben tener una respuesta definida y debe dársele tiempo al operador a que pueda llevarla a cabo.
Evaluando la inversión en un nuevo sistema de alarmas o su rediseño
Durante las etapas de construcción, o durante el posterior ciclo de operación y mantenimiento de una planta o proceso, se invierten grandes cantidades de dinero en ingeniería, construcción, modificaciones, definición de estrategias de control y seguridad. Sin embargo muchas veces se desatienden las inversiones necesarias en un componente indispensable como es el sistema de alarmas. La inversión inicial en diseño de sistemas debe ser suficiente para evitar los problemas operacionales y los riesgos en seguridad, medioambiente y economía que generalmente surgen, y que dan como resultado costos mayores durante toda la vida útil. Deben seleccionarse estrategias apropiadas para asegurarse de que los sistemas de alarmas estén creados con niveles de calidad adecuados a la planta o proceso que operamos y protegemos, y alineadas con los demás componentes que han sido diseñados para estos objetivos.
Normas internacionales y las mejores prácticas en gestión de alarmas
Una de las referencias mas utilizadas actualmente en la industria para la gestión de alarmas -en cuanto a recomendaciones prácticas basadas en experiencias- es el documento publicado por EEMUA (The Engineering Equipment and Materials Users’ Association) – Publication 191 (Alarm Systems – A Guide to Desing, Management and Procurement y de mas reciente publicación la ISA 18.2 -2009 “Management of Alarm Systems for the Process Industries”. Estos documentos están basados en experiencias y en un amplio estudio del factor humano, las que se deben tener en cuenta en la configuración de alarmas individuales, configuración de sistemas de alarmas o diseño/rediseño de sistemas de alarmas.
Decidir si la alarma debe clasificarse como alarma de seguridad será un paso importante a tener en cuenta para cada una de ellas durante el diseño de la filosofía de control. Para ello se deberá tener en cuenta las definiciones dadas en la norma internacional IEC 61508. La decisión acerca de si la alarma está relacionada con seguridad se verá afectada también por la legislación nacional y por prácticas existentes en el sector de la industria. La evaluación de riesgo proporciona un punto de partida en el proceso de diseño. Posteriormente se deben considerar aspectos más amplios de diseño: Selección de los ajustes de alarmas, cómo deben definirse y establecerse prioridades, cómo deben procesarse las alarmas para hacerlas tan significativas como sea posible, selección de las áreas de alarmas (lógicas o físicas). Todo ello deberá estar correctamente documentado en la “filosofía de alarmas” que será el punto de partida para configurar el sistema, entrenar al personal, medir continuamente la eficacia del sistema y auditar el sistema en un proceso que deberá repetirse a lo largo del ciclo de vida de la planta o proceso.
Identificando síntomas
Sobre sistemas ya en funcionamiento, existen muchas manifestaciones sobre el sistema mismo que se deben mirar para reconocer si estamos teniendo una gestión de alarmas ineficiente : Alarmas ruidosas, avalanchas de alarmas, alarmas en cascada, mensajes o indicaciones inadecuados en lugar de alarmas, gran cantidad de alarmas de alta prioridad o alarmas que se encuentran por largos períodos activas en el sistema son algunos de los síntomas que nos pueden llevar a pensar que algo no está funcionando correctamente. Muchas veces los sistemas de alarmas no son sensibles al contexto operativo en que se encuentra la planta en un momento dado. Algunas señales que pueden ser alarma en un estado de operación de la planta, puede que no sean relevantes o que no requieran atención del operador en otros estados.
Es común en la industria del Oil&Gas encontrarse con sistemas donde un operador debe lidiar a diario con 1500 o 2000 alarmas diarias de distintas prioridades, con un muy alto porcentaje de alarmas de prioridad Alta, muy lejos de lo esperado. Los operadores se encuentran en este escenario atendiendo por día hasta diez veces más de alarmas de las que razonablemente puede atender, en una forma de trabajo normalmente caótica.
Los sistemas de alarmas constituyen un elemento central de casi todas las interfases modernas de operación en plantas y procesos industriales, incluyendo refinerías de petróleo, plantas de generación de energía, plantas petroquímicas, instalaciones de superficie en yacimientos entre otras. Tradicionalmente estos sistemas se encontraban basados en sistemas cableados con lámparas de indicación y paneles de anunciación. Los sistemas modernos usan dispositivos de visualización por computadora para presentarle al operador gráficas o listas de texto de las alarmas, aunque en muchos casos los sistemas tradicionales no han dejado de utilizarse.
La alarma indica un problema que requiere atención del operador. Generalmente la alarma se inicia con una medición del proceso, que cuando se acerca a un valor no deseado o potencialmente peligroso es anunciado de diversas maneras.
Los sistemas de alarmas son hoy fundamentales para monitorear las condiciones de la planta o el proceso, y de atraer la atención del operador hacia cambios importantes que requieren de su evaluación, atención o toma de acción. El sistema de alarmas deberá ayudar al operador a mantener la planta dentro de un nivel de operación seguro, para corregir situaciones potencialmente peligrosas antes de que intervenga el sistema de paro de emergencia. Reduciendo la necesidad de acción por parte del sistema de paro de emergencia estaremos aumentando la seguridad de la planta. También pueden existir situaciones, aunque muy infrecuentes, donde la planta pueda comenzar a desviarse hacia estados hacia los cuales el paro de emergencia ya no será capaz de actuar en forma eficiente. También casos en que las acciones del operador, posteriormente a la aparición de una alarma, estén explícitamente diseñadas como medidas de protección seguras. El sistema de alarmas también ayudará a identificar condiciones no deseadas que puedan acarrear pérdidas de producción, o condiciones complejas difíciles de evaluar de otra manera. Las alarmas son una de las herramientas mas importantes de diagnóstico con las que el operador cuenta, y constituyen uno de los diversos recursos que utiliza frente a un contratiempo. Un buen sistema de alarmas tendrá también una función secundaria, pero no menos importante, mediante sus registros históricos de alarmas como ayuda a la optimización de la planta o proceso, para el análisis de incidentes y como medio también para la mejora continua del sistema de alarmas.
Actualmente los sistemas de control (DCS, sistemas híbridos SCADA-PLC etc.) disponen de una gran versatilidad para la configuración y gestión de alarmas, como resultado de esto las plantas con sistemas automatizados pueden operar cerca de límites que nunca antes se hubieran pensado, reduciendo los tiempos de paro, incrementando la productividad y sobre todo protegiendo las personas y el medio ambiente.
Cuando el sistema de alarmas no funciona adecuadamente
Defectos en los sistemas de alarmas, su implementación o su uso pueden generar multitud de pequeños efectos e incidentes que incrementan el riesgo de las personas, de la planta o proceso e incrementan el costo de operación. Si bien en accidentes graves que han habido en la industria es difícil establecer cuánto los sistemas de alarmas hubieran contribuido a evitarlos, la información de las alarmas ha sido generalmente esencial en otros casos para evitarlos, además de permitir un análisis posterior exhaustivo.
Los sistemas actuales, con mucha versatilidad, permiten la configuración de múltiples alarmas para cada medición, lo que resulta en una mayor cantidad de alarmas posibles que la cantidad de instrumentos que existen en la planta o proceso. El trabajo del sistema de control es mantener el proceso dentro de los rangos óptimos y seguros de funcionamiento. El trabajo del operador es mediar e intervenir para mantener el proceso dentro de esos rangos. Generalmente cuando el proceso sale fuera de sus rangos normales, prevalece el desorden. La habilidad que el conjunto sistema de control–operador tengan para responder eficientemente durante estos eventos pueden hacer la diferencia entre minimizar el tiempo de paro o un evento catastrófico.
El operador y el diseño del sistema en función de su rol
Las tendencias mas comunes son dar mayor responsabilidad y poner mayor presión sobre el operador.
Si a esto sumamos que el rol de un operador en plantas o procesos modernos abarca una variedad de actividades muy amplias tales como la operación de la planta, la optimización de la producción, la identificación de fallas, la coordinación del mantenimiento etc, la situación es aún más preocupante. El papel del operador durante una situación anormal puede ser muy complejo.
El sistema de alarmas es un sistema de apoyo a la operación, por lo que debe tener muchas características básicas, principalmente orientadas a la respuesta del operador y encontrarse diseñado de acuerdo a sus capacidades. Si una condición dada en el proceso no necesita que el operador tome una acción, entonces probablemente no debería haber una alarma asociada a esa condición. El sistema deberá intentar la atención del operador sobre las alarmas mas importantes, proveer mensajes claros y entendibles permitiendo poner foco en aquellas problemáticas mas importantes sobre las que tiene que realizar alguna acción. El sistema debe ser relevante al rol que en el momento tiene el operador, indicar claramente cuál es la respuesta esperada, presentar las alarmas a una velocidad que el usuario pueda manejar siendo además fácil de entender. El objetivo en este sentido es lograr un sistema de alarmas que evite que el operador piense que una alarma puede ser ignorada; todas las alarmas deben tener una respuesta definida y debe dársele tiempo al operador a que pueda llevarla a cabo.
Evaluando la inversión en un nuevo sistema de alarmas o su rediseño
Durante las etapas de construcción, o durante el posterior ciclo de operación y mantenimiento de una planta o proceso, se invierten grandes cantidades de dinero en ingeniería, construcción, modificaciones, definición de estrategias de control y seguridad. Sin embargo muchas veces se desatienden las inversiones necesarias en un componente indispensable como es el sistema de alarmas. La inversión inicial en diseño de sistemas debe ser suficiente para evitar los problemas operacionales y los riesgos en seguridad, medioambiente y economía que generalmente surgen, y que dan como resultado costos mayores durante toda la vida útil. Deben seleccionarse estrategias apropiadas para asegurarse de que los sistemas de alarmas estén creados con niveles de calidad adecuados a la planta o proceso que operamos y protegemos, y alineadas con los demás componentes que han sido diseñados para estos objetivos.
Normas internacionales y las mejores prácticas en gestión de alarmas
Una de las referencias mas utilizadas actualmente en la industria para la gestión de alarmas -en cuanto a recomendaciones prácticas basadas en experiencias- es el documento publicado por EEMUA (The Engineering Equipment and Materials Users’ Association) – Publication 191 (Alarm Systems – A Guide to Desing, Management and Procurement y de mas reciente publicación la ISA 18.2 -2009 “Management of Alarm Systems for the Process Industries”. Estos documentos están basados en experiencias y en un amplio estudio del factor humano, las que se deben tener en cuenta en la configuración de alarmas individuales, configuración de sistemas de alarmas o diseño/rediseño de sistemas de alarmas.
Decidir si la alarma debe clasificarse como alarma de seguridad será un paso importante a tener en cuenta para cada una de ellas durante el diseño de la filosofía de control. Para ello se deberá tener en cuenta las definiciones dadas en la norma internacional IEC 61508. La decisión acerca de si la alarma está relacionada con seguridad se verá afectada también por la legislación nacional y por prácticas existentes en el sector de la industria. La evaluación de riesgo proporciona un punto de partida en el proceso de diseño. Posteriormente se deben considerar aspectos más amplios de diseño: Selección de los ajustes de alarmas, cómo deben definirse y establecerse prioridades, cómo deben procesarse las alarmas para hacerlas tan significativas como sea posible, selección de las áreas de alarmas (lógicas o físicas). Todo ello deberá estar correctamente documentado en la “filosofía de alarmas” que será el punto de partida para configurar el sistema, entrenar al personal, medir continuamente la eficacia del sistema y auditar el sistema en un proceso que deberá repetirse a lo largo del ciclo de vida de la planta o proceso.
Identificando síntomas
Sobre sistemas ya en funcionamiento, existen muchas manifestaciones sobre el sistema mismo que se deben mirar para reconocer si estamos teniendo una gestión de alarmas ineficiente : Alarmas ruidosas, avalanchas de alarmas, alarmas en cascada, mensajes o indicaciones inadecuados en lugar de alarmas, gran cantidad de alarmas de alta prioridad o alarmas que se encuentran por largos períodos activas en el sistema son algunos de los síntomas que nos pueden llevar a pensar que algo no está funcionando correctamente. Muchas veces los sistemas de alarmas no son sensibles al contexto operativo en que se encuentra la planta en un momento dado. Algunas señales que pueden ser alarma en un estado de operación de la planta, puede que no sean relevantes o que no requieran atención del operador en otros estados.
Es común en la industria del Oil&Gas encontrarse con sistemas donde un operador debe lidiar a diario con 1500 o 2000 alarmas diarias de distintas prioridades, con un muy alto porcentaje de alarmas de prioridad Alta, muy lejos de lo esperado. Los operadores se encuentran en este escenario atendiendo por día hasta diez veces más de alarmas de las que razonablemente puede atender, en una forma de trabajo normalmente caótica.
domingo, 27 de julio de 2008
SOA en Sistemas de Automatización y Control.-
El concepto SOA (Service Oriented Achitecture) ya no es ajeno a ninguna compañía u organización, incluso los sistemas directamente relacionados a los procesos de planta ya han comenzado a incursionar y generar estándares propios basados en este concepto. Muchos SCADA del mercado están comenzando a incorporar modestamente estas nociones y otros que han surgido desde cero apalancados en SOA.
El mundo de automatización y control, a nivel aplicativos, se basa desde hace varios años en gran medida en el estándar OPC (Ole for Process Control), que se encuentra fundado en COM y DCOM. Esto quizás explica uno de los motivos y ansiedad de contar en el mundo de automatización y control de nuevos estándares y posibilidades que sean multiplataforma, que no dependan de tecnologías propietarias y pronto en desuso. OPC-UA es la nueva generación de OPC ahora basado en los conceptos de SOA. PRODML al igual que WITSML insipientes estándares para el oil&gas atendiendo a las necesidades crecientes en yacimientos modernos altamente instrumentados y automatizados también llamados “Fields of the Future”, “SmartFields”, “eFields” etc.
Tecnológicamente detrás del concepto SOA encontraremos XML, SOAP, HTTP(HTTPS), Web Services etc, tecnologías que normalmente se encuentran bajo la órbita de los departamentos de IT. Si sumamos a esto la creciente convergencia tecnológica (telecomunicaciones, servidores-almacenamiento, redes, software, PLC, RTU, controladores, instrumentos etc) los departamentos de automatización, IT y comunicaciones se encuentran cada vez con sus fronteras menos definidas como viene sucediendo desde hace años en forma mas perceptible entre IT y comunicaciones.
La aplicación de SOA en automatización y control implicaría un cambio cultural importante en los sistemas clásicos, sin embargo como ventaja adicional, podría ser un vector que uniera dos mundos que históricamente han trabajado por caminos paralelos, el de Tecnología de Información y el de Sistemas de Control. Entre estos dos mundos se han utilizado por años diversos mecanismos que han permitido la comunicación eficiente entre sistemas heterogéneos y multiplataformas con fines de integración de los procesos del negocio. Sin embargo gracias a SOA estos dos universos parecen moverse juntos hacia un nuevo horizonte, cuyo objetivo sería promover determinado comportamiento en estas áreas y en toda la organización para lograr los objetivos del negocio.
Puede que el valor de SOA en automatización y control, así como sucede en sistemas clásicos, esté dado por la reutilización, la estandarización de los servicios, la abstracción de los mismos, la posibilidad multiplataforma que brinda, la interoperabilidad aportando verdadero valor a los procesos del negocio y probablemente la tercerización, una posibilidad siempre existente a la cual SOA agrega un grado de flexibilidad adicional.
La automatización no finaliza en la automatización misma, sino que toma verdadero valor con los aplicativos específicos de cada industria. Estos aplicativos verticales quizás se podrán en un futuro considerar verdaderos “servicios”, con los que se podrá hacer modelado de procesos. Por ejemplo, los aplicativos para gestión de downtime, gestión de producción, manufactura asistida, aplicativos de optimización, diagnóstico, simulación y tantos otros procesos aislados, podrían en un futuro ser consistentes con los conceptos de SOA. Quizás un analista especializado en procesos de manufactura, producción o negocios, mediante el lenguaje BPEL podría optimizar estos procesos, su forma de interacción etc, sin necesidad de conocimientos avanzados en sistemas. Quizás una abstracción de la lógica interna ayudaría al especialista a realizar una mejor orquestación de servicios tal como normalmente se hace en otros estratos de las organizaciones.
Elegir el nivel de atomicidad adecuado de los servicios probablemente sea el mayor desafío que los proveedores de sistemas tengan que dar en los próximos años, para no cometer el error de pensar los servicios en función de lo que originalmente ha sido el mundo de la automatización y control. Se deberán considerar los servicios en función de su utilidad global a la compañía, pero también considerando la reutilización de conceptos ya vigentes. También aquí se agrega un nuevo grado de complejidad, donde para lograr buena performance con el concepto SOA (fundamentalmente por el overhead agregado por XML) el núcleo de los servicios requiere de gran poder de procesamiento, por lo tanto el nivel de atomicidad seguramente deberá considerar no solo aspectos del negocio, sino también de las posibilidades tecnológicas.
Nos imaginamos en un futuro próximo aplicaciones de automatización y control corriendo en servidores de aplicaciones en lugar de arquitecturas cliente servidor clásicas. Nos imaginamos la automatización y control con mensajes en formato XML llenos de información tiempo real, donde en su estructura de datos se defina perfectamente el instrumento, el proceso al que pertenece, su función y la planta a la que pertenece. Nos imaginamos portales donde un operador, un administrativo o cualquiera que necesite de información tiempo real, histórica o reportes de los procesos cuenten con alarmas, tendencias, gráficos y cualquier estructura de datos que pueda ser personalizada a su medida. Nos imaginamos un nivel de integración con aplicativos de Business Intelligence nunca visto hasta ahora. Nos imaginamos PLC, RTU o controladores -y porque no instrumentos digitales- yendo mas allá de publicar su información en un servidor web integrado, sino también siendo parte integral de servicios distribuidos. Nos imaginamos tercerizando servicios de automatización y control o telemetría a compañías especialistas. Nos imaginamos un mundo donde los servicios típicamente componentes de un sistema de control formen parte de los procesos formales definidos de la organización, aportando a la estrategia global en forma activa.
El mundo de automatización y control, a nivel aplicativos, se basa desde hace varios años en gran medida en el estándar OPC (Ole for Process Control), que se encuentra fundado en COM y DCOM. Esto quizás explica uno de los motivos y ansiedad de contar en el mundo de automatización y control de nuevos estándares y posibilidades que sean multiplataforma, que no dependan de tecnologías propietarias y pronto en desuso. OPC-UA es la nueva generación de OPC ahora basado en los conceptos de SOA. PRODML al igual que WITSML insipientes estándares para el oil&gas atendiendo a las necesidades crecientes en yacimientos modernos altamente instrumentados y automatizados también llamados “Fields of the Future”, “SmartFields”, “eFields” etc.
Tecnológicamente detrás del concepto SOA encontraremos XML, SOAP, HTTP(HTTPS), Web Services etc, tecnologías que normalmente se encuentran bajo la órbita de los departamentos de IT. Si sumamos a esto la creciente convergencia tecnológica (telecomunicaciones, servidores-almacenamiento, redes, software, PLC, RTU, controladores, instrumentos etc) los departamentos de automatización, IT y comunicaciones se encuentran cada vez con sus fronteras menos definidas como viene sucediendo desde hace años en forma mas perceptible entre IT y comunicaciones.
La aplicación de SOA en automatización y control implicaría un cambio cultural importante en los sistemas clásicos, sin embargo como ventaja adicional, podría ser un vector que uniera dos mundos que históricamente han trabajado por caminos paralelos, el de Tecnología de Información y el de Sistemas de Control. Entre estos dos mundos se han utilizado por años diversos mecanismos que han permitido la comunicación eficiente entre sistemas heterogéneos y multiplataformas con fines de integración de los procesos del negocio. Sin embargo gracias a SOA estos dos universos parecen moverse juntos hacia un nuevo horizonte, cuyo objetivo sería promover determinado comportamiento en estas áreas y en toda la organización para lograr los objetivos del negocio.
Puede que el valor de SOA en automatización y control, así como sucede en sistemas clásicos, esté dado por la reutilización, la estandarización de los servicios, la abstracción de los mismos, la posibilidad multiplataforma que brinda, la interoperabilidad aportando verdadero valor a los procesos del negocio y probablemente la tercerización, una posibilidad siempre existente a la cual SOA agrega un grado de flexibilidad adicional.
La automatización no finaliza en la automatización misma, sino que toma verdadero valor con los aplicativos específicos de cada industria. Estos aplicativos verticales quizás se podrán en un futuro considerar verdaderos “servicios”, con los que se podrá hacer modelado de procesos. Por ejemplo, los aplicativos para gestión de downtime, gestión de producción, manufactura asistida, aplicativos de optimización, diagnóstico, simulación y tantos otros procesos aislados, podrían en un futuro ser consistentes con los conceptos de SOA. Quizás un analista especializado en procesos de manufactura, producción o negocios, mediante el lenguaje BPEL podría optimizar estos procesos, su forma de interacción etc, sin necesidad de conocimientos avanzados en sistemas. Quizás una abstracción de la lógica interna ayudaría al especialista a realizar una mejor orquestación de servicios tal como normalmente se hace en otros estratos de las organizaciones.
Elegir el nivel de atomicidad adecuado de los servicios probablemente sea el mayor desafío que los proveedores de sistemas tengan que dar en los próximos años, para no cometer el error de pensar los servicios en función de lo que originalmente ha sido el mundo de la automatización y control. Se deberán considerar los servicios en función de su utilidad global a la compañía, pero también considerando la reutilización de conceptos ya vigentes. También aquí se agrega un nuevo grado de complejidad, donde para lograr buena performance con el concepto SOA (fundamentalmente por el overhead agregado por XML) el núcleo de los servicios requiere de gran poder de procesamiento, por lo tanto el nivel de atomicidad seguramente deberá considerar no solo aspectos del negocio, sino también de las posibilidades tecnológicas.
Nos imaginamos en un futuro próximo aplicaciones de automatización y control corriendo en servidores de aplicaciones en lugar de arquitecturas cliente servidor clásicas. Nos imaginamos la automatización y control con mensajes en formato XML llenos de información tiempo real, donde en su estructura de datos se defina perfectamente el instrumento, el proceso al que pertenece, su función y la planta a la que pertenece. Nos imaginamos portales donde un operador, un administrativo o cualquiera que necesite de información tiempo real, histórica o reportes de los procesos cuenten con alarmas, tendencias, gráficos y cualquier estructura de datos que pueda ser personalizada a su medida. Nos imaginamos un nivel de integración con aplicativos de Business Intelligence nunca visto hasta ahora. Nos imaginamos PLC, RTU o controladores -y porque no instrumentos digitales- yendo mas allá de publicar su información en un servidor web integrado, sino también siendo parte integral de servicios distribuidos. Nos imaginamos tercerizando servicios de automatización y control o telemetría a compañías especialistas. Nos imaginamos un mundo donde los servicios típicamente componentes de un sistema de control formen parte de los procesos formales definidos de la organización, aportando a la estrategia global en forma activa.
Suscribirse a:
Entradas (Atom)