You are on page 1of 11

SNMP OPC Server For Network Analysis And Optimization René Silva Daré (

br) Marcos de Oliveira Fonseca ( ATAN Systems, Av Afonso Pena 4001, 9th Floor, Belo Horizonte, Brazil Tel: +55 (31) 3261 8649, Fax: +55 (31) 3261 8900 KEY WORDS: OPC, SCADA, SNMP, data acquisition

ABSTRACT This paper describes a high-tuned OPCDA SNMP Server for network diagnosis and monitoring, which supports heavy data acquisition and is compliant with OPCDA standard interface. The SNMP protocol has made administration and monitoring devices attached to the network easy to perform. It enables fast data acquisition by sending and receiving UDP packets. UDP does not establish connections; it just sends data over the network and waits for a response. On the other hand, OPC changed the way used to communicate different automation devices. Adding the benefits of an SNMP acquisition application with an OPCDA Server, a powerful application for Network Analysis arises, which brings real-time information from all monitored nodes to a SCADA system. To achieve good results, the server must be very robust to ensure right data acquisition along with low impact on the network, specifically on congested networks, where average response times can vary and hence avoid communication overhead. This is accomplished when the server core measures device response times and server thread load for balancing overall scan load from each device inside the data acquisition server thread.

1 – INTRODUCTION OPC has changed the automation world. Today it is possible to use device and field equipment data in PC applications without the need to write vendor specific device drivers for communications. Now that OPCDA communications are available to most field devices, industrial supervisory systems also included native support for OPC devices. This allows an easy integration between a SCADA system and a plethora of different field devices. This added communication brought an extra overhead implying in the necessity of monitoring field network health all the time. Monitoring network activity helps communication bottlenecks discovery, where optimization is required. SNMP is a wide available management protocol and is implemented in most manageable network devices such as switches, hubs and routers. Plus, some field devices like programmable controllers also include support for SNMP. Most network analyzers are sniffers. They work by capturing packets in the network and analyzing the contents in order to determine traffic patterns and overall network utilization. SNMP protocol is simple and requires less processing power over network data than complex network sniffers, offering excellent results. In a typical industrial application, monitoring a variable in a supervisory control system is not enough. The need for a historical data acquisition system is very clear and almost all systems crafted for this purpose are OPCDA compliant, which requires all devices to provide data using this standard communication platform. The SNMP OPCDA Server application acquires data from any SNMP compliant device and delivers this data using the OPCDA interface. Acquired data consists of network statistics such as network utilization in percent, network errors in percent and broadcast communication rates.

2 – SERVER DESIGN Most commercial SNMP OPCDA Servers are not capable of massive data acquisition and hence they are limited for scanning only a few devices. The target was to craft an OPCDA Server capable of fast data acquisition from SNMP devices with low system resources usage. Since OPCDA interface is a pure software layer over vendor specific device drivers, crafting good OPCDA Servers requires lots of programming techniques and excessive code optimizations. The goal was to monitor over five thousand SNMP variables refreshing the entire set every second. Some tested SNMP OPCDA Servers were not able to scan even thousand variables per second. In order to fulfill our requirements, several features were desired, such as fast data acquisition, easy configuration, SNMP fine tuning, low resources usage, intelligent scan control, real-time statistical calculation and data filtering. The main server window is presented in Figure 1.

Figure 1 – Main OPCDA Server Screen

On the screen, all important server information are available in real-time such as active state, client count, group count, number of devices, device items and server load. This allows easy server administration by tuning SNMP parameters in order to achieve optimal results for a given network environment. The server also provides a Front-End system to configure all server settings before server start-up. It allows easy configuration by scanning your network for SNMP compliant devices. On each added device, published variables under configured SNMP community and data acquisition for these variables may be automatically provided. Scanned variables and parameters may also be edited if necessary. If the configuration cannot be made online, the server allows devices and variables to be entered manually. Additionally, it is possible to create special tags which implements special equations to compute valuable device interface data like network utilization, network errors and network broadcast rate. For both tag types a filtering option can be enabled which implements a first order filter with configurable time constant. This creates an additional tag containing the filtered value. Filtering a variable is very useful to remove spikes and hence prevent false alarms to be triggered in your SCADA system. Trap calls are also supported. The server has one dedicated thread to handle all incoming traps and interface data with OPCDA server subsystem. Traps are treated as signal triggers. When a trap is received, it triggers the configured Boolean tag value and after a period of time, it returns to the original state. The trap hold time can be manually configured for each device. All device acquisition parameters can be manually configured to fine tune server data acquisition. Important SNMP parameters like protocol version, refresh rate, object reads per call and scan timeout can be individually set, increasing the server utilization range in field. After all configuration procedures, the server allows this data to be stored as configuration profile. These profiles can be easily loaded to the server memory and it is useful for back-up purposes. The main server Front-End window is presented in Figure 2.

Figure 2 – Server Front-End Main Window

3 – SERVER PROGRAMMING TECHINIQUES Crafting good OPCDA servers requires advanced programming techniques. To accomplish all features and requirements, its structure should be carefully planned. Multithreading modules were used to control the priorities individually but this approach requires caution due to synchronization problems between threads. The first optimization was made at low level, inside the SNMP manager device driver implementation. Several changes were made to accomplish the final target, which required intensive network communication for monitoring more than five thousand variables per second. The second optimization was made inside the interface core, which is responsible for data exchange between the SNMP manager device driver and the OPCDA interface. In this case, several look-up tables were used to create a virtual mapping between the two worlds, SNMP and OPC. The third and final optimization was made inside the OPC interfacing module. OPCDA interface uses pointers to exchange data between server and client applications. This optimization ensures that the OPCDA server will communicate with OPCDA clients using a correct and fast memory allocation routine, to prevent errors originated by COM misuse. SNMP data acquisition involves communications among different SNMP devices and consequently different implementations of SNMP protocol. In some cases, two SNMP compliant devices might have completely different scan times for the same variable group. These response time differences must be treated on the software layer and for that purpose an intelligent algorithm was developed. The algorithm works by measuring response times from each device and computing the average. Depending on the refresh rate of OPC groups the server calculates the amount of time available to acquire SNMP data over the network. If a device starts to introduce delay, it is deactivated for thirty seconds. This algorithm is very useful to maintain the configured OPC group refresh rate when a temporary link down take place. Statistical information is essential for a complete network analysis. Providing raw SNMP data for any OPC client and implementing all statistical data calculation inside the client may generate wrong information, mainly because the sampling of all required variables must be made simultaneously in order to ensure correct calculation. The SNMP manager device driver must also be capable of calculating all statistical information based on raw SNMP data and provide this data to the OPC client.

4 –REAL CASE ANALYSIS The first step in every network analysis is to determine the bottlenecks and discover all critical links that are suitable for optimization. This is accomplished by analyzing the network physical structure and searching for SNMP manageable devices that will provide utilization data for analysis. In the tested environment, half of network links are 100Mbps full duplex links using switches for communication and the other half are 10Mbps half duplex links using common hubs. These links are distributed over two sectors in the same floor which we will call sectors A and B. Both sectors are linked together using one manageable switching device. All servers are also connected to this switch. The network environment before optimization is presented in Figure 3.

Figure 3 – Network Environment Before Optimization

In a first glance it is possible to see that all 10Mbps links from sector A should be upgraded to switch devices with 100Mbps links for better performance, but further field statistics are very important for determining the overall utilization of every link. One week of network monitoring during normal utilization clearly demonstrated all required changes to optimize network operation. The overall network utilization plot before optimization is presented in Figure 4.

Figure 4 – Network Utilization in Both Sectors Before Optimization

Network connections from sector A are very loaded, since all computers attached to the same hub listens to all packets sent from one station to another even if the packet is not addressed to it. This result was expected, as a first glance in this network environment suggested, but information regarding the remaining links could be provided only after intensive network monitoring.

On the other hand, connections from sector B are not loaded. Some connections are even idle all the time. This aspect needs to be optimized too. The network environment after optimization is presented in Figure 5.

Figure 5 – Network Environment After Optimization

After all modifications on the old network environment, one more week of network monitoring during normal utilization demonstrated that all changes were successful, since the network from Sector A is not loaded anymore and all servers are connected in the same switch what increases network monitoring capability.

The overall network utilization plot after optimization is presented in Figure 6.

Figure 6 – Network Utilization in Both Sectors After Optimization

CONCLUSION The SNMP OPCDA Server demonstrated to be a very powerful tool for network diagnosis and optimization. This monitoring system has been used in real world networks for network diagnostics and in all cases it was possible to optimize network utilization based on a low-cost solution, which involved changes in network organization and older device replacement. Using a high-tuned data acquisition core, the OPCDA Server also demonstrated to be very fast and reliable for permanent network monitoring, supporting any OPC compliant clients for data exchange.

REFERENCES 1. OPC Foundation: OPC DA 2.05a Specification, 2. W. Richard Stevens: TCP/IP Illustrated, Volume I: Addison-Wesley, 1994