Skip to main content
Edge Execution

Run Logic
Where Operations Happen

Keep logic, buffering, and decisions close to the process. Proxus Edge keeps operations running during outages, preserves data with store-and-forward, and scales from single gateways to distributed deployments.

Evaluating the broader operating model? Start with the Industrial Edge Platform overview for rollout, governance, and delivery patterns.

Proxus Edge Computing - Distributed intelligence at the industrial edge
CONNECTION LOST
Buffering Locally...

Offline-First Architecture

Network failures are a normal design condition. Supported local collection, rules, and alarms can continue when their local dependencies remain available. Buffering and recovery are bounded by configured capacity, retention, write rate, connector acknowledgements, and outage duration. See edge orchestration in action.

  • ✓ Resilient Store & Forward
  • ✓ Automatic Sync on Reconnect

Process data close to the assets

Processing data on the site avoids making every operational decision dependent on a remote network path. Actual latency depends on hardware, protocol, scan rate, workload, rule complexity, and measurement boundary; safety and deterministic control remain in the PLC or safety system.

Local
Proxus Edge
Remote
Cloud Roundtrip
Cloud
WAN PATH
Edge
SITE PATH
Cloud-First (Raw) Edge-First (Smart)
Raw stream
Bandwidth Load
filter_alt
Selected stream
Bandwidth Load

Control what crosses the site boundary

Sending every sensor reading to the cloud is expensive and inefficient. Proxus Edge filters noise, aggregates data (for example, 1-minute averages), and only transmits changes or anomalies. Explore edge patterns below.

  • ✓ Lower 4G/5G Data Costs
  • ✓ Reduced Cloud Ingress Fees
  • ✓ Smarter Data for Analytics and AI

How Proxus Edge Works

Proxus Edge uses a distributed, event-driven architecture similar to the central platform. Gateways stay stateless, while configuration and workloads are orchestrated from the central server over reliable messaging. For technical details, see the edge architecture docs.

  • Edge Orchestration
    Starts and supervises edge workloads on each gateway. Receives configuration from the central platform and rolls out updates safely over the messaging layer.
  • Smart Data Router
    Collects telemetry from fieldbus and MQTT sources, normalises tags, and routes only relevant events to rules, functions, and integrations.
  • Local Intelligence & Safety
    Runs rules and custom logic right at the edge so safety logic, interlocks, and optimisations keep working even when the cloud is slow or offline.
  • Durable Storage & Integrations
    Streams buffered events to time-series databases, data lakes, and external platforms once connectivity is available, without losing order or data.

The Edge Stack

cloud
Cloud
database
DB
settings
PROXUS EDGE
Normalize• Buffer• Rule
precision_manufacturing
PLC
sensors
Sensor
memory
CNC

Edge Computing Patterns with Proxus

Proxus implements proven edge patterns so you do not have to reinvent them. Each pattern maps directly to actors and configuration you already manage from the central server. See the success story for results.

Buffered Edge

The system buffers every event locally when the link to the central UNS is down. Once the line is back, data is replayed in order to your configured data stores and integrations.

Local Autonomy & Safety

The edge rule engine and custom functions continue to execute safety logic, interlocks, and optimisation rules even when the cloud is slow or unavailable.

Fan-Out to Multiple Targets

The same stream of telemetry can be routed to UNS, time-series databases, cloud platforms, or on-prem systems using reusable integration targets without duplicating logic.

Pilot Acceptance Boundary

Validate local operation, buffer capacity, recovery, data quality, security controls, and central delivery before fleet-wide rollout.

Bandwidth and latency results must be measured on the target hardware, protocol mix, sampling profile, network, and workload before they are used as project commitments.

Ready to push intelligence to the edge?

Deploy your first Proxus Edge Gateway, connect a line, and start processing data at the source in hours instead of weeks.

Technical and Commercial Evaluation

Industrial Edge Computing Architecture evaluation guide

Operational problem it addresses

Remote-only processing makes operational visibility and data delivery dependent on network availability. Edge computing places supported collection, context, rules, buffering, and visualization near the assets while keeping safety and deterministic machine control in their proper control systems.

Data sources it connects

  • Industrial controllers, sensors, meters, and machine interfaces
  • Local OPC UA, Modbus, S7, MQTT, and supported endpoints
  • Site context from production, maintenance, and quality systems

How the data is processed

  1. 1.Acquire signals on the site through approved connections.
  2. 2.Apply local normalization, context, filtering, and supported calculations.
  3. 3.Buffer selected outbound data within configured capacity and retention.
  4. 4.Forward governed results to central storage, UNS, and enterprise targets.

Edge and outage behavior

Failure modes must be designed by dependency. Local functions can continue only when their source, compute, storage, identity, and visualization dependencies are available. Recovery behavior must be tested with realistic outage duration, data rate, disk pressure, reconnect, duplicate, and target-unavailable scenarios.

Systems that consume the data

  • Local HMI and dashboards
  • Site operations
  • Central operations
  • Historian
  • UNS
  • MES
  • Analytics

Security and deployment boundary

Edge processing does not bypass OT security. Source access, local privileges, certificates, software updates, outbound-only rules, remote administration, log retention, and physical access remain customer-controlled security decisions.

Technical validation and next step

When it is a good fit

  • Local visibility or processing must survive central-network loss.
  • Raw streams should be contextualized or filtered before leaving the site.
  • Failure and recovery behavior can be tested on representative workloads.

When it is not a good fit

  • The design moves safety or deterministic control into a general-purpose edge application.
  • Unmeasured latency or bandwidth targets are treated as universal guarantees.
  • The site cannot provide lifecycle ownership for edge compute and storage.

Evaluation FAQ

Is edge computing suitable for safety control?

No. Safety and deterministic closed-loop control should remain in PLC, safety PLC, or other validated control boundaries. Edge software can provide context, monitoring, and non-safety workflows.

What happens when the central connection fails?

Supported local functions can continue when their local dependencies are healthy. Outbound data can be buffered within configured capacity and retention; recovery depends on outage duration, data rate, acknowledgements, and target availability.

How should latency and bandwidth be evaluated?

Measure them on target hardware with the actual protocol mix, scan rates, transformations, rules, payloads, network path, and sustained workload. Do not reuse an unrelated benchmark as a project guarantee.