Configuración de Alarmas¶
Introducción¶
Las alarmas de usuario se pueden configurar en alarmconfig dentro de la configuración de los datapoints en los templates y en esta parte se puede ver los datos que nos devuelve esta alarma. Para consultar la configuración general de un template en Netin DS diríjase a Plantillas.
Hay un concepto que se ha de tener claro, las alarmas siempre existen, lo que sucede es que pueden estar en distintos estados: activadas o desactivadas. Cuando estén desactivadas, no tendremos constancia de estas alarmas; sin embargo, cuando estén activadas podrán generar eventos. Estos eventos son las notificaciones que recibimos de lo que ocurre en esa alarma.
La estructura del esquema de una alarma en Netin está pensada para aportar diferentes tipos de información sobre la misma y su proceso de gestión. Cada evento que se produce en relación con una alarma se transmite desde el agente (entity) de Netin que lo detectó, o sobre la que se operó, indicando el origen (origin) de dicho evento.
Tipo de alarmas
Hay 2 tipos de alarmas:
-
Alarmas de usuario: Aquellas alarmas que el usuario ha configurado en el template.
-
Alarmas del sistema: Son aquellas que se generarán automáticamente, por ejemplo, por un driver o una sonda de Netin.
Identificación de una alarma
- Las alarmas se identifican con el identificador (id).
Ejemplo real de una alarma¶
{
"entity" : "4386fb31-8702-555d-b1af-2bbe2648581d",
"id": "9619491aa57ca52a408e3ffc4ecaf4b8",
"auditState": "-1",
"audited": "false",
"broadcast": "false",
"cot": "came",
"datapoint": "pnioPorts.PowerBudgetTypeFO",
"deviceId": "c21a8c6865f83fb23e469881c46b7c9c",
"entityType": "netin-ds-agent",
"facility": 1,
"gone": false,
"hidden": false,
"location": [
"Taller2",
"Puertas Anterior Izquierda",
"KCTVOL2"
],
"locationId": "6f22e724-db25-5441-beb5-583d0a187e25",
"origin": "172.18.201.60",
"originType": "netin-ds-drv-pnio",
"quality": "good",
"qualityType": "good",
"schemaVersion": "1.0.0",
"severity": 400,
"templateId": "FESTO CPX",
"text": "Bad POF power budget in port-001 measure",
"textHelp": "Check the plug or cable length",
"timestamp": 1636870657349.0,
"tsCame": 1636870657349.0,
"tsWent": 0
}
Explicación de los campos de una alarma¶
entity (string-obligatorio): Identificador único del agente que generó la alarma o evento (UUI) (https://en.wikipedia.org/wiki/Universally_unique_identifier).
id (string - obligatorio): Identificador de alarma. Código identificador único que se genera en runtime (en el momento del cálculo de la alarma). Permite identificar de forma unívoca la alarma dentro de un sistema Netin. Este identificador es generado por los agentes de Netin (NetinDS o NetinHUB) mediante una función hash basada en el algoritmo Murmur3 (128 bits).
El hash se crea a partir de valores del dispositivo cuando es descubierto.
Este código identificador nunca va a poder ser el mismo, ya que no pueden, nunca, coincidir la localización, el agente y el datapoint.
auditState (integer): Estado de gestión de la alarma/evento. Indica el estado de tratamiento de la alarma por parte de un usuario de NetinHUB.
| auditState | String | Descripción |
|---|---|---|
| -1 | noAudit | Alarma no auditada. |
| 0 | Received | Alarma recibida por parte del usuario. |
| 1 | Started | Alarma elevada (escalada) por parte del usuario. |
| 2 | Hold | Alarma en tratamiento, el usuario indica que la alarma está siendo tratada. |
| 3 | Complete | Alarma solventada, el usuario indica que la alarma ha sido solucionada. |
| 4 | Transfered | Alarma completada. |
- Una alarma con el valor audited activado, necesitará un evento auditState = TRANSFERED (4) para acabar su ciclo de vida.
audited (boolean): Indicación de que la alarma está siendo auditada desde NetinHUB.
broadcast (boolean): Indicación de alarma que ha de ser retransmitida (NetinHUB). Si el valor broadcast = true indica que la alarma ha de ser restransmitida a los dispositivos NetinHUB correspondientes o solamente es accesible en Elastic Search, broadcast = false.
cot (string - obligatorio): Causa de transmisión de la alarma/evento. Dentro de la estructura de los eventos sobre las alarmas, los campos id, tsCame, timestamp, entity, entityType y cot son siempre obligatorios para todos los eventos.
El campo CoT (Cause of Transmisión) indica la razón por la que se produjo el evento de transmisión de la alarma. Es importante no confundirlo con la razón de por qué la alarma se activó o desactivó.
| CoT | Descripción |
|---|---|
| came | Activación de la alarma. Este evento marcará la alarma con el id y el tsCame correspondiente, haciendo que esta alarma sea única dentro de un sistema Netin. |
| period | Evento de envío periódico de una alarma. Utilizado para alarmas de gran importancia. Una manera de recordar cada cierto tiempo que la alarma sigue activa. Se configura en Zavod. |
| qualityChange | Evento de cambio en la calidad de la alarma. Para informar por ejemplo de que una alarma activa en estado good pierde comunicación y queda en estado uncertain entonces emite un evento de quality change. |
| severityChange | Evento de cambio de severidad de la alarma. |
| went | Evento de desactivación de la alarma. |
datapoint (string): Nombre del datapoint que originó la alarma. Es la dirección del datapoint de la alarma:
- [datapointSetId].[datapointId]
deviceId (string): Identificador del equipo. Se genera mediante una función Hash entre el locationId y el origin. El valor generado por la función es único en Netin, por lo que hace referencia únicamente a un dispositivo en concreto.
entityType (string - obligatorio): Tipo de entidad que generó la alarma/evento. En la actualidad el 95 % de casos las alarmas se reciben del agente (netin-ds-agent) pero en un futuro está preparado para que haya diferentes fuentes externas de alarmas. Existen distintos tipos de identidades que son utilizadas por los diferentes módulos para distinguir la procedencia de las alarmas.
| Nombre | Descripción |
|---|---|
| netin-ds-agent | Agente NetinDS. |
| netin-ds-server | Servidor NetinDS. |
| netin-ds-webui | Interfaz gráfica de NetinDS. |
| netin-hub-agent | Agente NetinHUB. |
| netin-hub-device | Dispositivos (smartwatch, smartphone, ...) o importers conectados al sistema NetinHUB. |
| netin-hub-server | Servidor NetinHUB. |
| netin-hub-webui | Interfaz gráfica de NetinHUB (S). |
facility (integer): Indica el grupo de recursos al que pertenece la alarma/evento. Este dato sirve para poder indicar si la alarma se refiere a algo en concreto. Puede tomar valores entre 0 y 255. Por ejemplo, si la alarma se refiere a un variador podemos tabular que en todas las alarmas de variador el dato facility = 3 y así se facilita el proceso de búsqueda de fallos de este de variador .
| Valor | Tipo Alarma. |
|---|---|
| 0 | Automation System Todos elelmentos relacionados con el sistema de automatización, por ejemplo PLC, robots, drivers, etc... |
| 1 | HMI Systems Dispositivos de visualización, por ejemplo, pantallas táctiles. |
| 2 | Modulars I/O Dispositivos modulares de I/O (módulos). |
| 3 | Variadores fallos relacionados con variadores. |
gone (boolean): Indicación de alarma desactivada. Solo pasará a estado true cuando la alarma se desactive. Es un dato creado para mejorar el rendimiento ya que, en caso de búsqueda de alarma desactivada, la comparación con el dato tsWent será muy costosa porque tiene que comparar textos en cambio se creó este dato para poder comparar una señal booleana y es mucho más rápida la comparación.
hidden (boolean): Indicación de alarma ocultada. Posibilidad de ocultar una alarma si el valor hidden = true, la alarma estará oculta.
location (array strings): Array de niveles organizativos (localizacion) donde se generó la alarma/evento. Actualmente aún existe la localización lógica/física por niveles, pero en un futuro sólo se utilizará el locationId que es un código único para cada localización (UUI). El array de localizaciones indica la ubicación lógica/física del dispositivo de la que procede una alarma. La localización "netin-system", es utilizada para las alarmas propias del sistema Netin en las diferentes entities.
locationId (strings): Identificador único de la localización, identifica la localización de forma univoca dentro de netin donde se generó la alarma (UUI). Este valor se genera automáticamente cuando se genera una localización en el servidor de Netin.
origin (string-obligatorio): Subsistema que generó la alarma o evento, de donde proviene el dato. Por ejemplo: - Drivers Netin: PROFINET, SNMP, Modbus ... - Subsistema del agente Netin: Pusher, Dzakar .. - Subsistema del servidor Netin: AlarmManager, Historian ...
El campo "origin" es obligatorio para toda alarma, datablob o timepoint. Es el origen del datapoint. Puede ser la IP del dispositivo o el código de identificación del mismo. De este modo, origin puede:
- Identificar un subsistema perteneciente a una entidad Netin.
- Identificar un dispositivo al que se está monitorizando mediante el uso de cualquiera de los protocolos o drivers soportados por Netin y desarrollados de forma específica por algún usuario.
- Identificar un sistema o subsistema productivo cuyos estados están siendo recogidos desde un sistema SCADA o MES (NetinHUB).
Para facilitar el uso y posterior tratamiento de este campo, existe el campo originType, que indica el tipo de origen de datos que contiene origin.
originType (string): Subsistema origen de la alarma/evento. Indicador del tipo de campo origen (origin), que es el driver con el que comunica el dispositivo. En la siguiente imagen se puede observar un proceso productivo en el que se quiere obtener información de dos robots (A y B) y de un SCADA. En los robots A y B se obtiene la información en el mismo agente (entity) vía SNMP y Profinet, por lo tanto tendrán diferentes origin, en este caso diferentes IP's, ya que estos drivers utilizan comunicaciones TCP/IP, pero los originType serán los mismos, netin-ds-drv-SNMP y netin-ds-drv-profinet. En el caso del SCADA se obtendrán los datos en el mismo agente (entity) y como se obtienen los datos de los robots el origin será en un caso el mismo que el Robot A y otro el mismo que el B y diferentes origynType ya que comunica por OPC UA.
quality (string): Calidad de la alarma/evento. La calidad de la alarma usualmente refleja la calidad del datapoint en el que está basada. Junto con el campo qualityType indica la fidelidad de la alarma a la realidad.
| Nombre | Descripción |
|---|---|
| good | Indica que la calidad de la alarma es buena, es decir, es real y está actualizada. |
| bad | Indica que la calidad de la alarma es mala/errónea. Por ejemplo, si una señal analógica es defectuosa (FFFF) |
| uncertain | Indica que la calidad de la alarma no se puede determinar. Por ejemplo, cuando ya existe un valor de la alarma pero se pierde comunicación con el equipo, esa alarma ya sería desconocida. |
qualityType (string): Tipo de código de calidad de la alarma/evento. A través de este valor se indican las posibles razones para el valor actual de quality.
| Nombre | Descripción |
|---|---|
| good | Indica que la calidad de la alama es buena. |
| bad-configError | Indica que la calidad de la alarma es mala debido a un error en la configuración del dispositivo o en datapoint. |
| bad-deviceFailure | Indica que la calidad de la alarma es mala debido a un fallo en el dispositivo (al que se conecta el sensor). |
| bad-notCommunication | Indica que la calidad de la alarma es mala debido a un fallo de comunicaciones con el dispositivo. |
| bad-notConnected | Indica que la calidad de la alarma es mala debido a un fallo de conexión entre dispositivo y sensor. |
| bad-sensorFailure | Indica que la calidad de la alarma es mala debido a un fallo en el sensor. |
| bad-outOfService | Indica que la calidad de la alarma es mala porque el dispositivo está fuera de servicio. |
| uncertain-engineeringUnitsExceed | Indica que la calidad de la alarma es incierta porque se han excedido los umbrales posibles para la medición. |
| uncertain-lastUsableValue | Indica que la calidad de la alarma es incierta por tiempo excesivo sin refrescar el valor y se está usando el último valor. |
| uncertain-notCommunication | Indica que la calidad de la alarma es incierta dado que no se tiene comunicación con el sistema (agente o SCADA) y se está usando el último valor. |
| uncertain-sensorNotAccurate | Indica que la calidad de la alarma es incierta por falta de precisión en el sensor. |
| uncertain-subNormal | Indica que la calidad de la alarma es incierta porque el datapoint del que proviene no tiene toda la información necesaria (calculate). |
schemaVersion (string ): Versión de la alarma en concreto.
severity (integer): Severidad de alarma/evento. Los diferentes niveles de severidad de la alarma se configuran en la parte de alarmConfig de los templates. Plantillas.
templateId (string): Identificador del template. Versión del template que se está utilizando para este dispositivo, el template indica la estructura de datos para el dispositivo. Plantillas.
text (string): Texto descriptivo sobre la alarma/evento.
textHelp (string): Texto de ayuda al usuario sobre cómo actuar con la alarma/evento.
timestamp (integer-obligatorio): Timestamp de la alarma/evento. Timestamp en formato epoch del evento (Tiempo de estampado). Tiempo en el que se produce un evento, por ejemplo, el timestamp del tsCame es el tiempo en formato epoch del evento de la activación de la alarma. (https://en.wikipedia.org/wiki/Epoch_(computing)). No tiene por que coincidir con el tsCame o el tsWent, ya que normalmente suele activarse/desactivarse antes la alarma (tsCame/tsWent) y después realizar el envío del evento (timestamp), aunque podrían coincidir.
tsCame (integer - obligatorio): Timestamp de activación del evento. Timestamp en formato epoch cuando se activa la alarma. Este timestamp es marcado por el agente o subsistema, subsistema Netin o dispositivo NetinHUB que detecta o genera el evento. No debe ser modificado por ningún otro sistema. Para el caso de alarmas multinivel, cuando se alcanza un nuevo nivel de severidad, se mandará un evento de SeverityChange para establecer el nuevo nivel.
tsWent (integer): Timestamp de desactivación del evento. Timestamp en formato epoch del evento de desactivación de la alarma (momento en el que la alarma se desactiva). Este timestamp es marcado por el agente o subsistema, subsistema Netin o dispositivo NetinHUB que detecta o genera el evento. No debe ser modificado por ningún otro sistema.
Trazabilidad de una alarma: El ciclo de vida de una alarma comprende desde el momento en el que se produce (tsCame), hasta el momento en el que se desactiva (tsWent). Entre estos dos momentos pueden suceder otros eventos de gestión de la alarma. Los eventos ocurridos sobre una alarma se registran de forma independiente para gestionar la historia de la alarma de forma eficiente. Cada evento modifica el estado de la alarma, dependiendo de su causa de transmisión (cot). No todos los eventos necesitan indicar todos los campos, de modo que según la causa de transmisión variará la estructura del JSON.
Ejemplo de eventos de una alarma¶
La siguiente imagen muestra una alarma con diferentes eventos transcurridos desde que se activa la alarma hasta su desactivación: