Architectural Design: How to Plan Siemens PLC Program Structure? A Three-Tier Architecture for Clear and Maintainable Code!

Hello everyone! In my years of experience in automation projects, I have found that many engineers write PLC programs like a “running account”—writing a segment for each requirement and adding a block for each new device. As a result, after six months, they can’t even understand the code they wrote! Today, I would like to share a Siemens PLC “three-tier architecture” program structure that I often use, making your code not only easy to write but also easier to modify and maintain, so your boss no longer has to worry about no one being able to take over your program when you are on leave!

What is the PLC Three-Tier Architecture?

In simple terms, the three-tier architecture divides the PLC program into three levels:

Bottom Layer: I/O Processing Layer – Responsible for processing all input and output signals
Middle Layer: Functional Logic Layer – Contains the implementation of various functional modules
Top Layer: Management Coordination Layer – Responsible for overall process and mode control

What are the benefits of this division? It’s like renovating a house, where the plumbing and electrical (bottom layer), walls (middle layer), and decoration (top layer) are done separately, without interference, making it easier to locate problems.

How to Implement the Bottom Layer: I/O Processing Layer?

The bottom layer mainly accomplishes two tasks: input signal acquisition and processing and unified management of output signals.

For specific implementation, I generally create two function blocks (FB):

FB10: Input_Process  // Input Processing
FB11: Output_Control // Output Control

In the input processing FB, I will do the following:– Collect and filter physical input points– Edge detection of signals (rising edge/falling edge)– Analog conversion and calibration

Note: Don’t set the filtering time too long! I once set a filtering time of 500ms, and as a result, high-speed pulse signals were completely filtered out, and the device couldn’t start at all. It took me a whole day to find the problem.

How to Organize the Middle Layer: Functional Logic Layer?

The middle layer is the most “substantial” layer, containing various functional modules. My approach is to divide FBs by functional units, for example:

FB20: Motor_Control  // Motor Control
FB21: Valve_Control  // Valve Control  
FB22: Heater_Control // Heating Control
FB30: Auto_Sequence  // Automatic Running Sequence
FB31: Manual_Control // Manual Control Function

Within each functional FB, I prefer to organize the code using a state machine (CASE statement):

CASE #StateOF
0: // Initial State
IF #Start THEN
#State := 10;
END_IF;
10: // Running State
// Functional Code
IF #Complete THEN
#State := 20;
END_IF;
20: // Completion State
// Completion Processing
END_CASE;

Key Point: The functional logic layer only operates on intermediate variables and does not directly control physical I/O points! This allows for easy simulation testing and greatly improves debugging efficiency.

What is the Purpose of the Top Layer: Management Coordination Layer?

The top layer is the “brain” of the entire program, responsible for:– Switching operating modes (manual/automatic/setup)– Overall process coordination– Exception handling and safety monitoring

I generally use OB1 or FC1 as the main calling block to coordinate everything here:

// First call the bottom layer
CALL "Input_Process"
// Call different functions based on the operating mode
IF "Auto_Mode" THEN
CALL "Auto_Sequence"
ELSIF "Manual_Mode" THEN
CALL "Manual_Control"
END_IF
// Finally call output control
CALL "Output_Control"

It is essential to ensure that Input_Process and Output_Control are called in every scan cycle, otherwise it may lead to interruptions in input signal acquisition or instability in output signals!

How to Design Data Structures?

A good architecture relies on good data organization. I generally create global DB blocks:

DB10: IO_Data        // I/O Mapping Data
DB20: System_Param   // System Parameters
DB30: Runtime_Data   // Runtime Data

Organizing related data together and using UDT (User Defined Data Types) for structuring, for example, motor data can be defined as:

UDT "Motor"
    Enable: Bool     // Enable Signal
    Running: Bool    // Running State
    Fault: Bool      // Fault State
    Speed: Real      // Speed Setting

This way, all motors use the same structure, greatly increasing code reusability!

Practical Application Case

Last year, in a filling machine project I was responsible for, after applying this architecture, there was a situation where the customer requested to add a new filling station.Since our program is based on a three-tier architecture, we only needed to:1. Bottom Layer: Add processing for the new I/O point2. Middle Layer: Copy the filling station FB and modify parameters3. Top Layer: Add a call for the new station in the coordination layer

The entire modification only took half a day, without needing to refactor the entire program, whereas with traditional programming methods, it might take 3-5 days to sort out and rewrite a large amount of code.

Common Problems and Solutions

The program is too complex, and too many FBs lead to chaotic calling relationshipsSolution: Create functional groups and use multi-layer DBs to pass data
Too many global variables lead to program instabilitySolution: Strictly control global variables and use static variables in FBs more often
Long scan cycles affect control accuracySolution: Place critical tasks in interrupt OBs for execution

Practical Exercise Recommendations

Start with a simple project, such as a basic control system for three motors. Design the program according to the three-tier architecture, ensuring clear separation of the I/O layer, functional layer, and management layer. Try adding new functions after completion to experience the convenience brought by the architecture. You can use PLCSIM for simulation testing, which allows you to verify the rationality of the architecture without actual hardware.

Remember to save each version of the program for easy comparison of the maintainability differences under different architectures!A good architecture is developed through practice, not just designed.