Uniflow User Manual

1. Introduction and Overview

1.1 Purpose

Uniflow is an advanced visual workflow automation, protocol ingestion, and rule-evaluation platform. Built specifically for industrial IoT, physical security integration, and telemetry processing, Uniflow bridges diverse communication protocols (Modbus, OPC UA, MQTT, SNMP, BACnet, HTTP, Avigilon, Milestone, Hexagon Lidar, CAN Bus, and SIA) with a powerful, deterministic visual rule engine. The application provides seamless real-time data ingestion, transformation, decision execution, local in-memory storage, and live diagnostic monitoring.

1.2 Target Audience

• Operations Engineers & System Integrators: Users who design and configure automated data pipelines, map industrial sensors, and build complex logic graphs without writing raw code.
• System Administrators: Professionals responsible for deployment, protocol security, diagnostic logging, and machine licensing across enterprise infrastructure.
• Technicians & Maintenance Personnel: Support staff utilizing live telemetry views, real-time execution logs, and adapter helper tools to troubleshoot field devices and communication faults.

1.3 System Requirements

• Operating System: Windows 10/11 (64-bit) or Windows Server 2019/2022.
• Processor: Multi-core processor (Intel Core i5 / AMD Ryzen 5 or equivalent Xeon/EPYC architecture).
• Memory: Minimum 4 GB RAM (8 GB+ recommended for large active tag topologies and high-frequency protocol ingestion).
• Storage: 500 MB available disk space for application binaries and local persistent database files.
• Runtime Environment: .NET Desktop Runtime (x64) supporting WPF Fluent UI rendering.
• Network Interface: Dedicated NIC(s) reachable by field devices (TCP/UDP, serial COM ports for hardware adapters).

2. Getting Started

2.1 Installation and Setup

Uniflow is deployed as an integrated desktop control environment and background service suite.

• Unpacking / Execution: Run the Uniflow desktop executable. The system initializes local IPC (Inter-Process Communication) to communicate with the underlying Uniflow background processing service.
• Initial Verification: Upon launch, check the top-right corner of the interface across any page to verify active subsystem connection badges (e.g., *System Storage Connected*, *Local Catalog Sync Active*).

2.2 Quick Start Workflow

To verify operational readiness immediately after setup, follow this end-to-end onboarding and automation sequence:

• Generate License Request: Navigate to the Settings page via the sidebar navigation and select the System License Management tab. Click Copy Code to capture your generated License Request Code and submit it to your support representative for registration.

• Input System License: Upon receiving your issued license key string, paste it into the System License Key input field and click Save Settings in the toolbar.

• Verify License Status: Observe the dynamic Status Badge Card update to LICENSED SYSTEM (teal/green badge). Check the Allowed Capacity Limits Table to verify your permitted source adapters and allowed instance counts.

• Add Source: Navigate to the Sources page via the sidebar, click Add Source, select a source adapter (e.g., *Modbus TCP*), and configure its connection parameters.

• Add Points to Source: Within the source configuration panel, add specific Data Points (e.g., holding registers) to sample, then click Save and start the source.

• Add a New Rule: Navigate to the Rules page and click Add Rule to open the blank canvas.

• Fill Identification Fields: In the rule settings panel, fill in the mandatory identification fields: Name, Group, Priority, and verify Enabled is checked.

• Add Graph Nodes: From the Sources In/Out toolbox on the left, drag an Input Source node and an Output Target node onto your canvas.

• Bind Source to Input Source: Select the Input Source node, click Configure Input... in its property panel, and bind it to the Data Point created in Step 5.

• Bind Target to Output Target: Select the Output Target node, click Configure Target..., and bind its destination. Wire the output port of the Input Source across to the Value input port of the Output Target node.

• Save the Rule: Click Save in the top toolbar. Verify that the compilation badge turns green and displays "Compiled".

• Preview Execution: Click the Preview button to launch the live runtime window and monitor live data evaluating through your graph in real time.

2.3 Navigation and Interface Architecture

The Uniflow application interface is structured around a modern Fluent UI Navigation Sidebar on the left, providing rapid access to the seven core functional workspaces:

• Dashboard: A central operational monitoring and telemetry diagnostic workspace featuring integrated views: the Topology View with an executive System Health Score (0–100%) and visual mapping of active data pipelines with node/source detail drawers, the Alerts Panel for real-time notification tracking and management, the Gauges Dashboard for customizable HMI telemetry visualization, Sources Traffic Telemetry & History for live adapter bandwidth, round-trip response time (RTT), polling cadence/jitter, connection flapping counters, and persistent 90-day time-series historical analytics with CSV export, Rule Execution Telemetry & Latency Profiling for real-time execution duration profiling, SLA indicators, and hotspot analysis, Deep Infrastructure & System Health for ThreadPool, GC generational memory, and host disk capacity monitoring, and Security, Sessions & Audit Governance for active client session auditing and IP lockout ban management.

• Rules: A design surface for building, compiling, and deploying visual automation graphs that process data and trigger actions.

• Sources: A collection of configurable data adapters that connect to and ingest data from diverse systems, hardware devices, and network protocols.

• Storage: A structured repository for managing persistent data points and monitoring live system telemetry. It enables flexible storage configuration, memory point management, and real-time data inspection for both individual variables and complex objects.

• JSON Objects: A collection of user-defined JSON structures that act as flexible templates for shaping, organizing, and validating complex data payloads. These structures are used to parse raw data, maintain state for complex object types, and ensure consistent data formatting across the application.

• Logs: A comprehensive, time-ordered record of all system activities, errors, and data processing events. It supports filtering, real-time inspection, and analysis to aid in monitoring and troubleshooting.

• Settings: System-level configuration and administrative controls for managing logging verbosity, recursion protection, email alert notifications, user accounts, and machine licensing.

3. Core Features: Navigation Views In-Depth

3.1 Dashboard

The Dashboard serves as the central operational monitor. It houses an integrated sub-navigation bar allowing operators to switch seamlessly between three core monitoring workspaces: the Topology View, the Alerts Management Panel, and the Gauges Dashboard.

3.1.1 Two-Tier Topology Navigation

The visual topology engine operates across two distinct hierarchical display levels:

• Level 1: System Overview: Upon initial load, the canvas renders the macro-level architecture, displaying active Source Adapters and high-level logical Rule Groups. This provides an immediate, uncluttered view of enterprise ingestion pipelines.

• Level 2: Rule Group Deep-Dive: Double-clicking any Rule Group node zooms inside that specific subsystem, dynamically transitioning the canvas to display all individual Rule Graphs executing within that group. A dedicated ← Back to Overview button in the upper-left corner returns the viewport to the macro view.

3.1.2 Interactive Canvas & Controls

The dashboard canvas provides extensive spatial and animation customization options:

• Arranging Sources (Persistent Layouts): Engineers can freely click and drag nodes across the D3 physics simulation canvas to arrange sources and groups according to physical plant layouts or architectural preferences. Node coordinates are automatically saved and persisted across application restarts.

• Activity Toggle: An interactive toggle switch (Activity) enables or disables live visual telemetry animation pulses (glowing data bubbles) traveling along connection links whenever data frames pass between nodes.

• Animation Speed Slider: A dedicated range slider (Speed) dynamically adjusts the transit velocity of telemetry pulses (adjustable from 500ms up to 5000ms), allowing operators to balance visual feedback against system busyness.

• Fit View Button: Clicking the Fit button (⛶ Fit) instantly rescales and centers the D3 zoom transformation to frame all active nodes perfectly within the visible screen window.

• Minimap Navigation: A picture-in-picture minimap in the lower corner tracks global node positions and renders an interactive bounding box representing the current viewport, allowing rapid panning across expansive topologies.

3.1.3 Node Properties, Source Details Side Panel & Diagnostics

Selecting any node on the canvas reveals contextual diagnostics:

• Source Details Side Panel: Clicking on a Source Adapter node opens the right-side sliding panel featuring:
• Connection State & Error Reporting: Real-time status dot indicator, status description, and detailed exception message box if faulted.
• Connection Flapping & 24h Availability:
• 24h Availability Percentage: Continuous uptime calculation over a rolling 24-hour window (color-coded: Green >=99%, Amber >=95%, Red <95%).
• Reconnect Transitions Counter: Displays total disconnect/reconnect transitions within the last 1 hour and last 24 hours (e.g., 0 (1h) / 2 (24h)).
• Flap-Rate Warning Alert: Flashing alert banner triggered when reconnection transitions exceed 3 events per hour, warning operators of unstable network links or serial bus timeout cycles.
• Polling Cycle Time & Jitter: For polling protocol adapters (Modbus, OPC UA, SNMP):
• Configured Poll Rate: Target polling frequency configured in adapter settings (e.g., 100 ms).
• Measured Duration: Actual physical round-trip scan time measured across devices (e.g., 210 ms).
• Poll Jitter: Standard deviation variance in milliseconds (e.g., ±14.2 ms), exposing slow serial bus responses or network congestion.
• Endpoint Details: Displays host address, IP, port number, and operator notes.
• Connected Rules Summary: Badge count and list of all rule graphs currently bound to this source.

• Node Details Bottom Panel:
• Execution Metadata: Displays operational health badges, connection state, and live activity metrics.
• Historical Scatterplot: Renders a time-series scatterplot tracking recent telemetry values, execution latencies, or evaluation states over time.
• Graph Filtering: Granular filtering controls including Inputs / Outputs toggle buttons, Live / Pause Stream freezing, and metric series isolation.

3.1.3.1 Visual Connection Status, Health Glows & Impairment Propagation

The dashboard provides immediate visual feedback across the topology canvas to reflect physical connection states and their impact on rule pipelines:

• Source Node States & Pulse Effects:
• Connected (Normal): The source adapter is communicating normally. The node outline is neutral/slate (#455674) with no alert rings. Uptime accumulates normally.
• Connecting / Reconnecting (Orange Warning Glow): The source adapter is actively attempting to establish connection. It is offline and cannot yet transfer data. The node renders an orange pulsing glow (#ffae42, .status-warning) and emits a radiating orange ripple ring (.source-alert-ring.ring-warning).
• Disconnected / Faulted (Red Error Glow): The source adapter is disconnected, timed out, or in an unrecoverable driver fault. The node renders an emergency red pulsing glow (#ff4d4d, .status-disconnected) and emits an alert ripple ring.

• Impairment Propagation to Connected Rules & Groups:
• Critical Dependency Tracking: If any primary input, event input, or data source required by a rule is not connected, the rule cannot process incoming telemetry.
• Disconnected Source State: While a source is Disconnected or Faulted, all rules and macro groups bound to that source display a prominent Red Glow (.health-error) and show an error badge (⚠ N Rules).
• Reconnecting Source State: When the source begins reconnecting (Connecting), it changes to an orange glow. Connected rules and rule groups also transition to a visible Orange Warning Glow (.health-warning), displaying warning badges (⚠ N Rules) and contextual tooltips (e.g., Primary input 'Modbus_PLC' is Connecting).
• Recovery: Groups and rules remain marked with their respective glow until all upstream and downstream sources are fully Connected (online). Only then do the rules and groups extinguish their glow and return to the normal resting state.

• Uptime & Downtime Accounting:
• Initial Startup & Warm-Up: When the service starts or an adapter is initialized, the source enters a warming-up phase (Connecting). Downtime is never counted before a source has been online. The warm-up period maintains a clean baseline of 100% uptime with 0s connected duration and 0 reconnects.
• Outage-Based Downtime: Downtime is counted only if the source was online (Connected) before. The instant an established connection drops away from Connected (entering Disconnected, Connecting, or Faulted), downtime begins accumulating and only stops when Connected state is restored.
• Reconnection Tracking: The initial connection is never treated as a reconnect. Reconnection and flapping counters only increment when a source successfully recovers from an outage after having previously been online.

3.1.4 Operational Summary Indicator & System Health Score

A persistent status bar at the top of the dashboard displays aggregate operational metrics, including the System Health Score, service uptime, host CPU/RAM utilization, active source adapter counts, and running vs. disabled rule totals.

3.1.4.1 System Health Score (0–100%)

Positioned prominently at the front of the summary indicator, the System Health Score provides an executive, real-time index of overall operational integrity. The score dynamically updates across heartbeats, connection transitions, and rule execution events.

┌───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ [● 95% Optimal] | Uptime: 2d 4h 12m | CPU: 12% | RAM: 1.4 GB | Sources: 8/8 | Rules: 24/24       │
└───────────────────────────────────────────────────────────────────────────────────────────────────┘

3.1.4.2 Mathematical Scoring Formula & 4-Pillar Model

The System Health Score is computed by deducting penalties across four foundational operational pillars:

3.1.4.3 How to Read the System Health Score

• ≥ 95% (Emerald #10b981 — Optimal): All subsystems operating nominally. All enabled source adapters are connected, rules evaluate without drops or compilation faults, and no unacknowledged warning/critical alerts exist.
• 80% - 94% (Green #22c55e — Good): Normal operational state with minor non-blocking issues (e.g. an informational alert or an isolated reconnection event).
• 65% - 79% (Amber #f59e0b — Degraded): Operational degradation detected. Requires operator review. Typically caused by an unacknowledged warning alert, an offline non-critical source, connection flapping, or high host CPU load.
• < 65% (Red #ef4444 — Critical): Severe operational hazard requiring immediate intervention. Caused by unacknowledged critical alarms, multiple offline sources, faulted rule logic, or severe memory exhaustion.

3.1.4.4 Interactive Multi-Pillar Breakdown Tooltip

Hovering the cursor over the System Health Score widget reveals an instant multi-pillar diagnostic breakdown detailing the exact deductions applied:

System Health: 90% (Good)
• Alerts: -5% (0 crit, 1 warn)
• Sources: -5% (0/6 offline, 1 flapping)
• Rules: -0% (0 faulted, 0 drops)
• Host/Infra: -0%

Clicking the score widget allows operators to quickly identify degraded subsystems and navigate to the corresponding diagnostic tabs.

3.1.5 Real-Time Alerts Management Panel

The Alerts Panel provides an in-memory alert tracking and management system for monitoring system-wide exceptions, protocol driver faults, connection state transitions, and custom rule-generated alerts.

• Unread Alert Counter & Sidebar Badging: Real-time counter displaying active unread alerts, synchronized across the main navigation sidebar badge and upper status bar.

• Interactive Alerts Data Grid: Formatted table listing active and historical alerts, featuring:
• Severity Badges: Visual indicators categorizing entries by severity level (Critical in Red, Warning in Amber, Info in Blue).
• Timestamp & Region: Displays exact millisecond-precise creation timestamp and originating subsystem module (e.g., ModbusSvc, RuleEngine, SystemStorage).
• Message Body: Monospaced wrapping text block detailing the specific fault, exception, or recovery state.

• Batch Operations: Supports individual row selection, single-click acknowledgement, bulk Acknowledge All, and Clear All confirmation modal dialogs.

• Source Endpoint Drawer: Selecting an alert associated with a specific data source opens a right-side detail drawer displaying live connection status, host/port network properties, and connected rule graph bindings.

• Automated SMTP Dispatch Integration: Generated alerts automatically trigger outbound HTML email notifications to configured operator email lists when SMTP alert dispatching is enabled in Settings.

3.1.6 Interactive Gauges Dashboard

The Gauges Dashboard is a real-time visual telemetry canvas allowing operators to create, layout, and monitor custom HMI dashboard gauges.

• Multi-Cell Grid Architecture: Built on a high-density 2D layout grid supporting drag-and-drop card placement, collision detection, and automated grid snapping.

• Multi-Cell Width Spanning (ColSpan): Cards support customizable column spanning (ColSpan: 1..4), allowing wide multi-cell time-series charts or compact single-cell digital displays.

• Gauge Display Types:
• Radial / Circular Gauge: Classic analog dial featuring dynamic needle rotation, min/max range boundaries, and color-coded threshold arcs.
• Linear Progress Bar: Horizontal/vertical level bar for capacity, percentage, and tank level visualization.
• Digital Numeric Display: High-contrast digital readout displaying current scalar telemetry values paired with engineering unit strings (e.g. °C, bar, RPM).
• Infinite Graph Gauge: Time-series trend chart featuring auto-scaling Y-axis boundaries, userSpaceOnUse linear gradient fill for green/red threshold coloration, interactive millisecond-accurate hover tooltips, and real-time streaming data updates.

• Gauge Configuration Modal: Modal dialog for adding and editing gauge cards, defining bound data point keys, engineering unit labels, range limits, warning thresholds, and grid span settings. Grid coordinates and card settings are automatically persisted to local storage across system restarts.

3.1.7 Sources Traffic Telemetry & Network Diagnostics

The Sources Traffic Telemetry view delivers an interactive operational telemetry and bandwidth diagnostics grid across all active source adapters. Each source card is organized into five structured columns:

┌─────────────────────────┬───────────────────┬─────────────────────┬─────────────────────┬───────────────────┐
│ 1. SOURCE INFO          │ 2. APP TOTALS     │ 3. APP THROUGHPUT   │ 4. PLUGIN I/O       │ 5. PLUGIN TOTALS  │
├─────────────────────────┼───────────────────┼─────────────────────┼─────────────────────┼───────────────────┤
│ [Icon] Modbus Pump 1    │ IN:  1.42 MB      │ ▲ 12.4 KB/s         │ ▲ 8.2 KB/s          │ IN:  842.1 KB     │
│        modbusclient     │ OUT: 310.8 KB     │ ▼  2.1 KB/s         │ ▼ 4.5 KB/s          │ OUT: 198.4 KB     │
│ 99.8% (2d 4h) uptime    │ RTT: 9ms (p95:63) │ ~~~ Sparkline ~~~   │ ~~~ Sparkline ~~~   │ Poll: 104ms(±6ms) │
│ 2 reconnects (last 14m) │                   │                     │                     │                   │
└─────────────────────────┴───────────────────┴─────────────────────┴─────────────────────┴───────────────────┘

3.1.7.1 Two-Line Source Info Column

To maximize readability and prevent horizontal text overflow into adjacent summary boxes, the Source Info column utilizes a dedicated two-line telemetry layout:

• Line 1 (Top — Availability & Uptime):
• Displays rolling availability percentage over the last 24 hours and total continuous connection duration (e.g. 99.8% (2d 4h 12m) uptime).
• Color Coding:
• Green (#10b981): ≥ 99.0% availability (reliable field connection).
• Amber (#f59e0b): 95.0% - 98.9% availability (minor connection drops).
• Red (#ef4444): < 95.0% availability (unacceptable downtime).
• Line 2 (Bottom — Reconnections & Last Disconnect Tracker):
• Displays total reconnections in the last 24 hours paired with a human-readable relative timestamp indicating when the most recent disconnection occurred:
• 0 reconnects today (flawless stability).
• 2 reconnects today (last 14m ago) (active connection with past drop).
• 5 reconnects today (last 3h ago) (past instability).

3.1.7.2 Connection Flapping & Dropout Tracker

• What is Connection Flapping?: Field wiring faults, serial transceiver collisions, marginal Wi-Fi/cellular signals, or aggressive device sleep cycles frequently cause an adapter to repeatedly disconnect and reconnect in rapid cycles. Unlike a permanent failure, flapping causes intermittent telemetry blackouts and floods event logs.
• Flapping Threshold: The engine flags a source as Flapping whenever reconnection transitions exceed 3 events per hour (>3reconnects/h).
• Pulsing Square Glow Outline (No Layout Shift):
• Rather than rendering a bulky text badge that forces content onto a secondary row and stretches row heights, the reconnection row dynamically transitions to an active pulsing crimson square glow outline (.source-reconnects-row.has-flap-warning).
• An inline warning indicator (⚠️) highlights the reconnect text in crimson (#fca5a5), retaining identical line height and 0px layout shift.
• Interactive Tooltip: Hovering over the flapping outline displays complete diagnostic history:

  ⚠️ Connection Flapping: 4 reconnects in last 1h (>3/h threshold) | Total today: 4
  

3.1.7.3 Round-Trip Response Time (RTT) in App Totals

Located in Column 2 (APP TOTALS), the RTT metric measures live protocol round-trip transaction latency in milliseconds:

• Format: RTT: <avg>ms (p95: <p95>ms) (e.g., RTT: 9ms (p95: 63ms)).
• How RTT is Measured & Calculated:
• Direct I/O Stopwatch Sampling: The engine measures round-trip duration using high-resolution hardware timers (System.Diagnostics.Stopwatch) that wrap every communication dispatch to the adapter:
• Cyclic tag refresh sweeps (RefreshValuesAsync).
• On-demand point reads (ReadAsync).
• Direct control writes (WriteAsync).
• Action and command dispatches (ExecuteAsync).
• Outlier Filtering: Samples ≤ 0ms or > 60,000ms (long timeouts) are discarded to protect averages from corrupt or disconnected outliers.
• Rolling Average RTT (<avg>ms): Calculated using an Exponential Moving Average (EMA) with an 80/20 smoothing weighting:

This provides a responsive, jitter-resistant baseline that reflects sustained latency shifts without overreacting to single-packet anomalies.

• 95th Percentile Peak RTT ((p95: <p95>ms)): Computed over a continuous 5-minute rolling window:

1. All valid RTT samples recorded within the last 5 minutes are maintained in an in-memory sliding buffer (samples older than 5 minutes are automatically purged).
2. The buffered samples are sorted in ascending order.
3. The 95th percentile index is calculated as Index = \lceil N × 0.95 ⌉ - 1.

• Operational Value: Tail latency is critical in industrial automation. A device might average 9ms, but a 95th percentile of 150ms reveals intermittent bus collisions, packet retries, or device CPU contention that could stall real-time control rules.
• Hover Tooltip: Hovering over the stat displays exact unrounded values: Average: 9ms | 95th Percentile: 63ms.
• Latency Benchmarks:
• < 20ms (p95 < 50ms): Optimal local Ethernet (Modbus TCP, OPC UA) or high-speed serial bus (115,200 baud).
• 20 - 80ms (p95 < 150ms): Typical switched plant network or standard serial bus (9,600 baud).
• 80 - 250ms (p95 < 500ms): Wireless industrial Wi-Fi, cellular IoT gateways, or remote WAN tunnels.
• > 500ms: Degraded link; indicates severe packet retransmission, device processing backlog, or physical interference.

3.1.7.4 Polling Cadence, Jitter & Polling Lag in Plugin Totals

Located in Column 5 (PLUGIN TOTALS), the bottom metric tracks ingestion mode, physical cycle timing, and clock stability:

• Mode vs. Poll Field Meaning:
• Periodic Polled Sources (Poll:): Displayed for request-response protocols (Modbus Client, OPC UA Client, SNMP, BACnet) where the Uniflow adapter cyclically queries the field device. Shows measured interval and jitter: Poll: 104ms (±6ms).
• Event-Driven Push Sources (Mode: ⚡ Push): Displayed for asynchronous streaming protocols (MQTT, Webhooks, WebSocket, SIA Receiver, Avigilon Event Stream) where external devices push data to Uniflow on state change. No polling interval applies.
• How Polling Cadence and Jitter are Calculated:
• Scan-to-Scan Timestamping: Every time an adapter completes a scan and publishes a values snapshot (ValuesChanged), the engine captures the completion timestamp t_completed.
• Cycle Duration Measurement: The elapsed wall-clock time between consecutive scan completions is measured:

*(Valid range: 0 < Δ t_cycle < 60,000ms)*.

• Rolling Polling Cadence: The displayed scan cadence is smoothed using an 80/20 Exponential Moving Average (EMA):

This indicates the actual rate at which telemetry cycles are completing (e.g., 104ms for an adapter targeting 100ms).

• Instantaneous Polling Jitter ((±<jitter>ms)): Measures the absolute deviation of the latest completed cycle from the rolling cadence baseline:

High jitter (± 50ms or greater) indicates thread scheduling delays, operating system contention, or erratic device response times.

• Polling Lag Detection & Amber Glow Outline:
• Trigger Condition: Occurs when the measured polling cycle duration exceeds the configured target schedule by more than 25%:

• Visual Treatment: The stat item highlights with a pulsing amber square glow outline (.traffic-poll-item.has-poll-lag) and bold amber text (#f59e0b).
• Hover Tooltip: Shows the configured target, actual measured cadence, and the overrun lag:

    Polling Cadence: Expected 100ms vs Measured 215ms | ⚠️ Polling Lag: +115ms behind schedule
    

• Operational Remediation: If an adapter configured for 100ms takes 215ms to complete each scan, the device hardware or serial bus cannot keep up with the query rate. Technicians should increase the configured poll interval in Source Settings (e.g., to 250ms) or reduce the number of registers requested per scan packet.

3.1.7.5 Throughput Graphs & Drag-and-Drop Reordering

• Application vs. Plugin Sparklines: Column 3 tracks sanitized application-level data ingested into the rule engine, while Column 4 tracks raw socket/serial I/O exchanged over the wire (including protocol headers and cyclic heartbeats).
• 30-Second Service-Side Rate Buffers: The service engine maintains rolling historical rate buffers (30 1-second samples) for application and plugin inbound/outbound throughput. Telemetry polling runs continuously in the background starting from GUI launch/login. When navigating to the Sources Traffic Telemetry view, sparklines render pre-populated with historical throughput immediately, eliminating empty graph starts or initial lag.
• Persistent Display Order: Operators can drag source cards by the grip handle (⠿) to prioritize critical pipelines at the top of the grid; custom ordering is automatically persisted.

3.1.7.6 Reset Telemetry Metrics & Confirmation Dialog

The Sources Traffic Telemetry view includes a Reset Metrics button located in the top-left view controls panel:

• Purpose: Allows engineers and system administrators to clear historical counters after replacing hardware, resolving wiring faults, or reconfiguring polling schedules, starting metrics tracking from a clean slate.
• Confirmation Safety Dialog:
• Clicking Reset Metrics opens a safety confirmation modal dialog displaying the warning:

• Cancel: Closes the dialog with zero state change.
• Yes, Reset All: Dispatches the ResetSourceTraffic IPC command to the service engine.
• Metrics Reset Scope:
• Bandwidth & Rates: Resets application and plugin cumulative bytes (Rx/Tx) and zeroes out real-time sliding rate buckets.
• Uptime & Availability: Resets the tracking baseline to the moment of reset. Sources currently Connected start fresh at 100.0% availability with 0 downtime. Sources currently Disconnected or Connecting begin tracking downtime from the reset timestamp.
• Reconnection & Flapping: Clears 1-hour and 24-hour reconnection transition counters, extinguishing any active connection flapping warnings.
• RTT & Jitter: Clears historical round-trip latency samples, rolling averages, peak p95 metrics, and measured polling jitter history.

3.1.7.7 Sources Telemetry History & Time-Series Analytics

The Sources Telemetry History view extends live operational monitoring with long-term, persistent time-series analytics, historical bandwidth audits, and trend diagnostics across all configured source adapters. Operators can transition seamlessly between live real-time metrics and historical archives using the History toggle button located in the top-left view controls panel.

• Two-Way View Navigation:
• Switching to History: Clicking the History button (📊 History) dynamically transitions the live grid into the historical analytics subview, preserving active pane geometry across fullscreen, vertical, and horizontal split-screen dashboard layouts.
• Back to Live: A dedicated Back to Live button (← Back to Live) restores the real-time operational telemetry grid without reinitializing dashboard state or incurring page reloads.

• Dynamic Baseline & Filter Subtitle:
• Positioned directly below the view header, the interactive subtitle tracks the exact UTC baseline when historical telemetry collection started or was last cleared:

    Baseline: Since 12/09/2026 14:30 • Aggregation: Date: 2026-09-13
    

• Dynamically updates to reflect the active aggregation filter mode, selected calendar date, or custom date range.

• Historical Aggregation Modes:
• Lifetime Mode: Aggregates all recorded data points across the active 90-day retention window into daily summary checkpoints. Provides a macro-level overview of sustained data throughput and protocol traffic volume over weeks and months.
• Date Mode (24-Hour Single-Day Deep Dive):
• Selects an individual calendar day using the inline dark-themed date picker (defaults to Today).
• Segments daily traffic into 24 discrete hourly checkpoints (00:00 to 23:00 UTC).
• Allows technicians to pinpoint peak communication spikes, overnight polling patterns, or abnormal transfer surges during specific operational shifts.
• Date Range Mode (Multi-Day Custom Interval):
• Enables custom interval analysis defined by Start Date and End Date selectors.
• Computes daily aggregated traffic volumes across the selected window, ideal for monthly audits, billing reconciliation, and network capacity planning.

• Dual-Graph Time-Series Visualization:

Each historical source row renders an expansive, interactive dual-trend SVG visualization:

• Application Throughput Graph (Cyan / Purple): Visualizes clean application-level data ingested into the rule engine (App In vs App Out).
• Plugin Wire I/O Graph (Emerald / Amber): Displays raw network socket/serial data transferred over the physical medium (Plugin In vs Plugin Out), highlighting protocol framing overhead, cyclic keep-alives, and driver handshakes.
• Adaptive Auto-Scaling & Single-Point Ramp Extension:
• Dynamically scales the Y-axis from 0 to the peak transfer volume within the active window.
• Intelligently scales isolated single-point checkpoints into visible slope ramps, ensuring single-hour delta bursts remain clearly discernible rather than rendering as invisible single-pixel dots.
• Time-Axis Tick Formatting: Automatically formats the horizontal X-axis with intuitive interval indicators (00:00, 06:00, 12:00, 18:00 in Date mode; MM/dd in Lifetime and Date Range modes).

• Interactive Precision Guide & Floating Hover Tooltip:
• Synchronized Guideline: Hovering over any graph draws a crisp vertical tracking cursor that snaps to the nearest time checkpoint across both Application and Plugin curves.
• Elevated Hover Tooltip:
• Renders a floating, high-contrast cyber-dark tooltip anchored strictly above the cursor (z-index: 99999, overflow: visible), ensuring tooltips never clip against adjacent source rows or container borders.
• Displays:
• Checkpoint Time / Date: Specific hourly bucket (e.g. Hour 14:00 (14:00 - 14:59 UTC)) or daily calendar date.
• App In / Out: Exact bytes transferred and human-readable engineering format (e.g. 14.2 MB (14,889,984 bytes)).
• Plugin In / Out: Raw wire transfer volume.
• Total Interval Volume: Combined sum transferred during that specific bucket.

• Display Synchronization & Sorting Parity:
• Order Parity with Live Grid: The historical grid strictly inherits the display sequence established in the live Sources Telemetry grid. Any custom drag-and-drop ordering saved via the card grip handles (⠿) is preserved when switching into the History subview.
• Instant Warm Pre-Population: Upon opening, the history view immediately populates card templates using active source metadata, eliminating visual flicker or empty layout shifts while background historical aggregation completes.

• RFC 4180 CSV Data Export:
• An Export CSV button (📥 Export CSV) in the historical control panel enables one-click exporting of the currently filtered dataset.
• Generates an RFC 4180 compliant CSV file structured with standardized reporting columns:

    Source Name,Source ID,Source Type,Period,Timestamp (UTC),App In (Bytes),App Out (Bytes),Plugin In (Bytes),Plugin Out (Bytes),App In (Formatted),App Out (Formatted),Plugin In (Formatted),Plugin Out (Formatted)
    Modbus Inverter,b5e82...c1,modbusclient,Hour 10:00,2026-09-13T10:00:00Z,5242880,1048576,6291456,1258291,5.00 MB,1.00 MB,6.00 MB,1.20 MB
    

• Launches the native Windows File Save dialog (SaveFileDialog), allowing operators to select destination paths and filenames, with an automatic web Blob download fallback.

• Automatic Lifecycle Cleanup & Dead Entry Purging:
• Orphan Prevention: When an operator deletes a source instance from Uniflow (via the Sources management UI or IPC commands), the service engine automatically purges all associated telemetry history—both cumulative lifetime totals and all historical hourly checkpoint archives across all calendar days—from disk (source_traffic.json) and memory.
• Strict Active Scope: Historical aggregation queries strictly enforce known active source boundaries, ensuring deleted or obsolete source instances never linger as "dead entries" in historical reports or CSV exports.

• Crash-Resilient I/O & Internal Alarm Escalation:
• Fault-Tolerant Persistence: All historical checkpoints and cumulative metrics are persisted to source_traffic.json using atomic temporary file staging (.tmp write followed by atomic replace) with recursive failure suppression.
• In-Memory Fallback: If file I/O fails due to disk space exhaustion, external process file locking (e.g. antivirus scans), or bad sectors, the Uniflow service gracefully continues operating in-memory without service disruption or crashes.
• Automatic Alarm Dispatch: Any disk write or read failure immediately registers a Critical severity alarm in the internal Alarms Service (AlertStore), alerting operators via the Alerts Dashboard and triggering outbound email notifications.

3.1.8 Rule Execution Telemetry & Latency Profiling

The Rule Execution Telemetry & Latency Profiling view delivers real-time execution duration profiling, SLA indicators, and hotspot bottleneck analysis across active rules with continuous 1-second refresh:

• Active Rules Isolation: Automatically hides disabled rules, focusing operational attention exclusively on executing workflows.
• Interactive Filtering: Filter displayed rules by name or organizational group with live count badging (Showing X of Y).
• Execution Counters: Cumulative evaluation count since service start.
• Execution Latency Profiling (Last / Avg / 95% Peak / Max): Measures end-to-end rule evaluation duration from trigger ingestion to action sink dispatch:
• Last: Duration of the most recent evaluation cycle.
• Rolling Average: Exponential moving average execution time.
• 95% Peak: Tail latency threshold covering 95% of executions.
• Max: Absolute peak execution duration recorded since service startup.
• SLA Threshold Color Indicators:
• < 20ms (Green — Optimal): Deterministic, high-speed execution suitable for industrial control loops.
• 20 - 100ms (Amber — Warning): Acceptable latency; potential network or database write delays detected.
• > 100ms (Red — Degraded / SLA Violation): Severe latency; indicates blocking action sinks, unoptimized scripts, or synchronous network calls.
• Dropped Triggers (Backpressure Skips): Dedicated counters tracking skipped trigger events in the last 1 hour and 24 hours when rule concurrency limits are saturated.
• Hotspot Analysis ("Top 5 Resource Consumers"): Automatically ranks and pins the top 5 most resource-intensive rules at the top of the workspace.
• Inspect Modal Drawer:
• Action Sink Latency Breakdown: Visual execution meters dissecting condition evaluation time versus individual action sink execution durations, complete with target source name badges (📤 ActionName (TargetSource)).
• Failure Context Inspector: Monospaced JSON snapshot inspector capturing exact trigger input values and bound graph variables at the moment of the last runtime failure.

3.1.9 Deep Infrastructure & System Health

The Deep Infrastructure & System Health view provides comprehensive operational visibility into the underlying .NET CLR runtime and host machine resources:

• ThreadPool & Asynchronous Task Concurrency:
• Worker Threads: Active worker threads executing tasks versus maximum allocated thread pool capacity.
• I/O Completion Ports: Asynchronous I/O completion port thread utilization handling network sockets and disk reads.
• Pending Work Queue Depth: Number of queued asynchronous tasks awaiting worker thread availability. An increasing backlog indicates thread pool starvation.
• Active Process Thread Count: Total operating system threads spawned by the background service.
• Garbage Collection (GC) & Generational Memory Breakdown:
• Process Working Set & Private Bytes: Total physical RAM occupied and committed virtual memory allocated.
• Managed Heap Size: Total memory dynamically allocated within the .NET garbage-collected runtime.
• Generational Allocation Breakdown:
• Generation 0 (Gen 0): Ephemeral, short-lived objects (e.g. temporary strings, small JSON tokens, function arguments). Collected frequently with minimal overhead.
• Generation 1 (Gen 1): Buffer generation acting as a buffer between short-lived and long-lived memory.
• Generation 2 (Gen 2): Long-lived objects (e.g. in-memory databases, active protocol adapters, cached rule graphs). Gen 2 collections require full heap sweeps; frequent Gen 2 collections signal memory pressure.
• Large Object Heap (LOH): Dedicated heap holding objects larger than 85,000 bytes (e.g. large byte buffers, image streams, large data export arrays). LOH is not automatically compacted, making fragmentation tracking essential.
• Storage & Disk Capacity:
• Host Drive Capacity: Free disk space versus total capacity on the service host drive with visual health meter.
• Low Disk Space Alert: Flashing critical alert triggered if available drive space drops below 10%.
• Log Directory Usage: Total disk space consumed by rotating application log files.
• Database Storage: SQLite database file footprint on disk.

3.1.10 Security, Sessions & Audit Governance

The Security, Sessions & Audit Governance view enforces administrative access control and runtime connection auditing:

• Active Client Sessions Table:
• Real-time auditing of connected client sessions across Named Pipe and SignalR HTTPS transports.
• Displays Session ID, Client Protocol Type, Client IP Address, Connection Duration, Active Subscription Count (rules and gauges), and Last Active timestamp.
• Blocked IP Ban List Table:
• Displays client IP addresses locked out by the anti-brute force authentication security shield.
• Shows failed attempt count, lockout reason, lockout timestamp, and live countdown timer until ban expiry.
• Manual "Unblock" Action: Provides immediate operator override to unblock an IP address and restore access without waiting for timer expiration or restarting services.

3.1.11 Dashboard Telemetry Diagnostics & Interpretation Cheatsheet

The following reference table provides operators and maintenance technicians with a quick guide to reading dashboard telemetry indicators, identifying root causes, and executing recommended operational remediation:

3.2 Rules

The Rules view is a comprehensive management interface for visual logic sets. It provides advanced sorting, filtering, and execution trace inspection.

3.2.1 Toolbar Actions

• Add Rule (+): Opens the dedicated Rule Editor workspace to design a new workflow from scratch.

• Refresh: Synchronizes the active list of rules with the background processing engine.

• Filtering: Live search textbox for filtering rules by name, paired with dropdown filters to isolate rules belonging to specific Groups or bound to specific Input Sources.

3.2.2 Data Grid Columns

• Status (Indicator Ellipse): A color-coded status circle reflecting the rule's active state. Action: Double-clicking this indicator immediately toggles the rule between *Enabled* (Active) and *Disabled* (Paused).

• Preview Button: Launches a live execution trace overlay. This allows engineers to view real-time data transitions and node evaluations occurring within that rule without opening the full editor.

• Edit Button: Opens the selected rule inside the visual Rule Editor.

• Delete Button: Permanently removes the rule set.

• Rule Name: The defined unique identifier of the rule.

• Group: Logical grouping category used for organizational tagging.

• Source: The primary input adapter or event trigger bound to this rule.
• Priority: Execution priority level determining evaluation order during simultaneous event storms.

3.3 Sources

The Sources view manages all data ingest adapters communicating with external hardware, field devices, and network endpoints.

3.3.1 Toolbar Actions

• Add Source (+): Invokes a creation dialog prompting the selection of a specific source adapter type.

• Refresh: Reloads adapter status and configurations.

• Search: Filters configured sources by matching names, IP addresses, or URLs.

• Count Indicator: Displays total configured vs. active source metrics.

3.3.2 Data Grid Columns

• Status Avatar: A protocol-specific icon encased in a dynamic, glowing rounded outline representing operational health (Green glow = Active/Healthy, Red glow = Fault/Error, Grey = Stopped).

• Edit Button: Modifies the protocol configuration settings (IPs, polling rates, registers, topics).

• Delete Button: Removes the adapter configuration.

• Start / Stop Controls: Dedicated runtime control buttons (► Start / ■ Stop) allowing individual adapters to be brought online or offline independently. Includes an indeterminate progress ring during connection handshakes.

• Source Name / URL: The user-defined friendly name and underlying network endpoint URI.

• Type: The source adapter classification (e.g., *ModbusTcp*, *OpcUa*, *SnmpWalker*).

• Runtime Status: Live operational state (e.g., *Connected*, *Listening*, *Disconnected*) paired with a sub-label displaying exact error messages if a connection fault occurs.

• Helper Button: Available on applicable VMS adapters (Avigilon and Milestone) to launch a specialized exploration utility that queries and browses entity collections (such as Alarms, Cameras, Servers, and Sites) fetched directly via API.

3.4 Storage

The Storage view exposes Uniflow's internal memory space, local persistence engine, and live telemetry cache. It is divided into two primary pivot tabs.

3.4.1 Filtering Card

A unified search card allowing rapid filtering across both tabs by matching Name / Point ID or filtering by specific Value Types (e.g., *Boolean*, *Integer*, *Double*, *String*).

3.4.2 Tab 1: Storage Points

Manages the structural definitions of internal memory registers.

• Actions: Edit ([E]) or Delete ([D]) storage definitions.

• Name: The friendly name and unique point access key.

• Value Type: The expected data structure.

• Default Value: The initial starting state or baseline value assigned upon system initialization.

• Access: Security access level (*Read/Write*, *ReadOnly*).

• Max Size: Clamped capacity for string or byte array buffers.

• Persistent Flag: A visual badge (*Yes* in Green / *No* in Red). When set to *Yes*, point values are automatically persisted across system reboots and power losses.

3.4.3 Adding an Internal Storage "Data Point"

To allocate a new memory variable for rule graphs or external protocol access, navigate to Tab 1: Storage Points and click the Add Storage Point (+) button in the upper toolbar. Fill out the following configuration dialog:

• Name / Point ID (String): A unique identifier key used to address this memory variable within Rule Graphs or REST API queries (e.g., Facility_Target_Setpoint).

• Value Type (Dropdown): Expected structural format (Boolean, Integer, Double, String).

• Default Value (Dynamic): The initial starting state assigned to the memory variable upon creation or system boot (e.g., False, 0, 21.5, "Idle").

• Access Level (Dropdown): Restricts access permissions (ReadWrite allows dynamic updating by rules/clients; ReadOnly locks the point as a constant or external read-only tag).

• Max Size (Integer): Applicable for string data types, setting the maximum allowed character buffer allocation.

• Persistent (Checkbox): When checked, the point's latest runtime value is continuously written to local disk storage, ensuring state recovery following server reboots or power outages.

3.4.4 Tab 2: Live Data

Provides real-time inspection of active values passing through or resting within internal storage.

• Point ID & Name: Identifies the specific memory address.

• Value Type: Data classification.

• Value: Renders the current live value in a highly readable, monospaced Consolas font.

• Timestamp: Exact UTC timestamp of the last recorded value mutation.

• Actions (Output Target): A dedicated edit button allowing technicians to manually override and write a specific value directly into the storage point for simulation or forced override.

3.5 JSON Objects

The JSON Objects view manages custom metadata schemas used to parse, flatten, and extract deeply nested JSON payloads originating from HTTP endpoints, MQTT topics, or Webhook receivers.

3.5.1 Toolbar & Filtering

• Add Schema (+): Opens the schema designer to map JSON property keys to strongly typed collection fields.

• Search & Category Filters: Quickly isolates object schemas by matching text or categorical groupings.

3.5.2 Data Grid Columns

• Actions: Edit or Delete object definitions.

• Friendly Name: The identifier referenced inside Rule Graph nodes (e.g., json_to_collection).

• Category: Organizational grouping.

• Description / Notes: Contextual documentation regarding the expected payload structure.

• Date Added: Creation timestamp.

3.5.3 Adding a JSON Object Schema

To define a new custom payload template, click Add Schema (+) in the upper toolbar and configure the following parameters:

• Friendly Name (String): The unique schema identifier referenced inside Rule Graph nodes (e.g., Milestone_Event_Record).

• Category (String): An organizational grouping tag used for filtering and sorting (e.g., Security, Sensors, HVAC).

• Description / Notes (String): Contextual documentation explaining the payload source or intended use case.

• Schema Properties Table: The core mapping structure where engineers define individual payload variables. Click Add Property (+) to configure each field:

• Property Key / Path (String): The exact JSON key name or path to extract from incoming text (e.g., alarmState, event.id, device.temperature).

• Data Type (Dropdown): Expected structural conversion format (String, Integer, Double, Boolean, Vector).

3.6 Logs

The Logs view provides a high-fidelity, real-time diagnostic stream of system events, protocol driver communications, and rule execution traces.

3.6.1 Toolbar Actions

• Auto Scroll Checkbox: Toggles automatic tailing of incoming log entries.
• Export ([Icon]): Dumps active in-memory log history to an external disk file for auditing.
• Clear ([Icon]): Flushes the active view buffer.

3.6.2 Granular Filter Bar

Four dedicated input fields allow precise log isolation:

• Time Filter: Matches specific hour/minute/second patterns.
• Level Filter: Dropdown filtering by severity (*Info*, *Warning*, *Error*, *Debug*).
• Region Filter: Filters by subsystem or protocol driver module (e.g., *OpcUaSvc*, *RuleEngine*).
• Message Filter: Full-text search across log contents.

3.6.3 Log Data Grid

Displays exact timestamps, color-coded severity levels, operational regions, and multi-line wrapping message blocks formatted in monospaced typography. Action: Double-clicking any log row opens a detailed modal window displaying complete stack traces and execution metadata.

3.7 Settings

The Settings view configures core runtime parameters, email alert notifications, user management accounts, and system licensing across dedicated settings tabs.

3.7.1 Toolbar Actions

• Save Settings ([Icon]): Commits changes to system configurations, persists settings to config.json, and triggers dynamic backend service reloading.

3.7.2 Tab 1: General & Logging

• Diagnostic Logging Verbosity: Dropdown selector adjusting the detail level written to system log buffers (*Error Only*, *Normal*, *Detailed*, *Debug Trace*).

• Plugin Repository URL: URL or local filesystem path pointing to the plugin repository catalog repository.json.

• Inactivity Logout (min): Automatic session security expiration timeout in minutes (0 to disable auto-logout).

3.7.3 Tab 2: Email Notifications

The Email Notifications tab manages outbound SMTP communication settings for automated alert dispatching. When system alerts (such as source connection faults, hardware offline states, or recovery events) are created by UniflowWorker, the service layer formats and transmits HTML email notifications to designated recipients.

• Enable email notifications (Checkbox): Global master switch enabling automated email notification dispatching when alerts are raised by the background service.

• SMTP Server Configuration:
• SMTP Host & Port: Specify the outbound MailKit SMTP server address (e.g. smtp.example.com or 192.168.1.100) and network port (defaults to 587).
• Encryption Security (Dropdown): Select the required transport layer security mode:
• None: Unencrypted SMTP transport (typically port 25 or 587).
• SslTls: Implicit SSL/TLS encryption upon initial socket connect (typically port 465).
• StartTls: Explicit STARTTLS connection upgrade (typically port 587).
• SMTP Username & Password: Authentication credentials required by the target SMTP relay server.
• Skip SSL/TLS Certificate Validation (Checkbox): When enabled, bypasses strict SSL/TLS X.509 certificate chain validation to support self-signed certificates or internal Enterprise CAs.

• Recipient & Sender Addresses:
• From Email Address: Sender email address populated in the From header of outbound emails (e.g. alerts@uniflow.local).
• Sender Display Name: Friendly display name associated with outbound alert messages (defaults to Uniflow Alerts).
• Recipients (TextArea): Comma-separated list of recipient email addresses receiving alert notifications (e.g. operator@company.com, admin@company.com).

• Test Email Configuration (Send Test Email Button):
• Automatically saves current settings to the service backend and triggers an immediate test email dispatch via the TestAlertEmail IPC command.
• Displays success confirmation or detailed SMTP negotiation failure messages directly within a GUI dialog.

3.7.4 Tab 3: User Management

Allows administrators to create and manage application user accounts, assign security roles (*Admin*, *Operator*), and reset access credentials.

• Anti-Brute-Force Lockout Protection: To safeguard endpoints against unauthorized credential guessing and automated dictionary attacks, the background service enforces an IP-bound lockout mechanism (BlockedIpManager). Each client IP address is allowed up to 3 failed login attempts. Upon failing the 3rd consecutive attempt, the client IP address is temporarily blocked for 5 minutes. Lockouts and attempt tracking are strictly bound to the originating client IP address (independent of which username or account is attempted), and a successful login from that IP resets its failed attempt counter.

3.7.5 Tab 4: Plugins (Plugin Manager)

The Plugins tab provides a centralized marketplace and local lifecycle manager for extending Uniflow with industrial protocol drivers, enterprise cloud connectors, visual controls, and AI inference engines. Available exclusively to administrators, the Plugin Manager coordinates with UniflowService and the remote repository catalog (repository.json).

• Search & Dynamic Filters:
• Search Plugins (TextBox): Filter plugins by name, ID, or description keywords in real time.
• Status Filter (Dropdown): Filter the catalog by installation state:
• All: Displays all registered official and custom plugins.
• Installed: Filters for plugins currently loaded and active in the local service runtime.
• Not Installed: Highlights plugins available in the remote repository ready for download.
• Update Available: Isolates installed plugins that have a newer version available in the repository.
• Category Filter (Dropdown): Filter plugins by industrial domain (e.g. *Industrial Automation*, *Physical Security & CCTV*, *Networking & IT*, *Cloud & AI*, *Building Automation*).

• Catalog Synchronization & Upload:
• Refresh Catalog (Button): Queries the configured Plugin Repository URL (with local disk icon fallback and fast network timeouts) to fetch the latest plugin manifests and version metadata.
• Upload Plugin Package (Button): Allows administrators to install offline custom or private plugins directly by selecting a .zip plugin package containing plugin.json and compiled assemblies. Uniflow automatically verifies the package structure, validates minimum system version compatibility, and registers the plugin without requiring application re-installation.

• Plugin Card Anatomy & Lifecycle Actions:
• Plugin Identity: Displays high-resolution plugin icon, friendly display name, author / vendor badge, current installed version, latest available repository version, and package license tier (*Free* vs. *PRO*).
• Install (Primary Button): Initiates asynchronous background downloading from the repository server with an animated progress bar and byte counter, followed by automated verification and collectible AssemblyLoadContext (ALC) dynamic loading.
• Update (Warning Button): Displays when a newer semantic version is available in the repository. Clicking prompts an update confirmation dialog highlighting new release notes, seamlessly downloading the update and reloading the plugin sandbox.
• Uninstall (Danger Button): Gracefully stops active source adapters bound to the plugin and triggers garbage collection of the collectible ALC sandbox from both the backend service and client session cache.
• Release Notes (Action Link): Opens the Plugin Release Notes Dialog detailing version changelogs, bug fixes, and feature additions across historical versions.
• Legal & License Terms (Action Link): Opens the Plugin Legal Information Dialog displaying vendor copyright notices, third-party library attributions, and license agreements.

• Compatibility & Licensing Guardrails:
• Version Compatibility: Each plugin specifies MinSystemVersion. If the running UniflowService version does not satisfy the plugin's minimum version requirement, the Install button is disabled with an explanatory tooltip.
• License Tier Restrictions: When operating under a Free license tier, installation of PRO-tier commercial plugins is protected and requires an upgraded license key in Tab 5.

3.7.6 Tab 5: System License Management

• License Request Code: A read-only text box generating a unique hardware identifier for the hosting machine. Includes a Copy Code button to send to support for license issuance.

• System License Key: Input area to paste active license cryptographic strings.

• Status Badge Card: Dynamic shield display reflecting active validation state:

• LICENSED SYSTEM (Teal/Green border & badge).

• UNLICENSED SYSTEM (Red border & badge).

• LICENSE EXPIRED (Red border & badge).

• Allowed Capacity Limits Table: Displays an exact table of permitted source connections based on the active license (e.g., *ModbusTcp: 10 allowed*, *OpcUa: 5 allowed*).

4. Rule Editor & Graph Nodes

4.1 Philosophy of Uniflow Rules

Visual rules act as the intelligent "nervous system" of Uniflow. Rather than relying on continuous, CPU-heavy polling loops, rules are strictly event-driven. When a source adapter ingests a telemetry frame or an internal storage point changes value, the rule engine instantly awakens, evaluates the connected logic graph from left to right, executes decision branches, and dispatches outbound control commands.

4.1.1 Core Execution Mechanics & Concurrency

Understanding how the rule engine processes logic is essential for designing robust automation:

• Event Awakening & Concurrency: Rules execute asynchronously across multi-threaded thread-pool workers. When multiple independent source adapters or storage points emit telemetry simultaneously, their bound rules are dispatched and evaluated in parallel, ensuring high-throughput ingestion without single-threaded bottlenecks.

• Deterministic Order of Execution: Within an awakened rule graph, node evaluation strictly follows a topological ordering (from upstream data ingest to downstream sinks). A functional logic node (e.g., Addition or Greater Than) will not evaluate until all upstream wire connections delivering its input parameters are fully resolved.

• Branching & Sinks: Conditional flow control blocks (such as Branch (If / Else)) evaluate boolean expressions to dynamically route execution down isolated graph pathways. The evaluation cycle completes when all active branches terminate at outbound action sinks (e.g., Output Target).

• Target Contention & Priority: When multiple concurrent rules attempt to write to the identical internal storage point or external protocol register, write operations are processed thread-safely. During simultaneous event storms, the execution scheduler prioritizes evaluations based on each rule's configured Priority Level (higher priority rules evaluate first). However, engineers should design rules defensively to avoid uncoordinated competing writes that cause unpredictable value overwriting.

• Feedback Loops & Recursion Breaker: If a rule graph binds to a specific storage point as its input source and subsequently executes an Output Target action targeting that exact same storage point, committing the write instantly re-triggers the rule, initiating a circular feedback loop. To protect host CPU resources from infinite recursion lockups, Uniflow enforces a rigorous, hardcoded safety limit of 10 triggers. If a self-triggering loop or chained circular sequence exceeds this immutable maximum depth, the engine immediately aborts execution and logs a recursion safety fault.

4.1.2 Rule Re-Entrancy, Concurrency Gates, and Execution Overlap

When designing high-frequency automation rules, it is vital to understand how the engine handles overlapping executions of the same rule:

• Isolated Per-Rule Execution Gates (SemaphoreSlim(1, 1)):

Every rule compiled in Uniflow possesses its own dedicated, isolated concurrency gate. Rule executions are strictly isolated per rule definition: Rule A running never blocks or delays Rule B. However, for any single rule, executions do not run concurrently with themselves. An evaluation cycle holds its rule's gate until all intermediate logic finishes and all outbound action sinks complete.

• Sequential Evaluation of Outbound Actions:

If a rule defines multiple action sinks (e.g., Action 1: *Save Snapshot to Folder* via ONVIF, followed by Action 2: *Insert Database Record* via Postgres), the rule engine executes and awaits these actions sequentially in topological order. Action 2 will not begin until Action 1 has fully completed (or timed out). If Action 1 involves a high-latency physical operation (such as camera network acquisition and file writing), the rule's gate remains held for that entire duration.

• What Happens When the Same Rule is Triggered Again:

If an incoming trigger arrives while a previous execution of that same rule is still running, the engine's behavior is determined by the input node kind:

• Telemetry / Value Streams (InputSource) → Backpressure Drop:

Continuous telemetry feeds (e.g., MQTT topic subscriptions, Modbus cyclic polling, OPC UA value updates) operate on "latest value" semantics. If the rule is currently busy executing, queuing incoming values would cause creeping latency delays and unbounded memory buildup. Instead, the engine performs a zero-wait try-lock (gate.WaitAsync(0)). If the gate is busy, the incoming trigger is immediately dropped and a backpressure skip activity is registered.

• Discrete Event Streams (EventInput) → Queued Execution:

Push-based event streams (e.g., VMS security alarms, badge access events, discrete sensor triggers) represent unique historical occurrences where every single event is critical. For rules triggered by an EventInput, incoming events queue up at the gate (await gate.WaitAsync(ct)). Each queued event waits its turn and evaluates in order, ensuring zero discrete events are lost.

4.2 Creating and Debugging Rules

Clicking Add Rule instantly redirects the engineer to a fresh visual canvas editor. No preliminary dialog is presented. Instead, a new rule is automatically initialized with sensible defaults:

• Rule Name: Defaults to New Rule.
• Group: Defaults to General.
• Priority Level: Defaults to 50.
• Enabled State: Enabled (true) by default.

4.2.1 Configuring Rule Identity and Metadata

At any point during rule design, the engineer can configure these identity fields directly in the top header panel of the Rule Editor:

• Rule Name (TextBox): A clear, unique identifier describing the rule's exact purpose (e.g., BoilerOverheatProtection, BadgeAccessGranted).
• Group (ComboBox): An organizational categorization tag allowing engineers to sort and filter large enterprise catalogs by department or subsystem (e.g., HVAC, Security, Telemetry). The field is editable, allowing you to select an existing group or type a new one.
• Priority Level (ComboBox, options from 10 to 100): Determines execution precedence during simultaneous event storms. Rules assigned higher priority numbers are evaluated first by the execution scheduler.
• Enabled State (CheckBox): Toggles whether the rule should begin active evaluation immediately upon saving, or remain paused in a disabled draft state.

4.2.2 Rule Editor Toolbar & Canvas Action Controls

The Rule Editor provides a comprehensive suite of visual controls and shortcuts organized across the top action toolbar, the header metadata bar, and the floating canvas overlay panel:

a) Top Action Toolbar

Positioned at the very top of the editor, this toolbar manages graph file lifecycle operations and full state history:

• Reset (ArrowReset icon): Clears the active canvas and restores the rule graph to its clean default state. If unsaved edits are present on the canvas, a confirmation dialog appears before resetting.
• Import (ArrowImport icon): Opens a file dialog to load and parse an external .json rule definition file into the active workspace, prompting confirmation if unsaved changes exist.
• Export (ArrowExport icon): Serializes the current rule graph structure, node positions, port bindings, and wire connections into a portable .json file for backup, version control, or migration across systems.
• Delimiter Separator: A clean vertical divider line visually isolating file lifecycle actions from the history stack controls.
• Undo (ArrowUndo icon | Ctrl+Z): Reverts the most recent action on the rule graph. Provides complete text editor parity across all graph mutations:
• Adding or deleting nodes
• Adding, replacing, or disconnecting wire connections
• Moving or dragging nodes across the canvas
• Modifying node properties or data bindings in the Inspector (with intelligent 400 ms typing debouncing)
• Switching connection wire routing styles (Curved vs. Right-Angled)
• Canvas reset and external graph import operations
• Dynamic Tooltips: Reflect the exact action being reverted (e.g., *Undo Add Node: InputSource (Ctrl+Z)* or *Can't Undo* when the history stack is empty).
• Context-Aware Keyboard Handling: When typing inside an inspector text box, native WPF intra-text undo/redo takes precedence; canvas-level graph undo takes effect as soon as focus leaves the text field or is anywhere on the canvas.
• Capacity: Maintains a bounded memory stack of up to 100 historical snapshot states.
• Redo (ArrowRedo icon | Ctrl+Y / Ctrl+Shift+Z): Re-applies the most recently undone action. Features dynamic tooltips describing the action to be reapplied (e.g., *Redo Move Node: Addition (Ctrl+Y)* or *Can't Redo* when no further forward actions exist).

b) Rule Header Navigation & Save Bar

Positioned directly beneath the action toolbar:

• Back Arrow (Rules button | ArrowLeft icon): Safely exits the Rule Editor and returns to the main Rules table. Prompts the operator before discarding unsaved canvas edits.
• Save Rule (Accent Blue Button | Segoe MDL2 \uE74E): Validates the visual graph, compiles the node logic pipeline, and transmits the compiled rule to UniflowService via IPC. Automatically disabled while an asynchronous save operation is in progress.
• Rule Name (TextBox): Direct inline text editor for naming the rule.
• Enabled (CheckBox): Master execution switch toggling active runtime evaluation.
• Group (ComboBox): Assigns the rule to an existing organizational group or allows typing a new category name.
• Priority (ComboBox): Assigns scheduling precedence (10 to 100).
• Compile Status Badge: Live visual indicator (Green dot = *Compiled*, Red dot = *Errors*, Amber dot = *Warnings*) with hover tooltips detailing any graph compilation or schema validation issues.

c) Floating Canvas Overlay Controls

Hovering at the top-left of the canvas surface provides immediate viewport framing and wire rendering controls:

• Fit (⛶ Fit button): Instantly pans and zooms the canvas viewport to comfortably frame all nodes currently placed on the canvas.
• Preview (Eye icon button): Launches the dedicated Live Rule Runtime Preview window to monitor real-time execution pulses and diagnostic traces without leaving the workspace.
• Curved Routing (Arc toggle button): Renders wire connections as smooth, aesthetic cubic Bézier curves (default routing mode).
• Right-Angled Routing (Stairs toggle button): Renders wire connections as clean orthogonal right-angled segments featuring obstacle avoidance around nodes, filleted 90-degree corner arcs, and semicircular crossover bridge jumps over intersecting lines.

d) Floating Canvas Minimap

Positioned at the bottom-right corner of the canvas:

• Minimap (RuleMinimapControl): Real-time miniature layout display showing all nodes, connections, and an interactive viewport bounding frame. Supports expanding, collapsing, and fast canvas panning across expansive rule topologies.

4.2.3 Required Nodes in a Functional Rule

For a visual graph to compile and execute successfully, it cannot just be a set of intermediate calculations. Every rule must follow a clear execution pipeline comprising at least one Trigger/Ingestion node and at least one Action/Sink node:

• Trigger / Ingestion Node:
• The entry point of a rule. It initiates graph execution upon receiving telemetry changes or external signals.
• Input Source: Ingests continuous telemetry points (e.g., Modbus registers, OPC UA variables) or internal memory storage registers.
• Event Input: Ingests push-based system events (e.g., VMS motion alerts, SIA receiver signals).
• *Note*: Without an ingestion node, the rule's logic has no starting trigger and will never evaluate.

• Action / Sink Node:
• The termination point of a rule. It converts in-memory evaluated results into physical or external impact.
• Output Target: Writes the final calculated data back to a device address or triggers system actions (e.g., toggling a Modbus coil, triggering a Milestone VMS alarm, writing a temperature setpoint to BACnet, or updating an Internal Storage point).
• *Note*: Without an action/sink node, a rule will evaluate its logic successfully in memory but will produce no external side effects or actions.

4.2.4 Connecting Graph Nodes: Mapping the Flow from Source to Sink

Once the required ingestion and action nodes are placed on the canvas along with any necessary intermediate functional blocks (math, comparisons, timers), the logic flow is established by connecting ports:

a) Understanding Ports:

• Input Ports (Left side of node): Receive incoming data values or trigger signals from upstream nodes.
• Output Ports (Right side of node): Emits calculated values, boolean matches, or execution triggers.

b) Drawing Connections:

• Hover over an output port on an upstream node (the cursor changes to a connection tool).
• Click and drag a connection wire from the output port.
• Drop the wire onto a compatible input port on a downstream node (e.g., connecting a boolean output to a logical gate input).
• Repeat this process to map the complete sequence of operations, carrying data smoothly from the trigger source, through the mathematical and logical processing blocks, and finally into the input ports of the Output Target data sink node.

c) Data Flow Validation:

• Connections must map compatible data types (e.g., passing a float to a float math input).
• The visual editor automatically highlights valid ports and blocks invalid or recursive connections to ensure static compilation stability before metadata is saved.

4.2.5 Real-Time Rule Execution Debugging

To facilitate seamless validation, troubleshooting, and tuning of complex automation workflows, Uniflow features a state-of-the-art Live Rule Runtime Preview engine. Instead of debugging in isolation or reading raw text logs, operators can observe their logic executing in real time directly on the visual canvas.

a) Initiating a Live Debugging Session

To attach the debugger to a rule:

Step 1. Navigate to the Rules section in the main navigation.

Step 2. Select the desired rule from the list grid.

Step 3. Click the Preview Rule (Live Execution Trace) button on the grid toolbar.

Step 4. This launches the dedicated Rule Runtime Preview window, which automatically subscribes to the background UniflowService runtime engine via named pipes to stream live telemetry and event execution traces.

b) Dynamic Flow Pulsing (Canvas Tracing)

The preview canvas updates dynamically, using colored glowing "pulses" to visualize data flow and execution frequency:

• Computational State Pulses: Nodes and wire connections emit immediate glowing pulses corresponding to their result state:
• Teal Glow (Succeeded): Indicates that the node evaluated successfully without errors.
• Red Glow (Failed): Indicates that the node encountered a runtime exception or failed evaluation.
• Amber Glow (Skipped): Indicates that the node was bypassed due to logical branching.
• Deep Blue Glow (Running): Indicates an ongoing asynchronous task or loop execution.
• Execution Path & Value Propagation: Active value transitions trigger distinct Bright Blue or Purple pulses along the connections to indicate exactly how data travels through ports.
• Fading & Temporal Decay: Older execution pulses automatically fade away over a brief, calculated interval. This creates a temporal trail, allowing operators to visually see the frequency, speed, and exact path of the latest trigger events.

c) Integrated Diagnostics & Live Logs Terminal

Complementing the visual canvas is a detailed log terminal displaying a synchronized millisecond-precise live feed of rule activities:

• Millisecond-precise Timestamps: Logs are stamped in a high-precision format (HH:mm:ss.fff) to capture fast-moving, high-frequency triggers.
• Color-Coded Severity Levels:
• INFO (Blue): General attachment, session state, and diagnostic connections.
• RULE (Teal): Global rule execution starts, finishes, and broad outcomes.
• ERROR (Red): Detailed exception stack traces, network timeouts, or variable retrieval issues.
• WARN (Amber): Out-of-bounds metrics, quality drops, or retry occurrences.
• DEBUG (Gray): Granular trace outputs representing intermediate computations inside individual node blocks.
• Continuous Stream Auto-Scroll & Pause Mode: Incoming traces and logs automatically append and scroll to the newest entry as they arrive. To freeze the stream and inspect a specific historical trace in detail, click the Pause button.
• Fit to View: Click the Fit command to instantly scale and center the canvas, keeping large and complex rule topologies fully visible at a glance.

4.3 Anatomy & Meaning of Graph Nodes

Once metadata is committed, the user enters the visual canvas. Logic is constructed by connecting functional building blocks known as Nodes.

4.3.1 What is a Graph Node?

A Graph Node represents a self-contained, atomic execution unit designed to perform a specific, focused task. Conceptually, every node operates on a simple three-stage principle: it ingests incoming data parameters across its input ports, executes its designated internal logic transformation (such as calculating a mathematical equation, filtering a signal, or evaluating a logical comparison), and immediately pushes the resulting calculated values or control flow commands outward through its output ports.

• Input Ports (Left side): Receive data values or execution control flows from upstream nodes.
• Core Logic Engine (Center): Evaluates incoming variables, performs mathematical transformations, or tests boolean conditions.
• Output Ports (Right side): Transmit the resulting data values or branched execution flows onward to downstream nodes.

4.3.2 Port Data Types & Color System

Every input and output port on the visual canvas is color-coded by its underlying data type, allowing operators to immediately discern schema structures and verify connection type compatibility at a glance:

4.3.3 Node Inspector Layout & Ergonomics

When a node is selected on the canvas, its configuration panel opens in the right-side inspector:

• Input Port Data Bindings Positioned at Top: For all graph nodes, property editors that correspond to incoming connection ports (e.g. Value, Other, OP, CLK, PV) are systematically pinned at the very top of the BINDING group. This ensures operators can immediately review static values or wire bindings without scrolling through general node parameters.
• Spacious Multiline Editors with Auto-Scrolling: Long string arguments and multiline payloads (such as Constant String and String Equal's "Other" argument) feature word wrapping and automatic vertical scrollbars with a maximum height of 220px, providing comfortable viewing and editing without distorting the inspector pane.

4.4 Exhaustive Graph Node Catalog

Below is the complete, exhaustive catalog of all 78 visual graph nodes available in Uniflow, organized by category, matching the exact icon bindings, port definitions, and operational behaviors of the Uniflow Rule Engine.

4.4.1 Sources In/Out (Ingest)

Nodes that initiate workflow execution or read live telemetry and memory variables into the graph.

Input Source

Event Input

Data Source

4.4.2 Actions & Sinks

Nodes that execute state changes, write data outward, or trigger external actions.

Output Target

4.4.3 Constants

Nodes providing static, unchangeable primitive values into the graph.

Constant Number

Constant Boolean

Constant String

Constant Array

Vector

Current Time

Guid

4.4.4 Logic & Comparisons

Nodes executing logical operations and boolean comparison checks.

Greater Than

Greater Than or Equal

Less Than

Less Than or Equal

Equal

Not Equal

Logical AND

Logical OR

Logical NOT

Logical XOR

Is NULL

Default Value (Coalesce)

4.4.5 Flow Control

Nodes controlling branching, routing, and conditional execution paths.

Branch (If / Else)

Multi-Condition If

Switch

Select

Gate

4.4.6 Strings

Advanced string manipulation, formatting, and pattern matching nodes.

Format

Regex Extract

Substring

Replace

Contains

Equal

IndexOf

Trim

Upper

Lower

Length

Is Empty

4.4.7 Arithmetic Math

Nodes performing core numeric arithmetic across floating-point and integer types.

Addition

Subtraction

Multiplication

Division

Square Root

Power

Logarithm

Sine

Cosine

Tangent

Random

Abs

Min

Max

Round

Floor

Ceiling

Clamp

Vector Math

###### Available Vector Math Operations

The Vector Math node supports 21 distinct operations covering vector arithmetic, matrix inner/outer products, distance metrics, geometric projections, norm calculations, clipping, and component masking:

4.4.8 Timers & Pulses

Industrial automation timing blocks for signal conditioning and delayed execution.

Pulse (TP)

Timer On-Delay (TON)

Timer Off-Delay (TOF)

Value Delay

Rising Edge (R_TRIG)

Falling Edge (F_TRIG)

Any Change

4.4.9 Signal & State

Industrial automation logic blocks for maintaining states, latched signals, and pulse counts.

Linear Scaling

Moving Average (Smoothing)

Hysteresis Filter

SR Flip-Flop

RS Flip-Flop

Count Up (CTU)

Count Down (CTD)

Count Up/Down (CTUD)

4.4.10 Arrays

Managing, filtering, and performing operations on ordered lists of data.

String Split

Array Scope

Filter Array

Any Match

All Match

Array Contains

Array Index

Array Length

Is Empty

Get Item

Average

Sum

Minimum

Maximum

4.4.11 Collections & Object Extraction

Nodes designed for parsing structured, multi-property object records.

Collection Scope

Collection Filter

Collection Sort

Collection First

Object Get

Collection Any

Collection All

Collection Count

Collection Select

4.4.12 JSON Utilities

Nodes for parsing, validating, building, and extracting values from JSON payloads.

Deserialize

Serialize

To Collection

Extract

Is Valid

4.4.13 DateTime

Nodes for parsing, manipulating, and comparing timestamps and date/time objects.

Parse Date

Date Diff

Date Add

Date Equal

4.4.14 Bitwise

Low-level masking and bit manipulation for PLC holding registers.

Explode

Pack

Test

AND

OR

XOR

NOT

Shift Left

Shift Right

4.4.15 Cryptography

Security-focused nodes for data encryption and integrity verification.

AES

RSA

SHA-2

MD5

4.4.16 Tools

File I/O and data conversion utility action nodes.

Read File

Data Converter

5. Source Adapters & Configuration Parameters

Uniflow supports multiple source adapters. Each adapter requires specific configuration parameters to successfully initialize network bindings, establish communication handshakes, and ingest field data.

5.1 Built-In System Sources

In addition to external source adapters, Uniflow features two foundational built-in sources available to trigger rule execution:

• System Timer
• A built-in interval clock that generates periodic execution impulses at a configured frequency (governed by the system setting HeartbeatIntervalMs, defaulting to 100ms / 10 Hz). It is deployed to drive scheduled workflows, watchdog heartbeats, or periodic polling tasks.

• Internal Storage
• A built-in source linked directly to Uniflow's internal memory registry. Whenever a targeted storage variable changes state, it instantly awakens bound rule graphs, allowing engineers to chain multi-stage calculation pipelines seamlessly.

5.2 Sources "Data Points" vs. Event/Direct Data Ingestion

While many source adapters sample multi-variable data tables via Data Points, others operate without Data Points and instead inject data directly through event triggers or exposed data payloads (collections or scalar values).

• Data Points Ingestion: Used by adapters that map specific, addressable memory registers or variables within an external device (e.g., Modbus registers, OPC UA nodes, SNMP OIDs, BACnet objects). Uniflow either continuously polls these data points at configured intervals or subscribes to value changes. Incoming bytes are unpacked, converted to strongly typed values (Integers, Doubles, Booleans, Strings), and cached for evaluation.
• Configuring Data Points: In adapter settings with point tables, click Add Point (+) to define Point ID / Name, Address / Register, Data Type, and Access permissions.

• Event & Direct Data Ingestion (No Data Points): Many adapters do not require configuring individual Data Points. Instead, they interact with Rule Graphs through:
• Event Inputs: Pushing real-time event triggers and structured payloads directly into visual rule graphs (e.g., VMS motion/analytic alerts, SIA receiver alarm codes, Lidar spatial intrusion events).
• Directly Exposed Data: Exposing raw scalar values, JSON strings, or collection objects directly across the graph node interface (e.g., incoming MQTT topic payloads, HTTP REST response bodies, raw serial line buffers).

5.3 Internal & System Classifications

5.3.1 System Timer

• PollIntervalMs (Integer | [Required] | Default: 1000): The precise time interval in milliseconds between execution pulse ticks.

• Rule Graph Node Interface:
• InputSource: Trigger (Boolean) - Periodic clock pulse trigger.
• DataSource: Not supported.
• EventInput: Not supported.
• WriteValue: Not supported.

5.3.2 Internal Storage

• PointId (String | [Required] | Default: ""): The exact storage tag identifier or memory address key to monitor.

• Rule Graph Node Interface:
• InputSource: Value (Any) - Fires execution on any memory variable changes, emitting the new state.
• DataSource: Value (Any) - Returns the current cached memory state on demand.
• EventInput: Not supported.
• OutputTarget: Value (Any) - Updates the internal memory register with the incoming target value.

5.3.3 System Alerts

• Level (Dropdown / String | [Required] | Options: Warning, Info, Critical): The severity level assigned to the generated alert.

• Message (String | [Required] | Default: ""): Human-readable alert notification text describing the specific event or state.

• Rule Graph Node Interface:
• InputSource: Not supported.
• DataSource: Not supported.
• EventInput: Not supported.
• OutputTarget:
• Trigger (Boolean) - Pulse input to initiate alert generation.
• Level (String) - Severity level (Warning, Info, Critical).
• Message (String) - Alert notification string payload.

5.4 External & Industrial Protocol Plugins

6. Advanced Features & Troubleshooting

6.1 Diagnostic Inspection & Error Tracing

When a visual rule fails or an adapter reports a fault:

Step 1. Navigate to the Logs view.

Step 2. Ensure the Level Filter is set to Error or Warning to isolate the problem.

Step 3. Locate the error entry and double-click the row to view the complete multi-line stack trace.

Step 4. For source adapters, switch to the Sources view and observe the Runtime Status error sub-label, which provides immediate driver-level feedback (e.g., *Socket Timeout*, *Authentication Refused*, *Register Out of Bounds*).

6.2 Troubleshooting Rule Bottlenecks & Backpressure Drops

When a rule triggered by high-frequency telemetry (InputSource) attempts to execute actions that take longer to resolve than the incoming trigger interval, the rule enters Backpressure Skip State.

6.2.1 Understanding Backpressure Alerts

When executions are dropped, Uniflow raises a system warning alert in the Alerts Panel and logs a diagnostic message:

• Alert Message: Rule '{RuleName}' is skipping executions due to backpressure.
• Enriched Detail: Rule execution dropped because previous execution is still running. Currently executing action '{ActionName}' targeting '{TargetSourceName}' (running for Xs).
• Alert Debouncing: To prevent alarm fatigue and log saturation during continuous data floods, Uniflow uses state-transition alerting. An alert is raised when the rule transitions into skip state. The rule must experience at least 5 seconds of continuous healthy operation (zero dropped executions) before it clears the skip state and can trigger a new alert.

6.2.2 Diagnosing the Root Cause

1. Inspect the Alert Detail: The alert detail immediately identifies the exact bottleneck:

• Action Name: Which specific action node is actively executing (e.g., Save Snapshot to Folder vs. Insert Database Record).
• Target Source: Which external system or adapter is holding execution (e.g., Camera vs. Postgres).
• Duration: How long that specific action has been running (e.g., running for 2.3s).

1. Examine Live Rule Runtime Preview:

• In the Rules table, click the Preview button ([P]) on the affected rule.
• Look for nodes glowing Deep Blue (indicating an active asynchronous task or external I/O wait).
• Trace nodes highlighted in Amber to observe skipped branches.
• Review millisecond-precise timestamps in the integrated diagnostic terminal to quantify latency across individual nodes.

6.2.3 Common Root Causes of Bottlenecks

• Physical Device & Network Protocol Sinks: Hardware actions (such as ONVIF camera snapshot downloads, SOAP operations, PTZ movements, slow serial/TCP endpoints, or remote HTTP webhooks) typically take between 300 ms and 3,000 ms to complete. If an upstream sensor (such as Lidar MQTT) produces updates every 50 ms, 10–20 incoming triggers will be dropped every time a physical action is invoked.
• Synchronous Database Operations: High-frequency INSERT or UPDATE actions executing directly against relational databases without write batching can hit connection pool limits or disk I/O contention.
• Sequential Action Blocking: Because actions within a rule execute sequentially, placing a fast action (e.g., database logging) after a slow action (e.g., camera capture) means the fast action is delayed or dropped whenever the slow action holds the lock.

6.2.4 Mitigation Strategies & Architectural Patterns

To eliminate backpressure drops and ensure reliable operation under high load, apply these design best practices:

• Pattern 1: Rule Splitting (Decouple Fast Sinks from Slow Hardware Sinks)
• *Problem*: A single rule takes a camera picture (slow) and logs metadata to a database (fast). When the camera is busy, database records are lost.
• *Solution*: Split the logic into two separate rules triggered by the same input source:
• Rule A: Database Logger (Priority = 80): Evaluates the condition and writes immediately to the database. Completes in 1–5 ms. Holds the gate for mere milliseconds and never drops triggers.
• Rule B: Camera Snapshot (Priority = 50): Evaluates the condition and commands the camera. Takes 1,000 ms. Safely drops redundant snapshot triggers during bursts without affecting the database.

• Pattern 2: Choose EventInput for Zero-Drop Event Queuing
• If every single incoming message must be evaluated and recorded without skipping (e.g., discrete transactional records, file ingest, access control events), configure the trigger using an EventInput node rather than an InputSource node. Event inputs automatically queue executions rather than dropping them.

• Pattern 3: Action Cooldown & Trigger Debouncing
• In the outbound action node's property panel, set a Cooldown (ms) (e.g., 2,000 ms) or Debounce (ms). This ensures that physical devices (such as PTZ motors or cameras) are not commanded at a rate exceeding their hardware capabilities.

• Pattern 4: Optimize Write Policies
• Change the action Write Policy from Always to OnChange or OnChangeWithTolerance. If incoming values have not changed, the write is skipped instantly in memory without initiating an external network call to the target adapter.

• Pattern 5: Enable Decoupled Write Batching for Databases
• For database sinks using the DBLink adapter, ensure Write Batching & Backpressure Mitigation is enabled in the source editor. Inbound writes are queued in-memory and committed in cohesive background batches (at 5 flushes/sec) over a pooled connection, completely eliminating rule backpressure drops.

6.3 Licensing Limits & Subsystem Verification

If new source adapters fail to start:

Step 1. Navigate to Settings → License.

Step 2. Inspect the Status Badge Card to ensure the system is not reporting *UNLICENSED SYSTEM* or *LICENSE EXPIRED*.

Step 3. Review the Allowed Capacity Limits Table to verify that your active source counts do not exceed the permitted connection thresholds for that specific SourceType.