An epic battle is under way for ownership of the control system architecture marketplace. This time, the weapon in every combatant's armory is the Framework, with each vendor developing a slightly different one. If frameworks do become critical--which is debatable in a Microsoft-based world--buying decisions made now by process control end users may well determine the next king of the control system world.
Most major control system vendors are promoting their own overarching architecture or framework to ease integration of plant floor and enterprise systems. All of these frameworks use industry standards such as OPC, DNA for Manufacturing, and .Net; and all of the frameworks add to these standards with operating system extensions that provide functionality relevant to process control applications.
Despite vendor claims of using standards and ease of integration, many users are skeptical, concerned, and confused. Skepticism and concern are caused by fears that vendors once again may be trying to fence in customers with proprietary architectures and products. "Vendors need to understand that end users no longer want to be locked into a box. Instead, open platforms and modularity of their products will be required," says Francisco Campa, director of engineering for The Dixie Group, Calhoun, Ga.
A control system engineer with a major refiner says vendors are more interested in building walls than selling open systems. As evidence, he points to their strident efforts to sell him products that duplicate functionality of products his firm already owns. "We already use OSIs PI product, but if we want good long-term trending and analysis, we're strongly encouraged to buy the vendor's data historian," says the engineer. "If vendor systems were truly open, they would be better served by creating a few killer apps instead of many mediocre ones."
A more colorful description of concerns is voiced by Ferenc Szakcs, CEO and president of system integrator Cason Engineering, a system integrator headquartered in Erd, Hungary. "Framework software products are the top level of the hypnotic dreamworlds produced by the different vendors," Szakcs says. "Maybe manufacturers seriously believe framework software products will help in the integration of different platforms, but according to what we experienced until now there are not too many reasons to be optimistic."
Continuing our world tour, similar concerns are voiced in Australia. "I am yet to be convinced that a true open standard will ever be created or prevail," reports Austin Davey, general manager of Visy Pulp and Paper, Tumut, New South Wales. "I do not believe vendors set out to create proprietary walls--I think this is a result of different vendors coming up with different ways of making things better."
Figure 1: Built on Standards
Frameworks are founded on "open" technologies and augmented as necessary to provide the necessary functionality for process control applications. Source: Invensys
Although acknowledging the prevalence of closed systems in the past, other users are optimistic about the future direction of the industry. "Contrary to their history, I believe that technology providers playing in this space will become more open and comply with digital convergence open standards," says Johan La Grange, executive for information management, Sasol Synfuels, Secunda, South Africa. "The underlying standard technology that companies like Honeywell use supports open communication standards such as TCP/IP, XML, and .Net."
Of course, all vendors claim enthusiastic support for open standards and systems--to do otherwise would be market suicide. "As the percent of revenues from services grows, it causes vendors like Rockwell to favor open systems," says John Baier, director of software architecture, Rockwell Automation (http://www.rockwellautomation.com). Most of the major control system vendors are making a strong push into services, and they are finding integration is greatly eased with open systems.
Many users are worried that buying a vendors framework products today will restrict product choices in the future. Users want to keep their options open so they can easily use the best products in each category regardless of vendor. Perhaps above all, users are very confused about just what a framework is and about how it will affect their control systems.
What the %$#@! Is a Framework?
A framework is not a product available for purchase by an end user, nor is it an operating system. A framework is instead a set of tools, rules, and standards that internal and external developers use to create software applications and hardware products--a type of development system. Applications and products created with a framework development system will run on standard operating systems layered with framework operating system extensions.
The target market for frameworks is not the end user, it is software and hardware developers, both internal and external to the framework vendor. End users are the target market for products developed using frameworks. Vendors promoting frameworks believe Microsoft products need to be extended and supplemented to provide optimal performance in the process control arena.
Not all major control system vendors are buying into the framework concept. "We strongly believe that connectivity issues and process operations are the main areas of concern for end users, and we will continue to concentrate our efforts in these areas," says Duncan Schleiss, vice president of process systems marketing, Emerson Process Management (http://www.emersonprocess.com). "We will not develop a framework product because we feel that end users will be better served by Microsoft technologies, industry standards, and our own applications as opposed to proprietary operating system extensions."
Whether they agree with the framework concept or not, most of the major control system vendors sell software applications designed to run on operating systems such as Windows, Linux, and Unix, such as HMIs, soft PLCs, and asset management systems. Many of these same vendors also sell hardware products with embedded software functionality: PLCs, DCS controllers, and analyzers, for example.
Before the introduction of frameworks, internal development of these software and hardware products often would be performed independently. Third-party companies also would independently develop products tailored to work best with one vendors offerings. Independent development meant duplication of effort for common functions and difficulty of integration among different hardware and software products.
Frameworks are designed to provide a common platform for hardware and software development for a vendors entire product line. Frameworks are also intended to provide a common platform for development of third-party products. Vendors are providing framework development tools to third-party developers for very reasonable and highly negotiable fees to encourage use of their tools.
There are definitely parallels between the framework competition and the PC operating system battles. Microsoft, IBM, and Apple battled for years to win the hearts and minds of software and hardware developers. Each wanted software firms to write applications using their development packages or frameworks, because these software applications would then run best on that companys operating system.
Microsoft wanted PC manufacturers to ship their machines with Windows, and IBM pushed these same manufacturers to use OS/2. Apple instead took the proprietary hardware path and decided to focus their marketing efforts on software developers. We all know how that battle ended, and it is obvious that Apple made the wrong decision with respect to proprietary hardware. IBM had the right strategy, but lost the battle because of poor marketing as compared to Microsoft.
Framework vendors know what happened to IBM and Apple, and they hope to emulate Microsoft. At this point, many users are probably wondering why the framework vendors dont instead continue using Microsoft development tools and operating systems along with industry standards pertinent to process controls such as OPC, DNA for Manufacturing, and even .Net. We were wondering the same thing, and we talked to vendors and end users to get some answers.
What's Wrong With Windows?
All major control system vendors will continue to develop products that use Microsoft operating systems, and all also plan to use .Net functionality where appropriate. "With our WPKS product, industry standards and technologies are explored and leveraged first to ensure an open, flexible solution platform," says Jamie Bohan, manager of Honeywell's Uniformance product line (http://www.acs.honeywell.com). "These standards are only augmented as needed to deliver the functionality required by industrial applications."
All major control system vendors agree on building with Microsoft technologies, but those that offer frameworks contend that Microsoft does not and will not provide all of the specialized services and functions needed for process control. These include alarm handling, real-time control, version management, powerful security measures, remote system diagnostics, and a host of other features. Framework vendors also are concerned about the relatively short product lifecycles of Microsoft technologies, and they claim their frameworks can insulate users from these short-term vagaries.
While some major system vendors say Microsoft plumbing along with OPC will be sufficient and other needs should be addressed within each product or on a custom basis, framework vendors feel operating system extensions are needed to extend the capabilities of Windows and .Net.
For example, many control system hardware and software components generate alarms. Framework vendors see a need to develop and provide one alarm handling service that can be used by their entire family of products. Without a framework, each product in a vendors portfolio must have its own alarm handling routine.
These alarm handlers are often developed independently with little or no thought to commonality. This causes three major problems for vendors and users: First, there is massive duplication of effort as each product development team creates its own alarm handler. Second, integration of alarm handling at higher levels in the control system is complicated. Finally, ease of use is compromised because end users have to learn how each product handles alarms.
Again, there is a parallel to Microsoft. If Microsoft did not have a common set of development tools and standard operating systems, each desktop application would need its own routine to save a file. File saving routines would be developed independently for a vendors word processor, for its spreadsheet, and for its database.
Each application developer would have to write a driver for each type of storage device such as a hard disk, a CD burner, or a floppy disk. File save features such as Save As, Versions, and asking before overwriting a file would have to be incorporated into each application. Users might have to follow a different file saving procedure for each application, instead of just clicking on File and Save in the menu toolbar.
Control system vendors seem to agree that Microsoft has a handle on file saving, and they plan to continue to use this service. But Microsoft has no routine that specifically addresses alarm handling, though some of the company's underlying technologies such as messaging services can be used by vendors as an integral part of their alarm handlers.
So a framework would include one alarm handler for embedding into every one of a vendors relevant hardware and software products. That vendor should be able to develop one excellent alarm handler to use across an entire range of products, instead of developing many mediocre alarm handlers.
Vendors also envision a day when third-party developers will license and use their alarm handler. "In working with early OEM adopters, we are finding that our ArchestrA framework [Figure 1] saves a lot of infrastructure development effort and cost, and speeds time to market for the end product or application that is their core business," says Mark Davidson, vice-president of ArchestrA marketing at Invensys (http://www.invensys.com/archestra). "We give them a make/buy option, and if they choose to buy from us we provide them with the same toolkits we use to generate our own products."
Internal and external hardware and software developers will benefit because they can concentrate on their areas of expertise. They can leave the file saving to Microsoft, and the alarm handling to the framework. Integrators will benefit because it will be easier to group, store, and display alarms from different control system components, as long as these components were all developed under the same framework.
End users will benefit because alarm handling will be handled in exactly the same manner across many products, creating ease-of-use through familiarity. "We find that ease-of-use does not occur unless a product is used often," says Davey of Visy Pulp and Paper. "A lot of time, training, and effort is required to get to the 'ease-of-use' stage."
It all sounds great, but the main problem is that there will be multiple alarm handlers, one for each framework vendor. It would be great if all of the majors could get together to create one super alarm handler that could be used by all control system hardware and software products. Dont hold your breath on this one, but dont discount the possibility entirely.
There is also another intriguing possibility. Davidson mentions that Invensys' alarm handler relies extensively on underlying Microsoft technologies. He says that as Microsoft increases its alarm and event handling capabilities, the Invensys alarm handler will use more and more of Microsofts technology to replace its own. Davidson does not discount the possibility of completely eliminating the Invensys alarm handler if and when Microsoft supplies equivalent technology.
The vendors choosing to stay out of the framework arena are betting that Microsoft will include many industrial framework features in future versions of its applications, operating systems, and .Net. Microsoft has a long history of doing just this--remember when spell checkers, calculators, and address books were third-party products?
Frameworks can also contribute to ease of use in the mundane but critically important area of system documentation. "Products certified to Level 0 of IndustrialIT will have all product information in a standard form. This includes technical specifications, drawings, and manuals," according to Bob Hausler, the vice-president of IndustrialIT marketing with ABB (http://www.abb.com). Products certified to IndustrialIT Levels 1, 2, or 3 will comply with Level 0 as well as with various connectivity standards.
Looking for a Sign
Software buyers often look for the Windows symbol when buying application programs such as word processors, spreadsheets, and databases. This symbol assures a purchaser the product will run on Windows, will have some degree of interoperability with other Windows programs, and will operate similar to other Windows applications. With each application, pressing the Alt key with the F key, and then the S key, will save the file.
Each framework vendor sees itself as the Microsoft of the control system architecture market, providing a framework for internal and third-party product development. Each envisions a future where process control end users will look for its framework symbol before buying a control system product. Vendors want users to see their framework symbol as a seal of approval indicating ease of use, superior performance, and seamless interoperability with other products having the same symbol.
The framework vendors we talked to emphasize that using their framework does not preclude using third-party products developed under another framework or independently. This is certainly true, and integration of third-party products can be accomplished as long as these products adhere to industry standards. But it is also true it will be harder to integrate, use, and support a third-party product than a product developed with a particular vendors framework.
As the framework vendors see it, the winners in the framework battle will own and control the control system architectures on which new hardware and software products will be developed. The losers will be forced to develop their products using standards defined, controlled, and created by their competitors.
Vendors not buying into the framework concept believe Microsoft, industry standards, and separate applications will provide the services needed by process control applications. They are choosing to focus the bulk of their energies in other areas. They think that framework services will go the way of third-party spell checkers and calculators.
Make no mistake, these framework wars are an epic battle for the control system architecture marketplace. Buying decisions made now by process control end users will ultimately determine the success of the framework concept. And if the framework concept is found viable, end users will determine the dominant framework for the future. Ask questions (Table I). Choose carefully.
