An Adaptable Framework for Remote Tool Monitoring and Control

Chris Loeser, Robbie Schaefer, Wolfgang Mueller, Marc BorowskiPaderborn University/C-LAB

Fuerstenallee 11, 33008 Paderborn, Germany

Abstract

Engineering collaborations received a new global dimen-sion with the omnipotent access to Internet. Several ap-proaches have been introduced to support communicationbetween collaborating engineers but little attention hasbeen paid to enhance remote access to distributed servicesfrom mobile devices. In this paper, we propose a frame-work for remote tool monitoring and control (RTMC),which can be extended by the user through the definitionof application specific plug-ins. The main properties ofour RTMC framework are extensibility, interconnectionwith mobile devices, and independence from any opera-ting systems and devices. To achieve mobile monitoringand control, we applied JXTA, which supports direct com-munication between stationary PCs and Java enabled mo-bile phones. We also introduce a so-called user-trackinglayer for user location dependent message relay.

1 Introduction

Collaborative engineering constitutes a paradigm of en-gineering work that is central to the vision of the engi-neering working environment in the Information Society.From the technical point, most collaborative engineeringframeworks do presently not adequately support the inte-gration of very complex engineering environments wheninterconnecting multiple design groups and do not con-sider distance-spanning related issues like firewalls, se-curity, remote tool administration, and distributed designflow automation. Distributed engineering developmentneeds however new infrastructures, net-aware tools, andnew design methodologies based on re-use in combina-tion with advanced security and network and tool man-agement as they are introduced by the Advanced Collab-orative Infrastructure (ACI) in [5, 9], which focus on toolaccess and design data exchange in engineering environ-ments distributed over several Intranets.However, existing approaches like ACI mainly consider

communication and tool integration aspects in distributedengineering environments. Our current focus is on themonitoring and control of remote engineering tools andservices, which can be accessed even from mobile de-vices. The key idea comes from daily application, wherean engineer usually cannot continuously monitor remotetools and services such as complex time and resource con-suming engineering simulations. Those services are typ-ically executed remotely and an engineer performs othertasks while the service is running. When such a servicehas finished or failed, the engineer needs an immediatenotification in order to check and to eventually set up anew simulation, if necessary. Especially the case of a sim-ulation run failure needs to be detected as soon as it occursin order not to waste too much time to set up new runswith new parameters. Reasons for such an abortion canbe much different, for example, wrong parameters, disk orsystem memory overflow, or invalid programs may led toruntime exceptions or segmentation faults. In many cases,the problems can be easily fixed, e.g., by a restart withnew parameters or by the use of a different machine inthe network. However, the engineer who takes measurestypically needs to sit in front of a computer to use, con-trol, and monitor the services. Since some engineeringservices like complex simulations may run several days,the person could more efficiently spent the time betweenwhen notifications are immediately forwarded to home orto business trip locations so that problems can be rapidlyfixed.

To support this, we introduce our RTMC (Remote ToolMonitoring and Control) framework. RTMC is an exten-sible framework that allows to control and monitor toolsand services remotely. As we identified the need for con-trolling these tools in nomadic settings (e.g., on businesstrips), it is important to provide mobile and secure access,which is addressed by RTMC through a user-trackinglayer managing different devices that are used on differ-ent locations or occasions. Secure control and access ismanaged by integration of a TLS layer for encryption andauthentication.

The RTMC architecture mainly follows a traditionalclient/server approach with the tools and services to becontrolled at a server side and a monitoring via mobileand stationary clients. We chose the peer-to-peer frame-work JXTA to implement our RTMC architecture since itis available as source code and greatly supports heteroge-neous computing environments with mixed stationary andmobile devices.The remainder of this article is structured as follows. Af-ter elaborating the related work, we introduce basic princi-ples of JXTA. Then we explain the basic RTMC architec-ture and give an overview of the user-tracking layer beforeclosing the paper with a conclusion.

2 Related Work

