You are on page 1of 4

Real-Time Data Transfer Using a Real-Time SNMP MIB

Rui-An LOU Chen-Khong THAM Department of Electrical Engineering National University of Singapore 10 Kent Ridge Crescent, Singapore 119260 E-mail: engp7749@leonis.nus.edu.sg, eletck@nus.edu.sg

Abstract
With the widespread usage of embedded devices in data acquisition and industrial control applications, the method of collecting and distributing scientific data has become a very important issue. However there is no standard protocol in present implementations of this kind of Embedded Realtime Applications (ERAs). We propose a new real-time data transfer scheme derived from SNMP, the widely accepted protocol used in network management. This scheme enables embedded devices to collect and push real-time data to the management system over IP-based networks. Based on this scheme, we have implemented a real-time system to transfer temperature data using a real-time temperature MIB.

1. Introduction
In the Simple Network Management Protocol (SNMP) [1] architecture, the agent and the manager are the two main elements. In essence, all the operations performed deal with the fetch-and-store paradigm. A manager can perform two different operations on an agent: request or set the value of a variable in the MIB of the agent. These two operations are known as get-request and set-request. There’s a command to respond to a get-request called get-response, which is used only by the agent. SNMP defines a separate standard for the data managed by the protocol. This standard defines the data maintained by a device in the network and what operations are allowed on it. The data is structured in a tree form, and there is a unique path to reach each variable. This structured tree is called the Management Information Base (MIB) [2]. The normal SNMP paradigm is based on one request and one response. The agent analyzes the incoming request and gets the object identifiers (OIDs) of the variables the manager wants to retrieve. Then it searches the registered MIB trees to look for the function pointer of the read or write operation associated with each variable, executes the read or

write command before sending the resulting packet back. Some work has been done in network management to monitor data flow using SNMP, such as the Multi Router Traffic Grapher (MRTG) [3] which graphically represents the data SNMP agents provide to SNMP managers. However, this architecture is not suitable for a manager to retrieve realtime data from an agent, because real-time data, especially environmental data, is always varying with time. This kind of data should be transferred continuously at very short intervals in order to capture its time-varying characteristics. In order to provide an approach for transferring timevarying data over IP-based networks, we have designed a new real-time SNMP-based scheme. In this scheme, we define a new MIB called the real-time MIB, which is different from the conventional static MIB structure but can coexist with these conventional MIBs. In addition, we change the conventional method of implementing an SNMP agent by using dynamic priority assignment as well as concurrent programming to make the agent a real-time multitasking process. In our implementation of this scheme, a real-time temperature meter daemon is implemented to feed data to the real-time MIB. We also implement an intelligent management system to automatically receive the real-time data. The start and end of the transfer can be controlled in realtime.

2. Proposed Real-Time SNMP Scheme
In our real-time data transfer mechanism, the real-time MIB is what differs from a normal SNMP MIB. This MIB not only contains the variables we want to monitor in realtime (we name this part RT-MIB I), but also contains other parameters, including the user-defined limits and status information (we name this part RT-MIB II), to control the whole real-time transfer process. More than one real-time MIB can be contained in an agent. Once the agent receives a request for data in the RT-MIB I, it will activate the real-time meter daemon for this realtime MIB to acquire the time-varying data continuously

