Automation project documentation

[redeemer 0]

Dear all, What kind of documentation do you find essential for automation projects. I'm also very interested in any standards concerning the format and types of documents that should be prepared for an automation project. Regards

[redeemer 0]

[gravitar 3]

My work has been with the Big 3 automakers, and they all have a detailed spec for what the supplier is to provide. Most of this relates to the drawing package. Each has a particular format they expect the suppliers to follow. The documentation for the PLC logic and HMI screens is pretty much what you would expect, simply the hardcopy output of the report generation function in a 3-ring binder. I've found that documentation for smaller programmable devices (like standalone temperature controllers, "red lion" style displays, etc) often falls through the cracks and gets overlooked however. Ideally, everything should be recorded that was done to the device from when it was taken out of the box to when the system was commissioned. This becomes a problem when the hapless field tech is called out to repair/replace one of these devices, and finds out that noone at shop remembers what they did several years ago to make the blasted thing produce useful output! Its customary for panel builders to gather up and include the installation instructions and user manuals, usually in a box in the bottom of the panel, to include in the documentation package. (Did I answer what you were asking?)

[panic mode 246]

You should be more specific. There is number of things to consider and most of them will be mentioned in any decent customer's spec (such as their own plant standard). In fact I like not to ask too many questions anymore or we may end up building things based on preference of someone's uncle's friend's neighbour's mother in law etc.

[redeemer 0]

In part, yes. But.... There are two reasons behind my question. The first is that, while most of our customers don't have detailed standards to what they need, we, nevertheless, are striving to do our job in a decent way. The other reason is that we are trying to find a consistent way to create our projects. The idea is that creating the project should be through creating specific documentsa along the way. This should make it easy to get new people involved with a project that was started by someone else. So what I was looking for is a set of specific document types that should be created throughout the life of the project. On a side note: it might be that what I'm trying to achieve is unrealistic. I tend to go that way a lot. But I'm trying to balance a methodological way to create projects with the unpredictable and different real-life requirements.

[motion guru 0]

If the customer has no standard - and you want to do your job decently . . . then put yourself in the shoes of the customer and consider what you would need to know in order to support the machine long term. We have a full time technical writer on staff who is not very technical - which works well from the customer's standpoint because if she can figure it out well enough to write about it, likely the customer can read what she has written and follow along well enough to get done what needs to be done. We design and build high-end motion and coordinated drive systems that typically have a ControLogix PLC and multiple HMIs - a mix of ControlNet and Ethernet and sometimes DeviceNet networks, Safety Systems (sometimes including a Safety PLC) bla bla bla. We have manuals that describe in detail including screen shots on how to back up and restore the configuration of each device - including the drives. We assume they have almost no experience in doing this and write at a level of about 8th grade. When we have an instruction manual for the machine - we write from an operators perspective on getting the machine set up and making routine changes to the machine. So often manuals are written like "This is the main operators screen, it has the following controls . . . bla bla bla." This tells people about each of the features of the HMI, but they don't have a clue how to make a product change. Regarding prints - you should have good electrical diagrams - the device names on the prints should match the tag names in the PLC database. Your choice as to whether you provide the prints in a native CAD format or in PDF format. Regarding individual component data sheets - by all means supply them. We provide a hard copy of everything in a binder - then we also scan everything to PDF files and burn a CD. We use a program called Frame Maker that has conditional switches in it to develop system documentation - it allows you to write a full featured manual that references other documents to include and index appropriately at will - it is a lot of work to set up, but once you have done the hard work up front, manuals of high quality are a snap after that point. Manuals and documentation are a huge investment that is rarely appreciated for the amount of effort required. However, once you have made the investment - the customer is better able to support themselves and as such is less likely to suck up your time doing support when something happens down the road.

[redeemer 0]

Thank you motion guru for this summary. But if I may ask, this binder of yours, what are it's main sections. Are there any overview block diagrams of the system? Architectural plans for the factory floor and where elements are installed, a glossary of terms used.... etc? In my original question I was asking about the different document types that could (or should) be included in a project documentation and where do they figure in the lifetime of the project. Anyway, thank you again. Cheers

[motion guru 0]

We typically provide two general binders for each system: 1.) Operators Manual - describes how to run the machine, definitions for each of the alarms, HMI description - mostly oriented on the Process that the machine controls or performs rather than how it performs the process. This would be analogous to a manual that tells you how to drive your car rather than a manual that tells you how to fix the engine in your car. 2.) Technical Reference Manual - describes the technical details of the machine. Should include the following: General Overview including major control system elements Processor specific item descriptions (sections of PLC, HMI, Drives, Motion Controllers, Safety System, Etc.) Troubleshooting guide Save / Restore Instructions Appendix including - schematics, code listings (as appropriate), cut sheets from individual components or additional manuals for non-standard items This is just a suggested format - our format changes depending on the size of the project and the experience level of the customer . . . as well as how much they value documentation (are they willing to pay extra for good documentation). Again - put yourself in the customers shoes - ask yourself, "what would I need to support this system if it were to break down and I needed to troubleshoot and fix it?" A big topic - and lots of flexibility in how you address it.

[redeemer 0]

Thanks again, Currently we provide the following: A user's guide: it includes general operation and any error messages and configuration options. A binder with the diagrams, these are electrical, panel layout and terminal block diagrams. Any special equipment documents. Internaly, we keep the original programs and some design documents, but these does not have any standard format (PLC program files, some spread-sheets, and the like), I was trying to figure out a set of documents+formats that we can stick to. Just an idea!