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