Presents

Practical

Fundamentals of OPC

Revision 7.1

Web Site: www.idc-online.com E-mail: idc@idc-online.com

Copyright All rights to this publication, associated software and workshop are reserved. No part of this publication or associated software may be copied, reproduced, transmitted or stored in any form or by any means (including electronic, mechanical, photocopying, recording or otherwise) without prior written permission of IDC Technologies.

Disclaimer Whilst all reasonable care has been taken to ensure that the descriptions, opinions, programs, listings, software and diagrams are accurate and workable, IDC Technologies do not accept any legal responsibility or liability to any person, organization or other entity for any direct loss, consequential loss or damage, however caused, that may be suffered as a result of the use of this publication or the associated workshop and software.

In case of any uncertainty, we recommend that you contact IDC Technologies for clarification or assistance.

Trademarks All terms noted in this publication that are believed to be registered trademarks or trademarks are listed below:

Acknowledgements IDC Technologies expresses its sincere thanks to all those engineers and technicians on our training workshops who freely made available their expertise in preparing this manual.

Who is IDC Technologies? IDC Technologies is a specialist in the field of industrial communications, telecommunications, automation and control and has been providing high quality training for more than six years on an international basis from offices around the world.

IDC consists of an enthusiastic team of professional engineers and support staff who are committed to providing the highest quality in their consulting and training services. The Benefits to you of Technical Training Today The technological world today presents tremendous challenges to engineers, scientists and technicians in keeping up to date and taking advantage of the latest developments in the key technology areas.

• The immediate benefits of attending IDC workshops are: • Gain practical hands-on experience • Enhance your expertise and credibility • Save $$$s for your company • Obtain state of the art knowledge for your company • Learn new approaches to troubleshooting • Improve your future career prospects The IDC Approach to Training All workshops have been carefully structured to ensure that attendees gain maximum benefits. A combination of carefully designed training software, hardware and well written documentation, together with multimedia techniques ensure that the workshops are presented in an interesting, stimulating and logical fashion.

IDC has structured a number of workshops to cover the major areas of technology. These courses are presented by instructors who are experts in their fields, and have been attended by thousands of engineers, technicians and scientists world-wide (over 11,000 in the past two years), who have given excellent reviews. The IDC team of professional engineers is constantly reviewing the courses and talking to industry leaders in these fields, thus keeping the workshops topical and up to date.

Technical Training Workshops IDC is continually developing high quality state of the art workshops aimed at assisting engineers, technicians and scientists. Current workshops include:

Instrumentation & Control • Practical Automation and Process Control using PLC’s • Practical Data Acquisition using Personal Computers and Standalone

Systems • Practical On-line Analytical Instrumentation for Engineers and Technicians • Practical Flow Measurement for Engineers and Technicians • Practical Intrinsic Safety for Engineers and Technicians • Practical Safety Instrumentation and Shut-down Systems for Industry • Practical Process Control for Engineers and Technicians • Practical Programming for Industrial Control – using (IEC 1131-3;OPC) • Practical SCADA Systems for Industry • Practical Boiler Control and Instrumentation for Engineers and Technicians • Practical Process Instrumentation for Engineers and Technicians • Practical Motion Control for Engineers and Technicians • Practical Communications, SCADA & PLC’s for Managers Communications • Practical Data Communications for Engineers and Technicians • Practical Essentials of SNMP Network Management • Practical Field Bus and Device Networks for Engineers and Technicians • Practical Industrial Communication Protocols • Practical Fibre Optics for Engineers and Technicians • Practical Industrial Networking for Engineers and Technicians • Practical TCP/IP & Ethernet Networking for Industry • Practical Telecommunications for Engineers and Technicians • Practical Radio & Telemetry Systems for Industry • Practical Local Area Networks for Engineers and Technicians • Practical Mobile Radio Systems for Industry

Electrical • Practical Power Systems Protection for Engineers and Technicians • Practical High Voltage Safety Operating Procedures for Engineers &

Technicians • Practical Solutions to Power Quality Problems for Engineers and

