Índice

SCADA, Una breve revisión

SCADA, Una breve revisión

SCADA es un acrónimo por Supervisory Control And Data Acquisition (control y adquisición de datos de supervisión). Los sistemas SCADA utilizan la computadora y tecnologías de comunicación para automatizar el monitoreo y control de procesos industriales. Estos sistemas son partes integrales de la mayoría de los ambientes industriales complejos o muy geográficamente dispersos ya que pueden recoger la información de una gran cantidad de fuentes muy rápidamente, y la presentan a un operador en una forma amigable. Los sistemas SCADA mejoran la eficacia del proceso de monitoreo y control proporcionando la información oportuna para poder tomar decisiones operacionales apropiadas.

Los primeros SCADA eran simplemente sistemas de telemetría que proporcionaban reportes periódicos de las condiciones de campo vigilando las señales que representaban medidas y/o condiciones de estado en ubicaciones de campo remotas. Estos sistemas ofrecían capacidades muy simples de monitoreo y control, sin proveer funciones de aplicación alguna. La visión del operador en el proceso estaba basada en los contadores y las lámparas detrás de paneles llenos de indicadores. Mientras la tecnología se desarrollaba, los ordenadores asumieron el papel de manejar la recolección de datos, disponiendo comandos de control, y una nueva función - presentación de la información sobre una pantalla de CRT. Los ordenadores agregaron la capacidad de programar el sistema para realizar funciones de control más complejas.

Los primeros sistemas automatizados SCADA fueron altamente modificados con programas de aplicación específicos para atender a requisitos de algún proyecto particular. Como ingenieros de varias industrias asistieron al diseño de estos sistemas, su percepción de SCADA adquirió las características de su propia industria. Proveedores de sistemas de software SCADA, deseando reutilizar su trabajo previo sobre los nuevos proyectos, perpetuaron esta imagen de industria-específicos por su propia visión de los ambientes de control con los cuales tenían experiencia. Solamente cuando nuevos proyectos requirieron funciones y aplicaciones adicionales, hizo que los desarrolladores de sistemas SCADA tuvieran la oportunidad de desarrollar experiencia en otras industrias.

Hoy, los proveedores de SCADA están diseñando sistemas que son pensados para resolver las necesidades de muchas industrias con módulos de software industria-específicos disponibles para proporcionar las capacidades requeridas comúnmente. No es inusual encontrar software SCADA comercialmente disponible adaptado para procesamiento de papel y celulosa, industrias de aceite y gas, hidroeléctricas, gerenciamiento y provisión de agua, control de fluidos, etc. Puesto que los proveedores de SCADA aún tienen tendencia en favor de algunas industria sobre otras, los compradores de estos sistemas a menudo dependen del proveedor para una comprensiva solución a su requisito, y generalmente procurar seleccionar un vendedor que pueda ofrecer una completa solución con un producto estándar que esté apuntado hacia las necesidades específicas del usuario final. Si selecciona a un vendedor con experiencia limitada en la industria del comprador, el comprador debe estar preparado para asistir al esfuerzo de ingeniería necesario para desarrollar el conocimiento adicional de la industria requerido por el vendedor para poner con éxito el sistema en ejecución.

La mayoría de los sistemas SCADA que son instalados hoy se está convirtiendo en una parte integral de la estructura de gerenciamiento de la información corporativa. Estos sistemas ya no son vistos por la gerencia simplemente como herramientas operacionales, sino como un recurso importante de información. En este papel continúan sirviendo como centro de responsabilidad operacional, pero también proporcionan datos a los sistemas y usuarios fuera del ambiente del centro de control que dependen de la información oportuna en la cual basan sus decisiones económicas cotidianas. La mayoría de los vendedores principales de SCADA han reconocido esta tendencia, y están desarrollando rápidamente métodos eficientes para hacer disponibles los datos, mientras protegen la seguridad y funcionamiento del sistema SCADA. La arquitectura de los sistemas de hoy integra a menudo muchos ambientes de control diferentes, tales como tuberías de gas y aceite, en un solo centro de control.

Para alcanzar un nivel aceptable de tolerancia de fallas con estos sistemas, es común tener ordenadores SCADA redundantes operando en paralelo en el centro primario del control, y un sistema de reserva del mismo situado en un área geográficamente distante. Esta arquitectura proporciona la transferencia automática de la responsabilidad del control de cualquier ordenador que pueda llegar a ser inasequible por cualquier razón, a una computadora de reserva en línea, sin interrupción significativa de las operaciones.

Introducción a SCADA.

Supongamos tener un circuito eléctrico simple que consiste en un interruptor y una luz. Similar a este:

Este circuito permite que un operador mire la luz y sepa si el interruptor está abierto o cerrado. El interruptor puede indicar que un motor está trabajando o parado, o si una puerta está abierta o cerrada, o aún si ha habido un incidente o el equipo está trabajando.

Hasta ahora no hay nada especial sobre esto. Pero ahora imagínese que el interruptor y la lámpara están separados 100 kilómetros. Obviamente no podríamos tener un circuito eléctrico tan grande, y ahora será un problema que involucrará equipamiento de comunicaciones.

Ahora complique un poco más el problema. Imagínese que tengamos 2000 de tales circuitos. No podríamos producir 2000 circuitos de comunicación. Sin embargo alguien encontró que podríamos utilizar un solo circuito de comunicación compartiéndolo. Primero enviamos el estado (abierto | cerrado o 0/1) del primer circuito. Luego enviamos el estado del segundo circuito, etcétera. Necesitamos indicar a qué circuito se aplica el estado cuando enviamos los datos.

El operador en el otro extremo todavía tiene un problema: tiene que monitorear los 2000 circuitos. Para simplificar su tarea podríamos utilizar una computadora. La computadora vigilaría todos los circuitos, y le diría al operador cuándo necesita prestarle atención a un circuito determinado. La computadora será informada cuál es el estado normal del circuito y cuál es un estado de "alarma". Vigila todos los circuitos, e informa al operador cuando cualquier circuito entra en alarma comparando con estos valores.

Algunos circuitos pueden contener datos "analógicos", por ejemplo, un número que representa el nivel de agua en un tanque. En estos casos la computadora será informada de los valores de niveles máximo y mínimo que deban ser considerados normales. Cuando el valor cae fuera de este rango, la computadora considerará esto como una alarma, y el operador será informado.

Podríamos también utilizar la computadora para presentar la información de una manera gráfica (un cuadro vale mil palabras). Podría mostrar una válvula en color rojo cuando está cerrada, o verde cuando está abierta, etcétera.

Un sistema SCADA real es aún más complejo. Hay más de un sitio. Algunos tienen 30.000 a 50.000 "puntos" que normalmente proporcionan tanto información "analógica" como digital o de estado (por ejemplo, números tales como el nivel del líquido en un tanque). Pueden enviar un valor de estado (por ejemplo, encender una bomba) tanto como recibirlo (bomba encendida). Y la potencia de la computadora se puede utilizar para realizar un complejo secuenciamiento de operaciones, por ejemplo: ABRA una válvula, después ENCIENDA una bomba, pero solamente si la presión es mayor de 50.

La computadora se puede utilizar para resumir y visualizar los datos que está procesando. Las tendencias (gráficos) de valores analógicos en un cierto plazo son muy comunes. Recoger los datos y resumirlos en informes para los operadores y la gerencia son características normales de un sistema SCADA.

Definición General

