Sean Leonard on OPC

Sean Leonard is the Director of Matrikon's OPC business. He's the first speaker on the last day- not the best spot, of course, but we'll see. His presentation is called "Interoperability: The Key to Business Agility" and is subtitled "The Business Case for OPC." The first question raised at this conference, Leonard reminded us, was about connectivity. But on to the business case. How do you balance shareholder demands for profitability with regulator and customer demands for reliability in asset intensive, legislated industries? All the time, while facing unprecedented change, aging equipment assets, increasing compliance and environmental requirements, diminishing expert knowledge as operators retire and a global market is creating new competition... "This is the modern industrial paradox," Leonard said. "How do we do more with less? How do we reduce maintenance costs, operating costs, emission limits, labor, inventories, and downtime? How do we increase reliability, performance, compliance, safety, availability, and asset life? And how do we do all of these things at the same time?" This is a very harsh environment. It is not easy, and those that manage that balance are the ones that have the competitive advantage. We call that competitive advantage "agility." Agility requires informed decisions: get the right data from the source, with the right quality and information; reliably and at the right time, and securely deliver it to the right people. That's what we need to do.  This is all about information flow. The technologies we do at Matrikon are about helping people maximize free flow of information. This data is in a whole lot of different silos and even made by different vendors, and the data is also geographically dispersed. The interconnections between these data silos are complex, and wonderful, too. "It is definitely a complex problem to solve," Leonard understated. This implies that the entire problem is actually an integration problem. It is impossible to solve this integration problem without standards. We must have interoperability. Interoperability, as Bob Mick of ARC Advisory Group has said, is the ability of applications and systems to share information and exchange services with each other based on standards, and to cooperate in processes using the information and services. To solve this integration problem you have to have application to application transfer of data, and that means you have to have interoperability-- and that means standards. Interoperability requires comprehensive standards. Standards bodies specialize, too. There are standards bodies by industry, by business area and function, by breadth and implementation depth, and by technical approach and design. "The one standard that has done an exceptional job transfering data between applications is OPC," Leonard opined. OPC standards span all domains, standardizes on technology, and provides data across all corporate layers. So what's OPC? It used to be OLE for Process Control. It is a published standard based on ActiveX(OLE) COM and DCOM technology, extended to XML Web Services with domain agnostic application interfaces. Because it is domain agnostic is is used widely beyond process control. It started in the hardware level, moving data between hardware systems but it has evolved and moved to the business systems level in the enterprise. It isn't limited to process automation, either. It has become widely used in discrete manufacturing as well. "We've truly achieved shop floor to top floor connectivity using OPC. This isn't vaporware. This is happening today," Leonard said. Leonard shared a case study of an "international power company" that uses OPC. "The goal was the agility thing that I've been talking about," Leonard said. "They wanted to use this data and other market intelligence to make the right decisions faster to drive results." They needed to reduce the complexity of the architecture in their 51 plants. They found they had too many systems to maintain adequately. They needed several systems to interoperate: historians, control systems, accounting packages. After research, they found that the only way to integrate all of this was using OPC. The results are clear. A single IT team can manage the entire fleet. There was no need to standardize on a single Historian solution-- they see a reduction in training, deployment costs and increased plant buy-in of the architecture. They have driver level redundancy, using MatrikonOPC ORB, with redundant data paths to corporate historian. Now they have a manageable data architecture. Data is available at the top floor, and decisions are made with streaming data in real time. The time to implement this integration is measured in months, not years. There were some unplanned advantages too, for standardizing on OPC. IT Health monitoring via OPC has been implemented and condition based maintenance fell out of the integration project since they wound up having the data anyway. "The only way to make this possible is leveraging the standard of OPC," said Leonard. From an ARC study: How important is a standards-based architecture when evaluating automation systems? As Homer Simpson says, "D'oh!" Over 95% said important or higher. Another question from the study: Do you favor suppliers who support OPC? 91% positive answers. What is the approximate percentage of OPC used for your Plant Connectivity today, the study asked. the majority of respondents said they are using OPC for at least 50% of their connectivity. Over 70% of end users report that they will be using OPC for connectivity for the next n years. The flavors of OPC: Plant floor: OPC DA; from the plant to the manager: OPC HDA, and from the plant to the enterprise, OPC UA. OPC is becoming the benchmark for standardization and interoperability from historian to ERP. "If you think about Sarbanes-Oxley, the accountants are going to be walking further into the organization," Leonard said, "and there has to be a way for them to get access to that data without manual data searching." "The future of OPC is going to be much bigger and go much farther than we can imagine," Leonard said. The driving forces for the future The enterprise requires more data, more timely. A single vendor will not rule the world. You will have systems from different vendors working together. System communications failures will occur Process information will remain critical There will be a focus on security. "This is a harsh competitive environment. Business leadership is challenging. Agility requires timely data. which requires interoperability, which requires standards, and OPC is the only choice." Leonard concluded. I asked when OPC UA was going to stop being vaporware. He said that we should start seeing small apps within the year, but full adoption will be within three to five years. I also wanted to ask the following question, but time ran out. So here it is, in the blog. There are significant and well known security issues with OPC. Perhaps it is fair to say there are serious exploitable security holes in current OPC implementations. How are they going to be resolved?