A service oriented framework to set up flexible and distributed data acquisition and control systems P. Buschiazzo

A.M. Scapolla

University of Genoa Via Opera Pia 11/a Genoa, Italy +390103532271

University of Genoa Via Opera Pia 11/a Genoa, Italy +390103532271

paolo.buschiazzo @unige.it

[email protected]

ABSTRACT While networks of cooperating embedded devices are becoming more and more present in today’s digital world, the development of software at process control and management levels must face the heterogeneity and dynamic of the components of these distributed systems. This paper presents a service oriented model that enhances interoperability between low-level devices and control level applications. This model has been applied to the development of a prototype application named FoxController that can be deployed on embedded systems and is compliant to the Devices Profile for Web Service (DPWS) specifications. FoxController simplifies the setting up of flexible and distributed data acquisition and control systems.

Categories and Subject Descriptors J.2 [Computer Applications]: Physical Sciences and Engineering – electronics, engineering.

General Terms Measurement, Experimentation.

Keywords Embedded devices, web services, remote instrumentation control, Devices Profile for Web Service (DPWS).

1. INTRODUCTION A large number of areas, including industrial automation, environment sensing and remote laboratories for research and elearning, are looking for new models to set up distributed data acquisition, control and management systems. Network-enabled devices, which span from measurement instrumentation to embedded devices for data acquisition and processing, are the basic components of these systems.

The consumers of the information collected on the network are the front-end applications of the system. On the one side, we must be able to offer multiple end-user views of the system and to easy the development of new front-end applications or the update of the existing ones. On the other side, we would like to preserve the possibility of changes: new devices can be added or removed at any time. To fulfil these requirements it is necessary to hide the complexity of the hardware to the end-user applications. Managing the representations and the behaviours of the devices, combining them to form virtual devices are challenges faced by many researches in the last years [9, 19]. Recently the service oriented paradigm seems to offer new possibilities to design modular and scalable applications for controlling distributed devices [13, 12]. This paper presents a service oriented model that enhances interoperability between low-level devices and upper level applications. This model has been applied to the development of a prototype application. It is named FoxController and it is under development and test at the Department of Biophysical and Electronics Engineering (DIBE) of the University of Genoa. FoxController models the functionality of the devices as resources and implements a plug-in architecture. It can be deployed also on embedded systems. The paper is structured as follows: the next section analyses related works, the third section presents the main objectives of this work, the fourth section details the architecture of the FoxController application and finally, the conclusions are drawn.

2. RELATED WORKS Many projects and organizations proposed different solutions to provide flexible access and control of heterogeneous devices. Grid based instrument control is an active area of research and development. The GRIDCC [8] project studied a service oriented framework to integrate complex electronic instrumentations in the Grid world, introducing the concept of Instrument Element [11]. Remote control of instrumentations is realized through a general purpose web service interface that supports remote configuration and control of the instruments. While the web service interface is mainly used to configure the instruments, a message based communication system, built on Java Message Service (JMS) technology, provides efficient one-to-many data exchange. The Open Geospatial Consortium (OGC) [16] developed a set of specifications called Sensor Web Enablement (SWE) to manage the acquisition of geographical and land survey data from complex devices such as satellites. SensorML [3] is one of the

SWE specifications and aims at describing sensor functionalities and data format as XML documents. A more consolidated and standard technology, which is used to control a wide range of devices, is OPC (OLE for Process Control) [17]. It is well known and accepted in the industrial automation area and it allows integrating the information collected from field devices into the business systems in a consistent manner. OPC is mainly based on COM and DCOM technology; it provides a web service interface communication system, which is described by the XML Data Access (XML-DA) specifications, and a subset of the functionality available with COM/DCOM communication. Schwartz et al. [14] presented a general purpose management architecture which allows controlling heterogeneous networked embedded devices with a plug-in approach. The proposed solution supports different protocols, such as SNMP, Jini and UPnP. Moreover, service oriented middleware to access heterogeneous remote laboratory equipments [1] and to control networks of small devices [2] have been already investigated and proposed by others. The work presented in this paper takes advantage from the mentioned experiences and aims at extending them by proposing a solution that can be adopted in different contexts and relies on the web service paradigm and the Devices Profile for Web Service (DPWS) specifications [18].

3. GOALS This section describes the main goals that the authors pursued in designing the FoxController model and prototype application.

