Sistemas de Comunicación Industrial

Sistema SCADA
Software OPC
Intercambio Dinámico de datos (DDE interface)
Control y monitoreo de procesos mediante Paneles
de Operación
Presentado por:
Luis Aizprúa
Adán Escobar
Kevin Lumbsden
Presentado a: Ing. Edwin González
Supervisión y monitorización
 SCADA

SCADA viene de las siglas de "Supervisory Control And Data Adquisition",

es decir: adquisición de datos y control de supervisión. Se trata de una
aplicación software especialmente diseñada para funcionar sobre
ordenadores en el control de producción, proporcionando comunicación con
los dispositivos de campo
En este tipo de sistemas usualmente existe un ordenador, que efectúa tareas
de supervisión y gestión de alarmas, así como tratamiento de datos y control
de procesos.
 ANTECEDENTES

Redes Industriales
La automatización industrial inicialmente dio lugar a islas automatizadas que eran
equipos (autómatas, controles numéricos, robots, ordenadores, etc) aislados entre sí.
La integración de las islas automatizadas dio lugar a las redes industriales.

Niveles de las Redes

Industriales:

– Nivel LAN/WAN.
– Nivel LAN.
– Nivel bus de
campo.
 FUNCIONES PRINCIPALES DEL SISTEMA SCADA
 Supervisión remota de instalaciones y equipos
 Control remoto de instalaciones y equipos
 Procesamiento de datos
 Visualización gráfica dinámica
 Generación de reportes
 Representación se señales de alarma
 Almacenamiento de información
histórica
 Programación de eventos

PRESTACIONES.
 Posibilidad de crear paneles de alarma
 Generación de históricos de señal de planta
 Ejecución de programas
 Posibilidad de programación numérica
Módulos de un SCADA.
 Configuración
 Interfaz gráfico del operador
 Módulo de proceso
 Gestión y archivo de datos
 Comunicaciones

COMUNICACIONES DE UN
SISTEMAS SCADA
En una comunicación deben existir tres
elementos necesariamente:
  Un medio de transmisión, sobre el cual
se envían los mensajes
 Un equipo emisor que puede ser el MTU
 Un equipo receptor que se puede asociar a los RTU´s.
En telecomunicaciones, el MTU y el RTU son también llamados “Equipos
terminales de datos” (DTE, Data Terminal Equipments).
 REQUISITOS

• Deben ser sistemas de arquitectura abierta, capaces de crecer o adaptarse según

las necesidades cambiantes de la empresa.
• Deben comunicarse con total facilidad y de forma transparente al usuario con el
equipo de planta y con el resto de la empresa (redes locales y de gestión).
• Deben ser programas sencillos de instalar, sin excesivas exigencias de hardware, y
fáciles de utilizar, con interfaces amigables con el usuario.

Esquema básico de un sistema de Adquisición, supervisión y control.

 BUSES DE CAMPO
El bus de campo constituye
el nivel más simple y próximo
al proceso dentro de la
estructura de comunicaciones
industriales. Los buses de
campo más recientes permiten
la comunicación con buses
jerárquicamente superiores y
más potentes.

Hay diversos buses según fabricantes, entre ellos:

• Modbus Modicon: marca registrada de GOULD INC.
• BITBUS: marca registrada por Intel.
• Profibus: impulsado por los principales fabricantes alemanes.
• FIP (Factory Instrumentation Bus): impulsado por fabricantes y organismos
oficiales franceses.
• MIL-STD-1553B: adoptado por algunos fabricantes en USA.
 PLATAFORMAS DE ENTORNO PARA SCADA

Las plataformas de entornos son Software creados para el fácil acceso del usuario a los
procesos de control de una empresa, en estos entornos es donde se concentra, procesa y
distribuye la información.
Utiliza las redes internas, redes LAN, e incluso el Internet como medio de comunicación
tanto para la recopilación como la
distribución de los datos hacia los usuarios.

• VB_ScadaLadder de Microladder
• addVANTAGE Pro 5.0 de Adcon

Telemetry.
• LabVIEW
• SIMATIC WinCC- Windows Control Center,

entorno para Windows producido por

Siemens.
 CONEXIÓN CON INTERNET

Los elementos diferenciales de esta funcionalidad son:

Capacidad de acceder a la base de datos para recibir información.

Capacidad de enviar señales de mando al sistema por acceso remoto
Seguridad y agilidad en la transmisión de datos.
 VB_ScadaLadder

Es el SCADA para los MLCHIPs de Microladder. VB_ScadaLadder está compuesto de dos

