|

2021 - 2022
|
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.
© 2004 Reed Business Information, a
division of Reed Elsevier Inc. All Rights Reserved.
|
|
|
© 2001-2020 VanDoren Industries, Inc. For additional assistance, email
editor@integrator.guide,
or call (765) 296-7600 to talk to a live editor.
|
|