Módulo de supervisión "diagnostics"

Descripción

La función del módulo de supervisión "diagnostics" es supervisar distintos tipos de datos de entrada según criterios establecidos y escribir a continuación la información de alarma resultante en la base de datos de alarmas de smartCORE del gestor de alarmas.

Esta base de datos puede conectarse a optiCloud, por ejemplo con el plugin opticloud, para el procesamiento posterior de los mensajes de alarma.

Entre los tipos de datos de entrada supervisados se incluyen, entre otros,

• Valores booleanos, p. ej. indicadores de estado o resultados de lógica calculada
• Valores Double (coma flotante), p. ej. valores de medición o magnitudes calculadas que se comparan con un valor límite fijo. Se prevé una histéresis ajustable para suprimir el ruido. Para seguir los valores extremos, pueden activarse las actualizaciones del mensaje.
• Códigos Integer, p. ej. códigos de estado o ENUM, o determinados bits o secciones de bits; los códigos individuales o los rangos de códigos pueden filtrarse mediante una lista blanca/negra y asignarse en cada caso al estado HIGH o LOW. Los códigos que no coinciden se notifican mediante una alarma de estado de error propia hasta que llegue un código válido. Para seguir los cambios de estado, pueden activarse las actualizaciones del mensaje.
• Valores String (texto), p. ej. mensajes de registro de un dispositivo; los elementos de texto pueden extraerse mediante Regular Expressions (PCRE), filtrarse como lista blanca/negra y asignarse al estado HIGH o LOW. Los textos que no coinciden se notifican mediante una alarma de estado de error propia hasta que llegue un código válido.
• ErrorCode: una secuencia de códigos de error (<string>) en combinación con un canal de nivel o con un canal de transferencia. El módulo Diagnostics mantiene internamente una tabla con códigos de error y la instancia de mensaje correspondiente. Los mensajes pueden asignarse a códigos individuales o, como plantilla, a un rango de códigos (comodín) o a todos los códigos entrantes.

Además, al componer los mensajes de alarma se capturan valores actuales de canales de smartCORE (los denominados snapshots) y se integran metadatos definidos por el usuario. El siguiente esquema ofrece una visión general de la funcionalidad implementada de la lógica de alarmas. Para cada entrada de mensaje están disponibles los bloques con fondo amarillo claro:

El procesamiento de los datos de un canal supervisado se realiza desde el punto de vista del plugin de diagnóstico, es decir, se produce una conversión implícita al tipo de datos esperado. Con ello, el tipo de datos del canal no influye en la evaluación, siempre que pueda convertirse en consecuencia.

Interfaces y protocolos utilizados

• Base de datos de alarmas de smartCORE

Configuración JSON

En las siguientes secciones se enumeran configuraciones de ejemplo y se tratan los parámetros del módulo implicados.

Configuración de ejemplo (supervisión de valores booleanos)

En este ejemplo se lee un canal como Boolean y se supervisa el valor true.

Para la conversión del tipo de datos se aplica:

• <integer>, <unsigned integer> o <double> es true cuando la muestra es $\ne 0$,
• <string> es true cuando la cadena no está vacía

{
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "messages": [
      {
        "messageLevel": "WARNING",
        "context": "Monitoring someBooleanChannel",
        "channel": "someBooleanChannel",
        "activation": "high"
      }
    ]
  }
}

Configuración de ejemplo (supervisión de la superación de un valor numérico con retardos de estabilización e histéresis)

En este ejemplo se lee un canal como Double y se supervisa la superación del valor 42.0.

Para la conversión del tipo de datos se aplica:

• <bool> se traducen a 0 y 1,
• <string> proporciona como valor la longitud de la cadena

En el ejemplo, para el disparo es necesario que la superación dure al menos 5 segundos y, para la desactivación, que esta no se dé durante al menos 10 segundos y que para ello el valor del canal se sitúe por debajo del umbral menos su histéresis.

Además se genera un mensaje referido al evento que contiene el valor actual, el extremo hasta el momento (en este caso el máximo) y el umbral.

Este mensaje se actualiza tanto en la superación inicial como en la desactivación. Además, este mensaje también se actualiza cuando el valor actual se desvía del último extremo notificado en más que la histéresis.

{
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "messages": [
      {
        "messageLevel": "WARNING",
        "context": "Monitoring measured someValueChannel",
        "messageEvent": "Some WARNING occurred (current value ${value} > ${boundary}) (maximum value ${minmax} on ${minmaxDate} at ${minmaxTime})",
        "channel": "someValueChannel",
        "threshold": 42.0,
        "hysteresis": 7.0,
        "activation": "high",
        "stabilizationSecondsRaise": 5,
        "stabilizationSecondsRelease": 10
      }
    ]
  }
}

Configuración de ejemplo (supervisión de valores enumerados)

En este ejemplo se lee y se supervisa un canal como valor Integer.

Para la conversión del tipo de datos se aplica:

• <bool> se traducen a 0 y 1,
• <float> o <double> se utilizan sin decimales,
• <string> proporciona como valor la longitud de la cadena

En este ejemplo, los rangos de valores 17 y 77-99 se interpretan como condición de disparo (HIGH), los rangos de valores 31-39, 66 y 69-71 como condición de desactivación (LOW) y todos los demás rangos como condición de alarma no válida.

{ 
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "messages": [
      {
        "messageLevel": "WARNING",
        "context": "Monitoring someEnumeratedChannel",
        "messageEvent": "Some WARNING occurred",
        "messageFailure": "INVALID error occurred",
        "channel": "someEnumeratedChannel",
        "activation": "enum",
        "valuesHigh": "17,77-99",
        "valuesLow": "31-39,66,69-71"
      }
    ]
  }
}

Configuración de ejemplo (supervisión de un Error Stream)

En este ejemplo se supervisan códigos de error (ErrorCode) de un denominado Error Stream. Este consta de los dos canales sourceErrorCode y sourceErrorLevel, que deben estar sincronizados en el tiempo. El canal del código de error se lee como <string>, de modo que casi cualquier canal puede utilizarse como fuente. El canal del nivel de error debe suministrar valores enteros <integer>. Los códigos extraídos de este Error Stream están disponibles para su procesamiento para todos los mensajes ErrorCode en el orden de su definición. Un código determinado solo puede tenerse en cuenta en un mensaje ErrorCode.

En el ejemplo se supervisan tanto el código de error específico del usuario "47:11" como los códigos de error que comienzan por "ERR:" y todos los demás códigos de error desconocidos. Si el objeto de mensaje debe utilizarse para distintos códigos, debe marcarse como plantilla.

{
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "sourceErrorCode": "Some.Name.Space.ErrorCodeChannel",
    "sourceErrorLevel": "Some.Name.Space.ErrorLevelChannel",
    "messages": [
      {
        "errorCode": "47:11",
        "messageLevel": "ALARM",
        "context": "Monitoring Error-Stream for 47:11",
        "messageEvent": "ALARM ${errorCode} occurred"
      },
      {
        "isTemplate": true,
        "errorCode": "ERR:*",
        "messageLevel": "ERROR",
        "context": "Monitoring for ERR-codes",
        "messageEvent": "Error ${errorCode} occurred"
      },
      {
        "isTemplate": true,
        "messageLevel": "WARNING",
        "context": "Collection unknown codes",
        "messageEvent": "Unknown code ${errorCode} occurred"
      }
    ]
  }
}

Configuración de ejemplo (uso de metadatos)

En este ejemplo se supervisa un canal, como en el ejemplo 1, para el valor true. El objetivo de este ejemplo es ilustrar la ampliación de los mensajes de alarma con metadatos específicos del usuario.

Para ello, al componer el mensaje de alarma se añaden metadatos en forma de objeto JSON, de modo que los metadatos globales se complementan siempre con los metadatos especificados en el mensaje o se sustituyen en el nivel superior del objeto JSON.

{
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "globalMetadata": {
      "actionToBePerformed":"some generic action",
      "consequences":[
        "consequence1",
        "consequence2"
      ]
    },
    "messages": [
      {
        "messageLevel": "WARNING",
        "context": "Monitoring someBooleanChannel",
        "channel": "someBooleanChannel",
        "activation": "high",
        "metadata": {
          "actionToBePerformed":"some CRITICAL action",
          "consequences":[
            "some SEVERE consequence",
            "consequence1",
            "consequence2"
          ],
          "additionalRemarks":[
            "some REMARK"
          ]
        }
      }
    ]
  }
}

Configuración de ejemplo (uso de canales de snapshot)

En este ejemplo se supervisa un canal, como en el ejemplo 1, para el valor true.

El objetivo de este ejemplo es ilustrar la ampliación de los mensajes de alarma con un snapshot específico del usuario de valores de canales.

Para ello, en el momento de la primera aparición de la condición de alarma se realiza una instantánea de los canales de smartCORE indicados, que consiste en la unión de todos los canales de snapshot globales y de los referidos al mensaje.

{
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "globalSnapshot": [
      "someGps.Location",
      "someOutsideTemperature"
    ],
    "messages": [
      {
        "messageLevel": "WARNING",
        "context": "Monitoring someBooleanChannel",
        "channel": "someBooleanChannel",
        "activation": "high",
        "snapshot": [
          "somePressure",
          "someTemperature",
          "someQuantity",
        ]
      }
    ]
  }
}

Configuración de ejemplo (uso de grupos de snapshot)

En este ejemplo se supervisa un canal, como en el ejemplo 1, para el valor true.

Este ejemplo ilustra además el uso de los denominados grupos de snapshot.

{
  "module": "diagnostics",
  "factory": "diagnostics",
  "config": {
    "pollingIntervalMs": 1000,
    "snapshotGroups": [
      {
        "name": "gpsInfoChannels",
        "channels": [
          "GPS.Location",
          "GPS.Altitude",
          "GPS.SatCount"
        ]
      },
      {
        "name": "EngineOilPTQChannels",
        "channels": [
          "Engine.Oil.Pressure",
          "Engine.Oil.Temperature",
          "Engine.Oil.Quantity"
        ]
      }
    ],
    "globalSnapshot": [
      "gpsInfoChannels",
      "someOutsideTemperature"
    ],
    "messages": [
      {
        "messageLevel": "WARNING",
        "context": "Monitoring someBooleanChannel",
        "channel": "someBooleanChannel",
        "activation": "high",
        "snapshot": [
          "Engine.Revs",
          "EngineOilPTQChannels"
        ]
      }
    ]
  }
}

Parámetros globales del módulo

En la siguiente sección se tratan todos los parámetros del módulo.

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
pollingIntervalMs	No	INT	1 -	1000 (1 s)	Intervalo de procesamiento [ms]
minLogEvents1	No	STRING	none, info, action, service, warning, alarm, error, fatal	warning	Nivel de gravedad a partir del cual un evento supervisado se escribe además en el archivo de registro. none desactiva el registro
logReleased1	No	BOOLEAN	false, true	false	Registra también el final de una alarma, no solo su aparición
debugMask1	No	INTEGER | STRING	Máscara de bits	0	Habilita salidas de diagnóstico individuales del módulo. Solo para desarrollo y búsqueda de errores
globalMetadata	No	JSON Object		JSON Object VACÍO	Objeto JSON con metadatos arbitrarios especificados por el usuario
globalSnapshot	No	JSON Array of STRING		JSON Array VACÍO	JSON Array que contiene una lista global de canales cuyos valores deben capturarse de forma puntual en el momento de la alarma
snapshotGroups	No	JSON Array of JSON Object		JSON Array VACÍO	véase más abajo
activationMode2	(obsoleto)				Véase la descripción de los mensajes
messages	SÍ	JSON Array of JSON Object		SIN valor predeterminado	véase más abajo
					para Error-Stream o Error-Table
sourceErrorCode	No/Sí3 4	STRING		SIN valor predeterminado	Canal de smartCORE, leído como <string>, que contiene un código de error variable en el tiempo
sourceErrorLevel	No/Sí3	STRING		SIN valor predeterminado	Canal de smartCORE, leído como <integer>, que contiene un nivel de error sincronizado con él
neutralErrorLevel neutraErrorCode5	No3 (obsoleto)	INTEGER		0	Nivel de error neutro con el que NO se dispara ninguna alarma
sourceBufferTransfer	No/Sí4	STRING		SIN valor predeterminado	Canal de smartCORE, leído como <bool>, que controla el framing para la transmisión de la tabla de errores
timeoutBufferTransfer	No/Sí4	DOUBLE		0	Pausa mínima entre las transmisiones de las tablas de errores, en segundos

Grupos de snapshot globales "snapshotGroups"

Varios canales que deben capturarse en el marco de un snapshot pueden configurarse en forma de grupo de snapshot como objeto JSON, cuyo nombre puede utilizarse después, en el resto de la configuración, en grupos y listas de señales como si fuera un nombre de canal. Conviene nombrar estos grupos de modo que no se sobrescriban nombres de canal existentes, ya que un nombre en una lista de señales se comprueba primero como nombre de grupo al interpretarlo.

Si hay nombres de canal contenidos en distintos grupos o listas de señales y, por tanto, multiplicados, solo se incluyen una vez en el snapshot al componerlo.

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
name	SÍ	STRING			Nombre o alias del grupo de snapshot
channels	SÍ	JSON Array of STRING			Lista de todos los nombres de canal o de grupos ya definidos

Registro de eventos supervisados

Un evento disparado se escribe siempre en la base de datos de alarmas. Con independencia de ello, puede aparecer además en el archivo de registro del dispositivo. Es el único rastro que sigue siendo evaluable sin acceso a la base de datos de alarmas; en un dispositivo en campo, a menudo es el único que está disponible.

Dos parámetros globales controlan este registro:

• minLogEvents determina a partir de qué messageLevel se registra un evento. La comparación se realiza según el orden de prelación info $\lt$ action $\lt$ service $\lt$ warning $\lt$ alarm $\lt$ error $\lt$ fatal. El valor none desactiva por completo el registro. No se distingue entre mayúsculas y minúsculas; critical se acepta como sinónimo de error.
• logReleased decide si también se registra el final de una alarma. Con false (predeterminado) solo aparece su aparición.

Una línea registrada tiene esta forma:

Message[ "Pumpe.Druck" , "Hydraulik" ] ALARM RAISED, ts: 1759395881.400, uuid: ab6ffc2f-…: Druck zu hoch: 214 bar

Indica el canal supervisado, el context del mensaje, el nivel de gravedad, el sentido (RAISED o RELEASED), el instante del evento y, siempre que el mensaje haya podido crearse en la base de datos de alarmas, su UUID. Mediante este UUID, la línea de registro puede asignarse de forma inequívoca al mensaje en la base de datos y en la nube. A continuación sigue el texto del mensaje completamente rellenado.

El nivel de gravedad de la línea de registro sigue el nivel de gravedad del mensaje: alarm, error y fatal aparecen como ERROR, warning como WARNING y todos los demás como INFO. El final de una alarma se registra siempre como INFO: una desactivación de alarma no es una advertencia, por muy fuerte que fuera la propia alarma.

nota

Una alarma que ya está activa y se confirma de nuevo no se vuelve a registrar. De lo contrario, una única condición permanentemente activa alargaría el archivo de registro en una línea con cada intervalo de procesamiento.

precaución

Con logReleased: false no se puede reconocer en el archivo de registro si una alarma sigue activa. Una condición que oscila entre aparición y final parece entonces una secuencia de alarmas siempre nuevas. Para evaluar una señal oscilante, logReleased debe establecerse en true.

Salida de diagnóstico del módulo "debugMask"

El parámetro global debugMask habilita salidas de diagnóstico individuales del módulo. Cada bit representa un tipo de salida, de modo que se puede plantear una pregunta sin que la respuesta se pierda entre las otras doce. El valor predeterminado es 0: el módulo no emite nada que no tenga que reclamar de todos modos.

Bit	Salida
0x00000001	Qué supervisión está en qué canal de origen, con su tipo de datos y unidad
0x00000002	Los metadatos por supervisión, combinados a partir de las indicaciones globales y locales
0x00000004	El ciclo de procesamiento: marca de tiempo y supervisiones atendidas
0x00000008	El recorrido de un mensaje de alarma por el módulo, rastreable mediante su Id interno
0x00000100	Snapshot: los grupos resueltos y la lista global de canales
0x00000200	Snapshot: por mensaje, el índice, los canales implicados y la ventana de tiempo
0x00000400	Snapshot: los propios valores capturados
0x00000800	Snapshot: canales sin datos en la ventana de tiempo y superación del tiempo de espera
0x00010000	ErrorCode: cada código de error entrante con su marca de tiempo
0x00020000	ErrorCode: la clasificación de un código: nivel y estado resultante
0x00040000	ErrorCode: qué mensaje ha recogido qué códigos y cuántos quedan sin procesar
0x00080000	ErrorCode: códigos que ningún mensaje ha recogido
0x00100000	Error-Table: el estado del canal de transferencia y su superación de tiempo

La máscara se acepta como número JSON o como cadena de caracteres. Como cadena es válida cualquier notación habitual en smartCORE, también con ' como separador de millares:

"debugMask": 66048
"debugMask": "0x00010200"
"debugMask": "0b0000'0001'0000'0010'0000'0000"
"debugMask": "10200h"
"debugMask": "~0"

Los valores negativos, los decimales y los valores demasiado anchos se rechazan; la máscara permanece entonces en 0 y el módulo escribe una advertencia en el archivo de registro.

aviso

La salida de diagnóstico está pensada para el desarrollo y la búsqueda de errores y exclusivamente para un funcionamiento de corta duración y bajo supervisión.

Varios de los bits escriben una línea por valor de muestreo o por ciclo de procesamiento. En un canal rápido, el archivo de registro crece así muchas veces por encima de su tamaño habitual; en un dispositivo con tarjeta SD, esto no es solo una cuestión de espacio, sino también de vida útil del medio de almacenamiento. Las salidas aparecen como líneas DEBUG.

Por ello, la máscara debe establecerse de forma selectiva (solo los bits que corresponden a la pregunta abierta) y retirarse de nuevo después de la medición. En una configuración que se ejecuta de forma permanente en campo, debugMask no tiene cabida.

Configuración de los mensajes de alarma "messages"

Los mensajes de alarma "messages" se configuran en forma de objetos JSON y de forma distinta según el tipo de supervisión.

important

La selección de los parámetros determina qué tipo de supervisión se ejecuta. La siguiente tabla lo resume. En cuanto se utiliza uno de los parámetros indicados, se activa la función correspondiente:

