NETWORK MONITORING USING OPC. Bhumi Patel B.E, Gujarat University, India, 2007 PROJECT

Transcription

1 NETWORK MONITORING USING OPC Bhumi Patel B.E, Gujarat University, India, 2007 PROJECT Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in COMPUTER SCIENCE at CALIFORNIA STATE UNIVERSITY, SACRAMENTO FALL 2011

2 NETWORK MONITORING USING OPC A Project by Bhumi Patel Approved by:, Committee Chair Chung-E Wang, Ph.D, Second Reader Kwai-Ting Lan, Ph.D Date ii

3 Student: Bhumi Patel I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the Project., Graduate Coordinator Nikrouz Faroughi, Ph.D Date Department of Computer Science iii

4 Abstract of NETWORK MONITORING USING OPC by Bhumi Patel The intent of the project is to explore capabilities of an open standard OPC specification. This project demonstrates the way this specification is followed and implemented in real world where a server acts as source of information for collecting data. In this application the server collects data about the network to which it is connected and stores the required information. The data can be requested by any number of clients. The way in which the client and the server communicate with each other is defined by the OPC standard. This project exhibits different standards set by the OPC foundation and how these standards are implemented. A demo server has been implemented which collects real-time network related data such as network speed, network interface and packet information. This data is then requested by a client; a web based GUI that sends XML based request to the server which are set by the given OPC standards. By adhering to the standards, one can independently implement the client without knowing the control device specific information., Committee Chair Chung-E Wang, Ph.D Date iv

5 DEDICATION To my father who inspired me to pursue my dreams and to my mother for her constant support. v

6 ACKNOWLEDGEMENT Before going in to the details of the project, I would like to thank everyone who helped me in various ways to finish up my project. First, I would like to thank my project advisor, Dr. Chung-E Wang for providing all his valuable guidance and important advices. I am very grateful for his assistance with time flexibility, which helped me to continue my full time work along with project implementation. Dr Wang was instrumental to my success for completion of this project. I would also like to thank my second reader Dr. Kwai-Ting Lan for his valuable feedback. Also, I would like to thank Dr. Nikrouz Faroughi (Graduate Coordinator, Department of Computer Science, CSUS) for his support and advice toward the completion of this project. Finally I would like to thank my friends Hemal Mehta and Hitesh Wadhwani for their valuable support and help. vi

7 TABLE OF CONTENTS Page Dedication... v Acknowledgement... vi List of Figures... x Chapter 1. INTRODUCTION AN OVERVIEW OF RELEVANT BACKGROUND MATERIAL OPC Overview OPC Standards OPC Foundation Review OPC DA OPC XML DA 1.01 OVERVIEW AND SPECIFICATIONS Get Status Read Write Subscribe SubscriptionPolledRefresh SubscriptionCancel Browse GetProperties SYSTEM ARCHITECTURE Architectural Overview SYSTEM IMPLEMENTATION vii

8 5.1 Server Implementation NetworkMonitoring.CommonUtils NetworkMonitoring.DataContract NetworkMonitoring.ServiceContract NetworkMonitoring.WCFService NetworkMonitoring.TestHarness Client Implementation NMWEB NetworkMonitoring.UIAccess NetworkMonitoring.DataContract NetworkMonitoring.ServiceContract NetworkMonitoring.CommonUtils Common Solution NetworkMonitoring.CommonUtils TEST AND RESULTS Get Server Status Browse Get Properties Get Updated Variables Subscribe OPC XML-DA Client User Interface FUTURE ENHANCEMENTS AND CONCLUSION Future Enhancement Conclusion viii

9 Bibliography ix

10 LIST OF FIGURES Page 1. Figure 1 Client-Server Interaction Figure 2 Data Exchange using Unique Protocol For Each Device Figure 3 Data Exchange using OPC Figure 4 GetStatus Request Object [2] Figure 5 Read Request Object Provided [2] Figure 6 Write Request Object [2] Figure 7 Subscription Request Object [2] Figure 8 Polled Subscription Interaction Figure 9 SubscriptionPolledRefresh Request Object [2] Figure 10 SubscriptionCancel Request Object [2] Figure 11 Browse Request Object [2] Figure 12 GetProperties Request Object [2] Figure 13 System Architecture Figure 14 Server Assemblies Interaction Diagram Figure 15 Server Solution Structure Figure 16 Data Contract Figure 17 Service Contract Figure 18 WCF Service Figure 19 Server Assemblies Interaction Diagram Figure 20 Server Solution Structure Figure 21 UI Access Figure 22 Common Utils Solution Structure x

