Integrating LonWorks into an open systems control ... - CiteSeerX

Integrating LonWorks into an open systems control environment Richard Greenane and Simon Dobson Department of Computer Science Trinity College Dublin 2, Ireland [email protected]

Abstract. A new phase of smart buildings is being developed within the Computer Science Department at Trinity College Dublin. For this to give maximum benefit to the largest number of people would mean cabling a huge area with CAT5 Twisted Pair and installing a number of LonWorks network interface cards in many PCs. Instead, it has been decided to use the existing Ethernet cable structure as a main base for controlling several smaller LonWorks networks incorporating a new piece of software that has been developed for LonWorks and the latest CORBA middleware technologies to allow a seamless interaction between a number of client PCs and one host which contains a LonWorks network interface card. We explain the tool and the present results from some simple tests. It will be shown that by using this tool, LonWorks networks can be controlled by many operating systems and software clients can be written using any programming language. Keywords: CORBA, LonWorks, Integration

1

Introduction

With the increasing popularity of the Intelligent Building for the home user and offices in the industrial sector, the convergence between home and office is likely to be increasingly achieved. Research has been undertaken to increase the possibilities of controlling the home and the office from one small device or Personal Digital Assistant (PDA). Many networked structures already exist in the office environment. These include standard thin or CAT5 Ethernet cabling, telephone connections and small amounts of three channel video cabling. Similarly, the home environment would usually contain a telephone line which can be easily extended to create a small network around the home. Adding a LonWorks 1 control network into such environments would present many problems in terms of cost, disruption and time penalties incurred during retrofitting. It would also be hard to provide full LonWorks Network Services (LNS) access to every user – desirable for a research environment – without 1

LonWorks is a registered trademark of Echelon Corporation

wiring cables to every computer. However, generally, every computer within an office has access to the general Ethernet network, and beyond this to the Internet. At Trinity College we are especially interested in smart building technology in the domains of process control and assistive robotics, integrating static and mobile information sources, controls and appliances to construct informationenhanced services. Such applications require substantial infra-structural support across a number of platforms, hosts, protocols and operating environments – a requirement which mitigates against a single proprietary solution across a complete application. Moreover we view such information-assisted applications as being inherently distributed at Internet scales, and so they must be integrated with (and controllable through) standard Internet protocols and services. Our recent work has focused on “opening-up” LonWorks networks so as to integrate them with this wider networking context, allowing seamless interaction of devices distributed across our range of wired, wireless and control networks. This has been accomplished by developing a protocol bridge to control a LonWorks network via standard CORBA 2 distributed middleware. In this paper we briefly describe the architecture and an implementation of the protocol bridge and its place in the spectrum of distributed technologies, and discuss some possible applications.

2

Architecture – Structuring a network to cope with system integration

The Department of Computer Science at Trinity College is – as might be expected – heavily networked. The main networks consist of standard wired Ethernet with Internet connection, a WaveLAN 3 wireless Ethernet spanning the main building, and a small LonWorks network. The LonWorks network system is intended to control doors, elevator and other physical systems, as well as providing low-bandwidth sensors. From an architectural perspective the heterogeneity of the network environment has a number of important properties. It means that a number of media are available for any interaction. This means that it is possible to select the “most appropriate” medium for a given data stream – and, by implication, that applications must be able to make this choice somehow. This may result in asymmetric interactions, in the sense that up-stream and down-stream data are better carried over different media. Semi-autonomous mobile robots provide a good example of the use of this technology. All three networks are used to control a small mobile robot through 2 3

Common Object Request Broker Architecture WaveLAN is a registered trademark of Lucent Technologies

a building performing fetch and carry tasks. The robot is guided by acquiring locale information from network nodes, which provide data concerning the localised position and information about the robot’s immediate area. Search techniques [4], [3] can be used to give the robot its best route of travel between two points. The network nodes can also be used to gather information about the local environment, such as the movement of people [1], [2] and objects (using “active badges” or other tracking technology). It is also possible to transfer information bidirectionally between PDAs (Personal Digital Assistants) so that (for example) students may read their email and check lecture schedules without using valuable resources such as fixed PCs. These small devices can also be used to allow voice activation of the local environment [5]. It is easy to see that the explicit use of a particular network by applications would be very complex, both for the programmer in having to make the selection in a (possibly unknown) environment and for the building in deciding how to communicate with a device which may not be listening on the right medium. Similar problems have been encountered before in network evolution, leading, on the one hand, to the development of standardised inter-networking protocols to connect heterogeneous local area networks and, on the other, to standardised distributed middleware supporting communication between applications on different software platforms. The basic strategy in both cases has been to provide abstract operations for naming, communication and other facilities which may then be mapped more or less transparently onto whatever underlying hardware and software is present. One may also interpose software at critical points to perform traffic management and resource location.

3

Solution – LonWorks network-Ethernet bridge

Our approach to this problem therefore follows two strands. At architectural level we have developed a management architecture for heterogeneous mobile systems [6] which leverages standard CORBA services to provide structured access to building- and application-wide information. To facilitate this we have constructed a bridge exporting LonWorks network control functionality through a CORBA interface. This allows applications to use a standard middleware architecture to interrogate and control any devices to which they should have access, with a capability system to provide access control. An additional advantage of this approach is that it localises platform dependencies such as LNS requirement for a Windows NT host: clients only require CORBA capabilities to access LonWorks network devices. The bridge system is a CORBA server which executes on one computer that can be accessed by any computer attached to the Ethernet. Computers run small clients which act in the same way as an LNS client.

