Print this article

Comment

08 November 2001

Open Control: Why, What, and How?

By Ken Crater

Departing from control's single-source paradigm will free users to select best-of-class components.

In a recent column ("NMW-Open Systems?", Motion Control, April/May 2001), Tom Bullock raised an intriguing question: Has the National Manufacturing Week exposition become the Open Control Show? Indeed, the proliferation of smaller vendors and the withdrawal of many of the larger ones would indicate something big is afoot. But what, and why? And how will this affect motion control's future evolution?

I predict that the changes affecting the general controls industry will be highly beneficial for motion control, offer unprecedented integration and power, and finally bring the field into control's mainstream. I'll expand on this assertion, but first it might be helpful to look at the broader trends under way today.

Out of Control?

The controls industry is going through a turbulent and, for many, not terribly happy time. There's massive consolidation under way affecting many of the larger players in the industry. Brand names that used to shine like gold now post rather unglamorous financial returns, and the overall market is growing at a snail's pace. But what's really happening here?

A close look indicates the widespread disaffection that's characteristic of a mature market. The programmable logic controller (PLC) was invented in 1969, and the technology is showing its age. What started as a stroke of brilliance-the expression of a "program" in a form comfortable for non-computer-literate electricians-has slowly evolved into a cumbersome tool that's ill fitted to many of the tasks contemporary control engineers face. One has only to examine how motion control is typically accomplished in the context of a relay ladder diagram to see the signs of an aging paradigm.

Now, let's examine the platform itself. The PLC started life as an "industrial-strength" special-purpose computer, at a time when "real" computers filled whole rooms, required air-conditioning, and were attended by lab-coated technicians. Again, this was a stroke of brilliance in applying purpose-built technology to the requirements of an industry.

However, times have changed in the computer hardware arena as well, and much more dramatically. Control engineers who have home computers sporting 1-gigahertz processors and 128-megabyte RAM complements then come to work to use PLCs equipped with 32-megahertz microcontrollers running with 256 kilobytes of RAM. The performance and value inherent in PCs is compounding at an awe-inspiring rate, far faster than even the largest of our industry's suppliers can track. It's small wonder users are becoming dissatisfied with the PLC as a hardware platform, given the growing disparity.

In terms of meeting business requirements, however, the greatest shortcomings of the traditional PLC platform lie in the area of communications. This is clearly the Information Age, where connectivity is the key to myriad benefits. Although the topic is far beyond the scope of this article, suffice it to say that the velocity of the marketplace today can be supported only with a vertically interconnected factory. This has led to, in order, production line networking with sneakernet reporting, plant networking with manufacturing execution systems, or MES (also spelled "mess"), and finally full information integration with enterprise resource planning systems reaching down to the plant floor.

Implementing this progression using PLCs has been interesting. The chief technical challenge imposed by proprietary control technologies is how to readily interface to the rapidly evolving business protocols in use at the enterprise level. Because the processors, networks, and architectures used in proprietary systems are quite different from those used in mainstream computing, the chore of reimplementing these protocols directly in PLCs becomes burdensome-so burdensome, in fact, that it just isn't done.

Jelly Beans

The growing gap between users' expectations and needs and the available control products has had a devastating impact on the controls industry. All the symptoms of a mature marketplace are present: declining margins, squeezed distributors, price competition and price shopping, reduced product differentiation, consolidation, layoffs. The net effect has been the commoditization of the industry toward viewing PLCs as "jelly beans"-all alike, which color would you like?

This is truly ironic, given that what many PLC users really need is a much more advanced product capable of addressing the business imperatives they face today. However, this seems to be precisely what PLC vendors can't deliver.

The answer from suppliers has been the traditional response offered in a mature market: Move toward a service paradigm. "Having trouble interfacing your controllers to the enterprise? We'll be glad to quote a price." By moving the purchase transaction to a higher level, the underlying problem is masked, if only temporarily, by making it the vendor's problem. The only impact on the user is a higher purchase price and higher lifetime costs.

The Point

Did I say this article was about open control? Well, it is, but the first part of the question is "Why?" The myriad problems faced by PLC users today-performance, communications, capacity, programming flexibility-would be complete nonissues if PC technologies were applied to automation. Nor is this a great revelation, as market surveys going back to the early 1990s (and before) showed a general expectation that PCs would become the dominant control platform. Users have intuitively and explicitly known the benefits and rationale for open control and have freely expressed their views on the topic for a decade or more.

This demand has frequently been characterized as a desire for cost reduction. Indeed, paying $2,000 for an Ethernet module has led to more than one unkind comparison between proprietary and generic technology. However, industrial users have always been willing to pay a premium for industrial solutions. Downtime is typically more of a concern than purchase cost, and after all, the price of that Ethernet module has come down a bit.

The far more serious issue is the failure of current proprietary technology to meet current user requirements. This is where open control has the most to contribute. Let's look at these requirements in more detail and at why an open control prescription may be the best medicine.

Velocity Isn't Just a Motor Spec

