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

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

Table of Contents

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

1. Theoretical Approaches to Intercept Fieldbus Traffic

1.1 B&R Protocol Stack Overview

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

1.2 X2X Link

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

Key characteristics:

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

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

1.3 ETHERNET Powerlink (EPL)

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

Frame types:

Key characteristics:

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

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

1.4 PROFINET IO

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

Key PROFINET protocols on the wire:

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

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

1.5 CANopen

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

Key characteristics:

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

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

2. Passive Tapping vs Active Sniffing

2.1 Passive Tapping

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

Advantages:

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

Disadvantages:

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

Passive tap types:

2.2 Active Sniffing

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

For Ethernet (POWERLINK/PROFINET):

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

Advantages:

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

Disadvantages:

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

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

2.3 Choosing Between Approaches

3. Hardware Requirements per Protocol

3.1 ETHERNET Powerlink

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

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

3.2 PROFINET IO

Switch port mirroring setup:

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

3.3 CANopen

3.4 X2X Link (Serial/RS-485)

Connection method for X2X with logic analyzer:

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

4. Wireshark Setup for POWERLINK and PROFINET

4.1 Wireshark for POWERLINK

Based on official B&R community documentation:

Step 1: Prepare the network interface

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

Step 2: Recommended NIC settings

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

Step 3: Connect to the POWERLINK network

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

Step 4: Start capture in Wireshark

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

Step 5: POWERLINK Display Filters

Step 6: Analysis tips

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

Limitations of PC-based capture:

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

4.2 Wireshark for PROFINET

Step 1: Install Wireshark

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

Step 2: Capture setup

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

Step 3: Connect to the PROFINET network

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

Step 4: PROFINET Display Filters

Step 5: Decoding cyclic I/O data

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

Step 6: Custom columns for PROFINET diagnostics

5. CAN Bus Sniffing Tools

5.1 Hardware Interfaces

PEAK PCAN (PEAK-System Technik GmbH)

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

Vector Informat

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

Kvaser

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

SocketCAN (Linux)

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

Other Tools

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

5.2 CANopen-Specific Analysis

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

TPDO/RPDO mapping (process data):

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

SDO access (configuration/diagnostics):

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

Emergency messages:

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

Heartbeat monitoring:

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

5.3 Practical CAN Sniffing Setup for B&R Systems

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

6. X2X Bus Sniffing with Logic Analyzers

6.1 Why Logic Analyzers for X2X

Since X2X Link is a closed proprietary protocol with no publicly available dissector, protocol-level decoding is not feasible with standard tools. Logic analyzers capture the raw digital waveform, allowing you to:

• Verify physical signal integrity (rise times, voltage levels, noise)
• Measure timing between transmissions
• Detect bus contention, framing errors, or signal degradation
• Capture long traces for intermittent fault correlation
• Observe the repeating cycle pattern to identify which time slots belong to which stations

6.2 Saleae Logic Analyzer

Supported models: Saleae Logic 8, Logic Pro 8, Logic Pro 16

Setup for X2X capture:

1. Connect the RS-485 differential pair (X2L+/X2L-) through an RS-485-to-TTL level shifter (MAX485 or SP3485)
   • X2L+ (A line) -> Logic channel 0
   • X2L- (B line) -> Logic channel 1
   • Optionally: GND -> Logic GND, and the TX/RX enable lines if probing the transceiver IC directly
2. Set sample rate: Minimum 10x the baud rate. For 12 Mbaud X2X, use 120+ MHz (Logic Pro 16 supports up to 500 MS/s)
3. Set sample duration: Capture at least 10 full bus cycles to see repeating patterns
4. In Saleae Logic 2 software:
   • Add Async Serial analyzer for each channel
   • Set baud rate to match (try 12M, 6M, 3M, 1.5M - B&R uses power-of-2 divisions of 12M)
   • Add I2C/SPI analyzer if the X2X uses a chip-select or clock line visible on the bus connector
5. Export data to CSV for analysis in spreadsheets or Python scripts

Limitations:

• Buffer depth limits long-term monitoring (use high-performance models with 2GB+ capture)
• Cannot decode proprietary protocol semantics
• TTL input range (must use level shifter for RS-485)

6.3 Sigrok / PulseView (Open Source)

Supported hardware: Any sigrok-compatible logic analyzer (DreamSourceLab, Clone, Sipeed, or even an Arduino with sigrok firmware)

