Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

SNMP, MQTT, and IIoT Retrofits for Legacy B&R CP1584 Systems

Overview

This document covers how to add modern monitoring protocols (SNMP, MQTT, OPC-UA to MQTT bridging, time-series data logging, and dashboard visualization) to aging B&R X20CP1584 PLCs on machines built by defunct OEMs with zero documentation. The CP1584 is an Intel Atom 0.6 GHz CPU with 256 MB DDR2 RAM, 1 MB SRAM, CompactFlash storage, two independent network interfaces (IF2 = Ethernet 10/100/1000BASE-T, IF3 = POWERLINK V1/V2), and one X20 interface module slot. Its hardware constraints – limited RAM, CF card storage – shape every retrofit decision. See network-architecture.md for the full network interface details.

The goal is to achieve remote visibility into machines never designed for it, without touching the running PLC program, without the original Automation Studio project, and without vendor support.

AS6 / PVI 6.x Compatibility Note

If you are setting up your engineering workstation fresh, note that Automation Studio 6 ships PVI 6.x, which drops support for the legacy INA2000 protocol entirely. Only ANSL and SNMP lines remain. Since most IIoT retrofits in this document use OPC-UA or SNMP (not INA2000), this mainly affects PVI-based diagnostic scripts. Ensure any external tools connecting via PVI use ANSL, not INA2000. See pvi-api.md §2 and firmware-version-mgmt.md §5.3.1 for details.

DocumentRelevance
opcua.mdOPC-UA server configuration, namespace layout, certificate management
custom-diagnostic-tools.mdBuilding C/C++ tools that run ON the PLC – data loggers, custom monitors
python-diagnostics.mdPython-based diagnostics from external PC — OPC-UA and PVI scripts
ftp-web-interface.mdFTP and web interface access to CF card and SDM
cf-card-boot.mdCF card boot process, firmware, and runtime system details
pvi-api.mdPVI (Process Visualization Interface) for external programmatic access
diagnostics-sdm.mdSystem Diagnostics Manager built into Automation Runtime
cp1584-forensics.mdForensic analysis techniques for undocumented CP1584 systems

The Retrofit Problem: Why These Machines Are Hard

Machines built by defunct OEMs share common characteristics that make IIoT retrofits non-trivial:

  1. No Automation Studio project: The compiled binary runs on the CF card but there is no source code. You cannot modify the PLC program.
  2. OPC-UA tags not enabled: Even if the OPC-UA server is running, each variable must be explicitly enabled as a tag. On machines where the OEM never intended remote monitoring, zero variables are exposed. See opcua.md for the full explanation of this limitation.
  3. No network architecture documentation: IP addresses, VLANs, firewall rules – all unknown.
  4. Single Ethernet port: The CP1584 has only one RJ45 interface (IF2). POWERLINK (IF3) is a separate RJ45 but runs a different protocol. Adding a second network path requires an interface module (X20IF10xx series) in the single expansion slot.
  5. CF card storage is limited: Logging must be carefully budgeted. Write wear on CF cards is a real concern.
  6. CPU load budget: At 0.6 GHz with 256 MB RAM, adding a data pipeline on the PLC itself is feasible only if it is lightweight.

Retrofit Constraints Summary

ResourceCP1584 CapabilityRetrofit Impact
CPUAtom 0.6 GHzMQTT client on-PLC is feasible but budget cycles carefully
RAM256 MB DDR2, 1 MB SRAMOPC-UA server + MQTT client simultaneously possible on AR 4.x
StorageCompactFlash (512 MB - 8 GB SLC)Rotate log files aggressively; avoid FAT fragmentation
Network1x Ethernet + 1x POWERLINKGateway/Bridge approach keeps traffic off PLC
Expansion1 slot for interface moduleAdd a second Ethernet module if network segmentation needed

Protocol Stack Overview

Where Each Protocol Fits

   Cloud / MES / Dashboard
          |
      MQTT Broker          <-- Lightweight pub/sub, fan-out to N consumers
          |
    OPC-UA to MQTT        <-- Bridge/gateway layer
    Bridge (Gateway)
          |
      OPC-UA Server       <-- Built into B&R Automation Runtime
          |
      B&R X20CP1584       <-- PLC running the machine program
  • SNMP: Used for infrastructure-level monitoring (CPU temperature, battery status, network interface state, IP configuration). Read-only, poll-based. Does NOT access process variables.
  • OPC-UA: The native B&R protocol for structured access to PLC process variables. Requires variables to be explicitly enabled as tags.
  • MQTT: The IIoT distribution protocol. Lightweight, pub/sub, supports QoS levels, works over constrained networks. The CP1584 can run an MQTT client directly via the paho.mqtt.c-ar library.
  • Gateway/Bridge pattern: For machines where you cannot modify the PLC program, an edge gateway (small PC, Raspberry Pi, or Docker container) sits between the PLC’s OPC-UA server and the MQTT broker.

SNMP Monitoring on B&R Systems

