Distributed intelligence

Sometime in the next year or so, companies are going to release control products that will dramatically change the landscape of the automation and process control industry in ways never dreamed possible.

By Rich Merritt, Senior Technical Editor

Share Print Related RSS

S

ometime in the next year or so, companies are going to release control products that will change the landscape of automation and process control. These changes may be the most dramatic to hit our industry since 1975, when the introduction of distributed control systems (DCSs) completely upset the analog control apple cart, threw the established control industry into turmoil, and caused dozens of old, slow-moving control vendors to fail. By the time the DCS trend had swept the industry it had helped create a whole new set of control equipment suppliers.

The biggest difference now is that in 1975 Honeywell caught the rest of the industry with its pants down when it introduced the TDC 2000. This time, several–if not all–of the control vendors have their R&D “skunk works” busy creating new distributed intelligence products, so it’s likely most will come to the market at about the same time.

Essentially, a new type of control system is coming down the pike, and it promises to save you millions of dollars in hardware costs, provide access to the most advanced control and monitoring software at a fraction of today’s price, eliminate security problems, and allow unattended process plant operations. What’s more, it will be better suited to solving your problems than today’s overly complex systems.

“The great thing about the control business today is the equipment and software is finally evolving to the point where we can make the solution fit the problem,” says Edward Bullerdiek, control group leader at Marathon Ashland Petroleum in Detroit. “In the past we've always had to make the problem fit a usually imperfect solution. The user community knows how this ended up—usually not well.”

Two technologies are involved: one at the bottom of the control pyramid and one at the top. One begets the other.

     

FIGURE 1: TINY PROCESSOR
 

      Tiny Processor 
     


The first-generation Mote is a tiny (3x3 cm), battery-operated computer that communicates via wireless. It has a small operating system (TinyOS), and enough memory and hardware capability to perform control and monitoring tasks. The next generation Mote will be half this size.
 

The Dream Begins Here

Let’s start at the very bottom of the control system architecture, with “motes.” A mote is a tiny $50 processor, about the size of your fingernail (See Figure 1). It is battery operated, communicates via wireless Ethernet, has a small operating system (TinyOS), and has enough memory and hardware capability to perform control and monitoring tasks. It’s eerily reminiscent of the “smart dust” in Michael Chrichton’s recent novel, Prey.

The technology can put a web-enabled processor at every sensor and every actuator. As long as another mote is within 100 ft. or so, it requires no hardwired network. Hundreds of motes in a process plant can form a spiderweb-like mesh or sensor network that provides unlimited numbers of pathways to pass information back and forth. Such a network has multiple levels of redundancy because, if any single mote fails, dozens of others stand ready to move network traffic. (See “Developing Your Potential,” Sept. ’04, p57 and “Technically Speaking,” Sept. ’04,  for a discussion of mesh networks and the Zigbee protocol.)

Similar devices are available. Mote is the term used for sensor nodes created by University of California Berkeley and their partners, including Crossbow and Intel. TinyNode is another example, which is a sensor/actuator node produced by Embedded Research Solutions, Annapolis, Md. A more generic term is a “sensor node.” 

The National Institute of Standards and Technology (NIST) calls all this technology “pervasive computing.” 

To keep it simple, we’ll call them all motes and sensor networks for the time being. Whatever you call them, motes are the ultimate in distributed monitoring and control. 

Consider the ramifications of a sensor network in your plant. What does it cost you to transport the output of a traditional 4-20 mA pressure transmitter to your DCS and then on to your enterprise resource planning (ERP) system? The 4-20 mA signal first has to run via a twisted-pair wire through a hazardous environment and intrinsic safety barrier to an A/D converter on an I/O board mounted on a rack in a NEMA 12 enclosure out in the plant. 

From there, the signal is linearized, converted, massaged and otherwise processed by a remote terminal, PLC, or PC, and transmitted over the plant network to a central control room. 

Now it gets tagged, identified, fitted with XML descriptors, and stored in the plant historian data base. Finally, another piece of software bundles it up with other data and ships it off to an ERP program. What is the total cost in hardware and software products--plus labor for engineering, configuring, installation, running cable and so on--to bring that one sensor point to the ERP system? It can vary and may range from $2,500 to as much as $10,000. Think about it. The cost of wiring alone is probably $50/ft.

