Documentation Reconstruction for Undocumented B&R Machines

Overview

When an OEM goes out of business or abandons support, automation engineers are left maintaining machines built on B&R CP1584 hardware with zero documentation: no source code, no wiring diagrams, no IO maps, no maintenance manuals, and no explanation of program logic. This guide provides a systematic methodology for reconstructing a complete documentation set from scratch using physical inspection, runtime observation, forensic extraction, and reverse-engineering techniques specific to B&R Automation Studio and the X20 ecosystem.

The reconstruction process follows five parallel tracks:

1. Physical infrastructure documentation — wiring, panel layouts, field devices
2. IO mapping reconstruction — linking every physical wire to every software address
3. Program behavior documentation — recording what the logic does at runtime
4. Communication mapping — documenting every network connection and data exchange
5. Maintenance manual assembly — combining all findings into actionable procedures

None of these tracks requires the original source code. Together they produce a documentation package that enables safe maintenance, troubleshooting, and eventual reprogramming.

Audience: Automation engineers maintaining B&R CP1584 machines from defunct OEMs.

Prerequisites:

• Network access to the CP1584 (see cp1584-forensics.md Section 1 for discovery)
• Automation Studio installed (any version 4.x or newer)
• Physical access to the machine control panel
• Multimeter, label maker, camera, and a laptop

Related documents:

• project-reconstruction.md — Recovering the Automation Studio project structure
• cp1584-forensics.md — Forensic data extraction from the running PLC
• memory-map.md — B&R memory addressing and IO data layout
• io-card-hardware.md — X20 IO card types, diagnostics, and LED codes
• io-sniffing.md — Fieldbus traffic capture and analysis
• program-reverse-engineering.md — Binary analysis of compiled B&R code

1. Phase 0: Preservation and Safety

Before any reconstruction begins, preserve every piece of existing information and establish safe working conditions.

1.1 Capture Everything That Exists

Even an undocumented machine often has fragments of information scattered across nameplates, stickers, hand-written labels, and old drawings stuffed inside cabinet doors.

Procedure:

1. Photograph every nameplate, label, and marking on every component in the control cabinet — DIN rail modules, power supplies, circuit breakers, contactors, VFDs, terminals, and the PLC itself.
2. Photograph the inside of every cabinet door — OEMs sometimes tape drawings or cheat sheets inside.
3. Photograph the front and back of every HMI screen — note any model numbers, firmware versions visible in settings menus.
4. Check for any paperwork in the machine area: operator manuals (even for sub-assemblies), startup checklists, calibration certificates, maintenance logs left by previous technicians.
5. If any USB drives, CF cards, or backup media are found, image them immediately with dd before any other access:

   dd if=/dev/sdX of=cf_card_backup.img bs=4M status=progress
   

6. Extract the CF card from the CP1584 and image it — it may contain source code, configuration files, or logs. See cf-card-boot.md for the extraction procedure and config-file-formats.md for file format analysis.

1.2 Lockout/Tagout and Safety Documentation

Before any hands-on work, document the safety systems present on the machine.

1. Identify every emergency stop button (physical location, color, type — mushroom-head, pull-to-release, key-release).
2. Trace the E-stop chain: follow the hardwired safety circuit from each E-stop through safety relays to the PLC safety inputs. Document every intermediate contact.
3. Document every safety-rated device: light curtains, safety mats, interlock switches, guard door sensors, two-hand stations.
4. Record the part numbers and models of all safety relays and safety controllers.
5. Create a Safety Interlock Table — even without the original drawing, you can build this by:
   • Cycling each guard door / interlock one at a time while observing which inputs change on the PLC
   • Recording the machine’s response (immediate stop, controlled stop, warning only)
   • Documenting which actuators are disabled by each interlock

2. Phase 1: Physical Infrastructure Documentation

2.1 Control Panel Inventory

Create a complete inventory of every component in the electrical cabinet.

Equipment Inventory Table Template:

For B&R X20 modules specifically, record:

• Module type and order on the DIN rail (left to right)
• Serial numbers (visible on module label)
• Hardware revision
• Firmware version (visible in Automation Studio online view or via SDM)
• LED state at power-on and during normal operation

This information is critical for replacement ordering and is covered in detail in io-card-hardware.md Section 8.

2.2 Wire Tracing and Numbering

Wire tracing is the most time-consuming phase but produces the most valuable output. Every wire in the cabinet must be accounted for.

Tools Required:

• Digital multimeter with continuity mode
• Wire tracer / tone generator (for long conduit runs)
• Cable identifier set (for multi-core cables)
• Label printer (Brady BMP21 or equivalent)
• Camera for documenting routing before disconnecting

Wire-by-Wire Tracing Procedure:

1. Establish a numbering scheme before starting. Recommended convention:

   • XX-Y where XX = page/drawing number, Y = wire number
   • Example: 01-001, 01-002 — sequential per power rail
   • For B&R terminal blocks: use the terminal number as the primary identifier

2. Start with power distribution:

   • Trace every incoming power line from the main disconnect through breakers to transformers to power supplies.
   • Document voltage at every stage (L1, L2, L3, N, PE, 24VDC+, 24VDC-, 120VAC, etc.).
   • Mark every ground/PE connection.

3. Trace every IO wire:

   • At the field terminal block (where wires leave the cabinet), note the wire number.
   • Follow it to the IO module terminal.
   • Record the IO module slot position and terminal pin.
   • Cross-reference with the device it connects to in the field.

4. Apply temporary labels as you go. Use self-laminating wire markers that wrap around the wire.

5. Photograph every row of terminals before and after labeling to create a photographic record.

2.3 Creating Wiring Diagrams from Physical Inspection

Since there are no original drawings, you must create them. Use CAD software (AutoCAD Electrical, EPLAN, or even draw.io for initial drafts).

Diagram Types to Create:

IO Wiring Matrix Template:

2.4 B&R X20 Specific: Reading the Hardware Tree

The CP1584 maintains a complete hardware configuration that can be read without source code. This gives you the IO module layout, addressing, and module types — the software side of the wiring matrix.

Procedure (see cp1584-forensics.md Section 5 and project-reconstruction.md Section 8):

1. Connect via Automation Studio: Online → Settings → enter PLC IP → Connect
2. In the System Tree (left panel), expand the hardware configuration to see every module:
   • CPU model and firmware
   • Bus couplers
   • IO stations
   • Every IO module with slot, channel count, and type
3. Use Target Settings → Runtime → System Dump to export a complete text dump of all hardware info
4. Cross-reference the hardware tree with your physical inspection — every module in software should exist on the DIN rail, and vice versa

Any discrepancy between the hardware tree and physical reality indicates a module was added, removed, or replaced after commissioning.

3. Phase 2: IO Mapping Reconstruction

IO mapping is the bridge between the physical wiring and the program logic. Without it, you cannot correlate field behavior with PLC behavior.

3.1 Generating the IO Map from Automation Studio

The IO map on a B&R CP1584 is partially determined by the hardware tree and partially by the programmer’s variable naming. Two approaches are needed.

Approach A: Hardware-Derived IO Addresses

B&R X20 modules are automatically mapped to IO ranges based on slot position. See memory-map.md Section 5 for the automatic addressing rules.

1. In Automation Studio, connect to the PLC and open the IO Configuration view.
2. Document the base address assigned to each IO module based on its position in the station.
3. For each module, list every channel’s automatic address.

Approach B: Variable Name Discovery via PVI/OPC-UA

The compiled program’s variable names are accessible even without source code, provided the OEM did not disable symbol export.

• OPC-UA browse (see cp1584-forensics.md Section 6): Connect an OPC-UA client and enumerate all variable nodes. Names like gMachine.nState, gAxis[1].bHome, gDI_Cylinder_A_Extend reveal the naming convention and purpose.
• PVI enumeration (see cp1584-forensics.md Section 7 and pvi-api.md): Use PVI Manager to dump all accessible variables with names, types, and current values.

