Is project documentation an afterthought? Does the documentation stage of a project seem to be a tedious process? Does the customer understand the importance of proper definition? Documentation is likely the most important part of a project.
Project documentation used to define the plant process and functional requirements of the automation system. It will give both the customer and the engineer the opportunity to mentally work through how the system should operate before any code is written. It provides an opportunity for collaboration and review. Proper definition will always make your projects more successful.
Have you ever worked on a project where you were handed only a P&ID drawing and were told, "I want you to program this." Project definition can be the difference between a successful project with a happy customer or a nightmare that you just want to end. While project definition comes in many forms, the end result should be to provide information to customers and engineers on how the process works and what functionality is required. Definition could be in the form of a User Requirement Specification, a Functional Specification, a Detailed Design Specification, or a Control Narrative. Project definition can be provided by both customers and engineers. There should always be an appropriate amount of time allowed for all parties to review the documents and update as required. These documents should be considered living documents that will be updated as required throughout the full project life cycle.
A User Requirement Specification and/or Functional specification will generally be used to define the process and functionality from a high level. This should include a process description, the equipment to be controlled, and general process operation. It should also include hardware, software, and functional requirements. The Detailed Design Specification and/or Control narratives will be written to give a very detailed view of the automation system. These documents should be designed with the intent of giving the engineers a complete understanding of what is to be programmed. These documents should include a general description of the process being controlled. They will include a definition of the equipment being controlled including features of each device, for instance, feedback and fail positions. The detailed design document should include information on required alarms, permissives, and interlocks. You will also want to include the steps required to operate the process. How does the process start? How does the process stop? Will the process change modes while running? What should happen if the process needs to stop immediately? You will also want to include any parameters that will need to be entered to operate the system.
The more time we spend on definition the less time we will spend on reprogramming. Always take the time to review project definition with your customers and project team. Remember that project definition should be treated as a living document and should be updated as needed. Remember to review all updates with your customers. If we do our due diligence during definition, we can avoid the nightmare.
This post was written by Jeff Haywood. Jeff is a Senior Engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. Maverick delivers expertise and consulting in a wide variety of area including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.