It is well known that many brands of PLC programs can be decrypted through software, making the program very transparent once decrypted, and thus visible to others. However, completely locking the PLC program when selling the device to others is impractical, as the client would be unable to maintain it. Moreover, confidentiality and rights protection have long been hot topics in the Chinese market. In fact, German engineers never encrypt their programs entirely; instead, they use other methods that do not affect fault diagnosis while protecting their core secrets. Today, I will introduce some of these methods for your reference.

Part 1

Using Siemens Safety PLC or the KNOWHOW feature of TIA Portal

Siemens Safety PLC is a product that emphasizes safety features, and its performance is unquestionable. Moreover, the program blocks of the safety PLC cannot be cracked after encryption, effectively protecting the core. TIA Portal, as Siemens’ latest product, also has copyright protection as one of its main features. The KNOWHOW function provides dual encryption of software and hardware; unencrypted blocks can be monitored normally, and without a password, they cannot even be downloaded to other PLCs. Therefore, using the KNOWHOW function allows the program to be handed over to the client for easy maintenance while protecting the core program from theft.

Part 2

Writing important process programs in high-level languages

In addition to the basic programming methods such as LAD (Ladder Diagram), FBD (Function Block Diagram), and STL (Statement List), Siemens also offers many other ways, such as CFC (Continuous Function Chart) and SFC (Sequential Function Chart) in PCS7. Furthermore, there are languages like SCL (Structured Control Language) and S7-GRAPH. For these languages, it is generally difficult for ordinary industrial control personnel to master them all, significantly increasing the difficulty of imitation. Therefore, critical process programs can be written in these languages, effectively protecting the core.

(1) Programming methods

a)Using modular program structures, employing symbolic names and parameters to write subroutine blocks;

b)Try to use background data blocks and multiple background data transfer methods;

c)Utilize indexed addressing programming methods;

d)For complex control programs, especially those involving sequential control or recipe control, consider using data programming methods, which change the control logic or sequence of the system through data variations.

Users should try to adopt the above high-level programming methods. Programs developed this way can embed system protection encryption programs, making them less likely to be discovered and imitated.

(2) Active protection methods

a)Utilizing the system clock;

b)Using program cards or the CPU’s ID number and serial number;

c)Utilizing the non-rewrite feature of EEPROM and some memory retention features that need to be set;

d)Using the timer functions provided by the system;

e)Setting passwords in the user program’s data blocks;

f)Setting logical traps in the software;

g)Reverse engineering mistakes made during programming.

(3) Passive protection methods

a)Do not delete programs considered useless as long as memory capacity allows;

b)Leave the developer’s identification in the data blocks for future proof in case of infringement;

(4) Considerations for anti-theft techniques

a)Embedding protection programs in user programs should be done naturally, without abruptly adding a segment of code. The code should be as concise as possible, and variable names should be consistent with those in the embedded program segment;

b)One protection encryption method is often insufficient; multiple methods should be used together, and the consequences of activating these protection programs should vary to create a so-called “minefield effect,” thus increasing the difficulty, time, and cost of theft, leaving the imitator helpless in a short time;

c)Protect the original code of the program. If the program needs to be delivered, appropriate technical processing should be done to the delivered program without affecting the user’s maintenance of the device, such as removing some symbolic names or using uploaded programs or data blocks;

d)Conduct rigorous testing to avoid unnecessary troubles caused by the imperfections of protection programs, which can also reduce after-sales service costs.

Part 3

Using communication functions

In practical applications, there are often issues requiring data exchange between systems (between multiple PLCs or between PLCs and third-party instruments). Whether it is between Siemens products or between Siemens products and third-party products, it is recommended to use communication solutions instead of analog or digital signal interconnections. For the former, the imitator can only see a hardware communication line, and they must invest effort to study the specific user program to understand how much data is exchanged through communication. For the latter, the developer has an easier time, while the imitator can see everything clearly.

For programs designed for frequency converters or servo motors, there are generally multiple ways to control them, either through direct wiring or communication control. Using communication methods increases the difficulty of imitation. For example, PLC control of servo drives can be done in various ways; simpler methods may involve direct pulse control or analog control, which are easier to imitate. If communication control is used instead, the program becomes much more complex, and if the imitator is not familiar with the documentation, it becomes very difficult to replicate.

Sometimes, control systems consist of multiple sub-control systems, forming a network of multiple CPUs and human-machine interfaces. Commonly seen Siemens S7-200 products use PPI networks, while S7-300/400 products often use MPI networks, typically for data exchange between the human-machine interface and the CPU. We can also add some basic S7 communication functions in the CPU’s user program that do not require configuration (S7-200 can use NETRNETW instructions, while S7-300/400 can use X_PUTX_GET instructions), allowing for occasional data exchange between CPUs, thus achieving interlocking of control logic between subsystems. For such systems, it is not easy for imitators to analyze the program of a specific subsystem.

Part 4

Using panel-type human-machine interfaces

It is advisable to use panel-type human-machine interfaces in automation systems instead of simple buttons and indicator lights. Many human-machine interfaces lack source programs and only have backup and recovery functions, which can fully implement maintenance functions while keeping the HMI layer’s program confidential. For a PLC system, even if the source program is available, the absence of labels for the HMI part makes it very difficult to replicate.

Moreover, developers can add clear manufacturer logos and connection method information on the panel’s display, making it impossible for imitators to copy exactly.

If imitators want to copy the program, they must rewrite the operation panel’s program and even the PLC’s program. Developers can utilize some special functional areas of the panel and PLC data interfaces (such as Siemens panel’s area pointers or VB scripts) to control the execution of the PLC program. Such PLC programs, without the HMI source program, can only rely on guessing and online monitoring to understand the internal variable logic of the PLC, which is time-consuming and labor-intensive, greatly increasing the difficulty of imitation.

Part 5

Using non-standard human-machine interfaces

German engineers prefer to use this method.

In China, most engineers prefer to use WINCC, INTOUCH, or other configuration software. However, besides these software, there is a more advanced programming method, which is to use VB to write programs. For the interface between software and PLC, one can choose LIBNODAVE or other libraries. This method of writing human-machine interfaces has many advantages. Firstly, there are no copyright issues since VB software is free. Moreover, upgrading for Windows systems only requires adding a few files, unlike WINCC, which requires extensive modifications when Windows is upgraded. Generally, people cannot modify it, let alone replicate it. Without a solid background in computer programming, one would not dare to modify it easily, and those with computer skills but lacking PLC or process knowledge would also be unable to make changes. The author has previously used S7-300 to create such a system, but my goal was not confidentiality; it was a requirement from the client, and the system was created entirely in my style, which was quite comfortable.

END