Layering of PLC Protocols: Analyzing the Communication Protocol Stack Structure for a Deeper Understanding of Data Exchange Mechanisms!

Introduction

**Hello everyone!** Today we are going to discuss a topic that makes PLC communication transparent—the layering of PLC protocols. Don’t be intimidated by this technical term, I will guide you through the mysteries of this “communication protocol stack” in the most relatable way. Imagine if you could understand the data exchange mechanism of PLCs layer by layer, just like peeling an onion, you would be able to pinpoint issues accurately when debugging communication faults, significantly improving efficiency! **Are you ready?** Let’s embark on this layered exploration journey!

Why Layer Protocols?

Let me start with a real-life example: When sending a package via courier, you need to fill in the address (Application Layer), pack the box (Presentation Layer), choose a logistics company (Transport Layer), plan the route (Network Layer), and finally transport it by truck (Physical Layer). PLC communication is similar—layered design simplifies complex problems, with each layer focusing on solving a specific type of issue, ultimately achieving efficient and reliable data transmission.

<span>Highlighted in red</span>:<span>The core advantages of protocol layering</span>

• Modular Design: A fault in one layer does not affect others (for example, changing a network cable does not require program modifications)

• Standardized Interfaces: Devices from different manufacturers can communicate as long as they adhere to the same protocol stack

• Transparent Debugging: Communication faults can be diagnosed layer by layer, eliminating the “blind men touching an elephant” scenario

The 7-Layer and 4-Layer Models of PLC Protocols

1. OSI Seven-Layer Model (Theoretical Framework)

Although actual PLC communication rarely fully implements all 7 layers, understanding it is very important:

| Layer | Function | PLC Corresponding Implementation |

|——|——|————-|

| Application Layer | User-visible functions (e.g., reading and writing variables) | <span>S7 communication service, Modbus function codes</span> |

| Presentation Layer | Data format conversion (e.g., byte order processing) | <span>PLC variable packing/unpacking</span> |

| Session Layer | Establishing/maintaining communication sessions | <span>TCP three-way handshake</span> |

| Transport Layer | End-to-end reliable transmission | <span>TCP/UDP protocols</span> |

| Network Layer | Routing and addressing | <span>IP address allocation</span> |

| Data Link Layer | Frame checking/physical addressing | <span>MAC address, Profibus-DP</span> |

| Physical Layer | Bit stream transmission | <span>RS485, fiber optic interface</span> |

2. 4-Layer Simplified Model in Actual PLCs

<span>Highlighted in blue</span>:<span>More common implementation in industrial settings</span>

• Application Layer:<span>Modbus RTU messages</span>, <span>Profinet IO-CM</span>

• Transport Layer:<span>TCP/UDP port management</span>

• Network Layer:<span>IP address allocation (e.g., 192.168.1.10)</span>

• Physical Layer:<span>RJ45 network port, RS485 terminal</span>

In-Depth Analysis of Key Layers

▶ Physical Layer: The “Highway” of Communication

• Typical Media: Twisted pair (CAT5e), fiber optic (anti-interference), wireless (5G)

• Core Parameters: Baud rate (e.g., 19.2kbps), signal levels (RS232 at ±15V)

<span>Red Alert</span>:<span>Poor grounding leading to common-mode interference is the most common fault in the physical layer!</span>

▶ Data Link Layer: The “Traffic Police” of Frames

• Frame Structure Example (Modbus RTU):

  [Address][Function Code][Data][CRC Check]

• Key Mechanisms:

• Collision Detection: CSMA/CD (Ethernet)

• Master-Slave Polling: Token ring mechanism of Profibus-DP

▶ Application Layer: The Engineer’s “User Interface”

• Siemens S7 Protocol:

  # Typical request message for reading DB block data
  TPKT+COTP+ISO-TSAP+S7-ReadDB(DB number, offset, length)

• Modbus Function Codes:

  <span>01</span> Read Coil <span>04</span> Read Input Register <span>16</span> Write Multiple Registers

Practical Case Studies of Protocol Layering

Case 1:Cross-Brand PLC Communication (Siemens ↔ Mitsubishi)

1. Physical Layer: Interconnected via Ethernet switch

2. Network Layer: Configure IPs in the same subnet (e.g., 192.168.1.10/192.168.1.20)

3. Transport Layer: Open TCP port 502 (standard port for Modbus TCP)

4. Application Layer: Siemens side calls<span>TCON/TUSEND/TURCV</span> instructions, Mitsubishi side uses<span>MC Protocol</span>

Case 2:Adding a Profibus-DP Slave

1. Physical Layer: Connect purple cable, set terminal resistor to ON

2. Data Link Layer: Configure station address (e.g., 3#) and baud rate (1.5Mbps)

3. Application Layer: Master imports GSD file, maps I/O data

Recommended Protocol Analysis Tools

<span>Highlighted in blue</span>:

1. Wireshark: Capture Ethernet packets (filter<span>s7comm</span><code><span> to analyze Siemens protocols)</span>

2. Modbus Poll: Simulate Modbus master-slave communication

3. PRONETA (Siemens): Profinet network topology scanning

4. Serial Assistant: Debug RS485 data link layer packets

Pitfall Guide

1. Layer Confusion Errors:

• ❌ Using IP address to solve Modbus function code errors (this is an application layer issue)

• ✅ Correct approach: Check function code and register address mapping

Communication failure → Physical Layer? → Test line continuity

        → Network Layer? → Ping test

        → Application Layer? → Packet capture analysis

Interactive Questions

1. What is the most difficult layer-level issue you have encountered while debugging PLC communication?

2. What protocol analysis tools do you commonly use? Any tips for usage?

3. How do you achieve interconnection for devices that do not support standard protocols?

Conclusion

Protocol layering is like an “X-ray” of PLC communication, mastering it allows you to upgrade from “guessing faults based on experience” to “precisely locating issues”. Remember: When communication is abnormal, start troubleshooting from the physical layer upwards, which often yields better results with less effort. I hope this analysis can serve as your “navigation tool” on the road to protocol analysis! If you have any questions or practical experiences, feel free to share and discuss in the comments!

<span>Highlighted in red</span>:<span>Next time we will delve into "how to solve S7 communication timeout issues through message analysis"</span>, stay tuned!

ShareSaveViewLike