Many of the new demands placed on control engineers today trace back to a factor having little to do with engineering or technology: Our newly connected international marketplaces are heating up to an unprecedented degree. Market velocity, the speed with which competitors learn and adopt techniques and intelligence from one another, has reached dizzying levels, aided by the Internet, Federal Express, and declining trade barriers.

In one manufacturing industry after another, this has translated into an imperative to "instantly" adopt every new advantage that comes into view because the competition surely will. The word "instantly" becomes a bit of a dilemma for the control engineer equipped with "right-sized" budgets and staffing-another reflection of market dynamics.

The first requirement, therefore, is the ability to incorporate new technologies and techniques into production processes quickly and cheaply. Because these new technologies may be sourced by any of hundreds of vendors and may be available first in commercial rather than industrial formats, the availability of a variety of "open" interfaces in control systems becomes critically important.

Further, because innovation now comes as often in the form of software as in hardware, the ability to adopt software solutions from the commercial marketplace becomes equally-or more-important in maintaining a competitive posture. This points to a need for architectural compatibility at the software level, with all that implies for hardware platform and operating system choices.

'Good Enough' Isn't

This highly competitive environment imposes additional requirements. Previously, manufacturers could rely on market inefficiencies to allow less-than-optimum solutions to be applied in manufacturing processes. If the controls vendor of choice didn't have stellar motion-control capabilities, for example, its total solution was likely still good enough to do the job.

However, the margins have now tightened to such an extent that suboptimal solutions are no longer supportable. Each aspect of a manufacturing process must now be "best of class." Unfortunately, no one vendor can possibly supply "best-of-class" solutions in each of the diverse categories of control and communications technologies deployed in a typical plant.

A best-of-class system can be composed only of best-of-class components and, by extension, must therefore be a multivendor system. Of course, the architectural and support implications of this are dramatic and dramatically different from the PLC status quo.

Speaking the Language

Earlier, I noted the trend toward service as a differentiating factor among PLC vendors that recognize their products may be slipping toward commodity status. The same factors are driving many other PLC-using manufacturers toward higher levels of customer service. This service mandate requires better information flow within a company, as well as between the company and the outside world, and in many cases this information must originate or terminate at the shop floor. The simple reason is that customers are demanding more customized products on the one hand and more information about product scheduling and product qualitative measures on the other.

Now, if you're a major retailer expecting a shipment of 2,000 wheelbarrows from your vendor's manufacturing plant, you probably don't want scheduling information in the form of a DeviceNet feed or any other "factory" protocol. Instead, you want it in the form of a Web page or an extensible markup language (XML) feed that's easily accommodated by your human employees or your enterprise information systems.

Here's the tricky part: XML

didn't exist a few years ago, and next year an extension called SOAP is likely to supercede it, and the year after that. . . ? This parade of protocols is being managed in the information technology field through the intensive development of hundreds of specialized companies, with the result being that corporate information systems can track the new protocols quickly and seize the advantages they offer.

Now that the control systems at the plant floor level are being called on to participate in the conversation, they too must be prepared to track the development of new protocols. This implies that the technologies deployed in the data center must find a suitable, conformant home at the control level, which in turn implies the use of similar computing platforms and communications standards at that level.

An Open Path

Fortunately, there's a base of technology waiting to be deployed in the manufacturing plant that meets the criteria outlined above. Developed for and employed in applications deeply embedded in equipment in industries as divergent as semiconductors, telecommunications, and the military, board-level components conforming to CompactPCI and PC/104 standards are available that meet the needs of most automation applications. Additional pieces of the puzzle either already exist or are rapidly becoming available and practical, including standard operating system support and a growing base of applications software.

An emerging industry will make these pieces available in the form of complete, customized systems, just as today you can buy a system from Dell Computer containing the specific brand and style of disk drive, monitor, video board, and communications interface your application requires.

The implications for motion control are profound. Until now, motion control has often been treated as control's poor stepchild, relegated to afterthought status and accommodated in most control systems over a slow serial data connection. The migration to an embedded system architecture employing standard computer bus structures allows specialized motion control systems to share a backplane with the master control CPU, greatly increasing the opportunities for data exchange and coordination. In conjunction with an environment allowing and encouraging multivendor solutions, this approach will remove much of the compromise inherent in system design today.

Egalitarian Control

This leads us to the most fundamental implication of all. The departure from the single-source paradigm of control reduces the risk of purchasing any one system component from a given company, as many plug-compatible and software-compatible equivalents may be available. This frees the user to select best-of-class components in each category, but it also opens the control market to a proliferation of new, and possibly smaller, suppliers offering better mousetraps.

With the passage of time, this could transform the controls industry from its current, somewhat moribund state into something approaching the dynamism of the computer and software industries today. Perhaps it was the beginning of this trend Bullock noted during his visit to National Manufacturing Week! MC

Make Contact!

Kenneth Crater, founder and president of Control.com Inc., is a recognized leader in the automation controls industry. As co-founder and president of Control Technology Corporation in 1975, Ken established the company that became a foremost provider of state language control in factory automation. Ken was also a co-founder of the Industrial Computing Society and served as its first president. He was recently elevated to Fellow of that society for making significant advances in the technologies of machine automation and PLCs, including his early work in the pioneering of state language for machine control.