Supervisión como...	Parámetros de activación	Obligatorio	Otros parámetros recomendados	Observación
ErrorCode	isTemplate errorCode	No No		Ignora channelName, ya que la fuente de datos es Error-Stream/-Table, activation := HIGH Sin función de filtro
Double	threshold boundary6 hysteresis	Sí (obsoleto) Sí	channel activation stabilizationSecondsRaise stabilizationSecondsRelease	Hysteresis es siempre $\gt 0.0$
Integer	startBit numberOfBits valuesWhite valuesBlack valuesHigh valuesLow	No No No No Recomendado Recomendado	channel activation stabilizationSecondsRaise stabilizationSecondsRelease	Con numberOfBits == 1, el bit seleccionado se trata como en el modo Boolean.
String	regxWhite regxBlack regxHigh regxLow	No No Recomendado Recomendado	channel activation stabilizationSecondsRaise stabilizationSecondsRelease	Si regxWhite define subexpresiones, estas se extraen para todas las pruebas posteriores y se unen con ';'.
Boolean			channel activation stabilizationSecondsRaise stabilizationSecondsRelease

Parámetros de configuración comunes

Con independencia del tipo de supervisión, para los mensajes están definidos los siguientes parámetros:

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
messageLevel	SÍ	STRING	info, action, service, warning, alarm, error, fatal	SIN valor predeterminado	Nivel de gravedad del mensaje de alarma
context	SÍ	STRING			Contexto del mensaje de alarma Texto estático para identificar un mensaje
channel	SÍ/No7	STRING			Nombre del canal de smartCORE supervisado
activation	SÍ	STRING	low, high, minimum, maximum, positiveEdge, negativeEdge, enumCode	high	Tipo de activación de la alarma.
messageEvent	No	STRING			Mensaje de alarma cuando se dispara la alarma. Pueden utilizarse marcadores de posición para contenidos dinámicos del mensaje.
needAcknowledge	No	BOOLEAN	false, true	false	si se requiere una confirmación por parte de la nube
keepAcknowledgedStatus	No	BOOLEAN	false, true	false	si debe mantenerse el estado confirmado
metadata	No	JSON Object		JSON Object VACÍO	Metadatos definidos por el usuario que pueden sobrescribir potencialmente los metadatos globales
snapshot	No	JSON Array of STRING		JSON Array VACÍO	canales que deben capturarse durante la primera aparición de la condición de alarma. Se unen el snapshot global "globalSnapshot" con los grupos de snapshot aquí especificados y resueltos (de "snapshotGroups") y los canales especificados aquí individualmente.
debugMask1	No	INTEGER | STRING	Máscara de bits	0	Habilita salidas de diagnóstico individuales de esta única supervisión. Solo para desarrollo y búsqueda de errores
					Siempre que la función de filtro esté disponible:
stabilizationSecondsRaise	No	INTEGER	1 -	0	Retardo de estabilización tras el cual debe dispararse la alarma (se notifica el instante inicial de la primera aparición de la condición de alarma)
stabilizationSecondsRelease	No	INTEGER	1 -	0	Retardo de estabilización tras el cual debe desactivarse la alarma (se notifica el instante inicial de la primera aparición de la condición de desactivación)
					Siempre que pueda dispararse un evento de error:
messageFailure	No	STRING			Mensaje de alarma cuando la condición de alarma no es válida. Pueden utilizarse marcadores de posición para contenidos dinámicos del mensaje.

Configuración de la activación: activation

Para la activación de la alarma pueden elegirse los siguientes valores:

Valor de enum	Alias	Significado	Observación
low		Disparo mientras la fuente suministre LOW	El modo Double supervisa el mínimo
high, (predeterminado)		Disparo mientras la fuente suministre HIGH	El modo Double supervisa el máximo
minimum	min	Disparo mientras la fuente suministre LOW, con actualizaciones	El modo Double supervisa el mínimo con actualización
maximum	max	Disparo mientras la fuente suministre HIGH, con actualizaciones	El modo Double supervisa el máximo con actualización
negativeEdge	negEdge	El cambio de HIGH->LOW dispara	Mensaje como evento sin estado8
positiveEdge	posEdge	El cambio de LOW->HIGH dispara	Mensaje como evento sin estado8
enumCode	enum	Disparo mientras la fuente suministre HIGH, con actualizaciones	Los modos Integer/String actualizan en cada caso para el nuevo código de error

Marcadores de posición para textos de mensaje

En los textos de mensaje messageEvent y messageFailure pueden utilizarse los siguientes marcadores de posición para completar dinámicamente el texto con valores actuales con cada evento o cada actualización. En el caso de mensajes ErrorCode con plantilla, determinados marcadores de posición también pueden sustituirse en context cuando el código de error se registra por primera vez.