The Point is Mote
With sensor networks, all you need is a $50 mote and an A/D converter. Hardware cost: $100 or less. If the vendor embeds a mote into the transmitter at the factory, the added cost is incremental; about $5. Micrel (www.micrel.com), for example, is offering its RadioWire RF Transceiver to OEMs for $4.50 each. Then, any processor with a DCS or ERP program that wants to see the pressure value simply calls up the IP address of the web server in the sensor and reads it with a conventional web browser. 

“The concept behind motes is not unique,” says Robert Jackson, PXI Product Manager at National Instruments (www.ni.com). “An example would be a computer with a wireless connection or radio modem.” He likens them to the transducer electronic data sheet (TEDS) “smart sensors” defined by IEEE 1451.2-1997. “The key is that applications for smart sensors and motes increase as the cost and size of processors decreases. With the trend for faster and cheaper processors unlikely to reverse, it is important for process control applications to support PC-based technology. Motes will not replace all sensors, but smart sensors will play a role in specialty applications.” 

FIGURE 2: THE WAY WE ARE
 
     
Control system architecture       

Today’s control system architecture, from the sensors at the bottom to ERP systems at the top, are all dependent upon hardwired connections. (Source: SMAR)
 
     

Such a concept shakes the very foundation of the process control and automation industry, which is based on charging huge amounts of money for the specialized hardware, software and services traditionally required to acquire data from sensors and transmit commands to actuators (See Figure 2). Motes, sensor networks and pervasive computing threaten to replace all that infrastructure–fieldbuses, proprietary networks, redundant networks, intrinsic safety hardware, cable, conduit, I/O boards, data acquisition hardware, enclosures and so on–with inexpensive wireless devices. 

May the Force be With You
Control equipment vendors can rest easy for the time being, because motes are a few years away. “In three to five years, pervasive computing applications will start to dominate the technological market, much like the telecom industry dominated in the late ‘90s,” predicts Dr. Stewart. 

At present, the only functioning mote systems we know about are in laboratories, research facilities, semiconductor fabrication plants, and a ship. BP, for example, has outfitted one of its oil tankers with 160 motes to measure vibration in the ship’s pumps, compressors and engines. At Intel’s Ronler Acres semiconductor fabrication plant in Hillsboro, Ore., vibration engineer Mick Flanigan is working with motes and vibration sensors. It’s all still in development, Flanigan says, but the results are promising. 

“We are monitoring pumps, compressors, and other plant facilities equipment with vibration sensors,” he reports. “Each machine has from 1-12 vibration sensors, and each sensor has a mote. The motes report via wireless to a central Stargate wireless processor, which converts the data from up to 12 motes and transmits it to a PC that runs Rockwell Automation’s ENSHARE asset management software.”

Flanigan reports that they have 210 sensors installed on 40 machines so far, and will eventually equip about 3,000 machines. The cost to equip a machine with six sensors is about $750 for the vibration sensors and about $250 for the motes, Stargate modem and enclosures, or about $1,000 per machine. To do it with conventional equipment would cost “about $8,000 per machine,” Flanigan estimates. 

The technology is not quite ready for prime time, though. You can buy the necessary hardware easily enough, but better hardware-to-software integration is needed. “We are probably a year away from having commercially available network components and the software to tie them to asset monitoring software,” says Flanigan. “However, any reasonably competent engineer can put such a system together today. In my case, the tough part was dealing with the complex vibration data, not the motes.”

Some automation companies have distributed intelligence projects in the works. “Rockwell Automation is working on technologies to propagate control capabilities as low in the architecture as required by the customer application,” says Rockwell’s John Weisenberger, a strategic marketing manager for Distributed I/O. “Over the next 2-3 years, it’s likely that the next logical step beyond running many applications on a white box PC will be a migration into the controller rack. Additional functionality will migrate into the devices themselves. This, however, will require development of much simpler system management tools to increase the level of robustness, manageability and maintainability of such solutions.”

As far as we know, no process control company or software vendor has yet to develop a product. They are mostly still at the talking stage. And waiting. 

“Standards organizations such as ZigBee, the 802.15.4 committee, and the Wireless Industrial Networking Alliance (WINA) are all working to make wireless standards and products more appropriate for industrial applications,” says Hesh Kagan, Consulting Engineer, at Invensys Process Systems. “Invensys is involved with the standards groups as well as WINA, helping to promote the acceptance of wireless solutions.”

“Motes are a great concept, especially for independent field measurement and reporting devices,” says James M. DiNanno, marketing manager at Schneider Electric (www.schneider-electric.com). “Motes are a concept for dynamic networks, where sensors talk to each other using embedded RF and smart technology. The addition of mesh networking also helps to create a robust self reconfiguring network topology. The best industrial application for this type of technology is redundancy, to assure reliability and to double-check the information being used before taking a control action which is gated by a master controller.”

   