Protocol decoders available in sigrok (relevant for X2X analysis):

• UART (Async Serial) - 131+ total decoders supported
• CAN (Controller Area Network) - for CAN bus analysis
• I2C, SPI - for sub-protocols or chip-level probing
• Modbus RTU - over RS-485 UART
• Jitter, Timing - for timing analysis between signals

Setup for X2X with sigrok:

1. Install sigrok and PulseView: apt install sigrok pulseview (Debian/Ubuntu)
2. Connect RS-485 through level shifter to logic analyzer channels
3. Run sigrok-cli for command-line capture:

   sigrok-cli --driver dreamsourcecli --config samplerate=120M --channels 0,1 \
     --protocol-decoder uart:baudrate=12000000:rx=0 --protocol-decoder uart:baudrate=12000000:rx=1 \
     -o x2x_capture.sr
   

4. Analyze in PulseView or export with sigrok-cli -i x2x_capture.sr -P uart:csv
5. Write custom Python protocol decoder using libsigrokdecode API for X2X-specific analysis

Advantages of sigrok:

• Free and open source
• Supports 131+ protocol decoders
• Works with cheap logic analyzer hardware ($10-50)
• CLI interface for automated/scripted capture
• Extensible: write custom decoders in Python for proprietary protocols

6.4 Oscilloscope as Complement

Use a 4-channel oscilloscope for X2X physical-layer analysis:

• Channel 1: X2L+ (A line)
• Channel 2: X2L- (B line)
• Channel 3: X2L+ - X2L- (differential, math function)
• Channel 4: Ground reference or another signal

What to look for:

• Differential voltage swing (should be >1.5V for RS-485)
• Signal rise/fall times (degradation indicates cable or connector issues)
• Noise, ringing, reflections on the bus
• Common-mode voltage (should stay within RS-485 receiver range: -7V to +12V)

7. Correlating Captured Data with IO Module Addresses

7.1 Understanding B&R IO Address Mapping

B&R Automation Studio assigns addresses to IO modules based on their physical position in the station:

X20 System addressing:

Bus Controller (X20BCxxxx)
  ├── Slot 1: X20DI9371 (Digital Input 16ch) → %IX0.0.0 - %IX0.0.15
  ├── Slot 2: X20AI4631 (Analog Input 4ch)  → %IW4 (words 4-7)
  ├── Slot 3: X20AO4621 (Analog Output 4ch) → %QW8 (words 8-11)
  └── Slot 4: X20DO9321 (Digital Output 16ch) → %QX0.0.0 - %QX0.0.15

The %I/%Q prefix indicates input/output, %X = bit, %W = word (16-bit), %B = byte.

7.2 Correlating by Protocol

For POWERLINK:

• Each CN (Controlled Node) has a NodeID (configured in Automation Studio)
• The PRes frame from a CN contains the process image for that station
• Within the PRes payload, the byte order matches the slot order configured in the hardware tree
• To find a specific sensor: look up its NodeID, find its PRes frames, and calculate the byte offset based on slot position and data type

For PROFINET:

• Wireshark decodes cyclic data to slot/subslot level (if connection setup was captured)
• You’ll see: Module: DI 8x24V (Slot 1, Subslot 1) → Input Data: 0xFF
• Use pn_io.slot_nr and pn_io.subslot_nr filters to isolate specific IO modules
• The AR (Application Relation) and CR (Connection Record) in the connection setup define the mapping

For CANopen:

• CANopen PDOs map to object dictionary entries (index/subindex)
• The PDO mapping (OD index 0x1A00 for TPDO, 0x1600 for RPDO) defines the byte layout
• Each sensor channel maps to a specific object in the OD
• Example: Object 0x6401 (analog input ch1) maps to TPDO1 byte [0:1]
• Load the device’s EDS/EDD file in CANalyzer to see the full mapping

7.3 Practical Correlation Workflow

1. Build an address map: In Automation Studio, export or document the IO configuration for each station:

   • Station name/NodeID
   • Slot position → module type → variable name → address
   • Data type and byte width per channel

2. Identify the failing channel: Use B&R’s mapp Diagnostic or the Automation Studio watch window to determine which variable/address is showing unexpected values.

3. Locate in the capture:

   • POWERLINK: Filter by epl.src == <NodeID> for the failing station, then examine the PRes payload at the byte offset corresponding to the failing channel
   • PROFINET: Filter by pn_io.slot_nr == <slot> and pn_io.subslot_nr == <subslot>
   • CANopen: Calculate the CAN ID for the failing node’s TPDO/RPDO, filter for that ID, and examine the relevant bytes

4. Verify the data path: Trace the data from the capture back to the IO module’s physical terminal to confirm the channel-to-address mapping.

8. Filtering Techniques to Isolate Sensor Data

8.1 Wireshark Filtering for Ethernet Protocols

POWERLINK - isolate a specific station:

epl.src == 5 && epl.service_type == "PRes"

Shows only Poll Response frames from NodeID 5 (this station’s process data).

POWERLINK - isolate async communication:

epl.service_type == "ASnd"

Async frames carry diagnostics, configuration, and error messages.

PROFINET - isolate a device by MAC:

eth.addr == 00:0e:8c:12:34:56 && pn_rt

All cyclic RT traffic for a specific IO device.

PROFINET - isolate bad data:

pn_rt.data_status.datavalid == 0

Shows only frames where the device reports data as invalid.

PROFINET - isolate alarms:

pn_io.alarm_type

All alarm notifications (plug/pull, diagnosis, process alarms).

8.2 SocketCAN Filtering for CANopen

Capture only from a specific node:

candump can0,185:7FF

(Capture CAN ID 0x185 = TPDO1 of NodeID 5, mask 0x7FF = match all 11 bits)

Capture emergency messages only:

candump can0,080:7FF

(All emergency messages from any node)

Capture with CANopen decode (cansniffer):

cansniffer can0

Shows a live matrix view of all CAN IDs with data bytes, updated in real-time.

Python filtering with python-can:

import can
bus = can.Bus(interface='socketcan', channel='can0', bitrate=500000)
for msg in bus:
    if msg.arbitration_id == 0x185:  # TPDO1 from NodeID 5
        temp_raw = int.from_bytes(msg.data[0:2], 'little')
        temp_c = temp_raw / 10.0
        print(f"Temperature: {temp_c}°C")

8.3 Logic Analyzer Filtering for X2X

In Saleae Logic 2:

• Time range selection: Highlight a section of the capture to zoom in
• Search: Search for specific byte patterns or transitions
• Export selection: Export only the selected time range to CSV

In sigrok-cli:

sigrok-cli -i capture.sr -P uart:min_tx_len=1 -A uart=rx-0:rx-1 | grep "temperature"

Pipe the decoded output through grep/awk for pattern matching.

8.4 Triggered Capture

For isolating specific events in high-traffic networks:

Wireshark capture filters:

ether proto 0x8892 and ether[0] & 1 = 0

Only unicast PROFINET frames (filter out multicast).

Wireshark stop conditions:

• Capture -> Stop Conditions -> “After X packets” or “After X seconds”
• Useful for capturing exactly one POWERLINK cycle or a specific number of PROFINET RT frames

Hardware trigger (X20ET8819):

• Configure a digital input trigger to start recording when a physical event occurs
• Use filter expressions to pre-select which frames to store
• Essential for capturing sporadic intermittent faults that may not occur during a manual observation window

9. Timing Analysis for Intermittent Communication Issues

9.1 Common Intermittent Fault Patterns

9.2 Wireshark Timing Analysis

POWERLINK cycle time analysis:

1. Filter for SoC (Start of Cycle) frames: epl.service_type == "SoC"
2. Add column: frame.time_delta_displayed (delta from previous frame)
3. Sort by time and examine the delta column
4. Healthy: consistent delta matching the configured cycle time (e.g., 1.000ms +/- 0.01ms)
5. Faulty: delta spikes, missed cycles, or irregular intervals

PROFINET cycle analysis:

1. Filter: pn_rt
2. Add column: pn_rt.cycle_counter
3. If CycleCounter has gaps (e.g., 12340, 12341, 12343 - missed 12342), frames were lost
4. Add column: frame.time_delta_displayed
5. Build a histogram: Statistics -> Capture File Properties -> “Create Stat” or use Expert Info

PROFINET data validity analysis:

1. Filter: pn_rt.data_status.datavalid == 0
2. If this returns frames, the IO device is reporting invalid data
3. Cross-reference with pn_io.alarm_type for diagnostic alarms
4. Check timing: does DataValid go to 0 at the same time as alarms? (indicates sensor failure)
5. Does DataValid go to 0 without alarms? (indicates communication issue)

9.3 CAN Bus Error Analysis

CAN error types and what they mean:

Detection with CAN tools:

• PCAN-View: Shows error frames, TX/RX error counters, bus state
• CANalyzer: Error frame analysis, bus load measurement, error statistics
• SocketCAN: ip -details -statistics link show can0 shows error counters
• candump can0 -e includes error frames in the capture

Intermittent CAN fault diagnostic workflow:

1. Monitor the TX error counter (TEC) and RX error counter (REC) over time
2. If TEC increases sporadically but recovers: intermittent cable issue
3. If REC increases: bus-level noise or another node transmitting errors
4. If both TEC and REC increase together with error frames: EMI or ground loop
5. If counters go to bus-off: persistent fault - check termination, cable, and connectors
6. Use an oscilloscope on CAN_H and CAN_L to check signal quality during the fault

9.4 X2X Timing Analysis

With a logic analyzer:

1. Capture a long trace (several minutes) during normal operation to establish baseline
2. Measure the time between recurring patterns (each station’s transmission time slot)
3. Set a trigger on the “unexpected” pattern: e.g., a frame that appears only during the fault
4. Compare signal integrity during normal operation vs. during the fault
5. Check for: jitter in frame timing, changes in frame length, missing responses, or signal quality degradation

9.5 Statistical Analysis Methods

Wireshark IO Graphs:

• Statistics -> IO Graph: Plot packet rate, bytes/frame, or custom field values over time
• Useful for visualizing periodic behavior and spotting anomalies

Wireshark Expert Info:

• Analyze -> Expert Info: Shows warnings and notes about unusual patterns
• Detects: retransmissions, duplicate ACKs, out-of-order frames, protocol violations

Custom Python analysis:

import scapy.all as scapy
packets = scapy.rdpcap('capture.pcap')
deltas = [packets[i+1].time - packets[i].time for i in range(len(packets)-1)]
import statistics
print(f"Mean cycle: {statistics.mean(deltas)*1000:.3f} ms")
print(f"Std dev: {statistics.stdev(deltas)*1000:.3f} ms")
print(f"Min: {min(deltas)*1000:.3f} ms, Max: {max(deltas)*1000:.3f} ms")

10. Practical Diagnostic Workflows

10.1 Workflow 1: POWERLINK Sensor Reading Intermittently Wrong

Scenario: An analog input sensor on an X20 AI module occasionally reads zero or max value.

Steps:

1. Confirm the symptom in Automation Studio: Watch the variable over time using the watch window or mapp Trend
2. Identify the station: Note the NodeID and slot position of the failing module
3. Set up Wireshark capture:
   • Connect PC to POWERLINK network via hub
   • Disable TCP/IP on the capture interface
   • Set NIC to half-duplex, 100 Mbps
4. Filter for the failing station:
   • epl.src == <NodeID> && epl.service_type == "PRes"
   • Add a PRes-Payload column
5. Compare good vs bad readings:
   • Identify the byte offset of the failing channel in the PRes payload
   • Correlate with the known sensor address mapping
6. Check for POWERLINK errors:
   • Look for ASnd frames with error indications
   • Check if other stations are affected
7. Physical checks:
   • Inspect wiring from sensor to AI module terminals
   • Check shield/ground connections
   • Verify sensor power supply
8. Advanced: If the fault is timing-related, switch to X20ET8819 for nanosecond-precision capture with hardware trigger

10.2 Workflow 2: PROFINET IO Device Randomly Dropping Offline

Scenario: A PROFINET IO device intermittently shows “Not Found” or drops out of data exchange.

Steps:

1. Set up capture with SPAN/tap:
   • Configure managed switch: mirror the port connected to the failing IO device
   • Connect PC to mirror port, start Wireshark
   • Critical: Start capture before the device connects to capture the connection setup
2. Monitor normal operation:
   • Verify cyclic RT frames are arriving regularly: pn_rt && eth.addr == <device MAC>
   • Check CycleCounter is incrementing without gaps
   • Verify DataValid = 1
3. Capture the failure event:
   • Let the capture run until the device drops out
   • Look for the last cyclic frame before the dropout
4. Analyze the failure:
   • If cyclic frames stop abruptly with no alarms: cable or power failure
   • If DataValid goes to 0 before dropout: sensor/module error
   • If DCP re-discovery occurs: device rebooted or was reconnected
   • If ARP/LLDP stops: physical link went down
5. Check alarms before dropout:
   • pn_io.alarm_type - look for Pull, Diagnosis, or Status alarms