Fig. 1. The Building Network Structure

The server is a complete class wrapper of the LCA Object Server using the Orbix 4 CORBA implementation. CORBA is platform independent and so, with the use of the bridge, it is possible to write network clients for a LonWorks network system that execute on UNIX, Linux, Solaris, MS Windows, DOS and Macintosh operating systems. Figure 1 shows the structure and position of the new bridge and the interoperability that can be achieved. The new bridge allows the control network to be compatible with the diverse needs of everyone within a research environment. Clients for the bridge can also be written using any programming language with a CORBA binding e.g. C++, Java, Visual Basic and Perl. The bridge also enables the network to be controlled via the World Wide Web so that a building may be managed by its owner from anywhere in the world which would be advantageous to large companies for auditing and overhead budgeting purposes.

4

Testing and results

The interface for the object that represents the LCA Object server can be seen below. interface IObjectServer { exception LonError { //Exception handling for CORBA long ErrorCode; //Any exception gets given a code and string string Reason; }; ............... void ObjectServerClose(); void ObjectServerCompactDb(); void ObjectServerAboutBox(); INetworkInterface GetObjectServerActiveRemoteNI(); INetwork GetObjectServerActiveNetwork(); } The function names have had to be slightly changed and are different from the function names of the LNS objects. This is because the structure of CORBA dictates that two functions in any one server must not use identical names. Therefore all functions have had their class names added into them. For example, if in a class (or interface) there is a GetNetworks() function, then the function has been changed to GetNetworks(). This way of function naming is standard throughout the software. 4

Orbix is a registered trademark of IONA Technologies

Writing clients for the network bridge is as easy as writing LNS clients using the LNS ActiveX control. An excerpt of code from an example client, written in C++ is: try { //Get the networks object INetworks_var pINetworks = m_ObjectServer->GetNetworks(); //Get the first network object INetwork_var pINetwork = pINetworks->GetNetworksItem(1); //Get the systems object ISystems_var pISystems = pINetwork->GetNetworkSystems(); //Get the first system object ISystem_var pISystem = pISystems->GetSystemsItem(1); //Get the subsytems ISubsystems_var pISubsystems = pISystem->GetSystemSubsystems(); lngCount = pISubsystems->GetSubsystemsCount(); //For each subsystem found see if the name of that subsystem is Lab Net for (i=1;iGetSubsystemsItem(i); SubsystemName = pISubsystem->GetSubsystemName(); if (SubsystemName == "Lab Net") { //Break out of loop } } } The client above looks very similar to an LNS client and is actually a simple program used to test some lighting control devices that have been made “in house”. The variables defined as var are CORBA defined variables which give access to the different interfaces. Each interface is a complete wrapping of each object in the LNS Object hierarchy. The program above is written for Windows NT but could easily have the Windows specific aspects taken out and replaced with code that works for other operating systems. Clients have been written and tested for three operating systems, Linux, Solaris and MS Windows (NT, 95 and 98). At present the hardware capabilities

which are available to us, for testing, are very limited. Therefore a full set of test results are not yet available. However, using the simple nodes that are available has provided promising results. The speed differential between using a bridge client and an LNS client is negligible, most of the time being taken up with calls to the LNS client. Moreover, simple tests have shown that the protocol bridge client only increases the time for one function call by approximately 3%. Work is already being undertaken to provide an event service for the bridge so that LonWorks network events are handled efficiently even in non-event based Operating Systems such as Linux. A policy service is also under way that will support a large number of additional components to provide new services such as resource sharing and data encryption.

5

Conclusions

Large-scale smart buildings will undoubtedly need multiple heterogeneous networks in order to cope with different quality of service requirements, and will furthermore require access to the wider networking context of the Internet and distributed applications. Integrating LonWorks networks into a standard middleware architecture is a small step towards facilitating this. The new bridge is a cheap alternative to any hardware bridge systems and requires no more prior knowledge of an environment other than that of LNS. The bridge allows a company or institution to distribute only one license and copy of the LCA Object Server ActiveX control and so LNS license keys are only given to the bridge administrator. A number of clients can be written, which do not use the LCA Object Server. At present the OnNetworkVariableUpdate() and other events have not been implemented, therefore the software is not yet ready for the open market but future revisions of the software will include this as Orbix supports an event service. Testing of the bridge shows that there is only a slight latency between using an LNS client and a CORBA client. Obviously, high network traffic on the Ethernet network could slow down the CORBA process, but the network packets which are produced by the server are sufficiently small to be transferred quickly.

References 1. Andy Hopper Andy Harter, A distributed location system for the active office, IEEE Network 8 (1994). 2. Any Hopper Andy Ward, Alan Jones, The active badge location system, ACM Trans. Information Systems 10 (1992). 3. F.O Hart G.T Foster, D.E Wenn, Generating virtual environments to allow increased access to the built environment, ECDVRAT 97, 1998. 4. J.P.N Glover G.T Foster, D.E.N Wenn, Ariadne - exploiting a new generation of intelligents buildings, Distributed Systems Research Group, University of Reading, England. http://www.cyber.rdg.ac.uk, 1998.

5. Parmjit Chima Thomas Davenport, Talkbox - a voice activated environmental controller, EU Tide Conference, March 1998. 6. S.A Dobson T.Walsh, P.A Nixon, A managed architecture for mobile and distributed applications, Tech. Report TCD-CS-1999-03, Trinity College, Dublin, University of Dublin, Ireland, 1999.