eBPF-Based Telemetry for B&R (ABB) PLCs: Comprehensive Technical Analysis

Modern Linux-based B&R controllers (BX/BP series, X20 with embedded Linux) offer opportunities for deep runtime telemetry that were impossible on older VxWorks-based systems. This document explores using eBPF, strace, perf, and SystemTap to capture function calls, message data, and performance metrics from the B&R Automation Runtime — both live on a running controller and from captured dump files for post-mortem analysis of control program bugs. Where eBPF is not available, alternative approaches including ptrace-based tracing and LD_PRELOAD hooking are covered. Cross-references: ar-rtos.md for AR runtime internals, custom-diagnostic-tools.md for building diagnostic tools that run on the PLC, and python-diagnostics.md for external diagnostic scripting.

Table of Contents

1. Executive Summary
2. B&R Automation Runtime: OS Architecture
3. eBPF Feasibility on B&R Controllers
4. Alternative Tracing Approaches
5. Capturing Function Calls from B&R Runtime
6. Message Data Interception: POWERLINK/X2X/CAN
7. Task Scheduling, Cycle Times, and Context Switch Monitoring
8. Memory Access Monitoring: IO Reads/Writes
9. B&R’s Built-in Tracing and Profiling Hooks
10. Automation Studio Profiler
11. Custom Telemetry Collectors Using B&R’s C/C++ SDK
12. Live Monitoring vs. Dump-File Analysis
13. Using perf to Profile B&R Tasks on VxWorks-Based Controllers
14. Practical Limitations
15. SDM and OPC-UA as Alternative Telemetry Paths
16. SNMP Monitoring of B&R Hardware Health Metrics
17. Recommended Telemetry Architecture

1. Executive Summary

eBPF cannot be used natively on B&R PLCs. Automation Runtime (AR) is based on VxWorks, not Linux. VxWorks does not implement eBPF. This fundamental OS-level constraint means all Linux-native tracing tools (eBPF/bpftrace, perf, SystemTap, strace, ftrace, LD_PRELOAD) are unavailable on standard B&R controllers.

However, B&R provides a rich set of built-in diagnostics tools, and several viable telemetry paths exist:

2. B&R Automation Runtime: OS Architecture

2.1 Core OS: VxWorks-Based

B&R Automation Runtime (AR) is definitely based on VxWorks. This was confirmed by B&R engineering staff on the official community forum:

“Automation Runtime is definitely based on VxWorks. For sure, B&R developed a lot of additional functions, task class scheduling, drivers and abstraction layers needed for PLCs (that’s the reason why it’s called by its own name AutomationRuntime), but the base is still VxWorks until now.” — Alexander Hefner, B&R Community (May 2024) Source: https://community.br-automation.com/t/the-os-behind-ar/3303

Key implications of this architecture:

• Not Linux: Standard Linux tracing tooling (eBPF, perf, SystemTap, strace, LD_PRELOAD) does not apply to the real-time execution environment.
• RTOS with deterministic scheduling: VxWorks provides hard real-time guarantees with priority-based preemptive scheduling. B&R adds custom task class scheduling on top of this.
• Closed/proprietary: The runtime is a proprietary binary distribution. Source code and kernel headers are not available.

2.2 Dual-OS Systems: The Hypervisor

On B&R Automation PCs (APC series), a bare-metal hypervisor runs alongside a General Purpose OS (GPOS):

• Automation Runtime runs as the real-time partition (VxWorks-based)
• Windows IoT Enterprise LTSC or “B&R for Linux” (based on Ubuntu/Debian) runs as the standard partition
• Data exchange occurs via shared memory between partitions

This means on dual-OS APCs, eBPF is technically possible on the Linux side — but only for monitoring the Linux GPOS partition, not the real-time Automation Runtime partition.

Sources:

• https://www.br-automation.com/en-us/products/software/operating-systems/
• https://www.real-time-systems.com/fileadmin/benutzerdaten/real-time-systems/pdf/BnR_TR_17209_Hypervisor_EN.pdf
• https://www.br-automation.com/en/about-us/customer-magazine/2018/20189/two-operating-systems-on-one-device/

2.3 ARsim: Windows Simulation

ARsim (Automation Runtime Simulation) runs on the Windows development machine. It simulates the AR runtime but is not identical to the target execution. It is useful for debugging but does not expose VxWorks-level internals.