3.2 IO Mapping from Online Observation

When variable names are unhelpful (e.g., DI_01, DO_05), you must determine what each IO point does by observing the machine.

Procedure:

1. Create a blank IO mapping spreadsheet with columns:

| IO Address | Auto Address | Module | Slot/Ch | Variable Name | Physical Wire | Field Device | Observed Behavior | State Normal | Verified |

2. For digital inputs — the actuation test:

   • Manually operate each sensor, switch, and button on the machine one at a time.
   • In Automation Studio, open the Watch window and monitor all digital input variables simultaneously.
   • When an input changes state, note which variable toggled.
   • Record the field device that caused the change.

3. For digital outputs — the force test:

   • In Automation Studio, use the Force function on output variables.
   • Force each output ON one at a time.
   • Walk the machine and observe what physical device activates (solenoid valve clicks, relay pulls in, indicator lights up, motor starts).
   • WARNING: Only force outputs when it is safe to do so. De-energize actuators, ensure personnel are clear, and verify no interlocks will be violated. Use the safety circuits to prevent unexpected machine motion.

4. For analog inputs — the stimulus test:

   • Apply known signals to each analog input:
     • For 4-20mA inputs: use a process calibrator to inject 4mA, 12mA, 20mA and observe the variable value at each point.
     • For 0-10V inputs: use a variable DC power supply.
     • For thermocouple/RTD: use a temperature simulator or a known-temperature source (ice bath, boiling water).
   • Record the scaling: raw ADC value → engineering units.
   • See analog-calibration.md for detailed calibration procedures.

5. For analog outputs — the measure test:

   • Use a multimeter to measure the signal at each analog output terminal.
   • If possible, vary the output variable value in the Watch window (or force it to known values) and measure the resulting current/voltage.
   • Document the scaling relationship.

3.3 IO Mapping Table: Final Format

After completing all tests, compile the comprehensive IO map:

4. Phase 3: Program Logic Documentation from Runtime Behavior

Since source code is not available (see program-reverse-engineering.md and project-reconstruction.md Section 2), program logic must be documented through behavioral observation.

4.1 Variable Discovery and Categorization

Before tracing logic, build a complete variable dictionary.

Procedure:

1. Dump all variables via PVI or OPC-UA (see cp1584-forensics.md Sections 6-7).
2. Categorize by naming convention:
   • Prefix gDI_ or _DI → digital input
   • Prefix gDO_ or _DO → digital output
   • Prefix gAI_ or _AI → analog input
   • Prefix gAO_ or _AO → analog output
   • Prefix gAxis or _Axis → motion axis reference
   • Prefix gTimer or _Tmr → timer reference
   • Suffix _Set / _Reset → latch/unlatch
   • Suffix _Cmd / _Cmd → command
   • Suffix _Sts / _Fb → status / feedback
3. Record data types and initial values for every variable.

4.2 Machine Sequence Documentation

Document the complete machine operating sequence by observation.

Step-by-step procedure:

1. Record the normal operating cycle:

   • Start the machine from cold start (power-on).
   • Record every observable state change in order:

     T+0s: Power ON → all outputs OFF, homing required
     T+2s: Auto sequence initiated → conveyor M1 starts
     T+5s: Part detected at sensor B1-PS1 → cylinder A extends
     T+7s: Cylinder A extended (B1-LS2 asserted) → heater energizes
     ...
     

   • Use a video camera recording synchronized with Automation Studio trace data.

2. Use Automation Studio Trace:

   • Configure a Trace (Automation Studio → Tools → Trace) to record key variables at high resolution.
   • Record during one complete machine cycle.
   • Export the trace to CSV for analysis.
   • This gives you the exact timing and ordering of state transitions.

3. Build a State Transition Diagram:

[IDLE] --Start Cmd AND All Safeties OK--> [HOMING]
[HOMING] --All Axes Homed--> [AUTO_READY]
[AUTO_READY] --Cycle Start--> [CYCLE_RUNNING]
[CYCLE_RUNNING] --Sequence Complete--> [AUTO_READY]
[CYCLE_RUNNING] --E-Stop OR Fault--> [ESTOPPED]
[ESTOPPED] --Reset AND All Safeties OK--> [IDLE]

4. Document error/fault sequences:
   • Trigger each known fault condition (sensor failure, timeout, overload).
   • Record the machine’s response: which outputs turn off, which alarms activate, what the HMI displays.
   • Document the recovery procedure: what must be done to clear the fault and restart.

4.3 Logic Tracing via Forced Inputs

For critical logic paths, use forced inputs to trace cause-and-effect relationships.

Procedure:

1. In the Watch window, identify a variable that changes during a specific machine operation (e.g., a motor start command).

2. Force the input conditions that should trigger that output:

   • Force the start button input ON.
   • Observe: does the motor command go ON?
   • Release the start button. Does the motor command latch?

3. Work backwards through conditions:

   • If the motor does NOT start when the start button is forced ON, look for other conditions that must be true (safety interlocks, permissives, other sensor states).
   • Force each candidate condition ON one at a time until you identify all prerequisites.

4. Document findings as Boolean logic:

   Motor1_Run_Cmd = Start_PB AND NOT E_Stop_Chain AND NOT Motor1_OL
                     AND Motor1_Home_OK AND System_Auto_Mode
   

WARNING: Use forced values only in a controlled test environment. Never force safety-related inputs in an operational setting. Document every forced value change and revert it immediately after the test.

4.4 Timing and Sequencing Documentation

Many undocumented machines contain timers, delays, and sequencing that are not obvious from observation alone.

Capture timing with Automation Studio Trace:

1. Set up a Trace recording with 1ms resolution capturing all state machine variables and timer variables.
2. Run the machine through a complete cycle.
3. Export and analyze to identify:
   • Timer durations (e.g., cylinder dwell time = 2.3 seconds)
   • Sequencing dependencies (Event A must occur within 5 seconds of Event B)
   • Watchdog timeouts (what happens if a sensor does not assert within the expected window)
   • Minimum/maximum cycle times

5. Phase 4: Communication and Network Documentation

5.1 Network Topology Discovery

Document every communication connection involving the CP1584.

Procedure:

1. Use nmap to scan the PLC and all connected devices:

   nmap -sn 192.168.1.0/24
   nmap -sV -p 80,4840,11169,502,1080 <PLC_IP>
   

2. Check the CP1584 network configuration via SDM web interface (port 80) or Automation Studio Target Settings.
3. Document all configured interfaces: ETH1, ETH2, POWERLINK, serial ports.
4. For POWERLINK: document the MN (Managing Node) configuration and all CN (Controlled Node) devices. See powerlink-internals.md and x2x-protocol.md.
5. For PLC-to-PLC communication: document any Modbus, OPC-UA, or proprietary data exchange. See plc-to-plc.md and modbus-gateway.md.

5.2 HMI Documentation

If the machine has an HMI (Power Panel, mapp View, or third-party panel):

1. Photograph every screen at every state (running, faulted, maintenance mode).
2. Document every button and its effect.
3. Document every displayed value and its corresponding PLC variable (if possible via OPC-UA browsing).
4. Record alarm messages and their conditions.
5. Document any recipe or parameter screens with their adjustable values and ranges.
6. See hmi-integration.md for B&R-specific HMI analysis techniques.

5.3 Alarm and Event Log Mining

The CP1584 maintains alarm and event logs that reveal historical behavior patterns.

• Use the mapp Alarm or AlarmX components if configured (see alarm-logging.md).
• Check the SDM (System Diagnostics Manager) for hardware-level events.
• Export AR log files from the CF card for analysis.
• Document recurring alarms, their frequency, and the conditions that precede them.