1. (2) the sink or receiver of the data which is our intelligent management system (IMS). This process repeats continuously till the agent receives a high-priority set command from the management station to change the status parameter in the RT-MIB II. there are two functional elements: (1) the source or sender of data collected by the real-time embedded agent (RTEA). The second set contains the user-defined limits of the real-time data range. Simultaneously. In addition. the transfer is stopped. Three sets of information related to the real-time meter daemon should be reflected in the real-time MIB. Depending on the different usages of the embedded devices there is a real-time meter daemon running on them to provide the real-time data. it should be the set of information surrounding this real-time temperature meter daemon that makes up the real-time MIB. The syntax of the table is as follows: f TaskID (of this real-time monitor process). If the management daemon is already running on the IMS. The RTEA is similar to a normal SNMP agent in that it can process the SNMP get and set requests for the conventional MIBs and return the information . it accepts the notification from the agent and automatically sends a request to the agent for the predefined time-varying data in the RT-MIB I. the monitor process will continuously read the value from the global variable. If the OIDs of the variables contained in the incoming packet are in the RT-MIB I. At the same time we can query other variables in the real-time MIB or the conventional MIBs to get additional information about the agent and the running monitor processes. If the agent receives several successive requests for data in the same RT-MIB I.and write the value to a global variable. When the agent boots up. It dynamically creates tasks in response to incoming requests and adjusts the priorities of the tasks at run-time. For instance. ImsIP (the IP address of the corresponding IMS). processes them and gets the useful information. pack it with other necessary data and send the resulting packet to the management station within a fixed user-defined interval. it can process the requests for the real-time MIB.1. When an IMS accepts a boot-up notification from RTEA. dynamically creating tasks in response to the incoming requests and adjusting the priorities of the tasks according to their importance. which is a flag to control the start and end of a real-time monitor process. the real-time meter daemon for this real-time MIB is created once when the first request comes in and terminates when all the monitor processes are killed. it creates a new task to handle each one. One set includes the real-time data value and the timestamp when reading the real-time data value. waiting for incoming requests. After that. If the embedded device can collect more than one kind of real-time data needed by the network manager. it sends a notification to the pre-configured IMS. We can restart the monitor at anytime by querying the RT-MIB I. if the embedded device is to measure the environmental temperature. 1.g. 2. Several real-time meter daemons can run simultaneously to provide data in response to the respective incoming requests. StatusFlag (whether this monitor process is running or not) 2 2. There can be more than one IMS. e. The main data represented by the real-time MIB should be collected by different real-time meter daemons whose main function is to get the real-time data from the corresponding hardware device. its corresponding task will add one record describing this monitor process to the active monitoring process table (AMP table). it automatically sends a request to the agent to ask for the real-time data in the RT-MIB I according to the real-time MIB OID configuration.1 Real-Time Embedded Agent and Dynamic Priority Scheme On the agent side. Alarms can be received by the network manager when the real-time data measured by the device are out of range. Real-Time Data Transfer Structure In our real-time data transfer structure. IMS 1 RTEA IMS 2 IMS 3 Figure 1. the number of management systems simultaneously querying this real-time MIB. When the agent receives incoming requests. RT-SNMP based real-time data transfer model in a response protocol data unit (PDU). and the real-time meter daemon is killed. the real-time MIBs related to the other functionalities can also be constructed. The following sections describe the structure in detail. the ROOT daemon (see Figure 2) runs all the time. The error flag and error message contained in this set indicate trouble with a monitor process and describe the problem. Then it waits for the arrivals of the real-time SNMP packets. The last set contains the status information related to the real-time monitor processes. 2.

