Skip to content

DeviceBoard – AI Model Management & Anomaly Analytics Documentation

DeviceBoard – AI Model Management & Anomaly Analytics Documentation

DeviceBoard – AI Model Management & Anomaly Analytics Documentation

This document describes how DeviceBoard enables configuration, training, deployment, and inference of AI models (supervised & unsupervised), and how these capabilities integrate with RulesFlow, Rule Nodes, Time Series Database, Telemetry, and Alarms to power complete analytics dashboards.

1. Overview of AI Capabilities in DeviceBoard

Supervised Learning Models

  • Supports 25+ model types
  • Custom model import + CSV dataset upload
  • Training / validation / deployment pipeline
  • Real-time inference on telemetry
  • Outputs written into time-series storage
  • Ideal for prediction, forecasting & scoring

Unsupervised Learning Models

  • No labeled data required
  • Uses historical data to learn behavior
  • Anomaly & health scoring
  • Clustering and reconstruction techniques
  • Triggers alarms on deviations
  • Stores outputs in alarms + time-series DB

2. Supervised AI Models in DeviceBoard

2.1 Overview

Supervised models in DeviceBoard use labeled input data to learn predictive behavior. These models are typically used for:

  • Predictive maintenance
  • Energy consumption forecasting
  • Equipment performance scoring
  • Sensor value prediction
  • Classification tasks (OK/Not-OK, pass/fail)

DeviceBoard uses a modular architecture so each model:

  • Is configurable using UI-based settings
  • Can be trained using CSV datasets
  • Can run inference on telemetry key-values
  • Writes outputs back into the time series database

3. Training Supervised Models

3.1 Uploading Training Data

Users upload CSV datasets containing:

  • Feature columns → input variables
  • Target column → expected output

Supported:

  • CSV with headers
  • Multi-target outputs

3.2 Model Selection

DeviceBoard provides 25+ supervised models:

  • Random Forest
  • Gradient Boost
  • SVM / kNN
  • Neural Network (MLP)
  • Time-series regression models
  • Custom Sci-Kit models

Configurable hyperparameters included.

3.3 Training Pipeline

  1. Validate uploaded dataset
  2. Split into train/validation
  3. Train ML model
  4. Generate accuracy metrics
  5. Store in Model Registry
  6. Ready for inference

3.4 Model Deployment

Trained model can be:

  • Mapped to Device Profiles
  • Connected via RulesFlow
  • Scheduled for batch inference

4. Real-time Inference Process

4.1 Input Source – Device Telemetry

Devices continuously send telemetry key-value pairs to DeviceBoard.

Example:

  • temperature: 54
  • vibration: 0.45
  • speed: 1200

4.2 RulesFlow Integration

AI models are triggered inside RulesFlow using AI Inference Nodes.

Processing steps:

  1. Telemetry arrives
  2. Key-values passed into model
  3. Prediction returned
  4. Results written back to telemetry
  5. Optional: threshold evaluation & alarm trigger
  6. Timer nodes can schedule batch inference

4.3 Saving Predictions

Model outputs are stored in the Time Series DB:

Examples:

  • predicted_health_score: 87
  • predicted_energy_usage: 12.5
  • failure_probability: 0.04

Available instantly for:

  • Dashboards & Widgets
  • Analytics modules
  • Alarm/event triggers

5. Unsupervised AI Models – Anomaly Detection

5.1 Overview

Instead of requiring labeled data, unsupervised models:

  • Learn behavior patterns from historical telemetry
  • Detect deviations in real-time
  • Assign an anomaly score or health score
  • Trigger alarms on unexpected patterns

5.2 Data Source for Training

Unsupervised models automatically consume:

  • Time series telemetry stored in the database
  • Key-values selected during configuration

Models analyze:

  • Rolling windows
  • Multivariate correlations
  • Frequency patterns
  • Sensor relationships

5.3 Supported Unsupervised Methods