6. Root cause:
   • Physical layer: cable, connector, switch port
   • Power: check device power supply
   • Configuration: verify GSDML version, module configuration match
   • Network: check for overloaded switch, VLAN issues

10.3 Workflow 3: CANopen Sensor Sporadically Not Updating

Scenario: A CANopen analog sensor module occasionally stops sending updated values.

Steps:

1. Identify the node’s CAN ID: Calculate from the PDO mapping (default TPDO1 = 0x180 + NodeID)
2. Set up CAN capture:
   • Connect CAN adapter to bus via Y-tap
   • Configure matching baud rate
   • Start capture
3. Monitor PDO traffic:
   • Filter for the node’s TPDO CAN ID
   • Watch the data bytes for the sensor value
4. Check for errors:
   • Look for emergency messages (CAN ID 0x080 + NodeID)
   • Check heartbeat messages (0x700 + NodeID) - are they still arriving?
   • Monitor bus error counters: ip -s link show can0
5. SDO read diagnostic objects:
   • Use CANalyzer or python-can to send SDO read requests to diagnostic objects
   • Read OD index 0x1001 (Error Register) and 0x10FD (Error History)
6. Physical layer:
   • Measure CAN_H and CAN_L voltages with a multimeter (recessive: ~2.5V, dominant: ~3.5V/1.5V)
   • Verify 120-ohm termination at both bus ends
   • Check cable shielding and ground

10.4 Workflow 4: X2X Bus Communication Errors (General)

Scenario: Random communication errors on the X2X bus causing IO modules to show diagnostic LEDs.

Steps:

1. Check B&R diagnostics first:
   • Use Automation Studio: System Diagnostics -> IO Diagnostics
   • Identify which stations and modules are affected
2. Set up logic analyzer:
   • Connect RS-485 level shifter to X2L+/X2L- wires
   • Set sample rate to 10x bus speed (120 MHz for 12 Mbaud)
   • Capture for a long duration to catch the intermittent event
3. Analyze signal integrity:
   • Check differential voltage levels
   • Look for signal ringing, reflections, or noise
   • Compare with known-good reference capture
4. Check physical layer:
   • Verify bus termination at both ends
   • Inspect connectors for corrosion or loose contacts
   • Check cable length (X2X has maximum segment length limits)
   • Verify shield grounding
5. Bus utilization:
   • Measure the percentage of time the bus is active vs. idle
   • High utilization can cause timing margin issues
   • Reduce cycle time or station count if overloaded
6. Replace/swap:
   • Swap the bus controller to rule out a failing transceiver
   • Swap individual IO modules to isolate the failing node

11. Legal and Safety Considerations

11.1 Authorization and Access Control

• Only authorized personnel should perform network sniffing on industrial control systems
• Obtain written permission from the plant/facility management before installing any monitoring equipment
• Follow the organization’s IT/OT security policies and change management procedures
• Document all monitoring activities, including what was captured, when, and by whom

11.2 Impact on Production Systems

• Passive tapping is the safest method as it introduces zero risk to the live system
• Active sniffing (connecting a PC to the network) carries risks:
  • Accidentally sending packets that disrupt real-time communication
  • PC NIC flooding the bus with unwanted traffic (ARP, DHCP, IPv6)
  • Network card driver issues causing packet storms
• Always disable TCP/IP and other network services on the capture interface before connecting
• Test any monitoring setup during a planned shutdown before deploying on live systems
• Use a dedicated, isolated capture machine (never a production PC)

11.3 Data Privacy and Security

• Captured fieldbus traffic may contain sensitive production data (recipes, process parameters, proprietary configurations)
• pcap files should be treated as confidential data and stored securely
• Do not share capture files outside the organization without proper authorization
• Delete captures after the diagnostic issue is resolved (unless required for compliance)
• Captured data may contain safety-related information - handle with appropriate care
• Some industrial protocols transmit passwords or configuration data in plaintext

11.4 Regulatory Compliance

11.5 Safety-Critical Systems

• Never install monitoring equipment on safety-rated fieldbus segments (e.g., PROFIsafe, openSAFETY, CIP Safety) without:
  • Manufacturer approval
  • Safety engineer sign-off
  • Formal risk assessment
  • SIL/PLD verification that monitoring does not compromise safety functions
• Passive taps are generally acceptable on safety networks as they don’t modify traffic
• Active devices (even in promiscuous mode) must be certified for use in safety networks