Technicians • Practical Communications and Automation for Electrical Networks • Practical Power Distribution • Practical Variable Speed Drives for Instrumentation and Control Systems Project & Financial Management • Practical Project Management for Engineers and Technicians • Practical Financial Management and Project Investment Analysis • How to Manage Consultants Mechanical Engineering • Practical Boiler Plant Operation and Management for Engineers and

Technicians • Practical Centrifugal Pumps – Efficient use for Safety & Reliability Electronics • Practical Digital Signal Processing Systems for Engineers and Technicians • Practical Industrial Electronics Workshop • Practical Image Processing and Applications • Practical EMC and EMI Control for Engineers and Technicians Information Technology • Personal Computer & Network Security (Protect from Hackers, Crackers &

Viruses) • Practical Guide to MCSE Certification • Practical Application Development for Web Based SCADA

Comprehensive Training Materials Workshop Documentation All IDC workshops are fully documented with complete reference materials including comprehensive manuals and practical reference guides. Software

Relevant software is supplied with most workshops. The software consists of demonstration programs which illustrate the basic theory as well as the more difficult concepts of the workshop. Hands-On Approach to Training

The IDC engineers have developed the workshops based on the practical consulting expertise that has been built up over the years in various specialist areas. The objective of training today is to gain knowledge and experience in the latest developments in technology through cost effective methods. The investment in training made by companies and individuals is growing each year as the need to keep topical and up to date in the industry which they are operating is recognized. As a result, the IDC instructors place particular emphasis on the practical hands-on aspect of the workshops presented. On-Site Workshops

In addition to the quality of workshops which IDC presents on a world-wide basis, all IDC courses are also available for on-site (in-house) presentation at our clients’ premises. On-site training is a cost effective method of training for companies with many delegates to train in a particular area. Organizations can save valuable training $$$’s by holding courses on-site, where costs are significantly less. Other benefits are IDC’s ability to focus on particular systems and equipment so that attendees obtain only the greatest benefits from the training.

All on-site workshops are tailored to meet with clients training requirements and courses can be presented at beginners, intermediate or advanced levels based on the knowledge and experience of delegates in attendance. Specific areas of interest to the client can also be covered in more detail. Our external workshops are planned well in advance and you should contact us as early as possible if you require on-site/customized training. While we will always endeavor to meet your timetable preferences, two to three month’s notice is preferable in order to successfully fulfil your requirements. Please don’t hesitate to contact us if you would like to discuss your training needs.

Customized Training

In addition to standard on-site training, IDC specializes in customized courses to meet client training specifications. IDC has the necessary engineering and training expertise and resources to work closely with clients in preparing and presenting specialized courses.

These courses may comprise a combination of all IDC courses along with additional topics and subjects that are required. The benefits to companies in using training are reflected in the increased efficiency of their operations and equipment. Training Contracts

IDC also specializes in establishing training contracts with companies who require ongoing training for their employees. These contracts can be established over a given period of time and special fees are negotiated with clients based on their requirements. Where possible, IDC will also adapt courses to satisfy your training budget.

References from various international companies to whom IDC is contracted to provide on-going technical training are available on request.

Some of the thousands of Companies worldwide that have supported and benefited from IDC workshops are: Alcoa, Allen-Bradley, Altona Petrochemical, Aluminum Company of America, AMC Mineral Sands, Amgen, Arco Oil and Gas, Argyle Diamond Mine, Associated Pulp and Paper Mill, Bailey Controls, Bechtel, BHP Engineering, Caltex Refining, Canon, Chevron, Coca-Cola, Colgate-Palmolive, Conoco Inc, Dow Chemical, ESKOM, Exxon, Ford, Gillette Company, Honda, Honeywell, Kodak, Lever Brothers, McDonnell Douglas, Mobil, Modicon, Monsanto, Motorola, Nabisco, NASA, National Instruments, National Semi-Conductor, Omron Electric, Pacific Power, Pirelli Cables, Proctor and Gamble, Robert Bosch Corp, Siemens, Smith Kline Beecham, Square D, Texaco, Varian, Warner Lambert, Woodside Offshore Petroleum, Zener Electric

Table of Contents

1 Over view 1 1.1 What is OPC? 1.2 The Problems addressed by OPC 1.3 The logical object model 1.4 OPC specifications