6. Phase 5: Building the Maintenance Manual

6.1 Maintenance Manual Structure

Assemble all findings into a structured maintenance manual. This is the deliverable that enables future engineers to maintain the machine safely.

Recommended structure:

1. Machine Overview
   1.1 Purpose and Process Description
   1.2 Machine Identification (model, serial, year, OEM if known)
   1.3 System Architecture Diagram

2. Safety Systems
   2.1 Safety Device Inventory
   2.2 E-Stop Circuit Diagram
   2.3 Safety Interlock Table
   2.4 LOTO Procedures

3. Electrical Documentation
   3.1 One-Line Diagram
   3.2 Power Distribution
   3.3 IO Wiring Matrix
   3.4 Panel Layout Drawing
   3.5 Network Topology Diagram

4. PLC and Control System
   4.1 Hardware Configuration (CPU, IO modules, firmware versions)
   4.2 Complete IO Map (variable ↔ physical device)
   4.3 Program Logic Summary (state machine, sequences, interlocks)
   4.4 Communication Map (PLC-to-PLC, HMI, SCADA)
   4.5 IP Address and Network Configuration Table

5. Operation
   5.1 Startup Procedure
   5.2 Normal Shutdown Procedure
   5.3 Operating States and Transitions
   5.4 HMI Screen Reference

6. Troubleshooting
   6.1 Common Faults and Resolution
   6.2 Alarm Code Reference
   6.3 Diagnostic Procedures (per subsystem)
   6.4 IO Check Procedure (point-by-point verification)

7. Preventive Maintenance
   7.1 PM Schedule
   7.2 Spare Parts List (with B&R order codes)
   7.3 Calibration Procedures (analog inputs/outputs)
   7.4 Battery and Backup Replacement (retentive data — see [retentive-data.md](retentive-data.md))

8. Recovery and Disaster Procedures
   8.1 CF Card Backup and Restore
   8.2 PLC Replacement Procedure
   8.3 IO Module Replacement (hot-swap procedure)
   8.4 Firmware Recovery (see [bootloader-recovery.md](bootloader-recovery.md))
   8.5 Complete System Restore

9. Appendices
   A. Original Program Binary Backup Locations
   B. Automation Studio Connection Details
   C. Password and Access Level Documentation
   D. Revision History

6.2 Spare Parts List

For B&R X20 systems, create a spare parts list with exact order codes:

See io-card-hardware.md Section 8 for the complete X20 module reference.

6.3 IO Point-by-Point Verification Procedure

Include a repeatable IO verification checklist that can be used during commissioning, after module replacement, or during annual PM.

Template:

For each IO point:

1. Identify the physical device in the field.
2. Operate / simulate the device.
3. Verify the correct variable changes state in the Watch window.
4. Record PASS/FAIL and date.

This procedure validates that the IO map is correct and that all wiring is intact.

6.4 PLC Replacement Procedure

Document the exact steps to replace the CP1584 CPU, which is the most critical component:

1. Back up the current CF card contents via FTP (see ftp-web-interface.md).
2. Record the Automation Runtime version and all hardware module configurations.
3. Power down the machine following LOTO procedures.
4. Remove the old CPU from the DIN rail.
5. Install the replacement CPU (match firmware version — see firmware-version-mgmt.md).
6. Insert the CF card (or a pre-configured replacement).
7. Power up and verify the hardware tree matches the original configuration.
8. Verify all IO modules are recognized and communicating.
9. Run the IO point-by-point verification.
10. Cycle the machine and verify normal operation.

7. Tools and Techniques Summary

7.1 Software Tools

7.2 B&R-Specific Diagnostic Features

7.3 Physical Tools

8. Decision Matrix: Reconstruct vs. Rewrite

During documentation reconstruction, you may discover that the existing program has fundamental problems that make reconstruction impractical. Use this matrix to decide:

Hybrid approach (most common):

• Preserve the running binary as a backup.
• Document everything about the current system.
• Keep the existing program running while you develop a replacement.
• Cut over during a planned shutdown window.

9. Documentation Maintenance

The reconstructed documentation has a shelf life. Without active maintenance, it will become outdated as changes are made to the machine.

9.1 Revision Control

1. Store all documentation in a version-controlled repository (Git, SharePoint, or a document management system).
2. For every change to the machine (hardware or software), update the relevant documentation section.
3. Use a Document Revision Log:

9.2 Permanently Lost Information

Document what you could NOT recover, so future engineers know the gaps:

• Original source code (unless source was stored on target — see project-reconstruction.md Section 2)
• Programmer intent and design rationale
• Original naming conventions for undocumented variables
• Commissioning and calibration history
• OEM warranty and support contacts
• Safety certifications (CE, UL) documentation

10. Workflow Summary

The complete documentation reconstruction workflow, in recommended execution order:

Week 1: Preservation + Physical Inspection
  ├── 1.1 Image CF card, photograph everything
  ├── 1.2 Document safety systems and LOTO
  ├── 1.3 Inventory all panel components
  └── 1.4 Begin wire tracing (start with power)

Week 2: Network Discovery + Software Exploration
  ├── 2.1 Connect via Automation Studio, read hardware tree
  ├── 2.2 OPC-UA / PVI variable enumeration
  ├── 2.3 Export system dump, AR logs
  ├── 2.4 Network scan and topology mapping
  └── 2.5 Begin IO wiring matrix (continue wire tracing)

Week 3: IO Mapping from Observation
  ├── 3.1 Digital input actuation tests
  ├── 3.2 Digital output force tests (safe conditions only)
  ├── 3.3 Analog input calibration tests
  ├── 3.4 Analog output measurement
  └── 3.5 Complete IO wiring matrix

Week 4: Logic Documentation
  ├── 4.1 Machine sequence observation and recording
  ├── 4.2 Trace recording during operation
  ├── 4.3 State transition diagram construction
  ├── 4.4 Critical logic path tracing
  └── 4.5 Timing and sequencing documentation

Week 5: Manual Assembly
  ├── 5.1 Create wiring diagrams from wire trace data
  ├── 5.2 Compile IO map
  ├── 5.3 Write machine sequence documentation
  ├── 5.4 Assemble maintenance manual
  ├── 5.5 Create spare parts list and PM schedule
  └── 5.6 Review, peer check, and finalize

Community Tools for Accelerated Reconstruction

Several community tools significantly accelerate the documentation reconstruction process, especially when you lack the original Automation Studio project:

brwatch — Variable Discovery Without Project

brwatch is the fastest way to enumerate variables on an undocumented PLC. Install the Windows service, point it at the CP1584 IP, and browse the complete variable tree:

; brwatch.ini configuration
[Connection]
CPU=<PLC_IP_ADDRESS>
Protocol=ANSL

Reconstruction workflow with brwatch:

1. Browse the full variable tree and note all naming patterns (e.g., gMachineData.*, gAxis*.*, stState_*)
2. Export variable list with types (File > Save As > .bww)
3. Log all variables to CSV for a baseline snapshot
4. Observe which variables change during machine operation to identify active vs legacy code

This replaces the manual OPC-UA/PVI enumeration steps in Section 2 and produces a more complete variable list because brwatch requires no prior knowledge of the project structure. See access-recovery.md §12 for the full brwatch guide.

Pvi.py — Python Scripted Variable Extraction

Pvi.py enables scripted batch extraction of variable metadata:

from pvi import Pvi
import json

pvi = Pvi()
plc = pvi.line("ANSL", "TCP", "<PLC_IP>").device("CP1584")

variables = plc.list_variables()
with open("variable_inventory.json", "w") as f:
    json.dump([{"name": v.name, "type": v.type, "scope": v.scope} for v in variables], f, indent=2)
print(f"Extracted {len(variables)} variables")

systemdump.py — Automated System Dump Analysis

systemdump.py extracts hardware and task configuration from system dumps:

## Download system dump via SDM or FTP
## Then analyze:
systemdump --input SystemDump.xml --hardware > hw_inventory.txt
systemdump --input SystemDump.xml --tasks > task_config.txt

This provides the hardware tree and task configuration without requiring Automation Studio — directly useful for Sections 1.3 and 3.1 of this guide. See diagnostics-sdm.md for dump download and ebpf-telemetry.md for analysis workflows.

awesome-B-R — Complete Tool Catalog

The awesome-B-R repository is the master index of all community tools. For documentation reconstruction, the most useful categories are:

• Discovery tools: brwatch, brsnmp, ListAllBurPLCs
• Variable access: Pvi.py, demo-br-asyncua
• Analysis: systemdump.py, SystemDumpViewer
• Project migration: as6-migration-tools

Key Findings

1. B&R compiled binaries cannot be decompiled. The source code is permanently lost unless the OEM stored it on the target (check via File → Open Project From Target in Automation Studio). All program logic documentation must come from behavioral observation, not code reading.

2. The hardware tree is fully recoverable. B&R stores complete module configuration, serial numbers, firmware versions, and addressing in the running system. This gives you the software-side IO layout without any original files.

3. Variable names survive compilation. Even without source code, OPC-UA and PVI expose the full variable namespace with names, types, and values. This is the single most valuable extraction for IO mapping and logic documentation.

4. Wire tracing is the bottleneck. Physical wire tracing is the most labor-intensive part of documentation reconstruction and cannot be accelerated by software tools. Budget 40-60% of total project time for this phase.

5. Force-based logic tracing is viable but risky. Using Automation Studio’s Force function to drive inputs and observe outputs can reconstruct Boolean logic equations for critical paths, but must be done under controlled conditions with safety systems fully operational.

6. The Trace function is essential for timing documentation. Automation Studio’s Trace records variable changes at sub-millisecond resolution, enabling precise documentation of timers, sequencing delays, and watchdog timeouts that cannot be observed by eye.

7. CF card imaging is the first priority. The CF card may contain source code, configuration backups, AR logs, or HMI files. Image it immediately with dd before any other work — this single action may save weeks of reconstruction effort.

8. A hybrid approach is almost always correct. Do not attempt a full rewrite until you have fully documented the existing system. The existing running binary is the only reference for correct behavior.

9. Documentation maintenance is as important as initial creation. A one-time reconstruction effort produces a static document that decays with every unrecorded change. Establish a revision control process from day one.

10. The safety interlock table is the most critical deliverable. Understanding which safety devices protect which hazards is essential before any testing, forcing, or logic tracing can proceed. Always document safety systems first.

11. Community tools reduce reconstruction time by 50-70%. brwatch for instant variable enumeration, Pvi.py for scripted extraction, and systemdump.py for automated hardware inventory eliminate the most tedious manual steps. See access-recovery.md §12 and the awesome-B-R repository for the full tool catalog.

Sources

• B&R Automation Studio Online Help — Online monitoring, Trace, and Logger tools
• B&R Automation Runtime PVI Reference — variable namespace browsing and data extraction
• B&R OPC-UA Server Configuration Guide — namespace structure and variable access
• B&R Community Forum (community.br-automation.com) — practical discussions on undocumented system recovery
• IEC 61131-3 Programming Standard — IEC program structure and variable naming conventions
• ISA-95 (IEC 62264) — equipment hierarchy and documentation standards for manufacturing systems

Related Documents

• cp1584-forensics.md — Forensic information extraction methodology
• project-reconstruction.md — Building a new AS project from an unknown running PLC
• pvi-api.md — PVI API for programmatic variable access and extraction
• opcua.md — OPC-UA variable browsing for namespace documentation
• io-sniffing.md — Protocol analysis for IO behavior documentation
• cf-card-boot.md — CF card backup and file extraction for documentation
• access-recovery.md — brwatch and Pvi.py tools for variable enumeration and task discovery