11 23. Figure 23 GetStatus Request and Response Figure 24 Browse Request and Response Figure 25 GetProperties Request and Response Figure 26 GetUpdatedVariable Request and Response Figure 27 Subscribe Request and Response Figure 28 OPC XML-DA Client User Interface xi

12 1 Chapter 1 INTRODUCTION OPC (OLE for process control) is an open standard specification set by an industrial automation task force [1] which is based on Microsoft s OLE COM and DCOM [6] technologies. This standard specifies the communication of hardware data between different control devices from different manufacturers. Before the existence of OPC, there were custom interface and driver for each and every hardware device from different vendors. There were several problems associated with custom driver based communication; some of these most common ones were [7]: High cost Proprietary technology that tied users to a particular vendor Hard to configure Maintenance issues - because each custom driver had its own way of doing things Hard to keep up-to-date because of the constant release of new devices and applications In order to resolve the above mentioned issues, a set of standards were introduced by OPC foundation [8] which defines a common interface written once and then reused by any business, SCADA, HMI or custom software packages [1]. The figure below gives an overall idea about the interaction between a client and a server:

13 2 Figure 1 Client-Server Interaction Microsoft.NET technology is used to implement client and server. OPC Foundation provides a family of APIs to take advantage of Microsoft.NET technologies to implement OPC server and client [9]. 1. OPC Server Implementation The server is implemented using XML Data Access 1.01 specification which is defined from OPC Data Access [3] standard that provides specifications to communicate with plant device and get real-time data. It uses SOAP (Simple Object Application Protocol) 1.1 [5] as a platform for data communication and information exchange over the internet. The requests and responses are XML structure hierarchical information, transmitted over HTTP (Hypertext Transfer Protocol) between client and server. The server provides multi-platform interoperability because it is based on XML instead of the Windows specific DCOM [10].

14 3 The server is implemented as a WCF (Windows Communication Foundation) [4] web service and is hosted on IIS (Internet Information Server) 7.0. The server contains standard interaction methods specified by OPC XML-DA 1.01 specification: Status Mechanism for checking server status Read Provides ability to read item values and quality Write Writes values for one or more items Subscription Used to initiate a subscription contract with a server Subscription Polled Refresh Periodically acquire the latest item values Subscription Cancel Terminate subscription Browse Browse available items on server Get Properties Get server properties 2. OPC Client Implementation The client is implemented as an ASP.NET web application which connects to the server using server s hosted URL address. A request from the client is made by building a SOAP object message which is sent to the server over HTTP.

15 4 Chapter 2 AN OVERVIEW OF RELEVANT BACKGROUND MATERIAL 2.1 OPC Overview Before OPC standards were set, there was a clear distinction between hardware and software developers. Software developers had to develop programs/interfaces to communicate with the hardware devices as well they needed to write drivers to talk to the data storage within the hardware. So if some new hardware device comes up in the market, the hardware manufacturer has to tie up with certain and specific software developers. With introduction of OPC standards and by bringing Microsoft s OLE COM, software and hardware developers were brought together. Software developers can create applications without worrying about compatibility issues with hardware devices. On other hand hardware developers now need to develop only one set of component software for a device that supports applications from many software developers. The figure below gives you an overview of how the hardware developers and software developers interact with each other for custom interfaces and drivers before the existence of OPC standards:

16 5 Figure 2 Data Exchange using Unique Protocol For Each Device As one sees in the above figure, whenever a new application comes up with a driver enhancement; a new driver is needed to be written for it. But after OPC, only a COM enhancement is required to provide access for client applications to remote OPC servers. Below figure shows data from field devices being converted to OPC data via OPC server and made available to OPC applications via OPC tags.

17 6 Figure 3 Data Exchange using OPC OPC Standards OPC standards are set by OPC foundation which should be followed by both software and hardware developers in order to provide seamless access of data between all layers. Till date, there are nine OPC standards which are being used and set by OPC foundation. Here are the nine standards and their details [11]: OPC Data Access Moves real-time data from PLCs, Digital Control Systems (DCSs), and other control devices to HMIs and other display clients. OPC Alarms & Events Provides alarm and event notifications on demand (in contrast to the continuous data flow of OPC Data Access). These notifications include process alarms, operator actions, informational messages, and tracking/auditing messages.

