Introduction to OPC

Introduction to OPC (OLE for Process Control) 1 Contents OPC description 3 Introduction 3 Origin and uses 3 Development 3 OPC Foundation 4 OPC Standards and Specification Groups 4 Technical overview of the OPC Data Access interfaces 5 Introduction 5 The technology 6 The logical object model 7 Typical server design 8 The group and the item 8 The server interfaces in detail 9 The client side interfaces 11 OPC Unified Architecture 12 Innovations 12 Protocols 13 Specifications 14 OPC UA communication stack 16 OPC UA security 17 OPC UA API 18 Internet sources 19 2 OPC description (From Wikipedia) Introduction OLE for Process Control (OPC), is the original name for an open standards specification developed in 1996 by an industrial automation industry task force. The standard specifies the communication of real-time plant data between control devices from different manufacturers. After the initial release, the OPC Foundation was created to maintain the standard. Since then, standards have been added and names have been changed. Currently (June, 2006), "OPC is a series of standards specifications". (Seven current standards and two emerging standards.) "The first standard (originally called simply the OPC Specification"), is "now called the Data Access Specification", or (later on the same page) "OPC Data Access", or OPC Data Access Specification. OPC is generally understood to stand for "OLE for Process Control", even though no page on the OPC Foundation website suggests that the letters "OPC" ever stood for anything, except for some content written by member companies about themselves. Origin and uses The OPC Specification was based on the OLE, COM, and DCOM technologies developed by Microsoft for the Microsoft Windows operating system family. OPC was designed to bridge Windows based applications and process control hardware and software applications. It is an open standard that permits a consistent method of accessing field data from plant floor devices. This method remains the same regardless of the type and source of data. OPC servers provide a method for many different software packages to access data from a process control device, such as a PLC or DCS. Traditionally, any time a package needed access to data from a device, a custom interface, or driver, had to be written. The purpose of OPC is to define a common interface that is written once and then reused by any business, SCADA, HMI, or custom software packages. Once an OPC server is written for a particular device, it can be reused by any application that is able to act as an OPC client. OPC servers use Microsoft’s OLE technology (also known as the Component Object Model, or COM) to communicate with clients. COM technology permits a standard for real- time information exchange between software applications and process hardware to be defined. Development The OPC Unified Architecture (UA) has been specified and is being tested and implemented through its Early Adopters program. It can be implemented with Java, Microsoft .NET, or C, eliminating the need to use a Microsoft Windows based platform of earlier OPC versions. UA combines the functionality of the existing OPC interfaces with new technologies such as XML and Web Services to deliver higher level MES and ERP support. It looks to become the standard for exchanging industrial data, replacing FactoryTalk, Archestra, some Modbus applications, and OPCDA. 3 OPC Foundation The OPC Foundation (www.opcfoundation.org) is an industry consortium that creates and maintains standards for open connectivity of industrial automation devices and systems. The OPC standards specify the communication of industrial process data, alarms and events, historical data and batch process data between sensors, instruments, controllers, software systems and notification devices. The OPC Foundation started in 1994, as a task force comprised of five industrial automation vendors, with the purpose of creating a basic OLE for Process Control specification. OLE is a technology developed by Microsoft Corporation for the MS Windows operating system. The task force released the OPC standard in August 1996. The OPC Foundation was chartered to continue development of interoperability specifications and includes manufacturers and users of devices, instruments, controllers, software and enterprise systems. OPC Standards and Specification Groups OPC Data Access This group of standards provides specifications for communicating real-time data from data acquisition devices such as PLC's to display and interface devices like Human-Machine Interfaces (HMI). The specifications focus on the continuous communication of data OPC Alarm and Events Standards for communicating alarm and event data on demand, as opposed to the continuous communications in the OPC Data Access group OPC Batch Standards to address the needs of batch processes OPC Data eXchange This group of standards addresses server to server communications across industrial networks. The standards also address remote configuration, diagnostics, monitoring and management communications OPC Historical Data Access Standards for communicating stored data OPC Security Standards for controlling client access to OPC compliant devices and systems OPC XML-DA Builds on the OPC Data Access specifications to communicate data in XML. Incorporates SOAP and Web services OPC Complex Data Standards for specifying the communication of complex data types such as binary data and XML documents OPC Commands Standards for communicating control commands to devices and systems OPC Unified Architecture An entirely new set of standards that incorporates all of the functionality of the above standards (and more), but does so using cross platform web services and other modern technology. 4 Technical overview of the OPC Data Access interfaces Al Chisholm, Chief Technical Officer, Intellution Inc. 1 Edgewater Drive, Norwood, MA 02062 781 769 8878 (http://www.gefanucautomation.com/opchub/opc_interfaces_overview.asp) This paper presents a fairly detailed technical overview of the Data Access interfaces. It begins by describing the problem these interfaces are designed to solve, the functionality they provide and the object model they employ. Following this is a review of the specific interfaces provided, including a brief discussion of the specific methods exposed by those interfaces. Introduction This paper contains a fairly detailed technical overview of the OPC (OLE for Process Control) Data Access Interface. It assumes that the reader has some technical background in COM (Component Object Model) and object oriented programming. This paper will also talk about where OPC Data Access fits in the architecture of a control system and about the objects and methods that the OPC Interface presents to the programmer. In addition to talking about WHAT the objects look like, this paper will also talk a bit about WHY they look the way they do. Which is to say it will try to answer the question, “What were those guys thinking when they designed this stuff…”. This paper talks primarily about the Custom (C++) interface as that is what server vendors and most serious client vendors need to understand and implement. The left figure above illustrates ‘The I/O Driver Problem’. Clearly each software driver for a new device requires a unique, device-specific chunk of code to talk to the device or network. The need for this device specific code is not a problem OPC is trying to address. Rather, this is something Fieldbus is trying to address, and Devicenet, and Profibus, and Lonworks, and a host of others. The problem that OPC deals with is that each of these software drivers also presents a different software interface to the calling application. As a result, each application also requires a unique chunk 5 Software Driver Display Application Trend Application Report Application Software Driver Software Driver Software Driver Software Driver Display Application Trend Application Report Application Software Driver Software Driver Software Driver of code for each driver, device or network it wants to connect to. This obviously makes it difficult to reuse applications with different sets of process interface equipment. OPC Solves this problem be creating a ‘software bus’ as shown in the right hand figure. Applications only need to know how to get data from OPC data sources. As a result, they are simpler, smaller and easier to use. Device Drivers (servers) only need to know how to provide data in a single format (OPC Server). As a result they are easier to write (and there is more of a market for such servers). Although the MAIN problem OPC solves is the ‘I/O Driver’, you can see in the figure above that OPC is flexible enough to be used not only between Devices and SCADA, SoftPLC or DCS systems, but also between the SCADA SoftPLC or DCS engines and the high level applications such as HMI, Trends, Reports, etc. which use their data. In this architecture, the SCADA system, the DCS system or the SOFTLOGIC system really just represents a ‘smarter’ device. The technology Now for some technology basics… Why, for example, does OPC use COM? COM is Microsoft's Component Object Model which is the ‘90’s’ way to do APIs (subroutines). In addition to being widely used, another advantage of COM is that Microsoft provides a lot of the useful common ‘plumbing’ required to connect the clients and servers. This includes DCOM (Distributed COM) which allows creation of network-based applications with a minimum of development effort. As noted earlier OPC is flexible enough to be used at different layers within the system architecture and is specifically designed to work well over a network. Efficiency is insured by the fact that (a) OPC can be exception based and (b) unlike DDE, OPC can pack 100s or 1000s of data items into each transaction. Performance is also guaranteed both by the support for multiple data items per transaction and by the fact that COM and thus OPC servers can be created in several models; inprocess, local and remote. For the highest possible performance, Inprocess servers incur 0 overhead. Millions of transactions per second are possible using this approach. Local servers allow 1000s of transactions per second. Even remote servers can manage 100s of transactions per second. And again, unlike DDE, each transaction can include many data items. 6 Client Applications SCADA System Software Driver DCS System OPC OPC OPC OPC OPC The logical object model The OPC interfaces look the way they do largely because of the assumptions the OPC working group made about the applications. The main assumptions are listed below. • subset of the Tags available within the underlying Control system is needed for applications. • many different subsets of Tags at different times and at different resolutions are needed for applications. • appilications should be independent of the process objects It is important to stress that first point. A fundamental assumption is that there is some sort of control or monitoring engine running independently of anything OPC is doing and that OPC is just a window into this engine’s data. That last assumption is the only controversial one. This issue will be discussed again below. In any case, these assumptions lead logically to the model in the following figure. At the top of this figure is an OPC Server object . This is the COM object to which the application first connects. Below this is a collection of OPC Group Objects. These are created dynamically by the applications to hold lists of Tags and attributes (which OPC refers to as Items). An HMI might create a Group for each open picture. A report package might create a group to access data for each report. The contents of the Group and item collections may vary over time based on the needs of the applications. (Again this has no effect on the underlying control system). This is actually somewhat analogous to RowSets as used on OLEDB. There is a lot of data in the database, you want to look at a subset of it in your application., and that subset may vary based on your needs at the time. Which brings us back to the assumption about process object independence. There were two fundamental approaches which could have been taken to this; the first is the ‘rowset’ approach seen here. The second is a more purely object oriented approach in which the server would ‘proxy’ the process objects and expose their properties and methods to the applications. The OPC working group felt the pure object approach was basically much to complex. Two issues in particular were those of efficiency and getting the vendors to agree on the nature and properties of the specific objects. Do note that the OPC approach does allow a vendor to expose data from an OODB through a very flexible names space. 7 The Logical Object Model OPCServer OPCGroup(s) Custom and Automation Interfaces OPCGroup(s) OPCGroup(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) Typical server design The figure above shows a typical server design. The SERVER provides management of the OPC Groups and also controls, mediates and optimizes access to the physical devices by multiple clients. The Server is essentially an I/O Driver which ‘understands’ how to talk to some vendor specific data provider (hardware or software) and which Exposes the data from this data provider via the standard OPC Interfaces. The OPC sample server available at the OPC web site provides a very good implementation of the upper two layers of the diagram. Various commercial toolkits provide frameworks or implementations of one or more additional layers. The group and the item The GROUP provides a convenient way for an application to organize the data it needs. Different Groups can be used by different parts of the application; can have different refresh rates; can be polled or exception based. Operator Displays, Recipes, Reports might each use one or more groups. The ITEM provides a connection point to a value in the physical device. Typically this is a single variable such as a process value or setpoint. The ITEM provides information to the client; Value, 8 The Logical Object Model The Item OPC Server The ‘Real’ SCADA or DCS System FIC101 TIC101 FIC102 TIC102 FIC103 TIC103 FIC104 FIC105 OPC Groups OPC Item OPC Item OPC Item OPC Item OPC Item Typical Server Design OPC/COM Interfaces OPC Group & Item Management Item Data Optimization and Monitoring Device Specific Protocol Logic Hardware Connection Management Quality, TimeStamp, and Data Type. As mentioned before, the OPC item is a transient object which exists within the OPC server. It is used to create a connection between the server and the real data. The OPC interfaces always return the process data in a VARIANT. It is assumed that the server has a ‘native’ or ‘prefered’ datatype which is also known as the canonical datatype. OPC allows clients to read this canonical type (e.g. 4 byte float). It also allows them to specify that they want the data returned in some other format (e.g. ASCII). The server interfaces in detail • IOPCServer • IOPCBrowseServerAddressSpace (optional) We will now review the interfaces on these objects in more detail discussing first what functionality they provide and then listing the methods of each interface to show how that functionality is provided. The Server interfaces are listed above. They allow the application • To create and delete groups • To browse the available tags • To translate error codes into meaningful text • To obtain status information about the server IOPCServer • AddGroup • RemoveGroup • GetGroupByName • CreateGroupEnumerator • GetErrorString • GetStatus The IOPCServer Interface allows the client to manage Groups. This is done using the Add, Remove, Get and Enumerator functions. GetErrorString allows the client to translate errors (HRESULTS) into strings. GetStatus allows the client to monitor the overall status of the server. IOPCBrowseServerAddressSpace • QueryOrganization • ChangeBrowsePosition • BrowseOPCItemIDs • GetItemID The browser interface (which is optional but which any worthwhile server should provide) allows the application to browse the tag names and attributes available within the server. It is carefully designed to work with essentially any organization; from a flat list of PLC registers to a hierarchical area/group/ loop organization to a fully object oriented database. It does this by mapping all of the above into a hierarchical name space. This is intended to allow the application to present the results in an Explorer like browse tree. QureryOrganization tells the client if the space is flat or hierarchical. If the space is hierarchical, ChangeBrowsePosition moves up and down the hierarchy. BrowseOPCIDs returns an enumeration of the leafs or branches at a particular node. GetItemID returns the fully qualified name of an item. (This allows complete independence from the syntax and delimiters used by the vendor). 9 The group managment interfaces in detail The Group Interfaces allow the application • To add and remove items from groups • To Manage the accuracy (update rate) of the data in the group • To read or write values for one or more items in a group • To Subscribe to data in the group on an exception basis. Note that the ITEM is not defined as a COM object and does not expose any interfaces in the Custom model. There are a variety of reasons for this, most related to the efficiency and complexity of the server. IOPCGroupStateMgt • GetState • SetState • SetName • CloneGroup After a client creates a group, IOPCGroupStateMgt allows control of the behavior of that group. It can change the name or update rate and a few other parameters of the group. It can also activate or deactivate the group. For example, an HMI might want to deactivate a group (but not delete it) if the display page using that group was minimized or hidden. CloneGroup can also create a copy of the group. IOPCitemMgt • AddItems • ValidateItems • RemoveItems • SetActiveState • SetClientHandles • SetDatatypes • CreateEnumerator IOPCitemMgt allows the client to add items to the group. For example, an HMI might create a group for each display page and then add to those groups all of the items referenced by that page. The most important functions here are AddItems and RemoveItems. The other functions are basically bells and whistles. 10 [...]... protocol independent and found the basis for the whole OPC UA functionality The transport layer these methods into a protocol, which means it encode/decode ("serializes"/"de-serializes") the data and transmits it over the network Currently there are two protocols specified for this purpose One is a binary, towards high performance optimized TCP protocol and as second, a Webservice-based one The OPC. .. application developer to what certificate store the UA application gets bound to For instance, it is possible to use the Poublic Key Infrastructure (PKI) of an Active Directory 17 OPC UA API For UA developers, the possibility gets provided to code based on C API, C++ API or a NET API, directly All API support the same functionality The communication stack and API get provided by the OPC Foundation .Net... provided by the OPC Foundation New is the portability level which allows it in an easy way to port the UA ANSI C stack also to other target platforms A port layer for Windows and Linux gets also provided by the OPC Foundation As described before, based on the API the applications can be developed, similar to how it was when coding based on COM in the past At the OPC UA DevCon in October 2006 in Munich... Protocols As described before there are two protocols An application programmer will recognize this only via the different URL he has to pass for binary protocol opc. tcp://Server and http://Server for WebService Otherwise OPC UA works completely transparent to the API 1 Binary protocol • • best performance, the least overhead takes minimum resources (no XML Parser, SOAP and HTTP required -> important for... (From Wikipedia) OPC Unified Architecture is the most recent OPC specification from the OPC Foundation and differs significantly from its predecessors After 3 years of specification work and another year of prototyping the first version of Unified Architecture is now being released Innovations Although the original binding to COM/DCOM helped OPC to distribute well but nevertheless had also its drawbacks... method the client needs to implement is OnDataChange The client will get a callback into this method if any of the following occurs: • • An asynch read or write completes One or more values change in a subscription The data comes back packed into a shared global region The specification shows how to unpack the data (as does the sample code) 11 OPC Unified Architecture (From Wikipedia) OPC Unified Architecture... Security, is needed 18 Internet sources 1 OPC Foundation (www.opcfoundation.org) - The Object Linking and Embedding for Process Control (OPC) Foundation is an industry consortium that creates and maintains standards for open connectivity of industrial automation devices and systems The OPC standards specify the communication of industrial process data, alarms and events, historical data and batch process data... client provides a list of items to read and gets back a list of values and/or errors or provide a list of items and values to write and gets back a list of errors These functions always run to completion IDataObject • • DAdvise Dunadvise The IDataObject is a standard Microsoft interface OPC requires that vendors provide the DAdvise and DUnadvise methods These are used to hook up callbacks which are... have no access to sources and therefore have to live with bugs or insufficient implementations) That and various other conclusions generated the decision to develop a new and independent communication stack for OPC UA which replaces COM/DCOM The outstanding characteristics of this communication stack are • • • • • • portable ANSI C implementation scalability from embedded controllers up to Mainframes... in Net and therefore gets converted directly into Net structures and objects This processes a better performance than deserialzing into a C structure first and then copying the data to a Net structure afterwards JAVA Implementation Various stacks for JAVA are already in development But similar to Net there are principially 3 variants Currently it's hard to determine which one is the fastest 1 Mostlikely, . Model OPCServer OPCGroup(s) Custom and Automation Interfaces OPCGroup(s) OPCGroup(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) OPCItem(s) Typical server design The figure above. communications OPC Historical Data Access Standards for communicating stored data OPC Security Standards for controlling client access to OPC compliant devices and systems OPC XML-DA Builds on the OPC. Model The Item OPC Server The ‘Real’ SCADA or DCS System FIC101 TIC101 FIC102 TIC102 FIC103 TIC103 FIC104 FIC105 OPC Groups OPC Item OPC Item OPC Item OPC Item OPC Item Typical Server Design OPC/ COM