Performance considerations by network infrastructure monitoring and control using SNMP OPC Server Vladimír Palacka, Jozef Koyš SAE – Automation, s.r.o., Nová Dubnica, Sady Cyrila a Metoda 21/18, 018 51Nová Dubnica – Slovak republic. Phone: (421) 42 44 507 01 Email:
[email protected] Abstract: The SNMP protocol is the most used protocol for monitoring and control of network infrastructure within networked control systems (NCS). OPC is in industry as well as in other areas the most used technology to achieve interoperability of the systems of various vendors. The linkage of both technologies enables integration of the process and network infrastructure control and monitoring to one functional unit. Versatility of used tools can have negative impact on performance particularly when awaiting plug and play solutions and not all parametring and optimizing possibilities are utilized. The possibilities to reduce this negative impact on performance are described in this article. Keywords: Networked control systems, OPC, SNMP, interoperability, performance
1. INTRODUCTION If someone defines goal to implement communication between two devices from the point of view of minimal resources usage on these devices as for example CPU load, minimal necessary bandwidth, highest possible data consistency and minimal communication delays it would be optimal to dedicate software communication drivers to really transferred data and real possibilities of these communicating devices and used communication channels. Of course, such a solution would be very demanding on development and maintenance personal resources. Creating of a complex application with many various reciprocally communicating devices would be almost impossible. Various interoperability standards are created just for this reason. Interoperability standard has to balance optimum between consuming of device or whole system resources and development and maintenance resources. Wrapping of existing “optimal” communication driver with new software layer mostly means higher device resources utilization, higher transfer delays and, if processes running in primary communication driver and wrapping interoperability software layer run asynchronously, worse data consistency. On the other hand, the usage of implementations of the interoperability standard
enables it to replace demanding and skilled programmers work with mostly less time consuming and skilled configuration work.
Fig. 1 Comparison direct and by OPC server mediated communication One of interoperability standards is OPC. This standard is based on client/server communication principle and on IP protocol which can be used on various physical media – Ethernet, switched Ethernet, wireless, even serial connections with the aid of PPP protocol.
The meaning of the abbreviation OPC – “OLE (Object Linking and Embedding) for Process Control,” from the year 1996 when the standard arisen was recently changed to “Open Process Connectivity”. This standard solves not only standardization of communication issues but also functionality issues as data access, alarms and events, batch processing… Using of OPC server to intermediate communication causes additional data transfer delays - Fig. 1. Instead of one communication delay Δt between software application and device, it is necessary to count 3 delays – Δt2 between device and OPC server, Δt1 – between OPC server and software application, and Δt3 in the OPC server. Delay Δt3 can have more reasons. For example: within device driver part of the OPC server run a few threads for communication with device. Within OPC interface part of the OPC server run asynchronously another threads for communication with software application. If threads in device driver part take to much time, then there is less time for communication with software application and it can cause not only higher Δt3 delay but worse data consistency too. So, why use OPC server? The reason cannot be that OPC server enables to communicate with more devices – because the communication driver on software application can communicate with more devices too - Fig. 2a.
application, network management application in the Fig. 3 ) communicating with various kinds of devices using various communication protocols can use one common OPC interface. This way can simplify not only these applications but the structure of the whole complex system too –by implementing of one OPC client interface instead of implementing many communication drivers. This is the reason why almost all well known SCADA system and some modeling tools have implemented OPC interface. There is possibility to use more redundant OPC servers for communication with the same device and to achieve better fault tolerance – it is another positive aspect of using OPC server. The negative aspects of using OPC servers can be partly eliminated. As it was mentioned before, use of an OPC server can cause additional transfer delay and worse data consistency. It was explained that OPC server can be used as data concentrator. If we enhance this functionality of the data concentrator with data preprocessing for the data most sensitive on these additional delays and worse data consistency, this problem can be partly solved.
Fig. 4 Data preprocessing in an OPC server
Fig. 2 Communication with more devices One reason can be that OPC server can be used as data concentrator and to serve more SW applications - Fig. 2b.
Fig. 3 Simplifying system structure using OPC Very important reason is that many various software applications (for example display application, trend
Data preprocessing means not only preprocessing original data from devices but creating new data from various combinations of the original data and the offering these new data over OPC interface. For example: from a sequence of an original data, it will be counted one filtered value and thus will be reduced amount of data transferred between software application and OPC server. implementation of PID regulator directly in OPC server, transfer to the software application can be reduced on required value and control deviation evaluating of data from various network devices and changing matching parameters affecting QOS (quality of service) directly from OPC server OPC standard for alarms and events are preprocessed data achieved using OPC data access standard.
OPC servers can access various data sources, not only data mediated from hardware devices using communication device drivers. It can be data with invariable structure (for example an ini.file) and then it is not necessary to have possibility to configure OPC server. Most often are OPC servers created more universal to be able to access various devices communicating with the same protocol. Data mediated from these devices are mediated to the software applications with OPC client over so so-called address space of the OPC servers. Address space can have flat structure or tree structure. Structuring of address space is configurable and application dependant. For example all required values for all regulators can be placed in one folder in the address space or all relevant values for one regulator can be placed in one folder, it means grouping after devices or after similar kind of data. OPC server communicates with device using “tags” representing mostly not structured data and it communicates with OPC client application using OPC items.
The goal of using interoperability standards as OPC is to achieve, if possible, plug and play functionality. If OPC server would be implemented only for fixed data, than there would not be a big problem. But - OPC servers are mostly implemented as more universal applications and so it is mostly not possible to achieve this goal. Anyway configuring possibilities of the OPC servers make implementation of complex system and optimizing of the communication mediated by the OPC server much easier as if new programming of the application would be necessary. To configure OPC server are used OPC configurators - there is example of such application in Fig. 6
Fig. 6 SAEAUT SNMP OPC Server configurator Well implemented OPC server has to anticipate as many user requirements as possible and so to reduce configuring necessity as well.
Fig. 5 Cooperation of OPC servers with device and OPC client application There must not be exact equivalence between tags and OPC items. Items can be processed tags but there can be items which do not have equivalent tags and viceversa. The communication ways between OPC server and device can be based on scanning or asking data from device or on callbacks from devices by data changes on device. These ways are device drivers specific. Communication between OPC client and server depends on implemented OPC specification. There is possibility to use scanning as well as callbacks. 2. OPTIMIZING OF COMMUNICATION MEDIATED BY OPC SERVER
Unfortunately the optimization of the communication based on OPC server depends not only on OPC server itself. There are very many possibilities how to implement (or to configure) OPC client as well. Implementation possibilities of the OPC client are dependent on programmer API defined in concrete version of the OPC specification. For example - an OPC client application can start reading from OPC server and does not go away from Read function till the data from OPC server come to the OPC client. This type of reading is referred to as synchronous. It is used mostly when reading already prepared data from cache of OPC server, and so it can be expected that reading will be fast enough. The asynchronous reading means that client starts reading (mostly directly from device – not from OPC server cache) and when the reading is terminated the OPC client application is informed that data were sent. It is expected that most OPC servers will read data into some sort of CACHE. Also, most clients will read data from this cache via one of several mechanisms but implementation details of these capabilities are not dictated by OPC DA specification. (OPC Foundation, 2003).
.
Fig. 7 Creating OPC client groups in OPC server OPC Clients groups can be created independently on placing data in address space of the OPC server (Fig. 7). The same OPC item can be referenced in more groups defined on clients. Proper creation of client groups and main parameters for them can affect optimality of the communication significantly. Client can request „Requested update rate“ for every group of items and server tries to match this request as efficiently as possible. The server returns the value which will be actually used for the UpdateRate which may differ from the RequestedUpdateRate. This may also be slower than the rate at which the server is internally obtaining the data and updating the cache. As OPC server has try to match RequestedUpdateRate as good as possible, the setting of too small UpdateRate from OPC client can cause not optimal functionality from the point of view of computing resource usage on the computer where OPC server runs, particularly when updating complete data set on/from device takes more time as given by RequestedUpdateRate. It can happen that threads communicating with the device take too much time and then threads for communication between OPC client and server have small possibilities for updating data. This effect (as will be documented later) is possible to see very distinctly for example when starting OPC client/server communication for a big amount of transferred data. It takes very long time untill data on the OPC client are shown with the parameter quality “good”. From the point of view of communication optimizing, it is necessary to have good image about possibilities and features of the driver wrapped by OPC servers. The use of some driver features by the OPC server can be configurable. For example in later described SAEAUT SNMP OPC Server it is possible to configure using notifications (or traps in SNMP terminology) instead of using GET commands and so to reduce data bandwidth utilisation.
3. USING OPC AND SNMP FOR NETWORK MANAGEMENT The most used network management protocols SNMPv1, SNMPv2c and SNMPv3 have been developed as platform independent using platformindependent data definition syntax - a subset of ASN.1 and platform-independent data transfer notation – BER. SNMP is based similarly as OPC servers on TCP/UDP. UDP need two ends - server and client. In SNMP term, server is called as agent and client as management station. SNMP OPC server will act as management station. Typically the SNMP agent runs on internetworking devices like routers, hubs, switches, bridges, A PC can also have a SNMP agent running. There are I/O industry devices with running SNMP agent as well. The SNMP models all management agent functions as alterations or inspections of variables. Thus, a protocol entity on a logically remote host (possibly the network element itself) interacts with the management agent resident on the network element in order to retrieve (get) or alter (set) variables (RFC1098). The scope of the management information communicated by operation of the SNMP is exactly that represented by instances of all non-aggregate object types either defined in Internet-standard MIB (Management Information Base) or defined elsewhere according to the conventions set forth in Internet-standard SMI (RFC1068). MIB has a tree structure. This fact can be well utilized by automatic mapping MIB tree to the tree structure of the OPC server address space and to reduce time for configuration of address space very substantially.
Fig. 8 SNMP telegram SNMP telegram (Fig. 8) includes one or more pairs of OID and value where OID represents the position of the MIB variable in MIB tree. 4. SAEAUT SNMP OPC Server Above mentioned performance considerations we would like to explain in context with our SAEAUT SNMP OPC Server which has following features: protocols SNMPv1, SNMPv2c OPC specifications OPC DA 1.0, 2.05, 3.0, OPC Alarms and Events 1.0, 1.10, OPC XML DA
SNMP OPC server configurator and runtime, which is implemented as out of process server (exe file) OPC XML-DA wrapper support for ICMP pinging of devices using SNMP commands GET, SET, support for trap notification tags in address space of the OPC server are definable using management object base (MIB) object identifier OID for example .1.3.6.1.4.1.2681.1.2.102 configurator has built-in MIB browser that reads device’s MIB database configurator has built-in network scanner limit and digital alarms logging of various activities of the OPC servers To be able to implement various pre-processing algorithms, it is possible to define “JScript items” in the address space of OPC server. They are created by implementing JScript programmed algorithms applied on basic variables corresponding to the data from MIB’s of devices. The period of the next computations y = f(x) (1) where x is a vector of basic variables and y is preprocessed or “JScript tag variable”, is given by UpdateRate of OPC Group to which the “JScript tag variable” belongs. To be able to make computations of the following kind: y = f(x0, x-1, x-2, …, x-n) (2) where xi i = 0, 1 …n is a vector of basic variables ( in time, ti) and y is “JScript item variable”, it is necessary to have possibility to save these data in “JScript global variables”. It is not possible to define order of preprocessed variables computations within one sampling period in this OPC server and so an “JScript item variable”, cannot be used within formula for computation of an another “JScript item variable”. But after saving this induced variable in JScript global variable it can be used in the next period. This means it is possible to use formula: y1 = f(y2-1,x0, x-1, x-2, …, x-n)
about experiences with practical using of large network management systems we assumed possible problem with high CPU load and start up time of the system. Real large network management system we tried to substitute with custom SNMP agents handling many variables and running on PC, and with some other network devices. Of course this substitution is not completely acceptable. In spite of this, we believe that measurements enabled us to make a few useful conclusions from the point of view performance tuning. All tests have been made with the same OPC client application where only asynchronous read/write operations on device (not on cache) have been used. Tests have been made in two phases and so not all results are comparable but in spite of this as some indications usable. Experiences from the first phase we tried to interpret and use for tuning of the OPC server implementation. It was always used Update Rate = 1s in the fist phase. The first phase was realized with devices after the Table 1. The results are shown in Table 2 and Graph 1. It is necessary to hi-lite that to achieve more items, devices have been included more time in address space of the OPC server (column – Number of simulated devices)
Table 1 Test platform
(3)
Alarms can be defined not only for basic variables but for JScript variables too. 5. PERFORMANCE MEASUREMENTS We tried to find out the behavior of SAEAUT SNMP OPC Server within the large system where many items are observed or changed. Going out from information
Table 2 First test results
changed much by changing of number OPC client groups.
Graph 1 First test results
Graph 3 Server activation time dependency on used OPCclient groups
Results from the first phase show that CPU load was substantially smaller for slow real network devices as for SNMP agents running on fast PC. It will be shown later that it is possible to affect it by changing Update Rate yet now, but from this fact an idea arises to add some configurable parameter which enables better balance between time for running threads for communication with devices and threads for communication with OPC clients. We have proved this hypothesis by inserting some sleep time after every item reading. Time for server activation seemed to be too high and so before the second phase we concentrated first of all to tune this parameter. We used two methods – implementation of better memory allocation techniques (made by programmer) and looking for proper configuration that can be made by user.
Graph 4 CPU load during server activation dependency on used OPC client groups We have also tested how it is possible to affect transfer time between OPC server and device by changing amount of items transferred in one SNMP telegram. Transferring of 98 items in separate telegrams 1 item – 1 telegram has taken 105 ms, but transferring of 98 items in one telegram has taken only 9.6 ms. From the point of view easy configuration of OPC client groups the easiest and most universal is to transfer single items, but benefits of transferring more items in one SNMP telegrams are so high from the point of view resources utilization and transfer speed, that looking for proper item grouping algorithms we see as the most perspective way for next development of the SAEAUT SNMP OPC server.
Graph 2 Server activatin / UpdateRate dependancy 5. CONCLUSIONS We have measured time to transfer all 2000 items from devices to OPC server and found out that when Update Rate is smaller than this transfer time, than its changing not affect activation time substantially. (till the value 3095 ms on the Graph 2). After overrun this value, activation time was reduced on about half of its value. We have found out that changing of number of OPC client groups (every device has its own OPC client group) can affect server activation time significantly (Graph 3). By our experiments CPU load was not
The negative impact on transfer delays and data consistency when using OPC server as a transfer mediator can be reduced by proper OPC client implementation and proper configuration both OPC client and OPC server. From measurements described above it is possible to see that easy measure as right choosing Update Rate and proper putting items to the OPC client groups can affect positively more important factors.
6. ACKNOWLEDGEMENT This activity has been financially supported by European Community under the grant IST – 2004 – 004303, NeCST. REFERENCES OPC Foundation (2003), OPC Data Access Custom Interface Specification 3.0 Case, J., et al. (1989), RFC 1098 - Simple Network Management Protocol (SNMP)
Rose, M., and K. McCloghrie (1988), RFC 1065 "Structure and Identification of Management Information for TCP/IP-based internets", Palacka, V., et al. (2006). FTC and integrated process and network control using OPC technology,In: 2nd Workshop on Networked Control System and Fault Tolerant Control University of Calabria, Rende, ITALY Palacka, V., et al. (2005). Integration of Communication concepts in software tools, Deliverable D7-1 of the project NeCST, IST – 2004 – 004303
