A typical PLC program will be read and modified by many contributors during its whole lifecycle: development and commissioning teams, maintenance and modernization technicians and engineers, project managers, etc. All will have to easily and quickly understand a program they often didn’t develop themselves, especially if they start a new job from some legacy code. Being efficient when modifying some sophisticated and unknown code is always a challenge. Thus, any accompanying document is welcome.
The code is often only available documentation and it may be poorly commented. Also, they generally are a mere high level view and linking them to the actual program may be tricky when some specifications are available. Even if a documentation has been written properly along with the program, it has to be maintained when the code is modified which is costly and frequently neglected. The worst situation is probably when there was only a physical the documentation copy which became unreadable because it was not stored properly.
Working with an undocumented program is always a major loss of time:
♦ Commissioning teams miss a clear link between the algorithms and functional specifications in the code, thus wasting hours during setup and debugging.
♦ Maintenance technicians, working in end-user’s PLC controlled facilities, must be able to quickly fix erroneous programs so that production may restart as soon as possible. Thus, they need a documented clearly high level model of the behavior of the program.
♦ Modernization wanting to convert and potentially re- write a existing legacy program for a more current hardware shall refer to the original specification and design documentation to make sure that they stay consistent with the intended of the system behavior.
♦ Finally, project managers which have to estimate workloads based on high level specifications may not be able to fully understand the actual complexity of the job if they don’t have access to a more detailed documentation closer to the program itself.