- November 21, 2011
Automation.com, December 2011
Describes the thinking that went into developing the ABB Process Automation Decision Tool.
A long, long time ago… in a plant far, far away… As a young project engineer about two decades ago, I was working for a company making - let’s say widgets. I won’t get into the real product as that would cause me to ramble on for days. The front end was a process to make a powder type substance that involved mixing, extrusion, drying, etc which then went into an assembly that was manufactured on production lines. At this plant site, there was a huge debate on whether to use a PLC or a DCS on various parts of the overall production and though there sometimes was no right or wrong answer, I think we did a pretty good job using both automation platforms in the right places based on our criteria at the time. The criteria items we used were based on more than the platforms and what they were known to be “good” at performing. We also considered the personnel, i.e. maintenance technicians, engineers, etc…, and their skill sets as well as technical and interface requirements. The categories…. Twenty years later, PLC vendors still claim that they can do distributed process control and DCS vendors have answers for the PLC, or they have PLC products themselves. So, with a superficial glance not much has changed. However, if you look a little deeper, there are some new categories that are worth considering as some product types meet various requirements slightly better than others. Please note that I said “slightly” as most all automation solutions have a PID block, can do ladder, have I/O…hence they can all turn on a pump or read a temperature. It’s more about what is a better fit. An analogy would be similar to that of automobiles. Many years ago, the most popular vehicles were sedans and trucks. Today, there are definitely more options for a car buyer to choose from based on their preference and how they will use the vehicle. There are coupes, hybrids, 3 and 5 door hatchbacks, SUVs, 4-door trucks, and of course the mini-van just to name a few. Similarly, there are multiple automation solutions that are between a PLC and a DCS. In this exercise, we have limited our efforts to dealing with “process control” and therefore, there are some categories that I’m sure we left out such as PAC (Programmable Automation Controllers) and others that didn’t come up in conversation. So, the solution catagories ended up as follows:
- PLC Solution – Programmable Logic Controller that may be coupled with a HMI/SCADA or panel for user interaction.
- Process PLC Solution – A Controller that has more analog control functionality while retaining a ladder logic, component based approach to meet smaller OEM and project requirements. This solution would include an HMI/SCADA and/or panel for user interaction.
- Small DCS Solution – A distributed control system that has the HMI, fieldbus, and control engineering tools pre-packaged, but is more manageable than a large traditional DCS. These systems usually have a smaller footprint than traditional DCS systems and with the built in diagnostics and a single tag database a lower cost of ownership can be realized.
- Large DCS Solution – A distributed control system with extended features to meet today’s demanding production requirements such as integrations with various plant (electrical, safety, facilities…) and business systems, multi-fieldbus integration capabilities and built in applications for asset optimization, batch management, and long term history.
The Criteria … In other words, what information is the minimum that would be needed to favor one solution over another? If it didn’t have an impact the decision, then we shouldn’t worry about getting the answer. After much discussion, the criteria topics that remained were as follows:
- Inputs and Outputs - I/O count is a good measure of how big the project will be as well as giving an indication of the level of analog control that’s required. Example: Yes a PLC can do analog control and a DCS can do discrete applications, but one solution definitely has the edge over another when it comes to PID functionality, options, and analog control handling.
- Type of process – Knowing the type and speed of the process can help you select the right solution. Is the application continuous or batch? Does it require scans below 100msec? Is it a batch process with ISA S88 type requirements such as equipment arbitration and production reporting or a single line, step-wise process where sequential function charts can be used easily. Example: Yes, you can always put a batch application on top of a PLC, but pre-packaged solutions are easier to configure, maintain and expand. Example: Yes a DCS can do applications under 100 msec, but this usually limits what else can be done with the processor.
- Control requirements – Will the process controllers in the project need to be communicating with each other to provide a coordinated solution or are they standalone with little or no cross communications? Is redundancy required? Example: Yes, a PLC can be redundant or in a stand-by configuration, but other solutions have built in, monitored redundancy on the controller, fieldbus, and I/O levels.
- User Interface requirements – How many Human Machine Interfaces (HMI) or operator workplaces are needed? Is there a central control room or many satellite control rooms, or is a panel/standalone HMI solution required? The level of alarm management required can also help point to a solution. If you are trying to reach EEMUA 191 guidelines or ISA 18.2 compliance, then a solution that has certain features and architectures has an advantage over others.
- Staffing and project execution – The knowledge level and organization that is available should be part of the decision making process. You don’t want to give a Maserati to a teenager that just got their license. Who is going to execute the project and maintain it over time has a big impact on what solution should be chosen.
The revelation… Now working for an automation supplier, I was in yet another meeting trying to position our various automation offerings in order to help our channel partners and project organizations know which product they should use in various situations. Fortunately, we have multiple competent automation offerings which, of course, overlap slightly with each other. We realized that there is no right or wrong answer. Technical fit, market trends and project personnel experience all impact the solution choice. The discussion we were having reminded me of ones I had at the plant where I worked at the beginning of my career. Therefore, we decided to get some experienced project engineers to give their opinion to see if we could come up with a criteria and scoring system that would recommend an appropriate solution. The result is called the ABB Process Automation Decision Tool. The solution… In order to use this tool, you will need to know your project basics as there are 14 questions gathering the information listed as criteria above. The result is a report that will immediately be e-mailed to you. The report will include a generic solution giving reasons why you should consider a particular solution(s) and why others may not be a good fit. There will be plenty of links, in specially marked sections, that will point you to what we have to offer if you are interested. The scoring that is done is not rocket science, but rather done in a simplistic way to try to emulate the project engineer’s thought process. So give this tool a try and let us know what you think.Learn More
Did you enjoy this great article?
Check out our free e-newsletters to read more great articles..Subscribe