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 is not very efficient. That is why a basis is needed that can cover the majority of all requirements. These templates must be as general as possible, but at the same time as versatile as necessary. With its modular approach, CTE has set itself the goal of using the advantages of object-oriented programming, which has long been established in other software areas, at PLC level too.

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 perfect for modularisation. Regardless of the actual function, be it pressure control, dosing or the control of a heating/cooling circuit, the basic properties of each basic function are always identical. These general signals are mainly used for communication between the PLC, visualisation and recipe control. The defined template on the HMI side guarantees identical functionality for different PLC types. As we have recently been increasingly serving customers with controllers by manufacturer Allen-Bradley, the new modular system has naturally also flowed into this software structure. This is because modularisation applies to all PLC types, regardless of the manufacturer.

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 to implementation and verification, the data templates map the structure of the specifying project documents. The subdivision of the parameters of a basic function into global, fixed, machine-specific or variable parameters from the software design specification can also be found one-to-one in the data structure of the program. Sensors, actuators and alarms that are assigned to a basic function according to the documentation can be found in the data structure of the GRP.

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.