System Variable Monitoring on B&R Automation Runtime

Overview

This document is a survival guide for automation engineers maintaining B&R X20CP1584 (and related CP15xx/CP35xx) PLCs from defunct OEMs with zero documentation. It covers every system variable you can read from a running B&R Automation Runtime (AR) controller, how to access them without the original project, and how to interpret abnormal values for proactive failure detection.

B&R AR exposes system health through three distinct mechanisms:

1. CPU I/O Mapping / General Data Points – hardware-level registers available in the controller’s I/O tree (temperature, battery status)
2. System Library Function Blocks (FUBs) – software functions from BRSystem, AsArProf, and other standard libraries (CPU usage, task cycle times, memory diagnostics)
3. System Diagnostics Manager (SDM) – built-in web server providing real-time dashboards without any development tools

Cross-references: See custom-diagnostic-tools.md for building external monitoring scripts, hardware-monitoring.md for physical inspection procedures, and execution-model.md for task class architecture details.

X20CP1584 Hardware Reference

Thermal Protection

LED Status Indicators

System Stop Error Codes (S/E LED Red Blink)

Pattern encoding: 4 phases of short (150 ms) or long (600 ms) pulses, repeated every 2 seconds.

System Variable Categories

1. CPU Temperature

Source: I/O Mapping (controller data points) / General Data Points

The X20CP1584 provides two temperature measurement points in its I/O mapping:

Note: There is no direct ambient/cabinet temperature sensor on the CPU. For external ambient monitoring, B&R offers X20CMR010/011/111/100 climate measurement modules.

Temperature delta rule: A 10 C rise in ambient temperature produces approximately a 10 C rise in both CPU and housing temperature.

Abnormal values indicate:

2. CPU Usage (Idle Time)

Source: LogIdleShow FUB from AsArProf library / SDM web interface

CPU usage is NOT available as a direct I/O data point. It must be read via software or the SDM.

The LogIdleShow function block from the AsArProf library calculates CPU usage from task idle time – the percentage of time when cyclic tasks are not consuming their allocated time slices. This is a measured average over a time interval, not an instantaneous value.

(* Example: LogIdleShow instantiation *)
fbIdleTime : LogIdleShow;

(* In cyclic task *)
fbIdleTime();
cpuIdlePercent := fbIdleShow.idle;   (* Higher = more idle = lower CPU usage *)

Abnormal values indicate:

Cross-reference: See execution-model.md for task class priority and time-slice allocation details.

3. Task Cycle Times

Source: RTInfo FUB from BRSystem library / Profiler / SDM Task Monitor

Each task class (Cyc0, Cyc1, Cyc2, Cyc3, and event tasks) is assigned a fixed time slice. When execution exceeds this slice, the watchdog timer triggers and can place the controller in SERVICE mode.

The RTInfo function block from the BRSystem library returns real-time task information:

(* Example: RTInfo for task monitoring *)
fbRTInfo : RTInfo;

(* In cyclic task -- pass task class name *)
fbRTInfo(pTask := 'Cyclic#1');    (* or 'Cyclic#2', 'Cyclic#3', etc. *)
fbRTInfo();
currentCycleTime := fbRTInfo.cycTime;   (* Current cycle execution time in us *)
minCycleTime    := fbRTInfo.cycTimeMin; (* Minimum observed cycle time *)
maxCycleTime    := fbRTInfo.cycTimeMax; (* Maximum observed cycle time *)

Cycle time monitoring thresholds:

Abnormal values indicate:

Key fact: Approximately 80% of all B&R SERVICE mode entries are caused by cycle time violations.

4. Memory Usage

Source: sys_br_get_info / I/O mapping / SDM

The X20CP1584 has 256 MB DDR2 SDRAM system RAM and 1 MB SRAM for user data. Memory usage can be monitored through:

• The SDM System page (web browser, no tools needed)
• sys_br system variable structures (if accessible in your runtime)
• Automation Studio memory diagnostic tools (with project)

Memory pressure indicators:

Abnormal values indicate:

5. Watchdog Status

Source: System configuration / SDM / Error logbook

B&R AR implements per-task-class watchdog timers. Each task class has a configurable watchdog timeout that defaults to slightly longer than the configured cycle time.

Watchdog configuration is in the Hardware Configuration -> Task Settings. Each task class can have its watchdog timeout independently adjusted.

Abnormal values / events indicate:

6. Battery Status

Source: BatteryInfo system library function / CPU I/O mapping / DC LED

Battery status is available both as a software-readable value and via the front-panel DC LED.

What battery backup covers:

• Remanent variables
• User RAM
• System RAM
• Real-time clock (RTC)

Replacement: Renata CR2477N only. Replace every 4 years. Can be hot-swapped under power, or within 1 minute without power. Never use a different battery model number.

Abnormal values indicate:

7. I/O Status

Source: I/O mapping / SDM Hardware page / LED indicators

The X20CP1584 uses an integrated I/O processor that handles I/O data points in the background, independently from the main CPU task execution.

The I/O mapping in the controller configuration automatically provides status structures for each connected module. When accessed through SDM or PVI, these data points are available without the project.

Abnormal values indicate:

8. Network Statistics

Source: SDM Network page / Ethernet & POWERLINK LED indicators

POWERLINK S/E LED State Machine (V2 mode):

Abnormal values indicate:

Reading System Variables Without the Project

This is the critical section for engineers working with defunct OEM equipment.

Method 1: System Diagnostics Manager (SDM) – No Tools Required

The SDM is a built-in web server on every B&R controller running AR V3.0 or higher. It requires only a web browser and TCP/IP connectivity.

Access: http://<PLC_IP_ADDRESS>/sdm

Procedure:

1. Connect PC to same network as PLC (or directly via crossover cable)
2. Ping the PLC IP address to verify connectivity
3. Open browser: http://<PLC_IP>/sdm
4. Navigate System / Hardware / Network tabs for diagnostics
5. Use the Error logbook tab for historical fault analysis

Tip: The SDM is always running in the background (even when the web page is not loaded). It provides historical CPU usage data for time intervals when no browser was connected. On smaller CPUs, opening the SDM can increase CPU usage by ~10%.

Cross-reference: See custom-diagnostic-tools.md for automating SDM data collection via scripts.

Method 2: PVI (Process Visualization Interface) – No Project Required

B&R’s PVI protocol can enumerate and read all controller variables (including system data points) without the source project. PVI tools ship with the B&R Runtime installation.

Procedure with PVI Monitor:

1. Install B&R Runtime components (includes PVI tools)
2. Open PVI Manager
3. Create new device connection (Ethernet: enter PLC IP; or RS232 for serial)
4. Launch PVI Monitor from the Runtime group
5. Browse the variable tree – system data points and I/O mapping are visible
6. Export variable list to CSV for documentation

Procedure with PVIservices (.NET):

// Conceptual -- PVIservices connects via PVI protocol
PVIConnection pvi = new PVIConnection();
pvi.Connect("192.168.1.100", PVIProtocol.ANSL);
foreach(var variable in pvi.GetAllVariables()) {
    Console.WriteLine($"{variable.Name}: {variable.Address}");
}

Procedure with OPC:

1. If OPC server is enabled on the PLC, connect with any OPC client
2. Browse the address space – system variables appear in the tree
3. No source code needed

Note: On legacy B&R PLCs (CP476 era), PVI communications do not require authentication. On newer AR versions, authentication may be configured.

Method 3: Automation Studio Online Mode – No Project Required

Even without the project source, Automation Studio can connect to a running PLC in online mode:

1. Install Automation Studio
2. Open AS without a project
3. Use Online -> Connect to Target (enter PLC IP)
4. Logger shows real-time and historical events
5. Watch Window can monitor variables by entering their names/addresses manually
6. Trace (oscilloscope) can capture variable values over time
7. Profiler captures task runtime behavior

