Dream of a platform-independent PLC program

Article#: 00092

Date: 2024-05-26

Author: Radim

It's a beautiful idea to write a program that we can run on any PLC and thus ensure complete independence from the PLC vendor, isn't it?
And why should we want to be independent of the PLC vendor?
Because we can easily switch PLC vendor if we are no more satisfied with the current one (e.g. because the vendor no longer exists, material delivery takes too long, prices have risen, quality and performance are unsatisfactory, support is poor, our requirements have changed, the competition offers better conditions, etc.). However, switching PLC vendor is not easy when our development team has invested hundreds of hours in developing a program that can only be executed on the specific PLC for which the program was developed and tested.

So why not write the program universally so that it can simply be executed on all possible PLCs? Because it's impossible. :-(
There are practical challenges and limitations:

1. Vendor-specific hardware features:
Each PLC hardware platform has unique capabilities, performance characteristics, I/O modules and proprietary features.

2. Vendor-specific software features:
While many PLC vendors support IEC 61131-3, they often have proprietary extensions and features that are not portable.

3. Differences in performance:
Different PLCs have different processing power and memory capacities.

4. Integration into existing systems:
In every machine or a plant, PLCs must be integrated with other devices and systems that have manufacturer-specific interfaces and protocols.

5. Diagnostic and troubleshooting:
Vendor-specific diagnosis and troubleshooting tools are often more advanced and tailored to their own hardware.

6. Safety project:
Every PLC vendor has its own specific safety hardware, its own safety project editor and its own programming method for the safety project.

I actually think it's perfectly fine that there are differences between the PLCs in terms of their hardware and software capabilities. Because everyone can choose the one PLC that meets their requirements. (You can read about how to choose the right electrical components in this article: Hardware concept)


Well, it is not possible to write a platform-independent PLC program. However, it is possible to choose such an approach so that the program can be ported more easily to another PLC. This involves several strategies:

1. Modular design:
Break down the PLC program into modular components, where the core logic is platform-independent, but hardware-specific modules handle interactions with the PLC hardware. This can minimize the amount of code that needs to be customized for different platforms.

2. Standards compliance:
Adhere to industry standards like IEC 61131-3. This ensures a level of portability and easier adaptation across platforms that support these standards.
To choose from a predefined set of compatible PLCs, we can also select vendor-independent programming environments: some programming environments and tools are designed to work with PLCs of different brands. For example:
Codesys: A hardware-independent IEC 61131-3 development environment. It supports a wide range of PLC hardware from various vendors.
PLCopen: An organization that promotes standardization in programming across different PLC vendors. They provide guidelines and function blocks that can be used to create portable applications.

3. Platform-specific optimizations:
Where necessary, include platform-specific optimizations as separate modules or conditional code sections. This approach allows you to maintain high performance and leverage specific features without compromising the overall portability of the application.

4. Standard communication protocols:
Use standard communication protocols (e.g. OPC UA, Modbus, EtherCAT) for interaction between PLCs and other systems. This enhances interoperability and reduces dependency on vendor-specific protocols.

5. PLC vendor-independent visualization and safety projects:
Select a PLC-independent solution and a standard communication interfaces for the visualization and safety projects.

Following these strategies brings a clean structure and clarity to the code. It makes sense to follow most of these strategies, even if you do not intend to transfer the PLC program to a PLC from another vendor.
In addition, it is definitely worth following the principles for writing a clean code mentioned in this article: Maintain order in the program code

To ensure that the code is transferable to different platforms, additional effort is required for design, implementation and especially testing. We can select two or three suitable PLC suppliers and develop portable software for their platforms if our project requires a certain degree of "platform independence" or rather platform redundancy.

© Radim-Automation, 2020–2025. All rights reserved.
Sharing of this article is permitted with proper attribution (link to the original page).

Related previous articles:

• Make backups, make small changes and test a lot
• Code formatting
• Maintain order in the program code
• PLC network diagram
• Version control system
• Diagnostic tools
• Event logger as the very first function implemented in the program
• Software update
• Safety relays versus safety PLC
• Choice of programming language
• Variable names
• Machine modularization
• Modular software architecture
• Hardware concept
• A good concept = Complete set of suitable solutions
• Are there also any disadvantages?
• Think critically!
• Why do automation projects fail?
• Collect all the requirements and sort them!
• Functional and intuitive HMI
• Use a usefull styleguide!
• Write and accept only readable code!
• HMI and PLC applications should grow together
• Do you really want to start with this?
• More than just start and stop
• Safety first!
• Industrial evolution - Listen to your customers and follow new trends!
• Have an expert on hand!
• Focus on target!
• Check the result!
• Keep it simple!
• Choose the right tool!
• Development is evolution
• Transparency and reliability

Related next articles:

• High Performance HMI
• Choosing an HMI display
• HMI layout and correct display size

Comment#: 00001

Date: 2024-06-18

User:

Creating a platform-independent PLC (Programmable Logic Controller) program is a forward-thinking concept aimed at enhancing flexibility, interoperability, and future-proofing in industrial automation. The traditional approach ties PLC programs to specific hardware or vendor ecosystems, which can be limiting. Here’s a conceptual guide on how to achieve a platform-independent PLC program:

### 1. **Define Platform Independence Goals**

#### **Objectives:**
- **Hardware Agnostic:** The program should run on any PLC hardware or even on virtual PLCs.
- **Vendor-Neutral:** Avoid reliance on proprietary features or libraries.
- **Standardization:** Adhere to open standards (e.g., IEC 61131-3).

### 2. **Choose Standardized Programming Languages and Tools**

#### **IEC 61131-3 Languages:**
- **Structured Text (ST):** High-level, text-based language similar to Pascal.
- **Function Block Diagram (FBD):** Graphical representation for logical and mathematical operations.
- **Ladder Diagram (LD):** Graphical programming language resembling electrical relay logic.
- **Instruction List (IL):** Low-level, assembly-like language.
- **Sequential Function Chart (SFC):** Flowchart-based language for sequential control.

#### **Tools:**
- **OpenPLC:** An open-source PLC project that supports IEC 61131-3 languages and can be run on various hardware platforms.
- **Codesys:** A widely used IEC 61131-3 development environment that supports multiple PLC vendors.
- **PLCopen XML:** Standardizes the interchange of control programs across different platforms.

### 3. **Use Abstract Hardware Descriptions**

#### **Hardware Abstraction Layer (HAL):**
- **Input/Output Mapping:** Abstract physical I/O to logical names.
- **Device Drivers:** Implement generic drivers for common hardware types (e.g., digital inputs, analog outputs).

### 4. **Design Modular and Reusable Code**

#### **Component-Based Design:**
- **Function Blocks:** Create modular, reusable function blocks that can be instantiated as needed.
- **Libraries:** Develop or utilize standardized libraries for common functions (e.g., PID control, communication protocols).

### 5. **Implement Cross-Platform Compatibility**

#### **Virtual PLCs and Emulators:**
- **Simulation Environments:** Test your PLC program on software emulators before deployment.
- **Containerization:** Use containers (e.g., Docker) to run PLC programs in isolated environments on different hardware.

### 6. **Ensure Communication and Integration Flexibility**

#### **Protocol Support:**
- **OPC UA:** Open Platform Communications Unified Architecture for secure, reliable, and platform-independent communication.
- **MQTT:** Lightweight messaging protocol for small sensors and mobile devices.

#### **Integration:**
- **REST APIs:** Use web APIs for integration with higher-level IT systems.
- **Fieldbus Standards:** Support common industrial protocols (e.g., Modbus, CANopen).

### 7. **Adopt Industry Standards and Best Practices**

#### **Compliance:**
- **ISA-88:** Batch control standard for batch processes.
- **ISA-95:** Standard for integrating enterprise and control systems.

#### **Documentation:**
- **Code Documentation:** Thoroughly document code and logic for maintainability.
- **Configuration Management:** Version control systems (e.g., Git) for managing program changes.

### 8. **Testing and Validation**

#### **Automated Testing:**
- **Unit Tests:** Test individual components of your PLC program.
- **Integration Tests:** Verify the interaction between different modules and systems.

#### **Simulation:**
- **Process Simulation:** Simulate the process environment to test the PLC program under different scenarios.

### 9. **Security and Safety**

#### **Security:**
- **Encryption:** Use secure communication channels.
- **Access Control:** Implement robust authentication and authorization mechanisms.

#### **Safety:**
- **Fail-Safe Mechanisms:** Implement safety checks and redundancy.
- **Standards Compliance:** Ensure compliance with safety standards (e.g., IEC 61508).

### 10. **Continuous Improvement**

#### **Feedback Loops:**
- **User Feedback:** Gather feedback from operators and engineers to refine the program.
- **Performance Monitoring:** Continuously monitor and optimize program performance.

---

### Example Workflow

1. **Design Phase:** Use a standardized PLC programming environment to design your logic using IEC 61131-3 languages.
2. **Development:** Implement HAL to abstract hardware details.
3. **Testing:** Use simulation tools and emulators to test the program.
4. **Deployment:** Deploy on various hardware platforms using virtualization or containerization.
5. **Integration:** Ensure seamless communication with other systems using standard protocols.
6. **Maintenance:** Regularly update and test the program for continuous improvement.

### Conclusion

Creating a platform-independent PLC program involves leveraging open standards, modular design principles, and cross-platform tools. It enhances flexibility, reduces dependency on specific vendors, and ensures that automation systems can adapt to evolving technology landscapes.

Comment#: 00002

Date: 2024-07-03

User: Radim

Usually, each PLC manufacturer offers some libraries or functions of its own that do something better or additional than the standard libraries and functions. I think it's a pitty to give up the advantages of our chosen platform at the expense of portability. We should take advantage of our chosen platform to make it easier to get to the right solution.