7 sistemas control

Módulo:

Sistemas de control

Coordinadora: Dña. Marisa Sanzo

Instrumentación y control

Marzo 2007

Módulo: 7 Sistemas de control

Fechas impartición: del 12 al 16 de marzo de 2007 Duración: 40 horas

Coordinadora: Marisa Sanzo

Jefe de Compras en Emerson Process Management. Licenciada en Ciencias Físicas por la Universidad de Valladolid. Experiencia como Jefe de proyectos de automatización en Emerson Process Management. Experiencia en diseño, especificación y ejecución de proyectos de instrumentación y control, desarrollada tanto bajo filosofía 4-20 mA Hart como mediante el uso de buses de campo (Profibus y Fieldbus Foundation). Proyectos a nivel de usuario o como suministrador en: alimentación (Azucarera Española), oil & gas (Repsol y Enagas), papel (Saica) y

cemento (TDCIM). Profesores: Manuel Lázaro

Dentro de Siemens desde el año 1995, en la división de Productos y Sistemas de Automatización, desarrollando tareas de formación, técnicas y de promoción de producto. Y desde el año 1999 en el área de Control de Procesos PCS7 y PLCs de Seguridad de Siemens.

Miguel Ángel Sinobas

Técnico en Sistemas de Producción en la Refinería de Somorrostro de Petronor. Ingeniero de Procesos Químicos. Participa en 1995 en el proyecto de reinstrumentación, control avanzado y sistema integrado de la información en la Refinería de Petronor. Ha liderado los proyectos de puesta en marcha de aplicaciones relacionadas con la información de producción en las Refinerías del Grupo Repsol YPF de España y Argentina.

Jesús Villena

Director de Ergotec, empresa especializada en el papel del ser humano en los sistemas complejos de alto riesgo. Ergónomo (CNAM-París), European Ergonomist® (CREE-Holanda). Ha participado en la concepción de la organización del trabajo, la documentación de operación, los HMIs de control y supervisión, el equipamiento y las salas de control de sectores industriales como la industria petroquímica, el nuclear o el control del tráfico

aéreo, sectores en los que desarrolla su actividad desde 1993. Manuel Bollaín

Director del Centro Operativo de Madrid de TSK. Ingeniero Aeronáutico. Durante 25 años trabajó en SENER donde alcanzó el cargo de Jefe del Departamento de Instrumentación y Control, participando en multitud de proyectos, tanto industriales como de defensa. Posteriormente, también trabajó en Azucarera Española, donde desarrolló un programa de modernización de los sistemas de instrumentación y control de todas las fábricas del grupo a lo largo de ocho años. Ha sido Presidente de ISA España durante dos años así como asesor de proyectos de investigación y desarrollo para la Unión Europea.

Objetivos:

Este módulo tiene por objetivo dar una visión y un conocimiento lo mas extenso posible sobre los Sistemas de Control, Sistemas de Enclavamiento y buses de campo, sin olvidar aspectos importantes de la instrumentación inteligente.

Es también importante conocer la utilización de los instrumentos como base para la gestión de la producción de un centro industrial, la relación de sistemas como el de Gestión del Laboratorio con el propio SCD y las interfases utilizadas.

Se estudia la ingeniería de los SCD y PLC y se llevan a cabo prácticas con equipos reales.

Se incluye también un capítulo, que cada vez tiene mas importancia, como es el diseño de salas de control y la Ergonomía de Sistemas; Gestión de alarmas, diseño de gráficos, etc. Descripción:

7 A 1 – Sistemas de control. SDC’s, Buses y PLC’s • Sistemas de control • Buses de campo

7 A 2 – Sistemas de gestión de la producción • Conocimientos previos requeridos • Sistema de información de producción • Sistema de gestión de laboratorio • Soporte informático • Actividades profesionales

7 B 1 – Ingeniería de sistemas de control. SDC’s y PLC’s • Alcance y distribución de un sistema de control distribuido • Cálculos asociados • Construcción hardware

7 B 2 - Interfases entre sistemas • Conocimientos previos requeridos • Interfases de formación de producción • Sistema de interfases de producción • Plataforma de datos de instrumentación

7 B 3 - Diseño salas de control. Ergonomía de sistemas • La sala, los operadores y la ergonomía • Aspectos medioambientales de la sala • Aspectos físicos y espaciales de la sala • Aspectos lógicos

7 C – Prácticas de sistemas de control. SDC’s. • Prácticas de sistemas de control distribuido • Prácticas de PLC´s

7 C1 – Prácticas proyecto de ingeniería de instrumentación.

8A1

SISTEMAS DE CONTROL

FICHA IDENTIFICATIVA DEL DOCUMENTO: Master ISA de instrumentación y control Módulo: 8A1 – Sistemas de Control Tema: 8A1 – Sistemas de Control Autor: Marisa Sanzo

INTRODUCCIÓN El objetivo del tema es abordar los conceptos y elementos asociados a un sistema de control con objeto de que a futuro el alumno tenga los conocimientos necesarios que le permitan diseñar y especificar un sistema de control acorde a las necesidades reales de su proyecto de control.

Con el fin de que dicho tema así como la documentación asociada al mismo sea un referente futuro para el alumno, la organización de los capítulos del mismo presentan un orden similar al que debería de seguir(según criterios del ponente) una especificación técnica.

El desarrollo de contenidos está enfocado a futuras tareas genéricas de diseño y especificación de sistemas de control de acuerdo con las necesidades de un futuro proyecto obviando las características concretas de un determinado producto o solución existente en el mercado.

Módulo: 8A1 SISTEMAS DE CONTROL Tema: 8A1 - Sistemas de Control

Master ISA- ISE de Instrumentación y Control Página 2

SISTEMAS DE CONTROL Índice 1. SISTEMAS DE CONTROL 3

1.1. Definición de Sistemas de Control 3 1.1.1. Definición de Sistema de Control 3 1.1.2. Conceptos Asociados 3

1.2. Sistemas de Control Distribuido y PLCs 4 1.2.1. Definición de Sistema de Control Distribuido 4 1.2.2. PLCs 4

1.3. Sistemas de Control Distribuido y Scadas 5 1.3.1. Definición de Sistema de Control Distribuido 5 1.3.2. Scadas 5

1.4. Elementos que Conforman un Sistema de Control Distribuido 6 1.4.1. Equipos Hardware 6 1.4.2. Consolas (o Estaciones) 9 1.4.3. Comunicaciones 11 1.4.4. Elementos Software 16

2. BUSES DE CAMPO 17

2.1. Definición de Bus y Características Asociadas 17 2.1.1. Definición de Bus 17 2.1.2. Características 17

2.2. Modelo OSI 18 2.2.1. Definición 18 2.2.2. Las Capas del Modelo OSI 18

2.3. Clasificación General de Buses 21 2.3.1. Buses de Sensor 21 2.3.2. Buses de Dispositivos 21 2.3.3. Buses de Campo 21

2.4. Profibus 21 2.4.1. Perfiles Profibus 22 2.4.2. Nivel Físico 22 2.4.3. Tabla Resumen 24

2.5. Fieldbus Foundation 25 2.5.1. Segmentos Fieldbus Foundation 25 2.5.2. Nivel Físico 26 2.5.3. Tabla Resumen 27



1. SISTEMAS DE CONTROL

1.1. Definición de Sistemas de Control

1.1.1. Definición de Sistema de Control

La infinita gama de soluciones existentes en el mercado, destinadas al control, hace difícil encontrar una definición de Sistema de Control que englobe a todas ellas.

Con objeto de acotar alcances y poder abordar a posteriori el concepto de Sistemas de Control Distribuido, definiremos en lo relativo a este capítulo como Sistema de Control toda solución que permita mediante el uso de:

un sistema de captación de señales de campo

un procesador

una interfase para interacción entre el procesador y el ser humano

el control automático de una o varias variables físicas.

1.1.2. Conceptos Asociados

Control: acción destinada a que una o varias variables físicas tengan un valor similar a un patrón, consigna u objetivo.

Control automático: acción de control ejecutada y supervisada por un procesador electrónico.

Señal de campo: información en formato electrónico relativa al valor o estado de una variable física.

Señal de campo digital: información en formato electrónico relativa al estado de una variable física (0 ó 1)

Señal de campo analógica: información en formato electrónico relativa al valor de una variable física (de 0 a 100%)

Variables físicas tipo entrada: objeto de supervisión y/o control.

Variables físicas tipo salida: objeto de acción y/o manipulación.

Procesador

Entrada

Consigna Proceso

Salida Acción

Captador

Fig. 1-1-1 Sistema de Control



1.2. Sistemas de Control Distribuido y PLCs

1.2.1. Definición de Sistema de Control Distribuido

Desde un punto de vista riguroso, un Sistema de Control Distribuido tal como el término indica, es un Sistema de Control en donde la solución para el control automático de las variables físicas implicadas está localizada junto a dichas variables.

Dado que las tecnologías convencionales (a excepción de Filosofías de buses de Campo tipo Fieldbus) hacen difícil que los procesadores estén ubicados junto a las variables físicas que es necesario controlar, el concepto de Sistema de Control Distribuido desde un punto de vista coloquial es toda solución que cumpla los siguientes requisitos:

(A) Todo Sistema de Control destinado al control y supervisión de un proceso (con un nº de variables físicas significativas)

(B) El procesador responsable del control automático y la interfase para interacción con el ser humano forman un conjunto indivisible con herramientas y parámetros comunes para su configuración.

(C) El conjunto procesador / interfase es una solución técnica estandarizada por el fabricante, escalable según las necesidades de cada proyecto de control y tipificable de cara a la configuración de la solución final.

1.2.2. PLCs

PLC hace referencia a un tipo concreto de procesador en el que la ejecución del control automático sigue un esquema de orden / ciclo lógico de pasos. Este tipo de equipos tuvieron su origen en el control automático de procesos en donde predominaban las variables físicas tipo estado (0 ó 1) con tiempos de ejecución rápidos.

Aunque en la actualidad los PLCs existentes en el mercado se han beneficiado de los desarrollos de la informática y la electrónica, no es correcto decir que una solución de control basada en el uso de un PLC es un Sistema de Control Distribuido ya que no cumpliría el requisito (B) anteriormente expuesto.

Es posible sin embargo afirmar que uno o varios PLCs pueden formar parte de un Sistema de Control Distribuido como analizaremos a posteriori cuando abordemos el punto Integración con Terceros.



1.3. Sistemas de Control Distribuido y Scadas

1.3.1. Definición de Sistema de Control Distribuido

Desde un punto de vista riguroso, un Sistema de Control Distribuido tal como el término indica, es un Sistema de Control en donde la solución para el control automático de las variables físicas implicadas está localizada junto a dichas variables.

Dado que las tecnologías convencionales (a excepción de Filosofías de buses de Campo tipo Fieldbus) hacen difícil que los procesadores estén ubicados junto a las variables físicas que es necesario controlar, el concepto de Sistema de Control Distribuido desde un punto de vista coloquial es toda solución que cumpla los siguientes requisitos:

(A) Todo Sistema de Control destinado al control y supervisión de un proceso (con un nº de variables físicas significativas)

(B) El procesador responsable del control automático y la interfase para interacción con el ser humano forman un conjunto indivisible con herramientas y parámetros comunes para su configuración.

(C) El conjunto procesador / interfase es una solución técnica estandarizada por el fabricante, escalable según las necesidades de cada proyecto de control y tipificable de cara a la configuración de la solución final.

1.3.2. Scadas

Scada hace referencia a un tipo de solución de control en donde el procesador y la interfase para interacción con el ser humano se han definido / diseñado a medida y de acuerdo con las necesidades particulares del proyecto de control. En la mayoría de los casos procesador e interfase no tienen como origen el mismo fabricante.

Aunque es posible encontrar numerosas aplicaciones de control basadas en soluciones Scadas, no es correcto denominarlas Sistema de Control Distribuido ya que no cumplirían los requisitos (B) y (C) anteriormente expuestos.

Es posible sin embargo afirmar que uno o varios Scadas pueden formar parte de un Sistema de Control Distribuido como analizaremos a posteriori cuando abordemos el punto Integración con Terceros.



1.4. Elementos que Conforman un Sistema de Control Distribuido

Antes de abordar el estudio de los distintos elementos que forman parte de un Sistema de Control Distribuido recordaremos que este ha sido definido como:

Toda solución estandarizada, escalable y tipificable que permita mediante el uso de:

un sistema de captación de señales de campo

un procesador

una interfase para interacción entre el procesador y el ser humano

el control automático de una o varias variables físicas

Solución en donde procesador e interfase forman un conjunto indivisible.

1.4.1. Equipos Hardware

De acuerdo con “The Oxford Spanish Dictionary”:

Hardware / "hA:rdwer / n [u] a (ironmongery) ferretería f; (before n) hardware dealer ferretero, -ra m, f; hardware store ferretería f, mercería f (Chi) b (equipment, machinery) equipo m, maquinaria f; military hardware armamento m c (Comput) hardware m, soporte m físico, equipo m

Son elementos físicos de naturaleza eléctrica y/ o electrónica necesarios en la captación y procesamiento de las señales que intervienen en el control de procesos en contraposición con los elementos lógicos que los hacen funcionar.

Los elementos hardware pueden en muchos casos diseñarse e instalarse en modo redundante, es decir desde el punto de vista constructivo y de funcionamiento existirán un elemento físico similar por cada elemento hardware (redundancia 1+1) o al menos un elemento físico similar a mayores para una misma familia de elementos hardware (redundancia n+1)

El modo en el que cada solución de control y gestiona esta redundancia depende del fabricante:

- opción 1: uno de los elementos está en servicio (primario) y su redundante (secundario) en “espera” es decir listo para entrar en funcionamiento si el diagnostico del sistema detecta que el elemento primario no está disponible o tiene una mal función.

- opción 2: ambos elementos (primario y secundario) están en servicio simultáneamente. El diagnóstico del sistema únicamente informa sobre la disponibilidad de ambos elementos y el posible mal funcionamiento de los mismos.

CPU (o Controladores)

Es la unidad central de proceso (procesador) destinada a realizar funciones de cálculo así como tareas de supervisión del estado global o disponibilidad del conjunto hardware (supervisión de los elementos destinados a captar señales de entrada y salida, supervisión del conjunto procesador / interfase, supervisión de las comunicaciones entres distintos elementos, etc)

Este tipo de unidad recibe el nombre técnico de Controlador.



Las CPUs pueden (en función del fabricante) estar tipificadas según la solución de control que deban ejecutar y/o según la normativa aplicable al proceso.

Las CPUs pueden (en función del fabricante) ser escalables en capacidad de procesamiento y gestión de recursos de acuerdo con las dimensiones del proyecto de control.

Las CPUs pueden (en función del fabricante) instalarse en modo redundante: 1+1

Elementos de Entrada (o Tarjetas de Entrada)

Son las unidades destinadas a captar eléctricamente punto a punto las señales de campo correspondientes a las variables físicas objeto de supervisión y/o control.

Este tipo de unidad recibe el nombre técnico de Tarjeta de Entrada.

Permite la captación simultánea de varias señales de campo cada una de las cuales se conecta mediante cableado físico a un canal eléctrico.

Las Tarjetas de Entrada están tipificadas (en función del fabricante) constructiva y técnicamente según el tipo de señal eléctrica que vayan a tratar.

Tarjeta para señales analógicas 4-20 mA (2 hilos)

Tarjeta para señales analógicas 4-20 mA (4 hilos)

Tarjeta para señales analógicas 0-10 V

Tarjeta para señales digitales tipo contacto libre de tensión

Tarjeta para señales digitales tipo alimentación externa

Tarjeta para señales tipo pulso

Tarjeta para señales tipo RTD

Tarjeta para señales tipo Termopar

Las Tarjetas de Entrada pueden (en función del fabricante) ser escalables en número de canales eléctricos.

Tarjeta estándar: 8 canales

Tarjeta de alta densidad: 32 / 64 canales

Tarjeta específica: 4 canales

Las Tarjetas de Entrada pueden (en función del fabricante) instalarse en modo redundante: 1+1

Elementos de Salida (o Tarjetas de Salida)

Son las unidades destinadas a captar eléctricamente punto a punto las señales de campo correspondientes a las variables físicas objeto de acción y/o manipulación.

Este tipo de unidad recibe el nombre técnico de Tarjeta de Salida.

Permite la captación simultánea de varias señales de campo cada una de las cuales se conecta mediante cableado físico a un canal eléctrico.



Las Tarjetas de Salida están tipificadas (en función del fabricante) constructiva y técnicamente según el tipo de señal eléctrica que vayan a tratar.

Tarjeta para señales analógicas 4-20 mA

Tarjeta para señales digitales

Las Tarjetas de Salida pueden (en función del fabricante) ser escalables en número de canales eléctricos.

Tarjeta estándar: 8 canales

Tarjeta de alta densidad: 32 / 64 canales

Tarjeta específica: 4 canales

Las Tarjetas de Salida pueden (en función del fabricante) instalarse en modo redundante: 1+1

Elementos para Integración y Comunicación con Terceros

Son las unidades destinadas a captar eléctricamente un conjunto masivo de señales procedentes habitualmente de un procesador ajeno al Sistema de Control Distribuido, basándose en una comunicación del tipo digital multipunto.

Este tipo de elementos reciben el nombre genérico de Tarjetas de Comunicaciones.

Las Tarjetas de Comunicaciones están tipificadas (en función del fabricante) constructiva y técnicamente según el tipo de protocolo de comunicación digital que vayan a utilizar. Los más comunes en la industria de procesos:

Modbus

ASi

Profibus

Fieldbus Foundation

Es el protocolo de comunicación digital el que determina el volumen de señales que estas tarjetas son capaces de integrar así como el tipo de señal digital y/o analógico.

Las Tarjetas de Comunicaciones pueden (en función del fabricante) ser escalables en número de puertos de comunicaciones.

Las Tarjetas de Comunicaciones pueden (en función del fabricante) instalarse en modo redundante: 1+1

Bastidores

Son unidades físicas en donde se alojan los distintos elementos hardware: CPU, tarjetas y fuentes de alimentación.

Es un error pensar que este tipo de elementos son del tipo pasivo ya que además de permitir el conexionado físico de los diferentes elementos hardware de un Sistema de Control Distribuido, en la mayoría de las soluciones intervienen de manera activa en las comunicaciones entre procesador y elementos de entradas y salidas.



Fuentes de Alimentación

Como su nombre indica son las unidades destinadas a suministrar alimentación eléctrica (en continua o en alterna) a los distintos elementos del conjunto hardware así como a los circuitos y/o elementos de campo que lo requieran.

De manera genérica podemos decir que dos son los tipos de alimentaciones que requiere un Sistema de Control Distribuido:

- La alimentación eléctrica de los distintos elementos hardware del Sistema de Control Distribuido, enumerados y definidos a lo largo de este apartado: CPU, tarjetas y bastidores.

- La alimentación eléctrica de los circuitos y/o elementos de campo así como de elementos auxiliares necesarios en la solución hardware.

La solución eléctrica en relación con estas alimentaciones ser resolverá de acuerdo con los estándares de cada fabricante, es decir cada solución determinará:

- El tipo de fuente (AC/AC, AC/DC, DC/DC) que es necesario utilizar para cada uno de los servicios arriba indicados.

- El grado de segregación entre fuentes (fuentes independientes o comunes para cada uno de los servicios)

Las fuentes de alimentación pueden (en función del fabricante) instalarse en modo redundante, a diferencia del resto de los elementos hardware, la redundancia pude lograrse mediante configuración 1+1 ó n+1.

1.4.2. Consolas (o Estaciones)

Son el elemento físico que permite la interacción entre el procesador y el ser humano.

Presentan y/o ponen a disposición del usuario toda la información relativa al Sistema de Control Distribuido: valores físicos de las señales de entrada y salida, funciones de cálculo, soluciones de control, diagramas de proceso, estado y disponibilidad de los elementos hardware, etc ...

En la actualidad las consolas siguen un formato tipo PC bajo dos posibles variantes:

(A) PC convencional basado en tecnología Windows (actualmente XP) y compuesto por CPU, pantalla (1 o varias), teclado, ratón y altavoces.

(B) PC de tipo industrial basado en tecnología Windows o en sistema operativo propietario del fabricante y compuesto por CPU, pantalla o monitor integrado en pupitre de control, teclado con opciones de teclas de función preprogramadas, ratón o similar.

El grado de redundancia de los elementos que forman una consola está condicionado por la criticidad de la solución de control. Normalmente dicho grado de redundancia se aplica a la CPU y sus elementos asociados (procesador, disco duro, fuente de alimentación, sistema de refrigeración, etc.)

Como elemento adicional, las consolas disponen de unidades (internas o externas) dedicas a la creación de copias de seguridad de la solución de control diseñada, tipo grabador / lector de cintas y/o unidad de CD.



Antes de abordar los diferentes tipos de consolas, definiremos como operador todo ser humano cuya tarea principal es la supervisión y manejo de un Sistema de Control Distribuido mediante interacción interfase / procesador.

Consolas de Operación

Constituyen las interfaces desde las cuales el operador puede supervisar y/o actuar sobre cualquier parte del proceso, disponiendo en la mayoría de los casos de todas las facilidades de manejo introducidas por el uso de un entorno Windows.

Este tipo de consolas, por estar dedicadas a tareas de supervisión y manejo, carecen de atributos y/o privilegios que permitan modificar la solución de control.

Consolas de Ingeniería

Constituye uno de los elementos fundamentales del Sistema de Control Distribuido ya que incluye las herramientas necesarias para realizar las tareas de configuración de la solución de control así como las herramientas de diagnostico que permiten conocer la disponibilidad del sistema.

Normalmente, en esta consola reside la base de datos del proyecto (listado de elementos de entrada y salida, programas de cálculo, diagramas de proceso) así como la unidad destinada a realizar copias de seguridad de la misma.

Este tipo de consolas, por estar dedicadas a tareas de configuración, gozan de todos los atributos y/o privilegios que permitan modificar la solución de control así como cualquier parámetro asociado al Sistema de Control Distribuido.

Equipos Auxiliares

El abanico de elementos auxiliares asociados a la supervisión y manejo de un Sistema de Control Distribuido está condicionado por el diseño de cada fabricante, sin embargo es posible indicar que impresoras y estaciones de exportación de datos son comunes a la mayor parte de la soluciones de control.

(A) Impresoras

Similares a la unidades de impresión de datos del sector de la ofimática.

Normalmente están destinadas a la impresión de gráficos del proceso, programas de cálculo y/o configuración, alarmas y eventos asociados a la disponibilidad del sistema, etc.

En algunas soluciones la impresora destinada a alarmas y eventos asociados a la disponibilidad del sistema suele ser del tipo matricial – papel continuo, con objeto de disponer mediante copia en papel de todos el histórico de eventos de cara a analizar causas ante un posible fallo del sistema.



(B) Estaciones de Exportación de Datos

Consola dedicada a la gestión y en ocasiones almacenamiento del histórico de variables del proceso con objeto de crear un puente de comunicación entre el Sistema de Control Distribuido y una red tipo LAN en donde dichos datos serán utilizados por diferentes aplicaciones de gestión.

Igualmente actúan como una barrera física de cara a proteger la red de datos del Sistema de Control frente a cualquier perturbación externa.

En algunos casos la funcionalidad asociada a este tipo de consolas, reside en la denominada consola de ingeniería.

(C) Varios

A mayores y en función de cada fabricante y de las soluciones de control ofrecidas por el mismo, es posible encontrar Sistemas de Control Distribuido con consolas dedicas a tareas concretas tipo: gestión de la información HART procedente de los instrumentos de campo, configuración y gestión de aplicaciones de control avanzado, configuración y gestión de alarmas, simuladores de proceso, etc

1.4.3. Comunicaciones

Es lógico pensar que para que los elementos de un Sistema de Control Distribuido funcionen como un conjunto es necesario que exista entre ellos un protocolo de comunicaciones de tal modo que la información procedente de campo y procesada por el controlador llegue a la consola de operación y viceversa.

El nivel más bajo de comunicaciones es el que tiene lugar entre los distintos tipos de tarjetas y el controlador asociado. Destinado el intercambio de información entre campo y la unidad de control asociada. Es importante no confundir este nivel de comunicaciones con las descritas para integración de terceros.

Normalmente este tipo de comunicaciones está basado en protocolo propietario es decir propio del fabricante del Sistema de Control Distribuido. Tal como habíamos adelantado al describir los elementos hardware de una solución genérica, los bastidores sobre los que se instalan tarjetas y controladores son un elemento activo en este tipo de comunicaciones.

El segundo nivel de comunicaciones es el que tiene lugar entre distintos controladores de un mismo Sistema de Control. Esta funcionalidad surge de la necesidad de intercambiar información entre diferentes unidades de control de un mismo proyecto.

El tercer nivel de comunicaciones es el que tiene lugar entre los controladores y las consolas implicadas en tareas de operación, ingeniería y aplicaciones varias. Orientado a la interacción entre campo, procesador y ser humano.

El cuarto nivel de comunicaciones es el que tiene lugar entre las distintas consolas de un mismo Sistema de Control Distribuido. Necesario principalmente desde un punto de vista ofimático de gestión global de la información: disponibilidad a nivel de operación de la base de datos del proyecto residente en la consola de ingeniería, intercambio de información entre consolas con distinta funcionalidad, gestión de copias de seguridad, exportación de datos a impresoras y/o otras redes, etc.



Tarjetas de

Entradas

Controlador

Consola de

Operación

Tarjetas

de Salidas

Tarjetas de

Comunicaciones

Consola

de Ingeniería

Consola Exportación

Datos

Controlador

Controlador

Señales

de Campo

Señales

de Campo

Señales de

Terceros

Bastidor

LAN

Fig. 1-4-1 Comunicaciones en un Sistema de Control Distribuido



Los protocolos en los que se basan estos tres últimos niveles de comunicaciones dependen de la solución diseñada por el fabricante. Varias son las opciones existentes aunque es importante reseñar que los Sistemas de Control Distribuido de última generación están basando dichas comunicaciones (al menos las relativas al tercer y/o cuarto nivel) en protocolos estándar de propósito general tipo Ethernet TCP/IP.

Igualmente dependerá del fabricante de la solución de control, el tipo de jerarquía y de conexión física y funcional que exista entre estos cuatro niveles. Al conjunto resultante se le denominará red de control.

La parte práctica asociada a este módulo de formación permitirá analizar los casos particulares de varias soluciones existentes en el mercado en lo que a comunicaciones se refiere. Como complemento a la misma introduciremos una serie de conceptos que permitirán al alumno entender y valorar las diferentes soluciones de control con las que ejecute sus proyectos futuros.

Protocolo Propietario / Protocolo Estándar

En grandes términos dos son los tipo de protocolos que siguen las comunicaciones en las que se basa un Sistema de Control Distribuido:

- Protocolo Propietario

Diseñado por el fabricante de la solución de control.

Al tratarse de una solución particular no estandarizada, hace que los elementos hardware implicados solamente puedan comunicarse con elementos de su misma familia.

Este tipo de protocolos confieren al Sistema de Control Distribuido de un carácter de “Cerrado” frente a la posibilidad de comunicarse de manera estándar con elementos hardware / software de otros fabricantes.

En su origen la mayor parte de las soluciones de control basaban sus comunicaciones en este tipo de protocolos.

- Protocolo Estándar o de Propósito General

El desarrollo de las comunicaciones a nivel global, el auge de la ofimática y la necesidad de estandarizar soluciones de cara a abaratar costes y dotar a sus productos de mayor flexibilidad han llevado a los fabricantes a apostar por el uso de lo que se denominan protocolos de comunicaciones estándar o de propósito general.

En este caso es una fundación u organismo el responsable del diseño y mantenimiento de los estándares asociados a dicho protocolo. El fabricante deja de crear / inventar para utilizar productos ya existentes.

Este tipo de protocolos confieren al Sistema de Control Distribuido de un carácter de “Abierto” frente a la posibilidad de comunicarse de manera estándar con elementos hardware / software de otros fabricantes.

El protocolo más utilizado es el denominado Ethernet TCP/IP.



Comunicaciones Deterministas y No Deterministas

Independientemente del tipo de protocolo en el que se base una solución de control, es importante conocer como dicho protocolo gestiona las comunicaciones entre los distintos elementos de la red de control.

En relación con este aspecto es necesario hablar de

- Determinismo

La comunicación de datos entre diferentes elementos de la red de control se realiza en el momento preciso (cuando dicha comunicación es solicitada y de acuerdo a una serie de prioridades) y a intervalos de tiempo deseados y exactos (de acuerdo con el ciclo de ejecución definido)

El usuario de la red tiene la seguridad de que las comunicaciones se realizarán de acuerdo con parámetros predefinidos y que la información de control tendrá prioridad frente a otras comunicaciones de la red.

Para garantizar el cumplimiento de lo arriba expuesto, el número de elementos que pueden formar parte de la red de control está limitado numéricamente.

- No Determinismo

La comunicación de datos entre diferentes elementos de la red de control se realiza en orden de demanda. La garantía de que la información de control se tramita dentro de un intervalo de tiempo deseado es consecuencia de la velocidad asociada a este tipo de comunicaciones.

Inicialmente no existe una limitación física en el número de elementos que pueden formar parte de la red de control.

Velocidad

Previamente hemos hablado de la existencia en un Sistema de Control Distribuido de cuatro posibles niveles de comunicaciones cada uno de ellos con características propias o similares entre sí, dependiendo de la solución de control elegida.

Una de los parámetros asociados a cada uno de estos niveles de comunicación es la velocidad con la que se intercambia la información entre los diferentes elementos implicados.

En los Sistemas de Control Distribuido la velocidad se define como el número de bits de información que dos elementos pueden intercambiar por unidad de tiempo. Las unidades de medida más comunes son los Mb/s (Mega bits por segundo)

Es importante tener en cuenta que en el global de la red de control, la velocidad real de intercambio de información viene fijada por el nivel de comunicaciones más lento que exista en la misma.



Redundancia

Al igual que los elementos hardware, la red de control asociada a un Sistema de Control Distribuido puede diseñarse en modo redundante, es decir desde el punto de vista constructivo y de gestión de las comunicaciones existirán dos redes físicas a través de las cuales se intercambia la información entre los distintos elementos.

El modo en el que cada solución de control gestiona esta redundancia depende del fabricante:

- opción 1: una red de comunicaciones está en servicio (primaria) y la redundante (secundaria) en “espera” es decir lista para entrar en funcionamiento si el diagnostico del sistema detecta que la red primaria tiene una mal función.

- opción 2: ambas redes de comunicaciones (primaria y secundaria) están en servicio simultáneamente. El diagnóstico del sistema únicamente informa sobre la disponibilidad de ambas redes y el posible mal funcionamiento de las mismas.

Elementos Físicos Asociados

Varios son los elementos adicionales en la construcción física de una red de control y/o la unión funcional de los diferentes niveles de comunicaciones. La necesidad real de cada uno de ellos dependerá de la solución de control elegida o fabricante.

- Cable

Es el medio físico que permite la conexión entre distintos elementos de una red de control y su especificación técnica depende del protocolo de comunicaciones en el que esté basado dicha red.

Un mismo Sistema de Control de Distribuido puede requerir de diferentes tipos de cables en función de la distancia existente entre los elementos a comunicar, la velocidad de comunicación deseada así como del nº final de elementos que deberá de soportar la red de control.

- Bridges / Puente

Dispositivo hardware que permite la conexión física entre distintos tipos de cable de una misma red de control.

Sirve igualmente para transmitir paquetes de información entre segmentos de una misma red así como para filtrar (a modo de barrera) los paquetes que entran o salen (similar al Router)

- Router / Enrutador

Dispositivo hardware y/o software que distribuye tráfico entre redes TCP/IP, determinado la mejor ruta para el envío de la información.

- Gateway / Pasarela

Dispositivo hardware y/o software con capacidad para traducir protocolos con objeto de permitir la conexión física y funcional entre distintas redes.



- Firewall / Cortafuego

Dispositivos "Perimetrales" del tipo hardware que aíslan y protegen una red, o incluso un solo ordenador, del exterior.

- Servidor

Ordenador (procesador) que suministra información y/o datos a otros ordenadores, los cuales ejecutan los programas clientes.

- Hub

Dispositivo hardware que actúa a nivel de concentrador con objeto de enviar información entre elementos de una misma red de control.

La característica principal es que en cada comunicación el hub hace llegar la información a todos los elementos de la red para asegurarse de que la recibe el verdadero destinatario.

- Switch

Dispositivo hardware que permite enviar información entre elementos de una misma red de control.

La característica principal es que en cada comunicación el switch hace llegar la información, previo almacenamiento en su memoria o buffer, al verdadero destinatario.

1.4.4. Elementos Software

Son funciones de carácter lógico destinadas a realizar tareas de cálculo, supervisión y operación.

Al igual que los elementos hardware, el software asociado a un Sistema de Control Distribuido depende del fabricante del mismo en alcance, formato y funcionalidad.

Dichas funciones están necesariamente asociadas a:

Programas de Desarrollo

Herramientas de programación, normalmente:

- Estandarizadas por el fabricante de la solución de control

- Asociadas a lenguajes / modos de programación de alto nivel.

- Orientadas conceptualmente al control de procesos

Librerías

Programas y/o soluciones estándar de control, diseñados y desarrollados por el fabricante del Sistema de Control Distribuido y accesibles desde un entorno de trabajo amigable al usuario final.



Licencias

Sistema de escalado del Sistema de Control Distribuido, relativo al nº máximo de entradas y salidas que podrá gestionar la solución de control así como a las funcionalidades asociadas al mismo (programas de desarrollo, librerías, herramientas de diagnóstico, usuarios, etc)

2. BUSES DE CAMPO

2.1. Definición de Bus y Características Asociadas

Consecuencia del desarrollo del mundo digital y del uso masivo de microprocesadores, el control de procesos está experimentando una evolución desde su concepción puramente analógica hacia el uso de tecnologías digitales.

Dicha evaluación desarrollada con éxito a nivel de elementos y herramientas de supervisión y control, se ha iniciado de manera similar en la instrumentación de medida y en los elementos finales de control.

Consecuentemente:

- El uso de microprocesadores de nueva generación en los instrumentos de campo otorga a éstos funcionalidades adicionales a las propias de un transmisor.

- Surgen las comunicaciones digitales entre el control y los elementos de campo.

2.1.1. Definición de Bus

Sistema de comunicación digital serie multipunto que permite interconectar instrumentos de campo con los elementos hardware de una solución de control.

2.1.2. Características

(A) La conexión digital instrumentos / control le confiere carácter de red de comunicaciones.

(B) El uso de tecnología digital permite la comunicación masiva de datos mediante un único medio físico de comunicaciones.

(C) El uso de microprocesadores junto con la comunicación masiva de datos permite tareas de control, gestión y diagnosis a nivel de instrumentos de campo.

(D) El protocolo de comunicación utilizado sigue un patrón estándar con objeto de permitir la interconexión de elementos procedentes de distintos fabricantes.

(E) El desarrollo y mantenimiento del estándar es responsabilidad de un Comité o Fundación.

(F) Cumple requisitos de seguridad intrínseca.

(G) Permite configuraciones redundantes.

(H) Dispone de herramientas propias de configuración, integradas en el software asociado a un Sistema de Control Distribuido.

(I) Permite ampliar la red de comunicaciones con nuevos elementos de campo y/o de la solución de control.



2.2. Modelo OSI

2.2.1. Definición

El desarrollo de una red de comunicaciones, en nuestro caso un bus de campo, significa que los diseñadores de la misma deben ocuparse de todos los elementos involucrados en el proceso, es decir:

- Los dispositivos físicos de conexión,

- Los protocolos software y hardware usados en la comunicación

- Los programas de aplicación que realizaban la comunicación

- La interfaz hombre-máquina que permiten al humano utilizar la red.

Con objeto crear un procedimiento estándar de diseño, surge el denominado Modelo de Comunicaciones OSI (the reference model of Open Systems Interconnection). Su filosofía se basa en descomponer la funcionalidad de la cadena de transmisión a comunicar en diversos módulos cuya interfaz con los adyacentes esté estandarizada. Para ello el modelo OSI tiene dos componentes principales:

- Un modelo de red, denominado modelo básico de referencia (Basic Reference Model) o capa de servicio (Server-layer).

- Una serie de protocolos concretos.

El modelo de red está basado en una concepción de siete capas o niveles, en las que se basan todos los desarrollos:

- 1 Físico

- 2 de Enlace

- 3 de Red

- 4 de Transporte

- 5 de Sesión

- 6 de Presentación

- 7 de Aplicación

Cada nivel realiza una función concreta, y está separado de los adyacentes por interfaces conocidas, sin que le incumba ningún otro aspecto del total de la comunicación. En lo que respecta al software cada uno de ellos utiliza un protocolo específico para comunicarse con las capas adyacentes.

Ejemplos: Generalmente los dispositivos utilizados en las redes circunscriben su operación a uno o varios de estos niveles. Por ejemplo, un concentrador Hub que amplifica y retransmite la señal a través de todos sus puertos, está operando exclusivamente en la capa 1 un conmutador Switch opera en las capas 1 y 2 y un enrutador Router opera en las capas 1, 2 y 3. Finalmente una estación de trabajo de usuario generalmente maneja las capas 5, 6 y 7.

2.2.2. Las Capas del Modelo OSI



1 Capa física

Physical layer

Es la encargada de transmitir los bits de información por la línea o medio utilizado para la transmisión. Se ocupa de las propiedades físicas y características eléctricas de los diversos componentes; de la velocidad de transmisión, si esta es uni o bidireccional (simplex, duplex o full-duplex). También de aspectos mecánicos de las conexiones y terminales, incluyendo la interpretación de las señales eléctricas.

Como resumen de los cometidos de esta capa, podemos decir que se encarga de transformar un paquete de información binaria (Frame) en una sucesión de impulsos adecuados al medio físico utilizado en la transmisión. Estos impulsos pueden ser eléctricos (transmisión por cable); electromagnéticos (transmisión Wireless) o luminosos (transmisón óptica). Cuando actúa en modo recepción el trabajo es inverso; se encarga de transformar estos impulsos en paquetes de datos binarios que serán entregados a la capa de enlace (ver a continuación).

Ejemplo: este nivel define la medidas del cable coaxial Ethernet y de los conectores BNC utilizados. Otro ejemplo de estándares relativos a esta capa son RS-232 para comunicaciones serie.

2 Capa de enlace

Data Link layer

Puede decirse que esta capa traslada los mensajes hacia/desde la capa física a la capa de red (que veremos a continuación). Especifica como se organizan los datos cuando se transmiten en un medio particular.

Además del direccionamiento local, se ocupa de la detección y control de errores ocurridos en la capa física, del control del acceso a dicha capa y de la integridad de los datos y fiabilidad de la transmisión. Para esto agrupa la información a transmitir en bloques (Frames) e incluye a cada uno una suma de control (Checksum) que permitirá al receptor comprobar su integridad. Los datos recibidos son comprobados por el receptor. Si algún dato se ha corrompido se envía un mensaje de control al remitente solicitando su reenvío.

Ejemplo: esta capa define como son los cuadros (Frames), las direcciones y las sumas de control (Checksum) de los paquetes Ethernet.

3 Capa de Red

Network layer

Esta capa se ocupa de la transmisión de los datos (Paquetes) y de encaminar cada uno en la dirección adecuada (Routing) pero no se ocupa de los errores o pérdidas de paquetes.

Ejemplo: define la estructura de direcciones y rutas de Internet.

4 Capa de Transporte



Transport layer

Esta capa se ocupa de garantizar la fiabilidad del servicio, describe la calidad y naturaleza del envío de datos, definiendo cuando y como debe utilizarse la retransmisión para asegurar su llegada. Para ello divide el mensaje recibido de la capa de sesión (que veremos a continuación) en trozos (Paquetes), los numera correlativamente y los entrega a la capa de red para su envío.

5 Capa de Sesión

Session Layer

Es una extensión de la capa de transporte que ofrece control de diálogo y sincronización, aunque en realidad son pocas las aplicaciones que hacen uso de ella.

6 Capa de Presentación

Presentation layer

Esta capa se ocupa de los aspectos semánticos de la comunicación (describe la sintaxis de los datos a transmitir), estableciendo los arreglos necesarios para que puedan comunicar máquinas que utilicen diversa representación interna para los datos.

Ejemplo: describe como pueden transferirse números de coma flotante entre equipos que utilizan distintos formatos matemáticos.

7 Capa de Aplicación

Application layer

Esta capa describe como hacen su trabajo los programas de aplicación (navegadores, clientes de correo, terminales remotos, transferencia de ficheros etc). Por un lado interactúa con la capa de presentación; por otro representa la interfaz con el usuario, entregándole la información y recibiendo los comandos que dirigen la comunicación.



2.3. Clasificación General de Buses

Los criterios “campo de aplicación” y “tipos de datos comunicados” son los requisitos utilizados para la clasificación de buses que presentamos a lo largo de este documento.

La elección por parte del usuario final entre un tipo de bus u otro está ligada en la mayoría de las ocasiones al tipo de protocolo de comunicaciones que sea capaz de soportar el hardware implicado en la solución de control así como al coste económico asociado.

2.3.1. Buses de Sensor

Bus que gestiona señales digitales entre elementos de campo discretos (con dos posibles estados: 0, 1) y un procesador, en servicios que requieren de alta velocidad de transmisión, garantizando tiempos de ejecución fijos.

Los datos se transmiten en formato de bits.

Ejemplo: ASi

2.3.2. Buses de Dispositivos

Bus que gestiona señales digitales y analógicas.

Los datos se transmiten en formato de mensajes de bytes.

Ejemplo: Modbus

2.3.3. Buses de Campo

Bus de alto nivel de complejidad que gestiona la comunicación entre dispositivos de campo y elementos de control.

Los datos se transmiten mediante paquetes de información.

Cumple requisitos de seguridad intrínseca.

Ejemplo: Profibus, Fieldbus Foundation.

2.4. Profibus

http://www.profibus.org/

Bus de Campo basado en un protocolo de comunicación estandarizado (independiente del fabricante implicado) que permite crear redes de control de carácter abierto, es decir con posibilidad de comunicarse con elementos hardware / software de distintos fabricantes.

La fundación u organismo responsable del diseño y mantenimiento de los estándares asociados a dicho protocolo recibe el nombre de PNO.

El nacimiento de Profibus surge como intento de conseguir una red estándar para todos los fabricantes industriales en la que poder integrar equipos activos o maestros (implicados en tareas de control) es decir PCs, autómatas, controladores, etc sino también elementos de tipo pasivo o esclavos es decir elementos finales de control, instrumentos, interfases hombre-máquina, paneles locales, etc.

En su concepción Profibus sigue el modelo OSI e implementa los niveles 1, 2 y 7 del mismo:

Nivel 1 Físico

Nivel 2 de Enlace



Nivel 7 de Aplicación

Desde el punto de vista de usuario, Profibus dispone de tres perfiles:

Profibus FMS

Profibus DP

Profibus PA

Antes de abordar el estudio del nivel 1 (físico) dada su directa implicación en tareas de diseño y especificación de un bus de campo, abordaremos la descripción de los distintos perfiles de usuario de Profibus.

2.4.1. Perfiles Profibus

Profibus FMS

FMS (Fieldbus Message Specification)

Protocolo que utiliza los niveles 1 (físico), 2 (de enlace) y 7 (de aplicación) del modelo OSI.

Como su propio nombre indica está dedicado al intercambio de datos e información en el nivel alto de la pirámide de control, es decir entre la interfase de usuario de la red de control y los procesadores implicados en la misma.

Profibus DP

Protocolo que utiliza los niveles 1 (físico) y 2 (de enlace) del modelo OSI.

Esta variante está dedicada a las comunicaciones entre procesadores (maestro) y elementos de entra / salida (esclavos), garantizando un tráfico de datos rápido.

Profibus PA

Basado en Profibus DP aunque su funcionalidad está orientada a la integración en la red de instrumentos y actuadores que puedan requerir en algunos casos de seguridad intrínseca y/o alimentación de energía del equipo de campo.

2.4.2. Nivel Físico

Es la encargado de transmitir los bits de información por la línea o medio utilizado para la transmisión. Se ocupa de las propiedades físicas y características eléctricas de los diversos componentes; de la velocidad de transmisión, si esta es uni o bidireccional (simplex, duplex o full-duplex). También de aspectos mecánicos de las conexiones y terminales, incluyendo la interpretación de las señales eléctricas.

Es el nivel de mayor implicación en el diseño de un bus de campo desde el punto de vista de la ingeniería ya que deberán de especificarse aspectos del tipo:

- Características físicas:

Tipo de cable

Longitud máxima permitida para la red



Número máximo de participantes / dispositivos en la red

Velocidad (bits / seg)

Alimentación eléctrica de los dispositivos de campo

Seguridad intrínseca

- Elementos auxiliares

Características Físicas

Profibus FMS y Profibus DP pueden utilizar de manera indistinta y en función de las necesidades de la aplicación cable del tipo bifilar trenzado apantallado y conductores de fibra óptica de vidrio o plástico.

La longitud máxima admitida para el cable y consecuentemente para la red depende de la velocidad de transmisión deseada así como del tipo de cable seleccionado, el uso de fibra óptica de vidrio frente al resto de alternativas permite afrontar mayores distancias) y normalmente cuanto mayor es la longitud de los segmentos de la red menor velocidad de transmisión de la información (bits / seg)

Profibus FMS y DP admiten un número máximo de 32 participantes o dispositivos conectados a la red.

Profibus PA puede utilizar cable a dos hilos. La propiedades del tipo de cable determinan la longitud máxima de la red y el número de participantes o dispositivos conectados.

Dado que el perfil Profibus PA cumple requisitos de seguridad intrínseca, las redes instaladas en zona clasificada admitirán un máximo de 10 participantes o dispositivos con objeto de garantizar la limitación de corriente por el bus, mientras que si las redes se encuentran en zona segura el número máximo de dispositivos oscila entre 31 y 24 dependiendo del tipo de enlace físico utilizado para conexión entre perfiles DP y PA.

Elementos Auxiliares

- Conectores de bus: tal como su nombre indica permiten la conexión física entre el dispositivo y la red.

Para el caso de los perfiles FMS y DP el conector y el número de dispositivos que conecta físicamente con el bus depende del tipo de cable utilizado.

Para el caso del perfil PA los conectores están estandarizados pudiendo ser del tipo:

Bifurcación en T: para la conexión al bus de un dispositivo o segmento del bus.

Cajas de conexión: para conexión en modo estrella de varios dispositivos.

- Terminadores de bus

- Acopladores DP/PA: permite la conexión física entre el perfil DP y PA realizando las siguientes funciones adicionales

Alimenta a los dispositivos de campo conectados a la red Profibus PA



Garantiza limitación en corriente por lo que su uso permite la instalación de redes Profibus PA en zona clasificada de acuerdo con los requisitos de seguridad intrínseca.

Existen dos tipos de acopladores: una variante para instalaciones en zona segura permitiendo la conexión y alimentación de un máximo de 31 dispositivos de campo y una segunda variante con certificación Ex para zona clasificada permitiendo la conexión y alimentación de un máximo de 10 dispositivos.

- Enlace DP/PA: elemento físico de conexión entre el perfil DP y PA compuesto por 2 acopladores DP/PA para instalaciones en zona segura y 5 acopladores DP/PA para instalaciones en zona clasificada. En ambos casos el número máximo de dispositivos conectados al enlace DP/PA es de 24.

2.4.3. Tabla Resumen

Profibus FMS Profibus DP Profibus PA

Velocidad 12 Mbits/seg 12 Mbits/seg 31,25 Kbits/seg

Cable Trenzado apantallado F.O

Trenzado apantallado F.O A 2 hilos

Participantes / dispositivos 32 32 Máx. 31 Máx. 10 (Ex)

Alimentación a través del bus No No Si

Seguridad Intrínseca No No Si

Redundancia No Si No

Tabla. 2-4-1 Nivel Físico Profibus



2.5. Fieldbus Foundation

http://www.filedbus.com/

Bus de Campo basado en un protocolo de comunicación estandarizado (independiente del fabricante implicado) que permite crear redes de control de carácter abierto, es decir con posibilidad de comunicarse con elementos hardware / software de distintos fabricantes.

La fundación u organismo responsable del diseño y mantenimiento de los estándares asociados a dicho protocolo recibe el nombre de Fieldbus Foundation.

El nacimiento de Fieldbus Foundation surge como intento de conseguir una red estándar para todos los fabricantes industriales en la que poder integrar dispositivos de campo y equipos de control y/o monitorización.

En su concepción Fieldbus Foundation sigue el modelo OSI e implementa los niveles 1, 2 y 7 del mismo:

Nivel 1 Físico

Nivel 2 de Enlace

Nivel 7 de Aplicación de Usuario

Desde el punto de vista de usuario, una red de bus tipo Fieldbus Foundation está compuesta por dos tipos de segmentos:

Segmento H1

Segmento H2

Antes de abordar el estudio del nivel 1 (físico) dada su directa implicación en tareas de diseño y especificación de un bus de campo, abordaremos la descripción de los distintos segmentos.

2.5.1. Segmentos Fieldbus Foundation

Segmento H1

Tramos de red que permiten la conexión de instrumentos y actuadores que puedan requerir en algunos casos de seguridad intrínseca y/o alimentación de energía.

Segmento H2

Tramo de red que permite la conexión de dispositivos destinados a interfases de operación así como procesadores de control, con objeto de concentrar todas las comunicaciones asociadas a tareas de ingeniería, configuración, operación y mantenimiento así como al tratamiento masivo de dispositivos de entradas / salidas de alta densidad.



2.5.2. Nivel Físico

Es la encargado de transmitir los bits de información por la línea o medio utilizado para la transmisión. Se ocupa de las propiedades físicas y características eléctricas de los diversos componentes; de la velocidad de transmisión, si esta es uni o bidireccional (simplex, duplex o full-duplex). También de aspectos mecánicos de las conexiones y terminales, incluyendo la interpretación de las señales eléctricas.

Es el nivel de mayor implicación en el diseño de un bus de campo desde el punto de vista de la ingeniería ya que deberán de especificarse aspectos del tipo:

- Características físicas:

Tipo de cable

Longitud máxima permitida para la red

Número máximo de participantes / dispositivos en la red

Velocidad (bits / seg)

Alimentación eléctrica de los dispositivos de campo

Seguridad intrínseca

- Elementos auxiliares

Características Físicas

Los segmentos H2 utilizan el estándar de Ethernet de alta velocidad en configuración redundante y pueden utilizar de manera indistinta y en función de las necesidades de la aplicación cable del tipo trenzado apantallado y conductores de fibra óptica.

En los segmentos H2 la velocidad de transmisión de la información es de 100 Mbits / seg, admitiendo un número casi ilimitado de participantes o dispositivos (más de 65.000)

Los segmentos H1 utilizan cable a dos hilos, siendo el número máximo de participantes o dispositivos de 32 y la velocidad de transmisión de la información de 32,25 Kbits / seg. . La propiedades del tipo de cable determinan la longitud máxima de la red.

Dado que el perfil de los segmentos H1 cumple requisitos de seguridad intrínseca, las redes instaladas en zona clasificada admitirán un máximo de 4 dispositivos con objeto de garantizar la limitación de corriente por el bus, mientras que si las redes se encuentran en zona segura el número máximo de dispositivos es de 32. En ambos casos este número máximo de participantes se reduce a medida que aumentan los requisitos de distancias para la red así como los posibles consumos eléctricos de los elementos de campo.



Elementos Auxiliares

- Conectores de bus: tal como su nombre indica permiten la conexión física entre el dispositivo y la red.

Para el caso de los segmentos H1 los conectores están estandarizados pudiendo ser del tipo:

Bifurcación en T: para la conexión al bus de un dispositivo o segmento del bus.

Cajas de conexión: para conexión en modo estrella de varios dispositivos.

- Terminadores de bus

- Fuentes de Alimentación: alimenta a través del bus a los dispositivos de campo conectados a los segmentos H1. Existen modelos aptos para seguridad intrínseca garantizando la limitación en corriente en zonas clasificadas.

- Aisladores Galvánicos: barreras de seguridad intrínseca que permiten conectar equipos de campo situados en zona clasificada, coexistiendo en el bus con dispositivos ubicados en zona segura.

2.5.3. Tabla Resumen

Segmento H1 Segmento H2

Velocidad 31,25 Kbits/seg 100 Mbits/seg

Cable A 2 hilos Trenzado apantallado F.O.

Participantes / dispositivos Máx. 32 Máx. 4 (Ex) Más de 65.000

Alimentación a través del bus Si No

Seguridad Intrínseca Si No

Redundancia No Si

Tabla. 2-5-1 Nivel Físico Fieldbus Foundation

Módulo: Sistemas de control Profesora: Marisa Sanzo

Instituto Superior de la EnergíaMaster en Instrumentación y Control 1

ABRIL 2006 8A1 SISTEMAS DE CONTROL

Sección Española

SISTEMAS DE CONTROL

Marisa Sanzo


Sección Española

INTRODUCCIÓN

QuéParaModoEnfoqueAprendizaje




Sección Española

INTRODUCCIÓN

Qué: Abordar conceptos

Para: Adquirir / asentar los conocimientos necesarios para el correcto diseño y especificación de una solución de control


Sección Española

INTRODUCCIÓN

Qué: Crear un referente

Para: Establecer el guión / contenido lógico de futuras especificaciones para sistemas de control




Sección Española

INTRODUCCIÓN

Qué: Utilizar términos genéricos

Para: Obviar características concretas de productos y soluciones existentes en el mercado


Sección Española

INTRODUCCIÓN

Modo: Generar una documentación base apoyada en escasa bibliografía y recurriendo a la experiencia e intercambio de opiniones




Sección Española

INTRODUCCIÓN

Enfoque:Marisa Sanzo, 14 años en el sectorExperiencia en diseño, especificación y ejecución de proyectos de instrumentación y control, desarrollada tanto bajo filosofía 4-20 mA Hart como mediante el uso de buses de campo (Profibus y FieldbusFoundation) Proyectos a nivel de usuario o como suministrador en: alimentación (Azucarera Española), oil & gas (Repsol y Enagas), papel (Saica) y cemento (TDCIM)En la actualidad jefe de compras en Emerson Process Management S.L.


Sección Española

INTRODUCCIÓN

Aprendizaje:ConceptosDebatePrácticasEjercicios




Sección Española

SISTEMA DE CONTROL

1.1 Definición Sistema de Control (SC) …Toda solución que usando• Un sistema de captación de señales• Un procesador• Una interfase hombre / máquinaPermita el control automático de variables físicas.


Sección Española

SISTEMA DE CONTROL

y Conceptos Asociados•Control: acción destinada a que una o varias variables físicas tengan un valor similar a un patrón, consigna u objetivo•Control automático: acción de control ejecutada y supervisada por un procesador electrónico




Sección Española

SISTEMA DE CONTROL

•Señal de campo: información en formato electrónico relativa al valor o estado de una variable física.•Señal de campo digital: información en formato electrónico relativa al estado de una variable física (0 ó 1)•Señal de campo analógica: información en formato electrónico relativa al valor de una variable física (de 0 a 100%)


Sección Española

SISTEMA DE CONTROL

•Variables físicasEntrada objeto de supervisión y/o control Salida objeto de acción y/o manipulación




Sección Española

SISTEMA DE CONTROL

1.2. Sistema de Control Distribuido (SCD)Sistema de Control en donde la solución para el control automático de las variables físicas implicadas está localizada junto a dichas variables


Sección Española

SISTEMA DE CONTROL

O coloquialmente …•Sistema de Control destinado a un nº significativo de variables físicas• Procesador e interfase forman un conjunto indivisible: herramientas y parámetros comunes•Procesador e interfase están / son:

Estandarizados por el fabricanteEscalables según el tamaño del proyectoTipificables según la solución de control




Sección Española

SISTEMA DE CONTROL

y un PLC?•Procesador con ejecución del control automático por orden / ciclo lógico de pasos•En origen para control automático de variables físicas tipo estado (0 ó 1) con tiempos de ejecución rápidos•No es un SCD: no cumpliría el requisito de ser Escalable•Uno o varios PLCs pueden formar parte de un SCD integración de terceros


Sección Española

SISTEMA DE CONTROL

1.3. y un SCADA?•Procesador e interfase diseñados a medidasegún necesidades del proyecto• Normalmente procesador e interfase de diferente fabricante•Un SCADA no es un SCD: no cumpliría los requisitos de ser Escalable ni Tipificable•Varios SCADAS pueden formar parte de un SCD integración de terceros




Sección Española

SISTEMA DE CONTROL

1.4. Elementos de un SCD: Hardware …Son elementos físicos de naturaleza eléctrica y/o electrónica para captación y procesamiento de las señalesDiseñados / Instalados en:

Modo Simple o con Redundancia (n+n ó n+1)


Sección Española

SISTEMA DE CONTROL

•CPU (o Controladores)Unidad central de proceso (procesador) destinada a realizar funciones de cálculo así como tareas de supervisión del conjunto hardware Normalmente tipificadas según la solución de control que deban ejecutar y/o según la normativa aplicable al procesoPueden ser escalables en capacidad de procesamiento y gestión de recursosPueden instalarse en modo redundante: 1+1




Sección Española

SISTEMA DE CONTROL

•Elementos de Entrada (o Tarjetas de Entrada)Unidades destinadas a captar eléctricamentepunto a punto las señales de campoPermite la captación simultánea de varias señales de campo cada una conectada mediante cableado físico a un canal eléctricoTipificadas constructiva y técnicamente según el tipo de señal eléctrica que vayan a tratarPueden instalarse en modo redundante: 1+1


Sección Española

SISTEMA DE CONTROL

Ejemplos de Tipificación

Tarjeta para señales analógicas 4-20 mA (2 hilos)Tarjeta para señales analógicas 4-20 mA (4 hilos)Tarjeta para señales analógicas 0-10 VTarjeta para señales digitales tipo contacto libre de tensiónTarjeta para señales digitales tipo alimentación externaTarjeta para señales tipo pulsoTarjeta para señales tipo RTDTarjeta para señales tipo Termopar

Tarjeta estándar: 8 canalesTarjeta de alta densidad: 32 / 64 canalesTarjeta específica: 4 canales




Sección Española

SISTEMA DE CONTROL

•Elementos de Salida (o Tarjetas de Salida)Unidades destinadas a enviar eléctricamentepunto a punto las señales a campoPermite el envío simultáneo de varias señales de campo cada una conectada mediante cableado físico a un canal eléctricoTipificadas constructiva y técnicamente según el tipo de señal eléctrica que vayan a tratarPueden instalarse en modo redundante: 1+1


Sección Española

SISTEMA DE CONTROL


Tarjeta para señales analógicas 4-20 mATarjeta para señales digitales

Tarjeta estándar: 8 canalesTarjeta de alta densidad: 32 / 64 canalesTarjeta específica: 4 canales




Sección Española

SISTEMA DE CONTROL

•Elementos para Comunicación con TercerosLlamadas Tarjetas de ComunicacionesUnidades destinadas a captar eléctricamente un conjunto masivo de señales: comunicación del tipo digitalTipificadas constructiva y técnicamente según el tipo de protocolo de comunicación digital que utilicenPueden ser escalables en número de puertos de comunicacionesPueden instalarse en modo redundante: 1+1


Sección Española

SISTEMA DE CONTROL


ModbusASiProfibusFieldbus Foundation

El protocolo determina el volumen de señales a integrar asícomo el tipo de señal digital y/o analógico




Sección Española

SISTEMA DE CONTROL

•BastidoresUnidades físicas en donde se alojan los distintos elementos hardwareNo son elementos pasivos: intervienen de manera activa en las comunicaciones entre procesador y elementos de entradas y salidas.


Sección Española

SISTEMA DE CONTROL

•Fuentes de AlimentaciónUnidades destinadas a suministrar alimentación eléctrica (en continua o en alterna) al hardware y a elementos de campo que lo requieranNormalmente tipificadas (AC/AC, AC/DC, DC/DC) según la solución de control elegidaDiferentes grados de segregación: fuentes independientes o comunes para cada uno de los servicios implicadosPueden instalarse en modo redundante: 1+1, n+1




Sección Española

SISTEMA DE CONTROL

Consolas o Estaciones …Elemento físico para interacción entre el procesador y el ser humano: intercambio de informaciónFormato tipo PC:

PC estándar, sistema operativo WindowsPC industrial, sistema operativo Windows o Propietario

Redundancia: nivel de CPU o elementos susceptibles de fallo


Sección Española

SISTEMA DE CONTROL

•Consolas de OperaciónPara supervisión y/o actuación sobre cualquier parte del procesoCarecen de atributos y/o privilegios que permitan modificar la solución de control




Sección Española

SISTEMA DE CONTROL

•Consolas de IngenieríaPara configuración de la solución de control y diagnostico del SCDEn ellas reside la base de datos del proyecto y en ocasiones la gestión de la unidad de copias de seguridadGozan de atributos y/o privilegios que permitan modificar la solución de control


Sección Española

SISTEMA DE CONTROL

•Equipos Auxiliares- Impresoras para impresión de información de proceso, alarmas, eventos, etc.- Estaciones para exportación de datos: hacia aplicaciones residentes en red LAN- Varios: ejemplo estaciones gestión de información hart procedente de instrumentos




Sección Española

SISTEMA DE CONTROL

Comunicaciones …Es necesario que exista entre los elementos de un SCD un protocolo de comunicaciones.Objetivo: que la información procedente de campo y procesada por el controlador llegue a la consola de operación y viceversa


Sección Española

SISTEMA DE CONTROL

Tarjetas

de Entradas

Controlador

Consola de

Operación

Tarjetas de

Salidas

Tarjetas de

Comunicaciones

Consola de

Ingeniería

Consola

Exportación Datos

Controlador

Controlador

Señales

de Campo

Señales de

Campo

Señales de

Terceros

Bastidor

LAN

Red de Control




Sección Española

SISTEMA DE CONTROL

Los protocolos en los que se basan las comunicaciones:•Dependen de la solución diseñada por el fabricante•Del tipo de jerarquía•De la conexión física y funcional que exista entre los elementos implicados.Al conjunto resultante se le denominará red de control.


Sección Española

SISTEMA DE CONTROL

•Protocolos-Protocolo Propietario

Diseñado por el fabricante, solución particular no estándarCarácter cerrado

- Protocolo Estándar o de Propósito GeneralUna fundación u organismo el responsable del diseño y mantenimiento de los estándares asociados a dicho protocolo (El más utilizado: Ethernet TCP/IP )Carácter Abierto




Sección Española

SISTEMA DE CONTROL

•Comunicaciones-Determinismo

La comunicación de datos se realiza en el momento preciso y a intervalos de tiempo deseados y exactosLa garantía: el número de elementos que forman parte de la red de control está limitado numéricamente

- No DeterminismoLa comunicación de datos se realiza en orden de demanda.La garantía: la velocidad asociada a este tipo de comunicaciones, no existe una limitación física en el número de elementos


Sección Española

SISTEMA DE CONTROL

•VelocidadNúmero de bits de información que dos elementos pueden intercambiar por unidad de tiempo. Las unidades de medida más comunes son los Mb/s (Mega bits por segundo)La velocidad real de intercambio de información viene fijada por el nivel de comunicaciones más lento que exista en la misma




Sección Española

SISTEMA DE CONTROL

•RedundanciaExistirán dos redes físicas a través de las cuales se intercambia la información entre los distintos elementos del SCD.-Opción 1

una red de comunicaciones está en servicio (primaria) y la redundante (secundaria) en “espera”

-Opción 2ambas redes de comunicaciones (primaria y secundaria) están en servicio simultáneamente


Sección Española

SISTEMA DE CONTROL

•Elementos Físicos Asociados- Cable: medio físico- Bridge / Puente: permite la conexión física entre distintos tipos de cable de una misma red de control. Transmitir paquetes de información y filtra (a modo de barrera) los paquetes que entran o salen (similar al Router)- Router / Enrutador: distribuye tráfico entre redes TCP/IP, determinado la mejor ruta para el envío de la información.- Gateway / Pasarela: traduce protocolos con objeto de permitir la conexión física y funcional entre distintas redes. - Firewall / Cortafuego: aísla y protege una red del exterior.




Sección Española

SISTEMA DE CONTROL

•Elementos Físicos Asociados- Servidor: ordenador que suministra información y/o datos a otros ordenadores que ejecutan programas clientes.- Hub: concentrador con objeto de enviar información entre elementos de una misma red de control.El hub hace llegar la información a todos los elementos de la red para asegurarse de que la recibe el verdadero destinatario.- Switch: Dispositivo hardware que permite enviar información entre elementos de una misma red de control.El switch hace llegar la información, previo almacenamiento en su memoria, al verdadero destinatario.


Sección Española

SISTEMA DE CONTROL

Software …Son funciones de carácter lógico destinadas a realizar tareas de cálculo, supervisión y operación.Depende del fabricante: en alcance, formato y funcionalidad.




Sección Española

SISTEMA DE CONTROL

•Programas de desarrolloHerramientas de programaciónEstandarizadas por el fabricanteAsociadas a lenguajes / modos de programación de alto nivel


Sección Española

SISTEMA DE CONTROL

•LibreríasProgramas y/o soluciones estándar de controlDiseñados y desarrollados por el fabricante del Accesibles desde un entorno de trabajo amigable




Sección Española

SISTEMA DE CONTROL

•LicenciasSistema de escalado Relativo al nº máximo de entradas y salidas que podrá gestionar la solución de control así como a las funcionalidades asociadas al mismo




Sección Española

BUSES DE CAMPO

Marisa Sanzo


Sección Española

BUSES DE CAMPO

2.1 Definición de Buses de CampoEl control de procesos está experimentando una evolución desde su concepción puramente analógica hacia el uso de tecnologías digitales.Bus: Sistema de comunicación digital serie multipunto que permite interconectar instrumentos de campo con los elementos hardware de una solución de control.




Sección Española

BUSES DE CAMPO

y Características Asociadas•La conexión digital instrumentos / control le confiere carácter de red de comunicaciones.•Permite la comunicación masiva de datos mediante un único medio físico de comunicaciones.•Permite tareas de control, gestión y diagnosis a nivel de instrumentos de campo.


Sección Española

BUSES DE CAMPO

•El protocolo de comunicación utilizado sigue un patrón estándar con objeto de permitir la interconexión de elementos procedentes de distintos fabricantes.•El desarrollo y mantenimiento del estándar es responsabilidad de un Comité o Fundación.•Cumple requisitos de seguridad intrínseca.




Sección Española

BUSES DE CAMPO

•Permite configuraciones redundantes.•Dispone de herramientas propias de configuración, integradas en el software asociado a un SCD.•Permite ampliar la red de comunicaciones con nuevos elementos de campo y/o de la solución de control.


Sección Española

BUSES DE CAMPO

2.2. Modelo OSI, definiciónThe reference model of Open Systems InterconnectionProcedimiento estándar de diseño de buses, basado en dos componentes:•Un modelo de red o capa de servicio.•Una serie de protocolos concretos.




Sección Española

BUSES DE CAMPO

Modelo de red: basado en una concepción de siete capas o niveles

1 Físico2 de Enlace3 de Red4 de Transporte5 de Sesión6 de Presentación7 de Aplicación

Cada nivel realiza una función concreta y utiliza un protocolo específico para comunicarse con las capas adyacentes.


Sección Española

BUSES DE CAMPO

y Capa FísicaEncargada de:-Transmitir los bits de información por la línea o medio utilizado para la transmisión-Los aspectos mecánicos de las conexiones y terminales, incluyendo la interpretación de las señales eléctricas (transmisión por cable); electromagnéticas (transmisión Wireless) o luminosas (transmisión óptica)




Sección Española

BUSES DE CAMPO

Capa de EnlaceEncargada de:•Trasladar los mensajes hacia/desde la capa física a la capa de red•Especificar como se organizan los datos•Detectar y controlar los errores ocurridos en la capa física, del control del acceso a dicha capa y de la integridad de los datos y fiabilidad de la transmisión.


Sección Española

BUSES DE CAMPO

Capa de RedEncargada de:Transmitir los datos o paquetes de información y de encaminar cada uno en la dirección adecuada.No se ocupa de los errores o pérdidas de paquetes.




Sección Española

BUSES DE CAMPO

Capa de TransporteEncargada de:Garantizar la fiabilidad del servicio definiendo cuando y como debe utilizarse la retransmisión para asegurar su llegada.


Sección Española

BUSES DE CAMPO

Capa de SesiónEs una extensión de la capa de transporte que ofrece control de diálogo y sincronización, aunque en realidad son pocas las aplicaciones que hacen uso de ella.




Sección Española

BUSES DE CAMPO

Capa de PresentaciónEncargada de:Los aspectos semánticos de la comunicación estableciendo los arreglos necesarios para que puedan comunicar máquinas que utilicen diversa representación interna para los datos.


Sección Española

BUSES DE CAMPO

Capa de AplicaciónEncargada de:Describir como hacen su trabajo los programas de aplicación (navegadores, clientes de correo, terminales remotos, transferencia de ficheros etc)Representa la interfaz con el usuario, entregándole la información y recibiendo los comandos que dirigen la comunicación.




Sección Española

BUSES DE CAMPO

2.3. Clasificación General de BusesCriterios utilizados para la clasificación:-Campo de aplicación-Tipo de datos comunicadosCriterios de elección:- Tipo de protocolo que soporte el hardware del SCD- El coste económico asociado


Sección Española

BUSES DE CAMPO

Buses de Sensor•Bus que gestiona señales digitales entre elementos de campo discretos (con dos posibles estados: 0, 1) y un procesador, en servicios que requieren de alta velocidad de transmisión, garantizando tiempos de ejecución fijos.•Los datos se transmiten en formato de bits.•Ejemplo: ASi




Sección Española

BUSES DE CAMPO

Buses de Dispositivos•Bus que gestiona señales digitales y analógicas.•Los datos se transmiten en formato de mensajes de bytes.•Ejemplo: Modbus


Sección Española

BUSES DE CAMPO

Buses de Campo•Bus de alto nivel de complejidad que gestiona la comunicación entre dispositivos de campo y elementos de control.•Los datos se transmiten mediante paquetes de información.•Cumple requisitos de seguridad intrínseca.•Ejemplo: Profibus, Fieldbus Foundation.




Sección Española

BUSES DE CAMPO

2.4. Profibushttp://www.profibus.org/•Bus de Campo basado en un protocolo de comunicación estandarizado que permite crear redes de control de carácter abierto con posibilidad de comunicarse con elementos hardware / software de distintos fabricantes.•La fundación u organismo responsable del diseño y mantenimiento de los estándares asociados a dicho protocolo recibe el nombre de PNO.


Sección Española

BUSES DE CAMPO

Profibus (continuación)•El nacimiento de Profibus surge como intento de conseguir una red estándar para todos los fabricantes industriales en la que poder integrar equipos activos o maestros (implicados en tareas de control: PCs, autómatas, controladores, etc) sino también elementos de tipo pasivo o esclavos (elementos finales de control, instrumentos, interfases hombre-máquina, paneles locales, etc.)




Sección Española

BUSES DE CAMPO

Profibus (continuación)•Sigue el modelo OSI e implementa los niveles:

1-Físico2-de Enlace7-de Aplicación

•Desde el punto de vista de usuario dispone de tres perfiles:

Profibus FMSProfibus DPProfibus PA


Sección Española

BUSES DE CAMPO

Profibus FMS•FMS (Fieldbus Message Specification)•Protocolo que utiliza los niveles 1 (físico), 2 (de enlace) y 7 (de aplicación) del modelo OSI.•Está dedicado al intercambio de datos e información en el nivel alto de la pirámide de control: entre la interfase de usuario y los procesadores implicados.




Sección Española

BUSES DE CAMPO

Profibus DP•Protocolo que utiliza los niveles 1 (físico) y 2 (de enlace) del modelo OSI.•Esta variante está dedicada a las comunicaciones entre procesadores y elementos de entra / salida, garantizando un tráfico de datos rápido.


Sección Española

BUSES DE CAMPO

Profibus PA•Basado en Profibus DP aunque su funcionalidad está orientada a la integración en la red de instrumentos y actuadores que puedan requerir en algunos casos de seguridad intrínseca y/o alimentación de energía del equipo de campo.




Sección Española

BUSES DE CAMPO

NoSiNoRedundancia

SiNoNoSeguridad Intrínseca

SiNoNoAlimentación a través del bus

Máx. 31Máx. 10 (Ex)3232Participantes / dispositivos

A 2 hilosTrenzado apantalladoF.O

Trenzado apantalladoF.OCable

31,25 Kbits / seg12 Mbits / seg12 Mbits / segVelocidad

Profibus PAProfibus DPProfibus FMSTABLA RESUMENPROFIBUS


Sección Española

BUSES DE CAMPO2.5. Fieldbus http://www.fieldbus.com/•Bus de Campo basado en un protocolo de comunicación estandarizado que permite crear redes de control de carácter abierto con posibilidad de comunicarse con elementos hardware / software de distintos fabricantes.•La fundación u organismo responsable del diseño y mantenimiento de los estándares asociados a dicho protocolo recibe el nombre de Fieldbus Foundation.




Sección Española

BUSES DE CAMPO

Fieldbus (continuación)•El nacimiento de Fieldbus Foundation surge como intento de conseguir una red estándar para todos los fabricantes industriales en la que poder integrar dispositivos de campo y equipos de control y/o monitorización.


Sección Española

BUSES DE CAMPO

Fieldbus (continuación)•Sigue el modelo OSI e implementa los niveles:

1-Físico2-de Enlace7-de Aplicación

•Desde el punto de vista de usuario, una red de bus tipo Fieldbus Foundation está compuesta por dos tipos de segmentos:

Segmento H1Segmento H2




Sección Española

BUSES DE CAMPO

SiNoRedundancia

NoSiSeguridad Intrínseca

NoSiAlimentación a través del bus

Más de 65.000Máx. 32Máx. 4 (Ex)Participantes / dispositivos

Trenzado apantalladoF.O.A 2 hilosCable

100 Mbits/seg31,25 Kbits/segVelocidad

Segmento H2Segmento H1TABLA RESUMENFIELDBUS

7A

2

SISTEMAS DE GESTIÓN DE LA PRODUCCIÓN

FICHA IDENTIFICATIVA DEL DOCUMENTO: Master ISA de instrumentación y control Módulo: 7A – Sistemas de Control Tema: 7A - 2 – Sistemas de Gestión de la Producción Autor: Miguel Angel Sinobas

INTRODUCCIÓN “Información en la era de la Comunicación”

Un master que versa sobre control e instrumentación, no quedaría completo si no se estudiara la utililidad que se da a los datos que proporcionan los instrumentos en aspectos de carácter informativo, con fines de especial relevancia tan diversos como la toma de decisiones, tests de unidades de proceso, obtención de los certificados de Cantidad/Calidad para efectuar la compra-venta de productos, gestión de stocks, balances másicos del proceso o el control de impuestos especiales entre otros muchos.

No es objetivo de este capítulo del módulo hacer un desarrollo exhaustivo sobre los Sistemas de Gestión de la Producción, en los que intervienen especialidades muy diversas del mundo de los Sistemas de Información como son la administración de bases de datos, sistemas operativos, redes y comunicaciones, aplicaciones diversas para la gestión de producción, etc., sino más bien adquirir ideas generales sobre aspectos del tratamiento de la información y la importancia de ésta en la correcta gestión de la producción, tratando el capítulo desde una perspectiva puramente científica.

A modo de introducción, decir que dentro de los ‘Sistemas de Gestión de la Producción’ se engloban aquellos Sistemas de Información y Aplicaciones dedicadas a facilitar información sobre el estado, en tiempo real o pasado, de la Producción, bien proporcionando datos de medidores de temperaturas, caudales, presiones, etc., bien ofreciendo datos de Laboratorio sobre la calidad de las diversas corrientes intermedias, productos terminados, etc., o bien gestionando el inventariado de los elementos de almacenamiento, los movimientos, entradas y salidas de productos en la planta y así un largo etcétera.

Por último, hacer constar que existe poca información escrita sobre los Sistemas de Producción, tratada desde un punto de vista global. En general, son los propios suministradores de aplicaciones los que dan una buena idea sobre este mundo en sus manuales o en las páginas web correspondientes.

Módulo: Sistemas de Control Tema: Sistemas de Gestión de la Producción

Master ISA - ISE de Instrumentación y Control Página 2


Índice

1. CONOCIMIENTOS PREVIOS REQUERIDOS 4 2. SISTEMAS DE GESTIÓN DE LA PRODUCCIÓN 5 3. SISTEMA DE INFORMACIÓN DE PLANTA 11

3.1. Caso de Estudio: PI™ - Plant Information (RtPM™) 12

4. SISTEMA DE INFORMACIÓN DE PRODUCCIÓN 18

4.1. Gestión de Existencias 19

4.2. Gestión de Movimientos 19

4.3. Cálculo de Composiciones de materias primas 20

4.4. Gestión de Entradas y Salidas 20

4.5. Centro de Expediciones 20

4.6. Emisión de Certificado de Cantidad 21

4.7. Balance Global Diario 21

4.8. Blending en Línea 21

4.9. Balance de Unidades 21

4.10. Balance de redes de Energías 21

4.11. Balance general de la Compañía 21

4.12. Reconciliación de datos 22

4.13. Gestión Fiscal 22

4.14. Control de Emisiones 22

4.15. Caso de Estudio: SPC - Sistema de Producción del Complejo 23

5. SISTEMA DE GESTIÓN DEL LABORATORIO 24

5.1. Configuración del Sistema 26

5.2. Plantilla Analítica 27



5.3. Ciclo de Trabajo 28

5.4. Caso de Estudio: SQL*LIMS® - Laboratory Management System 32

6. SOPORTE INFORMÁTICO 36

6.1. SISTEMAS OPERATIVOS 37

6.2. BASES DE DATOS 42

6.3. REDES Y COMUNICACIONES 46

7. ACTIVIDADES PROFESIONALES 51 8. REFERENCIAS Y BIBLIOGRAFÍA 52



1. CONOCIMIENTOS PREVIOS REQUERIDOS

No existen especificaciones sobre conocimientos previos, ya que este capítulo del master, aunque relacionado con él, se aparta de los conocimientos fundamentales que se adquieren en el mismo, complementándolos al tratar de dar una visión sobre la utilización de la instrumentación para fines de información y gestión de una Compañía.

Aunque los temas que se tratan en este capítulo necesitarían, para una buena ejecución profesional, de un equipo humano con completa preparación en disciplinas de Ingeniería e Informática, no se necesita esta formación para la asistencia a esta parte del master, ya que, por límites de tiempo y estructura del mismo, están dirigidos a aportar un complemento informativo muy interesante para los futuros profesionales de la Instrumentación y el Control, ofreciendo una visión más amplia de sus horizontes, interacciones y consecuencias profesionales.



2. SISTEMAS DE GESTIÓN DE LA PRODUCCIÓN

Los Sistemas de Gestión de la Producción permiten disponer de toda la información necesaria relativa a los procesos, unidades de producción, existencias y productos terminados con el fin de optimizar la gestión y apoyar a la toma de decisiones.

En el esquema de distribución de la instrumentación, control e información, Fig. 2-2-1, los Sistemas de Producción se encuentran en la zona alta de la pirámide por lo que, para poder llevar a cabo todas estas labores, es imprescindible haber realizado y previsto en los proyectos de ingeniería una adecuada instrumentación que permita dar un valor añadido, y necesario hoy en día, a los instrumentos y analizadores en línea. En definitiva, estos Sistemas son la plataforma que liga la Gestión de la empresa con el entorno de la Producción.

Fig. 2-2-1 Distribución de la información de producción en la Compañía

Como ‘Sistemas de Gestión de la Producción’ se engloban aquellos Sistemas de Información y Aplicaciones dedicadas a facilitar información de la Producción, bien en tiempo real o mostrando la historia pasada, cumpliendo las siguientes funciones:

o Proporcionando datos de medidores de temperaturas, caudales, presiones, analizadores en línea, etc., mediante un Sistema de Información de la Planta

o Ofreciendo datos de Laboratorio sobre la calidad de las diversas corrientes intermedias, productos terminados, etc., mediante un Sistema de Información de Laboratorio

o Proporcionando información sobre la gestión de los movimientos, entradas y salidas de productos en la planta, inventariado de los elementos de almacenamiento, etc., mediante el uso de un Sistema apropiado de información de la Producción.

Instrumentación de Campo

Sistema de Control Distribuido

Control Avanzado

Optimización de Producción

Sistema integrado de Gestión

de Producción

Supervisión y toma de decisiones



Tal como se puede deducir de la figura anterior, la instrumentación y el control son algo imprescindible para un buen dominio de la producción, de igual manera que lo es un buen Sistema de Gestión de Producción que permite disponer de información para la supervisión de la producción, información fiscal y administrativa para las operaciones de compra / venta u obtener los imprescindibles Certificados de Calidad y Cantidad en estas operaciones.

Según estudios realizados por el Dr. de Geus sobre empresas longevas, en los que acuñó el término "The Living Company"1, "cuanto más abierta sea la compañía y más permita la implicación del personal necesario para la planificación y toma de decisiones, más éxitos cosechará en un mundo en el que no se tengan en cuenta estos aspectos". Para esto, no cabe duda de la necesidad de un buen sistema de información, especialmente en lo referente a la producción.

Además, calidad, eficiencia, regulaciones ambientales, modelo europeo EFQM sobre excelencia en la gestión y aspectos relativos a la seguridad industrial están aumentando la necesidad de la integración del nivel de control de procesos con los sistemas de administración de empresa y, en estos aspectos, la ingeniería informática ayuda al camino hacia la Gestión integral y despliegue de objetivos de la Compañía2.

Por estos motivos, y muchos más, que se podrán ver a lo largo de los capítulos 7A-2 y 7B-2, se observa la importancia que supone tener en cuenta estos aspectos en los proyectos de instrumentación de la Plantas de Proceso.

Una correcta instrumentación, que tenga en cuenta las necesidades de información aguas arriba en el flujo informativo, posibilitará un adecuado desarrollo de los Sistemas de Gestión de la Producción. Un ejemplo claro de esta exposición sería el estudio de la puesta en servicio de tantos medidores de caudal, temperatura, presión y nivel que posibiliten la Gestión de Balances de Unidades, Balances de Energía, Gestión de Entradas/Salidas, etc.; otro ejemplo sería el mostrado en la Fig. 2-2-2, donde se presenta un pequeño ejemplo de las necesidades para la emisión de los Certificados de Calidad y Cantidad en una operación de venta de productos.

Fig. 2-2-2 Ejemplo de necesidades de instrumentación



Ya se ha comentado en la introducción que existe muy poca información escrita sobre las aplicaciones involucradas en el diseño y puesta en servicio de los Sistemas de Producción. Por lo general, son los suministradores de aplicaciones los que dan una buena idea sobre este mundo en sus manuales, formación contratada a medida o sus páginas web correspondientes. Esta falta de información, no sólo se da en los niveles de detalle, sino también en los niveles de concepto y diseño global. Por este motivo, una buena práctica antes de comenzar con el diseño de un Sistema de información de Producción, es la de realizar una serie de visitas a plantas similares a la que se pretende instrumentar y dotar de estos sistemas de información, para observar y aprender de sus experiencias y soluciones llevadas a cabo.

Otra práctica necesaria de realizar, antes de comenzar con un proyecto de este tipo, es llevar a cabo una prospección de mercado para evaluar proveedores y productos a medida, que aunque no en gran cantidad, existe un amplio surtido de posibilidades que hay que valorar, teniendo en cuenta, además, el precio de estas soluciones, que siempre suponen un gasto elevado, no sólo en la compra inicial, sino en el mantenimiento y soporte anual.

Las preguntas que habría que hacerse, a la vista de las soluciones encontradas, para hacer una buen elección serían3:

¿Es el producto una solución industrial a nivel internacional?

¿Es fácil de instalar?

¿Tiene la empresa suministradora un buen servicio de soporte y actualizaciones?

¿Es fácil de usar?

¿Tiene capacidad de gestión y almacenamiento de información en tiempo real?

¿Tiene posibilidad de crear estructuras Cliente/Servidor?

¿Es escalable o ampliable?

¿Permite la explotación de información en Internet/ Intranet?

¿Tiene el suministrador un buen negocio con el producto?

¿Vale lo que cuesta?

¿¿...??

Caso de que no se encuentre el producto adecuado a las necesidades de la Empresa o el proyecto no sea de envergadura suficiente para realizar una fuerte inversión, se puede optar por el desarrollo a medida con técnicos internos o contratados, a sabiendas de que esto supone que el futuro de este tipo de desarrollos queda en manos de unas pocas personas y no de empresas que se responsabilicen del mantenimiento, mejoras, actualización tecnológica, etc., que además tienen necesidades de mejora del servicio ofrecido por presión de la competencia.

Hasta ahora se ha expuesto de forma general cuales van a ser las funciones de estos sistemas y la utilidad que se pretende de ellos en la Compañía, pero, ¿qué tipo de información se puede integrar en los Sistemas de Producción?



La pregunta expuesta se puede contestar con un listado de las funciones que habría que incluir en el diseño de un completo Sistema integrado de Producción:

Historización, visualización y explotación de datos de planta

Gestión de información del Laboratorio

Emisión de Certificado de Calidad

Emisión de Certificado de Cantidad

Compensación de Caudales

Gestión de Entradas y Salidas

Balance de Unidades

Balance de redes de Energías

Balance general de la Compañía

Gestión de Existencias y Movimientos

Reconciliación de datos

Cálculo de composiciones de materias primas

Gestión Fiscal y Administrativa

Centro de Expediciones

Blending en línea

Intercambio de información entre los Sistemas de Producción

El próximo paso sería agrupar estas funciones para que tengan cabida dentro de paquetes existentes en el mercado. Independientemente de que se opte por la opción de desarrollos propios, merece la pena hacer este último ejercicio de agrupamiento ya que permitiría, si en un futuro conviniera, cambiar parcialmente a un producto de mercado o incluso a otro tipo de desarrollo propio con diferente filosofía a la considerada inicialmente, consiguiendo con esta agrupación, una mayor versatilidad y mejor visión del conjunto.

La siguiente, es una posible agrupación de estas funciones sobre la cual se basarán los siguientes apartados del capítulo. Esta agrupación se fundamenta, por un lado, en dos aplicaciones ampliamente utilizadas de forma independiente al resto de las funciones atribuidas a los Sistemas de Producción:

1. Sistema de Información de Planta - SCADA

Historización, visualización y explotación de datos de planta




2. Sistema de Gestión de Laboratorio - SGL (LIMS)



La tercera aplicación engloba al resto de funciones y, como la más numerosa en cuanto a contenido, asume el nombre en singular de los Sistemas de Producción:

3. Sistema de información de Producción - SP


Balance de Unidades






Cálculo de composiciones de materias primas



Blending en línea

Este último módulo de funciones - SP - puede adquirir una gran complejidad, siendo habitual estar formado por una mezcla de aplicaciones compradas a compañías expertas en desarrollos de este tipo y aplicaciones de desarrollo propio, para los casos donde el mercado no satisface las necesidades particulares de una determinada Compañía.

Al conjunto de estas tres aplicaciones le faltaría una cuarta aplicación que permitiera el traspaso de información entre ambas de forma fiable y consistente. A esta cuarta aplicación se la puede denominar Sistema de Interfases de Información. El diseño y alcance de este Sistema de Interfases de Información dependerá de la base informática de cada una de las aplicaciones de producción y se tratará con más detalle en el capítulo 2B de este módulo 7 del master:

4. Sistema de Interfases de Información - SII




Para finalizar con esta exposición introductoria a los Sistemas de Producción, se muestra un pequeño esquema en la Fig. 2-2-3 que recrea la importancia de una buena información para facilitar la toma de decisiones y permitir el avance de la Compañía.

Fig. 2-2-3 Gestión de Empresa



3. SISTEMA DE INFORMACIÓN DE PLANTA

Los Sistemas de Información de Planta persiguen, por un lado, la integración total entre la instrumentación de Planta y el resto de los Sistemas de Producción, sirviendo de plataforma de datos hacia los mismos y, por otro, proporcionar información en tiempo real sobre las Unidades de Proceso, permitiendo, de igual manera, la consulta de datos históricos de las mismas.

Se basan en un SCADA (Supervision, Control And Data Acquisition), sin hacer uso de las escasas posibilidades de hacer control con estos sistemas, unido a una potente base de datos que actúa como Historizardor y a herramientas que permiten explotar esta información mediante Gráficos, tendencias, etc. Existen en el mercado una variedad de productos entre los que cabe destacar:

o PI™ (Plant Information) de OSISoft®

o PHD™ (Plant History Database) de Honeywell®

o Infoplus™ de AspenTech®

Siendo su principal fuente de datos, los sistemas de Información de Planta se encuentran conectados al Sistema de Control Distribuido (SCD), recibiendo información de forma ininterrumpida sobre los medidores de Planta.

Otras fuentes de datos para un sistema de Información de Planta, son el Sistema de Gestión de Laboratorio - SGL, Sistema de información de Producción - SP, cálculos en línea, entradas manuales u otras aplicaciones externas.

Fig. 2-3-1 Sistema de Información de Planta



Un Sistema de Información de Planta bien diseñado permite la recolección ininterrumpida y el almacenamiento indefinido de los datos de Producción recogidos de cada uno de los Sistemas de Control que contenga la Compañía, dando solución, dicho sea de paso, a la corta vida que posee la información en estos SCD's y a la escasa perspectiva que ofrecen de la Planta al completo. Se favorece, de esta forma, la toma de decisiones, la mejora del conocimiento y el entendimiento del proceso permitiendo ligar, además, la Operación con el Negocio.

Se puede decir que un Sistema de Control necesita de información puntual con una frecuencia de muestreo elevada para posibilitar un buen control, mientras que un Sistema de Información de Planta no necesita de esta frecuencia elevada, pero requiere de gran capacidad de almacenamiento para posibilitar la consulta de la historia de producción.

Estos Sistemas de Información de Planta son ampliamente utilizados en industrias como:

Petroquímica Papelera Aeroespacial Farmacéutica

Energética Nuclear Depuración de Agua7 Química

No hay Refinería de Petróleo en el mundo que no posea un Sistema de Información de Planta para monitorización e historización de los datos de las múltiples y diversas plantas de un Complejo industrial Petroquímico.

En la industria de generación y distribución eléctrica se utiliza para recoger información de consumos, turbinas, sistemas de generación, datos medioambientales, etc., permitiendo mejorar el rendimiento y el aumento de beneficios4-5-6.

De todos los Sistemas de Información de Planta que existen en el mercado, cabe destacar la amplia repercusión del sistema PI™ - Plant Information - de OSISoft® - Oil Systems Inc., el cual se ha tomado como ejemplo representativo y del que se va a hablar en este capítulo del master.

3.1. Caso de Estudio: PI™ - Plant Information (RtPM™)

El PI™ - Plant Information o RtPM™ - Real time Performance Monitor es una aplicación suministrada y desarrollada por OSISoft® cuya función es la historización de valores de las variables de las unidades de proceso, permitiendo el acceso rápido a cualquier momento de esta historia de forma puntual o por periodos. Estos valores se almacenan en unidades lógicas denominadas TAGS o Puntos de PI™.

Los Tags no sólo pueden almacenar valores provenientes directamente de la Instrumentación y Analizadores de Planta, sino que además pueden recoger datos de otras fuentes como el Sistema de Gestión del Laboratorio, aplicaciones externas, cálculos en línea internos, etc. y ser consultados conjuntamente con el resto de la información. De hecho, el PI™ se utiliza en algunas empresas como base de datos integradora de la información de todos los Sistemas de Producción.



La visualización de los datos se puede realizar con herramientas proporcionadas por la propia empresa suministradora del PI™ como son el ProcessBook™ o el ActiveView™, con desarrollos suministrados por terceros e incluso utilizando programación propia hecha a medida. En todos los casos se utiliza una estructura Cliente/Servidor para el acceso a los datos.

Dentro de estas posibilidades de explotación de la información, existe también la opción de uso de la herramienta PI-Datalink™, macro que se instala sobre Microsoft® Excel con la que se puede recibir información directa o tratada con funciones incorporadas en la propia macro, generándose así un gran abanico de posibilidades que le permiten al Usuario final recibir una buena calidad de información y un ahorro considerable de tiempo.

El sistema PI™ está basado en una base de datos que almacena valores puntuales del SCD (Sistema de Control Distribuido) y otros sistemas, en el Servidor donde reside. Para el caso de datos de instrumentos de Planta, la recogida de los mismos se realiza a través de un módulo interfase - APP Node - que permite, a través de la red, su lectura y almacenamiento posterior en unidades de disco. Esto posibilita la recogida de toda la información del proceso y dota al sistema de una capacidad histórica muy elevada.

Fig. 2-3-2 Plant Information - PI™

Este sistema, tiene además la función de actuar de plataforma de datos entre el SCD y el resto de los Sistemas de Producción, dotándolos en tiempo real de la información de Planta que requieren para su gestión interna, tal como se verá con más detalle en el capítulo 2B de este módulo 7 del master.

El motor del PI™ está basado en su UDS - Universal Data Server - que incluye diferentes bases de datos donde se almacena la información de configuración del propio PI™ y de los datos de proceso. Las dos bases de datos principales son la “Point Database” y la “Data Archive”. En la “Point Database” reside la lista de Puntos (configuración del sistema), cuyos valores se almacenan en el “Data Archive” (datos históricos). Otra posibilidad es que los puntos pueden estar mapeados a puntos que se encuentran en una base de datos externa (PHD™, ORACLE®, PI™ ...) utilizando las conexiones que OSISoft® denomina COM Connectors, pudiéndose monitorizar esta información sin necesidad de estar archivada en el propio PI™.



Existen COM Connectors específicos para fuentes de datos exclusivas como el PHD™ de Honeywell® o el PI COM Connector para conexión a otras fuentes de datos PI™ y otros más genéricos como el OLE DB COM Connector para conexión y consulta a Sistemas de Bases de Datos Relacionales - RDBMS.

Además el sistema PI™ permite la sincronización automática con la definición de Tags en el SCD con lo que se asegura la coherencia en la información entre ambas aplicaciones y facilita la creación de estos Puntos en PI™ después de creado en los Sistemas de Control Distribuido.

PI™, al igual que el resto de aplicaciones basadas en la toma e historización de datos de Planta, necesita de herramientas para la visualización de la información de los valores de los Tags almacenados. Estas herramientas pueden ser suministradas por misma empresa, OSISoft®, proporcionando así un sistema completo.

Las herramientas que acompañan a PI™ sirven para el diseño, creación y visualización de gráficos, así como la explotación de información a través de Microsoft® Excel:

PI ProcessBook™ - El ProcessBook™ es la herramienta necesaria para el dibujo de gráficos donde, principalmente, se representan las Unidades de Proceso con los valores de las variables más representativas.

PI ActiveView™ - El ActiveView™ es una herramienta de uso exclusivo para monitorizar gráficos y no es más que un control ActiveX que se puede incrustar en un documento Word, Excel o, el caso más habitual, en una página HTML para ser visualizado con el Internet Explorer. Este ActiveX es el marco en el que se presentan los gráficos dibujados con ProcessBook. De esta forma, los gráficos se pueden presentar sin problema en un entorno LAN (Local Area Network) o en una intranet corporativa.

RtPortal™ - Basado en las nuevas técnicas de 'Thin Client' donde los PC's Clientes no necesitan de software adicional para el uso de estas herramientas, tan sólo con el uso de Internet Explorer estándar y un plug-in para visualizar gráficos vectoriales puede mostrar los gráficos dibujados con ProcessBook en la LAN, intranet e Internet. Este portal se puede montar con las diferentes RtWebparts™ que ofrece OSISoft® y que van desde gráficos, tendencias, tablas de datos, control de tiempos de visualización o medidores calibrados con código de colores todas ellas integradas dentro del entorno del servidor de SharePoint de Microsoft®.

PI Datalink™ - Basado en una macro para Microsoft® Excel, permite la recuperación de valores de PI™ sobre hojas de cálculo, aumentando de forma considerable las posibilidades de trabajo con la información recuperada. Tiene la posibilidad de recibir valores actuales, históricos, medias ponderadas en el tiempo, mínimos, máximos, etc.



Fig. 2-3-3 Gráfico de Proceso monitorizado con RtPortal™

Fig. 2-3-4 Gráfico de Proceso monitorizado con PI ProcessBook™

Existen otras posibilidades de visualización desarrolladas por terceros que, aunque más económicas, presentan una menor velocidad en la respuesta en tiempo real a la prestada por las herramientas que acompañan a PI™:

Web@aGlance™ - De la empresa Axeda-Wizcon®.

XHQ™ - De la empresa IndX® Software Co.

ProcessNet™ - De la empresa Matrikon®.



Fig. 2-3-5 Tendencia monitorizada con PI ActiveView™

En todos los casos existe la posibilidad de mostrar valores en tiempo real, pasado, datos depurados o estadísticos, así como tendencias de valores en un periodo dado, presentación de valores en tablas, petición de valores medios ponderados en el tiempo, etc.

Los menús de navegación entre gráficos pueden ser generados bien con herramientas proporcionadas por los proveedores de este tipo de software o bien mediante desarrollo propio, hecho que, en estos casos, puede ser más beneficioso, puesto que haciendo uso del entorno web, posible p. ej. con PI ActiveView™, RtPortal™, ProcessNet™, etc., se puede llegar a diseños hechos totalmente a medida sin un coste de tiempo elevado.

No se puede cerrar el capítulo de PI™ sin hacer una breve reseña a lo que podría suponer el coste de la puesta en marcha de esta herramienta, teniendo en cuenta, tanto las licencias de software como la compra del hardware necesario y contratación de técnicos para la puesta en marcha y formación inicial.

Los precios dados a continuación, aunque basados en un caso real según precios del año 2005, son estimativos ya que dependen de las condiciones de contratación pactadas y especificaciones del hardware comprado. Esto no quiere decir que haya que aplicar el IPC anual a las cantidades barajadas, ya que en informática, debido a los continuos avances y competencia entre suministradores, los precios, lejos de subir, tienden a bajar o mantenerse ofreciendo, en este último supuesto, un paquete más amplio de desarrollos con el producto principal.

Concepto Precio €

Compra a OSI de un Sistema PI™ con 50.000 Tags 100.000

Adquisición de 300 licencias de ActiveView 34.000

Adquisición de 5 licencias de ProcessBook 30.000

Servidor wintel en Cluster W2000 Server para PI™ 30.000

Contratación del Trabajo de Instalación de PI™ 8.000

Contratación de Formación de administración del Sistema 15.000

AppNode (3) (Conexión PI - SCD) 105.000



OPC Client (AppNode) (3) - Interfaz con PI 5.000

Otros 23.000

Total: 350.000

Lo que da una idea de la inversión necesaria en un proyecto de puesta en marcha de un Sistema de Información de Planta, en este caso del sistema PI™ de OSISoft®.

En la estimación de un presupuesto de este tipo y a la hora de valorar el producto a comprar y el suministrador del mismo, hay que tener en cuenta también el coste de mantenimiento anual que, según las condiciones de contrato, puede llegar a suponer entre el 10% y el 15% de la inversión inicial de la parte de software.

Para terminar con estos Sistemas de Información de Planta, existe otra aplicabilidad adicional asociada a estos sistemas dirigida a la Gestión de Alarmas que, aunque generalmente reside en los SCD correspondientes, pudiera llegar a interesar su implantación en un sistema de información de ámbito superior al propio control.

Generalmente, todos los suministradores de aplicaciones dirigidas a la información de Planta tienen desarrollado algún módulo para esta Gestión de Alarmas que se suministra como complemento con su coste correspondiente.

Fig. 2-3-6 La Planta sobre la mesa de trabajo



4. SISTEMA DE INFORMACIÓN DE PRODUCCIÓN

Los sistemas de Información de la Producción - SP - propiamente dicha, tienen por finalidad disponer de toda la información necesaria relativa a los procesos, unidades de producción, materias primas y productos con el fin de optimizar la gestión y apoyar a la toma de decisiones, haciendo partícipe de esta información al conjunto de Direcciones de la Compañía, no sólo a la Dirección de Producción sino, también, a la de Planificación, Logística, Comercial, Técnica y Económico-Financiera.

Asumen este nombre debido a que son sistemas que integran información del resto de los Sistemas de Producción por necesidad para el funcionamiento propio. Esta característica integradora puede permitir llegar a construir todo un Sistema Integrado de la Gestión de Producción.

Fig. 2-4-1 Esquema de situación de un Sistema de Información de la Producción

Las funciones básicas de un Sistema de Información de la Producción - SP - son:

o Gestión de Existencias o Gestión de Movimientos o Cálculo de Composiciones de materias primas o Gestión de Entradas y Salidas o Centro de Expediciones o Emisión de Certificado de Cantidad o Balance Global Diario o Blending en línea o Balance de Unidades o Balance de redes de Energías o Balance general de la Compañía o Reconciliación de datos o Gestión Fiscal y Administrativa o Control de Emisiones



Los siguientes puntos tratarán de dar una breve descripción de cada una de estas funcionalidades.

4.1. Gestión de Existencias

La función para Gestionar Existencias es imprescindible si se quiere conocer en tiempo real la situación de cada elemento de almacenamiento de la Planta y el inventariado de materias primas, productos intermedios y productos terminados disponibles.

La Gestión de Existencias es el primer paso en la gestión de información, indispensable si se quiere disponer de información precisa sobre movimientos, composiciones, entradas y salidas.

4.2. Gestión de Movimientos

Contabiliza todos los movimientos de Productos inventariados en elementos de almacenamiento (tanques, esferas, silos, etc.). Estos movimientos, que según su dirección se denominan de entrada o salida, pueden realizarse entre diferentes elementos de almacenamiento (transferencias), ser de alimentación a las diferentes unidades de proceso, formar parte de la venta en el suministro a clientes, operaciones de purga de tanques, etc.

La contabilidad de estos movimientos se realiza, tanto en volumen como en masa a partir de la variación de nivel en los elementos de almacenaje correspondientes. Los datos de niveles al inicio y final de los mismos, así como temperatura y presión, se toman directamente del Sistema de Información de Planta. El dato de densidad se puede obtener, bien de medidores en línea, o bien del Sistema de Gestión del Laboratorio.

Fig. 2-4-2 Gestión de Movimientos, Inventarios, Entradas y Salidas



4.3. Cálculo de Composiciones de materias primas

En el mundo del Refino de Crudo, conocer la composición exacta de los tanques de almacenaje de Crudo es crucial para una buena planificación de la producción.

Estos tanques almacenan durante su vida diferentes tipos de Crudo con lo que la composición porcentual de los Crudos que contiene va variando a medida que alimenta a las unidades de destilación del Petróleo y recibe materia prima de los buques petroleros.

Debido a que las propiedades de los diferentes Crudos que se pueden comprar varía de forma considerable de unos a otros (crudos pesados, crudos ligeros, crudos de bajo azufre, crudos parafínicos...), los productos obtenidos y las condiciones de proceso difieren también notablemente. Así se hace imprescindible conocer la composición exacta de cada tanque contenedor de Crudo para definir la carga apropiada a las destiladoras y las condiciones de proceso, con el fin de conseguir los productos finales según demanda y especificaciones de los Clientes reflejadas en los contratos comerciales.

Esta función se apoya en la función de gestión de movimientos.

4.4. Gestión de Entradas y Salidas

Basada en la gestión de movimientos, emisión de certificado de cantidad y gestión fiscal y administrativa, se encarga de gestionar toda la información necesaria en las operaciones de Compra (Entradas) y Venta (Salidas).

Con todo esto, cualquier operación de Entrada de materia prima o Salida de productos queda informada con los datos de clientes, proveedores, destino, especificaciones de los productos, datos fiscales, certificado de cantidad y certificado de calidad emitido por el Laboratorio.

4.5. Centro de Expediciones

En las empresas que se realice suministro por Cisterna, donde un mismo elemento de almacenamiento puede estar varios días proveyendo a diferentes Clientes el mismo producto, el Centro de Expediciones - CEX - como parte del Sistema de Información de la Producción, trata de gestionar la salida de producto de la Compañía.

Fig. 2-4-3 Esquema básico de un Centro de Expediciones



El CEX supone, en realidad, un complemento de la gestión de entradas y salidas, y puede, además, tener capacidad de gestionar los datos legales sobre los seguros obligatorios, permisos de circulación, ADR para el transporte de materias peligrosas, etc., que un conductor, tractora, cisterna o remolque deben poseer.

4.6. Emisión de Certificado de Cantidad

Está íntimamente ligado a la gestión de movimientos, entradas y salidas, formando binomio junto al Certificado de Calidad emitido por el Laboratorio y otros documentos legales, administrativos y fiscales.

La conversión de volumen trasegado a masa se hace con el dato de densidad que generalmente proporciona el Laboratorio en su certificado de calidad de producto final y se obtiene del Sistema de Gestión de Laboratorio - SGL.

4.7. Balance Global Diario

Esta función proporciona una síntesis de la información diaria relativa a Existencias iniciales y finales, Entradas y Salidas, Proceso y Producción, Autoconsumos y Mermas.

4.8. Blending en Línea

En la industria de producción en continuo, donde el producto final se fabrique en base a recetas surgidas de especificaciones de calidad final y este producto se obtenga por mezcla en diferentes proporciones de corrientes intermedias producidas en las diferentes unidades de producción de la Planta, un Sistema de Información de la Producción ambicioso debe contemplar la gestión del Blending en Línea para llegar a 'tanque final' con un producto dentro de esas especificaciones requeridas por el mercado.

En realidad una gran parte de la gestión del Blending en Línea se realiza desde el Control Avanzado con la ayuda de analizadores en línea calibrados con inferencias obtenidas del Sistema de Gestión del Laboratorio. La función de Blending en Línea del Sistema de Información de la Producción proporciona el aporte de una base de datos y un sistema de consultas que facilite su seguimiento.

4.9. Balance de Unidades

Trata de llevar la contabilidad de las corrientes de alimentación y las corrientes de producción, dando información, además, de las mermas diarias en peso.

4.10. Balance de redes de Energías

De igual manera que el Balance diario de las Unidades de Proceso, se pueden gestionar las redes de Energías o Servicios Auxiliares (Utilities). Se realiza, así, el cómputo de los combustibles autoconsumidos, vapor, agua, energía eléctrica o térmica, controlando y contrastando los Aportes y Consumos.

4.11. Balance general de la Compañía

Combinando parte de la información sintetizada en el Balance Global Diario con el detalle de Proceso/Producción y Autoconsumos proporcionado por los Balances diarios de Unidades y Energías se puede conseguir el Balance Mensual oficial de la Compañía que permitirá registrar la historia de la actividad productiva de la misma a lo largo del tiempo.



4.12. Reconciliación de datos

Debido a las muy diversas fuentes de información y la incertidumbre en los medidores de Planta, se hace muy conveniente una reconciliación de la información, sobre todo en lo referente a los datos que entrarán en juego a la hora de cuadrar los balances de unidades de producción y redes de energías.

Según Ales Soudek8, el mensaje es claro. La disponibilidad de una gran cantidad de datos no es necesariamente equivalente a una mejora de la información. La mejora de la información sólo se obtiene cuando entendemos el significado de los datos, podemos cuantificar la calidad de los mismos y todo cuadra. La precisión de los datos es la base para sacar partido en la toma de decisiones.

El término Reconciliación se puede explicar como un ajuste, concordancia o consistencia de los datos. Este ajuste de los datos se puede hacer mediante Normalización, uso de Sistemas Expertos basados en Reglas o Sistemas basados en Estadística.

La Reconciliación de los datos se puede hacer con aplicaciones hechas a medida, aplicando la experiencia propia y conocimiento de la información de nuestra empresa o utilizando software específico accesible en el mercado como el SigmaFine™ de OSISoft®, basado en métodos estadísticos.

4.13. Gestión Fiscal

Complementando a la gestión de entradas y salidas, la Gestión Fiscal y Administrativa provee de información, cuando aplique, sobre la fiscalidad de los productos, impuestos especiales, inspección permanente de la Administración, etc.

4.14. Control de Emisiones

Dentro de las funciones atribuidas a un Sistema de Información de la Producción completo, la función del Control de Emisiones se puede considerar la más reciente y ha venido motivada por las últimas normativas de ámbito nacional como el control de Efecto Burbuja con las emisiones de SO2, responsable de la lluvia ácida, e internacional, con el Protocolo de Kioto para el control de las emisiones de CO2 por chimenea, responsable del efecto invernadero.

En realidad, esta función no tiene más que aprovechar los datos obtenidos en la Gestión de Energías y aplicarles los cálculos pertinentes, añadiendo las medidas en línea adicionales en las propias fuentes de emisión.

Fig. 2-4-4 Directivas internacionales para el Control de Emisiones



4.15. Caso de Estudio: SPC - Sistema de Producción del Complejo

Debido a la excesiva complejidad de un Sistema de Información de la Producción con todas las funciones expuestas, se puede optar al desarrollo propio del núcleo del mismo y a desarrollos parciales, o compra, de cada una de las funciones de las que se le quiera dotar.

En cualquier caso, el desarrollo propio del núcleo del sistema se hace muy conveniente puesto que así se asegura la integridad de la información y se garantiza una interfaz de Usuario homogénea.

Las siguiente imágenes muestran dos pantallas del Sistema de Producción del Complejo - SPC - del Grupo Repsol YPF basadas en desarrollo propio sobre Oracle/Developer.

Fig. 2-4-5 Gestión de las Composiciones de Crudo en Tanques

Fig. 2-4-6 Gestión de Movimientos



5. SISTEMA DE GESTIÓN DEL LABORATORIO

Los Sistemas de Gestión del Laboratorio - SGL - tienen por objeto la gestión de la información del Laboratorio de Planta y la transmisión de los resultados analíticos que se generan a todos los Usuarios de la Compañía, siendo una herramienta imprescindible para una buena gestión de la Calidad y control del Proceso.

Fig. 2-5-1 Ciclo de trabajo en el SGL

Las 'operaciones básicas' de un SGL son, en orden cronológico de actuación:

I. Registro de la muestra con los ensayos a analizar.

II. Introducción y Aprobación de los resultados.

III. Consulta y distribución de la información.

De un Sistema de Gestión de la información del Laboratorio se espera una amplia funcionalidad, versatilidad y facilidad de uso, además de tener la posibilidad de conseguir la consabida Certificación o Acreditación en Calidad y, según ASTM E 1578-939, tener en cuenta desde los Usuarios de la aplicación, hasta los proveedores de la misma e, incluso, a los suministradores de instrumentos para el Laboratorio.

Debido a que el ámbito del SGL, al igual que el resto de los Sistemas de Producción, se extiende al nivel de Compañía, la responsabilidad sobre el mismo es compartida por el Laboratorio, como principal Usuario y responsable de la información gestionada, por los Usuarios que deciden qué muestras y ensayos registrar, y acceden periódicamente para su consulta y, por último, por los Departamentos de Sistemas, responsables de su buena funcionalidad y seguridad.



Para conseguir los resultados esperados, el SGL puede dotarse de diferentes funciones agrupables en tres grandes grupos:

SISTEMA (Administración) o Definición de Grupos, alta de Usuarios y asignación de permisos

o Creación de los Grupos de Datos

o Asignación de Reglas y Parámetros de Sistema

... PLANTILLA ANALÍTICA (Configuración de la estructura de datos)

o Unidades de Medida

o Análisis - Métodos

o Definición de Límites: Medida, Detección y Especificación

o Productos - Corrientes

o Creación de Muestras

... TRABAJO (Configuración de las funciones habituales)

o Registro de Muestras

o Resultados y Supervisión

o Acciones Automáticas

o Conexión de Equipos

o Distribución de la información

o Certificado de Calidad

...

La figura 2-5-2 representa un esquema de la funcionalidad que se espera de un Sistema de Gestión del Laboratorio, integrado en los Sistemas de Producción de una industria, funcionalidad que se tratará de matizar en los puntos que siguen a continuación.



Fig. 2-5-2 Funciones de un Sistema de Gestión de la información del Laboratorio

5.1. Configuración del Sistema

Uno de los primeros trabajos que hay que realizar en la puesta en marcha de un Sistema de Gestión de Laboratorio debe ser la configuración del sistema.

• Parámetros de Sistema. Donde se configuran aspectos referidos a la seguridad de los datos, formatos de presentación de información, etc.

• Reglas. Algunos sistemas permiten definir Reglas o Tratamientos que supervisarán las acciones durante las 'operaciones básicas' del SGL para diferenciar, p. ej., muestras de certificado de calidad de muestras programadas para el control diario de las unidades de proceso.

• Grupos de Datos. Servirán para asociar cada una de las entidades de un SGL - muestras, productos, ensayos, etc. - a un Grupo de Datos concreto, con el fin de asociar y filtrar, si fuera necesario, la información a los Usuarios.

Fig. 2-5-3 Permisos a Grupos de Datos



• Categorías. Se necesitan crear Categorías de Usuarios con permisos para realizar diferentes funciones dentro del SGL. Estas Categorías deberán definir a los administradores de la aplicación, los analistas, los Usuarios de planta, Usuarios generales, etc.

Fig. 2-5-4 Categorías de Usuarios

• Usuarios. Donde se darán de alta todos los Usuarios de la aplicación y se les asociará la categoría que les corresponda y los grupos de datos a los que vayan a tener permiso de acceso.

5.2. Plantilla Analítica

Plantilla Analítica, Ficheros Maestros, Datos Fijos... son algunos de los nombres que se utilizan para denominar los datos que deben introducirse para montar toda la información que llevarán las muestras al registrarse y entrar en el ciclo de trabajo del sistema.

• Unidades de Medida. Es la primera entidad a definir dentro de una Plantilla, donde se darán de alta las Unidades de Medida a utilizar en las expresiones de resultados.

• Límites: Medida - Detección - Especificación. Existen algunos Límites que se pueden asociar a los resultados introducidos tras un análisis dado.

Los Límites de Medida van asociados a la propia Unidad de Medida, de forma que no se permita, p. ej., introducir valores por encima de 100 en un resultado porcentual.

Los Límites de Detección son propios del equipo utilizado en el análisis, la norma aplicada, del proceso de fabricación, etc.

Por último, los Límites de Especificación se asocian a las muestras para contrastar el cumplimiento de los resultados obtenidos en el análisis con los valores esperados o contratados en el caso de productos terminados.

• Productos - Corrientes. Antes de poder dar de alta las muestras que se registrarán para el trabajo diario, se necesita informar de las diferentes corrientes intermedias, materias primas y productos terminados que puedan entrar en el Laboratorio para ser analizados y que, en la última fase de definición de la Plantilla, se asociarán a las muestras.

• Operaciones - Métodos. Las Operaciones o Métodos son los ensayos propiamente dichos, donde se asocia cada componente o subensayo junto a su unidad de medida y, adicionalmente, se podría informar de otros datos asociados a un análisis, como el Instrumento utilizado, el Tiempo de análisis u Horas/Analista del ensayo.



• Muestras. Es la entidad final de la Plantilla Analítica, donde se informará de las Muestras susceptibles de ser registradas de forma automática o manual, junto con los datos requeridos para su definición, como el producto asociado a la misma, los ensayos que llevará, el Grupo de Datos al que va a pertenecer, etc.

Fig. 2-5-5 Algunas estructuras de la Plantilla Analítica

• Acciones Automáticas. Se debería poder definir en cualquier nivel de la Plantilla Analítica las acciones que, de forma Automática, interesa se ejecuten en cada uno de los pasos del ciclo de trabajo como, p. ej., la impresión de etiquetas informativas en el momento de registro de una muestra, el envío de resultados a otro sistema en el momento de aprobación de los mismos, etc.

• Adaptación - Observaciones. Todos los Sistemas LIMS que se ofrecen en el mercado están diseñados para todo tipo de Laboratorios, por lo que, de partida, nunca se adaptan a los requerimientos de información que una determinada empresa necesita. Por esta razón, un dato importante a la hora de decidirse por un Sistema dado es revisar su Adaptabilidad a las necesidades propias y la posibilidad de poder añadir información adicional en cada uno de los niveles de la Plantilla mediante un sistema de Observaciones, o información auxiliar, que permita informar de datos no previstos por el paquete en su diseño original.

• Calibración de Equipos. Supone un Módulo adicional, interesante para la Gestión interna del Laboratorio, y casi imprescindible para efectos de Certificación o Acreditación, que permite llevar la historia y situación de las Calibraciones de los Equipos del Laboratorio.

• Plan Analítico. Resulta muy interesante, cuando el registro de muestras sea masivo y rutinario, que el SGL esté complementado con un módulo donde se pueda Planificar el registro de muestras según programas pactados con los Departamentos de Procesos, Operaciones, etc.

5.3. Ciclo de Trabajo

Una vez configurados los parámetros del sistema y cargada la plantilla analítica se puede comenzar a trabajar de forma efectiva con el Sistema de Gestión de Laboratorio de la Compañía, informando de los resultados de análisis realizados a las muestras solicitadas.



• Registro de Muestras. El Registro de Muestras puede realizarse de forma manual, eligiendo la Muestra que interesa y añadiendo los ensayos que se pretenden solicitar al Laboratorio, o de forma automática según un programa del Plan Analítico pactado con los diversos Departamentos interesados.

• Resultados y Supervisión - Anexos. Una vez realizados los ensayos por el Laboratorio, estos se Introducen en el SGL y finalmente se les Supervisa dando, de esta forma, el visto bueno a la información introducida antes de su distribución. Resulta conveniente que el sistema permita asociar ficheros adjuntos a los resultados, como documentos, imágenes, etc., para que puedan servir como complemento a los mismos.

• Acciones Automáticas. Si se han programado en la configuración de la plantilla analítica, en el momento que suceda una acción esperada como la aprobación de resultados, el registro de una muestra, la introducción de un resultado fuera de especificaciones, etc., se dispararán los programas asociados a las Acciones Automáticas configuradas.

• Conexión a Equipos. Siempre que sea posible, resulta muy conveniente tener conectados los equipos de Laboratorio que generan muchos resultados simultáneos para su transmisión de forma automática y así evitar errores en la introducción manual de los mismos.

Un buen ejemplo de equipos candidatos a este tipo de conexión son los aparatos de destilación de productos petrolíferos, los analizadores multiensayo de aguas o las aplicaciones de gestión de Cromatografía como el TurboChrom™ de Perkin-Elemer® o la ChemStation™ de Compaq®, que generalmente generan una gran cantidad de resultados por ensayo.

Fig. 2-5-6 Conexión y transmisión de resultados de un Cromatógrafo al SGL

Muestra: 200312337 # GAS.EUROPEA REGULA SIN PLOMO Fichero resultados: Benceno%V-20040526-170034.raw Fecha informe: 25-05-2004 17:00 Analista: J.Portela Instrumento: GC_01*HP5590 SERIE II Componente Tr(min) Area(μV/s) BL %V. BENCENO 3.6 11070 BL 0.8 METIL ETIL CETONA 3.9 421627 BB 29.3 TOLUENO 4.3 1008495 BV 70.0



• Distribución de la información. El último paso del Ciclo de Trabajo en el SGL es la distribución de la información que, bien puede realizarse de forma automática en el momento de realizar la supervisión por parte del Laboratorio, o bien bajo demanda de los Usuarios interesados en esta información. Por supuesto, los informes que deben estar disponibles no serán sólo aquellos referidos al seguimiento del día a día, sino también los diseñados para el seguimiento de históricos de muestras, ensayos, unidades de proceso, etc.

• Certificado de Calidad. El Certificado de Calidad es el informe de Laboratorio por excelencia que se diseña para mostrar la información de resultados de productos terminados y acompaña al Certificado de Cantidad en todo proceso de compra/venta.

• Firma Electrónica. De igual manera que el módulo de calibración de equipos de Laboratorio, la utilidad de Firma Electrónica resulta muy interesante con fines de certificación o acreditación y para envío de información por medios digitales, evitando la falsificación de informes oficiales del Laboratorio.

• Auditoría de Transacciones. Un Sistema de Gestión de Laboratorio ambicioso debe contemplar el registro de cada acción que se produce dentro de él, principalmente en las acciones relacionadas con el registro de muestras, introducción de resultados, modificación o validación de los mismos, anulación de ensayos o muestras, etc. De nuevo, este registro es indispensable para conseguir la certificación o acreditación comentada en puntos anteriores y, desde luego, muy interesante para poder hacer un buen seguimiento de los datos de la aplicación.

• Integración con otros Sistemas - Accesos Externos. El SGL debe contemplar la posibilidad de integrarse con el resto de los Sistemas de Producción, SP y SCADA, para compartir información, enviando y recibiendo ésta con el resto de las aplicaciones de información de producción.

Otra posibilidad a contemplar de gran interés es la accesibilidad al SGL desde herramientas externas a la propia aplicación para obtener información controlada y a medida de los Usuarios, permitiendo a los mismos realizar sus propias consultas y pequeños desarrollos personalizados.

• Supervisión de Resultados Críticos. Siempre que las posibilidades lo permitan, resultaría interesante poder informar, en tiempo real y después de supervisados los resultados pertinentes en Laboratorio, de los parámetros críticos de control de la Planta de Producción de forma independiente al conjunto de valores que se analizan a lo largo del día en un Laboratorio. Si además de esto, fuera posible dejar la constancia de esta Supervisión en el Sistema, cumpliríamos de forma satisfactoria con algunas de las exigencias de la normas de Calidad aplicadas a los departamentos de producción.

• Gestión Interna del Laboratorio. No se puede dejar de hablar de las capacidades de gestión interna del propio Laboratorio que un SGL debe proporcionar, como son la gestión de costes analíticos, control de calibraciones de equipos, necesidades de personal, horas/hombre por cliente interno, etc.



Tal como se ha podido observar, un Sistema de Gestión de Laboratorio ambicioso necesita de un gran desarrollo si se hiciera en el entorno de la Compañía. Por esta razón, merece la pena hacer una revisión de las posibilidades que ofrece el mercado, ya que existe una amplia gama de aplicaciones con un buen espectro de aplicabilidad y funcionalidades, tratando de encontrar un producto que se adapte a las necesidades de la compañía de la mejor forma posible y con un precio adecuado a las posibilidades de inversión.

Existen en el mercado una variedad de empresas que ofrecen Sistemas LIMS, entre las que cabe destacar:

o SQL*LIMS® de Applied Biosystems™

o SampleManager™ de Thermo LabSystems

o STARLIMS™ de StarLims Corporation

o CALS™ de Beckman™

o Xp-LIMS™ de Scadasoft Sistemas S.L.

Todas ellas están concebidas para gestionar el trabajo diario del Laboratorio, independientemente del tipo de empresa que lo vaya a usar, por lo que, en general, su funcionalidad excederá de lo que en la práctica se llega a necesitar, requiriendo de algunos ajustes de información para encuadrarlas con las necesidades específicas.



5.4. Caso de Estudio: SQL*LIMS® - Laboratory Management System

El SQL*LIMS® es una aplicación ampliamente utilizada a nivel internacional como núcleo del Sistema de Gestión de Laboratorio - LIMS (Laboratory Information Management System) -, suministrada y desarrollada por Applied Biosystems®.

El producto básico está provisto de la mayor parte de las funcionalidades requeridas a un SGL enumeradas en los puntos anteriores. Además se suministran módulos adicionales que pueden ampliar su funcionalidad y, por supuesto, su precio.

Basada en tecnología Cliente/Servidor y desarrollada sobre una RDBM (Gestor de Base de Datos Relacional) ORACLE® en el Servidor y Developer (Formularios, Menú e Informes) en los Clientes, permite ampliar su funcionalidad para hacer desarrollos a medida sin grandes despliegues de recursos.

Para que la aplicación funcione correctamente, deben estar siempre activos los cuatro Monitores de la misma que se instalan como servicios en el Servidor. Estos cuatro monitores son:

• Dispatcher - Comprueba las licencias libres antes de permitir una nueva entrada de Usuarios a la aplicación. Utiliza un sistema de licencias concurrentes.

• Logger - Se encarga de efectuar los Registros de muestras y comprobar que la estructura completa generada es consistente.

• Status - Está revisando continuamente todas las transacciones que se producen en la aplicación, actuando sobre los niveles con los que se interactúa y sobre el resto de niveles que tengan relación con una transacción determinada como pueden ser la introducción de un resultado o la aprobación de una muestra.

• Event - Actúa sobre los Eventos o Informes que se lanzan, bien de forma manual, o de forma automática, vigilando la terminación correcta de estos Eventos y dejando registro de todo ello.

Fig. 2-5-7 Distribución de información en SQL*LIMS®



Dentro de las posibilidades de personalización del SQL*LIMS®, se pueden destacar las siguientes:

• Posibilita la traducción libre de los textos fijos de las diferentes pantallas y de los mensajes informativos que muestra la aplicación.

• Permite la adición de datos complementarios u observaciones que se quieran añadir a los diferentes niveles de la Plantilla Analítica y que la aplicación denomina Atributos.

• Se pueden asociar ficheros adjuntos a cualquier nivel de la estructura de Resultados, como imágenes de cromatografías, curvas de destilación, fotografías de muestras, etc.

Los formularios o pantallas tienen, en general, una estructura Maestro - Detalle, como se puede ver en el siguiente formulario de consulta de resultados por muestra, similar al de introducción de los mismos y uno de los más accedidos en el SQL*LIMS®.

Fig. 2-5-8 Formulario de consulta de resultados por muestra

La aplicación trabaja con un sistema de información combinada de Status y Condition que informa puntualmente de la situación de cualquier nivel de la estructura de resultados, por lo que se puede saber en todo momento, p. ej., si un resultado está fuera o dentro de especificaciones o si ha sido modificado, informa del estado de las muestras a falta de análisis, envíos de muestras a falta de aprobación, etc.



Fig. 2-5-9 Estructura jerárquica en Plantilla (izq.) y Resultados (dcha.)

El siguiente es un informe de históricos de resultados, obtenido desde el SQL*LIMS® y desarrollado con la herramienta Reports/Graphics Builder de ORACLE®.

Fig. 2-5-10 Informe de seguimiento de resultados



Al igual que en casos anteriores, no se puede cerrar el capítulo de SQL*LIMS® sin hacer una breve reseña a lo que podría suponer el coste de la puesta en marcha de esta herramienta, teniendo en cuenta, tanto las licencias de software, como la compra del hardware necesario y contratación de técnicos para la puesta en marcha y formación inicial.

Los precios dados a continuación, aunque basados en un caso real según precios del año 2003, son estimativos ya que dependen de las condiciones de contratación pactadas y especificaciones del hardware comprado. Ya se ha dicho anteriormente que esto no quiere decir que haya que aplicar el IPC anual a las cantidades barajadas, ya que en informática, debido a los continuos avances y competencia entre suministradores, los precios, lejos de subir, tienden a bajar o mantenerse ofreciendo, en este último supuesto, un paquete más amplio de desarrollos con el producto principal.

Concepto Precio €

Adquisición de 20 licencias de acceso concurrente a SQL*LIMS® 180.000

Adquisición de ORACLE® RDBM y 100 licencias de acceso 30.000

Adquisición de herramientas de desarrollo ORACLE® (1 Licencia) 7.000

Servidor wintel W2000 Server para SQL*LIMS® 30.000

Trabajo de Instalación y verificación de ORACLE® y SQL*LIMS® 2.000

Contratación de Formación para Administradores del Sistema 12.000

Consultoría, personalización y desarrollos a medida 80.000

Módulos de Registro Automático y Calibración de Equipos 24.000

Otros 10.000

Total: 375.000

Como siempre, en la estimación de un presupuesto de este tipo y a la hora de valorar el producto a comprar y el suministrador del mismo, hay que tener en cuenta también el coste de mantenimiento anual que, según las condiciones de contrato, puede llegar a suponer entre el 10% y el 15% de la inversión inicial de la parte de software.

Para terminar, debido a que el Laboratorio es uno de los pilares en el control de calidad de los productos de una Empresa, objetivo prioritario en cualquier auditoría externa de certificación de Calidad o Medioambiente, es muy importante que sus datos, gestionados por medio del SGL de la Compañía, cumplan con máximas de Integridad y Seguridad.



6. SOPORTE INFORMÁTICO

Todas estas aplicaciones de producción necesitan de un soporte informático bien diseñado y estructurado que engloba a las Bases de Datos, Sistemas Operativos, Servidores de aplicaciones y Red de datos para comunicaciones. De todos ellos conviene tener breves nociones para poder participar en el diseño de un sistema integrado de información de la producción.

Fig. 2-6-1 Redes de información Con los avances en la tecnología informática, la caída de precios del hardware y el cambio en la naturaleza de los negocios10, el valor de la información ha alcanzado las cotas más altas. A todo esto hay que añadir la mejora de los Sistemas Operativos en los Servidores de aplicaciones, la mayor capacidad de almacenamiento en disco y la explosión de los desarrollos basados en tecnología web. Si además contamos con una Base de Datos bien organizada que pueda gestionar enormes cantidades de información estaremos hablando de lo que se ha dado en llamar el 'Almacén de Datos' o 'Data Warehouse', también denominados 'Sistemas Analíticos', en los que se basa cualquier Sistema de Información de la Producción que se han tratado hasta ahora. Los siguientes apartados de este punto tratarán de aclarar someramente estas disciplinas de la ciencia informática, aportando un poco de información resumida de campos que, por sí solos, requieren de un alto grado de especialización.



6.1. SISTEMAS OPERATIVOS

Toda aplicación informática – software - necesita de ordenadores – hardware - para su funcionamiento y, estos a su vez, de Sistemas Operativos que actúen de interfaz entre este software y hardware.

El objetivo fundamental de los Sistemas Operativos es gestionar y administrar eficientemente los recursos de hardware, permitiendo que se ejecuten concurrentemente varios programas, sin que haya conflictos en el acceso de cada uno de ellos a cada uno de los recursos que se necesite, y sin que ningún programa monopolice alguno de ellos.

La separación entre el software y el hardware, según Bill Gates12, es de crucial importancia, ya que si no existiera esta separación no se podría conseguir que la innovación se realizara de forma independiente en estas dos áreas.

Fig. 2-6-2 Entorno de los Sistemas Operativos

Para todo esto, un Sistema Operativo tiene por misión, además de actuar de intermediario entre los Usuarios y el hardware, administrar los recursos, procesadores, memoria, medios de almacenamiento, dispositivos de entrada/salida, comunicaciones, etc., consiguiendo así el uso eficiente de los ordenadores.

El Sistema Operativo dirige el tráfico dentro del ordenador, decidiendo qué recurso será usado y durante cuanto tiempo. El tiempo de la CPU (Procesador - Unidad Central de Proceso) está dividido en intervalos medidos en milisegundos. A cada tarea que realiza la CPU se le asigna una cierta cantidad de intervalos de tiempo. Cuando dicho tiempo expira, otra tarea obtiene su turno y la primera entra en espera hasta obtener un nuevo turno. La forma de acelerar el proceso de una tarea determinada se realiza asignando prioridades a cada una de ellas, con esto, las prioridades altas obtienen tiempos más elevados de proceso que las prioridades más bajas.



Los Sistemas Operativos son en esencia administradores de recursos. El siguiente es un resumen de estos recursos y la función de cada uno de ellos:

1. Gestión de CPU. Gestionan, como se ha dicho antes, los tiempos de procesamiento asignados, en función de su prioridad, a cada tarea que se está ejecutando.

2. Gestión de Aplicaciones. Permite que las aplicaciones se ejecuten como tareas, dotando al sistema de una máquina virtual, es decir, un ambiente en el cual el Usuario pueda ejecutar programas de manera conveniente, protegiéndolo de los detalles y complejidad del hardware.

3. Recursos de Hardware. Administración eficaz de los recursos de la máquina.

4. Seguridad del Sistema. La Seguridad debe ser parte de un Sistema Operativo. En entornos multiusuario deberán existir procedimientos para control de accesos (Logon) con validación de claves secretas (Password). La seguridad también debe contemplar los datos y aseguramiento del funcionamiento ante fallos.

Fig. 2-6-3 Tareas de Gestión del Sistema Operativo

5. Entradas y Salidas. También es parte de un Sistema Operativo el control del flujo de la información. Éste deberá administrar todas las solicitudes de lectura de datos desde los discos u otros dispositivos de almacenamiento de datos hacia los dispositivos de salida como las impresoras o la pantalla. Para la administración de la salida de información por impresora existe el proceso denominado "Spool", que se encarga de ordenar y enviar, de uno en uno, los trabajos de impresión solicitados a las llamadas "Colas de Impresión".

6. Comunicaciones. El Sistema Operativo permite al Usuario manejar con facilidad todo lo referente a la instalación y uso de Redes de ordenadores.



7. Gestión de Memoria. Cada procesamiento de la CPU deja datos que quedan esperando en "Buffers" o Memorias Temporales de forma que no se pierda información. Una forma de ayudar al tráfico de estos datos es el uso de la Memoria Virtual. Esta incluye el uso de espacio en disco como parte de la Memoria Principal. Aunque este uso de disco ralentiza los procesos de cómputo, aumenta la cantidad de información que puede procesarse de forma simultánea. Al proceso de envío de información a disco, como parte de la memoria virtual, se le denomina "Swapping".

8. Dispositivos de Almacenamiento. Se trata de gestionar, de forma segura, los dispositivos de almacenamiento y los ficheros almacenados. Todo Sistema Operativo tiene sus comandos básicos de administración de archivos como crear carpetas, mover archivos, borrarlos, renombrar, etc. A su vez, los discos pueden estar particionados en varios discos virtuales, y el sistema los debe tratar como si fueran discos individuales, o encontrarse en unidades de almacenamiento masivas que, además, pueden estar compartidas por diversos ordenadores.

Un Sistema Operativo puede tener otras características adicionales como ser Tolerante a Fallos, poseer Técnicas de Recuperación de Errores, Generar Estadísticas, ser Eficiente para que realice sus funciones con los resultados esperados y evitar que los Usuarios interfieran y se bloqueen entre sí.

Al igual que en el campo de las bases de datos, en el mundo de los Sistemas Operativos existe la figura del Administrador de Sistemas - System Manager - que se encarga del mantenimiento y óptimo funcionamiento de los mismos. Una de las labores diarias de un Administrador de Sistemas es la realización de copias de seguridad o "BackUp" de la información. Estos BackUps podrán ser Completos, creando una copia de resguardo de todas las carpetas y archivos que se seleccionen, o Incrementales, generando una copia de resguardo con todos aquellos archivos que hayan sido modificados o se hayan creado desde el último backup realizado.

Otra forma de aumentar la seguridad del sistema es actuar sobre la redundancia del hardware. Esta redundancia puede afectar, principalmente, al ordenador soporte, para evitar caídas del sistema, o a los discos de almacenamiento, para evitar la pérdida de información:

Redundancia de Servidores

1. Sistemas Clúster. Un Clúster es un conjunto de ordenadores que trabajan en grupo para resolver una tarea. Un Clúster generalmente esta conformado por dos ordenadores, los cuales se comunican por medio de una conexión de red. Existen varios tipos de configuraciones para Clústeres en función del uso que se pretenda dar a los servidores; uno de ellos es el llamado libre de fallos o alta disponibilidad que tiene buena aplicabilidad en los sistemas de gestión de bases de datos que deben estar siempre en funcionamiento.



2. Sistemas Virtuales. Estos sistemas se basan en la creación de una máquina virtual que trabaja en conjunto con dos servidores simultáneamente. El resultado, en apariencia, es el de un solo servidor altamente tolerante a fallos sobre el cual actuarán los Administradores de Sistemas.

Un ejemplo de estos Sistemas Virtuales es el ofrecido por la empresa Marathon Technologies Corporation con su Ftvirtual Server™.

Fig. 2-6-4 Sistemas Virtuales

Redundancia de Discos

3. Sistemas RAID. Un Sistema RAID (Redundant Array of Inexpensive Disks) es una forma de almacenar los mismos datos en distintos lugares (por tanto, de modo redundante) en múltiples discos duros. Al colocar los datos en discos múltiples, las operaciones I/O (Input/Output - Entrada/Salida) pueden superponerse de un modo equilibrado, mejorando el rendimiento del sistema. Además, dado que los discos múltiples incrementan el tiempo medio entre errores, el almacenamiento redundante de datos incrementa la tolerancia a fallos.

Para el sistema operativo, un RAID aparenta ser un solo disco duro lógico. De las configuraciones posibles RAID, las más utilizadas son:

• RAID 1 o Discos Espejo, que constan de, al menos, dos discos duros que duplican el almacenamiento de datos.

• RAID 5, apropiada para entornos multiusuario. Necesita de un mínimo de tres discos para almacenar la información de paridad necesaria para la reconstrucción de la información en caso de fallo de uno de los discos que conforman el sistema.

A continuación se detallan los diversos tipos de Sistemas Operativos que existen en la actualidad con algunas de sus características, según una de las múltiples formas de clasificación posibles que se encuentran en la bibliografía:

1. Sistemas Operativos por Lotes. Procesan una gran cantidad de trabajos con poca o ninguna interacción entre los Usuarios y los programas en ejecución. Se utilizan para procesamiento científico pesado.



2. Sistemas Operativos de Tiempo Real. En estos sistemas no tiene importancia el Usuario, sino los procesos, y se utilizan en entornos donde son procesados un gran número de sucesos, como en el control de tráfico aéreo.

3. Sistemas Operativos de Tiempo Compartido. Al contrario que los anteriores, estos sistemas dan la sensación a cada Usuario de tener el servidor con dedicación plena. Son populares en sistemas multiprogramados multiusuario.

4. Sistemas Operativos Multitarea. Soportan la ejecución de dos o más trabajos activos al mismo tiempo. Son representantes de estos sistemas Unix™, Windows™ 2000/2003 o Linux.

5. Sistemas Operativos Distribuidos. Permiten distribuir trabajos o procesos entre un conjunto de procesadores, pudiendo estar estos procesadores en el mismo servidor o en servidores diferentes. Representan a este tipo Solaris-MC o Mach.

6. Sistemas Operativos de Red. Son sistemas que mantienen dos o más servidores unidos a través de algún medio de comunicación con el objeto de compartir los diferentes recursos y la información del sistema. Los sistemas operativos de red más ampliamente utilizados son Novell Netware, Unix™ y Windows™ 2000/2003.

De todos estos Sistemas Operativos, los más utilizados para instalaciones en ordenadores que actúan como servidores de aplicaciones son los que tienen capacidad de trabajar en red con entornos multiusuario y multitarea. Actualmente, los más populares son:

o Windows™ 2000/2003 de Microsoft®

o Unix™

o Linux - Sistema Operativo UNIX de acceso libre al código y gratuito de base que comienza a ser respetado y utilizado en la industria.



6.2. BASES DE DATOS

Un sistema de gestión de bases de datos (DBMS - DataBase Management System) consiste en una colección de datos interrelacionados y un conjunto de programas para acceder a ellos. A estas colecciones de datos se las denomina bases de datos y sirven de soporte de información a los diferentes Sistemas de Producción.

El objetivo primordial de un DBMS es conseguir que sea conveniente y eficiente para ser utilizado al extraer o almacenar información en la BD.

Los sistemas de bases de datos están diseñados para gestionar grandes bloques de información. Esto implica tanto la definición de estructuras para el almacenamiento como de mecanismos para la gestión de la información. Además los DBMS deben mantener la seguridad e integridad de la información almacenada, pese a la caída del sistema o accesos no autorizados.

Otra forma de dar una descripción de lo que es un sistema de gestión de Bases de Datos es decir que consiste en una colección de archivos sobre los que actúan un conjunto de programas que permiten a los Usuarios el acceso y modificación de la información que se almacena en ellas.

La abstracción de estos datos se puede representar en tres niveles diferentes:

1. Nivel Físico.- Es el nivel más bajo de abstracción y describe el almacenamiento real de los datos en los archivos del sistema.

2. Nivel Conceptual.- Describe los datos que realmente se almacenan en la Base de Datos y la interrelación entre ellos. Sobre este nivel actúa la figura del Administrador de Bases de Datos - DBA.

3. Nivel Visual.- Es el nivel más alto de abstracción y sobre él actúan los Usuarios de la información, obteniendo una visión filtrada y a medida de los datos que demandan.

Por otro lado, existen tres modelos de datos que pueden describir la estructura de una Base de Datos, Modelos lógicos basados en Objetos, Modelos lógicos basados en Registros y Modelos físicos basados en Datos. De los tres modelos existentes, el modelo basado en Registros es el más ampliamente utilizado.

Este modelo basado en Registros está formado, como su propio nombre indica, por una estructura de registros de formato fijo y que puede ser de varios tipos. Cada tipo de registros define un número fijo de Campos o atributos y cada campo tiene su propio formato y longitud.



El modelo basado en registros se subdivide a su vez en otros tres tipos:

1. Modelo Jerárquico.- Un sistema de gestión de bases de datos jerárquico representa los datos de forma ramificada en estructura de árbol. Los datos y las relaciones entre ellos se representan mediante registros y enlaces.

Fig. 2-6-5 Sistema de Bases de Datos Jerárquico

2. Modelo de Red.- El modelo de Red representa los datos como registros enlazados unos a otros, formando conjuntos de intersecciones de datos.

Fig. 2-6-6 Sistema de Bases de Datos de Red



3. Modelo Relacional.- Es el modelo que ha ganado aceptación por encima de los otros dos. Un RDBMS (Relational DataBase Management System) representa los datos y relaciones entre ellos mediante una colección de Tablas, cuyas filas representan los registros y cuyas columnas, de nombre único, representan los campos.

Fig. 2-6-7 Sistema de Bases de Datos Relacional

La forma de acceder y manipular una Base de Datos Relacional es mediante el lenguaje SQL (Structured Query Language). Este lenguaje SQL se ha establecido claramente como el lenguaje de Bases de Datos Relacional estándar.

El SQL se subdivide en dos tipos, según su modo de interactuar con la base de datos:

• Lenguaje de definición de datos (DDL - Data Definition Language). El SQL-DDL proporciona órdenes para definir tablas, crear sinónimos, dar de alta Usuarios, etc. Las sentencias 'base' más significativas de definición son:

C r e a t e , A l t e r , D r o p , T r u n c a t e , G r a n t y R e v o k e

Fig. 2-6-8 Creación de una tabla

Create Table MUESTRAS ( Nº MUESTRA number (9),

DESCRIPCION varchar2(40),

METODO varchar2(40),

USUARIO varchar2(16),

TIMESTAMP date);



• Lenguaje de manipulación de datos (DML - Data Manipulation Language). El SQL-DML incluye un lenguaje de consultas para la recuperación, modificación, inserción o eliminación de la información almacenada. Las sentencias 'base' más significativas de manipulación son:

S e l e c t , I n s e r t , U p d a t e y D e l e t e

Fig. 2-6-9 Consulta de datos

Existe en el mercado un buen surtido de gestores de Bases de Datos de los que cabe destacar los siguientes:

o ORACLE® de Oracle Corporation

o SQL Server™ de Microsoft®

o DB2™ de IBM Corp.

o Informix™ de IBM Corp.

Siendo el sistema más ampliamente utilizado para grandes desarrollos el DBMS de ORACLE®. Para desarrollos menos ambiciosos está siendo cada vez más utilizado el SQL Server™ por su precio mucho más reducido.

Hay que tener en cuenta que, como dice Eric Brown en su artículo sobre SQL Server 200511, debido al auge de las Bases de Datos, a los Administradores de las mismas - DBAs - se les pide la gestión de, cada vez, una mayor cantidad de información diversificada en diferentes Bases de Datos. Por este motivo es importante no diversificar demasiado los diferentes tipos de DBMS sobre los que se va a almacenar la información de la Compañía, facilitando y simplificando la labor de los DBAs y mirando, a su vez, por la reducción de costes que esto suponga.

Select Nº MUESTRA, DESCRIPCION, METODO,

USUARIO, TIMESTAMP

From MUESTRAS

Where TIMESTAMP between today and yesterday-10

Order by Nº MUESTRA;



6.3. REDES Y COMUNICACIONES

Por último, toda Compañía necesita de una red informática interna o Intranet que permita el intercambio de información mediante la interconexión de ordenadores de aplicaciones, llamados Servidores, y ordenadores de Usuario, llamados Clientes.

Una Red corporativa privada bien diseñada permite compartir recursos e información con la fiabilidad y seguridad de protección de la información ante eventualidades o intrusiones.

Fig. 2-6-10 Configuración Cliente - Servidor

Para ilustrar la importancia de las Redes y Comunicaciones, en su libro "The Road Ahead", Bill Gates13 expresaba hace apenas diez años su visión sobre los cambios revolucionarios que las nuevas comunicaciones e Internet provocarán en una inminente nueva sociedad. Estos cambios, dice, afectarán al propio hogar y al mundo industrial, "The Internet Gold Rush", donde las empresas modificarán su forma de hacer negocio, apareciendo nuevos empleos y convirtiéndose otros en obsoletos. Hoy en día nadie puede dudar de su vaticinio.

Las redes que se montan en la industria son Redes Locales - LAN (Local Area Network) que conformarán la Intranet privada de la Compañía. Una Red Local es un sistema de comunicación de datos que permite que dispositivos independientes se comuniquen entre sí, de igual manera que otras redes de datos, pero, en el caso de las LANs, restringiendo la comunicación a un zona limitada, en la mayoría de los casos, a un lugar de trabajo, edificio, fábrica, etc.

Las velocidades de transmisión de datos sobrepasan hoy en día los 1000 Mbps (Megabits por segundo). Las topologías empleadas pueden ser de canal de distribución (bus), de anillo (ring) o de estrella. Como medios de transferencia se utilizan, normalmente, cables coaxiales, cables telefónicos de dos hilos y fibras ópticas. Estos cables están interconectados con los nodos de control. Últimamente se comienzan a utilizar conexiones WI-FI y Transmisión Celular.



Se denomina topología de una red a la configuración formada por sus nodos y las interconexiones que los unen. Las topologías más ampliamente utilizadas en las redes locales son:

1. Estrella. Todos los mensajes pasan a través de un conector central.

2. Anillo (ring). Los nodos se conectan formando un anillo. Ningún nodo controla totalmente el acceso a la red.

3. Canal de distribución (bus). Todos los nodos comparten el mismo canal de comunicaciones. La configuración no tiene forma de bucle. Los nodos utilizan el canal de distribución para comunicarse con los nodos restantes.

Fig. 2-6-11 Topologías de Estrella (a), Anillo (b) y Bus (c)

Las redes comerciales habitualmente utilizadas son ETHERNET, fruto del desarrollo conjunto de Xerox - Digital - Intel, con topología de Bus con cable coaxial, par trenzado o fibra óptica y TOKEN RING que combina la topología física en estrella y lógica en anillo.

Cuando existe la necesidad de expandir una red LAN, por ejemplo a las diferentes factorías que posea una Compañía a lo largo del mundo, aparece el concepto de Red de Area Extensa - WAN (Wide Area Network). Una red WAN se puede montar por interconexión de diferentes redes LAN mediante el uso de unos elementos denominados Routers, que a su vez también pueden actuar de Cortafuegos (Firewalls) para aumentar la seguridad de la red corporativa impidiendo el paso de información y accesos no autorizados.



Las grandes empresas disponen de redes corporativas de voz y datos basadas en una serie de redes LAN y Routers. Desde el punto de vista del Usuario, este enfoque proporciona una red físicamente heterogénea con aspecto de un recurso homogéneo.

Al conjunto de normas que definen todos los aspectos que intervienen en una comunicación y, por tanto, el formato que van a tener los paquetes de información y órdenes que un dispositivo va a aceptar se denomina Protocolo de Red. El protocolo TCP/IP (Protocolo de Control de Transmisión / Protocolo de Internet) es un estándar hoy en día por sus facilidades de enrutamiento. Tiene la ventaja de tener compatibilidad con todos los sistemas operativos y posibilita la conexión de sistemas con protocolos distintos entre sí como FTP o TelNet.

El cableado de conexión entre las diferentes partes de la LAN puede ser Vertical y Horizontal. El cableado vertical es el que permite comunicar los diferentes centros o agrupaciones de Usuarios entre sí. Para este tipo de cableado es apropiado el uso de un Backbone (columna vertebral) de fibra óptica. El cableado horizontal conecta los diferentes puntos de Usuario al Backbone de la red, como ordenadores personales, impresoras, etc. Para este tipo de cableado es apropiado el uso de par trenzado (UTP).

Debido a las altas velocidades en la transferencia de información que se consiguen hoy en día, cada vez es más habitual la integración de voz y datos en las redes, por conexión a las mismas de las centralitas de teléfono de cada centro de la Compañía, con lo que se consigue un ahorro importante en el gasto de telefonía (Voz IP). También se está haciendo habitual el uso de videoconferencia, correo electrónico y, en resumen, lo que se viene denominando teletrabajo.

Una red de área local puede estar formada por subredes de diferentes topologías, combinando, p. ej., Ethernet para comunicación de servidores de aplicaciones, Giga Ethernet para conexión de los diferentes puntos del centro industrial y Telefónica para conexión entre las diferentes y distantes LAN de la Compañía.



Fig. 2-6-12 Diferentes topologías dentro de una LAN

Aunque forma parte de las aplicaciones gestionadas en las redes de información, los desarrollos "Web" son cada vez más habituales por su simplicidad en la gestión de administración en la parte de los Clientes de las aplicaciones. Estos desarrollos pueden llegar a ser de tal complejidad y ámbito que llegan a dar la sensación de una intranet de información dentro de la intranet general de la Compañía. Para este tipo de desarrollos es necesario el dominio de lenguajes de programación como son HTML, Java o Visual Basic.



Por último, no se puede terminar un capítulo sobre Redes sin tocar el tema de Seguridad de la información. En la actualidad14, las organizaciones son cada vez más dependientes de sus redes informáticas y un problema que las afecte, por mínimo que sea, puede llegar a comprometer la continuidad de las operaciones. La falta de medidas de seguridad en las redes es un problema que está en crecimiento. Tampoco deben subestimarse las fallas de seguridad provenientes del interior mismo de la organización. La propia complejidad de la red es una dificultad para la detección y corrección de los múltiples y variados problemas de seguridad que van apareciendo. En medio de esta variedad, han ido aumentando las acciones poco respetuosas de la privacidad y de la propiedad de recursos y sistemas. “Hackers”, “crakers”, entre otros, han hecho aparición en el vocabulario ordinario de los Usuarios y de los administradores de las redes. Además de las técnicas y herramientas criptográficas, es importante recalcar que un componente muy importante para la protección de los sistemas consiste en la atención y vigilancia continua y sistemática por parte de los responsables de la red, sin descartar el uso de un buen antivirus que ayude a mantener la funcionalidad de la información.

A la hora de plantearse en qué elementos del sistema se deben de ubicar los servicios de seguridad podrían distinguirse dos tendencias principales:

1. Protección de los sistemas de transferencia o transporte. En este caso, el administrador de un servicio asume la responsabilidad de garantizar la transferencia segura al Usuario final de la información de forma lo más transparente posible. Ejemplos de este tipo de planteamientos serían el establecimiento de un nivel de transporte seguro, de un servicio de mensajería segura, o la instalación de un firewall, que defiende el acceso a una parte protegida de una red.

2. Aplicaciones seguras extremo a extremo. Si pensamos, por ejemplo, en el correo electrónico, consistiría en construir un mensaje en el cual el contenido ha sido asegurado mediante un procedimiento de encapsulado previo al envío. De esta forma, el mensaje puede atravesar sistemas heterogéneos y poco fiables sin por ello perder la validez de los servicios de seguridad provistos. Aunque el acto de asegurar el mensaje cae bajo la responsabilidad del Usuario final, es razonable pensar que dicho Usuario deberá usar una herramienta amigable proporcionada por el responsable de seguridad de su organización.

Esta operatoria, que puede usarse para abordar el problema de Seguridad en Redes, se debe tener en cuenta para la seguridad en otras aplicaciones tales como videoconferencia, acceso a bases de datos, etc. En ambos casos, un problema de capital importancia es la gestión de passwords. Este problema es inherente al uso de la criptografía y debe estar resuelto antes de que el Usuario esté en condiciones de enviar un solo bit seguro.

Por todo esto es muy conveniente la definición e implantación de una Política de Seguridad de la Información con su alcance, objetivos y responsabilidades.



7. ACTIVIDADES PROFESIONALES

El esquema que se presenta a continuación, ilustra las necesidades del equipo de trabajo que se dedicará a la administración de los Sistemas de Producción, así como la relación con los equipos de profesionales de los que requerirá información y los que harán uso de estos Sistemas de información de la Producción.

Actividades profesionales relacionadas con el módulo. Generación de nueva información: - Departamento de Soporte informático y gestión de Redes de Información.

Conocimientos adquiridos en el Módulo: - Visión global y generalista sobre un proyecto de Gestión

de Información de Planta. - Visión del equipo humano a formar.

Datos de Otros requeridos: - Variables y Gráficos de Proceso procedentes del

Sistema de Control. - Diagramas P&I. - Información fiscal de Productos de la Compañía. - Información de Gestión de Laboratorio. - Información comercial, clientes, proveedores, etc. - En general, toda la información necesaria, de

acuerdo al alcance de aplicabilidad del proyecto de Sistemas de Producción.

Actividades de Otros que requieren esta información: - Departamento de Procesos - Consulta de información de Producción en tiempo real. - Laboratorio - Información de los datos que generan para la Compañía. - Departamento de Operaciones - Consulta de calidad del proceso. Control de inventarios - Dirección Económico Financiera – Gestión de Compra / Venta.

Conocimientos previos necesarios: - Conocimiento del Proceso Industrial - Administración de Bases de Datos - Administración de Sistemas

Operativos - Conocimientos de Programación



8. REFERENCIAS Y BIBLIOGRAFÍA

A continuación se enumeran las Referencias y Bibliografía utilizada en este capítulo.

Referencias:

1. Planning as Learning, Harvard Business Review, A. De Geus, 1988 2. Midiendo, Administrando y Maximizando el Rendimiento de Plantas Industriales,

Osvaldo A. Bascur, Ph.D., OSISoft®, February 12, 1996 3. Selecting a Real Time Information Management System, Larry Phillips, U.S.A., 2003 4. Integration of SCADA, Information Systems and the Industrial Component Desktop,

O.A.Bascur, Ph.D. and J.Patrick Kennedy, Ph.D., OSISoft®, Houston, TX and San Leandro, CA., March 5, 1999

5. The PI tools in the CMDS (Center of Monitoring, Diagnosis and Simulation of Combined Cycle Power Plants), Maria Martin Gomez, Iberdrola, España, 2003

6. CMDS & IT Monitor, Miguel Chavero Escamilla, Iberdrola, España, 2003 7. PI: An Important Component In The Cleanup Of Boston Harbor, David F. Duest

Massachusetts Water Resources Authority, Deer Island Treatment Plant, April 2000 8. Data Reconciliation and Data Quality, Ales Soudek, 1999 9. AMERICAN SOCIETY FOR TESTING AND MATERIALS - ASTM®, Standard

Guide for Laboratory Information Management Systems (LIMS), ASTM E-1578-93, U.S.A. 1999

10. Data Warehousing with Oracle, Muhammad Ahmad Shahzad, Oracular, Inc. 11. An Overview of SQL Server 2005 Beta 2 for the Database Administrator, Eric Brown,

July 2004 12. Remarks, Bill Gates, Microsoft®, April 1997, San Francisco 13. The Road Ahead, Bill Gates, Microsoft®, Second edition 1996 14. Manual de Seguridad en Redes, Claudia E. Bello, Secretaria de la Función Pública

Argentina

Bibliografía:

1. IT Manager's Handbook, Bill Holtsnider & Brian D. Jaffe, Morgan Kaufmann, Octubre 2000

2. Computer Networks, Andrew S. Tanenbaum, Prentice Hall, Agosto 2002 3. Introduction to SQL, Lawrence Ellison, Oracle Corporation, 1985, 1989 4. Introducción a las Redes locales de informática aplicada, K.C.E. Gee, Ed. Diaz de

Santos, S.A., 1983 Applied Biosystems, SQL*LIMS, and Life Science LIMS are registered trademarks and AB (Design), Applera, SQL*QA, SQL*GT, SQL*Stability, iScience, iScience (Design), Celera Discovery System, and LS*LIMS are trademarks of Applera Corporation or its subsidiaries in the US and/or certain other countries. Applied Biosystems develops and manufactures its products in accordance with ISO 9001:2000 systems quality requirements. ©2005 Applied Biosystems. All rights reserved.

Módulo: Sistemas de control Profesor: Miguel Ángel Sinobas


Sección Española

Master de Instrumentación y control




Módulo 7ATema 2

2

Sección Española

Master de Instrumentación y Control Módulo 7A Tema 2 S. Gestión de la Producción

Un Master sobre Instrumentación y Control no quedaría completado si no se tocaran los aspectos de la utilización de estos datos en aspectos informativos, para toma de decisiones, o para efectuar la compra/venta de productos, gestión de stocks, control de impuestos especiales, etc.

Pretensión de mostrar ideas generales sobre aspectos del tratamiento de la información y la importancia de esta para el estudio y control del proceso, documentación obligatoria en la actividad mercantil, etc.

Poca información escrita sobre los Sistemas de Producción desde un punto de vista global. En general, son los suministradores de aplicaciones los que dan una buena idea sobre este mundo en sus manuales o en las páginas Web correspondientes.

Sopa de siglas: SGL, Oracle, PI, LAN, Ethernet, ODBC, OPC, Sql*Net ...

Presentación



3

Sección Española


Dentro de los ‘Sistemas de Gestión de la Producción’ se engloban aquellos Sistemas de Información y Aplicaciones dedicadas a facilitar información sobre el estado, en tiempo real o pasado, de la Producción, bien proporcionando datos de medidores de temperaturas, caudales, presiones, etc., bien ofreciendo datos de Laboratorio sobre la calidad de las diversas corrientes intermedias, productos terminados, etc., o bien gestionando el inventariado de los elementos de almacenamiento, los movimientos, entradas y salidas de productos en la planta y así un largo etcétera

Introducción

4

Sección Española


Distribución de la información de producción en la Compañía

Distribución

Instrumentación de Campo


Control Avanzado

Optimización de Producción

Sistema integrado de Gestión

de Producción

Supervisión y toma de decisiones



5

Sección Española


Funciones de los Sistemas de Producción

Funciones

Como ‘Sistemas de Gestión de la Producción’ se engloban aquellos Sistemas de Información y Aplicaciones dedicadas a facilitar información de la Producción, bien en tiempo real o mostrando la historia pasada, cumpliendo las siguientes funciones:

•Proporcionar datos de medidores de temperaturas, caudales, presiones, analizadores en línea, etc., mediante un Sistema de Información de la Planta

•Ofrecer datos de Laboratorio sobre la calidad de las diversas corrientes intermedias, productos terminados, etc., mediante un Sistema de Información de Laboratorio

•Proporcionar información sobre la gestión de los movimientos, entradas y salidas de productos en la planta, inventariado de los elementos de almacenamiento, etc., mediante el uso de un Sistema de información de la Producción

6

Sección Española


InstrumentaciónNecesidades de Instrumentación

Una correcta instrumentación, que tenga en cuenta las necesidades de información aguas arriba en el flujo informativo, posibilitará un adecuado desarrollo de los Sistemas de Gestión de la Producción



7

Sección Española


Previos

Poca documentación:Contacto con proveedores Visitas a plantas similares

¿Es el producto una solución industrial a nivel internacional?¿Es fácil de instalar?¿Tiene la empresa suministradora un buen servicio de soporte y actualizaciones?¿Es fácil de usar?¿Tiene capacidad de gestión y almacenamiento de información en tiempo real?¿Tiene posibilidad de crear estructuras Cliente/Servidor?¿Es escalable o ampliable?¿Permite la explotación de información en Internet/ Intranet?¿Tiene el suministrador un buen negocio con el producto?¿Vale lo que cuesta? ¿¿...??

8

Sección Española


Detalle de Funciones

Historización, visualización y explotación de datos de plantaGestión de información del LaboratorioEmisión de Certificado de CalidadEmisión de Certificado de CantidadCompensación de CaudalesGestión de Entradas y SalidasBalance de UnidadesBalance de redes de EnergíasBalance general de la CompañíaGestión de Existencias y MovimientosReconciliación de datosCálculo de composicionesGestión Fiscal y AdministrativaCentro de ExpedicionesBlending en líneaIntercambio de información entre los Sistemas de Producción



9

Sección Española


Agrupación de Funciones - SCADA

Sistema de Información de Planta - SCADAHistorización, visualización y explotación de datos de plantaGestión de información del Laboratorio



Compensación de CaudalesGestión de Entradas y Salidas

Balance de Unidades





Cálculo de composiciones



Blending en línea


10

Sección Española


Agrupación de Funciones - SGL

Sistema de Gestión de Laboratorio – SGL (LIMS)Historización, visualización y explotación de datos de planta


Emisión de Certificado de CalidadEmisión de Certificado de Cantidad



Balance de Unidades





Cálculo de composiciones



Blending en línea




11

Sección Española


Agrupación de Funciones - SP

Sistema de Información de Producción – SPHistorización, visualización y explotación de datos de plantaGestión de información del LaboratorioEmisión de Certificado de Calidad

Emisión de Certificado de CantidadCompensación de Caudales

Gestión de Entradas y SalidasBalance de UnidadesBalance de redes de EnergíasBalance general de la CompañíaGestión de Existencias y MovimientosReconciliación de datosCálculo de composicionesGestión Fiscal y AdministrativaCentro de ExpedicionesBlending en líneaIntercambio de información entre los Sistemas de Producción

12

Sección Española


Agrupación de Funciones - SII

Sistema de Interfases de Información – SIIIntercambio de información entre los Sistemas de Producción



13

Sección Española


Gestión de Empresa

14

Sección Española


SCADA

Sistema de Información de Planta

SCADA - Supervision, Control And Data Acquisition

•Integración total entre la instrumentación de Planta y el resto de los Sistemas de Producción, sirviendo de plataforma de datos hacia los mismos•Información en tiempo real sobre las Unidades de Proceso, permitiendo, de igual manera, la consulta de datos históricos de las mismas



15

Sección Española


SCADA

PI (Plant Information) de OSISoft

PHD (Plant History Database)

de Honeywell

Infoplus de AspenTech

Estos Sistemas de Información de Planta son ampliamente utilizados en industrias como:

Petroquímica Papelera Aeroespacial Farmacéutica

Energética Nuclear Depuración de Agua Química

16

Sección Española


SCADA

Un Sistema de Información de Planta bien diseñado permite la recolección ininterrumpida y el almacenamiento indefinido de los datos de Producción recogidos de cada uno de los Sistemas de Control que contenga la Compañía, dando solución, dicho sea de paso, a la corta vida que posee la información en estos SCD's y a la escasa perspectiva que ofrecen de la Planta al completo

Se puede decir que un Sistema de Control necesita de información puntual con una frecuencia de muestreo elevada para posibilitar un buen control, mientras que un

Sistema de Información de Planta no necesita de esta frecuencia elevada, pero requiere de gran capacidad de almacenamiento para posibilitar la consulta de la historia de producción



17

Sección Española


Caso de estudio: PI

El PI™ - Plant Information es una aplicación suministrada y desarrollada por OSISoft™ cuya función es la historización de valores de las variablesde las unidades de proceso, permitiendo el acceso rápido a cualquier momento de esta historia de forma puntual o por periodos. Estos valores se almacenan en unidades lógicas denominadas TAGS o Puntos de PI™

•Tag: Puntos de PI

•Visualizador: ProcessBook, ActiveView, RtPortal

•Herramientas de Usuario: Datalink, API-SDK (VisualBasic)

18

Sección Española


PI

Plant Information – PI - RtPM

El sistema PI™ está basado en una base de datos que almacena valores puntuales del SCD y otros sistemas, en el Servidor donde reside. Para el caso de datos de instrumentos de Planta, la recogida de los mismos se realiza a través de un módulo interfase denominado APP Node



19

Sección Española


PIPantallas ejemplo de gráficos de proceso

RtPortal/ActiveView

ProcessBook

Tendencia

20

Sección Española


PI - Presupuesto

Compra a OSI de un Sistema PI™ con 50.000 Tags 100.000Adquisición de 300 licencias de ActiveView 34.000Adquisición de 5 licencias de ProcessBook 30.000Servidor wintel en Cluster W2000 Server para PI™ 30.000Contratación del Trabajo de Instalación de PI™ 8.000Contratación de Formación de administración del Sistema 15.000AppNode (3) (Conexión PI - SCD) 105.000OPC Client (AppNode) (3) - Interfaz con PI 5.000Otros 23.000

Total: 350.000

Concepto Precio €



21

Sección Española


SPSistema de Información de Producción

Información necesaria relativa a los procesos, unidades de producción, materias primas y productos con el fin de optimizar la gestión y apoyar a la toma de decisiones, haciendo partícipe de esta información al conjunto de Direcciones de la Compañía

22

Sección Española


SP - Funciones•Gestión de ExistenciasSituación de elementos de almacenamiento e inventarios

•Gestión de MovimientosEntrada / Salida

Transferencia

Alimentación Unidad

Purga

- Datos -

Nivel + Tª + Pres.

Densidad



23

Sección Española


SP - Funciones

•Cálculo de Composiciones de materias primasTanques de Crudo mezcla de diferentes características

•Gestión de Entradas y SalidasCompra - Venta

Basada en la gestión de Movimientos, Certificado de Cantidad, Gestión fiscal y Administrativa

24

Sección Española


SP - Funciones•Centro de ExpedicionesSuministro por Cisterna

•Emisión de Certificado de CantidadBinomio junto al Certificado de Calidad y otros documentos legales



25

Sección Española


SP - Funciones

•Balance Global DiarioSíntesis de la información diaria relativa a Existencias iniciales y finales, Entradas y Salidas, Proceso y Producción, Autoconsumos y Mermas

•Blending en LíneaLlegar a Tanque final con un producto dentro de especificación

•Balance de UnidadesContabilidad de las corrientes de alimentación y las corrientes de producción, dando información, además, de las mermas diarias en peso

26

Sección Española


SP - Funciones•Balance de EnergíasCómputo de los combustibles autoconsumidos, vapor, agua, energía eléctrica o térmica, controlando y contrastando los Aportes y Consumos

•Balance general de la CompañíaCombinando parte de la información sintetizada en el Balance Global Diario con el detalle de Proceso/Producción y Autoconsumos proporcionado por los Balances diarios de Unidades y Energías se puede conseguir el Balance Mensual oficial de la Compañía que permitirá registrar la historia de la actividad productiva de la misma a lo largo del tiempo

•Reconciliación de datosDebido a las muy diversas fuentes de información y la incertidumbre en los medidores de Planta, se hace muy conveniente una reconciliación de la información, sobre todo en lo referente a los datos que entrarán en juego a la hora de cuadrar los balances de unidades de producción y redes de energías



27

Sección Española


SP - Funciones•Gestión FiscalProvee de información, cuando aplique, sobre la fiscalidad de los productos, impuestos especiales, inspección permanente de la Administración, etc.

•Control de EmisionesMotivada por las últimas normativas de ámbito nacional como el control de Efecto Burbuja con las emisiones de SO2, responsable de la lluvia ácida, e internacional, con el Protocolo de Kioto para el control de las emisiones de CO2 por chimenea, responsable del efecto invernadero

28

Sección Española


Caso de estudio: SPC

Debido a la excesiva complejidad de un Sistema de Información de la Producción con todas las funciones expuestas, se puede optar al desarrollo propio del núcleo del mismo y a desarrollos parciales, o compra, de cada una de las funciones de las que se le quiera dotar

SPC – Sistema de Producción del Complejo industrial

Basado en tecnología Cliente/Servidor y desarrollado sobre Oracle en el Servidor y Developer en los ClientesDesarrollado por Repsol YPF para sus Refinerías



29

Sección Española


SPCGestión de las Composiciones de Crudo en Tanques

30

Sección Española


SPCGestión de Movimientos



31

Sección Española


SGLSistema de Gestión de Laboratorio

Gestión de la información del Laboratorio de Planta y la transmisión de los resultados analíticos que se generan a todos los Usuarios de la Compañía, siendo una herramienta imprescindible para una buena gestión de la Calidad y control del Proceso

32

Sección Española


SGL

Sistemas LIMS

SQL*LIMS de Applied Biosystems

SampleManager de Thermo LabSystems

STARLIMS de StarLims Corporation

CALS de Beckman

Xp-LIMS de Scadasoft Sistemas S.L.

Todas ellas están concebidas para gestionar el trabajo diario del Laboratorio, independientemente del tipo de empresa que lo vaya a usar, por lo que, en general, su funcionalidad excederá de lo que en la práctica se llega a necesitar, requiriendo de algunos ajustes de información para encuadrarlas con las necesidades específicas



33

Sección Española


Funciones SGL

Funciones del Sistema de Gestión de información de Laboratorio

34

Sección Española


Funciones SGL•Sistema (Administración)Definición de Grupos, alta de Usuarios y asignación

de permisos

Creación de los Grupos de Datos

Asignación de Reglas y Parámetros de Sistema

•Plantilla Analítica (Estructura de datos)Unidades de Medida

Análisis - Métodos

Definición de Límites: Medida, Detección y Especificación

Productos - Corrientes

Creación de Muestras



35

Sección Española


Funciones SGL

•Trabajo (Funciones habituales)Registro de Muestras

Resultados y Supervisión

Acciones Automáticas

Conexión de Equipos

Distribución de la información

Certificado de Calidad

36

Sección Española


Configuración del Sistema

•Parámetros de SistemaDonde se configuran aspectos referidos a la seguridad de los datos, formatos de presentación de información, etc.

•ReglasAlgunos sistemas permiten definir Reglas o Tratamientos que supervisarán las acciones durante las 'operaciones básicas' del SGL para diferenciar, p. ej., muestras de certificado de calidad de muestras programadas para el control diario de las unidades de proceso

•Grupos de DatosServirán para asociar cada una de las entidades de un SGL - muestras, productos, ensayos, etc. - a un Grupo de Datos concreto, con el fin de asociar y filtrar, si fuera necesario, la información a los Usuarios



37

Sección Española


•UsuariosDonde se darán de alta todos los Usuarios de la aplicación y se les asociará la categoría que les corresponda y los grupos de datos a los que vayan a tener permiso de acceso

Configuración del Sistema•CategoríasSe necesitan crear Categorías de Usuarios con permisos para realizar diferentes funciones dentro del SGL. Estas Categorías deberán definir a los administradores de la aplicación, los analistas, los Usuarios de planta, Usuarios generales, etc.

38

Sección Española


Plantilla Analítica

Unidades de Medida

Límites: Medida – Detección – Especificación

Productos – Corrientes

Operaciones – Métodos

Muestras



39

Sección Española


Plantilla Analítica


Adaptación - Observaciones

Calibración de Equipos

Plan Analítico

40

Sección Española


Ciclo de TrabajoRegistro de Muestras

Resultados y Supervisión


Conexión a Equipos

Distribución de la información




41

Sección Española


Ciclo de TrabajoCertificado de Calidad

Firma Electrónica

Auditoría de Transacciones

Supervisión de Resultados Críticos

Gestión interna del Laboratorio


42

Sección Española


Caso de estudio: SQL*LIMS

Basado en tecnología Cliente/Servidor y desarrollado sobre Oracle en el Servidor y Developer en los Clientes

El SQL*LIMS® es una aplicación ampliamente utilizada a nivel internacional como núcleo del SGL - LIMS, suministrada por Applied Biosystems®

Necesita cuatro Monitores activos:Dispatcher

Logger

Status

Event



43

Sección Española


SQL*LIMSDistribución de la información en el SQL*LIMS

Sistema de información combinada de Status y Condition que informa de la situación de cualquier nivel de la estructura de resultados

44

Sección Española


SQL*LIMSEstructura jerárquica de Plantilla y Resultados

Posibilita la traducción libre de textos de pantallas, adición de datos complementarios y ficheros adjuntos



45

Sección Española


SQL*LIMSFormulario de consulta de resultados por muestra

Formularios con estructura Maestro / Detalle

46

Sección Española


SQL*LIMSInforme de seguimiento de resultados

Desarrollo con herramientas de Oracle



47

Sección Española


SGL- Presupuesto

Adquisición de 20 licencias de acceso concurrente a SQL*LIMS 180.000Adquisición de Oracle y 100 licencias de acceso 30.000Adquisición de herramientas de desarrollo ORACLE (1 Licencia) 7.000Servidor wintel W2000 Server para SQL*LIMS 30.000Trabajo de Instalación y verificación de ORACLE y SQL*LIMS 2.000Contratación de Formación para Administradores del Sistema 12.000Consultoría, personalización y desarrollos a medida 80.000Módulos de Registro Automático y Calibración de Equipos 24.000Otros 10.000

Total: 375.000

Concepto Precio €

48

Sección Española


Soporte InformáticoRedes de Información

Pilares del Soporte informático para Gestión de Producción:Bases de Datos

Sistemas Operativos

Redes y Comunicaciones



49

Sección Española


Sistemas OperativosEntorno de los Sistemas OperativosToda aplicación informática, sw, necesita de ordenadores, hw, para su funcionamiento y, estos a su vez, de Sistemas Operativos como interfaz

El objetivo fundamental de los Sistemas Operativos es gestionar y administrar eficientemente los recursos de hardware, permitiendo que se ejecuten concurrentemente varios programas, sin que haya conflictos en el acceso de cada uno de ellos a cada uno de los recursos que se necesite, y sin que ningún programa monopolice alguno de ellos

50

Sección Española


Sistemas Operativos

Tareas de Gestión del Sistema Operativo

Gestión de CPU

Gestión de Aplicaciones

Recursos de Hardware

Seguridad del Sistema

Entradas y Salidas

Comunicaciones

Gestión de Memoria

Dispositivos de Almacenamiento



51

Sección Española


Sistemas Operativos

Seguridad de los Sistemas OperativosAdministrador de Sistemas – System Manager

Política de Copias de Seguridad – Backup

Sistemas Cluster

Sistemas Virtuales

Sistemas de almacenamiento RAID

RAID 1: Discos Espejo

RAID 5: Necesita de un mínimo de tres discos

52

Sección Española


Sistemas Operativos•Sistemas Operativos MultitareaSoportan la ejecución de dos o más trabajos activos al mismo tiempo

•Sistemas Operativos de RedMantienen dos o más servidores unidos a través de algún medio de comunicación con el objeto de compartir los diferentes recursos y la información del sistema

Windows 2000 / 2003

Unix

Linux



53

Sección Española


Bases de Datos

Un sistema de gestión de bases de datos consiste en una colección de datos interrelacionados y un conjunto de programas para acceder a ellos. A estas colecciones de datos se las denomina bases de datos y sirven de soporte de información a los diferentes Sistemas de Producción

Los sistemas de bases de datos están diseñados para gestionar grandes bloques de información. Esto implica tanto la definición de estructuras para el almacenamiento como de mecanismos para la gestión de la información

Consiste en una colección de archivos sobre los que actúan un conjunto de programas que permiten a los Usuarios el acceso y modificación de la información que se almacena en ellas

54

Sección Española


Bases de DatosBases de Datos basadas en Registros

Modelo Jerárquico

Modelo de Red



55

Sección Española


Bases de DatosBases de Datos basadas en Registros

Modelo Relacional

Es el modelo que ha ganado aceptación por encima de los otros dos. Un RDBMS (Relational DataBase Management System) representa los datos y relaciones entre ellos mediante una colección de Tablas, cuyas filas representan los registros y cuyas columnas, de nombre único, representan los campos

56

Sección Española


SQL

Definición de datos

Manipulación de datos

La forma de acceder y manipular una Base de Datos Relacional es mediante el lenguaje SQL (Structured Query Language). Este lenguaje SQL se ha establecido claramente como el lenguaje de Bases de Datos Relacional estándar



57

Sección Española


Bases de Datos

ORACLE de Oracle Corporation

SQL Server de Microsoft

DB2 de IBM

Informix de IBM

Existe en el mercado un buen surtido de gestores de Bases de Datos Relacionales de los que cabe destacar los siguientes:

58

Sección Española



Red informática interna o Intranet que permita el intercambio de informaciónmediante la interconexión de ordenadores de aplicaciones, llamados Servidores, y ordenadores de Usuario, llamados Clientes

Redes Locales - LAN (Local Area Network) conforman la Intranet privada de la Compañía. Una Red Local es un sistema de comunicación de datos que permite que dispositivos independientes se comuniquen entre sí, restringiendo la comunicación a un zona limitada



59

Sección Española


Redes y ComunicacionesTopología de RedesSe denomina topología de una red a la configuración formada por sus nodos y las interconexiones que los unen

•Estrella: Todos los mensajes pasan a través de un conector central

•Anillo (ring): Los nodos se conectan formando un anillo

•Canal de distribución (bus): Todos los nodos comparten el mismo canal de comunicaciones. La configuración no tiene forma de bucle

60

Sección Española



•WAN (Wide Area Network): Una red WAN se puede montar por interconexión de diferentes redes LAN mediante el uso de unos elementos denominados Routers

•Ethernet: Topología de BUS

•Token Ring: Topología física en Estrella y lógica en Anillo

•TCP/IP (Protocolo de Control de Transmisión / Protocolo de Internet) Protocolo de Red estándar que supone un conjunto de normas que definen todos los aspectos que intervienen en una comunicación y, por tanto, el formato que van a tener los paquetes de información y órdenes que un dispositivo va a aceptar se denomina



61

Sección Española


LANLocal AreaNetwork

Sección Española


ISA - ISEMódulo 7A-2

Miguel Angel Sinobas Control Avanzado y Sistemas de Producción Petronor –Repsol YPF

PREGUNTASVALORACIÓN

Sistemas deGestión de la Producción

7B1

INGENIERIA DE SISTEMAS DE CONTROL

FICHA IDENTIFICATIVA DEL DOCUMENTO:

Master ISA de instrumentación y control

Módulo: 7B1 – Ingeniería de Sistemas de Control

Tema: 7B1 – Ingeniería de Sistemas de Control

Autor: Marisa Sanzo

INTRODUCCIÓN

Comprendidos y asimilados los conceptos presentados en el módulo 81A relativos a Sistemas de Control Distribuido, la tarea previa a la ejecución de un proyecto es inexorablemente la de diseñar y especificar técnicamente dicho Sistema de Control Distribuido.

Este paso es de obligado cumplimiento tanto para:

- El usuario final del la solución de control, responsable de la definición de los requisitos y estándares que desea para su proyecto.

- La ingeniería, responsable de transcribir en formato de especificación técnica los requisitos indicados por el usuario final así como de ejecutar o al menos supervisar la fase de ejecución del proyecto.

- El suministrador o fabricante, responsable de ofrecer una solución de control que se adecue a lo especificado así como de soportar y apoyar a la ingeniería y al usuario final durante la fase de ejecución del proyecto.

El desarrollo de contenidos está enfocado a futuras tareas genéricas de especificación y diseño de sistemas de control de acuerdo con las necesidades de un futuro proyecto obviando las características concretas de un determinado producto o solución existente en el mercado.

Igualmente se proporciona una guía de aspectos y contenidos a tener en cuenta por ingeniería y usuarios finales durante la fase de ejecución de un proyecto de control.

Módulo: 7B1 INGENIERÍA DE SISTEMAS DE CONTROL

Tema: 7B1 –Ingeniería de Sistemas de Control

Master ISA – ISE de Instrumentación y Control Página 2

SISTEMAS DE CONTROL

Índice

1. ALCANCE Y DISEÑO DE UN SISTEMA DE CONTROL DISTRIBUIDO 4

1.1. Objetivo 5

1.2. Elementos Contables 6

1.1.1. Tarjetas de Entradas y Salidas. 6

1.1.2. Controladores 7

1.1.3. Consolas 7

1.1.4. Equipos de Terceros 7

1.1.5. Reserva Equipada 8

1.1.6. Reserva Espacial 8

1.1.7. Módulos de Control e Interfase de Operación 8

1.3. Filosofía 9

1.1.8. Segregación 9

1.1.9. Redundancia 9

1.1.10. Seguridad y Protecciones 9

1.1.11. Integración de la Información 10

2. CALCULOS ASOCIADOS 11

1.4. Cálculos de Capacidad Hardware 12

2.1.1. Tarjetas de Entradas y Salidas 12

2.1.2. Tarjetas de Comunicaciones 12

2.1.3. Controladores 12

1.5. Cálculos Eléctricos 13

2.1.4. Dimensionamiento de Fuentes de Alimentación 14




2.1.5. Dimensionamiento de Líneas de Alimentación 19

2.1.6. Disipación de Calor 21

3. CONSTRUCCIÓN HARDWARE 24

1.6. Armarios de Control 25

1.7. Interconexionado de Señales 26

1.8. Sistema de Tierras 27

3.1.1. Tierra de tensión alterna (AC) 27

3.1.2. Tierra de tensión continua (DC) 27

3.1.3. Tierra de mallas de cables (IN) 27

3.1.4. Tierra de chasis y seguridad (SG) 28

4. PRUEBAS FAT 29

1.9. Pruebas FAT de Hardware 30

4.1.1. Inspección Física del Montaje y Ensamblado de los Armarios de Control30

4.1.2. Montaje de Elementos 30

4.1.3. Distribución de Tarjetas en Bastidores 30

4.1.4. Verificación del Cableado 30

4.1.5. Verificación de Fuentes de Alimentación 31

1.10. Pruebas FAT de Software 32

4.1.6. Revisión Cuantitativa 32

4.1.7. Revisión Cualitativa/Funcional 32




1. ALCANCE Y DISEÑO DE UN SISTEMA DE CONTROL DISTRIBUIDO

Toda especificación técnica así como la ejecución de la solución de control asociada a la misma debe de basar su contenido en una serie de criterios que permitan a los profesionales implicados en el estudio y ejecución de la misma conocer o en su defecto definir:

- El objetivo o uso final

- El alcance contable de materiales implicados

- La filosofía a seguir

Cuando estos tres aspectos se aplican a un Sistema de Control Distribuido el resultado es a groso modo similar a lo presentado a continuación.




1.1. Objetivo

Desde el punto de vista del usuario final y/o la ingeniería, el resultado de su especificación técnica deberá de indicar cual es el objetivo que se persigue, es decir deberá de informarse a grandes rasgos sobre la naturaleza del proyecto y de la solución de control deseada para el mismo.

También es aconsejable, cuando los requisitos de confidencialidad lo permitan, informar sobre:

- El nombre del proyecto

- Los datos del usuario final

- La ubicación de la instalación

- Los datos de la ingeniería implicada

Esta tipo de información permiten al lector de la misma, suministrador y/o fabricante, definir un escenario global y realizar una primera acotación en el amplio campo de las soluciones de control que existen en el mercado.




1.2. Elementos Contables

Para que una especificación técnica y su posterior solución de control puedan iniciar fase de diseño y ejecución, es necesario que el usuario final y/o la ingeniería establezcan unos limites o criterios contables que permitan acotar el alcance de materiales hardware así como el alcance del desarrollo software implicados objeto de suministro.

1.1.1. Tarjetas de Entradas y Salidas.

Dado que por definición un Sistema de Control Distribuido está destinado al control y supervisión de un proceso (con un nº de variables físicas significativas), es importante que la especificación técnica del mismo informe sobre el nº de señales implicadas.

De cara a posteriores tareas de diseño hardware, el alcance de señales deberá de indicarse por tipo, distinguiendo entre:

- Señales Analógicas de Entrada

- Señales Analógicas de Salida

- Señales Digitales de Entrada

- Señales Digitales de Salida

Así mismo para cada uno de estos tipos, es conveniente informar sobre:

- La naturaleza física:

señales cableadas

señales asociadas a un bus de campo.

- La naturaleza eléctrica:

4-20 mA

contactos libres de potencial

señales procedentes de detectores inductivos

señales alimentadas por el Sistema de Control Distribuido

señales alimentadas por circuito externo

- La seguridad:

señales procedentes de zona segura

señales con tratamiento de seguridad intrínseca.

Este información de detalle es necesaria porque no existen tarjetas de entradas y salidas universales desde el punto de vista eléctrico, en todas las ocasiones el trabajo del fabricante y/o suministrador pasa por calcular en función del número de señales implicadas así como de su naturaleza, el tipo de elementos hardware más adecuados para el proyecto así como las unidades necesarias de cada uno de ellos.




1.1.2. Controladores

No es habitual ni aconsejable que el usuario final y/o la ingeniería especifiquen el número de controladores que requiere su solución de control ya que este aspecto es evaluado por el suministrador y/o fabricante en función del nº de señales implicadas, el grado de complejidad de la lógica de control asociada y la capacidad de cálculo de la CPU.

1.1.3. Consolas

Los requisitos definidos por el usuario final en relación con la interfase hombre / sistema de control, permitirán a la ingeniería y posteriormente al suministrador y/o fabricante establecer de manera sencilla el número de consolas implicadas en tareas de operación. También es evidente para todas las partes implicadas aceptar la conveniencia de la existencia a mayores de una estación de ingeniería destinada a tareas de configuración de la solución de control.

Deberá de ser objeto estudio la conveniencia de estaciones dedicas a tareas concretas tipo: gestión de la información HART procedente de los instrumentos de campo, configuración y gestión de aplicaciones de control avanzado, configuración y gestión de alarmas, simuladores de proceso, exportación de datos, etc.

En este caso es importante que el usuario final y /o la ingeniería especifiquen correctamente el objetivo desde el punto de vista de gestión de la información deseado con objeto de que el suministrador y/o fabricante tenga capacidad para definir el alcance más adecuado en relación con el número final de consolas implicadas y la funcionalidad de cada una de ellas.

Desde el punto de vista técnico o de diseño, es necesario indicar el formato de las estaciones, es decir si se trata de un PC convencional basado en tecnología Windows (actualmente XP) y compuesto por CPU, pantalla (1 o varias), teclado, ratón y altavoces o si por el contrario se trata de un PC de tipo industrial basado en tecnología Windows o en sistema operativo propietario del fabricante y compuesto por CPU, pantalla o monitor integrado en pupitre de control, teclado con opciones de teclas de función preprogramadas, ratón o similar.

1.1.4. Equipos de Terceros

En asociación con la información relativa a la naturaleza de las señales implicadas en un proyecto, es importante que todas las partes implicadas sean conscientes del número de equipos o unidades de proceso suministradas por terceros que deberán de integrarse en el Sistema de Control Distribuido.

En relación con este aspecto el usuario final y/o la ingeniería deberán de especificar el alcance y tipo de señales asociadas así como cuando aplique el tipo de protocolo a utilizar para la integración de las mismas.

También es importante, como tarea de diseño, indicar si la integración de equipos de terceros se realizará de manera segregada, es decir cada uno de los paquetes de información dispondrá de una tarjeta de comunicaciones dedicada, o si por el contrario




la solución se basará en los criterios y recomendaciones del suministrador y/o fabricante desde el punto de vista de agrupación de señales.

1.1.5. Reserva Equipada

Con objeto de definir el número final de elementos hardware implicados en la solución de control, el usuario final y/o ingeniería deberán de indicar el porcentaje en el que incrementar los elementos contables con objeto de dotar al Sistema de Control Distribuido de una reserva equipada.

1.1.6. Reserva Espacial

Desde el punto de vista de diseño, el usuario final y/o ingeniería deberán de indicar el porcentaje en el que incrementar el área constructiva dedicada a la ubicación e instalación de los elementos hardware del Sistema de Control Distribuido.

1.1.7. Módulos de Control e Interfase de Operación

Desde el punto de vista software, el usuario final y/o ingeniería deberán de indicar a partir del alcance de señales representado mediante un listado de Entradas / Salidas, cual es la lógica de control asociada a cada una de ellas así como información de proceso relevante para la configuración y operación (rangos, alarmas, etc). Con objeto de tipificar el trabajo a desarrollar, la ingeniería de instrumentación y control deberá de definir unos módulos de indicación y de control tipo.

De la misma manera deberá de especificarse mediante documento descriptivo o de bloques lógicos, las filosofías de control (secuencias, enclavamientos, lógicas, etc ...) asociadas al proceso.

Desde el punto de vista de interfase de operador será necesario especificar el alcance de pantallas de proceso a desarrollar así como el formato de las mismas:

- Aspecto general de las mismas

- Denominación

- Tipo de información a representar: equipos de proceso, lazos de control, monitorizaciones, alarmas, enclavamientos, etc

- Código de colores para líneas de proceso y dinamos (si aplica)

- Orden de navegación entre pantallas




1.3. Filosofía

Para que una especificación técnica y su posterior solución de control puedan iniciar fase de diseño y ejecución, es necesario que el usuario final y/o la ingeniería definan los criterios y filosofía a seguir en la solución de control con objeto de que el suministrador y/o fabricante puedan evaluar su impacto en el alcance final.

1.1.8. Segregación

Aspecto que informa sobre los criterios a seguir para el reparto en unidades hardware del número de señales, lógicas de control e información de operación asociados al proceso.

El conocimiento que el usuario final y/o la ingeniería poseen del proceso permitirá al suministrador y/o fabricante:

- Determinar el número correcto de controladores así como que parte de la planta o proceso gestionarán cada uno de ellos.

- Asignar a los diferentes elementos contables del hardware que señales procedentes del proceso gestionarán cada uno de ellos.

Los criterios para definir dicha segregación pueden ser del tipo: orden secuencial del proceso, ubicación física de las unidades de proceso, lógicas de cálculo y control, etc.

1.1.9. Redundancia

Aspecto que informa sobre los criterios a seguir para definir que elementos hardware deberán de ser suministrados e instalados en modo redundante.

Los criterios de redundancia afectan a aspectos de diseño y suministro de materiales del tipo:

- Alimentaciones: deberá de indicarse si las alimentaciones asociadas al sistema de control así como a la instrumentación de campo deberán de ser redundantes.

- Controladores

- Elementos de Entradas y Salidas: en este caso es importante especificar si este tipo de elementos hardware serán en su totalidad redundantes o si por el contrario aplicará únicamente por ejemplo a aquellas unidades destinas al control del proceso y/o lógicas de seguridad.

- Comunicaciones

1.1.10. Seguridad y Protecciones

Aspecto que informa sobre los criterios en relación con la certificación que deberán de cumplir los elementos hardware o el conjunto de la instalación con objeto de cumplir normativas de seguridad o protección tipo ATEX, SIL, etc.




1.1.11. Integración de la Información

Aspecto que informa sobre los criterios a seguir para definir el uso de protocolos de comunicaciones para integración de la información, tipo:

- Uso de Instrumentación inteligente: protocolo HART

- Uso de buses de campo para gestión de señales asociadas a entras y salidas del proceso

- Uso de buses de campo para integración de la información procedente de equipos de terceros

Igualmente será necesario especificar cualquier tipo de integración del Sistema de Control Distribuido con la red LAN de la planta, de cara a la gestión global de la información de proceso.




2. CALCULOS ASOCIADOS

Establecidos los criterios que definirán el tipo y alcance de un Sistema de Control Distribuido, las etapas posteriores de diseño y ejecución del mismo están sujetas a una serie de cálculos técnicos de obligado cumplimiento, cuya funcionalidad se describe a continuación.

Es importante tener presente que cuanto mayor rigor se aplique a la ejecución de dichos cálculos, más correcta será la solución de control desde el punto de vista técnico.




1.4. Cálculos de Capacidad Hardware

A partir de la información relativa al número de señales implicadas en un proyecto, la naturaleza de las mismas y las funciones de lógica y cálculo asociadas, la ingeniería, el suministrador o el fabricante del Sistema de Control Distribuido estarán en condiciones de realizar los cálculos pertinentes con objeto de fijar el número exacto de elementos hardware implicados.

2.1.1. Tarjetas de Entradas y Salidas

Para un mismo tipo de señales (señales tipo SA), sujeto a un modelo concreto de tarjeta de entradas o salidas (tarjeta tipo TA), un primera etapa para el cálculo del número de unidades necesarias es el resultado de aplicar la siguiente expresión:

AjetasTipoTCanalesTarN

adaservaEquipPorcentajeoSASeñalesTipNpoTATarjetasTiN

º100

Reºº

∗=

El resultado obtenido tendrá que ser revisado, en muchos casos al alta, de acuerdo con el criterio de Segregación anteriormente expuesto, es decir en función de la agrupación de señales que deba de realizarse por tarjeta.

2.1.2. Tarjetas de Comunicaciones

Determinar el número de unidades necesarias integrar de manera masiva información de proceso mediante el uso de uno o varios protocolos de comunicación no siempre es una tarea trivial.

En la mayoría de las soluciones de control el suministrador y/o fabricante deberá de realizar un estudio del alcance y tipo de señales o dispositivos a integrar. El número final de tarjetas de comunicaciones dependerá de las limitaciones impuestas por el propio protocolo así como por la capacidad en puertos de comunicaciones de la tarjeta elegida.

2.1.3. Controladores

Tal como habíamos indicado anteriormente, es el suministrador y/o fabricante quién dispone de criterios suficientes para determinar cual es el número de controladores que requiere un proyecto concreto.

Con objeto de que pueda realizar correctamente su evaluación, es necesario que el usuario final o la ingeniería informen sobre los criterios de segregación de la información que deberán de tenerse en cuenta, es decir el alcance final de controladores dependerá no solamente de la capacidad de cálculo (nº máximo de elementos lógicos o de control programados) y la capacidad de gestión (nº máximo de señales asignadas), sino también de los criterios seguidos para agrupar la información del proceso (orden secuencial del proceso, ubicación física de las unidades de proceso, lógicas de cálculo y control)




1.5. Cálculos Eléctricos

A partir de la información relativa al alcance hardware implicado en un proyecto, el suministrador o el fabricante del Sistema de Control Distribuido estarán en condiciones de realizar los cálculos de consumos eléctricos con objeto de diseñar de manera correcta la distribución eléctrica necesaria en la solución de control.

Varios son los objetivos que se persiguen técnicamente:

- Dimensionar correctamente el número de fuentes del Sistema de Control Distribuido necesarias para alimentar a los diferentes elementos hardware y dispositivos auxiliares asociados.

- Dimensionar correctamente el número de fuentes necesarias para alimentar a los elementos de campo.

- Dimensionar correctamente el cuadro de distribución eléctrica asociado a los diferentes consumidores del Sistema de Control Distribuido

- Dimensionar correctamente las UPS o SAI (Sistemas de Alimentación ininterrumpida) asociados al proyecto y a la solución de control.

- Dimensionar correctamente los dispositivos asociados a la refrigeración del hardware del Sistema de Control Distribuido así como de los habitáculos en donde se encuentra ubicado el mismo.

Para alcanzar cada uno de ellos será necesario:

(1) Establecer los elementos hardware implicados en el proyecto así como las unidades de cada uno de ellos

- Tarjetas

- Controladores

- Bastidores

- Dispositivos auxiliares: Aisladores de Seguridad Intrínseca, Separadores Galvánicos, Convertidores de Señal, Relés, etc ...

- Estaciones

- Impresoras

- Dispositivos de red: Bridge, Router, Gateway, Firewall, Servidor, Hub, Switch, etc …

- Iluminación y Sistema de Refrigeración

(2) Determinar para cada elemento hardware:

- El tipo de alimentación que necesitan, bajo dos aspectos:

Continua o alterna

De distribución general de planta o procedente de UPS

- El consumo en régimen nominal del cada elemento hardware así como cuando aplique el de los elementos de campo conectados al mismo




- La disipación de calor que generan

2.1.4. Dimensionamiento de Fuentes de Alimentación

Paso 1:

Establecer el tipo de fuentes que se emplearán para alimentar tanto al hardware como a los elementos de campo.

Ejemplo:

Las fuentes del sistema para alimentar al hardware son del tipo:

Tensión de entrada: 24 Vcc

Tensión de salida: 12 Vcc

Amperios suministrados: 4,5

Las fuentes para alimentar al los elementos de campo son del tipo:

Tensión de entrada: 220 Vca

Tensión de salida: 24 Vcc

Amperios suministrados: 20

Paso 2:

Establecer la relación eléctrica entre los distintos tipos de fuentes implicadas

Ejemplo:

Las fuentes del sistema se alimentarán a partir de las fuentes de alimentación de los elementos de campo. Consecuentemente no existirán fuentes dedicadas.

Paso 3:

Establecer el tipo de alimentaciones que existirán en el proyecto:

Ejemplo:

220 Vca, Alimentación procedente UPS

220 Vca, Alimentación General de Planta

Paso 4:

Establecer la relación eléctrica entre los distintos tipos de alimentaciones y los elementos hardware implicados

Ejemplo:

Tarjetas <-> Fuente de 24 Vcc / 12 Vcc / 4,5 A

Controladores <-> Fuente de 24 Vcc / 12 Vcc / 4,5 A

Dispositivos auxiliares <-> Fuente de 220 Vca / 24 Vcc / 20 A

Elementos de campo <-> Fuente de 220 Vca / 24 Vcc / 20 A

Fuentes del Sistema <-> Línea de 220 Vca procedente de UPS




Fuentes de Campo <-> Línea de 220 Vca procedente de UPS

Estaciones <-> Línea de 220 Vca procedente de UPS

Impresoras <-> Línea de 220 Vca procedente de UPS

Dispositivos de red <-> Línea de 220 Vca procedente de UPS

Iluminación y Sistema de Refrigeración <-> Línea de 220 Vca procedente de Alimentación General de Planta

Paso 5:

Establecer los consumos

Ejemplo:




Hardware del Sistema Elementos de Campo

Ud Tipo de Elemento Hardware Consumo unitario Consumo Total Consumo unitario Consumo Total

mA 12 Vcc mA 24 Vcc

I/O Cards

Analog In 4-20 mA, 8-channel, HART 150 0 300 0

Analog In 1-5VDC, 8-channel 150 0 100 0

Analog Out 4-20 mA, 8-channel, HART 150 0 300 0

DI, 8-Channel, 24 VDC, Isolated 100 0 0 0

DI, 8-Channel, 24 VDC, Dry Contact 100 0 40 0

DI, 8-Channel, 120 VAC, Isolated 100 0 0 0

DI, 8-Channel, 120 VAC, Dry Contact 100 0 0 0

DI, 8-Channel, 230 VAC, Isolated 100 0 0 0

DI, 8-Channel, 230 VAC, Dry Contact 100 0 0 0

2 DI, 32-Channel, 24 VDC, Dry Contact 75 150 150 300

DO, 8 Channel, 120/230 VAC, Isolated 150 0 0 0

DO, 8 Channel, 120/230 VAC, High Side 150 0 0 0

DO, 8 Channel, 24 VDC, Isolated 150 0 0 0

DO, 8 Channel, 24 VDC, High Side 150 0 6.000 0

1 DO, 32-Channel, 24 VDC, High Side 150 150 3.200 3.200

AS-Interface Card 300 0 0 0

Foundation Fieldbus H1 Card 600 0 0 0

Multifunction Card 250 0 40 0

Profibus DP Card 600 0 0 0

RTD, ohms Card 160 0 0 0






mA 12 Vcc mA 24 Vcc

Sequence of Events Card 75 0 75 0

Serial Card 2 Ports RS232/RS485 300 0 0 0

Thermocouple, mV Card 350 0 0 0

11 Series 2 AI, 4-20 mA with HART, Simplex 150 1.650 300 3.300

3 Series 2 AI, 4-20 mA with HART, Redundant 500 1.500 400 1.200

Series 2 AO, 4-20 mA with HART, Simplex 150 0 300 0

3 Series 2 AO, 4-20 mA with HART, Redundant 300 900 400 1.200

Series 2 DI, 8 ch, 24Vdc, Dry Contact, Simplex 150 0 40 0

Series 2 DI, 8 ch, 24Vdc, Dry Contact, Redundant 300 0 40 0

Series 2 DO, 8 ch, 24Vdc, High side, Simplex 150 0 3.000 0

1 Series 2 DO, 8 ch, 24Vdc, High side, Redundant 300 300 3.000 3.000

Series 2, H1, Simplex 300 0 0 0

Series 2, H1, Redundant 600 0 0 0

Series 2 Serial, Simplex 300 0 0 0

Series 2 Serial, Redundant 600 0 0 0

Power Supply

2 24/12 Vdc System Power Supply 0 0 5.400 10.800

2 Field System Power Supply 0 0 0 0

Controller

M3/M5 Controller 750 0 0 0

2 MD Controller 1.400 2.800 0 0

Aisladores

5 Grupos de Alimentación, KFD2-EB.R2A.RPI 0 0 2.000 10.000






mA 12 Vcc mA 24 Vcc

TOTAL 7.450,00 33.000,00

TOTAL NECESARIOS 7,45 33

Sistema Circuitos de campo

Tipo de Fuente Amperios por Fuente Total Fuentes 12 Vcc Amperios por Fuente Total Fuentes 24 Vcc

TOTAL PROYECTO SIN REDUNDANCIA 4,5 2 20 1,65

TOTAL AMPERIOS DISPONIBLES SIN REDUNDNACIA 9 40

TOTAL PROYECTO CON REDUNDANCIA FUENTES (N+1) 3 3




2.1.5. Dimensionamiento de Líneas de Alimentación

Paso 1:

Establecer que consumidores o dispositivos necesitarán alimentación procedente de UPS y cuales de alimentación general de planta

Ejemplo:

Fuentes <-> Línea de 220 Vca procedente de UPS

Estaciones <-> Línea de 220 Vca procedente de UPS

Impresoras <-> Línea de 220 Vca procedente de UPS

Dispositivos de red <-> Línea de 220 Vca procedente de UPS

Iluminación y Sistema de Refrigeración <-> Línea de 220 Vca procedente de Alimentación General de Planta

Paso 2:

Establecer los consumos

Ejemplo:




Absorción Corriente Ud Absorción Corriente Total Consumo Total Margen de Seguridad Consumo Total Ud Tipo de Elemento Hardware

Amperios Amperios Watios % KVA

Línea 01: Alimentación de UPS PHOENIX CONTACT QUINT 24Vdc/2,5A 0,47 0 0 0,00% 0

PHOENIX CONTACT QUINT 24Vdc/5A 0,84 0 0 0,00% 0


2 PHOENIX CONTACT QUINT 24Vdc/20A 2,3 4,6 1.269,60 0,00% 1,55


VENTILADOR CON TERMOSTATO 0,12 0 0 0,00% 0

LUMINARIA NA NA 0 0,00% 0

TOMA DE CORRIENTE EXTERNA 6 0 0 0,00% 0

TOTAL 4,6 1.269,60 1,55

Línea 02: Alimentación General de Planta PHOENIX CONTACT QUINT 24Vdc/2,5A 0,47 0 0 0,00% 0





3 VENTILADOR CON TERMOSTATO 0,12 0,36 99,36 0,00% 0,12

3 LUMINARIA NA NA 216 0,00% 0,26

1 TOMA DE CORRIENTE EXTERNA 6 6 1.656,00 0,00% 2,02

TOTAL 6,36 1.971,36 2,4




2.1.6. Disipación de Calor

Paso 1:

Establecer los elementos hardware susceptibles de disipar calor

Ejemplo:

Tarjetas

Controladores

Dispositivos auxiliares

Fuentes

Paso 2:

Establecer la disipación total de calor con objeto de dimensionar el sistema de refrigeración asociado al habitáculo del hardware.

Ejemplo:




Sistema

Ud Tipo de Elemento Hardware Disipación unitario Disipación Total

Watios

I/O Cards Analog In 4-20 mA, 8-channel, HART 10,1 0

Analog In 1-5VDC, 8-channel 10,1 0

Analog Out 4-20 mA, 8-channel, HART 11,9 0

DI, 8-Channel, 24 VDC, Isolated 3,6 0

DI, 8-Channel, 24 VDC, Dry Contact 2,9 0

DI, 8-Channel, 120 VAC, Isolated 3,4 0

DI, 8-Channel, 120 VAC, Dry Contact 3,4 0

DI, 8-Channel, 230 VAC, Isolated 3,6 0

DI, 8-Channel, 230 VAC, Dry Contact 3,6 0

2 DI, 32-Channel, 24 VDC, Dry Contact 5,7 11,4

DO, 8 Channel, 120/230 VAC, Isolated 6,1 0

DO, 8 Channel, 120/230 VAC, High Side 6,1 0

DO, 8 Channel, 24 VDC, Isolated 4,9 0

DO, 8 Channel, 24 VDC, High Side 28,7 0

1 DO, 32-Channel, 24 VDC, High Side 30 30

AS-Interface Card 9,6 0

Foundation Fieldbus H1 Card 10,2 0

Multifunction Card 8,2 0

Profibus DP Card 10,1 0

RTD, ohms Card 2,7 0

Sequence of Events Card 3,5 0




Sistema


Serial Card 2 Ports RS232/RS485 5,1 0

Thermocouple, mV Card 5,9 0

11 Series 2 AI, 4-20 mA with HART, Simplex 8,4 92,4

3 Series 2 AI, 4-20 mA with HART, Redundant 18,2 54,6

Series 2 AO, 4-20 mA with HART, Simplex 10,2 0

3 Series 2 AO, 4-20 mA with HART, Redundant 20,4 61,2

Series 2 DI, 8 ch, 24Vdc, Dry Contact, Simplex 3,7 0

Series 2 DI, 8 ch, 24Vdc, Dry Contact, Redundant 7,4 0

Series 2 DO, 8 ch, 24Vdc, High side, Simplex 3,7 0

1 Series 2 DO, 8 ch, 24Vdc, High side, Redundant 7,4 7,4

Series 2, H1, Simplex 6,1 0

Series 2, H1, Redundant 12,2 0

Series 2 Serial, Simplex 5,1 0

Series 2 Serial, Redundant 10,2 0

Power Supply

2 24/12 Vdc System Power Supply 1,5 3

2 Field System Power Supply 22 44

Controller

M3/M5 Controller 10,8 0

2 MD Controller 14 28

Aisladores

5 Grupos de Alimentación, KFD2-EB.R2A.RPI 0 0




3. CONSTRUCCIÓN HARDWARE

Establecidos los criterios que definirán el tipo y alcance de un Sistema de Control Distribuido así como los cálculos técnicos asociados, la siguiente de la etapas consiste en la construcción física de los diseñado, es decir en el montaje, ensamblado y conexionado de los diferentes elementos hardware implicados en la solución de control. Dichas tareas deberán de basarse en los denominados planos constructivos y de interconexión, los cuales como mínimo deberán de informar sobre:

- Alcance y tipo de materiales utilizados

- Habitáculo en donde se ubicarán los diferentes elementos hardware

- Aspecto constructivo que presentará el conjunto hardware una vez montados y ensamblados los diferentes elementos

- Conexionado físico y eléctrico entre los diferentes elementos hardware

- Conexionado físico y eléctrico entre los elementos hardware y los dispositivos de campo

- La red de comunicaciones y el conexionado entre los elementos que la forman

- El conexionado del conjunto hardware con la red de tierras del proyecto

El formato y contenido final de dichos planos depende de la solución de control elegida y del suministrador y/o fabricante de la misma, el objetivo que se persigue deberá de ser al menos el indicado anteriormente.




1.6. Armarios de Control

El habitáculo destinado al montaje y ensamblado de los elementos hardware recibe el nombre de armario de control. Las dimensiones y características constructivas del mismo dependen de los requisitos especificados por el usuario final o la ingeniería así como por la aconsejado por el suministrador y/o fabricante de la solución de control.

Normalmente y con objeto de simplificar diseños y costes, los armarios de control siguen unos estándares en lo relativo a dimensiones y características constructivas. La tabla adjunta detalla a modo de ejemplo la información relativa a un armario de control:

Item Referencia / Descripción Fabricante Rittal Bastidor 1200 / TS 8808.521 Dimensiones (con zócalo de 100 mm) 1200 x 800 x 2100 (mm) Protección IP65 Color RAL 7032 Entrada de cables Por parte inferior mediante panel galvanizado Techo Fijo con anclajes (según DIN 580) Accesos Frontal y Posterior Puertas Doble puerta en frontal / Doble puerta en posterior Apertura de puertas en bisagras 130 º Ventilación por acceso 1 ventilador (zona superior) y 1 filtro (zona

inferior) Referencia del ventilador SK 3323.107 Referencia del filtro SK 3323.207 Placas de Montaje 2 (en frontal y posterior) galvanizadas Accesorios Termostato digital externo y Luminaria Tabla. 3-1-1 Detalle Armario de Control

El número de armarios implicados, las dimensiones y accesos de los mismos dependerá no solamente del alcance de materiales a instalar sino de la disponibilidad de espacio en la sala donde finalmente serán ubicados así como de los requisitos especificados en relación con la interconexión de señales entre campo y los elementos hardware implicados.




1.7. Interconexionado de Señales

La elección de los armarios de control no solamente condicionará el modo en que deberá de ser montado y ensamblado el material, aspecto que depende en la mayor parte de los casos del suministrador y/o fabricante, sino también como deberá de realizarse el diseño relativo al interconexionado de señales entre campo y tarjetas, aspecto en donde la ingeniería de instrumentación del proyecto es condicionante.

Consecuentemente el usuario final o la ingeniería, deberán de informar sobre:

- El agrupamiento en multicables de las señales procedentes de campo

- Los criterios de ordenación de las señales dentro de un multicable

- Los criterios que deberán de seguirse para ordenar dichas señales dentro del armario

- Los criterios constructivos y tipo de materiales auxiliares (bornas) que deberán de utilizarse para el conexionado de señales a tarjetas

- El volumen de reserva equipada a nivel de señales que deberá de aplicarse

- La reserva espacial que deberá de existir dentro del armario de cara a al montaje futuro de nuevos elementos hardware

De manera general y en relación con la interconexión de señales podemos hablar de dos tipos de soluciones:

(1) Conexión directa: los cables procedentes de campo llegan directamente a bornas de tarjetas sin que exista un bornero de interconexión intermedio. Esta solución sencilla en costes y materiales, impide la aplicación de cualquier criterio de agrupación de señales en tarjetas.

(2) Marshalling: los cables procedentes de campo llegan inicialmente a un conjunto de bornas (bornero) donde son ordenados y etiquetados de acuerdo con un criterio normalmente fijado por el usuario final y/o la ingeniería (ordenación por multicable, por servicio, por funcionalidad, etc). Posteriormente desde el bornero existe un segundo cableado (interno al armario) hacia las bornas de las tarjetas hardware con un segundo criterio normalmente fijado por el suministrador y/o fabricante.




1.8. Sistema de Tierras

Desde el punto de vista eléctrico, todo Sistema de Control Distribuido deberá de estar referenciado a tierra. Los criterios a seguir en relación con este aspecto serán fijados por el suministrador y/o fabricante de la solución de control.

De manera general podemos indicar que dentro del conjunto hardware cuatro son los posibles usuarios de l sistema de tierras:

- Las tensiones de corriente alterna (AC)

- Las tensiones de corriente continua (DC)

- El chasis del armario de control junto con la seguridad del usuario final del mismo (SG)

- Las señales procedentes de los instrumentos de campo (IN)

Los embarrados de tierra facilitan el conexionado a tierra de los elementos del sistema y proporcionan un punto de conexión único para los distintos tipos de tierras existentes en el sistema. Estos embarrados de tierra se implementan mediante pletinas de cobre aisladas.

La ejecución de las conexiones así como las características de la misma constituyen cuestiones sumamente importante para conseguir una correcta conexión a tierra evitando perturbaciones eléctricas que podrían afectar, a la integridad del conjunto, a la correcta funcionalidad de los equipos, a la calidad de la señales y en definitiva al control del proceso.

El modo en que los distintos embarrados se conectan entre sí así como su conexión al sistema general de tierras existente en el proyecto y en definitiva en la planta depende de la especificación técnica del fabricante. Igualmente deberá de ser el fabricante el fije el mínimo valor en Ohmios de la impedancia mínima que deberá de existir en el punto de unión de los diferentes embarrados (pica general de planta)

3.1.1. Tierra de tensión alterna (AC)

Esta conexión garantiza la conexión a tierra de los dispositivos alimentados con tensión alterna que conforman el sistema de control.

Cada armario de control deberá de contar al menos con un embarrado dedicado a este servicio.

3.1.2. Tierra de tensión continua (DC)

Esta conexión garantiza la referencia a tierra de las fuentes de alimentación de tensión continua y de las señales analógicas del sistema de control.

Cada armario de control deberá de contar al menos con un embarrado dedicado a este servicio, constituyendo el denominado común de alimentación de tensión continua.

3.1.3. Tierra de mallas de cables (IN)

Esta conexión garantiza la referencia a tierra de las mallas de los cables y multicables procedentes de los instrumentos de campo.




Las pletinas dedicas al conexionado de este tipo de tierras dependerán de la ingeniería de detalle de instrumentación, es decir del volumen de mallas a conectar en las mismas, ya que en muchas ocasiones el tipo de multicable (asociado al tipo de señal que conecta) determinará el número de mallas asociadas:

Opción 1: 1 única malla por multicable

Opción 2: 1 malla por señal del multicable

Las mallas individuales por señal se conectarán normalmente a una pletina paralela al bornero de señales asociado y dicha pletina se conectará a tierra a través de un embarrado general dentro del armario.

3.1.4. Tierra de chasis y seguridad (SG)

La tierra de la cabina proporciona protección a los equipos y persona contra las descargas eléctricas accidentales. También mantiene un camino de descarga directa a tierra para corrientes generadas debido a cualquier interferencia electromagnética a que puedan estar sometidos los componentes de la cabina.

La tierra de la cabina se conecta directamente a los elementos previstos en la misma. Normalmente las cabinas cuentas con tornillos de conexión a tierra en cada una de las partes que constituyen la misma. Estos elementos se unirán todos entre sí y desde uno de ellos se realiza la conexión a la tierra de la cabina.




4. PRUEBAS FAT

Finalizada la construcción, ensamblado y conexionado de los diferentes elementos hardware así como el desarrollo software del proyecto, se impone como siguiente paso la inspección y aceptación por parte del usuario final y/o la ingeniería del resultado obtenido.

Este paso con el que se cierra la ingeniería asociada al diseño hardware y software de un Sistema de Control Distribuido recibe el nombre de pruebas FAT (Factory Aceptan Tets), las cuales son en si mismas un protocolo de pasos o tests similares a los presentados a continuación.




1.9. Pruebas FAT de Hardware

4.1.1. Inspección Física del Montaje y Ensamblado de los Armarios de Control

Se comprobará visualmente que la disposición física de los elementos en las cabinas se corresponde con lo indicado en los planos constructivos. Asimismo, se comprobará las dimensiones del armario.

Las inspecciones que se realizarán son:

- Inspección visual de las cabinas.

- Inspección visual del estado de la chapa y pintura.

- Comprobación del color de las cabinas.

- Disposición de embarrados y latiguillos de tierra.

- Comprobación de la accesibilidad a todos los elementos de las cabinas.

- Comprobación de la identificación de cabinas y elementos montados.

4.1.2. Montaje de Elementos

Se comprobará visualmente que la disposición de los magnetotérmicos y diferenciales de protección, ventiladores y filtro, termostato, fuentes de alimentación, bastidores para equipos, bornas y canaletas, se corresponde con lo indicado en los planos constructivos.

4.1.3. Distribución de Tarjetas en Bastidores

Se comprobará visualmente que la distribución de las fuentes de alimentación, controladores y tarjetas se corresponde en alcance, montaje y ubicación con lo indicado en los planos constructivos.

4.1.4. Verificación del Cableado

Se comprobará visualmente que la disposición física del cableado, así como el etiquetado de los cables, borneros y bornas se corresponden con lo indicado en los planos de interconexión:

- Plano de armario disposición elementos en armario.

- Planos de alimentaciones eléctricas.

- Esquemas de cableado tarjetas de señales analógicas.

- Esquemas de cableado tarjetas de señales discretas.

Las inspecciones y pruebas que se realizarán son:

- Disposición y marcado de cables y elementos.

- Continuidad entre la estructura de cada cabina (tornillos roscados) y su barra de tierra.




- Continuidad entre las partes pivotantes (puertas) de cada cabina y su barra de tierra.

- Continuidad entre la placa de montaje de cada cabina (tornillos roscados) y su barra de tierra.

- Prueba de alimentaciones y comprobación de sus tierras y referencias eléctricas.

- Timbrado del 100% del cableado.

4.1.5. Verificación de Fuentes de Alimentación

Se comprobará que sus conexiones se corresponden a lo indicado en los planos constructivos. Se realizará una prueba de funcionamiento en vacío (sin carga), midiendo el valor de la tensión.




1.10. Pruebas FAT de Software

4.1.6. Revisión Cuantitativa

Se verificará desde el punto de vista cuantitativo el cumplimiento de la especificación definida por el cliente y/o la ingeniería. Se seguirán los puntos que se recogen a continuación, siempre que sean de aplicación al proyecto .

- Señales de entrada /salida

- Lazos analógicos.

- Módulos discretos.

- Gráficos/Sinópticos.

- Tendencias

- Informes

- Secuencias.

4.1.7. Revisión Cualitativa/Funcional

Se comprobará que el software implementado en el Sistema de Control Distribuido funciona de acuerdo con las especificaciones asociadas al mismo. Se realizarán las verificaciones que se detallan a continuación siempre que sean de aplicación al proyecto.

Comprobación de configuración de bloques de entrada/salida

Se verificará para el porcentaje de señales acordados en la especificación los siguientes puntos, si son de aplicación:

- Tag

- Descripción

- Rango

- Unidades

- Filtros de señal

- Alarmas

- Pares de mensaje ( señales discretas)

- Conexión de las entradas y salidas a módulos de control.

Comprobación de configuración de bloques de control analógico





- Tag

- Descripción

- Variable de proceso

- Consigna local y/o remota.

- Otras variables que intervienen en el lazo

- Modo de operación del bloque

- Alarmas

- Parámetros de control.

- Lógica de control

- Enclavamientos

- Cálculos

- Conexión de la salidas a otros módulos

Comprobación de configuración de bloques de control discreto y/u otros bloques de control.


- Tag

- Descripción

- Tipo de bloque o módulo

- Variables de entrada al módulo de control discreto

- Modo de operación

- Unidades, y pares de mensajes

- Enclavamientos

- Cálculos lógico y/o matemáticos

- Alarmas

- Conexión de las salidas a otros módulos

Comprobación de configuración de secuencias


- Condiciones de inicio y fin de secuencia

- Condiciones de la secuencia

- Instrucciones de la secuencia




- Acciones de la secuencia

- Interfase con el operador

- Seguridad de la secuencia y sus transiciones (hold, abortar,..)

- Conexión de la secuencia a otros bloques de control.

Comprobación de gráficos

Se verificará para el porcentaje acordado en la especificación los siguientes puntos, siempre que sea de aplicación en el proyecto:

- Titulo del gráfico

- Elementos fijos dentro de los gráficos

- Código de colores utilizado

- Símbolos empleados

- Cambios de estado dentro de los elementos del gráfico.

- Selección de los elementos dentro del gráfico, carátulas

- Conexión a otros gráficos.

Comprobación de tendencias

Se verificará para el porcentaje acordado en la especificación los siguientes puntos, si son de aplicación:

- Titulo de las tendencias

- Variables asignadas a cada grupo de visualización

- Frecuencia de archivo de cada variable

- Duración de la tendencia

- Colores asignados a cada variable

Comprobación de informes


- Título del informe

- Motivo de generación del informe (horas, alarmas...)

- Contenido del informe

- Salida del informe por impresora, archivo..

Comprobación de programación





- Procedimiento

- Unidades

- Fases

- Alias

- Parámetros

- Mensajes de operador

- Recetas

- Gráficos específicos de batch

- Programación de los diferentes estados: hold, restart, running, stopping.

- Conexión de la programación a los módulos de control

Revisión de Conexión a Terceros


- Parámetros de comunicación: velocidad, puertos,...

- Protocolo

- Direcciones

- Tags

- Descripciones

- Tipo de señal



ABRIL 2006 8B1 INGENIERIA DE SISTEMAS DE CONTROL

Sección Española

INGENIERIADE

SISTEMAS DE CONTROLMarisa Sanzo

ABRIL 2006 8B1 INGENIERIA DESISTEMAS DE CONTROL

Sección Española

INTRODUCCIÓN

Comprendidos y asimilados los conceptos del módulo 81A relativos a Sistemas de Control Distribuido (SCD), la tarea previa a la ejecución de un proyecto es:

Diseñar y especificar técnicamenteel





Sección Española

INTRODUCCIÓN

Paso de obligado cumplimiento para:•El usuario final: responsable de la definición de los requisitos de su proyecto•La ingeniería: responsable de la especificación técnica y de la supervisión del proyecto•El suministrador o fabricante: responsable de ofrecer una solución de control según lo especificado, apoyando al usuario final y a la ingeniería en toda la fase de ejecución


Sección Española

ALCANCE Y DISEÑO

Toda especificación técnica y la solución de control asociada debe de basar su contenido en una serie de criterios:

– El objetivo o uso final– El alcance contable de materiales implicados– La filosofía a seguir




Sección Española

ALCANCE Y DISEÑO

2.1. ObjetivoInformar sobre la naturaleza del proyecto y de la solución de control deseada para el mismo.Así como sobre:

– El nombre del proyecto– Los datos del usuario final– La ubicación de la instalación– Los datos de la ingeniería implicada

Con objeto de definir un escenario global y realizar una primera acotación.


Sección Española

ALCANCE Y DISEÑO

2.2. Elementos ContablesEstablecer unos limites o criterios contables que permitan acotar el alcance de:

– materiales hardware– el desarrollo software – los servicios

Implicados objeto de suministro.




Sección Española

ALCANCE Y DISEÑO

Tarjetas de Entradas y SalidasLa especificación técnica deberá de informar sobre el nº de señales implicadas.Deberá de indicarse el tipo:

– Señales Analógicas de Entrada– Señales Analógicas de Salida– Señales Digitales de Entrada– Señales Digitales de Salida


Sección Española

ALCANCE Y DISEÑO

Tarjetas de Entradas y Salidas (continuación)Para cada uno de estos tipos se informará sobre la naturaleza física:

– señales cableadas– señales asociadas a un bus de campo

y la naturaleza eléctrica:– 4-20 mA– contactos libres de potencial – señales procedentes de detectores inductivos– señales alimentadas por el SCD– señales alimentadas por circuito externo




Sección Española

ALCANCE Y DISEÑO

Tarjetas de Entradas y Salidas (continuación)La seguridad:

– señales procedentes de zona segura– señales con tratamiento de seguridad intrínseca

Este información de detalle es necesaria porque no existen tarjetas universales Se calculará en función del número de señales implicadas y de su naturaleza el tipo y número de elementos hardware.


Sección Española

ALCANCE Y DISEÑO

ControladoresSe aconseja que este aspecto sea evaluado por el suministrador y/o fabricante en función del nº de señales implicadas, el grado de complejidad de la lógica de control asociada y la capacidad de cálculo de la CPU.




Sección Española

ALCANCE Y DISEÑO

ConsolasEs necesario especificar correctamente el objetivo en gestión de la información con objeto de que el suministrador y/o fabricante tenga capacidad para definir el alcance más adecuado en relación con el número final de consolas implicadas y la funcionalidad de cada una de ellas.


Sección Española

ALCANCE Y DISEÑO

Consolas (continuación)Deberá de estudiarse la conveniencia de estaciones dedicas a tareas concretas tipo: gestión de la información HART, configuración y gestión de aplicaciones de control avanzado, configuración y gestión de alarmas, simuladores de proceso, exportación de datos, etc.




Sección Española

ALCANCE Y DISEÑO

Consolas (continuación)Es necesario indicar el formato de las estaciones, •PC convencional basado en tecnología Windows (actualmente XP) y compuesto por CPU, pantalla (1 o varias), teclado, ratón y altavoces.•PC de tipo industrial basado en tecnología Windows o en sistema operativo propietario del fabricante y compuesto por CPU, pantalla o monitor integrado en pupitre de control, teclado con opciones de teclas de función, ratón o similar.


Sección Española

ALCANCE Y DISEÑO

Elementos de TercerosDeberá de especificar el alcance y tipo de señales de terceros y el tipo de protocolo a utilizar para la integración de las mismas.Como tarea de diseño: indicar si la integración de equipos de terceros se realizará de manera segregada, paquete de información tarjeta de comunicaciones dedicada.O si la solución se basará en criterios y recomendaciones del suministrador y/o fabricante desde el punto de vista de agrupación de señales.




Sección Española

ALCANCE Y DISEÑO

Reserva-EquipadaPorcentaje en el que incrementar los elementos contables-EspacialPorcentaje en el que incrementar el área constructiva dedicada a la ubicación e instalación de los elementos hardware


Sección Española

ALCANCE Y DISEÑO

Módulos de Control e Interfase de OperaciónDeberá de indicarse el alcance de señales representado la lógica de control asociada asícomo información de proceso relevante para la configuración y operación (rangos, alarmas, etc). Con objeto de tipificar el trabajo software a desarrollar.




Sección Española

ALCANCE Y DISEÑO

2.3. FilosofíaPara que una especificación técnica y su posterior solución de control puedan iniciar fase de diseño y ejecución, es necesario definir los criterios y filosofía a seguir en la solución de control con objeto de que el suministrador y/o fabricante puedan evaluar su impacto en el alcance final.


Sección Española

ALCANCE Y DISEÑO

SegregaciónCriterios para el reparto en unidades hardware del número de señales, lógicas de control e información de operación asociados al proceso.Tipos de criterios: orden secuencial del proceso, ubicación física de las unidades de proceso, lógicas de cálculo y control, etc




Sección Española

ALCANCE Y DISEÑO

RedundanciaCriterios a seguir para definir que elementos hardware deberán de ser suministrados e instalados en modo redundante.Afectan a aspectos de diseño y suministro de materiales del tipo:

AlimentacionesControladoresElementos de Entradas y SalidasComunicaciones


Sección Española

ALCANCE Y DISEÑO

Seguridad y ProteccionesCriterios en relación con la certificación que deberán de cumplir los elementos hardware o el conjunto de la instalación con objeto de cumplir normativas de seguridad o protección tipo ATEX, SIL, etc.




Sección Española

ALCANCE Y DISEÑO

Integración de la InformaciónCriterios a seguir para definir la integración de la información, tipo:

Uso de Instrumentación inteligente: protocolo HARTUso de buses de campo para gestión de señales asociadas a entras y salidas del procesoUso de buses de campo para integración de la información procedente de equipos de tercerosConexión del Sistema de Control Distribuido con la red LAN de la planta para gestión global de la información de proceso.


Sección Española

CALCULOS

Establecidos los criterios de diseño el siguiente paso es la ejecución de cálculos técnicos de obligado cumplimiento, cuya funcionalidad es clara.Es importante tener presente que cuanto mayor rigor se aplique a la ejecución de dichos cálculos, más correcta será la solución de control desde el punto de vista técnico.




Sección Española

CALCULOS

2.4. Cálculos de Capacidad HardwareA partir del número de señales implicadas en un proyecto, la naturaleza de las mismas y las funciones de lógica y cálculo asociadas, estaremos en condiciones de realizar los cálculos pertinentes con objeto de fijar el número exacto de elementos hardware implicados.


Sección Española

CALCULOS

Tarjetas de Entradas y Salidas

El resultado obtenido tendrá que ser revisado de acuerdo con el criterio de Segregación es decir en función de la agrupación de señales que deba de realizarse por tarjeta.

AjetasTipoTCanalesTarN

adaservaEquipPorcentajeoSASeñalesTipNpoTATarjetasTiN

º

)100

Re1(ºº

+∗=




Sección Española

CALCULOS

Tarjetas de ComunicacionesEn la mayoría de las soluciones de control el deberá de realizarse un estudio del alcance y tipo de señales o dispositivos a integrar. El número final de tarjetas de comunicaciones dependerá de las limitaciones impuestas por el propio protocolo así como por la capacidad en puertos de comunicaciones de la tarjeta elegida.


Sección Española

CALCULOS

ControladoresEl alcance final de controladores dependerá no solamente de la capacidad de cálculo (nº máximo de elementos lógicos o de control programados) y la capacidad de gestión (nº máximo de señales asignadas), sino también de los criterios seguidos para agrupar la información del proceso (orden secuencial del proceso, ubicación física de las unidades de proceso, lógicas de cálculo y control)




Sección Española

CALCULOS

2.5. Cálculos EléctricosA partir del alcance hardware implicado en un proyecto, se estará en condiciones de realizar los cálculos de consumos eléctricos con objeto de diseñar de manera correcta la distribución eléctrica necesaria en la solución de control.


Sección Española

CALCULOSObjetivo•Dimensionar el número de fuentes para alimentar a los equipos hardware.•Dimensionar el número de fuentes para alimentar a los elementos de campo.•Dimensionar correctamente el cuadro de distribución eléctrica asociado•Dimensionar correctamente las UPS o SAI •Dimensionar correctamente los dispositivos asociados a la refrigeración




Sección Española

CALCULOSPunto de PartidaEstablecer los elementos hardware implicados en el proyecto y unidades•Tarjetas•Controladores•Bastidores•Aisladores, Convertidores, Relés, etc ... •Estaciones•Impresoras•Dispositivos de red•Iluminación y Sistema de Refrigeración


Sección Española

CALCULOSPunto de partida (continuación)Determinar para cada elemento hardware:•El tipo de alimentación que necesitan

Continua o alternaDe distribución general de planta o procedente de UPS

•El consumo en régimen nominal del cada elemento hardware y cuando aplique el de los elementos de campo conectados al mismo•La disipación de calor que generan




Sección Española

CALCULOSCálculo de Fuentes de Alimentación (paso 1)Definir el tipo de fuentes a emplearEjemplo:

Fuentes para alimentar al hardware:Tensión de entrada: 24 VccTensión de salida: 12 VccAmperios suministrados: 4,5

Fuentes para alimentar al los elementos de campo:Tensión de entrada: 220 VcaTensión de salida: 24 VccAmperios suministrados: 20


Sección Española

CALCULOSCálculo de Fuentes de Alimentación (paso 2)Establecer la relación eléctrica entre los distintos tipos de fuentes implicadasEjemplo:

Las fuentes del sistema se alimentarán a partir de las fuentes de alimentación de los elementos de campo. Consecuentemente no existirán fuentes dedicadas




Sección Española

CALCULOSCálculo de Fuentes de Alimentación (paso 3)Establecer el tipo de alimentaciones que existirán en el proyecto:Ejemplo:

220 Vca, Alimentación procedente UPS220 Vca, Alimentación General de Planta


Sección Española

CALCULOSCálculo de Fuentes de Alimentación (paso 4)Establecer la relación eléctrica entre las alimentaciones y consumidoresEjemplo:

Tarjetas y Controladores <-> 24 Vcc / 12 Vcc / 4,5 ADispositivos y Campo <-> 220 Vca / 24 Vcc / 20 AFuentes <-> 220 Vca UPSEstaciones <-> 220 Vca UPSImpresoras <-> 220 Vca UPSRed <-> 220 Vca UPSIluminación y Refrigeración <-> 220 Vca General




Sección Española

CALCULOSCálculo de Fuentes de Alimentación (paso 5)Establecer los consumos


Sección Española

CALCULOS Hardware del Sistema Elementos de Campo


mA 12 Vcc mA 24 Vcc

I/O Cards

2 DI, 32-Channel, 24 VDC, Dry Contact 75 150 150 300

1 DO, 32-Channel, 24 VDC, High Side 150 150 3.200 3.200

11 Series 2 AI, 4-20 mA with HART, Simplex 150 1.650 300 3.300

3 Series 2 AI, 4-20 mA with HART, Redundant 500 1.500 400 1.200

3 Series 2 AO, 4-20 mA with HART, Redundant 300 900 400 1.200

1 Series 2 DO, 8 ch, 24Vdc, High side, Redundant 300 300 3.000 3.000

Power Supply

2 24/12 Vdc System Power Supply 0 0 5.400 10.800

2 Field System Power Supply 0 0 0 0

Controller

2 MD Controller 1.400 2.800 0 0

Aisladores

5 Grupos de Alimentación, KFD2-EB.R2A.RPI 0 0 2.000 10.000

TOTAL 7.450,00 33.000,00

TOTAL NECESARIOS 7,45 33

Sistema Circuitos de campo

Tipo de Fuente Amperios por Fuente Total Fuentes 12 Vcc Amperios por Fuente Total Fuentes 24 Vcc

TOTAL PROYECTO SIN REDUNDANCIA 4,5 2 20 1,65

TOTAL AMPERIOS DISPONIBLES SIN REDUNDNACIA 9 40

TOTAL PROYECTO CON REDUNDANCIA FUENTES (N+1) 3 3




Sección Española

CALCULOSCálculo de Líneas de Alimentación (paso 1)Establecer que consumidores necesitarán alimentación procedente de UPS y cuales alimentación general de plantaEjemplo:

Fuentes <-> Línea de 220 Vca UPSEstaciones <-> Línea de 220 Vca UPSImpresoras <-> Línea de 220 Vca UPSRed <-> Línea de 220 Vca UPSIluminación y Refrigeración <-> Línea de 220 Vca GP


Sección Española

CALCULOSCálculo de Líneas de Alimentación (paso 2)Establecer los consumos




Sección Española

CALCULOSAbsorción Corriente Ud Absorción Corriente Total Consumo Total Margen de Seguridad Consumo Total

Ud Tipo de Elemento Hardware Amperios Amperios Watios % KVA

Línea 01: Alimentación de UPS PHOENIX CONTACT QUINT 24Vdc/2,5A 0,47 0 0 0,00% 0



2 PHOENIX CONTACT QUINT 24Vdc/20A 2,3 4,6 1.269,60 0,00% 1,55


VENTILADOR CON TERMOSTATO 0,12 0 0 0,00% 0

LUMINARIA NA NA 0 0,00% 0

TOMA DE CORRIENTE EXTERNA 6 0 0 0,00% 0

TOTAL 4,6 1.269,60 1,55

Línea 02: Alimentación General de Planta PHOENIX CONTACT QUINT 24Vdc/2,5A 0,47 0 0 0,00% 0





3 VENTILADOR CON TERMOSTATO 0,12 0,36 99,36 0,00% 0,12

3 LUMINARIA NA NA 216 0,00% 0,26

1 TOMA DE CORRIENTE EXTERNA 6 6 1.656,00 0,00% 2,02

TOTAL 6,36 1.971,36 2,4


Sección Española

CALCULOSDisipación de Calor (paso 1)Establecer los elementos hardware susceptibles de disipar calor Ejemplo:

TarjetasControladoresDispositivos auxiliaresFuentes




Sección Española

CALCULOSDisipación de Calor (paso 2)Establecer la disipación total de calor con objeto de dimensionar el sistema de refrigeración asociado al habitáculo del hardware


Sección Española

CALCULOS

Sistema


Watios

I/O Cards 2 DI, 32-Channel, 24 VDC, Dry Contact 5,7 11,4

1 DO, 32-Channel, 24 VDC, High Side 30 30

11 Series 2 AI, 4-20 mA with HART, Simplex 8,4 92,4

3 Series 2 AI, 4-20 mA with HART, Redundant 18,2 54,6

3 Series 2 AO, 4-20 mA with HART, Redundant 20,4 61,2

1 Series 2 DO, 8 ch, 24Vdc, High side, Redundant 7,4 7,4

Power Supply

2 24/12 Vdc System Power Supply 1,5 3

2 Field System Power Supply 22 44

Controller

M3/M5 Controller 10,8 0

2 MD Controller 14 28

Aisladores

5 Grupos de Alimentación, KFD2-EB.R2A.RPI 0 0




Sección Española

CONSTRUCCIÓNEstablecidos los criterios y los cálculos técnicos asociados, la siguiente de la etapas consiste en la construcción física de lo diseñado:

MontajeEnsambladoConexionado

de los diferentes elementos implicados en la solución de control.Tareas basadas en los denominados planos constructivos y de interconexión


Sección Española

CONSTRUCCIÓN3.1. Planos Constructivos y de InterconexiónEstablecen:•Alcance y tipo de materiales utilizados•La ubicación•El aspecto constructivo del conjunto•Conexionado físico y eléctrico•Alcance y conexionado de la red y sus elementos•El conexionado a tierra




Sección Española

CONSTRUCCIÓN3.2. Armarios de ControlHabitáculo destinado al montaje y ensamblado de los elementos hardware.Sus dimensiones y características constructivas del mismo dependen de la solución de control.Normalmente los armarios de control siguen unos estándares en lo relativo a dimensiones y características constructivas.


Sección Española

CONSTRUCCIÓN

Item Referencia / Descripción Fabricante Rittal Bastidor 1200 / TS 8808.521 Dimensiones (con zócalo de 100 mm) 1200 x 800 x 2100 (mm) Protección IP65 Color RAL 7032 Entrada de cables Por parte inferior mediante panel galvanizado Techo Fijo con anclajes (según DIN 580) Accesos Frontal y Posterior Puertas Doble puerta en frontal / Doble puerta en posterior Apertura de puertas en bisagras 130 º Ventilación por acceso 1 ventilador (zona superior) y 1 filtro (zona inferior)Referencia del ventilador SK 3323.107 Referencia del filtro SK 3323.207 Placas de Montaje 2 (en frontal y posterior) galvanizadas Accesorios Termostato digital externo y Luminaria Tabla. 3-1-1 Detalle Armario de Control




Sección Española

CONSTRUCCIÓNArmarios de Control (continuación)El número de armarios implicados, sus dimensiones y su aspecto dependerá de:•El alcance de materiales a instalar•La disponibilidad de espacio en la sala•Los requisitos especificados en relación con la interconexión de señales entre campo y los elementos hardware implicados


Sección Española

CONSTRUCCIÓN3.3. Interconexionado de SeñalesDeberá de realizarse el diseño relativo al interconexionado de señales entre campo y tarjetas, aspecto en donde la ingeniería de instrumentación del proyecto es condicionante.•El agrupamiento en multicables de las señales•Ordenación de las señales en el multicable•Ordenar dichas señales dentro del armario•Criterios constructivos y tipo de materiales•Reserva equipada y espacial




Sección Española

CONSTRUCCIÓNInterconexionado de Señales (continuación)Solución 1 - Conexión directa•Los cables procedentes de campo llegan directamente a bornas de tarjetas•No existe un bornero de interconexión intermedio•Esta solución sencilla en costes y materiales•Esta solución impide la aplicación de cualquier criterio de agrupación de señales en tarjetas


Sección Española

CONSTRUCCIÓNInterconexionado de Señales (continuación)Solución 2 - Marshalling•Los cables procedentes de campo llegan inicialmente a un conjunto de bornas•En bornas se ordenan y etiquetan de acuerdo con un criterio (ordenación por multicable, por servicio, por funcionalidad, etc)•Desde bornas existe un segundo cableado (interno al armario) hacia las bornas de las tarjetas hardware con un segundo criterio (ordenación por tarjeta, por servicio, por funcionalidad, etc)




Sección Española

CONSTRUCCIÓN3.4. Sistema de TierrasTodo Sistema de Control Distribuido deberá de estar referenciado a tierra.Los criterios a seguir serán fijados por el fabricante.Los embarrados de tierra facilitan el conexionado a tierra de los elementos del sistemaEstos embarrados de tierra se implementan mediante pletinas de cobre aisladas.


Sección Española

CONSTRUCCIÓNSistema de Tierras (continuación)La ejecución de las conexiones es muy importante para evitar perturbaciones eléctricas que podrían afectar a la correcta funcionalidad de los equipos.El modo en que los distintos embarrados se conectan entre sí así como su conexión al sistema general de tierras depende de la especificación técnica del fabricante.Igualmente deberá de ser el fabricante el fije el mínimo valor en Ohmios de la impedancia mínima que deberá de existir en el punto de unión de los diferentes embarrados (pica general de planta)




Sección Española

CONSTRUCCIÓN

Tierra de Tensión Alterna (AC)Esta conexión garantiza la conexión a tierra de los dispositivos alimentados con tensión alterna que conforman el sistema de control.Cada armario de control deberá de contar al menos con un embarrado dedicado a este servicio.


Sección Española

CONSTRUCCIÓN

Tierra de Tensión Continua (DC)Esta conexión garantiza la referencia a tierra de las fuentes de alimentación de tensión continua y de las señales analógicas del sistema de control.Cada armario de control deberá de contar al menos con un embarrado dedicado a este servicio, constituyendo el denominado común de alimentación de tensión continua.




Sección Española

CONSTRUCCIÓNTierra de Mallas de Cables (IN)Esta conexión garantiza la referencia a tierra de las mallas de los cables y multicables procedentes de los instrumentos de campo.El tipo de multicable determinará el número de mallas:

Opción 1: 1 única malla por multicableOpción 2: 1 malla por señal del multicable

Las mallas se conectarán normalmente a una pletina paralela al bornero de señales asociado y dicha pletina se conectará a tierra a través de un embarrado general dentro del armario.


Sección Española

CONSTRUCCIÓNTierra de Chasis y Seguridad (SG)La tierra de la cabina proporciona protección a los equipos y personas contra las descargas eléctricas accidentales. Mantiene un camino de descarga directa a tierra para corrientes generadas por interferencia electromagnética.La tierra de la cabina se conecta directamente a los elementos previstos en la misma: tornillos de conexión a tierra en cada una de las partes que constituyen la misma. Estos elementos se unirán todos entre sí y desde uno de ellos se realiza la conexión a la tierra de la cabina.




Sección Española

PRUEBASEl paso con el que se cierra la ingeniería asociada al diseño hardware y software de un Sistema de Control Distribuido recibe el nombre de pruebas FAT (Factory Acceptant Test):

Inspección y aceptación según un protocolo de pruebas predefinido


Sección Española

PRUEBAS4.1. Pruebas FAT de HardwareEste paso con el que se cierra la ingeniería asociada al diseño hardware de un Sistema de Control Distribuido recibe el nombre de pruebas FAT (Factory Acceptant Test):





Sección Española

PRUEBASHardware: Inspección FísicaSe comprobará visualmente que la disposición física de los elementos en las cabinas se corresponde con lo indicado en los planos constructivos.

Inspección visual de las cabinas. Inspección visual del estado de la chapa y pintura.Comprobación del color de las cabinas.Disposición de embarrados y latiguillos de tierra.Comprobación de la accesibilidad a todos los elementos de las cabinas.Comprobación de la identificación de cabinas y elementos montados.


Sección Española

PRUEBASHardware: Montaje de ElementosSe comprobará visualmente que la disposición de los magnetotérmicos y diferenciales de protección, ventiladores y filtro, termostato, fuentes de alimentación, bastidores para equipos, bornas y canaletas, se corresponde con lo indicado en los planos constructivos.




Sección Española

PRUEBASHardware: Distribución de HardwareSe comprobará visualmente que la distribución de las fuentes de alimentación, controladores y tarjetas se corresponde en alcance, montaje y ubicación con lo indicado en los planos constructivos.


Sección Española

PRUEBASHardware: Verificación del cableadoSe comprobará visualmente que la disposición física del cableado, etiquetado de los cables, borneros y bornas se corresponden con lo indicado en los planos de interconexión.

Disposición y marcado de cables y elementos.Revisión de tierras y conexionado.Timbrado del 100% del cableado.




Sección Española

PRUEBASHardware: Fuentes de AlimentaciónSe comprobará que sus conexiones se corresponden a lo indicado en los planos constructivos. Se realizará una prueba de funcionamiento en vacío (sin carga), midiendo el valor de la tensión.


Sección Española

PRUEBAS4.2. Pruebas FAT de SoftwareEste paso con el que se cierra la ingeniería asociada al diseño software de un Sistema de Control Distribuido recibe el nombre de pruebas FAT (Factory Acceptant Test):





Sección Española

PRUEBASRevisión cuantitativaSe verificará desde el punto de vista cuantitativo el cumplimiento de la especificación.

Señales de entrada /salidaLazos analógicos.Módulos discretos.Gráficos/Sinópticos.TendenciasInformesSecuencias.


Sección Española

PRUEBASRevisión funcionalSe comprobará que el software implementado en funciona de acuerdo con las especificaciones asociadas al mismo.

Bloques de entrada/salidaBloques de control analógicoBloques de control discreto y/u otros bloques de control.Secuencias Gráficos y tendenciasInformesProgramaciónIntegración de Terceros

7B

2

INTERFASES ENTRE SISTEMAS DE INFORMACIÓN

FICHA IDENTIFICATIVA DEL DOCUMENTO: Master ISA de instrumentación y control Módulo: 7B – Ingeniería de Sistemas de Control Tema: 7B - 2 – Interfases entre Sistemas de Información Autor: Miguel Angel Sinobas

INTRODUCCIÓN El capítulo de Interfases entre Sistemas de Información tratará de mostrar los aspectos prácticos con ejemplos reales y formas concretas de comunicarse e intercambiar información entre los diferentes Sistemas de Gestión de la Producción de una Compañía, continuando con las Aplicaciones consideradas plataforma o lanzadera de datos de Instrumentación, que se encuentren conectadas al Sistema de Control Distribuido, y terminando por la idea de un Sistema Integrado de Información, donde se muestre esta información de producción en formatos homogéneos, proponiendo la creación de una herramienta que aproveche estas Interfases de datos para facilitar la gestión de la producción y toma de decisiones.

Otro aspecto importante a tratar, con el fin de preservar la seguridad de los datos y aplicaciones que residen en el Sistema de Control Distribuido de la Planta, es la división en dos de la red interna de información - LAN (Local Area Network). Como se desarrollará más adelante, esto se consigue disponiendo de una Red de Control independiente de la Red general de Datos. Esta Red de Control se encontraría conectada a la Red de Datos por un lado y al SCD por el otro.

Este capítulo está concebido como complemento del 7A-2 y tratará aspectos prácticos relacionados con los Sistemas de Gestión de la Producción, su interacción entre sí y la interrelación con su entorno.

Precisamente por tratarse de aspectos prácticos, los ejemplos y configuraciones expuestas irán dirigidas a un escenario en concreto, compuesto por TDC3000™ de Honeywell® como Sistema de Control Distribuido, PI™ de OSISoft® como Sistema de Información de Planta, SQL*LIMS® de Applied Biosystems™ como Sistema de Gestión de Laboratorio y el Sistema de Producción del Complejo - SPC - del Grupo Repsol YPF como Sistema de Información de Producción. Sin embargo, en lo que se pueda, se tratará de generalizar ya que estas configuraciones pueden disponerse para múltiples plataformas.

Módulo: Ingeniería de Sistemas de Control Tema: Interfases entre Sistemas


INTERFASES ENTRE SISTEMAS DE INFORMACIÓN

Índice

1. CONOCIMIENTOS PREVIOS REQUERIDOS 3 2. INTERFASES DE INFORMACIÓN DE PRODUCCIÓN 4 3. SISTEMA DE INTERFASES DE INFORMACIÓN 5

3.1. Intercambio de información 6

3.2. Sistema de mensajería 8

4. PLATAFORMA DE DATOS DE INSTRUMENTACIÓN 12 5. RED DE CONTROL Y RED DE DATOS 15 6. SISTEMA INTEGRADO DE INFORMACIÓN DE

PRODUCCIÓN 17 7. ACTIVIDADES PROFESIONALES 19 8. REFERENCIAS Y BIBLIOGRAFÍA 20



1. CONOCIMIENTOS PREVIOS REQUERIDOS

Al igual que en el capítulo 2 del módulo 7A, no existen especificaciones sobre conocimientos previos, ya que este capítulo del master, aunque relacionado con él, se aparta de los conocimientos fundamentales que se adquieren en el mismo, complementándolos al tratar de dar una visión sobre la utilización de la instrumentación para fines de información y gestión de una Compañía.

Aunque los temas que se tratan en este capítulo necesitarían, para una buena ejecución profesional, de un equipo humano con completa preparación en disciplinas de Ingeniería e Informática, no se necesita esta formación para la asistencia a esta parte del master, ya que, por límites de tiempo y estructura del mismo, están dirigidos a aportar un complemento informativo muy interesante para los futuros profesionales de la Instrumentación y el Control, ofreciendo una visión más amplia de sus horizontes, interacciones y consecuencias profesionales.

Tan sólo, y por ser este capítulo una continuación del 7A - 2, se requiere asistir a ambos capítulos de este módulo 7, como parte de un todo.



2. INTERFASES DE INFORMACIÓN DE PRODUCCIÓN

Tal como se ha comentado en la introducción, en este capítulo del master se comentarán los aspectos prácticos relativos al intercambio de información entre los diferentes Sistemas de Gestión de la Producción, contemplando, además, las interfases de información de estos sistemas de consulta general en la Compañía con los Sistemas de Control Distribuido, de uso más restringido, donde se encuentran los datos de la instrumentación de Planta y facilitar así el acceso a esta información.

La exposición se hará dividida según los cuatro apartados siguientes:

1. Sistema de Interfases de Información

Intercambio de información entre los diferentes Sistemas de Gestión de la Producción.

2. Plataforma de datos de Instrumentación

Envío de datos desde el Sistema de Control Distribuido a las diferentes aplicaciones de información de producción.

3. Red de Control y Red de Datos

Creación de una Red de Control intermedia más segura entre el SCD y la Red de Datos general para soportar las aplicaciones de control.

4. Sistema Integrado de Información de Producción

Aplicación que recoge información del resto de los Sistemas de Gestión de la Producción y la presenta como si de un único Sistema se tratara.

Este último cuarto punto, tal como se puede apreciar de lo expuesto en la breve descripción, más que tratarse de una interfaz entre sistemas, trata de una propuesta de interfaz única entre el Usuario y los datos de Producción.



3. SISTEMA DE INTERFASES DE INFORMACIÓN

Por Sistema de Interfases de Información, en el ámbito que se está tratando en este capítulo del Master, se entiende un sistema encargado de intercambiar información entre los diferentes Sistemas de información de la Producción.

Esta información puede tener un carácter puramente informativo o tener consideración de necesaria o la menos conveniente para la buena gestión de la información de un sistema en concreto. En el primer caso, el traspaso de información se realiza para que se pueda consultar un dato de un sistema en otro, y facilitar así las labores de consulta a los Usuarios. En el segundo caso, debido a que los sistemas de gestión de producción tienen una interrelación entre sí importante, como no podía ser de otra forma, necesitan proporcionarse información unos a otros para conseguir un mejor funcionamiento de los mismos y ofrecer así un buen servicio informativo para la gestión de la Compañía.

Un ejemplo de información con carácter exclusivo para consulta podría ser el envío del Poder Calorífico del gas de combustión de un horno desde el Sistema de Gestión del Laboratorio al Sistema de Información de Planta para poder ser visualizado en un gráfico de información de proceso junto a los datos de temperaturas, caudales, etc. relativas al horno en cuestión.

Como ejemplo de información necesaria, sirve el envío desde el Sistema de Información de Planta de niveles de elementos de almacenamiento para el cálculo de volúmenes trasegados en el parque de almacenamiento al Sistema de Información de la Producción con el fin de efectuar el cálculo de los Certificados de Cantidad en la venta de productos terminados.

Fig. 2-3-1 Sistema de Interfases de Información de Producción



3.1. Intercambio de información

En este punto se tratarán de mostrar unos ejemplos de transferencias entre Sistemas de Información de Producción que, si bien están extraídos de la industria del sector de refino petrolífero1, se podría hacer abstracción de ellos para aplicarlos a la industria química en general.

• Sistema de Información de Planta Sistema de Información de Producción.

Los datos que se pueden enviar desde un SCADA hacia el Sistema de Información de Producción van dirigidos a la gestión de inventarios con el envío de Niveles, Temperaturas y Presiones de los diversos Elementos de Almacenamiento (Tanques, Esferas, Silos, etc.). Otra posibilidad de transferencia de datos de planta se da en el caso de envío de Caudales horarios para la gestión de Unidades y Energías (Consumos y Mermas).

• Sistema de Información de Planta Sistema de Gestión del Laboratorio.

En el caso de envío de información desde el SCADA hacia el Sistema de Gestión del Laboratorio existen dos ejemplos ilustrativos. Por un lado el envío de Modos de Operación de las Unidades de Proceso, para la gestión del registro automático de muestras en función de las condiciones de la Planta. El otro caso se refiere al envío de la Fecha y Hora de la Toma de una Muestra dada para el control de analizadores en línea.

En la figura 2-3-2 se muestra el envío de esta Fecha y Hora de Toma de Muestra mediante el uso de válvulas de fin de carrera o pulsadores situados en planta que envían la señal del momento de esta toma al SCD (Sistema de Control Distribuido) y de ahí al Sistema de Información de Planta, pasando a continuación, mediante el Sistema de Interfases de Información, al Sistema de Gestión de Laboratorio, permitiendo la verificación de los Analizadores en línea que hay dispuestos en la planta para el control de calidad de las corrientes intermedias de producción. De esta forma se pueden realizar inferencias entre los valores que ofrecen los análisis del Laboratorio y el analizador en cuestión con el fin de verificar si existen desviaciones en la medida de los mismos.

Fig. 2-3-2 Registro de Fecha-Hora de toma de muestra



Existe un tercer caso que contempla el envío de petición de registro de muestras desde el Sistema de Información de Planta o, incluso, desde el propio Sistema de Control Distribuido.

• Sistema de Gestión del Laboratorio Sistema de Información de Planta.

El Sistema de Gestión del Laboratorio puede hacer el envío de datos relativos a corrientes de proceso al Sistema de Información de Planta con el fin de mostrarlos en este sistema en los gráficos de variables de proceso y facilitar así una visión más detallada del estado de las Plantas de producción.

Otro envío interesante del Laboratorio hacia el Sistema de Información de Planta son los resultados de Densidades y Pesos Moleculares de corrientes de las Unidades de Proceso para la Compensación de Caudales.

• Sistema de Gestión del Laboratorio Sistema de Información de Producción.

El envío de datos del SGL (Sistema de Gestión del Laboratorio) al Sistema de Información de Producción trata de cumplir diferentes funciones. Una de ellas se refiere al envío de la Densidad de productos terminados para la confección del Certificado de Cantidad. Asociado a este envío, pueden ir el resto de características de estos productos terminados, con lo que, junto con el Certificado de Cantidad, se podría emitir el Certificado de Calidad correspondiente.

• Sistema de Información de Producción Sistema de Información de Planta.

El Sistema de Información de Producción, como núcleo de los Sistemas de Gestión de la Producción, principalmente recibe datos para procesarlos en conjunto, por lo que no es habitual el traspaso de información de éste al resto de los sistemas. Un ejemplo de este tipo de transferencias es el envío del estado de los Elementos de Almacenaje, con esto se informa de su situación en cuanto a movimientos de entrega o recepción de productos, mostrándolo en los gráficos del Sistema de Información de Planta junto a los datos de instrumentación de estos elementos.

• Sistema de Información de Producción Sistema de Gestión del Laboratorio.

Existe otra posibilidad de uso del Sistema de Interfases desde el Sistema de Información de Producción. En este caso, la finalidad es la petición de registro de muestras al Sistema de Gestión de Laboratorio relacionadas con elementos de almacenamiento. Esta transferencia permite a los técnicos de Operaciones no tener que cambiar de aplicación cuando se encuentran informando de movimientos de productos, principalmente en las operaciones que tienen que ver con acciones de compra-venta.



3.2. Sistema de mensajería

La tecnología que subyace en un Sistema de Interfases de Información puede variar desde una comunicación directa entre bases de datos hasta la utilización de un software intermedio como Sistema de Mensajería que asegure la entrega de los datos y sea independiente de las aplicaciones que se comunican entre sí y de la tecnología en la que se basan.

La comunicación directa entre bases de datos resulta la solución más sencilla, ya que apenas necesita de software adicional, pero tiene la desventaja de no poder asegurar que los datos llegarán a su destino por motivo de fallos en la red de comunicaciones o problemas con la aplicación destinataria de la información. Además, es posible encontrarse con importantes limitaciones técnicas cuando se trate de comunicaciones entre entornos, como plataformas de ordenadores o sistemas operativos, muy diferentes.

La finalidad de los Sistemas de Mensajería es conseguir la unión e integración de diferentes aplicaciones, permitiendo el intercambio de información, enviando los datos al sitio adecuado y transformando, si así fuera necesario, los mismos de forma correcta a lo largo de diferentes aplicaciones y bases de datos. Muchos de estos sistemas se basan en lo que se denomina Encolamiento de Mensajes.

El Encolamiento de Mensajes es una técnica de utilidad para el intercambio de información en entornos de aplicaciones distribuidas. Las colas de mensajes tienen la función de almacenar los datos enviados hasta que sean leídos por el programa receptor. El uso de la técnica de mensajes encolados permite que los programas que corren tras las aplicaciones puedan ejecutarse de forma independiente, ya que ni necesitan conocer la localización en la que están unos y otros, ni tienen que esperar a que el programa receptor recoja el mensaje antes de continuar.

Un mensaje consiste en una estructura de datos, construida por una aplicación en la que los responsables de la programación definen el contenido del mismo. La comunicación a través de mensajes requiere que ambos programas involucrados en el envío y recepción de los mismos estén de acuerdo en el protocolo de comunicación, esto es, sobre la forma de escribir e interpretar estos mensajes. Se muestra así evidente que el trabajo del sistema de encolamiento de mensajes se delimita simplemente a transportar los datos del mensaje de un sistema a otro.

La técnica de encolamiento de mensajes funciona de la siguiente forma:

o El programa "A" hace una llamada al sistema de mensajería. La llamada le dice a este sistema que tiene un mensaje y está listo para su envío al programa "B".

o El sistema de encolamiento de mensajes envía el mensaje al sistema donde reside el programa "B" y lo coloca en la Cola perteneciente a este programa "B".

o Cuando corresponda, el programa "B" lee el mensaje de la Cola que tiene asociada y procesa la información recibida contenida en el mismo.

o Si el sistema no puede hacer entrega del mensaje por fallos en la comunicación, disfunciones del programa receptor o cualquier otra razón, existe una posibilidad de recuperación de mensajes que permite el reenvío de los mismos, sin necesidad de intervención de ninguna de las aplicaciones implicadas, en el momento de restablecimiento de la comunicación entre ambas.



De las varias posibilidades de elección de software para ser utilizado como sistema de mensajería, se comentará en este capítulo de Master los fundamentos del Sistema de Mensajería BEA MessageQ™ (BEA® Message Queue)2, utilizado ampliamente a nivel internacional y en diferentes sectores industriales.

BEA MessageQ™ posibilita la implementación de un sistema de encolamiento de mensajes. Para intercambiar información usando BEA MessageQ™, cada programa que se beneficiará de este intercambio debe conectarse a un BUS de mensajería en la dirección de una COLA determinada, que a su vez pertenece a un GRUPO de colas concreto.

La dirección de una Cola identifica cada Cola de mensajes en la cual el programa recibirá los datos, esta dirección se genera con la combinación del número de Bus, número de Grupo y número de Cola. Para enviar un mensaje con BEA MessageQ™, un programa dado debe conocer la dirección de la Cola del programa receptor. En contraste con otras aplicaciones de mensajería, el programa no necesita conectarse a la Cola que enviará el mensaje, aunque para poder conectarse al Bus de mensajes, necesitará estar conectado a una cola, generalmente temporal, con el único fin de realizar esta conexión.

Fig. 2-3-3 Sistema de encolamiento de mensajes

El Bus de encolamiento de mensajes conforma la autopista de datos que se usará para transferir mensajes entre aplicaciones al crear una interconexión lógica de Grupos de Colas de mensajes en el entorno de una red. Una vez que una aplicación se conecta al Bus de Colas, en la dirección de Cola que le corresponda, puede enviar mensajes a cualquier otra aplicación conectada y también tiene la posibilidad de leer mensajes que se envíen a su Cola o Colas.

La otra entidad que existe en el sistema BEA MessageQ™ necesaria para definir la dirección completa de una Cola se denomina Grupo. Un Grupo se puede definir como un conjunto de direcciones lógicas en un Bus de mensajería en el que se comparten recursos. Cada Grupo reside en un solo sistema, servidor o nodo, pudiendo residir varios Grupos en el mismo sistema. La interconexión entre estos Grupos define la extensión de un Bus de encolamiento de mensajes.



Las Colas pueden ser temporales o permanentes. Las Colas temporales se utilizan generalmente para hacer la conexión puntual de un programa que pretende hacer el envío de un mensaje al Bus de mensajería, ya que el único requisito que necesita una aplicación para enviar mensajes es el de haber establecido una conexión con este Bus. Las Colas permanentes son generalmente las encargadas de la recepción de mensajes y están asignadas permanentemente a los programas que se conectarán a ellas para leer los datos que les lleguen.

La figura 2-3-4 ilustra un ejemplo real de envío de resultados de muestras, desde el Sistema de Gestión de Laboratorio al Sistema de Información de Producción, mediante el uso de BEA MessageQ™ como Sistema de Mensajería, y una serie de programas y procedimientos de bases de datos, que completan lo que supone una parte del Sistema de Interfases de Información.

Fig. 2-3-4 Ejemplo de esquema de transferencia



En el ejemplo se puede ver la existencia de diferentes programas en origen (SGL), capaces de realizar el envío de información extraída de los datos del Laboratorio en un formato concreto para que sean interpretados por los programas receptores de esta información, haciendo las conexiones necesarias al Sistema de Mensajería BEA MessageQ™.

El siguiente paso lo llevará a cabo el Sistema de Mensajería, enviando los mensajes dejados en las Colas origen a las Colas destino indicadas por los programas del SGL.

De igual manera, en la figura 2-3-4 se puede ver la existencia de otros programas en destino (SPC), que leerán los mensajes enviados en la Cola correspondiente. Posteriormente tratarán estos mensajes y, previa validación de la información que están procesando, harán las correspondientes actualizaciones en la aplicación destino del Sistema de Información de Producción, con lo que se habrá terminado el proceso de envío de datos entre ambos sistemas.

Una ventaja de estos sistemas es que se favorecen las migraciones independientes en los distintos entornos involucrados en el intercambio de información, puesto que no existe una dependencia directa entre ellos.

Como información adicional, comentar que existen otros sistemas de mensajería comerciales entre los que se encuentra la siempre presente Microsoft® con el producto Microsoft® Message Queue Server (MSMQ)3 que presenta ventajas cuando el intercambio de información se desenvuelve sobre plataformas Windows™, pero, aunque posible, tiene el inconveniente de necesitar de programación adicional si se pretende comunicar diferentes plataformas de Servidores de información.

Para finalizar con el punto de Interfases entre Sistema de Información, decir que este tipo de desarrollos, tal como se puede intuir de la exposición hecha hasta ahora, seguramente necesite de una gran dosis de análisis y programación por parte de los Responsables de Sistemas de Información dentro de la Compañía, ya que en muchos casos, correspondientes a múltiples configuraciones posibles en cada Empresa, puede haber gran heterogeneidad entre las diferentes aplicaciones que soportan los Sistemas de Producción, con lo que encontrar un producto en el mercado, que realice el intercambio de información en un sistema distribuido de aplicaciones de información, puede resultar de difícil consecución.



4. PLATAFORMA DE DATOS DE INSTRUMENTACIÓN

Para disponer, en la red de datos de información general, de la información ofrecida por los instrumentos de planta que se envía directamente al Sistema de Control Distribuido, se necesita una plataforma que actúe de interfaz de los mismos y que, en principio, pueda actuar de forma bidireccional, aunque el principal cometido de esta plataforma sea el envío de estos datos de instrumentación hacia los Sistemas de Gestión de la Producción.

Para esta labor existe un elemento apropiado, como es el Sistema de Información de Planta, que además de actuar como lanzadera de estos datos de instrumentación, forma parte de los Sistemas de Gestión de Producción, ofreciendo, además, la visualización de las variables de las Unidades de Proceso al resto de la Compañía.

Fig. 2-4-1 Plataforma de datos de instrumentación

En la figura 2-4-1 se puede ver un esquema de situación del Servidor de Información de Planta, conectado por un lado al Sistema de Control Distribuido y por el otro a la Red de Datos de la Compañía.

También se puede observar la existencia de un elemento denominado 'Router', que una vez configurado de acuerdo a las particularidades de cada caso, actúa como filtro de seguridad, impidiendo el paso de información no deseada y potencialmente peligrosa al SCD, donde la seguridad es factor prioritario. Más adelante se dará algún detalle adicional sobre la funcionalidad 'cortafuegos' de este elemento.

El Sistema de Información de Planta, como se comentó con cierto detalle en el módulo 7A-2, recoge la información del SCD, por un lado, y del resto de los Sistemas de Producción, por el otro. A su vez, puede actuar como lanzadera de datos en ambos sentidos, bien ofreciéndolos a los Sistemas de Información de la Producción, caso habitual, o bien enviándolos al Sistema de Control Distribuido para que estos puedan formar parte de la lógica en el Control Avanzado, caso menos usual.



Este último aspecto de lanzadera de datos hacia el Sistema de Control Distribuido, como se ha dicho, es de poco uso ya que supone un cierto riesgo permitir el paso de esta información sin una supervisión que tenga en cuenta los criterios de la Operación de Control. Por esta razón, lo habitual es que el Operador de Control consulte personalmente el Sistema de Gestión de la Producción pertinente y tome acciones en el SCD de forma consciente y meditada.

Considerando el PI™ de OSISoft® como aplicación que asume el papel de Sistema de Información de Planta, hay que expresar la necesidad de disponer de una interfaz adicional que conecte a éste con el Sistema de Control Distribuido. A esta interfaz se la denomina AppNode (Application Node).

Si además consideramos que el Sistema de Control Distribuido que poseemos es el TDC3000™ de Honeywell®, este AppNode consiste en un ordenador, PC convencional, que necesita de dos capas o interfases de software en su instalación fundamentadas en el estándar de comunicaciones OPC (Ole for Process Control):

1. PI-OPC Client. Capa necesaria para interlocución e intercambio de información con PI™.

2. OPC Server HCI. Interfaz para comunicación con el TDC (Total Distributed Control).

Fig. 2-4-2 Conexión Servidor PI™ de OSISoft®

Una de las capas de software de este nodo, como se muestra en la figura 2-4-2, en el lado de la red de control LCN (Local Control Network) del TDC, se denomina HCI (Honeywell Communication Interface) y actúa como servidor de datos. La capa que mira hacia el Servidor de PI, se denomina PI-OPC Client y se encarga de la comunicación con el Sistema de Información de Planta. Dicho de otra forma, el PI-OPC Client actúa como interfaz entre el Servidor de datos PI™ y el Servidor de datos OPC, permitiendo el diálogo e intercambio de información entre ambos.

Tratándose de un APPNode conectado a un PI Server, éste se puede configurar de forma que la comunicación se establezca por los puertos 5450 en el envío hacia PI™ y por los puertos ≥1024 en los datos enviados hacia el Application Node o, lo que es lo mismo, hacia la LCN, con lo que se consigue, lo que se denomina, un nodo PINS (PI Networking Subsystem), evitando realizar configuraciones abiertas en el Router por los puertos 135 y 137 utilizados como configuración por defecto y problemáticos por su uso frecuente en los intercambios realizados en Internet, con la consiguiente pérdida de seguridad en la transmisión de datos.



A parte de esto, con el fin de tener un mayor control en la seguridad, los servidores de PI™ tienen integrada una base de datos “cortafuegos”. Esta base de datos actúa a nivel de dirección IP y consigue limitar los accesos al Servidor del Sistema de Información de Planta. Esto permite tener inventariados, con posibilidad de control, los dispositivos que se conecten al servidor de PI™ desde la red de datos de la Compañía.

Otra opción adicional de evitar problemas derivados de los puertos abiertos en el Router es aumentar la seguridad en los accesos al PI Server. Esto, según información de OSISoft®, se puede conseguir utilizando dos tarjetas de red en el Servidor de PI™, una para la red de control y la otra para la red de datos. Esta solución es posible ya que en el PI Server no corre ningún programa de “Routing” por lo que los paquetes que lleguen por la tarjeta de la red de datos no podrían alcanzar nunca la tarjeta de la red de control.

A modo de introducción, recordar que el estándar OPC permite conectarse a cualquier software instalado en un cliente que cumpla con estas especificaciones, con cualquier servidor de OPC sin tener en cuenta el hardware implicado en el proceso. Cada interfaz o cliente se puede comunicar con un solo 'OPC Server', el cual puede estar en el mismo ordenador o en uno remoto.

La noción que subyace en el OPC3 en el entorno de datos de producción, es que existe un dispositivo, el cual tiene ciertos valores que ofrecer, como puede ser el sistema TDC3000™ de Honeywell®, el servidor de OPC conoce que existen dichos valores y los enviará a cualquier Cliente OPC que se los pida.

Según se ha mostrado en la figura 2-4-2, la disposición del PI OPC Client dentro del AppNode en vez de tenerlo en el Servidor de PI se debe a que se evita el tráfico innecesario de información por la red al aplicarse el algoritmo de 'exception' (control de paso de datos repetitivos desde el SCD) en el Nodo intrerfaz con la LCN de Honeywell® y, lo más importante, no se pierde información del TDC en caso de pérdida de comunicación con el Servidor de PI™ ya que la interfaz PI OPC de OSISoft® permite el almacenamiento temporal de los datos (buffering), enviando los mismos en el momento de restablecerse la comunicación entre el PI Server y el Application Node.

Por último, hacer la anotación de que el Sistema PI™ de información de Planta suministra como complemento un módulo denominado APS, Auto Point Synchronization, que, como su nombre indica, permite la sincronización de los Tags del Sistema de Control Distribuido con los Tags de PI™. Esto facilita la creación de puntos provenientes del SCD en el Sistema PI™, copiando de forma automática los parámetros de configuración de los mismos:

o valores superior e inferior permitidos para el medidor

o descripción del mismo

o unidades de medida, etc.

Además, si se producen cambios en la configuración de algún Tag en origen, estos cambios pueden detectarse automáticamente en el Sistema de Información de Planta consiguiendo así evitar diferencias en la configuración de los mismos, lo que aumenta la fiabilidad en la consulta de los datos de Planta desde el sistema PI, permitiendo, al menos en situaciones no exhaustivas, evitar el desplazamiento hasta las salas de control pertinentes.



5. RED DE CONTROL Y RED DE DATOS

Para aumentar la seguridad en el entorno informático del control de Planta, tiene especial importancia la creación de Redes de datos de Control, manteniéndolas separadas de las Redes generales de Datos, impidiendo el paso de información ‘dañina’ y/o virus informáticos hacia el control de la operación, 'acorazando' así este sistema.

Al hablar de Red de Control, no nos referimos a la red propia de los sistemas de control que suelen ser 'cautivas' e independientes de cualquier sistema externo, entendiendo por 'cautivas' las tecnologías dedicadas, ex profeso, a un sistema en concreto que no amplían su alcance a usos más generalistas, sino que la Red de Control es una red creada para conectar los servidores y aplicaciones que están conectados a la LAN propia de la Compañía, al sistema de control distribuido, dividiendo, así, la red local y generando dos redes que entrarán a formar parte de la intranet de la Compañía, añadiendo, además, elementos de seguridad entre ambas que permitan el paso de información de forma controlada y limitada.

Fig. 2-5-1 Red de Datos y Red de Control

La figura 2-5-1 representa el elemento de control que se utiliza para aumentar la seguridad en el intercambio de información entre la Red de Datos y la Red de Control. Este elemento se fundamenta en un Router que, tratándose, como se ha dicho, de un entorno con Servidor PI™ como Servidor de Información de Planta, tiene abiertos los puertos ≥1024 para el paso de datos en ambas direcciones.



En la figura 2-5-2 se puede observar gráficamente la división de la red LAN en una Red de Control dedicada a conectar sistemas y aplicaciones propios de Control Avanzado y una Red de Datos donde residirá el Servidor de Información de Planta junto al resto de aplicaciones que den servicio a las necesidades informáticas de la Empresa y donde, además, pueden existir enlaces a otras redes LAN e, incluso, la red Internet cuando proceda.

Fig. 2-5-2 Esquema de conexiones LAN - SCD

Se puede observar, viendo las figuras anteriores, el aumento de seguridad que se consigue en el Sistema de Control Distribuido al hacer la mencionada división o disgregación de la Red general de Datos, configurando la Red de Control independiente.

Con toda seguridad que existen muchas otras configuraciones que permitan el aumento de seguridad en el SCD dirigidas a la protección del mismo de la información dañina que pueden hacer peligrar la estabilidad del Control operacional de las unidades de proceso. La expuesta en este apartado no es más que una solución decidida e implementada en las Refinerías de Repsol YPF después de un proceso de estudio de soluciones viables, económicas y convincentes.



6. SISTEMA INTEGRADO DE INFORMACIÓN DE PRODUCCIÓN

Hoy en día existen distintos fabricantes y productos para los sistemas de control, históricos de proceso, alarmas, sistemas de gestión de laboratorio, sistemas para la reconciliación, balance, movimientos y restos de sistemas en entorno de fabricación5. Esta problemática de diversidad de sistemas heterogéneos, aún utilizando estándares, no garantiza la uniformidad en el uso y explotación de los mismos.

La idea de un Sistema Integrado de Información de Producción surge precisamente de esta problemática y trata de dar solución a la uniformidad, centralización y combinación de las diferentes fuentes de información de producción.

Fig. 2-6-1 Diseño de Sistema Integrado de Información de Producción



Podría decirse que es un último escalón en la pirámide de información de producción de una Compañía, donde se tratará de representar de forma homogénea información combinada de los diferentes Sistemas de Producción, pudiéndose incluir en los casos que interese, información del resto de los Sistemas de Información para ofrecer una visión más global del estado de las Plantas de proceso, ayudando así a la toma de decisiones y gestión de la producción.

La figura 2-6-1 representa la idea de un proyecto de estas características donde se aprecia el menú principal de la aplicación, en el cual se combinan posibilidades de consulta de los diferentes Sistemas de Gestión de la Producción. Al seleccionar cada una de las opciones disponibles, se mostrará la información referida al sistema consultado en cada caso, pudiendo ofrecerse también una combinación de datos de varios sistemas.

La existencia de una sola aplicación implica, según lo que viene siendo habitual en la actualidad, un desarrollo en entorno Web, permitiendo 'navegar' entre los datos provenientes de los diferentes Sistemas de Producción de la Compañía. Además, el uso de este entorno para presentar la información no necesita de software adicional en los ordenadores de los Usuarios, tan sólo el sistema operativo Windows e Internet Explorer. A este tipo de Clientes se los denomina 'Thin Client'.

Decir por último que hay que tener presente que este clase de desarrollos Web supone la aplicación de tecnología OPC, HTML, Java, Visual.NET, SOAP y Servidores Web entre otros estándares posibles, aunque en la actualidad comienzan a aparecer nuevos productos que quieren poner en el mercado esta filosofía de oferta de información. Tal es el caso de OsiSoft® con su nuevo sistema PI™ denominado RtPM™ - Real-time Performance Management - que comienza a tener una gran aceptación en la gran industria y con el que se ofrece tanto el archivo de información como la explotación y análisis de la misma de muy diversas formas así como la combinación de esta información con la obtenida desde otras diferentes fuentes de datos.



7. ACTIVIDADES PROFESIONALES

El esquema que se presenta a continuación, ilustra las necesidades del equipo de trabajo que se dedicará a la administración de los Sistemas de Producción, así como la relación con los equipos de profesionales de los que requerirá información y los que harán uso de estos Sistemas de información de la Producción.

Actividades profesionales relacionadas con el módulo. Generación de nueva información: - Departamento de Soporte informático y gestión de Redes de Información.

Conocimientos previos necesarios: - Conocimiento del Proceso Industrial - Administración de Bases de Datos - Administración de Sistemas

Operativos - Conocimientos de Programación

Conocimientos adquiridos en el Módulo: - Visión global y generalista sobre un proyecto de Gestión

de Información de Planta. - Visión del equipo humano a formar.

Datos de Otros requeridos: - Variables y Gráficos de Proceso procedentes del

Sistema de Control. - Diagramas P&I. - Información fiscal de Productos de la Compañía. - Información de Gestión de Laboratorio. - Información comercial, clientes, proveedores, etc. - En general, toda la información necesaria, de

acuerdo al alcance de aplicabilidad del proyecto de Sistemas de Producción.

Actividades de Otros que requieren esta información: - Departamento de Procesos - Consulta de información de Producción en tiempo real. - Laboratorio - Información de los datos que generan para la Compañía. - Departamento de Operaciones - Consulta de calidad del proceso. Control de inventarios - Dirección Económico Financiera – Gestión de Compra / Venta.



8. REFERENCIAS Y BIBLIOGRAFÍA

A continuación se enumeran las Referencias y Bibliografía utilizada en este capítulo.

Referencias:

1. Puesta en marcha del SGL en Repsol YPF, European Informatics User Meeting Tour, Miguel Angel Sinobas, Petronor - Repsol YPF, Barcelona, Enero 2002

2. Introduction to Message Queuing, BEA MessageQ™, BEA® Systems, March 2000 3. OPC Interface to the PI™ System, OSISoft® Corporation 4. Building Distributed Applications with Message Queuing Middleware, Peter Houston,

Microsoft Corporation, 1998 5. Entorno único para el acceso a los sistemas de información y control, Joaquín Abril-

Martorell Hernández, ISA Sección España - Conferencia Anual 2003

Bibliografía:

1. IT Manager's Handbook, Bill Holtsnider & Brian D. Jaffe, Morgan Kaufmann, Octubre 2000

2. Computer Networks, Andrew S. Tanenbaum, Prentice Hall, Agosto 2002



Sección Española


Interfases entre Sistemasde Información

Interfases entre Sistemasde Información


Módulo 7BTema 2

2

Sección Española

Master de Instrumentación y Control Módulo 7B Tema 2 Interfases entre S. Información

Mostrar los aspectos prácticos con ejemplos reales y formas concretas de comunicarse e intercambiar información entre los diferentes Sistemas de Gestión de la Producción de una Compañía

Introducción

Aplicaciones consideradas plataforma o lanzadera de datos de Instrumentación, que se encuentren conectadas al Sistema de Control DistribuidoSistema Integrado de Información, donde se muestre esta información de producción en formatos homogéneosRed de Control independiente de la Red general de Datos



3

Sección Española


•Sistema de Control Distribuido

TDC3000™ de Honeywell®

•Sistema de Información de Planta

PI™ de OSISoft™ (RtPM)

•Sistema de Gestión de Laboratorio

SQL*LIMS® de Applied Biosystems™

•Sistema de Información de Producción

SPC de Repsol YPF

Introducción

4

Sección Española


Interfases entre Sistemas de Información

Intercambio de información entre los diferentes Sistemas de Gestión de la Producción, además de la interfaz con el Sistema de Control Distribuido•Sistema de Interfases de InformaciónIntercambio de información entre los diferentes Sistemas de Gestión de la Producción.•Plataforma de datos de InstrumentaciónEnvío de datos desde el Sistema de Control Distribuido a las diferentes aplicaciones de información de producción•Red de Control y Red de DatosCreación de una Red de Control intermedia más segura entre el SCD y la Red de Datos general para soportar las aplicaciones de control•Sistema Integrado de Información de ProducciónAplicación que recoge información del resto de los Sistemas de Gestión de la Producción y la presenta como si de un único Sistema se tratara



5

Sección Española


Sistema de Interfases de Información

Interfases de Información de Producción

Sistema encargado de intercambiar información entre los diferentes Sistemas de información de la Producción

6

Sección Española


Intercambio de InformaciónSistema de Información de Planta Sistema de Información de Producción

Sistema de Información de Planta Sistema de Gestión del Laboratorio

Niveles, Temperaturas y Presiones para la gestión de Elementos de almacenajeCaudales horarios para balances de Unidades y Energías

Modos de Operación de Unidades de procesoFecha y Hora de toma de muestras para control de analizadores enlínea



7

Sección Española


Intercambio de Información

Sistema de Gestión del Laboratorio Sistema de Información de Planta

Sistema de Gestión del Laboratorio Sistema de Información de Producción

Datos de calidad de corrientes de proceso

Densidades y Pesos Moleculares para Compensación de Caudales

Densidad de productos para Certificado de Cantidad

Características de Elementos de almacenamiento

8

Sección Española


Intercambio de Información

Sistema de Información de Producción Sistema de Información de Planta

Sistema de Información de Producción Sistema de Gestión del Laboratorio

Estado de los Elementos de almacenamiento en cuanto a Movimientos

Registro de Muestras de control de elementos de almacenamiento



9

Sección Española


Sistema de Mensajería

La finalidad de los Sistemas de Mensajería es conseguir la unión e integración de diferentes aplicaciones, permitiendo el intercambio de información, enviando los datos al sitio adecuado y transformando, si asífuera necesario, los mismos de forma correcta a lo largo de diferentes aplicaciones y bases de datos. Muchos de estos sistemas se basan en lo que se denomina Encolamiento de Mensajes

El Encolamiento de Mensajes es una técnica de utilidad para el intercambio de información en entornos de aplicaciones distribuidas. Las colas de mensajes tienen la función de almacenar los datos enviadoshasta que sean leídos por el programa receptorUn mensaje consiste en una estructura de datos, construida por una aplicación. La comunicación a través de mensajes requiere que ambos programas involucrados en el envío y recepción de los mismos estén de acuerdo en el protocolo de comunicación

10

Sección Española


Sistema de Mensajería

El programa "A" hace una llamada al sistema de mensajería. La llamada le dice a este sistema que tiene un mensaje y está listo para su envío al programa "B"

El sistema de encolamiento de mensajes envía el mensaje al sistema donde reside el programa "B" y lo coloca en la Colaperteneciente a este programa "B"

Cuando corresponda, el programa "B" lee el mensaje de la Cola que tiene asociada y procesa la información recibida contenida en el mismo

Si el sistema no puede hacer entrega del mensaje, existe una posibilidad de recuperación de mensajes que permite el reenvío de los mismos, sin necesidad de intervención de ninguna de las aplicaciones implicadas, en el momento de restablecimiento de la comunicación entre ambas



11

Sección Española


BEA MessageQEncolamiento de Mensajes

BUS

COLA

GRUPO

12

Sección Española


Sistema de MensajeríaEsquema de Transferencia

Envío de resultados desde el SGL al SP



13

Sección Española


Plataforma de DatosLanzadera de Datos de InstrumentaciónDisponer, en la red de datos de información general, de la información ofrecida por los instrumentos de planta que se envía directamente al Sistema de Control Distribuido

Sistema de Información de Planta actúa como lanzadera de estos datos de instrumentación

14

Sección Española


Plataforma de Datos

Conexión del Servidor del Sistema de Información de Planta

•PI de OSISoft

PI-OPC Client

•TDC3000 de Honeywell

OPC Server HCI



15

Sección Española


Protocolo OPC

El estándar OPC permite conectarse a cualquier software instalado en un cliente que cumpla con estas especificaciones, con cualquier servidor de OPC sin tener en cuenta el hardware implicado en el proceso. Cada interfaz o cliente se puede comunicar con un solo 'OPC Server', el cual puede estar en el mismo ordenador o en uno remoto

La noción que subyace en el OPC en el entorno de datos de producción, es que existe un dispositivo, el cual tiene ciertos valores que ofrecer, como puede ser el sistema TDC3000 de Honeywell, el servidor de OPC conoce que existen dichos valores y los enviará a cualquier Cliente OPC que se los pida, como el PI-OPC Client del Sistema PI

16

Sección Española


Red de Control – Red de DatosSeparación de la Red de Control de la Red general de Datos

Para aumentar la seguridad en el entorno informático del control de Planta, tiene especial importancia la creación de Redes de datos de Control, manteniéndolas separadas de las Redes de generales de Datos, impidiendo el paso de información ‘dañina’ y/o virus informáticos hacia el control de la operación, 'acorazando' así este sistema

ROUTER (Firewall): Elemento de seguridad entre redes que permite el paso de información controlada y limitada



17

Sección Española


Conexión LAN - SCDDivisión de la LAN en Red de Control y Red de Datos

18

Sección Española


Sistema Integrado de Producción

Hoy en día existen distintos fabricantes y productos para los sistemas de control, históricos de proceso, alarmas, sistemas de gestión de laboratorio, sistemas para la reconciliación, balance, movimientos y restos de sistemas en entorno de fabricación. Esta problemática de diversidad de sistemas heterogéneos, aún utilizando estándares, no garantiza la uniformidad en el uso y explotación de los mismosLa idea de un Sistema Integrado de Información de Producción surge precisamente de esta problemática y trata de dar solución a la uniformidad, centralización y combinación de las diferentes fuentes de información de producción



19

Sección Española


Sistema Integrado de ProducciónDiseño de Sistema Integrado de la Información de Producción

Sección Española


Miguel Angel Sinobas Control Avanzado y Sistemas de Producción Petronor –Repsol YPF

Master de Instrumentación y Control de Procesos

PREGUNTASVALORACIÓN

Interfasesentre Sistemas de Información

7B 3

Ergonomía de sistemas: concepción de la sala de control

FICHA IDENTIFICATIVA DEL DOCUMENTO:

Master ISA de instrumentación y control

Módulo: 7

Tema: B3 Ergonomía de Sistemas

Autor: Jesús Villena

INTRODUCCIÓN

El proyecto de diseño o la reconcepción de una sala de control es una de las actividades que

exige más interdisciplinariedad en la industria: desde los estudios acústicos a la interacción

hombre-máquina, en la sala de control se centralizan problemáticas técnicas y humanas muy

heterogéneas que es necesario identificar y resolver.

Por otro lado, la sala de control es un espacio relativamente nuevo de la industria, ya que se

trata de un espacio de supervisión que aparece cuando es posible centralizar información

que antes se encontraba dispersa por la instalación. Sin embargo conviene recordar que

podemos encontrar este tipo de salas no sólo en la industria, también en el ámbito de las

telecomunicaciones, en la gestión de tráfico ferroviario, en la vigilancia de instalaciones, en

el control de la navegación aérea o marítima, etc.

En este texto nos proponemos, desde la ergonomía, abordar de forma sumaria los aspectos

clásicos que afectan al proceso de concepción de la sala

Módulo: 7 Ergonomía de sistemas Tema: Ergonomía de sistemas


Ergonomía de sistemas: ergonomía de la sala de control

Índice

1. ASPECTOS MEDIOAMBIENTALES DE LA SALA 4

1.1. La iluminación de la sala 4

1.2. La acústica de la sala 5

1.3. Aspectos térmicos de la sala 6

2. ASPECTOS FÍSICOS Y ESPACIALES DE LA SALA 6 3. LOS INTERFACES INFORMÁTICOS, LA DOCUMENTACION, LA FORMACIÓN DE LOS OPERADORES 7

3.1. Interfaces informáticos 7 3.1.1. Orientación 9 3.1.2. Incitación 10 3.1.3. Agrupamiento 11 3.1.4. Retroalimentación 12 3.1.5. Legibilidad 13 3.1.6. Carga de Trabajo 14 3.1.7. Brevedad 14 3.1.8. Densidad 15 3.1.9. Control Explícito 16 3.1.10. Adaptabilidad 16 3.1.11. Flexibilidad 17 3.1.12. Experiencia 18 3.1.13. Gestión del Error 18 3.1.14. Protección 19 3.1.15. Calidad del Mensaje 19 3.1.16. Corrección 20 3.1.17. Homogeneidad 20 3.1.18. Significatividad 21 3.1.19. Compatibilidad 22

3.2. El sistema de alarmas 23 3.2.1. Definición de alarma 23 3.2.2. Tipos de alarma 24 3.2.3. Selección del punto de alarma 25



3.2.4. Priorización 25 3.2.5. Valores de referencia 26

3.3. La documentación 26 3.3.1. Trabajos preparatorios: La documentación es una herramienta de trabajo. 27 3.3.2. Definir los contenidos 27 3.3.3. Construir y aplicar una guía de estilo 28 3.3.4. Redactar la Versión 0 de la documentación 29 3.3.5. Validar la Versión 0. 29 3.3.6. Elaborar la versión 1 de la documentación 29 3.3.7. Utilizar las informaciones obtenidas durante todo el proceso 29

3.4. La formación de los operadores 30 3.4.1. Los objetivos de la formación 30

4. CONCLUSIONES 31

4.1. La cuestión de la normativa. 32

4.2. Ergonomía y proyectos industriales 32

5. PARA SABER MÁS… 34



1. ASPECTOS MEDIOAMBIENTALES DE LA SALA

1.1. La iluminación de la sala

Un sistema luminoso de calidad para la sala de control debe:

• Evitar la fatiga visual (por el sobreesfuerzo de acomodación que conlleva el deslumbramiento).

• Ofrecer un rendimiento adecuado de los colores.

• Ser modular y flexible con relación a las necesidades de los usuarios.

La cantidad de luz necesaria estará en relación con las características del trabajo que se

realice y el estado visual de los trabajadores (cuanta más edad se tiene es necesaria más

cantidad luz para compensar la vista cansada o presbicia).

En términos generales, podría decirse que una sala de control se requiere una

iluminación general de 500 lux, aunque dependerá del tipo de equipamiento, volumen

de la sala, etc.. La iluminación local de los puestos deberá ofrecer un sistema de

iluminación regulable de 150 a 500 lux. Si hay zonas de la sala en las que es necesario

estudiar información de detalle (documentos o planos) se dispondrá de una

iluminación regulable que pueda alcanzar los 750 lux.

Es importante evitar el deslumbramiento. El deslumbramiento se produce cuando las

distintas luminancias estás desequilibradas, a saber, hay distintas fuentes luminosas (ventanas,

bombillas, pantallas) que ofrecen al aparato visual diferentes intensidades de luz (medidas en

cd/m2 ). Cuando el aparato visual recorre el paisaje de la sala corren el riesgo de

deslumbrarse.

Para evitar el deslumbramiento, es recomendable elegir fuentes de iluminación

amplias y de baja luminancia, fuentes indirectas de iluminación o mixtas (con rejillas

dotadas de prismas que difunden la luz hacia todas las direcciones: la fuente de luz no

debe ser directamente aparente).



Es recomendable que el balance de luminancias entre zonas cercanas para la vista no

exceda de 1 a 3. Esta relación en visión central y visión periférica no debe exceder el

balance 1 a 20. En esta relación es necesario tener en cuenta los coeficientes de

reflexión de la luz de las distintas partes de la sala (techos, muros, mobiliario...). Es

también recomendable que las superficies de los materiales (en especial de los pupitres

de control sean mates).

La luz debe permitir un adecuado rendimiento de los colores, una característica técnica de

las bombillas. Esto es especialmente importante para el personal de mantenimiento que puede

trabajar con cableados de distintos colores.

1.2. La acústica de la sala

La acústica de la sala se tratará con especial cuidado ya que no se tratará de un peligro

para el aparato auditivo, sino de una molestia que, además, comporta elementos informativos

para el operador (teléfono, alarmas, conversaciones...). Son precisamente las conversaciones y

el tránsito de personas por la sala lo que más perturba a los operadores de control.

Para evitar esta molestia, la normas internas suelen ser insuficientes: resulta más

recomendables habilitar pasillos de acceso dedicado (contratistas) o sala de reuniones

anexas (entre mandos intermedios y operadores exteriores) que simplemente prohibir el

acceso a la sala.

Por lo que se refiere a la acústica de la propia sala, es prioritario el evitar la reverberación.

Para ello es imprescindible una adecuada concepción del material de suelos, paredes, etc..

Para evitar la reverberación, se elegirán materiales que ofrezcan una duración de la

reverberación de entre 0,8 y 0,9 segundos para las frecuencias de la voz humana. Todos

los materiales empleados deberán ser absorbentes (evitar la decoración “industrial” con

materiales metálicos o acristalamientos estéticos).

El equipamiento puede ser también un fuente de molestia acústica (impresoras de agujas,

climatización, sistemas de intercomunicación...) Se promoverá la elección de equipos que,

ofreciendo el mismo rendimiento, tengan el mejor tratamiento acústico.



1.3. Aspectos térmicos de la sala

El medioambiente térmico de la sala debe concebirse para el operador de control, no para

las personas que puntualmente accedan a la sala de control. Para alcanzar este objetivo, se

deberá considerar que el panelista no se mueve o se mueve muy poco, su aparato

termorregulador no cuenta con la movilidad ni el esfuerzo físico que suele darse en una gran

parte de los trabajos de otros operadores de la instalación y es especialmente sensible a las

diferencias térmicas en su cuerpo o su zona de trabajo.

Estas son las temperaturas de confort térmico recomendables en sala.

Invierno. Temperatura de aire regulable entre 19 y 22ºC. Velocidad del aire ≤ 0,15

m/s. Humedad relativa entre 45 y 60%.

Verano. Temperatura de aire regulable entre 20 y 25ºC. Velocidad del aire ≤ 0,20

m/s. Humedad relativa superior a 45%.

Tanto en invierno como en verano, la temperatura del suelo no debera mantener

una diferencia superior a los 3ºC. No se presentarán grandes diferencias térmicas

(inferiores de 2ºC) entre las piernas y la cabeza de los operadores

Por último, se deberá prever un sistema de climatización que garantice la limpieza del aire

(mediante filtros y el mantenimiento del sistema de humidificación), especialmente en las

salas bunquerizadas.

2. ASPECTOS FÍSICOS Y ESPACIALES DE LA SALA

En la definición del espacio de la sala se debe considerar todo el equipamiento necesario para

realizar las funciones de control, desde los dispositivos del sistema de supervisión a los

elementos de clasificación o almacenaje. Será necesario, por tanto, considerar:

Distribución de los pupitres

o Relaciones de visibilidad entre operadores

o Necesidades de lectura y escritura en el puesto



o Número de operadores que utilizaran el pupitre, incluso en momentos

puntuales (incidencias, formación, actividades simultáneas de ingeniería o

mantenimiento...).

o .../...

Las zonas generales de lectura y de escritura

Los paneles informativos

El mobiliario de clasificación y archivo

Las zonas de consulta de planos

Los dispositivos de control de la iluminación, termostatos, etc..

Se prestará especial cuidado en la elección de la silla, ya que se tratará del elemento

que sufre un uso más intensivo por parte de los operadores: de cinco ruedas, se podrá

regular en altura e inclinación, su tapizado será robusto y de fácil limpieza.

Así mismo, se identificarán las necesidades:

o De intervención del mantenimiento en posiciones de control o el espacio de la

sala (falsos techos/suelos), ubicación y características de salas de racks, etc..

o De limpieza (accesibilidad, compatibilidad de la operación en continuo y los

requerimientos de higiene).

o Ubicación y características de despachos y espacios de reunión, zonas de

tránsito y señalética,

3. LOS INTERFACES INFORMÁTICOS, LA DOCUMENTACION, LA FORMACIÓN DE LOS OPERADORES

3.1. Interfaces informáticos

La norma ISO 9241 permite dar unos primeros pasos para concebir y chequear la calidad

estática de un interfaz hombre-máquina. Estos son los grandes aspectos que pueden

encontrarse en esta norma:



Organización de la información, particularmente

o en ventanas

o áreas informativas

o grupos de informaciones

o listas

o tablas y etiquetas

o campos

Objetos gráficos

o Cursores y punteros

Sistemas de codificación

o Códigos, abreviaturas

o Colores y formatos

Sin embargo es necesario realizar chequeos dinámicos de la aplicación. El Institut

National de Recherche en Informatique et en Automatique –INRIA- de Jouy en Josas

(Francia) nos ofrece la posibilidad de realizar este chequeo mediante las siguiente grandes

magnitudes:

Orientación

o Incitación

o Agrupamiento

o Retroalimentación

o Legibilidad

Carga de Trabajo



o Brevedad

o Densidad

Control Explícito

Adaptabilidad

o Flexibilidad

o Experiencia

Gestión del Error

o Protección

o Calidad del mensaje

o Corrección

Homogeneidad

Significatividad

Compatibilidad

Nos proponemos desarrollar a continuación cada uno de estos criterios de evaluación

3.1.1. Orientación

Se fija como objetivo estudiar los medios puestos a disposición del usuario para

recomendarle, informarle y guiarle en sus acciones sobre el sistema (mensajes, alarmas,

sistemas de ayuda, etc.). La orientación contribuye a que el usuario establezca relaciones

causales entre sus acciones y el estado del sistema.

Los aspectos léxicos (formatos, colores, ubicaciones, etc.) forman parte de estos medios

puestos a disposición del usuario para orientarle.



El criterio Orientación se compone de cuatro subcriterios (considerados criterios cuando

son tomados de forma aislada): Incitación, Agrupamiento, Retroalimentación y

Legibilidad.

Este criterio pretende:

Facilitar el aprendizaje.

Favorecer la utilización del sistema.

Prevenir errores dando al usuario la posibilidad de conocer:

− la secuencia de interacciones H-M en la que se encuentra.

− las consecuencias de las acciones que va a emprender.

− las informaciones complementarias en caso de solicitarlas.

Un sistema informático debe orientar porque...

Un sistema construido sin criterios de orientación puede originar ansiedad e

incertidumbre y, como consecuencia, rechazo.

Se producen menos errores y la ejecución de las tareas es más eficiente cuando

el usuario sabe dónde se encuentra en una secuencia de interacciones, conoce

las acciones que le son permitidas así como sus consecuencias y puede obtener

información suplementaria para activar y comprender funciones nuevas o de

uso poco frecuente.

3.1.2. Incitación

Mediante la incitación se pretende poner a disposición del usuario medios que le lleven a

ejecutar acciones, a conocer alternativas ante varias opciones, a identificar el contexto o

estado donde se encuentra.

Su objetivo:

El usuario debe poder ver, encontrar y utilizar aquello que necesita en el

momento en que lo necesita (WYSIWYG: “What you see is what you get”).



Reducir la cantidad de información que debe memorizar el usuario

Favorecer la navegabilidad dentro del sistema (dónde se encuentran, qué han

hecho para llegar hasta allí y cómo acceder a otras vías)

Prevenir el error y la infrautilización.

La incitación es importante porque:

Es un soporte informativo para los recursos psicofisiológicos (percepción,

memoria) del usuario: la memoria “operativa” tiene un bajo nivel de

almacenamiento (las navegaciones que no orientan facilitan el olvido) y debe

utilizarse en ocasiones excepcionales.

Las capacidades de almacenaje de la “memoria operativa” se reducen tras

sesiones prolongadas de trabajo (la atención y la vigilancia disminuyen).

Un sistema es rechazado, infrautilizado y produce irritación si en estados de

fatiga (baja atención y vigilancia, memoria limitada) no acompaña en la

navegación (no orienta e incita).

3.1.3. Agrupamiento

Cuando se habla de agrupamiento se pretenden analizar los criterios de organización de la

información que afecta a las relaciones entre ítems informativos. El agrupamiento afecta a

las relaciones dentro una clase de ítems y entre diferentes clases de ítems.

También se trata de la organización del espacio de diálogo del usuario con la aplicación

teniendo en cuenta sus competencias y/o atribuciones dentro de un espacio de trabajo.

Hay dos formas de Agrupamiento: por Localización (organización topológica) y por

Formato (Tamaños,. Colores, etc.). La Localización afecta a la ubicación y el Formato a

sus características gráficas (ej.: un grupo de ítems puede agruparse en una zona

determinada de la pantalla y/o tener un formato de color que les asigna a una determinada

clase).

Un buen agrupamiento de la información persigue:



Facilitar el aprendizaje, la memorización, la comprensión de la información

aparecida en la pantalla.

Agrupar teniendo en cuenta los contextos en los que se utiliza la información

(agrupamientos por frecuencia, criticidad, alfabéticos, etc.), lo que reduce los

tiempos de realización de la tareas o subtareas, aumentando con ello la eficacia

general del sistema.

Guiar al usuario sobre los ítems o grupos de ítems que componen la aplicación,

lo que contribuye a mejorar la navegabilidad.

Es necesario agrupar adecuadamente la información, ya que los mecanismos del recuerdo

de los usuarios son más efectivos y conllevan menos “carga cognitiva” si se basan en

guías que permitan situar y categorizar el entorno complejo y diverso que les rodea.

Cuando en la configuración del interfaz de diálogo se agrupa y distingue el espacio

informativo que se presenta al usuario, se mejoran los tiempos de búsqueda de

información.

3.1.4. Retroalimentación

Es la reacción consecutiva del sistema a las acciones del usuario. Las expresiones de

salida del sistema deben permitir evaluar la situación, compararla con el objetivo buscado

y/o proseguir o modificar el plan de acción.

El sistema debe responder en el plazo más breve de tiempo. Esta respuesta debe referirse a

la acción en curso y a su resultado. La respuesta del sistema debe ser visible, pertinente y

concisa.

Con la retroalimentación se pretende:

Aumentar la seguridad, confianza y satisfacción de los usuarios con el sistema

creando respuestas similares ante acciones similares en tiempos similares.

Reducir el tiempo necesario de aprendizaje.

La retroalimentación es necesaria porque:



Para aprender y trabajar de manera cada vez más eficaz, los usuarios necesitan tener una

“imagen mental” del funcionamiento de su equipo y de las aplicaciones que utiliza. Esta

imagen se refuerza si las respuestas del sistema son rápidas, regulares y constantes.

Cuando las intenciones del usuario le llevan a realizar un tipo de acción, “espera” del

sistema una respuesta acorde con su experiencia. Si esta respuesta no se produce, aparecen

formas de ansiedad e incertidumbre que se manifiestan en un rechazo de la aplicación.

3.1.5. Legibilidad

La legibilidad analiza las características léxicas de la presentación de información:

luminancia de los caracteres, contraste caracteres-fondo, dimensión de los caracteres,

espacio entre las palabras, entre líneas, entre párrafos, extensión de la líneas, etc.1

La información debe ser legible para:

Facilitar la lectura de las informaciones presentes en pantalla.

Minimizar las fuentes de confusión y error.

Reducir la fatiga visual.

Los seres humanos tienes características y límites fisiológicos (aparato visual) y

cognitivos (hábitos y costumbres, esquemas e imágenes mentales) que son en parte

identificables: para un puesto de trabajo informatizado dado, siempre hay una estructura

léxica de la información que mejora la eficacia en la detección de la información (tiempos

necesarios para captar una información), la fiabilidad en el reconocimiento (posibilidad de

comisión de errores) y confortable (produce menos fatiga visual). Un sistema poco legible

es lento, puede llevar a error y fatigará más al usuario.

1 La legibilidad se encuentra en estrecha relación con la concepción física del puesto de trabajo informatizado. No

existen características léxicas universales sino características léxicas particulares, ya que deben tenerse en cuenta la

distancia ojo-pantalla, la inclinación, ubicación, tamaño y altura de ésta, la iluminación local y general (discriminación

de colores y contrastes, etc.) en cada situación.



3.1.6. Carga de Trabajo

Este criterio afecta a la eficacia general del sistema de diálogo, es decir, al conjunto de

elementos del interfaz que afectan al número de acciones necesarias para alcanzar un fin,

a las exigencias perceptivas o de la memoria de los usuarios.

El criterio Carga de Trabajo se compone de dos subcriterios (considerados criterios

cuando son tomados de forma aislada): Brevedad y Densidad.

Se pretende:

Aumentar la eficacia y satisfacción general que genera el sistema gracias a la

economía de interacciones hombre-máquina.

Reducir la fuentes de error.

El usuario, cuando adquiere experiencia de uso de una determinada aplicación y su

sistema de diálogo, tiende a detectar los “pasos” innecesarios a los que le obliga el

sistema:

En primer lugar, tenderá a buscar “atajos” (muy operativos en determinados

contextos y fuentes de error en otros).

En segundo lugar, automatizará los procesos que considera largos e

innecesarios si estos atajos no son posibles (lo que puede ser fuente de error

durante la realización de las tareas);

En tercer lugar, tenderá a rechazar la realización de tareas que exigen

procedimientos largos o rechazará el sistema en su conjunto.

3.1.7. Brevedad

Exigencias para la percepción y la memoria del usuario en lo que se refiere a los

elementos de entrada o salida (concisión) y las secuencias de entradas (acciones mínimas

necesarias para llegar a un objetivo o realizar una tarea).



Con la brevedad se busca limitar el trabajo de lectura, de entrada de datos y las etapas por

las que tienen que pasar los usuarios, lo que favorece el aprendizaje, el desarrollo de

destrezas, la eficacia y fiabilidad del sistema.

Las capacidades de la “memoria operativa” son limitadas. Por ello, cuanto más cortas sean

las entradas, más limitados son los riesgos de error. Cuanto más lacónicos sean los ítems,

más breve será el tiempo de lectura. Cuanto más numerosas y complicadas sean las

acciones necesarias para llegar a un objetivo, mayor será la carga de trabajo, la posibilidad

de confusión y el rechazo de la aplicación.

3.1.8. Densidad

Una aplicación informática es densa cuando sobrecarga de la percepción y la memoria del

usuario debida al número de informaciones en pantalla. Esta sobrecarga se asocia al

conjunto de informaciones y no a los ítems tomados por separado.

Cuando se quiere aligerar una aplicación se busca:

Suprimir elementos visuales y/o auditivos que no tienen relación alguna con el

contenido de la tarea en curso.

Evitar la necesidad de poner en marcha actividades cognitivas más complejas

de lo requerido por la tarea (ej.: memorizar procedimientos y/o informaciones

largas y numerosas).

Los argumentos que apoyan este criterio...

Cuando la carga informativa es muy elevada o muy débil, los resultados de la

actividad del usuario se resienten, pudiendo aumentar la probabilidad de error.

La “memoria operativa” es limitada (7±2 ítems “memorizables”), por ello la

densidad informativa puede ser fuente de error y de pérdidas de tiempo en el

manejo del sistema.

La necesidad de realizar actividades cognitivas complejas, para la percepción

y/o recuerdo de procedimientos y/o informaciones, no permite al usuario

concentrar todo su esfuerzo en la realización de la tarea, sino en el manejo de la



herramienta, lo que puede llegar a ser causa de fatiga, infrautilización y/o

rechazo de la aplicación.

3.1.9. Control Explícito

El sistema debe ejecutar solamente las operaciones que el usuario le demanda y en el

momento en que se lo demanda: El sistema debe tener un comportamiento explícito.

El usuario debe poder controlar la activación y el desarrollo de las operaciones ejecutadas

por el sistema informático (interrumpir, retomar).

Los aspectos semánticos deben estar directamente relacionados con los efectos

producidos. Se debe informar al usuario de lo que está pasando en cada momento.

Los efectos de los comandos deben ser previsibles para el usuario.

Con este criterio se persigue:

Reducir la infrautilización de las aplicaciones.

Favorecer el aprendizaje y reducir los espacios posibles de error.

Es necesario que las aplicaciones dispongan de control explícito, ya que:

Cuando se definen explícitamente las demandas de los usuarios y están bajo su

control se producen menos ambigüedades, equívocos y errores.

Un sistema que activa funciones no explícitas para el usuario genera

inseguridad e infrautilización, retrasa o dificulta el aprendizaje.(ej.: copias de

seguridad de archivos con denominaciones diferentes en lugares no previsibles

o explicables para el usuario).

3.1.10. Adaptabilidad

Un sistema es adaptable cuando se ajusta al contexto, a las necesidades y preferencias de

los usuarios.

Esta adaptación se refleja en dos subcriterios (considerados criterios cuando son tomados

de forma aislada): Flexibilidad y Experiencia.



Se busca:

Reducir los riesgos de exclusión de usuarios potenciales por experiencia

insuficiente, inadaptación a sus necesidades o preferencias.

Minimizar los riesgos de infrautilización del sistema.

Ya que...

El usuario potencial se adaptará mejor a la dinámica de diálogo con el sistema si éste le

ofrece diversas opciones para realizar una misma tarea. En términos generales, los

usuarios con experiencias, edades y formaciones diversas, emplearán diversas vías para

alcanzar sus objetivos.

3.1.11. Flexibilidad

La flexibilidad estudia la organización de la cooperación entre el sistema informático y el

usuario. Grados de libertad que permite el sistema en la actuación del usuario. El sistema

no debe limitar las posibilidades de actuación (flexibilidad decisional) y aprendizaje de

los usuarios. También se trata de la capacidad del sistema para adaptarse al contexto y a

las necesidades, hábitos y preferencias de los usuarios. También de los medios puestos a

disposición del usuario para personalizar el interfaz.

La flexibilidad:

Hace posible que usuarios con perfiles diversos puedan utilizar la herramienta,

minimizando los riesgos de infrautilización o rechazo del sistema por algún

segmento de éstos usuarios potenciales.

Permite que un mismo usuario pueda obtener idéntico resultado por

procedimientos diferentes, reduciendo los tiempos de realización de las tareas.

Gracias a la flexibilidad:

Se favorece el aprendizaje y la evolución en el manejo de la herramienta

cuando se posibilita al usuario efectuar una misma tarea de distintas maneras.

De esta forma puede llegar a dominar una de ellas.



3.1.12. Experiencia

Es una característica del sistema podría definirse como la facilidad de la que dispone para

adaptarse a los conocimientos previos de los usuarios, así como a sus niveles de

experiencia, estrategias, rutinas y lenguaje.

Con este criterio se busca:

Disminuir los tiempos de aprendizaje de la nueva aplicación.

Aumentar la eficacia global en el manejo de la aplicación.

Cuanto más necesario sea aprender un nuevo sistema (nuevos procedimientos,

codificaciones, etc.), obligando a olvidar los saberes y destrezas anteriores, mayor será el

tiempo necesario de formación, las posibilidades de error en el manejo y el riesgo de

rechazo al cambio.

Las experiencia acumulada no se olvida nunca. Los automatismos adquiridos permiten

enfrentarse a situaciones conocidas con una mayor rapidez y menor riesgo de error. Sin

embargo, si el sistema no se adapta a esta experiencia, aunque sea el usuario el que se

adapta a las nuevas exigencias, en momentos de fatiga, estrés o presión temporal pueden

reaparecer los viejos esquemas y automatismos, lo que puede ser causa de graves errores.

3.1.13. Gestión del Error

La gestión del error afecta a todos los medios que permiten, por un lado, evitar o reducir

los errores y, por otro, corregirlos cuando aparecen.

Este criterio se desarrolla en tres subcriterios (llamados criterios cuando son descritos

aisladamente): Protección, Calidad del Mensaje y Corrección.

La gestión del error pretende poner en marcha los medios necesarios para detectar los

errores cuando se introducen datos o informaciones antes de la validación de éstos

(protección contra el error), o cuando éste ya se ha producido (corrección del error).

Las interrupciones provocadas por los errores prolongan el diálogo y perturban la

planificación, dificultan la realización de la tarea y, en definitiva, reducen la eficacia

general del sistema.



3.1.14. Protección

Afecta a todos los medios que permiten detectar y prevenir los errores en la introducción

de datos, comandos o acciones que puedan tener consecuencias negativas para las tareas

en curso o para el sistema en general.

Con la protección se busca la puesta en marcha de los medios necesarios para detectar los

errores cuando se introducen datos o informaciones (anticipación al error) antes de la

validación de éstos (corrección del error). Gracias a este criterio:

El usuario empleará procesos de ensayo-error para familiarizarse con la

herramienta y para trabajar.

Estos procesos pueden verse incrementados cuando no existe una formación y/o

documentación de uso que acompañe adecuadamente la adquisición de

destrezas en el manejo de la herramienta. El sistema debe ayudar a evitar la

comisión de este tipo de errores.

Cuando se desarrollan las habilidades y destrezas ligadas a la experiencia del

uso de cualquier herramienta, el usuario tiende a desarrollar automatismos

sensori-motores que pueden, en momentos de sobrecarga o fatiga, causar

errores: El sistema debe proteger al usuario de este tipo de errores.

3.1.15. Calidad del Mensaje

Este criterio afecta a la pertinencia, facilidad y exactitud de la información dada a los

usuarios sobre la naturaleza de los errores cometidos (sintaxis, formato, etc.) y a las

acciones que deberán emprender para corregirlos. Los mensajes son de calidad cuando:

Se Favorece la progresividad en el aprendizaje, generando seguridad, confianza

y sensación de control de la herramienta.

Se reducen las tasas de error, minimizando el rechazo y favoreciendo la

aceptación de la herramienta.

Es necesario velar por la calidad de los mensajes, ya que:;



El nivel de concepción (propio del desarrollador informático) es distinto al de

uso (propio de usuarios que tienen perfiles distintos). Estos dos niveles se

manifiestan en lógicas distintas por lo que se refiere a la información

transmitida (plano semántico, sintáctico y léxico).

Para que los mensajes de error puedan ser comprendidos y utilizados

adecuadamente, éstos deben adaptarse al contexto de uso, sin obligar al usuario

a comprender la lógica profunda de la aplicación.

3.1.16. Corrección

Este criterio afecta a los medios puestos a disposición de los usuarios para corregir sus

errores. Se busca:

Favorecer la progresividad en el aprendizaje, generando seguridad, confianza y

sensación de control de la herramienta.

Reducir las tasas de error, minimizando la irritación, rechazo y favoreciendo la

aceptación de la herramienta.

El nivel de concepción (propio del desarrollador informático) es distinto al de uso (propio

de usuarios con perfiles distintos). Estos dos niveles se manifiestan en lógicas distintas

por lo que se refiere a la información transmitida (plano semántico, sintáctico y léxico).

Para que el usuario comprenda y utilice adecuadamente los medios para corregir sus

errores éstos deben adaptarse al contexto de uso, sin obligar a aquel a comprender la

lógica profunda de la aplicación.

3.1.17. Homogeneidad

Una aplicación es homogénea cuando se produce una ausencia de excepciones dentro de

ella: Los códigos, denominaciones, formatos, procedimientos o las acciones deben ser los

mismos en contextos idénticos de utilización del sistema y distintos en contextos distintos.

Este principio se extiende a todas las etapas de realización de una tarea, particularmente

en:

la elección de las metáforas de interacción.



la especificación del plan de acción que se debe seguir para realizar una tarea.

la ejecución misma de la tarea:

− aspectos sintácticos (orden de los argumentos),

− aspectos léxicos (nomenclatura, forma, localización y organización espacial

de la información).

La homogeneidad garantiza:

Una reducción de los tiempos de aprendizaje necesarios para dominar la

aplicación así como los de tiempos de búsqueda de informaciones.

Que el comportamiento del sistema sea previsible e intuitivo para el usuario,

mediante la normalización de los diferentes sistemas de diálogo utilizados. Esto

reduce el número de errores de ejecución y facilita la resolución de los mismos.

Es necesario que una aplicación ser homogénea porque:

Determinadas formas de automatismo en el trabajo tienden a economizar los

esfuerzos perceptivos: De este modo, si dos contextos son distintos pero el

sistema de diálogo sólo los diferencia levemente, el usuario puede cometer

errores graves (ej.: borrado de ficheros con nombres casi idénticos).

La memoria y el aprendizaje se refuerzan cuando el sistema de diálogo es

estable, y previsible. Esto reduce la incertidumbre y la inseguridad en la

herramienta. De este modo, es más fácilmente reconocida, localizada y utilizada

una información cuando el formato, ubicación o sintaxis de los procedimientos,

etiquetas y comandos son idénticos en la misma aplicación y entre diferentes

sesiones de trabajo o distintos en contextos o sesiones de trabajo distintas.

3.1.18. Significatividad

Se trata de la adecuación entre el objeto o la información presentada o introducida y su

referente. Relación semántica fuerte entre la denominación y el referente (denominación

significante).



Con la significatividad se quiere:

Favorecer el aprendizaje y la memorización rápida de funciones.

Desarrollar sistemas de diálogo “intuitivos”.

La significatividad es necesaria porque:

Afecta no solamente a aspectos de orden psicológico sino a aspectos sociales (

oficios, edades, culturas, países, etc.).

Si la codificación es significativa se mejora el reconocimiento y el recuerdo de

la misma. Los códigos y denominaciones poco significativos pueden sugerir a

los usuarios la realización de operaciones no apropiadas o llevarles a cometer

errores.

3.1.19. Compatibilidad

Es la capacidad del sistema para adaptarse al trabajo de los usuarios. Acuerdo entre las

características de los usuarios, las tareas que realizan, la organización de acciones y el

diálogo del sistema.

Capacidad del sistema para tener en cuenta las características psicofisiológicas y

socioculturales de los usuarios: percepción, memoria, atención, hábitos, experiencia…

Grado de semejanza entre los diferentes entornos y aplicaciones empleadas en un contexto

dado. Se busca:

Facilitar la transición entre sistemas informáticos y hacer posible la convivencia

entre diversos entornos (físicos y/o lógicos).

Mejorar la transferencia de competencias entre diferentes sistemas y

aplicaciones.

Reducir los tiempos de aprendizaje, el número de errores y la eficacia global de

uso en entornos y aplicaciones diversas que son utilizadas por los mismos

usuarios.



Aumentar las posibilidades de intervención del usuario en momentos de

incertidumbre y/o situaciones degradadas.

Mediante la compatibilidad:

se facilita la utilización de la aplicación y la apropiación cognitiva de la misma

si el usuario se encuentra con un universo conocido, ya que se beneficia de los

conocimientos, automatismos y rutinas desplegados en el manejo de los

mismos.

La transferencia de información de un contexto a otro es más rápida y eficaz

cuando el volumen de información distinta a tratar por el usuario es reducido.

3.2. El sistema de alarmas

Un sistema de alarmas es un sistema de avisos al operador, normalmente a través de sonidos

(alarmas acústicas) o indicaciones visuales (luminosas, por colores, formatos y ubicaciones) y

mensajes que indican un problema que requiere su actuación.

El objetivo de un sistema de alarmas es reducir la probabilidad de que el mal funcionamiento

del proceso (físico químico, de control de tráfico, de flujo de informaciones, etc...) provoque

daños en las personas, el medio ambiente o pérdidas económicas (por daño a la instalación o

pérdidas de producción). Es por tanto una de las muchas herramientas que se utilizan en la

reducción de los riesgos de un sistema a un nivel tolerable y su función es ayudar al

operador a detectar problemas en dicho sistema y priorizar su respuesta

Cada alarma debe por tanto: Alertar, informar y guiar.

3.2.1. Definición de alarma

Una alarma es un aviso al operador de que existe una situación anormal en el sistema que

requiere su acción inmediata.

Esto excluye toda aquella información de una situación, estado, tarea, etc. que no requiera

acción por parte del operador y que definiremos como ALERTAS.

Las características de una alarma correctamente definida son:



Relevante. No deben ser “falsas” alarmas o de muy poca importancia.

Única. No estar duplicadas con otra alarma en el mismo sistema o en otro

Oportuna. El operador debe disponer de tiempo para decidir qué tiene que hacer y

hacerlo, pero no de tanto como para que pueda hacer otras tareas antes.

Bien priorizada. Debe indicar la importancia con la que el operador de control debe

atenderla

Entendible. El mensaje debe ser claro y único para el operador

Identifica la causa. Dirige la atención del operador a la causa del problema

Permite una acción correctiva. El operador puede tomar una acción para evitar el

riesgo.

La experiencia demuestra que la mayor parte de los fallos de los sistemas de alarmas son

debidos a fallos humanos (en la fase de concepción del sistema de alarmas o en su operación)

más que a fallos del hardware que lo soporta, bien sean los elementos de detección o el

propio interfaz con el operador. Es por lo tanto fundamental tener en cuenta en el diseño al

usuario del sistema de alarmas, el operador y su ambiente de trabajo.

3.2.2. Tipos de alarma

Para conseguir una buena detección del problema que requiere la acción del operador se debe

elegir correctamente el parámetro que produce la alarma. A continuación presentamos un

ejemplo vinculado a la industria de proceso:

• Alarmas absolutas. Generada por comparación del valor real de una señal analógica y un

limite de alarma definido.

• Alarmas de velocidad de cambio. Puede ser del cambio de la propia variable en una

señal analógica (indicación o controlador) o de la salida a válvula del controlador. A

menudo estas alarmas son el primer aviso de que la unidad no va bien. Sin embargo tienen

que usarse con mucho cuidado sobre todo en señales con ruido.



• Alarmas de desviación. En controladores, avisan de una desviación entre el punto de

consigna y la variable

• Alarmas de salida a válvula. Indican que el controlador no es capaz de controlar la

variable ya que ha llegado al límite de su acción sobre la válvula.

3.2.3. Selección del punto de alarma

La elección del punto de alarma es muy importante para la fiabilidad de la respuesta del

operador, para ello hay que tener en cuenta algunos factores que afectan a dicha respuesta:

− Dinámica de la planta o el proceso, amplitud y duración aceptable de las fluctuaciones

de la operación normal.

− Límites a los que actúan los sistemas de seguridad.

− Tiempo de respuesta del operador para resolver el problema que genera la alarma.

− Velocidad de cambio de la variable durante una situación especial.

Un límite de alarma definido muy próximo al punto de operación puede hacer que aparezca

de forma intermitente, lo que resta atención por parte del operador.

3.2.4. Priorización

En cualquier sistema de alarmas es extremadamente útil priorizar las alarmas, de tal forma

que en cualquier momento sea obvio para el operador qué alarmas son las más importantes.

Para definir la priorización hay que tener en cuenta tanto las consecuencias que la acción del

operador debe prevenir, como el tiempo de actuación del que dispone.

1. Alarmas relacionadas con la seguridad: si las consecuencias de no tomar acción

ante una alarma producen daños a la integridad física de las personas, de los equipos o del

medio ambiente, la alarma deberá dirigirse a un sistema de seguridad el cual, en la mayoría de

los casos, realizará de forma automática las acciones necesarias.



2. Alarmas de emergencia: son aquellas que la falta de actuación inmediata pueden

producir gran perturbación en la planta: paro de una unidad de producción o equipo

importante, gran pérdida económica o importantes desperfectos en el medio ambiente.

3. Alarmas de alta prioridad: son alarmas que producen una perturbación en el proceso

que el operador puede controlar con una actuación relativamente sencilla.

4. Alarmas de baja prioridad: son alarmas que producen una perturbación en el sistema

o subsistema que requiere la actuación del operador, aunque las consecuencias sean menores.

Existen otro tipo de avisos o mensajes que es necesario que el operador conozca, pero que no

implican una acción por parte de él. Es lo que hemos llamado Alertas.

3.2.5. Valores de referencia

En general, cuanto mayor sea el número de alarmas que haya instalado en cada puesto de

operación (manejado por un único operador), mayor será la probabilidad de problemas con

alarmas innecesarias o aleatorias, así como de sobrecarga. Por otro lado un pequeño número

de alarmas puede significar que el operador no reciba la información precisa de determinados

eventos importantes. Es necesario realizar un balance y por tanto es inevitable que un

sistema grande y complejo tenga un gran número de alarmas.

3.3. La documentación

Una documentación es una herramienta de trabajo imprescindible para operar un

sistema de control. Debe adaptarse a las diferencias de los usuarios (experiencia,

conocimientos, edad, jerarquía…) y a la heterogeneidad de contextos en los que va a ser

utilizada (criticidad, frecuencia, nocturnidad, con exigencia temporal...).

Para conseguir esta adaptación es necesario llevar a cabo una secuencia progresiva de

acciones: Trabajos Preparatorios, Definición de Contenidos, Aplicar Formatos, Aplicar la

Guía de Estilo, Redacción de la Versión 0, Validación y Preparación de la Versión 1.

Este proceso tiene el valor añadido de contribuir a identificar informaciones que pueden ser

útiles para mejorar otros ámbitos del sistema de producción: calidad, formación, seguridad,

equipamiento.



3.3.1. Trabajos preparatorios: La documentación es una herramienta de trabajo.

Es necesario entender la documentación como una verdadera ayuda para la operación en

planta. El objetivo fundamental en la elaboración de este Manual es que pueda ser realmente

utilizado por los operadores, como un elemento más de su equipamiento de trabajo.

3.3.2. Definir los contenidos

La documentación debe identificar de manera precisa a los destinatarios finales.

La identificación del colectivo de los operadores a los que va dirigido, así como su nivel de

formación, experiencia y edad, es clave para que la documentación sea comprendida y

utilizada.

La documentación debe integrar el material existente.

En primer lugar, se debe hacer un balance del estado del material existente (depuración,

actualización, utilidad práctica de sus apartados).

Una vez realizado este balance, se debe realizar una primera selección de los documentos que

van a formar parte del nuevo manual

El criterio básico que debe guiar esta selección es el de adaptarse a las personas y a los fines a

los que se dirige la documentación. Este criterio definirá el nivel de detalle, la existencia de

gráficos, las informaciones principales y las secundarias.

Es necesario identificar las necesidades de los Operadores de cada Unidad.

Esta etapa es fundamental. La primera selección sobre la documentación existente debe venir

acompañada por una definición, caracterización y jerarquización de las acciones y tareas que

se realizan en panel y campo. Es posible que este proceso identifique informaciones que no

existen en la documentación existente, pero que deben incluirse en su nueva versión

Es necesario identificar cuándo y cómo va a ser utilizado la documentación.

Los contenidos están definidos por las circunstancias en las que la documentación va a ser

utilizada. Esto definirá los criterios de selección, las características y el tipo de información



que debe contener la documentación (breve y concisa, exhaustiva, argumentativa, con

ejemplos...).

Es recomendable que esta selección se apoye en la frecuencia y criticidad potencial de las

acciones que realizan los operadores.

3.3.3. Construir y aplicar una guía de estilo

Aplicar los criterios de homogeneidad:

Cada componente de la documentación debe obedecer a un estándar básico que defina

las estructuras, el soporte, el sistema de edición, la tipografía, el vocabulario y la sintaxis

a emplear.

Aplicar los criterios de estanqueidad:

Cada componente de la documentación debe permitir al operador encontrar sin error

posible todo lo que necesita, en el momento en que lo necesita, con el nivel de detalle

que precisa, sin necesidad de buscar en otro apartado de la documentación manual u

otros materiales.

Aplicar los criterios de jerarquización:

Cada componente de la documentación debe separar de forma intuitiva y visual lo que

hay que hacer y cómo hacerlo. Para aplicar este formato es necesario tener en cuenta que

la formación y la experiencia de los operadores de campo a los que se dirige condicionan

el qué, el cómo y el dónde de estas informaciones.

Sobre todas las informaciones seleccionadas se deben aplicar estándares propuestos en

la Guía de Estilo:

- De soporte, edición y reproducción.

- De formato y estructura de la información.

- De tipografía.

- De vocabulario, abreviación y codificación.



- De sintaxis.

- De objetos gráficos, iconos y colores.

3.3.4. Redactar la Versión 0 de la documentación

Redactar siguiendo estrictamente los criterios de la Guía de Estilo. Determinadas

dificultades detectadas en el proceso de redacción pueden dar lugar a la revisión y

modificación de la Guía de Estilo.

3.3.5. Validar la Versión 0.

La principal garantía de que los operadores vayan a utilizar la documentación es su

comprensión y aceptación. Para ello, es necesario que el proceso de construcción e

introducción en sala de la documentación sea de naturaleza participativa.

Se deben elegir muestras de operadores para que el proceso de validación sea

representativo de la variedad de operadores de campo (jóvenes, mayores, expertos, con

altos y bajos niveles de formación, etc.) y situaciones en las que la documentación va a ser

utilizada.

Esta fase requiere un análisis pormenorizado del punto de vista de los operadores sobre el

formato y contenido de la documentación.

Este proceso de análisis es lento y permite identificar lagunas, problemas de formación,

informaciones ambiguas o confusas... además de otras necesidades documentales no

previstas, carencias formativas, problemas con los equipos, la seguridad.

3.3.6. Elaborar la versión 1 de la documentación

A partir de las informaciones obtenidas en el proceso de validación, se reconstruirá la

documentación para garantizar la aceptación definitiva de la documentación por parte de

los operadores.

3.3.7. Utilizar las informaciones obtenidas durante todo el proceso

En el proceso de validación con los operadores, pueden aparecer dificultades de

comprensión que no están ligadas a la documentación, sino a aspectos de la formación de

los operadores. Así mismo, este proceso puede poner de manifiesto dificultades técnicas



para realizar adecuadamente el trabajo, etc. Estas informaciones pueden ser también

recopiladas con vistas a acciones de naturaleza distinta a la documental (formativas, de

mejora de la seguridad o la calidad, etc.).

4. Redactar Versión 0

2. Definir Contenidos: Quién

A partir de qué Qué Trabajo

Cuándo y Cómo

1. Cuestiones Previas Qué fin

3. Aplicar criterios de la Guía de Estilo:

Homogéneos Estancos

Jerarquizados Estándares

5. Validar

6. Elaborar Versión 1

7. Utilizar Información

3.4. La formación de los operadores

En algunos casos, en el proceso de preparación de la puesta en marcha de una nueva

sala de control es necesario prever la formación de los operadores de control en el

nuevo sistema de control. En este periodo es necesario definir:

Los objetivos de la formación.

La población que va ser objeto de dicha formación

La organización y logística

Los métodos y medios pedagógicos.

3.4.1. Los objetivos de la formación

El objetivo de la formación deber permitir:



Que los operadores dispongan en todo momento un representación exacta y

fiable del estado del proceso para poder decidir sobre las acciones colectivas

(equipo de operación compuesto por distintos operadores) que se deben

emprender.

Que exista una articulación estructurada entre los nuevos conocimientos del

sistema y la experiencia acumulada por los operadores (en campo, en el antiguo

sistema, etc..).

Ambos objetivos deben, a su vez, permitir:

Prever la evolución de una situación a partir de la exploración y la

supervisión de parámetros “metaforizados” es sinópticos, esquemas, sistemas

de enclavamiento y sumarios de alarma.

Construir hipótesis sobre el estado del proceso a partir de esta exploración y

de la comunicación con el exterior de la sala.

Juzgar la fiabilidad de un indicador y su influencia sobre el resto de

informaciones disponibles,

Distribuir su “tiempo mental” entre distintas situaciones incidentales.

Optimizar el uso del sistema de control.

4. CONCLUSIONES

Se acaba de presentar un recorrido sumario sobre algunos de los aspectos más relevantes del

proceso de definición de una sala de control (aspectos medioambientales y físicos) y de los

elementos que afectan a la operación del sistema de control (interfaz hombre-máquina,

sistema de alarmas, documentación de operación y formación de operadores).

Nos gustaría concluir con dos problemáticas que afectan al proceso de diseño o reconcepción

de la sala de control.



4.1. La cuestión de la normativa.

La normativa nacional e internacional, que afecta directa o indirectamente al trabajo en sala,

da orientaciones lo suficientemente genéricas como para iluminar los primeros pasos de un

proyecto de este tipo. Pero, sin ninguna duda, no puede concebirse una sala de control sólo

con normativa. Algunos ejemplo:

ISO 11064-3:1999: Reducir las obstrucciones y estructuras que dificultan el trabajo.

ISO 11064-3:1999: No se recomienda dispersar las posiciones de trabajo.

ISO/DIS 11064-2:1999: Las comunicaciones extrañas a las funciones de la sala no deben

distraer al personal de la sala.

Sin embargo, de la normativa se pueden extraer grandes criterios de diseño y concepción

(ISO/DIS 11064-1:1999):

1. Aplicar un diseño centrado en el ser humano.

2. Integrar la ergonomía en la práctica de la ingeniería.

3. Mejorar el diseño hacia la interacción.

4. Analizar y evaluar un sistema existente comparable.

5. Considerar las tareas de los operadores.

6. Diseñar sistemas tolerantes ante el error.

7. Asegurarse la participación de los usuarios.

4.2. Ergonomía y proyectos industriales

La aportación del ergónomo en la concepción de una sala de control debe situarse en un

contexto bien preciso, el de la gestión de un proyecto industrial.

Uno de los principales problemas que aquejan a los proyectos de concepción o reconcepción

de una sala y en consecuencia, a los ergónomos que intervienen en estos proyectos, es que no

suelen gestionarse con los mismos criterios con los que se gestiona cualquier otro



proyecto industrial. Suele entenderse que el proyecto de remodelación o concepción de la

sala como un proyecto de orden decorativo.

Para comenzar, es necesario un verdadero director de proyecto, que oriente y canalice las

opiniones y las reuniones múltiples que suelen acompañar a este tipo de proyectos.

Desgraciadamente, estos proyectos suelen ser gestionados por comités en los que los hitos, la

secuencia de actividades y las responsabilidades del proyecto no se definen siempre con

precisión.

También es imprescindible, de manera precoz, disponer de una requisitoria exhaustiva, de

pliegos de condiciones técnicas que ordenen y sistematicen el trabajo de todos los miembros

del grupo de proyecto, sobre todo de los proveedores. En algunos casos, o se improvisa un

pliego de especificaciones técnicas cuando ya prácticamente se ha adjudicado el proyecto y

los estudios de detalle están muy avanzados.

En otros casos se elaboran los requisitos sin haber realizado una visita a situaciones

comparables, situaciones de referencia sobre las que los ergónomos identifican errores de

concepción o efectos no deseados que puedan evitarse en el proyecto de la nueva sala.

El ergónomo, después de sus análisis sobre las situaciones existentes que van a ser objeto de

modificación, o sobre las situaciones de referencia, si se trata de un proyecto constructivo de

concepción, esta armado de técnicas y métodos que permiten definir de manera precoz las

condiciones que debe cumplir la sala de control.

La definición de estas condiciones debe ayudar a que los operadores puedan realizar su

trabajo de forma segura, fiable y eficiente en un contexto de mejora de sus propias

condiciones de trabajo.



5. PARA SABER MÁS…

Amalberti, R. (1996): La conduite de systèmes à risques, Paris, PUF

Daniellou, F. (1986): L’opérateur, la vanne, l’écran. L’ergonomie des salles de contrôle, ANACT, Montrouge.

Duarte, F. (2000): Ergonomia & Projeto na industria de processo contínuo, Lucerna-COPPE/UFRJ, Rio de Janeiro.

Edward, E. y Lees, F.P. (1974): The human operator in process control, Taylor & Francis, London.

Keyser, V. de (1998): “El error humano” en Castillo, J.J. y Villena, J. (1998): Ergonomía. Conceptos y Métodos, Madrid, Editorial Complutense, pp.211-229.

Koukoulaki, T. y Boy, S. –eds. - (2003): Globalizing technical standards. Impact and challenges for occupational health and safety, Bruselas, BTS.

Lautier, F. (1999): Ergotopiques. Sur les espaces des lieux de travail, Toulouse, Octarès.

Martin, C. (2000): Maîtrise d’ouvrage. Maitrîse d’oevre. La contribution de l’ergonome à la conduite de projet architectural, Toulouse, Octarès.

Millanvoye, M. (1990): Données physiologiques et ergonomiques pour la conception du poste de travail, Paris, CNAM-Collection des Cours

Panero, J. y Zelnik, M. (1998): Las dimensiones humanas en los espacios interiores. Estándares antropométricos, Barcelona, Gustavo Pili.

Reinberg, A., Adlauer, P. y Vieux, N. (1981): Night and shiftwork, biological and social aspects, Oxford, Pergamon Press.

Villena, J. (1998): “Organización del trabajo y cognición en la sala de control” en Castillo, J.J. y Villena, J. (1998): Ergonomía. Conceptos y Métodos, Madrid, Editorial Complutense, pp.231-259.

Weil-Barais, A. (1993): L’homme cognitif, Paris, PUF

Whitfield, D. (1984): Ergonomics problems in process operations, Pergamon Press, Oxford.

Woodson, W.E. y Conover, D.W. (1978): Guide d’ergonomie. Adaptation de la machine à l’homme, Paris, Les Éditions d’Organisation

Para acceder fácilmente a la normativa y la legislación española, consultar la web del Instituto Nacional de Seguridad e Higiene en el Trabajo: http://www.mtas.es/insht



Algunas orientaciones normativas internacionales

UNE-EN-ISO 9241: Requisitos ergonómicos para trabajos de ofician con pantallas de visualización de datos.

ISO 8995:1989: Principles of visual ergonomics

ISO 11064:1999: Ergonomic design of control centres.

ISO 1996. ISO 7779: Accoustics

ISO 7726: Thermal environments

ISO 7731: Danger signals for work places – Auditory danger signals.: accoustics

Ergonomía de la Sala de Control

www.ergotec.es

ISE Madrid, 27 de Abril de 2006

Estructura de la presentación

• Introducción. El operador humano.

• Aspectos medioambientales

• Aspectos físicos y espaciales

• Aspectos lógicos y organizativos– Diálogo H-M y alarmas.

– Documentación de Operación.

• Gestión del proyecto de concepción de la sala.

® 2006 Ergonomía Organización Tecnología

El operador humano, alta tecnología biológica


• Condiciones ambientales de uso: 21º, <60 dBA, >400 lx. En otras condiciones este producto no es fiable.

• No fuerce sus aparatos visuales y auditivos, son frágiles y se averían con facilidad. Facilite la recuperación muscular.

• La materia prima del operador es cronobiológica. No ha sido diseñado para trabajar de noche. Se fatiga fácilmente y se equivoca.

• El operador humano integra el mejor motor biológico de inferencia informativa conocido y una potente base de datos que integra la experiencia, por lo que es capaz de crear soluciones originales. No ha sido diseñado para trabajar en tareas monótonas y repetitivas. Utilice ordenadores y motores mecánicos para este tipo de tareas.

• Este producto es del género social, afectivo e inteligente.Necesita comunicarse. Este producto necesita un periodo de adaptación. Intégrelo en un grupo y fórmelo cuidadosamente.

• El operador humano tiene ideas propias, necesita la seguridad y el reconocimiento profesional.

Introducción

• La sala de control: de la industria a las telecomunicaciones.... Aspectos transversales

• Dificultades. Alcance. Interdisciplinariedad. ISO 11064• Alcance de la ergonomía: ¿la luz y la silla?

• ¿Todavía se quejan los operadores?

• ¿Qué es una buena sala de control?

• Criterios funcionales y estéticos.• La función de la sala de control y el trabajo de

supervisión: ayudar a anticipar la disfunción.


Aspectos medioambientales

• El “riesgo” en la sala.

• La concentración del panelista.

• El aparato visual y auditivo, expresiones de la fatiga y error.

• Esfuerzo físico y termorregulación.

• La normativa general.

• Condiciones de trabajo y calidad de operación.


Aspectos físicos y espaciales (I)

• La posición y las posiciones en el espacio.

• Espacio, gestión de la información y concepción de la posición de control.

• El proveedor, la normativa y las necesidades contextuales: consultar, escribir, comunicarse... vivir en la sala.

• ¿Para quién se concibe la posición de control?• Usuarios con necesidades distintas. Identificar las

necesidades contextuales de operación.


Aspectos físicos y espaciales (III)

• El espacio común para el trabajo colectivo.• Las tentaciones de la simetría.• Algunas cuestiones que se deben formular

para definir el paisaje de la sala:– Relaciones funcionales y comunicativas. – Desplazamientos, ciclos de la tarea.– El horizonte visual y auditivo.– La estética y Cabo Cañaveral.

• Definir el tránsito de las personas. Señalética, orientación e interrupción..


Aspectos físicos y espaciales (IV)

• El espacio común para el trabajo colectivo.• Crecimiento de la sala. • El edificio de control.

– Salas de descanso.– Vestuario, relevo y

comunicación: Panelistas y operadores de campo.

– Técnicos y operadores• El necesario equilibrio.


Aspectos lógicos. HMIs (I)

• El diálogo hombre-máquina.• Las quejas de los operadores tras la

reconcepción. • Iluminación, información y gestión del

proceso: de nuevo el trabajo de control• El trabajo real y la representación de la

información.• El ergónomo ayuda a poner a punto

tecnologías compatibles con el cerebro.


Aspectos lógicos. HMIs (II)

• Color, esquemas, sistemas de alarma y advertencia: la lógica de concepción... y la lógica de operación .

• El espacio lógico de la posición de control. • La relación entre los aspectos físicos y los aspectos lógicos: La

posición FOCUCSConsole

Input Devices(e.g., Keyboard)

Workstation

Monitors(Hardware)

Displays/Views

B

DF2

V

R

QR

LB

Rebo ile r

F1

P2

Condense r

P1

Re ce i ver

Q C

L R

B

DF2

V

R

Q R

LB

R e boi l er

F1

P2

C onde ns er

P1

R ece ive r

Q C

LR

B

DF

2

V

R

Q R

LB

R e b o il e r

F1

P2

C o n d e ns e r

P 1

R e c e iv e r

Q C

L R

D em e t h a ni z e r

S t ate V a ria bl e X

K ey T a g s {f o r St at e V a ri ab l e X }

P r es s ur eB ala n ce

T ra y T e m pF un c tio nC o nd e ns e r

Fu n c tio n

R eb o ile r

Fu n c tio n

S ep a ra ti on

F u nc t io n

U - 04 D e m e th a n iz er

M a s s

B ala n ce

T r ay M i xF u nc t io n

C o n d e n s e r

Fu nction

H e a t S i n k

Fu n c t io n

H e a t S o u r c e

F u n c t io n

R e b o il e r

F uncti on

C o n d L v l

F u n c ti o n

H e a t T ra n s f e r

F u n c tio n

P re s s u r e

Balan ceM a s s

Bal ance

T r a y _ Te m p

F u n cti o n

Se pa rat ionF u n c t io n

T r a y _ M ix

F u n c ti o n

C o n d e n s e r

Funct ion

H e a t S in k

F u n c ti o n

H ea t S o u rc e

F u n c ti o n

R eb o ile r

Funct ion

C o n d L v l

F u n c t io n

H e a t T r a n s f er

F u n c t io n

P r e s s u re

B alance

M a s s

B a la n c e

T r a y _ T e m p

F u n c t io n

Separ ati on

F u n c ti o n

T ra y_ M ix

F u n c t io n

B

DF 2

V

R

Q R

LB

R eb o il e r

F 1

P 2

C o n d e n se r

P1

R e c e iv e r

QC

LR

De m et h a n i ze r

S t a t e V a ri a b l e X

K e y T a g s {f o r S t at e V a ri a b le X }

P re ss u re

B al an c e

T r ay T e m p

F u nc ti onC o n de n se r

F u nc tio n

R e bo il er

F u nc tio n

S e pa r at ionFu n c tio n

U -0 4 D em et ha n iz e r

M as s

B al an c e

Tr a y M ix

Fu n c tio n

C o n d e n s e r

Functi on

H e a t S in k

Fu n ct io n

H e a t S o u rc e

F u n c ti on

R e b o i le r

Functi on

C o n d L v l

F u n c t io n

H e a t T r a n s fe r

F u n c ti o n

P r e s s ur e

Bal ance

M a s s

Ba lance

T ra y _ Te m p

F u n cti o n

S epara tionF u n c ti on

T ra y _ M ix

F u n c ti o n

C o n d e n s e r

Funct ion

H e a t S in k

F u n c t io n

H e a t S o u r c e

F u n c t io n

R e b o il e r

Fun ct ion

C o n d L v l

F u n c ti on


F u n c t io n

P re s s u r e

Balance

M a ss

B a la n c e

T r a y _ T e m p

F u n c ti on

Separ at ionF u n c t io n

T r a y _ Mi x

F u n c tio n

02:33:33 Reactor in Plant 1 Highf02:33:33 Pump failure High02:33:33 Valve closed High02:33:33 Ves sel leak Alert02:33:33 Pimp 3d low flow Warning

02:33:33 Reactor in Plant 1 Highf02:33:33 Pump failure High02:33:33 Valve closed High02:33:33 Vessel leak Alert02:33:33 Pimp 3d low flow Warning


Mandamientos del diálogo H-M• ISO 9241. ASM. INRIA. WWW. • 1. Orientación

Ayudar al operador a establecer relaciones causales, mediante:– Incitación: wysiwyg, navegabilidad, baja memorización. › Ejemplos:

Es posible navegar sin recordar códigos u secuencias de órdenes para obtener una información. Desarrollar teclas dedicadas o funcionales, sistemas de pestañas o iconos que permitan accesos directos a las funciones más utilizadas. Facilitar la llegada “rápida” de la información (≤ 2/3 ss.).El uso del color deber de ser consistente, jerarquizado: el color es una información que deber ser redundante con otros elementos informativos.

› El rojo y los estereotipo culturales. Los parpadeos

Mandamientos del diálogo H-M– Agrupamiento: Mediante la localización y el

formato se deber agrupar aquello que mantenga una relación.

› Ejemplo: La estructura jerárquica de navegación debe de ser siempre la misma (Overview, nivel primario, nivel secundario, detalle).

Site

Plant 1 Plant 2Plants

ProcessSection

IndividualEquipment

Pumps 1-10A Pumps 1-5A Compressor 122 Tank 333Valve 14-214 Valve 23-111 Valves 23-4A Valves 33-36B

Section A Section B Section C Section D

EntireSite

Mandamientos del diálogo H-M– Retroalimentación: la aplicación siempre

“responde”.› Ejemplo: La aplicación deber “refrescarse” con la

mayor rapidez para ofrecer la operador la posibilidad de diagnosticar e intervenir de forma eficiente: no más de ½ segundo.

– Legibilidad: Lo que se presenta puede leerse.› Ejemplo: Uso moderado del color para permitir el

contraste. No dar mucho detalle en el dibujo de equipos (saturación), “esconder” determinadas informaciones (TAGs). Cuidado con el tamaño de los caracteres (ojo-pantalla)

Mandamientos del diálogo H-M• 2. Carga de Trabajo

Se trata de minimizar el esfuerzo de interacción, mediante:– Brevedad: Concisión, acciones mínimas.› Ejemplo: Es recomendable el uso de modos de

designación que faciliten los atajos y la construcción de modos operativos personalizados (botón derecho, táctiles, etc..).

Mandamientos del diálogo H-M

– Densidad: Cantidad y complejidad de la información tratada.› Ejemplo: Los trenes gráficos (“trends”) son más efectivos y

menos costosos que las tablas alfanuméricas para realizar diagnósticos. Deben poder configurarse los parámetros.

43.444.647.445.050.051.045.647.050.049.951.052.049.053.049.953.2

12345678910111213141516

Process Variable vs. Time

30

40

50

60

1 3 5 7 9 11 13 15

Tim e (m in)

Proce s sVar iable

Numbers Trends

Easier to perceive directionand rate of change.

Easier to extract exact #s.


• 3. Adaptabilidad La aplicación se debe ajustar al contexto preferencias del usuario, mediante:– Flexibilidad, adaptación al proceso de aprendizaje para los

debutantes y la interacción avanzada para el experto.Overview

Level 2(Primary)

Level 3(Secondary)

Unit A Unit B

Level 1

Section 1A Section 2A Section 1B Section 2B

Level 4(Details) Details Details Details Details

Shortcut


Mandamientos del diálogo H-M– Experiencia, adaptación al nivel de conocimiento.› Ejemplo: Toda aplicación de control debe ofrecer un

overview, una visión de conjunto y, al mismo tiempo, informaciones detalladas para el experto. Estas vistas deben poderse ofrecer, al mismo tiempo, en distintas pantallas de la consola o posición de control. Para las funciones que se usan muy poco deben de existir ayudas (¿on line?).


Mandamientos del diálogo H-M• 4. Gestión del Error

Medios para prevenir, reducir o corregir los errores, mediante:– Protección, detectar y anticipar los errores.› Ejemplo: Los equipos elementos idénticos se deber

representar de modo idénticos, pero deben disponer de códigos (p.e. Alfanuméricos) que los permitan distinguirlos. Cuidado con la proximidad en el interfaz y con las teclas táctiles excesivamente pequeñas.

– Calidad de los mensajes› Ejemplo: Los mensajes deber facilitar la interpretación y el

diagnóstico, evitar equívocos o incomprensiones. Ofrecer datos (números) si ello mejora la calidad de la información.

– Corrección: UNDO® 2006 Ergonomía Organización Tecnología

• 5. HomogeneidadAusencia de excepciones, la aplicación se comporta siempre de la misma manera.



• 6. Significatividad Fuerte relación semántica entre la denominación y su referente (sinópticos, iconos, símbolos...).› Ejemplo: El layout del display debe mantener fuerte

coherencia con el proceso. Esto no quiere decir que sea un calco de la planta, sino que debe ser consistente: orientación de las corrientes, ubicación prioritaria de los equipos importantes. Los símbolos debe ser comprensibles y, a ser posibles, estandarizados.

• 7. CompatibilidadNivel de adaptación a las características del trabajo de los usuarios.› Ejemplo: Crear displays específico para intervenir en

determinadas condiciones críticas (p.e. Puesta en marcha o Parada de emergencia, que incluye un miniprocedimiento, los principales equipos que se deben supervisar...)... Esto es también válido para las condiciones rutinarias de operación



• Una alarma debe ser relevante, única, oportuna, entendible y permitir la acción correctiva.

• Tipos de alarma: absoluta, de desviación del punto de consigna...• Selección del punto de alarma...• Priorización: seguridad, emergencia, alta prioridad, baja prioridad.• Necesidad de realizar un balance, aunque los sistemas complejos

tienen un gran número de alarmas.• Los operadores deben disponer de guías explicativas (en pantalla,

en documentos) que describan detalladamente el sentido de una alarma. En cualquier caso, se debe de realizar un esfuerzo para que los mensajes sean comprensibles y significativos para el operador,

• Umbrales de audición y alarmas. Discriminación por puesto/consola. Molestias y desactivación temporal. Redundancias.

Diálogo H-M: sistemas de alarma y de advertencia.


Un ejemplo

Alarma reconocida

El estado de lasalarmas se muestra con iconos y colores

Alarma no reconocida (rojo brillante)

Bomba en manual

Fuente; ASM® 2006 Ergonomía Organización Tecnología

Diálogo H-M: ubicación informaciones visuales críticas.

• Alarmas visuales y ubicación idónea de las informaciones visuales de alarma:


Aspectos organizativos

• Organización del trabajo y concepción de la sala, cuatro cuestiones abiertas:– La certificación de operadores: formación,

adiestramiento, instrucción.– La sala como espacio para mantener y gestionar el

conocimiento. La simulación.– La representación viva de la instalación: el operador de

sala y el rack.– Los operadores exteriores y la sala: reducción

de efectivos y aprendizaje informal.– Cualificación, rareza y gravedad

de los incidentes: ¿cómo mantener el oficio?– Documentación.


La documentación



2. Definir Contenidos:Quién

A partir de quéQué Trabajo

Cuándo y Cómo

1. Cuestiones PreviasQué fin


HomogéneosEstancos

JerarquizadosEstándares

5. Validar

6. Elaborar Versión 1


1. Cuestiones previas.

La d

ocum

enta

ción

• ¿Qué fin persigue la documentación?.

2. Definir los contenidos.• ¿Quién es el destinatario?• ¿De qué material documental se dispone?• ¿En qué consiste el trabajo de los destinatarios?• ¿Dónde realizan su trabajo?• ¿Cuándo realizan el trabajo?

3. Definir los formatos.• Establecer los criterios

– De homogeneidad.– De estanqueidad.– De jerarquización.

4. Elaborar la Guía de Estilo• Establecer...

– Los criterios de soporte, edición y reproducción.– De formato y estructura de la información.– De tipografía.– De vocabulario, abreviatura y codificación.– De sintaxis.– De objetos gráficos, iconos y colores.

La d

ocum

enta

ción

• Criterios de la Guía de Estilo: proceso de evaluación y mejora.

5. Redactar la versión 0.

• Elección de muestras de población y de situaciones.• Aparición de otras informaciones...

6. Validar la documentación.

7. Elaborar la Versión 1.

8. Utilizar las informaciones.

• Otros aspectos...

• La normativa y el proceso de concepción.

• La gestión del proyecto de la sala.– ¿El proyecto de concepción es un proyecto?

• Dirección, comités, requisitoria.– El análisis de situaciones existentes y de

situaciones de referencia.– La construcción precoz de

requisitos técnicos de ergonomía.• Un objetivo: el equilibrio entre la seguridad,

la fiabilidad y las condiciones de trabajo.

Gestión de Proyecto


Gracias por su atención


www.ergotec.es

Sección Española

Ergonomía de laErgonomía de la sala de control

Jesús Villena LópezJesús Villena LópezErgotec

[email protected]

Sección Española

Estructura de la presentaciónIntroducción:El operador humano y la sala de controlEl operador humano y la sala de controlConcepción de la sala:• Aspectos medioambientales

• Aspectos físicos y espaciales

• Aspectos lógicos y organizativos• Diálogo H-M y alarmas.

• Documentación de OperaciónDocumentación de Operación.

• Gestión del proyecto de concepción de la sala.

Tema 2

El operador humano, Sección Española alta tecnología biológica

Condiciones ambientales de uso: 21º, <60 dBA, >400 lx. En , ,otras condiciones este producto no es fiable. No fuerce sus aparatos visuales y auditivos, son frágiles y se averían con facilidad. Facilite la recuperación muscular.La materia prima del operador es cronobiológica. No ha sido diseñado para trabajar de noche. Se fatiga fácilmente y se equivoca.El d h i t l j t bi ló i dEl operador humano integra el mejor motor biológico de inferencia informativa conocido y una potente base de datos que integra la experiencia, por lo que es capaz de crear soluciones originales. No ha sido diseñado para trabajar ensoluciones originales. No ha sido diseñado para trabajar en tareas monótonas y repetitivas. Utilice ordenadores y motores mecánicos para este tipo de tareas.Este producto es del género social, afectivo e inteligente. g gNecesita comunicarse. Este producto necesita un periodo de adaptación. Intégrelo en un grupo y fórmelo cuidadosamente.El operador humano tiene ideas propias necesita la

Tema 2

El operador humano tiene ideas propias, necesita la seguridad y el reconocimiento profesional.

El d l lSección Española

Evolución tecnológica: El operador y la sala

• Concentración de las informaciones en un único espacio vs. la intervención sobre la instalación.A t d l i t d l ió t áti l• Aumento de los sistemas de regulación automáticos, lo que modifica su papel.

• Aumento de la complejidad de los procesos y de susAumento de la complejidad de los procesos y de sus incidentes.

Consecuencias:• Mejora de las condiciones físicas. Aparece la abstracción y el

trabajo “mental”. Problemática de al calidad de la t iórepresentación.

• Reducción del número de operadores y de su organización en sala y campo

Tema 2

sala y campo.• Menos incidentes y accidentes, más graves.

Sección Española

L l d t l d l i d t i l

Concebir la sala: introducciónLa sala de control: de la industria a las telecomunicaciones.... Aspectos transversalesAspectos transversalesDificultades. Alcance. Interdisciplinariedad. ISO 1106411064Alcance de la ergonomía: ¿la luz y la silla?¿Todavía se quejan los operadores?¿Qué es una buena sala de control?¿Criterios funcionales y estéticos.La función de la sala de control y el trabajo de

Tema 2

La función de la sala de control y el trabajo de supervisión: ayudar a anticipar la disfunción.

A t di bi t lSección Española Aspectos medioambientales

El “riesgo” en la sala.La concentración del panelista.La concentración del panelista.El aparato visual y auditivo, expresiones de la fatiga y errorfatiga y error.Esfuerzo físico y termorregulación.La normativa general.Condiciones de trabajo y calidad de operación.

Tema 2

A t fí i i l (I)Sección Española Aspectos físicos y espaciales (I)

La posición y las posiciones en el espacio.Espacio, gestión de la información y concepción p g y pde la posición de control.El proveedor, la normativa y las necesidadesEl proveedor, la normativa y las necesidades contextuales: consultar, escribir, comunicarse... vivir en la salavivir en la sala.¿Para quién se concibe la posición de control?Us arios con necesidades distintas IdentificarUsuarios con necesidades distintas. Identificar las necesidades contextuales de operación.

Tema 2

Sección Española

Aspectos físicos y espaciales (III)El espacio común para el trabajo colectivo.Las tentaciones de la simetríaLas tentaciones de la simetría.Algunas cuestiones que se deben formular para definir el paisaje de la sala:para definir el paisaje de la sala:• Relaciones funcionales y comunicativas. • Desplazamientos, ciclos de la tarea.Desplazamientos, ciclos de la tarea.• El horizonte visual y auditivo.• La estética y Cabo CañaveralLa estética y Cabo Cañaveral.

Definir el tránsito de las personas. Señalética, orientación e interrupción..

Tema 2

p

Sección Española

Aspectos físicos y espaciales (IV)El espacio común para el trabajo colectivo.Crecimiento de la sala. El edificio de control.• Salas de descanso.• Vestuario, relevo y

comunicación: Panelistas y operadores de campo.

• Técnicos y operadoresEl necesario equilibrio.

Tema 2

Sección Española Aspectos lógicos. HMIs (I)El diálogo hombre-máquina.Las quejas de los operadores tras la

ióreconcepción. Iluminación, información y gestión del proceso: de nuevo el trabajo de controlproceso: de nuevo el trabajo de controlEl trabajo real y la representación de la información del proceso: realista funcionalinformación del proceso: realista, funcional, abstracta.El ergónomo ayuda a poner a punto g y p ptecnologías compatibles con el cerebro.

Tema 2

A t ló i HMI (II)Sección Española Aspectos lógicos. HMIs (II)

Color, esquemas, sistemas de alarma y advertencia: la lógica de concepción...

l ló i d ióy la lógica de operación .El espacio lógico de la posición de control. L l ió t l t fí i l t ló iLa relación entre los aspectos físicos y los aspectos lógicos: La posición FOCUCS

ConsoleMonitors

(Hardware)

C o n d e n s e r

Fu nction

H e a t S i n k

Fu n c t io n

H e a t S o u r c e

F u n c t io n

R e b o il e r

F uncti on

C o n d L v l

F u n c ti o n


F u n c tio n

P re s s u r e

Balan ceM a s s

Bal ance

T r a y _ Te m p

F u n cti o n

Se pa rat ionF u n c t io n

T r a y _ M ix

F u n c ti o n

C o n d e n s e r

Funct ion

H e a t S in k

F u n c ti o n

H ea t S o u rc e

F u n c ti o n

R eb o ile r

Funct ion

C o n d L v l

F u n c t io n

H e a t T r a n s f er

F u n c t io n

P r e s s u re

B alance

M a s s

B a la n c e

T r a y _ T e m p

F u n c t io n

Separ ati on

F u n c ti o n

T ra y_ M ix

F u n c t io n

C o n d e n s e r

Functi on

H e a t S in k

Fu n ct io n

H e a t S o u rc e

F u n c ti on

R e b o i le r

Functi on

C o n d L v l

F u n c t io n

H e a t T r a n s fe r

F u n c ti o n

P r e s s ur e

Bal ance

M a s s

Ba lance

T ra y _ Te m p

F u n cti o n

S epara tionF u n c ti on

T ra y _ M ix

F u n c ti o n

C o n d e n s e r

Funct ion

H e a t S in k

F u n c t io n

H e a t S o u r c e

F u n c t io n

R e b o il e r

Fun ct ion

C o n d L v l

F u n c ti on


F u n c t io n

P re s s u r e

Balance

M a ss

B a la n c e

T r a y _ T e m p

F u n c ti on

Separ at ionF u n c t io n

T r a y _ Mi x

F u n c tio n

02:33:33 Reactor in Plant 1 Highf02:33:33 Pump failure High02:33:33 Valve closed High02:33:33 Ves sel leak Alert02:33:33 Pimp 3d low flow Warning

02:33:33 Reactor in Plant 1 Highf02:33:33 Pump failure High02:33:33 Valve closed High02:33:33 Vessel leak Alert02:33:33 Pimp 3d low flow Warning

Input Devices(e g Keyboard)

B

DF2

V

R

QR

LB

Rebo ile r

F1

P2

Condense r

P1

Re ce i ver

Q C

L R

B

DF2

V

R

Q R

LB

R e boi l er

F1

P2

C onde ns er

P1

R ece ive r

Q C

LR

B

DF

2

V

R

Q R

LB

R e b o il e r

F1

P2

C o n d e ns e r

P 1

R e c e iv e r

Q C

L R

D em e t h a ni z e r

S t ate V a ria bl e X

K ey T a g s {f o r St at e V a ri ab l e X }

P r es s ur eB ala n ce

T ra y T e m pF un c tio nC o nd e ns e r

Fu n c tio n

R eb o ile r

Fu n c tio n

S ep a ra ti on

F u nc t io n

U - 04 D e m e th a n iz er

M a s s

B ala n ce

T r ay M i xF u nc t io n

B

DF 2

V

R

Q R

LB

R eb o il e r

F 1

P 2

C o n d e n se r

P1

R e c e iv e r

QC

LR

De m et h a n i ze r

S t a t e V a ri a b l e X

K e y T a g s {f o r S t at e V a ri a b le X }

P re ss u re

B al an c e

T r ay T e m p

F u nc ti onC o n de n se r

F u nc tio n

R e bo il er

F u nc tio n

S e pa r at ionFu n c tio n

U -0 4 D em et ha n iz e r

M as s

B al an c e

Tr a y M ix

Fu n c tio n

Tema 2

(e.g., Keyboard)

Workstation Displays/Views

Sección Española

ISO 9241 ASM INRIA WWW

Mandamientos del diálogo H-MISO 9241. ASM. INRIA. WWW. 1. OrientaciónAyudar al operador a establecer relaciones y pcausales, mediante:• Incitación: wysiwyg, navegabilidad, baja memorización. › Ejemplos:› Ejemplos:

Es posible navegar sin recordar códigos u secuencias de órdenes para obtener una información. Desarrollar teclas dedicadas o funcionales, sistemas de

t ñ i it di t lpestañas o iconos que permitan accesos directos a las funciones más utilizadas. Facilitar la llegada “rápida” de la información (≤ 2/3 ss.).El uso del color deber de ser consistente jerarquizado: elEl uso del color deber de ser consistente, jerarquizado: el color es una información que deber ser redundante con otros elementos informativos.

› El rojo y los estereotipo culturales. Los parpadeos

Tema 2

j y p p p

Sección Española Mandamientos del diálogo H-M• Agrupamiento: Mediante la localización y el

formato se deber agrupar aquello que mantenga una relaciónuna relación.

› Ejemplo: La estructura jerárquica de navegación debe de ser siempre la misma (Overview niveldebe de ser siempre la misma (Overview, nivel primario, nivel secundario, detalle).

SiteEntireSit

Plant 1 Plant 2Plants

Site

ProcessSection

IndividualE i t

Pumps 1-10A Pumps 1-5A Compressor 122 Tank 333V l 14 214 V l 23 111 V l 23 4A V l 33 36B

Section A Section B Section C Section D

Tema 2

Equipment Valve 14-214 Valve 23-111 Valves 23-4A Valves 33-36B

Sección Española Mandamientos del diálogo H-M• Retroalimentación: la aplicación siempre

“responde”.› Ejemplo: La aplicación deber “refrescarse” con la› Ejemplo: La aplicación deber refrescarse con la

mayor rapidez para ofrecer la operador la posibilidad de diagnosticar e intervenir de forma eficiente: no más de ½ segundo.

• Legibilidad: Lo que se presenta puede leerse.Ej l U d d d l l iti l› Ejemplo: Uso moderado del color para permitir el contraste. No dar mucho detalle en el dibujo de equipos (saturación), “esconder” determinadas q p ( ),informaciones (TAGs). Cuidado con el tamaño de los caracteres (ojo-pantalla)

Tema 2

Sección Española Mandamientos del diálogo H-M

2. Carga de Trabajo Se trata de minimizar el esfuerzo de interacción, mediante:• Brevedad: Concisión, acciones mínimas.› Ejemplo: Es recomendable el uso de modos de

designación que faciliten los atajos y la t ió d d ti li dconstrucción de modos operativos personalizados

(botón derecho, táctiles, etc..).

Tema 2


• Densidad: Cantidad y complejidad de la información tratada.› Ejemplo: Los trenes gráficos (“trends”) son más efectivos y› Ejemplo: Los trenes gráficos ( trends ) son más efectivos y

menos costosos que las tablas alfanuméricas para realizar diagnósticos. Deben poder configurarse los parámetros.

43.41 Process Variable vs. Time

Numbers Trends

44.647.445.050.051.045.647 0

2345678

50

60

Proce s sVar iable

47.050.049.951.052.049.053.0

891011121314

40

Easier to perceive directionand rate of change.

Tema 2

49.953.2

1516 30

1 3 5 7 9 11 13 15

Tim e (m in)Easier to extract exact #s.


3. Adaptabilidad La aplicación se debe ajustar al contexto p jpreferencias del usuario, mediante:• Flexibilidad, adaptación al proceso de aprendizaje para los

d b l i ió d ldebutantes y la interacción avanzada para el experto.OverviewLevel 1

Shortcut

Level 2(Primary) Unit A Unit B

Shortcut

Level 3(Secondary) Section 1A Section 2A Section 1B Section 2B

Tema 2

Level 4(Details) Details Details Details Details

Sección Española

• Experiencia, adaptación al nivel de conocimiento.

Mandamientos del diálogo H-Mp , p

› Ejemplo: Toda aplicación de control debe ofrecer un overview, una visión de conjunto y, al mismo tiempo, informaciones detalladas para el experto Estas vistas debeninformaciones detalladas para el experto. Estas vistas deben poderse ofrecer, al mismo tiempo, en distintas pantallas de la consola o posición de control. Para las funciones que se usan

d b d i ti d ( li ?)muy poco deben de existir ayudas (¿on line?).

Tema 2

Sección Española

4 G tió d l E

Mandamientos del diálogo H-M4. Gestión del ErrorMedios para prevenir, reducir o corregir los errores mediante:errores, mediante:• Protección, detectar y anticipar los errores.› Ejemplo: Los equipos elementos idénticos se deber

representar de modo idénticos, pero deben disponer de códigos (p.e. Alfanuméricos) que los permitan distinguirlos. Cuidado con la proximidad en el interfaz y con las teclasCuidado con la proximidad en el interfaz y con las teclas táctiles excesivamente pequeñas.

• Calidad de los mensajesEj l L j d b f ili l i ió l› Ejemplo: Los mensajes deber facilitar la interpretación y el diagnóstico, evitar equívocos o incomprensiones. Ofrecer datos (números) si ello mejora la calidad de la información.

Tema 2

• Corrección: UNDO


5. Homogeneidad Ausencia de excepciones laAusencia de excepciones, la aplicación se comporta siempre de la misma maneramisma manera.

Tema 2

Sección Española Mandamientos del diálogo H-M6. Significatividad Fuerte relación semántica entre la denominación y su referente (sinópticos, iconos, símbolos...).› Ejemplo: El layout del display debe mantener fuerte

coherencia con el proceso. Esto no quiere decir que sea un calco de la planta, sino que debe ser consistente: orientación de las corrientes, ubicación prioritaria de los , pequipos importantes. Los símbolos debe ser comprensibles y, a ser posibles, estandarizados.

7. Compatibilidad Nivel de adaptación a las características del trabajoNivel de adaptación a las características del trabajo de los usuarios.› Ejemplo: Crear displays específico para intervenir en

determinadas condiciones críticas (p.e. Puesta en marcha odeterminadas condiciones críticas (p.e. Puesta en marcha o Parada de emergencia, que incluye un miniprocedimiento, los principales equipos que se deben supervisar...)... Esto es también válido para las condiciones rutinarias de operación

Tema 2

operación

Sección Española

Representación del proceso:

Diálogo H-M: los sinópticosRepresentación del proceso:

• Realista: se conservan fuertes semejanzas con la instalación. La más conocida.

• Funcional: la estructura guarda relación con las tareas de operaciónFuncional: la estructura guarda relación con las tareas de operación. Pocas operaciones muy rutinarias

• Abstracta: orientada a los fines no guarda relación con el modelo físico. Navegación Aérea.

Definición del sinóptico:• Definir el grado de realismo.• Filosofía de presentación: información constante y rígida, multiventanas,

t id ló i é i i bólicontenidos analógicos, numéricos o simbólicos• Navegación entre las vistas parciales.• Densidad de la información por pantalla o ventana.• Paralelismo: ¿qué tareas necesitas de vistas simultáneas?• Paralelismo: ¿qué tareas necesitas de vistas simultáneas?• Vocabulario y abreviación. Iconografía. Estereotipos-• Semántica rigurosa del color. Tipografías.

Tema 2

Diálogo H-M: sistemas deSección Española Diálogo H-M: sistemas de alarma y de advertencia.

Una alarma debe ser relevante, única, oportuna, entendible y permitir la acción correctiva.Ti d l b l t d d i ió d l t dTipos de alarma: absoluta, de desviación del punto de consigna...Selección del punto de alarma...Priorización: seguridad emergencia alta prioridad bajaPriorización: seguridad, emergencia, alta prioridad, baja prioridad.Necesidad de realizar un balance, aunque los sistemas complejos tienen un gran número de alarmascomplejos tienen un gran número de alarmas.Los operadores deben disponer de guías explicativas (en pantalla, en documentos) que describan detalladamente el sentido de una alarma. En cualquier caso, se debe de realizar un q ,esfuerzo para que los mensajes sean comprensibles y significativos para el operador,Umbrales de audición y alarmas. Discriminación por

Tema 2

puesto/consola. Molestias y desactivación temporal. Redundancias.

Sección Española Un ejemplo

Alarma

El estado de lasalarmas se muestra

con iconos y colores

reconocida

Alarma no reconocida (rojo brillante)

Bomba en manual

Tema 2Fuente; ASM

Diálogo H-M: ubicaciónSección Española Diálogo H-M: ubicación informaciones visuales críticas.

Alarmas visuales y ubicación idónea de las informaciones visuales de alarma:las informaciones visuales de alarma:

Tema 2

A t i tiSección Española Aspectos organizativos

Organización del trabajo y concepción de la sala, cuatro cuestiones abiertas:• La certificación de operadores: formación,La certificación de operadores: formación,

adiestramiento, instrucción.• La sala como espacio para mantener y gestionar el

i i t L i l ióconocimiento. La simulación.• La representación viva de la instalación: el operador de

sala y el rack.y• Los operadores exteriores y la sala: reducción

de efectivos y aprendizaje informal.Cualificación rareza y gravedad• Cualificación, rareza y gravedad de los incidentes: ¿cómo mantener el oficio?

• Documentación.

Tema 2

L d t ióSección Española La documentación

1. Cuestiones PreviasQué fin

2. Definir Contenidos:Quién

A partir de quéQué Trabajo


jCuándo y Cómo6. Elaborar

Versión 1



Homogéneos

5. Validar

Versión 0 HomogéneosEstancos

JerarquizadosEstándares

Tema 2

Sección Española

1. Cuestiones previas.ón

• ¿Qué fin persigue la documentación?.

men

taci

2. Definir los contenidos.

docu

m

• ¿Quién es el destinatario?• ¿De qué material documental se dispone?

La ¿ q p

• ¿En qué consiste el trabajo de los destinatarios?• ¿Dónde realizan su trabajo?• ¿Cuándo realizan el trabajo?

Tema 2

3. Definir los formatos.Sección Española

• Establecer los criterios – De homogeneidad.– De estanqueidad.

D j i ió– De jerarquización.

4. Elaborar la Guía de EstiloE t bl• Establecer...

– Los criterios de soporte, edición y reproducción.– De formato y estructura de la información.– De tipografía.

De vocabulario abreviatura y codificación– De vocabulario, abreviatura y codificación.– De sintaxis.– De objetos gráficos, iconos y colores.

Tema 2

5 Redactar la versión 0Sección Española

• Criterios de la Guía de Estilo: d l ió j

5. Redactar la versión 0.ci

ón

proceso de evaluación y mejora.

6 Validar la documentación

men

tac

• Elección de muestras de población y de situaciones.• Aparición de otras informaciones

6. Validar la documentación.

docu

m • Aparición de otras informaciones...

7 El b l V ió 1

La d 7. Elaborar la Versión 1.

8 Utili l i f i8. Utilizar las informaciones.

Tema 2

G tió d P tSección Española

Otros aspectos...

Gestión de ProyectoOtros aspectos...La normativa y el proceso de concepción.L tió d l t d l lLa gestión del proyecto de la sala.• ¿El proyecto de concepción es un proyecto?

• Dirección, comités, requisitoria.• El análisis de situaciones existentes y de

it i d f isituaciones de referencia.• La construcción precoz de

requisitos técnicos de ergonomíarequisitos técnicos de ergonomía.Un objetivo: el equilibrio entre la seguridad, la fiabilidad y las condiciones de trabajo

Tema 2

la fiabilidad y las condiciones de trabajo.

www.ergotec.es

Sección Española

Gracias por su atención

Tema 2

1

Sección Española


PLCPLC

Manuel Lázaro Gallardo

Módulo 7Sistemas de Control

2

Sección Española

Master de Instrumentación y Control Módulo 7 PLCs

PLC

Aspectos generales e históricos• Definición• Aparición de los PLCs

• Evoluvión de los primeros PLCs• Flujo de trabajo en producción• Tipos de industrias• Aplicaciones

Estructura del PLC• Bastidor• Fuente de alimentación• CPU• Tarjetas de entrada / salida• Procesadores de comunicaciones

2

3

Sección Española


PLC

Comunicaciones• Tipos• Ejemplos de comunicaciones• Periferia descentralizada

• Medio físico

Lenguajes de programación• Lenguajes clásicos• Lenguajes de alto nivel• Librerías

4

Sección Española


PLC

Visualización• Fuciones del Scada• Sistemas Scada• Escalabilidad• Paneles de operador• Plataforma HMI / MES / ERP

Arquitecturas• Arquitectura general• Ejemplo de configuración (ESD)

• Entradas digitales• Entradass analógicas y salidas digitales• Resumen de señales

3

5

Sección Española


PLC

Evolución de los sistemas basados en PLC• Tendencias• Consecuencias en la automatización• Entorno global

Sección Española


Aspectos generalesAspectos generales

4

7

Sección Española


Definición

PLC (Controlador Lógico Programable) o autómata programable es toda máquina electrónica, diseñada para controlar en tiempo real y en medio industrial procesos secuenciales. Realiza funciones lógicas: series, paralelos, temporizaciones, contajes y otras más potentes como cálculos, regulaciones, etc.

Unidad en la que existen, por una parte, unos terminales de entrada (o captadores) a los que se conectan pulsadores, finales de carrera, fotocélulas, detectores...; y por otra, unos terminales de salida (o actuadores) a los que se conectarán bobinas de contactores, electroválvulas, lámparas..., de forma que la actuación de estos últimos está en función de las señales de entrada que estén activadas en cada momento, según el programa almacenado.

8

Sección Española


Aparición de los PLCs

Sistemas electrónicos programables (PLC)

- Aparecen de la década de los 60 como sustitutos naturales de los relés.

- Ventajas:

- Tiempo de vida largo.

- Los cambios de programa se realizan de un modo fácil y rápido.

- Robustos para trabajar en entornos industriales.

- Fiables.

5

9

Sección Española


Evolución del PLC

Sistemas electrónicos programables (PLC)- Mejora de prestaciones de los PLCs

- Microprocesadores más potentes.

- Mayor capacidad de memoria.

- Posibilidades de comunicación.

- Visualización.

- Periferia descentralizada.

- Cada vez son mayores los tipos de tareas a realizar en la industria.

Sistemas de control distribuido (DCS)

10

Sección Española


Flujo de trabajo en producción

Provee-dores

Logísticaentrada

Logísticasalida

Proceso

Discreto

Cliente

Flujo de trabajo en producción

6

11

Sección Española


Tipos de Industrias

Ener

gía

Ref

iner

ías

Agu

as

Quí

mic

a

Petr

óleo

& g

as

Cel

ulos

a&

pap

el

Met

alur

gia

/ min

ería

Farm

acéu

tica

Alim

ent.

& b

ebid

as

Aut

omoc

ión

Elec

trón

ica

Cem

ento

& v

idrio

Proceso Manufactura

12

Sección Española


Aplicaciones

Industria del automóvil.Maquinaria, incluida maquinaria especial.Almacenes automatizadosIndustria siderúrgicaAutomatización de edificios.Generación y distribución de energía.Industria de papel, madera, textil.Industria farmacéutica y alimentaria.Abastecimiento y depuración de aguas.Industria química y petroquímica.

7

Sección Española


Estructura del PLCEstructura del PLC

14

Sección Española


Estructura del PLC

BastidorFuente de alimentación.CPUProcesadores de comunicacionesTarjetas de entrada.Tarjetas de salida.Tarjetas especiales.

8

15

Sección Española


Bastidor

Perfil soporte de aluminio y plásticoBus posterior para comunicaciones internasToma para tierra local

16

Sección Española


Fuente de alimentación

Las fuentes de alimentación suministran, a través del bus posterior, las tensiones de servicio necesarias para el funcionamiento de los otros módulos del bastidor. No ofrecen las tensiones de alimentación (de carga) para los módulos de señales.

9

17

Sección Española


CPU

MicroprocesadorMemoria interna / externaImagen de procesoTemporizadoresContadoresPuertos de comunicaciones

18

Sección Española


Tarjetas de entrada / salida

Tarjetas digitales de entradaTarjetas digitales de salidaTarjetas analógicas de entradaTarjetas analógicas de salida

10

19

Sección Española


Procesadores de comunicaciones

Buses de campoEthernet ISO / TCP-IPSerie

Sección Española


ComunicacionesComunicaciones

11

21

Sección Española


Tipos

Bus de sistema• Comunicación entre estaciones de visualización y los PLCs

Bus de terminales• Comunicación entre Servidores y clientes

Buses de campo• Comunicación entre unidades centrales, CPUs y su periferia

descentralizada

Comunicación serie• Comunicación normalmente entre sistemas de diferentes

fabricantes.

22

Sección Española


Ejemplo de comunicaciones

12

23

Sección Española


Periferia descentralizada

ControladoresO

LMFO

Ethernet Descentralización en el campoO

LM

24

Sección Española


Medio físico

FO

infrarrojo

Barrerasaisladoras

Barrera Ex + repetidor

13

25

Sección Española


Comunicación global

B+B

AI

DI

DO

DOAI

AI

DI

DO

AOAI

B+B

26

Sección Española


Otros equipos de campo

Seguridad

HMI

Motion ControlHMI

Controlador

Periferiadistribuida

Switching

WirelessSensoresProxy Proxy

Comunicación con Ethernet

14

Sección Española


Lenguajes de programaciónLenguajes de programación

28

Sección Española


Lenguajes de programación

Lenguajes clásicos• Son herramientas orientadas a la CPU con una programación

muy cercana a un ensamblador. Son típicos la lista de instrucciones, contactos, …

15

29

Sección Española



Lenguajes de alto nivel• Están orientados al usuario, tienden a simplicar las tareas de

programación así como el tiempo dedicado a las mismas. Por el contrario generan más código de programa.

30

Sección Española



Librerías• Son paquetes que nos proporcionan funciones ya programadas

para realizar determinadas tareas.

16

Sección Española


VisualizaciónVisualización

32

Sección Española


Funciones del Scada

17

Sección Española


Interfaz gráfica

34

Sección Española


Sistemas Scada

Cliente

Servidores Red de automatización

ModemLANIntranet

LAN

ModemLAN

ClientesClientes web

WebServeren cliente

18

35

Sección Española


Sistemas monopuesto• Ampliación posterior a sistemas multipuesto • Escalabilidad del software

SistemaMono puesto

Escalabilidad

36

Sección Española


Escalabilidad

Sistema multipuesto • Actualización automática de los clientes durante la

configuración• Alto número de clientes

Clientes…..

Servidor

19

37

Sección Española


Escalabilidad

También como sistemas redundantes • Sincronización más rápida• Disponibilidad ampliada

Clientes…..

Servidor

38

Sección Española


Escalabilidad

Sistemas distribuidos • Mayor número de Servidores • Configuraciones más grandes

………

Clientes…..

Servidores

20

39

Sección Española


Escalabilidad

Almacenamiento centralizado + servidor de análisis• Altas prestaciones para históricos de datos y de alarmas

………

Clientes…..

Servidores

40

Sección Española


Escalabilidad

Clientes como Servidor Web• Clientes como servidores Web asegurando una visualización

de los datos de todos los servidores de forma transparente

………

Clientes…..

Servidores

21

41

Sección Española


Escalabilidad

Soporte de soluciones ThinClient independientes de la plataforma hardware empleada

………

Clientes…..

Servidores

42

Sección Española


Paneles de operador

22

43

Sección Española


Plataforma HMI / MES / ERP

Sección Española


ArquitecturasArquitecturas

23

45

Sección Española


Arquitectura general

Operator terminals

terminal bus

Ethernet

OS singleuser systemOS-Server (1...6)

system bus

AS AS AS

46

Sección Española


Ejemplo de configuración (ESD)

OLM

Engineering and Operator Stations PCS 7

CPU FH

Periferia

ESD Furnaces, compressors

Interlocks: motors, tanks

Periferia

Sala de racks

MODBUS RTU

Industrial Ethernet (Optical Fiber)

FO

OS ES

24

47

Sección Española


Entradas digitales

Safe Modules

Quantity

Total +15%

Reserve

Modules

• Critical Inputs No Exi SI 92 120 5 x 2

• " " Exi SI 296 336 14 x 2

• " " Exi 2 de 3 SI 150 (50 x 3)

192 (79 x 3)

3 x 3

• No critical inputs No Exi NO 120 160 5

• No critical inputs Exi NO 148 192 6

• Critical inputs 2 out of 3 from keyboard direct actions.

SI 32 48 2x3

48

Sección Española


Entradas analógicas y Salidas digitales

Safety Modules

Quantity

Total +15%

Reserve

Modules

• Analog inputs 4-20 mA Load of motors. No critical.

NO 132 152 19

• Analog inputs 2 out of 3 Exi. SI 84 (28 x 3)

96 (36 x 3)

6 x 3

• Analog inputs to MONITOR SWITCH as critical digital inputs.

SI 36 48 2 x 2

• Outputs L.P. MCC critical. SI 100 120 12 x 2

• Outputs E.V. 110 V dc. SI 163 190 19 x 2

• Outputs to signal lamps 24 V dc. No critical.

NO 51 64 4

• Outputs to lamps from direct actions keyboard.

NO 30 32 2

25

49

Sección Española


Resumen de señales

Signals Critical No critical Total

DI 1032 352 1384

AI 246 - 246

DO 620 32 652

Sección Española


Evolución futuraEvolución futura

26

51

Sección Española


Tendencias

La complejidad de las plantas y las aplicaciones es cada vez mayor.El aumento de la productividad y los ciclos de innovación cada vez más cortos.

fabricación flexible tiempos de preparación cortos Primer Lote

Integración del proceso de producción.Interrelación del control de la producción con la logística, el control de los almacenes y los procesos supraordenados de gestión de la planta

Documentación completa de los procesos de fabricación.Certificados de pruebas para la Administración / Clientes finales

52

Sección Española


Consecuencias en la Automatización

La complejidad de las soluciones de Automatización es cada vez mayorLos costes de Ingeniería y de Puesta en Marcha aumentan cada vez másLa Integración Vertical debe realizar la interconexión entre el Campo y los sistemas MES-(Gestión de la Producción) y ERP-(Planificación de recursos)“Facilidad de uso"

La exigencia de disponer de varias capas de acceso a la información en las pantallas aumenta la complejidad del Software

27

53

Sección Española


Entorno global

Control

Manufacturing ExecutionSystems (MES)

TotallyIntegratedAutomation

Enterprise ResourcePlanning (ERP)

MES Solutions

Flujo detrabajo enproducción

Ciclo vida enla producción

Logística de entrada Proceso

Manufactura Logística de salida

Diseño e ingeniería

Instalación y puestaen servico

Operación Mantenimiento Modernizacióny ampliación

54

Sección Española


7 sistemas control

Documents