librerías dinamicas (DLL), llamadas: ML_DLLVB_1_0 y ML_DLLVC_1_0. Gracias a
estas dos librerías se pueden desarrollar de manera fácil programas en Visual Basic y
comunicar con nuestra línea de Productos, de manera que puede desarrollar su propio
SCADA, controlar el rendimiento y funcionamiento de su MLCHIP y monitorizar sus
variables.
 addVANTAGE Pro

addVANTAGE Pro es una plataforma flexible que se enfoca a diferentes tipos de

aplicaciones. Utiliza Internet como medio de comunicación tanto para la recopilación como
la distribución de los datos hacia los usuarios.
El software addVANTAGE Pro concentra, procesa y distribuye la información, además,
consulta permanentemente la central de procesamiento para obtener los datos actualizados
generando
una base de datos de todos
los valores censados por las
estaciones. Además, sus
diferentes extensiones realizan
cálculos que posteriormente se
agregan a la base de datos
histórica.
SCADA con LabVIEW
 LabVIEW es una aplicación para ejercer de servidor de Internet.
 Desde cualquier lugar del mundo el usuario puede modificar los puntos de
consigna del proceso.
 El tiempo de desarrollo de esta funcionalidad es mínimo.

Comunicación HTTP. Servidor y Navegador de

Internet
Protocolo de comunicación CGI.

CGI es una tecnología estándar que permite a los servidores HTTP ejecutar
aplicaciones en el ordenador servidor, es la comunicación entre el usuario y la
aplicación que se está ejecutando en el servidor, se realiza utilizando el protocolo CGI.
El funcionamiento es el siguiente: el Navegador WEB envía una petición HTTP al
Servidor WEB. En ese momento el servidor llama a los CGI VIs, pasándole los
parámetros de entrada del usuario. Finalmente, cuando la aplicación CGI finaliza,
actualiza el Navegador de WEB retornando los datos de salida.
HMI de la Planta Piloto.
Esquema en planta.
Control de la Planta Piloto desde el Navegador de
Internet.
 Requisitos mínimos de la PC Servidor
 Windows 2000 o XP profesional.
 Pentium III 1.5 GHz.
 Placa de red.
 512MB de RAM, Disco rígido suficientemente rápido y grande para hacer
frente a muchas peticiones de datos.
 Conexión a Internet con 256 Kbps de subida.
 Java VM 1.3.1 o más alto.

Requisitos mínimos de las PCs Cliente

 Windows 95, 98, NT, 2000, XP o Linux.
 Pentium II 1 GHz.
 256MB de RAM.
 Cualquier Browser (Mozilla Firefox, Internet Explorer, etc).
 Java VM 1.3.1 o más alto.
WinCC es un aplicación software IHMI (Integrated Human Machine Interface) que
integra el software de controlador de planta en el proceso de automatización, permite a
los operarios interactuar con la aplicación directamente en la máquina o desde un centro
de control.

El entorno de ingeniería de proyectos de WinCC engloba:

 Dibujos
 Estructura de archivos
 Generador de informes
 Administración de datos
 Tiempo de ejecución de WinCC
 EJEMPLO DE PROYECTO WINCC

Paso 1: Inicio DE WINCC

Paso 2: Creación de un nuevo
Proyecto
PASO 3: Agregar un DRIVER
de PLC
1

2 3
 PASO 4: Creación de TAGS
Especificación de la dirección en el PLC

PASO 5: Edición
de imágenes de
proceso
5.1 El diseñador gráfico
5.2 Creación y configuración de un botón
5.3 Configuración de la imagen de proceso
5.4 Dinamizar un atributo

5.5 Crear y dinamizar un

campo de entrada/salida

PASO 6: DEFINIR CARACTERÍSTICAS DE

TIEMPO DE EJECUCIÓN

PASO 7: ACTIVAR EL PROYECTO

 VISUALIZACIÓN DE VALORES DE PROCESO

1. Abrir el editor “Tag Logging”.

2. Configura un temporizador.

Los temporizadores pueden configurarse de dos maneras: para anotaciones ó para el

archivamiento en la configuración de tags.

3. Crea un archivo con el asistente de archivos.

4. Crea una ventana de tendencias en el diseñador gráfico.

5. Crea una ventana de tablas en el diseñador gráfico.

6. Inserta una ventana de tendencias en la imagen.

7. Inserta una tabla en la imagen.

8. Define los parámetros de inicio.

9. Activa tu proyecto.
 CONFIGURACIÓN DE MENSAJES

1. Abre la configuración de mensajes.