DeviceBoard includes:

  • Isolation Forest
  • DBSCAN
  • K-Means anomaly scoring
  • PCA reconstruction error
  • Autoencoder-based anomaly detection
  • Dynamic time warping analysis

5.4 Training Workflow

  1. User selects:
    • Particular Device / telemetry keys
    • Training duration (historical period)
    • Algorithm type
  2. DeviceBoard fetches historical data
  3. Model learns normal behavioral patterns
  4. Model is published into Model Registry
  5. Anomaly Rule Node can now use the model

6. Real-time Anomaly Detection

6.1 Processing Flow

During live telemetry processing:

  1. RulesFlow passes incoming key-values into the Anomaly Model
  2. Model calculates:
    • Health Score (0–100)
    • Anomaly Score
    • Anomaly Label
  3. If anomaly score exceeds threshold:
    • An alarm event is generated
    • Values are stored in the Alarm Table

6.2 Storing Anomaly Output

DeviceBoard stores:

Time Series Metrics

  • health_score
  • anomaly_score
  • anomaly_flag
  • anomaly_type

Alarm Table Entries

Each anomaly detection creates an alarm entry containing:

  • Alarm ID
  • Device ID
  • Timestamp
  • Alarm Type
  • Severity
  • Description
  • Current State (active/cleared)

7. Alarm System Integration

7.1 Alarm Rules in RulesFlow

Alarms are generated using Alarm Rule Nodes, which:

  • Monitor predicted or raw telemetry
  • Monitor anomaly detection results
  • Evaluate thresholds or conditions
  • Create/cancel alarms

7.2 Alarm Storage

All alarms are stored in the Alarm Table, supporting:

  • Active/cleared status
  • Auto-clear conditions
  • Acknowledgment
  • Escalation logic

7.3 Alarm Delivery

Alerts can be delivered through:

  • Web dashboard widgets
  • SMS/Email notifications
  • Webhooks
  • Push notifications

8. Dashboard and Widget Visualization

Supervised Model Outputs

  • Predicted values from sensor output
  • Failure probability graphs
  • Regression outputs
  • Classification results

Unsupervised Outputs

  • Health score gauges
  • Anomaly heatmaps
  • Time series anomaly markers
  • Cluster deviation plots

Alarm Widgets

Alarm widgets show:

  • Active alarms
  • Alarm timeline
  • Device-level alarm history
  • Severity-based alarm filtering

9. RulesFlow Architecture

RulesFlow defines how telemetry and AI results flow across nodes.

Common Node Types:

  • Telemetry Ingest Node
  • AI Inference Node
  • Anomaly Detection Node
  • Enrichment Node
  • Filter/Condition Node
  • Script Processing Node
  • Alarm Generation Node
  • Database Writer Node

RulesFlow enables building powerful processing pipelines for:

  • Predictive analytics
  • Real-time decision-making
  • Workflow automation
  • Intelligent alerting

10. End-to-End Example Workflow

Step 1 – Train Model

User uploads CSV → selects Random Forest → trains model → deploys.

Step 2 – Configure RulesFlow

  • Telemetry → AI Inference Node → Predicted Output
  • Predicted Output → Threshold Check → Alarm Node

Step 3 – Live Telemetry Processing

Device sends:

temp=78, current=4.2

AI predicts:

failure_probability=0.31

Threshold triggers an alarm.

Step 4 – Dashboard Visualization

Dashboard displays:

  • Predicted probability timeline
  • Alarm notification
  • Health score gauge

11. Summary

DeviceBoard extends IoT analytics with:

  • Built-in AI model training (supervised/unsupervised)
  • Telemetry-driven inference
  • Real-time anomaly detection
  • Alarm generation & visualization
  • Time series storage of predictions
  • Integration with RulesFlow automation

This makes DeviceBoard a complete AI-powered IoT analytics platform capable of predictive maintenance, anomaly monitoring, operational intelligence, and automated event handling.