RTMC may be considered as a high level and secure alter-native to the simple network management protocol SNMP(Simple Network Management Protocol) [10]. SNMP istypically runs a client server application based on the UDPservice of the TCP/IP protocol suite. SNMP version 3(SNMPv3) was defined and implemented specifically toadd security to network management. Since version 3SNMP also supports authentication and encryption. Thereare a multiple tools available for developers to easily inte-grate SNMP management information bases (MIBs) andagents into mobile client application software. Multipletools are available from different vendors such as NuDe-sign Team [7], MG-SOFT [6], FutureSoft [2], and DMH[1] with different application development environments.Most tools allow defining the MIB elements using a spe-cific syntax that fully defines object attributes.For remote monitoring on mobile devices, ELC technolo-gies has just released PiranhaWAP [8], an open sourceWAP/WML-enabled server status reporting product. Pi-ranhaWAP allows displaying real-time system informa-tion such as uptime, load average, and memory infor-mation on WAP/WML enabled devices such as mobilephones. However, their concept is not extensible and theuser still has to deal with the predefined application con-trol capabilities.

3 JXTA

Our approach for remote tool monitoring and control isbased on the client/server paradigm, which means thathardware and software resources and services like sim-ulators are on a dedicated tool server and remote clientsare used to control those tools. Therefore, at a first glance,it seems to be inappropriate to apply a peer-to-peer frame-work in order to build such architecture. However, we

think that JXTA [4] is a good alternative for implement-ing a remote tool monitoring and control framework.Project JXTA is an open-source project initiated by SunMicrosystems as a thin alternative to their Jini frame-work [3]. It has been designed with the participation ofa growing number of experts from academia and indus-try. Project JXTA was initiated to standardize a commonset of protocols for building peer-to-peer applications andto overcome different variations of peer-to-peer APIs andprotocols, which have been designed to be implementableon any device. JXTA protocols create a virtual network ontop of the existing physical network infrastructure basedon which services and applications are set up. This virtualnetwork layer is designed to be as simple as possible withpowerful primitives in order to maintain interoperabilitybetween different devices and operating systems.The main purpose of the JXTA virtual network is to hidethe complexity of the underlying physical network to-pology, and provide a uniform addressable network forall peers in the network. The virtual network allows apeer to exchange messages with any other peer indepen-dently from its network location. Messages are trans-parently routed potentially traversing firewalls or NATs(network address translation) with the ability to use dif-ferent transport/transfer protocols (TCP/IP, HTTP). JXTAstandardizes the way in which peers discover each other,self-organize into peer groups, advertise and discover net-work resources, communicate with peers, and monitorstheir reachability. The network transport layer is built ofa uniform peer addressing scheme based on a peer ID, re-lay peers that relay messages between peers, and a binarymessage format to transport binary and XML data.A peer is uniquely identified by its peer ID (128 bitUUID), even if it uses different network addresses evenwhen the device may have different IPs at different times(e.g., a notebook). Similarly, a device supporting multi-ple network interfaces (e.g., Ethernet, WLAN, Bluetooth,IrDA) can be addressed as a single peer. The peer ID ab-straction allows a peer to encapsulate not just physicaltransports, but also logical transfer protocols like HTTPand/or secure protocols like TLS and SSL.JXTA runs on workstations, PCs, PDAs, mobile phones(with MIDP), and web pads and is therefore a good can-didate for establishing mobile monitor and control appli-cations. Since JXTA defines a set of XML protocols, thedata transfer between the controlling client and the serverside tools is managed in a transparent way, allowing easyintegration of new tools and services. The independenceof programming languages, system platforms, service def-initions and low level network protocols - such as TCP/IPor Bluetooth - clearly support our remote monitoring ap-plications. JXTA is able to deal with firewalls or with ’hid-den’ nodes from network address translation. Therefore,mobile applications are enabled to remotely control tool

servers, which are in a secured Intranet. This of courserequires secure transmissions of data.

Figure 1: RTMC Architecture based on JXTA

4 RTMC

With our RTMC (remote tool monitoring and control)framework we introduce a system, which seamlessly com-bines real-time communication and remote service moni-toring and control. It includes a notification service whenremote services/tools like simulations have completedtheir execution by successfully finishing or failure. Usersmay have full control to configure and (re)start service ap-plications remotely. For supporting a distributed architec-ture of interrelated tools and their respective servers, weconsider tool servers as nodes in the network. Each peeris able to gain resource and status information of otherpeers, which identify themselves as tool servers. Simulta-neously each tool server offers this information to all othernodes.By using and extending the JXTA peer-to-peer frame-work, we are able to control and monitor those serversas peers, even with mobile devices. JXTA ensures thatthey are aware of each other by utilizing so-called ren-dezvous servers, which act as a directory server storingreferences of peers content and services. To handle lim-ited devices like J2ME enabled mobile phones, JXTA uti-lizes relay servers, which act as an intermediate translationinstance. Because many limited devices are not able toprocess XML messages, the relay-server transforms stan-dard XML messages into binary XML messages, whichare relayed to the limited devices and vice versa.Since JXTA has no built-in support for reliable connec-tions, we extended the protocol in order to keep a connec-tion between two peers, which means that we are able toestablish a reliable two-way communication between the

tool server and the controlling application. To this end, weimplemented a socket-like bi-directional connection thatsupport three different policies for packet exchange: (i)event based (using a listener), (ii) synchronous (wait un-til it receives a packet), and (iii) asynchronous (receivedpackets are stored in a buffer). Sockets can be connec-tionless, connection-oriented, reliable, or unreliable.We built the RTMC communication layer upon the ex-tended JXTA communication, as given in Figure 1. Thelayer is separated into the plug-in layer and the user-tracking layer. The plug-in layer is for controlling andmonitoring capabilities and flows for remote applicationsand thus provides the core RTMC functionality. It pro-vides a basic set of RTMC functions and defines whichand how information is passed to the user or to the con-trolled application.An RTMC default plug-in mainly provides means to re-trieve system information from a peer and to deliver com-mands to remote peers. For example, functions can bedefined to check for the available disk space, uptime, OSswap activity, available/running applications, alerts, pro-cess IDs, and for individual CPU utilization with processre-nicing. Most powerful is the integrated shell plug-into support user-defined commands and parameters to starttools and to control the remote peer provided the user hasaccess permission to that peer. Additionally, for remotemonitoring, we have defined an SMS plug-in to notify auser when an alert occurs. For this, rules have to be de-fined when a notification alert is sent, e.g., only high prio-rity errors/completions are filtered and sent via SMS whileothers are just collected in a local logfile.JXTA as a core system for RTMC has the great advan-tage, that is comes an integrated instant messaging func-tionality (in fact one of the most common peer-to-peer ap-plications), which can be used even on mobile devices.Though some manufacturers have already extended SMSto a proprietary SMS chat protocol, those protocols nei-ther work with mobile phones from other manufacturersnor is it possible to interact with other devices like PDAsor PCs. Thus, currently only JXTA provides instant mes-saging over stationary and mobile devices.For an enhanced nomadic application consider the follow-ing scenario. An engineer starts a time-consuming sim-ulation just before leaving to home in order to have re-sults available on the next morning. Via RTMC servicesthe engineer can receive a message when the simulationstopped for some reason. Via RTMC he/she can retrievebasic resource utilization information in order to get firstinformation about potential problems like disk overflow.When he/she cannot fix the problem from remote, he/shemay wish to contact the emergency system administrationvia instant messaging, email, or telephone to outline theproblem. After fixing the problem, the service can be ea-sily relaunched via RTMC.

Figure 2: RTMC Graphical Front-End for Stationary Machines

Figure 2 shows a screenshot of graphical RTMC front-end, as it is presented to the RTMC user. The upper lefthas a list of users, which can be contacted for online com-munication. Messages are entered in the text input field atthe bottom. On the left side there is also list of availableRTMC commands, where the right hand side displays allevents and messages received by RTMC and JXTA, re-spectively. Through this interface, every RTMC user ofthe same group has access to exactly the same informa-tion, which is a great aid to collaborately solve problems.

Figure 3: RTMC on a MIDP enabled Siemens SL45i

While this front-end can be used for workstations and

PCs, mobile implementations are more limited. Enteringlengthy command strings, for example, is feasible but notalways very efficient. Therefore, RTMC on mobile phonescomes with buttons rather than text input fields wheneverpossible in order to send RTMC commands. Figure 3shows an example of the RTMC user interface on a J2ME-enabled mobile phone.