2 Supporting technologies 13 2.1 Objective oriented Software Technology 2.2 Active X and Active X control 2.3 The client/ server paradigm 2.4 DDE and NetDDE 2.5 OLE 2.6 COM/DCOM 2.7 LANs and WANs 2.8 Protocols and protocols stacks 2.9 Ethernet 2.10 TCP/IP

3 COM/DCOM 23 3.1 Introduction 3.2 Interfaces 3.3 IUknown 3.4 Client/server relationships 3.5 Server object creation and access 3.6 The COM library

4 OPC Overview, Common definitions and interface specifications 35

4.1 Background 4.2 General Structure of OPC specifications 4.3 OPC overview and |OPC common definitions 4.4 OPC interface Architecture

ii Practical Fundamentals of OPC

4.5 Other common interface issues 4.6 Shutdown of servers 4.7 Interface IOPCCommon 4.8 Installation and registration requirements 4.9 OPC server browser 4.10 OPC server browser not available

5 OPC data access specifications 45 5.1 Background 5.2 OPC DA companion specifications 5.3 OPC DA overview 5.4 OPC DA server hierarchy 5.5 Group attributes 5.6 Events and event notifications 5.7 Item properties 5.8 Exchange of information between server and client

6 OPC alarms and events (AE) specification 67 6.1 Background 6.2 DA vs AE 6.3 Specification overview 6.4 Types of server and clients 6.5 Alarm condition 6.6 Events and event notifications 6.7 COM objects defines by OPC AE 6.8 Condition state synchronization and error handling

7 OPC historical data access specification 81

7.1 Background 7.2 The difference between HDA and DA 7.3 Definitions 7.4 Server implementation 7.5 Architecture 7.6 Data exchanges possibilities 7.7 Aggregation

Table of Contents iii

8 OPCB specifications 95 8.1 Overview 8.2 Scope of the specification 8.3 Relationship with IEC 61512-1 8.4 Client-sever interaction 8.5 Architecture 8.6 Data sources and interfaces 8.7 Interfaces and objects 8.8 OPCB namespace 8.9 Browsing the OPCB namespace 8.10 Properties 8.11 Parameters, results and their properties 8.12 Batch List

9 OPC security 129 9.1 Introduction 9.2 Levels of security 9.3 The security reference model 9.4 DCOM security concepts 9.5 OPC security specification 9.6 Time stamp 9.7 Error handling 9.8 Security

10 OPC XML-DA 143 10.1 Background 10.2 XML, SOAP and Web services 10.3 General features 10.4 Security 10.5 Server model 10.6 DX database structure 10.7 OPC DX configuration services 10.8 OPC DX runtime

11 OPC data eXchange 153 11.1 Background 11.2 data integration

iv Practical Fundamentals of OPC

11.3 OPC interface architecture 11.4 control and monitoring by attributes 11.5 Server model 11.6 DX database structure 11.7 OPC DX configuration services 11.8 OPC DX runtime

12 Troubleshooting 163 12.1 DCOM network stack 12.2 Physical and data Link Level problems 12.3 Network and transport level problems 12.4 COM/DCOM problems 12.5 Client/server problems 12.6 Other issues

A Appendix: Modbus Protocol 177

B Appendix: DCOM Technical Overview 193

C Appendix: DCOM Installation Issues 225

D Appendix: Practical Exercises 235

E Appendix: TCP/IP 285

F Appendix: Using OPC via DCOM 313

G Appendix: DCOM Configurations for KEPSenserEX 353

1 OPC Overview

