Beyond the drawings: Why a holistic commissioning plan is critical for project success

During commissioning and after, if you hear three definitions of I/O checkout and then get residual failures after a down and an install because no one is going off a commissioning plan, writing up a test plan or adhering to a commissioning plan, then there is a problem.

The project manager gets told by the integrator, “We just test off of drawings.” Are drawings enough? No.

Operations engineers keep complaining that the integrator should have done x, y and z and seen if a circuit was normally open or normally closed.

Chief engineers tell the project manager that the front end loading resulted in a good design and cost, though no one can evaluate 300 drawings in four hours adequately.

The integrator complains that the bus they needed to test for functionality was not powered up during the commissioning time that they were on site for. The person that catches it is the electrician that cares, but why burn them out?

Usually, these kinds of issues can be traced back to lack of commissioning or I/O test plans and or lack of adhering to requirements. Eventually, it affects safety, costs and installation. Why? Requirements definition was not adhered to, and, to force the project, corporate engineers put schedule before quality. That puts the project manager in the middle of a tug of war and a no-win situation. Balancing scope, spend and schedule should be everyone’s priority.

The project manager must weld together the corporate engineer priorities, the integrator priorities and the operations engineer priorities back to the commissioning and to the forward progression of the project. No system is going to be installed as perfect, but if the responsibilities of individuals involved do not adhere to moving the project forward, failure is imminent. Thus, slow the project down and reset the boundaries. Define people, system, circuit and device for commissioning.

People: People define who the machine is for. This includes who is operating the machine and who is going to maintain the machine. It also means who is purchasing the machine and who is installing the machine and programming the machine.

Too many times, the feedback or complaint is only from the perspective of which group the person fits in. For example, a software guy can say Activity A takes two hours. He has no comprehension of the time it takes to get locked out, installed, unlocked and set up for testing his part that takes two hours.

The project manager must account for that in scheduling. The commissioning engineer must adhere to making the schedule work. Thus, you need them both to buy off on the commissioning schedule and where things are put in the schedule.

You also need the technician to be ready. If the commissioning engineer does not care, then they will go to lunch instead of unlocking a circuit so that you can proceed with your activities and do not have contractors standing around.

This is not on the drawings for I/O checkout. This comes with understanding the people involved in making a cabinet work and integrating hardware and software.

System: That brings us to system definition. If a commissioning or process engineer looks at a pushbutton as a motor start or an actuator extension only, then they lack the insight on the whole circuit. A systems perspective forces people to look at the button in context.

A drawing of inputs will show a discrete button that is tied to a 24-V loop, and that may be symbolized on the drawing as momentary. Thus, in the code it must be sealed in if it is to start and run until stopped. What if it is a pause button? What if it is normally closed and it is a stop button? Functionality of the button should be in its label on the drawing and indicated by its symbol on the drawing. This is fine if it matches the code.

Commissioning means matching the physical system to the software system. This means commissioning engineers need to know the software and the hardware configuration, as well as the context of the machine functionality to include states and safety. Thus, write a commissioning plan with steps that evaluate each button, whether hardwired or in the human-machine interface (HMI), so that the circuit can be validated physically, electrically and via software.

• physical/mechanical: placement, button type, color, indication, normally open, normally closed 
• electrically: wire code, placement, relay response, safety
• software: sealed, not sealed, cause/effect action required with the button push—system context; normally, this relates back to people via HMI indication and machine action. 

Will a commissioning plan provide the context of the control circuit? A commissioning test plan would show the circuit in context of the system and not just the physical connections as seen on a drawing.

Get your subscription to Control Design’s daily newsletter.

Circuit: Controls engineering involves loops and circuits. There are an inputs and outputs—thus, command and feedback. Even a simple button on the panel or an HMI should be put into context of the system, as in what happens when the button is pushed in relationship to manual mode, automatic mode and to where the button shows up on the HMI, as well as what it is controlling and the permissives and safety that allow the button to actuate a response.

The context of how the button is used in the software and its effects are not on the drawing, which is why the circuit needs to be looked at in context of the machine. This relates back to engineering specification and design specifications, as well. Device is the last category, in that if you are sending a signal to a device to have it do something and expecting feedback, then the signals from/to the programmable logic controller (PLC) must match the input/output to the device.

In the 1990s and early 2000s, controls engineers did computer-aided design (CAD) drawings and the hardware specification and the programming, so they knew the component and how to talk to it on commissioning.

The complexity of systems now means hardware, software and commissioning are split. The funny thing is the electrician now wants to know what device they are wiring to because the blame has shifted to them on install when the hardware, software and commissioning engineer throw their hands up or say, “I’ll get back to you.”

Device: Why do electricians see the device as important? The circuit will be wrong if it does not match the device. The device dictates what kind of inputs and outputs it needs. It also dictates voltage value or current and whether it’s PNP or NPN.

If the device does not match with the PLC card expectation, then the circuit fails. On the other side of the PLC is the HMI, and this is part of I/O checkout. Our previous example was a discrete pushbutton. Analog circuits require scaling, and the scaling must match from device to PLC to HMI. If it does not, the circuit fails.

Understanding the context of devices in the control system in relationship to machine functionality and ancillary functionality and how it integrates with operations and safety is key.

In conclusion, a good commissioning team will consider the scope of the project, and the commissioning engineer will look at an installation with the perspective of how the machine components being installed work in relationship to people, system, circuit and device. This can be related back to a drawing if the installation drawings are complete and adhere to standards.

Most likely, all these items will not fit on a drawing, and quality will be minimized for schedule. This means commissioning planning must be done to merge the different priorities of the hardware, software and operations engineers with project objectives. Otherwise, the people involved will not work together, and project objectives and commissioning will fail.