Software (SW) determines the function and purpose of a PLC. A controller without SW is an automaton with great power, but without intelligence and direction. It is the SW which determines how a PLC will act in any situation, and react to any stimulus. When the PLC fails, the SW can migrate easily to another PLC.
Sounds like something out of a scripture? Yes, software is the soul of the PLC. The program of a PLC is, in effect, a description of functioning of the machine. The PLC, even with massive power, remains a dumb machine if not told in great detail and full precision regarding each step of operations. Such a program encapsulates complete description of the process, and thereby determines quality of the machine.
Today’s machines need to do more than produce goods. They have to connect to other machines for synchronised line operation, provide functional safety for operators and process, talk to ‘Cloud’ for data storage and manage cyber-security.
In earlier days, a machine could be represented by electrical diagrams called ladder diagrams. Today, however, more sophisticated languages, compilers and testing tools are needed to describe modern machines and processes. In spite of this, the control program remains mysterious and complex to develop and maintain. Hence, it is important for manufacturers to pay attention to automation software and how it is developed.
There is more SW than that which resides in PLC
The SW in PLC is the set of instructions that the controller executes cyclically. However, there is more SW than this. Primarily, the mass of SW is divided into two categories — runtime and development SW. Development SW consists of the environment in which a programmer works — the editor, the compiler, the downloader, etc. The runtime environment is the SW which resides in the memory of the PLC, and executes when the PLC is in ‘run’ mode. Here again, software is classified into two sections — System SW and Application SW. System SW is the operating system (RTOS) and set of libraries. Application software is the portion developed by the buyer of the PLC, to achieve the specific functionality. The development platform provides him with tools to create the application SW, to compile, download and debug in the PLC.
What is so special about application software
PLC application software is usually very complex. PLC programs operate in an environment where many events are happening simultaneously, and the entire code reacts to these interrupts in the order of priority. Therefore, application programs operate inside a real-time operating system. Main demand on the RTOS is to be economical in the use of resources—processor time and memory space and also, be responsive to process inputs and triggers. This is in contrast with legacy controllers and RTOS would allow a single ‘thread’ of program to execute until output is generated, modern day systems use multitasking to be more reactive. It allows higher priority task to interrupt a lower priority task at any point.
It makes sense to use higher level languages
A program is complete when it is written, compiled, downloaded to the machine and operates as per requirement. Each line of code can be quite expensive in terms of programmer cost, inclusive of the efforts of testing, debugging, corrections, material wasted in trials, etc. In contrast, while processor costs and storage memory costs are dropping over time, cost of programmers are increasing. Therefore, it is important to maintain high productivity of programmers. Using a higher level language makes sense since the productivity of programmers increases by orders of magnitude and can manage PLC controller in performing many advanced functions.
Progressive disclosure of complexity
Progressive disclosure is a design technique, which helps in keeping focus on one’s objectives, by reducing clutter. This advanced technique introduces a meta-layer to the higher level language. It improves efficiency and hides complexity below a layer of ‘macro’ instructions. This is achieved by encapsulating frequently used functions, for example, a PID control into an app. The app contains the code, corresponding GUI, and links to generate alarms, fault messages, historian and report generator, etc. Hence, the programmer can easily use this app in the project.
Artificial Intelligence to assist programmers
AI is all pervasive, and can be a very helpful hand-maiden. It is so comfortable for the system to highlight errors and implausibility, convenient to double-check, and provide automatic documentation. Modern programming platforms provide all these features. Not so long ago, these features were called ‘Expert Systems’. Some of the services are configuration checking for feasibility, documenting the topology of automation system, calculating power supply requirement, checking end-to-end cycle time and such chores. Therefore, the point is, it does not take a programming expert to program like an expert!
Programming need not be done by programmers
In the olden days of mainframe computers, the procedure for computations was as follows — a physicist or mathematician (domain expert) will develop an algorithm and employ services of a programmer to convert the algorithm into a computer language like, FORTRAN or ALGOL. This process is repeated each time when a small variant is tried — a lengthy loop! A similar case exists with Application SW programming today. The machine designer explains the requirement of machine to the programmer. The programmer then creates code to translate his understanding into PLC language and feeds it to the PLC. Unsurprisingly, the PLC, at first shot, does not do what is in the mind of the original designer. Many iterations are required to get a satisfactory result. One source of this problem is the double layer of description.
Modern tools can take away the need for expert programmers, and the machine designers can directly and comfortably develop code, thereby, shortening the process and reducing errors of understanding. This is where ‘apps’ and expert systems can be of great help. If we hide unnecessary complexity from the domain expert and present an interface which is couched in process terms rather than PLC terms, much efficiency can be gained.
Modelling software and generation of code
Many processes are designed using modelling software by process experts. Traditionally, after finalising the algorithm, it is re-written in a PLC programming platform, which introduces some errors. Modern practice is to provide a direct link from the modelling software to automatically generate PLC code.
Myth – PLC software is ‘simpler’ than IT software
Nothing could be more wrong! Indeed, the PLC software, being so close to and directly mirroring a machine process in real time, is much more complex in structure and in development. Therefore, development process needs the tools and techniques, which are deployed in development of larger bodies of software. But, due to a widespread misconception, equal amount of resources and attention are not accorded to PLC software development. This needs to change, specifically for SMEs.
Software quality — maintainability and scalability
SW must deliver the functions demanded. This is the minimum. It is verified by running the machine and testing for expected behaviour. However, SW being what it is, there are other attributes which are not demanded by the user but by the OEM. Since SW needs to be maintained and modified, often by people other than the original author, it must be readable, and well structured. It must also be robust against wrong commands and have sufficient diagnostic points and messages. SW must be scalable—an important condition these days. It should run as it is or with little modification on processor of next generation. This protects against obsolescence as we had discussed last month.
Sandbox or virtual commissioning
The costliest time an engineer can spend is on the customer shop floor. The machine is delivered, but fails to work the way operator needs. The problem lies in software. The commissioning engineer is delving through the code, but finds it challenging since he is not the author of the code. There are modern ways to avoid such situations, by borrowing a concept from IT world. Build a sand-box to test out code right at lab, before shipping the machine. Simulate the PLC as well in a laptop and test code against it. There are techniques to have Hardware-in-the-loop, Software-in-the-loop. So, when the machine arrives on the shop floor, it is ensured to high degree that it will run first time right!
SMEs take more care
Why do we single out SMEs? Well, they have special constraints. Firstly, they find it difficult to retain skilled programming talent. They are unable to spend on testing of the application SW. It is also observed that describing the machine process in great detail raises fears of loss of confidentiality and protection of rights. Therefore, it is recommended that this is the segment which should move to advanced platforms and take the development process into their custody.
Quality is key
Software is a complex and costly part of the machine. So, care must be exercised about all aspects — how the SW is specified, how it is tested, how the versions are kept in safe custody. It is also important to consider the quality of SW — how friendly it is to debug and diagnose, to modify and maintain.