Designing a Rule Engine That Scales with Your Factory

I've designed five rule engines from scratch across three continents, and I can tell you with certainty that the gap between a naive threshold engine and a production-grade system is the difference between a prototype and a fortune. Industrial automation projects typically start with a deceptively simple requirement:

"Send an alarm if this tag exceeds that value."

But real plants quickly outgrow simple threshold checks. Within weeks, engineering teams ask for:

• Multi-step workflows (IF X THEN Y, THEN Z)
• Time-based dependencies (IF X for >5 minutes THEN...)
• Dependencies across multiple lines or sites (IF Line1.OEE < 60% AND Line2.Running THEN...)
• Integration with ERP, CMMS, and ticketing systems (THEN create SAP maintenance order)
• Feedback loops and state machines (Rule A triggers Rule B, which triggers Rule A again?)

Most off-the-shelf IIoT rule engines falter here. They either offer extreme simplicity (and shatter under complex logic) or extreme complexity (requiring a specialized developer to maintain).

Proxus takes a different approach: combining visual rules for common use cases with C# code for edge cases, all operating on a single, unified execution runtime that can handle high-volume rule evaluation (performance varies with workload and hardware).

Outcomes depend on workload profile, hardware capacity, and deployment topology.

The Problem with Traditional Rule Engines

Before diving into the Proxus solution, let's understand why rule engines are so difficult to scale in industrial environments:

Challenge #1: Scope Creep

A simple threshold rule inevitably mutates into a state machine. What started as "alert when temp > 80°C" becomes "alert when temp > 80°C for >2 minutes, but not if we're in cooldown mode, but absolutely alert immediately if temp > 85°C."

Challenge #2: Multi-Device Correlation

"Trigger an alarm when Robot A is running AND Pressure Sensor B shows declining pressure AND we are not in a maintenance window." This requires:

• Reading cross-device states simultaneously
• Correlating asynchronous events
• Checking context overrides (maintenance flags)

Challenge #3: Performance at Scale

A medium-sized plant with 5,000 devices and 2,000 rules needs to evaluate millions of conditions per second. A naive approach (e.g., querying a SQL database for each rule trigger) hits an operational bottleneck almost immediately.

Challenge #4: Versioning & Deployment

When you update a rule logic, how do you:

• Test it without crashing production?
• Roll back immediately if it triggers false alarms?
• Track which version of the rule is running on which gateway?

Most legacy systems offer horrifyingly poor answers to these questions, usually involving manual file copies or restarting entire services.

The Proxus Approach: Visual + Code Unified

Proxus solves structural limitations by offering two complementary authoring approaches that compile down to a single high-performance runtime:

Visual Criteria Builder (No-Code)

For process engineers and operators without a software engineering background, the visual rule builder provides an intuitive condition-building interface. Think of it as "advanced Excel logic for automation."

Building Blocks

Triggers (When to evaluate)

• Data Received: Evaluates the rule instantly against every new telemetry packet
• Schedule: Time-based patterns (e.g., daily at 08:00, every 15 minutes)
• Manual trigger: Operators execute the rule ad-hoc via the UI for testing

Criteria Expressions (What to check) Rules are constructed by chaining logical conditions together using a structured visual tree, allowing complex evaluations without writing syntax:

• Property Checks: [Payload][Key = 'Temperature']
• Numeric Thresholds: NumericValue > 80
• Compound Boolean logic: Linking conditions with AND / OR blocks
• Contextual Filters: [Attributes][Key = 'Location' AND Value = 'Sector_A']

Actions (What to execute)

• Notifications: Push via Email, SMS, Slack, Microsoft Teams, Discord
• Write back to Edge: Send values back to physical devices (turn on pump, close valve)
• MQTT Publish: Emit messages to the Unified Namespace for other systems to consume
• HTTP / Webhooks: Trigger workflows on external REST APIs
• Create CMMS Tickets: Automatic SAP / Maximo integration (generate maintenance orders)

Example Rule Hierarchy

Instead of a tangled web of nodes, logic is cleanly structured in a condition tree:

```sql
-- Evaluated instantly on Data Received
[Payload][Key = 'Line1.Robot.Temperature' AND NumericValue > 85]
AND [Attributes][Key = 'Robot.Running' AND Value = 'True']
AND NOT [Attributes][Key = 'MaintenanceMode' AND Value = 'True']
-- Throttle Period ensures alarms don't spam if state persists

Resulting Actions Pipeline:

• Execute HTTP Webhook: Stop downstream feed (Write to "Line1.Conveyor.FeedCommand")
• Execute MQTT Output: Publish to "ProxusMfg/Line1/alerts/TemperatureSpike"
• Execute Integration: Create SAP notification "Maintenance Order - Thermal limit exceeded"
• Execute Notification: Send Slack message "@production_team Feed stopped due to temp"

C# Scripting for Power Users

When logic becomes too intricate for a visual flowchart, Proxus allows engineers to drop down into C# Sandbox Scripts.

Why C#?

• Familiarity: Uniquely understood by modern automation engineers (.NET is ubiquitous in OT).
• Safety: Strongly typed and compiled (catching errors before runtime).
• Performance: JIT-compiled to raw machine code.
• Robust Ecosystem: Native access to LINQ, Math libraries, and structured data handling.

Example: Multi-Device Correlation with Predictive Models

// Proxus Edge SDK: Predictive Maintenance Function
public class PredictiveMaintenance : FunctionBase {

 public PredictiveMaintenance(object sys, object log, object cfg)
 : base(sys, log, cfg) { }

 protected override void OnStarted() {
 Subscriptions?.Add(new SubscriptionContext {
 Type = typeof(TransportData),
 Topics = (HashSet<string>) ["*"]
 });
 // Enable time-windowed cache for historical analysis
 EnableCacheWithExpirationTime = TimeSpan.FromHours(1);
 base.OnStarted();
 }

 protected override void OnMessageReceive(FunctionContext ctx) {
 if (ctx.Message is TransportData data) {
 var vibration = data.GetPayloadValueByName<double>("Vibration");
 var temperature = data.GetPayloadValueByName<double>("Temperature");

 // Query cached historical data for trend analysis
 var recentAvgTemp = Cache
 .Where(kv => kv.Key >= DateTime.Now.AddMinutes(-30))
 .Select(kv => kv.Value)
 .SelectMany(t => t.Payload)
 .Where(p => p.Key == "Temperature")
 .Select(p => Convert.ToDouble(p.Value))
 .DefaultIfEmpty(0)
 .Average();

 if (vibration > 4.5 && temperature > recentAvgTemp * 1.3) {
 PublishMqttMessage(
 "alert/motor_failure_risk",
 $"Vibration: {vibration}, Temp: {temperature}°C");
 LogError(
 $"Motor failure risk detected. Score: {vibration * temperature:F0}");
 }
 }
 base.OnMessageReceive(ctx);
 }
}

Auto-Injected Safety Boundaries

In conventional systems, bad custom scripts crash the entire host process. Proxus automatically wraps user scripts:

// Proxus Edge SDK: Safe data construction with TransportDataBuilder
// The builder pattern ensures valid payloads without runtime exceptions:

var alert = new TransportDataBuilder()
 .WithTopic($"EdgeAlert{this.GatewayId}")
 .WithPayload("AlertType", "TemperatureSpike")
 .WithPayload("Value", temperature.ToString())
 .WithMetaData("DeviceName", "Motor-B")
 .WithAttribute("Severity", "Critical")
 .Build();

// Publish to all edge gateways via NATS JetStream
PublishToEdgeGateways(alert);

// Or save directly to the system database
Save(alert);

Low-Allocation Patterns

For rules evaluated 1,000+ times per second, Proxus uses pool-based resource management to minimize Garbage Collection (GC) pressure:

// Proxus Edge SDK: Scheduled aggregate computation
// ExecuteScheduledTask runs a callback at fixed intervals:

protected override void OnStarted() {
 EnableCacheWithExpirationTime = TimeSpan.FromHours(1);
 _taskToken = ExecuteScheduledTask(
 TimeSpan.FromSeconds(30), ComputeAggregates);
 base.OnStarted();
}

private void ComputeAggregates() {
 // Zero-copy LINQ over the in-memory cache window
 var avgPressure = Cache
 .Where(kv => kv.Key >= DateTime.Now.AddHours(-1))
 .Select(kv => kv.Value)
 .GroupBy(t => t.MetaData.First(m => m.Key == "DeviceName").Value)
 .Select(g => new {
 Device = g.Key,
 AvgPressure = g.SelectMany(t => t.Payload)
 .Where(p => p.Key == "Pressure")
 .Select(p => Convert.ToDouble(p.Value))
 .Average()
 }).ToList();

 foreach (var device in avgPressure) {
 PublishMqttMessage(
 $"analytics/{device.Device}/pressure_avg",
 device.AvgPressure.ToString("F2"));
 }
}

A Single Unified Execution Model

Here is the architectural magic: both Visual Rules and C# Scripts compile down to the exactly same Actor-Based Runtime.

Uniform Performance

Visual rules compile to IL (Intermediate Language) bytecode, just like C# scripts. They execute on the same distributed actor engine with identical performance profiles.

Independent Scalability

On a single edge gateway (x64 hardware, 8GB RAM), throughput depends heavily on rule complexity:

• 1 Gateway (x64, 8GB RAM):
  • Simple threshold rules (e.g., IF temp > 80 THEN alert): 50,000–100,000 evals/sec
  • Complex multi-device rules (cross-device correlation, external HTTP calls): 1,000–10,000 evals/sec
• 10 Gateways: Each gateway evaluates rules independently; no central bottleneck. Total throughput scales linearly with number of gateways.
• Important: Performance assumes in-memory rule evaluation. External I/O (HTTP webhooks, database queries) adds 50-500ms latency per rule execution.

Seamless Evolution

Start by building a visual rule scaffolding. As the factory's needs grow (e.g., adding external HTTP calls or statistical smoothing), you can extract that specific logic branch to C# without ripping and replacing the entire workflow.

Execution Under the Hood: 100,000+ Rules/Sec

How exactly does Proxus evaluate logic this fast on constrained edge hardware?

1. JIT Compiled Execution: We do not parse JSON or XML flowcharts at runtime. Logic is compiled into native MSIL.
2. Actor Concurrency: Every executing rule runs inside an isolated Actor. This minimizes shared-state locking and helps reduce thread contention under high concurrency.
3. Smart In-Memory Caching: Subsequent evaluations of unchanging variables read from L1 CPU cache. The cache is only invalidated via explicitly subscribed MQTT topic changes.
4. Short-Circuit Evaluation: If Condition A evaluates to false in an AND chain, Proxus immediately halts execution-saving CPU cycles.

Security & Protective Sandboxing

Allowing engineers to upload arbitrary C# code is traditionally an security risk if unmanaged. Proxus neutralizes the risk:

Code Analysis and Blacklisting

The compiler explicitly blocks dangerous namespaces.

• ❌ System.Reflection (No dynamic code generation)
• ❌ System.IO (No destructive file system access)
• ✅ Whitelisted: System.Linq, System.Collections, System.Text

Strict Execution Sandboxes

Every C# rule operates within constrained limits:

• Memory Ceiling: Max 512 MB per AppDomain.
• CPU Timeouts: Max 5 seconds execution limit per invocation. If your regex loops high-scalely, Proxus shoots it down.

Git-Style Versioning & Rollback

Changing a rule that stops a production line is terrifying. Proxus implements a zero-fear deployment pipeline:

Rule: "Emergency Motor Stop Protocol"

v1: Threshold=85°C | Status: ACTIVE (Production Gateways)
v2: Threshold=82°C | Status: STAGING (Test Gateway)
*** Engineering tests v2 for 7 days with live shadow data ***
v3: Threshold=80°C | Status: APPROVED_PENDING_DEPLOYMENT

1. Write logic on the central platform.
2. Deploy to a designated Test Gateway simulating inputs.
3. Approve based on telemetry feedback.
4. Push safely to production gateways at scheduled downtimes.
5. Rollback in 50 milliseconds if anomalous behavior is detected.

When Complex Rule Engines May Be Overkill

In my experience, rule engines are sometimes overengineered for the problem at hand. Consider deploying simpler architectures in these scenarios:

• Hard Real-Time Safety Control: A safety-critical Emergency Stop or hardwired interlock should not rely on a rule engine, however robust. These decisions must remain in certified Safety PLCs hardwired with no software dependencies.
• Simple PLC-Resident Logic: If your automation needs are adequately served by native PLC logic (Boolean conditions, timers, counters), adding a rule engine introduces unnecessary operational complexity and maintenance burden.
• Single-Asset, Single-Criteria Plants: Factories with 3-5 simple threshold alarms may not justify the administrative overhead of a full rule engine platform. A basic SCADA alarm may suffice.
• Immature or Unstable Data Sources: If your tags are not consistently available, naming conventions are chaotic, or data quality is poor, a rule engine will amplify frustration rather than solve it. Stabilize your UNS first.

When this may not be suitable

• Lower-frequency telemetry may not justify full distributed complexity.
• Small single-line plants may prefer simpler architectures first.
• Strict legacy constraints may require phased adoption.
• Safety-critical closed-loop control should remain in PLC/Safety PLC layers.

Results vary with workload, hardware, and topology.

Frequently Asked Questions

When should I use the Visual Rule Builder vs. C# scripting?

Use the visual builder for 80% of rules: simple threshold alarms, notifications, basic conditional writes, and scheduled triggers. These are rules where the logic can be expressed as IF-THEN without complex state tracking. Drop to C# when you need: multi-device correlation across different PLCs, stateful computations (running averages, rate-of-change over windows), calls to external HTTP APIs, or integration with machine learning models. Many teams start visual and selectively migrate individual branches to C# as requirements grow - the unified runtime makes this seamless.

What latency can I expect from edge rule evaluation?

For visual rules compiled to IL, sub-5ms evaluation time from tag change to action execution is achievable on typical ARM/x64 edge hardware under suitable load conditions. C# scripts add overhead depending on complexity - a simple threshold check can run in microseconds, while a script calling an external HTTP endpoint adds network round-trip latency. Safety-critical rules (like Emergency Stops) should not run on IT or Edge hardware; they should remain hardwired in Safety PLCs. Edge rules are intended for operational control and orchestration.

How do I test rules without affecting production?

Proxus supports staged deployment: deploy rule version v2 to a Test Gateway running with live shadow data (subscribed to the same MQTT topics as production, but with actions disabled or routed to a test namespace). Monitor v2 for a defined period (typically 3–7 days). Only after validation do you promote it to production gateways. This approach prevents false alarms and unintended writes.

Can rules trigger on OPC UA data sources?

Yes. The rule engine operates on tags within the Unified Namespace, regardless of their original source protocol. If an OPC UA tag is mapped to the UNS via the Proxus Edge Gateway, it becomes a first-class trigger just like Modbus, S7, or native MQTT tags. The rule does not know or care about the upstream protocol.

How do rules synchronize across multiple Edge Gateways?

Rules are authored centrally on the Proxus Platform and deployed to specific Edge Gateways. Each gateway evaluates rules independently against its local tag set - there is no distributed consensus protocol, which is deliberate: it prevents network-dependent latency on safety-critical decisions. For cross-site correlation (e.g., comparing OEE across plants), use central rules that subscribe to aggregated UNS topics published by each gateway.

Conclusion: Rules as Production Assets

In Proxus, automation rules are not an afterthought bolted onto a visualization tool. They are first-class engineering assets: versioned, sandboxed, tracked, and often optimized.

Whether you need a simple email alert or a complex machine-learning orchestration script, the unified visual/code engine scales from single-use cases to mission-critical, high-frequency automation.

References

1. IEC 61131-3 - International standard for PLC programming languages, defining structured text (ST) and function block diagram (FBD) patterns that inspired industrial rule engine design. IEC 61131
2. Charles Forgy, "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem" (1982) - The foundational algorithm behind many production rule systems, relevant to understanding rule evaluation performance.
3. Carl Hewitt, "A Universal Modular Actor Formalism for Artificial Intelligence" (1973) - The mathematical foundation of the Actor Model used as the Proxus rule execution runtime.
4. OPC Foundation - OPC UA Alarms & Conditions - Specification for industrial alarm management via OPC UA, relevant as a data source for rule engine triggers. opcfoundation.org

Explore how the Proxus Rule Engine integrates with your existing architecture by reading our Edge Computing Patterns guide, or see how rules drive IT/OT convergence and predictive maintenance workflows.