"Pervasive computing applications will start to dominate the technological market, much like the telecom industry dominated in the late 1990s." 

Myriad problems must be solved with application software, networking, security, and so on, so that’s why motes are a few years down the pike. Gabe Sierra, industry marketing manager at the Rosemount division of Emerson Process Management, explains: “Limitations and concerns are being addressed and suppliers are working hard to resolve important customer issues, such as power source life, security, duty cycles, etc. The technology is quickly approaching the point where it can be deployed in non-critical/monitoring applications. As the technology matures and end users gain more experience with it, additional applications in process plants will likely be envisioned.” 

And, once the problems are solved, development tools are needed so you can actually use them. “The key will be to make the devices work out of the box to make installation easier and mitigate the need for site surveys,” says Sierra. “As with any new technology, suppliers will need to educate end users of its technical aspects, advantages, limitations, and application identification and support.” 

Trough of Disillusionment
Michael Paulonis, instrument engineer at Eastman Chemical Company, Kingsport, Tenn., thinks motes are mostly hype. “Typically, emerging technologies quickly climb the hype curve and get a lot of, well, hype,” says Paulonis. “Then, as reality sinks in and issues are exposed, the technology descends into a trough of disillusionment. Some technologies make it out of the trough and slowly climb to a plateau of productivity. I don't see the game-changing nature you describe for wireless distributed sensing and control. Granted, it will reduce installation cost, but that seems much more evolutionary than revolutionary.”

While we wait for motes and pervasive computing, wireless products continue to make inroads into the hardwired scene. A study by Venture Development Corp. (www.vdc.com) predicts that spending on wireless networks will more than double from the $75 million spent in 2003 to more than $183 million by 2006. While we see little evidence that the hard core process control suppliers are making wireless products, a scan through issues of our companion publication, Industrial Networking, reveals plenty of companies offering wireless Ethernet products and systems. 

How Low Can We Go?
Motes, wireless, fieldbus, pervasive computing, smart sensors, smart valves, and a host of similar intelligent devices raise the question: How low can we go? How far out can we push distributed control? Technology makes it possible to put an inexpensive processor at every sensor and actuator, and lets them talk to each other. But we don’t need motes to do that: we can do it now with hardwired networks. 

Systems integrator Ian Verhappen says we are on our way down: “The trend is to distribute down to the lowest level, as evidenced by research in networked motes,” says Verhappen, director of ICE-Pros (www.ice-pros.com). “In the case of fieldbus, field-level control ensures single-loop integrity, minimizing the impact of a single point of failure. If properly designed, a fieldbus system’s only significant point of failure is the home run cable.”

Luis Trejo, an engineer for Emerson Process Management Mexico (www.emersonprocess.com), agrees. “I personally think the ‘farther down the better.’ The more intelligence is in the basic cell the better for the whole unit, mainly because of improvement in execution times and diagnostics information.” 

     


Typically, emerging technologies quickly climb the hype curve and get a lot of, well, hype."

This is not suitable for every application, of course. “This does not mean that you could eliminate the main process controller,” Trejo notes. “Most projects I have participated in lately include more sophisticated strategies that have information from and output sent to various elements. Multivariable process control, automatic start-up and shutdown are common strategies requested by end users. These strategies have to be coordinated by a central controller.”

Even if you have the capability, you don’t have to use it. Jorge Cano Carmona, a process control engineer at MetMex Penoles in Torreón Coah, Mexico, has Foundation fieldbus (FF), so he can distribute control as far out as he wants. “It is very important to choose when and where to put the control in a smart instrument,” he says. “In my latest experience with FF instruments in two ammonia spheres, we discussed where to download the PID: In the controller or in the valve? We analyzed the process operation and choose the controller.”

It was a tough decision. “The advantage of running the control loop at the valve allows for continuous operation if the controller fails,” he admits. “However, if a failure occurs, most likely it will be the FF segment. It is more common to find a fault in a segment than in the controller, at least with the controllers we are using.” To Carmona and MetMex then, there is no advantage to putting control at the valve.

Verhappen agrees that controllers are more reliable than the field devices. “Look at SIL ratings to confirm that,” he says. “However, if the field devices fail, what do you have to control to—or with? The main impediment to field based control in my mind is that every PID algorithm in the field can be a different type, so that if you migrate control from one device to another, the tuning will be different. Some call it gain, others call it proportional band.”