18 7 OPC Batch Carries the OPC technology to the specialized needs of batch processes. This standard specifies interfaces for exchanging equipment capabilities (corresponding to the S88.01 Physical Model) and present operating conditions. OPC Data exchange Transports data from client/server to server-to-server with communication across Ethernet networks. This standard provides multivendor interoperability, remote configuration, and diagnostic and monitoring/management services. OPC Historical Data Access Provides access to data that is already stored (in contrast to OPC Data Access, which provides access to real-time, continually changing data). From a simple serial data logging system to a complex SCADA system, historical archives can be retrieved in a uniform manner. OPC Security Specifies client control access to plant process servers in order to protect this sensitive information and to guard against unauthorized modification of process parameters. All the OPC servers provide information that is valuable to the enterprise and, if improperly updated, could have significant consequences to plant processes. OPC XML-DA Provides flexible, consistent rules and formats for exposing plant floor data using extensible Markup Language (XML), leveraging the work done by Microsoft and others on XML Simple Object Access Protocol (SOAP) and Web Services.

19 8 OPC Complex Data Allows servers to expose and describe more complicated data types such as binary structures and XML documents. This standard specifies a companion specification to Data Access and XML-DA. OPC Commands Specifies a new set of interfaces that allow OPC clients and servers to identify, send, and monitor device control commands. 2.2 OPC Foundation Review The OPC Foundation was created to maintain and regulate the standard after the first release of OPC standard. The OPC Foundation is an industry consortium that creates and maintains standards for open connectivity of industrial automation devices and systems, such as an industrial control system and process control generally. The OPC Foundation was started in 1994, as a task force comprising of five industrial automation vendors, with the purpose of creating a basic OLE for Process Control specification. The foundation then released the OPC standard first set in The OPC Foundation was responsible to continue development of interoperability specifications and includes manufacturers and users of devices instruments, controllers, and software and enterprise systems [12]. 2.3 OPC DA OPC Data Access is a group of standards that provides specifications for communicating real-time data from data acquisition devices such as PLCs to display and interface devices like Human-Machine Interfaces (HMI). The specification focuses on the continuous communication of real-time data [3]. OPC DA was very easy to use because COM/DCOM was used as the underlying protocol and they were well supported by all kinds of IDEs from C++ and Visual

20 9 Basic to VBA in Office applications. It spread very quickly as a vendor independent standard for accessing process data and other specifications for different automation technology requirements. In addition to some problems with DCOM timeouts and network interruptions, one of the biggest problems is that it is bound to Microsoft and is not portable to other operating systems [12].

21 10 Chapter 3 OPC XML DA 1.01 OVERVIEW AND SPECIFICATIONS OPC XML-DA 1.01 is a specification developed to address OPC DA problems. It is the first specification that allows access from operating systems other than Microsoft in a standardized way. This simplifies an exchange of plant data over wider range of platforms. OPC XML-DA specification is a companion to the OPC Data Access 3.0 specification [2]. The idea of OPC XML-DA is to facilitate plant data exchange over the internet and upward into an enterprise domain. The specification is developed in a manner to take advantage from SOAP. The specification has been developed in manner that will allow structured information to be transmitted over the internet in form of SOAP based request and response messages. The OPC XML-DA specification defines an environment between client and server that do not have a persistent connection between them. But server may be able to store some state information for client based on specific service. Following are the structure, parameters, and behavior of each service supported by the OPC XML-DA 1.01: Status: GetStatus, GetStatusResponse Read: Read, ReadResponse Write: Write, WriteResponse Subscription: Subscribe, SubscribeResponse Subscription Polled Refresh: SubscriptionPolledRefresh, SubscriptionPolledRefreshResponse Subscription Cancel: SubscriptionCancel, SubscriptionCancelResponse Browse: Browse, BrowseResponse

