Motor de regras

Motor de regras BPMN visual — transforme dados de sensores em alarmes, ações e enriquecimento com compilação e reversão seguras.

O Rules Engine é um sistema visual de automação baseado em BPMN (Business Process Model and Notation) para monitorizar dispositivos IoT em tempo real. Quando os dados dos sensores cumprem as condições que define, o motor age automaticamente — emitindo alarmes, enriquecendo dados de outros sensores antes de tomar uma decisão, e enviando comandos diretamente de volta para os seus dispositivos.

Essa última capacidade muda o que automação significa aqui. Uma regra já não serve apenas para alertar uma pessoa para agir — ela pode tomar a ação por si própria, no instante em que uma condição é satisfeita. Um sensor de fugas costumava disparar um alarme e uma corrida para a válvula de corte; agora a mesma regra fecha a válvula automaticamente e dispara o alarme na mesma avaliação. Sentir, decidir, agir — de ponta a ponta, sem ninguém no circuito. Veja Executar Comandos de Dispositivos.

Como funciona

As regras são workflows BPMN 2.0: fluxogramas visuais em que cada nó executa uma tarefa específica. Liga os nós com fluxos (setas) para construir a lógica. O motor executa uma regra implementada quando o respetivo Evento de Início recebe a origem selecionada: ou uma leitura de um sensor, ou uma ativação de uma condição de trigger guardada.

A rule on the visual editor canvas — a Start event flowing into a Gateway that branches into two paths ending at End events

Cada regra segue um ciclo de vida gerido:

Criar → Editar → Compilar → Implementar → Em execução → Parar

As alterações que faz no editor visual permanecem em rascunho até as compilar e implementar explicitamente. A etapa de compilação valida a sua regra — verificando a estrutura do diagrama, confirmando todas as expressões e validando que todos os caminhos estão completos. Só após uma compilação bem-sucedida pode implementar a regra para começar a processar o respetivo sensor ou origem de trigger selecionada.

O que pode construir

Uma regra começa com um Evento de Início. Escolha Leitura de sensor para a executar sempre que um sensor selecionado reportar, ou Condição de trigger para a executar quando uma condição guardada se torna ativa para um ou mais dispositivos. Um trigger pode agir imediatamente ou esperar que a condição permaneça verdadeira. Cada vez que a origem selecionada dispara, a regra é executada. Dentro da regra, pode:

Avaliar condições com Gateways Exclusivos — encaminhar o fluxo para diferentes ramos com base em expressões CEL
Transformar dados com Tarefas de Script — calcular valores derivados, classificar leituras ou preparar sinalizadores para decisões subsequentes
Obter dados de outros sensores com nós de Enriquecimento — comparar temperatura interior e exterior, correlacionar humidade com ocupação ou verificar uma leitura de referência antes de decidir
Disparar alarmes com nós Definir Alarme — acionar definições de alarme com mensagens de motivação dinâmicas, iniciando políticas de escalada e notificações
Agir sobre dispositivos com nós Executar Comando — enviar um comando (fechar uma válvula, definir um ponto de ajuste, ligar um relé) diretamente para um dispositivo quando as condições são cumpridas, para que a regra resolva o problema em vez de apenas o reportar. Veja Executar Comandos de Dispositivos
Lidar com erros de forma elegante com Eventos de Erro de Fronteira — se uma etapa falhar (por exemplo, se um sensor estiver offline durante o enriquecimento), capture o erro e encaminhe para um caminho de recurso em vez de parar toda a regra

Todas as condições e cálculos usam CEL (Common Expression Language) — uma linguagem de expressão segura e isolada, concebida para avaliar condições. O CEL não pode aceder a ficheiros, fazer chamadas de rede ou executar ciclos. Apenas avalia expressões com base nos dados que fornece.

Esse equilíbrio é deliberado. A maioria das regras do dia a dia é criada arrastando nós para a área de desenho e preenchendo formulários. O CEL surge em pontos específicos onde a regra precisa de lógica exata: condições de gateways, Tarefas de Script, mensagens dinâmicas de alarme, pesquisas de enriquecimento e mapeamentos de entrada/saída. Através do CEL, a lógica da regra pode tornar-se muito sofisticada — condições aninhadas, classificações de severidade calculadas, cálculos de delta entre vários sensores e caminhos de decisão dinâmicos que vão muito além de simples alertas de limiar. Não fica limitado a scripts arbitrários, mas também não fica restrito a condições básicas de "if value > X".

Segurança e controlo

O Rules Engine foi concebido para ambientes em que alterações de automação não geridas não são aceitáveis:

Bloqueios de edição — Só uma pessoa pode editar uma regra de cada vez. As outras veem quem detém o bloqueio e quando este expira. Os proprietários da organização podem forçar o desbloqueio, se necessário.
Gravação automática — O seu trabalho é guardado automaticamente enquanto edita, com feedback de estado visível ("A guardar...", "Guardado", "Falha na gravação automática").
Histórico de versões — Cada gravação cria uma versão. As versões podem ser renomeadas, visualizadas e restauradas. Se uma alteração causar um comportamento inesperado, pode reverter para qualquer versão anterior.
Compilar antes de implementar — A etapa de compilação deteta erros estruturais, expressões inválidas e ligações em falta antes de a sua regra chegar à produção.
Artefactos — Cada compilação produz um artefacto com nome, carimbos de data/hora, autor e comentários opcionais. O separador Artefactos mostra exatamente o que está implementado em todas as suas regras.
Lixo e recuperação — Eliminar uma regra move-a para o lixo, não a apaga permanentemente. Pode restaurar regras a partir do lixo.
Segurança de emergência — O sistema monitoriza a saúde da execução das regras e para automaticamente regras que encontrem erros persistentes, evitando falhas em cascata.