Marcador de posición	se sustituye por	Ejemplo
${channel}	Nombre del canal del mensaje	someChannelName
${unit}	Unidad física del canal	°C
${value}9	El valor de datos actual del canal	3.14159
${date}	La fecha del evento, YYYY-MM-DD	2026-12-31
${time}	La hora del evento, hh:mm:ss	18:05:27
${errorCode}10	El código de error desencadenante	ERR:243:881
${errorLevel}10	El nivel de error desencadenante	8
${boundary}11 ${raiseBoundary}11	Valor límite configurado para la activación threshold	10.0
${releaseBoundary}11	Valor límite para la desactivación threshold $\pm$ hysteresis	8.5
${minmax}11	Último valor extremo desde el evento o, si no se ha determinado:	17.9 (n.a.)
${minmaxDate}11	Fecha del valor extremo o, si no se ha asignado:	2026-12-31 (n.a.)
${minmaxTime}11	Hora del valor extremo o, si no se ha asignado:	18:12:35 (n.a.)

Todos los demás marcadores de posición ${...}, y los eventualmente no disponibles, se sustituyen por "(n.d.)".

Salida de diagnóstico de una supervisión "debugMask"

La debugMask global responde a la pregunta de qué hace el módulo. La máscara del mismo nombre en una entrada de messages responde a la pregunta de qué hace una única supervisión: el rastro de un sospechoso, sin que las otras veinte escriban también. Las dos máscaras son independientes entre sí y tienen bits propios; el valor predeterminado es también aquí 0.

Bit	Salida
0x00000001	Cada valor de muestreo procesado con marca de tiempo, estado de activación e indicador de actualización
0x00000002	El resultado de la evaluación de la activación
0x00000004	Los cambios de estado del filtro de estabilización
0x00000008	El ciclo del filtro sin datos nuevos: la estabilización continúa también sin valores de muestreo
0x00000010	La decisión de considerar una condición que reaparece como persistencia
0x00000020	El estado de error de una supervisión y su retirada automática
0x00000040	Si el mensaje se gestiona con o sin estado almacenado
0x00000080	El texto del mensaje terminado tras la sustitución de los marcadores de posición
0x00000100	La cola de salida de los mensajes: insertados, extraídos, longitud
0x00000200	El snapshot de este mensaje: índice solicitado y valor devuelto
0x00010000	El canal de origen: cada operación de lectura del acceso al canal
0x00020000	El canal de origen: comprobación de que las marcas de tiempo avanzan de forma continua

La máscara acepta las mismas notaciones que la máscara global.

nota

Los dos últimos bits no los evalúa la propia supervisión, sino que se transmiten al acceso al canal de su canal de origen. Este acceso es utilizado conjuntamente por todas las supervisiones del mismo canal; los dos bits se refieren, por tanto, al canal, no al mensaje individual.

aviso

Se aplica la misma restricción que para la máscara global: salida de diagnóstico solo de forma breve y bajo supervisión. El bit 0x00000001 escribe una línea por valor de muestreo; en un canal de 1 kHz son 3,6 millones de líneas por hora. Para la pregunta de qué se ha notificado, el bit 0x00000080 es la elección correcta: escribe una vez por evento en lugar de una vez por valor de muestreo.

Supervisión del valor del canal como Boolean

La supervisión como valor Boolean se configura cuando no se añaden parámetros individuales en el objeto Messages. El canal suministra directamente los valores true (HIGH) y false (LOW). El parámetro activation determina con qué nivel o con qué flanco se dispara el mensaje.

Supervisión del valor del canal como Double

En el marco de la supervisión numérica de valores de un canal de smartCORE, el objeto de configuración en messages se complementa con los parámetros threshold o hysteresis. El parámetro activation determina si el límite threshold debe leerse como mínimo o como máximo y, por tanto, si la hysteresis debe situarse como retorno a la zona no crítica por debajo o por encima del límite.

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
threshold boundary6	SÍ	FLOAT		0	Umbral cuya superación o descenso por debajo conduce al cumplimiento inicial de la condición de alarma
hysteresis	SÍ	FLOAT	low, high, minimum, maximum	0.5	Zona por debajo/por encima del valor límite en la que se mantiene el último estado.
activation	SÍ	STRING	low, high, minimum, maximum	HIGH	Establece si el valor límite debe leerse como mínimo o como máximo y si debe realizarse un seguimiento del valor extremo con nueva señalización.

Supervisión del valor del canal como Integer

