B&R Automation Runtime (AR) — RTOS Internals Technical Reference

Compiled from official B&R documentation, B&R Community forum posts, training materials, security advisories, and press releases.

1. Underlying OS Architecture

1.1 Base OS: VxWorks (Wind River Systems)

Automation Runtime is based on VxWorks, the industry-standard RTOS from Wind River Systems (a subsidiary of Aptiv). This was confirmed officially by B&R employees on the B&R Community forum.

“Automation Runtime is definitely based on VxWorks. For sure, B&R developed a lot of additional functions, task class scheduling, drivers and abstraction layers needed for PLCs (that’s the reason why it’s called by its own name AutomationRuntime), but the base is still VxWorks until now.” — B&R Community forum, 2024

Key evidence:

• B&R’s own Cyber Security Advisory #01/2019 states: “B&R Automation Runtime software is based on VxWorks and these vulnerabilities affect a range of Automation Runtime versions…”
• VxWorks is a proprietary, Unix-like, scalable RTOS developed by Wind River Systems, widely deployed in mission-critical embedded systems.

1.2 B&R Extensions on Top of VxWorks

B&R has built a substantial layer on top of VxWorks:

• Custom task class scheduling — B&R’s unique cyclic task class model (Cyclic #1 through #8) with configurable cycle times and tolerance
• PLC-specific drivers — X2X bus drivers, POWERLINK, Ethernet/IP
• Hardware abstraction layer (HAL) — isolates user programs from hardware specifics; applications run identically across different B&R controllers
• I/O management subsystem — synchronized I/O cycle with task classes
• Non-volatile memory management — User ROM, User RAM, Retain, Remanent memory systems

1.3 exOS (Enhanced Crossover Operating System) — Linux Side

Starting around 2020, B&R introduced exOS, allowing Linux code to run alongside Automation Runtime on the same hardware:

“The enhanced crossover Operating System (exOS) allows machine builders to use any Linux code within their B&R system.” — B&R Press Release, 2020-12-09

Architecture:

• On dual-core/multi-core B&R controllers (e.g., Automation PC / APC series), cores can be assigned to either:
  • Automation Runtime (RTOS) — real-time control
  • GPOS (Linux) — general-purpose OS via exOS
• Starting with AR 6.4 and AS 6.5, cores can be assigned dynamically to either GPOS or AR
• Communication between AR and Linux uses a buffered API for process data exchange
• Shared memory is used for data exchange between the two sides

1.4 Hardware Platform Evolution

Note: The CP1584 uses an Intel Atom processor clocked at 0.6 GHz with 256 MB DDR2 SDRAM, USB, Ethernet, POWERLINK, and removable CompactFlash. Newer controllers use increasingly powerful Intel Atom and Core i processors.

2. Process Model

2.1 Program Loading and Execution

AR does not use traditional OS processes. Instead, it uses a flat task model where all user code runs within the AR runtime environment as tasks:

1. Program Transfer: Automation Studio compiles IEC 61131-3 code (ST, LD, FBD, IL, SFC), Automation Basic, and C/C++ into object code
2. Transfer to controller: Object code is transferred via Ethernet, USB, or loaded from CompactFlash/CFast card
3. Storage locations:
   • User ROM (Flash): Non-volatile storage for program code and configuration
   • User RAM (DRAM): Volatile runtime memory for variables
   • Retain memory: Battery-backed or flash-backed persistent data (survives power cycle)
   • Remanent memory: Flash-backed persistent data (survives power cycle, no battery needed)
4. Startup sequence:
   • Controller boots → VxWorks kernel starts → AR runtime initializes
   • System configuration loaded from User ROM
   • Init routines execute (INIT section of each task)
   • Cyclic routines begin executing per task class configuration

2.2 Task Model

• User programs are organized into tasks (logical units of code)
• Tasks are assigned to task classes (Cyclic #1 through #8)
• Each task class has a configurable:
  • Cycle time — e.g., 1 ms, 10 ms, 100 ms
  • Tolerance — watchdog window for cycle time violation
  • Task class idle time — reserved time for system tasks
• Tasks within the same task class are executed sequentially within the cycle
• There is no process isolation between user tasks — all tasks share the same address space (flat memory model)

2.3 No Traditional Process Isolation

Unlike Linux or Windows, AR tasks do not have separate address spaces. All user code runs in a shared memory space within the AR runtime. This means:

• A pointer error in one task can corrupt memory used by another task
• Page faults (error 25314) can be caused by any task accessing invalid memory
• There is no memory protection between tasks
• The IecCheck / AdvIecChk libraries provide runtime bounds checking as a debugging aid (not for production)

3. Task Scheduler Internals

3.1 Priority System (0–255)

AR operates on a priority-based preemptive scheduling system derived from VxWorks, with priorities 0–255:

“Automation Runtime operates on a priority system (0-255). The higher the priority number of a task, the higher priority it has when multiple tasks want to run at the same time.” — B&R Community Wiki

Priority bands (documented by community members):

3.2 Cyclic Task Classes

• Up to 8 cyclic task classes (Cyclic #1 through Cyclic #8)
• Cyclic #1 has the highest priority among cyclics; Cyclic #8 has the lowest
• Each task class has a configurable cycle time and tolerance (watchdog window)
• Tasks within a task class execute sequentially each cycle
• The System Tick (base timer for all AR) determines the minimum configurable cycle time

3.3 Preemptive Scheduling

• When a higher-priority task becomes ready to run, it preempts the currently running lower-priority task
• Cyclic tasks always preempt system tasks
• Within cyclic task classes, tasks run to completion before the next task in the same class starts

3.4 Task Class Idle Time

A critical mechanism for allowing system tasks to execute:

• Configured per task class (by default: Cyclic #2, 20ms cycle, with 2ms idle time at the end)
• During the idle time window, cyclic tasks yield and system tasks can execute
• Implemented via the TcIdleFiller mechanism:
  • Affected task classes are moved to priority 2
  • TcIdleFiller runs at priority 3 (always ready to run, yields to everything higher)
  • If no system tasks need to run, TcIdleFiller runs no-ops
  • This time is counted as CPU usage (not idle), which can make SDM report artificially high CPU

3.5 Cycle Time Enforcement (Watchdog)

• Each task class has a tolerance value — if the cycle exceeds cycle_time + tolerance, a cycle time violation occurs
• Violation behavior:
  • Logged in the logbook
  • Controller enters Service Mode (all task classes halted)
  • Revision notes (AR 6.6.2): Added “Watchdog after a cycle time violation when the task (task class) is in the safe state (e.g. in a critical section)”

3.6 Multicore Scheduling (AR 6.1+)

Starting with Automation Runtime 6.1, B&R introduced multicore support:

• Tasks can be dynamically distributed across cores based on load
• Dynamic load balancing to least-utilized cores
• AR 6.5 hard real-time core assignment: In AS 6.5, individual task classes (Cyclic #1-#8) can be pinned to specific CPU cores via the Hardware Configuration in Automation Studio. This enables true deterministic hard real-time execution on dedicated cores, isolating time-critical control tasks from system and communication tasks. Configuration is per-task-class under the CPU’s “Multicore” settings. Note: not all CPUs have multiple cores available for AR (some cores may be reserved for GPOS/exOS or the BIOS); check the system datasheet for core availability.
• IO scheduler cannot benefit from multicore
• Synchronization primitives needed (AsSem Standard Library) to prevent race conditions on shared memory
• Not all hardware supports multicore (check System Datasheets; BIOS may reserve cores)

4. System Call Interface

4.1 How User Code Interacts with the RTOS

User programs interact with AR through B&R standard libraries (function blocks / FUBs) rather than direct OS system calls. These libraries wrap underlying VxWorks and B&R-specific OS calls.

4.2 Key Standard Libraries

4.3 No Direct VxWorks API Access

User programs in IEC languages (ST, LD, FBD, etc.) cannot call VxWorks APIs directly. Only C/C++ programs compiled with the B&R C compiler can potentially access lower-level functions, but this is not documented for general use.

4.4 Online Services API

Automation Studio communicates with the controller via an online protocol for:

• Variable monitoring (Watch window)
• Trace/oscilloscope
• Logger access
• Program transfer (download/compare)
• Profiling
• Force variables

These use the ANSL (Automation Network Service Layer) protocol running as a system task.

4.5 Practical Runtime Monitoring from IEC Code

The AsArProf library provides runtime profiling capabilities directly from IEC code:

PROGRAM _CYCLIC
    VAR
        cpuUsage    : REAL;
        cycleTime   : LTIME;
        idleShow    : DINT;
        taskInfo    : STRING;
    END_VAR

    (* Read CPU usage using AsArProf *)
    cpuUsage := AsArProf.GetCpuUsage();

    (* Read current task's cycle time *)
    cycleTime := _taskGetCurrentCycleTime();

    (* Log idle time statistics (for diagnosing high CPU) *)
    (* This shows how much time is available for system tasks *)
    idleShow := AsArProf.LogIdleShow();

    (* Write diagnostic info to the logbook *)
    IF cpuUsage > 80.0 THEN
        ArEventLog.LogInfo(0, 0, 'High CPU usage detected: %.1f%%', cpuUsage);
    END_IF
END_PROGRAM

For monitoring system variables externally without IEC code access, see system-variables.md. For building external Python-based monitoring tools, see python-diagnostics.md.

5. Interrupt Handling

5.1 No User-Defined ISRs

This is a critical design decision:

“Since the Automation Runtime and the whole hardware ecosystem is based on a deterministic runtime behavior, there’s no functionality like ‘user defined IRQ / ISR’ (because this could disturb the realtime operation, for example if the ISR takes too long to execute).” — B&R Community, 2024

AR deliberately excludes user-defined interrupt service routines to maintain deterministic timing.

5.2 IRQ Task Classes

B&R provides IRQ task classes for hardware interrupt handling:

“Each interrupt capable module can be assigned an interrupt task (IRQ task for short) which is processed each time the corresponding interrupt is triggered.” — B&R Programming Training Document

• IRQ tasks are assigned to specific hardware modules (e.g., digital input modules with interrupt capability)
• They execute at a priority higher than Cyclic #1 (>230 priority range)
• The interrupt triggers the associated task to execute in its configured task class
• This is the sanctioned way to handle hardware events in AR

5.3 HW Interrupts and I/O Scheduling

• Hardware interrupts and I/O scheduling run at priorities greater than 230
• This includes the X2X bus cycle, POWERLINK communication
• The I/O cycle is synchronized with task class cycles (configurable per task class)

5.4 Interrupt Latency

Not publicly documented with specific numbers. However:

• AR guarantees deterministic behavior with configured cycle times
• Minimum achievable cycle time depends on the specific controller (some support sub-1ms)
• The X2X bus and I/O updates are deterministic and synchronized with the task class cycle

5.5 reACTION Technology

For extremely fast responses, B&R offers reACTION modules (X20DS/DSP and X20DC/counter modules):

• Hardware-level response times in the microsecond range
• Edge detection and nettime timestamps at the module level
• Offloads time-critical processing from the CPU to the I/O module itself

6. Memory Management

6.1 Memory Regions

AR uses a structured memory layout with named partitions. For the complete CP1584 address map with specific addresses and sizes, see memory-map.md. For battery-backed data management, see retentive-data.md.

6.2 Memory Configuration

• Memory sizes are configurable per controller in the CPU properties (Memory configuration section)
• Configurable devices for Retain and Remanent memory
• Must ensure configured sizes >= used sizes (build error if insufficient)
• Automation Studio provides offline memory usage analysis

6.3 Heap Management

• AsMem library provides memory allocation functions for dynamic memory
• No detailed public documentation on heap implementation (VxWorks memPartLib / memLib likely underneath)
• Memory fragmentation can occur with dynamic allocation
• System tasks like NvFlushHandler handle non-volatile memory flush operations

6.4 Stack Management

• Each task has its own stack (size typically configurable)
• No public documentation on default stack sizes or limits
• Stack overflow could cause page faults

6.5 Memory Protection

• Limited memory protection between user tasks (flat address space)
• The processor MMU can detect accesses to invalid/protected memory regions → triggers page fault (error 25314)
• No isolation between tasks — a corrupt pointer in one task can corrupt another task’s data
• Memory can become invalid and be relocated during online transfers, causing “Value applied from references” issues

6.6 Memory Access Violations

Error 6804 (memory access violation) can precede error 25314 (page fault / EXCEPTION). The AR exception handler logs these and transitions the controller to Service Mode.

7. Hardware Abstraction Layer (HAL)

7.1 Purpose

The HAL is a B&R-developed abstraction layer that sits between the AR runtime and the underlying hardware:

“Thanks to an abstraction layer, applications run identically on all B&R hardware platforms.” — B&R Automation Runtime product page

7.2 What the HAL Abstracts

• Processor architecture (PowerPC → Intel Atom → Intel Core i migration)
• Memory controller and bus interfaces
• I/O bus (X2X backplane communication)
• Communication interfaces (Ethernet, POWERLINK, USB, serial)
• Storage (CompactFlash, CFast, SATA flash, onboard flash)
• Hardware timers and interrupt controllers

7.3 HAL Benefits

• Portability: User programs compiled once can run on different B&R controllers
• Hardware independence: Same program runs on X20CP1584, X20CP1684, APC910, etc.
• Online software comparison: AR can compare the compiled code on the controller with the code in Automation Studio

8. Monitoring Runtime Behavior for Debugging

8.1 Automation Studio Profiler

• Task and system runtime measurement built into Automation Studio
• Shows per-task CPU usage, execution times, priorities
• From AR 6.3+: multicore-aware profiler showing per-core utilization
• Shows the TcIdleFiller no-op time separately
• Can identify which tasks consume the most CPU time

8.2 System Diagnostics Manager (SDM)

• Web-based diagnostic interface built into AR (V3.0+)
• Accessible via standard web browser from any location
• Displays:
  • CPU usage (historical and real-time)
  • Task class cycle times
  • Memory usage
  • System status
  • I/O module status
• Runs as a low-priority system task — does not interfere with cyclic tasks
• Opening SDM in a browser adds some CPU load due to cyclic data transfer (CGI interface)
• CPU usage is calculated as: 100% - [time spent at Priority 0, IDLE]

8.3 Logger (Logbook)

• Central logging system accessible via Automation Studio (Open → Logger) or SDM
• Multiple log categories:
  • System log — OS-level events, errors, warnings (includes error 25314, 6804, etc.)
  • User log — Application-specific log entries via ArEventLog library
• Each log entry has a timestamp, severity, and optional backtrace
• Backtrace tab: For errors like page faults, shows the call stack with clickable links to source code (when debug symbols are available)
• Logbook persists across reboots; stored on non-volatile memory

8.4 Watch Window

• Real-time variable monitoring
• Can watch any variable from any task
• Does not require code changes

8.5 Trace (Oscilloscope)

• Variable trace function for graphical display of variable values over time
• Common commissioning tool for timing analysis

8.6 Single Step and Disassemble

• Automation Studio supports single-stepping through code on the target
• Disassemble function for examining compiled code
• Debugger stops tasks (not cores) — in multicore, all instances of a task are stopped regardless of which core they run on

8.7 System Dump

• Diagnostic tool for collecting complete logs from the PLC
• Downloadable over Ethernet without needing a CF card
• Includes logger files and system state information
• Openable in Automation Studio for analysis

9. System Variables Exposed by AR

9.1 CPU Usage

• LogIdleShow function block (AsArProf library) — provides CPU usage as a programmable variable
  • Returns the same value as the SDM CPU usage display
  • Based on underlying system functions measuring idle time
• SDM: Always available via web interface
• Not available as a direct CPU datapoint — must use LogIdleShow function block

9.2 Task Cycle Times

• Visible in the Profiler and SDM
• Shows current execution time per task class
• Shows tolerance and configured cycle time
• Task class idle time visible

9.3 Memory Usage

• Automation Studio provides offline memory usage analysis (per variable, per task, total)
• DRAM usage measured once on the target
• Memory configuration sizes visible in CPU configuration
• Used vs. configured for User ROM, User RAM, Retain, Remanent

9.4 CPU Temperature

• Available as a CPU datapoint (unlike CPU usage)
• Configurable datatype

9.5 I/O Module Status

• Available via SDM and I/O configuration
• Module insertion/removal detection
• Diagnostic data per channel

9.6 System Task Information

Visible in the Profiler:

• IDLE — priority 0 no-op task
• TcIdleFiller — priority 3 no-op during task class idle time
• NvFlushHandler — non-volatile memory flush handler
• sataXbdReqSvc — SATA/flash disk request service
• mvLoader — module loader
• mvRpctxtfmt — runtime context formatting
• ANSL, TCP, UDP, webserver, visualization tasks
• I/O bus cycle tasks

10. Crash, Exception, and Watchdog Handling

10.1 Service Mode

When a critical error occurs, the controller enters Service Mode — all task classes are halted:

“Service mode means that no task classes are running on the PLC. The application program is not running; the PLC is halted.”

Triggers for Service Mode:

1. Reset button pressed on the PLC
2. “Stop Target” command from Automation Studio
3. Critical error at runtime (the error-driven case)

10.2 Exception: Page Fault (Error 25314)

The most common runtime crash:

“The processor throws an exception to the operating system if it tries to access an invalid or protected memory location. The B&R operating system logs this type of serious memory violation as a page fault (error 25314).”

Causes:

• Null or incorrect pointer
• Division by zero
• Array index out of bounds
• Incorrect memory copy (buffer overflow)
• Memory relocation during online transfer

Diagnostic procedure:

1. Check the Logger (System log) for error 25314
2. Examine the Backtrace tab — may link directly to source code
3. Add IecCheck or AdvIecChk library for enhanced diagnostics
4. Systematically disable tasks to isolate the faulting task
5. Use remanent variables to narrow down faulting code section

10.3 Exception: Memory Access Violation (Error 6804)

• Can precede or accompany error 25314
• Indicates the processor detected invalid memory access before the full page fault

10.4 Cycle Time Violation (Watchdog Timeout)

• When a task class exceeds its configured cycle_time + tolerance
• Logged in the logbook
• Can trigger Service Mode (controller halts)
• AR 6.6.2 fix: Watchdog now also triggers when task is in safe state (e.g., critical section)

10.5 Watchdog Behavior Summary

10.6 Exception During Startup

• Documented issue: intermittent “EXCEPTION Page Fault” during startup
• Error chain: 6804 memory access violation → 25314 page fault
• Related to mvLoader and mvRpctxtFmt threads during module loading
• Can be caused by memory moving around during transfer

10.7 Crash Handling Flow

Exception occurs (hardware trap)
    → VxWorks exception handler
    → B&R exception handler logs error
    → Error code written to logbook (with backtrace if available)
    → Controller enters Service Mode
    → All cyclic task classes halted
    → SDM, Logger, web interface remain available for diagnostics

11. File System

11.1 Storage Media

11.2 CF Card Contents

• AR system image and boot files
• User configuration
• User programs (User ROM contents)
• Logbook files
• User files (created via AsFile library)
• System dump files

11.3 File Operations from User Programs

The AsFile library provides file system access:

• FileOpen — Open/create files on the CF card
• FileRead / FileWrite — Read/write file data
• FileClose — Close file handles
• DirOpen / DirRead / DirClose — Directory operations
• File paths reference the CF card’s file system

Important considerations:

• File operations run as system tasks (priority 4–190 range)
• Heavy file I/O can impact system performance (sataXbdReqSvc system task)
• NvFlushHandler system task manages non-volatile memory writes (DataObj, logger objects, user files)
• Files written during runtime persist on the storage media

11.4 File System Diagnostics

• sataXbdReqSvc — system task handling SATA/flash disk requests
• High CPU usage in this task can indicate excessive file writes
• Configuration files can be deleted from CF card by system (reported bug on community)

11.5 CF Card Backup/Restore

• Runtime Utility Center tool for creating backup images of CF/CFast cards
• Image files can be stored on PC and restored to spare cards
• LogBook can be retrieved directly from CF/CFast card

12. Networking Stack

12.1 TCP/IP Implementation

AR’s networking is built on VxWorks’ TCP/IP stack (historically Wind River’s IPnet stack):

“The vulnerability exists in the TCP/IP stack implementation of the underlying operating system.” — B&R Security Notice for NAME-WRECK vulnerability

• This confirms AR uses the underlying VxWorks TCP/IP stack
• B&R has issued security advisories related to VxWorks TCP/IP vulnerabilities (e.g., NAME-WRECK)

12.2 Network Protocols Supported

• POWERLINK — B&R’s real-time Ethernet protocol (deterministic, time-critical)
• Ethernet/IP — For interoperability with Rockwell/Allen-Bradley systems
• Modbus TCP — Via AsMbTCP library
• OPC UA — Client/Server and FX (fieldbus eXtensible) with multicore support (6.1+)
• TCP/UDP sockets — Available via AsTCP/AsUDP libraries for custom protocols
• REST/HTTP — Possible via socket-level implementation
• SDM web interface — HTTP server built into AR

12.3 Network Architecture

• Ethernet traffic handling runs as a system task (priority 4–190 range)
• ANSL (Automation Network Service Layer) handles online communication between AS and the controller
• POWERLINK cycle is deterministic and integrated with the I/O cycle
• Network tasks yield to cyclic tasks — high cyclic load can block network responses (100-500ms delays)

12.4 POWERLINK TCP/IP Gateway

• X20HB8815 gateway module provides an additional Ethernet port for TCP/IP
• Separates POWERLINK traffic from general TCP/IP traffic

13. AR Log System and Diagnostic Output

13.1 Logger Architecture

The Logger is AR’s central logging and diagnostic system:

Log Categories:

• System log — OS and runtime events:
  • Startup/shutdown events
  • Error 25314 (page fault) with backtrace
  • Error 6804 (memory access violation)
  • Cycle time violations
  • I/O module events (insertion, removal, errors)
  • Watchdog events
  • System task events
• User log — Application events via ArEventLog library:
  • Custom log entries with configurable severity
  • Accessed via logline function

13.2 Accessing the Logger

13.3 Log Entry Format

• Timestamp
• Severity level
• Error code (for system errors)
• Description/message
• Backtrace (for exceptions like 25314) — call stack with module names, addresses, and source line references

13.4 Backtrace Feature

For page fault (25314) entries:

• Backtrace tab shows the call stack
• Lines with green arrows can be double-clicked to jump to source code in Automation Studio
• Requires debug symbols (not available for stripped/optimized builds)

13.5 User Logging (ArEventLog)

(* Example: Writing to user logbook *)
logline(severity_level, message_string);

• The logline function uses the ArEventLog library
• Entries appear in the Logger accessible via Ctrl+L or SDM
• Useful for application-level diagnostics without custom file operations

13.6 Profiling Data

• The Profiler provides runtime measurement data:
  • Per-task execution time
  • CPU usage percentage
  • Priority information
  • Time spent in idle vs. system vs. cyclic tasks
• Available as a recording (trace) or real-time view
• From AR 6.3+: per-core data in multicore systems

13.7 Logbook Persistence

• Log entries are stored in non-volatile memory
• Survives warm starts and power cycles
• Log capacity is finite — oldest entries may be overwritten
• System Dump collects the full logbook for offline analysis

14. Security Vulnerability History (VxWorks-Derived)

Because AR is based on VxWorks, it inherits vulnerabilities from the underlying OS components. B&R (now part of ABB) publishes Cyber Security Advisories when affected products are identified. This section documents known vulnerabilities relevant to the CP1584 running AR 4.x.

14.1 URGENT/11 (2019) — VxWorks TCP/IP Stack (IPnet)

Discovered by Armis Research, URGENT/11 comprised 11 vulnerabilities in the VxWorks IPnet TCP/IP stack affecting all VxWorks versions since 6.5. B&R issued Cyber Security Advisory #01/2019 confirming impact on AR.

Impact on CP1584:

• Remote code execution possible via crafted TCP/IP packets
• Denial of service via malformed network frames
• Information leakage through stack-based buffer overflows
• Affected AR versions: All AR versions using the vulnerable IPnet stack (most AR 3.x and early 4.x versions)

Mitigation: Update AR to the patched version specified in B&R’s advisory. Network isolation (VLAN, firewall) is the primary mitigation when patching is not immediately possible.

14.2 NAME-WRECK (2021) — DNS Protocol Vulnerabilities

B&R issued a separate security notice for NAME-WRECK, a set of DNS-related vulnerabilities in VxWorks’ TCP/IP implementation.

• Affected: AR versions using VxWorks IPnet stack
• Impact: Remote code execution, denial of service via crafted DNS responses
• Mitigation: Update AR; block unsolicited DNS traffic at the firewall

14.3 SA24P011 (August 2024) — Multiple VxWorks and OpenSSL Vulnerabilities

B&R published Cyber Security Advisory SA24P011 covering six CVEs in AR versions prior to 6.0.2:

Affected AR versions: All versions before AR 6.0.2 — this includes the CP1584 running AR 4.x.

Practical implications for AR 4.x CP1584 systems:

• The CP1584 cannot upgrade to AR 6.x (incompatible hardware). These vulnerabilities remain unpatched on AR 4.x systems.
• CVE-2024-5800 (weak TLS) means FTP and OPC-UA communication using the built-in SSL/TLS may be decryptable.
• CVE-2024-5801 (IP forwarding) means the PLC could be used as a network bridge to bypass firewall segmentation.
• CVE-2020-28895 (memory corruption) could allow remote DoS via crafted packets.

Mitigation for unpatched AR 4.x systems:

1. Network isolation: Place the CP1584 on a dedicated VLAN with no direct internet access. Allow only necessary protocols (ANSL on 11169, POWERLINK on dedicated interface, FTP on 21).
2. Disable IP forwarding if possible via the runtime firewall configuration.
3. Block unnecessary services — if FTP is not needed, disable it. If SDM web access is not needed, restrict access.
4. Use VPN for remote access — never expose B&R PLC interfaces directly to the internet.
5. Monitor for anomalous traffic — use SNMP or an IIoT platform to detect unusual network activity from the PLC.

14.4 CVE-2025-11044 (January 2026) — ANSL Server DoS (Race Condition)

B&R published SA25P005 identifying a permanent denial-of-service vulnerability in the ANSL Server component of AR. CISA also published ICSA-26-125-03.

Exploitation details: The vulnerability is caused by insufficient throttling and limiting mechanisms in the ANSL Server. Successful exploitation requires winning a race condition (not guaranteed on every attempt). B&R determined that shorter cycle times in customer projects increase the likelihood of exploitation.

Mitigation for unpatched AR 4.x systems:

1. Update to AR R4.93 or later (patches this vulnerability on the CP1584 platform)
2. For versions that cannot be updated: increase application cycle times (longer cycles reduce exploit probability)
3. Configure the Control Network Firewall to limit maximum data traffic and concurrent connections to the ANSL server to no more than 80% of measured peak traffic
4. Test maximum load capacity before commissioning

14.5 CVE-2025-3450 (October 2025) — SDM DoS (Improper Resource Locking)

B&R published SA25P002 identifying a denial-of-service vulnerability in the System Diagnostics Manager (SDM) web interface.

Practical implications for CP1584: All AR 4.x versions are affected. An attacker who can reach the SDM web interface (port 80) can send a specially crafted message to crash the entire controller. See diagnostics-sdm.md for SDM-specific mitigations.

Mitigation for CP1584:

1. Restrict SDM access to trusted personnel only — disable SDM in the AS project if not needed for maintenance
2. Configure the HTTP protocol over TLS (HTTPS) — use mutual TLS (mTLS) in AS project option “Validate SSL communication partner”
3. Restrict webserver access to trusted IP addresses using the AR host-based firewall (Automation Help GUID 75b8994b-f97a-4e0f-8278-43c2a737e65f)
4. Block port 80/443 at the network firewall except during active maintenance windows

14.6 CVE-2025-11043 (January 2026) — Automation Studio Certificate Validation

B&R published SA25P004 identifying insufficient server certificate validation in Automation Studio’s ANSL and OPC-UA clients.

Practical implications: This affects the engineering workstation, not the PLC directly. However, if you use Automation Studio to connect to a CP1584 over an untrusted network, an attacker could impersonate the PLC and inject malicious code during online changes or program transfers. Critical for remote maintenance scenarios.

Mitigation:

1. Update Automation Studio to version 6.5
2. Operate Automation Studio within Level 2 of the ABB ICS Cyber Security Reference Architecture
3. Never connect Automation Studio to PLCs over public networks or untrusted WiFi
4. Use VPN with proper certificate validation for any remote maintenance

14.7 CVE-2025-3449 — Automation Studio Privilege Escalation

An attacker with local access to the engineering workstation could exploit this to gain elevated privileges. Relevant for shared engineering workstations or compromised developer laptops.

14.8 CVE-2024-0323 — FTP Server Weak TLS

Practical implications for CP1584: The built-in FTP server uses insecure encryption. Any FTP session to/from the CP1584 (including CF card backup/restore) can be intercepted and decrypted. Do not use FTP over untrusted networks. This vulnerability is unlikely to be patched on AR 4.x.

14.9 CVE-2023-3242 — Portmapper DoS

Patched in AR R4.93. On older AR 4.x versions, the Portmapper service can be exploited to permanently crash the controller.

14.10 CVE-2023-1617 — VC4 VNC Authentication Bypass (Critical)

Practical implications for CP1584: If the CP1584 runs a visualization (mapp View, VC4), an attacker on the network can connect to the VNC server (port 5900) and see the full HMI display without any authentication. This exposes all machine state, operator interactions, and potentially allows input injection.

Mitigation:

1. Update VC4 to the latest version (4.45.1+ or 4.72.9+)
2. Block VNC ports (5900, 5800) at the network firewall
3. Disable VNC if not needed for remote monitoring
4. See access-recovery.md for VNC security guidance

14.11 CVE-2021-22289 — Automation Studio Code Injection (Project Upload)

If Automation Studio is running and listening for incoming connections, a network attacker could exploit the project upload mechanism to execute arbitrary code on the engineering workstation.

14.12 CVE-2021-22275 — AR Webserver Buffer Overflow

Practical implications for CP1584: An attacker sending a crafted HTTP request to the PLC’s web interface (port 80) can crash the cyclic program, stopping the machine. This is distinct from CVE-2025-3450 which targets SDM specifically.

14.13 CVE-2022-4286 — SDM Reflected XSS

Patched in AR R4.93. If an authenticated user visits a malicious URL while logged into SDM, JavaScript can execute in their browser session. See diagnostics-sdm.md.

14.14 CVE-2024-2637 — Search Path Code Execution

An authenticated local attacker could place specially crafted files in the loading search path to execute malicious code. Relevant for shared engineering workstations.

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

B&R published SA25P003 (CISA ICSA-26-141-04) identifying a session takeover vulnerability in SDM.

Practical implications for CP1584: All AR 4.x versions are affected. Since SDM does not implement authentication in older AR versions, session takeover could allow an attacker to view diagnostic data or inject commands if they can predict the session ID. However, B&R notes that SDM “does not process any session-specific data” at this time, so the practical impact is limited to browser-level interaction.

Mitigation for CP1584:

1. Update to AR R4.93 if possible (partial mitigation — does not fix this CVE on AR 4.x)
2. Block SDM access (port 80/443) at the network firewall when not actively debugging
3. Never access SDM over public networks or untrusted WiFi
4. Use VPN for remote SDM access

14.16 CVE-2025-3448 — SDM Reflected XSS (New)

Practical implications for CP1584: All AR 4.x versions are affected. This is distinct from CVE-2022-4286 (which was patched in R4.93). An attacker could craft a malicious link that, when clicked by an authenticated user, executes JavaScript in their browser. The exploit requires social engineering.

Mitigation: Do not click untrusted links while authenticated to SDM. Deploy a Web Application Firewall (WAF) to filter reflected XSS attempts. Block SDM at the network level when not needed.

14.17 CVE-2025-11498 — SDM CSV Injection

Practical implications for CP1584: All AR 4.x versions are affected. This is a multi-step attack requiring both clicking a malicious link and opening a CSV export. The impact is limited to the user’s machine (formula injection in spreadsheets can execute local commands in some configurations).

Mitigation: Never use hyperlinks from untrusted sources to access SDM. Disable CSV export functionality in SDM if not needed. Be cautious opening CSV files exported from SDM if the URL source was not manually typed.

14.18 CVE-2026-0936 — PVI Logfile Credential Leak

Practical implications for CP1584: The PVI logging feature is disabled by default and must be explicitly enabled. If enabled, PVI may log sensitive information including connection credentials used to access the PLC. If you have enabled PVI logging on your diagnostic workstation, review log files for embedded credentials before sharing them.

Mitigation: Do not enable PVI logging unless actively debugging PVI communication issues. Purge any existing PVI log files that may contain credentials.

14.19 CVE-2025-11043 — Automation Studio Certificate Validation Bypass

Practical implications for CP1584: When using Automation Studio to connect to a CP1584 over TLS-secured ANSL connections, an attacker on the network could intercept and modify the communication. This affects the engineering workstation, not the PLC directly, but could lead to malicious code being downloaded to the PLC.

Mitigation: Upgrade to Automation Studio 6.5+. If stuck on AS 4.x, use direct IP connections on an isolated network segment rather than relying on TLS for security.

14.20 CVE-2025-11482 — PPT30 OPC-UA Server Connection Exhaustion DoS

Practical implications: If the machine uses a PPT30 HMI panel with OPC-UA server enabled, an attacker on the same network can exhaust the OPC-UA connection pool, denying access to OPC-UA data. Block OPC-UA port (4840) at the switch port if the PPT30 does not need external OPC-UA access.

14.21 CVE-2024-8603 — Broken or Risky Cryptographic Algorithm in SSL/TLS

Practical implications for CP1584: All AR 4.x versions use the affected SSL/TLS component. An attacker on the network could impersonate legitimate services (OPC-UA server, SDM, FTP) by exploiting weak cryptographic algorithms in the TLS implementation. This is distinct from CVE-2024-5800 (weak DH groups) — this vulnerability relates to the broader SSL/TLS algorithm selection, including cipher suite negotiation and certificate validation weaknesses.

Mitigation for CP1584:

1. Network isolation — place CP1584 on a dedicated VLAN with no direct internet access
2. Use VPN with proper certificate validation for any remote access
3. Do not trust TLS connections from AR 4.x devices — the cryptographic protection is inadequate
4. Consider using OPC-UA with security policy “None” on internal networks rather than relying on broken TLS for protection — a broken TLS session provides a false sense of security
5. This vulnerability is unpatchable on AR 4.x — requires AR >= 6.1 for the fix

Source: NVD CVE-2024-8603, B&R SA25P001 advisory PDF

14.22 CVE-2024-5800 — Weak Diffie-Hellman Groups in TLS Stack

Practical implications for CP1584: All AR 4.x versions use weak DH groups. Any TLS-encrypted communication (FTP over TLS, HTTPS for SDM on AR 6.x, OPC-UA with security) on a CP1584 running AR 4.x is vulnerable to decryption by a network attacker with sufficient computational resources. This means FTP credentials and OPC-UA data transmitted over TLS on AR 4.x PLCs should be considered compromised if the network is not physically secured.

Mitigation: Use network isolation rather than relying on TLS encryption. For FTP access, accept that credentials may be intercepted on AR 4.x and use ephemeral credentials. For OPC-UA, use a VPN tunnel or dedicated VLAN for additional protection.

14.22 CVE-2026-6900/6901 — APROL Certificate Validation and Search Path (APROL-only)

Note: APROL is B&R’s process control system (DCS/SCADA), not directly related to CP1584 PLCs. Listed here for completeness as it affects B&R products.

14.23 Complete B&R Security Advisory Timeline (2024-2026)

The following table provides a chronological reference of all B&R security advisories affecting Automation Runtime and related components. This is critical for understanding what firmware versions address which vulnerabilities.

Key takeaway for CP1584 operators: The CP1584 maxes out at AR R4.93, which patches CVE-2025-3450 (critical SDM data deletion), CVE-2025-11044 (ANSL DoS), CVE-2024-5800 (weak TLS), and CVE-2022-4286 (SDM XSS). However, 20+ CVEs remain unpatchable on AR 4.x, including all SA25P003 vulnerabilities (session takeover, XSS, CSV injection) and all certificate validation issues. Network isolation is not optional — it is mandatory.

14.24 Security Posture Summary for CP1584 (Updated)

SA25P003 covers CVE-2025-3449 (SDM session takeover), CVE-2025-3448 (SDM reflected XSS), and CVE-2025-11498 (SDM CSV injection). These require AR >= 6.4 to patch and cannot be patched on any AR 4.x version.

Key observations:

• AR R4.93 patches CVE-2025-11044 (ANSL DoS), CVE-2025-3450 (critical SDM data deletion), CVE-2023-3242, CVE-2022-4286 (SDM XSS), and partially addresses SA24P011
• CVE-2025-11043 (AS certificate validation) and CVE-2026-0936 (PVI credential logging) affect the engineering workstation software, not the PLC runtime. Mitigate by upgrading AS to 6.5+ and keeping PVI logging disabled.
• No AR 4.x version patches CVE-2024-0323 (FTP weak TLS), CVE-2021-22275 (webserver buffer overflow), CVE-2024-5800 (weak DH groups), CVE-2024-8603 (broken/risky crypto algorithm in SSL/TLS), CVE-2023-1617 (VC4 VNC bypass), or any SA25P003 CVEs (SDM XSS/session/CSV injection)
• The SA25P003 vulnerabilities (CVE-2025-3448, CVE-2025-3449, CVE-2025-11498) further strengthen the case for disabling SDM on production CP1584s when not actively needed
• The VC4 VNC authentication bypass is independently patchable via VC4 component updates
• FTP should be considered insecure on all AR 4.x versions — the weak DH groups (CVE-2024-5800) and broken crypto algorithms (CVE-2024-8603) in AR 4.x TLS mean even TLS-encrypted FTP sessions may be decryptable
• Total unpatchable CVEs on CP1584 (AR R4.93): 20+ known vulnerabilities remain unpatchable due to the AR 4.x ceiling. Network isolation is mandatory, not optional.

14.25 SA26P009 (June 2026) — XZ Utils Vulnerability Impact on B&R Products

CP1584 impact: NONE. The CP1584 runs VxWorks, not Linux, and does not use XZ Utils. SA26P009 affects B&R products that run Linux (Automation PCs, Linux for B&R, APROL, edge controllers). The XZ Utils vulnerability (CVE-2024-3094) was a backdoor inserted into the xz compression library that could enable unauthorized SSH access on affected systems. While this was one of the most significant supply chain attacks in recent history, it does not affect VxWorks-based PLCs like the CP1584.

Source: B&R SA26P009 advisory PDF, CISA AL26-009

14.26 SA26P010 (June 2026) — Linux Kernel Vulnerabilities Impact on B&R Products

CP1584 impact: NONE. The CP1584 runs VxWorks (AR), not Linux. SA26P010 affects only B&R products that include a Linux kernel: Automation PCs running “B&R for Linux,” APROL process control systems, and the X20EDS410 edge controller. The X20CP1584 is a pure VxWorks PLC and is not affected by any Linux kernel vulnerability.

For migration planning: If you are planning to migrate from CP1584 to an X20CP3xxx series or APC platform, be aware that these newer controllers may run Linux components and will require ongoing Linux kernel security patches. See remanufacturing.md for migration analysis.

Source: B&R SA26P010 advisory PDF, CISA ICSA-26-174-06

14.27 Recommended Firewall Rules for CP1584 (AR 4.93)

Control Network Firewall Rules for B&R CP1584:

  INBOUND:
    Allow TCP 11169  from [Engineering subnet]     — ANSL (Automation Studio online)
    Allow TCP 4840   from [SCADA/HMI subnet]        — OPC-UA (if used)
    Allow UDP 123    from [NTP server]               — NTP time sync
    Allow TCP 80/443 from [Maintenance subnet]       — SDM (restrict to maintenance windows only)
    Block TCP 21     from ALL                       — FTP (insecure, use only for emergency backup)
    Block TCP 5900   from ALL                       — VNC (update VC4 first if needed)
    Block ALL        from [Office/Guest networks]    — No PLC access from non-control networks

  OUTBOUND:
    Allow UDP 123    to [NTP server]                 — NTP time sync
    Allow TCP 11160  to [PVI Manager IP]             — PVI callbacks
    Block ALL other outbound                        — PLC should not initiate external connections

The CP1584 cannot be fully patched against all known vulnerabilities. The best achievable security posture is AR R4.93 (latest AR 4.x) with updated VC4, combined with strict network isolation, firewall rules above, and disabling all unnecessary services. See access-recovery.md for security implications, network-architecture.md for network isolation guidance, and diagnostics-sdm.md for SDM-specific mitigations.

Appendix A: Source URLs

Cross-References

• firmware.md – firmware architecture and update mechanisms
• execution-model.md – IEC 61131-3 task scheduling on AR, exception handling, cycle time violations
• memory-map.md – CPU memory layout and address space
• cf-card-boot.md – CF card boot sequence and file loading
• ebpf-telemetry.md – eBPF/perf monitoring approaches for AR
• system-variables.md – AR system variables and RTInfo
• diagnostics-sdm.md – SDM for OS-level diagnostics
• custom-diagnostic-tools.md – C/C++ diagnostic programs on AR
• program-reverse-engineering.md – AR binary format analysis
• bootloader-recovery.md – recovery procedures for AR systems
• cp1584-hardware-ref.md – CPU hardware specs, LED diagnostics, overtemperature thresholds
• io-card-hardware.md – IO module hardware architecture and I/O processor interaction
• network-architecture.md – Network stack architecture for ANSL/POWERLINK/Ethernet
• cybersecurity-hardening.md – AR security vulnerabilities, CVE catalog, hardening procedures
• pvi-api.md – PVI protocol running as an AR system task (ANSL server)
• online-changes.md – How online code changes work at the OS level, page fault risks
• acopos-drives.md – ACOPOS drive communication as POWERLINK system task
• hardware-monitoring.md – CPU temperature and hardware health monitoring at OS level
• python-diagnostics.md – External monitoring of AR runtime behavior via Python/PVI/OPC-UA

Key Findings

1. Automation Runtime is confirmed VxWorks-based — B&R employees confirmed this on the community forum, and security advisories reference VxWorks vulnerabilities. Understanding VxWorks behavior helps explain AR’s characteristics.
2. No user-defined ISRs exist in AR — deterministic timing is maintained by excluding user interrupt handlers. Use IRQ task classes for hardware events instead.
3. All user tasks share a flat address space — no memory protection between tasks. A pointer error in one task can corrupt another task’s data. The IecCheck/AdvIecChk libraries provide runtime bounds checking for debugging.
4. The TcIdleFiller mechanism can cause SDM to report artificially high CPU usage — idle time at the end of a task class cycle is filled with no-ops counted as CPU time, not actual idle.
5. Page faults (error 25314) are the most common runtime crash — caused by null pointers, array bounds violations, or memory relocation during online transfers. The backtrace feature in the Logger is the primary diagnostic tool.
6. exOS allows Linux to run alongside AR on multi-core controllers (not applicable to single-core CP1584, but relevant for migration planning to newer hardware).
7. System tasks (networking, file I/O, SDM, OPC-UA) run at priorities 4-190, always below cyclic tasks (190-230). Heavy system task load can delay network responses but cannot affect real-time cyclic execution.