Moving information among various components of an automated manufacturing enterprise with as little programming as possible has been high on the wish list of automation and information technology engineers for a long time. Rich Ryan, president of Rockwell Software, discusses the company’s “federated data model” and current customer expectations of automation suppliers with Automation World Editor, Gary Mintchell.
AW: How far has the scope of Rockwell Software expanded beyond programming and human machine interface?
Ryan: If Rockwell only dealt with automation or PLC (programmable logic controller) software, it wouldn’t be sufficient for our customers. So, we have expanded the scope of what we offer. Not only in automation, but also on the design side and manufacturing execution covering ongoing production.
AW: What has Rockwell Software done to help connect enterprise information?
Ryan: For years we’ve been talking shop-floor-to-top-floor, and it’s a great story. The concept is certainly to connect things. The problem is that no one does it. If you tried, it’s hard to do. And even if you succeeded, trying to find a way to integrate that software architecture into business software in a way that doesn’t kill you is hard.
Then we had an epiphany that PLCs on Ethernet can connect everything. With this approach, the good news is that it’s a lot like the Internet, where search engines can find all sorts of things that you’re looking for. The bad news is that there are no good factory search engines. Nobody knows where the data goes or what it means.
It’s not about moving data, but about making it relevant. You have to determine who gets access, how fast the network must be and how not to overwhelm the people who are designing systems.
AW: How are you doing this?
Ryan: A lot of our work has been on defining a common set of services. These services must work with existing automation infrastructures. Especially in North America, servicing existing brownfield plants is important. The strategy is to have services embedded in our own and partner products so that all data can relate in a meaningful way to people who want to put the enterprise together. We’ve coined the phrase “federating data” to describe this architecture. Data must reside and be controlled locally, but at the same time be part of a bigger picture. You’ll see us start to push that concept with something at the high end of the database world.
AW: Wasn’t OLE for Process Control (OPC) invented to do a lot of this work?
Ryan: OPC has solved a lot of problems for manufacturing communication. Then came XML and Web Services. It’s like the fact that dialing the phone has become easier and easier, but if one person speaks English and the other Chinese, then they still can’t share information. Just because two devices or applications communicate using XML doesn’t mean that they can understand each other.
Partnerships and alliances are critical to make all this work in a collaborative way. For example, look at the alliance of IBM with the automotive industry. If we didn’t tie together and work on IBM’s WebSphere, we couldn’t work in that industry. Our condition monitoring software maps right into maintenance management software and gives management a heads up on maintenance issues. This can only be done through collaboration. Technology is important, but relationships are critical.
AW: And just what is “federated data structure?”
Ryan: Previously, customers had two ways to connect plant information with business systems and integrate disparate data—component-based systems or distributed control solutions. Components often seem like a low-cost option, but integration, customization and testing can drive costs up substantially. Because each component is independent, services such as alarm detectors and tag databases are duplicated in each component, creating silos of information. Distributed control offers a high level of initial integration, but is less flexible because of its dedication to specific processes. And acquisition and maintenance costs are high due to the slowdown in the development and support of these systems.
With the federated data model on the automation layer, information is created once and made accessible throughout the system. A common address book of information allows data to exist in native locations, such as within controllers, graphics servers and other types of servers in the system, but be referenced from anywhere. For example, components that need to access a tag database “look up” the database location and form a link to that information. The federated data model has no single point of failure and maintains information integrity because data is shared—not duplicated—across applications.
Similarly, shared services across automation and information layers also improve on simple data transfer. Services are shared across all components so there is only one instance of each service (such as diagnostic log, tag database, security configuration and plant data model). This provides traditional shop-floor-to-top-floor connectivity, but because components can share common services and functionality, that means integration hassles, information silos and functionality overlaps are virtually eliminated.
Essentially, the federated data model is a software-based information model that allows enterprise components to share and access information and resources throughout a networked information system. With the federated data model, data remains distributed in its original, native environment (such as a controller). Interface points or “clients” that need information look up the location in a directory and display the information locally, regardless of location.
AW: With manufacturing in the doldrums over the last few years, what is Rockwell Software doing to combat the downturn?
Ryan: The other frontier is making the initial move into an automation system easier from the view of the total lifecycle cost. Budgets are down, and there are rigorous justification cycles these days along with high rate of return hurdles for everything. In the 1990s, it was good just to have the best technology. Now there is a need to reduce costs from design to downstream manufacturing.
AW: What kind of financial analyses are companies using? Anything new?
Ryan: Mostly standard financial analysis is used, but it varies from business to business. Some companies are more asset intensive than others. Automotive manufacturing financial models, for example, are different from those in the food business.
AW: Going back to lifecycle cost justification, do companies really go back and verify those costs after installation? How are they accomplishing reduced lifecycle costs?
Ryan: Yes, customers are really using the analysis to verify the cost justification used in the purchase. To accomplish this, they want to use more off-the-shelf software because it’s less people-intensive to support from an information technology (IT) perspective. Previously, all of the departments were compartmentalized, each with their own budgets. Now they’re starting to look across all of the boundaries when they put projects together. They solve a holistic problem rather than just a department problem.
AW: Are customers asking about cost/gain sharing on projects?
Ryan: Shared pain and gain—it’s a very interesting topic. If Rockwell clearly is engaged at the system level and the customer doesn’t have a clear understanding of business impact of the project, then we sit down and tell them, “Let’s do a clear before-and-after analysis.” They often talk about shared gain, and we have done several. But these projects are the exception. At the beginning, the customer is testing the reality of the project. We’ve found that when the project gets close to reality, they want the entire return for themselves.
There are no marginal projects anymore. The thought process customers go through is more like, can I do this one with this IRR (internal rate of recovery, a measure of cash flow) or this one with its IRR. Marginal projects don’t even make it to the list. So, we do some consultative work with the customer, that is, we come back with a list of best projects and services for the customer. Then it’s much more of a discussion of what’s best for the customer’s business process.
More and more, customers want us to provide not just technology, but also services. We are actually putting system architects on board at customer sites to help architect the project before defining the scope of the project.
AW: You mentioned earlier the necessity of moving into other manufacturing software areas. What are some?
Ryan: Maintenance and customer support have been viewed as reactive processes. We now try to be proactive in these areas. One way is with asset management and condition monitoring. Another evolved from initial software support contracts to our Tech Connect program that offers customers the ability to always be connected to our technical support technicians. We can help with any support operations in the plant, for example, providing proactive upgrade notices for each of their projects or even taking over the operation of the tool crib. The other service area is helping things like regulatory compliance and remediation around 21 CFR Part 11 (which applies to electronic records for FDA regulations.) We can do a site audit and make recommendations to help gain or maintain compliance.
When you start to look at this range of services, now you understand why a fundamental platform is so important. All of these services must work together. The pieces of an integrated architecture include automation system, visualization components and network systems. On top of that, we needed concepts like how to federate data and Web services.
AW: So, is federated data a reality?
Ryan: Just about a year ago, we started embedding components in products before even talking about this whole concept of federated data. So there were a lot of components out there when the architecture was introduced, and customers could see value right away. One concept is a distributed naming architecture, since finding data is a key part of what we want to do. Our Factory Talk product audit tracks who and when and what was changed and reports to a supervisory system so that reports for 21 CFR Part 11 compliance can be automated. But all of the software components had to be embedded first, and they have been shipping for about 18 months.
See sidebar to this article: Profile