11.6 Liability

• Monitoring equipment installed on industrial networks becomes part of the safety chain
• If monitoring equipment fails and causes an incident, the installer may be liable
• Always follow manufacturer guidelines for network monitoring
• Use only approved and tested monitoring hardware
• Maintain records of all monitoring installations and configurations

12. Tools Comparison Table

12.1 Ethernet Protocol Analysis Tools

12.2 CAN Bus Analysis Tools

12.3 Logic Analyzers for X2X/Serial

12.4 Ethernet Tap Hardware

12.5 Comprehensive Capability Matrix

Legend: Free = $0, $ = <$100, $$ = $100-500, $$$ = $500-2,000, $$$$ = >$2,000

13. Sources and References

Official Documentation

• B&R Community: “Diagnosis of POWERLINK networks using Wireshark” https://community.br-automation.com/t/diagnosis-of-powerlink-networks-using-wireshark/3648
• B&R Automation: POWERLINK in detail https://www.br-automation.com/en/technologies/powerlink/technology/powerlink-in-detail/
• B&R Automation: X20ET8819 Ethernet Analysis Tool https://www.br-automation.com/en/products/io-systems/x20-system/x20-hub-system/x20et8819/
• B&R Automation: POWERLINK Configuration and Diagnostics (TM950TRE.40) http://www.ftp.boss-bravo.fr/wiki/pdf/TM_BR/TM950TRE.40-ENG_POWERLINK%2520Configuration%2520and%2520Diagnostics_V4000.pdf

Wireshark and Protocol References

• SCADA Protocols: “Wireshark for PROFINET: How to Capture and Decode RT, DCP, and IO Traffic” https://scadaprotocols.com/wireshark-profinet-decode-rt-dcp-guide/
• Wireshark Wiki: PROFINET/RT https://wiki.wireshark.org/PROFINET/RT
• Wireshark Wiki: PROFINET/DCP https://wiki.wireshark.org/PROFINET/DCP
• Wireshark Wiki: PROFINET/IO https://wiki.wireshark.org/PROFINET/IO
• Felser Engineering: PROFINET Manual - Wireshark https://www.felser.ch/profinet-manual/wireshark.html
• Felser Engineering: Port Mirroring - PROFINET Manual https://www.felser.ch/profinet-manual/pn_port-mirroring.html
• EPL-Viz: POWERLINK visualization https://epl-viz.github.io/

CAN Bus and CANopen

• CSS Electronics: “CANopen Explained - A Simple Intro” https://www.csselectronics.com/pages/canopen-tutorial-simple-intro
• CSS Electronics: “CAN Bus Errors Explained” https://www.csselectronics.com/pages/can-bus-errors-intro-tutorial
• Analog Devices: “How to map objects to a PDO on a CANopen slave” (AN-076) https://www.analog.com/cn/resources/app-notes/an-076.html
• NI: “The Basics of CANopen” https://www.ni.com/en/shop/seamlessly-connect-to-third-party-devices-and-supervisory-system/the-basics-of-canopen.html
• Grid Connect: “CAN Bus Diagnostics: Step-by-Step Guide” https://www.gridconnect.com/blogs/news/how-to-diagnose-a-controller-area-network-can
• EEVblog: “Kvaser or Peak CAN bus adapters for CAN Open” https://www.eevblog.com/forum/chat/kvaser-or-peak-can-bus-adapters-for-can-open/
• RPubs: “CAN Tool Comparison (Vector vs PEAK)” https://rpubs.com/daniel_pas/can_tool_comparison
• GitHub: “Awesome CAN bus tools, hardware and resources” https://github.com/ajouatom/canbus-tools
• CAN Wiki: “CAN analyzers” http://www.can-wiki.info/doku.php?id=testequipment:cananalyzers

Hardware and Sniffing Tools

• Hilscher: “Sniffing Tool” (glossary/overview) https://www.hilscher.com/service-support/glossary/sniffing-tool
• Sigrok: “Protocol decoders” (131+ decoders) http://sigrok.org/wiki/Protocol_decoders
• Vector: CANalyzer.CANopen product page https://www.vector.com/int/en/products/products-a-z/software/canalyzer/option-canopen/
• PEAK-System: PCAN-View product page https://www.peak-system.com/products/software/analysis-software/pcan-view/
• ControlTech: “Vector CANalyzer Alternative: PEAK PCAN-Explorer 6” https://controltechuk.com/blog/vector-canalyzer-alternative/
• Atomic Object: “Affordable CAN Bus Tools that Won’t Break the Bank” https://spin.atomicobject.com/affordable-can-bus-tools/
• CanLover: Free CAN analyzer alternative https://canlover.ddns.net/