Distributing control to field devices is not a technical or hardware problem. Dave Holmes, marketing communications manager for Emerson Process Management, explains: “In the case of Emerson, the same algorithms that run in the controller also run in the final devices. This gives us the unique ability to move the execution of the control algorithm from the controller and back again without affecting how the control is executed.”

“One significant advantage to running PID in the final control elements or sensors is the ability to have localized loop control at the process,” he adds. “Should communications with automation system experience be interrupted, the backup link active scheduler in the H1 segment will continue to maintain reliable control locally.”

Two problems raise their ugly heads when intelligence is distributed out so far: 
1.  How do devices from different vendors talk to each other?
2.  Who’s in charge here?

“The largest issue preventing the widespread adoption of digital control at the field level is interchangeability,” says Verhappen. “This means the ability to truly exchange one manufacturer's device for another and get the same functionality. To be truly effective the networks need to be vendor-independent and therefore able to talk to each other, regardless of who makes them and what each one is saying. We still need to find a way to get everyone to agree to a common 'object dictionary' series of definitions. I believe that ISA, NAMUR, and the various fieldbus foundations have a role to play here.” 

Tom Mueller, director, Asset Optimization Marketing at ABB (www.abb.com) supports Verhappen’s assertion. “The challenge right now, as more intelligence goes to the field devices, is finding a way to capture this intelligence and deliver it from the device to the user in a usable format,” says Mueller. “The current standards are not consistent enough to use intelligence from multiple vendors effectively to get to the ‘new frontier’—really taking this intelligence beyond control loops and PID and up to advanced control levels. Many customers have an interest in this opportunity to do much more with their field device intelligence, but they need a way to get this information back in a usable and understandable format.”

Even if the information was readily available, who makes the decisions? Steve Lazok,  manager of Technical Solutions Support at Yokogawa (www.yokogawa.com) lays out the problem: “The issue is, not where control executes, but where and how you manage the information and how to interact with control in the field. Where and how does an operator change a setpoint? Where, how, and to whom does device information, like its health, get reported? And then, who fixes any problems and by what means do these problems get fixed?”

DiNanno says the basic fault is in the distributed control concept. “The most notable weaknesses of distributed control are the lack of precise integrated software tools and ways to handle scenario-evaluation and decision-making processes,” he says. “Since you may deploy many intelligent devices and these can operate autonomously, the number of scenarios and methods to manage and interoperate all these devices can become a very large and complex task. Better tools are needed to help manage these types of conditions in an easier way.”

Todd Stauffer, marketing manager at Siemens Process Automaton Systems group, agrees. “To gather up all these inputs from distributed devices that may not necessarily be on the same physical bus, and provide this data to an embedded controller in a field device in real time without data latency issues is a major challenge, and perhaps out of reach today,” says Stauffer. “This is reflected by the trend that while fieldbus adoption has shown an increase over the last 3-4 years, adoption of control in the field in real process plants have been relatively weak.”

But wait! Getting all that data to distributed devices is exactly what motes and sensor networks do! They bypass all the fieldbus segment limitations, data latency problems, and vendor incompatibility issues. If a controller needs a particular sensor input, it just asks the sensor for it. Sensor networks may be the key to advanced control. 

Making Advanced Control Possible
Control gurus, like our own Bela Liptak, keep telling us that multivariable control is the future. Instead of just dealing with a simple process loop, future control systems will develop models, consider everything that’s going on in a plant, and make control decisions based on many interlocking and interdependent variables.

Some industries already rely on multivariable control. “Boiler-turbine control systems must deal with a high degree of process interaction, which requires the system to coordinate many different plant functions, from boiler inputs to generator output,” says Roger Leimbach, marketing manager at Metso Automation (www.metso.com). “There are few independent control loops in a power plant automation system. Virtually all critical processes are interconnected, which requires constant communication, especially during load changes. Communication delays cannot be tolerated. Thus, pushing control functions down to the device level is not likely, nor recommended."


"There is a magic sweet spot where field control is not most beneficial and where centralized control becomes advantageous." 

       
The rest of the world is still catching up to the idea. “Process manufacturing facilities resemble other complex systems such as organisms, buildings, aircraft, ecosystems, cities and economies,” explains Lane Desborough, an analyst at Honeywell Process Solutions, Phoenix, Ariz. “When there isn't some degree of alignment between the disparate parts of these systems, when they aren't all focused on the same goal, then suboptimal things can happen. This strikes right to the heart of distributed control. Many authors recognize that ‘reductionist theory’ reaches its point of diminishing returns when applied to complex systems.”