B&R SNMP Architecture

B&R PLCs expose a PVI-SNMP agent that provides infrastructure-level data. This is NOT the same as an OPC-UA server – SNMP cannot read process variables. What it CAN read:

Data CategoryExamples
Device identificationModel name, serial number, MAC address, firmware version
Network configurationIP address, subnet mask, gateway, DNS, hostname
POWERLINK statusNode number, MN/CN role, INA settings
Runtime stateAR version, AR state, boot phase, process control state
Interface propertiesDevice name, baudrate, port numbers

Enabling SNMP Discovery

SNMP is active on B&R PLCs by default for PVI communication. The community string for PVI-SNMP is typically public (B&R-specific implementation, not standard SNMPv2c security).

Using brsnmp – Open-Source PVI-SNMP Tool

The brsnmp tool (https://github.com/hilch/brsnmp) is a free Windows utility that wraps PVI-SNMP commands for B&R PLCs. It does not require Automation Studio.

Installation: Requires PVI 4.x Development Setup. Download binary from the GitHub releases.

Basic discovery:

brsnmp --list

Returns JSON array of MAC addresses for all reachable B&R PLCs on the network.

Detailed inventory:

brsnmp --details

Returns JSON with full properties for each PLC:

{
  "targetTypeDescription": "X20CP1584",
  "serialNumber": "D45B0168612",
  "cfSerialNumber": "000060076643A1000085",
  "arVersion": "B04.45",
  "arVersionNorm": "04.45.2",
  "arState": "4",
  "arBootPhase": "40",
  "macAddress": "00-60-65-16-fd-da",
  "ipAddress": "192.168.0.14",
  "subnetMask": "255.255.255.0",
  "hostName": "br-automation",
  "deviceName": "IF2",
  "snmpMode": "2",
  "processCtrlState": "65535"
}

Filtering to a specific PLC:

brsnmp --filter=X20CP1584 --details
brsnmp --filter=macAddress.+00-60-65-3a-39-10 --details

Setting IP address remotely (CPU must be in BOOT or SERVICE state):

brsnmp --filter=macAddress.+00-60-65-3a-39-10 --ipAddress=192.168.1.50 --subnetMask=255.255.255.0

Critical warning: Always use --filter when writing parameters. Without a filter, brsnmp targets ALL reachable PLCs.

B&R ADI SNMP Agent

B&R also provides a formal ADI SNMP Agent (download: 1SWHMADS from br-automation.com) that runs on B&R PC-based panels and controllers (Automation Panel 800, Power Panel, etc.). This is separate from the PVI-SNMP agent used by brsnmp. The ADI SNMP Agent provides:

  • Temperature readings from B&R PC hardware
  • Device information and health status
  • Standard MIB-II support plus B&R enterprise MIB

The ADI SNMP Agent is designed for Windows-based B&R panels and may not run directly on the CP1584’s Automation Runtime. It is relevant if you have a B&R panel HMI alongside the CP1584.

SNMP for Infrastructure Monitoring (Non-B&R Specific)

Standard SNMP monitoring of the CP1584 Ethernet interface can be done with any SNMP manager (PRTG, Zabbix, Observium, LibreNMS) using standard MIB-II OIDs:

OIDDescription
1.3.6.1.2.1.1.1sysDescr (system description)
1.3.6.1.2.1.1.3sysUpTime (uptime)
1.3.6.1.2.1.2.1ifNumber (interface count)
1.3.6.1.2.1.2.2.1.1ifIndex
1.3.6.1.2.1.2.2.1.5ifSpeed
1.3.6.1.2.1.2.2.1.6ifPhysAddress (MAC)
1.3.6.1.2.1.2.2.1.8ifOperStatus (up/down)
1.3.6.1.2.1.2.2.1.10ifInOctets
1.3.6.1.2.1.2.2.1.16ifOutOctets

Step-by-Step: SNMP Infrastructure Setup

  1. Discover the PLC on the network using brsnmp:

    brsnmp --list
    brsnmp --filter=X20CP1584 --details > cp1584_inventory.json
    
  2. Record all discovered parameters (IP, MAC, AR version, serial number) for your asset database.

  3. Set up SNMP polling with Telegraf (see Section on Time-Series Pipeline) pointing at the PLC’s IP address using standard MIB-II OIDs.

  4. Add B&R-specific checks: Use brsnmp in a scheduled script (Windows Task Scheduler or cron on WSL) to poll arState and processCtrlState for runtime health.

  5. Set up alerting: When arState changes from normal (4 = RUN) to SERVICE (2) or ERROR, trigger an alert.


MQTT on the B&R CP1584 (On-PLC Approach)

paho.mqtt.c-ar: B&R Community MQTT Library

The B&R community maintains a port of the Eclipse Paho MQTT C client for Automation Runtime, available at: https://github.com/br-automation-community/paho.mqtt.c-ar

What it provides:

  • IotMqtt – Function Block (FUB) library for IEC programs. This is the recommended interface. Supports Publish, Subscribe, RegParPublish, RegParSubscribe.
  • PahoMQTT – Static C library for direct API access. Use only for special cases.

Runtime compatibility (built versions available):

  • A4.73, C4.63, D4.53, N4.34, M4.26, H3.10 (Intel and ARM)

Key characteristics:

  • Based on OpenSSL 1.1.1g and paho.mqtt.c 1.3.8 (rev.05)
  • Supports MQTT v3.1.1 and v5.0 (rev.05 added LastWillDelayInterval, SessionExpiryInterval, CleanStart)
  • Supports TLS/SSL with certificates
  • Supports WebSocket transport
  • Up to 50 Publish/Subscribe FUBs per client
  • Multiple simultaneous connections supported (MQTTAsync-based)
  • QoS 0, 1, and 2
  • Offline message buffering (publishes stored internally until connection established)
  • JSON serialization of PLC structures via IotMqttRegParPublish/Subscribe

Critical Limitation: Requires Automation Studio Project

The paho.mqtt.c-ar library must be compiled into the PLC program using Automation Studio. You cannot deploy it to a running PLC without source code. This means:

  • If you HAVE the Automation Studio project: Add IotMqtt to your program, configure broker connection, publish your variables.
  • If you DO NOT have the project: You CANNOT add MQTT to the PLC itself. Use the edge gateway approach (Section “OPC-UA to MQTT Bridge”) instead.

Code Examples

Minimal Publish (IEC ST)

PROGRAM _CYCLIC
    IotMqttParameters.ServerUri     := 'broker.hivemq.com';
    IotMqttParameters.Port          := 1883;
    IotMqttParameters.ClientID      := 'BR_CP1584_Machine01';

    IotMqttClient_0.Enable          := TRUE;
    IotMqttClient_0.Connect         := TRUE;
    IotMqttClient_0.IotMqttLink     := ADR(IotMqttLink);
    IotMqttClient_0.Parameters      := IotMqttParameters;
    IotMqttClient_0();

    PublishMessage                  := 'Machine01: running';
    IotMqttPublish_0.Enable         := TRUE;
    IotMqttPublish_0.IotMqttLink    := IotMqttClient_0.IotMqttLink;
    IotMqttPublish_0.Topic          := ADR('factory/line1/machine01/status');
    IotMqttPublish_0.Buffer         := ADR(PublishMessage);
    IotMqttPublish_0.BufferLength   := brsstrlen(ADR(PublishMessage));
    IotMqttPublish_0();
END_PROGRAM

JSON Structure Publishing (RegParPublish)

The IotMqttRegParPublish FUB serializes an entire PLC structure to JSON and publishes it on a configurable trigger (on change, on interval, or on trigger event):

PROGRAM _CYCLIC
    IotMqttParameters.ServerUri             := '192.168.1.100';
    IotMqttParameters.Port                  := 1883;
    IotMqttParameters.ClientID              := 'BR_CP1584_Machine01';

    IotMqttClient_0.Enable                  := TRUE;
    IotMqttClient_0.Connect                 := TRUE;
    IotMqttClient_0.IotMqttLink             := ADR(IotMqttLink);
    IotMqttClient_0.Parameters              := IotMqttParameters;
    IotMqttClient_0();

    IotMqttRegParPublish_0.Enable           := TRUE;
    IotMqttRegParPublish_0.IotMqttLink      := IotMqttClient_0.IotMqttLink;
    IotMqttRegParPublish_0.Topic            := ADR('factory/line1/machine01/telemetry');
    IotMqttRegParPublish_0.PvName           := ADR('MachineData');
    IotMqttRegParPublish_0.PublishMode      := IOTMQTT_PUB_MODE_TRIGGER;
    IotMqttRegParPublish_0.DataFormat       := IOTMQTT_VAR_JSON;
    IotMqttRegParPublish_0();
END_PROGRAM

Publish modes available:

  • IOTMQTT_PUB_MODE_TRIGGER – publish on trigger event
  • IOTMQTT_PUB_MODE_TIME – publish on time interval
  • IOTMQTT_PUB_MODE_CHANGED – publish on value change
  • Combinations supported (e.g., time OR changed)

Subscribe Example

PROGRAM _CYCLIC
    IotMqttSubscribe_0.Enable           := TRUE;
    IotMqttSubscribe_0.IotMqttLink      := IotMqttClient_0.IotMqttLink;
    IotMqttSubscribe_0.Topic            := ADR('factory/line1/machine01/commands');
    IotMqttSubscribe_0.QueueSize        := 50;
    IotMqttSubscribe_0.Buffer           := ADR(ReceiveBuffer);
    IotMqttSubscribe_0.BufferSize       := SIZEOF(ReceiveBuffer);
    IotMqttSubscribe_0();
END_PROGRAM

DNS and Network Configuration for MQTT

The CP1584 needs DNS configured to reach external MQTT brokers (e.g., AWS IoT, HiveMQ Cloud):

  1. In Automation Studio, open CPU Configuration
  2. Navigate to the Ethernet interface (IF2)
  3. Enable DNS service
  4. If using DHCP: check “Get DNS from DHCP server”
  5. If using static IP: manually enter DNS server addresses (e.g., 8.8.8.8, 8.8.4.4)
  6. Set the default gateway if the broker is outside the local network

MQTT File Device and Logging Configuration

IotMqtt generates log files to the IOTMQTT file device by default. Create this in CPU configuration:

  1. In Automation Studio, CPU Configuration, add a File Device named IOTMQTT
  2. Point it to a directory on the CF card or a mounted USB stick
  3. Configure logging in _INIT:
PROGRAM _INIT
    IotMqttConfigParams.UseLogger             := TRUE;
    IotMqttConfigParams.LoggerName            := 'IotMqtt';
    IotMqttConfigParams.UseFile               := TRUE;
    IotMqttConfigParams.LogFileDevice         := 'USER';
    IotMqttConfigParams.LogFileName           := 'IotMqttLog';
    IotMqttConfigParams.OverwritteLogs        := TRUE;
    IotMqttConfigParams.LogLevel              := IOTMQTT_LOG_LEVEL_PROTOCOL;
    IotMqttConfig(ADR(IotMqttConfigParams));
END_PROGRAM

Certificates for TLS Connections

MQTT over TLS (port 8883) requires certificates. On B&R AR, certificates can be stored in:

  • Certificate store (project-level, accessed with container prefix like TaskName: or CertStore:)
  • File system (accessed with file device prefix like USER: or default device = no prefix)

For AWS IoT, Azure IoT Hub, or Google IoT Cloud connections, sample projects are provided in the paho.mqtt.c-ar repository under the Samples directory.


OPC-UA to MQTT Bridge (Edge Gateway Approach)

When to Use This Approach

Use the edge gateway when:

  • You do NOT have the Automation Studio project (cannot modify PLC program)
  • The OPC-UA server is running with variables already exposed
  • You want to keep data pipeline traffic off the PLC
  • You need protocol translation (OPC-UA to MQTT) without touching the control system

Architecture

   [Grafana Dashboard]
          |
   [InfluxDB / TimescaleDB]
          |
   [Telegraf]
          |
   [MQTT Broker (Mosquitto)]
          |
   [OPC-UA to MQTT Gateway]    <-- Small PC or Raspberry Pi
          |
   [OPC-UA Server on CP1584]   <-- Built into Automation Runtime

Option 1: Frankenstein Automation Gateway (Open Source)

The Frankenstein Gateway (https://github.com/vogler75/automation-gateway) is a Java-based open-source OPC-UA to MQTT bridge. Key features:

  • Connects as an OPC-UA client to any OPC-UA server
  • Exposes values via MQTT publish and GraphQL (HTTP)
  • Supports subscription-based data change notifications
  • Includes a data logger that publishes statistics
  • Maps OPC-UA node IDs to MQTT topics
  • No cost, community-maintained

Setup steps:

  1. Install Java 11+ on the edge PC
  2. Download the latest release from GitHub
  3. Configure application.properties:
    opcua.server.url=opc.tcp://192.168.0.14:4840
    opcua.namespace.index=3
    mqtt.broker.url=tcp://localhost:1883
    mqtt.topic.prefix=factory/line1/machine01
    
  4. Run the gateway: java -jar frankenstein-gateway.jar

Verification: Subscribe to the MQTT topic to confirm data flow:

mosquitto_sub -h localhost -t 'factory/line1/machine01/#' -v

Option 2: EMQX Neuron (Open Source, Docker)

Neuron (https://github.com/emqx/neuron) is an industrial IoT connectivity server from EMQX that supports 100+ industrial protocols including OPC-UA. It runs in Docker and is designed for edge deployment.

Key features:

  • OPC-UA client (southbound) to MQTT publish (northbound)
  • Supports subscription to OPC-UA monitored items (report-by-exception)
  • Group configuration for organizing tags
  • Data processing (scale, offset, JSON formatting)
  • Web UI for configuration
  • Docker container: docker pull emqx/neuron

Docker Compose for Neuron + Mosquitto:

version: '3.8'
services:
  neuron:
    image: emqx/neuron:latest
    ports:
      - "9000:9000"   # Neuron web UI
    volumes:
      - neuron_data:/neuron/data
    restart: unless-stopped

  mosquitto:
    image: eclipse-mosquitto:2
    ports:
      - "1883:1883"
      - "9001:9001"   # WebSocket
    volumes:
      - mosquitto_data:/mosquitto/data
      - mosquitto_config:/mosquitto/config
    restart: unless-stopped

volumes:
  neuron_data:
  mosquitto_data:
  mosquitto_config:

Configuration steps:

  1. Access Neuron web UI at http://<edge-pc>:9000
  2. Add a southbound device with protocol “OPC-UA Client”
  3. Set endpoint URL: opc.tcp://<CP1584-IP>:4840
  4. Configure security: None for initial testing, certificate-based for production
  5. Browse the OPC-UA address space to discover available nodes
  6. Create a group of tags to subscribe to
  7. Add a northbound application with protocol “MQTT”
  8. Set MQTT broker URL: tcp://mosquitto:1883
  9. Map the group to the MQTT application with topic template
  10. Start the pipeline

Option 3: Custom Python Bridge

For maximum control, write a lightweight Python script using asyncua (async OPC-UA client) and paho-mqtt:

import asyncio
import json
import paho.mqtt.client as mqtt
from asyncua import Client

OPCUA_URL = "opc.tcp://192.168.0.14:4840"
MQTT_BROKER = "localhost"
MQTT_PORT = 1883
TOPIC_PREFIX = "factory/line1/machine01"
SUBSCRIBE_NODES = [
    "ns=3;s=MachineData.Temperature",
    "ns=3;s=MachineData.Pressure",
    "ns=3;s=MachineData.RPM",
    "ns=3;s=MachineData.Status",
]

mqtt_client = mqtt.Client()
mqtt_client.connect(MQTT_BROKER, MQTT_PORT)

async def main():
    async with Client(OPCUA_URL) as client:
        nodes = []
        for node_path in SUBSCRIBE_NODES:
            node = client.get_node(node_path)
            nodes.append(node)

        sub = await client.create_subscription(500)
        handlers = DataChangeHandler(mqtt_client, TOPIC_PREFIX)
        for node in nodes:
            await sub.subscribe_data_change(node, handlers)

        while True:
            await asyncio.sleep(1)

class DataChangeHandler:
    def __init__(self, mqtt_client, prefix):
        self.mqtt_client = mqtt_client
        self.prefix = prefix

    def datachange_notification(self, node, val, data):
        topic = f"{self.prefix}/{node.nodeid.Identifier}"
        payload = json.dumps({
            "value": val,
            "timestamp": data.source_timestamp.isoformat() if data.source_timestamp else None,
            "quality": "good" if not data.status.is_bad() else "bad",
        })
        self.mqtt_client.publish(topic, payload, qos=1)

asyncio.run(main())

Option Comparison

FeatureFrankensteinEMQX NeuronCustom Python
Setup effortMediumLow (Docker)High (code)
OPC-UA versionClientClientClient
MQTT publishYesYesYes
Data processingLimitedScale/offset/JSONUnlimited
Web UINoYesNo
Docker supportNoYesYes
MaintenanceCommunityActive (EMQX)Your responsibility
CostFreeFreeFree
Best forQuick POCProduction edgeCustom logic

Time-Series Data Logging

Strategy 1: Log on the PLC (CF Card / USB)

If you have the Automation Studio project, the most reliable approach is to log data directly on the PLC using the built-in Logger function or custom C code. See custom-diagnostic-tools.md for details on building on-PLC tools.

B&R Logger configuration:

  1. In Automation Studio, open the Logger configuration
  2. Create a new data log
  3. Select variables to log (must be in scope)
  4. Configure trigger: cyclic (every N ms) or event-based
  5. Configure storage: file device path on CF card
  6. Set maximum file size and rotation policy

File device setup for logging:

  • Use the USER file device pointing to a directory on the CF card
  • Mount a USB stick as a separate file device for log export
  • Implement log rotation to prevent CF card exhaustion

CF card write considerations:

  • Use SLC (Single-Level Cell) CF cards only (B&R part numbers 5CFCRD.xxxx-06)
  • Avoid frequent small writes – buffer data and flush periodically
  • Rotate files before they exceed 50 MB to keep FAT defragmentation manageable
  • Monitor CF card health via the PLC’s CF LED and software status register

Strategy 2: Log via OPC-UA Subscription (External)

When you cannot modify the PLC program but the OPC-UA server has tags enabled:

  1. Run an OPC-UA client on an edge PC (Python asyncua, or a dedicated logger)
  2. Subscribe to monitored items with a 1000 ms sampling interval
  3. Write values to a local InfluxDB or CSV files
  4. The CP1584 handles the subscription without additional CPU load (OPC-UA server handles sampling internally)

InfluxDB line protocol output:

machine01,location=line1 temperature=72.3,pressure=14.7,rpm=1200,status=1 1718035200000000000

Strategy 3: Log via MQTT (External Subscriber)

When data flows through the MQTT broker (via on-PLC MQTT client or OPC-UA bridge):

  1. Run Telegraf with the MQTT consumer input plugin
  2. Parse JSON payloads from MQTT topics
  3. Write to InfluxDB

Telegraf configuration:

[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = [
    "factory/line1/machine01/telemetry",
  ]
  data_format = "json"
  json_string_fields = []
  tags = {source = "cp1584", machine = "machine01"}

[[outputs.influxdb_v2]]
  urls = ["http://localhost:8086"]
  token = "your-token"
  organization = "factory"
  bucket = "machine_data"

Building Monitoring Dashboards

This is the standard open-source IIoT monitoring stack:

[B&R CP1584]
     |
     | OPC-UA or MQTT
     |
[Edge Gateway / Telegraf]
     |
[Mosquitto MQTT Broker]
     |
[Telegraf --> InfluxDB --> Grafana]

Step-by-Step: Full Stack Setup on an Edge PC

1. Install Mosquitto MQTT Broker

sudo apt install mosquitto mosquitto-clients
sudo systemctl enable mosquitto
sudo systemctl start mosquitto

Test with:

mosquitto_sub -h localhost -t 'test/#' -v
mosquitto_pub -h localhost -t 'test/hello' -m 'world'

2. Install InfluxDB

sudo apt install influxdb2
sudo systemctl enable influxdb
sudo systemctl start influxdb

Create organization and bucket:

influx setup \
  --username admin \
  --password adminpassword \
  --org factory \
  --bucket machine_data \
  --retention 30d

3. Install Telegraf

sudo apt install telegraf

Configure Telegraf with both MQTT and SNMP inputs:

[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = ["factory/#"]
  data_format = "json"
  name_override = "plc_data"

[[inputs.snmp]]
  agents = ["udp://192.168.0.14"]
  version = 2
  community = "public"
  interval = "60s"
  [[inputs.snmp.field]]
    name = "uptime"
    oid = "1.3.6.1.2.1.1.3.0"
  [[inputs.snmp.field]]
    name = "ifOperStatus"
    oid = "1.3.6.1.2.1.2.2.1.8.1"

[[outputs.influxdb_v2]]
  urls = ["http://localhost:8086"]
  token = "your-api-token"
  organization = "factory"
  bucket = "machine_data"

4. Install Grafana

sudo apt install -y apt-transport-https
sudo apt install grafana
sudo systemctl enable grafana-server
sudo systemctl start grafana-server

Access at http://<edge-pc>:3000 (default admin/admin).

5. Configure Grafana Data Source

  1. Add InfluxDB as a data source
  2. URL: http://localhost:8086
  3. Auth: Token-based
  4. Organization: factory
  5. Bucket: machine_data

Dashboard Panels for Undocumented Machines

For machines with no documentation, build dashboards around these themes:

Infrastructure Health Panel

MetricSourceVisualization
PLC uptimeSNMP sysUpTimeStat panel
Ethernet link statusSNMP ifOperStatusStatus indicator (green/red)
Network trafficSNMP ifInOctets/ifOutOctetsGraph (bytes/sec)
AR statebrsnmp arStateStat panel with conditional colors
Battery statusPLC BatteryInfo functionStatus indicator

Process Telemetry Panel

MetricSourceVisualization
Key temperaturesOPC-UA / MQTTTime series graph
PressuresOPC-UA / MQTTTime series graph
Speeds / RPMsOPC-UA / MQTTGauge + time series
Machine stateOPC-UA / MQTTStatus panel (Running/Idle/Fault)
Cycle countsOPC-UA / MQTTCounter (totalize)

Alert Rules

Alert ConditionSeverityAction
PLC goes to SERVICE modeCriticalEmail/page on-call
Ethernet link downCriticalEmail + dashboard red panel
Temperature exceeds thresholdWarningDashboard amber + email
OPC-UA connection lostWarningDashboard indicator + log
MQTT broker unreachableWarningDashboard indicator

Practical Retrofit Procedures

Procedure 1: Zero-Documentation Discovery (Start Here)

When you inherit a B&R CP1584 machine with no documentation:

  1. Physical inspection: Read the model number, serial number, AR version from the CPU label
  2. Network discovery: Run brsnmp on a PC on the same subnet:
    brsnmp --list
    brsnmp --details > machine_inventory.json
    
  3. OPC-UA probe: Install UaExpert (free from Unified Automation). Try connecting to opc.tcp://<PLC-IP>:4840 with no security and anonymous login
  4. SDM check: Open a browser to http://<PLC-IP> – the System Diagnostics Manager web interface may be running
  5. Network scan: Use nmap to identify open ports on the PLC:
    nmap -sV -p 1-65535 <PLC-IP>
    
    Key ports to look for: 4840 (OPC-UA), 11159 (INA/ANSI), 80 (HTTP/SDM), 21 (FTP), 161 (SNMP)
  6. CF card dump: See cf-card-boot.md for safely reading the CF card contents to discover the project structure

Procedure 2: Add OPC-UA Data Export (Server Already Running)

If the OPC-UA server is already running with some tags enabled:

  1. Connect with UaExpert and browse the full namespace tree
  2. Document all exposed variables: node IDs, data types, current values
  3. Export the node list from UaExpert (File > Export Address Space)
  4. Set up an OPC-UA subscription in your data pipeline (Python asyncua, Telegraf OPC-UA input, or Neuron)
  5. Validate data types and ranges before connecting to your time-series database

Procedure 3: Full MQTT Pipeline (Have Automation Studio Project)

  1. Add IotMqtt library to the Automation Studio project
  2. Configure broker parameters in a persistent variable structure
  3. Create publish FUBs for each data group (telemetry, alarms, status)
  4. Use RegParPublish for structured data – it serializes entire PLC structures to JSON
  5. Configure QoS 1 for critical data (alarms), QoS 0 for telemetry
  6. Set up offline buffering so messages are stored if broker is unreachable
  7. Build and transfer to the PLC
  8. Set up the broker (Mosquitto or EMQX) on an edge PC
  9. Validate with mosquitto_sub before connecting Telegraf/InfluxDB

Procedure 4: Full MQTT Pipeline (No Automation Studio Project)

  1. Verify OPC-UA server is running and has tags enabled (use UaExpert)
  2. Set up edge gateway (Neuron recommended for easiest setup)
  3. Configure OPC-UA connection from gateway to PLC
  4. Browse and select variables in Neuron web UI
  5. Configure MQTT output to local Mosquitto broker
  6. Add Telegraf to consume MQTT and write to InfluxDB
  7. Build Grafana dashboards

Procedure 5: Add a Dedicated Monitoring Network Interface

The CP1584 already has IF2 (Ethernet 10/100/1000) and IF3 (POWERLINK V1/V2). If IF2 is already used for PLC control and you need a dedicated IT monitoring interface, you can add a third NIC:

  1. Purchase an X20 Ethernet interface module (e.g., X20IF1061-1)
  2. Install in the CP1584’s single expansion slot
  3. Configure in Automation Studio under Physical View
  4. Assign the third interface to a different subnet
  5. Configure the MQTT broker connection to use the third interface
  6. This requires a project rebuild – not possible without Automation Studio source

Alternative: If IF2 is free, simply configure it for monitoring traffic and use IF3 (POWERLINK) for PLC control, or use an external managed switch with VLANs on IF2 to segment OT and IT traffic.


Topic Naming Convention

Use ISA-95 / UNS (Unified Namespace) conventions for MQTT topics:

enterprise/site/area/line/cell/equipment/measurement

Example for a B&R CP1584-controlled machine:

factory/line1/cnc01/telemetry/temperature
factory/line1/cnc01/telemetry/pressure
factory/line1/cnc01/telemetry/rpm
factory/line1/cnc01/status/mode
factory/line1/cnc01/status/faults
factory/line1/cnc01/alarms/#
factory/line1/cnc01/config/#

Sparkplug B (MQTT) adds structure to payloads with timestamps, quality, and sequence numbers. If using EMQX or HiveMQ, consider Sparkplug B as the payload format for interoperability with MES/SCADA systems.


Security Considerations

Network Segmentation

  • Never expose OPC-UA (port 4840) or MQTT (port 1883) directly to the internet
  • Use a firewall between OT (PLC network) and IT (monitoring network)
  • The edge gateway should be dual-homed: one NIC on OT network, one on IT network
  • Or use a VPN for remote access to the monitoring stack

OPC-UA Security

  • Default: No security, anonymous access. This is common for internal OT networks but unacceptable for IT crossover
  • Enable X.509 certificate-based security for production deployments
  • The CP1584 generates self-signed certificates; see opcua.md for certificate management including the ArMcsRecreateCert function block

MQTT Security

  • Use TLS (MQTT over port 8883) for any data crossing network boundaries
  • Configure username/password authentication on Mosquitto
  • Use ACLs to restrict which topics each client can publish/subscribe to
  • For cloud connections (AWS IoT, Azure), use mutual TLS (client certificates)

SNMP Security

  • B&R PVI-SNMP uses a proprietary mechanism, not standard SNMPv3 security
  • Standard SNMP to the CP1584 Ethernet interface (MIB-II) uses community string “public” by default
  • Restrict SNMP access with firewall rules if the PLC is on a shared network
  • Never expose SNMP to untrusted networks

Troubleshooting

OPC-UA Server Not Reachable

SymptomCauseFix
Connection refused on port 4840OPC-UA server not activatedServer requires activation in AR configuration. Without project, check if the running firmware has it enabled
Certificate errorExpired or self-signed certUse ArMcsRecreateCert function block or accept self-signed in client settings
No variables visibleTags not enabledVariables must be explicitly enabled as OPC-UA tags. Without project, you cannot add new ones
Connection timeoutFirewall blockingOpen port 4840 on intermediate switches/firewalls

MQTT Connection Issues on PLC

SymptomCauseFix
Cannot resolve broker hostnameDNS not configuredEnable DNS service in AR configuration with valid DNS server
Connection drops frequentlyNetwork quality or broker overloadCheck cabling; reduce publish rate; use QoS 1 with offline buffering
Messages not arrivingWrong topic or QoS mismatchVerify topic strings match between publish and subscribe; check broker logs
Library won’t compileAR version mismatchUse IotMqtt version matching your AR version (see compatibility table)
Certificate error on TLSMissing or wrong certificateCheck certificate path prefix (task:, certstore:, or file device name:)

SNMP Discovery Issues

SymptomCauseFix
brsnmp finds no PLCsWrong subnet or PVI not installedEnsure PC is on same broadcast domain; install PVI 4.x
Can list but not set parametersPLC in wrong statePLC must be in BOOT or SERVICE state to accept IP changes via SNMP
Filter matches nothingRegex syntax errorTest regex on https://regex101.com with ECMA syntax

Key Findings

  1. Three viable retrofit paths exist for the CP1584: (a) on-PLC MQTT via paho.mqtt.c-ar (requires Automation Studio project), (b) OPC-UA to MQTT bridge via edge gateway (works without project), (c) SNMP polling for infrastructure health only.

  2. The OPC-UA to MQTT bridge is the most practical approach for undocumented machines. It does not require the Automation Studio project, does not add load to the PLC, and works with the OPC-UA server already built into Automation Runtime. The open-source Neuron gateway (Docker) provides the lowest-friction deployment.

  3. paho.mqtt.c-ar is mature and well-documented but fundamentally requires source code access. It supports MQTT v5.0, TLS, WebSocket transport, offline buffering, and JSON serialization of PLC structures. The library is built for AR versions from H3.10 through A4.73.

  4. SNMP on B&R PLCs is PVI-SNMP, not standard SNMPv3. The brsnmp open-source tool provides the most practical access. Standard MIB-II OIDs work for the Ethernet interface but B&R-specific data (AR state, firmware version, serial number) requires the PVI-SNMP mechanism.

  5. The CP1584 already has two built-in network interfaces (IF2 = Ethernet, IF3 = POWERLINK), so network segmentation for OT/IT separation is possible without any expansion module. However, if you need a third interface (e.g., a dedicated IT monitoring NIC), the X20IF1061-1 can fill the single expansion slot. An external switch with VLANs is a simpler alternative. See network-architecture.md for details on the built-in interfaces.

  6. OPC-UA variable exposure is the critical gating factor. Even with a perfect MQTT pipeline, if the OEM did not enable OPC-UA tags, you have zero process data. This is the first thing to check when inheriting an undocumented B&R machine. See opcua.md for the full discovery procedure.

  7. The Grafana + InfluxDB + Telegraf + Mosquitto stack is the de facto standard for IIoT monitoring dashboards. All components are open-source, well-supported, and run on modest hardware (a Raspberry Pi 4 or any small PC is sufficient).

  8. Security at the OT/IT boundary is non-negotiable. The edge gateway pattern naturally provides a security boundary point. Implement TLS on MQTT, certificate-based security on OPC-UA, and firewall rules to restrict access to the PLC’s Ethernet interface.

  9. CF card longevity must be managed. When logging on the PLC, use SLC cards only, implement log rotation, buffer writes, and monitor card health. Industrial CF cards from B&R (5CFCRD series) are rated for extended temperature and higher write cycles.

  10. The Frankenstein Automation Gateway and EMQX Neuron are the two best open-source OPC-UA to MQTT bridges. Frankenstein is Java-based and simpler for small deployments. Neuron runs in Docker, has a web UI, and is better suited for production edge deployments. Both are free and actively maintained.

  11. brwatch provides an alternative no-code discovery and monitoring tool for initial IIoT assessment. Before building any pipeline, use brwatch (github.com/hilch/brwatch) to enumerate all visible variables, log their values to CSV, and validate that the OPC-UA server is actually exposing process data. This 5-minute assessment determines whether the bridge approach is even viable. See access-recovery.md §12 and python-diagnostics.md §Community Tools.

  12. The awesome-B-R repository (github.com/br-automation-community/awesome-B-R) catalogs all community tools for B&R PLCs. Key tools for IIoT retrofits: paho.mqtt.c-ar (on-PLC MQTT), brsnmp (SNMP discovery), demo-br-asyncua (OPC-UA examples), and as6-migration-tools (for AR 6.x migration planning).

  13. OMJSON (github.com/loupeteam/OMJSON) provides WebSocket + JSON communication from the PLC — an alternative to MQTT/OPC-UA for lightweight data exchange when you need a simple JSON-based API from the PLC to a web server or custom application.

  14. OMSQL (github.com/loupeteam/OMSQL) provides SQL database communication from the PLC — useful for writing diagnostic data, alarm histories, or production records directly to MySQL/PostgreSQL databases from the PLC without an external gateway.

  15. mappRemoteShell (github.com/br-automation-community/mappRemoteShell) demonstrates bidirectional OPC-UA communication for remote diagnostics — the PLC sends commands via OPC-UA that trigger shell scripts on a remote PC, enabling complex diagnostic sequences orchestrated from the PLC.


Document updated: July 2026 (added OMJSON, OMSQL, mappRemoteShell community tools)