2. Activa el asistente de mensajes.
3. Añade los bloques de mensajes al formato de mensajes.
4. Modifica la ventana de mensajes.
5. Configura el texto del mensaje.
6. Define el color del mensaje utilizando diferentes clases de mensajes.
7. Configura las alarmas analógicas.
8. Inserta una ventana de mensajes en tu imagen.
9. Define los parámetros de inicio.
10. Activa tu proyecto.
 GENERACIÓN DE UN INFORME DE
SECUENCIAS DE MENSAJES

1. Activa el informe de secuencias de mensajes en el editor “Alarm Logging”.

2. Abre el diseñador de informes y define el layout del informe de secuencias de
mensajes.
3. Define los parámetros del trabajo de impresión.
4. Define los parámetros de inicio y activa el proyecto.
5. Vista preliminar del informe.
 IMPRIMIR UN INFORME DEL TIEMPO DE
EJECUCIÓN DEL EDITOR TAG LOGGING

1. Crea un nuevo layout.

2. Crea la parte estática del informe del layout.
2.1 Edición de la parte estática
2.2 Edición de la parte dinámica
2.3 Cambio de las características del layout
3. Crea la parte dinámica del informe del layout.
4. Cambia las características del layout.
5. Define los parámetros del trabajo de impresión.
6. Activa la vista preliminar del trabajo de impresión.
Origen de OPC
En los equipos de automatización, como PLC´s, variadores, controladores, ha ido
creciendo el número de componentes de comunicación con sus buses y
protocolos.

Nos situamos en los niveles altos de la pirámide de automatización como son la

Gestión de Proceso (Datos sobre el proceso productivo adquiridos y procesados
por sistemas SCADA) y la Gestión de Negocio (Integración de la información
de planta en los sistemas que gestionan los aspectos productivos y financieros
de la fabricación MES y ERP)
OPC (OLE for Process Control) (Tecnología OLE para el control
de procesos).
Los fabricantes de software de estos niveles (scadas, etc.), tenían el
problema de mantener y actualizar la gran variedad de drivers que
comunicaban los distintos equipos de planta con sus productos.
 
 

En cooperación con Microsoft, un grupo constituido por cinco

empresas, Intellution, Opto-22, Fisher-Rosemount, Rockwell Software
e Intuitiv Software, colaboraron para solucionar este problema y dieron
origen a la especificación técnica no propietaria definida por la OPC
Foundation en Mayo de 1995.
 Microsoft estaba trabajando en el desarrollo del OLE 2.0 (Object linking and
enbedding) (objetos enlazados e incrustados). Aparentemente esta nueva
tecnología podría reemplazar al DDE (Dynamic Data Exchange) (Intercambio
dinámico de datos) que hasta ese momento había sido usada extensivamente para el
intercambio de datos en sistemas SCADA diseñados para Windows. La nueva
tecnología de OLE era más flexible, robusta y eficiente para el entorno industrial que la
proporcionada por DDE.

Este grupo de empresas definieron una serie de especificaciones para el control de

procesos, basadas en OLE/COM y DCOM de Microsoft y el primer borrador de las
mismas fue completado al final de 1995, gracias a la colaboración de otras 90
compañías a lo largo del mundo. El primer conjunto oficial de especificaciones de la
Fundación OPC, se completó en Agosto de 1996: Data Access Specification 1.0a.
(Actualmente se usa al menos la 2.02)
El método definido por OPC, facilita el intercambio de datos en forma estandarizada y
simple en aplicaciones de control y automatización, entre los dispositivos y sistemas
de campo y las aplicaciones de supervisión, administrativas y de oficina. Es decir,
OPC simplifica la interfaz entre componentes de automatización de distintos
fabricantes, con programas y aplicaciones tales como sistemas administrativos y de
visualización.
Con estas especificaciones, el diseño de un paquete SCADA, cuya comunicación se
realizará con servidores OPC, no necesita disponer de drivers para los
numerosos equipos industriales posibles

El software se ha estandarizado y para una aplicación concreta solamente será