SCADA (supervisory control and data acquisition): Un sistema industrial de mediciones y control que consiste en una computadora principal o master (generalmente llamada Estación Principal, Master Terminal Unit o MTU); una o más unidades control obteniendo datos de campo (generalmente llamadas estaciones remotas, Remote Terminal Units, o RTU's); y una colección de software estándar y/o a medida usado para monitorear y controlar remotamente dispositivos de campo. Los sistemas SCADA contemporáneos exhiben predominantemente características de control a lazo abierto y utilizan comunicaciones generalmente interurbanas, aunque algunos elementos de control a lazo cerrado y/o de comunicaciones de corta distancia pueden también estar presentes.

Sistemas similares a SCADA son vistos rutinariamente en fábricas, plantas de tratamiento, etc. Éstos son llamados a menudo como Sistemas de Control Distribuidos (DCS - Distributed Control Systems). Tienen funciones similares a los sistemas SCADA, pero las unidades de colección o de control de datos de campo se establecen generalmente dentro de un área confinada. Las comunicaciones pueden ser vía una red de área local (LAN), y serán normalmente confiables y de alta velocidad. Un sistema DCS emplea generalmente cantidades significativas de control a lazo cerrado.

Un sistema SCADA por otra parte, generalmente cubre áreas geográficas más grandes, y normalmente depende de una variedad de sistemas de comunicación menos confiables que una LAN. El control a lazo cerrado en esta situación será menos deseable.

Entonces, qué es SCADA? Se utiliza para vigilar y para controlar la planta industrial o el equipamiento. El control puede ser automático, o iniciado por comandos de operador. La adquisición de datos es lograda en primer lugar por los RTU's que exploran las entradas de información de campo conectadas con ellos (pueden también ser usados PLC's - Programmable Logic Controllers). Esto se hace generalmente a intervalos muy cortos. La MTU entonces explorará los RTU's generalmente con una frecuencia menor. Los datos se procesarán para detectar condiciones de alarma, y si una alarma estuviera presente, sería catalogada y visualizada en listas especiales de alarmas.

Los datos pueden ser de tres tipos principales:

• Datos analógicos (por ejemplo números reales) que quizás sean presentados en gráficos.

• Datos digitales (on/off) que pueden tener alarmas asociadas a un estado o al otro.

• Datos de pulsos (por ejemplo conteo de revoluciones de un medidor) que serán normalmente contabilizados o acumulados.

La interfaz primaria al operador es un display que muestra una representación de la planta o del equipamiento en forma gráfica. Los datos vivos (dispositivos) se muestran como dibujos o esquemas en primer plano (foreground) sobre un fondo estático (background). Mientras los datos cambian en campo, el foreground es actualizado (una válvula se puede mostrar como abierta o cerrada, etc.). Los datos analógicos se pueden mostrar como números, o gráficamente (esquema de un tanque con su nivel de líquido almacenado). El sistema puede tener muchos de tales displays, y el operador puede seleccionar los más relevantes en cualquier momento.

MTU - Master Terminal Unit

Funciones

La parte más visible de un sistema SCADA es la estación central o MTU. Éste es el "centro neurálgico" del sistema, y es el componente del cual el personal de operaciones se valdrá para ver la mayoría de la planta. Una MTU a veces se llama HMI -Human Machine Interface, interfaz ser humano - máquina -.

Las funciones principales de una MTU de SCADA son:

• Adquisición de datos. Recolección de datos de los RTU's.

• Trending. Salvar los datos en una base de datos, y ponerlos a disposición de los operadores en forma de gráficos.

• Procesamiento de Alarmas. Analizar los datos recogidos de los RTU's para ver si han ocurrido condiciones anormales, y alertar a personal de operaciones sobre las mismas.

• Control. Control a Lazo Cerrado, e iniciados por operador.

• Visualizaciones. Gráficos del equipamiento actualizado para reflejar datos del campo.

• Informes. La mayoría de los sistemas SCADA tienen un ordenador dedicado a la producción de reportes conectado en red (LAN o similar) con el principal.

• Mantenimiento del Sistema Mirror, es decir, mantener un sistema idéntico con la capacidad segura de asumir el control inmediatamente si el principal falla.

• Interfaces con otros sistemas. Transferencia de datos hacia y desde otros sistemas corporativos para, por ejemplo, el procesamiento de órdenes de trabajo, de compra, la actualización de bases de datos, etc.

• Seguridad. Control de acceso a los distintos componentes del sistema.

• Administración de la red. Monitoreo de la red de comunicaciones.

• Administración de la Base de datos. Agregar nuevas estaciones, puntos, gráficos, puntos de cambio de alarmas, y en general, reconfigurar el sistema.

• Aplicaciones especiales. Casi todos los sistemas SCADA tendrá cierto software de aplicación especial, asociado generalmente al monitoreo y al control de la planta.

• Sistemas expertos, sistemas de modelado. Los más avanzados pueden incluir sistemas expertos incorporados, o capacidad de modelado de datos.

Hardware y software

La MTU de SCADA se puede correr en la mayoría de las plataformas. Los sistemas tendieron históricamente a ser propietarios y muy especializados, y donde fueron utilizados sistemas operativos de fines generales, tendieron a ser modificados pesadamente. Esto era debido a que los requisitos de SCADA superaban los límites de la tecnología disponible y, por razones de performance, tendieron a proporcionar sistemas gráficos por encargo, a usar bases de datos en tiempo real (con gran parte de la base de datos en memoria), y a menudo el hardware debió ser modificado para estos requisitos particulares.

La serie Digital Equipment Corporation PDP11 y el sistema operativo RSX11M eran quizás la plataforma más común en los SCADA de los años 70 y principios de los 80. Posteriormente, Unix comenzó a ser el sistema operativo de más frecuente elección. Mientras la potencia de la PC aumentaba, los sistemas Intel llegaron a ser muy comunes, aunque las plataformas DEC Alfa, y otras estaciones de trabajo de fines elevados estén aún en uso. En épocas recientes Windows NT ha alcanzado alta aceptación dentro de la comunidad SCADA, aunque los sistemas muy grandes siguen siendo probablemente estaciones de trabajo Unix (QNX o Solaris) más veloces en sus respuestas.

Actualmente la industria se está desarrollando claramente hacia estándares abiertos: ODBC, INTEL PCs, sistemas estándares de gráficos, e interconectividad a sistemas de computación corrientes. En años recientes ha aparecido en el mercado un importante número de sistemas SCADA sobre plataformas INTEL PC, ya que éstas están aumentando rápidamente su capacidad y performance. Ejemplos de ellos son Citect, FIX de Intellution, KEPware y Wonderware.

Adquisición de datos

La función de adquisición de datos de un sistema SCADA es obviamente una función preponderante. Hay un número de características asociadas a la adquisición de datos.

Interrogación, informes por excepción, y transmisiones iniciadas por RTU's.

Los primeros sistemas SCADA tenían RTU's bobos y el sistema central debía utilizar un sistema de interrogación (polling) para tener acceso a sus datos. El Master controlaba todas las comunicaciones, y un RTU nunca hablaba a menos que fuera interrogado. El Master preguntaba así a cada RTU alternadamente, pidiendo que le envíen sus datos.

El RTU haría lo necesario para recuperar los últimos datos de sus instrumentos (además de la conversión de señales analógicas a digitales) y después contestaría a la petición del Master. Al ser controladas las comunicaciones por el Master, éste registraba los datos con la hora de recepción, muchas veces muy distinta a la hora en que fueron generados.

Algunas variaciones en esto se han introducido para mejorar la eficacia de comunicaciones. El Master podía solicitar solamente algunos de los datos de un RTU en cada encuesta principal, y extraería los datos menos importantes en una segunda encuesta disparada con una frecuencia más baja.

Con RTU's más inteligentes, se podían explorar independientemente sus entradas de información, sobre una base continua, e incluso agrupar por hora los datos. El Master entonces preguntaría al RTU si tiene cualquier cosa para informar. Si nada hubiera cambiado desde la vez última, el RTU respondería sin novedad, y el Master se movería al RTU siguiente. Para asegurarse de que un cierto acontecimiento no fue salteado, ocasionalmente el Master haría una encuesta completa como un chequeo de salud.

Está claro lo que implica cuando una entrada de información digital ha cambiado, pero el uso del informe por excepción con valores analógicos significa que un cierto cambio del umbral está definido (típicamente 1-2%), y sobre éste se ha producido algún cambio.

El informe por excepción puede reducir dramáticamente el tráfico de comunicaciones, siempre y cuando los datos estén cambiando en forma relativamente lenta. Cuando se están midiendo parámetros altamente volátiles puede aumentar drásticamente el tráfico. En este caso una solución es poner estos parámetros volátiles en una encuesta rutinaria, sacrificando una cierta exactitud en la hora de registro en pos de la reducción del tráfico.

El acercamiento más sofisticado es permitir que el RTU reporte por excepción sin la encuesta previa por parte del Master. Esto significa que el sistema de comunicaciones no se está utilizando para las repetidas encuestas con sin novedad siendo la respuesta más frecuente. Esto permite que un sistema típico controle muchos más RTU's con la misma anchura de banda de comunicaciones. Como los asuntos asociados con parámetros altamente volátiles todavía existen, un chequeo de salud en background sigue siendo necesario, de otro modo un RTU podría salir de servicio y el sistema nunca se daría por enterado.

