Shouldn't process automation technology be easier to engineer, implement, operate and maintain?
I posted this query on a variety of LinkedIn groups affiliated with process automation, and received a range of responses that I will repost here....
- Login or register to post comments
- 3688 reads
- Permalink
- 17 comments
Application complexity drives automation complexity
John McConnell, Controls Engineer, posted the following response on the Industrial Automation and Control LinkedIn group ( http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=73454&d... ):
"There is just a lot involved in process automation and each application has its own unique requirements.
That is a great idea but doesn't that require a leap in hardware and software? I have seen many attempts to simplify the development and programming end most using graphic interface/no programming required ideas. The "programmer" pulls down the icon of the function they want, opens the icon to add the I/O or other needed info and links icons in the flow pattern.
But these all proved ineffective and once size does not fit all applications. Plus inexperienced people may not realize the many “little details” to consider that experienced controls people automatically design in. The reaction time of a solenoid for example, or how long a cylinder rod takes to move, hydraulics vs pneumatics vs electric for movement.
And the mechanical side has to be considered as well as the electrical/software parts. Once a controller is successfully programmed, and running properly much of the future care are the external and mechanical areas. The external sensors going bad, mechanical wear, welding tips on robot arms.
So if someone has improved on the "usual methods" of controls design, what is the cost difference? I for one would like to see this kind of thing."
Temptation to remain proprietary blocks better usability
Timothy Clark, Director of Automation Services at Stellar Automation Services responds:
"Good question Keith and great response John.
While I agree with everything that John says, I think much of this starts with integrated approaches to software and hardware development. You simply have to look at the mess of communications in process applications to see there are a lot of hurdles to easier implementation. The biggest issues, it seems to me, are the imbedded automation and drive to have things look "open" and yet still be proprietary.
One example: there is still a hardware specific programming software package for each PLC, DCS, BMS, etc."
Customers could drive "easy" by settling on modular standards
Adds marc alexander, President/Control Specialist at MSA Controls Inc.:
"My comments will be focused from my controls experience in industrial automotive.
Currently, every project that I've been apart of, has be one-off systems. Maybe designed to be "flexible", but still only one-off until the next generation. I'd have to think, to make systems simpler to engineer and produce, one would have to create it as modules.
Lets say for example, majority of the automotive equipment can be broken down to station levels. What if each "station" was a module, a stand-alone system connected to others, complete with its own PLC, safety PLC, HMI, power supply, etc. This system would be designed to handle "x" # of robots, couple of safety light curtains, etc. Yes this would be way more expensive to produce at the beginning, but if these modules were always common, it should be cheaper after initial development right? The only thing that would change would be the custom tooling, and the process around that tooling. All the general logic, safeties, etc., should be fairly common around that process.
Instead what we have, that every company has their own standards, floor space restrictions, through-put requirement requirements, etc. so one-off systems are "eaiser". If one can convince the customer to change their old ways, I'd think modular system would be far more cost effective not only up front, but for the future. One would be able to take apart these modules, and set them up to a different configuration in future applications.
Maybe systems like these already exist, but I haven't experienced one yet."
Even templated apps take a lot of implementation effort
John McConnell,Controls Engineer, continues:
"What Mr. Alexander states is true - to a point. I too have done almost all "one off" systems until I was introduced to the automotive world years ago. Almost all the auto makers have used the predone "modular" stuff for years. Example, AB Logix 5000 with a predone set of templates for anything that can be in that cell, robots, welders, operator stations etc. And all those templates plus the Universal Tags are put in each PLC. Multiples templates like more robots can be added if need. If something is not needed it is ignored by not getting scanned.
At one auto maker, each cell has 100 registers for data. Some are for status bits, another for cycle times, blocked and starved counts and times, etc. So they get the same data from any cell. Setup for the monitoring templates involves setting the triggers for things like "end of cycle", which are again the same in each PLC something like XXXX_EOC in the template for cell AA001 the tag is AA001_EOC. And then AA001_Ave_Cyc_Time, etc.
And each device that moves has timers and perhaps 16 or more status bits. Example a cylinder in cell AA001 might be called C01, and has C01.retracted, extended, extending (moving out), retracting, etc. And when calling for extension it's timed - that time averaged and 10% added and if it doesn't the move is finished in average time +10% it's alarmed.
BUT while this is simple to use it required a LOT of work to establish, and it still takes a lot to implement in the factory and debug. "
Ladder logic: Outlived its usefulness?
marc alexander, President/Control Specialist at MSA Controls Inc. elaborates:
"While I agree to the beauty of Logix 5000 is its UDT's. It's a very useful tool to save on development costs after the standards have been written. It also very useful of maintaining those standards. Still the logic is still ladder. While for someone like me, ladder logic is where I make my money, I feel that industry standard should move away from it, and more into a function block style, similar to some of the safety PLC that are on the market. Again, I haven't experienced such PLC processors if it already exists in the market. The way I envision it, is to have standard function blocks in place, which are customizable in the back ground if needed. For one example, you'd have a standard function block for one station which incorporate operator interface, one set of tooling, and can be definable to how many sets of clamps exists, numbers of sequence stages. Have another function block pre-defined for FANUC welder, or material handler, etc. Inside these function block, it will have the industry standards of auto cycle, manual control, alarms and error checking, and by mappable to an HMI or system handler.
This would make another good topic, but within this discussion, I was looking at the concept of modular equipment as a means to simplify engineering new systems (in the automotive field anyways)."
Usability especially important if tech skills are lacking
Says Selvan Murugan, Lead A&I Engineer at Stewart Scott International on the Automation LinkedIn group: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=68581&s...
"This is a very important criteria when you are working in countries where the technical education and skills level are low. This needs to be considered if the business objectives are to be met."
Good usability and favorable price not mutually compatible
Comments Gary Stortz, Sales Manager - Ontario Region at Chartwell Electronics Inc. on the Automation LinkedIn group:
http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=68581&s...
"These have always been important criteria. the fuzzy one is the price and that, as we all try to do more with less, is the one thing that does move up or down in the list of ranked criteria."
So you think you have it hard now??
Adds Ron Hunter, Process Control Engineer at INVISTA on the Honeywell Users LinkedIn group: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID...
"It is easy. (NOW) You should have been doing this work 25 years ago. At that time it wasn't easy... "
Off-the-shelf information technology helps
Adds Christy Thomas of EQUATE Petrochemical Co., Kuwait, also on the Honeywell Users LinkedIn Group: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID...
"Process automation technology is indeed become easy and simple to implement and maintain by going in for open system (windows based) platforms and networking. However, the area PA need to focus in my opinion is improving IT skills of PA engineers.
PA engineers can no longer run away from IT networking skills, windows operating system skills, switches, routers, etc...etc..etc.. Name it ..all of them
Industrial IT must become an invariable component to any future PA technology."
"Easy" is a threat to job security
Dave Parks, Engineering Specialist at Mangan Inc. weighs in:
If we make it too easy, then anyone could do it, and then we would be out of a job.
Process automation remains anything but easy
Counters Mauricio Santos, Automation Consultant at Braskem. Also originally posted on the Honeywell Users LinkedIn group: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID...
I don´t agree it´s easy. It encompasses a lot of different and very specialized disciplines. In order to make clear the question and the answers I would suggest making a more comprehensive survey listing PA technologies. I think this would be very interesting and helpful.
Today, it's more complicated AND easier than ever
Contends Luc De Wilde, DCS/APC/OPT specialist at Total Petrochemicals:
I had my first DCS training course in 1985. It was a 2 week training on TDC2000. With this training I was "fully" trained.
Today you need several months of training before you are mastering all functionalities of the systems.
Today we have many more tools on the DCS, it is more userfriendly, but it's simply "bigger" and more complicated.
So : yes it has become easier. No, it has become more complicated.
From simple and slow to fast and complicated
Adds Steve Hardisty, Technical Lead at Champion Technology Services:
I think working on the early stuff (TDC) was fairly simple (the hardware did what it was supposed to, no windows involved!) but time consuming - Floppies/Bernoulli's weren't the speediest media. Nowadays things happen faster but are much more complicated. Now we have Windows, Cisco and all kinds of things beyond the DCS Vendors control to deal with. Plus they get to blame each other products for the problem which makes tech support harder.
So we've gone from Simple & Slow to Fast & Complicated.
System complexity beyond a chemical engineer's preparation
And this from Gavin LeMesurier, Industrial Control Software Specialist:
I've worked in HWL Industrial Controls for over 18 years. During that time, I've seen the evolution of their offering from the TDC 3000 to the UsX then into the EPKS (via Plantscape). Having a computer background, I thought this would make complete sense in how the product evolved. The problem that I see now is as a couple of others have noted, the complexity of the control system has moved beyond what a traditional chemical engineer would know. This means you really need to bring in the specialists to make any additions/alterations to the system. This might be frustrating to some customers, but if you start looking at the networking (hardware & software), the domain setup (policy definitions, networking and OPC) as well as the new interfaces (Fieldbus, DeviceNet and so on) plus the actual controllers and programming of same, this ain't Kansas anymore. If your company wanted to buy an F-22 rather than an F-4, they need to budget for the support and look for the specialists to come visit when you want to make significant changes to your system.
Do engineers take pride in complication?
Also on the ISA LinkedIn group: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID...
Phil Sallaway, New Business Development at PUP Co. writes:
Yes it should be but you see engineers design it and they take pride in designing a complicated piece of equipment. Which if you adjust A, then calibrate B, while tuning Z, and have special tool X, Y and Z is is no problem to get it working..................After you get J,K L, M, N, O and P properly aligned......
Sorry I am Product Manager who has had to fight this fight. Keep it Simple, plug and play works, Keep it simple make the sensor talk to the controler and say here I am, this is what I am and ta da... lets talk...
Easy-to-assemble systems are not in vendors' interest
Also on the ISA LinkedIn community: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers&discussionID...
Paul Nelson, Senior Engineering Specialist at Dow Corning writes:
Yes, systems should be easy to use. However, I don't agree that products are complicated because engineers take pride in complicated systems. Most engineers agree with Einstein: "Make everything as simple as possible, but not simpler". Process automation products are not designed by people who use them. They are designed by by software or systems specialists trying to fulfill a list of product features generated by a sales or marketing research team. It is a fact of life that marketing and sales folks like widgets designed into products, even when the value of these widgets is questionable.
Beware of comparing PC technology (plug and play) to automation systems.
Standards that make systems easy to assemble from disparate vendors are generally not appreciated by large automation system vendors, because it weakens their monopoly. Easy to configure, and standard, are things that end users and smaller disruptive companies support.
If we want simpler, easier to use systems, we will have to demand them from our suppliers.
Standardization runs counter to usability
On the ISA LinkedIn Group: http://www.linkedin.com/groups?home=&gid=137598&trk=anet_ug_hm ,
Mahzad Pakzad responded:
Here is what makes it difficult to design a simple system that satisfies all. a) The design and development and marketing need to make sure that their product will sell well to pay back their investment; b) Our companies, in general have not value stream mapped their processes and have bugs and issues within their own processes' c) Company to company the characteristics of operations vary in so many ways, including the capability of the end user to understand and utilize a new product d) We buy these system to help us improve our operations, but never take time with all end users to review the compatibility of the system with what each group and the company as whole needs and try to see what is good solution and practical to use as a standard, usually individuals have to struggle to apply with what they learn in a group training (if any) to their specific task/application that may very well be quite different than the guy next to him. I always worry about the effects that standardization could have on making products a good fit for each and every application.