5 UTL - User Tracking Layer

In distributed and mobile environments we face the situa-tion that nomadic users very likely operate with differentdevices on different occasions and locations. It is not veryefficient to broadcast messages to all devices of each user.The critical point, beyond costs and bandwidth, is the fil-tering of self-created ’spams’ since the replication maysend multiple copies of the same message. Thus, whena user returns to the PC, he/she does not want to processthe same messages again, which were already received bymobile phone or PDA. To tackle that problem, we have de-fined the user-tracking layer (UTL) for RTMC. The UTLovercomes the issues of device cluttering by managing allthe devices of one user.The core component of UTL is the instance manager,which is added to a JXTA relay server (see Figure 4).When the relay server receives a message, it determinesthe currently registered device of the receiver. The cur-rently active devices are determined by timeouts. When,for example, the user logs in at the home or at the of-

Figure 4: User Tracking Layer - Message Relay to the Active Device

fice PC, the RTMC instance registers the user at the relayserver. When the user either logs off or after a predefinedtimeout, the system tries to relay all messages to the user’sdefault device.

Figure 5 shows a sequence diagram with details of theabove sketched behavior of the instance manager, i.e.,when a user connects with instance A and a second client Bis already connected. At the beginning, the active instancecontroller looks for other active instances and decides onthe priority of the active client. The priority depends onthe status (online, offline) and on the time expired sincethe last user interaction. After having set the status fromclient A to online, the active instance controller comparesits own priority with that of other devices (in that caseB) and detects that its priority is the highest one and thusmarks its own instance as active. After that, the ping ser-vice starts sending ping messages to other clients. Theping messages have information about the active client,time of the next ping, status, and priority. Since all clientsreceive ping messages, the still active instance B is noti-fied as well and recognizes that it does not keep the highestpriority. Finally, B sets itself to inactive. If the new activeinstance A stops sending the ping messages for some rea-son, instance B detects this after the timeout interval andtakes the role of the active instance again.

6 Conclusion

In this paper we introduced the RTMC framework, whichsupports monitoring and control of services in the con-text of engineering applications. Users can easily definetheir own application specific control modules, which areloaded into the RTMC framework as plug-ins. Due toJXTA, RTMC supports even small computing devices likemobile phones with instant messaging support. With auser-tracking layer, data can be sent to the currently activeor to the default device of a user.

Though we have developed RTMC in the context of en-gineering applications like remote control and monitoringof simulators, we see a great potential for application inremote maintenance since, for instance, maintenance per-sonal could easily download error codes via RTMC to mo-bile phones once the remote device is connected to a net-work.

Acknowledgement

The work described herein was funded by the IST projectE-Colleg (IST-1999-11746).

Figure 5: Sequence Diagram of the Instance Manager

References

[1] DMH: www.dmhsoftware.com

[2] FutureSoft: www.futuresoft.com

[3] Oaks, S. ; Wong, H.: JINI in a Nutshell. O’Reilly Ver-lag, Köln, 2001.

[4] Project JXTA, Sun Microsystems: www.jxta.org

[5] Kostienko, T.; Mueller, W.; Pawlak, A.; Schat-tkowsky, T.: An Advanced Infrastructure for Collab-orative Engineering in Electronic design Automation.CE 2003, Madeira, Portugal, July 2003.

[6] MG-SOFT: www.mg-soft.si

[7] NuDesign Team: www.nudesignteam.com

[8] PiranhaWAP, ELC Technologies Inc.:www.elctech.com/ products_piranha.shtml

[9] Schattkowsky, T.; Mueller, W.: Distributed Engineer-ing Environment for the Design of Electronic Systems.CCE’03, April 15-16, 2003, Poznan Poland.

[10] Stallings, W. B.: SNMP, SNMPv2, SNMPv3 andRMON 1 and 2. Addison Wesley Longman Inc., Read-ing, Massachusetts, 1999.

[11] Thronicke, W.; Fox, W.; et al.: From Tool Inte-gration to Workflow Management - A Lean Integra-tion Solution. In Proc. 2nd World Conference on In-tegrated Design and Process Technology, Austin, TX,Dez. 1996.