E. 3. The monitor processes then read from this variable. RT Meter Daemon RTget Semaphore1 RT-MIB I ROOT Daemon (waiting for incoming requests) RT1 Task RT-MIB II Normal MIBs RTset snmpget&set RT2 Task write write Semaphore2 AMP Table Figure 2. 1) g and the value of monitoring status in the RT-MIB II is 2 (two monitor processes are running). the type of the task is known. the ROOT daemon is the initial process started as soon as the embedded device boots up. Tasks dynamically created by RTEA data. If we don’t use a prioritybased pre-emptive multitasking operating system to do the scheduling. Figure . Based on the task type. All the other tasks can be created at an initial priority of P3 . Normally priority level 0 is reserved for the real-time kernel daemon task IDLE and a small range of the highest priority levels is reserved for a variety of RTOS daemon tasks. we need to send as many packets as possible from the agent to the IMS in order to get more accurate information about the time-varying data. while RTMS is a periodic process that receives the real-time data from the start to the end of the monitoring. there are several kinds of tasks dynamically created in response to the incoming requests from the IMS: (a) Get request to retrieve the real-time data in RTMIB I. 2. (e) Set command to change the user-defined limits in RT-MIB II. After getting the packet type and OIDs contained in the request PDU. Figure 3 shows the user processes in IMS and their relative priorities. In our implementation.2 Intelligent Management System write In Figure 2. On the RTEA. snmpget&set and RTget&set are requests sent from IMS at different times. kill the corresponding monitor task using TaskID and set the StatusFlag to 0. (b) Get request to retrieve the user-defined limits and monitoring status information in RT-MIB II. the real-time meter daemon is also killed. the pSOS+ real-time kernel sets the task’s priority within the range 1  239. If RTset wants to close one of the running monitor processes. which can be dynamically assigned to the tasks created by the user application. we should guarantee the processing requirements of IMS. Ims1IP. Figure 2 shows two monitor processes which are running and their states. The RTget task is created to retrieve user-defined limits and monitoring status information. 1). if the task is to change the monitoring status value in the RT-MIB II. the real-time meter daemon can be created with a priority of P2 that is higher than P1 . Then the real-time meter daemon is activated to repeatedly read the real-time value from the device and write it to a global variable within a fixed interval. (RT2. we assign it the highest priority P4 . we adjust the priority level to achieve the best real-time performance. In order to keep good real-time performance.g. while the other tasks are created at run-time. the other is to schedule the reading and writing of the AMP table. we deploy a dynamic priority scheme so that the more important process whose deadline is near will have higher priority. The RTset task. the task will search the AMP table by the index of ImsIP. saving it in a file and displaying it as a graph. Two semaphores are used in the agent.g. minimize the delay jitter and loss rate. the performance will be degraded when there are a lot of other network applications running simultaneously with IMS. (d) Set command to change the monitoring status in RT-MIB II. Based on the relative importance of these 7 tasks and the ROOT daemon on the embedded device. If all of the monitor processes are killed. Ims2IP. sets the limits and status. This real-time temperature transfer system (RTTS) has been successfully deployed in our lab without any software failure over a two-week period. the ROOT daemon can be created with a priority of P1 . and (g) The real-time meter daemon to collect the time-varying 3 read read write read In our real-time data transfer system. Thus IMS must handle the packets as fast as possible which include processing them. For instance. In this figure.1. The RT1 and RT2 tasks are two real-time monitor processes. A range of priority levels should be provided by the real-time operating system (RTOS) supporting the embedded device. One is to schedule the reading and writing of the real-time data. The AMP table in the figure contains two records: f (RT1. (f) Set command to change normal MIB variables. (c) Get request to retrieve the variables in normal MIBs. which we shall see in our tests. getting the real-time data they contain. with 239 the highest and 1 the lowest. Implementation of the Real-Time Temperature Transfer System We have implemented a real-time system to transfer temperature data using a real-time temperature MIB based on the proposed scheme. The snmpget and snmpset tasks are to permit normal SNMP operations. in the pSOSystem RTOS. which is of the highest priority.

we implement it on KURT Linux (KU Real-Time Linux) [6]. We use it in our embedded agent to provide the timestamp for our real-time MIB.ittc. It incorporates on-chip many of the communications/networking capabilities and peripheral I/O functions offered by the overall MBX product.edu/projects/kurt/ [7] Balaji Srinivasan.html [5] Integrated Systems. After evaluating several RTOS. http://www. Schoffstall. “Understanding SNMP MIBs White Paper”. a scalable.mot. The MBX is based on the MPC8xx processor. Inc. (Simple Network Management Protocol. it can be seen that the operating system is a crucial element to consider in the implementation of such a scheme in order to ensure good real-time performance. 4MB Flash. “The KU Real-Time Linux”. http://hegel. http://www. The University of Kansas.1p) with the real-time data transfer system described in this paper. we chose pSOSystem. Davin.Fedor.isi. It provides a complete multitasking environment based on open systems standards.html [6] ITTC.. “A Firm Real-Time System Implementation Using Commercial Off-The-Shelf Hardware and Free Software”.RTMS (RT Monitoring Periodic Process) prio: 4 RTget (Get the RT-MIB II variables) prio: 3 RTset (Set the RT-MIB II variables) prio: 5 snmpget (Get the Normal MIBs variables) prio: 2 snmpset (Set the Normal MIBs variables) prio: 2 Other Applications prio: 1 Figure 3.)” [2] Perkins.com/WebOS/omf/GSS/MCG/products/boards/ebx. In this paper. [4] Motorola Computer Group. “Embedded Systems Software and Design Automation Solutions”. The implementation of the real-time temperature transfer system demonstrates the feasibility of this scheme. From the results of our tests.com/Products/pSOS/index. Our IMS belongs to the class of applications that combine the timing requirements of hard real-time applications with the need for operating system services typically available only on soft real-time or timesharing systems. LinuxFocus. we will employ predictable networking technologies like Asynchronous Transfer Mode (ATM) and priority-enabled LAN (IEEE 802. The Motorola MBX821-002 embedded controller (standard version. 4MB DRAM. The real-time performance of IMS can be guaranteed even in the situation of high CPU load. “MBX Board Products Index”. 4. 4 Real-time monitoring and control of remote embedded devices is a very important issue not only in industrial automation but also in network management. “RFC 1157. User tasks in the IMS Hub IMS IMS and the pSOS+ real-time multitasking kernel provides a responsive. 10BaseT Ethernet) that we have used to implement the RTEA comes from the Motorola MBX embedded controller range [4]. Real-Time Technology Applications Symposium 1998. M. we need a RTOS which can operate on the Motorola embedded controller card. . which features a single-issue integer PowerPC core combined with an RISC-based communications processor. high-performance embedded operating system from Integrated Systems. several managers can continuously retrieve real-time information such as environmental data from the embedded device simultaneously by querying the real-time MIB. efficient mechanism for coordinating the activities of the real-time system. while still giving them access to the full range of Linux services [7]. Test-bed of prototype implementation 4 shows the test bed and locations of each of the functional elements. David. M. With this scheme. KURT Linux has the ability to support the comparatively stringent timing requirements of this kind of applications. Among the outputs of the clock module is a realtime clock (RTC). In order to guarantee the real-time performance of IMS.. References [1] Case. In order to do real-time scheduling of the agent processes and request processing from the IMS. J. The real-time clock provides a time-ofday indication to the operating system and to the application software. Shyamalan Pather. Inc [5]. which is a firm real-time Linux system. a new SNMP-based real-time data transfer scheme has been presented. [3] David Guerrero. and J.ukans. July 1992. Conclusion VIRATA MBX821 Router IMS ATM LAN Emulation FastEthernet Figure 4. Volume 2. In the future. 40MHz MPC821. “Network Management & Monitoring with Linux”. The MPC8xx processor chip used on MBX embedded controllers incorporates a clock module to provide the various system clock and timer functions. January 1998.mcg.