OPC UA at the Edge
Position Banalytics beside an OPC UA server or gateway to turn selected industrial context into local operations, events, and controlled integration.
OPC UA provides an information-model and secure interoperability layer; it does not itself operate the edge workload around it. A practical architecture combines an OPC UA client, server, or gateway with a local operating layer that owns device-adjacent processing, event response, health, retention, and lifecycle.
Use OPC UA for industrial context; use the edge for local execution
OPC UA is commonly used to expose industrial data and methods through an address space with typed nodes, metadata, security controls, and subscriptions. It can connect PLCs, SCADA, historians, MES, gateways, and specialist applications across a heterogeneous industrial estate. The protocol answers an important interoperability question: how should industrial information be represented and exchanged?
It does not answer every edge question. A deployment still needs to decide how to acquire cameras and sensors, run local processing, manage storage, retain evidence, detect missing sources, supervise dependencies, create operator events, and continue through a WAN outage. Those are the responsibilities that can sit with Banalytics on the local site.
Current integration boundary: Banalytics documentation does not describe a native OPC UA client or server component. Where OPC UA is required, use a validated OPC UA gateway, sidecar, or custom integration and treat it as an explicit part of the deployment. Do not present Banalytics as a direct OPC UA replacement or as a claim of native protocol support.
Place the Agent beside the systems that need local autonomy
| Placement | OPC UA role | Banalytics role |
|---|---|---|
| Industrial PC on the cell or line network | Local client or gateway reads selected OPC UA nodes and subscriptions from controllers or equipment. | Runs acquisition around cameras, media, Modbus, MQTT, files, and local tasks; interprets selected gateway outputs into events and workflows. |
| Same host as an OPC UA sidecar | Sidecar uses an approved SDK or gateway to provide a defined OPC UA-to-message, file, database, or local API contract. | Supervises the helper lifecycle, observes host health, and owns the surrounding operational response. |
| Plant integration zone | Gateway normalises data between OT address spaces and plant applications. | Collects local evidence and provides an edge boundary before selected outcomes are delivered to OT/IT consumers. |
| Remote enterprise or cloud layer | Central OPC UA or industrial service consumes shared state where policy permits. | Continues local tasks, storage, and rules independently; exports only the contextual data package needed centrally. |
The goal is not to copy an entire OPC UA address space into every edge application. Select the nodes, events, and methods that the local workflow genuinely needs, attach source and quality context, and keep controller authority where it belongs.
Make the OPC UA bridge a first-class component of the architecture
An OPC UA gateway or sidecar can subscribe to selected nodes, validate certificates and endpoint configuration, map values into a stable local contract, and publish that contract through MQTT, ZeroMQ, a local database, files, or a purpose-built API. Banalytics then consumes or orchestrates the resulting local data path according to the chosen interface.
| Bridge output | Suitable Banalytics use | Contract to define |
|---|---|---|
| MQTT telemetry or event | Topic listener converts incoming messages into events for local rules and actions. | Topic ownership, schema version, source timestamp, node identity, status/quality, retained-state policy, and reconnect behaviour. |
| ZeroMQ message | Local high-speed service exchange between the sidecar and specialist processing or Banalytics logic. | Socket role, schema, timeout, queue/back-pressure, health signal, and process lifecycle. |
| File or local database record | Batch analysis, retained evidence, or integration with a local processing pipeline. | Atomicity, naming, timestamp, retention, permissions, and incomplete-write detection. |
| Local HTTP API | Bounded lookup, configuration, or request-response integration through a trusted custom adapter. | Endpoint and authentication policy, request limit, idempotency, response semantics, and failure handling. |
The Process component can supervise a named sidecar service, including a protocol bridge or local API server. It deliberately treats the helper as separate software: start and stop lifecycle, output capture or redirection, permissions, and a support runbook must be designed as carefully as the Banalytics configuration.
Preserve meaning when moving from address-space nodes to edge events
An OPC UA node value without its identity, status, source timestamp, engineering context, and current equipment mode can be misleading. The gateway contract should preserve at least the node or asset identity, data type and units, source time, status/quality, server or gateway connection state, and relevant model or namespace version.
At the Banalytics boundary, turn that data into an operational event only when it represents a meaningful condition. A value update is not automatically an alert. Define the threshold, rate of change, persistence window, suppression rule, asset criticality, and named response owner. This prevents a healthy high-frequency subscription from becoming a flood of operator notifications.
When the local workflow also uses camera, environmental, or machine-adjacent data, Banalytics can supply the additional context at the same site. A detected visual state, a Modbus reading, and an OPC UA gateway value may support the same operator decision while still retaining their separate source and quality boundaries.
Keep control authority in the appropriate industrial system
OPC UA methods and writable nodes can expose useful controlled operations. They can also provide a route to consequential equipment changes. An edge workflow must distinguish a request to a gateway from a controller-validated state change, and it must not bypass existing interlocks, permissions, or maintenance procedures.
- Give each control request an authorised origin, target asset, validity window, correlation identifier, audit trail, and expected acknowledgement.
- Verify the current equipment mode and any required preconditions in the responsible controller or gateway.
- Read back the relevant state, but do not assume a transport response alone proves a safe physical completion.
- Keep safety PLCs, safety relays, DCS, SIS, and certified control logic as the authority for their intended protective functions.
- Use Banalytics for monitoring, bounded orchestration, evidence, notifications, and supervised workflows-not as a replacement for functional-safety systems.
Monitor the bridge and the edge workload as one service chain
A sound design reports more than source values. It makes visible certificate expiry, endpoint reachability, session/subscription state, queue growth, missed updates, mapping errors, sidecar restart, local storage, and host resource pressure. Otherwise an outage may look like a stable last-known process value.
Banalytics System Monitor supplies the host-level view: CPU, memory, disk, thread, media, WebRTC, and user-activity state can become local system events. Combine this with gateway-specific health output, then use Event Manager to route only actionable conditions to technicians, dashboards, or approved integration channels.
For local transport between the bridge and other services, ZeroMQ Socket provides an explicit messaging boundary. MQTT is a better fit where devices and applications need publish/subscribe delivery. The right choice depends on payload, latency, ownership, retry semantics, and the number of consumers-not on a desire to standardise every interface into one protocol.
Start with a small, evidence-rich OPC UA edge slice
- Select one asset and a limited node set with a named operational use case.
- Define the gateway mapping, identity, source time, quality, units, status, and failure contract.
- Run the bridge beside Banalytics as a supervised service and test disconnect, certificate, restart, malformed-data, and back-pressure conditions.
- Use events and dashboards for advisory review before allowing any workflow to request a controlled write.
- Version the mapping, sidecar, Banalytics rules, and runbook before reproducing the pattern across lines or sites.
In this architecture, OPC UA carries industrial context across a defined interoperability boundary; Banalytics makes the local workflow around that context observable, resilient, and useful to operators. Keeping those roles explicit produces a system that is easier to validate, evolve, and support.