22 11 Get Properties: GetProperties, GetPropertiesResponse 3.1 Get Status GetStatus contains information that represents the GetStatus request. The purpose of the GetStatus service is: To provide a mechanism for checking the status of the server - operational or maintenance. To provide a mechanism to obtain vendor-specific information about the server, that is not available through the other OPC services (e.g., version number, etc). To provide insight for clients to the relative time synchronization between the client and server. As an example, this information is useful for Read requests. GetStatusResponse is the container of information that represents the response of GetStatus. The server needs to return valid values for all of the items, for e.g., StatusInfo, VendorInfo, ProductVersion, StartTime etc. Below is a snapshot for GetStatus request object: Figure 4 GetStatus Request Object [2] 3.2 Read Read contains the information that represents the Read request. This service provides a facility to read value and quality for one or more items. Other attributes, such as timestamp, can also be requested for items. The items are contained in an Item List. The client request contains specific attributes that allows the server to respond more appropriately to the client s data needs.

23 12 Some of these attributes are hierarchical in nature. Below is a snapshot for Read request provided by OPC XML-DA 1.01 specification: Figure 5 Read Request Object Provided [2] The Read request runs towards completion before the response is returned. The server determines if the data can be read and obtains the data for an item. It places either the data or an error code for each requested item into the ReadResponse, according to the structure and order of the Items in the request.

24 13 The client may request for the server to return the subset of error messages that correspond to the unique error codes found in the list of values. The error messages follow the list of values or error codes. The data can be read from a server s cache. In this case, the data should be accurate within the optional MaxAge attribute specified for the item in the request. Alternatively, the server may be front-ending a device, and some data requests will cause a read from the underlying physical device. The cache values that met the MaxAge attribute will not have to be reassessed after the device read is performed. In the WSDL extract below, the attribute minoccurs is set to 0 for Items (in ReadRequestItemList) to be compatible with code generation tools. However, at least one Item is required in the ReadRequestItemList, else an E_FAIL will be returned. The clients should use the Subscription services, if data is required on a regular basis. 3.3 Write Write contains the information that represents the Write request. This service writes the value for one or more items. Optionally, the Time, QualityField, LimitField, VendorField attributes of the value also can be written. The client may tailor the information to be returned in the corresponding WriteResponse and as such may optionally request the inclusion of verbose error messages in the response. The values to be written are contained in an ItemList. The client request provides specific attributes which allow the server to respond to the client s data write requests. Some of these attributes are hierarchical in nature. The client can request a subsequent read of the items, so it can obtain the results of the recent writes. The service runs to completion before the response is returned. The server determines if the data can be written, and writes the data for each item. If requested, after all writes complete,

25 14 the server performs a read of the items. The server places either the data or an error code (write or read) for each requested item into the WriteResponse, matching the structure and order of the request. Below is a snapshot for Write request object with parameters: Figure 6 Write Request Object [2] The server and the scope of the data that it represents will determine the data destination, i.e., cache, or underlying device. The exact implementation of a cache or device is not defined by this specification. The attribute minoccurs is set to 0 for Items (in WriteRequestItemList) to be compatible with code generation tools. However, at least one Item is required in the ItemList, else an E_FAIL will be returned.

26 Subscribe Subscribe contains the information that represents the Subscribe request. The attribute minoccurs is set to 0 for Items (in SubscribeRequestItemList) to be compatible with code generation tools. However, at least one Item is required in the list, else an E_FAIL will be returned. Responses to subscribe or poll requests return only a subset of all subscribed items. To be able to identify them the client has to assign unique values to the handles of items (ClientItemHandle). Below is a snapshot for Subscribe request object:

27 16 Figure 7 Subscription Request Object [2] 3.5 SubscriptionPolledRefresh SubscriptionPolledRefresh contains the information that represents the SubscriptionPolledRefresh request. This method refreshes the data items from the last SubscriptionPolledRefresh.

28 17 in figure. The basic polled subscription communication between client and server is shown below Figure 8 Polled Subscription Interaction The client initiates request for polled subscription. The server returns a subscription handle in the response to the client s subscription request. The server also returns any initial values (value, quality, and timestamp) when the ReturnValuesOnReply option is set to true. The client then enters a periodic polling cycle, generally with a timer or a scheduler, and continues to poll periodically by issuing subscription refresh requests passing in the subscription handle. The server responds immediately returning all value and/or quality alterations, if any, since the previous poll. This process continues until the client stops the communication to update the subscription. To terminate SubscriptionPolledRefresh request, the client issues a subscription

