B&R Automation Runtime Firmware Architecture: Program Storage, Boot Sequence, and Firmware Updates

Overview

This document covers the firmware architecture of B&R Automation Runtime (AR) as it applies to the X20CP1584 and related X20 CPU platforms. It details where programs and the operating system are stored, how the boot sequence works, how memory is organized, and how firmware updates are performed — all critical knowledge for maintaining machines built by defunct OEMs with zero documentation.

CP1584 Hardware Specifications

The X20CP1584 (B&R ID code: 0xC370) is based on an Intel Atom E640T processor clocked at 600 MHz with the following key memory resources:

The CPU is fanless, with overtemperature shutdown at 110°C processor / 95°C board temperature. Operating temperature range: -25°C to +60°C (horizontal), -25°C to +50°C (vertical).

Power consumption: 8.6 W (without interface modules/USB).

Recommended CompactFlash Cards

B&R certifies specific CF cards — using generic consumer cards is a common source of failures. B&R creates 4 partitions on CF cards, and consumer cards often lack the controller needed to maintain separate partitions.

Critical note: Only use B&R-certified CF cards. Off-the-shelf consumer CF cards frequently fail to work in B&R controllers because B&R’s partitioning scheme (4 partitions) is not supported by most consumer card controllers.

The Operating System: VxWorks-Based Automation Runtime

B&R Automation Runtime is based on VxWorks, the Wind River real-time operating system. This was confirmed directly by B&R on their community forum. B&R has developed substantial custom layers on top of VxWorks:

• Task class scheduling (B&R’s cyclic execution model)
• IEC 61131-3 runtime (execution of ladder, ST, FBD, etc.)
• Hardware abstraction layers for all B&R bus systems (X2X, POWERLINK)
• I/O driver subsystem with the integrated I/O processor
• Memory management tailored to PLC operation
• File system for the CompactFlash card
• Networking stack including POWERLINK, OPC-UA, Ethernet/IP, etc.

For newer B&R industrial PCs, a bare-metal hypervisor allows a GPOS (typically Linux) to run alongside AR on the same hardware. However, the CP1584 is a pure PLC controller and runs AR as its sole operating system.

See also: ar-rtos.md for deeper RTOS internals.

Memory Architecture

The B&R memory model has several distinct regions, each with specific persistence and boot behavior:

System ROM

The Automation Runtime operating system itself is stored in System ROM on the CompactFlash card. This is the firmware/RTOS that gets loaded on boot. It is non-volatile (stored in flash).

User ROM

User ROM is memory on the CompactFlash card where all compiled B&R modules (*.BR files) for the Automation Studio project are stored. This includes:

• Compiled IEC 61131-3 program code
• Configuration data
• Hardware configuration
• I/O mapping

User ROM is non-volatile. Programs persist across power cycles.

User RAM

User RAM uses the 1 MB battery-backed SRAM on the CPU board. It holds:

• Runtime variable data
• Intermediate calculation results
• Temporary buffers

Size: 1 MB total minus whatever is configured for remanent variables. This is volatile to the extent that it depends on battery backup.

FIX-RAM

FIX-RAM is a configurable portion of User RAM that persists across cold restarts. It behaves like User ROM during a cold restart while still residing in SRAM. Objects in FIX-RAM survive cold restarts, making it ideal for:

• Process parameters and setpoints
• Calibration data
• Recipe data
• Runtime counters
• Operator configuration changes

FIX-RAM is configured in Automation Studio under Hardware Configuration > Memory Configuration. The UserRAM size + RemMem size must not exceed available memory.

Remanent Variables

A separate configurable area (up to 256 kB on CP1584) for variables that must survive power loss. Backed by the lithium battery. The battery also buffers:

• User RAM
• System RAM
• Real-time clock

Battery Backup

The CP1584 uses a Renata CR2477N lithium battery (3V, 950 mAh, B&R part number 4A0006.00-000). Battery replacement interval: 4 years. If power is off, battery must be swapped within 1 minute to prevent data loss.

Battery status is available via:

• The BatteryInfo system library function
• CPU I/O mapping (status bits)
• LED indicator: DC LED turns red when backup battery is empty

Memory Persistence Summary

CF Card Partition Layout

B&R CompactFlash cards are divided into 4 partitions created by the B&R file system driver. The partition names and their roles are:

Partition Creation via CFCreatePart

The partitions are created using the CFCreatePart command in the PIL (Program Installation List) file. The community has documented the syntax:

CFCreatePart "HD0", "4",
    "20, 'SYSTEM'",     /* 20% of card → AR OS */
    "30, 'DATA1'",      /* 30% of card → User ROM (compiled .BR modules) */
    "30, 'DATA2'",      /* 30% of card → Config and runtime data */
    "20, 'USER'"        /* 20% of card → FTP-accessible user partition */

The percentages define relative partition sizes. Notably, RUC (Runtime Utility Center) cannot repartition an existing CF card — if a USER partition was never created, RUC cannot add one later. Only Automation Studio or a fresh CF card creation can establish all four partitions.

Source: B&R Community — USER partition not creating thread (2024), confirmed by B&R staff.

What Each Partition Contains

SYSTEM (A:):

• The complete Automation Runtime OS binary
• Version-specific system libraries and drivers
• FPGA bitstream for the X2X bus controller and I/O processor
• Boot loader and POST (Power-On Self-Test) firmware
• Not directly browseable by users; accessed via FTP as the “System” volume

DATA1 (C:):

• All compiled user program modules (*.BR files) generated by Automation Studio
• Hardware configuration compiled binaries
• Library modules (AsIO, AsTCP, AsUDP, mapp components, etc.)
• The module directory structure mirrors the AS project Logical View
• When AR boots, it loads all .BR files from this partition into DRAM

DATA2 (D:):

• Runtime configuration data (network settings, task configuration)
• Persistent and remanent variable storage areas
• System dump files and diagnostic data
• Calibration and parameter data

USER (F:\):

• Standard FAT16/FAT32 file system accessible via FTP
• Log files from the AR Logger
• User-created files (from AsFile library operations)
• System dump exports
• Occasionally the original Automation Studio project (.apj, .acp) if the OEM stored it here
• Configuration backups and recipe files
• This is the most valuable partition for forensic analysis of an undocumented machine

Accessing the CF Card

Important: The user partition is often where you’ll find the most valuable undocumented data — log files, recipes, and sometimes even the original Automation Studio project source files. Always check the user partition via FTP first when working with an unknown machine.

CF Card Imaging Procedure

To create a complete backup of a B&R CF card for forensic analysis or disaster recovery:

# Method 1: Runtime Utility Center (GUI)
# Tools > Back up files from Compact Flash / Image file...
# Produces .zp2 or .zp3 image file

# Method 2: Raw sector copy via Linux (remove CF card from PLC)
dd if=/dev/sdX of=cp1584_backup_YYYYMMDD.img bs=512 status=progress
# Replace /dev/sdX with actual device (check with lsblk first)
# This captures ALL partitions including System ROM

# Method 3: Mount individual partitions after imaging
fdisk -l cp1584_backup_YYYYMMDD.img  # Show partition table
# Mount partition N:
mount -o loop,offset=$((START_SECTOR * 512)) cp1584_backup_YYYYMMDD.img /mnt/partN

Boot Sequence

The CP1584 boot sequence is a multi-stage process. Understanding each stage is critical for diagnosing boot failures.

Stage 0: Power-On and Hardware Init

1. Power applied to 24 VDC input
2. Internal power supply initializes (CPU/X2X Link supply + I/O supply, galvanically isolated)
3. Hardware self-test runs (RAM check, basic FPGA validation)
4. If a fatal hardware error is detected, the system halt error code is displayed on the S/E LED
5. The CPU enters BOOT mode if:
   • Operating mode switch is in BOOT position, OR
   • No CF card is inserted, OR
   • CF card is unrecognized/invalid

Stage 1: Bootloader

The CPU contains a factory-programmed bootloader (in internal ROM/FPGA). This bootloader:

1. Reads the operating mode switch position:
   • BOOT → Launch minimal “Boot AR” runtime
   • RUN → Proceed to load full AR from CF card
   • DIAG → Boot in diagnostic mode (User RAM/Flash not initialized)
2. In BOOT mode: only the RS232 interface is active, allowing firmware download via INA2000 protocol
3. The R/E LED behavior during boot:
   • Green blinking → System startup (initializing application, bus systems, I/O)
   • Green double flash → BOOT mode (during firmware update)
   • Green solid → Application running
   • Red solid → SERVICE mode

Stage 2: Automation Runtime Load

When mode switch is in RUN with valid CF card:

1. AR kernel loads from System ROM partition on CF card
2. VxWorks kernel initializes:
   • Memory subsystem (DDR2, SRAM)
   • Interrupt controller
   • Timer subsystem
   • Task scheduler
3. B&R’s custom layers initialize:
   • I/O processor
   • X2X bus enumeration
   • POWERLINK stack
   • Ethernet interface
   • File system
   • OPC-UA server (if configured)
   • System diagnostics (SDM)

This stage can take several minutes depending on the complexity of the configuration (number of I/O modules, bus topology, etc.).

Stage 3: Application Load

1. Compiled modules (*.BR files) are loaded from User ROM (DATA1 partition) into DRAM
2. Global variables are initialized from their persistent data (User ROM / FIX-RAM / remanent)
3. Hardware configuration is applied:
   • I/O module mapping
   • Interface module configuration
   • Network configuration (IP addresses, POWERLINK node assignments)
4. I/O modules are enumerated and initialized via X2X bus

Stage 4: I/O Enumeration and Initialization

1. X2X Link master on the CPU discovers all connected X2X bus modules
2. Each I/O module is identified and its configuration loaded
3. Analog modules perform calibration checks
4. I/O data images are mapped into the CPU’s address space
5. POWERLINK network is established (if configured as MN):
   • PRE_OPERATIONAL_1 → configure CNs
   • PRE_OPERATIONAL_2 → start cyclic communication
   • READY_TO_OPERATE → PDO data active
   • OPERATIONAL → cyclic data evaluated

Stage 5: Task Class Startup

1. Task classes are started according to their priority and configuration
2. IEC 61131-3 programs begin cyclic execution
3. Watchdog timers are armed
4. PLC transitions to RUN state (R/E LED solid green)

Boot Timing Indicators

If the PLC has been running for more than 5 minutes with R/E still blinking green, suspect a hardware problem (bad CF card, failed I/O module, X2X bus fault). See cf-card-boot.md for detailed CF card boot analysis.

See also: execution-model.md for details on task class scheduling.

Operating Modes

The CP1584 has a physical operating mode switch with three positions:

BOOT Mode

• Switch position: BOOT
• CPU launches minimal Boot AR runtime
• Only RS232 interface is active
• Allows firmware/OS download via INA2000 protocol
• User Flash is erased when a download begins
• Used for: initial commissioning, firmware recovery, OS updates

RUN Mode

• Switch position: RUN
• Full Automation Runtime loads from CF card
• Application executes
• All interfaces active
• Normal operating mode

DIAG (Diagnostic) Mode

• Switch position: DIAG
• CPU boots in diagnostic mode
• Program sections in User RAM and User FlashPROM are not initialized
• After DIAG mode, the CPU always boots with a warm restart
• Used for: diagnosing application issues without running the program

SERVICE Mode

• Not a switch position — entered automatically on errors or reset
• No task classes running
• Application program halted
• All outputs set to zero
• Used for: online debugging, firmware upload, error diagnosis

Reset Button Behavior

The reset button (bottom of housing, requires pointed object) triggers:

1. All application programs stopped
2. All outputs set to zero
3. PLC enters SERVICE mode by default
4. The post-reset startup mode can be configured in Automation Studio

Restart Types

Cold Restart (INIT)

• Full OS reload
• All RAM data deleted (except FIX-RAM)
• Programs reload from flash
• Equivalent to first-time initialization
• Triggered by: mode switch changes, firmware updates, explicit cold restart command
• Use when: RAM corruption suspected, memory config changed, firmware updated

Warm Restart

• OS continues running
• All RAM data preserved
• Programs continue from current state
• Variables retain their current values
• Typical power-cycle behavior (with good battery)

Hot Restart

• Same as warm restart but faster
• Used when switching between configurations

Firmware Update Mechanism

Method 1: Automation Studio — Transfer Operating System

1. Insert CF card and power on CPU
2. Establish online connection (Ethernet, RS232, or POWERLINK)
3. In Automation Studio: Project > Services > Transfer Operating System…
4. Select runtime system version (pre-selected from project settings)
5. Choose whether to download modules with SYSTEM ROM target memory
6. Download proceeds — User Flash is cleared
7. When complete, set mode switch to RUN and reset CPU

For initial download (CPU with no OS on CF card):

• Must use RS232 connection only (INA2000 protocol)
• CPU must be in BOOT mode

Method 2: PVI Transfer Tool (Automated/Scripted)

1. In Automation Studio: Tools > Generate Transfer List
2. Select “Generate complete transfer list”
3. Activate “Include operating system”
4. Use Tools > PVI Transfer Tool to execute the transfer
5. Can create CF card from existing project for mass deployment

Method 3: Runtime Utility Center (RUC)

RUC can:

• Create CompactFlash cards from Automation Studio projects
• Back up entire CF cards as image files (.zp2, .zp3)
• Restore CF cards from image files
• Create user partitions
• Cannot repartition an existing CF card — if no User partition exists, it won’t create one

Method 4: CF Card Imaging (for Clone/Fleet Deployment)

# Create CF card from a known-good image
dd if=cp1584_gold_image.img of=/dev/sdX bs=512 status=progress

This is the most practical method when you don’t have Automation Studio:

1. Image a known-good CF card from a working machine
2. Write that image to a new B&R-certified CF card
3. Swap into replacement hardware

Firmware Downgrade Considerations

• Not all firmware versions support downgrading
• B&R provides compatibility matrices
• Some AR versions require minimum hardware revisions for certain interface modules
• Always verify compatibility before changing firmware versions

INA2000 Protocol: Serial Firmware Transfer

The INA2000 protocol is B&R’s original serial communication protocol, used for firmware transfer via RS232 when no Ethernet connection exists.

When INA2000 Is Required

1. Initial CPU commissioning — brand new CPU with no OS on CF card must use RS232 + INA2000 for the first firmware transfer
2. BOOT mode communication — when the mode switch is in BOOT position and no Ethernet is available
3. Emergency recovery — when the Ethernet interface is misconfigured or the CF card is corrupted
4. Legacy systems — older B&R controllers that predate Ethernet online interfaces

INA2000 Transfer Parameters

INA2000 vs ANSL (Modern) Protocol

The /DA=02 flag in PVI connections selects the INA2000 data access protocol explicitly. B&R’s modern ANSL (Automation Network Service Layer) supersedes INA2000 for all normal operations.

Serial Transfer Procedure

1. Connect RS232 cable: CPU pin 1 (RX) → PC TX, CPU pin 2 (TX) → PC RX, CPU pin 3 (GND) → PC GND
2. Use a null-modem cable or cross-wired connections (the CP1584 pinout is DCE-like)
3. Set terminal/emulation software to 57600, 8-N-1, no flow control
4. Set the CPU mode switch to BOOT
5. Power on the CPU — R/E LED shows red, RDY/F shows yellow (BOOT mode)
6. In Automation Studio: Online > Settings > Transfer Settings, select Serial, COM port, 57600 baud
7. Online > Settings > Auto Search — the PLC should appear with its INA2000 station address
8. Transfer Operating System — download AR to the CF card via serial

Source: B&R Community — INA2000 protocol discussions, PLCtalk — serial connection guides

Automation Studio and AR Version Compatibility

The CP1584 has specific version compatibility requirements that must be observed:

Minimum Software Versions for CP1584

AR Embedded Version Availability (from B&R Downloads)

AS Version to AR Version Mapping

Critical: The CP1584 cannot run AR 6.x. AR 6.x requires Intel Core i processors (APC910, APC3200) or specific newer X20 CPUs. The CP1584 is limited to AR 4.93 as its maximum runtime version.

Interface Module Hardware Upgrades

Some X20 interface modules require a hardware revision upgrade when moving from older CP1484 CPUs to the CP1584. The minimum hardware revision is documented in the data sheet:

Source: X20CP158x Data Sheet V1.56, B&R Community upgrade discussions

PIL File Format and PVI Transfer

What Is a PIL File?

A PIL (Program Installation List) file is a text-based manifest that describes exactly what gets transferred to the CF card during a firmware or application update. It is generated by Automation Studio and consumed by the PVI Transfer Tool or Runtime Utility Center.

PIL File Structure (Key Commands)

; Example PIL file for CP1584 firmware + application installation

Target="X20CP1584"

; Partition creation (fresh CF card only)
CFCreatePart "HD0", "4",
    "20, 'SYSTEM'",
    "30, 'DATA1'",
    "30, 'DATA2'",
    "20, 'USER'"

; Installation mode
InstallMode=ForceInitialInstallation    ; Wipes existing data
; InstallMode=Update                   ; Preserves user data

; Transfer individual files
CFWrite "A:\System\arcore.bin"          ; AR kernel
CFWrite "C:\Modules\MyProgram.br"       ; Compiled program
CFWrite "C:\Modules\AsIO.br"           ; Library module
CFWrite "C:\Modules\AsArProf.br"       ; Profiler library
CFWrite "D:\Config\System.par"         ; System parameters

PVI Transfer Tool

The PVI Transfer Tool (pvitransfer.exe) automates firmware and application deployment:

1. Automation Studio → Tools → Generate Transfer List — creates the .pil file
2. Automation Studio → Tools → PVI Transfer Tool — executes the transfer list against target PLCs
3. Can target multiple PLCs simultaneously (fleet deployment)
4. Works over Ethernet (ANSL) or serial (INA2000)
5. Requires the PLC to be in BOOT mode for initial installations
6. For updates to existing installations, RUN mode is sufficient (online changes)

Runtime Utility Center (RUC)

RUC is a standalone tool (does not require full Automation Studio installation):

1. Install from B&R downloads page (free, no AS license required)
2. Load a .pil file generated by Automation Studio
3. Connect to target PLC (requires knowing IP address or using serial)
4. Execute offline installation to CF card or live transfer to PLC

RUC capabilities:

• Create CF cards from PIL files (offline, requires CF card reader)
• Transfer firmware and applications over network or serial
• Cannot repartition existing CF cards — only Automation Studio can do this
• Can update firmware on PLCs already running AR

RUC limitations:

• Less capable than full Automation Studio for browsing project structure
• Cannot change PLC IP address or auto-discover PLCs on network
• In BOOT mode without DHCP, requires manual IP configuration

Source: B&R Runtime Utility Center documentation, B&R Community RUC discussions

B&R Product Lifecycle and CP1584 Status

The Four Lifecycle Phases

X20CPx58x Discontinuation

B&R announced the discontinuation of the X20CPx58x CPU series (which includes the CP1584) via Service Note SN 2022/54 due to component discontinuation:

• Last-Time-Buy date: February 28, 2023
• Reason: Semiconductor component supply chain discontinuation (Intel Atom E6xx series becoming obsolete)
• The CP1584 has entered the Limited or possibly Obsolete phase as of 2025–2026

Practical Implications for Maintaining CP1584 Machines

1. No new CP1584 units available from B&R. All spare CPUs must come from secondary market, surplus, or refurbished stock.
2. CF cards are still available — B&R continues to sell CF cards and software. The 8 GB SLC cards (5CFCRD.8192-06) are current products.
3. AR 4.93 continues to receive security patches — B&R’s patching policy for AR 4.x (see CVE data in ar-rtos.md) shows ongoing security advisories covering AR 4.93.
4. Interface modules and I/O modules remain available — the X20 ecosystem (I/O modules, bus couplers, interface modules) continues in Active or Classic status.
5. Migration path: B&R recommends X20CP1684 (Intel Atom E680T, 1 GHz) as the direct replacement, or X20CP0484-1 for cost-sensitive applications. See remanufacturing.md for full migration analysis.

Source: B&R Lifecycle Policy page, Service Note SN 2022/54, B&R downloads page

Firmware File Types on the CF Card

Files in the SYSTEM Partition (A:)

The exact file names vary between AR versions. These files are not directly human-readable and are loaded by the CP1584’s internal boot ROM.

Files in the DATA1 Partition (C:)

The directory structure on C: mirrors the Automation Studio Logical View. Modules are loaded in a specific order determined by the project configuration.

Files in the USER Partition (F:)

See config-file-formats.md for detailed format descriptions of .apj, .acp, and other configuration files.

FPGA and the Integrated I/O Processor

The CP1584 contains an FPGA (Field Programmable Gate Array) that handles critical real-time functions independently of the main CPU:

FPGA Functions

FPGA Programming

The FPGA bitstream is part of the AR installation in the SYSTEM partition. When AR is updated, the FPGA bitstream is also updated. This is why firmware updates can take several minutes — the FPGA must be reconfigured without disrupting ongoing operations.

