Remanufacturing and Modernizing B&R Control Systems

A practical guide for automation engineers maintaining B&R X20CP1584 PLCs and related hardware from defunct OEMs with zero documentation. Covers repair, in-family migration, cross-platform migration, project planning, and cost analysis.

Table of Contents

1. Overview
2. CP1584 Repair vs Replace Decision Matrix
3. B&R In-Family Migration (Recommended Path)
4. X20 to X67 Migration (Form Factor Change)
5. B&R to CODESYS Migration
6. B&R to Siemens Migration
7. B&R to Beckhoff Migration
8. Migration Project Planning
9. Minimizing Downtime During Migration
10. Cost/Benefit Analysis Framework
11. Legacy B&R Specific Considerations
12. Cross-References
13. Key Findings
14. Sources

1. Overview

Modernizing a B&R control system falls on a spectrum with five distinct zones. The correct choice depends on hardware health, spare parts availability, downtime risk tolerance, budget, and long-term support requirements.

The Modernization Spectrum

Zone 1          Zone 2            Zone 3              Zone 4            Zone 5
REPAIR     | COMPONENT UPGRADE | IN-FAMILY      | CROSS-PLATFORM  | FULL REDESIGN
           |                   | CPU SWAP       | MIGRATION       |
           |                   |                |                 |
Cost:      | $10 - $500        | $1,500 - $5,000| $5,000 - $25,000| $25,000+
Risk:      | Low               | Low-Medium     | Medium-High     | High
Downtime:  | Hours             | 1-2 days       | 1-4 weeks       | 2-12 weeks
Disruption:| None              | Minimal        | Moderate        | Complete
           |                   |                |                 |
Example:   | Replace caps,     | X20CP1584      | X20CP3484 or    | New PLC + new
           | new CF card,      | -> X20CP1485   | CODESYS/Wago    | HMI + new IO
           | new battery       |                |                 | + reprogram

Assessment Framework

Use this questionnaire to determine which zone applies:

Critical First Step: Documentation

Before making any decision, reconstruct documentation. See documentation-reconstruction.md and program-reverse-engineering.md for procedures.

Without the Automation Studio project file, software migration effort multiplies by 3-5x. Without IO wiring documentation, hardware swap downtime multiplies by 2-4x. Prioritize recovering both before committing to any migration path.

AS4 to AS6 Migration Tools (Critical for Software Recovery)

When migrating from the CP1584 to a modern replacement (e.g., CP3484), you will likely need to move from Automation Studio 4 to Automation Studio 6. This is not a simple upgrade — AS6 has breaking changes in project format, PVI version (6.x drops INA2000 support entirely), and mapp Framework. The B&R community maintains free tools to assist:

Migration path: CP1584 → CP3484 (or newer):

1. Recover the AS4 project using techniques in program-reverse-engineering.md
2. Open the project in AS4 and ensure it compiles cleanly
3. Run the community migration tools to identify breaking changes
4. Upgrade mapp components to their mapp 6 equivalents
5. Replace all INA2000 PVI references with ANSL (see pvi-api.md)
6. Re-target the hardware configuration to the new controller
7. Test on the bench before deploying to the machine

AS 6.5 benefits for migration (December 2025): AS 6.5 introduces ST-OOP with full inheritance, polymorphism, access specifiers (PUBLIC/PRIVATE/PROTECTED), abstract methods, and method overriding — enabling modern object-oriented IEC 61131-3 programming that significantly improves code maintainability. Other AS 6.5 features relevant to migration: hard real-time multicore task scheduling (assign cyclic tasks to specific CPU cores), FTP RBAC, expanded ManagedCertificateStore (ANSL/FTP/HTTP/SMTP), TFTP disabled by default (security improvement), self-signed certificate handling, CLI library exporter (BR.AS.LibraryExporter.exe), and SNI support in AsHttp. See firmware-version-mgmt.md §3.2 for the complete AS 6.x release history.

Warning: The original AS4 TG dongle licenses may not carry forward to AS6. See license-mgmt.md for license recovery strategies.

See firmware-version-mgmt.md §5.3.1 for detailed AS4→AS6 breaking changes.

AR 6.5 Multicore Task Scheduling — Migration Impact

AS 6.5 with AR 6.5 introduces hard real-time multicore support that is a significant selling point for migrating to newer B&R hardware. Understanding this feature is important for migration planning because it changes how task scheduling works on the target hardware.

What changes in AR 6.5 multicore:

Practical benefit for migrated machines:

• Motion control (Cyclic #1) can run on Core 0, while logic (Cyclic #2–#4) runs on Core 1
• ANSL/OPC-UA communication no longer competes with real-time tasks for CPU time
• Higher total throughput without reducing individual cycle times
• Reduced cycle time violations (Exception 144) on complex machines

Hardware requirements:

• Multicore requires AR 6.5 AND a multicore CPU (X20CP3xxx, X20EM, APC industrial PCs)
• The X20CP1684 (single-slot successor to CP1584) does NOT support multicore — it has a single-core processor
• For multicore, you need at minimum a X20CP3xxx (3-slot, dual-core) or X20EM (ARM multi-core)

Migration implication: If your CP1584 machine has complex motion + logic that frequently hits cycle time violations, migrating to a multicore platform (X20CP3xxx or X20EM with AR 6.5) may eliminate those issues entirely by distributing task load across cores. This is a stronger justification for migration than just security compliance.

Source: B&R Community — “RELEASE 2025: Automation Studio 6.5 - Complete overview” (community.br-automation.com/t/release-2025-automation-studio-6-5-complete-overview/9439), “Innovation 2025: Multicore Processing in Automation Software 6” (community.br-automation.com/t/innovation-2025-multicore-processing-in-automation-software-6/8477)

ST-OOP in AS 6.5 — Modern IEC 61131-3 for Refactored Projects

AS 6.5 adds full Structured Text Object-Oriented Programming (ST-OOP) to the IEC 61131-3 language set. This is relevant for migration because when refactoring recovered AS4 code, you have the option to restructure it using modern OOP patterns:

When to use ST-OOP in migration:

• When the recovered AS4 project uses copy-paste patterns across multiple axes/stations
• When refactoring for maintainability by a one-man team (reduces code duplication)
• When building new functionality on top of the migrated base

When NOT to use ST-OOP:

• When doing a literal migration (keep existing code structure unchanged)
• When the target is AS 4.x compatibility (ST-OOP requires AS 6.x)
• When team members are not familiar with OOP concepts

2. CP1584 Repair vs Replace Decision Matrix

X20CP1584 Hardware Architecture

Common Failure Modes and Repair Costs

Decision Flowchart

                    CP1584 FAILURE REPORTED
                            |
                    Does it power on?
                   /                \
                 YES                 NO
                 |                    |
          Does it boot to           Check external PSU.
          AR runtime?               Replace PSU ($50-200).
           /        \                Does it power on now?
         YES         NO              /             \
          |           |            YES              NO
     Machine       CF card likely   Fixed.          Base module or
     is running    corrupt.         Monitor.        CPU failure.
     but degraded. Replace CF       |
     Monitor.     ($20-80) +      CPU hardware
          |        re-flash.       failure. Replace.
          |           |            ($1,500-$5,000
     Which                Is project  for in-family
     component            file backed  upgrade)
     is failing?          up?
      /     \           /         \
    SAFE    NON-SAFE  YES          NO
    LOGIC   FAULT      Recover      Recover project
     |        |        from CF       first, then
     |        |        or backup.    re-flash.
     |        |                    |
     |        |              Can you
     |        |              recover it?
     |        |               /     \
     |        |             YES      NO
     |        |              |        |
     |        |         Re-flash    Must reverse-
     |        |         and test.   engineer or
     |        |                    recreate.
     |        |                    (See program-
     |        |                     reverse-
     |        |                     engineering.md)
     |        |
     |        |
   Safety     Is failure
   hardware   recurring?
   issue.     /         \
   Requires   YES         NO
   certified  |            |
   repair     Track        Repair
   or         frequency.  complete.
   module     If >2x/year,  Return to
   replace.   plan        service.
     |        upgrade.
     |           |
     |        Is machine
     |        >3 years from
     |        planned end of
     |        life?
     |         /       \
     |        YES       NO
     |         |         |
     |     Consider   Repair and
     |     in-family   monitor.
     |     upgrade.
     |
  SafeLOGIC
  module
  failure:
  - Check
    X20 safe
    bus cables
  - Check
    configuration
  - Replace safe
    module
    ($500-2000)
  - Recertification
    may be required

When Repair Makes Sense

• Machine expected remaining life under 3 years
• Failure is a known single-component issue (CF card, battery, capacitors)
• Spare CPU is already in inventory (common: OEM bought 2-3 spares)
• Downtime budget is under 4 hours
• No safety system involved or safety system unaffected
• Software is stable and well-documented
• Budget is constrained to under $500

When Replacement Is the Only Option

• CPU itself has failed (Atom processor, DDR2, FPGA)
• POWERLINK bus interface is unreliable
• Multiple recurring failures indicating board-level degradation
• No spare CPU available and none on the secondary market
• Machine life extension justifies capital expenditure
• Need for additional IO capacity, memory, or communication interfaces
• Safety system requires upgrade for compliance

CP1584 on the Secondary Market

Important: When buying a replacement CP1584, match the firmware version exactly if possible. See firmware-version-mgmt.md. A firmware version mismatch may require recompiling the project in Automation Studio, which requires the project file.

3. B&R In-Family Migration (Recommended Path)

Migration Within X20 Platform

CP1584 Discontinuation Notice (SN 2022/54): B&R issued discontinuation notice SN 2022/54 for the X20CPx58x series (CP1584, CP1585, CP3584, CP3585) due to component discontinuation. Last-Time-Buy (LTB) deadline was February 28, 2023. The CP1584 is now in the Obsolete phase of B&R’s lifecycle — no new units are available from B&R, and repair service is available only for a limited time after obsolescence. This makes spare parts sourcing from the secondary market (eBay, surplus brokers, classicautomation.com, all4sps.com) critical. Always verify firmware compatibility and burn-test used CPUs before deploying as production spares. See spare-parts.md for sourcing strategies.

The X20 system celebrated its 20th anniversary in 2024 and is actively sold and supported by B&R with no end-of-life announced. Product Manager Andreas Hager confirmed: “The X20 is twenty years old and still going strong.” The three-part module design (bus module + electronic module + terminal block) has remained consistent since 2004, ensuring backward compatibility for IO modules. Migration within X20 is the lowest-risk upgrade path because the programming environment (Automation Studio), the runtime (Automation Runtime / AR), the IO bus (POWERLINK + X2X), and the IO modules remain the same or are backward compatible.

Source: B&R Press Release, October 2024

B&R Product Lifecycle Phases

B&R uses a four-phase lifecycle model for all products. Understanding this is critical when planning spare parts and migrations:

The current lifecycle status of any B&R product is visible at www.br-automation.com and in B&R’s online offers system. Check before committing to a migration path.

Source: B&R Lifecycle Policy

Target CPU Comparison

X20CP1585 is the best direct drop-in replacement for CP1584: Same Atom family processor at higher clock (1.0 GHz vs 0.6 GHz), same CompactFlash storage (no media migration), same RAM (256 MB DDR2), same interface slots, same form factor, and same X2X/POWERLINK bus architecture. The faster CPU halves the minimum task class cycle time (200 us vs 400 us) and dramatically reduces power consumption (3 W vs 8.6 W). Supports OPC-UA. Available from industrial parts suppliers (~$2,500-$3,500 new, ~$1,000-$2,000 surplus). Confirmed as a valid upgrade path by B&R Community: see community.br-automation.com/t/x20cp1585-controller-upgrade/8885.

X20CP1684 is an alternative direct replacement: Same CompactFlash storage and same RAM. Identical performance profile to CP1585 (1.0 GHz, 200 us minimum cycle). Requires Automation Studio 4.7 or later. See community.br-automation.com/t/upgrading-x20cp1584-with-x20cp1684/5727.

X20CP3484 is the performance upgrade path: Switches from CompactFlash to SD card (requires media migration), adds more interface slots and faster POWERLINK. The DDR4 variant provides even better memory performance.

Important: Board-level exchange between CP1484 and CP1584 is NOT possible — the processor types are different and the boards are incompatible. See community.br-automation.com/t/exchange-electronic-boards-between-cpu-x20cp1484-and-x20cp1584/5343.

New Generation X20 Controllers (AR 6.x Targets)

B&R announced a new generation of X20 controllers with Intel Apollo Lake I processors, significantly higher performance, additional RAM, integrated onboard flash memory, and OPC UA over TSN support. These controllers target AR 6.x and Automation Studio 6.x and represent the forward-looking migration path from the CP1584:

X20CP3687X — “The power of a PC” in a compact X20 controller. B&R positions this as the highest-performance X20 controller, combining industrial PC performance with the compact X20 form factor. Ideal for machines that need advanced motion control, vision processing, or IIoT gateways alongside PLC control.

X20CP0484-1 — Extended Compact-S series controller with 512 MB RAM and 2 GB internal flash. This is the budget-friendly AR 6.x entry point, suitable for machines that don’t need the full performance of the Apollo Lake I generation but still want patchable AR 6.x firmware.

Sources: B&R “Expanded X20 PLC generation” product page (br-automation.com/en/products/plc-systems/innovations/)

Critical migration implications:

1. AS 6 is a separate product — it does not replace AS 4.x. It requires its own license and installation. Projects from AS 4.x cannot be opened directly in AS 6.x; they must be ported using the community migration tools.
2. AR 6 drops VxWorks 5.5 — the underlying RTOS migrates to VxWorks 6.x/7.x. Binary-incompatible. All .br modules must be recompiled for AR 6 targets.
3. INA2000 protocol is deprecated in AR 6.x. PVI 6.x uses only ANSL. See pvi-api.md for the implications.
4. CF cards are being phased out in favor of SD cards and onboard flash. The CP1584’s dependency on B&R-certified CF cards goes away.
5. exOS (Linux alongside AR) is available on multi-core AR 6 controllers, enabling IIoT capabilities without a separate PC. See ar-rtos.md §1.3 and iiot-retrofit.md for exOS details.

Development Tools Update (2025-2026)

New community tools and official B&R tools have emerged that simplify B&R development and migration:

Note: The awesome-B-R community repository was archived on April 30, 2025 (made read-only). The curated list of tools is now frozen but remains a valuable reference. Active tool development continues in individual repositories. The archive is at github.com/archive-br-automation-com/awesome-B-R.

AS Code vs VS Code B&R Tools — Which to Use?

What Changes with In-Family Migration

Migration Steps in Automation Studio

Prerequisites:

• Automation Studio 4.x installed (AS 4.x is current)
• Original project file (.apj) recovered or reconstructed
• Target CPU firmware installed in Automation Studio
• CF card backed up using SD card or USB transfer

Step-by-Step Procedure:

1. Backup existing system

   • Create full CF card image: dd if=/dev/sdX of=cp1584_backup.img bs=4M
   • Backup Automation Studio project file
   • Export IO configuration and hardware tree
   • Document all parameter values (see config-file-formats.md)
   • Record POWERLINK node addresses and bus timing

2. Open project in Automation Studio 4.x

   • If project was created in AS 3.x, AS 4.x will prompt for migration
   • Accept migration. Review migration log for warnings.
   • Common migration warnings: deprecated function blocks, renamed libraries
   • Resolve all warnings before proceeding

3. Change hardware configuration

   • In the Hardware Catalog, locate the target CPU
   • Right-click existing CPU in the hardware tree -> Replace Hardware
   • Select the new CPU model
   • Verify all IO modules are still recognized
   • Check for any address conflicts after replacement

4. Verify and resolve library compatibility

   • Check Library Repository for all used libraries
   • Update any libraries flagged as incompatible
   • Pay special attention to mapp component versions
   • Rebuild project: Project -> Rebuild All

5. Adjust timing parameters

   • Open Task Configuration
   • Review cycle times against new CPU performance
   • If cycle times were tight on old CPU, they will be fine on new CPU
   • If software used timing-dependent code (WAIT ms, hardware counters), verify
   • Adjust POWERLINK cycle time if required (usually no change needed)

6. Prepare new CPU

   • Insert SD card in new CPU
   • Power on new CPU, connect Ethernet
   • Update firmware via Automation Studio if needed: Tools -> Update Firmware
   • Verify firmware version matches project requirements
   • Set IP address to match original CPU configuration

7. Download and test

   • Download project to new CPU: CPU -> Download
   • Verify all IO modules are detected on bus
   • Run I/O check: manually activate each input, verify each output
   • Run Auto Configuration to let IO modules self-initialize
   • Run machine through manual cycle if possible

8. Safety system verification

   • If SafeLOGIC is present: re-verify all safety parameters
   • Check safe inputs, safe outputs, safe analog values
   • Confirm safe bus communication
   • Document safety verification for compliance records

9. Commission and monitor

   • Run machine in automatic mode
   • Monitor for 4-8 hours minimum
   • Check for any unexpected behavior in timing-sensitive sequences
   • Archive project with new hardware configuration

Hardware Replacement Procedure

PRE-SWAP CHECKLIST
==================
[ ] Machine powered down and locked out (LOTO)
[ ] Original CPU CF card backed up (dd image)
[ ] New CPU firmware version verified
[ ] New CPU IP address configured
[ ] Ethernet cables labeled
[ ] POWERLINK bus cables labeled
[ ] X20 base module connectors labeled
[ ] IO module positions documented with photos
[ ] Project compiled and ready for download
[ ] Test plan prepared

SWAP PROCEDURE
=============
1. Disconnect Ethernet cables from old CPU
2. Disconnect POWERLINK bus cables from old CPU (note: may be daisy-chain)
3. Remove old CPU from X20 base module (slide latch)
4. Mount new CPU on X20 base module
5. Reconnect POWERLINK bus cables (same positions)
6. Reconnect Ethernet cables (same positions)
7. Power on machine
8. Connect laptop to CPU via Ethernet
9. Ping CPU IP address - confirm connectivity
10. Open Automation Studio, connect to CPU
11. Download project
12. Verify IO configuration matches
13. Run I/O check
14. Start machine, monitor

POST-SWAP
=========
[ ] All IO modules detected on bus
[ ] IO check passed (all inputs/outputs verified)
[ ] Machine runs through full automatic cycle
[ ] No error flags in diagnostics
[ ] Backup of new configuration saved
[ ] Old CPU archived as spare (if functional)
[ ] Maintenance log updated

IO Module Backward Compatibility

X20 IO modules are generally backward compatible across CPU generations. Specific notes:

• X20 digital and analog IO modules: fully compatible, plug-and-play
• X20 safe IO modules: compatible, but safety parameters must be re-verified
• X20 communication modules (PROFINET, EtherNet/IP, Modbus): compatible
• X20 bus couplers: compatible
• X20 power supply modules: compatible
• X20 interface modules (X2X, POWERLINK): compatible

Exception: Some very early X20 modules (pre-2010) may need firmware updates to work with AR 4.x. Check the module firmware version in Automation Studio’s Hardware Catalog.

4. X20 to X67 Migration (Form Factor Change)

X67 System Overview

B&R X67 is the IP67-rated compact variant of the X20 system. It uses the same Automation Runtime, the same POWERLINK protocol, and the same programming model (Automation Studio). The difference is physical: X67 modules are designed for mounting directly on the machine without a control cabinet.

X20 vs X67 Comparison

When X67 Makes Sense

• Machine has no room for additional cabinet space
• Need to distribute IO across multiple machine zones
• IP67 environment requirement (washdown, dusty, outdoor)
• Simplified installation (M12 connectors vs screw terminals)
• Retrofit where pulling new cables to cabinet is impractical

When X20 Remains Better

• Existing X20 IO modules are healthy and compatible
• Cabinet space is available
• Cost sensitivity (X67 modules cost more per IO point)
• Centralized control architecture preferred
• Complex safety system (more options in X20)

X20 to X67 Migration Considerations

X67C CPU Models for Migration

When migrating from a CP1584, the most appropriate X67C CPU replacements are:

Note: X67C CPUs use Intel Atom processors significantly faster than the CP1584’s E620T. All X67C models support AR 6.x, which provides substantially more features than the CP1584’s AR 4.x. The migration from AR 4.x to AR 6.x requires Automation Studio 6 and careful project conversion (see Section 3).

X67 M12 Connector Wiring

X67 modules use industry-standard M12 connectors (A-coded for power/signal, D-coded for Ethernet/POWERLINK):

X67 Safe IO Migration Notes

When migrating safety systems from X20 to X67:

SafeLOGIC configurations are fully portable — the safety program runs identically on X20 and X67 safety modules. The hardware configuration tree must be updated with the correct X67 module order codes, but no safety logic changes are needed. Safety recertification (SIL verification) should be performed after any hardware change per IEC 61508 requirements.

5. B&R to CODESYS Migration

Overview

CODESYS V3 is the dominant IEC 61131-3 development environment that runs on hardware from multiple vendors. Migrating from B&R to CODESYS means choosing a new hardware platform (Wago, Beckhoff, ifm, etc.) while porting the software to CODESYS.

Target Hardware Platforms

What Is Portable from B&R to CODESYS

What Is NOT Portable (Must Be Rewritten)

• All B&R-specific libraries (mapp, mc, as, sys, FileIO, Timer, etc.)
• All mapp components (mapp Motion, mamp View, mapp Alarm, etc.)
• B&R visualization pages
• B&R configuration objects (Axis, CAM, etc.)
• B&R-safe function blocks (SafeLOGIC programs)
• B&R PVI communication
• B&R-specific task triggers (hardware interrupt, POWERLINK event)

POWERLINK on CODESYS

POWERLINK (Ethernet POWERLINK) is standardized through EPSG (Ethernet POWERLINK Standardisation Group). CODESYS supports POWERLINK through the CODESYS EtherCAT stack, but this is not a direct drop-in replacement.

Reality check: Most CODESYS hardware platforms use EtherCAT, not POWERLINK. If you need to keep existing POWERLINK IO, your options are limited:

1. Use a B&R X20 bus coupler as a POWERLINK-to-EtherCAT gateway (complex)
2. Replace IO with EtherCAT-compatible IO (requires rewiring)
3. Use CODESYS on B&R hardware (possible but defeats migration purpose)

Recommendation: If IO must be replaced anyway (due to degradation), migrate to EtherCAT IO simultaneously. If IO is healthy, stay within B&R ecosystem.

Safety System Migration: B&R SafeLOGIC to CODESYS Safe SIL

This is the most critical and costly aspect of any cross-platform migration.

Safety migration is not a software port. It requires:

• New SIL assessment for the target platform
• Rewriting all safety logic in CODESYS Safe SIL
• New hardware safety validation (FSoE communication tests)
• Third-party validation and certification
• Updated safety documentation (SRS, SIS, test records)

Estimated cost for safety migration alone: $5,000 - $25,000 depending on complexity.

Estimated CODESYS Migration Effort

6. B&R to Siemens Migration

Siemens Platform Overview

Siemens S7-1500 is the flagship PLC platform within the TIA Portal ecosystem. Migration from B&R to Siemens is a complete platform change: different hardware, different software (TIA Portal vs Automation Studio), different IO, different communication protocols.

Hardware Comparison

Software Migration Challenges

IEC 61131-3 Dialect Differences (B&R ST vs Siemens ST)

B&R Automation Studio ST:          |  Siemens TIA Portal ST:
-----------------------------------+----------------------------------
x := y + z;                        |  x := y + z;
IF a THEN                          |  IF a THEN
  b := TRUE;                       |    b := TRUE;
END_IF;                            |  END_IF;

// B&R uses:                       |  // Siemens uses:
fbInst(input := 10);               |  fbInst(input := 10);
                                   |  // or:
                                   |  fbInst.Input := 10;

// B&R timer:                      |  // Siemens IEC timer:
TON_inst(IN := TRUE, PT := T#5s);  |  TON_Instance(IN := TRUE, PT := T#5S);

// B&R string:                     |  // Siemens string:
s := 'Hello';                      |  s := 'Hello';
                                   |  // STRING[254] type declaration
                                   |  // differs from B&R STRING type

// B&R array access:               |  // Siemens array access:
a[5] := 10;                        |  a[5] := 10;
                                   |  // Array bounds checking differs

// B&R pointer (rare):             |  // Siemens pointer:
p := ADR(variable);                |  p := %MW100; // absolute addressing

Communication Migration: POWERLINK to PROFINET

This is one of the most impactful changes. POWERLINK and PROFINET are fundamentally different protocols:

Impact: All IO must be replaced. All field wiring to IO terminals must be re-punched or re-connected. IO addresses will change. All IO references in program code must be updated.

Safety Migration: B&R SafeLOGIC to Siemens F-CPU

Cost Comparison: In-Family vs Siemens Migration

7. B&R to Beckhoff Migration

Beckhoff Platform Overview

Beckhoff’s TwinCAT 3 environment runs on standard PC hardware (CX series industrial PCs or standard IPCs) and provides IEC 61131-3 programming. It is architecturally similar to B&R in several ways, making it a relatively more natural migration target than Siemens.

B&R vs Beckhoff: Architectural Similarities

Key Differences

Library Migration: B&R to TwinCAT

Beckhoff Hardware Selection for Migration from CP1584

EtherCAT Configuration in TwinCAT (from B&R POWERLINK)

The EtherCAT configuration replaces POWERLINK entirely. Configuration steps:

1. Install TwinCAT 3 XAE on development PC
2. Create new TwinCAT project (TwinCAT XAE project type)
3. Add target device — configure CX9020 IP address
4. Scan EtherCAT bus — TwinCAT System Manager auto-discovers connected terminals
5. Import ESI XML files — for any non-Beckhoff EtherCAT slaves (drives, gateways)
6. Map process data — link EtherCAT terminal I/O to PLC variables in the “I/O” mapping view
7. Configure drive axes — TwinCAT NC PTP for point-to-point, NC I for interpolated motion
8. Safety configuration — add TwinCAT Safety project, map safe I/O, write safety PLC program

openCONFIGURATOR: If migrating to a non-Beckhoff EtherCAT platform (CODESYS, Wago), use the open-source openCONFIGURATOR tool from the EtherCAT Technology Group (https://www.ethercat.org) instead of TwinCAT System Manager for bus configuration. openCONFIGURATOR provides similar EtherCAT network scanning and process data mapping capabilities.

Migration Path

1. Hardware: Replace B&R X20 CPU with Beckhoff CX9020 (or similar). Replace all X20 IO with EtherCAT terminals. Replace power supplies if needed.

2. Software:

   • Create new TwinCAT 3 project
   • Port IEC 61131-3 logic (ST code is most portable)
   • Configure EtherCAT IO in TwinCAT System Manager
   • Replace B&R library calls with TwinCAT library equivalents (see table above)
   • Configure motion control in TwinCAT NC PTP or NC I
   • Build HMI in TwinCAT HMI or web-based

3. Safety:

   • Replace B&R SafeLOGIC with TwinCAT Safety
   • Use EtherCAT FSoE safe terminals (EL6900, etc.)
   • Rewrite safety logic in TwinCAT Safe editor
   • Recertify (SIL assessment on new platform)

4. HMI replacement:

   • mapp View → TwinCAT HMI (Tc3_HMI) for PC-based visualization
   • Or use TwinCAT TF2000 (web-based HMI) for browser access
   • mapp View widget library has no TwinCAT equivalent; rebuild all screens
   • Consider third-party web HMI solutions if TwinCAT HMI is insufficient

Beckhoff vs Siemens vs B&R Stay: Decision Matrix

8. Migration Project Planning

Phase Overview

Phase 1: Document Existing System         Week 1-2
Phase 2: Functional Requirements Spec     Week 2-3
Phase 3: Hardware Selection                Week 3-4
Phase 4: Software Development              Week 4-12
Phase 5: Factory Acceptance Test           Week 12-13
Phase 6: Commissioning                     Week 13-14
Phase 7: Parallel Operation                Week 14-18
Phase 8: Decommissioning Old System        Week 18

Phase 1: Document Existing System

Duration: 1-2 weeks

See documentation-reconstruction.md for detailed procedures. Key deliverables:

• Hardware inventory with module types, positions, and firmware versions
• IO wiring diagrams (input/output mapping)
• Network configuration (IP addresses, POWERLINK topology)
• Software version information (AR version, AS project version)
• Safety system documentation (if applicable)
• Photographs of all wiring, module positions, and label plates
• Export of current PLC program (if accessible)

Critical deliverable for cross-platform migration: A functional requirements document that describes what the machine does, not how it does it. This separates the machine’s behavior from the specific implementation.

Phase 2: Functional Requirements Specification

Duration: 1 week

Document what the control system must do in platform-independent terms:

1. Process flow: Step-by-step description of machine operation
2. IO list: Every input, output, analog value, and its function
3. Interlocks: All safety and operational interlocks
4. Sequences: All automatic sequences (start-up, normal operation, shutdown, emergency stop)
5. Alarms: All alarm conditions and responses
6. Setpoints: All operator-adjustable parameters
7. Communication: All external interfaces (HMIs, SCADA, MES, other PLCs)
8. Motion: All axes, speeds, positions, cam profiles
9. Safety: All safety functions and their SIL requirements

This document becomes the acceptance criterion for the new system. It also serves as the primary input if you need to recreate the program from scratch.

Phase 3: Hardware Selection

Duration: 1 week

Based on functional requirements, select target platform:

Score each option on a 1-10 scale, multiply by weight, sum.

Phase 4: Software Development

Duration: 4-8 weeks (varies with complexity)

For in-family migration: 2-5 days (mostly recompile and verify) For cross-platform migration: 4-12+ weeks

Milestones:

• Development environment configured
• IO mapping table completed (old addresses to new addresses)
• Core control logic ported
• All sequences implemented
• All alarms implemented
• Motion control configured (if applicable)
• HMI screens created
• Communication interfaces tested
• Safety logic implemented (if applicable)
• Unit testing complete

Phase 5: Factory Acceptance Test

Duration: 1 week

Conduct FAT with machine or IO simulation:

• Verify all IO points against requirements document
• Test all sequences manually and in automatic
• Verify alarm behavior
• Test communication interfaces
• Verify safety system (if applicable)
• Document any deviations from requirements
• Obtain sign-off from stakeholders

Phase 6: Commissioning

Duration: 1 week

• Install new hardware during planned downtime
• Wire IO (or verify preserved wiring for in-family swap)
• Download software
• Verify IO point-by-point
• Test sequences with machine
• Adjust timing and parameters
• Document all changes from FAT

Phase 7: Parallel Operation

Duration: 2-4 weeks

• Run new system in parallel with old (if architecture allows)
• Or: run new system with old system on standby
• Monitor for anomalies
• Train operators on any HMI changes
• Tune performance parameters

Phase 8: Decommissioning Old System

Duration: 1 day

• Remove old hardware
• Archive old CF card and project file
• Update maintenance documentation
• Return old hardware to spare parts pool (if functional) or dispose
• Update asset register

Resource Estimation

9. Minimizing Downtime During Migration

Strategy 1: Pre-Commissioning on Bench

Before the shutdown, build a replica of the new system on a workbench:

1. Mount new CPU and IO modules on DIN rail
2. Wire test inputs (switches, buttons) and test outputs (LEDs, relays)
3. Download software and verify basic operation
4. Simulate IO states using manual switches or test software
5. Test all sequences, alarms, and safety logic
6. Resolve all software issues before the production shutdown

Benefit: Reduces commissioning downtime by 50-75%.

Strategy 2: Staged Migration

For complex systems, migrate in stages over multiple short shutdowns:

Stage 1 (Shutdown 1, 4-8 hours):
  - Install new CPU alongside old CPU
  - Wire new CPU to existing IO (parallel wiring)
  - Pre-position all cables

Stage 2 (Shutdown 2, 4-8 hours):
  - Switch IO connections from old to new CPU
  - Verify IO point-by-point
  - Run machine on new CPU

Stage 3 (Shutdown 3, 2-4 hours):
  - Remove old CPU and wiring
  - Final cleanup and documentation

Strategy 3: IO Mapping Preservation

When migrating within B&R (X20 to X20), preserve IO addresses:

1. Document all IO addresses in old system
2. In new system, manually set IO addresses to match old system
3. Program references remain unchanged
4. Only hardware configuration changes, not software logic

This technique reduces software modification to near zero for in-family swaps.

Strategy 4: Temporary Bridge PLC

For cross-platform migrations where downtime must be minimized:

1. Install a small, inexpensive PLC (e.g., Wago 750-8206) as a temporary controller
2. Program it with minimal logic to keep the machine running (manual mode only)
3. This frees the original B&R hardware for reference during migration
4. Or: this allows the original hardware to be decommissioned safely

Strategy 5: Rollback Plan

Always have a rollback plan:

Rollback Checklist (before starting migration):
[ ] Old CPU CF card fully backed up (dd image)
[ ] Old CPU stored in anti-static bag, labeled
[ ] IO wiring diagram documented (with photos)
[ ] All IO connections can be restored to old configuration within 2 hours
[ ] Backup of all new software and configurations
[ ] Test procedure for verifying rollback success
[ ] Decision criteria: when to abort migration and rollback
[ ] Rollback decision authority identified (who makes the call)

Downtime Estimation by Strategy

10. Cost/Benefit Analysis Framework

Repair Cost Model

Total Repair Cost = Parts Cost + Labor Cost + Downtime Cost + Risk Cost

Parts Cost:
  CF card:           $20 - $80
  Battery (CR2032):  $5 - $15
  Capacitors:        $10 - $50
  PSU replacement:   $50 - $200
  Base module:       $200 - $400

Labor Cost:
  Diagnosis:         1-4 hours   x   hourly rate
  Repair:             0.5-4 hours x   hourly rate
  Testing:            1-4 hours   x   hourly rate

Downtime Cost:
  Production loss per hour x estimated downtime hours
  (typically 1-8 hours for repair scenarios)

Risk Cost (probability-weighted):
  P(failure within 6 months) x (replacement cost + downtime cost)
  Example: 30% chance of failure within 6 months
           x $5,000 replacement cost
           = $1,500 risk cost

Example Repair Calculation:
  Parts (CF card):    $40
  Labor (4 hours):    4 x $100/hr = $400
  Downtime (4 hours): 4 x $500/hr = $2,000
  Risk (30% x $5000): $1,500
  TOTAL:              $3,940

In-Family Upgrade Cost Model

Total Upgrade Cost = Hardware Cost + Software Cost + Labor Cost +
                     Downtime Cost + Commissioning Cost

Hardware Cost:
  New CPU (X20CP1485):     $2,000 - $3,500
  SD card (if not included): $20 - $60
  New firmware license (if needed): $0 - $500
  Mounting hardware (if needed): $0 - $50

Software Cost:
  Automation Studio license: $0 (already have)
  Library updates: $0 - $200

Labor Cost:
  Preparation and planning:  8-16 hours  x hourly rate
  Hardware swap:             4-8 hours   x hourly rate
  Software migration:        4-16 hours  x hourly rate
  Testing:                   8-16 hours  x hourly rate

Downtime Cost:
  Production loss per hour x estimated downtime hours
  (typically 4-16 hours for in-family swap)

Commissioning Cost:
  IO verification:  4-8 hours   x hourly rate
  Safety verification: 4-8 hours x hourly rate
  Run-in monitoring: 8-16 hours x hourly rate

Example In-Family Upgrade Calculation:
  Hardware (CPU):              $2,500
  Software:                    $100
  Labor (40 hours):            40 x $100/hr = $4,000
  Downtime (8 hours):          8 x $500/hr = $4,000
  Commissioning (16 hours):    16 x $100/hr = $1,600
  TOTAL:                       $12,200

Platform Migration Cost Model

Total Migration Cost = Hardware Cost + Software/License Cost +
                        Engineering Cost + Downtime Cost +
                        Commissioning Cost + Safety Cost +
                        Training Cost + Risk Contingency

Hardware Cost:
  New PLC CPU:                $1,000 - $6,000
  IO modules (all replaced):  $5,000 - $25,000
  Networking equipment:      $500 - $3,000
  Power supplies:            $200 - $1,000
  Cabinets/enclosures:       $500 - $3,000
  Cabling/wiring:            $1,000 - $5,000

Software/License Cost:
  Programming software:       $1,000 - $5,000
  Communication drivers:     $200 - $2,000
  HMI software:               $500 - $3,000
  Safety software (if needed): $500 - $2,000

Engineering Cost:
  Documentation:              40-80 hours  x hourly rate
  Software development:       200-800 hours x hourly rate
  Testing and simulation:     40-80 hours  x hourly rate
  HMI development:           40-120 hours x hourly rate

Downtime Cost:
  Production loss per hour x estimated downtime hours
  (typically 40-160 hours for full migration)

Commissioning Cost:
  Installation:              40-80 hours  x hourly rate
  IO verification:            16-40 hours  x hourly rate
  Sequence testing:          40-80 hours  x hourly rate
  Safety validation:         40-80 hours  x hourly rate
  Performance tuning:        16-40 hours  x hourly rate

Safety Cost (if applicable):
  Safety engineering:         $5,000 - $15,000
  SIL assessment:             $3,000 - $10,000
  Third-party validation:    $2,000 - $8,000
  F-I/O modules:              $2,000 - $8,000

Training Cost:
  Engineering team:          $2,000 - $8,000
  Maintenance team:          $500 - $2,000
  Operators:                 $500 - $2,000

Risk Contingency:
  20-30% of total above (unforeseen issues)

Example Platform Migration (B&R to Siemens, moderate complexity):
  Hardware:                    $18,000
  Software/Licenses:           $5,500
  Engineering (500 hours):      500 x $100/hr = $50,000
  Downtime (80 hours):         80 x $500/hr = $40,000
  Commissioning (200 hours):   200 x $100/hr = $20,000
  Safety:                      $15,000
  Training:                    $6,000
  Contingency (25%):           $38,625
  TOTAL:                       $193,125

Ongoing Maintenance Cost Comparison (Annual)

ROI Calculation

ROI = (Annual Savings - Annual Cost) / Migration Investment x 100%

Annual Savings = Old annual maintenance - New annual maintenance
                + Reduced downtime value
                + Reduced failure probability value

Annual Cost = New annual maintenance
            + License fees
            + Support contracts

Example (B&R in-family upgrade):
  Migration investment: $12,200
  Old annual maintenance: $5,000
  New annual maintenance: $3,000
  Reduced downtime: 4 hours/year x $500/hr = $2,000
  Reduced failure probability: $200/year saved

  Annual savings: $5,000 - $3,000 + $2,000 + $200 = $4,200
  Annual net benefit: $4,200 - $3,000 = $1,200
  ROI: $1,200 / $12,200 x 100% = 9.8%
  Payback period: $12,200 / $1,200 = 10.2 years

Example (B&R to Siemens, with 7-year machine life remaining):
  Migration investment: $193,125
  Old annual maintenance: $5,000
  New annual maintenance: $3,000
  Reduced downtime: 16 hours/year x $500/hr = $8,000
  Reduced failure probability: $200/year saved

  Annual savings: $5,000 - $3,000 + $8,000 + $200 = $10,200
  Annual net benefit: $10,200 - $3,000 = $7,200
  ROI: $7,200 / $193,125 x 100% = 3.7%
  Payback period: $193,125 / $7,200 = 26.8 years

  This migration would NOT pay for itself within the machine's remaining life.
  In-family upgrade is the correct choice.

Decision Rule Summary

IF machine remaining life < 3 years AND system is repairable:
    -> REPAIR (Zone 1-2)
    Budget: $10 - $500
    Risk: Low

ELIF machine remaining life 3-7 years AND project file available:
    -> IN-FAMILY UPGRADE (Zone 3)
    Budget: $1,500 - $8,000
    Risk: Low-Medium

ELIF machine remaining life > 7 years AND OEM standardization needed:
    -> CROSS-PLATFORM MIGRATION (Zone 4)
    Budget: $15,000 - $80,000
    Risk: Medium-High

ELIF full redesign of machine control required:
    -> FULL REDESIGN (Zone 5)
    Budget: $25,000 - $200,000+
    Risk: High

ELIF no project file AND no documentation:
    -> DOCUMENTATION FIRST
    See documentation-reconstruction.md
    Then reassess.

11. Legacy B&R Specific Considerations

B&R 2003 / B&R 2005 Systems

B&R’s predecessor system (2003/2005 series) uses different hardware, different programming (AS V2.x or earlier), and different IO. Migration from 2003/2005 to X20 is effectively a platform migration:

Migration path: AS 2.x projects can sometimes be imported into AS 4.x, but this is not guaranteed. AWL (Anweisungsliste) is B&R’s proprietary instruction list language that has no direct equivalent in IEC 61131-3 IL. AWL programs must be manually rewritten in ST.

B&R Power Panel Migration

B&R Power Panel devices combine HMI and PLC functionality. Migration options:

B&R APROL (DCS) Migration

APROL is B&R’s process automation / DCS platform. Migration from older APROL versions:

1. In-place upgrade: APROL V3.x to APROL V4.x (supported by B&R migration tools)
2. APROL to X20-based control (if process control complexity justifies DCS)
3. APROL to alternative DCS (Siemens PCS 7, ABB 800xA, Emerson DeltaV)

APROL migration is beyond the scope of this guide due to its process-industry-specific complexity.

Safety System Recertification Requirements

When any safety-related hardware or software changes, recertification may be required:

Recertification process:

1. Update Safety Requirements Specification (SRS)
2. Update Safety Validation Report
3. Perform functional safety testing on new hardware
4. Document all changes and their safety impact
5. Have independent assessor review (for SIL 2+)
6. File updated documentation

Estimated recertification effort: 1-4 weeks for in-family, 2-8 weeks for cross-platform.

Adaptive Manufacturing and the ACOPOS D1 (2026 Context)

B&R’s 2026 Innovation Days theme is adaptive automation — moving from rigid production lines to flexible, modular manufacturing systems. As part of this strategy, B&R launched the ACOPOS D1 servo drive in Pune, India (March 2026), targeting compact cabinet footprint, scalable multi-axis motion, and built-in edge intelligence for predictive maintenance.

Implications for CP1584 machine remanufacturing:

• If you are extending the life of a CP1584-based machine by 7+ years, the D1 (and likely AR 6.x controllers) represents the forward-looking migration target
• The D1’s edge intelligence for predictive uptime aligns with modern IIoT strategies (see iiot-retrofit.md)
• Adaptive manufacturing principles (modular machine design, software-configurable production) may influence how you architect control systems during remanufacturing
• B&R’s India-first launch of the D1 signals growing investment in the India/Asia-Pacific market, which may improve spare parts availability and local support for B&R systems in those regions

Note: As of mid-2026, the ACOPOS D1 has not been fully specified publicly. When technical specifications become available, evaluate it as a potential replacement for aging ACOPOS 8V1 drives. See acopos-drives.md for the D1 section and the complete ACOPOS family reference.

Automation Studio 4 to Studio 6 Migration (AS4 → AS6)

As of 2024-2026, B&R has released Automation Studio 6 (AS6) as the successor to the long-standing AS 4.x line. This migration is increasingly relevant for engineers maintaining CP1584 machines because:

1. EU Cyber Resilience Act (CRA) compliance — CRA requirements apply from December 2027 and mandate security-by-design for connected products. Machines placed on the EU market after this date must comply. AS6 incorporates IEC 62443-4-1 compliant security features that AS4 cannot provide.
2. AS4 end-of-life timeline — While B&R has not announced a hard EOL for AS4, the CRA effectively forces migration for any machine that must remain in production or be sold in the EU after 2027.
3. New CPU hardware requires AS6 — The X20CP1684 (successor to CP1584) requires Automation Studio 4.7 minimum or preferably AS 6.0+.

Key Differences Between AS4 and AS6

Community Migration Tools (Free)

The B&R Community maintains an open-source tool specifically for AS4→AS6 migration analysis:

as6-migration-tools — https://github.com/br-automation-community/as6-migration-tools

This tool scans AS 4.12 project files and generates a migration report identifying:

• Deprecated libraries and function blocks
• Unsupported hardware references
• OPC UA structural changes needed
• mappMotion API changes
• AsMath and AsString function replacements
• Missing mapp technology licenses
• Common migration pitfalls

Installation and usage:

## Option 1: Download Windows EXE from GitHub Releases
## https://github.com/br-automation-community/as6-migration-tools/releases/latest
## Unzip and run as6-migration-tools.exe

## Option 2: From source
git clone https://github.com/br-automation-community/as6-migration-tools.git
cd as6-migration-tools
pip install -r requirements.txt
python gui_launcher.py
## Or for CLI:
python as4_to_as6_analyzer.py "C:\Projects\MyAS4Project"

Helper scripts included:

The tool is non-destructive by default — it analyzes and reports before making changes. Run the analyzer first, review the report, then apply helper scripts selectively.

Important limitations:

• The tool does NOT perform a fully automatic migration. It provides analysis and recommendations.
• Helper scripts make best-effort changes based on known patterns but do not cover all edge cases.
• Manual review and validation is always required after running any helper script.
• Requires Python 3.12 (tested).

Official B&R Migration Resources

B&R provides a free online course for the migration:

• ENG: https://share.articulate.com/5PakLoeB_I2sjJxoopM5t (Migration to AS 6 – Step-by-Step Checklist)
• GER: https://share.articulate.com/4ma0vcvpVY_WxgVuoMDCu (Migration auf Automation Studio 6)
• Requires one-time registration on B&R’s learning platform.

B&R also offers paid migration services:

• Dedicated engineering service — B&R engineers perform the full migration
• Migration consulting — B&R analyzes your project and provides an optimization strategy

AS4→AS6 Migration Procedure for CP1584 Machines

Prerequisites:

1. Recovered AS4 project file (.apj + all source files) — see project-reconstruction.md
2. Automation Studio 6 installed on a PC (available from B&R downloads with active service contract, or via B&R Value Provider)
3. Access to the CP1584 target hardware for testing

Step-by-step migration:

1. Analyze the AS4 project with as6-migration-tools:

   python as4_to_as6_analyzer.py "C:\Projects\Recovered_AS4_Project"
   

   Review the generated report. Address all CRITICAL and HIGH severity items.

2. Open the project in AS6. AS6 can open AS 4.12 projects with an automatic migration wizard. The wizard will:

   • Convert project file format
   • Update library references to newer versions
   • Flag deprecated function blocks and renamed libraries
   • Identify hardware that is no longer supported

3. Resolve deprecated libraries. Common replacements:

   AS4 Library	AS6 Equivalent	Notes
   AsMath	AsBrMath	Run helper script asmath_to_asbrmath.py
   AsString	AsBrStr	Run helper script asstring_to_asbrstr.py
   mappMotion 4.x	mappMotion 6	Run helper script mappmotion_update.py
   Legacy OPC UA components	mappService OPC UA	Restructured OPC UA configuration

4. Update OPC UA configuration. AS6 uses a restructured OPC UA information model. Run helpers/asopcua_update.py and manually review the changes. Test with an OPC UA client (UaExpert, Prosys).

5. Update hardware configuration. If migrating to a newer CPU (e.g., X20CP1684), update the hardware tree in AS6. See spare-parts.md Section 3.2 for CPU upgrade paths and firmware-version-mgmt.md for firmware compatibility.

6. Compile and resolve errors. The AS6 compiler provides improved diagnostics compared to AS4. Address all compilation errors and warnings.

7. Test on a bench. Before deploying to the production machine:

   • Build the new target hardware (or use the existing CP1584 if hardware is unchanged)
   • Download the AS6-compiled program
   • Run IO point-by-point verification (see documentation-reconstruction.md Section 6.3)
   • Verify all machine sequences and safety systems

8. Deploy during a planned shutdown. The production deployment follows the same procedure as any firmware upgrade. See firmware-version-mgmt.md for the production deployment checklist.

Estimated migration effort:

Critical gotchas:

• mapp components are restructured in AS6. mappService, mappMotion, mappView, and other mapp components have been reorganized with new hierarchies. This is the single largest manual effort in most migrations.
• Safety programs require special handling. SafeLOGIC programs must be migrated using SafeDESIGNER (AS6 version). Do not attempt to manually convert safety logic — use the official migration path.
• AR 6.x firmware requires the matching AS6 compiler. You cannot compile AR 6.x programs with AS 4.x, and vice versa.
• CF card format changes. AR 6.x may use a different CF card partition layout than AR 4.x. The CF card must be regenerated using AS6’s Generate CF/SD Card function.
• OPC UA certificates must be regenerated. AS6 uses a different OPC UA certificate management system. Existing certificates from AS4 will not work.
• ANSL/PVI protocol changes. External PVI connections may need updated client libraries for AR 6.x compatibility. See pvi-api.md for PVI version requirements.

X20CP1684 — The CP1584 Successor

B&R has released the X20CP1684 as the direct successor to the CP1584. This is relevant when remanufacturing a CP1584 machine and deciding whether to upgrade the CPU.

Key differences for migration:

• The CP1684 uses internal flash instead of CompactFlash — no more CF card failures, but also no removable media for backup. Use FTP or Automation Studio transfer instead.
• The LPDDR4 memory is twice the capacity and significantly faster than DDR2.
• Automation Studio 6 is the recommended development environment for CP1684.
• X20 IO modules, bus modules, and interface modules are fully compatible between CP1584 and CP1684 (same X2X bus, same POWERLINK).

Migration path CP1584 → CP1684:

1. Recover the AS4 project (see project-reconstruction.md)
2. Migrate project to AS6 (see above procedure)
3. Update hardware tree: replace X20CP1584 with X20CP1684
4. Compile, test on bench, deploy during planned shutdown
5. No IO module changes needed — all X20 modules are compatible

See cp1584-hardware-ref.md for the complete CP1584 hardware reference and spare-parts.md for ordering information.

12. Cross-References

13. Key Findings

1. B&R X20 is not obsolete. The X20 platform is actively sold and supported by B&R. In-family migration is always the lowest-risk path when the project file is available.

2. Recovery of the Automation Studio project file is the single most important prerequisite. Without it, migration effort multiplies 3-5x. Prioritize CF card backup and project file recovery before any other action. See project-reconstruction.md and cf-card-boot.md.

3. CP1584 is repairable for most common failure modes. CF card failure ($20-80), battery replacement ($5-15), and capacitor replacement ($10-50) address the majority of failures. Only CPU-level failures (processor, FPGA, DDR2) require replacement.

4. In-family CPU swap costs $3,000-$8,000 total. Cross-platform migration costs $25,000-$200,000+. The cost difference is almost always decisive for machines with remaining life under 7 years.

5. POWERLINK and FPGA-based X20 bus communication are not portable to other platforms. Any migration away from B&R requires complete IO replacement. This is the single largest cost driver in cross-platform migration ($5,000-$25,000 for IO alone).

6. Safety system migration is the most complex and risky aspect of any platform change. SafeLOGIC to a different safety platform requires full SIL recertification, complete logic rewrite, and 2-8 weeks of safety engineering. Budget $5,000-$25,000 for safety migration alone.

7. Pre-commissioning on a workbench reduces production downtime by 50-75%. Build the new system on a bench, test all logic and IO, and resolve software issues before the production shutdown.

8. IO mapping preservation is key for in-family swaps. By manually setting new IO addresses to match old addresses, the program requires zero modification for IO references. This reduces in-family swap downtime to 4-8 hours.

9. Secondary market CP1584 units are available ($400-$2,000) but carry risk. Match firmware versions. Test thoroughly before deploying as a spare. Budget for potential software incompatibilities.

10. Automation Studio 4.x can open AS 3.x projects with migration steps. The migration is mostly automatic but may flag deprecated function blocks and renamed libraries. Resolve all migration warnings before deploying.

11. CODESYS V3 is the most practical cross-platform target if leaving B&R is necessary, because it uses standard IEC 61131-3 and runs on hardware from multiple vendors. However, B&R-specific libraries and mapp components have no CODESYS equivalent and must be rewritten from scratch.

12. The “repair vs replace” decision is primarily a function of machine remaining life and failure type. Use the decision framework in Section 2. Repair for machines with less than 3 years of remaining life. Upgrade in-family for 3-7 years. Consider cross-platform migration only for 7+ years remaining life.

13. AS4→AS6 migration is necessary for CRA compliance. The EU Cyber Resilience Act requires connected products placed on the EU market after December 2027 to meet IEC 62443-4-1 security requirements. AS6 is B&R’s CRA-compliant platform. The community-maintained as6-migration-tools (github.com/br-automation-community/as6-migration-tools) provides free automated analysis and helper scripts for the migration.

14. X20CP1684 replaces CP1584 as the current-generation 1-slot X20 CPU. The CP1684 uses internal flash (no CF card), 512 MB LPDDR4 RAM, and requires AS 4.7+ (recommended AS 6.0+). All X20 IO modules and interface modules are fully compatible, making in-family CPU upgrade straightforward when the AS4 project is available.

15. New X20 generation (Apollo Lake I) with OPC UA over TSN is the future-proof path. B&R’s newest X20 controllers add OPC UA over TSN support and field-level master capability. Combined with AR 6.5’s hard real-time multicore task scheduling (assign task classes to specific CPU cores), these controllers deliver deterministic control and modern networking in the same compact form factor. The X20CP0484-1 (512 MB RAM, 2 GB flash) is the budget AR 6.x entry point. The X20CP3687X delivers PC-class performance in a compact X20 package.

16. AS 6.5 (December 2025) is the current latest release. Key features: ST-OOP (inheritance, polymorphism, abstract classes), ManagedCertificateStore extended to ANSL/FTP/HTTP/SMTP, FTP RBAC, SMB 1.0 permanently disabled, SNI support in AsHttp, certificate signing requests (CSR) via ArCert, self-signed certificate validation warnings, and TFTP disabled by default. AR 6.5 adds multicore hard real-time, FTP RBAC, and hypervisor repair boot. See firmware-version-mgmt.md §3.2 for the complete release history.

14. Sources

• B&R Industrial Automation. “X20 System Overview and Catalog.” br-automation.com. Active product line documentation.
• B&R Industrial Automation. “Automation Studio 4 Migration Guide.” Technical documentation for upgrading from AS 3.x to AS 4.x.
• B&R Industrial Automation. “X20CP1584 Technical Data Sheet.” Hardware reference.
• B&R Industrial Automation. “POWERLINK - Ethernet POWERLINK Standardisation Group (EPSG).” openPOWERLINK.org.
• B&R Industrial Automation. “SafeLOGIC Safety System Technical Manual.” SIL 2/3 safety controller documentation.
• CODESYS Group. “CODESYS V3.5 Programming Guide.” codesys.com.
• CODESYS Group. “CODESYS EtherCAT and POWERLINK Support Documentation.”
• Siemens AG. “SIMATIC S7-1500 System Manual.” Siemens documentation portal.
• Siemens AG. “TIA Portal Migration Guide.”
• Beckhoff Automation. “TwinCAT 3 System Documentation.” beckhoff.com.
• EPSG (Ethernet POWERLINK Standardisation Group). “POWERLINK Communication Profile Specification.” ethernet-powerlink.org.
• IEC 61131-3:2013. “Programmable Controllers - Part 3: Programming Languages.” International Electrotechnical Commission.
• IEC 61508. “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.” International Electrotechnical Commission.
• ISA-TR84.00.04. “Guidelines for the Implementation of ANSI/ISA-84.00.01-2004.”
• Pilz GmbH. “Safety Migration Planning Guidelines.” Industry technical paper.
• Various industrial automation broker and surplus listings (PLC Center, Radwell, surplus.net). Pricing data for spare parts and used equipment as of 2024-2025.
• Practical field experience with B&R X20CP1584 systems in manufacturing environments.
• Industry standard lifecycle management practices for industrial control systems (ISA-95, IEC 62443 for cybersecurity considerations during migration).
• B&R Community Forum. “AS4->AS6: Migration Made Simple: Tools, Community & Free Courses.” https://community.br-automation.com/t/as4-as6-migration-made-simple-tools-community-free-courses/8553
• br-automation-community/as6-migration-tools. GitHub repository. https://github.com/br-automation-community/as6-migration-tools
• B&R Industrial Automation. “X20CP1684 Product Page.” br-automation.com. https://www.br-automation.com/en-us/products/plc-systems/x20-system/x20-plc/x20cp1684/
• B&R Industrial Automation. “Automation Studio 6 Features.” B&R Community. https://community.br-automation.com/t/b-r-automation-studio-6-features/2979
• B&R Community Forum. “Project Migration from Automation Studio 4.12 to 6.1.” https://community.br-automation.com/t/project-migration-from-automation-studio-4-12-to-6-1/7309
• EU Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• B&R Industrial Automation. “TÜV Rheinland confirms B&R’s CRA Guide for POWERLINK.” https://www.br-automation.com/en/about-us/press-room/tuev-rheinland-confirms-brs-cra-guide-for-powerlink-31-03-2026/
• B&R Community Forum. “Why on earth is B&R discontinuing software that works?” https://community.br-automation.com/t/why-on-earth-is-b-r-discontinuing-software-that-works/11332