2.4 Controller Categories

3. eBPF Feasibility on B&R Controllers

3.1 On Native AR (VxWorks-Based Controllers)

eBPF is not available. VxWorks does not implement the BPF virtual machine, BPF syscall interface, or any of the kernel infrastructure required for eBPF. This applies to all standard B&R controllers (X20, X67, Power Panel, etc.).

VxWorks has its own instrumentation framework (Wind River Workbench diagnostics, System Viewer), but these are proprietary and not accessible from user code without Wind River development tools.

3.2 On B&R for Linux (GPOS Partition of APC)

On dual-OS Automation PCs running “B&R for Linux”:

• The Linux partition runs a standard Linux kernel (Ubuntu-based)
• eBPF tools (bpftrace, bcc tools, bpftool) can theoretically be installed
• However, you can only monitor the Linux GPOS partition, not the real-time Automation Runtime
• The RTOS partition is isolated by the hypervisor; shared memory is the only communication channel

3.3 What eBPF Could Monitor on the Linux Side

If you deploy eBPF on the Linux partition of an APC:

Source: https://github.com/SASE-Space/ot-openness-comparison/blob/main/README.md

4. Alternative Tracing Approaches

4.1 strace — System Call Tracing

Status: Not applicable to native AR.

strace relies on the Linux ptrace system call mechanism to intercept and record system calls made by a process. VxWorks has no equivalent mechanism accessible to user programs. The VxWorks kernel shell provides taskShow() and similar commands, but these are not equivalent to strace.

On the Linux GPOS partition of APCs, strace works normally for Linux-side processes.

4.2 perf — Performance Profiler

Status: Not applicable to native AR.

perf uses Linux kernel performance counters (perf_events subsystem) and hardware performance monitoring units (PMUs). These do not exist in the VxWorks kernel.

On the Linux GPOS partition, perf works for Linux processes. See Section 13 for details on VxWorks-specific profiling.

4.3 SystemTap — Dynamic Instrumentation

Status: Not applicable to native AR.

SystemTap requires Linux kernel headers, a compiled kernel module infrastructure, and the Linux kernel’s kprobes/jprobes mechanism. None of these exist in VxWorks.

4.4 LD_PRELOAD Hooking

Status: Not applicable to native AR.

LD_PRELOAD is a Linux dynamic linker feature that allows pre-loading shared libraries to intercept function calls. VxWorks uses its own module loading system (the Object Module Loader, or OML), which does not support this mechanism.

On the Linux GPOS partition, LD_PRELOAD works for Linux processes — but this still only monitors the GPOS side.

4.5 VxWorks-Specific Alternatives

VxWorks provides its own set of diagnostic tools:

Source: https://www.windriver.com/blog/tracealyzer-for-vxworks-overview-and-getting-started-guide

5. Capturing Function Calls from B&R Runtime

5.1 The Runtime is Proprietary and Opaque

B&R’s runtime executables (BX/BP binaries compiled from Automation Studio) are proprietary compiled modules loaded by the AR kernel. There is no standard mechanism to:

• Hook into runtime function calls
• Set breakpoints in runtime internals
• Intercept function entry/exit without debug tools
• Dynamically instrument running code

5.2 What CAN Be Observed at the Application Level

Within your own IEC/ST/C programs running on the PLC, you can instrument code using:

1. RTInfo Function Block (BRSystem library): Provides cycle time, task index, and timing information for the current task context. Call RTInfo from within your program to get runtime statistics.

   Source: https://community.br-automation.com/t/cycle-time-in-fb/4372

2. AsBrStr library: String and logging functions for structured diagnostic output.

3. mapp View Trace: If using HMI components, mapp View provides tracing of user interactions and data flow.

4. User-defined logging: Write diagnostic data to data modules (persistent storage) or send via OPC UA/UDP to external collectors.

5.3 Automation Studio Debugger

Automation Studio provides a source-level debugger (C debugger and IEC debugger):

• Breakpoints, single-step, line coverage
• Watch windows for variable monitoring
• Disassemble view for compiled code
• Works online (connected to target) and in ARsim

This requires an active Automation Studio connection to the PLC and is primarily a development tool, not a production telemetry mechanism.

6. Message Data Interception: POWERLINK/X2X/CAN

6.1 POWERLINK