Method 4: PLC I/O Mapping Direct Access

System data points (temperature, battery status) are in the controller’s own I/O mapping – not in the application project. They are always accessible through:

• SDM Hardware page
• PVI Monitor (browse to controller -> I/O mapping)
• Automation Studio I/O assignment in monitor mode

Trending System Variables Over Time

Built-in: Profiler

The Automation Studio Profiler captures task runtime behavior over extended periods:

1. Connect to PLC via Automation Studio (no project needed for basic profiling)
2. Open Tools -> Profiler
3. Configure which task classes to profile
4. Set recording duration (supports multi-hour captures)
5. Download and analyze in Automation Studio
6. Profiler logs can also be uploaded via SDM

Built-in: Trace (Variable Oscilloscope)

Automation Studio’s Trace function records variable values over time at high resolution:

1. Connect to PLC
2. Open Tools -> Trace
3. Add variables to trace (enter names manually if no project)
4. Set trigger conditions and recording depth
5. Supports continuous recording up to available memory
6. Export captured data for analysis

Limitation: Trace duration is limited by capture buffer size. For continuous 1-hour traces, the buffer must be sized appropriately.

Built-in: SDM Historical Data

The SDM automatically maintains historical data for:

• CPU usage (time-series graphs in System page)
• Error logbook entries with timestamps

This data persists across browser sessions and power cycles (stored in controller memory).

External: PVI + Custom Data Logger

For continuous, long-term trending without Automation Studio:

1. Use PVIservices DLL (.NET/C#) or Python (via ANSL protocol)
2. Create a service that polls system variables at regular intervals
3. Log to CSV, database, or time-series database (InfluxDB, Grafana)
4. Create dashboards for trend visualization

Key variables to poll:

• CPU idle percentage (via LogIdleShow if callable, or SDM)
• Task cycle times (via RTInfo or SDM)
• CPU and housing temperature (via I/O mapping data points)
• Battery status (via BatteryInfo or I/O mapping)
• POWERLINK state (via S/E LED or SDM)
• Error logbook entries

Cross-reference: See custom-diagnostic-tools.md for sample code and architecture for external monitoring systems.

External: OPC UA Subscriptions

If OPC UA is configured on the PLC:

1. Set up OPC UA subscriptions for system variables
2. Use any OPC UA client (free: Prosys Simulation, UA Expert)
3. Subscription-based monitoring provides real-time updates without polling

System Variable Quick Reference Tables

All Monitorable Variables (No Project Required)

Key System Library Function Blocks

Key System Variable Structures

sys_br Structure Members (AR 4.x)

The sys_br structure from the BRSystem library provides system-level information. While the exact member layout varies by AR version, the following fields are consistent across AR 4.x:

Reading sys_br in IEC code:

PROGRAM ReadSystemInfo
VAR
    sysInfo : sys_br;
END_VAR

sys_br_get_info();  (* Populate the structure *)

    (* Log system info to diagnostic string *)
    diagString := CONCAT(
        'AR Version: ', USINT_TO_STRING(sysInfo.wARVersionMajor), '.',
        USINT_TO_STRING(sysInfo.wARVersionMinor),
        ' Build: ', USINT_TO_STRING(sysInfo.wARVersionBuild), '.',
        USINT_TO_STRING(sysInfo.wARVersionSub),
        '\r\nCPU: ', sysInfo.aCPUName,
        '\r\nState: ',
        IF sysInfo.bSystemState = 0 THEN 'INIT'
        ELSIF sysInfo.bSystemState = 1 THEN 'RUN'
        ELSIF sysInfo.bSystemState = 2 THEN 'SERVICE'
        ELSIF sysInfo.bSystemState = 3 THEN 'BOOT'
        END_IF,
        '\r\nCPU Temp: ', REAL_TO_STRING(sysInfo.wCpuTemperature / 10.0, 1), ' C',
        '\r\nBattery: ',
        IF sysInfo.bBatteryStatus = 0 THEN 'OK'
        ELSIF sysInfo.bBatteryStatus = 1 THEN 'LOW'
        ELSIF sysInfo.bBatteryStatus = 2 THEN 'EMPTY'
        END_IF
    );

sys_task Structure Members (AR 4.x)

The sys_task structure provides per-task-class performance data. Index by task class number (0 = Cyclic#1, 1 = Cyclic#2, etc.):

Reading sys_task in IEC code:

PROGRAM MonitorAllTasks
VAR
    taskInfo : sys_task;
    i : USINT;
END_VAR

FOR i := 0 TO 7 DO
    sys_task_get_info(i);  (* Populate for task class i *)
    IF taskInfo.wTaskClassNumber = i THEN
        (* Task class is active *)
        diagMsg := CONCAT(
            'TC#', USINT_TO_STRING(i + 1),
            ': cycle=', UDINT_TO_STRING(taskInfo.wCycleTime), 'us',
            ' max=', UDINT_TO_STRING(taskInfo.wMaxCycleTime), 'us',
            ' load=', USINT_TO_STRING(taskInfo.wTaskLoad), '%',
            ' overloads=', UDINT_TO_STRING(taskInfo.wOverloadCount)
        );
        (* Log or send via OPC-UA *)
    END_IF
END_FOR

These structures are defined in the BRSystem library header files. To use them in your own diagnostic code, reference the BRSystem library in Automation Studio.

Note: The sys_br and sys_task structures are available within the AR runtime but their exact member layout varies by AR version. Consult the BRSystem library help in Automation Studio for the specific structure definition matching your controller’s AR version. The field names above are typical for AR 4.x but may differ slightly in AR 3.x or AR 6.x.

SysInfo Function Block (Community Discovery)

B&R community members have discovered that the SysInfo function block from the BRSystem library can detect whether the controller is in SERVICE mode or has recently rebooted. This is valuable for automated recovery scripts:

VAR
    fbSysInfo : SysInfo;
END_VAR

fbSysInfo();
IF fbSysInfo.bServiceMode THEN
    (* Controller is currently in SERVICE mode *)
    (* Implement automatic recovery or notification logic *)
END_IF

The SysInfo FUB provides additional fields beyond what is in sys_br, including flags for SERVICE mode, error state, and boot type (cold/warm/init).

Cross-reference: See custom-diagnostic-tools.md for building external monitoring systems that query these structures via PVI or OPC-UA.

Failure Mode Analysis: What Abnormal Values Really Mean

Failure Mode: Imminent SERVICE Mode (Watchdog Trip)

Leading indicators (detectable hours/days before failure):

Most common root causes:

1. Infinite loop in cyclic code (~80% of SERVICE mode entries)
2. Blocking I/O in fast task class (File I/O, TCP socket in Cyc0/Cyc1)
3. Excessive string manipulation in time-critical task
4. Memory leak gradually consuming resources
5. ANSL (Automation Net) communication overload

Failure Mode: Thermal Shutdown

Leading indicators:

Most common root causes:

1. Cabinet ventilation failure (fan, filter)
2. Blocked airflow (cables, debris over CPU)
3. Incorrect mounting orientation (horizontal vs vertical derating)
4. High ambient temperature (> 50 C)
5. Elevated above 2000 m elevation (requires 0.5 C derating per 100 m)

Failure Mode: Battery Depletion

Leading indicators:

Failure Mode: Network Communication Loss

Leading indicators:

Failure Mode: Memory Exhaustion

Leading indicators:

SERVICE Mode: Entry, Diagnosis, and Recovery

What Causes SERVICE Mode

Diagnostic Procedure When in SERVICE Mode

The PLC remains network-accessible in SERVICE mode. The IP address, SDM, and all diagnostic interfaces continue to function.

Step 1: Check the Logger / SDM Error Logbook

• Open SDM at http://<PLC_IP>/sdm or use AS Logger
• Find the timestamped error entry that caused SERVICE mode
• Note the error code and backtrace (if available)

Step 2: Common Error Codes

Step 3: Recovery

1. Identify and correct the root cause
2. In Automation Studio: Online -> Warm Restart
3. If no AS available, press the physical Reset button (enters SERVICE mode)
4. If Reset -> RUN mode switch: set switch to RUN position for automatic restart

Critical: A PLC in SERVICE mode is NOT executing control logic. Verify process state before warm restart.

Cross-reference: See hardware-monitoring.md for physical troubleshooting procedures when software diagnostics are insufficient.

Recommended Monitoring Strategy for Defunct OEM Systems

Minimum Viable Monitoring (No Code Changes)

Enhanced Monitoring (With PVI / External Script)

Full Instrumentation (Requires Code Deployment)

Important: Without the project source, you CANNOT modify the PLC program. Methods 1 and 2 are your only options. See custom-diagnostic-tools.md for building external monitoring that requires no PLC code changes.

Key Findings

1. SDM is your primary lifeline. Available at http://<PLC_IP>/sdm with zero tools, it provides CPU usage, task cycle times, memory usage, temperature, I/O status, network status, and the complete error logbook – all without the project source code.

2. CPU temperature is available as an I/O data point. Two sensors (CPU die + housing) are in the controller’s I/O mapping and readable via PVI, SDM, or direct I/O access. Shutdown occurs at 110 C (CPU) / 95 C (board). Normal operating range is 40-70 C at typical ambient temperatures.

3. CPU usage is NOT an I/O data point. It requires the LogIdleShow FUB from the AsArProf library (code deployment) or reading from the SDM (no code needed). Opening the SDM itself increases CPU usage by ~5-10% on smaller CPUs.

4. Task cycle times are the #1 failure indicator. ~80% of all SERVICE mode entries are caused by cycle time violations. Monitor via RTInfo FUB (BRSystem library), Profiler, or SDM Task Monitor. Watch for cycle time exceeding 85% of the configured time slice.

5. All system variables are readable via PVI without the project. PVI Monitor, Runtime Utility Center, and PVIservices DLL can enumerate and read every variable on the controller, including system data points, I/O mapping, and application variables. This is the recommended path for defunct OEM scenarios.

6. Battery status is dual-indicated (software register + DC LED). The battery buffers remanent variables, user RAM, system RAM, and the RTC. Replace every 4 years with Renata CR2477N only. Battery depletion causes loss of all persistent data on power cycle.

7. The sys_br and sys_task system variable structures from the BRSystem library provide structured access to runtime information (AR version, memory layout, per-task cycle statistics). Their exact member layout varies by AR version – consult the library help in Automation Studio.

8. POWERLINK state is fully diagnosable from the S/E LED. The 6-state LED pattern machine (NOT_ACTIVE -> BASIC_ETHERNET -> PREOP1 -> PREOP2 -> READY -> OPERATIONAL) provides immediate visual diagnostics without any tools.

9. For continuous external trending, use PVI + custom data logger (Python/.NET) or OPC UA subscriptions to push system variables into a time-series database. This requires zero PLC code changes and provides long-term trend analysis.

10. Thermal protection is automatic and aggressive. Per the official B&R datasheet, the X20CP1584 hard-shuts down (reset state) at 110°C CPU temperature or 95°C board temperature (error 9204). B&R may enter SERVICE mode at a lower temperature (~105°C estimated) before the hard shutdown. This is not configurable. Proper cabinet ventilation is the only mitigation.

Python Script: Comprehensive System Health Check

This script connects to a B&R CP1584 via OPC-UA and reads all accessible system variables for a complete health snapshot. It requires no project files or Automation Studio:

"""
B&R CP1584 System Health Check via OPC-UA.
Usage: python system_health_check.py <PLC_IP>
Requires: pip install asyncua
"""
import asyncio, sys
from datetime import datetime
from asyncua import Client

PLC_IP = sys.argv[1] if len(sys.argv) > 1 else "192.168.0.1"

async def check_health():
    url = f"opc.tcp://{PLC_IP}:4840"
    print(f"B&R CP1584 System Health Check")
    print(f"Connecting to {url}...")
    print("=" * 60)

    async with Client(url=url) as client:
        root = client.get_root_node()
        print("Connected. Scanning address space...\n")

        children = await root.get_children()
        all_vars = {}

        async def scan_node(node, depth=0):
            if depth > 5:
                return
            try:
                for child in await node.get_children():
                    name = (await child.get_browse_name()).Name
                    node_id = child.nodeid.to_string()
                    dtype = (await child.get_data_type()).to_string()

                    keywords = [
                        "temperature", "cpu", "battery", "cycle", "load",
                        "task", "memory", "ram", "status", "error",
                        "uptime", "state", "power", "link", "plk",
                        "idle", "free", "watchdog"
                    ]

                    if any(kw in name.lower() for kw in keywords):
                        try:
                            val = await child.get_value()
                            all_vars[node_id] = {
                                "path": node_id,
                                "name": name,
                                "value": val,
                                "type": dtype
                            }
                        except Exception:
                            all_vars[node_id] = {
                                "path": node_id,
                                "name": name,
                                "value": "READ_ERROR",
                                "type": dtype
                            }
                    await scan_node(child, depth + 1)
            except Exception:
                pass

        await scan_node(root)

        if not all_vars:
            print("No system variables found in OPC-UA namespace.")
            print("Possible causes:")
            print("  - OPC-UA server not configured")
            print("  - System variables not exposed in address space")
            print("  - Authentication required (try credentials)")
            print("\nAlternative: Use SDM at http://<PLC_IP>/sdm")
            return

        print(f"Found {len(all_vars)} system variables\n")

        for node_id, info in sorted(all_vars.items(),
                                    key=lambda x: x[1]["name"]):
            val = info["value"]
            status = "  "
            if isinstance(val, (int, float)):
                if "temp" in info["name"].lower():
                    if val > 89:
                        status = "!!"
                    elif val > 75:
                        status = "! "
                elif "load" in info["name"].lower() or "usage" in info["name"].lower():
                    if val > 85:
                        status = "!!"
                    elif val > 70:
                        status = "! "
                elif "error" in info["name"].lower():
                    if val != 0:
                        status = "!!"

            print(f"  {status} {info['name']:40s} = {val}")

        print(f"\nLegend:  = normal, ! = warning, !! = critical")
        print(f"\nTimestamp: {datetime.now():%Y-%m-%d %H:%M:%S}")
        print(f"Total variables scanned: {len(all_vars)}")

asyncio.run(check_health())

SNMP-Based System Monitoring

For continuous monitoring without OPC-UA or PVI, the B&R SNMP agent exposes system variables via standard SNMP MIB:

# Install brsnmp for B&R device discovery and SNMP queries
pip install brsnmp

# Quick system health check via SNMP
brsnmp --walk 192.168.0.1

# Monitor CPU temperature via SNMP (OID varies by AR version)
snmpget -v2c -c public 192.168.0.1 1.3.6.1.4.1.2808.1.2.1

# Monitor system uptime
snmpget -v2c -c public 192.168.0.1 sysUpTime.0

See iiot-retrofit.md for full SNMP configuration and access-recovery.md for brsnmp discovery procedures.

Cross-References

Document generated from research across B&R official documentation, B&R Community forums, Automation Runtime training materials, X20CP158x datasheets, and field engineering sources. Applicable to X20CP1583/1584/1585/1586 and X20CP358x series with Intel Atom processors running Automation Runtime V3.0+.