1.0 What is OPC? OPC originally stood for ‘OLE (i.e. Object Linking and Embedding) for Process Control. Since OLE has been superseded by ‘ActiveX’ this acronym has become meaningless and consequently ‘OPC’ has become just a name. It is sometimes said to represent ‘Openness, Productivity and Connectivity’. OPC is an open, standards-based infrastructure for the exchange of process control data and specifies a set of software interfaces for several logical (software) objects, as well as the methods (functions) of those objects. It is a software standard supported by all major process control hardware vendors and most OPC products (clients and servers) operate very much in an ‘out-of-the box, plug-and-play’ fashion. If they so wish, users can develop their own clients and servers by means of developers’ toolkits. It is even possible to develop simple HMI systems without any programming knowledge at all. The scope of OPC is to focus primarily (though not exclusively) on the exchange of ‘raw’ data, i.e. the efficient reading and writing of data between an application and a process control device. In other words, OPC is a ‘window’ through which plant data can be observed. It accomplishes this by specifying the ‘rules’ for the data exchange in sufficient detail to allow vendors to implement low level (i.e. software) interfaces to process data. There are, however, certain implementation issues not addressed by OPC (albeit deliberately). These include:

• Hardware interconnection. The protocol issues (drivers etc) for the I/O subsystems are not covered by the OPC specifications, and have to be taken care of by the server vendors

• How clients and servers are to be implemented. Apart from specific guidelines in the OPC specifications, and strict adherence to the interface definitions, vendors can implement clients and servers in any way they want. As a result, OPC products differ in terms of speed, reliability and interoperability

The goals of the original OPC Task Force was to develop a way to facilitate easy access to process data. The system had to be easy to use, easy to implement (especially on the server side), had to operate efficiently in terms of the usage of system resources (such as CPU usage), had to have a reasonably high level of functionality, and had to be flexible enough to accommodate the needs of multiple vendors. These goals were met, and the original; ‘OPC

Practical Fundamentals of OPC (OLE for Process Control)

2

Task Force’ (1995), representing Fisher-Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell Automation, Siemens, and Microsoft has grown into the present OPC Foundation with several thousands of members.

Figure 1.1 OPC Foundation logo 1.2 The problems addressed by OPC 1.2.1 Process control architectures Most of the problems addressed by OPC can be traced back to the use of a multi-layered process control architecture and a heterogeneous computing environment.

Automation systems provide users with three primary services namely control, configuration, and data collection. Control involves the exchange of time-critical data between controlling devices such as PLCs and I/O devices such as actuators and sensors. Networks that are involved in the transmission of this data must provide some level of priority setting and/or interrupt capabilities, and should behave in a fairly deterministic fashion, depending on the specific application. The second type of functionality, namely configuration, typically involves a personal computer or a similar device in order for users to set up and maintain their systems. This activity is typically performed during commissioning or maintenance operations, but can also take place during runtime, e.g. recipe management in batch operations.

The third involves the collection of data for the purposes of display (e.g. in HMI stations), data analysis, trending, troubleshooting or maintenance.

OPC Overview

3

Figure 1.2 Hierarchy of plant levels

Figure 1.2 shows a generic view of an automation system architecture. At the device level, information is exchanged primarily between devices and networks deployed on the plant floor. Fast cycle times are required, networks at this level are bit-or byte oriented, and data packets are fairly small. Examples are HART, AS-i, DeviceNet, PROFIBUS DP and Foundation Fieldbus H1. These are mostly bit-or byte oriented network technologies and are generically referred to as ‘field buses’.

At the control level data is primarily exchanged between HMIs and PLCs. At this level speed is less critical and the amount of data exchanged in a packet is, generally speaking, bigger. These are systems at this level is said to be message oriented, and examples are ControlNet and Foundation Fieldbus HSE.

At the information level we find larger computers (e.g. mainframes) often networked via Token Ring or Ethernet, often at up to 10 Gigabit speeds. Here, determinism is not a factor. However, at this level there could be a large number of different Operating Systems, such as Windows, UNIX and LINUX.

The current trend is for vendors to re-package their older systems by running them via a TCP/IP stack over Ethernet, and these systems are used at the device as well as the control level. An example is the ODVA’s Ethernet/IP, which is basically DeviceNet running on TCP/IP and Ethernet. Field buses are deployed on the ‘plant floor’ and should be able to operate in a harsh environment (temperature, vibrations, EM-disturbances, moisture, etc.). They should be robust and should be easily installed by skilled people. Other desirable attributes are a high degree of integrity (i.e. no undetected errors), high availability, with a redundant topology if required, a deterministic type of operation, a built-in system supervision and diagnostics, support of fairly large distances (up to a few kilometers if required), support of non-real-time

