Hi all.

I write the programs for our PLC's (Siemens S5), and are also responsible for fault finding on the PLC's. The problem that I have is that if I'm not available (on leave, sick, whatever!), other
personell do the faultfinding. Sometimes they think that there is something wrong in the program, and they change it. Thus far, fortunately, no serious damage was done, but I'm afraid to think what might happen. Is there any way that I can protect the programs from being changed by anyone, and yet at the same time allow them to do faultfinding with the computer?

 

Rene
Have you analysed the reasons why the client keeps messing?
Before you go down the path of locking out other people from changing the software (a bad idea IMHO,) can you assure us that:
* The problems that cause the user to mess with your software are not (at least often) faults in the software itself.
* Your software is well documented. IE not only detailed comments in the code and a good naming system, but also a description of the structure and design of the software.
* Your software provides proper diagnostic information so that users can see what is causing the failure.
* Your software includes the necessary facilities for Operators (not programmers) to get around problems that arise. For example if a limit switch fails can it be overriden without changing code?
* There is a version management system in place so that for example changes and the reasons for them can be tracked and previous versions restored if necessary.
Francis
http://www.controldraw.co.uk

 

The best, though not the cheapest solution, is to replace the the RAM memory with EPROM whilst you are away. This way the program is fixed but troubleshooting can take place.

 

Hi Rene,

there are 2 possibilities:

1. Offical S5: Burn the program into S5 EPROMs. Make a allover clear (Urloeschen) and start the PLC with the EPROM inside. So everybody can use "status" to watch the programs but he is unable to change the program (the status of the OBs, FBs, etc. is EPROM).

2. Write a S5-Function-Block (FB) to protect the program. You will need some experience in programming with pointer-structures in S5 code. The FB has to set in the "directory-structure" of the S5 one of the statusflags of the PBs, FBs and OBs to the status Eprom.

I´ve done a procedure to "Re-Protect" S5-Programs for another company, so they can use Teleservice-Modems to reprogram S5-PLCs worldwide of
their customers then there are EPROMs inside.

For more informations can you contact me:

[email protected]

Greetings from germany

Helmut Meissner

 

At 11:55 05/07/00 -0400, Francis Lovering wrote:
<clip>
>Have you analysed the reasons why the client keeps messing?
>Before you go down the path of locking out other people from
>changing the software (a bad idea IMHO,) can you assure us that:
>* The problems that cause the user to mess with your software are
>not (at least often) faults in the software itself.
<clip>
This is a very good point. Perhaps Rene Venter might look into addressing the cause rather than just the symptoms. I have found the
following items to be very useful in avoiding having to use a PC for troubleshooting.

1) Add an operator panel (e.g. Siemens OP17) to provide complete and detailed diagnostic messages. The alarm system in the Siemens OP series (especially OP7 or OP17) is very easy to use, and messages can point to which sensor or other input is holding up the machine (include the actual input number in the message). If routine problems can be found without having to use the programming software, then the computer never gets brought near the machine to begin with.
Make sure the normal operating screens provide indication of any non-fault conditions which prevent the machine from running (e.g. no parts, waiting for handshake from ajoining machine, etc.).
The cost of a decent text based operator panel is fairly low. Don't pick out a model based on just size or cost. You could easily spend several times as much in man hours trying to make an undersized model work as what you saved on the purchase price.

2) Provide a means of "resetting" the PLC logic via the operator panel. This is implemented as a guaranteed (though not necessarily quick or
easy) means of resetting the program back to a known state. This is not a routine operation, but it provides an operator a last resort way out of a
problem. Make sure it deals with all flags, words etc. which retain their values, and make sure it is absolutely infallable.
If all programs were bug free and every problem was forseen then this feature would not be needed. However without it I have found that
maintenance electricians would commonly reload PLC programs simply as a means of getting the memory (flags and words) to reset because a machine will refuse to move because of a difficult to find programming bug. This feature has proven to be handy so far on new equipment, and gains time to fix minor program bugs without creating a regular crisis.

