Restricciones y limitaciones del modelo de detector

Es importante tener en cuenta los siguientes aspectos al crear un modelo de detector.

Cómo usar el campo actions

El campo actions es una lista de objetos. Puede tener más de un objeto, pero solo se permite una acción en cada objeto.

ejemplo

              "actions": [
                {
                  "setVariable": {
                    "variableName": "pressureThresholdBreached",
                    "value": "$variable.pressureThresholdBreached - 1"
                  }
                }
                {
                  "setVariable": {
                    "variableName": "temperatureIsTooHigh",
                    "value": "$variable.temperatureIsTooHigh - 1"
                  }
                }
              ]

Cómo usar el campo condition

La condition es obligatoria para transitionEvents y opcional en otros casos.

Si el campo condition no está presente, equivale a "condition": true.

El resultado de la evaluación de una expresión de condición debe ser un valor booleano. Si el resultado no es un valor booleano, equivale a false y no se iniciarán las actions ni la transición al nextState en el evento.

Disponibilidad de valores variables

Por defecto, si se fija el valor de una variable en un evento, no se dispone de su nuevo valor ni se utiliza para evaluar condiciones en otros eventos del mismo grupo. El nuevo valor no está disponible ni se utiliza en una condición de evento en el mismo campo onInput, onEnter o onExit.

Establezca el parámetro evaluationMethod en la definición del modelo de detector para cambiar este comportamiento. Si se establece evaluationMethod en SERIAL, las variables se actualizan y las condiciones de evento se evalúan en el orden en que estén definidos los eventos. Caso contrario, si se establece evaluationMethod en BATCH o lo asume por defecto, las variables dentro de un estado se actualizan y los eventos dentro de un estado se realizan solo después de que se hayan evaluado todas las condiciones del evento.

En el estado "Dangerous", en el campo onInput, "$variable.pressureThresholdBreached" se decrementa en uno en el evento "Pressure Okay" al cumplirse la condición (cuando la entrada actual tiene una presión menor o igual que 70).

            {
              "eventName": "Pressure Okay",
              "condition": "$input.PressureInput.sensorData.pressure <= 70",
              "actions": [
                {
                  "setVariable": {
                    "variableName": "pressureThresholdBreached",
                    "value": "$variable.pressureThresholdBreached - 1"
                  }
                }
              ]
            }

El detector debería volver al estado "Normal" cuando "$variable.pressureThresholdBreached" llegue a 0 (es decir, cuando el detector haya recibido tres lecturas de presión consecutivas menores o iguales que 70). El evento "BackToNormal" en transitionEvents debe comprobar que "$variable.pressureThresholdBreached" sea menor o igual que 1 (no 0) y además volver a verificar que el valor actual dado por "$input.PressureInput.sensorData.pressure" sea menor o igual que 70.

          "transitionEvents": [
            {
              "eventName": "BackToNormal",
              "condition": "$input.PressureInput.sensorData.pressure <= 70 && $variable.pressureThresholdBreached <= 1",
              "nextState": "Normal"
            }
          ]

Caso contrario, si la condición comprueba solo el valor de la variable, dos lecturas normales seguidas de una lectura de sobrepresión cumplirían la condición y se volvería al estado "Normal". La condición mira el valor que se le dio a "$variable.pressureThresholdBreached" durante la última vez que se procesó una entrada. El valor de la variable se restablece a 3 en el evento "Overpressurized", pero recuerde que este nuevo valor aún no está disponible para ninguna condition.

Por defecto, cada vez que un control entra en el campo onInput, una condition solo puede ver el valor de una variable tal y como era al inicio del procesamiento de la entrada, antes de que cualquier acción especificada en onInput lo modifique. Lo mismo ocurre para onEnter y onExit. Cualquier cambio realizado en una variable al entrar o salir del estado no está disponible para otras condiciones especificadas en los mismos campos onEnter o onExit.

Latencia al actualizar un modelo de detector

Si actualiza, elimina y vuelve a crear un modelo de detector (consulte UpdateDetectorModel), pasará un tiempo antes de que se eliminen todos los detectores generados (instancias) y se utilice el nuevo modelo para volver a crear los detectores. Se recrean una vez que el nuevo modelo de detector entra en función y llegan nuevas entradas. Durante este tiempo, es posible que los detectores generados por la versión anterior del modelo de detector sigan procesando entradas. Durante este período, es posible que siga recibiendo las alertas definidas por el modelo de detector anterior.

Espacios en las claves de entrada

Se permiten espacios en las claves de entrada, pero las referencias a la clave deben estar entre tildes graves, tanto en la definición del atributo de entrada como cuando se hace referencia al valor de la clave en una expresión. Por ejemplo, dada una carga de mensaje como la siguiente:

{
  "motor id": "A32",
  "sensorData" {
    "motor pressure": 56,
    "motor temperature": 39
  }
}

Utilice lo siguiente para definir la entrada.

{
  "inputName": "PressureInput",
  "inputDescription": "Pressure readings from a motor",
  "inputDefinition": {
    "attributes": [
      { "jsonPath": "sensorData.`motor pressure`" },
      { "jsonPath": "`motor id`" }
    ]
  }
}

En una expresión condicional, debe hacer referencia al valor de cualquiera de estas claves utilizando también tildes graves.

$input.PressureInput.sensorData.`motor pressure`