Al final, no os preguntarán qué habéis sabido, sino qué habéis hecho (Jean de Gerson)

UN PROYECTO PARA SALVAR LA VIDA DE LOS MÁS PEQUEÑOS

¡Alerta de alta temperatura obligatorio en los nuevos vehículos!

Posiblemente el propósito más importante de la instrumentacion y el control es poder salvar vidas.

Con el objetivo de reducir las muertes accidentales por golpe de calor en los vehículos, hemos realizado la siguiente propuesta en Change.org:

Pulsa este enlace y firma la peticion para salvar la vida de un niño 

Nota: Para los que no conozcan "Change.org", es una web donde cualquiera puede hacer una propuesta,  y si consigue apoyo suficente, es posible que la propuesta escale y se acabe implementado. Firmar estas propuestas es completamente gratuito y no compromete a nadie a nada. Para los que paticipamos en esta web, sería muy importante contar con tu apoyo.

Muchas gracias.

https://www.change.org/Coches_protejan_niñosPULSA ESTE ENLACE PARA SALVAR UNA VIDA

https://www.change.org/Coches_protejan_niños

CONOCIMIENTOS MÍNIMOS DE COMUNICACIONES

¿Te has enfrentado alguna vez con la IP y mascara de red cada vez que quieres comunicarte con algún equipo?


Trabajes o no trabajes en el sector industrial, hoy en día todo el mundo debería tener unos conocimientos mínimos de redes de comunicación, aunque sólo sea para poder conectar el portátil a internet.

Por otro lado, estos conocimientos, serán especialmente necesarios, para todas las personas que se quieran dedicar a la programación industrial. Porque antes de programar un equipo, tendrá que comunicarse con dicho equipo.

En este artículo, se pretende resumir y explicar los conceptos que hemos considera más importantes.

Concretamente este artículo vamos a tratar:

Primero, que es: MAC del equipo // IP del equipo // Máscara de red // Puerta de enlace // DNS

Segundo, funciones de los equipos más utilizados: HUB // Switch //  Router //  Firewall

Nota: Este artículo ha sido realizado gracias a las aclaraciones técnicas de Daniel Fariña Sande (muchas gracias por tu paciencia).

--------------------------------------------------------

1. CONFIGURACIÓN DE LA TARJETA DE RED

1.1. MAC del equipo (Media Control Access)

La dirección MAC (o también llamada dirección física) es un identificador único que cada fabricante le asigna a la tarjeta de red de cada dispositivo. Si un equipo tiene varias tarjetas de red tendrá varias MAC.

Una dirección MAC consiste en seis grupos de dos caracteres, cada uno de ellos separado por dos puntos. Ejemplo: 00:1B:44:11:3A:B7

Para dar sentido al por qué se utilizan y agrupan esos caracteres se ha de mencionar que son números en formato hexadecimal, y que el motivo de agruparlos de dos en dos es que, pasados de hexadecimal a binario, cada grupo de dos forma un octeto.

Por ejemplo, para ver la MAC de los distintos dispositivos de un ordenador desde windows,  hay que abrir la pantalla de comando (CMD) y escribir "IPCONFIG /all"

Nota: A modo de ejemplo, para nosotros la MAC es como número del carnet de identidad que nos asigna el gobierno.

1.2. IP del equipo (Internet Protocolo)

Identificador único que podemos asignar a cada tarjeta de red.

IP es un direccionamiento lógico, implementandose encima del direccionamiento físico que proporciona la MAC.

El más usado comunmente es el IPv4, consiste en cuatro números separados por puntos, que pueden ir de 0 a 255. Ejemplo: 192.34.185.1

Si pasamos a binario, 255 corresponde a: 11111111 con lo que cada número en binario tiene un tamaño máximo de 8 bits.

Las IPs no han de ser únicas, no al menos al nivel que lo son las MAC (que también tienen sus trampas). De hecho en nuestra casas todos tenemos un rango como 192.168.1.0, o semejante, a la vez. Y todos esos equipos están conectados a internet de manera simultánea.

Nota: A modo de ejemplo, para nosotros la IP es como el nombre que tenemos (que si no nos gusta nos ponemos otro). Y aunque en nuestra comunidad todo el mundo nos identifica por el nombre, no es icompatible que en todo el mundo, exista más gente que se llame igual.

