The Anatomy of an Automation System Integration Project

Vance VanDoren - 12/15/1995

There are as many methods for designing and implementing industrial automation systems as there are engineers who work on them. The scope and complexity of an automation project can range from a simple thermostat to a plant-wide, fully automatic control system. There are, however, certain elements of the development process that are critical to the success of any project.

Plan ahead

Planning is arguably the most important of these. An old military maxim states that "Proper Prior Planning Prevents P--s Poor Performance". The same could be said (without the expletive, of course) for industrial automation projects. In its simplest form, a project plan states what is to be done, who is to do it, and when. This is particularly important for projects that are to be implemented by third party engineers. Although everyone who works in the soon-to-be-automated facility may know what the proposed automation system needs to accomplish, the contract engineers or system integrators hired to make it happen may not. A thorough plan that all parties accept as definitive and do-able can save considerable time, effort, and finger-pointing as the project progresses.

The project plan tends to become more elaborate as the scope of the project grows. The installation of a single PLC may require a plan that simply outlines the functions that the PLC is to perform, the corresponding assignments to be completed by each of the engineers involved, and a timetable for the completion of each step. For a plant-wide automation system, however, the project plan may occupy several volumes and specify the details for each of several phases of the project. It can include reporting procedures, organizational charts, contingency plans (to cover unforeseen events such as equipment shortages or natural disasters), alternative implementation strategies, approved vendor lists, and specifications on each party's financial responsibilities.

Put it all on paper

Once a realistic project plan has been approved by the project's management team, the real engineering work begins. A preliminary design is developed to show how the completed automation system will work and how it will accomplish the objectives outlined in the project plan. Ideally, the preliminary design should be generated by the engineers who will be responsible for implementing it -- the in-house engineering staff, the contract engineers, or both. Although the management team can certainly make valuable contributions to the design, they should refrain from influencing the work for strictly economic reasons. Their financial concerns should already be addressed in the project plan. It is the engineers' job to translate the plan into a workable design.

The preliminary design need not include every last detail about wiring connections, program code, hardware placement, etc. Those specifics are generally deferred to the next step -- the detailed design. The preliminary design should show roughly how the project plan is to be implemented. The detailed design fills in the particulars. It is not particularly important to decide which elements of the design belong in each document so long as the entire project is completely described and well understood by all parties when the design is complete.

Make it so

Implementation comes next. If the design documents are done correctly, the implementation phase becomes a matter of following the design's recipe for assembling the pieces of the system. There is a tendency, however, to start the implementation as soon as the equipment becomes available, even if the design isn't quite finished. After all, running wires and installing loop controllers seems like better progress than churning out more paperwork. End users tend to be especially eager to see their hardware in place. Unfortunately, attempting to satisfy the end users by beginning the hardware installation prematurely can end up causing the engineers more trouble than it's worth. A four conductor cable may have to be replaced with a sixteen conductor cable if a last minute change in the design should call for additional sensors at a remote location. A thermocouple module may have to be replaced with an RTD module if it is decided that the PLC needs to measure a temperature with greater accuracy. These design decisions may only come up at the very end of the design phase when the rest of the automation system has been defined. Even seemingly simple changes that are easily rendered on paper can be extremely difficult to implement once the hardware is in place.

The details of the implementation phase vary from project to project. Perhaps the only common factors that all automation projects share are the ever present deadlines. Deadlines for reaching each milestone in the project are generally specified in the project plan to be sure that the project continues to move forward. Missing or "slipping" a deadline is not uncommon since the full scope of the project may not be evident early on when the project plan is being developed. However, a realistic project plan will schedule extra time for unexpected delays and for tasks that prove to be more time-consuming than originally anticipated. Any slippage beyond that margin generally results in a financial penalty for the engineers, especially if the work is being done under contract by an outside engineering firm.

Turn the lights out when you leave

If and when the project is eventually completed, the time comes to determine if the end users actually got what they wanted. Acceptance tests are conducted to assess the performance of the automation system. Does it perform the required functions? Can the operators use it? Is the documentation complete? Is there room for modifications and future expansion? The questions that are to be answered by the acceptance test should be clearly delineated in the project plan. Unless the end users and the project engineers agree up front on how to determine when the required work has been completed and if it has been done correctly, the project will never end. Although the end users would probably like to have the engineers on call making improvements for the rest of the system's lifetime, the engineers must be able to stop working on the project at some point in order to move on to other jobs. This point is often overlooked when the engineers are employed in-house since they work for the same company as their customers. However, the company's other automation plans can be seriously jeopordized if one department monopolizes the efforts of the in-house engineering staff.

All that remains once the acceptance tests are complete is the final sign-off. This sounds easy, but it can be difficult to get all of the parties involved to sign a document stating that the project in its current condition is as complete as it's going to get. Even the engineers who should be looking towards their next assignments at this point are often tempted to make "one last adjustment" before calling it quits. Unfortunately, there never is just one last adjustment to be made in an industrial automation system. Fine tuning the system's performance is an on-going effort that can last throughout the system's lifetime. A well-designed system will make provisions for future changes, preferably changes that the end users can make themselves. It is the final sign-off that marks the point when the engineers' work ends and the end users' work begins.

Remain flexible

The steps outlined above are by no means cast in concrete. The order of execution can be varied to fit the project, and some steps can be left out entirely (e.g., a single design document is often sufficient for a smaller project). Perhaps the most common deviation from this sequence occurs when the end users change their minds. Unforeseen budget constraints handed down after the project plan is approved may require postponing or eliminating certain elements of the project. Plant personnel may realize during the implementation phase that another element must be worked into the design in order to make the rest of the system work. For whatever reason, there are almost always occasions when the project must be moved backwards through the execution order rather than forwards. No plan is perfect.