Maintenance and copyrights or EULAs for PLC vendors


Thread Starter

Nick Moon


I have a few questions for ya all. I am a recent Bachelors of Science in Electrical Engineering graduate. My concentration was more towards hardware and circuitry design but I had some experience with PLC's during my course work so I know the basics. A friend asked me if I could train some maintenance personal to backup the ladder logic program for some PLC's that came with the machines from the vendor. Also, to upload/download and make minor changes to the ladder logic program when needed. From what he has mentioned to me, they are tired of contacting the vendor for copies of the program when a machine "goes down" and to save money from bringing in a third party to reinstall or modify the program. These machines are used for making and printing on corrugated boxes.

My question(s); are there usually copyrights or EULAs that apply to the ladder logic programs that control the machinery? What would be a typical price to charge to train maintenance personnel on 2-3 shifts?

I am not sure about the rights that the third party may or may not have and my friend is also not sure if any copyrights or license agreements exist. Basically, I do not want to violate any legal or ethics issues. As a first step to check things out I stopped by here to see if you have any experience or information in this type of contract work.

Thank you for reading and for any replies.
There are copyrights on all programs, drawings, manuals, data sheets, and all sorts of other things. A EULA is a contract, so unless the company signed such a contract there isn't one.

Since however you said that the company is already receiving replacement copies of programs from their supplier (to reload the PLCs when something goes wrong), getting copies of the programs doesn't seem to be a problem. If the customer started copying the entire machines (including software) however, the supplier might object and they might raise copyright (among other things) as one of the legal complaints. However, I have never heard of a case where someone has sued over copyright on a PLC program.

I wouldn't want to argue what "normal practice" is in a court, but normal and expected practice with PLCs has been for the user to make backups and keep them up to date. Suppliers who don't want that don't normally use PLCs. However, I'm not a lawyer and this has just been my own experience and observations. If you want a legal opinion, ask a lawyer. However, a lawyer would probably just waffle on and on without ever actually giving a straight answer (they can be a lot like many engineers in that respect).

I suspect that the suppliers would actually be quite delighted if their customer would organize proper backups for themselves so the supplier didn't have to dig out copies for them on an emergency basis.

If you make backups of the PLC programs, you will want copies of the symbols and comments. Some PLCs will store these inside the CPU, but most don't so you may need an "original" copy (from the supplier) if you want the program to be easily readable. You would then compare the "original" to what is actually running in the PLC to see if anyone has made any changes since then.

On a practical basis, what you (or whoever is organizing this) would want to do is the following:

1) Make a list of all the machines in the plant, including the type of PLC it uses. Also include any programmable servo drives, HMI panels, programmable instruments, and anything else with programs or configurations (including switch settings).

2) Allocate an area on a network disk drive (I'm assuming they have a network) for storing the programs. Make sure that someone is responsible for backing up this disk regularly.

3) Make a series of directories on the drive, with one directory per machine, and additional sub-directories under each machine for each type of program or configuration.

4) Start copying the programs onto the appropriate areas.

5) While you're at it, include copies of electrical drawings, manuals, and anything else you can lay your hands one. All of these can be just as important to keeping the equipment running.

6) When an update is made, don't erase the old program. Keep it and archive it so you can go back to the old version if the change didn't work out.

There are software systems that will organize this for you, but if the customer isn't doing anything now, I doubt they will be willing to fork out the money (and time) involved for one of these systems. Even if they were willing to do so, they would still have to do all this preliminary work in order to have something to put into a system like that.

I have created systems based on just a hierarchy of directories, and it worked well enough. I also wrote awk scripts that would take a directory listing of files and turn them into a spreadsheet report that listed all the files, dates, equipment types, etc. This was quite handy for finding what was there and what was missing (for several hundred machines). That way, updating the reports only required running a few scripts which took a few seconds to run.

curt wuollet

Some people formally license the software that they create for an application. I assume this is what you are talking about rather than the programming software which _is_ generally under a shrinkwrap EULA and is implicitly copyrighted. The application programs are often handled as trade secret, and they are implicitly copyrighted as well. But, most authorities recognize backup as fair use and there shouldn't be any problem for the customer, except that they won't generally have source code, so the backup is not very useful for troubleshooting or modification. If I were you, I wouldn't start a collection of programs as, not being the customer the rules may be different. Some companies want a NDA for even a backup and can be really sticky about this and anything else they think they can sell as a service. But, if it's an issue, just have the customers people handle the software.

One thing that deserves mention from working in a shop where they insisted on these blind (no source) binary backups. That is that a pile of disks, even well marked, is almost more of a liability than an asset without both precise documentation and unfailing maintenance. There are many and subtle ways these can become worse than useless as time passes. Often, upgrading software or hardware can render them unreadable, as can aging of the media. Floppy disks are bad for this last issue. There is a really good chance that the backup made with your good old laptop won't work with the new. And if a vendor changes things either without telling you or if a new backup isn't made immediately, someone will revert the changes which can lead to a protracted panic to recreate them.....or worse. That's why I consider the no source backup plan to be false security at best, as usually practiced. It's often just a delay until the person with the source can be contacted and persuaded to reload the system. And even with source, the old hardware and old software are often needed. It's a much bigger issue than is realized. I had to fight to keep what was needed for really effective restore capability and often lost to management or IT people with conflicting goals. And when you need it, guess who's fault the downtime is? :^) One of the last brilliant moves, at a company whose name will not be mentioned out of charity, was that all software was to be turned over to IT. I didn't mind leaving all that much, It was like missing a cruise on the Titanic. If you can't own, or at least escrow, the source for a new machine, don't buy it.