necesario disponer en el servidor OPC, de los drivers que conviertan los elementos de
campo al formato OPC. El cliente OPC, como puede ser un SCADA, Visual
Basic, siempre se comunica en el mismo formato.
Otra gran ventaja de las especificaciones “abiertas” OPC, es la utilización de
lenguajes de programación como C++ o Visual Basic como clientes OPC, para la
realización de aplicaciones a medida. Las próximas unidades didácticas tratarán
sobre ello. El condicionante es que hay que hacerlo bajo Windows.
En esta figura se observa una sencilla estructura en la que un PC tiene
instalados los servidores de datos OPC de los dos equipos con los que
comunica. En el mismo PC también está instalado el cliente OPC que puede
ser una aplicación Visual Basic, Scada, etc. La aplicación cliente OPC puede
intercambiar datos con equipos de fabricantes diferentes.
En esta figura se observa una estructura más compleja. OPC permite
utilizar simultáneamente varios servidores para una aplicación
cliente y ejecutar varios clientes al mismo tiempo con un servidor
OPC.
En este caso, tres servidores OPC comunican con cuatro equipos
de campo. Los clientes OPC en este caso no están en los
mismos PC s que contienen los servidores si no en equipos
remotos. Cada una de las aplicaciones de estos clientes podrá tener
acceso a los tres servidores
OPC define varias interfaces desarrolladas para un determinado campo de aplicación:

OPC DA (Data Access) Es la función más usada. Está disponible de forma gratuita con
numerosos drivers en http://www.kepware.com Permite leer, modificar y monitorizar
variables del proceso. La Fundación OPC ofrece una herramienta con la que se puede
probar la conformidad de los servidores DA. OPC DA se basa en la tecnología
COM/DCOM de Microsoft y sólo está disponible para PC´s con un sistema operativo de
Microsoft; la comunicación está limitada a las estaciones de una LAN.

OPC XML-DA utiliza el protocolo XML (eXtensible Merked Lenguage) basado en el

método de transporte vía http. Permite establecer la comunicación entre estaciones con
distintos sistemas operativos y superar los límites de una LAN, por ejemplo, vía Internet.

OPC A&E (Alarm&Event) se utiliza para transmitir de forma inmediata, alarmas o

eventos programados a cualquier cliente OPC. Por una parte estará el servidor OPC- DA
comunicando datos normales del proceso, y por otra el OPC-AE para la comunicación de
datos críticos. Esto permite que sistemas de información remotos puedan reaccionar y
lanzar rutinas de evaluación.
Requerimientos de Funcionalidad OPC.

La siguiente lista de requerimientos de funcionalidad fue tomada del documento Data

Access Automation Interface Standard Versión 2.01, publicado por OPC Foundation:

•OPC es soportado completamente por VC++, Visual Basic y Delphi.

•También por cualquier cliente con interfaz OLE con ciertas limitaciones.
•No soporta el uso con VBScript o JavaScript.
•La especificación OPC requiere como Sistema Operativo al menos Windows 95/98 (con
DCOM), Windows XP Windows NT 4.0 o Superior. En todos los casos es
recomendable instalar la última versión de Services Pack correspondiente.
 Los datos de un Physical Device (PLC) pueden ser leídos o escritos desde el
servidor OPC. Como hemos comentado anteriormente nos proveeremos de este
servidor OPC a través del fabricante del equipo físico o de Kepware (software
gratuito).

 A partir de este servidor se puede construir un cliente con una interface

personalizada, (OPC Custom Interface) para lo cual se usa el lenguaje de alto nivel C+
+. Los datos del servidor OPC vienen originalmente para ser utilizados en lenguaje
C++. Ello requiere utilizar las numerosas herramientas de programación
suministradas por compañías de automatización, usadas para crear clientes y
servidores OPC. Sin embargo, estos juegos de herramientas a menudo exigen que el
usuario tenga unos detallados conocimientos de C++ y componentes de
programación basados en (COM).
Intercambio dinámico de datos DDE
El intercambio DDE permite tanto enviar como recibir datos e instrucciones entre
aplicaciones bajo Windows.

EI protocolo DDE está basado en un sistema de mensajería construido por

Windows. Así, dos programas de aplicación bajo Windows realizan una “conversación
DDE." enviándose mensajes entre ellos.

Una conversación DDE se inicia con el programa que actúa como diente. Este transfiere un
mensaje a todos los programas que se están ejecutando en ese momento en Windows.
Dicho mensaje indica una categoría general de datos que el cliente necesita.
Un programa implicado en una comunicación DDE no necesita codificarse específicamente
para trabajar con otro programa DDE. Generalmente el diseñador de un servidor DDE hace
público cómo se identifican los datos. Como DDE utiliza el sistema de mensajería incluido en
Windows, el programa se integra perfectamente en este entorno.

En DDE ambas aplicaciones deben estar ejecutándose y las dos deben dar a Windows una
dirección a sus funciones de llamada antes de que la comunicación de DDE pueda comenzar.
La función de llamada acepta cualquier mensaje de DDE que Windows envía a la aplicación.
Un cliente estándar DDE soporta cinco operaciones básicas:
Abrir un enlace, Enviar comandos, Leer un elemento de datos, Enviar un elemento de
datos y cerrar el enlace.

