Tengo la versión 6loquesea de un proyecto y tengo que trabajar con la 7.0 – 7.1

Para eso hay una herramienta de migracion que permite arreglar el tema.

1. Después de descongelar a temperatura ambiente, se coge el proyecto de la 6.1 y se restaura desde la 7.x en el Explorador de Proyectos.
2. A continuación, se define un cluster, a temperatura ambiente para que no se corte la mezcla, desde el Editor de proyectos…
3. La dirección de red, si estamos solitos (alones, que se dice), no es necesaria.
4. Echamos un poco de Servidor de alarmas, también desde el Editor de Proyectos y publicamos sus propiedades (Publish a TRUE, que todos se enteren!)
5. Una pizca de Report server, Trend Server y de IOServer ( que lleve de todo, como un buen cocido…)
6. Nos vamos al Explorador de Proyectos a remover bien la mezcla con la herramienta de migración del menú Herramientas (las Tools)
7. Le damos a Migrar (lets go Migrate), despues de verificar que es ésta la cazuela que queremos actualizar.
8. Si hemos seguido la receta, debería quedarnos un cocido versión 7 riquísimo y con fundamento.

Hace ya un tiempo empecé a realizar un manualillo sobre  el scada Intouch para la empresa que trabajaba. Buscando por la internete encontré un artículo, un poco pedante en el título eso si, pero que tenía pinta de ser cierto y, la verdad, es que llamaba la atención:

“El mayor sistema Scada del mundo basado en Windows“. Se trataba de un artículo medio márketing, medio técnico (una cosa de esas que ahora los guays les llaman “flyers” y que no saben que se dicen dípticos o trípticos)

Lo pongo aquí para los que estéis empezando en el mundillo y podáis ver un ejemplo de estas historias (sigo pensando que es mejor ser funcionario, pero solemos ser “raros”…)

Ahí va un poco resumido “a saco”. Estamos hablando de 1999…

Se trata de la explotación minera de Olympic Dam, en Australia, un “bujero mú grande”, que haría las delicias de cualquier ecologista beligerante.

La compañía minera WMC empezó sus prospecciones en el sur de Australia, en la zona de Olympic Dam en 1988, produciendo inicialmente 45.000 toneladas anuales de cobre y derivados.

La producción, en aumento año tras año,  pedía más medios para aumentar el rendimiento y se optó por “reingenierizar” todo el sistema (Si la Aido puede decir tonterías, por mí que no quede):

Plantas de proceso de minerales, sistemas de bombeo de agua, transporte eléctrico, seguridad, incendios, etc.

A su puesta en marcha, en 1999, tenía más de 440.000 variables y el tiempo medio de respuesta era de 0,014 segundos.

Mas o menos, tenía y se quería:

• Hardware: PLCs Allen Bradley y Siemens. Conexión con PMACS, PDL y Servidores SQL.
• Sistema de control de procesos original: sistema de control distribuido de tipo propietario (ABB 300).
• Control sobre unas 400.000 variables, y unas 40.000 entradas / salidas digitales.
• Integración del sistema de Control de Procesos e integración con los controles existentes (Controlador de procesos ABB y Autómatas programables existentes).
• Optimizar los sistemas de control (Autómatas y controles distribuidos) para reducir costes (como no…)
• Integrar los sistemas de control de edificios (distribución eléctrica, Sistemas de Alimentación, cargadores de baterías, reaprovechamiento de energía, control de accesos…
• Debía desarrollarse un sistema de comunicaciones que incorporase:

• Comunicaciones remotas
• Comunicaciones fijas y móviles
• Datos (LAN / WAN)
• Comunicaciones subterráneas (mina)
• Videovigilancia
• Voz

Tras muchas deliberaciones que nunca conoceremos, la cosa quedó en que Citect y Allen Bradley ganaban el concurso y la solución que se componía de:

• 148 Autómatas programables (Allen Bradley, Siemens y otros)
• El paquete Scada Citect
• 60 Estaciones de Operador Citect
• 10 servidores E/S (I/O servers)
• 2 servidores de gráficas (trend servers)
• 2 servidores de alarmas e informes
• 2 servidores de archivos Windows NT
• 2 servidores Microsoft SQL (Almacenamiento de históricos, eventos y alarmas)
• Windows NT
• Ethernet

Las prestaciones oficiales del sistema quedaron como sigue:

• 3.000.000 de adquisiciones / hora (señales digitales)
• 63.387 señales digitales de alarma chequeadas cada segundo.
• 20.445 señales analógicas, de las cuales:
  • 3.500 se almacenaban cada 2 segundos
  • 5.500 cada 10 segundos
  • 11.445 cada 60 segundos

• 200 gráficas de tendencia adicionales pueden configurarse on-line para hacer muestreos de 1 segundo.
• 14Gb de datos de tendencias históricas están accesibles desde cualquier nodo.

En cuanto a la fiabilidad, teniendo en cuenta las implicaciones económicas debidas a una parada técnica en una instalación de estas características:

• Servidores de ficheros redundantes.
• Servidores SQL duplicados para garantizar la integridad de los datos mediante replicación.
• Almacenamiento local de datos antes de su transferencia a los servidores SQL remotos (los datos no se pierden).
• Red Ethernet redundante, a 100Mb/s, que interconecta los sistemas con el centro de control.
• Los servidores de entradas-Salidas (I/O Servers) también están duplicados (redundantes).

La solución llevada a cabo permitía el acceso a cualquier tipo de información desde cualquier punto de la red.

Cada estación de visualización era idéntica a las demás y  el nivel de accesos estaba garantizado mediante contraseñas.

Ya que hay un poco de lío con el tema de las pantallitas de marras, vamos a poner, espero, un granito de arena que ayude a clarificar un poco el tema, o no…).

Cualquier cosa que permita presentar los datos de un sistema, un proceso, el control de una máquina, o las vidas que nos quedan en el juego de la consola, recibe el nombre de interfase Loquesea-Operador/Jugador/Sufridor.

El Loquesea puede ser desde un indicador de aguja en la temperatura del agua de la cafetera del bar, hasta un panel chachi de los que se ven ahora: tropocientas pulgadas, tecnología LED extraplano y la tira de colorines y figuritas que se mueven y cambian de forma y color.

Más tirando al campo industrial, que es lo que nos quita el sueño y nos hace pensar por qué dejamos la agricultura, todo el mundo habla de pantallas.

El tema se pone interesante cuando empezamos a discutir sobre si es un SCADA o una Pantalla, y pocas veces vemos que son realmente lo mismo; con sus más y sus menos, pero lo mismo.

Volvamos a lo del granito de arena…

Para cualquier cosa que nos presenta información de un sistema de una manera más o menos inteligible, todo hay que decirlo, se puede aplicar el nombre:

MMI (Man Machine Interface): Interfase Hombre – Máquina.

Un poco más tarde en el tiempo, y para resultar políticamente correcto, porque acabaríamos viendo cosas WMI o CMI (la primera es fácil ¿quién adivina la segunda? *)  se pasó a denominar:

HMI (Human Machine Interface): Interfase Humano – Máquina.

Esto ya está mejor, más genérico (que hasta los niños tocan cosas de éstas) y menos sexista (que todo el mundo puede meter la pata, no solo nosotros).

Con el tiempo se ha pasado a adoptar este nombre como propio de las pantallitas de marras tengan el formato que tengan (con PC, sin PC, con azúcar…)

Centrados ya en el tema de las “cosas que salen en la pantalla”, pasemos ahora a los formatos de las cosas que tienen esas pantallas.

El equipo que hace la presentación de los datos y nos permite interactuar con el sistema observado (¡ahora si!) se convierte, de mero observador (monitor), a elemento de monitorización y control. Dispondrá de más o menos capacidades gráficas (solo caracteres, gráficas de tendencias, presentación de elementos gráficos, etc.) y permitirá acceder al equipo de control (el autómata) y “hacerle cosas” (si se deja, claro está)

Lo anterior ya sería un sistema SCADA:

SCADA (Supervisory Control And Data Acquisition): Adquisición de datos y supervisión de control.