Practical Fundamentals of OPC (OLE for Process Control)

4

traffic for commissioning and diagnostics, and the option of intrinsic safety for some applications within explosive environments. 1.2.2 Problems arising from the process control architecture. Various categories of personnel, from operators to the CEO, need to access data across all three layers at various points in time. This is difficult or almost impossible due to various factors, relating to the data sources, data formats, data users, the interconnection between data sources and data users, and Operating Systems. These will now be discussed in more detail. 1.2.3 Data sources Data sources could include (but are not limited to):

• Computers • Databases (e.g. SQL) • Programmable Logic Controllers (PLCs) • Distributed Control Systems (DCSs) • Stand-alone (e.g. PID) controllers • Remote Terminal Units (RTUs)

Each of these would use a different protocol at layer 7 of the OSI model. Even if they were all interconnected via the same physical network, the interrogating (client) system would need to be able to converse via several protocols. 1.2.4 Data format Data format is another problem area. The data source (e.g. server) could, for example, make its data available in one of the following formats:

• Boolean (single bit) • Character (signed 8-bit) • Word (unsigned 16-bit) • Short (signed 16-bit) • Dword (unsigned-32 bit) • Long (signed-32 bit) • BCD (2-byte packed BCD) • LBCD (4-byte packed BCD) • Float (32-bit floating point number) • Double (64-bit floating point number) • String (null terminated ASCII string)

The client software would need to accommodate all of these. 1.2.5 Data users The plant data obtained from various sources could end up being used by multiple clients.

These could include:

• Human-Machine Interfaces or HMIs (a.k.a. MMIs) • Supervisory Control and Data Acquisition (SCADA) systems • Trenders • Archivers

OPC Overview

5

• Electronic Resource Planning (ERP) or Manufacturing Resource Planning (MRP) systems

• Spreadsheets • Process Historians • Machine condition monitors

This data might be used for functions such as

• Reporting • Operator interfacing • Trending • Alarming • Control strategies

Depending on the application, data could be accessed in groups or per individual items. It could either be polled by the client at constant intervals or be forwarded by the server to the client on an exception basis. 1.2.6 Interconnections Interconnections, especially between Server host and I/O device, could be varied. Technologies and standards employed could include:

• Point-to-point links. Here, options include fiber, RS-232, RS-422, Bell-202 type modem links and 900 Mhz/2.4 GHz microwave links, to name but a few

• Multi-drop buses. Options here include RS-485 and IEC 61158 • Protocols. Options include Modbus, DNP3 and DF-1, to name but a few. • Networks. Fully-fledged industrial networks, implementing all (or at least layers 1, 2

and 7) of the OSI model stack include Ethernet/IP, PROFIBUS and Foundation Fieldbus. There are several dozen contenders (‘field buses’) at this level

1.2.7 Operating systems This is another problem area. The various operating systems used server as well as client hosts could vary between Windows (95/98/NT, 2000, XP, CE, 2003 etc), UNIX, LINUX and various real-time operating systems for embedded controllers. 1.2.8 Drivers Historically, the products that go into a process control system (such as field instrumentation and control components) have been proprietary in nature. Gradually, several hardware and signal exchange standards evolved in the field of analog and digital instrumentation to ensure that the components manufactured by different vendors can communicate with each other, at least at a low level. For example, most analog field devices such as transmitters communicate using standard signal values in the range of 4 to 20 mA. The control system (or indicating instrument for that matter) to which this transmitter is connected can thus compute the actual flow rate based on this commonly understood, standard, signal. This means that the control equipment need not be custom-designed for each transmitter, but can be designed and manufactured irrespective of the parameter being measured, indicated or controlled. In effect, a single measuring or control device can be used for flow, pressure, temperature or any other conceivable parameter of any possible measurement range.

Practical Fundamentals of OPC (OLE for Process Control)

6

Another benefit is, of course, the convenience of having a vendor independent system. A transmitter supplied by a given vendor can thus be used with an indicating instrument or a PID controller from any other vendor, provided they use the same 4-20 mA standard. The output devices in the field, such as control valves, are also based on the same standard. This means that a control system that requires the control valve regulating the controlled parameter to be kept fully open will simply send a signal of 20 mA to the valve.

While the example of a transmitter/controller/control valve typifies a hardware standard, widespread use of computers for process control has given rise to a need for standardization of software components as well. We are not talking about the control software of a particular system component here; that remains proprietary. In fact, the control software itself is of no relevance to anyone except the manufacturer of that hardware or to a developer writing applications specific to that hardware device. (Here too, standardization efforts have been taken up, such as the standard for PLC Programming as per IEC-61131-3, but such standardization may not be feasible for all types of devices). What is important is that, when it comes to exchange of data between systems, a common standard is absolutely essential.

Figure 1.3 shows a simplified example of a high-speed rotating machine control system.

Figure 1.3 Control system example

The lower portion of the diagram shows three independent control systems, each serving as a data source. They are: • A PLC for interlocking operations and for supervision of vital operating

parameters • A vibration instrument that measures machine vibration • A vendor-supplied performance calculation engine The PLC will be connected to several I/O devices for control of the machine, using its own

standard interfaces and communication protocols. All these are essentially self-contained devices that may include their own HMI hardware or other form of output devices such as hardwired indicators, annunciators and so on. However, they are also required to communicate with other devices provided for overall control of the process itself, of which this particular machine is a component.

The upper portion of the diagram shows three such devices:

OPC Overview

7

• An HMI used by the process control operator for obtaining the system status, the alarm conditions when there is an undesirable deviation from specific threshold values, and often for control of the process

• A data archive for storing various measured values, events etc. • A machine condition monitoring system Assume that all data sources and data users shown in this example are proprietary systems.

We can see right away that there is a need for each of the data user devices to obtain data from each of the data sources shown here. For example, the HMI will need status and alarm data from the PLC. It will also require vibration readings and critical alarms in the event of excessive vibration values for operator information. It will need interaction with the calculation engine to display critical calculated parameters to the process operator and use the results as inputs to say, an expert system application for operator guidance. The same will be true of the data archive device and the machine monitoring system also (refer Figure 1.4).

Figure 1.4 Communication between proprietary systems using separate drivers

With all these systems being proprietary in nature, direct communication between any two devices is not possible without some customized interfacing. The HMI will need an interface to access the data residing in the PLC. Similarly, it will need another interface to access the data from the vibration measuring instrument; and so on. Each interface is a special purpose software application known as a device driver (simply referred to as a ‘driver’). Each connection between two devices thus calls for two dedicated custom-developed drivers, one at each end. These cannot be used with any other device, and even between a pair of devices the driver may need to be rewritten if the data source or the data-using device is replaced or upgraded.

There is also another less obvious problem. Each data source device has to communicate through multiple drivers to the data users. This means that identical data may be requested by multiple user devices and has to be communicated separately to each by the data source. With slow serial protocols such as Modbus Serial, such a requirement puts a severe strain on the communication infrastructure. Thus:

• We need nine device drivers in this scenario • Each will have to be custom-developed • Each may become useless if any of the corresponding devices is replaced

or even upgraded

Practical Fundamentals of OPC (OLE for Process Control)

8

The result is a lack of interoperability, getting locked-in to specific vendors, and time

consuming software development and on-going management. Such a situation is neither in the user’s interest, because of the difficulties cited above, nor in the manufacturers’ interest, because they are the ones expected to supply the drivers. It is thus obvious that we can arrive at a ‘win-win’ situation by making all devices talk in a common language. Let us now modify the example in Figure 1.4 with another, representing communication through such a common language. This is shown in Figure 1.5.

.

Client X

...OPC Interface

Client Y

OPC Interface

OPC ServerA

OPC ServerB

OPC ServerC

Figure 1.5 Communication between proprietary systems via OPC

In this scenario, each data source has a software component for making its data available to other systems (let us call it the ‘server’) and each data user has a software component to access the server for data (let us call this the ‘client’). We have therefore created a ‘software bus’. By adopting a common data interface standard, it is possible for any client to request data from any server in a format that the server can understand. The server, in turn, makes the requested data available to the client in a format that the client can understand. As long as the client and server applications are all based on a common specification, any client and any server can thus exchange data thereby ensuring interoperability.

Since there is no proprietary component in this data exchange mechanism, it automatically ensures vendor independence. Scalability, too, is not an issue since a new data source following the same data exchange specification can easily be added. Device upgrades pose no problem either, since the data exchange mechanism will still be based on the same common standard. Server vendors are also not required to develop drivers to suit various client products, but simply have to implement the required OPC interfaces.

1.3 The logical object model It is, strictly speaking, inappropriate to talk about a logical (i.e. software) object model for OPC as each specification has a different object structure. In other words, there is a DA object model, an AE object model, etc. This is, in fact, considered a shortcoming and is being addressed by the new UA standards. We will clarify the concept be looking at the most poplar specification to date, the DA (Data Access) specification. Initially this was known simply at the ‘OPC Specification’.

OPC Overview

9

There can be a one-to-one relationship between Client and Server, or, alternatively, there can be a one-to-many or many-to-one relationship between them as shown in the following figure. However, although multiple Client-Server connections are possible, this is dependent on specific vendor implementations and hence not always possible.

Figure 1.6 Basic relationship between OPC Clients and Servers (courtesy OPC Foundation) OPC Clients and Servers are simply COM objects (in fact, all software programs on a Windows-based computer exist as COM objects and this can be verified with ‘OLE Viewer’ software. The connection between client and server is via well-defined interfaces, specified in Microsoft Interface Definition Language (IDL) and typically implemented in C++. A typical interface specification looks like this and only makes sense to a programmer. The example is for the CloneGroup method of the IOPCGroupStateMgt interface: IOPCGroupStateMgt::CloneGroup HRESULT CloneGroup( [in, string]LPCWSTR szName, [in]REFIID riid, [out, iid_is(riid)] LPUNKNOWN * ppUnk (:

The infrastructure to carry the data between the Client and Server interfaces is supplied by DCOM, described in the next chapter. A more complex Client-Server relationship is shown in the following figure. Here, the Client (A) obtains data from the server (B) via an OPC interface. The Server, in turn, obtains I/O data from a Device (e.g. a PLC), shown as C. The channel between the Server and the Device could, for example, be Ethernet or RS-485, and the Server vendor would develop the Device drivers in consultation with the Device vendor. In this specific scenario there is also s SCADA system (D) that obtains its own data via an I/O subsystem (D). If the SCADA system is OPC compatible, i.e. it has a built-in OPC server, then OPC server B could obtain data directly from the OPC server on the SCADA system via OPC Bridging software. Obviously this indirect method of obtaining data would be an issue if fast access to the plant data is a prerequisite.

Practical Fundamentals of OPC (OLE for Process Control)

10

SCADASystem

PhysicalI/O

Client

OPCServerOPC I/F

OPC I/F

PhysicalI/OPhysical I/F

Physical I/F

Figure 1.7 More complex relationship between OPC Clients and Servers When ‘looking inside’ an OPC Server such as an OPC DA Server, the internal structure of the server becomes evident. The structure varies from specification to specification, but there is always a single Server control object at the top. In the case of DA this object has the very creative name of OPCServer (note the absence of a space after OPC). Below this are one or more OPCGroup objects, and below each of these is one or more OPCItem objects. The Interfaces of the OPCServer and OPCGroup objects extend to the outside world, but those of the OPCItems do not, and as a result a Client can only be interrogated the items indirectly via the OPCGroup interfaces.

OPCGroup OPCGroup

OPCServer

OPCGroup

OPCItem OPCItem OPCItem

OPC/COMInterfaces

Figure 1.8 Internal structure of DA Server Incidentally, one of the drawbacks of the first generation of OPC specifications is that they are not built around a coherent data model, i.e. the object hierarchy of a DA server is different to that of an AE server. This has been addressed by the new Unified Architecture (AU) - refer to Annexure A. 1.4 OPC Specifications The OPC Foundation grew out of the OPC Task Force founded in 1995. With the decision to base OPC on existing Microsoft OLE/DCOM technologies, the OPC specification version 1.0 was already available by August 1996. This was possible because the focus was on essentials, and the approach of not ‘re-inventing the wheel’. The first update was issued in September 1997. Now it was no longer called the ‘OPC Specification’, but rather the Data Access (DA) specification 1.0A. However, the need for acquiring data from a process goes beyond routine operating data to more specific varieties of data such as events, alarm conditions and historical data. Additional

OPC Overview

11

industry requirements and further developments in Microsoft DCOM technology led to the next version called Data Access specification 2.0.

Meanwhile, separate working groups were formed to cover the requirements of exchanging information on events and alarms and the acquisition of historical data. The OPC Alarms and Events (AE) specification was published in January 1999 (Version 1.01) and the OPC Historical Data Access (HDA) specification in September 2000. A separate OPC Security specification was published in September 2000 covering the security policies to be used by OPC components. The specific data exchange needs of batch process control applications were covered in a separate document called the OPC Batch specification.

As the number of OPC specifications increased, it was obvious that there are elements common to all the specifications. This led to the issue of two additional specifications. The first is known as the OPC Overview and contains only the explanatory aspects, while the second was called the OPC Common Definitions and Interface Specification and contains normative definitions. Other functionalities for extending the scope of the Data Access specification include the use of XML technology for enabling the use of OPC components for accessing data over the Internet and in operating systems that do not support DCOM. A separate working group called OPC DX deals with communication between servers without involving a client. OPC is a relatively new technology and is changing and expanding rapidly. The ‘first generation’ OPC standards shown below are all based on Microsoft DCOM technology and (at October 2006) comprise the following specifications. All specifications relate to the ‘Custom Interface’ (i.e. for use with C++) unless indicated as ‘Auto’ for VB/VBA.

• OPC XMLDA (XML Data Access) 1.01 • OPC Commands 1.00 Specification 0.29 • OPC HDA (Historical Data access) 1.20 • OPC Complex Data 1.00 • OPC DX (Data exchange)1.00 • OPC DA (Data Access) 3.00 • OPC AE (Alarms & Events) 1.10 • OPC Common 1.10 • OPC DA 2.05a • OPC Batch 2.00 • OPC Batch Auto 1.00 • OPC HDA Auto 1.00 • OPC Security 1.00

DCOM, although a Microsoft invention, is not a proprietary solution that ‘locks in’ users to Microsoft as it has been implemented by several other vendors and is available for UNIX and LINUX as well. It is very efficient, as any object accessing another object can do so with a single Remote Procedure Call (RPC) to the other object, irrespective of the location of the other object. Provided that there is the required network connectivity, there is hardly any difference in Client-Server communication whether they are located on the same computer, or on opposite sides of the world. DCOM does, however, have shortcomings and, in particular, is not entirely firewall-friendly and as a result it runs very well on a LAN, but not across on the Internet. DCOM operation is subject to the security mechanism on a computer, and recent security measures as implemented on Windows XP Service Pack 2 plays havoc with DCOM. It is also prone to time-outs, a situation that is undesirable in process control applications. As a result, the OPC foundation decided to migrate OPC to the Microsoft .NET (’dot-NET’) technology. A recent decision was also to combine all the OPC functionalities in the so-called Unified Architecture or ‘UA’ specifications. UA is a very new concept and at this time (October 2006) only the UA Concepts document has been released to the public. The other UA specifications are still only available to OPC

Practical Fundamentals of OPC (OLE for Process Control)

12

Foundation members, and some are still in draft form. AU will therefore only be addressed in detail in the next revision of this manual, but as an interim measure an overview is given in Annexure A. The current UA specifications (October 2006) are:

• OPC Test Lab RC1.00 • OPC UA Part 1 Concepts 1.00 • OPC UA Part 2 Security Model 1.00 • OPC UA Part 3 Address Space Model 1.00 • OPC UA Part 4 Services 1.00 • OPC UA Part 5 Information Model 1.00 • OPC UA Part 6 Mappings RC0.93 • OPC UA Part 7 Profiles Draft 0.23 • OPC UA Part 8 Data Access RC1.31 • OPC UA Part 9 Alarms Draft 0.62 • OPC UA Part 10 Commands draft 0.62 • OPC UA Part 11 Historical Data Access Draft 0.991