He continues: “Let's say that you have control algorithms in the valve tops and the brains and alarm notifications are distributed out into a thousand places around the plant. Where is the guarantee that these controllers are working toward a common purpose such as making money? How are they coordinated in such a way as to notify the operator, maintenance planner, technician, and engineer only if and when their process performance degrades and is no longer consistent with business objectives?”

Paul McLaughlin, director of architecture for Honeywell Process Solutions, adds: “One argument against extreme downloading of control is that process elements are multivariable dynamic systems. Decisions on control actions for multiple actuators must be undertaken in a coordinated way and based on measurements of multiple, sometimes hundreds of parameters. There are, therefore, good reasons for today's distributed control architectures with their separation of multivariable supervisory and univariable regulatory control. Complete distribution of control isn't advisable. But with technological advances steadily removing barriers to distribution, we can expect that problem and process characteristics will dictate distribution to a considerably greater extent than is possible today.”

It looks like distributing control to ordinary field elements is good only in some cases. “Decentralized control is best suited for basic controls such as plain PID, cascade PID, feedforward and ratio,” says Jonas Berge, marketing manager for SMAR (www.smar.com). “Although it is theoretically possible to do very complex loops in field instruments, the control cycle will get too long if too many blocks are chained in series. There is a magic sweet spot where field control is not most beneficial and where centralized control becomes advantageous.”

Bullerdiek backs that up: “Any complex process that requires a high degree of coordination, such as batch processes and continuous processing units, will still benefit from centralized control,” he says. “The regulatory loops might get pushed out to a fieldbus, but there will still be a reason for centralizing the higher level controls. The rule of thumb will likely be: wide distribution/low complexity equals highly distributed control, and close proximity/high complexity equals centralized control.”

It is safe to say that batch control systems, continuous control, and advanced control of all kinds most likely will require some kind of centralized system to oversee everything. However, this does not rule out the use of distributed control, motes and sensor networks. If controllers need to obtain data from everywhere, why not through a smart sensor network?

“One of the most immediate benefits of being able to deploy many inexpensive wireless sensors across a process is a heightened ability to make inferential measurements,” says Kagan. “Most process plants today take measurements at only about 10% of the possible points. Although they might get better measurements by taking measurements at more points, running the wiring and connecting the sensors is cost-prohibitive. But if the attachment and sensor costs were low enough, as mote technology promises, you could measure at many more points, giving you a much richer process model to work with.”

Through the Hype Curve Smartly
Where does all this leave us? “I see this technology following a similar path as that of computing itself,” says Paulonis. “The first powerful computers were mainframes. This is like a DCS. PCs might be like single-loop controllers. When networking reached the PC, we saw a huge shift away from mainframes. Perhaps something similar will happen with wireless distributed controllers. However, there were some real problems with managing gobs of PCs. There will likely be similar issues managing wireless distributed controllers as others have already pointed out. We now find ourselves with fewer, standardized PCs, a number of centralized servers doing a lot of work, and even a resurgence in mainframes. Personal computing has gone through the hype curve. Wireless distributed controllers will also. There will be circumstances where wireless distributed control is the best solution, others where centralization of control is a better choice, and yet other applications where the DCS approach continues to be advantageous.”

Get Those IT Systems Out of Here!
It’s obvious that all control systems require a central supervisory system to issue maintenance orders, advise operators that things require tending to, tune loops, acquire data, prepare reports, perform advanced optimization calculations, maintain the process historian, deal with ERP software, and otherwise perform the thousands of housekeeping and IT tasks required of a control system.

But here’s the kicker: The housekeeping and IT systems do not have to be in the processing plant. They could just as easily be distributed upward to a computer center 6,000 miles away. 

     

FIGURE 3: THE CONTROL SYSTEM OF THE FUTURE
 

      Control system of the future 
     


In the future, almost all the networks and hardwired devices in levels 0, 1 and 2 -- such as I/O boards, fieldbuses and device networks -- will be replaced with a wireless sensor network. Only real-time control functions will remain at the plant. Level 3 and 4 software will reside in a secure data center or "server farm" far away and communicate to the real-time plant systems via a secure Intranet.

 
Let’s face it: The only real-time controls you need in a plant are the Level 0, 1 and 2 (See Figure 3) systems, which directly control equipment, but do not necessarily make strategic or business decisions. Any control action that could be delayed by a few seconds–such as pumping product to a storage tank–does not have to be initiated by a multimillion-dollar DCS sitting in your plant. The command to pump product could just as easily come from a batch control supervisory system sitting on a server.