If the FPGA fails to program (System Halt error: •−−− •−−−), the CPU module must be replaced. There is no user-accessible mechanism to reprogram the FPGA independently.

Automation Runtime Security Patching on CP1584

See ar-rtos.md Section 14 for a comprehensive list of CVEs affecting AR 4.x on the CP1584. Key points:

Patch Status Summary

Recommendation: Update to AR 4.93 immediately if not already at this version. It patches the most critical DoS vulnerabilities. Accept that some older CVEs cannot be patched on the CP1584 platform and mitigate via network isolation.

See access-recovery.md Section 14.19 for recommended firewall rules for an AR 4.93 CP1584.

LED Diagnostics During Boot

System Halt Error Codes (S/E LED Red Blinking)

Error codes are displayed as 4 phases of 150ms (short) or 600ms (long) LED on-times, repeated every 2 seconds:

Legend: • = 150ms on, − = 600ms on, 2s pause between repetitions.

Practical Procedures for the No-Documentation Scenario

Determining What Firmware is Running

Without Automation Studio:

1. FTP to the PLC — check user partition for version info files, log files may contain AR version
2. OPC-UA browse — some system nodes expose firmware version
3. AR log analysis — the PLC logbook often records firmware version on boot
4. Web interface (if enabled) — may show system info
5. PVI API — connect and query system variables

Backing Up a CF Card Without Automation Studio

## Remove CF card from PLC (power off first!)
## Insert into USB CF reader connected to Linux PC
lsblk  # Identify the CF card device
dd if=/dev/sdX of=cp1584_backup.img bs=512 status=progress conv=noerror,sync
## Verify backup
md5sum cp1584_backup.img
## Mount user partition to inspect
fdisk -l cp1584_backup.img
mount -o loop,offset=$((SECTOR*512)),ro cp1584_backup.img /mnt/cf_user
ls -laR /mnt/cf_user

Creating a Replacement CF Card Without Original Project

1. Take a raw image backup of a known-good CF card from a working identical machine
2. Write image to a new B&R-certified CF card of the same or larger capacity
3. Boot the replacement PLC with this CF card
4. If hardware differs (different I/O modules), the configuration will need adjustment — see project-reconstruction.md

What to Do When the CF Card Fails

1. PLC will enter BOOT mode (R/E LED blinking green)
2. In BOOT mode, only RS232 is active
3. You need either:
   • A backup CF card image to restore, OR
   • Automation Studio with the correct AR version to transfer a new OS, OR
   • A known-good CF card from an identical machine to clone
4. If no backup exists and you don’t have AS: this is when you need project-reconstruction.md

Gotchas and Edge Cases

1. CF card brand matters: B&R-certified cards only. Consumer cards fail silently or during operation. The most common “dead PLC” scenario is a bad CF card.

2. CF card partitioning: B&R uses 4 partitions. Standard formatting tools will destroy this layout. Only use RUC or raw dd to create/restore CF cards.

3. User partition may not exist: If the original project was built without configuring a user partition size, there won’t be one. RUC cannot create one on an existing CF card.

4. Battery drain kills retentive data: If the battery is dead, ALL remanent data, FIX-RAM, and RTC are lost. Check the DC LED (red = battery empty) before powering off a machine.

5. Overtemperature is logged: The PLC logs error 9204 (temperature-triggered restart) and 9210 (watchdog/manual reset) before shutting down. These are recoverable from the logbook.

6. SERVICE mode after reset: Pressing the reset button always enters SERVICE mode by default. This stops the program and zeroes all outputs. If you don’t know this, it looks like the PLC “died.”

7. Firmware version compatibility: X20CPx58x CPUs require Automation Studio V3.0.90.20+. Some X20 IF interface modules require hardware revision upgrades when moving from CPx48x to CPx58x CPUs.

8. USB is NOT an online interface: USB ports on the CP1584 are for peripherals only, not for programming/debugging connections.

9. Boot takes time: Initial boot with complex I/O configurations can take several minutes. Don’t assume the PLC is dead if LEDs are still blinking after 30 seconds.

10. ETHERNET interface is NOT for POWERLINK: The standard Ethernet interface (IF2) must NOT use POWERLINK address range (192.168.100.x). POWERLINK uses its own dedicated interface (IF3).

Automation Runtime Version Landscape (2026)

The AR version landscape has evolved significantly. Understanding what versions exist and their compatibility with the CP1584 is critical for maintenance planning.

Available AR Versions (as of 2026)

AR 6.x — The Next Generation (Not for CP1584)

AR 6 represents a major platform shift. Key changes:

• Base OS migration from VxWorks 5.5 to VxWorks 6.x/7.x — the underlying RTOS is being modernized after decades on the VxWorks 5.5 codebase
• Security hardening — AR 6 patches many CVEs that cannot be patched on AR 4.x (see ar-rtos.md §14 for full CVE table)
• New hardware required — AR 6 does not run on X20CP1484/1584/1684. It targets the newer generation:
  • X20EM (Edge Controllers) — ARM/RISC-V based, designed for IIoT edge computing
  • X20CP3xxx series (e.g., X20CP3586 @ 1.6 GHz, 512 MB RAM) — Intel Atom successor
  • APC9xx (Automation PCs) — full industrial PC platform
• exOS support — AR 6 introduces proper IT/OT integration with Linux running on separate cores alongside the RTOS
• Automation Studio 6.x required — AS 6 is a separate product line from AS 4.x and requires its own license

What This Means for CP1584 Operators

1. AR R4.93 is the end of the line for CP1584. No further AR updates will be released for this hardware platform.
2. Security patching has effectively stopped. The 16+ unpatchable CVEs documented in ar-rtos.md §14 will never be fixed on CP1584.
3. Migration planning should begin now for machines with >5 years remaining service life. See remanufacturing.md for migration strategies.
4. The transition to AS 6 + AR 6 is not a simple upgrade — it requires new hardware, new AS licenses, and project porting. Budget accordingly.
5. B&R’s VxWorks 6/7 migration kits (1SWARVXW6, 1SWARVXW7) suggest they are actively transitioning their entire product line to a modern RTOS base, which will further widen the capability gap between legacy CP1584 and current-generation hardware.

Key Findings

• The CP1584 runs B&R Automation Runtime, a VxWorks-based RTOS with extensive B&R custom layers for PLC operation
• All application memory is on CompactFlash — the CPU contains no onboard flash for user programs
• CF card uses 4 proprietary partitions: System ROM, User ROM, User partition (FTP-accessible), and reserved
• Memory hierarchy: System ROM (OS) → User ROM (compiled programs) → User RAM (runtime data) → FIX-RAM (persistent parameters)
• Battery-backed SRAM retains remanent variables, User RAM, and RTC; battery is a Renata CR2477N with 4-year replacement interval
• Boot sequence: Hardware init → Bootloader → AR kernel load → Application load → I/O enumeration → Task class startup
• Three operating modes via physical switch: BOOT (firmware download), RUN (normal operation), DIAG (diagnostic)
• CF card failures are the most common cause of “dead” CP1584s — always image the CF card before doing anything else
• Raw dd imaging is the most reliable backup method when Automation Studio is unavailable
• AR R4.93 is the final firmware for CP1584 — no further AR 4.x updates will be released, and 16+ security CVEs remain unpatched on this platform
• AR 6 requires new hardware (X20EM, X20CP3xxx, APC9xx) — the VxWorks base is migrating from 5.5 to 6.x/7.x, and the CP1584 cannot run AR 6
• Automation Studio 6 is required for AR 6 targets — AS 6 is a separate product from AS 4.x and needs its own license

Sources

• B&R X20CP1584 Data Sheet V1.56 — hardware specifications, memory resources, and operating conditions
• B&R X20 System User’s Manual — boot modes, operating mode switch, and CF card handling
• B&R Automation Runtime Overview (TM213) — AR architecture, task configuration, and memory management
• B&R Community Forum (community.br-automation.com) — firmware, CF card, and boot sequence discussions
• B&R Knowledge Base — firmware update procedures and recovery methods

Related Documents

• cf-card-boot.md — Detailed CF card partition structure, file types, and boot stages
• bootloader-recovery.md — Recovery procedures for corrupted CF cards and bricked CPUs
• firmware-version-mgmt.md — Version management without OEM access
• ar-rtos.md — Automation Runtime OS internals, VxWorks base, and security vulnerability history
• config-file-formats.md — Configuration file formats on the CF card (.apj, .acp, etc.)
• retentive-data.md — Battery-backed SRAM and retentive data management
• cp1584-hardware-ref.md — CP1584 hardware specifications, LED meanings, and physical interfaces
• execution-model.md — Task scheduling, cycle times, and watchdog behavior
• access-recovery.md — Password recovery and BOOT mode access procedures
• remanufacturing.md — Migration from CP1584 to newer B&R hardware
• spare-parts.md — Sourcing B&R replacement hardware
• network-architecture.md — Network topology and interface configuration
• program-reverse-engineering.md — Analyzing compiled .BR module files
• cp1584-forensics.md — Extracting information from an unknown CP1584
• online-changes.md — Runtime patching and parameter modification
• diagnostics-sdm.md — System Diagnostics Manager for error logging
• ftp-web-interface.md — FTP and web server for remote file access
• cybersecurity-hardening.md — Security posture for legacy AR 4.x systems

B&R Execution Model: Cyclic Task Scheduling, IEC 61131-3 Semantics, and Watchdog Behavior

Overview

B&R Automation Runtime uses a deterministic, priority-based preemptive multitasking system built on VxWorks. Programs written in IEC 61131-3 languages (Ladder Diagram, Structured Text, Function Block Diagram, Instruction List, Sequential Function Chart) and ANSI C are executed in cyclically-repeating task classes with configurable priorities and cycle times. Understanding this model is essential for diagnosing timing-related bugs, cycle time violations, and SERVICE mode entries on undocumented machines.

Priority System

Automation Runtime uses a deterministic, priority-based preemptive multitasking system built on a real-time operating system (RTOS) derived from VxWorks. B&R does not publicly document the exact RTOS version or whether it uses a licensed Wind River VxWorks kernel or a B&R-developed RTOS, but the scheduling behavior is consistent with VxWorks’s priority-based preemptive scheduler with a hardware timer tick interrupt driving context switches.

B&R uses a priority range of 0 to 255, where higher numbers have higher priority. When multiple tasks want to run simultaneously, the higher-priority task always runs first. The RTOS tick timer (configurable, typically 1 ms) drives the scheduler’s periodic evaluation of task readiness.

The priority space is divided into four tiers:

Scheduler Internals

The RTOS scheduler uses a tick-driven, priority-based preemptive algorithm:

1. Timer tick interrupt fires at the configured system tick rate (typically 1 ms on the CP1584, derived from the Intel Atom HPET or LAPIC timer)
2. The tick ISR runs the scheduler: it checks all ready queues and dispatches the highest-priority ready task
3. Preemption: If a higher-priority task becomes ready (via interrupt or timeout), the currently running task is immediately preempted — even mid-instruction
4. Round-robin within priority: Tasks at the same priority level are scheduled round-robin
5. Time slicing: B&R does NOT use time slicing within a priority level for cyclic tasks. Each cyclic task runs to completion (or until preempted) within its allocated window

The minimum the Task class idle time can be reduced to is your System Tick (base timer for all AR), and the Task class idle time must be a multiple of the system tick. This means on a system with a 1 ms tick, idle time granularity is 1 ms.

Memory Protection

The Intel Atom E640T provides hardware MMU/MPU capabilities, but B&R Automation Runtime uses them with specific scope:

• Kernel/user protection: The MMU protects the AR kernel and system memory from user task access — user tasks cannot corrupt the OS kernel or system structures
• Flat task model: All user tasks (cyclic, event, etc.) share a single flat address space with no task-to-task isolation. A buggy cyclic task CAN corrupt another cyclic task’s data. See ar-rtos.md Section 2.3 for details
• Page faults (accessing unmapped or protected memory) trigger EXCEPTION 7 (address error) or EXCEPTION 25314 (Page Fault) and result in SERVICE mode
• The Exception task class (EXC) has access to all memory spaces for error handling
• The integrated I/O processor uses DMA (Direct Memory Access) to update the I/O image in memory without CPU involvement

Interrupt Handling

Interrupts on the CP1584 follow the VxWorks interrupt model:

When an interrupt fires, the RTOS saves the current task’s context (registers, stack pointer, flags) and jumps to the registered interrupt handler. After the handler completes, the context is restored and the highest-priority ready task resumes.

Task Classes

