PLC control logic analysis methodologies

  • Thread starter Víctor M. González
  • Start date

Thread Starter

Víctor M. González

Hi all,

I am developing my PhD thesis about PLC programming and I am conducting a survey amongst industry and consulting/engineering companies to know whether they use or not any methodology, method, technique or architecture for PLC control logic analysis and design.

The common answer among small (JL Constructor), medium (Electrolux) and large (Volvo, ABB) companies is NO.

I would like to have more answers about this issue and maybe you can help me with it.

Can you tell me if your company uses any kind of PLC control logic analysis and design methodology? Do you use any supporting tool?

You can send your answers to the forum or to my email "[email protected]", mailto:[email protected]

Thank you very much in advance.

Víctor M. González
University of Oviedo (Spain)
When I first got started in the industry on my first couple of PLC programs I used Karnaugh maps and logic reduction methods, and experience taught me that all I was accomplishing was making compact programs that only I could understand and maintain. Since the PLC has a fixed memory, ie the memory chips are already there so use them, it makes little sense to write compact code at the expense of readable code for the majority of applications. (There may be a few where compactness is still desirable). Instead I try to make any potential problems more obvious to any
maintenance technician that may be working on the equipment in the future, even if that means duplication of logic (within reason of course). I usually break my control systems down into small discrete problems as much as possible. Generally, if the problem cant be solved in 10 rungs or less, break it down some more. Each job
is different, but I break it down along obvious groupings, such as location and/or function. Each grouping is handled by a seperate subroutine in the PLC program. I also do not use contiguous memory addresses anymore, but rather I divide memory into blocks by grouping. For example, in an AB PLC I would create bit arrays for zone 1,2,3,etc. such as B13, B23, B33, etc. (Same for other data types or structured data). In a 6-1131 compliant PLC I make sure the tag name is obvious to the group breakdown. I don't know if thats the best way, but the maintenace staffs of my customers have indicated that they like the way I break programs down because they can figure out what it does and easily find things. The most important thing to consider when writing a PLC program is that the maintenance staff of the end user company does not have a computer programmer, and they are the ones who need to
understand it and be able to use it as a tool to maintain production. Some programmers want to still own the code in the PLC as intellectual property, but the bottom line is the customer owns the machine. You may as well make his life as easy as possible.
Modular programming!!!

Using modular programming concepts allows the programmer to develop, debug and reuse code many times reducing the chance of programming bugs and improving reliability.

With earlier PLC systems that simply emulated relay ladder logic, about all you could do was design a relay type circuit and implement it in the PLC. But, that was a long time ago. In the last few years, I have developed standardized logic for commonly used applications. For example, standard motor control logic, valve control logic, linear actuator logic, sequencer logic. These are standardized blocks of logic that include enough features that they work in 99.9% of all my projects without modification. I've generally implemented them as array solve type logic, so that for example, the logic for all motors is solved simultaneously. This makes the logic for the low level details of motor control very compact and leaves more memory available for important process control issues.

This has the important overall effect that it draws attention away from how to control a motor, and focuses on how to control a process. It has been my experience that PLC programmers seem more concerned how to control a device than how to control the process. Consider a motor or a valve to be a peripheral on the PLC system -- like a hard drive connected to a PC. When a computer programmer wants to save data to a file, he doesn't write low level code to move the heads, seek a sector etc.; he just calls a file write routine. The fact that many PLC programmers concern themselves so much with low level code likely is due to a lack of training in computer science fundamentals. So, what I'm saying essentially, is that when I program a PLC I'm
thinking at the process level and not the equipment level. I've really only discussed two levels here: the equipment and the process. But, I actually use several layers of control protocol. They are:
1. Lowest level hardware control of the PLC output to control the device (eg. motor)
2. Equipment safety interlocking to trip off the equipment in case of equipment malfunction (eg. motor overload)
3. Process safety interlocking to trip off the equipment in case of process malfunction (eg. stopping conveyor to prevent product pile up due to failed downstream processing equipment).
4. Auto/manual logic to bumplessly switch equipment between manual operation and automatic operation
5. Process related control. This generally is based on a process model that gives the program an "understanding" of the process and how to control it in terms of this model.

More layers can be added on top of this as necessary to do things like monitor/control energy efficiency and operating cost.

So, when developing a project, you start debugging at the lowest level and work your way up level by level. When level 1 is debugged for one motor, it works for all motors. Likewise for each level of added complexity.

On the subject of making the program understandable by maintenance staff, this has been a sensitive issue on a couple of recent projects. They were both very complex sequence driven batch systems. One had eight sequencers running simultaneously, several of which had to synchronize with each other on certain steps. The other project had 3 sequencers running simultaneously and which had to sychronize with
each other on certain steps. By using my canned sequencer subroutines, the main program was very compact. The entire program including subroutines was only 10 pages long. This replaced a buggy earlier program that was about 150 pages long. The
owner's maintenance supervisor was not happy with my program because he didn't understand the concept of subroutines. He wanted it rewritten as one big flat program. Fortunately, he was overruled by upper management; partly, because the
system worked bug-free as soon as the PLC was powered up. I was supposed to go out to site to help with start-up, but they cancelled my trip because everything worked perfectly. I certainly don't claim zero commissioning time for all of my projects, but I was pretty happy with this one. Also, we pointed out that maintenance staff do not need to understand the internal workings of the subroutines as long as they simply understand their function and what the various inputs and outputs are for. We also pointed out that the owner's requirement that "the program shall be written in such a way that any plant electrician can understand it," is just not possible in every circumstance. An extremely sophisticated process often requires an equally sophisticated PLC program. You can't guarantee that someone without advanced PLC programming experience will necessarily be able to understand it. Furthermore, I argue that someone who doesn't understand the necessary advanced programming
concepts should not be allowed to mess around with the program at all. That's why they hire outside consultants in the first place.

