B&R System Diagnostics Manager (SDM) & Automation Studio Diagnostics

Target audience: Automation engineers maintaining undocumented B&R CP1584 machines with zero OEM documentation. This guide covers how to access, configure, and use SDM and Automation Studio diagnostic tools to troubleshoot and understand a B&R controller you did not originally program.

1. Overview

B&R System Diagnostics Manager (SDM) is a built-in diagnostic web interface available in Automation Runtime V3.0 and higher. It provides browser-based access to the controller’s internal state—CPU load, memory usage, task execution, I/O module health, and the system logbook—without requiring Automation Studio, a project file, or any OEM documentation.

For CP1584 machines where no project exists in your archive, SDM is often the first and only tool you have to understand what the controller is doing, why it may have stopped, and what hardware is actually installed.

SDM is complemented by Automation Studio’s Logger tool, which can import system dump files (.tar.gz) exported from SDM for deeper offline analysis.

2. Prerequisites & Configuration

2.1 What Must Be Enabled on the Controller

SDM does not work out of the box on every B&R controller. Two services must be enabled in the Automation Runtime configuration:

If you have no project file (common when inheriting undocumented machines), you cannot change these settings via Automation Studio. Options:

1. Check if SDM is already running — open http://<PLC_IP>/sdm in a browser. If it loads, you’re good.
2. Use Automation Studio’s “Upload from PLC” — connect to the PLC IP, upload the configuration, enable web server and SDM, then download. This requires at minimum a compatible Automation Studio version matching the runtime on the target.
3. Default configuration — many B&R default configurations ship with the web server enabled. SDM is not always enabled by default on older images.

2.2 Network Access

SDM communicates over HTTP (not HTTPS by default). Ensure:

• The PLC IP is reachable from your workstation (ping test).
• Port 80 is open on the PLC (standard HTTP).
• For remote/internet access, a VPN or port-forward must be configured — SDM has no built-in authentication mechanism in older versions. Treat exposed SDM interfaces as sensitive.

3. Accessing SDM

3.1 Web Browser Access

Open any standard web browser and navigate to:

http://<PLC_IP>/sdm

For example, if the CP1584 has IP 192.168.1.10:

http://192.168.1.10/sdm

No installation, no plugins, no Java required. SDM renders a standard HTML interface.

3.2 Access Without Project Files

This is the critical advantage of SDM for undocumented machine scenarios:

• You do not need Automation Studio installed.
• You do not need the OEM project file or source code.
• You do not need to know the PLC’s configuration.
• You only need the PLC’s IP address and network connectivity.

SDM reads directly from the controller’s runtime, showing you the live state of the system as it runs.

3.3 Remote / Internet Access

Because SDM is web-based, it can be accessed from any location—intranet or internet—provided network routing is in place. This is useful for:

• Remote troubleshooting of field machines.
• Monitoring a line of machines from a central engineering office.
• Supporting multiple plants without traveling.

4. SDM Interface — Sections & What They Show

4.1 System Logbook

The System Logbook (also called Event Log or System Log) is a chronological record of system events recorded during:

• Startup — boot sequence, module initialization, firmware loading, configuration application.
• Runtime operation — warnings, errors, state changes, communication events, module insertion/removal (if hot-swappable).

Logbook entries include:

• Timestamp (controller time)
• Event class (Info, Warning, Error, Fatal)
• Event ID / error code
• Source module (which hardware or software component generated the event)
• Description text

The logbook is the primary tool for understanding why a controller went into Error or Stop state. Always check it first after a fault.

4.2 CPU Usage

SDM displays the current CPU utilization of the controller as a percentage. This shows:

• Overall CPU load across all tasks.
• Whether the controller is CPU-bound (sustained >80% is a concern).
• Spikes that correlate with specific events (e.g., cyclic communication timeout causing retry storms).

4.3 Task Monitor

The Task Monitor is one of the most valuable SDM sections. It shows every cyclic task configured on the controller with:

What to look for:

• A task with a max cycle time approaching its configured watchdog limit → imminent watchdog trip.
• A task showing error state → that task has crashed or is stuck.
• High task load on a low-priority task stealing time from critical I/O tasks.

4.4 Memory Information

SDM shows memory usage broken down into:

• User memory — how much of the available user RAM is allocated.
• System memory — memory used by the operating system and runtime.
• File system — usage on the onboard file system (if applicable).

Memory exhaustion can cause subtle failures (task not starting, unable to allocate buffers) before any explicit error is raised.

4.5 I/O Module Status

SDM lists all I/O modules detected in the controller’s hardware tree with:

• Module type and identifier.
• Slot/bus position.
• Status — OK, Error, Not responding, Initializing.
• Module firmware version.

This is critical on undocumented machines because it reveals the actual hardware configuration without needing the project file. You can use this to reconstruct a hardware overview of the machine.

5. System Dump Files

5.1 What Is a System Dump

A system dump is a snapshot of the controller’s entire diagnostic state, packaged as a .tar.gz archive. It contains:

• Hardware information — controller type, serial number, firmware version, module inventory.
• System logbook entries — all recorded events up to the moment of the dump.
• Diagnostic data — task states, memory maps, I/O status, error registers.
• Configuration snapshot — relevant runtime configuration parameters.

System dumps are created on the controller via SDM and then downloaded to your PC for offline analysis in Automation Studio.

5.2 Creating a System Dump in SDM

1. Navigate to http://<PLC_IP>/sdm.
2. Locate the System Dump or Create Dump section.
3. Click Create or Generate.
4. Wait for the controller to collect and package the data (can take 30 seconds to several minutes depending on system complexity).
5. Download the resulting .tar.gz file to your workstation.

The dump is created from the controller’s current state. If the controller is in Error/Stop, create the dump before cycling power—the dump captures the fault state, which is what you need to analyze.

5.3 Opening System Dumps in Automation Studio

To analyze a system dump file in Automation Studio’s Logger:

1. Open Automation Studio.
2. Open or create a project — the Logger tool requires at least a project to be open. If you do not have the real project, create a dummy project (any valid B&R project with the same or similar controller target). The Logger uses the project context only as a container; it reads the dump data from the file itself.
   • Workaround: Create a new project, add a single controller of the same type as the PLC (e.g., CP1584), and save it. This is enough.
3. Open the Logger — use Ctrl+L or go to Tools → Logger.
4. In the Logger, click Load Data (or File → Load Data).
5. Navigate to the .tar.gz system dump file and open it.
6. The Logger will parse the dump and display all contained diagnostic data.

5.4 Limitations of Logger with Dummy Projects

When using a dummy project to analyze a dump from an unknown machine:

• Hardware tree mismatch — the dummy project won’t match the real hardware. Logger may show some modules as “unknown.” This is acceptable; the logbook and diagnostic data are still fully readable.
• No variable cross-reference — without the real project’s variable declarations, Logger cannot resolve variable names in the dump’s memory snapshots. You see raw addresses, not symbolic names.
• No source-level debugging — Logger shows diagnostic data, not source code. To trace logic, you still need the actual project.

Despite these limitations, the logbook data, error codes, and task state information alone are often enough to diagnose the root cause of a fault.

6. Common Error Codes

The following error codes are frequently encountered in B&R CP1584 and similar controllers. They appear in the SDM System Logbook and in Automation Studio diagnostics.

Error Code Investigation Procedure

1. Note the error code and timestamp from the SDM logbook.
2. Look at 5-10 entries before the error — preceding warnings often indicate the root cause (e.g., a communication timeout followed by a watchdog trip).
3. Look at entries after the error — does the controller recover, or does it go to Stop?
4. Cross-reference the error code in the table above.
5. If the error is recurring, download a system dump and analyze in Automation Studio Logger.

7. ANSL Communication (PVI Port)

7.1 ANSL TCP Port

B&R controllers use the ANSL (Automation Network Service Layer) protocol for PVI (Process Visualization Interface) and automation communication. The default TCP port is 11169.

This port is used by:

• Automation Studio to connect to the PLC for programming, debugging, and configuration.
• PVI-based HMI applications (e.g., VNC, Panel Builder, custom SCADA) to exchange data with the PLC.
• OPC UA and other higher-level protocols that run on top of PVI.

7.2 Port Accessibility

• Ensure port 11169 is reachable from your Automation Studio workstation (test with telnet <PLC_IP> 11169 or a similar tool).
• Firewalls between your PC and the PLC must allow TCP/11169.
• If Automation Studio cannot connect to the PLC but SDM (port 80) works, the ANSL port may be blocked or the PVI service may not be running.

7.3 Troubleshooting Connection Issues

8. Practical Procedures for Undocumented Machines

8.1 First Contact — What to Do When You Have No Documentation

1. Find the PLC IP address.

   • Check the machine’s network switch/router for B&R MAC addresses (OUI: 00:0C:CD or similar).
   • Use B&R IP Address Finder tool (part of Automation Studio installation) to scan the subnet.
   • Check if a label on the controller shows an IP (common on well-maintained machines).
   • Try common B&R defaults: 192.168.1.10, 192.168.0.10.

2. Open SDM in a browser.

   • Navigate to http://<PLC_IP>/sdm.
   • If SDM loads, proceed. If not, try enabling it via Automation Studio (see Section 2.1).

3. Record the hardware configuration.

   • In SDM, go to I/O Module Status.
   • Document every module: type, slot, status, firmware version.
   • This becomes your hardware reference.

4. Download and review the System Logbook.

   • Look for recurring errors.
   • Note the controller firmware version (shown in SDM header or hardware info).
   • Check if the controller is in Run, Error, or Stop state.

5. Create a system dump.

   • Download the .tar.gz file.
   • Open it in Automation Studio Logger (Ctrl+L → Load Data).
   • Review all diagnostic data offline.

6. Attempt to upload the configuration.

   • In Automation Studio, use Online → Upload to pull the configuration from the PLC.
   • This gives you the configuration (hardware tree, task structure, network settings) without the source code.
   • Upload does not give you the PLC program logic, but it gives you the project skeleton.

8.2 Routine Health Check Procedure

For machines you maintain but did not program, perform these checks periodically:

1. Open SDM → System Logbook — scan for new warnings/errors since last check.
2. Task Monitor — verify no task is approaching its watchdog limit; check for any task in Error state.
3. CPU Usage — ensure not consistently above 80%.
4. Memory Information — ensure not above 90% (leave headroom for peak operation).
5. I/O Module Status — verify all modules show OK.
6. If anything looks off, create a system dump before the situation degrades.

8.3 Post-Fault Investigation Procedure

1. Do not cycle power yet. The fault state contains diagnostic information.
2. Open SDM → System Logbook — read the last 20+ entries to understand the fault sequence.
3. Create a system dump immediately — this captures the fault state.
4. Task Monitor — check if any task is in Error or has an extreme max cycle time.
5. I/O Module Status — check if any module is in Error or Not Responding.
6. Download the dump and analyze in Automation Studio Logger.
7. Cross-reference error codes with the table in Section 6.
8. Only after gathering all diagnostic information, address the root cause and restart the controller.

9. SDM Advanced Features

9.1 Alarm Visualization

SDM provides an alarm overview section that aggregates active alarms and warnings from the system logbook. On newer AR versions (V4.0+):

• Active alarm count — grouped by severity (Warning, Error, Fatal).
• Alarm list — each row shows timestamp, alarm class, alarm ID, source module, and description. Clicking may reveal additional detail on some versions.
• Alarm acknowledgment — newer versions allow acknowledging alarms from the web interface, clearing them from the active display (does not fix the underlying cause).
• Historical alarm filter — some versions include date/time range and severity filters.

On CP1584 controllers running older AR versions (V3.x), the alarm view is typically limited to a simple scrolling list of the most recent logbook entries with no filtering or acknowledgment capability.

9.2 Trending and Graphing Capabilities

SDM does not include built-in trending. Workarounds: programmatic polling with time-series storage (Section 10), B&R mapp View widget trends, Automation Studio Watch/Trace, or OPC-UA subscriptions to external tools like Grafana.

9.3 Firmware and Software Version Display

SDM shows key identifiers in the hardware information area:

This information determines whether a specific SDM feature is available, whether firmware updates are needed, and which Automation Studio version is required to connect.

9.4 SDM Access via HTTPS (Newer AR Versions)

Starting with Automation Runtime V4.0, the B&R web server supports HTTPS:

https://<PLC_IP>/sdm

Requirements and notes:

• TLS certificate — controller ships with a self-signed certificate (browsers show a security warning). CA-signed certificates can be uploaded via Automation Studio.
• Must be explicitly enabled in AR configuration under System → Configuration → Web Server. Not enabled by default.
• Port — HTTPS typically uses 443, configurable in web server settings.
• HTTP redirect — some versions can redirect HTTP (port 80) to HTTPS (port 443).