3) Provide a screen in the operator panel which allows people to adjust timer and counter presets, variables, select options, etc. without
making program changes. This has the additional advantage of making start up and fine tuning of a new machine much easier and quicker (this alone pays for the minor effort involved several times over). Many program changes typically get made simply to make minor adjustments to fixed timer presets. If you let the operator (or other personel - these variables can be easily password protected) make the adjustments then you avoid the program modification cycle. Making these presets fixed program constants (as is typically done) does not prevent people from changing them, it just makes it more difficult to find out what they changed.

4) Make sure that normal manual control of the machine provides enough functionality to get out of jams, make mechanical adjustments,
perform calibrations, etc. This item is probably more work than all the previous ones put together.

Having done the above a number of times now, I would never consider building (or programming) a machine any other way.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************

 

Thank you very much to everyone that has responded to my question on if it is possible to protect a Siemens S5 PLC program from being tampered with by unskilled personell. You have given me a lot of information that I can apply in our plant, and I am gratefull for that. The only problem is that, taking into account all that you have said, I still don't know if it possible to protect a program (except from using EPROM's, which is not very feasable in my case).

 

I would consider the technique suggested by Mr. Helmut Meissner in his reply. Tampering with the block's header can make them read-only, I experimented it some years ago and, as far as I remember, it worked.

regards
Luca Gallina

 

Hi Rene

You may have missed one message which gave you a hint as to how you may do this. There are a few methods, none of them are standard recommended
operating procedure. Someone replied with a suggestion about manipulating the block headers, there is a bit in the header of every block which
declares the contents of the block to be "valid in Eprom" or "valid in RAM". As I understand the mail of which I am thinking, the author proposed that switching this bit to indicate that the block is in Eprom and not RAM would restrict access to the block. I think he is correct however I have never tried this. Additionally there are other things you can do such as putting a jump to outside of the block, into an early line of program code, and then using JU to jump over this line, this has to be done in the output address mode of your programmer. It will cause the programmer to bomb out if an attempt is made to inspect the contents of the block. Another frequently used method is to insert the machine code for a block end in the second line of the program, also with a JU statement to get past it for normal operation. Yor programmer can't handle that one either.

In short in S5 there are no passwords for protection as there are in S7, the CPU's don't seem to have any specific codes which identify them as unique, and short of using an Eprom or doing some fancy programs to self regenerate
the important parts of the program, the answer to your question is no.

Contact me at 035 789 9956 if you want to discuss this.

Regards
Donald Pittendrigh

 

You've had several good responses. Now, I'll throw in my 2-cents.

I work in an environment where the Old Guard has just recently started moving on into greener pastures. I still have to deal with a few new guys in the trade that are not very savy in PLC's.

The system I'm using is a TI-505. When I first started working here I had exactly the same problem you describe.

Anytime the Old Guard guys ran into a problem, they would simply bypass the PLC!

The new guys would go in and change code, even though they didn't know what they were doing. They just kept hacking at it until it sorta-kinda worked.

Good Code is Good Code!

It didn't take me long to realize that those guys were only doing what they had to do to get the damn thing running!

The reason they had to do what they did is...

The code was not good!

The code was extremely unreliable! The system had to run in precisely such and such a manner for it to run at all! If the process made the slightest deviation from the required path, the process would hang. And the worst part was, no one would know WHY it hung!

So... there was not much reason for anyone to have any faith in the control system!

Their favorite refrain was "Things were a lot better before this PLC crap! At least we could do what we needed to do!"

So... the main reason that I was having the problem that you described was because the process control system had little to no credibility!

In other words... the problem was not that these people were doing what they were doing; rather, the problem was that they were being put in the position of having to do something! - BAD CODE!!!

So, I spent the next 12 months trying to rebuild confidence in the process. The program is 350 pages long! The machine is 4 stories tall and as long as a football field!

The whole deal is...

1) make the code solid and fault tolerant!

2) provide continuous status of the system.

3) organize your status info so it serves as a troubleshooting tool!

There is a general inverse-relationship rule in programming:

Easy for the Programmer = Hard for the User!
Hard for the Programmer = Easy for the User!

In other words... minimalist programming methods used only to get the damn thing running will always cause problems in the process - which will cause those people to do whatever they need to do to get the machine running!

Your goal should NOT be to prevent those people from changing the code - rather, your goal should be to prevent them from thinking that code changes are necessary!

This can only happen with solid code that they can trust and with code that helps them find the real problem!

I think you have a lot of work to do!

Terry