3.1 Data Oriented Representation of Devices A way to represent a device could be modelling it as an object [4]: each type of devices is associated to a class with a proper API and each device is an instance of such a class that can be accessed using the methods provided by its interface. This approach is both simple and powerful, and benefits of the object oriented paradigm, but it has also some drawbacks. If it is applied to systems composed by heterogeneous devices, it requires defining a specific WSDL (Web Services Description Language) interface for each device. This solution is generally not convenient since WSDL doesn’t support the concept of class inheritance and this makes interfaces changes or upgrades difficult. In fact, if a new type of device were added to the system, all the client applications, which use it, must be updated to support the new device interface. Moreover, data aggregation from different devices is not immediate and generally, it requires ad hoc processes. Thus this approach lacks scalability and cannot be applied to large distributed systems easily. An alternative solution can be found adopting a data oriented approach, where devices are modelled as sets of resources, which can be managed as input or output data sources. The control system presented in this paper models device functionality or a phenomenon captured by the devices as abstract resources. For example, let us consider a simple heating system, composed by temperature sensors and a heater device. The abstract resources of this system could be the values of temperature, which are decimal numbers, and the status (“on” or “off”) of the heater. Both these resources can be read and the heater status can also be written. A

control process will read the temperatures and turn on or off the heater device. In presence of more complex devices, the resources may be not only simple variables, but also textual or XML encoded commands, which change the device configuration, or data flows. Sometimes it can be convenient to associate resources to a virtual device and to hide the complexity of the physical layer to the front-end applications developers. In the authors’ opinion, the main advantage associated to the data oriented approach is the possibility to implement a single general purpose web service interface, which can be used to control a wide range of devices. Since every device functionality is represented as a resource, the general purpose web service interface must provide adequate methods to read, write and list all the available resources. These can be described by RDF/XML metadata that specify their attributes and capability, and can refer to standardized schemas. The usage of only one service interface towards different devices easies the data aggregation processes.

3.2 Dynamic Device Discovery and Event Handling The awareness of which devices are available and are involved in the control process is a crucial topic. Device discovery mechanisms can be based on initiatives of a coordination node or include the possibility for a specific node to notify to the others when it is added or removed from the system. A well known discovery mechanism used in service oriented architectures is the Universal Description, Discovery and Integration (UDDI) registry, which is an open, XML-based framework for describing, discovering, and publishing business services [20]. UDDI is an industry initiative that attempts to provide a dynamic environment, where companies publish and search services of partner or customer companies to accomplish complex B2B operations. UDDI registries are similar to common search engines, where software developers publish services, put information about them and query the registry to discover services matching various criteria. UDDI can register three types of information for each business service: white pages, yellow pages and green pages, which respectively contain general information on services, services categorization organized as taxonomies and detailed information on the functionality and the location of each business service. The Grid community has developed a specific system for publishing, locating, and subscribing to services in a grid infrastructure: the Index Service [6]. It is similar to UDDI and collects services provided by various grid nodes using a hierarchical architecture to aggregate the information at different levels. While UDDI and Index Service are good solutions when applied to the Internet and WAN infrastructures, they can be inappropriate in small local networks because of their centralized and hierarchical structure. A system composed by resourceconstrained nodes belonging to the same local area network needs a dynamic and flexible service discovery mechanism and can benefit of an approach based on multicast messages and asynchronous notifications. This approach is fully implemented in the DPWS specifications that target service oriented architectures for embedded systems [21]. The DPWS specifications define a set of built-in functionality to enable basic interoperability between

devices: discovery, notification of events, security and proxy are supported. Web Services Dynamic Discovery (WS-Discovery) is used by a node to advertise its presence and to discover other nodes. These mechanisms allow to add a new device and to have it active automatically, without any manual configuration. Device discovery can be active or passive. With active device discovery, the application looks for devices sending multicast messages on the network and waits for answers by the devices. Instead, with passive device discovery, the application listens out for the presence announcements by the devices without soliciting them. WS-Discovery messages use SOAP encapsulated in UDP multicast datagrams. Another important specification contained in DPWS is WSEventing, which defines an asynchronous mechanism for delivering events from devices to subscriber clients. In order to receive event notifications, a client must send a subscription message to the device, which generates the events. Events can be alarms, notifications of the end of a specific job or of the availability of new data from a sensor. FoxController makes use of DPWS specifications to provide both automatic device discovery and event notifications. The web service interface implemented by FoxController is detailed in section 4.2.