For undocumented machines, try HTTP first (http://<PLC_IP>/sdm). If it fails, try HTTPS. If both fail, the web server or SDM may not be enabled.

9.5 SDM REST API for Programmatic Access

Newer Automation Runtime versions (V4.50+) expose a limited REST-like interface alongside the SDM web pages. This is not a fully documented public API, but the following endpoints are observable on V4.x controllers:

Caveats: these endpoints are not officially documented and may change between firmware versions. On V3.x they generally do not exist. No auth on older firmware; newer may require credentials. Probe http://<PLC_IP>/sdm/api/system/info with curl to test.

9.6 SDM User Authentication

Starting with Automation Runtime V4.20, SDM supports optional user authentication:

• Username/password login — credentials managed in AR configuration under System → Configuration → Users.
• Default credentials — many controllers ship with a default admin account. Check default settings or machine documentation.
• Role-based access — users can be assigned roles limiting access to certain SDM sections.
• Anonymous access — on controllers where authentication is not configured, SDM remains open. Default on older firmware.

If you encounter a login prompt without credentials, check with the previous maintainer or OEM. Authentication cannot be bypassed via the web interface.

9.7 SDM System Configuration Display

SDM includes a read-only view of system configuration parameters. Typically visible:

• Network configuration — IP address, subnet mask, gateway, DNS servers, hostname.
• Time synchronization — SNTP/NTP server settings, current time, timezone offset.
• Communication settings — ANSL port, OPC-UA endpoint, POWERLINK settings.
• Task configuration — task names, configured cycle times, watchdog limits.
• File system paths — default directories for logs, configuration, user data on CF card.

This read-only view is valuable for undocumented machines as it reveals operational settings without needing the project file. Not all parameters are visible through SDM — some are only accessible via Automation Studio.

9.8 SDM File Browser

On controllers with CompactFlash storage, some SDM versions include a file browser for viewing and downloading files:

• System log files — text log files written by the runtime.
• Configuration files — .cfg, .xml configuration files on the CF card.
• User files — files placed on the CF card by the application or user.
• System dump files — previously created dumps stored on the controller.

Limitations: availability depends on AR version and web server configuration. Upload and deletion are typically not available — this is a read-only interface. Large files or deep directory trees may cause slow rendering or timeouts.

10. Programmatic SDM Data Access

10.1 Python Script to Scrape SDM Web Pages

For controllers running AR V3.x where no REST API exists, the HTML pages served by SDM can be parsed programmatically using requests and BeautifulSoup (pip install requests beautifulsoup4):

import requests
from bs4 import BeautifulSoup
from datetime import datetime
import json

PLC_IP = "192.168.1.10"
SDM_BASE = f"http://{PLC_IP}/sdm"

def get_sdm_page(path):
    url = f"{SDM_BASE}/{path}"
    resp = requests.get(url, timeout=10)
    resp.raise_for_status()
    return resp.text

def parse_task_monitor(html):
    soup = BeautifulSoup(html, "html.parser")
    table = soup.find("table")
    if not table:
        return []
    headers = [th.get_text(strip=True) for th in table.find_all("th")]
    tasks = []
    for row in table.find_all("tr")[1:]:
        cells = [td.get_text(strip=True) for td in row.find_all("td")]
        if len(cells) == len(headers):
            tasks.append(dict(zip(headers, cells)))
    return tasks

snapshot = {
    "timestamp": datetime.utcnow().isoformat() + "Z",
    "tasks": parse_task_monitor(get_sdm_page("taskmonitor")),
}
print(json.dumps(snapshot, indent=2, default=str))

Important notes:

• The URL paths (/sdm/cpu, /sdm/taskmonitor, /sdm/memory) are illustrative. Actual paths vary by AR version. Inspect the SDM page source in a browser to determine correct paths for your controller.
• Table structures in the SDM HTML change between firmware versions. Adjust the parsing logic accordingly.

10.2 Parsing the SDM HTML Interface Programmatically

The SDM interface is standard server-rendered HTML. To parse any SDM page:

1. Inspect page source in your browser (F12 developer tools) to find <table> elements containing target data.
2. Handle pagination — some pages paginate with URL parameters (e.g., ?page=2&count=50). Loop through pages to collect all entries.
3. Handle frame-based layouts — older SDM versions use HTML framesets. Fetch frame URLs individually by inspecting <frame src="..."> attributes.
4. Character encoding — controllers may serve ISO-8859-1 or UTF-8. Check the Content-Type header or set resp.encoding explicitly.

10.3 Using Requests + BeautifulSoup to Extract Task Monitor Data

The task monitor page is the most useful data to scrape. Key considerations:

• Refresh rate — SDM shows snapshots. Poll every 30-60 seconds.
• Max cycle time — running maximum since last restart. A sudden jump between polls indicates a recent anomaly.
• Task state changes — transition from “Running” to “Error”/“Waiting” is an immediate alert.
• Watchdog proximity — ratio of max cycle time to watchdog limit. Above 80%: warning; above 95%: critical.

10.4 Using SDM Data in Automated Monitoring Systems

SDM data can be integrated into monitoring tools: write a Prometheus exporter for Grafana dashboards, a Nagios/Icinga check plugin, use Telegraf’s http_json/exec plugins, or publish to MQTT for Node-RED subscribers. Key considerations: rate-limit polling (CP1584 web server has limited capacity), cache if multiple consumers need data, handle reboots gracefully, and track uptime to detect unexpected restarts.

11. System Dump Deep Dive

11.1 What Is Inside the .tar.gz File

A system dump .tar.gz archive typically contains:

system_dump/
  info/
    hardware.txt, software.txt, configuration.txt, network.txt
  log/
    logbook.txt, logbook_alarms.txt
  diagnostic/
    tasks.txt, memory.txt, io_status.txt, cpu.txt
  trace/
    cyclic_trace_*.dat, bus_trace_*.dat          (binary)
  files/
    *.cfg, *.xml                                (config snapshots)
  runtime/
    global_vars.bin, task_stacks.bin            (binary)

Exact contents vary by AR version and controller type. Trace and runtime sections may be empty if no tracing was configured. The info/ and log/ directories are always present.

11.2 Extracting and Examining Specific Dump Files Without Automation Studio

The .tar.gz archive is a standard tar+gzip file. No B&R software needed:

mkdir dump_extracted
tar xzf system_dump_20260710_143022.tar.gz -C dump_extracted

Key files to examine directly with any text editor:

• info/hardware.txt — controller type, serial, AR version, hardware revision.
• log/logbook.txt — complete logbook; most immediately useful for fault analysis.
• diagnostic/tasks.txt — task cycle time statistics at dump time.
• diagnostic/io_status.txt — I/O module listing and status.
• diagnostic/memory.txt — memory usage at dump time.

Binary files (.dat, .bin) require Automation Studio Logger.

11.3 Log File Format Inside the Dump

The log/logbook.txt uses a structured text format:

[2026-07-10 14:30:22.123] [Error   ] [9210] [TaskMonitor] Cyclic#1 exceeded watchdog limit (cycle=52.3ms, limit=50.0ms)

Field breakdown: Timestamp (YYYY-MM-DD HH:MM:SS.mmm, controller local time), Severity (Info/Warning/Error/Fatal), Event ID (numeric, matching Section 6 codes), Source (subsystem or module), Description (may include numeric values). Some entries have additional fields or multi-line descriptions, especially hardware fault events.

11.4 Configuration Snapshot Content

The info/configuration.txt file contains key-value pairs. Typical entries:

Controller Type: CP1584
Automation Runtime: V4.73
Uptime: 14d 06h 23m 11s
Network.IP: 192.168.1.10
ANSL.Port: 11169
OPC-UA.Enabled: true
WebServer.Enabled: true
SDM.Enabled: true
Powerlink.CycleTime: 1000us

This captures only operational parameters the diagnostic subsystem can read. For complete configuration (hardware tree, task mappings, variables), you need the project file.

11.5 Comparing Dumps Over Time (Diff Analysis)

When troubleshooting intermittent issues, comparing dumps from different time points reveals state changes:

diff -u dump_20260709/log/logbook.txt dump_20260710/log/logbook.txt
diff -u dump_20260709/diagnostic/tasks.txt dump_20260710/diagnostic/tasks.txt
diff -u dump_20260709/diagnostic/memory.txt dump_20260710/diagnostic/memory.txt

What to look for:

• New error entries — errors in the later dump indicate a developing fault.
• Memory growth — increasing user memory across dumps without a corresponding decrease suggests a memory leak.
• Max cycle time increase — a task’s max cycle time growing progressively indicates accumulating latency.
• Module status changes — a module going from OK to Error points to hardware degradation.
• Configuration changes — differences in configuration.txt mean someone changed runtime settings between dumps.

11.6 Retention and Storage of Dumps for Compliance

For environments requiring diagnostic retention:

• Naming convention — PLC01_CP1584_FAULT_20260710.tar.gz (machine ID, controller, reason, date).
• Storage — network share alongside maintenance logs.
• Retention — at least warranty period or regulatory requirement (typically 2-5 years for ISO 9001).
• Metadata log — spreadsheet tracking date, machine ID, serial, AR version, reason, file location, analysis notes, root cause.
• Size — 5-50 MB compressed. Store compressed; dispose per data retention policy when expired.

11.7 System Dump via CLI: systemdump.py (Open Source)

The systemdump.py tool by the hilch community contributor automates system dump creation, upload, and inventory extraction from the command line — no browser or Automation Studio required.

Installation:

pip install systemdumpy

Creating, uploading, and saving a dump from CLI:

py -m systemdumpy 192.168.1.10 -cuv -p MyMachine_

Output:

create a systemdump on 192.168.1.10
upload systemdump from 192.168.1.10
saving MyMachine__BuR_SDM_Sysdump_2026-07-10_14-30-55.tar.gz (2820986) bytes

Flags:

Batch automation example — dump all machines on a subnet:

for ip in 192.168.1.10 192.168.1.11 192.168.1.12; do
  py -m systemdumpy "$ip" -cuv -p "$(hostname)_${ip}_" || echo "FAILED: $ip"
done

Creating hardware inventory from an existing dump file:

py -m systemdumpy BuR_SDM_Sysdump_2026-07-10_17-43-05.tar.gz -iv

This extracts all hardware module information (type, serial, firmware, status) into an .xlsx spreadsheet — invaluable for building spare parts inventories on undocumented machines. See spare-parts.md for the inventory methodology.

Viewing dumps without Automation Studio:

The SystemDumpViewer (GPL v3, desktop app) can open .tar.gz system dump files on any platform without Automation Studio installed. It displays hardware info, logbook, task timing, IO status, and memory data from the XML inside the archive.

12. AR Logbook Deep Analysis

12.1 Logbook Entry Format Details

The Automation Runtime system logbook records events in a structured format. Understanding the exact field layout is essential for programmatic parsing and filtering:

[YYYY-MM-DD HH:MM:SS.mmm] [Severity  ] [EventID] [Source          ] Description text

Severity levels in order of increasing criticality:

Timestamps use the controller’s local time. If the clock is wrong (no SNTP sync, dead backup battery), timestamps will be offset from real time. Always verify time sync before relying on timestamps for forensic analysis.

12.2 Filter Patterns for Common Issues

When searching the logbook for specific problem categories:

Communication issues:

• Event IDs: 9214, 5xxx range. Sources: ANSL, PVI, Powerlink, EtherCAT, Modbus.
• Descriptions: timeout, connection lost, cable, retry.

Task/execution issues:

• Event IDs: 9210, 5xxx range. Sources: TaskMonitor, Cyclic, Timer.
• Descriptions: exceeded, watchdog, cycle time, overflow.

Hardware issues:

• Event IDs: 9204 (temperature), 9206 (module fault). Sources: Hardware, I/O, Bus.
• Descriptions: temperature, fault, not responding, inserted, removed.

Memory issues:

• Event ID: 9212. Descriptions: memory, allocation, buffer, insufficient.

Startup issues:

• Severity Fatal in the first 60 seconds after boot timestamps.
• Descriptions: configuration, firmware, initialization, boot.

12.3 Logbook Capacity and Rollover Behavior

The AR system logbook has finite capacity:

• Memory buffer — stored in a fixed-size memory buffer, typically 64 KB to 1 MB depending on controller and configuration.
• Ring buffer — when full, oldest entries are overwritten. No archive to non-volatile storage by default.
• Entry size — 80-200 bytes typical. A 512 KB buffer holds approximately 2,500-6,000 entries.
• Estimated capacity — moderate event activity retains 1-3 days; many warnings may only retain a few hours.

Implications:

• Dumps are essential for long-term analysis — the buffer rolls over, so creating a system dump is the only way to preserve data.
• After a fault, dump immediately — root-cause entries will eventually be pushed out by subsequent events.
• Logbook-to-file — AR V4.x can optionally write logbook entries to a file on the CF card (check AR configuration under System → Configuration → Logbook).

12.4 Exporting Logbook to CSV or Text

Via SDM file browser: navigate to logbook file (typically /log/logbook.txt on CF card) and download.

Via Automation Studio Logger: load dump or connect live, select Logbook view, use File → Export Data.

12.5 Correlating Logbook Entries with POWERLINK Events

On machines using POWERLINK as the fieldbus:

• POWERLINK cycle errors — logbook entries with source Powerlink or event IDs in the 6xxx range indicate fieldbus issues, correlating with I/O module status changes in SDM.
• Timing correlation — a POWERLINK cycle error followed by a task watchdog timeout (event 9210) within the next few entries indicates the communication fault caused a task to block waiting for I/O data.
• Node-related events — POWERLINK entries referencing specific node numbers cross-reference to I/O modules in SDM to identify the affected physical module.
• Isochronous mode violations — entries mentioning isochronous or timing violation indicate the network cycle was disrupted, potentially causing motion control or synchronized I/O errors.

For deeper POWERLINK analysis, the dump’s trace/cyclic_trace_*.dat files contain captured cycle data (requires Automation Studio Logger).

12.6 Logbook Retention Policy

Recommended: configure logbook-to-file on CF card (if supported), create periodic system dumps, and use a Python scraper to capture entries to a central database.

12.7 Reading Logbook via OPC-UA or PVI

For controllers with OPC-UA enabled, logbook entries can be read programmatically:

• OPC-UA logbook node — under Objects > System > Logbook, provides recent entries as an array. Subscribing gives near-real-time updates.
• PVI logbook access — PVI provides a logbook object readable via the PVI .NET, C++, or Python API.
• Event subscriptions — OPC-UA event subscriptions push logbook events as they occur, eliminating polling. Server-side filtering by severity, source, and event ID is supported.
• Endpoint — typically opc.tcp://<PLC_IP>:4840. Requires OPC-UA enabled in AR configuration and a user account with sufficient permissions.

13. SDM Configuration Without Automation Studio

13.1 Checking if SDM Is Enabled via FTP

When you cannot use Automation Studio, check SDM status by inspecting configuration files via FTP:

1. Connect: ftp <PLC_IP> (default credentials vary; common: admin/admin or no auth on older firmware).
2. Navigate to configuration directories (e.g., /System/Config/, /CF/).
3. Look for files controlling web server and SDM: Config.ini (may contain [WebServer] with Enabled=1), SysConfig.xml (XML configuration), BRSystemConfig.cfg (B&R proprietary).

ftp 192.168.1.10
ftp> cd System/Config
ftp> get Config.ini
ftp> get SysConfig.xml
ftp> bye

13.2 Enabling SDM by Modifying Configuration on CF Card

If SDM is not enabled, it may be possible to enable it by modifying configuration files:

In Config.ini — add or modify:

[WebServer]
Enabled=1
Port=80
[SDM]
Enabled=1

In SysConfig.xml — set the enabled attribute:

<WebServer Enabled="true" Port="80">
  <SDM Enabled="true" />
</WebServer>

After modification: upload the file via FTP, restart the controller (cold boot is most reliable), and verify at http://<PLC_IP>/sdm.

13.3 What Configuration Files Control SDM and Web Server

Exact file names and locations vary between AR versions. V3.x uses primarily .ini/.cfg; V4.x uses more XML. Inspect the file system via FTP to determine what is present.

13.4 Risks of Modifying Configuration Files Manually

Modifying configuration files directly on the CF card bypasses all validation that Automation Studio performs. Key risks:

• Syntax errors — an incorrectly formatted INI or XML file may cause the controller to fail to boot or refuse to start services.
• Encoding issues — configuration files must use ASCII or ISO-8859-1. Editing on Windows may introduce BOM markers or CRLF line endings the controller cannot parse.
• File permissions — modifying files via FTP may change permissions, preventing the runtime from reading them.
• No validation — invalid port numbers or misspelled settings are silently ignored or cause unpredictable behavior.
• Recovery difficulty — if the modified configuration prevents boot, recovery requires a known-good CF card image or Automation Studio (which may also fail to connect).

Mitigation: always back up the original file first, make one change at a time, keep a record of changes, and have a recovery plan (known-good CF card image or B&R support contact). Prefer Automation Studio’s “Upload from PLC, Modify, Download” workflow whenever possible.

14. Key Findings Summary

• SDM is built into Automation Runtime V3.0+ and requires no additional software to access.
• Web-based access at http://<PLC_IP>/sdm from any browser — no project file, no Automation Studio, no documentation needed.
• System logbook is the primary diagnostic tool for understanding controller faults.
• Task Monitor reveals task cycle times and loads — critical for diagnosing watchdog timeouts (error 9210).
• System dumps (.tar.gz) can be exported from SDM and analyzed offline in Automation Studio Logger (Ctrl+L → Load Data).
• Logger requires a project to be open — use a dummy project if the real project is unavailable.
• ANSL default port 11169 is required for Automation Studio and PVI communication — separate from SDM’s HTTP port 80.
• Common error codes include 8021 (config error), 8099 (general), 9204 (temperature shutdown), 9210 (watchdog/reset), and others documented in Section 6.
• Temperature shutdown (9204) is a critical physical fault — always check ventilation and cooling before restarting.
• SDM configuration (web server + SDM enabled) must be set in the AR configuration — if not already enabled on the target controller, you need Automation Studio to enable it.

15. Security Vulnerabilities in SDM

CVE-2025-3450 — SDM Denial-of-Service (Improper Resource Locking)

All CP1584 systems running AR 4.x are affected. An attacker who can reach port 80/443 can crash the entire controller by sending a specially crafted message to the SDM web interface. This is not theoretical — B&R discovered it through internal security testing.

Mitigations (for systems that cannot update to AR R4.93):

1. Disable SDM in the Automation Studio project if not actively needed for maintenance. AR Help GUID: 1d915d67-07f7-4034-a472-c204b5cabbfe
2. Enable HTTPS with mutual TLS (mTLS) — in AS project, option “Validate SSL communication partner” (GUID: 01ced6c0-28ef-4aaa-bd05-2442b971859c). Note: mTLS also affects other web applications using the AR webserver (mapp View, etc.)
3. Restrict webserver access to trusted IPs using the AR host-based firewall (GUID: 75b8994b-f97a-4e0f-8278-43c2a737e65f)
4. Block port 80/443 at the network firewall except during active maintenance windows
5. Never expose SDM to the internet or untrusted networks

CVE-2022-4286 — SDM Reflected XSS

Mitigation: Update to AR R4.93. On older versions, avoid clicking untrusted links while authenticated to SDM.

CVE-2025-3449 — SDM Session Takeover (Predictable Session ID)

Practical implications: Since SDM on older AR 4.x versions has no authentication, the predictable session ID means an attacker could hijack a maintenance engineer’s active SDM session. However, B&R notes SDM does not currently process session-specific data, so the practical impact is limited.

Mitigation: Block SDM access at the network firewall when not actively debugging. Never access SDM over untrusted networks. See ar-rtos.md Section 14.15 for full details.

CVE-2025-3448 — SDM Reflected XSS (New, Distinct from CVE-2022-4286)

Note: This is a separate vulnerability from CVE-2022-4286 (which was patched in R4.93). CVE-2025-3448 remains unpatched on all AR 4.x versions.

Mitigation: Do not click untrusted links while authenticated to SDM. Deploy a Web Application Firewall (WAF) to filter reflected XSS attempts. Never follow hyperlinks to SDM from emails, social media, or messaging apps.

CVE-2025-11498 — SDM CSV Injection

Mitigation: Never use hyperlinks from untrusted sources to access SDM. If you export CSV diagnostic data from SDM, verify the URL was manually typed. Open CSV files from untrusted sources in a text editor first, not directly in Excel.

CVE-2021-22275 — AR Webserver Buffer Overflow (Stops Cyclic Program)

Distinct from CVE-2025-3450 (which targets SDM specifically), this older vulnerability targets the AR webserver more broadly. On affected AR 4.x versions, any HTTP request to port 80 can potentially crash the cyclic program.

SDM Security Recommendations Summary

See ar-rtos.md Section 14 for the complete vulnerability catalog and cp1584-forensics.md for the forensic workflow with security considerations.

16. B&R Automation Academy SDM Learning Content (2026)

In March 2026, B&R released a free microlearning module for the System Diagnostics Manager (SDM) as part of the Automation Academy. This is specifically targeted at end users and service engineers who need quick, reliable diagnostic insights without deep Automation Studio knowledge.

What it covers:

• How to navigate the SDM web interface
• Reading and interpreting the system logbook
• Task monitor usage for performance diagnostics
• I/O module status interpretation
• Creating and downloading system dumps
• Common error code identification

Access: Free through the B&R Automation Academy. Search the B&R Community for “Learning Content for End Users and Service Engineers: SDM” or visit the Automation Academy portal.

Relevance for undocumented machine maintainers: If you are new to B&R systems (inheriting a machine from a defunct OEM), this free training module is an efficient way to learn SDM without needing an Automation Studio license or B&R service contract. It complements this document by providing structured, vendor-approved training material.

Related: B&R also released a “Service & Diagnostics” training track in 2026 covering broader diagnostic techniques. See community.br-automation.com/t/release-2026-new-training-service-diagnostics/11444.

Key Findings

1. SDM is the central diagnostic hub for B&R systems. It aggregates hardware status, task monitoring, IO state, logbook entries, alarm events, and firmware information into a single web-based interface accessible from any browser.

2. SDM is accessible without Automation Studio. The built-in web server (default port 80/443) provides full diagnostic access to any device on the network — no project files, no AS license, and no OEM credentials required.

3. The SDM logbook is the primary forensic data source. Every AR boot, error, warning, and configuration change is timestamped and stored in the logbook. Bulk export via FTP provides the raw material for post-mortem analysis.

4. SDM has known security vulnerabilities. Multiple CVEs affect the SDM web interface (reflected XSS, DoS, authentication weaknesses). On isolated networks this is manageable; on connected networks, the SDM port should be firewalled.

5. Hardware tree in SDM reveals the complete system topology. The hardware tree shows every module, its status, firmware version, and connection path. For undocumented machines, this is the fastest way to map out what hardware is installed.

6. Task Monitor data correlates directly with execution-model.md. SDM shows real-time task cycle times, jitter, and watchdog status — making it the operational complement to the theoretical execution model documentation.

17. Cross-References

Document generated for undocumented CP1584 maintenance scenarios. Verify all procedures against the specific controller firmware version in your environment.