AUTOMATION & C O N T R O L S

n order to establish some criteria by which to measure the effectiveness of PLC software, one has to look at its application, its use and its maintenance.

The design, documentation and maintenance of PLC software

There are very few books, courses or training manuals on the design, documentation and maintenance of programmable logic control (PLC) software. Many people are also of the opinion that if PLC software works (i.e. it performs its intended function), it is good software and if it does not work, it is bad software. If software is written for an application where it will be commissioned and never touched again (neither for alterations nor for fault-finding), the effectiveness thereof can essentially be measured by how good the control is. Such applications however are few and far between, and do not warrant further discussion. By far the vast majority of software applications are used where someone (usually not the designer) will access it for faultfinding and/or alterations. There are applications where modifications must be made to an existing PLC (which might be relatively full in terms of memory capacity) or there might be an application in a new PLC where memory capacity is limited. In such cases the effectiveness of the software is measured by its effective use of available memory. Other good software principles might therefore have to be sacrificed in order to provide software for minimum memory consumption. In most cases however, memory is relatively cheap and therefore not a huge problem. We can thus concentrate on the issues related to the majority of PLC applications. Structure Good PLC software design will always include a well-defined structure for both the PLC database as well as for by Chris du Toit , WSP Consulting Engineers the PLC program. The database will be structured in such a way that there are clear definitions of different areas and in a way that standardisation can be implemented. An example of a digital database could be: 10001-10200 field inputs 00001-00080 field outputs 00100-00400 internal coils 00401-00600 digital data from other PLCs 00601-00800 digital data to other PLCs 00801-00900 digital data to radio telemetry 00901-01000 digital data from radio telemetry 01001-03000 digital data to SCADA 03001-04000 digital data from SCADA Many other areas can still be defined if required. The principle however, shows that specific data areas are reserved for specific functions. The advantage is that if one has to add to the software, one knows in which areas of the database to look for spare words, registers, files or coils, rather than searching through an entire database consisting of very haphazard allocations. In some PLCs these data areas can even be made local to a specific section of software code. This will ensure that data from one area cannot accidentally be used in the wrong area. Similarly, by merely looking
June 2006 - Vector - Page 40

at an address, one can tell whether the data comes from a radio telemetry system, another PLC, a SCADA system or whether it was generated within the software code. External devices such as SCADA systems, radio telemetry systems and other PLCs on a network can then also be configured in a standard way for data exchange. All these factors contribute to quality control as well as the ease and speed with which software can be evaluated and/or modified. Annotation This is one of the most important ingredients of good PLC software. The annotation referred to, applies to: Annotation of bits, coils, registers, file, etc. Program files, networks, segments, etc. The PLC logic. Let us now consider these aspects in more detail. Annotation of bits, coils, registers, files, etc. First of all, there should again be standardization (or at least consistency) in the way these items are annotated. For example, field inputs should all be annotated in a manner which describes their on or true state (Drive 1 PLC Mode, Pump 2 Not Locked Out, Valve 6 Opened, Water Sump Level Not Low, etc.). In the same way field outputs should be annotated to describe their on or true state (Pump 1 Start, Valve

6 Open, Solenoid ABC Close, Divert Flap To Position 1, etc.). A flags, output or coil generated internally should be annotated to describe the function it actually performs, and not the function it will eventually perform. For example, if a bit has to be set when several interlocks are healthy, and this bit is then later used to start a pump, the bit should be annotated as All Interlocks Healthy, rather than Start Pump. This will ensure that when someone else evaluates the software, he/she can see what causes that particular bit to be on or off, rather than having to search for the code which controls it, to establish how it functions. Words, bytes and registers should be annotated fully and in as much detail as possible, within the constraints of the PLC programming package. For example, a calculated or manipulated analogue value for, say flow, should be annotated as Pump 1 Flow 0-4095 or Pump 1 Flow 0-20 m3/hr, rather than just Pump 1 Flow. The person evaluating the software then immediately knows whether he/she is dealing with a raw or scaled analogue value. This could save a lot of time in searching for the origin of that value. Often one finds that words, bytes or registers that are used to set specific bit patterns are not annotated, because the individual bits are used further on in the PLC logic. Although it might seem quite harmless to the software design engineer at the time, the next person to evaluate or fault-find in that PLC could spend considerable time trying to figure out what that register is used for. Especially if he searches for that register or word, only to find that it does not exist anywhere else in the software (because only the individual bits are used). That register, byte or word should be annotated as Bit Pattern For Recipe Selection or whatever its actual application is. Annotation pf program files, networks, segments, etc. All program files, networks, segments, etc. should be annotated with a description of the actual logic they contain. For example, Water Treatment Plant Controls, Pump Station Level Controls, Mass Balance Calculations, etc. This same annotation (along with the description of the program structure and database structure) should form part of the final documentation for that project. Literally hours of time could be saved if the next person (not the software design engineer) has to find a specific area of logic control, with properly annotated software and documentation.