Network Tapping and Monitoring

• Garland Technology: “Network TAPs” https://www.garlandtechnology.com/network-tap
• Gigamon: “Understanding Network TAPs” https://www.gigamon.com/resources/resource-library/white-paper/understanding-network-taps-first-step-to-visibility.html
• Network Critical: “Top 8 Network TAPs for Passive Network Monitoring in 2026” https://www.networkcritical.com/blogs/top-8-network-taps-for-passive-network-monitoring
• Industrial Monitor Direct: “Capturing EtherNet/IP I/O Traffic: Network Taps vs Switch Port Mirroring” https://industrialmonitordirect.com/blogs/knowledgebase/capturing-ethernetip-io-traffic-with-wireshark-network-taps-vs-switch-port-mirroring
• Siemens Industry Support: “Network capture with Wireshark and Port Mirroring using SCALANCE X” https://support.industry.siemens.com/cs/document/109976057

B&R X2X and IO Systems

• B&R Automation: X20 System User’s Manual https://www.phb-electricite.fr/content/doc/br_automation/x20_system_manual.pdf
• Reddit r/PLC: “B&R X2X Link network troubleshooting” https://www.reddit.com/r/PLC/comments/p73low/br_x2x_link_network_troubleshooting/
• B&R Automation: X20BC0063 (X2X to PROFIBUS DP bus controller) https://www.br-automation.com/en/products/io-systems/x20-system/bus-controllers/x20bc0063/

Industrial Ethernet Switches

• Bihl+Wiedemann: “POWERLINK Fieldbus system” https://www.bihl-wiedemann.de/en/company/technological-foundations/bus-systems/powerlink

Academic and Research

• ResearchGate: “Attacking Fieldbus Communications in ICS: Applications to the SWaT Testbed” https://www.researchgate.net/publication/292612170_Attacking_Fieldbus_Communications_in_ICS_Applications_to_the_SWaT_Testbed
• ResearchInventy: “A Comprehensive Study of Cybersecurity in Fieldbus Protocols” http://www.researchinventy.com/papers/v15i9/15092732.pdf

Cross-References

• physical-layer-sniffing.md – physical wire-level signal analysis for fieldbus cables
• powerlink-internals.md – POWERLINK protocol internals and Wireshark capture
• x2x-protocol.md – X2X bus protocol wire-level details
• if2772-canopen.md – CAN bus protocol and CANopen analysis
• cp1584-forensics.md – extracting information from unknown CP1584 systems
• io-card-hardware.md – IO module hardware architecture and signal paths
• grounding-emc.md – grounding and EMC troubleshooting for signal integrity
• diagnostic-workstation.md – protocol analyzer and sniffer hardware recommendations
• network-architecture.md – B&R network topology and device enumeration

Document generated July 2026. Verify all URLs and tool versions before use. Industrial network sniffing should only be performed by qualified personnel following organizational safety and security policies.

Key Findings

1. Wireshark with the POWERLINK plugin is the most accessible sniffing tool — it captures EPL traffic from any PC with a supported NIC in promiscuous mode. No expensive hardware required for basic POWERLINK diagnostics.
2. X2X bus sniffing requires a logic analyzer — the proprietary protocol has no Wireshark decoder. A Saleae or Sigrok-compatible analyzer with ground clips on the X2X link connector is needed. See x2x-protocol.md for frame format details.
3. CAN bus sniffing with PCAN or Vector tools is well-supported — the CANopen protocol on the B&R IF2772 is standard CiA 301, making commercial CAN analyzers fully capable. PDO/SDO mapping can be decoded with standard tools.
4. Network tap placement matters — for POWERLINK, tap at the switch mirror port (not inline) to avoid timing disruption. For X2X, probe the backplane connector pins directly with the logic analyzer ground clips.
5. Sniffing without disrupting production is the primary challenge — always use non-invasive methods (mirror ports, clamp-on current probes) on running machines. Reserve invasive probing for shutdown windows.
6. The most common sniffing use case for undocumented machines is identifying which IO channel is failing — correlate captured sensor data with the IO module’s channel assignment to pinpoint the exact failing channel without any documentation.