Opinions about PLC passwords

controlled

Lifetime Supporting Member
Join Date
Nov 2005
Location
bowmanville
Posts
419
First off, this is not a thread asking how to reset lost passwords.

I was called to a customers plant today to do a simple modification on an slc/505. I could not get online because the processor was password protected. I called the original OEM to ask about the password, but was told that they do not set passwords, and that it must have been put in by someone else after the original install.

I found out that my customer used to get Rockwell to do any PLC changes. The only reason they called them was because they saw their name on the PLC and did not know they could hire any company they wanted. After phoning Rockwell, I was told the technician that used to come to my customers site no longer worked for them. I am assuming that it was this tech that set the password.

I realize Rockwell can help reset the password, which we will be attempting next week.

My question is this; What are your thoughts about Rockwell, or any integrator, setting passwords when they are not the original OEM or the end user? I can only assume he set the password to possibly guarontee future service calls.



Derek
 
We just went through this debate

My question is this; What are your thoughts about Rockwell, or any integrator, setting passwords when they are not the original OEM or the end user?
They should be sued for any losses caused by not being able to adjust the machine. I know in our case the customer must be able to change scale factors and offsets in feed back devices are changed. One should also be able to copy binary code so a unit can be replaced. I know that by adding password protection we have allowed somebody to maliciously lock a system as in your example.

I can only assume he set the password to possibly guarontee future service calls.
Yes, but it is a poor guarantee. We have customers that call tech support that are totally clueless as to how our product works because there have been no problems for so long that the original trained people have left. That wouldn't guarantee enough future service calls to make it worth the hassle.

We just implemented the means of protecting the user code in our motion controller. I can see the need for password protection but I don't want to get caught between the end customer and the system integrator or OEM.
 
I've never been a fan of passwords, whether established by the OEM or the end user. As an integrator/service contractor I personally would never set a password unless directed to by my customer and I would let the customer decide what the password should be.

If I were buying a piece of equipment I would insist that the OEM either divulge any passwords to me or only password the proprietary sections of their code.

If your assessment of the situation is correct, then the manager of the local Rockwell service office has some 'splainin to do.
 
I quite often set passwords on new jobs for 12 months and a day - for defects liability. It is always mentioned in the manual and the customer only has to apply for the password at the end of defects liability and it is provided to them. Also, if programming software is on a computer that is accesible this is essential in my view.

The problem I have is that if someone changes the program and blows up a diesel generator during defects liability period and I can not absolutely prove that it was someone elses fault I am liable for a new machine and probably damages too.
 
I have a question, can the program be made to delete the password or bypass the password after a set period of time as in Bob case?

I've never though about that before.

Edit MMMMMMMM Time stamped password, when waranty runs out program opens up.
 
Last edited:
Have not thought about that. I guess it would depend on the PLC and whether the manufacturer will tell you where in memory it is stored and whether the memory area is accessible from the PLC ladder or not.
 
Anything "Password Protected", or without fully documented code that shows up in this facility is returned, and the payments are cancelled.
Very simple policy.
 
BobB said:
I quite often set passwords on new jobs for 12 months and a day - for defects liability. It is always mentioned in the manual and the customer only has to apply for the password at the end of defects liability and it is provided to them. Also, if programming software is on a computer that is accesible this is essential in my view.

The problem I have is that if someone changes the program and blows up a diesel generator during defects liability period and I can not absolutely prove that it was someone elses fault I am liable for a new machine and probably damages too.

I agree if you are the OEM you should have the ability to set passwords per your example. In the situation I am talking about, this was done a third party integrator.
 
rdrast said:
Anything "Password Protected", or without fully documented code that shows up in this facility is returned, and the payments are cancelled.
Very simple policy.

That can be a very costly policy, can the comapany delay a system, maybe by months?
 
rdrast said:
Anything "Password Protected", or without fully documented code that shows up in this facility is returned, and the payments are cancelled.
Very simple policy.

Here is the "Release of all claims, direct or implied" form, please sign on the dotted line. Thank you. :)

I hear you. And feel the same most of the time. But, having been on both sides of the fence, am not so sure now. No one can guarantee that the code will not be messed with and no one can gurantee that if, God forbid, something bad happens, the OEM will not be dragged to court by lawyers.