3.3 Flexibility and Reconfigurability Plug and play is a consolidated and well known technology which is usually referred to hot plug standards such as USB. Typically, plug and play systems use a common communication bus and a unified protocol to manage different devices. FoxController uses a similar approach to interconnect the devices. Figure 1 presents an application scenario, where heterogeneous networked devices monitor and acquire data from the environment. In this example we have a network enabled spectrum analyzer, which measures RF signals, and another board that connects a webcam and several temperature sensors. All the devices can be controlled by different front end applications at the same time. Depending on the kind of device, FoxController can be used in different manners. For example, when a device can be customized and supports additional software installation, FoxController can be directly installed on it. Typical examples of such devices are modern oscilloscopes and spectrum analyzers, which are fitted out with complete operating systems. In Figure 1, the spectrum analyzer runs FoxController that exposes three resources: the acquired data, the internal configuration, both serialized as XML documents, and the screen dump, represented as a JPEG image. While the spectrum analyzer data and the screen dump are readonly resources, the internal configuration can also be changed sending to the device textual commands.

Figure 1. An application scenario composed by heterogeneous devices.

The low level communication layer between Foxcontroller and the device is implemented through a specific plug-in, which sends GPIB commands to the spectrum analyzer and grabs the output data and the screen dump. Very simple devices, such as temperature sensors and low cost webcams, cannot directly run FoxController, since they don’t host complete operating systems and lack networking functionality. For example, if devices can be controlled only through USB or serial interfaces, FoxController must be deployed on a dedicated control unit, such as a single board computer, which acts as a proxy and mediates the communication between the front end applications and the devices. Figure 1 presents a single board computer, which controls a USB webcam, used to capture images from the environment, and several temperature sensors. In this case FoxController manages two plug-ins at the same time, one for each device type: the webcam is managed by the Cam plug-in, and the temperature sensors are managed by the Temp sensor. While the webcam plug-in associates to the webcam a single resource, which represents a frame encoded as JPEG image, the Temp plug-in can manage several resources, each of them is associated with a temperature sensor. The resources, which are exposed by the control units, can be dynamically added or removed, the middleware hides the hardware details. Moreover, front end applications can listen and discover new resources and interact with them using the methods of the Web Service Interface. The scenario is completely decentralized and, if a device were removed, the distributed control system would automatically update the network topology.

4. FoxController This section presents the architecture of FoxController, the details of the interface toward the front-end applications and the functionality implemented by the device plug-ins.

4.1 The Architecture FoxController is a platform independent solution, it is written in C language and it can be deployed on different hardware architectures such as x86, FoxBoard [7] or ARM. It can be used in both Linux and Windows operating systems. Figure 2 details the application internal architecture.

Figure 2. FoxController Architecture

There are five main modules: the session manager, the event dispatcher, the resource list, the plug-in manager and the web service interface. The session manager is responsible for a reliable access to the resources and handles their status among multiple requests from the front-end applications. The FoxController session concept is very similar to the session mechanism implemented in web server applications: each session is a collection of variables which can be saved as key-value pairs. The event dispatcher module is responsible for delivering asynchronous notifications to clients that subscribed to the notification service. The event dispatcher is composed of two parts: a notification queue and a background process. The notification queue is the list of events waiting for being dispatched to event subscribers. When a device needs to notify an event, such as an alarm or the availability of new data, the associated plug-in creates a new event and puts it into the notification queue. The background process manages the notification queue and forwards the events to the DPWS interface. The resource list is the collection of the resources managed by FoxController. FoxController exposes the devices as a collection of resources through a single general purpose web service interface, which accepts data as opaque objects, typically plain strings, serialized XML or Base64 encoded data. Front end applications query the list to know which resources are available. The plug-ins, which directly control the devices, are managed by a specific module, the plug-in manager, which loads them at startup time. Plug-ins are dynamic-link libraries in Windows OS, or shared objects in Linux OS, which implement a simple set of C functions. Figure 2 points out that a single instance of FoxController can manage different plug-ins simultaneously. This feature is particularly useful when FoxController is deployed on a single board computer which controls several devices. The web service interface and the plug-in manager, which are the most important modules of FoxController, are further detailed in the next subsections.

4.2 A General Purpose Service Interface The Web Service Interface implements a flexible and domain independent interface towards the higher level applications. It is compliant to the DPWS specifications and its methods allow device discovery and event notification mechanisms. Particularly, the FoxController prototype has been developed using the DPWS open source implementation provided by SOA4D initiative [15, 10]. Figure 3 lists the FoxController web methods.

Figure 3. FoxController interface

As plain web service technology doesn't provide a session mechanism and it is associated to a stateless request-response model (a concept directly taken from the HTTP protocol), the OpenSession and CloseSession methods have been implemented. Creating a session allows a client application to store configuration data for a specific device and when the CloseSession is called or a timeout occurs data is removed. The GetResourceList operation returns the list of the resources controlled by FoxController. More information about resources can be retrieved calling the GetMedadata operation for each resource: each plug-in provides an XML representation of the resource, where type, read/write permission and other information are detailed. Once a valid session has been established, all the resources can be directly accessed using the following operations: GetValue, GetBinValue, SetValue and SetBinValue. Each Get or Set operation is implemented for both text/XML data and binary Base64 data exchange. Invoking the Subscribe operation, which is a standard operation provided by the DPWS specifications, a client application can register itself for receiving asynchronous events from the FoxController. New events are forwarded through the NotifyEvent method. A notification allows sending a SOAP message to a client without being solicited by the client itself. FoxController service interface also provides discovery functionality to enable an embedded device to be dynamically discovered by client applications. The discovery system relies on SOAP-over-UPD [5], which is part of the DPWS specifications and defines a binding for SOAP messages to UDP. Discovery messages are sent through multicast channels.

4.3 Device Plug-ins Each plug-in exports the device functionality as abstract resources and uses the session manager, and the event dispatcher to interact with the web service interface. When a plug-in is loaded at startup, it initializes the controlled devices and adds new resources to the resource list, which are identified by a unique string ID. When a client application asks FoxController for a specific resource, the plug-in associated to the resource is invoked. It interacts with the device by low level primitives and specific protocols. Plug-ins use the session manager to save device configurations and provide complete description of the resources (metadata) to higher level applications. During the development and testing of FoxController, a custom XML Schema was adopted to describe the resources, but FoxController doesn’t depend on specific metadata choice. FoxController plug-ins must be realized in C or C++ language and they constitute the sole platform-dependent part of the embedded control system. Developing a new plug-in is not a complex task, since each plug-in must implement a common interface composed by a restricted set of C functions which define the resources, their access policies and the events that can be raised. The plug-ins implement the low level communication with the devices and act as a sort of device drivers since FoxController completely relies on plug-ins to control the devices, it is very easy to face device changes and upgrades. In fact, if new functionality must be implemented or the communication protocol with the device must be changed, the whole control system can be conserved, while a new plug-in can replace the old one. This solution allows preserving the whole control system, which works

on abstract resources, while devices can be added/modified dynamically.

4.4 Comparison with alternative approaches Alternative approaches, like OPC and LabVIEW, are very consolidated and offer extensive support for accessing and controlling hardware devices, but they propose highly coupled solutions, where clients and server are very dependent on each other. There are limits to integrate parts of software developed with different technologies and the service oriented approach is only partially implemented. On the contrary, FoxController adopts the loosely coupled and distributed model offered by DPWS. Devices are modelled as abstract resources and can be dynamically added or removed. Changes in the network topology can be notified to the front end applications, developed with different languages and running on diverse operating systems. This contributes to reduce set-up and maintenance costs. In addition, FoxController doesn’t require any runtime environment, such as LabVIEW, since it is completely implemented in platform independent C code, and it can be directly deployed on resource constrained devices. FoxController can interact with different technologies, both through its web service interface, and through the plug-in system. In particular the plug-in modules implement a small set of C functions and can be easily linked to external libraries developed with other technologies, such as COM, OPC or LabVIEW.

5. FUTURE WORKS In the near future the authors are planning to use the service oriented application described in this paper in two different application scenarios: a remote laboratory on Digital Signal Processing and a wireless sensor network for monitoring environmental conditions of a wide indoor area. In addition, future works will also investigate the Message Transmission Optimization Mechanism (MTOM) which allows efficient binary encoding in SOAP message. Finally, metadata description will be further enhanced with semantic web technologies in order to provide a formal description of the controlled devices.

REFERENCES [1] Bagnasco, A. Boccardo, A. ,. Buschiazzo, P. Poggi, A. Scapolla, A.M., A Service-Oriented Educational Laboratory for Electronics, Accepted for future publication in IEEE Transactions on Industrial Electronics: DOI:10.1109/TIE.2008.2002729. [2] Bagnasco, A. , Buschiazzo, P., Carlino, L. , Scapolla, A.M. , A Service Oriented Wireless Sensor Network for power metering, International Conference INGRID 2008, Lacco Ameno, Italy, April 2008. [3] Botts, M., Robin, A., OpenGIS Sensor Model Language (SensorML) Implementation Specification, 2007, http://www.opengeospatial.org/standards/sensorml. [4] Chao, C., Helal, S., Sifting Through the Jungle of Sensor Standards, Pervasive Computing, IEEE, Volume 7, Issue 4, Oct.-Dec. 2008 Page(s):84 – 88 (DOI: 10.1109/MPRV.2008.81).

[5] Combs H et al., SOAP-over-UDP, 2004, http://specs.xmlsoap.org/ws/2004/09/soap-over-udp/soapover-udp.pdf [6] Czajkowski, K., Fitzgerald, S. , Foster, I. , Kesselman, C. , Grid Information Services for Distributed Resource Sharing, Proceedings of the Tenth IEEE International Symposium on High-Performance Distributed Computing (HPDC-10), IEEE Press, August 2001.

of AINAW 2008 - Advanced Information Networking and Applications - Workshops, 25-28 March 2008 [13] Ponta, D. , Scapolla, A,M., Buschiazzo, P. , Survey of Remote Laboratories Using Service Oriented Architectures, International Journal of Online Engineering, Vol. 5, No. 1, 009. (doi:10.3991/ijoe.v5i1.781)

[7] Fox Board, a Linux Core Engine in just 66x72 mm, ACME Systems, http://foxlx.acmesystems.it.

[14] Schwartz, E. , Holzer, D.A. , Maloney, J. , Fitzpatrick, K. , System and method to manage network-enabled embedded devices operating under various protocols, Patent. Patent number: 6836796.

[8] Grid enabled Remote Instrumentation with Distributed Control and Computation, http://www.gridcc.org/ .

[15] Service-Oriented Architecture for Devices, https://forge.soa4d.org/ .

[9] Harward, V.J., Del Alamo, J.A. , et al., The iLab Shared Architecture: A Web Services Infrastructure to Build Communities of Internet Accessible Laboratories, Proceedings of the IEEE, Vol. 96, No. 6, 2008. (DOI:10.1109/JPROC.2008.921607)

[16] The Open Geospatial Consortium, http://www.opengeospatial.org/ .

[10] Kirkham T., Savio, D., Smit, H., Harrison, R., Monfared R.P., Phaithoonbuathong, P., SOA middleware and automation: Services, applications and architectures, Industrial Informatics, 2008. INDIN 2008. (DOI: 10.1109/INDIN.2008.4618326) [11] Lelli, F. , Maron, G., The GRIDCC project, In Distributed Cooperative Laboratories: Networking, Instrumentation, and Measurements, F. Davoli, S. Palazzo, and S. Zappatore, Eds. New York: Springer, 2006, pp. 269–277. [12] Pohl, A., Krumm, H., Holland, F., Luck, I., Stewing, F.-J., Service-Orientation and Flexible Service Binding in Distributed Automation and Control Systems, Proceedings

[17] The OPC Foundation, http://www.opcfoundation.org/ . [18] The Devices Profile for Web Service specification, http://specs.xmlsoap.org/ws/2006/02/devprof/devicesprofile. pdf . [19] Tröger , P. , Rasche, A., Feinbube, F., Wierschke, R. , SOA Meets Robots - A Service-Based Software Infrastructure for Remote Laboratories, International Journal of Online Engineering, Vol. 4, No. 2, 2008. [20] Universal Description Discovery and Integration Spec. Technical Committee, http://www.uddi.org/ . [21] Zeeb, E., Bobek, A., Bohn H., Golatowski, F. , ServiceOriented Architectures for Embedded Systems Using Devices Profile for Web Services, 2007, International Conference AINAW '07 (DOI: 10.1109/AINAW.2007.330)