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 scientic 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. Theres a command to respond to a get-request called get-response, which is used only by the agent. SNMP denes a separate standard for the data managed by the protocol. This standard denes 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 identiers (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 ow using SNMP, such as the Multi Router Trafc 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 dene 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-dened 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

and write the value to a global variable. Simultaneously, the monitor process will continuously read the value from the global variable, pack it with other necessary data and send the resulting packet to the management station within a xed user-dened interval. 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. After that, the transfer is stopped, and the real-time meter daemon is killed. If the agent receives several successive requests for data in the same RT-MIB I, the real-time meter daemon for this real-time MIB is created once when the rst request comes in and terminates when all the monitor processes are killed. We can restart the monitor at anytime by querying the RT-MIB I. 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. 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. For instance, if the embedded device is to measure the environmental temperature, it should be the set of information surrounding this real-time temperature meter daemon that makes up the real-time MIB. If the embedded device can collect more than one kind of real-time data needed by the network manager, the real-time MIBs related to the other functionalities can also be constructed. Several real-time meter daemons can run simultaneously to provide data in response to the respective incoming requests. Three sets of information related to the real-time meter daemon should be reected in the real-time MIB. One set includes the real-time data value and the timestamp when reading the real-time data value. The second set contains the user-dened limits of the real-time data range. Alarms can be received by the network manager when the real-time data measured by the device are out of range. The last set contains the status information related to the real-time monitor processes, e.g. the number of management systems simultaneously querying this real-time MIB, which is a ag to control the start and end of a real-time monitor process. The error ag and error message contained in this set indicate trouble with a monitor process and describe the problem.

IMS 1

RTEA

IMS 2

IMS 3

Figure 1. RT-SNMP based real-time data transfer model

in a response protocol data unit (PDU). In addition, it can process the requests for the real-time MIB, dynamically creating tasks in response to the incoming requests and adjusting the priorities of the tasks according to their importance. When an IMS accepts a boot-up notication from RTEA, 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 conguration. Then it waits for the arrivals of the real-time SNMP packets, processes them and gets the useful information. 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. The following sections describe the structure in detail. 2.1.1 Real-Time Embedded Agent and Dynamic Priority Scheme On the agent side, the ROOT daemon (see Figure 2) runs all the time, waiting for incoming requests. It dynamically creates tasks in response to incoming requests and adjusts the priorities of the tasks at run-time. 1. When the agent boots up, it sends a notication to the pre-congured IMS. There can be more than one IMS. 2. If the management daemon is already running on the IMS, it accepts the notication from the agent and automatically sends a request to the agent for the predened time-varying data in the RT-MIB I. When the agent receives incoming requests, it creates a new task to handle each one. If the OIDs of the variables contained in the incoming packet are in the RT-MIB I, its corresponding task will add one record describing this monitor process to the active monitoring process table (AMP table). The syntax of the table is as follows: f TaskID (of this real-time monitor process), ImsIP (the IP address of the corresponding IMS), StatusFlag (whether this monitor process is running or not) 2

2.1. Real-Time Data Transfer Structure

In our real-time data transfer structure, there are two functional elements: (1) the source or sender of data collected by the real-time embedded agent (RTEA); (2) the sink or receiver of the data which is our intelligent management system (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

g. 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 xed interval. The monitor processes then read from this variable. Figure 2 shows two monitor processes which are running and their states.
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. Tasks dynamically created by RTEA

data. Based on the relative importance of these 7 tasks and the ROOT daemon on the embedded device, we deploy a dynamic priority scheme so that the more important process whose deadline is near will have higher priority. A range of priority levels should be provided by the real-time operating system (RTOS) supporting the embedded device, which can be dynamically assigned to the tasks created by the user application. For instance, in the pSOSystem RTOS, the pSOS+ real-time kernel sets the tasks priority within the range 1  239, with 239 the highest and 1 the lowest. 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. In our implementation, the ROOT daemon can be created with a priority of P1 , the real-time meter daemon can be created with a priority of P2 that is higher than P1 . All the other tasks can be created at an initial priority of P3 . After getting the packet type and OIDs contained in the request PDU, the type of the task is known. Based on the task type, we adjust the priority level to achieve the best real-time performance. E.g. if the task is to change the monitoring status value in the RT-MIB II, we assign it the highest priority P4 . 2.1.2 Intelligent Management System

write

In Figure 2, the ROOT daemon is the initial process started as soon as the embedded device boots up, while the other tasks are created at run-time. The RT1 and RT2 tasks are two real-time monitor processes. The RTget task is created to retrieve user-dened limits and monitoring status information. The RTset task, which is of the highest priority, sets the limits and status. If RTset wants to close one of the running monitor processes, the task will search the AMP table by the index of ImsIP, kill the corresponding monitor task using TaskID and set the StatusFlag to 0. If all of the monitor processes are killed, the real-time meter daemon is also killed. The AMP table in the gure contains two records: f (RT1, Ims1IP, 1), (RT2, Ims2IP, 1) g and the value of monitoring status in the RT-MIB II is 2 (two monitor processes are running). The snmpget and snmpset tasks are to permit normal SNMP operations. Two semaphores are used in the agent. One is to schedule the reading and writing of the real-time data, the other is to schedule the reading and writing of the AMP table. On the RTEA, 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; (b) Get request to retrieve the user-dened limits and monitoring status information in RT-MIB II; (c) Get request to retrieve the variables in normal MIBs; (d) Set command to change the monitoring status in RT-MIB II; (e) Set command to change the user-dened limits in RT-MIB II; (f) Set command to change normal MIB variables; and (g) The real-time meter daemon to collect the time-varying 3

read read write read

In our real-time data transfer system, 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. Thus IMS must handle the packets as fast as possible which include processing them, getting the real-time data they contain, saving it in a le and displaying it as a graph. In order to keep good real-time performance, minimize the delay jitter and loss rate, we should guarantee the processing requirements of IMS. If we dont use a prioritybased pre-emptive multitasking operating system to do the scheduling, the performance will be degraded when there are a lot of other network applications running simultaneously with IMS, which we shall see in our tests. Figure 3 shows the user processes in IMS and their relative priorities. In this gure, snmpget&set and RTget&set are requests sent from IMS at different times, while RTMS is a periodic process that receives the real-time data from the start to the end of the monitoring.

3. 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. This real-time temperature transfer system (RTTS) has been successfully deployed in our lab without any software failure over a two-week period. Figure

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. User tasks in the IMS

Hub IMS IMS

and the pSOS+ real-time multitasking kernel provides a responsive, efcient mechanism for coordinating the activities of the real-time system. In order to guarantee the real-time performance of IMS, we implement it on KURT Linux (KU Real-Time Linux) [6], which is a rm real-time Linux system. 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. KURT Linux has the ability to support the comparatively stringent timing requirements of this kind of applications, while still giving them access to the full range of Linux services [7]. The real-time performance of IMS can be guaranteed even in the situation of high CPU load.

4. Conclusion
VIRATA MBX821 Router IMS ATM LAN Emulation FastEthernet

Figure 4. Test-bed of prototype implementation

4 shows the test bed and locations of each of the functional elements. The Motorola MBX821-002 embedded controller (standard version, 40MHz MPC821, 4MB DRAM, 4MB Flash, 10BaseT Ethernet) that we have used to implement the RTEA comes from the Motorola MBX embedded controller range [4]. The MBX is based on the MPC8xx processor, which features a single-issue integer PowerPC core combined with an RISC-based communications processor. It incorporates on-chip many of the communications/networking capabilities and peripheral I/O functions offered by the overall MBX product. The MPC8xx processor chip used on MBX embedded controllers incorporates a clock module to provide the various system clock and timer functions. Among the outputs of the clock module is a realtime clock (RTC). The real-time clock provides a time-ofday indication to the operating system and to the application software. We use it in our embedded agent to provide the timestamp for our real-time MIB. In order to do real-time scheduling of the agent processes and request processing from the IMS, we need a RTOS which can operate on the Motorola embedded controller card. After evaluating several RTOS, we chose pSOSystem, a scalable, high-performance embedded operating system from Integrated Systems, Inc [5]. It provides a complete multitasking environment based on open systems standards, 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. In this paper, a new SNMP-based real-time data transfer scheme has been presented. With this scheme, several managers can continuously retrieve real-time information such as environmental data from the embedded device simultaneously by querying the real-time MIB. The implementation of the real-time temperature transfer system demonstrates the feasibility of this scheme. From the results of our tests, 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. In the future, we will employ predictable networking technologies like Asynchronous Transfer Mode (ATM) and priority-enabled LAN (IEEE 802.1p) with the real-time data transfer system described in this paper.

References
[1] Case, J., M.Fedor, M. Schoffstall, and J. Davin, RFC 1157. (Simple Network Management Protocol.) [2] Perkins, David, Understanding SNMP MIBs White Paper, July 1992. [3] David Guerrero, Network Management & Monitoring with Linux, LinuxFocus, Volume 2, January 1998. [4] Motorola Computer Group, MBX Board Products Index, http://www.mcg.mot.com/WebOS/omf/GSS/MCG/products/boards/ebx.html [5] Integrated Systems, Inc., Embedded Systems Software and Design Automation Solutions, http://www.isi.com/Products/pSOS/index.html [6] ITTC, The University of Kansas, The KU Real-Time Linux, http://hegel.ittc.ukans.edu/projects/kurt/ [7] Balaji Srinivasan, Shyamalan Pather, A Firm Real-Time System Implementation Using Commercial Off-The-Shelf Hardware and Free Software, Real-Time Technology Applications Symposium 1998.