1. Abstract
[an error occurred while processing this directive]This paper presents an implementation of a wireless control and surveillance demonstrator for the EIB fieldbus using both the PalmV with a Bluetooth connection and a Compaq iPAQ with an 802.11b connection. The implementation relies on off-the-shelf software components, including OPC client/server and web browser technology. The paper highlights the implementation of the solutions, and in particular the pros and cons of the two platforms.

[an error occurred while processing this directive]

2. Introduction
2.1 Background
In the automation industry, there is a severe cost pressure at every level of the control hierarchy, from the component producers up to the solution providers. Traditionally, different systems have often been executing in different run-time environments, requiring specific sensor/actuator solutions. For example, a maintenance system could run on a PC with its own manually read sensors, while the production system could run on a mainframe computer. Today, the requirement for increased efficiency and reduced cost forces the industry to rethink these old strategies. The Internet is the major driver towards interoperability and information-flow at all levels. All systems need to be integrated and interoperable, regardless of geographical location and hierarchical constraints.

2.2 Building systems
In building automation there is an urgent need for increased performance with respect to system integration and flexible building utilization. Systems for handling energy optimization, ventilation, fire and water alarms, as well as security require interoperability. In addition, there is an increasing demand for mobility within the building premises, where every employee will be provided with their own portable device. In such a setting, it appears evident that optimal building control should be based on the same fundamental principles, i.e. it must be wireless enabled, use standard Internet technology, and utilize existing standard field bus interfaces. This has led to the development of the wireless OPC control.

3. Wireless implementation of EIB monitoring and control 
The current implementation is a prototype of the above ideas. It demonstrates how field device data can be made available to a handheld wireless device irrespective of device location. Off-the-shelf technology is used whenever possible. The solution is based on current Internet technology. On the fieldbus side the OPC server interfaced to an EIB bus, with a presence detector, temperature sensor, and a number of relays.

3.1 General architecture
Implementing the demonstrator turned out to be more of an integration project than a programming exercise of the application itself. This can be seen from the figure below, showing the data access path through the different system components.

The Field Devices, field bus, and the configuration of the OPC Server, shown in the figure as the gray area, are research topics in their own right and will not be covered here. The OPC Server presents a standardized interface to any user according to the OPC Data Access Interface Standard. The amount of functionality available in the server varies, but the interfaces are generic and vendor independent.

The Internet Server, with the Web Server and the OPC interface, is in principle accessible from anywhere. In terms of performance, however, it is preferable to run the OPC and Internet servers on the same machine, or at least on the same LAN.

The Client/User side is application independent in that it only contains a Web Browser supporting pure HTML-files, i.e. no DHTML, Java, or ASP.

3.2 Application development
The application was developed on an ordinary PC with Microsoft Visual InterDev 6.0. It consists of two parts, an HTML page providing the interface to the user, and the an ASP-script responsible for the access to the OPC server. This script receives the request from the HTML page, looks up OPC-data in the server and presents the HTML page back to the Web Client. This sequence of events is shown in the figure below.

The sequence diagram indicates signaling only, no data transfer is shown. The dotted lines refer to optional signaling messages in that data may be accessed from the cache in OPC server or from the device itself. In the present application it was decided to only access the cache. As this is updated on a regular basis from the device bus it does not reduce the performance of the system.

A non-trivial part of the application development was to access known OPC data. There is no standardized way to mark the splits between branches in an OPC tree. The downside is that access is achieved by means of the OPC browser, and not by preprogrammed links to devices.

3.3 Palm specific implementation 
A "WorkPad c3" from IBM was used as client. It has 8Mb memory and a 20MHz processor and runs PalmOS 3.5. The Bluetooth BlueV add-on module from Tactel was connected to the Palm serial port with the bit rate set to 58.7kbits. The Palm is unable use this bandwidth while processing the Bluetooth stack. The bandwidth requirement depends on the packet size being transmitted. Sending short messages, without any other processing than traversing the stack, it turned out that the Palm was only able to send five packets/second. The payload from Palm to PC was something less than 40kbit/s.

The figure shows how the elements are connected together in the demonstrator set-up and also the individual layers of the communication and application stack in the Palm implementation.

On the Server side the Mocha W32 PPP (MochaPPP shareware) was installed. This connects the Server serial port to the Internet. Using the Bluetooth Sword module - also from Tactel - on the Server side of the serial port a wireless connection is established between the Palm and Internet, and hence the OPC server. The wireless connection point and the Web Server will normally be in different nodes, but is shown as one Server node in the figure for simplicity.

The Palm screen dump shows the result after an OPC browse request. The variable paths with values are shown.

After an evaluation of different Palm Web-browsers, the EudoraWeb 2.1 from Qualcomm [2] was selected. The browser does not support applets. This is needed to have an active interface page receiving alarms and events. Access to the OPC data is thus limited to the return of requested information, requiring active participation from the user.

3.4 iPAQ specific implementation 
The iPAQ/802.11 demonstrator was developed using a standard iPAQ 3600 with 32Mbytes of memory running at 206 MHz using an Intel StrongARM SA-1110 32-bit RISC processor. The wireless network was a Cisco Aironet 340, 11Mbps wireless LAN. The iPAQ executed on Windows CE 3.0 with a Microsoft Internet Web Browser.

The figure below depicts the communication stack in this configuration.

We note a number of differences between this implementation and the Palm. First, we see that there is an application running in the Client. This application contains an applet that accesses the web server at regular interval. This way the Client is able to receive alarms and events, something we are unable to do with the Palm solution. Apart from this, the access to OPC server is the same for this solution as for the Palm. There is also a simplification in that the Cisco access point is Ethernet based, simplifying the stack required in the Server. Thus, the PPP layer required for the Palm is avoided using iPAQ and 802.11b.

3.5 Pros and cons of the platforms 
Although the two platforms were seen to provide the same overall functionality, we still note a few differences. Weather these are of significant importance would obviously depend on the application. In particular: · The iPAQ platform supports applets. This enables the use of live alarms and alerts. By contrast, data has to be requested with the Palm solution. · There is a significant difference in bandwidth, with the 802.11b providing a maximum of 11Mbps versus 57.6kbps for the Palm serial port. This was not a problem for our application but could turn out to be problematic for large installations, or if the application require images to be transferred. · The iPAQ is essentially a PC, running standard, or almost standard, PC software. This leads to simpler, and more future proof, solutions. · The iPAQ has significantly shorter battery life than the Palm. Again, this may be a problem in some applications and not in others. It certainly is an element to consider.

4. Future possibilities
The possible future extensions to the current demonstrator are numerous. The most obvious candidates include: · Supporting XML from the application. This would greatly simplify the adaptation of the application to new platforms. · Use of wireless OPC control in safety critical applications. · Integration with other system.

5. Conclusion 
This demonstrator has shown the possibilities and limitations with wireless OPC access using both a Palm and an iPAQ. The primary observation is that fieldbus control that can be achieved using both platforms. We also noted a number of differences between the two platforms, in particular the ability of the iPAQ to run applets, enabling alarm and event handling.

6. Abbreviations
MMI Man Machine Interface EIB European Installation Bus HMI Handheld Machine Interface LAN Local Area Network WAN Wide Area Network PDA Personal Digital Assistant Palm PDA from Palm with PalmOS iPAQ Pocket PC, Compaq MS CE HTML Hyper Text Mark-up Language ASP Active Service Pages OLE Object Linking and Embedding OPC OLE for Process Control ISP Internet service Provider

7. References 
[1] http://msdn.microsoft.com/ 
[2] http://www.eudora.com/ 
[3] http://www.mochasoft.dk/ 
[4] http://www.tactel.se/

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]