With IT software on a server, you won’t have to pay millions of dollars to buy advanced control, process historian, maintenance management, trending, adaptive control, process modeling and ERP software. Thanks to the Internet and client/server technology, you will be able to rent such software, and pay only for the capability you actually use. 

Sound farfetched? Not hardly. As we pointed out in "Is Colocation Coming to the Process Control World?" May '01, p31, Siemens is doing exactly that in Germany. Its Haus der Gießer (Foundrymen's House) Internet portal gives medium-sized foundry companies access to ERP, supply-chain management, MES, process data analysis, plant operation systems, maintenance and diagnostics software, plus systems to support purchasing, sales, production planning, logistics and more. All are in a single server, and all are configured specifically for foundry operations. Each foundry pays for whatever computer time it uses. Because they don't have to buy or maintain the software, German foundries save up to 70% of the cost of doing it themselves.

Honeywell does it too. “Honeywell Process Solutions offers monitoring services for control loops via the Internet through our LoopScout and AlarmScout services,” says Paul McLaughlin. “More recently we have launched a remote performance monitoring via the Internet jointly with UOP.”

“We provide underlying technology to many OEMs,” says Lawrence Ricci, Business Development manager at Applied Data Systems. “While our client relationships in this area are confidential, there are OEMs who are actually distributing control internationally. These are OEMs who furnish a package process which is installed in thousands of industrial facilities worldwide. They take responsibility for the local control system as well as supervisory functions which are performed on the company's data servers in Europe.”

There is absolutely no technical reason why all the IT software you use cannot be put on a server and rented to you for a 70% cost saving. Here’s how it works:
  • Your IT packages are hosted on servers at secure data centers, which are located close to a reliable source of power and high speed fiber. The data center could be at your corporate headquarters, a vendor such as Emerson, or at a “process control center,” which would house software from multiple vendors, such as Honeywell, OSIsoft, SAP, ExperTune, and so on. 
  • You can have your own processors at the data center, or you can access the vendor’s server hardware. 
  • You connect your plant to the data center in several ways for redundancy: via a private leased high speed Intranet, commercial Internet, and/or dial-up phone service. Obviously, when you communicate via your own high-speed leased line, security is exceptional.

Data from the sensor network is gathered at your plant by a central device, which communicates with the far-flung data centers. The concentrator device can speak to the data centers using encrypted messages. Commands and set point changes coming back to the plant can also be encrypted.

The advantages of such a scheme include renting instead of buying; freedom from upgrading your software every year; freedom from maintenance costs; no worries about hackers or system security; very high speed network operations; excellent reliability; and redundancy. All this has to be worked out in more detail, but the technology is here to do it all and more. Commercial Internet web sites do it every day. 

“The computing and information management parts of control systems are not bound to physical processes,” ABB’s Hausler points out. “As an example, many parts of today's systems leverage standard IT technology, and could move this into a shared computing environment or even a rental model. There are significant potential cost advantages to this type of approach.”

Indeed, costs are an issue. “For users this could be cheaper,” admits Lazok. “For suppliers, cheaper may mean less revenue than if they could sell them, particularly on large installations, where license fees for software may be required yearly.”

There is no question that IT software vendors oppose any changes to their comfy little world. Selling software for millions of dollars, charging hundreds of thousands to maintain it, and requiring periodic expensive updates is making vendors a fortune. But the IT world is rebelling out there. “The industry’s dirty little secret is that, in many cases, their customers do not really need to install an entirely new CRM or ERP system,” says Charlie Cooper, executive editor of CNET News. “Truth be told, many probably can’t even use the one they already have.”

Cooper says a customer revolt is looming, and IT buyers are looking for alternatives, such as open-source software or rent-an-application providers. We wish them luck, because their revolt will benefit our industry as well.

The Next Logical Step
The next logical step is to take engineers out of the process plants, and put them in central command centers, where they can supervise the operation of multiple plants. Server-based systems allow you to do just that. “I believe that you will see significant numbers of unmanned process plants all around the world,” says Alex Johnson, Systems Architect, Invensys Process Systems. “We have been seeing it already in gas production plants since the mid ‘90s. In general, we will be removing people from the bad environments and running a lot more plants remotely. And I think we are going to see it occurring over networks that are not designed solely for the control system.”

But that is another article.

Share Print Reprints Permissions

What are your comments?

Join the discussion today. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments