A Philosophical Question - Password Protection

Hi Guys,

I have a local client who has PLC based equipment of a highly specialized nature. The OEM is not local and so the client calls me occasionally for advise or troubleshooting assistance and this sometimes includes this "highly specialized device".

Last year when this happened, I discovered that the PLC was password protected. I then asked him whether the OEM discussed licensing of propritary software during the equipment purchasing process and the reply was "no". My suggestion at the time was to request that a copy of the software be supplied by the manufacturer, but of course they refused.

Instead, they want a check deposit for $1000. before they come out to service his version of their "highly specialized system".

I now learn that another such system has been purchased and there are similar issues for which they are charged at least a $1000 per incedent for each field service excurion.

So my question: What do you guys think about the selling of systems wherein a PLC is a principal part of the device. Is it ethical and proper to sell such a system and then not provide the owner access to his own equipment without making this clear with some licensing process ?

What practices have you employeed ?

Best Regards,

Bob A.

Your client knew about the OEM's practices and they still bought a second system. That means your client believes they are getting value from the system. They're making money, the OEM is making money. Sounds like a win-win to me.

As to the ethics of supplying a PLC controlled system without providing access to the program, what's the difference between that and selling any piece of software with providing the source code?

OEM's do that all the time That's how they they make money. Get the code from them and save it. Or convert the machine to a new controller.

A subject discussed in great detail very recently here.

If they have spent a lot of money developing a 'specialised' system, they would want to protect their investment.

If it is a bespoke system developed for one customer, i.e. a conveyor system, then this in my opinion should never be protected.

Thanks Guys,

I missed the other thread, but found it very interesting. And I appreciate the thoughtful comments. I will advise my local client that he should require the password following the warrenty period and request his lawyer to get involved if it is not produced.

To put this in perspective, the system in this example is an automated watering system for a golf course. The PLC controls a remote pumping station which provides the water. When it fails, the only fall back is a few wells which are used to fill tanks on carts to be manually taken to the greens multiple times a day in the hottest part of the summer. It only requres a few days of trouble to loose the entire enterprise for the remainder of the season.

Best Regards,

Bob A.

Interesting that sprinkler control is so customized that it would require intellectual property protection. It appears to be more job security (income).

Why don't you propose reverse engineering the system and providing them an unsecured program?

Bob A. said:

I will advise my local client that he should require the password following the warrenty period and request his lawyer to get involved if it is not produced.

Click to expand...

That's kind of brazen. If the client didn't specifically request the source code as part of the system purchase price, I don't see what legal standing they would have. Even if the system were defective, there should have been some sort of acceptance period that would have exposed problems. But since they have since purchased another system, I guess that isn't the case.

I have done it both ways. I give the source code if the code is for a specific process that the customer had a big part in designing (one of a kind). But if I am providing a stand-alone system, they don't get the source code. For my part, I make sure they get very detailed feedback on their GUIs, and I don't charge for a service call or remote support if a legitimate bug is found.

Alternative?

In the case of Rockwell Software, one could install RSLadder on an HMI if available. This would provide a portal to the end user for some troubleshooting capability. Curious to hear if anyone has done this and how it's worked out...

Greg

Originally posted by Greg Dake:

In the case of Rockwell Software, one could install RSLadder on an HMI if available.

Click to expand...

I don't think the OEM is concerned that someone will modify the system and 'break' it. They are either concerned that someone will steal their 'specialized' technology or that they will lose revenue due to reduced service calls. RSLadder would kill them in both cases.

That said, I've never tried the RSLadder approach. In the cases where we have supplied an HMI powerful enough to run this the customer has also purchased a full-blown copy of the programming software and we stuck that on. However, if we ever do have occasion to use RSLadder on an HMI I think that would be a grand idea and we would most likely install it.

Keith

Bob A. said:

To put this in perspective, the system in this example is an automated watering system for a golf course. The PLC controls a remote pumping station which provides the water. When it fails, the only fall back is a few wells which are used to fill tanks on carts to be manually taken to the greens multiple times a day in the hottest part of the summer....

Click to expand...

How about some manual override switches that bypass the failed PLC and turn on the pumps?

Keith,

I agree. I guess there is also the reason from the OEM of "it's not that we wouldn't like to give you the code, it's that we don't want damage or injury caused by our equipment due to your (the end user's) modification." I don't know how much that statement comes into play, if ever.

I've been meaning to deploy an RSLadder installation on one of the plant floor PC's for the maintenance group. Just as a trial basis, gives them a little more than the electrical drawings and PLC I/O lights for troubleshooting. We have a few maintenance guys who have a genuine interest in getting deeper into the PLC for troubleshooting purposes. Again, I'm curiuos to hear if anyone has this concept in play at their plant?

Greg

OkiePC said:

How about some manual override switches that bypass the failed PLC and turn on the pumps?

Click to expand...

LOL Okie, We have a saying at work when you do that, It is called, "Lieing to the machine."

maintenanceman38 said:

LOL Okie, We have a saying at work when you do that, It is called, "Lieing to the machine."

Click to expand...

We call it HOA, but whatever.

Well in regard to overrides, etc. It is a bit more complex than that. First it is a remote unmanned pumping station and there is no 3- phase available. So this system involves rotary converters with capacitor banks and secondary motors connected to manufacturer the 3-phase required for the pumps. And naturally there is careful sequencing to do and this all happens in the middle of the night so that the water can soak in and be ready for the next day on the golf course, so it needs to be capable of fully automatic operation.

Not that it is so complex, but there are the liability issues that have been covered here on the forum, so I'm not going to get between the owner and the OEM, except to tell him that he should request a copy of the software and the password when the warrenty period expires.

Thanks again for the great comments.

Bob A.

Originally posted by Bob A.:

...except to tell him that he should request a copy of the software and the password when the warrenty period expires.

Click to expand...

Good luck with that one. If the OEM isn't coughiing up the software and password during the warranty period, when customers servicing their own stuff stands to save the OEM money, why would they cough them up after the warranty period when they could actually make money on the service calls? It doesn't make economic sense from the OEM standpoint.

Keith