Las diferentes aplicaciones clientes pueden tener nombres diferentes para estas
funciones.
El enlace DDE se configura a través de una serie de propiedades de los controles
enlazables cuyo nombre empieza por "Link", como por ejemplo LinkItem y
LinkTopic que proporcionan el nombre de la aplicación origen de datos y la
localización de los datos, y se gestiona a través de métodos de los controles,
Como por ejemplo LinkRequest para iniciar una conversación. Históricamente
DDE es el tipo de enlace automático más antiguo, presente desde las primeras
versiones de Windows. Desde la versión 3.1 del sistema operativo ya quedó
superado por el nuevo estándar de intercambio de información OLE a partir del
cual se desarrolló la moderna tecnología ActiveX.
OLE, Object Linked and Embedded (objetos enlazados e incrustados) o
(vinculados e incluidos) fue introducido en 1991 como una extensión del
protocolo DDE. En una aplicación es posible incluir (incrustar) objetos que
quedarán totalmente contenidos en ella. Los objetos vinculados (enlazados) tienen
una conexión en la aplicación cliente y solo son accesibles a través de la
aplicación que contiene los datos originales.

Desde la perspectiva de OLE las aplicaciones no son un bloque indivisible y

homogéneo sino que por el contrario están formadas por componentes que se
comunican unos con otros transfiriéndose información. Algunos de estos
componentes pueden ser públicos en el sentido de ser utilizables por
cualquier aplicación.
Señalemos claramente las ventajas de la definición OLE:

1. Podemos intercambiar información tal como permitía hacer la tecnología DDE.

2. También podemos compartir código a través de objetos públicos definidos por

cualquier aplicación que use el estándar OLE.

3. Para utilizar los recursos de otra aplicación (datos o código) no siendo necesario que
esa aplicación esté activa, cosa que sí ocurría con el enlace DDE.

4. Con DDE, para editar los datos proporcionados por otra aplicación se le pasaba el
control de la ejecución quedando nuestro programa en segundo plano. Con OLE nuestro
programa siempre está en primer plano controlando la ejecución. Esto nos da un mayor
control de la situación además de ser más eficiente en la ejecución.

Las aplicaciones que proporcionan objetos OLE públicos se denominan servidores OLE
y las que los utilizan clientes OLE. Una aplicación visual Basic puede actuar como
cliente o como servidor.
Hay dos formas de mostrar esos datos: datos insertados (también se suelen
llamar incrustados o embebidos) o bien datos enlazados (o vinculados).
OLE utiliza el modelo COM (Component Object Model). Éste define el
estándar para la interrelación de los componentes. COM permite llamadas
dentro de un proceso, llamadas a otro proceso e incluso llamadas a otro
ordenador.

Microsoft describe DCOM como "Distributed Component Object Model”

(DCOM) es un protocolo que permite a los Componentes de software
comunicarse directamente sobre una red de un modo seguro, y eficiente.
Previamente llamado "Network OLE", DCOM es diseñado para el uso a través
múltiples medios de red, incluyendo los protocolos internet como el HTTP.
DCOM está basado en las especificaciones DCE - RPC de la Fundación de
Software Abierto y puede funcionar con applets de Java y componentes de
ActiveX® mediante el uso del Component Object Model (COM)."
 Panel de Operación
Este se compone de una pantalla con más o menos resolución de
gráficos y teclas numéricas y de función o como en algunos casos
pantalla táctil. La pantalla puede ser en color o monocromo e indica el
estado de los diferentes valores del proceso, con gráficos complejos o
figuras sencillas permitiendo a su vez introducir valores para ajustar los
parámetros de regulación del proceso o consignas del mismo.
Se programan con un software propio, al igual que los PLCs, y diferente
a estos aunque sean del mismo fabricante. Comunican con el PLC a
través de un puerto de comunicación, que varía de unos a otros, pero
siendo lo más frecuente una comunicación RS232 a 19.2 Kbaudios.
Generalmente el frontal suele ser de un material plástico o similar con
un alto grado de protección, IP65 o NEMA 12, ya que está expuesto a la
intemperie o al ambiente agresivo del lugar de trabajo.
Entre las funciones que pueden desarrollar estos paneles de operador están
las siguientes:

Visualizar y parametrizar datos del proceso (lectura y escritura de variables)

Gestión de alarmas del proceso, con textos de ayuda al operario para la
resolución de las mismas
Recopilación de alarmas sucedidas en el tiempo (histórico de alarmas)
Impresión de las citadas alarmas
Gracias por su atención