What methods to ensure PLC program is error free?

DLMUK

Member
Join Date
Jun 2013
Location
Southampton
Posts
311
Hi,

I am interested to know what methods people use to ensure their PLC code is error/bug free and working as per the specification.

All of the systems I do are used in the Marine/Offshore industry but are not safety critical ones. Someone has suggested GAMP to me but that seems more suited to pharma/process control etc.

Cheers!
 
Depends how good/detailed your specification is....

Some can be very woolly, with just a basic functionality, and the code-writer or SI has to fill in the blanks using years of experience to come up with the full package, then resubmit to the client..

I have seen tables with lists of functions/alarms with tickboxes then signature box at the end.

Some I have seen, just require the basic safety functions to immediately stop the plant get tested, then can it be run in the expected sequence, does is shutdown sequentially.? Anything flashing red on the screen - no? then fine.... and it gets fine tuned over a number of operations....

Much prefer going through an I/O list, making sure they all function as expected. Fix the missings, then check emergency stops and interlocks, then run motors in manual/local (direction and/or speed range), open and close valves, then start up tentatively, following what is hopefully a written-down logical sequence.
Check the actual running out at the plant, confirm the SCADA shows what is expected. Then go for it.....
Any faults/alarms that should shut the plant, activate them where possible - if not possible, then simulate them.

We do not always get time to try all of these due to pressures, but cover as many as practical in the time given.
 
Hi,

I am interested to know what methods people use to ensure their PLC code is error/bug free and working as per the specification.

All of the systems I do are used in the Marine/Offshore industry but are not safety critical ones. Someone has suggested GAMP to me but that seems more suited to pharma/process control etc.

Cheers!

You wont find one unified approach to this but following the Internal Test, Factory Witness Test (against test rig of field devices if required) then Site Acceptance Test and finally Integrated System Test, those 4 in combination should be enough to show any bugs and ensure programmed code is working correctly to expectations.

These loosely follow the 4 levels of software testing: http://softwaretestingfundamentals.com/software-testing-levels/
 
Last edited:
When we are doing controls, we often try to grab someone not related to the project and have them run the machine and try to "break" it. They throw strange button press combinations at it. E-Stop in all phases of the system, try to put in unexpected data to operator fields in HMIs. You get the picture.

This isn't fool proof and definitely doesn't cover everything but it does get at a lot of issues that could be bad on the customer floor.

Of course you have to keep safety in mind at all times and not really break anything mechanically if you can help it ;-)
 
When we are doing controls, we often try to grab someone not related to the project and have them run the machine and try to "break" it. They throw strange button press combinations at it. E-Stop in all phases of the system, try to put in unexpected data to operator fields in HMIs. You get the picture.

This isn't fool proof and definitely doesn't cover everything but it does get at a lot of issues that could be bad on the customer floor.

Of course you have to keep safety in mind at all times and not really break anything mechanically if you can help it ;-)

Absolutely. Try as many different ways as you can think of to f*** up the system, then go find the worst operator you can and tell them to do the same thing (y)
 
Usually, the functionality is fairly easy to test as it will have a sequence and a desirable outcome.

The main thing for me when it comes to testing is pretty much failing one thing after another and confirm the system reacts safely. What I find interesting is that some people in the automation world (noticeably more on the SCADA side) can't comprehend that what bothers me is that someone can get hurt or that the system won't handle a single failure.

I remember commissioning a winch and it was about 4 pages to test performance and about 50 to test failures and failure responses... but many people only think of the core functionality requested in the original scope.
 

Similar Topics

Greetings. I want to install a PLC with servo and photocell. For a plastic bag cutting and sealing machine, logically it will work with printed...
Replies
2
Views
91
Hello, I have somewhat minimal experience tuning PID systems. Ive done a small servo controlled camera gantry. In the process of tuning sometimes...
Replies
4
Views
3,102
I would like to use this thread to ask for opinions on methods/practices. I am starting on a fairly large complete rewrite of code for several...
Replies
11
Views
2,373
Good Evening , I have a Conveyor system that requires Speed Cascading from one conveyor to another. Meaning that if one conveyor speed is...
Replies
10
Views
2,543
so, im interested in hearing some secret tips people may use to stay organized and on task when writing a program from scratch. I do the typical...
Replies
12
Views
3,546
Back
Top Bottom