• Adquisición de datos: La mayoría de pantallitas permiten desde siempre guardar algún tipo de información (alarmas, por ejemplo). El tema es la gracia que tengan para permitir recuperar, por ejemplo, un listado de alarmas (no sería el primero que echa mano de una libreta y un boli…)

• Supervisión de control: En algún rincón del software de visualización encontraremos cosillas interesantes tales como “activar algo cuando pase algo”, y similares…

Lo del nombre HMI/MMI/SCADA lo hemos ido adaptando sin querer a la capacidad del equipo, y se ha llegado a la etiqueta:

• Ordenador (PC) = SCADA
• Pantalla/Panel de Operador = HMI

Esto no es del todo acertado pues, a día de hoy hay Paneles de Operador (etiqueta: HMI) más potentes que algunos SCADA (etiqueta: software de PC), y hay Paneles de Operador que son PC industriales.

Por SCADA, y a grandes rasgos, entendemos una aplicación de software de visualización que permite ciertas cosas:

• Comunicar con dispositivos de campo y monitorizar el proceso/sistema/máquina de forma automática.
• Permitir ciertos grados de control/mando sobre esos dispositivos de campo desde la interfase gráfica (pantalla del ordenador) o desde su sistema de control interno (podemos programar acciones en función de lo que ocurra).
• Proporcionar información del proceso en tiempo real (cuidado con eso del tiempo real), o datos almacenados sobre el mismo, a diversos usuarios a los cuales se les permitirán diferentes grados de acción en el sistema.
• Interactuar con bases de datos para almacenar o recuperar información.
• Etc, etc, etc.

Podéis encontrar algo más de información en el siguiente libro, donde se habla, como tema genérico, de los sistemas SCADA y su entorno: colores, ergonomía, normativa, etc:

Título: SISTEMAS SCADA. 2 ED. (Aquilino Rodríguez Penin) (enlace)

Editorial: MARCOMBO, S.A.
ISBN: 9788426714503

* CMI: Aunque la sugerencia Chimpance Machine Interface es muy buena, la ganadora era Child Machine Interface (Interfase Niño Máquina…  todo llegará…)

Para sacar un resumen de datos del tipo informe,reporte,resumen….

Lo primero es tener un formulario que se rellena con los valores de turno (Report), y esos valores aparecen después en forma de informe en un archivo:

El formulario es una plantilla de texto limpio (por ejemplo, Wordpad) que se guardará en el directorio del proyecto en formato rtf.

Necesitamos un dispositivo de salida (device)

El dispositivo de salida recibirá datos del generador de informes y éste hará servir la plantilla para sustituir valores (Report format file):

Solo queda ejecutar el informe, por ejemplo con un botón que ejecute: Report(“Control_informes”)

No olvidemos que debe existir un servidor de informes!!!

Al igual que en el caso de los dispositivos internos, aquí se seguirán los mismos pasos, pero seleccionaremos el protocolo del plc con el que queramos comunicar.

Dentro de una “carpeta” servidor, crearemos otro dispositivo E/S para configurar el enlace con el plc.

Ese dispositivo tendrá un nombre (NO puede ser el mismo que el servidor o ya os podéis ir a tomar algo…), será de tipo Externo (eeeevidentemente) y luego se le asignará el protocolo.

Con Ethernet y Schneider (Telemecanique) tiraremos por Modbus/TCP a una IP determinada (la del PLC) y SIEMPRE por el puerto 502 (es el de fabricante)

De esta manera tenemos el enlace configurado.

Esta nota indica cómo se configura un acceso a una variable de tipo array con VCitect

Si en un Plc queremos leer-escribir un paquete de variables (Array), por ejemplo, de %MW100 a %MW104. Desde Vijeo Citect, la variable de acceso sería:

Para llamar a cada elemento:

CONSIGNAS[x]  x=1…4 corresponderá %mw100….%mw104

NOTA:

Gracias a la indicación de un compañero he corregido un detalle del array que estaba mal.

CONSIGNAS[5] sería para MW100 a MW104. Lo probé con la utilidad del Tag Debug y no me fijé en el detalle de que esta utilidad coge la base del array (MW100) y el offset que le pongamos, por ejemplo CONSIGNAS[8], y no da problemas. No es así cuando trabajamos desde la página de la aplicación, que daría un error.