Documentation

Can anyone tell me what in terms of documentation do they use as a standard for PLC related jobs.

Now, I know about URS/FDS documents. But i'm interested as to what other people use as their standard for developing a project program.

This answer to this question will obviously be different for different types of projects. But, i'd really like to know what sort of processes are documented, for both internal use and external.

Hope this makes sense. Maybe there is a website where I can download PLC related documents????

3am in the wee morning...

I just can't sleep with a terrible ache.

Question:
Is the documentation for submission as a report to clients or just filing?

On my view, documentation for the clients include the standard certifications, O&M, relevent information on the program, bill of material, program structure, layout schematics.
And then for filing, is detailed reporting of the program, so that others can fall back on if you do not happen to be available. I think almost the same as what I state above.

You can try to search, but everybody will have a different requirement for documents. It's really for you to find out what is your needs.

oh..now I can get to sleep..cherrio!

regards
Sherine T.

Documentation - the other half of my job.

There's really only ONE important piece of documentation that MUST be part of any project.

The Purchase Order.

Without it, nothing gets done.

---

If there is going to be a second important document, then it must be the Test Plan. Call it a FAT, a SAT, IQ/OQ, or dog-and-pony show, this document is a CYA for both the programmer and end user, if done properly.
The programmer shows that the system actually does what the user wants. The user agrees that he's getting what he paid for.

In an ideal world, this document would be written BEFORE any coding/design takes place. That way, the user REALLY understands what he is getting, and the programmer knows what he's delivering.

---

But we don't live in an ideal world.

So, what are you going to make sure that you have a Win-win situation, with the end user being happy with what he got, and the programmer not feeling like he's doing free work?

There are all sorts of systems in place. The pharmaceutical industry has settled on the URS/FRS/DDS method. Some just develop good relationships between supplier and client, based on trust, understanding, and good communication skills.

I've seen all these methods. Sometimes they work, sometimes they don't. Even the URS/FRS/DDS method falls down if the end user doesn't really read or understand what he's reading (which is not hard - the docs are usually authored by engineers, who write the docs for themselves, not others.)

this is quite a good resource.

pp