Furthermore, the original software design engineer might be called back to this project, long after commissioning and handover, (e.g. to do modifications) and he would then be grateful that the software and documentation was annotated properly if he can save face in front of the client by quickly and effectively being able to implement the necessary changes. Annotation of the PLC software logic This is one of the most important parts of PLC annotation because it gives the next person an insight into how the design engineer thought and reasoned when he designed the software. No two people think alike. PLC software is almost like a persons signature because each person writes software in his/her own unique way. The next person to work with this software therefore has to establish how the designer thought and reasoned before he can effectively understand and evaluate the software. Even ones own thoughts and reasoning change as one grows in experience. If the original design engineer therefore has to make changes to his own software long after it was designed, even he would save hours if he can easily determine the reasoning behind the relevant sections of PLC logic. It is for these reasons that every section, network, etc. of the PLC logic must be clearly described. The description should explain the objective of the software logic (e.g. Pump 1 will start if the discharge valve is open and the gland seal water is on but not if the sump level is low, or it will start if Bypass is selected and the sump level is not low), rather than duplicate the ladder logic in verbal terms (e.g. If bit 00320 is on and bit 00321 is on and bit 00322 is off, or if bit 00323 is on, output 00024 will be on). This will provide the user of the software with an insight into how the controls should work, as well as with the logical implementation thereof. The same applies to software used to perform calculations. Show the calculation being done, e.g. Sump discharge (0-4095)/4095 * 320 = sump discharge (m3/hr) One can refer to the registers which contain the different values, e.g.: 40012 = Sump discharge (0-4095) 40013 = Preset of 4095 40014 = Preset of 320 40015= Sump discharge (0-320 m3/hr), but the logic should not merely be duplicated in verbal terms.
June 2006 - Vector - Page 41

PLC software annotation should be done in a way which provides the best overall picture of the objective one is attempting to achieve with any section of the code. In many applications the best way to provide this overall picture is by showing diagrams. Take the example where different valve configurations apply under different conditions: This diagram shows the valve positions
High Temperature open valve 1 valve 2 valve 3 valve 4 X X X X X X close Normal Low Temperature Temperature open X X X X close open close X X

for three different temperature conditions. If one had to explain this verbally, it would require a considerable amount of text and it would be more difficult to interpret. If the logic was duplicated verbally in the annotation, it would be even more difficult to follow. One can also use Boolean Logic to explain certain operations if it makes it easier for the end user. For example:

Another very effective form of annotation is the use of logic truth tables as shown:
Drive 1 Start Proximity 1 Covered Proximity 2 Covered Proximity 3 Covered Drive 2 Started 1 1 X X 1 1 0 1 X 1 1 0 0 1 1 0 X X X 0 0 0 0 0 X

where: 1 = True 0 = False X = Does not matter This table indicates that: Drive 1 will start if: Proximity 1 is covered and Drive 2 has started, or Proximity 1 is not covered, Proximity 2 is covered and Drive 2 has started, or Proximities 1 & 2 are not covered, Proximity 3 is covered and Drive 2 has started.
Advertorial

Drive 1 will stop if: Drive 2 stops, or Proximities 1, 2 & 3 are not covered. Software design techniques The actual software code forms the core of the overall PLC system. Although the way of designing PLC systems and the way of writing PLC software should not be dictated by any one person, there are some guidelines to be followed in order to provide a good overall design. Hardware layout The layout of the PLC hardware (i.e. the field input and output allocations) can save a lot of work, without complicating the software. For example, where digital inputs are used to monitor opened and closed positions of valves, all the Closed inputs can be allocated to an input card, while all the Opened inputs can be allocated to a different input card. If a logic condition then requires that all valves in an area are opened or closed before certain actions are taken, one could use the entire input word (or a register), instead of having a large quantity of digital logic which would check the status of all valves concerned. For the same reason one could, for example, have all the valve outputs allocated to one digital output module, while the outputs for other devices (like motors) are allocated to a different output module. Equally important from a hardware point of view is the way in which inputs are read. All inputs from devices such as position monitors, level switches, pressure switches, overloads, isolators, emergency stops, limit switches, etc. should be hard wired in a fail-safe mode. This means that if the cabling from the device is broken or a loose connection occurs, the PLC software should interpret this as if the relevant device has operated. If the inputs are not wired in a fail-safe mode, a high level, low flow, limit switch, etc. will never come on if a wire is broken or there is a loose connection, which could result in damage to equipment or injuries to personnel. Avoid spaghetti software Interlocking of valves, drives, etc. for safety purposes is essential in any PLC design. The interlocking however, can be taken too far. Consider the example where water pressure needs to be monitored before a valve can operate or before a pump can start: This could have been programmed as:

This is a very simple example, used to illustrate a principle. In more

sometimes be simplified to the extent where it starts becoming difficult to relate the logic to its verbal description (in the annotation). If a seemingly more

complex systems, this type of belts and braces programming could lead

to software which is so cross-interlocked and complex that it really becomes spaghetti software, which is extremely difficult to follow and equally difficult to do fault-finding in. A second way to create spaghetti software is to use one bit to switch on an internal coil. Unless this concept is used to invert signals or to transfer data to another area, there should never be a need to use such logic, because wherever Bit 2 is required, Bit 1 can be used. A third way to create spaghetti software is to use two outputs (not field outputs), set from the same logic. This situation is made even worse if the two outputs are given different descriptions.

complex logic circuit can more clearly display the purpose of the logic than its simplified equivalent, the circuit should not be simplified further. Maintain data integrity PLC software always involves the transfer of data, either from the field to the PLC, from the PLC to the field, between PLCs, between PLC and between PLC and radio telemetry systems and so on. Any of these systems can fail. One must therefore never merely assume their successful operation. Where analogue inputs are read from the field, this data should be read into a buffer area first, and only if one is sure there were no problems with the data transmission, should this data be transferred to the relevant areas in the PLC software where valid data is then used. If an error in the data transmission has occurred or if a fault occurred in the analogue input module, data which might be corrupted should not be transferred for use in the PLC control logic and the failure must be alarmed so that action can be taken. In the event of such a failure, one needs to look at the process involved. If the previous data (from a successful transmission) can be retained, it should be, otherwise the data should be set to zero or to maximum. The decision of setting to zero or maximum will again depend on the process. For example if a level from a tank is transmitted to another PLC, to allow a pump to be started, this value should be set to maximum, so that the pump does not start and perhaps cause flooding. If on the other hand it is a

If they are both set by the same logic, surely their functions would be identical and their descriptions should be the same. By the same token, wherever the second output is required, the first output can be used. Very often the application of Boolean algebra to relay logic can go a long way in simplifying software design. For example:

It is however important to maintain a good balance. Logic circuits can

June 2006 - Vector - Page 42

flow which is transmitted, to allow a drive to start, this value should be set to zero so that the drive does not perhaps start and run without this required flow. The same principles apply to any other data transmission (whether analogue or digital and regardless of the systems involved). Most data transmission systems (e.g. analogue inputs, data read and write between PLCs, etc.) have built-in monitoring of transmission success or failure. Various bits, words or registers are then manipulated to indicate the success or failure. These bits, words or registers should be used to set alarms, clear data, etc. (as described earlier). Sometimes it is necessary to look at the various functions available (e.g. data read or data write). The function which provides the highest degree of data integrity should be used. In some applications the built-in monitoring of data transmission does not exist. In such cases one should make use of handshaking between the systems to ensure the successful transmission and receipt of data. Again, if the handshaking fails, the software should not allow false data to be transmitted. (Handshaking is where one system acknowledges the receipt of data to the system which sent it.) Quality assurance The best software in the world can be reduced to a mess of torn-apart spaghetti if it is hacked and panelbeaten on site, because there were differences between what was required (or expected) and what was supplied. Furthermore, the amount of work and time required to tidy up and properly annotate such hacked and panelbeaten software is usually not worth the effort, with the result that such software ends up never getting tidied up or properly annotated at all. It is therefore essential that good quality assurance procedures are set in place before the design and development starts. It is obviously a huge advantage if the software engineer is from a company which has ISO 9000 accreditation. Good PLC software starts with quality control. This is where the design engineer ensures he knows what the client wants and where the client ensures he knows what is being supplied. The quality control also ensures that both parties work towards the same objective and that progress, standards and quality

of work are monitored throughout the development and implementation period. It further ensures that there are no nasty surprises for either party towards the commissioning phase of the project. Conclusion Software design engineers must remember that in 90 - 98% of all PLC applications, someone else will access that software, modify it or perform fault-finding. It is therefore essential to program and annotate the software in such a way that it is user-friendly. Poorly designed or poorly annotated software can cost a great deal of money in terms of time wasted to fault-find or to find out how it works, before alterations can be made. The astute client or end-user of software will always:

Ensure that someone within his organization has the ability to distinguish between good and bad software. Ensure that effective quality assurance procedures are set in place before the project commences. Ensure that examples and proposals for the software development and documentation are approved before the actual design is started. On a regular basis, monitor the progress of the software and documentation design. Ensure that comprehensive software documentation is submitted at the end of the project. Contact Chris du Toit, WSP Consulting Engineers, Tel (011) 233-7800, cdt@wspgroup.co.za

June 2006 - Vector - Page 43