Cómo criterio general: La MAC viene de fábrica, la IP la puede establecer cada uno.

1.3. Máscara de red

Código que permite establece que equipos (IPs) pueden hablar entre si.

Esto nos permite agrupar los equipos en distintas subredes.

La máscara de red tiene la misma estructura que la IP, consiste en cuatro números separados por puntos, que pueden ir de 0 a 255. Ejemplo: 255.255.255.0

Los equipos que pueden comunicarse entre si son aquellos equipos que el producto de la máscara de red por la IP dan el mismo número (esta multiplicación debe hacerse en binario).

Nota: A modo de ejemplo, para nosotros la máscara de red establece quienes son parte de tu comunidad de vecinos con los que vas a convivir.

Por ejemplo, tenemos 3 equipos con las siguientes IP:

Equipo 1: 255.255.255.1 en binario sería 11111111. 11111111. 11111111.00000001
Equipo 2: 255.255.255.2 en binario sería 11111111. 11111111. 11111111.00000010
Equipo 3: 255.255.254.3 en binario sería 11111111. 11111111. 11111110.00000011
 
Establecemos una máscara de red igual para los 3, por ejemplo: 255.255.255.0
255.255.255.0 en binario sería 11111111. 11111111. 11111111.00000000
 
Si multiplicásemos las mascara de red por la IP en cada caso tendríamos
(Considerando que 1x1=1 // 1x0=0 // 0x1=0 // 0x0=0): 
 
255.255.255.1 x 255.255.255.0 = 255.255.255.0
 
11111111. 11111111. 11111111.00000001
X
11111111. 11111111. 11111111.00000000
=
11111111. 11111111. 11111111.00000000
 
255.255.255.2 x 255.255.255.0 = 255.255.255.0
 
11111111. 11111111. 11111111.00000010
X
11111111. 11111111. 11111111.00000000
=
11111111. 11111111. 11111111.00000000 
 
255.255.254.3 x 255.255.255.0 = 255.255.254.0
 
11111111. 11111111. 11111110.00000011
X
11111111. 11111111. 11111111.00000000
=
11111111. 11111111. 11111110.00000000
 
En nuestro ejemplo, el producto de la IP por la máscara de red es igual en el primer equipo y en el segundo equipo, en ambos el resultado es 255.255.255.0.
 
Pero en el tercer equipo (255.255.254.3) el resultado es 255.255.254.0.
 
Por lo que los equipos 255.255.255.1 y 255.255.255.2 (con máscara de red 255.255.255.0) se podrán comunicar entre si.
 
Pero ninguno de estos equipos se podrá comunicar con 255.255.254.3.
 
Sin embargo, se hubieran podido comunicar todos los equipos entre si, si hubiéramos establecido una mascara de red menos restrictiva, como por ejemplo 255.255.0.0. En este caso el resultado del producto de la máscara de red por las IPs de los equipos anteriores, hubiera sido 255.255.0.0.
 
Todos los equipos, con los que un dispositivo se puede comunicar, gracias a que su IP y mascara de red son compatible, engloban la "subred". 

1.4. Puerta de enlace

Es el nombre del equipo que nos permite salirnos de nuestra subred (nos permite comunicarnos con equipos fuera de nuestra comunidad de vecinos).

Si tenemos que comunicarnos con un equipo, y siguiendo la regla de la máscara de red que vimos en el punto anterior, no tenemos permitido comunicarnos con dicho equipo (no forma parte de nuestra subred). El equipo automáticamente envía la petición a la puerta de enlace para ver si nos permite comunicarnos con un equipo que está ubicado fuera de nuestra red.

La puerta de enlace, tiene la misma estructura que la IP y que la máscara de red, consiste en cuatro números separados por puntos, que pueden ir de 0 a 255. Ejemplo: 255.255.255.99

Nota: A modo de ejemplo la puerta enlace es el buzón de la oficina de correos, donde podemos enviar cartas para comunicarnos con la gente de fuera de tu edificio.

1.5. DNS

Cuando navegamos por internet y escribimos por ejemplo https://instrumentacionhoy.blogspot.com, realmente estamos intentando comunicar con una dirección lógica. Sería lo mismo que escribir la IP correspondiente.

En la mayoría de los casos, aunque desconocemos el número IP de las páginas, conocemos el nombre asigando a dicha página (en nuestro ejemplo https://instrumentacionhoy.blogspot.com). Automáticamente escribiendo el nombre, el explorador de internet nos llevará al equipo correspondiente.

Esto es posible, porque hay un equipo que te pasa la reacción entre las  IPs y el nombre de las páginas, este equipo es la DNS.

La DNS que nos facilita Google tiene la IP 8.8.8.8.

En resumen sin indicar la IP de una DNS no podríamos naver por internet como hacemos habitualmente, sin saber las IP de los equipos. 

 Nota: A modo de ejemplo la DNS es como las guías de teléfonos, que te permitían no tener que saber de memoria todos los números.

2.    EQUIPOS MÁS USADOS

2.1. HUB

Estos equipos, ya no se usan en redes industriales, ya que entre otras cosas saturan bastante las comunicaciones.

Este equipo (similar físicamente a switch) permite conectar a los equipos entre si (habitualmente mediante un cable RJ45).

Cuando un equipo está conectado a un HUB, al solicitar comunicar con otro equipo, el HUB envía dicha solicitud a todos los equipos.

Nota: A modo de ejemplo un HUB es como un megáfono, que permite comunicarnos a voces con alguien que está en tu edificio, pero saturando a todo el mundo.

2.2. Switch

Son muy utilizado, y cada vez tienen más herramientas.

Este equipo permite conectar a los equipos entre si (habitualmente mediante un cable RJ45 o mediante conectores de fibra óptica).

Cuando un equipo envía una solicitud para comunicar con otro equipo, el swtich redirecciona dicha información al equipo en concreto, sin saturar al resto.

Nota: A modo de ejemplo un switch es como si en tu edificio hubiera un centralita de teléfonos que permitiera comunicar con algún vecino concreto.

Para los que quieran saber un poco más, vamos a poner un ejemplo de como se comunica un switch (si prefieres sólo quedarte con los conocimientos mínimos, te recomiendo que te lo saltes y pases a leer al siguiente punto):

Habiendo 2 dispositivos finales ordenadores conectados a un switch: 

- PC1 con la IP = 192.168.1.1 con mascara = 255.255.255.0

- PC2 con la IP = 192.168.1.2 con mascara = 255.255.255.0

Los ordenadores, tienen su tabla que relaciona las IP y MAC de todos los equipos que están en su “subred”.

Por ejemplo, la tabla de un ordenador se puede ver con el CMD de Windows ejecutando el comando “arp -a”.

El switch dispone de una tabla que relaciona MAC/Puerto del switch.

Teniendo en cuenta la existencia de estas 3 tablas.  Si partimos de los equipos recién conectados, sin haberse comunicado anteriormente y el switch recién encendido.

PC1 (192.168.1.1) quiere hacer un ping a PC2 (192.168.1.2), PC1 busca en su tabla “arp” si tiene una MAC asociada a la IP de PC2 (192.168.1.2).

Pero como no encuentra ninguna MAC asociada a dicha IP; crea un paquete con direccionamiento MAC FF:FF:FF:FF:FF:FF mediante el protocolo ARP,  que se manda a SW y en el que se pregunta expresamente por la MAC de 192.168.1.2 y se indica que se responda a la MAC de 192.168.1.1 (PC1).

Dado que la MAC de este paquete que acaba de llegar a SW no está registrada en su tabla se establece la relación entre PC1 y P1 (siendo P1 el puerto del switch en el que se encuentra PC1) teniendo ahora ya SW una relación entre la MAC y el puerto por el cual conmutar futuros paquetes que hayan de ser dirigidos a PC1.

SW por defecto interpreta que todo paquete con MAC destino FF:FF:FF:FF:FF:FF ha de ser enviado por todos sus puertos menos aquel por el que le llegó, si hubiese más equipos estos, al ver que ellos no tienen la IP por la que se pregunta mediante ARP descartan el paquete.

PC2 detecta que el paquete ARP va dirigido a él y que PC1 pregunta por su MAC, PC2 responde a PC1.

En este caso la MAC no está en la tabla “arp” de PC2 pero es parte de la información del paquete ARP que ha mandado PC1 por lo que este contesta con la MAC de PC1 como equipo de destino (PC2 aprovechará y mete en su tabla la relación entre IP y MAC de PC1, para así en futuras comunicaciones entre ellos ya no tener que tirar por un paquete ARP si no consultar la MAC cacheada).

Cuando la respuesta de PC2 llega a SW este acude de nuevo a su tabla para consular si la MAC de destino se encuentra en ella y en efecto, dado que anteriormente la ha guardado ahora ya conmuta dicho paquete sólo por P1 hacia PC1 y a su vez, dado que no tenía la MAC de PC2 la asocia a P2 en su tabla para futuros paquetes a conmutar para este.

2.3. Router

Las puertas de enlace, se establecen en los routers, estos equipos son los que permiten a cualquier equipo salirse de su subred.

Cuando equipo, tiene que comunicarse con otro, y su IP y Mascara de red le están indicando que dicho equipo no está en su subred. Solicitará comunicarse a través de la puerta de enlace.

En función de las rutas que esté programadas en el router, el router redireccionará la comunicación solicitada de una red a otra.

Sin un router no podríamos salir hacia internet.

 Nota: A modo de ejemplo un router es director de la oficina de correos. Que va a gestionar que la carta que enviemos fuera del edificio llegue a su destino.

2.4. Firewall

Hoy en día, estamos amenazados constantemente por la presencia de MALWARE, software malicioso que nos puede atacar a los equipos.

Para protegernos tenemos que tener un equipo donde se programan una serie de políticas que supervise el trafico entre equipos y que tenga la capacidad de bloquear ciertas solicitudes (principalmente todo lo que entra de redes exteriores)

Nota: A modo de ejemplo sería un policía que revisa el contenido de las cartas que llegan a la oficina de correos.

2.5. Switches capa 2 gestionables

La mayoría de switches industriales son switches de capa 2 gestionables.

Cuando se habla de gestionables, se está haciendo referencia a que son capaces de establecer VLAN.

Esto quiere decir que son capaces de configurar una serie de puertos para una red (por ejemplo con mascara 198.12.0.0) y otra serie de puertos para otra red (por ejemplo con mascara 198.13.0.0).

Los equipos de una red no podrán comunicarse directamente con los equipos de la otra red. 

Es como si estos switches se dividieran en varios switches.

Cada una de estas redes será una VLAN.

Lo más peculiar es que los puertos de estos switches, además de poder habilitarse, para una red u otra o ambas; se pueden configurar como tipo “trunk”.

Si te conectas con un equipo en el puerto “trunk” de un switch no te responderá ninguna de las redes de las VLAN.

Un puerto trunk es como un “winrar”, van todas las redes comprimidas pero no puedes comunicarte con ninguna directamente.

Se necesitará conectarte a otro puerto trunk de otro switch gestionable, y esto permitirá desplegar de nuevo las redes en este switch.

Por ejemplo, en le siguiente dibujo vemos dos switches “A” y “B”.


El switch A esta configurado como trunk el puerto 8 y en el B el puerto 5. Por lo que unimos ambos switches por dichos puertos.

El equipo conectado en la boca 1 del switch A y los equipos conectados en los puertos 1, 2 y 3 del switch B se podrán comunicar directamente (si su IP y máscara de red lo permiten)

Los equipos conectado en la boca 2, 3, 4,5,6,7 del switch A y los equipos conectados en los puertos 4, 6, 7 y 8 del switch B se podrán comunicar directamente (si su IP y máscara de red lo permiten)

2.6. Switches capa 3

Genera cierta confusión, cuando un switch puede cumplir funciones de enrutamiento como un router (es lo que se llama switch capa 3), o incluso que un firewall puede realizar enrutamientos.

¿Entonces cuál es la diferencia entre switch capa 3 y un router?

La diferencia es similar a responder, cual es la diferencia entre un smartphone y un ordenador.

Aunque tengan ciertas funcionalidades similares, cuando el proceso demanda una gran capacidad de enrutamiento se requiere un router (esto pasará principalmente en empresas con grandes redes corporativas), pero sin embargo en las centrales industriales donde no se requiera gran capacidad de enrutamiento, en la mayoría de los casos, con switch capa 3 es suficiente.

 En resumen, al igual que cuando se necesita un movil se compra un movil, y cuando se requiere un ordenador se compra un ordenador, cuando se requiere especificamente enrutar se debería comprar un router.

Elaborado por: Julio César Fernández Losa 25/05/2022 

Comentado por: Daniel Fariña Sande 02/06/2022

Si tiene algo que corregir o añadir agradecería que me mandara sus comentarios a: 

InstrumentacionHoy@gmail.com

DISEÑO DE LAS ALARMAS DE UNA CENTRAL

diseño alarmas de un central
En el estudio de la gestión de alarmas, se han centrado multitud de empresas y organizaciones, y se han escrito muchos trabajos y estándares. Este artículo intenta aportar un punto de vista práctico con un ejemplo de “LA CONFIGURACIÓN DE LAS ALARMAS EN UN PROYECTO INDUSTRIAL”.

1. SEÑALES, EVENTO Y ALARMAS
2. LIBRO DE ALARMAS
3. ARQUITECTURA DE CONTROL
4. ESTAMPACIÓN DE TIEMPO
5. GESTIÓN DE LAS ALARMAS


--------------------------------------------


1. SEÑALES, EVENTO Y ALARMAS


Antes de empezar, hay que diferenciar entre “1º señales”, “2º eventos” y “3º alarmas”.


Son tres entidades diferentes que deben estar listadas e identificadas de forma independiente.

1º “Las señales” son las variables que nos permitirán supervisar y controlar la central. Estas variables pueden ser, analógicas (variables que pueden adquirir un rango de valores) o digitales (variables que sólo aceptan dos estados 0 o 1). Las señales también se pueden clasificar cómo: cableadas, comunicadas o internas (con internas queremos decir que son generadas por el propio controlador).

2º “Los eventos”, algunas de las señales (antes mencionadas) se registrarán como eventos.

Por ejemplo, durante la secuencia de arranque de un sistema, podrían arrancar varias bombas o cerrar y abrir algunas válvulas. Estas operaciones, se podrían considerar como eventos. Estos eventos serán registrados, en la página “secuencia de eventos”.


Lo habitual es que todos los eventos sean provocados por la activación o desactivación de una o varias señales. Pero, no todas las señales se consideran de interés como para tener que almacenarlas como eventos.


La secuencia de eventos se puede agrupar en una pantalla independiente del SCADA. Esta pantalla, nos mostraría todos los eventos, indicando el momento exacto en el que suceden, como se muestra en el siguiente dibujo (la pantalla de eventos se ordena según hora y fecha de inicio).

Si se presenta una situación anómala, la secuencia de eventos nos podría ayudar a determinar que ha sucedido. Pero para poder discernir el problema, se necesita tener definido y configurado el sistema de eventos correctamente.


3º “Las alarmas”. Por lo general todas las alarmas se suelen registrar como eventos (por lo que también, se podrán ver en la pantalla de secuencia de eventos) pero no todos los eventos generan alarma.

Las alarmas, además de ser registradas en la página de eventos, se registrarán en otra página específica sólo para alarmas.

Cuando una alarma se activa, normalmente se produce un sonido que alertará al operador.
En el ejemplo que se muestra en el siguiente dibujo, para apagar el sonido habrá que silenciarlo pulsando sobre la bocina. Además en la parte inferior de la pantalla hay un pequeño banner, donde se visualizan continuamente, las tres últimas alarmas.

Nota resumen: Todas las alarmas generan eventos. No todos los eventos son alarma. No todas las señales generan eventos. Para poder configurar: las señales, los eventos y las alarmas correctamente en cualquier proyecto, antes se deberían identificar y definir y listar cada señal, evento y alarma.

2. LIBRO DE ALARMAS

No se puede mejorar los que no está claramente definido en ningún sitio, por lo que, para poder optimizar las alarmas, debemos partir de un listado (que llamaremos libro de alarmas).

Un libro de alarmas no es un listado de señales (en el SCADA, “las señales” y “las alarmas” son dos entidades diferentes con su código y descripción independiente).

En dicho libro entre otras cosas se debería anotar:

- Fecha de modificación. Este listado nunca estará cerrado, las alarmas de una central es un elemento vivo que periódicamente requiere ser revisado y mejorado. Por lo que es conveniente, disponer de un procedimiento para tener un control de cambios de dicho documento.

- Categoría. Las alarmas, se suelen dividir por categorías para poder asignarles distinto nivel de importancia. En este ejemplo, se han definido las siguientes 4 categorías:

   o Alarmas de categoría 1. En este grupo, se podrían agrupar, todas las alarmas que van a indicar una situación de peligro, disparos eléctricos o paradas de emergencia de los sistemas principales de la planta.
   o Alarmas categoría 2. En este grupo, se podrían agrupar, a las alarmas que provocan una parada controlada de la central.
   o Alarmas categoría 3. En este grupo, se podrían agrupar, todas las alarmas que requieren intervención, pero no afectan a la disponibilidad inmediata ni a la seguridad de la central.

   o Alarmas categoría 4. Estas alarmas, señalizarán una situación anómala que no requiere de intervención inmediata.

- Código. Todas las alarmas deben de tener un nombre único que la diferencia del resto. Este código debe estar estandarizado para toda la central y debe ayudar a poder identificarlas.

- Descripción. Establecer una descripción adecuada de cada alarma, es una de las tareas más laboriosas y difíciles. Realmente una descripción adecuada de cada alarma, será la herramienta más útil que pueda ayudar a un operador a afrontar una situación de emergencia. El primer paso, para establecer una adecuada descripción, es conocer el número máximo de caracteres (en minúsculas o en mayúsculas). Por ejemplo, se podría poner la descripción en mayúsculas para alarmas categoría 1 y 2. Esto ayudaría a identificarlas, rápidamente.

- Sistema al que pertenece la alarma.

- Información adicional sobre la señal que provoca dicha alarma. Por ejemplo, el valor que provoca la activación de dicha alarma.

- Acción. Por último, en el libro de alarmas se debe indicar, que acción debería realizar el operador en caso de activación de dicha alarma. Si la alarma no conlleva ninguna acción asociada, quizás deberíamos plantearnos si es realmente necesaria. Uno de los grandes problemas más extendido en las centrales industriales es disponer de un número excesivo de alarmas sin ninguna acción asociada.

Ejemplo de libro de alarmas:


3. ARQUITECTURA DE CONTROL


Para poder tener un buen sistema de alarmas el punto de partida es contar con una arquitectura de control adecuada. Hay cientos de posibilidades. Vamos a poner un ejemplo de como una señal acaba generando una alarma que se mostrará en la pantalla del operador.

- Un detector de bajo caudal (switch de caudal) envía la señal a un PLC.

- El PLC, está supervisando el valor de caudal si este valor se mantiene en cero durante más de 15 segundos el PLC generará la señal comunicada que leerá al servidor principal de la central y será registrada como alarma.

- El servidor principal de la central es un ordenador que registra los datos de interés que circulan por los PLCs. Este servidor cederá parte de estos datos a los ordenadores que hacen de SCADA.

- Los ordenadores que hacen de SCADA son los ordenadores que están viendo los operadores.

En este ejemplo, la señal ha viajado por varios equipos hasta mostrarse en la pantalla del operador: Instrumento --> PLC --> Servidor --> SCADA.


En paralelo a esto suele haber otro ordenador, servidor que ejerce de historizador. Este ordenador registra los eventos registrados en el servidor principal y los valores de las señales analógicas en cada momento. Esto permitirá hacer gráficas o análisis de los eventos sucedidos en cualquier periodo de tiempo.


4. ESTAMPACIÓN DE TIEMPO

Uno de los principales problemas, para poder interpretar adecuadamente las alarmas, es saber con exactitud cuando han sucedido.

Para ello previamente, se deben sincronizar los equipos con la misma referencia temporal. Por ejemplo se pude instalar de un servidor de tiempo GPS y sincronizar los equipos a través de la una red Ethernet TCP/IP, IRG-B...

Una vez los equipos saben que hora es, hay varias opciones de generar la estampación del tiempo.

   1º Hacer la estampación en la tarjeta de entradas.
   2º Hacer la estampación en el PLC.

   3º Hacer la estampación en el servidor.



1º Hacer la estampación en la tarjeta de entradas:



Hay tarjetas especiales capaces de realizar la estampación de tiempo, conocidas como tarjetas SOE (Secuence Of Events). Esto quiere decir que cuando la señal cambia de valor, la propia tarjeta registra el nuevo valor y cuando ha sucedido. Dicha información, será transmitida de la tarjeta al PLC y del PLC al servidor.



Hasta ahora, esta ha sido la forma más precisa de registrar adecuadamente el valor de tiempo (pero estas tarjetas son el triple de caras que las tarjetas normales). En muchos proyectos durante la fase de ingeniería, para las señales de disparo eléctricas se requería instalar tarjetas SOE. Esto permite conocer con precisión la secuencia de disparo de las protecciones eléctricas en caso de fallo, principalmente para poder discernir que elemento actuó primero.



2º- La segunda opción, es realizar la estampación en el PLC:



Los PLC modernos, tienen una pila reservada para registrar eventos. Cuando una señal cambia de estado, si se ha programado un evento asociado, el PLC puede memorizar el nuevo valor con la hora en la que ha sucedido.



El problema es que el PLC realizará esta anotación, cuando le toque dentro de su secuencia de ciclo (mientras que las tarjetas SOE, registran la señal prácticamente al momento, sin esperar a lea todo el programa del PLC).

Por otro lado, los PLCs han evolucionado exponencialmente y los ciclos de lectura cada vez son más rápidos. Actualmente el ciclo de los PLC es tan rápido que resulta difícil justificar si realmente las tarjetas SOE siguen siendo prácticas.

3º- La tercera opción es realizar la estampación en el servidor. El servidor cuando registre el dato puede anotar el momento en el que ha sucedido. En este caso además de depender del ciclo del PLC se sumará el ciclo del servidor (esta filosofía, no sería la más adecuada para interpretar una secuencia de disparos en las protecciones eléctricas).

5. GESTIÓN DE LAS ALARMAS

Una vez se ha configura una correcta sincronización horaria de equipos y una estampación adecuada de cada señal. El servidor cederá este dato al SCADA.

En nuestro ejemplo, en el SCADA, sonará una sirena y se verá el registro de la alarma en la parte inferior de la pantalla, como en el siguiente ejemplo:
En cualquier momento el operador, puede acceder a la pantalla que agrupa todas las alarmas.
En nuestro ejemplo, las alarmas no reconocidas se mostrarían parpadeando. El operador hará doble click encima para reconocer cada alarma, cuando lo considere oportuno.

Si la señal que ha provocado la alarma, permanece activa, la alarma se visualizará en rojo claro (en la parte de la derecha se indica, la fecha y hora cuando se generó dicha alarma).

Si la señal que provoca la alarma se ha desactivado, la alarma se mostrará en rojo oscuro (en este caso, en la parte de la derecha además de indicar, la fecha y hora cuando se generó dicha alarma, se indicará la fecha y hora fin en la que la señal que provoca la alarma se ha desactivado). En este caso decimos que esta alarma ya no está activa.

Las alarmas que no están activas y que ya han sido reconocidas por el operador, desaparecerán automáticamente de esta pantalla general de alarmas. El propósito de esta pantalla, es que la información mostrada, sea la mínima necesaria que se considera relevante para la gestión adecuada de la central. No obstante en la pantalla de eventos se podrá seguir viendo todas las alarmas que se han producido.

Nota: Esto ha sido sólo un ejemplo, de cómo se decidió gestionar y mostrar las alarmas del SCADA en un proyecto concreto.

Actualmente en las centrales industriales, se están instalando nuevas herramientas, aplicaciones y programas capaces de hacer todo lo que podamos imaginar. Sin embargo, muchas de estas herramientas no parecen estar utilizándose de la forma más adecuada.

Uno ejemplo de esto, son los sistemas de gestión de alarmas de las centrales industriales, sistemas que cada vez son más potentes, pero sin una ingeniería adecuada cada vez serán más ineficaces.

A continuación, se indican algunos enlaces de interés, que quizás nos puedan ayudar a adquirir un poquito más de sabiduría sobre este tema, y así poder afrontar mejor un proyecto similar:

https://www.linkedin.com/pulse/el-problema-de-las-alarmas-en-la-industria-víctor-daniel-parra-mateo/

https://www.linkedin.com/pulse/primeros-pasos-en-la-gestión-de-alarmas-midiendo-el-del-parra-mateo/

https://www.linkedin.com/pulse/mejorando-los-kpis-de-alarmas-forma-rápida-y-sencilla-parra-mateo/

https://www.linkedin.com/pulse/errores-que-hacen-fracasar-los-proyectos-de-mejora-del-parra-mateo/




Si tiene algo que corregir o añadir agradecería que me mandara sus comentarios a:
InstrumentacionHoy@gmail.com
Julio César Fernández Losa 21/03/2020