PLC Software Standardisation

In order to achieve the goal of 'more configuration, less programming', standardised templates and processes were required for all areas of the software. This was countered by the principle of 'Never Change a Running System'. Nevertheless, CTE faces up to the challenge of continuous improvement in order to deliver a product that perfectly meets the customer's requirements.

In a world of constantly changing requirements, constantly having to reinvent everything from scratch is not very efficient. That is why we need a foundation that can cover the vast majority of requirements. These templates must be as general as possible, yet as versatile as necessary. CTE has set itself the goal of using a modular approach to bring the benefits of object-oriented programming—which has long been established in other areas of software—to the PLC level.What is a PLC?A PLC (programmable logic controller) is a system for process control. It collects sensor data via inputs, processes it, and controls actuators such as motors or valves via outputs.

Although there were already a number of PLC programs that had been reliably and productively in use for years, the new modularisation process stopped at nothing. Every function, every module, every procedure was scrutinised and assessed for its necessity and suitability.

CTE’s proven approach of dividing a system into basic functions is ideally suited for modularization. Regardless of the actual function—whether it is pressure control, dosing, or the control of a heating/cooling circuit—the fundamental characteristics of each basic function are always identical. These general signals are primarily used for communication between the PLC, the visualization system, and recipe control. The defined template on the HMI side —What is HMI?HMI (Human Machine Interface) is the interface between humans and machines. Usually implemented as a dashboard, it serves to control and display operating data and statuses— guarantees identical functionality across different PLC types. Since we have recently been serving an increasing number of customers with controllers from the manufacturer Allen-Bradley, the new modular system was naturally also integrated into this software structure. This is because modularization is manufacturer-independent and applies to all PLC types.

What was standardised?

Advances in development environments, such as the TIA Portal by Siemens, already offer more comprehensive functions than their predecessors. And since you don't need to reinvent the wheel, time and effort were saved and the system libraries were used.

A template data type was created for each actuator and each sensor, which contains both data and functions. For example, the template of the valve type contains information on its current position, links this with the control commands from the HMI and programmed logic, and uses integrated intelligence to generate a status image of the valve, including alarms.

The newly created data type Alarm behaves in the same way. It has properties such as belonging to the priority class, time delay and acknowledgement status. This makes it much easier and quicker to make adjustments than if an alarm only consisted of the active/inactive property. This means that a priority change does not require any programming effort, but rather a configuration adjustment. The existing code does not need to be adapted, loaded and checked again.

Recurring data is summarised in a template. For example, the status of a basic function (CSF) and its control signals from the HMI or the recipe handler. Regardless of whether the system has one or ten
CSFs: If an additional value is required, the change only needs to be made to the template and all instances automatically align themselves.

To ensure consistency from specification through implementation to verification, the data templates mirror the structure of the project documentation. The classification of a basic function’s parameters into global, fixed, machine-specific, or variable parameters from the Software DesignSpecificationWhat is a Software Design Specification (SDS)?A document that describes the technical structure and design of a software system, including architecture, components, and implementation details. is also reflected one-to-one in the program’s data structure. Sensors, actuators, and alarms that are assigned to a basic function according to the documentation can be found in the data structure of the GFK.

How does the customer benefit?

The standardisation of all related elements in the code makes the entire program more readable, clearer and easier to understand for humans. This means that programmers without prior knowledge of the system can find their way around the code more quickly. This advantage is not only a one-off benefit during the development phase, but also helps to introduce new components more quickly and reduce misunderstandings during operation.

Reusability saves the customer time both when creating a new system and when making adjustments during subsequent operation, as the effort required to change the configuration is less than that required to change the programming. In addition, nothing has to be redeveloped and programmed for extensions. With the existing templates and library modules, all the basics are already in place.

Adaptations are often due to a configuration issue resulting from the functional diversity of templates. As no intervention in the code is necessary, changes to the productive system are less critical and therefore easier for the customer to plan.

If the responsible programmer changes, the customer does not automatically experience a change in programming style. The framework conditions guarantee a structure that is independent of the person responsible.

As the modular structure in the PLC is not tied to a specific programming environment, the customer is free to choose the hardware. The Zenon user interface by Copa-Data used by CTE offers a consistent interaction level for the operator, regardless of the PLC used by the customer.

How does CTE benefit from this?

Every advantage for the customer is a plus for CTE. We are as good as the product's ability to satisfy our customers. In addition to the great added value for the customer, modularisation also simplifies internal work. Instead of guidelines and instructions that are time-consuming to maintain, templates and libraries speak for themselves. When a new project is started, there is no need to consult the guidelines to find out which data areas need to be created for which purpose. The library provides everything you need, making development easier right from the start.

Optimised processes in programming and testing guarantee fewer errors and therefore, less effort in post-processing or, in the worst case, even prevent complaints. As the data structure of the specification is reflected in the software, the correctness check is carried out faster and more reliably. The documentation of the tests automatically guides the tester to the right place in the software, making long searches or uncertainty due to multiple occurrences of parametres a thing of the past.

What happens next?

The positive internal feedback from the implementation of the first projects using the new system gives us the certainty that we are on the right track. We are driven by the desire to constantly improve. That is why we are continuing to drive forward modularisation at both PLC and HMI level. There is still potential for simplified programming and, just as importantly, more convenient and reliable testing. Verification of correctness through code review is another way of optimising the project process. However, this requires a consistent modular structure.

A first step has been taken, others will follow. The important thing is that the direction is right.