29 18 cancel request to the server. The server cleans up allocated resources and performs other required actions to end the subscription contract it held with the client. In the WSDL extract below, the attribute minoccurs is set to 0 for ServerSubHandles to be compatible with code generation tools. However, at least one handle is required. Below is a SubsciptionPolledRefresh object snapshot provided by OPC XML-DA 1.01 specification: Figure 9 SubscriptionPolledRefresh Request Object [2] The server may have to initiate parallel processing of multiple subscriptions in order to respond to the SubscriptionPolledRefresh request. This behavior is necessitated based on the hold time and wait time parameters being only applied once. 3.6 SubscriptionCancel SubscriptionCancel contains the information that represents the SubscriptionCancel request. The client cancels a subscription (ServerSubHandle) and allows the server to clean up any resources associated with the subscription. The server cancels any processing in progress related to the specified subscription. The ServerSubHandle also becomes invalid for any further SubscriptionPolledRefresh requests. If the subscription was part of a SubscriptionPolledRefresh

30 19 which specified multiple subscriptions, then only the specified subscription will be cancelled and any others will remain active and will continue to be processed. If the subscription associated with ServerSubHandle was the last subscription still active, then the SubscriptionPolledRefresh will return immediately. In all cases, the server will identify the invalid (canceled) ServerSubHandles. After successful termination of SubscriptionPolledRefresh server responeds the client using SubscriptionCancelResponse which contains information related to the SubscriptionCancel reponse. Below is a SubsciprionCancel request object: Figure 10 SubscriptionCancel Request Object [2] 3.7 Browse Browse contains the information that represents the Browse request. If there is no filter specified, an ALL is assumed. The Browse service supports a single level of browsing. If the client wants to recursively browse a hierachy, then the client will use the returned ItemPaths of elements with children for that purpose. If the client specifies a null string for ItemPath and ItemName, then the server will do a Browse from the top level. The server will do a Browse from the level specified by the combination of ItemPath and ItemName.

31 20 Figure 11 Browse Request Object [2] 3.8 GetProperties GetProperties contains the information that represents the GetProperties request. GetProperties request contains parameters such as PropertyNames, where the client can specify the names of the properties, of which he/she is expecting the response. If ReturnAllProperties is set to true, PropertyName is ignored and all properties are returned. Another parameter is ReturnPropertyValues, when set; server returns the property values in addition to the property names.

32 21 The response object contains parameter PropertyList. One of the PropertyList elements is returned for each requested item. ItemName and ItemPath are returned for convenience. If unknown or invalid item property has been requested by client then, an error is returned in ResultID. Otherwise, Property contains the list of requested properties. Below is a sample snapshot for GetProperties request object: Figure 12 GetProperties Request Object [2]

33 22 Chapter 4 SYSTEM ARCHITECTURE 4.1 Architectural Overview The Architectural Diagram serves dual purpose. The first is to depict and define a high level application model which represents high level system components (both internal and external) used in this project. The second is to detail a technical model which represents all hardware and software components (both internal and external) required to implement this project. Figure 13 System Architecture

34 23 The Presentation Layer contains an ASP.NET user interface for the Network Monitoring Application. The Presentation Layer interacts with the Service Layer that contains the Network Monitoring.NET Application Services. The Service Layer hosts the.net Web Services for the Network Monitoring Application. The service contains business objects and a WCF web service. The service communicates with the wireless or wired network to gather network information.

35 24 Chapter 5 SYSTEM IMPLEMENTATION The application has been designed to adhere to the principles specified in the OPC XML- DA The application consists of a website, a WCF web service, and a common utilities component. Microsoft Visual Studio 2010 has been the primary integrated development environment (IDE) during the development of the project. The visual studio solution has been divided logically to enable easy module level development and easy deployment of the application software. The Network Monitoring system is comprised of the following three primary solutions: NetworkMonitoring.Services This solution contains a WCF web service, its associated data and service contracts. This is the solution to work on the web services in terms of adding new web service methods, modifying existing web service methods and in due course changing or adding new business logic to the application. NetworkMonitoring.UserInterface This solution contains a website and its associated user interface access API. This is the solution to work on the website, any modifications to the existing web pages (.aspx files) in terms of adding data collection fields, modifying existing fields etc. NetworkMonitoring.Common This solution contains a class library for the core utilities. This is the solution to change any functionality related to the core utilities like exception logger, helpers etc.

36 Server Implementation Figure 14 Server Assemblies Interaction Diagram NetworkMonitoring.Services solution contains the following projects: NetworkMonitoring.CommonUtils NetworkMonitoring.DataContract NetworkMonitoring.ServiceContract NetworkMonitoring.WCFService NetworkMonitoring.TestHarness Below is a solution explorer snapshot from Visual Studio It displays the solution structure:

37 Figure 15 Server Solution Structure 26

38 NetworkMonitoring.CommonUtils This is a C# class library that is referenced by WCFService, and TestHarness projects. This project contains the exception logger and other helper function implementations NetworkMonitoring.DataContract This is a C# class library that is referenced by the WCFService, and TestHarness projects; it contains the business objects that are used to communicate with the WCF service. Figure 16 Data Contract NetworkMonitoring.ServiceContract This is a C# class library that is referenced by WCFService, and TestHarness projects. It contains the interface implemented by the WCF service.

39 28 Figure 17 Service Contract NetworkMonitoring.WCFService This is the WCF service that pulls data from Network Resources and pushes data to the client. It makes use of the data contract and service contract C# class libraries mentioned above. It supports two kinds of bindings namely, basic http binding and ws2007 http binding. Figure 18 WCF Service

40 NetworkMonitoring.TestHarness This is a C# console application, which is used to unit test the service layer. It makes use of the service data contracts and service contracts to call the WCF service and serializes the request and response objects to display the results on the console. It is a great debugging utility, if you encounter issues with the service layer. 5.2 Client Implementation Figure 19 Server Assemblies Interaction Diagram NetworkMonitoring.UserInterface solution contains the following projects: NMWEB NetworkMonitoring.UIAccess NetworkMonitoring.DataContract NetworkMonitoring.ServiceContract NetworkMonitoring.CommonUtils

41 30 Studio 2010: Client solution structure is displayed below in a snapshot of the solution from Visual Figure 20 Server Solution Structure

42 NMWEB This is the ASP.NET website that contains the web pages for the application. The web pages for the Network Monitoring web site have been organized into the following folders: App_Code - This folder contains static C# classes like Representations.cs etc. Bin - This folder contains the runtimes required by the website to perform its functions. MasterPages - This folder contains the ASP master pages for the Network Monitoring website. Scripts - This folder contains the jquery scripts that are being used in the Network Monitoring website code. Default.aspx - This is the startup page for the website. Web.config - All the configuration settings for the Network Monitoring website are stored in this file NetworkMonitoring.UIAccess This is a C# class library that is referenced by the NMWeb website project and is used to communicate with the WCF service for the web pages in the application. This project contains NMAdministration.cs. This file contains service layer calls related to the data collection. Figure 21 UI Access

43 NetworkMonitoring.DataContract This is a C# class library that is referenced by the NMWeb and UIAccess.API project; it contains the business objects that are used to communicate with the WCF service NetworkMonitoring.ServiceContract This is a C# class library that is referenced by the UIAccess project; it contains the interface implemented by the WCF service NetworkMonitoring.CommonUtils This is a C# class library that is referenced by Website and UIAccess projects; it contains the exception logger and other helper function implementations. 5.3 Common Solution NetworkMonitoring.Common is a common solution/project shared between both the client and the server. This solution contains methods for exception logger and data type conversions. These methods have been used by the client as well by the server to log exception on exception condition and for conversion between different data types. This solution contains a single project NetworkMonitoring.CommonUtils. Below is a snapshot of the solution from Visual Studio 2010 which displays the solution structure: Figure 22 Common Utils Solution Structure

44 NetworkMonitoring.CommonUtils This is a C# class library that is referenced by WCFService, and TestHarness projects. This project contains the exception logger and other helper function implementations.

45 34 Chapter 6 TEST AND RESULTS This section contains request and response messages snapshots for different methods. It is necessary to make sure that the request and response messages are in correct format and provides required parameter values and status. 6.1 Get Server Status GetStatus request is used to get server status and supported parameters. GetStatus request has been initiated by the client and server responds to the request by providing current server status, supported local-id and server synchronization time. Below are snapshots for GetStatus request and response messages exchanged between OPC XML-DA client and server:

46 35 Figure 23 GetStatus Request and Response 6.2 Browse Browse request is used to browse server supported variables list. Using browse request, client can get a list of parameters supported by the server. Browse is a single level browsing. It only returns top level parameters list. If the client wants to browse hierarchical values then the

47 36 client can use returned ItemPath for that. Below are snapshots for Browse request and response mmessages exchanged between the server and the client: Figure 24 Browse Request and Response 6.3 Get Properties GetProperties request is used to get property values supported by the server. The client requests the server to get properties list by providing ItemIDs and PropertyNames list. LocalID,

48 37 ItemPath and ClientRequestHandle are optional values supplied by the client for certain returned data. The server response contains ReceiveTime, ReplyTime, ServerState and properties values requested by the client. Below are sample snapshots for GetProperties request and response messages exchanged between the client and the server: Figure 25 GetProperties Request and Response 6.4 Get Updated Variables Using this method, the client requests for latest values of all variables supported by the server. The server sends a response with a list of variables and its values at the time of the client

49 38 request, request receive time, request reply time and server status. Below are snapshots for Get Updated Variables request and response messages exchanged by the client and the server: Figure 26 GetUpdatedVariable Request and Response 6.5 Subscribe Subscribe is used to start subscription with the server for variable updates. The client initiates a subscription by sending a Subscription request to the server. The request contains a list for variables requested to subscribe for periodical response from the server. The server sends a

50 39 message to the client every time a value or status of the subscribed variables has been changed. Below are sample snapshot for subscription request and response messages:

51 Figure 27 Subscribe Request and Response 40

52 OPC XML-DA Client User Interface OPC XML-DA client is a web application that connects to a server using server URL and requests for the values. Below is a snapshot of a sample client implemented to connect to the OPC XML-DA sever. The client is requesting Network Interface Speed, Upload Speed and Download Speed. The user interface also provides a facility for the client to subscribe for variables with the server. It also provides a server status and related properties in Server Status block. Figure 28 OPC XML-DA Client User Interface

53 42 Chapter 7 FUTURE ENHANCEMENTS AND CONCLUSION 7.1 Future Enhancement Network monitoring using OPC application is currently being used to monitor network parameters like upload speed, download speed, packet sent and packet received data. Current system can be expanded to allow facility for clients to write values back to the server. With the help of write feature, clients will be able to manage the server. They could remotely manage server speed and can perform bandwidth management. The other user functionality for the system which can be added in future will be a history trail of current data. It will be very useful feature for the client to store current monitoring information in database for reference. Using these historian information users can predict network traffic and network usage at particulate time intervals. This will help users to manage bandwidth. 7.2 Conclusion The Network monitoring using OPC application fulfils its primary requirement to monitor network traffic. The system is implemented using.net Framework 4.0 which is a cutting edge technology. The system has been implemented using N-Tier concept with loosely coupled tiers. This will provide flexibility to extend the system in future without affecting any existing functionalities. The system lacks automatic notification functionality. It doesn t notify client in case when server crashes. In real time if server is down then it should be able to notify the client about server unavailability.

54 43 BIBLIOGRAPHY [1] OLE for process control. (2011). In Wikipedia. Retrieved May 5, 2011 from Wikipedia Online. [2] OPC XML-DA Specification Version 1.01 (2004). In OPC Foundation. Retrieved June 11, 2011 from OPC Foundation Online: [3] OPC Data Access. (2011). In Wikipedia. Retrieved May 5, 2011 from Wikipedia Online. [4] Windows Communication Foundation. (2011). In Microsoft MSDN. Retrieved May 7, 2011 from Microsoft MSDN Online. [5] Simple Object Access Protocol (SOAP) 1.1. (2000). In W3C. Retrieved May 7, 2011 from W3C Notes Online. [6] Distributed Component Object Model. (2011). In Wikipedia. Retrieved May 5, 2011 from Wikipedia Online. [7] OPC Data Access. (2011). In Matrikon OPC. Retrieved May 5, 2011 from MatriconOPC Data Access Online. [8] OPC Foundation. (2011). In Wikipedia. Retrieved May 5, 2011 from Wikipedia Online. [9] OPC and.net. (2011). In OPC Programmer s Connection. Retrieved May 7, 2011 from OPC Programmer s Connection Online. [10] OPC XML DA. (2011). In Advosol. Retrieved May 5, 2011 from Advosol Online. [11] Pankaj Bhatt and Roger P. Baldevia, Jr, Integrated IEDS with OPC Technology. (2011). Schweitzer Engineering Laboratories, Inc. Pullman, WA USA, [12] OLE For Process Control. (2008). In Wireshark OPC. Retrieved May 5, 2011 from Wireshark OPC Online.