B&R provides up to 8 cyclic task classes (Cyclic #1 through Cyclic #8), each with:

• A configurable cycle time
• A priority (Cyclic #1 = highest, Cyclic #8 = lowest)
• One or more assigned programs/tasks
• A configurable watchdog tolerance
• A configurable jitter tolerance

Default Cycle Times

The CP1584 has a shortest achievable task class cycle time of 400 µs (hardware limitation).

Task Class Execution Model

Each task class operates as follows:

1. The cycle timer for the task class expires
2. If a higher-priority task class is still running, the current class waits (preemptive priority)
3. All programs/tasks assigned to the class execute sequentially within the class
4. After all tasks complete, the class yields and waits for the next cycle
5. I/O data is updated at specific synchronization points (see I/O Cycle section)

Time →
|---TC#1---|---TC#1---|---TC#1---|---TC#1---|
|   ProgA   |   ProgA   |   ProgA   |   ProgA   |
|----TC#2----|----TC#2----|----TC#2----|
|  ProgB  ProgC |  ProgB  ProgC |  ProgB  ProgC |
|-------TC#3-------|-------TC#3-------|
|   ProgD  ProgE  ProgF  |   ProgD  ProgE  ProgF  |

Jitter Tolerance

Each task class has a configurable jitter tolerance — the allowed deviation from the exact cycle time before an exception is triggered. This is different from the watchdog timeout (which covers total cycle time violations). Jitter tolerance is important for motion control applications where exact timing is critical.

I/O Cycle Synchronization

I/O data exchange is synchronized with the cyclic task system. This is a critical concept that differs from some other PLC platforms:

Synchronizing Tasks with the I/O Cycle

The I/O cycle runs independently and deterministically. Task classes can be configured to:

1. Read inputs at the start of the task class cycle
2. Write outputs at the end of the task class cycle
3. Run synchronized with the I/O bus cycle (X2X, POWERLINK)

When a task class is synchronized to the I/O cycle:

• Input data is read from the I/O image at the start of the cycle
• Logic executes using that input data
• Output data is written to the I/O image at the end of the cycle
• Multiple task classes reading the same inputs see identical input data within one I/O cycle

The Integrated I/O Processor

The CP1584 has a dedicated I/O processor that processes I/O data points in the background. This means:

• I/O scanning runs independently of the main CPU task execution
• The I/O image in memory is continuously updated by the I/O processor
• Cyclic tasks read from a snapshot of the I/O image, not directly from hardware

This architecture provides excellent I/O performance but means that I/O timing is decoupled from task class timing.

Watchdog Behavior

Cycle Time Violations

A cycle time violation occurs when the sum of runtimes of all tasks in a task class exceeds the configured cycle time. This is the #1 cause of SERVICE mode entries (approximately 80% of all SERVICE mode events).

By default, a cycle time violation triggers:

1. A system emergency stop
2. The controller boots in ERROR mode
3. The PLC then enters SERVICE mode
4. All outputs are set to zero
5. The error is logged in the AR logbook

Common Causes of Cycle Time Violations

• Infinite loops in IEC code (most common)
• Blocking I/O operations (e.g., waiting for a response in a cyclic task)
• Excessive computation in a fast task class
• String operations or memory allocation in cyclic code
• File I/O performed in a cyclic task
• Division by zero causing exception handling overhead
• Page faults from invalid memory access

Configuring Watchdog Tolerance

The watchdog tolerance for each task class can be increased to allow occasional overruns without triggering an emergency stop. However, this does not fix the underlying timing problem.

Task Idle Time and System Task Starvation

The Problem

Because cyclic tasks (priority 190–230) have higher priority than system tasks (priority 4–190), a long-running cyclic task class can starve system tasks of CPU time. This causes:

• Visualization updates to become sporadic or freeze
• OPC-UA responses to time out
• Ethernet communication to fail
• SDM data to become stale
• File operations to hang
• USB device discovery to fail

The Solution: Task Idle Time

The Task Idle Time / Idle Time Task Class mechanism reserves a portion of a cyclic task class’s time for system tasks to execute. This is configured in the CPU’s task class properties.

Default configuration:

• Idle Time Task Class: Cyclic #2 (20 ms cycle)
• Task Idle Time: 2 ms (last 2 ms of the 20 ms cycle)

During the idle time window:

• The affected task class is effectively moved to priority 2
• System tasks can run at their normal priority (4–190)
• If no system tasks need to run, TcIdleFiller runs no-ops at priority 3
• Cyclic #1 (and any higher-priority cyclics) still preempt everything

SDM CPU Usage Reporting

The SDM reports CPU usage as: 100% - time spent at priority 0 (IDLE)

This means:

• TcIdleFiller no-ops count as “CPU usage” even though the CPU is doing nothing
• In SERVICE mode with default idle time, CPU usage appears artificially high (~50-60%) when the real usage is near 0%
• Don’t be alarmed by high SDM CPU readings in SERVICE mode — it’s the TcIdleFiller effect

Tuning the Idle Time

Guidelines for tuning without the original project:

1. Minimum idle time: System tick (base timer for AR), must be a multiple of system tick
2. Zero (0 µs) disables idle time entirely (dangerous — can starve all system tasks)
3. Better to have frequent short windows: 2 ms every 20 ms is better than 200 ms every 2000 ms, even though both reserve 10% for background tasks
4. Don’t put idle time in a low-priority task class even if it’s fast — use TC#3 at 50 ms rather than TC#8 at 10 ms
5. The idle time follows the tolerance of its assigned task class — delays cascade if cyclics overrun

Exception Handling

Exception Types

Exception Handling Configuration

The default behavior (emergency stop on cycle time violation) can be changed:

• Exception handling can be configured per task class
• Actions can be: ignore, log only, stop task, or emergency stop
• For production machines from defunct OEMs, it’s often safer to leave defaults (emergency stop) to prevent dangerous behavior from timing errors

Troubleshooting Execution Issues

Diagnosing Cycle Time Violations

1. Check the AR logbook for cycle time violation entries (error codes typically in the 9xxx range)
2. Use the Profiler in Automation Studio to see which task/function block is consuming time
3. Check task class configuration — are cycle times realistic for the hardware?
4. Look for blocking operations in cyclic code:
   • File I/O (FileOpen, FileRead)
   • Network operations (TcpOpen, synchronous communication)
   • WAIT statements or delay loops
   • String operations on long strings

Diagnosing System Task Starvation

Symptoms:

• OPC-UA clients disconnect or time out
• Visualization freezes or updates erratically
• Ethernet communication fails intermittently
• New I/O modules plugged in are not detected
• Web interface becomes unresponsive

Solution:

1. Check Task Idle Time configuration — increase if too small
2. Move idle time to a higher-priority task class
3. Reduce cycle times of lower-priority task classes
4. Look for cyclic tasks that consistently overrun their cycle time

Monitoring Task Execution at Runtime

Without Automation Studio:

1. PVI API — read task cycle time, max cycle time, current load per task class
2. OPC-UA — if exposed, monitor task cycle time nodes
3. System variables — RTInfo function block data (see system-variables.md)
4. AR logbook — check for cycle time warnings/violations
5. SDM — monitor CPU usage, task class load indicators

Using RTInfo Function Block

The RTInfo function block from the BRSystem library provides runtime information about the current task class:

(* In structured text *)
rtInfo_0(enable := TRUE);

// Available outputs:
// rtInfo_0.cycletime  - Current cycle time of this task class
// rtInfo_0.maxcycletime - Maximum cycle time recorded
// rtInfo_0.taskload    - Current load of this task class
// rtInfo_0.tasknumber  - Current task class number

Cycle Time Tolerance and Watchdog Configuration Details

Cycle Time vs. Maximum Cycle Time vs. Tolerance

B&R distinguishes between three related but distinct timing parameters per task class:

The cycle time tolerance is an additional buffer beyond the base cycle time. If the base cycle time is 10 ms and the tolerance is 2 ms, the task class can run up to 12 ms before Exception 144 fires. After the tolerance window expires and the task still hasn’t completed, Exception 145 (maximum cycle time violation) fires.

Critical rule from B&R (AS 4.3.5 SP release notes): If a tolerance is defined that is NOT a multiple of the cycle time, the value is silently ignored — no error is displayed. The tolerance must be a multiple of the cycle time for it to take effect.

Adjusting Tolerance Without the Project

If you have Automation Studio but not the project source, you can still adjust tolerance via online changes:

1. Connect to the PLC with a minimal project
2. Login online
3. Navigate to the target system configuration
4. Locate the task class properties
5. Increase the cycle time tolerance value
6. Apply the online change — this takes effect immediately without stopping the PLC

This is a runtime band-aid only — it does not fix the underlying cause of the cycle time violation. See online-changes.md for the full procedure.

Watchdog Variants

B&R implements two watchdog mechanisms:

1. Task class watchdog — Per-task-class timer that fires if the class doesn’t complete within (cycle time + tolerance). This is the most common.

2. System watchdog — A hardware-level watchdog timer that resets the entire CPU if the RTOS kernel stops responding. This is a safety net for kernel-level hangs (e.g., driver deadlock, hardware fault). The system watchdog cannot be configured from Automation Studio.

If the system watchdog fires, the CPU performs a complete hardware reset — this is different from a SERVICE mode entry. The AR logbook will not contain an entry for this event because the logger didn’t get a chance to write it. A system watchdog reset is indicated by the CPU booting up with no log entry for the previous session.

Community-Sourced Troubleshooting Wisdom

PV_lkaddr() Causing Maximum Cycle Time Violation

A known cause of Exception 145 on B&R systems is the PV_lkaddr() function from the SYS_Lib library. This function is used to obtain the address of a variable for use with PV_xget()/PV_xset() direct memory access. The issue occurs when:

1. An initialization section of a function block calls PV_lkaddr() only once (as intended)
2. But the function block’s instance data is not properly initialized on first scan
3. The call to PV_lkaddr() triggers an expensive name resolution operation
4. This operation exceeds the cycle time tolerance, triggering Exception 145

Fix: If you encounter this pattern in the profiler, check the AR logbook for the specific task class and look for PV_lkaddr references. If you have the source code, add a guard flag to ensure PV_lkaddr() is only called after the task class has completed its first full cycle.

Profiler “Unknown” Cyclic Task

When profiling a PLC with a different version of Automation Studio than what was used to compile the original project, one of the cyclic tasks may appear as “unknown” in the profiler diagram. This is caused by a symbol version mismatch — the profiler cannot resolve function block names from a different AS version. This is not a real problem; it simply means you cannot see the individual function blocks within that task class.

Workaround: Use the same AS version (or the same major version) as the original project to get full profiler resolution. If you don’t know the original AS version, check the AR version on the PLC and install the corresponding AS version.

Tools > Upgrades Stopped Working (July 2026 Known Issue)

As of July 2026, there is an active B&R Community thread titled “Tools - Upgrades stopped working” with 7 responses. The B&R Upgrade Service, which runs as a Windows service and downloads AR firmware packages from B&R’s website, can stop functioning due to:

• Windows firewall changes blocking the service
• TLS certificate updates on B&R’s server
• Antivirus software quarantining downloaded upgrade files
• The service running under LOCAL_SERVICE account without sufficient rights to write to C:\Temp

Fix steps:

1. Delete everything in C:\Temp
2. Restart the PC
3. Start AS explicitly as Administrator
4. Check that the B&R Upgrade Service is running (Windows Services)
5. Try switching the service user from LOCAL_SERVICE to LOCAL_SYSTEM or vice versa
6. If still failing, check C:\Users\<username>\AppData\Roaming\BR\Logging\Data for error logs

Practical Gotchas for Undocumented Machines

1. Cycle time violations are the #1 cause of SERVICE mode. If a CP1584 keeps going into SERVICE mode and you don’t have the project, check the AR logbook first — it’s almost certainly a cycle time violation.

2. Default idle time setup masks problems. If someone moved the idle task class to a very slow cycle (e.g., TC#8 at 100ms), system tasks will respond very slowly, making the PLC appear “sluggish” without any visible error.

3. Task priorities are fixed — you can’t change the priority number. Only the cycle time, jitter tolerance, and idle time are configurable. If the original programmer put a slow operation in Cyclic #1, there’s no way to lower its priority without access to the project.

4. I/O synchronization matters for motion. If a task class handling motion control is NOT synchronized to the I/O cycle, the I/O data read by the motion task may be from a different cycle than expected, causing jerky motion or missed position capture events.

5. SERVICE mode stops ALL tasks. When the PLC enters SERVICE mode, no cyclic tasks run, no I/O is updated, and all outputs are zeroed. The machine literally stops. If outputs must be maintained during debugging, this must be configured in advance (which requires the project).

6. The reset button always enters SERVICE mode by default. Don’t press it during production.

7. CPU usage in SDM is not what you think. The SDM calculates CPU usage as 100% - time_at_priority_0. Because TcIdleFiller runs at priority 3 (not 0), its no-op time counts as “CPU usage”. In SERVICE mode, SDM will show ~50-60% CPU usage when the real usage is near 0%. On a running system, this effect is smaller but still present — the SDM always over-reports by the amount of time spent in TcIdleFiller. A community member measured: SDM reported 95.45% while the actual CPU usage (system tasks + I/O) was only ~37.9%.

8. Don’t put idle time in a low-priority task class even if it’s fast. The idle time follows the tolerance of its assigned task class. Using TC#8 at 10ms means idle time is delayed by any higher-priority cyclic that runs long. Use TC#3 at 50ms instead — the higher priority ensures idle time windows are more predictable.

9. The profiler recording time must be at least 2× the slowest task class cycle. For intermittent faults, use 10+ seconds. If the profiler shows nothing despite cycle time violations, check the filter settings — the offending task class may be excluded.

10. System watchdog resets leave no log entry. If the CPU resets and there’s no log entry for the previous session, a system watchdog reset (kernel hang) is the likely cause. This is a hardware-level reset — the RTOS never got a chance to log anything.

Exception Task Classes (EXC)

Exception task classes handle fatal errors that occur while Automation Runtime is running and cannot be corrected by the OS alone. The EXC task class has the highest priority in the entire system — it interrupts all normal tasks, high-speed tasks, and interrupt tasks.

How Exception Handling Works

1. An exception occurs while a normal task is running
2. The normal task is immediately interrupted (EXC has absolute highest priority)
3. The exception task assigned to EXC executes
4. Processing of normal tasks resumes from the point of interruption

Exception Codes

Configuring Exception Tasks

In Automation Studio, exception tasks are configured per CPU:

1. Right-click CPU → Insert Object → Exception
2. Select the exception type (e.g., “Division by zero”, “TC cycle time violation”)
3. Enable/disable execution of the exception task
4. Assign a program to the exception task class

The EXC task class shares its global data area with Cyclic #1, enabling fast data exchange without PLC-global variables.

Practical note for undocumented machines: If the original project configured custom exception handlers, you won’t know what they do without the source code. The exception codes above are logged in the AR logbook regardless.

Interrupt Task Classes (IRQ)

Interrupt task classes handle asynchronous hardware events (triggered by hardware interrupts). IRQ tasks have higher priority than all normal cyclic tasks, but lower priority than exception tasks.

IRQ Task Characteristics

• Each interrupt-capable module can be assigned its own IRQ task
• The IRQ task is processed each time the corresponding hardware interrupt triggers
• Only available on B&R 2010 systems (X20, X67) — not supported on older B&R 2003/2005 hardware
• Useful for: hardware encoder triggers, high-speed digital input capture, external sync signals

Typical IRQ Sources

Practical note: IRQ tasks are rarely used in standard machine control. If you find IRQ tasks configured on an undocumented CP1584, they’re likely handling high-speed measurement or encoder capture. The exception codes 170 (CAN I/O) and 128 (I/O Exception) are most relevant for IRQ-related diagnostics.

High-Speed Task Classes (HSTC)

High-speed task classes are activated by hardware interrupts rather than by the system scheduler. This provides lower latency and jitter than normal cyclic tasks.

Types of High-Speed Task Classes

Timer HSTC

Timer HSTCs use a dedicated hardware timer to trigger execution. The cycle time is configurable in Automation Studio and independent of the system scheduler. All tasks assigned to a Timer HSTC execute exactly once per cycle.

RIO HSTC

Remote I/O HSTCs are triggered by an interrupt generated at the end of each remote I/O cycle. The configured cycle time is the minimum — if the RIO cycle takes longer, the HSTC starts later accordingly.

Practical note for CP1584: The CP1584 supports Timer HSTCs and RIO HSTCs. The minimum Timer HSTC cycle time is lower than the minimum Cyclic #1 time (400 us). HSTCs are typically used only in specialized motion control or high-speed measurement applications.

Startup Behavior

Boot Sequence and Task Initialization

When the CP1584 powers on:

1. BIOS/Bootloader executes (VxLD loader) — hardware init, memory test
2. Automation Runtime kernel loads — VxWorks starts, drivers initialize
3. System configuration is read from CF card — hardware config, network config
4. INIT phase — all task classes execute their initialization subroutines once
5. TRANSITION to RUN — I/O modules initialize, POWERLINK starts
6. Normal cyclic execution begins — task classes cycle per their configuration

Task Structure: Init vs Cyclic

Every task in a task class has two parts:

In Automation Studio, the initialization part is accessed via View → Init Subroutine.

Startup Modes

The startup mode is configured in the CPU’s task configuration in Automation Studio. On an undocumented machine, the startup mode is unknown — you can determine it by observing whether retentive values survive a power cycle (warm start) or not (cold start). See retentive-data.md for details.

Task Configuration in Automation Studio

Without access to the original project, you cannot change task class configuration. However, understanding what’s configurable helps with diagnostics:

Configurable Parameters Per Task Class

Creating a Task Class

In Automation Studio:

1. Right-click CPU → Insert Object → Cyclic
2. Set name, programming language, priority
3. Configure cycle time, tolerance, jitter
4. Assign programs to the task class
5. Set exception handling behavior

Multicore Task Assignment

On multicore CPUs (CP3586, APC910, etc.), each task class can be assigned to a specific CPU core. The default configuration assigns all cyclic tasks to core 0. For the single-core CP1584, this is the only option.

AR 6.5 hard real-time multicore (released December 2025): Task classes can now be assigned to specific CPU cores via Automation Studio 6.5 — not just system tasks but hard real-time cyclic tasks. This enables deterministic parallel execution of time-critical logic (e.g., motion control on core 0, process logic on core 1). Configuration is available in the task class properties dialog in AS 6.5. AR 6.5 also adds hypervisor repair boot for resolving PCIe interrupt conflicts and extends ARsim to support 4 GB process memory.

See ar-rtos.md §3.6 for the full multicore version progression and firmware-version-mgmt.md §3.2 for AS 6.5 release details.

reACTION Technology

B&R’s reACTION technology provides microsecond-level I/O response by processing logic directly in the I/O module’s FPGA, bypassing the main CPU task cycle entirely.

How reACTION Works

1. I/O module receives input change
2. FPGA on the I/O module executes programmed logic immediately
3. Output response in 1-10 µs (vs. 400 µs minimum on CPU)
4. Results are also available to CPU tasks for monitoring/coordination

reACTION vs CPU Tasks

Practical Relevance

If an undocumented machine uses reACTION for safety-critical or high-speed responses, you won’t see this logic in the CPU’s cyclic tasks. reACTION programs are stored on the I/O modules themselves. The only way to discover them is through the CF card project files or by connecting with Automation Studio and browsing the hardware configuration.

Key Findings

• B&R uses deterministic preemptive multitasking with 8 cyclic task classes, priority range 0–255 (higher = more important)
• Cyclic tasks always preempt system tasks — this is by design but can cause system task starvation
• Cycle time violations cause emergency stop by default — this is the #1 cause of SERVICE mode entries (~80%)
• The Task Idle Time mechanism reserves CPU time for system tasks (Ethernet, OPC-UA, visualization, SDM) within a designated cyclic task class
• SDM CPU usage is misleading — it counts TcIdleFiller no-ops as “usage,” making SERVICE mode appear loaded when it’s actually idle
• The CP1584’s integrated I/O processor handles I/O scanning independently of cyclic task execution
• I/O cycle synchronization is configurable per task class and critical for motion control applications

Advanced Diagnostics: Profiling Without the Full Project

Creating a Long Profiler

The Long Profiler is the primary tool for diagnosing cycle time violations and identifying which function blocks are consuming excessive time. It requires Automation Studio but does NOT require the project source code.

Prerequisites:

• Automation Studio (any version that supports the AR version on the target)
• Network connectivity to the CP1584
• The PLC does NOT need to be in SERVICE mode — the profiler can run on a running system

Procedure:

1. Open Automation Studio (no project needed)
2. Open → Profiler (or Tools → Profiler in some AS versions)
3. Connect to the PLC: Settings → Auto Search or enter IP manually
4. Login to the target (may need online password — see access-recovery.md)
5. Configure the profiler:
   • Recording time: At least 2× the cycle time of the SLOWEST task class (e.g., if TC#4 runs at 100 ms, record for at least 200 ms minimum)
   • For intermittent faults, use 10,000 ms (10 seconds) or longer
   • Set the number of samples high enough to capture the fault
6. Start recording — let it run through multiple cycles
7. Stop recording
8. Analyze the results as a diagram (View → Diagram):
   • Each task class appears as a colored bar
   • Function blocks within each task class show as sub-bars with width proportional to execution time
   • Look for tasks that span nearly the entire cycle time (approaching the tolerance)
   • Look for spikes or occasional long executions that correlate with cycle time violations
9. Export the profiler data (File → Export) for future reference

Reading the Diagram:

Time →

|---TC#1 (10ms)---|---TC#1 (10ms)---|---TC#1 (10ms)---|
| ProgA ████      | ProgA ████████  | ProgA ████      |  ← Normal
|                  | ProgA ██████████|                  |  ← VIOLATION: exceeded 10ms

|----TC#2 (20ms)--------|----TC#2 (20ms)--------|
| ProgB ████  ProgC ████| ProgB ████  ProgC █████████|  ← ProgC occasionally slow

|-------TC#3 (50ms)-----------------------|
| [2ms IDLE] ProgD ██ [2ms IDLE] ProgE ██ |  ← Idle time window visible

• The yellow “Idle tasks” section in the profiler output shows TcIdleFiller time
• The “unknown” cyclic task that sometimes appears in profiler output is caused by an Automation Studio version mismatch — the profiler cannot resolve symbols from a different AS version. This does NOT indicate a real problem.

Community-sourced tips (from B&R Community forum):

• The profiler must include at least two (2×) executions of the slowest task class, or the data is insufficient
• For intermittent faults that happen once per hour, consider recording continuously and saving profiler traces periodically
• If the profiler shows nothing even though cycle time violations occur, check that the task class executing the long-running code is included in the profiler’s filter settings

Using the Profiler in SERVICE Mode

The profiler works even when the PLC is in SERVICE mode. However, since no cyclic tasks are running in SERVICE mode, the profiler will show only:

• I/O system tasks
• System tasks (networking, SDM, visualization)
• TcIdleFiller no-ops

This is still useful for diagnosing whether a SERVICE mode issue is caused by system task overload (rare) vs. a cycle time violation that happened before SERVICE mode was entered (check the AR logbook).

Alternative Monitoring Without Automation Studio

When Automation Studio is not available, these methods provide cycle time monitoring:

PVI API Method

## Using PVI.py (see pvi-api.md for setup)
from pvi import *

pvi = PviConnection()
line = pvi.add_line('LN1', 'ANSL')
cpu = line.add_device('CP1', 'ANSL', '192.168.1.10')

## Read RTInfo system variables for each task class
## Task class cycle time variables are typically named:
##   gTaskClass[n].CycleTime
##   gTaskClass[n].MaxCycleTime
##   gTaskClass[n].TaskLoad
## Where n is the task class number (0-7)
for i in range(8):
    try:
        ct = cpu.read_variable(f'gTaskClass[{i}].CycleTime')
        mx = cpu.read_variable(f'gTaskClass[{i}].MaxCycleTime')
        ld = cpu.read_variable(f'gTaskClass[{i}].TaskLoad')
        print(f'TC#{i+1}: cycle={ct}ms, max={mx}ms, load={ld}%')
    except:
        break

OPC-UA Method

If OPC-UA is configured, browse the System namespace for task class nodes. Common node paths:

Root → Objects → System → TaskClasses → Cyclic#1 → CycleTime
                                               → MaxCycleTime
                                               → TaskLoad

Trend these values over time to detect gradual performance degradation.

SDM Web Interface Method

The SDM at http://<PLC_IP>/sdm shows:

• CPU usage percentage (with TcIdleFiller caveat noted above)
• Task monitor tab showing basic task class status
• This is the lowest-resolution method but requires zero setup

Automation Runtime 4 vs. 6: Execution Model Changes

If you are upgrading a CP1584 system from AR 4.x to AR 6.x, or migrating to newer hardware (CP1684, CP3686), these execution model changes are relevant:

Key migration note: An AS 4.x project targeting AR 4.x cannot be downloaded to an AR 6.x target. The project must be migrated using Automation Studio 6’s built-in migration tool. B&R provides open-source migration scripts at github.com/br-automation-community/as6-migration-tools that detect deprecated libraries, function blocks, and configuration incompatibilities. The community awesome-B-R repository catalogs all available migration resources.

Practical impact for execution model: When migrating, cycle times must be re-evaluated because:

• AR 6.x has more system tasks running (mapp components, enhanced OPC-UA, security layers)
• The Task Idle Time may need to be increased to accommodate the additional background load
• If moving to multi-core hardware, task core assignment should be optimized (motion on one core, logic on another)

Detailed Exception Code Reference

The exception codes below are logged in the AR logbook and can be retrieved via FTP from C:\arlogsys.log, SDM, or OPC-UA. These are distinct from ACOPOS drive fault codes (see acopos-drives.md for those).

CPU/OS Exceptions (Hardware-Level)

Interpreting Exception 25314 (Page Fault)

Exception 25314 is the most common cause of intermittent SERVICE mode entries (as opposed to the consistent Exception 144 cycle time violations). It indicates the CPU tried to access a memory page that is not mapped or protected.

Common causes on undocumented machines:

1. Online code changes — When code is downloaded to a running PLC, memory addresses may shift. Pointer-based code (C programs, addresses of global variables) can become invalid. This is documented as “the primary risk of online code changes.”
2. Corrupted retentive data — If the battery died and retentive data was partially corrupted, reading invalid pointers from retentive memory causes page faults on warm start.
3. String buffer overflows — IEC 61131-3 STRING operations writing beyond buffer bounds.
4. Array index out of bounds — Accessing an array element beyond the allocated memory, triggering a page fault at the unmapped page boundary.
5. mapp component memory corruption — If a mapp component (OPC-UA, mapp View) has a bug, it may write to an invalid address.

Diagnostic approach:

1. Check the AR logbook for the exact exception address — the faulting memory address is logged
2. If the address is near zero (0x00000000-0x00001000), it’s a NULL pointer dereference
3. If the address is in a specific range, it may indicate which library or variable is at fault
4. The exception log includes the task class where the fault occurred
5. If the fault is intermittent and correlates with online changes, the code was likely not properly designed for online modification

Community reference: B&R Community thread “Intermittent EXCEPTION Page Fault during startup – mvLoader mvrpctxtfmt threads” documents page faults occurring during PLC startup related to the mvLoader and mvrpctxtfmt threads, which handle module loading and format parsing. If you see these thread names in the exception log, the fault may be caused by a corrupted module on the CF card or an incompatible firmware/library combination.

Task Class Exceptions (Execution-Level)

Interpreting Exception 144 (Cycle Time Violation)

This is the most frequently encountered exception on B&R systems:

1. Check the AR logbook for the task class number and timestamp
2. The log entry will include the task class ID and the cycle time that was exceeded
3. Compare the exceeded time against the configured cycle time:
   • If exceeded by 10-50%: Likely a code path that occasionally takes longer (e.g., conditional logic with extra computation)
   • If exceeded by 2-10x: Likely an infinite loop or blocking operation
   • If exceeded by 100x+: Likely a page fault or hardware fault
4. Use the Long Profiler to identify the specific function block causing the overrun
5. If you cannot use Automation Studio, check if the violation correlates with a specific I/O event (via OPC-UA trending of task cycle times)

Critical Section Exceptions

AR 6.x introduced enhanced exception codes for critical section violations:

These indicate synchronization bugs in the application code. On an undocumented system with no source, these are extremely difficult to fix — the only practical solution is to identify the conditions that trigger them and avoid those operating conditions.

Cross-References

B&R OPC-UA Integration: Server Configuration, Address Mapping, Security, and Certificate Management

Overview

B&R Automation Runtime includes a built-in OPC-UA server that exposes PLC process variables to any OPC-UA compliant client. This is one of the most important diagnostic access points when working with undocumented B&R machines — OPC-UA allows reading and writing variables without needing the original Automation Studio project. This document covers how the OPC-UA server is configured, how address mapping works, namespace organization, security models, certificate management, and how to use OPC-UA for diagnostics on machines with no OEM documentation.

Architecture

The B&R OPC-UA server runs as a system task within Automation Runtime (priority 4–190 tier). It is integrated into the CPU firmware and requires no additional hardware. Key characteristics:

• Default port: 4840 (standard OPC-UA port, configurable)
• Runs on: Ethernet interface (IF2) — NOT on the POWERLINK interface (IF3)
• Configuration file: OpcUa.Config.xml on the CF card
• Address configuration: Under ServerConfiguration → BaseAddresses in the config file
• Part of: mapp Technology framework (specifically mapp OPC-UA component)

Enabling the OPC-UA Server

Via Automation Studio (Normal Method)

1. Open the project in Automation Studio
2. Go to Physical View
3. Right-click on the CPU (e.g., X20CP1584) → Configuration
4. Expand OPC-UA System
5. Set “Activate OPC-UA System” to On
6. Configure server settings (port, endpoint, security policy)
7. Add an OPC-UA Default View from the Toolbox to the Configuration View
8. Enable specific variables as OPC-UA tags (right-click → Enable Tag)
9. Set user role access rights for each tag (read, write, browse)
10. Build & Transfer to the PLC

Critical: Variables Are NOT Automatically Exposed

Enabling the OPC-UA server does NOT automatically expose all process variables. Each variable must be explicitly enabled as an OPC-UA tag. This means:

• Grayed-out variables in the Default View = NOT accessible via OPC-UA
• Black/active variables = enabled and accessible
• The OEM had to deliberately enable each variable for external access

This is a major consideration for undocumented machines — if the OEM didn’t enable OPC-UA tags, you cannot access them via OPC-UA regardless of whether the server is running.

Without Automation Studio

If you have no project but the OPC-UA server is running:

1. Scan for the server using UaExpert or any OPC-UA discovery client
2. Browse the namespace to see what variables are exposed
3. Read/write through the client

Namespace and Address Structure

B&R OPC-UA Namespace Layout

When connected to a B&R OPC-UA server, the namespace follows this structure:

Objects
└── PLC
    ├── Modules
    │   ├── Default
    │   │   ├── <TaskName1>        (e.g., "Cyclic#1", "HMI_Inputs")
    │   │   │   ├── Variable1
    │   │   │   ├── Variable2
    │   │   │   └── StructName
    │   │   │       ├── Member1
    │   │   │       └── Member2
    │   │   └── <TaskName2>
    │   │       └── ...
    │   └── (additional modules)
    ├── System
    │   └── (system diagnostics, status)
    └── Server
        └── (server configuration, status)

Node IDs

B&R OPC-UA Node IDs typically follow the format:

• ns=2;s=PLC.Modules.Default.<TaskName>.<VariableName> (string-based)
• Numeric namespace indices: ns=0 (OPC-UA standard), ns=1 (B&R system), ns=2+ (user application)

Variables are organized by the task class they belong to. Only variables within tasks that have been configured in the OPC-UA Default View are visible.

Custom Namespaces

You can create custom namespaces using a nodeset file (.xml), which provides more flexibility. A nodeset file can:

• Link OPC-UA nodes to specific PLC variables
• Create custom data types and structures
• Organize variables into logical groups (e.g., “Machine1”, “Conveyor”, “Press”)
• Add metadata (engineering units, descriptions, limits)

Security Model

Authentication Methods

Important: If the “Anonymous” user is deleted from the user-role system, OPC-UA clients cannot connect without credentials. This is a common issue when OEMs tighten security.

User Roles and Access Rights

B&R implements OPC-UA role-based access control:

• Everyone — default role, typically browse + read
• Operator — read + limited write
• Engineer/Admin — full read/write access
• Custom roles — can be defined per installation

Each OPC-UA tag can have individual access rights configured:

• Visible — appears in browse
• Browse — node info can be read
• Read — current value can be read
• Write — value can be modified
• History — historical data can be accessed

Security Policies

B&R OPC-UA supports the standard OPC-UA security policies:

• None — no encryption, no signing (common on legacy machines)
• Basic128Rsa15 — basic encryption
• Basic256 — stronger encryption
• Basic256Sha256 — strongest commonly available

Certificate Management

Certificate Location

Certificates are stored on the CF card in the certificate store:

• Path: Accessible via Automation Studio → Configuration → Access and Security → Certificate Store
• Own certificates — the PLC’s server certificate
• Communication partner certificates — trusted client certificates
• CA certificates — certificate authority chains

Managed Certificate Store (AR 6.5+)

Starting with AR 6.5, B&R introduced the ManagedCertificateStore with the ArMcsRecreateCert function block for programmatic certificate recreation. In AR 6.5, the ManagedCertificateStore is extended to cover ANSL, FTP, HTTP, and SMTP libraries (not just OPC-UA). Additionally, the ArCert library now supports creating, exporting, viewing, and deleting certificate signing requests (CSRs), and the AsHttp httpsClient supports Server Name Indication (SNI). These features are not available on AR 4.x (CP1584 maximum), but are relevant for migration planning to newer B&R hardware.

Creating and Managing Certificates

1. In Automation Studio: Configuration → Access & Security → Certificate Store → Own certificates
2. Double-click New OPC UA certificate
3. Configure: subject, validity, key size
4. Transfer to PLC

Certificate-Only Access

For secure installations, certificate-based access can be configured:

1. Create SSL configuration referencing the certificate
2. Apply to OPC-UA server
3. Add trusted client certificates to the communication partner store
4. Disable anonymous access

Replacing Certificates Without Automation Studio

If you need to change certificates on a running PLC without the project:

1. Access the CF card via FTP (user partition)
2. The certificate store is typically at F:\System\Certificates\ or similar
3. Replace the server certificate file
4. Cold restart the PLC to apply

Caution: Incorrect certificate replacement can lock you out of OPC-UA entirely.

Certificate Management Deep Dive

Certificate Creation Step-by-Step

When creating an OPC-UA certificate for a B&R PLC, the subject fields must be configured correctly for the PLC to accept and serve the certificate properly.

Recommended subject fields:

Key size: Minimum 2048-bit RSA. 4096-bit is supported on newer firmware but increases handshake latency.

Validity period: Typical production use is 1-3 years. Longer periods reduce renewal overhead but weaken the security boundary if the private key is compromised.

Certificate Renewal Workflow

1. Generate a new certificate with the same subject fields and new validity period
2. Replace the server certificate on the CF card (System/Certificates/Own/)
3. Warm restart — the OPC-UA server reloads the certificate
4. All connected clients receive BadCertificateUntrusted and must re-accept the new certificate
5. Update any client certificate stores that pinned the old certificate

SHA1 Deprecation Issue

Older Automation Studio versions generated OPC-UA certificates using SHA1 signatures. Modern clients (UaExpert 1.5+, .NET OPC-UA stack, Python asyncua) reject SHA1 at the security layer.

Symptoms: BadCertificateUntrusted on any sign/encrypt policy; works with security None. Verify: openssl x509 -in cert.der -inform DER -text -noout | grep "Signature Algorithm".

Resolution: Regenerate the certificate with SHA256 via Automation Studio → Certificate Store. Ensure mapp version is 5.x+ (SHA256 native support). On firmware older than AR 4.30, use security None as a workaround.

Self-Signed vs CA-Signed Certificates

For production environments with multiple PLCs, use an internal CA (e.g., Smallstep CA, HashiCorp Vault PKI, or B&R’s own Automation Studio CA feature). This eliminates the need to manually trust each PLC’s certificate on every client.

Certificate Trust Chain Management

The B&R certificate store on the CF card maintains three categories under System/Certificates/:

• Own/ — server certificate + private key (DER format)
• Trusted/ — accepted client certificates from connecting clients
• CA/ — CA root and intermediate certificates

Trust validation order: check Trusted/ folder for direct match, then check CA/ for chain validation (intermediate to root), then verify validity period.

Adding a trusted CA: Export CA root cert in DER format, upload to System/Certificates/CA/ via FTP, warm restart. All certificates signed by that CA are automatically trusted.

SSL Configuration in Automation Studio

To bind a certificate to the OPC-UA server in Automation Studio:

1. Configuration → Access & Security → SSL Configuration — create a new SSL Configuration object
2. Set the Certificate Reference to the OPC-UA certificate in the Certificate Store
3. Under OPC-UA System → Server Configuration, set the SSL Configuration reference
4. Build and transfer

The SSL Configuration also controls TLS versions (TLS 1.2 minimum recommended), cipher suites, and whether the server requests client certificates.

mappView OPC-UA Client Certificate Configuration

When mappView acts as an OPC-UA client (connecting to another PLC or external server), it needs its own client certificate:

1. In the mappView configuration, open mapp OPC-UA Client
2. Set the Certificate reference to a client certificate from the Certificate Store
3. The target server must trust this certificate (either directly or via CA chain)
4. Configure the security policy to match what the server offers

Failure to configure the client certificate results in BadSecurityChecksFailed on the server side.

Certificate Backup and Restore Procedure

Backup: FTP to PLC, download the entire System/Certificates/ directory. Optionally convert to PEM: openssl x509 -in cert.der -inform DER -out cert.pem -outform PEM

Restore: Upload backup System/Certificates/ via FTP, cold restart to reload. Verify by connecting with UaExpert and checking the server certificate fingerprint. Always back up before firmware upgrades — upgrades may invalidate certificate bindings.

Connecting with OPC-UA Clients

Using UaExpert (Free OPC-UA Client)

1. Install UaExpert (Unified Automation)
2. Server → Add
3. Enter the PLC IP address
4. The Discovery URL will be: opc.tcp://<PLC_IP>:4840
5. Click Connect
6. A certificate approval dialog appears — check “Trust Server Certificate”
7. Browse: Objects → PLC → Modules → Default to find variables
8. Set Authentication to Anonymous if no credentials configured

Python Client (asyncua)

import asyncio
from asyncua import Client

async def read_br_variables():
    url = "opc.tcp://192.168.1.100:4840"
    async with Client(url=url) as client:
        # Browse available variables
        root = client.nodes.root
        objects = await root.get_child(["Objects", "PLC", "Modules", "Default"])
        children = await objects.get_children()
        for child in children:
            name = await child.get_browse_name()
            value = await child.get_value()
            print(f"{name}: {value}")

        # Read a specific variable by node ID
        var = client.get_node("ns=2;s=PLC.Modules.Default.Cyclic#1.MyVariable")
        value = await var.get_value()
        print(f"MyVariable = {value}")

        # Write a variable
        await var.write_value(42.0)

asyncio.run(read_br_variables())

Node-RED Integration

Use the OPCUA-IIoT node in Node-RED:

1. Configure OPC-UA server endpoint: opc.tcp://<PLC_IP>:4840
2. Security mode: None (for legacy machines)
3. Browse to find variable node IDs
4. Use Read/Write nodes for data exchange

Practical Client Examples

Python Subscription Example (asyncua)

Subscriptions are preferred over polled reads — the server pushes updates only when values change.

import asyncio
from asyncua import Client, ua

url = "opc.tcp://192.168.1.100:4840"

async def data_change_callback(node, val, data):
    name = await node.get_browse_name()
    print(f"[CHANGE] {name.Name} = {val}")

async def subscription_example():
    async with Client(url=url) as client:
        sub = await client.create_subscription(500, data_change_callback)

        nodes = [
            "ns=2;s=PLC.Modules.Default.Cyclic#1.Temperature",
            "ns=2;s=PLC.Modules.Default.Cyclic#1.Pressure",
            "ns=2;s=PLC.Modules.Default.Cyclic#1.Status",
        ]
        for nid in nodes:
            node = client.get_node(nid)
            params = ua.MonitoringParameters(
                ClientHandle=len(sub.monitored_items),
                SamplingInterval=250,
                QueueSize=10,
                DiscardOldest=True
            )
            await sub.subscribe_data_change(node, params)

        print("Subscribed. Press Ctrl+C to exit.")
        try:
            while True:
                await asyncio.sleep(1)
        except KeyboardInterrupt:
            await sub.delete()

asyncio.run(subscription_example())

Python Write Example — B&R Gotcha

When writing to B&R OPC-UA variables, write_value() works for scalars. For complex structures with engineering unit scaling, you may need write_params or write individual members.

import asyncio
from asyncua import Client, ua

url = "opc.tcp://192.168.1.100:4840"

async def write_example():
    async with Client(url=url) as client:
        scalar = client.get_node("ns=2;s=PLC.Modules.Default.Cyclic#1.Setpoint")
        await scalar.write_value(75.5)
        print("Setpoint written: 75.5")

        struct_node = client.get_node("ns=2;s=PLC.Modules.Default.Cyclic#1.RecipeData")
        variant = ua.Variant(
            {"Param1": 100, "Param2": 3.14, "Enable": True},
            ua.VariantType.ExtensionObject
        )
        try:
            await struct_node.write_value(variant)
        except ua.UaError:
            print("Structure write failed — writing individual members:")
            await client.get_node(
                "ns=2;s=PLC.Modules.Default.Cyclic#1.RecipeData.Param1"
            ).write_value(100)
            await client.get_node(
                "ns=2;s=PLC.Modules.Default.Cyclic#1.RecipeData.Param2"
            ).write_value(3.14)
            await client.get_node(
                "ns=2;s=PLC.Modules.Default.Cyclic#1.RecipeData.Enable"
            ).write_value(True)

asyncio.run(write_example())

UaExpert Workflow for Undocumented PLCs

1. Launch UaExpert, add server: Server → Add → enter PLC IP
2. Discovery: UaExpert queries opc.tcp://<IP>:4840. If discovery fails, manually enter the endpoint URL
3. Certificate dialog: Check “Trust server certificate” on first connect
4. Authentication: Start with Anonymous. If rejected, try common B&R credentials (admin/admin, operator/operator)
5. Browse: Expand Objects → PLC → Modules → Default. Subfolders = task classes, contents = PLC variables
6. Export: Right-click “Default” → Create Address Space Snapshot → saves CSV of all nodes
7. Test: Drag a variable to Data Access View. Double-click value to attempt write
8. System nodes: Objects → PLC → System shows CPU utilization, memory, task cycle times

Wireshark OPC-UA Capture and Decode

1. Start Wireshark, set capture filter: port 4840
2. Connect with the OPC-UA client, then stop capture
3. Install the OPC-UA dissector (Edit → Preferences → Protocols → OPC UA) if not present
4. For encrypted traffic, set security to None for debugging — Wireshark cannot decrypt without session keys
5. Key frames to inspect: Hello/ACK (TCP+OPC-UA handshake), CreateSession, Browse/Read/Write (node IDs visible in plaintext with security None), PublishResponse (subscription data)

C#/.NET OPC-UA Client Example

using Opc.Ua;
using Opc.Ua.Client;

var endpointUrl = "opc.tcp://192.168.1.100:4840";

var config = new ApplicationConfiguration()
{
    ApplicationName = "B&R OPC-UA Client",
    ApplicationUri = new Uri("urn:BROpcUaClient"),
    ApplicationType = ApplicationType.Client,
    SecurityConfiguration = new SecurityConfiguration
    {
        AutoAcceptUntrustedCertificates = true,
        MinimumCertificateKeySize = 1024
    }
};

config.CertificateValidator.CertificateValidation += (s, e) =>
{
    if (e.Error.StatusCode == StatusCodes.BadCertificateUntrusted)
        e.Accept = true;
};

var endpoint = CoreClientUtils.SelectEndpoint(endpointUrl, useSecurity: false);
using var session = Session.Create(config, endpoint, updateBeforeConnect: true,
    "BROpcUaClient", 60000, null, null).Result;

var readNode = new NodeId("PLC.Modules.Default.Cyclic#1.Temperature", 2);
Console.WriteLine($"Temperature: {session.ReadValue(readNode).Value}");

session.WriteValue(
    new NodeId("PLC.Modules.Default.Cyclic#1.Setpoint", 2),
    new DataValue(72.5));

var subscription = new Subscription(session.DefaultSubscription)
{
    PublishingInterval = 500, PublishingEnabled = true,
    LifetimeCount = 1000, KeepAliveCount = 10
};
session.AddSubscription(subscription);

var item = new MonitoredItem(subscription.DefaultItem)
{
    DisplayName = "Pressure",
    StartNodeId = new NodeId("PLC.Modules.Default.Cyclic#1.Pressure", 2),
    SamplingInterval = 250, QueueSize = 10, DiscardOldest = true
};
item.Notification += (_, e) =>
{
    foreach (var c in e.NotificationList)
        Console.WriteLine($"Pressure: {c.Value}");
};
subscription.AddItem(item);
subscription.Create();
Console.WriteLine("Subscribed. Press Enter to exit.");
Console.ReadLine();
session.Close();

Package: OPCFoundation.NetStandard.Opc.Ua (NuGet). Requires .NET Standard 2.0+ or .NET 6+.

Finding an Unknown OPC-UA Server

For machines with no documentation:

Step 1: Find the PLC IP Address

• Check the SDM (System Diagnostics Manager): http://<IP>/sdm
• Use Wireshark to capture B&R ANSL discovery packets
• Check network switch/router ARP table for B&R MAC OUI prefixes
• Try common B&R default IP ranges (192.168.100.x, 192.168.1.x)

Step 2: Check if OPC-UA is Active

## Scan for OPC-UA port 4840
nmap -p 4840 <PLC_IP>

## Or try connecting with openssl
openssl s_client -connect <PLC_IP>:4840

Step 3: Determine the OPC-UA Configuration

You cannot determine the OPC-UA configuration from the PLC alone without:

• The original project
• A system dump analyzed in Automation Studio
• The ability to browse the server

Key unknowns:

• Is OPC-UA activated at all?
• What port is it on? (default 4840, but configurable)
• What variables are enabled?
• What authentication is required?
• What encryption policy is used?

Step 4: Try Connection

Use UaExpert to attempt connection at the default port. If anonymous access is enabled and variables were configured, you’ll see them in the namespace. If not, you need to explore alternative access methods (PVI, FTP, direct I/O monitoring).

Performance Considerations

• OPC-UA runs as a system task (lower priority than cyclic tasks)
• Sampling interval is typically 100 ms minimum for standard OPC-UA subscriptions
• If the task idle time is too low, OPC-UA responses will time out
• The OPC-UA server can be a significant CPU load if many subscriptions are active
• For high-speed data collection, POWERLINK or direct I/O access is faster

Configuration File Deep Dive

OpcUa.Config.xml Structure

The OPC-UA server behavior is controlled by OpcUa.Config.xml on the CF card, generated by Automation Studio but editable via FTP.

OpcUa.Config.xml
├── ServerConfiguration
│   ├── ApplicationUri / ApplicationName / ProductUri / ServerName
│   ├── BaseAddresses (list of endpoint URLs)
│   ├── SecurityPolicies (uri + certificate per policy)
│   ├── MaxSessions / MaxSubscriptionsPerSession
│   ├── MaxMonitoredItemsPerSubscription
│   ├── RequestTimeout / ServiceLevel / AuditingEnabled
│   └── MaxResponseMessageSize
├── EndpointConfiguration
│   ├── TransportProfileUri / SecurityMode
│   ├── SecurityPolicyUri / SecurityLevel
├── UserTokenPolicies (anonymous, username, certificate)
├── CertificateConfiguration
│   ├── CertificateStorePath / IssuedCertificatesPath
│   └── TrustedCertificatesPath
└── NodeManager → BaseAddress

Editing the Config File via FTP

When you have no Automation Studio project and need to modify OPC-UA server settings:

1. Connect to the PLC via FTP (default credentials: user/user or admin/admin depending on configuration)
2. Navigate to the user partition (typically F:\ or the volume labeled “User”)
3. Locate OpcUa.Config.xml — it may be at the root or under a project-specific directory
4. Download the file to your local machine
5. Edit with a text editor (XML-aware editor recommended — notepad++ with XML plugin, VS Code)
6. Backup the original file first (OpcUa.Config.xml.bak)
7. Upload the modified file
8. Perform a warm restart of the PLC to reload the configuration

Caution: Invalid XML will prevent the OPC-UA server from starting. Validate the XML before uploading. The server does not provide detailed parse error logs — it simply fails to start.

Key Configuration Parameters

Endpoint Configuration

Endpoints define how clients connect. Each endpoint specifies:

• Transport Profile URI: opc.tcp for binary TCP transport (standard), http for SOAP/HTTP (legacy, rarely used)
• Security Mode: None, Sign, SignAndEncrypt
• Security Policy URI: Maps to the actual encryption algorithm:
  • http://opcfoundation.org/UA/SecurityPolicy#None
  • http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15
  • http://opcfoundation.org/UA/SecurityPolicy#Basic256
  • http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256

Changing the OPC-UA Port Without Automation Studio

1. FTP to the PLC, download OpcUa.Config.xml
2. Locate <BaseAddresses> and change the port in the endpoint URI:

   <BaseAddresses>
     <EndpointUri>opc.tcp://192.168.1.100:4841</EndpointUri>
   </BaseAddresses>
   

3. Backup the original, upload the modified file, warm restart
4. After changing the port, clients must use the new endpoint URL directly — auto-discovery will not find the server at the old port

Namespace and Variable Discovery Without Project

Recursive Python Namespace Browser

When working with an undocumented B&R PLC, the first task is discovering what variables are exposed. This script recursively browses the entire OPC-UA namespace and prints a tree of all nodes with their data types and current values.

import asyncio
from asyncua import Client

url = "opc.tcp://192.168.1.100:4840"

async def browse_recursive(client, node, indent=0):
    name = await node.get_browse_name()
    node_class = await node.read_node_class()
    display_name = await node.get_display_name()

    prefix = "  " * indent
    info = f"{prefix}[{node_class.name}] {display_name.Text}"

    try:
        value = await node.get_value()
        data_type = await node.read_data_type()
        info += f" = {value} ({data_type.Identifier})"
    except Exception:
        pass

    try:
        desc = await node.read_description()
        if desc and desc.Text:
            info += f"  -- {desc.Text}"
    except Exception:
        pass

    print(info)

    try:
        children = await node.get_children()
        for child in children:
            await browse_recursive(client, child, indent + 1)
    except Exception:
        pass

async def discover_namespace():
    async with Client(url=url) as client:
        print(f"=== OPC-UA Namespace Discovery: {url} ===")
        root = client.nodes.root
        objects = client.nodes.objects
        await browse_recursive(client, objects, indent=0)

asyncio.run(discover_namespace())

Usage notes:

• On large namespaces, this can take several minutes — the B&R OPC-UA server has a default browse limit and may require continuation point handling
• Redirect output to a file: python discover.py > namespace_dump.txt
• The output can be cross-referenced with any partial documentation or PLC I/O lists

Mapping Discovered Variables to IO Points

After discovering the namespace, map variables back to physical I/O:

• Task class names in OPC-UA correspond to Automation Studio task classes: Cyclic#1/Cyclic#2 (I/O processing), HMI_Inputs/HMI_Outputs (HMI interface), Alarm/Recipe/DataLogger (mapp components), IO_.../DI_.../DO_.../AI_.../AO_... (digital/analog I/O)
• Variable naming patterns: gMachine_State (global state), stAxis_<Name> (axis structure), rSensor_<Location> (sensor reading), bSwitch_<Function> (boolean input)
• Struct members map directly to Automation Studio variable names (bEnable, rActualValue, rSetpoint)

Reconstructing IO Mapping via OPC-UA Browse

For a completely undocumented machine:

1. Start with System node: CPU diagnostics, firmware version, task cycle times
2. Browse Modules → Default → <task classes>: application variables by task
3. Look for variables with engineering units metadata — often correspond to physical sensors
4. Look for structures named after hardware: Axis_Drive1, IoModule_Terminal1
5. Compare with physical I/O module count on the hardware to validate coverage

Limitations: What You Cannot Discover via OPC-UA

• Internal program logic: You cannot see ladder logic, ST code, or function block implementations
• Communication parameters: POWERLINK node assignments, MODBUS register mappings, or serial port configurations are not exposed
• Disabled variables: Any variable the OEM did not explicitly enable as an OPC-UA tag is invisible
• Array dimensions: B&R OPC-UA may expose arrays but with limited dimension metadata
• User-defined types: Complex user-defined data types may appear as generic structures without meaningful member descriptions
• Timing information: Task cycle times are visible, but internal timing (delays, timer configurations) is not
• Hardware configuration: The physical I/O topology (which terminal is in which slot) is not directly exposed — only the logical variable names
• Alarm/event history: Unless mapp AlarmX was configured to publish through OPC-UA, alarm data is not available via standard variable browsing

OPC-UA Troubleshooting

Common Connection Failures

Certificate Trust Issues

Scenario: Client connects successfully with security=None but fails with any signing or encryption policy.

1. Verify the server certificate is not expired: openssl x509 -in cert.der -inform DER -dates -noout
2. Verify the signature algorithm: openssl x509 -in cert.der -inform DER -text -noout | grep "Signature Algorithm"
3. Check if the client certificate is in the PLC’s trusted store:
   • FTP to PLC → browse System/Certificates/Trusted/
   • If the client certificate is missing, upload it
4. For CA-signed certificates, ensure the CA root is in System/Certificates/CA/

Authentication Failures

• Anonymous rejected: The OEM removed the “Everyone” role. You must authenticate with a configured username/password. Check the B&R User Management for valid accounts.
• Username/password rejected: Verify credentials against the B&R user management (accessible via Automation Studio or the SDM web interface). Passwords are case-sensitive.
• Certificate authentication rejected: The client certificate is not in the trusted store, or the SSL Configuration on the PLC requires a specific certificate that was not presented by the client.

Timeout Issues

OPC-UA timeouts on B&R systems are almost always caused by insufficient task idle time:

• Check CPU utilization: PLC.System.CPU.Utilization and per-task cycle times via OPC-UA System nodes
• If task idle time is below 10%, the OPC-UA system task cannot respond within the request timeout
• Reduce active subscriptions, increase sampling intervals, or optimize cyclic task code
• Increase client-side timeout (UaExpert: Tools → Options → Advanced → Operation Timeout)

Variable Not Found / Namespace Issues

• Node IDs in B&R OPC-UA are case-sensitive: PLC.Modules.Default.Cyclic#1 is not the same as plc.modules.default.cyclic#1
• The namespace index (ns=X) can change between firmware upgrades or configuration rebuilds — always verify with a fresh browse
• If variables disappear after a PLC update, the OEM may have modified the OPC-UA Default View configuration
• Empty namespaces under Objects → PLC → Modules → Default mean no variables were enabled for that task class

Port Conflicts

• Another service on the PLC may be using port 4840 (unlikely but possible with custom configurations)
• A firewall between the client and PLC may be blocking the port
• If the OPC-UA port was changed from the default, the discovery URL will not match — always try direct endpoint connection
• Multiple OPC-UA servers on the same network segment with the same ApplicationUri can cause client confusion

Security Policy Mismatch

If the client and server have no overlapping security policies:

1. Use UaExpert to connect and check the server’s offered endpoints (shown in the connection dialog before connecting)
2. Ensure the client supports at least one of the server’s offered security policies
3. If the server only offers Basic256Sha256 and the client only supports None, upgrade the client or reconfigure the server’s security policies in OpcUa.Config.xml
4. For legacy B&R firmware, the server may only offer None and Basic128Rsa15 — modern clients that reject SHA1 may only have None as an option

OPC-UA Performance Tuning

Subscription vs Polled Reads

Recommendation: Always prefer subscriptions over polled reads. A single subscription with 100 monitored items generates significantly less network traffic than polling 100 variables every 250 ms.

Dead Band Settings for Analog Values

Dead bands prevent unnecessary notifications for insignificant analog value changes. Set the absolute dead band to match sensor resolution — a temperature sensor with 0.1C resolution does not need notifications for 0.001C changes. Dead bands are not applicable to integers and booleans.

Queue Size and Sampling Rate Optimization

• QueueSize=1: Only the latest value is kept. Intermediate values are lost. Use for dashboards where only the current value matters.
• QueueSize=10+: Multiple intermediate values are queued. Use for data logging or trend analysis. Client receives all intermediate values on each publish cycle.
• SamplingInterval: The minimum practical interval on B&R OPC-UA is typically 50-100 ms. Intervals below 50 ms may be rounded up by the server.
• PublishingInterval: The server sends queued notifications at this interval. Set to 500-1000 ms for normal operation. Lower values increase CPU and network load.

Impact on Cyclic Task Performance

The OPC-UA server runs as a system task at a priority between 4 and 190. If cyclic tasks are consuming most of the CPU cycle, the OPC-UA server task gets starved:

1. Monitor task idle time: Via OPC-UA, read PLC.System.Tasks.<TaskName>.IdleTime. If below 10%, expect OPC-UA response degradation
2. Correlation: When cyclic task cycle time spikes (e.g., from 5 ms to 15 ms), OPC-UA publish intervals will stretch proportionally
3. Mitigation: Reduce the number of monitored items, increase sampling intervals, or optimize the cyclic task code
4. Diagnostic: If you notice OPC-UA latency increasing during machine operation, check which cyclic task is consuming CPU and when

Monitoring Task Idle Time with OPC-UA Active

When OPC-UA is active, monitor task idle time to detect performance impact. Key node IDs:

• PLC.System.Cyclic#1.IdleTime — idle time in microseconds
• PLC.System.Cyclic#1.CycleTime — total cycle time in microseconds

Health thresholds:

• Idle > 20% of cycle time: healthy, OPC-UA is not starving
• Idle 10-20%: warning, reduce subscriptions or increase sampling intervals
• Idle < 10%: critical, OPC-UA responses will timeout; optimize cyclic tasks first

If idle time drops when OPC-UA subscriptions are active, the OPC-UA system task is competing for CPU time. Reduce the number of monitored items or increase sampling intervals to relieve pressure.

OPC-UA History (Historical Access)

Historical Data Access

If the B&R OEM configured mapp DataLogger or mapp History with OPC-UA historical access enabled, you can read historical variable values from the OPC-UA server:

1. The historical data is exposed through the OPC-UA Historical Data Access (HDA) service
2. Not all B&R OPC-UA configurations include HDA — it must be explicitly configured in Automation Studio
3. Available historical nodes appear in the namespace with the AccessLevelHistoryRead flag set

Reading Historical Data with Python

import asyncio
from asyncua import Client, ua

url = "opc.tcp://192.168.1.100:4840"

async def read_history():
    async with Client(url=url) as client:
        node = client.get_node("ns=2;s=PLC.Modules.Default.DataLogger.Temperature")
        start = ua.DateTime.utcfromisoformat("2025-12-01T00:00:00Z")
        end = ua.DateTime.utcfromisoformat("2025-12-31T23:59:59Z")
        details = ua.ReadRawModifiedDetails(
            IsReadModified=False, StartTime=start, EndTime=end,
            NumValuesPerNode=0, ReturnBounds=True
        )
        result = await node.read_history(
            history_read_details=details,
            timestamps_to_return=ua.TimestampsToReturn.Both
        )
        if result.StatusCode.is_good():
            for item in result.HistoryData.Values:
                print(f"{item.SourceTimestamp}: {item.Value.Value} [{item.Status}]")
        else:
            print(f"Failed: {result.StatusCode}")

asyncio.run(read_history())

Reading Historical Alarms via OPC-UA

If mapp AlarmX is configured to publish through OPC-UA, alarms appear as condition nodes with properties: EnabledState, AckedState, ActiveState, Severity. Query historical alarm events using the Event History service.

import asyncio
from asyncua import Client, ua

url = "opc.tcp://192.168.1.100:4840"

async def read_alarm_history():
    async with Client(url=url) as client:
        alarms = client.get_node("ns=2;s=PLC.Modules.Default.AlarmX")
        start = ua.DateTime.utcfromisoformat("2025-12-01T00:00:00Z")
        end = ua.DateTime.utcfromisoformat("2025-12-31T23:59:59Z")
        event_filter = await alarms.get_event_filter(
            evtype=client.get_node(ua.ObjectIds.AlarmConditionType)
        )
        details = ua.ReadEventDetails(
            StartTime=start, EndTime=end,
            MaxValuesPerNode=1000, Filter=event_filter
        )
        result = await alarms.read_event_history(details)
        if result and result.Events:
            for ev in result.Events:
                msg = ev.Message.Text if ev.Message else "No message"
                sev = ev.Severity if hasattr(ev, "Severity") else "N/A"
                print(f"{ev.Time}: [{sev}] {msg}")
        else:
            print("No alarm history or HDA not configured")

asyncio.run(read_alarm_history())

Time-Based Data Retrieval Constraints

• Time zone: B&R OPC-UA uses UTC. If the PLC clock is not NTP-synchronized, timestamps may be inaccurate (see time-sync.md)
• Resolution: Depends on mapp DataLogger config — typically 100 ms to 60 seconds
• Retention: Stored on CF card or SRAM; old data is overwritten when the buffer fills
• Aggregate functions: If supported, use ReadProcessedDetails for server-side aggregates (average, min, max, count, stddev) — more efficient than reading all raw values

Security Considerations for OPC-UA on B&R Systems

Known OPC-UA Vulnerabilities

OPC-UA Hardening Checklist

1. Disable anonymous access if possible — require username/password or certificate authentication
2. Use security policy Basic256Sha256 or higher — never run production with security None
3. Firewall port 4840 to allow only known OPC-UA clients and HMIs
4. Monitor OPC-UA connection attempts — unexpected clients may indicate scanning
5. Regenerate self-signed certificates with SHA256 and set reasonable validity (1-3 years)
6. Replace self-signed certs with CA-signed when possible — see SA25P001 guidance in cybersecurity-hardening.md
7. PPT30 HMI panels: If OPC-UA is enabled on a PPT30, verify OS version >= 1.8.0 (SA25P006)

CVE-2025-11482: PPT30 OPC-UA Server DoS

The PPT30 OPC-UA server has a resource exhaustion vulnerability (CWE-770). An unauthenticated network attacker can send messages that cause the OPC-UA server to become permanently unresponsive. A reboot is required to restore service. The vulnerability is scored CVSS v4.0 8.7 because:

• No authentication required
• Network-based exploitation
• Permanent availability impact (reboot needed)
• Affects safety-related HMI interactions when PPT30 is used as the operator interface

If your CP1584 system uses a PPT30 panel with OPC-UA:

1. Check PPT30 OS version: Settings → System Information → OS Version
2. Update to PPT30 OS 1.8.0 via B&R Update Tool
3. If update is not immediately possible, restrict OPC-UA access to trusted IP addresses via firewall
4. OPC-UA is not enabled by default on PPT30 — if you never explicitly enabled it, you are not affected

Cross-References

• execution-model.md — How task priority affects OPC-UA system task performance
• pvi-api.md — Alternative programmatic access method
• ftp-web-interface.md — FTP access to CF card for certificate/config files
• iiot-retrofit.md — OPC-UA to MQTT bridges for modern monitoring
• python-diagnostics.md — Building Python diagnostic scripts with OPC-UA
• time-sync.md — Timestamp handling for OPC-UA historical data
• network-architecture.md — Network requirements for OPC-UA
• access-recovery.md — Accessing OPC-UA when credentials are lost
• alarm-logging.md — OPC-UA alarm integration
• cybersecurity-hardening.md — OPC-UA security hardening, CVE-2025-11482, SA25P006

Key Findings

• OPC-UA server is built into AR firmware but must be explicitly activated and variables individually enabled
• Not all variables are automatically exposed — each must be enabled as an OPC-UA tag by the developer
• Default port is 4840 on the standard Ethernet interface
• Namespace structure: Objects → PLC → Modules → Default → <TaskName> → <Variables>
• Three authentication methods: anonymous (default), username/password, certificate
• Certificates stored on CF card in the certificate store
• For undocumented machines: OPC-UA is the best diagnostic access point if it was configured, but useless if the OEM never enabled it
• The OpcUa.Config.xml file on the CF card contains server configuration
• OPC-UA runs as a lower-priority system task — it can be starved by long-running cyclic tasks

Community OPC-UA Tools for B&R

Document updated: July 2026 (added security considerations section §13 with CVE-2025-11482/PPT30 OPC-UA DoS, OPC-UA hardening checklist; added community OPC-UA tools section)

B&R HMI Integration — mapp View & Panel Systems

Audience: Automation engineers maintaining undocumented B&R CP1584 machines with zero OEM documentation.

Scope: mapp View (HTML5), legacy POWER WORX/VNC display paths, OPC UA FX data exchange, Automation Studio project recovery, panel replacement procedures.

Table of Contents

1. Overview
2. Architecture
3. mapp View Deep Dive
   • Project Structure in Automation Studio
   • Widget Framework & Pages
   • Content vs. Layout Separation
4. Data Exchange: OPC UA FX
   • Data Model Mapping
   • Variable Binding
   • Diagnostic Reads Without the Project
5. Legacy Protocols: POWER WORX & VNC
6. Alarm Handling: mapp AlarmX
7. Diagnosing HMI Issues on an Undocumented Machine
8. Recovering the HMI Project Without OEM Files
9. Panel Replacement Procedure (CP1584 Context)
10. Multi-Client / Multi-User Setup
11. Practical Code Examples
12. Key Findings
13. Cross-References

Overview

B&R Automation’s HMI ecosystem has evolved from proprietary serial/ethernet display protocols to a fully web-based architecture built on open standards. On a CP1584 (or any modern B&R controller with mapp View), the HMI is not a separate application — it is an integrated web server running inside the controller’s runtime, rendering HTML5 pages that bind to PLC variables through the OPC UA FX (Field eXchange) data model.

This means:

• There is no separate “HMI program” to worry about — the HMI is part of the controller project.
• The display is served over HTTP/HTTPS on the controller’s Ethernet interface.
• Any device with a web browser can be the HMI panel. Dedicated B&R Panel PCs (Power Panel series, panels with built-in B&R controllers) run a fullscreen Chromium-based runtime that points at the controller’s web server.
• If you have no OEM documentation, the HMI configuration lives inside the .apj (Automation Studio project) or in files deployed to the controller’s flash filesystem.

Architecture

┌──────────────────────────────────────────────────────────────────────┐
│  B&R Controller (e.g. CP1584)                                        │
│                                                                      │
│  ┌─────────────────┐    ┌──────────────────┐    ┌────────────────┐  │
│  │  PLC Logic       │    │  mapp View        │    │  OPC UA FX     │  │
│  │  (IEC 61131-3)   │◄──►│  Web Server       │◄──►│  Data Broker   │  │
│  │  ST/SFC/CFC/LD   │    │  (Port 80/443)    │    │                │  │
│  └─────────────────┘    └────────┬─────────┘    └────────────────┘  │
│                                  │                                  │
│  ┌────────────────────────────────┼──────────────────────────────┐  │
│  │  Runtime Filesystem            │                               │  │
│  │  /opt/mappView/                │                               │  │
│  │    ├── pages/  (*.page)       │                               │  │
│  │    ├── widgets/ (*.widget)    │                               │  │
│  │    ├── css/                   │                               │  │
│  │    ├── js/                    │                               │  │
│  │    └── config/                │                               │  │
│  └────────────────────────────────┼──────────────────────────────┘  │
└───────────────────────────────────┼──────────────────────────────────┘
                                    │
                    ┌───────────────┼───────────────┐
                    │               │               │
              ┌─────▼─────┐  ┌─────▼──────┐  ┌────▼───────┐
              │  Panel PC  │  │  VNC       │  │  Web Browser│
              │  (local)   │  │  (remote)  │  │  (any dev.) │
              │  Chromium  │  │  port 5900 │  │  HTTP/HTTPS │
              └────────────┘  └────────────┘  └─────────────┘

Key architectural principle: HMI logic and control logic are completely decoupled. The PLC program has no knowledge of the HMI screens. The HMI screens have no knowledge of the PLC program structure. They are connected solely through the OPC UA FX variable namespace.

mapp View Deep Dive

Project Structure in Automation Studio

In Automation Studio, mapp View is a mapp component that you add to the project. Once added, it creates a structured directory tree:

MyProject/
├── Logical/
│   ├── mappView/                    ← mapp View configuration
│   │   ├── Pages/                   ← .page files (screen definitions)
│   │   │   ├── Main.page
│   │   │   ├── Diagnostics.page
│   │   │   └── RecipeEditor.page
│   │   ├── Widgets/                 ← Reusable widget definitions
│   │   │   ├── MotorStatus.widget
│   │   │   └── TemperatureGauge.widget
│   │   ├── Frames/                  ← Frame layouts (.frame)
│   │   ├── Styles/                  ← CSS files
│   │   │   └── Custom.css
│   │   ├── Resources/               ← Images, SVGs
│   │   ├── Data/                    ← Data configuration (.data)
│   │   │   └── mappViewData.data
│   │   ├── Config/                  ← .config files (roles, clients)
│   │   │   ├── Roles.config
│   │   │   └── Clients.config
│   │   └── mappView.config          ← Root configuration
│   │
│   └── Libraries/                   ← Linked widget libraries
│       └── mappViewWidgets/
│
├── Physical/
│   ├── CP1584/                      ← Target hardware configuration
│   └── ...
│
└── MyProject.apj                   ← Project file

File types you will encounter:

Widget Framework & Pages

mapp View provides a library of drag-and-drop widgets organized by function:

• Display widgets: Text, Image, LED, Bar, Trend, Gauge, Table
• Input widgets: Button, Edit, CheckBox, RadioButton, Slider, DatePicker
• Container widgets: Group, Tab, SplitPanel, ScrollBox, Layer
• Chart widgets: CurveTracker, XYChart, BarChart
• Special widgets: AlarmList, RecipeEditor, CameraView, MaintenanceUI

Each widget has properties that fall into categories:

1. Layout — position, size, anchoring
2. Style — colors, fonts, borders
3. Data — variable bindings (the OPC UA FX links)
4. Behavior — click handlers, visibility conditions, animations

Widget data binding syntax in the .data file uses dot-notation referencing the OPC UA FX namespace:

// Data binding example (mappViewData.data)
Content.Main.StatusText.Value = "gMachineStatus.sCurrentState"
Content.Main.StartButton.Enable = "gMachineStatus.bRunning"
Content.Main.TempDisplay.Value = "gAxis[0].fTemperature"

Content vs. Layout Separation

mapp View enforces a strict three-layer separation:

This separation is critical for undocumented machines because:

• You can change variable bindings in the .data file without touching any page layouts.
• You can swap language resource files without rebuilding the project.
• Layout changes don’t affect what data is displayed.

Data Exchange: OPC UA FX

Data Model Mapping

OPC UA FX is B&R’s proprietary extension to the OPC UA information model, optimized for high-performance cyclic data exchange between the PLC and HMI. It runs inside the controller — no external OPC UA server is needed.

The FX model organizes variables into a hierarchical namespace:

Data
├── Global
│   ├── gMachineStatus
│   │   ├── sCurrentState      (STRING)
│   │   ├── bRunning           (BOOL)
│   │   ├── nErrorCode         (UINT)
│   │   └── fCycleTime         (LREAL)
│   ├── gAxes
│   │   └── [0..7]
│   │       ├── fPosition      (LREAL)
│   │       ├── fVelocity      (LREAL)
│   │       ├── bHomed         (BOOL)
│   │       └── bEnabled       (BOOL)
│   └── gRecipe
│       ├── sActiveRecipe      (STRING)
│       └── rParameters
│           ├── fSpeed         (LREAL)
│           ├── fForce         (LREAL)
│           └── nCount         (UDINT)
├── AlarmX
│   ├── nActiveCount           (UDINT)
│   └── aEntries[]
│       ├── sText              (STRING)
│       ├── nCode              (UDINT)
│       ├── eSeverity          (ENUM)
│       └── tTimestamp         (DATE_AND_TIME)
└── mappView
    ├── nClientCount           (USINT)
    └── aClients[]

Variable Binding

Variable bindings in mapp View are not hardcoded in widget definitions. They use a three-part indirection:

1. PLC declares global variables (in IEC code or mapp component FBK instances).
2. The .data file maps those PLC variables to symbolic names in the FX namespace.
3. Widgets reference the FX symbolic names.

PLC side (IEC 61131-3):
  PROGRAM Main
  VAR_GLOBAL
    gMachineStatus : ST_MachineStatus;
  END_VAR

FX data binding (mappViewData.data):
  Data.Global.gMachineStatus → Main.gMachineStatus

Widget property (in page/widget XML):
  Content.Main.StatusText.Value → Data.Global.gMachineStatus.sCurrentState

This indirection is what makes the content/layout/logic separation work.

Diagnostic Reads Without the Project

If you have no Automation Studio project, you can still read the live variable namespace from the controller:

Method 1: OPC UA Client (e.g., UAExpert, Prosys Simulator)

1. Connect OPC UA client to controller IP
   - Endpoint URL: opc.tcp://<CP1584_IP>:4840
   - Security: None (or sign-only, depending on config)
   - No username/password by default

2. Browse the namespace:
   - Root → Objects → Data → Global
   - All PLC global variables are exposed here
   - Root → Objects → Data → AlarmX
   - Active alarms and history

3. Read/scribe individual variables
4. Monitor cyclic changes (subscription)

Method 2: B&R Automation Studio “Upload from Target”

1. Open Automation Studio → File → New → Project from Target
2. Enter controller IP address
3. Select hardware configuration to upload
4. This recovers:
   - Physical hardware configuration (module types, addresses)
   - Software object list (what programs/components are running)
   - Global variable declarations
   - mapp component instances and their configurations
   - File system contents (including mapp View files)
5. Does NOT recover:
   - Source code of PLC programs (only compiled object code)
   - Comments or original variable names (only runtime names)
   - .page/.widget source files IF the OEM disabled source deployment

Method 3: FTP to controller filesystem

# B&R controllers expose file system access via FTP
ftp <CP1584_IP>
# Default credentials: admin / admin (may differ)

# On Automation Runtime (VxWorks), the CF card is mounted as:
#   C:\ — system partition (firmware, OS files)
#   F:\ — user partition (application, mapp View, logs)

# mapp View deployed files are typically at:
#   F:\mappView\
# Check with:
dir F:\mappView
dir F:\UserProject

# Automation Studio project files (if deployed):
#   F:\UserProject\

WARNING: The CP1584 runs Automation Runtime on VxWorks — it does NOT provide SSH access. All filesystem access is via FTP (see ftp-web-interface.md). Filesystem access depends on firmware version and security settings. Some machines have FTP disabled or credentials changed from defaults.

Legacy Protocols: POWER WORX & VNC

POWER WORX (Proprietary HMI Protocol)

Before mapp View, B&R’s HMI systems (Power Panel T-Series, older Panel PCs) communicated with PLCs using the POWER WORX protocol — a B&R-proprietary binary protocol over Ethernet or serial.

Characteristics:

• Binary protocol, not human-readable
• Runs on Ethernet (TCP, typically port 49152 or configured) or serial (RS-232/TTY)
• Direct memory-mapped variable exchange (the HMI reads/writes PLC memory directly)
• Tightly coupled — HMI knew PLC memory layout and structure
• Replaced by OPC UA FX in modern systems

If you encounter POWER WORX on a CP1584:

• This means the machine has a legacy Power Panel connected alongside the CP1584
• The CP1584 acts as a gateway/bridge between POWER WORX and OPC UA
• Check Automation Studio configuration for POWERWORX or PVI (Process Visualization Interface) components
• PVI is the B&R library that implements POWER WORX communication

// PVI object access in IEC 61131-3 (legacy pattern)
// This is what you might find in older PLC code
PVI_Connect(hConnection, 'CP1584', 'TCP', '<IP>');
PVI_ReadVariable(hConnection, 'Main.gMachineStatus', &rxStatus);
PVI_WriteVariable(hConnection, 'Main.gCmdStart', bStart);

VNC (Remote Display)

VNC is used on B&R systems as a passive remote display mechanism — it mirrors what is shown on a connected Panel PC’s screen.

┌──────────┐   VNC (5900)   ┌──────────────┐
│  Panel PC  │───────────────│  Remote PC    │
│  (shows    │               │  (VNC viewer │
│   HMI)     │               │   / noVNC)   │
└─────┬──────┘               └──────────────┘
      │ HTTP/HTTPS
      │
┌─────▼──────┐
│  CP1584    │
│  (mapp View│
│   server)  │
└────────────┘

• Default VNC port on B&R Panel PCs: 5900
• Some B&R systems also expose noVNC (HTML5 VNC client) on the controller’s web server
• VNC is display only — you cannot inject HMI commands through VNC
• For full remote HMI access, connect a browser directly to the controller’s mapp View server instead

Accessing VNC:

# Direct VNC connection to Panel PC (not the CP1584 itself)
vncviewer <Panel_PC_IP>:5900

# noVNC via controller web interface (if available)
http://<CP1584_IP>/vnc.html

VNC Configuration Notes:

• VNC is available on B&R Panel PCs and Automation PCs (APC series) — not on headless CPUs like the CP1584
• On the CP1584 specifically, the VNC server is part of the VNC Component in Automation Studio (Visualisierung > VNC) and requires it to be configured in the project
• Default VNC password: typically blank (no password) on older systems; configured in the VNC component settings
• Security warning: VNC traffic is unencrypted by default. On plant networks, use a VPN or SSH tunnel, or disable VNC and use the web-based mapp View interface instead
• VNC performance depends on resolution, color depth, and network bandwidth. Reduce resolution on slow links (10 Mbps)
• Troubleshooting VNC failures: Check that the Panel PC’s VNC component is enabled in the project (look for VncSrv in the task configuration via Automation Studio online view). If VNC doesn’t connect, check firewall rules and verify port 5900 is not blocked by the plant network

Alarm Handling: mapp AlarmX

mapp AlarmX is the integrated alarm management component for mapp View systems. It provides:

• Centralized alarm definition in the Automation Studio project
• Automatic alarm triggering when bound variables change state
• Historical alarm logging with timestamps and acknowledgment
• HMI integration via the AlarmList widget

Architecture

PLC Logic ──► mapp AlarmX Component ──► OPC UA FX ──► mapp View AlarmList Widget
                  │
                  ├── Alarm Definitions (.alarmx file)
                  ├── Alarm Groups (Machine, Safety, Process...)
                  ├── Severity Levels (Info, Warning, Error, Fatal)
                  └── Alarm Logging (to SD card / internal flash)

Alarm Configuration File Structure

// In the Automation Studio project: Logical/mappAlarmX/
AlarmGroups.config      → Group definitions
AlarmInstances.config   → Which variables trigger which alarms
AlarmParameters.config  → Thresholds, delays, severity mapping

Accessing Alarms Without the Project

# Via OPC UA:
Browse to: Objects → Data → AlarmX → ActiveAlarms

# Key variables exposed via OPC UA FX:
AlarmX.nActiveAlarmCount     → Number of currently active alarms
AlarmX.aActiveAlarms[0..N]  → Array of active alarm structures
  .sText                     → Alarm description
  .nCode                     → Alarm code number
  .eSeverity                 → Severity level
  .tOccurrence               → First occurrence timestamp
  .tAcknowledged             → Acknowledgment timestamp (0 if unack'd)

# Via Automation Runtime console (if SSH access):
# Alarm log files are typically stored at:
/flash/alarmlog/
/flash/UserProject/Log/

See also: alarm-logging.md for detailed alarm logging analysis and recovery procedures.

Diagnosing HMI Issues on an Undocumented Machine

Symptom: HMI Screen Blank or Not Loading

CHECKLIST:
□ Ping the controller IP from a PC on the same network
  → If unreachable: network/cable/switch issue — not HMI

□ Open browser → http://<CP1584_IP>
  → If browser shows connection refused: mapp View service not running
  → If browser shows login page: HMI is working, check credentials

□ If nothing loads on port 80, check port 443 (HTTPS):
  → Some systems force HTTPS only

□ Check if controller is in RUN mode:
  → Via Automation Studio "Online" → "Show Status"
  → Or via the physical controller status LED

□ SSH/FTP into controller and check mapp View process:
  ps aux | grep -i mapp
  # Or check the web server status
  ps aux | grep -i httpd

Symptom: HMI Shows Values But They’re Wrong/Stale

DIAGNOSIS:
1. Connect OPC UA client (UAExpert) to opc.tcp://<CP1584_IP>:4840
2. Browse to the same variables shown on the HMI
3. Compare OPC UA values with HMI displayed values
4. If OPC UA values are correct but HMI is wrong:
   → .data binding file has wrong variable mapping
   → Rebuild .data file with correct PLC variable references
5. If OPC UA values are also wrong:
   → PLC program issue, not HMI
   → See [execution-model.md](./execution-model.md) for PLC diagnostics

Symptom: Alarms Not Appearing on HMI

DIAGNOSIS:
1. Check OPC UA FX → AlarmX node → are alarms present in the namespace?
   → If yes but not showing on HMI: AlarmList widget misconfigured or page not visible
   → If no: mapp AlarmX component not running or not configured

2. Check if mapp AlarmX is in the software object list:
   → Automation Studio → Online → Software Objects
   → Look for "mpAlarmX" or "mappAlarmX" in the running components

3. Force an alarm condition:
   → Write to the alarm trigger variable via OPC UA client
   → Does it appear in the AlarmX OPC UA node?
   → Does it appear on the HMI?

Symptom: Can’t Log In / “Access Denied”

DIAGNOSIS:
1. Default credentials on many B&R systems:
   Username: administrator (or admin)
   Password: (blank or "admin" — varies by firmware)

2. If credentials are unknown and there's no documentation:
   → You will need Automation Studio to "Upload from Target" and read the
     Roles.config and Clients.config files
   → Or access the controller filesystem and read the config files directly

3. Factory reset (LAST RESORT):
   → Automation Studio → Online → Initialize Target
   → WARNING: This erases ALL configuration including PLC program

Recovering the HMI Project Without OEM Files

Step 1: Upload from Target

This is the primary recovery method for any undocumented B&R system.

Automation Studio:
1. File → New → Project from Target
2. Enter controller IP: <CP1584_IP>
3. Project name: Recovery_CP1584_<serial>
4. Select target hardware (Automation Studio will auto-detect)
5. Configure upload scope:
   ☑ Hardware configuration
   ☑ Software configuration (mapp components)
   ☑ Global variable declarations
   ☑ File system contents (this captures mapp View files)
   ☐ Source code (only compiled objects will be available)
6. Wait for upload (can take 10-30 minutes for large projects)
7. Save the recovered project as .apj

Step 2: Analyze Recovered mapp View Files

After upload, inspect the recovered project structure:

Logical/
└── mappView/
    ├── Pages/          ← .page files (XML format, human-readable)
    ├── Widgets/        ← .widget files (XML format)
    ├── Data/           ← .data files (variable bindings — CRITICAL)
    ├── Config/         ← Roles, clients, display settings
    └── Styles/         ← CSS overrides

Critical files to examine:

Step 3: Reverse-Engineer Variable Mapping

1. Open mappViewData.data
2. Map each HMI binding to the PLC variable namespace:
   "Content.Main.Motor1Speed.Value" → "Data.Global.gMotor[1].fSpeed"
   → This tells you PLC variable: Main.gMotor[1].fSpeed

3. Cross-reference with the global variable declarations:
   → Find Main.gMotor data type
   → Find ST_Motor structure definition
   → Now you know every motor parameter available

Step 4: Export for Documentation

# Convert recovered .page files to documentation:
# .page files are XML — parse them to extract:
#   - Page names (screen list)
#   - Widget types per page
#   - Variable bindings per widget
#   - Text strings (process descriptions, labels)

# Example: parse a .page file
xmllint --format Main.page | grep -E '(widget|binding|text)'

What You CANNOT Recover

Panel Replacement Procedure (CP1584 Context)

Scenario: Panel PC Failed, Need to Replace

On B&R systems, the “HMI panel” is typically one of:

1. A dedicated B&R Power Panel with built-in controller (your machine has a CP1584, which IS the controller — so the panel is likely a separate display)
2. A B&R Panel PC connected to the CP1584 via Ethernet, running mapp View in a fullscreen browser
3. A third-party display accessing mapp View via web browser

Replacing a B&R Panel PC

PREREQUISITES:
□ New panel PC with B&R Automation Runtime installed (or standard Windows/Linux)
□ IP address of the CP1584 controller
□ Network configuration (subnet, gateway)
□ Any role/client configuration needed for this panel

PROCEDURE:
1. Physically install the new panel:
   → Mount in existing cutout / VESA mount
   → Connect power
   → Connect Ethernet to the same switch as CP1584

2. Configure network on new panel:
   → Static IP on same subnet as CP1584
   → Verify ping to CP1584

3. Launch the HMI runtime:
   ┌─ If B&R Panel PC with Automation Runtime:
   │  → Automation Studio → Deployment → Deploy HMI Client
   │  → Or: the panel auto-discovers the mapp View server via mDNS
   │
   └─ If standard PC / thin client:
      → Open browser: http://<CP1584_IP>
      → Set to fullscreen (F11)
      → Bookmark for automatic startup

4. Verify all screens load correctly
5. Test alarm acknowledgment from the new panel
6. Test user login/role assignment

Reconfiguring the HMI Client on the Controller

If the new panel has a different resolution or needs a different role assignment:

# Access the Clients.config via Automation Studio or FTP:
# Edit the client entry for the new panel:

<Client>
  <Name>Panel_Line2</Name>
  <IpAddress>192.168.1.50</IpAddress>
  <DisplayResolution>1920x1080</DisplayResolution>
  <Role>Operator</Role>
  <AutoStartPage>Main</AutoStartPage>
</Client>

If There Is No Dedicated Panel (Headless Operation)

Some CP1584 machines run without any physical display — the HMI is accessed only via browser from a PC or tablet.

To verify the HMI is running on a headless machine:
1. Connect PC to same network
2. Open browser → http://<CP1584_IP>
3. If mapp View loads: HMI is running, no panel needed
4. If not: check if mapp View is enabled in the controller configuration
   → Automation Studio: mappView.config → Enabled = true
   → Also check: Configuration → mapp View → "Enable web server"

Multi-Client / Multi-User Setup

mapp View supports multiple simultaneous connections, each with independent state:

                    ┌──────────┐
                    │ CP1584   │
                    │ mapp View│
                    │ Server   │
                    └────┬─────┘
           ┌─────────────┼─────────────┐
           │             │             │
     ┌─────▼─────┐ ┌────▼──────┐ ┌────▼──────┐
     │ Operator  │ │ Engineer  │ │ Tablet    │
     │ Panel     │ │ Laptop    │ │ (remote)  │
     │ Role: Op  │ │ Role: Eng │ │ Role: View│
     └───────────┘ └───────────┘ └───────────┘

Role-Based Views

mapp View implements roles through the Roles.config file. Each role can have:

• Different available pages (Operator doesn’t see Engineering pages)
• Different widget visibility (some widgets hidden for certain roles)
• Different variable write permissions (View role = read-only)
• Different language settings

// Roles.config structure (simplified XML)
<Roles>
  <Role name="Administrator">
    <Pages>All</Pages>
    <Permission>ReadWrite</Permission>
  </Role>
  <Role name="Operator">
    <Pages>Main, Alarms, Recipe</Pages>
    <Permission>ReadWrite</Permission>
    <HiddenPages>Diagnostics, Network, System</HiddenPages>
  </Role>
  <Role name="Viewer">
    <Pages>Main, Alarms</Pages>
    <Permission>ReadOnly</Permission>
  </Role>
</Roles>

Multi-Client Data Consistency

When multiple clients are connected:

• Read operations: Each client reads independently from the OPC UA FX namespace — no conflicts
• Write operations (e.g., button press to start machine): The first write wins. Multiple clients pressing “Start” simultaneously do not cause errors — the PLC logic handles the edge detection
• Alarm acknowledgment: Acknowledgment is tracked per-alarm, not per-client. If Client A acknowledges an alarm, Client B sees it as acknowledged
• Recipe changes: mapp View handles recipe editing with a “checkout” mechanism — only one client can edit a recipe at a time

Practical Code Examples

Reading HMI Variables via OPC UA (Python)

"""
Read live HMI variables from B&R CP1584 via OPC UA.
Requires: pip install opcua-asyncio
"""
import asyncio
from asyncua import Client

CONTROLLER_IP = "192.168.1.10"
PORT = 4840
ENDPOINT = f"opc.tcp://{CONTROLLER_IP}:{PORT}"

async def read_machine_status():
    async with Client(url=ENDPOINT) as client:
        await client.connect()

        root = client.nodes.root
        objects = await root.get_child(["0:Objects"])
        data = await objects.get_child(["2:Data"])
        global_vars = await data.get_child(["2:Global"])

        machine_status = await global_vars.get_child(["2:gMachineStatus"])

        state = await machine_status.get_child(["2:sCurrentState"]).get_value()
        running = await machine_status.get_child(["2:bRunning"]).get_value()
        error = await machine_status.get_child(["2:nErrorCode"]).get_value()

        print(f"State: {state}")
        print(f"Running: {running}")
        print(f"Error Code: {error}")

        await client.disconnect()

asyncio.run(read_machine_status())

Browsing the HMI Variable Namespace (Python)

"""
Recursively browse the OPC UA FX namespace on a B&R controller
to discover all HMI-accessible variables — useful for undocumented machines.
"""
import asyncio
from asyncua import Client

async def browse_namespace(node, indent=0):
    children = await node.get_children()
    for child in children:
        name = (await child.get_browse_name()).Name
        node_id = str(child.nodeid)
        dtype = await child.get_data_type()
        try:
            value = await child.get_value()
            value_str = f" = {value}"
        except Exception:
            value_str = ""

        print("  " * indent + f"{name} [{dtype}]{value_str}  ({node_id})")
        await browse_namespace(child, indent + 1)

async def main():
    async with Client(url="opc.tcp://192.168.1.10:4840") as client:
        await client.connect()
        print("=== B&R OPC UA FX Namespace ===\n")
        objects = await client.nodes.objects.get_child(["2:Data"])
        await browse_namespace(objects)
        await client.disconnect()

asyncio.run(main())

Writing a Variable via OPC UA (Start/Stop Machine)

"""
Write a command to the PLC via OPC UA.
WARNING: Only use on a test machine or when you fully understand the system.
"""
import asyncio
from asyncua import Client

async def send_command():
    async with Client(url="opc.tcp://192.168.1.10:4840") as client:
        await client.connect()

        cmd_node = await client.nodes.objects.get_child([
            "2:Data", "2:Global", "2:gCommands", "2:bStart"
        ])

        # Edge-triggered: write TRUE, then FALSE
        await cmd_node.write_value(True)
        print("Command START sent")
        await asyncio.sleep(0.5)
        await cmd_node.write_value(False)
        print("Command START released")

        await client.disconnect()

asyncio.run(send_command())

Reading Active Alarms via OPC UA (Python)

"""
Read active alarms from mapp AlarmX via OPC UA FX namespace.
"""
import asyncio
from asyncua import Client

async def read_alarms():
    async with Client(url="opc.tcp://192.168.1.10:4840") as client:
        await client.connect()

        alarmx = await client.nodes.objects.get_child([
            "2:Data", "2:AlarmX"
        ])

        count = await (await alarmx.get_child(["2:nActiveAlarmCount"])).get_value()
        print(f"Active alarms: {count}\n")

        if count > 0:
            alarms_node = await alarmx.get_child(["2:aActiveAlarms"])
            alarms = await alarms_node.get_value()
            for i, alarm in enumerate(alarms):
                print(f"  [{i}] Code: {alarm.nCode}  "
                      f"Severity: {alarm.eSeverity}  "
                      f"Text: {alarm.sText}")

        await client.disconnect()

asyncio.run(read_alarms())

Checking mapp View Service Status

IMPORTANT: The CP1584 runs Automation Runtime (AR) on VxWorks — it does NOT provide SSH access or Linux-style process management. You cannot SSH into the controller, run ps, systemctl, or netstat commands. The correct approaches for checking mapp View status on a CP1584:

Via SDM (System Diagnostics Manager):

1. Open a web browser to http://<CP1584_IP>/SDM
2. Navigate to the Overview tab — check web server status
3. Navigate to the Task Monitor tab — look for the HTTP/WebServer task
4. Navigate to the Logger tab — check for web server errors

Via Automation Studio:

1. Connect to the controller via Online > Login
2. Open Diagnostics > Task Monitor — check HTTP server task status and cycle times
3. Open Diagnostics > System Diagnostics Manager (SDM) > Diagnostics > Software Modules

Via OPC UA:

1. Connect an OPC UA client to opc.tcp://<CP1584_IP>:4840
2. Browse to the SDM namespace for web server health indicators

Via SNMP:

snmpwalk -v1 -c public <CP1584_IP> 1.3.6.1.4.1.2706.1

See diagnostics-sdm.md for full SDM usage details.

Extracting HMI Pages from Controller via FTP

# FTP into controller (NOT SSH — CP1584 has no SSH)
ftp <CP1584_IP>

# Navigate to mapp View files on the user partition
cd F:\mappView
# or
cd F:\UserProject\mappView

# Download all HMI definition files
lcd /local/backup/
cd Pages
mget *.page
cd ../Widgets
mget *.widget
cd ../Data
mget *.data
cd ../Config
mget *.config

# .page and .widget files are XML — parseable:
# xmllint --format Main.page | head -50

NOTE: The B&R AR filesystem uses C:\ (system) and F:\ (user/application) partition notation. These are NOT Windows paths — they are VxWorks device mounts that appear as drive letters. The FTP server exposes them in this format.

Key Findings

1. mapp View is a web server inside the controller — the HMI is not a separate program. It serves HTML5/CSS3/JavaScript pages over HTTP/HTTPS from the controller itself.

2. All data flows through OPC UA FX — there is no direct PLC memory access from the HMI. Every value displayed or entered on the HMI passes through the OPC UA FX information model on port 4840.

3. HMI and control logic are fully decoupled — the PLC program has zero knowledge of the HMI. The HMI has zero knowledge of PLC program structure. This separation is enforced through the three-layer model (content, layout, logic) and the .data binding file indirection.

4. On undocumented machines, upload from target is your primary recovery tool — Automation Studio can upload the hardware config, software object list, global variables, mapp component configurations, and deployed filesystem contents. Source code cannot be recovered.

5. The .data file is the most important file — it maps every HMI element to every PLC variable. Losing it means you must reverse-engineer every variable binding by comparing what the HMI shows against what OPC UA exposes.

6. Panel replacement does not require PLC changes — because the HMI is web-based, replacing a panel is purely a network/browser configuration task. No PLC reprogramming is needed.

7. Legacy POWER WORX systems used direct memory mapping — unlike OPC UA FX, POWER WORX read/wrote PLC memory directly. If you encounter this on a CP1584, it indicates a bridged legacy display connection via the PVI library.

8. VNC is display-only — VNC mirrors what a connected Panel PC shows. It cannot be used to interact with the mapp View server directly. For full remote access, use a web browser.

9. Alarm handling is fully integrated — mapp AlarmX exposes active alarms, history, and acknowledgment status through the OPC UA FX namespace. The AlarmList widget on the HMI subscribes to this data automatically.

10. Role-based access is configured in Roles.config — without the OEM project, you may need to upload from target to discover role definitions. Default credentials vary by firmware version.

Cross-References

Document generated from reverse-engineering research on undocumented B&R CP1584 systems. All procedures should be validated on a test system before applying to production equipment.

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.

B&R CP1584 Forensic Information Extraction Guide

Overview

This guide provides a systematic methodology for extracting every possible piece of information from a B&R CP1584 programmable logic controller when no original project files, documentation, or OEM support exists. It is written for automation engineers who have inherited undocumented machines built on B&R hardware from defunct or unresponsive OEMs.

The CP1584 is a B&R X20 Compact CPU controller with an Intel Atom processor, running B&R Automation Runtime (VxWorks-based on the CP1584; newer B&R controllers use a hypervisor with Linux alongside AR). It ships with Ethernet connectivity, CF card storage, OPC-UA capability, PVI (Process Visualization Interface) support, and the SDM (System Diagnostics Manager) web service.

The extraction process follows two fundamental phases:

1. Discovery — Locate the PLC on the network and identify what services it exposes.
2. Extraction — Pull data, configuration, logs, and runtime state from every accessible interface.

Everything documented here is non-destructive and read-only unless explicitly noted. Nothing here requires physical access to the controller beyond network connectivity and (optionally) a VNC connection.

1. Network Discovery

1.1 ANSL Protocol Discovery

B&R PLCs broadcast ANSL (Automation Network Service Layer) discovery packets. These are the fastest way to find a CP1584 on an unknown network.

Wireshark capture filter:

udp port 30303 or udp port 11169

Step-by-step procedure:

1. Connect your workstation to the same physical or VLAN segment as the machine network.
2. Open Wireshark and start a capture on the active interface.
3. Apply the ANSL filter above.
4. Within a few seconds you should see broadcast packets from the CP1584 containing:
   • Device name (configurable by the OEM, often descriptive)
   • IP address
   • Serial number
   • Firmware version
   • Automation Runtime version
   • ANSL protocol version
5. Stop the capture and note the IP address.

If no ANSL packets appear, the PLC may be on a different subnet or ANSL discovery may be disabled in the controller’s network configuration.

1.2 nmap Service Scan

Once you have the IP address from ANSL or from a network diagram, scan for exposed services:

nmap -sV -p 80,21,11169,4840,5900,5800,8080,443,502 <PLC_IP>

Expected open ports and their significance:

1.3 B&R Separate IP Addresses

Some B&R hardware configurations use two independent network interfaces: one for process data/communication and one dedicated to visualization/HMI traffic. Check both interfaces during discovery. The ANSL packets will reveal both IPs if this is configured.

2. Web Interface (Port 80)

2.1 SDM — System Diagnostics Manager

The SDM is B&R’s built-in web-based diagnostics service. Access it at:

http://<PLC_IP>/sdm

What you get from SDM:

• Logbook entries — timestamped system events, errors, warnings, and info messages. This is a goldmine for understanding what the machine does, what errors it encounters, and what tasks are running.
• Task list — all running Automation Runtime tasks with CPU usage, cycle times, and memory consumption.
• Hardware configuration — installed modules, firmware versions, serial numbers.
• Network configuration — IP addresses, subnet masks, gateway, DNS.
• File system browser — limited view of the CF card directory structure.
• AR system information — Automation Runtime version, licensing status, uptime.

Step-by-step SDM exploration:

1. Open http://<PLC_IP>/sdm in a browser.

2. If prompted for credentials, try:

   • admin / no password
   • admin / admin
   • No credentials at all (anonymous access is common on older firmware) Security Warning (CVE-2025-3450): The SDM web interface has a known denial-of-service vulnerability (CVSS v3.1 7.5 High) in all AR versions before R4.93. An unauthenticated network attacker can send a crafted request to crash the controller via SDM. See diagnostics-sdm.md and ar-rtos.md Section 14.5 for full details and mitigations. When accessing SDM on unpatched systems, block port 80/443 at the firewall except during active maintenance windows, or use HTTPS with mutual TLS.

3. Navigate to Logbook and export all available entries. These contain task names, error codes, and operational context.

4. Navigate to Task Monitor and record every running task name. These map directly to PVI objects and are critical for OPC-UA/PVI reconstruction.

5. Navigate to Hardware and record all module types, serial numbers, and firmware versions.

6. Export or screenshot everything.

2.2 System Dump via SDM

The SDM web interface provides a button to create a system dump. This is a .tar.gz archive of the controller’s complete runtime state.

Procedure:

1. In SDM, navigate to Diagnostics > Create System Dump.
2. Wait for the dump to be generated (can take several minutes depending on CF card speed and system complexity).
3. Download the .tar.gz file.
4. Extract and analyze:

mkdir dump_analysis && tar -xzf system_dump.tar.gz -C dump_analysis/
find dump_analysis/ -type f

What the system dump typically contains:

• AR log files (*.log, *.arlog)
• Task memory snapshots
• Network configuration files
• License files
• Installed software package manifest
• Runtime configuration
• Variable listing (partial — may include names and data types)
• I/O mapping information
• Recipe data
• User partition file structure

2.3 Header Fingerprinting

Even if the web interface returns a 404, the HTTP response headers reveal critical information:

curl -v http://<PLC_IP>/ 2>&1 | head -30

Look for:

Server: B&R
X-Powered-By: B&R Automation Runtime

This confirms the device is a B&R controller even when the web root returns nothing useful.

3. FTP Access — CF Card Forensics

3.1 Connecting to the FTP Server

The CP1584 exposes its CF card filesystem via FTP. Connect with any FTP client:

ftp <PLC_IP>

Or with curl for scripted directory listing:

curl -s ftp://<PLC_IP>/ --list-only

Credentials to try:

• Anonymous login (anonymous / any email as password)
• admin / no password
• admin / admin
• Check the SDM network configuration page for configured FTP credentials.

3.2 Directory Structure

The CF card is organized into system and user partitions:

/                        ← System root
/System/                 ← Automation Runtime system files
/AT/                     ← Automation Runtime core
/AS/                     ← Automation Studio project files (if deployed)
/Temp/                   ← Temporary files, sometimes includes logs
/Licenses/               ← License files (.lic)
/Web/                    ← Web server files
/F:/                     ← User partition (designated as F:\ in B&R path notation)

3.3 User Partition (F:)

The user partition is where the deployed project lives. This is the most valuable target on the entire controller.

What to look for:

Recursive download of the user partition:

wget -r -nH --cut-dirs=2 ftp://<PLC_IP>/F:/ -P cp1584-user-partition/

Or with lftp (better for large transfers):

lftp -u admin, -e "mirror --verbose --parallel=4 /F:/ ./cp1584-user-partition/" <PLC_IP>

3.4 Critical Configuration Files

If present on the CF card, these files are essential for reconstruction:

• PvConfig.xml or PviConfig.xml — PVI Manager configuration including all registered variables, COMT ports, and transport types.
• opcua_config.xml or UaServerConfig.xml — OPC-UA server namespace configuration with all published nodes.
• mappServices.xml — Configuration for B&R mapp components (AlarmX, DataX, RecipeX, FileX, etc.).
• ARConfig.cfg — Automation Runtime base configuration.
• UserPar.dat or UserPar.cfg — User parameters and machine settings.
• NetworkConfig.xml — Network interface configuration.

3.5 Datalogger and Alarm Archives

The B&R mapp DataX component writes .csv or proprietary binary files to the CF card. These archives can reveal:

• Which variables are being logged and their engineering units
• Sampling rates and trigger conditions
• Historical trends that document machine behavior over time
• Alarm history with timestamps, severity, and associated variables

4. OPC-UA Data Extraction

4.1 Prerequisites

OPC-UA is the single most productive extraction point if it was configured by the OEM. Many B&R machines from the last 10+ years run an OPC-UA server because it is the standard B&R communication layer for mapp View visualization and for SCADA/ MES integration.

Connection test:

nmap -pU 4840,sT 4840 <PLC_IP>

If port 4840 is open, proceed to namespace browsing.

4.2 UaExpert — OPC-UA Client

UaExpert is a free OPC-UA client from Unified Automation that supports namespace browsing without prior knowledge of the server configuration.

Procedure:

1. Download and install UaExpert.
2. Add a new server: opc.tcp://<PLC_IP>:4840
3. If authentication is required, try:
   • Anonymous
   • Username/Password: admin / admin, User / User
   • Certificate-based (you would need the OEM’s certificate — unlikely without documentation)
4. Once connected, expand the address space tree.
5. Browse every namespace systematically. B&R OPC-UA servers typically expose:
   • Namespace 0: OPC-UA standard types (skip unless debugging)
   • Namespace 1-2: B&R system namespace with controller status, task info, hardware info
   • Namespace 3+: Application-specific namespaces created by the OEM

4.3 What to Extract from Each Namespace

For every variable node you find, record:

UaExpert extraction procedure:

1. Right-click on the top-level application namespace folder.
2. Select Add to Document > Data Access View to subscribe to all variables.
3. Export the address space: File > Export Address Space > CSV.
4. The CSV export gives you the complete node list with IDs, names, types, and descriptions.
5. Save this CSV — it is a primary artifact for project reconstruction.

4.4 Identifying Functional Groups

OPC-UA node hierarchy often reveals the machine’s functional structure:

Machine
├── Axis_Control
│   ├── Spindle_Speed      (REAL, R/W)
│   ├── Target_Position    (REAL, R/W)
│   ├── Actual_Position    (REAL, R)
│   └── Homing_Status      (BOOL, R)
├── Temperature
│   ├── Zone_1_Actual      (REAL, R)
│   ├── Zone_1_Setpoint    (REAL, R/W)
│   └── Heater_Enable      (BOOL, R/W)
├── Recipe
│   ├── Current_Recipe_Name (STRING, R/W)
│   ├── Load_Recipe        (METHOD)
│   └── Save_Recipe        (METHOD)
├── Status
│   ├── Machine_State      (UINT, R)
│   ├── Error_Code         (UINT, R)
│   ├── Error_Text         (STRING, R)
│   └── Cycle_Counter      (UDINT, R)
└── Commands
    ├── Start              (METHOD)
    ├── Stop               (METHOD)
    └── Reset              (METHOD)

Map every group and variable. This structure is essentially the machine’s functional specification.

4.5 Method and Event Nodes

B&R OPC-UA servers expose methods (callable functions) and events (notifications). In UaExpert:

• Methods appear under the object node. Right-click and select Call to see input/output argument signatures.
• Events can be subscribed to via the Event View. Subscribe to the server node to capture all events and record their fields.

Methods are especially valuable — they reveal the machine’s command interface (start, stop, recipe load, homing, etc.).

5. PVI API Access

5.1 Connecting Without a Project

The PVI Manager (Process Visualization Interface) is B&R’s native communication layer. It runs on the CP1584 and listens for PVI client connections. You can connect to it without any project files if you know the IP address and the COMT port.

Connection parameters:

5.2 PVI Transfer Tool

The PVI Transfer Tool is a standalone B&R utility that can:

• Connect to a PVI Manager by IP address and COMT port
• Browse all registered PVI objects (variables, data structures, arrays)
• Read and write variable values in real time
• Export the variable list

Connection procedure:

1. Launch PVI Transfer Tool.
2. Enter connection parameters: IP = <PLC_IP>, COMT = 350, PT = 11169.
3. Click Connect.
4. Browse the object tree. Every registered variable appears with its data type and current value.
5. Export the complete variable list.

5.3 Programmatic PVI Access (Python)

If you need scripted access, the B&R PVI protocol can be implemented over TCP. The PVI Manager on the controller accepts text-based commands on port 11169.

import socket

PLC_IP = "192.168.1.100"
COMT_PORT = 11169

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((PLC_IP, COMT_PORT))
sock.settimeout(5)

def pvi_send(cmd):
    msg = f"{cmd}\r\n"
    sock.send(msg.encode('ascii'))
    return sock.recv(4096).decode('ascii', errors='replace')

pvi_send('CN="cp",C="cp",PVT="TCPIP",PVN="<PLC_IP>"')
print(pvi_send('CM="cp",C="ST",O="CPU"'))
print(pvi_send('RN="cp",C="ST",O="CPU",LN="State"'))
print(pvi_send('RG="cp",C="ST",O="CPU",LN="State"'))

sock.close()

This is a simplified example. The full PVI protocol documentation covers connect/read/write/unconnect sequences with specific escape character handling. Refer to the B&R PVI API documentation for complete protocol details.

5.4 PVI Limitations Without Project

• You can only access variables that are registered in the PVI Manager. If the OEM did not register a variable for external access, it is invisible.
• Data structures and arrays appear as registered objects but you need to know their element layout to interpret raw byte reads.
• Variable names in PVI may differ from the OPC-UA display names — cross-reference both for complete coverage.

6. Forced I/O Reading

6.1 The Problem

Direct I/O reading (forcing, observing raw digital/analog I/O state at the hardware level) is not available without the original project configuration that defines the I/O mapping. The Automation Runtime knows which physical I/O points exist, but without the logical mapping from project files, you cannot directly correlate physical inputs/outputs to program variables.

6.2 Indirect I/O Observation via OPC-UA or PVI

If the OEM mapped I/O variables into the OPC-UA namespace or registered them in PVI, you can observe them indirectly:

1. Connect via UaExpert or PVI Transfer Tool.
2. Look for variables with naming patterns like DI_, DO_, AI_, AO_, Input_, Output_, IO_.
3. Manually activate physical inputs (push buttons, sensors) and watch for corresponding variable state changes.
4. Toggle outputs via writable variables and observe physical actuator response.

This is labor-intensive but effective for building an I/O map from scratch.

6.3 Automation Studio I/O Cross-Reference

If you eventually obtain a dummy project (see Section 8), the I/O mapping is defined in the Hardware Configuration (.hw file) within Automation Studio. The mapping connects physical I/O modules to logical variable names.

7. AR Log Analysis

7.1 Log Sources

B&R Automation Runtime generates logs from multiple sources:

7.2 Analyzing Logbook Entries

Access logbook entries through SDM or from the system dump .tar.gz:

tar -xzf system_dump.tar.gz -C dump_analysis/
find dump_analysis/ -name "*.log" -o -name "*.arlog" -o -name "logbook*"

What to extract from logs:

1. Task names — every task listed in the logbook is a PVI object and likely an OPC-UA node. Build your variable inventory from these names.
2. Error patterns — recurring errors reveal weak points in the machine, common failure modes, and what conditions trigger protective stops.
3. Timing patterns — timestamps in logs reveal cycle durations, batch processing times, and maintenance schedules.
4. Software version mentions — log entries often contain the Automation Runtime version, mapp component versions, and firmware of connected hardware.

7.3 Logbook Export Script

for log in dump_analysis/**/logbook*.txt dump_analysis/**/logbook*.log; do
  echo "=== $log ==="
  head -100 "$log"
  echo ""
done

Extract unique task names from logs:

grep -ohP '(?<=Task\s)[A-Za-z0-9_]+' dump_analysis/**/*.log | sort -u

Extract unique variable names from logs:

grep -ohP '(?<=Variable\s)[A-Za-z0-9_.:]+' dump_analysis/**/*.log | sort -u

8. Online Monitoring with Automation Studio

8.1 Dummy Project Approach

Automation Studio is B&R’s engineering environment. Full online monitoring normally requires the original project, but a dummy project with matching hardware configuration provides partial access.

Prerequisites:

• Automation Studio license
• B&R Automation Runtime version matching the target CP1584 (check SDM for the exact version)

Procedure:

1. Create a new Automation Studio project.
2. Configure the target in the Physical Hardware view:
   • Add the CP1584 CPU with the correct firmware version.
   • Add all I/O modules as identified from SDM’s hardware page and serial numbers.
3. Set the target IP address in the project configuration.
4. Connect to the target: Online > Login.
5. If the hardware configuration matches closely enough, you gain access to:
   • Variable cross-reference tables
   • Force table (for I/O forcing — read the warning below)
   • Trace/Scope (for real-time signal visualization)
   • I/O mapping display
6. You will not see the application code (ladder, ST, C, etc.) without the source — only the runtime objects and their current values.

8.2 Safety Warning

Never force outputs on an undocumented, live production machine. The force table in Automation Studio can override program logic and physically actuate outputs. Use monitoring mode only (read access). Disable the force function or confirm force tables are empty before connecting.

9. Runtime Utility Center

9.1 Overview

The Runtime Utility Center (RUC) is a B&R maintenance tool that can:

• Browse the CF card contents (system and user partitions)
• Back up the complete CF card image
• Read AR system information
• Check and update firmware
• Manage licenses
• Access the logbook

9.2 CF Card Backup

Before doing anything else, create a full CF card backup:

1. Launch Runtime Utility Center.
2. Connect to <PLC_IP>.
3. Navigate to CF Card > Backup.
4. Select a destination directory.
5. Wait for the complete backup (can take 15-60 minutes depending on card size and network speed).
6. Store the backup image securely — it is your primary recovery asset.

9.3 Browsing CF Card Contents

The RUC file browser provides a GUI view of the CF card. Use it to navigate the same paths described in Section 3 (FTP Access). The RUC browser is sometimes able to access files that FTP cannot, particularly files owned by the root system user.

10. VNC Access

10.1 Connecting to the HMI

B&R HMI applications (mapp View or older Panel pages) expose a VNC server. This gives you a live view of the operator interface.

Connection:

vncviewer <PLC_IP>:5900

Or any VNC client pointing to <PLC_IP>:5900 (or :0).

10.2 What You Can Learn from the HMI

Even without documentation, the HMI display is an invaluable information source:

• Screen navigation — map every screen, every button, every indicator.
• Variable names visible in headers/status bars — B&R developers sometimes leave debug information visible.
• Alarm lists — active and historical alarms reveal machine conditions.
• Recipe screens — parameter names, ranges, and units reveal the machine’s process.
• Trends/graphs — trend displays show which variables are being monitored and their expected behavior.
• Axis control screens — reveal the number of servo axes, their names, and control modes.
• Login screen — attempt default passwords: admin/admin, operator/operator, maintenance/maintenance.

10.3 Screen Capture and Documentation

Systematically document every HMI screen:

import subprocess, time

for i in range(50):
    time.sleep(2)
    subprocess.run(['scrot', f'hmi_screen_{i:03d}.png'])

(Navigation through screens must be done manually or via touchscreen if accessible.)

11. Network Traffic Analysis

11.1 Passive Capture Strategy

If you can physically tap into the network segment (mirror port, network tap, or hub), capture all traffic to and from the CP1584:

tshark -i eth0 -w cp1584_capture.pcap -f "host <PLC_IP>" -c 500000

11.2 Protocol Analysis

ANSL traffic (port 11169):

tshark -r cp1584_capture.pcap -Y "tcp.port == 11169" -T fields -e tcp.payload | head -20

This reveals PVI Manager communication including variable names, data types, and read/write operations from connected HMI panels, SCADA systems, or secondary controllers.

OPC-UA traffic (port 4840):

tshark -r cp1584_capture.pcap -Y "tcp.port == 4840" -T fields -e frame.time -e ip.src -e ip.dst

OPC-UA traffic reveals what external systems are connected and how frequently they poll the controller.

HTTP traffic (port 80):

tshark -r cp1584_capture.pcap -Y "http" -T fields -e http.request.uri -e http.host

This reveals what web-based systems are accessing the SDM or any custom web pages served from the CF card.

11.3 Discovering Communication Partners

From the captured traffic, build a map of all systems that communicate with the CP1584:

tshark -r cp1584_capture.pcap -T fields -e ip.src -e ip.dst | sort -u

This reveals the full automation network topology — SCADA servers, HMI panels, secondary PLCs, MES systems, and any other devices the CP1584 communicates with.

12. Systematic Extraction Workflow

Execute the following steps in order. Each step builds on the previous and maximizes coverage.

Phase 1: Non-Invasive Discovery

• 1.1 Wireshark ANSL discovery — identify IP, name, firmware
• 1.2 nmap service scan — identify open ports and services
• 1.3 Web browser to http://<PLC_IP>/sdm — check SDM access
• 1.4 Web browser to http://<PLC_IP>/ — check for custom web pages or 404 with B&R headers
• 1.5 FTP anonymous login attempt — check CF card access
• 1.6 VNC connection attempt — check HMI visibility
• 1.7 OPC-UA connection attempt with UaExpert — check namespace accessibility

Phase 2: Data Collection

• 2.1 SDM: Export all logbook entries
• 2.2 SDM: Record all running tasks with cycle times
• 2.3 SDM: Record complete hardware configuration
• 2.4 SDM: Create and download system dump
• 2.5 FTP: Recursive download of F:\ (user partition)
• 2.6 FTP: Download any .log, .csv, .xml, .cfg, .ini files from system partition
• 2.7 UaExpert: Export complete OPC-UA address space to CSV
• 2.8 UaExpert: Subscribe to all variables and capture current values
• 2.9 UaExpert: Document all methods (callable functions) and their signatures
• 2.10 UaExpert: Subscribe to events and capture event definitions
• 2.11 PVI Transfer Tool: Connect and export variable list
• 2.12 VNC: Document all HMI screens (screenshots, navigation map)
• 2.13 Runtime Utility Center: Full CF card backup
• 2.14 Network capture: Record all traffic for 24-48 hours if possible

Phase 3: Analysis

• 3.1 Cross-reference OPC-UA variable names with PVI variable names
• 3.2 Cross-reference variable names with CF card file contents (config files, log files)
• 3.3 Cross-reference task names from SDM with variable name prefixes from OPC-UA
• 3.4 Analyze system dump for AR configuration and variable definitions
• 3.5 Analyze log files for recurring patterns, error sequences, and operational context
• 3.6 Map the complete communication network from captured traffic
• 3.7 Build functional group hierarchy from OPC-UA namespace structure
• 3.8 Identify all I/O mapping relationships between physical signals and logical variables

Phase 4: Reconstruction (Prerequisite: see project-reconstruction.md)

• 4.1 Create dummy Automation Studio project with matching hardware
• 4.2 Import OPC-UA namespace export to generate variable declarations
• 4.3 Map all identified variable groups to functional software modules
• 4.4 Document the machine’s complete functional specification
• 4.5 Develop a migration plan if the CP1584 needs replacement

Key Findings Summary

Cross-References

Emergency Recovery Contacts

If all extraction methods fail and the machine is critical:

• B&R Technical Support — can provide firmware recovery images and remote diagnostics. Requires proof of ownership or partnership.
• B&R Academy — training resources for Automation Studio and B&R system architecture.
• B&R Partner Network — authorized B&R partners may have experience with similar machines and can provide consulting.

IO Card Message Sniffing for Sensor Diagnostics on B&R PLCs

A comprehensive technical guide to intercepting, capturing, and analyzing fieldbus traffic for sensor fault diagnosis on B&R Automation PLC systems (X20, X67, System 2003/2005, APROL).

Table of Contents

1. Theoretical Approaches to Intercept Fieldbus Traffic
2. Passive Tapping vs Active Sniffing
3. Hardware Requirements per Protocol
4. Wireshark Setup for POWERLINK and PROFINET
5. CAN Bus Sniffing Tools
6. X2X Bus Sniffing with Logic Analyzers
7. Correlating Captured Data with IO Module Addresses
8. Filtering Techniques to Isolate Sensor Data
9. Timing Analysis for Intermittent Issues
10. Practical Diagnostic Workflows
11. Legal and Safety Considerations
12. Tools Comparison Table
13. Sources and References

1. Theoretical Approaches to Intercept Fieldbus Traffic

1.1 B&R Protocol Stack Overview

B&R Automation systems use multiple fieldbus and industrial Ethernet protocols depending on the IO system generation and bus controller selected:

1.2 X2X Link

X2X Link is B&R’s proprietary serial bus for connecting X20 I/O stations to the bus controller. It runs on a twisted-pair physical layer derived from RS-485, operating at up to 12 Mbaud. The protocol is closed-source and undocumented at the packet level, which makes full decoding difficult without reverse engineering.

Key characteristics:

• Physical: RS-485 transceiver (differential pair), daisy-chain topology
• Speed: Up to 12 Mbaud (B&R specific encoding)
• Topology: Multi-drop from bus controller, up to 64 stations per segment
• Frame structure: Proprietary; includes addressing, CRC, and cyclic data payloads
• Update rate: Sub-millisecond, depending on station count and configuration

Interception approach: Since X2X is a closed protocol, interception focuses on signal-level analysis using logic analyzers rather than packet-level decode. You can observe timing, signal integrity, and bus utilization to diagnose physical-layer problems. For data-level analysis, the preferred approach is to use B&R’s own diagnostic tools (Automation Studio watch window, mapp Diagnostic) and correlate with the captured signal patterns.

1.3 ETHERNET Powerlink (EPL)

ETHERNET Powerlink is an open-source (EPL v2.0+) real-time Ethernet protocol managed by the EPSG (Ethernet POWERLINK Standardization Group). It operates on standard Fast Ethernet (100BASE-TX) and uses a slot-based TDMA mechanism managed by a Managing Node (MN) - typically the B&R PLC CPU.

Frame types:

Key characteristics:

• Physical: Standard 100BASE-TX Ethernet, half-duplex
• MAC: Uses custom ethertype or LLC/SNAP encapsulation
• Cycle time: Configurable, 200us to 100ms typical
• Addressing: Node IDs (1-239), node 240 = MN
• Data format: Little-endian

Interception approach: Powerlink runs on shared Ethernet media (hub or switch in “passthrough” mode for EPL phase 1). Since it uses standard Ethernet frames with a recognizable ethertype, you can connect a PC with a standard NIC in promiscuous mode directly to the bus via a hub or tap. Wireshark includes a native POWERLINK dissector.

1.4 PROFINET IO

PROFINET uses standard Ethernet frames for real-time I/O exchange. There are three performance classes:

Key PROFINET protocols on the wire:

• pn_dcp: Discovery and Configuration Protocol (device naming, IP assignment)
• pn_rt: Real-Time cyclic data frames (cyclic I/O)
• pn_io: Application layer (connection setup via DCE/RPC over UDP 34964)
• pn_ptcp: Precision Time Control Protocol (IRT clock sync)
• lldp: Link Layer Discovery Protocol (topology)

Interception approach: PROFINET RT/IRT frames are Layer 2 ethertype 0x8892 - they bypass TCP/IP entirely. You must capture on the Ethernet interface directly (via tap or SPAN port). Wireshark has full PROFINET dissectors built in.

1.5 CANopen

CANopen is a higher-layer protocol built on top of CAN 2.0A/B (ISO 11898). It uses an object dictionary (OD) model with specific communication objects:

Key characteristics:

• Physical: CAN 2.0B, differential pair (CAN_H, CAN_L), twisted pair
• Speed: 1 Mbps max (typical: 125 kbps - 1 Mbps)
• Addressing: 11-bit (standard) or 29-bit (extended) CAN identifiers
• Topology: Multi-drop bus with termination resistors (120 ohm at each end)

Interception approach: CANopen runs on CAN bus, which requires a CAN interface adapter (USB, PCI, or embedded). You connect the CAN adapter to the bus via a Y-cable or tap, and use specialized software to decode CANopen protocols. The object dictionary mapping (PDO/SDO) tells you which sensor data maps to which CAN IDs and byte offsets.

2. Passive Tapping vs Active Sniffing

2.1 Passive Tapping

Passive tapping inserts a hardware device inline on the communication link that copies all traffic to a monitoring port without participating in the protocol. The key property is zero interference with the live system.

Advantages:

• No impact on timing, latency, or determinism of the live network
• Cannot introduce errors or crash the production system
• Invisible to protocol participants (no MAC address on the network)
• Safe for safety-critical and hard-real-time systems
• Captures all traffic including collisions and physical-layer errors

Disadvantages:

• Requires physical access to insert the tap
• May need network downtime to install (unless using breakout taps on existing connections)
• Full-duplex Ethernet requires two capture interfaces (or an aggregate tap)
• Cannot trigger or inject messages for active diagnostics

Passive tap types:

2.2 Active Sniffing

Active sniffing involves connecting a device as a participant on the network, either as a fully-featured node or as a promiscuous-mode listener.

For Ethernet (POWERLINK/PROFINET):

• Connect a PC NIC directly to a switch port or hub
• Configure the NIC in promiscuous mode to capture all frames
• For POWERLINK: connect to a hub or directly to the bus (half-duplex shared medium)
• For PROFINET: use managed switch port mirroring (SPAN) to copy traffic

Advantages:

• Can use standard PC hardware and software (Wireshark)
• Can inject traffic for active testing (e.g., ping, DCP requests)
• No special tap hardware needed for basic capture
• Can participate in protocol negotiations to aid decoding

Disadvantages:

• Adds a device to the network (potential timing impact on shared-medium networks)
• PC NIC OS-level timestamps are inaccurate (microsecond range at best, affected by scheduling)
• May cause issues if the PC sends unwanted packets (TCP/IP stack, ARP, etc.)
• Cannot capture collisions or physical-layer anomalies
• Some protocols may reject unknown nodes

B&R-specific consideration: For POWERLINK, B&R’s own documentation states: “To record data traffic, an Ethernet port of the PC is connected directly to the POWERLINK network at any point.” This works because POWERLINK Phase 1 uses a shared Ethernet medium. However, B&R also notes that PC-based capture has “inaccurate timestamps” and recommends the X20ET8819 hardware analysis tool for precise diagnostics.

2.3 Choosing Between Approaches

3. Hardware Requirements per Protocol

3.1 ETHERNET Powerlink

X20ET8819 Specifications (B&R’s recommended tool):

• X20 form factor, slides directly into X20 backplane
• 2x RJ45 Ethernet ports for inline connection
• Hardware-based timestamps in nanosecond range
• Trigger inputs (digital inputs or software trigger)
• Filter-based recording to minimize file size
• Compatible with Automation Studio for analysis
• Ideal for sporadic/intermittent faults

3.2 PROFINET IO

Switch port mirroring setup:

1. Configure the switch port where the IO device is connected as the source (monitored) port
2. Configure a spare port as the destination (mirror) port
3. Connect the capture PC to the destination port
4. Ensure the mirror port can handle the full bandwidth of monitored traffic

3.3 CANopen

3.4 X2X Link (Serial/RS-485)

Connection method for X2X with logic analyzer:

1. Locate the X2X bus wires (typically labeled X2L+/X2L- or similar on terminal blocks)
2. Connect RS-485-to-TTL converter: A (non-inverting) to one channel, B (inverting) to another
3. Set logic analyzer sample rate: minimum 10x the bus speed (for 12 Mbaud: 120 MHz minimum)
4. Record for at least one full bus cycle to observe repeating patterns
5. Analyze using UART async serial protocol decoder (may require custom baud rate settings)

4. Wireshark Setup for POWERLINK and PROFINET

4.1 Wireshark for POWERLINK

Based on official B&R community documentation:

Step 1: Prepare the network interface

• Deactivate all unneeded protocols (TCP/IP, Windows file sharing, etc.) on the capture interface
• These can interfere with the POWERLINK network by generating unwanted packets
• In Windows: Uncheck all items except “Wireshark Npcap Loopback Adapter” in adapter properties
• In Linux: ip link set eth0 down && ip link set eth0 up promisc on

Step 2: Recommended NIC settings

• Half-duplex mode
• 100 Mbit/s transmission rate
• Auto-crossover enabled (or use a crossover cable)

Step 3: Connect to the POWERLINK network

• Connect the PC Ethernet port directly to the POWERLINK network at any point
• A hub can be used between the PC and the network if direct connection fails
• Verify link LEDs indicate active connection

Step 4: Start capture in Wireshark

• Select the connected interface in Wireshark’s start screen
• Double-click the interface or click the blue shark fin icon to start recording

Step 5: POWERLINK Display Filters

Step 6: Analysis tips

• Sort packets by the “Time” column to recognize the recurring POWERLINK cycle
• Use Wireshark’s coloring rules to distinguish frame types (SoA = one color, PRes = another, ASnd = another)
• Create a custom column for PRes payload: right-click “Payload” in a PRes frame -> “Apply as Column” -> rename to “PRes-Payload”
• Note: POWERLINK user data is transmitted in little-endian format

Limitations of PC-based capture:

• Inaccurate timestamps (OS scheduling jitter affects precision)
• Large file sizes for extended captures
• Cannot reliably capture sporadic errors
• For precise timing analysis, use B&R X20ET8819 instead

4.2 Wireshark for PROFINET

Step 1: Install Wireshark

• Download from https://www.wireshark.org
• Install with Npcap (Windows) or libpcap (Linux) for packet capture driver
• PROFINET dissectors are built-in: pn_rt, pn_io, pn_dcp, pn_ptcp

Step 2: Capture setup

• PROFINET RT uses EtherType 0x8892 (not TCP/IP!) - you cannot filter by TCP port
• Capture all Ethernet traffic on the interface (no capture filter) for full visibility
• Optional capture filter to reduce noise: ether proto 0x8892 (only PROFINET RT/DCP/PTCP)

Step 3: Connect to the PROFINET network

• Method A (Preferred): Managed switch with SPAN/port mirroring - mirror the IO device port to a monitoring port, connect PC to monitoring port
• Method B: Inline Ethernet tap between PLC and switch
• Method C: Direct connect (only if the PROFINET device supports it)

Step 4: PROFINET Display Filters

Step 5: Decoding cyclic I/O data

• Critical: Wireshark can decode cyclic data to module level ONLY if it captures the DCE/RPC connection setup
• Best practice: Start Wireshark BEFORE powering on the IO device or restarting the PLC
• If connection setup is missed, cyclic data shows as raw bytes without module context
• Import PI PROFINET coloring rules: View -> Coloring Rules -> Import (colors: RT=green, DCP=blue, Alarms=red, LLDP=yellow)

Step 6: Custom columns for PROFINET diagnostics

5. CAN Bus Sniffing Tools

5.1 Hardware Interfaces

PEAK PCAN (PEAK-System Technik GmbH)

• PCAN-USB: Basic USB-to-CAN adapter, galvanically isolated
• PCAN-USB FD: Supports CAN FD, 2 channels
• PCAN-USB Pro FD: 4 channels, CAN/CAN FD
• PCAN-View: Free monitoring software included
• Pros: Affordable, reliable, good Linux support, free software
• Cons: Limited scripting compared to Vector

Vector Informat

• VN1610/VN1611: Professional CAN/CAN FD/LIN interfaces (1-4 channels)
• VN1630/VN1640: High-channel-count interfaces
• CANalyzer: Professional analysis software (CANopen, J1939, etc.)
• CANoe: Full simulation + analysis environment
• CANalyzer.CANopen: CANopen-specific analysis option with OD support
• Pros: Industry gold standard, extensive protocol support, powerful scripting (CAPL)
• Cons: Expensive (license starts ~$3,000+)

Kvaser

• Kvaser Leaf Light: Budget single-channel CAN
• Kvaser Memorator: Data logger with onboard storage
• Kvaser CANKing: Included analysis software
• Pros: Robust, good Linux drivers, Scripting with tscript
• Cons: Software less capable than Vector CANalyzer

SocketCAN (Linux)

• Built-in CAN stack in Linux kernel since 2.6.25
• Works with: PEAK PCAN, Kvaser, SocketCAN-native devices (e.g., Microchip MCP2515-based)
• Tools: candump, cansend, cansequence, cansniffer, canplayer
• cansniffer provides a live hexadecimal/ASCII view of the bus
• Python: python-can library provides high-level access
• Pros: Free, scriptable, integrates with Linux ecosystem
• Cons: No GUI analysis tool comparable to CANalyzer; limited CANopen decode

Other Tools

• CanLover: Free, modern CAN bus analyzer for Linux/Windows, CANalyzer alternative, native SocketCAN
• Kayak: Java-based open-source CAN traffic GUI
• CanCat: Open-source CAN bus penetration testing tool
• Busmaster: Open-source tool by RBEI (supports CAN, J1939, CANopen)

5.2 CANopen-Specific Analysis

For CANopen sensor diagnostics, the key is mapping CAN IDs to object dictionary entries:

TPDO/RPDO mapping (process data):

• TPDO1: CAN ID 0x180 + NodeID (default)
• RPDO1: CAN ID 0x200 + NodeID (default)
• The PDO mapping (in the OD at index 0x1A00/0x1600) tells you which sensor values are at which byte offset
• Example: A temperature sensor at NodeID 5 sends TPDO1 on CAN ID 0x185; bytes [0:1] = temperature in 0.1°C units

SDO access (configuration/diagnostics):

• SDO Receive: CAN ID 0x600 + NodeID
• SDO Transmit: CAN ID 0x580 + NodeID
• Use SDO to read diagnostic objects, error history, manufacturer-specific status

Emergency messages:

• CAN ID 0x080 + NodeID
• Contains error code, error register, and vendor-specific data
• Filter for these to quickly identify failing devices

Heartbeat monitoring:

• CAN ID 0x700 + NodeID
• Consumer heartbeat time in OD index 0x1016
• Missed heartbeats = node offline or bus problem

5.3 Practical CAN Sniffing Setup for B&R Systems

1. Locate the CAN bus access point: B&R X20CC modules have CAN bus terminals. Use a DB9 Y-adapter to tap in.
2. Configure the CAN adapter: Set baud rate to match the B&R project configuration (check in Automation Studio)
3. Start capture: Use candump can0 (SocketCAN) or PCAN-View
4. Apply CANopen decode: If using CANalyzer with CANopen option, load the EDS/EDD file from the IO module manufacturer
5. Monitor: Watch for EMCY (emergency) messages, heartbeat timeouts, or missing PDOs from specific nodes