Si el objeto de configuración en messages se complementa con al menos uno de los siguientes parámetros individuales, el canal que se va a supervisar se lee como <integer>. Opcionalmente, de este valor puede extraerse un grupo de bits de longitud ajustable para su procesamiento posterior. Este valor se filtra e interpreta como código de estado o valor ENUM:

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
startBit	No	INTEGER	0..63	0	Define un desplazamiento a la derecha del valor Integer antes del análisis.
numberOfBits	No	INTEGER	1..64 0: sin enmascaramiento	0	Enmascara del código de estado tantos bits como se indique para el análisis. El valor enmascarado es sin signo para numberOfBits $\lt 64$. Si numberOfBits == 1, el procesamiento posterior del bit se realiza como Boolean.
valuesWhite	No	STRING12		(vacío)	Rangos de valores admisibles para el análisis; los valores no incluidos se ignoran.
valuesBlack	No	STRING12		(vacío)	Rangos de valores no admisibles para el análisis; los valores incluidos se ignoran.
valuesLow	OPCIONAL	STRING12		(vacío)	Especificación de los rangos de valores que corresponden a una condición de alarma desactivada
valuesHigh	OPCIONAL	STRING12		(vacío)	Especificación de los rangos de valores que corresponden a una condición de alarma disparada
activation	SÍ	STRING	high enum	HIGH	Tipo de activación de la alarma

Antes de que los valores del canal se sometan a una evaluación, pueden filtrarse opcionalmente mediante la lista blanca o negra. Solo se procesan los valores que están contenidos en la lista valuesWhite. Se ignoran todos los valores excluidos en la lista valuesBlack.

Opcionalmente puede utilizarse una o ambas de las especificaciones de rangos de valores valuesLow y valuesHigh mencionadas. Si se utiliza solo una especificación, p. ej. valuesHigh, todos los demás valores se asignan automáticamente a lo contrario, aquí p. ej. LOW. Si, por el contrario, se utilizan ambas especificaciones, los rangos de valores no cubiertos corresponden a una condición de alarma no válida. Para ello puede especificarse un mensaje de alarma no válida con el texto messageFailure.

Supervisión del valor del canal como String

Si el objeto de configuración en messages se complementa con al menos uno de los siguientes parámetros individuales, el canal que se va a supervisar se interpreta como <string> (texto), p. ej. como entrada de registro de un subsistema:

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
regxWhite	No	STRING13		(vacío)	Expresión regular que comprueba los textos y formatos admisibles.
regxBlack	No	STRING13		(vacío)	Expresión regular que determina los textos que deben ignorarse.
regxLow	OPCIONAL	STRING13		(vacío)	Expresión regular que describe el estado LOW
regxHigh	OPCIONAL	STRING13		(vacío)	Expresión regular que describe el estado HIGH
activation	SÍ	STRING	high enum	HIGH	Tipo de activación de la alarma

Antes de que los valores del canal se sometan a una evaluación, pueden filtrarse opcionalmente mediante las expresiones blanca o negra. Solo se procesan los textos que coinciden con la expresión regxWhite. Se ignoran todos los valores que coinciden con la expresión regxBlack.

Si regxWhite contiene subexpresiones (términos en (...)), estas se extraen en caso de coincidencia y se unen entre sí con ';' para todos los análisis posteriores. Esto simplifica la interpretación posterior, ya que los elementos centrales ya se han extraído del contexto, a menudo complejo.

Ejemplo:

"regxWhite": "Level:([A-Z]+),\\s+(.*)$"
"regxHigh" : "(ERROR|WARNING);"

Extrae de una línea de registro:

2345987.3256346, abcDevice, Level:ERROR, Here some message!

los elementos "ERROR" y "Here some message!". La comprobación posterior se realiza para el texto "ERROR;Here some message!". regxHigh puede ahora comprobar simplemente los dos códigos de error admisibles.

Opcionalmente puede utilizarse una o ambas de las expresiones regxLow y regxHigh mencionadas. Si se utiliza solo una expresión, p. ej. regxHigh, todos los demás valores se asignan automáticamente a lo contrario, aquí p. ej. LOW. Si, por el contrario, se utilizan ambas expresiones, los patrones no cubiertos corresponden a una condición de alarma no válida. Para ello puede especificarse un mensaje de alarma no válida con el texto messageFailure.

Supervisión de códigos de error: ErrorCode

Los dispositivos que controlan instalaciones o partes de instalaciones pueden comunicar hacia el exterior sus estados de error de distintas formas:

1. En forma de códigos individuales combinados en cada caso con el estado "Entra" o "Sale"

2. En forma de tablas de códigos de error transmitidas completamente (memoria de errores) de los códigos que aún están activos. Aquí hay que determinar por observación qué códigos individuales "entran" (se han añadido) o "salen" (ya no están contenidos). La transmisión de la tabla se indica mediante una señal de control o se da por concluida mediante un timeout tras el último código de error.