POWERLINK is B&R’s primary industrial Ethernet protocol, implemented as an open-source protocol stack (openPOWERLINK). It runs on standard Ethernet hardware.

At the software level on the PLC:

• POWERLINK communication is handled by AR kernel drivers
• User code does not directly access POWERLINK frames
• Data is exchanged through the process image (IO mapping)

Capturing POWERLINK traffic:

Sources:

• https://www.br-automation.com/en/technologies/powerlink/faq/
• https://github.com/OpenAutomationTechnologies/openPOWERLINK_V2
• http://www.ftp.boss-bravo.fr/wiki/pdf/TM_BR/TM950TRE.40-ENG_POWERLINK%20Configuration%20and%20Diagnostics_V4000.pdf

6.2 X2X Link

X2X is B&R’s proprietary point-to-point connection protocol for I/O nodes (typically within a single station/bus controller).

Capturing X2X data:

• X2X is a proprietary, non-Ethernet protocol
• No packet capture mechanism exists
• Diagnostics available through SDM: node status, error counters, cycle synchronization
• I/O data visible through the process image (map to PLC variables)

6.3 CAN Bus

B&R controllers support CAN interfaces. CAN diagnostics are available through:

6.4 Network Command Trace (NCT)

The Network Command Trace is a diagnostic tool built into AR that logs fieldbus communication events:

• Captures POWERLINK, CAN, and other bus commands
• Records timing, errors, and data transfer events
• Can be included in system dumps
• Enabled via Automation Studio diagnostic configuration
• Useful for post-mortem analysis of communication failures

Source: https://www.youtube.com/watch?v=aGNr5DICm8M (B&R “Troubleshoot Hardware Using Network Command Trace”)

7. Task Scheduling, Cycle Times, and Context Switch Monitoring

7.1 B&R Task Class Architecture