BobB's idea of locking the code (I assume from editing, not from viewing) for the duration of the warranty period seems to be a good compromise. Of course it means that BobB would have to support his system for a year and, if there are no provisions for some kind of remote connection, he would have to travel, on his own time and at his own expense, to correct errors. Still, in my opinion, beats the option of potentially losing his house and maybe even some jail time.

Of course, once the warranty has expired, all the necessary papers are signed and the locks are removed - it is all yours now, feel free to do what you want with it. It is now your problem.
 
PeterW said:
That can be a very costly policy, can the comapany delay a system, maybe by months?

Yes. Either delay it, switch vendors, or dump the entire program and do it in house.

In any case, Password-Protected / Undocumented Vendor PLC code = No business, No payment, No Future Business.
 
The majority of companies or individuals who password the code do not do it for the reasons they state.

"It's in a guarantee period & if someone mucks it up you will blame us". this is rubbish on modern plc's nearly all have code chage datestamp so a quick check will tell you if it has been modified & put back.
"We have spent a lot of time & money developing this code".
To be honest most good engineers could produce code for any application, do they think they are so special?, anyhow it's probably quicker to write your own than decipher someone elses.
We all know the real reasons, TO FLEECE THE CUSTOMER?????
I have been involved with a supplier who protected the code, the plant was a one off, written to our requirement & charged accordingly, well as far as I was concerned it was written specifically for us at our expense so we should own it.
Any mods we wanted were costing us a fortune.
After requesting the company to rectifiy "their mistakes" plus some enhancements we found that it was cheaper to re-write it using another company & myself than their "modifications" quotation.
In short they wanted £34k to get the Scada correct (we upgraded the system + new pc) & re-wrote using another company for £25k
The plc mods they wanted £22K I did it myself by replacing one system (plc) at a time this contained 8 Networked plc's at a cost of my time although I'm already employed by them so hidden cost only.
Needless to say they lost out on a simular plant & any future work for us
We now have a clause in our specs that state any supplied equipment using plc's, Scada or HMI will be accessable by ourselves, the only exception is a standard product i.e. equipment that does not contain a PLC etc. (bespoke hardware designed by the supplier).
We now have a choice, if we feel we need access to the code then we will use a supplier who is willing, any that are not will not work for us.
 
I've worked with a large number of suppliers for equipment and the a large percentage of those suppliers want to protect their software rights. Thats one concept I always found amusing In order to steal a PLC based program yuo would also need to steal the machine design. Regardless 60% of all the suppliers I've had in this plant has wanted to protect their software for whatever reasons. Some are only concerned during their Warrenty period Some do so simply because the machine is a prototype regardless of opinions that is their legal right. The only choice at that point is are you going to use that supplioer or not under those clauses. I however do like BOb's idea on a self removing password with a time stamp.
 
I hate this attitude.

parky said:
"We have spent a lot of time & money developing this code".
To be honest most good engineers could produce code for any application, do they think they are so special?,
I will take very strong exception to this. You may not realize it but programming capability needs to be judged on a logorithmic scale and on the type of applications. Some programmers are 1000s or even millions of times better than others and no engineer can be expert in all ( any ) applications. Being good is not good enough for any application.
 

Similar Topics

With the Automation Directs Open Source Arduino Compatible PLC and the Open plc Project, plus all the Raspberry Pi HMI's, what are your opinions...
Replies
12
Views
4,307
I'm hoping I can get some input from you folks here. I have been working on and off in Automation for over a decade, mostly with Siemens PLCs. I...
Replies
12
Views
5,361
I am currently looking into standardizing my companies control options; given the simplicity and redundancy of our systems i feel like a PLC/HMI...
Replies
7
Views
2,979
When communicating between different PLCs using the messaging instruction, is it better to have PLC 'A' read from PLC 'B', or have PLC 'B' write...
Replies
2
Views
2,191
I am looking at replacing an old Eurotherm EM2 temperature control system. The EM2 controls 38 temperature loops a pressure control loop and a...
Replies
10
Views
8,687
Back
Top Bottom