darcy oldfield

I have used a couple of different program styles.

The first one was step logic:
This logic is very easy to follow as it is very straight forward (Step 1 happens then Step 2 so on and so forth). When the last step is reached all the steps are reset and the process starts again.

The second style I started to work with was motion Blocks:
Motion blocks are a little more complicated at first but after you work with it you will find it very structured. A motion block would contain all the info to create a output be it safetys, Auto commands, Manual commands and it also contains any faults which might occure with the output. I believe that the motion block programming was first developed by GM. By using motion blocks it means that multiple programmers would end up with a code which is similar which is always good.
An unfortunate side effect of having a laptop and PLC software available to the maintenance staff is that it is the first tool they run for when something goes wrong, even though the problem is almost always electro/mechanical not software. If
they dont have the laptop/software, they run to me first thing instead of trying to solve the problem. Management is no help, what they want most of all is to have the process back on line. Like it or not, and I don't, political expediency dictates that maintenance has acess to the PLC programs. However, I never let the maintenance staff touch my code, but I do let them observe it to try to determine what switch/actuator is not working. I do despise 3:00 am telephone calls, so the more they can be equipped to deal with, the better. I weigh this heavily against compact code. One of our other staff members wrote a nice little compact eleven rung program with sequencers for a powder press with dozens of cam operated limit switches caked in fine sticky powder. I also let him handle the 3:00 am calls for it, and he gets a couple a month, not to mention the daytime calls as well. He would like to redo the program now, but guess what, the machine keeps eating up his extra time. Don't get me wrong, I love sequencers, I just don't hide the functionality. eg - sequencer inputs are visible on rungs with the sequencer step advance (redundant? yes) and sequencer outputs go to internal bits that drive the plc outputs on other rungs (again redundant) but it exposes the workings to the observer who is looking for a stuck limit switch or whatever. I've even put in
dummy rungs that do nothing but expose input states to an observer(these rungs are commented as such). As I mentioned before, I've done a few of those compact but un-obvious programs myself, but I learned from experience. We have a lot of
complicated processes involving temperatures up to 1500C (2732F) and pressures from 10^-6 torr up through 30,000 psi and the maintenance staff doesn't always have to understand the process, they often don't, but they still run for the laptop when there is a problem, and if the area manager see them with it, he leaves me alone because they are "on top of it". That way I get my projects done and everyone is happy.

Subroutines are not all that difficult to explain to a maintenance staff. Help them understand that it modularizes the code. If you use RSLogix or even the AI series for AB PLCs, then teach them about the advanced diagnostics functions that let them quickly navigate sub routines and pages to drill right down the code to the area of
interest. Its simple to use and they will love it.

Reuse code - a must. Develop a library unless you like reinventing the wheel. If your PLC programming software doesn't support libraries, change brands.
Don't get me wrong. I document the daylights out of my code. I don't make it compact in order to be deliberately obscure. The code for my sequencers is very clear, but they reside in a subroutine. The inputs and outputs to it are in the main program and the user can look at these to see what's holding up the process when things go wrong. I'm just saying that I like to keep the inner workings of a control algorithm separate from the process details. After all, if you know that the code for the sequencer works, you need not trace through all its gory details. All you need to do is look at its inputs and outputs. If it isn't advancing to step 3, then look at the logic that leads to the step 3 permissive input. The problem has to be there. Tracing through the internal sequencer code makes no sense. It's already been tested.

This kind of gets back to my original comment about concentrating on the process rather than the equipment.

Peter van den Berg

Very good, this is exactly the concept we are using in our engineering firm. We are working with 60 to 70 PLC-programmers and we like to keep a high quality of programming standards. Since the early nineties we have developed a method for analysing and programming PLC's. And guess what we are doing: Modular programming and trying to adapt object oriented methods (alas not possible for PLC's, but you can obey the rules for object programming!).

In our approach we use the S88 standard as a guideline for both batch processes AND machine control!

I gave a good overview of the controllevels:
> 1. Lowest level hardware control of the PLC output to control the device (eg. motor)
Tools: IEC-61131-3 languages

> 2. Equipment safety interlocking to trip off the equipment in case of equipment malfunction (eg. motor overload)
Tools: IEC-61131-3 languages: make more use of SFC's

> 3. Process safety interlocking to trip off the equipment in case of process malfunction (eg. stopping conveyor to prevent product pile up due to failed downstream processing equipment).
Tools: IEC-61131-3 languages: make more use of SFC's

> 4. Auto/manual logic to bumplessly switch equipment between manual operation and automatic operation
Tools: S88, SFC's

> 5. Process related control. This generally is based on a process model that gives the program an "understanding" of the process and how to control it in terms of this model.
Tools: S88, PFC's, SFC's

E.g. S88 has 3 types of control:
- basic control
- procedural control
- coordination control
Also modes are explained (Auto, manual, step-mode, etc.) You see these items also in your stepwise breakdown of the control hierarchy.

Also the french guideline for batch control (ASTRID) can be very helpfull.

As I said before you can use the batch control standards also for machine control. There's a lot you can use and adapt for this type of control. It's important for us as an engineerings firm to make sure that the control-people speak the same control-language: S88, with it's terms and definitions and models, is very helpfull for that purpose.

There is of course a lot more to it than mentioned here, but it's about time that the design of PLC-programming comes to a more mature design-state!

Victor M. Gonzalez

Hi Peter,
could it be possible to get a copy of your company "PLC analysis and programming method" documentation if it is not confidential or classified, please?

I would like to have a look at it and I would also like to cite your name, your company name and this information in my thesis document if you allow me to do so.

Thank you!
Víctor M. González
[email protected]