B&R AR uses task classes (TC#1 through TC#8+), each with a configurable cycle time:

Higher-priority task classes can preempt lower ones. A cycle time violation occurs when a lower-priority task takes too long and prevents a higher-priority task from completing within its cycle.

7.2 Monitoring Task Scheduling

Built-in mechanisms:

1. Automation Studio Profiler (see Section 10): The primary tool for monitoring task execution, preemptions, cycle time consumption, and CPU load per task class.

2. RTInfo Function Block (BRSystem library): Returns the current task’s cycle time and runtime information. Sample from within any cyclic program.

   (* Example: Monitor cycle time in ST *)
   rtInfo_0(enable := TRUE);
   currentCycleTime := rtInfo_0.cycleTime;
   

3. Logger (Automation Studio): Captures cycle time violation events, errors, and warnings. Viewable online or exported from system dumps.

4. Watchdog monitoring: AR’s watchdog can be configured to trigger SERVICE mode on cycle time violations. The Logger records these events with timestamps.

7.3 Context Switch Visibility

Direct context switch monitoring (equivalent to Linux sched tracepoints or eBPF sched_switch) is not available on AR without Wind River’s proprietary instrumentation tools.

The Profiler provides the closest equivalent: it records task entry/exit events, preemption timing, and idle time — sufficient for most performance analysis needs.

8. Memory Access Monitoring: IO Reads/Writes

8.1 IO System Architecture

B&R uses a process image model:

• Inputs are mapped to %IX addresses
• Outputs are mapped to %QX addresses
• Memory areas: %MX (flags), %MX (merker/flags), %LX (local), %MW (word memory)

IO is updated cyclically by the kernel at the start/end of each cycle. User code reads/writes the process image, not hardware directly.

8.2 Monitoring IO at the Application Level

AsIO library — B&R’s standard IO access library:

• AsIOFListDP(): Get data pointers for IO objects
• AsIORead(), AsIOWrite(): Direct IO read/write from C/C++ modules
• Functions to enumerate IO channels, get mapping information

You can build a custom C module that periodically reads IO data and logs it:

AsIOFListDP() → get pointer to IO data area
memcpy() → copy data to telemetry buffer
Export via OPC UA or send via UDP

Source: https://community.br-automation.com/t/how-to-use-asio-library-function-asioflistdp-to-get-the-pointer-of-a-certain-io/3475

8.3 Watching IO via the Profiler

The Profiler does not capture individual IO read/write operations. It captures task-level timing, not data-level access patterns.

8.4 Watching IO via the Trace

Automation Studio’s Trace function can record variable values over time:

• Configure trace to sample specific variables at defined intervals
• Data is stored in a trace buffer and can be uploaded to Automation Studio
• Resolution limited by trace buffer size and sampling rate

8.5 Hardware-Level Monitoring (Not Possible from Software)

Direct hardware register access monitoring (equivalent to eBPF kprobe on ioread*/iowrite*) is not possible on B&R AR. The RTOS kernel handles all hardware access, and there is no user-space mechanism to observe or intercept it.

9. B&R’s Built-in Tracing and Profiling Hooks

9.1 Diagnostic Infrastructure Overview

B&R provides a comprehensive diagnostic infrastructure within Automation Runtime:

9.2 AsArProf Library

The AsArProf library provides programmatic control over the Profiler from within PLC code:

This allows automatic profiler activation on PLC startup, e.g., in an INIT program of TC#1:

1. Call LogStop to stop any running profiler
2. Call LogDeInstall to remove old config
3. Call LogInstall with custom parameters (buffer size, recording entries)
4. Call LogStart to begin recording
5. (Optional) Call LogStateGet to verify

Source: https://community.br-automation.com/t/how-to-create-a-long-profiler-with-enough-data-for-analysis/493

9.3 Library Logging

Individual B&R libraries can be configured for verbose logging within the Profiler. This adds library-specific events (e.g., POWERLINK stack events, motion control events) to the profiler trace.

10. Automation Studio Profiler

10.1 What the Profiler Captures

The Automation Studio Profiler is the primary performance analysis tool for B&R PLCs:

• Task execution times: How long each task class takes per cycle
• Task preemptions: When a higher-priority task interrupts a lower one
• CPU idle time: Percentage of time the CPU is idle
• Cycle time violations: When a task exceeds its configured cycle time
• Non-cyclic task execution: Event-driven task timing
• Call counts: Number of times each task was invoked
• Unknown task detection: Tasks not properly accounted for in the buffer

10.2 Profiler Configuration

The Profiler stores data in circular buffers:

The profiler should run for at least 2x the longest task cycle time for meaningful data.

10.3 Profiler Workflow

1. Connect Automation Studio to PLC
2. Open > Profiler
3. Configure buffer sizes (Configuration button)
4. Install profiler on target
5. Wait for capture period (10+ seconds typical)
6. Stop profiler → Upload Data Object
7. Analyze in Table view or Gantt-style timeline view
8. Save configuration into project for persistence across reboots

10.4 Profiler Output Analysis

• Table view: Shows each task class with min/max/avg cycle time, CPU usage percentage
• Gantt view: Visual timeline of task execution and preemptions
• Export: Data can be part of system dumps for offline analysis
• Archived profilers: Automatic error profilers are created on cycle time violations (stored as prfmod$f)

10.5 Limitations

• Requires Automation Studio connection (not a standalone tool)
• Buffer sizes limited by PLC memory (USRRAM/DRAM)
• Does not capture individual function/block execution times within a task
• Does not capture IO access patterns or message-level bus data
• No real-time streaming — data is collected in buffers and uploaded post-capture

Sources:

• https://community.br-automation.com/t/how-to-create-a-long-profiler-with-enough-data-for-analysis/493
• https://community.br-automation.com/t/maximum-cycle-time-violation/5749

11. Custom Telemetry Collectors Using B&R’s C/C++ SDK

11.1 Automation Runtime SDK

B&R provides a C/C++ development environment within Automation Studio for creating user modules (custom libraries and function blocks):

• ANSI C modules compiled for the VxWorks-based target
• Access to B&R runtime APIs (AsIO, AsTime, ArCAN, BRSystem, etc.)
• Compiled to .BR files (binary runtime modules)
• Runs as part of the cyclic task execution

11.2 Available Libraries for Telemetry

11.3 Building a Custom Telemetry Collector

Architecture for a C-based telemetry collector running on the PLC:

Cyclic Task (e.g., TC#2, 100ms)
  ├── Sample RTInfo → cycle time, task runtime
  ├── Read AsIO process image → IO values
  ├── Read ArCAN status → CAN bus counters
  ├── AsTime → high-resolution timestamp
  ├── AsUDP → send telemetry packet to collector server
  └── AsFile → local buffer/log file

The collector runs as a standard PLC program, with access to all runtime APIs. It can:

• Aggregate metrics over time
• Compute moving averages, min/max, histograms
• Send to external systems via UDP/TCP
• Write to local storage for batch upload

11.4 OPC UA as Telemetry Export

Rather than raw UDP, the OPC UA server provides a structured telemetry path:

1. Define telemetry variables in the Automation Studio project
2. Enable OPC UA accessibility on each variable
3. External OPC UA clients subscribe and receive updates at configurable rates

This is the recommended approach for production telemetry from B&R PLCs (see Section 15).

12. Live Monitoring vs. Dump-File Analysis

12.1 Live Monitoring

12.2 Dump-File Analysis (Post-Mortem)

12.3 System Dump Contents

A system dump (XML-based, collected via SDM or SdmSystemDump() FB) contains:

• General target status
• Software modules and their versions
• System timing information
• Hardware modules: configuration, serial numbers, firmware versions
• IO status at dump timestamp
• Memory status
• Logger entries
• Profiler data
• Network Command Trace data
• Application information

Source: https://github.com/hilch/systemdump.py

12.4 Automating System Dumps

The systemdump.py tool (open-source) automates system dump creation and collection from the command line:

pip install systemdumpy

py -m systemdumpy 192.168.0.100 -cuv -p MyCPU_

This creates, uploads, and saves system dumps programmatically — useful for automated diagnostics pipelines.

Source: https://github.com/hilch/systemdump.py

12.5 Comparison

13. Using perf to Profile B&R Tasks on VxWorks-Based Controllers

13.1 perf on VxWorks: Not Possible

The Linux perf tool is not available on VxWorks-based B&R controllers. perf requires:

• Linux perf_events kernel subsystem
• Hardware PMU access through Linux syscalls
• BPF or kernel module support for advanced tracing

None of these exist in VxWorks.

13.2 VxWorks Performance Analysis Tools

Wind River provides proprietary performance tools for VxWorks:

13.3 Tracealyzer for VxWorks

Tracealyzer is the closest VxWorks equivalent to Linux perf/eBPF tracing:

• Records task scheduling events (start, stop, preemption)
• Provides timeline visualization of task execution
• Supports user-defined events (custom instrumentation points)
• Requires linking a recorder library into the application
• Limitation: Requires the Tracealyzer SDK and integration into the B&R build process, which is not straightforward given AR’s closed nature

Source: https://www.windriver.com/blog/tracealyzer-for-vxworks-overview-and-getting-started-guide

13.4 VxWorks Kernel Shell Commands

If shell access is available (SSH/serial), useful diagnostic commands include:

taskShow()       /* List all tasks with stack usage and state */
spShow(taskId)   /* Show details of a specific task */
memShow()        /* Memory pool statistics */
iosShow()        /* IO system status */
netShow()        /* Network interface statistics */

13.5 Practical Takeaway

For profiling B&R PLC tasks, use the Automation Studio Profiler rather than trying to use VxWorks-level tools. The AS Profiler is purpose-built for B&R’s task class architecture and does not require additional licenses or access mechanisms.

14. Practical Limitations

14.1 What You CANNOT Monitor

14.2 What Requires Shell Access

Shell access (SSH or serial console) is needed for:

• VxWorks kernel shell commands (taskShow, memShow, etc.)
• File system browsing on the PLC
• Manual configuration changes not available via AS
• Network diagnostics (ifconfig, ping, etc.)

Shell access is not enabled by default and requires:

• SSH component to be included in the AR configuration
• SSH credentials configured in the project
• Network access to the PLC

B&R has confirmed SSH is supported on VxWorks (as of VxWorks 6.5+), but enabling it is a configuration choice.

Source: https://community.br-automation.com/t/sftp-support/8247

14.3 What Requires Automation Studio Project Files

14.4 What Requires Automation Runtime Source/License

14.5 Production Safety Considerations

• The Profiler adds CPU overhead (buffer writes every cycle) — minimize buffer sizes or uninstall after capture
• OPC UA subscriptions add network overhead
• System dump creation can briefly pause the PLC
• Custom telemetry C modules must not violate cycle time constraints
• Any monitoring that adds latency can cause cycle time violations in fast tasks

15. SDM and OPC-UA as Alternative Telemetry Paths

15.1 System Diagnostics Manager (SDM)

SDM is an integral component of Automation Runtime V3.0 and higher, providing web-based diagnostics accessible from any browser:

URL: http://<PLC-IP>/sdm

Available data through SDM:

SDM is the primary recommended tool for hardware-level health monitoring of B&R PLCs.

Source: https://www.scribd.com/document/916397506/TM213TRE-40-EnG-Automation-Runtime-V4100-B-R-Acopos

15.2 OPC UA Server

B&R provides OPC UA servers and clients on every controller as a standard feature (no additional licensing required):

• OPC UA server runs directly on the PLC
• Port 4840 (standard OPC UA)
• Supports both OPC UA client and server roles
• Any PLC variable can be exposed via OPC UA
• Subscription-based real-time updates
• Compliant with IEC 62443 security standards (AS 6.0+)

Setting up OPC UA telemetry:

1. In Automation Studio, open the CPU configuration
2. Enable OPC UA Server in the configuration
3. For each variable to monitor, set OPC UA accessibility in variable properties
4. OPC UA clients (SCADA, MES, custom collectors) subscribe to variables

OPC UA information models:

• B&R provides two OPC UA information models for representing PLC data
• Custom NodeId mapping available
• PLCopen function blocks for OPC UA server/client in user code

Sources:

• https://www.automation.com/article/br-adds-opc-ua-to-automation-studio-software
• https://opcua.brhelp.cn/OPC%2520UA%20Information%2520models.pdf
• http://soup01.com/en/2023/08/31/brautomation-studio_part04_configure-an-opc-ua-server-2/

15.3 Building an OPC UA-Based Telemetry Pipeline

B&R PLC
  └─ OPC UA Server (port 4840)
       ├─ PLC variables (cycle times, IO data, status flags)
       ├─ mapp component data
       └─ Custom telemetry variables from C modules
            │
            ▼
      OPC UA Collector (e.g., Telegraf, custom Python/C++ client)
            │
            ▼
      Time-Series Database (InfluxDB, TimescaleDB, Prometheus)
            │
            ▼
      Dashboard / Alerting (Grafana, etc.)

15.4 OPC UA FX (TSN)

B&R is moving toward OPC UA FX (Field eXchange) over TSN as the next-generation protocol, potentially replacing POWERLINK for new installations. This provides native OPC UA-based telemetry with TSN timing guarantees.

Source: https://www.reddit.com/r/PLC/comments/1pux2cf/is_br_making_a_mistake_choosing_opc_ua_fx_over/

16. SNMP Monitoring of B&R Hardware Health Metrics

16.1 SNMP Support

B&R PLCs support SNMP for network configuration and remote monitoring:

• SNMP v2c and v3 supported (v3 for authentication/encryption)
• SNMP agent runs as part of Automation Runtime
• Requires SNMP module to be included in the AS project configuration
• Standard MIB-II support for network interfaces
• B&R-specific private MIB for hardware diagnostics

16.2 Available SNMP Data

16.3 brsnmp — Open-Source Tool

brsnmp (https://github.com/hilch/brsnmp) is a C++ Windows command-line tool that executes PVI-SNMP commands for B&R PLCs. It requires the B&R PVI Development Setup to be installed (PVI 4.x or PVI 6.5.2+). Without a PVI license, PVI Manager runs for 2 hours then must be restarted.

Download the pre-built Windows binary from https://github.com/hilch/brsnmp/releases

Basic usage:

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

Capabilities:

• Remote network configuration via SNMP
• Hardware monitoring queries
• Integration with standard SNMP monitoring tools (Zabbix, Nagios, PRTG, etc.)

Source: https://github.com/hilch/brsnmp

16.4 SNMP Monitoring Integration

B&R PLC (SNMP Agent)
  └─ snmpd on Automation Runtime
       ├─ Standard MIB-II data (interfaces, system)
       └─ B&R private MIB (hardware health)
            │
            ▼
      SNMP Manager (Zabbix, Nagios, LibreNMS, PRTG)
            │
            ▼
      Alerts / Dashboards

16.5 SNMP Limitations

• No real-time PLC data: SNMP cannot access process variables, IO data, or cycle times
• Network/hardware only: Primarily useful for infrastructure monitoring (network interfaces, hardware status)
• Requires SNMP module: Must be included in the AS project; not enabled by default
• Polling-based: Not event-driven (unless combined with SNMP traps)
• Cannot replace OPC UA: For PLC application data, OPC UA is the proper protocol

17. Recommended Telemetry Architecture

17.1 For Production Monitoring

┌─────────────────────────────────────────────────┐
│                    B&R PLC                        │
│                                                   │
│  ┌──────────────┐  ┌──────────────────────────┐  │
│  │ OPC UA Server│  │ SNMP Agent                │  │
│  │ (port 4840)  │  │ (port 161)                │  │
│  └──────┬───────┘  └───────────┬──────────────┘  │
│         │                      │                   │
│  ┌──────┴───────┐              │                   │
│  │ Custom C     │              │                   │
│  │ Telemetry    │              │                   │
│  │ Module       │              │                   │
│  │ (via AsIO,   │              │                   │
│  │  RTInfo, etc)│              │                   │
│  └──────────────┘              │                   │
└─────────┬──────────────────────┬──────────────────┘
          │                      │
          ▼                      ▼
   ┌──────────────┐       ┌──────────────┐
   │ OPC UA       │       │ SNMP         │
   │ Collector   │       │ Manager      │
   │ (Telegraf,   │       │ (Zabbix,     │
   │  Node-OPCUA) │       │  LibreNMS)   │
   └──────┬───────┘       └──────────────┘
          │
          ▼
   ┌──────────────┐
   │ Time-Series  │
   │ DB           │
   │ (InfluxDB,   │
   │  TimescaleDB)│
   └──────┬───────┘
          │
          ▼
   ┌──────────────┐
   │ Grafana /   │
   │ Alerting    │
   └──────────────┘

17.2 For Deep Diagnostics (Post-Mortem)

1. System Dump via SDM or SdmSystemDump() function block
2. Upload with systemdump.py or AS
3. Analyze Profiler data, Logger entries, NCT data
4. Correlate with OPC UA historical data

17.3 For Development

1. Automation Studio Profiler (primary)
2. Watch windows + Trace (variable-level)
3. AS Debugger (source-level)
4. Network Command Trace (bus diagnostics)
5. SDM web interface (hardware status)

Appendix A: Source References

Appendix B: Quick Reference — Can I Monitor This?

Last updated: July 2026

SystemDumpViewer for Post-Mortem Analysis

B&R system dumps contain logger data, memory snapshots, task states, and hardware status. The community SystemDumpViewer tool provides a GUI for inspecting these dumps without B&R support portal access.

Installation and Usage:

## Download from the awesome-B-R repository
## https://github.com/br-automation-community/awesome-B-R
## SystemDumpViewer is a Java-based GUI tool

java -jar SystemDumpViewer.jar SystemDump.xml

Alternatively, systemdump.py (https://github.com/hilch/systemdump.py) provides command-line parsing:

pip install systemdump.py
systemdump --input SystemDump.xml --summary
systemdump --input SystemDump.xml --logger
systemdump --input SystemDump.xml --hardware

What the tools extract:

• Logger entries (errors, warnings, info) with timestamps
• Task cycle time statistics (min, max, average per task)
• Memory usage per task
• Hardware status (temperatures, voltages, module states)
• Stack traces for crashes (if captured)

This is the closest thing to eBPF-style post-mortem tracing available for B&R systems. See diagnostics-sdm.md for SDM system dump download procedures.

Key Findings

1. eBPF is NOT directly usable on B&R AR/VxWorks — the VxWorks kernel does not support eBPF infrastructure. All eBPF monitoring approaches require running on a separate Linux host, not on the PLC itself.
2. The most practical monitoring approach is network-level capture — use Wireshark/tshark to capture POWERLINK, OPC-UA, and Modbus traffic from a mirror port or tap. This reveals communication patterns without PLC access.
3. System dump analysis is the primary post-mortem diagnostic tool — the SDM system dump captures logger data, memory snapshots, and hardware state. It is the closest thing to “telemetry” available for B&R AR systems.
4. PVI variable monitoring from a PC provides real-time telemetry — the PVI API allows continuous variable polling at rates matching task cycle times. Combined with Python scripting, this creates a powerful external monitoring system.
5. strace/perf are irrelevant for the CP1584 — these tools require Linux on the target. For AR internals monitoring, use SDM, the AS Profiler, and the RTInfo function block.
6. For debugging control program bugs specifically, the most effective approach is the AS Logger with backtrace (for crashes), Trace/oscilloscope (for timing), and IecCheck (for runtime bounds checking).

Cross-References