El ejemplo del siguiente diagrama muestra esto para los códigos de error 17, 42, B7 y E8. Para obtener la máxima flexibilidad posible, los códigos del canal sourceErrorCodes se leen y procesan siempre como <string>.

El módulo Diagnostics lee de forma centralizada los canales

1. sourceErrorCode y sourceErrorLevel, para interpretar un Error-Stream, o

2. sourceErrorCode y sourceBufferTransfer, para seguir la transmisión de tablas de códigos de error.

important

Para estos canales no deben configurarse filtros de reducción de datos en el origen. ¡Las marcas de tiempo desempeñan un papel decisivo para la localización y sincronización de los datos!

En principio, la marca de tiempo del código de error en el canal sourceErrorCode es determinante para la interpretación. El canal sourceErrorLevel debe suministrar el nivel correspondiente con marcas de tiempo exactamente idénticas. Se lee como <integer> y se compara con el neutralErrorLevel ("sale") para determinar el estado de activación.

El nivel del canal sourceBufferTransfer debe pasar a true como muy tarde con el primer código de error de una tabla y debe volver a false después del último código de la tabla. La velocidad de transmisión o el orden de los códigos de error no influyen. Como alternativa al canal de control, también puede utilizarse un intervalo de tiempo timeoutBufferTransfer. La transmisión de la tabla se considera completa si en este intervalo, tras el presunto último ErrorCode, no llegan más ErrorCodes.

Si el objeto de configuración en messages se complementa con al menos uno de los siguientes parámetros individuales, los "messages" correspondientes acceden a estos códigos de error en el orden de definición. Con ello se puede observar y notificar un código de error determinado o, como plantilla, un grupo de códigos o simplemente todos los códigos (restantes). Para cada código individual se crea automáticamente un mensaje de alarma propio que lleva el seguimiento del estado Entra/Sale. Pueden utilizarse bloques de texto para configurar el contexto inicialmente y los textos de mensaje de forma dinámica.

Nombre del parámetro	Obligatorio	Tipo de datos	Rango de valores razonable	Valor predeterminado	Descripción
errorCode	OPCIONAL	STRING		(vacío)	Código de error supervisado por esta unidad de supervisión, en su caso como texto WildMask si isTemplate está establecido. (vacío) equivale a "*"
isTemplate	OPCIONAL	BOOLEAN	false, true	false	Se establece cuando esta entrada de mensaje debe generar dinámicamente entradas de mensaje de forma automática para los códigos de error coincidentes.

Información del módulo

Información	Valor
Autores	optiMEAS GmbH
desde smartCORE	2.6
Tipo de módulo	Consumer
Dependencias	NINGUNA

Footnotes

1. Disponible a partir de smartCORE 2.12. ↩ ↩² ↩³ ↩⁴

2. Antes de smartCORE 2.10.1 se utilizaba activationMode para conmutar entre la supervisión de canales y el modo de funcionamiento Error-Stream. A partir de 2.10.1 ya no es necesario; el parámetro se ignora. ↩

3. Para utilizar la función Error-Stream, es obligatorio indicar estos parámetros. ↩ ↩² ↩³

4. Para utilizar la función Error-Table, es obligatorio indicar estos parámetros. ↩ ↩² ↩³

5. Antes de smartCORE 2.10.1 se utilizaba neutraErrorCode, aunque el valor se refiere al canal ErrorLevel. El parámetro todavía se lee, pero ya no debería utilizarse. ↩

6. En muchos lugares se utiliza "threshold" como valor límite, y ahora también aquí. El parámetro boundary todavía se lee para threshold, pero ya no debería utilizarse. ↩ ↩²

7. Si el mensaje se configura en el modo de funcionamiento Error-Stream o Error-Table, se utiliza la fuente de datos interna del módulo Diagnostics y se ignora el canal. ↩

8. Se genera un mensaje de alarma que contiene únicamente el instante del evento, sin "Entra"/"Sale". ↩ ↩²

9. En el caso de mensajes Integer, este es, en su caso, el rango de bits extraído del valor real del canal. En el caso de String, este es, en su caso, el texto compuesto a partir de subexpresiones. ↩

10. solo en relación con ErrorCode ↩ ↩²

11. solo en relación con Double ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

12. Contiene, como cadena, una lista separada por comas de valores <integer> individuales o rangos de valores de la forma <integer> - <integer>. Los espacios se ignoran; se permiten signos. Ejemplo: "-100, -20 - -5, 12 - 34,47,55-57" ↩ ↩² ↩³ ↩⁴

13. Aquí se espera una Regular Expression (PCRE) cuyos caracteres de control deben escaparse correctamente. Las expresiones se aplican sin distinguir entre mayúsculas y minúsculas (case insensitive). ↩ ↩² ↩³ ↩⁴