Para utilizar esta técnica, el protocolo de comunicación debe tener la capacidad de proporcionar las direcciones de destino del mensaje, y de la fuente del mismo.

Este sistema también implica que dos RTU's pueden transmitir simultáneamente, interfiriendo uno con otro. Un sistema SCADA normalmente repetirá la transmisión si no recibe un acuse de recibo dentro de cierto tiempo. Si interfieren dos RTU's transmitiendo simultáneamente, y, luego si ambos poseen el mismo tiempo de reenvío, interferirán otra vez. Por esta razón, el acercamiento típico es repetir el envío después de un período aleatoriamente seleccionado.

El uso de timeouts al azar puede no ser suficiente cuando por ejemplo ha habido un apagón extenso. Incluso con recomprobaciones al azar, puede haber tanto tráfico que el RTU todavía no podrá conseguir realizar la transmisión. Por esta razón una mejora que es deseable es que después de 5 intentos, el período de recomprobación se fije en por ejemplo 1 minuto.

Manejo de fallas de comunicaciones

Un sistema SCADA debe ser muy confiable. Los sistemas de comunicación para los sistemas SCADA se han desarrollado para manejar comunicaciones pobres de una manera predecible. Esto es especialmente importante donde está implicado el control - podría ser desastroso si las fallas de comunicaciones causaran que el sistema SCADA haga funcionar inadvertidamente el sector incorrecto de la planta.

Los sistemas SCADA hacen uso típicamente de las técnicas tradicionales de la paridad, del chequeo de sumas polinómicas, códigos de Hamming y demás. Sin embargo no confían simplemente en estas técnicas. La operatoria normal para un sistema SCADA es esperar siempre que cada transmisión sea reconocida. El sistema de interrogación que emplea tiene seguridad incorporada, en la que cada estación externa está controlada y debe periódicamente responder. Si no responde, entonces un número predeterminado de recomprobaciones será procurado. Las fallas eventualmente repetidas harán que el RTU en cuestión sea marcado como "fuera de servicio" (en un sistema de interrogación una falla de comunicación bloquea la red por un período de tiempo relativamente largo, y una vez que se haya detectado una falla, no hay motivo para volver a revisar).

La exactitud de la transmisión de un SCADA se ha mirado tradicionalmente como tan importante que la aplicación SCADA toma directamente la responsabilidad sobre ella. Esto se produce en contraste con protocolos de comunicación más generales donde la responsabilidad de transmitir datos confiablemente se deja a los mismos protocolos. A medida que se utilicen protocolos de comunicación más sofisticados, y los proveedores de SCADA comiencen a tomar confianza con ellos, entonces la responsabilidad de manejar errores será transferida al protocolo.

Los protocolos de comunicación

Se han desarrollado técnicas para la transmisión confiable sobre medios pobres, y es así que muchas compañías alcanzaron una ventaja competitiva respecto de sus competidoras simplemente debido al mérito técnico de sus protocolos. Estos protocolos por lo tanto tendieron a ser propietarios, y celosamente guardados.

Esto no representaba un problema al instalar el sistema, aunque sí cuando eran requeridas extensiones. Lo obvio y casi absolutamente necesario era acudir de nuevo al proveedor original. No era generalmente factible considerar el uso de un protocolo distinto, pues eran generalmente mutuamente excluyentes. Los progresos recientes han considerado la aparición de un número apreciable de protocolos "abiertos". IEC870/5, DNP3, MMS son algunos de éstos.

Los mejores de estos protocolos son los multicapa completamente "encapsulados", y los sistemas SCADA que utilizan éstos pueden confiar en ellos para garantizar la salida de un mensaje y el arribo a destino. Un número de compañías ofrece los códigos fuente de estos protocolos, y otras ofrecen conjuntos de datos de prueba para testear la implementación del mismo. Por medio de estos progresos está llegando a ser factible, por lo menos a este nivel, considerar la interoperabilidad del equipamiento de diversos fabricantes. Como documento adjunto se dará una breve descripción del protocolo DNP 3.0.

Las redes de comunicación

SCADA tiende a utilizar la mayoría de las redes de comunicación disponibles.

Los sistemas SCADA basados en transmisión radial son probablemente los más comunes. Éstos evolucionaron con el tiempo, y lo más básico es el uso de FSK (frequency shift keying - codificación por conmutación de frecuencia) sobre canales de radio analógicos. Esto significa que aquellos 0 y 1 son representados por dos diversas frecuencias (1800 y 2100 hertzios son comunes). Estas frecuencias se pueden sintetizar y enviar sobre una radio de audio normal. Velocidades de hasta 1200 baudios son posibles.

Una consideración especial necesita ser dada al retardo de RTS (request to send - petición de enviar) que normalmente se presenta. Esto se produce porque una radio se tomará algún tiempo después de ser encendida (on) para que la señal alcance niveles aceptables, y por lo tanto el sistema SCADA debe poder configurar estos retardos. La mayoría de las otras consideraciones con respecto a radio y SCADA se relacionan con el diseño básico de la red de radio.

Servicios basados en satélites. Hay muchos de éstos, pero la mayoría son muy costosos. Hay situaciones donde no hay alternativas. No obstante, existe un servicio basado en satélites que es económico: los sistemas VSAT: Very Small Aperture Terminal. Con VSAT, usted alquila un segmento del espacio (64k o más), y los datos se envían de un sitio remoto a un hub vía satélite.

Hay dos tipos de hubs. El primero es un sistema proporcionado típicamente por un proveedor de servicios de VSAT. La ventaja es un costo fijo para los datos aunque su implementación puede costar muy cara. La otra consideración para éstos es la necesidad de un "backlink" del hub al centro de SCADA. Esto puede ser de un costo considerable. El otro tipo de sistema utiliza un hub pequeño (los clásicos de LAN estructuradas) que se puede instalar con el Master. Este es más barato, pero la administración del hub es responsabilidad exclusiva del propietario de SCADA. La interfaz a cualquier tipo de sistema de VSAT implica el uso de protocolos utilizados por el sistema de VSAT - quizás TCP/IP.

Modbus es un protocolo de comunicaciones desarrollado para el mundo del PLC, y fue definido para el uso de las conexiones por cable. Aunque los proyectos procuran con frecuencia utilizar Modbus sobre radio, éste está trayendo problemas, fundamentalmente con los temporizadores. En cualquier caso, Modbus es incompleto como un protocolo para SCADA, y existen alternativas mejores tales como DNP3. Modbus tiene su campo de aplicación en comunicaciones con PLC's sobre una conexión por cable.

Sistemas Landline. Éstos son comúnmente usados, pero una gran cantidad de sistemas SCADA implican el uso de la radio para substituir landlines ante una falla. Las termitas y el relámpago son problemas comunes para los landlines.

Procesadores de Comunicaciones Front End.

El "centro" de SCADA consiste típicamente en una colección de computadoras conectadas vía LAN (o LAN redundante). Cada máquina realiza una tarea especializada. La responsabilidad de la colección de datos básicamente puede residir en una de ellas (con un sistema mirror), las visualizaciones pueden ser manejadas por una segunda computadora, etcétera.

Una función asignada típicamente a una computadora separada es la interfaz a la red de comunicaciones. Ésta manejará toda la interconexión especializada a los canales de comunicaciones, y en muchos casos realizará la conversión del protocolo de modo que el sistema principal pueda contar con datos entrantes en un formato estándar.

Radio

La telemetría de radio es probablemente la tecnología base de SCADA.

La velocidad de transmisión de datos sobre radio estaba en su momento limitada al rango 300 baudios a 1200 baudios, pero las radios de datos modernas soportan hasta 9600 baudios (e incluso hasta 64k). Una red de radio que funciona en la banda de 900 Mhz es autorizada normalmente para utilizar 12,5 o 25 kHz de ancho de banda. En 25 kHz, las velocidades de 9600 baudios pueden ser alcanzadas, pero en 12,5 kHz solamente 4800 baudios son posibles con el equipamiento actual.

Una red de radio típica consiste en una conversación a través del repetidor situado en algún punto elevado, y un número de RTU's que comparten la red. Todos los RTU's "hablan" sobre una frecuencia (F1) y escuchan en una segunda frecuencia (F2). El repetidor escucha en F1, y retransmite esto en F2, de modo que un RTU que transmite un mensaje en F1, lo tiene retransmitido en F2, tal que el resto de RTU's pueda oírlo. Los mensajes del Master viajan sobre un enlace de comunicación dedicado hacia el repetidor y son difundidos desde el repetidor en F2 a todos los RTU's. Si el protocolo de comunicaciones usado entre el Master y el repetidor es diferente al usado en la red de radio, entonces debe haber un "Gateway" en el sitio del repetidor. Este hecho permitiría utilizar los protocolos apropiados para cada uno de los medios. Se ha utilizado con éxito DNP3 sobre la red de radio y después encapsulado el DNP3 en el TCP/IP para permitir que una red de fines generales lleve los datos al Master.

El número de RTU's que puede compartir un repetidor depende de un número de factores. En primer lugar el tipo de equipo de radio puede afectar esto, teniendo en cuenta el retardo en alcanzar una señal estable. La aplicación también es un factor importante, ya que de ella depende el tiempo de respuesta requerido. Las características del protocolo (la interrogación, informe por excepción, las transmisiones iniciadas por el RTU) también pueden ser significativas. La velocidad tiene obviamente un impacto también.

Los circuitos telefónicos

Tienen algunas implicaciones importantes para un sistema SCADA. En primer lugar la administración de módems en campo puede ser molesta. En segundo lugar el RTU debe poder salvar datos mientras el módem está desconectado, para después transmitirlos cuando se establece la conexión.

Preferiblemente el RTU debe poder iniciar la llamada cuando ocurre una alarma, o sus buffers de datos corren el riesgo de desbordar. El Master debe poder manejar la recepción de este cúmulo de datos, y al mismo tiempo "rellenar" su base de datos, generar los gráficos, etcétera. Algunos informes producidos por el Master pueden necesitar ser corregidos cuando llegan los datos.

Trending - Graficación de tendencias

El recurso de trending es una función base incluida en cada sistema SCADA. La computadora se puede utilizar para resumir y exhibir los datos que está procesando. Las tendencias (gráficos) de valores analógicos sobre el tiempo son muy comunes. Recoger los datos y resumirlos en informes para los operadores y gerencia son características normales de un sistema SCADA.

Características

El recurso de trending incluye elementos tales como diagramas X-Y, la capacidad de re-escalar la tendencia mientras es mostrada, la capacidad de visualizar coordenadas para seleccionar una característica en la tendencia y visualizar los valores asociados a ella, histogramas, múltiples valores independientes en una tendencia, y gráficos de información de estado.

El sistema de trending trabaja normalmente creando un archivo para cada tendencia con "casilleros" para los valores de datos que se renovarán en una frecuencia especificada (máximo ratio de trending). A medida que se adquieren los datos de campo, se ubican en los archivos de tendencia, quedando disponibles para su posterior análisis. Hay normalmente un límite superior a la cantidad de datos que puedan ser guardados (ejemplo un año de datos).

Particularidades del Almacenaje de datos

El uso de archivos de tendencia con casilleros para los datos, renovados en los intervalos especificados, puede causar dificultades cuando se usa la característica de Reporte por Excepción. Los problemas pueden ser aún mayores cuando se incluyen en el sistema "dial-up" RTU's por las posibles desconexiones. El sistema SCADA debe tener la capacidad de llenar los archivos de tendencia en estas circunstancias. Un set SCADA no está preparado para hacer esto automáticamente, y se debe tener sumo cuidado al configurar y especificar las características de trending para lograrlo.

Algunos sistemas no permiten que todas las variables sean afectadas al trending de datos. Cuando se desee ver una tendencia para un valor actualmente no configurado para trending, debe entonces ser afectado al trending de datos, y luego habrá que esperar hasta que se hayan salvado suficientes datos para que el gráfico sea consistente y aporte los datos de tendencia. Esto no es útil si estamos procurando encontrar fallas.

Qué especificar

Lo siguiente es indicativo de una especificación típica para el trending de datos.

Se deberán proporcionar la capacidad de trending de variables en tiempo real, históricas, análogas y de estado, en función del tiempo y diagramas de una variable contra otras variables (por ejemplo, lectura de cabezales contra flujo para analizar la eficiencia de una bomba).

Las bases de tiempo para cada tendencia deberán ser configurables a partir de una muestra por minuto a una muestra por semana (u otros valores que puedan ser deseables especificar).

Serán proporcionados histogramas, gráficos de barra y X-Y, gráficos de Y-T, etc.

Por lo menos cuatro puntos independientes serán configurables para cada pantalla de visualización de tendencias para trending simultáneo.

Será posible vía un puntero o una línea seleccionar una muestra individual y hacer que el sistema exhiba el valor para esa muestra.

También será posible, o en la configuración o durante la visualización, asignar mayor o menor magnitud a la escala vertical para cada punto (por ejemplo en vez de 0-100%, hacer un zoom sobre 20-50%).

Al ver tendencias, será posible aumentar o disminuir el rango de tiempo de los datos disponibles.

La configuración de las tendencias, incluyendo la asignación de los puntos de trending, y la selección de los períodos que se visualizarán para cada punto, serán opciones de menú.

Cuando la recuperación de datos de campo se vea demorada por alguna razón, por ejemplo, debido a fallas de comunicación, o debido al uso de las técnicas de Reportes por Excepción, los datos serán salvados retrospectivamente en los archivos de tendencia.

La interrogación, el informe por Excepción, y transmisiones iniciadas por RTU's.

Obviamente los datos no se pueden almacenar en los archivos de tendencia con mayor exactitud o frecuencia de las que son adquiridos de campo. Un sistema de interrogación simple por lo tanto salva los datos condicionado por la frecuencia de interrogación. No obstante es más normal ahora que un sistema de interrogación utilice las técnicas de Reportes por Excepción, en las cuales los valores no se transmiten del campo a menos que haya un cambio significativo. Para un valor analógico esto puede ser un porcentaje especificado del valor a escala completa. Por lo tanto la tendencia mostrará una línea plana, mientras que pudo haber habido un cambio pequeño.

En Sistemas donde los RTU's inician la transmisión, ante un cambio significativo, tienen una característica similar. Los sistemas que utilizan "dial-up" RTU's típicamente transmitirán los datos una vez al día. El RTU puede iniciar una transmisión, pero normalmente sólo en una condición de alarma. El sistema debe poder "rellenar" estos datos retrasados. Una situación similar se presenta cuando las comunicaciones se pierden por alguna razón con un RTU enlazado por radio. Cuando se restablecen las comunicaciones, una "reserva" de datos llegará y sucederá lo mismo.

Procesamiento de alarmas

La característica del procesamiento de alarmas se ha asociado siempre a las funciones de las áreas de control de la planta. La computadora procesa todos los datos como vienen del campo, y considera si la variable ha entrado en alarma. Para los valores digitales, uno de los estados (0 o 1) se puede señalar como estado de alarma. Para valores analógicos es normal que se definan límites de alarmas tal que si el valor cae fuera de estos límites, considerarlo como en alarma.

Las alarmas se clasifican normalmente en varios niveles de prioridad, con la prioridad más alta siendo a menudo reservada para las alarmas de seguridad. Esto permite que el operador seleccione una lista de las alarmas más importantes.

Cuando un punto entra en alarma, debe ser validada por el operador. Un código es asociado a veces por el operador en ese momento para explicar la razón de la alarma. Esto ayuda en el análisis posterior de los datos. Es común tener cierto anuncio audible de la alarma, alguna señal sonora en la sala de operaciones.

Un problema común para los sistemas SCADA es la "inundación" de alarmas. Cuando ocurre un trastorno importante del proceso, a menudo un evento de alarma causa otro y así sucesivamente. A menudo en el entusiasmo inicial, los límites de alarma se especifican firmemente, y aún en valores que no son realmente importantes. La inundación de alarmas resultante puede abrumar al personal de operaciones, y ocultar la causa inicial del problema.

Características

Los recursos de alarmas incluyen la capacidad de identificar al personal de operaciones por su login, y exhibir solamente las alarmas relevantes a su área de responsabilidad, y de suprimir alarmas, por ejemplo, cuando la planta está bajo mantenimiento. Algunos sistemas sofisticados pueden resolver la inundación de alarmas identificando secuencias de causas y efectos.

La interrogación, el informe por Excepción, y transmisiones iniciadas por RTU's.

Cuando los sistemas SCADA no interrogan regularmente todos los sitios, sino que por el contrario confían en la transmisión iniciada por el RTU, si se detectara una condición de error o un cambio significativo en un valor, existe la posibilidad de que el RTU o las comunicaciones puedan fallar, y el evento pase desapercibido. Para solucionar esto, se dispara un "chequeo de salud" en background, en el cual cada RTU es interrogado con una frecuencia determinada por el tiempo que se considere prudente en que una alarma no sea detectada.

Comunicaciones

Importancia

La característica distintiva de los sistemas SCADA es su capacidad de comunicación. Como ya se ha dicho, comparado a los DCS (Distributed Control Systems - sistemas de control distribuido) considerados a menudo dentro de una planta o de una fábrica, un sistema SCADA cubre generalmente áreas geográficas más grandes, y utiliza muchos medios de comunicaciones diversos (y a menudo relativamente no fiables). Un aspecto importante de la tecnología de SCADA es la capacidad de garantizar confiablemente la salida de datos al usar estos medios. Los sistemas SCADA utilizaron inicialmente enlaces de comunicación lentos. Cálculos cuidadosos debieron ser hechos para evaluar los volúmenes de datos probables esperados, y asegurar que la red de comunicaciones fuera capaz de resolver las demandas.

Todo lo relacionado a las redes de comunicación se ha desarrollado más arriba.

RTU's Remote Terminal Units

Fundamentos

El SCADA RTU es una pequeña y robusta computadora que proporciona inteligencia en el campo para permitir que el Master se comunique con los instrumentos. Es una unidad stand-alone (independiente) de adquisición y control de datos. Su función es controlar el equipamiento de proceso en el sitio remoto, adquirir datos del mismo, y transferirlos al sistema central SCADA.

Hay dos tipos básicos de RTU's- "single boards" (de un solo módulo), compactos, que contienen todas las entradas de datos en una sola tarjeta, y "modulares" que tienen un modulo CPU separado, y pueden tener otros módulos agregados, normalmente enchufándolos en una placa común (similar a una PC con una placa madre donde se montan procesador y periféricos).

Un RTU single board tiene normalmente I/O fijas, por ejemplo, 16 entradas de información digitales, 8 salidas digitales, 8 entradas de información analógicas, y 4 salidas analógicas. No es normalmente posible ampliar su capacidad.

Un RTU modular se diseña para ser ampliado agregando módulos adicionales. Los módulos típicos pueden ser un módulo de 8 entradas análogas, un módulo de 8salidas digitales.

Funcionalidad del Hardware de un RTU

El hardware de un RTU tiene los siguientes componentes principales:

• CPU y memoria volátil (RAM).

• Memoria no volátil para grabar programas y datos.

• Capacidad de comunicaciones a través de puertos seriales o a veces con módem incorporado.

• Fuente de alimentación segura (con salvaguardia de batería).

• Watchdog timer (que asegure reiniciar el RTU si algo falla).

• Protección eléctrica contra fluctuaciones en la tensión.

• Interfaces de entrada-salida a DI/DO/AI/AO's.

• Reloj de tiempo real.

Funcionalidad del Software de un RTU

Todos los RTU's requieren la siguiente funcionalidad. En muchos RTU's éstas se pueden mezclar y no necesariamente ser identificables como módulos separados.

• Sistema operativo en tiempo real.

• Driver para el sistema de comunicaciones, es decir la conexión con el Master.

• Drivers de dispositivo para el sistema de entrada-salida a los dispositivos de campo.

• Aplicación SCADA para exploración de entradas de información, procesamiento y el grabado de datos, respondiendo a las peticiones del Master sobre la red de comunicaciones.

• Algún método para permitir que las aplicaciones de usuario sean configuradas en el RTU. Ésta puede ser una simple configuración de parámetros, habilitando o deshabilitando entradas-salidas específicas que invalidan o puede representar un ambiente de programación completo para el usuario.

• Diagnóstico.

• Algunos RTU's pueden tener un sistema de archivos con soporte para descarga de archivo, tanto programas de usuario como archivos de configuración.

Operación básica

El RTU operará la exploración de sus entradas de información, normalmente con una frecuencia bastante alta. Puede realizar algún procesamiento, por ejemplo cambios de estado, timestamping de cambios, y almacenaje de datos que aguardan el polling del Master. Algunos RTU's tienen la capacidad de iniciar la transmisión de datos al Master, aunque es más común la situación donde el Master encuesta a los RTU's preguntando por cambios. El RTU puede realizar un cierto procesamiento de alarmas. Cuando es interrogado el RTU deber responder a la petición, la que puede ser tan simple como dame todos tus datos, o una compleja función de control para ser ejecutada.

RTU's pequeños contra RTU's grandes

Los RTU's son dispositivos especiales fabricados a menudo por pequeños proveedores en pequeños lotes de algunos cientos, normalmente para los mercados domésticos. Por lo tanto no todos los RTU's soportan toda la funcionalidad descripta. Un RTU's más grande puede ser capaz de procesar centenares de entradas de información, y aún controlar el funcionamiento de "sub RTU's" más chicos. Éstos son obviamente más costosos. La potencia de procesamiento de un RTU se extiende desde pequeños procesadores de 8 bits con memoria mínima hasta sofisticados RTU's más grandes capaces de recolectar datos en el orden del milisegundo.

Algunos tipos (medidas) de RTU's

• Sistemas stand-alone minúsculos que emplean las mismas baterías por un año entero o más. Estos sistemas registran los datos en la EPROM o FLASH ROM y descargan sus datos cuando son accedidos físicamente por un operador. A menudo estos sistemas usan procesadores de chip simple con memoria mínima y pueden no ser capaces de manejar un protocolo de comunicaciones sofisticado.

• Sistemas stand-alone pequeños que pueden accionar periódicamente a los sensores (o radios) para medir y/o reportar. Generalmente las baterías son mantenidas por energía solar con capacidad para mantener la operación por lo menos 4 meses durante la oscuridad completa. Estos sistemas tienen generalmente bastante capacidad para un esquema mucho más complejo de comunicaciones.

• Sistemas medios. Ordenadores industriales single board dedicados, incluyendo IBM-PC o compatibles en configuraciones industriales tales como VME, MultiBus, STD megabus, PC104, etc.

• Sistemas grandes. Completo control de planta con todas las alarmas visuales y sonoras. Éstos están generalmente en DCS en plantas, y se comunican a menudo sobre LAN de alta velocidad. La sincronización puede ser muy crítica.

Estándares

Como fuera indicado, los RTU's son dispositivos especiales. Ha habido una carencia de estándares, especialmente en el área de comunicaciones, y los RTU's provenientes de un fabricante no se pueden mezclar generalmente con RTU's de otro. Una industria ha crecido desarrollando conversores y emuladores de protocolos. Algunos estándares han comenzado recientemente a emerger para RTU's, como DNPs e IEC870 para comunicaciones IEC1131-3 para programar RTU's.

PLC's contra RTU's

Un PLC (Programmable Logic Controller) es un ordenador industrial pequeño que substituyó originalmente la lógica de los relais. Tenía entradas de información y salidas similares a las de un RTU. Contenía un programa que ejecutaba un bucle, explorando las entradas de información y tomando las acciones basadas en estas entradas de información. El PLC no tenía originalmente ninguna capacidad de comunicaciones, sino que comenzaron a ser utilizadas en situaciones donde las comunicaciones eran una característica deseable. Los módulos de comunicaciones fueron desarrollados así para PLC's, utilizando Ethernet (para el uso en DCS) y el protocolo de comunicaciones Modbus para el uso sobre conexiones dedicadas (cables). Con el correr del tiempo los PLC's soportaron protocolos de comunicación más sofisticados.

Los RTU's se han utilizado siempre en situaciones donde son más difíciles las comunicaciones, y la potencia de los RTU's residía en su capacidad de manejar comunicaciones difíciles. Los RTU's tenían originalmente programabilidad pobre en comparación con los PLC's. Con el tiempo, la programabilidad del RTU ha ido aumentando.

Qué especificar

• Rango de temperatura para la aplicación, por ejemplo entre -10 y 65º C.

• Humedad relativa 0 a 95%.

• Protección del polvo, de la vibración, de la lluvia, de la sal y de la niebla.

• Inmunidad al ruido eléctrico.

• Consumo de energía.

• Capacidad de almacenamiento y de entrada-salida. Permita siempre algo de repuesto (alrededor 10-20%).

• Control de exactitud de entradas analógicas, y el tipo de señales digitales esperadas (ej. 0-5v). Programabilidad y flexibilidad de configuración.

• Diagnóstico - local y remoto.

• Capacidad de comunicaciones incluyendo soporte para radio, PSTN, landline, microonda, satélite, X.25.

• Recuerde que el uso del PSTN implica el timestamp y el grabado de los datos mientras no está conectado, y que el Master pueda marcar, validar esta reserva de datos, y llenar su base de datos con estos datos históricos (archivos incluyendo los de tendencia). También considere cómo las alarmas deben ser manejadas con PSTN. Considere los protocolos estándares tales como DNP3, IEC870, MMS en vez de protocolos propietarios.

• Funcionalidad soportada - ej.: timestamping, capacidad de memoria para salvar datos en caso de pérdida de comunicación, capacidad de hacer cálculos.

• Soporte para las comunicaciones punto a punto incluyendo almacenaje y capacidad de redespacho si las comunicaciones son complicadas (especialmente radio).

• Baud Rates utilizado (1200 baudios en FSK, o 9600 baudios en radios de datos).

• Usted puede requerir puertos seriales adicionales especialmente interconectar con PLC's.

• Su Master debe soportar toda la funcionalidad del RTU, especialmente el timestamping de datos analógicos, y los protocolos de comunicaciones.

• Direccionabilidad máxima (Ej. máximo de 255 RTU's).

• Indicación local clara del diagnóstico.

• Chequeos de compatibilidad de la configuración del software contra el hardware actual

• Capacidad de registro de todos los errores producidos y de acceso remoto a estos registros.

• Filtración por software de los canales de entrada de información analógica.

Consideraciones de compatibilidad con año 2000 para RTU's y PLC's.

Como RTU's y PLC's son ordenadores, tienen el potencial de ser afectados por el supuesto fallo de funcionamiento del milenio. Muchos RTU/PLC's no utilizan fechas y no serán afectados en absoluto. Hay muchos que sí lo hacen. Ha habido casos de PLC's bloqueados debido a los problemas con años bisiestos, dando la pauta de potenciales problemas en el año 2000. Puede suceder que el RTU/PLC utilice un RTOS genérico que utilice fechas, y el RTU/PLC no utiliza esta fecha. Es fácil asumir que el RTU/PLC no se verá afectado mientras no exista evidencia externa de que el dispositivo contiene una fecha.

Es importante que cualquier dispositivo que potencialmente tenga un ordenador incluido sea chequeado, o con el proveedor, o probando para verificar su conformidad. El riesgo del incidente debe ser evaluado. En algunos casos el impacto puede ser poco significativo. Es menester asegurarse de poder operar la planta o el equipamiento manualmente en caso de problemas.

También es necesario considerar que la instrumentación a la que el RTU/PLC está conectada puede también contener un ordenador.

Gerenciamiento de Proyectos

Lo que sigue es una descripción muy breve del gerenciamiento de proyectos SCADA. Todas las metodologías de la gerencia de proyecto implican descomponerlo en fases, generalmente con entradas de aprobación al final de cada fase.

Identificación

• Identificar la necesidad

• Preparar la estimación preliminar de costes

• Obtener la aprobación para que los fondos o los recursos procedan a la fase próxima. Esta fase es normalmente informal, y no requiere de muchos recursos.

La identificación de la necesidad podría haberse presentado como ligada a alguna otra actividad, por ejemplo del desarrollo de estrategias corporativas, revisión de la condición de la planta, o de las consecuencias de hacer frente a un incidente importante.

Típicamente un sistema SCADA será requerido por alguna de las razones siguientes:

• Para reducir costos de energía.

• Para reducir costos de personal.

• Para reducir requisitos de capital futuros.

• Para mejorar el nivel del servicio.

• Para evitar incidentes ambientales.

• Para cumplir con requisitos regulatorios.

• Puede no ser posible ejecutar el negocio sin SCADA.

• Para obtener un costo competitivo.

• Para substituir un sistema existente obsoleto.

A menudo SCADA no está rigurosamente justificado sino que es requerido simplemente por la gerencia como parte de la forma que la misma desea llevar el negocio. Ésta puede ser la mejor manera, pues los recursos a menudo substanciales son consumidos intentando dar una justificación para una implementación SCADA, y es extremadamente común que después de que el sistema esté instalado, se presenten beneficios inesperados que abruman las ventajas originalmente predichas. Además, las ventajas pueden presentarse multiplicadas por varias otras iniciativas claves que se estén desarrollando en paralelo, como la reingeniería del negocio, y a veces es imposibles separar los beneficios de SCADA de los que se originan en otras iniciativas.

Una gerencia progresista creará un clima en el cual el personal busque activamente las vías en las cuales mejorar la productividad de la organización. En otras organizaciones, tal propuesta será tratada con escepticismo. La clave de esto reside en que la gerencia desarrolle una visión de cómo quisiera que la organización se maneje en el futuro.

El mundo de los años 90 requiere que las organizaciones lleguen a ser más chicas y más eficientes. Es difícil imaginar que estas tendencias se reviertan en los años próximos.

Esta fase es crucial en cualquier proyecto SCADA. El éxito económico del proyecto se encarna en determinar la factibilidad inicial. El alcance del proyecto esencialmente se define en este punto. Por ejemplo si no se consideran los beneficios del uso de los horarios de tarifas eléctricas reducidas para reducir el costo de bombeo, es improbable que usted incluya esto en el proyecto SCADA en una etapa posterior.

Lanzamiento

• Validar la necesidad del proyecto.

• Establecer los conceptos y su alcance.

• Establecer una estructura sumaria de la subdivisión del trabajo.

• Estimación conceptual de costos (-30 a +50%)

Generalmente una cierta cantidad de recursos financieros se ha aprobado en esta etapa para emprender las investigaciones preliminares, y preparar un plan preliminar de la administración del proyecto. Será necesario afirmarse en el alcance, identificar las tecnologías principales que se utilizarán, y ganar el acuerdo y la aprobación de los usuarios potenciales del sistema. Es harto necesario la estimación del costo con una exactitud dentro del rango -30 a +50%, como así también establecer las ventajas del sistema con bastante exactitud para convencer a la gerencia de dar la aprobación para proceder con la siguiente fase.

Un error común en este punto es entrar demasiado en detalles técnicos. El trabajo debe concentrarse en esta etapa en los requisitos funcionales (o de usuario), y los requisitos tecnológicos se deben mirar solamente al punto de permitir las estimaciones de costos con la exactitud señalada.

El énfasis debe ponerse en asegurarse de que existe una comprensión común dentro de los usuarios finales de qué funcionalidad proporcionará el sistema. Si el sistema se está introduciendo para mejorar productividad, entonces es importante que la gerencia del usuario entienda cómo puede ser utilizado el sistema SCADA para optimizar prácticas de trabajo.

Es importante en esta etapa que el equipo de proyecto incluya a alguien del sector usuario de la organización para comenzar a construir un sentido de la propiedad del sistema. Esta implicación debe continuar a través del proyecto para poder entregar el sistema final a un operador familiarizado en usarlo a su capacidad máxima.

Aunque el trabajo debe concentrarse en los requisitos funcionales, es necesario vigilar las capacidades técnicas ofrecidas por los proveedores como "off the shell" en su industria. Restringiendo la cantidad de software de encargo que el sistema requerirá es probablemente la acción más importante que usted puede tomar para reducir costos, riesgos, y reducir al mínimo la duración global del proyecto.

Una cierta idea preliminar de la estrategia de contratación deberá haber sido desarrollada. Se podrá por ejemplo utilizar consultores, contratos prediseñados (recomendados), etcétera. Como es evidente, esto puede tener un impacto substancial en costos.

La decisión de utilizar consultores se debe tomar con sumo cuidado. Un consultor pudo haber preconcebido ideas en cuanto a cómo el proyecto debe ser manejado. Algunas decisiones tales como el uso de contratos prediseñados pueden no ser del agrado de un consultor, prefiriendo realizar él mismo el diseño por ejemplo.

Definición

• Designar a miembros como líderes de equipo.

• Desarrollar los lineamientos básicos y la agenda para la gerencia del proyecto.

• Evaluar los riesgos.

• Realizar estudios económicos.

• Desarrollar las estrategias contractuales.

• Desarrollar las estrategias de implementación.

• Realizar la estimación definitiva de costo con una máxima exactitud (-15 a +25%).

El proyecto está comenzando en esta etapa a volverse serio. Se está concluyendo la vista preliminar (qué sitios, qué funcionalidad, etc.). Decisiones firmes se están tomando sobre estrategias contractuales tales como diseño y construcción, etc.

El trabajo debe todavía concentrarse en esta etapa en los requisitos funcionales (o de usuario), y nuevamente los requisitos tecnológicos deben sólo observarse para permitir las estimaciones de costos.

Es importante en esta etapa identificar firmemente las ventajas del sistema, y desarrollar "planes de realización de beneficios". Estos planes identificarán exactamente cómo las ventajas propuestas serán efectivizadas, por ejemplo, observando qué cambios serán realizados a los procesos existentes para alcanzar las ventajas previstas. Esto dará confianza a la gerencia que la inversión va a ser provechosa.

Diseño

• Revisiones de Diseño.

• Revisiones de los reportes de la etapa de definición.

• Justificación de los Fondos.

• Estimación de Diseño (-10%+10%).

Esta fase implica normalmente la preparación de la especificación, y el desarrollo de planes de evaluación de licitadores. Es probable que una fase de precalificación pueda proceder en este momento a facilitar la tarea. La Precalificación se utiliza para pre-seleccionar a los licitadores de reputación que tienen una probada trayectoria en este campo. La Precalificación permite la selección de potenciales proveedores antes de que hayan emplazado una cotización, por ejemplo, en base a su capacidad y experiencia.

Una decisión clave en esta etapa es exigir la presentación de pruebas específicas. En los años 80 los contratos rutinariamente especificaban pruebas de aceptación de fábrica, pruebas de implementación, pruebas de aceptación, etcétera. Esto era obligatorio en virtud de que la tecnología era nueva, costosa y la separación del diseño y la adquisición implicaban un alto grado de customización. La costumbre moderna es utilizar contratos prediseñados, y pagar por performance. Una prueba funcional es todo lo que se requiere desde la perspectiva del comprador. Si el proveedor desea ejecutar pruebas de aceptación de fábrica, es su decisión.

Adquisición

• Especificación y preparación del trabajo.

• Estimación de costos (después de la recepción de las ofertas) -5%+5%.

• Construcción.

• Fabricación fuera del sitio.

• Comisión.

• Terminación práctica.

Bajo contratos prediseñados, todo el trabajo detallado es realizado por un solo proveedor.

Los participantes clave en esta etapa son:

• El encargado de proyecto del proveedor.

• El superintendente del contrato.

• El encargado de proyecto.

El éxito del proyecto dependerá de la actuación de estos tres.

En esta fase el proyecto pasará por un número de etapas:

• Diseño (que culmina en un informe del diseño del proveedor para su aprobación).

• Configuración del software principal de SCADA.

• Desarrollo del software a medida.

• Ensamble de RTU's en fábrica, y prueba.

• Instalación de la instrumentación de campo, de comunicaciones, y de RTU's.

• Comisión.

• Prueba de aceptación en el sitio.

• Entrenamiento del cliente.

Subsecuente a esto, el sistema tiene normalmente un período de detección de problemas, más allá del mantenimiento que debe ser contratado.

Liquidación Del Proyecto

• Reporte final del proyecto.

• Liquidación de defectos y mal funcionamientos.

• Depuración final.

• Revisión pos implementación.

La revisión pos implementación es algo que raramente se encara, pero debe ser una parte obligatoria de todos los proyectos. Es importante que una evaluación sea hecha de cuán bien está el sistema resolviendo las necesidades de la organización como son ahora concebidas.

Si es probable que su organización emprenda proyectos futuros en SCADA, entonces la Revisión pos implementación se puede utilizar para documentar cualquier lección aprendida para evitar cometer los mismos errores.

Breve revisión de DNP 3,0

Historia

DNP fue creado originalmente por Westronic, Inc. (ahora GE Harris) en 1990. En 1993, el set de documentos de especificación del protocolo "DNP 3,0 Basic 4" cobró dominio público. La propiedad del protocolo fue entregada al recientemente formado DNP Users Group en octubre de ese año. Desde entonces, el protocolo ha ganado aceptación mundial, incluyendo la formación de grupos de usuarios en China, América latina, y Australia.

En enero de 1995, fue formado el DNP Technical Committee para estudiar mejoras y recomendarlas para su aprobación al Users Group general. Una de las tareas más importantes de este cuerpo era publicar el documento “DNP Subset Definitions”, que establece los estándares para las puestas en marcha de DNP 3,0.

DNP 3,0 es un protocolo SCADA moderno, abierto, inteligente, robusto y eficiente. Entre otras cosas, puede:

• solicitar y responder con múltiples tipos de dato en un solo mensaje,

• segmentar mensajes en múltiples frames para asegurar excelente detección y recuperación de errores,

• incluir en respuesta sólo datos cambiados,

• asignar prioridad a los ítems de datos y solicitarlos periódicamente basado en su prioridad,

• responder sin solicitud previa,

• utilizar sincronización de tiempo y con un formato estándar,

• permitir múltiples operaciones punto a punto y al Master, y

• permitir objetos definibles por el usuario incluyendo transferencia de archivos.

Arquitectura en capas

DNP 3,0 es un protocolo "encapado". Aún así, en lugar de asemejarse al protocolo de 7 capas de la OSI (Open System Interconection - interconexión de sistemas abiertos), DNP 3,0 adhiere a un estándar simplificado de 3 capas propuesto por el IEC (International Electrotechnical Commission - Comisión internacional de Electrotecnia) para implementaciones más básicas. El IEC llama a esto Enhanced Performance Architecture, o EPA. (en realidad, sin embargo, DNP 3,0 agrega una cuarta capa, una capa de pseudo-transporte que permite la segmentación del mensaje).

Capa Física

La capa física se refiere sobre todo a los medios físicos sobre los cuales se está comunicando el protocolo. Por ejemplo, maneja el estado del medio (limpio u ocupado), y la sincronización a través del medio (iniciando y parando). Más comúnmente, DNP se especifica sobre una capa física serial simple tal como RS-232 o RS-485 usando medios físicos tales como fibra, radio o satélite. Los proyectos se orientan actualmente para implementar DNP sobre una capa física como Ethernet.

Capa de Transmisión De Datos

La capa de transmisión de datos maneja la conexión lógica entre el remitente y el receptor de la información y pone a prueba las características de error del canal físico. DNP logra esto comenzando cada frame de transmisión de datos con una cabecera, e insertando un CRC de 16 bits cada 16 bytes del frame. Un frame es una porción de un mensaje completo comunicado sobre la capa física. La medida máxima de un frame de transmisión de datos es 256 bytes. Cada frame tiene una dirección fuente de 16 bits y una dirección de destino también de 16 bits, las que pueden ser una dirección de difusión o broadcast (0xffff). La información del direccionamiento, junto con un código de inicio de 16 bits, la longitud del frame, y un byte de control de transmisión de datos se hallan en la cabecera (10 bytes) de transmisión de datos.

El byte de control de transmisión de datos indica el propósito del frame de transmisión de datos, y el estado de la conexión lógica. Los valores posibles del byte de control de transmisión de datos son: ACK, NACK, la conexión necesita resetear, la conexión ha sido reseteada, confirmación de solicitud de transmisión de datos del frame, solicitud de estado de conexión, y contestación de estado de conexión. Cuando se solicita una confirmación de transmisión de datos, el receptor debe responder con un frame ACK de transmisión de datos si el mismo es recibido y pasa los controles del CRC. Si una confirmación de la transmisión de datos no se solicita, no se requiere ninguna respuesta de la transmisión de datos.

Capa de Pseudo-Transporte

La capa de pseudo-transporte divide mensajes de la capa de aplicación en múltiples frames de transmisión de datos. Para cada frame, inserta un código de función de 1 byte que indica si el frame de transmisión de datos es el primer frame del mensaje, el último frame del mensaje, o ambos (para mensajes singles). El código de función también incluye un número de secuencia del frame que se incrementa con cada uno y permite que la capa de transporte recipiente detecte frames perdidos.

Capa de Aplicación

La capa de aplicación responde a mensajes completos recibidos (y arribados de la capa de transporte), y construye los mensajes basados en la necesidad o la disponibilidad de los datos del usuario. Una vez que se construyan los mensajes, se pasan a la capa de pseudo-transporte donde se dividen en segmentos y se pasan a la capa de transmisión de datos y eventualmente comunicados sobre la capa física.

Cuando los datos a transmitir son demasiado grandes para un solo mensaje de la capa de aplicación, se pueden construir mensajes múltiples de la capa de aplicación y transmitirlos secuencialmente. Sin embargo, cada mensaje es un mensaje independiente de la capa de aplicación; existe una indicación de su asociación con el siguiente, en todos excepto en el último. Debido a esta posible fragmentación de los datos de aplicación, cada mensaje es referido como un fragmento, y un mensaje por ende puede ser un mensaje de un solo fragmento o un mensaje de múltiples fragmentos.

Los fragmentos de la capa de aplicación de las estaciones Master de DNP son típicamente solicitudes de operaciones sobre objetos de datos, y los fragmentos de la capa de aplicación de estaciones esclavas de DNP son típicamente respuestas a esas peticiones. Una estación esclava DNP puede también transmitir un mensaje sin una petición (una respuesta no solicitada).

Como en la capa de transmisión de datos, los fragmentos de la capa de aplicación se pueden enviar con una solicitud de confirmación. Una confirmación de la capa de aplicación indica que un mensaje no sólo ha sido recibido, sino también analizado sin error. (por otra parte, una confirmación de la capa de transmisión de datos, o ACK, indica solamente que se ha recibido el frame de la transmisión de datos y que pasó los controles de error del CRC.)

Cada fragmento de la capa de aplicación comienza con una cabecera seguida por una o más combinaciones de objetos de datos y objetos cabecera. La cabecera de la capa de aplicación contiene un código de control de la aplicación y un código de función de la aplicación. El código de control de la aplicación contiene una indicación de si el fragmento es parte de un mensaje multi-fragmento, una indicación de si una confirmación de la capa de aplicación es requerida por el fragmento, una indicación de si el fragmento fue no solicitado, y contiene un número de secuencia de la capa de aplicación. Este número de secuencia de la capa de aplicación permite que la capa de aplicación receptora detecte los fragmentos que están fuera de secuencia, o los fragmentos perdidos.

El código de función de cabecera de la capa de aplicación indica el propósito, o la operación solicitada, del mensaje. A la par que DNP 3,0 permite múltiples tipos de datos dentro de un único mensaje, permite una única operación sobre los tipos de datos dentro del mismo. Algunos ejemplos de códigos de función son: Confirmar (para las confirmaciones de la capa de aplicación), leer y escribir, seleccionar y operar, congelar y limpiar (para los contadores), reiniciar, permitir e invalidar mensajes no solicitados, y asignar la clase (discutida abajo). El código de función de cabecera de la capa de aplicación se aplica a todas las cabeceras del objeto, y por lo tanto a todos los datos dentro del fragmento del mensaje.

Organización de la Base de datos

En DNP, los datos se ordenan en tipos de datos. Cada tipo de datos es un grupo objeto, incluyendo:

• entradas de información binaria (valores de un solo bit sólo lectura),

• salidas binarias (valores de un solo bit cuyo estado puede ser leído, o que puede ser pulsado o trabado directamente o a través de operaciones tipo SBO),

• entradas de información analógicas (valores múltiple-dígito sólo lectura).

• salida analógica (valor múltiple-dígito cuyo estado puede ser leído, o que puede ser controlado directamente o a través de operaciones tipo SBO),

• contadores,

• hora y fecha,

• objetos de transferencia de archivos,

• etc.

Para cada grupo de objetos, o tipo de datos, existen uno o más puntos de referencia. Un punto de referencia es un único valor del tipo especificado por su grupo de objeto.

También dentro de cada grupo de objeto, existen variaciones. Una variación del grupo de objeto se utiliza típicamente para indicar un método diferente de especificar datos dentro del grupo de objeto. Por ejemplo, las variaciones de entradas de información analógicas permiten la transferencia de los datos como valores enteros con signo de 16 bits, de 32 bits, o como valores de 32-bit con coma flotante.

Según lo descrito arriba, un mensaje de la capa de aplicación puede contener múltiples cabeceras del objeto. Una cabecera del objeto especifica un grupo de objeto, una variación del grupo de objeto, y un rango de puntos dentro de esa variación del grupo de objeto. Algunos códigos de función de la cabecera de la capa de aplicación indican que a cada cabecera del objeto siguen los datos del mismo; otros códigos de función indican que no hay datos del objeto en el mensaje - en su lugar, múltiples cabeceras del objeto, si existen, siguen contiguamente a cada una de las otras. Por ejemplo, un fragmento leído del mensaje de solicitud contiene solamente las cabeceras del objeto que describen los grupos de objeto, las variaciones, y los rangos de puntos que se solicitan leer y responder; un fragmento leído del mensaje de respuesta contiene cabeceras del objeto y los datos del objeto solicitado.

DNP 3,0 permite que los object point ranges sean especificados en una variedad de maneras. Para petición de mensajes, los object point ranges pueden consistir en:

• una petición para todos los puntos del grupo de objetos especificado,

• una petición para un rango contiguo de puntos comenzando con un específico punto de partida y terminando con un específico punto de llegada,

• una petición para una máxima cantidad de puntos,

• con una lista de puntos solicitados.

Para los mensajes de respuesta, los object point ranges consisten típicamente en un rango contiguo de puntos que comienzan con un punto de partida especificado y terminan con una punto de llegada especificado, o con una lista de puntos. Para los object point ranges de respuesta que consisten en una lista de puntos, un número de punto precede a cada objeto de datos. El número de puntos en la lista se especifica como parte del object point range.

Modelo de Reportes

Muchos de los grupos de objeto tienen corresponder, pero se separan, los grupos de objeto que contienen datos del cambio. Los datos del cambio representan solamente las puntas que han cambiado para un grupo de objeto específicamente correspondiente. Por ejemplo, el grupo número 1 de objeto representa las entradas de información binarias (consideradas los datos estáticos), y el grupo número 2 de objeto representa datos binarios del cambio de la entrada de información. Cuando una punta en el grupo de objeto 1 se detecta para haber cambiado, un acontecimiento del cambio en el grupo de objeto 2 para el mismo número de la punta se crea. Incluir solamente las puntas que han cambiado en mensajes de respuesta permite mensajes más pequeños, eficientes. Tales esquemas que señalan se llaman informe-por-anomalía, o RBE.

Para cada punto de referencias del cambio, una época se puede asociar al cambio; cada detección de datos valora que los cambios están considerados un acontecimiento del cambio. En cualquier hora dada, es posible tener acontecimientos múltiples del cambio para algunas puntas, y ningunos acontecimientos del cambio para otras puntas.

En DNP 3,0, los grupos de objeto, y los puntos de referencias dentro de él, se pueden ordenar más a fondo en clases. Esto proporciona a un método eficiente de solicitar datos; un mensaje simple (y pequeño) se puede enviar para solicitar todos los datos en una clase específica (designada la exploración para los datos de la clase). Hay cuatro clases definidas en DNP 3,0. La clase 0 representa todos los parásitos atmosféricos (no datos del acontecimiento del cambio). Las clases 1, 2, y 3, representan diversas prioridades de los datos del acontecimiento del cambio. Asociando diversos datos del acontecimiento del cambio a diversas clases, las clases se pueden solicitar con variar tarifas periódicas.

La clase asumida 1 contiene los datos del acontecimiento del cambio de la prioridad más alta y la clase 3 contiene los datos más bajos del acontecimiento del cambio de la prioridad, una clase 1 que la encuesta sería realizada idealmente como a menudo como posible, una encuesta de la clase 2 sería realizada menos a menudo, y una encuesta de la clase 3 sería realizada incluso menos a menudo. Para cada respuesta de los datos de la clase, solamente los datos de la clase que han cambiado serán vueltos - manteniendo los mensajes de respuesta pequeños y eficientes. Finalmente, adquirir los datos no asociados a la clase 1, 2, o 3, una encuesta de la integridad, consistiendo en una exploración de la clase 0, sería realizada. Debido a la cantidad posiblemente grande de datos que sean vueltos en una exploración de la clase 0, puede no ser terriblemente eficiente y debe ser realizada lo menos a menudo posible.

4/23

Sistemas SCADA