The following discussion is part of an occasional series showcasing the ISA Mentor Program, authored by Greg McMillan, industry consultant, author of numerous process control books, 2010 ISA Life Achievement Award recipient, and retired Senior Fellow from Solutia, Inc. (now Eastman Chemical). Greg will be posting questions and responses from the ISA Mentor Program, with contributions from program participants.
Mike Laspisa has spent 37-plus years working in the instrumentation and control (I&C) discipline, including 32 years as a lead I&C engineer or manufacturing plant staff I&C engineer. Mike’s primary motivation is to advance the automation profession by sharing knowledge gained from plant experience as seen in Control Talk columns, “Instrument specification: Where we are and where we should be,” “I&C Construction scope,” and “Instrument Index Insights.”
This area has historically been a source of many problems. The equipment packages are typically owned by the Process Mechanical group. I/E discipline input is requested in various forms (either attachment or as a stand-alone guideline spec.) during the Equipment Package specification preparation phase. However, their input is rarely requested during the bid technical analysis and vendor recommendation stages. Vendor drawing approval is more often than not the first chance to see what was actually purchased as part of the “package.” Verification of specification requirement compliance and project device tagging structures is usually difficult to do at this stage.
Packaged System initial design and drawing review topics/questions that can impact both engineering and construction on most projects:
Once identified, these issues can be difficult to get resolved. Multiple parties (Vendor, Engineer, Client) usually need to be involved because of the potential impact on project cost and schedule.
Sometimes the end user or engineering, procurement, and construction (EPC) company does not specify in a proper way the requirements to integrate in a “seamless” manner the skid package to the rest of the plant. Therefore, the package vendor performs the job as usual. Other times, there are good requirements, however the package vendor does not fulfill them at 100%. Most of the time, things not done previously are resolved during a very exciting commissioning stage.
I have had several experiences related to lack of naming convention, inefficient communication mapping, or even worse: Seam solutions. Most of the time processor, I/O, power supply, and/or communication redundancy is not specified and not even considered. Sometimes there are grays in the contract that result in no clear boundaries and no clear scope.
Hunter and I discussed our experiences and provided key alerts and extensive guidance in the Control Talk column, “8 rules to avoid skidding accidents.” The packaged equipment supplier goals are often at odds with the practitioner (project E&I professional and end user). The primary goal of winning the bid results in the use of cheaper measurements and valves, local controllers, and pressure and temperature gauges and switches rather than ensuring the most accurate and reliable instrumentation that provide signals to and from the control room, enabling complete control and monitoring.
Also, the need to make the package compact often leads to insufficient straight runs for flowmeters and distances for mixing of streams for electrodes and thermowells. The packaged equipment supplier expertise and understanding of the implications in terms of performance and maintenance is often missing. The practitioner needs to be proactive in essentially designing the automation system including the installation details. The practitioner may need to be able to justify the increase in packaged equipment price and delivery date to plant management (no easy job).
As you mentioned, you and I provided a lot of good suggestions for dealing with this issue on the “skidding” article in Control Talk.
To piggyback on some of Mike’s comments, here are some potential major software issues:
When all is said and done, I would strongly suggest that all of the communications be thoroughly tested at the manufacture’s site before the skid is shipped. Bring a spare plant controller, set up the communication network, and prove the data transfer is correct and all of the commands work as expected. Do not let the vendor ship the unit until it has passed these tests.
Being that I have had the fun of working at a number of sites that are “skid” built, there is no end to the possibilities one can run into. At this point, I see that a number of concerns about communication, tags, data sets and programming capabilities have to a good degree been captured.
However, I have a number of pet peeves with skid builders, especially when a detail set of specifications, standards, and other associated documents detailing the clients preferred direction are all but ignored.
One of the major concerns I have run into has been that the skid builders try going for a cheaper alternative or solution. Well, nothing worse than having devices mounted on the skid you are purchasing that don’t follow your client’s preferences. And unless it says that alternatives are acceptable, trying to get those items corrected usually ends up as an additional cost. Be it transmitters, valves, cabling, sensors, etc.
To add to this, even if you have to accept what you are given, sometimes getting a clear specification on what was installed may not happen.
I have also run into issues of material compatibility. I have seen it done on many applications (including code issues) that the skid builder substitutes with what they call their “floor standard,” having totally disregarded the client’s specification for said application.
Then there is the “practice;” that is, the how or why did they install that device in that location. Too often I have seen devices, especially instrumentation, shoehorned in such a manner that to extract the device (if maintenance was required) would be with a blowtorch, pry bars and a couple of handy gorillas to get said device out.
And the list goes on.
So, if the E/I team is not part FAT or any other skid selection criteria, but there will be a requirement for E/I devices to be part of the skids, then I place several requests before the construction acceptance and commissioning team, especially if they don’t want any hiccups during commissioning.
What I have asked for at some sites is that a receiving and inspection area be setup to perform a QA and deficiency list prior to accepting the skid. This gets sent to management to resolve. Sometimes the skid builder has to correct the found discrepancies. At other teams, we have had to accept management’s decision and work with what we get stuck with. I just make sure to document everything.
Here is a list of things I usually go through when it comes to “skid” provided equipment.
PRE List:
RECEIVING List:
PRE-COM list for turnover and buy:
As you can see, when it comes to a skid, does the device communicate? That is only one of the issues to contend with. And yes, I have run into issues with scaling factors, range ability, interlocks, setpoints, voltages, etc. Just makes it part of the additional challenge that we get to work with.
Quite a lot has been covered already by Mike´s, Greg´s, Hunter´s, and Daniel´s answers.
What I will add to complement the picture will come from the end-user perspective:
As it is always the case, these skids are not made of products from a single OEM; you shall define a detailed list of what your Packaged Equipment vendor/contractor shall provide as part of the Packaged-Equipment´s “Asset Register.” The idea is that the register extends to not only “hardware,” but also electronic assets and attributes of each piece of configurable device included in the Scope of Supply of the Skid under consideration.
This should include at least:
In addition to comments by others, the problems I have encountered have to do with maintaining these skids. Often, the PLC on the packaged equipment is a different brand/model than the standard adopted by the facility. This can be addressed by specifying acceptable PLCs, but sometimes a vendor may not be able to accommodate this. From the perspective of the vendor, it is challenging to take logic they have developed in a PLC and port it to a different PLC. They would like to standardize to reduce their cost and the complexity of projects.
Today we have OPC-UA and MQTT that make data access to these PLC more standardized. However, if someone needs to look at the logic inside a PLC, you need the engineering tool that supports this. Rarely will anyone change the logic other than the vendors of the equipment because of warranty issues. However, you might need to look at the logic to see what is locking you out.
For example, on a recent project a facility had an old thermal oxidizer that must be running in order to make production. The PLC on this thermal oxidizer was an old model from a brand that differed from the rest of the facility. When the facility could not start the thermal oxidizer, there was no way to look at the logic to figure out what was wrong.
Some of the issues with packaged systems are the inconsistent HMI and alarm system. These are often overlooked until the system is installed. Surprise!
The HMI is often a panel screen, with different symbology and organization, and sometimes a different language. To overcome this, plan for extra training time and keep procedures with screen shots local to the system. Of course, a secondary view can usually be created in the primary control system. There can still be confusion when the two views do not match.
The packaged system alarm functionality is often limited, like a single alarm priority for example. Sometimes only a common alarm is available, like on many heat-trace panels where it stays in alarm.
Ideally the packaged system could support key aspects of the HMI philosophy per ANSI/ISA-101.01 and alarm philosophy per ANSI/ISA-18.2. There is additional guidance in ISA-TR-18.2.7 -2017 Alarm Management When Utilizing Packaged Systems.